chain/binutils.git - Unnamed repository; edit this file 'description' to name the repository.
aboutsummaryrefslogtreecommitdiff
path: root/ChangeLog.git
blob: ba5ed49397e33a5354f00c74dc8325db5e8f6466 (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
6371
6372
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
6821
6822
6823
6824
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
6923
6924
6925
6926
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
7164
7165
7166
7167
7168
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
7705
7706
7707
7708
7709
7710
7711
7712
7713
7714
7715
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
7842
7843
7844
7845
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
7866
7867
7868
7869
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
7919
7920
7921
7922
7923
7924
7925
7926
7927
7928
7929
7930
7931
7932
7933
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
7956
7957
7958
7959
7960
7961
7962
7963
7964
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
7988
7989
7990
7991
7992
7993
7994
7995
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
8161
8162
8163
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234
8235
8236
8237
8238
8239
8240
8241
8242
8243
8244
8245
8246
8247
8248
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290
8291
8292
8293
8294
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
8329
8330
8331
8332
8333
8334
8335
8336
8337
8338
8339
8340
8341
8342
8343
8344
8345
8346
8347
8348
8349
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
8379
8380
8381
8382
8383
8384
8385
8386
8387
8388
8389
8390
8391
8392
8393
8394
8395
8396
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
8418
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
8485
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
8563
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
8585
8586
8587
8588
8589
8590
8591
8592
8593
8594
8595
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
8640
8641
8642
8643
8644
8645
8646
8647
8648
8649
8650
8651
8652
8653
8654
8655
8656
8657
8658
8659
8660
8661
8662
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
9639
9640
9641
9642
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
9654
9655
9656
9657
9658
9659
9660
9661
9662
9663
9664
9665
9666
9667
9668
9669
9670
9671
9672
9673
9674
9675
9676
9677
9678
9679
9680
9681
9682
9683
9684
9685
9686
9687
9688
9689
9690
9691
9692
9693
9694
9695
9696
9697
9698
9699
9700
9701
9702
9703
9704
9705
9706
9707
9708
9709
9710
9711
9712
9713
9714
9715
9716
9717
9718
9719
9720
9721
9722
9723
9724
9725
9726
9727
9728
9729
9730
9731
9732
9733
9734
9735
9736
9737
9738
9739
9740
9741
9742
9743
9744
9745
9746
9747
9748
9749
9750
9751
9752
9753
9754
9755
9756
9757
9758
9759
9760
9761
9762
9763
9764
9765
9766
9767
9768
9769
9770
9771
9772
9773
9774
9775
9776
9777
9778
9779
9780
9781
9782
9783
9784
9785
9786
9787
9788
9789
9790
9791
9792
9793
9794
9795
9796
9797
9798
9799
9800
9801
9802
9803
9804
9805
9806
9807
9808
9809
9810
9811
9812
9813
9814
9815
9816
9817
9818
9819
9820
9821
9822
9823
9824
9825
9826
9827
9828
9829
9830
9831
9832
9833
9834
9835
9836
9837
9838
9839
9840
9841
9842
9843
9844
9845
9846
9847
9848
9849
9850
9851
9852
9853
9854
9855
9856
9857
9858
9859
9860
9861
9862
9863
9864
9865
9866
9867
9868
9869
9870
9871
9872
9873
9874
9875
9876
9877
9878
9879
9880
9881
9882
9883
9884
9885
9886
9887
9888
9889
9890
9891
9892
9893
9894
9895
9896
9897
9898
9899
9900
9901
9902
9903
9904
9905
9906
9907
9908
9909
9910
9911
9912
9913
9914
9915
9916
9917
9918
9919
9920
9921
9922
9923
9924
9925
9926
9927
9928
9929
9930
9931
9932
9933
9934
9935
9936
9937
9938
9939
9940
9941
9942
9943
9944
9945
9946
9947
9948
9949
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
9960
9961
9962
9963
9964
9965
9966
9967
9968
9969
9970
9971
9972
9973
9974
9975
9976
9977
9978
9979
9980
9981
9982
9983
9984
9985
9986
9987
9988
9989
9990
9991
9992
9993
9994
9995
9996
9997
9998
9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279
11280
11281
11282
11283
11284
11285
11286
11287
11288
11289
11290
11291
11292
11293
11294
11295
11296
11297
11298
11299
11300
11301
11302
11303
11304
11305
11306
11307
11308
11309
11310
11311
11312
11313
11314
11315
11316
11317
11318
11319
11320
11321
11322
11323
11324
11325
11326
11327
11328
11329
11330
11331
11332
11333
11334
11335
11336
11337
11338
11339
11340
11341
11342
11343
11344
11345
11346
11347
11348
11349
11350
11351
11352
11353
11354
11355
11356
11357
11358
11359
11360
11361
11362
11363
11364
11365
11366
11367
11368
11369
11370
11371
11372
11373
11374
11375
11376
11377
11378
11379
11380
11381
11382
11383
11384
11385
11386
11387
11388
11389
11390
11391
11392
11393
11394
11395
11396
11397
11398
11399
11400
11401
11402
11403
11404
11405
11406
11407
11408
11409
11410
11411
11412
11413
11414
11415
11416
11417
11418
11419
11420
11421
11422
11423
11424
11425
11426
11427
11428
11429
11430
11431
11432
11433
11434
11435
11436
11437
11438
11439
11440
11441
11442
11443
11444
11445
11446
11447
11448
11449
11450
11451
11452
11453
11454
11455
11456
11457
11458
11459
11460
11461
11462
11463
11464
11465
11466
11467
11468
11469
11470
11471
11472
11473
11474
11475
11476
11477
11478
11479
11480
11481
11482
11483
11484
11485
11486
11487
11488
11489
11490
11491
11492
11493
11494
11495
11496
11497
11498
11499
11500
11501
11502
11503
11504
11505
11506
11507
11508
11509
11510
11511
11512
11513
11514
11515
11516
11517
11518
11519
11520
11521
11522
11523
11524
11525
11526
11527
11528
11529
11530
11531
11532
11533
11534
11535
11536
11537
11538
11539
11540
11541
11542
11543
11544
11545
11546
11547
11548
11549
11550
11551
11552
11553
11554
11555
11556
11557
11558
11559
11560
11561
11562
11563
11564
11565
11566
11567
11568
11569
11570
11571
11572
11573
11574
11575
11576
11577
11578
11579
11580
11581
11582
11583
11584
11585
11586
11587
11588
11589
11590
11591
11592
11593
11594
11595
11596
11597
11598
11599
11600
11601
11602
11603
11604
11605
11606
11607
11608
11609
11610
11611
11612
11613
11614
11615
11616
11617
11618
11619
11620
11621
11622
11623
11624
11625
11626
11627
11628
11629
11630
11631
11632
11633
11634
11635
11636
11637
11638
11639
11640
11641
11642
11643
11644
11645
11646
11647
11648
11649
11650
11651
11652
11653
11654
11655
11656
11657
11658
11659
11660
11661
11662
11663
11664
11665
11666
11667
11668
11669
11670
11671
11672
11673
11674
11675
11676
11677
11678
11679
11680
11681
11682
11683
11684
11685
11686
11687
11688
11689
11690
11691
11692
11693
11694
11695
11696
11697
11698
11699
11700
11701
11702
11703
11704
11705
11706
11707
11708
11709
11710
11711
11712
11713
11714
11715
11716
11717
11718
11719
11720
11721
11722
11723
11724
11725
11726
11727
11728
11729
11730
11731
11732
11733
11734
11735
11736
11737
11738
11739
11740
11741
11742
11743
11744
11745
11746
11747
11748
11749
11750
11751
11752
11753
11754
11755
11756
11757
11758
11759
11760
11761
11762
11763
11764
11765
11766
11767
11768
11769
11770
11771
11772
11773
11774
11775
11776
11777
11778
11779
11780
11781
11782
11783
11784
11785
11786
11787
11788
11789
11790
11791
11792
11793
11794
11795
11796
11797
11798
11799
11800
11801
11802
11803
11804
11805
11806
11807
11808
11809
11810
11811
11812
11813
11814
11815
11816
11817
11818
11819
11820
11821
11822
11823
11824
11825
11826
11827
11828
11829
11830
11831
11832
11833
11834
11835
11836
11837
11838
11839
11840
11841
11842
11843
11844
11845
11846
11847
11848
11849
11850
11851
11852
11853
11854
11855
11856
11857
11858
11859
11860
11861
11862
11863
11864
11865
11866
11867
11868
11869
11870
11871
11872
11873
11874
11875
11876
11877
11878
11879
11880
11881
11882
11883
11884
11885
11886
11887
11888
11889
11890
11891
11892
11893
11894
11895
11896
11897
11898
11899
11900
11901
11902
11903
11904
11905
11906
11907
11908
11909
11910
11911
11912
11913
11914
11915
11916
11917
11918
11919
11920
11921
11922
11923
11924
11925
11926
11927
11928
11929
11930
11931
11932
11933
11934
11935
11936
11937
11938
11939
11940
11941
11942
11943
11944
11945
11946
11947
11948
11949
11950
11951
11952
11953
11954
11955
11956
11957
11958
11959
11960
11961
11962
11963
11964
11965
11966
11967
11968
11969
11970
11971
11972
11973
11974
11975
11976
11977
11978
11979
11980
11981
11982
11983
11984
11985
11986
11987
11988
11989
11990
11991
11992
11993
11994
11995
11996
11997
11998
11999
12000
12001
12002
12003
12004
12005
12006
12007
12008
12009
12010
12011
12012
12013
12014
12015
12016
12017
12018
12019
12020
12021
12022
12023
12024
12025
12026
12027
12028
12029
12030
12031
12032
12033
12034
12035
12036
12037
12038
12039
12040
12041
12042
12043
12044
12045
12046
12047
12048
12049
12050
12051
12052
12053
12054
12055
12056
12057
12058
12059
12060
12061
12062
12063
12064
12065
12066
12067
12068
12069
12070
12071
12072
12073
12074
12075
12076
12077
12078
12079
12080
12081
12082
12083
12084
12085
12086
12087
12088
12089
12090
12091
12092
12093
12094
12095
12096
12097
12098
12099
12100
12101
12102
12103
12104
12105
12106
12107
12108
12109
12110
12111
12112
12113
12114
12115
12116
12117
12118
12119
12120
12121
12122
12123
12124
12125
12126
12127
12128
12129
12130
12131
12132
12133
12134
12135
12136
12137
12138
12139
12140
12141
12142
12143
12144
12145
12146
12147
12148
12149
12150
12151
12152
12153
12154
12155
12156
12157
12158
12159
12160
12161
12162
12163
12164
12165
12166
12167
12168
12169
12170
12171
12172
12173
12174
12175
12176
12177
12178
12179
12180
12181
12182
12183
12184
12185
12186
12187
12188
12189
12190
12191
12192
12193
12194
12195
12196
12197
12198
12199
12200
12201
12202
12203
12204
12205
12206
12207
12208
12209
12210
12211
12212
12213
12214
12215
12216
12217
12218
12219
12220
12221
12222
12223
12224
12225
12226
12227
12228
12229
12230
12231
12232
12233
12234
12235
12236
12237
12238
12239
12240
12241
12242
12243
12244
12245
12246
12247
12248
12249
12250
12251
12252
12253
12254
12255
12256
12257
12258
12259
12260
12261
12262
12263
12264
12265
12266
12267
12268
12269
12270
12271
12272
12273
12274
12275
12276
12277
12278
12279
12280
12281
12282
12283
12284
12285
12286
12287
12288
12289
12290
12291
12292
12293
12294
12295
12296
12297
12298
12299
12300
12301
12302
12303
12304
12305
12306
12307
12308
12309
12310
12311
12312
12313
12314
12315
12316
12317
12318
12319
12320
12321
12322
12323
12324
12325
12326
12327
12328
12329
12330
12331
12332
12333
12334
12335
12336
12337
12338
12339
12340
12341
12342
12343
12344
12345
12346
12347
12348
12349
12350
12351
12352
12353
12354
12355
12356
12357
12358
12359
12360
12361
12362
12363
12364
12365
12366
12367
12368
12369
12370
12371
12372
12373
12374
12375
12376
12377
12378
12379
12380
12381
12382
12383
12384
12385
12386
12387
12388
12389
12390
12391
12392
12393
12394
12395
12396
12397
12398
12399
12400
12401
12402
12403
12404
12405
12406
12407
12408
12409
12410
12411
12412
12413
12414
12415
12416
12417
12418
12419
12420
12421
12422
12423
12424
12425
12426
12427
12428
12429
12430
12431
12432
12433
12434
12435
12436
12437
12438
12439
12440
12441
12442
12443
12444
12445
12446
12447
12448
12449
12450
12451
12452
12453
12454
12455
12456
12457
12458
12459
12460
12461
12462
12463
12464
12465
12466
12467
12468
12469
12470
12471
12472
12473
12474
12475
12476
12477
12478
12479
12480
12481
12482
12483
12484
12485
12486
12487
12488
12489
12490
12491
12492
12493
12494
12495
12496
12497
12498
12499
12500
12501
12502
12503
12504
12505
12506
12507
12508
12509
12510
12511
12512
12513
12514
12515
12516
12517
12518
12519
12520
12521
12522
12523
12524
12525
12526
12527
12528
12529
12530
12531
12532
12533
12534
12535
12536
12537
12538
12539
12540
12541
12542
12543
12544
12545
12546
12547
12548
12549
12550
12551
12552
12553
12554
12555
12556
12557
12558
12559
12560
12561
12562
12563
12564
12565
12566
12567
12568
12569
12570
12571
12572
12573
12574
12575
12576
12577
12578
12579
12580
12581
12582
12583
12584
12585
12586
12587
12588
12589
12590
12591
12592
12593
12594
12595
12596
12597
12598
12599
12600
12601
12602
12603
12604
12605
12606
12607
12608
12609
12610
12611
12612
12613
12614
12615
12616
12617
12618
12619
12620
12621
12622
12623
12624
12625
12626
12627
12628
12629
12630
12631
12632
12633
12634
12635
12636
12637
12638
12639
12640
12641
12642
12643
12644
12645
12646
12647
12648
12649
12650
12651
12652
12653
12654
12655
12656
12657
12658
12659
12660
12661
12662
12663
12664
12665
12666
12667
12668
12669
12670
12671
12672
12673
12674
12675
12676
12677
12678
12679
12680
12681
12682
12683
12684
12685
12686
12687
12688
12689
12690
12691
12692
12693
12694
12695
12696
12697
12698
12699
12700
12701
12702
12703
12704
12705
12706
12707
12708
12709
12710
12711
12712
12713
12714
12715
12716
12717
12718
12719
12720
12721
12722
12723
12724
12725
12726
12727
12728
12729
12730
12731
12732
12733
12734
12735
12736
12737
12738
12739
12740
12741
12742
12743
12744
12745
12746
12747
12748
12749
12750
12751
12752
12753
12754
12755
12756
12757
12758
12759
12760
12761
12762
12763
12764
12765
12766
12767
12768
12769
12770
12771
12772
12773
12774
12775
12776
12777
12778
12779
12780
12781
12782
12783
12784
12785
12786
12787
12788
12789
12790
12791
12792
12793
12794
12795
12796
12797
12798
12799
12800
12801
12802
12803
12804
12805
12806
12807
12808
12809
12810
12811
12812
12813
12814
12815
12816
12817
12818
12819
12820
12821
12822
12823
12824
12825
12826
12827
12828
12829
12830
12831
12832
12833
12834
12835
12836
12837
12838
12839
12840
12841
12842
12843
12844
12845
12846
12847
12848
12849
12850
12851
12852
12853
12854
12855
12856
12857
12858
12859
12860
12861
12862
12863
12864
12865
12866
12867
12868
12869
12870
12871
12872
12873
12874
12875
12876
12877
12878
12879
12880
12881
12882
12883
12884
12885
12886
12887
12888
12889
12890
12891
12892
12893
12894
12895
12896
12897
12898
12899
12900
12901
12902
12903
12904
12905
12906
12907
12908
12909
12910
12911
12912
12913
12914
12915
12916
12917
12918
12919
12920
12921
12922
12923
12924
12925
12926
12927
12928
12929
12930
12931
12932
12933
12934
12935
12936
12937
12938
12939
12940
12941
12942
12943
12944
12945
12946
12947
12948
12949
12950
12951
12952
12953
12954
12955
12956
12957
12958
12959
12960
12961
12962
12963
12964
12965
12966
12967
12968
12969
12970
12971
12972
12973
12974
12975
12976
12977
12978
12979
12980
12981
12982
12983
12984
12985
12986
12987
12988
12989
12990
12991
12992
12993
12994
12995
12996
12997
12998
12999
13000
13001
13002
13003
13004
13005
13006
13007
13008
13009
13010
13011
13012
13013
13014
13015
13016
13017
13018
13019
13020
13021
13022
13023
13024
13025
13026
13027
13028
13029
13030
13031
13032
13033
13034
13035
13036
13037
13038
13039
13040
13041
13042
13043
13044
13045
13046
13047
13048
13049
13050
13051
13052
13053
13054
13055
13056
13057
13058
13059
13060
13061
13062
13063
13064
13065
13066
13067
13068
13069
13070
13071
13072
13073
13074
13075
13076
13077
13078
13079
13080
13081
13082
13083
13084
13085
13086
13087
13088
13089
13090
13091
13092
13093
13094
13095
13096
13097
13098
13099
13100
13101
13102
13103
13104
13105
13106
13107
13108
13109
13110
13111
13112
13113
13114
13115
13116
13117
13118
13119
13120
13121
13122
13123
13124
13125
13126
13127
13128
13129
13130
13131
13132
13133
13134
13135
13136
13137
13138
13139
13140
13141
13142
13143
13144
13145
13146
13147
13148
13149
13150
13151
13152
13153
13154
13155
13156
13157
13158
13159
13160
13161
13162
13163
13164
13165
13166
13167
13168
13169
13170
13171
13172
13173
13174
13175
13176
13177
13178
13179
13180
13181
13182
13183
13184
13185
13186
13187
13188
13189
13190
13191
13192
13193
13194
13195
13196
13197
13198
13199
13200
13201
13202
13203
13204
13205
13206
13207
13208
13209
13210
13211
13212
13213
13214
13215
13216
13217
13218
13219
13220
13221
13222
13223
13224
13225
13226
13227
13228
13229
13230
13231
13232
13233
13234
13235
13236
13237
13238
13239
13240
13241
13242
13243
13244
13245
13246
13247
13248
13249
13250
13251
13252
13253
13254
13255
13256
13257
13258
13259
13260
13261
13262
13263
13264
13265
13266
13267
13268
13269
13270
13271
13272
13273
13274
13275
13276
13277
13278
13279
13280
13281
13282
13283
13284
13285
13286
13287
13288
13289
13290
13291
13292
13293
13294
13295
13296
13297
13298
13299
13300
13301
13302
13303
13304
13305
13306
13307
13308
13309
13310
13311
13312
13313
13314
13315
13316
13317
13318
13319
13320
13321
13322
13323
13324
13325
13326
13327
13328
13329
13330
13331
13332
13333
13334
13335
13336
13337
13338
13339
13340
13341
13342
13343
13344
13345
13346
13347
13348
13349
13350
13351
13352
13353
13354
13355
13356
13357
13358
13359
13360
13361
13362
13363
13364
13365
13366
13367
13368
13369
13370
13371
13372
13373
13374
13375
13376
13377
13378
13379
13380
13381
13382
13383
13384
13385
13386
13387
13388
13389
13390
13391
13392
13393
13394
13395
13396
13397
13398
13399
13400
13401
13402
13403
13404
13405
13406
13407
13408
13409
13410
13411
13412
13413
13414
13415
13416
13417
13418
13419
13420
13421
13422
13423
13424
13425
13426
13427
13428
13429
13430
13431
13432
13433
13434
13435
13436
13437
13438
13439
13440
13441
13442
13443
13444
13445
13446
13447
13448
13449
13450
13451
13452
13453
13454
13455
13456
13457
13458
13459
13460
13461
13462
13463
13464
13465
13466
13467
13468
13469
13470
13471
13472
13473
13474
13475
13476
13477
13478
13479
13480
13481
13482
13483
13484
13485
13486
13487
13488
13489
13490
13491
13492
13493
13494
13495
13496
13497
13498
13499
13500
13501
13502
13503
13504
13505
13506
13507
13508
13509
13510
13511
13512
13513
13514
13515
13516
13517
13518
13519
13520
13521
13522
13523
13524
13525
13526
13527
13528
13529
13530
13531
13532
13533
13534
13535
13536
13537
13538
13539
13540
13541
13542
13543
13544
13545
13546
13547
13548
13549
13550
13551
13552
13553
13554
13555
13556
13557
13558
13559
13560
13561
13562
13563
13564
13565
13566
13567
13568
13569
13570
13571
13572
13573
13574
13575
13576
13577
13578
13579
13580
13581
13582
13583
13584
13585
13586
13587
13588
13589
13590
13591
13592
13593
13594
13595
13596
13597
13598
13599
13600
13601
13602
13603
13604
13605
13606
13607
13608
13609
13610
13611
13612
13613
13614
13615
13616
13617
13618
13619
13620
13621
13622
13623
13624
13625
13626
13627
13628
13629
13630
13631
13632
13633
13634
13635
13636
13637
13638
13639
13640
13641
13642
13643
13644
13645
13646
13647
13648
13649
13650
13651
13652
13653
13654
13655
13656
13657
13658
13659
13660
13661
13662
13663
13664
13665
13666
13667
13668
13669
13670
13671
13672
13673
13674
13675
13676
13677
13678
13679
13680
13681
13682
13683
13684
13685
13686
13687
13688
13689
13690
13691
13692
13693
13694
13695
13696
13697
13698
13699
13700
13701
13702
13703
13704
13705
13706
13707
13708
13709
13710
13711
13712
13713
13714
13715
13716
13717
13718
13719
13720
13721
13722
13723
13724
13725
13726
13727
13728
13729
13730
13731
13732
13733
13734
13735
13736
13737
13738
13739
13740
13741
13742
13743
13744
13745
13746
13747
13748
13749
13750
13751
13752
13753
13754
13755
13756
13757
13758
13759
13760
13761
13762
13763
13764
13765
13766
13767
13768
13769
13770
13771
13772
13773
13774
13775
13776
13777
13778
13779
13780
13781
13782
13783
13784
13785
13786
13787
13788
13789
13790
13791
13792
13793
13794
13795
13796
13797
13798
13799
13800
13801
13802
13803
13804
13805
13806
13807
13808
13809
13810
13811
13812
13813
13814
13815
13816
13817
13818
13819
13820
13821
13822
13823
13824
13825
13826
13827
13828
13829
13830
13831
13832
13833
13834
13835
13836
13837
13838
13839
13840
13841
13842
13843
13844
13845
13846
13847
13848
13849
13850
13851
13852
13853
13854
13855
13856
13857
13858
13859
13860
13861
13862
13863
13864
13865
13866
13867
13868
13869
13870
13871
13872
13873
13874
13875
13876
13877
13878
13879
13880
13881
13882
13883
13884
13885
13886
13887
13888
13889
13890
13891
13892
13893
13894
13895
13896
13897
13898
13899
13900
13901
13902
13903
13904
13905
13906
13907
13908
13909
13910
13911
13912
13913
13914
13915
13916
13917
13918
13919
13920
13921
13922
13923
13924
13925
13926
13927
13928
13929
13930
13931
13932
13933
13934
13935
13936
13937
13938
13939
13940
13941
13942
13943
13944
13945
13946
13947
13948
13949
13950
13951
13952
13953
13954
13955
13956
13957
13958
13959
13960
13961
13962
13963
13964
13965
13966
13967
13968
13969
13970
13971
13972
13973
13974
13975
13976
13977
13978
13979
13980
13981
13982
13983
13984
13985
13986
13987
13988
13989
13990
13991
13992
13993
13994
13995
13996
13997
13998
13999
14000
14001
14002
14003
14004
14005
14006
14007
14008
14009
14010
14011
14012
14013
14014
14015
14016
14017
14018
14019
14020
14021
14022
14023
14024
14025
14026
14027
14028
14029
14030
14031
14032
14033
14034
14035
14036
14037
14038
14039
14040
14041
14042
14043
14044
14045
14046
14047
14048
14049
14050
14051
14052
14053
14054
14055
14056
14057
14058
14059
14060
14061
14062
14063
14064
14065
14066
14067
14068
14069
14070
14071
14072
14073
14074
14075
14076
14077
14078
14079
14080
14081
14082
14083
14084
14085
14086
14087
14088
14089
14090
14091
14092
14093
14094
14095
14096
14097
14098
14099
14100
14101
14102
14103
14104
14105
14106
14107
14108
14109
14110
14111
14112
14113
14114
14115
14116
14117
14118
14119
14120
14121
14122
14123
14124
14125
14126
14127
14128
14129
14130
14131
14132
14133
14134
14135
14136
14137
14138
14139
14140
14141
14142
14143
14144
14145
14146
14147
14148
14149
14150
14151
14152
14153
14154
14155
14156
14157
14158
14159
14160
14161
14162
14163
14164
14165
14166
14167
14168
14169
14170
14171
14172
14173
14174
14175
14176
14177
14178
14179
14180
14181
14182
14183
14184
14185
14186
14187
14188
14189
14190
14191
14192
14193
14194
14195
14196
14197
14198
14199
14200
14201
14202
14203
14204
14205
14206
14207
14208
14209
14210
14211
14212
14213
14214
14215
14216
14217
14218
14219
14220
14221
14222
14223
14224
14225
14226
14227
14228
14229
14230
14231
14232
14233
14234
14235
14236
14237
14238
14239
14240
14241
14242
14243
14244
14245
14246
14247
14248
14249
14250
14251
14252
14253
14254
14255
14256
14257
14258
14259
14260
14261
14262
14263
14264
14265
14266
14267
14268
14269
14270
14271
14272
14273
14274
14275
14276
14277
14278
14279
14280
14281
14282
14283
14284
14285
14286
14287
14288
14289
14290
14291
14292
14293
14294
14295
14296
14297
14298
14299
14300
14301
14302
14303
14304
14305
14306
14307
14308
14309
14310
14311
14312
14313
14314
14315
14316
14317
14318
14319
14320
14321
14322
14323
14324
14325
14326
14327
14328
14329
14330
14331
14332
14333
14334
14335
14336
14337
14338
14339
14340
14341
14342
14343
14344
14345
14346
14347
14348
14349
14350
14351
14352
14353
14354
14355
14356
14357
14358
14359
14360
14361
14362
14363
14364
14365
14366
14367
14368
14369
14370
14371
14372
14373
14374
14375
14376
14377
14378
14379
14380
14381
14382
14383
14384
14385
14386
14387
14388
14389
14390
14391
14392
14393
14394
14395
14396
14397
14398
14399
14400
14401
14402
14403
14404
14405
14406
14407
14408
14409
14410
14411
14412
14413
14414
14415
14416
14417
14418
14419
14420
14421
14422
14423
14424
14425
14426
14427
14428
14429
14430
14431
14432
14433
14434
14435
14436
14437
14438
14439
14440
14441
14442
14443
14444
14445
14446
14447
14448
14449
14450
14451
14452
14453
14454
14455
14456
14457
14458
14459
14460
14461
14462
14463
14464
14465
14466
14467
14468
14469
14470
14471
14472
14473
14474
14475
14476
14477
14478
14479
14480
14481
14482
14483
14484
14485
14486
14487
14488
14489
14490
14491
14492
14493
14494
14495
14496
14497
14498
14499
14500
14501
14502
14503
14504
14505
14506
14507
14508
14509
14510
14511
14512
14513
14514
14515
14516
14517
14518
14519
14520
14521
14522
14523
14524
14525
14526
14527
14528
14529
14530
14531
14532
14533
14534
14535
14536
14537
14538
14539
14540
14541
14542
14543
14544
14545
14546
14547
14548
14549
14550
14551
14552
14553
14554
14555
14556
14557
14558
14559
14560
14561
14562
14563
14564
14565
14566
14567
14568
14569
14570
14571
14572
14573
14574
14575
14576
14577
14578
14579
14580
14581
14582
14583
14584
14585
14586
14587
14588
14589
14590
14591
14592
14593
14594
14595
14596
14597
14598
14599
14600
14601
14602
14603
14604
14605
14606
14607
14608
14609
14610
14611
14612
14613
14614
14615
14616
14617
14618
14619
14620
14621
14622
14623
14624
14625
14626
14627
14628
14629
14630
14631
14632
14633
14634
14635
14636
14637
14638
14639
14640
14641
14642
14643
14644
14645
14646
14647
14648
14649
14650
14651
14652
14653
14654
14655
14656
14657
14658
14659
14660
14661
14662
14663
14664
14665
14666
14667
14668
14669
14670
14671
14672
14673
14674
14675
14676
14677
14678
14679
14680
14681
14682
14683
14684
14685
14686
14687
14688
14689
14690
14691
14692
14693
14694
14695
14696
14697
14698
14699
14700
14701
14702
14703
14704
14705
14706
14707
14708
14709
14710
14711
14712
14713
14714
14715
14716
14717
14718
14719
14720
14721
14722
14723
14724
14725
14726
14727
14728
14729
14730
14731
14732
14733
14734
14735
14736
14737
14738
14739
14740
14741
14742
14743
14744
14745
14746
14747
14748
14749
14750
14751
14752
14753
14754
14755
14756
14757
14758
14759
14760
14761
14762
14763
14764
14765
14766
14767
14768
14769
14770
14771
14772
14773
14774
14775
14776
14777
14778
14779
14780
14781
14782
14783
14784
14785
14786
14787
14788
14789
14790
14791
14792
14793
14794
14795
14796
14797
14798
14799
14800
14801
14802
14803
14804
14805
14806
14807
14808
14809
14810
14811
14812
14813
14814
14815
14816
14817
14818
14819
14820
14821
14822
14823
14824
14825
14826
14827
14828
14829
14830
14831
14832
14833
14834
14835
14836
14837
14838
14839
14840
14841
14842
14843
14844
14845
14846
14847
14848
14849
14850
14851
14852
14853
14854
14855
14856
14857
14858
14859
14860
14861
14862
14863
14864
14865
14866
14867
14868
14869
14870
14871
14872
14873
14874
14875
14876
14877
14878
14879
14880
14881
14882
14883
14884
14885
14886
14887
14888
14889
14890
14891
14892
14893
14894
14895
14896
14897
14898
14899
14900
14901
14902
14903
14904
14905
14906
14907
14908
14909
14910
14911
14912
14913
14914
14915
14916
14917
14918
14919
14920
14921
14922
14923
14924
14925
14926
14927
14928
14929
14930
14931
14932
14933
14934
14935
14936
14937
14938
14939
14940
14941
14942
14943
14944
14945
14946
14947
14948
14949
14950
14951
14952
14953
14954
14955
14956
14957
14958
14959
14960
14961
14962
14963
14964
14965
14966
14967
14968
14969
14970
14971
14972
14973
14974
14975
14976
14977
14978
14979
14980
14981
14982
14983
14984
14985
14986
14987
14988
14989
14990
14991
14992
14993
14994
14995
14996
14997
14998
14999
15000
15001
15002
15003
15004
15005
15006
15007
15008
15009
15010
15011
15012
15013
15014
15015
15016
15017
15018
15019
15020
15021
15022
15023
15024
15025
15026
15027
15028
15029
15030
15031
15032
15033
15034
15035
15036
15037
15038
15039
15040
15041
15042
15043
15044
15045
15046
15047
15048
15049
15050
15051
15052
15053
15054
15055
15056
15057
15058
15059
15060
15061
15062
15063
15064
15065
15066
15067
15068
15069
15070
15071
15072
15073
15074
15075
15076
15077
15078
15079
15080
15081
15082
15083
15084
15085
15086
15087
15088
15089
15090
15091
15092
15093
15094
15095
15096
15097
15098
15099
15100
15101
15102
15103
15104
15105
15106
15107
15108
15109
15110
15111
15112
15113
15114
15115
15116
15117
15118
15119
15120
15121
15122
15123
15124
15125
15126
15127
15128
15129
15130
15131
15132
15133
15134
15135
15136
15137
15138
15139
15140
15141
15142
15143
15144
15145
15146
15147
15148
15149
15150
15151
15152
15153
15154
15155
15156
15157
15158
15159
15160
15161
15162
15163
15164
15165
15166
15167
15168
15169
15170
15171
15172
15173
15174
15175
15176
15177
15178
15179
15180
15181
15182
15183
15184
15185
15186
15187
15188
15189
15190
15191
15192
15193
15194
15195
15196
15197
15198
15199
15200
15201
15202
15203
15204
15205
15206
15207
15208
15209
15210
15211
15212
15213
15214
15215
15216
15217
15218
15219
15220
15221
15222
15223
15224
15225
15226
15227
15228
15229
15230
15231
15232
15233
15234
15235
15236
15237
15238
15239
15240
15241
15242
15243
15244
15245
15246
15247
15248
15249
15250
15251
15252
15253
15254
15255
15256
15257
15258
15259
15260
15261
15262
15263
15264
15265
15266
15267
15268
15269
15270
15271
15272
15273
15274
15275
15276
15277
15278
15279
15280
15281
15282
15283
15284
15285
15286
15287
15288
15289
15290
15291
15292
15293
15294
15295
15296
15297
15298
15299
15300
15301
15302
15303
15304
15305
15306
15307
15308
15309
15310
15311
15312
15313
15314
15315
15316
15317
15318
15319
15320
15321
15322
15323
15324
15325
15326
15327
15328
15329
15330
15331
15332
15333
15334
15335
15336
15337
15338
15339
15340
15341
15342
15343
15344
15345
15346
15347
15348
15349
15350
15351
15352
15353
15354
15355
15356
15357
15358
15359
15360
15361
15362
15363
15364
15365
15366
15367
15368
15369
15370
15371
15372
15373
15374
15375
15376
15377
15378
15379
15380
15381
15382
15383
15384
15385
15386
15387
15388
15389
15390
15391
15392
15393
15394
15395
15396
15397
15398
15399
15400
15401
15402
15403
15404
15405
15406
15407
15408
15409
15410
15411
15412
15413
15414
15415
15416
15417
15418
15419
15420
15421
15422
15423
15424
15425
15426
15427
15428
15429
15430
15431
15432
15433
15434
15435
15436
15437
15438
15439
15440
15441
15442
15443
15444
15445
15446
15447
15448
15449
15450
15451
15452
15453
15454
15455
15456
15457
15458
15459
15460
15461
15462
15463
15464
15465
15466
15467
15468
15469
15470
15471
15472
15473
15474
15475
15476
15477
15478
15479
15480
15481
15482
15483
15484
15485
15486
15487
15488
15489
15490
15491
15492
15493
15494
15495
15496
15497
15498
15499
15500
15501
15502
15503
15504
15505
15506
15507
15508
15509
15510
15511
15512
15513
15514
15515
15516
15517
15518
15519
15520
15521
15522
15523
15524
15525
15526
15527
15528
15529
15530
15531
15532
15533
15534
15535
15536
15537
15538
15539
15540
15541
15542
15543
15544
15545
15546
15547
15548
15549
15550
15551
15552
15553
15554
15555
15556
15557
15558
15559
15560
15561
15562
15563
15564
15565
15566
15567
15568
15569
15570
15571
15572
15573
15574
15575
15576
15577
15578
15579
15580
15581
15582
15583
15584
15585
15586
15587
15588
15589
15590
15591
15592
15593
15594
15595
15596
15597
15598
15599
15600
15601
15602
15603
15604
15605
15606
15607
15608
15609
15610
15611
15612
15613
15614
15615
15616
15617
15618
15619
15620
15621
15622
15623
15624
15625
15626
15627
15628
15629
15630
15631
15632
15633
15634
15635
15636
15637
15638
15639
15640
15641
15642
15643
15644
15645
15646
15647
15648
15649
15650
15651
15652
15653
15654
15655
15656
15657
15658
15659
15660
15661
15662
15663
15664
15665
15666
15667
15668
15669
15670
15671
15672
15673
15674
15675
15676
15677
15678
15679
15680
15681
15682
15683
15684
15685
15686
15687
15688
15689
15690
15691
15692
15693
15694
15695
15696
15697
15698
15699
15700
15701
15702
15703
15704
15705
15706
15707
15708
15709
15710
15711
15712
15713
15714
15715
15716
15717
15718
15719
15720
15721
15722
15723
15724
15725
15726
15727
15728
15729
15730
15731
15732
15733
15734
15735
15736
15737
15738
15739
15740
15741
15742
15743
15744
15745
15746
15747
15748
15749
15750
15751
15752
15753
15754
15755
15756
15757
15758
15759
15760
15761
15762
15763
15764
15765
15766
15767
15768
15769
15770
15771
15772
15773
15774
15775
15776
15777
15778
15779
15780
15781
15782
15783
15784
15785
15786
15787
15788
15789
15790
15791
15792
15793
15794
15795
15796
15797
15798
15799
15800
15801
15802
15803
15804
15805
15806
15807
15808
15809
15810
15811
15812
15813
15814
15815
15816
15817
15818
15819
15820
15821
15822
15823
15824
15825
15826
15827
15828
15829
15830
15831
15832
15833
15834
15835
15836
15837
15838
15839
15840
15841
15842
15843
15844
15845
15846
15847
15848
15849
15850
15851
15852
15853
15854
15855
15856
15857
15858
15859
15860
15861
15862
15863
15864
15865
15866
15867
15868
15869
15870
15871
15872
15873
15874
15875
15876
15877
15878
15879
15880
15881
15882
15883
15884
15885
15886
15887
15888
15889
15890
15891
15892
15893
15894
15895
15896
15897
15898
15899
15900
15901
15902
15903
15904
15905
15906
15907
15908
15909
15910
15911
15912
15913
15914
15915
15916
15917
15918
15919
15920
15921
15922
15923
15924
15925
15926
15927
15928
15929
15930
15931
15932
15933
15934
15935
15936
15937
15938
15939
15940
15941
15942
15943
15944
15945
15946
15947
15948
15949
15950
15951
15952
15953
15954
15955
15956
15957
15958
15959
15960
15961
15962
15963
15964
15965
15966
15967
15968
15969
15970
15971
15972
15973
15974
15975
15976
15977
15978
15979
15980
15981
15982
15983
15984
15985
15986
15987
15988
15989
15990
15991
15992
15993
15994
15995
15996
15997
15998
15999
16000
16001
16002
16003
16004
16005
16006
16007
16008
16009
16010
16011
16012
16013
16014
16015
16016
16017
16018
16019
16020
16021
16022
16023
16024
16025
16026
16027
16028
16029
16030
16031
16032
16033
16034
16035
16036
16037
16038
16039
16040
16041
16042
16043
16044
16045
16046
16047
16048
16049
16050
16051
16052
16053
16054
16055
16056
16057
16058
16059
16060
16061
16062
16063
16064
16065
16066
16067
16068
16069
16070
16071
16072
16073
16074
16075
16076
16077
16078
16079
16080
16081
16082
16083
16084
16085
16086
16087
16088
16089
16090
16091
16092
16093
16094
16095
16096
16097
16098
16099
16100
16101
16102
16103
16104
16105
16106
16107
16108
16109
16110
16111
16112
16113
16114
16115
16116
16117
16118
16119
16120
16121
16122
16123
16124
16125
16126
16127
16128
16129
16130
16131
16132
16133
16134
16135
16136
16137
16138
16139
16140
16141
16142
16143
16144
16145
16146
16147
16148
16149
16150
16151
16152
16153
16154
16155
16156
16157
16158
16159
16160
16161
16162
16163
16164
16165
16166
16167
16168
16169
16170
16171
16172
16173
16174
16175
16176
16177
16178
16179
16180
16181
16182
16183
16184
16185
16186
16187
16188
16189
16190
16191
16192
16193
16194
16195
16196
16197
16198
16199
16200
16201
16202
16203
16204
16205
16206
16207
16208
16209
16210
16211
16212
16213
16214
16215
16216
16217
16218
16219
16220
16221
16222
16223
16224
16225
16226
16227
16228
16229
16230
16231
16232
16233
16234
16235
16236
16237
16238
16239
16240
16241
16242
16243
16244
16245
16246
16247
16248
16249
16250
16251
16252
16253
16254
16255
16256
16257
16258
16259
16260
16261
16262
16263
16264
16265
16266
16267
16268
16269
16270
16271
16272
16273
16274
16275
16276
16277
16278
16279
16280
16281
16282
16283
16284
16285
16286
16287
16288
16289
16290
16291
16292
16293
16294
16295
16296
16297
16298
16299
16300
16301
16302
16303
16304
16305
16306
16307
16308
16309
16310
16311
16312
16313
16314
16315
16316
16317
16318
16319
16320
16321
16322
16323
16324
16325
16326
16327
16328
16329
16330
16331
16332
16333
16334
16335
16336
16337
16338
16339
16340
16341
16342
16343
16344
16345
16346
16347
16348
16349
16350
16351
16352
16353
16354
16355
16356
16357
16358
16359
16360
16361
16362
16363
16364
16365
16366
16367
16368
16369
16370
16371
16372
16373
16374
16375
16376
16377
16378
16379
16380
16381
16382
16383
16384
16385
16386
16387
16388
16389
16390
16391
16392
16393
16394
16395
16396
16397
16398
16399
16400
16401
16402
16403
16404
16405
16406
16407
16408
16409
16410
16411
16412
16413
16414
16415
16416
16417
16418
16419
16420
16421
16422
16423
16424
16425
16426
16427
16428
16429
16430
16431
16432
16433
16434
16435
16436
16437
16438
16439
16440
16441
16442
16443
16444
16445
16446
16447
16448
16449
16450
16451
16452
16453
16454
16455
16456
16457
16458
16459
16460
16461
16462
16463
16464
16465
16466
16467
16468
16469
16470
16471
16472
16473
16474
16475
16476
16477
16478
16479
16480
16481
16482
16483
16484
16485
16486
16487
16488
16489
16490
16491
16492
16493
16494
16495
16496
16497
16498
16499
16500
16501
16502
16503
16504
16505
16506
16507
16508
16509
16510
16511
16512
16513
16514
16515
16516
16517
16518
16519
16520
16521
16522
16523
16524
16525
16526
16527
16528
16529
16530
16531
16532
16533
16534
16535
16536
16537
16538
16539
16540
16541
16542
16543
16544
16545
16546
16547
16548
16549
16550
16551
16552
16553
16554
16555
16556
16557
16558
16559
16560
16561
16562
16563
16564
16565
16566
16567
16568
16569
16570
16571
16572
16573
16574
16575
16576
16577
16578
16579
16580
16581
16582
16583
16584
16585
16586
16587
16588
16589
16590
16591
16592
16593
16594
16595
16596
16597
16598
16599
16600
16601
16602
16603
16604
16605
16606
16607
16608
16609
16610
16611
16612
16613
16614
16615
16616
16617
16618
16619
16620
16621
16622
16623
16624
16625
16626
16627
16628
16629
16630
16631
16632
16633
16634
16635
16636
16637
16638
16639
16640
16641
16642
16643
16644
16645
16646
16647
16648
16649
16650
16651
16652
16653
16654
16655
16656
16657
16658
16659
16660
16661
16662
16663
16664
16665
16666
16667
16668
16669
16670
16671
16672
16673
16674
16675
16676
16677
16678
16679
16680
16681
16682
16683
16684
16685
16686
16687
16688
16689
16690
16691
16692
16693
16694
16695
16696
16697
16698
16699
16700
16701
16702
16703
16704
16705
16706
16707
16708
16709
16710
16711
16712
16713
16714
16715
16716
16717
16718
16719
16720
16721
16722
16723
16724
16725
16726
16727
16728
16729
16730
16731
16732
16733
16734
16735
16736
16737
16738
16739
16740
16741
16742
16743
16744
16745
16746
16747
16748
16749
16750
16751
16752
16753
16754
16755
16756
16757
16758
16759
16760
16761
16762
16763
16764
16765
16766
16767
16768
16769
16770
16771
16772
16773
16774
16775
16776
16777
16778
16779
16780
16781
16782
16783
16784
16785
16786
16787
16788
16789
16790
16791
16792
16793
16794
16795
16796
16797
16798
16799
16800
16801
16802
16803
16804
16805
16806
16807
16808
16809
16810
16811
16812
16813
16814
16815
16816
16817
16818
16819
16820
16821
16822
16823
16824
16825
16826
16827
16828
16829
16830
16831
16832
16833
16834
16835
16836
16837
16838
16839
16840
16841
16842
16843
16844
16845
16846
16847
16848
16849
16850
16851
16852
16853
16854
16855
16856
16857
16858
16859
16860
16861
16862
16863
16864
16865
16866
16867
16868
16869
16870
16871
16872
16873
16874
16875
16876
16877
16878
16879
16880
16881
16882
16883
16884
16885
16886
16887
16888
16889
16890
16891
16892
16893
16894
16895
16896
16897
16898
16899
16900
16901
16902
16903
16904
16905
16906
16907
16908
16909
16910
16911
16912
16913
16914
16915
16916
16917
16918
16919
16920
16921
16922
16923
16924
16925
16926
16927
16928
16929
16930
16931
16932
16933
16934
16935
16936
16937
16938
16939
16940
16941
16942
16943
16944
16945
16946
16947
16948
16949
16950
16951
16952
16953
16954
16955
16956
16957
16958
16959
16960
16961
16962
16963
16964
16965
16966
16967
16968
16969
16970
16971
16972
16973
16974
16975
16976
16977
16978
16979
16980
16981
16982
16983
16984
16985
16986
16987
16988
16989
16990
16991
16992
16993
16994
16995
16996
16997
16998
16999
17000
17001
17002
17003
17004
17005
17006
17007
17008
17009
17010
17011
17012
17013
17014
17015
17016
17017
17018
17019
17020
17021
17022
17023
17024
17025
17026
17027
17028
17029
17030
17031
17032
17033
17034
17035
17036
17037
17038
17039
17040
17041
17042
17043
17044
17045
17046
17047
17048
17049
17050
17051
17052
17053
17054
17055
17056
17057
17058
17059
17060
17061
17062
17063
17064
17065
17066
17067
17068
17069
17070
17071
17072
17073
17074
17075
17076
17077
17078
17079
17080
17081
17082
17083
17084
17085
17086
17087
17088
17089
17090
17091
17092
17093
17094
17095
17096
17097
17098
17099
17100
17101
17102
17103
17104
17105
17106
17107
17108
17109
17110
17111
17112
17113
17114
17115
17116
17117
17118
17119
17120
17121
17122
17123
17124
17125
17126
17127
17128
17129
17130
17131
17132
17133
17134
17135
17136
17137
17138
17139
17140
17141
17142
17143
17144
17145
17146
17147
17148
17149
17150
17151
17152
17153
17154
17155
17156
17157
17158
17159
17160
17161
17162
17163
17164
17165
17166
17167
17168
17169
17170
17171
17172
17173
17174
17175
17176
17177
17178
17179
17180
17181
17182
17183
17184
17185
17186
17187
17188
17189
17190
17191
17192
17193
17194
17195
17196
17197
17198
17199
17200
17201
17202
17203
17204
17205
17206
17207
17208
17209
17210
17211
17212
17213
17214
17215
17216
17217
17218
17219
17220
17221
17222
17223
17224
17225
17226
17227
17228
17229
17230
17231
17232
17233
17234
17235
17236
17237
17238
17239
17240
17241
17242
17243
17244
17245
17246
17247
17248
17249
17250
17251
17252
17253
17254
17255
17256
17257
17258
17259
17260
17261
17262
17263
17264
17265
17266
17267
17268
17269
17270
17271
17272
17273
17274
17275
17276
17277
17278
17279
17280
17281
17282
17283
17284
17285
17286
17287
17288
17289
17290
17291
17292
17293
17294
17295
17296
17297
17298
17299
17300
17301
17302
17303
17304
17305
17306
17307
17308
17309
17310
17311
17312
17313
17314
17315
17316
17317
17318
17319
17320
17321
17322
17323
17324
17325
17326
17327
17328
17329
17330
17331
17332
17333
17334
17335
17336
17337
17338
17339
17340
17341
17342
17343
17344
17345
17346
17347
17348
17349
17350
17351
17352
17353
17354
17355
17356
17357
17358
17359
17360
17361
17362
17363
17364
17365
17366
17367
17368
17369
17370
17371
17372
17373
17374
17375
17376
17377
17378
17379
17380
17381
17382
17383
17384
17385
17386
17387
17388
17389
17390
17391
17392
17393
17394
17395
17396
17397
17398
17399
17400
17401
17402
17403
17404
17405
17406
17407
17408
17409
17410
17411
17412
17413
17414
17415
17416
17417
17418
17419
17420
17421
17422
17423
17424
17425
17426
17427
17428
17429
17430
17431
17432
17433
17434
17435
17436
17437
17438
17439
17440
17441
17442
17443
17444
17445
17446
17447
17448
17449
17450
17451
17452
17453
17454
17455
17456
17457
17458
17459
17460
17461
17462
17463
17464
17465
17466
17467
17468
17469
17470
17471
17472
17473
17474
17475
17476
17477
17478
17479
17480
17481
17482
17483
17484
17485
17486
17487
17488
17489
17490
17491
17492
17493
17494
17495
17496
17497
17498
17499
17500
17501
17502
17503
17504
17505
17506
17507
17508
17509
17510
17511
17512
17513
17514
17515
17516
17517
17518
17519
17520
17521
17522
17523
17524
17525
17526
17527
17528
17529
17530
17531
17532
17533
17534
17535
17536
17537
17538
17539
17540
17541
17542
17543
17544
17545
17546
17547
17548
17549
17550
17551
17552
17553
17554
17555
17556
17557
17558
17559
17560
17561
17562
17563
17564
17565
17566
17567
17568
17569
17570
17571
17572
17573
17574
17575
17576
17577
17578
17579
17580
17581
17582
17583
17584
17585
17586
17587
17588
17589
17590
17591
17592
17593
17594
17595
17596
17597
17598
17599
17600
17601
17602
17603
17604
17605
17606
17607
17608
17609
17610
17611
17612
17613
17614
17615
17616
17617
17618
17619
17620
17621
17622
17623
17624
17625
17626
17627
17628
17629
17630
17631
17632
17633
17634
17635
17636
17637
17638
17639
17640
17641
17642
17643
17644
17645
17646
17647
17648
17649
17650
17651
17652
17653
17654
17655
17656
17657
17658
17659
17660
17661
17662
17663
17664
17665
17666
17667
17668
17669
17670
17671
17672
17673
17674
17675
17676
17677
17678
17679
17680
17681
17682
17683
17684
17685
17686
17687
17688
17689
17690
17691
17692
17693
17694
17695
17696
17697
17698
17699
17700
17701
17702
17703
17704
17705
17706
17707
17708
17709
17710
17711
17712
17713
17714
17715
17716
17717
17718
17719
17720
17721
17722
17723
17724
17725
17726
17727
17728
17729
17730
17731
17732
17733
17734
17735
17736
17737
17738
17739
17740
17741
17742
17743
17744
17745
17746
17747
17748
17749
17750
17751
17752
17753
17754
17755
17756
17757
17758
17759
17760
17761
17762
17763
17764
17765
17766
17767
17768
17769
17770
17771
17772
17773
17774
17775
17776
17777
17778
17779
17780
17781
17782
17783
17784
17785
17786
17787
17788
17789
17790
17791
17792
17793
17794
17795
17796
17797
17798
17799
17800
17801
17802
17803
17804
17805
17806
17807
17808
17809
17810
17811
17812
17813
17814
17815
17816
17817
17818
17819
17820
17821
17822
17823
17824
17825
17826
17827
17828
17829
17830
17831
17832
17833
17834
17835
17836
17837
17838
17839
17840
17841
17842
17843
17844
17845
17846
17847
17848
17849
17850
17851
17852
17853
17854
17855
17856
17857
17858
17859
17860
17861
17862
17863
17864
17865
17866
17867
17868
17869
17870
17871
17872
17873
17874
17875
17876
17877
17878
17879
17880
17881
17882
17883
17884
17885
17886
17887
17888
17889
17890
17891
17892
17893
17894
17895
17896
17897
17898
17899
17900
17901
17902
17903
17904
17905
17906
17907
17908
17909
17910
17911
17912
17913
17914
17915
17916
17917
17918
17919
17920
17921
17922
17923
17924
17925
17926
17927
17928
17929
17930
17931
17932
17933
17934
17935
17936
17937
17938
17939
17940
17941
17942
17943
17944
17945
17946
17947
17948
17949
17950
17951
17952
17953
17954
17955
17956
17957
17958
17959
17960
17961
17962
17963
17964
17965
17966
17967
17968
17969
17970
17971
17972
17973
17974
17975
17976
17977
17978
17979
17980
17981
17982
17983
17984
17985
17986
17987
17988
17989
17990
17991
17992
17993
17994
17995
17996
17997
17998
17999
18000
18001
18002
18003
18004
18005
18006
18007
18008
18009
18010
18011
18012
18013
18014
18015
18016
18017
18018
18019
18020
18021
18022
18023
18024
18025
18026
18027
18028
18029
18030
18031
18032
18033
18034
18035
18036
18037
18038
18039
18040
18041
18042
18043
18044
18045
18046
18047
18048
18049
18050
18051
18052
18053
18054
18055
18056
18057
18058
18059
18060
18061
18062
18063
18064
18065
18066
18067
18068
18069
18070
18071
18072
18073
18074
18075
18076
18077
18078
18079
18080
18081
18082
18083
18084
18085
18086
18087
18088
18089
18090
18091
18092
18093
18094
18095
18096
18097
18098
18099
18100
18101
18102
18103
18104
18105
18106
18107
18108
18109
18110
18111
18112
18113
18114
18115
18116
18117
18118
18119
18120
18121
18122
18123
18124
18125
18126
18127
18128
18129
18130
18131
18132
18133
18134
18135
18136
18137
18138
18139
18140
18141
18142
18143
18144
18145
18146
18147
18148
18149
18150
18151
18152
18153
18154
18155
18156
18157
18158
18159
18160
18161
18162
18163
18164
18165
18166
18167
18168
18169
18170
18171
18172
18173
18174
18175
18176
18177
18178
18179
18180
18181
18182
18183
18184
18185
18186
18187
18188
18189
18190
18191
18192
18193
18194
18195
18196
18197
18198
18199
18200
18201
18202
18203
18204
18205
18206
18207
18208
18209
18210
18211
18212
18213
18214
18215
18216
18217
18218
18219
18220
18221
18222
18223
18224
18225
18226
18227
18228
18229
18230
18231
18232
18233
18234
18235
18236
18237
18238
18239
18240
18241
18242
18243
18244
18245
18246
18247
18248
18249
18250
18251
18252
18253
18254
18255
18256
18257
18258
18259
18260
18261
18262
18263
18264
18265
18266
18267
18268
18269
18270
18271
18272
18273
18274
18275
18276
18277
18278
18279
18280
18281
18282
18283
18284
18285
18286
18287
18288
18289
18290
18291
18292
18293
18294
18295
18296
18297
18298
18299
18300
18301
18302
18303
18304
18305
18306
18307
18308
18309
18310
18311
18312
18313
18314
18315
18316
18317
18318
18319
18320
18321
18322
18323
18324
18325
18326
18327
18328
18329
18330
18331
18332
18333
18334
18335
18336
18337
18338
18339
18340
18341
18342
18343
18344
18345
18346
18347
18348
18349
18350
18351
18352
18353
18354
18355
18356
18357
18358
18359
18360
18361
18362
18363
18364
18365
18366
18367
18368
18369
18370
18371
18372
18373
18374
18375
18376
18377
18378
18379
18380
18381
18382
18383
18384
18385
18386
18387
18388
18389
18390
18391
18392
18393
18394
18395
18396
18397
18398
18399
18400
18401
18402
18403
18404
18405
18406
18407
18408
18409
18410
18411
18412
18413
18414
18415
18416
18417
18418
18419
18420
18421
18422
18423
18424
18425
18426
18427
18428
18429
18430
18431
18432
18433
18434
18435
18436
18437
18438
18439
18440
18441
18442
18443
18444
18445
18446
18447
18448
18449
18450
18451
18452
18453
18454
18455
18456
18457
18458
18459
18460
18461
18462
18463
18464
18465
18466
18467
18468
18469
18470
18471
18472
18473
18474
18475
18476
18477
18478
18479
18480
18481
18482
18483
18484
18485
18486
18487
18488
18489
18490
18491
18492
18493
18494
18495
18496
18497
18498
18499
18500
18501
18502
18503
18504
18505
18506
18507
18508
18509
18510
18511
18512
18513
18514
18515
18516
18517
18518
18519
18520
18521
18522
18523
18524
18525
18526
18527
18528
18529
18530
18531
18532
18533
18534
18535
18536
18537
18538
18539
18540
18541
18542
18543
18544
18545
18546
18547
18548
18549
18550
18551
18552
18553
18554
18555
18556
18557
18558
18559
18560
18561
18562
18563
18564
18565
18566
18567
18568
18569
18570
18571
18572
18573
18574
18575
18576
18577
18578
18579
18580
18581
18582
18583
18584
18585
18586
18587
18588
18589
18590
18591
18592
18593
18594
18595
18596
18597
18598
18599
18600
18601
18602
18603
18604
18605
18606
18607
18608
18609
18610
18611
18612
18613
18614
18615
18616
18617
18618
18619
18620
18621
18622
18623
18624
18625
18626
18627
18628
18629
18630
18631
18632
18633
18634
18635
18636
18637
18638
18639
18640
18641
18642
18643
18644
18645
18646
18647
18648
18649
18650
18651
18652
18653
18654
18655
18656
18657
18658
18659
18660
18661
18662
18663
18664
18665
18666
18667
18668
18669
18670
18671
18672
18673
18674
18675
18676
18677
18678
18679
18680
18681
18682
18683
18684
18685
18686
18687
18688
18689
18690
18691
18692
18693
18694
18695
18696
18697
18698
18699
18700
18701
18702
18703
18704
18705
18706
18707
18708
18709
18710
18711
18712
18713
18714
18715
18716
18717
18718
18719
18720
18721
18722
18723
18724
18725
18726
18727
18728
18729
18730
18731
18732
18733
18734
18735
18736
18737
18738
18739
18740
18741
18742
18743
18744
18745
18746
18747
18748
18749
18750
18751
18752
18753
18754
18755
18756
18757
18758
18759
18760
18761
18762
18763
18764
18765
18766
18767
18768
18769
18770
18771
18772
18773
18774
18775
18776
18777
18778
18779
18780
18781
18782
18783
18784
18785
18786
18787
18788
18789
18790
18791
18792
18793
18794
18795
18796
18797
18798
18799
18800
18801
18802
18803
18804
18805
18806
18807
18808
18809
18810
18811
18812
18813
18814
18815
18816
18817
18818
18819
18820
18821
18822
18823
18824
18825
18826
18827
18828
18829
18830
18831
18832
18833
18834
18835
18836
18837
18838
18839
18840
18841
18842
18843
18844
18845
18846
18847
18848
18849
18850
18851
18852
18853
18854
18855
18856
18857
18858
18859
18860
18861
18862
18863
18864
18865
18866
18867
18868
18869
18870
18871
18872
18873
18874
18875
18876
18877
18878
18879
18880
18881
18882
18883
18884
18885
18886
18887
18888
18889
18890
18891
18892
18893
18894
18895
18896
18897
18898
18899
18900
18901
18902
18903
18904
18905
18906
18907
18908
18909
18910
18911
18912
18913
18914
18915
18916
18917
18918
18919
18920
18921
18922
18923
18924
18925
18926
18927
18928
18929
18930
18931
18932
18933
18934
18935
18936
18937
18938
18939
18940
18941
18942
18943
18944
18945
18946
18947
18948
18949
18950
18951
18952
18953
18954
18955
18956
18957
18958
18959
18960
18961
18962
18963
18964
18965
18966
18967
18968
18969
18970
18971
18972
18973
18974
18975
18976
18977
18978
18979
18980
18981
18982
18983
18984
18985
18986
18987
18988
18989
18990
18991
18992
18993
18994
18995
18996
18997
18998
18999
19000
19001
19002
19003
19004
19005
19006
19007
19008
19009
19010
19011
19012
19013
19014
19015
19016
19017
19018
19019
19020
19021
19022
19023
19024
19025
19026
19027
19028
19029
19030
19031
19032
19033
19034
19035
19036
19037
19038
19039
19040
19041
19042
19043
19044
19045
19046
19047
19048
19049
19050
19051
19052
19053
19054
19055
19056
19057
19058
19059
19060
19061
19062
19063
19064
19065
19066
19067
19068
19069
19070
19071
19072
19073
19074
19075
19076
19077
19078
19079
19080
19081
19082
19083
19084
19085
19086
19087
19088
19089
19090
19091
19092
19093
19094
19095
19096
19097
19098
19099
19100
19101
19102
19103
19104
19105
19106
19107
19108
19109
19110
19111
19112
19113
19114
19115
19116
19117
19118
19119
19120
19121
19122
19123
19124
19125
19126
19127
19128
19129
19130
19131
19132
19133
19134
19135
19136
19137
19138
19139
19140
19141
19142
19143
19144
19145
19146
19147
19148
19149
19150
19151
19152
19153
19154
19155
19156
19157
19158
19159
19160
19161
19162
19163
19164
19165
19166
19167
19168
19169
19170
19171
19172
19173
19174
19175
19176
19177
19178
19179
19180
19181
19182
19183
19184
19185
19186
19187
19188
19189
19190
19191
19192
19193
19194
19195
19196
19197
19198
19199
19200
19201
19202
19203
19204
19205
19206
19207
19208
19209
19210
19211
19212
19213
19214
19215
19216
19217
19218
19219
19220
19221
19222
19223
19224
19225
19226
19227
19228
19229
19230
19231
19232
19233
19234
19235
19236
19237
19238
19239
19240
19241
19242
19243
19244
19245
19246
19247
19248
19249
19250
19251
19252
19253
19254
19255
19256
19257
19258
19259
19260
19261
19262
19263
19264
19265
19266
19267
19268
19269
19270
19271
19272
19273
19274
19275
19276
19277
19278
19279
19280
19281
19282
19283
19284
19285
19286
19287
19288
19289
19290
19291
19292
19293
19294
19295
19296
19297
19298
19299
19300
19301
19302
19303
19304
19305
19306
19307
19308
19309
19310
19311
19312
19313
19314
19315
19316
19317
19318
19319
19320
19321
19322
19323
19324
19325
19326
19327
19328
19329
19330
19331
19332
19333
19334
19335
19336
19337
19338
19339
19340
19341
19342
19343
19344
19345
19346
19347
19348
19349
19350
19351
19352
19353
19354
19355
19356
19357
19358
19359
19360
19361
19362
19363
19364
19365
19366
19367
19368
19369
19370
19371
19372
19373
19374
19375
19376
19377
19378
19379
19380
19381
19382
19383
19384
19385
19386
19387
19388
19389
19390
19391
19392
19393
19394
19395
19396
19397
19398
19399
19400
19401
19402
19403
19404
19405
19406
19407
19408
19409
19410
19411
19412
19413
19414
19415
19416
19417
19418
19419
19420
19421
19422
19423
19424
19425
19426
19427
19428
19429
19430
19431
19432
19433
19434
19435
19436
19437
19438
19439
19440
19441
19442
19443
19444
19445
19446
19447
19448
19449
19450
19451
19452
19453
19454
19455
19456
19457
19458
19459
19460
19461
19462
19463
19464
19465
19466
19467
19468
19469
19470
19471
19472
19473
19474
19475
19476
19477
19478
19479
19480
19481
19482
19483
19484
19485
19486
19487
19488
19489
19490
19491
19492
19493
19494
19495
19496
19497
19498
19499
19500
19501
19502
19503
19504
19505
19506
19507
19508
19509
19510
19511
19512
19513
19514
19515
19516
19517
19518
19519
19520
19521
19522
19523
19524
19525
19526
19527
19528
19529
19530
19531
19532
19533
19534
19535
19536
19537
19538
19539
19540
19541
19542
19543
19544
19545
19546
19547
19548
19549
19550
19551
19552
19553
19554
19555
19556
19557
19558
19559
19560
19561
19562
19563
19564
19565
19566
19567
19568
19569
19570
19571
19572
19573
19574
19575
19576
19577
19578
19579
19580
19581
19582
19583
19584
19585
19586
19587
19588
19589
19590
19591
19592
19593
19594
19595
19596
19597
19598
19599
19600
19601
19602
19603
19604
19605
19606
19607
19608
19609
19610
19611
19612
19613
19614
19615
19616
19617
19618
19619
19620
19621
19622
19623
19624
19625
19626
19627
19628
19629
19630
19631
19632
19633
19634
19635
19636
19637
19638
19639
19640
19641
19642
19643
19644
19645
19646
19647
19648
19649
19650
19651
19652
19653
19654
19655
19656
19657
19658
19659
19660
19661
19662
19663
19664
19665
19666
19667
19668
19669
19670
19671
19672
19673
19674
19675
19676
19677
19678
19679
19680
19681
19682
19683
19684
19685
19686
19687
19688
19689
19690
19691
19692
19693
19694
19695
19696
19697
19698
19699
19700
19701
19702
19703
19704
19705
19706
19707
19708
19709
19710
19711
19712
19713
19714
19715
19716
19717
19718
19719
19720
19721
19722
19723
19724
19725
19726
19727
19728
19729
19730
19731
19732
19733
19734
19735
19736
19737
19738
19739
19740
19741
19742
19743
19744
19745
19746
19747
19748
19749
19750
19751
19752
19753
19754
19755
19756
19757
19758
19759
19760
19761
19762
19763
19764
19765
19766
19767
19768
19769
19770
19771
19772
19773
19774
19775
19776
19777
19778
19779
19780
19781
19782
19783
19784
19785
19786
19787
19788
19789
19790
19791
19792
19793
19794
19795
19796
19797
19798
19799
19800
19801
19802
19803
19804
19805
19806
19807
19808
19809
19810
19811
19812
19813
19814
19815
19816
19817
19818
19819
19820
19821
19822
19823
19824
19825
19826
19827
19828
19829
19830
19831
19832
19833
19834
19835
19836
19837
19838
19839
19840
19841
19842
19843
19844
19845
19846
19847
19848
19849
19850
19851
19852
19853
19854
19855
19856
19857
19858
19859
19860
19861
19862
19863
19864
19865
19866
19867
19868
19869
19870
19871
19872
19873
19874
19875
19876
19877
19878
19879
19880
19881
19882
19883
19884
19885
19886
19887
19888
19889
19890
19891
19892
19893
19894
19895
19896
19897
19898
19899
19900
19901
19902
19903
19904
19905
19906
19907
19908
19909
19910
19911
19912
19913
19914
19915
19916
19917
19918
19919
19920
19921
19922
19923
19924
19925
19926
19927
19928
19929
19930
19931
19932
19933
19934
19935
19936
19937
19938
19939
19940
19941
19942
19943
19944
19945
19946
19947
19948
19949
19950
19951
19952
19953
19954
19955
19956
19957
19958
19959
19960
19961
19962
19963
19964
19965
19966
19967
19968
19969
19970
19971
19972
19973
19974
19975
19976
19977
19978
19979
19980
19981
19982
19983
19984
19985
19986
19987
19988
19989
19990
19991
19992
19993
19994
19995
19996
19997
19998
19999
20000
20001
20002
20003
20004
20005
20006
20007
20008
20009
20010
20011
20012
20013
20014
20015
20016
20017
20018
20019
20020
20021
20022
20023
20024
20025
20026
20027
20028
20029
20030
20031
20032
20033
20034
20035
20036
20037
20038
20039
20040
20041
20042
20043
20044
20045
20046
20047
20048
20049
20050
20051
20052
20053
20054
20055
20056
20057
20058
20059
20060
20061
20062
20063
20064
20065
20066
20067
20068
20069
20070
20071
20072
20073
20074
20075
20076
20077
20078
20079
20080
20081
20082
20083
20084
20085
20086
20087
20088
20089
20090
20091
20092
20093
20094
20095
20096
20097
20098
20099
20100
20101
20102
20103
20104
20105
20106
20107
20108
20109
20110
20111
20112
20113
20114
20115
20116
20117
20118
20119
20120
20121
20122
20123
20124
20125
20126
20127
20128
20129
20130
20131
20132
20133
20134
20135
20136
20137
20138
20139
20140
20141
20142
20143
20144
20145
20146
20147
20148
20149
20150
20151
20152
20153
20154
20155
20156
20157
20158
20159
20160
20161
20162
20163
20164
20165
20166
20167
20168
20169
20170
20171
20172
20173
20174
20175
20176
20177
20178
20179
20180
20181
20182
20183
20184
20185
20186
20187
20188
20189
20190
20191
20192
20193
20194
20195
20196
20197
20198
20199
20200
20201
20202
20203
20204
20205
20206
20207
20208
20209
20210
20211
20212
20213
20214
20215
20216
20217
20218
20219
20220
20221
20222
20223
20224
20225
20226
20227
20228
20229
20230
20231
20232
20233
20234
20235
20236
20237
20238
20239
20240
20241
20242
20243
20244
20245
20246
20247
20248
20249
20250
20251
20252
20253
20254
20255
20256
20257
20258
20259
20260
20261
20262
20263
20264
20265
20266
20267
20268
20269
20270
20271
20272
20273
20274
20275
20276
20277
20278
20279
20280
20281
20282
20283
20284
20285
20286
20287
20288
20289
20290
20291
20292
20293
20294
20295
20296
20297
20298
20299
20300
20301
20302
20303
20304
20305
20306
20307
20308
20309
20310
20311
20312
20313
20314
20315
20316
20317
20318
20319
20320
20321
20322
20323
20324
20325
20326
20327
20328
20329
20330
20331
20332
20333
20334
20335
20336
20337
20338
20339
20340
20341
20342
20343
20344
20345
20346
20347
20348
20349
20350
20351
20352
20353
20354
20355
20356
20357
20358
20359
20360
20361
20362
20363
20364
20365
20366
20367
20368
20369
20370
20371
20372
20373
20374
20375
20376
20377
20378
20379
20380
20381
20382
20383
20384
20385
20386
20387
20388
20389
20390
20391
20392
20393
20394
20395
20396
20397
20398
20399
20400
20401
20402
20403
20404
20405
20406
20407
20408
20409
20410
20411
20412
20413
20414
20415
20416
20417
20418
20419
20420
20421
20422
20423
20424
20425
20426
20427
20428
20429
20430
20431
20432
20433
20434
20435
20436
20437
20438
20439
20440
20441
20442
20443
20444
20445
20446
20447
20448
20449
20450
20451
20452
20453
20454
20455
20456
20457
20458
20459
20460
20461
20462
20463
20464
20465
20466
20467
20468
20469
20470
20471
20472
20473
20474
20475
20476
20477
20478
20479
20480
20481
20482
20483
20484
20485
20486
20487
20488
20489
20490
20491
20492
20493
20494
20495
20496
20497
20498
20499
20500
20501
20502
20503
20504
20505
20506
20507
20508
20509
20510
20511
20512
20513
20514
20515
20516
20517
20518
20519
20520
20521
20522
20523
20524
20525
20526
20527
20528
20529
20530
20531
20532
20533
20534
20535
20536
20537
20538
20539
20540
20541
20542
20543
20544
20545
20546
20547
20548
20549
20550
20551
20552
20553
20554
20555
20556
20557
20558
20559
20560
20561
20562
20563
20564
20565
20566
20567
20568
20569
20570
20571
20572
20573
20574
20575
20576
20577
20578
20579
20580
20581
20582
20583
20584
20585
20586
20587
20588
20589
20590
20591
20592
20593
20594
20595
20596
20597
20598
20599
20600
20601
20602
20603
20604
20605
20606
20607
20608
20609
20610
20611
20612
20613
20614
20615
20616
20617
20618
20619
20620
20621
20622
20623
20624
20625
20626
20627
20628
20629
20630
20631
20632
20633
20634
20635
20636
20637
20638
20639
20640
20641
20642
20643
20644
20645
20646
20647
20648
20649
20650
20651
20652
20653
20654
20655
20656
20657
20658
20659
20660
20661
20662
20663
20664
20665
20666
20667
20668
20669
20670
20671
20672
20673
20674
20675
20676
20677
20678
20679
20680
20681
20682
20683
20684
20685
20686
20687
20688
20689
20690
20691
20692
20693
20694
20695
20696
20697
20698
20699
20700
20701
20702
20703
20704
20705
20706
20707
20708
20709
20710
20711
20712
20713
20714
20715
20716
20717
20718
20719
20720
20721
20722
20723
20724
20725
20726
20727
20728
20729
20730
20731
20732
20733
20734
20735
20736
20737
20738
20739
20740
20741
20742
20743
20744
20745
20746
20747
20748
20749
20750
20751
20752
20753
20754
20755
20756
20757
20758
20759
20760
20761
20762
20763
20764
20765
20766
20767
20768
20769
20770
20771
20772
20773
20774
20775
20776
20777
20778
20779
20780
20781
20782
20783
20784
20785
20786
20787
20788
20789
20790
20791
20792
20793
20794
20795
20796
20797
20798
20799
20800
20801
20802
20803
20804
20805
20806
20807
20808
20809
20810
20811
20812
20813
20814
20815
20816
20817
20818
20819
20820
20821
20822
20823
20824
20825
20826
20827
20828
20829
20830
20831
20832
20833
20834
20835
20836
20837
20838
20839
20840
20841
20842
20843
20844
20845
20846
20847
20848
20849
20850
20851
20852
20853
20854
20855
20856
20857
20858
20859
20860
20861
20862
20863
20864
20865
20866
20867
20868
20869
20870
20871
20872
20873
20874
20875
20876
20877
20878
20879
20880
20881
20882
20883
20884
20885
20886
20887
20888
20889
20890
20891
20892
20893
20894
20895
20896
20897
20898
20899
20900
20901
20902
20903
20904
20905
20906
20907
20908
20909
20910
20911
20912
20913
20914
20915
20916
20917
20918
20919
20920
20921
20922
20923
20924
20925
20926
20927
20928
20929
20930
20931
20932
20933
20934
20935
20936
20937
20938
20939
20940
20941
20942
20943
20944
20945
20946
20947
20948
20949
20950
20951
20952
20953
20954
20955
20956
20957
20958
20959
20960
20961
20962
20963
20964
20965
20966
20967
20968
20969
20970
20971
20972
20973
20974
20975
20976
20977
20978
20979
20980
20981
20982
20983
20984
20985
20986
20987
20988
20989
20990
20991
20992
20993
20994
20995
20996
20997
20998
20999
21000
21001
21002
21003
21004
21005
21006
21007
21008
21009
21010
21011
21012
21013
21014
21015
21016
21017
21018
21019
21020
21021
21022
21023
21024
21025
21026
21027
21028
21029
21030
21031
21032
21033
21034
21035
21036
21037
21038
21039
21040
21041
21042
21043
21044
21045
21046
21047
21048
21049
21050
21051
21052
21053
21054
21055
21056
21057
21058
21059
21060
21061
21062
21063
21064
21065
21066
21067
21068
21069
21070
21071
21072
21073
21074
21075
21076
21077
21078
21079
21080
21081
21082
21083
21084
21085
21086
21087
21088
21089
21090
21091
21092
21093
21094
21095
21096
21097
21098
21099
21100
21101
21102
21103
21104
21105
21106
21107
21108
21109
21110
21111
21112
21113
21114
21115
21116
21117
21118
21119
21120
21121
21122
21123
21124
21125
21126
21127
21128
21129
21130
21131
21132
21133
21134
21135
21136
21137
21138
21139
21140
21141
21142
21143
21144
21145
21146
21147
21148
21149
21150
21151
21152
21153
21154
21155
21156
21157
21158
21159
21160
21161
21162
21163
21164
21165
21166
21167
21168
21169
21170
21171
21172
21173
21174
21175
21176
21177
21178
21179
21180
21181
21182
21183
21184
21185
21186
21187
21188
21189
21190
21191
21192
21193
21194
21195
21196
21197
21198
21199
21200
21201
21202
21203
21204
21205
21206
21207
21208
21209
21210
21211
21212
21213
21214
21215
21216
21217
21218
21219
21220
21221
21222
21223
21224
21225
21226
21227
21228
21229
21230
21231
21232
21233
21234
21235
21236
21237
21238
21239
21240
21241
21242
21243
21244
21245
21246
21247
21248
21249
21250
21251
21252
21253
21254
21255
21256
21257
21258
21259
21260
21261
21262
21263
21264
21265
21266
21267
21268
21269
21270
21271
21272
21273
21274
21275
21276
21277
21278
21279
21280
21281
21282
21283
21284
21285
21286
21287
21288
21289
21290
21291
21292
21293
21294
21295
21296
21297
21298
21299
21300
21301
21302
21303
21304
21305
21306
21307
21308
21309
21310
21311
21312
21313
21314
21315
21316
21317
21318
21319
21320
21321
21322
21323
21324
21325
21326
21327
21328
21329
21330
21331
21332
21333
21334
21335
21336
21337
21338
21339
21340
21341
21342
21343
21344
21345
21346
21347
21348
21349
21350
21351
21352
21353
21354
21355
21356
21357
21358
21359
21360
21361
21362
21363
21364
21365
21366
21367
21368
21369
21370
21371
21372
21373
21374
21375
21376
21377
21378
21379
21380
21381
21382
21383
21384
21385
21386
21387
21388
21389
21390
21391
21392
21393
21394
21395
21396
21397
21398
21399
21400
21401
21402
21403
21404
21405
21406
21407
21408
21409
21410
21411
21412
21413
21414
21415
21416
21417
21418
21419
21420
21421
21422
21423
21424
21425
21426
21427
21428
21429
21430
21431
21432
21433
21434
21435
21436
21437
21438
21439
21440
21441
21442
21443
21444
21445
21446
21447
21448
21449
21450
21451
21452
21453
21454
21455
21456
21457
21458
21459
21460
21461
21462
21463
21464
21465
21466
21467
21468
21469
21470
21471
21472
21473
21474
21475
21476
21477
21478
21479
21480
21481
21482
21483
21484
21485
21486
21487
21488
21489
21490
21491
21492
21493
21494
21495
21496
21497
21498
21499
21500
21501
21502
21503
21504
21505
21506
21507
21508
21509
21510
21511
21512
21513
21514
21515
21516
21517
21518
21519
21520
21521
21522
21523
21524
21525
21526
21527
21528
21529
21530
21531
21532
21533
21534
21535
21536
21537
21538
21539
21540
21541
21542
21543
21544
21545
21546
21547
21548
21549
21550
21551
21552
21553
21554
21555
21556
21557
21558
21559
21560
21561
21562
21563
21564
21565
21566
21567
21568
21569
21570
21571
21572
21573
21574
21575
21576
21577
21578
21579
21580
21581
21582
21583
21584
21585
21586
21587
21588
21589
21590
21591
21592
21593
21594
21595
21596
21597
21598
21599
21600
21601
21602
21603
21604
21605
21606
21607
21608
21609
21610
21611
21612
21613
21614
21615
21616
21617
21618
21619
21620
21621
21622
21623
21624
21625
21626
21627
21628
21629
21630
21631
21632
21633
21634
21635
21636
21637
21638
21639
21640
21641
21642
21643
21644
21645
21646
21647
21648
21649
21650
21651
21652
21653
21654
21655
21656
21657
21658
21659
21660
21661
21662
21663
21664
21665
21666
21667
21668
21669
21670
21671
21672
21673
21674
21675
21676
21677
21678
21679
21680
21681
21682
21683
21684
21685
21686
21687
21688
21689
21690
21691
21692
21693
21694
21695
21696
21697
21698
21699
21700
21701
21702
21703
21704
21705
21706
21707
21708
21709
21710
21711
21712
21713
21714
21715
21716
21717
21718
21719
21720
21721
21722
21723
21724
21725
21726
21727
21728
21729
21730
21731
21732
21733
21734
21735
21736
21737
21738
21739
21740
21741
21742
21743
21744
21745
21746
21747
21748
21749
21750
21751
21752
21753
21754
21755
21756
21757
21758
21759
21760
21761
21762
21763
21764
21765
21766
21767
21768
21769
21770
21771
21772
21773
21774
21775
21776
21777
21778
21779
21780
21781
21782
21783
21784
21785
21786
21787
21788
21789
21790
21791
21792
21793
21794
21795
21796
21797
21798
21799
21800
21801
21802
21803
21804
21805
21806
21807
21808
21809
21810
21811
21812
21813
21814
21815
21816
21817
21818
21819
21820
21821
21822
21823
21824
21825
21826
21827
21828
21829
21830
21831
21832
21833
21834
21835
21836
21837
21838
21839
21840
21841
21842
21843
21844
21845
21846
21847
21848
21849
21850
21851
21852
21853
21854
21855
21856
21857
21858
21859
21860
21861
21862
21863
21864
21865
21866
21867
21868
21869
21870
21871
21872
21873
21874
21875
21876
21877
21878
21879
21880
21881
21882
21883
21884
21885
21886
21887
21888
21889
21890
21891
21892
21893
21894
21895
21896
21897
21898
21899
21900
21901
21902
21903
21904
21905
21906
21907
21908
21909
21910
21911
21912
21913
21914
21915
21916
21917
21918
21919
21920
21921
21922
21923
21924
21925
21926
21927
21928
21929
21930
21931
21932
21933
21934
21935
21936
21937
21938
21939
21940
21941
21942
21943
21944
21945
21946
21947
21948
21949
21950
21951
21952
21953
21954
21955
21956
21957
21958
21959
21960
21961
21962
21963
21964
21965
21966
21967
21968
21969
21970
21971
21972
21973
21974
21975
21976
21977
21978
21979
21980
21981
21982
21983
21984
21985
21986
21987
21988
21989
21990
21991
21992
21993
21994
21995
21996
21997
21998
21999
22000
22001
22002
22003
22004
22005
22006
22007
22008
22009
22010
22011
22012
22013
22014
22015
22016
22017
22018
22019
22020
22021
22022
22023
22024
22025
22026
22027
22028
22029
22030
22031
22032
22033
22034
22035
22036
22037
22038
22039
22040
22041
22042
22043
22044
22045
22046
22047
22048
22049
22050
22051
22052
22053
22054
22055
22056
22057
22058
22059
22060
22061
22062
22063
22064
22065
22066
22067
22068
22069
22070
22071
22072
22073
22074
22075
22076
22077
22078
22079
22080
22081
22082
22083
22084
22085
22086
22087
22088
22089
22090
22091
22092
22093
22094
22095
22096
22097
22098
22099
22100
22101
22102
22103
22104
22105
22106
22107
22108
22109
22110
22111
22112
22113
22114
22115
22116
22117
22118
22119
22120
22121
22122
22123
22124
22125
22126
22127
22128
22129
22130
22131
22132
22133
22134
22135
22136
22137
22138
22139
22140
22141
22142
22143
22144
22145
22146
22147
22148
22149
22150
22151
22152
22153
22154
22155
22156
22157
22158
22159
22160
22161
22162
22163
22164
22165
22166
22167
22168
22169
22170
22171
22172
22173
22174
22175
22176
22177
22178
22179
22180
22181
22182
22183
22184
22185
22186
22187
22188
22189
22190
22191
22192
22193
22194
22195
22196
22197
22198
22199
22200
22201
22202
22203
22204
22205
22206
22207
22208
22209
22210
22211
22212
22213
22214
22215
22216
22217
22218
22219
22220
22221
22222
22223
22224
22225
22226
22227
22228
22229
22230
22231
22232
22233
22234
22235
22236
22237
22238
22239
22240
22241
22242
22243
22244
22245
22246
22247
22248
22249
22250
22251
22252
22253
22254
22255
22256
22257
22258
22259
22260
22261
22262
22263
22264
22265
22266
22267
22268
22269
22270
22271
22272
22273
22274
22275
22276
22277
22278
22279
22280
22281
22282
22283
22284
22285
22286
22287
22288
22289
22290
22291
22292
22293
22294
22295
22296
22297
22298
22299
22300
22301
22302
22303
22304
22305
22306
22307
22308
22309
22310
22311
22312
22313
22314
22315
22316
22317
22318
22319
22320
22321
22322
22323
22324
22325
22326
22327
22328
22329
22330
22331
22332
22333
22334
22335
22336
22337
22338
22339
22340
22341
22342
22343
22344
22345
22346
22347
22348
22349
22350
22351
22352
22353
22354
22355
22356
22357
22358
22359
22360
22361
22362
22363
22364
22365
22366
22367
22368
22369
22370
22371
22372
22373
22374
22375
22376
22377
22378
22379
22380
22381
22382
22383
22384
22385
22386
22387
22388
22389
22390
22391
22392
22393
22394
22395
22396
22397
22398
22399
22400
22401
22402
22403
22404
22405
22406
22407
22408
22409
22410
22411
22412
22413
22414
22415
22416
22417
22418
22419
22420
22421
22422
22423
22424
22425
22426
22427
22428
22429
22430
22431
22432
22433
22434
22435
22436
22437
22438
22439
22440
22441
22442
22443
22444
22445
22446
22447
22448
22449
22450
22451
22452
22453
22454
22455
22456
22457
22458
22459
22460
22461
22462
22463
22464
22465
22466
22467
22468
22469
22470
22471
22472
22473
22474
22475
22476
22477
22478
22479
22480
22481
22482
22483
22484
22485
22486
22487
22488
22489
22490
22491
22492
22493
22494
22495
22496
22497
22498
22499
22500
22501
22502
22503
22504
22505
22506
22507
22508
22509
22510
22511
22512
22513
22514
22515
22516
22517
22518
22519
22520
22521
22522
22523
22524
22525
22526
22527
22528
22529
22530
22531
22532
22533
22534
22535
22536
22537
22538
22539
22540
22541
22542
22543
22544
22545
22546
22547
22548
22549
22550
22551
22552
22553
22554
22555
22556
22557
22558
22559
22560
22561
22562
22563
22564
22565
22566
22567
22568
22569
22570
22571
22572
22573
22574
22575
22576
22577
22578
22579
22580
22581
22582
22583
22584
22585
22586
22587
22588
22589
22590
22591
22592
22593
22594
22595
22596
22597
22598
22599
22600
22601
22602
22603
22604
22605
22606
22607
22608
22609
22610
22611
22612
22613
22614
22615
22616
22617
22618
22619
22620
22621
22622
22623
22624
22625
22626
22627
22628
22629
22630
22631
22632
22633
22634
22635
22636
22637
22638
22639
22640
22641
22642
22643
22644
22645
22646
22647
22648
22649
22650
22651
22652
22653
22654
22655
22656
22657
22658
22659
22660
22661
22662
22663
22664
22665
22666
22667
22668
22669
22670
22671
22672
22673
22674
22675
22676
22677
22678
22679
22680
22681
22682
22683
22684
22685
22686
22687
22688
22689
22690
22691
22692
22693
22694
22695
22696
22697
22698
22699
22700
22701
22702
22703
22704
22705
22706
22707
22708
22709
22710
22711
22712
22713
22714
22715
22716
22717
22718
22719
22720
22721
22722
22723
22724
22725
22726
22727
22728
22729
22730
22731
22732
22733
22734
22735
22736
22737
22738
22739
22740
22741
22742
22743
22744
22745
22746
22747
22748
22749
22750
22751
22752
22753
22754
22755
22756
22757
22758
22759
22760
22761
22762
22763
22764
22765
22766
22767
22768
22769
22770
22771
22772
22773
22774
22775
22776
22777
22778
22779
22780
22781
22782
22783
22784
22785
22786
22787
22788
22789
22790
22791
22792
22793
22794
22795
22796
22797
22798
22799
22800
22801
22802
22803
22804
22805
22806
22807
22808
22809
22810
22811
22812
22813
22814
22815
22816
22817
22818
22819
22820
22821
22822
22823
22824
22825
22826
22827
22828
22829
22830
22831
22832
22833
22834
22835
22836
22837
22838
22839
22840
22841
22842
22843
22844
22845
22846
22847
22848
22849
22850
22851
22852
22853
22854
22855
22856
22857
22858
22859
22860
22861
22862
22863
22864
22865
22866
22867
22868
22869
22870
22871
22872
22873
22874
22875
22876
22877
22878
22879
22880
22881
22882
22883
22884
22885
22886
22887
22888
22889
22890
22891
22892
22893
22894
22895
22896
22897
22898
22899
22900
22901
22902
22903
22904
22905
22906
22907
22908
22909
22910
22911
22912
22913
22914
22915
22916
22917
22918
22919
22920
22921
22922
22923
22924
22925
22926
22927
22928
22929
22930
22931
22932
22933
22934
22935
22936
22937
22938
22939
22940
22941
22942
22943
22944
22945
22946
22947
22948
22949
22950
22951
22952
22953
22954
22955
22956
22957
22958
22959
22960
22961
22962
22963
22964
22965
22966
22967
22968
22969
22970
22971
22972
22973
22974
22975
22976
22977
22978
22979
22980
22981
22982
22983
22984
22985
22986
22987
22988
22989
22990
22991
22992
22993
22994
22995
22996
22997
22998
22999
23000
23001
23002
23003
23004
23005
23006
23007
23008
23009
23010
23011
23012
23013
23014
23015
23016
23017
23018
23019
23020
23021
23022
23023
23024
23025
23026
23027
23028
23029
23030
23031
23032
23033
23034
23035
23036
23037
23038
23039
23040
23041
23042
23043
23044
23045
23046
23047
23048
23049
23050
23051
23052
23053
23054
23055
23056
23057
23058
23059
23060
23061
23062
23063
23064
23065
23066
23067
23068
23069
23070
23071
23072
23073
23074
23075
23076
23077
23078
23079
23080
23081
23082
23083
23084
23085
23086
23087
23088
23089
23090
23091
23092
23093
23094
23095
23096
23097
23098
23099
23100
23101
23102
23103
23104
23105
23106
23107
23108
23109
23110
23111
23112
23113
23114
23115
23116
23117
23118
23119
23120
23121
23122
23123
23124
23125
23126
23127
23128
23129
23130
23131
23132
23133
23134
23135
23136
23137
23138
23139
23140
23141
23142
23143
23144
23145
23146
23147
23148
23149
23150
23151
23152
23153
23154
23155
23156
23157
23158
23159
23160
23161
23162
23163
23164
23165
23166
23167
23168
23169
23170
23171
23172
23173
23174
23175
23176
23177
23178
23179
23180
23181
23182
23183
23184
23185
23186
23187
23188
23189
23190
23191
23192
23193
23194
23195
23196
23197
23198
23199
23200
23201
23202
23203
23204
23205
23206
23207
23208
23209
23210
23211
23212
23213
23214
23215
23216
23217
23218
23219
23220
23221
23222
23223
23224
23225
23226
23227
23228
23229
23230
23231
23232
23233
23234
23235
23236
23237
23238
23239
23240
23241
23242
23243
23244
23245
23246
23247
23248
23249
23250
23251
23252
23253
23254
23255
23256
23257
23258
23259
23260
23261
23262
23263
23264
23265
23266
23267
23268
23269
23270
23271
23272
23273
23274
23275
23276
23277
23278
23279
23280
23281
23282
23283
23284
23285
23286
23287
23288
23289
23290
23291
23292
23293
23294
23295
23296
23297
23298
23299
23300
23301
23302
23303
23304
23305
23306
23307
23308
23309
23310
23311
23312
23313
23314
23315
23316
23317
23318
23319
23320
23321
23322
23323
23324
23325
23326
23327
23328
23329
23330
23331
23332
23333
23334
23335
23336
23337
23338
23339
23340
23341
23342
23343
23344
23345
23346
23347
23348
23349
23350
23351
23352
23353
23354
23355
23356
23357
23358
23359
23360
23361
23362
23363
23364
23365
23366
23367
23368
23369
23370
23371
23372
23373
23374
23375
23376
23377
23378
23379
23380
23381
23382
23383
23384
23385
23386
23387
23388
23389
23390
23391
23392
23393
23394
23395
23396
23397
23398
23399
23400
23401
23402
23403
23404
23405
23406
23407
23408
23409
23410
23411
23412
23413
23414
23415
23416
23417
23418
23419
23420
23421
23422
23423
23424
23425
23426
23427
23428
23429
23430
23431
23432
23433
23434
23435
23436
23437
23438
23439
23440
23441
23442
23443
23444
23445
23446
23447
23448
23449
23450
23451
23452
23453
23454
23455
23456
23457
23458
23459
23460
23461
23462
23463
23464
23465
23466
23467
23468
23469
23470
23471
23472
23473
23474
23475
23476
23477
23478
23479
23480
23481
23482
23483
23484
23485
23486
23487
23488
23489
23490
23491
23492
23493
23494
23495
23496
23497
23498
23499
23500
23501
23502
23503
23504
23505
23506
23507
23508
23509
23510
23511
23512
23513
23514
23515
23516
23517
23518
23519
23520
23521
23522
23523
23524
23525
23526
23527
23528
23529
23530
23531
23532
23533
23534
23535
23536
23537
23538
23539
23540
23541
23542
23543
23544
23545
23546
23547
23548
23549
23550
23551
23552
23553
23554
23555
23556
23557
23558
23559
23560
23561
23562
23563
23564
23565
23566
23567
23568
23569
23570
23571
23572
23573
23574
23575
23576
23577
23578
23579
23580
23581
23582
23583
23584
23585
23586
23587
23588
23589
23590
23591
23592
23593
23594
23595
23596
23597
23598
23599
23600
23601
23602
23603
23604
23605
23606
23607
23608
23609
23610
23611
23612
23613
23614
23615
23616
23617
23618
23619
23620
23621
23622
23623
23624
23625
23626
23627
23628
23629
23630
23631
23632
23633
23634
23635
23636
23637
23638
23639
23640
23641
23642
23643
23644
23645
23646
23647
23648
23649
23650
23651
23652
23653
23654
23655
23656
23657
23658
23659
23660
23661
23662
23663
23664
23665
23666
23667
23668
23669
23670
23671
23672
23673
23674
23675
23676
23677
23678
23679
23680
23681
23682
23683
23684
23685
23686
23687
23688
23689
23690
23691
23692
23693
23694
23695
23696
23697
23698
23699
23700
23701
23702
23703
23704
23705
23706
23707
23708
23709
23710
23711
23712
23713
23714
23715
23716
23717
23718
23719
23720
23721
23722
23723
23724
23725
23726
23727
23728
23729
23730
23731
23732
23733
23734
23735
23736
23737
23738
23739
23740
23741
23742
23743
23744
23745
23746
23747
23748
23749
23750
23751
23752
23753
23754
23755
23756
23757
23758
23759
23760
23761
23762
23763
23764
23765
23766
23767
23768
23769
23770
23771
23772
23773
23774
23775
23776
23777
23778
23779
23780
23781
23782
23783
23784
23785
23786
23787
23788
23789
23790
23791
23792
23793
23794
23795
23796
23797
23798
23799
23800
23801
23802
23803
23804
23805
23806
23807
23808
23809
23810
23811
23812
23813
23814
23815
23816
23817
23818
23819
23820
23821
23822
23823
23824
23825
23826
23827
23828
23829
23830
23831
23832
23833
23834
23835
23836
23837
23838
23839
23840
23841
23842
23843
23844
23845
23846
23847
23848
23849
23850
23851
23852
23853
23854
23855
23856
23857
23858
23859
23860
23861
23862
23863
23864
23865
23866
23867
23868
23869
23870
23871
23872
23873
23874
23875
23876
23877
23878
23879
23880
23881
23882
23883
23884
23885
23886
23887
23888
23889
23890
23891
23892
23893
23894
23895
23896
23897
23898
23899
23900
23901
23902
23903
23904
23905
23906
23907
23908
23909
23910
23911
23912
23913
23914
23915
23916
23917
23918
23919
23920
23921
23922
23923
23924
23925
23926
23927
23928
23929
23930
23931
23932
23933
23934
23935
23936
23937
23938
23939
23940
23941
23942
23943
23944
23945
23946
23947
23948
23949
23950
23951
23952
23953
23954
23955
23956
23957
23958
23959
23960
23961
23962
23963
23964
23965
23966
23967
23968
23969
23970
23971
23972
23973
23974
23975
23976
23977
23978
23979
23980
23981
23982
23983
23984
23985
23986
23987
23988
23989
23990
23991
23992
23993
23994
23995
23996
23997
23998
23999
24000
24001
24002
24003
24004
24005
24006
24007
24008
24009
24010
24011
24012
24013
24014
24015
24016
24017
24018
24019
24020
24021
24022
24023
24024
24025
24026
24027
24028
24029
24030
24031
24032
24033
24034
24035
24036
24037
24038
24039
24040
24041
24042
24043
24044
24045
24046
24047
24048
24049
24050
24051
24052
24053
24054
24055
24056
24057
24058
24059
24060
24061
24062
24063
24064
24065
24066
24067
24068
24069
24070
24071
24072
24073
24074
24075
24076
24077
24078
24079
24080
24081
24082
24083
24084
24085
24086
24087
24088
24089
24090
24091
24092
24093
24094
24095
24096
24097
24098
24099
24100
24101
24102
24103
24104
24105
24106
24107
24108
24109
24110
24111
24112
24113
24114
24115
24116
24117
24118
24119
24120
24121
24122
24123
24124
24125
24126
24127
24128
24129
24130
24131
24132
24133
24134
24135
24136
24137
24138
24139
24140
24141
24142
24143
24144
24145
24146
24147
24148
24149
24150
24151
24152
24153
24154
24155
24156
24157
24158
24159
24160
24161
24162
24163
24164
24165
24166
24167
24168
24169
24170
24171
24172
24173
24174
24175
24176
24177
24178
24179
24180
24181
24182
24183
24184
24185
24186
24187
24188
24189
24190
24191
24192
24193
24194
24195
24196
24197
24198
24199
24200
24201
24202
24203
24204
24205
24206
24207
24208
24209
24210
24211
24212
24213
24214
24215
24216
24217
24218
24219
24220
24221
24222
24223
24224
24225
24226
24227
24228
24229
24230
24231
24232
24233
24234
24235
24236
24237
24238
24239
24240
24241
24242
24243
24244
24245
24246
24247
24248
24249
24250
24251
24252
24253
24254
24255
24256
24257
24258
24259
24260
24261
24262
24263
24264
24265
24266
24267
24268
24269
24270
24271
24272
24273
24274
24275
24276
24277
24278
24279
24280
24281
24282
24283
24284
24285
24286
24287
24288
24289
24290
24291
24292
24293
24294
24295
24296
24297
24298
24299
24300
24301
24302
24303
24304
24305
24306
24307
24308
24309
24310
24311
24312
24313
24314
24315
24316
24317
24318
24319
24320
24321
24322
24323
24324
24325
24326
24327
24328
24329
24330
24331
24332
24333
24334
24335
24336
24337
24338
24339
24340
24341
24342
24343
24344
24345
24346
24347
24348
24349
24350
24351
24352
24353
24354
24355
24356
24357
24358
24359
24360
24361
24362
24363
24364
24365
24366
24367
24368
24369
24370
24371
24372
24373
24374
24375
24376
24377
24378
24379
24380
24381
24382
24383
24384
24385
24386
24387
24388
24389
24390
24391
24392
24393
24394
24395
24396
24397
24398
24399
24400
24401
24402
24403
24404
24405
24406
24407
24408
24409
24410
24411
24412
24413
24414
24415
24416
24417
24418
24419
24420
24421
24422
24423
24424
24425
24426
24427
24428
24429
24430
24431
24432
24433
24434
24435
24436
24437
24438
24439
24440
24441
24442
24443
24444
24445
24446
24447
24448
24449
24450
24451
24452
24453
24454
24455
24456
24457
24458
24459
24460
24461
24462
24463
24464
24465
24466
24467
24468
24469
24470
24471
24472
24473
24474
24475
24476
24477
24478
24479
24480
24481
24482
24483
24484
24485
24486
24487
24488
24489
24490
24491
24492
24493
24494
24495
24496
24497
24498
24499
24500
24501
24502
24503
24504
24505
24506
24507
24508
24509
24510
24511
24512
24513
24514
24515
24516
24517
24518
24519
24520
24521
24522
24523
24524
24525
24526
24527
24528
24529
24530
24531
24532
24533
24534
24535
24536
24537
24538
24539
24540
24541
24542
24543
24544
24545
24546
24547
24548
24549
24550
24551
24552
24553
24554
24555
24556
24557
24558
24559
24560
24561
24562
24563
24564
24565
24566
24567
24568
24569
24570
24571
24572
24573
24574
24575
24576
24577
24578
24579
24580
24581
24582
24583
24584
24585
24586
24587
24588
24589
24590
24591
24592
24593
24594
24595
24596
24597
24598
24599
24600
24601
24602
24603
24604
24605
24606
24607
24608
24609
24610
24611
24612
24613
24614
24615
24616
24617
24618
24619
24620
24621
24622
24623
24624
24625
24626
24627
24628
24629
24630
24631
24632
24633
24634
24635
24636
24637
24638
24639
24640
24641
24642
24643
24644
24645
24646
24647
24648
24649
24650
24651
24652
24653
24654
24655
24656
24657
24658
24659
24660
24661
24662
24663
24664
24665
24666
24667
24668
24669
24670
24671
24672
24673
24674
24675
24676
24677
24678
24679
24680
24681
24682
24683
24684
24685
24686
24687
24688
24689
24690
24691
24692
24693
24694
24695
24696
24697
24698
24699
24700
24701
24702
24703
24704
24705
24706
24707
24708
24709
24710
24711
24712
24713
24714
24715
24716
24717
24718
24719
24720
24721
24722
24723
24724
24725
24726
24727
24728
24729
24730
24731
24732
24733
24734
24735
24736
24737
24738
24739
24740
24741
24742
24743
24744
24745
24746
24747
24748
24749
24750
24751
24752
24753
24754
24755
24756
24757
24758
24759
24760
24761
24762
24763
24764
24765
24766
24767
24768
24769
24770
24771
24772
24773
24774
24775
24776
24777
24778
24779
24780
24781
24782
24783
24784
24785
24786
24787
24788
24789
24790
24791
24792
24793
24794
24795
24796
24797
24798
24799
24800
24801
24802
24803
24804
24805
24806
24807
24808
24809
24810
24811
24812
24813
24814
24815
24816
24817
24818
24819
24820
24821
24822
24823
24824
24825
24826
24827
24828
24829
24830
24831
24832
24833
24834
24835
24836
24837
24838
24839
24840
24841
24842
24843
24844
24845
24846
24847
24848
24849
24850
24851
24852
24853
24854
24855
24856
24857
24858
24859
24860
24861
24862
24863
24864
24865
24866
24867
24868
24869
24870
24871
24872
24873
24874
24875
24876
24877
24878
24879
24880
24881
24882
24883
24884
24885
24886
24887
24888
24889
24890
24891
24892
24893
24894
24895
24896
24897
24898
24899
24900
24901
24902
24903
24904
24905
24906
24907
24908
24909
24910
24911
24912
24913
24914
24915
24916
24917
24918
24919
24920
24921
24922
24923
24924
24925
24926
24927
24928
24929
24930
24931
24932
24933
24934
24935
24936
24937
24938
24939
24940
24941
24942
24943
24944
24945
24946
24947
24948
24949
24950
24951
24952
24953
24954
24955
24956
24957
24958
24959
24960
24961
24962
24963
24964
24965
24966
24967
24968
24969
24970
24971
24972
24973
24974
24975
24976
24977
24978
24979
24980
24981
24982
24983
24984
24985
24986
24987
24988
24989
24990
24991
24992
24993
24994
24995
24996
24997
24998
24999
25000
25001
25002
25003
25004
25005
25006
25007
25008
25009
25010
25011
25012
25013
25014
25015
25016
25017
25018
25019
25020
25021
25022
25023
25024
25025
25026
25027
25028
25029
25030
25031
25032
25033
25034
25035
25036
25037
25038
25039
25040
25041
25042
25043
25044
25045
25046
25047
25048
25049
25050
25051
25052
25053
25054
25055
25056
25057
25058
25059
25060
25061
25062
25063
25064
25065
25066
25067
25068
25069
25070
25071
25072
25073
25074
25075
25076
25077
25078
25079
25080
25081
25082
25083
25084
25085
25086
25087
25088
25089
25090
25091
25092
25093
25094
25095
25096
25097
25098
25099
25100
25101
25102
25103
25104
25105
25106
25107
25108
25109
25110
25111
25112
25113
25114
25115
25116
25117
25118
25119
25120
25121
25122
25123
25124
25125
25126
25127
25128
25129
25130
25131
25132
25133
25134
25135
25136
25137
25138
25139
25140
25141
25142
25143
25144
25145
25146
25147
25148
25149
25150
25151
25152
25153
25154
25155
25156
25157
25158
25159
25160
25161
25162
25163
25164
25165
25166
25167
25168
25169
25170
25171
25172
25173
25174
25175
25176
25177
25178
25179
25180
25181
25182
25183
25184
25185
25186
25187
25188
25189
25190
25191
25192
25193
25194
25195
25196
25197
25198
25199
25200
25201
25202
25203
25204
25205
25206
25207
25208
25209
25210
25211
25212
25213
25214
25215
25216
25217
25218
25219
25220
25221
25222
25223
25224
25225
25226
25227
25228
25229
25230
25231
25232
25233
25234
25235
25236
25237
25238
25239
25240
25241
25242
25243
25244
25245
25246
25247
25248
25249
25250
25251
25252
25253
25254
25255
25256
25257
25258
25259
25260
25261
25262
25263
25264
25265
25266
25267
25268
25269
25270
25271
25272
25273
25274
25275
25276
25277
25278
25279
25280
25281
25282
25283
25284
25285
25286
25287
25288
25289
25290
25291
25292
25293
25294
25295
25296
25297
25298
25299
25300
25301
25302
25303
25304
25305
25306
25307
25308
25309
25310
25311
25312
25313
25314
25315
25316
25317
25318
25319
25320
25321
25322
25323
25324
25325
25326
25327
25328
25329
25330
25331
25332
25333
25334
25335
25336
25337
25338
25339
25340
25341
25342
25343
25344
25345
25346
25347
25348
25349
25350
25351
25352
25353
25354
25355
25356
25357
25358
25359
25360
25361
25362
25363
25364
25365
25366
25367
25368
25369
25370
25371
25372
25373
25374
25375
25376
25377
25378
25379
25380
25381
25382
25383
25384
25385
25386
25387
25388
25389
25390
25391
25392
25393
25394
25395
25396
25397
25398
25399
25400
25401
25402
25403
25404
25405
25406
25407
25408
25409
25410
25411
25412
25413
25414
25415
25416
25417
25418
25419
25420
25421
25422
25423
25424
25425
25426
25427
25428
25429
25430
25431
25432
25433
25434
25435
25436
25437
25438
25439
25440
25441
25442
25443
25444
25445
25446
25447
25448
25449
25450
25451
25452
25453
25454
25455
25456
25457
25458
25459
25460
25461
25462
25463
25464
25465
25466
25467
25468
25469
25470
25471
25472
25473
25474
25475
25476
25477
25478
25479
25480
25481
25482
25483
25484
25485
25486
25487
25488
25489
25490
25491
25492
25493
25494
25495
25496
25497
25498
25499
25500
25501
25502
25503
25504
25505
25506
25507
25508
25509
25510
25511
25512
25513
25514
25515
25516
25517
25518
25519
25520
25521
25522
25523
25524
25525
25526
25527
25528
25529
25530
25531
25532
25533
25534
25535
25536
25537
25538
25539
25540
25541
25542
25543
25544
25545
25546
25547
25548
25549
25550
25551
25552
25553
25554
25555
25556
25557
25558
25559
25560
25561
25562
25563
25564
25565
25566
25567
25568
25569
25570
25571
25572
25573
25574
25575
25576
25577
25578
25579
25580
25581
25582
25583
25584
25585
25586
25587
25588
25589
25590
25591
25592
25593
25594
25595
25596
25597
25598
25599
25600
25601
25602
25603
25604
25605
25606
25607
25608
25609
25610
25611
25612
25613
25614
25615
25616
25617
25618
25619
25620
25621
25622
25623
25624
25625
25626
25627
25628
25629
25630
25631
25632
25633
25634
25635
25636
25637
25638
25639
25640
25641
25642
25643
25644
25645
25646
25647
25648
25649
25650
25651
25652
25653
25654
25655
25656
25657
25658
25659
25660
25661
25662
25663
25664
25665
25666
25667
25668
25669
25670
25671
25672
25673
25674
25675
25676
25677
25678
25679
25680
25681
25682
25683
25684
25685
25686
25687
25688
25689
25690
25691
25692
25693
25694
25695
25696
25697
25698
25699
25700
25701
25702
25703
25704
25705
25706
25707
25708
25709
25710
25711
25712
25713
25714
25715
25716
25717
25718
25719
25720
25721
25722
25723
25724
25725
25726
25727
25728
25729
25730
25731
25732
25733
25734
25735
25736
25737
25738
25739
25740
25741
25742
25743
25744
25745
25746
25747
25748
25749
25750
25751
25752
25753
25754
25755
25756
25757
25758
25759
25760
25761
25762
25763
25764
25765
25766
25767
25768
25769
25770
25771
25772
25773
25774
25775
25776
25777
25778
25779
25780
25781
25782
25783
25784
25785
25786
25787
25788
25789
25790
25791
25792
25793
25794
25795
25796
25797
25798
25799
25800
25801
25802
25803
25804
25805
25806
25807
25808
25809
25810
25811
25812
25813
25814
25815
25816
25817
25818
25819
25820
25821
25822
25823
25824
25825
25826
25827
25828
25829
25830
25831
25832
25833
25834
25835
25836
25837
25838
25839
25840
25841
25842
25843
25844
25845
25846
25847
25848
25849
25850
25851
25852
25853
25854
25855
25856
25857
25858
25859
25860
25861
25862
25863
25864
25865
25866
25867
25868
25869
25870
25871
25872
25873
25874
25875
25876
25877
25878
25879
25880
25881
25882
25883
25884
25885
25886
25887
25888
25889
25890
25891
25892
25893
25894
25895
25896
25897
25898
25899
25900
25901
25902
25903
25904
25905
25906
25907
25908
25909
25910
25911
25912
25913
25914
25915
25916
25917
25918
25919
25920
25921
25922
25923
25924
25925
25926
25927
25928
25929
25930
25931
25932
25933
25934
25935
25936
25937
25938
25939
25940
25941
25942
25943
25944
25945
25946
25947
25948
25949
25950
25951
25952
25953
25954
25955
25956
25957
25958
25959
25960
25961
25962
25963
25964
25965
25966
25967
25968
25969
25970
25971
25972
25973
25974
25975
25976
25977
25978
25979
25980
25981
25982
25983
25984
25985
25986
25987
25988
25989
25990
25991
25992
25993
25994
25995
25996
25997
25998
25999
26000
26001
26002
26003
26004
26005
26006
26007
26008
26009
26010
26011
26012
26013
26014
26015
26016
26017
26018
26019
26020
26021
26022
26023
26024
26025
26026
26027
26028
26029
26030
26031
26032
26033
26034
26035
26036
26037
26038
26039
26040
26041
26042
26043
26044
26045
26046
26047
26048
26049
26050
26051
26052
26053
26054
26055
26056
26057
26058
26059
26060
26061
26062
26063
26064
26065
26066
26067
26068
26069
26070
26071
26072
26073
26074
26075
26076
26077
26078
26079
26080
26081
26082
26083
26084
26085
26086
26087
26088
26089
26090
26091
26092
26093
26094
26095
26096
26097
26098
26099
26100
26101
26102
26103
26104
26105
26106
26107
26108
26109
26110
26111
26112
26113
26114
26115
26116
26117
26118
26119
26120
26121
26122
26123
26124
26125
26126
26127
26128
26129
26130
26131
26132
26133
26134
26135
26136
26137
26138
26139
26140
26141
26142
26143
26144
26145
26146
26147
26148
26149
26150
26151
26152
26153
26154
26155
26156
26157
26158
26159
26160
26161
26162
26163
26164
26165
26166
26167
26168
26169
26170
26171
26172
26173
26174
26175
26176
26177
26178
26179
26180
26181
26182
26183
26184
26185
26186
26187
26188
26189
26190
26191
26192
26193
26194
26195
26196
26197
26198
26199
26200
26201
26202
26203
26204
26205
26206
26207
26208
26209
26210
26211
26212
26213
26214
26215
26216
26217
26218
26219
26220
26221
26222
26223
26224
26225
26226
26227
26228
26229
26230
26231
26232
26233
26234
26235
26236
26237
26238
26239
26240
26241
26242
26243
26244
26245
26246
26247
26248
26249
26250
26251
26252
26253
26254
26255
26256
26257
26258
26259
26260
26261
26262
26263
26264
26265
26266
26267
26268
26269
26270
26271
26272
26273
26274
26275
26276
26277
26278
26279
26280
26281
26282
26283
26284
26285
26286
26287
26288
26289
26290
26291
26292
26293
26294
26295
26296
26297
26298
26299
26300
26301
26302
26303
26304
26305
26306
26307
26308
26309
26310
26311
26312
26313
26314
26315
26316
26317
26318
26319
26320
26321
26322
26323
26324
26325
26326
26327
26328
26329
26330
26331
26332
26333
26334
26335
26336
26337
26338
26339
26340
26341
26342
26343
26344
26345
26346
26347
26348
26349
26350
26351
26352
26353
26354
26355
26356
26357
26358
26359
26360
26361
26362
26363
26364
26365
26366
26367
26368
26369
26370
26371
26372
26373
26374
26375
26376
26377
26378
26379
26380
26381
26382
26383
26384
26385
26386
26387
26388
26389
26390
26391
26392
26393
26394
26395
26396
26397
26398
26399
26400
26401
26402
26403
26404
26405
26406
26407
26408
26409
26410
26411
26412
26413
26414
26415
26416
26417
26418
26419
26420
26421
26422
26423
26424
26425
26426
26427
26428
26429
26430
26431
26432
26433
26434
26435
26436
26437
26438
26439
26440
26441
26442
26443
26444
26445
26446
26447
26448
26449
26450
26451
26452
26453
26454
26455
26456
26457
26458
26459
26460
26461
26462
26463
26464
26465
26466
26467
26468
26469
26470
26471
26472
26473
26474
26475
26476
26477
26478
26479
26480
26481
26482
26483
26484
26485
26486
26487
26488
26489
26490
26491
26492
26493
26494
26495
26496
26497
26498
26499
26500
26501
26502
26503
26504
26505
26506
26507
26508
26509
26510
26511
26512
26513
26514
26515
26516
26517
26518
26519
26520
26521
26522
26523
26524
26525
26526
26527
26528
26529
26530
26531
26532
26533
26534
26535
26536
26537
26538
26539
26540
26541
26542
26543
26544
26545
26546
26547
26548
26549
26550
26551
26552
26553
26554
26555
26556
26557
26558
26559
26560
26561
26562
26563
26564
26565
26566
26567
26568
26569
26570
26571
26572
26573
26574
26575
26576
26577
26578
26579
26580
26581
26582
26583
26584
26585
26586
26587
26588
26589
26590
26591
26592
26593
26594
26595
26596
26597
26598
26599
26600
26601
26602
26603
26604
26605
26606
26607
26608
26609
26610
26611
26612
26613
26614
26615
26616
26617
26618
26619
26620
26621
26622
26623
26624
26625
26626
26627
26628
26629
26630
26631
26632
26633
26634
26635
26636
26637
26638
26639
26640
26641
26642
26643
26644
26645
26646
26647
26648
26649
26650
26651
26652
26653
26654
26655
26656
26657
26658
26659
26660
26661
26662
26663
26664
26665
26666
26667
26668
26669
26670
26671
26672
26673
26674
26675
26676
26677
26678
26679
26680
26681
26682
26683
26684
26685
26686
26687
26688
26689
26690
26691
26692
26693
26694
26695
26696
26697
26698
26699
26700
26701
26702
26703
26704
26705
26706
26707
26708
26709
26710
26711
26712
26713
26714
26715
26716
26717
26718
26719
26720
26721
26722
26723
26724
26725
26726
26727
26728
26729
26730
26731
26732
26733
26734
26735
26736
26737
26738
26739
26740
26741
26742
26743
26744
26745
26746
26747
26748
26749
26750
26751
26752
26753
26754
26755
26756
26757
26758
26759
26760
26761
26762
26763
26764
26765
26766
26767
26768
26769
26770
26771
26772
26773
26774
26775
26776
26777
26778
26779
26780
26781
26782
26783
26784
26785
26786
26787
26788
26789
26790
26791
26792
26793
26794
26795
26796
26797
26798
26799
26800
26801
26802
26803
26804
26805
26806
26807
26808
26809
26810
26811
26812
26813
26814
26815
26816
26817
26818
26819
26820
26821
26822
26823
26824
26825
26826
26827
26828
26829
26830
26831
26832
26833
26834
26835
26836
26837
26838
26839
26840
26841
26842
26843
26844
26845
26846
26847
26848
26849
26850
26851
26852
26853
26854
26855
26856
26857
26858
26859
26860
26861
26862
26863
26864
26865
26866
26867
26868
26869
26870
26871
26872
26873
26874
26875
26876
26877
26878
26879
26880
26881
26882
26883
26884
26885
26886
26887
26888
26889
26890
26891
26892
26893
26894
26895
26896
26897
26898
26899
26900
26901
26902
26903
26904
26905
26906
26907
26908
26909
26910
26911
26912
26913
26914
26915
26916
26917
26918
26919
26920
26921
26922
26923
26924
26925
26926
26927
26928
26929
26930
26931
26932
26933
26934
26935
26936
26937
26938
26939
26940
26941
26942
26943
26944
26945
26946
26947
26948
26949
26950
26951
26952
26953
26954
26955
26956
26957
26958
26959
26960
26961
26962
26963
26964
26965
26966
26967
26968
26969
26970
26971
26972
26973
26974
26975
26976
26977
26978
26979
26980
26981
26982
26983
26984
26985
26986
26987
26988
26989
26990
26991
26992
26993
26994
26995
26996
26997
26998
26999
27000
27001
27002
27003
27004
27005
27006
27007
27008
27009
27010
27011
27012
27013
27014
27015
27016
27017
27018
27019
27020
27021
27022
27023
27024
27025
27026
27027
27028
27029
27030
27031
27032
27033
27034
27035
27036
27037
27038
27039
27040
27041
27042
27043
27044
27045
27046
27047
27048
27049
27050
27051
27052
27053
27054
27055
27056
27057
27058
27059
27060
27061
27062
27063
27064
27065
27066
27067
27068
27069
27070
27071
27072
27073
27074
27075
27076
27077
27078
27079
27080
27081
27082
27083
27084
27085
27086
27087
27088
27089
27090
27091
27092
27093
27094
27095
27096
27097
27098
27099
27100
27101
27102
27103
27104
27105
27106
27107
27108
27109
27110
27111
27112
27113
27114
27115
27116
27117
27118
27119
27120
27121
27122
27123
27124
27125
27126
27127
27128
27129
27130
27131
27132
27133
27134
27135
27136
27137
27138
27139
27140
27141
27142
27143
27144
27145
27146
27147
27148
27149
27150
27151
27152
27153
27154
27155
27156
27157
27158
27159
27160
27161
27162
27163
27164
27165
27166
27167
27168
27169
27170
27171
27172
27173
27174
27175
27176
27177
27178
27179
27180
27181
27182
27183
27184
27185
27186
27187
27188
27189
27190
27191
27192
27193
27194
27195
27196
27197
27198
27199
27200
27201
27202
27203
27204
27205
27206
27207
27208
27209
27210
27211
27212
27213
27214
27215
27216
27217
27218
27219
27220
27221
27222
27223
27224
27225
27226
27227
27228
27229
27230
27231
27232
27233
27234
27235
27236
27237
27238
27239
27240
27241
27242
27243
27244
27245
27246
27247
27248
27249
27250
27251
27252
27253
27254
27255
27256
27257
27258
27259
27260
27261
27262
27263
27264
27265
27266
27267
27268
27269
27270
27271
27272
27273
27274
27275
27276
27277
27278
27279
27280
27281
27282
27283
27284
27285
27286
27287
27288
27289
27290
27291
27292
27293
27294
27295
27296
27297
27298
27299
27300
27301
27302
27303
27304
27305
27306
27307
27308
27309
27310
27311
27312
27313
27314
27315
27316
27317
27318
27319
27320
27321
27322
27323
27324
27325
27326
27327
27328
27329
27330
27331
27332
27333
27334
27335
27336
27337
27338
27339
27340
27341
27342
27343
27344
27345
27346
27347
27348
27349
27350
27351
27352
27353
27354
27355
27356
27357
27358
27359
27360
27361
27362
27363
27364
27365
27366
27367
27368
27369
27370
27371
27372
27373
27374
27375
27376
27377
27378
27379
27380
27381
27382
27383
27384
27385
27386
27387
27388
27389
27390
27391
27392
27393
27394
27395
27396
27397
27398
27399
27400
27401
27402
27403
27404
27405
27406
27407
27408
27409
27410
27411
27412
27413
27414
27415
27416
27417
27418
27419
27420
27421
27422
27423
27424
27425
27426
27427
27428
27429
27430
27431
27432
27433
27434
27435
27436
27437
27438
27439
27440
27441
27442
27443
27444
27445
27446
27447
27448
27449
27450
27451
27452
27453
27454
27455
27456
27457
27458
27459
27460
27461
27462
27463
27464
27465
27466
27467
27468
27469
27470
27471
27472
27473
27474
27475
27476
27477
27478
27479
27480
27481
27482
27483
27484
27485
27486
27487
27488
27489
27490
27491
27492
27493
27494
27495
27496
27497
27498
27499
27500
27501
27502
27503
27504
27505
27506
27507
27508
27509
27510
27511
27512
27513
27514
27515
27516
27517
27518
27519
27520
27521
27522
27523
27524
27525
27526
27527
27528
27529
27530
27531
27532
27533
27534
27535
27536
27537
27538
27539
27540
27541
27542
27543
27544
27545
27546
27547
27548
27549
27550
27551
27552
27553
27554
27555
27556
27557
27558
27559
27560
27561
27562
27563
27564
27565
27566
27567
27568
27569
27570
27571
27572
27573
27574
27575
27576
27577
27578
27579
27580
27581
27582
27583
27584
27585
27586
27587
27588
27589
27590
27591
27592
27593
27594
27595
27596
27597
27598
27599
27600
27601
27602
27603
27604
27605
27606
27607
27608
27609
27610
27611
27612
27613
27614
27615
27616
27617
27618
27619
27620
27621
27622
27623
27624
27625
27626
27627
27628
27629
27630
27631
27632
27633
27634
27635
27636
27637
27638
27639
27640
27641
27642
27643
27644
27645
27646
27647
27648
27649
27650
27651
27652
27653
27654
27655
27656
27657
27658
27659
27660
27661
27662
27663
27664
27665
27666
27667
27668
27669
27670
27671
27672
27673
27674
27675
27676
27677
27678
27679
27680
27681
27682
27683
27684
27685
27686
27687
27688
27689
27690
27691
27692
27693
27694
27695
27696
27697
27698
27699
27700
27701
27702
27703
27704
27705
27706
27707
27708
27709
27710
27711
27712
27713
27714
27715
27716
27717
27718
27719
27720
27721
27722
27723
27724
27725
27726
27727
27728
27729
27730
27731
27732
27733
27734
27735
27736
27737
27738
27739
27740
27741
27742
27743
27744
27745
27746
27747
27748
27749
27750
27751
27752
27753
27754
27755
27756
27757
27758
27759
27760
27761
27762
27763
27764
27765
27766
27767
27768
27769
27770
27771
27772
27773
27774
27775
27776
27777
27778
27779
27780
27781
27782
27783
27784
27785
27786
27787
27788
27789
27790
27791
27792
27793
27794
27795
27796
27797
27798
27799
27800
27801
27802
27803
27804
27805
27806
27807
27808
27809
27810
27811
27812
27813
27814
27815
27816
27817
27818
27819
27820
27821
27822
27823
27824
27825
27826
27827
27828
27829
27830
27831
27832
27833
27834
27835
27836
27837
27838
27839
27840
27841
27842
27843
27844
27845
27846
27847
27848
27849
27850
27851
27852
27853
27854
27855
27856
27857
27858
27859
27860
27861
27862
27863
27864
27865
27866
27867
27868
27869
27870
27871
27872
27873
27874
27875
27876
27877
27878
27879
27880
27881
27882
27883
27884
27885
27886
27887
27888
27889
27890
27891
27892
27893
27894
27895
27896
27897
27898
27899
27900
27901
27902
27903
27904
27905
27906
27907
27908
27909
27910
27911
27912
27913
27914
27915
27916
27917
27918
27919
27920
27921
27922
27923
27924
27925
27926
27927
27928
27929
27930
27931
27932
27933
27934
27935
27936
27937
27938
27939
27940
27941
27942
27943
27944
27945
27946
27947
27948
27949
27950
27951
27952
27953
27954
27955
27956
27957
27958
27959
27960
27961
27962
27963
27964
27965
27966
27967
27968
27969
27970
27971
27972
27973
27974
27975
27976
27977
27978
27979
27980
27981
27982
27983
27984
27985
27986
27987
27988
27989
27990
27991
27992
27993
27994
27995
27996
27997
27998
27999
28000
28001
28002
28003
28004
28005
28006
28007
28008
28009
28010
28011
28012
28013
28014
28015
28016
28017
28018
28019
28020
28021
28022
28023
28024
28025
28026
28027
28028
28029
28030
28031
28032
28033
28034
28035
28036
28037
28038
28039
28040
28041
28042
28043
28044
28045
28046
28047
28048
28049
28050
28051
28052
28053
28054
28055
28056
28057
28058
28059
28060
28061
28062
28063
28064
28065
28066
28067
28068
28069
28070
28071
28072
28073
28074
28075
28076
28077
28078
28079
28080
28081
28082
28083
28084
28085
28086
28087
28088
28089
28090
28091
28092
28093
28094
28095
28096
28097
28098
28099
28100
28101
28102
28103
28104
28105
28106
28107
28108
28109
28110
28111
28112
28113
28114
28115
28116
28117
28118
28119
28120
28121
28122
28123
28124
28125
28126
28127
28128
28129
28130
28131
28132
28133
28134
28135
28136
28137
28138
28139
28140
28141
28142
28143
28144
28145
28146
28147
28148
28149
28150
28151
28152
28153
28154
28155
28156
28157
28158
28159
28160
28161
28162
28163
28164
28165
28166
28167
28168
28169
28170
28171
28172
28173
28174
28175
28176
28177
28178
28179
28180
28181
28182
28183
28184
28185
28186
28187
28188
28189
28190
28191
28192
28193
28194
28195
28196
28197
28198
28199
28200
28201
28202
28203
28204
28205
28206
28207
28208
28209
28210
28211
28212
28213
28214
28215
28216
28217
28218
28219
28220
28221
28222
28223
28224
28225
28226
28227
28228
28229
28230
28231
28232
28233
28234
28235
28236
28237
28238
28239
28240
28241
28242
28243
28244
28245
28246
28247
28248
28249
28250
28251
28252
28253
28254
28255
28256
28257
28258
28259
28260
28261
28262
28263
28264
28265
28266
28267
28268
28269
28270
28271
28272
28273
28274
28275
28276
28277
28278
28279
28280
28281
28282
28283
28284
28285
28286
28287
28288
28289
28290
28291
28292
28293
28294
28295
28296
28297
28298
28299
28300
28301
28302
28303
28304
28305
28306
28307
28308
28309
28310
28311
28312
28313
28314
28315
28316
28317
28318
28319
28320
28321
28322
28323
28324
28325
28326
28327
28328
28329
28330
28331
28332
28333
28334
28335
28336
28337
28338
28339
28340
28341
28342
28343
28344
28345
28346
28347
28348
28349
28350
28351
28352
28353
28354
28355
28356
28357
28358
28359
28360
28361
28362
28363
28364
28365
28366
28367
28368
28369
28370
28371
28372
28373
28374
28375
28376
28377
28378
28379
28380
28381
28382
28383
28384
28385
28386
28387
28388
28389
28390
28391
28392
28393
28394
28395
28396
28397
28398
28399
28400
28401
28402
28403
28404
28405
28406
28407
28408
28409
28410
28411
28412
28413
28414
28415
28416
28417
28418
28419
28420
28421
28422
28423
28424
28425
28426
28427
28428
28429
28430
28431
28432
28433
28434
28435
28436
28437
28438
28439
28440
28441
28442
28443
28444
28445
28446
28447
28448
28449
28450
28451
28452
28453
28454
28455
28456
28457
28458
28459
28460
28461
28462
28463
28464
28465
28466
28467
28468
28469
28470
28471
28472
28473
28474
28475
28476
28477
28478
28479
28480
28481
28482
28483
28484
28485
28486
28487
28488
28489
28490
28491
28492
28493
28494
28495
28496
28497
28498
28499
28500
28501
28502
28503
28504
28505
28506
28507
28508
28509
28510
28511
28512
28513
28514
28515
28516
28517
28518
28519
28520
28521
28522
28523
28524
28525
28526
28527
28528
28529
28530
28531
28532
28533
28534
28535
28536
28537
28538
28539
28540
28541
28542
28543
28544
28545
28546
28547
28548
28549
28550
28551
28552
28553
28554
28555
28556
28557
28558
28559
28560
28561
28562
28563
28564
28565
28566
28567
28568
28569
28570
28571
28572
28573
28574
28575
28576
28577
28578
28579
28580
28581
28582
28583
28584
28585
28586
28587
28588
28589
28590
28591
28592
28593
28594
28595
28596
28597
28598
28599
28600
28601
28602
28603
28604
28605
28606
28607
28608
28609
28610
28611
28612
28613
28614
28615
28616
28617
28618
28619
28620
28621
28622
28623
28624
28625
28626
28627
28628
28629
28630
28631
28632
28633
28634
28635
28636
28637
28638
28639
28640
28641
28642
28643
28644
28645
28646
28647
28648
28649
28650
28651
28652
28653
28654
28655
28656
28657
28658
28659
28660
28661
28662
28663
28664
28665
28666
28667
28668
28669
28670
28671
28672
28673
28674
28675
28676
28677
28678
28679
28680
28681
28682
28683
28684
28685
28686
28687
28688
28689
28690
28691
28692
28693
28694
28695
28696
28697
28698
28699
28700
28701
28702
28703
28704
28705
28706
28707
28708
28709
28710
28711
28712
28713
28714
28715
28716
28717
28718
28719
28720
28721
28722
28723
28724
28725
28726
28727
28728
28729
28730
28731
28732
28733
28734
28735
28736
28737
28738
28739
28740
28741
28742
28743
28744
28745
28746
28747
28748
28749
28750
28751
28752
28753
28754
28755
28756
28757
28758
28759
28760
28761
28762
28763
28764
28765
28766
28767
28768
28769
28770
28771
28772
28773
28774
28775
28776
28777
28778
28779
28780
28781
28782
28783
28784
28785
28786
28787
28788
28789
28790
28791
28792
28793
28794
28795
28796
28797
28798
28799
28800
28801
28802
28803
28804
28805
28806
28807
28808
28809
28810
28811
28812
28813
28814
28815
28816
28817
28818
28819
28820
28821
28822
28823
28824
28825
28826
28827
28828
28829
28830
28831
28832
28833
28834
28835
28836
28837
28838
28839
28840
28841
28842
28843
28844
28845
28846
28847
28848
28849
28850
28851
28852
28853
28854
28855
28856
28857
28858
28859
28860
28861
28862
28863
28864
28865
28866
28867
28868
28869
28870
28871
28872
28873
28874
28875
28876
28877
28878
28879
28880
28881
28882
28883
28884
28885
28886
28887
28888
28889
28890
28891
28892
28893
28894
28895
28896
28897
28898
28899
28900
28901
28902
28903
28904
28905
28906
28907
28908
28909
28910
28911
28912
28913
28914
28915
28916
28917
28918
28919
28920
28921
28922
28923
28924
28925
28926
28927
28928
28929
28930
28931
28932
28933
28934
28935
28936
28937
28938
28939
28940
28941
28942
28943
28944
28945
28946
28947
28948
28949
28950
28951
28952
28953
28954
28955
28956
28957
28958
28959
28960
28961
28962
28963
28964
28965
28966
28967
28968
28969
28970
28971
28972
28973
28974
28975
28976
28977
28978
28979
28980
28981
28982
28983
28984
28985
28986
28987
28988
28989
28990
28991
28992
28993
28994
28995
28996
28997
28998
28999
29000
29001
29002
29003
29004
29005
29006
29007
29008
29009
29010
29011
29012
29013
29014
29015
29016
29017
29018
29019
29020
29021
29022
29023
29024
29025
29026
29027
29028
29029
29030
29031
29032
29033
29034
29035
29036
29037
29038
29039
29040
29041
29042
29043
29044
29045
29046
29047
29048
29049
29050
29051
29052
29053
29054
29055
29056
29057
29058
29059
29060
29061
29062
29063
29064
29065
29066
29067
29068
29069
29070
29071
29072
29073
29074
29075
29076
29077
29078
29079
29080
29081
29082
29083
29084
29085
29086
29087
29088
29089
29090
29091
29092
29093
29094
29095
29096
29097
29098
29099
29100
29101
29102
29103
29104
29105
29106
29107
29108
29109
29110
29111
29112
29113
29114
29115
29116
29117
29118
29119
29120
29121
29122
29123
29124
29125
29126
29127
29128
29129
29130
29131
29132
29133
29134
29135
29136
29137
29138
29139
29140
29141
29142
29143
29144
29145
29146
29147
29148
29149
29150
29151
29152
29153
29154
29155
29156
29157
29158
29159
29160
29161
29162
29163
29164
29165
29166
29167
29168
29169
29170
29171
29172
29173
29174
29175
29176
29177
29178
29179
29180
29181
29182
29183
29184
29185
29186
29187
29188
29189
29190
29191
29192
29193
29194
29195
29196
29197
29198
29199
29200
29201
29202
29203
29204
29205
29206
29207
29208
29209
29210
29211
29212
29213
29214
29215
29216
29217
29218
29219
29220
29221
29222
29223
29224
29225
29226
29227
29228
29229
29230
29231
29232
29233
29234
29235
29236
29237
29238
29239
29240
29241
29242
29243
29244
29245
29246
29247
29248
29249
29250
29251
29252
29253
29254
29255
29256
29257
29258
29259
29260
29261
29262
29263
29264
29265
29266
29267
29268
29269
29270
29271
29272
29273
29274
29275
29276
29277
29278
29279
29280
29281
29282
29283
29284
29285
29286
29287
29288
29289
29290
29291
29292
29293
29294
29295
29296
29297
29298
29299
29300
29301
29302
29303
29304
29305
29306
29307
29308
29309
29310
29311
29312
29313
29314
29315
29316
29317
29318
29319
29320
29321
29322
29323
29324
29325
29326
29327
29328
29329
29330
29331
29332
29333
29334
29335
29336
29337
29338
29339
29340
29341
29342
29343
29344
29345
29346
29347
29348
29349
29350
29351
29352
29353
29354
29355
29356
29357
29358
29359
29360
29361
29362
29363
29364
29365
29366
29367
29368
29369
29370
29371
29372
29373
29374
29375
29376
29377
29378
29379
29380
29381
29382
29383
29384
29385
29386
29387
29388
29389
29390
29391
29392
29393
29394
29395
29396
29397
29398
29399
29400
29401
29402
29403
29404
29405
29406
29407
29408
29409
29410
29411
29412
29413
29414
29415
29416
29417
29418
29419
29420
29421
29422
29423
29424
29425
29426
29427
29428
29429
29430
29431
29432
29433
29434
29435
29436
29437
29438
29439
29440
29441
29442
29443
29444
29445
29446
29447
29448
29449
29450
29451
29452
29453
29454
29455
29456
29457
29458
29459
29460
29461
29462
29463
29464
29465
29466
29467
29468
29469
29470
29471
29472
29473
29474
29475
29476
29477
29478
29479
29480
29481
29482
29483
29484
29485
29486
29487
29488
29489
29490
29491
29492
29493
29494
29495
29496
29497
29498
29499
29500
29501
29502
29503
29504
29505
29506
29507
29508
29509
29510
29511
29512
29513
29514
29515
29516
29517
29518
29519
29520
29521
29522
29523
29524
29525
29526
29527
29528
29529
29530
29531
29532
29533
29534
29535
29536
29537
29538
29539
29540
29541
29542
29543
29544
29545
29546
29547
29548
29549
29550
29551
29552
29553
29554
29555
29556
29557
29558
29559
29560
29561
29562
29563
29564
29565
29566
29567
29568
29569
29570
29571
29572
29573
29574
29575
29576
29577
29578
29579
29580
29581
29582
29583
29584
29585
29586
29587
29588
29589
29590
29591
29592
29593
29594
29595
29596
29597
29598
29599
29600
29601
29602
29603
29604
29605
29606
29607
29608
29609
29610
29611
29612
29613
29614
29615
29616
29617
29618
29619
29620
29621
29622
29623
29624
29625
29626
29627
29628
29629
29630
29631
29632
29633
29634
29635
29636
29637
29638
29639
29640
29641
29642
29643
29644
29645
29646
29647
29648
29649
29650
29651
29652
29653
29654
29655
29656
29657
29658
29659
29660
29661
29662
29663
29664
29665
29666
29667
29668
29669
29670
29671
29672
29673
29674
29675
29676
29677
29678
29679
29680
29681
29682
29683
29684
29685
29686
29687
29688
29689
29690
29691
29692
29693
29694
29695
29696
29697
29698
29699
29700
29701
29702
29703
29704
29705
29706
29707
29708
29709
29710
29711
29712
29713
29714
29715
29716
29717
29718
29719
29720
29721
29722
29723
29724
29725
29726
29727
29728
29729
29730
29731
29732
29733
29734
29735
29736
29737
29738
29739
29740
29741
29742
29743
29744
29745
29746
29747
29748
29749
29750
29751
29752
29753
29754
29755
29756
29757
29758
29759
29760
29761
29762
29763
29764
29765
29766
29767
29768
29769
29770
29771
29772
29773
29774
29775
29776
29777
29778
29779
29780
29781
29782
29783
29784
29785
29786
29787
29788
29789
29790
29791
29792
29793
29794
29795
29796
29797
29798
29799
29800
29801
29802
29803
29804
29805
29806
29807
29808
29809
29810
29811
29812
29813
29814
29815
29816
29817
29818
29819
29820
29821
29822
29823
29824
29825
29826
29827
29828
29829
29830
29831
29832
29833
29834
29835
29836
29837
29838
29839
29840
29841
29842
29843
29844
29845
29846
29847
29848
29849
29850
29851
29852
29853
29854
29855
29856
29857
29858
29859
29860
29861
29862
29863
29864
29865
29866
29867
29868
29869
29870
29871
29872
29873
29874
29875
29876
29877
29878
29879
29880
29881
29882
29883
29884
29885
29886
29887
29888
29889
29890
29891
29892
29893
29894
29895
29896
29897
29898
29899
29900
29901
29902
29903
29904
29905
29906
29907
29908
29909
29910
29911
29912
29913
29914
29915
29916
29917
29918
29919
29920
29921
29922
29923
29924
29925
29926
29927
29928
29929
29930
29931
29932
29933
29934
29935
29936
29937
29938
29939
29940
29941
29942
29943
29944
29945
29946
29947
29948
29949
29950
29951
29952
29953
29954
29955
29956
29957
29958
29959
29960
29961
29962
29963
29964
29965
29966
29967
29968
29969
29970
29971
29972
29973
29974
29975
29976
29977
29978
29979
29980
29981
29982
29983
29984
29985
29986
29987
29988
29989
29990
29991
29992
29993
29994
29995
29996
29997
29998
29999
30000
30001
30002
30003
30004
30005
30006
30007
30008
30009
30010
30011
30012
30013
30014
30015
30016
30017
30018
30019
30020
30021
30022
30023
30024
30025
30026
30027
30028
30029
30030
30031
30032
30033
30034
30035
30036
30037
30038
30039
30040
30041
30042
30043
30044
30045
30046
30047
30048
30049
30050
30051
30052
30053
30054
30055
30056
30057
30058
30059
30060
30061
30062
30063
30064
30065
30066
30067
30068
30069
30070
30071
30072
30073
30074
30075
30076
30077
30078
30079
30080
30081
30082
30083
30084
30085
30086
30087
30088
30089
30090
30091
30092
30093
30094
30095
30096
30097
30098
30099
30100
30101
30102
30103
30104
30105
30106
30107
30108
30109
30110
30111
30112
30113
30114
30115
30116
30117
30118
30119
30120
30121
30122
30123
30124
30125
30126
30127
30128
30129
30130
30131
30132
30133
30134
30135
30136
30137
30138
30139
30140
30141
30142
30143
30144
30145
30146
30147
30148
30149
30150
30151
30152
30153
30154
30155
30156
30157
30158
30159
30160
30161
30162
30163
30164
30165
30166
30167
30168
30169
30170
30171
30172
30173
30174
30175
30176
30177
30178
30179
30180
30181
30182
30183
30184
30185
30186
30187
30188
30189
30190
30191
30192
30193
30194
30195
30196
30197
30198
30199
30200
30201
30202
30203
30204
30205
30206
30207
30208
30209
30210
30211
30212
30213
30214
30215
30216
30217
30218
30219
30220
30221
30222
30223
30224
30225
30226
30227
30228
30229
30230
30231
30232
30233
30234
30235
30236
30237
30238
30239
30240
30241
30242
30243
30244
30245
30246
30247
30248
30249
30250
30251
30252
30253
30254
30255
30256
30257
30258
30259
30260
30261
30262
30263
30264
30265
30266
30267
30268
30269
30270
30271
30272
30273
30274
30275
30276
30277
30278
30279
30280
30281
30282
30283
30284
30285
30286
30287
30288
30289
30290
30291
30292
30293
30294
30295
30296
30297
30298
30299
30300
30301
30302
30303
30304
30305
30306
30307
30308
30309
30310
30311
30312
30313
30314
30315
30316
30317
30318
30319
30320
30321
30322
30323
30324
30325
30326
30327
30328
30329
30330
30331
30332
30333
30334
30335
30336
30337
30338
30339
30340
30341
30342
30343
30344
30345
30346
30347
30348
30349
30350
30351
30352
30353
30354
30355
30356
30357
30358
30359
30360
30361
30362
30363
30364
30365
30366
30367
30368
30369
30370
30371
30372
30373
30374
30375
30376
30377
30378
30379
30380
30381
30382
30383
30384
30385
30386
30387
30388
30389
30390
30391
30392
30393
30394
30395
30396
30397
30398
30399
30400
30401
30402
30403
30404
30405
30406
30407
30408
30409
30410
30411
30412
30413
30414
30415
30416
30417
30418
30419
30420
30421
30422
30423
30424
30425
30426
30427
30428
30429
30430
30431
30432
30433
30434
30435
30436
30437
30438
30439
30440
30441
30442
30443
30444
30445
30446
30447
30448
30449
30450
30451
30452
30453
30454
30455
30456
30457
30458
30459
30460
30461
30462
30463
30464
30465
30466
30467
30468
30469
30470
30471
30472
30473
30474
30475
30476
30477
30478
30479
30480
30481
30482
30483
30484
30485
30486
30487
30488
30489
30490
30491
30492
30493
30494
30495
30496
30497
30498
30499
30500
30501
30502
30503
30504
30505
30506
30507
30508
30509
30510
30511
30512
30513
30514
30515
30516
30517
30518
30519
30520
30521
30522
30523
30524
30525
30526
30527
30528
30529
30530
30531
30532
30533
30534
30535
30536
30537
30538
30539
30540
30541
30542
30543
30544
30545
30546
30547
30548
30549
30550
30551
30552
30553
30554
30555
30556
30557
30558
30559
30560
30561
30562
30563
30564
30565
30566
30567
30568
30569
30570
30571
30572
30573
30574
30575
30576
30577
30578
30579
30580
30581
30582
30583
30584
30585
30586
30587
30588
30589
30590
30591
30592
30593
30594
30595
30596
30597
30598
30599
30600
30601
30602
30603
30604
30605
30606
30607
30608
30609
30610
30611
30612
30613
30614
30615
30616
30617
30618
30619
30620
30621
30622
30623
30624
30625
30626
30627
30628
30629
30630
30631
30632
30633
30634
30635
30636
30637
30638
30639
30640
30641
30642
30643
30644
30645
30646
30647
30648
30649
30650
30651
30652
30653
30654
30655
30656
30657
30658
30659
30660
30661
30662
30663
30664
30665
30666
30667
30668
30669
30670
30671
30672
30673
30674
30675
30676
30677
30678
30679
30680
30681
30682
30683
30684
30685
30686
30687
30688
30689
30690
30691
30692
30693
30694
30695
30696
30697
30698
30699
30700
30701
30702
30703
30704
30705
30706
30707
30708
30709
30710
30711
30712
30713
30714
30715
30716
30717
30718
30719
30720
30721
30722
30723
30724
30725
30726
30727
30728
30729
30730
30731
30732
30733
30734
30735
30736
30737
30738
30739
30740
30741
30742
30743
30744
30745
30746
30747
30748
30749
30750
30751
30752
30753
30754
30755
30756
30757
30758
30759
30760
30761
30762
30763
30764
30765
30766
30767
30768
30769
30770
30771
30772
30773
30774
30775
30776
30777
30778
30779
30780
30781
30782
30783
30784
30785
30786
30787
30788
30789
30790
30791
30792
30793
30794
30795
30796
30797
30798
30799
30800
30801
30802
30803
30804
30805
30806
30807
30808
30809
30810
30811
30812
30813
30814
30815
30816
30817
30818
30819
30820
30821
30822
30823
30824
30825
30826
30827
30828
30829
30830
30831
30832
30833
30834
30835
30836
30837
30838
30839
30840
30841
30842
30843
30844
30845
30846
30847
30848
30849
30850
30851
30852
30853
30854
30855
30856
30857
30858
30859
30860
30861
30862
30863
30864
30865
30866
30867
30868
30869
30870
30871
30872
30873
30874
30875
30876
30877
30878
30879
30880
30881
30882
30883
30884
30885
30886
30887
30888
30889
30890
30891
30892
30893
30894
30895
30896
30897
30898
30899
30900
30901
30902
30903
30904
30905
30906
30907
30908
30909
30910
30911
30912
30913
30914
30915
30916
30917
30918
30919
30920
30921
30922
30923
30924
30925
30926
30927
30928
30929
30930
30931
30932
30933
30934
30935
30936
30937
30938
30939
30940
30941
30942
30943
30944
30945
30946
30947
30948
30949
30950
30951
30952
30953
30954
30955
30956
30957
30958
30959
30960
30961
30962
30963
30964
30965
30966
30967
30968
30969
30970
30971
30972
30973
30974
30975
30976
30977
30978
30979
30980
30981
30982
30983
30984
30985
30986
30987
30988
30989
30990
30991
30992
30993
30994
30995
30996
30997
30998
30999
31000
31001
31002
31003
31004
31005
31006
31007
31008
31009
31010
31011
31012
31013
31014
31015
31016
31017
31018
31019
31020
31021
31022
31023
31024
31025
31026
31027
31028
31029
31030
31031
31032
31033
31034
31035
31036
31037
31038
31039
31040
31041
31042
31043
31044
31045
31046
31047
31048
31049
31050
31051
31052
31053
31054
31055
31056
31057
31058
31059
31060
31061
31062
31063
31064
31065
31066
31067
31068
31069
31070
31071
31072
31073
31074
31075
31076
31077
31078
31079
31080
31081
31082
31083
31084
31085
31086
31087
31088
31089
31090
31091
31092
31093
31094
31095
31096
31097
31098
31099
31100
31101
31102
31103
31104
31105
31106
31107
31108
31109
31110
31111
31112
31113
31114
31115
31116
31117
31118
31119
31120
31121
31122
31123
31124
31125
31126
31127
31128
31129
31130
31131
31132
31133
31134
31135
31136
31137
31138
31139
31140
31141
31142
31143
31144
31145
31146
31147
31148
31149
31150
31151
31152
31153
31154
31155
31156
31157
31158
31159
31160
31161
31162
31163
31164
31165
31166
31167
31168
31169
31170
31171
31172
31173
31174
31175
31176
31177
31178
31179
31180
31181
31182
31183
31184
31185
31186
31187
31188
31189
31190
31191
31192
31193
31194
31195
31196
31197
31198
31199
31200
31201
31202
31203
31204
31205
31206
31207
31208
31209
31210
31211
31212
31213
31214
31215
31216
31217
31218
31219
31220
31221
31222
31223
31224
31225
31226
31227
31228
31229
31230
31231
31232
31233
31234
31235
31236
31237
31238
31239
31240
31241
31242
31243
31244
31245
31246
31247
31248
31249
31250
31251
31252
31253
31254
31255
31256
31257
31258
31259
31260
31261
31262
31263
31264
31265
31266
31267
31268
31269
31270
31271
31272
31273
31274
31275
31276
31277
31278
31279
31280
31281
31282
31283
31284
31285
31286
31287
31288
31289
31290
31291
31292
31293
31294
31295
31296
31297
31298
31299
31300
31301
31302
31303
31304
31305
31306
31307
31308
31309
31310
31311
31312
31313
31314
31315
31316
31317
31318
31319
31320
31321
31322
31323
31324
31325
31326
31327
31328
31329
31330
31331
31332
31333
31334
31335
31336
31337
31338
31339
31340
31341
31342
31343
31344
31345
31346
31347
31348
31349
31350
31351
31352
31353
31354
31355
31356
31357
31358
31359
31360
31361
31362
31363
31364
31365
31366
31367
31368
31369
31370
31371
31372
31373
31374
31375
31376
31377
31378
31379
31380
31381
31382
31383
31384
31385
31386
31387
31388
31389
31390
31391
31392
31393
31394
31395
31396
31397
31398
31399
31400
31401
31402
31403
31404
31405
31406
31407
31408
31409
31410
31411
31412
31413
31414
31415
31416
31417
31418
31419
31420
31421
31422
31423
31424
31425
31426
31427
31428
31429
31430
31431
31432
31433
31434
31435
31436
31437
31438
31439
31440
31441
31442
31443
31444
31445
31446
31447
31448
31449
31450
31451
31452
31453
31454
31455
31456
31457
31458
31459
31460
31461
31462
31463
31464
31465
31466
31467
31468
31469
31470
31471
31472
31473
31474
31475
31476
31477
31478
31479
31480
31481
31482
31483
31484
31485
31486
31487
31488
31489
31490
31491
31492
31493
31494
31495
31496
31497
31498
31499
31500
31501
31502
31503
31504
31505
31506
31507
31508
31509
31510
31511
31512
31513
31514
31515
31516
31517
31518
31519
31520
31521
31522
31523
31524
31525
31526
31527
31528
31529
31530
31531
31532
31533
31534
31535
31536
31537
31538
31539
31540
31541
31542
31543
31544
31545
31546
31547
31548
31549
31550
31551
31552
31553
31554
31555
31556
31557
31558
31559
31560
31561
31562
31563
31564
31565
31566
31567
31568
31569
31570
31571
31572
31573
31574
31575
31576
31577
31578
31579
31580
31581
31582
31583
31584
31585
31586
31587
31588
31589
31590
31591
31592
31593
31594
31595
31596
31597
31598
31599
31600
31601
31602
31603
31604
31605
31606
31607
31608
31609
31610
31611
31612
31613
31614
31615
31616
31617
31618
31619
31620
31621
31622
31623
31624
31625
31626
31627
31628
31629
31630
31631
31632
31633
31634
31635
31636
31637
31638
31639
31640
31641
31642
31643
31644
31645
31646
31647
31648
31649
31650
31651
31652
31653
31654
31655
31656
31657
31658
31659
31660
31661
31662
31663
31664
31665
31666
31667
31668
31669
31670
31671
31672
31673
31674
31675
31676
31677
31678
31679
31680
31681
31682
31683
31684
31685
31686
31687
31688
31689
31690
31691
31692
31693
31694
31695
31696
31697
31698
31699
31700
31701
31702
31703
31704
31705
31706
31707
31708
31709
31710
31711
31712
31713
31714
31715
31716
31717
31718
31719
31720
31721
31722
31723
31724
31725
31726
31727
31728
31729
31730
31731
31732
31733
31734
31735
31736
31737
31738
31739
31740
31741
31742
31743
31744
31745
31746
31747
31748
31749
31750
31751
31752
31753
31754
31755
31756
31757
31758
31759
31760
31761
31762
31763
31764
31765
31766
31767
31768
31769
31770
31771
31772
31773
31774
31775
31776
31777
31778
31779
31780
31781
31782
31783
31784
31785
31786
31787
31788
31789
31790
31791
31792
31793
31794
31795
31796
31797
31798
31799
31800
31801
31802
31803
31804
31805
31806
31807
31808
31809
31810
31811
31812
31813
31814
31815
31816
31817
31818
31819
31820
31821
31822
31823
31824
31825
31826
31827
31828
31829
31830
31831
31832
31833
31834
31835
31836
31837
31838
31839
31840
31841
31842
31843
31844
31845
31846
31847
31848
31849
31850
31851
31852
31853
31854
31855
31856
31857
31858
31859
31860
31861
31862
31863
31864
31865
31866
31867
31868
31869
31870
31871
31872
31873
31874
31875
31876
31877
31878
31879
31880
31881
31882
31883
31884
31885
31886
31887
31888
31889
31890
31891
31892
31893
31894
31895
31896
31897
31898
31899
31900
31901
31902
31903
31904
31905
31906
31907
31908
31909
31910
31911
31912
31913
31914
31915
31916
31917
31918
31919
31920
31921
31922
31923
31924
31925
31926
31927
31928
31929
31930
31931
31932
31933
31934
31935
31936
31937
31938
31939
31940
31941
31942
31943
31944
31945
31946
31947
31948
31949
31950
31951
31952
31953
31954
31955
31956
31957
31958
31959
31960
31961
31962
31963
31964
31965
31966
31967
31968
31969
31970
31971
31972
31973
31974
31975
31976
31977
31978
31979
31980
31981
31982
31983
31984
31985
31986
31987
31988
31989
31990
31991
31992
31993
31994
31995
31996
31997
31998
31999
32000
32001
32002
32003
32004
32005
32006
32007
32008
32009
32010
32011
32012
32013
32014
32015
32016
32017
32018
32019
32020
32021
32022
32023
32024
32025
32026
32027
32028
32029
32030
32031
32032
32033
32034
32035
32036
32037
32038
32039
32040
32041
32042
32043
32044
32045
32046
32047
32048
32049
32050
32051
32052
32053
32054
32055
32056
32057
32058
32059
32060
32061
32062
32063
32064
32065
32066
32067
32068
32069
32070
32071
32072
32073
32074
32075
32076
32077
32078
32079
32080
32081
32082
32083
32084
32085
32086
32087
32088
32089
32090
32091
32092
32093
32094
32095
32096
32097
32098
32099
32100
32101
32102
32103
32104
32105
32106
32107
32108
32109
32110
32111
32112
32113
32114
32115
32116
32117
32118
32119
32120
32121
32122
32123
32124
32125
32126
32127
32128
32129
32130
32131
32132
32133
32134
32135
32136
32137
32138
32139
32140
32141
32142
32143
32144
32145
32146
32147
32148
32149
32150
32151
32152
32153
32154
32155
32156
32157
32158
32159
32160
32161
32162
32163
32164
32165
32166
32167
32168
32169
32170
32171
32172
32173
32174
32175
32176
32177
32178
32179
32180
32181
32182
32183
32184
32185
32186
32187
32188
32189
32190
32191
32192
32193
32194
32195
32196
32197
32198
32199
32200
32201
32202
32203
32204
32205
32206
32207
32208
32209
32210
32211
32212
32213
32214
32215
32216
32217
32218
32219
32220
32221
32222
32223
32224
32225
32226
32227
32228
32229
32230
32231
32232
32233
32234
32235
32236
32237
32238
32239
32240
32241
32242
32243
32244
32245
32246
32247
32248
32249
32250
32251
32252
32253
32254
32255
32256
32257
32258
32259
32260
32261
32262
32263
32264
32265
32266
32267
32268
32269
32270
32271
32272
32273
32274
32275
32276
32277
32278
32279
32280
32281
32282
32283
32284
32285
32286
32287
32288
32289
32290
32291
32292
32293
32294
32295
32296
32297
32298
32299
32300
32301
32302
32303
32304
32305
32306
32307
32308
32309
32310
32311
32312
32313
32314
32315
32316
32317
32318
32319
32320
32321
32322
32323
32324
32325
32326
32327
32328
32329
32330
32331
32332
32333
32334
32335
32336
32337
32338
32339
32340
32341
32342
32343
32344
32345
32346
32347
32348
32349
32350
32351
32352
32353
32354
32355
32356
32357
32358
32359
32360
32361
32362
32363
32364
32365
32366
32367
32368
32369
32370
32371
32372
32373
32374
32375
32376
32377
32378
32379
32380
32381
32382
32383
32384
32385
32386
32387
32388
32389
32390
32391
32392
32393
32394
32395
32396
32397
32398
32399
32400
32401
32402
32403
32404
32405
32406
32407
32408
32409
32410
32411
32412
32413
32414
32415
32416
32417
32418
32419
32420
32421
32422
32423
32424
32425
32426
32427
32428
32429
32430
32431
32432
32433
32434
32435
32436
32437
32438
32439
32440
32441
32442
32443
32444
32445
32446
32447
32448
32449
32450
32451
32452
32453
32454
32455
32456
32457
32458
32459
32460
32461
32462
32463
32464
32465
32466
32467
32468
32469
32470
32471
32472
32473
32474
32475
32476
32477
32478
32479
32480
32481
32482
32483
32484
32485
32486
32487
32488
32489
32490
32491
32492
32493
32494
32495
32496
32497
32498
32499
32500
32501
32502
32503
32504
32505
32506
32507
32508
32509
32510
32511
32512
32513
32514
32515
32516
32517
32518
32519
32520
32521
32522
32523
32524
32525
32526
32527
32528
32529
32530
32531
32532
32533
32534
32535
32536
32537
32538
32539
32540
32541
32542
32543
32544
32545
32546
32547
32548
32549
32550
32551
32552
32553
32554
32555
32556
32557
32558
32559
32560
32561
32562
32563
32564
32565
32566
32567
32568
32569
32570
32571
32572
32573
32574
32575
32576
32577
32578
32579
32580
32581
32582
32583
32584
32585
32586
32587
32588
32589
32590
32591
32592
32593
32594
32595
32596
32597
32598
32599
32600
32601
32602
32603
32604
32605
32606
32607
32608
32609
32610
32611
32612
32613
32614
32615
32616
32617
32618
32619
32620
32621
32622
32623
32624
32625
32626
32627
32628
32629
32630
32631
32632
32633
32634
32635
32636
32637
32638
32639
32640
32641
32642
32643
32644
32645
32646
32647
32648
32649
32650
32651
32652
32653
32654
32655
32656
32657
32658
32659
32660
32661
32662
32663
32664
32665
32666
32667
32668
32669
32670
32671
32672
32673
32674
32675
32676
32677
32678
32679
32680
32681
32682
32683
32684
32685
32686
32687
32688
32689
32690
32691
32692
32693
32694
32695
32696
32697
32698
32699
32700
32701
32702
32703
32704
32705
32706
32707
32708
32709
32710
32711
32712
32713
32714
32715
32716
32717
32718
32719
32720
32721
32722
32723
32724
32725
32726
32727
32728
32729
32730
32731
32732
32733
32734
32735
32736
32737
32738
32739
32740
32741
32742
32743
32744
32745
32746
32747
32748
32749
32750
32751
32752
32753
32754
32755
32756
32757
32758
32759
32760
32761
32762
32763
32764
32765
32766
32767
32768
32769
32770
32771
32772
32773
32774
32775
32776
32777
32778
32779
32780
32781
32782
32783
32784
32785
32786
32787
32788
32789
32790
32791
32792
32793
32794
32795
32796
32797
32798
32799
32800
32801
32802
32803
32804
32805
32806
32807
32808
32809
32810
32811
32812
32813
32814
32815
32816
32817
32818
32819
32820
32821
32822
32823
32824
32825
32826
32827
32828
32829
32830
32831
32832
32833
32834
32835
32836
32837
32838
32839
32840
32841
32842
32843
32844
32845
32846
32847
32848
32849
32850
32851
32852
32853
32854
32855
32856
32857
32858
32859
32860
32861
32862
32863
32864
32865
32866
32867
32868
32869
32870
32871
32872
32873
32874
32875
32876
32877
32878
32879
32880
32881
32882
32883
32884
32885
32886
32887
32888
32889
32890
32891
32892
32893
32894
32895
32896
32897
32898
32899
32900
32901
32902
32903
32904
32905
32906
32907
32908
32909
32910
32911
32912
32913
32914
32915
32916
32917
32918
32919
32920
32921
32922
32923
32924
32925
32926
32927
32928
32929
32930
32931
32932
32933
32934
32935
32936
32937
32938
32939
32940
32941
32942
32943
32944
32945
32946
32947
32948
32949
32950
32951
32952
32953
32954
32955
32956
32957
32958
32959
32960
32961
32962
32963
32964
32965
32966
32967
32968
32969
32970
32971
32972
32973
32974
32975
32976
32977
32978
32979
32980
32981
32982
32983
32984
32985
32986
32987
32988
32989
32990
32991
32992
32993
32994
32995
32996
32997
32998
32999
33000
33001
33002
33003
33004
33005
33006
33007
33008
33009
33010
33011
33012
33013
33014
33015
33016
33017
33018
33019
33020
33021
33022
33023
33024
33025
33026
33027
33028
33029
33030
33031
33032
33033
33034
33035
33036
33037
33038
33039
33040
33041
33042
33043
33044
33045
33046
33047
33048
33049
33050
33051
33052
33053
33054
33055
33056
33057
33058
33059
33060
33061
33062
33063
33064
33065
33066
33067
33068
33069
33070
33071
33072
33073
33074
33075
33076
33077
33078
33079
33080
33081
33082
33083
33084
33085
33086
33087
33088
33089
33090
33091
33092
33093
33094
33095
33096
33097
33098
33099
33100
33101
33102
33103
33104
33105
33106
33107
33108
33109
33110
33111
33112
33113
33114
33115
33116
33117
33118
33119
33120
33121
33122
33123
33124
33125
33126
33127
33128
33129
33130
33131
33132
33133
33134
33135
33136
33137
33138
33139
33140
33141
33142
33143
33144
33145
33146
33147
33148
33149
33150
33151
33152
33153
33154
33155
33156
33157
33158
33159
33160
33161
33162
33163
33164
33165
33166
33167
33168
33169
33170
33171
33172
33173
33174
33175
33176
33177
33178
33179
33180
33181
33182
33183
33184
33185
33186
33187
33188
33189
33190
33191
33192
33193
33194
33195
33196
33197
33198
33199
33200
33201
33202
33203
33204
33205
33206
33207
33208
33209
33210
33211
33212
33213
33214
33215
33216
33217
33218
33219
33220
33221
33222
33223
33224
33225
33226
33227
33228
33229
33230
33231
33232
33233
33234
33235
33236
33237
33238
33239
33240
33241
33242
33243
33244
33245
33246
33247
33248
33249
33250
33251
33252
33253
33254
33255
33256
33257
33258
33259
33260
33261
33262
33263
33264
33265
33266
33267
33268
33269
33270
33271
33272
33273
33274
33275
33276
33277
33278
33279
33280
33281
33282
33283
33284
33285
33286
33287
33288
33289
33290
33291
33292
33293
33294
33295
33296
33297
33298
33299
33300
33301
33302
33303
33304
33305
33306
33307
33308
33309
33310
33311
33312
33313
33314
33315
33316
33317
33318
33319
33320
33321
33322
33323
33324
33325
33326
33327
33328
33329
33330
33331
33332
33333
33334
33335
33336
33337
33338
33339
33340
33341
33342
33343
33344
33345
33346
33347
33348
33349
33350
33351
33352
33353
33354
33355
33356
33357
33358
33359
33360
33361
33362
33363
33364
33365
33366
33367
33368
33369
33370
33371
33372
33373
33374
33375
33376
33377
33378
33379
33380
33381
33382
33383
33384
33385
33386
33387
33388
33389
33390
33391
33392
33393
33394
33395
33396
33397
33398
33399
33400
33401
33402
33403
33404
33405
33406
33407
33408
33409
33410
33411
33412
33413
33414
33415
33416
33417
33418
33419
33420
33421
33422
33423
33424
33425
33426
33427
33428
33429
33430
33431
33432
33433
33434
33435
33436
33437
33438
33439
33440
33441
33442
33443
33444
33445
33446
33447
33448
33449
33450
33451
33452
33453
33454
33455
33456
33457
33458
33459
33460
33461
33462
33463
33464
33465
33466
33467
33468
33469
33470
33471
33472
33473
33474
33475
33476
33477
33478
33479
33480
33481
33482
33483
33484
33485
33486
33487
33488
33489
33490
33491
33492
33493
33494
33495
33496
33497
33498
33499
33500
33501
33502
33503
33504
33505
33506
33507
33508
33509
33510
33511
33512
33513
33514
33515
33516
33517
33518
33519
33520
33521
33522
33523
33524
33525
33526
33527
33528
33529
33530
33531
33532
33533
33534
33535
33536
33537
33538
33539
33540
33541
33542
33543
33544
33545
33546
33547
33548
33549
33550
33551
33552
33553
33554
33555
33556
33557
33558
33559
33560
33561
33562
33563
33564
33565
33566
33567
33568
33569
33570
33571
33572
33573
33574
33575
33576
33577
33578
33579
33580
33581
33582
33583
33584
33585
33586
33587
33588
33589
33590
33591
33592
33593
33594
33595
33596
33597
33598
33599
33600
33601
33602
33603
33604
33605
33606
33607
33608
33609
33610
33611
33612
33613
33614
33615
33616
33617
33618
33619
33620
33621
33622
33623
33624
33625
33626
33627
33628
33629
33630
33631
33632
33633
33634
33635
33636
33637
33638
33639
33640
33641
33642
33643
33644
33645
33646
33647
33648
33649
33650
33651
33652
33653
33654
33655
33656
33657
33658
33659
33660
33661
33662
33663
33664
33665
33666
33667
33668
33669
33670
33671
33672
33673
33674
33675
33676
33677
33678
33679
33680
33681
33682
33683
33684
33685
33686
33687
33688
33689
33690
33691
33692
33693
33694
33695
33696
33697
33698
33699
33700
33701
33702
33703
33704
33705
33706
33707
33708
33709
33710
33711
33712
33713
33714
33715
33716
33717
33718
33719
33720
33721
33722
33723
33724
33725
33726
33727
33728
33729
33730
33731
33732
33733
33734
33735
33736
33737
33738
33739
33740
33741
33742
33743
33744
33745
33746
33747
33748
33749
33750
33751
33752
33753
33754
33755
33756
33757
33758
33759
33760
33761
33762
33763
33764
33765
33766
33767
33768
33769
33770
33771
33772
33773
33774
33775
33776
33777
33778
33779
33780
33781
33782
33783
33784
33785
33786
33787
33788
33789
33790
33791
33792
33793
33794
33795
33796
33797
33798
33799
33800
33801
33802
33803
33804
33805
33806
33807
33808
33809
33810
33811
33812
33813
33814
33815
33816
33817
33818
33819
33820
33821
33822
33823
33824
33825
33826
33827
33828
33829
33830
33831
33832
33833
33834
33835
33836
33837
33838
33839
33840
33841
33842
33843
33844
33845
33846
33847
33848
33849
33850
33851
33852
33853
33854
33855
33856
33857
33858
33859
33860
33861
33862
33863
33864
33865
33866
33867
33868
33869
33870
33871
33872
33873
33874
33875
33876
33877
33878
33879
33880
33881
33882
33883
33884
33885
33886
33887
33888
33889
33890
33891
33892
33893
33894
33895
33896
33897
33898
33899
33900
33901
33902
33903
33904
33905
33906
33907
33908
33909
33910
33911
33912
33913
33914
33915
33916
33917
33918
33919
33920
33921
33922
33923
33924
33925
33926
33927
33928
33929
33930
33931
33932
33933
33934
33935
33936
33937
33938
33939
33940
33941
33942
33943
33944
33945
33946
33947
33948
33949
33950
33951
33952
33953
33954
33955
33956
33957
33958
33959
33960
33961
33962
33963
33964
33965
33966
33967
33968
33969
33970
33971
33972
33973
33974
33975
33976
33977
33978
33979
33980
33981
33982
33983
33984
33985
33986
33987
33988
33989
33990
33991
33992
33993
33994
33995
33996
33997
33998
33999
34000
34001
34002
34003
34004
34005
34006
34007
34008
34009
34010
34011
34012
34013
34014
34015
34016
34017
34018
34019
34020
34021
34022
34023
34024
34025
34026
34027
34028
34029
34030
34031
34032
34033
34034
34035
34036
34037
34038
34039
34040
34041
34042
34043
34044
34045
34046
34047
34048
34049
34050
34051
34052
34053
34054
34055
34056
34057
34058
34059
34060
34061
34062
34063
34064
34065
34066
34067
34068
34069
34070
34071
34072
34073
34074
34075
34076
34077
34078
34079
34080
34081
34082
34083
34084
34085
34086
34087
34088
34089
34090
34091
34092
34093
34094
34095
34096
34097
34098
34099
34100
34101
34102
34103
34104
34105
34106
34107
34108
34109
34110
34111
34112
34113
34114
34115
34116
34117
34118
34119
34120
34121
34122
34123
34124
34125
34126
34127
34128
34129
34130
34131
34132
34133
34134
34135
34136
34137
34138
34139
34140
34141
34142
34143
34144
34145
34146
34147
34148
34149
34150
34151
34152
34153
34154
34155
34156
34157
34158
34159
34160
34161
34162
34163
34164
34165
34166
34167
34168
34169
34170
34171
34172
34173
34174
34175
34176
34177
34178
34179
34180
34181
34182
34183
34184
34185
34186
34187
34188
34189
34190
34191
34192
34193
34194
34195
34196
34197
34198
34199
34200
34201
34202
34203
34204
34205
34206
34207
34208
34209
34210
34211
34212
34213
34214
34215
34216
34217
34218
34219
34220
34221
34222
34223
34224
34225
34226
34227
34228
34229
34230
34231
34232
34233
34234
34235
34236
34237
34238
34239
34240
34241
34242
34243
34244
34245
34246
34247
34248
34249
34250
34251
34252
34253
34254
34255
34256
34257
34258
34259
34260
34261
34262
34263
34264
34265
34266
34267
34268
34269
34270
34271
34272
34273
34274
34275
34276
34277
34278
34279
34280
34281
34282
34283
34284
34285
34286
34287
34288
34289
34290
34291
34292
34293
34294
34295
34296
34297
34298
34299
34300
34301
34302
34303
34304
34305
34306
34307
34308
34309
34310
34311
34312
34313
34314
34315
34316
34317
34318
34319
34320
34321
34322
34323
34324
34325
34326
34327
34328
34329
34330
34331
34332
34333
34334
34335
34336
34337
34338
34339
34340
34341
34342
34343
34344
34345
34346
34347
34348
34349
34350
34351
34352
34353
34354
34355
34356
34357
34358
34359
34360
34361
34362
34363
34364
34365
34366
34367
34368
34369
34370
34371
34372
34373
34374
34375
34376
34377
34378
34379
34380
34381
34382
34383
34384
34385
34386
34387
34388
34389
34390
34391
34392
34393
34394
34395
34396
34397
34398
34399
34400
34401
34402
34403
34404
34405
34406
34407
34408
34409
34410
34411
34412
34413
34414
34415
34416
34417
34418
34419
34420
34421
34422
34423
34424
34425
34426
34427
34428
34429
34430
34431
34432
34433
34434
34435
34436
34437
34438
34439
34440
34441
34442
34443
34444
34445
34446
34447
34448
34449
34450
34451
34452
34453
34454
34455
34456
34457
34458
34459
34460
34461
34462
34463
34464
34465
34466
34467
34468
34469
34470
34471
34472
34473
34474
34475
34476
34477
34478
34479
34480
34481
34482
34483
34484
34485
34486
34487
34488
34489
34490
34491
34492
34493
34494
34495
34496
34497
34498
34499
34500
34501
34502
34503
34504
34505
34506
34507
34508
34509
34510
34511
34512
34513
34514
34515
34516
34517
34518
34519
34520
34521
34522
34523
34524
34525
34526
34527
34528
34529
34530
34531
34532
34533
34534
34535
34536
34537
34538
34539
34540
34541
34542
34543
34544
34545
34546
34547
34548
34549
34550
34551
34552
34553
34554
34555
34556
34557
34558
34559
34560
34561
34562
34563
34564
34565
34566
34567
34568
34569
34570
34571
34572
34573
34574
34575
34576
34577
34578
34579
34580
34581
34582
34583
34584
34585
34586
34587
34588
34589
34590
34591
34592
34593
34594
34595
34596
34597
34598
34599
34600
34601
34602
34603
34604
34605
34606
34607
34608
34609
34610
34611
34612
34613
34614
34615
34616
34617
34618
34619
34620
34621
34622
34623
34624
34625
34626
34627
34628
34629
34630
34631
34632
34633
34634
34635
34636
34637
34638
34639
34640
34641
34642
34643
34644
34645
34646
34647
34648
34649
34650
34651
34652
34653
34654
34655
34656
34657
34658
34659
34660
34661
34662
34663
34664
34665
34666
34667
34668
34669
34670
34671
34672
34673
34674
34675
34676
34677
34678
34679
34680
34681
34682
34683
34684
34685
34686
34687
34688
34689
34690
34691
34692
34693
34694
34695
34696
34697
34698
34699
34700
34701
34702
34703
34704
34705
34706
34707
34708
34709
34710
34711
34712
34713
34714
34715
34716
34717
34718
34719
34720
34721
34722
34723
34724
34725
34726
34727
34728
34729
34730
34731
34732
34733
34734
34735
34736
34737
34738
34739
34740
34741
34742
34743
34744
34745
34746
34747
34748
34749
34750
34751
34752
34753
34754
34755
34756
34757
34758
34759
34760
34761
34762
34763
34764
34765
34766
34767
34768
34769
34770
34771
34772
34773
34774
34775
34776
34777
34778
34779
34780
34781
34782
34783
34784
34785
34786
34787
34788
34789
34790
34791
34792
34793
34794
34795
34796
34797
34798
34799
34800
34801
34802
34803
34804
34805
34806
34807
34808
34809
34810
34811
34812
34813
34814
34815
34816
34817
34818
34819
34820
34821
34822
34823
34824
34825
34826
34827
34828
34829
34830
34831
34832
34833
34834
34835
34836
34837
34838
34839
34840
34841
34842
34843
34844
34845
34846
34847
34848
34849
34850
34851
34852
34853
34854
34855
34856
34857
34858
34859
34860
34861
34862
34863
34864
34865
34866
34867
34868
34869
34870
34871
34872
34873
34874
34875
34876
34877
34878
34879
34880
34881
34882
34883
34884
34885
34886
34887
34888
34889
34890
34891
34892
34893
34894
34895
34896
34897
34898
34899
34900
34901
34902
34903
34904
34905
34906
34907
34908
34909
34910
34911
34912
34913
34914
34915
34916
34917
34918
34919
34920
34921
34922
34923
34924
34925
34926
34927
34928
34929
34930
34931
34932
34933
34934
34935
34936
34937
34938
34939
34940
34941
34942
34943
34944
34945
34946
34947
34948
34949
34950
34951
34952
34953
34954
34955
34956
34957
34958
34959
34960
34961
34962
34963
34964
34965
34966
34967
34968
34969
34970
34971
34972
34973
34974
34975
34976
34977
34978
34979
34980
34981
34982
34983
34984
34985
34986
34987
34988
34989
34990
34991
34992
34993
34994
34995
34996
34997
34998
34999
35000
35001
35002
35003
35004
35005
35006
35007
35008
35009
35010
35011
35012
35013
35014
35015
35016
35017
35018
35019
35020
35021
35022
35023
35024
35025
35026
35027
35028
35029
35030
35031
35032
35033
35034
35035
35036
35037
35038
35039
35040
35041
35042
35043
35044
35045
35046
35047
35048
35049
35050
35051
35052
35053
35054
35055
35056
35057
35058
35059
35060
35061
35062
35063
35064
35065
35066
35067
35068
35069
35070
35071
35072
35073
35074
35075
35076
35077
35078
35079
35080
35081
35082
35083
35084
35085
35086
35087
35088
35089
35090
35091
35092
35093
35094
35095
35096
35097
35098
35099
35100
35101
35102
35103
35104
35105
35106
35107
35108
35109
35110
35111
35112
35113
35114
35115
35116
35117
35118
35119
35120
35121
35122
35123
35124
35125
35126
35127
35128
35129
35130
35131
35132
35133
35134
35135
35136
35137
35138
35139
35140
35141
35142
35143
35144
35145
35146
35147
35148
35149
35150
35151
35152
35153
35154
35155
35156
35157
35158
35159
35160
35161
35162
35163
35164
35165
35166
35167
35168
35169
35170
35171
35172
35173
35174
35175
35176
35177
35178
35179
35180
35181
35182
35183
35184
35185
35186
35187
35188
35189
35190
35191
35192
35193
35194
35195
35196
35197
35198
35199
35200
35201
35202
35203
35204
35205
35206
35207
35208
35209
35210
35211
35212
35213
35214
35215
35216
35217
35218
35219
35220
35221
35222
35223
35224
35225
35226
35227
35228
35229
35230
35231
35232
35233
35234
35235
35236
35237
35238
35239
35240
35241
35242
35243
35244
35245
35246
35247
35248
35249
35250
35251
35252
35253
35254
35255
35256
35257
35258
35259
35260
35261
35262
35263
35264
35265
35266
35267
35268
35269
35270
35271
35272
35273
35274
35275
35276
35277
35278
35279
35280
35281
35282
35283
35284
35285
35286
35287
35288
35289
35290
35291
35292
35293
35294
35295
35296
35297
35298
35299
35300
35301
35302
35303
35304
35305
35306
35307
35308
35309
35310
35311
35312
35313
35314
35315
35316
35317
35318
35319
35320
35321
35322
35323
35324
35325
35326
35327
35328
35329
35330
35331
35332
35333
35334
35335
35336
35337
35338
35339
35340
35341
35342
35343
35344
35345
35346
35347
35348
35349
35350
35351
35352
35353
35354
35355
35356
35357
35358
35359
35360
35361
35362
35363
35364
35365
35366
35367
35368
35369
35370
35371
35372
35373
35374
35375
35376
35377
35378
35379
35380
35381
35382
35383
35384
35385
35386
35387
35388
35389
35390
35391
35392
35393
35394
35395
35396
35397
35398
35399
35400
35401
35402
35403
35404
35405
35406
35407
35408
35409
35410
35411
35412
35413
35414
35415
35416
35417
35418
35419
35420
35421
35422
35423
35424
35425
35426
35427
35428
35429
35430
35431
35432
35433
35434
35435
35436
35437
35438
35439
35440
35441
35442
35443
35444
35445
35446
35447
35448
35449
35450
35451
35452
35453
35454
35455
35456
35457
35458
35459
35460
35461
35462
35463
35464
35465
35466
35467
35468
35469
35470
35471
35472
35473
35474
35475
35476
35477
35478
35479
35480
35481
35482
35483
35484
35485
35486
35487
35488
35489
35490
35491
35492
35493
35494
35495
35496
35497
35498
35499
35500
35501
35502
35503
35504
35505
35506
35507
35508
35509
35510
35511
35512
35513
35514
35515
35516
35517
35518
35519
35520
35521
35522
35523
35524
35525
35526
35527
35528
35529
35530
35531
35532
35533
35534
35535
35536
35537
35538
35539
35540
35541
35542
35543
35544
35545
35546
35547
35548
35549
35550
35551
35552
35553
35554
35555
35556
35557
35558
35559
35560
35561
35562
35563
35564
35565
35566
35567
35568
35569
35570
35571
35572
35573
35574
35575
35576
35577
35578
35579
35580
35581
35582
35583
35584
35585
35586
35587
35588
35589
35590
35591
35592
35593
35594
35595
35596
35597
35598
35599
35600
35601
35602
35603
35604
35605
35606
35607
35608
35609
35610
35611
35612
35613
35614
35615
35616
35617
35618
35619
35620
35621
35622
35623
35624
35625
35626
35627
35628
35629
35630
35631
35632
35633
35634
35635
35636
35637
35638
35639
35640
35641
35642
35643
35644
35645
35646
35647
35648
35649
35650
35651
35652
35653
35654
35655
35656
35657
35658
35659
35660
35661
35662
35663
35664
35665
35666
35667
35668
35669
35670
35671
35672
35673
35674
35675
35676
35677
35678
35679
35680
35681
35682
35683
35684
35685
35686
35687
35688
35689
35690
35691
35692
35693
35694
35695
35696
35697
35698
35699
35700
35701
35702
35703
35704
35705
35706
35707
35708
35709
35710
35711
35712
35713
35714
35715
35716
35717
35718
35719
35720
35721
35722
35723
35724
35725
35726
35727
35728
35729
35730
35731
35732
35733
35734
35735
35736
35737
35738
35739
35740
35741
35742
35743
35744
35745
35746
35747
35748
35749
35750
35751
35752
35753
35754
35755
35756
35757
35758
35759
35760
35761
35762
35763
35764
35765
35766
35767
35768
35769
35770
35771
35772
35773
35774
35775
35776
35777
35778
35779
35780
35781
35782
35783
35784
35785
35786
35787
35788
35789
35790
35791
35792
35793
35794
35795
35796
35797
35798
35799
35800
35801
35802
35803
35804
35805
35806
35807
35808
35809
35810
35811
35812
35813
35814
35815
35816
35817
35818
35819
35820
35821
35822
35823
35824
35825
35826
35827
35828
35829
35830
35831
35832
35833
35834
35835
35836
35837
35838
35839
35840
35841
35842
35843
35844
35845
35846
35847
35848
35849
35850
35851
35852
35853
35854
35855
35856
35857
35858
35859
35860
35861
35862
35863
35864
35865
35866
35867
35868
35869
35870
35871
35872
35873
35874
35875
35876
35877
35878
35879
35880
35881
35882
35883
35884
35885
35886
35887
35888
35889
35890
35891
35892
35893
35894
35895
35896
35897
35898
35899
35900
35901
35902
35903
35904
35905
35906
35907
35908
35909
35910
35911
35912
35913
35914
35915
35916
35917
35918
35919
35920
35921
35922
35923
35924
35925
35926
35927
35928
35929
35930
35931
35932
35933
35934
35935
35936
35937
35938
35939
35940
35941
35942
35943
35944
35945
35946
35947
35948
35949
35950
35951
35952
35953
35954
35955
35956
35957
35958
35959
35960
35961
35962
35963
35964
35965
35966
35967
35968
35969
35970
35971
35972
35973
35974
35975
35976
35977
35978
35979
35980
35981
35982
35983
35984
35985
35986
35987
35988
35989
35990
35991
35992
35993
35994
35995
35996
35997
35998
35999
36000
36001
36002
36003
36004
36005
36006
36007
36008
36009
36010
36011
36012
36013
36014
36015
36016
36017
36018
36019
36020
36021
36022
36023
36024
36025
36026
36027
36028
36029
36030
36031
36032
36033
36034
36035
36036
36037
36038
36039
36040
36041
36042
36043
36044
36045
36046
36047
36048
36049
36050
36051
36052
36053
36054
36055
36056
36057
36058
36059
36060
36061
36062
36063
36064
36065
36066
36067
36068
36069
36070
36071
36072
36073
36074
36075
36076
36077
36078
36079
36080
36081
36082
36083
36084
36085
36086
36087
36088
36089
36090
36091
36092
36093
36094
36095
36096
36097
36098
36099
36100
36101
36102
36103
36104
36105
36106
36107
36108
36109
36110
36111
36112
36113
36114
36115
36116
36117
36118
36119
36120
36121
36122
36123
36124
36125
36126
36127
36128
36129
36130
36131
36132
36133
36134
36135
36136
36137
36138
36139
36140
36141
36142
36143
36144
36145
36146
36147
36148
36149
36150
36151
36152
36153
36154
36155
36156
36157
36158
36159
36160
36161
36162
36163
36164
36165
36166
36167
36168
36169
36170
36171
36172
36173
36174
36175
36176
36177
36178
36179
36180
36181
36182
36183
36184
36185
36186
36187
36188
36189
36190
36191
36192
36193
36194
36195
36196
36197
36198
36199
36200
36201
36202
36203
36204
36205
36206
36207
36208
36209
36210
36211
36212
36213
36214
36215
36216
36217
36218
36219
36220
36221
36222
36223
36224
36225
36226
36227
36228
36229
36230
36231
36232
36233
36234
36235
36236
36237
36238
36239
36240
36241
36242
36243
36244
36245
36246
36247
36248
36249
36250
36251
36252
36253
36254
36255
36256
36257
36258
36259
36260
36261
36262
36263
36264
36265
36266
36267
36268
36269
36270
36271
36272
36273
36274
36275
36276
36277
36278
36279
36280
36281
36282
36283
36284
36285
36286
36287
36288
36289
36290
36291
36292
36293
36294
36295
36296
36297
36298
36299
36300
36301
36302
36303
36304
36305
36306
36307
36308
36309
36310
36311
36312
36313
36314
36315
36316
36317
36318
36319
36320
36321
36322
36323
36324
36325
36326
36327
36328
36329
36330
36331
36332
36333
36334
36335
36336
36337
36338
36339
36340
36341
36342
36343
36344
36345
36346
36347
36348
36349
36350
36351
36352
36353
36354
36355
36356
36357
36358
36359
36360
36361
36362
36363
36364
36365
36366
36367
36368
36369
36370
36371
36372
36373
36374
36375
36376
36377
36378
36379
36380
36381
36382
36383
36384
36385
36386
36387
36388
36389
36390
36391
36392
36393
36394
36395
36396
36397
36398
36399
36400
36401
36402
36403
36404
36405
36406
36407
36408
36409
36410
36411
36412
36413
36414
36415
36416
36417
36418
36419
36420
36421
36422
36423
36424
36425
36426
36427
36428
36429
36430
36431
36432
36433
36434
36435
36436
36437
36438
36439
36440
36441
36442
36443
36444
36445
36446
36447
36448
36449
36450
36451
36452
36453
36454
36455
36456
36457
36458
36459
36460
36461
36462
36463
36464
36465
36466
36467
36468
36469
36470
36471
36472
36473
36474
36475
36476
36477
36478
36479
36480
36481
36482
36483
36484
36485
36486
36487
36488
36489
36490
36491
36492
36493
36494
36495
36496
36497
36498
36499
36500
36501
36502
36503
36504
36505
36506
36507
36508
36509
36510
36511
36512
36513
36514
36515
36516
36517
36518
36519
36520
36521
36522
36523
36524
36525
36526
36527
36528
36529
36530
36531
36532
36533
36534
36535
36536
36537
36538
36539
36540
36541
36542
36543
36544
36545
36546
36547
36548
36549
36550
36551
36552
36553
36554
36555
36556
36557
36558
36559
36560
36561
36562
36563
36564
36565
36566
36567
36568
36569
36570
36571
36572
36573
36574
36575
36576
36577
36578
36579
36580
36581
36582
36583
36584
36585
36586
36587
36588
36589
36590
36591
36592
36593
36594
36595
36596
36597
36598
36599
36600
36601
36602
36603
36604
36605
36606
36607
36608
36609
36610
36611
36612
36613
36614
36615
36616
36617
36618
36619
36620
36621
36622
36623
36624
36625
36626
36627
36628
36629
36630
36631
36632
36633
36634
36635
36636
36637
36638
36639
36640
36641
36642
36643
36644
36645
36646
36647
36648
36649
36650
36651
36652
36653
36654
36655
36656
36657
36658
36659
36660
36661
36662
36663
36664
36665
36666
36667
36668
36669
36670
36671
36672
36673
36674
36675
36676
36677
36678
36679
36680
36681
36682
36683
36684
36685
36686
36687
36688
36689
36690
36691
36692
36693
36694
36695
36696
36697
36698
36699
36700
36701
36702
36703
36704
36705
36706
36707
36708
36709
36710
36711
36712
36713
36714
36715
36716
36717
36718
36719
36720
36721
36722
36723
36724
36725
36726
36727
36728
36729
36730
36731
36732
36733
36734
36735
36736
36737
36738
36739
36740
36741
36742
36743
36744
36745
36746
36747
36748
36749
36750
36751
36752
36753
36754
36755
36756
36757
36758
36759
36760
36761
36762
36763
36764
36765
36766
36767
36768
36769
36770
36771
36772
36773
36774
36775
36776
36777
36778
36779
36780
36781
36782
36783
36784
36785
36786
36787
36788
36789
36790
36791
36792
36793
36794
36795
36796
36797
36798
36799
36800
36801
36802
36803
36804
36805
36806
36807
36808
36809
36810
36811
36812
36813
36814
36815
36816
36817
36818
36819
36820
36821
36822
36823
36824
36825
36826
36827
36828
36829
36830
36831
36832
36833
36834
36835
36836
36837
36838
36839
36840
36841
36842
36843
36844
36845
36846
36847
36848
36849
36850
36851
36852
36853
36854
36855
36856
36857
36858
36859
36860
36861
36862
36863
36864
36865
36866
36867
36868
36869
36870
36871
36872
36873
36874
36875
36876
36877
36878
36879
36880
36881
36882
36883
36884
36885
36886
36887
36888
36889
36890
36891
36892
36893
36894
36895
36896
36897
36898
36899
36900
36901
36902
36903
36904
36905
36906
36907
36908
36909
36910
36911
36912
36913
36914
36915
36916
36917
36918
36919
36920
36921
36922
36923
36924
36925
36926
36927
36928
36929
36930
36931
36932
36933
36934
36935
36936
36937
36938
36939
36940
36941
36942
36943
36944
36945
36946
36947
36948
36949
36950
36951
36952
36953
36954
36955
36956
36957
36958
36959
36960
36961
36962
36963
36964
36965
36966
36967
36968
36969
36970
36971
36972
36973
36974
36975
36976
36977
36978
36979
36980
36981
36982
36983
36984
36985
36986
36987
36988
36989
36990
36991
36992
36993
36994
36995
36996
36997
36998
36999
37000
37001
37002
37003
37004
37005
37006
37007
37008
37009
37010
37011
37012
37013
37014
37015
37016
37017
37018
37019
37020
37021
37022
37023
37024
37025
37026
37027
37028
37029
37030
37031
37032
37033
37034
37035
37036
37037
37038
37039
37040
37041
37042
37043
37044
37045
37046
37047
37048
37049
37050
37051
37052
37053
37054
37055
37056
37057
37058
37059
37060
37061
37062
37063
37064
37065
37066
37067
37068
37069
37070
37071
37072
37073
37074
37075
37076
37077
37078
37079
37080
37081
37082
37083
37084
37085
37086
37087
37088
37089
37090
37091
37092
37093
37094
37095
37096
37097
37098
37099
37100
37101
37102
37103
37104
37105
37106
37107
37108
37109
37110
37111
37112
37113
37114
37115
37116
37117
37118
37119
37120
37121
37122
37123
37124
37125
37126
37127
37128
37129
37130
37131
37132
37133
37134
37135
37136
37137
37138
37139
37140
37141
37142
37143
37144
37145
37146
37147
37148
37149
37150
37151
37152
37153
37154
37155
37156
37157
37158
37159
37160
37161
37162
37163
37164
37165
37166
37167
37168
37169
37170
37171
37172
37173
37174
37175
37176
37177
37178
37179
37180
37181
37182
37183
37184
37185
37186
37187
37188
37189
37190
37191
37192
37193
37194
37195
37196
37197
37198
37199
37200
37201
37202
37203
37204
37205
37206
37207
37208
37209
37210
37211
37212
37213
37214
37215
37216
37217
37218
37219
37220
37221
37222
37223
37224
37225
37226
37227
37228
37229
37230
37231
37232
37233
37234
37235
37236
37237
37238
37239
37240
37241
37242
37243
37244
37245
37246
37247
37248
37249
37250
37251
37252
37253
37254
37255
37256
37257
37258
37259
37260
37261
37262
37263
37264
37265
37266
37267
37268
37269
37270
37271
37272
37273
37274
37275
37276
37277
37278
37279
37280
37281
37282
37283
37284
37285
37286
37287
37288
37289
37290
37291
37292
37293
37294
37295
37296
37297
37298
37299
37300
37301
37302
37303
37304
37305
37306
37307
37308
37309
37310
37311
37312
37313
37314
37315
37316
37317
37318
37319
37320
37321
37322
37323
37324
37325
37326
37327
37328
37329
37330
37331
37332
37333
37334
37335
37336
37337
37338
37339
37340
37341
37342
37343
37344
37345
37346
37347
37348
37349
37350
37351
37352
37353
37354
37355
37356
37357
37358
37359
37360
37361
37362
37363
37364
37365
37366
37367
37368
37369
37370
37371
37372
37373
37374
37375
37376
37377
37378
37379
37380
37381
37382
37383
37384
37385
37386
37387
37388
37389
37390
37391
37392
37393
37394
37395
37396
37397
37398
37399
37400
37401
37402
37403
37404
37405
37406
37407
37408
37409
37410
37411
37412
37413
37414
37415
37416
37417
37418
37419
37420
37421
37422
37423
37424
37425
37426
37427
37428
37429
37430
37431
37432
37433
37434
37435
37436
37437
37438
37439
37440
37441
37442
37443
37444
37445
37446
37447
37448
37449
37450
37451
37452
37453
37454
37455
37456
37457
37458
37459
37460
37461
37462
37463
37464
37465
37466
37467
37468
37469
37470
37471
37472
37473
37474
37475
37476
37477
37478
37479
37480
37481
37482
37483
37484
37485
37486
37487
37488
37489
37490
37491
37492
37493
37494
37495
37496
37497
37498
37499
37500
37501
37502
37503
37504
37505
37506
37507
37508
37509
37510
37511
37512
37513
37514
37515
37516
37517
37518
37519
37520
37521
37522
37523
37524
37525
37526
37527
37528
37529
37530
37531
37532
37533
37534
37535
37536
37537
37538
37539
37540
37541
37542
37543
37544
37545
37546
37547
37548
37549
37550
37551
37552
37553
37554
37555
37556
37557
37558
37559
37560
37561
37562
37563
37564
37565
37566
37567
37568
37569
37570
37571
37572
37573
37574
37575
37576
37577
37578
37579
37580
37581
37582
37583
37584
37585
37586
37587
37588
37589
37590
37591
37592
37593
37594
37595
37596
37597
37598
37599
37600
37601
37602
37603
37604
37605
37606
37607
37608
37609
37610
37611
37612
37613
37614
37615
37616
37617
37618
37619
37620
37621
37622
37623
37624
37625
37626
37627
37628
37629
37630
37631
37632
37633
37634
37635
37636
37637
37638
37639
37640
37641
37642
37643
37644
37645
37646
37647
37648
37649
37650
37651
37652
37653
37654
37655
37656
37657
37658
37659
37660
37661
37662
37663
37664
37665
37666
37667
37668
37669
37670
37671
37672
37673
37674
37675
37676
37677
37678
37679
37680
37681
37682
37683
37684
37685
37686
37687
37688
37689
37690
37691
37692
37693
37694
37695
37696
37697
37698
37699
37700
37701
37702
37703
37704
37705
37706
37707
37708
37709
37710
37711
37712
37713
37714
37715
37716
37717
37718
37719
37720
37721
37722
37723
37724
37725
37726
37727
37728
37729
37730
37731
37732
37733
37734
37735
37736
37737
37738
37739
37740
37741
37742
37743
37744
37745
37746
37747
37748
37749
37750
37751
37752
37753
37754
37755
37756
37757
37758
37759
37760
37761
37762
37763
37764
37765
37766
37767
37768
37769
37770
37771
37772
37773
37774
37775
37776
37777
37778
37779
37780
37781
37782
37783
37784
37785
37786
37787
37788
37789
37790
37791
37792
37793
37794
37795
37796
37797
37798
37799
37800
37801
37802
37803
37804
37805
37806
37807
37808
37809
37810
37811
37812
37813
37814
37815
37816
37817
37818
37819
37820
37821
37822
37823
37824
37825
37826
37827
37828
37829
37830
37831
37832
37833
37834
37835
37836
37837
37838
37839
37840
37841
37842
37843
37844
37845
37846
37847
37848
37849
37850
37851
37852
37853
37854
37855
37856
37857
37858
37859
37860
37861
37862
37863
37864
37865
37866
37867
37868
37869
37870
37871
37872
37873
37874
37875
37876
37877
37878
37879
37880
37881
37882
37883
37884
37885
37886
37887
37888
37889
37890
37891
37892
37893
37894
37895
37896
37897
37898
37899
37900
37901
37902
37903
37904
37905
37906
37907
37908
37909
37910
37911
37912
37913
37914
37915
37916
37917
37918
37919
37920
37921
37922
37923
37924
37925
37926
37927
37928
37929
37930
37931
37932
37933
37934
37935
37936
37937
37938
37939
37940
37941
37942
37943
37944
37945
37946
37947
37948
37949
37950
37951
37952
37953
37954
37955
37956
37957
37958
37959
37960
37961
37962
37963
37964
37965
37966
37967
37968
37969
37970
37971
37972
37973
37974
37975
37976
37977
37978
37979
37980
37981
37982
37983
37984
37985
37986
37987
37988
37989
37990
37991
37992
37993
37994
37995
37996
37997
37998
37999
38000
38001
38002
38003
38004
38005
38006
38007
38008
38009
38010
38011
38012
38013
38014
38015
38016
38017
38018
38019
38020
38021
38022
38023
38024
38025
38026
38027
38028
38029
38030
38031
38032
38033
38034
38035
38036
38037
38038
38039
38040
38041
38042
38043
38044
38045
38046
38047
38048
38049
38050
38051
38052
38053
38054
38055
38056
38057
38058
38059
38060
38061
38062
38063
38064
38065
38066
38067
38068
38069
38070
38071
38072
38073
38074
38075
38076
38077
38078
38079
38080
38081
38082
38083
38084
38085
38086
38087
38088
38089
38090
38091
38092
38093
38094
38095
38096
38097
38098
38099
38100
38101
38102
38103
38104
38105
38106
38107
38108
38109
38110
38111
38112
38113
38114
38115
38116
38117
38118
38119
38120
38121
38122
38123
38124
38125
38126
38127
38128
38129
38130
38131
38132
38133
38134
38135
38136
38137
38138
38139
38140
38141
38142
38143
38144
38145
38146
38147
38148
38149
38150
38151
38152
38153
38154
38155
38156
38157
38158
38159
38160
38161
38162
38163
38164
38165
38166
38167
38168
38169
38170
38171
38172
38173
38174
38175
38176
38177
38178
38179
38180
38181
38182
38183
38184
38185
38186
38187
38188
38189
38190
38191
38192
38193
38194
38195
38196
38197
38198
38199
38200
38201
38202
38203
38204
38205
38206
38207
38208
38209
38210
38211
38212
38213
38214
38215
38216
38217
38218
38219
38220
38221
38222
38223
38224
38225
38226
38227
38228
38229
38230
38231
38232
38233
38234
38235
38236
38237
38238
38239
38240
38241
38242
38243
38244
38245
38246
38247
38248
38249
38250
38251
38252
38253
38254
38255
38256
38257
38258
38259
38260
38261
38262
38263
38264
38265
38266
38267
38268
38269
38270
38271
38272
38273
38274
38275
38276
38277
38278
38279
38280
38281
38282
38283
38284
38285
38286
38287
38288
38289
38290
38291
38292
38293
38294
38295
38296
38297
38298
38299
38300
38301
38302
38303
38304
38305
38306
38307
38308
38309
38310
38311
38312
38313
38314
38315
38316
38317
38318
38319
38320
38321
38322
38323
38324
38325
38326
38327
38328
38329
38330
38331
38332
38333
38334
38335
38336
38337
38338
38339
38340
38341
38342
38343
38344
38345
38346
38347
38348
38349
38350
38351
38352
38353
38354
38355
38356
38357
38358
38359
38360
38361
38362
38363
38364
38365
38366
38367
38368
38369
38370
38371
38372
38373
38374
38375
38376
38377
38378
38379
38380
38381
38382
38383
38384
38385
38386
38387
38388
38389
38390
38391
38392
38393
38394
38395
38396
38397
38398
38399
38400
38401
38402
38403
38404
38405
38406
38407
38408
38409
38410
38411
38412
38413
38414
38415
38416
38417
38418
38419
38420
38421
38422
38423
38424
38425
38426
38427
38428
38429
38430
38431
38432
38433
38434
38435
38436
38437
38438
38439
38440
38441
38442
38443
38444
38445
38446
38447
38448
38449
38450
38451
38452
38453
38454
38455
38456
38457
38458
38459
38460
38461
38462
38463
38464
38465
38466
38467
38468
38469
38470
38471
38472
38473
38474
38475
38476
38477
38478
38479
38480
38481
38482
38483
38484
38485
38486
38487
38488
38489
38490
38491
38492
38493
38494
38495
38496
38497
38498
38499
38500
38501
38502
38503
38504
38505
38506
38507
38508
38509
38510
38511
38512
38513
38514
38515
38516
38517
38518
38519
38520
38521
38522
38523
38524
38525
38526
38527
38528
38529
38530
38531
38532
38533
38534
38535
38536
38537
38538
38539
38540
38541
38542
38543
38544
38545
38546
38547
38548
38549
38550
38551
38552
38553
38554
38555
38556
38557
38558
38559
38560
38561
38562
38563
38564
38565
38566
38567
38568
38569
38570
38571
38572
38573
38574
38575
38576
38577
38578
38579
38580
38581
38582
38583
38584
38585
38586
38587
38588
38589
38590
38591
38592
38593
38594
38595
38596
38597
38598
38599
38600
38601
38602
38603
38604
38605
38606
38607
38608
38609
38610
38611
38612
38613
38614
38615
38616
38617
38618
38619
38620
38621
38622
38623
38624
38625
38626
38627
38628
38629
38630
38631
38632
38633
38634
38635
38636
38637
38638
38639
38640
38641
38642
38643
38644
38645
38646
38647
38648
38649
38650
38651
38652
38653
38654
38655
38656
38657
38658
38659
38660
38661
38662
38663
38664
38665
38666
38667
38668
38669
38670
38671
38672
38673
38674
38675
38676
38677
38678
38679
38680
38681
38682
38683
38684
38685
38686
38687
38688
38689
38690
38691
38692
38693
38694
38695
38696
38697
38698
38699
38700
38701
38702
38703
38704
38705
38706
38707
38708
38709
38710
38711
38712
38713
38714
38715
38716
38717
38718
38719
38720
38721
38722
38723
38724
38725
38726
38727
38728
38729
38730
38731
38732
38733
38734
38735
38736
38737
38738
38739
38740
38741
38742
38743
38744
38745
38746
38747
38748
38749
38750
38751
38752
38753
38754
38755
38756
38757
38758
38759
38760
38761
38762
38763
38764
38765
38766
38767
38768
38769
38770
38771
38772
38773
38774
38775
38776
38777
38778
38779
38780
38781
38782
38783
38784
38785
38786
38787
38788
38789
38790
38791
38792
38793
38794
38795
38796
38797
38798
38799
38800
38801
38802
38803
38804
38805
38806
38807
38808
38809
38810
38811
38812
38813
38814
38815
38816
38817
38818
38819
38820
38821
38822
38823
38824
38825
38826
38827
38828
38829
38830
38831
38832
38833
38834
38835
38836
38837
38838
38839
38840
38841
38842
38843
38844
38845
38846
38847
38848
38849
38850
38851
38852
38853
38854
38855
38856
38857
38858
38859
38860
38861
38862
38863
38864
38865
38866
38867
38868
38869
38870
38871
38872
38873
38874
38875
38876
38877
38878
38879
38880
38881
38882
38883
38884
38885
38886
38887
38888
38889
38890
38891
38892
38893
38894
38895
38896
38897
38898
38899
38900
38901
38902
38903
38904
38905
38906
38907
38908
38909
38910
38911
38912
38913
38914
38915
38916
38917
38918
38919
38920
38921
38922
38923
38924
38925
38926
38927
38928
38929
38930
38931
38932
38933
38934
38935
38936
38937
38938
38939
38940
38941
38942
38943
38944
38945
38946
38947
38948
38949
38950
38951
38952
38953
38954
38955
38956
38957
38958
38959
38960
38961
38962
38963
38964
38965
38966
38967
38968
38969
38970
38971
38972
38973
38974
38975
38976
38977
38978
38979
38980
38981
38982
38983
38984
38985
38986
38987
38988
38989
38990
38991
38992
38993
38994
38995
38996
38997
38998
38999
39000
39001
39002
39003
39004
39005
39006
39007
39008
39009
39010
39011
39012
39013
39014
39015
39016
39017
39018
39019
39020
39021
39022
39023
39024
39025
39026
39027
39028
39029
39030
39031
39032
39033
39034
39035
39036
39037
39038
39039
39040
39041
39042
39043
39044
39045
39046
39047
39048
39049
39050
39051
39052
39053
39054
39055
39056
39057
39058
39059
39060
39061
39062
39063
39064
39065
39066
39067
39068
39069
39070
39071
39072
39073
39074
39075
39076
39077
39078
39079
39080
39081
39082
39083
39084
39085
39086
39087
39088
39089
39090
39091
39092
39093
39094
39095
39096
39097
39098
39099
39100
39101
39102
39103
39104
39105
39106
39107
39108
39109
39110
39111
39112
39113
39114
39115
39116
39117
39118
39119
39120
39121
39122
39123
39124
39125
39126
39127
39128
39129
39130
39131
39132
39133
39134
39135
39136
39137
39138
39139
39140
39141
39142
39143
39144
39145
39146
39147
39148
39149
39150
39151
39152
39153
39154
39155
39156
39157
39158
39159
39160
39161
39162
39163
39164
39165
39166
39167
39168
39169
39170
39171
39172
39173
39174
39175
39176
39177
39178
39179
39180
39181
39182
39183
39184
39185
39186
39187
39188
39189
39190
39191
39192
39193
39194
39195
39196
39197
39198
39199
39200
39201
39202
39203
39204
39205
39206
39207
39208
39209
39210
39211
39212
39213
39214
39215
39216
39217
39218
39219
39220
39221
39222
39223
39224
39225
39226
39227
39228
39229
39230
39231
39232
39233
39234
39235
39236
39237
39238
39239
39240
39241
39242
39243
39244
39245
39246
39247
39248
39249
39250
39251
39252
39253
39254
39255
39256
39257
39258
39259
39260
39261
39262
39263
39264
39265
39266
39267
39268
39269
39270
39271
39272
39273
39274
39275
39276
39277
39278
39279
39280
39281
39282
39283
39284
39285
39286
39287
39288
39289
39290
39291
39292
39293
39294
39295
39296
39297
39298
39299
39300
39301
39302
39303
39304
39305
39306
39307
39308
39309
39310
39311
39312
39313
39314
39315
39316
39317
39318
39319
39320
39321
39322
39323
39324
39325
39326
39327
39328
39329
39330
39331
39332
39333
39334
39335
39336
39337
39338
39339
39340
39341
39342
39343
39344
39345
39346
39347
39348
39349
39350
39351
39352
39353
39354
39355
39356
39357
39358
39359
39360
39361
39362
39363
39364
39365
39366
39367
39368
39369
39370
39371
39372
39373
39374
39375
39376
39377
39378
39379
39380
39381
39382
39383
39384
39385
39386
39387
39388
39389
39390
39391
39392
39393
39394
39395
39396
39397
39398
39399
39400
39401
39402
39403
39404
39405
39406
39407
39408
39409
39410
39411
39412
39413
39414
39415
39416
39417
39418
39419
39420
39421
39422
39423
39424
39425
39426
39427
39428
39429
39430
39431
39432
39433
39434
39435
39436
39437
39438
39439
39440
39441
39442
39443
39444
39445
39446
39447
39448
39449
39450
39451
39452
39453
39454
39455
39456
39457
39458
39459
39460
39461
39462
39463
39464
39465
39466
39467
39468
39469
39470
39471
39472
39473
39474
39475
39476
39477
39478
39479
39480
39481
39482
39483
39484
39485
39486
39487
39488
39489
39490
39491
39492
39493
39494
39495
39496
39497
39498
39499
39500
39501
39502
39503
39504
39505
39506
39507
39508
39509
39510
39511
39512
39513
39514
39515
39516
39517
39518
39519
39520
39521
39522
39523
39524
39525
39526
39527
39528
39529
39530
39531
39532
39533
39534
39535
39536
39537
39538
39539
39540
39541
39542
39543
39544
39545
39546
39547
39548
39549
39550
39551
39552
39553
39554
39555
39556
39557
39558
39559
39560
39561
39562
39563
39564
39565
39566
39567
39568
39569
39570
39571
39572
39573
39574
39575
39576
39577
39578
39579
39580
39581
39582
39583
39584
39585
39586
39587
39588
39589
39590
39591
39592
39593
39594
39595
39596
39597
39598
39599
39600
39601
39602
39603
39604
39605
39606
39607
39608
39609
39610
39611
39612
39613
39614
39615
39616
39617
39618
39619
39620
39621
39622
39623
39624
39625
39626
39627
39628
39629
39630
39631
39632
39633
39634
39635
39636
39637
39638
39639
39640
39641
39642
39643
39644
39645
39646
39647
39648
39649
39650
39651
39652
39653
39654
39655
39656
39657
39658
39659
39660
39661
39662
39663
39664
39665
39666
39667
39668
39669
39670
39671
39672
39673
39674
39675
39676
39677
39678
39679
39680
39681
39682
39683
39684
39685
39686
39687
39688
39689
39690
39691
39692
39693
39694
39695
39696
39697
39698
39699
39700
39701
39702
39703
39704
39705
39706
39707
39708
39709
39710
39711
39712
39713
39714
39715
39716
39717
39718
39719
39720
39721
39722
39723
39724
39725
39726
39727
39728
39729
39730
39731
39732
39733
39734
39735
39736
39737
39738
39739
39740
39741
39742
39743
39744
39745
39746
39747
39748
39749
39750
39751
39752
39753
39754
39755
39756
39757
39758
39759
39760
39761
39762
39763
39764
39765
39766
39767
39768
39769
39770
39771
39772
39773
39774
39775
39776
39777
39778
39779
39780
39781
39782
39783
39784
39785
39786
39787
39788
39789
39790
39791
39792
39793
39794
39795
39796
39797
39798
39799
39800
39801
39802
39803
39804
39805
39806
39807
39808
39809
39810
39811
39812
39813
39814
39815
39816
39817
39818
39819
39820
39821
39822
39823
39824
39825
39826
39827
39828
39829
39830
39831
39832
39833
39834
39835
39836
39837
39838
39839
39840
39841
39842
39843
39844
39845
39846
39847
39848
39849
39850
39851
39852
39853
39854
39855
39856
39857
39858
39859
39860
39861
39862
39863
39864
39865
39866
39867
39868
39869
39870
39871
39872
39873
39874
39875
39876
39877
39878
39879
39880
39881
39882
39883
39884
39885
39886
39887
39888
39889
39890
39891
39892
39893
39894
39895
39896
39897
39898
39899
39900
39901
39902
39903
39904
39905
39906
39907
39908
39909
39910
39911
39912
39913
39914
39915
39916
39917
39918
39919
39920
39921
39922
39923
39924
39925
39926
39927
39928
39929
39930
39931
39932
39933
39934
39935
39936
39937
39938
39939
39940
39941
39942
39943
39944
39945
39946
39947
39948
39949
39950
39951
39952
39953
39954
39955
39956
39957
39958
39959
39960
39961
39962
39963
39964
39965
39966
39967
39968
39969
39970
39971
39972
39973
39974
39975
39976
39977
39978
39979
39980
39981
39982
39983
39984
39985
39986
39987
39988
39989
39990
39991
39992
39993
39994
39995
39996
39997
39998
39999
40000
40001
40002
40003
40004
40005
40006
40007
40008
40009
40010
40011
40012
40013
40014
40015
40016
40017
40018
40019
40020
40021
40022
40023
40024
40025
40026
40027
40028
40029
40030
40031
40032
40033
40034
40035
40036
40037
40038
40039
40040
40041
40042
40043
40044
40045
40046
40047
40048
40049
40050
40051
40052
40053
40054
40055
40056
40057
40058
40059
40060
40061
40062
40063
40064
40065
40066
40067
40068
40069
40070
40071
40072
40073
40074
40075
40076
40077
40078
40079
40080
40081
40082
40083
40084
40085
40086
40087
40088
40089
40090
40091
40092
40093
40094
40095
40096
40097
40098
40099
40100
40101
40102
40103
40104
40105
40106
40107
40108
40109
40110
40111
40112
40113
40114
40115
40116
40117
40118
40119
40120
40121
40122
40123
40124
40125
40126
40127
40128
40129
40130
40131
40132
40133
40134
40135
40136
40137
40138
40139
40140
40141
40142
40143
40144
40145
40146
40147
40148
40149
40150
40151
40152
40153
40154
40155
40156
40157
40158
40159
40160
40161
40162
40163
40164
40165
40166
40167
40168
40169
40170
40171
40172
40173
40174
40175
40176
40177
40178
40179
40180
40181
40182
40183
40184
40185
40186
40187
40188
40189
40190
40191
40192
40193
40194
40195
40196
40197
40198
40199
40200
40201
40202
40203
40204
40205
40206
40207
40208
40209
40210
40211
40212
40213
40214
40215
40216
40217
40218
40219
40220
40221
40222
40223
40224
40225
40226
40227
40228
40229
40230
40231
40232
40233
40234
40235
40236
40237
40238
40239
40240
40241
40242
40243
40244
40245
40246
40247
40248
40249
40250
40251
40252
40253
40254
40255
40256
40257
40258
40259
40260
40261
40262
40263
40264
40265
40266
40267
40268
40269
40270
40271
40272
40273
40274
40275
40276
40277
40278
40279
40280
40281
40282
40283
40284
40285
40286
40287
40288
40289
40290
40291
40292
40293
40294
40295
40296
40297
40298
40299
40300
40301
40302
40303
40304
40305
40306
40307
40308
40309
40310
40311
40312
40313
40314
40315
40316
40317
40318
40319
40320
40321
40322
40323
40324
40325
40326
40327
40328
40329
40330
40331
40332
40333
40334
40335
40336
40337
40338
40339
40340
40341
40342
40343
40344
40345
40346
40347
40348
40349
40350
40351
40352
40353
40354
40355
40356
40357
40358
40359
40360
40361
40362
40363
40364
40365
40366
40367
40368
40369
40370
40371
40372
40373
40374
40375
40376
40377
40378
40379
40380
40381
40382
40383
40384
40385
40386
40387
40388
40389
40390
40391
40392
40393
40394
40395
40396
40397
40398
40399
40400
40401
40402
40403
40404
40405
40406
40407
40408
40409
40410
40411
40412
40413
40414
40415
40416
40417
40418
40419
40420
40421
40422
40423
40424
40425
40426
40427
40428
40429
40430
40431
40432
40433
40434
40435
40436
40437
40438
40439
40440
40441
40442
40443
40444
40445
40446
40447
40448
40449
40450
40451
40452
40453
40454
40455
40456
40457
40458
40459
40460
40461
40462
40463
40464
40465
40466
40467
40468
40469
40470
40471
40472
40473
40474
40475
40476
40477
40478
40479
40480
40481
40482
40483
40484
40485
40486
40487
40488
40489
40490
40491
40492
40493
40494
40495
40496
40497
40498
40499
40500
40501
40502
40503
40504
40505
40506
40507
40508
40509
40510
40511
40512
40513
40514
40515
40516
40517
40518
40519
40520
40521
40522
40523
40524
40525
40526
40527
40528
40529
40530
40531
40532
40533
40534
40535
40536
40537
40538
40539
40540
40541
40542
40543
40544
40545
40546
40547
40548
40549
40550
40551
40552
40553
40554
40555
40556
40557
40558
40559
40560
40561
40562
40563
40564
40565
40566
40567
40568
40569
40570
40571
40572
40573
40574
40575
40576
40577
40578
40579
40580
40581
40582
40583
40584
40585
40586
40587
40588
40589
40590
40591
40592
40593
40594
40595
40596
40597
40598
40599
40600
40601
40602
40603
40604
40605
40606
40607
40608
40609
40610
40611
40612
40613
40614
40615
40616
40617
40618
40619
40620
40621
40622
40623
40624
40625
40626
40627
40628
40629
40630
40631
40632
40633
40634
40635
40636
40637
40638
40639
40640
40641
40642
40643
40644
40645
40646
40647
40648
40649
40650
40651
40652
40653
40654
40655
40656
40657
40658
40659
40660
40661
40662
40663
40664
40665
40666
40667
40668
40669
40670
40671
40672
40673
40674
40675
40676
40677
40678
40679
40680
40681
40682
40683
40684
40685
40686
40687
40688
40689
40690
40691
40692
40693
40694
40695
40696
40697
40698
40699
40700
40701
40702
40703
40704
40705
40706
40707
40708
40709
40710
40711
40712
40713
40714
40715
40716
40717
40718
40719
40720
40721
40722
40723
40724
40725
40726
40727
40728
40729
40730
40731
40732
40733
40734
40735
40736
40737
40738
40739
40740
40741
40742
40743
40744
40745
40746
40747
40748
40749
40750
40751
40752
40753
40754
40755
40756
40757
40758
40759
40760
40761
40762
40763
40764
40765
40766
40767
40768
40769
40770
40771
40772
40773
40774
40775
40776
40777
40778
40779
40780
40781
40782
40783
40784
40785
40786
40787
40788
40789
40790
40791
40792
40793
40794
40795
40796
40797
40798
40799
40800
40801
40802
40803
40804
40805
40806
40807
40808
40809
40810
40811
40812
40813
40814
40815
40816
40817
40818
40819
40820
40821
40822
40823
40824
40825
40826
40827
40828
40829
40830
40831
40832
40833
40834
40835
40836
40837
40838
40839
40840
40841
40842
40843
40844
40845
40846
40847
40848
40849
40850
40851
40852
40853
40854
40855
40856
40857
40858
40859
40860
40861
40862
40863
40864
40865
40866
40867
40868
40869
40870
40871
40872
40873
40874
40875
40876
40877
40878
40879
40880
40881
40882
40883
40884
40885
40886
40887
40888
40889
40890
40891
40892
40893
40894
40895
40896
40897
40898
40899
40900
40901
40902
40903
40904
40905
40906
40907
40908
40909
40910
40911
40912
40913
40914
40915
40916
40917
40918
40919
40920
40921
40922
40923
40924
40925
40926
40927
40928
40929
40930
40931
40932
40933
40934
40935
40936
40937
40938
40939
40940
40941
40942
40943
40944
40945
40946
40947
40948
40949
40950
40951
40952
40953
40954
40955
40956
40957
40958
40959
40960
40961
40962
40963
40964
40965
40966
40967
40968
40969
40970
40971
40972
40973
40974
40975
40976
40977
40978
40979
40980
40981
40982
40983
40984
40985
40986
40987
40988
40989
40990
40991
40992
40993
40994
40995
40996
40997
40998
40999
41000
41001
41002
41003
41004
41005
41006
41007
41008
41009
41010
41011
41012
41013
41014
41015
41016
41017
41018
41019
41020
41021
41022
41023
41024
41025
41026
41027
41028
41029
41030
41031
41032
41033
41034
41035
41036
41037
41038
41039
41040
41041
41042
41043
41044
41045
41046
41047
41048
41049
41050
41051
41052
41053
41054
41055
41056
41057
41058
41059
41060
41061
41062
41063
41064
41065
41066
41067
41068
41069
41070
41071
41072
41073
41074
41075
41076
41077
41078
41079
41080
41081
41082
41083
41084
41085
41086
41087
41088
41089
41090
41091
41092
41093
41094
41095
41096
41097
41098
41099
41100
41101
41102
41103
41104
41105
41106
41107
41108
41109
41110
41111
41112
41113
41114
41115
41116
41117
41118
41119
41120
41121
41122
41123
41124
41125
41126
41127
41128
41129
41130
41131
41132
41133
41134
41135
41136
41137
41138
41139
41140
41141
41142
41143
41144
41145
41146
41147
41148
41149
41150
41151
41152
41153
41154
41155
41156
41157
41158
41159
41160
41161
41162
41163
41164
41165
41166
41167
41168
41169
41170
41171
41172
41173
41174
41175
41176
41177
41178
41179
41180
41181
41182
41183
41184
41185
41186
41187
41188
41189
41190
41191
41192
41193
41194
41195
41196
41197
41198
41199
41200
41201
41202
41203
41204
41205
41206
41207
41208
41209
41210
41211
41212
41213
41214
41215
41216
41217
41218
41219
41220
41221
41222
41223
41224
41225
41226
41227
41228
41229
41230
41231
41232
41233
41234
41235
41236
41237
41238
41239
41240
41241
41242
41243
41244
41245
41246
41247
41248
41249
41250
41251
41252
41253
41254
41255
41256
41257
41258
41259
41260
41261
41262
41263
41264
41265
41266
41267
41268
41269
41270
41271
41272
41273
41274
41275
41276
41277
41278
41279
41280
41281
41282
41283
41284
41285
41286
41287
41288
41289
41290
41291
41292
41293
41294
41295
41296
41297
41298
41299
41300
41301
41302
41303
41304
41305
41306
41307
41308
41309
41310
41311
41312
41313
41314
41315
41316
41317
41318
41319
41320
41321
41322
41323
41324
41325
41326
41327
41328
41329
41330
41331
41332
41333
41334
41335
41336
41337
41338
41339
41340
41341
41342
41343
41344
41345
41346
41347
41348
41349
41350
41351
41352
41353
41354
41355
41356
41357
41358
41359
41360
41361
41362
41363
41364
41365
41366
41367
41368
41369
41370
41371
41372
41373
41374
41375
41376
41377
41378
41379
41380
41381
41382
41383
41384
41385
41386
41387
41388
41389
41390
41391
41392
41393
41394
41395
41396
41397
41398
41399
41400
41401
41402
41403
41404
41405
41406
41407
41408
41409
41410
41411
41412
41413
41414
41415
41416
41417
41418
41419
41420
41421
41422
41423
41424
41425
41426
41427
41428
41429
41430
41431
41432
41433
41434
41435
41436
41437
41438
41439
41440
41441
41442
41443
41444
41445
41446
41447
41448
41449
41450
41451
41452
41453
41454
41455
41456
41457
41458
41459
41460
41461
41462
41463
41464
41465
41466
41467
41468
41469
41470
41471
41472
41473
41474
41475
41476
41477
41478
41479
41480
41481
41482
41483
41484
41485
41486
41487
41488
41489
41490
41491
41492
41493
41494
41495
41496
41497
41498
41499
41500
41501
41502
41503
41504
41505
41506
41507
41508
41509
41510
41511
41512
41513
41514
41515
41516
41517
41518
41519
41520
41521
41522
41523
41524
41525
41526
41527
41528
41529
41530
41531
41532
41533
41534
41535
41536
41537
41538
41539
41540
41541
41542
41543
41544
41545
41546
41547
41548
41549
41550
41551
41552
41553
41554
41555
41556
41557
41558
41559
41560
41561
41562
41563
41564
41565
41566
41567
41568
41569
41570
41571
41572
41573
41574
41575
41576
41577
41578
41579
41580
41581
41582
41583
41584
41585
41586
41587
41588
41589
41590
41591
41592
41593
41594
41595
41596
41597
41598
41599
41600
41601
41602
41603
41604
41605
41606
41607
41608
41609
41610
41611
41612
41613
41614
41615
41616
41617
41618
41619
41620
41621
41622
41623
41624
41625
41626
41627
41628
41629
41630
41631
41632
41633
41634
41635
41636
41637
41638
41639
41640
41641
41642
41643
41644
41645
41646
41647
41648
41649
41650
41651
41652
41653
41654
41655
41656
41657
41658
41659
41660
41661
41662
41663
41664
41665
41666
41667
41668
41669
41670
41671
41672
41673
41674
41675
41676
41677
41678
41679
41680
41681
41682
41683
41684
41685
41686
41687
41688
41689
41690
41691
41692
41693
41694
41695
41696
41697
41698
41699
41700
41701
41702
41703
41704
41705
41706
41707
41708
41709
41710
41711
41712
41713
41714
41715
41716
41717
41718
41719
41720
41721
41722
41723
41724
41725
41726
41727
41728
41729
41730
41731
41732
41733
41734
41735
41736
41737
41738
41739
41740
41741
41742
41743
41744
41745
41746
41747
41748
41749
41750
41751
41752
41753
41754
41755
41756
41757
41758
41759
41760
41761
41762
41763
41764
41765
41766
41767
41768
41769
41770
41771
41772
41773
41774
41775
41776
41777
41778
41779
41780
41781
41782
41783
41784
41785
41786
41787
41788
41789
41790
41791
41792
41793
41794
41795
41796
41797
41798
41799
41800
41801
41802
41803
41804
41805
41806
41807
41808
41809
41810
41811
41812
41813
41814
41815
41816
41817
41818
41819
41820
41821
41822
41823
41824
41825
41826
41827
41828
41829
41830
41831
41832
41833
41834
41835
41836
41837
41838
41839
41840
41841
41842
41843
41844
41845
41846
41847
41848
41849
41850
41851
41852
41853
41854
41855
41856
41857
41858
41859
41860
41861
41862
41863
41864
41865
41866
41867
41868
41869
41870
41871
41872
41873
41874
41875
41876
41877
41878
41879
41880
41881
41882
41883
41884
41885
41886
41887
41888
41889
41890
41891
41892
41893
41894
41895
41896
41897
41898
41899
41900
41901
41902
41903
41904
41905
41906
41907
41908
41909
41910
41911
41912
41913
41914
41915
41916
41917
41918
41919
41920
41921
41922
41923
41924
41925
41926
41927
41928
41929
41930
41931
41932
41933
41934
41935
41936
41937
41938
41939
41940
41941
41942
41943
41944
41945
41946
41947
41948
41949
41950
41951
41952
41953
41954
41955
41956
41957
41958
41959
41960
41961
41962
41963
41964
41965
41966
41967
41968
41969
41970
41971
41972
41973
41974
41975
41976
41977
41978
41979
41980
41981
41982
41983
41984
41985
41986
41987
41988
41989
41990
41991
41992
41993
41994
41995
41996
41997
41998
41999
42000
42001
42002
42003
42004
42005
42006
42007
42008
42009
42010
42011
42012
42013
42014
42015
42016
42017
42018
42019
42020
42021
42022
42023
42024
42025
42026
42027
42028
42029
42030
42031
42032
42033
42034
42035
42036
42037
42038
42039
42040
42041
42042
42043
42044
42045
42046
42047
42048
42049
42050
42051
42052
42053
42054
42055
42056
42057
42058
42059
42060
42061
42062
42063
42064
42065
42066
42067
42068
42069
42070
42071
42072
42073
42074
42075
42076
42077
42078
42079
42080
42081
42082
42083
42084
42085
42086
42087
42088
42089
42090
42091
42092
42093
42094
42095
42096
42097
42098
42099
42100
42101
42102
42103
42104
42105
42106
42107
42108
42109
42110
42111
42112
42113
42114
42115
42116
42117
42118
42119
42120
42121
42122
42123
42124
42125
42126
42127
42128
42129
42130
42131
42132
42133
42134
42135
42136
42137
42138
42139
42140
42141
42142
42143
42144
42145
42146
42147
42148
42149
42150
42151
42152
42153
42154
42155
42156
42157
42158
42159
42160
42161
42162
42163
42164
42165
42166
42167
42168
42169
42170
42171
42172
42173
42174
42175
42176
42177
42178
42179
42180
42181
42182
42183
42184
42185
42186
42187
42188
42189
42190
42191
42192
42193
42194
42195
42196
42197
42198
42199
42200
42201
42202
42203
42204
42205
42206
42207
42208
42209
42210
42211
42212
42213
42214
42215
42216
42217
42218
42219
42220
42221
42222
42223
42224
42225
42226
42227
42228
42229
42230
42231
42232
42233
42234
42235
42236
42237
42238
42239
42240
42241
42242
42243
42244
42245
42246
42247
42248
42249
42250
42251
42252
42253
42254
42255
42256
42257
42258
42259
42260
42261
42262
42263
42264
42265
42266
42267
42268
42269
42270
42271
42272
42273
42274
42275
42276
42277
42278
42279
42280
42281
42282
42283
42284
42285
42286
42287
42288
42289
42290
42291
42292
42293
42294
42295
42296
42297
42298
42299
42300
42301
42302
42303
42304
42305
42306
42307
42308
42309
42310
42311
42312
42313
42314
42315
42316
42317
42318
42319
42320
42321
42322
42323
42324
42325
42326
42327
42328
42329
42330
42331
42332
42333
42334
42335
42336
42337
42338
42339
42340
42341
42342
42343
42344
42345
42346
42347
42348
42349
42350
42351
42352
42353
42354
42355
42356
42357
42358
42359
42360
42361
42362
42363
42364
42365
42366
42367
42368
42369
42370
42371
42372
42373
42374
42375
42376
42377
42378
42379
42380
42381
42382
42383
42384
42385
42386
42387
42388
42389
42390
42391
42392
42393
42394
42395
42396
42397
42398
42399
42400
42401
42402
42403
42404
42405
42406
42407
42408
42409
42410
42411
42412
42413
42414
42415
42416
42417
42418
42419
42420
42421
42422
42423
42424
42425
42426
42427
42428
42429
42430
42431
42432
42433
42434
42435
42436
42437
42438
42439
42440
42441
42442
42443
42444
42445
42446
42447
42448
42449
42450
42451
42452
42453
42454
42455
42456
42457
42458
42459
42460
42461
42462
42463
42464
42465
42466
42467
42468
42469
42470
42471
42472
42473
42474
42475
42476
42477
42478
42479
42480
42481
42482
42483
42484
42485
42486
42487
42488
42489
42490
42491
42492
42493
42494
42495
42496
42497
42498
42499
42500
42501
42502
42503
42504
42505
42506
42507
42508
42509
42510
42511
42512
42513
42514
42515
42516
42517
42518
42519
42520
42521
42522
42523
42524
42525
42526
42527
42528
42529
42530
42531
42532
42533
42534
42535
42536
42537
42538
42539
42540
42541
42542
42543
42544
42545
42546
42547
42548
42549
42550
42551
42552
42553
42554
42555
42556
42557
42558
42559
42560
42561
42562
42563
42564
42565
42566
42567
42568
42569
42570
42571
42572
42573
42574
42575
42576
42577
42578
42579
42580
42581
42582
42583
42584
42585
42586
42587
42588
42589
42590
42591
42592
42593
42594
42595
42596
42597
42598
42599
42600
42601
42602
42603
42604
42605
42606
42607
42608
42609
42610
42611
42612
42613
42614
42615
42616
42617
42618
42619
42620
42621
42622
42623
42624
42625
42626
42627
42628
42629
42630
42631
42632
42633
42634
42635
42636
42637
42638
42639
42640
42641
42642
42643
42644
42645
42646
42647
42648
42649
42650
42651
42652
42653
42654
42655
42656
42657
42658
42659
42660
42661
42662
42663
42664
42665
42666
42667
42668
42669
42670
42671
42672
42673
42674
42675
42676
42677
42678
42679
42680
42681
42682
42683
42684
42685
42686
42687
42688
42689
42690
42691
42692
42693
42694
42695
42696
42697
42698
42699
42700
42701
42702
42703
42704
42705
42706
42707
42708
42709
42710
42711
42712
42713
42714
42715
42716
42717
42718
42719
42720
42721
42722
42723
42724
42725
42726
42727
42728
42729
42730
42731
42732
42733
42734
42735
42736
42737
42738
42739
42740
42741
42742
42743
42744
42745
42746
42747
42748
42749
42750
42751
42752
42753
42754
42755
42756
42757
42758
42759
42760
42761
42762
42763
42764
42765
42766
42767
42768
42769
42770
42771
42772
42773
42774
42775
42776
42777
42778
42779
42780
42781
42782
42783
42784
42785
42786
42787
42788
42789
42790
42791
42792
42793
42794
42795
42796
42797
42798
42799
42800
42801
42802
42803
42804
42805
42806
42807
42808
42809
42810
42811
42812
42813
42814
42815
42816
42817
42818
42819
42820
42821
42822
42823
42824
42825
42826
42827
42828
42829
42830
42831
42832
42833
42834
42835
42836
42837
42838
42839
42840
42841
42842
42843
42844
42845
42846
42847
42848
42849
42850
42851
42852
42853
42854
42855
42856
42857
42858
42859
42860
42861
42862
42863
42864
42865
42866
42867
42868
42869
42870
42871
42872
42873
42874
42875
42876
42877
42878
42879
42880
42881
42882
42883
42884
42885
42886
42887
42888
42889
42890
42891
42892
42893
42894
42895
42896
42897
42898
42899
42900
42901
42902
42903
42904
42905
42906
42907
42908
42909
42910
42911
42912
42913
42914
42915
42916
42917
42918
42919
42920
42921
42922
42923
42924
42925
42926
42927
42928
42929
42930
42931
42932
42933
42934
42935
42936
42937
42938
42939
42940
42941
42942
42943
42944
42945
42946
42947
42948
42949
42950
42951
42952
42953
42954
42955
42956
42957
42958
42959
42960
42961
42962
42963
42964
42965
42966
42967
42968
42969
42970
42971
42972
42973
42974
42975
42976
42977
42978
42979
42980
42981
42982
42983
42984
42985
42986
42987
42988
42989
42990
42991
42992
42993
42994
42995
42996
42997
42998
42999
43000
43001
43002
43003
43004
43005
43006
43007
43008
43009
43010
43011
43012
43013
43014
43015
43016
43017
43018
43019
43020
43021
43022
43023
43024
43025
43026
43027
43028
43029
43030
43031
43032
43033
43034
43035
43036
43037
43038
43039
43040
43041
43042
43043
43044
43045
43046
43047
43048
43049
43050
43051
43052
43053
43054
43055
43056
43057
43058
43059
43060
43061
43062
43063
43064
43065
43066
43067
43068
43069
43070
43071
43072
43073
43074
43075
43076
43077
43078
43079
43080
43081
43082
43083
43084
43085
43086
43087
43088
43089
43090
43091
43092
43093
43094
43095
43096
43097
43098
43099
43100
43101
43102
43103
43104
43105
43106
43107
43108
43109
43110
43111
43112
43113
43114
43115
43116
43117
43118
43119
43120
43121
43122
43123
43124
43125
43126
43127
43128
43129
43130
43131
43132
43133
43134
43135
43136
43137
43138
43139
43140
43141
43142
43143
43144
43145
43146
43147
43148
43149
43150
43151
43152
43153
43154
43155
43156
43157
43158
43159
43160
43161
43162
43163
43164
43165
43166
43167
43168
43169
43170
43171
43172
43173
43174
43175
43176
43177
43178
43179
43180
43181
43182
43183
43184
43185
43186
43187
43188
43189
43190
43191
43192
43193
43194
43195
43196
43197
43198
43199
43200
43201
43202
43203
43204
43205
43206
43207
43208
43209
43210
43211
43212
43213
43214
43215
43216
43217
43218
43219
43220
43221
43222
43223
43224
43225
43226
43227
43228
43229
43230
43231
43232
43233
43234
43235
43236
43237
43238
43239
43240
43241
43242
43243
43244
43245
43246
43247
43248
43249
43250
43251
43252
43253
43254
43255
43256
43257
43258
43259
43260
43261
43262
43263
43264
43265
43266
43267
43268
43269
43270
43271
43272
43273
43274
43275
43276
43277
43278
43279
43280
43281
43282
43283
43284
43285
43286
43287
43288
43289
43290
43291
43292
43293
43294
43295
43296
43297
43298
43299
43300
43301
43302
43303
43304
43305
43306
43307
43308
43309
43310
43311
43312
43313
43314
43315
43316
43317
43318
43319
43320
43321
43322
43323
43324
43325
43326
43327
43328
43329
43330
43331
43332
43333
43334
43335
43336
43337
43338
43339
43340
43341
43342
43343
43344
43345
43346
43347
43348
43349
43350
43351
43352
43353
43354
43355
43356
43357
43358
43359
43360
43361
43362
43363
43364
43365
43366
43367
43368
43369
43370
43371
43372
43373
43374
43375
43376
43377
43378
43379
43380
43381
43382
43383
43384
43385
43386
43387
43388
43389
43390
43391
43392
43393
43394
43395
43396
43397
43398
43399
43400
43401
43402
43403
43404
43405
43406
43407
43408
43409
43410
43411
43412
43413
43414
43415
43416
43417
43418
43419
43420
43421
43422
43423
43424
43425
43426
43427
43428
43429
43430
43431
43432
43433
43434
43435
43436
43437
43438
43439
43440
43441
43442
43443
43444
43445
43446
43447
43448
43449
43450
43451
43452
43453
43454
43455
43456
43457
43458
43459
43460
43461
43462
43463
43464
43465
43466
43467
43468
43469
43470
43471
43472
43473
43474
43475
43476
43477
43478
43479
43480
43481
43482
43483
43484
43485
43486
43487
43488
43489
43490
43491
43492
43493
43494
43495
43496
43497
43498
43499
43500
43501
43502
43503
43504
43505
43506
43507
43508
43509
43510
43511
43512
43513
43514
43515
43516
43517
43518
43519
43520
43521
43522
43523
43524
43525
43526
43527
43528
43529
43530
43531
43532
43533
43534
43535
43536
43537
43538
43539
43540
43541
43542
43543
43544
43545
43546
43547
43548
43549
43550
43551
43552
43553
43554
43555
43556
43557
43558
43559
43560
43561
43562
43563
43564
43565
43566
43567
43568
43569
43570
43571
43572
43573
43574
43575
43576
43577
43578
43579
43580
43581
43582
43583
43584
43585
43586
43587
43588
43589
43590
43591
43592
43593
43594
43595
43596
43597
43598
43599
43600
43601
43602
43603
43604
43605
43606
43607
43608
43609
43610
43611
43612
43613
43614
43615
43616
43617
43618
43619
43620
43621
43622
43623
43624
43625
43626
43627
43628
43629
43630
43631
43632
43633
43634
43635
43636
43637
43638
43639
43640
43641
43642
43643
43644
43645
43646
43647
43648
43649
43650
43651
43652
43653
43654
43655
43656
43657
43658
43659
43660
43661
43662
43663
43664
43665
43666
43667
43668
43669
43670
43671
43672
43673
43674
43675
43676
43677
43678
43679
43680
43681
43682
43683
43684
43685
43686
43687
43688
43689
43690
43691
43692
43693
43694
43695
43696
43697
43698
43699
43700
43701
43702
43703
43704
43705
43706
43707
43708
43709
43710
43711
43712
43713
43714
43715
43716
43717
43718
43719
43720
43721
43722
43723
43724
43725
43726
43727
43728
43729
43730
43731
43732
43733
43734
43735
43736
43737
43738
43739
43740
43741
43742
43743
43744
43745
43746
43747
43748
43749
43750
43751
43752
43753
43754
43755
43756
43757
43758
43759
43760
43761
43762
43763
43764
43765
43766
43767
43768
43769
43770
43771
43772
43773
43774
43775
43776
43777
43778
43779
43780
43781
43782
43783
43784
43785
43786
43787
43788
43789
43790
43791
43792
43793
43794
43795
43796
43797
43798
43799
43800
43801
43802
43803
43804
43805
43806
43807
43808
43809
43810
43811
43812
43813
43814
43815
43816
43817
43818
43819
43820
43821
43822
43823
43824
43825
43826
43827
43828
43829
43830
43831
43832
43833
43834
43835
43836
43837
43838
43839
43840
43841
43842
43843
43844
43845
43846
43847
43848
43849
43850
43851
43852
43853
43854
43855
43856
43857
43858
43859
43860
43861
43862
43863
43864
43865
43866
43867
43868
43869
43870
43871
43872
43873
43874
43875
43876
43877
43878
43879
43880
43881
43882
43883
43884
43885
43886
43887
43888
43889
43890
43891
43892
43893
43894
43895
43896
43897
43898
43899
43900
43901
43902
43903
43904
43905
43906
43907
43908
43909
43910
43911
43912
43913
43914
43915
43916
43917
43918
43919
43920
43921
43922
43923
43924
43925
43926
43927
43928
43929
43930
43931
43932
43933
43934
43935
43936
43937
43938
43939
43940
43941
43942
43943
43944
43945
43946
43947
43948
43949
43950
43951
43952
43953
43954
43955
43956
43957
43958
43959
43960
43961
43962
43963
43964
43965
43966
43967
43968
43969
43970
43971
43972
43973
43974
43975
43976
43977
43978
43979
43980
43981
43982
43983
43984
43985
43986
43987
43988
43989
43990
43991
43992
43993
43994
43995
43996
43997
43998
43999
44000
44001
44002
44003
44004
44005
44006
44007
44008
44009
44010
44011
44012
44013
44014
44015
44016
44017
44018
44019
44020
44021
44022
44023
44024
44025
44026
44027
44028
44029
44030
44031
44032
44033
44034
44035
44036
44037
44038
44039
44040
44041
44042
44043
44044
44045
44046
44047
44048
44049
44050
44051
44052
44053
44054
44055
44056
44057
44058
44059
44060
44061
44062
44063
44064
44065
44066
44067
44068
44069
44070
44071
44072
44073
44074
44075
44076
44077
44078
44079
44080
44081
44082
44083
44084
44085
44086
44087
44088
44089
44090
44091
44092
44093
44094
44095
44096
44097
44098
44099
44100
44101
44102
44103
44104
44105
44106
44107
44108
44109
44110
44111
44112
44113
44114
44115
44116
44117
44118
44119
44120
44121
44122
44123
44124
44125
44126
44127
44128
44129
44130
44131
44132
44133
44134
44135
44136
44137
44138
44139
44140
44141
44142
44143
44144
44145
44146
44147
44148
44149
44150
44151
44152
44153
44154
44155
44156
44157
44158
44159
44160
44161
44162
44163
44164
44165
44166
44167
44168
44169
44170
44171
44172
44173
44174
44175
44176
44177
44178
44179
44180
44181
44182
44183
44184
44185
44186
44187
44188
44189
44190
44191
44192
44193
44194
44195
44196
44197
44198
44199
44200
44201
44202
44203
44204
44205
44206
44207
44208
44209
44210
44211
44212
44213
44214
44215
44216
44217
44218
44219
44220
44221
44222
44223
44224
44225
44226
44227
44228
44229
44230
44231
44232
44233
44234
44235
44236
44237
44238
44239
44240
44241
44242
44243
44244
44245
44246
44247
44248
44249
44250
44251
44252
44253
44254
44255
44256
44257
44258
44259
44260
44261
44262
44263
44264
44265
44266
44267
44268
44269
44270
44271
44272
44273
44274
44275
44276
44277
44278
44279
44280
44281
44282
44283
44284
44285
44286
44287
44288
44289
44290
44291
44292
44293
44294
44295
44296
44297
44298
44299
44300
44301
44302
44303
44304
44305
44306
44307
44308
44309
44310
44311
44312
44313
44314
44315
44316
44317
44318
44319
44320
44321
44322
44323
44324
44325
44326
44327
44328
44329
44330
44331
44332
44333
44334
44335
44336
44337
44338
44339
44340
44341
44342
44343
44344
44345
44346
44347
44348
44349
44350
44351
44352
44353
44354
44355
44356
44357
44358
44359
44360
44361
44362
44363
44364
44365
44366
44367
44368
44369
44370
44371
44372
44373
44374
44375
44376
44377
44378
44379
44380
44381
44382
44383
44384
44385
44386
44387
44388
44389
44390
44391
44392
44393
44394
44395
44396
44397
44398
44399
44400
44401
44402
44403
44404
44405
44406
44407
44408
44409
44410
44411
44412
44413
44414
44415
44416
44417
44418
44419
44420
44421
44422
44423
44424
44425
44426
44427
44428
44429
44430
44431
44432
44433
44434
44435
44436
44437
44438
44439
44440
44441
44442
44443
44444
44445
44446
44447
44448
44449
44450
44451
44452
44453
44454
44455
44456
44457
44458
44459
44460
44461
44462
44463
44464
44465
44466
44467
44468
44469
44470
44471
44472
44473
44474
44475
44476
44477
44478
44479
44480
44481
44482
44483
44484
44485
44486
44487
44488
44489
44490
44491
44492
44493
44494
44495
44496
44497
44498
44499
44500
44501
44502
44503
44504
44505
44506
44507
44508
44509
44510
44511
44512
44513
44514
44515
44516
44517
44518
44519
44520
44521
44522
44523
44524
44525
44526
44527
44528
44529
44530
44531
44532
44533
44534
44535
44536
44537
44538
44539
44540
44541
44542
44543
44544
44545
44546
44547
44548
44549
44550
44551
44552
44553
44554
44555
44556
44557
44558
44559
44560
44561
44562
44563
44564
44565
44566
44567
44568
44569
44570
44571
44572
44573
44574
44575
44576
44577
44578
44579
44580
44581
44582
44583
44584
44585
44586
44587
44588
44589
44590
44591
44592
44593
44594
44595
44596
44597
44598
44599
44600
44601
44602
44603
44604
44605
44606
44607
44608
44609
44610
44611
44612
44613
44614
44615
44616
44617
44618
44619
44620
44621
44622
44623
44624
44625
44626
44627
44628
44629
44630
44631
44632
44633
44634
44635
44636
44637
44638
44639
44640
44641
44642
44643
44644
44645
44646
44647
44648
44649
44650
44651
44652
44653
44654
44655
44656
44657
44658
44659
44660
44661
44662
44663
44664
44665
44666
44667
44668
44669
44670
44671
44672
44673
44674
44675
44676
44677
44678
44679
44680
44681
44682
44683
44684
44685
44686
44687
44688
44689
44690
44691
44692
44693
44694
44695
44696
44697
44698
44699
44700
44701
44702
44703
44704
44705
44706
44707
44708
44709
44710
44711
44712
44713
44714
44715
44716
44717
44718
44719
44720
44721
44722
44723
44724
44725
44726
44727
44728
44729
44730
44731
44732
44733
44734
44735
44736
44737
44738
44739
44740
44741
44742
44743
44744
44745
44746
44747
44748
44749
44750
44751
44752
44753
44754
44755
44756
44757
44758
44759
44760
44761
44762
44763
44764
44765
44766
44767
44768
44769
44770
44771
44772
44773
44774
44775
44776
44777
44778
44779
44780
44781
44782
44783
44784
44785
44786
44787
44788
44789
44790
44791
44792
44793
44794
44795
44796
44797
44798
44799
44800
44801
44802
44803
44804
44805
44806
44807
44808
44809
44810
44811
44812
44813
44814
44815
44816
44817
44818
44819
44820
44821
44822
44823
44824
44825
44826
44827
44828
44829
44830
44831
44832
44833
44834
44835
44836
44837
44838
44839
44840
44841
44842
44843
44844
44845
44846
44847
44848
44849
44850
44851
44852
44853
44854
44855
44856
44857
44858
44859
44860
44861
44862
44863
44864
44865
44866
44867
44868
44869
44870
44871
44872
44873
44874
44875
44876
44877
44878
44879
44880
44881
44882
44883
44884
44885
44886
44887
44888
44889
44890
44891
44892
44893
44894
44895
44896
44897
44898
44899
44900
44901
44902
44903
44904
44905
44906
44907
44908
44909
44910
44911
44912
44913
44914
44915
44916
44917
44918
44919
44920
44921
44922
44923
44924
44925
44926
44927
44928
44929
44930
44931
44932
44933
44934
44935
44936
44937
44938
44939
44940
44941
44942
44943
44944
44945
44946
44947
44948
44949
44950
44951
44952
44953
44954
44955
44956
44957
44958
44959
44960
44961
44962
44963
44964
44965
44966
44967
44968
44969
44970
44971
44972
44973
44974
44975
44976
44977
44978
44979
44980
44981
44982
44983
44984
44985
44986
44987
44988
44989
44990
44991
44992
44993
44994
44995
44996
44997
44998
44999
45000
45001
45002
45003
45004
45005
45006
45007
45008
45009
45010
45011
45012
45013
45014
45015
45016
45017
45018
45019
45020
45021
45022
45023
45024
45025
45026
45027
45028
45029
45030
45031
45032
45033
45034
45035
45036
45037
45038
45039
45040
45041
45042
45043
45044
45045
45046
45047
45048
45049
45050
45051
45052
45053
45054
45055
45056
45057
45058
45059
45060
45061
45062
45063
45064
45065
45066
45067
45068
45069
45070
45071
45072
45073
45074
45075
45076
45077
45078
45079
45080
45081
45082
45083
45084
45085
45086
45087
45088
45089
45090
45091
45092
45093
45094
45095
45096
45097
45098
45099
45100
45101
45102
45103
45104
45105
45106
45107
45108
45109
45110
45111
45112
45113
45114
45115
45116
45117
45118
45119
45120
45121
45122
45123
45124
45125
45126
45127
45128
45129
45130
45131
45132
45133
45134
45135
45136
45137
45138
45139
45140
45141
45142
45143
45144
45145
45146
45147
45148
45149
45150
45151
45152
45153
45154
45155
45156
45157
45158
45159
45160
45161
45162
45163
45164
45165
45166
45167
45168
45169
45170
45171
45172
45173
45174
45175
45176
45177
45178
45179
45180
45181
45182
45183
45184
45185
45186
45187
45188
45189
45190
45191
45192
45193
45194
45195
45196
45197
45198
45199
45200
45201
45202
45203
45204
45205
45206
45207
45208
45209
45210
45211
45212
45213
45214
45215
45216
45217
45218
45219
45220
45221
45222
45223
45224
45225
45226
45227
45228
45229
45230
45231
45232
45233
45234
45235
45236
45237
45238
45239
45240
45241
45242
45243
45244
45245
45246
45247
45248
45249
45250
45251
45252
45253
45254
45255
45256
45257
45258
45259
45260
45261
45262
45263
45264
45265
45266
45267
45268
45269
45270
45271
45272
45273
45274
45275
45276
45277
45278
45279
45280
45281
45282
45283
45284
45285
45286
45287
45288
45289
45290
45291
45292
45293
45294
45295
45296
45297
45298
45299
45300
45301
45302
45303
45304
45305
45306
45307
45308
45309
45310
45311
45312
45313
45314
45315
45316
45317
45318
45319
45320
45321
45322
45323
45324
45325
45326
45327
45328
45329
45330
45331
45332
45333
45334
45335
45336
45337
45338
45339
45340
45341
45342
45343
45344
45345
45346
45347
45348
45349
45350
45351
45352
45353
45354
45355
45356
45357
45358
45359
45360
45361
45362
45363
45364
45365
45366
45367
45368
45369
45370
45371
45372
45373
45374
45375
45376
45377
45378
45379
45380
45381
45382
45383
45384
45385
45386
45387
45388
45389
45390
45391
45392
45393
45394
45395
45396
45397
45398
45399
45400
45401
45402
45403
45404
45405
45406
45407
45408
45409
45410
45411
45412
45413
45414
45415
45416
45417
45418
45419
45420
45421
45422
45423
45424
45425
45426
45427
45428
45429
45430
45431
45432
45433
45434
45435
45436
45437
45438
45439
45440
45441
45442
45443
45444
45445
45446
45447
45448
45449
45450
45451
45452
45453
45454
45455
45456
45457
45458
45459
45460
45461
45462
45463
45464
45465
45466
45467
45468
45469
45470
45471
45472
45473
45474
45475
45476
45477
45478
45479
45480
45481
45482
45483
45484
45485
45486
45487
45488
45489
45490
45491
45492
45493
45494
45495
45496
45497
45498
45499
45500
45501
45502
45503
45504
45505
45506
45507
45508
45509
45510
45511
45512
45513
45514
45515
45516
45517
45518
45519
45520
45521
45522
45523
45524
45525
45526
45527
45528
45529
45530
45531
45532
45533
45534
45535
45536
45537
45538
45539
45540
45541
45542
45543
45544
45545
45546
45547
45548
45549
45550
45551
45552
45553
45554
45555
45556
45557
45558
45559
45560
45561
45562
45563
45564
45565
45566
45567
45568
45569
45570
45571
45572
45573
45574
45575
45576
45577
45578
45579
45580
45581
45582
45583
45584
45585
45586
45587
45588
45589
45590
45591
45592
45593
45594
45595
45596
45597
45598
45599
45600
45601
45602
45603
45604
45605
45606
45607
45608
45609
45610
45611
45612
45613
45614
45615
45616
45617
45618
45619
45620
45621
45622
45623
45624
45625
45626
45627
45628
45629
45630
45631
45632
45633
45634
45635
45636
45637
45638
45639
45640
45641
45642
45643
45644
45645
45646
45647
45648
45649
45650
45651
45652
45653
45654
45655
45656
45657
45658
45659
45660
45661
45662
45663
45664
45665
45666
45667
45668
45669
45670
45671
45672
45673
45674
45675
45676
45677
45678
45679
45680
45681
45682
45683
45684
45685
45686
45687
45688
45689
45690
45691
45692
45693
45694
45695
45696
45697
45698
45699
45700
45701
45702
45703
45704
45705
45706
45707
45708
45709
45710
45711
45712
45713
45714
45715
45716
45717
45718
45719
45720
45721
45722
45723
45724
45725
45726
45727
45728
45729
45730
45731
45732
45733
45734
45735
45736
45737
45738
45739
45740
45741
45742
45743
45744
45745
45746
45747
45748
45749
45750
45751
45752
45753
45754
45755
45756
45757
45758
45759
45760
45761
45762
45763
45764
45765
45766
45767
45768
45769
45770
45771
45772
45773
45774
45775
45776
45777
45778
45779
45780
45781
45782
45783
45784
45785
45786
45787
45788
45789
45790
45791
45792
45793
45794
45795
45796
45797
45798
45799
45800
45801
45802
45803
45804
45805
45806
45807
45808
45809
45810
45811
45812
45813
45814
45815
45816
45817
45818
45819
45820
45821
45822
45823
45824
45825
45826
45827
45828
45829
45830
45831
45832
45833
45834
45835
45836
45837
45838
45839
45840
45841
45842
45843
45844
45845
45846
45847
45848
45849
45850
45851
45852
45853
45854
45855
45856
45857
45858
45859
45860
45861
45862
45863
45864
45865
45866
45867
45868
45869
45870
45871
45872
45873
45874
45875
45876
45877
45878
45879
45880
45881
45882
45883
45884
45885
45886
45887
45888
45889
45890
45891
45892
45893
45894
45895
45896
45897
45898
45899
45900
45901
45902
45903
45904
45905
45906
45907
45908
45909
45910
45911
45912
45913
45914
45915
45916
45917
45918
45919
45920
45921
45922
45923
45924
45925
45926
45927
45928
45929
45930
45931
45932
45933
45934
45935
45936
45937
45938
45939
45940
45941
45942
45943
45944
45945
45946
45947
45948
45949
45950
45951
45952
45953
45954
45955
45956
45957
45958
45959
45960
45961
45962
45963
45964
45965
45966
45967
45968
45969
45970
45971
45972
45973
45974
45975
45976
45977
45978
45979
45980
45981
45982
45983
45984
45985
45986
45987
45988
45989
45990
45991
45992
45993
45994
45995
45996
45997
45998
45999
46000
46001
46002
46003
46004
46005
46006
46007
46008
46009
46010
46011
46012
46013
46014
46015
46016
46017
46018
46019
46020
46021
46022
46023
46024
46025
46026
46027
46028
46029
46030
46031
46032
46033
46034
46035
46036
46037
46038
46039
46040
46041
46042
46043
46044
46045
46046
46047
46048
46049
46050
46051
46052
46053
46054
46055
46056
46057
46058
46059
46060
46061
46062
46063
46064
46065
46066
46067
46068
46069
46070
46071
46072
46073
46074
46075
46076
46077
46078
46079
46080
46081
46082
46083
46084
46085
46086
46087
46088
46089
46090
46091
46092
46093
46094
46095
46096
46097
46098
46099
46100
46101
46102
46103
46104
46105
46106
46107
46108
46109
46110
46111
46112
46113
46114
46115
46116
46117
46118
46119
46120
46121
46122
46123
46124
46125
46126
46127
46128
46129
46130
46131
46132
46133
46134
46135
46136
46137
46138
46139
46140
46141
46142
46143
46144
46145
46146
46147
46148
46149
46150
46151
46152
46153
46154
46155
46156
46157
46158
46159
46160
46161
46162
46163
46164
46165
46166
46167
46168
46169
46170
46171
46172
46173
46174
46175
46176
46177
46178
46179
46180
46181
46182
46183
46184
46185
46186
46187
46188
46189
46190
46191
46192
46193
46194
46195
46196
46197
46198
46199
46200
46201
46202
46203
46204
46205
46206
46207
46208
46209
46210
46211
46212
46213
46214
46215
46216
46217
46218
46219
46220
46221
46222
46223
46224
46225
46226
46227
46228
46229
46230
46231
46232
46233
46234
46235
46236
46237
46238
46239
46240
46241
46242
46243
46244
46245
46246
46247
46248
46249
46250
46251
46252
46253
46254
46255
46256
46257
46258
46259
46260
46261
46262
46263
46264
46265
46266
46267
46268
46269
46270
46271
46272
46273
46274
46275
46276
46277
46278
46279
46280
46281
46282
46283
46284
46285
46286
46287
46288
46289
46290
46291
46292
46293
46294
46295
46296
46297
46298
46299
46300
46301
46302
46303
46304
46305
46306
46307
46308
46309
46310
46311
46312
46313
46314
46315
46316
46317
46318
46319
46320
46321
46322
46323
46324
46325
46326
46327
46328
46329
46330
46331
46332
46333
46334
46335
46336
46337
46338
46339
46340
46341
46342
46343
46344
46345
46346
46347
46348
46349
46350
46351
46352
46353
46354
46355
46356
46357
46358
46359
46360
46361
46362
46363
46364
46365
46366
46367
46368
46369
46370
46371
46372
46373
46374
46375
46376
46377
46378
46379
46380
46381
46382
46383
46384
46385
46386
46387
46388
46389
46390
46391
46392
46393
46394
46395
46396
46397
46398
46399
46400
46401
46402
46403
46404
46405
46406
46407
46408
46409
46410
46411
46412
46413
46414
46415
46416
46417
46418
46419
46420
46421
46422
46423
46424
46425
46426
46427
46428
46429
46430
46431
46432
46433
46434
46435
46436
46437
46438
46439
46440
46441
46442
46443
46444
46445
46446
46447
46448
46449
46450
46451
46452
46453
46454
46455
46456
46457
46458
46459
46460
46461
46462
46463
46464
46465
46466
46467
46468
46469
46470
46471
46472
46473
46474
46475
46476
46477
46478
46479
46480
46481
46482
46483
46484
46485
46486
46487
46488
46489
46490
46491
46492
46493
46494
46495
46496
46497
46498
46499
46500
46501
46502
46503
46504
46505
46506
46507
46508
46509
46510
46511
46512
46513
46514
46515
46516
46517
46518
46519
46520
46521
46522
46523
46524
46525
46526
46527
46528
46529
46530
46531
46532
46533
46534
46535
46536
46537
46538
46539
46540
46541
46542
46543
46544
46545
46546
46547
46548
46549
46550
46551
46552
46553
46554
46555
46556
46557
46558
46559
46560
46561
46562
46563
46564
46565
46566
46567
46568
46569
46570
46571
46572
46573
46574
46575
46576
46577
46578
46579
46580
46581
46582
46583
46584
46585
46586
46587
46588
46589
46590
46591
46592
46593
46594
46595
46596
46597
46598
46599
46600
46601
46602
46603
46604
46605
46606
46607
46608
46609
46610
46611
46612
46613
46614
46615
46616
46617
46618
46619
46620
46621
46622
46623
46624
46625
46626
46627
46628
46629
46630
46631
46632
46633
46634
46635
46636
46637
46638
46639
46640
46641
46642
46643
46644
46645
46646
46647
46648
46649
46650
46651
46652
46653
46654
46655
46656
46657
46658
46659
46660
46661
46662
46663
46664
46665
46666
46667
46668
46669
46670
46671
46672
46673
46674
46675
46676
46677
46678
46679
46680
46681
46682
46683
46684
46685
46686
46687
46688
46689
46690
46691
46692
46693
46694
46695
46696
46697
46698
46699
46700
46701
46702
46703
46704
46705
46706
46707
46708
46709
46710
46711
46712
46713
46714
46715
46716
46717
46718
46719
46720
46721
46722
46723
46724
46725
46726
46727
46728
46729
46730
46731
46732
46733
46734
46735
46736
46737
46738
46739
46740
46741
46742
46743
46744
46745
46746
46747
46748
46749
46750
46751
46752
46753
46754
46755
46756
46757
46758
46759
46760
46761
46762
46763
46764
46765
46766
46767
46768
46769
46770
46771
46772
46773
46774
46775
46776
46777
46778
46779
46780
46781
46782
46783
46784
46785
46786
46787
46788
46789
46790
46791
46792
46793
46794
46795
46796
46797
46798
46799
46800
46801
46802
46803
46804
46805
46806
46807
46808
46809
46810
46811
46812
46813
46814
46815
46816
46817
46818
46819
46820
46821
46822
46823
46824
46825
46826
46827
46828
46829
46830
46831
46832
46833
46834
46835
46836
46837
46838
46839
46840
46841
46842
46843
46844
46845
46846
46847
46848
46849
46850
46851
46852
46853
46854
46855
46856
46857
46858
46859
46860
46861
46862
46863
46864
46865
46866
46867
46868
46869
46870
46871
46872
46873
46874
46875
46876
46877
46878
46879
46880
46881
46882
46883
46884
46885
46886
46887
46888
46889
46890
46891
46892
46893
46894
46895
46896
46897
46898
46899
46900
46901
46902
46903
46904
46905
46906
46907
46908
46909
46910
46911
46912
46913
46914
46915
46916
46917
46918
46919
46920
46921
46922
46923
46924
46925
46926
46927
46928
46929
46930
46931
46932
46933
46934
46935
46936
46937
46938
46939
46940
46941
46942
46943
46944
46945
46946
46947
46948
46949
46950
46951
46952
46953
46954
46955
46956
46957
46958
46959
46960
46961
46962
46963
46964
46965
46966
46967
46968
46969
46970
46971
46972
46973
46974
46975
46976
46977
46978
46979
46980
46981
46982
46983
46984
46985
46986
46987
46988
46989
46990
46991
46992
46993
46994
46995
46996
46997
46998
46999
47000
47001
47002
47003
47004
47005
47006
47007
47008
47009
47010
47011
47012
47013
47014
47015
47016
47017
47018
47019
47020
47021
47022
47023
47024
47025
47026
47027
47028
47029
47030
47031
47032
47033
47034
47035
47036
47037
47038
47039
47040
47041
47042
47043
47044
47045
47046
47047
47048
47049
47050
47051
47052
47053
47054
47055
47056
47057
47058
47059
47060
47061
47062
47063
47064
47065
47066
47067
47068
47069
47070
47071
47072
47073
47074
47075
47076
47077
47078
47079
47080
47081
47082
47083
47084
47085
47086
47087
47088
47089
47090
47091
47092
47093
47094
47095
47096
47097
47098
47099
47100
47101
47102
47103
47104
47105
47106
47107
47108
47109
47110
47111
47112
47113
47114
47115
47116
47117
47118
47119
47120
47121
47122
47123
47124
47125
47126
47127
47128
47129
47130
47131
47132
47133
47134
47135
47136
47137
47138
47139
47140
47141
47142
47143
47144
47145
47146
47147
47148
47149
47150
47151
47152
47153
47154
47155
47156
47157
47158
47159
47160
47161
47162
47163
47164
47165
47166
47167
47168
47169
47170
47171
47172
47173
47174
47175
47176
47177
47178
47179
47180
47181
47182
47183
47184
47185
47186
47187
47188
47189
47190
47191
47192
47193
47194
47195
47196
47197
47198
47199
47200
47201
47202
47203
47204
47205
47206
47207
47208
47209
47210
47211
47212
47213
47214
47215
47216
47217
47218
47219
47220
47221
47222
47223
47224
47225
47226
47227
47228
47229
47230
47231
47232
47233
47234
47235
47236
47237
47238
47239
47240
47241
47242
47243
47244
47245
47246
47247
47248
47249
47250
47251
47252
47253
47254
47255
47256
47257
47258
47259
47260
47261
47262
47263
47264
47265
47266
47267
47268
47269
47270
47271
47272
47273
47274
47275
47276
47277
47278
47279
47280
47281
47282
47283
47284
47285
47286
47287
47288
47289
47290
47291
47292
47293
47294
47295
47296
47297
47298
47299
47300
47301
47302
47303
47304
47305
47306
47307
47308
47309
47310
47311
47312
47313
47314
47315
47316
47317
47318
47319
47320
47321
47322
47323
47324
47325
47326
47327
47328
47329
47330
47331
47332
47333
47334
47335
47336
47337
47338
47339
47340
47341
47342
47343
47344
47345
47346
47347
47348
47349
47350
47351
47352
47353
47354
47355
47356
47357
47358
47359
47360
47361
47362
47363
47364
47365
47366
47367
47368
47369
47370
47371
47372
47373
47374
47375
47376
47377
47378
47379
47380
47381
47382
47383
47384
47385
47386
47387
47388
47389
47390
47391
47392
47393
47394
47395
47396
47397
47398
47399
47400
47401
47402
47403
47404
47405
47406
47407
47408
47409
47410
47411
47412
47413
47414
47415
47416
47417
47418
47419
47420
47421
47422
47423
47424
47425
47426
47427
47428
47429
47430
47431
47432
47433
47434
47435
47436
47437
47438
47439
47440
47441
47442
47443
47444
47445
47446
47447
47448
47449
47450
47451
47452
47453
47454
47455
47456
47457
47458
47459
47460
47461
47462
47463
47464
47465
47466
47467
47468
47469
47470
47471
47472
47473
47474
47475
47476
47477
47478
47479
47480
47481
47482
47483
47484
47485
47486
47487
47488
47489
47490
47491
47492
47493
47494
47495
47496
47497
47498
47499
47500
47501
47502
47503
47504
47505
47506
47507
47508
47509
47510
47511
47512
47513
47514
47515
47516
47517
47518
47519
47520
47521
47522
47523
47524
47525
47526
47527
47528
47529
47530
47531
47532
47533
47534
47535
47536
47537
47538
47539
47540
47541
47542
47543
47544
47545
47546
47547
47548
47549
47550
47551
47552
47553
47554
47555
47556
47557
47558
47559
47560
47561
47562
47563
47564
47565
47566
47567
47568
47569
47570
47571
47572
47573
47574
47575
47576
47577
47578
47579
47580
47581
47582
47583
47584
47585
47586
47587
47588
47589
47590
47591
47592
47593
47594
47595
47596
47597
47598
47599
47600
47601
47602
47603
47604
47605
47606
47607
47608
47609
47610
47611
47612
47613
47614
47615
47616
47617
47618
47619
47620
47621
47622
47623
47624
47625
47626
47627
47628
47629
47630
47631
47632
47633
47634
47635
47636
47637
47638
47639
47640
47641
47642
47643
47644
47645
47646
47647
47648
47649
47650
47651
47652
47653
47654
47655
47656
47657
47658
47659
47660
47661
47662
47663
47664
47665
47666
47667
47668
47669
47670
47671
47672
47673
47674
47675
47676
47677
47678
47679
47680
47681
47682
47683
47684
47685
47686
47687
47688
47689
47690
47691
47692
47693
47694
47695
47696
47697
47698
47699
47700
47701
47702
47703
47704
47705
47706
47707
47708
47709
47710
47711
47712
47713
47714
47715
47716
47717
47718
47719
47720
47721
47722
47723
47724
47725
47726
47727
47728
47729
47730
47731
47732
47733
47734
47735
47736
47737
47738
47739
47740
47741
47742
47743
47744
47745
47746
47747
47748
47749
47750
47751
47752
47753
47754
47755
47756
47757
47758
47759
47760
47761
47762
47763
47764
47765
47766
47767
47768
47769
47770
47771
47772
47773
47774
47775
47776
47777
47778
47779
47780
47781
47782
47783
47784
47785
47786
47787
47788
47789
47790
47791
47792
47793
47794
47795
47796
47797
47798
47799
47800
47801
47802
47803
47804
47805
47806
47807
47808
47809
47810
47811
47812
47813
47814
47815
47816
47817
47818
47819
47820
47821
47822
47823
47824
47825
47826
47827
47828
47829
47830
47831
47832
47833
47834
47835
47836
47837
47838
47839
47840
47841
47842
47843
47844
47845
47846
47847
47848
47849
47850
47851
47852
47853
47854
47855
47856
47857
47858
47859
47860
47861
47862
47863
47864
47865
47866
47867
47868
47869
47870
47871
47872
47873
47874
47875
47876
47877
47878
47879
47880
47881
47882
47883
47884
47885
47886
47887
47888
47889
47890
47891
47892
47893
47894
47895
47896
47897
47898
47899
47900
47901
47902
47903
47904
47905
47906
47907
47908
47909
47910
47911
47912
47913
47914
47915
47916
47917
47918
47919
47920
47921
47922
47923
47924
47925
47926
47927
47928
47929
47930
47931
47932
47933
47934
47935
47936
47937
47938
47939
47940
47941
47942
47943
47944
47945
47946
47947
47948
47949
47950
47951
47952
47953
47954
47955
47956
47957
47958
47959
47960
47961
47962
47963
47964
47965
47966
47967
47968
47969
47970
47971
47972
47973
47974
47975
47976
47977
47978
47979
47980
47981
47982
47983
47984
47985
47986
47987
47988
47989
47990
47991
47992
47993
47994
47995
47996
47997
47998
47999
48000
48001
48002
48003
48004
48005
48006
48007
48008
48009
48010
48011
48012
48013
48014
48015
48016
48017
48018
48019
48020
48021
48022
48023
48024
48025
48026
48027
48028
48029
48030
48031
48032
48033
48034
48035
48036
48037
48038
48039
48040
48041
48042
48043
48044
48045
48046
48047
48048
48049
48050
48051
48052
48053
48054
48055
48056
48057
48058
48059
48060
48061
48062
48063
48064
48065
48066
48067
48068
48069
48070
48071
48072
48073
48074
48075
48076
48077
48078
48079
48080
48081
48082
48083
48084
48085
48086
48087
48088
48089
48090
48091
48092
48093
48094
48095
48096
48097
48098
48099
48100
48101
48102
48103
48104
48105
48106
48107
48108
48109
48110
48111
48112
48113
48114
48115
48116
48117
48118
48119
48120
48121
48122
48123
48124
48125
48126
48127
48128
48129
48130
48131
48132
48133
48134
48135
48136
48137
48138
48139
48140
48141
48142
48143
48144
48145
48146
48147
48148
48149
48150
48151
48152
48153
48154
48155
48156
48157
48158
48159
48160
48161
48162
48163
48164
48165
48166
48167
48168
48169
48170
48171
48172
48173
48174
48175
48176
48177
48178
48179
48180
48181
48182
48183
48184
48185
48186
48187
48188
48189
48190
48191
48192
48193
48194
48195
48196
48197
48198
48199
48200
48201
48202
48203
48204
48205
48206
48207
48208
48209
48210
48211
48212
48213
48214
48215
48216
48217
48218
48219
48220
48221
48222
48223
48224
48225
48226
48227
48228
48229
48230
48231
48232
48233
48234
48235
48236
48237
48238
48239
48240
48241
48242
48243
48244
48245
48246
48247
48248
48249
48250
48251
48252
48253
48254
48255
48256
48257
48258
48259
48260
48261
48262
48263
48264
48265
48266
48267
48268
48269
48270
48271
48272
48273
48274
48275
48276
48277
48278
48279
48280
48281
48282
48283
48284
48285
48286
48287
48288
48289
48290
48291
48292
48293
48294
48295
48296
48297
48298
48299
48300
48301
48302
48303
48304
48305
48306
48307
48308
48309
48310
48311
48312
48313
48314
48315
48316
48317
48318
48319
48320
48321
48322
48323
48324
48325
48326
48327
48328
48329
48330
48331
48332
48333
48334
48335
48336
48337
48338
48339
48340
48341
48342
48343
48344
48345
48346
48347
48348
48349
48350
48351
48352
48353
48354
48355
48356
48357
48358
48359
48360
48361
48362
48363
48364
48365
48366
48367
48368
48369
48370
48371
48372
48373
48374
48375
48376
48377
48378
48379
48380
48381
48382
48383
48384
48385
48386
48387
48388
48389
48390
48391
48392
48393
48394
48395
48396
48397
48398
48399
48400
48401
48402
48403
48404
48405
48406
48407
48408
48409
48410
48411
48412
48413
48414
48415
48416
48417
48418
48419
48420
48421
48422
48423
48424
48425
48426
48427
48428
48429
48430
48431
48432
48433
48434
48435
48436
48437
48438
48439
48440
48441
48442
48443
48444
48445
48446
48447
48448
48449
48450
48451
48452
48453
48454
48455
48456
48457
48458
48459
48460
48461
48462
48463
48464
48465
48466
48467
48468
48469
48470
48471
48472
48473
48474
48475
48476
48477
48478
48479
48480
48481
48482
48483
48484
48485
48486
48487
48488
48489
48490
48491
48492
48493
48494
48495
48496
48497
48498
48499
48500
48501
48502
48503
48504
48505
48506
48507
48508
48509
48510
48511
48512
48513
48514
48515
48516
48517
48518
48519
48520
48521
48522
48523
48524
48525
48526
48527
48528
48529
48530
48531
48532
48533
48534
48535
48536
48537
48538
48539
48540
48541
48542
48543
48544
48545
48546
48547
48548
48549
48550
48551
48552
48553
48554
48555
48556
48557
48558
48559
48560
48561
48562
48563
48564
48565
48566
48567
48568
48569
48570
48571
48572
48573
48574
48575
48576
48577
48578
48579
48580
48581
48582
48583
48584
48585
48586
48587
48588
48589
48590
48591
48592
48593
48594
48595
48596
48597
48598
48599
48600
48601
48602
48603
48604
48605
48606
48607
48608
48609
48610
48611
48612
48613
48614
48615
48616
48617
48618
48619
48620
48621
48622
48623
48624
48625
48626
48627
48628
48629
48630
48631
48632
48633
48634
48635
48636
48637
48638
48639
48640
48641
48642
48643
48644
48645
48646
48647
48648
48649
48650
48651
48652
48653
48654
48655
48656
48657
48658
48659
48660
48661
48662
48663
48664
48665
48666
48667
48668
48669
48670
48671
48672
48673
48674
48675
48676
48677
48678
48679
48680
48681
48682
48683
48684
48685
48686
48687
48688
48689
48690
48691
48692
48693
48694
48695
48696
48697
48698
48699
48700
48701
48702
48703
48704
48705
48706
48707
48708
48709
48710
48711
48712
48713
48714
48715
48716
48717
48718
48719
48720
48721
48722
48723
48724
48725
48726
48727
48728
48729
48730
48731
48732
48733
48734
48735
48736
48737
48738
48739
48740
48741
48742
48743
48744
48745
48746
48747
48748
48749
48750
48751
48752
48753
48754
48755
48756
48757
48758
48759
48760
48761
48762
48763
48764
48765
48766
48767
48768
48769
48770
48771
48772
48773
48774
48775
48776
48777
48778
48779
48780
48781
48782
48783
48784
48785
48786
48787
48788
48789
48790
48791
48792
48793
48794
48795
48796
48797
48798
48799
48800
48801
48802
48803
48804
48805
48806
48807
48808
48809
48810
48811
48812
48813
48814
48815
48816
48817
48818
48819
48820
48821
48822
48823
48824
48825
48826
48827
48828
48829
48830
48831
48832
48833
48834
48835
48836
48837
48838
48839
48840
48841
48842
48843
48844
48845
48846
48847
48848
48849
48850
48851
48852
48853
48854
48855
48856
48857
48858
48859
48860
48861
48862
48863
48864
48865
48866
48867
48868
48869
48870
48871
48872
48873
48874
48875
48876
48877
48878
48879
48880
48881
48882
48883
48884
48885
48886
48887
48888
48889
48890
48891
48892
48893
48894
48895
48896
48897
48898
48899
48900
48901
48902
48903
48904
48905
48906
48907
48908
48909
48910
48911
48912
48913
48914
48915
48916
48917
48918
48919
48920
48921
48922
48923
48924
48925
48926
48927
48928
48929
48930
48931
48932
48933
48934
48935
48936
48937
48938
48939
48940
48941
48942
48943
48944
48945
48946
48947
48948
48949
48950
48951
48952
48953
48954
48955
48956
48957
48958
48959
48960
48961
48962
48963
48964
48965
48966
48967
48968
48969
48970
48971
48972
48973
48974
48975
48976
48977
48978
48979
48980
48981
48982
48983
48984
48985
48986
48987
48988
48989
48990
48991
48992
48993
48994
48995
48996
48997
48998
48999
49000
49001
49002
49003
49004
49005
49006
49007
49008
49009
49010
49011
49012
49013
49014
49015
49016
49017
49018
49019
49020
49021
49022
49023
49024
49025
49026
49027
49028
49029
49030
49031
49032
49033
49034
49035
49036
49037
49038
49039
49040
49041
49042
49043
49044
49045
49046
49047
49048
49049
49050
49051
49052
49053
49054
49055
49056
49057
49058
49059
49060
49061
49062
49063
49064
49065
49066
49067
49068
49069
49070
49071
49072
49073
49074
49075
49076
49077
49078
49079
49080
49081
49082
49083
49084
49085
49086
49087
49088
49089
49090
49091
49092
49093
49094
49095
49096
49097
49098
49099
49100
49101
49102
49103
49104
49105
49106
49107
49108
49109
49110
49111
49112
49113
49114
49115
49116
49117
49118
49119
49120
49121
49122
49123
49124
49125
49126
49127
49128
49129
49130
49131
49132
49133
49134
49135
49136
49137
49138
49139
49140
49141
49142
49143
49144
49145
49146
49147
49148
49149
49150
49151
49152
49153
49154
49155
49156
49157
49158
49159
49160
49161
49162
49163
49164
49165
49166
49167
49168
49169
49170
49171
49172
49173
49174
49175
49176
49177
49178
49179
49180
49181
49182
49183
49184
49185
49186
49187
49188
49189
49190
49191
49192
49193
49194
49195
49196
49197
49198
49199
49200
49201
49202
49203
49204
49205
49206
49207
49208
49209
49210
49211
49212
49213
49214
49215
49216
49217
49218
49219
49220
49221
49222
49223
49224
49225
49226
49227
49228
49229
49230
49231
49232
49233
49234
49235
49236
49237
49238
49239
49240
49241
49242
49243
49244
49245
49246
49247
49248
49249
49250
49251
49252
49253
49254
49255
49256
49257
49258
49259
49260
49261
49262
49263
49264
49265
49266
49267
49268
49269
49270
49271
49272
49273
49274
49275
49276
49277
49278
49279
49280
49281
49282
49283
49284
49285
49286
49287
49288
49289
49290
49291
49292
49293
49294
49295
49296
49297
49298
49299
49300
49301
49302
49303
49304
49305
49306
49307
49308
49309
49310
49311
49312
49313
49314
49315
49316
49317
49318
49319
49320
49321
49322
49323
49324
49325
49326
49327
49328
49329
49330
49331
49332
49333
49334
49335
49336
49337
49338
49339
49340
49341
49342
49343
49344
49345
49346
49347
49348
49349
49350
49351
49352
49353
49354
49355
49356
49357
49358
49359
49360
49361
49362
49363
49364
49365
49366
49367
49368
49369
49370
49371
49372
49373
49374
49375
49376
49377
49378
49379
49380
49381
49382
49383
49384
49385
49386
49387
49388
49389
49390
49391
49392
49393
49394
49395
49396
49397
49398
49399
49400
49401
49402
49403
49404
49405
49406
49407
49408
49409
49410
49411
49412
49413
49414
49415
49416
49417
49418
49419
49420
49421
49422
49423
49424
49425
49426
49427
49428
49429
49430
49431
49432
49433
49434
49435
49436
49437
49438
49439
49440
49441
49442
49443
49444
49445
49446
49447
49448
49449
49450
49451
49452
49453
49454
49455
49456
49457
49458
49459
49460
49461
49462
49463
49464
49465
49466
49467
49468
49469
49470
49471
49472
49473
49474
49475
49476
49477
49478
49479
49480
49481
49482
49483
49484
49485
49486
49487
49488
49489
49490
49491
49492
49493
49494
49495
49496
49497
49498
49499
49500
49501
49502
49503
49504
49505
49506
49507
49508
49509
49510
49511
49512
49513
49514
49515
49516
49517
49518
49519
49520
49521
49522
49523
49524
49525
49526
49527
49528
49529
49530
49531
49532
49533
49534
49535
49536
49537
49538
49539
49540
49541
49542
49543
49544
49545
49546
49547
49548
49549
49550
49551
49552
49553
49554
49555
49556
49557
49558
49559
49560
49561
49562
49563
49564
49565
49566
49567
49568
49569
49570
49571
49572
49573
49574
49575
49576
49577
49578
49579
49580
49581
49582
49583
49584
49585
49586
49587
49588
49589
49590
49591
49592
49593
49594
49595
49596
49597
49598
49599
49600
49601
49602
49603
49604
49605
49606
49607
49608
49609
49610
49611
49612
49613
49614
49615
49616
49617
49618
49619
49620
49621
49622
49623
49624
49625
49626
49627
49628
49629
49630
49631
49632
49633
49634
49635
49636
49637
49638
49639
49640
49641
49642
49643
49644
49645
49646
49647
49648
49649
49650
49651
49652
49653
49654
49655
49656
49657
49658
49659
49660
49661
49662
49663
49664
49665
49666
49667
49668
49669
49670
49671
49672
49673
49674
49675
49676
49677
49678
49679
49680
49681
49682
49683
49684
49685
49686
49687
49688
49689
49690
49691
49692
49693
49694
49695
49696
49697
49698
49699
49700
49701
49702
49703
49704
49705
49706
49707
49708
49709
49710
49711
49712
49713
49714
49715
49716
49717
49718
49719
49720
49721
49722
49723
49724
49725
49726
49727
49728
49729
49730
49731
49732
49733
49734
49735
49736
49737
49738
49739
49740
49741
49742
49743
49744
49745
49746
49747
49748
49749
49750
49751
49752
49753
49754
49755
49756
49757
49758
49759
49760
49761
49762
49763
49764
49765
49766
49767
49768
49769
49770
49771
49772
49773
49774
49775
49776
49777
49778
49779
49780
49781
49782
49783
49784
49785
49786
49787
49788
49789
49790
49791
49792
49793
49794
49795
49796
49797
49798
49799
49800
49801
49802
49803
49804
49805
49806
49807
49808
49809
49810
49811
49812
49813
49814
49815
49816
49817
49818
49819
49820
49821
49822
49823
49824
49825
49826
49827
49828
49829
49830
49831
49832
49833
49834
49835
49836
49837
49838
49839
49840
49841
49842
49843
49844
49845
49846
49847
49848
49849
49850
49851
49852
49853
49854
49855
49856
49857
49858
49859
49860
49861
49862
49863
49864
49865
49866
49867
49868
49869
49870
49871
49872
49873
49874
49875
49876
49877
49878
49879
49880
49881
49882
49883
49884
49885
49886
49887
49888
49889
49890
49891
49892
49893
49894
49895
49896
49897
49898
49899
49900
49901
49902
49903
49904
49905
49906
49907
49908
49909
49910
49911
49912
49913
49914
49915
49916
49917
49918
49919
49920
49921
49922
49923
49924
49925
49926
49927
49928
49929
49930
49931
49932
49933
49934
49935
49936
49937
49938
49939
49940
49941
49942
49943
49944
49945
49946
49947
49948
49949
49950
49951
49952
49953
49954
49955
49956
49957
49958
49959
49960
49961
49962
49963
49964
49965
49966
49967
49968
49969
49970
49971
49972
49973
49974
49975
49976
49977
49978
49979
49980
49981
49982
49983
49984
49985
49986
49987
49988
49989
49990
49991
49992
49993
49994
49995
49996
49997
49998
49999
50000
50001
50002
50003
50004
50005
50006
50007
50008
50009
50010
50011
50012
50013
50014
50015
50016
50017
50018
50019
50020
50021
50022
50023
50024
50025
50026
50027
50028
50029
50030
50031
50032
50033
50034
50035
50036
50037
50038
50039
50040
50041
50042
50043
50044
50045
50046
50047
50048
50049
50050
50051
50052
50053
50054
50055
50056
50057
50058
50059
50060
50061
50062
50063
50064
50065
50066
50067
50068
50069
50070
50071
50072
50073
50074
50075
50076
50077
50078
50079
50080
50081
50082
50083
50084
50085
50086
50087
50088
50089
50090
50091
50092
50093
50094
50095
50096
50097
50098
50099
50100
50101
50102
50103
50104
50105
50106
50107
50108
50109
50110
50111
50112
50113
50114
50115
50116
50117
50118
50119
50120
50121
50122
50123
50124
50125
50126
50127
50128
50129
50130
50131
50132
50133
50134
50135
50136
50137
50138
50139
50140
50141
50142
50143
50144
50145
50146
50147
50148
50149
50150
50151
50152
50153
50154
50155
50156
50157
50158
50159
50160
50161
50162
50163
50164
50165
50166
50167
50168
50169
50170
50171
50172
50173
50174
50175
50176
50177
50178
50179
50180
50181
50182
50183
50184
50185
50186
50187
50188
50189
50190
50191
50192
50193
50194
50195
50196
50197
50198
50199
50200
50201
50202
50203
50204
50205
50206
50207
50208
50209
50210
50211
50212
50213
50214
50215
50216
50217
50218
50219
50220
50221
50222
50223
50224
50225
50226
50227
50228
50229
50230
50231
50232
50233
50234
50235
50236
50237
50238
50239
50240
50241
50242
50243
50244
50245
50246
50247
50248
50249
50250
50251
50252
50253
50254
50255
50256
50257
50258
50259
50260
50261
50262
50263
50264
50265
50266
50267
50268
50269
50270
50271
50272
50273
50274
50275
50276
50277
50278
50279
50280
50281
50282
50283
50284
50285
50286
50287
50288
50289
50290
50291
50292
50293
50294
50295
50296
50297
50298
50299
50300
50301
50302
50303
50304
50305
50306
50307
50308
50309
50310
50311
50312
50313
50314
50315
50316
50317
50318
50319
50320
50321
50322
50323
50324
50325
50326
50327
50328
50329
50330
50331
50332
50333
50334
50335
50336
50337
50338
50339
50340
50341
50342
50343
50344
50345
50346
50347
50348
50349
50350
50351
50352
50353
50354
50355
50356
50357
50358
50359
50360
50361
50362
50363
50364
50365
50366
50367
50368
50369
50370
50371
50372
50373
50374
50375
50376
50377
50378
50379
50380
50381
50382
50383
50384
50385
50386
50387
50388
50389
50390
50391
50392
50393
50394
50395
50396
50397
50398
50399
50400
50401
50402
50403
50404
50405
50406
50407
50408
50409
50410
50411
50412
50413
50414
50415
50416
50417
50418
50419
50420
50421
50422
50423
50424
50425
50426
50427
50428
50429
50430
50431
50432
50433
50434
50435
50436
50437
50438
50439
50440
50441
50442
50443
50444
50445
50446
50447
50448
50449
50450
50451
50452
50453
50454
50455
50456
50457
50458
50459
50460
50461
50462
50463
50464
50465
50466
50467
50468
50469
50470
50471
50472
50473
50474
50475
50476
50477
50478
50479
50480
50481
50482
50483
50484
50485
50486
50487
50488
50489
50490
50491
50492
50493
50494
50495
50496
50497
50498
50499
50500
50501
50502
50503
50504
50505
50506
50507
50508
50509
50510
50511
50512
50513
50514
50515
50516
50517
50518
50519
50520
50521
50522
50523
50524
50525
50526
50527
50528
50529
50530
50531
50532
50533
50534
50535
50536
50537
50538
50539
50540
50541
50542
50543
50544
50545
50546
50547
50548
50549
50550
50551
50552
50553
50554
50555
50556
50557
50558
50559
50560
50561
50562
50563
50564
50565
50566
50567
50568
50569
50570
50571
50572
50573
50574
50575
50576
50577
50578
50579
50580
50581
50582
50583
50584
50585
50586
50587
50588
50589
50590
50591
50592
50593
50594
50595
50596
50597
50598
50599
50600
50601
50602
50603
50604
50605
50606
50607
50608
50609
50610
50611
50612
50613
50614
50615
50616
50617
50618
50619
50620
50621
50622
50623
50624
50625
50626
50627
50628
50629
50630
50631
50632
50633
50634
50635
50636
50637
50638
50639
50640
50641
50642
50643
50644
50645
50646
50647
50648
50649
50650
50651
50652
50653
50654
50655
50656
50657
50658
50659
50660
50661
50662
50663
50664
50665
50666
50667
50668
50669
50670
50671
50672
50673
50674
50675
50676
50677
50678
50679
50680
50681
50682
50683
50684
50685
50686
50687
50688
50689
50690
50691
50692
50693
50694
50695
50696
50697
50698
50699
50700
50701
50702
50703
50704
50705
50706
50707
50708
50709
50710
50711
50712
50713
50714
50715
50716
50717
50718
50719
50720
50721
50722
50723
50724
50725
50726
50727
50728
50729
50730
50731
50732
50733
50734
50735
50736
50737
50738
50739
50740
50741
50742
50743
50744
50745
50746
50747
50748
50749
50750
50751
50752
50753
50754
50755
50756
50757
50758
50759
50760
50761
50762
50763
50764
50765
50766
50767
50768
50769
50770
50771
50772
50773
50774
50775
50776
50777
50778
50779
50780
50781
50782
50783
50784
50785
50786
50787
50788
50789
50790
50791
50792
50793
50794
50795
50796
50797
50798
50799
50800
50801
50802
50803
50804
50805
50806
50807
50808
50809
50810
50811
50812
50813
50814
50815
50816
50817
50818
50819
50820
50821
50822
50823
50824
50825
50826
50827
50828
50829
50830
50831
50832
50833
50834
50835
50836
50837
50838
50839
50840
50841
50842
50843
50844
50845
50846
50847
50848
50849
50850
50851
50852
50853
50854
50855
50856
50857
50858
50859
50860
50861
50862
50863
50864
50865
50866
50867
50868
50869
50870
50871
50872
50873
50874
50875
50876
50877
50878
50879
50880
50881
50882
50883
50884
50885
50886
50887
50888
50889
50890
50891
50892
50893
50894
50895
50896
50897
50898
50899
50900
50901
50902
50903
50904
50905
50906
50907
50908
50909
50910
50911
50912
50913
50914
50915
50916
50917
50918
50919
50920
50921
50922
50923
50924
50925
50926
50927
50928
50929
50930
50931
50932
50933
50934
50935
50936
50937
50938
50939
50940
50941
50942
50943
50944
50945
50946
50947
50948
50949
50950
50951
50952
50953
50954
50955
50956
50957
50958
50959
50960
50961
50962
50963
50964
50965
50966
50967
50968
50969
50970
50971
50972
50973
50974
50975
50976
50977
50978
50979
50980
50981
50982
50983
50984
50985
50986
50987
50988
50989
50990
50991
50992
50993
50994
50995
50996
50997
50998
50999
51000
51001
51002
51003
51004
51005
51006
51007
51008
51009
51010
51011
51012
51013
51014
51015
51016
51017
51018
51019
51020
51021
51022
51023
51024
51025
51026
51027
51028
51029
51030
51031
51032
51033
51034
51035
51036
51037
51038
51039
51040
51041
51042
51043
51044
51045
51046
51047
51048
51049
51050
51051
51052
51053
51054
51055
51056
51057
51058
51059
51060
51061
51062
51063
51064
51065
51066
51067
51068
51069
51070
51071
51072
51073
51074
51075
51076
51077
51078
51079
51080
51081
51082
51083
51084
51085
51086
51087
51088
51089
51090
51091
51092
51093
51094
51095
51096
51097
51098
51099
51100
51101
51102
51103
51104
51105
51106
51107
51108
51109
51110
51111
51112
51113
51114
51115
51116
51117
51118
51119
51120
51121
51122
51123
51124
51125
51126
51127
51128
51129
51130
51131
51132
51133
51134
51135
51136
51137
51138
51139
51140
51141
51142
51143
51144
51145
51146
51147
51148
51149
51150
51151
51152
51153
51154
51155
51156
51157
51158
51159
51160
51161
51162
51163
51164
51165
51166
51167
51168
51169
51170
51171
51172
51173
51174
51175
51176
51177
51178
51179
51180
51181
51182
51183
51184
51185
51186
51187
51188
51189
51190
51191
51192
51193
51194
51195
51196
51197
51198
51199
51200
51201
51202
51203
51204
51205
51206
51207
51208
51209
51210
51211
51212
51213
51214
51215
51216
51217
51218
51219
51220
51221
51222
51223
51224
51225
51226
51227
51228
51229
51230
51231
51232
51233
51234
51235
51236
51237
51238
51239
51240
51241
51242
51243
51244
51245
51246
51247
51248
51249
51250
51251
51252
51253
51254
51255
51256
51257
51258
51259
51260
51261
51262
51263
51264
51265
51266
51267
51268
51269
51270
51271
51272
51273
51274
51275
51276
51277
51278
51279
51280
51281
51282
51283
51284
51285
51286
51287
51288
51289
51290
51291
51292
51293
51294
51295
51296
51297
51298
51299
51300
51301
51302
51303
51304
51305
51306
51307
51308
51309
51310
51311
51312
51313
51314
51315
51316
51317
51318
51319
51320
51321
51322
51323
51324
51325
51326
51327
51328
51329
51330
51331
51332
51333
51334
51335
51336
51337
51338
51339
51340
51341
51342
51343
51344
51345
51346
51347
51348
51349
51350
51351
51352
51353
51354
51355
51356
51357
51358
51359
51360
51361
51362
51363
51364
51365
51366
51367
51368
51369
51370
51371
51372
51373
51374
51375
51376
51377
51378
51379
51380
51381
51382
51383
51384
51385
51386
51387
51388
51389
51390
51391
51392
51393
51394
51395
51396
51397
51398
51399
51400
51401
51402
51403
51404
51405
51406
51407
51408
51409
51410
51411
51412
51413
51414
51415
51416
51417
51418
51419
51420
51421
51422
51423
51424
51425
51426
51427
51428
51429
51430
51431
51432
51433
51434
51435
51436
51437
51438
51439
51440
51441
51442
51443
51444
51445
51446
51447
51448
51449
51450
51451
51452
51453
51454
51455
51456
51457
51458
51459
51460
51461
51462
51463
51464
51465
51466
51467
51468
51469
51470
51471
51472
51473
51474
51475
51476
51477
51478
51479
51480
51481
51482
51483
51484
51485
51486
51487
51488
51489
51490
51491
51492
51493
51494
51495
51496
51497
51498
51499
51500
51501
51502
51503
51504
51505
51506
51507
51508
51509
51510
51511
51512
51513
51514
51515
51516
51517
51518
51519
51520
51521
51522
51523
51524
51525
51526
51527
51528
51529
51530
51531
51532
51533
51534
51535
51536
51537
51538
51539
51540
51541
51542
51543
51544
51545
51546
51547
51548
51549
51550
51551
51552
51553
51554
51555
51556
51557
51558
51559
51560
51561
51562
51563
51564
51565
51566
51567
51568
51569
51570
51571
51572
51573
51574
51575
51576
51577
51578
51579
51580
51581
51582
51583
51584
51585
51586
51587
51588
51589
51590
51591
51592
51593
51594
51595
51596
51597
51598
51599
51600
51601
51602
51603
51604
51605
51606
51607
51608
51609
51610
51611
51612
51613
51614
51615
51616
51617
51618
51619
51620
51621
51622
51623
51624
51625
51626
51627
51628
51629
51630
51631
51632
51633
51634
51635
51636
51637
51638
51639
51640
51641
51642
51643
51644
51645
51646
51647
51648
51649
51650
51651
51652
51653
51654
51655
51656
51657
51658
51659
51660
51661
51662
51663
51664
51665
51666
51667
51668
51669
51670
51671
51672
51673
51674
51675
51676
51677
51678
51679
51680
51681
51682
51683
51684
51685
51686
51687
51688
51689
51690
51691
51692
51693
51694
51695
51696
51697
51698
51699
51700
51701
51702
51703
51704
51705
51706
51707
51708
51709
51710
51711
51712
51713
51714
51715
51716
51717
51718
51719
51720
51721
51722
51723
51724
51725
51726
51727
51728
51729
51730
51731
51732
51733
51734
51735
51736
51737
51738
51739
51740
51741
51742
51743
51744
51745
51746
51747
51748
51749
51750
51751
51752
51753
51754
51755
51756
51757
51758
51759
51760
51761
51762
51763
51764
51765
51766
51767
51768
51769
51770
51771
51772
51773
51774
51775
51776
51777
51778
51779
51780
51781
51782
51783
51784
51785
51786
51787
51788
51789
51790
51791
51792
51793
51794
51795
51796
51797
51798
51799
51800
51801
51802
51803
51804
51805
51806
51807
51808
51809
51810
51811
51812
51813
51814
51815
51816
51817
51818
51819
51820
51821
51822
51823
51824
51825
51826
51827
51828
51829
51830
51831
51832
51833
51834
51835
51836
51837
51838
51839
51840
51841
51842
51843
51844
51845
51846
51847
51848
51849
51850
51851
51852
51853
51854
51855
51856
51857
51858
51859
51860
51861
51862
51863
51864
51865
51866
51867
51868
51869
51870
51871
51872
51873
51874
51875
51876
51877
51878
51879
51880
51881
51882
51883
51884
51885
51886
51887
51888
51889
51890
51891
51892
51893
51894
51895
51896
51897
51898
51899
51900
51901
51902
51903
51904
51905
51906
51907
51908
51909
51910
51911
51912
51913
51914
51915
51916
51917
51918
51919
51920
51921
51922
51923
51924
51925
51926
51927
51928
51929
51930
51931
51932
51933
51934
51935
51936
51937
51938
51939
51940
51941
51942
51943
51944
51945
51946
51947
51948
51949
51950
51951
51952
51953
51954
51955
51956
51957
51958
51959
51960
51961
51962
51963
51964
51965
51966
51967
51968
51969
51970
51971
51972
51973
51974
51975
51976
51977
51978
51979
51980
51981
51982
51983
51984
51985
51986
51987
51988
51989
51990
51991
51992
51993
51994
51995
51996
51997
51998
51999
52000
52001
52002
52003
52004
52005
52006
52007
52008
52009
52010
52011
52012
52013
52014
52015
52016
52017
52018
52019
52020
52021
52022
52023
52024
52025
52026
52027
52028
52029
52030
52031
52032
52033
52034
52035
52036
52037
52038
52039
52040
52041
52042
52043
52044
52045
52046
52047
52048
52049
52050
52051
52052
52053
52054
52055
52056
52057
52058
52059
52060
52061
52062
52063
52064
52065
52066
52067
52068
52069
52070
52071
52072
52073
52074
52075
52076
52077
52078
52079
52080
52081
52082
52083
52084
52085
52086
52087
52088
52089
52090
52091
52092
52093
52094
52095
52096
52097
52098
52099
52100
52101
52102
52103
52104
52105
52106
52107
52108
52109
52110
52111
52112
52113
52114
52115
52116
52117
52118
52119
52120
52121
52122
52123
52124
52125
52126
52127
52128
52129
52130
52131
52132
52133
52134
52135
52136
52137
52138
52139
52140
52141
52142
52143
52144
52145
52146
52147
52148
52149
52150
52151
52152
52153
52154
52155
52156
52157
52158
52159
52160
52161
52162
52163
52164
52165
52166
52167
52168
52169
52170
52171
52172
52173
52174
52175
52176
52177
52178
52179
52180
52181
52182
52183
52184
52185
52186
52187
52188
52189
52190
52191
52192
52193
52194
52195
52196
52197
52198
52199
52200
52201
52202
52203
52204
52205
52206
52207
52208
52209
52210
52211
52212
52213
52214
52215
52216
52217
52218
52219
52220
52221
52222
52223
52224
52225
52226
52227
52228
52229
52230
52231
52232
52233
52234
52235
52236
52237
52238
52239
52240
52241
52242
52243
52244
52245
52246
52247
52248
52249
52250
52251
52252
52253
52254
52255
52256
52257
52258
52259
52260
52261
52262
52263
52264
52265
52266
52267
52268
52269
52270
52271
52272
52273
52274
52275
52276
52277
52278
52279
52280
52281
52282
52283
52284
52285
52286
52287
52288
52289
52290
52291
52292
52293
52294
52295
52296
52297
52298
52299
52300
52301
52302
52303
52304
52305
52306
52307
52308
52309
52310
52311
52312
52313
52314
52315
52316
52317
52318
52319
52320
52321
52322
52323
52324
52325
52326
52327
52328
52329
52330
52331
52332
52333
52334
52335
52336
52337
52338
52339
52340
52341
52342
52343
52344
52345
52346
52347
52348
52349
52350
52351
52352
52353
52354
52355
52356
52357
52358
52359
52360
52361
52362
52363
52364
52365
52366
52367
52368
52369
52370
52371
52372
52373
52374
52375
52376
52377
52378
52379
52380
52381
52382
52383
52384
52385
52386
52387
52388
52389
52390
52391
52392
52393
52394
52395
52396
52397
52398
52399
52400
52401
52402
52403
52404
52405
52406
52407
52408
52409
52410
52411
52412
52413
52414
52415
52416
52417
52418
52419
52420
52421
52422
52423
52424
52425
52426
52427
52428
52429
52430
52431
52432
52433
52434
52435
52436
52437
52438
52439
52440
52441
52442
52443
52444
52445
52446
52447
52448
52449
52450
52451
52452
52453
52454
52455
52456
52457
52458
52459
52460
52461
52462
52463
52464
52465
52466
52467
52468
52469
52470
52471
52472
52473
52474
52475
52476
52477
52478
52479
52480
52481
52482
52483
52484
52485
52486
52487
52488
52489
52490
52491
52492
52493
52494
52495
52496
52497
52498
52499
52500
52501
52502
52503
52504
52505
52506
52507
52508
52509
52510
52511
52512
52513
52514
52515
52516
52517
52518
52519
52520
52521
52522
52523
52524
52525
52526
52527
52528
52529
52530
52531
52532
52533
52534
52535
52536
52537
52538
52539
52540
52541
52542
52543
52544
52545
52546
52547
52548
52549
52550
52551
52552
52553
52554
52555
52556
52557
52558
52559
52560
52561
52562
52563
52564
52565
52566
52567
52568
52569
52570
52571
52572
52573
52574
52575
52576
52577
52578
52579
52580
52581
52582
52583
52584
52585
52586
52587
52588
52589
52590
52591
52592
52593
52594
52595
52596
52597
52598
52599
52600
52601
52602
52603
52604
52605
52606
52607
52608
52609
52610
52611
52612
52613
52614
52615
52616
52617
52618
52619
52620
52621
52622
52623
52624
52625
52626
52627
52628
52629
52630
52631
52632
52633
52634
52635
52636
52637
52638
52639
52640
52641
52642
52643
52644
52645
52646
52647
52648
52649
52650
52651
52652
52653
52654
52655
52656
52657
52658
52659
52660
52661
52662
52663
52664
52665
52666
52667
52668
52669
52670
52671
52672
52673
52674
52675
52676
52677
52678
52679
52680
52681
52682
52683
52684
52685
52686
52687
52688
52689
52690
52691
52692
52693
52694
52695
52696
52697
52698
52699
52700
52701
52702
52703
52704
52705
52706
52707
52708
52709
52710
52711
52712
52713
52714
52715
52716
52717
52718
52719
52720
52721
52722
52723
52724
52725
52726
52727
52728
52729
52730
52731
52732
52733
52734
52735
52736
52737
52738
52739
52740
52741
52742
52743
52744
52745
52746
52747
52748
52749
52750
52751
52752
52753
52754
52755
52756
52757
52758
52759
52760
52761
52762
52763
52764
52765
52766
52767
52768
52769
52770
52771
52772
52773
52774
52775
52776
52777
52778
52779
52780
52781
52782
52783
52784
52785
52786
52787
52788
52789
52790
52791
52792
52793
52794
52795
52796
52797
52798
52799
52800
52801
52802
52803
52804
52805
52806
52807
52808
52809
52810
52811
52812
52813
52814
52815
52816
52817
52818
52819
52820
52821
52822
52823
52824
52825
52826
52827
52828
52829
52830
52831
52832
52833
52834
52835
52836
52837
52838
52839
52840
52841
52842
52843
52844
52845
52846
52847
52848
52849
52850
52851
52852
52853
52854
52855
52856
52857
52858
52859
52860
52861
52862
52863
52864
52865
52866
52867
52868
52869
52870
52871
52872
52873
52874
52875
52876
52877
52878
52879
52880
52881
52882
52883
52884
52885
52886
52887
52888
52889
52890
52891
52892
52893
52894
52895
52896
52897
52898
52899
52900
52901
52902
52903
52904
52905
52906
52907
52908
52909
52910
52911
52912
52913
52914
52915
52916
52917
52918
52919
52920
52921
52922
52923
52924
52925
52926
52927
52928
52929
52930
52931
52932
52933
52934
52935
52936
52937
52938
52939
52940
52941
52942
52943
52944
52945
52946
52947
52948
52949
52950
52951
52952
52953
52954
52955
52956
52957
52958
52959
52960
52961
52962
52963
52964
52965
52966
52967
52968
52969
52970
52971
52972
52973
52974
52975
52976
52977
52978
52979
52980
52981
52982
52983
52984
52985
52986
52987
52988
52989
52990
52991
52992
52993
52994
52995
52996
52997
52998
52999
53000
53001
53002
53003
53004
53005
53006
53007
53008
53009
53010
53011
53012
53013
53014
53015
53016
53017
53018
53019
53020
53021
53022
53023
53024
53025
53026
53027
53028
53029
53030
53031
53032
53033
53034
53035
53036
53037
53038
53039
53040
53041
53042
53043
53044
53045
53046
53047
53048
53049
53050
53051
53052
53053
53054
53055
53056
53057
53058
53059
53060
53061
53062
53063
53064
53065
53066
53067
53068
53069
53070
53071
53072
53073
53074
53075
53076
53077
53078
53079
53080
53081
53082
53083
53084
53085
53086
53087
53088
53089
53090
53091
53092
53093
53094
53095
53096
53097
53098
53099
53100
53101
53102
53103
53104
53105
53106
53107
53108
53109
53110
53111
53112
53113
53114
53115
53116
53117
53118
53119
53120
53121
53122
53123
53124
53125
53126
53127
53128
53129
53130
53131
53132
53133
53134
53135
53136
53137
53138
53139
53140
53141
53142
53143
53144
53145
53146
53147
53148
53149
53150
53151
53152
53153
53154
53155
53156
53157
53158
53159
53160
53161
53162
53163
53164
53165
53166
53167
53168
53169
53170
53171
53172
53173
53174
53175
53176
53177
53178
53179
53180
53181
53182
53183
53184
53185
53186
53187
53188
53189
53190
53191
53192
53193
53194
53195
53196
53197
53198
53199
53200
53201
53202
53203
53204
53205
53206
53207
53208
53209
53210
53211
53212
53213
53214
53215
53216
53217
53218
53219
53220
53221
53222
53223
53224
53225
53226
53227
53228
53229
53230
53231
53232
53233
53234
53235
53236
53237
53238
53239
53240
53241
53242
53243
53244
53245
53246
53247
53248
53249
53250
53251
53252
53253
53254
53255
53256
53257
53258
53259
53260
53261
53262
53263
53264
53265
53266
53267
53268
53269
53270
53271
53272
53273
53274
53275
53276
53277
53278
53279
53280
53281
53282
53283
53284
53285
53286
53287
53288
53289
53290
53291
53292
53293
53294
53295
53296
53297
53298
53299
53300
53301
53302
53303
53304
53305
53306
53307
53308
53309
53310
53311
53312
53313
53314
53315
53316
53317
53318
53319
53320
53321
53322
53323
53324
53325
53326
53327
53328
53329
53330
53331
53332
53333
53334
53335
53336
53337
53338
53339
53340
53341
53342
53343
53344
53345
53346
53347
53348
53349
53350
53351
53352
53353
53354
53355
53356
53357
53358
53359
53360
53361
53362
53363
53364
53365
53366
53367
53368
53369
53370
53371
53372
53373
53374
53375
53376
53377
53378
53379
53380
53381
53382
53383
53384
53385
53386
53387
53388
53389
53390
53391
53392
53393
53394
53395
53396
53397
53398
53399
53400
53401
53402
53403
53404
53405
53406
53407
53408
53409
53410
53411
53412
53413
53414
53415
53416
53417
53418
53419
53420
53421
53422
53423
53424
53425
53426
53427
53428
53429
53430
53431
53432
53433
53434
53435
53436
53437
53438
53439
53440
53441
53442
53443
53444
53445
53446
53447
53448
53449
53450
53451
53452
53453
53454
53455
53456
53457
53458
53459
53460
53461
53462
53463
53464
53465
53466
53467
53468
53469
53470
53471
53472
53473
53474
53475
53476
53477
53478
53479
53480
53481
53482
53483
53484
53485
53486
53487
53488
53489
53490
53491
53492
53493
53494
53495
53496
53497
53498
53499
53500
53501
53502
53503
53504
53505
53506
53507
53508
53509
53510
53511
53512
53513
53514
53515
53516
53517
53518
53519
53520
53521
53522
53523
53524
53525
53526
53527
53528
53529
53530
53531
53532
53533
53534
53535
53536
53537
53538
53539
53540
53541
53542
53543
53544
53545
53546
53547
53548
53549
53550
53551
53552
53553
53554
53555
53556
53557
53558
53559
53560
53561
53562
53563
53564
53565
53566
53567
53568
53569
53570
53571
53572
53573
53574
53575
53576
53577
53578
53579
53580
53581
53582
53583
53584
53585
53586
53587
53588
53589
53590
53591
53592
53593
53594
53595
53596
53597
53598
53599
53600
53601
53602
53603
53604
53605
53606
53607
53608
53609
53610
53611
53612
53613
53614
53615
53616
53617
53618
53619
53620
53621
53622
53623
53624
53625
53626
53627
53628
53629
53630
53631
53632
53633
53634
53635
53636
53637
53638
53639
53640
53641
53642
53643
53644
53645
53646
53647
53648
53649
53650
53651
53652
53653
53654
53655
53656
53657
53658
53659
53660
53661
53662
53663
53664
53665
53666
53667
53668
53669
53670
53671
53672
53673
53674
53675
53676
53677
53678
53679
53680
53681
53682
53683
53684
53685
53686
53687
53688
53689
53690
53691
53692
53693
53694
53695
53696
53697
53698
53699
53700
53701
53702
53703
53704
53705
53706
53707
53708
53709
53710
53711
53712
53713
53714
53715
53716
53717
53718
53719
53720
53721
53722
53723
53724
53725
53726
53727
53728
53729
53730
53731
53732
53733
53734
53735
53736
53737
53738
53739
53740
53741
53742
53743
53744
53745
53746
53747
53748
53749
53750
53751
53752
53753
53754
53755
53756
53757
53758
53759
53760
53761
53762
53763
53764
53765
53766
53767
53768
53769
53770
53771
53772
53773
53774
53775
53776
53777
53778
53779
53780
53781
53782
53783
53784
53785
53786
53787
53788
53789
53790
53791
53792
53793
53794
53795
53796
53797
53798
53799
53800
53801
53802
53803
53804
53805
53806
53807
53808
53809
53810
53811
53812
53813
53814
53815
53816
53817
53818
53819
53820
53821
53822
53823
53824
53825
53826
53827
53828
53829
53830
53831
53832
53833
53834
53835
53836
53837
53838
53839
53840
53841
53842
53843
53844
53845
53846
53847
53848
53849
53850
53851
53852
53853
53854
53855
53856
53857
53858
53859
53860
53861
53862
53863
53864
53865
53866
53867
53868
53869
53870
53871
53872
53873
53874
53875
53876
53877
53878
53879
53880
53881
53882
53883
53884
53885
53886
53887
53888
53889
53890
53891
53892
53893
53894
53895
53896
53897
53898
53899
53900
53901
53902
53903
53904
53905
53906
53907
53908
53909
53910
53911
53912
53913
53914
53915
53916
53917
53918
53919
53920
53921
53922
53923
53924
53925
53926
53927
53928
53929
53930
53931
53932
53933
53934
53935
53936
53937
53938
53939
53940
53941
53942
53943
53944
53945
53946
53947
53948
53949
53950
53951
53952
53953
53954
53955
53956
53957
53958
53959
53960
53961
53962
53963
53964
53965
53966
53967
53968
53969
53970
53971
53972
53973
53974
53975
53976
53977
53978
53979
53980
53981
53982
53983
53984
53985
53986
53987
53988
53989
53990
53991
53992
53993
53994
53995
53996
53997
53998
53999
54000
54001
54002
54003
54004
54005
54006
54007
54008
54009
54010
54011
54012
54013
54014
54015
54016
54017
54018
54019
54020
54021
54022
54023
54024
54025
54026
54027
54028
54029
54030
54031
54032
54033
54034
54035
54036
54037
54038
54039
54040
54041
54042
54043
54044
54045
54046
54047
54048
54049
54050
54051
54052
54053
54054
54055
54056
54057
54058
54059
54060
54061
54062
54063
54064
54065
54066
54067
54068
54069
54070
54071
54072
54073
54074
54075
54076
54077
54078
54079
54080
54081
54082
54083
54084
54085
54086
54087
54088
54089
54090
54091
54092
54093
54094
54095
54096
54097
54098
54099
54100
54101
54102
54103
54104
54105
54106
54107
54108
54109
54110
54111
54112
54113
54114
54115
54116
54117
54118
54119
54120
54121
54122
54123
54124
54125
54126
54127
54128
54129
54130
54131
54132
54133
54134
54135
54136
54137
54138
54139
54140
54141
54142
54143
54144
54145
54146
54147
54148
54149
54150
54151
54152
54153
54154
54155
54156
54157
54158
54159
54160
54161
54162
54163
54164
54165
54166
54167
54168
54169
54170
54171
54172
54173
54174
54175
54176
54177
54178
54179
54180
54181
54182
54183
54184
54185
54186
54187
54188
54189
54190
54191
54192
54193
54194
54195
54196
54197
54198
54199
54200
54201
54202
54203
54204
54205
54206
54207
54208
54209
54210
54211
54212
54213
54214
54215
54216
54217
54218
54219
54220
54221
54222
54223
54224
54225
54226
54227
54228
54229
54230
54231
54232
54233
54234
54235
54236
54237
54238
54239
54240
54241
54242
54243
54244
54245
54246
54247
54248
54249
54250
54251
54252
54253
54254
54255
54256
54257
54258
54259
54260
54261
54262
54263
54264
54265
54266
54267
54268
54269
54270
54271
54272
54273
54274
54275
54276
54277
54278
54279
54280
54281
54282
54283
54284
54285
54286
54287
54288
54289
54290
54291
54292
54293
54294
54295
54296
54297
54298
54299
54300
54301
54302
54303
54304
54305
54306
54307
54308
54309
54310
54311
54312
54313
54314
54315
54316
54317
54318
54319
54320
54321
54322
54323
54324
54325
54326
54327
54328
54329
54330
54331
54332
54333
54334
54335
54336
54337
54338
54339
54340
54341
54342
54343
54344
54345
54346
54347
54348
54349
54350
54351
54352
54353
54354
54355
54356
54357
54358
54359
54360
54361
54362
54363
54364
54365
54366
54367
54368
54369
54370
54371
54372
54373
54374
54375
54376
54377
54378
54379
54380
54381
54382
54383
54384
54385
54386
54387
54388
54389
54390
54391
54392
54393
54394
54395
54396
54397
54398
54399
54400
54401
54402
54403
54404
54405
54406
54407
54408
54409
54410
54411
54412
54413
54414
54415
54416
54417
54418
54419
54420
54421
54422
54423
54424
54425
54426
54427
54428
54429
54430
54431
54432
54433
54434
54435
54436
54437
54438
54439
54440
54441
54442
54443
54444
54445
54446
54447
54448
54449
54450
54451
54452
54453
54454
54455
54456
54457
54458
54459
54460
54461
54462
54463
54464
54465
54466
54467
54468
54469
54470
54471
54472
54473
54474
54475
54476
54477
54478
54479
54480
54481
54482
54483
54484
54485
54486
54487
54488
54489
54490
54491
54492
54493
54494
54495
54496
54497
54498
54499
54500
54501
54502
54503
54504
54505
54506
54507
54508
54509
54510
54511
54512
54513
54514
54515
54516
54517
54518
54519
54520
54521
54522
54523
54524
54525
54526
54527
54528
54529
54530
54531
54532
54533
54534
54535
54536
54537
54538
54539
54540
54541
54542
54543
54544
54545
54546
54547
54548
54549
54550
54551
54552
54553
54554
54555
54556
54557
54558
54559
54560
54561
54562
54563
54564
54565
54566
54567
54568
54569
54570
54571
54572
54573
54574
54575
54576
54577
54578
54579
54580
54581
54582
54583
54584
54585
54586
54587
54588
54589
54590
54591
54592
54593
54594
54595
54596
54597
54598
54599
54600
54601
54602
54603
54604
54605
54606
54607
54608
54609
54610
54611
54612
54613
54614
54615
54616
54617
54618
54619
54620
54621
54622
54623
54624
54625
54626
54627
54628
54629
54630
54631
54632
54633
54634
54635
54636
54637
54638
54639
54640
54641
54642
54643
54644
54645
54646
54647
54648
54649
54650
54651
54652
54653
54654
54655
54656
54657
54658
54659
54660
54661
54662
54663
54664
54665
54666
54667
54668
54669
54670
54671
54672
54673
54674
54675
54676
54677
54678
54679
54680
54681
54682
54683
54684
54685
54686
54687
54688
54689
54690
54691
54692
54693
54694
54695
54696
54697
54698
54699
54700
54701
54702
54703
54704
54705
54706
54707
54708
54709
54710
54711
54712
54713
54714
54715
54716
54717
54718
54719
54720
54721
54722
54723
54724
54725
54726
54727
54728
54729
54730
54731
54732
54733
54734
54735
54736
54737
54738
54739
54740
54741
54742
54743
54744
54745
54746
54747
54748
54749
54750
54751
54752
54753
54754
54755
54756
54757
54758
54759
54760
54761
54762
54763
54764
54765
54766
54767
54768
54769
54770
54771
54772
54773
54774
54775
54776
54777
54778
54779
54780
54781
54782
54783
54784
54785
54786
54787
54788
54789
54790
54791
54792
54793
54794
54795
54796
54797
54798
54799
54800
54801
54802
54803
54804
54805
54806
54807
54808
54809
54810
54811
54812
54813
54814
54815
54816
54817
54818
54819
54820
54821
54822
54823
54824
54825
54826
54827
54828
54829
54830
54831
54832
54833
54834
54835
54836
54837
54838
54839
54840
54841
54842
54843
54844
54845
54846
54847
54848
54849
54850
54851
54852
54853
54854
54855
54856
54857
54858
54859
54860
54861
54862
54863
54864
54865
54866
54867
54868
54869
54870
54871
54872
54873
54874
54875
54876
54877
54878
54879
54880
54881
54882
54883
54884
54885
54886
54887
54888
54889
54890
54891
54892
54893
54894
54895
54896
54897
54898
54899
54900
54901
54902
54903
54904
54905
54906
54907
54908
54909
54910
54911
54912
54913
54914
54915
54916
54917
54918
54919
54920
54921
54922
54923
54924
54925
54926
54927
54928
54929
54930
54931
54932
54933
54934
54935
54936
54937
54938
54939
54940
54941
54942
54943
54944
54945
54946
54947
54948
54949
54950
54951
54952
54953
54954
54955
54956
54957
54958
54959
54960
54961
54962
54963
54964
54965
54966
54967
54968
54969
54970
54971
54972
54973
54974
54975
54976
54977
54978
54979
54980
54981
54982
54983
54984
54985
54986
54987
54988
54989
54990
54991
54992
54993
54994
54995
54996
54997
54998
54999
55000
55001
55002
55003
55004
55005
55006
55007
55008
55009
55010
55011
55012
55013
55014
55015
55016
55017
55018
55019
55020
55021
55022
55023
55024
55025
55026
55027
55028
55029
55030
55031
55032
55033
55034
55035
55036
55037
55038
55039
55040
55041
55042
55043
55044
55045
55046
55047
55048
55049
55050
55051
55052
55053
55054
55055
55056
55057
55058
55059
55060
55061
55062
55063
55064
55065
55066
55067
55068
55069
55070
55071
55072
55073
55074
55075
55076
55077
55078
55079
55080
55081
55082
55083
55084
55085
55086
55087
55088
55089
55090
55091
55092
55093
55094
55095
55096
55097
55098
55099
55100
55101
55102
55103
55104
55105
55106
55107
55108
55109
55110
55111
55112
55113
55114
55115
55116
55117
55118
55119
55120
55121
55122
55123
55124
55125
55126
55127
55128
55129
55130
55131
55132
55133
55134
55135
55136
55137
55138
55139
55140
55141
55142
55143
55144
55145
55146
55147
55148
55149
55150
55151
55152
55153
55154
55155
55156
55157
55158
55159
55160
55161
55162
55163
55164
55165
55166
55167
55168
55169
55170
55171
55172
55173
55174
55175
55176
55177
55178
55179
55180
55181
55182
55183
55184
55185
55186
55187
55188
55189
55190
55191
55192
55193
55194
55195
55196
55197
55198
55199
55200
55201
55202
55203
55204
55205
55206
55207
55208
55209
55210
55211
55212
55213
55214
55215
55216
55217
55218
55219
55220
55221
55222
55223
55224
55225
55226
55227
55228
55229
55230
55231
55232
55233
55234
55235
55236
55237
55238
55239
55240
55241
55242
55243
55244
55245
55246
55247
55248
55249
55250
55251
55252
55253
55254
55255
55256
55257
55258
55259
55260
55261
55262
55263
55264
55265
55266
55267
55268
55269
55270
55271
55272
55273
55274
55275
55276
55277
55278
55279
55280
55281
55282
55283
55284
55285
55286
55287
55288
55289
55290
55291
55292
55293
55294
55295
55296
55297
55298
55299
55300
55301
55302
55303
55304
55305
55306
55307
55308
55309
55310
55311
55312
55313
55314
55315
55316
55317
55318
55319
55320
55321
55322
55323
55324
55325
55326
55327
55328
55329
55330
55331
55332
55333
55334
55335
55336
55337
55338
55339
55340
55341
55342
55343
55344
55345
55346
55347
55348
55349
55350
55351
55352
55353
55354
55355
55356
55357
55358
55359
55360
55361
55362
55363
55364
55365
55366
55367
55368
55369
55370
55371
55372
55373
55374
55375
55376
55377
55378
55379
55380
55381
55382
55383
55384
55385
55386
55387
55388
55389
55390
55391
55392
55393
55394
55395
55396
55397
55398
55399
55400
55401
55402
55403
55404
55405
55406
55407
55408
55409
55410
55411
55412
55413
55414
55415
55416
55417
55418
55419
55420
55421
55422
55423
55424
55425
55426
55427
55428
55429
55430
55431
55432
55433
55434
55435
55436
55437
55438
55439
55440
55441
55442
55443
55444
55445
55446
55447
55448
55449
55450
55451
55452
55453
55454
55455
55456
55457
55458
55459
55460
55461
55462
55463
55464
55465
55466
55467
55468
55469
55470
55471
55472
55473
55474
55475
55476
55477
55478
55479
55480
55481
55482
55483
55484
55485
55486
55487
55488
55489
55490
55491
55492
55493
55494
55495
55496
55497
55498
55499
55500
55501
55502
55503
55504
55505
55506
55507
55508
55509
55510
55511
55512
55513
55514
55515
55516
55517
55518
55519
55520
55521
55522
55523
55524
55525
55526
55527
55528
55529
55530
55531
55532
55533
55534
55535
55536
55537
55538
55539
55540
55541
55542
55543
55544
55545
55546
55547
55548
55549
55550
55551
55552
55553
55554
55555
55556
55557
55558
55559
55560
55561
55562
55563
55564
55565
55566
55567
55568
55569
55570
55571
55572
55573
55574
55575
55576
55577
55578
55579
55580
55581
55582
55583
55584
55585
55586
55587
55588
55589
55590
55591
55592
55593
55594
55595
55596
55597
55598
55599
55600
55601
55602
55603
55604
55605
55606
55607
55608
55609
55610
55611
55612
55613
55614
55615
55616
55617
55618
55619
55620
55621
55622
55623
55624
55625
55626
55627
55628
55629
55630
55631
55632
55633
55634
55635
55636
55637
55638
55639
55640
55641
55642
55643
55644
55645
55646
55647
55648
55649
55650
55651
55652
55653
55654
55655
55656
55657
55658
55659
55660
55661
55662
55663
55664
55665
55666
55667
55668
55669
55670
55671
55672
55673
55674
55675
55676
55677
55678
55679
55680
55681
55682
55683
55684
55685
55686
55687
55688
55689
55690
55691
55692
55693
55694
55695
55696
55697
55698
55699
55700
55701
55702
55703
55704
55705
55706
55707
55708
55709
55710
55711
55712
55713
55714
55715
55716
55717
55718
55719
55720
55721
55722
55723
55724
55725
55726
55727
55728
55729
55730
55731
55732
55733
55734
55735
55736
55737
55738
55739
55740
55741
55742
55743
55744
55745
55746
55747
55748
55749
55750
55751
55752
55753
55754
55755
55756
55757
55758
55759
55760
55761
55762
55763
55764
55765
55766
55767
55768
55769
55770
55771
55772
55773
55774
55775
55776
55777
55778
55779
55780
55781
55782
55783
55784
55785
55786
55787
55788
55789
55790
55791
55792
55793
55794
55795
55796
55797
55798
55799
55800
55801
55802
55803
55804
55805
55806
55807
55808
55809
55810
55811
55812
55813
55814
55815
55816
55817
55818
55819
55820
55821
55822
55823
55824
55825
55826
55827
55828
55829
55830
55831
55832
55833
55834
55835
55836
55837
55838
55839
55840
55841
55842
55843
55844
55845
55846
55847
55848
55849
55850
55851
55852
55853
55854
55855
55856
55857
55858
55859
55860
55861
55862
55863
55864
55865
55866
55867
55868
55869
55870
55871
55872
55873
55874
55875
55876
55877
55878
55879
55880
55881
55882
55883
55884
55885
55886
55887
55888
55889
55890
55891
55892
55893
55894
55895
55896
55897
55898
55899
55900
55901
55902
55903
55904
55905
55906
55907
55908
55909
55910
55911
55912
55913
55914
55915
55916
55917
55918
55919
55920
55921
55922
55923
55924
55925
55926
55927
55928
55929
55930
55931
55932
55933
55934
55935
55936
55937
55938
55939
55940
55941
55942
55943
55944
55945
55946
55947
55948
55949
55950
55951
55952
55953
55954
55955
55956
55957
55958
55959
55960
55961
55962
55963
55964
55965
55966
55967
55968
55969
55970
55971
55972
55973
55974
55975
55976
55977
55978
55979
55980
55981
55982
55983
55984
55985
55986
55987
55988
55989
55990
55991
55992
55993
55994
55995
55996
55997
55998
55999
56000
56001
56002
56003
56004
56005
56006
56007
56008
56009
56010
56011
56012
56013
56014
56015
56016
56017
56018
56019
56020
56021
56022
56023
56024
56025
56026
56027
56028
56029
56030
56031
56032
56033
56034
56035
56036
56037
56038
56039
56040
56041
56042
56043
56044
56045
56046
56047
56048
56049
56050
56051
56052
56053
56054
56055
56056
56057
56058
56059
56060
56061
56062
56063
56064
56065
56066
56067
56068
56069
56070
56071
56072
56073
56074
56075
56076
56077
56078
56079
56080
56081
56082
56083
56084
56085
56086
56087
56088
56089
56090
56091
56092
56093
56094
56095
56096
56097
56098
56099
56100
56101
56102
56103
56104
56105
56106
56107
56108
56109
56110
56111
56112
56113
56114
56115
56116
56117
56118
56119
56120
56121
56122
56123
56124
56125
56126
56127
56128
56129
56130
56131
56132
56133
56134
56135
56136
56137
56138
56139
56140
56141
56142
56143
56144
56145
56146
56147
56148
56149
56150
56151
56152
56153
56154
56155
56156
56157
56158
56159
56160
56161
56162
56163
56164
56165
56166
56167
56168
56169
56170
56171
56172
56173
56174
56175
56176
56177
56178
56179
56180
56181
56182
56183
56184
56185
56186
56187
56188
56189
56190
56191
56192
56193
56194
56195
56196
56197
56198
56199
56200
56201
56202
56203
56204
56205
56206
56207
56208
56209
56210
56211
56212
56213
56214
56215
56216
56217
56218
56219
56220
56221
56222
56223
56224
56225
56226
56227
56228
56229
56230
56231
56232
56233
56234
56235
56236
56237
56238
56239
56240
56241
56242
56243
56244
56245
56246
56247
56248
56249
56250
56251
56252
56253
56254
56255
56256
56257
56258
56259
56260
56261
56262
56263
56264
56265
56266
56267
56268
56269
56270
56271
56272
56273
56274
56275
56276
56277
56278
56279
56280
56281
56282
56283
56284
56285
56286
56287
56288
56289
56290
56291
56292
56293
56294
56295
56296
56297
56298
56299
56300
56301
56302
56303
56304
56305
56306
56307
56308
56309
56310
56311
56312
56313
56314
56315
56316
56317
56318
56319
56320
56321
56322
56323
56324
56325
56326
56327
56328
56329
56330
56331
56332
56333
56334
56335
56336
56337
56338
56339
56340
56341
56342
56343
56344
56345
56346
56347
56348
56349
56350
56351
56352
56353
56354
56355
56356
56357
56358
56359
56360
56361
56362
56363
56364
56365
56366
56367
56368
56369
56370
56371
56372
56373
56374
56375
56376
56377
56378
56379
56380
56381
56382
56383
56384
56385
56386
56387
56388
56389
56390
56391
56392
56393
56394
56395
56396
56397
56398
56399
56400
56401
56402
56403
56404
56405
56406
56407
56408
56409
56410
56411
56412
56413
56414
56415
56416
56417
56418
56419
56420
56421
56422
56423
56424
56425
56426
56427
56428
56429
56430
56431
56432
56433
56434
56435
56436
56437
56438
56439
56440
56441
56442
56443
56444
56445
56446
56447
56448
56449
56450
56451
56452
56453
56454
56455
56456
56457
56458
56459
56460
56461
56462
56463
56464
56465
56466
56467
56468
56469
56470
56471
56472
56473
56474
56475
56476
56477
56478
56479
56480
56481
56482
56483
56484
56485
56486
56487
56488
56489
56490
56491
56492
56493
56494
56495
56496
56497
56498
56499
56500
56501
56502
56503
56504
56505
56506
56507
56508
56509
56510
56511
56512
56513
56514
56515
56516
56517
56518
56519
56520
56521
56522
56523
56524
56525
56526
56527
56528
56529
56530
56531
56532
56533
56534
56535
56536
56537
56538
56539
56540
56541
56542
56543
56544
56545
56546
56547
56548
56549
56550
56551
56552
56553
56554
56555
56556
56557
56558
56559
56560
56561
56562
56563
56564
56565
56566
56567
56568
56569
56570
56571
56572
56573
56574
56575
56576
56577
56578
56579
56580
56581
56582
56583
56584
56585
56586
56587
56588
56589
56590
56591
56592
56593
56594
56595
56596
56597
56598
56599
56600
56601
56602
56603
56604
56605
56606
56607
56608
56609
56610
56611
56612
56613
56614
56615
56616
56617
56618
56619
56620
56621
56622
56623
56624
56625
56626
56627
56628
56629
56630
56631
56632
56633
56634
56635
56636
56637
56638
56639
56640
56641
56642
56643
56644
56645
56646
56647
56648
56649
56650
56651
56652
56653
56654
56655
56656
56657
56658
56659
56660
56661
56662
56663
56664
56665
56666
56667
56668
56669
56670
56671
56672
56673
56674
56675
56676
56677
56678
56679
56680
56681
56682
56683
56684
56685
56686
56687
56688
56689
56690
56691
56692
56693
56694
56695
56696
56697
56698
56699
56700
56701
56702
56703
56704
56705
56706
56707
56708
56709
56710
56711
56712
56713
56714
56715
56716
56717
56718
56719
56720
56721
56722
56723
56724
56725
56726
56727
56728
56729
56730
56731
56732
56733
56734
56735
56736
56737
56738
56739
56740
56741
56742
56743
56744
56745
56746
56747
56748
56749
56750
56751
56752
56753
56754
56755
56756
56757
56758
56759
56760
56761
56762
56763
56764
56765
56766
56767
56768
56769
56770
56771
56772
56773
56774
56775
56776
56777
56778
56779
56780
56781
56782
56783
56784
56785
56786
56787
56788
56789
56790
56791
56792
56793
56794
56795
56796
56797
56798
56799
56800
56801
56802
56803
56804
56805
56806
56807
56808
56809
56810
56811
56812
56813
56814
56815
56816
56817
56818
56819
56820
56821
56822
56823
56824
56825
56826
56827
56828
56829
56830
56831
56832
56833
56834
56835
56836
56837
56838
56839
56840
56841
56842
56843
56844
56845
56846
56847
56848
56849
56850
56851
56852
56853
56854
56855
56856
56857
56858
56859
56860
56861
56862
56863
56864
56865
56866
56867
56868
56869
56870
56871
56872
56873
56874
56875
56876
56877
56878
56879
56880
56881
56882
56883
56884
56885
56886
56887
56888
56889
56890
56891
56892
56893
56894
56895
56896
56897
56898
56899
56900
56901
56902
56903
56904
56905
56906
56907
56908
56909
56910
56911
56912
56913
56914
56915
56916
56917
56918
56919
56920
56921
56922
56923
56924
56925
56926
56927
56928
56929
56930
56931
56932
56933
56934
56935
56936
56937
56938
56939
56940
56941
56942
56943
56944
56945
56946
56947
56948
56949
56950
56951
56952
56953
56954
56955
56956
56957
56958
56959
56960
56961
56962
56963
56964
56965
56966
56967
56968
56969
56970
56971
56972
56973
56974
56975
56976
56977
56978
56979
56980
56981
56982
56983
56984
56985
56986
56987
56988
56989
56990
56991
56992
56993
56994
56995
56996
56997
56998
56999
57000
57001
57002
57003
57004
57005
57006
57007
57008
57009
57010
57011
57012
57013
57014
57015
57016
57017
57018
57019
57020
57021
57022
57023
57024
57025
57026
57027
57028
57029
57030
57031
57032
57033
57034
57035
57036
57037
57038
57039
57040
57041
57042
57043
57044
57045
57046
57047
57048
57049
57050
57051
57052
57053
57054
57055
57056
57057
57058
57059
57060
57061
57062
57063
57064
57065
57066
57067
57068
57069
57070
57071
57072
57073
57074
57075
57076
57077
57078
57079
57080
57081
57082
57083
57084
57085
57086
57087
57088
57089
57090
57091
57092
57093
57094
57095
57096
57097
57098
57099
57100
57101
57102
57103
57104
57105
57106
57107
57108
57109
57110
57111
57112
57113
57114
57115
57116
57117
57118
57119
57120
57121
57122
57123
57124
57125
57126
57127
57128
57129
57130
57131
57132
57133
57134
57135
57136
57137
57138
57139
57140
57141
57142
57143
57144
57145
57146
57147
57148
57149
57150
57151
57152
57153
57154
57155
57156
57157
57158
57159
57160
57161
57162
57163
57164
57165
57166
57167
57168
57169
57170
57171
57172
57173
57174
57175
57176
57177
57178
57179
57180
57181
57182
57183
57184
57185
57186
57187
57188
57189
57190
57191
57192
57193
57194
57195
57196
57197
57198
57199
57200
57201
57202
57203
57204
57205
57206
57207
57208
57209
57210
57211
57212
57213
57214
57215
57216
57217
57218
57219
57220
57221
57222
57223
57224
57225
57226
57227
57228
57229
57230
57231
57232
57233
57234
57235
57236
57237
57238
57239
57240
57241
57242
57243
57244
57245
57246
57247
57248
57249
57250
57251
57252
57253
57254
57255
57256
57257
57258
57259
57260
57261
57262
57263
57264
57265
57266
57267
57268
57269
57270
57271
57272
57273
57274
57275
57276
57277
57278
57279
57280
57281
57282
57283
57284
57285
57286
57287
57288
57289
57290
57291
57292
57293
57294
57295
57296
57297
57298
57299
57300
57301
57302
57303
57304
57305
57306
57307
57308
57309
57310
57311
57312
57313
57314
57315
57316
57317
57318
57319
57320
57321
57322
57323
57324
57325
57326
57327
57328
57329
57330
57331
57332
57333
57334
57335
57336
57337
57338
57339
57340
57341
57342
57343
57344
57345
57346
57347
57348
57349
57350
57351
57352
57353
57354
57355
57356
57357
57358
57359
57360
57361
57362
57363
57364
57365
57366
57367
57368
57369
57370
57371
57372
57373
57374
57375
57376
57377
57378
57379
57380
57381
57382
57383
57384
57385
57386
57387
57388
57389
57390
57391
57392
57393
57394
57395
57396
57397
57398
57399
57400
57401
57402
57403
57404
57405
57406
57407
57408
57409
57410
57411
57412
57413
57414
57415
57416
57417
57418
57419
57420
57421
57422
57423
57424
57425
57426
57427
57428
57429
57430
57431
57432
57433
57434
57435
57436
57437
57438
57439
57440
57441
57442
57443
57444
57445
57446
57447
57448
57449
57450
57451
57452
57453
57454
57455
57456
57457
57458
57459
57460
57461
57462
57463
57464
57465
57466
57467
57468
57469
57470
57471
57472
57473
57474
57475
57476
57477
57478
57479
57480
57481
57482
57483
57484
57485
57486
57487
57488
57489
57490
57491
57492
57493
57494
57495
57496
57497
57498
57499
57500
57501
57502
57503
57504
57505
57506
57507
57508
57509
57510
57511
57512
57513
57514
57515
57516
57517
57518
57519
57520
57521
57522
57523
57524
57525
57526
57527
57528
57529
57530
57531
57532
57533
57534
57535
57536
57537
57538
57539
57540
57541
57542
57543
57544
57545
57546
57547
57548
57549
57550
57551
57552
57553
57554
57555
57556
57557
57558
57559
57560
57561
57562
57563
57564
57565
57566
57567
57568
57569
57570
57571
57572
57573
57574
57575
57576
57577
57578
57579
57580
57581
57582
57583
57584
57585
57586
57587
57588
57589
57590
57591
57592
57593
57594
57595
57596
57597
57598
57599
57600
57601
57602
57603
57604
57605
57606
57607
57608
57609
57610
57611
57612
57613
57614
57615
57616
57617
57618
57619
57620
57621
57622
57623
57624
57625
57626
57627
57628
57629
57630
57631
57632
57633
57634
57635
57636
57637
57638
57639
57640
57641
57642
57643
57644
57645
57646
57647
57648
57649
57650
57651
57652
57653
57654
57655
57656
57657
57658
57659
57660
57661
57662
57663
57664
57665
57666
57667
57668
57669
57670
57671
57672
57673
57674
57675
57676
57677
57678
57679
57680
57681
57682
57683
57684
57685
57686
57687
57688
57689
57690
57691
57692
57693
57694
57695
57696
57697
57698
57699
57700
57701
57702
57703
57704
57705
57706
57707
57708
57709
57710
57711
57712
57713
57714
57715
57716
57717
57718
57719
57720
57721
57722
57723
57724
57725
57726
57727
57728
57729
57730
57731
57732
57733
57734
57735
57736
57737
57738
57739
57740
57741
57742
57743
57744
57745
57746
57747
57748
57749
57750
57751
57752
57753
57754
57755
57756
57757
57758
57759
57760
57761
57762
57763
57764
57765
57766
57767
57768
57769
57770
57771
57772
57773
57774
57775
57776
57777
57778
57779
57780
57781
57782
57783
57784
57785
57786
57787
57788
57789
57790
57791
57792
57793
57794
57795
57796
57797
57798
57799
57800
57801
57802
57803
57804
57805
57806
57807
57808
57809
57810
57811
57812
57813
57814
57815
57816
57817
57818
57819
57820
57821
57822
57823
57824
57825
57826
57827
57828
57829
57830
57831
57832
57833
57834
57835
57836
57837
57838
57839
57840
57841
57842
57843
57844
57845
57846
57847
57848
57849
57850
57851
57852
57853
57854
57855
57856
57857
57858
57859
57860
57861
57862
57863
57864
57865
57866
57867
57868
57869
57870
57871
57872
57873
57874
57875
57876
57877
57878
57879
57880
57881
57882
57883
57884
57885
57886
57887
57888
57889
57890
57891
57892
57893
57894
57895
57896
57897
57898
57899
57900
57901
57902
57903
57904
57905
57906
57907
57908
57909
57910
57911
57912
57913
57914
57915
57916
57917
57918
57919
57920
57921
57922
57923
57924
57925
57926
57927
57928
57929
57930
57931
57932
57933
57934
57935
57936
57937
57938
57939
57940
57941
57942
57943
57944
57945
57946
57947
57948
57949
57950
57951
57952
57953
57954
57955
57956
57957
57958
57959
57960
57961
57962
57963
57964
57965
57966
57967
57968
57969
57970
57971
57972
57973
57974
57975
57976
57977
57978
57979
57980
57981
57982
57983
57984
57985
57986
57987
57988
57989
57990
57991
57992
57993
57994
57995
57996
57997
57998
57999
58000
58001
58002
58003
58004
58005
58006
58007
58008
58009
58010
58011
58012
58013
58014
58015
58016
58017
58018
58019
58020
58021
58022
58023
58024
58025
58026
58027
58028
58029
58030
58031
58032
58033
58034
58035
58036
58037
58038
58039
58040
58041
58042
58043
58044
58045
58046
58047
58048
58049
58050
58051
58052
58053
58054
58055
58056
58057
58058
58059
58060
58061
58062
58063
58064
58065
58066
58067
58068
58069
58070
58071
58072
58073
58074
58075
58076
58077
58078
58079
58080
58081
58082
58083
58084
58085
58086
58087
58088
58089
58090
58091
58092
58093
58094
58095
58096
58097
58098
58099
58100
58101
58102
58103
58104
58105
58106
58107
58108
58109
58110
58111
58112
58113
58114
58115
58116
58117
58118
58119
58120
58121
58122
58123
58124
58125
58126
58127
58128
58129
58130
58131
58132
58133
58134
58135
58136
58137
58138
58139
58140
58141
58142
58143
58144
58145
58146
58147
58148
58149
58150
58151
58152
58153
58154
58155
58156
58157
58158
58159
58160
58161
58162
58163
58164
58165
58166
58167
58168
58169
58170
58171
58172
58173
58174
58175
58176
58177
58178
58179
58180
58181
58182
58183
58184
58185
58186
58187
58188
58189
58190
58191
58192
58193
58194
58195
58196
58197
58198
58199
58200
58201
58202
58203
58204
58205
58206
58207
58208
58209
58210
58211
58212
58213
58214
58215
58216
58217
58218
58219
58220
58221
58222
58223
58224
58225
58226
58227
58228
58229
58230
58231
58232
58233
58234
58235
58236
58237
58238
58239
58240
58241
58242
58243
58244
58245
58246
58247
58248
58249
58250
58251
58252
58253
58254
58255
58256
58257
58258
58259
58260
58261
58262
58263
58264
58265
58266
58267
58268
58269
58270
58271
58272
58273
58274
58275
58276
58277
58278
58279
58280
58281
58282
58283
58284
58285
58286
58287
58288
58289
58290
58291
58292
58293
58294
58295
58296
58297
58298
58299
58300
58301
58302
58303
58304
58305
58306
58307
58308
58309
58310
58311
58312
58313
58314
58315
58316
58317
58318
58319
58320
58321
58322
58323
58324
58325
58326
58327
58328
58329
58330
58331
58332
58333
58334
58335
58336
58337
58338
58339
58340
58341
58342
58343
58344
58345
58346
58347
58348
58349
58350
58351
58352
58353
58354
58355
58356
58357
58358
58359
58360
58361
58362
58363
58364
58365
58366
58367
58368
58369
58370
58371
58372
58373
58374
58375
58376
58377
58378
58379
58380
58381
58382
58383
58384
58385
58386
58387
58388
58389
58390
58391
58392
58393
58394
58395
58396
58397
58398
58399
58400
58401
58402
58403
58404
58405
58406
58407
58408
58409
58410
58411
58412
58413
58414
58415
58416
58417
58418
58419
58420
58421
58422
58423
58424
58425
58426
58427
58428
58429
58430
58431
58432
58433
58434
58435
58436
58437
58438
58439
58440
58441
58442
58443
58444
58445
58446
58447
58448
58449
58450
58451
58452
58453
58454
58455
58456
58457
58458
58459
58460
58461
58462
58463
58464
58465
58466
58467
58468
58469
58470
58471
58472
58473
58474
58475
58476
58477
58478
58479
58480
58481
58482
58483
58484
58485
58486
58487
58488
58489
58490
58491
58492
58493
58494
58495
58496
58497
58498
58499
58500
58501
58502
58503
58504
58505
58506
58507
58508
58509
58510
58511
58512
58513
58514
58515
58516
58517
58518
58519
58520
58521
58522
58523
58524
58525
58526
58527
58528
58529
58530
58531
58532
58533
58534
58535
58536
58537
58538
58539
58540
58541
58542
58543
58544
58545
58546
58547
58548
58549
58550
58551
58552
58553
58554
58555
58556
58557
58558
58559
58560
58561
58562
58563
58564
58565
58566
58567
58568
58569
58570
58571
58572
58573
58574
58575
58576
58577
58578
58579
58580
58581
58582
58583
58584
58585
58586
58587
58588
58589
58590
58591
58592
58593
58594
58595
58596
58597
58598
58599
58600
58601
58602
58603
58604
58605
58606
58607
58608
58609
58610
58611
58612
58613
58614
58615
58616
58617
58618
58619
58620
58621
58622
58623
58624
58625
58626
58627
58628
58629
58630
58631
58632
58633
58634
58635
58636
58637
58638
58639
58640
58641
58642
58643
58644
58645
58646
58647
58648
58649
58650
58651
58652
58653
58654
58655
58656
58657
58658
58659
58660
58661
58662
58663
58664
58665
58666
58667
58668
58669
58670
58671
58672
58673
58674
58675
58676
58677
58678
58679
58680
58681
58682
58683
58684
58685
58686
58687
58688
58689
58690
58691
58692
58693
58694
58695
58696
58697
58698
58699
58700
58701
58702
58703
58704
58705
58706
58707
58708
58709
58710
58711
58712
58713
58714
58715
58716
58717
58718
58719
58720
58721
58722
58723
58724
58725
58726
58727
58728
58729
58730
58731
58732
58733
58734
58735
58736
58737
58738
58739
58740
58741
58742
58743
58744
58745
58746
58747
58748
58749
58750
58751
58752
58753
58754
58755
58756
58757
58758
58759
58760
58761
58762
58763
58764
58765
58766
58767
58768
58769
58770
58771
58772
58773
58774
58775
58776
58777
58778
58779
58780
58781
58782
58783
58784
58785
58786
58787
58788
58789
58790
58791
58792
58793
58794
58795
58796
58797
58798
58799
58800
58801
58802
58803
58804
58805
58806
58807
58808
58809
58810
58811
58812
58813
58814
58815
58816
58817
58818
58819
58820
58821
58822
58823
58824
58825
58826
58827
58828
58829
58830
58831
58832
58833
58834
58835
58836
58837
58838
58839
58840
58841
58842
58843
58844
58845
58846
58847
58848
58849
58850
58851
58852
58853
58854
58855
58856
58857
58858
58859
58860
58861
58862
58863
58864
58865
58866
58867
58868
58869
58870
58871
58872
58873
58874
58875
58876
58877
58878
58879
58880
58881
58882
58883
58884
58885
58886
58887
58888
58889
58890
58891
58892
58893
58894
58895
58896
58897
58898
58899
58900
58901
58902
58903
58904
58905
58906
58907
58908
58909
58910
58911
58912
58913
58914
58915
58916
58917
58918
58919
58920
58921
58922
58923
58924
58925
58926
58927
58928
58929
58930
58931
58932
58933
58934
58935
58936
58937
58938
58939
58940
58941
58942
58943
58944
58945
58946
58947
58948
58949
58950
58951
58952
58953
58954
58955
58956
58957
58958
58959
58960
58961
58962
58963
58964
58965
58966
58967
58968
58969
58970
58971
58972
58973
58974
58975
58976
58977
58978
58979
58980
58981
58982
58983
58984
58985
58986
58987
58988
58989
58990
58991
58992
58993
58994
58995
58996
58997
58998
58999
59000
59001
59002
59003
59004
59005
59006
59007
59008
59009
59010
59011
59012
59013
59014
59015
59016
59017
59018
59019
59020
59021
59022
59023
59024
59025
59026
59027
59028
59029
59030
59031
59032
59033
59034
59035
59036
59037
59038
59039
59040
59041
59042
59043
59044
59045
59046
59047
59048
59049
59050
59051
59052
59053
59054
59055
59056
59057
59058
59059
59060
59061
59062
59063
59064
59065
59066
59067
59068
59069
59070
59071
59072
59073
59074
59075
59076
59077
59078
59079
59080
59081
59082
59083
59084
59085
59086
59087
59088
59089
59090
59091
59092
59093
59094
59095
59096
59097
59098
59099
59100
59101
59102
59103
59104
59105
59106
59107
59108
59109
59110
59111
59112
59113
59114
59115
59116
59117
59118
59119
59120
59121
59122
59123
59124
59125
59126
59127
59128
59129
59130
59131
59132
59133
59134
59135
59136
59137
59138
59139
59140
59141
59142
59143
59144
59145
59146
59147
59148
59149
59150
59151
59152
59153
59154
59155
59156
59157
59158
59159
59160
59161
59162
59163
59164
59165
59166
59167
59168
59169
59170
59171
59172
59173
59174
59175
59176
59177
59178
59179
59180
59181
59182
59183
59184
59185
59186
59187
59188
59189
59190
59191
59192
59193
59194
59195
59196
59197
59198
59199
59200
59201
59202
59203
59204
59205
59206
59207
59208
59209
59210
59211
59212
59213
59214
59215
59216
59217
59218
59219
59220
59221
59222
59223
59224
59225
59226
59227
59228
59229
59230
59231
59232
59233
59234
59235
59236
59237
59238
59239
59240
59241
59242
59243
59244
59245
59246
59247
59248
59249
59250
59251
59252
59253
59254
59255
59256
59257
59258
59259
59260
59261
59262
59263
59264
59265
59266
59267
59268
59269
59270
59271
59272
59273
59274
59275
59276
59277
59278
59279
59280
59281
59282
59283
59284
59285
59286
59287
59288
59289
59290
59291
59292
59293
59294
59295
59296
59297
59298
59299
59300
59301
59302
59303
59304
59305
59306
59307
59308
59309
59310
59311
59312
59313
59314
59315
59316
59317
59318
59319
59320
59321
59322
59323
59324
59325
59326
59327
59328
59329
59330
59331
59332
59333
59334
59335
59336
59337
59338
59339
59340
59341
59342
59343
59344
59345
59346
59347
59348
59349
59350
59351
59352
59353
59354
59355
59356
59357
59358
59359
59360
59361
59362
59363
59364
59365
59366
59367
59368
59369
59370
59371
59372
59373
59374
59375
59376
59377
59378
59379
59380
59381
59382
59383
59384
59385
59386
59387
59388
59389
59390
59391
59392
59393
59394
59395
59396
59397
59398
59399
59400
59401
59402
59403
59404
59405
59406
59407
59408
59409
59410
59411
59412
59413
59414
59415
59416
59417
59418
59419
59420
59421
59422
59423
59424
59425
59426
59427
59428
59429
59430
59431
59432
59433
59434
59435
59436
59437
59438
59439
59440
59441
59442
59443
59444
59445
59446
59447
59448
59449
59450
59451
59452
59453
59454
59455
59456
59457
59458
59459
59460
59461
59462
59463
59464
59465
59466
59467
59468
59469
59470
59471
59472
59473
59474
59475
59476
59477
59478
59479
59480
59481
59482
59483
59484
59485
59486
59487
59488
59489
59490
59491
59492
59493
59494
59495
59496
59497
59498
59499
59500
59501
59502
59503
59504
59505
59506
59507
59508
59509
59510
59511
59512
59513
59514
59515
59516
59517
59518
59519
59520
59521
59522
59523
59524
59525
59526
59527
59528
59529
59530
59531
59532
59533
59534
59535
59536
59537
59538
59539
59540
59541
59542
59543
59544
59545
59546
59547
59548
59549
59550
59551
59552
59553
59554
59555
59556
59557
59558
59559
59560
59561
59562
59563
59564
59565
59566
59567
59568
59569
59570
59571
59572
59573
59574
59575
59576
59577
59578
59579
59580
59581
59582
59583
59584
59585
59586
59587
59588
59589
59590
59591
59592
59593
59594
59595
59596
59597
59598
59599
59600
59601
59602
59603
59604
59605
59606
59607
59608
59609
59610
59611
59612
59613
59614
59615
59616
59617
59618
59619
59620
59621
59622
59623
59624
59625
59626
59627
59628
59629
59630
59631
59632
59633
59634
59635
59636
59637
59638
59639
59640
59641
59642
59643
59644
59645
59646
59647
59648
59649
59650
59651
59652
59653
59654
59655
59656
59657
59658
59659
59660
59661
59662
59663
59664
59665
59666
59667
59668
59669
59670
59671
59672
59673
59674
59675
59676
59677
59678
59679
59680
59681
59682
59683
59684
59685
59686
59687
59688
59689
59690
59691
59692
59693
59694
59695
59696
59697
59698
59699
59700
59701
59702
59703
59704
59705
59706
59707
59708
59709
59710
59711
59712
59713
59714
59715
59716
59717
59718
59719
59720
59721
59722
59723
59724
59725
59726
59727
59728
59729
59730
59731
59732
59733
59734
59735
59736
59737
59738
59739
59740
59741
59742
59743
59744
59745
59746
59747
59748
59749
59750
59751
59752
59753
59754
59755
59756
59757
59758
59759
59760
59761
59762
59763
59764
59765
59766
59767
59768
59769
59770
59771
59772
59773
59774
59775
59776
59777
59778
59779
59780
59781
59782
59783
59784
59785
59786
59787
59788
59789
59790
59791
59792
59793
59794
59795
59796
59797
59798
59799
59800
59801
59802
59803
59804
59805
59806
59807
59808
59809
59810
59811
59812
59813
59814
59815
59816
59817
59818
59819
59820
59821
59822
59823
59824
59825
59826
59827
59828
59829
59830
59831
59832
59833
59834
59835
59836
59837
59838
59839
59840
59841
59842
59843
59844
59845
59846
59847
59848
59849
59850
59851
59852
59853
59854
59855
59856
59857
59858
59859
59860
59861
59862
59863
59864
59865
59866
59867
59868
59869
59870
59871
59872
59873
59874
59875
59876
59877
59878
59879
59880
59881
59882
59883
59884
59885
59886
59887
59888
59889
59890
59891
59892
59893
59894
59895
59896
59897
59898
59899
59900
59901
59902
59903
59904
59905
59906
59907
59908
59909
59910
59911
59912
59913
59914
59915
59916
59917
59918
59919
59920
59921
59922
59923
59924
59925
59926
59927
59928
59929
59930
59931
59932
59933
59934
59935
59936
59937
59938
59939
59940
59941
59942
59943
59944
59945
59946
59947
59948
59949
59950
59951
59952
59953
59954
59955
59956
59957
59958
59959
59960
59961
59962
59963
59964
59965
59966
59967
59968
59969
59970
59971
59972
59973
59974
59975
59976
59977
59978
59979
59980
59981
59982
59983
59984
59985
59986
59987
59988
59989
59990
59991
59992
59993
59994
59995
59996
59997
59998
59999
60000
60001
60002
60003
60004
60005
60006
60007
60008
60009
60010
60011
60012
60013
60014
60015
60016
60017
60018
60019
60020
60021
60022
60023
60024
60025
60026
60027
60028
60029
60030
60031
60032
60033
60034
60035
60036
60037
60038
60039
60040
60041
60042
60043
60044
60045
60046
60047
60048
60049
60050
60051
60052
60053
60054
60055
60056
60057
60058
60059
60060
60061
60062
60063
60064
60065
60066
60067
60068
60069
60070
60071
60072
60073
60074
60075
60076
60077
60078
60079
60080
60081
60082
60083
60084
60085
60086
60087
60088
60089
60090
60091
60092
60093
60094
60095
60096
60097
60098
60099
60100
60101
60102
60103
60104
60105
60106
60107
60108
60109
60110
60111
60112
60113
60114
60115
60116
60117
60118
60119
60120
60121
60122
60123
60124
60125
60126
60127
60128
60129
60130
60131
60132
60133
60134
60135
60136
60137
60138
60139
60140
60141
60142
60143
60144
60145
60146
60147
60148
60149
60150
60151
60152
60153
60154
60155
60156
60157
60158
60159
60160
60161
60162
60163
60164
60165
60166
60167
60168
60169
60170
60171
60172
60173
60174
60175
60176
60177
60178
60179
60180
60181
60182
60183
60184
60185
60186
60187
60188
60189
60190
60191
60192
60193
60194
60195
60196
60197
60198
60199
60200
60201
60202
60203
60204
60205
60206
60207
60208
60209
60210
60211
60212
60213
60214
60215
60216
60217
60218
60219
60220
60221
60222
60223
60224
60225
60226
60227
60228
60229
60230
60231
60232
60233
60234
60235
60236
60237
60238
60239
60240
60241
60242
60243
60244
60245
60246
60247
60248
60249
60250
60251
60252
60253
60254
60255
60256
60257
60258
60259
60260
60261
60262
60263
60264
60265
60266
60267
60268
60269
60270
60271
60272
60273
60274
60275
60276
60277
60278
60279
60280
60281
60282
60283
60284
60285
60286
60287
60288
60289
60290
60291
60292
60293
60294
60295
60296
60297
60298
60299
60300
60301
60302
60303
60304
60305
60306
60307
60308
60309
60310
60311
60312
60313
60314
60315
60316
60317
60318
60319
60320
60321
60322
60323
60324
60325
60326
60327
60328
60329
60330
60331
60332
60333
60334
60335
60336
60337
60338
60339
60340
60341
60342
60343
60344
60345
60346
60347
60348
60349
60350
60351
60352
60353
60354
60355
60356
60357
60358
60359
60360
60361
60362
60363
60364
60365
60366
60367
60368
60369
60370
60371
60372
60373
60374
60375
60376
60377
60378
60379
60380
60381
60382
60383
60384
60385
60386
60387
60388
60389
60390
60391
60392
60393
60394
60395
60396
60397
60398
60399
60400
60401
60402
60403
60404
60405
60406
60407
60408
60409
60410
60411
60412
60413
60414
60415
60416
60417
60418
60419
60420
60421
60422
60423
60424
60425
60426
60427
60428
60429
60430
60431
60432
60433
60434
60435
60436
60437
60438
60439
60440
60441
60442
60443
60444
60445
60446
60447
60448
60449
60450
60451
60452
60453
60454
60455
60456
60457
60458
60459
60460
60461
60462
60463
60464
60465
60466
60467
60468
60469
60470
60471
60472
60473
60474
60475
60476
60477
60478
60479
60480
60481
60482
60483
60484
60485
60486
60487
60488
60489
60490
60491
60492
60493
60494
60495
60496
60497
60498
60499
60500
60501
60502
60503
60504
60505
60506
60507
60508
60509
60510
60511
60512
60513
60514
60515
60516
60517
60518
60519
60520
60521
60522
60523
60524
60525
60526
60527
60528
60529
60530
60531
60532
60533
60534
60535
60536
60537
60538
60539
60540
60541
60542
60543
60544
60545
60546
60547
60548
60549
60550
60551
60552
60553
60554
60555
60556
60557
60558
60559
60560
60561
60562
60563
60564
60565
60566
60567
60568
60569
60570
60571
60572
60573
60574
60575
60576
60577
60578
60579
60580
60581
60582
60583
60584
60585
60586
60587
60588
60589
60590
60591
60592
60593
60594
60595
60596
60597
60598
60599
60600
60601
60602
60603
60604
60605
60606
60607
60608
60609
60610
60611
60612
60613
60614
60615
60616
60617
60618
60619
60620
60621
60622
60623
60624
60625
60626
60627
60628
60629
60630
60631
60632
60633
60634
60635
60636
60637
60638
60639
60640
60641
60642
60643
60644
60645
60646
60647
60648
60649
60650
60651
60652
60653
60654
60655
60656
60657
60658
60659
60660
60661
60662
60663
60664
60665
60666
60667
60668
60669
60670
60671
60672
60673
60674
60675
60676
60677
60678
60679
60680
60681
60682
60683
60684
60685
60686
60687
60688
60689
60690
60691
60692
60693
60694
60695
60696
60697
60698
60699
60700
60701
60702
60703
60704
60705
60706
60707
60708
60709
60710
60711
60712
60713
60714
60715
60716
60717
60718
60719
60720
60721
60722
60723
60724
60725
60726
60727
60728
60729
60730
60731
60732
60733
60734
60735
60736
60737
60738
60739
60740
60741
60742
60743
60744
60745
60746
60747
60748
60749
60750
60751
60752
60753
60754
60755
60756
60757
60758
60759
60760
60761
60762
60763
60764
60765
60766
60767
60768
60769
60770
60771
60772
60773
60774
60775
60776
60777
60778
60779
60780
60781
60782
60783
60784
60785
60786
60787
60788
60789
60790
60791
60792
60793
60794
60795
60796
60797
60798
60799
60800
60801
60802
60803
60804
60805
60806
60807
60808
60809
60810
60811
60812
60813
60814
60815
60816
60817
60818
60819
60820
60821
60822
60823
60824
60825
60826
60827
60828
60829
60830
60831
60832
60833
60834
60835
60836
60837
60838
60839
60840
60841
60842
60843
60844
60845
60846
60847
60848
60849
60850
60851
60852
60853
60854
60855
60856
60857
60858
60859
60860
60861
60862
60863
60864
60865
60866
60867
60868
60869
60870
60871
60872
60873
60874
60875
60876
60877
60878
60879
60880
60881
60882
60883
60884
60885
60886
60887
60888
60889
60890
60891
60892
60893
60894
60895
60896
60897
60898
60899
60900
60901
60902
60903
60904
60905
60906
60907
60908
60909
60910
60911
60912
60913
60914
60915
60916
60917
60918
60919
60920
60921
60922
60923
60924
60925
60926
60927
60928
60929
60930
60931
60932
60933
60934
60935
60936
60937
60938
60939
60940
60941
60942
60943
60944
60945
60946
60947
60948
60949
60950
60951
60952
60953
60954
60955
60956
60957
60958
60959
60960
60961
60962
60963
60964
60965
60966
60967
60968
60969
60970
60971
60972
60973
60974
60975
60976
60977
60978
60979
60980
60981
60982
60983
60984
60985
60986
60987
60988
60989
60990
60991
60992
60993
60994
60995
60996
60997
60998
60999
61000
61001
61002
61003
61004
61005
61006
61007
61008
61009
61010
61011
61012
61013
61014
61015
61016
61017
61018
61019
61020
61021
61022
61023
61024
61025
61026
61027
61028
61029
61030
61031
61032
61033
61034
61035
61036
61037
61038
61039
61040
61041
61042
61043
61044
61045
61046
61047
61048
61049
61050
61051
61052
61053
61054
61055
61056
61057
61058
61059
61060
61061
61062
61063
61064
61065
61066
61067
61068
61069
61070
61071
61072
61073
61074
61075
61076
61077
61078
61079
61080
61081
61082
61083
61084
61085
61086
61087
61088
61089
61090
61091
61092
61093
61094
61095
61096
61097
61098
61099
61100
61101
61102
61103
61104
61105
61106
61107
61108
61109
61110
61111
61112
61113
61114
61115
61116
61117
61118
61119
61120
61121
61122
61123
61124
61125
61126
61127
61128
61129
61130
61131
61132
61133
61134
61135
61136
61137
61138
61139
61140
61141
61142
61143
61144
61145
61146
61147
61148
61149
61150
61151
61152
61153
61154
61155
61156
61157
61158
61159
61160
61161
61162
61163
61164
61165
61166
61167
61168
61169
61170
61171
61172
61173
61174
61175
61176
61177
61178
61179
61180
61181
61182
61183
61184
61185
61186
61187
61188
61189
61190
61191
61192
61193
61194
61195
61196
61197
61198
61199
61200
61201
61202
61203
61204
61205
61206
61207
61208
61209
61210
61211
61212
61213
61214
61215
61216
61217
61218
61219
61220
61221
61222
61223
61224
61225
61226
61227
61228
61229
61230
61231
61232
61233
61234
61235
61236
61237
61238
61239
61240
61241
61242
61243
61244
61245
61246
61247
61248
61249
61250
61251
61252
61253
61254
61255
61256
61257
61258
61259
61260
61261
61262
61263
61264
61265
61266
61267
61268
61269
61270
61271
61272
61273
61274
61275
61276
61277
61278
61279
61280
61281
61282
61283
61284
61285
61286
61287
61288
61289
61290
61291
61292
61293
61294
61295
61296
61297
61298
61299
61300
61301
61302
61303
61304
61305
61306
61307
61308
61309
61310
61311
61312
61313
61314
61315
61316
61317
61318
61319
61320
61321
61322
61323
61324
61325
61326
61327
61328
61329
61330
61331
61332
61333
61334
61335
61336
61337
61338
61339
61340
61341
61342
61343
61344
61345
61346
61347
61348
61349
61350
61351
61352
61353
61354
61355
61356
61357
61358
61359
61360
61361
61362
61363
61364
61365
61366
61367
61368
61369
61370
61371
61372
61373
61374
61375
61376
61377
61378
61379
61380
61381
61382
61383
61384
61385
61386
61387
61388
61389
61390
61391
61392
61393
61394
61395
61396
61397
61398
61399
61400
61401
61402
61403
61404
61405
61406
61407
61408
61409
61410
61411
61412
61413
61414
61415
61416
61417
61418
61419
61420
61421
61422
61423
61424
61425
61426
61427
61428
61429
61430
61431
61432
61433
61434
61435
61436
61437
61438
61439
61440
61441
61442
61443
61444
61445
61446
61447
61448
61449
61450
61451
61452
61453
61454
61455
61456
61457
61458
61459
61460
61461
61462
61463
61464
61465
61466
61467
61468
61469
61470
61471
61472
61473
61474
61475
61476
61477
61478
61479
61480
61481
61482
61483
61484
61485
61486
61487
61488
61489
61490
61491
61492
61493
61494
61495
61496
61497
61498
61499
61500
61501
61502
61503
61504
61505
61506
61507
61508
61509
61510
61511
61512
61513
61514
61515
61516
61517
61518
61519
61520
61521
61522
61523
61524
61525
61526
61527
61528
61529
61530
61531
61532
61533
61534
61535
61536
61537
61538
61539
61540
61541
61542
61543
61544
61545
61546
61547
61548
61549
61550
61551
61552
61553
61554
61555
61556
61557
61558
61559
61560
61561
61562
61563
61564
61565
61566
61567
61568
61569
61570
61571
61572
61573
61574
61575
61576
61577
61578
61579
61580
61581
61582
61583
61584
61585
61586
61587
61588
61589
61590
61591
61592
61593
61594
61595
61596
61597
61598
61599
61600
61601
61602
61603
61604
61605
61606
61607
61608
61609
61610
61611
61612
61613
61614
61615
61616
61617
61618
61619
61620
61621
61622
61623
61624
61625
61626
61627
61628
61629
61630
61631
61632
61633
61634
61635
61636
61637
61638
61639
61640
61641
61642
61643
61644
61645
61646
61647
61648
61649
61650
61651
61652
61653
61654
61655
61656
61657
61658
61659
61660
61661
61662
61663
61664
61665
61666
61667
61668
61669
61670
61671
61672
61673
61674
61675
61676
61677
61678
61679
61680
61681
61682
61683
61684
61685
61686
61687
61688
61689
61690
61691
61692
61693
61694
61695
61696
61697
61698
61699
61700
61701
61702
61703
61704
61705
61706
61707
61708
61709
61710
61711
61712
61713
61714
61715
61716
61717
61718
61719
61720
61721
61722
61723
61724
61725
61726
61727
61728
61729
61730
61731
61732
61733
61734
61735
61736
61737
61738
61739
61740
61741
61742
61743
61744
61745
61746
61747
61748
61749
61750
61751
61752
61753
61754
61755
61756
61757
61758
61759
61760
61761
61762
61763
61764
61765
61766
61767
61768
61769
61770
61771
61772
61773
61774
61775
61776
61777
61778
61779
61780
61781
61782
61783
61784
61785
61786
61787
61788
61789
61790
61791
61792
61793
61794
61795
61796
61797
61798
61799
61800
61801
61802
61803
61804
61805
61806
61807
61808
61809
61810
61811
61812
61813
61814
61815
61816
61817
61818
61819
61820
61821
61822
61823
61824
61825
61826
61827
61828
61829
61830
61831
61832
61833
61834
61835
61836
61837
61838
61839
61840
61841
61842
61843
61844
61845
61846
61847
61848
61849
61850
61851
61852
61853
61854
61855
61856
61857
61858
61859
61860
61861
61862
61863
61864
61865
61866
61867
61868
61869
61870
61871
61872
61873
61874
61875
61876
61877
61878
61879
61880
61881
61882
61883
61884
61885
61886
61887
61888
61889
61890
61891
61892
61893
61894
61895
61896
61897
61898
61899
61900
61901
61902
61903
61904
61905
61906
61907
61908
61909
61910
61911
61912
61913
61914
61915
61916
61917
61918
61919
61920
61921
61922
61923
61924
61925
61926
61927
61928
61929
61930
61931
61932
61933
61934
61935
61936
61937
61938
61939
61940
61941
61942
61943
61944
61945
61946
61947
61948
61949
61950
61951
61952
61953
61954
61955
61956
61957
61958
61959
61960
61961
61962
61963
61964
61965
61966
61967
61968
61969
61970
61971
61972
61973
61974
61975
61976
61977
61978
61979
61980
61981
61982
61983
61984
61985
61986
61987
61988
61989
61990
61991
61992
61993
61994
61995
61996
61997
61998
61999
62000
62001
62002
62003
62004
62005
62006
62007
62008
62009
62010
62011
62012
62013
62014
62015
62016
62017
62018
62019
62020
62021
62022
62023
62024
62025
62026
62027
62028
62029
62030
62031
62032
62033
62034
62035
62036
62037
62038
62039
62040
62041
62042
62043
62044
62045
62046
62047
62048
62049
62050
62051
62052
62053
62054
62055
62056
62057
62058
62059
62060
62061
62062
62063
62064
62065
62066
62067
62068
62069
62070
62071
62072
62073
62074
62075
62076
62077
62078
62079
62080
62081
62082
62083
62084
62085
62086
62087
62088
62089
62090
62091
62092
62093
62094
62095
62096
62097
62098
62099
62100
62101
62102
62103
62104
62105
62106
62107
62108
62109
62110
62111
62112
62113
62114
62115
62116
62117
62118
62119
62120
62121
62122
62123
62124
62125
62126
62127
62128
62129
62130
62131
62132
62133
62134
62135
62136
62137
62138
62139
62140
62141
62142
62143
62144
62145
62146
62147
62148
62149
62150
62151
62152
62153
62154
62155
62156
62157
62158
62159
62160
62161
62162
62163
62164
62165
62166
62167
62168
62169
62170
62171
62172
62173
62174
62175
62176
62177
62178
62179
62180
62181
62182
62183
62184
62185
62186
62187
62188
62189
62190
62191
62192
62193
62194
62195
62196
62197
62198
62199
62200
62201
62202
62203
62204
62205
62206
62207
62208
62209
62210
62211
62212
62213
62214
62215
62216
62217
62218
62219
62220
62221
62222
62223
62224
62225
62226
62227
62228
62229
62230
62231
62232
62233
62234
62235
62236
62237
62238
62239
62240
62241
62242
62243
62244
62245
62246
62247
62248
62249
62250
62251
62252
62253
62254
62255
62256
62257
62258
62259
62260
62261
62262
62263
62264
62265
62266
62267
62268
62269
62270
62271
62272
62273
62274
62275
62276
62277
62278
62279
62280
62281
62282
62283
62284
62285
62286
62287
62288
62289
62290
62291
62292
62293
62294
62295
62296
62297
62298
62299
62300
62301
62302
62303
62304
62305
62306
62307
62308
62309
62310
62311
62312
62313
62314
62315
62316
62317
62318
62319
62320
62321
62322
62323
62324
62325
62326
62327
62328
62329
62330
62331
62332
62333
62334
62335
62336
62337
62338
62339
62340
62341
62342
62343
62344
62345
62346
62347
62348
62349
62350
62351
62352
62353
62354
62355
62356
62357
62358
62359
62360
62361
62362
62363
62364
62365
62366
62367
62368
62369
62370
62371
62372
62373
62374
62375
62376
62377
62378
62379
62380
62381
62382
62383
62384
62385
62386
62387
62388
62389
62390
62391
62392
62393
62394
62395
62396
62397
62398
62399
62400
62401
62402
62403
62404
62405
62406
62407
62408
62409
62410
62411
62412
62413
62414
62415
62416
62417
62418
62419
62420
62421
62422
62423
62424
62425
62426
62427
62428
62429
62430
62431
62432
62433
62434
62435
62436
62437
62438
62439
62440
62441
62442
62443
62444
62445
62446
62447
62448
62449
62450
62451
62452
62453
62454
62455
62456
62457
62458
62459
62460
62461
62462
62463
62464
62465
62466
62467
62468
62469
62470
62471
62472
62473
62474
62475
62476
62477
62478
62479
62480
62481
62482
62483
62484
62485
62486
62487
62488
62489
62490
62491
62492
62493
62494
62495
62496
62497
62498
62499
62500
62501
62502
62503
62504
62505
62506
62507
62508
62509
62510
62511
62512
62513
62514
62515
62516
62517
62518
62519
62520
62521
62522
62523
62524
62525
62526
62527
62528
62529
62530
62531
62532
62533
62534
62535
62536
62537
62538
62539
62540
62541
62542
62543
62544
62545
62546
62547
62548
62549
62550
62551
62552
62553
62554
62555
62556
62557
62558
62559
62560
62561
62562
62563
62564
62565
62566
62567
62568
62569
62570
62571
62572
62573
62574
62575
62576
62577
62578
62579
62580
62581
62582
62583
62584
62585
62586
62587
62588
62589
62590
62591
62592
62593
62594
62595
62596
62597
62598
62599
62600
62601
62602
62603
62604
62605
62606
62607
62608
62609
62610
62611
62612
62613
62614
62615
62616
62617
62618
62619
62620
62621
62622
62623
62624
62625
62626
62627
62628
62629
62630
62631
62632
62633
62634
62635
62636
62637
62638
62639
62640
62641
62642
62643
62644
62645
62646
62647
62648
62649
62650
62651
62652
62653
62654
62655
62656
62657
62658
62659
62660
62661
62662
62663
62664
62665
62666
62667
62668
62669
62670
62671
62672
62673
62674
62675
62676
62677
62678
62679
62680
62681
62682
62683
62684
62685
62686
62687
62688
62689
62690
62691
62692
62693
62694
62695
62696
62697
62698
62699
62700
62701
62702
62703
62704
62705
62706
62707
62708
62709
62710
62711
62712
62713
62714
62715
62716
62717
62718
62719
62720
62721
62722
62723
62724
62725
62726
62727
62728
62729
62730
62731
62732
62733
62734
62735
62736
62737
62738
62739
62740
62741
62742
62743
62744
62745
62746
62747
62748
62749
62750
62751
62752
62753
62754
62755
62756
62757
62758
62759
62760
62761
62762
62763
62764
62765
62766
62767
62768
62769
62770
62771
62772
62773
62774
62775
62776
62777
62778
62779
62780
62781
62782
62783
62784
62785
62786
62787
62788
62789
62790
62791
62792
62793
62794
62795
62796
62797
62798
62799
62800
62801
62802
62803
62804
62805
62806
62807
62808
62809
62810
62811
62812
62813
62814
62815
62816
62817
62818
62819
62820
62821
62822
62823
62824
62825
62826
62827
62828
62829
62830
62831
62832
62833
62834
62835
62836
62837
62838
62839
62840
62841
62842
62843
62844
62845
62846
62847
62848
62849
62850
62851
62852
62853
62854
62855
62856
62857
62858
62859
62860
62861
62862
62863
62864
62865
62866
62867
62868
62869
62870
62871
62872
62873
62874
62875
62876
62877
62878
62879
62880
62881
62882
62883
62884
62885
62886
62887
62888
62889
62890
62891
62892
62893
62894
62895
62896
62897
62898
62899
62900
62901
62902
62903
62904
62905
62906
62907
62908
62909
62910
62911
62912
62913
62914
62915
62916
62917
62918
62919
62920
62921
62922
62923
62924
62925
62926
62927
62928
62929
62930
62931
62932
62933
62934
62935
62936
62937
62938
62939
62940
62941
62942
62943
62944
62945
62946
62947
62948
62949
62950
62951
62952
62953
62954
62955
62956
62957
62958
62959
62960
62961
62962
62963
62964
62965
62966
62967
62968
62969
62970
62971
62972
62973
62974
62975
62976
62977
62978
62979
62980
62981
62982
62983
62984
62985
62986
62987
62988
62989
62990
62991
62992
62993
62994
62995
62996
62997
62998
62999
63000
63001
63002
63003
63004
63005
63006
63007
63008
63009
63010
63011
63012
63013
63014
63015
63016
63017
63018
63019
63020
63021
63022
63023
63024
63025
63026
63027
63028
63029
63030
63031
63032
63033
63034
63035
63036
63037
63038
63039
63040
63041
63042
63043
63044
63045
63046
63047
63048
63049
63050
63051
63052
63053
63054
63055
63056
63057
63058
63059
63060
63061
63062
63063
63064
63065
63066
63067
63068
63069
63070
63071
63072
63073
63074
63075
63076
63077
63078
63079
63080
63081
63082
63083
63084
63085
63086
63087
63088
63089
63090
63091
63092
63093
63094
63095
63096
63097
63098
63099
63100
63101
63102
63103
63104
63105
63106
63107
63108
63109
63110
63111
63112
63113
63114
63115
63116
63117
63118
63119
63120
63121
63122
63123
63124
63125
63126
63127
63128
63129
63130
63131
63132
63133
63134
63135
63136
63137
63138
63139
63140
63141
63142
63143
63144
63145
63146
63147
63148
63149
63150
63151
63152
63153
63154
63155
63156
63157
63158
63159
63160
63161
63162
63163
63164
63165
63166
63167
63168
63169
63170
63171
63172
63173
63174
63175
63176
63177
63178
63179
63180
63181
63182
63183
63184
63185
63186
63187
63188
63189
63190
63191
63192
63193
63194
63195
63196
63197
63198
63199
63200
63201
63202
63203
63204
63205
63206
63207
63208
63209
63210
63211
63212
63213
63214
63215
63216
63217
63218
63219
63220
63221
63222
63223
63224
63225
63226
63227
63228
63229
63230
63231
63232
63233
63234
63235
63236
63237
63238
63239
63240
63241
63242
63243
63244
63245
63246
63247
63248
63249
63250
63251
63252
63253
63254
63255
63256
63257
63258
63259
63260
63261
63262
63263
63264
63265
63266
63267
63268
63269
63270
63271
63272
63273
63274
63275
63276
63277
63278
63279
63280
63281
63282
63283
63284
63285
63286
63287
63288
63289
63290
63291
63292
63293
63294
63295
63296
63297
63298
63299
63300
63301
63302
63303
63304
63305
63306
63307
63308
63309
63310
63311
63312
63313
63314
63315
63316
63317
63318
63319
63320
63321
63322
63323
63324
63325
63326
63327
63328
63329
63330
63331
63332
63333
63334
63335
63336
63337
63338
63339
63340
63341
63342
63343
63344
63345
63346
63347
63348
63349
63350
63351
63352
63353
63354
63355
63356
63357
63358
63359
63360
63361
63362
63363
63364
63365
63366
63367
63368
63369
63370
63371
63372
63373
63374
63375
63376
63377
63378
63379
63380
63381
63382
63383
63384
63385
63386
63387
63388
63389
63390
63391
63392
63393
63394
63395
63396
63397
63398
63399
63400
63401
63402
63403
63404
63405
63406
63407
63408
63409
63410
63411
63412
63413
63414
63415
63416
63417
63418
63419
63420
63421
63422
63423
63424
63425
63426
63427
63428
63429
63430
63431
63432
63433
63434
63435
63436
63437
63438
63439
63440
63441
63442
63443
63444
63445
63446
63447
63448
63449
63450
63451
63452
63453
63454
63455
63456
63457
63458
63459
63460
63461
63462
63463
63464
63465
63466
63467
63468
63469
63470
63471
63472
63473
63474
63475
63476
63477
63478
63479
63480
63481
63482
63483
63484
63485
63486
63487
63488
63489
63490
63491
63492
63493
63494
63495
63496
63497
63498
63499
63500
63501
63502
63503
63504
63505
63506
63507
63508
63509
63510
63511
63512
63513
63514
63515
63516
63517
63518
63519
63520
63521
63522
63523
63524
63525
63526
63527
63528
63529
63530
63531
63532
63533
63534
63535
63536
63537
63538
63539
63540
63541
63542
63543
63544
63545
63546
63547
63548
63549
63550
63551
63552
63553
63554
63555
63556
63557
63558
63559
63560
63561
63562
63563
63564
63565
63566
63567
63568
63569
63570
63571
63572
63573
63574
63575
63576
63577
63578
63579
63580
63581
63582
63583
63584
63585
63586
63587
63588
63589
63590
63591
63592
63593
63594
63595
63596
63597
63598
63599
63600
63601
63602
63603
63604
63605
63606
63607
63608
63609
63610
63611
63612
63613
63614
63615
63616
63617
63618
63619
63620
63621
63622
63623
63624
63625
63626
63627
63628
63629
63630
63631
63632
63633
63634
63635
63636
63637
63638
63639
63640
63641
63642
63643
63644
63645
63646
63647
63648
63649
63650
63651
63652
63653
63654
63655
63656
63657
63658
63659
63660
63661
63662
63663
63664
63665
63666
63667
63668
63669
63670
63671
63672
63673
63674
63675
63676
63677
63678
63679
63680
63681
63682
63683
63684
63685
63686
63687
63688
63689
63690
63691
63692
63693
63694
63695
63696
63697
63698
63699
63700
63701
63702
63703
63704
63705
63706
63707
63708
63709
63710
63711
63712
63713
63714
63715
63716
63717
63718
63719
63720
63721
63722
63723
63724
63725
63726
63727
63728
63729
63730
63731
63732
63733
63734
63735
63736
63737
63738
63739
63740
63741
63742
63743
63744
63745
63746
63747
63748
63749
63750
63751
63752
63753
63754
63755
63756
63757
63758
63759
63760
63761
63762
63763
63764
63765
63766
63767
63768
63769
63770
63771
63772
63773
63774
63775
63776
63777
63778
63779
63780
63781
63782
63783
63784
63785
63786
63787
63788
63789
63790
63791
63792
63793
63794
63795
63796
63797
63798
63799
63800
63801
63802
63803
63804
63805
63806
63807
63808
63809
63810
63811
63812
63813
63814
63815
63816
63817
63818
63819
63820
63821
63822
63823
63824
63825
63826
63827
63828
63829
63830
63831
63832
63833
63834
63835
63836
63837
63838
63839
63840
63841
63842
63843
63844
63845
63846
63847
63848
63849
63850
63851
63852
63853
63854
63855
63856
63857
63858
63859
63860
63861
63862
63863
63864
63865
63866
63867
63868
63869
63870
63871
63872
63873
63874
63875
63876
63877
63878
63879
63880
63881
63882
63883
63884
63885
63886
63887
63888
63889
63890
63891
63892
63893
63894
63895
63896
63897
63898
63899
63900
63901
63902
63903
63904
63905
63906
63907
63908
63909
63910
63911
63912
63913
63914
63915
63916
63917
63918
63919
63920
63921
63922
63923
63924
63925
63926
63927
63928
63929
63930
63931
63932
63933
63934
63935
63936
63937
63938
63939
63940
63941
63942
63943
63944
63945
63946
63947
63948
63949
63950
63951
63952
63953
63954
63955
63956
63957
63958
63959
63960
63961
63962
63963
63964
63965
63966
63967
63968
63969
63970
63971
63972
63973
63974
63975
63976
63977
63978
63979
63980
63981
63982
63983
63984
63985
63986
63987
63988
63989
63990
63991
63992
63993
63994
63995
63996
63997
63998
63999
64000
64001
64002
64003
64004
64005
64006
64007
64008
64009
64010
64011
64012
64013
64014
64015
64016
64017
64018
64019
64020
64021
64022
64023
64024
64025
64026
64027
64028
64029
64030
64031
64032
64033
64034
64035
64036
64037
64038
64039
64040
64041
64042
64043
64044
64045
64046
64047
64048
64049
64050
64051
64052
64053
64054
64055
64056
64057
64058
64059
64060
64061
64062
64063
64064
64065
64066
64067
64068
64069
64070
64071
64072
64073
64074
64075
64076
64077
64078
64079
64080
64081
64082
64083
64084
64085
64086
64087
64088
64089
64090
64091
64092
64093
64094
64095
64096
64097
64098
64099
64100
64101
64102
64103
64104
64105
64106
64107
64108
64109
64110
64111
64112
64113
64114
64115
64116
64117
64118
64119
64120
64121
64122
64123
64124
64125
64126
64127
64128
64129
64130
64131
64132
64133
64134
64135
64136
64137
64138
64139
64140
64141
64142
64143
64144
64145
64146
64147
64148
64149
64150
64151
64152
64153
64154
64155
64156
64157
64158
64159
64160
64161
64162
64163
64164
64165
64166
64167
64168
64169
64170
64171
64172
64173
64174
64175
64176
64177
64178
64179
64180
64181
64182
64183
64184
64185
64186
64187
64188
64189
64190
64191
64192
64193
64194
64195
64196
64197
64198
64199
64200
64201
64202
64203
64204
64205
64206
64207
64208
64209
64210
64211
64212
64213
64214
64215
64216
64217
64218
64219
64220
64221
64222
64223
64224
64225
64226
64227
64228
64229
64230
64231
64232
64233
64234
64235
64236
64237
64238
64239
64240
64241
64242
64243
64244
64245
64246
64247
64248
64249
64250
64251
64252
64253
64254
64255
64256
64257
64258
64259
64260
64261
64262
64263
64264
64265
64266
64267
64268
64269
64270
64271
64272
64273
64274
64275
64276
64277
64278
64279
64280
64281
64282
64283
64284
64285
64286
64287
64288
64289
64290
64291
64292
64293
64294
64295
64296
64297
64298
64299
64300
64301
64302
64303
64304
64305
64306
64307
64308
64309
64310
64311
64312
64313
64314
64315
64316
64317
64318
64319
64320
64321
64322
64323
64324
64325
64326
64327
64328
64329
64330
64331
64332
64333
64334
64335
64336
64337
64338
64339
64340
64341
64342
64343
64344
64345
64346
64347
64348
64349
64350
64351
64352
64353
64354
64355
64356
64357
64358
64359
64360
64361
64362
64363
64364
64365
64366
64367
64368
64369
64370
64371
64372
64373
64374
64375
64376
64377
64378
64379
64380
64381
64382
64383
64384
64385
64386
64387
64388
64389
64390
64391
64392
64393
64394
64395
64396
64397
64398
64399
64400
64401
64402
64403
64404
64405
64406
64407
64408
64409
64410
64411
64412
64413
64414
64415
64416
64417
64418
64419
64420
64421
64422
64423
64424
64425
64426
64427
64428
64429
64430
64431
64432
64433
64434
64435
64436
64437
64438
64439
64440
64441
64442
64443
64444
64445
64446
64447
64448
64449
64450
64451
64452
64453
64454
64455
64456
64457
64458
64459
64460
64461
64462
64463
64464
64465
64466
64467
64468
64469
64470
64471
64472
64473
64474
64475
64476
64477
64478
64479
64480
64481
64482
64483
64484
64485
64486
64487
64488
64489
64490
64491
64492
64493
64494
64495
64496
64497
64498
64499
64500
64501
64502
64503
64504
64505
64506
64507
64508
64509
64510
64511
64512
64513
64514
64515
64516
64517
64518
64519
64520
64521
64522
64523
64524
64525
64526
64527
64528
64529
64530
64531
64532
64533
64534
64535
64536
64537
64538
64539
64540
64541
64542
64543
64544
64545
64546
64547
64548
64549
64550
64551
64552
64553
64554
64555
64556
64557
64558
64559
64560
64561
64562
64563
64564
64565
64566
64567
64568
64569
64570
64571
64572
64573
64574
64575
64576
64577
64578
64579
64580
64581
64582
64583
64584
64585
64586
64587
64588
64589
64590
64591
64592
64593
64594
64595
64596
64597
64598
64599
64600
64601
64602
64603
64604
64605
64606
64607
64608
64609
64610
64611
64612
64613
64614
64615
64616
64617
64618
64619
64620
64621
64622
64623
64624
64625
64626
64627
64628
64629
64630
64631
64632
64633
64634
64635
64636
64637
64638
64639
64640
64641
64642
64643
64644
64645
64646
64647
64648
64649
64650
64651
64652
64653
64654
64655
64656
64657
64658
64659
64660
64661
64662
64663
64664
64665
64666
64667
64668
64669
64670
64671
64672
64673
64674
64675
64676
64677
64678
64679
64680
64681
64682
64683
64684
64685
64686
64687
64688
64689
64690
64691
64692
64693
64694
64695
64696
64697
64698
64699
64700
64701
64702
64703
64704
64705
64706
64707
64708
64709
64710
64711
64712
64713
64714
64715
64716
64717
64718
64719
64720
64721
64722
64723
64724
64725
64726
64727
64728
64729
64730
64731
64732
64733
64734
64735
64736
64737
64738
64739
64740
64741
64742
64743
64744
64745
64746
64747
64748
64749
64750
64751
64752
64753
64754
64755
64756
64757
64758
64759
64760
64761
64762
64763
64764
64765
64766
64767
64768
64769
64770
64771
64772
64773
64774
64775
64776
64777
64778
64779
64780
64781
64782
64783
64784
64785
64786
64787
64788
64789
64790
64791
64792
64793
64794
64795
64796
64797
64798
64799
64800
64801
64802
64803
64804
64805
64806
64807
64808
64809
64810
64811
64812
64813
64814
64815
64816
64817
64818
64819
64820
64821
64822
64823
64824
64825
64826
64827
64828
64829
64830
64831
64832
64833
64834
64835
64836
64837
64838
64839
64840
64841
64842
64843
64844
64845
64846
64847
64848
64849
64850
64851
64852
64853
64854
64855
64856
64857
64858
64859
64860
64861
64862
64863
64864
64865
64866
64867
64868
64869
64870
64871
64872
64873
64874
64875
64876
64877
64878
64879
64880
64881
64882
64883
64884
64885
64886
64887
64888
64889
64890
64891
64892
64893
64894
64895
64896
64897
64898
64899
64900
64901
64902
64903
64904
64905
64906
64907
64908
64909
64910
64911
64912
64913
64914
64915
64916
64917
64918
64919
64920
64921
64922
64923
64924
64925
64926
64927
64928
64929
64930
64931
64932
64933
64934
64935
64936
64937
64938
64939
64940
64941
64942
64943
64944
64945
64946
64947
64948
64949
64950
64951
64952
64953
64954
64955
64956
64957
64958
64959
64960
64961
64962
64963
64964
64965
64966
64967
64968
64969
64970
64971
64972
64973
64974
64975
64976
64977
64978
64979
64980
64981
64982
64983
64984
64985
64986
64987
64988
64989
64990
64991
64992
64993
64994
64995
64996
64997
64998
64999
65000
65001
65002
65003
65004
65005
65006
65007
65008
65009
65010
65011
65012
65013
65014
65015
65016
65017
65018
65019
65020
65021
65022
65023
65024
65025
65026
65027
65028
65029
65030
65031
65032
65033
65034
65035
65036
65037
65038
65039
65040
65041
65042
65043
65044
65045
65046
65047
65048
65049
65050
65051
65052
65053
65054
65055
65056
65057
65058
65059
65060
65061
65062
65063
65064
65065
65066
65067
65068
65069
65070
65071
65072
65073
65074
65075
65076
65077
65078
65079
65080
65081
65082
65083
65084
65085
65086
65087
65088
65089
65090
65091
65092
65093
65094
65095
65096
65097
65098
65099
65100
65101
65102
65103
65104
65105
65106
65107
65108
65109
65110
65111
65112
65113
65114
65115
65116
65117
65118
65119
65120
65121
65122
65123
65124
65125
65126
65127
65128
65129
65130
65131
65132
65133
65134
65135
65136
65137
65138
65139
65140
65141
65142
65143
65144
65145
65146
65147
65148
65149
65150
65151
65152
65153
65154
65155
65156
65157
65158
65159
65160
65161
65162
65163
65164
65165
65166
65167
65168
65169
65170
65171
65172
65173
65174
65175
65176
65177
65178
65179
65180
65181
65182
65183
65184
65185
65186
65187
65188
65189
65190
65191
65192
65193
65194
65195
65196
65197
65198
65199
65200
65201
65202
65203
65204
65205
65206
65207
65208
65209
65210
65211
65212
65213
65214
65215
65216
65217
65218
65219
65220
65221
65222
65223
65224
65225
65226
65227
65228
65229
65230
65231
65232
65233
65234
65235
65236
65237
65238
65239
65240
65241
65242
65243
65244
65245
65246
65247
65248
65249
65250
65251
65252
65253
65254
65255
65256
65257
65258
65259
65260
65261
65262
65263
65264
65265
65266
65267
65268
65269
65270
65271
65272
65273
65274
65275
65276
65277
65278
65279
65280
65281
65282
65283
65284
65285
65286
65287
65288
65289
65290
65291
65292
65293
65294
65295
65296
65297
65298
65299
65300
65301
65302
65303
65304
65305
65306
65307
65308
65309
65310
65311
65312
65313
65314
65315
65316
65317
65318
65319
65320
65321
65322
65323
65324
65325
65326
65327
65328
65329
65330
65331
65332
65333
65334
65335
65336
65337
65338
65339
65340
65341
65342
65343
65344
65345
65346
65347
65348
65349
65350
65351
65352
65353
65354
65355
65356
65357
65358
65359
65360
65361
65362
65363
65364
65365
65366
65367
65368
65369
65370
65371
65372
65373
65374
65375
65376
65377
65378
65379
65380
65381
65382
65383
65384
65385
65386
65387
65388
65389
65390
65391
65392
65393
65394
65395
65396
65397
65398
65399
65400
65401
65402
65403
65404
65405
65406
65407
65408
65409
65410
65411
65412
65413
65414
65415
65416
65417
65418
65419
65420
65421
65422
65423
65424
65425
65426
65427
65428
65429
65430
65431
65432
65433
65434
65435
65436
65437
65438
65439
65440
65441
65442
65443
65444
65445
65446
65447
65448
65449
65450
65451
65452
65453
65454
65455
65456
65457
65458
65459
65460
65461
65462
65463
65464
65465
65466
65467
65468
65469
65470
65471
65472
65473
65474
65475
65476
65477
65478
65479
65480
65481
65482
65483
65484
65485
65486
65487
65488
65489
65490
65491
65492
65493
65494
65495
65496
65497
65498
65499
65500
65501
65502
65503
65504
65505
65506
65507
65508
65509
65510
65511
65512
65513
65514
65515
65516
65517
65518
65519
65520
65521
65522
65523
65524
65525
65526
65527
65528
65529
65530
65531
65532
65533
65534
65535
65536
65537
65538
65539
65540
65541
65542
65543
65544
65545
65546
65547
65548
65549
65550
65551
65552
65553
65554
65555
65556
65557
65558
65559
65560
65561
65562
65563
65564
65565
65566
65567
65568
65569
65570
65571
65572
65573
65574
65575
65576
65577
65578
65579
65580
65581
65582
65583
65584
65585
65586
65587
65588
65589
65590
65591
65592
65593
65594
65595
65596
65597
65598
65599
65600
65601
65602
65603
65604
65605
65606
65607
65608
65609
65610
65611
65612
65613
65614
65615
65616
65617
65618
65619
65620
65621
65622
65623
65624
65625
65626
65627
65628
65629
65630
65631
65632
65633
65634
65635
65636
65637
65638
65639
65640
65641
65642
65643
65644
65645
65646
65647
65648
65649
65650
65651
65652
65653
65654
65655
65656
65657
65658
65659
65660
65661
65662
65663
65664
65665
65666
65667
65668
65669
65670
65671
65672
65673
65674
65675
65676
65677
65678
65679
65680
65681
65682
65683
65684
65685
65686
65687
65688
65689
65690
65691
65692
65693
65694
65695
65696
65697
65698
65699
65700
65701
65702
65703
65704
65705
65706
65707
65708
65709
65710
65711
65712
65713
65714
65715
65716
65717
65718
65719
65720
65721
65722
65723
65724
65725
65726
65727
65728
65729
65730
65731
65732
65733
65734
65735
65736
65737
65738
65739
65740
65741
65742
65743
65744
65745
65746
65747
65748
65749
65750
65751
65752
65753
65754
65755
65756
65757
65758
65759
65760
65761
65762
65763
65764
65765
65766
65767
65768
65769
65770
65771
65772
65773
65774
65775
65776
65777
65778
65779
65780
65781
65782
65783
65784
65785
65786
65787
65788
65789
65790
65791
65792
65793
65794
65795
65796
65797
65798
65799
65800
65801
65802
65803
65804
65805
65806
65807
65808
65809
65810
65811
65812
65813
65814
65815
65816
65817
65818
65819
65820
65821
65822
65823
65824
65825
65826
65827
65828
65829
65830
65831
65832
65833
65834
65835
65836
65837
65838
65839
65840
65841
65842
65843
65844
65845
65846
65847
65848
65849
65850
65851
65852
65853
65854
65855
65856
65857
65858
65859
65860
65861
65862
65863
65864
65865
65866
65867
65868
65869
65870
65871
65872
65873
65874
65875
65876
65877
65878
65879
65880
65881
65882
65883
65884
65885
65886
65887
65888
65889
65890
65891
65892
65893
65894
65895
65896
65897
65898
65899
65900
65901
65902
65903
65904
65905
65906
65907
65908
65909
65910
65911
65912
65913
65914
65915
65916
65917
65918
65919
65920
65921
65922
65923
65924
65925
65926
65927
65928
65929
65930
65931
65932
65933
65934
65935
65936
65937
65938
65939
65940
65941
65942
65943
65944
65945
65946
65947
65948
65949
65950
65951
65952
65953
65954
65955
65956
65957
65958
65959
65960
65961
65962
65963
65964
65965
65966
65967
65968
65969
65970
65971
65972
65973
65974
65975
65976
65977
65978
65979
65980
65981
65982
65983
65984
65985
65986
65987
65988
65989
65990
65991
65992
65993
65994
65995
65996
65997
65998
65999
66000
66001
66002
66003
66004
66005
66006
66007
66008
66009
66010
66011
66012
66013
66014
66015
66016
66017
66018
66019
66020
66021
66022
66023
66024
66025
66026
66027
66028
66029
66030
66031
66032
66033
66034
66035
66036
66037
66038
66039
66040
66041
66042
66043
66044
66045
66046
66047
66048
66049
66050
66051
66052
66053
66054
66055
66056
66057
66058
66059
66060
66061
66062
66063
66064
66065
66066
66067
66068
66069
66070
66071
66072
66073
66074
66075
66076
66077
66078
66079
66080
66081
66082
66083
66084
66085
66086
66087
66088
66089
66090
66091
66092
66093
66094
66095
66096
66097
66098
66099
66100
66101
66102
66103
66104
66105
66106
66107
66108
66109
66110
66111
66112
66113
66114
66115
66116
66117
66118
66119
66120
66121
66122
66123
66124
66125
66126
66127
66128
66129
66130
66131
66132
66133
66134
66135
66136
66137
66138
66139
66140
66141
66142
66143
66144
66145
66146
66147
66148
66149
66150
66151
66152
66153
66154
66155
66156
66157
66158
66159
66160
66161
66162
66163
66164
66165
66166
66167
66168
66169
66170
66171
66172
66173
66174
66175
66176
66177
66178
66179
66180
66181
66182
66183
66184
66185
66186
66187
66188
66189
66190
66191
66192
66193
66194
66195
66196
66197
66198
66199
66200
66201
66202
66203
66204
66205
66206
66207
66208
66209
66210
66211
66212
66213
66214
66215
66216
66217
66218
66219
66220
66221
66222
66223
66224
66225
66226
66227
66228
66229
66230
66231
66232
66233
66234
66235
66236
66237
66238
66239
66240
66241
66242
66243
66244
66245
66246
66247
66248
66249
66250
66251
66252
66253
66254
66255
66256
66257
66258
66259
66260
66261
66262
66263
66264
66265
66266
66267
66268
66269
66270
66271
66272
66273
66274
66275
66276
66277
66278
66279
66280
66281
66282
66283
66284
66285
66286
66287
66288
66289
66290
66291
66292
66293
66294
66295
66296
66297
66298
66299
66300
66301
66302
66303
66304
66305
66306
66307
66308
66309
66310
66311
66312
66313
66314
66315
66316
66317
66318
66319
66320
66321
66322
66323
66324
66325
66326
66327
66328
66329
66330
66331
66332
66333
66334
66335
66336
66337
66338
66339
66340
66341
66342
66343
66344
66345
66346
66347
66348
66349
66350
66351
66352
66353
66354
66355
66356
66357
66358
66359
66360
66361
66362
66363
66364
66365
66366
66367
66368
66369
66370
66371
66372
66373
66374
66375
66376
66377
66378
66379
66380
66381
66382
66383
66384
66385
66386
66387
66388
66389
66390
66391
66392
66393
66394
66395
66396
66397
66398
66399
66400
66401
66402
66403
66404
66405
66406
66407
66408
66409
66410
66411
66412
66413
66414
66415
66416
66417
66418
66419
66420
66421
66422
66423
66424
66425
66426
66427
66428
66429
66430
66431
66432
66433
66434
66435
66436
66437
66438
66439
66440
66441
66442
66443
66444
66445
66446
66447
66448
66449
66450
66451
66452
66453
66454
66455
66456
66457
66458
66459
66460
66461
66462
66463
66464
66465
66466
66467
66468
66469
66470
66471
66472
66473
66474
66475
66476
66477
66478
66479
66480
66481
66482
66483
66484
66485
66486
66487
66488
66489
66490
66491
66492
66493
66494
66495
66496
66497
66498
66499
66500
66501
66502
66503
66504
66505
66506
66507
66508
66509
66510
66511
66512
66513
66514
66515
66516
66517
66518
66519
66520
66521
66522
66523
66524
66525
66526
66527
66528
66529
66530
66531
66532
66533
66534
66535
66536
66537
66538
66539
66540
66541
66542
66543
66544
66545
66546
66547
66548
66549
66550
66551
66552
66553
66554
66555
66556
66557
66558
66559
66560
66561
66562
66563
66564
66565
66566
66567
66568
66569
66570
66571
66572
66573
66574
66575
66576
66577
66578
66579
66580
66581
66582
66583
66584
66585
66586
66587
66588
66589
66590
66591
66592
66593
66594
66595
66596
66597
66598
66599
66600
66601
66602
66603
66604
66605
66606
66607
66608
66609
66610
66611
66612
66613
66614
66615
66616
66617
66618
66619
66620
66621
66622
66623
66624
66625
66626
66627
66628
66629
66630
66631
66632
66633
66634
66635
66636
66637
66638
66639
66640
66641
66642
66643
66644
66645
66646
66647
66648
66649
66650
66651
66652
66653
66654
66655
66656
66657
66658
66659
66660
66661
66662
66663
66664
66665
66666
66667
66668
66669
66670
66671
66672
66673
66674
66675
66676
66677
66678
66679
66680
66681
66682
66683
66684
66685
66686
66687
66688
66689
66690
66691
66692
66693
66694
66695
66696
66697
66698
66699
66700
66701
66702
66703
66704
66705
66706
66707
66708
66709
66710
66711
66712
66713
66714
66715
66716
66717
66718
66719
66720
66721
66722
66723
66724
66725
66726
66727
66728
66729
66730
66731
66732
66733
66734
66735
66736
66737
66738
66739
66740
66741
66742
66743
66744
66745
66746
66747
66748
66749
66750
66751
66752
66753
66754
66755
66756
66757
66758
66759
66760
66761
66762
66763
66764
66765
66766
66767
66768
66769
66770
66771
66772
66773
66774
66775
66776
66777
66778
66779
66780
66781
66782
66783
66784
66785
66786
66787
66788
66789
66790
66791
66792
66793
66794
66795
66796
66797
66798
66799
66800
66801
66802
66803
66804
66805
66806
66807
66808
66809
66810
66811
66812
66813
66814
66815
66816
66817
66818
66819
66820
66821
66822
66823
66824
66825
66826
66827
66828
66829
66830
66831
66832
66833
66834
66835
66836
66837
66838
66839
66840
66841
66842
66843
66844
66845
66846
66847
66848
66849
66850
66851
66852
66853
66854
66855
66856
66857
66858
66859
66860
66861
66862
66863
66864
66865
66866
66867
66868
66869
66870
66871
66872
66873
66874
66875
66876
66877
66878
66879
66880
66881
66882
66883
66884
66885
66886
66887
66888
66889
66890
66891
66892
66893
66894
66895
66896
66897
66898
66899
66900
66901
66902
66903
66904
66905
66906
66907
66908
66909
66910
66911
66912
66913
66914
66915
66916
66917
66918
66919
66920
66921
66922
66923
66924
66925
66926
66927
66928
66929
66930
66931
66932
66933
66934
66935
66936
66937
66938
66939
66940
66941
66942
66943
66944
66945
66946
66947
66948
66949
66950
66951
66952
66953
66954
66955
66956
66957
66958
66959
66960
66961
66962
66963
66964
66965
66966
66967
66968
66969
66970
66971
66972
66973
66974
66975
66976
66977
66978
66979
66980
66981
66982
66983
66984
66985
66986
66987
66988
66989
66990
66991
66992
66993
66994
66995
66996
66997
66998
66999
67000
67001
67002
67003
67004
67005
67006
67007
67008
67009
67010
67011
67012
67013
67014
67015
67016
67017
67018
67019
67020
67021
67022
67023
67024
67025
67026
67027
67028
67029
67030
67031
67032
67033
67034
67035
67036
67037
67038
67039
67040
67041
67042
67043
67044
67045
67046
67047
67048
67049
67050
67051
67052
67053
67054
67055
67056
67057
67058
67059
67060
67061
67062
67063
67064
67065
67066
67067
67068
67069
67070
67071
67072
67073
67074
67075
67076
67077
67078
67079
67080
67081
67082
67083
67084
67085
67086
67087
67088
67089
67090
67091
67092
67093
67094
67095
67096
67097
67098
67099
67100
67101
67102
67103
67104
67105
67106
67107
67108
67109
67110
67111
67112
67113
67114
67115
67116
67117
67118
67119
67120
67121
67122
67123
67124
67125
67126
67127
67128
67129
67130
67131
67132
67133
67134
67135
67136
67137
67138
67139
67140
67141
67142
67143
67144
67145
67146
67147
67148
67149
67150
67151
67152
67153
67154
67155
67156
67157
67158
67159
67160
67161
67162
67163
67164
67165
67166
67167
67168
67169
67170
67171
67172
67173
67174
67175
67176
67177
67178
67179
67180
67181
67182
67183
67184
67185
67186
67187
67188
67189
67190
67191
67192
67193
67194
67195
67196
67197
67198
67199
67200
67201
67202
67203
67204
67205
67206
67207
67208
67209
67210
67211
67212
67213
67214
67215
67216
67217
67218
67219
67220
67221
67222
67223
67224
67225
67226
67227
67228
67229
67230
67231
67232
67233
67234
67235
67236
67237
67238
67239
67240
67241
67242
67243
67244
67245
67246
67247
67248
67249
67250
67251
67252
67253
67254
67255
67256
67257
67258
67259
67260
67261
67262
67263
67264
67265
67266
67267
67268
67269
67270
67271
67272
67273
67274
67275
67276
67277
67278
67279
67280
67281
67282
67283
67284
67285
67286
67287
67288
67289
67290
67291
67292
67293
67294
67295
67296
67297
67298
67299
67300
67301
67302
67303
67304
67305
67306
67307
67308
67309
67310
67311
67312
67313
67314
67315
67316
67317
67318
67319
67320
67321
67322
67323
67324
67325
67326
67327
67328
67329
67330
67331
67332
67333
67334
67335
67336
67337
67338
67339
67340
67341
67342
67343
67344
67345
67346
67347
67348
67349
67350
67351
67352
67353
67354
67355
67356
67357
67358
67359
67360
67361
67362
67363
67364
67365
67366
67367
67368
67369
67370
67371
67372
67373
67374
67375
67376
67377
67378
67379
67380
67381
67382
67383
67384
67385
67386
67387
67388
67389
67390
67391
67392
67393
67394
67395
67396
67397
67398
67399
67400
67401
67402
67403
67404
67405
67406
67407
67408
67409
67410
67411
67412
67413
67414
67415
67416
67417
67418
67419
67420
67421
67422
67423
67424
67425
67426
67427
67428
67429
67430
67431
67432
67433
67434
67435
67436
67437
67438
67439
67440
67441
67442
67443
67444
67445
67446
67447
67448
67449
67450
67451
67452
67453
67454
67455
67456
67457
67458
67459
67460
67461
67462
67463
67464
67465
67466
67467
67468
67469
67470
67471
67472
67473
67474
67475
67476
67477
67478
67479
67480
67481
67482
67483
67484
67485
67486
67487
67488
67489
67490
67491
67492
67493
67494
67495
67496
67497
67498
67499
67500
67501
67502
67503
67504
67505
67506
67507
67508
67509
67510
67511
67512
67513
67514
67515
67516
67517
67518
67519
67520
67521
67522
67523
67524
67525
67526
67527
67528
67529
67530
67531
67532
67533
67534
67535
67536
67537
67538
67539
67540
67541
67542
67543
67544
67545
67546
67547
67548
67549
67550
67551
67552
67553
67554
67555
67556
67557
67558
67559
67560
67561
67562
67563
67564
67565
67566
67567
67568
67569
67570
67571
67572
67573
67574
67575
67576
67577
67578
67579
67580
67581
67582
67583
67584
67585
67586
67587
67588
67589
67590
67591
67592
67593
67594
67595
67596
67597
67598
67599
67600
67601
67602
67603
67604
67605
67606
67607
67608
67609
67610
67611
67612
67613
67614
67615
67616
67617
67618
67619
67620
67621
67622
67623
67624
67625
67626
67627
67628
67629
67630
67631
67632
67633
67634
67635
67636
67637
67638
67639
67640
67641
67642
67643
67644
67645
67646
67647
67648
67649
67650
67651
67652
67653
67654
67655
67656
67657
67658
67659
67660
67661
67662
67663
67664
67665
67666
67667
67668
67669
67670
67671
67672
67673
67674
67675
67676
67677
67678
67679
67680
67681
67682
67683
67684
67685
67686
67687
67688
67689
67690
67691
67692
67693
67694
67695
67696
67697
67698
67699
67700
67701
67702
67703
67704
67705
67706
67707
67708
67709
67710
67711
67712
67713
67714
67715
67716
67717
67718
67719
67720
67721
67722
67723
67724
67725
67726
67727
67728
67729
67730
67731
67732
67733
67734
67735
67736
67737
67738
67739
67740
67741
67742
67743
67744
67745
67746
67747
67748
67749
67750
67751
67752
67753
67754
67755
67756
67757
67758
67759
67760
67761
67762
67763
67764
67765
67766
67767
67768
67769
67770
67771
67772
67773
67774
67775
67776
67777
67778
67779
67780
67781
67782
67783
67784
67785
67786
67787
67788
67789
67790
67791
67792
67793
67794
67795
67796
67797
67798
67799
67800
67801
67802
67803
67804
67805
67806
67807
67808
67809
67810
67811
67812
67813
67814
67815
67816
67817
67818
67819
67820
67821
67822
67823
67824
67825
67826
67827
67828
67829
67830
67831
67832
67833
67834
67835
67836
67837
67838
67839
67840
67841
67842
67843
67844
67845
67846
67847
67848
67849
67850
67851
67852
67853
67854
67855
67856
67857
67858
67859
67860
67861
67862
67863
67864
67865
67866
67867
67868
67869
67870
67871
67872
67873
67874
67875
67876
67877
67878
67879
67880
67881
67882
67883
67884
67885
67886
67887
67888
67889
67890
67891
67892
67893
67894
67895
67896
67897
67898
67899
67900
67901
67902
67903
67904
67905
67906
67907
67908
67909
67910
67911
67912
67913
67914
67915
67916
67917
67918
67919
67920
67921
67922
67923
67924
67925
67926
67927
67928
67929
67930
67931
67932
67933
67934
67935
67936
67937
67938
67939
67940
67941
67942
67943
67944
67945
67946
67947
67948
67949
67950
67951
67952
67953
67954
67955
67956
67957
67958
67959
67960
67961
67962
67963
67964
67965
67966
67967
67968
67969
67970
67971
67972
67973
67974
67975
67976
67977
67978
67979
67980
67981
67982
67983
67984
67985
67986
67987
67988
67989
67990
67991
67992
67993
67994
67995
67996
67997
67998
67999
68000
68001
68002
68003
68004
68005
68006
68007
68008
68009
68010
68011
68012
68013
68014
68015
68016
68017
68018
68019
68020
68021
68022
68023
68024
68025
68026
68027
68028
68029
68030
68031
68032
68033
68034
68035
68036
68037
68038
68039
68040
68041
68042
68043
68044
68045
68046
68047
68048
68049
68050
68051
68052
68053
68054
68055
68056
68057
68058
68059
68060
68061
68062
68063
68064
68065
68066
68067
68068
68069
68070
68071
68072
68073
68074
68075
68076
68077
68078
68079
68080
68081
68082
68083
68084
68085
68086
68087
68088
68089
68090
68091
68092
68093
68094
68095
68096
68097
68098
68099
68100
68101
68102
68103
68104
68105
68106
68107
68108
68109
68110
68111
68112
68113
68114
68115
68116
68117
68118
68119
68120
68121
68122
68123
68124
68125
68126
68127
68128
68129
68130
68131
68132
68133
68134
68135
68136
68137
68138
68139
68140
68141
68142
68143
68144
68145
68146
68147
68148
68149
68150
68151
68152
68153
68154
68155
68156
68157
68158
68159
68160
68161
68162
68163
68164
68165
68166
68167
68168
68169
68170
68171
68172
68173
68174
68175
68176
68177
68178
68179
68180
68181
68182
68183
68184
68185
68186
68187
68188
68189
68190
68191
68192
68193
68194
68195
68196
68197
68198
68199
68200
68201
68202
68203
68204
68205
68206
68207
68208
68209
68210
68211
68212
68213
68214
68215
68216
68217
68218
68219
68220
68221
68222
68223
68224
68225
68226
68227
68228
68229
68230
68231
68232
68233
68234
68235
68236
68237
68238
68239
68240
68241
68242
68243
68244
68245
68246
68247
68248
68249
68250
68251
68252
68253
68254
68255
68256
68257
68258
68259
68260
68261
68262
68263
68264
68265
68266
68267
68268
68269
68270
68271
68272
68273
68274
68275
68276
68277
68278
68279
68280
68281
68282
68283
68284
68285
68286
68287
68288
68289
68290
68291
68292
68293
68294
68295
68296
68297
68298
68299
68300
68301
68302
68303
68304
68305
68306
68307
68308
68309
68310
68311
68312
68313
68314
68315
68316
68317
68318
68319
68320
68321
68322
68323
68324
68325
68326
68327
68328
68329
68330
68331
68332
68333
68334
68335
68336
68337
68338
68339
68340
68341
68342
68343
68344
68345
68346
68347
68348
68349
68350
68351
68352
68353
68354
68355
68356
68357
68358
68359
68360
68361
68362
68363
68364
68365
68366
68367
68368
68369
68370
68371
68372
68373
68374
68375
68376
68377
68378
68379
68380
68381
68382
68383
68384
68385
68386
68387
68388
68389
68390
68391
68392
68393
68394
68395
68396
68397
68398
68399
68400
68401
68402
68403
68404
68405
68406
68407
68408
68409
68410
68411
68412
68413
68414
68415
68416
68417
68418
68419
68420
68421
68422
68423
68424
68425
68426
68427
68428
68429
68430
68431
68432
68433
68434
68435
68436
68437
68438
68439
68440
68441
68442
68443
68444
68445
68446
68447
68448
68449
68450
68451
68452
68453
68454
68455
68456
68457
68458
68459
68460
68461
68462
68463
68464
68465
68466
68467
68468
68469
68470
68471
68472
68473
68474
68475
68476
68477
68478
68479
68480
68481
68482
68483
68484
68485
68486
68487
68488
68489
68490
68491
68492
68493
68494
68495
68496
68497
68498
68499
68500
68501
68502
68503
68504
68505
68506
68507
68508
68509
68510
68511
68512
68513
68514
68515
68516
68517
68518
68519
68520
68521
68522
68523
68524
68525
68526
68527
68528
68529
68530
68531
68532
68533
68534
68535
68536
68537
68538
68539
68540
68541
68542
68543
68544
68545
68546
68547
68548
68549
68550
68551
68552
68553
68554
68555
68556
68557
68558
68559
68560
68561
68562
68563
68564
68565
68566
68567
68568
68569
68570
68571
68572
68573
68574
68575
68576
68577
68578
68579
68580
68581
68582
68583
68584
68585
68586
68587
68588
68589
68590
68591
68592
68593
68594
68595
68596
68597
68598
68599
68600
68601
68602
68603
68604
68605
68606
68607
68608
68609
68610
68611
68612
68613
68614
68615
68616
68617
68618
68619
68620
68621
68622
68623
68624
68625
68626
68627
68628
68629
68630
68631
68632
68633
68634
68635
68636
68637
68638
68639
68640
68641
68642
68643
68644
68645
68646
68647
68648
68649
68650
68651
68652
68653
68654
68655
68656
68657
68658
68659
68660
68661
68662
68663
68664
68665
68666
68667
68668
68669
68670
68671
68672
68673
68674
68675
68676
68677
68678
68679
68680
68681
68682
68683
68684
68685
68686
68687
68688
68689
68690
68691
68692
68693
68694
68695
68696
68697
68698
68699
68700
68701
68702
68703
68704
68705
68706
68707
68708
68709
68710
68711
68712
68713
68714
68715
68716
68717
68718
68719
68720
68721
68722
68723
68724
68725
68726
68727
68728
68729
68730
68731
68732
68733
68734
68735
68736
68737
68738
68739
68740
68741
68742
68743
68744
68745
68746
68747
68748
68749
68750
68751
68752
68753
68754
68755
68756
68757
68758
68759
68760
68761
68762
68763
68764
68765
68766
68767
68768
68769
68770
68771
68772
68773
68774
68775
68776
68777
68778
68779
68780
68781
68782
68783
68784
68785
68786
68787
68788
68789
68790
68791
68792
68793
68794
68795
68796
68797
68798
68799
68800
68801
68802
68803
68804
68805
68806
68807
68808
68809
68810
68811
68812
68813
68814
68815
68816
68817
68818
68819
68820
68821
68822
68823
68824
68825
68826
68827
68828
68829
68830
68831
68832
68833
68834
68835
68836
68837
68838
68839
68840
68841
68842
68843
68844
68845
68846
68847
68848
68849
68850
68851
68852
68853
68854
68855
68856
68857
68858
68859
68860
68861
68862
68863
68864
68865
68866
68867
68868
68869
68870
68871
68872
68873
68874
68875
68876
68877
68878
68879
68880
68881
68882
68883
68884
68885
68886
68887
68888
68889
68890
68891
68892
68893
68894
68895
68896
68897
68898
68899
68900
68901
68902
68903
68904
68905
68906
68907
68908
68909
68910
68911
68912
68913
68914
68915
68916
68917
68918
68919
68920
68921
68922
68923
68924
68925
68926
68927
68928
68929
68930
68931
68932
68933
68934
68935
68936
68937
68938
68939
68940
68941
68942
68943
68944
68945
68946
68947
68948
68949
68950
68951
68952
68953
68954
68955
68956
68957
68958
68959
68960
68961
68962
68963
68964
68965
68966
68967
68968
68969
68970
68971
68972
68973
68974
68975
68976
68977
68978
68979
68980
68981
68982
68983
68984
68985
68986
68987
68988
68989
68990
68991
68992
68993
68994
68995
68996
68997
68998
68999
69000
69001
69002
69003
69004
69005
69006
69007
69008
69009
69010
69011
69012
69013
69014
69015
69016
69017
69018
69019
69020
69021
69022
69023
69024
69025
69026
69027
69028
69029
69030
69031
69032
69033
69034
69035
69036
69037
69038
69039
69040
69041
69042
69043
69044
69045
69046
69047
69048
69049
69050
69051
69052
69053
69054
69055
69056
69057
69058
69059
69060
69061
69062
69063
69064
69065
69066
69067
69068
69069
69070
69071
69072
69073
69074
69075
69076
69077
69078
69079
69080
69081
69082
69083
69084
69085
69086
69087
69088
69089
69090
69091
69092
69093
69094
69095
69096
69097
69098
69099
69100
69101
69102
69103
69104
69105
69106
69107
69108
69109
69110
69111
69112
69113
69114
69115
69116
69117
69118
69119
69120
69121
69122
69123
69124
69125
69126
69127
69128
69129
69130
69131
69132
69133
69134
69135
69136
69137
69138
69139
69140
69141
69142
69143
69144
69145
69146
69147
69148
69149
69150
69151
69152
69153
69154
69155
69156
69157
69158
69159
69160
69161
69162
69163
69164
69165
69166
69167
69168
69169
69170
69171
69172
69173
69174
69175
69176
69177
69178
69179
69180
69181
69182
69183
69184
69185
69186
69187
69188
69189
69190
69191
69192
69193
69194
69195
69196
69197
69198
69199
69200
69201
69202
69203
69204
69205
69206
69207
69208
69209
69210
69211
69212
69213
69214
69215
69216
69217
69218
69219
69220
69221
69222
69223
69224
69225
69226
69227
69228
69229
69230
69231
69232
69233
69234
69235
69236
69237
69238
69239
69240
69241
69242
69243
69244
69245
69246
69247
69248
69249
69250
69251
69252
69253
69254
69255
69256
69257
69258
69259
69260
69261
69262
69263
69264
69265
69266
69267
69268
69269
69270
69271
69272
69273
69274
69275
69276
69277
69278
69279
69280
69281
69282
69283
69284
69285
69286
69287
69288
69289
69290
69291
69292
69293
69294
69295
69296
69297
69298
69299
69300
69301
69302
69303
69304
69305
69306
69307
69308
69309
69310
69311
69312
69313
69314
69315
69316
69317
69318
69319
69320
69321
69322
69323
69324
69325
69326
69327
69328
69329
69330
69331
69332
69333
69334
69335
69336
69337
69338
69339
69340
69341
69342
69343
69344
69345
69346
69347
69348
69349
69350
69351
69352
69353
69354
69355
69356
69357
69358
69359
69360
69361
69362
69363
69364
69365
69366
69367
69368
69369
69370
69371
69372
69373
69374
69375
69376
69377
69378
69379
69380
69381
69382
69383
69384
69385
69386
69387
69388
69389
69390
69391
69392
69393
69394
69395
69396
69397
69398
69399
69400
69401
69402
69403
69404
69405
69406
69407
69408
69409
69410
69411
69412
69413
69414
69415
69416
69417
69418
69419
69420
69421
69422
69423
69424
69425
69426
69427
69428
69429
69430
69431
69432
69433
69434
69435
69436
69437
69438
69439
69440
69441
69442
69443
69444
69445
69446
69447
69448
69449
69450
69451
69452
69453
69454
69455
69456
69457
69458
69459
69460
69461
69462
69463
69464
69465
69466
69467
69468
69469
69470
69471
69472
69473
69474
69475
69476
69477
69478
69479
69480
69481
69482
69483
69484
69485
69486
69487
69488
69489
69490
69491
69492
69493
69494
69495
69496
69497
69498
69499
69500
69501
69502
69503
69504
69505
69506
69507
69508
69509
69510
69511
69512
69513
69514
69515
69516
69517
69518
69519
69520
69521
69522
69523
69524
69525
69526
69527
69528
69529
69530
69531
69532
69533
69534
69535
69536
69537
69538
69539
69540
69541
69542
69543
69544
69545
69546
69547
69548
69549
69550
69551
69552
69553
69554
69555
69556
69557
69558
69559
69560
69561
69562
69563
69564
69565
69566
69567
69568
69569
69570
69571
69572
69573
69574
69575
69576
69577
69578
69579
69580
69581
69582
69583
69584
69585
69586
69587
69588
69589
69590
69591
69592
69593
69594
69595
69596
69597
69598
69599
69600
69601
69602
69603
69604
69605
69606
69607
69608
69609
69610
69611
69612
69613
69614
69615
69616
69617
69618
69619
69620
69621
69622
69623
69624
69625
69626
69627
69628
69629
69630
69631
69632
69633
69634
69635
69636
69637
69638
69639
69640
69641
69642
69643
69644
69645
69646
69647
69648
69649
69650
69651
69652
69653
69654
69655
69656
69657
69658
69659
69660
69661
69662
69663
69664
69665
69666
69667
69668
69669
69670
69671
69672
69673
69674
69675
69676
69677
69678
69679
69680
69681
69682
69683
69684
69685
69686
69687
69688
69689
69690
69691
69692
69693
69694
69695
69696
69697
69698
69699
69700
69701
69702
69703
69704
69705
69706
69707
69708
69709
69710
69711
69712
69713
69714
69715
69716
69717
69718
69719
69720
69721
69722
69723
69724
69725
69726
69727
69728
69729
69730
69731
69732
69733
69734
69735
69736
69737
69738
69739
69740
69741
69742
69743
69744
69745
69746
69747
69748
69749
69750
69751
69752
69753
69754
69755
69756
69757
69758
69759
69760
69761
69762
69763
69764
69765
69766
69767
69768
69769
69770
69771
69772
69773
69774
69775
69776
69777
69778
69779
69780
69781
69782
69783
69784
69785
69786
69787
69788
69789
69790
69791
69792
69793
69794
69795
69796
69797
69798
69799
69800
69801
69802
69803
69804
69805
69806
69807
69808
69809
69810
69811
69812
69813
69814
69815
69816
69817
69818
69819
69820
69821
69822
69823
69824
69825
69826
69827
69828
69829
69830
69831
69832
69833
69834
69835
69836
69837
69838
69839
69840
69841
69842
69843
69844
69845
69846
69847
69848
69849
69850
69851
69852
69853
69854
69855
69856
69857
69858
69859
69860
69861
69862
69863
69864
69865
69866
69867
69868
69869
69870
69871
69872
69873
69874
69875
69876
69877
69878
69879
69880
69881
69882
69883
69884
69885
69886
69887
69888
69889
69890
69891
69892
69893
69894
69895
69896
69897
69898
69899
69900
69901
69902
69903
69904
69905
69906
69907
69908
69909
69910
69911
69912
69913
69914
69915
69916
69917
69918
69919
69920
69921
69922
69923
69924
69925
69926
69927
69928
69929
69930
69931
69932
69933
69934
69935
69936
69937
69938
69939
69940
69941
69942
69943
69944
69945
69946
69947
69948
69949
69950
69951
69952
69953
69954
69955
69956
69957
69958
69959
69960
69961
69962
69963
69964
69965
69966
69967
69968
69969
69970
69971
69972
69973
69974
69975
69976
69977
69978
69979
69980
69981
69982
69983
69984
69985
69986
69987
69988
69989
69990
69991
69992
69993
69994
69995
69996
69997
69998
69999
70000
70001
70002
70003
70004
70005
70006
70007
70008
70009
70010
70011
70012
70013
70014
70015
70016
70017
70018
70019
70020
70021
70022
70023
70024
70025
70026
70027
70028
70029
70030
70031
70032
70033
70034
70035
70036
70037
70038
70039
70040
70041
70042
70043
70044
70045
70046
70047
70048
70049
70050
70051
70052
70053
70054
70055
70056
70057
70058
70059
70060
70061
70062
70063
70064
70065
70066
70067
70068
70069
70070
70071
70072
70073
70074
70075
70076
70077
70078
70079
70080
70081
70082
70083
70084
70085
70086
70087
70088
70089
70090
70091
70092
70093
70094
70095
70096
70097
70098
70099
70100
70101
70102
70103
70104
70105
70106
70107
70108
70109
70110
70111
70112
70113
70114
70115
70116
70117
70118
70119
70120
70121
70122
70123
70124
70125
70126
70127
70128
70129
70130
70131
70132
70133
70134
70135
70136
70137
70138
70139
70140
70141
70142
70143
70144
70145
70146
70147
70148
70149
70150
70151
70152
70153
70154
70155
70156
70157
70158
70159
70160
70161
70162
70163
70164
70165
70166
70167
70168
70169
70170
70171
70172
70173
70174
70175
70176
70177
70178
70179
70180
70181
70182
70183
70184
70185
70186
70187
70188
70189
70190
70191
70192
70193
70194
70195
70196
70197
70198
70199
70200
70201
70202
70203
70204
70205
70206
70207
70208
70209
70210
70211
70212
70213
70214
70215
70216
70217
70218
70219
70220
70221
70222
70223
70224
70225
70226
70227
70228
70229
70230
70231
70232
70233
70234
70235
70236
70237
70238
70239
70240
70241
70242
70243
70244
70245
70246
70247
70248
70249
70250
70251
70252
70253
70254
70255
70256
70257
70258
70259
70260
70261
70262
70263
70264
70265
70266
70267
70268
70269
70270
70271
70272
70273
70274
70275
70276
70277
70278
70279
70280
70281
70282
70283
70284
70285
70286
70287
70288
70289
70290
70291
70292
70293
70294
70295
70296
70297
70298
70299
70300
70301
70302
70303
70304
70305
70306
70307
70308
70309
70310
70311
70312
70313
70314
70315
70316
70317
70318
70319
70320
70321
70322
70323
70324
70325
70326
70327
70328
70329
70330
70331
70332
70333
70334
70335
70336
70337
70338
70339
70340
70341
70342
70343
70344
70345
70346
70347
70348
70349
70350
70351
70352
70353
70354
70355
70356
70357
70358
70359
70360
70361
70362
70363
70364
70365
70366
70367
70368
70369
70370
70371
70372
70373
70374
70375
70376
70377
70378
70379
70380
70381
70382
70383
70384
70385
70386
70387
70388
70389
70390
70391
70392
70393
70394
70395
70396
70397
70398
70399
70400
70401
70402
70403
70404
70405
70406
70407
70408
70409
70410
70411
70412
70413
70414
70415
70416
70417
70418
70419
70420
70421
70422
70423
70424
70425
70426
70427
70428
70429
70430
70431
70432
70433
70434
70435
70436
70437
70438
70439
70440
70441
70442
70443
70444
70445
70446
70447
70448
70449
70450
70451
70452
70453
70454
70455
70456
70457
70458
70459
70460
70461
70462
70463
70464
70465
70466
70467
70468
70469
70470
70471
70472
70473
70474
70475
70476
70477
70478
70479
70480
70481
70482
70483
70484
70485
70486
70487
70488
70489
70490
70491
70492
70493
70494
70495
70496
70497
70498
70499
70500
70501
70502
70503
70504
70505
70506
70507
70508
70509
70510
70511
70512
70513
70514
70515
70516
70517
70518
70519
70520
70521
70522
70523
70524
70525
70526
70527
70528
70529
70530
70531
70532
70533
70534
70535
70536
70537
70538
70539
70540
70541
70542
70543
70544
70545
70546
70547
70548
70549
70550
70551
70552
70553
70554
70555
70556
70557
70558
70559
70560
70561
70562
70563
70564
70565
70566
70567
70568
70569
70570
70571
70572
70573
70574
70575
70576
70577
70578
70579
70580
70581
70582
70583
70584
70585
70586
70587
70588
70589
70590
70591
70592
70593
70594
70595
70596
70597
70598
70599
70600
70601
70602
70603
70604
70605
70606
70607
70608
70609
70610
70611
70612
70613
70614
70615
70616
70617
70618
70619
70620
70621
70622
70623
70624
70625
70626
70627
70628
70629
70630
70631
70632
70633
70634
70635
70636
70637
70638
70639
70640
70641
70642
70643
70644
70645
70646
70647
70648
70649
70650
70651
70652
70653
70654
70655
70656
70657
70658
70659
70660
70661
70662
70663
70664
70665
70666
70667
70668
70669
70670
70671
70672
70673
70674
70675
70676
70677
70678
70679
70680
70681
70682
70683
70684
70685
70686
70687
70688
70689
70690
70691
70692
70693
70694
70695
70696
70697
70698
70699
70700
70701
70702
70703
70704
70705
70706
70707
70708
70709
70710
70711
70712
70713
70714
70715
70716
70717
70718
70719
70720
70721
70722
70723
70724
70725
70726
70727
70728
70729
70730
70731
70732
70733
70734
70735
70736
70737
70738
70739
70740
70741
70742
70743
70744
70745
70746
70747
70748
70749
70750
70751
70752
70753
70754
70755
70756
70757
70758
70759
70760
70761
70762
70763
70764
70765
70766
70767
70768
70769
70770
70771
70772
70773
70774
70775
70776
70777
70778
70779
70780
70781
70782
70783
70784
70785
70786
70787
70788
70789
70790
70791
70792
70793
70794
70795
70796
70797
70798
70799
70800
70801
70802
70803
70804
70805
70806
70807
70808
70809
70810
70811
70812
70813
70814
70815
70816
70817
70818
70819
70820
70821
70822
70823
70824
70825
70826
70827
70828
70829
70830
70831
70832
70833
70834
70835
70836
70837
70838
70839
70840
70841
70842
70843
70844
70845
70846
70847
70848
70849
70850
70851
70852
70853
70854
70855
70856
70857
70858
70859
70860
70861
70862
70863
70864
70865
70866
70867
70868
70869
70870
70871
70872
70873
70874
70875
70876
70877
70878
70879
70880
70881
70882
70883
70884
70885
70886
70887
70888
70889
70890
70891
70892
70893
70894
70895
70896
70897
70898
70899
70900
70901
70902
70903
70904
70905
70906
70907
70908
70909
70910
70911
70912
70913
70914
70915
70916
70917
70918
70919
70920
70921
70922
70923
70924
70925
70926
70927
70928
70929
70930
70931
70932
70933
70934
70935
70936
70937
70938
70939
70940
70941
70942
70943
70944
70945
70946
70947
70948
70949
70950
70951
70952
70953
70954
70955
70956
70957
70958
70959
70960
70961
70962
70963
70964
70965
70966
70967
70968
70969
70970
70971
70972
70973
70974
70975
70976
70977
70978
70979
70980
70981
70982
70983
70984
70985
70986
70987
70988
70989
70990
70991
70992
70993
70994
70995
70996
70997
70998
70999
71000
71001
71002
71003
71004
71005
71006
71007
71008
71009
71010
71011
71012
71013
71014
71015
71016
71017
71018
71019
71020
71021
71022
71023
71024
71025
71026
71027
71028
71029
71030
71031
71032
71033
71034
71035
71036
71037
71038
71039
71040
71041
71042
71043
71044
71045
71046
71047
71048
71049
71050
71051
71052
71053
71054
71055
71056
71057
71058
71059
71060
71061
71062
71063
71064
71065
71066
71067
71068
71069
71070
71071
71072
71073
71074
71075
71076
71077
71078
71079
71080
71081
71082
71083
71084
71085
71086
71087
71088
71089
71090
71091
71092
71093
71094
71095
71096
71097
71098
71099
71100
71101
71102
71103
71104
71105
71106
71107
71108
71109
71110
71111
71112
71113
71114
71115
71116
71117
71118
71119
71120
71121
71122
71123
71124
71125
71126
71127
71128
71129
71130
71131
71132
71133
71134
71135
71136
71137
71138
71139
71140
71141
71142
71143
71144
71145
71146
71147
71148
71149
71150
71151
71152
71153
71154
71155
71156
71157
71158
71159
71160
71161
71162
71163
71164
71165
71166
71167
71168
71169
71170
71171
71172
71173
71174
71175
71176
71177
71178
71179
71180
71181
71182
71183
71184
71185
71186
71187
71188
71189
71190
71191
71192
71193
71194
71195
71196
71197
71198
71199
71200
71201
71202
71203
71204
71205
71206
71207
71208
71209
71210
71211
71212
71213
71214
71215
71216
71217
71218
71219
71220
71221
71222
71223
71224
71225
71226
71227
71228
71229
71230
71231
71232
71233
71234
71235
71236
71237
71238
71239
71240
71241
71242
71243
71244
71245
71246
71247
71248
71249
71250
71251
71252
71253
71254
71255
71256
71257
71258
71259
71260
71261
71262
71263
71264
71265
71266
71267
71268
71269
71270
71271
71272
71273
71274
71275
71276
71277
71278
71279
71280
71281
71282
71283
71284
71285
71286
71287
71288
71289
71290
71291
71292
71293
71294
71295
71296
71297
71298
71299
71300
71301
71302
71303
71304
71305
71306
71307
71308
71309
71310
71311
71312
71313
71314
71315
71316
71317
71318
71319
71320
71321
71322
71323
71324
71325
71326
71327
71328
71329
71330
71331
71332
71333
71334
71335
71336
71337
71338
71339
71340
71341
71342
71343
71344
71345
71346
71347
71348
71349
71350
71351
71352
71353
71354
71355
71356
71357
71358
71359
71360
71361
71362
71363
71364
71365
71366
71367
71368
71369
71370
71371
71372
71373
71374
71375
71376
71377
71378
71379
71380
71381
71382
71383
71384
71385
71386
71387
71388
71389
71390
71391
71392
71393
71394
71395
71396
71397
71398
71399
71400
71401
71402
71403
71404
71405
71406
71407
71408
71409
71410
71411
71412
71413
71414
71415
71416
71417
71418
71419
71420
71421
71422
71423
71424
71425
71426
71427
71428
71429
71430
71431
71432
71433
71434
71435
71436
71437
71438
71439
71440
71441
71442
71443
71444
71445
71446
71447
71448
71449
71450
71451
71452
71453
71454
71455
71456
71457
71458
71459
71460
71461
71462
71463
71464
71465
71466
71467
71468
71469
71470
71471
71472
71473
71474
71475
71476
71477
71478
71479
71480
71481
71482
71483
71484
71485
71486
71487
71488
71489
71490
71491
71492
71493
71494
71495
71496
71497
71498
71499
71500
71501
71502
71503
71504
71505
71506
71507
71508
71509
71510
71511
71512
71513
71514
71515
71516
71517
71518
71519
71520
71521
71522
71523
71524
71525
71526
71527
71528
71529
71530
71531
71532
71533
71534
71535
71536
71537
71538
71539
71540
71541
71542
71543
71544
71545
71546
71547
71548
71549
71550
71551
71552
71553
71554
71555
71556
71557
71558
71559
71560
71561
71562
71563
71564
71565
71566
71567
71568
71569
71570
71571
71572
71573
71574
71575
71576
71577
71578
71579
71580
71581
71582
71583
71584
71585
71586
71587
71588
71589
71590
71591
71592
71593
71594
71595
71596
71597
71598
71599
71600
71601
71602
71603
71604
71605
71606
71607
71608
71609
71610
71611
71612
71613
71614
71615
71616
71617
71618
71619
71620
71621
71622
71623
71624
71625
71626
71627
71628
71629
71630
71631
71632
71633
71634
71635
71636
71637
71638
71639
71640
71641
71642
71643
71644
71645
71646
71647
71648
71649
71650
71651
71652
71653
71654
71655
71656
71657
71658
71659
71660
71661
71662
71663
71664
71665
71666
71667
71668
71669
71670
71671
71672
71673
71674
71675
71676
71677
71678
71679
71680
71681
71682
71683
71684
71685
71686
71687
71688
71689
71690
71691
71692
71693
71694
71695
71696
71697
71698
71699
71700
71701
71702
71703
71704
71705
71706
71707
71708
71709
71710
71711
71712
71713
71714
71715
71716
71717
71718
71719
71720
71721
71722
71723
71724
71725
71726
71727
71728
71729
71730
71731
71732
71733
71734
71735
71736
71737
71738
71739
71740
71741
71742
71743
71744
71745
71746
71747
71748
71749
71750
71751
71752
71753
71754
71755
71756
71757
71758
71759
71760
71761
71762
71763
71764
71765
71766
71767
71768
71769
71770
71771
71772
71773
71774
71775
71776
71777
71778
71779
71780
71781
71782
71783
71784
71785
71786
71787
71788
71789
71790
71791
71792
71793
71794
71795
71796
71797
71798
71799
71800
71801
71802
71803
71804
71805
71806
71807
71808
71809
71810
71811
71812
71813
71814
71815
71816
71817
71818
71819
71820
71821
71822
71823
71824
71825
71826
71827
71828
71829
71830
71831
71832
71833
71834
71835
71836
71837
71838
71839
71840
71841
71842
71843
71844
71845
71846
71847
71848
71849
71850
71851
71852
71853
71854
71855
71856
71857
71858
71859
71860
71861
71862
71863
71864
71865
71866
71867
71868
71869
71870
71871
71872
71873
71874
71875
71876
71877
71878
71879
71880
71881
71882
71883
71884
71885
71886
71887
71888
71889
71890
71891
71892
71893
71894
71895
71896
71897
71898
71899
71900
71901
71902
71903
71904
71905
71906
71907
71908
71909
71910
71911
71912
71913
71914
71915
71916
71917
71918
71919
71920
71921
71922
71923
71924
71925
71926
71927
71928
71929
71930
71931
71932
71933
71934
71935
71936
71937
71938
71939
71940
71941
71942
71943
71944
71945
71946
71947
71948
71949
71950
71951
71952
71953
71954
71955
71956
71957
71958
71959
71960
71961
71962
71963
71964
71965
71966
71967
71968
71969
71970
71971
71972
71973
71974
71975
71976
71977
71978
71979
71980
71981
71982
71983
71984
71985
71986
71987
71988
71989
71990
71991
71992
71993
71994
71995
71996
71997
71998
71999
72000
72001
72002
72003
72004
72005
72006
72007
72008
72009
72010
72011
72012
72013
72014
72015
72016
72017
72018
72019
72020
72021
72022
72023
72024
72025
72026
72027
72028
72029
72030
72031
72032
72033
72034
72035
72036
72037
72038
72039
72040
72041
72042
72043
72044
72045
72046
72047
72048
72049
72050
72051
72052
72053
72054
72055
72056
72057
72058
72059
72060
72061
72062
72063
72064
72065
72066
72067
72068
72069
72070
72071
72072
72073
72074
72075
72076
72077
72078
72079
72080
72081
72082
72083
72084
72085
72086
72087
72088
72089
72090
72091
72092
72093
72094
72095
72096
72097
72098
72099
72100
72101
72102
72103
72104
72105
72106
72107
72108
72109
72110
72111
72112
72113
72114
72115
72116
72117
72118
72119
72120
72121
72122
72123
72124
72125
72126
72127
72128
72129
72130
72131
72132
72133
72134
72135
72136
72137
72138
72139
72140
72141
72142
72143
72144
72145
72146
72147
72148
72149
72150
72151
72152
72153
72154
72155
72156
72157
72158
72159
72160
72161
72162
72163
72164
72165
72166
72167
72168
72169
72170
72171
72172
72173
72174
72175
72176
72177
72178
72179
72180
72181
72182
72183
72184
72185
72186
72187
72188
72189
72190
72191
72192
72193
72194
72195
72196
72197
72198
72199
72200
72201
72202
72203
72204
72205
72206
72207
72208
72209
72210
72211
72212
72213
72214
72215
72216
72217
72218
72219
72220
72221
72222
72223
72224
72225
72226
72227
72228
72229
72230
72231
72232
72233
72234
72235
72236
72237
72238
72239
72240
72241
72242
72243
72244
72245
72246
72247
72248
72249
72250
72251
72252
72253
72254
72255
72256
72257
72258
72259
72260
72261
72262
72263
72264
72265
72266
72267
72268
72269
72270
72271
72272
72273
72274
72275
72276
72277
72278
72279
72280
72281
72282
72283
72284
72285
72286
72287
72288
72289
72290
72291
72292
72293
72294
72295
72296
72297
72298
72299
72300
72301
72302
72303
72304
72305
72306
72307
72308
72309
72310
72311
72312
72313
72314
72315
72316
72317
72318
72319
72320
72321
72322
72323
72324
72325
72326
72327
72328
72329
72330
72331
72332
72333
72334
72335
72336
72337
72338
72339
72340
72341
72342
72343
72344
72345
72346
72347
72348
72349
72350
72351
72352
72353
72354
72355
72356
72357
72358
72359
72360
72361
72362
72363
72364
72365
72366
72367
72368
72369
72370
72371
72372
72373
72374
72375
72376
72377
72378
72379
72380
72381
72382
72383
72384
72385
72386
72387
72388
72389
72390
72391
72392
72393
72394
72395
72396
72397
72398
72399
72400
72401
72402
72403
72404
72405
72406
72407
72408
72409
72410
72411
72412
72413
72414
72415
72416
72417
72418
72419
72420
72421
72422
72423
72424
72425
72426
72427
72428
72429
72430
72431
72432
72433
72434
72435
72436
72437
72438
72439
72440
72441
72442
72443
72444
72445
72446
72447
72448
72449
72450
72451
72452
72453
72454
72455
72456
72457
72458
72459
72460
72461
72462
72463
72464
72465
72466
72467
72468
72469
72470
72471
72472
72473
72474
72475
72476
72477
72478
72479
72480
72481
72482
72483
72484
72485
72486
72487
72488
72489
72490
72491
72492
72493
72494
72495
72496
72497
72498
72499
72500
72501
72502
72503
72504
72505
72506
72507
72508
72509
72510
72511
72512
72513
72514
72515
72516
72517
72518
72519
72520
72521
72522
72523
72524
72525
72526
72527
72528
72529
72530
72531
72532
72533
72534
72535
72536
72537
72538
72539
72540
72541
72542
72543
72544
72545
72546
72547
72548
72549
72550
72551
72552
72553
72554
72555
72556
72557
72558
72559
72560
72561
72562
72563
72564
72565
72566
72567
72568
72569
72570
72571
72572
72573
72574
72575
72576
72577
72578
72579
72580
72581
72582
72583
72584
72585
72586
72587
72588
72589
72590
72591
72592
72593
72594
72595
72596
72597
72598
72599
72600
72601
72602
72603
72604
72605
72606
72607
72608
72609
72610
72611
72612
72613
72614
72615
72616
72617
72618
72619
72620
72621
72622
72623
72624
72625
72626
72627
72628
72629
72630
72631
72632
72633
72634
72635
72636
72637
72638
72639
72640
72641
72642
72643
72644
72645
72646
72647
72648
72649
72650
72651
72652
72653
72654
72655
72656
72657
72658
72659
72660
72661
72662
72663
72664
72665
72666
72667
72668
72669
72670
72671
72672
72673
72674
72675
72676
72677
72678
72679
72680
72681
72682
72683
72684
72685
72686
72687
72688
72689
72690
72691
72692
72693
72694
72695
72696
72697
72698
72699
72700
72701
72702
72703
72704
72705
72706
72707
72708
72709
72710
72711
72712
72713
72714
72715
72716
72717
72718
72719
72720
72721
72722
72723
72724
72725
72726
72727
72728
72729
72730
72731
72732
72733
72734
72735
72736
72737
72738
72739
72740
72741
72742
72743
72744
72745
72746
72747
72748
72749
72750
72751
72752
72753
72754
72755
72756
72757
72758
72759
72760
72761
72762
72763
72764
72765
72766
72767
72768
72769
72770
72771
72772
72773
72774
72775
72776
72777
72778
72779
72780
72781
72782
72783
72784
72785
72786
72787
72788
72789
72790
72791
72792
72793
72794
72795
72796
72797
72798
72799
72800
72801
72802
72803
72804
72805
72806
72807
72808
72809
72810
72811
72812
72813
72814
72815
72816
72817
72818
72819
72820
72821
72822
72823
72824
72825
72826
72827
72828
72829
72830
72831
72832
72833
72834
72835
72836
72837
72838
72839
72840
72841
72842
72843
72844
72845
72846
72847
72848
72849
72850
72851
72852
72853
72854
72855
72856
72857
72858
72859
72860
72861
72862
72863
72864
72865
72866
72867
72868
72869
72870
72871
72872
72873
72874
72875
72876
72877
72878
72879
72880
72881
72882
72883
72884
72885
72886
72887
72888
72889
72890
72891
72892
72893
72894
72895
72896
72897
72898
72899
72900
72901
72902
72903
72904
72905
72906
72907
72908
72909
72910
72911
72912
72913
72914
72915
72916
72917
72918
72919
72920
72921
72922
72923
72924
72925
72926
72927
72928
72929
72930
72931
72932
72933
72934
72935
72936
72937
72938
72939
72940
72941
72942
72943
72944
72945
72946
72947
72948
72949
72950
72951
72952
72953
72954
72955
72956
72957
72958
72959
72960
72961
72962
72963
72964
72965
72966
72967
72968
72969
72970
72971
72972
72973
72974
72975
72976
72977
72978
72979
72980
72981
72982
72983
72984
72985
72986
72987
72988
72989
72990
72991
72992
72993
72994
72995
72996
72997
72998
72999
73000
73001
73002
73003
73004
73005
73006
73007
73008
73009
73010
73011
73012
73013
73014
73015
73016
73017
73018
73019
73020
73021
73022
73023
73024
73025
73026
73027
73028
73029
73030
73031
73032
73033
73034
73035
73036
73037
73038
73039
73040
73041
73042
73043
73044
73045
73046
73047
73048
73049
73050
73051
73052
73053
73054
73055
73056
73057
73058
73059
73060
73061
73062
73063
73064
73065
73066
73067
73068
73069
73070
73071
73072
73073
73074
73075
73076
73077
73078
73079
73080
73081
73082
73083
73084
73085
73086
73087
73088
73089
73090
73091
73092
73093
73094
73095
73096
73097
73098
73099
73100
73101
73102
73103
73104
73105
73106
73107
73108
73109
73110
73111
73112
73113
73114
73115
73116
73117
73118
73119
73120
73121
73122
73123
73124
73125
73126
73127
73128
73129
73130
73131
73132
73133
73134
73135
73136
73137
73138
73139
73140
73141
73142
73143
73144
73145
73146
73147
73148
73149
73150
73151
73152
73153
73154
73155
73156
73157
73158
73159
73160
73161
73162
73163
73164
73165
73166
73167
73168
73169
73170
73171
73172
73173
73174
73175
73176
73177
73178
73179
73180
73181
73182
73183
73184
73185
73186
73187
73188
73189
73190
73191
73192
73193
73194
73195
73196
73197
73198
73199
73200
73201
73202
73203
73204
73205
73206
73207
73208
73209
73210
73211
73212
73213
73214
73215
73216
73217
73218
73219
73220
73221
73222
73223
73224
73225
73226
73227
73228
73229
73230
73231
73232
73233
73234
73235
73236
73237
73238
73239
73240
73241
73242
73243
73244
73245
73246
73247
73248
73249
73250
73251
73252
73253
73254
73255
73256
73257
73258
73259
73260
73261
73262
73263
73264
73265
73266
73267
73268
73269
73270
73271
73272
73273
73274
73275
73276
73277
73278
73279
73280
73281
73282
73283
73284
73285
73286
73287
73288
73289
73290
73291
73292
73293
73294
73295
73296
73297
73298
73299
73300
73301
73302
73303
73304
73305
73306
73307
73308
73309
73310
73311
73312
73313
73314
73315
73316
73317
73318
73319
73320
73321
73322
73323
73324
73325
73326
73327
73328
73329
73330
73331
73332
73333
73334
73335
73336
73337
73338
73339
73340
73341
73342
73343
73344
73345
73346
73347
73348
73349
73350
73351
73352
73353
73354
73355
73356
73357
73358
73359
73360
73361
73362
73363
73364
73365
73366
73367
73368
73369
73370
73371
73372
73373
73374
73375
73376
73377
73378
73379
73380
73381
73382
73383
73384
73385
73386
73387
73388
73389
73390
73391
73392
73393
73394
73395
73396
73397
73398
73399
73400
73401
73402
73403
73404
73405
73406
73407
73408
73409
73410
73411
73412
73413
73414
73415
73416
73417
73418
73419
73420
73421
73422
73423
73424
73425
73426
73427
73428
73429
73430
73431
73432
73433
73434
73435
73436
73437
73438
73439
73440
73441
73442
73443
73444
73445
73446
73447
73448
73449
73450
73451
73452
73453
73454
73455
73456
73457
73458
73459
73460
73461
73462
73463
73464
73465
73466
73467
73468
73469
73470
73471
73472
73473
73474
73475
73476
73477
73478
73479
73480
73481
73482
73483
73484
73485
73486
73487
73488
73489
73490
73491
73492
73493
73494
73495
73496
73497
73498
73499
73500
73501
73502
73503
73504
73505
73506
73507
73508
73509
73510
73511
73512
73513
73514
73515
73516
73517
73518
73519
73520
73521
73522
73523
73524
73525
73526
73527
73528
73529
73530
73531
73532
73533
73534
73535
73536
73537
73538
73539
73540
73541
73542
73543
73544
73545
73546
73547
73548
73549
73550
73551
73552
73553
73554
73555
73556
73557
73558
73559
73560
73561
73562
73563
73564
73565
73566
73567
73568
73569
73570
73571
73572
73573
73574
73575
73576
73577
73578
73579
73580
73581
73582
73583
73584
73585
73586
73587
73588
73589
73590
73591
73592
73593
73594
73595
73596
73597
73598
73599
73600
73601
73602
73603
73604
73605
73606
73607
73608
73609
73610
73611
73612
73613
73614
73615
73616
73617
73618
73619
73620
73621
73622
73623
73624
73625
73626
73627
73628
73629
73630
73631
73632
73633
73634
73635
73636
73637
73638
73639
73640
73641
73642
73643
73644
73645
73646
73647
73648
73649
73650
73651
73652
73653
73654
73655
73656
73657
73658
73659
73660
73661
73662
73663
73664
73665
73666
73667
73668
73669
73670
73671
73672
73673
73674
73675
73676
73677
73678
73679
73680
73681
73682
73683
73684
73685
73686
73687
73688
73689
73690
73691
73692
73693
73694
73695
73696
73697
73698
73699
73700
73701
73702
73703
73704
73705
73706
73707
73708
73709
73710
73711
73712
73713
73714
73715
73716
73717
73718
73719
73720
73721
73722
73723
73724
73725
73726
73727
73728
73729
73730
73731
73732
73733
73734
73735
73736
73737
73738
73739
73740
73741
73742
73743
73744
73745
73746
73747
73748
73749
73750
73751
73752
73753
73754
73755
73756
73757
73758
73759
73760
73761
73762
73763
73764
73765
73766
73767
73768
73769
73770
73771
73772
73773
73774
73775
73776
73777
73778
73779
73780
73781
73782
73783
73784
73785
73786
73787
73788
73789
73790
73791
73792
73793
73794
73795
73796
73797
73798
73799
73800
73801
73802
73803
73804
73805
73806
73807
73808
73809
73810
73811
73812
73813
73814
73815
73816
73817
73818
73819
73820
73821
73822
73823
73824
73825
73826
73827
73828
73829
73830
73831
73832
73833
73834
73835
73836
73837
73838
73839
73840
73841
73842
73843
73844
73845
73846
73847
73848
73849
73850
73851
73852
73853
73854
73855
73856
73857
73858
73859
73860
73861
73862
73863
73864
73865
73866
73867
73868
73869
73870
73871
73872
73873
73874
73875
73876
73877
73878
73879
73880
73881
73882
73883
73884
73885
73886
73887
73888
73889
73890
73891
73892
73893
73894
73895
73896
73897
73898
73899
73900
73901
73902
73903
73904
73905
73906
73907
73908
73909
73910
73911
73912
73913
73914
73915
73916
73917
73918
73919
73920
73921
73922
73923
73924
73925
73926
73927
73928
73929
73930
73931
73932
73933
73934
73935
73936
73937
73938
73939
73940
73941
73942
73943
73944
73945
73946
73947
73948
73949
73950
73951
73952
73953
73954
73955
73956
73957
73958
73959
73960
73961
73962
73963
73964
73965
73966
73967
73968
73969
73970
73971
73972
73973
73974
73975
73976
73977
73978
73979
73980
73981
73982
73983
73984
73985
73986
73987
73988
73989
73990
73991
73992
73993
73994
73995
73996
73997
73998
73999
74000
74001
74002
74003
74004
74005
74006
74007
74008
74009
74010
74011
74012
74013
74014
74015
74016
74017
74018
74019
74020
74021
74022
74023
74024
74025
74026
74027
74028
74029
74030
74031
74032
74033
74034
74035
74036
74037
74038
74039
74040
74041
74042
74043
74044
74045
74046
74047
74048
74049
74050
74051
74052
74053
74054
74055
74056
74057
74058
74059
74060
74061
74062
74063
74064
74065
74066
74067
74068
74069
74070
74071
74072
74073
74074
74075
74076
74077
74078
74079
74080
74081
74082
74083
74084
74085
74086
74087
74088
74089
74090
74091
74092
74093
74094
74095
74096
74097
74098
74099
74100
74101
74102
74103
74104
74105
74106
74107
74108
74109
74110
74111
74112
74113
74114
74115
74116
74117
74118
74119
74120
74121
74122
74123
74124
74125
74126
74127
74128
74129
74130
74131
74132
74133
74134
74135
74136
74137
74138
74139
74140
74141
74142
74143
74144
74145
74146
74147
74148
74149
74150
74151
74152
74153
74154
74155
74156
74157
74158
74159
74160
74161
74162
74163
74164
74165
74166
74167
74168
74169
74170
74171
74172
74173
74174
74175
74176
74177
74178
74179
74180
74181
74182
74183
74184
74185
74186
74187
74188
74189
74190
74191
74192
74193
74194
74195
74196
74197
74198
74199
74200
74201
74202
74203
74204
74205
74206
74207
74208
74209
74210
74211
74212
74213
74214
74215
74216
74217
74218
74219
74220
74221
74222
74223
74224
74225
74226
74227
74228
74229
74230
74231
74232
74233
74234
74235
74236
74237
74238
74239
74240
74241
74242
74243
74244
74245
74246
74247
74248
74249
74250
74251
74252
74253
74254
74255
74256
74257
74258
74259
74260
74261
74262
74263
74264
74265
74266
74267
74268
74269
74270
74271
74272
74273
74274
74275
74276
74277
74278
74279
74280
74281
74282
74283
74284
74285
74286
74287
74288
74289
74290
74291
74292
74293
74294
74295
74296
74297
74298
74299
74300
74301
74302
74303
74304
74305
74306
74307
74308
74309
74310
74311
74312
74313
74314
74315
74316
74317
74318
74319
74320
74321
74322
74323
74324
74325
74326
74327
74328
74329
74330
74331
74332
74333
74334
74335
74336
74337
74338
74339
74340
74341
74342
74343
74344
74345
74346
74347
74348
74349
74350
74351
74352
74353
74354
74355
74356
74357
74358
74359
74360
74361
74362
74363
74364
74365
74366
74367
74368
74369
74370
74371
74372
74373
74374
74375
74376
74377
74378
74379
74380
74381
74382
74383
74384
74385
74386
74387
74388
74389
74390
74391
74392
74393
74394
74395
74396
74397
74398
74399
74400
74401
74402
74403
74404
74405
74406
74407
74408
74409
74410
74411
74412
74413
74414
74415
74416
74417
74418
74419
74420
74421
74422
74423
74424
74425
74426
74427
74428
74429
74430
74431
74432
74433
74434
74435
74436
74437
74438
74439
74440
74441
74442
74443
74444
74445
74446
74447
74448
74449
74450
74451
74452
74453
74454
74455
74456
74457
74458
74459
74460
74461
74462
74463
74464
74465
74466
74467
74468
74469
74470
74471
74472
74473
74474
74475
74476
74477
74478
74479
74480
74481
74482
74483
74484
74485
74486
74487
74488
74489
74490
74491
74492
74493
74494
74495
74496
74497
74498
74499
74500
74501
74502
74503
74504
74505
74506
74507
74508
74509
74510
74511
74512
74513
74514
74515
74516
74517
74518
74519
74520
74521
74522
74523
74524
74525
74526
74527
74528
74529
74530
74531
74532
74533
74534
74535
74536
74537
74538
74539
74540
74541
74542
74543
74544
74545
74546
74547
74548
74549
74550
74551
74552
74553
74554
74555
74556
74557
74558
74559
74560
74561
74562
74563
74564
74565
74566
74567
74568
74569
74570
74571
74572
74573
74574
74575
74576
74577
74578
74579
74580
74581
74582
74583
74584
74585
74586
74587
74588
74589
74590
74591
74592
74593
74594
74595
74596
74597
74598
74599
74600
74601
74602
74603
74604
74605
74606
74607
74608
74609
74610
74611
74612
74613
74614
74615
74616
74617
74618
74619
74620
74621
74622
74623
74624
74625
74626
74627
74628
74629
74630
74631
74632
74633
74634
74635
74636
74637
74638
74639
74640
74641
74642
74643
74644
74645
74646
74647
74648
74649
74650
74651
74652
74653
74654
74655
74656
74657
74658
74659
74660
74661
74662
74663
74664
74665
74666
74667
74668
74669
74670
74671
74672
74673
74674
74675
74676
74677
74678
74679
74680
74681
74682
74683
74684
74685
74686
74687
74688
74689
74690
74691
74692
74693
74694
74695
74696
74697
74698
74699
74700
74701
74702
74703
74704
74705
74706
74707
74708
74709
74710
74711
74712
74713
74714
74715
74716
74717
74718
74719
74720
74721
74722
74723
74724
74725
74726
74727
74728
74729
74730
74731
74732
74733
74734
74735
74736
74737
74738
74739
74740
74741
74742
74743
74744
74745
74746
74747
74748
74749
74750
74751
74752
74753
74754
74755
74756
74757
74758
74759
74760
74761
74762
74763
74764
74765
74766
74767
74768
74769
74770
74771
74772
74773
74774
74775
74776
74777
74778
74779
74780
74781
74782
74783
74784
74785
74786
74787
74788
74789
74790
74791
74792
74793
74794
74795
74796
74797
74798
74799
74800
74801
74802
74803
74804
74805
74806
74807
74808
74809
74810
74811
74812
74813
74814
74815
74816
74817
74818
74819
74820
74821
74822
74823
74824
74825
74826
74827
74828
74829
74830
74831
74832
74833
74834
74835
74836
74837
74838
74839
74840
74841
74842
74843
74844
74845
74846
74847
74848
74849
74850
74851
74852
74853
74854
74855
74856
74857
74858
74859
74860
74861
74862
74863
74864
74865
74866
74867
74868
74869
74870
74871
74872
74873
74874
74875
74876
74877
74878
74879
74880
74881
74882
74883
74884
74885
74886
74887
74888
74889
74890
74891
74892
74893
74894
74895
74896
74897
74898
74899
74900
74901
74902
74903
74904
74905
74906
74907
74908
74909
74910
74911
74912
74913
74914
74915
74916
74917
74918
74919
74920
74921
74922
74923
74924
74925
74926
74927
74928
74929
74930
74931
74932
74933
74934
74935
74936
74937
74938
74939
74940
74941
74942
74943
74944
74945
74946
74947
74948
74949
74950
74951
74952
74953
74954
74955
74956
74957
74958
74959
74960
74961
74962
74963
74964
74965
74966
74967
74968
74969
74970
74971
74972
74973
74974
74975
74976
74977
74978
74979
74980
74981
74982
74983
74984
74985
74986
74987
74988
74989
74990
74991
74992
74993
74994
74995
74996
74997
74998
74999
75000
75001
75002
75003
75004
75005
75006
75007
75008
75009
75010
75011
75012
75013
75014
75015
75016
75017
75018
75019
75020
75021
75022
75023
75024
75025
75026
75027
75028
75029
75030
75031
75032
75033
75034
75035
75036
75037
75038
75039
75040
75041
75042
75043
75044
75045
75046
75047
75048
75049
75050
75051
75052
75053
75054
75055
75056
75057
75058
75059
75060
75061
75062
75063
75064
75065
75066
75067
75068
75069
75070
75071
75072
75073
75074
75075
75076
75077
75078
75079
75080
75081
75082
75083
75084
75085
75086
75087
75088
75089
75090
75091
75092
75093
75094
75095
75096
75097
75098
75099
75100
75101
75102
75103
75104
75105
75106
75107
75108
75109
75110
75111
75112
75113
75114
75115
75116
75117
75118
75119
75120
75121
75122
75123
75124
75125
75126
75127
75128
75129
75130
75131
75132
75133
75134
75135
75136
75137
75138
75139
75140
75141
75142
75143
75144
75145
75146
75147
75148
75149
75150
75151
75152
75153
75154
75155
75156
75157
75158
75159
75160
75161
75162
75163
75164
75165
75166
75167
75168
75169
75170
75171
75172
75173
75174
75175
75176
75177
75178
75179
75180
75181
75182
75183
75184
75185
75186
75187
75188
75189
75190
75191
75192
75193
75194
75195
75196
75197
75198
75199
75200
75201
75202
75203
75204
75205
75206
75207
75208
75209
75210
75211
75212
75213
75214
75215
75216
75217
75218
75219
75220
75221
75222
75223
75224
75225
75226
75227
75228
75229
75230
75231
75232
75233
75234
75235
75236
75237
75238
75239
75240
75241
75242
75243
75244
75245
75246
75247
75248
75249
75250
75251
75252
75253
75254
75255
75256
75257
75258
75259
75260
75261
75262
75263
75264
75265
75266
75267
75268
75269
75270
75271
75272
75273
75274
75275
75276
75277
75278
75279
75280
75281
75282
75283
75284
75285
75286
75287
75288
75289
75290
75291
75292
75293
75294
75295
75296
75297
75298
75299
75300
75301
75302
75303
75304
75305
75306
75307
75308
75309
75310
75311
75312
75313
75314
75315
75316
75317
75318
75319
75320
75321
75322
75323
75324
75325
75326
75327
75328
75329
75330
75331
75332
75333
75334
75335
75336
75337
75338
75339
75340
75341
75342
75343
75344
75345
75346
75347
75348
75349
75350
75351
75352
75353
75354
75355
75356
75357
75358
75359
75360
75361
75362
75363
75364
75365
75366
75367
75368
75369
75370
75371
75372
75373
75374
75375
75376
75377
75378
75379
75380
75381
75382
75383
75384
75385
75386
75387
75388
75389
75390
75391
75392
75393
75394
75395
75396
75397
75398
75399
75400
75401
75402
75403
75404
75405
75406
75407
75408
75409
75410
75411
75412
75413
75414
75415
75416
75417
75418
75419
75420
75421
75422
75423
75424
75425
75426
75427
75428
75429
75430
75431
75432
75433
75434
75435
75436
75437
75438
75439
75440
75441
75442
75443
75444
75445
75446
75447
75448
75449
75450
75451
75452
75453
75454
75455
75456
75457
75458
75459
75460
75461
75462
75463
75464
75465
75466
75467
75468
75469
75470
75471
75472
75473
75474
75475
75476
75477
75478
75479
75480
75481
75482
75483
75484
75485
75486
75487
75488
75489
75490
75491
75492
75493
75494
75495
75496
75497
75498
75499
75500
75501
75502
75503
75504
75505
75506
75507
75508
75509
75510
75511
75512
75513
75514
75515
75516
75517
75518
75519
75520
75521
75522
75523
75524
75525
75526
75527
75528
75529
75530
75531
75532
75533
75534
75535
75536
75537
75538
75539
75540
75541
75542
75543
75544
75545
75546
75547
75548
75549
75550
75551
75552
75553
75554
75555
75556
75557
75558
75559
75560
75561
75562
75563
75564
75565
75566
75567
75568
75569
75570
75571
75572
75573
75574
75575
75576
75577
75578
75579
75580
75581
75582
75583
75584
75585
75586
75587
75588
75589
75590
75591
75592
75593
75594
75595
75596
75597
75598
75599
75600
75601
75602
75603
75604
75605
75606
75607
75608
75609
75610
75611
75612
75613
75614
75615
75616
75617
75618
75619
75620
75621
75622
75623
75624
75625
75626
75627
75628
75629
75630
75631
75632
75633
75634
75635
75636
75637
75638
75639
75640
75641
75642
75643
75644
75645
75646
75647
75648
75649
75650
75651
75652
75653
75654
75655
75656
75657
75658
75659
75660
75661
75662
75663
75664
75665
75666
75667
75668
75669
75670
75671
75672
75673
75674
75675
75676
75677
75678
75679
75680
75681
75682
75683
75684
75685
75686
75687
75688
75689
75690
75691
75692
75693
75694
75695
75696
75697
75698
75699
75700
75701
75702
75703
75704
75705
75706
75707
75708
75709
75710
75711
75712
75713
75714
75715
75716
75717
75718
75719
75720
75721
75722
75723
75724
75725
75726
75727
75728
75729
75730
75731
75732
75733
75734
75735
75736
75737
75738
75739
75740
75741
75742
75743
75744
75745
75746
75747
75748
75749
75750
75751
75752
75753
75754
75755
75756
75757
75758
75759
75760
75761
75762
75763
75764
75765
75766
75767
75768
75769
75770
75771
75772
75773
75774
75775
75776
75777
75778
75779
75780
75781
75782
75783
75784
75785
75786
75787
75788
75789
75790
75791
75792
75793
75794
75795
75796
75797
75798
75799
75800
75801
75802
75803
75804
75805
75806
75807
75808
75809
75810
75811
75812
75813
75814
75815
75816
75817
75818
75819
75820
75821
75822
75823
75824
75825
75826
75827
75828
75829
75830
75831
75832
75833
75834
75835
75836
75837
75838
75839
75840
75841
75842
75843
75844
75845
75846
75847
75848
75849
75850
75851
75852
75853
75854
75855
75856
75857
75858
75859
75860
75861
75862
75863
75864
75865
75866
75867
75868
75869
75870
75871
75872
75873
75874
75875
75876
75877
75878
75879
75880
75881
75882
75883
75884
75885
75886
75887
75888
75889
75890
75891
75892
75893
75894
75895
75896
75897
75898
75899
75900
75901
75902
75903
75904
75905
75906
75907
75908
75909
75910
75911
75912
75913
75914
75915
75916
75917
75918
75919
75920
75921
75922
75923
75924
75925
75926
75927
75928
75929
75930
75931
75932
75933
75934
75935
75936
75937
75938
75939
75940
75941
75942
75943
75944
75945
75946
75947
75948
75949
75950
75951
75952
75953
75954
75955
75956
75957
75958
75959
75960
75961
75962
75963
75964
75965
75966
75967
75968
75969
75970
75971
75972
75973
75974
75975
75976
75977
75978
75979
75980
75981
75982
75983
75984
75985
75986
75987
75988
75989
75990
75991
75992
75993
75994
75995
75996
75997
75998
75999
76000
76001
76002
76003
76004
76005
76006
76007
76008
76009
76010
76011
76012
76013
76014
76015
76016
76017
76018
76019
76020
76021
76022
76023
76024
76025
76026
76027
76028
76029
76030
76031
76032
76033
76034
76035
76036
76037
76038
76039
76040
76041
76042
76043
76044
76045
76046
76047
76048
76049
76050
76051
76052
76053
76054
76055
76056
76057
76058
76059
76060
76061
76062
76063
76064
76065
76066
76067
76068
76069
76070
76071
76072
76073
76074
76075
76076
76077
76078
76079
76080
76081
76082
76083
76084
76085
76086
76087
76088
76089
76090
76091
76092
76093
76094
76095
76096
76097
76098
76099
76100
76101
76102
76103
76104
76105
76106
76107
76108
76109
76110
76111
76112
76113
76114
76115
76116
76117
76118
76119
76120
76121
76122
76123
76124
76125
76126
76127
76128
76129
76130
76131
76132
76133
76134
76135
76136
76137
76138
76139
76140
76141
76142
76143
76144
76145
76146
76147
76148
76149
76150
76151
76152
76153
76154
76155
76156
76157
76158
76159
76160
76161
76162
76163
76164
76165
76166
76167
76168
76169
76170
76171
76172
76173
76174
76175
76176
76177
76178
76179
76180
76181
76182
76183
76184
76185
76186
76187
76188
76189
76190
76191
76192
76193
76194
76195
76196
76197
76198
76199
76200
76201
76202
76203
76204
76205
76206
76207
76208
76209
76210
76211
76212
76213
76214
76215
76216
76217
76218
76219
76220
76221
76222
76223
76224
76225
76226
76227
76228
76229
76230
76231
76232
76233
76234
76235
76236
76237
76238
76239
76240
76241
76242
76243
76244
76245
76246
76247
76248
76249
76250
76251
76252
76253
76254
76255
76256
76257
76258
76259
76260
76261
76262
76263
76264
76265
76266
76267
76268
76269
76270
76271
76272
76273
76274
76275
76276
76277
76278
76279
76280
76281
76282
76283
76284
76285
76286
76287
76288
76289
76290
76291
76292
76293
76294
76295
76296
76297
76298
76299
76300
76301
76302
76303
76304
76305
76306
76307
76308
76309
76310
76311
76312
76313
76314
76315
76316
76317
76318
76319
76320
76321
76322
76323
76324
76325
76326
76327
76328
76329
76330
76331
76332
76333
76334
76335
76336
76337
76338
76339
76340
76341
76342
76343
76344
76345
76346
76347
76348
76349
76350
76351
76352
76353
76354
76355
76356
76357
76358
76359
76360
76361
76362
76363
76364
76365
76366
76367
76368
76369
76370
76371
76372
76373
76374
76375
76376
76377
76378
76379
76380
76381
76382
76383
76384
76385
76386
76387
76388
76389
76390
76391
76392
76393
76394
76395
76396
76397
76398
76399
76400
76401
76402
76403
76404
76405
76406
76407
76408
76409
76410
76411
76412
76413
76414
76415
76416
76417
76418
76419
76420
76421
76422
76423
76424
76425
76426
76427
76428
76429
76430
76431
76432
76433
76434
76435
76436
76437
76438
76439
76440
76441
76442
76443
76444
76445
76446
76447
76448
76449
76450
76451
76452
76453
76454
76455
76456
76457
76458
76459
76460
76461
76462
76463
76464
76465
76466
76467
76468
76469
76470
76471
76472
76473
76474
76475
76476
76477
76478
76479
76480
76481
76482
76483
76484
76485
76486
76487
76488
76489
76490
76491
76492
76493
76494
76495
76496
76497
76498
76499
76500
76501
76502
76503
76504
76505
76506
76507
76508
76509
76510
76511
76512
76513
76514
76515
76516
76517
76518
76519
76520
76521
76522
76523
76524
76525
76526
76527
76528
76529
76530
76531
76532
76533
76534
76535
76536
76537
76538
76539
76540
76541
76542
76543
76544
76545
76546
76547
76548
76549
76550
76551
76552
76553
76554
76555
76556
76557
76558
76559
76560
76561
76562
76563
76564
76565
76566
76567
76568
76569
76570
76571
76572
76573
76574
76575
76576
76577
76578
76579
76580
76581
76582
76583
76584
76585
76586
76587
76588
76589
76590
76591
76592
76593
76594
76595
76596
76597
76598
76599
76600
76601
76602
76603
76604
76605
76606
76607
76608
76609
76610
76611
76612
76613
76614
76615
76616
76617
76618
76619
76620
76621
76622
76623
76624
76625
76626
76627
76628
76629
76630
76631
76632
76633
76634
76635
76636
76637
76638
76639
76640
76641
76642
76643
76644
76645
76646
76647
76648
76649
76650
76651
76652
76653
76654
76655
76656
76657
76658
76659
76660
76661
76662
76663
76664
76665
76666
76667
76668
76669
76670
76671
76672
76673
76674
76675
76676
76677
76678
76679
76680
76681
76682
76683
76684
76685
76686
76687
76688
76689
76690
76691
76692
76693
76694
76695
76696
76697
76698
76699
76700
76701
76702
76703
76704
76705
76706
76707
76708
76709
76710
76711
76712
76713
76714
76715
76716
76717
76718
76719
76720
76721
76722
76723
76724
76725
76726
76727
76728
76729
76730
76731
76732
76733
76734
76735
76736
76737
76738
76739
76740
76741
76742
76743
76744
76745
76746
76747
76748
76749
76750
76751
76752
76753
76754
76755
76756
76757
76758
76759
76760
76761
76762
76763
76764
76765
76766
76767
76768
76769
76770
76771
76772
76773
76774
76775
76776
76777
76778
76779
76780
76781
76782
76783
76784
76785
76786
76787
76788
76789
76790
76791
76792
76793
76794
76795
76796
76797
76798
76799
76800
76801
76802
76803
76804
76805
76806
76807
76808
76809
76810
76811
76812
76813
76814
76815
76816
76817
76818
76819
76820
76821
76822
76823
76824
76825
76826
76827
76828
76829
76830
76831
76832
76833
76834
76835
76836
76837
76838
76839
76840
76841
76842
76843
76844
76845
76846
76847
76848
76849
76850
76851
76852
76853
76854
76855
76856
76857
76858
76859
76860
76861
76862
76863
76864
76865
76866
76867
76868
76869
76870
76871
76872
76873
76874
76875
76876
76877
76878
76879
76880
76881
76882
76883
76884
76885
76886
76887
76888
76889
76890
76891
76892
76893
76894
76895
76896
76897
76898
76899
76900
76901
76902
76903
76904
76905
76906
76907
76908
76909
76910
76911
76912
76913
76914
76915
76916
76917
76918
76919
76920
76921
76922
76923
76924
76925
76926
76927
76928
76929
76930
76931
76932
76933
76934
76935
76936
76937
76938
76939
76940
76941
76942
76943
76944
76945
76946
76947
76948
76949
76950
76951
76952
76953
76954
76955
76956
76957
76958
76959
76960
76961
76962
76963
76964
76965
76966
76967
76968
76969
76970
76971
76972
76973
76974
76975
76976
76977
76978
76979
76980
76981
76982
76983
76984
76985
76986
76987
76988
76989
76990
76991
76992
76993
76994
76995
76996
76997
76998
76999
77000
77001
77002
77003
77004
77005
77006
77007
77008
77009
77010
77011
77012
77013
77014
77015
77016
77017
77018
77019
77020
77021
77022
77023
77024
77025
77026
77027
77028
77029
77030
77031
77032
77033
77034
77035
77036
77037
77038
77039
77040
77041
77042
77043
77044
77045
77046
77047
77048
77049
77050
77051
77052
77053
77054
77055
77056
77057
77058
77059
77060
77061
77062
77063
77064
77065
77066
77067
77068
77069
77070
77071
77072
77073
77074
77075
77076
77077
77078
77079
77080
77081
77082
77083
77084
77085
77086
77087
77088
77089
77090
77091
77092
77093
77094
77095
77096
77097
77098
77099
77100
77101
77102
77103
77104
77105
77106
77107
77108
77109
77110
77111
77112
77113
77114
77115
77116
77117
77118
77119
77120
77121
77122
77123
77124
77125
77126
77127
77128
77129
77130
77131
77132
77133
77134
77135
77136
77137
77138
77139
77140
77141
77142
77143
77144
77145
77146
77147
77148
77149
77150
77151
77152
77153
77154
77155
77156
77157
77158
77159
77160
77161
77162
77163
77164
77165
77166
77167
77168
77169
77170
77171
77172
77173
77174
77175
77176
77177
77178
77179
77180
77181
77182
77183
77184
77185
77186
77187
77188
77189
77190
77191
77192
77193
77194
77195
77196
77197
77198
77199
77200
77201
77202
77203
77204
77205
77206
77207
77208
77209
77210
77211
77212
77213
77214
77215
77216
77217
77218
77219
77220
77221
77222
77223
77224
77225
77226
77227
77228
77229
77230
77231
77232
77233
77234
77235
77236
77237
77238
77239
77240
77241
77242
77243
77244
77245
77246
77247
77248
77249
77250
77251
77252
77253
77254
77255
77256
77257
77258
77259
77260
77261
77262
77263
77264
77265
77266
77267
77268
77269
77270
77271
77272
77273
77274
77275
77276
77277
77278
77279
77280
77281
77282
77283
77284
77285
77286
77287
77288
77289
77290
77291
77292
77293
77294
77295
77296
77297
77298
77299
77300
77301
77302
77303
77304
77305
77306
77307
77308
77309
77310
77311
77312
77313
77314
77315
77316
77317
77318
77319
77320
77321
77322
77323
77324
77325
77326
77327
77328
77329
77330
77331
77332
77333
77334
77335
77336
77337
77338
77339
77340
77341
77342
77343
77344
77345
77346
77347
77348
77349
77350
77351
77352
77353
77354
77355
77356
77357
77358
77359
77360
77361
77362
77363
77364
77365
77366
77367
77368
77369
77370
77371
77372
77373
77374
77375
77376
77377
77378
77379
77380
77381
77382
77383
77384
77385
77386
77387
77388
77389
77390
77391
77392
77393
77394
77395
77396
77397
77398
77399
77400
77401
77402
77403
77404
77405
77406
77407
77408
77409
77410
77411
77412
77413
77414
77415
77416
77417
77418
77419
77420
77421
77422
77423
77424
77425
77426
77427
77428
77429
77430
77431
77432
77433
77434
77435
77436
77437
77438
77439
77440
77441
77442
77443
77444
77445
77446
77447
77448
77449
77450
77451
77452
77453
77454
77455
77456
77457
77458
77459
77460
77461
77462
77463
77464
77465
77466
77467
77468
77469
77470
77471
77472
77473
77474
77475
77476
77477
77478
77479
77480
77481
77482
77483
77484
77485
77486
77487
77488
77489
77490
77491
77492
77493
77494
77495
77496
77497
77498
77499
77500
77501
77502
77503
77504
77505
77506
77507
77508
77509
77510
77511
77512
77513
77514
77515
77516
77517
77518
77519
77520
77521
77522
77523
77524
77525
77526
77527
77528
77529
77530
77531
77532
77533
77534
77535
77536
77537
77538
77539
77540
77541
77542
77543
77544
77545
77546
77547
77548
77549
77550
77551
77552
77553
77554
77555
77556
77557
77558
77559
77560
77561
77562
77563
77564
77565
77566
77567
77568
77569
77570
77571
77572
77573
77574
77575
77576
77577
77578
77579
77580
77581
77582
77583
77584
77585
77586
77587
77588
77589
77590
77591
77592
77593
77594
77595
77596
77597
77598
77599
77600
77601
77602
77603
77604
77605
77606
77607
77608
77609
77610
77611
77612
77613
77614
77615
77616
77617
77618
77619
77620
77621
77622
77623
77624
77625
77626
77627
77628
77629
77630
77631
77632
77633
77634
77635
77636
77637
77638
77639
77640
77641
77642
77643
77644
77645
77646
77647
77648
77649
77650
77651
77652
77653
77654
77655
77656
77657
77658
77659
77660
77661
77662
77663
77664
77665
77666
77667
77668
77669
77670
77671
77672
77673
77674
77675
77676
77677
77678
77679
77680
77681
77682
77683
77684
77685
77686
77687
77688
77689
77690
77691
77692
77693
77694
77695
77696
77697
77698
77699
77700
77701
77702
77703
77704
77705
77706
77707
77708
77709
77710
77711
77712
77713
77714
77715
77716
77717
77718
77719
77720
77721
77722
77723
77724
77725
77726
77727
77728
77729
77730
77731
77732
77733
77734
77735
77736
77737
77738
77739
77740
77741
77742
77743
77744
77745
77746
77747
77748
77749
77750
77751
77752
77753
77754
77755
77756
77757
77758
77759
77760
77761
77762
77763
77764
77765
77766
77767
77768
77769
77770
77771
77772
77773
77774
77775
77776
77777
77778
77779
77780
77781
77782
77783
77784
77785
77786
77787
77788
77789
77790
77791
77792
77793
77794
77795
77796
77797
77798
77799
77800
77801
77802
77803
77804
77805
77806
77807
77808
77809
77810
77811
77812
77813
77814
77815
77816
77817
77818
77819
77820
77821
77822
77823
77824
77825
77826
77827
77828
77829
77830
77831
77832
77833
77834
77835
77836
77837
77838
77839
77840
77841
77842
77843
77844
77845
77846
77847
77848
77849
77850
77851
77852
77853
77854
77855
77856
77857
77858
77859
77860
77861
77862
77863
77864
77865
77866
77867
77868
77869
77870
77871
77872
77873
77874
77875
77876
77877
77878
77879
77880
77881
77882
77883
77884
77885
77886
77887
77888
77889
77890
77891
77892
77893
77894
77895
77896
77897
77898
77899
77900
77901
77902
77903
77904
77905
77906
77907
77908
77909
77910
77911
77912
77913
77914
77915
77916
77917
77918
77919
77920
77921
77922
77923
77924
77925
77926
77927
77928
77929
77930
77931
77932
77933
77934
77935
77936
77937
77938
77939
77940
77941
77942
77943
77944
77945
77946
77947
77948
77949
77950
77951
77952
77953
77954
77955
77956
77957
77958
77959
77960
77961
77962
77963
77964
77965
77966
77967
77968
77969
77970
77971
77972
77973
77974
77975
77976
77977
77978
77979
77980
77981
77982
77983
77984
77985
77986
77987
77988
77989
77990
77991
77992
77993
77994
77995
77996
77997
77998
77999
78000
78001
78002
78003
78004
78005
78006
78007
78008
78009
78010
78011
78012
78013
78014
78015
78016
78017
78018
78019
78020
78021
78022
78023
78024
78025
78026
78027
78028
78029
78030
78031
78032
78033
78034
78035
78036
78037
78038
78039
78040
78041
78042
78043
78044
78045
78046
78047
78048
78049
78050
78051
78052
78053
78054
78055
78056
78057
78058
78059
78060
78061
78062
78063
78064
78065
78066
78067
78068
78069
78070
78071
78072
78073
78074
78075
78076
78077
78078
78079
78080
78081
78082
78083
78084
78085
78086
78087
78088
78089
78090
78091
78092
78093
78094
78095
78096
78097
78098
78099
78100
78101
78102
78103
78104
78105
78106
78107
78108
78109
78110
78111
78112
78113
78114
78115
78116
78117
78118
78119
78120
78121
78122
78123
78124
78125
78126
78127
78128
78129
78130
78131
78132
78133
78134
78135
78136
78137
78138
78139
78140
78141
78142
78143
78144
78145
78146
78147
78148
78149
78150
78151
78152
78153
78154
78155
78156
78157
78158
78159
78160
78161
78162
78163
78164
78165
78166
78167
78168
78169
78170
78171
78172
78173
78174
78175
78176
78177
78178
78179
78180
78181
78182
78183
78184
78185
78186
78187
78188
78189
78190
78191
78192
78193
78194
78195
78196
78197
78198
78199
78200
78201
78202
78203
78204
78205
78206
78207
78208
78209
78210
78211
78212
78213
78214
78215
78216
78217
78218
78219
78220
78221
78222
78223
78224
78225
78226
78227
78228
78229
78230
78231
78232
78233
78234
78235
78236
78237
78238
78239
78240
78241
78242
78243
78244
78245
78246
78247
78248
78249
78250
78251
78252
78253
78254
78255
78256
78257
78258
78259
78260
78261
78262
78263
78264
78265
78266
78267
78268
78269
78270
78271
78272
78273
78274
78275
78276
78277
78278
78279
78280
78281
78282
78283
78284
78285
78286
78287
78288
78289
78290
78291
78292
78293
78294
78295
78296
78297
78298
78299
78300
78301
78302
78303
78304
78305
78306
78307
78308
78309
78310
78311
78312
78313
78314
78315
78316
78317
78318
78319
78320
78321
78322
78323
78324
78325
78326
78327
78328
78329
78330
78331
78332
78333
78334
78335
78336
78337
78338
78339
78340
78341
78342
78343
78344
78345
78346
78347
78348
78349
78350
78351
78352
78353
78354
78355
78356
78357
78358
78359
78360
78361
78362
78363
78364
78365
78366
78367
78368
78369
78370
78371
78372
78373
78374
78375
78376
78377
78378
78379
78380
78381
78382
78383
78384
78385
78386
78387
78388
78389
78390
78391
78392
78393
78394
78395
78396
78397
78398
78399
78400
78401
78402
78403
78404
78405
78406
78407
78408
78409
78410
78411
78412
78413
78414
78415
78416
78417
78418
78419
78420
78421
78422
78423
78424
78425
78426
78427
78428
78429
78430
78431
78432
78433
78434
78435
78436
78437
78438
78439
78440
78441
78442
78443
78444
78445
78446
78447
78448
78449
78450
78451
78452
78453
78454
78455
78456
78457
78458
78459
78460
78461
78462
78463
78464
78465
78466
78467
78468
78469
78470
78471
78472
78473
78474
78475
78476
78477
78478
78479
78480
78481
78482
78483
78484
78485
78486
78487
78488
78489
78490
78491
78492
78493
78494
78495
78496
78497
78498
78499
78500
78501
78502
78503
78504
78505
78506
78507
78508
78509
78510
78511
78512
78513
78514
78515
78516
78517
78518
78519
78520
78521
78522
78523
78524
78525
78526
78527
78528
78529
78530
78531
78532
78533
78534
78535
78536
78537
78538
78539
78540
78541
78542
78543
78544
78545
78546
78547
78548
78549
78550
78551
78552
78553
78554
78555
78556
78557
78558
78559
78560
78561
78562
78563
78564
78565
78566
78567
78568
78569
78570
78571
78572
78573
78574
78575
78576
78577
78578
78579
78580
78581
78582
78583
78584
78585
78586
78587
78588
78589
78590
78591
78592
78593
78594
78595
78596
78597
78598
78599
78600
78601
78602
78603
78604
78605
78606
78607
78608
78609
78610
78611
78612
78613
78614
78615
78616
78617
78618
78619
78620
78621
78622
78623
78624
78625
78626
78627
78628
78629
78630
78631
78632
78633
78634
78635
78636
78637
78638
78639
78640
78641
78642
78643
78644
78645
78646
78647
78648
78649
78650
78651
78652
78653
78654
78655
78656
78657
78658
78659
78660
78661
78662
78663
78664
78665
78666
78667
78668
78669
78670
78671
78672
78673
78674
78675
78676
78677
78678
78679
78680
78681
78682
78683
78684
78685
78686
78687
78688
78689
78690
78691
78692
78693
78694
78695
78696
78697
78698
78699
78700
78701
78702
78703
78704
78705
78706
78707
78708
78709
78710
78711
78712
78713
78714
78715
78716
78717
78718
78719
78720
78721
78722
78723
78724
78725
78726
78727
78728
78729
78730
78731
78732
78733
78734
78735
78736
78737
78738
78739
78740
78741
78742
78743
78744
78745
78746
78747
78748
78749
78750
78751
78752
78753
78754
78755
78756
78757
78758
78759
78760
78761
78762
78763
78764
78765
78766
78767
78768
78769
78770
78771
78772
78773
78774
78775
78776
78777
78778
78779
78780
78781
78782
78783
78784
78785
78786
78787
78788
78789
78790
78791
78792
78793
78794
78795
78796
78797
78798
78799
78800
78801
78802
78803
78804
78805
78806
78807
78808
78809
78810
78811
78812
78813
78814
78815
78816
78817
78818
78819
78820
78821
78822
78823
78824
78825
78826
78827
78828
78829
78830
78831
78832
78833
78834
78835
78836
78837
78838
78839
78840
78841
78842
78843
78844
78845
78846
78847
78848
78849
78850
78851
78852
78853
78854
78855
78856
78857
78858
78859
78860
78861
78862
78863
78864
78865
78866
78867
78868
78869
78870
78871
78872
78873
78874
78875
78876
78877
78878
78879
78880
78881
78882
78883
78884
78885
78886
78887
78888
78889
78890
78891
78892
78893
78894
78895
78896
78897
78898
78899
78900
78901
78902
78903
78904
78905
78906
78907
78908
78909
78910
78911
78912
78913
78914
78915
78916
78917
78918
78919
78920
78921
78922
78923
78924
78925
78926
78927
78928
78929
78930
78931
78932
78933
78934
78935
78936
78937
78938
78939
78940
78941
78942
78943
78944
78945
78946
78947
78948
78949
78950
78951
78952
78953
78954
78955
78956
78957
78958
78959
78960
78961
78962
78963
78964
78965
78966
78967
78968
78969
78970
78971
78972
78973
78974
78975
78976
78977
78978
78979
78980
78981
78982
78983
78984
78985
78986
78987
78988
78989
78990
78991
78992
78993
78994
78995
78996
78997
78998
78999
79000
79001
79002
79003
79004
79005
79006
79007
79008
79009
79010
79011
79012
79013
79014
79015
79016
79017
79018
79019
79020
79021
79022
79023
79024
79025
79026
79027
79028
79029
79030
79031
79032
79033
79034
79035
79036
79037
79038
79039
79040
79041
79042
79043
79044
79045
79046
79047
79048
79049
79050
79051
79052
79053
79054
79055
79056
79057
79058
79059
79060
79061
79062
79063
79064
79065
79066
79067
79068
79069
79070
79071
79072
79073
79074
79075
79076
79077
79078
79079
79080
79081
79082
79083
79084
79085
79086
79087
79088
79089
79090
79091
79092
79093
79094
79095
79096
79097
79098
79099
79100
79101
79102
79103
79104
79105
79106
79107
79108
79109
79110
79111
79112
79113
79114
79115
79116
79117
79118
79119
79120
79121
79122
79123
79124
79125
79126
79127
79128
79129
79130
79131
79132
79133
79134
79135
79136
79137
79138
79139
79140
79141
79142
79143
79144
79145
79146
79147
79148
79149
79150
79151
79152
79153
79154
79155
79156
79157
79158
79159
79160
79161
79162
79163
79164
79165
79166
79167
79168
79169
79170
79171
79172
79173
79174
79175
79176
79177
79178
79179
79180
79181
79182
79183
79184
79185
79186
79187
79188
79189
79190
79191
79192
79193
79194
79195
79196
79197
79198
79199
79200
79201
79202
79203
79204
79205
79206
79207
79208
79209
79210
79211
79212
79213
79214
79215
79216
79217
79218
79219
79220
79221
79222
79223
79224
79225
79226
79227
79228
79229
79230
79231
79232
79233
79234
79235
79236
79237
79238
79239
79240
79241
79242
79243
79244
79245
79246
79247
79248
79249
79250
79251
79252
79253
79254
79255
79256
79257
79258
79259
79260
79261
79262
79263
79264
79265
79266
79267
79268
79269
79270
79271
79272
79273
79274
79275
79276
79277
79278
79279
79280
79281
79282
79283
79284
79285
79286
79287
79288
79289
79290
79291
79292
79293
79294
79295
79296
79297
79298
79299
79300
79301
79302
79303
79304
79305
79306
79307
79308
79309
79310
79311
79312
79313
79314
79315
79316
79317
79318
79319
79320
79321
79322
79323
79324
79325
79326
79327
79328
79329
79330
79331
79332
79333
79334
79335
79336
79337
79338
79339
79340
79341
79342
79343
79344
79345
79346
79347
79348
79349
79350
79351
79352
79353
79354
79355
79356
79357
79358
79359
79360
79361
79362
79363
79364
79365
79366
79367
79368
79369
79370
79371
79372
79373
79374
79375
79376
79377
79378
79379
79380
79381
79382
79383
79384
79385
79386
79387
79388
79389
79390
79391
79392
79393
79394
79395
79396
79397
79398
79399
79400
79401
79402
79403
79404
79405
79406
79407
79408
79409
79410
79411
79412
79413
79414
79415
79416
79417
79418
79419
79420
79421
79422
79423
79424
79425
79426
79427
79428
79429
79430
79431
79432
79433
79434
79435
79436
79437
79438
79439
79440
79441
79442
79443
79444
79445
79446
79447
79448
79449
79450
79451
79452
79453
79454
79455
79456
79457
79458
79459
79460
79461
79462
79463
79464
79465
79466
79467
79468
79469
79470
79471
79472
79473
79474
79475
79476
79477
79478
79479
79480
79481
79482
79483
79484
79485
79486
79487
79488
79489
79490
79491
79492
79493
79494
79495
79496
79497
79498
79499
79500
79501
79502
79503
79504
79505
79506
79507
79508
79509
79510
79511
79512
79513
79514
79515
79516
79517
79518
79519
79520
79521
79522
79523
79524
79525
79526
79527
79528
79529
79530
79531
79532
79533
79534
79535
79536
79537
79538
79539
79540
79541
79542
79543
79544
79545
79546
79547
79548
79549
79550
79551
79552
79553
79554
79555
79556
79557
79558
79559
79560
79561
79562
79563
79564
79565
79566
79567
79568
79569
79570
79571
79572
79573
79574
79575
79576
79577
79578
79579
79580
79581
79582
79583
79584
79585
79586
79587
79588
79589
79590
79591
79592
79593
79594
79595
79596
79597
79598
79599
79600
79601
79602
79603
79604
79605
79606
79607
79608
79609
79610
79611
79612
79613
79614
79615
79616
79617
79618
79619
79620
79621
79622
79623
79624
79625
79626
79627
79628
79629
79630
79631
79632
79633
79634
79635
79636
79637
79638
79639
79640
79641
79642
79643
79644
79645
79646
79647
79648
79649
79650
79651
79652
79653
79654
79655
79656
79657
79658
79659
79660
79661
79662
79663
79664
79665
79666
79667
79668
79669
79670
79671
79672
79673
79674
79675
79676
79677
79678
79679
79680
79681
79682
79683
79684
79685
79686
79687
79688
79689
79690
79691
79692
79693
79694
79695
79696
79697
79698
79699
79700
79701
79702
79703
79704
79705
79706
79707
79708
79709
79710
79711
79712
79713
79714
79715
79716
79717
79718
79719
79720
79721
79722
79723
79724
79725
79726
79727
79728
79729
79730
79731
79732
79733
79734
79735
79736
79737
79738
79739
79740
79741
79742
79743
79744
79745
79746
79747
79748
79749
79750
79751
79752
79753
79754
79755
79756
79757
79758
79759
79760
79761
79762
79763
79764
79765
79766
79767
79768
79769
79770
79771
79772
79773
79774
79775
79776
79777
79778
79779
79780
79781
79782
79783
79784
79785
79786
79787
79788
79789
79790
79791
79792
79793
79794
79795
79796
79797
79798
79799
79800
79801
79802
79803
79804
79805
79806
79807
79808
79809
79810
79811
79812
79813
79814
79815
79816
79817
79818
79819
79820
79821
79822
79823
79824
79825
79826
79827
79828
79829
79830
79831
79832
79833
79834
79835
79836
79837
79838
79839
79840
79841
79842
79843
79844
79845
79846
79847
79848
79849
79850
79851
79852
79853
79854
79855
79856
79857
79858
79859
79860
79861
79862
79863
79864
79865
79866
79867
79868
79869
79870
79871
79872
79873
79874
79875
79876
79877
79878
79879
79880
79881
79882
79883
79884
79885
79886
79887
79888
79889
79890
79891
79892
79893
79894
79895
79896
79897
79898
79899
79900
79901
79902
79903
79904
79905
79906
79907
79908
79909
79910
79911
79912
79913
79914
79915
79916
79917
79918
79919
79920
79921
79922
79923
79924
79925
79926
79927
79928
79929
79930
79931
79932
79933
79934
79935
79936
79937
79938
79939
79940
79941
79942
79943
79944
79945
79946
79947
79948
79949
79950
79951
79952
79953
79954
79955
79956
79957
79958
79959
79960
79961
79962
79963
79964
79965
79966
79967
79968
79969
79970
79971
79972
79973
79974
79975
79976
79977
79978
79979
79980
79981
79982
79983
79984
79985
79986
79987
79988
79989
79990
79991
79992
79993
79994
79995
79996
79997
79998
79999
80000
80001
80002
80003
80004
80005
80006
80007
80008
80009
80010
80011
80012
80013
80014
80015
80016
80017
80018
80019
80020
80021
80022
80023
80024
80025
80026
80027
80028
80029
80030
80031
80032
80033
80034
80035
80036
80037
80038
80039
80040
80041
80042
80043
80044
80045
80046
80047
80048
80049
80050
80051
80052
80053
80054
80055
80056
80057
80058
80059
80060
80061
80062
80063
80064
80065
80066
80067
80068
80069
80070
80071
80072
80073
80074
80075
80076
80077
80078
80079
80080
80081
80082
80083
80084
80085
80086
80087
80088
80089
80090
80091
80092
80093
80094
80095
80096
80097
80098
80099
80100
80101
80102
80103
80104
80105
80106
80107
80108
80109
80110
80111
80112
80113
80114
80115
80116
80117
80118
80119
80120
80121
80122
80123
80124
80125
80126
80127
80128
80129
80130
80131
80132
80133
80134
80135
80136
80137
80138
80139
80140
80141
80142
80143
80144
80145
80146
80147
80148
80149
80150
80151
80152
80153
80154
80155
80156
80157
80158
80159
80160
80161
80162
80163
80164
80165
80166
80167
80168
80169
80170
80171
80172
80173
80174
80175
80176
80177
80178
80179
80180
80181
80182
80183
80184
80185
80186
80187
80188
80189
80190
80191
80192
80193
80194
80195
80196
80197
80198
80199
80200
80201
80202
80203
80204
80205
80206
80207
80208
80209
80210
80211
80212
80213
80214
80215
80216
80217
80218
80219
80220
80221
80222
80223
80224
80225
80226
80227
80228
80229
80230
80231
80232
80233
80234
80235
80236
80237
80238
80239
80240
80241
80242
80243
80244
80245
80246
80247
80248
80249
80250
80251
80252
80253
80254
80255
80256
80257
80258
80259
80260
80261
80262
80263
80264
80265
80266
80267
80268
80269
80270
80271
80272
80273
80274
80275
80276
80277
80278
80279
80280
80281
80282
80283
80284
80285
80286
80287
80288
80289
80290
80291
80292
80293
80294
80295
80296
80297
80298
80299
80300
80301
80302
80303
80304
80305
80306
80307
80308
80309
80310
80311
80312
80313
80314
80315
80316
80317
80318
80319
80320
80321
80322
80323
80324
80325
80326
80327
80328
80329
80330
80331
80332
80333
80334
80335
80336
80337
80338
80339
80340
80341
80342
80343
80344
80345
80346
80347
80348
80349
80350
80351
80352
80353
80354
80355
80356
80357
80358
80359
80360
80361
80362
80363
80364
80365
80366
80367
80368
80369
80370
80371
80372
80373
80374
80375
80376
80377
80378
80379
80380
80381
80382
80383
80384
80385
80386
80387
80388
80389
80390
80391
80392
80393
80394
80395
80396
80397
80398
80399
80400
80401
80402
80403
80404
80405
80406
80407
80408
80409
80410
80411
80412
80413
80414
80415
80416
80417
80418
80419
80420
80421
80422
80423
80424
80425
80426
80427
80428
80429
80430
80431
80432
80433
80434
80435
80436
80437
80438
80439
80440
80441
80442
80443
80444
80445
80446
80447
80448
80449
80450
80451
80452
80453
80454
80455
80456
80457
80458
80459
80460
80461
80462
80463
80464
80465
80466
80467
80468
80469
80470
80471
80472
80473
80474
80475
80476
80477
80478
80479
80480
80481
80482
80483
80484
80485
80486
80487
80488
80489
80490
80491
80492
80493
80494
80495
80496
80497
80498
80499
80500
80501
80502
80503
80504
80505
80506
80507
80508
80509
80510
80511
80512
80513
80514
80515
80516
80517
80518
80519
80520
80521
80522
80523
80524
80525
80526
80527
80528
80529
80530
80531
80532
80533
80534
80535
80536
80537
80538
80539
80540
80541
80542
80543
80544
80545
80546
80547
80548
80549
80550
80551
80552
80553
80554
80555
80556
80557
80558
80559
80560
80561
80562
80563
80564
80565
80566
80567
80568
80569
80570
80571
80572
80573
80574
80575
80576
80577
80578
80579
80580
80581
80582
80583
80584
80585
80586
80587
80588
80589
80590
80591
80592
80593
80594
80595
80596
80597
80598
80599
80600
80601
80602
80603
80604
80605
80606
80607
80608
80609
80610
80611
80612
80613
80614
80615
80616
80617
80618
80619
80620
80621
80622
80623
80624
80625
80626
80627
80628
80629
80630
80631
80632
80633
80634
80635
80636
80637
80638
80639
80640
80641
80642
80643
80644
80645
80646
80647
80648
80649
80650
80651
80652
80653
80654
80655
80656
80657
80658
80659
80660
80661
80662
80663
80664
80665
80666
80667
80668
80669
80670
80671
80672
80673
80674
80675
80676
80677
80678
80679
80680
80681
80682
80683
80684
80685
80686
80687
80688
80689
80690
80691
80692
80693
80694
80695
80696
80697
80698
80699
80700
80701
80702
80703
80704
80705
80706
80707
80708
80709
80710
80711
80712
80713
80714
80715
80716
80717
80718
80719
80720
80721
80722
80723
80724
80725
80726
80727
80728
80729
80730
80731
80732
80733
80734
80735
80736
80737
80738
80739
80740
80741
80742
80743
80744
80745
80746
80747
80748
80749
80750
80751
80752
80753
80754
80755
80756
80757
80758
80759
80760
80761
80762
80763
80764
80765
80766
80767
80768
80769
80770
80771
80772
80773
80774
80775
80776
80777
80778
80779
80780
80781
80782
80783
80784
80785
80786
80787
80788
80789
80790
80791
80792
80793
80794
80795
80796
80797
80798
80799
80800
80801
80802
80803
80804
80805
80806
80807
80808
80809
80810
80811
80812
80813
80814
80815
80816
80817
80818
80819
80820
80821
80822
80823
80824
80825
80826
80827
80828
80829
80830
80831
80832
80833
80834
80835
80836
80837
80838
80839
80840
80841
80842
80843
80844
80845
80846
80847
80848
80849
80850
80851
80852
80853
80854
80855
80856
80857
80858
80859
80860
80861
80862
80863
80864
80865
80866
80867
80868
80869
80870
80871
80872
80873
80874
80875
80876
80877
80878
80879
80880
80881
80882
80883
80884
80885
80886
80887
80888
80889
80890
80891
80892
80893
80894
80895
80896
80897
80898
80899
80900
80901
80902
80903
80904
80905
80906
80907
80908
80909
80910
80911
80912
80913
80914
80915
80916
80917
80918
80919
80920
80921
80922
80923
80924
80925
80926
80927
80928
80929
80930
80931
80932
80933
80934
80935
80936
80937
80938
80939
80940
80941
80942
80943
80944
80945
80946
80947
80948
80949
80950
80951
80952
80953
80954
80955
80956
80957
80958
80959
80960
80961
80962
80963
80964
80965
80966
80967
80968
80969
80970
80971
80972
80973
80974
80975
80976
80977
80978
80979
80980
80981
80982
80983
80984
80985
80986
80987
80988
80989
80990
80991
80992
80993
80994
80995
80996
80997
80998
80999
81000
81001
81002
81003
81004
81005
81006
81007
81008
81009
81010
81011
81012
81013
81014
81015
81016
81017
81018
81019
81020
81021
81022
81023
81024
81025
81026
81027
81028
81029
81030
81031
81032
81033
81034
81035
81036
81037
81038
81039
81040
81041
81042
81043
81044
81045
81046
81047
81048
81049
81050
81051
81052
81053
81054
81055
81056
81057
81058
81059
81060
81061
81062
81063
81064
81065
81066
81067
81068
81069
81070
81071
81072
81073
81074
81075
81076
81077
81078
81079
81080
81081
81082
81083
81084
81085
81086
81087
81088
81089
81090
81091
81092
81093
81094
81095
81096
81097
81098
81099
81100
81101
81102
81103
81104
81105
81106
81107
81108
81109
81110
81111
81112
81113
81114
81115
81116
81117
81118
81119
81120
81121
81122
81123
81124
81125
81126
81127
81128
81129
81130
81131
81132
81133
81134
81135
81136
81137
81138
81139
81140
81141
81142
81143
81144
81145
81146
81147
81148
81149
81150
81151
81152
81153
81154
81155
81156
81157
81158
81159
81160
81161
81162
81163
81164
81165
81166
81167
81168
81169
81170
81171
81172
81173
81174
81175
81176
81177
81178
81179
81180
81181
81182
81183
81184
81185
81186
81187
81188
81189
81190
81191
81192
81193
81194
81195
81196
81197
81198
81199
81200
81201
81202
81203
81204
81205
81206
81207
81208
81209
81210
81211
81212
81213
81214
81215
81216
81217
81218
81219
81220
81221
81222
81223
81224
81225
81226
81227
81228
81229
81230
81231
81232
81233
81234
81235
81236
81237
81238
81239
81240
81241
81242
81243
81244
81245
81246
81247
81248
81249
81250
81251
81252
81253
81254
81255
81256
81257
81258
81259
81260
81261
81262
81263
81264
81265
81266
81267
81268
81269
81270
81271
81272
81273
81274
81275
81276
81277
81278
81279
81280
81281
81282
81283
81284
81285
81286
81287
81288
81289
81290
81291
81292
81293
81294
81295
81296
81297
81298
81299
81300
81301
81302
81303
81304
81305
81306
81307
81308
81309
81310
81311
81312
81313
81314
81315
81316
81317
81318
81319
81320
81321
81322
81323
81324
81325
81326
81327
81328
81329
81330
81331
81332
81333
81334
81335
81336
81337
81338
81339
81340
81341
81342
81343
81344
81345
81346
81347
81348
81349
81350
81351
81352
81353
81354
81355
81356
81357
81358
81359
81360
81361
81362
81363
81364
81365
81366
81367
81368
81369
81370
81371
81372
81373
81374
81375
81376
81377
81378
81379
81380
81381
81382
81383
81384
81385
81386
81387
81388
81389
81390
81391
81392
81393
81394
81395
81396
81397
81398
81399
81400
81401
81402
81403
81404
81405
81406
81407
81408
81409
81410
81411
81412
81413
81414
81415
81416
81417
81418
81419
81420
81421
81422
81423
81424
81425
81426
81427
81428
81429
81430
81431
81432
81433
81434
81435
81436
81437
81438
81439
81440
81441
81442
81443
81444
81445
81446
81447
81448
81449
81450
81451
81452
81453
81454
81455
81456
81457
81458
81459
81460
81461
81462
81463
81464
81465
81466
81467
81468
81469
81470
81471
81472
81473
81474
81475
81476
81477
81478
81479
81480
81481
81482
81483
81484
81485
81486
81487
81488
81489
81490
81491
81492
81493
81494
81495
81496
81497
81498
81499
81500
81501
81502
81503
81504
81505
81506
81507
81508
81509
81510
81511
81512
81513
81514
81515
81516
81517
81518
81519
81520
81521
81522
81523
81524
81525
81526
81527
81528
81529
81530
81531
81532
81533
81534
81535
81536
81537
81538
81539
81540
81541
81542
81543
81544
81545
81546
81547
81548
81549
81550
81551
81552
81553
81554
81555
81556
81557
81558
81559
81560
81561
81562
81563
81564
81565
81566
81567
81568
81569
81570
81571
81572
81573
81574
81575
81576
81577
81578
81579
81580
81581
81582
81583
81584
81585
81586
81587
81588
81589
81590
81591
81592
81593
81594
81595
81596
81597
81598
81599
81600
81601
81602
81603
81604
81605
81606
81607
81608
81609
81610
81611
81612
81613
81614
81615
81616
81617
81618
81619
81620
81621
81622
81623
81624
81625
81626
81627
81628
81629
81630
81631
81632
81633
81634
81635
81636
81637
81638
81639
81640
81641
81642
81643
81644
81645
81646
81647
81648
81649
81650
81651
81652
81653
81654
81655
81656
81657
81658
81659
81660
81661
81662
81663
81664
81665
81666
81667
81668
81669
81670
81671
81672
81673
81674
81675
81676
81677
81678
81679
81680
81681
81682
81683
81684
81685
81686
81687
81688
81689
81690
81691
81692
81693
81694
81695
81696
81697
81698
81699
81700
81701
81702
81703
81704
81705
81706
81707
81708
81709
81710
81711
81712
81713
81714
81715
81716
81717
81718
81719
81720
81721
81722
81723
81724
81725
81726
81727
81728
81729
81730
81731
81732
81733
81734
81735
81736
81737
81738
81739
81740
81741
81742
81743
81744
81745
81746
81747
81748
81749
81750
81751
81752
81753
81754
81755
81756
81757
81758
81759
81760
81761
81762
81763
81764
81765
81766
81767
81768
81769
81770
81771
81772
81773
81774
81775
81776
81777
81778
81779
81780
81781
81782
81783
81784
81785
81786
81787
81788
81789
81790
81791
81792
81793
81794
81795
81796
81797
81798
81799
81800
81801
81802
81803
81804
81805
81806
81807
81808
81809
81810
81811
81812
81813
81814
81815
81816
81817
81818
81819
81820
81821
81822
81823
81824
81825
81826
81827
81828
81829
81830
81831
81832
81833
81834
81835
81836
81837
81838
81839
81840
81841
81842
81843
81844
81845
81846
81847
81848
81849
81850
81851
81852
81853
81854
81855
81856
81857
81858
81859
81860
81861
81862
81863
81864
81865
81866
81867
81868
81869
81870
81871
81872
81873
81874
81875
81876
81877
81878
81879
81880
81881
81882
81883
81884
81885
81886
81887
81888
81889
81890
81891
81892
81893
81894
81895
81896
81897
81898
81899
81900
81901
81902
81903
81904
81905
81906
81907
81908
81909
81910
81911
81912
81913
81914
81915
81916
81917
81918
81919
81920
81921
81922
81923
81924
81925
81926
81927
81928
81929
81930
81931
81932
81933
81934
81935
81936
81937
81938
81939
81940
81941
81942
81943
81944
81945
81946
81947
81948
81949
81950
81951
81952
81953
81954
81955
81956
81957
81958
81959
81960
81961
81962
81963
81964
81965
81966
81967
81968
81969
81970
81971
81972
81973
81974
81975
81976
81977
81978
81979
81980
81981
81982
81983
81984
81985
81986
81987
81988
81989
81990
81991
81992
81993
81994
81995
81996
81997
81998
81999
82000
82001
82002
82003
82004
82005
82006
82007
82008
82009
82010
82011
82012
82013
82014
82015
82016
82017
82018
82019
82020
82021
82022
82023
82024
82025
82026
82027
82028
82029
82030
82031
82032
82033
82034
82035
82036
82037
82038
82039
82040
82041
82042
82043
82044
82045
82046
82047
82048
82049
82050
82051
82052
82053
82054
82055
82056
82057
82058
82059
82060
82061
82062
82063
82064
82065
82066
82067
82068
82069
82070
82071
82072
82073
82074
82075
82076
82077
82078
82079
82080
82081
82082
82083
82084
82085
82086
82087
82088
82089
82090
82091
82092
82093
82094
82095
82096
82097
82098
82099
82100
82101
82102
82103
82104
82105
82106
82107
82108
82109
82110
82111
82112
82113
82114
82115
82116
82117
82118
82119
82120
82121
82122
82123
82124
82125
82126
82127
82128
82129
82130
82131
82132
82133
82134
82135
82136
82137
82138
82139
82140
82141
82142
82143
82144
82145
82146
82147
82148
82149
82150
82151
82152
82153
82154
82155
82156
82157
82158
82159
82160
82161
82162
82163
82164
82165
82166
82167
82168
82169
82170
82171
82172
82173
82174
82175
82176
82177
82178
82179
82180
82181
82182
82183
82184
82185
82186
82187
82188
82189
82190
82191
82192
82193
82194
82195
82196
82197
82198
82199
82200
82201
82202
82203
82204
82205
82206
82207
82208
82209
82210
82211
82212
82213
82214
82215
82216
82217
82218
82219
82220
82221
82222
82223
82224
82225
82226
82227
82228
82229
82230
82231
82232
82233
82234
82235
82236
82237
82238
82239
82240
82241
82242
82243
82244
82245
82246
82247
82248
82249
82250
82251
82252
82253
82254
82255
82256
82257
82258
82259
82260
82261
82262
82263
82264
82265
82266
82267
82268
82269
82270
82271
82272
82273
82274
82275
82276
82277
82278
82279
82280
82281
82282
82283
82284
82285
82286
82287
82288
82289
82290
82291
82292
82293
82294
82295
82296
82297
82298
82299
82300
82301
82302
82303
82304
82305
82306
82307
82308
82309
82310
82311
82312
82313
82314
82315
82316
82317
82318
82319
82320
82321
82322
82323
82324
82325
82326
82327
82328
82329
82330
82331
82332
82333
82334
82335
82336
82337
82338
82339
82340
82341
82342
82343
82344
82345
82346
82347
82348
82349
82350
82351
82352
82353
82354
82355
82356
82357
82358
82359
82360
82361
82362
82363
82364
82365
82366
82367
82368
82369
82370
82371
82372
82373
82374
82375
82376
82377
82378
82379
82380
82381
82382
82383
82384
82385
82386
82387
82388
82389
82390
82391
82392
82393
82394
82395
82396
82397
82398
82399
82400
82401
82402
82403
82404
82405
82406
82407
82408
82409
82410
82411
82412
82413
82414
82415
82416
82417
82418
82419
82420
82421
82422
82423
82424
82425
82426
82427
82428
82429
82430
82431
82432
82433
82434
82435
82436
82437
82438
82439
82440
82441
82442
82443
82444
82445
82446
82447
82448
82449
82450
82451
82452
82453
82454
82455
82456
82457
82458
82459
82460
82461
82462
82463
82464
82465
82466
82467
82468
82469
82470
82471
82472
82473
82474
82475
82476
82477
82478
82479
82480
82481
82482
82483
82484
82485
82486
82487
82488
82489
82490
82491
82492
82493
82494
82495
82496
82497
82498
82499
82500
82501
82502
82503
82504
82505
82506
82507
82508
82509
82510
82511
82512
82513
82514
82515
82516
82517
82518
82519
82520
82521
82522
82523
82524
82525
82526
82527
82528
82529
82530
82531
82532
82533
82534
82535
82536
82537
82538
82539
82540
82541
82542
82543
82544
82545
82546
82547
82548
82549
82550
82551
82552
82553
82554
82555
82556
82557
82558
82559
82560
82561
82562
82563
82564
82565
82566
82567
82568
82569
82570
82571
82572
82573
82574
82575
82576
82577
82578
82579
82580
82581
82582
82583
82584
82585
82586
82587
82588
82589
82590
82591
82592
82593
82594
82595
82596
82597
82598
82599
82600
82601
82602
82603
82604
82605
82606
82607
82608
82609
82610
82611
82612
82613
82614
82615
82616
82617
82618
82619
82620
82621
82622
82623
82624
82625
82626
82627
82628
82629
82630
82631
82632
82633
82634
82635
82636
82637
82638
82639
82640
82641
82642
82643
82644
82645
82646
82647
82648
82649
82650
82651
82652
82653
82654
82655
82656
82657
82658
82659
82660
82661
82662
82663
82664
82665
82666
82667
82668
82669
82670
82671
82672
82673
82674
82675
82676
82677
82678
82679
82680
82681
82682
82683
82684
82685
82686
82687
82688
82689
82690
82691
82692
82693
82694
82695
82696
82697
82698
82699
82700
82701
82702
82703
82704
82705
82706
82707
82708
82709
82710
82711
82712
82713
82714
82715
82716
82717
82718
82719
82720
82721
82722
82723
82724
82725
82726
82727
82728
82729
82730
82731
82732
82733
82734
82735
82736
82737
82738
82739
82740
82741
82742
82743
82744
82745
82746
82747
82748
82749
82750
82751
82752
82753
82754
82755
82756
82757
82758
82759
82760
82761
82762
82763
82764
82765
82766
82767
82768
82769
82770
82771
82772
82773
82774
82775
82776
82777
82778
82779
82780
82781
82782
82783
82784
82785
82786
82787
82788
82789
82790
82791
82792
82793
82794
82795
82796
82797
82798
82799
82800
82801
82802
82803
82804
82805
82806
82807
82808
82809
82810
82811
82812
82813
82814
82815
82816
82817
82818
82819
82820
82821
82822
82823
82824
82825
82826
82827
82828
82829
82830
82831
82832
82833
82834
82835
82836
82837
82838
82839
82840
82841
82842
82843
82844
82845
82846
82847
82848
82849
82850
82851
82852
82853
82854
82855
82856
82857
82858
82859
82860
82861
82862
82863
82864
82865
82866
82867
82868
82869
82870
82871
82872
82873
82874
82875
82876
82877
82878
82879
82880
82881
82882
82883
82884
82885
82886
82887
82888
82889
82890
82891
82892
82893
82894
82895
82896
82897
82898
82899
82900
82901
82902
82903
82904
82905
82906
82907
82908
82909
82910
82911
82912
82913
82914
82915
82916
82917
82918
82919
82920
82921
82922
82923
82924
82925
82926
82927
82928
82929
82930
82931
82932
82933
82934
82935
82936
82937
82938
82939
82940
82941
82942
82943
82944
82945
82946
82947
82948
82949
82950
82951
82952
82953
82954
82955
82956
82957
82958
82959
82960
82961
82962
82963
82964
82965
82966
82967
82968
82969
82970
82971
82972
82973
82974
82975
82976
82977
82978
82979
82980
82981
82982
82983
82984
82985
82986
82987
82988
82989
82990
82991
82992
82993
82994
82995
82996
82997
82998
82999
83000
83001
83002
83003
83004
83005
83006
83007
83008
83009
83010
83011
83012
83013
83014
83015
83016
83017
83018
83019
83020
83021
83022
83023
83024
83025
83026
83027
83028
83029
83030
83031
83032
83033
83034
83035
83036
83037
83038
83039
83040
83041
83042
83043
83044
83045
83046
83047
83048
83049
83050
83051
83052
83053
83054
83055
83056
83057
83058
83059
83060
83061
83062
83063
83064
83065
83066
83067
83068
83069
83070
83071
83072
83073
83074
83075
83076
83077
83078
83079
83080
83081
83082
83083
83084
83085
83086
83087
83088
83089
83090
83091
83092
83093
83094
83095
83096
83097
83098
83099
83100
83101
83102
83103
83104
83105
83106
83107
83108
83109
83110
83111
83112
83113
83114
83115
83116
83117
83118
83119
83120
83121
83122
83123
83124
83125
83126
83127
83128
83129
83130
83131
83132
83133
83134
83135
83136
83137
83138
83139
83140
83141
83142
83143
83144
83145
83146
83147
83148
83149
83150
83151
83152
83153
83154
83155
83156
83157
83158
83159
83160
83161
83162
83163
83164
83165
83166
83167
83168
83169
83170
83171
83172
83173
83174
83175
83176
83177
83178
83179
83180
83181
83182
83183
83184
83185
83186
83187
83188
83189
83190
83191
83192
83193
83194
83195
83196
83197
83198
83199
83200
83201
83202
83203
83204
83205
83206
83207
83208
83209
83210
83211
83212
83213
83214
83215
83216
83217
83218
83219
83220
83221
83222
83223
83224
83225
83226
83227
83228
83229
83230
83231
83232
83233
83234
83235
83236
83237
83238
83239
83240
83241
83242
83243
83244
83245
83246
83247
83248
83249
83250
83251
83252
83253
83254
83255
83256
83257
83258
83259
83260
83261
83262
83263
83264
83265
83266
83267
83268
83269
83270
83271
83272
83273
83274
83275
83276
83277
83278
83279
83280
83281
83282
83283
83284
83285
83286
83287
83288
83289
83290
83291
83292
83293
83294
83295
83296
83297
83298
83299
83300
83301
83302
83303
83304
83305
83306
83307
83308
83309
83310
83311
83312
83313
83314
83315
83316
83317
83318
83319
83320
83321
83322
83323
83324
83325
83326
83327
83328
83329
83330
83331
83332
83333
83334
83335
83336
83337
83338
83339
83340
83341
83342
83343
83344
83345
83346
83347
83348
83349
83350
83351
83352
83353
83354
83355
83356
83357
83358
83359
83360
83361
83362
83363
83364
83365
83366
83367
83368
83369
83370
83371
83372
83373
83374
83375
83376
83377
83378
83379
83380
83381
83382
83383
83384
83385
83386
83387
83388
83389
83390
83391
83392
83393
83394
83395
83396
83397
83398
83399
83400
83401
83402
83403
83404
83405
83406
83407
83408
83409
83410
83411
83412
83413
83414
83415
83416
83417
83418
83419
83420
83421
83422
83423
83424
83425
83426
83427
83428
83429
83430
83431
83432
83433
83434
83435
83436
83437
83438
83439
83440
83441
83442
83443
83444
83445
83446
83447
83448
83449
83450
83451
83452
83453
83454
83455
83456
83457
83458
83459
83460
83461
83462
83463
83464
83465
83466
83467
83468
83469
83470
83471
83472
83473
83474
83475
83476
83477
83478
83479
83480
83481
83482
83483
83484
83485
83486
83487
83488
83489
83490
83491
83492
83493
83494
83495
83496
83497
83498
83499
83500
83501
83502
83503
83504
83505
83506
83507
83508
83509
83510
83511
83512
83513
83514
83515
83516
83517
83518
83519
83520
83521
83522
83523
83524
83525
83526
83527
83528
83529
83530
83531
83532
83533
83534
83535
83536
83537
83538
83539
83540
83541
83542
83543
83544
83545
83546
83547
83548
83549
83550
83551
83552
83553
83554
83555
83556
83557
83558
83559
83560
83561
83562
83563
83564
83565
83566
83567
83568
83569
83570
83571
83572
83573
83574
83575
83576
83577
83578
83579
83580
83581
83582
83583
83584
83585
83586
83587
83588
83589
83590
83591
83592
83593
83594
83595
83596
83597
83598
83599
83600
83601
83602
83603
83604
83605
83606
83607
83608
83609
83610
83611
83612
83613
83614
83615
83616
83617
83618
83619
83620
83621
83622
83623
83624
83625
83626
83627
83628
83629
83630
83631
83632
83633
83634
83635
83636
83637
83638
83639
83640
83641
83642
83643
83644
83645
83646
83647
83648
83649
83650
83651
83652
83653
83654
83655
83656
83657
83658
83659
83660
83661
83662
83663
83664
83665
83666
83667
83668
83669
83670
83671
83672
83673
83674
83675
83676
83677
83678
83679
83680
83681
83682
83683
83684
83685
83686
83687
83688
83689
83690
83691
83692
83693
83694
83695
83696
83697
83698
83699
83700
83701
83702
83703
83704
83705
83706
83707
83708
83709
83710
83711
83712
83713
83714
83715
83716
83717
83718
83719
83720
83721
83722
83723
83724
83725
83726
83727
83728
83729
83730
83731
83732
83733
83734
83735
83736
83737
83738
83739
83740
83741
83742
83743
83744
83745
83746
83747
83748
83749
83750
83751
83752
83753
83754
83755
83756
83757
83758
83759
83760
83761
83762
83763
83764
83765
83766
83767
83768
83769
83770
83771
83772
83773
83774
83775
83776
83777
83778
83779
83780
83781
83782
83783
83784
83785
83786
83787
83788
83789
83790
83791
83792
83793
83794
83795
83796
83797
83798
83799
83800
83801
83802
83803
83804
83805
83806
83807
83808
83809
83810
83811
83812
83813
83814
83815
83816
83817
83818
83819
83820
83821
83822
83823
83824
83825
83826
83827
83828
83829
83830
83831
83832
83833
83834
83835
83836
83837
83838
83839
83840
83841
83842
83843
83844
83845
83846
83847
83848
83849
83850
83851
83852
83853
83854
83855
83856
83857
83858
83859
83860
83861
83862
83863
83864
83865
83866
83867
83868
83869
83870
83871
83872
83873
83874
83875
83876
83877
83878
83879
83880
83881
83882
83883
83884
83885
83886
83887
83888
83889
83890
83891
83892
83893
83894
83895
83896
83897
83898
83899
83900
83901
83902
83903
83904
83905
83906
83907
83908
83909
83910
83911
83912
83913
83914
83915
83916
83917
83918
83919
83920
83921
83922
83923
83924
83925
83926
83927
83928
83929
83930
83931
83932
83933
83934
83935
83936
83937
83938
83939
83940
83941
83942
83943
83944
83945
83946
83947
83948
83949
83950
83951
83952
83953
83954
83955
83956
83957
83958
83959
83960
83961
83962
83963
83964
83965
83966
83967
83968
83969
83970
83971
83972
83973
83974
83975
83976
83977
83978
83979
83980
83981
83982
83983
83984
83985
83986
83987
83988
83989
83990
83991
83992
83993
83994
83995
83996
83997
83998
83999
84000
84001
84002
84003
84004
84005
84006
84007
84008
84009
84010
84011
84012
84013
84014
84015
84016
84017
84018
84019
84020
84021
84022
84023
84024
84025
84026
84027
84028
84029
84030
84031
84032
84033
84034
84035
84036
84037
84038
84039
84040
84041
84042
84043
84044
84045
84046
84047
84048
84049
84050
84051
84052
84053
84054
84055
84056
84057
84058
84059
84060
84061
84062
84063
84064
84065
84066
84067
84068
84069
84070
84071
84072
84073
84074
84075
84076
84077
84078
84079
84080
84081
84082
84083
84084
84085
84086
84087
84088
84089
84090
84091
84092
84093
84094
84095
84096
84097
84098
84099
84100
84101
84102
84103
84104
84105
84106
84107
84108
84109
84110
84111
84112
84113
84114
84115
84116
84117
84118
84119
84120
84121
84122
84123
84124
84125
84126
84127
84128
84129
84130
84131
84132
84133
84134
84135
84136
84137
84138
84139
84140
84141
84142
84143
84144
84145
84146
84147
84148
84149
84150
84151
84152
84153
84154
84155
84156
84157
84158
84159
84160
84161
84162
84163
84164
84165
84166
84167
84168
84169
84170
84171
84172
84173
84174
84175
84176
84177
84178
84179
84180
84181
84182
84183
84184
84185
84186
84187
84188
84189
84190
84191
84192
84193
84194
84195
84196
84197
84198
84199
84200
84201
84202
84203
84204
84205
84206
84207
84208
84209
84210
84211
84212
84213
84214
84215
84216
84217
84218
84219
84220
84221
84222
84223
84224
84225
84226
84227
84228
84229
84230
84231
84232
84233
84234
84235
84236
84237
84238
84239
84240
84241
84242
84243
84244
84245
84246
84247
84248
84249
84250
84251
84252
84253
84254
84255
84256
84257
84258
84259
84260
84261
84262
84263
84264
84265
84266
84267
84268
84269
84270
84271
84272
84273
84274
84275
84276
84277
84278
84279
84280
84281
84282
84283
84284
84285
84286
84287
84288
84289
84290
84291
84292
84293
84294
84295
84296
84297
84298
84299
84300
84301
84302
84303
84304
84305
84306
84307
84308
84309
84310
84311
84312
84313
84314
84315
84316
84317
84318
84319
84320
84321
84322
84323
84324
84325
84326
84327
84328
84329
84330
84331
84332
84333
84334
84335
84336
84337
84338
84339
84340
84341
84342
84343
84344
84345
84346
84347
84348
84349
84350
84351
84352
84353
84354
84355
84356
84357
84358
84359
84360
84361
84362
84363
84364
84365
84366
84367
84368
84369
84370
84371
84372
84373
84374
84375
84376
84377
84378
84379
84380
84381
84382
84383
84384
84385
84386
84387
84388
84389
84390
84391
84392
84393
84394
84395
84396
84397
84398
84399
84400
84401
84402
84403
84404
84405
84406
84407
84408
84409
84410
84411
84412
84413
84414
84415
84416
84417
84418
84419
84420
84421
84422
84423
84424
84425
84426
84427
84428
84429
84430
84431
84432
84433
84434
84435
84436
84437
84438
84439
84440
84441
84442
84443
84444
84445
84446
84447
84448
84449
84450
84451
84452
84453
84454
84455
84456
84457
84458
84459
84460
84461
84462
84463
84464
84465
84466
84467
84468
84469
84470
84471
84472
84473
84474
84475
84476
84477
84478
84479
84480
84481
84482
84483
84484
84485
84486
84487
84488
84489
84490
84491
84492
84493
84494
84495
84496
84497
84498
84499
84500
84501
84502
84503
84504
84505
84506
84507
84508
84509
84510
84511
84512
84513
84514
84515
84516
84517
84518
84519
84520
84521
84522
84523
84524
84525
84526
84527
84528
84529
84530
84531
84532
84533
84534
84535
84536
84537
84538
84539
84540
84541
84542
84543
84544
84545
84546
84547
84548
84549
84550
84551
84552
84553
84554
84555
84556
84557
84558
84559
84560
84561
84562
84563
84564
84565
84566
84567
84568
84569
84570
84571
84572
84573
84574
84575
84576
84577
84578
84579
84580
84581
84582
84583
84584
84585
84586
84587
84588
84589
84590
84591
84592
84593
84594
84595
84596
84597
84598
84599
84600
84601
84602
84603
84604
84605
84606
84607
84608
84609
84610
84611
84612
84613
84614
84615
84616
84617
84618
84619
84620
84621
84622
84623
84624
84625
84626
84627
84628
84629
84630
84631
84632
84633
84634
84635
84636
84637
84638
84639
84640
84641
84642
84643
84644
84645
84646
84647
84648
84649
84650
84651
84652
84653
84654
84655
84656
84657
84658
84659
84660
84661
84662
84663
84664
84665
84666
84667
84668
84669
84670
84671
84672
84673
84674
84675
84676
84677
84678
84679
84680
84681
84682
84683
84684
84685
84686
84687
84688
84689
84690
84691
84692
84693
84694
84695
84696
84697
84698
84699
84700
84701
84702
84703
84704
84705
84706
84707
84708
84709
84710
84711
84712
84713
84714
84715
84716
84717
84718
84719
84720
84721
84722
84723
84724
84725
84726
84727
84728
84729
84730
84731
84732
84733
84734
84735
84736
84737
84738
84739
84740
84741
84742
84743
84744
84745
84746
84747
84748
84749
84750
84751
84752
84753
84754
84755
84756
84757
84758
84759
84760
84761
84762
84763
84764
84765
84766
84767
84768
84769
84770
84771
84772
84773
84774
84775
84776
84777
84778
84779
84780
84781
84782
84783
84784
84785
84786
84787
84788
84789
84790
84791
84792
84793
84794
84795
84796
84797
84798
84799
84800
84801
84802
84803
84804
84805
84806
84807
84808
84809
84810
84811
84812
84813
84814
84815
84816
84817
84818
84819
84820
84821
84822
84823
84824
84825
84826
84827
84828
84829
84830
84831
84832
84833
84834
84835
84836
84837
84838
84839
84840
84841
84842
84843
84844
84845
84846
84847
84848
84849
84850
84851
84852
84853
84854
84855
84856
84857
84858
84859
84860
84861
84862
84863
84864
84865
84866
84867
84868
84869
84870
84871
84872
84873
84874
84875
84876
84877
84878
84879
84880
84881
84882
84883
84884
84885
84886
84887
84888
84889
84890
84891
84892
84893
84894
84895
84896
84897
84898
84899
84900
84901
84902
84903
84904
84905
84906
84907
84908
84909
84910
84911
84912
84913
84914
84915
84916
84917
84918
84919
84920
84921
84922
84923
84924
84925
84926
84927
84928
84929
84930
84931
84932
84933
84934
84935
84936
84937
84938
84939
84940
84941
84942
84943
84944
84945
84946
84947
84948
84949
84950
84951
84952
84953
84954
84955
84956
84957
84958
84959
84960
84961
84962
84963
84964
84965
84966
84967
84968
84969
84970
84971
84972
84973
84974
84975
84976
84977
84978
84979
84980
84981
84982
84983
84984
84985
84986
84987
84988
84989
84990
84991
84992
84993
84994
84995
84996
84997
84998
84999
85000
85001
85002
85003
85004
85005
85006
85007
85008
85009
85010
85011
85012
85013
85014
85015
85016
85017
85018
85019
85020
85021
85022
85023
85024
85025
85026
85027
85028
85029
85030
85031
85032
85033
85034
85035
85036
85037
85038
85039
85040
85041
85042
85043
85044
85045
85046
85047
85048
85049
85050
85051
85052
85053
85054
85055
85056
85057
85058
85059
85060
85061
85062
85063
85064
85065
85066
85067
85068
85069
85070
85071
85072
85073
85074
85075
85076
85077
85078
85079
85080
85081
85082
85083
85084
85085
85086
85087
85088
85089
85090
85091
85092
85093
85094
85095
85096
85097
85098
85099
85100
85101
85102
85103
85104
85105
85106
85107
85108
85109
85110
85111
85112
85113
85114
85115
85116
85117
85118
85119
85120
85121
85122
85123
85124
85125
85126
85127
85128
85129
85130
85131
85132
85133
85134
85135
85136
85137
85138
85139
85140
85141
85142
85143
85144
85145
85146
85147
85148
85149
85150
85151
85152
85153
85154
85155
85156
85157
85158
85159
85160
85161
85162
85163
85164
85165
85166
85167
85168
85169
85170
85171
85172
85173
85174
85175
85176
85177
85178
85179
85180
85181
85182
85183
85184
85185
85186
85187
85188
85189
85190
85191
85192
85193
85194
85195
85196
85197
85198
85199
85200
85201
85202
85203
85204
85205
85206
85207
85208
85209
85210
85211
85212
85213
85214
85215
85216
85217
85218
85219
85220
85221
85222
85223
85224
85225
85226
85227
85228
85229
85230
85231
85232
85233
85234
85235
85236
85237
85238
85239
85240
85241
85242
85243
85244
85245
85246
85247
85248
85249
85250
85251
85252
85253
85254
85255
85256
85257
85258
85259
85260
85261
85262
85263
85264
85265
85266
85267
85268
85269
85270
85271
85272
85273
85274
85275
85276
85277
85278
85279
85280
85281
85282
85283
85284
85285
85286
85287
85288
85289
85290
85291
85292
85293
85294
85295
85296
85297
85298
85299
85300
85301
85302
85303
85304
85305
85306
85307
85308
85309
85310
85311
85312
85313
85314
85315
85316
85317
85318
85319
85320
85321
85322
85323
85324
85325
85326
85327
85328
85329
85330
85331
85332
85333
85334
85335
85336
85337
85338
85339
85340
85341
85342
85343
85344
85345
85346
85347
85348
85349
85350
85351
85352
85353
85354
85355
85356
85357
85358
85359
85360
85361
85362
85363
85364
85365
85366
85367
85368
85369
85370
85371
85372
85373
85374
85375
85376
85377
85378
85379
85380
85381
85382
85383
85384
85385
85386
85387
85388
85389
85390
85391
85392
85393
85394
85395
85396
85397
85398
85399
85400
85401
85402
85403
85404
85405
85406
85407
85408
85409
85410
85411
85412
85413
85414
85415
85416
85417
85418
85419
85420
85421
85422
85423
85424
85425
85426
85427
85428
85429
85430
85431
85432
85433
85434
85435
85436
85437
85438
85439
85440
85441
85442
85443
85444
85445
85446
85447
85448
85449
85450
85451
85452
85453
85454
85455
85456
85457
85458
85459
85460
85461
85462
85463
85464
85465
85466
85467
85468
85469
85470
85471
85472
85473
85474
85475
85476
85477
85478
85479
85480
85481
85482
85483
85484
85485
85486
85487
85488
85489
85490
85491
85492
85493
85494
85495
85496
85497
85498
85499
85500
85501
85502
85503
85504
85505
85506
85507
85508
85509
85510
85511
85512
85513
85514
85515
85516
85517
85518
85519
85520
85521
85522
85523
85524
85525
85526
85527
85528
85529
85530
85531
85532
85533
85534
85535
85536
85537
85538
85539
85540
85541
85542
85543
85544
85545
85546
85547
85548
85549
85550
85551
85552
85553
85554
85555
85556
85557
85558
85559
85560
85561
85562
85563
85564
85565
85566
85567
85568
85569
85570
85571
85572
85573
85574
85575
85576
85577
85578
85579
85580
85581
85582
85583
85584
85585
85586
85587
85588
85589
85590
85591
85592
85593
85594
85595
85596
85597
85598
85599
85600
85601
85602
85603
85604
85605
85606
85607
85608
85609
85610
85611
85612
85613
85614
85615
85616
85617
85618
85619
85620
85621
85622
85623
85624
85625
85626
85627
85628
85629
85630
85631
85632
85633
85634
85635
85636
85637
85638
85639
85640
85641
85642
85643
85644
85645
85646
85647
85648
85649
85650
85651
85652
85653
85654
85655
85656
85657
85658
85659
85660
85661
85662
85663
85664
85665
85666
85667
85668
85669
85670
85671
85672
85673
85674
85675
85676
85677
85678
85679
85680
85681
85682
85683
85684
85685
85686
85687
85688
85689
85690
85691
85692
85693
85694
85695
85696
85697
85698
85699
85700
85701
85702
85703
85704
85705
85706
85707
85708
85709
85710
85711
85712
85713
85714
85715
85716
85717
85718
85719
85720
85721
85722
85723
85724
85725
85726
85727
85728
85729
85730
85731
85732
85733
85734
85735
85736
85737
85738
85739
85740
85741
85742
85743
85744
85745
85746
85747
85748
85749
85750
85751
85752
85753
85754
85755
85756
85757
85758
85759
85760
85761
85762
85763
85764
85765
85766
85767
85768
85769
85770
85771
85772
85773
85774
85775
85776
85777
85778
85779
85780
85781
85782
85783
85784
85785
85786
85787
85788
85789
85790
85791
85792
85793
85794
85795
85796
85797
85798
85799
85800
85801
85802
85803
85804
85805
85806
85807
85808
85809
85810
85811
85812
85813
85814
85815
85816
85817
85818
85819
85820
85821
85822
85823
85824
85825
85826
85827
85828
85829
85830
85831
85832
85833
85834
85835
85836
85837
85838
85839
85840
85841
85842
85843
85844
85845
85846
85847
85848
85849
85850
85851
85852
85853
85854
85855
85856
85857
85858
85859
85860
85861
85862
85863
85864
85865
85866
85867
85868
85869
85870
85871
85872
85873
85874
85875
85876
85877
85878
85879
85880
85881
85882
85883
85884
85885
85886
85887
85888
85889
85890
85891
85892
85893
85894
85895
85896
85897
85898
85899
85900
85901
85902
85903
85904
85905
85906
85907
85908
85909
85910
85911
85912
85913
85914
85915
85916
85917
85918
85919
85920
85921
85922
85923
85924
85925
85926
85927
85928
85929
85930
85931
85932
85933
85934
85935
85936
85937
85938
85939
85940
85941
85942
85943
85944
85945
85946
85947
85948
85949
85950
85951
85952
85953
85954
85955
85956
85957
85958
85959
85960
85961
85962
85963
85964
85965
85966
85967
85968
85969
85970
85971
85972
85973
85974
85975
85976
85977
85978
85979
85980
85981
85982
85983
85984
85985
85986
85987
85988
85989
85990
85991
85992
85993
85994
85995
85996
85997
85998
85999
86000
86001
86002
86003
86004
86005
86006
86007
86008
86009
86010
86011
86012
86013
86014
86015
86016
86017
86018
86019
86020
86021
86022
86023
86024
86025
86026
86027
86028
86029
86030
86031
86032
86033
86034
86035
86036
86037
86038
86039
86040
86041
86042
86043
86044
86045
86046
86047
86048
86049
86050
86051
86052
86053
86054
86055
86056
86057
86058
86059
86060
86061
86062
86063
86064
86065
86066
86067
86068
86069
86070
86071
86072
86073
86074
86075
86076
86077
86078
86079
86080
86081
86082
86083
86084
86085
86086
86087
86088
86089
86090
86091
86092
86093
86094
86095
86096
86097
86098
86099
86100
86101
86102
86103
86104
86105
86106
86107
86108
86109
86110
86111
86112
86113
86114
86115
86116
86117
86118
86119
86120
86121
86122
86123
86124
86125
86126
86127
86128
86129
86130
86131
86132
86133
86134
86135
86136
86137
86138
86139
86140
86141
86142
86143
86144
86145
86146
86147
86148
86149
86150
86151
86152
86153
86154
86155
86156
86157
86158
86159
86160
86161
86162
86163
86164
86165
86166
86167
86168
86169
86170
86171
86172
86173
86174
86175
86176
86177
86178
86179
86180
86181
86182
86183
86184
86185
86186
86187
86188
86189
86190
86191
86192
86193
86194
86195
86196
86197
86198
86199
86200
86201
86202
86203
86204
86205
86206
86207
86208
86209
86210
86211
86212
86213
86214
86215
86216
86217
86218
86219
86220
86221
86222
86223
86224
86225
86226
86227
86228
86229
86230
86231
86232
86233
86234
86235
86236
86237
86238
86239
86240
86241
86242
86243
86244
86245
86246
86247
86248
86249
86250
86251
86252
86253
86254
86255
86256
86257
86258
86259
86260
86261
86262
86263
86264
86265
86266
86267
86268
86269
86270
86271
86272
86273
86274
86275
86276
86277
86278
86279
86280
86281
86282
86283
86284
86285
86286
86287
86288
86289
86290
86291
86292
86293
86294
86295
86296
86297
86298
86299
86300
86301
86302
86303
86304
86305
86306
86307
86308
86309
86310
86311
86312
86313
86314
86315
86316
86317
86318
86319
86320
86321
86322
86323
86324
86325
86326
86327
86328
86329
86330
86331
86332
86333
86334
86335
86336
86337
86338
86339
86340
86341
86342
86343
86344
86345
86346
86347
86348
86349
86350
86351
86352
86353
86354
86355
86356
86357
86358
86359
86360
86361
86362
86363
86364
86365
86366
86367
86368
86369
86370
86371
86372
86373
86374
86375
86376
86377
86378
86379
86380
86381
86382
86383
86384
86385
86386
86387
86388
86389
86390
86391
86392
86393
86394
86395
86396
86397
86398
86399
86400
86401
86402
86403
86404
86405
86406
86407
86408
86409
86410
86411
86412
86413
86414
86415
86416
86417
86418
86419
86420
86421
86422
86423
86424
86425
86426
86427
86428
86429
86430
86431
86432
86433
86434
86435
86436
86437
86438
86439
86440
86441
86442
86443
86444
86445
86446
86447
86448
86449
86450
86451
86452
86453
86454
86455
86456
86457
86458
86459
86460
86461
86462
86463
86464
86465
86466
86467
86468
86469
86470
86471
86472
86473
86474
86475
86476
86477
86478
86479
86480
86481
86482
86483
86484
86485
86486
86487
86488
86489
86490
86491
86492
86493
86494
86495
86496
86497
86498
86499
86500
86501
86502
86503
86504
86505
86506
86507
86508
86509
86510
86511
86512
86513
86514
86515
86516
86517
86518
86519
86520
86521
86522
86523
86524
86525
86526
86527
86528
86529
86530
86531
86532
86533
86534
86535
86536
86537
86538
86539
86540
86541
86542
86543
86544
86545
86546
86547
86548
86549
86550
86551
86552
86553
86554
86555
86556
86557
86558
86559
86560
86561
86562
86563
86564
86565
86566
86567
86568
86569
86570
86571
86572
86573
86574
86575
86576
86577
86578
86579
86580
86581
86582
86583
86584
86585
86586
86587
86588
86589
86590
86591
86592
86593
86594
86595
86596
86597
86598
86599
86600
86601
86602
86603
86604
86605
86606
86607
86608
86609
86610
86611
86612
86613
86614
86615
86616
86617
86618
86619
86620
86621
86622
86623
86624
86625
86626
86627
86628
86629
86630
86631
86632
86633
86634
86635
86636
86637
86638
86639
86640
86641
86642
86643
86644
86645
86646
86647
86648
86649
86650
86651
86652
86653
86654
86655
86656
86657
86658
86659
86660
86661
86662
86663
86664
86665
86666
86667
86668
86669
86670
86671
86672
86673
86674
86675
86676
86677
86678
86679
86680
86681
86682
86683
86684
86685
86686
86687
86688
86689
86690
86691
86692
86693
86694
86695
86696
86697
86698
86699
86700
86701
86702
86703
86704
86705
86706
86707
86708
86709
86710
86711
86712
86713
86714
86715
86716
86717
86718
86719
86720
86721
86722
86723
86724
86725
86726
86727
86728
86729
86730
86731
86732
86733
86734
86735
86736
86737
86738
86739
86740
86741
86742
86743
86744
86745
86746
86747
86748
86749
86750
86751
86752
86753
86754
86755
86756
86757
86758
86759
86760
86761
86762
86763
86764
86765
86766
86767
86768
86769
86770
86771
86772
86773
86774
86775
86776
86777
86778
86779
86780
86781
86782
86783
86784
86785
86786
86787
86788
86789
86790
86791
86792
86793
86794
86795
86796
86797
86798
86799
86800
86801
86802
86803
86804
86805
86806
86807
86808
86809
86810
86811
86812
86813
86814
86815
86816
86817
86818
86819
86820
86821
86822
86823
86824
86825
86826
86827
86828
86829
86830
86831
86832
86833
86834
86835
86836
86837
86838
86839
86840
86841
86842
86843
86844
86845
86846
86847
86848
86849
86850
86851
86852
86853
86854
86855
86856
86857
86858
86859
86860
86861
86862
86863
86864
86865
86866
86867
86868
86869
86870
86871
86872
86873
86874
86875
86876
86877
86878
86879
86880
86881
86882
86883
86884
86885
86886
86887
86888
86889
86890
86891
86892
86893
86894
86895
86896
86897
86898
86899
86900
86901
86902
86903
86904
86905
86906
86907
86908
86909
86910
86911
86912
86913
86914
86915
86916
86917
86918
86919
86920
86921
86922
86923
86924
86925
86926
86927
86928
86929
86930
86931
86932
86933
86934
86935
86936
86937
86938
86939
86940
86941
86942
86943
86944
86945
86946
86947
86948
86949
86950
86951
86952
86953
86954
86955
86956
86957
86958
86959
86960
86961
86962
86963
86964
86965
86966
86967
86968
86969
86970
86971
86972
86973
86974
86975
86976
86977
86978
86979
86980
86981
86982
86983
86984
86985
86986
86987
86988
86989
86990
86991
86992
86993
86994
86995
86996
86997
86998
86999
87000
87001
87002
87003
87004
87005
87006
87007
87008
87009
87010
87011
87012
87013
87014
87015
87016
87017
87018
87019
87020
87021
87022
87023
87024
87025
87026
87027
87028
87029
87030
87031
87032
87033
87034
87035
87036
87037
87038
87039
87040
87041
87042
87043
87044
87045
87046
87047
87048
87049
87050
87051
87052
87053
87054
87055
87056
87057
87058
87059
87060
87061
87062
87063
87064
87065
87066
87067
87068
87069
87070
87071
87072
87073
87074
87075
87076
87077
87078
87079
87080
87081
87082
87083
87084
87085
87086
87087
87088
87089
87090
87091
87092
87093
87094
87095
87096
87097
87098
87099
87100
87101
87102
87103
87104
87105
87106
87107
87108
87109
87110
87111
87112
87113
87114
87115
87116
87117
87118
87119
87120
87121
87122
87123
87124
87125
87126
87127
87128
87129
87130
87131
87132
87133
87134
87135
87136
87137
87138
87139
87140
87141
87142
87143
87144
87145
87146
87147
87148
87149
87150
87151
87152
87153
87154
87155
87156
87157
87158
87159
87160
87161
87162
87163
87164
87165
87166
87167
87168
87169
87170
87171
87172
87173
87174
87175
87176
87177
87178
87179
87180
87181
87182
87183
87184
87185
87186
87187
87188
87189
87190
87191
87192
87193
87194
87195
87196
87197
87198
87199
87200
87201
87202
87203
87204
87205
87206
87207
87208
87209
87210
87211
87212
87213
87214
87215
87216
87217
87218
87219
87220
87221
87222
87223
87224
87225
87226
87227
87228
87229
87230
87231
87232
87233
87234
87235
87236
87237
87238
87239
87240
87241
87242
87243
87244
87245
87246
87247
87248
87249
87250
87251
87252
87253
87254
87255
87256
87257
87258
87259
87260
87261
87262
87263
87264
87265
87266
87267
87268
87269
87270
87271
87272
87273
87274
87275
87276
87277
87278
87279
87280
87281
87282
87283
87284
87285
87286
87287
87288
87289
87290
87291
87292
87293
87294
87295
87296
87297
87298
87299
87300
87301
87302
87303
87304
87305
87306
87307
87308
87309
87310
87311
87312
87313
87314
87315
87316
87317
87318
87319
87320
87321
87322
87323
87324
87325
87326
87327
87328
87329
87330
87331
87332
87333
87334
87335
87336
87337
87338
87339
87340
87341
87342
87343
87344
87345
87346
87347
87348
87349
87350
87351
87352
87353
87354
87355
87356
87357
87358
87359
87360
87361
87362
87363
87364
87365
87366
87367
87368
87369
87370
87371
87372
87373
87374
87375
87376
87377
87378
87379
87380
87381
87382
87383
87384
87385
87386
87387
87388
87389
87390
87391
87392
87393
87394
87395
87396
87397
87398
87399
87400
87401
87402
87403
87404
87405
87406
87407
87408
87409
87410
87411
87412
87413
87414
87415
87416
87417
87418
87419
87420
87421
87422
87423
87424
87425
87426
87427
87428
87429
87430
87431
87432
87433
87434
87435
87436
87437
87438
87439
87440
87441
87442
87443
87444
87445
87446
87447
87448
87449
87450
87451
87452
87453
87454
87455
87456
87457
87458
87459
87460
87461
87462
87463
87464
87465
87466
87467
87468
87469
87470
87471
87472
87473
87474
87475
87476
87477
87478
87479
87480
87481
87482
87483
87484
87485
87486
87487
87488
87489
87490
87491
87492
87493
87494
87495
87496
87497
87498
87499
87500
87501
87502
87503
87504
87505
87506
87507
87508
87509
87510
87511
87512
87513
87514
87515
87516
87517
87518
87519
87520
87521
87522
87523
87524
87525
87526
87527
87528
87529
87530
87531
87532
87533
87534
87535
87536
87537
87538
87539
87540
87541
87542
87543
87544
87545
87546
87547
87548
87549
87550
87551
87552
87553
87554
87555
87556
87557
87558
87559
87560
87561
87562
87563
87564
87565
87566
87567
87568
87569
87570
87571
87572
87573
87574
87575
87576
87577
87578
87579
87580
87581
87582
87583
87584
87585
87586
87587
87588
87589
87590
87591
87592
87593
87594
87595
87596
87597
87598
87599
87600
87601
87602
87603
87604
87605
87606
87607
87608
87609
87610
87611
87612
87613
87614
87615
87616
87617
87618
87619
87620
87621
87622
87623
87624
87625
87626
87627
87628
87629
87630
87631
87632
87633
87634
87635
87636
87637
87638
87639
87640
87641
87642
87643
87644
87645
87646
87647
87648
87649
87650
87651
87652
87653
87654
87655
87656
87657
87658
87659
87660
87661
87662
87663
87664
87665
87666
87667
87668
87669
87670
87671
87672
87673
87674
87675
87676
87677
87678
87679
87680
87681
87682
87683
87684
87685
87686
87687
87688
87689
87690
87691
87692
87693
87694
87695
87696
87697
87698
87699
87700
87701
87702
87703
87704
87705
87706
87707
87708
87709
87710
87711
87712
87713
87714
87715
87716
87717
87718
87719
87720
87721
87722
87723
87724
87725
87726
87727
87728
87729
87730
87731
87732
87733
87734
87735
87736
87737
87738
87739
87740
87741
87742
87743
87744
87745
87746
87747
87748
87749
87750
87751
87752
87753
87754
87755
87756
87757
87758
87759
87760
87761
87762
87763
87764
87765
87766
87767
87768
87769
87770
87771
87772
87773
87774
87775
87776
87777
87778
87779
87780
87781
87782
87783
87784
87785
87786
87787
87788
87789
87790
87791
87792
87793
87794
87795
87796
87797
87798
87799
87800
87801
87802
87803
87804
87805
87806
87807
87808
87809
87810
87811
87812
87813
87814
87815
87816
87817
87818
87819
87820
87821
87822
87823
87824
87825
87826
87827
87828
87829
87830
87831
87832
87833
87834
87835
87836
87837
87838
87839
87840
87841
87842
87843
87844
87845
87846
87847
87848
87849
87850
87851
87852
87853
87854
87855
87856
87857
87858
87859
87860
87861
87862
87863
87864
87865
87866
87867
87868
87869
87870
87871
87872
87873
87874
87875
87876
87877
87878
87879
87880
87881
87882
87883
87884
87885
87886
87887
87888
87889
87890
87891
87892
87893
87894
87895
87896
87897
87898
87899
87900
87901
87902
87903
87904
87905
87906
87907
87908
87909
87910
87911
87912
87913
87914
87915
87916
87917
87918
87919
87920
87921
87922
87923
87924
87925
87926
87927
87928
87929
87930
87931
87932
87933
87934
87935
87936
87937
87938
87939
87940
87941
87942
87943
87944
87945
87946
87947
87948
87949
87950
87951
87952
87953
87954
87955
87956
87957
87958
87959
87960
87961
87962
87963
87964
87965
87966
87967
87968
87969
87970
87971
87972
87973
87974
87975
87976
87977
87978
87979
87980
87981
87982
87983
87984
87985
87986
87987
87988
87989
87990
87991
87992
87993
87994
87995
87996
87997
87998
87999
88000
88001
88002
88003
88004
88005
88006
88007
88008
88009
88010
88011
88012
88013
88014
88015
88016
88017
88018
88019
88020
88021
88022
88023
88024
88025
88026
88027
88028
88029
88030
88031
88032
88033
88034
88035
88036
88037
88038
88039
88040
88041
88042
88043
88044
88045
88046
88047
88048
88049
88050
88051
88052
88053
88054
88055
88056
88057
88058
88059
88060
88061
88062
88063
88064
88065
88066
88067
88068
88069
88070
88071
88072
88073
88074
88075
88076
88077
88078
88079
88080
88081
88082
88083
88084
88085
88086
88087
88088
88089
88090
88091
88092
88093
88094
88095
88096
88097
88098
88099
88100
88101
88102
88103
88104
88105
88106
88107
88108
88109
88110
88111
88112
88113
88114
88115
88116
88117
88118
88119
88120
88121
88122
88123
88124
88125
88126
88127
88128
88129
88130
88131
88132
88133
88134
88135
88136
88137
88138
88139
88140
88141
88142
88143
88144
88145
88146
88147
88148
88149
88150
88151
88152
88153
88154
88155
88156
88157
88158
88159
88160
88161
88162
88163
88164
88165
88166
88167
88168
88169
88170
88171
88172
88173
88174
88175
88176
88177
88178
88179
88180
88181
88182
88183
88184
88185
88186
88187
88188
88189
88190
88191
88192
88193
88194
88195
88196
88197
88198
88199
88200
88201
88202
88203
88204
88205
88206
88207
88208
88209
88210
88211
88212
88213
88214
88215
88216
88217
88218
88219
88220
88221
88222
88223
88224
88225
88226
88227
88228
88229
88230
88231
88232
88233
88234
88235
88236
88237
88238
88239
88240
88241
88242
88243
88244
88245
88246
88247
88248
88249
88250
88251
88252
88253
88254
88255
88256
88257
88258
88259
88260
88261
88262
88263
88264
88265
88266
88267
88268
88269
88270
88271
88272
88273
88274
88275
88276
88277
88278
88279
88280
88281
88282
88283
88284
88285
88286
88287
88288
88289
88290
88291
88292
88293
88294
88295
88296
88297
88298
88299
88300
88301
88302
88303
88304
88305
88306
88307
88308
88309
88310
88311
88312
88313
88314
88315
88316
88317
88318
88319
88320
88321
88322
88323
88324
88325
88326
88327
88328
88329
88330
88331
88332
88333
88334
88335
88336
88337
88338
88339
88340
88341
88342
88343
88344
88345
88346
88347
88348
88349
88350
88351
88352
88353
88354
88355
88356
88357
88358
88359
88360
88361
88362
88363
88364
88365
88366
88367
88368
88369
88370
88371
88372
88373
88374
88375
88376
88377
88378
88379
88380
88381
88382
88383
88384
88385
88386
88387
88388
88389
88390
88391
88392
88393
88394
88395
88396
88397
88398
88399
88400
88401
88402
88403
88404
88405
88406
88407
88408
88409
88410
88411
88412
88413
88414
88415
88416
88417
88418
88419
88420
88421
88422
88423
88424
88425
88426
88427
88428
88429
88430
88431
88432
88433
88434
88435
88436
88437
88438
88439
88440
88441
88442
88443
88444
88445
88446
88447
88448
88449
88450
88451
88452
88453
88454
88455
88456
88457
88458
88459
88460
88461
88462
88463
88464
88465
88466
88467
88468
88469
88470
88471
88472
88473
88474
88475
88476
88477
88478
88479
88480
88481
88482
88483
88484
88485
88486
88487
88488
88489
88490
88491
88492
88493
88494
88495
88496
88497
88498
88499
88500
88501
88502
88503
88504
88505
88506
88507
88508
88509
88510
88511
88512
88513
88514
88515
88516
88517
88518
88519
88520
88521
88522
88523
88524
88525
88526
88527
88528
88529
88530
88531
88532
88533
88534
88535
88536
88537
88538
88539
88540
88541
88542
88543
88544
88545
88546
88547
88548
88549
88550
88551
88552
88553
88554
88555
88556
88557
88558
88559
88560
88561
88562
88563
88564
88565
88566
88567
88568
88569
88570
88571
88572
88573
88574
88575
88576
88577
88578
88579
88580
88581
88582
88583
88584
88585
88586
88587
88588
88589
88590
88591
88592
88593
88594
88595
88596
88597
88598
88599
88600
88601
88602
88603
88604
88605
88606
88607
88608
88609
88610
88611
88612
88613
88614
88615
88616
88617
88618
88619
88620
88621
88622
88623
88624
88625
88626
88627
88628
88629
88630
88631
88632
88633
88634
88635
88636
88637
88638
88639
88640
88641
88642
88643
88644
88645
88646
88647
88648
88649
88650
88651
88652
88653
88654
88655
88656
88657
88658
88659
88660
88661
88662
88663
88664
88665
88666
88667
88668
88669
88670
88671
88672
88673
88674
88675
88676
88677
88678
88679
88680
88681
88682
88683
88684
88685
88686
88687
88688
88689
88690
88691
88692
88693
88694
88695
88696
88697
88698
88699
88700
88701
88702
88703
88704
88705
88706
88707
88708
88709
88710
88711
88712
88713
88714
88715
88716
88717
88718
88719
88720
88721
88722
88723
88724
88725
88726
88727
88728
88729
88730
88731
88732
88733
88734
88735
88736
88737
88738
88739
88740
88741
88742
88743
88744
88745
88746
88747
88748
88749
88750
88751
88752
88753
88754
88755
88756
88757
88758
88759
88760
88761
88762
88763
88764
88765
88766
88767
88768
88769
88770
88771
88772
88773
88774
88775
88776
88777
88778
88779
88780
88781
88782
88783
88784
88785
88786
88787
88788
88789
88790
88791
88792
88793
88794
88795
88796
88797
88798
88799
88800
88801
88802
88803
88804
88805
88806
88807
88808
88809
88810
88811
88812
88813
88814
88815
88816
88817
88818
88819
88820
88821
88822
88823
88824
88825
88826
88827
88828
88829
88830
88831
88832
88833
88834
88835
88836
88837
88838
88839
88840
88841
88842
88843
88844
88845
88846
88847
88848
88849
88850
88851
88852
88853
88854
88855
88856
88857
88858
88859
88860
88861
88862
88863
88864
88865
88866
88867
88868
88869
88870
88871
88872
88873
88874
88875
88876
88877
88878
88879
88880
88881
88882
88883
88884
88885
88886
88887
88888
88889
88890
88891
88892
88893
88894
88895
88896
88897
88898
88899
88900
88901
88902
88903
88904
88905
88906
88907
88908
88909
88910
88911
88912
88913
88914
88915
88916
88917
88918
88919
88920
88921
88922
88923
88924
88925
88926
88927
88928
88929
88930
88931
88932
88933
88934
88935
88936
88937
88938
88939
88940
88941
88942
88943
88944
88945
88946
88947
88948
88949
88950
88951
88952
88953
88954
88955
88956
88957
88958
88959
88960
88961
88962
88963
88964
88965
88966
88967
88968
88969
88970
88971
88972
88973
88974
88975
88976
88977
88978
88979
88980
88981
88982
88983
88984
88985
88986
88987
88988
88989
88990
88991
88992
88993
88994
88995
88996
88997
88998
88999
89000
89001
89002
89003
89004
89005
89006
89007
89008
89009
89010
89011
89012
89013
89014
89015
89016
89017
89018
89019
89020
89021
89022
89023
89024
89025
89026
89027
89028
89029
89030
89031
89032
89033
89034
89035
89036
89037
89038
89039
89040
89041
89042
89043
89044
89045
89046
89047
89048
89049
89050
89051
89052
89053
89054
89055
89056
89057
89058
89059
89060
89061
89062
89063
89064
89065
89066
89067
89068
89069
89070
89071
89072
89073
89074
89075
89076
89077
89078
89079
89080
89081
89082
89083
89084
89085
89086
89087
89088
89089
89090
89091
89092
89093
89094
89095
89096
89097
89098
89099
89100
89101
89102
89103
89104
89105
89106
89107
89108
89109
89110
89111
89112
89113
89114
89115
89116
89117
89118
89119
89120
89121
89122
89123
89124
89125
89126
89127
89128
89129
89130
89131
89132
89133
89134
89135
89136
89137
89138
89139
89140
89141
89142
89143
89144
89145
89146
89147
89148
89149
89150
89151
89152
89153
89154
89155
89156
89157
89158
89159
89160
89161
89162
89163
89164
89165
89166
89167
89168
89169
89170
89171
89172
89173
89174
89175
89176
89177
89178
89179
89180
89181
89182
89183
89184
89185
89186
89187
89188
89189
89190
89191
89192
89193
89194
89195
89196
89197
89198
89199
89200
89201
89202
89203
89204
89205
89206
89207
89208
89209
89210
89211
89212
89213
89214
89215
89216
89217
89218
89219
89220
89221
89222
89223
89224
89225
89226
89227
89228
89229
89230
89231
89232
89233
89234
89235
89236
89237
89238
89239
89240
89241
89242
89243
89244
89245
89246
89247
89248
89249
89250
89251
89252
89253
89254
89255
89256
89257
89258
89259
89260
89261
89262
89263
89264
89265
89266
89267
89268
89269
89270
89271
89272
89273
89274
89275
89276
89277
89278
89279
89280
89281
89282
89283
89284
89285
89286
89287
89288
89289
89290
89291
89292
89293
89294
89295
89296
89297
89298
89299
89300
89301
89302
89303
89304
89305
89306
89307
89308
89309
89310
89311
89312
89313
89314
89315
89316
89317
89318
89319
89320
89321
89322
89323
89324
89325
89326
89327
89328
89329
89330
89331
89332
89333
89334
89335
89336
89337
89338
89339
89340
89341
89342
89343
89344
89345
89346
89347
89348
89349
89350
89351
89352
89353
89354
89355
89356
89357
89358
89359
89360
89361
89362
89363
89364
89365
89366
89367
89368
89369
89370
89371
89372
89373
89374
89375
89376
89377
89378
89379
89380
89381
89382
89383
89384
89385
89386
89387
89388
89389
89390
89391
89392
89393
89394
89395
89396
89397
89398
89399
89400
89401
89402
89403
89404
89405
89406
89407
89408
89409
89410
89411
89412
89413
89414
89415
89416
89417
89418
89419
89420
89421
89422
89423
89424
89425
89426
89427
89428
89429
89430
89431
89432
89433
89434
89435
89436
89437
89438
89439
89440
89441
89442
89443
89444
89445
89446
89447
89448
89449
89450
89451
89452
89453
89454
89455
89456
89457
89458
89459
89460
89461
89462
89463
89464
89465
89466
89467
89468
89469
89470
89471
89472
89473
89474
89475
89476
89477
89478
89479
89480
89481
89482
89483
89484
89485
89486
89487
89488
89489
89490
89491
89492
89493
89494
89495
89496
89497
89498
89499
89500
89501
89502
89503
89504
89505
89506
89507
89508
89509
89510
89511
89512
89513
89514
89515
89516
89517
89518
89519
89520
89521
89522
89523
89524
89525
89526
89527
89528
89529
89530
89531
89532
89533
89534
89535
89536
89537
89538
89539
89540
89541
89542
89543
89544
89545
89546
89547
89548
89549
89550
89551
89552
89553
89554
89555
89556
89557
89558
89559
89560
89561
89562
89563
89564
89565
89566
89567
89568
89569
89570
89571
89572
89573
89574
89575
89576
89577
89578
89579
89580
89581
89582
89583
89584
89585
89586
89587
89588
89589
89590
89591
89592
89593
89594
89595
89596
89597
89598
89599
89600
89601
89602
89603
89604
89605
89606
89607
89608
89609
89610
89611
89612
89613
89614
89615
89616
89617
89618
89619
89620
89621
89622
89623
89624
89625
89626
89627
89628
89629
89630
89631
89632
89633
89634
89635
89636
89637
89638
89639
89640
89641
89642
89643
89644
89645
89646
89647
89648
89649
89650
89651
89652
89653
89654
89655
89656
89657
89658
89659
89660
89661
89662
89663
89664
89665
89666
89667
89668
89669
89670
89671
89672
89673
89674
89675
89676
89677
89678
89679
89680
89681
89682
89683
89684
89685
89686
89687
89688
89689
89690
89691
89692
89693
89694
89695
89696
89697
89698
89699
89700
89701
89702
89703
89704
89705
89706
89707
89708
89709
89710
89711
89712
89713
89714
89715
89716
89717
89718
89719
89720
89721
89722
89723
89724
89725
89726
89727
89728
89729
89730
89731
89732
89733
89734
89735
89736
89737
89738
89739
89740
89741
89742
89743
89744
89745
89746
89747
89748
89749
89750
89751
89752
89753
89754
89755
89756
89757
89758
89759
89760
89761
89762
89763
89764
89765
89766
89767
89768
89769
89770
89771
89772
89773
89774
89775
89776
89777
89778
89779
89780
89781
89782
89783
89784
89785
89786
89787
89788
89789
89790
89791
89792
89793
89794
89795
89796
89797
89798
89799
89800
89801
89802
89803
89804
89805
89806
89807
89808
89809
89810
89811
89812
89813
89814
89815
89816
89817
89818
89819
89820
89821
89822
89823
89824
89825
89826
89827
89828
89829
89830
89831
89832
89833
89834
89835
89836
89837
89838
89839
89840
89841
89842
89843
89844
89845
89846
89847
89848
89849
89850
89851
89852
89853
89854
89855
89856
89857
89858
89859
89860
89861
89862
89863
89864
89865
89866
89867
89868
89869
89870
89871
89872
89873
89874
89875
89876
89877
89878
89879
89880
89881
89882
89883
89884
89885
89886
89887
89888
89889
89890
89891
89892
89893
89894
89895
89896
89897
89898
89899
89900
89901
89902
89903
89904
89905
89906
89907
89908
89909
89910
89911
89912
89913
89914
89915
89916
89917
89918
89919
89920
89921
89922
89923
89924
89925
89926
89927
89928
89929
89930
89931
89932
89933
89934
89935
89936
89937
89938
89939
89940
89941
89942
89943
89944
89945
89946
89947
89948
89949
89950
89951
89952
89953
89954
89955
89956
89957
89958
89959
89960
89961
89962
89963
89964
89965
89966
89967
89968
89969
89970
89971
89972
89973
89974
89975
89976
89977
89978
89979
89980
89981
89982
89983
89984
89985
89986
89987
89988
89989
89990
89991
89992
89993
89994
89995
89996
89997
89998
89999
90000
90001
90002
90003
90004
90005
90006
90007
90008
90009
90010
90011
90012
90013
90014
90015
90016
90017
90018
90019
90020
90021
90022
90023
90024
90025
90026
90027
90028
90029
90030
90031
90032
90033
90034
90035
90036
90037
90038
90039
90040
90041
90042
90043
90044
90045
90046
90047
90048
90049
90050
90051
90052
90053
90054
90055
90056
90057
90058
90059
90060
90061
90062
90063
90064
90065
90066
90067
90068
90069
90070
90071
90072
90073
90074
90075
90076
90077
90078
90079
90080
90081
90082
90083
90084
90085
90086
90087
90088
90089
90090
90091
90092
90093
90094
90095
90096
90097
90098
90099
90100
90101
90102
90103
90104
90105
90106
90107
90108
90109
90110
90111
90112
90113
90114
90115
90116
90117
90118
90119
90120
90121
90122
90123
90124
90125
90126
90127
90128
90129
90130
90131
90132
90133
90134
90135
90136
90137
90138
90139
90140
90141
90142
90143
90144
90145
90146
90147
90148
90149
90150
90151
90152
90153
90154
90155
90156
90157
90158
90159
90160
90161
90162
90163
90164
90165
90166
90167
90168
90169
90170
90171
90172
90173
90174
90175
90176
90177
90178
90179
90180
90181
90182
90183
90184
90185
90186
90187
90188
90189
90190
90191
90192
90193
90194
90195
90196
90197
90198
90199
90200
90201
90202
90203
90204
90205
90206
90207
90208
90209
90210
90211
90212
90213
90214
90215
90216
90217
90218
90219
90220
90221
90222
90223
90224
90225
90226
90227
90228
90229
90230
90231
90232
90233
90234
90235
90236
90237
90238
90239
90240
90241
90242
90243
90244
90245
90246
90247
90248
90249
90250
90251
90252
90253
90254
90255
90256
90257
90258
90259
90260
90261
90262
90263
90264
90265
90266
90267
90268
90269
90270
90271
90272
90273
90274
90275
90276
90277
90278
90279
90280
90281
90282
90283
90284
90285
90286
90287
90288
90289
90290
90291
90292
90293
90294
90295
90296
90297
90298
90299
90300
90301
90302
90303
90304
90305
90306
90307
90308
90309
90310
90311
90312
90313
90314
90315
90316
90317
90318
90319
90320
90321
90322
90323
90324
90325
90326
90327
90328
90329
90330
90331
90332
90333
90334
90335
90336
90337
90338
90339
90340
90341
90342
90343
90344
90345
90346
90347
90348
90349
90350
90351
90352
90353
90354
90355
90356
90357
90358
90359
90360
90361
90362
90363
90364
90365
90366
90367
90368
90369
90370
90371
90372
90373
90374
90375
90376
90377
90378
90379
90380
90381
90382
90383
90384
90385
90386
90387
90388
90389
90390
90391
90392
90393
90394
90395
90396
90397
90398
90399
90400
90401
90402
90403
90404
90405
90406
90407
90408
90409
90410
90411
90412
90413
90414
90415
90416
90417
90418
90419
90420
90421
90422
90423
90424
90425
90426
90427
90428
90429
90430
90431
90432
90433
90434
90435
90436
90437
90438
90439
90440
90441
90442
90443
90444
90445
90446
90447
90448
90449
90450
90451
90452
90453
90454
90455
90456
90457
90458
90459
90460
90461
90462
90463
90464
90465
90466
90467
90468
90469
90470
90471
90472
90473
90474
90475
90476
90477
90478
90479
90480
90481
90482
90483
90484
90485
90486
90487
90488
90489
90490
90491
90492
90493
90494
90495
90496
90497
90498
90499
90500
90501
90502
90503
90504
90505
90506
90507
90508
90509
90510
90511
90512
90513
90514
90515
90516
90517
90518
90519
90520
90521
90522
90523
90524
90525
90526
90527
90528
90529
90530
90531
90532
90533
90534
90535
90536
90537
90538
90539
90540
90541
90542
90543
90544
90545
90546
90547
90548
90549
90550
90551
90552
90553
90554
90555
90556
90557
90558
90559
90560
90561
90562
90563
90564
90565
90566
90567
90568
90569
90570
90571
90572
90573
90574
90575
90576
90577
90578
90579
90580
90581
90582
90583
90584
90585
90586
90587
90588
90589
90590
90591
90592
90593
90594
90595
90596
90597
90598
90599
90600
90601
90602
90603
90604
90605
90606
90607
90608
90609
90610
90611
90612
90613
90614
90615
90616
90617
90618
90619
90620
90621
90622
90623
90624
90625
90626
90627
90628
90629
90630
90631
90632
90633
90634
90635
90636
90637
90638
90639
90640
90641
90642
90643
90644
90645
90646
90647
90648
90649
90650
90651
90652
90653
90654
90655
90656
90657
90658
90659
90660
90661
90662
90663
90664
90665
90666
90667
90668
90669
90670
90671
90672
90673
90674
90675
90676
90677
90678
90679
90680
90681
90682
90683
90684
90685
90686
90687
90688
90689
90690
90691
90692
90693
90694
90695
90696
90697
90698
90699
90700
90701
90702
90703
90704
90705
90706
90707
90708
90709
90710
90711
90712
90713
90714
90715
90716
90717
90718
90719
90720
90721
90722
90723
90724
90725
90726
90727
90728
90729
90730
90731
90732
90733
90734
90735
90736
90737
90738
90739
90740
90741
90742
90743
90744
90745
90746
90747
90748
90749
90750
90751
90752
90753
90754
90755
90756
90757
90758
90759
90760
90761
90762
90763
90764
90765
90766
90767
90768
90769
90770
90771
90772
90773
90774
90775
90776
90777
90778
90779
90780
90781
90782
90783
90784
90785
90786
90787
90788
90789
90790
90791
90792
90793
90794
90795
90796
90797
90798
90799
90800
90801
90802
90803
90804
90805
90806
90807
90808
90809
90810
90811
90812
90813
90814
90815
90816
90817
90818
90819
90820
90821
90822
90823
90824
90825
90826
90827
90828
90829
90830
90831
90832
90833
90834
90835
90836
90837
90838
90839
90840
90841
90842
90843
90844
90845
90846
90847
90848
90849
90850
90851
90852
90853
90854
90855
90856
90857
90858
90859
90860
90861
90862
90863
90864
90865
90866
90867
90868
90869
90870
90871
90872
90873
90874
90875
90876
90877
90878
90879
90880
90881
90882
90883
90884
90885
90886
90887
90888
90889
90890
90891
90892
90893
90894
90895
90896
90897
90898
90899
90900
90901
90902
90903
90904
90905
90906
90907
90908
90909
90910
90911
90912
90913
90914
90915
90916
90917
90918
90919
90920
90921
90922
90923
90924
90925
90926
90927
90928
90929
90930
90931
90932
90933
90934
90935
90936
90937
90938
90939
90940
90941
90942
90943
90944
90945
90946
90947
90948
90949
90950
90951
90952
90953
90954
90955
90956
90957
90958
90959
90960
90961
90962
90963
90964
90965
90966
90967
90968
90969
90970
90971
90972
90973
90974
90975
90976
90977
90978
90979
90980
90981
90982
90983
90984
90985
90986
90987
90988
90989
90990
90991
90992
90993
90994
90995
90996
90997
90998
90999
91000
91001
91002
91003
91004
91005
91006
91007
91008
91009
91010
91011
91012
91013
91014
91015
91016
91017
91018
91019
91020
91021
91022
91023
91024
91025
91026
91027
91028
91029
91030
91031
91032
91033
91034
91035
91036
91037
91038
91039
91040
91041
91042
91043
91044
91045
91046
91047
91048
91049
91050
91051
91052
91053
91054
91055
91056
91057
91058
91059
91060
91061
91062
91063
91064
91065
91066
91067
91068
91069
91070
91071
91072
91073
91074
91075
91076
91077
91078
91079
91080
91081
91082
91083
91084
91085
91086
91087
91088
91089
91090
91091
91092
91093
91094
91095
91096
91097
91098
91099
91100
91101
91102
91103
91104
91105
91106
91107
91108
91109
91110
91111
91112
91113
91114
91115
91116
91117
91118
91119
91120
91121
91122
91123
91124
91125
91126
91127
91128
91129
91130
91131
91132
91133
91134
91135
91136
91137
91138
91139
91140
91141
91142
91143
91144
91145
91146
91147
91148
91149
91150
91151
91152
91153
91154
91155
91156
91157
91158
91159
91160
91161
91162
91163
91164
91165
91166
91167
91168
91169
91170
91171
91172
91173
91174
91175
91176
91177
91178
91179
91180
91181
91182
91183
91184
91185
91186
91187
91188
91189
91190
91191
91192
91193
91194
91195
91196
91197
91198
91199
91200
91201
91202
91203
91204
91205
91206
91207
91208
91209
91210
91211
91212
91213
91214
91215
91216
91217
91218
91219
91220
91221
91222
91223
91224
91225
91226
91227
91228
91229
91230
91231
91232
91233
91234
91235
91236
91237
91238
91239
91240
91241
91242
91243
91244
91245
91246
91247
91248
91249
91250
91251
91252
91253
91254
91255
91256
91257
91258
91259
91260
91261
91262
91263
91264
91265
91266
91267
91268
91269
91270
91271
91272
91273
91274
91275
91276
91277
91278
91279
91280
91281
91282
91283
91284
91285
91286
91287
91288
91289
91290
91291
91292
91293
91294
91295
91296
91297
91298
91299
91300
91301
91302
91303
91304
91305
91306
91307
91308
91309
91310
91311
91312
91313
91314
91315
91316
91317
91318
91319
91320
91321
91322
91323
91324
91325
91326
91327
91328
91329
91330
91331
91332
91333
91334
91335
91336
91337
91338
91339
91340
91341
91342
91343
91344
91345
91346
91347
91348
91349
91350
91351
91352
91353
91354
91355
91356
91357
91358
91359
91360
91361
91362
91363
91364
91365
91366
91367
91368
91369
91370
91371
91372
91373
91374
91375
91376
91377
91378
91379
91380
91381
91382
91383
91384
91385
91386
91387
91388
91389
91390
91391
91392
91393
91394
91395
91396
91397
91398
91399
91400
91401
91402
91403
91404
91405
91406
91407
91408
91409
91410
91411
91412
91413
91414
91415
91416
91417
91418
91419
91420
91421
91422
91423
91424
91425
91426
91427
91428
91429
91430
91431
91432
91433
91434
91435
91436
91437
91438
91439
91440
91441
91442
91443
91444
91445
91446
91447
91448
91449
91450
91451
91452
91453
91454
91455
91456
91457
91458
91459
91460
91461
91462
91463
91464
91465
91466
91467
91468
91469
91470
91471
91472
91473
91474
91475
91476
91477
91478
91479
91480
91481
91482
91483
91484
91485
91486
91487
91488
91489
91490
91491
91492
91493
91494
91495
91496
91497
91498
91499
91500
91501
91502
91503
91504
91505
91506
91507
91508
91509
91510
91511
91512
91513
91514
91515
91516
91517
91518
91519
91520
91521
91522
91523
91524
91525
91526
91527
91528
91529
91530
91531
91532
91533
91534
91535
91536
91537
91538
91539
91540
91541
91542
91543
91544
91545
91546
91547
91548
91549
91550
91551
91552
91553
91554
91555
91556
91557
91558
91559
91560
91561
91562
91563
91564
91565
91566
91567
91568
91569
91570
91571
91572
91573
91574
91575
91576
91577
91578
91579
91580
91581
91582
91583
91584
91585
91586
91587
91588
91589
91590
91591
91592
91593
91594
91595
91596
91597
91598
91599
91600
91601
91602
91603
91604
91605
91606
91607
91608
91609
91610
91611
91612
91613
91614
91615
91616
91617
91618
91619
91620
91621
91622
91623
91624
91625
91626
91627
91628
91629
91630
91631
91632
91633
91634
91635
91636
91637
91638
91639
91640
91641
91642
91643
91644
91645
91646
91647
91648
91649
91650
91651
91652
91653
91654
91655
91656
91657
91658
91659
91660
91661
91662
91663
91664
91665
91666
91667
91668
91669
91670
91671
91672
91673
91674
91675
91676
91677
91678
91679
91680
91681
91682
91683
91684
91685
91686
91687
91688
91689
91690
91691
91692
91693
91694
91695
91696
91697
91698
91699
91700
91701
91702
91703
91704
91705
91706
91707
91708
91709
91710
91711
91712
91713
91714
91715
91716
91717
91718
91719
91720
91721
91722
91723
91724
91725
91726
91727
91728
91729
91730
91731
91732
91733
91734
91735
91736
91737
91738
91739
91740
91741
91742
91743
91744
91745
91746
91747
91748
91749
91750
91751
91752
91753
91754
91755
91756
91757
91758
91759
91760
91761
91762
91763
91764
91765
91766
91767
91768
91769
91770
91771
91772
91773
91774
91775
91776
91777
91778
91779
91780
91781
91782
91783
91784
91785
91786
91787
91788
91789
91790
91791
91792
91793
91794
91795
91796
91797
91798
91799
91800
91801
91802
91803
91804
91805
91806
91807
91808
91809
91810
91811
91812
91813
91814
91815
91816
91817
91818
91819
91820
91821
91822
91823
91824
91825
91826
91827
91828
91829
91830
91831
91832
91833
91834
91835
91836
91837
91838
91839
91840
91841
91842
91843
91844
91845
91846
91847
91848
91849
91850
91851
91852
91853
91854
91855
91856
91857
91858
91859
91860
91861
91862
91863
91864
91865
91866
91867
91868
91869
91870
91871
91872
91873
91874
91875
91876
91877
91878
91879
91880
91881
91882
91883
91884
91885
91886
91887
91888
91889
91890
91891
91892
91893
91894
91895
91896
91897
91898
91899
91900
91901
91902
91903
91904
91905
91906
91907
91908
91909
91910
91911
91912
91913
91914
91915
91916
91917
91918
91919
91920
91921
91922
91923
91924
91925
91926
91927
91928
91929
91930
91931
91932
91933
91934
91935
91936
91937
91938
91939
91940
91941
91942
91943
91944
91945
91946
91947
91948
91949
91950
91951
91952
91953
91954
91955
91956
91957
91958
91959
91960
91961
91962
91963
91964
91965
91966
91967
91968
91969
91970
91971
91972
91973
91974
91975
91976
91977
91978
91979
91980
91981
91982
91983
91984
91985
91986
91987
91988
91989
91990
91991
91992
91993
91994
91995
91996
91997
91998
91999
92000
92001
92002
92003
92004
92005
92006
92007
92008
92009
92010
92011
92012
92013
92014
92015
92016
92017
92018
92019
92020
92021
92022
92023
92024
92025
92026
92027
92028
92029
92030
92031
92032
92033
92034
92035
92036
92037
92038
92039
92040
92041
92042
92043
92044
92045
92046
92047
92048
92049
92050
92051
92052
92053
92054
92055
92056
92057
92058
92059
92060
92061
92062
92063
92064
92065
92066
92067
92068
92069
92070
92071
92072
92073
92074
92075
92076
92077
92078
92079
92080
92081
92082
92083
92084
92085
92086
92087
92088
92089
92090
92091
92092
92093
92094
92095
92096
92097
92098
92099
92100
92101
92102
92103
92104
92105
92106
92107
92108
92109
92110
92111
92112
92113
92114
92115
92116
92117
92118
92119
92120
92121
92122
92123
92124
92125
92126
92127
92128
92129
92130
92131
92132
92133
92134
92135
92136
92137
92138
92139
92140
92141
92142
92143
92144
92145
92146
92147
92148
92149
92150
92151
92152
92153
92154
92155
92156
92157
92158
92159
92160
92161
92162
92163
92164
92165
92166
92167
92168
92169
92170
92171
92172
92173
92174
92175
92176
92177
92178
92179
92180
92181
92182
92183
92184
92185
92186
92187
92188
92189
92190
92191
92192
92193
92194
92195
92196
92197
92198
92199
92200
92201
92202
92203
92204
92205
92206
92207
92208
92209
92210
92211
92212
92213
92214
92215
92216
92217
92218
92219
92220
92221
92222
92223
92224
92225
92226
92227
92228
92229
92230
92231
92232
92233
92234
92235
92236
92237
92238
92239
92240
92241
92242
92243
92244
92245
92246
92247
92248
92249
92250
92251
92252
92253
92254
92255
92256
92257
92258
92259
92260
92261
92262
92263
92264
92265
92266
92267
92268
92269
92270
92271
92272
92273
92274
92275
92276
92277
92278
92279
92280
92281
92282
92283
92284
92285
92286
92287
92288
92289
92290
92291
92292
92293
92294
92295
92296
92297
92298
92299
92300
92301
92302
92303
92304
92305
92306
92307
92308
92309
92310
92311
92312
92313
92314
92315
92316
92317
92318
92319
92320
92321
92322
92323
92324
92325
92326
92327
92328
92329
92330
92331
92332
92333
92334
92335
92336
92337
92338
92339
92340
92341
92342
92343
92344
92345
92346
92347
92348
92349
92350
92351
92352
92353
92354
92355
92356
92357
92358
92359
92360
92361
92362
92363
92364
92365
92366
92367
92368
92369
92370
92371
92372
92373
92374
92375
92376
92377
92378
92379
92380
92381
92382
92383
92384
92385
92386
92387
92388
92389
92390
92391
92392
92393
92394
92395
92396
92397
92398
92399
92400
92401
92402
92403
92404
92405
92406
92407
92408
92409
92410
92411
92412
92413
92414
92415
92416
92417
92418
92419
92420
92421
92422
92423
92424
92425
92426
92427
92428
92429
92430
92431
92432
92433
92434
92435
92436
92437
92438
92439
92440
92441
92442
92443
92444
92445
92446
92447
92448
92449
92450
92451
92452
92453
92454
92455
92456
92457
92458
92459
92460
92461
92462
92463
92464
92465
92466
92467
92468
92469
92470
92471
92472
92473
92474
92475
92476
92477
92478
92479
92480
92481
92482
92483
92484
92485
92486
92487
92488
92489
92490
92491
92492
92493
92494
92495
92496
92497
92498
92499
92500
92501
92502
92503
92504
92505
92506
92507
92508
92509
92510
92511
92512
92513
92514
92515
92516
92517
92518
92519
92520
92521
92522
92523
92524
92525
92526
92527
92528
92529
92530
92531
92532
92533
92534
92535
92536
92537
92538
92539
92540
92541
92542
92543
92544
92545
92546
92547
92548
92549
92550
92551
92552
92553
92554
92555
92556
92557
92558
92559
92560
92561
92562
92563
92564
92565
92566
92567
92568
92569
92570
92571
92572
92573
92574
92575
92576
92577
92578
92579
92580
92581
92582
92583
92584
92585
92586
92587
92588
92589
92590
92591
92592
92593
92594
92595
92596
92597
92598
92599
92600
92601
92602
92603
92604
92605
92606
92607
92608
92609
92610
92611
92612
92613
92614
92615
92616
92617
92618
92619
92620
92621
92622
92623
92624
92625
92626
92627
92628
92629
92630
92631
92632
92633
92634
92635
92636
92637
92638
92639
92640
92641
92642
92643
92644
92645
92646
92647
92648
92649
92650
92651
92652
92653
92654
92655
92656
92657
92658
92659
92660
92661
92662
92663
92664
92665
92666
92667
92668
92669
92670
92671
92672
92673
92674
92675
92676
92677
92678
92679
92680
92681
92682
92683
92684
92685
92686
92687
92688
92689
92690
92691
92692
92693
92694
92695
92696
92697
92698
92699
92700
92701
92702
92703
92704
92705
92706
92707
92708
92709
92710
92711
92712
92713
92714
92715
92716
92717
92718
92719
92720
92721
92722
92723
92724
92725
92726
92727
92728
92729
92730
92731
92732
92733
92734
92735
92736
92737
92738
92739
92740
92741
92742
92743
92744
92745
92746
92747
92748
92749
92750
92751
92752
92753
92754
92755
92756
92757
92758
92759
92760
92761
92762
92763
92764
92765
92766
92767
92768
92769
92770
92771
92772
92773
92774
92775
92776
92777
92778
92779
92780
92781
92782
92783
92784
92785
92786
92787
92788
92789
92790
92791
92792
92793
92794
92795
92796
92797
92798
92799
92800
92801
92802
92803
92804
92805
92806
92807
92808
92809
92810
92811
92812
92813
92814
92815
92816
92817
92818
92819
92820
92821
92822
92823
92824
92825
92826
92827
92828
92829
92830
92831
92832
92833
92834
92835
92836
92837
92838
92839
92840
92841
92842
92843
92844
92845
92846
92847
92848
92849
92850
92851
92852
92853
92854
92855
92856
92857
92858
92859
92860
92861
92862
92863
92864
92865
92866
92867
92868
92869
92870
92871
92872
92873
92874
92875
92876
92877
92878
92879
92880
92881
92882
92883
92884
92885
92886
92887
92888
92889
92890
92891
92892
92893
92894
92895
92896
92897
92898
92899
92900
92901
92902
92903
92904
92905
92906
92907
92908
92909
92910
92911
92912
92913
92914
92915
92916
92917
92918
92919
92920
92921
92922
92923
92924
92925
92926
92927
92928
92929
92930
92931
92932
92933
92934
92935
92936
92937
92938
92939
92940
92941
92942
92943
92944
92945
92946
92947
92948
92949
92950
92951
92952
92953
92954
92955
92956
92957
92958
92959
92960
92961
92962
92963
92964
92965
92966
92967
92968
92969
92970
92971
92972
92973
92974
92975
92976
92977
92978
92979
92980
92981
92982
92983
92984
92985
92986
92987
92988
92989
92990
92991
92992
92993
92994
92995
92996
92997
92998
92999
93000
93001
93002
93003
93004
93005
93006
93007
93008
93009
93010
93011
93012
93013
93014
93015
93016
93017
93018
93019
93020
93021
93022
93023
93024
93025
93026
93027
93028
93029
93030
93031
93032
93033
93034
93035
93036
93037
93038
93039
93040
93041
93042
93043
93044
93045
93046
93047
93048
93049
93050
93051
93052
93053
93054
93055
93056
93057
93058
93059
93060
93061
93062
93063
93064
93065
93066
93067
93068
93069
93070
93071
93072
93073
93074
93075
93076
93077
93078
93079
93080
93081
93082
93083
93084
93085
93086
93087
93088
93089
93090
93091
93092
93093
93094
93095
93096
93097
93098
93099
93100
93101
93102
93103
93104
93105
93106
93107
93108
93109
93110
93111
93112
93113
93114
93115
93116
93117
93118
93119
93120
93121
93122
93123
93124
93125
93126
93127
93128
93129
93130
93131
93132
93133
93134
93135
93136
93137
93138
93139
93140
93141
93142
93143
93144
93145
93146
93147
93148
93149
93150
93151
93152
93153
93154
93155
93156
93157
93158
93159
93160
93161
93162
93163
93164
93165
93166
93167
93168
93169
93170
93171
93172
93173
93174
93175
93176
93177
93178
93179
93180
93181
93182
93183
93184
93185
93186
93187
93188
93189
93190
93191
93192
93193
93194
93195
93196
93197
93198
93199
93200
93201
93202
93203
93204
93205
93206
93207
93208
93209
93210
93211
93212
93213
93214
93215
93216
93217
93218
93219
93220
93221
93222
93223
93224
93225
93226
93227
93228
93229
93230
93231
93232
93233
93234
93235
93236
93237
93238
93239
93240
93241
93242
93243
93244
93245
93246
93247
93248
93249
93250
93251
93252
93253
93254
93255
93256
93257
93258
93259
93260
93261
93262
93263
93264
93265
93266
93267
93268
93269
93270
93271
93272
93273
93274
93275
93276
93277
93278
93279
93280
93281
93282
93283
93284
93285
93286
93287
93288
93289
93290
93291
93292
93293
93294
93295
93296
93297
93298
93299
93300
93301
93302
93303
93304
93305
93306
93307
93308
93309
93310
93311
93312
93313
93314
93315
93316
93317
93318
93319
93320
93321
93322
93323
93324
93325
93326
93327
93328
93329
93330
93331
93332
93333
93334
93335
93336
93337
93338
93339
93340
93341
93342
93343
93344
93345
93346
93347
93348
93349
93350
93351
93352
93353
93354
93355
93356
93357
93358
93359
93360
93361
93362
93363
93364
93365
93366
93367
93368
93369
93370
93371
93372
93373
93374
93375
93376
93377
93378
93379
93380
93381
93382
93383
93384
93385
93386
93387
93388
93389
93390
93391
93392
93393
93394
93395
93396
93397
93398
93399
93400
93401
93402
93403
93404
93405
93406
93407
93408
93409
93410
93411
93412
93413
93414
93415
93416
93417
93418
93419
93420
93421
93422
93423
93424
93425
93426
93427
93428
93429
93430
93431
93432
93433
93434
93435
93436
93437
93438
93439
93440
93441
93442
93443
93444
93445
93446
93447
93448
93449
93450
93451
93452
93453
93454
93455
93456
93457
93458
93459
93460
93461
93462
93463
93464
93465
93466
93467
93468
93469
93470
93471
93472
93473
93474
93475
93476
93477
93478
93479
93480
93481
93482
93483
93484
93485
93486
93487
93488
93489
93490
93491
93492
93493
93494
93495
93496
93497
93498
93499
93500
93501
93502
93503
93504
93505
93506
93507
93508
93509
93510
93511
93512
93513
93514
93515
93516
93517
93518
93519
93520
93521
93522
93523
93524
93525
93526
93527
93528
93529
93530
93531
93532
93533
93534
93535
93536
93537
93538
93539
93540
93541
93542
93543
93544
93545
93546
93547
93548
93549
93550
93551
93552
93553
93554
93555
93556
93557
93558
93559
93560
93561
93562
93563
93564
93565
93566
93567
93568
93569
93570
93571
93572
93573
93574
93575
93576
93577
93578
93579
93580
93581
93582
93583
93584
93585
93586
93587
93588
93589
93590
93591
93592
93593
93594
93595
93596
93597
93598
93599
93600
93601
93602
93603
93604
93605
93606
93607
93608
93609
93610
93611
93612
93613
93614
93615
93616
93617
93618
93619
93620
93621
93622
93623
93624
93625
93626
93627
93628
93629
93630
93631
93632
93633
93634
93635
93636
93637
93638
93639
93640
93641
93642
93643
93644
93645
93646
93647
93648
93649
93650
93651
93652
93653
93654
93655
93656
93657
93658
93659
93660
93661
93662
93663
93664
93665
93666
93667
93668
93669
93670
93671
93672
93673
93674
93675
93676
93677
93678
93679
93680
93681
93682
93683
93684
93685
93686
93687
93688
93689
93690
93691
93692
93693
93694
93695
93696
93697
93698
93699
93700
93701
93702
93703
93704
93705
93706
93707
93708
93709
93710
93711
93712
93713
93714
93715
93716
93717
93718
93719
93720
93721
93722
93723
93724
93725
93726
93727
93728
93729
93730
93731
93732
93733
93734
93735
93736
93737
93738
93739
93740
93741
93742
93743
93744
93745
93746
93747
93748
93749
93750
93751
93752
93753
93754
93755
93756
93757
93758
93759
93760
93761
93762
93763
93764
93765
93766
93767
93768
93769
93770
93771
93772
93773
93774
93775
93776
93777
93778
93779
93780
93781
93782
93783
93784
93785
93786
93787
93788
93789
93790
93791
93792
93793
93794
93795
93796
93797
93798
93799
93800
93801
93802
93803
93804
93805
93806
93807
93808
93809
93810
93811
93812
93813
93814
93815
93816
93817
93818
93819
93820
93821
93822
93823
93824
93825
93826
93827
93828
93829
93830
93831
93832
93833
93834
93835
93836
93837
93838
93839
93840
93841
93842
93843
93844
93845
93846
93847
93848
93849
93850
93851
93852
93853
93854
93855
93856
93857
93858
93859
93860
93861
93862
93863
93864
93865
93866
93867
93868
93869
93870
93871
93872
93873
93874
93875
93876
93877
93878
93879
93880
93881
93882
93883
93884
93885
93886
93887
93888
93889
93890
93891
93892
93893
93894
93895
93896
93897
93898
93899
93900
93901
93902
93903
93904
93905
93906
93907
93908
93909
93910
93911
93912
93913
93914
93915
93916
93917
93918
93919
93920
93921
93922
93923
93924
93925
93926
93927
93928
93929
93930
93931
93932
93933
93934
93935
93936
93937
93938
93939
93940
93941
93942
93943
93944
93945
93946
93947
93948
93949
93950
93951
93952
93953
93954
93955
93956
93957
93958
93959
93960
93961
93962
93963
93964
93965
93966
93967
93968
93969
93970
93971
93972
93973
93974
93975
93976
93977
93978
93979
93980
93981
93982
93983
93984
93985
93986
93987
93988
93989
93990
93991
93992
93993
93994
93995
93996
93997
93998
93999
94000
94001
94002
94003
94004
94005
94006
94007
94008
94009
94010
94011
94012
94013
94014
94015
94016
94017
94018
94019
94020
94021
94022
94023
94024
94025
94026
94027
94028
94029
94030
94031
94032
94033
94034
94035
94036
94037
94038
94039
94040
94041
94042
94043
94044
94045
94046
94047
94048
94049
94050
94051
94052
94053
94054
94055
94056
94057
94058
94059
94060
94061
94062
94063
94064
94065
94066
94067
94068
94069
94070
94071
94072
94073
94074
94075
94076
94077
94078
94079
94080
94081
94082
94083
94084
94085
94086
94087
94088
94089
94090
94091
94092
94093
94094
94095
94096
94097
94098
94099
94100
94101
94102
94103
94104
94105
94106
94107
94108
94109
94110
94111
94112
94113
94114
94115
94116
94117
94118
94119
94120
94121
94122
94123
94124
94125
94126
94127
94128
94129
94130
94131
94132
94133
94134
94135
94136
94137
94138
94139
94140
94141
94142
94143
94144
94145
94146
94147
94148
94149
94150
94151
94152
94153
94154
94155
94156
94157
94158
94159
94160
94161
94162
94163
94164
94165
94166
94167
94168
94169
94170
94171
94172
94173
94174
94175
94176
94177
94178
94179
94180
94181
94182
94183
94184
94185
94186
94187
94188
94189
94190
94191
94192
94193
94194
94195
94196
94197
94198
94199
94200
94201
94202
94203
94204
94205
94206
94207
94208
94209
94210
94211
94212
94213
94214
94215
94216
94217
94218
94219
94220
94221
94222
94223
94224
94225
94226
94227
94228
94229
94230
94231
94232
94233
94234
94235
94236
94237
94238
94239
94240
94241
94242
94243
94244
94245
94246
94247
94248
94249
94250
94251
94252
94253
94254
94255
94256
94257
94258
94259
94260
94261
94262
94263
94264
94265
94266
94267
94268
94269
94270
94271
94272
94273
94274
94275
94276
94277
94278
94279
94280
94281
94282
94283
94284
94285
94286
94287
94288
94289
94290
94291
94292
94293
94294
94295
94296
94297
94298
94299
94300
94301
94302
94303
94304
94305
94306
94307
94308
94309
94310
94311
94312
94313
94314
94315
94316
94317
94318
94319
94320
94321
94322
94323
94324
94325
94326
94327
94328
94329
94330
94331
94332
94333
94334
94335
94336
94337
94338
94339
94340
94341
94342
94343
94344
94345
94346
94347
94348
94349
94350
94351
94352
94353
94354
94355
94356
94357
94358
94359
94360
94361
94362
94363
94364
94365
94366
94367
94368
94369
94370
94371
94372
94373
94374
94375
94376
94377
94378
94379
94380
94381
94382
94383
94384
94385
94386
94387
94388
94389
94390
94391
94392
94393
94394
94395
94396
94397
94398
94399
94400
94401
94402
94403
94404
94405
94406
94407
94408
94409
94410
94411
94412
94413
94414
94415
94416
94417
94418
94419
94420
94421
94422
94423
94424
94425
94426
94427
94428
94429
94430
94431
94432
94433
94434
94435
94436
94437
94438
94439
94440
94441
94442
94443
94444
94445
94446
94447
94448
94449
94450
94451
94452
94453
94454
94455
94456
94457
94458
94459
94460
94461
94462
94463
94464
94465
94466
94467
94468
94469
94470
94471
94472
94473
94474
94475
94476
94477
94478
94479
94480
94481
94482
94483
94484
94485
94486
94487
94488
94489
94490
94491
94492
94493
94494
94495
94496
94497
94498
94499
94500
94501
94502
94503
94504
94505
94506
94507
94508
94509
94510
94511
94512
94513
94514
94515
94516
94517
94518
94519
94520
94521
94522
94523
94524
94525
94526
94527
94528
94529
94530
94531
94532
94533
94534
94535
94536
94537
94538
94539
94540
94541
94542
94543
94544
94545
94546
94547
94548
94549
94550
94551
94552
94553
94554
94555
94556
94557
94558
94559
94560
94561
94562
94563
94564
94565
94566
94567
94568
94569
94570
94571
94572
94573
94574
94575
94576
94577
94578
94579
94580
94581
94582
94583
94584
94585
94586
94587
94588
94589
94590
94591
94592
94593
94594
94595
94596
94597
94598
94599
94600
94601
94602
94603
94604
94605
94606
94607
94608
94609
94610
94611
94612
94613
94614
94615
94616
94617
94618
94619
94620
94621
94622
94623
94624
94625
94626
94627
94628
94629
94630
94631
94632
94633
94634
94635
94636
94637
94638
94639
94640
94641
94642
94643
94644
94645
94646
94647
94648
94649
94650
94651
94652
94653
94654
94655
94656
94657
94658
94659
94660
94661
94662
94663
94664
94665
94666
94667
94668
94669
94670
94671
94672
94673
94674
94675
94676
94677
94678
94679
94680
94681
94682
94683
94684
94685
94686
94687
94688
94689
94690
94691
94692
94693
94694
94695
94696
94697
94698
94699
94700
94701
94702
94703
94704
94705
94706
94707
94708
94709
94710
94711
94712
94713
94714
94715
94716
94717
94718
94719
94720
94721
94722
94723
94724
94725
94726
94727
94728
94729
94730
94731
94732
94733
94734
94735
94736
94737
94738
94739
94740
94741
94742
94743
94744
94745
94746
94747
94748
94749
94750
94751
94752
94753
94754
94755
94756
94757
94758
94759
94760
94761
94762
94763
94764
94765
94766
94767
94768
94769
94770
94771
94772
94773
94774
94775
94776
94777
94778
94779
94780
94781
94782
94783
94784
94785
94786
94787
94788
94789
94790
94791
94792
94793
94794
94795
94796
94797
94798
94799
94800
94801
94802
94803
94804
94805
94806
94807
94808
94809
94810
94811
94812
94813
94814
94815
94816
94817
94818
94819
94820
94821
94822
94823
94824
94825
94826
94827
94828
94829
94830
94831
94832
94833
94834
94835
94836
94837
94838
94839
94840
94841
94842
94843
94844
94845
94846
94847
94848
94849
94850
94851
94852
94853
94854
94855
94856
94857
94858
94859
94860
94861
94862
94863
94864
94865
94866
94867
94868
94869
94870
94871
94872
94873
94874
94875
94876
94877
94878
94879
94880
94881
94882
94883
94884
94885
94886
94887
94888
94889
94890
94891
94892
94893
94894
94895
94896
94897
94898
94899
94900
94901
94902
94903
94904
94905
94906
94907
94908
94909
94910
94911
94912
94913
94914
94915
94916
94917
94918
94919
94920
94921
94922
94923
94924
94925
94926
94927
94928
94929
94930
94931
94932
94933
94934
94935
94936
94937
94938
94939
94940
94941
94942
94943
94944
94945
94946
94947
94948
94949
94950
94951
94952
94953
94954
94955
94956
94957
94958
94959
94960
94961
94962
94963
94964
94965
94966
94967
94968
94969
94970
94971
94972
94973
94974
94975
94976
94977
94978
94979
94980
94981
94982
94983
94984
94985
94986
94987
94988
94989
94990
94991
94992
94993
94994
94995
94996
94997
94998
94999
95000
95001
95002
95003
95004
95005
95006
95007
95008
95009
95010
95011
95012
95013
95014
95015
95016
95017
95018
95019
95020
95021
95022
95023
95024
95025
95026
95027
95028
95029
95030
95031
95032
95033
95034
95035
95036
95037
95038
95039
95040
95041
95042
95043
95044
95045
95046
95047
95048
95049
95050
95051
95052
95053
95054
95055
95056
95057
95058
95059
95060
95061
95062
95063
95064
95065
95066
95067
95068
95069
95070
95071
95072
95073
95074
95075
95076
95077
95078
95079
95080
95081
95082
95083
95084
95085
95086
95087
95088
95089
95090
95091
95092
95093
95094
95095
95096
95097
95098
95099
95100
95101
95102
95103
95104
95105
95106
95107
95108
95109
95110
95111
95112
95113
95114
95115
95116
95117
95118
95119
95120
95121
95122
95123
95124
95125
95126
95127
95128
95129
95130
95131
95132
95133
95134
95135
95136
95137
95138
95139
95140
95141
95142
95143
95144
95145
95146
95147
95148
95149
95150
95151
95152
95153
95154
95155
95156
95157
95158
95159
95160
95161
95162
95163
95164
95165
95166
95167
95168
95169
95170
95171
95172
95173
95174
95175
95176
95177
95178
95179
95180
95181
95182
95183
95184
95185
95186
95187
95188
95189
95190
95191
95192
95193
95194
95195
95196
95197
95198
95199
95200
95201
95202
95203
95204
95205
95206
95207
95208
95209
95210
95211
95212
95213
95214
95215
95216
95217
95218
95219
95220
95221
95222
95223
95224
95225
95226
95227
95228
95229
95230
95231
95232
95233
95234
95235
95236
95237
95238
95239
95240
95241
95242
95243
95244
95245
95246
95247
95248
95249
95250
95251
95252
95253
95254
95255
95256
95257
95258
95259
95260
95261
95262
95263
95264
95265
95266
95267
95268
95269
95270
95271
95272
95273
95274
95275
95276
95277
95278
95279
95280
95281
95282
95283
95284
95285
95286
95287
95288
95289
95290
95291
95292
95293
95294
95295
95296
95297
95298
95299
95300
95301
95302
95303
95304
95305
95306
95307
95308
95309
95310
95311
95312
95313
95314
95315
95316
95317
95318
95319
95320
95321
95322
95323
95324
95325
95326
95327
95328
95329
95330
95331
95332
95333
95334
95335
95336
95337
95338
95339
95340
95341
95342
95343
95344
95345
95346
95347
95348
95349
95350
95351
95352
95353
95354
95355
95356
95357
95358
95359
95360
95361
95362
95363
95364
95365
95366
95367
95368
95369
95370
95371
95372
95373
95374
95375
95376
95377
95378
95379
95380
95381
95382
95383
95384
95385
95386
95387
95388
95389
95390
95391
95392
95393
95394
95395
95396
95397
95398
95399
95400
95401
95402
95403
95404
95405
95406
95407
95408
95409
95410
95411
95412
95413
95414
95415
95416
95417
95418
95419
95420
95421
95422
95423
95424
95425
95426
95427
95428
95429
95430
95431
95432
95433
95434
95435
95436
95437
95438
95439
95440
95441
95442
95443
95444
95445
95446
95447
95448
95449
95450
95451
95452
95453
95454
95455
95456
95457
95458
95459
95460
95461
95462
95463
95464
95465
95466
95467
95468
95469
95470
95471
95472
95473
95474
95475
95476
95477
95478
95479
95480
95481
95482
95483
95484
95485
95486
95487
95488
95489
95490
95491
95492
95493
95494
95495
95496
95497
95498
95499
95500
95501
95502
95503
95504
95505
95506
95507
95508
95509
95510
95511
95512
95513
95514
95515
95516
95517
95518
95519
95520
95521
95522
95523
95524
95525
95526
95527
95528
95529
95530
95531
95532
95533
95534
95535
95536
95537
95538
95539
95540
95541
95542
95543
95544
95545
95546
95547
95548
95549
95550
95551
95552
95553
95554
95555
95556
95557
95558
95559
95560
95561
95562
95563
95564
95565
95566
95567
95568
95569
95570
95571
95572
95573
95574
95575
95576
95577
95578
95579
95580
95581
95582
95583
95584
95585
95586
95587
95588
95589
95590
95591
95592
95593
95594
95595
95596
95597
95598
95599
95600
95601
95602
95603
95604
95605
95606
95607
95608
95609
95610
95611
95612
95613
95614
95615
95616
95617
95618
95619
95620
95621
95622
95623
95624
95625
95626
95627
95628
95629
95630
95631
95632
95633
95634
95635
95636
95637
95638
95639
95640
95641
95642
95643
95644
95645
95646
95647
95648
95649
95650
95651
95652
95653
95654
95655
95656
95657
95658
95659
95660
95661
95662
95663
95664
95665
95666
95667
95668
95669
95670
95671
95672
95673
95674
95675
95676
95677
95678
95679
95680
95681
95682
95683
95684
95685
95686
95687
95688
95689
95690
95691
95692
95693
95694
95695
95696
95697
95698
95699
95700
95701
95702
95703
95704
95705
95706
95707
95708
95709
95710
95711
95712
95713
95714
95715
95716
95717
95718
95719
95720
95721
95722
95723
95724
95725
95726
95727
95728
95729
95730
95731
95732
95733
95734
95735
95736
95737
95738
95739
95740
95741
95742
95743
95744
95745
95746
95747
95748
95749
95750
95751
95752
95753
95754
95755
95756
95757
95758
95759
95760
95761
95762
95763
95764
95765
95766
95767
95768
95769
95770
95771
95772
95773
95774
95775
95776
95777
95778
95779
95780
95781
95782
95783
95784
95785
95786
95787
95788
95789
95790
95791
95792
95793
95794
95795
95796
95797
95798
95799
95800
95801
95802
95803
95804
95805
95806
95807
95808
95809
95810
95811
95812
95813
95814
95815
95816
95817
95818
95819
95820
95821
95822
95823
95824
95825
95826
95827
95828
95829
95830
95831
95832
95833
95834
95835
95836
95837
95838
95839
95840
95841
95842
95843
95844
95845
95846
95847
95848
95849
95850
95851
95852
95853
95854
95855
95856
95857
95858
95859
95860
95861
95862
95863
95864
95865
95866
95867
95868
95869
95870
95871
95872
95873
95874
95875
95876
95877
95878
95879
95880
95881
95882
95883
95884
95885
95886
95887
95888
95889
95890
95891
95892
95893
95894
95895
95896
95897
95898
95899
95900
95901
95902
95903
95904
95905
95906
95907
95908
95909
95910
95911
95912
95913
95914
95915
95916
95917
95918
95919
95920
95921
95922
95923
95924
95925
95926
95927
95928
95929
95930
95931
95932
95933
95934
95935
95936
95937
95938
95939
95940
95941
95942
95943
95944
95945
95946
95947
95948
95949
95950
95951
95952
95953
95954
95955
95956
95957
95958
95959
95960
95961
95962
95963
95964
95965
95966
95967
95968
95969
95970
95971
95972
95973
95974
95975
95976
95977
95978
95979
95980
95981
95982
95983
95984
95985
95986
95987
95988
95989
95990
95991
95992
95993
95994
95995
95996
95997
95998
95999
96000
96001
96002
96003
96004
96005
96006
96007
96008
96009
96010
96011
96012
96013
96014
96015
96016
96017
96018
96019
96020
96021
96022
96023
96024
96025
96026
96027
96028
96029
96030
96031
96032
96033
96034
96035
96036
96037
96038
96039
96040
96041
96042
96043
96044
96045
96046
96047
96048
96049
96050
96051
96052
96053
96054
96055
96056
96057
96058
96059
96060
96061
96062
96063
96064
96065
96066
96067
96068
96069
96070
96071
96072
96073
96074
96075
96076
96077
96078
96079
96080
96081
96082
96083
96084
96085
96086
96087
96088
96089
96090
96091
96092
96093
96094
96095
96096
96097
96098
96099
96100
96101
96102
96103
96104
96105
96106
96107
96108
96109
96110
96111
96112
96113
96114
96115
96116
96117
96118
96119
96120
96121
96122
96123
96124
96125
96126
96127
96128
96129
96130
96131
96132
96133
96134
96135
96136
96137
96138
96139
96140
96141
96142
96143
96144
96145
96146
96147
96148
96149
96150
96151
96152
96153
96154
96155
96156
96157
96158
96159
96160
96161
96162
96163
96164
96165
96166
96167
96168
96169
96170
96171
96172
96173
96174
96175
96176
96177
96178
96179
96180
96181
96182
96183
96184
96185
96186
96187
96188
96189
96190
96191
96192
96193
96194
96195
96196
96197
96198
96199
96200
96201
96202
96203
96204
96205
96206
96207
96208
96209
96210
96211
96212
96213
96214
96215
96216
96217
96218
96219
96220
96221
96222
96223
96224
96225
96226
96227
96228
96229
96230
96231
96232
96233
96234
96235
96236
96237
96238
96239
96240
96241
96242
96243
96244
96245
96246
96247
96248
96249
96250
96251
96252
96253
96254
96255
96256
96257
96258
96259
96260
96261
96262
96263
96264
96265
96266
96267
96268
96269
96270
96271
96272
96273
96274
96275
96276
96277
96278
96279
96280
96281
96282
96283
96284
96285
96286
96287
96288
96289
96290
96291
96292
96293
96294
96295
96296
96297
96298
96299
96300
96301
96302
96303
96304
96305
96306
96307
96308
96309
96310
96311
96312
96313
96314
96315
96316
96317
96318
96319
96320
96321
96322
96323
96324
96325
96326
96327
96328
96329
96330
96331
96332
96333
96334
96335
96336
96337
96338
96339
96340
96341
96342
96343
96344
96345
96346
96347
96348
96349
96350
96351
96352
96353
96354
96355
96356
96357
96358
96359
96360
96361
96362
96363
96364
96365
96366
96367
96368
96369
96370
96371
96372
96373
96374
96375
96376
96377
96378
96379
96380
96381
96382
96383
96384
96385
96386
96387
96388
96389
96390
96391
96392
96393
96394
96395
96396
96397
96398
96399
96400
96401
96402
96403
96404
96405
96406
96407
96408
96409
96410
96411
96412
96413
96414
96415
96416
96417
96418
96419
96420
96421
96422
96423
96424
96425
96426
96427
96428
96429
96430
96431
96432
96433
96434
96435
96436
96437
96438
96439
96440
96441
96442
96443
96444
96445
96446
96447
96448
96449
96450
96451
96452
96453
96454
96455
96456
96457
96458
96459
96460
96461
96462
96463
96464
96465
96466
96467
96468
96469
96470
96471
96472
96473
96474
96475
96476
96477
96478
96479
96480
96481
96482
96483
96484
96485
96486
96487
96488
96489
96490
96491
96492
96493
96494
96495
96496
96497
96498
96499
96500
96501
96502
96503
96504
96505
96506
96507
96508
96509
96510
96511
96512
96513
96514
96515
96516
96517
96518
96519
96520
96521
96522
96523
96524
96525
96526
96527
96528
96529
96530
96531
96532
96533
96534
96535
96536
96537
96538
96539
96540
96541
96542
96543
96544
96545
96546
96547
96548
96549
96550
96551
96552
96553
96554
96555
96556
96557
96558
96559
96560
96561
96562
96563
96564
96565
96566
96567
96568
96569
96570
96571
96572
96573
96574
96575
96576
96577
96578
96579
96580
96581
96582
96583
96584
96585
96586
96587
96588
96589
96590
96591
96592
96593
96594
96595
96596
96597
96598
96599
96600
96601
96602
96603
96604
96605
96606
96607
96608
96609
96610
96611
96612
96613
96614
96615
96616
96617
96618
96619
96620
96621
96622
96623
96624
96625
96626
96627
96628
96629
96630
96631
96632
96633
96634
96635
96636
96637
96638
96639
96640
96641
96642
96643
96644
96645
96646
96647
96648
96649
96650
96651
96652
96653
96654
96655
96656
96657
96658
96659
96660
96661
96662
96663
96664
96665
96666
96667
96668
96669
96670
96671
96672
96673
96674
96675
96676
96677
96678
96679
96680
96681
96682
96683
96684
96685
96686
96687
96688
96689
96690
96691
96692
96693
96694
96695
96696
96697
96698
96699
96700
96701
96702
96703
96704
96705
96706
96707
96708
96709
96710
96711
96712
96713
96714
96715
96716
96717
96718
96719
96720
96721
96722
96723
96724
96725
96726
96727
96728
96729
96730
96731
96732
96733
96734
96735
96736
96737
96738
96739
96740
96741
96742
96743
96744
96745
96746
96747
96748
96749
96750
96751
96752
96753
96754
96755
96756
96757
96758
96759
96760
96761
96762
96763
96764
96765
96766
96767
96768
96769
96770
96771
96772
96773
96774
96775
96776
96777
96778
96779
96780
96781
96782
96783
96784
96785
96786
96787
96788
96789
96790
96791
96792
96793
96794
96795
96796
96797
96798
96799
96800
96801
96802
96803
96804
96805
96806
96807
96808
96809
96810
96811
96812
96813
96814
96815
96816
96817
96818
96819
96820
96821
96822
96823
96824
96825
96826
96827
96828
96829
96830
96831
96832
96833
96834
96835
96836
96837
96838
96839
96840
96841
96842
96843
96844
96845
96846
96847
96848
96849
96850
96851
96852
96853
96854
96855
96856
96857
96858
96859
96860
96861
96862
96863
96864
96865
96866
96867
96868
96869
96870
96871
96872
96873
96874
96875
96876
96877
96878
96879
96880
96881
96882
96883
96884
96885
96886
96887
96888
96889
96890
96891
96892
96893
96894
96895
96896
96897
96898
96899
96900
96901
96902
96903
96904
96905
96906
96907
96908
96909
96910
96911
96912
96913
96914
96915
96916
96917
96918
96919
96920
96921
96922
96923
96924
96925
96926
96927
96928
96929
96930
96931
96932
96933
96934
96935
96936
96937
96938
96939
96940
96941
96942
96943
96944
96945
96946
96947
96948
96949
96950
96951
96952
96953
96954
96955
96956
96957
96958
96959
96960
96961
96962
96963
96964
96965
96966
96967
96968
96969
96970
96971
96972
96973
96974
96975
96976
96977
96978
96979
96980
96981
96982
96983
96984
96985
96986
96987
96988
96989
96990
96991
96992
96993
96994
96995
96996
96997
96998
96999
97000
97001
97002
97003
97004
97005
97006
97007
97008
97009
97010
97011
97012
97013
97014
97015
97016
97017
97018
97019
97020
97021
97022
97023
97024
97025
97026
97027
97028
97029
97030
97031
97032
97033
97034
97035
97036
97037
97038
97039
97040
97041
97042
97043
97044
97045
97046
97047
97048
97049
97050
97051
97052
97053
97054
97055
97056
97057
97058
97059
97060
97061
97062
97063
97064
97065
97066
97067
97068
97069
97070
97071
97072
97073
97074
97075
97076
97077
97078
97079
97080
97081
97082
97083
97084
97085
97086
97087
97088
97089
97090
97091
97092
97093
97094
97095
97096
97097
97098
97099
97100
97101
97102
97103
97104
97105
97106
97107
97108
97109
97110
97111
97112
97113
97114
97115
97116
97117
97118
97119
97120
97121
97122
97123
97124
97125
97126
97127
97128
97129
97130
97131
97132
97133
97134
97135
97136
97137
97138
97139
97140
97141
97142
97143
97144
97145
97146
97147
97148
97149
97150
97151
97152
97153
97154
97155
97156
97157
97158
97159
97160
97161
97162
97163
97164
97165
97166
97167
97168
97169
97170
97171
97172
97173
97174
97175
97176
97177
97178
97179
97180
97181
97182
97183
97184
97185
97186
97187
97188
97189
97190
97191
97192
97193
97194
97195
97196
97197
97198
97199
97200
97201
97202
97203
97204
97205
97206
97207
97208
97209
97210
97211
97212
97213
97214
97215
97216
97217
97218
97219
97220
97221
97222
97223
97224
97225
97226
97227
97228
97229
97230
97231
97232
97233
97234
97235
97236
97237
97238
97239
97240
97241
97242
97243
97244
97245
97246
97247
97248
97249
97250
97251
97252
97253
97254
97255
97256
97257
97258
97259
97260
97261
97262
97263
97264
97265
97266
97267
97268
97269
97270
97271
97272
97273
97274
97275
97276
97277
97278
97279
97280
97281
97282
97283
97284
97285
97286
97287
97288
97289
97290
97291
97292
97293
97294
97295
97296
97297
97298
97299
97300
97301
97302
97303
97304
97305
97306
97307
97308
97309
97310
97311
97312
97313
97314
97315
97316
97317
97318
97319
97320
97321
97322
97323
97324
97325
97326
97327
97328
97329
97330
97331
97332
97333
97334
97335
97336
97337
97338
97339
97340
97341
97342
97343
97344
97345
97346
97347
97348
97349
97350
97351
97352
97353
97354
97355
97356
97357
97358
97359
97360
97361
97362
97363
97364
97365
97366
97367
97368
97369
97370
97371
97372
97373
97374
97375
97376
97377
97378
97379
97380
97381
97382
97383
97384
97385
97386
97387
97388
97389
97390
97391
97392
97393
97394
97395
97396
97397
97398
97399
97400
97401
97402
97403
97404
97405
97406
97407
97408
97409
97410
97411
97412
97413
97414
97415
97416
97417
97418
97419
97420
97421
97422
97423
97424
97425
97426
97427
97428
97429
97430
97431
97432
97433
97434
97435
97436
97437
97438
97439
97440
97441
97442
97443
97444
97445
97446
97447
97448
97449
97450
97451
97452
97453
97454
97455
97456
97457
97458
97459
97460
97461
97462
97463
97464
97465
97466
97467
97468
97469
97470
97471
97472
97473
97474
97475
97476
97477
97478
97479
97480
97481
97482
97483
97484
97485
97486
97487
97488
97489
97490
97491
97492
97493
97494
97495
97496
97497
97498
97499
97500
97501
97502
97503
97504
97505
97506
97507
97508
97509
97510
97511
97512
97513
97514
97515
97516
97517
97518
97519
97520
97521
97522
97523
97524
97525
97526
97527
97528
97529
97530
97531
97532
97533
97534
97535
97536
97537
97538
97539
97540
97541
97542
97543
97544
97545
97546
97547
97548
97549
97550
97551
97552
97553
97554
97555
97556
97557
97558
97559
97560
97561
97562
97563
97564
97565
97566
97567
97568
97569
97570
97571
97572
97573
97574
97575
97576
97577
97578
97579
97580
97581
97582
97583
97584
97585
97586
97587
97588
97589
97590
97591
97592
97593
97594
97595
97596
97597
97598
97599
97600
97601
97602
97603
97604
97605
97606
97607
97608
97609
97610
97611
97612
97613
97614
97615
97616
97617
97618
97619
97620
97621
97622
97623
97624
97625
97626
97627
97628
97629
97630
97631
97632
97633
97634
97635
97636
97637
97638
97639
97640
97641
97642
97643
97644
97645
97646
97647
97648
97649
97650
97651
97652
97653
97654
97655
97656
97657
97658
97659
97660
97661
97662
97663
97664
97665
97666
97667
97668
97669
97670
97671
97672
97673
97674
97675
97676
97677
97678
97679
97680
97681
97682
97683
97684
97685
97686
97687
97688
97689
97690
97691
97692
97693
97694
97695
97696
97697
97698
97699
97700
97701
97702
97703
97704
97705
97706
97707
97708
97709
97710
97711
97712
97713
97714
97715
97716
97717
97718
97719
97720
97721
97722
97723
97724
97725
97726
97727
97728
97729
97730
97731
97732
97733
97734
97735
97736
97737
97738
97739
97740
97741
97742
97743
97744
97745
97746
97747
97748
97749
97750
97751
97752
97753
97754
97755
97756
97757
97758
97759
97760
97761
97762
97763
97764
97765
97766
97767
97768
97769
97770
97771
97772
97773
97774
97775
97776
97777
97778
97779
97780
97781
97782
97783
97784
97785
97786
97787
97788
97789
97790
97791
97792
97793
97794
97795
97796
97797
97798
97799
97800
97801
97802
97803
97804
97805
97806
97807
97808
97809
97810
97811
97812
97813
97814
97815
97816
97817
97818
97819
97820
97821
97822
97823
97824
97825
97826
97827
97828
97829
97830
97831
97832
97833
97834
97835
97836
97837
97838
97839
97840
97841
97842
97843
97844
97845
97846
97847
97848
97849
97850
97851
97852
97853
97854
97855
97856
97857
97858
97859
97860
97861
97862
97863
97864
97865
97866
97867
97868
97869
97870
97871
97872
97873
97874
97875
97876
97877
97878
97879
97880
97881
97882
97883
97884
97885
97886
97887
97888
97889
97890
97891
97892
97893
97894
97895
97896
97897
97898
97899
97900
97901
97902
97903
97904
97905
97906
97907
97908
97909
97910
97911
97912
97913
97914
97915
97916
97917
97918
97919
97920
97921
97922
97923
97924
97925
97926
97927
97928
97929
97930
97931
97932
97933
97934
97935
97936
97937
97938
97939
97940
97941
97942
97943
97944
97945
97946
97947
97948
97949
97950
97951
97952
97953
97954
97955
97956
97957
97958
97959
97960
97961
97962
97963
97964
97965
97966
97967
97968
97969
97970
97971
97972
97973
97974
97975
97976
97977
97978
97979
97980
97981
97982
97983
97984
97985
97986
97987
97988
97989
97990
97991
97992
97993
97994
97995
97996
97997
97998
97999
98000
98001
98002
98003
98004
98005
98006
98007
98008
98009
98010
98011
98012
98013
98014
98015
98016
98017
98018
98019
98020
98021
98022
98023
98024
98025
98026
98027
98028
98029
98030
98031
98032
98033
98034
98035
98036
98037
98038
98039
98040
98041
98042
98043
98044
98045
98046
98047
98048
98049
98050
98051
98052
98053
98054
98055
98056
98057
98058
98059
98060
98061
98062
98063
98064
98065
98066
98067
98068
98069
98070
98071
98072
98073
98074
98075
98076
98077
98078
98079
98080
98081
98082
98083
98084
98085
98086
98087
98088
98089
98090
98091
98092
98093
98094
98095
98096
98097
98098
98099
98100
98101
98102
98103
98104
98105
98106
98107
98108
98109
98110
98111
98112
98113
98114
98115
98116
98117
98118
98119
98120
98121
98122
98123
98124
98125
98126
98127
98128
98129
98130
98131
98132
98133
98134
98135
98136
98137
98138
98139
98140
98141
98142
98143
98144
98145
98146
98147
98148
98149
98150
98151
98152
98153
98154
98155
98156
98157
98158
98159
98160
98161
98162
98163
98164
98165
98166
98167
98168
98169
98170
98171
98172
98173
98174
98175
98176
98177
98178
98179
98180
98181
98182
98183
98184
98185
98186
98187
98188
98189
98190
98191
98192
98193
98194
98195
98196
98197
98198
98199
98200
98201
98202
98203
98204
98205
98206
98207
98208
98209
98210
98211
98212
98213
98214
98215
98216
98217
98218
98219
98220
98221
98222
98223
98224
98225
98226
98227
98228
98229
98230
98231
98232
98233
98234
98235
98236
98237
98238
98239
98240
98241
98242
98243
98244
98245
98246
98247
98248
98249
98250
98251
98252
98253
98254
98255
98256
98257
98258
98259
98260
98261
98262
98263
98264
98265
98266
98267
98268
98269
98270
98271
98272
98273
98274
98275
98276
98277
98278
98279
98280
98281
98282
98283
98284
98285
98286
98287
98288
98289
98290
98291
98292
98293
98294
98295
98296
98297
98298
98299
98300
98301
98302
98303
98304
98305
98306
98307
98308
98309
98310
98311
98312
98313
98314
98315
98316
98317
98318
98319
98320
98321
98322
98323
98324
98325
98326
98327
98328
98329
98330
98331
98332
98333
98334
98335
98336
98337
98338
98339
98340
98341
98342
98343
98344
98345
98346
98347
98348
98349
98350
98351
98352
98353
98354
98355
98356
98357
98358
98359
98360
98361
98362
98363
98364
98365
98366
98367
98368
98369
98370
98371
98372
98373
98374
98375
98376
98377
98378
98379
98380
98381
98382
98383
98384
98385
98386
98387
98388
98389
98390
98391
98392
98393
98394
98395
98396
98397
98398
98399
98400
98401
98402
98403
98404
98405
98406
98407
98408
98409
98410
98411
98412
98413
98414
98415
98416
98417
98418
98419
98420
98421
98422
98423
98424
98425
98426
98427
98428
98429
98430
98431
98432
98433
98434
98435
98436
98437
98438
98439
98440
98441
98442
98443
98444
98445
98446
98447
98448
98449
98450
98451
98452
98453
98454
98455
98456
98457
98458
98459
98460
98461
98462
98463
98464
98465
98466
98467
98468
98469
98470
98471
98472
98473
98474
98475
98476
98477
98478
98479
98480
98481
98482
98483
98484
98485
98486
98487
98488
98489
98490
98491
98492
98493
98494
98495
98496
98497
98498
98499
98500
98501
98502
98503
98504
98505
98506
98507
98508
98509
98510
98511
98512
98513
98514
98515
98516
98517
98518
98519
98520
98521
98522
98523
98524
98525
98526
98527
98528
98529
98530
98531
98532
98533
98534
98535
98536
98537
98538
98539
98540
98541
98542
98543
98544
98545
98546
98547
98548
98549
98550
98551
98552
98553
98554
98555
98556
98557
98558
98559
98560
98561
98562
98563
98564
98565
98566
98567
98568
98569
98570
98571
98572
98573
98574
98575
98576
98577
98578
98579
98580
98581
98582
98583
98584
98585
98586
98587
98588
98589
98590
98591
98592
98593
98594
98595
98596
98597
98598
98599
98600
98601
98602
98603
98604
98605
98606
98607
98608
98609
98610
98611
98612
98613
98614
98615
98616
98617
98618
98619
98620
98621
98622
98623
98624
98625
98626
98627
98628
98629
98630
98631
98632
98633
98634
98635
98636
98637
98638
98639
98640
98641
98642
98643
98644
98645
98646
98647
98648
98649
98650
98651
98652
98653
98654
98655
98656
98657
98658
98659
98660
98661
98662
98663
98664
98665
98666
98667
98668
98669
98670
98671
98672
98673
98674
98675
98676
98677
98678
98679
98680
98681
98682
98683
98684
98685
98686
98687
98688
98689
98690
98691
98692
98693
98694
98695
98696
98697
98698
98699
98700
98701
98702
98703
98704
98705
98706
98707
98708
98709
98710
98711
98712
98713
98714
98715
98716
98717
98718
98719
98720
98721
98722
98723
98724
98725
98726
98727
98728
98729
98730
98731
98732
98733
98734
98735
98736
98737
98738
98739
98740
98741
98742
98743
98744
98745
98746
98747
98748
98749
98750
98751
98752
98753
98754
98755
98756
98757
98758
98759
98760
98761
98762
98763
98764
98765
98766
98767
98768
98769
98770
98771
98772
98773
98774
98775
98776
98777
98778
98779
98780
98781
98782
98783
98784
98785
98786
98787
98788
98789
98790
98791
98792
98793
98794
98795
98796
98797
98798
98799
98800
98801
98802
98803
98804
98805
98806
98807
98808
98809
98810
98811
98812
98813
98814
98815
98816
98817
98818
98819
98820
98821
98822
98823
98824
98825
98826
98827
98828
98829
98830
98831
98832
98833
98834
98835
98836
98837
98838
98839
98840
98841
98842
98843
98844
98845
98846
98847
98848
98849
98850
98851
98852
98853
98854
98855
98856
98857
98858
98859
98860
98861
98862
98863
98864
98865
98866
98867
98868
98869
98870
98871
98872
98873
98874
98875
98876
98877
98878
98879
98880
98881
98882
98883
98884
98885
98886
98887
98888
98889
98890
98891
98892
98893
98894
98895
98896
98897
98898
98899
98900
98901
98902
98903
98904
98905
98906
98907
98908
98909
98910
98911
98912
98913
98914
98915
98916
98917
98918
98919
98920
98921
98922
98923
98924
98925
98926
98927
98928
98929
98930
98931
98932
98933
98934
98935
98936
98937
98938
98939
98940
98941
98942
98943
98944
98945
98946
98947
98948
98949
98950
98951
98952
98953
98954
98955
98956
98957
98958
98959
98960
98961
98962
98963
98964
98965
98966
98967
98968
98969
98970
98971
98972
98973
98974
98975
98976
98977
98978
98979
98980
98981
98982
98983
98984
98985
98986
98987
98988
98989
98990
98991
98992
98993
98994
98995
98996
98997
98998
98999
99000
99001
99002
99003
99004
99005
99006
99007
99008
99009
99010
99011
99012
99013
99014
99015
99016
99017
99018
99019
99020
99021
99022
99023
99024
99025
99026
99027
99028
99029
99030
99031
99032
99033
99034
99035
99036
99037
99038
99039
99040
99041
99042
99043
99044
99045
99046
99047
99048
99049
99050
99051
99052
99053
99054
99055
99056
99057
99058
99059
99060
99061
99062
99063
99064
99065
99066
99067
99068
99069
99070
99071
99072
99073
99074
99075
99076
99077
99078
99079
99080
99081
99082
99083
99084
99085
99086
99087
99088
99089
99090
99091
99092
99093
99094
99095
99096
99097
99098
99099
99100
99101
99102
99103
99104
99105
99106
99107
99108
99109
99110
99111
99112
99113
99114
99115
99116
99117
99118
99119
99120
99121
99122
99123
99124
99125
99126
99127
99128
99129
99130
99131
99132
99133
99134
99135
99136
99137
99138
99139
99140
99141
99142
99143
99144
99145
99146
99147
99148
99149
99150
99151
99152
99153
99154
99155
99156
99157
99158
99159
99160
99161
99162
99163
99164
99165
99166
99167
99168
99169
99170
99171
99172
99173
99174
99175
99176
99177
99178
99179
99180
99181
99182
99183
99184
99185
99186
99187
99188
99189
99190
99191
99192
99193
99194
99195
99196
99197
99198
99199
99200
99201
99202
99203
99204
99205
99206
99207
99208
99209
99210
99211
99212
99213
99214
99215
99216
99217
99218
99219
99220
99221
99222
99223
99224
99225
99226
99227
99228
99229
99230
99231
99232
99233
99234
99235
99236
99237
99238
99239
99240
99241
99242
99243
99244
99245
99246
99247
99248
99249
99250
99251
99252
99253
99254
99255
99256
99257
99258
99259
99260
99261
99262
99263
99264
99265
99266
99267
99268
99269
99270
99271
99272
99273
99274
99275
99276
99277
99278
99279
99280
99281
99282
99283
99284
99285
99286
99287
99288
99289
99290
99291
99292
99293
99294
99295
99296
99297
99298
99299
99300
99301
99302
99303
99304
99305
99306
99307
99308
99309
99310
99311
99312
99313
99314
99315
99316
99317
99318
99319
99320
99321
99322
99323
99324
99325
99326
99327
99328
99329
99330
99331
99332
99333
99334
99335
99336
99337
99338
99339
99340
99341
99342
99343
99344
99345
99346
99347
99348
99349
99350
99351
99352
99353
99354
99355
99356
99357
99358
99359
99360
99361
99362
99363
99364
99365
99366
99367
99368
99369
99370
99371
99372
99373
99374
99375
99376
99377
99378
99379
99380
99381
99382
99383
99384
99385
99386
99387
99388
99389
99390
99391
99392
99393
99394
99395
99396
99397
99398
99399
99400
99401
99402
99403
99404
99405
99406
99407
99408
99409
99410
99411
99412
99413
99414
99415
99416
99417
99418
99419
99420
99421
99422
99423
99424
99425
99426
99427
99428
99429
99430
99431
99432
99433
99434
99435
99436
99437
99438
99439
99440
99441
99442
99443
99444
99445
99446
99447
99448
99449
99450
99451
99452
99453
99454
99455
99456
99457
99458
99459
99460
99461
99462
99463
99464
99465
99466
99467
99468
99469
99470
99471
99472
99473
99474
99475
99476
99477
99478
99479
99480
99481
99482
99483
99484
99485
99486
99487
99488
99489
99490
99491
99492
99493
99494
99495
99496
99497
99498
99499
99500
99501
99502
99503
99504
99505
99506
99507
99508
99509
99510
99511
99512
99513
99514
99515
99516
99517
99518
99519
99520
99521
99522
99523
99524
99525
99526
99527
99528
99529
99530
99531
99532
99533
99534
99535
99536
99537
99538
99539
99540
99541
99542
99543
99544
99545
99546
99547
99548
99549
99550
99551
99552
99553
99554
99555
99556
99557
99558
99559
99560
99561
99562
99563
99564
99565
99566
99567
99568
99569
99570
99571
99572
99573
99574
99575
99576
99577
99578
99579
99580
99581
99582
99583
99584
99585
99586
99587
99588
99589
99590
99591
99592
99593
99594
99595
99596
99597
99598
99599
99600
99601
99602
99603
99604
99605
99606
99607
99608
99609
99610
99611
99612
99613
99614
99615
99616
99617
99618
99619
99620
99621
99622
99623
99624
99625
99626
99627
99628
99629
99630
99631
99632
99633
99634
99635
99636
99637
99638
99639
99640
99641
99642
99643
99644
99645
99646
99647
99648
99649
99650
99651
99652
99653
99654
99655
99656
99657
99658
99659
99660
99661
99662
99663
99664
99665
99666
99667
99668
99669
99670
99671
99672
99673
99674
99675
99676
99677
99678
99679
99680
99681
99682
99683
99684
99685
99686
99687
99688
99689
99690
99691
99692
99693
99694
99695
99696
99697
99698
99699
99700
99701
99702
99703
99704
99705
99706
99707
99708
99709
99710
99711
99712
99713
99714
99715
99716
99717
99718
99719
99720
99721
99722
99723
99724
99725
99726
99727
99728
99729
99730
99731
99732
99733
99734
99735
99736
99737
99738
99739
99740
99741
99742
99743
99744
99745
99746
99747
99748
99749
99750
99751
99752
99753
99754
99755
99756
99757
99758
99759
99760
99761
99762
99763
99764
99765
99766
99767
99768
99769
99770
99771
99772
99773
99774
99775
99776
99777
99778
99779
99780
99781
99782
99783
99784
99785
99786
99787
99788
99789
99790
99791
99792
99793
99794
99795
99796
99797
99798
99799
99800
99801
99802
99803
99804
99805
99806
99807
99808
99809
99810
99811
99812
99813
99814
99815
99816
99817
99818
99819
99820
99821
99822
99823
99824
99825
99826
99827
99828
99829
99830
99831
99832
99833
99834
99835
99836
99837
99838
99839
99840
99841
99842
99843
99844
99845
99846
99847
99848
99849
99850
99851
99852
99853
99854
99855
99856
99857
99858
99859
99860
99861
99862
99863
99864
99865
99866
99867
99868
99869
99870
99871
99872
99873
99874
99875
99876
99877
99878
99879
99880
99881
99882
99883
99884
99885
99886
99887
99888
99889
99890
99891
99892
99893
99894
99895
99896
99897
99898
99899
99900
99901
99902
99903
99904
99905
99906
99907
99908
99909
99910
99911
99912
99913
99914
99915
99916
99917
99918
99919
99920
99921
99922
99923
99924
99925
99926
99927
99928
99929
99930
99931
99932
99933
99934
99935
99936
99937
99938
99939
99940
99941
99942
99943
99944
99945
99946
99947
99948
99949
99950
99951
99952
99953
99954
99955
99956
99957
99958
99959
99960
99961
99962
99963
99964
99965
99966
99967
99968
99969
99970
99971
99972
99973
99974
99975
99976
99977
99978
99979
99980
99981
99982
99983
99984
99985
99986
99987
99988
99989
99990
99991
99992
99993
99994
99995
99996
99997
99998
99999
100000
100001
100002
100003
100004
100005
100006
100007
100008
100009
100010
100011
100012
100013
100014
100015
100016
100017
100018
100019
100020
100021
100022
100023
100024
100025
100026
100027
100028
100029
100030
100031
100032
100033
100034
100035
100036
100037
100038
100039
100040
100041
100042
100043
100044
100045
100046
100047
100048
100049
100050
100051
100052
100053
100054
100055
100056
100057
100058
100059
100060
100061
100062
100063
100064
100065
100066
100067
100068
100069
100070
100071
100072
100073
100074
100075
100076
100077
100078
100079
100080
100081
100082
100083
100084
100085
100086
100087
100088
100089
100090
100091
100092
100093
100094
100095
100096
100097
100098
100099
100100
100101
100102
100103
100104
100105
100106
100107
100108
100109
100110
100111
100112
100113
100114
100115
100116
100117
100118
100119
100120
100121
100122
100123
100124
100125
100126
100127
100128
100129
100130
100131
100132
100133
100134
100135
100136
100137
100138
100139
100140
100141
100142
100143
100144
100145
100146
100147
100148
100149
100150
100151
100152
100153
100154
100155
100156
100157
100158
100159
100160
100161
100162
100163
100164
100165
100166
100167
100168
100169
100170
100171
100172
100173
100174
100175
100176
100177
100178
100179
100180
100181
100182
100183
100184
100185
100186
100187
100188
100189
100190
100191
100192
100193
100194
100195
100196
100197
100198
100199
100200
100201
100202
100203
100204
100205
100206
100207
100208
100209
100210
100211
100212
100213
100214
100215
100216
100217
100218
100219
100220
100221
100222
100223
100224
100225
100226
100227
100228
100229
100230
100231
100232
100233
100234
100235
100236
100237
100238
100239
100240
100241
100242
100243
100244
100245
100246
100247
100248
100249
100250
100251
100252
100253
100254
100255
100256
100257
100258
100259
100260
100261
100262
100263
100264
100265
100266
100267
100268
100269
100270
100271
100272
100273
100274
100275
100276
100277
100278
100279
100280
100281
100282
100283
100284
100285
100286
100287
100288
100289
100290
100291
100292
100293
100294
100295
100296
100297
100298
100299
100300
100301
100302
100303
100304
100305
100306
100307
100308
100309
100310
100311
100312
100313
100314
100315
100316
100317
100318
100319
100320
100321
100322
100323
100324
100325
100326
100327
100328
100329
100330
100331
100332
100333
100334
100335
100336
100337
100338
100339
100340
100341
100342
100343
100344
100345
100346
100347
100348
100349
100350
100351
100352
100353
100354
100355
100356
100357
100358
100359
100360
100361
100362
100363
100364
100365
100366
100367
100368
100369
100370
100371
100372
100373
100374
100375
100376
100377
100378
100379
100380
100381
100382
100383
100384
100385
100386
100387
100388
100389
100390
100391
100392
100393
100394
100395
100396
100397
100398
100399
100400
100401
100402
100403
100404
100405
100406
100407
100408
100409
100410
100411
100412
100413
100414
100415
100416
100417
100418
100419
100420
100421
100422
100423
100424
100425
100426
100427
100428
100429
100430
100431
100432
100433
100434
100435
100436
100437
100438
100439
100440
100441
100442
100443
100444
100445
100446
100447
100448
100449
100450
100451
100452
100453
100454
100455
100456
100457
100458
100459
100460
100461
100462
100463
100464
100465
100466
100467
100468
100469
100470
100471
100472
100473
100474
100475
100476
100477
100478
100479
100480
100481
100482
100483
100484
100485
100486
100487
100488
100489
100490
100491
100492
100493
100494
100495
100496
100497
100498
100499
100500
100501
100502
100503
100504
100505
100506
100507
100508
100509
100510
100511
100512
100513
100514
100515
100516
100517
100518
100519
100520
100521
100522
100523
100524
100525
100526
100527
100528
100529
100530
100531
100532
100533
100534
100535
100536
100537
100538
100539
100540
100541
100542
100543
100544
100545
100546
100547
100548
100549
100550
100551
100552
100553
100554
100555
100556
100557
100558
100559
100560
100561
100562
100563
100564
100565
100566
100567
100568
100569
100570
100571
100572
100573
100574
100575
100576
100577
100578
100579
100580
100581
100582
100583
100584
100585
100586
100587
100588
100589
100590
100591
100592
100593
100594
100595
100596
100597
100598
100599
100600
100601
100602
100603
100604
100605
100606
100607
100608
100609
100610
100611
100612
100613
100614
100615
100616
100617
100618
100619
100620
100621
100622
100623
100624
100625
100626
100627
100628
100629
100630
100631
100632
100633
100634
100635
100636
100637
100638
100639
100640
100641
100642
100643
100644
100645
100646
100647
100648
100649
100650
100651
100652
100653
100654
100655
100656
100657
100658
100659
100660
100661
100662
100663
100664
100665
100666
100667
100668
100669
100670
100671
100672
100673
100674
100675
100676
100677
100678
100679
100680
100681
100682
100683
100684
100685
100686
100687
100688
100689
100690
100691
100692
100693
100694
100695
100696
100697
100698
100699
100700
100701
100702
100703
100704
100705
100706
100707
100708
100709
100710
100711
100712
100713
100714
100715
100716
100717
100718
100719
100720
100721
100722
100723
100724
100725
100726
100727
100728
100729
100730
100731
100732
100733
100734
100735
100736
100737
100738
100739
100740
100741
100742
100743
100744
100745
100746
100747
100748
100749
100750
100751
100752
100753
100754
100755
100756
100757
100758
100759
100760
100761
100762
100763
100764
100765
100766
100767
100768
100769
100770
100771
100772
100773
100774
100775
100776
100777
100778
100779
100780
100781
100782
100783
100784
100785
100786
100787
100788
100789
100790
100791
100792
100793
100794
100795
100796
100797
100798
100799
100800
100801
100802
100803
100804
100805
100806
100807
100808
100809
100810
100811
100812
100813
100814
100815
100816
100817
100818
100819
100820
100821
100822
100823
100824
100825
100826
100827
100828
100829
100830
100831
100832
100833
100834
100835
100836
100837
100838
100839
100840
100841
100842
100843
100844
100845
100846
100847
100848
100849
100850
100851
100852
100853
100854
100855
100856
100857
100858
100859
100860
100861
100862
100863
100864
100865
100866
100867
100868
100869
100870
100871
100872
100873
100874
100875
100876
100877
100878
100879
100880
100881
100882
100883
100884
100885
100886
100887
100888
100889
100890
100891
100892
100893
100894
100895
100896
100897
100898
100899
100900
100901
100902
100903
100904
100905
100906
100907
100908
100909
100910
100911
100912
100913
100914
100915
100916
100917
100918
100919
100920
100921
100922
100923
100924
100925
100926
100927
100928
100929
100930
100931
100932
100933
100934
100935
100936
100937
100938
100939
100940
100941
100942
100943
100944
100945
100946
100947
100948
100949
100950
100951
100952
100953
100954
100955
100956
100957
100958
100959
100960
100961
100962
100963
100964
100965
100966
100967
100968
100969
100970
100971
100972
100973
100974
100975
100976
100977
100978
100979
100980
100981
100982
100983
100984
100985
100986
100987
100988
100989
100990
100991
100992
100993
100994
100995
100996
100997
100998
100999
101000
101001
101002
101003
101004
101005
101006
101007
101008
101009
101010
101011
101012
101013
101014
101015
101016
101017
101018
101019
101020
101021
101022
101023
101024
101025
101026
101027
101028
101029
101030
101031
101032
101033
101034
101035
101036
101037
101038
101039
101040
101041
101042
101043
101044
101045
101046
101047
101048
101049
101050
101051
101052
101053
101054
101055
101056
101057
101058
101059
101060
101061
101062
101063
101064
101065
101066
101067
101068
101069
101070
101071
101072
101073
101074
101075
101076
101077
101078
101079
101080
101081
101082
101083
101084
101085
101086
101087
101088
101089
101090
101091
101092
101093
101094
101095
101096
101097
101098
101099
101100
101101
101102
101103
101104
101105
101106
101107
101108
101109
101110
101111
101112
101113
101114
101115
101116
101117
101118
101119
101120
101121
101122
101123
101124
101125
101126
101127
101128
101129
101130
101131
101132
101133
101134
101135
101136
101137
101138
101139
101140
101141
101142
101143
101144
101145
101146
101147
101148
101149
101150
101151
101152
101153
101154
101155
101156
101157
101158
101159
101160
101161
101162
101163
101164
101165
101166
101167
101168
101169
101170
101171
101172
101173
101174
101175
101176
101177
101178
101179
101180
101181
101182
101183
101184
101185
101186
101187
101188
101189
101190
101191
101192
101193
101194
101195
101196
101197
101198
101199
101200
101201
101202
101203
101204
101205
101206
101207
101208
101209
101210
101211
101212
101213
101214
101215
101216
101217
101218
101219
101220
101221
101222
101223
101224
101225
101226
101227
101228
101229
101230
101231
101232
101233
101234
101235
101236
101237
101238
101239
101240
101241
101242
101243
101244
101245
101246
101247
101248
101249
101250
101251
101252
101253
101254
101255
101256
101257
101258
101259
101260
101261
101262
101263
101264
101265
101266
101267
101268
101269
101270
101271
101272
101273
101274
101275
101276
101277
101278
101279
101280
101281
101282
101283
101284
101285
101286
101287
101288
101289
101290
101291
101292
101293
101294
101295
101296
101297
101298
101299
101300
101301
101302
101303
101304
101305
101306
101307
101308
101309
101310
101311
101312
101313
101314
101315
101316
101317
101318
101319
101320
101321
101322
101323
101324
101325
101326
101327
101328
101329
101330
101331
101332
101333
101334
101335
101336
101337
101338
101339
101340
101341
101342
101343
101344
101345
101346
101347
101348
101349
101350
101351
101352
101353
101354
101355
101356
101357
101358
101359
101360
101361
101362
101363
101364
101365
101366
101367
101368
101369
101370
101371
101372
101373
101374
101375
101376
101377
101378
101379
101380
101381
101382
101383
101384
101385
101386
101387
101388
101389
101390
101391
101392
101393
101394
101395
101396
101397
101398
101399
101400
101401
101402
101403
101404
101405
101406
101407
101408
101409
101410
101411
101412
101413
101414
101415
101416
101417
101418
101419
101420
101421
101422
101423
101424
101425
101426
101427
101428
101429
101430
101431
101432
101433
101434
101435
101436
101437
101438
101439
101440
101441
101442
101443
101444
101445
101446
101447
101448
101449
101450
101451
101452
101453
101454
101455
101456
101457
101458
101459
101460
101461
101462
101463
101464
101465
101466
101467
101468
101469
101470
101471
101472
101473
101474
101475
101476
101477
101478
101479
101480
101481
101482
101483
101484
101485
101486
101487
101488
101489
101490
101491
101492
101493
101494
101495
101496
101497
101498
101499
101500
101501
101502
101503
101504
101505
101506
101507
101508
101509
101510
101511
101512
101513
101514
101515
101516
101517
101518
101519
101520
101521
101522
101523
101524
101525
101526
101527
101528
101529
101530
101531
101532
101533
101534
101535
101536
101537
101538
101539
101540
101541
101542
101543
101544
101545
101546
101547
101548
101549
101550
101551
101552
101553
101554
101555
101556
101557
101558
101559
101560
101561
101562
101563
101564
101565
101566
101567
101568
101569
101570
101571
101572
101573
101574
101575
101576
101577
101578
101579
101580
101581
101582
101583
101584
101585
101586
101587
101588
101589
101590
101591
101592
101593
101594
101595
101596
101597
101598
101599
101600
101601
101602
101603
101604
101605
101606
101607
101608
101609
101610
101611
101612
101613
101614
101615
101616
101617
101618
101619
101620
101621
101622
101623
101624
101625
101626
101627
101628
101629
101630
101631
101632
101633
101634
101635
101636
101637
101638
101639
101640
101641
101642
101643
101644
101645
101646
101647
101648
101649
101650
101651
101652
101653
101654
101655
101656
101657
101658
101659
101660
101661
101662
101663
101664
101665
101666
101667
101668
101669
101670
101671
101672
101673
101674
101675
101676
101677
101678
101679
101680
101681
101682
101683
101684
101685
101686
101687
101688
101689
101690
101691
101692
101693
101694
101695
101696
101697
101698
101699
101700
101701
101702
101703
101704
101705
101706
101707
101708
101709
101710
101711
101712
101713
101714
101715
101716
101717
101718
101719
101720
101721
101722
101723
101724
101725
101726
101727
101728
101729
101730
101731
101732
101733
101734
101735
101736
101737
101738
101739
101740
101741
101742
101743
101744
101745
101746
101747
101748
101749
101750
101751
101752
101753
101754
101755
101756
101757
101758
101759
101760
101761
101762
101763
101764
101765
101766
101767
101768
101769
101770
101771
101772
101773
101774
101775
101776
101777
101778
101779
101780
101781
101782
101783
101784
101785
101786
101787
101788
101789
101790
101791
101792
101793
101794
101795
101796
101797
101798
101799
101800
101801
101802
101803
101804
101805
101806
101807
101808
101809
101810
101811
101812
101813
101814
101815
101816
101817
101818
101819
101820
101821
101822
101823
101824
101825
101826
101827
101828
101829
101830
101831
101832
101833
101834
101835
101836
101837
101838
101839
101840
101841
101842
101843
101844
101845
101846
101847
101848
101849
101850
101851
101852
101853
101854
101855
101856
101857
101858
101859
101860
101861
101862
101863
101864
101865
101866
101867
101868
101869
101870
101871
101872
101873
101874
101875
101876
101877
101878
101879
101880
101881
101882
101883
101884
101885
101886
101887
101888
101889
101890
101891
101892
101893
101894
101895
101896
101897
101898
101899
101900
101901
101902
101903
101904
101905
101906
101907
101908
101909
101910
101911
101912
101913
101914
101915
101916
101917
101918
101919
101920
101921
101922
101923
101924
101925
101926
101927
101928
101929
101930
101931
101932
101933
101934
101935
101936
101937
101938
101939
101940
101941
101942
101943
101944
101945
101946
101947
101948
101949
101950
101951
101952
101953
101954
101955
101956
101957
101958
101959
101960
101961
101962
101963
101964
101965
101966
101967
101968
101969
101970
101971
101972
101973
101974
101975
101976
101977
101978
101979
101980
101981
101982
101983
101984
101985
101986
101987
101988
101989
101990
101991
101992
101993
101994
101995
101996
101997
101998
101999
102000
102001
102002
102003
102004
102005
102006
102007
102008
102009
102010
102011
102012
102013
102014
102015
102016
102017
102018
102019
102020
102021
102022
102023
102024
102025
102026
102027
102028
102029
102030
102031
102032
102033
102034
102035
102036
102037
102038
102039
102040
102041
102042
102043
102044
102045
102046
102047
102048
102049
102050
102051
102052
102053
102054
102055
102056
102057
102058
102059
102060
102061
102062
102063
102064
102065
102066
102067
102068
102069
102070
102071
102072
102073
102074
102075
102076
102077
102078
102079
102080
102081
102082
102083
102084
102085
102086
102087
102088
102089
102090
102091
102092
102093
102094
102095
102096
102097
102098
102099
102100
102101
102102
102103
102104
102105
102106
102107
102108
102109
102110
102111
102112
102113
102114
102115
102116
102117
102118
102119
102120
102121
102122
102123
102124
102125
102126
102127
102128
102129
102130
102131
102132
102133
102134
102135
102136
102137
102138
102139
102140
102141
102142
102143
102144
102145
102146
102147
102148
102149
102150
102151
102152
102153
102154
102155
102156
102157
102158
102159
102160
102161
102162
102163
102164
102165
102166
102167
102168
102169
102170
102171
102172
102173
102174
102175
102176
102177
102178
102179
102180
102181
102182
102183
102184
102185
102186
102187
102188
102189
102190
102191
102192
102193
102194
102195
102196
102197
102198
102199
102200
102201
102202
102203
102204
102205
102206
102207
102208
102209
102210
102211
102212
102213
102214
102215
102216
102217
102218
102219
102220
102221
102222
102223
102224
102225
102226
102227
102228
102229
102230
102231
102232
102233
102234
102235
102236
102237
102238
102239
102240
102241
102242
102243
102244
102245
102246
102247
102248
102249
102250
102251
102252
102253
102254
102255
102256
102257
102258
102259
102260
102261
102262
102263
102264
102265
102266
102267
102268
102269
102270
102271
102272
102273
102274
102275
102276
102277
102278
102279
102280
102281
102282
102283
102284
102285
102286
102287
102288
102289
102290
102291
102292
102293
102294
102295
102296
102297
102298
102299
102300
102301
102302
102303
102304
102305
102306
102307
102308
102309
102310
102311
102312
102313
102314
102315
102316
102317
102318
102319
102320
102321
102322
102323
102324
102325
102326
102327
102328
102329
102330
102331
102332
102333
102334
102335
102336
102337
102338
102339
102340
102341
102342
102343
102344
102345
102346
102347
102348
102349
102350
102351
102352
102353
102354
102355
102356
102357
102358
102359
102360
102361
102362
102363
102364
102365
102366
102367
102368
102369
102370
102371
102372
102373
102374
102375
102376
102377
102378
102379
102380
102381
102382
102383
102384
102385
102386
102387
102388
102389
102390
102391
102392
102393
102394
102395
102396
102397
102398
102399
102400
102401
102402
102403
102404
102405
102406
102407
102408
102409
102410
102411
102412
102413
102414
102415
102416
102417
102418
102419
102420
102421
102422
102423
102424
102425
102426
102427
102428
102429
102430
102431
102432
102433
102434
102435
102436
102437
102438
102439
102440
102441
102442
102443
102444
102445
102446
102447
102448
102449
102450
102451
102452
102453
102454
102455
102456
102457
102458
102459
102460
102461
102462
102463
102464
102465
102466
102467
102468
102469
102470
102471
102472
102473
102474
102475
102476
102477
102478
102479
102480
102481
102482
102483
102484
102485
102486
102487
102488
102489
102490
102491
102492
102493
102494
102495
102496
102497
102498
102499
102500
102501
102502
102503
102504
102505
102506
102507
102508
102509
102510
102511
102512
102513
102514
102515
102516
102517
102518
102519
102520
102521
102522
102523
102524
102525
102526
102527
102528
102529
102530
102531
102532
102533
102534
102535
102536
102537
102538
102539
102540
102541
102542
102543
102544
102545
102546
102547
102548
102549
102550
102551
102552
102553
102554
102555
102556
102557
102558
102559
102560
102561
102562
102563
102564
102565
102566
102567
102568
102569
102570
102571
102572
102573
102574
102575
102576
102577
102578
102579
102580
102581
102582
102583
102584
102585
102586
102587
102588
102589
102590
102591
102592
102593
102594
102595
102596
102597
102598
102599
102600
102601
102602
102603
102604
102605
102606
102607
102608
102609
102610
102611
102612
102613
102614
102615
102616
102617
102618
102619
102620
102621
102622
102623
102624
102625
102626
102627
102628
102629
102630
102631
102632
102633
102634
102635
102636
102637
102638
102639
102640
102641
102642
102643
102644
102645
102646
102647
102648
102649
102650
102651
102652
102653
102654
102655
102656
102657
102658
102659
102660
102661
102662
102663
102664
102665
102666
102667
102668
102669
102670
102671
102672
102673
102674
102675
102676
102677
102678
102679
102680
102681
102682
102683
102684
102685
102686
102687
102688
102689
102690
102691
102692
102693
102694
102695
102696
102697
102698
102699
102700
102701
102702
102703
102704
102705
102706
102707
102708
102709
102710
102711
102712
102713
102714
102715
102716
102717
102718
102719
102720
102721
102722
102723
102724
102725
102726
102727
102728
102729
102730
102731
102732
102733
102734
102735
102736
102737
102738
102739
102740
102741
102742
102743
102744
102745
102746
102747
102748
102749
102750
102751
102752
102753
102754
102755
102756
102757
102758
102759
102760
102761
102762
102763
102764
102765
102766
102767
102768
102769
102770
102771
102772
102773
102774
102775
102776
102777
102778
102779
102780
102781
102782
102783
102784
102785
102786
102787
102788
102789
102790
102791
102792
102793
102794
102795
102796
102797
102798
102799
102800
102801
102802
102803
102804
102805
102806
102807
102808
102809
102810
102811
102812
102813
102814
102815
102816
102817
102818
102819
102820
102821
102822
102823
102824
102825
102826
102827
102828
102829
102830
102831
102832
102833
102834
102835
102836
102837
102838
102839
102840
102841
102842
102843
102844
102845
102846
102847
102848
102849
102850
102851
102852
102853
102854
102855
102856
102857
102858
102859
102860
102861
102862
102863
102864
102865
102866
102867
102868
102869
102870
102871
102872
102873
102874
102875
102876
102877
102878
102879
102880
102881
102882
102883
102884
102885
102886
102887
102888
102889
102890
102891
102892
102893
102894
102895
102896
102897
102898
102899
102900
102901
102902
102903
102904
102905
102906
102907
102908
102909
102910
102911
102912
102913
102914
102915
102916
102917
102918
102919
102920
102921
102922
102923
102924
102925
102926
102927
102928
102929
102930
102931
102932
102933
102934
102935
102936
102937
102938
102939
102940
102941
102942
102943
102944
102945
102946
102947
102948
102949
102950
102951
102952
102953
102954
102955
102956
102957
102958
102959
102960
102961
102962
102963
102964
102965
102966
102967
102968
102969
102970
102971
102972
102973
102974
102975
102976
102977
102978
102979
102980
102981
102982
102983
102984
102985
102986
102987
102988
102989
102990
102991
102992
102993
102994
102995
102996
102997
102998
102999
103000
103001
103002
103003
103004
103005
103006
103007
103008
103009
103010
103011
103012
103013
103014
103015
103016
103017
103018
103019
103020
103021
103022
103023
103024
103025
103026
103027
103028
103029
103030
103031
103032
103033
103034
103035
103036
103037
103038
103039
103040
103041
103042
103043
103044
103045
103046
103047
103048
103049
103050
103051
103052
103053
103054
103055
103056
103057
103058
103059
103060
103061
103062
103063
103064
103065
103066
103067
103068
103069
103070
103071
103072
103073
103074
103075
103076
103077
103078
103079
103080
103081
103082
103083
103084
103085
103086
103087
103088
103089
103090
103091
103092
103093
103094
103095
103096
103097
103098
103099
103100
103101
103102
103103
103104
103105
103106
103107
103108
103109
103110
103111
103112
103113
103114
103115
103116
103117
103118
103119
103120
103121
103122
103123
103124
103125
103126
103127
103128
103129
103130
103131
103132
103133
103134
103135
103136
103137
103138
103139
103140
103141
103142
103143
103144
103145
103146
103147
103148
103149
103150
103151
103152
103153
103154
103155
103156
103157
103158
103159
103160
103161
103162
103163
103164
103165
103166
103167
103168
103169
103170
103171
103172
103173
103174
103175
103176
103177
103178
103179
103180
103181
103182
103183
103184
103185
103186
103187
103188
103189
103190
103191
103192
103193
103194
103195
103196
103197
103198
103199
103200
103201
103202
103203
103204
103205
103206
103207
103208
103209
103210
103211
103212
103213
103214
103215
103216
103217
103218
103219
103220
103221
103222
103223
103224
103225
103226
103227
103228
103229
103230
103231
103232
103233
103234
103235
103236
103237
103238
103239
103240
103241
103242
103243
103244
103245
103246
103247
103248
103249
103250
103251
103252
103253
103254
103255
103256
103257
103258
103259
103260
103261
103262
103263
103264
103265
103266
103267
103268
103269
103270
103271
103272
103273
103274
103275
103276
103277
103278
103279
103280
103281
103282
103283
103284
103285
103286
103287
103288
103289
103290
103291
103292
103293
103294
103295
103296
103297
103298
103299
103300
103301
103302
103303
103304
103305
103306
103307
103308
103309
103310
103311
103312
103313
103314
103315
103316
103317
103318
103319
103320
103321
103322
103323
103324
103325
103326
103327
103328
103329
103330
103331
103332
103333
103334
103335
103336
103337
103338
103339
103340
103341
103342
103343
103344
103345
103346
103347
103348
103349
103350
103351
103352
103353
103354
103355
103356
103357
103358
103359
103360
103361
103362
103363
103364
103365
103366
103367
103368
103369
103370
103371
103372
103373
103374
103375
103376
103377
103378
103379
103380
103381
103382
103383
103384
103385
103386
103387
103388
103389
103390
103391
103392
103393
103394
103395
103396
103397
103398
103399
103400
103401
103402
103403
103404
103405
103406
103407
103408
103409
103410
103411
103412
103413
103414
103415
103416
103417
103418
103419
103420
103421
103422
103423
103424
103425
103426
103427
103428
103429
103430
103431
103432
103433
103434
103435
103436
103437
103438
103439
103440
103441
103442
103443
103444
103445
103446
103447
103448
103449
103450
103451
103452
103453
103454
103455
103456
103457
103458
103459
103460
103461
103462
103463
103464
103465
103466
103467
103468
103469
103470
103471
103472
103473
103474
103475
103476
103477
103478
103479
103480
103481
103482
103483
103484
103485
103486
103487
103488
103489
103490
103491
103492
103493
103494
103495
103496
103497
103498
103499
103500
103501
103502
103503
103504
103505
103506
103507
103508
103509
103510
103511
103512
103513
103514
103515
103516
103517
103518
103519
103520
103521
103522
103523
103524
103525
103526
103527
103528
103529
103530
103531
103532
103533
103534
103535
103536
103537
103538
103539
103540
103541
103542
103543
103544
103545
103546
103547
103548
103549
103550
103551
103552
103553
103554
103555
103556
103557
103558
103559
103560
103561
103562
103563
103564
103565
103566
103567
103568
103569
103570
103571
103572
103573
103574
103575
103576
103577
103578
103579
103580
103581
103582
103583
103584
103585
103586
103587
103588
103589
103590
103591
103592
103593
103594
103595
103596
103597
103598
103599
103600
103601
103602
103603
103604
103605
103606
103607
103608
103609
103610
103611
103612
103613
103614
103615
103616
103617
103618
103619
103620
103621
103622
103623
103624
103625
103626
103627
103628
103629
103630
103631
103632
103633
103634
103635
103636
103637
103638
103639
103640
103641
103642
103643
103644
103645
103646
103647
103648
103649
103650
103651
103652
103653
103654
103655
103656
103657
103658
103659
103660
103661
103662
103663
103664
103665
103666
103667
103668
103669
103670
103671
103672
103673
103674
103675
103676
103677
103678
103679
103680
103681
103682
103683
103684
103685
103686
103687
103688
103689
103690
103691
103692
103693
103694
103695
103696
103697
103698
103699
103700
103701
103702
103703
103704
103705
103706
103707
103708
103709
103710
103711
103712
103713
103714
103715
103716
103717
103718
103719
103720
103721
103722
103723
103724
103725
103726
103727
103728
103729
103730
103731
103732
103733
103734
103735
103736
103737
103738
103739
103740
103741
103742
103743
103744
103745
103746
103747
103748
103749
103750
103751
103752
103753
103754
103755
103756
103757
103758
103759
103760
103761
103762
103763
103764
103765
103766
103767
103768
103769
103770
103771
103772
103773
103774
103775
103776
103777
103778
103779
103780
103781
103782
103783
103784
103785
103786
103787
103788
103789
103790
103791
103792
103793
103794
103795
103796
103797
103798
103799
103800
103801
103802
103803
103804
103805
103806
103807
103808
103809
103810
103811
103812
103813
103814
103815
103816
103817
103818
103819
103820
103821
103822
103823
103824
103825
103826
103827
103828
103829
103830
103831
103832
103833
103834
103835
103836
103837
103838
103839
103840
103841
103842
103843
103844
103845
103846
103847
103848
103849
103850
103851
103852
103853
103854
103855
103856
103857
103858
103859
103860
103861
103862
103863
103864
103865
103866
103867
103868
103869
103870
103871
103872
103873
103874
103875
103876
103877
103878
103879
103880
103881
103882
103883
103884
103885
103886
103887
103888
103889
103890
103891
103892
103893
103894
103895
103896
103897
103898
103899
103900
103901
103902
103903
103904
103905
103906
103907
103908
103909
103910
103911
103912
103913
103914
103915
103916
103917
103918
103919
103920
103921
103922
103923
103924
103925
103926
103927
103928
103929
103930
103931
103932
103933
103934
103935
103936
103937
103938
103939
103940
103941
103942
103943
103944
103945
103946
103947
103948
103949
103950
103951
103952
103953
103954
103955
103956
103957
103958
103959
103960
103961
103962
103963
103964
103965
103966
103967
103968
103969
103970
103971
103972
103973
103974
103975
103976
103977
103978
103979
103980
103981
103982
103983
103984
103985
103986
103987
103988
103989
103990
103991
103992
103993
103994
103995
103996
103997
103998
103999
104000
104001
104002
104003
104004
104005
104006
104007
104008
104009
104010
104011
104012
104013
104014
104015
104016
104017
104018
104019
104020
104021
104022
104023
104024
104025
104026
104027
104028
104029
104030
104031
104032
104033
104034
104035
104036
104037
104038
104039
104040
104041
104042
104043
104044
104045
104046
104047
104048
104049
104050
104051
104052
104053
104054
104055
104056
104057
104058
104059
104060
104061
104062
104063
104064
104065
104066
104067
104068
104069
104070
104071
104072
104073
104074
104075
104076
104077
104078
104079
104080
104081
104082
104083
104084
104085
104086
104087
104088
104089
104090
104091
104092
104093
104094
104095
104096
104097
104098
104099
104100
104101
104102
104103
104104
104105
104106
104107
104108
104109
104110
104111
104112
104113
104114
104115
104116
104117
104118
104119
104120
104121
104122
104123
104124
104125
104126
104127
104128
104129
104130
104131
104132
104133
104134
104135
104136
104137
104138
104139
104140
104141
104142
104143
104144
104145
104146
104147
104148
104149
104150
104151
104152
104153
104154
104155
104156
104157
104158
104159
104160
104161
104162
104163
104164
104165
104166
104167
104168
104169
104170
104171
104172
104173
104174
104175
104176
104177
104178
104179
104180
104181
104182
104183
104184
104185
104186
104187
104188
104189
104190
104191
104192
104193
104194
104195
104196
104197
104198
104199
104200
104201
104202
104203
104204
104205
104206
104207
104208
104209
104210
104211
104212
104213
104214
104215
104216
104217
104218
104219
104220
104221
104222
104223
104224
104225
104226
104227
104228
104229
104230
104231
104232
104233
104234
104235
104236
104237
104238
104239
104240
104241
104242
104243
104244
104245
104246
104247
104248
104249
104250
104251
104252
104253
104254
104255
104256
104257
104258
104259
104260
104261
104262
104263
104264
104265
104266
104267
104268
104269
104270
104271
104272
104273
104274
104275
104276
104277
104278
104279
104280
104281
104282
104283
104284
104285
104286
104287
104288
104289
104290
104291
104292
104293
104294
104295
104296
104297
104298
104299
104300
104301
104302
104303
104304
104305
104306
104307
104308
104309
104310
104311
104312
104313
104314
104315
104316
104317
104318
104319
104320
104321
104322
104323
104324
104325
104326
104327
104328
104329
104330
104331
104332
104333
104334
104335
104336
104337
104338
104339
104340
104341
104342
104343
104344
104345
104346
104347
104348
104349
104350
104351
104352
104353
104354
104355
104356
104357
104358
104359
104360
104361
104362
104363
104364
104365
104366
104367
104368
104369
104370
104371
104372
104373
104374
104375
104376
104377
104378
104379
104380
104381
104382
104383
104384
104385
104386
104387
104388
104389
104390
104391
104392
104393
104394
104395
104396
104397
104398
104399
104400
104401
104402
104403
104404
104405
104406
104407
104408
104409
104410
104411
104412
104413
104414
104415
104416
104417
104418
104419
104420
104421
104422
104423
104424
104425
104426
104427
104428
104429
104430
104431
104432
104433
104434
104435
104436
104437
104438
104439
104440
104441
104442
104443
104444
104445
104446
104447
104448
104449
104450
104451
104452
104453
104454
104455
104456
104457
104458
104459
104460
104461
104462
104463
104464
104465
104466
104467
104468
104469
104470
104471
104472
104473
104474
104475
104476
104477
104478
104479
104480
104481
104482
104483
104484
104485
104486
104487
104488
104489
104490
104491
104492
104493
104494
104495
104496
104497
104498
104499
104500
104501
104502
104503
104504
104505
104506
104507
104508
104509
104510
104511
104512
104513
104514
104515
104516
104517
104518
104519
104520
104521
104522
104523
104524
104525
104526
104527
104528
104529
104530
104531
104532
104533
104534
104535
104536
104537
104538
104539
104540
104541
104542
104543
104544
104545
104546
104547
104548
104549
104550
104551
104552
104553
104554
104555
104556
104557
104558
104559
104560
104561
104562
104563
104564
104565
104566
104567
104568
104569
104570
104571
104572
104573
104574
104575
104576
104577
104578
104579
104580
104581
104582
104583
104584
104585
104586
104587
104588
104589
104590
104591
104592
104593
104594
104595
104596
104597
104598
104599
104600
104601
104602
104603
104604
104605
104606
104607
104608
104609
104610
104611
104612
104613
104614
104615
104616
104617
104618
104619
104620
104621
104622
104623
104624
104625
104626
104627
104628
104629
104630
104631
104632
104633
104634
104635
104636
104637
104638
104639
104640
104641
104642
104643
104644
104645
104646
104647
104648
104649
104650
104651
104652
104653
104654
104655
104656
104657
104658
104659
104660
104661
104662
104663
104664
104665
104666
104667
104668
104669
104670
104671
104672
104673
104674
104675
104676
104677
104678
104679
104680
104681
104682
104683
104684
104685
104686
104687
104688
104689
104690
104691
104692
104693
104694
104695
104696
104697
104698
104699
104700
104701
104702
104703
104704
104705
104706
104707
104708
104709
104710
104711
104712
104713
104714
104715
104716
104717
104718
104719
104720
104721
104722
104723
104724
104725
104726
104727
104728
104729
104730
104731
104732
104733
104734
104735
104736
104737
104738
104739
104740
104741
104742
104743
104744
104745
104746
104747
104748
104749
104750
104751
104752
104753
104754
104755
104756
104757
104758
104759
104760
104761
104762
104763
104764
104765
104766
104767
104768
104769
104770
104771
104772
104773
104774
104775
104776
104777
104778
104779
104780
104781
104782
104783
104784
104785
104786
104787
104788
104789
104790
104791
104792
104793
104794
104795
104796
104797
104798
104799
104800
104801
104802
104803
104804
104805
104806
104807
104808
104809
104810
104811
104812
104813
104814
104815
104816
104817
104818
104819
104820
104821
104822
104823
104824
104825
104826
104827
104828
104829
104830
104831
104832
104833
104834
104835
104836
104837
104838
104839
104840
104841
104842
104843
104844
104845
104846
104847
104848
104849
104850
104851
104852
104853
104854
104855
104856
104857
104858
104859
104860
104861
104862
104863
104864
104865
104866
104867
104868
104869
104870
104871
104872
104873
104874
104875
104876
104877
104878
104879
104880
104881
104882
104883
104884
104885
104886
104887
104888
104889
104890
104891
104892
104893
104894
104895
104896
104897
104898
104899
104900
104901
104902
104903
104904
104905
104906
104907
104908
104909
104910
104911
104912
104913
104914
104915
104916
104917
104918
104919
104920
104921
104922
104923
104924
104925
104926
104927
104928
104929
104930
104931
104932
104933
104934
104935
104936
104937
104938
104939
104940
104941
104942
104943
104944
104945
104946
104947
104948
104949
104950
104951
104952
104953
104954
104955
104956
104957
104958
104959
104960
104961
104962
104963
104964
104965
104966
104967
104968
104969
104970
104971
104972
104973
104974
104975
104976
104977
104978
104979
104980
104981
104982
104983
104984
104985
104986
104987
104988
104989
104990
104991
104992
104993
104994
104995
104996
104997
104998
104999
105000
105001
105002
105003
105004
105005
105006
105007
105008
105009
105010
105011
105012
105013
105014
105015
105016
105017
105018
105019
105020
105021
105022
105023
105024
105025
105026
105027
105028
105029
105030
105031
105032
105033
105034
105035
105036
105037
105038
105039
105040
105041
105042
105043
105044
105045
105046
105047
105048
105049
105050
105051
105052
105053
105054
105055
105056
105057
105058
105059
105060
105061
105062
105063
105064
105065
105066
105067
105068
105069
105070
105071
105072
105073
105074
105075
105076
105077
105078
105079
105080
105081
105082
105083
105084
105085
105086
105087
105088
105089
105090
105091
105092
105093
105094
105095
105096
105097
105098
105099
105100
105101
105102
105103
105104
105105
105106
105107
105108
105109
105110
105111
105112
105113
105114
105115
105116
105117
105118
105119
105120
105121
105122
105123
105124
105125
105126
105127
105128
105129
105130
105131
105132
105133
105134
105135
105136
105137
105138
105139
105140
105141
105142
105143
105144
105145
105146
105147
105148
105149
105150
105151
105152
105153
105154
105155
105156
105157
105158
105159
105160
105161
105162
105163
105164
105165
105166
105167
105168
105169
105170
105171
105172
105173
105174
105175
105176
105177
105178
105179
105180
105181
105182
105183
105184
105185
105186
105187
105188
105189
105190
105191
105192
105193
105194
105195
105196
105197
105198
105199
105200
105201
105202
105203
105204
105205
105206
105207
105208
105209
105210
105211
105212
105213
105214
105215
105216
105217
105218
105219
105220
105221
105222
105223
105224
105225
105226
105227
105228
105229
105230
105231
105232
105233
105234
105235
105236
105237
105238
105239
105240
105241
105242
105243
105244
105245
105246
105247
105248
105249
105250
105251
105252
105253
105254
105255
105256
105257
105258
105259
105260
105261
105262
105263
105264
105265
105266
105267
105268
105269
105270
105271
105272
105273
105274
105275
105276
105277
105278
105279
105280
105281
105282
105283
105284
105285
105286
105287
105288
105289
105290
105291
105292
105293
105294
105295
105296
105297
105298
105299
105300
105301
105302
105303
105304
105305
105306
105307
105308
105309
105310
105311
105312
105313
105314
105315
105316
105317
105318
105319
105320
105321
105322
105323
105324
105325
105326
105327
105328
105329
105330
105331
105332
105333
105334
105335
105336
105337
105338
105339
105340
105341
105342
105343
105344
105345
105346
105347
105348
105349
105350
105351
105352
105353
105354
105355
105356
105357
105358
105359
105360
105361
105362
105363
105364
105365
105366
105367
105368
105369
105370
105371
105372
105373
105374
105375
105376
105377
105378
105379
105380
105381
105382
105383
105384
105385
105386
105387
105388
105389
105390
105391
105392
105393
105394
105395
105396
105397
105398
105399
105400
105401
105402
105403
105404
105405
105406
105407
105408
105409
105410
105411
105412
105413
105414
105415
105416
105417
105418
105419
105420
105421
105422
105423
105424
105425
105426
105427
105428
105429
105430
105431
105432
105433
105434
105435
105436
105437
105438
105439
105440
105441
105442
105443
105444
105445
105446
105447
105448
105449
105450
105451
105452
105453
105454
105455
105456
105457
105458
105459
105460
105461
105462
105463
105464
105465
105466
105467
105468
105469
105470
105471
105472
105473
105474
105475
105476
105477
105478
105479
105480
105481
105482
105483
105484
105485
105486
105487
105488
105489
105490
105491
105492
105493
105494
105495
105496
105497
105498
105499
105500
105501
105502
105503
105504
105505
105506
105507
105508
105509
105510
105511
105512
105513
105514
105515
105516
105517
105518
105519
105520
105521
105522
105523
105524
105525
105526
105527
105528
105529
105530
105531
105532
105533
105534
105535
105536
105537
105538
105539
105540
105541
105542
105543
105544
105545
105546
105547
105548
105549
105550
105551
105552
105553
105554
105555
105556
105557
105558
105559
105560
105561
105562
105563
105564
105565
105566
105567
105568
105569
105570
105571
105572
105573
105574
105575
105576
105577
105578
105579
105580
105581
105582
105583
105584
105585
105586
105587
105588
105589
105590
105591
105592
105593
105594
105595
105596
105597
105598
105599
105600
105601
105602
105603
105604
105605
105606
105607
105608
105609
105610
105611
105612
105613
105614
105615
105616
105617
105618
105619
105620
105621
105622
105623
105624
105625
105626
105627
105628
105629
105630
105631
105632
105633
105634
105635
105636
105637
105638
105639
105640
105641
105642
105643
105644
105645
105646
105647
105648
105649
105650
105651
105652
105653
105654
105655
105656
105657
105658
105659
105660
105661
105662
105663
105664
105665
105666
105667
105668
105669
105670
105671
105672
105673
105674
105675
105676
105677
105678
105679
105680
105681
105682
105683
105684
105685
105686
105687
105688
105689
105690
105691
105692
105693
105694
105695
105696
105697
105698
105699
105700
105701
105702
105703
105704
105705
105706
105707
105708
105709
105710
105711
105712
105713
105714
105715
105716
105717
105718
105719
105720
105721
105722
105723
105724
105725
105726
105727
105728
105729
105730
105731
105732
105733
105734
105735
105736
105737
105738
105739
105740
105741
105742
105743
105744
105745
105746
105747
105748
105749
105750
105751
105752
105753
105754
105755
105756
105757
105758
105759
105760
105761
105762
105763
105764
105765
105766
105767
105768
105769
105770
105771
105772
105773
105774
105775
105776
105777
105778
105779
105780
105781
105782
105783
105784
105785
105786
105787
105788
105789
105790
105791
105792
105793
105794
105795
105796
105797
105798
105799
105800
105801
105802
105803
105804
105805
105806
105807
105808
105809
105810
105811
105812
105813
105814
105815
105816
105817
105818
105819
105820
105821
105822
105823
105824
105825
105826
105827
105828
105829
105830
105831
105832
105833
105834
105835
105836
105837
105838
105839
105840
105841
105842
105843
105844
105845
105846
105847
105848
105849
105850
105851
105852
105853
105854
105855
105856
105857
105858
105859
105860
105861
105862
105863
105864
105865
105866
105867
105868
105869
105870
105871
105872
105873
105874
105875
105876
105877
105878
105879
105880
105881
105882
105883
105884
105885
105886
105887
105888
105889
105890
105891
105892
105893
105894
105895
105896
105897
105898
105899
105900
105901
105902
105903
105904
105905
105906
105907
105908
105909
105910
105911
105912
105913
105914
105915
105916
105917
105918
105919
105920
105921
105922
105923
105924
105925
105926
105927
105928
105929
105930
105931
105932
105933
105934
105935
105936
105937
105938
105939
105940
105941
105942
105943
105944
105945
105946
105947
105948
105949
105950
105951
105952
105953
105954
105955
105956
105957
105958
105959
105960
105961
105962
105963
105964
105965
105966
105967
105968
105969
105970
105971
105972
105973
105974
105975
105976
105977
105978
105979
105980
105981
105982
105983
105984
105985
105986
105987
105988
105989
105990
105991
105992
105993
105994
105995
105996
105997
105998
105999
106000
106001
106002
106003
106004
106005
106006
106007
106008
106009
106010
106011
106012
106013
106014
106015
106016
106017
106018
106019
106020
106021
106022
106023
106024
106025
106026
106027
106028
106029
106030
106031
106032
106033
106034
106035
106036
106037
106038
106039
106040
106041
106042
106043
106044
106045
106046
106047
106048
106049
106050
106051
106052
106053
106054
106055
106056
106057
106058
106059
106060
106061
106062
106063
106064
106065
106066
106067
106068
106069
106070
106071
106072
106073
106074
106075
106076
106077
106078
106079
106080
106081
106082
106083
106084
106085
106086
106087
106088
106089
106090
106091
106092
106093
106094
106095
106096
106097
106098
106099
106100
106101
106102
106103
106104
106105
106106
106107
106108
106109
106110
106111
106112
106113
106114
106115
106116
106117
106118
106119
106120
106121
106122
106123
106124
106125
106126
106127
106128
106129
106130
106131
106132
106133
106134
106135
106136
106137
106138
106139
106140
106141
106142
106143
106144
106145
106146
106147
106148
106149
106150
106151
106152
106153
106154
106155
106156
106157
106158
106159
106160
106161
106162
106163
106164
106165
106166
106167
106168
106169
106170
106171
106172
106173
106174
106175
106176
106177
106178
106179
106180
106181
106182
106183
106184
106185
106186
106187
106188
106189
106190
106191
106192
106193
106194
106195
106196
106197
106198
106199
106200
106201
106202
106203
106204
106205
106206
106207
106208
106209
106210
106211
106212
106213
106214
106215
106216
106217
106218
106219
106220
106221
106222
106223
106224
106225
106226
106227
106228
106229
106230
106231
106232
106233
106234
106235
106236
106237
106238
106239
106240
106241
106242
106243
106244
106245
106246
106247
106248
106249
106250
106251
106252
106253
106254
106255
106256
106257
106258
106259
106260
106261
106262
106263
106264
106265
106266
106267
106268
106269
106270
106271
106272
106273
106274
106275
106276
106277
106278
106279
106280
106281
106282
106283
106284
106285
106286
106287
106288
106289
106290
106291
106292
106293
106294
106295
106296
106297
106298
106299
106300
106301
106302
106303
106304
106305
106306
106307
106308
106309
106310
106311
106312
106313
106314
106315
106316
106317
106318
106319
106320
106321
106322
106323
106324
106325
106326
106327
106328
106329
106330
106331
106332
106333
106334
106335
106336
106337
106338
106339
106340
106341
106342
106343
106344
106345
106346
106347
106348
106349
106350
106351
106352
106353
106354
106355
106356
106357
106358
106359
106360
106361
106362
106363
106364
106365
106366
106367
106368
106369
106370
106371
106372
106373
106374
106375
106376
106377
106378
106379
106380
106381
106382
106383
106384
106385
106386
106387
106388
106389
106390
106391
106392
106393
106394
106395
106396
106397
106398
106399
106400
106401
106402
106403
106404
106405
106406
106407
106408
106409
106410
106411
106412
106413
106414
106415
106416
106417
106418
106419
106420
106421
106422
106423
106424
106425
106426
106427
106428
106429
106430
106431
106432
106433
106434
106435
106436
106437
106438
106439
106440
106441
106442
106443
106444
106445
106446
106447
106448
106449
106450
106451
106452
106453
106454
106455
106456
106457
106458
106459
106460
106461
106462
106463
106464
106465
106466
106467
106468
106469
106470
106471
106472
106473
106474
106475
106476
106477
106478
106479
106480
106481
106482
106483
106484
106485
106486
106487
106488
106489
106490
106491
106492
106493
106494
106495
106496
106497
106498
106499
106500
106501
106502
106503
106504
106505
106506
106507
106508
106509
106510
106511
106512
106513
106514
106515
106516
106517
106518
106519
106520
106521
106522
106523
106524
106525
106526
106527
106528
106529
106530
106531
106532
106533
106534
106535
106536
106537
106538
106539
106540
106541
106542
106543
106544
106545
106546
106547
106548
106549
106550
106551
106552
106553
106554
106555
106556
106557
106558
106559
106560
106561
106562
106563
106564
106565
106566
106567
106568
106569
106570
106571
106572
106573
106574
106575
106576
106577
106578
106579
106580
106581
106582
106583
106584
106585
106586
106587
106588
106589
106590
106591
106592
106593
106594
106595
106596
106597
106598
106599
106600
106601
106602
106603
106604
106605
106606
106607
106608
106609
106610
106611
106612
106613
106614
106615
106616
106617
106618
106619
106620
106621
106622
106623
106624
106625
106626
106627
106628
106629
106630
106631
106632
106633
106634
106635
106636
106637
106638
106639
106640
106641
106642
106643
106644
106645
106646
106647
106648
106649
106650
106651
106652
106653
106654
106655
106656
106657
106658
106659
106660
106661
106662
106663
106664
106665
106666
106667
106668
106669
106670
106671
106672
106673
106674
106675
106676
106677
106678
106679
106680
106681
106682
106683
106684
106685
106686
106687
106688
106689
106690
106691
106692
106693
106694
106695
106696
106697
106698
106699
106700
106701
106702
106703
106704
106705
106706
106707
106708
106709
106710
106711
106712
106713
106714
106715
106716
106717
106718
106719
106720
106721
106722
106723
106724
106725
106726
106727
106728
106729
106730
106731
106732
106733
106734
106735
106736
106737
106738
106739
106740
106741
106742
106743
106744
106745
106746
106747
106748
106749
106750
106751
106752
106753
106754
106755
106756
106757
106758
106759
106760
106761
106762
106763
106764
106765
106766
106767
106768
106769
106770
106771
106772
106773
106774
106775
106776
106777
106778
106779
106780
106781
106782
106783
106784
106785
106786
106787
106788
106789
106790
106791
106792
106793
106794
106795
106796
106797
106798
106799
106800
106801
106802
106803
106804
106805
106806
106807
106808
106809
106810
106811
106812
106813
106814
106815
106816
106817
106818
106819
106820
106821
106822
106823
106824
106825
106826
106827
106828
106829
106830
106831
106832
106833
106834
106835
106836
106837
106838
106839
106840
106841
106842
106843
106844
106845
106846
106847
106848
106849
106850
106851
106852
106853
106854
106855
106856
106857
106858
106859
106860
106861
106862
106863
106864
106865
106866
106867
106868
106869
106870
106871
106872
106873
106874
106875
106876
106877
106878
106879
106880
106881
106882
106883
106884
106885
106886
106887
106888
106889
106890
106891
106892
106893
106894
106895
106896
106897
106898
106899
106900
106901
106902
106903
106904
106905
106906
106907
106908
106909
106910
106911
106912
106913
106914
106915
106916
106917
106918
106919
106920
106921
106922
106923
106924
106925
106926
106927
106928
106929
106930
106931
106932
106933
106934
106935
106936
106937
106938
106939
106940
106941
106942
106943
106944
106945
106946
106947
106948
106949
106950
106951
106952
106953
106954
106955
106956
106957
106958
106959
106960
106961
106962
106963
106964
106965
106966
106967
106968
106969
106970
106971
106972
106973
106974
106975
106976
106977
106978
106979
106980
106981
106982
106983
106984
106985
106986
106987
106988
106989
106990
106991
106992
106993
106994
106995
106996
106997
106998
106999
107000
107001
107002
107003
107004
107005
107006
107007
107008
107009
107010
107011
107012
107013
107014
107015
107016
107017
107018
107019
107020
107021
107022
107023
107024
107025
107026
107027
107028
107029
107030
107031
107032
107033
107034
107035
107036
107037
107038
107039
107040
107041
107042
107043
107044
107045
107046
107047
107048
107049
107050
107051
107052
107053
107054
107055
107056
107057
107058
107059
107060
107061
107062
107063
107064
107065
107066
107067
107068
107069
107070
107071
107072
107073
107074
107075
107076
107077
107078
107079
107080
107081
107082
107083
107084
107085
107086
107087
107088
107089
107090
107091
107092
107093
107094
107095
107096
107097
107098
107099
107100
107101
107102
107103
107104
107105
107106
107107
107108
107109
107110
107111
107112
107113
107114
107115
107116
107117
107118
107119
107120
107121
107122
107123
107124
107125
107126
107127
107128
107129
107130
107131
107132
107133
107134
107135
107136
107137
107138
107139
107140
107141
107142
107143
107144
107145
107146
107147
107148
107149
107150
107151
107152
107153
107154
107155
107156
107157
107158
107159
107160
107161
107162
107163
107164
107165
107166
107167
107168
107169
107170
107171
107172
107173
107174
107175
107176
107177
107178
107179
107180
107181
107182
107183
107184
107185
107186
107187
107188
107189
107190
107191
107192
107193
107194
107195
107196
107197
107198
107199
107200
107201
107202
107203
107204
107205
107206
107207
107208
107209
107210
107211
107212
107213
107214
107215
107216
107217
107218
107219
107220
107221
107222
107223
107224
107225
107226
107227
107228
107229
107230
107231
107232
107233
107234
107235
107236
107237
107238
107239
107240
107241
107242
107243
107244
107245
107246
107247
107248
107249
107250
107251
107252
107253
107254
107255
107256
107257
107258
107259
107260
107261
107262
107263
107264
107265
107266
107267
107268
107269
107270
107271
107272
107273
107274
107275
107276
107277
107278
107279
107280
107281
107282
107283
107284
107285
107286
107287
107288
107289
107290
107291
107292
107293
107294
107295
107296
107297
107298
107299
107300
107301
107302
107303
107304
107305
107306
107307
107308
107309
107310
107311
107312
107313
107314
107315
107316
107317
107318
107319
107320
107321
107322
107323
107324
107325
107326
107327
107328
107329
107330
107331
107332
107333
107334
107335
107336
107337
107338
107339
107340
107341
107342
107343
107344
107345
107346
107347
107348
107349
107350
107351
107352
107353
107354
107355
107356
107357
107358
107359
107360
107361
107362
107363
107364
107365
107366
107367
107368
107369
107370
107371
107372
107373
107374
107375
107376
107377
107378
107379
107380
107381
107382
107383
107384
107385
107386
107387
107388
107389
107390
107391
107392
107393
107394
107395
107396
107397
107398
107399
107400
107401
107402
107403
107404
107405
107406
107407
107408
107409
107410
107411
107412
107413
107414
107415
107416
107417
107418
107419
107420
107421
107422
107423
107424
107425
107426
107427
107428
107429
107430
107431
107432
107433
107434
107435
107436
107437
107438
107439
107440
107441
107442
107443
107444
107445
107446
107447
107448
107449
107450
107451
107452
107453
107454
107455
107456
107457
107458
107459
107460
107461
107462
107463
107464
107465
107466
107467
107468
107469
107470
107471
107472
107473
107474
107475
107476
107477
107478
107479
107480
107481
107482
107483
107484
107485
107486
107487
107488
107489
107490
107491
107492
107493
107494
107495
107496
107497
107498
107499
107500
107501
107502
107503
107504
107505
107506
107507
107508
107509
107510
107511
107512
107513
107514
107515
107516
107517
107518
107519
107520
107521
107522
107523
107524
107525
107526
107527
107528
107529
107530
107531
107532
107533
107534
107535
107536
107537
107538
107539
107540
107541
107542
107543
107544
107545
107546
107547
107548
107549
107550
107551
107552
107553
107554
107555
107556
107557
107558
107559
107560
107561
107562
107563
107564
107565
107566
107567
107568
107569
107570
107571
107572
107573
107574
107575
107576
107577
107578
107579
107580
107581
107582
107583
107584
107585
107586
107587
107588
107589
107590
107591
107592
107593
107594
107595
107596
107597
107598
107599
107600
107601
107602
107603
107604
107605
107606
107607
107608
107609
107610
107611
107612
107613
107614
107615
107616
107617
107618
107619
107620
107621
107622
107623
107624
107625
107626
107627
107628
107629
107630
107631
107632
107633
107634
107635
107636
107637
107638
107639
107640
107641
107642
107643
107644
107645
107646
107647
107648
107649
107650
107651
107652
107653
107654
107655
107656
107657
107658
107659
107660
107661
107662
107663
107664
107665
107666
107667
107668
107669
107670
107671
107672
107673
107674
107675
107676
107677
107678
107679
107680
107681
107682
107683
107684
107685
107686
107687
107688
107689
107690
107691
107692
107693
107694
107695
107696
107697
107698
107699
107700
107701
107702
107703
107704
107705
107706
107707
107708
107709
107710
107711
107712
107713
107714
107715
107716
107717
107718
107719
107720
107721
107722
107723
107724
107725
107726
107727
107728
107729
107730
107731
107732
107733
107734
107735
107736
107737
107738
107739
107740
107741
107742
107743
107744
107745
107746
107747
107748
107749
107750
107751
107752
107753
107754
107755
107756
107757
107758
107759
107760
107761
107762
107763
107764
107765
107766
107767
107768
107769
107770
107771
107772
107773
107774
107775
107776
107777
107778
107779
107780
107781
107782
107783
107784
107785
107786
107787
107788
107789
107790
107791
107792
107793
107794
107795
107796
107797
107798
107799
107800
107801
107802
107803
107804
107805
107806
107807
107808
107809
107810
107811
107812
107813
107814
107815
107816
107817
107818
107819
107820
107821
107822
107823
107824
107825
107826
107827
107828
107829
107830
107831
107832
107833
107834
107835
107836
107837
107838
107839
107840
107841
107842
107843
107844
107845
107846
107847
107848
107849
107850
107851
107852
107853
107854
107855
107856
107857
107858
107859
107860
107861
107862
107863
107864
107865
107866
107867
107868
107869
107870
107871
107872
107873
107874
107875
107876
107877
107878
107879
107880
107881
107882
107883
107884
107885
107886
107887
107888
107889
107890
107891
107892
107893
107894
107895
107896
107897
107898
107899
107900
107901
107902
107903
107904
107905
107906
107907
107908
107909
107910
107911
107912
107913
107914
107915
107916
107917
107918
107919
107920
107921
107922
107923
107924
107925
107926
107927
107928
107929
107930
107931
107932
107933
107934
107935
107936
107937
107938
107939
107940
107941
107942
107943
107944
107945
107946
107947
107948
107949
107950
107951
107952
107953
107954
107955
107956
107957
107958
107959
107960
107961
107962
107963
107964
107965
107966
107967
107968
107969
107970
107971
107972
107973
107974
107975
107976
107977
107978
107979
107980
107981
107982
107983
107984
107985
107986
107987
107988
107989
107990
107991
107992
107993
107994
107995
107996
107997
107998
107999
108000
108001
108002
108003
108004
108005
108006
108007
108008
108009
108010
108011
108012
108013
108014
108015
108016
108017
108018
108019
108020
108021
108022
108023
108024
108025
108026
108027
108028
108029
108030
108031
108032
108033
108034
108035
108036
108037
108038
108039
108040
108041
108042
108043
108044
108045
108046
108047
108048
108049
108050
108051
108052
108053
108054
108055
108056
108057
108058
108059
108060
108061
108062
108063
108064
108065
108066
108067
108068
108069
108070
108071
108072
108073
108074
108075
108076
108077
108078
108079
108080
108081
108082
108083
108084
108085
108086
108087
108088
108089
108090
108091
108092
108093
108094
108095
108096
108097
108098
108099
108100
108101
108102
108103
108104
108105
108106
108107
108108
108109
108110
108111
108112
108113
108114
108115
108116
108117
108118
108119
108120
108121
108122
108123
108124
108125
108126
108127
108128
108129
108130
108131
108132
108133
108134
108135
108136
108137
108138
108139
108140
108141
108142
108143
108144
108145
108146
108147
108148
108149
108150
108151
108152
108153
108154
108155
108156
108157
108158
108159
108160
108161
108162
108163
108164
108165
108166
108167
108168
108169
108170
108171
108172
108173
108174
108175
108176
108177
108178
108179
108180
108181
108182
108183
108184
108185
108186
108187
108188
108189
108190
108191
108192
108193
108194
108195
108196
108197
108198
108199
108200
108201
108202
108203
108204
108205
108206
108207
108208
108209
108210
108211
108212
108213
108214
108215
108216
108217
108218
108219
108220
108221
108222
108223
108224
108225
108226
108227
108228
108229
108230
108231
108232
108233
108234
108235
108236
108237
108238
108239
108240
108241
108242
108243
108244
108245
108246
108247
108248
108249
108250
108251
108252
108253
108254
108255
108256
108257
108258
108259
108260
108261
108262
108263
108264
108265
108266
108267
108268
108269
108270
108271
108272
108273
108274
108275
108276
108277
108278
108279
108280
108281
108282
108283
108284
108285
108286
108287
108288
108289
108290
108291
108292
108293
108294
108295
108296
108297
108298
108299
108300
108301
108302
108303
108304
108305
108306
108307
108308
108309
108310
108311
108312
108313
108314
108315
108316
108317
108318
108319
108320
108321
108322
108323
108324
108325
108326
108327
108328
108329
108330
108331
108332
108333
108334
108335
108336
108337
108338
108339
108340
108341
108342
108343
108344
108345
108346
108347
108348
108349
108350
108351
108352
108353
108354
108355
108356
108357
108358
108359
108360
108361
108362
108363
108364
108365
108366
108367
108368
108369
108370
108371
108372
108373
108374
108375
108376
108377
108378
108379
108380
108381
108382
108383
108384
108385
108386
108387
108388
108389
108390
108391
108392
108393
108394
108395
108396
108397
108398
108399
108400
108401
108402
108403
108404
108405
108406
108407
108408
108409
108410
108411
108412
108413
108414
108415
108416
108417
108418
108419
108420
108421
108422
108423
108424
108425
108426
108427
108428
108429
108430
108431
108432
108433
108434
108435
108436
108437
108438
108439
108440
108441
108442
108443
108444
108445
108446
108447
108448
108449
108450
108451
108452
108453
108454
108455
108456
108457
108458
108459
108460
108461
108462
108463
108464
108465
108466
108467
108468
108469
108470
108471
108472
108473
108474
108475
108476
108477
108478
108479
108480
108481
108482
108483
108484
108485
108486
108487
108488
108489
108490
108491
108492
108493
108494
108495
108496
108497
108498
108499
108500
108501
108502
108503
108504
108505
108506
108507
108508
108509
108510
108511
108512
108513
108514
108515
108516
108517
108518
108519
108520
108521
108522
108523
108524
108525
108526
108527
108528
108529
108530
108531
108532
108533
108534
108535
108536
108537
108538
108539
108540
108541
108542
108543
108544
108545
108546
108547
108548
108549
108550
108551
108552
108553
108554
108555
108556
108557
108558
108559
108560
108561
108562
108563
108564
108565
108566
108567
108568
108569
108570
108571
108572
108573
108574
108575
108576
108577
108578
108579
108580
108581
108582
108583
108584
108585
108586
108587
108588
108589
108590
108591
108592
108593
108594
108595
108596
108597
108598
108599
108600
108601
108602
108603
108604
108605
108606
108607
108608
108609
108610
108611
108612
108613
108614
108615
108616
108617
108618
108619
108620
108621
108622
108623
108624
108625
108626
108627
108628
108629
108630
108631
108632
108633
108634
108635
108636
108637
108638
108639
108640
108641
108642
108643
108644
108645
108646
108647
108648
108649
108650
108651
108652
108653
108654
108655
108656
108657
108658
108659
108660
108661
108662
108663
108664
108665
108666
108667
108668
108669
108670
108671
108672
108673
108674
108675
108676
108677
108678
108679
108680
108681
108682
108683
108684
108685
108686
108687
108688
108689
108690
108691
108692
108693
108694
108695
108696
108697
108698
108699
108700
108701
108702
108703
108704
108705
108706
108707
108708
108709
108710
108711
108712
108713
108714
108715
108716
108717
108718
108719
108720
108721
108722
108723
108724
108725
108726
108727
108728
108729
108730
108731
108732
108733
108734
108735
108736
108737
108738
108739
108740
108741
108742
108743
108744
108745
108746
108747
108748
108749
108750
108751
108752
108753
108754
108755
108756
108757
108758
108759
108760
108761
108762
108763
108764
108765
108766
108767
108768
108769
108770
108771
108772
108773
108774
108775
108776
108777
108778
108779
108780
108781
108782
108783
108784
108785
108786
108787
108788
108789
108790
108791
108792
108793
108794
108795
108796
108797
108798
108799
108800
108801
108802
108803
108804
108805
108806
108807
108808
108809
108810
108811
108812
108813
108814
108815
108816
108817
108818
108819
108820
108821
108822
108823
108824
108825
108826
108827
108828
108829
108830
108831
108832
108833
108834
108835
108836
108837
108838
108839
108840
108841
108842
108843
108844
108845
108846
108847
108848
108849
108850
108851
108852
108853
108854
108855
108856
108857
108858
108859
108860
108861
108862
108863
108864
108865
108866
108867
108868
108869
108870
108871
108872
108873
108874
108875
108876
108877
108878
108879
108880
108881
108882
108883
108884
108885
108886
108887
108888
108889
108890
108891
108892
108893
108894
108895
108896
108897
108898
108899
108900
108901
108902
108903
108904
108905
108906
108907
108908
108909
108910
108911
108912
108913
108914
108915
108916
108917
108918
108919
108920
108921
108922
108923
108924
108925
108926
108927
108928
108929
108930
108931
108932
108933
108934
108935
108936
108937
108938
108939
108940
108941
108942
108943
108944
108945
108946
108947
108948
108949
108950
108951
108952
108953
108954
108955
108956
108957
108958
108959
108960
108961
108962
108963
108964
108965
108966
108967
108968
108969
108970
108971
108972
108973
108974
108975
108976
108977
108978
108979
108980
108981
108982
108983
108984
108985
108986
108987
108988
108989
108990
108991
108992
108993
108994
108995
108996
108997
108998
108999
109000
109001
109002
109003
109004
109005
109006
109007
109008
109009
109010
109011
109012
109013
109014
109015
109016
109017
109018
109019
109020
109021
109022
109023
109024
109025
109026
109027
109028
109029
109030
109031
109032
109033
109034
109035
109036
109037
109038
109039
109040
109041
109042
109043
109044
109045
109046
109047
109048
109049
109050
109051
109052
109053
109054
109055
109056
109057
109058
109059
109060
109061
109062
109063
109064
109065
109066
109067
109068
109069
109070
109071
109072
109073
109074
109075
109076
109077
109078
109079
109080
109081
109082
109083
109084
109085
109086
109087
109088
109089
109090
109091
109092
109093
109094
109095
109096
109097
109098
109099
109100
109101
109102
109103
109104
109105
109106
109107
109108
109109
109110
109111
109112
109113
109114
109115
109116
109117
109118
109119
109120
109121
109122
109123
109124
109125
109126
109127
109128
109129
109130
109131
109132
109133
109134
109135
109136
109137
109138
109139
109140
109141
109142
109143
109144
109145
109146
109147
109148
109149
109150
109151
109152
109153
109154
109155
109156
109157
109158
109159
109160
109161
109162
109163
109164
109165
109166
109167
109168
109169
109170
109171
109172
109173
109174
109175
109176
109177
109178
109179
109180
109181
109182
109183
109184
109185
109186
109187
109188
109189
109190
109191
109192
109193
109194
109195
109196
109197
109198
109199
109200
109201
109202
109203
109204
109205
109206
109207
109208
109209
109210
109211
109212
109213
109214
109215
109216
109217
109218
109219
109220
109221
109222
109223
109224
109225
109226
109227
109228
109229
109230
109231
109232
109233
109234
109235
109236
109237
109238
109239
109240
109241
109242
109243
109244
109245
109246
109247
109248
109249
109250
109251
109252
109253
109254
109255
109256
109257
109258
109259
109260
109261
109262
109263
109264
109265
109266
109267
109268
109269
109270
109271
109272
109273
109274
109275
109276
109277
109278
109279
109280
109281
109282
109283
109284
109285
109286
109287
109288
109289
109290
109291
109292
109293
109294
109295
109296
109297
109298
109299
109300
109301
109302
109303
109304
109305
109306
109307
109308
109309
109310
109311
109312
109313
109314
109315
109316
109317
109318
109319
109320
109321
109322
109323
109324
109325
109326
109327
109328
109329
109330
109331
109332
109333
109334
109335
109336
109337
109338
109339
109340
109341
109342
109343
109344
109345
109346
109347
109348
109349
109350
109351
109352
109353
109354
109355
109356
109357
109358
109359
109360
109361
109362
109363
109364
109365
109366
109367
109368
109369
109370
109371
109372
109373
109374
109375
109376
109377
109378
109379
109380
109381
109382
109383
109384
109385
109386
109387
109388
109389
109390
109391
109392
109393
109394
109395
109396
109397
109398
109399
109400
109401
109402
109403
109404
109405
109406
109407
109408
109409
109410
109411
109412
109413
109414
109415
109416
109417
109418
109419
109420
109421
109422
109423
109424
109425
109426
109427
109428
109429
109430
109431
109432
109433
109434
109435
109436
109437
109438
109439
109440
109441
109442
109443
109444
109445
109446
109447
109448
109449
109450
109451
109452
109453
109454
109455
109456
109457
109458
109459
109460
109461
109462
109463
109464
109465
109466
109467
109468
109469
109470
109471
109472
109473
109474
109475
109476
109477
109478
109479
109480
109481
109482
109483
109484
109485
109486
109487
109488
109489
109490
109491
109492
109493
109494
109495
109496
109497
109498
109499
109500
109501
109502
109503
109504
109505
109506
109507
109508
109509
109510
109511
109512
109513
109514
109515
109516
109517
109518
109519
109520
109521
109522
109523
109524
109525
109526
109527
109528
109529
109530
109531
109532
109533
109534
109535
109536
109537
109538
109539
109540
109541
109542
109543
109544
109545
109546
109547
109548
109549
109550
109551
109552
109553
109554
109555
109556
109557
109558
109559
109560
109561
109562
109563
109564
109565
109566
109567
109568
109569
109570
109571
109572
109573
109574
109575
109576
109577
109578
109579
109580
109581
109582
109583
109584
109585
109586
109587
109588
109589
109590
109591
109592
109593
109594
109595
109596
109597
109598
109599
109600
109601
109602
109603
109604
109605
109606
109607
109608
109609
109610
109611
109612
109613
109614
109615
109616
109617
109618
109619
109620
109621
109622
109623
109624
109625
109626
109627
109628
109629
109630
109631
109632
109633
109634
109635
109636
109637
109638
109639
109640
109641
109642
109643
109644
109645
109646
109647
109648
109649
109650
109651
109652
109653
109654
109655
109656
109657
109658
109659
109660
109661
109662
109663
109664
109665
109666
109667
109668
109669
109670
109671
109672
109673
109674
109675
109676
109677
109678
109679
109680
109681
109682
109683
109684
109685
109686
109687
109688
109689
109690
109691
109692
109693
109694
109695
109696
109697
109698
109699
109700
109701
109702
109703
109704
109705
109706
109707
109708
109709
109710
109711
109712
109713
109714
109715
109716
109717
109718
109719
109720
109721
109722
109723
109724
109725
109726
109727
109728
109729
109730
109731
109732
109733
109734
109735
109736
109737
109738
109739
109740
109741
109742
109743
109744
109745
109746
109747
109748
109749
109750
109751
109752
109753
109754
109755
109756
109757
109758
109759
109760
109761
109762
109763
109764
109765
109766
109767
109768
109769
109770
109771
109772
109773
109774
109775
109776
109777
109778
109779
109780
109781
109782
109783
109784
109785
109786
109787
109788
109789
109790
109791
109792
109793
109794
109795
109796
109797
109798
109799
109800
109801
109802
109803
109804
109805
109806
109807
109808
109809
109810
109811
109812
109813
109814
109815
109816
109817
109818
109819
109820
109821
109822
109823
109824
109825
109826
109827
109828
109829
109830
109831
109832
109833
109834
109835
109836
109837
109838
109839
109840
109841
109842
109843
109844
109845
109846
109847
109848
109849
109850
109851
109852
109853
109854
109855
109856
109857
109858
109859
109860
109861
109862
109863
109864
109865
109866
109867
109868
109869
109870
109871
109872
109873
109874
109875
109876
109877
109878
109879
109880
109881
109882
109883
109884
109885
109886
109887
109888
109889
109890
109891
109892
109893
109894
109895
109896
109897
109898
109899
109900
109901
109902
109903
109904
109905
109906
109907
109908
109909
109910
109911
109912
109913
109914
109915
109916
109917
109918
109919
109920
109921
109922
109923
109924
109925
109926
109927
109928
109929
109930
109931
109932
109933
109934
109935
109936
109937
109938
109939
109940
109941
109942
109943
109944
109945
109946
109947
109948
109949
109950
109951
109952
109953
109954
109955
109956
109957
109958
109959
109960
109961
109962
109963
109964
109965
109966
109967
109968
109969
109970
109971
109972
109973
109974
109975
109976
109977
109978
109979
109980
109981
109982
109983
109984
109985
109986
109987
109988
109989
109990
109991
109992
109993
109994
109995
109996
109997
109998
109999
110000
110001
110002
110003
110004
110005
110006
110007
110008
110009
110010
110011
110012
110013
110014
110015
110016
110017
110018
110019
110020
110021
110022
110023
110024
110025
110026
110027
110028
110029
110030
110031
110032
110033
110034
110035
110036
110037
110038
110039
110040
110041
110042
110043
110044
110045
110046
110047
110048
110049
110050
110051
110052
110053
110054
110055
110056
110057
110058
110059
110060
110061
110062
110063
110064
110065
110066
110067
110068
110069
110070
110071
110072
110073
110074
110075
110076
110077
110078
110079
110080
110081
110082
110083
110084
110085
110086
110087
110088
110089
110090
110091
110092
110093
110094
110095
110096
110097
110098
110099
110100
110101
110102
110103
110104
110105
110106
110107
110108
110109
110110
110111
110112
110113
110114
110115
110116
110117
110118
110119
110120
110121
110122
110123
110124
110125
110126
110127
110128
110129
110130
110131
110132
110133
110134
110135
110136
110137
110138
110139
110140
110141
110142
110143
110144
110145
110146
110147
110148
110149
110150
110151
110152
110153
110154
110155
110156
110157
110158
110159
110160
110161
110162
110163
110164
110165
110166
110167
110168
110169
110170
110171
110172
110173
110174
110175
110176
110177
110178
110179
110180
110181
110182
110183
110184
110185
110186
110187
110188
110189
110190
110191
110192
110193
110194
110195
110196
110197
110198
110199
110200
110201
110202
110203
110204
110205
110206
110207
110208
110209
110210
110211
110212
110213
110214
110215
110216
110217
110218
110219
110220
110221
110222
110223
110224
110225
110226
110227
110228
110229
110230
110231
110232
110233
110234
110235
110236
110237
110238
110239
110240
110241
110242
110243
110244
110245
110246
110247
110248
110249
110250
110251
110252
110253
110254
110255
110256
110257
110258
110259
110260
110261
110262
110263
110264
110265
110266
110267
110268
110269
110270
110271
110272
110273
110274
110275
110276
110277
110278
110279
110280
110281
110282
110283
110284
110285
110286
110287
110288
110289
110290
110291
110292
110293
110294
110295
110296
110297
110298
110299
110300
110301
110302
110303
110304
110305
110306
110307
110308
110309
110310
110311
110312
110313
110314
110315
110316
110317
110318
110319
110320
110321
110322
110323
110324
110325
110326
110327
110328
110329
110330
110331
110332
110333
110334
110335
110336
110337
110338
110339
110340
110341
110342
110343
110344
110345
110346
110347
110348
110349
110350
110351
110352
110353
110354
110355
110356
110357
110358
110359
110360
110361
110362
110363
110364
110365
110366
110367
110368
110369
110370
110371
110372
110373
110374
110375
110376
110377
110378
110379
110380
110381
110382
110383
110384
110385
110386
110387
110388
110389
110390
110391
110392
110393
110394
110395
110396
110397
110398
110399
110400
110401
110402
110403
110404
110405
110406
110407
110408
110409
110410
110411
110412
110413
110414
110415
110416
110417
110418
110419
110420
110421
110422
110423
110424
110425
110426
110427
110428
110429
110430
110431
110432
110433
110434
110435
110436
110437
110438
110439
110440
110441
110442
110443
110444
110445
110446
110447
110448
110449
110450
110451
110452
110453
110454
110455
110456
110457
110458
110459
110460
110461
110462
110463
110464
110465
110466
110467
110468
110469
110470
110471
110472
110473
110474
110475
110476
110477
110478
110479
110480
110481
110482
110483
110484
110485
110486
110487
110488
110489
110490
110491
110492
110493
110494
110495
110496
110497
110498
110499
110500
110501
110502
110503
110504
110505
110506
110507
110508
110509
110510
110511
110512
110513
110514
110515
110516
110517
110518
110519
110520
110521
110522
110523
110524
110525
110526
110527
110528
110529
110530
110531
110532
110533
110534
110535
110536
110537
110538
110539
110540
110541
110542
110543
110544
110545
110546
110547
110548
110549
110550
110551
110552
110553
110554
110555
110556
110557
110558
110559
110560
110561
110562
110563
110564
110565
110566
110567
110568
110569
110570
110571
110572
110573
110574
110575
110576
110577
110578
110579
110580
110581
110582
110583
110584
110585
110586
110587
110588
110589
110590
110591
110592
110593
110594
110595
110596
110597
110598
110599
110600
110601
110602
110603
110604
110605
110606
110607
110608
110609
110610
110611
110612
110613
110614
110615
110616
110617
110618
110619
110620
110621
110622
110623
110624
110625
110626
110627
110628
110629
110630
110631
110632
110633
110634
110635
110636
110637
110638
110639
110640
110641
110642
110643
110644
110645
110646
110647
110648
110649
110650
110651
110652
110653
110654
110655
110656
110657
110658
110659
110660
110661
110662
110663
110664
110665
110666
110667
110668
110669
110670
110671
110672
110673
110674
110675
110676
110677
110678
110679
110680
110681
110682
110683
110684
110685
110686
110687
110688
110689
110690
110691
110692
110693
110694
110695
110696
110697
110698
110699
110700
110701
110702
110703
110704
110705
110706
110707
110708
110709
110710
110711
110712
110713
110714
110715
110716
110717
110718
110719
110720
110721
110722
110723
110724
110725
110726
110727
110728
110729
110730
110731
110732
110733
110734
110735
110736
110737
110738
110739
110740
110741
110742
110743
110744
110745
110746
110747
110748
110749
110750
110751
110752
110753
110754
110755
110756
110757
110758
110759
110760
110761
110762
110763
110764
110765
110766
110767
110768
110769
110770
110771
110772
110773
110774
110775
110776
110777
110778
110779
110780
110781
110782
110783
110784
110785
110786
110787
110788
110789
110790
110791
110792
110793
110794
110795
110796
110797
110798
110799
110800
110801
110802
110803
110804
110805
110806
110807
110808
110809
110810
110811
110812
110813
110814
110815
110816
110817
110818
110819
110820
110821
110822
110823
110824
110825
110826
110827
110828
110829
110830
110831
110832
110833
110834
110835
110836
110837
110838
110839
110840
110841
110842
110843
110844
110845
110846
110847
110848
110849
110850
110851
110852
110853
110854
110855
110856
110857
110858
110859
110860
110861
110862
110863
110864
110865
110866
110867
110868
110869
110870
110871
110872
110873
110874
110875
110876
110877
110878
110879
110880
110881
110882
110883
110884
110885
110886
110887
110888
110889
110890
110891
110892
110893
110894
110895
110896
110897
110898
110899
110900
110901
110902
110903
110904
110905
110906
110907
110908
110909
110910
110911
110912
110913
110914
110915
110916
110917
110918
110919
110920
110921
110922
110923
110924
110925
110926
110927
110928
110929
110930
110931
110932
110933
110934
110935
110936
110937
110938
110939
110940
110941
110942
110943
110944
110945
110946
110947
110948
110949
110950
110951
110952
110953
110954
110955
110956
110957
110958
110959
110960
110961
110962
110963
110964
110965
110966
110967
110968
110969
110970
110971
110972
110973
110974
110975
110976
110977
110978
110979
110980
110981
110982
110983
110984
110985
110986
110987
110988
110989
110990
110991
110992
110993
110994
110995
110996
110997
110998
110999
111000
111001
111002
111003
111004
111005
111006
111007
111008
111009
111010
111011
111012
111013
111014
111015
111016
111017
111018
111019
111020
111021
111022
111023
111024
111025
111026
111027
111028
111029
111030
111031
111032
111033
111034
111035
111036
111037
111038
111039
111040
111041
111042
111043
111044
111045
111046
111047
111048
111049
111050
111051
111052
111053
111054
111055
111056
111057
111058
111059
111060
111061
111062
111063
111064
111065
111066
111067
111068
111069
111070
111071
111072
111073
111074
111075
111076
111077
111078
111079
111080
111081
111082
111083
111084
111085
111086
111087
111088
111089
111090
111091
111092
111093
111094
111095
111096
111097
111098
111099
111100
111101
111102
111103
111104
111105
111106
111107
111108
111109
111110
111111
111112
111113
111114
111115
111116
111117
111118
111119
111120
111121
111122
111123
111124
111125
111126
111127
111128
111129
111130
111131
111132
111133
111134
111135
111136
111137
111138
111139
111140
111141
111142
111143
111144
111145
111146
111147
111148
111149
111150
111151
111152
111153
111154
111155
111156
111157
111158
111159
111160
111161
111162
111163
111164
111165
111166
111167
111168
111169
111170
111171
111172
111173
111174
111175
111176
111177
111178
111179
111180
111181
111182
111183
111184
111185
111186
111187
111188
111189
111190
111191
111192
111193
111194
111195
111196
111197
111198
111199
111200
111201
111202
111203
111204
111205
111206
111207
111208
111209
111210
111211
111212
111213
111214
111215
111216
111217
111218
111219
111220
111221
111222
111223
111224
111225
111226
111227
111228
111229
111230
111231
111232
111233
111234
111235
111236
111237
111238
111239
111240
111241
111242
111243
111244
111245
111246
111247
111248
111249
111250
111251
111252
111253
111254
111255
111256
111257
111258
111259
111260
111261
111262
111263
111264
111265
111266
111267
111268
111269
111270
111271
111272
111273
111274
111275
111276
111277
111278
111279
111280
111281
111282
111283
111284
111285
111286
111287
111288
111289
111290
111291
111292
111293
111294
111295
111296
111297
111298
111299
111300
111301
111302
111303
111304
111305
111306
111307
111308
111309
111310
111311
111312
111313
111314
111315
111316
111317
111318
111319
111320
111321
111322
111323
111324
111325
111326
111327
111328
111329
111330
111331
111332
111333
111334
111335
111336
111337
111338
111339
111340
111341
111342
111343
111344
111345
111346
111347
111348
111349
111350
111351
111352
111353
111354
111355
111356
111357
111358
111359
111360
111361
111362
111363
111364
111365
111366
111367
111368
111369
111370
111371
111372
111373
111374
111375
111376
111377
111378
111379
111380
111381
111382
111383
111384
111385
111386
111387
111388
111389
111390
111391
111392
111393
111394
111395
111396
111397
111398
111399
111400
111401
111402
111403
111404
111405
111406
111407
111408
111409
111410
111411
111412
111413
111414
111415
111416
111417
111418
111419
111420
111421
111422
111423
111424
111425
111426
111427
111428
111429
111430
111431
111432
111433
111434
111435
111436
111437
111438
111439
111440
111441
111442
111443
111444
111445
111446
111447
111448
111449
111450
111451
111452
111453
111454
111455
111456
111457
111458
111459
111460
111461
111462
111463
111464
111465
111466
111467
111468
111469
111470
111471
111472
111473
111474
111475
111476
111477
111478
111479
111480
111481
111482
111483
111484
111485
111486
111487
111488
111489
111490
111491
111492
111493
111494
111495
111496
111497
111498
111499
111500
111501
111502
111503
111504
111505
111506
111507
111508
111509
111510
111511
111512
111513
111514
111515
111516
111517
111518
111519
111520
111521
111522
111523
111524
111525
111526
111527
111528
111529
111530
111531
111532
111533
111534
111535
111536
111537
111538
111539
111540
111541
111542
111543
111544
111545
111546
111547
111548
111549
111550
111551
111552
111553
111554
111555
111556
111557
111558
111559
111560
111561
111562
111563
111564
111565
111566
111567
111568
111569
111570
111571
111572
111573
111574
111575
111576
111577
111578
111579
111580
111581
111582
111583
111584
111585
111586
111587
111588
111589
111590
111591
111592
111593
111594
111595
111596
111597
111598
111599
111600
111601
111602
111603
111604
111605
111606
111607
111608
111609
111610
111611
111612
111613
111614
111615
111616
111617
111618
111619
111620
111621
111622
111623
111624
111625
111626
111627
111628
111629
111630
111631
111632
111633
111634
111635
111636
111637
111638
111639
111640
111641
111642
111643
111644
111645
111646
111647
111648
111649
111650
111651
111652
111653
111654
111655
111656
111657
111658
111659
111660
111661
111662
111663
111664
111665
111666
111667
111668
111669
111670
111671
111672
111673
111674
111675
111676
111677
111678
111679
111680
111681
111682
111683
111684
111685
111686
111687
111688
111689
111690
111691
111692
111693
111694
111695
111696
111697
111698
111699
111700
111701
111702
111703
111704
111705
111706
111707
111708
111709
111710
111711
111712
111713
111714
111715
111716
111717
111718
111719
111720
111721
111722
111723
111724
111725
111726
111727
111728
111729
111730
111731
111732
111733
111734
111735
111736
111737
111738
111739
111740
111741
111742
111743
111744
111745
111746
111747
111748
111749
111750
111751
111752
111753
111754
111755
111756
111757
111758
111759
111760
111761
111762
111763
111764
111765
111766
111767
111768
111769
111770
111771
111772
111773
111774
111775
111776
111777
111778
111779
111780
111781
111782
111783
111784
111785
111786
111787
111788
111789
111790
111791
111792
111793
111794
111795
111796
111797
111798
111799
111800
111801
111802
111803
111804
111805
111806
111807
111808
111809
111810
111811
111812
111813
111814
111815
111816
111817
111818
111819
111820
111821
111822
111823
111824
111825
111826
111827
111828
111829
111830
111831
111832
111833
111834
111835
111836
111837
111838
111839
111840
111841
111842
111843
111844
111845
111846
111847
111848
111849
111850
111851
111852
111853
111854
111855
111856
111857
111858
111859
111860
111861
111862
111863
111864
111865
111866
111867
111868
111869
111870
111871
111872
111873
111874
111875
111876
111877
111878
111879
111880
111881
111882
111883
111884
111885
111886
111887
111888
111889
111890
111891
111892
111893
111894
111895
111896
111897
111898
111899
111900
111901
111902
111903
111904
111905
111906
111907
111908
111909
111910
111911
111912
111913
111914
111915
111916
111917
111918
111919
111920
111921
111922
111923
111924
111925
111926
111927
111928
111929
111930
111931
111932
111933
111934
111935
111936
111937
111938
111939
111940
111941
111942
111943
111944
111945
111946
111947
111948
111949
111950
111951
111952
111953
111954
111955
111956
111957
111958
111959
111960
111961
111962
111963
111964
111965
111966
111967
111968
111969
111970
111971
111972
111973
111974
111975
111976
111977
111978
111979
111980
111981
111982
111983
111984
111985
111986
111987
111988
111989
111990
111991
111992
111993
111994
111995
111996
111997
111998
111999
112000
112001
112002
112003
112004
112005
112006
112007
112008
112009
112010
112011
112012
112013
112014
112015
112016
112017
112018
112019
112020
112021
112022
112023
112024
112025
112026
112027
112028
112029
112030
112031
112032
112033
112034
112035
112036
112037
112038
112039
112040
112041
112042
112043
112044
112045
112046
112047
112048
112049
112050
112051
112052
112053
112054
112055
112056
112057
112058
112059
112060
112061
112062
112063
112064
112065
112066
112067
112068
112069
112070
112071
112072
112073
112074
112075
112076
112077
112078
112079
112080
112081
112082
112083
112084
112085
112086
112087
112088
112089
112090
112091
112092
112093
112094
112095
112096
112097
112098
112099
112100
112101
112102
112103
112104
112105
112106
112107
112108
112109
112110
112111
112112
112113
112114
112115
112116
112117
112118
112119
112120
112121
112122
112123
112124
112125
112126
112127
112128
112129
112130
112131
112132
112133
112134
112135
112136
112137
112138
112139
112140
112141
112142
112143
112144
112145
112146
112147
112148
112149
112150
112151
112152
112153
112154
112155
112156
112157
112158
112159
112160
112161
112162
112163
112164
112165
112166
112167
112168
112169
112170
112171
112172
112173
112174
112175
112176
112177
112178
112179
112180
112181
112182
112183
112184
112185
112186
112187
112188
112189
112190
112191
112192
112193
112194
112195
112196
112197
112198
112199
112200
112201
112202
112203
112204
112205
112206
112207
112208
112209
112210
112211
112212
112213
112214
112215
112216
112217
112218
112219
112220
112221
112222
112223
112224
112225
112226
112227
112228
112229
112230
112231
112232
112233
112234
112235
112236
112237
112238
112239
112240
112241
112242
112243
112244
112245
112246
112247
112248
112249
112250
112251
112252
112253
112254
112255
112256
112257
112258
112259
112260
112261
112262
112263
112264
112265
112266
112267
112268
112269
112270
112271
112272
112273
112274
112275
112276
112277
112278
112279
112280
112281
112282
112283
112284
112285
112286
112287
112288
112289
112290
112291
112292
112293
112294
112295
112296
112297
112298
112299
112300
112301
112302
112303
112304
112305
112306
112307
112308
112309
112310
112311
112312
112313
112314
112315
112316
112317
112318
112319
112320
112321
112322
112323
112324
112325
112326
112327
112328
112329
112330
112331
112332
112333
112334
112335
112336
112337
112338
112339
112340
112341
112342
112343
112344
112345
112346
112347
112348
112349
112350
112351
112352
112353
112354
112355
112356
112357
112358
112359
112360
112361
112362
112363
112364
112365
112366
112367
112368
112369
112370
112371
112372
112373
112374
112375
112376
112377
112378
112379
112380
112381
112382
112383
112384
112385
112386
112387
112388
112389
112390
112391
112392
112393
112394
112395
112396
112397
112398
112399
112400
112401
112402
112403
112404
112405
112406
112407
112408
112409
112410
112411
112412
112413
112414
112415
112416
112417
112418
112419
112420
112421
112422
112423
112424
112425
112426
112427
112428
112429
112430
112431
112432
112433
112434
112435
112436
112437
112438
112439
112440
112441
112442
112443
112444
112445
112446
112447
112448
112449
112450
112451
112452
112453
112454
112455
112456
112457
112458
112459
112460
112461
112462
112463
112464
112465
112466
112467
112468
112469
112470
112471
112472
112473
112474
112475
112476
112477
112478
112479
112480
112481
112482
112483
112484
112485
112486
112487
112488
112489
112490
112491
112492
112493
112494
112495
112496
112497
112498
112499
112500
112501
112502
112503
112504
112505
112506
112507
112508
112509
112510
112511
112512
112513
112514
112515
112516
112517
112518
112519
112520
112521
112522
112523
112524
112525
112526
112527
112528
112529
112530
112531
112532
112533
112534
112535
112536
112537
112538
112539
112540
112541
112542
112543
112544
112545
112546
112547
112548
112549
112550
112551
112552
112553
112554
112555
112556
112557
112558
112559
112560
112561
112562
112563
112564
112565
112566
112567
112568
112569
112570
112571
112572
112573
112574
112575
112576
112577
112578
112579
112580
112581
112582
112583
112584
112585
112586
112587
112588
112589
112590
112591
112592
112593
112594
112595
112596
112597
112598
112599
112600
112601
112602
112603
112604
112605
112606
112607
112608
112609
112610
112611
112612
112613
112614
112615
112616
112617
112618
112619
112620
112621
112622
112623
112624
112625
112626
112627
112628
112629
112630
112631
112632
112633
112634
112635
112636
112637
112638
112639
112640
112641
112642
112643
112644
112645
112646
112647
112648
112649
112650
112651
112652
112653
112654
112655
112656
112657
112658
112659
112660
112661
112662
112663
112664
112665
112666
112667
112668
112669
112670
112671
112672
112673
112674
112675
112676
112677
112678
112679
112680
112681
112682
112683
112684
112685
112686
112687
112688
112689
112690
112691
112692
112693
112694
112695
112696
112697
112698
112699
112700
112701
112702
112703
112704
112705
112706
112707
112708
112709
112710
112711
112712
112713
112714
112715
112716
112717
112718
112719
112720
112721
112722
112723
112724
112725
112726
112727
112728
112729
112730
112731
112732
112733
112734
112735
112736
112737
112738
112739
112740
112741
112742
112743
112744
112745
112746
112747
112748
112749
112750
112751
112752
112753
112754
112755
112756
112757
112758
112759
112760
112761
112762
112763
112764
112765
112766
112767
112768
112769
112770
112771
112772
112773
112774
112775
112776
112777
112778
112779
112780
112781
112782
112783
112784
112785
112786
112787
112788
112789
112790
112791
112792
112793
112794
112795
112796
112797
112798
112799
112800
112801
112802
112803
112804
112805
112806
112807
112808
112809
112810
112811
112812
112813
112814
112815
112816
112817
112818
112819
112820
112821
112822
112823
112824
112825
112826
112827
112828
112829
112830
112831
112832
112833
112834
112835
112836
112837
112838
112839
112840
112841
112842
112843
112844
112845
112846
112847
112848
112849
112850
112851
112852
112853
112854
112855
112856
112857
112858
112859
112860
112861
112862
112863
112864
112865
112866
112867
112868
112869
112870
112871
112872
112873
112874
112875
112876
112877
112878
112879
112880
112881
112882
112883
112884
112885
112886
112887
112888
112889
112890
112891
112892
112893
112894
112895
112896
112897
112898
112899
112900
112901
112902
112903
112904
112905
112906
112907
112908
112909
112910
112911
112912
112913
112914
112915
112916
112917
112918
112919
112920
112921
112922
112923
112924
112925
112926
112927
112928
112929
112930
112931
112932
112933
112934
112935
112936
112937
112938
112939
112940
112941
112942
112943
112944
112945
112946
112947
112948
112949
112950
112951
112952
112953
112954
112955
112956
112957
112958
112959
112960
112961
112962
112963
112964
112965
112966
112967
112968
112969
112970
112971
112972
112973
112974
112975
112976
112977
112978
112979
112980
112981
112982
112983
112984
112985
112986
112987
112988
112989
112990
112991
112992
112993
112994
112995
112996
112997
112998
112999
113000
113001
113002
113003
113004
113005
113006
113007
113008
113009
113010
113011
113012
113013
113014
113015
113016
113017
113018
113019
113020
113021
113022
113023
113024
113025
113026
113027
113028
113029
113030
113031
113032
113033
113034
113035
113036
113037
113038
113039
113040
113041
113042
113043
113044
113045
113046
113047
113048
113049
113050
113051
113052
113053
113054
113055
113056
113057
113058
113059
113060
113061
113062
113063
113064
113065
113066
113067
113068
113069
113070
113071
113072
113073
113074
113075
113076
113077
113078
113079
113080
113081
113082
113083
113084
113085
113086
113087
113088
113089
113090
113091
113092
113093
113094
113095
113096
113097
113098
113099
113100
113101
113102
113103
113104
113105
113106
113107
113108
113109
113110
113111
113112
113113
113114
113115
113116
113117
113118
113119
113120
113121
113122
113123
113124
113125
113126
113127
113128
113129
113130
113131
113132
113133
113134
113135
113136
113137
113138
113139
113140
113141
113142
113143
113144
113145
113146
113147
113148
113149
113150
113151
113152
113153
113154
113155
113156
113157
113158
113159
113160
113161
113162
113163
113164
113165
113166
113167
113168
113169
113170
113171
113172
113173
113174
113175
113176
113177
113178
113179
113180
113181
113182
113183
113184
113185
113186
113187
113188
113189
113190
113191
113192
113193
113194
113195
113196
113197
113198
113199
113200
113201
113202
113203
113204
113205
113206
113207
113208
113209
113210
113211
113212
113213
113214
113215
113216
113217
113218
113219
113220
113221
113222
113223
113224
113225
113226
113227
113228
113229
113230
113231
113232
113233
113234
113235
113236
113237
113238
113239
113240
113241
113242
113243
113244
113245
113246
113247
113248
113249
113250
113251
113252
113253
113254
113255
113256
113257
113258
113259
113260
113261
113262
113263
113264
113265
113266
113267
113268
113269
113270
113271
113272
113273
113274
113275
113276
113277
113278
113279
113280
113281
113282
113283
113284
113285
113286
113287
113288
113289
113290
113291
113292
113293
113294
113295
113296
113297
113298
113299
113300
113301
113302
113303
113304
113305
113306
113307
113308
113309
113310
113311
113312
113313
113314
113315
113316
113317
113318
113319
113320
113321
113322
113323
113324
113325
113326
113327
113328
113329
113330
113331
113332
113333
113334
113335
113336
113337
113338
113339
113340
113341
113342
113343
113344
113345
113346
113347
113348
113349
113350
113351
113352
113353
113354
113355
113356
113357
113358
113359
113360
113361
113362
113363
113364
113365
113366
113367
113368
113369
113370
113371
113372
113373
113374
113375
113376
113377
113378
113379
113380
113381
113382
113383
113384
113385
113386
113387
113388
113389
113390
113391
113392
113393
113394
113395
113396
113397
113398
113399
113400
113401
113402
113403
113404
113405
113406
113407
113408
113409
113410
113411
113412
113413
113414
113415
113416
113417
113418
113419
113420
113421
113422
113423
113424
113425
113426
113427
113428
113429
113430
113431
113432
113433
113434
113435
113436
113437
113438
113439
113440
113441
113442
113443
113444
113445
113446
113447
113448
113449
113450
113451
113452
113453
113454
113455
113456
113457
113458
113459
113460
113461
113462
113463
113464
113465
113466
113467
113468
113469
113470
113471
113472
113473
113474
113475
113476
113477
113478
113479
113480
113481
113482
113483
113484
113485
113486
113487
113488
113489
113490
113491
113492
113493
113494
113495
113496
113497
113498
113499
113500
113501
113502
113503
113504
113505
113506
113507
113508
113509
113510
113511
113512
113513
113514
113515
113516
113517
113518
113519
113520
113521
113522
113523
113524
113525
113526
113527
113528
113529
113530
113531
113532
113533
113534
113535
113536
113537
113538
113539
113540
113541
113542
113543
113544
113545
113546
113547
113548
113549
113550
113551
113552
113553
113554
113555
113556
113557
113558
113559
113560
113561
113562
113563
113564
113565
113566
113567
113568
113569
113570
113571
113572
113573
113574
113575
113576
113577
113578
113579
113580
113581
113582
113583
113584
113585
113586
113587
113588
113589
113590
113591
113592
113593
113594
113595
113596
113597
113598
113599
113600
113601
113602
113603
113604
113605
113606
113607
113608
113609
113610
113611
113612
113613
113614
113615
113616
113617
113618
113619
113620
113621
113622
113623
113624
113625
113626
113627
113628
113629
113630
113631
113632
113633
113634
113635
113636
113637
113638
113639
113640
113641
113642
113643
113644
113645
113646
113647
113648
113649
113650
113651
113652
113653
113654
113655
113656
113657
113658
113659
113660
113661
113662
113663
113664
113665
113666
113667
113668
113669
113670
113671
113672
113673
113674
113675
113676
113677
113678
113679
113680
113681
113682
113683
113684
113685
113686
113687
113688
113689
113690
113691
113692
113693
113694
113695
113696
113697
113698
113699
113700
113701
113702
113703
113704
113705
113706
113707
113708
113709
113710
113711
113712
113713
113714
113715
113716
113717
113718
113719
113720
113721
113722
113723
113724
113725
113726
113727
113728
113729
113730
113731
113732
113733
113734
113735
113736
113737
113738
113739
113740
113741
113742
113743
113744
113745
113746
113747
113748
113749
113750
113751
113752
113753
113754
113755
113756
113757
113758
113759
113760
113761
113762
113763
113764
113765
113766
113767
113768
113769
113770
113771
113772
113773
113774
113775
113776
113777
113778
113779
113780
113781
113782
113783
113784
113785
113786
113787
113788
113789
113790
113791
113792
113793
113794
113795
113796
113797
113798
113799
113800
113801
113802
113803
113804
113805
113806
113807
113808
113809
113810
113811
113812
113813
113814
113815
113816
113817
113818
113819
113820
113821
113822
113823
113824
113825
113826
113827
113828
113829
113830
113831
113832
113833
113834
113835
113836
113837
113838
113839
113840
113841
113842
113843
113844
113845
113846
113847
113848
113849
113850
113851
113852
113853
113854
113855
113856
113857
113858
113859
113860
113861
113862
113863
113864
113865
113866
113867
113868
113869
113870
113871
113872
113873
113874
113875
113876
113877
113878
113879
113880
113881
113882
113883
113884
113885
113886
113887
113888
113889
113890
113891
113892
113893
113894
113895
113896
113897
113898
113899
113900
113901
113902
113903
113904
113905
113906
113907
113908
113909
113910
113911
113912
113913
113914
113915
113916
113917
113918
113919
113920
113921
113922
113923
113924
113925
113926
113927
113928
113929
113930
113931
113932
113933
113934
113935
113936
113937
113938
113939
113940
113941
113942
113943
113944
113945
113946
113947
113948
113949
113950
113951
113952
113953
113954
113955
113956
113957
113958
113959
113960
113961
113962
113963
113964
113965
113966
113967
113968
113969
113970
113971
113972
113973
113974
113975
113976
113977
113978
113979
113980
113981
113982
113983
113984
113985
113986
113987
113988
113989
113990
113991
113992
113993
113994
113995
113996
113997
113998
113999
114000
114001
114002
114003
114004
114005
114006
114007
114008
114009
114010
114011
114012
114013
114014
114015
114016
114017
114018
114019
114020
114021
114022
114023
114024
114025
114026
114027
114028
114029
114030
114031
114032
114033
114034
114035
114036
114037
114038
114039
114040
114041
114042
114043
114044
114045
114046
114047
114048
114049
114050
114051
114052
114053
114054
114055
114056
114057
114058
114059
114060
114061
114062
114063
114064
114065
114066
114067
114068
114069
114070
114071
114072
114073
114074
114075
114076
114077
114078
114079
114080
114081
114082
114083
114084
114085
114086
114087
114088
114089
114090
114091
114092
114093
114094
114095
114096
114097
114098
114099
114100
114101
114102
114103
114104
114105
114106
114107
114108
114109
114110
114111
114112
114113
114114
114115
114116
114117
114118
114119
114120
114121
114122
114123
114124
114125
114126
114127
114128
114129
114130
114131
114132
114133
114134
114135
114136
114137
114138
114139
114140
114141
114142
114143
114144
114145
114146
114147
114148
114149
114150
114151
114152
114153
114154
114155
114156
114157
114158
114159
114160
114161
114162
114163
114164
114165
114166
114167
114168
114169
114170
114171
114172
114173
114174
114175
114176
114177
114178
114179
114180
114181
114182
114183
114184
114185
114186
114187
114188
114189
114190
114191
114192
114193
114194
114195
114196
114197
114198
114199
114200
114201
114202
114203
114204
114205
114206
114207
114208
114209
114210
114211
114212
114213
114214
114215
114216
114217
114218
114219
114220
114221
114222
114223
114224
114225
114226
114227
114228
114229
114230
114231
114232
114233
114234
114235
114236
114237
114238
114239
114240
114241
114242
114243
114244
114245
114246
114247
114248
114249
114250
114251
114252
114253
114254
114255
114256
114257
114258
114259
114260
114261
114262
114263
114264
114265
114266
114267
114268
114269
114270
114271
114272
114273
114274
114275
114276
114277
114278
114279
114280
114281
114282
114283
114284
114285
114286
114287
114288
114289
114290
114291
114292
114293
114294
114295
114296
114297
114298
114299
114300
114301
114302
114303
114304
114305
114306
114307
114308
114309
114310
114311
114312
114313
114314
114315
114316
114317
114318
114319
114320
114321
114322
114323
114324
114325
114326
114327
114328
114329
114330
114331
114332
114333
114334
114335
114336
114337
114338
114339
114340
114341
114342
114343
114344
114345
114346
114347
114348
114349
114350
114351
114352
114353
114354
114355
114356
114357
114358
114359
114360
114361
114362
114363
114364
114365
114366
114367
114368
114369
114370
114371
114372
114373
114374
114375
114376
114377
114378
114379
114380
114381
114382
114383
114384
114385
114386
114387
114388
114389
114390
114391
114392
114393
114394
114395
114396
114397
114398
114399
114400
114401
114402
114403
114404
114405
114406
114407
114408
114409
114410
114411
114412
114413
114414
114415
114416
114417
114418
114419
114420
114421
114422
114423
114424
114425
114426
114427
114428
114429
114430
114431
114432
114433
114434
114435
114436
114437
114438
114439
114440
114441
114442
114443
114444
114445
114446
114447
114448
114449
114450
114451
114452
114453
114454
114455
114456
114457
114458
114459
114460
114461
114462
114463
114464
114465
114466
114467
114468
114469
114470
114471
114472
114473
114474
114475
114476
114477
114478
114479
114480
114481
114482
114483
114484
114485
114486
114487
114488
114489
114490
114491
114492
114493
114494
114495
114496
114497
114498
114499
114500
114501
114502
114503
114504
114505
114506
114507
114508
114509
114510
114511
114512
114513
114514
114515
114516
114517
114518
114519
114520
114521
114522
114523
114524
114525
114526
114527
114528
114529
114530
114531
114532
114533
114534
114535
114536
114537
114538
114539
114540
114541
114542
114543
114544
114545
114546
114547
114548
114549
114550
114551
114552
114553
114554
114555
114556
114557
114558
114559
114560
114561
114562
114563
114564
114565
114566
114567
114568
114569
114570
114571
114572
114573
114574
114575
114576
114577
114578
114579
114580
114581
114582
114583
114584
114585
114586
114587
114588
114589
114590
114591
114592
114593
114594
114595
114596
114597
114598
114599
114600
114601
114602
114603
114604
114605
114606
114607
114608
114609
114610
114611
114612
114613
114614
114615
114616
114617
114618
114619
114620
114621
114622
114623
114624
114625
114626
114627
114628
114629
114630
114631
114632
114633
114634
114635
114636
114637
114638
114639
114640
114641
114642
114643
114644
114645
114646
114647
114648
114649
114650
114651
114652
114653
114654
114655
114656
114657
114658
114659
114660
114661
114662
114663
114664
114665
114666
114667
114668
114669
114670
114671
114672
114673
114674
114675
114676
114677
114678
114679
114680
114681
114682
114683
114684
114685
114686
114687
114688
114689
114690
114691
114692
114693
114694
114695
114696
114697
114698
114699
114700
114701
114702
114703
114704
114705
114706
114707
114708
114709
114710
114711
114712
114713
114714
114715
114716
114717
114718
114719
114720
114721
114722
114723
114724
114725
114726
114727
114728
114729
114730
114731
114732
114733
114734
114735
114736
114737
114738
114739
114740
114741
114742
114743
114744
114745
114746
114747
114748
114749
114750
114751
114752
114753
114754
114755
114756
114757
114758
114759
114760
114761
114762
114763
114764
114765
114766
114767
114768
114769
114770
114771
114772
114773
114774
114775
114776
114777
114778
114779
114780
114781
114782
114783
114784
114785
114786
114787
114788
114789
114790
114791
114792
114793
114794
114795
114796
114797
114798
114799
114800
114801
114802
114803
114804
114805
114806
114807
114808
114809
114810
114811
114812
114813
114814
114815
114816
114817
114818
114819
114820
114821
114822
114823
114824
114825
114826
114827
114828
114829
114830
114831
114832
114833
114834
114835
114836
114837
114838
114839
114840
114841
114842
114843
114844
114845
114846
114847
114848
114849
114850
114851
114852
114853
114854
114855
114856
114857
114858
114859
114860
114861
114862
114863
114864
114865
114866
114867
114868
114869
114870
114871
114872
114873
114874
114875
114876
114877
114878
114879
114880
114881
114882
114883
114884
114885
114886
114887
114888
114889
114890
114891
114892
114893
114894
114895
114896
114897
114898
114899
114900
114901
114902
114903
114904
114905
114906
114907
114908
114909
114910
114911
114912
114913
114914
114915
114916
114917
114918
114919
114920
114921
114922
114923
114924
114925
114926
114927
114928
114929
114930
114931
114932
114933
114934
114935
114936
114937
114938
114939
114940
114941
114942
114943
114944
114945
114946
114947
114948
114949
114950
114951
114952
114953
114954
114955
114956
114957
114958
114959
114960
114961
114962
114963
114964
114965
114966
114967
114968
114969
114970
114971
114972
114973
114974
114975
114976
114977
114978
114979
114980
114981
114982
114983
114984
114985
114986
114987
114988
114989
114990
114991
114992
114993
114994
114995
114996
114997
114998
114999
115000
115001
115002
115003
115004
115005
115006
115007
115008
115009
115010
115011
115012
115013
115014
115015
115016
115017
115018
115019
115020
115021
115022
115023
115024
115025
115026
115027
115028
115029
115030
115031
115032
115033
115034
115035
115036
115037
115038
115039
115040
115041
115042
115043
115044
115045
115046
115047
115048
115049
115050
115051
115052
115053
115054
115055
115056
115057
115058
115059
115060
115061
115062
115063
115064
115065
115066
115067
115068
115069
115070
115071
115072
115073
115074
115075
115076
115077
115078
115079
115080
115081
115082
115083
115084
115085
115086
115087
115088
115089
115090
115091
115092
115093
115094
115095
115096
115097
115098
115099
115100
115101
115102
115103
115104
115105
115106
115107
115108
115109
115110
115111
115112
115113
115114
115115
115116
115117
115118
115119
115120
115121
115122
115123
115124
115125
115126
115127
115128
115129
115130
115131
115132
115133
115134
115135
115136
115137
115138
115139
115140
115141
115142
115143
115144
115145
115146
115147
115148
115149
115150
115151
115152
115153
115154
115155
115156
115157
115158
115159
115160
115161
115162
115163
115164
115165
115166
115167
115168
115169
115170
115171
115172
115173
115174
115175
115176
115177
115178
115179
115180
115181
115182
115183
115184
115185
115186
115187
115188
115189
115190
115191
115192
115193
115194
115195
115196
115197
115198
115199
115200
115201
115202
115203
115204
115205
115206
115207
115208
115209
115210
115211
115212
115213
115214
115215
115216
115217
115218
115219
115220
115221
115222
115223
115224
115225
115226
115227
115228
115229
115230
115231
115232
115233
115234
115235
115236
115237
115238
115239
115240
115241
115242
115243
115244
115245
115246
115247
115248
115249
115250
115251
115252
115253
115254
115255
115256
115257
115258
115259
115260
115261
115262
115263
115264
115265
115266
115267
115268
115269
115270
115271
115272
115273
115274
115275
115276
115277
115278
115279
115280
115281
115282
115283
115284
115285
115286
115287
115288
115289
115290
115291
115292
115293
115294
115295
115296
115297
115298
115299
115300
115301
115302
115303
115304
115305
115306
115307
115308
115309
115310
115311
115312
115313
115314
115315
115316
115317
115318
115319
115320
115321
115322
115323
115324
115325
115326
115327
115328
115329
115330
115331
115332
115333
115334
115335
115336
115337
115338
115339
115340
115341
115342
115343
115344
115345
115346
115347
115348
115349
115350
115351
115352
115353
115354
115355
115356
115357
115358
115359
115360
115361
115362
115363
115364
115365
115366
115367
115368
115369
115370
115371
115372
115373
115374
115375
115376
115377
115378
115379
115380
115381
115382
115383
115384
115385
115386
115387
115388
115389
115390
115391
115392
115393
115394
115395
115396
115397
115398
115399
115400
115401
115402
115403
115404
115405
115406
115407
115408
115409
115410
115411
115412
115413
115414
115415
115416
115417
115418
115419
115420
115421
115422
115423
115424
115425
115426
115427
115428
115429
115430
115431
115432
115433
115434
115435
115436
115437
115438
115439
115440
115441
115442
115443
115444
115445
115446
115447
115448
115449
115450
115451
115452
115453
115454
115455
115456
115457
115458
115459
115460
115461
115462
115463
115464
115465
115466
115467
115468
115469
115470
115471
115472
115473
115474
115475
115476
115477
115478
115479
115480
115481
115482
115483
115484
115485
115486
115487
115488
115489
115490
115491
115492
115493
115494
115495
115496
115497
115498
115499
115500
115501
115502
115503
115504
115505
115506
115507
115508
115509
115510
115511
115512
115513
115514
115515
115516
115517
115518
115519
115520
115521
115522
115523
115524
115525
115526
115527
115528
115529
115530
115531
115532
115533
115534
115535
115536
115537
115538
115539
115540
115541
115542
115543
115544
115545
115546
115547
115548
115549
115550
115551
115552
115553
115554
115555
115556
115557
115558
115559
115560
115561
115562
115563
115564
115565
115566
115567
115568
115569
115570
115571
115572
115573
115574
115575
115576
115577
115578
115579
115580
115581
115582
115583
115584
115585
115586
115587
115588
115589
115590
115591
115592
115593
115594
115595
115596
115597
115598
115599
115600
115601
115602
115603
115604
115605
115606
115607
115608
115609
115610
115611
115612
115613
115614
115615
115616
115617
115618
115619
115620
115621
115622
115623
115624
115625
115626
115627
115628
115629
115630
115631
115632
115633
115634
115635
115636
115637
115638
115639
115640
115641
115642
115643
115644
115645
115646
115647
115648
115649
115650
115651
115652
115653
115654
115655
115656
115657
115658
115659
115660
115661
115662
115663
115664
115665
115666
115667
115668
115669
115670
115671
115672
115673
115674
115675
115676
115677
115678
115679
115680
115681
115682
115683
115684
115685
115686
115687
115688
115689
115690
115691
115692
115693
115694
115695
115696
115697
115698
115699
115700
115701
115702
115703
115704
115705
115706
115707
115708
115709
115710
115711
115712
115713
115714
115715
115716
115717
115718
115719
115720
115721
115722
115723
115724
115725
115726
115727
115728
115729
115730
115731
115732
115733
115734
115735
115736
115737
115738
115739
115740
115741
115742
115743
115744
115745
115746
115747
115748
115749
115750
115751
115752
115753
115754
115755
115756
115757
115758
115759
115760
115761
115762
115763
115764
115765
115766
115767
115768
115769
115770
115771
115772
115773
115774
115775
115776
115777
115778
115779
115780
115781
115782
115783
115784
115785
115786
115787
115788
115789
115790
115791
115792
115793
115794
115795
115796
115797
115798
115799
115800
115801
115802
115803
115804
115805
115806
115807
115808
115809
115810
115811
115812
115813
115814
115815
115816
115817
115818
115819
115820
115821
115822
115823
115824
115825
115826
115827
115828
115829
115830
115831
115832
115833
115834
115835
115836
115837
115838
115839
115840
115841
115842
115843
115844
115845
115846
115847
115848
115849
115850
115851
115852
115853
115854
115855
115856
115857
115858
115859
115860
115861
115862
115863
115864
115865
115866
115867
115868
115869
115870
115871
115872
115873
115874
115875
115876
115877
115878
115879
115880
115881
115882
115883
115884
115885
115886
115887
115888
115889
115890
115891
115892
115893
115894
115895
115896
115897
115898
115899
115900
115901
115902
115903
115904
115905
115906
115907
115908
115909
115910
115911
115912
115913
115914
115915
115916
115917
115918
115919
115920
115921
115922
115923
115924
115925
115926
115927
115928
115929
115930
115931
115932
115933
115934
115935
115936
115937
115938
115939
115940
115941
115942
115943
115944
115945
115946
115947
115948
115949
115950
115951
115952
115953
115954
115955
115956
115957
115958
115959
115960
115961
115962
115963
115964
115965
115966
115967
115968
115969
115970
115971
115972
115973
115974
115975
115976
115977
115978
115979
115980
115981
115982
115983
115984
115985
115986
115987
115988
115989
115990
115991
115992
115993
115994
115995
115996
115997
115998
115999
116000
116001
116002
116003
116004
116005
116006
116007
116008
116009
116010
116011
116012
116013
116014
116015
116016
116017
116018
116019
116020
116021
116022
116023
116024
116025
116026
116027
116028
116029
116030
116031
116032
116033
116034
116035
116036
116037
116038
116039
116040
116041
116042
116043
116044
116045
116046
116047
116048
116049
116050
116051
116052
116053
116054
116055
116056
116057
116058
116059
116060
116061
116062
116063
116064
116065
116066
116067
116068
116069
116070
116071
116072
116073
116074
116075
116076
116077
116078
116079
116080
116081
116082
116083
116084
116085
116086
116087
116088
116089
116090
116091
116092
116093
116094
116095
116096
116097
116098
116099
116100
116101
116102
116103
116104
116105
116106
116107
116108
116109
116110
116111
116112
116113
116114
116115
116116
116117
116118
116119
116120
116121
116122
116123
116124
116125
116126
116127
116128
116129
116130
116131
116132
116133
116134
116135
116136
116137
116138
116139
116140
116141
116142
116143
116144
116145
116146
116147
116148
116149
116150
116151
116152
116153
116154
116155
116156
116157
116158
116159
116160
116161
116162
116163
116164
116165
116166
116167
116168
116169
116170
116171
116172
116173
116174
116175
116176
116177
116178
116179
116180
116181
116182
116183
116184
116185
116186
116187
116188
116189
116190
116191
116192
116193
116194
116195
116196
116197
116198
116199
116200
116201
116202
116203
116204
116205
116206
116207
116208
116209
116210
116211
116212
116213
116214
116215
116216
116217
116218
116219
116220
116221
116222
116223
116224
116225
116226
116227
116228
116229
116230
116231
116232
116233
116234
116235
116236
116237
116238
116239
116240
116241
116242
116243
116244
116245
116246
116247
116248
116249
116250
116251
116252
116253
116254
116255
116256
116257
116258
116259
116260
116261
116262
116263
116264
116265
116266
116267
116268
116269
116270
116271
116272
116273
116274
116275
116276
116277
116278
116279
116280
116281
116282
116283
116284
116285
116286
116287
116288
116289
116290
116291
116292
116293
116294
116295
116296
116297
116298
116299
116300
116301
116302
116303
116304
116305
116306
116307
116308
116309
116310
116311
116312
116313
116314
116315
116316
116317
116318
116319
116320
116321
116322
116323
116324
116325
116326
116327
116328
116329
116330
116331
116332
116333
116334
116335
116336
116337
116338
116339
116340
116341
116342
116343
116344
116345
116346
116347
116348
116349
116350
116351
116352
116353
116354
116355
116356
116357
116358
116359
116360
116361
116362
116363
116364
116365
116366
116367
116368
116369
116370
116371
116372
116373
116374
116375
116376
116377
116378
116379
116380
116381
116382
116383
116384
116385
116386
116387
116388
116389
116390
116391
116392
116393
116394
116395
116396
116397
116398
116399
116400
116401
116402
116403
116404
116405
116406
116407
116408
116409
116410
116411
116412
116413
116414
116415
116416
116417
116418
116419
116420
116421
116422
116423
116424
116425
116426
116427
116428
116429
116430
116431
116432
116433
116434
116435
116436
116437
116438
116439
116440
116441
116442
116443
116444
116445
116446
116447
116448
116449
116450
116451
116452
116453
116454
116455
116456
116457
116458
116459
116460
116461
116462
116463
116464
116465
116466
116467
116468
116469
116470
116471
116472
116473
116474
116475
116476
116477
116478
116479
116480
116481
116482
116483
116484
116485
116486
116487
116488
116489
116490
116491
116492
116493
116494
116495
116496
116497
116498
116499
116500
116501
116502
116503
116504
116505
116506
116507
116508
116509
116510
116511
116512
116513
116514
116515
116516
116517
116518
116519
116520
116521
116522
116523
116524
116525
116526
116527
116528
116529
116530
116531
116532
116533
116534
116535
116536
116537
116538
116539
116540
116541
116542
116543
116544
116545
116546
116547
116548
116549
116550
116551
116552
116553
116554
116555
116556
116557
116558
116559
116560
116561
116562
116563
116564
116565
116566
116567
116568
116569
116570
116571
116572
116573
116574
116575
116576
116577
116578
116579
116580
116581
116582
116583
116584
116585
116586
116587
116588
116589
116590
116591
116592
116593
116594
116595
116596
116597
116598
116599
116600
116601
116602
116603
116604
116605
116606
116607
116608
116609
116610
116611
116612
116613
116614
116615
116616
116617
116618
116619
116620
116621
116622
116623
116624
116625
116626
116627
116628
116629
116630
116631
116632
116633
116634
116635
116636
116637
116638
116639
116640
116641
116642
116643
116644
116645
116646
116647
116648
116649
116650
116651
116652
116653
116654
116655
116656
116657
116658
116659
116660
116661
116662
116663
116664
116665
116666
116667
116668
116669
116670
116671
116672
116673
116674
116675
116676
116677
116678
116679
116680
116681
116682
116683
116684
116685
116686
116687
116688
116689
116690
116691
116692
116693
116694
116695
116696
116697
116698
116699
116700
116701
116702
116703
116704
116705
116706
116707
116708
116709
116710
116711
116712
116713
116714
116715
116716
116717
116718
116719
116720
116721
116722
116723
116724
116725
116726
116727
116728
116729
116730
116731
116732
116733
116734
116735
116736
116737
116738
116739
116740
116741
116742
116743
116744
116745
116746
116747
116748
116749
116750
116751
116752
116753
116754
116755
116756
116757
116758
116759
116760
116761
116762
116763
116764
116765
116766
116767
116768
116769
116770
116771
116772
116773
116774
116775
116776
116777
116778
116779
116780
116781
116782
116783
116784
116785
116786
116787
116788
116789
116790
116791
116792
116793
116794
116795
116796
116797
116798
116799
116800
116801
116802
116803
116804
116805
116806
116807
116808
116809
116810
116811
116812
116813
116814
116815
116816
116817
116818
116819
116820
116821
116822
116823
116824
116825
116826
116827
116828
116829
116830
116831
116832
116833
116834
116835
116836
116837
116838
116839
116840
116841
116842
116843
116844
116845
116846
116847
116848
116849
116850
116851
116852
116853
116854
116855
116856
116857
116858
116859
116860
116861
116862
116863
116864
116865
116866
116867
116868
116869
116870
116871
116872
116873
116874
116875
116876
116877
116878
116879
116880
116881
116882
116883
116884
116885
116886
116887
116888
116889
116890
116891
116892
116893
116894
116895
116896
116897
116898
116899
116900
116901
116902
116903
116904
116905
116906
116907
116908
116909
116910
116911
116912
116913
116914
116915
116916
116917
116918
116919
116920
116921
116922
116923
116924
116925
116926
116927
116928
116929
116930
116931
116932
116933
116934
116935
116936
116937
116938
116939
116940
116941
116942
116943
116944
116945
116946
116947
116948
116949
116950
116951
116952
116953
116954
116955
116956
116957
116958
116959
116960
116961
116962
116963
116964
116965
116966
116967
116968
116969
116970
116971
116972
116973
116974
116975
116976
116977
116978
116979
116980
116981
116982
116983
116984
116985
116986
116987
116988
116989
116990
116991
116992
116993
116994
116995
116996
116997
116998
116999
117000
117001
117002
117003
117004
117005
117006
117007
117008
117009
117010
117011
117012
117013
117014
117015
117016
117017
117018
117019
117020
117021
117022
117023
117024
117025
117026
117027
117028
117029
117030
117031
117032
117033
117034
117035
117036
117037
117038
117039
117040
117041
117042
117043
117044
117045
117046
117047
117048
117049
117050
117051
117052
117053
117054
117055
117056
117057
117058
117059
117060
117061
117062
117063
117064
117065
117066
117067
117068
117069
117070
117071
117072
117073
117074
117075
117076
117077
117078
117079
117080
117081
117082
117083
117084
117085
117086
117087
117088
117089
117090
117091
117092
117093
117094
117095
117096
117097
117098
117099
117100
117101
117102
117103
117104
117105
117106
117107
117108
117109
117110
117111
117112
117113
117114
117115
117116
117117
117118
117119
117120
117121
117122
117123
117124
117125
117126
117127
117128
117129
117130
117131
117132
117133
117134
117135
117136
117137
117138
117139
117140
117141
117142
117143
117144
117145
117146
117147
117148
117149
117150
117151
117152
117153
117154
117155
117156
117157
117158
117159
117160
117161
117162
117163
117164
117165
117166
117167
117168
117169
117170
117171
117172
117173
117174
117175
117176
117177
117178
117179
117180
117181
117182
117183
117184
117185
117186
117187
117188
117189
117190
117191
117192
117193
117194
117195
117196
117197
117198
117199
117200
117201
117202
117203
117204
117205
117206
117207
117208
117209
117210
117211
117212
117213
117214
117215
117216
117217
117218
117219
117220
117221
117222
117223
117224
117225
117226
117227
117228
117229
117230
117231
117232
117233
117234
117235
117236
117237
117238
117239
117240
117241
117242
117243
117244
117245
117246
117247
117248
117249
117250
117251
117252
117253
117254
117255
117256
117257
117258
117259
117260
117261
117262
117263
117264
117265
117266
117267
117268
117269
117270
117271
117272
117273
117274
117275
117276
117277
117278
117279
117280
117281
117282
117283
117284
117285
117286
117287
117288
117289
117290
117291
117292
117293
117294
117295
117296
117297
117298
117299
117300
117301
117302
117303
117304
117305
117306
117307
117308
117309
117310
117311
117312
117313
117314
117315
117316
117317
117318
117319
117320
117321
117322
117323
117324
117325
117326
117327
117328
117329
117330
117331
117332
117333
117334
117335
117336
117337
117338
117339
117340
117341
117342
117343
117344
117345
117346
117347
117348
117349
117350
117351
117352
117353
117354
117355
117356
117357
117358
117359
117360
117361
117362
117363
117364
117365
117366
117367
117368
117369
117370
117371
117372
117373
117374
117375
117376
117377
117378
117379
117380
117381
117382
117383
117384
117385
117386
117387
117388
117389
117390
117391
117392
117393
117394
117395
117396
117397
117398
117399
117400
117401
117402
117403
117404
117405
117406
117407
117408
117409
117410
117411
117412
117413
117414
117415
117416
117417
117418
117419
117420
117421
117422
117423
117424
117425
117426
117427
117428
117429
117430
117431
117432
117433
117434
117435
117436
117437
117438
117439
117440
117441
117442
117443
117444
117445
117446
117447
117448
117449
117450
117451
117452
117453
117454
117455
117456
117457
117458
117459
117460
117461
117462
117463
117464
117465
117466
117467
117468
117469
117470
117471
117472
117473
117474
117475
117476
117477
117478
117479
117480
117481
117482
117483
117484
117485
117486
117487
117488
117489
117490
117491
117492
117493
117494
117495
117496
117497
117498
117499
117500
117501
117502
117503
117504
117505
117506
117507
117508
117509
117510
117511
117512
117513
117514
117515
117516
117517
117518
117519
117520
117521
117522
117523
117524
117525
117526
117527
117528
117529
117530
117531
117532
117533
117534
117535
117536
117537
117538
117539
117540
117541
117542
117543
117544
117545
117546
117547
117548
117549
117550
117551
117552
117553
117554
117555
117556
117557
117558
117559
117560
117561
117562
117563
117564
117565
117566
117567
117568
117569
117570
117571
117572
117573
117574
117575
117576
117577
117578
117579
117580
117581
117582
117583
117584
117585
117586
117587
117588
117589
117590
117591
117592
117593
117594
117595
117596
117597
117598
117599
117600
117601
117602
117603
117604
117605
117606
117607
117608
117609
117610
117611
117612
117613
117614
117615
117616
117617
117618
117619
117620
117621
117622
117623
117624
117625
117626
117627
117628
117629
117630
117631
117632
117633
117634
117635
117636
117637
117638
117639
117640
117641
117642
117643
117644
117645
117646
117647
117648
117649
117650
117651
117652
117653
117654
117655
117656
117657
117658
117659
117660
117661
117662
117663
117664
117665
117666
117667
117668
117669
117670
117671
117672
117673
117674
117675
117676
117677
117678
117679
117680
117681
117682
117683
117684
117685
117686
117687
117688
117689
117690
117691
117692
117693
117694
117695
117696
117697
117698
117699
117700
117701
117702
117703
117704
117705
117706
117707
117708
117709
117710
117711
117712
117713
117714
117715
117716
117717
117718
117719
117720
117721
117722
117723
117724
117725
117726
117727
117728
117729
117730
117731
117732
117733
117734
117735
117736
117737
117738
117739
117740
117741
117742
117743
117744
117745
117746
117747
117748
117749
117750
117751
117752
117753
117754
117755
117756
117757
117758
117759
117760
117761
117762
117763
117764
117765
117766
117767
117768
117769
117770
117771
117772
117773
117774
117775
117776
117777
117778
117779
117780
117781
117782
117783
117784
117785
117786
117787
117788
117789
117790
117791
117792
117793
117794
117795
117796
117797
117798
117799
117800
117801
117802
117803
117804
117805
117806
117807
117808
117809
117810
117811
117812
117813
117814
117815
117816
117817
117818
117819
117820
117821
117822
117823
117824
117825
117826
117827
117828
117829
117830
117831
117832
117833
117834
117835
117836
117837
117838
117839
117840
117841
117842
117843
117844
117845
117846
117847
117848
117849
117850
117851
117852
117853
117854
117855
117856
117857
117858
117859
117860
117861
117862
117863
117864
117865
117866
117867
117868
117869
117870
117871
117872
117873
117874
117875
117876
117877
117878
117879
117880
117881
117882
117883
117884
117885
117886
117887
117888
117889
117890
117891
117892
117893
117894
117895
117896
117897
117898
117899
117900
117901
117902
117903
117904
117905
117906
117907
117908
117909
117910
117911
117912
117913
117914
117915
117916
117917
117918
117919
117920
117921
117922
117923
117924
117925
117926
117927
117928
117929
117930
117931
117932
117933
117934
117935
117936
117937
117938
117939
117940
117941
117942
117943
117944
117945
117946
117947
117948
117949
117950
117951
117952
117953
117954
117955
117956
117957
117958
117959
117960
117961
117962
117963
117964
117965
117966
117967
117968
117969
117970
117971
117972
117973
117974
117975
117976
117977
117978
117979
117980
117981
117982
117983
117984
117985
117986
117987
117988
117989
117990
117991
117992
117993
117994
117995
117996
117997
117998
117999
118000
118001
118002
118003
118004
118005
118006
118007
118008
118009
118010
118011
118012
118013
118014
118015
118016
118017
118018
118019
118020
118021
118022
118023
118024
118025
118026
118027
118028
118029
118030
118031
118032
118033
118034
118035
118036
118037
118038
118039
118040
118041
118042
118043
118044
118045
118046
118047
118048
118049
118050
118051
118052
118053
118054
118055
118056
118057
118058
118059
118060
118061
118062
118063
118064
118065
118066
118067
118068
118069
118070
118071
118072
118073
118074
118075
118076
118077
118078
118079
118080
118081
118082
118083
118084
118085
118086
118087
118088
118089
118090
118091
118092
118093
118094
118095
118096
118097
118098
118099
118100
118101
118102
118103
118104
118105
118106
118107
118108
118109
118110
118111
118112
118113
118114
118115
118116
118117
118118
118119
118120
118121
118122
118123
118124
118125
118126
118127
118128
118129
118130
118131
118132
118133
118134
118135
118136
118137
118138
118139
118140
118141
118142
118143
118144
118145
118146
118147
118148
118149
118150
118151
118152
118153
118154
118155
118156
118157
118158
118159
118160
118161
118162
118163
118164
118165
118166
118167
118168
118169
118170
118171
118172
118173
118174
118175
118176
118177
118178
118179
118180
118181
118182
118183
118184
118185
118186
118187
118188
118189
118190
118191
118192
118193
118194
118195
118196
118197
118198
118199
118200
118201
118202
118203
118204
118205
118206
118207
118208
118209
118210
118211
118212
118213
118214
118215
118216
118217
118218
118219
118220
118221
118222
118223
118224
118225
118226
118227
118228
118229
118230
118231
118232
118233
118234
118235
118236
118237
118238
118239
118240
118241
118242
118243
118244
118245
118246
118247
118248
118249
118250
118251
118252
118253
118254
118255
118256
118257
118258
118259
118260
118261
118262
118263
118264
118265
118266
118267
118268
118269
118270
118271
118272
118273
118274
118275
118276
118277
118278
118279
118280
118281
118282
118283
118284
118285
118286
118287
118288
118289
118290
118291
118292
118293
118294
118295
118296
118297
118298
118299
118300
118301
118302
118303
118304
118305
118306
118307
118308
118309
118310
118311
118312
118313
118314
118315
118316
118317
118318
118319
118320
118321
118322
118323
118324
118325
118326
118327
118328
118329
118330
118331
118332
118333
118334
118335
118336
118337
118338
118339
118340
118341
118342
118343
118344
118345
118346
118347
118348
118349
118350
118351
118352
118353
118354
118355
118356
118357
118358
118359
118360
118361
118362
118363
118364
118365
118366
118367
118368
118369
118370
118371
118372
118373
118374
118375
118376
118377
118378
118379
118380
118381
118382
118383
118384
118385
118386
118387
118388
118389
118390
118391
118392
118393
118394
118395
118396
118397
118398
118399
118400
118401
118402
118403
118404
118405
118406
118407
118408
118409
118410
118411
118412
118413
118414
118415
118416
118417
118418
118419
118420
118421
118422
118423
118424
118425
118426
118427
118428
118429
118430
118431
118432
118433
118434
118435
118436
118437
118438
118439
118440
118441
118442
118443
118444
118445
118446
118447
118448
118449
118450
118451
118452
118453
118454
118455
118456
118457
118458
118459
118460
118461
118462
118463
118464
118465
118466
118467
118468
118469
118470
118471
118472
118473
118474
118475
118476
118477
118478
118479
118480
118481
118482
118483
118484
118485
118486
118487
118488
118489
118490
118491
118492
118493
118494
118495
118496
118497
118498
118499
118500
118501
118502
118503
118504
118505
118506
118507
118508
118509
118510
118511
118512
118513
118514
118515
118516
118517
118518
118519
118520
118521
118522
118523
118524
118525
118526
118527
118528
118529
118530
118531
118532
118533
118534
118535
118536
118537
118538
118539
118540
118541
118542
118543
118544
118545
118546
118547
118548
118549
118550
118551
118552
118553
118554
118555
118556
118557
118558
118559
118560
118561
118562
118563
118564
118565
118566
118567
118568
118569
118570
118571
118572
118573
118574
118575
118576
118577
118578
118579
118580
118581
118582
118583
118584
118585
118586
118587
118588
118589
118590
118591
118592
118593
118594
118595
118596
118597
118598
118599
118600
118601
118602
118603
118604
118605
118606
118607
118608
118609
118610
118611
118612
118613
118614
118615
118616
118617
118618
118619
118620
118621
118622
118623
118624
118625
118626
118627
118628
118629
118630
118631
118632
118633
118634
118635
118636
118637
118638
118639
118640
118641
118642
118643
118644
118645
118646
118647
118648
118649
118650
118651
118652
118653
118654
118655
118656
118657
118658
118659
118660
118661
118662
118663
118664
118665
118666
118667
118668
118669
118670
118671
118672
118673
118674
118675
118676
118677
118678
118679
118680
118681
118682
118683
118684
118685
118686
118687
118688
118689
118690
118691
118692
118693
118694
118695
118696
118697
118698
118699
118700
118701
118702
118703
118704
118705
118706
118707
118708
118709
118710
118711
118712
118713
118714
118715
118716
118717
118718
118719
118720
118721
118722
118723
118724
118725
118726
118727
118728
118729
118730
118731
118732
118733
118734
118735
118736
118737
118738
118739
118740
118741
118742
118743
118744
118745
118746
118747
118748
118749
118750
118751
118752
118753
118754
118755
118756
118757
118758
118759
118760
118761
118762
118763
118764
118765
118766
118767
118768
118769
118770
118771
118772
118773
118774
118775
118776
118777
118778
118779
118780
118781
118782
118783
118784
118785
118786
118787
118788
118789
118790
118791
118792
118793
118794
118795
118796
118797
118798
118799
118800
118801
118802
118803
118804
118805
118806
118807
118808
118809
118810
118811
118812
118813
118814
118815
118816
118817
118818
118819
118820
118821
118822
118823
118824
118825
118826
118827
118828
118829
118830
118831
118832
118833
118834
118835
118836
118837
118838
118839
118840
118841
118842
118843
118844
118845
118846
118847
118848
118849
118850
118851
118852
118853
118854
118855
118856
118857
118858
118859
118860
118861
118862
118863
118864
118865
118866
118867
118868
118869
118870
118871
118872
118873
118874
118875
118876
118877
118878
118879
118880
118881
118882
118883
118884
118885
118886
118887
118888
118889
118890
118891
118892
118893
118894
118895
118896
118897
118898
118899
118900
118901
118902
118903
118904
118905
118906
118907
118908
118909
118910
118911
118912
118913
118914
118915
118916
118917
118918
118919
118920
118921
118922
118923
118924
118925
118926
118927
118928
118929
118930
118931
118932
118933
118934
118935
118936
118937
118938
118939
118940
118941
118942
118943
118944
118945
118946
118947
118948
118949
118950
118951
118952
118953
118954
118955
118956
118957
118958
118959
118960
118961
118962
118963
118964
118965
118966
118967
118968
118969
118970
118971
118972
118973
118974
118975
118976
118977
118978
118979
118980
118981
118982
118983
118984
118985
118986
118987
118988
118989
118990
118991
118992
118993
118994
118995
118996
118997
118998
118999
119000
119001
119002
119003
119004
119005
119006
119007
119008
119009
119010
119011
119012
119013
119014
119015
119016
119017
119018
119019
119020
119021
119022
119023
119024
119025
119026
119027
119028
119029
119030
119031
119032
119033
119034
119035
119036
119037
119038
119039
119040
119041
119042
119043
119044
119045
119046
119047
119048
119049
119050
119051
119052
119053
119054
119055
119056
119057
119058
119059
119060
119061
119062
119063
119064
119065
119066
119067
119068
119069
119070
119071
119072
119073
119074
119075
119076
119077
119078
119079
119080
119081
119082
119083
119084
119085
119086
119087
119088
119089
119090
119091
119092
119093
119094
119095
119096
119097
119098
119099
119100
119101
119102
119103
119104
119105
119106
119107
119108
119109
119110
119111
119112
119113
119114
119115
119116
119117
119118
119119
119120
119121
119122
119123
119124
119125
119126
119127
119128
119129
119130
119131
119132
119133
119134
119135
119136
119137
119138
119139
119140
119141
119142
119143
119144
119145
119146
119147
119148
119149
119150
119151
119152
119153
119154
119155
119156
119157
119158
119159
119160
119161
119162
119163
119164
119165
119166
119167
119168
119169
119170
119171
119172
119173
119174
119175
119176
119177
119178
119179
119180
119181
119182
119183
119184
119185
119186
119187
119188
119189
119190
119191
119192
119193
119194
119195
119196
119197
119198
119199
119200
119201
119202
119203
119204
119205
119206
119207
119208
119209
119210
119211
119212
119213
119214
119215
119216
119217
119218
119219
119220
119221
119222
119223
119224
119225
119226
119227
119228
119229
119230
119231
119232
119233
119234
119235
119236
119237
119238
119239
119240
119241
119242
119243
119244
119245
119246
119247
119248
119249
119250
119251
119252
119253
119254
119255
119256
119257
119258
119259
119260
119261
119262
119263
119264
119265
119266
119267
119268
119269
119270
119271
119272
119273
119274
119275
119276
119277
119278
119279
119280
119281
119282
119283
119284
119285
119286
119287
119288
119289
119290
119291
119292
119293
119294
119295
119296
119297
119298
119299
119300
119301
119302
119303
119304
119305
119306
119307
119308
119309
119310
119311
119312
119313
119314
119315
119316
119317
119318
119319
119320
119321
119322
119323
119324
119325
119326
119327
119328
119329
119330
119331
119332
119333
119334
119335
119336
119337
119338
119339
119340
119341
119342
119343
119344
119345
119346
119347
119348
119349
119350
119351
119352
119353
119354
119355
119356
119357
119358
119359
119360
119361
119362
119363
119364
119365
119366
119367
119368
119369
119370
119371
119372
119373
119374
119375
119376
119377
119378
119379
119380
119381
119382
119383
119384
119385
119386
119387
119388
119389
119390
119391
119392
119393
119394
119395
119396
119397
119398
119399
119400
119401
119402
119403
119404
119405
119406
119407
119408
119409
119410
119411
119412
119413
119414
119415
119416
119417
119418
119419
119420
119421
119422
119423
119424
119425
119426
119427
119428
119429
119430
119431
119432
119433
119434
119435
119436
119437
119438
119439
119440
119441
119442
119443
119444
119445
119446
119447
119448
119449
119450
119451
119452
119453
119454
119455
119456
119457
119458
119459
119460
119461
119462
119463
119464
119465
119466
119467
119468
119469
119470
119471
119472
119473
119474
119475
119476
119477
119478
119479
119480
119481
119482
119483
119484
119485
119486
119487
119488
119489
119490
119491
119492
119493
119494
119495
119496
119497
119498
119499
119500
119501
119502
119503
119504
119505
119506
119507
119508
119509
119510
119511
119512
119513
119514
119515
119516
119517
119518
119519
119520
119521
119522
119523
119524
119525
119526
119527
119528
119529
119530
119531
119532
119533
119534
119535
119536
119537
119538
119539
119540
119541
119542
119543
119544
119545
119546
119547
119548
119549
119550
119551
119552
119553
119554
119555
119556
119557
119558
119559
119560
119561
119562
119563
119564
119565
119566
119567
119568
119569
119570
119571
119572
119573
119574
119575
119576
119577
119578
119579
119580
119581
119582
119583
119584
119585
119586
119587
119588
119589
119590
119591
119592
119593
119594
119595
119596
119597
119598
119599
119600
119601
119602
119603
119604
119605
119606
119607
119608
119609
119610
119611
119612
119613
119614
119615
119616
119617
119618
119619
119620
119621
119622
119623
119624
119625
119626
119627
119628
119629
119630
119631
119632
119633
119634
119635
119636
119637
119638
119639
119640
119641
119642
119643
119644
119645
119646
119647
119648
119649
119650
119651
119652
119653
119654
119655
119656
119657
119658
119659
119660
119661
119662
119663
119664
119665
119666
119667
119668
119669
119670
119671
119672
119673
119674
119675
119676
119677
119678
119679
119680
119681
119682
119683
119684
119685
119686
119687
119688
119689
119690
119691
119692
119693
119694
119695
119696
119697
119698
119699
119700
119701
119702
119703
119704
119705
119706
119707
119708
119709
119710
119711
119712
119713
119714
119715
119716
119717
119718
119719
119720
119721
119722
119723
119724
119725
119726
119727
119728
119729
119730
119731
119732
119733
119734
119735
119736
119737
119738
119739
119740
119741
119742
119743
119744
119745
119746
119747
119748
119749
119750
119751
119752
119753
119754
119755
119756
119757
119758
119759
119760
119761
119762
119763
119764
119765
119766
119767
119768
119769
119770
119771
119772
119773
119774
119775
119776
119777
119778
119779
119780
119781
119782
119783
119784
119785
119786
119787
119788
119789
119790
119791
119792
119793
119794
119795
119796
119797
119798
119799
119800
119801
119802
119803
119804
119805
119806
119807
119808
119809
119810
119811
119812
119813
119814
119815
119816
119817
119818
119819
119820
119821
119822
119823
119824
119825
119826
119827
119828
119829
119830
119831
119832
119833
119834
119835
119836
119837
119838
119839
119840
119841
119842
119843
119844
119845
119846
119847
119848
119849
119850
119851
119852
119853
119854
119855
119856
119857
119858
119859
119860
119861
119862
119863
119864
119865
119866
119867
119868
119869
119870
119871
119872
119873
119874
119875
119876
119877
119878
119879
119880
119881
119882
119883
119884
119885
119886
119887
119888
119889
119890
119891
119892
119893
119894
119895
119896
119897
119898
119899
119900
119901
119902
119903
119904
119905
119906
119907
119908
119909
119910
119911
119912
119913
119914
119915
119916
119917
119918
119919
119920
119921
119922
119923
119924
119925
119926
119927
119928
119929
119930
119931
119932
119933
119934
119935
119936
119937
119938
119939
119940
119941
119942
119943
119944
119945
119946
119947
119948
119949
119950
119951
119952
119953
119954
119955
119956
119957
119958
119959
119960
119961
119962
119963
119964
119965
119966
119967
119968
119969
119970
119971
119972
119973
119974
119975
119976
119977
119978
119979
119980
119981
119982
119983
119984
119985
119986
119987
119988
119989
119990
119991
119992
119993
119994
119995
119996
119997
119998
119999
120000
120001
120002
120003
120004
120005
120006
120007
120008
120009
120010
120011
120012
120013
120014
120015
120016
120017
120018
120019
120020
120021
120022
120023
120024
120025
120026
120027
120028
120029
120030
120031
120032
120033
120034
120035
120036
120037
120038
120039
120040
120041
120042
120043
120044
120045
120046
120047
120048
120049
120050
120051
120052
120053
120054
120055
120056
120057
120058
120059
120060
120061
120062
120063
120064
120065
120066
120067
120068
120069
120070
120071
120072
120073
120074
120075
120076
120077
120078
120079
120080
120081
120082
120083
120084
120085
120086
120087
120088
120089
120090
120091
120092
120093
120094
120095
120096
120097
120098
120099
120100
120101
120102
120103
120104
120105
120106
120107
120108
120109
120110
120111
120112
120113
120114
120115
120116
120117
120118
120119
120120
120121
120122
120123
120124
120125
120126
120127
120128
120129
120130
120131
120132
120133
120134
120135
120136
120137
120138
120139
120140
120141
120142
120143
120144
120145
120146
120147
120148
120149
120150
120151
120152
120153
120154
120155
120156
120157
120158
120159
120160
120161
120162
120163
120164
120165
120166
120167
120168
120169
120170
120171
120172
120173
120174
120175
120176
120177
120178
120179
120180
120181
120182
120183
120184
120185
120186
120187
120188
120189
120190
120191
120192
120193
120194
120195
120196
120197
120198
120199
120200
120201
120202
120203
120204
120205
120206
120207
120208
120209
120210
120211
120212
120213
120214
120215
120216
120217
120218
120219
120220
120221
120222
120223
120224
120225
120226
120227
120228
120229
120230
120231
120232
120233
120234
120235
120236
120237
120238
120239
120240
120241
120242
120243
120244
120245
120246
120247
120248
120249
120250
120251
120252
120253
120254
120255
120256
120257
120258
120259
120260
120261
120262
120263
120264
120265
120266
120267
120268
120269
120270
120271
120272
120273
120274
120275
120276
120277
120278
120279
120280
120281
120282
120283
120284
120285
120286
120287
120288
120289
120290
120291
120292
120293
120294
120295
120296
120297
120298
120299
120300
120301
120302
120303
120304
120305
120306
120307
120308
120309
120310
120311
120312
120313
120314
120315
120316
120317
120318
120319
120320
120321
120322
120323
120324
120325
120326
120327
120328
120329
120330
120331
120332
120333
120334
120335
120336
120337
120338
120339
120340
120341
120342
120343
120344
120345
120346
120347
120348
120349
120350
120351
120352
120353
120354
120355
120356
120357
120358
120359
120360
120361
120362
120363
120364
120365
120366
120367
120368
120369
120370
120371
120372
120373
120374
120375
120376
120377
120378
120379
120380
120381
120382
120383
120384
120385
120386
120387
120388
120389
120390
120391
120392
120393
120394
120395
120396
120397
120398
120399
120400
120401
120402
120403
120404
120405
120406
120407
120408
120409
120410
120411
120412
120413
120414
120415
120416
120417
120418
120419
120420
120421
120422
120423
120424
120425
120426
120427
120428
120429
120430
120431
120432
120433
120434
120435
120436
120437
120438
120439
120440
120441
120442
120443
120444
120445
120446
120447
120448
120449
120450
120451
120452
120453
120454
120455
120456
120457
120458
120459
120460
120461
120462
120463
120464
120465
120466
120467
120468
120469
120470
120471
120472
120473
120474
120475
120476
120477
120478
120479
120480
120481
120482
120483
120484
120485
120486
120487
120488
120489
120490
120491
120492
120493
120494
120495
120496
120497
120498
120499
120500
120501
120502
120503
120504
120505
120506
120507
120508
120509
120510
120511
120512
120513
120514
120515
120516
120517
120518
120519
120520
120521
120522
120523
120524
120525
120526
120527
120528
120529
120530
120531
120532
120533
120534
120535
120536
120537
120538
120539
120540
120541
120542
120543
120544
120545
120546
120547
120548
120549
120550
120551
120552
120553
120554
120555
120556
120557
120558
120559
120560
120561
120562
120563
120564
120565
120566
120567
120568
120569
120570
120571
120572
120573
120574
120575
120576
120577
120578
120579
120580
120581
120582
120583
120584
120585
120586
120587
120588
120589
120590
120591
120592
120593
120594
120595
120596
120597
120598
120599
120600
120601
120602
120603
120604
120605
120606
120607
120608
120609
120610
120611
120612
120613
120614
120615
120616
120617
120618
120619
120620
120621
120622
120623
120624
120625
120626
120627
120628
120629
120630
120631
120632
120633
120634
120635
120636
120637
120638
120639
120640
120641
120642
120643
120644
120645
120646
120647
120648
120649
120650
120651
120652
120653
120654
120655
120656
120657
120658
120659
120660
120661
120662
120663
120664
120665
120666
120667
120668
120669
120670
120671
120672
120673
120674
120675
120676
120677
120678
120679
120680
120681
120682
120683
120684
120685
120686
120687
120688
120689
120690
120691
120692
120693
120694
120695
120696
120697
120698
120699
120700
120701
120702
120703
120704
120705
120706
120707
120708
120709
120710
120711
120712
120713
120714
120715
120716
120717
120718
120719
120720
120721
120722
120723
120724
120725
120726
120727
120728
120729
120730
120731
120732
120733
120734
120735
120736
120737
120738
120739
120740
120741
120742
120743
120744
120745
120746
120747
120748
120749
120750
120751
120752
120753
120754
120755
120756
120757
120758
120759
120760
120761
120762
120763
120764
120765
120766
120767
120768
120769
120770
120771
120772
120773
120774
120775
120776
120777
120778
120779
120780
120781
120782
120783
120784
120785
120786
120787
120788
120789
120790
120791
120792
120793
120794
120795
120796
120797
120798
120799
120800
120801
120802
120803
120804
120805
120806
120807
120808
120809
120810
120811
120812
120813
120814
120815
120816
120817
120818
120819
120820
120821
120822
120823
120824
120825
120826
120827
120828
120829
120830
120831
120832
120833
120834
120835
120836
120837
120838
120839
120840
120841
120842
120843
120844
120845
120846
120847
120848
120849
120850
120851
120852
120853
120854
120855
120856
120857
120858
120859
120860
120861
120862
120863
120864
120865
120866
120867
120868
120869
120870
120871
120872
120873
120874
120875
120876
120877
120878
120879
120880
120881
120882
120883
120884
120885
120886
120887
120888
120889
120890
120891
120892
120893
120894
120895
120896
120897
120898
120899
120900
120901
120902
120903
120904
120905
120906
120907
120908
120909
120910
120911
120912
120913
120914
120915
120916
120917
120918
120919
120920
120921
120922
120923
120924
120925
120926
120927
120928
120929
120930
120931
120932
120933
120934
120935
120936
120937
120938
120939
120940
120941
120942
120943
120944
120945
120946
120947
120948
120949
120950
120951
120952
120953
120954
120955
120956
120957
120958
120959
120960
120961
120962
120963
120964
120965
120966
120967
120968
120969
120970
120971
120972
120973
120974
120975
120976
120977
120978
120979
120980
120981
120982
120983
120984
120985
120986
120987
120988
120989
120990
120991
120992
120993
120994
120995
120996
120997
120998
120999
121000
121001
121002
121003
121004
121005
121006
121007
121008
121009
121010
121011
121012
121013
121014
121015
121016
121017
121018
121019
121020
121021
121022
121023
121024
121025
121026
121027
121028
121029
121030
121031
121032
121033
121034
121035
121036
121037
121038
121039
121040
121041
121042
121043
121044
121045
121046
121047
121048
121049
121050
121051
121052
121053
121054
121055
121056
121057
121058
121059
121060
121061
121062
121063
121064
121065
121066
121067
121068
121069
121070
121071
121072
121073
121074
121075
121076
121077
121078
121079
121080
121081
121082
121083
121084
121085
121086
121087
121088
121089
121090
121091
121092
121093
121094
121095
121096
121097
121098
121099
121100
121101
121102
121103
121104
121105
121106
121107
121108
121109
121110
121111
121112
121113
121114
121115
121116
121117
121118
121119
121120
121121
121122
121123
121124
121125
121126
121127
121128
121129
121130
121131
121132
121133
121134
121135
121136
121137
121138
121139
121140
121141
121142
121143
121144
121145
121146
121147
121148
121149
121150
121151
121152
121153
121154
121155
121156
121157
121158
121159
121160
121161
121162
121163
121164
121165
121166
121167
121168
121169
121170
121171
121172
121173
121174
121175
121176
121177
121178
121179
121180
121181
121182
121183
121184
121185
121186
121187
121188
121189
121190
121191
121192
121193
121194
121195
121196
121197
121198
121199
121200
121201
121202
121203
121204
121205
121206
121207
121208
121209
121210
121211
121212
121213
121214
121215
121216
121217
121218
121219
121220
121221
121222
121223
121224
121225
121226
121227
121228
121229
121230
121231
121232
121233
121234
121235
121236
121237
121238
121239
121240
121241
121242
121243
121244
121245
121246
121247
121248
121249
121250
121251
121252
121253
121254
121255
121256
121257
121258
121259
121260
121261
121262
121263
121264
121265
121266
121267
121268
121269
121270
121271
121272
121273
121274
121275
121276
121277
121278
121279
121280
121281
121282
121283
121284
121285
121286
121287
121288
121289
121290
121291
121292
121293
121294
121295
121296
121297
121298
121299
121300
121301
121302
121303
121304
121305
121306
121307
121308
121309
121310
121311
121312
121313
121314
121315
121316
121317
121318
121319
121320
121321
121322
121323
121324
121325
121326
121327
121328
121329
121330
121331
121332
121333
121334
121335
121336
121337
121338
121339
121340
121341
121342
121343
121344
121345
121346
121347
121348
121349
121350
121351
121352
121353
121354
121355
121356
121357
121358
121359
121360
121361
121362
121363
121364
121365
121366
121367
121368
121369
121370
121371
121372
121373
121374
121375
121376
121377
121378
121379
121380
121381
121382
121383
121384
121385
121386
121387
121388
121389
121390
121391
121392
121393
121394
121395
121396
121397
121398
121399
121400
121401
121402
121403
121404
121405
121406
121407
121408
121409
121410
121411
121412
121413
121414
121415
121416
121417
121418
121419
121420
121421
121422
121423
121424
121425
121426
121427
121428
121429
121430
121431
121432
121433
121434
121435
121436
121437
121438
121439
121440
121441
121442
121443
121444
121445
121446
121447
121448
121449
121450
121451
121452
121453
121454
121455
121456
121457
121458
121459
121460
121461
121462
121463
121464
121465
121466
121467
121468
121469
121470
121471
121472
121473
121474
121475
121476
121477
121478
121479
121480
121481
121482
121483
121484
121485
121486
121487
121488
121489
121490
121491
121492
121493
121494
121495
121496
121497
121498
121499
121500
121501
121502
121503
121504
121505
121506
121507
121508
121509
121510
121511
121512
121513
121514
121515
121516
121517
121518
121519
121520
121521
121522
121523
121524
121525
121526
121527
121528
121529
121530
121531
121532
121533
121534
121535
121536
121537
121538
121539
121540
121541
121542
121543
121544
121545
121546
121547
121548
121549
121550
121551
121552
121553
121554
121555
121556
121557
121558
121559
121560
121561
121562
121563
121564
121565
121566
121567
121568
121569
121570
121571
121572
121573
121574
121575
121576
121577
121578
121579
121580
121581
121582
121583
121584
121585
121586
121587
121588
121589
121590
121591
121592
121593
121594
121595
121596
121597
121598
121599
121600
121601
121602
121603
121604
121605
121606
121607
121608
121609
121610
121611
121612
121613
121614
121615
121616
121617
121618
121619
121620
121621
121622
121623
121624
121625
121626
121627
121628
121629
121630
121631
121632
121633
121634
121635
121636
121637
121638
121639
121640
121641
121642
121643
121644
121645
121646
121647
121648
121649
121650
121651
121652
121653
121654
121655
121656
121657
121658
121659
121660
121661
121662
121663
121664
121665
121666
121667
121668
121669
121670
121671
121672
121673
121674
121675
121676
121677
121678
121679
121680
121681
121682
121683
121684
121685
121686
121687
121688
121689
121690
121691
121692
121693
121694
121695
121696
121697
121698
121699
121700
121701
121702
121703
121704
121705
121706
121707
121708
121709
121710
121711
121712
121713
121714
121715
121716
121717
121718
121719
121720
121721
121722
121723
121724
121725
121726
121727
121728
121729
121730
121731
121732
121733
121734
121735
121736
121737
121738
121739
121740
121741
121742
121743
121744
121745
121746
121747
121748
121749
121750
121751
121752
121753
121754
121755
121756
121757
121758
121759
121760
121761
121762
121763
121764
121765
121766
121767
121768
121769
121770
121771
121772
121773
121774
121775
121776
121777
121778
121779
121780
121781
121782
121783
121784
121785
121786
121787
121788
121789
121790
121791
121792
121793
121794
121795
121796
121797
121798
121799
121800
121801
121802
121803
121804
121805
121806
121807
121808
121809
121810
121811
121812
121813
121814
121815
121816
121817
121818
121819
121820
121821
121822
121823
121824
121825
121826
121827
121828
121829
121830
121831
121832
121833
121834
121835
121836
121837
121838
121839
121840
121841
121842
121843
121844
121845
121846
121847
121848
121849
121850
121851
121852
121853
121854
121855
121856
121857
121858
121859
121860
121861
121862
121863
121864
121865
121866
121867
121868
121869
121870
121871
121872
121873
121874
121875
121876
121877
121878
121879
121880
121881
121882
121883
121884
121885
121886
121887
121888
121889
121890
121891
121892
121893
121894
121895
121896
121897
121898
121899
121900
121901
121902
121903
121904
121905
121906
121907
121908
121909
121910
121911
121912
121913
121914
121915
121916
121917
121918
121919
121920
121921
121922
121923
121924
121925
121926
121927
121928
121929
121930
121931
121932
121933
121934
121935
121936
121937
121938
121939
121940
121941
121942
121943
121944
121945
121946
121947
121948
121949
121950
121951
121952
121953
121954
121955
121956
121957
121958
121959
121960
121961
121962
121963
121964
121965
121966
121967
121968
121969
121970
121971
121972
121973
121974
121975
121976
121977
121978
121979
121980
121981
121982
121983
121984
121985
121986
121987
121988
121989
121990
121991
121992
121993
121994
121995
121996
121997
121998
121999
122000
122001
122002
122003
122004
122005
122006
122007
122008
122009
122010
122011
122012
122013
122014
122015
122016
122017
122018
122019
122020
122021
122022
122023
122024
122025
122026
122027
122028
122029
122030
122031
122032
122033
122034
122035
122036
122037
122038
122039
122040
122041
122042
122043
122044
122045
122046
122047
122048
122049
122050
122051
122052
122053
122054
122055
122056
122057
122058
122059
122060
122061
122062
122063
122064
122065
122066
122067
122068
122069
122070
122071
122072
122073
122074
122075
122076
122077
122078
122079
122080
122081
122082
122083
122084
122085
122086
122087
122088
122089
122090
122091
122092
122093
122094
122095
122096
122097
122098
122099
122100
122101
122102
122103
122104
122105
122106
122107
122108
122109
122110
122111
122112
122113
122114
122115
122116
122117
122118
122119
122120
122121
122122
122123
122124
122125
122126
122127
122128
122129
122130
122131
122132
122133
122134
122135
122136
122137
122138
122139
122140
122141
122142
122143
122144
122145
122146
122147
122148
122149
122150
122151
122152
122153
122154
122155
122156
122157
122158
122159
122160
122161
122162
122163
122164
122165
122166
122167
122168
122169
122170
122171
122172
122173
122174
122175
122176
122177
122178
122179
122180
122181
122182
122183
122184
122185
122186
122187
122188
122189
122190
122191
122192
122193
122194
122195
122196
122197
122198
122199
122200
122201
122202
122203
122204
122205
122206
122207
122208
122209
122210
122211
122212
122213
122214
122215
122216
122217
122218
122219
122220
122221
122222
122223
122224
122225
122226
122227
122228
122229
122230
122231
122232
122233
122234
122235
122236
122237
122238
122239
122240
122241
122242
122243
122244
122245
122246
122247
122248
122249
122250
122251
122252
122253
122254
122255
122256
122257
122258
122259
122260
122261
122262
122263
122264
122265
122266
122267
122268
122269
122270
122271
122272
122273
122274
122275
122276
122277
122278
122279
122280
122281
122282
122283
122284
122285
122286
122287
122288
122289
122290
122291
122292
122293
122294
122295
122296
122297
122298
122299
122300
122301
122302
122303
122304
122305
122306
122307
122308
122309
122310
122311
122312
122313
122314
122315
122316
122317
122318
122319
122320
122321
122322
122323
122324
122325
122326
122327
122328
122329
122330
122331
122332
122333
122334
122335
122336
122337
122338
122339
122340
122341
122342
122343
122344
122345
122346
122347
122348
122349
122350
122351
122352
122353
122354
122355
122356
122357
122358
122359
122360
122361
122362
122363
122364
122365
122366
122367
122368
122369
122370
122371
122372
122373
122374
122375
122376
122377
122378
122379
122380
122381
122382
122383
122384
122385
122386
122387
122388
122389
122390
122391
122392
122393
122394
122395
122396
122397
122398
122399
122400
122401
122402
122403
122404
122405
122406
122407
122408
122409
122410
122411
122412
122413
122414
122415
122416
122417
122418
122419
122420
122421
122422
122423
122424
122425
122426
122427
122428
122429
122430
122431
122432
122433
122434
122435
122436
122437
122438
122439
122440
122441
122442
122443
122444
122445
122446
122447
122448
122449
122450
122451
122452
122453
122454
122455
122456
122457
122458
122459
122460
122461
122462
122463
122464
122465
122466
122467
122468
122469
122470
122471
122472
122473
122474
122475
122476
122477
122478
122479
122480
122481
122482
122483
122484
122485
122486
122487
122488
122489
122490
122491
122492
122493
122494
122495
122496
122497
122498
122499
122500
122501
122502
122503
122504
122505
122506
122507
122508
122509
122510
122511
122512
122513
122514
122515
122516
122517
122518
122519
122520
122521
122522
122523
122524
122525
122526
122527
122528
122529
122530
122531
122532
122533
122534
122535
122536
122537
122538
122539
122540
122541
122542
122543
122544
122545
122546
122547
122548
122549
122550
122551
122552
122553
122554
122555
122556
122557
122558
122559
122560
122561
122562
122563
122564
122565
122566
122567
122568
122569
122570
122571
122572
122573
122574
122575
122576
122577
122578
122579
122580
122581
122582
122583
122584
122585
122586
122587
122588
122589
122590
122591
122592
122593
122594
122595
122596
122597
122598
122599
122600
122601
122602
122603
122604
122605
122606
122607
122608
122609
122610
122611
122612
122613
122614
122615
122616
122617
122618
122619
122620
122621
122622
122623
122624
122625
122626
122627
122628
122629
122630
122631
122632
122633
122634
122635
122636
122637
122638
122639
122640
122641
122642
122643
122644
122645
122646
122647
122648
122649
122650
122651
122652
122653
122654
122655
122656
122657
122658
122659
122660
122661
122662
122663
122664
122665
122666
122667
122668
122669
122670
122671
122672
122673
122674
122675
122676
122677
122678
122679
122680
122681
122682
122683
122684
122685
122686
122687
122688
122689
122690
122691
122692
122693
122694
122695
122696
122697
122698
122699
122700
122701
122702
122703
122704
122705
122706
122707
122708
122709
122710
122711
122712
122713
122714
122715
122716
122717
122718
122719
122720
122721
122722
122723
122724
122725
122726
122727
122728
122729
122730
122731
122732
122733
122734
122735
122736
122737
122738
122739
122740
122741
122742
122743
122744
122745
122746
122747
122748
122749
122750
122751
122752
122753
122754
122755
122756
122757
122758
122759
122760
122761
122762
122763
122764
122765
122766
122767
122768
122769
122770
122771
122772
122773
122774
122775
122776
122777
122778
122779
122780
122781
122782
122783
122784
122785
122786
122787
122788
122789
122790
122791
122792
122793
122794
122795
122796
122797
122798
122799
122800
122801
122802
122803
122804
122805
122806
122807
122808
122809
122810
122811
122812
122813
122814
122815
122816
122817
122818
122819
122820
122821
122822
122823
122824
122825
122826
122827
122828
122829
122830
122831
122832
122833
122834
122835
122836
122837
122838
122839
122840
122841
122842
122843
122844
122845
122846
122847
122848
122849
122850
122851
122852
122853
122854
122855
122856
122857
122858
122859
122860
122861
122862
122863
122864
122865
122866
122867
122868
122869
122870
122871
122872
122873
122874
122875
122876
122877
122878
122879
122880
122881
122882
122883
122884
122885
122886
122887
122888
122889
122890
122891
122892
122893
122894
122895
122896
122897
122898
122899
122900
122901
122902
122903
122904
122905
122906
122907
122908
122909
122910
122911
122912
122913
122914
122915
122916
122917
122918
122919
122920
122921
122922
122923
122924
122925
122926
122927
122928
122929
122930
122931
122932
122933
122934
122935
122936
122937
122938
122939
122940
122941
122942
122943
122944
122945
122946
122947
122948
122949
122950
122951
122952
122953
122954
122955
122956
122957
122958
122959
122960
122961
122962
122963
122964
122965
122966
122967
122968
122969
122970
122971
122972
122973
122974
122975
122976
122977
122978
122979
122980
122981
122982
122983
122984
122985
122986
122987
122988
122989
122990
122991
122992
122993
122994
122995
122996
122997
122998
122999
123000
123001
123002
123003
123004
123005
123006
123007
123008
123009
123010
123011
123012
123013
123014
123015
123016
123017
123018
123019
123020
123021
123022
123023
123024
123025
123026
123027
123028
123029
123030
123031
123032
123033
123034
123035
123036
123037
123038
123039
123040
123041
123042
123043
123044
123045
123046
123047
123048
123049
123050
123051
123052
123053
123054
123055
123056
123057
123058
123059
123060
123061
123062
123063
123064
123065
123066
123067
123068
123069
123070
123071
123072
123073
123074
123075
123076
123077
123078
123079
123080
123081
123082
123083
123084
123085
123086
123087
123088
123089
123090
123091
123092
123093
123094
123095
123096
123097
123098
123099
123100
123101
123102
123103
123104
123105
123106
123107
123108
123109
123110
123111
123112
123113
123114
123115
123116
123117
123118
123119
123120
123121
123122
123123
123124
123125
123126
123127
123128
123129
123130
123131
123132
123133
123134
123135
123136
123137
123138
123139
123140
123141
123142
123143
123144
123145
123146
123147
123148
123149
123150
123151
123152
123153
123154
123155
123156
123157
123158
123159
123160
123161
123162
123163
123164
123165
123166
123167
123168
123169
123170
123171
123172
123173
123174
123175
123176
123177
123178
123179
123180
123181
123182
123183
123184
123185
123186
123187
123188
123189
123190
123191
123192
123193
123194
123195
123196
123197
123198
123199
123200
123201
123202
123203
123204
123205
123206
123207
123208
123209
123210
123211
123212
123213
123214
123215
123216
123217
123218
123219
123220
123221
123222
123223
123224
123225
123226
123227
123228
123229
123230
123231
123232
123233
123234
123235
123236
123237
123238
123239
123240
123241
123242
123243
123244
123245
123246
123247
123248
123249
123250
123251
123252
123253
123254
123255
123256
123257
123258
123259
123260
123261
123262
123263
123264
123265
123266
123267
123268
123269
123270
123271
123272
123273
123274
123275
123276
123277
123278
123279
123280
123281
123282
123283
123284
123285
123286
123287
123288
123289
123290
123291
123292
123293
123294
123295
123296
123297
123298
123299
123300
123301
123302
123303
123304
123305
123306
123307
123308
123309
123310
123311
123312
123313
123314
123315
123316
123317
123318
123319
123320
123321
123322
123323
123324
123325
123326
123327
123328
123329
123330
123331
123332
123333
123334
123335
123336
123337
123338
123339
123340
123341
123342
123343
123344
123345
123346
123347
123348
123349
123350
123351
123352
123353
123354
123355
123356
123357
123358
123359
123360
123361
123362
123363
123364
123365
123366
123367
123368
123369
123370
123371
123372
123373
123374
123375
123376
123377
123378
123379
123380
123381
123382
123383
123384
123385
123386
123387
123388
123389
123390
123391
123392
123393
123394
123395
123396
123397
123398
123399
123400
123401
123402
123403
123404
123405
123406
123407
123408
123409
123410
123411
123412
123413
123414
123415
123416
123417
123418
123419
123420
123421
123422
123423
123424
123425
123426
123427
123428
123429
123430
123431
123432
123433
123434
123435
123436
123437
123438
123439
123440
123441
123442
123443
123444
123445
123446
123447
123448
123449
123450
123451
123452
123453
123454
123455
123456
123457
123458
123459
123460
123461
123462
123463
123464
123465
123466
123467
123468
123469
123470
123471
123472
123473
123474
123475
123476
123477
123478
123479
123480
123481
123482
123483
123484
123485
123486
123487
123488
123489
123490
123491
123492
123493
123494
123495
123496
123497
123498
123499
123500
123501
123502
123503
123504
123505
123506
123507
123508
123509
123510
123511
123512
123513
123514
123515
123516
123517
123518
123519
123520
123521
123522
123523
123524
123525
123526
123527
123528
123529
123530
123531
123532
123533
123534
123535
123536
123537
123538
123539
123540
123541
123542
123543
123544
123545
123546
123547
123548
123549
123550
123551
123552
123553
123554
123555
123556
123557
123558
123559
123560
123561
123562
123563
123564
123565
123566
123567
123568
123569
123570
123571
123572
123573
123574
123575
123576
123577
123578
123579
123580
123581
123582
123583
123584
123585
123586
123587
123588
123589
123590
123591
123592
123593
123594
123595
123596
123597
123598
123599
123600
123601
123602
123603
123604
123605
123606
123607
123608
123609
123610
123611
123612
123613
123614
123615
123616
123617
123618
123619
123620
123621
123622
123623
123624
123625
123626
123627
123628
123629
123630
123631
123632
123633
123634
123635
123636
123637
123638
123639
123640
123641
123642
123643
123644
123645
123646
123647
123648
123649
123650
123651
123652
123653
123654
123655
123656
123657
123658
123659
123660
123661
123662
123663
123664
123665
123666
123667
123668
123669
123670
123671
123672
123673
123674
123675
123676
123677
123678
123679
123680
123681
123682
123683
123684
123685
123686
123687
123688
123689
123690
123691
123692
123693
123694
123695
123696
123697
123698
123699
123700
123701
123702
123703
123704
123705
123706
123707
123708
123709
123710
123711
123712
123713
123714
123715
123716
123717
123718
123719
123720
123721
123722
123723
123724
123725
123726
123727
123728
123729
123730
123731
123732
123733
123734
123735
123736
123737
123738
123739
123740
123741
123742
123743
123744
123745
123746
123747
123748
123749
123750
123751
123752
123753
123754
123755
123756
123757
123758
123759
123760
123761
123762
123763
123764
123765
123766
123767
123768
123769
123770
123771
123772
123773
123774
123775
123776
123777
123778
123779
123780
123781
123782
123783
123784
123785
123786
123787
123788
123789
123790
123791
123792
123793
123794
123795
123796
123797
123798
123799
123800
123801
123802
123803
123804
123805
123806
123807
123808
123809
123810
123811
123812
123813
123814
123815
123816
123817
123818
123819
123820
123821
123822
123823
123824
123825
123826
123827
123828
123829
123830
123831
123832
123833
123834
123835
123836
123837
123838
123839
123840
123841
123842
123843
123844
123845
123846
123847
123848
123849
123850
123851
123852
123853
123854
123855
123856
123857
123858
123859
123860
123861
123862
123863
123864
123865
123866
123867
123868
123869
123870
123871
123872
123873
123874
123875
123876
123877
123878
123879
123880
123881
123882
123883
123884
123885
123886
123887
123888
123889
123890
123891
123892
123893
123894
123895
123896
123897
123898
123899
123900
123901
123902
123903
123904
123905
123906
123907
123908
123909
123910
123911
123912
123913
123914
123915
123916
123917
123918
123919
123920
123921
123922
123923
123924
123925
123926
123927
123928
123929
123930
123931
123932
123933
123934
123935
123936
123937
123938
123939
123940
123941
123942
123943
123944
123945
123946
123947
123948
123949
123950
123951
123952
123953
123954
123955
123956
123957
123958
123959
123960
123961
123962
123963
123964
123965
123966
123967
123968
123969
123970
123971
123972
123973
123974
123975
123976
123977
123978
123979
123980
123981
123982
123983
123984
123985
123986
123987
123988
123989
123990
123991
123992
123993
123994
123995
123996
123997
123998
123999
124000
124001
124002
124003
124004
124005
124006
124007
124008
124009
124010
124011
124012
124013
124014
124015
124016
124017
124018
124019
124020
124021
124022
124023
124024
124025
124026
124027
124028
124029
124030
124031
124032
124033
124034
124035
124036
124037
124038
124039
124040
124041
124042
124043
124044
124045
124046
124047
124048
124049
124050
124051
124052
124053
124054
124055
124056
124057
124058
124059
124060
124061
124062
124063
124064
124065
124066
124067
124068
124069
124070
124071
124072
124073
124074
124075
124076
124077
124078
124079
124080
124081
124082
124083
124084
124085
124086
124087
124088
124089
124090
124091
124092
124093
124094
124095
124096
124097
124098
124099
124100
124101
124102
124103
124104
124105
124106
124107
124108
124109
124110
124111
124112
124113
124114
124115
124116
124117
124118
124119
124120
124121
124122
124123
124124
124125
124126
124127
124128
124129
124130
124131
124132
124133
124134
124135
124136
124137
124138
124139
124140
124141
124142
124143
124144
124145
124146
124147
124148
124149
124150
124151
124152
124153
124154
124155
124156
124157
124158
124159
124160
124161
124162
124163
124164
124165
124166
124167
124168
124169
124170
124171
124172
124173
124174
124175
124176
124177
124178
124179
124180
124181
124182
124183
124184
124185
124186
124187
124188
124189
124190
124191
124192
124193
124194
124195
124196
124197
124198
124199
124200
124201
124202
124203
124204
124205
124206
124207
124208
124209
124210
124211
124212
124213
124214
124215
124216
124217
124218
124219
124220
124221
124222
124223
124224
124225
124226
124227
124228
124229
124230
124231
124232
124233
124234
124235
124236
124237
124238
124239
124240
124241
124242
124243
124244
124245
124246
124247
124248
124249
124250
124251
124252
124253
124254
124255
124256
124257
124258
124259
124260
124261
124262
124263
124264
124265
124266
124267
124268
124269
124270
124271
124272
124273
124274
124275
124276
124277
124278
124279
124280
124281
124282
124283
124284
124285
124286
124287
124288
124289
124290
124291
124292
124293
124294
124295
124296
124297
124298
124299
124300
124301
124302
124303
124304
124305
124306
124307
124308
124309
124310
124311
124312
124313
124314
124315
124316
124317
124318
124319
124320
124321
124322
124323
124324
124325
124326
124327
124328
124329
124330
124331
124332
124333
124334
124335
124336
124337
124338
124339
124340
124341
124342
124343
124344
124345
124346
124347
124348
124349
124350
124351
124352
124353
124354
124355
124356
124357
124358
124359
124360
124361
124362
124363
124364
124365
124366
124367
124368
124369
124370
124371
124372
124373
124374
124375
124376
124377
124378
124379
124380
124381
124382
124383
124384
124385
124386
124387
124388
124389
124390
124391
124392
124393
124394
124395
124396
124397
124398
124399
124400
124401
124402
124403
124404
124405
124406
124407
124408
124409
124410
124411
124412
124413
124414
124415
124416
124417
124418
124419
124420
124421
124422
124423
124424
124425
124426
124427
124428
124429
124430
124431
124432
124433
124434
124435
124436
124437
124438
124439
124440
124441
124442
124443
124444
124445
124446
124447
124448
124449
124450
124451
124452
124453
124454
124455
124456
124457
124458
124459
124460
124461
124462
124463
124464
124465
124466
124467
124468
124469
124470
124471
124472
124473
124474
124475
124476
124477
124478
124479
124480
124481
124482
124483
124484
124485
124486
124487
124488
124489
124490
124491
124492
124493
124494
124495
124496
124497
124498
124499
124500
124501
124502
124503
124504
124505
124506
124507
124508
124509
124510
124511
124512
124513
124514
124515
124516
124517
124518
124519
124520
124521
124522
124523
124524
124525
124526
124527
124528
124529
124530
124531
124532
124533
124534
124535
124536
124537
124538
124539
124540
124541
124542
124543
124544
124545
124546
124547
124548
124549
124550
124551
124552
124553
124554
124555
124556
124557
124558
124559
124560
124561
124562
124563
124564
124565
124566
124567
124568
124569
124570
124571
124572
124573
124574
124575
124576
124577
124578
124579
124580
124581
124582
124583
124584
124585
124586
124587
124588
124589
124590
124591
124592
124593
124594
124595
124596
124597
124598
124599
124600
124601
124602
124603
124604
124605
124606
124607
124608
124609
124610
124611
124612
124613
124614
124615
124616
124617
124618
124619
124620
124621
124622
124623
124624
124625
124626
124627
124628
124629
124630
124631
124632
124633
124634
124635
124636
124637
124638
124639
124640
124641
124642
124643
124644
124645
124646
124647
124648
124649
124650
124651
124652
124653
124654
124655
124656
124657
124658
124659
124660
124661
124662
124663
124664
124665
124666
124667
124668
124669
124670
124671
124672
124673
124674
124675
124676
124677
124678
124679
124680
124681
124682
124683
124684
124685
124686
124687
124688
124689
124690
124691
124692
124693
124694
124695
124696
124697
124698
124699
124700
124701
124702
124703
124704
124705
124706
124707
124708
124709
124710
124711
124712
124713
124714
124715
124716
124717
124718
124719
124720
124721
124722
124723
124724
124725
124726
124727
124728
124729
124730
124731
124732
124733
124734
124735
124736
124737
124738
124739
124740
124741
124742
124743
124744
124745
124746
124747
124748
124749
124750
124751
124752
124753
124754
124755
124756
124757
124758
124759
124760
124761
124762
124763
124764
124765
124766
124767
124768
124769
124770
124771
124772
124773
124774
124775
124776
124777
124778
124779
124780
124781
124782
124783
124784
124785
124786
124787
124788
124789
124790
124791
124792
124793
124794
124795
124796
124797
124798
124799
124800
124801
124802
124803
124804
124805
124806
124807
124808
124809
124810
124811
124812
124813
124814
124815
124816
124817
124818
124819
124820
124821
124822
124823
124824
124825
124826
124827
124828
124829
124830
124831
124832
124833
124834
124835
124836
124837
124838
124839
124840
124841
124842
124843
124844
124845
124846
124847
124848
124849
124850
124851
124852
124853
124854
124855
124856
124857
124858
124859
124860
124861
124862
124863
124864
124865
124866
124867
124868
124869
124870
124871
124872
124873
124874
124875
124876
124877
124878
124879
124880
124881
124882
124883
124884
124885
124886
124887
124888
124889
124890
124891
124892
124893
124894
124895
124896
124897
124898
124899
124900
124901
124902
124903
124904
124905
124906
124907
124908
124909
124910
124911
124912
124913
124914
124915
124916
124917
124918
124919
124920
124921
124922
124923
124924
124925
124926
124927
124928
124929
124930
124931
124932
124933
124934
124935
124936
124937
124938
124939
124940
124941
124942
124943
124944
124945
124946
124947
124948
124949
124950
124951
124952
124953
124954
124955
124956
124957
124958
124959
124960
124961
124962
124963
124964
124965
124966
124967
124968
124969
124970
124971
124972
124973
124974
124975
124976
124977
124978
124979
124980
124981
124982
124983
124984
124985
124986
124987
124988
124989
124990
124991
124992
124993
124994
124995
124996
124997
124998
124999
125000
125001
125002
125003
125004
125005
125006
125007
125008
125009
125010
125011
125012
125013
125014
125015
125016
125017
125018
125019
125020
125021
125022
125023
125024
125025
125026
125027
125028
125029
125030
125031
125032
125033
125034
125035
125036
125037
125038
125039
125040
125041
125042
125043
125044
125045
125046
125047
125048
125049
125050
125051
125052
125053
125054
125055
125056
125057
125058
125059
125060
125061
125062
125063
125064
125065
125066
125067
125068
125069
125070
125071
125072
125073
125074
125075
125076
125077
125078
125079
125080
125081
125082
125083
125084
125085
125086
125087
125088
125089
125090
125091
125092
125093
125094
125095
125096
125097
125098
125099
125100
125101
125102
125103
125104
125105
125106
125107
125108
125109
125110
125111
125112
125113
125114
125115
125116
125117
125118
125119
125120
125121
125122
125123
125124
125125
125126
125127
125128
125129
125130
125131
125132
125133
125134
125135
125136
125137
125138
125139
125140
125141
125142
125143
125144
125145
125146
125147
125148
125149
125150
125151
125152
125153
125154
125155
125156
125157
125158
125159
125160
125161
125162
125163
125164
125165
125166
125167
125168
125169
125170
125171
125172
125173
125174
125175
125176
125177
125178
125179
125180
125181
125182
125183
125184
125185
125186
125187
125188
125189
125190
125191
125192
125193
125194
125195
125196
125197
125198
125199
125200
125201
125202
125203
125204
125205
125206
125207
125208
125209
125210
125211
125212
125213
125214
125215
125216
125217
125218
125219
125220
125221
125222
125223
125224
125225
125226
125227
125228
125229
125230
125231
125232
125233
125234
125235
125236
125237
125238
125239
125240
125241
125242
125243
125244
125245
125246
125247
125248
125249
125250
125251
125252
125253
125254
125255
125256
125257
125258
125259
125260
125261
125262
125263
125264
125265
125266
125267
125268
125269
125270
125271
125272
125273
125274
125275
125276
125277
125278
125279
125280
125281
125282
125283
125284
125285
125286
125287
125288
125289
125290
125291
125292
125293
125294
125295
125296
125297
125298
125299
125300
125301
125302
125303
125304
125305
125306
125307
125308
125309
125310
125311
125312
125313
125314
125315
125316
125317
125318
125319
125320
125321
125322
125323
125324
125325
125326
125327
125328
125329
125330
125331
125332
125333
125334
125335
125336
125337
125338
125339
125340
125341
125342
125343
125344
125345
125346
125347
125348
125349
125350
125351
125352
125353
125354
125355
125356
125357
125358
125359
125360
125361
125362
125363
125364
125365
125366
125367
125368
125369
125370
125371
125372
125373
125374
125375
125376
125377
125378
125379
125380
125381
125382
125383
125384
125385
125386
125387
125388
125389
125390
125391
125392
125393
125394
125395
125396
125397
125398
125399
125400
125401
125402
125403
125404
125405
125406
125407
125408
125409
125410
125411
125412
125413
125414
125415
125416
125417
125418
125419
125420
125421
125422
125423
125424
125425
125426
125427
125428
125429
125430
125431
125432
125433
125434
125435
125436
125437
125438
125439
125440
125441
125442
125443
125444
125445
125446
125447
125448
125449
125450
125451
125452
125453
125454
125455
125456
125457
125458
125459
125460
125461
125462
125463
125464
125465
125466
125467
125468
125469
125470
125471
125472
125473
125474
125475
125476
125477
125478
125479
125480
125481
125482
125483
125484
125485
125486
125487
125488
125489
125490
125491
125492
125493
125494
125495
125496
125497
125498
125499
125500
125501
125502
125503
125504
125505
125506
125507
125508
125509
125510
125511
125512
125513
125514
125515
125516
125517
125518
125519
125520
125521
125522
125523
125524
125525
125526
125527
125528
125529
125530
125531
125532
125533
125534
125535
125536
125537
125538
125539
125540
125541
125542
125543
125544
125545
125546
125547
125548
125549
125550
125551
125552
125553
125554
125555
125556
125557
125558
125559
125560
125561
125562
125563
125564
125565
125566
125567
125568
125569
125570
125571
125572
125573
125574
125575
125576
125577
125578
125579
125580
125581
125582
125583
125584
125585
125586
125587
125588
125589
125590
125591
125592
125593
125594
125595
125596
125597
125598
125599
125600
125601
125602
125603
125604
125605
125606
125607
125608
125609
125610
125611
125612
125613
125614
125615
125616
125617
125618
125619
125620
125621
125622
125623
125624
125625
125626
125627
125628
125629
125630
125631
125632
125633
125634
125635
125636
125637
125638
125639
125640
125641
125642
125643
125644
125645
125646
125647
125648
125649
125650
125651
125652
125653
125654
125655
125656
125657
125658
125659
125660
125661
125662
125663
125664
125665
125666
125667
125668
125669
125670
125671
125672
125673
125674
125675
125676
125677
125678
125679
125680
125681
125682
125683
125684
125685
125686
125687
125688
125689
125690
125691
125692
125693
125694
125695
125696
125697
125698
125699
125700
125701
125702
125703
125704
125705
125706
125707
125708
125709
125710
125711
125712
125713
125714
125715
125716
125717
125718
125719
125720
125721
125722
125723
125724
125725
125726
125727
125728
125729
125730
125731
125732
125733
125734
125735
125736
125737
125738
125739
125740
125741
125742
125743
125744
125745
125746
125747
125748
125749
125750
125751
125752
125753
125754
125755
125756
125757
125758
125759
125760
125761
125762
125763
125764
125765
125766
125767
125768
125769
125770
125771
125772
125773
125774
125775
125776
125777
125778
125779
125780
125781
125782
125783
125784
125785
125786
125787
125788
125789
125790
125791
125792
125793
125794
125795
125796
125797
125798
125799
125800
125801
125802
125803
125804
125805
125806
125807
125808
125809
125810
125811
125812
125813
125814
125815
125816
125817
125818
125819
125820
125821
125822
125823
125824
125825
125826
125827
125828
125829
125830
125831
125832
125833
125834
125835
125836
125837
125838
125839
125840
125841
125842
125843
125844
125845
125846
125847
125848
125849
125850
125851
125852
125853
125854
125855
125856
125857
125858
125859
125860
125861
125862
125863
125864
125865
125866
125867
125868
125869
125870
125871
125872
125873
125874
125875
125876
125877
125878
125879
125880
125881
125882
125883
125884
125885
125886
125887
125888
125889
125890
125891
125892
125893
125894
125895
125896
125897
125898
125899
125900
125901
125902
125903
125904
125905
125906
125907
125908
125909
125910
125911
125912
125913
125914
125915
125916
125917
125918
125919
125920
125921
125922
125923
125924
125925
125926
125927
125928
125929
125930
125931
125932
125933
125934
125935
125936
125937
125938
125939
125940
125941
125942
125943
125944
125945
125946
125947
125948
125949
125950
125951
125952
125953
125954
125955
125956
125957
125958
125959
125960
125961
125962
125963
125964
125965
125966
125967
125968
125969
125970
125971
125972
125973
125974
125975
125976
125977
125978
125979
125980
125981
125982
125983
125984
125985
125986
125987
125988
125989
125990
125991
125992
125993
125994
125995
125996
125997
125998
125999
126000
126001
126002
126003
126004
126005
126006
126007
126008
126009
126010
126011
126012
126013
126014
126015
126016
126017
126018
126019
126020
126021
126022
126023
126024
126025
126026
126027
126028
126029
126030
126031
126032
126033
126034
126035
126036
126037
126038
126039
126040
126041
126042
126043
126044
126045
126046
126047
126048
126049
126050
126051
126052
126053
126054
126055
126056
126057
126058
126059
126060
126061
126062
126063
126064
126065
126066
126067
126068
126069
126070
126071
126072
126073
126074
126075
126076
126077
126078
126079
126080
126081
126082
126083
126084
126085
126086
126087
126088
126089
126090
126091
126092
126093
126094
126095
126096
126097
126098
126099
126100
126101
126102
126103
126104
126105
126106
126107
126108
126109
126110
126111
126112
126113
126114
126115
126116
126117
126118
126119
126120
126121
126122
126123
126124
126125
126126
126127
126128
126129
126130
126131
126132
126133
126134
126135
126136
126137
126138
126139
126140
126141
126142
126143
126144
126145
126146
126147
126148
126149
126150
126151
126152
126153
126154
126155
126156
126157
126158
126159
126160
126161
126162
126163
126164
126165
126166
126167
126168
126169
126170
126171
126172
126173
126174
126175
126176
126177
126178
126179
126180
126181
126182
126183
126184
126185
126186
126187
126188
126189
126190
126191
126192
126193
126194
126195
126196
126197
126198
126199
126200
126201
126202
126203
126204
126205
126206
126207
126208
126209
126210
126211
126212
126213
126214
126215
126216
126217
126218
126219
126220
126221
126222
126223
126224
126225
126226
126227
126228
126229
126230
126231
126232
126233
126234
126235
126236
126237
126238
126239
126240
126241
126242
126243
126244
126245
126246
126247
126248
126249
126250
126251
126252
126253
126254
126255
126256
126257
126258
126259
126260
126261
126262
126263
126264
126265
126266
126267
126268
126269
126270
126271
126272
126273
126274
126275
126276
126277
126278
126279
126280
126281
126282
126283
126284
126285
126286
126287
126288
126289
126290
126291
126292
126293
126294
126295
126296
126297
126298
126299
126300
126301
126302
126303
126304
126305
126306
126307
126308
126309
126310
126311
126312
126313
126314
126315
126316
126317
126318
126319
126320
126321
126322
126323
126324
126325
126326
126327
126328
126329
126330
126331
126332
126333
126334
126335
126336
126337
126338
126339
126340
126341
126342
126343
126344
126345
126346
126347
126348
126349
126350
126351
126352
126353
126354
126355
126356
126357
126358
126359
126360
126361
126362
126363
126364
126365
126366
126367
126368
126369
126370
126371
126372
126373
126374
126375
126376
126377
126378
126379
126380
126381
126382
126383
126384
126385
126386
126387
126388
126389
126390
126391
126392
126393
126394
126395
126396
126397
126398
126399
126400
126401
126402
126403
126404
126405
126406
126407
126408
126409
126410
126411
126412
126413
126414
126415
126416
126417
126418
126419
126420
126421
126422
126423
126424
126425
126426
126427
126428
126429
126430
126431
126432
126433
126434
126435
126436
126437
126438
126439
126440
126441
126442
126443
126444
126445
126446
126447
126448
126449
126450
126451
126452
126453
126454
126455
126456
126457
126458
126459
126460
126461
126462
126463
126464
126465
126466
126467
126468
126469
126470
126471
126472
126473
126474
126475
126476
126477
126478
126479
126480
126481
126482
126483
126484
126485
126486
126487
126488
126489
126490
126491
126492
126493
126494
126495
126496
126497
126498
126499
126500
126501
126502
126503
126504
126505
126506
126507
126508
126509
126510
126511
126512
126513
126514
126515
126516
126517
126518
126519
126520
126521
126522
126523
126524
126525
126526
126527
126528
126529
126530
126531
126532
126533
126534
126535
126536
126537
126538
126539
126540
126541
126542
126543
126544
126545
126546
126547
126548
126549
126550
126551
126552
126553
126554
126555
126556
126557
126558
126559
126560
126561
126562
126563
126564
126565
126566
126567
126568
126569
126570
126571
126572
126573
126574
126575
126576
126577
126578
126579
126580
126581
126582
126583
126584
126585
126586
126587
126588
126589
126590
126591
126592
126593
126594
126595
126596
126597
126598
126599
126600
126601
126602
126603
126604
126605
126606
126607
126608
126609
126610
126611
126612
126613
126614
126615
126616
126617
126618
126619
126620
126621
126622
126623
126624
126625
126626
126627
126628
126629
126630
126631
126632
126633
126634
126635
126636
126637
126638
126639
126640
126641
126642
126643
126644
126645
126646
126647
126648
126649
126650
126651
126652
126653
126654
126655
126656
126657
126658
126659
126660
126661
126662
126663
126664
126665
126666
126667
126668
126669
126670
126671
126672
126673
126674
126675
126676
126677
126678
126679
126680
126681
126682
126683
126684
126685
126686
126687
126688
126689
126690
126691
126692
126693
126694
126695
126696
126697
126698
126699
126700
126701
126702
126703
126704
126705
126706
126707
126708
126709
126710
126711
126712
126713
126714
126715
126716
126717
126718
126719
126720
126721
126722
126723
126724
126725
126726
126727
126728
126729
126730
126731
126732
126733
126734
126735
126736
126737
126738
126739
126740
126741
126742
126743
126744
126745
126746
126747
126748
126749
126750
126751
126752
126753
126754
126755
126756
126757
126758
126759
126760
126761
126762
126763
126764
126765
126766
126767
126768
126769
126770
126771
126772
126773
126774
126775
126776
126777
126778
126779
126780
126781
126782
126783
126784
126785
126786
126787
126788
126789
126790
126791
126792
126793
126794
126795
126796
126797
126798
126799
126800
126801
126802
126803
126804
126805
126806
126807
126808
126809
126810
126811
126812
126813
126814
126815
126816
126817
126818
126819
126820
126821
126822
126823
126824
126825
126826
126827
126828
126829
126830
126831
126832
126833
126834
126835
126836
126837
126838
126839
126840
126841
126842
126843
126844
126845
126846
126847
126848
126849
126850
126851
126852
126853
126854
126855
126856
126857
126858
126859
126860
126861
126862
126863
126864
126865
126866
126867
126868
126869
126870
126871
126872
126873
126874
126875
126876
126877
126878
126879
126880
126881
126882
126883
126884
126885
126886
126887
126888
126889
126890
126891
126892
126893
126894
126895
126896
126897
126898
126899
126900
126901
126902
126903
126904
126905
126906
126907
126908
126909
126910
126911
126912
126913
126914
126915
126916
126917
126918
126919
126920
126921
126922
126923
126924
126925
126926
126927
126928
126929
126930
126931
126932
126933
126934
126935
126936
126937
126938
126939
126940
126941
126942
126943
126944
126945
126946
126947
126948
126949
126950
126951
126952
126953
126954
126955
126956
126957
126958
126959
126960
126961
126962
126963
126964
126965
126966
126967
126968
126969
126970
126971
126972
126973
126974
126975
126976
126977
126978
126979
126980
126981
126982
126983
126984
126985
126986
126987
126988
126989
126990
126991
126992
126993
126994
126995
126996
126997
126998
126999
127000
127001
127002
127003
127004
127005
127006
127007
127008
127009
127010
127011
127012
127013
127014
127015
127016
127017
127018
127019
127020
127021
127022
127023
127024
127025
127026
127027
127028
127029
127030
127031
127032
127033
127034
127035
127036
127037
127038
127039
127040
127041
127042
127043
127044
127045
127046
127047
127048
127049
127050
127051
127052
127053
127054
127055
127056
127057
127058
127059
127060
127061
127062
127063
127064
127065
127066
127067
127068
127069
127070
127071
127072
127073
127074
127075
127076
127077
127078
127079
127080
127081
127082
127083
127084
127085
127086
127087
127088
127089
127090
127091
127092
127093
127094
127095
127096
127097
127098
127099
127100
127101
127102
127103
127104
127105
127106
127107
127108
127109
127110
127111
127112
127113
127114
127115
127116
127117
127118
127119
127120
127121
127122
127123
127124
127125
127126
127127
127128
127129
127130
127131
127132
127133
127134
127135
127136
127137
127138
127139
127140
127141
127142
127143
127144
127145
127146
127147
127148
127149
127150
127151
127152
127153
127154
127155
127156
127157
127158
127159
127160
127161
127162
127163
127164
127165
127166
127167
127168
127169
127170
127171
127172
127173
127174
127175
127176
127177
127178
127179
127180
127181
127182
127183
127184
127185
127186
127187
127188
127189
127190
127191
127192
127193
127194
127195
127196
127197
127198
127199
127200
127201
127202
127203
127204
127205
127206
127207
127208
127209
127210
127211
127212
127213
127214
127215
127216
127217
127218
127219
127220
127221
127222
127223
127224
127225
127226
127227
127228
127229
127230
127231
127232
127233
127234
127235
127236
127237
127238
127239
127240
127241
127242
127243
127244
127245
127246
127247
127248
127249
127250
127251
127252
127253
127254
127255
127256
127257
127258
127259
127260
127261
127262
127263
127264
127265
127266
127267
127268
127269
127270
127271
127272
127273
127274
127275
127276
127277
127278
127279
127280
127281
127282
127283
127284
127285
127286
127287
127288
127289
127290
127291
127292
127293
127294
127295
127296
127297
127298
127299
127300
127301
127302
127303
127304
127305
127306
127307
127308
127309
127310
127311
127312
127313
127314
127315
127316
127317
127318
127319
127320
127321
127322
127323
127324
127325
127326
127327
127328
127329
127330
127331
127332
127333
127334
127335
127336
127337
127338
127339
127340
127341
127342
127343
127344
127345
127346
127347
127348
127349
127350
127351
127352
127353
127354
127355
127356
127357
127358
127359
127360
127361
127362
127363
127364
127365
127366
127367
127368
127369
127370
127371
127372
127373
127374
127375
127376
127377
127378
127379
127380
127381
127382
127383
127384
127385
127386
127387
127388
127389
127390
127391
127392
127393
127394
127395
127396
127397
127398
127399
127400
127401
127402
127403
127404
127405
127406
127407
127408
127409
127410
127411
127412
127413
127414
127415
127416
127417
127418
127419
127420
127421
127422
127423
127424
127425
127426
127427
127428
127429
127430
127431
127432
127433
127434
127435
127436
127437
127438
127439
127440
127441
127442
127443
127444
127445
127446
127447
127448
127449
127450
127451
127452
127453
127454
127455
127456
127457
127458
127459
127460
127461
127462
127463
127464
127465
127466
127467
127468
127469
127470
127471
127472
127473
127474
127475
127476
127477
127478
127479
127480
127481
127482
127483
127484
127485
127486
127487
127488
127489
127490
127491
127492
127493
127494
127495
127496
127497
127498
127499
127500
127501
127502
127503
127504
127505
127506
127507
127508
127509
127510
127511
127512
127513
127514
127515
127516
127517
127518
127519
127520
127521
127522
127523
127524
127525
127526
127527
127528
127529
127530
127531
127532
127533
127534
127535
127536
127537
127538
127539
127540
127541
127542
127543
127544
127545
127546
127547
127548
127549
127550
127551
127552
127553
127554
127555
127556
127557
127558
127559
127560
127561
127562
127563
127564
127565
127566
127567
127568
127569
127570
127571
127572
127573
127574
127575
127576
127577
127578
127579
127580
127581
127582
127583
127584
127585
127586
127587
127588
127589
127590
127591
127592
127593
127594
127595
127596
127597
127598
127599
127600
127601
127602
127603
127604
127605
127606
127607
127608
127609
127610
127611
127612
127613
127614
127615
127616
127617
127618
127619
127620
127621
127622
127623
127624
127625
127626
127627
127628
127629
127630
127631
127632
127633
127634
127635
127636
127637
127638
127639
127640
127641
127642
127643
127644
127645
127646
127647
127648
127649
127650
127651
127652
127653
127654
127655
127656
127657
127658
127659
127660
127661
127662
127663
127664
127665
127666
127667
127668
127669
127670
127671
127672
127673
127674
127675
127676
127677
127678
127679
127680
127681
127682
127683
127684
127685
127686
127687
127688
127689
127690
127691
127692
127693
127694
127695
127696
127697
127698
127699
127700
127701
127702
127703
127704
127705
127706
127707
127708
127709
127710
127711
127712
127713
127714
127715
127716
127717
127718
127719
127720
127721
127722
127723
127724
127725
127726
127727
127728
127729
127730
127731
127732
127733
127734
127735
127736
127737
127738
127739
127740
127741
127742
127743
127744
127745
127746
127747
127748
127749
127750
127751
127752
127753
127754
127755
127756
127757
127758
127759
127760
127761
127762
127763
127764
127765
127766
127767
127768
127769
127770
127771
127772
127773
127774
127775
127776
127777
127778
127779
127780
127781
127782
127783
127784
127785
127786
127787
127788
127789
127790
127791
127792
127793
127794
127795
127796
127797
127798
127799
127800
127801
127802
127803
127804
127805
127806
127807
127808
127809
127810
127811
127812
127813
127814
127815
127816
127817
127818
127819
127820
127821
127822
127823
127824
127825
127826
127827
127828
127829
127830
127831
127832
127833
127834
127835
127836
127837
127838
127839
127840
127841
127842
127843
127844
127845
127846
127847
127848
127849
127850
127851
127852
127853
127854
127855
127856
127857
127858
127859
127860
127861
127862
127863
127864
127865
127866
127867
127868
127869
127870
127871
127872
127873
127874
127875
127876
127877
127878
127879
127880
127881
127882
127883
127884
127885
127886
127887
127888
127889
127890
127891
127892
127893
127894
127895
127896
127897
127898
127899
127900
127901
127902
127903
127904
127905
127906
127907
127908
127909
127910
127911
127912
127913
127914
127915
127916
127917
127918
127919
127920
127921
127922
127923
127924
127925
127926
127927
127928
127929
127930
127931
127932
127933
127934
127935
127936
127937
127938
127939
127940
127941
127942
127943
127944
127945
127946
127947
127948
127949
127950
127951
127952
127953
127954
127955
127956
127957
127958
127959
127960
127961
127962
127963
127964
127965
127966
127967
127968
127969
127970
127971
127972
127973
127974
127975
127976
127977
127978
127979
127980
127981
127982
127983
127984
127985
127986
127987
127988
127989
127990
127991
127992
127993
127994
127995
127996
127997
127998
127999
128000
128001
128002
128003
128004
128005
128006
128007
128008
128009
128010
128011
128012
128013
128014
128015
128016
128017
128018
128019
128020
128021
128022
128023
128024
128025
128026
128027
128028
128029
128030
128031
128032
128033
128034
128035
128036
128037
128038
128039
128040
128041
128042
128043
128044
128045
128046
128047
128048
128049
128050
128051
128052
128053
128054
128055
128056
128057
128058
128059
128060
128061
128062
128063
128064
128065
128066
128067
128068
128069
128070
128071
128072
128073
128074
128075
128076
128077
128078
128079
128080
128081
128082
128083
128084
128085
128086
128087
128088
128089
128090
128091
128092
128093
128094
128095
128096
128097
128098
128099
128100
128101
128102
128103
128104
128105
128106
128107
128108
128109
128110
128111
128112
128113
128114
128115
128116
128117
128118
128119
128120
128121
128122
128123
128124
128125
128126
128127
128128
128129
128130
128131
128132
128133
128134
128135
128136
128137
128138
128139
128140
128141
128142
128143
128144
128145
128146
128147
128148
128149
128150
128151
128152
128153
128154
128155
128156
128157
128158
128159
128160
128161
128162
128163
128164
128165
128166
128167
128168
128169
128170
128171
128172
128173
128174
128175
128176
128177
128178
128179
128180
128181
128182
128183
128184
128185
128186
128187
128188
128189
128190
128191
128192
128193
128194
128195
128196
128197
128198
128199
128200
128201
128202
128203
128204
128205
128206
128207
128208
128209
128210
128211
128212
128213
128214
128215
128216
128217
128218
128219
128220
128221
128222
128223
128224
128225
128226
128227
128228
128229
128230
128231
128232
128233
128234
128235
128236
128237
128238
128239
128240
128241
128242
128243
128244
128245
128246
128247
128248
128249
128250
128251
128252
128253
128254
128255
128256
128257
128258
128259
128260
128261
128262
128263
128264
128265
128266
128267
128268
128269
128270
128271
128272
128273
128274
128275
128276
128277
128278
128279
128280
128281
128282
128283
128284
128285
128286
128287
128288
128289
128290
128291
128292
128293
128294
128295
128296
128297
128298
128299
128300
128301
128302
128303
128304
128305
128306
128307
128308
128309
128310
128311
128312
128313
128314
128315
128316
128317
128318
128319
128320
128321
128322
128323
128324
128325
128326
128327
128328
128329
128330
128331
128332
128333
128334
128335
128336
128337
128338
128339
128340
128341
128342
128343
128344
128345
128346
128347
128348
128349
128350
128351
128352
128353
128354
128355
128356
128357
128358
128359
128360
128361
128362
128363
128364
128365
128366
128367
128368
128369
128370
128371
128372
128373
128374
128375
128376
128377
128378
128379
128380
128381
128382
128383
128384
128385
128386
128387
128388
128389
128390
128391
128392
128393
128394
128395
128396
128397
128398
128399
128400
128401
128402
128403
128404
128405
128406
128407
128408
128409
128410
128411
128412
128413
128414
128415
128416
128417
128418
128419
128420
128421
128422
128423
128424
128425
128426
128427
128428
128429
128430
128431
128432
128433
128434
128435
128436
128437
128438
128439
128440
128441
128442
128443
128444
128445
128446
128447
128448
128449
128450
128451
128452
128453
128454
128455
128456
128457
128458
128459
128460
128461
128462
128463
128464
128465
128466
128467
128468
128469
128470
128471
128472
128473
128474
128475
128476
128477
128478
128479
128480
128481
128482
128483
128484
128485
128486
128487
128488
128489
128490
128491
128492
128493
128494
128495
128496
128497
128498
128499
128500
128501
128502
128503
128504
128505
128506
128507
128508
128509
128510
128511
128512
128513
128514
128515
128516
128517
128518
128519
128520
128521
128522
128523
128524
128525
128526
128527
128528
128529
128530
128531
128532
128533
128534
128535
128536
128537
128538
128539
128540
128541
128542
128543
128544
128545
128546
128547
128548
128549
128550
128551
128552
128553
128554
128555
128556
128557
128558
128559
128560
128561
128562
128563
128564
128565
128566
128567
128568
128569
128570
128571
128572
128573
128574
128575
128576
128577
128578
128579
128580
128581
128582
128583
128584
128585
128586
128587
128588
128589
128590
128591
128592
128593
128594
128595
128596
128597
128598
128599
128600
128601
128602
128603
128604
128605
128606
128607
128608
128609
128610
128611
128612
128613
128614
128615
128616
128617
128618
128619
128620
128621
128622
128623
128624
128625
128626
128627
128628
128629
128630
128631
128632
128633
128634
128635
128636
128637
128638
128639
128640
128641
128642
128643
128644
128645
128646
128647
128648
128649
128650
128651
128652
128653
128654
128655
128656
128657
128658
128659
128660
128661
128662
128663
128664
128665
128666
128667
128668
128669
128670
128671
128672
128673
128674
128675
128676
128677
128678
128679
128680
128681
128682
128683
128684
128685
128686
128687
128688
128689
128690
128691
128692
128693
128694
128695
128696
128697
128698
128699
128700
128701
128702
128703
128704
128705
128706
128707
128708
128709
128710
128711
128712
128713
128714
128715
128716
128717
128718
128719
128720
128721
128722
128723
128724
128725
128726
128727
128728
128729
128730
128731
128732
128733
128734
128735
128736
128737
128738
128739
128740
128741
128742
128743
128744
128745
128746
128747
128748
128749
128750
128751
128752
128753
128754
128755
128756
128757
128758
128759
128760
128761
128762
128763
128764
128765
128766
128767
128768
128769
128770
128771
128772
128773
128774
128775
128776
128777
128778
128779
128780
128781
128782
128783
128784
128785
128786
128787
128788
128789
128790
128791
128792
128793
128794
128795
128796
128797
128798
128799
128800
128801
128802
128803
128804
128805
128806
128807
128808
128809
128810
128811
128812
128813
128814
128815
128816
128817
128818
128819
128820
128821
128822
128823
128824
128825
128826
128827
128828
128829
128830
128831
128832
128833
128834
128835
128836
128837
128838
128839
128840
128841
128842
128843
128844
128845
128846
128847
128848
128849
128850
128851
128852
128853
128854
128855
128856
128857
128858
128859
128860
128861
128862
128863
128864
128865
128866
128867
128868
128869
128870
128871
128872
128873
128874
128875
128876
128877
128878
128879
128880
128881
128882
128883
128884
128885
128886
128887
128888
128889
128890
128891
128892
128893
128894
128895
128896
128897
128898
128899
128900
128901
128902
128903
128904
128905
128906
128907
128908
128909
128910
128911
128912
128913
128914
128915
128916
128917
128918
128919
128920
128921
128922
128923
128924
128925
128926
128927
128928
128929
128930
128931
128932
128933
128934
128935
128936
128937
128938
128939
128940
128941
128942
128943
128944
128945
128946
128947
128948
128949
128950
128951
128952
128953
128954
128955
128956
128957
128958
128959
128960
128961
128962
128963
128964
128965
128966
128967
128968
128969
128970
128971
128972
128973
128974
128975
128976
128977
128978
128979
128980
128981
128982
128983
128984
128985
128986
128987
128988
128989
128990
128991
128992
128993
128994
128995
128996
128997
128998
128999
129000
129001
129002
129003
129004
129005
129006
129007
129008
129009
129010
129011
129012
129013
129014
129015
129016
129017
129018
129019
129020
129021
129022
129023
129024
129025
129026
129027
129028
129029
129030
129031
129032
129033
129034
129035
129036
129037
129038
129039
129040
129041
129042
129043
129044
129045
129046
129047
129048
129049
129050
129051
129052
129053
129054
129055
129056
129057
129058
129059
129060
129061
129062
129063
129064
129065
129066
129067
129068
129069
129070
129071
129072
129073
129074
129075
129076
129077
129078
129079
129080
129081
129082
129083
129084
129085
129086
129087
129088
129089
129090
129091
129092
129093
129094
129095
129096
129097
129098
129099
129100
129101
129102
129103
129104
129105
129106
129107
129108
129109
129110
129111
129112
129113
129114
129115
129116
129117
129118
129119
129120
129121
129122
129123
129124
129125
129126
129127
129128
129129
129130
129131
129132
129133
129134
129135
129136
129137
129138
129139
129140
129141
129142
129143
129144
129145
129146
129147
129148
129149
129150
129151
129152
129153
129154
129155
129156
129157
129158
129159
129160
129161
129162
129163
129164
129165
129166
129167
129168
129169
129170
129171
129172
129173
129174
129175
129176
129177
129178
129179
129180
129181
129182
129183
129184
129185
129186
129187
129188
129189
129190
129191
129192
129193
129194
129195
129196
129197
129198
129199
129200
129201
129202
129203
129204
129205
129206
129207
129208
129209
129210
129211
129212
129213
129214
129215
129216
129217
129218
129219
129220
129221
129222
129223
129224
129225
129226
129227
129228
129229
129230
129231
129232
129233
129234
129235
129236
129237
129238
129239
129240
129241
129242
129243
129244
129245
129246
129247
129248
129249
129250
129251
129252
129253
129254
129255
129256
129257
129258
129259
129260
129261
129262
129263
129264
129265
129266
129267
129268
129269
129270
129271
129272
129273
129274
129275
129276
129277
129278
129279
129280
129281
129282
129283
129284
129285
129286
129287
129288
129289
129290
129291
129292
129293
129294
129295
129296
129297
129298
129299
129300
129301
129302
129303
129304
129305
129306
129307
129308
129309
129310
129311
129312
129313
129314
129315
129316
129317
129318
129319
129320
129321
129322
129323
129324
129325
129326
129327
129328
129329
129330
129331
129332
129333
129334
129335
129336
129337
129338
129339
129340
129341
129342
129343
129344
129345
129346
129347
129348
129349
129350
129351
129352
129353
129354
129355
129356
129357
129358
129359
129360
129361
129362
129363
129364
129365
129366
129367
129368
129369
129370
129371
129372
129373
129374
129375
129376
129377
129378
129379
129380
129381
129382
129383
129384
129385
129386
129387
129388
129389
129390
129391
129392
129393
129394
129395
129396
129397
129398
129399
129400
129401
129402
129403
129404
129405
129406
129407
129408
129409
129410
129411
129412
129413
129414
129415
129416
129417
129418
129419
129420
129421
129422
129423
129424
129425
129426
129427
129428
129429
129430
129431
129432
129433
129434
129435
129436
129437
129438
129439
129440
129441
129442
129443
129444
129445
129446
129447
129448
129449
129450
129451
129452
129453
129454
129455
129456
129457
129458
129459
129460
129461
129462
129463
129464
129465
129466
129467
129468
129469
129470
129471
129472
129473
129474
129475
129476
129477
129478
129479
129480
129481
129482
129483
129484
129485
129486
129487
129488
129489
129490
129491
129492
129493
129494
129495
129496
129497
129498
129499
129500
129501
129502
129503
129504
129505
129506
129507
129508
129509
129510
129511
129512
129513
129514
129515
129516
129517
129518
129519
129520
129521
129522
129523
129524
129525
129526
129527
129528
129529
129530
129531
129532
129533
129534
129535
129536
129537
129538
129539
129540
129541
129542
129543
129544
129545
129546
129547
129548
129549
129550
129551
129552
129553
129554
129555
129556
129557
129558
129559
129560
129561
129562
129563
129564
129565
129566
129567
129568
129569
129570
129571
129572
129573
129574
129575
129576
129577
129578
129579
129580
129581
129582
129583
129584
129585
129586
129587
129588
129589
129590
129591
129592
129593
129594
129595
129596
129597
129598
129599
129600
129601
129602
129603
129604
129605
129606
129607
129608
129609
129610
129611
129612
129613
129614
129615
129616
129617
129618
129619
129620
129621
129622
129623
129624
129625
129626
129627
129628
129629
129630
129631
129632
129633
129634
129635
129636
129637
129638
129639
129640
129641
129642
129643
129644
129645
129646
129647
129648
129649
129650
129651
129652
129653
129654
129655
129656
129657
129658
129659
129660
129661
129662
129663
129664
129665
129666
129667
129668
129669
129670
129671
129672
129673
129674
129675
129676
129677
129678
129679
129680
129681
129682
129683
129684
129685
129686
129687
129688
129689
129690
129691
129692
129693
129694
129695
129696
129697
129698
129699
129700
129701
129702
129703
129704
129705
129706
129707
129708
129709
129710
129711
129712
129713
129714
129715
129716
129717
129718
129719
129720
129721
129722
129723
129724
129725
129726
129727
129728
129729
129730
129731
129732
129733
129734
129735
129736
129737
129738
129739
129740
129741
129742
129743
129744
129745
129746
129747
129748
129749
129750
129751
129752
129753
129754
129755
129756
129757
129758
129759
129760
129761
129762
129763
129764
129765
129766
129767
129768
129769
129770
129771
129772
129773
129774
129775
129776
129777
129778
129779
129780
129781
129782
129783
129784
129785
129786
129787
129788
129789
129790
129791
129792
129793
129794
129795
129796
129797
129798
129799
129800
129801
129802
129803
129804
129805
129806
129807
129808
129809
129810
129811
129812
129813
129814
129815
129816
129817
129818
129819
129820
129821
129822
129823
129824
129825
129826
129827
129828
129829
129830
129831
129832
129833
129834
129835
129836
129837
129838
129839
129840
129841
129842
129843
129844
129845
129846
129847
129848
129849
129850
129851
129852
129853
129854
129855
129856
129857
129858
129859
129860
129861
129862
129863
129864
129865
129866
129867
129868
129869
129870
129871
129872
129873
129874
129875
129876
129877
129878
129879
129880
129881
129882
129883
129884
129885
129886
129887
129888
129889
129890
129891
129892
129893
129894
129895
129896
129897
129898
129899
129900
129901
129902
129903
129904
129905
129906
129907
129908
129909
129910
129911
129912
129913
129914
129915
129916
129917
129918
129919
129920
129921
129922
129923
129924
129925
129926
129927
129928
129929
129930
129931
129932
129933
129934
129935
129936
129937
129938
129939
129940
129941
129942
129943
129944
129945
129946
129947
129948
129949
129950
129951
129952
129953
129954
129955
129956
129957
129958
129959
129960
129961
129962
129963
129964
129965
129966
129967
129968
129969
129970
129971
129972
129973
129974
129975
129976
129977
129978
129979
129980
129981
129982
129983
129984
129985
129986
129987
129988
129989
129990
129991
129992
129993
129994
129995
129996
129997
129998
129999
130000
130001
130002
130003
130004
130005
130006
130007
130008
130009
130010
130011
130012
130013
130014
130015
130016
130017
130018
130019
130020
130021
130022
130023
130024
130025
130026
130027
130028
130029
130030
130031
130032
130033
130034
130035
130036
130037
130038
130039
130040
130041
130042
130043
130044
130045
130046
130047
130048
130049
130050
130051
130052
130053
130054
130055
130056
130057
130058
130059
130060
130061
130062
130063
130064
130065
130066
130067
130068
130069
130070
130071
130072
130073
130074
130075
130076
130077
130078
130079
130080
130081
130082
130083
130084
130085
130086
130087
130088
130089
130090
130091
130092
130093
130094
130095
130096
130097
130098
130099
130100
130101
130102
130103
130104
130105
130106
130107
130108
130109
130110
130111
130112
130113
130114
130115
130116
130117
130118
130119
130120
130121
130122
130123
130124
130125
130126
130127
130128
130129
130130
130131
130132
130133
130134
130135
130136
130137
130138
130139
130140
130141
130142
130143
130144
130145
130146
130147
130148
130149
130150
130151
130152
130153
130154
130155
130156
130157
130158
130159
130160
130161
130162
130163
130164
130165
130166
130167
130168
130169
130170
130171
130172
130173
130174
130175
130176
130177
130178
130179
130180
130181
130182
130183
130184
130185
130186
130187
130188
130189
130190
130191
130192
130193
130194
130195
130196
130197
130198
130199
130200
130201
130202
130203
130204
130205
130206
130207
130208
130209
130210
130211
130212
130213
130214
130215
130216
130217
130218
130219
130220
130221
130222
130223
130224
130225
130226
130227
130228
130229
130230
130231
130232
130233
130234
130235
130236
130237
130238
130239
130240
130241
130242
130243
130244
130245
130246
130247
130248
130249
130250
130251
130252
130253
130254
130255
130256
130257
130258
130259
130260
130261
130262
130263
130264
130265
130266
130267
130268
130269
130270
130271
130272
130273
130274
130275
130276
130277
130278
130279
130280
130281
130282
130283
130284
130285
130286
130287
130288
130289
130290
130291
130292
130293
130294
130295
130296
130297
130298
130299
130300
130301
130302
130303
130304
130305
130306
130307
130308
130309
130310
130311
130312
130313
130314
130315
130316
130317
130318
130319
130320
130321
130322
130323
130324
130325
130326
130327
130328
130329
130330
130331
130332
130333
130334
130335
130336
130337
130338
130339
130340
130341
130342
130343
130344
130345
130346
130347
130348
130349
130350
130351
130352
130353
130354
130355
130356
130357
130358
130359
130360
130361
130362
130363
130364
130365
130366
130367
130368
130369
130370
130371
130372
130373
130374
130375
130376
130377
130378
130379
130380
130381
130382
130383
130384
130385
130386
130387
130388
130389
130390
130391
130392
130393
130394
130395
130396
130397
130398
130399
130400
130401
130402
130403
130404
130405
130406
130407
130408
130409
130410
130411
130412
130413
130414
130415
130416
130417
130418
130419
130420
130421
130422
130423
130424
130425
130426
130427
130428
130429
130430
130431
130432
130433
130434
130435
130436
130437
130438
130439
130440
130441
130442
130443
130444
130445
130446
130447
130448
130449
130450
130451
130452
130453
130454
130455
130456
130457
130458
130459
130460
130461
130462
130463
130464
130465
130466
130467
130468
130469
130470
130471
130472
130473
130474
130475
130476
130477
130478
130479
130480
130481
130482
130483
130484
130485
130486
130487
130488
130489
130490
130491
130492
130493
130494
130495
130496
130497
130498
130499
130500
130501
130502
130503
130504
130505
130506
130507
130508
130509
130510
130511
130512
130513
130514
130515
130516
130517
130518
130519
130520
130521
130522
130523
130524
130525
130526
130527
130528
130529
130530
130531
130532
130533
130534
130535
130536
130537
130538
130539
130540
130541
130542
130543
130544
130545
130546
130547
130548
130549
130550
130551
130552
130553
130554
130555
130556
130557
130558
130559
130560
130561
130562
130563
130564
130565
130566
130567
130568
130569
130570
130571
130572
130573
130574
130575
130576
130577
130578
130579
130580
130581
130582
130583
130584
130585
130586
130587
130588
130589
130590
130591
130592
130593
130594
130595
130596
130597
130598
130599
130600
130601
130602
130603
130604
130605
130606
130607
130608
130609
130610
130611
130612
130613
130614
130615
130616
130617
130618
130619
130620
130621
130622
130623
130624
130625
130626
130627
130628
130629
130630
130631
130632
130633
130634
130635
130636
130637
130638
130639
130640
130641
130642
130643
130644
130645
130646
130647
130648
130649
130650
130651
130652
130653
130654
130655
130656
130657
130658
130659
130660
130661
130662
130663
130664
130665
130666
130667
130668
130669
130670
130671
130672
130673
130674
130675
130676
130677
130678
130679
130680
130681
130682
130683
130684
130685
130686
130687
130688
130689
130690
130691
130692
130693
130694
130695
130696
130697
130698
130699
130700
130701
130702
130703
130704
130705
130706
130707
130708
130709
130710
130711
130712
130713
130714
130715
130716
130717
130718
130719
130720
130721
130722
130723
130724
130725
130726
130727
130728
130729
130730
130731
130732
130733
130734
130735
130736
130737
130738
130739
130740
130741
130742
130743
130744
130745
130746
130747
130748
130749
130750
130751
130752
130753
130754
130755
130756
130757
130758
130759
130760
130761
130762
130763
130764
130765
130766
130767
130768
130769
130770
130771
130772
130773
130774
130775
130776
130777
130778
130779
130780
130781
130782
130783
130784
130785
130786
130787
130788
130789
130790
130791
130792
130793
130794
130795
130796
130797
130798
130799
130800
130801
130802
130803
130804
130805
130806
130807
130808
130809
130810
130811
130812
130813
130814
130815
130816
130817
130818
130819
130820
130821
130822
130823
130824
130825
130826
130827
130828
130829
130830
130831
130832
130833
130834
130835
130836
130837
130838
130839
130840
130841
130842
130843
130844
130845
130846
130847
130848
130849
130850
130851
130852
130853
130854
130855
130856
130857
130858
130859
130860
130861
130862
130863
130864
130865
130866
130867
130868
130869
130870
130871
130872
130873
130874
130875
130876
130877
130878
130879
130880
130881
130882
130883
130884
130885
130886
130887
130888
130889
130890
130891
130892
130893
130894
130895
130896
130897
130898
130899
130900
130901
130902
130903
130904
130905
130906
130907
130908
130909
130910
130911
130912
130913
130914
130915
130916
130917
130918
130919
130920
130921
130922
130923
130924
130925
130926
130927
130928
130929
130930
130931
130932
130933
130934
130935
130936
130937
130938
130939
130940
130941
130942
130943
130944
130945
130946
130947
130948
130949
130950
130951
130952
130953
130954
130955
130956
130957
130958
130959
130960
130961
130962
130963
130964
130965
130966
130967
130968
130969
130970
130971
130972
130973
130974
130975
130976
130977
130978
130979
130980
130981
130982
130983
130984
130985
130986
130987
130988
130989
130990
130991
130992
130993
130994
130995
130996
130997
130998
130999
131000
131001
131002
131003
131004
131005
131006
131007
131008
131009
131010
131011
131012
131013
131014
131015
131016
131017
131018
131019
131020
131021
131022
131023
131024
131025
131026
131027
131028
131029
131030
131031
131032
131033
131034
131035
131036
131037
131038
131039
131040
131041
131042
131043
131044
131045
131046
131047
131048
131049
131050
131051
131052
131053
131054
131055
131056
131057
131058
131059
131060
131061
131062
131063
131064
131065
131066
131067
131068
131069
131070
131071
131072
131073
131074
131075
131076
131077
131078
131079
131080
131081
131082
131083
131084
131085
131086
131087
131088
131089
131090
131091
131092
131093
131094
131095
131096
131097
131098
131099
131100
131101
131102
131103
131104
131105
131106
131107
131108
131109
131110
131111
131112
131113
131114
131115
131116
131117
131118
131119
131120
131121
131122
131123
131124
131125
131126
131127
131128
131129
131130
131131
131132
131133
131134
131135
131136
131137
131138
131139
131140
131141
131142
131143
131144
131145
131146
131147
131148
131149
131150
131151
131152
131153
131154
131155
131156
131157
131158
131159
131160
131161
131162
131163
131164
131165
131166
131167
131168
131169
131170
131171
131172
131173
131174
131175
131176
131177
131178
131179
131180
131181
131182
131183
131184
131185
131186
131187
131188
131189
131190
131191
131192
131193
131194
131195
131196
131197
131198
131199
131200
131201
131202
131203
131204
131205
131206
131207
131208
131209
131210
131211
131212
131213
131214
131215
131216
131217
131218
131219
131220
131221
131222
131223
131224
131225
131226
131227
131228
131229
131230
131231
131232
131233
131234
131235
131236
131237
131238
131239
131240
131241
131242
131243
131244
131245
131246
131247
131248
131249
131250
131251
131252
131253
131254
131255
131256
131257
131258
131259
131260
131261
131262
131263
131264
131265
131266
131267
131268
131269
131270
131271
131272
131273
131274
131275
131276
131277
131278
131279
131280
131281
131282
131283
131284
131285
131286
131287
131288
131289
131290
131291
131292
131293
131294
131295
131296
131297
131298
131299
131300
131301
131302
131303
131304
131305
131306
131307
131308
131309
131310
131311
131312
131313
131314
131315
131316
131317
131318
131319
131320
131321
131322
131323
131324
131325
131326
131327
131328
131329
131330
131331
131332
131333
131334
131335
131336
131337
131338
131339
131340
131341
131342
131343
131344
131345
131346
131347
131348
131349
131350
131351
131352
131353
131354
131355
131356
131357
131358
131359
131360
131361
131362
131363
131364
131365
131366
131367
131368
131369
131370
131371
131372
131373
131374
131375
131376
131377
131378
131379
131380
131381
131382
131383
131384
131385
131386
131387
131388
131389
131390
131391
131392
131393
131394
131395
131396
131397
131398
131399
131400
131401
131402
131403
131404
131405
131406
131407
131408
131409
131410
131411
131412
131413
131414
131415
131416
131417
131418
131419
131420
131421
131422
131423
131424
131425
131426
131427
131428
131429
131430
131431
131432
131433
131434
131435
131436
131437
131438
131439
131440
131441
131442
131443
131444
131445
131446
131447
131448
131449
131450
131451
131452
131453
131454
131455
131456
131457
131458
131459
131460
131461
131462
131463
131464
131465
131466
131467
131468
131469
131470
131471
131472
131473
131474
131475
131476
131477
131478
131479
131480
131481
131482
131483
131484
131485
131486
131487
131488
131489
131490
131491
131492
131493
131494
131495
131496
131497
131498
131499
131500
131501
131502
131503
131504
131505
131506
131507
131508
131509
131510
131511
131512
131513
131514
131515
131516
131517
131518
131519
131520
131521
131522
131523
131524
131525
131526
131527
131528
131529
131530
131531
131532
131533
131534
131535
131536
131537
131538
131539
131540
131541
131542
131543
131544
131545
131546
131547
131548
131549
131550
131551
131552
131553
131554
131555
131556
131557
131558
131559
131560
131561
131562
131563
131564
131565
131566
131567
131568
131569
131570
131571
131572
131573
131574
131575
131576
131577
131578
131579
131580
131581
131582
131583
131584
131585
131586
131587
131588
131589
131590
131591
131592
131593
131594
131595
131596
131597
131598
131599
131600
131601
131602
131603
131604
131605
131606
131607
131608
131609
131610
131611
131612
131613
131614
131615
131616
131617
131618
131619
131620
131621
131622
131623
131624
131625
131626
131627
131628
131629
131630
131631
131632
131633
131634
131635
131636
131637
131638
131639
131640
131641
131642
131643
131644
131645
131646
131647
131648
131649
131650
131651
131652
131653
131654
131655
131656
131657
131658
131659
131660
131661
131662
131663
131664
131665
131666
131667
131668
131669
131670
131671
131672
131673
131674
131675
131676
131677
131678
131679
131680
131681
131682
131683
131684
131685
131686
131687
131688
131689
131690
131691
131692
131693
131694
131695
131696
131697
131698
131699
131700
131701
131702
131703
131704
131705
131706
131707
131708
131709
131710
131711
131712
131713
131714
131715
131716
131717
131718
131719
131720
131721
131722
131723
131724
131725
131726
131727
131728
131729
131730
131731
131732
131733
131734
131735
131736
131737
131738
131739
131740
131741
131742
131743
131744
131745
131746
131747
131748
131749
131750
131751
131752
131753
131754
131755
131756
131757
131758
131759
131760
131761
131762
131763
131764
131765
131766
131767
131768
131769
131770
131771
131772
131773
131774
131775
131776
131777
131778
131779
131780
131781
131782
131783
131784
131785
131786
131787
131788
131789
131790
131791
131792
131793
131794
131795
131796
131797
131798
131799
131800
131801
131802
131803
131804
131805
131806
131807
131808
131809
131810
131811
131812
131813
131814
131815
131816
131817
131818
131819
131820
131821
131822
131823
131824
131825
131826
131827
131828
131829
131830
131831
131832
131833
131834
131835
131836
131837
131838
131839
131840
131841
131842
131843
131844
131845
131846
131847
131848
131849
131850
131851
131852
131853
131854
131855
131856
131857
131858
131859
131860
131861
131862
131863
131864
131865
131866
131867
131868
131869
131870
131871
131872
131873
131874
131875
131876
131877
131878
131879
131880
131881
131882
131883
131884
131885
131886
131887
131888
131889
131890
131891
131892
131893
131894
131895
131896
131897
131898
131899
131900
131901
131902
131903
131904
131905
131906
131907
131908
131909
131910
131911
131912
131913
131914
131915
131916
131917
131918
131919
131920
131921
131922
131923
131924
131925
131926
131927
131928
131929
131930
131931
131932
131933
131934
131935
131936
131937
131938
131939
131940
131941
131942
131943
131944
131945
131946
131947
131948
131949
131950
131951
131952
131953
131954
131955
131956
131957
131958
131959
131960
131961
131962
131963
131964
131965
131966
131967
131968
131969
131970
131971
131972
131973
131974
131975
131976
131977
131978
131979
131980
131981
131982
131983
131984
131985
131986
131987
131988
131989
131990
131991
131992
131993
131994
131995
131996
131997
131998
131999
132000
132001
132002
132003
132004
132005
132006
132007
132008
132009
132010
132011
132012
132013
132014
132015
132016
132017
132018
132019
132020
132021
132022
132023
132024
132025
132026
132027
132028
132029
132030
132031
132032
132033
132034
132035
132036
132037
132038
132039
132040
132041
132042
132043
132044
132045
132046
132047
132048
132049
132050
132051
132052
132053
132054
132055
132056
132057
132058
132059
132060
132061
132062
132063
132064
132065
132066
132067
132068
132069
132070
132071
132072
132073
132074
132075
132076
132077
132078
132079
132080
132081
132082
132083
132084
132085
132086
132087
132088
132089
132090
132091
132092
132093
132094
132095
132096
132097
132098
132099
132100
132101
132102
132103
132104
132105
132106
132107
132108
132109
132110
132111
132112
132113
132114
132115
132116
132117
132118
132119
132120
132121
132122
132123
132124
132125
132126
132127
132128
132129
132130
132131
132132
132133
132134
132135
132136
132137
132138
132139
132140
132141
132142
132143
132144
132145
132146
132147
132148
132149
132150
132151
132152
132153
132154
132155
132156
132157
132158
132159
132160
132161
132162
132163
132164
132165
132166
132167
132168
132169
132170
132171
132172
132173
132174
132175
132176
132177
132178
132179
132180
132181
132182
132183
132184
132185
132186
132187
132188
132189
132190
132191
132192
132193
132194
132195
132196
132197
132198
132199
132200
132201
132202
132203
132204
132205
132206
132207
132208
132209
132210
132211
132212
132213
132214
132215
132216
132217
132218
132219
132220
132221
132222
132223
132224
132225
132226
132227
132228
132229
132230
132231
132232
132233
132234
132235
132236
132237
132238
132239
132240
132241
132242
132243
132244
132245
132246
132247
132248
132249
132250
132251
132252
132253
132254
132255
132256
132257
132258
132259
132260
132261
132262
132263
132264
132265
132266
132267
132268
132269
132270
132271
132272
132273
132274
132275
132276
132277
132278
132279
132280
132281
132282
132283
132284
132285
132286
132287
132288
132289
132290
132291
132292
132293
132294
132295
132296
132297
132298
132299
132300
132301
132302
132303
132304
132305
132306
132307
132308
132309
132310
132311
132312
132313
132314
132315
132316
132317
132318
132319
132320
132321
132322
132323
132324
132325
132326
132327
132328
132329
132330
132331
132332
132333
132334
132335
132336
132337
132338
132339
132340
132341
132342
132343
132344
132345
132346
132347
132348
132349
132350
132351
132352
132353
132354
132355
132356
132357
132358
132359
132360
132361
132362
132363
132364
132365
132366
132367
132368
132369
132370
132371
132372
132373
132374
132375
132376
132377
132378
132379
132380
132381
132382
132383
132384
132385
132386
132387
132388
132389
132390
132391
132392
132393
132394
132395
132396
132397
132398
132399
132400
132401
132402
132403
132404
132405
132406
132407
132408
132409
132410
132411
132412
132413
132414
132415
132416
132417
132418
132419
132420
132421
132422
132423
132424
132425
132426
132427
132428
132429
132430
132431
132432
132433
132434
132435
132436
132437
132438
132439
132440
132441
132442
132443
132444
132445
132446
132447
132448
132449
132450
132451
132452
132453
132454
132455
132456
132457
132458
132459
132460
132461
132462
132463
132464
132465
132466
132467
132468
132469
132470
132471
132472
132473
132474
132475
132476
132477
132478
132479
132480
132481
132482
132483
132484
132485
132486
132487
132488
132489
132490
132491
132492
132493
132494
132495
132496
132497
132498
132499
132500
132501
132502
132503
132504
132505
132506
132507
132508
132509
132510
132511
132512
132513
132514
132515
132516
132517
132518
132519
132520
132521
132522
132523
132524
132525
132526
132527
132528
132529
132530
132531
132532
132533
132534
132535
132536
132537
132538
132539
132540
132541
132542
132543
132544
132545
132546
132547
132548
132549
132550
132551
132552
132553
132554
132555
132556
132557
132558
132559
132560
132561
132562
132563
132564
132565
132566
132567
132568
132569
132570
132571
132572
132573
132574
132575
132576
132577
132578
132579
132580
132581
132582
132583
132584
132585
132586
132587
132588
132589
132590
132591
132592
132593
132594
132595
132596
132597
132598
132599
132600
132601
132602
132603
132604
132605
132606
132607
132608
132609
132610
132611
132612
132613
132614
132615
132616
132617
132618
132619
132620
132621
132622
132623
132624
132625
132626
132627
132628
132629
132630
132631
132632
132633
132634
132635
132636
132637
132638
132639
132640
132641
132642
132643
132644
132645
132646
132647
132648
132649
132650
132651
132652
132653
132654
132655
132656
132657
132658
132659
132660
132661
132662
132663
132664
132665
132666
132667
132668
132669
132670
132671
132672
132673
132674
132675
132676
132677
132678
132679
132680
132681
132682
132683
132684
132685
132686
132687
132688
132689
132690
132691
132692
132693
132694
132695
132696
132697
132698
132699
132700
132701
132702
132703
132704
132705
132706
132707
132708
132709
132710
132711
132712
132713
132714
132715
132716
132717
132718
132719
132720
132721
132722
132723
132724
132725
132726
132727
132728
132729
132730
132731
132732
132733
132734
132735
132736
132737
132738
132739
132740
132741
132742
132743
132744
132745
132746
132747
132748
132749
132750
132751
132752
132753
132754
132755
132756
132757
132758
132759
132760
132761
132762
132763
132764
132765
132766
132767
132768
132769
132770
132771
132772
132773
132774
132775
132776
132777
132778
132779
132780
132781
132782
132783
132784
132785
132786
132787
132788
132789
132790
132791
132792
132793
132794
132795
132796
132797
132798
132799
132800
132801
132802
132803
132804
132805
132806
132807
132808
132809
132810
132811
132812
132813
132814
132815
132816
132817
132818
132819
132820
132821
132822
132823
132824
132825
132826
132827
132828
132829
132830
132831
132832
132833
132834
132835
132836
132837
132838
132839
132840
132841
132842
132843
132844
132845
132846
132847
132848
132849
132850
132851
132852
132853
132854
132855
132856
132857
132858
132859
132860
132861
132862
132863
132864
132865
132866
132867
132868
132869
132870
132871
132872
132873
132874
132875
132876
132877
132878
132879
132880
132881
132882
132883
132884
132885
132886
132887
132888
132889
132890
132891
132892
132893
132894
132895
132896
132897
132898
132899
132900
132901
132902
132903
132904
132905
132906
132907
132908
132909
132910
132911
132912
132913
132914
132915
132916
132917
132918
132919
132920
132921
132922
132923
132924
132925
132926
132927
132928
132929
132930
132931
132932
132933
132934
132935
132936
132937
132938
132939
132940
132941
132942
132943
132944
132945
132946
132947
132948
132949
132950
132951
132952
132953
132954
132955
132956
132957
132958
132959
132960
132961
132962
132963
132964
132965
132966
132967
132968
132969
132970
132971
132972
132973
132974
132975
132976
132977
132978
132979
132980
132981
132982
132983
132984
132985
132986
132987
132988
132989
132990
132991
132992
132993
132994
132995
132996
132997
132998
132999
133000
133001
133002
133003
133004
133005
133006
133007
133008
133009
133010
133011
133012
133013
133014
133015
133016
133017
133018
133019
133020
133021
133022
133023
133024
133025
133026
133027
133028
133029
133030
133031
133032
133033
133034
133035
133036
133037
133038
133039
133040
133041
133042
133043
133044
133045
133046
133047
133048
133049
133050
133051
133052
133053
133054
133055
133056
133057
133058
133059
133060
133061
133062
133063
133064
133065
133066
133067
133068
133069
133070
133071
133072
133073
133074
133075
133076
133077
133078
133079
133080
133081
133082
133083
133084
133085
133086
133087
133088
133089
133090
133091
133092
133093
133094
133095
133096
133097
133098
133099
133100
133101
133102
133103
133104
133105
133106
133107
133108
133109
133110
133111
133112
133113
133114
133115
133116
133117
133118
133119
133120
133121
133122
133123
133124
133125
133126
133127
133128
133129
133130
133131
133132
133133
133134
133135
133136
133137
133138
133139
133140
133141
133142
133143
133144
133145
133146
133147
133148
133149
133150
133151
133152
133153
133154
133155
133156
133157
133158
133159
133160
133161
133162
133163
133164
133165
133166
133167
133168
133169
133170
133171
133172
133173
133174
133175
133176
133177
133178
133179
133180
133181
133182
133183
133184
133185
133186
133187
133188
133189
133190
133191
133192
133193
133194
133195
133196
133197
133198
133199
133200
133201
133202
133203
133204
133205
133206
133207
133208
133209
133210
133211
133212
133213
133214
133215
133216
133217
133218
133219
133220
133221
133222
133223
133224
133225
133226
133227
133228
133229
133230
133231
133232
133233
133234
133235
133236
133237
133238
133239
133240
133241
133242
133243
133244
133245
133246
133247
133248
133249
133250
133251
133252
133253
133254
133255
133256
133257
133258
133259
133260
133261
133262
133263
133264
133265
133266
133267
133268
133269
133270
133271
133272
133273
133274
133275
133276
133277
133278
133279
133280
133281
133282
133283
133284
133285
133286
133287
133288
133289
133290
133291
133292
133293
133294
133295
133296
133297
133298
133299
133300
133301
133302
133303
133304
133305
133306
133307
133308
133309
133310
133311
133312
133313
133314
133315
133316
133317
133318
133319
133320
133321
133322
133323
133324
133325
133326
133327
133328
133329
133330
133331
133332
133333
133334
133335
133336
133337
133338
133339
133340
133341
133342
133343
133344
133345
133346
133347
133348
133349
133350
133351
133352
133353
133354
133355
133356
133357
133358
133359
133360
133361
133362
133363
133364
133365
133366
133367
133368
133369
133370
133371
133372
133373
133374
133375
133376
133377
133378
133379
133380
133381
133382
133383
133384
133385
133386
133387
133388
133389
133390
133391
133392
133393
133394
133395
133396
133397
133398
133399
133400
133401
133402
133403
133404
133405
133406
133407
133408
133409
133410
133411
133412
133413
133414
133415
133416
133417
133418
133419
133420
133421
133422
133423
133424
133425
133426
133427
133428
133429
133430
133431
133432
133433
133434
133435
133436
133437
133438
133439
133440
133441
133442
133443
133444
133445
133446
133447
133448
133449
133450
133451
133452
133453
133454
133455
133456
133457
133458
133459
133460
133461
133462
133463
133464
133465
133466
133467
133468
133469
133470
133471
133472
133473
133474
133475
133476
133477
133478
133479
133480
133481
133482
133483
133484
133485
133486
133487
133488
133489
133490
133491
133492
133493
133494
133495
133496
133497
133498
133499
133500
133501
133502
133503
133504
133505
133506
133507
133508
133509
133510
133511
133512
133513
133514
133515
133516
133517
133518
133519
133520
133521
133522
133523
133524
133525
133526
133527
133528
133529
133530
133531
133532
133533
133534
133535
133536
133537
133538
133539
133540
133541
133542
133543
133544
133545
133546
133547
133548
133549
133550
133551
133552
133553
133554
133555
133556
133557
133558
133559
133560
133561
133562
133563
133564
133565
133566
133567
133568
133569
133570
133571
133572
133573
133574
133575
133576
133577
133578
133579
133580
133581
133582
133583
133584
133585
133586
133587
133588
133589
133590
133591
133592
133593
133594
133595
133596
133597
133598
133599
133600
133601
133602
133603
133604
133605
133606
133607
133608
133609
133610
133611
133612
133613
133614
133615
133616
133617
133618
133619
133620
133621
133622
133623
133624
133625
133626
133627
133628
133629
133630
133631
133632
133633
133634
133635
133636
133637
133638
133639
133640
133641
133642
133643
133644
133645
133646
133647
133648
133649
133650
133651
133652
133653
133654
133655
133656
133657
133658
133659
133660
133661
133662
133663
133664
133665
133666
133667
133668
133669
133670
133671
133672
133673
133674
133675
133676
133677
133678
133679
133680
133681
133682
133683
133684
133685
133686
133687
133688
133689
133690
133691
133692
133693
133694
133695
133696
133697
133698
133699
133700
133701
133702
133703
133704
133705
133706
133707
133708
133709
133710
133711
133712
133713
133714
133715
133716
133717
133718
133719
133720
133721
133722
133723
133724
133725
133726
133727
133728
133729
133730
133731
133732
133733
133734
133735
133736
133737
133738
133739
133740
133741
133742
133743
133744
133745
133746
133747
133748
133749
133750
133751
133752
133753
133754
133755
133756
133757
133758
133759
133760
133761
133762
133763
133764
133765
133766
133767
133768
133769
133770
133771
133772
133773
133774
133775
133776
133777
133778
133779
133780
133781
133782
133783
133784
133785
133786
133787
133788
133789
133790
133791
133792
133793
133794
133795
133796
133797
133798
133799
133800
133801
133802
133803
133804
133805
133806
133807
133808
133809
133810
133811
133812
133813
133814
133815
133816
133817
133818
133819
133820
133821
133822
133823
133824
133825
133826
133827
133828
133829
133830
133831
133832
133833
133834
133835
133836
133837
133838
133839
133840
133841
133842
133843
133844
133845
133846
133847
133848
133849
133850
133851
133852
133853
133854
133855
133856
133857
133858
133859
133860
133861
133862
133863
133864
133865
133866
133867
133868
133869
133870
133871
133872
133873
133874
133875
133876
133877
133878
133879
133880
133881
133882
133883
133884
133885
133886
133887
133888
133889
133890
133891
133892
133893
133894
133895
133896
133897
133898
133899
133900
133901
133902
133903
133904
133905
133906
133907
133908
133909
133910
133911
133912
133913
133914
133915
133916
133917
133918
133919
133920
133921
133922
133923
133924
133925
133926
133927
133928
133929
133930
133931
133932
133933
133934
133935
133936
133937
133938
133939
133940
133941
133942
133943
133944
133945
133946
133947
133948
133949
133950
133951
133952
133953
133954
133955
133956
133957
133958
133959
133960
133961
133962
133963
133964
133965
133966
133967
133968
133969
133970
133971
133972
133973
133974
133975
133976
133977
133978
133979
133980
133981
133982
133983
133984
133985
133986
133987
133988
133989
133990
133991
133992
133993
133994
133995
133996
133997
133998
133999
134000
134001
134002
134003
134004
134005
134006
134007
134008
134009
134010
134011
134012
134013
134014
134015
134016
134017
134018
134019
134020
134021
134022
134023
134024
134025
134026
134027
134028
134029
134030
134031
134032
134033
134034
134035
134036
134037
134038
134039
134040
134041
134042
134043
134044
134045
134046
134047
134048
134049
134050
134051
134052
134053
134054
134055
134056
134057
134058
134059
134060
134061
134062
134063
134064
134065
134066
134067
134068
134069
134070
134071
134072
134073
134074
134075
134076
134077
134078
134079
134080
134081
134082
134083
134084
134085
134086
134087
134088
134089
134090
134091
134092
134093
134094
134095
134096
134097
134098
134099
134100
134101
134102
134103
134104
134105
134106
134107
134108
134109
134110
134111
134112
134113
134114
134115
134116
134117
134118
134119
134120
134121
134122
134123
134124
134125
134126
134127
134128
134129
134130
134131
134132
134133
134134
134135
134136
134137
134138
134139
134140
134141
134142
134143
134144
134145
134146
134147
134148
134149
134150
134151
134152
134153
134154
134155
134156
134157
134158
134159
134160
134161
134162
134163
134164
134165
134166
134167
134168
134169
134170
134171
134172
134173
134174
134175
134176
134177
134178
134179
134180
134181
134182
134183
134184
134185
134186
134187
134188
134189
134190
134191
134192
134193
134194
134195
134196
134197
134198
134199
134200
134201
134202
134203
134204
134205
134206
134207
134208
134209
134210
134211
134212
134213
134214
134215
134216
134217
134218
134219
134220
134221
134222
134223
134224
134225
134226
134227
134228
134229
134230
134231
134232
134233
134234
134235
134236
134237
134238
134239
134240
134241
134242
134243
134244
134245
134246
134247
134248
134249
134250
134251
134252
134253
134254
134255
134256
134257
134258
134259
134260
134261
134262
134263
134264
134265
134266
134267
134268
134269
134270
134271
134272
134273
134274
134275
134276
134277
134278
134279
134280
134281
134282
134283
134284
134285
134286
134287
134288
134289
134290
134291
134292
134293
134294
134295
134296
134297
134298
134299
134300
134301
134302
134303
134304
134305
134306
134307
134308
134309
134310
134311
134312
134313
134314
134315
134316
134317
134318
134319
134320
134321
134322
134323
134324
134325
134326
134327
134328
134329
134330
134331
134332
134333
134334
134335
134336
134337
134338
134339
134340
134341
134342
134343
134344
134345
134346
134347
134348
134349
134350
134351
134352
134353
134354
134355
134356
134357
134358
134359
134360
134361
134362
134363
134364
134365
134366
134367
134368
134369
134370
134371
134372
134373
134374
134375
134376
134377
134378
134379
134380
134381
134382
134383
134384
134385
134386
134387
134388
134389
134390
134391
134392
134393
134394
134395
134396
134397
134398
134399
134400
134401
134402
134403
134404
134405
134406
134407
134408
134409
134410
134411
134412
134413
134414
134415
134416
134417
134418
134419
134420
134421
134422
134423
134424
134425
134426
134427
134428
134429
134430
134431
134432
134433
134434
134435
134436
134437
134438
134439
134440
134441
134442
134443
134444
134445
134446
134447
134448
134449
134450
134451
134452
134453
134454
134455
134456
134457
134458
134459
134460
134461
134462
134463
134464
134465
134466
134467
134468
134469
134470
134471
134472
134473
134474
134475
134476
134477
134478
134479
134480
134481
134482
134483
134484
134485
134486
134487
134488
134489
134490
134491
134492
134493
134494
134495
134496
134497
134498
134499
134500
134501
134502
134503
134504
134505
134506
134507
134508
134509
134510
134511
134512
134513
134514
134515
134516
134517
134518
134519
134520
134521
134522
134523
134524
134525
134526
134527
134528
134529
134530
134531
134532
134533
134534
134535
134536
134537
134538
134539
134540
134541
134542
134543
134544
134545
134546
134547
134548
134549
134550
134551
134552
134553
134554
134555
134556
134557
134558
134559
134560
134561
134562
134563
134564
134565
134566
134567
134568
134569
134570
134571
134572
134573
134574
134575
134576
134577
134578
134579
134580
134581
134582
134583
134584
134585
134586
134587
134588
134589
134590
134591
134592
134593
134594
134595
134596
134597
134598
134599
134600
134601
134602
134603
134604
134605
134606
134607
134608
134609
134610
134611
134612
134613
134614
134615
134616
134617
134618
134619
134620
134621
134622
134623
134624
134625
134626
134627
134628
134629
134630
134631
134632
134633
134634
134635
134636
134637
134638
134639
134640
134641
134642
134643
134644
134645
134646
134647
134648
134649
134650
134651
134652
134653
134654
134655
134656
134657
134658
134659
134660
134661
134662
134663
134664
134665
134666
134667
134668
134669
134670
134671
134672
134673
134674
134675
134676
134677
134678
134679
134680
134681
134682
134683
134684
134685
134686
134687
134688
134689
134690
134691
134692
134693
134694
134695
134696
134697
134698
134699
134700
134701
134702
134703
134704
134705
134706
134707
134708
134709
134710
134711
134712
134713
134714
134715
134716
134717
134718
134719
134720
134721
134722
134723
134724
134725
134726
134727
134728
134729
134730
134731
134732
134733
134734
134735
134736
134737
134738
134739
134740
134741
134742
134743
134744
134745
134746
134747
134748
134749
134750
134751
134752
134753
134754
134755
134756
134757
134758
134759
134760
134761
134762
134763
134764
134765
134766
134767
134768
134769
134770
134771
134772
134773
134774
134775
134776
134777
134778
134779
134780
134781
134782
134783
134784
134785
134786
134787
134788
134789
134790
134791
134792
134793
134794
134795
134796
134797
134798
134799
134800
134801
134802
134803
134804
134805
134806
134807
134808
134809
134810
134811
134812
134813
134814
134815
134816
134817
134818
134819
134820
134821
134822
134823
134824
134825
134826
134827
134828
134829
134830
134831
134832
134833
134834
134835
134836
134837
134838
134839
134840
134841
134842
134843
134844
134845
134846
134847
134848
134849
134850
134851
134852
134853
134854
134855
134856
134857
134858
134859
134860
134861
134862
134863
134864
134865
134866
134867
134868
134869
134870
134871
134872
134873
134874
134875
134876
134877
134878
134879
134880
134881
134882
134883
134884
134885
134886
134887
134888
134889
134890
134891
134892
134893
134894
134895
134896
134897
134898
134899
134900
134901
134902
134903
134904
134905
134906
134907
134908
134909
134910
134911
134912
134913
134914
134915
134916
134917
134918
134919
134920
134921
134922
134923
134924
134925
134926
134927
134928
134929
134930
134931
134932
134933
134934
134935
134936
134937
134938
134939
134940
134941
134942
134943
134944
134945
134946
134947
134948
134949
134950
134951
134952
134953
134954
134955
134956
134957
134958
134959
134960
134961
134962
134963
134964
134965
134966
134967
134968
134969
134970
134971
134972
134973
134974
134975
134976
134977
134978
134979
134980
134981
134982
134983
134984
134985
134986
134987
134988
134989
134990
134991
134992
134993
134994
134995
134996
134997
134998
134999
135000
135001
135002
135003
135004
135005
135006
135007
135008
135009
135010
135011
135012
135013
135014
135015
135016
135017
135018
135019
135020
135021
135022
135023
135024
135025
135026
135027
135028
135029
135030
135031
135032
135033
135034
135035
135036
135037
135038
135039
135040
135041
135042
135043
135044
135045
135046
135047
135048
135049
135050
135051
135052
135053
135054
135055
135056
135057
135058
135059
135060
135061
135062
135063
135064
135065
135066
135067
135068
135069
135070
135071
135072
135073
135074
135075
135076
135077
135078
135079
135080
135081
135082
135083
135084
135085
135086
135087
135088
135089
135090
135091
135092
135093
135094
135095
135096
135097
135098
135099
135100
135101
135102
135103
135104
135105
135106
135107
135108
135109
135110
135111
135112
135113
135114
135115
135116
135117
135118
135119
135120
135121
135122
135123
135124
135125
135126
135127
135128
135129
135130
135131
135132
135133
135134
135135
135136
135137
135138
135139
135140
135141
135142
135143
135144
135145
135146
135147
135148
135149
135150
135151
135152
135153
135154
135155
135156
135157
135158
135159
135160
135161
135162
135163
135164
135165
135166
135167
135168
135169
135170
135171
135172
135173
135174
135175
135176
135177
135178
135179
135180
135181
135182
135183
135184
135185
135186
135187
135188
135189
135190
135191
135192
135193
135194
135195
135196
135197
135198
135199
135200
135201
135202
135203
135204
135205
135206
135207
135208
135209
135210
135211
135212
135213
135214
135215
135216
135217
135218
135219
135220
135221
135222
135223
135224
135225
135226
135227
135228
135229
135230
135231
135232
135233
135234
135235
135236
135237
135238
135239
135240
135241
135242
135243
135244
135245
135246
135247
135248
135249
135250
135251
135252
135253
135254
135255
135256
135257
135258
135259
135260
135261
135262
135263
135264
135265
135266
135267
135268
135269
135270
135271
135272
135273
135274
135275
135276
135277
135278
135279
135280
135281
135282
135283
135284
135285
135286
135287
135288
135289
135290
135291
135292
135293
135294
135295
135296
135297
135298
135299
135300
135301
135302
135303
135304
135305
135306
135307
135308
135309
135310
135311
135312
135313
135314
135315
135316
135317
135318
135319
135320
135321
135322
135323
135324
135325
135326
135327
135328
135329
135330
135331
135332
135333
135334
135335
135336
135337
135338
135339
135340
135341
135342
135343
135344
135345
135346
135347
135348
135349
135350
135351
135352
135353
135354
135355
135356
135357
135358
135359
135360
135361
135362
135363
135364
135365
135366
135367
135368
135369
135370
135371
135372
135373
135374
135375
135376
135377
135378
135379
135380
135381
135382
135383
135384
135385
135386
135387
135388
135389
135390
135391
135392
135393
135394
135395
135396
135397
135398
135399
135400
135401
135402
135403
135404
135405
135406
135407
135408
135409
135410
135411
135412
135413
135414
135415
135416
135417
135418
135419
135420
135421
135422
135423
135424
135425
135426
135427
135428
135429
135430
135431
135432
135433
135434
135435
135436
135437
135438
135439
135440
135441
135442
135443
135444
135445
135446
135447
135448
135449
135450
135451
135452
135453
135454
135455
135456
135457
135458
135459
135460
135461
135462
135463
135464
135465
135466
135467
135468
135469
135470
135471
135472
135473
135474
135475
135476
135477
135478
135479
135480
135481
135482
135483
135484
135485
135486
135487
135488
135489
135490
135491
135492
135493
135494
135495
135496
135497
135498
135499
135500
135501
135502
135503
135504
135505
135506
135507
135508
135509
135510
135511
135512
135513
135514
135515
135516
135517
135518
135519
135520
135521
135522
135523
135524
135525
135526
135527
135528
135529
135530
135531
135532
135533
135534
135535
135536
135537
135538
135539
135540
135541
135542
135543
135544
135545
135546
135547
135548
135549
135550
135551
135552
135553
135554
135555
135556
135557
135558
135559
135560
135561
135562
135563
135564
135565
135566
135567
135568
135569
135570
135571
135572
135573
135574
135575
135576
135577
135578
135579
135580
135581
135582
135583
135584
135585
135586
135587
135588
135589
135590
135591
135592
135593
135594
135595
135596
135597
135598
135599
135600
135601
135602
135603
135604
135605
135606
135607
135608
135609
135610
135611
135612
135613
135614
135615
135616
135617
135618
135619
135620
135621
135622
135623
135624
135625
135626
135627
135628
135629
135630
135631
135632
135633
135634
135635
135636
135637
135638
135639
135640
135641
135642
135643
135644
135645
135646
135647
135648
135649
135650
135651
135652
135653
135654
135655
135656
135657
135658
135659
135660
135661
135662
135663
135664
135665
135666
135667
135668
135669
135670
135671
135672
135673
135674
135675
135676
135677
135678
135679
135680
135681
135682
135683
135684
135685
135686
135687
135688
135689
135690
135691
135692
135693
135694
135695
135696
135697
135698
135699
135700
135701
135702
135703
135704
135705
135706
135707
135708
135709
135710
135711
135712
135713
135714
135715
135716
135717
135718
135719
135720
135721
135722
135723
135724
135725
135726
135727
135728
135729
135730
135731
135732
135733
135734
135735
135736
135737
135738
135739
135740
135741
135742
135743
135744
135745
135746
135747
135748
135749
135750
135751
135752
135753
135754
135755
135756
135757
135758
135759
135760
135761
135762
135763
135764
135765
135766
135767
135768
135769
135770
135771
135772
135773
135774
135775
135776
135777
135778
135779
135780
135781
135782
135783
135784
135785
135786
135787
135788
135789
135790
135791
135792
135793
135794
135795
135796
135797
135798
135799
135800
135801
135802
135803
135804
135805
135806
135807
135808
135809
135810
135811
135812
135813
135814
135815
135816
135817
135818
135819
135820
135821
135822
135823
135824
135825
135826
135827
135828
135829
135830
135831
135832
135833
135834
135835
135836
135837
135838
135839
135840
135841
135842
135843
135844
135845
135846
135847
135848
135849
135850
135851
135852
135853
135854
135855
135856
135857
135858
135859
135860
135861
135862
135863
135864
135865
135866
135867
135868
135869
135870
135871
135872
135873
135874
135875
135876
135877
135878
135879
135880
135881
135882
135883
135884
135885
135886
135887
135888
135889
135890
135891
135892
135893
135894
135895
135896
135897
135898
135899
135900
135901
135902
135903
135904
135905
135906
135907
135908
135909
135910
135911
135912
135913
135914
135915
135916
135917
135918
135919
135920
135921
135922
135923
135924
135925
135926
135927
135928
135929
135930
135931
135932
135933
135934
135935
135936
135937
135938
135939
135940
135941
135942
135943
135944
135945
135946
135947
135948
135949
135950
135951
135952
135953
135954
135955
135956
135957
135958
135959
135960
135961
135962
135963
135964
135965
135966
135967
135968
135969
135970
135971
135972
135973
135974
135975
135976
135977
135978
135979
135980
135981
135982
135983
135984
135985
135986
135987
135988
135989
135990
135991
135992
135993
135994
135995
135996
135997
135998
135999
136000
136001
136002
136003
136004
136005
136006
136007
136008
136009
136010
136011
136012
136013
136014
136015
136016
136017
136018
136019
136020
136021
136022
136023
136024
136025
136026
136027
136028
136029
136030
136031
136032
136033
136034
136035
136036
136037
136038
136039
136040
136041
136042
136043
136044
136045
136046
136047
136048
136049
136050
136051
136052
136053
136054
136055
136056
136057
136058
136059
136060
136061
136062
136063
136064
136065
136066
136067
136068
136069
136070
136071
136072
136073
136074
136075
136076
136077
136078
136079
136080
136081
136082
136083
136084
136085
136086
136087
136088
136089
136090
136091
136092
136093
136094
136095
136096
136097
136098
136099
136100
136101
136102
136103
136104
136105
136106
136107
136108
136109
136110
136111
136112
136113
136114
136115
136116
136117
136118
136119
136120
136121
136122
136123
136124
136125
136126
136127
136128
136129
136130
136131
136132
136133
136134
136135
136136
136137
136138
136139
136140
136141
136142
136143
136144
136145
136146
136147
136148
136149
136150
136151
136152
136153
136154
136155
136156
136157
136158
136159
136160
136161
136162
136163
136164
136165
136166
136167
136168
136169
136170
136171
136172
136173
136174
136175
136176
136177
136178
136179
136180
136181
136182
136183
136184
136185
136186
136187
136188
136189
136190
136191
136192
136193
136194
136195
136196
136197
136198
136199
136200
136201
136202
136203
136204
136205
136206
136207
136208
136209
136210
136211
136212
136213
136214
136215
136216
136217
136218
136219
136220
136221
136222
136223
136224
136225
136226
136227
136228
136229
136230
136231
136232
136233
136234
136235
136236
136237
136238
136239
136240
136241
136242
136243
136244
136245
136246
136247
136248
136249
136250
136251
136252
136253
136254
136255
136256
136257
136258
136259
136260
136261
136262
136263
136264
136265
136266
136267
136268
136269
136270
136271
136272
136273
136274
136275
136276
136277
136278
136279
136280
136281
136282
136283
136284
136285
136286
136287
136288
136289
136290
136291
136292
136293
136294
136295
136296
136297
136298
136299
136300
136301
136302
136303
136304
136305
136306
136307
136308
136309
136310
136311
136312
136313
136314
136315
136316
136317
136318
136319
136320
136321
136322
136323
136324
136325
136326
136327
136328
136329
136330
136331
136332
136333
136334
136335
136336
136337
136338
136339
136340
136341
136342
136343
136344
136345
136346
136347
136348
136349
136350
136351
136352
136353
136354
136355
136356
136357
136358
136359
136360
136361
136362
136363
136364
136365
136366
136367
136368
136369
136370
136371
136372
136373
136374
136375
136376
136377
136378
136379
136380
136381
136382
136383
136384
136385
136386
136387
136388
136389
136390
136391
136392
136393
136394
136395
136396
136397
136398
136399
136400
136401
136402
136403
136404
136405
136406
136407
136408
136409
136410
136411
136412
136413
136414
136415
136416
136417
136418
136419
136420
136421
136422
136423
136424
136425
136426
136427
136428
136429
136430
136431
136432
136433
136434
136435
136436
136437
136438
136439
136440
136441
136442
136443
136444
136445
136446
136447
136448
136449
136450
136451
136452
136453
136454
136455
136456
136457
136458
136459
136460
136461
136462
136463
136464
136465
136466
136467
136468
136469
136470
136471
136472
136473
136474
136475
136476
136477
136478
136479
136480
136481
136482
136483
136484
136485
136486
136487
136488
136489
136490
136491
136492
136493
136494
136495
136496
136497
136498
136499
136500
136501
136502
136503
136504
136505
136506
136507
136508
136509
136510
136511
136512
136513
136514
136515
136516
136517
136518
136519
136520
136521
136522
136523
136524
136525
136526
136527
136528
136529
136530
136531
136532
136533
136534
136535
136536
136537
136538
136539
136540
136541
136542
136543
136544
136545
136546
136547
136548
136549
136550
136551
136552
136553
136554
136555
136556
136557
136558
136559
136560
136561
136562
136563
136564
136565
136566
136567
136568
136569
136570
136571
136572
136573
136574
136575
136576
136577
136578
136579
136580
136581
136582
136583
136584
136585
136586
136587
136588
136589
136590
136591
136592
136593
136594
136595
136596
136597
136598
136599
136600
136601
136602
136603
136604
136605
136606
136607
136608
136609
136610
136611
136612
136613
136614
136615
136616
136617
136618
136619
136620
136621
136622
136623
136624
136625
136626
136627
136628
136629
136630
136631
136632
136633
136634
136635
136636
136637
136638
136639
136640
136641
136642
136643
136644
136645
136646
136647
136648
136649
136650
136651
136652
136653
136654
136655
136656
136657
136658
136659
136660
136661
136662
136663
136664
136665
136666
136667
136668
136669
136670
136671
136672
136673
136674
136675
136676
136677
136678
136679
136680
136681
136682
136683
136684
136685
136686
136687
136688
136689
136690
136691
136692
136693
136694
136695
136696
136697
136698
136699
136700
136701
136702
136703
136704
136705
136706
136707
136708
136709
136710
136711
136712
136713
136714
136715
136716
136717
136718
136719
136720
136721
136722
136723
136724
136725
136726
136727
136728
136729
136730
136731
136732
136733
136734
136735
136736
136737
136738
136739
136740
136741
136742
136743
136744
136745
136746
136747
136748
136749
136750
136751
136752
136753
136754
136755
136756
136757
136758
136759
136760
136761
136762
136763
136764
136765
136766
136767
136768
136769
136770
136771
136772
136773
136774
136775
136776
136777
136778
136779
136780
136781
136782
136783
136784
136785
136786
136787
136788
136789
136790
136791
136792
136793
136794
136795
136796
136797
136798
136799
136800
136801
136802
136803
136804
136805
136806
136807
136808
136809
136810
136811
136812
136813
136814
136815
136816
136817
136818
136819
136820
136821
136822
136823
136824
136825
136826
136827
136828
136829
136830
136831
136832
136833
136834
136835
136836
136837
136838
136839
136840
136841
136842
136843
136844
136845
136846
136847
136848
136849
136850
136851
136852
136853
136854
136855
136856
136857
136858
136859
136860
136861
136862
136863
136864
136865
136866
136867
136868
136869
136870
136871
136872
136873
136874
136875
136876
136877
136878
136879
136880
136881
136882
136883
136884
136885
136886
136887
136888
136889
136890
136891
136892
136893
136894
136895
136896
136897
136898
136899
136900
136901
136902
136903
136904
136905
136906
136907
136908
136909
136910
136911
136912
136913
136914
136915
136916
136917
136918
136919
136920
136921
136922
136923
136924
136925
136926
136927
136928
136929
136930
136931
136932
136933
136934
136935
136936
136937
136938
136939
136940
136941
136942
136943
136944
136945
136946
136947
136948
136949
136950
136951
136952
136953
136954
136955
136956
136957
136958
136959
136960
136961
136962
136963
136964
136965
136966
136967
136968
136969
136970
136971
136972
136973
136974
136975
136976
136977
136978
136979
136980
136981
136982
136983
136984
136985
136986
136987
136988
136989
136990
136991
136992
136993
136994
136995
136996
136997
136998
136999
137000
137001
137002
137003
137004
137005
137006
137007
137008
137009
137010
137011
137012
137013
137014
137015
137016
137017
137018
137019
137020
137021
137022
137023
137024
137025
137026
137027
137028
137029
137030
137031
137032
137033
137034
137035
137036
137037
137038
137039
137040
137041
137042
137043
137044
137045
137046
137047
137048
137049
137050
137051
137052
137053
137054
137055
137056
137057
137058
137059
137060
137061
137062
137063
137064
137065
137066
137067
137068
137069
137070
137071
137072
137073
137074
137075
137076
137077
137078
137079
137080
137081
137082
137083
137084
137085
137086
137087
137088
137089
137090
137091
137092
137093
137094
137095
137096
137097
137098
137099
137100
137101
137102
137103
137104
137105
137106
137107
137108
137109
137110
137111
137112
137113
137114
137115
137116
137117
137118
137119
137120
137121
137122
137123
137124
137125
137126
137127
137128
137129
137130
137131
137132
137133
137134
137135
137136
137137
137138
137139
137140
137141
137142
137143
137144
137145
137146
137147
137148
137149
137150
137151
137152
137153
137154
137155
137156
137157
137158
137159
137160
137161
137162
137163
137164
137165
137166
137167
137168
137169
137170
137171
137172
137173
137174
137175
137176
137177
137178
137179
137180
137181
137182
137183
137184
137185
137186
137187
137188
137189
137190
137191
137192
137193
137194
137195
137196
137197
137198
137199
137200
137201
137202
137203
137204
137205
137206
137207
137208
137209
137210
137211
137212
137213
137214
137215
137216
137217
137218
137219
137220
137221
137222
137223
137224
137225
137226
137227
137228
137229
137230
137231
137232
137233
137234
137235
137236
137237
137238
137239
137240
137241
137242
137243
137244
137245
137246
137247
137248
137249
137250
137251
137252
137253
137254
137255
137256
137257
137258
137259
137260
137261
137262
137263
137264
137265
137266
137267
137268
137269
137270
137271
137272
137273
137274
137275
137276
137277
137278
137279
137280
137281
137282
137283
137284
137285
137286
137287
137288
137289
137290
137291
137292
137293
137294
137295
137296
137297
137298
137299
137300
137301
137302
137303
137304
137305
137306
137307
137308
137309
137310
137311
137312
137313
137314
137315
137316
137317
137318
137319
137320
137321
137322
137323
137324
137325
137326
137327
137328
137329
137330
137331
137332
137333
137334
137335
137336
137337
137338
137339
137340
137341
137342
137343
137344
137345
137346
137347
137348
137349
137350
137351
137352
137353
137354
137355
137356
137357
137358
137359
137360
137361
137362
137363
137364
137365
137366
137367
137368
137369
137370
137371
137372
137373
137374
137375
137376
137377
137378
137379
137380
137381
137382
137383
137384
137385
137386
137387
137388
137389
137390
137391
137392
137393
137394
137395
137396
137397
137398
137399
137400
137401
137402
137403
137404
137405
137406
137407
137408
137409
137410
137411
137412
137413
137414
137415
137416
137417
137418
137419
137420
137421
137422
137423
137424
137425
137426
137427
137428
137429
137430
137431
137432
137433
137434
137435
137436
137437
137438
137439
137440
137441
137442
137443
137444
137445
137446
137447
137448
137449
137450
137451
137452
137453
137454
137455
137456
137457
137458
137459
137460
137461
137462
137463
137464
137465
137466
137467
137468
137469
137470
137471
137472
137473
137474
137475
137476
137477
137478
137479
137480
137481
137482
137483
137484
137485
137486
137487
137488
137489
137490
137491
137492
137493
137494
137495
137496
137497
137498
137499
137500
137501
137502
137503
137504
137505
137506
137507
137508
137509
137510
137511
137512
137513
137514
137515
137516
137517
137518
137519
137520
137521
137522
137523
137524
137525
137526
137527
137528
137529
137530
137531
137532
137533
137534
137535
137536
137537
137538
137539
137540
137541
137542
137543
137544
137545
137546
137547
137548
137549
137550
137551
137552
137553
137554
137555
137556
137557
137558
137559
137560
137561
137562
137563
137564
137565
137566
137567
137568
137569
137570
137571
137572
137573
137574
137575
137576
137577
137578
137579
137580
137581
137582
137583
137584
137585
137586
137587
137588
137589
137590
137591
137592
137593
137594
137595
137596
137597
137598
137599
137600
137601
137602
137603
137604
137605
137606
137607
137608
137609
137610
137611
137612
137613
137614
137615
137616
137617
137618
137619
137620
137621
137622
137623
137624
137625
137626
137627
137628
137629
137630
137631
137632
137633
137634
137635
137636
137637
137638
137639
137640
137641
137642
137643
137644
137645
137646
137647
137648
137649
137650
137651
137652
137653
137654
137655
137656
137657
137658
137659
137660
137661
137662
137663
137664
137665
137666
137667
137668
137669
137670
137671
137672
137673
137674
137675
137676
137677
137678
137679
137680
137681
137682
137683
137684
137685
137686
137687
137688
137689
137690
137691
137692
137693
137694
137695
137696
137697
137698
137699
137700
137701
137702
137703
137704
137705
137706
137707
137708
137709
137710
137711
137712
137713
137714
137715
137716
137717
137718
137719
137720
137721
137722
137723
137724
137725
137726
137727
137728
137729
137730
137731
137732
137733
137734
137735
137736
137737
137738
137739
137740
137741
137742
137743
137744
137745
137746
137747
137748
137749
137750
137751
137752
137753
137754
137755
137756
137757
137758
137759
137760
137761
137762
137763
137764
137765
137766
137767
137768
137769
137770
137771
137772
137773
137774
137775
137776
137777
137778
137779
137780
137781
137782
137783
137784
137785
137786
137787
137788
137789
137790
137791
137792
137793
137794
137795
137796
137797
137798
137799
137800
137801
137802
137803
137804
137805
137806
137807
137808
137809
137810
137811
137812
137813
137814
137815
137816
137817
137818
137819
137820
137821
137822
137823
137824
137825
137826
137827
137828
137829
137830
137831
137832
137833
137834
137835
137836
137837
137838
137839
137840
137841
137842
137843
137844
137845
137846
137847
137848
137849
137850
137851
137852
137853
137854
137855
137856
137857
137858
137859
137860
137861
137862
137863
137864
137865
137866
137867
137868
137869
137870
137871
137872
137873
137874
137875
137876
137877
137878
137879
137880
137881
137882
137883
137884
137885
137886
137887
137888
137889
137890
137891
137892
137893
137894
137895
137896
137897
137898
137899
137900
137901
137902
137903
137904
137905
137906
137907
137908
137909
137910
137911
137912
137913
137914
137915
137916
137917
137918
137919
137920
137921
137922
137923
137924
137925
137926
137927
137928
137929
137930
137931
137932
137933
137934
137935
137936
137937
137938
137939
137940
137941
137942
137943
137944
137945
137946
137947
137948
137949
137950
137951
137952
137953
137954
137955
137956
137957
137958
137959
137960
137961
137962
137963
137964
137965
137966
137967
137968
137969
137970
137971
137972
137973
137974
137975
137976
137977
137978
137979
137980
137981
137982
137983
137984
137985
137986
137987
137988
137989
137990
137991
137992
137993
137994
137995
137996
137997
137998
137999
138000
138001
138002
138003
138004
138005
138006
138007
138008
138009
138010
138011
138012
138013
138014
138015
138016
138017
138018
138019
138020
138021
138022
138023
138024
138025
138026
138027
138028
138029
138030
138031
138032
138033
138034
138035
138036
138037
138038
138039
138040
138041
138042
138043
138044
138045
138046
138047
138048
138049
138050
138051
138052
138053
138054
138055
138056
138057
138058
138059
138060
138061
138062
138063
138064
138065
138066
138067
138068
138069
138070
138071
138072
138073
138074
138075
138076
138077
138078
138079
138080
138081
138082
138083
138084
138085
138086
138087
138088
138089
138090
138091
138092
138093
138094
138095
138096
138097
138098
138099
138100
138101
138102
138103
138104
138105
138106
138107
138108
138109
138110
138111
138112
138113
138114
138115
138116
138117
138118
138119
138120
138121
138122
138123
138124
138125
138126
138127
138128
138129
138130
138131
138132
138133
138134
138135
138136
138137
138138
138139
138140
138141
138142
138143
138144
138145
138146
138147
138148
138149
138150
138151
138152
138153
138154
138155
138156
138157
138158
138159
138160
138161
138162
138163
138164
138165
138166
138167
138168
138169
138170
138171
138172
138173
138174
138175
138176
138177
138178
138179
138180
138181
138182
138183
138184
138185
138186
138187
138188
138189
138190
138191
138192
138193
138194
138195
138196
138197
138198
138199
138200
138201
138202
138203
138204
138205
138206
138207
138208
138209
138210
138211
138212
138213
138214
138215
138216
138217
138218
138219
138220
138221
138222
138223
138224
138225
138226
138227
138228
138229
138230
138231
138232
138233
138234
138235
138236
138237
138238
138239
138240
138241
138242
138243
138244
138245
138246
138247
138248
138249
138250
138251
138252
138253
138254
138255
138256
138257
138258
138259
138260
138261
138262
138263
138264
138265
138266
138267
138268
138269
138270
138271
138272
138273
138274
138275
138276
138277
138278
138279
138280
138281
138282
138283
138284
138285
138286
138287
138288
138289
138290
138291
138292
138293
138294
138295
138296
138297
138298
138299
138300
138301
138302
138303
138304
138305
138306
138307
138308
138309
138310
138311
138312
138313
138314
138315
138316
138317
138318
138319
138320
138321
138322
138323
138324
138325
138326
138327
138328
138329
138330
138331
138332
138333
138334
138335
138336
138337
138338
138339
138340
138341
138342
138343
138344
138345
138346
138347
138348
138349
138350
138351
138352
138353
138354
138355
138356
138357
138358
138359
138360
138361
138362
138363
138364
138365
138366
138367
138368
138369
138370
138371
138372
138373
138374
138375
138376
138377
138378
138379
138380
138381
138382
138383
138384
138385
138386
138387
138388
138389
138390
138391
138392
138393
138394
138395
138396
138397
138398
138399
138400
138401
138402
138403
138404
138405
138406
138407
138408
138409
138410
138411
138412
138413
138414
138415
138416
138417
138418
138419
138420
138421
138422
138423
138424
138425
138426
138427
138428
138429
138430
138431
138432
138433
138434
138435
138436
138437
138438
138439
138440
138441
138442
138443
138444
138445
138446
138447
138448
138449
138450
138451
138452
138453
138454
138455
138456
138457
138458
138459
138460
138461
138462
138463
138464
138465
138466
138467
138468
138469
138470
138471
138472
138473
138474
138475
138476
138477
138478
138479
138480
138481
138482
138483
138484
138485
138486
138487
138488
138489
138490
138491
138492
138493
138494
138495
138496
138497
138498
138499
138500
138501
138502
138503
138504
138505
138506
138507
138508
138509
138510
138511
138512
138513
138514
138515
138516
138517
138518
138519
138520
138521
138522
138523
138524
138525
138526
138527
138528
138529
138530
138531
138532
138533
138534
138535
138536
138537
138538
138539
138540
138541
138542
138543
138544
138545
138546
138547
138548
138549
138550
138551
138552
138553
138554
138555
138556
138557
138558
138559
138560
138561
138562
138563
138564
138565
138566
138567
138568
138569
138570
138571
138572
138573
138574
138575
138576
138577
138578
138579
138580
138581
138582
138583
138584
138585
138586
138587
138588
138589
138590
138591
138592
138593
138594
138595
138596
138597
138598
138599
138600
138601
138602
138603
138604
138605
138606
138607
138608
138609
138610
138611
138612
138613
138614
138615
138616
138617
138618
138619
138620
138621
138622
138623
138624
138625
138626
138627
138628
138629
138630
138631
138632
138633
138634
138635
138636
138637
138638
138639
138640
138641
138642
138643
138644
138645
138646
138647
138648
138649
138650
138651
138652
138653
138654
138655
138656
138657
138658
138659
138660
138661
138662
138663
138664
138665
138666
138667
138668
138669
138670
138671
138672
138673
138674
138675
138676
138677
138678
138679
138680
138681
138682
138683
138684
138685
138686
138687
138688
138689
138690
138691
138692
138693
138694
138695
138696
138697
138698
138699
138700
138701
138702
138703
138704
138705
138706
138707
138708
138709
138710
138711
138712
138713
138714
138715
138716
138717
138718
138719
138720
138721
138722
138723
138724
138725
138726
138727
138728
138729
138730
138731
138732
138733
138734
138735
138736
138737
138738
138739
138740
138741
138742
138743
138744
138745
138746
138747
138748
138749
138750
138751
138752
138753
138754
138755
138756
138757
138758
138759
138760
138761
138762
138763
138764
138765
138766
138767
138768
138769
138770
138771
138772
138773
138774
138775
138776
138777
138778
138779
138780
138781
138782
138783
138784
138785
138786
138787
138788
138789
138790
138791
138792
138793
138794
138795
138796
138797
138798
138799
138800
138801
138802
138803
138804
138805
138806
138807
138808
138809
138810
138811
138812
138813
138814
138815
138816
138817
138818
138819
138820
138821
138822
138823
138824
138825
138826
138827
138828
138829
138830
138831
138832
138833
138834
138835
138836
138837
138838
138839
138840
138841
138842
138843
138844
138845
138846
138847
138848
138849
138850
138851
138852
138853
138854
138855
138856
138857
138858
138859
138860
138861
138862
138863
138864
138865
138866
138867
138868
138869
138870
138871
138872
138873
138874
138875
138876
138877
138878
138879
138880
138881
138882
138883
138884
138885
138886
138887
138888
138889
138890
138891
138892
138893
138894
138895
138896
138897
138898
138899
138900
138901
138902
138903
138904
138905
138906
138907
138908
138909
138910
138911
138912
138913
138914
138915
138916
138917
138918
138919
138920
138921
138922
138923
138924
138925
138926
138927
138928
138929
138930
138931
138932
138933
138934
138935
138936
138937
138938
138939
138940
138941
138942
138943
138944
138945
138946
138947
138948
138949
138950
138951
138952
138953
138954
138955
138956
138957
138958
138959
138960
138961
138962
138963
138964
138965
138966
138967
138968
138969
138970
138971
138972
138973
138974
138975
138976
138977
138978
138979
138980
138981
138982
138983
138984
138985
138986
138987
138988
138989
138990
138991
138992
138993
138994
138995
138996
138997
138998
138999
139000
139001
139002
139003
139004
139005
139006
139007
139008
139009
139010
139011
139012
139013
139014
139015
139016
139017
139018
139019
139020
139021
139022
139023
139024
139025
139026
139027
139028
139029
139030
139031
139032
139033
139034
139035
139036
139037
139038
139039
139040
139041
139042
139043
139044
139045
139046
139047
139048
139049
139050
139051
139052
139053
139054
139055
139056
139057
139058
139059
139060
139061
139062
139063
139064
139065
139066
139067
139068
139069
139070
139071
139072
139073
139074
139075
139076
139077
139078
139079
139080
139081
139082
139083
139084
139085
139086
139087
139088
139089
139090
139091
139092
139093
139094
139095
139096
139097
139098
139099
139100
139101
139102
139103
139104
139105
139106
139107
139108
139109
139110
139111
139112
139113
139114
139115
139116
139117
139118
139119
139120
139121
139122
139123
139124
139125
139126
139127
139128
139129
139130
139131
139132
139133
139134
139135
139136
139137
139138
139139
139140
139141
139142
139143
139144
139145
139146
139147
139148
139149
139150
139151
139152
139153
139154
139155
139156
139157
139158
139159
139160
139161
139162
139163
139164
139165
139166
139167
139168
139169
139170
139171
139172
139173
139174
139175
139176
139177
139178
139179
139180
139181
139182
139183
139184
139185
139186
139187
139188
139189
139190
139191
139192
139193
139194
139195
139196
139197
139198
139199
139200
139201
139202
139203
139204
139205
139206
139207
139208
139209
139210
139211
139212
139213
139214
139215
139216
139217
139218
139219
139220
139221
139222
139223
139224
139225
139226
139227
139228
139229
139230
139231
139232
139233
139234
139235
139236
139237
139238
139239
139240
139241
139242
139243
139244
139245
139246
139247
139248
139249
139250
139251
139252
139253
139254
139255
139256
139257
139258
139259
139260
139261
139262
139263
139264
139265
139266
139267
139268
139269
139270
139271
139272
139273
139274
139275
139276
139277
139278
139279
139280
139281
139282
139283
139284
139285
139286
139287
139288
139289
139290
139291
139292
139293
139294
139295
139296
139297
139298
139299
139300
139301
139302
139303
139304
139305
139306
139307
139308
139309
139310
139311
139312
139313
139314
139315
139316
139317
139318
139319
139320
139321
139322
139323
139324
139325
139326
139327
139328
139329
139330
139331
139332
139333
139334
139335
139336
139337
139338
139339
139340
139341
139342
139343
139344
139345
139346
139347
139348
139349
139350
139351
139352
139353
139354
139355
139356
139357
139358
139359
139360
139361
139362
139363
139364
139365
139366
139367
139368
139369
139370
139371
139372
139373
139374
139375
139376
139377
139378
139379
139380
139381
139382
139383
139384
139385
139386
139387
139388
139389
139390
139391
139392
139393
139394
139395
139396
139397
139398
139399
139400
139401
139402
139403
139404
139405
139406
139407
139408
139409
139410
139411
139412
139413
139414
139415
139416
139417
139418
139419
139420
139421
139422
139423
139424
139425
139426
139427
139428
139429
139430
139431
139432
139433
139434
139435
139436
139437
139438
139439
139440
139441
139442
139443
139444
139445
139446
139447
139448
139449
139450
139451
139452
139453
139454
139455
139456
139457
139458
139459
139460
139461
139462
139463
139464
139465
139466
139467
139468
139469
139470
139471
139472
139473
139474
139475
139476
139477
139478
139479
139480
139481
139482
139483
139484
139485
139486
139487
139488
139489
139490
139491
139492
139493
139494
139495
139496
139497
139498
139499
139500
139501
139502
139503
139504
139505
139506
139507
139508
139509
139510
139511
139512
139513
139514
139515
139516
139517
139518
139519
139520
139521
139522
139523
139524
139525
139526
139527
139528
139529
139530
139531
139532
139533
139534
139535
139536
139537
139538
139539
139540
139541
139542
139543
139544
139545
139546
139547
139548
139549
139550
139551
139552
139553
139554
139555
139556
139557
139558
139559
139560
139561
139562
139563
139564
139565
139566
139567
139568
139569
139570
139571
139572
139573
139574
139575
139576
139577
139578
139579
139580
139581
139582
139583
139584
139585
139586
139587
139588
139589
139590
139591
139592
139593
139594
139595
139596
139597
139598
139599
139600
139601
139602
139603
139604
139605
139606
139607
139608
139609
139610
139611
139612
139613
139614
139615
139616
139617
139618
139619
139620
139621
139622
139623
139624
139625
139626
139627
139628
139629
139630
139631
139632
139633
139634
139635
139636
139637
139638
139639
139640
139641
139642
139643
139644
139645
139646
139647
139648
139649
139650
139651
139652
139653
139654
139655
139656
139657
139658
139659
139660
139661
139662
139663
139664
139665
139666
139667
139668
139669
139670
139671
139672
139673
139674
139675
139676
139677
139678
139679
139680
139681
139682
139683
139684
139685
139686
139687
139688
139689
139690
139691
139692
139693
139694
139695
139696
139697
139698
139699
139700
139701
139702
139703
139704
139705
139706
139707
139708
139709
139710
139711
139712
139713
139714
139715
139716
139717
139718
139719
139720
139721
139722
139723
139724
139725
139726
139727
139728
139729
139730
139731
139732
139733
139734
139735
139736
139737
139738
139739
139740
139741
139742
139743
139744
139745
139746
139747
139748
139749
139750
139751
139752
139753
139754
139755
139756
139757
139758
139759
139760
139761
139762
139763
139764
139765
139766
139767
139768
139769
139770
139771
139772
139773
139774
139775
139776
139777
139778
139779
139780
139781
139782
139783
139784
139785
139786
139787
139788
139789
139790
139791
139792
139793
139794
139795
139796
139797
139798
139799
139800
139801
139802
139803
139804
139805
139806
139807
139808
139809
139810
139811
139812
139813
139814
139815
139816
139817
139818
139819
139820
139821
139822
139823
139824
139825
139826
139827
139828
139829
139830
139831
139832
139833
139834
139835
139836
139837
139838
139839
139840
139841
139842
139843
139844
139845
139846
139847
139848
139849
139850
139851
139852
139853
139854
139855
139856
139857
139858
139859
139860
139861
139862
139863
139864
139865
139866
139867
139868
139869
139870
139871
139872
139873
139874
139875
139876
139877
139878
139879
139880
139881
139882
139883
139884
139885
139886
139887
139888
139889
139890
139891
139892
139893
139894
139895
139896
139897
139898
139899
139900
139901
139902
139903
139904
139905
139906
139907
139908
139909
139910
139911
139912
139913
139914
139915
139916
139917
139918
139919
139920
139921
139922
139923
139924
139925
139926
139927
139928
139929
139930
139931
139932
139933
139934
139935
139936
139937
139938
139939
139940
139941
139942
139943
139944
139945
139946
139947
139948
139949
139950
139951
139952
139953
139954
139955
139956
139957
139958
139959
139960
139961
139962
139963
139964
139965
139966
139967
139968
139969
139970
139971
139972
139973
139974
139975
139976
139977
139978
139979
139980
139981
139982
139983
139984
139985
139986
139987
139988
139989
139990
139991
139992
139993
139994
139995
139996
139997
139998
139999
140000
140001
140002
140003
140004
140005
140006
140007
140008
140009
140010
140011
140012
140013
140014
140015
140016
140017
140018
140019
140020
140021
140022
140023
140024
140025
140026
140027
140028
140029
140030
140031
140032
140033
140034
140035
140036
140037
140038
140039
140040
140041
140042
140043
140044
140045
140046
140047
140048
140049
140050
140051
140052
140053
140054
140055
140056
140057
140058
140059
140060
140061
140062
140063
140064
140065
140066
140067
140068
140069
140070
140071
140072
140073
140074
140075
140076
140077
140078
140079
140080
140081
140082
140083
140084
140085
140086
140087
140088
140089
140090
140091
140092
140093
140094
140095
140096
140097
140098
140099
140100
140101
140102
140103
140104
140105
140106
140107
140108
140109
140110
140111
140112
140113
140114
140115
140116
140117
140118
140119
140120
140121
140122
140123
140124
140125
140126
140127
140128
140129
140130
140131
140132
140133
140134
140135
140136
140137
140138
140139
140140
140141
140142
140143
140144
140145
140146
140147
140148
140149
140150
140151
140152
140153
140154
140155
140156
140157
140158
140159
140160
140161
140162
140163
140164
140165
140166
140167
140168
140169
140170
140171
140172
140173
140174
140175
140176
140177
140178
140179
140180
140181
140182
140183
140184
140185
140186
140187
140188
140189
140190
140191
140192
140193
140194
140195
140196
140197
140198
140199
140200
140201
140202
140203
140204
140205
140206
140207
140208
140209
140210
140211
140212
140213
140214
140215
140216
140217
140218
140219
140220
140221
140222
140223
140224
140225
140226
140227
140228
140229
140230
140231
140232
140233
140234
140235
140236
140237
140238
140239
140240
140241
140242
140243
140244
140245
140246
140247
140248
140249
140250
140251
140252
140253
140254
140255
140256
140257
140258
140259
140260
140261
140262
140263
140264
140265
140266
140267
140268
140269
140270
140271
140272
140273
140274
140275
140276
140277
140278
140279
140280
140281
140282
140283
140284
140285
140286
140287
140288
140289
140290
140291
140292
140293
140294
140295
140296
140297
140298
140299
140300
140301
140302
140303
140304
140305
140306
140307
140308
140309
140310
140311
140312
140313
140314
140315
140316
140317
140318
140319
140320
140321
140322
140323
140324
140325
140326
140327
140328
140329
140330
140331
140332
140333
140334
140335
140336
140337
140338
140339
140340
140341
140342
140343
140344
140345
140346
140347
140348
140349
140350
140351
140352
140353
140354
140355
140356
140357
140358
140359
140360
140361
140362
140363
140364
140365
140366
140367
140368
140369
140370
140371
140372
140373
140374
140375
140376
140377
140378
140379
140380
140381
140382
140383
140384
140385
140386
140387
140388
140389
140390
140391
140392
140393
140394
140395
140396
140397
140398
140399
140400
140401
140402
140403
140404
140405
140406
140407
140408
140409
140410
140411
140412
140413
140414
140415
140416
140417
140418
140419
140420
140421
140422
140423
140424
140425
140426
140427
140428
140429
140430
140431
140432
140433
140434
140435
140436
140437
140438
140439
140440
140441
140442
140443
140444
140445
140446
140447
140448
140449
140450
140451
140452
140453
140454
140455
140456
140457
140458
140459
140460
140461
140462
140463
140464
140465
140466
140467
140468
140469
140470
140471
140472
140473
140474
140475
140476
140477
140478
140479
140480
140481
140482
140483
140484
140485
140486
140487
140488
140489
140490
140491
140492
140493
140494
140495
140496
140497
140498
140499
140500
140501
140502
140503
140504
140505
140506
140507
140508
140509
140510
140511
140512
140513
140514
140515
140516
140517
140518
140519
140520
140521
140522
140523
140524
140525
140526
140527
140528
140529
140530
140531
140532
140533
140534
140535
140536
140537
140538
140539
140540
140541
140542
140543
140544
140545
140546
140547
140548
140549
140550
140551
140552
140553
140554
140555
140556
140557
140558
140559
140560
140561
140562
140563
140564
140565
140566
140567
140568
140569
140570
140571
140572
140573
140574
140575
140576
140577
140578
140579
140580
140581
140582
140583
140584
140585
140586
140587
140588
140589
140590
140591
140592
140593
140594
140595
140596
140597
140598
140599
140600
140601
140602
140603
140604
140605
140606
140607
140608
140609
140610
140611
140612
140613
140614
140615
140616
140617
140618
140619
140620
140621
140622
140623
140624
140625
140626
140627
140628
140629
140630
140631
140632
140633
140634
140635
140636
140637
140638
140639
140640
140641
140642
140643
140644
140645
140646
140647
140648
140649
140650
140651
140652
140653
140654
140655
140656
140657
140658
140659
140660
140661
140662
140663
140664
140665
140666
140667
140668
140669
140670
140671
140672
140673
140674
140675
140676
140677
140678
140679
140680
140681
140682
140683
140684
140685
140686
140687
140688
140689
140690
140691
140692
140693
140694
140695
140696
140697
140698
140699
140700
140701
140702
140703
140704
140705
140706
140707
140708
140709
140710
140711
140712
140713
140714
140715
140716
140717
140718
140719
140720
140721
140722
140723
140724
140725
140726
140727
140728
140729
140730
140731
140732
140733
140734
140735
140736
140737
140738
140739
140740
140741
140742
140743
140744
140745
140746
140747
140748
140749
140750
140751
140752
140753
140754
140755
140756
140757
140758
140759
140760
140761
140762
140763
140764
140765
140766
140767
140768
140769
140770
140771
140772
140773
140774
140775
140776
140777
140778
140779
140780
140781
140782
140783
140784
140785
140786
140787
140788
140789
140790
140791
140792
140793
140794
140795
140796
140797
140798
140799
140800
140801
140802
140803
140804
140805
140806
140807
140808
140809
140810
140811
140812
140813
140814
140815
140816
140817
140818
140819
140820
140821
140822
140823
140824
140825
140826
140827
140828
140829
140830
140831
140832
140833
140834
140835
140836
140837
140838
140839
140840
140841
140842
140843
140844
140845
140846
140847
140848
140849
140850
140851
140852
140853
140854
140855
140856
140857
140858
140859
140860
140861
140862
140863
140864
140865
140866
140867
140868
140869
140870
140871
140872
140873
140874
140875
140876
140877
140878
140879
140880
140881
140882
140883
140884
140885
140886
140887
140888
140889
140890
140891
140892
140893
140894
140895
140896
140897
140898
140899
140900
140901
140902
140903
140904
140905
140906
140907
140908
140909
140910
140911
140912
140913
140914
140915
140916
140917
140918
140919
140920
140921
140922
140923
140924
140925
140926
140927
140928
140929
140930
140931
140932
140933
140934
140935
140936
140937
140938
140939
140940
140941
140942
140943
140944
140945
140946
140947
140948
140949
140950
140951
140952
140953
140954
140955
140956
140957
140958
140959
140960
140961
140962
140963
140964
140965
140966
140967
140968
140969
140970
140971
140972
140973
140974
140975
140976
140977
140978
140979
140980
140981
140982
140983
140984
140985
140986
140987
140988
140989
140990
140991
140992
140993
140994
140995
140996
140997
140998
140999
141000
141001
141002
141003
141004
141005
141006
141007
141008
141009
141010
141011
141012
141013
141014
141015
141016
141017
141018
141019
141020
141021
141022
141023
141024
141025
141026
141027
141028
141029
141030
141031
141032
141033
141034
141035
141036
141037
141038
141039
141040
141041
141042
141043
141044
141045
141046
141047
141048
141049
141050
141051
141052
141053
141054
141055
141056
141057
141058
141059
141060
141061
141062
141063
141064
141065
141066
141067
141068
141069
141070
141071
141072
141073
141074
141075
141076
141077
141078
141079
141080
141081
141082
141083
141084
141085
141086
141087
141088
141089
141090
141091
141092
141093
141094
141095
141096
141097
141098
141099
141100
141101
141102
141103
141104
141105
141106
141107
141108
141109
141110
141111
141112
141113
141114
141115
141116
141117
141118
141119
141120
141121
141122
141123
141124
141125
141126
141127
141128
141129
141130
141131
141132
141133
141134
141135
141136
141137
141138
141139
141140
141141
141142
141143
141144
141145
141146
141147
141148
141149
141150
141151
141152
141153
141154
141155
141156
141157
141158
141159
141160
141161
141162
141163
141164
141165
141166
141167
141168
141169
141170
141171
141172
141173
141174
141175
141176
141177
141178
141179
141180
141181
141182
141183
141184
141185
141186
141187
141188
141189
141190
141191
141192
141193
141194
141195
141196
141197
141198
141199
141200
141201
141202
141203
141204
141205
141206
141207
141208
141209
141210
141211
141212
141213
141214
141215
141216
141217
141218
141219
141220
141221
141222
141223
141224
141225
141226
141227
141228
141229
141230
141231
141232
141233
141234
141235
141236
141237
141238
141239
141240
141241
141242
141243
141244
141245
141246
141247
141248
141249
141250
141251
141252
141253
141254
141255
141256
141257
141258
141259
141260
141261
141262
141263
141264
141265
141266
141267
141268
141269
141270
141271
141272
141273
141274
141275
141276
141277
141278
141279
141280
141281
141282
141283
141284
141285
141286
141287
141288
141289
141290
141291
141292
141293
141294
141295
141296
141297
141298
141299
141300
141301
141302
141303
141304
141305
141306
141307
141308
141309
141310
141311
141312
141313
141314
141315
141316
141317
141318
141319
141320
141321
141322
141323
141324
141325
141326
141327
141328
141329
141330
141331
141332
141333
141334
141335
141336
141337
141338
141339
141340
141341
141342
141343
141344
141345
141346
141347
141348
141349
141350
141351
141352
141353
141354
141355
141356
141357
141358
141359
141360
141361
141362
141363
141364
141365
141366
141367
141368
141369
141370
141371
141372
141373
141374
141375
141376
141377
141378
141379
141380
141381
141382
141383
141384
141385
141386
141387
141388
141389
141390
141391
141392
141393
141394
141395
141396
141397
141398
141399
141400
141401
141402
141403
141404
141405
141406
141407
141408
141409
141410
141411
141412
141413
141414
141415
141416
141417
141418
141419
141420
141421
141422
141423
141424
141425
141426
141427
141428
141429
141430
141431
141432
141433
141434
141435
141436
141437
141438
141439
141440
141441
141442
141443
141444
141445
141446
141447
141448
141449
141450
141451
141452
141453
141454
141455
141456
141457
141458
141459
141460
141461
141462
141463
141464
141465
141466
141467
141468
141469
141470
141471
141472
141473
141474
141475
141476
141477
141478
141479
141480
141481
141482
141483
141484
141485
141486
141487
141488
141489
141490
141491
141492
141493
141494
141495
141496
141497
141498
141499
141500
141501
141502
141503
141504
141505
141506
141507
141508
141509
141510
141511
141512
141513
141514
141515
141516
141517
141518
141519
141520
141521
141522
141523
141524
141525
141526
141527
141528
141529
141530
141531
141532
141533
141534
141535
141536
141537
141538
141539
141540
141541
141542
141543
141544
141545
141546
141547
141548
141549
141550
141551
141552
141553
141554
141555
141556
141557
141558
141559
141560
141561
141562
141563
141564
141565
141566
141567
141568
141569
141570
141571
141572
141573
141574
141575
141576
141577
141578
141579
141580
141581
141582
141583
141584
141585
141586
141587
141588
141589
141590
141591
141592
141593
141594
141595
141596
141597
141598
141599
141600
141601
141602
141603
141604
141605
141606
141607
141608
141609
141610
141611
141612
141613
141614
141615
141616
141617
141618
141619
141620
141621
141622
141623
141624
141625
141626
141627
141628
141629
141630
141631
141632
141633
141634
141635
141636
141637
141638
141639
141640
141641
141642
141643
141644
141645
141646
141647
141648
141649
141650
141651
141652
141653
141654
141655
141656
141657
141658
141659
141660
141661
141662
141663
141664
141665
141666
141667
141668
141669
141670
141671
141672
141673
141674
141675
141676
141677
141678
141679
141680
141681
141682
141683
141684
141685
141686
141687
141688
141689
141690
141691
141692
141693
141694
141695
141696
141697
141698
141699
141700
141701
141702
141703
141704
141705
141706
141707
141708
141709
141710
141711
141712
141713
141714
141715
141716
141717
141718
141719
141720
141721
141722
141723
141724
141725
141726
141727
141728
141729
141730
141731
141732
141733
141734
141735
141736
141737
141738
141739
141740
141741
141742
141743
141744
141745
141746
141747
141748
141749
141750
141751
141752
141753
141754
141755
141756
141757
141758
141759
141760
141761
141762
141763
141764
141765
141766
141767
141768
141769
141770
141771
141772
141773
141774
141775
141776
141777
141778
141779
141780
141781
141782
141783
141784
141785
141786
141787
141788
141789
141790
141791
141792
141793
141794
141795
141796
141797
141798
141799
141800
141801
141802
141803
141804
141805
141806
141807
141808
141809
141810
141811
141812
141813
141814
141815
141816
141817
141818
141819
141820
141821
141822
141823
141824
141825
141826
141827
141828
141829
141830
141831
141832
141833
141834
141835
141836
141837
141838
141839
141840
141841
141842
141843
141844
141845
141846
141847
141848
141849
141850
141851
141852
141853
141854
141855
141856
141857
141858
141859
141860
141861
141862
141863
141864
141865
141866
141867
141868
141869
141870
141871
141872
141873
141874
141875
141876
141877
141878
141879
141880
141881
141882
141883
141884
141885
141886
141887
141888
141889
141890
141891
141892
141893
141894
141895
141896
141897
141898
141899
141900
141901
141902
141903
141904
141905
141906
141907
141908
141909
141910
141911
141912
141913
141914
141915
141916
141917
141918
141919
141920
141921
141922
141923
141924
141925
141926
141927
141928
141929
141930
141931
141932
141933
141934
141935
141936
141937
141938
141939
141940
141941
141942
141943
141944
141945
141946
141947
141948
141949
141950
141951
141952
141953
141954
141955
141956
141957
141958
141959
141960
141961
141962
141963
141964
141965
141966
141967
141968
141969
141970
141971
141972
141973
141974
141975
141976
141977
141978
141979
141980
141981
141982
141983
141984
141985
141986
141987
141988
141989
141990
141991
141992
141993
141994
141995
141996
141997
141998
141999
142000
142001
142002
142003
142004
142005
142006
142007
142008
142009
142010
142011
142012
142013
142014
142015
142016
142017
142018
142019
142020
142021
142022
142023
142024
142025
142026
142027
142028
142029
142030
142031
142032
142033
142034
142035
142036
142037
142038
142039
142040
142041
142042
142043
142044
142045
142046
142047
142048
142049
142050
142051
142052
142053
142054
142055
142056
142057
142058
142059
142060
142061
142062
142063
142064
142065
142066
142067
142068
142069
142070
142071
142072
142073
142074
142075
142076
142077
142078
142079
142080
142081
142082
142083
142084
142085
142086
142087
142088
142089
142090
142091
142092
142093
142094
142095
142096
142097
142098
142099
142100
142101
142102
142103
142104
142105
142106
142107
142108
142109
142110
142111
142112
142113
142114
142115
142116
142117
142118
142119
142120
142121
142122
142123
142124
142125
142126
142127
142128
142129
142130
142131
142132
142133
142134
142135
142136
142137
142138
142139
142140
142141
142142
142143
142144
142145
142146
142147
142148
142149
142150
142151
142152
142153
142154
142155
142156
142157
142158
142159
142160
142161
142162
142163
142164
142165
142166
142167
142168
142169
142170
142171
142172
142173
142174
142175
142176
142177
142178
142179
142180
142181
142182
142183
142184
142185
142186
142187
142188
142189
142190
142191
142192
142193
142194
142195
142196
142197
142198
142199
142200
142201
142202
142203
142204
142205
142206
142207
142208
142209
142210
142211
142212
142213
142214
142215
142216
142217
142218
142219
142220
142221
142222
142223
142224
142225
142226
142227
142228
142229
142230
142231
142232
142233
142234
142235
142236
142237
142238
142239
142240
142241
142242
142243
142244
142245
142246
142247
142248
142249
142250
142251
142252
142253
142254
142255
142256
142257
142258
142259
142260
142261
142262
142263
142264
142265
142266
142267
142268
142269
142270
142271
142272
142273
142274
142275
142276
142277
142278
142279
142280
142281
142282
142283
142284
142285
142286
142287
142288
142289
142290
142291
142292
142293
142294
142295
142296
142297
142298
142299
142300
142301
142302
142303
142304
142305
142306
142307
142308
142309
142310
142311
142312
142313
142314
142315
142316
142317
142318
142319
142320
142321
142322
142323
142324
142325
142326
142327
142328
142329
142330
142331
142332
142333
142334
142335
142336
142337
142338
142339
142340
142341
142342
142343
142344
142345
142346
142347
142348
142349
142350
142351
142352
142353
142354
142355
142356
142357
142358
142359
142360
142361
142362
142363
142364
142365
142366
142367
142368
142369
142370
142371
142372
142373
142374
142375
142376
142377
142378
142379
142380
142381
142382
142383
142384
142385
142386
142387
142388
142389
142390
142391
142392
142393
142394
142395
142396
142397
142398
142399
142400
142401
142402
142403
142404
142405
142406
142407
142408
142409
142410
142411
142412
142413
142414
142415
142416
142417
142418
142419
142420
142421
142422
142423
142424
142425
142426
142427
142428
142429
142430
142431
142432
142433
142434
142435
142436
142437
142438
142439
142440
142441
142442
142443
142444
142445
142446
142447
142448
142449
142450
142451
142452
142453
142454
142455
142456
142457
142458
142459
142460
142461
142462
142463
142464
142465
142466
142467
142468
142469
142470
142471
142472
142473
142474
142475
142476
142477
142478
142479
142480
142481
142482
142483
142484
142485
142486
142487
142488
142489
142490
142491
142492
142493
142494
142495
142496
142497
142498
142499
142500
142501
142502
142503
142504
142505
142506
142507
142508
142509
142510
142511
142512
142513
142514
142515
142516
142517
142518
142519
142520
142521
142522
142523
142524
142525
142526
142527
142528
142529
142530
142531
142532
142533
142534
142535
142536
142537
142538
142539
142540
142541
142542
142543
142544
142545
142546
142547
142548
142549
142550
142551
142552
142553
142554
142555
142556
142557
142558
142559
142560
142561
142562
142563
142564
142565
142566
142567
142568
142569
142570
142571
142572
142573
142574
142575
142576
142577
142578
142579
142580
142581
142582
142583
142584
142585
142586
142587
142588
142589
142590
142591
142592
142593
142594
142595
142596
142597
142598
142599
142600
142601
142602
142603
142604
142605
142606
142607
142608
142609
142610
142611
142612
142613
142614
142615
142616
142617
142618
142619
142620
142621
142622
142623
142624
142625
142626
142627
142628
142629
142630
142631
142632
142633
142634
142635
142636
142637
142638
142639
142640
142641
142642
142643
142644
142645
142646
142647
142648
142649
142650
142651
142652
142653
142654
142655
142656
142657
142658
142659
142660
142661
142662
142663
142664
142665
142666
142667
142668
142669
142670
142671
142672
142673
142674
142675
142676
142677
142678
142679
142680
142681
142682
142683
142684
142685
142686
142687
142688
142689
142690
142691
142692
142693
142694
142695
142696
142697
142698
142699
142700
142701
142702
142703
142704
142705
142706
142707
142708
142709
142710
142711
142712
142713
142714
142715
142716
142717
142718
142719
142720
142721
142722
142723
142724
142725
142726
142727
142728
142729
142730
142731
142732
142733
142734
142735
142736
142737
142738
142739
142740
142741
142742
142743
142744
142745
142746
142747
142748
142749
142750
142751
142752
142753
142754
142755
142756
142757
142758
142759
142760
142761
142762
142763
142764
142765
142766
142767
142768
142769
142770
142771
142772
142773
142774
142775
142776
142777
142778
142779
142780
142781
142782
142783
142784
142785
142786
142787
142788
142789
142790
142791
142792
142793
142794
142795
142796
142797
142798
142799
142800
142801
142802
142803
142804
142805
142806
142807
142808
142809
142810
142811
142812
142813
142814
142815
142816
142817
142818
142819
142820
142821
142822
142823
142824
142825
142826
142827
142828
142829
142830
142831
142832
142833
142834
142835
142836
142837
142838
142839
142840
142841
142842
142843
142844
142845
142846
142847
142848
142849
142850
142851
142852
142853
142854
142855
142856
142857
142858
142859
142860
142861
142862
142863
142864
142865
142866
142867
142868
142869
142870
142871
142872
142873
142874
142875
142876
142877
142878
142879
142880
142881
142882
142883
142884
142885
142886
142887
142888
142889
142890
142891
142892
142893
142894
142895
142896
142897
142898
142899
142900
142901
142902
142903
142904
142905
142906
142907
142908
142909
142910
142911
142912
142913
142914
142915
142916
142917
142918
142919
142920
142921
142922
142923
142924
142925
142926
142927
142928
142929
142930
142931
142932
142933
142934
142935
142936
142937
142938
142939
142940
142941
142942
142943
142944
142945
142946
142947
142948
142949
142950
142951
142952
142953
142954
142955
142956
142957
142958
142959
142960
142961
142962
142963
142964
142965
142966
142967
142968
142969
142970
142971
142972
142973
142974
142975
142976
142977
142978
142979
142980
142981
142982
142983
142984
142985
142986
142987
142988
142989
142990
142991
142992
142993
142994
142995
142996
142997
142998
142999
143000
143001
143002
143003
143004
143005
143006
143007
143008
143009
143010
143011
143012
143013
143014
143015
143016
143017
143018
143019
143020
143021
143022
143023
143024
143025
143026
143027
143028
143029
143030
143031
143032
143033
143034
143035
143036
143037
143038
143039
143040
143041
143042
143043
143044
143045
143046
143047
143048
143049
143050
143051
143052
143053
143054
143055
143056
143057
143058
143059
143060
143061
143062
143063
143064
143065
143066
143067
143068
143069
143070
143071
143072
143073
143074
143075
143076
143077
143078
143079
143080
143081
143082
143083
143084
143085
143086
143087
143088
143089
143090
143091
143092
143093
143094
143095
143096
143097
143098
143099
143100
143101
143102
143103
143104
143105
143106
143107
143108
143109
143110
143111
143112
143113
143114
143115
143116
143117
143118
143119
143120
143121
143122
143123
143124
143125
143126
143127
143128
143129
143130
143131
143132
143133
143134
143135
143136
143137
143138
143139
143140
143141
143142
143143
143144
143145
143146
143147
143148
143149
143150
143151
143152
143153
143154
143155
143156
143157
143158
143159
143160
143161
143162
143163
143164
143165
143166
143167
143168
143169
143170
143171
143172
143173
143174
143175
143176
143177
143178
143179
143180
143181
143182
143183
143184
143185
143186
143187
143188
143189
143190
143191
143192
143193
143194
143195
143196
143197
143198
143199
143200
143201
143202
143203
143204
143205
143206
143207
143208
143209
143210
143211
143212
143213
143214
143215
143216
143217
143218
143219
143220
143221
143222
143223
143224
143225
143226
143227
143228
143229
143230
143231
143232
143233
143234
143235
143236
143237
143238
143239
143240
143241
143242
143243
143244
143245
143246
143247
143248
143249
143250
143251
143252
143253
143254
143255
143256
143257
143258
143259
143260
143261
143262
143263
143264
143265
143266
143267
143268
143269
143270
143271
143272
143273
143274
143275
143276
143277
143278
143279
143280
143281
143282
143283
143284
143285
143286
143287
143288
143289
143290
143291
143292
143293
143294
143295
143296
143297
143298
143299
143300
143301
143302
143303
143304
143305
143306
143307
143308
143309
143310
143311
143312
143313
143314
143315
143316
143317
143318
143319
143320
143321
143322
143323
143324
143325
143326
143327
143328
143329
143330
143331
143332
143333
143334
143335
143336
143337
143338
143339
143340
143341
143342
143343
143344
143345
143346
143347
143348
143349
143350
143351
143352
143353
143354
143355
143356
143357
143358
143359
143360
143361
143362
143363
143364
143365
143366
143367
143368
143369
143370
143371
143372
143373
143374
143375
143376
143377
143378
143379
143380
143381
143382
143383
143384
143385
143386
143387
143388
143389
143390
143391
143392
143393
143394
143395
143396
143397
143398
143399
143400
143401
143402
143403
143404
143405
143406
143407
143408
143409
143410
143411
143412
143413
143414
143415
143416
143417
143418
143419
143420
143421
143422
143423
143424
143425
143426
143427
143428
143429
143430
143431
143432
143433
143434
143435
143436
143437
143438
143439
143440
143441
143442
143443
143444
143445
143446
143447
143448
143449
143450
143451
143452
143453
143454
143455
143456
143457
143458
143459
143460
143461
143462
143463
143464
143465
143466
143467
143468
143469
143470
143471
143472
143473
143474
143475
143476
143477
143478
143479
143480
143481
143482
143483
143484
143485
143486
143487
143488
143489
143490
143491
143492
143493
143494
143495
143496
143497
143498
143499
143500
143501
143502
143503
143504
143505
143506
143507
143508
143509
143510
143511
143512
143513
143514
143515
143516
143517
143518
143519
143520
143521
143522
143523
143524
143525
143526
143527
143528
143529
143530
143531
143532
143533
143534
143535
143536
143537
143538
143539
143540
143541
143542
143543
143544
143545
143546
143547
143548
143549
143550
143551
143552
143553
143554
143555
143556
143557
143558
143559
143560
143561
143562
143563
143564
143565
143566
143567
143568
143569
143570
143571
143572
143573
143574
143575
143576
143577
143578
143579
143580
143581
143582
143583
143584
143585
143586
143587
143588
143589
143590
143591
143592
143593
143594
143595
143596
143597
143598
143599
143600
143601
143602
143603
143604
143605
143606
143607
143608
143609
143610
143611
143612
143613
143614
143615
143616
143617
143618
143619
143620
143621
143622
143623
143624
143625
143626
143627
143628
143629
143630
143631
143632
143633
143634
143635
143636
143637
143638
143639
143640
143641
143642
143643
143644
143645
143646
143647
143648
143649
143650
143651
143652
143653
143654
143655
143656
143657
143658
143659
143660
143661
143662
143663
143664
143665
143666
143667
143668
143669
143670
143671
143672
143673
143674
143675
143676
143677
143678
143679
143680
143681
143682
143683
143684
143685
143686
143687
143688
143689
143690
143691
143692
143693
143694
143695
143696
143697
143698
143699
143700
143701
143702
143703
143704
143705
143706
143707
143708
143709
143710
143711
143712
143713
143714
143715
143716
143717
143718
143719
143720
143721
143722
143723
143724
143725
143726
143727
143728
143729
143730
143731
143732
143733
143734
143735
143736
143737
143738
143739
143740
143741
143742
143743
143744
143745
143746
143747
143748
143749
143750
143751
143752
143753
143754
143755
143756
143757
143758
143759
143760
143761
143762
143763
143764
143765
143766
143767
143768
143769
143770
143771
143772
143773
143774
143775
143776
143777
143778
143779
143780
143781
143782
143783
143784
143785
143786
143787
143788
143789
143790
143791
143792
143793
143794
143795
143796
143797
143798
143799
143800
143801
143802
143803
143804
143805
143806
143807
143808
143809
143810
143811
143812
143813
143814
143815
143816
143817
143818
143819
143820
143821
143822
143823
143824
143825
143826
143827
143828
143829
143830
143831
143832
143833
143834
143835
143836
143837
143838
143839
143840
143841
143842
143843
143844
143845
143846
143847
143848
143849
143850
143851
143852
143853
143854
143855
143856
143857
143858
143859
143860
143861
143862
143863
143864
143865
143866
143867
143868
143869
143870
143871
143872
143873
143874
143875
143876
143877
143878
143879
143880
143881
143882
143883
143884
143885
143886
143887
143888
143889
143890
143891
143892
143893
143894
143895
143896
143897
143898
143899
143900
143901
143902
143903
143904
143905
143906
143907
143908
143909
143910
143911
143912
143913
143914
143915
143916
143917
143918
143919
143920
143921
143922
143923
143924
143925
143926
143927
143928
143929
143930
143931
143932
143933
143934
143935
143936
143937
143938
143939
143940
143941
143942
143943
143944
143945
143946
143947
143948
143949
143950
143951
143952
143953
143954
143955
143956
143957
143958
143959
143960
143961
143962
143963
143964
143965
143966
143967
143968
143969
143970
143971
143972
143973
143974
143975
143976
143977
143978
143979
143980
143981
143982
143983
143984
143985
143986
143987
143988
143989
143990
143991
143992
143993
143994
143995
143996
143997
143998
143999
144000
144001
144002
144003
144004
144005
144006
144007
144008
144009
144010
144011
144012
144013
144014
144015
144016
144017
144018
144019
144020
144021
144022
144023
144024
144025
144026
144027
144028
144029
144030
144031
144032
144033
144034
144035
144036
144037
144038
144039
144040
144041
144042
144043
144044
144045
144046
144047
144048
144049
144050
144051
144052
144053
144054
144055
144056
144057
144058
144059
144060
144061
144062
144063
144064
144065
144066
144067
144068
144069
144070
144071
144072
144073
144074
144075
144076
144077
144078
144079
144080
144081
144082
144083
144084
144085
144086
144087
144088
144089
144090
144091
144092
144093
144094
144095
144096
144097
144098
144099
144100
144101
144102
144103
144104
144105
144106
144107
144108
144109
144110
144111
144112
144113
144114
144115
144116
144117
144118
144119
144120
144121
144122
144123
144124
144125
144126
144127
144128
144129
144130
144131
144132
144133
144134
144135
144136
144137
144138
144139
144140
144141
144142
144143
144144
144145
144146
144147
144148
144149
144150
144151
144152
144153
144154
144155
144156
144157
144158
144159
144160
144161
144162
144163
144164
144165
144166
144167
144168
144169
144170
144171
144172
144173
144174
144175
144176
144177
144178
144179
144180
144181
144182
144183
144184
144185
144186
144187
144188
144189
144190
144191
144192
144193
144194
144195
144196
144197
144198
144199
144200
144201
144202
144203
144204
144205
144206
144207
144208
144209
144210
144211
144212
144213
144214
144215
144216
144217
144218
144219
144220
144221
144222
144223
144224
144225
144226
144227
144228
144229
144230
144231
144232
144233
144234
144235
144236
144237
144238
144239
144240
144241
144242
144243
144244
144245
144246
144247
144248
144249
144250
144251
144252
144253
144254
144255
144256
144257
144258
144259
144260
144261
144262
144263
144264
144265
144266
144267
144268
144269
144270
144271
144272
144273
144274
144275
144276
144277
144278
144279
144280
144281
144282
144283
144284
144285
144286
144287
144288
144289
144290
144291
144292
144293
144294
144295
144296
144297
144298
144299
144300
144301
144302
144303
144304
144305
144306
144307
144308
144309
144310
144311
144312
144313
144314
144315
144316
144317
144318
144319
144320
144321
144322
144323
144324
144325
144326
144327
144328
144329
144330
144331
144332
144333
144334
144335
144336
144337
144338
144339
144340
144341
144342
144343
144344
144345
144346
144347
144348
144349
144350
144351
144352
144353
144354
144355
144356
144357
144358
144359
144360
144361
144362
144363
144364
144365
144366
144367
144368
144369
144370
144371
144372
144373
144374
144375
144376
144377
144378
144379
144380
144381
144382
144383
144384
144385
144386
144387
144388
144389
144390
144391
144392
144393
144394
144395
144396
144397
144398
144399
144400
144401
144402
144403
144404
144405
144406
144407
144408
144409
144410
144411
144412
144413
144414
144415
144416
144417
144418
144419
144420
144421
144422
144423
144424
144425
144426
144427
144428
144429
144430
144431
144432
144433
144434
144435
144436
144437
144438
144439
144440
144441
144442
144443
144444
144445
144446
144447
144448
144449
144450
144451
144452
144453
144454
144455
144456
144457
144458
144459
144460
144461
144462
144463
144464
144465
144466
144467
144468
144469
144470
144471
144472
144473
144474
144475
144476
144477
144478
144479
144480
144481
144482
144483
144484
144485
144486
144487
144488
144489
144490
144491
144492
144493
144494
144495
144496
144497
144498
144499
144500
144501
144502
144503
144504
144505
144506
144507
144508
144509
144510
144511
144512
144513
144514
144515
144516
144517
144518
144519
144520
144521
144522
144523
144524
144525
144526
144527
144528
144529
144530
144531
144532
144533
144534
144535
144536
144537
144538
144539
144540
144541
144542
144543
144544
144545
144546
144547
144548
144549
144550
144551
144552
144553
144554
144555
144556
144557
144558
144559
144560
144561
144562
144563
144564
144565
144566
144567
144568
144569
144570
144571
144572
144573
144574
144575
144576
144577
144578
144579
144580
144581
144582
144583
144584
144585
144586
144587
144588
144589
144590
144591
144592
144593
144594
144595
144596
144597
144598
144599
144600
144601
144602
144603
144604
144605
144606
144607
144608
144609
144610
144611
144612
144613
144614
144615
144616
144617
144618
144619
144620
144621
144622
144623
144624
144625
144626
144627
144628
144629
144630
144631
144632
144633
144634
144635
144636
144637
144638
144639
144640
144641
144642
144643
144644
144645
144646
144647
144648
144649
144650
144651
144652
144653
144654
144655
144656
144657
144658
144659
144660
144661
144662
144663
144664
144665
144666
144667
144668
144669
144670
144671
144672
144673
144674
144675
144676
144677
144678
144679
144680
144681
144682
144683
144684
144685
144686
144687
144688
144689
144690
144691
144692
144693
144694
144695
144696
144697
144698
144699
144700
144701
144702
144703
144704
144705
144706
144707
144708
144709
144710
144711
144712
144713
144714
144715
144716
144717
144718
144719
144720
144721
144722
144723
144724
144725
144726
144727
144728
144729
144730
144731
144732
144733
144734
144735
144736
144737
144738
144739
144740
144741
144742
144743
144744
144745
144746
144747
144748
144749
144750
144751
144752
144753
144754
144755
144756
144757
144758
144759
144760
144761
144762
144763
144764
144765
144766
144767
144768
144769
144770
144771
144772
144773
144774
144775
144776
144777
144778
144779
144780
144781
144782
144783
144784
144785
144786
144787
144788
144789
144790
144791
144792
144793
144794
144795
144796
144797
144798
144799
144800
144801
144802
144803
144804
144805
144806
144807
144808
144809
144810
144811
144812
144813
144814
144815
144816
144817
144818
144819
144820
144821
144822
144823
144824
144825
144826
144827
144828
144829
144830
144831
144832
144833
144834
144835
144836
144837
144838
144839
144840
144841
144842
144843
144844
144845
144846
144847
144848
144849
144850
144851
144852
144853
144854
144855
144856
144857
144858
144859
144860
144861
144862
144863
144864
144865
144866
144867
144868
144869
144870
144871
144872
144873
144874
144875
144876
144877
144878
144879
144880
144881
144882
144883
144884
144885
144886
144887
144888
144889
144890
144891
144892
144893
144894
144895
144896
144897
144898
144899
144900
144901
144902
144903
144904
144905
144906
144907
144908
144909
144910
144911
144912
144913
144914
144915
144916
144917
144918
144919
144920
144921
144922
144923
144924
144925
144926
144927
144928
144929
144930
144931
144932
144933
144934
144935
144936
144937
144938
144939
144940
144941
144942
144943
144944
144945
144946
144947
144948
144949
144950
144951
144952
144953
144954
144955
144956
144957
144958
144959
144960
144961
144962
144963
144964
144965
144966
144967
144968
144969
144970
144971
144972
144973
144974
144975
144976
144977
144978
144979
144980
144981
144982
144983
144984
144985
144986
144987
144988
144989
144990
144991
144992
144993
144994
144995
144996
144997
144998
144999
145000
145001
145002
145003
145004
145005
145006
145007
145008
145009
145010
145011
145012
145013
145014
145015
145016
145017
145018
145019
145020
145021
145022
145023
145024
145025
145026
145027
145028
145029
145030
145031
145032
145033
145034
145035
145036
145037
145038
145039
145040
145041
145042
145043
145044
145045
145046
145047
145048
145049
145050
145051
145052
145053
145054
145055
145056
145057
145058
145059
145060
145061
145062
145063
145064
145065
145066
145067
145068
145069
145070
145071
145072
145073
145074
145075
145076
145077
145078
145079
145080
145081
145082
145083
145084
145085
145086
145087
145088
145089
145090
145091
145092
145093
145094
145095
145096
145097
145098
145099
145100
145101
145102
145103
145104
145105
145106
145107
145108
145109
145110
145111
145112
145113
145114
145115
145116
145117
145118
145119
145120
145121
145122
145123
145124
145125
145126
145127
145128
145129
145130
145131
145132
145133
145134
145135
145136
145137
145138
145139
145140
145141
145142
145143
145144
145145
145146
145147
145148
145149
145150
145151
145152
145153
145154
145155
145156
145157
145158
145159
145160
145161
145162
145163
145164
145165
145166
145167
145168
145169
145170
145171
145172
145173
145174
145175
145176
145177
145178
145179
145180
145181
145182
145183
145184
145185
145186
145187
145188
145189
145190
145191
145192
145193
145194
145195
145196
145197
145198
145199
145200
145201
145202
145203
145204
145205
145206
145207
145208
145209
145210
145211
145212
145213
145214
145215
145216
145217
145218
145219
145220
145221
145222
145223
145224
145225
145226
145227
145228
145229
145230
145231
145232
145233
145234
145235
145236
145237
145238
145239
145240
145241
145242
145243
145244
145245
145246
145247
145248
145249
145250
145251
145252
145253
145254
145255
145256
145257
145258
145259
145260
145261
145262
145263
145264
145265
145266
145267
145268
145269
145270
145271
145272
145273
145274
145275
145276
145277
145278
145279
145280
145281
145282
145283
145284
145285
145286
145287
145288
145289
145290
145291
145292
145293
145294
145295
145296
145297
145298
145299
145300
145301
145302
145303
145304
145305
145306
145307
145308
145309
145310
145311
145312
145313
145314
145315
145316
145317
145318
145319
145320
145321
145322
145323
145324
145325
145326
145327
145328
145329
145330
145331
145332
145333
145334
145335
145336
145337
145338
145339
145340
145341
145342
145343
145344
145345
145346
145347
145348
145349
145350
145351
145352
145353
145354
145355
145356
145357
145358
145359
145360
145361
145362
145363
145364
145365
145366
145367
145368
145369
145370
145371
145372
145373
145374
145375
145376
145377
145378
145379
145380
145381
145382
145383
145384
145385
145386
145387
145388
145389
145390
145391
145392
145393
145394
145395
145396
145397
145398
145399
145400
145401
145402
145403
145404
145405
145406
145407
145408
145409
145410
145411
145412
145413
145414
145415
145416
145417
145418
145419
145420
145421
145422
145423
145424
145425
145426
145427
145428
145429
145430
145431
145432
145433
145434
145435
145436
145437
145438
145439
145440
145441
145442
145443
145444
145445
145446
145447
145448
145449
145450
145451
145452
145453
145454
145455
145456
145457
145458
145459
145460
145461
145462
145463
145464
145465
145466
145467
145468
145469
145470
145471
145472
145473
145474
145475
145476
145477
145478
145479
145480
145481
145482
145483
145484
145485
145486
145487
145488
145489
145490
145491
145492
145493
145494
145495
145496
145497
145498
145499
145500
145501
145502
145503
145504
145505
145506
145507
145508
145509
145510
145511
145512
145513
145514
145515
145516
145517
145518
145519
145520
145521
145522
145523
145524
145525
145526
145527
145528
145529
145530
145531
145532
145533
145534
145535
145536
145537
145538
145539
145540
145541
145542
145543
145544
145545
145546
145547
145548
145549
145550
145551
145552
145553
145554
145555
145556
145557
145558
145559
145560
145561
145562
145563
145564
145565
145566
145567
145568
145569
145570
145571
145572
145573
145574
145575
145576
145577
145578
145579
145580
145581
145582
145583
145584
145585
145586
145587
145588
145589
145590
145591
145592
145593
145594
145595
145596
145597
145598
145599
145600
145601
145602
145603
145604
145605
145606
145607
145608
145609
145610
145611
145612
145613
145614
145615
145616
145617
145618
145619
145620
145621
145622
145623
145624
145625
145626
145627
145628
145629
145630
145631
145632
145633
145634
145635
145636
145637
145638
145639
145640
145641
145642
145643
145644
145645
145646
145647
145648
145649
145650
145651
145652
145653
145654
145655
145656
145657
145658
145659
145660
145661
145662
145663
145664
145665
145666
145667
145668
145669
145670
145671
145672
145673
145674
145675
145676
145677
145678
145679
145680
145681
145682
145683
145684
145685
145686
145687
145688
145689
145690
145691
145692
145693
145694
145695
145696
145697
145698
145699
145700
145701
145702
145703
145704
145705
145706
145707
145708
145709
145710
145711
145712
145713
145714
145715
145716
145717
145718
145719
145720
145721
145722
145723
145724
145725
145726
145727
145728
145729
145730
145731
145732
145733
145734
145735
145736
145737
145738
145739
145740
145741
145742
145743
145744
145745
145746
145747
145748
145749
145750
145751
145752
145753
145754
145755
145756
145757
145758
145759
145760
145761
145762
145763
145764
145765
145766
145767
145768
145769
145770
145771
145772
145773
145774
145775
145776
145777
145778
145779
145780
145781
145782
145783
145784
145785
145786
145787
145788
145789
145790
145791
145792
145793
145794
145795
145796
145797
145798
145799
145800
145801
145802
145803
145804
145805
145806
145807
145808
145809
145810
145811
145812
145813
145814
145815
145816
145817
145818
145819
145820
145821
145822
145823
145824
145825
145826
145827
145828
145829
145830
145831
145832
145833
145834
145835
145836
145837
145838
145839
145840
145841
145842
145843
145844
145845
145846
145847
145848
145849
145850
145851
145852
145853
145854
145855
145856
145857
145858
145859
145860
145861
145862
145863
145864
145865
145866
145867
145868
145869
145870
145871
145872
145873
145874
145875
145876
145877
145878
145879
145880
145881
145882
145883
145884
145885
145886
145887
145888
145889
145890
145891
145892
145893
145894
145895
145896
145897
145898
145899
145900
145901
145902
145903
145904
145905
145906
145907
145908
145909
145910
145911
145912
145913
145914
145915
145916
145917
145918
145919
145920
145921
145922
145923
145924
145925
145926
145927
145928
145929
145930
145931
145932
145933
145934
145935
145936
145937
145938
145939
145940
145941
145942
145943
145944
145945
145946
145947
145948
145949
145950
145951
145952
145953
145954
145955
145956
145957
145958
145959
145960
145961
145962
145963
145964
145965
145966
145967
145968
145969
145970
145971
145972
145973
145974
145975
145976
145977
145978
145979
145980
145981
145982
145983
145984
145985
145986
145987
145988
145989
145990
145991
145992
145993
145994
145995
145996
145997
145998
145999
146000
146001
146002
146003
146004
146005
146006
146007
146008
146009
146010
146011
146012
146013
146014
146015
146016
146017
146018
146019
146020
146021
146022
146023
146024
146025
146026
146027
146028
146029
146030
146031
146032
146033
146034
146035
146036
146037
146038
146039
146040
146041
146042
146043
146044
146045
146046
146047
146048
146049
146050
146051
146052
146053
146054
146055
146056
146057
146058
146059
146060
146061
146062
146063
146064
146065
146066
146067
146068
146069
146070
146071
146072
146073
146074
146075
146076
146077
146078
146079
146080
146081
146082
146083
146084
146085
146086
146087
146088
146089
146090
146091
146092
146093
146094
146095
146096
146097
146098
146099
146100
146101
146102
146103
146104
146105
146106
146107
146108
146109
146110
146111
146112
146113
146114
146115
146116
146117
146118
146119
146120
146121
146122
146123
146124
146125
146126
146127
146128
146129
146130
146131
146132
146133
146134
146135
146136
146137
146138
146139
146140
146141
146142
146143
146144
146145
146146
146147
146148
146149
146150
146151
146152
146153
146154
146155
146156
146157
146158
146159
146160
146161
146162
146163
146164
146165
146166
146167
146168
146169
146170
146171
146172
146173
146174
146175
146176
146177
146178
146179
146180
146181
146182
146183
146184
146185
146186
146187
146188
146189
146190
146191
146192
146193
146194
146195
146196
146197
146198
146199
146200
146201
146202
146203
146204
146205
146206
146207
146208
146209
146210
146211
146212
146213
146214
146215
146216
146217
146218
146219
146220
146221
146222
146223
146224
146225
146226
146227
146228
146229
146230
146231
146232
146233
146234
146235
146236
146237
146238
146239
146240
146241
146242
146243
146244
146245
146246
146247
146248
146249
146250
146251
146252
146253
146254
146255
146256
146257
146258
146259
146260
146261
146262
146263
146264
146265
146266
146267
146268
146269
146270
146271
146272
146273
146274
146275
146276
146277
146278
146279
146280
146281
146282
146283
146284
146285
146286
146287
146288
146289
146290
146291
146292
146293
146294
146295
146296
146297
146298
146299
146300
146301
146302
146303
146304
146305
146306
146307
146308
146309
146310
146311
146312
146313
146314
146315
146316
146317
146318
146319
146320
146321
146322
146323
146324
146325
146326
146327
146328
146329
146330
146331
146332
146333
146334
146335
146336
146337
146338
146339
146340
146341
146342
146343
146344
146345
146346
146347
146348
146349
146350
146351
146352
146353
146354
146355
146356
146357
146358
146359
146360
146361
146362
146363
146364
146365
146366
146367
146368
146369
146370
146371
146372
146373
146374
146375
146376
146377
146378
146379
146380
146381
146382
146383
146384
146385
146386
146387
146388
146389
146390
146391
146392
146393
146394
146395
146396
146397
146398
146399
146400
146401
146402
146403
146404
146405
146406
146407
146408
146409
146410
146411
146412
146413
146414
146415
146416
146417
146418
146419
146420
146421
146422
146423
146424
146425
146426
146427
146428
146429
146430
146431
146432
146433
146434
146435
146436
146437
146438
146439
146440
146441
146442
146443
146444
146445
146446
146447
146448
146449
146450
146451
146452
146453
146454
146455
146456
146457
146458
146459
146460
146461
146462
146463
146464
146465
146466
146467
146468
146469
146470
146471
146472
146473
146474
146475
146476
146477
146478
146479
146480
146481
146482
146483
146484
146485
146486
146487
146488
146489
146490
146491
146492
146493
146494
146495
146496
146497
146498
146499
146500
146501
146502
146503
146504
146505
146506
146507
146508
146509
146510
146511
146512
146513
146514
146515
146516
146517
146518
146519
146520
146521
146522
146523
146524
146525
146526
146527
146528
146529
146530
146531
146532
146533
146534
146535
146536
146537
146538
146539
146540
146541
146542
146543
146544
146545
146546
146547
146548
146549
146550
146551
146552
146553
146554
146555
146556
146557
146558
146559
146560
146561
146562
146563
146564
146565
146566
146567
146568
146569
146570
146571
146572
146573
146574
146575
146576
146577
146578
146579
146580
146581
146582
146583
146584
146585
146586
146587
146588
146589
146590
146591
146592
146593
146594
146595
146596
146597
146598
146599
146600
146601
146602
146603
146604
146605
146606
146607
146608
146609
146610
146611
146612
146613
146614
146615
146616
146617
146618
146619
146620
146621
146622
146623
146624
146625
146626
146627
146628
146629
146630
146631
146632
146633
146634
146635
146636
146637
146638
146639
146640
146641
146642
146643
146644
146645
146646
146647
146648
146649
146650
146651
146652
146653
146654
146655
146656
146657
146658
146659
146660
146661
146662
146663
146664
146665
146666
146667
146668
146669
146670
146671
146672
146673
146674
146675
146676
146677
146678
146679
146680
146681
146682
146683
146684
146685
146686
146687
146688
146689
146690
146691
146692
146693
146694
146695
146696
146697
146698
146699
146700
146701
146702
146703
146704
146705
146706
146707
146708
146709
146710
146711
146712
146713
146714
146715
146716
146717
146718
146719
146720
146721
146722
146723
146724
146725
146726
146727
146728
146729
146730
146731
146732
146733
146734
146735
146736
146737
146738
146739
146740
146741
146742
146743
146744
146745
146746
146747
146748
146749
146750
146751
146752
146753
146754
146755
146756
146757
146758
146759
146760
146761
146762
146763
146764
146765
146766
146767
146768
146769
146770
146771
146772
146773
146774
146775
146776
146777
146778
146779
146780
146781
146782
146783
146784
146785
146786
146787
146788
146789
146790
146791
146792
146793
146794
146795
146796
146797
146798
146799
146800
146801
146802
146803
146804
146805
146806
146807
146808
146809
146810
146811
146812
146813
146814
146815
146816
146817
146818
146819
146820
146821
146822
146823
146824
146825
146826
146827
146828
146829
146830
146831
146832
146833
146834
146835
146836
146837
146838
146839
146840
146841
146842
146843
146844
146845
146846
146847
146848
146849
146850
146851
146852
146853
146854
146855
146856
146857
146858
146859
146860
146861
146862
146863
146864
146865
146866
146867
146868
146869
146870
146871
146872
146873
146874
146875
146876
146877
146878
146879
146880
146881
146882
146883
146884
146885
146886
146887
146888
146889
146890
146891
146892
146893
146894
146895
146896
146897
146898
146899
146900
146901
146902
146903
146904
146905
146906
146907
146908
146909
146910
146911
146912
146913
146914
146915
146916
146917
146918
146919
146920
146921
146922
146923
146924
146925
146926
146927
146928
146929
146930
146931
146932
146933
146934
146935
146936
146937
146938
146939
146940
146941
146942
146943
146944
146945
146946
146947
146948
146949
146950
146951
146952
146953
146954
146955
146956
146957
146958
146959
146960
146961
146962
146963
146964
146965
146966
146967
146968
146969
146970
146971
146972
146973
146974
146975
146976
146977
146978
146979
146980
146981
146982
146983
146984
146985
146986
146987
146988
146989
146990
146991
146992
146993
146994
146995
146996
146997
146998
146999
147000
147001
147002
147003
147004
147005
147006
147007
147008
147009
147010
147011
147012
147013
147014
147015
147016
147017
147018
147019
147020
147021
147022
147023
147024
147025
147026
147027
147028
147029
147030
147031
147032
147033
147034
147035
147036
147037
147038
147039
147040
147041
147042
147043
147044
147045
147046
147047
147048
147049
147050
147051
147052
147053
147054
147055
147056
147057
147058
147059
147060
147061
147062
147063
147064
147065
147066
147067
147068
147069
147070
147071
147072
147073
147074
147075
147076
147077
147078
147079
147080
147081
147082
147083
147084
147085
147086
147087
147088
147089
147090
147091
147092
147093
147094
147095
147096
147097
147098
147099
147100
147101
147102
147103
147104
147105
147106
147107
147108
147109
147110
147111
147112
147113
147114
147115
147116
147117
147118
147119
147120
147121
147122
147123
147124
147125
147126
147127
147128
147129
147130
147131
147132
147133
147134
147135
147136
147137
147138
147139
147140
147141
147142
147143
147144
147145
147146
147147
147148
147149
147150
147151
147152
147153
147154
147155
147156
147157
147158
147159
147160
147161
147162
147163
147164
147165
147166
147167
147168
147169
147170
147171
147172
147173
147174
147175
147176
147177
147178
147179
147180
147181
147182
147183
147184
147185
147186
147187
147188
147189
147190
147191
147192
147193
147194
147195
147196
147197
147198
147199
147200
147201
147202
147203
147204
147205
147206
147207
147208
147209
147210
147211
147212
147213
147214
147215
147216
147217
147218
147219
147220
147221
147222
147223
147224
147225
147226
147227
147228
147229
147230
147231
147232
147233
147234
147235
147236
147237
147238
147239
147240
147241
147242
147243
147244
147245
147246
147247
147248
147249
147250
147251
147252
147253
147254
147255
147256
147257
147258
147259
147260
147261
147262
147263
147264
147265
147266
147267
147268
147269
147270
147271
147272
147273
147274
147275
147276
147277
147278
147279
147280
147281
147282
147283
147284
147285
147286
147287
147288
147289
147290
147291
147292
147293
147294
147295
147296
147297
147298
147299
147300
147301
147302
147303
147304
147305
147306
147307
147308
147309
147310
147311
147312
147313
147314
147315
147316
147317
147318
147319
147320
147321
147322
147323
147324
147325
147326
147327
147328
147329
147330
147331
147332
147333
147334
147335
147336
147337
147338
147339
147340
147341
147342
147343
147344
147345
147346
147347
147348
147349
147350
147351
147352
147353
147354
147355
147356
147357
147358
147359
147360
147361
147362
147363
147364
147365
147366
147367
147368
147369
147370
147371
147372
147373
147374
147375
147376
147377
147378
147379
147380
147381
147382
147383
147384
147385
147386
147387
147388
147389
147390
147391
147392
147393
147394
147395
147396
147397
147398
147399
147400
147401
147402
147403
147404
147405
147406
147407
147408
147409
147410
147411
147412
147413
147414
147415
147416
147417
147418
147419
147420
147421
147422
147423
147424
147425
147426
147427
147428
147429
147430
147431
147432
147433
147434
147435
147436
147437
147438
147439
147440
147441
147442
147443
147444
147445
147446
147447
147448
147449
147450
147451
147452
147453
147454
147455
147456
147457
147458
147459
147460
147461
147462
147463
147464
147465
147466
147467
147468
147469
147470
147471
147472
147473
147474
147475
147476
147477
147478
147479
147480
147481
147482
147483
147484
147485
147486
147487
147488
147489
147490
147491
147492
147493
147494
147495
147496
147497
147498
147499
147500
147501
147502
147503
147504
147505
147506
147507
147508
147509
147510
147511
147512
147513
147514
147515
147516
147517
147518
147519
147520
147521
147522
147523
147524
147525
147526
147527
147528
147529
147530
147531
147532
147533
147534
147535
147536
147537
147538
147539
147540
147541
147542
147543
147544
147545
147546
147547
147548
147549
147550
147551
147552
147553
147554
147555
147556
147557
147558
147559
147560
147561
147562
147563
147564
147565
147566
147567
147568
147569
147570
147571
147572
147573
147574
147575
147576
147577
147578
147579
147580
147581
147582
147583
147584
147585
147586
147587
147588
147589
147590
147591
147592
147593
147594
147595
147596
147597
147598
147599
147600
147601
147602
147603
147604
147605
147606
147607
147608
147609
147610
147611
147612
147613
147614
147615
147616
147617
147618
147619
147620
147621
147622
147623
147624
147625
147626
147627
147628
147629
147630
147631
147632
147633
147634
147635
147636
147637
147638
147639
147640
147641
147642
147643
147644
147645
147646
147647
147648
147649
147650
147651
147652
147653
147654
147655
147656
147657
147658
147659
147660
147661
147662
147663
147664
147665
147666
147667
147668
147669
147670
147671
147672
147673
147674
147675
147676
147677
147678
147679
147680
147681
147682
147683
147684
147685
147686
147687
147688
147689
147690
147691
147692
147693
147694
147695
147696
147697
147698
147699
147700
147701
147702
147703
147704
147705
147706
147707
147708
147709
147710
147711
147712
147713
147714
147715
147716
147717
147718
147719
147720
147721
147722
147723
147724
147725
147726
147727
147728
147729
147730
147731
147732
147733
147734
147735
147736
147737
147738
147739
147740
147741
147742
147743
147744
147745
147746
147747
147748
147749
147750
147751
147752
147753
147754
147755
147756
147757
147758
147759
147760
147761
147762
147763
147764
147765
147766
147767
147768
147769
147770
147771
147772
147773
147774
147775
147776
147777
147778
147779
147780
147781
147782
147783
147784
147785
147786
147787
147788
147789
147790
147791
147792
147793
147794
147795
147796
147797
147798
147799
147800
147801
147802
147803
147804
147805
147806
147807
147808
147809
147810
147811
147812
147813
147814
147815
147816
147817
147818
147819
147820
147821
147822
147823
147824
147825
147826
147827
147828
147829
147830
147831
147832
147833
147834
147835
147836
147837
147838
147839
147840
147841
147842
147843
147844
147845
147846
147847
147848
147849
147850
147851
147852
147853
147854
147855
147856
147857
147858
147859
147860
147861
147862
147863
147864
147865
147866
147867
147868
147869
147870
147871
147872
147873
147874
147875
147876
147877
147878
147879
147880
147881
147882
147883
147884
147885
147886
147887
147888
147889
147890
147891
147892
147893
147894
147895
147896
147897
147898
147899
147900
147901
147902
147903
147904
147905
147906
147907
147908
147909
147910
147911
147912
147913
147914
147915
147916
147917
147918
147919
147920
147921
147922
147923
147924
147925
147926
147927
147928
147929
147930
147931
147932
147933
147934
147935
147936
147937
147938
147939
147940
147941
147942
147943
147944
147945
147946
147947
147948
147949
147950
147951
147952
147953
147954
147955
147956
147957
147958
147959
147960
147961
147962
147963
147964
147965
147966
147967
147968
147969
147970
147971
147972
147973
147974
147975
147976
147977
147978
147979
147980
147981
147982
147983
147984
147985
147986
147987
147988
147989
147990
147991
147992
147993
147994
147995
147996
147997
147998
147999
148000
148001
148002
148003
148004
148005
148006
148007
148008
148009
148010
148011
148012
148013
148014
148015
148016
148017
148018
148019
148020
148021
148022
148023
148024
148025
148026
148027
148028
148029
148030
148031
148032
148033
148034
148035
148036
148037
148038
148039
148040
148041
148042
148043
148044
148045
148046
148047
148048
148049
148050
148051
148052
148053
148054
148055
148056
148057
148058
148059
148060
148061
148062
148063
148064
148065
148066
148067
148068
148069
148070
148071
148072
148073
148074
148075
148076
148077
148078
148079
148080
148081
148082
148083
148084
148085
148086
148087
148088
148089
148090
148091
148092
148093
148094
148095
148096
148097
148098
148099
148100
148101
148102
148103
148104
148105
148106
148107
148108
148109
148110
148111
148112
148113
148114
148115
148116
148117
148118
148119
148120
148121
148122
148123
148124
148125
148126
148127
148128
148129
148130
148131
148132
148133
148134
148135
148136
148137
148138
148139
148140
148141
148142
148143
148144
148145
148146
148147
148148
148149
148150
148151
148152
148153
148154
148155
148156
148157
148158
148159
148160
148161
148162
148163
148164
148165
148166
148167
148168
148169
148170
148171
148172
148173
148174
148175
148176
148177
148178
148179
148180
148181
148182
148183
148184
148185
148186
148187
148188
148189
148190
148191
148192
148193
148194
148195
148196
148197
148198
148199
148200
148201
148202
148203
148204
148205
148206
148207
148208
148209
148210
148211
148212
148213
148214
148215
148216
148217
148218
148219
148220
148221
148222
148223
148224
148225
148226
148227
148228
148229
148230
148231
148232
148233
148234
148235
148236
148237
148238
148239
148240
148241
148242
148243
148244
148245
148246
148247
148248
148249
148250
148251
148252
148253
148254
148255
148256
148257
148258
148259
148260
148261
148262
148263
148264
148265
148266
148267
148268
148269
148270
148271
148272
148273
148274
148275
148276
148277
148278
148279
148280
148281
148282
148283
148284
148285
148286
148287
148288
148289
148290
148291
148292
148293
148294
148295
148296
148297
148298
148299
148300
148301
148302
148303
148304
148305
148306
148307
148308
148309
148310
148311
148312
148313
148314
148315
148316
148317
148318
148319
148320
148321
148322
148323
148324
148325
148326
148327
148328
148329
148330
148331
148332
148333
148334
148335
148336
148337
148338
148339
148340
148341
148342
148343
148344
148345
148346
148347
148348
148349
148350
148351
148352
148353
148354
148355
148356
148357
148358
148359
148360
148361
148362
148363
148364
148365
148366
148367
148368
148369
148370
148371
148372
148373
148374
148375
148376
148377
148378
148379
148380
148381
148382
148383
148384
148385
148386
148387
148388
148389
148390
148391
148392
148393
148394
148395
148396
148397
148398
148399
148400
148401
148402
148403
148404
148405
148406
148407
148408
148409
148410
148411
148412
148413
148414
148415
148416
148417
148418
148419
148420
148421
148422
148423
148424
148425
148426
148427
148428
148429
148430
148431
148432
148433
148434
148435
148436
148437
148438
148439
148440
148441
148442
148443
148444
148445
148446
148447
148448
148449
148450
148451
148452
148453
148454
148455
148456
148457
148458
148459
148460
148461
148462
148463
148464
148465
148466
148467
148468
148469
148470
148471
148472
148473
148474
148475
148476
148477
148478
148479
148480
148481
148482
148483
148484
148485
148486
148487
148488
148489
148490
148491
148492
148493
148494
148495
148496
148497
148498
148499
148500
148501
148502
148503
148504
148505
148506
148507
148508
148509
148510
148511
148512
148513
148514
148515
148516
148517
148518
148519
148520
148521
148522
148523
148524
148525
148526
148527
148528
148529
148530
148531
148532
148533
148534
148535
148536
148537
148538
148539
148540
148541
148542
148543
148544
148545
148546
148547
148548
148549
148550
148551
148552
148553
148554
148555
148556
148557
148558
148559
148560
148561
148562
148563
148564
148565
148566
148567
148568
148569
148570
148571
148572
148573
148574
148575
148576
148577
148578
148579
148580
148581
148582
148583
148584
148585
148586
148587
148588
148589
148590
148591
148592
148593
148594
148595
148596
148597
148598
148599
148600
148601
148602
148603
148604
148605
148606
148607
148608
148609
148610
148611
148612
148613
148614
148615
148616
148617
148618
148619
148620
148621
148622
148623
148624
148625
148626
148627
148628
148629
148630
148631
148632
148633
148634
148635
148636
148637
148638
148639
148640
148641
148642
148643
148644
148645
148646
148647
148648
148649
148650
148651
148652
148653
148654
148655
148656
148657
148658
148659
148660
148661
148662
148663
148664
148665
148666
148667
148668
148669
148670
148671
148672
148673
148674
148675
148676
148677
148678
148679
148680
148681
148682
148683
148684
148685
148686
148687
148688
148689
148690
148691
148692
148693
148694
148695
148696
148697
148698
148699
148700
148701
148702
148703
148704
148705
148706
148707
148708
148709
148710
148711
148712
148713
148714
148715
148716
148717
148718
148719
148720
148721
148722
148723
148724
148725
148726
148727
148728
148729
148730
148731
148732
148733
148734
148735
148736
148737
148738
148739
148740
148741
148742
148743
148744
148745
148746
148747
148748
148749
148750
148751
148752
148753
148754
148755
148756
148757
148758
148759
148760
148761
148762
148763
148764
148765
148766
148767
148768
148769
148770
148771
148772
148773
148774
148775
148776
148777
148778
148779
148780
148781
148782
148783
148784
148785
148786
148787
148788
148789
148790
148791
148792
148793
148794
148795
148796
148797
148798
148799
148800
148801
148802
148803
148804
148805
148806
148807
148808
148809
148810
148811
148812
148813
148814
148815
148816
148817
148818
148819
148820
148821
148822
148823
148824
148825
148826
148827
148828
148829
148830
148831
148832
148833
148834
148835
148836
148837
148838
148839
148840
148841
148842
148843
148844
148845
148846
148847
148848
148849
148850
148851
148852
148853
148854
148855
148856
148857
148858
148859
148860
148861
148862
148863
148864
148865
148866
148867
148868
148869
148870
148871
148872
148873
148874
148875
148876
148877
148878
148879
148880
148881
148882
148883
148884
148885
148886
148887
148888
148889
148890
148891
148892
148893
148894
148895
148896
148897
148898
148899
148900
148901
148902
148903
148904
148905
148906
148907
148908
148909
148910
148911
148912
148913
148914
148915
148916
148917
148918
148919
148920
148921
148922
148923
148924
148925
148926
148927
148928
148929
148930
148931
148932
148933
148934
148935
148936
148937
148938
148939
148940
148941
148942
148943
148944
148945
148946
148947
148948
148949
148950
148951
148952
148953
148954
148955
148956
148957
148958
148959
148960
148961
148962
148963
148964
148965
148966
148967
148968
148969
148970
148971
148972
148973
148974
148975
148976
148977
148978
148979
148980
148981
148982
148983
148984
148985
148986
148987
148988
148989
148990
148991
148992
148993
148994
148995
148996
148997
148998
148999
149000
149001
149002
149003
149004
149005
149006
149007
149008
149009
149010
149011
149012
149013
149014
149015
149016
149017
149018
149019
149020
149021
149022
149023
149024
149025
149026
149027
149028
149029
149030
149031
149032
149033
149034
149035
149036
149037
149038
149039
149040
149041
149042
149043
149044
149045
149046
149047
149048
149049
149050
149051
149052
149053
149054
149055
149056
149057
149058
149059
149060
149061
149062
149063
149064
149065
149066
149067
149068
149069
149070
149071
149072
149073
149074
149075
149076
149077
149078
149079
149080
149081
149082
149083
149084
149085
149086
149087
149088
149089
149090
149091
149092
149093
149094
149095
149096
149097
149098
149099
149100
149101
149102
149103
149104
149105
149106
149107
149108
149109
149110
149111
149112
149113
149114
149115
149116
149117
149118
149119
149120
149121
149122
149123
149124
149125
149126
149127
149128
149129
149130
149131
149132
149133
149134
149135
149136
149137
149138
149139
149140
149141
149142
149143
149144
149145
149146
149147
149148
149149
149150
149151
149152
149153
149154
149155
149156
149157
149158
149159
149160
149161
149162
149163
149164
149165
149166
149167
149168
149169
149170
149171
149172
149173
149174
149175
149176
149177
149178
149179
149180
149181
149182
149183
149184
149185
149186
149187
149188
149189
149190
149191
149192
149193
149194
149195
149196
149197
149198
149199
149200
149201
149202
149203
149204
149205
149206
149207
149208
149209
149210
149211
149212
149213
149214
149215
149216
149217
149218
149219
149220
149221
149222
149223
149224
149225
149226
149227
149228
149229
149230
149231
149232
149233
149234
149235
149236
149237
149238
149239
149240
149241
149242
149243
149244
149245
149246
149247
149248
149249
149250
149251
149252
149253
149254
149255
149256
149257
149258
149259
149260
149261
149262
149263
149264
149265
149266
149267
149268
149269
149270
149271
149272
149273
149274
149275
149276
149277
149278
149279
149280
149281
149282
149283
149284
149285
149286
149287
149288
149289
149290
149291
149292
149293
149294
149295
149296
149297
149298
149299
149300
149301
149302
149303
149304
149305
149306
149307
149308
149309
149310
149311
149312
149313
149314
149315
149316
149317
149318
149319
149320
149321
149322
149323
149324
149325
149326
149327
149328
149329
149330
149331
149332
149333
149334
149335
149336
149337
149338
149339
149340
149341
149342
149343
149344
149345
149346
149347
149348
149349
149350
149351
149352
149353
149354
149355
149356
149357
149358
149359
149360
149361
149362
149363
149364
149365
149366
149367
149368
149369
149370
149371
149372
149373
149374
149375
149376
149377
149378
149379
149380
149381
149382
149383
149384
149385
149386
149387
149388
149389
149390
149391
149392
149393
149394
149395
149396
149397
149398
149399
149400
149401
149402
149403
149404
149405
149406
149407
149408
149409
149410
149411
149412
149413
149414
149415
149416
149417
149418
149419
149420
149421
149422
149423
149424
149425
149426
149427
149428
149429
149430
149431
149432
149433
149434
149435
149436
149437
149438
149439
149440
149441
149442
149443
149444
149445
149446
149447
149448
149449
149450
149451
149452
149453
149454
149455
149456
149457
149458
149459
149460
149461
149462
149463
149464
149465
149466
149467
149468
149469
149470
149471
149472
149473
149474
149475
149476
149477
149478
149479
149480
149481
149482
149483
149484
149485
149486
149487
149488
149489
149490
149491
149492
149493
149494
149495
149496
149497
149498
149499
149500
149501
149502
149503
149504
149505
149506
149507
149508
149509
149510
149511
149512
149513
149514
149515
149516
149517
149518
149519
149520
149521
149522
149523
149524
149525
149526
149527
149528
149529
149530
149531
149532
149533
149534
149535
149536
149537
149538
149539
149540
149541
149542
149543
149544
149545
149546
149547
149548
149549
149550
149551
149552
149553
149554
149555
149556
149557
149558
149559
149560
149561
149562
149563
149564
149565
149566
149567
149568
149569
149570
149571
149572
149573
149574
149575
149576
149577
149578
149579
149580
149581
149582
149583
149584
149585
149586
149587
149588
149589
149590
149591
149592
149593
149594
149595
149596
149597
149598
149599
149600
149601
149602
149603
149604
149605
149606
149607
149608
149609
149610
149611
149612
149613
149614
149615
149616
149617
149618
149619
149620
149621
149622
149623
149624
149625
149626
149627
149628
149629
149630
149631
149632
149633
149634
149635
149636
149637
149638
149639
149640
149641
149642
149643
149644
149645
149646
149647
149648
149649
149650
149651
149652
149653
149654
149655
149656
149657
149658
149659
149660
149661
149662
149663
149664
149665
149666
149667
149668
149669
149670
149671
149672
149673
149674
149675
149676
149677
149678
149679
149680
149681
149682
149683
149684
149685
149686
149687
149688
149689
149690
149691
149692
149693
149694
149695
149696
149697
149698
149699
149700
149701
149702
149703
149704
149705
149706
149707
149708
149709
149710
149711
149712
149713
149714
149715
149716
149717
149718
149719
149720
149721
149722
149723
149724
149725
149726
149727
149728
149729
149730
149731
149732
149733
149734
149735
149736
149737
149738
149739
149740
149741
149742
149743
149744
149745
149746
149747
149748
149749
149750
149751
149752
149753
149754
149755
149756
149757
149758
149759
149760
149761
149762
149763
149764
149765
149766
149767
149768
149769
149770
149771
149772
149773
149774
149775
149776
149777
149778
149779
149780
149781
149782
149783
149784
149785
149786
149787
149788
149789
149790
149791
149792
149793
149794
149795
149796
149797
149798
149799
149800
149801
149802
149803
149804
149805
149806
149807
149808
149809
149810
149811
149812
149813
149814
149815
149816
149817
149818
149819
149820
149821
149822
149823
149824
149825
149826
149827
149828
149829
149830
149831
149832
149833
149834
149835
149836
149837
149838
149839
149840
149841
149842
149843
149844
149845
149846
149847
149848
149849
149850
149851
149852
149853
149854
149855
149856
149857
149858
149859
149860
149861
149862
149863
149864
149865
149866
149867
149868
149869
149870
149871
149872
149873
149874
149875
149876
149877
149878
149879
149880
149881
149882
149883
149884
149885
149886
149887
149888
149889
149890
149891
149892
149893
149894
149895
149896
149897
149898
149899
149900
149901
149902
149903
149904
149905
149906
149907
149908
149909
149910
149911
149912
149913
149914
149915
149916
149917
149918
149919
149920
149921
149922
149923
149924
149925
149926
149927
149928
149929
149930
149931
149932
149933
149934
149935
149936
149937
149938
149939
149940
149941
149942
149943
149944
149945
149946
149947
149948
149949
149950
149951
149952
149953
149954
149955
149956
149957
149958
149959
149960
149961
149962
149963
149964
149965
149966
149967
149968
149969
149970
149971
149972
149973
149974
149975
149976
149977
149978
149979
149980
149981
149982
149983
149984
149985
149986
149987
149988
149989
149990
149991
149992
149993
149994
149995
149996
149997
149998
149999
150000
150001
150002
150003
150004
150005
150006
150007
150008
150009
150010
150011
150012
150013
150014
150015
150016
150017
150018
150019
150020
150021
150022
150023
150024
150025
150026
150027
150028
150029
150030
150031
150032
150033
150034
150035
150036
150037
150038
150039
150040
150041
150042
150043
150044
150045
150046
150047
150048
150049
150050
150051
150052
150053
150054
150055
150056
150057
150058
150059
150060
150061
150062
150063
150064
150065
150066
150067
150068
150069
150070
150071
150072
150073
150074
150075
150076
150077
150078
150079
150080
150081
150082
150083
150084
150085
150086
150087
150088
150089
150090
150091
150092
150093
150094
150095
150096
150097
150098
150099
150100
150101
150102
150103
150104
150105
150106
150107
150108
150109
150110
150111
150112
150113
150114
150115
150116
150117
150118
150119
150120
150121
150122
150123
150124
150125
150126
150127
150128
150129
150130
150131
150132
150133
150134
150135
150136
150137
150138
150139
150140
150141
150142
150143
150144
150145
150146
150147
150148
150149
150150
150151
150152
150153
150154
150155
150156
150157
150158
150159
150160
150161
150162
150163
150164
150165
150166
150167
150168
150169
150170
150171
150172
150173
150174
150175
150176
150177
150178
150179
150180
150181
150182
150183
150184
150185
150186
150187
150188
150189
150190
150191
150192
150193
150194
150195
150196
150197
150198
150199
150200
150201
150202
150203
150204
150205
150206
150207
150208
150209
150210
150211
150212
150213
150214
150215
150216
150217
150218
150219
150220
150221
150222
150223
150224
150225
150226
150227
150228
150229
150230
150231
150232
150233
150234
150235
150236
150237
150238
150239
150240
150241
150242
150243
150244
150245
150246
150247
150248
150249
150250
150251
150252
150253
150254
150255
150256
150257
150258
150259
150260
150261
150262
150263
150264
150265
150266
150267
150268
150269
150270
150271
150272
150273
150274
150275
150276
150277
150278
150279
150280
150281
150282
150283
150284
150285
150286
150287
150288
150289
150290
150291
150292
150293
150294
150295
150296
150297
150298
150299
150300
150301
150302
150303
150304
150305
150306
150307
150308
150309
150310
150311
150312
150313
150314
150315
150316
150317
150318
150319
150320
150321
150322
150323
150324
150325
150326
150327
150328
150329
150330
150331
150332
150333
150334
150335
150336
150337
150338
150339
150340
150341
150342
150343
150344
150345
150346
150347
150348
150349
150350
150351
150352
150353
150354
150355
150356
150357
150358
150359
150360
150361
150362
150363
150364
150365
150366
150367
150368
150369
150370
150371
150372
150373
150374
150375
150376
150377
150378
150379
150380
150381
150382
150383
150384
150385
150386
150387
150388
150389
150390
150391
150392
150393
150394
150395
150396
150397
150398
150399
150400
150401
150402
150403
150404
150405
150406
150407
150408
150409
150410
150411
150412
150413
150414
150415
150416
150417
150418
150419
150420
150421
150422
150423
150424
150425
150426
150427
150428
150429
150430
150431
150432
150433
150434
150435
150436
150437
150438
150439
150440
150441
150442
150443
150444
150445
150446
150447
150448
150449
150450
150451
150452
150453
150454
150455
150456
150457
150458
150459
150460
150461
150462
150463
150464
150465
150466
150467
150468
150469
150470
150471
150472
150473
150474
150475
150476
150477
150478
150479
150480
150481
150482
150483
150484
150485
150486
150487
150488
150489
150490
150491
150492
150493
150494
150495
150496
150497
150498
150499
150500
150501
150502
150503
150504
150505
150506
150507
150508
150509
150510
150511
150512
150513
150514
150515
150516
150517
150518
150519
150520
150521
150522
150523
150524
150525
150526
150527
150528
150529
150530
150531
150532
150533
150534
150535
150536
150537
150538
150539
150540
150541
150542
150543
150544
150545
150546
150547
150548
150549
150550
150551
150552
150553
150554
150555
150556
150557
150558
150559
150560
150561
150562
150563
150564
150565
150566
150567
150568
150569
150570
150571
150572
150573
150574
150575
150576
150577
150578
150579
150580
150581
150582
150583
150584
150585
150586
150587
150588
150589
150590
150591
150592
150593
150594
150595
150596
150597
150598
150599
150600
150601
150602
150603
150604
150605
150606
150607
150608
150609
150610
150611
150612
150613
150614
150615
150616
150617
150618
150619
150620
150621
150622
150623
150624
150625
150626
150627
150628
150629
150630
150631
150632
150633
150634
150635
150636
150637
150638
150639
150640
150641
150642
150643
150644
150645
150646
150647
150648
150649
150650
150651
150652
150653
150654
150655
150656
150657
150658
150659
150660
150661
150662
150663
150664
150665
150666
150667
150668
150669
150670
150671
150672
150673
150674
150675
150676
150677
150678
150679
150680
150681
150682
150683
150684
150685
150686
150687
150688
150689
150690
150691
150692
150693
150694
150695
150696
150697
150698
150699
150700
150701
150702
150703
150704
150705
150706
150707
150708
150709
150710
150711
150712
150713
150714
150715
150716
150717
150718
150719
150720
150721
150722
150723
150724
150725
150726
150727
150728
150729
150730
150731
150732
150733
150734
150735
150736
150737
150738
150739
150740
150741
150742
150743
150744
150745
150746
150747
150748
150749
150750
150751
150752
150753
150754
150755
150756
150757
150758
150759
150760
150761
150762
150763
150764
150765
150766
150767
150768
150769
150770
150771
150772
150773
150774
150775
150776
150777
150778
150779
150780
150781
150782
150783
150784
150785
150786
150787
150788
150789
150790
150791
150792
150793
150794
150795
150796
150797
150798
150799
150800
150801
150802
150803
150804
150805
150806
150807
150808
150809
150810
150811
150812
150813
150814
150815
150816
150817
150818
150819
150820
150821
150822
150823
150824
150825
150826
150827
150828
150829
150830
150831
150832
150833
150834
150835
150836
150837
150838
150839
150840
150841
150842
150843
150844
150845
150846
150847
150848
150849
150850
150851
150852
150853
150854
150855
150856
150857
150858
150859
150860
150861
150862
150863
150864
150865
150866
150867
150868
150869
150870
150871
150872
150873
150874
150875
150876
150877
150878
150879
150880
150881
150882
150883
150884
150885
150886
150887
150888
150889
150890
150891
150892
150893
150894
150895
150896
150897
150898
150899
150900
150901
150902
150903
150904
150905
150906
150907
150908
150909
150910
150911
150912
150913
150914
150915
150916
150917
150918
150919
150920
150921
150922
150923
150924
150925
150926
150927
150928
150929
150930
150931
150932
150933
150934
150935
150936
150937
150938
150939
150940
150941
150942
150943
150944
150945
150946
150947
150948
150949
150950
150951
150952
150953
150954
150955
150956
150957
150958
150959
150960
150961
150962
150963
150964
150965
150966
150967
150968
150969
150970
150971
150972
150973
150974
150975
150976
150977
150978
150979
150980
150981
150982
150983
150984
150985
150986
150987
150988
150989
150990
150991
150992
150993
150994
150995
150996
150997
150998
150999
151000
151001
151002
151003
151004
151005
151006
151007
151008
151009
151010
151011
151012
151013
151014
151015
151016
151017
151018
151019
151020
151021
151022
151023
151024
151025
151026
151027
151028
151029
151030
151031
151032
151033
151034
151035
151036
151037
151038
151039
151040
151041
151042
151043
151044
151045
151046
151047
151048
151049
151050
151051
151052
151053
151054
151055
151056
151057
151058
151059
151060
151061
151062
151063
151064
151065
151066
151067
151068
151069
151070
151071
151072
151073
151074
151075
151076
151077
151078
151079
151080
151081
151082
151083
151084
151085
151086
151087
151088
151089
151090
151091
151092
151093
151094
151095
151096
151097
151098
151099
151100
151101
151102
151103
151104
151105
151106
151107
151108
151109
151110
151111
151112
151113
151114
151115
151116
151117
151118
151119
151120
151121
151122
151123
151124
151125
151126
151127
151128
151129
151130
151131
151132
151133
151134
151135
151136
151137
151138
151139
151140
151141
151142
151143
151144
151145
151146
151147
151148
151149
151150
151151
151152
151153
151154
151155
151156
151157
151158
151159
151160
151161
151162
151163
151164
151165
151166
151167
151168
151169
151170
151171
151172
151173
151174
151175
151176
151177
151178
151179
151180
151181
151182
151183
151184
151185
151186
151187
151188
151189
151190
151191
151192
151193
151194
151195
151196
151197
151198
151199
151200
151201
151202
151203
151204
151205
151206
151207
151208
151209
151210
151211
151212
151213
151214
151215
151216
151217
151218
151219
151220
151221
151222
151223
151224
151225
151226
151227
151228
151229
151230
151231
151232
151233
151234
151235
151236
151237
151238
151239
151240
151241
151242
151243
151244
151245
151246
151247
151248
151249
151250
151251
151252
151253
151254
151255
151256
151257
151258
151259
151260
151261
151262
151263
151264
151265
151266
151267
151268
151269
151270
151271
151272
151273
151274
151275
151276
151277
151278
151279
151280
151281
151282
151283
151284
151285
151286
151287
151288
151289
151290
151291
151292
151293
151294
151295
151296
151297
151298
151299
151300
151301
151302
151303
151304
151305
151306
151307
151308
151309
151310
151311
151312
151313
151314
151315
151316
151317
151318
151319
151320
151321
151322
151323
151324
151325
151326
151327
151328
151329
151330
151331
151332
151333
151334
151335
151336
151337
151338
151339
151340
151341
151342
151343
151344
151345
151346
151347
151348
151349
151350
151351
151352
151353
151354
151355
151356
151357
151358
151359
151360
151361
151362
151363
151364
151365
151366
151367
151368
151369
151370
151371
151372
151373
151374
151375
151376
151377
151378
151379
151380
151381
151382
151383
151384
151385
151386
151387
151388
151389
151390
151391
151392
151393
151394
151395
151396
151397
151398
151399
151400
151401
151402
151403
151404
151405
151406
151407
151408
151409
151410
151411
151412
151413
151414
151415
151416
151417
151418
151419
151420
151421
151422
151423
151424
151425
151426
151427
151428
151429
151430
151431
151432
151433
151434
151435
151436
151437
151438
151439
151440
151441
151442
151443
151444
151445
151446
151447
151448
151449
151450
151451
151452
151453
151454
151455
151456
151457
151458
151459
151460
151461
151462
151463
151464
151465
151466
151467
151468
151469
151470
151471
151472
151473
151474
151475
151476
151477
151478
151479
151480
151481
151482
151483
151484
151485
151486
151487
151488
151489
151490
151491
151492
151493
151494
151495
151496
151497
151498
151499
151500
151501
151502
151503
151504
151505
151506
151507
151508
151509
151510
151511
151512
151513
151514
151515
151516
151517
151518
151519
151520
151521
151522
151523
151524
151525
151526
151527
151528
151529
151530
151531
151532
151533
151534
151535
151536
151537
151538
151539
151540
151541
151542
151543
151544
151545
151546
151547
151548
151549
151550
151551
151552
151553
151554
151555
151556
151557
151558
151559
151560
151561
151562
151563
151564
151565
151566
151567
151568
151569
151570
151571
151572
151573
151574
151575
151576
151577
151578
151579
151580
151581
151582
151583
151584
151585
151586
151587
151588
151589
151590
151591
151592
151593
151594
151595
151596
151597
151598
151599
151600
151601
151602
151603
151604
151605
151606
151607
151608
151609
151610
151611
151612
151613
151614
151615
151616
151617
151618
151619
151620
151621
151622
151623
151624
151625
151626
151627
151628
151629
151630
151631
151632
151633
151634
151635
151636
151637
151638
151639
151640
151641
151642
151643
151644
151645
151646
151647
151648
151649
151650
151651
151652
151653
151654
151655
151656
151657
151658
151659
151660
151661
151662
151663
151664
151665
151666
151667
151668
151669
151670
151671
151672
151673
151674
151675
151676
151677
151678
151679
151680
151681
151682
151683
151684
151685
151686
151687
151688
151689
151690
151691
151692
151693
151694
151695
151696
151697
151698
151699
151700
151701
151702
151703
151704
151705
151706
151707
151708
151709
151710
151711
151712
151713
151714
151715
151716
151717
151718
151719
151720
151721
151722
151723
151724
151725
151726
151727
151728
151729
151730
151731
151732
151733
151734
151735
151736
151737
151738
151739
151740
151741
151742
151743
151744
151745
151746
151747
151748
151749
151750
151751
151752
151753
151754
151755
151756
151757
151758
151759
151760
151761
151762
151763
151764
151765
151766
151767
151768
151769
151770
151771
151772
151773
151774
151775
151776
151777
151778
151779
151780
151781
151782
151783
151784
151785
151786
151787
151788
151789
151790
151791
151792
151793
151794
151795
151796
151797
151798
151799
151800
151801
151802
151803
151804
151805
151806
151807
151808
151809
151810
151811
151812
151813
151814
151815
151816
151817
151818
151819
151820
151821
151822
151823
151824
151825
151826
151827
151828
151829
151830
151831
151832
151833
151834
151835
151836
151837
151838
151839
151840
151841
151842
151843
151844
151845
151846
151847
151848
151849
151850
151851
151852
151853
151854
151855
151856
151857
151858
151859
151860
151861
151862
151863
151864
151865
151866
151867
151868
151869
151870
151871
151872
151873
151874
151875
151876
151877
151878
151879
151880
151881
151882
151883
151884
151885
151886
151887
151888
151889
151890
151891
151892
151893
151894
151895
151896
151897
151898
151899
151900
151901
151902
151903
151904
151905
151906
151907
151908
151909
151910
151911
151912
151913
151914
151915
151916
151917
151918
151919
151920
151921
151922
151923
151924
151925
151926
151927
151928
151929
151930
151931
151932
151933
151934
151935
151936
151937
151938
151939
151940
151941
151942
151943
151944
151945
151946
151947
151948
151949
151950
151951
151952
151953
151954
151955
151956
151957
151958
151959
151960
151961
151962
151963
151964
151965
151966
151967
151968
151969
151970
151971
151972
151973
151974
151975
151976
151977
151978
151979
151980
151981
151982
151983
151984
151985
151986
151987
151988
151989
151990
151991
151992
151993
151994
151995
151996
151997
151998
151999
152000
152001
152002
152003
152004
152005
152006
152007
152008
152009
152010
152011
152012
152013
152014
152015
152016
152017
152018
152019
152020
152021
152022
152023
152024
152025
152026
152027
152028
152029
152030
152031
152032
152033
152034
152035
152036
152037
152038
152039
152040
152041
152042
152043
152044
152045
152046
152047
152048
152049
152050
152051
152052
152053
152054
152055
152056
152057
152058
152059
152060
152061
152062
152063
152064
152065
152066
152067
152068
152069
152070
152071
152072
152073
152074
152075
152076
152077
152078
152079
152080
152081
152082
152083
152084
152085
152086
152087
152088
152089
152090
152091
152092
152093
152094
152095
152096
152097
152098
152099
152100
152101
152102
152103
152104
152105
152106
152107
152108
152109
152110
152111
152112
152113
152114
152115
152116
152117
152118
152119
152120
152121
152122
152123
152124
152125
152126
152127
152128
152129
152130
152131
152132
152133
152134
152135
152136
152137
152138
152139
152140
152141
152142
152143
152144
152145
152146
152147
152148
152149
152150
152151
152152
152153
152154
152155
152156
152157
152158
152159
152160
152161
152162
152163
152164
152165
152166
152167
152168
152169
152170
152171
152172
152173
152174
152175
152176
152177
152178
152179
152180
152181
152182
152183
152184
152185
152186
152187
152188
152189
152190
152191
152192
152193
152194
152195
152196
152197
152198
152199
152200
152201
152202
152203
152204
152205
152206
152207
152208
152209
152210
152211
152212
152213
152214
152215
152216
152217
152218
152219
152220
152221
152222
152223
152224
152225
152226
152227
152228
152229
152230
152231
152232
152233
152234
152235
152236
152237
152238
152239
152240
152241
152242
152243
152244
152245
152246
152247
152248
152249
152250
152251
152252
152253
152254
152255
152256
152257
152258
152259
152260
152261
152262
152263
152264
152265
152266
152267
152268
152269
152270
152271
152272
152273
152274
152275
152276
152277
152278
152279
152280
152281
152282
152283
152284
152285
152286
152287
152288
152289
152290
152291
152292
152293
152294
152295
152296
152297
152298
152299
152300
152301
152302
152303
152304
152305
152306
152307
152308
152309
152310
152311
152312
152313
152314
152315
152316
152317
152318
152319
152320
152321
152322
152323
152324
152325
152326
152327
152328
152329
152330
152331
152332
152333
152334
152335
152336
152337
152338
152339
152340
152341
152342
152343
152344
152345
152346
152347
152348
152349
152350
152351
152352
152353
152354
152355
152356
152357
152358
152359
152360
152361
152362
152363
152364
152365
152366
152367
152368
152369
152370
152371
152372
152373
152374
152375
152376
152377
152378
152379
152380
152381
152382
152383
152384
152385
152386
152387
152388
152389
152390
152391
152392
152393
152394
152395
152396
152397
152398
152399
152400
152401
152402
152403
152404
152405
152406
152407
152408
152409
152410
152411
152412
152413
152414
152415
152416
152417
152418
152419
152420
152421
152422
152423
152424
152425
152426
152427
152428
152429
152430
152431
152432
152433
152434
152435
152436
152437
152438
152439
152440
152441
152442
152443
152444
152445
152446
152447
152448
152449
152450
152451
152452
152453
152454
152455
152456
152457
152458
152459
152460
152461
152462
152463
152464
152465
152466
152467
152468
152469
152470
152471
152472
152473
152474
152475
152476
152477
152478
152479
152480
152481
152482
152483
152484
152485
152486
152487
152488
152489
152490
152491
152492
152493
152494
152495
152496
152497
152498
152499
152500
152501
152502
152503
152504
152505
152506
152507
152508
152509
152510
152511
152512
152513
152514
152515
152516
152517
152518
152519
152520
152521
152522
152523
152524
152525
152526
152527
152528
152529
152530
152531
152532
152533
152534
152535
152536
152537
152538
152539
152540
152541
152542
152543
152544
152545
152546
152547
152548
152549
152550
152551
152552
152553
152554
152555
152556
152557
152558
152559
152560
152561
152562
152563
152564
152565
152566
152567
152568
152569
152570
152571
152572
152573
152574
152575
152576
152577
152578
152579
152580
152581
152582
152583
152584
152585
152586
152587
152588
152589
152590
152591
152592
152593
152594
152595
152596
152597
152598
152599
152600
152601
152602
152603
152604
152605
152606
152607
152608
152609
152610
152611
152612
152613
152614
152615
152616
152617
152618
152619
152620
152621
152622
152623
152624
152625
152626
152627
152628
152629
152630
152631
152632
152633
152634
152635
152636
152637
152638
152639
152640
152641
152642
152643
152644
152645
152646
152647
152648
152649
152650
152651
152652
152653
152654
152655
152656
152657
152658
152659
152660
152661
152662
152663
152664
152665
152666
152667
152668
152669
152670
152671
152672
152673
152674
152675
152676
152677
152678
152679
152680
152681
152682
152683
152684
152685
152686
152687
152688
152689
152690
152691
152692
152693
152694
152695
152696
152697
152698
152699
152700
152701
152702
152703
152704
152705
152706
152707
152708
152709
152710
152711
152712
152713
152714
152715
152716
152717
152718
152719
152720
152721
152722
152723
152724
152725
152726
152727
152728
152729
152730
152731
152732
152733
152734
152735
152736
152737
152738
152739
152740
152741
152742
152743
152744
152745
152746
152747
152748
152749
152750
152751
152752
152753
152754
152755
152756
152757
152758
152759
152760
152761
152762
152763
152764
152765
152766
152767
152768
152769
152770
152771
152772
152773
152774
152775
152776
152777
152778
152779
152780
152781
152782
152783
152784
152785
152786
152787
152788
152789
152790
152791
152792
152793
152794
152795
152796
152797
152798
152799
152800
152801
152802
152803
152804
152805
152806
152807
152808
152809
152810
152811
152812
152813
152814
152815
152816
152817
152818
152819
152820
152821
152822
152823
152824
152825
152826
152827
152828
152829
152830
152831
152832
152833
152834
152835
152836
152837
152838
152839
152840
152841
152842
152843
152844
152845
152846
152847
152848
152849
152850
152851
152852
152853
152854
152855
152856
152857
152858
152859
152860
152861
152862
152863
152864
152865
152866
152867
152868
152869
152870
152871
152872
152873
152874
152875
152876
152877
152878
152879
152880
152881
152882
152883
152884
152885
152886
152887
152888
152889
152890
152891
152892
152893
152894
152895
152896
152897
152898
152899
152900
152901
152902
152903
152904
152905
152906
152907
152908
152909
152910
152911
152912
152913
152914
152915
152916
152917
152918
152919
152920
152921
152922
152923
152924
152925
152926
152927
152928
152929
152930
152931
152932
152933
152934
152935
152936
152937
152938
152939
152940
152941
152942
152943
152944
152945
152946
152947
152948
152949
152950
152951
152952
152953
152954
152955
152956
152957
152958
152959
152960
152961
152962
152963
152964
152965
152966
152967
152968
152969
152970
152971
152972
152973
152974
152975
152976
152977
152978
152979
152980
152981
152982
152983
152984
152985
152986
152987
152988
152989
152990
152991
152992
152993
152994
152995
152996
152997
152998
152999
153000
153001
153002
153003
153004
153005
153006
153007
153008
153009
153010
153011
153012
153013
153014
153015
153016
153017
153018
153019
153020
153021
153022
153023
153024
153025
153026
153027
153028
153029
153030
153031
153032
153033
153034
153035
153036
153037
153038
153039
153040
153041
153042
153043
153044
153045
153046
153047
153048
153049
153050
153051
153052
153053
153054
153055
153056
153057
153058
153059
153060
153061
153062
153063
153064
153065
153066
153067
153068
153069
153070
153071
153072
153073
153074
153075
153076
153077
153078
153079
153080
153081
153082
153083
153084
153085
153086
153087
153088
153089
153090
153091
153092
153093
153094
153095
153096
153097
153098
153099
153100
153101
153102
153103
153104
153105
153106
153107
153108
153109
153110
153111
153112
153113
153114
153115
153116
153117
153118
153119
153120
153121
153122
153123
153124
153125
153126
153127
153128
153129
153130
153131
153132
153133
153134
153135
153136
153137
153138
153139
153140
153141
153142
153143
153144
153145
153146
153147
153148
153149
153150
153151
153152
153153
153154
153155
153156
153157
153158
153159
153160
153161
153162
153163
153164
153165
153166
153167
153168
153169
153170
153171
153172
153173
153174
153175
153176
153177
153178
153179
153180
153181
153182
153183
153184
153185
153186
153187
153188
153189
153190
153191
153192
153193
153194
153195
153196
153197
153198
153199
153200
153201
153202
153203
153204
153205
153206
153207
153208
153209
153210
153211
153212
153213
153214
153215
153216
153217
153218
153219
153220
153221
153222
153223
153224
153225
153226
153227
153228
153229
153230
153231
153232
153233
153234
153235
153236
153237
153238
153239
153240
153241
153242
153243
153244
153245
153246
153247
153248
153249
153250
153251
153252
153253
153254
153255
153256
153257
153258
153259
153260
153261
153262
153263
153264
153265
153266
153267
153268
153269
153270
153271
153272
153273
153274
153275
153276
153277
153278
153279
153280
153281
153282
153283
153284
153285
153286
153287
153288
153289
153290
153291
153292
153293
153294
153295
153296
153297
153298
153299
153300
153301
153302
153303
153304
153305
153306
153307
153308
153309
153310
153311
153312
153313
153314
153315
153316
153317
153318
153319
153320
153321
153322
153323
153324
153325
153326
153327
153328
153329
153330
153331
153332
153333
153334
153335
153336
153337
153338
153339
153340
153341
153342
153343
153344
153345
153346
153347
153348
153349
153350
153351
153352
153353
153354
153355
153356
153357
153358
153359
153360
153361
153362
153363
153364
153365
153366
153367
153368
153369
153370
153371
153372
153373
153374
153375
153376
153377
153378
153379
153380
153381
153382
153383
153384
153385
153386
153387
153388
153389
153390
153391
153392
153393
153394
153395
153396
153397
153398
153399
153400
153401
153402
153403
153404
153405
153406
153407
153408
153409
153410
153411
153412
153413
153414
153415
153416
153417
153418
153419
153420
153421
153422
153423
153424
153425
153426
153427
153428
153429
153430
153431
153432
153433
153434
153435
153436
153437
153438
153439
153440
153441
153442
153443
153444
153445
153446
153447
153448
153449
153450
153451
153452
153453
153454
153455
153456
153457
153458
153459
153460
153461
153462
153463
153464
153465
153466
153467
153468
153469
153470
153471
153472
153473
153474
153475
153476
153477
153478
153479
153480
153481
153482
153483
153484
153485
153486
153487
153488
153489
153490
153491
153492
153493
153494
153495
153496
153497
153498
153499
153500
153501
153502
153503
153504
153505
153506
153507
153508
153509
153510
153511
153512
153513
153514
153515
153516
153517
153518
153519
153520
153521
153522
153523
153524
153525
153526
153527
153528
153529
153530
153531
153532
153533
153534
153535
153536
153537
153538
153539
153540
153541
153542
153543
153544
153545
153546
153547
153548
153549
153550
153551
153552
153553
153554
153555
153556
153557
153558
153559
153560
153561
153562
153563
153564
153565
153566
153567
153568
153569
153570
153571
153572
153573
153574
153575
153576
153577
153578
153579
153580
153581
153582
153583
153584
153585
153586
153587
153588
153589
153590
153591
153592
153593
153594
153595
153596
153597
153598
153599
153600
153601
153602
153603
153604
153605
153606
153607
153608
153609
153610
153611
153612
153613
153614
153615
153616
153617
153618
153619
153620
153621
153622
153623
153624
153625
153626
153627
153628
153629
153630
153631
153632
153633
153634
153635
153636
153637
153638
153639
153640
153641
153642
153643
153644
153645
153646
153647
153648
153649
153650
153651
153652
153653
153654
153655
153656
153657
153658
153659
153660
153661
153662
153663
153664
153665
153666
153667
153668
153669
153670
153671
153672
153673
153674
153675
153676
153677
153678
153679
153680
153681
153682
153683
153684
153685
153686
153687
153688
153689
153690
153691
153692
153693
153694
153695
153696
153697
153698
153699
153700
153701
153702
153703
153704
153705
153706
153707
153708
153709
153710
153711
153712
153713
153714
153715
153716
153717
153718
153719
153720
153721
153722
153723
153724
153725
153726
153727
153728
153729
153730
153731
153732
153733
153734
153735
153736
153737
153738
153739
153740
153741
153742
153743
153744
153745
153746
153747
153748
153749
153750
153751
153752
153753
153754
153755
153756
153757
153758
153759
153760
153761
153762
153763
153764
153765
153766
153767
153768
153769
153770
153771
153772
153773
153774
153775
153776
153777
153778
153779
153780
153781
153782
153783
153784
153785
153786
153787
153788
153789
153790
153791
153792
153793
153794
153795
153796
153797
153798
153799
153800
153801
153802
153803
153804
153805
153806
153807
153808
153809
153810
153811
153812
153813
153814
153815
153816
153817
153818
153819
153820
153821
153822
153823
153824
153825
153826
153827
153828
153829
153830
153831
153832
153833
153834
153835
153836
153837
153838
153839
153840
153841
153842
153843
153844
153845
153846
153847
153848
153849
153850
153851
153852
153853
153854
153855
153856
153857
153858
153859
153860
153861
153862
153863
153864
153865
153866
153867
153868
153869
153870
153871
153872
153873
153874
153875
153876
153877
153878
153879
153880
153881
153882
153883
153884
153885
153886
153887
153888
153889
153890
153891
153892
153893
153894
153895
153896
153897
153898
153899
153900
153901
153902
153903
153904
153905
153906
153907
153908
153909
153910
153911
153912
153913
153914
153915
153916
153917
153918
153919
153920
153921
153922
153923
153924
153925
153926
153927
153928
153929
153930
153931
153932
153933
153934
153935
153936
153937
153938
153939
153940
153941
153942
153943
153944
153945
153946
153947
153948
153949
153950
153951
153952
153953
153954
153955
153956
153957
153958
153959
153960
153961
153962
153963
153964
153965
153966
153967
153968
153969
153970
153971
153972
153973
153974
153975
153976
153977
153978
153979
153980
153981
153982
153983
153984
153985
153986
153987
153988
153989
153990
153991
153992
153993
153994
153995
153996
153997
153998
153999
154000
154001
154002
154003
154004
154005
154006
154007
154008
154009
154010
154011
154012
154013
154014
154015
154016
154017
154018
154019
154020
154021
154022
154023
154024
154025
154026
154027
154028
154029
154030
154031
154032
154033
154034
154035
154036
154037
154038
154039
154040
154041
154042
154043
154044
154045
154046
154047
154048
154049
154050
154051
154052
154053
154054
154055
154056
154057
154058
154059
154060
154061
154062
154063
154064
154065
154066
154067
154068
154069
154070
154071
154072
154073
154074
154075
154076
154077
154078
154079
154080
154081
154082
154083
154084
154085
154086
154087
154088
154089
154090
154091
154092
154093
154094
154095
154096
154097
154098
154099
154100
154101
154102
154103
154104
154105
154106
154107
154108
154109
154110
154111
154112
154113
154114
154115
154116
154117
154118
154119
154120
154121
154122
154123
154124
154125
154126
154127
154128
154129
154130
154131
154132
154133
154134
154135
154136
154137
154138
154139
154140
154141
154142
154143
154144
154145
154146
154147
154148
154149
154150
154151
154152
154153
154154
154155
154156
154157
154158
154159
154160
154161
154162
154163
154164
154165
154166
154167
154168
154169
154170
154171
154172
154173
154174
154175
154176
154177
154178
154179
154180
154181
154182
154183
154184
154185
154186
154187
154188
154189
154190
154191
154192
154193
154194
154195
154196
154197
154198
154199
154200
154201
154202
154203
154204
154205
154206
154207
154208
154209
154210
154211
154212
154213
154214
154215
154216
154217
154218
154219
154220
154221
154222
154223
154224
154225
154226
154227
154228
154229
154230
154231
154232
154233
154234
154235
154236
154237
154238
154239
154240
154241
154242
154243
154244
154245
154246
154247
154248
154249
154250
154251
154252
154253
154254
154255
154256
154257
154258
154259
154260
154261
154262
154263
154264
154265
154266
154267
154268
154269
154270
154271
154272
154273
154274
154275
154276
154277
154278
154279
154280
154281
154282
154283
154284
154285
154286
154287
154288
154289
154290
154291
154292
154293
154294
154295
154296
154297
154298
154299
154300
154301
154302
154303
154304
154305
154306
154307
154308
154309
154310
154311
154312
154313
154314
154315
154316
154317
154318
154319
154320
154321
154322
154323
154324
154325
154326
154327
154328
154329
154330
154331
154332
154333
154334
154335
154336
154337
154338
154339
154340
154341
154342
154343
154344
154345
154346
154347
154348
154349
154350
154351
154352
154353
154354
154355
154356
154357
154358
154359
154360
154361
154362
154363
154364
154365
154366
154367
154368
154369
154370
154371
154372
154373
154374
154375
154376
154377
154378
154379
154380
154381
154382
154383
154384
154385
154386
154387
154388
154389
154390
154391
154392
154393
154394
154395
154396
154397
154398
154399
154400
154401
154402
154403
154404
154405
154406
154407
154408
154409
154410
154411
154412
154413
154414
154415
154416
154417
154418
154419
154420
154421
154422
154423
154424
154425
154426
154427
154428
154429
154430
154431
154432
154433
154434
154435
154436
154437
154438
154439
154440
154441
154442
154443
154444
154445
154446
154447
154448
154449
154450
154451
154452
154453
154454
154455
154456
154457
154458
154459
154460
154461
154462
154463
154464
154465
154466
154467
154468
154469
154470
154471
154472
154473
154474
154475
154476
154477
154478
154479
154480
154481
154482
154483
154484
154485
154486
154487
154488
154489
154490
154491
154492
154493
154494
154495
154496
154497
154498
154499
154500
154501
154502
154503
154504
154505
154506
154507
154508
154509
154510
154511
154512
154513
154514
154515
154516
154517
154518
154519
154520
154521
154522
154523
154524
154525
154526
154527
154528
154529
154530
154531
154532
154533
154534
154535
154536
154537
154538
154539
154540
154541
154542
154543
154544
154545
154546
154547
154548
154549
154550
154551
154552
154553
154554
154555
154556
154557
154558
154559
154560
154561
154562
154563
154564
154565
154566
154567
154568
154569
154570
154571
154572
154573
154574
154575
154576
154577
154578
154579
154580
154581
154582
154583
154584
154585
154586
154587
154588
154589
154590
154591
154592
154593
154594
154595
154596
154597
154598
154599
154600
154601
154602
154603
154604
154605
154606
154607
154608
154609
154610
154611
154612
154613
154614
154615
154616
154617
154618
154619
154620
154621
154622
154623
154624
154625
154626
154627
154628
154629
154630
154631
154632
154633
154634
154635
154636
154637
154638
154639
154640
154641
154642
154643
154644
154645
154646
154647
154648
154649
154650
154651
154652
154653
154654
154655
154656
154657
154658
154659
154660
154661
154662
154663
154664
154665
154666
154667
154668
154669
154670
154671
154672
154673
154674
154675
154676
154677
154678
154679
154680
154681
154682
154683
154684
154685
154686
154687
154688
154689
154690
154691
154692
154693
154694
154695
154696
154697
154698
154699
154700
154701
154702
154703
154704
154705
154706
154707
154708
154709
154710
154711
154712
154713
154714
154715
154716
154717
154718
154719
154720
154721
154722
154723
154724
154725
154726
154727
154728
154729
154730
154731
154732
154733
154734
154735
154736
154737
154738
154739
154740
154741
154742
154743
154744
154745
154746
154747
154748
154749
154750
154751
154752
154753
154754
154755
154756
154757
154758
154759
154760
154761
154762
154763
154764
154765
154766
154767
154768
154769
154770
154771
154772
154773
154774
154775
154776
154777
154778
154779
154780
154781
154782
154783
154784
154785
154786
154787
154788
154789
154790
154791
154792
154793
154794
154795
154796
154797
154798
154799
154800
154801
154802
154803
154804
154805
154806
154807
154808
154809
154810
154811
154812
154813
154814
154815
154816
154817
154818
154819
154820
154821
154822
154823
154824
154825
154826
154827
154828
154829
154830
154831
154832
154833
154834
154835
154836
154837
154838
154839
154840
154841
154842
154843
154844
154845
154846
154847
154848
154849
154850
154851
154852
154853
154854
154855
154856
154857
154858
154859
154860
154861
154862
154863
154864
154865
154866
154867
154868
154869
154870
154871
154872
154873
154874
154875
154876
154877
154878
154879
154880
154881
154882
154883
154884
154885
154886
154887
154888
154889
154890
154891
154892
154893
154894
154895
154896
154897
154898
154899
154900
154901
154902
154903
154904
154905
154906
154907
154908
154909
154910
154911
154912
154913
154914
154915
154916
154917
154918
154919
154920
154921
154922
154923
154924
154925
154926
154927
154928
154929
154930
154931
154932
154933
154934
154935
154936
154937
154938
154939
154940
154941
154942
154943
154944
154945
154946
154947
154948
154949
154950
154951
154952
154953
154954
154955
154956
154957
154958
154959
154960
154961
154962
154963
154964
154965
154966
154967
154968
154969
154970
154971
154972
154973
154974
154975
154976
154977
154978
154979
154980
154981
154982
154983
154984
154985
154986
154987
154988
154989
154990
154991
154992
154993
154994
154995
154996
154997
154998
154999
155000
155001
155002
155003
155004
155005
155006
155007
155008
155009
155010
155011
155012
155013
155014
155015
155016
155017
155018
155019
155020
155021
155022
155023
155024
155025
155026
155027
155028
155029
155030
155031
155032
155033
155034
155035
155036
155037
155038
155039
155040
155041
155042
155043
155044
155045
155046
155047
155048
155049
155050
155051
155052
155053
155054
155055
155056
155057
155058
155059
155060
155061
155062
155063
155064
155065
155066
155067
155068
155069
155070
155071
155072
155073
155074
155075
155076
155077
155078
155079
155080
155081
155082
155083
155084
155085
155086
155087
155088
155089
155090
155091
155092
155093
155094
155095
155096
155097
155098
155099
155100
155101
155102
155103
155104
155105
155106
155107
155108
155109
155110
155111
155112
155113
155114
155115
155116
155117
155118
155119
155120
155121
155122
155123
155124
155125
155126
155127
155128
155129
155130
155131
155132
155133
155134
155135
155136
155137
155138
155139
155140
155141
155142
155143
155144
155145
155146
155147
155148
155149
155150
155151
155152
155153
155154
155155
155156
155157
155158
155159
155160
155161
155162
155163
155164
155165
155166
155167
155168
155169
155170
155171
155172
155173
155174
155175
155176
155177
155178
155179
155180
155181
155182
155183
155184
155185
155186
155187
155188
155189
155190
155191
155192
155193
155194
155195
155196
155197
155198
155199
155200
155201
155202
155203
155204
155205
155206
155207
155208
155209
155210
155211
155212
155213
155214
155215
155216
155217
155218
155219
155220
155221
155222
155223
155224
155225
155226
155227
155228
155229
155230
155231
155232
155233
155234
155235
155236
155237
155238
155239
155240
155241
155242
155243
155244
155245
155246
155247
155248
155249
155250
155251
155252
155253
155254
155255
155256
155257
155258
155259
155260
155261
155262
155263
155264
155265
155266
155267
155268
155269
155270
155271
155272
155273
155274
155275
155276
155277
155278
155279
155280
155281
155282
155283
155284
155285
155286
155287
155288
155289
155290
155291
155292
155293
155294
155295
155296
155297
155298
155299
155300
155301
155302
155303
155304
155305
155306
155307
155308
155309
155310
155311
155312
155313
155314
155315
155316
155317
155318
155319
155320
155321
155322
155323
155324
155325
155326
155327
155328
155329
155330
155331
155332
155333
155334
155335
155336
155337
155338
155339
155340
155341
155342
155343
155344
155345
155346
155347
155348
155349
155350
155351
155352
155353
155354
155355
155356
155357
155358
155359
155360
155361
155362
155363
155364
155365
155366
155367
155368
155369
155370
155371
155372
155373
155374
155375
155376
155377
155378
155379
155380
155381
155382
155383
155384
155385
155386
155387
155388
155389
155390
155391
155392
155393
155394
155395
155396
155397
155398
155399
155400
155401
155402
155403
155404
155405
155406
155407
155408
155409
155410
155411
155412
155413
155414
155415
155416
155417
155418
155419
155420
155421
155422
155423
155424
155425
155426
155427
155428
155429
155430
155431
155432
155433
155434
155435
155436
155437
155438
155439
155440
155441
155442
155443
155444
155445
155446
155447
155448
155449
155450
155451
155452
155453
155454
155455
155456
155457
155458
155459
155460
155461
155462
155463
155464
155465
155466
155467
155468
155469
155470
155471
155472
155473
155474
155475
155476
155477
155478
155479
155480
155481
155482
155483
155484
155485
155486
155487
155488
155489
155490
155491
155492
155493
155494
155495
155496
155497
155498
155499
155500
155501
155502
155503
155504
155505
155506
155507
155508
155509
155510
155511
155512
155513
155514
155515
155516
155517
155518
155519
155520
155521
155522
155523
155524
155525
155526
155527
155528
155529
155530
155531
155532
155533
155534
155535
155536
155537
155538
155539
155540
155541
155542
155543
155544
155545
155546
155547
155548
155549
155550
155551
155552
155553
155554
155555
155556
155557
155558
155559
155560
155561
155562
155563
155564
155565
155566
155567
155568
155569
155570
155571
155572
155573
155574
155575
155576
155577
155578
155579
155580
155581
155582
155583
155584
155585
155586
155587
155588
155589
155590
155591
155592
155593
155594
155595
155596
155597
155598
155599
155600
155601
155602
155603
155604
155605
155606
155607
155608
155609
155610
155611
155612
155613
155614
155615
155616
155617
155618
155619
155620
155621
155622
155623
155624
155625
155626
155627
155628
155629
155630
155631
155632
155633
155634
155635
155636
155637
155638
155639
155640
155641
155642
155643
155644
155645
155646
155647
155648
155649
155650
155651
155652
155653
155654
155655
155656
155657
155658
155659
155660
155661
155662
155663
155664
155665
155666
155667
155668
155669
155670
155671
155672
155673
155674
155675
155676
155677
155678
155679
155680
155681
155682
155683
155684
155685
155686
155687
155688
155689
155690
155691
155692
155693
155694
155695
155696
155697
155698
155699
155700
155701
155702
155703
155704
155705
155706
155707
155708
155709
155710
155711
155712
155713
155714
155715
155716
155717
155718
155719
155720
155721
155722
155723
155724
155725
155726
155727
155728
155729
155730
155731
155732
155733
155734
155735
155736
155737
155738
155739
155740
155741
155742
155743
155744
155745
155746
155747
155748
155749
155750
155751
155752
155753
155754
155755
155756
155757
155758
155759
155760
155761
155762
155763
155764
155765
155766
155767
155768
155769
155770
155771
155772
155773
155774
155775
155776
155777
155778
155779
155780
155781
155782
155783
155784
155785
155786
155787
155788
155789
155790
155791
155792
155793
155794
155795
155796
155797
155798
155799
155800
155801
155802
155803
155804
155805
155806
155807
155808
155809
155810
155811
155812
155813
155814
155815
155816
155817
155818
155819
155820
155821
155822
155823
155824
155825
155826
155827
155828
155829
155830
155831
155832
155833
155834
155835
155836
155837
155838
155839
155840
155841
155842
155843
155844
155845
155846
155847
155848
155849
155850
155851
155852
155853
155854
155855
155856
155857
155858
155859
155860
155861
155862
155863
155864
155865
155866
155867
155868
155869
155870
155871
155872
155873
155874
155875
155876
155877
155878
155879
155880
155881
155882
155883
155884
155885
155886
155887
155888
155889
155890
155891
155892
155893
155894
155895
155896
155897
155898
155899
155900
155901
155902
155903
155904
155905
155906
155907
155908
155909
155910
155911
155912
155913
155914
155915
155916
155917
155918
155919
155920
155921
155922
155923
155924
155925
155926
155927
155928
155929
155930
155931
155932
155933
155934
155935
155936
155937
155938
155939
155940
155941
155942
155943
155944
155945
155946
155947
155948
155949
155950
155951
155952
155953
155954
155955
155956
155957
155958
155959
155960
155961
155962
155963
155964
155965
155966
155967
155968
155969
155970
155971
155972
155973
155974
155975
155976
155977
155978
155979
155980
155981
155982
155983
155984
155985
155986
155987
155988
155989
155990
155991
155992
155993
155994
155995
155996
155997
155998
155999
156000
156001
156002
156003
156004
156005
156006
156007
156008
156009
156010
156011
156012
156013
156014
156015
156016
156017
156018
156019
156020
156021
156022
156023
156024
156025
156026
156027
156028
156029
156030
156031
156032
156033
156034
156035
156036
156037
156038
156039
156040
156041
156042
156043
156044
156045
156046
156047
156048
156049
156050
156051
156052
156053
156054
156055
156056
156057
156058
156059
156060
156061
156062
156063
156064
156065
156066
156067
156068
156069
156070
156071
156072
156073
156074
156075
156076
156077
156078
156079
156080
156081
156082
156083
156084
156085
156086
156087
156088
156089
156090
156091
156092
156093
156094
156095
156096
156097
156098
156099
156100
156101
156102
156103
156104
156105
156106
156107
156108
156109
156110
156111
156112
156113
156114
156115
156116
156117
156118
156119
156120
156121
156122
156123
156124
156125
156126
156127
156128
156129
156130
156131
156132
156133
156134
156135
156136
156137
156138
156139
156140
156141
156142
156143
156144
156145
156146
156147
156148
156149
156150
156151
156152
156153
156154
156155
156156
156157
156158
156159
156160
156161
156162
156163
156164
156165
156166
156167
156168
156169
156170
156171
156172
156173
156174
156175
156176
156177
156178
156179
156180
156181
156182
156183
156184
156185
156186
156187
156188
156189
156190
156191
156192
156193
156194
156195
156196
156197
156198
156199
156200
156201
156202
156203
156204
156205
156206
156207
156208
156209
156210
156211
156212
156213
156214
156215
156216
156217
156218
156219
156220
156221
156222
156223
156224
156225
156226
156227
156228
156229
156230
156231
156232
156233
156234
156235
156236
156237
156238
156239
156240
156241
156242
156243
156244
156245
156246
156247
156248
156249
156250
156251
156252
156253
156254
156255
156256
156257
156258
156259
156260
156261
156262
156263
156264
156265
156266
156267
156268
156269
156270
156271
156272
156273
156274
156275
156276
156277
156278
156279
156280
156281
156282
156283
156284
156285
156286
156287
156288
156289
156290
156291
156292
156293
156294
156295
156296
156297
156298
156299
156300
156301
156302
156303
156304
156305
156306
156307
156308
156309
156310
156311
156312
156313
156314
156315
156316
156317
156318
156319
156320
156321
156322
156323
156324
156325
156326
156327
156328
156329
156330
156331
156332
156333
156334
156335
156336
156337
156338
156339
156340
156341
156342
156343
156344
156345
156346
156347
156348
156349
156350
156351
156352
156353
156354
156355
156356
156357
156358
156359
156360
156361
156362
156363
156364
156365
156366
156367
156368
156369
156370
156371
156372
156373
156374
156375
156376
156377
156378
156379
156380
156381
156382
156383
156384
156385
156386
156387
156388
156389
156390
156391
156392
156393
156394
156395
156396
156397
156398
156399
156400
156401
156402
156403
156404
156405
156406
156407
156408
156409
156410
156411
156412
156413
156414
156415
156416
156417
156418
156419
156420
156421
156422
156423
156424
156425
156426
156427
156428
156429
156430
156431
156432
156433
156434
156435
156436
156437
156438
156439
156440
156441
156442
156443
156444
156445
156446
156447
156448
156449
156450
156451
156452
156453
156454
156455
156456
156457
156458
156459
156460
156461
156462
156463
156464
156465
156466
156467
156468
156469
156470
156471
156472
156473
156474
156475
156476
156477
156478
156479
156480
156481
156482
156483
156484
156485
156486
156487
156488
156489
156490
156491
156492
156493
156494
156495
156496
156497
156498
156499
156500
156501
156502
156503
156504
156505
156506
156507
156508
156509
156510
156511
156512
156513
156514
156515
156516
156517
156518
156519
156520
156521
156522
156523
156524
156525
156526
156527
156528
156529
156530
156531
156532
156533
156534
156535
156536
156537
156538
156539
156540
156541
156542
156543
156544
156545
156546
156547
156548
156549
156550
156551
156552
156553
156554
156555
156556
156557
156558
156559
156560
156561
156562
156563
156564
156565
156566
156567
156568
156569
156570
156571
156572
156573
156574
156575
156576
156577
156578
156579
156580
156581
156582
156583
156584
156585
156586
156587
156588
156589
156590
156591
156592
156593
156594
156595
156596
156597
156598
156599
156600
156601
156602
156603
156604
156605
156606
156607
156608
156609
156610
156611
156612
156613
156614
156615
156616
156617
156618
156619
156620
156621
156622
156623
156624
156625
156626
156627
156628
156629
156630
156631
156632
156633
156634
156635
156636
156637
156638
156639
156640
156641
156642
156643
156644
156645
156646
156647
156648
156649
156650
156651
156652
156653
156654
156655
156656
156657
156658
156659
156660
156661
156662
156663
156664
156665
156666
156667
156668
156669
156670
156671
156672
156673
156674
156675
156676
156677
156678
156679
156680
156681
156682
156683
156684
156685
156686
156687
156688
156689
156690
156691
156692
156693
156694
156695
156696
156697
156698
156699
156700
156701
156702
156703
156704
156705
156706
156707
156708
156709
156710
156711
156712
156713
156714
156715
156716
156717
156718
156719
156720
156721
156722
156723
156724
156725
156726
156727
156728
156729
156730
156731
156732
156733
156734
156735
156736
156737
156738
156739
156740
156741
156742
156743
156744
156745
156746
156747
156748
156749
156750
156751
156752
156753
156754
156755
156756
156757
156758
156759
156760
156761
156762
156763
156764
156765
156766
156767
156768
156769
156770
156771
156772
156773
156774
156775
156776
156777
156778
156779
156780
156781
156782
156783
156784
156785
156786
156787
156788
156789
156790
156791
156792
156793
156794
156795
156796
156797
156798
156799
156800
156801
156802
156803
156804
156805
156806
156807
156808
156809
156810
156811
156812
156813
156814
156815
156816
156817
156818
156819
156820
156821
156822
156823
156824
156825
156826
156827
156828
156829
156830
156831
156832
156833
156834
156835
156836
156837
156838
156839
156840
156841
156842
156843
156844
156845
156846
156847
156848
156849
156850
156851
156852
156853
156854
156855
156856
156857
156858
156859
156860
156861
156862
156863
156864
156865
156866
156867
156868
156869
156870
156871
156872
156873
156874
156875
156876
156877
156878
156879
156880
156881
156882
156883
156884
156885
156886
156887
156888
156889
156890
156891
156892
156893
156894
156895
156896
156897
156898
156899
156900
156901
156902
156903
156904
156905
156906
156907
156908
156909
156910
156911
156912
156913
156914
156915
156916
156917
156918
156919
156920
156921
156922
156923
156924
156925
156926
156927
156928
156929
156930
156931
156932
156933
156934
156935
156936
156937
156938
156939
156940
156941
156942
156943
156944
156945
156946
156947
156948
156949
156950
156951
156952
156953
156954
156955
156956
156957
156958
156959
156960
156961
156962
156963
156964
156965
156966
156967
156968
156969
156970
156971
156972
156973
156974
156975
156976
156977
156978
156979
156980
156981
156982
156983
156984
156985
156986
156987
156988
156989
156990
156991
156992
156993
156994
156995
156996
156997
156998
156999
157000
157001
157002
157003
157004
157005
157006
157007
157008
157009
157010
157011
157012
157013
157014
157015
157016
157017
157018
157019
157020
157021
157022
157023
157024
157025
157026
157027
157028
157029
157030
157031
157032
157033
157034
157035
157036
157037
157038
157039
157040
157041
157042
157043
157044
157045
157046
157047
157048
157049
157050
157051
157052
157053
157054
157055
157056
157057
157058
157059
157060
157061
157062
157063
157064
157065
157066
157067
157068
157069
157070
157071
157072
157073
157074
157075
157076
157077
157078
157079
157080
157081
157082
157083
157084
157085
157086
157087
157088
157089
157090
157091
157092
157093
157094
157095
157096
157097
157098
157099
157100
157101
157102
157103
157104
157105
157106
157107
157108
157109
157110
157111
157112
157113
157114
157115
157116
157117
157118
157119
157120
157121
157122
157123
157124
157125
157126
157127
157128
157129
157130
157131
157132
157133
157134
157135
157136
157137
157138
157139
157140
157141
157142
157143
157144
157145
157146
157147
157148
157149
157150
157151
157152
157153
157154
157155
157156
157157
157158
157159
157160
157161
157162
157163
157164
157165
157166
157167
157168
157169
157170
157171
157172
157173
157174
157175
157176
157177
157178
157179
157180
157181
157182
157183
157184
157185
157186
157187
157188
157189
157190
157191
157192
157193
157194
157195
157196
157197
157198
157199
157200
157201
157202
157203
157204
157205
157206
157207
157208
157209
157210
157211
157212
157213
157214
157215
157216
157217
157218
157219
157220
157221
157222
157223
157224
157225
157226
157227
157228
157229
157230
157231
157232
157233
157234
157235
157236
157237
157238
157239
157240
157241
157242
157243
157244
157245
157246
157247
157248
157249
157250
157251
157252
157253
157254
157255
157256
157257
157258
157259
157260
157261
157262
157263
157264
157265
157266
157267
157268
157269
157270
157271
157272
157273
157274
157275
157276
157277
157278
157279
157280
157281
157282
157283
157284
157285
157286
157287
157288
157289
157290
157291
157292
157293
157294
157295
157296
157297
157298
157299
157300
157301
157302
157303
157304
157305
157306
157307
157308
157309
157310
157311
157312
157313
157314
157315
157316
157317
157318
157319
157320
157321
157322
157323
157324
157325
157326
157327
157328
157329
157330
157331
157332
157333
157334
157335
157336
157337
157338
157339
157340
157341
157342
157343
157344
157345
157346
157347
157348
157349
157350
157351
157352
157353
157354
157355
157356
157357
157358
157359
157360
157361
157362
157363
157364
157365
157366
157367
157368
157369
157370
157371
157372
157373
157374
157375
157376
157377
157378
157379
157380
157381
157382
157383
157384
157385
157386
157387
157388
157389
157390
157391
157392
157393
157394
157395
157396
157397
157398
157399
157400
157401
157402
157403
157404
157405
157406
157407
157408
157409
157410
157411
157412
157413
157414
157415
157416
157417
157418
157419
157420
157421
157422
157423
157424
157425
157426
157427
157428
157429
157430
157431
157432
157433
157434
157435
157436
157437
157438
157439
157440
157441
157442
157443
157444
157445
157446
157447
157448
157449
157450
157451
157452
157453
157454
157455
157456
157457
157458
157459
157460
157461
157462
157463
157464
157465
157466
157467
157468
157469
157470
157471
157472
157473
157474
157475
157476
157477
157478
157479
157480
157481
157482
157483
157484
157485
157486
157487
157488
157489
157490
157491
157492
157493
157494
157495
157496
157497
157498
157499
157500
157501
157502
157503
157504
157505
157506
157507
157508
157509
157510
157511
157512
157513
157514
157515
157516
157517
157518
157519
157520
157521
157522
157523
157524
157525
157526
157527
157528
157529
157530
157531
157532
157533
157534
157535
157536
157537
157538
157539
157540
157541
157542
157543
157544
157545
157546
157547
157548
157549
157550
157551
157552
157553
157554
157555
157556
157557
157558
157559
157560
157561
157562
157563
157564
157565
157566
157567
157568
157569
157570
157571
157572
157573
157574
157575
157576
157577
157578
157579
157580
157581
157582
157583
157584
157585
157586
157587
157588
157589
157590
157591
157592
157593
157594
157595
157596
157597
157598
157599
157600
157601
157602
157603
157604
157605
157606
157607
157608
157609
157610
157611
157612
157613
157614
157615
157616
157617
157618
157619
157620
157621
157622
157623
157624
157625
157626
157627
157628
157629
157630
157631
157632
157633
157634
157635
157636
157637
157638
157639
157640
157641
157642
157643
157644
157645
157646
157647
157648
157649
157650
157651
157652
157653
157654
157655
157656
157657
157658
157659
157660
157661
157662
157663
157664
157665
157666
157667
157668
157669
157670
157671
157672
157673
157674
157675
157676
157677
157678
157679
157680
157681
157682
157683
157684
157685
157686
157687
157688
157689
157690
157691
157692
157693
157694
157695
157696
157697
157698
157699
157700
157701
157702
157703
157704
157705
157706
157707
157708
157709
157710
157711
157712
157713
157714
157715
157716
157717
157718
157719
157720
157721
157722
157723
157724
157725
157726
157727
157728
157729
157730
157731
157732
157733
157734
157735
157736
157737
157738
157739
157740
157741
157742
157743
157744
157745
157746
157747
157748
157749
157750
157751
157752
157753
157754
157755
157756
157757
157758
157759
157760
157761
157762
157763
157764
157765
157766
157767
157768
157769
157770
157771
157772
157773
157774
157775
157776
157777
157778
157779
157780
157781
157782
157783
157784
157785
157786
157787
157788
157789
157790
157791
157792
157793
157794
157795
157796
157797
157798
157799
157800
157801
157802
157803
157804
157805
157806
157807
157808
157809
157810
157811
157812
157813
157814
157815
157816
157817
157818
157819
157820
157821
157822
157823
157824
157825
157826
157827
157828
157829
157830
157831
157832
157833
157834
157835
157836
157837
157838
157839
157840
157841
157842
157843
157844
157845
157846
157847
157848
157849
157850
157851
157852
157853
157854
157855
157856
157857
157858
157859
157860
157861
157862
157863
157864
157865
157866
157867
157868
157869
157870
157871
157872
157873
157874
157875
157876
157877
157878
157879
157880
157881
157882
157883
157884
157885
157886
157887
157888
157889
157890
157891
157892
157893
157894
157895
157896
157897
157898
157899
157900
157901
157902
157903
157904
157905
157906
157907
157908
157909
157910
157911
157912
157913
157914
157915
157916
157917
157918
157919
157920
157921
157922
157923
157924
157925
157926
157927
157928
157929
157930
157931
157932
157933
157934
157935
157936
157937
157938
157939
157940
157941
157942
157943
157944
157945
157946
157947
157948
157949
157950
157951
157952
157953
157954
157955
157956
157957
157958
157959
157960
157961
157962
157963
157964
157965
157966
157967
157968
157969
157970
157971
157972
157973
157974
157975
157976
157977
157978
157979
157980
157981
157982
157983
157984
157985
157986
157987
157988
157989
157990
157991
157992
157993
157994
157995
157996
157997
157998
157999
158000
158001
158002
158003
158004
158005
158006
158007
158008
158009
158010
158011
158012
158013
158014
158015
158016
158017
158018
158019
158020
158021
158022
158023
158024
158025
158026
158027
158028
158029
158030
158031
158032
158033
158034
158035
158036
158037
158038
158039
158040
158041
158042
158043
158044
158045
158046
158047
158048
158049
158050
158051
158052
158053
158054
158055
158056
158057
158058
158059
158060
158061
158062
158063
158064
158065
158066
158067
158068
158069
158070
158071
158072
158073
158074
158075
158076
158077
158078
158079
158080
158081
158082
158083
158084
158085
158086
158087
158088
158089
158090
158091
158092
158093
158094
158095
158096
158097
158098
158099
158100
158101
158102
158103
158104
158105
158106
158107
158108
158109
158110
158111
158112
158113
158114
158115
158116
158117
158118
158119
158120
158121
158122
158123
158124
158125
158126
158127
158128
158129
158130
158131
158132
158133
158134
158135
158136
158137
158138
158139
158140
158141
158142
158143
158144
158145
158146
158147
158148
158149
158150
158151
158152
158153
158154
158155
158156
158157
158158
158159
158160
158161
158162
158163
158164
158165
158166
158167
158168
158169
158170
158171
158172
158173
158174
158175
158176
158177
158178
158179
158180
158181
158182
158183
158184
158185
158186
158187
158188
158189
158190
158191
158192
158193
158194
158195
158196
158197
158198
158199
158200
158201
158202
158203
158204
158205
158206
158207
158208
158209
158210
158211
158212
158213
158214
158215
158216
158217
158218
158219
158220
158221
158222
158223
158224
158225
158226
158227
158228
158229
158230
158231
158232
158233
158234
158235
158236
158237
158238
158239
158240
158241
158242
158243
158244
158245
158246
158247
158248
158249
158250
158251
158252
158253
158254
158255
158256
158257
158258
158259
158260
158261
158262
158263
158264
158265
158266
158267
158268
158269
158270
158271
158272
158273
158274
158275
158276
158277
158278
158279
158280
158281
158282
158283
158284
158285
158286
158287
158288
158289
158290
158291
158292
158293
158294
158295
158296
158297
158298
158299
158300
158301
158302
158303
158304
158305
158306
158307
158308
158309
158310
158311
158312
158313
158314
158315
158316
158317
158318
158319
158320
158321
158322
158323
158324
158325
158326
158327
158328
158329
158330
158331
158332
158333
158334
158335
158336
158337
158338
158339
158340
158341
158342
158343
158344
158345
158346
158347
158348
158349
158350
158351
158352
158353
158354
158355
158356
158357
158358
158359
158360
158361
158362
158363
158364
158365
158366
158367
158368
158369
158370
158371
158372
158373
158374
158375
158376
158377
158378
158379
158380
158381
158382
158383
158384
158385
158386
158387
158388
158389
158390
158391
158392
158393
158394
158395
158396
158397
158398
158399
158400
158401
158402
158403
158404
158405
158406
158407
158408
158409
158410
158411
158412
158413
158414
158415
158416
158417
158418
158419
158420
158421
158422
158423
158424
158425
158426
158427
158428
158429
158430
158431
158432
158433
158434
158435
158436
158437
158438
158439
158440
158441
158442
158443
158444
158445
158446
158447
158448
158449
158450
158451
158452
158453
158454
158455
158456
158457
158458
158459
158460
158461
158462
158463
158464
158465
158466
158467
158468
158469
158470
158471
158472
158473
158474
158475
158476
158477
158478
158479
158480
158481
158482
158483
158484
158485
158486
158487
158488
158489
158490
158491
158492
158493
158494
158495
158496
158497
158498
158499
158500
158501
158502
158503
158504
158505
158506
158507
158508
158509
158510
158511
158512
158513
158514
158515
158516
158517
158518
158519
158520
158521
158522
158523
158524
158525
158526
158527
158528
158529
158530
158531
158532
158533
158534
158535
158536
158537
158538
158539
158540
158541
158542
158543
158544
158545
158546
158547
158548
158549
158550
158551
158552
158553
158554
158555
158556
158557
158558
158559
158560
158561
158562
158563
158564
158565
158566
158567
158568
158569
158570
158571
158572
158573
158574
158575
158576
158577
158578
158579
158580
158581
158582
158583
158584
158585
158586
158587
158588
158589
158590
158591
158592
158593
158594
158595
158596
158597
158598
158599
158600
158601
158602
158603
158604
158605
158606
158607
158608
158609
158610
158611
158612
158613
158614
158615
158616
158617
158618
158619
158620
158621
158622
158623
158624
158625
158626
158627
158628
158629
158630
158631
158632
158633
158634
158635
158636
158637
158638
158639
158640
158641
158642
158643
158644
158645
158646
158647
158648
158649
158650
158651
158652
158653
158654
158655
158656
158657
158658
158659
158660
158661
158662
158663
158664
158665
158666
158667
158668
158669
158670
158671
158672
158673
158674
158675
158676
158677
158678
158679
158680
158681
158682
158683
158684
158685
158686
158687
158688
158689
158690
158691
158692
158693
158694
158695
158696
158697
158698
158699
158700
158701
158702
158703
158704
158705
158706
158707
158708
158709
158710
158711
158712
158713
158714
158715
158716
158717
158718
158719
158720
158721
158722
158723
158724
158725
158726
158727
158728
158729
158730
158731
158732
158733
158734
158735
158736
158737
158738
158739
158740
158741
158742
158743
158744
158745
158746
158747
158748
158749
158750
158751
158752
158753
158754
158755
158756
158757
158758
158759
158760
158761
158762
158763
158764
158765
158766
158767
158768
158769
158770
158771
158772
158773
158774
158775
158776
158777
158778
158779
158780
158781
158782
158783
158784
158785
158786
158787
158788
158789
158790
158791
158792
158793
158794
158795
158796
158797
158798
158799
158800
158801
158802
158803
158804
158805
158806
158807
158808
158809
158810
158811
158812
158813
158814
158815
158816
158817
158818
158819
158820
158821
158822
158823
158824
158825
158826
158827
158828
158829
158830
158831
158832
158833
158834
158835
158836
158837
158838
158839
158840
158841
158842
158843
158844
158845
158846
158847
158848
158849
158850
158851
158852
158853
158854
158855
158856
158857
158858
158859
158860
158861
158862
158863
158864
158865
158866
158867
158868
158869
158870
158871
158872
158873
158874
158875
158876
158877
158878
158879
158880
158881
158882
158883
158884
158885
158886
158887
158888
158889
158890
158891
158892
158893
158894
158895
158896
158897
158898
158899
158900
158901
158902
158903
158904
158905
158906
158907
158908
158909
158910
158911
158912
158913
158914
158915
158916
158917
158918
158919
158920
158921
158922
158923
158924
158925
158926
158927
158928
158929
158930
158931
158932
158933
158934
158935
158936
158937
158938
158939
158940
158941
158942
158943
158944
158945
158946
158947
158948
158949
158950
158951
158952
158953
158954
158955
158956
158957
158958
158959
158960
158961
158962
158963
158964
158965
158966
158967
158968
158969
158970
158971
158972
158973
158974
158975
158976
158977
158978
158979
158980
158981
158982
158983
158984
158985
158986
158987
158988
158989
158990
158991
158992
158993
158994
158995
158996
158997
158998
158999
159000
159001
159002
159003
159004
159005
159006
159007
159008
159009
159010
159011
159012
159013
159014
159015
159016
159017
159018
159019
159020
159021
159022
159023
159024
159025
159026
159027
159028
159029
159030
159031
159032
159033
159034
159035
159036
159037
159038
159039
159040
159041
159042
159043
159044
159045
159046
159047
159048
159049
159050
159051
159052
159053
159054
159055
159056
159057
159058
159059
159060
159061
159062
159063
159064
159065
159066
159067
159068
159069
159070
159071
159072
159073
159074
159075
159076
159077
159078
159079
159080
159081
159082
159083
159084
159085
159086
159087
159088
159089
159090
159091
159092
159093
159094
159095
159096
159097
159098
159099
159100
159101
159102
159103
159104
159105
159106
159107
159108
159109
159110
159111
159112
159113
159114
159115
159116
159117
159118
159119
159120
159121
159122
159123
159124
159125
159126
159127
159128
159129
159130
159131
159132
159133
159134
159135
159136
159137
159138
159139
159140
159141
159142
159143
159144
159145
159146
159147
159148
159149
159150
159151
159152
159153
159154
159155
159156
159157
159158
159159
159160
159161
159162
159163
159164
159165
159166
159167
159168
159169
159170
159171
159172
159173
159174
159175
159176
159177
159178
159179
159180
159181
159182
159183
159184
159185
159186
159187
159188
159189
159190
159191
159192
159193
159194
159195
159196
159197
159198
159199
159200
159201
159202
159203
159204
159205
159206
159207
159208
159209
159210
159211
159212
159213
159214
159215
159216
159217
159218
159219
159220
159221
159222
159223
159224
159225
159226
159227
159228
159229
159230
159231
159232
159233
159234
159235
159236
159237
159238
159239
159240
159241
159242
159243
159244
159245
159246
159247
159248
159249
159250
159251
159252
159253
159254
159255
159256
159257
159258
159259
159260
159261
159262
159263
159264
159265
159266
159267
159268
159269
159270
159271
159272
159273
159274
159275
159276
159277
159278
159279
159280
159281
159282
159283
159284
159285
159286
159287
159288
159289
159290
159291
159292
159293
159294
159295
159296
159297
159298
159299
159300
159301
159302
159303
159304
159305
159306
159307
159308
159309
159310
159311
159312
159313
159314
159315
159316
159317
159318
159319
159320
159321
159322
159323
159324
159325
159326
159327
159328
159329
159330
159331
159332
159333
159334
159335
159336
159337
159338
159339
159340
159341
159342
159343
159344
159345
159346
159347
159348
159349
159350
159351
159352
159353
159354
159355
159356
159357
159358
159359
159360
159361
159362
159363
159364
159365
159366
159367
159368
159369
159370
159371
159372
159373
159374
159375
159376
159377
159378
159379
159380
159381
159382
159383
159384
159385
159386
159387
159388
159389
159390
159391
159392
159393
159394
159395
159396
159397
159398
159399
159400
159401
159402
159403
159404
159405
159406
159407
159408
159409
159410
159411
159412
159413
159414
159415
159416
159417
159418
159419
159420
159421
159422
159423
159424
159425
159426
159427
159428
159429
159430
159431
159432
159433
159434
159435
159436
159437
159438
159439
159440
159441
159442
159443
159444
159445
159446
159447
159448
159449
159450
159451
159452
159453
159454
159455
159456
159457
159458
159459
159460
159461
159462
159463
159464
159465
159466
159467
159468
159469
159470
159471
159472
159473
159474
159475
159476
159477
159478
159479
159480
159481
159482
159483
159484
159485
159486
159487
159488
159489
159490
159491
159492
159493
159494
159495
159496
159497
159498
159499
159500
159501
159502
159503
159504
159505
159506
159507
159508
159509
159510
159511
159512
159513
159514
159515
159516
159517
159518
159519
159520
159521
159522
159523
159524
159525
159526
159527
159528
159529
159530
159531
159532
159533
159534
159535
159536
159537
159538
159539
159540
159541
159542
159543
159544
159545
159546
159547
159548
159549
159550
159551
159552
159553
159554
159555
159556
159557
159558
159559
159560
159561
159562
159563
159564
159565
159566
159567
159568
159569
159570
159571
159572
159573
159574
159575
159576
159577
159578
159579
159580
159581
159582
159583
159584
159585
159586
159587
159588
159589
159590
159591
159592
159593
159594
159595
159596
159597
159598
159599
159600
159601
159602
159603
159604
159605
159606
159607
159608
159609
159610
159611
159612
159613
159614
159615
159616
159617
159618
159619
159620
159621
159622
159623
159624
159625
159626
159627
159628
159629
159630
159631
159632
159633
159634
159635
159636
159637
159638
159639
159640
159641
159642
159643
159644
159645
159646
159647
159648
159649
159650
159651
159652
159653
159654
159655
159656
159657
159658
159659
159660
159661
159662
159663
159664
159665
159666
159667
159668
159669
159670
159671
159672
159673
159674
159675
159676
159677
159678
159679
159680
159681
159682
159683
159684
159685
159686
159687
159688
159689
159690
159691
159692
159693
159694
159695
159696
159697
159698
159699
159700
159701
159702
159703
159704
159705
159706
159707
159708
159709
159710
159711
159712
159713
159714
159715
159716
159717
159718
159719
159720
159721
159722
159723
159724
159725
159726
159727
159728
159729
159730
159731
159732
159733
159734
159735
159736
159737
159738
159739
159740
159741
159742
159743
159744
159745
159746
159747
159748
159749
159750
159751
159752
159753
159754
159755
159756
159757
159758
159759
159760
159761
159762
159763
159764
159765
159766
159767
159768
159769
159770
159771
159772
159773
159774
159775
159776
159777
159778
159779
159780
159781
159782
159783
159784
159785
159786
159787
159788
159789
159790
159791
159792
159793
159794
159795
159796
159797
159798
159799
159800
159801
159802
159803
159804
159805
159806
159807
159808
159809
159810
159811
159812
159813
159814
159815
159816
159817
159818
159819
159820
159821
159822
159823
159824
159825
159826
159827
159828
159829
159830
159831
159832
159833
159834
159835
159836
159837
159838
159839
159840
159841
159842
159843
159844
159845
159846
159847
159848
159849
159850
159851
159852
159853
159854
159855
159856
159857
159858
159859
159860
159861
159862
159863
159864
159865
159866
159867
159868
159869
159870
159871
159872
159873
159874
159875
159876
159877
159878
159879
159880
159881
159882
159883
159884
159885
159886
159887
159888
159889
159890
159891
159892
159893
159894
159895
159896
159897
159898
159899
159900
159901
159902
159903
159904
159905
159906
159907
159908
159909
159910
159911
159912
159913
159914
159915
159916
159917
159918
159919
159920
159921
159922
159923
159924
159925
159926
159927
159928
159929
159930
159931
159932
159933
159934
159935
159936
159937
159938
159939
159940
159941
159942
159943
159944
159945
159946
159947
159948
159949
159950
159951
159952
159953
159954
159955
159956
159957
159958
159959
159960
159961
159962
159963
159964
159965
159966
159967
159968
159969
159970
159971
159972
159973
159974
159975
159976
159977
159978
159979
159980
159981
159982
159983
159984
159985
159986
159987
159988
159989
159990
159991
159992
159993
159994
159995
159996
159997
159998
159999
160000
160001
160002
160003
160004
160005
160006
160007
160008
160009
160010
160011
160012
160013
160014
160015
160016
160017
160018
160019
160020
160021
160022
160023
160024
160025
160026
160027
160028
160029
160030
160031
160032
160033
160034
160035
160036
160037
160038
160039
160040
160041
160042
160043
160044
160045
160046
160047
160048
160049
160050
160051
160052
160053
160054
160055
160056
160057
160058
160059
160060
160061
160062
160063
160064
160065
160066
160067
160068
160069
160070
160071
160072
160073
160074
160075
160076
160077
160078
160079
160080
160081
160082
160083
160084
160085
160086
160087
160088
160089
160090
160091
160092
160093
160094
160095
160096
160097
160098
160099
160100
160101
160102
160103
160104
160105
160106
160107
160108
160109
160110
160111
160112
160113
160114
160115
160116
160117
160118
160119
160120
160121
160122
160123
160124
160125
160126
160127
160128
160129
160130
160131
160132
160133
160134
160135
160136
160137
160138
160139
160140
160141
160142
160143
160144
160145
160146
160147
160148
160149
160150
160151
160152
160153
160154
160155
160156
160157
160158
160159
160160
160161
160162
160163
160164
160165
160166
160167
160168
160169
160170
160171
160172
160173
160174
160175
160176
160177
160178
160179
160180
160181
160182
160183
160184
160185
160186
160187
160188
160189
160190
160191
160192
160193
160194
160195
160196
160197
160198
160199
160200
160201
160202
160203
160204
160205
160206
160207
160208
160209
160210
160211
160212
160213
160214
160215
160216
160217
160218
160219
160220
160221
160222
160223
160224
160225
160226
160227
160228
160229
160230
160231
160232
160233
160234
160235
160236
160237
160238
160239
160240
160241
160242
160243
160244
160245
160246
160247
160248
160249
160250
160251
160252
160253
160254
160255
160256
160257
160258
160259
160260
160261
160262
160263
160264
160265
160266
160267
160268
160269
160270
160271
160272
160273
160274
160275
160276
160277
160278
160279
160280
160281
160282
160283
160284
160285
160286
160287
160288
160289
160290
160291
160292
160293
160294
160295
160296
160297
160298
160299
160300
160301
160302
160303
160304
160305
160306
160307
160308
160309
160310
160311
160312
160313
160314
160315
160316
160317
160318
160319
160320
160321
160322
160323
160324
160325
160326
160327
160328
160329
160330
160331
160332
160333
160334
160335
160336
160337
160338
160339
160340
160341
160342
160343
160344
160345
160346
160347
160348
160349
160350
160351
160352
160353
160354
160355
160356
160357
160358
160359
160360
160361
160362
160363
160364
160365
160366
160367
160368
160369
160370
160371
160372
160373
160374
160375
160376
160377
160378
160379
160380
160381
160382
160383
160384
160385
160386
160387
160388
160389
160390
160391
160392
160393
160394
160395
160396
160397
160398
160399
160400
160401
160402
160403
160404
160405
160406
160407
160408
160409
160410
160411
160412
160413
160414
160415
160416
160417
160418
160419
160420
160421
160422
160423
160424
160425
160426
160427
160428
160429
160430
160431
160432
160433
160434
160435
160436
160437
160438
160439
160440
160441
160442
160443
160444
160445
160446
160447
160448
160449
160450
160451
160452
160453
160454
160455
160456
160457
160458
160459
160460
160461
160462
160463
160464
160465
160466
160467
160468
160469
160470
160471
160472
160473
160474
160475
160476
160477
160478
160479
160480
160481
160482
160483
160484
160485
160486
160487
160488
160489
160490
160491
160492
160493
160494
160495
160496
160497
160498
160499
160500
160501
160502
160503
160504
160505
160506
160507
160508
160509
160510
160511
160512
160513
160514
160515
160516
160517
160518
160519
160520
160521
160522
160523
160524
160525
160526
160527
160528
160529
160530
160531
160532
160533
160534
160535
160536
160537
160538
160539
160540
160541
160542
160543
160544
160545
160546
160547
160548
160549
160550
160551
160552
160553
160554
160555
160556
160557
160558
160559
160560
160561
160562
160563
160564
160565
160566
160567
160568
160569
160570
160571
160572
160573
160574
160575
160576
160577
160578
160579
160580
160581
160582
160583
160584
160585
160586
160587
160588
160589
160590
160591
160592
160593
160594
160595
160596
160597
160598
160599
160600
160601
160602
160603
160604
160605
160606
160607
160608
160609
160610
160611
160612
160613
160614
160615
160616
160617
160618
160619
160620
160621
160622
160623
160624
160625
160626
160627
160628
160629
160630
160631
160632
160633
160634
160635
160636
160637
160638
160639
160640
160641
160642
160643
160644
160645
160646
160647
160648
160649
160650
160651
160652
160653
160654
160655
160656
160657
160658
160659
160660
160661
160662
160663
160664
160665
160666
160667
160668
160669
160670
160671
160672
160673
160674
160675
160676
160677
160678
160679
160680
160681
160682
160683
160684
160685
160686
160687
160688
160689
160690
160691
160692
160693
160694
160695
160696
160697
160698
160699
160700
160701
160702
160703
160704
160705
160706
160707
160708
160709
160710
160711
160712
160713
160714
160715
160716
160717
160718
160719
160720
160721
160722
160723
160724
160725
160726
160727
160728
160729
160730
160731
160732
160733
160734
160735
160736
160737
160738
160739
160740
160741
160742
160743
160744
160745
160746
160747
160748
160749
160750
160751
160752
160753
160754
160755
160756
160757
160758
160759
160760
160761
160762
160763
160764
160765
160766
160767
160768
160769
160770
160771
160772
160773
160774
160775
160776
160777
160778
160779
160780
160781
160782
160783
160784
160785
160786
160787
160788
160789
160790
160791
160792
160793
160794
160795
160796
160797
160798
160799
160800
160801
160802
160803
160804
160805
160806
160807
160808
160809
160810
160811
160812
160813
160814
160815
160816
160817
160818
160819
160820
160821
160822
160823
160824
160825
160826
160827
160828
160829
160830
160831
160832
160833
160834
160835
160836
160837
160838
160839
160840
160841
160842
160843
160844
160845
160846
160847
160848
160849
160850
160851
160852
160853
160854
160855
160856
160857
160858
160859
160860
160861
160862
160863
160864
160865
160866
160867
160868
160869
160870
160871
160872
160873
160874
160875
160876
160877
160878
160879
160880
160881
160882
160883
160884
160885
160886
160887
160888
160889
160890
160891
160892
160893
160894
160895
160896
160897
160898
160899
160900
160901
160902
160903
160904
160905
160906
160907
160908
160909
160910
160911
160912
160913
160914
160915
160916
160917
160918
160919
160920
160921
160922
160923
160924
160925
160926
160927
160928
160929
160930
160931
160932
160933
160934
160935
160936
160937
160938
160939
160940
160941
160942
160943
160944
160945
160946
160947
160948
160949
160950
160951
160952
160953
160954
160955
160956
160957
160958
160959
160960
160961
160962
160963
160964
160965
160966
160967
160968
160969
160970
160971
160972
160973
160974
160975
160976
160977
160978
160979
160980
160981
160982
160983
160984
160985
160986
160987
160988
160989
160990
160991
160992
160993
160994
160995
160996
160997
160998
160999
161000
161001
161002
161003
161004
161005
161006
161007
161008
161009
161010
161011
161012
161013
161014
161015
161016
161017
161018
161019
161020
161021
161022
161023
161024
161025
161026
161027
161028
161029
161030
161031
161032
161033
161034
161035
161036
161037
161038
161039
161040
161041
161042
161043
161044
161045
161046
161047
161048
161049
161050
161051
161052
161053
161054
161055
161056
161057
161058
161059
161060
161061
161062
161063
161064
161065
161066
161067
161068
161069
161070
161071
161072
161073
161074
161075
161076
161077
161078
161079
161080
161081
161082
161083
161084
161085
161086
161087
161088
161089
161090
161091
161092
161093
161094
161095
161096
161097
161098
161099
161100
161101
161102
161103
161104
161105
161106
161107
161108
161109
161110
161111
161112
161113
161114
161115
161116
161117
161118
161119
161120
161121
161122
161123
161124
161125
161126
161127
161128
161129
161130
161131
161132
161133
161134
161135
161136
161137
161138
161139
161140
161141
161142
161143
161144
161145
161146
161147
161148
161149
161150
161151
161152
161153
161154
161155
161156
161157
161158
161159
161160
161161
161162
161163
161164
161165
161166
161167
161168
161169
161170
161171
161172
161173
161174
161175
161176
161177
161178
161179
161180
161181
161182
161183
161184
161185
161186
161187
161188
161189
161190
161191
161192
161193
161194
161195
161196
161197
161198
161199
161200
161201
161202
161203
161204
161205
161206
161207
161208
161209
161210
161211
161212
161213
161214
161215
161216
161217
161218
161219
161220
161221
161222
161223
161224
161225
161226
161227
161228
161229
161230
161231
161232
161233
161234
161235
161236
161237
161238
161239
161240
161241
161242
161243
161244
161245
161246
161247
161248
161249
161250
161251
161252
161253
161254
161255
161256
161257
161258
161259
161260
161261
161262
161263
161264
161265
161266
161267
161268
161269
161270
161271
161272
161273
161274
161275
161276
161277
161278
161279
161280
161281
161282
161283
161284
161285
161286
161287
161288
161289
161290
161291
161292
161293
161294
161295
161296
161297
161298
161299
161300
161301
161302
161303
161304
161305
161306
161307
161308
161309
161310
161311
161312
161313
161314
161315
161316
161317
161318
161319
161320
161321
161322
161323
161324
161325
161326
161327
161328
161329
161330
161331
161332
161333
161334
161335
161336
161337
161338
161339
161340
161341
161342
161343
161344
161345
161346
161347
161348
161349
161350
161351
161352
161353
161354
161355
161356
161357
161358
161359
161360
161361
161362
161363
161364
161365
161366
161367
161368
161369
161370
161371
161372
161373
161374
161375
161376
161377
161378
161379
161380
161381
161382
161383
161384
161385
161386
161387
161388
161389
161390
161391
161392
161393
161394
161395
161396
161397
161398
161399
161400
161401
161402
161403
161404
161405
161406
161407
161408
161409
161410
161411
161412
161413
161414
161415
161416
161417
161418
161419
161420
161421
161422
161423
161424
161425
161426
161427
161428
161429
161430
161431
161432
161433
161434
161435
161436
161437
161438
161439
161440
161441
161442
161443
161444
161445
161446
161447
161448
161449
161450
161451
161452
161453
161454
161455
161456
161457
161458
161459
161460
161461
161462
161463
161464
161465
161466
161467
161468
161469
161470
161471
161472
161473
161474
161475
161476
161477
161478
161479
161480
161481
161482
161483
161484
161485
161486
161487
161488
161489
161490
161491
161492
161493
161494
161495
161496
161497
161498
161499
161500
161501
161502
161503
161504
161505
161506
161507
161508
161509
161510
161511
161512
161513
161514
161515
161516
161517
161518
161519
161520
161521
161522
161523
161524
161525
161526
161527
161528
161529
161530
161531
161532
161533
161534
161535
161536
161537
161538
161539
161540
161541
161542
161543
161544
161545
161546
161547
161548
161549
161550
161551
161552
161553
161554
161555
161556
161557
161558
161559
161560
161561
161562
161563
161564
161565
161566
161567
161568
161569
161570
161571
161572
161573
161574
161575
161576
161577
161578
161579
161580
161581
161582
161583
161584
161585
161586
161587
161588
161589
161590
161591
161592
161593
161594
161595
161596
161597
161598
161599
161600
161601
161602
161603
161604
161605
161606
161607
161608
161609
161610
161611
161612
161613
161614
161615
161616
161617
161618
161619
161620
161621
161622
161623
161624
161625
161626
161627
161628
161629
161630
161631
161632
161633
161634
161635
161636
161637
161638
161639
161640
161641
161642
161643
161644
161645
161646
161647
161648
161649
161650
161651
161652
161653
161654
161655
161656
161657
161658
161659
161660
161661
161662
161663
161664
161665
161666
161667
161668
161669
161670
161671
161672
161673
161674
161675
161676
161677
161678
161679
161680
161681
161682
161683
161684
161685
161686
161687
161688
161689
161690
161691
161692
161693
161694
161695
161696
161697
161698
161699
161700
161701
161702
161703
161704
161705
161706
161707
161708
161709
161710
161711
161712
161713
161714
161715
161716
161717
161718
161719
161720
161721
161722
161723
161724
161725
161726
161727
161728
161729
161730
161731
161732
161733
161734
161735
161736
161737
161738
161739
161740
161741
161742
161743
161744
161745
161746
161747
161748
161749
161750
161751
161752
161753
161754
161755
161756
161757
161758
161759
161760
161761
161762
161763
161764
161765
161766
161767
161768
161769
161770
161771
161772
161773
161774
161775
161776
161777
161778
161779
161780
161781
161782
161783
161784
161785
161786
161787
161788
161789
161790
161791
161792
161793
161794
161795
161796
161797
161798
161799
161800
161801
161802
161803
161804
161805
161806
161807
161808
161809
161810
161811
161812
161813
161814
161815
161816
161817
161818
161819
161820
161821
161822
161823
161824
161825
161826
161827
161828
161829
161830
161831
161832
161833
161834
161835
161836
161837
161838
161839
161840
161841
161842
161843
161844
161845
161846
161847
161848
161849
161850
161851
161852
161853
161854
161855
161856
161857
161858
161859
161860
161861
161862
161863
161864
161865
161866
161867
161868
161869
161870
161871
161872
161873
161874
161875
161876
161877
161878
161879
161880
161881
161882
161883
161884
161885
161886
161887
161888
161889
161890
161891
161892
161893
161894
161895
161896
161897
161898
161899
161900
161901
161902
161903
161904
161905
161906
161907
161908
161909
161910
161911
161912
161913
161914
161915
161916
161917
161918
161919
161920
161921
161922
161923
161924
161925
161926
161927
161928
161929
161930
161931
161932
161933
161934
161935
161936
161937
161938
161939
161940
161941
161942
161943
161944
161945
161946
161947
161948
161949
161950
161951
161952
161953
161954
161955
161956
161957
161958
161959
161960
161961
161962
161963
161964
161965
161966
161967
161968
161969
161970
161971
161972
161973
161974
161975
161976
161977
161978
161979
161980
161981
161982
161983
161984
161985
161986
161987
161988
161989
161990
161991
161992
161993
161994
161995
161996
161997
161998
161999
162000
162001
162002
162003
162004
162005
162006
162007
162008
162009
162010
162011
162012
162013
162014
162015
162016
162017
162018
162019
162020
162021
162022
162023
162024
162025
162026
162027
162028
162029
162030
162031
162032
162033
162034
162035
162036
162037
162038
162039
162040
162041
162042
162043
162044
162045
162046
162047
162048
162049
162050
162051
162052
162053
162054
162055
162056
162057
162058
162059
162060
162061
162062
162063
162064
162065
162066
162067
162068
162069
162070
162071
162072
162073
162074
162075
162076
162077
162078
162079
162080
162081
162082
162083
162084
162085
162086
162087
162088
162089
162090
162091
162092
162093
162094
162095
162096
162097
162098
162099
162100
162101
162102
162103
162104
162105
162106
162107
162108
162109
162110
162111
162112
162113
162114
162115
162116
162117
162118
162119
162120
162121
162122
162123
162124
162125
162126
162127
162128
162129
162130
162131
162132
162133
162134
162135
162136
162137
162138
162139
162140
162141
162142
162143
162144
162145
162146
162147
162148
162149
162150
162151
162152
162153
162154
162155
162156
162157
162158
162159
162160
162161
162162
162163
162164
162165
162166
162167
162168
162169
162170
162171
162172
162173
162174
162175
162176
162177
162178
162179
162180
162181
162182
162183
162184
162185
162186
162187
162188
162189
162190
162191
162192
162193
162194
162195
162196
162197
162198
162199
162200
162201
162202
162203
162204
162205
162206
162207
162208
162209
162210
162211
162212
162213
162214
162215
162216
162217
162218
162219
162220
162221
162222
162223
162224
162225
162226
162227
162228
162229
162230
162231
162232
162233
162234
162235
162236
162237
162238
162239
162240
162241
162242
162243
162244
162245
162246
162247
162248
162249
162250
162251
162252
162253
162254
162255
162256
162257
162258
162259
162260
162261
162262
162263
162264
162265
162266
162267
162268
162269
162270
162271
162272
162273
162274
162275
162276
162277
162278
162279
162280
162281
162282
162283
162284
162285
162286
162287
162288
162289
162290
162291
162292
162293
162294
162295
162296
162297
162298
162299
162300
162301
162302
162303
162304
162305
162306
162307
162308
162309
162310
162311
162312
162313
162314
162315
162316
162317
162318
162319
162320
162321
162322
162323
162324
162325
162326
162327
162328
162329
162330
162331
162332
162333
162334
162335
162336
162337
162338
162339
162340
162341
162342
162343
162344
162345
162346
162347
162348
162349
162350
162351
162352
162353
162354
162355
162356
162357
162358
162359
162360
162361
162362
162363
162364
162365
162366
162367
162368
162369
162370
162371
162372
162373
162374
162375
162376
162377
162378
162379
162380
162381
162382
162383
162384
162385
162386
162387
162388
162389
162390
162391
162392
162393
162394
162395
162396
162397
162398
162399
162400
162401
162402
162403
162404
162405
162406
162407
162408
162409
162410
162411
162412
162413
162414
162415
162416
162417
162418
162419
162420
162421
162422
162423
162424
162425
162426
162427
162428
162429
162430
162431
162432
162433
162434
162435
162436
162437
162438
162439
162440
162441
162442
162443
162444
162445
162446
162447
162448
162449
162450
162451
162452
162453
162454
162455
162456
162457
162458
162459
162460
162461
162462
162463
162464
162465
162466
162467
162468
162469
162470
162471
162472
162473
162474
162475
162476
162477
162478
162479
162480
162481
162482
162483
162484
162485
162486
162487
162488
162489
162490
162491
162492
162493
162494
162495
162496
162497
162498
162499
162500
162501
162502
162503
162504
162505
162506
162507
162508
162509
162510
162511
162512
162513
162514
162515
162516
162517
162518
162519
162520
162521
162522
162523
162524
162525
162526
162527
162528
162529
162530
162531
162532
162533
162534
162535
162536
162537
162538
162539
162540
162541
162542
162543
162544
162545
162546
162547
162548
162549
162550
162551
162552
162553
162554
162555
162556
162557
162558
162559
162560
162561
162562
162563
162564
162565
162566
162567
162568
162569
162570
162571
162572
162573
162574
162575
162576
162577
162578
162579
162580
162581
162582
162583
162584
162585
162586
162587
162588
162589
162590
162591
162592
162593
162594
162595
162596
162597
162598
162599
162600
162601
162602
162603
162604
162605
162606
162607
162608
162609
162610
162611
162612
162613
162614
162615
162616
162617
162618
162619
162620
162621
162622
162623
162624
162625
162626
162627
162628
162629
162630
162631
162632
162633
162634
162635
162636
162637
162638
162639
162640
162641
162642
162643
162644
162645
162646
162647
162648
162649
162650
162651
162652
162653
162654
162655
162656
162657
162658
162659
162660
162661
162662
162663
162664
162665
162666
162667
162668
162669
162670
162671
162672
162673
162674
162675
162676
162677
162678
162679
162680
162681
162682
162683
162684
162685
162686
162687
162688
162689
162690
162691
162692
162693
162694
162695
162696
162697
162698
162699
162700
162701
162702
162703
162704
162705
162706
162707
162708
162709
162710
162711
162712
162713
162714
162715
162716
162717
162718
162719
162720
162721
162722
162723
162724
162725
162726
162727
162728
162729
162730
162731
162732
162733
162734
162735
162736
162737
162738
162739
162740
162741
162742
162743
162744
162745
162746
162747
162748
162749
162750
162751
162752
162753
162754
162755
162756
162757
162758
162759
162760
162761
162762
162763
162764
162765
162766
162767
162768
162769
162770
162771
162772
162773
162774
162775
162776
162777
162778
162779
162780
162781
162782
162783
162784
162785
162786
162787
162788
162789
162790
162791
162792
162793
162794
162795
162796
162797
162798
162799
162800
162801
162802
162803
162804
162805
162806
162807
162808
162809
162810
162811
162812
162813
162814
162815
162816
162817
162818
162819
162820
162821
162822
162823
162824
162825
162826
162827
162828
162829
162830
162831
162832
162833
162834
162835
162836
162837
162838
162839
162840
162841
162842
162843
162844
162845
162846
162847
162848
162849
162850
162851
162852
162853
162854
162855
162856
162857
162858
162859
162860
162861
162862
162863
162864
162865
162866
162867
162868
162869
162870
162871
162872
162873
162874
162875
162876
162877
162878
162879
162880
162881
162882
162883
162884
162885
162886
162887
162888
162889
162890
162891
162892
162893
162894
162895
162896
162897
162898
162899
162900
162901
162902
162903
162904
162905
162906
162907
162908
162909
162910
162911
162912
162913
162914
162915
162916
162917
162918
162919
162920
162921
162922
162923
162924
162925
162926
162927
162928
162929
162930
162931
162932
162933
162934
162935
162936
162937
162938
162939
162940
162941
162942
162943
162944
162945
162946
162947
162948
162949
162950
162951
162952
162953
162954
162955
162956
162957
162958
162959
162960
162961
162962
162963
162964
162965
162966
162967
162968
162969
162970
162971
162972
162973
162974
162975
162976
162977
162978
162979
162980
162981
162982
162983
162984
162985
162986
162987
162988
162989
162990
162991
162992
162993
162994
162995
162996
162997
162998
162999
163000
163001
163002
163003
163004
163005
163006
163007
163008
163009
163010
163011
163012
163013
163014
163015
163016
163017
163018
163019
163020
163021
163022
163023
163024
163025
163026
163027
163028
163029
163030
163031
163032
163033
163034
163035
163036
163037
163038
163039
163040
163041
163042
163043
163044
163045
163046
163047
163048
163049
163050
163051
163052
163053
163054
163055
163056
163057
163058
163059
163060
163061
163062
163063
163064
163065
163066
163067
163068
163069
163070
163071
163072
163073
163074
163075
163076
163077
163078
163079
163080
163081
163082
163083
163084
163085
163086
163087
163088
163089
163090
163091
163092
163093
163094
163095
163096
163097
163098
163099
163100
163101
163102
163103
163104
163105
163106
163107
163108
163109
163110
163111
163112
163113
163114
163115
163116
163117
163118
163119
163120
163121
163122
163123
163124
163125
163126
163127
163128
163129
163130
163131
163132
163133
163134
163135
163136
163137
163138
163139
163140
163141
163142
163143
163144
163145
163146
163147
163148
163149
163150
163151
163152
163153
163154
163155
163156
163157
163158
163159
163160
163161
163162
163163
163164
163165
163166
163167
163168
163169
163170
163171
163172
163173
163174
163175
163176
163177
163178
163179
163180
163181
163182
163183
163184
163185
163186
163187
163188
163189
163190
163191
163192
163193
163194
163195
163196
163197
163198
163199
163200
163201
163202
163203
163204
163205
163206
163207
163208
163209
163210
163211
163212
163213
163214
163215
163216
163217
163218
163219
163220
163221
163222
163223
163224
163225
163226
163227
163228
163229
163230
163231
163232
163233
163234
163235
163236
163237
163238
163239
163240
163241
163242
163243
163244
163245
163246
163247
163248
163249
163250
163251
163252
163253
163254
163255
163256
163257
163258
163259
163260
163261
163262
163263
163264
163265
163266
163267
163268
163269
163270
163271
163272
163273
163274
163275
163276
163277
163278
163279
163280
163281
163282
163283
163284
163285
163286
163287
163288
163289
163290
163291
163292
163293
163294
163295
163296
163297
163298
163299
163300
163301
163302
163303
163304
163305
163306
163307
163308
163309
163310
163311
163312
163313
163314
163315
163316
163317
163318
163319
163320
163321
163322
163323
163324
163325
163326
163327
163328
163329
163330
163331
163332
163333
163334
163335
163336
163337
163338
163339
163340
163341
163342
163343
163344
163345
163346
163347
163348
163349
163350
163351
163352
163353
163354
163355
163356
163357
163358
163359
163360
163361
163362
163363
163364
163365
163366
163367
163368
163369
163370
163371
163372
163373
163374
163375
163376
163377
163378
163379
163380
163381
163382
163383
163384
163385
163386
163387
163388
163389
163390
163391
163392
163393
163394
163395
163396
163397
163398
163399
163400
163401
163402
163403
163404
163405
163406
163407
163408
163409
163410
163411
163412
163413
163414
163415
163416
163417
163418
163419
163420
163421
163422
163423
163424
163425
163426
163427
163428
163429
163430
163431
163432
163433
163434
163435
163436
163437
163438
163439
163440
163441
163442
163443
163444
163445
163446
163447
163448
163449
163450
163451
163452
163453
163454
163455
163456
163457
163458
163459
163460
163461
163462
163463
163464
163465
163466
163467
163468
163469
163470
163471
163472
163473
163474
163475
163476
163477
163478
163479
163480
163481
163482
163483
163484
163485
163486
163487
163488
163489
163490
163491
163492
163493
163494
163495
163496
163497
163498
163499
163500
163501
163502
163503
163504
163505
163506
163507
163508
163509
163510
163511
163512
163513
163514
163515
163516
163517
163518
163519
163520
163521
163522
163523
163524
163525
163526
163527
163528
163529
163530
163531
163532
163533
163534
163535
163536
163537
163538
163539
163540
163541
163542
163543
163544
163545
163546
163547
163548
163549
163550
163551
163552
163553
163554
163555
163556
163557
163558
163559
163560
163561
163562
163563
163564
163565
163566
163567
163568
163569
163570
163571
163572
163573
163574
163575
163576
163577
163578
163579
163580
163581
163582
163583
163584
163585
163586
163587
163588
163589
163590
163591
163592
163593
163594
163595
163596
163597
163598
163599
163600
163601
163602
163603
163604
163605
163606
163607
163608
163609
163610
163611
163612
163613
163614
163615
163616
163617
163618
163619
163620
163621
163622
163623
163624
163625
163626
163627
163628
163629
163630
163631
163632
163633
163634
163635
163636
163637
163638
163639
163640
163641
163642
163643
163644
163645
163646
163647
163648
163649
163650
163651
163652
163653
163654
163655
163656
163657
163658
163659
163660
163661
163662
163663
163664
163665
163666
163667
163668
163669
163670
163671
163672
163673
163674
163675
163676
163677
163678
163679
163680
163681
163682
163683
163684
163685
163686
163687
163688
163689
163690
163691
163692
163693
163694
163695
163696
163697
163698
163699
163700
163701
163702
163703
163704
163705
163706
163707
163708
163709
163710
163711
163712
163713
163714
163715
163716
163717
163718
163719
163720
163721
163722
163723
163724
163725
163726
163727
163728
163729
163730
163731
163732
163733
163734
163735
163736
163737
163738
163739
163740
163741
163742
163743
163744
163745
163746
163747
163748
163749
163750
163751
163752
163753
163754
163755
163756
163757
163758
163759
163760
163761
163762
163763
163764
163765
163766
163767
163768
163769
163770
163771
163772
163773
163774
163775
163776
163777
163778
163779
163780
163781
163782
163783
163784
163785
163786
163787
163788
163789
163790
163791
163792
163793
163794
163795
163796
163797
163798
163799
163800
163801
163802
163803
163804
163805
163806
163807
163808
163809
163810
163811
163812
163813
163814
163815
163816
163817
163818
163819
163820
163821
163822
163823
163824
163825
163826
163827
163828
163829
163830
163831
163832
163833
163834
163835
163836
163837
163838
163839
163840
163841
163842
163843
163844
163845
163846
163847
163848
163849
163850
163851
163852
163853
163854
163855
163856
163857
163858
163859
163860
163861
163862
163863
163864
163865
163866
163867
163868
163869
163870
163871
163872
163873
163874
163875
163876
163877
163878
163879
163880
163881
163882
163883
163884
163885
163886
163887
163888
163889
163890
163891
163892
163893
163894
163895
163896
163897
163898
163899
163900
163901
163902
163903
163904
163905
163906
163907
163908
163909
163910
163911
163912
163913
163914
163915
163916
163917
163918
163919
163920
163921
163922
163923
163924
163925
163926
163927
163928
163929
163930
163931
163932
163933
163934
163935
163936
163937
163938
163939
163940
163941
163942
163943
163944
163945
163946
163947
163948
163949
163950
163951
163952
163953
163954
163955
163956
163957
163958
163959
163960
163961
163962
163963
163964
163965
163966
163967
163968
163969
163970
163971
163972
163973
163974
163975
163976
163977
163978
163979
163980
163981
163982
163983
163984
163985
163986
163987
163988
163989
163990
163991
163992
163993
163994
163995
163996
163997
163998
163999
164000
164001
164002
164003
164004
164005
164006
164007
164008
164009
164010
164011
164012
164013
164014
164015
164016
164017
164018
164019
164020
164021
164022
164023
164024
164025
164026
164027
164028
164029
164030
164031
164032
164033
164034
164035
164036
164037
164038
164039
164040
164041
164042
164043
164044
164045
164046
164047
164048
164049
164050
164051
164052
164053
164054
164055
164056
164057
164058
164059
164060
164061
164062
164063
164064
164065
164066
164067
164068
164069
164070
164071
164072
164073
164074
164075
164076
164077
164078
164079
164080
164081
164082
164083
164084
164085
164086
164087
164088
164089
164090
164091
164092
164093
164094
164095
164096
164097
164098
164099
164100
164101
164102
164103
164104
164105
164106
164107
164108
164109
164110
164111
164112
164113
164114
164115
164116
164117
164118
164119
164120
164121
164122
164123
164124
164125
164126
164127
164128
164129
164130
164131
164132
164133
164134
164135
164136
164137
164138
164139
164140
164141
164142
164143
164144
164145
164146
164147
164148
164149
164150
164151
164152
164153
164154
164155
164156
164157
164158
164159
164160
164161
164162
164163
164164
164165
164166
164167
164168
164169
164170
164171
164172
164173
164174
164175
164176
164177
164178
164179
164180
164181
164182
164183
164184
164185
164186
164187
164188
164189
164190
164191
164192
164193
164194
164195
164196
164197
164198
164199
164200
164201
164202
164203
164204
164205
164206
164207
164208
164209
164210
164211
164212
164213
164214
164215
164216
164217
164218
164219
164220
164221
164222
164223
164224
164225
164226
164227
164228
164229
164230
164231
164232
164233
164234
164235
164236
164237
164238
164239
164240
164241
164242
164243
164244
164245
164246
164247
164248
164249
164250
164251
164252
164253
164254
164255
164256
164257
164258
164259
164260
164261
164262
164263
164264
164265
164266
164267
164268
164269
164270
164271
164272
164273
164274
164275
164276
164277
164278
164279
164280
164281
164282
164283
164284
164285
164286
164287
164288
164289
164290
164291
164292
164293
164294
164295
164296
164297
164298
164299
164300
164301
164302
164303
164304
164305
164306
164307
164308
164309
164310
164311
164312
164313
164314
164315
164316
164317
164318
164319
164320
164321
164322
164323
164324
164325
164326
164327
164328
164329
164330
164331
164332
164333
164334
164335
164336
164337
164338
164339
164340
164341
164342
164343
164344
164345
164346
164347
164348
164349
164350
164351
164352
164353
164354
164355
164356
164357
164358
164359
164360
164361
164362
164363
164364
164365
164366
164367
164368
164369
164370
164371
164372
164373
164374
164375
164376
164377
164378
164379
164380
164381
164382
164383
164384
164385
164386
164387
164388
164389
164390
164391
164392
164393
164394
164395
164396
164397
164398
164399
164400
164401
164402
164403
164404
164405
164406
164407
164408
164409
164410
164411
164412
164413
164414
164415
164416
164417
164418
164419
164420
164421
164422
164423
164424
164425
164426
164427
164428
164429
164430
164431
164432
164433
164434
164435
164436
164437
164438
164439
164440
164441
164442
164443
164444
164445
164446
164447
164448
164449
164450
164451
164452
164453
164454
164455
164456
164457
164458
164459
164460
164461
164462
164463
164464
164465
164466
164467
164468
164469
164470
164471
164472
164473
164474
164475
164476
164477
164478
164479
164480
164481
164482
164483
164484
164485
164486
164487
164488
164489
164490
164491
164492
164493
164494
164495
164496
164497
164498
164499
164500
164501
164502
164503
164504
164505
164506
164507
164508
164509
164510
164511
164512
164513
164514
164515
164516
164517
164518
164519
164520
164521
164522
164523
164524
164525
164526
164527
164528
164529
164530
164531
164532
164533
164534
164535
164536
164537
164538
164539
164540
164541
164542
164543
164544
164545
164546
164547
164548
164549
164550
164551
164552
164553
164554
164555
164556
164557
164558
164559
164560
164561
164562
164563
164564
164565
164566
164567
164568
164569
164570
164571
164572
164573
164574
164575
164576
164577
164578
164579
164580
164581
164582
164583
164584
164585
164586
164587
164588
164589
164590
164591
164592
164593
164594
164595
164596
164597
164598
164599
164600
164601
164602
164603
164604
164605
164606
164607
164608
164609
164610
164611
164612
164613
164614
164615
164616
164617
164618
164619
164620
164621
164622
164623
164624
164625
164626
164627
164628
164629
164630
164631
164632
164633
164634
164635
164636
164637
164638
164639
164640
164641
164642
164643
164644
164645
164646
164647
164648
164649
164650
164651
164652
164653
164654
164655
164656
164657
164658
164659
164660
164661
164662
164663
164664
164665
164666
164667
164668
164669
164670
164671
164672
164673
164674
164675
164676
164677
164678
164679
164680
164681
164682
164683
164684
164685
164686
164687
164688
164689
164690
164691
164692
164693
164694
164695
164696
164697
164698
164699
164700
164701
164702
164703
164704
164705
164706
164707
164708
164709
164710
164711
164712
164713
164714
164715
164716
164717
164718
164719
164720
164721
164722
164723
164724
164725
164726
164727
164728
164729
164730
164731
164732
164733
164734
164735
164736
164737
164738
164739
164740
164741
164742
164743
164744
164745
164746
164747
164748
164749
164750
164751
164752
164753
164754
164755
164756
164757
164758
164759
164760
164761
164762
164763
164764
164765
164766
164767
164768
164769
164770
164771
164772
164773
164774
164775
164776
164777
164778
164779
164780
164781
164782
164783
164784
164785
164786
164787
164788
164789
164790
164791
164792
164793
164794
164795
164796
164797
164798
164799
164800
164801
164802
164803
164804
164805
164806
164807
164808
164809
164810
164811
164812
164813
164814
164815
164816
164817
164818
164819
164820
164821
164822
164823
164824
164825
164826
164827
164828
164829
164830
164831
164832
164833
164834
164835
164836
164837
164838
164839
164840
164841
164842
164843
164844
164845
164846
164847
164848
164849
164850
164851
164852
164853
164854
164855
164856
164857
164858
164859
164860
164861
164862
164863
164864
164865
164866
164867
164868
164869
164870
164871
164872
164873
164874
164875
164876
164877
164878
164879
164880
164881
164882
164883
164884
164885
164886
164887
164888
164889
164890
164891
164892
164893
164894
164895
164896
164897
164898
164899
164900
164901
164902
164903
164904
164905
164906
164907
164908
164909
164910
164911
164912
164913
164914
164915
164916
164917
164918
164919
164920
164921
164922
164923
164924
164925
164926
164927
164928
164929
164930
164931
164932
164933
164934
164935
164936
164937
164938
164939
164940
164941
164942
164943
164944
164945
164946
164947
164948
164949
164950
164951
164952
164953
164954
164955
164956
164957
164958
164959
164960
164961
164962
164963
164964
164965
164966
164967
164968
164969
164970
164971
164972
164973
164974
164975
164976
164977
164978
164979
164980
164981
164982
164983
164984
164985
164986
164987
164988
164989
164990
164991
164992
164993
164994
164995
164996
164997
164998
164999
165000
165001
165002
165003
165004
165005
165006
165007
165008
165009
165010
165011
165012
165013
165014
165015
165016
165017
165018
165019
165020
165021
165022
165023
165024
165025
165026
165027
165028
165029
165030
165031
165032
165033
165034
165035
165036
165037
165038
165039
165040
165041
165042
165043
165044
165045
165046
165047
165048
165049
165050
165051
165052
165053
165054
165055
165056
165057
165058
165059
165060
165061
165062
165063
165064
165065
165066
165067
165068
165069
165070
165071
165072
165073
165074
165075
165076
165077
165078
165079
165080
165081
165082
165083
165084
165085
165086
165087
165088
165089
165090
165091
165092
165093
165094
165095
165096
165097
165098
165099
165100
165101
165102
165103
165104
165105
165106
165107
165108
165109
165110
165111
165112
165113
165114
165115
165116
165117
165118
165119
165120
165121
165122
165123
165124
165125
165126
165127
165128
165129
165130
165131
165132
165133
165134
165135
165136
165137
165138
165139
165140
165141
165142
165143
165144
165145
165146
165147
165148
165149
165150
165151
165152
165153
165154
165155
165156
165157
165158
165159
165160
165161
165162
165163
165164
165165
165166
165167
165168
165169
165170
165171
165172
165173
165174
165175
165176
165177
165178
165179
165180
165181
165182
165183
165184
165185
165186
165187
165188
165189
165190
165191
165192
165193
165194
165195
165196
165197
165198
165199
165200
165201
165202
165203
165204
165205
165206
165207
165208
165209
165210
165211
165212
165213
165214
165215
165216
165217
165218
165219
165220
165221
165222
165223
165224
165225
165226
165227
165228
165229
165230
165231
165232
165233
165234
165235
165236
165237
165238
165239
165240
165241
165242
165243
165244
165245
165246
165247
165248
165249
165250
165251
165252
165253
165254
165255
165256
165257
165258
165259
165260
165261
165262
165263
165264
165265
165266
165267
165268
165269
165270
165271
165272
165273
165274
165275
165276
165277
165278
165279
165280
165281
165282
165283
165284
165285
165286
165287
165288
165289
165290
165291
165292
165293
165294
165295
165296
165297
165298
165299
165300
165301
165302
165303
165304
165305
165306
165307
165308
165309
165310
165311
165312
165313
165314
165315
165316
165317
165318
165319
165320
165321
165322
165323
165324
165325
165326
165327
165328
165329
165330
165331
165332
165333
165334
165335
165336
165337
165338
165339
165340
165341
165342
165343
165344
165345
165346
165347
165348
165349
165350
165351
165352
165353
165354
165355
165356
165357
165358
165359
165360
165361
165362
165363
165364
165365
165366
165367
165368
165369
165370
165371
165372
165373
165374
165375
165376
165377
165378
165379
165380
165381
165382
165383
165384
165385
165386
165387
165388
165389
165390
165391
165392
165393
165394
165395
165396
165397
165398
165399
165400
165401
165402
165403
165404
165405
165406
165407
165408
165409
165410
165411
165412
165413
165414
165415
165416
165417
165418
165419
165420
165421
165422
165423
165424
165425
165426
165427
165428
165429
165430
165431
165432
165433
165434
165435
165436
165437
165438
165439
165440
165441
165442
165443
165444
165445
165446
165447
165448
165449
165450
165451
165452
165453
165454
165455
165456
165457
165458
165459
165460
165461
165462
165463
165464
165465
165466
165467
165468
165469
165470
165471
165472
165473
165474
165475
165476
165477
165478
165479
165480
165481
165482
165483
165484
165485
165486
165487
165488
165489
165490
165491
165492
165493
165494
165495
165496
165497
165498
165499
165500
165501
165502
165503
165504
165505
165506
165507
165508
165509
165510
165511
165512
165513
165514
165515
165516
165517
165518
165519
165520
165521
165522
165523
165524
165525
165526
165527
165528
165529
165530
165531
165532
165533
165534
165535
165536
165537
165538
165539
165540
165541
165542
165543
165544
165545
165546
165547
165548
165549
165550
165551
165552
165553
165554
165555
165556
165557
165558
165559
165560
165561
165562
165563
165564
165565
165566
165567
165568
165569
165570
165571
165572
165573
165574
165575
165576
165577
165578
165579
165580
165581
165582
165583
165584
165585
165586
165587
165588
165589
165590
165591
165592
165593
165594
165595
165596
165597
165598
165599
165600
165601
165602
165603
165604
165605
165606
165607
165608
165609
165610
165611
165612
165613
165614
165615
165616
165617
165618
165619
165620
165621
165622
165623
165624
165625
165626
165627
165628
165629
165630
165631
165632
165633
165634
165635
165636
165637
165638
165639
165640
165641
165642
165643
165644
165645
165646
165647
165648
165649
165650
165651
165652
165653
165654
165655
165656
165657
165658
165659
165660
165661
165662
165663
165664
165665
165666
165667
165668
165669
165670
165671
165672
165673
165674
165675
165676
165677
165678
165679
165680
165681
165682
165683
165684
165685
165686
165687
165688
165689
165690
165691
165692
165693
165694
165695
165696
165697
165698
165699
165700
165701
165702
165703
165704
165705
165706
165707
165708
165709
165710
165711
165712
165713
165714
165715
165716
165717
165718
165719
165720
165721
165722
165723
165724
165725
165726
165727
165728
165729
165730
165731
165732
165733
165734
165735
165736
165737
165738
165739
165740
165741
165742
165743
165744
165745
165746
165747
165748
165749
165750
165751
165752
165753
165754
165755
165756
165757
165758
165759
165760
165761
165762
165763
165764
165765
165766
165767
165768
165769
165770
165771
165772
165773
165774
165775
165776
165777
165778
165779
165780
165781
165782
165783
165784
165785
165786
165787
165788
165789
165790
165791
165792
165793
165794
165795
165796
165797
165798
165799
165800
165801
165802
165803
165804
165805
165806
165807
165808
165809
165810
165811
165812
165813
165814
165815
165816
165817
165818
165819
165820
165821
165822
165823
165824
165825
165826
165827
165828
165829
165830
165831
165832
165833
165834
165835
165836
165837
165838
165839
165840
165841
165842
165843
165844
165845
165846
165847
165848
165849
165850
165851
165852
165853
165854
165855
165856
165857
165858
165859
165860
165861
165862
165863
165864
165865
165866
165867
165868
165869
165870
165871
165872
165873
165874
165875
165876
165877
165878
165879
165880
165881
165882
165883
165884
165885
165886
165887
165888
165889
165890
165891
165892
165893
165894
165895
165896
165897
165898
165899
165900
165901
165902
165903
165904
165905
165906
165907
165908
165909
165910
165911
165912
165913
165914
165915
165916
165917
165918
165919
165920
165921
165922
165923
165924
165925
165926
165927
165928
165929
165930
165931
165932
165933
165934
165935
165936
165937
165938
165939
165940
165941
165942
165943
165944
165945
165946
165947
165948
165949
165950
165951
165952
165953
165954
165955
165956
165957
165958
165959
165960
165961
165962
165963
165964
165965
165966
165967
165968
165969
165970
165971
165972
165973
165974
165975
165976
165977
165978
165979
165980
165981
165982
165983
165984
165985
165986
165987
165988
165989
165990
165991
165992
165993
165994
165995
165996
165997
165998
165999
166000
166001
166002
166003
166004
166005
166006
166007
166008
166009
166010
166011
166012
166013
166014
166015
166016
166017
166018
166019
166020
166021
166022
166023
166024
166025
166026
166027
166028
166029
166030
166031
166032
166033
166034
166035
166036
166037
166038
166039
166040
166041
166042
166043
166044
166045
166046
166047
166048
166049
166050
166051
166052
166053
166054
166055
166056
166057
166058
166059
166060
166061
166062
166063
166064
166065
166066
166067
166068
166069
166070
166071
166072
166073
166074
166075
166076
166077
166078
166079
166080
166081
166082
166083
166084
166085
166086
166087
166088
166089
166090
166091
166092
166093
166094
166095
166096
166097
166098
166099
166100
166101
166102
166103
166104
166105
166106
166107
166108
166109
166110
166111
166112
166113
166114
166115
166116
166117
166118
166119
166120
166121
166122
166123
166124
166125
166126
166127
166128
166129
166130
166131
166132
166133
166134
166135
166136
166137
166138
166139
166140
166141
166142
166143
166144
166145
166146
166147
166148
166149
166150
166151
166152
166153
166154
166155
166156
166157
166158
166159
166160
166161
166162
166163
166164
166165
166166
166167
166168
166169
166170
166171
166172
166173
166174
166175
166176
166177
166178
166179
166180
166181
166182
166183
166184
166185
166186
166187
166188
166189
166190
166191
166192
166193
166194
166195
166196
166197
166198
166199
166200
166201
166202
166203
166204
166205
166206
166207
166208
166209
166210
166211
166212
166213
166214
166215
166216
166217
166218
166219
166220
166221
166222
166223
166224
166225
166226
166227
166228
166229
166230
166231
166232
166233
166234
166235
166236
166237
166238
166239
166240
166241
166242
166243
166244
166245
166246
166247
166248
166249
166250
166251
166252
166253
166254
166255
166256
166257
166258
166259
166260
166261
166262
166263
166264
166265
166266
166267
166268
166269
166270
166271
166272
166273
166274
166275
166276
166277
166278
166279
166280
166281
166282
166283
166284
166285
166286
166287
166288
166289
166290
166291
166292
166293
166294
166295
166296
166297
166298
166299
166300
166301
166302
166303
166304
166305
166306
166307
166308
166309
166310
166311
166312
166313
166314
166315
166316
166317
166318
166319
166320
166321
166322
166323
166324
166325
166326
166327
166328
166329
166330
166331
166332
166333
166334
166335
166336
166337
166338
166339
166340
166341
166342
166343
166344
166345
166346
166347
166348
166349
166350
166351
166352
166353
166354
166355
166356
166357
166358
166359
166360
166361
166362
166363
166364
166365
166366
166367
166368
166369
166370
166371
166372
166373
166374
166375
166376
166377
166378
166379
166380
166381
166382
166383
166384
166385
166386
166387
166388
166389
166390
166391
166392
166393
166394
166395
166396
166397
166398
166399
166400
166401
166402
166403
166404
166405
166406
166407
166408
166409
166410
166411
166412
166413
166414
166415
166416
166417
166418
166419
166420
166421
166422
166423
166424
166425
166426
166427
166428
166429
166430
166431
166432
166433
166434
166435
166436
166437
166438
166439
166440
166441
166442
166443
166444
166445
166446
166447
166448
166449
166450
166451
166452
166453
166454
166455
166456
166457
166458
166459
166460
166461
166462
166463
166464
166465
166466
166467
166468
166469
166470
166471
166472
166473
166474
166475
166476
166477
166478
166479
166480
166481
166482
166483
166484
166485
166486
166487
166488
166489
166490
166491
166492
166493
166494
166495
166496
166497
166498
166499
166500
166501
166502
166503
166504
166505
166506
166507
166508
166509
166510
166511
166512
166513
166514
166515
166516
166517
166518
166519
166520
166521
166522
166523
166524
166525
166526
166527
166528
166529
166530
166531
166532
166533
166534
166535
166536
166537
166538
166539
166540
166541
166542
166543
166544
166545
166546
166547
166548
166549
166550
166551
166552
166553
166554
166555
166556
166557
166558
166559
166560
166561
166562
166563
166564
166565
166566
166567
166568
166569
166570
166571
166572
166573
166574
166575
166576
166577
166578
166579
166580
166581
166582
166583
166584
166585
166586
166587
166588
166589
166590
166591
166592
166593
166594
166595
166596
166597
166598
166599
166600
166601
166602
166603
166604
166605
166606
166607
166608
166609
166610
166611
166612
166613
166614
166615
166616
166617
166618
166619
166620
166621
166622
166623
166624
166625
166626
166627
166628
166629
166630
166631
166632
166633
166634
166635
166636
166637
166638
166639
166640
166641
166642
166643
166644
166645
166646
166647
166648
166649
166650
166651
166652
166653
166654
166655
166656
166657
166658
166659
166660
166661
166662
166663
166664
166665
166666
166667
166668
166669
166670
166671
166672
166673
166674
166675
166676
166677
166678
166679
166680
166681
166682
166683
166684
166685
166686
166687
166688
166689
166690
166691
166692
166693
166694
166695
166696
166697
166698
166699
166700
166701
166702
166703
166704
166705
166706
166707
166708
166709
166710
166711
166712
166713
166714
166715
166716
166717
166718
166719
166720
166721
166722
166723
166724
166725
166726
166727
166728
166729
166730
166731
166732
166733
166734
166735
166736
166737
166738
166739
166740
166741
166742
166743
166744
166745
166746
166747
166748
166749
166750
166751
166752
166753
166754
166755
166756
166757
166758
166759
166760
166761
166762
166763
166764
166765
166766
166767
166768
166769
166770
166771
166772
166773
166774
166775
166776
166777
166778
166779
166780
166781
166782
166783
166784
166785
166786
166787
166788
166789
166790
166791
166792
166793
166794
166795
166796
166797
166798
166799
166800
166801
166802
166803
166804
166805
166806
166807
166808
166809
166810
166811
166812
166813
166814
166815
166816
166817
166818
166819
166820
166821
166822
166823
166824
166825
166826
166827
166828
166829
166830
166831
166832
166833
166834
166835
166836
166837
166838
166839
166840
166841
166842
166843
166844
166845
166846
166847
166848
166849
166850
166851
166852
166853
166854
166855
166856
166857
166858
166859
166860
166861
166862
166863
166864
166865
166866
166867
166868
166869
166870
166871
166872
166873
166874
166875
166876
166877
166878
166879
166880
166881
166882
166883
166884
166885
166886
166887
166888
166889
166890
166891
166892
166893
166894
166895
166896
166897
166898
166899
166900
166901
166902
166903
166904
166905
166906
166907
166908
166909
166910
166911
166912
166913
166914
166915
166916
166917
166918
166919
166920
166921
166922
166923
166924
166925
166926
166927
166928
166929
166930
166931
166932
166933
166934
166935
166936
166937
166938
166939
166940
166941
166942
166943
166944
166945
166946
166947
166948
166949
166950
166951
166952
166953
166954
166955
166956
166957
166958
166959
166960
166961
166962
166963
166964
166965
166966
166967
166968
166969
166970
166971
166972
166973
166974
166975
166976
166977
166978
166979
166980
166981
166982
166983
166984
166985
166986
166987
166988
166989
166990
166991
166992
166993
166994
166995
166996
166997
166998
166999
167000
167001
167002
167003
167004
167005
167006
167007
167008
167009
167010
167011
167012
167013
167014
167015
167016
167017
167018
167019
167020
167021
167022
167023
167024
167025
167026
167027
167028
167029
167030
167031
167032
167033
167034
167035
167036
167037
167038
167039
167040
167041
167042
167043
167044
167045
167046
167047
167048
167049
167050
167051
167052
167053
167054
167055
167056
167057
167058
167059
167060
167061
167062
167063
167064
167065
167066
167067
167068
167069
167070
167071
167072
167073
167074
167075
167076
167077
167078
167079
167080
167081
167082
167083
167084
167085
167086
167087
167088
167089
167090
167091
167092
167093
167094
167095
167096
167097
167098
167099
167100
167101
167102
167103
167104
167105
167106
167107
167108
167109
167110
167111
167112
167113
167114
167115
167116
167117
167118
167119
167120
167121
167122
167123
167124
167125
167126
167127
167128
167129
167130
167131
167132
167133
167134
167135
167136
167137
167138
167139
167140
167141
167142
167143
167144
167145
167146
167147
167148
167149
167150
167151
167152
167153
167154
167155
167156
167157
167158
167159
167160
167161
167162
167163
167164
167165
167166
167167
167168
167169
167170
167171
167172
167173
167174
167175
167176
167177
167178
167179
167180
167181
167182
167183
167184
167185
167186
167187
167188
167189
167190
167191
167192
167193
167194
167195
167196
167197
167198
167199
167200
167201
167202
167203
167204
167205
167206
167207
167208
167209
167210
167211
167212
167213
167214
167215
167216
167217
167218
167219
167220
167221
167222
167223
167224
167225
167226
167227
167228
167229
167230
167231
167232
167233
167234
167235
167236
167237
167238
167239
167240
167241
167242
167243
167244
167245
167246
167247
167248
167249
167250
167251
167252
167253
167254
167255
167256
167257
167258
167259
167260
167261
167262
167263
167264
167265
167266
167267
167268
167269
167270
167271
167272
167273
167274
167275
167276
167277
167278
167279
167280
167281
167282
167283
167284
167285
167286
167287
167288
167289
167290
167291
167292
167293
167294
167295
167296
167297
167298
167299
167300
167301
167302
167303
167304
167305
167306
167307
167308
167309
167310
167311
167312
167313
167314
167315
167316
167317
167318
167319
167320
167321
167322
167323
167324
167325
167326
167327
167328
167329
167330
167331
167332
167333
167334
167335
167336
167337
167338
167339
167340
167341
167342
167343
167344
167345
167346
167347
167348
167349
167350
167351
167352
167353
167354
167355
167356
167357
167358
167359
167360
167361
167362
167363
167364
167365
167366
167367
167368
167369
167370
167371
167372
167373
167374
167375
167376
167377
167378
167379
167380
167381
167382
167383
167384
167385
167386
167387
167388
167389
167390
167391
167392
167393
167394
167395
167396
167397
167398
167399
167400
167401
167402
167403
167404
167405
167406
167407
167408
167409
167410
167411
167412
167413
167414
167415
167416
167417
167418
167419
167420
167421
167422
167423
167424
167425
167426
167427
167428
167429
167430
167431
167432
167433
167434
167435
167436
167437
167438
167439
167440
167441
167442
167443
167444
167445
167446
167447
167448
167449
167450
167451
167452
167453
167454
167455
167456
167457
167458
167459
167460
167461
167462
167463
167464
167465
167466
167467
167468
167469
167470
167471
167472
167473
167474
167475
167476
167477
167478
167479
167480
167481
167482
167483
167484
167485
167486
167487
167488
167489
167490
167491
167492
167493
167494
167495
167496
167497
167498
167499
167500
167501
167502
167503
167504
167505
167506
167507
167508
167509
167510
167511
167512
167513
167514
167515
167516
167517
167518
167519
167520
167521
167522
167523
167524
167525
167526
167527
167528
167529
167530
167531
167532
167533
167534
167535
167536
167537
167538
167539
167540
167541
167542
167543
167544
167545
167546
167547
167548
167549
167550
167551
167552
167553
167554
167555
167556
167557
167558
167559
167560
167561
167562
167563
167564
167565
167566
167567
167568
167569
167570
167571
167572
167573
167574
167575
167576
167577
167578
167579
167580
167581
167582
167583
167584
167585
167586
167587
167588
167589
167590
167591
167592
167593
167594
167595
167596
167597
167598
167599
167600
167601
167602
167603
167604
167605
167606
167607
167608
167609
167610
167611
167612
167613
167614
167615
167616
167617
167618
167619
167620
167621
167622
167623
167624
167625
167626
167627
167628
167629
167630
167631
167632
167633
167634
167635
167636
167637
167638
167639
167640
167641
167642
167643
167644
167645
167646
167647
167648
167649
167650
167651
167652
167653
167654
167655
167656
167657
167658
167659
167660
167661
167662
167663
167664
167665
167666
167667
167668
167669
167670
167671
167672
167673
167674
167675
167676
167677
167678
167679
167680
167681
167682
167683
167684
167685
167686
167687
167688
167689
167690
167691
167692
167693
167694
167695
167696
167697
167698
167699
167700
167701
167702
167703
167704
167705
167706
167707
167708
167709
167710
167711
167712
167713
167714
167715
167716
167717
167718
167719
167720
167721
167722
167723
167724
167725
167726
167727
167728
167729
167730
167731
167732
167733
167734
167735
167736
167737
167738
167739
167740
167741
167742
167743
167744
167745
167746
167747
167748
167749
167750
167751
167752
167753
167754
167755
167756
167757
167758
167759
167760
167761
167762
167763
167764
167765
167766
167767
167768
167769
167770
167771
167772
167773
167774
167775
167776
167777
167778
167779
167780
167781
167782
167783
167784
167785
167786
167787
167788
167789
167790
167791
167792
167793
167794
167795
167796
167797
167798
167799
167800
167801
167802
167803
167804
167805
167806
167807
167808
167809
167810
167811
167812
167813
167814
167815
167816
167817
167818
167819
167820
167821
167822
167823
167824
167825
167826
167827
167828
167829
167830
167831
167832
167833
167834
167835
167836
167837
167838
167839
167840
167841
167842
167843
167844
167845
167846
167847
167848
167849
167850
167851
167852
167853
167854
167855
167856
167857
167858
167859
167860
167861
167862
167863
167864
167865
167866
167867
167868
167869
167870
167871
167872
167873
167874
167875
167876
167877
167878
167879
167880
167881
167882
167883
167884
167885
167886
167887
167888
167889
167890
167891
167892
167893
167894
167895
167896
167897
167898
167899
167900
167901
167902
167903
167904
167905
167906
167907
167908
167909
167910
167911
167912
167913
167914
167915
167916
167917
167918
167919
167920
167921
167922
167923
167924
167925
167926
167927
167928
167929
167930
167931
167932
167933
167934
167935
167936
167937
167938
167939
167940
167941
167942
167943
167944
167945
167946
167947
167948
167949
167950
167951
167952
167953
167954
167955
167956
167957
167958
167959
167960
167961
167962
167963
167964
167965
167966
167967
167968
167969
167970
167971
167972
167973
167974
167975
167976
167977
167978
167979
167980
167981
167982
167983
167984
167985
167986
167987
167988
167989
167990
167991
167992
167993
167994
167995
167996
167997
167998
167999
168000
168001
168002
168003
168004
168005
168006
168007
168008
168009
168010
168011
168012
168013
168014
168015
168016
168017
168018
168019
168020
168021
168022
168023
168024
168025
168026
168027
168028
168029
168030
168031
168032
168033
168034
168035
168036
168037
168038
168039
168040
168041
168042
168043
168044
168045
168046
168047
168048
168049
168050
168051
168052
168053
168054
168055
168056
168057
168058
168059
168060
168061
168062
168063
168064
168065
168066
168067
168068
168069
168070
168071
168072
168073
168074
168075
168076
168077
168078
168079
168080
168081
168082
168083
168084
168085
168086
168087
168088
168089
168090
168091
168092
168093
168094
168095
168096
168097
168098
168099
168100
168101
168102
168103
168104
168105
168106
168107
168108
168109
168110
168111
168112
168113
168114
168115
168116
168117
168118
168119
168120
168121
168122
168123
168124
168125
168126
168127
168128
168129
168130
168131
168132
168133
168134
168135
168136
168137
168138
168139
168140
168141
168142
168143
168144
168145
168146
168147
168148
168149
168150
168151
168152
168153
168154
168155
168156
168157
168158
168159
168160
168161
168162
168163
168164
168165
168166
168167
168168
168169
168170
168171
168172
168173
168174
168175
168176
168177
168178
168179
168180
168181
168182
168183
168184
168185
168186
168187
168188
168189
168190
168191
168192
168193
168194
168195
168196
168197
168198
168199
168200
168201
168202
168203
168204
168205
168206
168207
168208
168209
168210
168211
168212
168213
168214
168215
168216
168217
168218
168219
168220
168221
168222
168223
168224
168225
168226
168227
168228
168229
168230
168231
168232
168233
168234
168235
168236
168237
168238
168239
168240
168241
168242
168243
168244
168245
168246
168247
168248
168249
168250
168251
168252
168253
168254
168255
168256
168257
168258
168259
168260
168261
168262
168263
168264
168265
168266
168267
168268
168269
168270
168271
168272
168273
168274
168275
168276
168277
168278
168279
168280
168281
168282
168283
168284
168285
168286
168287
168288
168289
168290
168291
168292
168293
168294
168295
168296
168297
168298
168299
168300
168301
168302
168303
168304
168305
168306
168307
168308
168309
168310
168311
168312
168313
168314
168315
168316
168317
168318
168319
168320
168321
168322
168323
168324
168325
168326
168327
168328
168329
168330
168331
168332
168333
168334
168335
168336
168337
168338
168339
168340
168341
168342
168343
168344
168345
168346
168347
168348
168349
168350
168351
168352
168353
168354
168355
168356
168357
168358
168359
168360
168361
168362
168363
168364
168365
168366
168367
168368
168369
168370
168371
168372
168373
168374
168375
168376
168377
168378
168379
168380
168381
168382
168383
168384
168385
168386
168387
168388
168389
168390
168391
168392
168393
168394
168395
168396
168397
168398
168399
168400
168401
168402
168403
168404
168405
168406
168407
168408
168409
168410
168411
168412
168413
168414
168415
168416
168417
168418
168419
168420
168421
168422
168423
168424
168425
168426
168427
168428
168429
168430
168431
168432
168433
168434
168435
168436
168437
168438
168439
168440
168441
168442
168443
168444
168445
168446
168447
168448
168449
168450
168451
168452
168453
168454
168455
168456
168457
168458
168459
168460
168461
168462
168463
168464
168465
168466
168467
168468
168469
168470
168471
168472
168473
168474
168475
168476
168477
168478
168479
168480
168481
168482
168483
168484
168485
168486
168487
168488
168489
168490
168491
168492
168493
168494
168495
168496
168497
168498
168499
168500
168501
168502
168503
168504
168505
168506
168507
168508
168509
168510
168511
168512
168513
168514
168515
168516
168517
168518
168519
168520
168521
168522
168523
168524
168525
168526
168527
168528
168529
168530
168531
168532
168533
168534
168535
168536
168537
168538
168539
168540
168541
168542
168543
168544
168545
168546
168547
168548
168549
168550
168551
168552
168553
168554
168555
168556
168557
168558
168559
168560
168561
168562
168563
168564
168565
168566
168567
168568
168569
168570
168571
168572
168573
168574
168575
168576
168577
168578
168579
168580
168581
168582
168583
168584
168585
168586
168587
168588
168589
168590
168591
168592
168593
168594
168595
168596
168597
168598
168599
168600
168601
168602
168603
168604
168605
168606
168607
168608
168609
168610
168611
168612
168613
168614
168615
168616
168617
168618
168619
168620
168621
168622
168623
168624
168625
168626
168627
168628
168629
168630
168631
168632
168633
168634
168635
168636
168637
168638
168639
168640
168641
168642
168643
168644
168645
168646
168647
168648
168649
168650
168651
168652
168653
168654
168655
168656
168657
168658
168659
168660
168661
168662
168663
168664
168665
168666
168667
168668
168669
168670
168671
168672
168673
168674
168675
168676
168677
168678
168679
168680
168681
168682
168683
168684
168685
168686
168687
168688
168689
168690
168691
168692
168693
168694
168695
168696
168697
168698
168699
168700
168701
168702
168703
168704
168705
168706
168707
168708
168709
168710
168711
168712
168713
168714
168715
168716
168717
168718
168719
168720
168721
168722
168723
168724
168725
168726
168727
168728
168729
168730
168731
168732
168733
168734
168735
168736
168737
168738
168739
168740
168741
168742
168743
168744
168745
168746
168747
168748
168749
168750
168751
168752
168753
168754
168755
168756
168757
168758
168759
168760
168761
168762
168763
168764
168765
168766
168767
168768
168769
168770
168771
168772
168773
168774
168775
168776
168777
168778
168779
168780
168781
168782
168783
168784
168785
168786
168787
168788
168789
168790
168791
168792
168793
168794
168795
168796
168797
168798
168799
168800
168801
168802
168803
168804
168805
168806
168807
168808
168809
168810
168811
168812
168813
168814
168815
168816
168817
168818
168819
168820
168821
168822
168823
168824
168825
168826
168827
168828
168829
168830
168831
168832
168833
168834
168835
168836
168837
168838
168839
168840
168841
168842
168843
168844
168845
168846
168847
168848
168849
168850
168851
168852
168853
168854
168855
168856
168857
168858
168859
168860
168861
168862
168863
168864
168865
168866
168867
168868
168869
168870
168871
168872
168873
168874
168875
168876
168877
168878
168879
168880
168881
168882
168883
168884
168885
168886
168887
168888
168889
168890
168891
168892
168893
168894
168895
168896
168897
168898
168899
168900
168901
168902
168903
168904
168905
168906
168907
168908
168909
168910
168911
168912
168913
168914
168915
168916
168917
168918
168919
168920
168921
168922
168923
168924
168925
168926
168927
168928
168929
168930
168931
168932
168933
168934
168935
168936
168937
168938
168939
168940
168941
168942
168943
168944
168945
168946
168947
168948
168949
168950
168951
168952
168953
168954
168955
168956
168957
168958
168959
168960
168961
168962
168963
168964
168965
168966
168967
168968
168969
168970
168971
168972
168973
168974
168975
168976
168977
168978
168979
168980
168981
168982
168983
168984
168985
168986
168987
168988
168989
168990
168991
168992
168993
168994
168995
168996
168997
168998
168999
169000
169001
169002
169003
169004
169005
169006
169007
169008
169009
169010
169011
169012
169013
169014
169015
169016
169017
169018
169019
169020
169021
169022
169023
169024
169025
169026
169027
169028
169029
169030
169031
169032
169033
169034
169035
169036
169037
169038
169039
169040
169041
169042
169043
169044
169045
169046
169047
169048
169049
169050
169051
169052
169053
169054
169055
169056
169057
169058
169059
169060
169061
169062
169063
169064
169065
169066
169067
169068
169069
169070
169071
169072
169073
169074
169075
169076
169077
169078
169079
169080
169081
169082
169083
169084
169085
169086
169087
169088
169089
169090
169091
169092
169093
169094
169095
169096
169097
169098
169099
169100
169101
169102
169103
169104
169105
169106
169107
169108
169109
169110
169111
169112
169113
169114
169115
169116
169117
169118
169119
169120
169121
169122
169123
169124
169125
169126
169127
169128
169129
169130
169131
169132
169133
169134
169135
169136
169137
169138
169139
169140
169141
169142
169143
169144
169145
169146
169147
169148
169149
169150
169151
169152
169153
169154
169155
169156
169157
169158
169159
169160
169161
169162
169163
169164
169165
169166
169167
169168
169169
169170
169171
169172
169173
169174
169175
169176
169177
169178
169179
169180
169181
169182
169183
169184
169185
169186
169187
169188
169189
169190
169191
169192
169193
169194
169195
169196
169197
169198
169199
169200
169201
169202
169203
169204
169205
169206
169207
169208
169209
169210
169211
169212
169213
169214
169215
169216
169217
169218
169219
169220
169221
169222
169223
169224
169225
169226
169227
169228
169229
169230
169231
169232
169233
169234
169235
169236
169237
169238
169239
169240
169241
169242
169243
169244
169245
169246
169247
169248
169249
169250
169251
169252
169253
169254
169255
169256
169257
169258
169259
169260
169261
169262
169263
169264
169265
169266
169267
169268
169269
169270
169271
169272
169273
169274
169275
169276
169277
169278
169279
169280
169281
169282
169283
169284
169285
169286
169287
169288
169289
169290
169291
169292
169293
169294
169295
169296
169297
169298
169299
169300
169301
169302
169303
169304
169305
169306
169307
169308
169309
169310
169311
169312
169313
169314
169315
169316
169317
169318
169319
169320
169321
169322
169323
169324
169325
169326
169327
169328
169329
169330
169331
169332
169333
169334
169335
169336
169337
169338
169339
169340
169341
169342
169343
169344
169345
169346
169347
169348
169349
169350
169351
169352
169353
169354
169355
169356
169357
169358
169359
169360
169361
169362
169363
169364
169365
169366
169367
169368
169369
169370
169371
169372
169373
169374
169375
169376
169377
169378
169379
169380
169381
169382
169383
169384
169385
169386
169387
169388
169389
169390
169391
169392
169393
169394
169395
169396
169397
169398
169399
169400
169401
169402
169403
169404
169405
169406
169407
169408
169409
169410
169411
169412
169413
169414
169415
169416
169417
169418
169419
169420
169421
169422
169423
169424
169425
169426
169427
169428
169429
169430
169431
169432
169433
169434
169435
169436
169437
169438
169439
169440
169441
169442
169443
169444
169445
169446
169447
169448
169449
169450
169451
169452
169453
169454
169455
169456
169457
169458
169459
169460
169461
169462
169463
169464
169465
169466
169467
169468
169469
169470
169471
169472
169473
169474
169475
169476
169477
169478
169479
169480
169481
169482
169483
169484
169485
169486
169487
169488
169489
169490
169491
169492
169493
169494
169495
169496
169497
169498
169499
169500
169501
169502
169503
169504
169505
169506
169507
169508
169509
169510
169511
169512
169513
169514
169515
169516
169517
169518
169519
169520
169521
169522
169523
169524
169525
169526
169527
169528
169529
169530
169531
169532
169533
169534
169535
169536
169537
169538
169539
169540
169541
169542
169543
169544
169545
169546
169547
169548
169549
169550
169551
169552
169553
169554
169555
169556
169557
169558
169559
169560
169561
169562
169563
169564
169565
169566
169567
169568
169569
169570
169571
169572
169573
169574
169575
169576
169577
169578
169579
169580
169581
169582
169583
169584
169585
169586
169587
169588
169589
169590
169591
169592
169593
169594
169595
169596
169597
169598
169599
169600
169601
169602
169603
169604
169605
169606
169607
169608
169609
169610
169611
169612
169613
169614
169615
169616
169617
169618
169619
169620
169621
169622
169623
169624
169625
169626
169627
169628
169629
169630
169631
169632
169633
169634
169635
169636
169637
169638
169639
169640
169641
169642
169643
169644
169645
169646
169647
169648
169649
169650
169651
169652
169653
169654
169655
169656
169657
169658
169659
169660
169661
169662
169663
169664
169665
169666
169667
169668
169669
169670
169671
169672
169673
169674
169675
169676
169677
169678
169679
169680
169681
169682
169683
169684
169685
169686
169687
169688
169689
169690
169691
169692
169693
169694
169695
169696
169697
169698
169699
169700
169701
169702
169703
169704
169705
169706
169707
169708
169709
169710
169711
169712
169713
169714
169715
169716
169717
169718
169719
169720
169721
169722
169723
169724
169725
169726
169727
169728
169729
169730
169731
169732
169733
169734
169735
169736
169737
169738
169739
169740
169741
169742
169743
169744
169745
169746
169747
169748
169749
169750
169751
169752
169753
169754
169755
169756
169757
169758
169759
169760
169761
169762
169763
169764
169765
169766
169767
169768
169769
169770
169771
169772
169773
169774
169775
169776
169777
169778
169779
169780
169781
169782
169783
169784
169785
169786
169787
169788
169789
169790
169791
169792
169793
169794
169795
169796
169797
169798
169799
169800
169801
169802
169803
169804
169805
169806
169807
169808
169809
169810
169811
169812
169813
169814
169815
169816
169817
169818
169819
169820
169821
169822
169823
169824
169825
169826
169827
169828
169829
169830
169831
169832
169833
169834
169835
169836
169837
169838
169839
169840
169841
169842
169843
169844
169845
169846
169847
169848
169849
169850
169851
169852
169853
169854
169855
169856
169857
169858
169859
169860
169861
169862
169863
169864
169865
169866
169867
169868
169869
169870
169871
169872
169873
169874
169875
169876
169877
169878
169879
169880
169881
169882
169883
169884
169885
169886
169887
169888
169889
169890
169891
169892
169893
169894
169895
169896
169897
169898
169899
169900
169901
169902
169903
169904
169905
169906
169907
169908
169909
169910
169911
169912
169913
169914
169915
169916
169917
169918
169919
169920
169921
169922
169923
169924
169925
169926
169927
169928
169929
169930
169931
169932
169933
169934
169935
169936
169937
169938
169939
169940
169941
169942
169943
169944
169945
169946
169947
169948
169949
169950
169951
169952
169953
169954
169955
169956
169957
169958
169959
169960
169961
169962
169963
169964
169965
169966
169967
169968
169969
169970
169971
169972
169973
169974
169975
169976
169977
169978
169979
169980
169981
169982
169983
169984
169985
169986
169987
169988
169989
169990
169991
169992
169993
169994
169995
169996
169997
169998
169999
170000
170001
170002
170003
170004
170005
170006
170007
170008
170009
170010
170011
170012
170013
170014
170015
170016
170017
170018
170019
170020
170021
170022
170023
170024
170025
170026
170027
170028
170029
170030
170031
170032
170033
170034
170035
170036
170037
170038
170039
170040
170041
170042
170043
170044
170045
170046
170047
170048
170049
170050
170051
170052
170053
170054
170055
170056
170057
170058
170059
170060
170061
170062
170063
170064
170065
170066
170067
170068
170069
170070
170071
170072
170073
170074
170075
170076
170077
170078
170079
170080
170081
170082
170083
170084
170085
170086
170087
170088
170089
170090
170091
170092
170093
170094
170095
170096
170097
170098
170099
170100
170101
170102
170103
170104
170105
170106
170107
170108
170109
170110
170111
170112
170113
170114
170115
170116
170117
170118
170119
170120
170121
170122
170123
170124
170125
170126
170127
170128
170129
170130
170131
170132
170133
170134
170135
170136
170137
170138
170139
170140
170141
170142
170143
170144
170145
170146
170147
170148
170149
170150
170151
170152
170153
170154
170155
170156
170157
170158
170159
170160
170161
170162
170163
170164
170165
170166
170167
170168
170169
170170
170171
170172
170173
170174
170175
170176
170177
170178
170179
170180
170181
170182
170183
170184
170185
170186
170187
170188
170189
170190
170191
170192
170193
170194
170195
170196
170197
170198
170199
170200
170201
170202
170203
170204
170205
170206
170207
170208
170209
170210
170211
170212
170213
170214
170215
170216
170217
170218
170219
170220
170221
170222
170223
170224
170225
170226
170227
170228
170229
170230
170231
170232
170233
170234
170235
170236
170237
170238
170239
170240
170241
170242
170243
170244
170245
170246
170247
170248
170249
170250
170251
170252
170253
170254
170255
170256
170257
170258
170259
170260
170261
170262
170263
170264
170265
170266
170267
170268
170269
170270
170271
170272
170273
170274
170275
170276
170277
170278
170279
170280
170281
170282
170283
170284
170285
170286
170287
170288
170289
170290
170291
170292
170293
170294
170295
170296
170297
170298
170299
170300
170301
170302
170303
170304
170305
170306
170307
170308
170309
170310
170311
170312
170313
170314
170315
170316
170317
170318
170319
170320
170321
170322
170323
170324
170325
170326
170327
170328
170329
170330
170331
170332
170333
170334
170335
170336
170337
170338
170339
170340
170341
170342
170343
170344
170345
170346
170347
170348
170349
170350
170351
170352
170353
170354
170355
170356
170357
170358
170359
170360
170361
170362
170363
170364
170365
170366
170367
170368
170369
170370
170371
170372
170373
170374
170375
170376
170377
170378
170379
170380
170381
170382
170383
170384
170385
170386
170387
170388
170389
170390
170391
170392
170393
170394
170395
170396
170397
170398
170399
170400
170401
170402
170403
170404
170405
170406
170407
170408
170409
170410
170411
170412
170413
170414
170415
170416
170417
170418
170419
170420
170421
170422
170423
170424
170425
170426
170427
170428
170429
170430
170431
170432
170433
170434
170435
170436
170437
170438
170439
170440
170441
170442
170443
170444
170445
170446
170447
170448
170449
170450
170451
170452
170453
170454
170455
170456
170457
170458
170459
170460
170461
170462
170463
170464
170465
170466
170467
170468
170469
170470
170471
170472
170473
170474
170475
170476
170477
170478
170479
170480
170481
170482
170483
170484
170485
170486
170487
170488
170489
170490
170491
170492
170493
170494
170495
170496
170497
170498
170499
170500
170501
170502
170503
170504
170505
170506
170507
170508
170509
170510
170511
170512
170513
170514
170515
170516
170517
170518
170519
170520
170521
170522
170523
170524
170525
170526
170527
170528
170529
170530
170531
170532
170533
170534
170535
170536
170537
170538
170539
170540
170541
170542
170543
170544
170545
170546
170547
170548
170549
170550
170551
170552
170553
170554
170555
170556
170557
170558
170559
170560
170561
170562
170563
170564
170565
170566
170567
170568
170569
170570
170571
170572
170573
170574
170575
170576
170577
170578
170579
170580
170581
170582
170583
170584
170585
170586
170587
170588
170589
170590
170591
170592
170593
170594
170595
170596
170597
170598
170599
170600
170601
170602
170603
170604
170605
170606
170607
170608
170609
170610
170611
170612
170613
170614
170615
170616
170617
170618
170619
170620
170621
170622
170623
170624
170625
170626
170627
170628
170629
170630
170631
170632
170633
170634
170635
170636
170637
170638
170639
170640
170641
170642
170643
170644
170645
170646
170647
170648
170649
170650
170651
170652
170653
170654
170655
170656
170657
170658
170659
170660
170661
170662
170663
170664
170665
170666
170667
170668
170669
170670
170671
170672
170673
170674
170675
170676
170677
170678
170679
170680
170681
170682
170683
170684
170685
170686
170687
170688
170689
170690
170691
170692
170693
170694
170695
170696
170697
170698
170699
170700
170701
170702
170703
170704
170705
170706
170707
170708
170709
170710
170711
170712
170713
170714
170715
170716
170717
170718
170719
170720
170721
170722
170723
170724
170725
170726
170727
170728
170729
170730
170731
170732
170733
170734
170735
170736
170737
170738
170739
170740
170741
170742
170743
170744
170745
170746
170747
170748
170749
170750
170751
170752
170753
170754
170755
170756
170757
170758
170759
170760
170761
170762
170763
170764
170765
170766
170767
170768
170769
170770
170771
170772
170773
170774
170775
170776
170777
170778
170779
170780
170781
170782
170783
170784
170785
170786
170787
170788
170789
170790
170791
170792
170793
170794
170795
170796
170797
170798
170799
170800
170801
170802
170803
170804
170805
170806
170807
170808
170809
170810
170811
170812
170813
170814
170815
170816
170817
170818
170819
170820
170821
170822
170823
170824
170825
170826
170827
170828
170829
170830
170831
170832
170833
170834
170835
170836
170837
170838
170839
170840
170841
170842
170843
170844
170845
170846
170847
170848
170849
170850
170851
170852
170853
170854
170855
170856
170857
170858
170859
170860
170861
170862
170863
170864
170865
170866
170867
170868
170869
170870
170871
170872
170873
170874
170875
170876
170877
170878
170879
170880
170881
170882
170883
170884
170885
170886
170887
170888
170889
170890
170891
170892
170893
170894
170895
170896
170897
170898
170899
170900
170901
170902
170903
170904
170905
170906
170907
170908
170909
170910
170911
170912
170913
170914
170915
170916
170917
170918
170919
170920
170921
170922
170923
170924
170925
170926
170927
170928
170929
170930
170931
170932
170933
170934
170935
170936
170937
170938
170939
170940
170941
170942
170943
170944
170945
170946
170947
170948
170949
170950
170951
170952
170953
170954
170955
170956
170957
170958
170959
170960
170961
170962
170963
170964
170965
170966
170967
170968
170969
170970
170971
170972
170973
170974
170975
170976
170977
170978
170979
170980
170981
170982
170983
170984
170985
170986
170987
170988
170989
170990
170991
170992
170993
170994
170995
170996
170997
170998
170999
171000
171001
171002
171003
171004
171005
171006
171007
171008
171009
171010
171011
171012
171013
171014
171015
171016
171017
171018
171019
171020
171021
171022
171023
171024
171025
171026
171027
171028
171029
171030
171031
171032
171033
171034
171035
171036
171037
171038
171039
171040
171041
171042
171043
171044
171045
171046
171047
171048
171049
171050
171051
171052
171053
171054
171055
171056
171057
171058
171059
171060
171061
171062
171063
171064
171065
171066
171067
171068
171069
171070
171071
171072
171073
171074
171075
171076
171077
171078
171079
171080
171081
171082
171083
171084
171085
171086
171087
171088
171089
171090
171091
171092
171093
171094
171095
171096
171097
171098
171099
171100
171101
171102
171103
171104
171105
171106
171107
171108
171109
171110
171111
171112
171113
171114
171115
171116
171117
171118
171119
171120
171121
171122
171123
171124
171125
171126
171127
171128
171129
171130
171131
171132
171133
171134
171135
171136
171137
171138
171139
171140
171141
171142
171143
171144
171145
171146
171147
171148
171149
171150
171151
171152
171153
171154
171155
171156
171157
171158
171159
171160
171161
171162
171163
171164
171165
171166
171167
171168
171169
171170
171171
171172
171173
171174
171175
171176
171177
171178
171179
171180
171181
171182
171183
171184
171185
171186
171187
171188
171189
171190
171191
171192
171193
171194
171195
171196
171197
171198
171199
171200
171201
171202
171203
171204
171205
171206
171207
171208
171209
171210
171211
171212
171213
171214
171215
171216
171217
171218
171219
171220
171221
171222
171223
171224
171225
171226
171227
171228
171229
171230
171231
171232
171233
171234
171235
171236
171237
171238
171239
171240
171241
171242
171243
171244
171245
171246
171247
171248
171249
171250
171251
171252
171253
171254
171255
171256
171257
171258
171259
171260
171261
171262
171263
171264
171265
171266
171267
171268
171269
171270
171271
171272
171273
171274
171275
171276
171277
171278
171279
171280
171281
171282
171283
171284
171285
171286
171287
171288
171289
171290
171291
171292
171293
171294
171295
171296
171297
171298
171299
171300
171301
171302
171303
171304
171305
171306
171307
171308
171309
171310
171311
171312
171313
171314
171315
171316
171317
171318
171319
171320
171321
171322
171323
171324
171325
171326
171327
171328
171329
171330
171331
171332
171333
171334
171335
171336
171337
171338
171339
171340
171341
171342
171343
171344
171345
171346
171347
171348
171349
171350
171351
171352
171353
171354
171355
171356
171357
171358
171359
171360
171361
171362
171363
171364
171365
171366
171367
171368
171369
171370
171371
171372
171373
171374
171375
171376
171377
171378
171379
171380
171381
171382
171383
171384
171385
171386
171387
171388
171389
171390
171391
171392
171393
171394
171395
171396
171397
171398
171399
171400
171401
171402
171403
171404
171405
171406
171407
171408
171409
171410
171411
171412
171413
171414
171415
171416
171417
171418
171419
171420
171421
171422
171423
171424
171425
171426
171427
171428
171429
171430
171431
171432
171433
171434
171435
171436
171437
171438
171439
171440
171441
171442
171443
171444
171445
171446
171447
171448
171449
171450
171451
171452
171453
171454
171455
171456
171457
171458
171459
171460
171461
171462
171463
171464
171465
171466
171467
171468
171469
171470
171471
171472
171473
171474
171475
171476
171477
171478
171479
171480
171481
171482
171483
171484
171485
171486
171487
171488
171489
171490
171491
171492
171493
171494
171495
171496
171497
171498
171499
171500
171501
171502
171503
171504
171505
171506
171507
171508
171509
171510
171511
171512
171513
171514
171515
171516
171517
171518
171519
171520
171521
171522
171523
171524
171525
171526
171527
171528
171529
171530
171531
171532
171533
171534
171535
171536
171537
171538
171539
171540
171541
171542
171543
171544
171545
171546
171547
171548
171549
171550
171551
171552
171553
171554
171555
171556
171557
171558
171559
171560
171561
171562
171563
171564
171565
171566
171567
171568
171569
171570
171571
171572
171573
171574
171575
171576
171577
171578
171579
171580
171581
171582
171583
171584
171585
171586
171587
171588
171589
171590
171591
171592
171593
171594
171595
171596
171597
171598
171599
171600
171601
171602
171603
171604
171605
171606
171607
171608
171609
171610
171611
171612
171613
171614
171615
171616
171617
171618
171619
171620
171621
171622
171623
171624
171625
171626
171627
171628
171629
171630
171631
171632
171633
171634
171635
171636
171637
171638
171639
171640
171641
171642
171643
171644
171645
171646
171647
171648
171649
171650
171651
171652
171653
171654
171655
171656
171657
171658
171659
171660
171661
171662
171663
171664
171665
171666
171667
171668
171669
171670
171671
171672
171673
171674
171675
171676
171677
171678
171679
171680
171681
171682
171683
171684
171685
171686
171687
171688
171689
171690
171691
171692
171693
171694
171695
171696
171697
171698
171699
171700
171701
171702
171703
171704
171705
171706
171707
171708
171709
171710
171711
171712
171713
171714
171715
171716
171717
171718
171719
171720
171721
171722
171723
171724
171725
171726
171727
171728
171729
171730
171731
171732
171733
171734
171735
171736
171737
171738
171739
171740
171741
171742
171743
171744
171745
171746
171747
171748
171749
171750
171751
171752
171753
171754
171755
171756
171757
171758
171759
171760
171761
171762
171763
171764
171765
171766
171767
171768
171769
171770
171771
171772
171773
171774
171775
171776
171777
171778
171779
171780
171781
171782
171783
171784
171785
171786
171787
171788
171789
171790
171791
171792
171793
171794
171795
171796
171797
171798
171799
171800
171801
171802
171803
171804
171805
171806
171807
171808
171809
171810
171811
171812
171813
171814
171815
171816
171817
171818
171819
171820
171821
171822
171823
171824
171825
171826
171827
171828
171829
171830
171831
171832
171833
171834
171835
171836
171837
171838
171839
171840
171841
171842
171843
171844
171845
171846
171847
171848
171849
171850
171851
171852
171853
171854
171855
171856
171857
171858
171859
171860
171861
171862
171863
171864
171865
171866
171867
171868
171869
171870
171871
171872
171873
171874
171875
171876
171877
171878
171879
171880
171881
171882
171883
171884
171885
171886
171887
171888
171889
171890
171891
171892
171893
171894
171895
171896
171897
171898
171899
171900
171901
171902
171903
171904
171905
171906
171907
171908
171909
171910
171911
171912
171913
171914
171915
171916
171917
171918
171919
171920
171921
171922
171923
171924
171925
171926
171927
171928
171929
171930
171931
171932
171933
171934
171935
171936
171937
171938
171939
171940
171941
171942
171943
171944
171945
171946
171947
171948
171949
171950
171951
171952
171953
171954
171955
171956
171957
171958
171959
171960
171961
171962
171963
171964
171965
171966
171967
171968
171969
171970
171971
171972
171973
171974
171975
171976
171977
171978
171979
171980
171981
171982
171983
171984
171985
171986
171987
171988
171989
171990
171991
171992
171993
171994
171995
171996
171997
171998
171999
172000
172001
172002
172003
172004
172005
172006
172007
172008
172009
172010
172011
172012
172013
172014
172015
172016
172017
172018
172019
172020
172021
172022
172023
172024
172025
172026
172027
172028
172029
172030
172031
172032
172033
172034
172035
172036
172037
172038
172039
172040
172041
172042
172043
172044
172045
172046
172047
172048
172049
172050
172051
172052
172053
172054
172055
172056
172057
172058
172059
172060
172061
172062
172063
172064
172065
172066
172067
172068
172069
172070
172071
172072
172073
172074
172075
172076
172077
172078
172079
172080
172081
172082
172083
172084
172085
172086
172087
172088
172089
172090
172091
172092
172093
172094
172095
172096
172097
172098
172099
172100
172101
172102
172103
172104
172105
172106
172107
172108
172109
172110
172111
172112
172113
172114
172115
172116
172117
172118
172119
172120
172121
172122
172123
172124
172125
172126
172127
172128
172129
172130
172131
172132
172133
172134
172135
172136
172137
172138
172139
172140
172141
172142
172143
172144
172145
172146
172147
172148
172149
172150
172151
172152
172153
172154
172155
172156
172157
172158
172159
172160
172161
172162
172163
172164
172165
172166
172167
172168
172169
172170
172171
172172
172173
172174
172175
172176
172177
172178
172179
172180
172181
172182
172183
172184
172185
172186
172187
172188
172189
172190
172191
172192
172193
172194
172195
172196
172197
172198
172199
172200
172201
172202
172203
172204
172205
172206
172207
172208
172209
172210
172211
172212
172213
172214
172215
172216
172217
172218
172219
172220
172221
172222
172223
172224
172225
172226
172227
172228
172229
172230
172231
172232
172233
172234
172235
172236
172237
172238
172239
172240
172241
172242
172243
172244
172245
172246
172247
172248
172249
172250
172251
172252
172253
172254
172255
172256
172257
172258
172259
172260
172261
172262
172263
172264
172265
172266
172267
172268
172269
172270
172271
172272
172273
172274
172275
172276
172277
172278
172279
172280
172281
172282
172283
172284
172285
172286
172287
172288
172289
172290
172291
172292
172293
172294
172295
172296
172297
172298
172299
172300
172301
172302
172303
172304
172305
172306
172307
172308
172309
172310
172311
172312
172313
172314
172315
172316
172317
172318
172319
172320
172321
172322
172323
172324
172325
172326
172327
172328
172329
172330
172331
172332
172333
172334
172335
172336
172337
172338
172339
172340
172341
172342
172343
172344
172345
172346
172347
172348
172349
172350
172351
172352
172353
172354
172355
172356
172357
172358
172359
172360
172361
172362
172363
172364
172365
172366
172367
172368
172369
172370
172371
172372
172373
172374
172375
172376
172377
172378
172379
172380
172381
172382
172383
172384
172385
172386
172387
172388
172389
172390
172391
172392
172393
172394
172395
172396
172397
172398
172399
172400
172401
172402
172403
172404
172405
172406
172407
172408
172409
172410
172411
172412
172413
172414
172415
172416
172417
172418
172419
172420
172421
172422
172423
172424
172425
172426
172427
172428
172429
172430
172431
172432
172433
172434
172435
172436
172437
172438
172439
172440
172441
172442
172443
172444
172445
172446
172447
172448
172449
172450
172451
172452
172453
172454
172455
172456
172457
172458
172459
172460
172461
172462
172463
172464
172465
172466
172467
172468
172469
172470
172471
172472
172473
172474
172475
172476
172477
172478
172479
172480
172481
172482
172483
172484
172485
172486
172487
172488
172489
172490
172491
172492
172493
172494
172495
172496
172497
172498
172499
172500
172501
172502
172503
172504
172505
172506
172507
172508
172509
172510
172511
172512
172513
172514
172515
172516
172517
172518
172519
172520
172521
172522
172523
172524
172525
172526
172527
172528
172529
172530
172531
172532
172533
172534
172535
172536
172537
172538
172539
172540
172541
172542
172543
172544
172545
172546
172547
172548
172549
172550
172551
172552
172553
172554
172555
172556
172557
172558
172559
172560
172561
172562
172563
172564
172565
172566
172567
172568
172569
172570
172571
172572
172573
172574
172575
172576
172577
172578
172579
172580
172581
172582
172583
172584
172585
172586
172587
172588
172589
172590
172591
172592
172593
172594
172595
172596
172597
172598
172599
172600
172601
172602
172603
172604
172605
172606
172607
172608
172609
172610
172611
172612
172613
172614
172615
172616
172617
172618
172619
172620
172621
172622
172623
172624
172625
172626
172627
172628
172629
172630
172631
172632
172633
172634
172635
172636
172637
172638
172639
172640
172641
172642
172643
172644
172645
172646
172647
172648
172649
172650
172651
172652
172653
172654
172655
172656
172657
172658
172659
172660
172661
172662
172663
172664
172665
172666
172667
172668
172669
172670
172671
172672
172673
172674
172675
172676
172677
172678
172679
172680
172681
172682
172683
172684
172685
172686
172687
172688
172689
172690
172691
172692
172693
172694
172695
172696
172697
172698
172699
172700
172701
172702
172703
172704
172705
172706
172707
172708
172709
172710
172711
172712
172713
172714
172715
172716
172717
172718
172719
172720
172721
172722
172723
172724
172725
172726
172727
172728
172729
172730
172731
172732
172733
172734
172735
172736
172737
172738
172739
172740
172741
172742
172743
172744
172745
172746
172747
172748
172749
172750
172751
172752
172753
172754
172755
172756
172757
172758
172759
172760
172761
172762
172763
172764
172765
172766
172767
172768
172769
172770
172771
172772
172773
172774
172775
172776
172777
172778
172779
172780
172781
172782
172783
172784
172785
172786
172787
172788
172789
172790
172791
172792
172793
172794
172795
172796
172797
172798
172799
172800
172801
172802
172803
172804
172805
172806
172807
172808
172809
172810
172811
172812
172813
172814
172815
172816
172817
172818
172819
172820
172821
172822
172823
172824
172825
172826
172827
172828
172829
172830
172831
172832
172833
172834
172835
172836
172837
172838
172839
172840
172841
172842
172843
172844
172845
172846
172847
172848
172849
172850
172851
172852
172853
172854
172855
172856
172857
172858
172859
172860
172861
172862
172863
172864
172865
172866
172867
172868
172869
172870
172871
172872
172873
172874
172875
172876
172877
172878
172879
172880
172881
172882
172883
172884
172885
172886
172887
172888
172889
172890
172891
172892
172893
172894
172895
172896
172897
172898
172899
172900
172901
172902
172903
172904
172905
172906
172907
172908
172909
172910
172911
172912
172913
172914
172915
172916
172917
172918
172919
172920
172921
172922
172923
172924
172925
172926
172927
172928
172929
172930
172931
172932
172933
172934
172935
172936
172937
172938
172939
172940
172941
172942
172943
172944
172945
172946
172947
172948
172949
172950
172951
172952
172953
172954
172955
172956
172957
172958
172959
172960
172961
172962
172963
172964
172965
172966
172967
172968
172969
172970
172971
172972
172973
172974
172975
172976
172977
172978
172979
172980
172981
172982
172983
172984
172985
172986
172987
172988
172989
172990
172991
172992
172993
172994
172995
172996
172997
172998
172999
173000
173001
173002
173003
173004
173005
173006
173007
173008
173009
173010
173011
173012
173013
173014
173015
173016
173017
173018
173019
173020
173021
173022
173023
173024
173025
173026
173027
173028
173029
173030
173031
173032
173033
173034
173035
173036
173037
173038
173039
173040
173041
173042
173043
173044
173045
173046
173047
173048
173049
173050
173051
173052
173053
173054
173055
173056
173057
173058
173059
173060
173061
173062
173063
173064
173065
173066
173067
173068
173069
173070
173071
173072
173073
173074
173075
173076
173077
173078
173079
173080
173081
173082
173083
173084
173085
173086
173087
173088
173089
173090
173091
173092
173093
173094
173095
173096
173097
173098
173099
173100
173101
173102
173103
173104
173105
173106
173107
173108
173109
173110
173111
173112
173113
173114
173115
173116
173117
173118
173119
173120
173121
173122
173123
173124
173125
173126
173127
173128
173129
173130
173131
173132
173133
173134
173135
173136
173137
173138
173139
173140
173141
173142
173143
173144
173145
173146
173147
173148
173149
173150
173151
173152
173153
173154
173155
173156
173157
173158
173159
173160
173161
173162
173163
173164
173165
173166
173167
173168
173169
173170
173171
173172
173173
173174
173175
173176
173177
173178
173179
173180
173181
173182
173183
173184
173185
173186
173187
173188
173189
173190
173191
173192
173193
173194
173195
173196
173197
173198
173199
173200
173201
173202
173203
173204
173205
173206
173207
173208
173209
173210
173211
173212
173213
173214
173215
173216
173217
173218
173219
173220
173221
173222
173223
173224
173225
173226
173227
173228
173229
173230
173231
173232
173233
173234
173235
173236
173237
173238
173239
173240
173241
173242
173243
173244
173245
173246
173247
173248
173249
173250
173251
173252
173253
173254
173255
173256
173257
173258
173259
173260
173261
173262
173263
173264
173265
173266
173267
173268
173269
173270
173271
173272
173273
173274
173275
173276
173277
173278
173279
173280
173281
173282
173283
173284
173285
173286
173287
173288
173289
173290
173291
173292
173293
173294
173295
173296
173297
173298
173299
173300
173301
173302
173303
173304
173305
173306
173307
173308
173309
173310
173311
173312
173313
173314
173315
173316
173317
173318
173319
173320
173321
173322
173323
173324
173325
173326
173327
173328
173329
173330
173331
173332
173333
173334
173335
173336
173337
173338
173339
173340
173341
173342
173343
173344
173345
173346
173347
173348
173349
173350
173351
173352
173353
173354
173355
173356
173357
173358
173359
173360
173361
173362
173363
173364
173365
173366
173367
173368
173369
173370
173371
173372
173373
173374
173375
173376
173377
173378
173379
173380
173381
173382
173383
173384
173385
173386
173387
173388
173389
173390
173391
173392
173393
173394
173395
173396
173397
173398
173399
173400
173401
173402
173403
173404
173405
173406
173407
173408
173409
173410
173411
173412
173413
173414
173415
173416
173417
173418
173419
173420
173421
173422
173423
173424
173425
173426
173427
173428
173429
173430
173431
173432
173433
173434
173435
173436
173437
173438
173439
173440
173441
173442
173443
173444
173445
173446
173447
173448
173449
173450
173451
173452
173453
173454
173455
173456
173457
173458
173459
173460
173461
173462
173463
173464
173465
173466
173467
173468
173469
173470
173471
173472
173473
173474
173475
173476
173477
173478
173479
173480
173481
173482
173483
173484
173485
173486
173487
173488
173489
173490
173491
173492
173493
173494
173495
173496
173497
173498
173499
173500
173501
173502
173503
173504
173505
173506
173507
173508
173509
173510
173511
173512
173513
173514
173515
173516
173517
173518
173519
173520
173521
173522
173523
173524
173525
173526
173527
173528
173529
173530
173531
173532
173533
173534
173535
173536
173537
173538
173539
173540
173541
173542
173543
173544
173545
173546
173547
173548
173549
173550
173551
173552
173553
173554
173555
173556
173557
173558
173559
173560
173561
173562
173563
173564
173565
173566
173567
173568
173569
173570
173571
173572
173573
173574
173575
173576
173577
173578
173579
173580
173581
173582
173583
173584
173585
173586
173587
173588
173589
173590
173591
173592
173593
173594
173595
173596
173597
173598
173599
173600
173601
173602
173603
173604
173605
173606
173607
173608
173609
173610
173611
173612
173613
173614
173615
173616
173617
173618
173619
173620
173621
173622
173623
173624
173625
173626
173627
173628
173629
173630
173631
173632
173633
173634
173635
173636
173637
173638
173639
173640
173641
173642
173643
173644
173645
173646
173647
173648
173649
173650
173651
173652
173653
173654
173655
173656
173657
173658
173659
173660
173661
173662
173663
173664
173665
173666
173667
173668
173669
173670
173671
173672
173673
173674
173675
173676
173677
173678
173679
173680
173681
173682
173683
173684
173685
173686
173687
173688
173689
173690
173691
173692
173693
173694
173695
173696
173697
173698
173699
173700
173701
173702
173703
173704
173705
173706
173707
173708
173709
173710
173711
173712
173713
173714
173715
173716
173717
173718
173719
173720
173721
173722
173723
173724
173725
173726
173727
173728
173729
173730
173731
173732
173733
173734
173735
173736
173737
173738
173739
173740
173741
173742
173743
173744
173745
173746
173747
173748
173749
173750
173751
173752
173753
173754
173755
173756
173757
173758
173759
173760
173761
173762
173763
173764
173765
173766
173767
173768
173769
173770
173771
173772
173773
173774
173775
173776
173777
173778
173779
173780
173781
173782
173783
173784
173785
173786
173787
173788
173789
173790
173791
173792
173793
173794
173795
173796
173797
173798
173799
173800
173801
173802
173803
173804
173805
173806
173807
173808
173809
173810
173811
173812
173813
173814
173815
173816
173817
173818
173819
173820
173821
173822
173823
173824
173825
173826
173827
173828
173829
173830
173831
173832
173833
173834
173835
173836
173837
173838
173839
173840
173841
173842
173843
173844
173845
173846
173847
173848
173849
173850
173851
173852
173853
173854
173855
173856
173857
173858
173859
173860
173861
173862
173863
173864
173865
173866
173867
173868
173869
173870
173871
173872
173873
173874
173875
173876
173877
173878
173879
173880
173881
173882
173883
173884
173885
173886
173887
173888
173889
173890
173891
173892
173893
173894
173895
173896
173897
173898
173899
173900
173901
173902
173903
173904
173905
173906
173907
173908
173909
173910
173911
173912
173913
173914
173915
173916
173917
173918
173919
173920
173921
173922
173923
173924
173925
173926
173927
173928
173929
173930
173931
173932
173933
173934
173935
173936
173937
173938
173939
173940
173941
173942
173943
173944
173945
173946
173947
173948
173949
173950
173951
173952
173953
173954
173955
173956
173957
173958
173959
173960
173961
173962
173963
173964
173965
173966
173967
173968
173969
173970
173971
173972
173973
173974
173975
173976
173977
173978
173979
173980
173981
173982
173983
173984
173985
173986
173987
173988
173989
173990
173991
173992
173993
173994
173995
173996
173997
173998
173999
174000
174001
174002
174003
174004
174005
174006
174007
174008
174009
174010
174011
174012
174013
174014
174015
174016
174017
174018
174019
174020
174021
174022
174023
174024
174025
174026
174027
174028
174029
174030
174031
174032
174033
174034
174035
174036
174037
174038
174039
174040
174041
174042
174043
174044
174045
174046
174047
174048
174049
174050
174051
174052
174053
174054
174055
174056
174057
174058
174059
174060
174061
174062
174063
174064
174065
174066
174067
174068
174069
174070
174071
174072
174073
174074
174075
174076
174077
174078
174079
174080
174081
174082
174083
174084
174085
174086
174087
174088
174089
174090
174091
174092
174093
174094
174095
174096
174097
174098
174099
174100
174101
174102
174103
174104
174105
174106
174107
174108
174109
174110
174111
174112
174113
174114
174115
174116
174117
174118
174119
174120
174121
174122
174123
174124
174125
174126
174127
174128
174129
174130
174131
174132
174133
174134
174135
174136
174137
174138
174139
174140
174141
174142
174143
174144
174145
174146
174147
174148
174149
174150
174151
174152
174153
174154
174155
174156
174157
174158
174159
174160
174161
174162
174163
174164
174165
174166
174167
174168
174169
174170
174171
174172
174173
174174
174175
174176
174177
174178
174179
174180
174181
174182
174183
174184
174185
174186
174187
174188
174189
174190
174191
174192
174193
174194
174195
174196
174197
174198
174199
174200
174201
174202
174203
174204
174205
174206
174207
174208
174209
174210
174211
174212
174213
174214
174215
174216
174217
174218
174219
174220
174221
174222
174223
174224
174225
174226
174227
174228
174229
174230
174231
174232
174233
174234
174235
174236
174237
174238
174239
174240
174241
174242
174243
174244
174245
174246
174247
174248
174249
174250
174251
174252
174253
174254
174255
174256
174257
174258
174259
174260
174261
174262
174263
174264
174265
174266
174267
174268
174269
174270
174271
174272
174273
174274
174275
174276
174277
174278
174279
174280
174281
174282
174283
174284
174285
174286
174287
174288
174289
174290
174291
174292
174293
174294
174295
174296
174297
174298
174299
174300
174301
174302
174303
174304
174305
174306
174307
174308
174309
174310
174311
174312
174313
174314
174315
174316
174317
174318
174319
174320
174321
174322
174323
174324
174325
174326
174327
174328
174329
174330
174331
174332
174333
174334
174335
174336
174337
174338
174339
174340
174341
174342
174343
174344
174345
174346
174347
174348
174349
174350
174351
174352
174353
174354
174355
174356
174357
174358
174359
174360
174361
174362
174363
174364
174365
174366
174367
174368
174369
174370
174371
174372
174373
174374
174375
174376
174377
174378
174379
174380
174381
174382
174383
174384
174385
174386
174387
174388
174389
174390
174391
174392
174393
174394
174395
174396
174397
174398
174399
174400
174401
174402
174403
174404
174405
174406
174407
174408
174409
174410
174411
174412
174413
174414
174415
174416
174417
174418
174419
174420
174421
174422
174423
174424
174425
174426
174427
174428
174429
174430
174431
174432
174433
174434
174435
174436
174437
174438
174439
174440
174441
174442
174443
174444
174445
174446
174447
174448
174449
174450
174451
174452
174453
174454
174455
174456
174457
174458
174459
174460
174461
174462
174463
174464
174465
174466
174467
174468
174469
174470
174471
174472
174473
174474
174475
174476
174477
174478
174479
174480
174481
174482
174483
174484
174485
174486
174487
174488
174489
174490
174491
174492
174493
174494
174495
174496
174497
174498
174499
174500
174501
174502
174503
174504
174505
174506
174507
174508
174509
174510
174511
174512
174513
174514
174515
174516
174517
174518
174519
174520
174521
174522
174523
174524
174525
174526
174527
174528
174529
174530
174531
174532
174533
174534
174535
174536
174537
174538
174539
174540
174541
174542
174543
174544
174545
174546
174547
174548
174549
174550
174551
174552
174553
174554
174555
174556
174557
174558
174559
174560
174561
174562
174563
174564
174565
174566
174567
174568
174569
174570
174571
174572
174573
174574
174575
174576
174577
174578
174579
174580
174581
174582
174583
174584
174585
174586
174587
174588
174589
174590
174591
174592
174593
174594
174595
174596
174597
174598
174599
174600
174601
174602
174603
174604
174605
174606
174607
174608
174609
174610
174611
174612
174613
174614
174615
174616
174617
174618
174619
174620
174621
174622
174623
174624
174625
174626
174627
174628
174629
174630
174631
174632
174633
174634
174635
174636
174637
174638
174639
174640
174641
174642
174643
174644
174645
174646
174647
174648
174649
174650
174651
174652
174653
174654
174655
174656
174657
174658
174659
174660
174661
174662
174663
174664
174665
174666
174667
174668
174669
174670
174671
174672
174673
174674
174675
174676
174677
174678
174679
174680
174681
174682
174683
174684
174685
174686
174687
174688
174689
174690
174691
174692
174693
174694
174695
174696
174697
174698
174699
174700
174701
174702
174703
174704
174705
174706
174707
174708
174709
174710
174711
174712
174713
174714
174715
174716
174717
174718
174719
174720
174721
174722
174723
174724
174725
174726
174727
174728
174729
174730
174731
174732
174733
174734
174735
174736
174737
174738
174739
174740
174741
174742
174743
174744
174745
174746
174747
174748
174749
174750
174751
174752
174753
174754
174755
174756
174757
174758
174759
174760
174761
174762
174763
174764
174765
174766
174767
174768
174769
174770
174771
174772
174773
174774
174775
174776
174777
174778
174779
174780
174781
174782
174783
174784
174785
174786
174787
174788
174789
174790
174791
174792
174793
174794
174795
174796
174797
174798
174799
174800
174801
174802
174803
174804
174805
174806
174807
174808
174809
174810
174811
174812
174813
174814
174815
174816
174817
174818
174819
174820
174821
174822
174823
174824
174825
174826
174827
174828
174829
174830
174831
174832
174833
174834
174835
174836
174837
174838
174839
174840
174841
174842
174843
174844
174845
174846
174847
174848
174849
174850
174851
174852
174853
174854
174855
174856
174857
174858
174859
174860
174861
174862
174863
174864
174865
174866
174867
174868
174869
174870
174871
174872
174873
174874
174875
174876
174877
174878
174879
174880
174881
174882
174883
174884
174885
174886
174887
174888
174889
174890
174891
174892
174893
174894
174895
174896
174897
174898
174899
174900
174901
174902
174903
174904
174905
174906
174907
174908
174909
174910
174911
174912
174913
174914
174915
174916
174917
174918
174919
174920
174921
174922
174923
174924
174925
174926
174927
174928
174929
174930
174931
174932
174933
174934
174935
174936
174937
174938
174939
174940
174941
174942
174943
174944
174945
174946
174947
174948
174949
174950
174951
174952
174953
174954
174955
174956
174957
174958
174959
174960
174961
174962
174963
174964
174965
174966
174967
174968
174969
174970
174971
174972
174973
174974
174975
174976
174977
174978
174979
174980
174981
174982
174983
174984
174985
174986
174987
174988
174989
174990
174991
174992
174993
174994
174995
174996
174997
174998
174999
175000
175001
175002
175003
175004
175005
175006
175007
175008
175009
175010
175011
175012
175013
175014
175015
175016
175017
175018
175019
175020
175021
175022
175023
175024
175025
175026
175027
175028
175029
175030
175031
175032
175033
175034
175035
175036
175037
175038
175039
175040
175041
175042
175043
175044
175045
175046
175047
175048
175049
175050
175051
175052
175053
175054
175055
175056
175057
175058
175059
175060
175061
175062
175063
175064
175065
175066
175067
175068
175069
175070
175071
175072
175073
175074
175075
175076
175077
175078
175079
175080
175081
175082
175083
175084
175085
175086
175087
175088
175089
175090
175091
175092
175093
175094
175095
175096
175097
175098
175099
175100
175101
175102
175103
175104
175105
175106
175107
175108
175109
175110
175111
175112
175113
175114
175115
175116
175117
175118
175119
175120
175121
175122
175123
175124
175125
175126
175127
175128
175129
175130
175131
175132
175133
175134
175135
175136
175137
175138
175139
175140
175141
175142
175143
175144
175145
175146
175147
175148
175149
175150
175151
175152
175153
175154
175155
175156
175157
175158
175159
175160
175161
175162
175163
175164
175165
175166
175167
175168
175169
175170
175171
175172
175173
175174
175175
175176
175177
175178
175179
175180
175181
175182
175183
175184
175185
175186
175187
175188
175189
175190
175191
175192
175193
175194
175195
175196
175197
175198
175199
175200
175201
175202
175203
175204
175205
175206
175207
175208
175209
175210
175211
175212
175213
175214
175215
175216
175217
175218
175219
175220
175221
175222
175223
175224
175225
175226
175227
175228
175229
175230
175231
175232
175233
175234
175235
175236
175237
175238
175239
175240
175241
175242
175243
175244
175245
175246
175247
175248
175249
175250
175251
175252
175253
175254
175255
175256
175257
175258
175259
175260
175261
175262
175263
175264
175265
175266
175267
175268
175269
175270
175271
175272
175273
175274
175275
175276
175277
175278
175279
175280
175281
175282
175283
175284
175285
175286
175287
175288
175289
175290
175291
175292
175293
175294
175295
175296
175297
175298
175299
175300
175301
175302
175303
175304
175305
175306
175307
175308
175309
175310
175311
175312
175313
175314
175315
175316
175317
175318
175319
175320
175321
175322
175323
175324
175325
175326
175327
175328
175329
175330
175331
175332
175333
175334
175335
175336
175337
175338
175339
175340
175341
175342
175343
175344
175345
175346
175347
175348
175349
175350
175351
175352
175353
175354
175355
175356
175357
175358
175359
175360
175361
175362
175363
175364
175365
175366
175367
175368
175369
175370
175371
175372
175373
175374
175375
175376
175377
175378
175379
175380
175381
175382
175383
175384
175385
175386
175387
175388
175389
175390
175391
175392
175393
175394
175395
175396
175397
175398
175399
175400
175401
175402
175403
175404
175405
175406
175407
175408
175409
175410
175411
175412
175413
175414
175415
175416
175417
175418
175419
175420
175421
175422
175423
175424
175425
175426
175427
175428
175429
175430
175431
175432
175433
175434
175435
175436
175437
175438
175439
175440
175441
175442
175443
175444
175445
175446
175447
175448
175449
175450
175451
175452
175453
175454
175455
175456
175457
175458
175459
175460
175461
175462
175463
175464
175465
175466
175467
175468
175469
175470
175471
175472
175473
175474
175475
175476
175477
175478
175479
175480
175481
175482
175483
175484
175485
175486
175487
175488
175489
175490
175491
175492
175493
175494
175495
175496
175497
175498
175499
175500
175501
175502
175503
175504
175505
175506
175507
175508
175509
175510
175511
175512
175513
175514
175515
175516
175517
175518
175519
175520
175521
175522
175523
175524
175525
175526
175527
175528
175529
175530
175531
175532
175533
175534
175535
175536
175537
175538
175539
175540
175541
175542
175543
175544
175545
175546
175547
175548
175549
175550
175551
175552
175553
175554
175555
175556
175557
175558
175559
175560
175561
175562
175563
175564
175565
175566
175567
175568
175569
175570
175571
175572
175573
175574
175575
175576
175577
175578
175579
175580
175581
175582
175583
175584
175585
175586
175587
175588
175589
175590
175591
175592
175593
175594
175595
175596
175597
175598
175599
175600
175601
175602
175603
175604
175605
175606
175607
175608
175609
175610
175611
175612
175613
175614
175615
175616
175617
175618
175619
175620
175621
175622
175623
175624
175625
175626
175627
175628
175629
175630
175631
175632
175633
175634
175635
175636
175637
175638
175639
175640
175641
175642
175643
175644
175645
175646
175647
175648
175649
175650
175651
175652
175653
175654
175655
175656
175657
175658
175659
175660
175661
175662
175663
175664
175665
175666
175667
175668
175669
175670
175671
175672
175673
175674
175675
175676
175677
175678
175679
175680
175681
175682
175683
175684
175685
175686
175687
175688
175689
175690
175691
175692
175693
175694
175695
175696
175697
175698
175699
175700
175701
175702
175703
175704
175705
175706
175707
175708
175709
175710
175711
175712
175713
175714
175715
175716
175717
175718
175719
175720
175721
175722
175723
175724
175725
175726
175727
175728
175729
175730
175731
175732
175733
175734
175735
175736
175737
175738
175739
175740
175741
175742
175743
175744
175745
175746
175747
175748
175749
175750
175751
175752
175753
175754
175755
175756
175757
175758
175759
175760
175761
175762
175763
175764
175765
175766
175767
175768
175769
175770
175771
175772
175773
175774
175775
175776
175777
175778
175779
175780
175781
175782
175783
175784
175785
175786
175787
175788
175789
175790
175791
175792
175793
175794
175795
175796
175797
175798
175799
175800
175801
175802
175803
175804
175805
175806
175807
175808
175809
175810
175811
175812
175813
175814
175815
175816
175817
175818
175819
175820
175821
175822
175823
175824
175825
175826
175827
175828
175829
175830
175831
175832
175833
175834
175835
175836
175837
175838
175839
175840
175841
175842
175843
175844
175845
175846
175847
175848
175849
175850
175851
175852
175853
175854
175855
175856
175857
175858
175859
175860
175861
175862
175863
175864
175865
175866
175867
175868
175869
175870
175871
175872
175873
175874
175875
175876
175877
175878
175879
175880
175881
175882
175883
175884
175885
175886
175887
175888
175889
175890
175891
175892
175893
175894
175895
175896
175897
175898
175899
175900
175901
175902
175903
175904
175905
175906
175907
175908
175909
175910
175911
175912
175913
175914
175915
175916
175917
175918
175919
175920
175921
175922
175923
175924
175925
175926
175927
175928
175929
175930
175931
175932
175933
175934
175935
175936
175937
175938
175939
175940
175941
175942
175943
175944
175945
175946
175947
175948
175949
175950
175951
175952
175953
175954
175955
175956
175957
175958
175959
175960
175961
175962
175963
175964
175965
175966
175967
175968
175969
175970
175971
175972
175973
175974
175975
175976
175977
175978
175979
175980
175981
175982
175983
175984
175985
175986
175987
175988
175989
175990
175991
175992
175993
175994
175995
175996
175997
175998
175999
176000
176001
176002
176003
176004
176005
176006
176007
176008
176009
176010
176011
176012
176013
176014
176015
176016
176017
176018
176019
176020
176021
176022
176023
176024
176025
176026
176027
176028
176029
176030
176031
176032
176033
176034
176035
176036
176037
176038
176039
176040
176041
176042
176043
176044
176045
176046
176047
176048
176049
176050
176051
176052
176053
176054
176055
176056
176057
176058
176059
176060
176061
176062
176063
176064
176065
176066
176067
176068
176069
176070
176071
176072
176073
176074
176075
176076
176077
176078
176079
176080
176081
176082
176083
176084
176085
176086
176087
176088
176089
176090
176091
176092
176093
176094
176095
176096
176097
176098
176099
176100
176101
176102
176103
176104
176105
176106
176107
176108
176109
176110
176111
176112
176113
176114
176115
176116
176117
176118
176119
176120
176121
176122
176123
176124
176125
176126
176127
176128
176129
176130
176131
176132
176133
176134
176135
176136
176137
176138
176139
176140
176141
176142
176143
176144
176145
176146
176147
176148
176149
176150
176151
176152
176153
176154
176155
176156
176157
176158
176159
176160
176161
176162
176163
176164
176165
176166
176167
176168
176169
176170
176171
176172
176173
176174
176175
176176
176177
176178
176179
176180
176181
176182
176183
176184
176185
176186
176187
176188
176189
176190
176191
176192
176193
176194
176195
176196
176197
176198
176199
176200
176201
176202
176203
176204
176205
176206
176207
176208
176209
176210
176211
176212
176213
176214
176215
176216
176217
176218
176219
176220
176221
176222
176223
176224
176225
176226
176227
176228
176229
176230
176231
176232
176233
176234
176235
176236
176237
176238
176239
176240
176241
176242
176243
176244
176245
176246
176247
176248
176249
176250
176251
176252
176253
176254
176255
176256
176257
176258
176259
176260
176261
176262
176263
176264
176265
176266
176267
176268
176269
176270
176271
176272
176273
176274
176275
176276
176277
176278
176279
176280
176281
176282
176283
176284
176285
176286
176287
176288
176289
176290
176291
176292
176293
176294
176295
176296
176297
176298
176299
176300
176301
176302
176303
176304
176305
176306
176307
176308
176309
176310
176311
176312
176313
176314
176315
176316
176317
176318
176319
176320
176321
176322
176323
176324
176325
176326
176327
176328
176329
176330
176331
176332
176333
176334
176335
176336
176337
176338
176339
176340
176341
176342
176343
176344
176345
176346
176347
176348
176349
176350
176351
176352
176353
176354
176355
176356
176357
176358
176359
176360
176361
176362
176363
176364
176365
176366
176367
176368
176369
176370
176371
176372
176373
176374
176375
176376
176377
176378
176379
176380
176381
176382
176383
176384
176385
176386
176387
176388
176389
176390
176391
176392
176393
176394
176395
176396
176397
176398
176399
176400
176401
176402
176403
176404
176405
176406
176407
176408
176409
176410
176411
176412
176413
176414
176415
176416
176417
176418
176419
176420
176421
176422
176423
176424
176425
176426
176427
176428
176429
176430
176431
176432
176433
176434
176435
176436
176437
176438
176439
176440
176441
176442
176443
176444
176445
176446
176447
176448
176449
176450
176451
176452
176453
176454
176455
176456
176457
176458
176459
176460
176461
176462
176463
176464
176465
176466
176467
176468
176469
176470
176471
176472
176473
176474
176475
176476
176477
176478
176479
176480
176481
176482
176483
176484
176485
176486
176487
176488
176489
176490
176491
176492
176493
176494
176495
176496
176497
176498
176499
176500
176501
176502
176503
176504
176505
176506
176507
176508
176509
176510
176511
176512
176513
176514
176515
176516
176517
176518
176519
176520
176521
176522
176523
176524
176525
176526
176527
176528
176529
176530
176531
176532
176533
176534
176535
176536
176537
176538
176539
176540
176541
176542
176543
176544
176545
176546
176547
176548
176549
176550
176551
176552
176553
176554
176555
176556
176557
176558
176559
176560
176561
176562
176563
176564
176565
176566
176567
176568
176569
176570
176571
176572
176573
176574
176575
176576
176577
176578
176579
176580
176581
176582
176583
176584
176585
176586
176587
176588
176589
176590
176591
176592
176593
176594
176595
176596
176597
176598
176599
176600
176601
176602
176603
176604
176605
176606
176607
176608
176609
176610
176611
176612
176613
176614
176615
176616
176617
176618
176619
176620
176621
176622
176623
176624
176625
176626
176627
176628
176629
176630
176631
176632
176633
176634
176635
176636
176637
176638
176639
176640
176641
176642
176643
176644
176645
176646
176647
176648
176649
176650
176651
176652
176653
176654
176655
176656
176657
176658
176659
176660
176661
176662
176663
176664
176665
176666
176667
176668
176669
176670
176671
176672
176673
176674
176675
176676
176677
176678
176679
176680
176681
176682
176683
176684
176685
176686
176687
176688
176689
176690
176691
176692
176693
176694
176695
176696
176697
176698
176699
176700
176701
176702
176703
176704
176705
176706
176707
176708
176709
176710
176711
176712
176713
176714
176715
176716
176717
176718
176719
176720
176721
176722
176723
176724
176725
176726
176727
176728
176729
176730
176731
176732
176733
176734
176735
176736
176737
176738
176739
176740
176741
176742
176743
176744
176745
176746
176747
176748
176749
176750
176751
176752
176753
176754
176755
176756
176757
176758
176759
176760
176761
176762
176763
176764
176765
176766
176767
176768
176769
176770
176771
176772
176773
176774
176775
176776
176777
176778
176779
176780
176781
176782
176783
176784
176785
176786
176787
176788
176789
176790
176791
176792
176793
176794
176795
176796
176797
176798
176799
176800
176801
176802
176803
176804
176805
176806
176807
176808
176809
176810
176811
176812
176813
176814
176815
176816
176817
176818
176819
176820
176821
176822
176823
176824
176825
176826
176827
176828
176829
176830
176831
176832
176833
176834
176835
176836
176837
176838
176839
176840
176841
176842
176843
176844
176845
176846
176847
176848
176849
176850
176851
176852
176853
176854
176855
176856
176857
176858
176859
176860
176861
176862
176863
176864
176865
176866
176867
176868
176869
176870
176871
176872
176873
176874
176875
176876
176877
176878
176879
176880
176881
176882
176883
176884
176885
176886
176887
176888
176889
176890
176891
176892
176893
176894
176895
176896
176897
176898
176899
176900
176901
176902
176903
176904
176905
176906
176907
176908
176909
176910
176911
176912
176913
176914
176915
176916
176917
176918
176919
176920
176921
176922
176923
176924
176925
176926
176927
176928
176929
176930
176931
176932
176933
176934
176935
176936
176937
176938
176939
176940
176941
176942
176943
176944
176945
176946
176947
176948
176949
176950
176951
176952
176953
176954
176955
176956
176957
176958
176959
176960
176961
176962
176963
176964
176965
176966
176967
176968
176969
176970
176971
176972
176973
176974
176975
176976
176977
176978
176979
176980
176981
176982
176983
176984
176985
176986
176987
176988
176989
176990
176991
176992
176993
176994
176995
176996
176997
176998
176999
177000
177001
177002
177003
177004
177005
177006
177007
177008
177009
177010
177011
177012
177013
177014
177015
177016
177017
177018
177019
177020
177021
177022
177023
177024
177025
177026
177027
177028
177029
177030
177031
177032
177033
177034
177035
177036
177037
177038
177039
177040
177041
177042
177043
177044
177045
177046
177047
177048
177049
177050
177051
177052
177053
177054
177055
177056
177057
177058
177059
177060
177061
177062
177063
177064
177065
177066
177067
177068
177069
177070
177071
177072
177073
177074
177075
177076
177077
177078
177079
177080
177081
177082
177083
177084
177085
177086
177087
177088
177089
177090
177091
177092
177093
177094
177095
177096
177097
177098
177099
177100
177101
177102
177103
177104
177105
177106
177107
177108
177109
177110
177111
177112
177113
177114
177115
177116
177117
177118
177119
177120
177121
177122
177123
177124
177125
177126
177127
177128
177129
177130
177131
177132
177133
177134
177135
177136
177137
177138
177139
177140
177141
177142
177143
177144
177145
177146
177147
177148
177149
177150
177151
177152
177153
177154
177155
177156
177157
177158
177159
177160
177161
177162
177163
177164
177165
177166
177167
177168
177169
177170
177171
177172
177173
177174
177175
177176
177177
177178
177179
177180
177181
177182
177183
177184
177185
177186
177187
177188
177189
177190
177191
177192
177193
177194
177195
177196
177197
177198
177199
177200
177201
177202
177203
177204
177205
177206
177207
177208
177209
177210
177211
177212
177213
177214
177215
177216
177217
177218
177219
177220
177221
177222
177223
177224
177225
177226
177227
177228
177229
177230
177231
177232
177233
177234
177235
177236
177237
177238
177239
177240
177241
177242
177243
177244
177245
177246
177247
177248
177249
177250
177251
177252
177253
177254
177255
177256
177257
177258
177259
177260
177261
177262
177263
177264
177265
177266
177267
177268
177269
177270
177271
177272
177273
177274
177275
177276
177277
177278
177279
177280
177281
177282
177283
177284
177285
177286
177287
177288
177289
177290
177291
177292
177293
177294
177295
177296
177297
177298
177299
177300
177301
177302
177303
177304
177305
177306
177307
177308
177309
177310
177311
177312
177313
177314
177315
177316
177317
177318
177319
177320
177321
177322
177323
177324
177325
177326
177327
177328
177329
177330
177331
177332
177333
177334
177335
177336
177337
177338
177339
177340
177341
177342
177343
177344
177345
177346
177347
177348
177349
177350
177351
177352
177353
177354
177355
177356
177357
177358
177359
177360
177361
177362
177363
177364
177365
177366
177367
177368
177369
177370
177371
177372
177373
177374
177375
177376
177377
177378
177379
177380
177381
177382
177383
177384
177385
177386
177387
177388
177389
177390
177391
177392
177393
177394
177395
177396
177397
177398
177399
177400
177401
177402
177403
177404
177405
177406
177407
177408
177409
177410
177411
177412
177413
177414
177415
177416
177417
177418
177419
177420
177421
177422
177423
177424
177425
177426
177427
177428
177429
177430
177431
177432
177433
177434
177435
177436
177437
177438
177439
177440
177441
177442
177443
177444
177445
177446
177447
177448
177449
177450
177451
177452
177453
177454
177455
177456
177457
177458
177459
177460
177461
177462
177463
177464
177465
177466
177467
177468
177469
177470
177471
177472
177473
177474
177475
177476
177477
177478
177479
177480
177481
177482
177483
177484
177485
177486
177487
177488
177489
177490
177491
177492
177493
177494
177495
177496
177497
177498
177499
177500
177501
177502
177503
177504
177505
177506
177507
177508
177509
177510
177511
177512
177513
177514
177515
177516
177517
177518
177519
177520
177521
177522
177523
177524
177525
177526
177527
177528
177529
177530
177531
177532
177533
177534
177535
177536
177537
177538
177539
177540
177541
177542
177543
177544
177545
177546
177547
177548
177549
177550
177551
177552
177553
177554
177555
177556
177557
177558
177559
177560
177561
177562
177563
177564
177565
177566
177567
177568
177569
177570
177571
177572
177573
177574
177575
177576
177577
177578
177579
177580
177581
177582
177583
177584
177585
177586
177587
177588
177589
177590
177591
177592
177593
177594
177595
177596
177597
177598
177599
177600
177601
177602
177603
177604
177605
177606
177607
177608
177609
177610
177611
177612
177613
177614
177615
177616
177617
177618
177619
177620
177621
177622
177623
177624
177625
177626
177627
177628
177629
177630
177631
177632
177633
177634
177635
177636
177637
177638
177639
177640
177641
177642
177643
177644
177645
177646
177647
177648
177649
177650
177651
177652
177653
177654
177655
177656
177657
177658
177659
177660
177661
177662
177663
177664
177665
177666
177667
177668
177669
177670
177671
177672
177673
177674
177675
177676
177677
177678
177679
177680
177681
177682
177683
177684
177685
177686
177687
177688
177689
177690
177691
177692
177693
177694
177695
177696
177697
177698
177699
177700
177701
177702
177703
177704
177705
177706
177707
177708
177709
177710
177711
177712
177713
177714
177715
177716
177717
177718
177719
177720
177721
177722
177723
177724
177725
177726
177727
177728
177729
177730
177731
177732
177733
177734
177735
177736
177737
177738
177739
177740
177741
177742
177743
177744
177745
177746
177747
177748
177749
177750
177751
177752
177753
177754
177755
177756
177757
177758
177759
177760
177761
177762
177763
177764
177765
177766
177767
177768
177769
177770
177771
177772
177773
177774
177775
177776
177777
177778
177779
177780
177781
177782
177783
177784
177785
177786
177787
177788
177789
177790
177791
177792
177793
177794
177795
177796
177797
177798
177799
177800
177801
177802
177803
177804
177805
177806
177807
177808
177809
177810
177811
177812
177813
177814
177815
177816
177817
177818
177819
177820
177821
177822
177823
177824
177825
177826
177827
177828
177829
177830
177831
177832
177833
177834
177835
177836
177837
177838
177839
177840
177841
177842
177843
177844
177845
177846
177847
177848
177849
177850
177851
177852
177853
177854
177855
177856
177857
177858
177859
177860
177861
177862
177863
177864
177865
177866
177867
177868
177869
177870
177871
177872
177873
177874
177875
177876
177877
177878
177879
177880
177881
177882
177883
177884
177885
177886
177887
177888
177889
177890
177891
177892
177893
177894
177895
177896
177897
177898
177899
177900
177901
177902
177903
177904
177905
177906
177907
177908
177909
177910
177911
177912
177913
177914
177915
177916
177917
177918
177919
177920
177921
177922
177923
177924
177925
177926
177927
177928
177929
177930
177931
177932
177933
177934
177935
177936
177937
177938
177939
177940
177941
177942
177943
177944
177945
177946
177947
177948
177949
177950
177951
177952
177953
177954
177955
177956
177957
177958
177959
177960
177961
177962
177963
177964
177965
177966
177967
177968
177969
177970
177971
177972
177973
177974
177975
177976
177977
177978
177979
177980
177981
177982
177983
177984
177985
177986
177987
177988
177989
177990
177991
177992
177993
177994
177995
177996
177997
177998
177999
178000
178001
178002
178003
178004
178005
178006
178007
178008
178009
178010
178011
178012
178013
178014
178015
178016
178017
178018
178019
178020
178021
178022
178023
178024
178025
178026
178027
178028
178029
178030
178031
178032
178033
178034
178035
178036
178037
178038
178039
178040
178041
178042
178043
178044
178045
178046
178047
178048
178049
178050
178051
178052
178053
178054
178055
178056
178057
178058
178059
178060
178061
178062
178063
178064
178065
178066
178067
178068
178069
178070
178071
178072
178073
178074
178075
178076
178077
178078
178079
178080
178081
178082
178083
178084
178085
178086
178087
178088
178089
178090
178091
178092
178093
178094
178095
178096
178097
178098
178099
178100
178101
178102
178103
178104
178105
178106
178107
178108
178109
178110
178111
178112
178113
178114
178115
178116
178117
178118
178119
178120
178121
178122
178123
178124
178125
178126
178127
178128
178129
178130
178131
178132
178133
178134
178135
178136
178137
178138
178139
178140
178141
178142
178143
178144
178145
178146
178147
178148
178149
178150
178151
178152
178153
178154
178155
178156
178157
178158
178159
178160
178161
178162
178163
178164
178165
178166
178167
178168
178169
178170
178171
178172
178173
178174
178175
178176
178177
178178
178179
178180
178181
178182
178183
178184
178185
178186
178187
178188
178189
178190
178191
178192
178193
178194
178195
178196
178197
178198
178199
178200
178201
178202
178203
178204
178205
178206
178207
178208
178209
178210
178211
178212
178213
178214
178215
178216
178217
178218
178219
178220
178221
178222
178223
178224
178225
178226
178227
178228
178229
178230
178231
178232
178233
178234
178235
178236
178237
178238
178239
178240
178241
178242
178243
178244
178245
178246
178247
178248
178249
178250
178251
178252
178253
178254
178255
178256
178257
178258
178259
178260
178261
178262
178263
178264
178265
178266
178267
178268
178269
178270
178271
178272
178273
178274
178275
178276
178277
178278
178279
178280
178281
178282
178283
178284
178285
178286
178287
178288
178289
178290
178291
178292
178293
178294
178295
178296
178297
178298
178299
178300
178301
178302
178303
178304
178305
178306
178307
178308
178309
178310
178311
178312
178313
178314
178315
178316
178317
178318
178319
178320
178321
178322
178323
178324
178325
178326
178327
178328
178329
178330
178331
178332
178333
178334
178335
178336
178337
178338
178339
178340
178341
178342
178343
178344
178345
178346
178347
178348
178349
178350
178351
178352
178353
178354
178355
178356
178357
178358
178359
178360
178361
178362
178363
178364
178365
178366
178367
178368
178369
178370
178371
178372
178373
178374
178375
178376
178377
178378
178379
178380
178381
178382
178383
178384
178385
178386
178387
178388
178389
178390
178391
178392
178393
178394
178395
178396
178397
178398
178399
178400
178401
178402
178403
178404
178405
178406
178407
178408
178409
178410
178411
178412
178413
178414
178415
178416
178417
178418
178419
178420
178421
178422
178423
178424
178425
178426
178427
178428
178429
178430
178431
178432
178433
178434
178435
178436
178437
178438
178439
178440
178441
178442
178443
178444
178445
178446
178447
178448
178449
178450
178451
178452
178453
178454
178455
178456
178457
178458
178459
178460
178461
178462
178463
178464
178465
178466
178467
178468
178469
178470
178471
178472
178473
178474
178475
178476
178477
178478
178479
178480
178481
178482
178483
178484
178485
178486
178487
178488
178489
178490
178491
178492
178493
178494
178495
178496
178497
178498
178499
178500
178501
178502
178503
178504
178505
178506
178507
178508
178509
178510
178511
178512
178513
178514
178515
178516
178517
178518
178519
178520
178521
178522
178523
178524
178525
178526
178527
178528
178529
178530
178531
178532
178533
178534
178535
178536
178537
178538
178539
178540
178541
178542
178543
178544
178545
178546
178547
178548
178549
178550
178551
178552
178553
178554
178555
178556
178557
178558
178559
178560
178561
178562
178563
178564
178565
178566
178567
178568
178569
178570
178571
178572
178573
178574
178575
178576
178577
178578
178579
178580
178581
178582
178583
178584
178585
178586
178587
178588
178589
178590
178591
178592
178593
178594
178595
178596
178597
178598
178599
178600
178601
178602
178603
178604
178605
178606
178607
178608
178609
178610
178611
178612
178613
178614
178615
178616
178617
178618
178619
178620
178621
178622
178623
178624
178625
178626
178627
178628
178629
178630
178631
178632
178633
178634
178635
178636
178637
178638
178639
178640
178641
178642
178643
178644
178645
178646
178647
178648
178649
178650
178651
178652
178653
178654
178655
178656
178657
178658
178659
178660
178661
178662
178663
178664
178665
178666
178667
178668
178669
178670
178671
178672
178673
178674
178675
178676
178677
178678
178679
178680
178681
178682
178683
178684
178685
178686
178687
178688
178689
178690
178691
178692
178693
178694
178695
178696
178697
178698
178699
178700
178701
178702
178703
178704
178705
178706
178707
178708
178709
178710
178711
178712
178713
178714
178715
178716
178717
178718
178719
178720
178721
178722
178723
178724
178725
178726
178727
178728
178729
178730
178731
178732
178733
178734
178735
178736
178737
178738
178739
178740
178741
178742
178743
178744
178745
178746
178747
178748
178749
178750
178751
178752
178753
178754
178755
178756
178757
178758
178759
178760
178761
178762
178763
178764
178765
178766
178767
178768
178769
178770
178771
178772
178773
178774
178775
178776
178777
178778
178779
178780
178781
178782
178783
178784
178785
178786
178787
178788
178789
178790
178791
178792
178793
178794
178795
178796
178797
178798
178799
178800
178801
178802
178803
178804
178805
178806
178807
178808
178809
178810
178811
178812
178813
178814
178815
178816
178817
178818
178819
178820
178821
178822
178823
178824
178825
178826
178827
178828
178829
178830
178831
178832
178833
178834
178835
178836
178837
178838
178839
178840
178841
178842
178843
178844
178845
178846
178847
178848
178849
178850
178851
178852
178853
178854
178855
178856
178857
178858
178859
178860
178861
178862
178863
178864
178865
178866
178867
178868
178869
178870
178871
178872
178873
178874
178875
178876
178877
178878
178879
178880
178881
178882
178883
178884
178885
178886
178887
178888
178889
178890
178891
178892
178893
178894
178895
178896
178897
178898
178899
178900
178901
178902
178903
178904
178905
178906
178907
178908
178909
178910
178911
178912
178913
178914
178915
178916
178917
178918
178919
178920
178921
178922
178923
178924
178925
178926
178927
178928
178929
178930
178931
178932
178933
178934
178935
178936
178937
178938
178939
178940
178941
178942
178943
178944
178945
178946
178947
178948
178949
178950
178951
178952
178953
178954
178955
178956
178957
178958
178959
178960
178961
178962
178963
178964
178965
178966
178967
178968
178969
178970
178971
178972
178973
178974
178975
178976
178977
178978
178979
178980
178981
178982
178983
178984
178985
178986
178987
178988
178989
178990
178991
178992
178993
178994
178995
178996
178997
178998
178999
179000
179001
179002
179003
179004
179005
179006
179007
179008
179009
179010
179011
179012
179013
179014
179015
179016
179017
179018
179019
179020
179021
179022
179023
179024
179025
179026
179027
179028
179029
179030
179031
179032
179033
179034
179035
179036
179037
179038
179039
179040
179041
179042
179043
179044
179045
179046
179047
179048
179049
179050
179051
179052
179053
179054
179055
179056
179057
179058
179059
179060
179061
179062
179063
179064
179065
179066
179067
179068
179069
179070
179071
179072
179073
179074
179075
179076
179077
179078
179079
179080
179081
179082
179083
179084
179085
179086
179087
179088
179089
179090
179091
179092
179093
179094
179095
179096
179097
179098
179099
179100
179101
179102
179103
179104
179105
179106
179107
179108
179109
179110
179111
179112
179113
179114
179115
179116
179117
179118
179119
179120
179121
179122
179123
179124
179125
179126
179127
179128
179129
179130
179131
179132
179133
179134
179135
179136
179137
179138
179139
179140
179141
179142
179143
179144
179145
179146
179147
179148
179149
179150
179151
179152
179153
179154
179155
179156
179157
179158
179159
179160
179161
179162
179163
179164
179165
179166
179167
179168
179169
179170
179171
179172
179173
179174
179175
179176
179177
179178
179179
179180
179181
179182
179183
179184
179185
179186
179187
179188
179189
179190
179191
179192
179193
179194
179195
179196
179197
179198
179199
179200
179201
179202
179203
179204
179205
179206
179207
179208
179209
179210
179211
179212
179213
179214
179215
179216
179217
179218
179219
179220
179221
179222
179223
179224
179225
179226
179227
179228
179229
179230
179231
179232
179233
179234
179235
179236
179237
179238
179239
179240
179241
179242
179243
179244
179245
179246
179247
179248
179249
179250
179251
179252
179253
179254
179255
179256
179257
179258
179259
179260
179261
179262
179263
179264
179265
179266
179267
179268
179269
179270
179271
179272
179273
179274
179275
179276
179277
179278
179279
179280
179281
179282
179283
179284
179285
179286
179287
179288
179289
179290
179291
179292
179293
179294
179295
179296
179297
179298
179299
179300
179301
179302
179303
179304
179305
179306
179307
179308
179309
179310
179311
179312
179313
179314
179315
179316
179317
179318
179319
179320
179321
179322
179323
179324
179325
179326
179327
179328
179329
179330
179331
179332
179333
179334
179335
179336
179337
179338
179339
179340
179341
179342
179343
179344
179345
179346
179347
179348
179349
179350
179351
179352
179353
179354
179355
179356
179357
179358
179359
179360
179361
179362
179363
179364
179365
179366
179367
179368
179369
179370
179371
179372
179373
179374
179375
179376
179377
179378
179379
179380
179381
179382
179383
179384
179385
179386
179387
179388
179389
179390
179391
179392
179393
179394
179395
179396
179397
179398
179399
179400
179401
179402
179403
179404
179405
179406
179407
179408
179409
179410
179411
179412
179413
179414
179415
179416
179417
179418
179419
179420
179421
179422
179423
179424
179425
179426
179427
179428
179429
179430
179431
179432
179433
179434
179435
179436
179437
179438
179439
179440
179441
179442
179443
179444
179445
179446
179447
179448
179449
179450
179451
179452
179453
179454
179455
179456
179457
179458
179459
179460
179461
179462
179463
179464
179465
179466
179467
179468
179469
179470
179471
179472
179473
179474
179475
179476
179477
179478
179479
179480
179481
179482
179483
179484
179485
179486
179487
179488
179489
179490
179491
179492
179493
179494
179495
179496
179497
179498
179499
179500
179501
179502
179503
179504
179505
179506
179507
179508
179509
179510
179511
179512
179513
179514
179515
179516
179517
179518
179519
179520
179521
179522
179523
179524
179525
179526
179527
179528
179529
179530
179531
179532
179533
179534
179535
179536
179537
179538
179539
179540
179541
179542
179543
179544
179545
179546
179547
179548
179549
179550
179551
179552
179553
179554
179555
179556
179557
179558
179559
179560
179561
179562
179563
179564
179565
179566
179567
179568
179569
179570
179571
179572
179573
179574
179575
179576
179577
179578
179579
179580
179581
179582
179583
179584
179585
179586
179587
179588
179589
179590
179591
179592
179593
179594
179595
179596
179597
179598
179599
179600
179601
179602
179603
179604
179605
179606
179607
179608
179609
179610
179611
179612
179613
179614
179615
179616
179617
179618
179619
179620
179621
179622
179623
179624
179625
179626
179627
179628
179629
179630
179631
179632
179633
179634
179635
179636
179637
179638
179639
179640
179641
179642
179643
179644
179645
179646
179647
179648
179649
179650
179651
179652
179653
179654
179655
179656
179657
179658
179659
179660
179661
179662
179663
179664
179665
179666
179667
179668
179669
179670
179671
179672
179673
179674
179675
179676
179677
179678
179679
179680
179681
179682
179683
179684
179685
179686
179687
179688
179689
179690
179691
179692
179693
179694
179695
179696
179697
179698
179699
179700
179701
179702
179703
179704
179705
179706
179707
179708
179709
179710
179711
179712
179713
179714
179715
179716
179717
179718
179719
179720
179721
179722
179723
179724
179725
179726
179727
179728
179729
179730
179731
179732
179733
179734
179735
179736
179737
179738
179739
179740
179741
179742
179743
179744
179745
179746
179747
179748
179749
179750
179751
179752
179753
179754
179755
179756
179757
179758
179759
179760
179761
179762
179763
179764
179765
179766
179767
179768
179769
179770
179771
179772
179773
179774
179775
179776
179777
179778
179779
179780
179781
179782
179783
179784
179785
179786
179787
179788
179789
179790
179791
179792
179793
179794
179795
179796
179797
179798
179799
179800
179801
179802
179803
179804
179805
179806
179807
179808
179809
179810
179811
179812
179813
179814
179815
179816
179817
179818
179819
179820
179821
179822
179823
179824
179825
179826
179827
179828
179829
179830
179831
179832
179833
179834
179835
179836
179837
179838
179839
179840
179841
179842
179843
179844
179845
179846
179847
179848
179849
179850
179851
179852
179853
179854
179855
179856
179857
179858
179859
179860
179861
179862
179863
179864
179865
179866
179867
179868
179869
179870
179871
179872
179873
179874
179875
179876
179877
179878
179879
179880
179881
179882
179883
179884
179885
179886
179887
179888
179889
179890
179891
179892
179893
179894
179895
179896
179897
179898
179899
179900
179901
179902
179903
179904
179905
179906
179907
179908
179909
179910
179911
179912
179913
179914
179915
179916
179917
179918
179919
179920
179921
179922
179923
179924
179925
179926
179927
179928
179929
179930
179931
179932
179933
179934
179935
179936
179937
179938
179939
179940
179941
179942
179943
179944
179945
179946
179947
179948
179949
179950
179951
179952
179953
179954
179955
179956
179957
179958
179959
179960
179961
179962
179963
179964
179965
179966
179967
179968
179969
179970
179971
179972
179973
179974
179975
179976
179977
179978
179979
179980
179981
179982
179983
179984
179985
179986
179987
179988
179989
179990
179991
179992
179993
179994
179995
179996
179997
179998
179999
180000
180001
180002
180003
180004
180005
180006
180007
180008
180009
180010
180011
180012
180013
180014
180015
180016
180017
180018
180019
180020
180021
180022
180023
180024
180025
180026
180027
180028
180029
180030
180031
180032
180033
180034
180035
180036
180037
180038
180039
180040
180041
180042
180043
180044
180045
180046
180047
180048
180049
180050
180051
180052
180053
180054
180055
180056
180057
180058
180059
180060
180061
180062
180063
180064
180065
180066
180067
180068
180069
180070
180071
180072
180073
180074
180075
180076
180077
180078
180079
180080
180081
180082
180083
180084
180085
180086
180087
180088
180089
180090
180091
180092
180093
180094
180095
180096
180097
180098
180099
180100
180101
180102
180103
180104
180105
180106
180107
180108
180109
180110
180111
180112
180113
180114
180115
180116
180117
180118
180119
180120
180121
180122
180123
180124
180125
180126
180127
180128
180129
180130
180131
180132
180133
180134
180135
180136
180137
180138
180139
180140
180141
180142
180143
180144
180145
180146
180147
180148
180149
180150
180151
180152
180153
180154
180155
180156
180157
180158
180159
180160
180161
180162
180163
180164
180165
180166
180167
180168
180169
180170
180171
180172
180173
180174
180175
180176
180177
180178
180179
180180
180181
180182
180183
180184
180185
180186
180187
180188
180189
180190
180191
180192
180193
180194
180195
180196
180197
180198
180199
180200
180201
180202
180203
180204
180205
180206
180207
180208
180209
180210
180211
180212
180213
180214
180215
180216
180217
180218
180219
180220
180221
180222
180223
180224
180225
180226
180227
180228
180229
180230
180231
180232
180233
180234
180235
180236
180237
180238
180239
180240
180241
180242
180243
180244
180245
180246
180247
180248
180249
180250
180251
180252
180253
180254
180255
180256
180257
180258
180259
180260
180261
180262
180263
180264
180265
180266
180267
180268
180269
180270
180271
180272
180273
180274
180275
180276
180277
180278
180279
180280
180281
180282
180283
180284
180285
180286
180287
180288
180289
180290
180291
180292
180293
180294
180295
180296
180297
180298
180299
180300
180301
180302
180303
180304
180305
180306
180307
180308
180309
180310
180311
180312
180313
180314
180315
180316
180317
180318
180319
180320
180321
180322
180323
180324
180325
180326
180327
180328
180329
180330
180331
180332
180333
180334
180335
180336
180337
180338
180339
180340
180341
180342
180343
180344
180345
180346
180347
180348
180349
180350
180351
180352
180353
180354
180355
180356
180357
180358
180359
180360
180361
180362
180363
180364
180365
180366
180367
180368
180369
180370
180371
180372
180373
180374
180375
180376
180377
180378
180379
180380
180381
180382
180383
180384
180385
180386
180387
180388
180389
180390
180391
180392
180393
180394
180395
180396
180397
180398
180399
180400
180401
180402
180403
180404
180405
180406
180407
180408
180409
180410
180411
180412
180413
180414
180415
180416
180417
180418
180419
180420
180421
180422
180423
180424
180425
180426
180427
180428
180429
180430
180431
180432
180433
180434
180435
180436
180437
180438
180439
180440
180441
180442
180443
180444
180445
180446
180447
180448
180449
180450
180451
180452
180453
180454
180455
180456
180457
180458
180459
180460
180461
180462
180463
180464
180465
180466
180467
180468
180469
180470
180471
180472
180473
180474
180475
180476
180477
180478
180479
180480
180481
180482
180483
180484
180485
180486
180487
180488
180489
180490
180491
180492
180493
180494
180495
180496
180497
180498
180499
180500
180501
180502
180503
180504
180505
180506
180507
180508
180509
180510
180511
180512
180513
180514
180515
180516
180517
180518
180519
180520
180521
180522
180523
180524
180525
180526
180527
180528
180529
180530
180531
180532
180533
180534
180535
180536
180537
180538
180539
180540
180541
180542
180543
180544
180545
180546
180547
180548
180549
180550
180551
180552
180553
180554
180555
180556
180557
180558
180559
180560
180561
180562
180563
180564
180565
180566
180567
180568
180569
180570
180571
180572
180573
180574
180575
180576
180577
180578
180579
180580
180581
180582
180583
180584
180585
180586
180587
180588
180589
180590
180591
180592
180593
180594
180595
180596
180597
180598
180599
180600
180601
180602
180603
180604
180605
180606
180607
180608
180609
180610
180611
180612
180613
180614
180615
180616
180617
180618
180619
180620
180621
180622
180623
180624
180625
180626
180627
180628
180629
180630
180631
180632
180633
180634
180635
180636
180637
180638
180639
180640
180641
180642
180643
180644
180645
180646
180647
180648
180649
180650
180651
180652
180653
180654
180655
180656
180657
180658
180659
180660
180661
180662
180663
180664
180665
180666
180667
180668
180669
180670
180671
180672
180673
180674
180675
180676
180677
180678
180679
180680
180681
180682
180683
180684
180685
180686
180687
180688
180689
180690
180691
180692
180693
180694
180695
180696
180697
180698
180699
180700
180701
180702
180703
180704
180705
180706
180707
180708
180709
180710
180711
180712
180713
180714
180715
180716
180717
180718
180719
180720
180721
180722
180723
180724
180725
180726
180727
180728
180729
180730
180731
180732
180733
180734
180735
180736
180737
180738
180739
180740
180741
180742
180743
180744
180745
180746
180747
180748
180749
180750
180751
180752
180753
180754
180755
180756
180757
180758
180759
180760
180761
180762
180763
180764
180765
180766
180767
180768
180769
180770
180771
180772
180773
180774
180775
180776
180777
180778
180779
180780
180781
180782
180783
180784
180785
180786
180787
180788
180789
180790
180791
180792
180793
180794
180795
180796
180797
180798
180799
180800
180801
180802
180803
180804
180805
180806
180807
180808
180809
180810
180811
180812
180813
180814
180815
180816
180817
180818
180819
180820
180821
180822
180823
180824
180825
180826
180827
180828
180829
180830
180831
180832
180833
180834
180835
180836
180837
180838
180839
180840
180841
180842
180843
180844
180845
180846
180847
180848
180849
180850
180851
180852
180853
180854
180855
180856
180857
180858
180859
180860
180861
180862
180863
180864
180865
180866
180867
180868
180869
180870
180871
180872
180873
180874
180875
180876
180877
180878
180879
180880
180881
180882
180883
180884
180885
180886
180887
180888
180889
180890
180891
180892
180893
180894
180895
180896
180897
180898
180899
180900
180901
180902
180903
180904
180905
180906
180907
180908
180909
180910
180911
180912
180913
180914
180915
180916
180917
180918
180919
180920
180921
180922
180923
180924
180925
180926
180927
180928
180929
180930
180931
180932
180933
180934
180935
180936
180937
180938
180939
180940
180941
180942
180943
180944
180945
180946
180947
180948
180949
180950
180951
180952
180953
180954
180955
180956
180957
180958
180959
180960
180961
180962
180963
180964
180965
180966
180967
180968
180969
180970
180971
180972
180973
180974
180975
180976
180977
180978
180979
180980
180981
180982
180983
180984
180985
180986
180987
180988
180989
180990
180991
180992
180993
180994
180995
180996
180997
180998
180999
181000
181001
181002
181003
181004
181005
181006
181007
181008
181009
181010
181011
181012
181013
181014
181015
181016
181017
181018
181019
181020
181021
181022
181023
181024
181025
181026
181027
181028
181029
181030
181031
181032
181033
181034
181035
181036
181037
181038
181039
181040
181041
181042
181043
181044
181045
181046
181047
181048
181049
181050
181051
181052
181053
181054
181055
181056
181057
181058
181059
181060
181061
181062
181063
181064
181065
181066
181067
181068
181069
181070
181071
181072
181073
181074
181075
181076
181077
181078
181079
181080
181081
181082
181083
181084
181085
181086
181087
181088
181089
181090
181091
181092
181093
181094
181095
181096
181097
181098
181099
181100
181101
181102
181103
181104
181105
181106
181107
181108
181109
181110
181111
181112
181113
181114
181115
181116
181117
181118
181119
181120
181121
181122
181123
181124
181125
181126
181127
181128
181129
181130
181131
181132
181133
181134
181135
181136
181137
181138
181139
181140
181141
181142
181143
181144
181145
181146
181147
181148
181149
181150
181151
181152
181153
181154
181155
181156
181157
181158
181159
181160
181161
181162
181163
181164
181165
181166
181167
181168
181169
181170
181171
181172
181173
181174
181175
181176
181177
181178
181179
181180
181181
181182
181183
181184
181185
181186
181187
181188
181189
181190
181191
181192
181193
181194
181195
181196
181197
181198
181199
181200
181201
181202
181203
181204
181205
181206
181207
181208
181209
181210
181211
181212
181213
181214
181215
181216
181217
181218
181219
181220
181221
181222
181223
181224
181225
181226
181227
181228
181229
181230
181231
181232
181233
181234
181235
181236
181237
181238
181239
181240
181241
181242
181243
181244
181245
181246
181247
181248
181249
181250
181251
181252
181253
181254
181255
181256
181257
181258
181259
181260
181261
181262
181263
181264
181265
181266
181267
181268
181269
181270
181271
181272
181273
181274
181275
181276
181277
181278
181279
181280
181281
181282
181283
181284
181285
181286
181287
181288
181289
181290
181291
181292
181293
181294
181295
181296
181297
181298
181299
181300
181301
181302
181303
181304
181305
181306
181307
181308
181309
181310
181311
181312
181313
181314
181315
181316
181317
181318
181319
181320
181321
181322
181323
181324
181325
181326
181327
181328
181329
181330
181331
181332
181333
181334
181335
181336
181337
181338
181339
181340
181341
181342
181343
181344
181345
181346
181347
181348
181349
181350
181351
181352
181353
181354
181355
181356
181357
181358
181359
181360
181361
181362
181363
181364
181365
181366
181367
181368
181369
181370
181371
181372
181373
181374
181375
181376
181377
181378
181379
181380
181381
181382
181383
181384
181385
181386
181387
181388
181389
181390
181391
181392
181393
181394
181395
181396
181397
181398
181399
181400
181401
181402
181403
181404
181405
181406
181407
181408
181409
181410
181411
181412
181413
181414
181415
181416
181417
181418
181419
181420
181421
181422
181423
181424
181425
181426
181427
181428
181429
181430
181431
181432
181433
181434
181435
181436
181437
181438
181439
181440
181441
181442
181443
181444
181445
181446
181447
181448
181449
181450
181451
181452
181453
181454
181455
181456
181457
181458
181459
181460
181461
181462
181463
181464
181465
181466
181467
181468
181469
181470
181471
181472
181473
181474
181475
181476
181477
181478
181479
181480
181481
181482
181483
181484
181485
181486
181487
181488
181489
181490
181491
181492
181493
181494
181495
181496
181497
181498
181499
181500
181501
181502
181503
181504
181505
181506
181507
181508
181509
181510
181511
181512
181513
181514
181515
181516
181517
181518
181519
181520
181521
181522
181523
181524
181525
181526
181527
181528
181529
181530
181531
181532
181533
181534
181535
181536
181537
181538
181539
181540
181541
181542
181543
181544
181545
181546
181547
181548
181549
181550
181551
181552
181553
181554
181555
181556
181557
181558
181559
181560
181561
181562
181563
181564
181565
181566
181567
181568
181569
181570
181571
181572
181573
181574
181575
181576
181577
181578
181579
181580
181581
181582
181583
181584
181585
181586
181587
181588
181589
181590
181591
181592
181593
181594
181595
181596
181597
181598
181599
181600
181601
181602
181603
181604
181605
181606
181607
181608
181609
181610
181611
181612
181613
181614
181615
181616
181617
181618
181619
181620
181621
181622
181623
181624
181625
181626
181627
181628
181629
181630
181631
181632
181633
181634
181635
181636
181637
181638
181639
181640
181641
181642
181643
181644
181645
181646
181647
181648
181649
181650
181651
181652
181653
181654
181655
181656
181657
181658
181659
181660
181661
181662
181663
181664
181665
181666
181667
181668
181669
181670
181671
181672
181673
181674
181675
181676
181677
181678
181679
181680
181681
181682
181683
181684
181685
181686
181687
181688
181689
181690
181691
181692
181693
181694
181695
181696
181697
181698
181699
181700
181701
181702
181703
181704
181705
181706
181707
181708
181709
181710
181711
181712
181713
181714
181715
181716
181717
181718
181719
181720
181721
181722
181723
181724
181725
181726
181727
181728
181729
181730
181731
181732
181733
181734
181735
181736
181737
181738
181739
181740
181741
181742
181743
181744
181745
181746
181747
181748
181749
181750
181751
181752
181753
181754
181755
181756
181757
181758
181759
181760
181761
181762
181763
181764
181765
181766
181767
181768
181769
181770
181771
181772
181773
181774
181775
181776
181777
181778
181779
181780
181781
181782
181783
181784
181785
181786
181787
181788
181789
181790
181791
181792
181793
181794
181795
181796
181797
181798
181799
181800
181801
181802
181803
181804
181805
181806
181807
181808
181809
181810
181811
181812
181813
181814
181815
181816
181817
181818
181819
181820
181821
181822
181823
181824
181825
181826
181827
181828
181829
181830
181831
181832
181833
181834
181835
181836
181837
181838
181839
181840
181841
181842
181843
181844
181845
181846
181847
181848
181849
181850
181851
181852
181853
181854
181855
181856
181857
181858
181859
181860
181861
181862
181863
181864
181865
181866
181867
181868
181869
181870
181871
181872
181873
181874
181875
181876
181877
181878
181879
181880
181881
181882
181883
181884
181885
181886
181887
181888
181889
181890
181891
181892
181893
181894
181895
181896
181897
181898
181899
181900
181901
181902
181903
181904
181905
181906
181907
181908
181909
181910
181911
181912
181913
181914
181915
181916
181917
181918
181919
181920
181921
181922
181923
181924
181925
181926
181927
181928
181929
181930
181931
181932
181933
181934
181935
181936
181937
181938
181939
181940
181941
181942
181943
181944
181945
181946
181947
181948
181949
181950
181951
181952
181953
181954
181955
181956
181957
181958
181959
181960
181961
181962
181963
181964
181965
181966
181967
181968
181969
181970
181971
181972
181973
181974
181975
181976
181977
181978
181979
181980
181981
181982
181983
181984
181985
181986
181987
181988
181989
181990
181991
181992
181993
181994
181995
181996
181997
181998
181999
182000
182001
182002
182003
182004
182005
182006
182007
182008
182009
182010
182011
182012
182013
182014
182015
182016
182017
182018
182019
182020
182021
182022
182023
182024
182025
182026
182027
182028
182029
182030
182031
182032
182033
182034
182035
182036
182037
182038
182039
182040
182041
182042
182043
182044
182045
182046
182047
182048
182049
182050
182051
182052
182053
182054
182055
182056
182057
182058
182059
182060
182061
182062
182063
182064
182065
182066
182067
182068
182069
182070
182071
182072
182073
182074
182075
182076
182077
182078
182079
182080
182081
182082
182083
182084
182085
182086
182087
182088
182089
182090
182091
182092
182093
182094
182095
182096
182097
182098
182099
182100
182101
182102
182103
182104
182105
182106
182107
182108
182109
182110
182111
182112
182113
182114
182115
182116
182117
182118
182119
182120
182121
182122
182123
182124
182125
182126
182127
182128
182129
182130
182131
182132
182133
182134
182135
182136
182137
182138
182139
182140
182141
182142
182143
182144
182145
182146
182147
182148
182149
182150
182151
182152
182153
182154
182155
182156
182157
182158
182159
182160
182161
182162
182163
182164
182165
182166
182167
182168
182169
182170
182171
182172
182173
182174
182175
182176
182177
182178
182179
182180
182181
182182
182183
182184
182185
182186
182187
182188
182189
182190
182191
182192
182193
182194
182195
182196
182197
182198
182199
182200
182201
182202
182203
182204
182205
182206
182207
182208
182209
182210
182211
182212
182213
182214
182215
182216
182217
182218
182219
182220
182221
182222
182223
182224
182225
182226
182227
182228
182229
182230
182231
182232
182233
182234
182235
182236
182237
182238
182239
182240
182241
182242
182243
182244
182245
182246
182247
182248
182249
182250
182251
182252
182253
182254
182255
182256
182257
182258
182259
182260
182261
182262
182263
182264
182265
182266
182267
182268
182269
182270
182271
182272
182273
182274
182275
182276
182277
182278
182279
182280
182281
182282
182283
182284
182285
182286
182287
182288
182289
182290
182291
182292
182293
182294
182295
182296
182297
182298
182299
182300
182301
182302
182303
182304
182305
182306
182307
182308
182309
182310
182311
182312
182313
182314
182315
182316
182317
182318
182319
182320
182321
182322
182323
182324
182325
182326
182327
182328
182329
182330
182331
182332
182333
182334
182335
182336
182337
182338
182339
182340
182341
182342
182343
182344
182345
182346
182347
182348
182349
182350
182351
182352
182353
182354
182355
182356
182357
182358
182359
182360
182361
182362
182363
182364
182365
182366
182367
182368
182369
182370
182371
182372
182373
182374
182375
182376
182377
182378
182379
182380
182381
182382
182383
182384
182385
182386
182387
182388
182389
182390
182391
182392
182393
182394
182395
182396
182397
182398
182399
182400
182401
182402
182403
182404
182405
182406
182407
182408
182409
182410
182411
182412
182413
182414
182415
182416
182417
182418
182419
182420
182421
182422
182423
182424
182425
182426
182427
182428
182429
182430
182431
182432
182433
182434
182435
182436
182437
182438
182439
182440
182441
182442
182443
182444
182445
182446
182447
182448
182449
182450
182451
182452
182453
182454
182455
182456
182457
182458
182459
182460
182461
182462
182463
182464
182465
182466
182467
182468
182469
182470
182471
182472
182473
182474
182475
182476
182477
182478
182479
182480
182481
182482
182483
182484
182485
182486
182487
182488
182489
182490
182491
182492
182493
182494
182495
182496
182497
182498
182499
182500
182501
182502
182503
182504
182505
182506
182507
182508
182509
182510
182511
182512
182513
182514
182515
182516
182517
182518
182519
182520
182521
182522
182523
182524
182525
182526
182527
182528
182529
182530
182531
182532
182533
182534
182535
182536
182537
182538
182539
182540
182541
182542
182543
182544
182545
182546
182547
182548
182549
182550
182551
182552
182553
182554
182555
182556
182557
182558
182559
182560
182561
182562
182563
182564
182565
182566
182567
182568
182569
182570
182571
182572
182573
182574
182575
182576
182577
182578
182579
182580
182581
182582
182583
182584
182585
182586
182587
182588
182589
182590
182591
182592
182593
182594
182595
182596
182597
182598
182599
182600
182601
182602
182603
182604
182605
182606
182607
182608
182609
182610
182611
182612
182613
182614
182615
182616
182617
182618
182619
182620
182621
182622
182623
182624
182625
182626
182627
182628
182629
182630
182631
182632
182633
182634
182635
182636
182637
182638
182639
182640
182641
182642
182643
182644
182645
182646
182647
182648
182649
182650
182651
182652
182653
182654
182655
182656
182657
182658
182659
182660
182661
182662
182663
182664
182665
182666
182667
182668
182669
182670
182671
182672
182673
182674
182675
182676
182677
182678
182679
182680
182681
182682
182683
182684
182685
182686
182687
182688
182689
182690
182691
182692
182693
182694
182695
182696
182697
182698
182699
182700
182701
182702
182703
182704
182705
182706
182707
182708
182709
182710
182711
182712
182713
182714
182715
182716
182717
182718
182719
182720
182721
182722
182723
182724
182725
182726
182727
182728
182729
182730
182731
182732
182733
182734
182735
182736
182737
182738
182739
182740
182741
182742
182743
182744
182745
182746
182747
182748
182749
182750
182751
182752
182753
182754
182755
182756
182757
182758
182759
182760
182761
182762
182763
182764
182765
182766
182767
182768
182769
182770
182771
182772
182773
182774
182775
182776
182777
182778
182779
182780
182781
182782
182783
182784
182785
182786
182787
182788
182789
182790
182791
182792
182793
182794
182795
182796
182797
182798
182799
182800
182801
182802
182803
182804
182805
182806
182807
182808
182809
182810
182811
182812
182813
182814
182815
182816
182817
182818
182819
182820
182821
182822
182823
182824
182825
182826
182827
182828
182829
182830
182831
182832
182833
182834
182835
182836
182837
182838
182839
182840
182841
182842
182843
182844
182845
182846
182847
182848
182849
182850
182851
182852
182853
182854
182855
182856
182857
182858
182859
182860
182861
182862
182863
182864
182865
182866
182867
182868
182869
182870
182871
182872
182873
182874
182875
182876
182877
182878
182879
182880
182881
182882
182883
182884
182885
182886
182887
182888
182889
182890
182891
182892
182893
182894
182895
182896
182897
182898
182899
182900
182901
182902
182903
182904
182905
182906
182907
182908
182909
182910
182911
182912
182913
182914
182915
182916
182917
182918
182919
182920
182921
182922
182923
182924
182925
182926
182927
182928
182929
182930
182931
182932
182933
182934
182935
182936
182937
182938
182939
182940
182941
182942
182943
182944
182945
182946
182947
182948
182949
182950
182951
182952
182953
182954
182955
182956
182957
182958
182959
182960
182961
182962
182963
182964
182965
182966
182967
182968
182969
182970
182971
182972
182973
182974
182975
182976
182977
182978
182979
182980
182981
182982
182983
182984
182985
182986
182987
182988
182989
182990
182991
182992
182993
182994
182995
182996
182997
182998
182999
183000
183001
183002
183003
183004
183005
183006
183007
183008
183009
183010
183011
183012
183013
183014
183015
183016
183017
183018
183019
183020
183021
183022
183023
183024
183025
183026
183027
183028
183029
183030
183031
183032
183033
183034
183035
183036
183037
183038
183039
183040
183041
183042
183043
183044
183045
183046
183047
183048
183049
183050
183051
183052
183053
183054
183055
183056
183057
183058
183059
183060
183061
183062
183063
183064
183065
183066
183067
183068
183069
183070
183071
183072
183073
183074
183075
183076
183077
183078
183079
183080
183081
183082
183083
183084
183085
183086
183087
183088
183089
183090
183091
183092
183093
183094
183095
183096
183097
183098
183099
183100
183101
183102
183103
183104
183105
183106
183107
183108
183109
183110
183111
183112
183113
183114
183115
183116
183117
183118
183119
183120
183121
183122
183123
183124
183125
183126
183127
183128
183129
183130
183131
183132
183133
183134
183135
183136
183137
183138
183139
183140
183141
183142
183143
183144
183145
183146
183147
183148
183149
183150
183151
183152
183153
183154
183155
183156
183157
183158
183159
183160
183161
183162
183163
183164
183165
183166
183167
183168
183169
183170
183171
183172
183173
183174
183175
183176
183177
183178
183179
183180
183181
183182
183183
183184
183185
183186
183187
183188
183189
183190
183191
183192
183193
183194
183195
183196
183197
183198
183199
183200
183201
183202
183203
183204
183205
183206
183207
183208
183209
183210
183211
183212
183213
183214
183215
183216
183217
183218
183219
183220
183221
183222
183223
183224
183225
183226
183227
183228
183229
183230
183231
183232
183233
183234
183235
183236
183237
183238
183239
183240
183241
183242
183243
183244
183245
183246
183247
183248
183249
183250
183251
183252
183253
183254
183255
183256
183257
183258
183259
183260
183261
183262
183263
183264
183265
183266
183267
183268
183269
183270
183271
183272
183273
183274
183275
183276
183277
183278
183279
183280
183281
183282
183283
183284
183285
183286
183287
183288
183289
183290
183291
183292
183293
183294
183295
183296
183297
183298
183299
183300
183301
183302
183303
183304
183305
183306
183307
183308
183309
183310
183311
183312
183313
183314
183315
183316
183317
183318
183319
183320
183321
183322
183323
183324
183325
183326
183327
183328
183329
183330
183331
183332
183333
183334
183335
183336
183337
183338
183339
183340
183341
183342
183343
183344
183345
183346
183347
183348
183349
183350
183351
183352
183353
183354
183355
183356
183357
183358
183359
183360
183361
183362
183363
183364
183365
183366
183367
183368
183369
183370
183371
183372
183373
183374
183375
183376
183377
183378
183379
183380
183381
183382
183383
183384
183385
183386
183387
183388
183389
183390
183391
183392
183393
183394
183395
183396
183397
183398
183399
183400
183401
183402
183403
183404
183405
183406
183407
183408
183409
183410
183411
183412
183413
183414
183415
183416
183417
183418
183419
183420
183421
183422
183423
183424
183425
183426
183427
183428
183429
183430
183431
183432
183433
183434
183435
183436
183437
183438
183439
183440
183441
183442
183443
183444
183445
183446
183447
183448
183449
183450
183451
183452
183453
183454
183455
183456
183457
183458
183459
183460
183461
183462
183463
183464
183465
183466
183467
183468
183469
183470
183471
183472
183473
183474
183475
183476
183477
183478
183479
183480
183481
183482
183483
183484
183485
183486
183487
183488
183489
183490
183491
183492
183493
183494
183495
183496
183497
183498
183499
183500
183501
183502
183503
183504
183505
183506
183507
183508
183509
183510
183511
183512
183513
183514
183515
183516
183517
183518
183519
183520
183521
183522
183523
183524
183525
183526
183527
183528
183529
183530
183531
183532
183533
183534
183535
183536
183537
183538
183539
183540
183541
183542
183543
183544
183545
183546
183547
183548
183549
183550
183551
183552
183553
183554
183555
183556
183557
183558
183559
183560
183561
183562
183563
183564
183565
183566
183567
183568
183569
183570
183571
183572
183573
183574
183575
183576
183577
183578
183579
183580
183581
183582
183583
183584
183585
183586
183587
183588
183589
183590
183591
183592
183593
183594
183595
183596
183597
183598
183599
183600
183601
183602
183603
183604
183605
183606
183607
183608
183609
183610
183611
183612
183613
183614
183615
183616
183617
183618
183619
183620
183621
183622
183623
183624
183625
183626
183627
183628
183629
183630
183631
183632
183633
183634
183635
183636
183637
183638
183639
183640
183641
183642
183643
183644
183645
183646
183647
183648
183649
183650
183651
183652
183653
183654
183655
183656
183657
183658
183659
183660
183661
183662
183663
183664
183665
183666
183667
183668
183669
183670
183671
183672
183673
183674
183675
183676
183677
183678
183679
183680
183681
183682
183683
183684
183685
183686
183687
183688
183689
183690
183691
183692
183693
183694
183695
183696
183697
183698
183699
183700
183701
183702
183703
183704
183705
183706
183707
183708
183709
183710
183711
183712
183713
183714
183715
183716
183717
183718
183719
183720
183721
183722
183723
183724
183725
183726
183727
183728
183729
183730
183731
183732
183733
183734
183735
183736
183737
183738
183739
183740
183741
183742
183743
183744
183745
183746
183747
183748
183749
183750
183751
183752
183753
183754
183755
183756
183757
183758
183759
183760
183761
183762
183763
183764
183765
183766
183767
183768
183769
183770
183771
183772
183773
183774
183775
183776
183777
183778
183779
183780
183781
183782
183783
183784
183785
183786
183787
183788
183789
183790
183791
183792
183793
183794
183795
183796
183797
183798
183799
183800
183801
183802
183803
183804
183805
183806
183807
183808
183809
183810
183811
183812
183813
183814
183815
183816
183817
183818
183819
183820
183821
183822
183823
183824
183825
183826
183827
183828
183829
183830
183831
183832
183833
183834
183835
183836
183837
183838
183839
183840
183841
183842
183843
183844
183845
183846
183847
183848
183849
183850
183851
183852
183853
183854
183855
183856
183857
183858
183859
183860
183861
183862
183863
183864
183865
183866
183867
183868
183869
183870
183871
183872
183873
183874
183875
183876
183877
183878
183879
183880
183881
183882
183883
183884
183885
183886
183887
183888
183889
183890
183891
183892
183893
183894
183895
183896
183897
183898
183899
183900
183901
183902
183903
183904
183905
183906
183907
183908
183909
183910
183911
183912
183913
183914
183915
183916
183917
183918
183919
183920
183921
183922
183923
183924
183925
183926
183927
183928
183929
183930
183931
183932
183933
183934
183935
183936
183937
183938
183939
183940
183941
183942
183943
183944
183945
183946
183947
183948
183949
183950
183951
183952
183953
183954
183955
183956
183957
183958
183959
183960
183961
183962
183963
183964
183965
183966
183967
183968
183969
183970
183971
183972
183973
183974
183975
183976
183977
183978
183979
183980
183981
183982
183983
183984
183985
183986
183987
183988
183989
183990
183991
183992
183993
183994
183995
183996
183997
183998
183999
184000
184001
184002
184003
184004
184005
184006
184007
184008
184009
184010
184011
184012
184013
184014
184015
184016
184017
184018
184019
184020
184021
184022
184023
184024
184025
184026
184027
184028
184029
184030
184031
184032
184033
184034
184035
184036
184037
184038
184039
184040
184041
184042
184043
184044
184045
184046
184047
184048
184049
184050
184051
184052
184053
184054
184055
184056
184057
184058
184059
184060
184061
184062
184063
184064
184065
184066
184067
184068
184069
184070
184071
184072
184073
184074
184075
184076
184077
184078
184079
184080
184081
184082
184083
184084
184085
184086
184087
184088
184089
184090
184091
184092
184093
184094
184095
184096
184097
184098
184099
184100
184101
184102
184103
184104
184105
184106
184107
184108
184109
184110
184111
184112
184113
184114
184115
184116
184117
184118
184119
184120
184121
184122
184123
184124
184125
184126
184127
184128
184129
184130
184131
184132
184133
184134
184135
184136
184137
184138
184139
184140
184141
184142
184143
184144
184145
184146
184147
184148
184149
184150
184151
184152
184153
184154
184155
184156
184157
184158
184159
184160
184161
184162
184163
184164
184165
184166
184167
184168
184169
184170
184171
184172
184173
184174
184175
184176
184177
184178
184179
184180
184181
184182
184183
184184
184185
184186
184187
184188
184189
184190
184191
184192
184193
184194
184195
184196
184197
184198
184199
184200
184201
184202
184203
184204
184205
184206
184207
184208
184209
184210
184211
184212
184213
184214
184215
184216
184217
184218
184219
184220
184221
184222
184223
184224
184225
184226
184227
184228
184229
184230
184231
184232
184233
184234
184235
184236
184237
184238
184239
184240
184241
184242
184243
184244
184245
184246
184247
184248
184249
184250
184251
184252
184253
184254
184255
184256
184257
184258
184259
184260
184261
184262
184263
184264
184265
184266
184267
184268
184269
184270
184271
184272
184273
184274
184275
184276
184277
184278
184279
184280
184281
184282
184283
184284
184285
184286
184287
184288
184289
184290
184291
184292
184293
184294
184295
184296
184297
184298
184299
184300
184301
184302
184303
184304
184305
184306
184307
184308
184309
184310
184311
184312
184313
184314
184315
184316
184317
184318
184319
184320
184321
184322
184323
184324
184325
184326
184327
184328
184329
184330
184331
184332
184333
184334
184335
184336
184337
184338
184339
184340
184341
184342
184343
184344
184345
184346
184347
184348
184349
184350
184351
184352
184353
184354
184355
184356
184357
184358
184359
184360
184361
184362
184363
184364
184365
184366
184367
184368
184369
184370
184371
184372
184373
184374
184375
184376
184377
184378
184379
184380
184381
184382
184383
184384
184385
184386
184387
184388
184389
184390
184391
184392
184393
184394
184395
184396
184397
184398
184399
184400
184401
184402
184403
184404
184405
184406
184407
184408
184409
184410
184411
184412
184413
184414
184415
184416
184417
184418
184419
184420
184421
184422
184423
184424
184425
184426
184427
184428
184429
184430
184431
184432
184433
184434
184435
184436
184437
184438
184439
184440
184441
184442
184443
184444
184445
184446
184447
184448
184449
184450
184451
184452
184453
184454
184455
184456
184457
184458
184459
184460
184461
184462
184463
184464
184465
184466
184467
184468
184469
184470
184471
184472
184473
184474
184475
184476
184477
184478
184479
184480
184481
184482
184483
184484
184485
184486
184487
184488
184489
184490
184491
184492
184493
184494
184495
184496
184497
184498
184499
184500
184501
184502
184503
184504
184505
184506
184507
184508
184509
184510
184511
184512
184513
184514
184515
184516
184517
184518
184519
184520
184521
184522
184523
184524
184525
184526
184527
184528
184529
184530
184531
184532
184533
184534
184535
184536
184537
184538
184539
184540
184541
184542
184543
184544
184545
184546
184547
184548
184549
184550
184551
184552
184553
184554
184555
184556
184557
184558
184559
184560
184561
184562
184563
184564
184565
184566
184567
184568
184569
184570
184571
184572
184573
184574
184575
184576
184577
184578
184579
184580
184581
184582
184583
184584
184585
184586
184587
184588
184589
184590
184591
184592
184593
184594
184595
184596
184597
184598
184599
184600
184601
184602
184603
184604
184605
184606
184607
184608
184609
184610
184611
184612
184613
184614
184615
184616
184617
184618
184619
184620
184621
184622
184623
184624
184625
184626
184627
184628
184629
184630
184631
184632
184633
184634
184635
184636
184637
184638
184639
184640
184641
184642
184643
184644
184645
184646
184647
184648
184649
184650
184651
184652
184653
184654
184655
184656
184657
184658
184659
184660
184661
184662
184663
184664
184665
184666
184667
184668
184669
184670
184671
184672
184673
184674
184675
184676
184677
184678
184679
184680
184681
184682
184683
184684
184685
184686
184687
184688
184689
184690
184691
184692
184693
184694
184695
184696
184697
184698
184699
184700
184701
184702
184703
184704
184705
184706
184707
184708
184709
184710
184711
184712
184713
184714
184715
184716
184717
184718
184719
184720
184721
184722
184723
184724
184725
184726
184727
184728
184729
184730
184731
184732
184733
184734
184735
184736
184737
184738
184739
184740
184741
184742
184743
184744
184745
184746
184747
184748
184749
184750
184751
184752
184753
184754
184755
184756
184757
184758
184759
184760
184761
184762
184763
184764
184765
184766
184767
184768
184769
184770
184771
184772
184773
184774
184775
184776
184777
184778
184779
184780
184781
184782
184783
184784
184785
184786
184787
184788
184789
184790
184791
184792
184793
184794
184795
184796
184797
184798
184799
184800
184801
184802
184803
184804
184805
184806
184807
184808
184809
184810
184811
184812
184813
184814
184815
184816
184817
184818
184819
184820
184821
184822
184823
184824
184825
184826
184827
184828
184829
184830
184831
184832
184833
184834
184835
184836
184837
184838
184839
184840
184841
184842
184843
184844
184845
184846
184847
184848
184849
184850
184851
184852
184853
184854
184855
184856
184857
184858
184859
184860
184861
184862
184863
184864
184865
184866
184867
184868
184869
184870
184871
184872
184873
184874
184875
184876
184877
184878
184879
184880
184881
184882
184883
184884
184885
184886
184887
184888
184889
184890
184891
184892
184893
184894
184895
184896
184897
184898
184899
184900
184901
184902
184903
184904
184905
184906
184907
184908
184909
184910
184911
184912
184913
184914
184915
184916
184917
184918
184919
184920
184921
184922
184923
184924
184925
184926
184927
184928
184929
184930
184931
184932
184933
184934
184935
184936
184937
184938
184939
184940
184941
184942
184943
184944
184945
184946
184947
184948
184949
184950
184951
184952
184953
184954
184955
184956
184957
184958
184959
184960
184961
184962
184963
184964
184965
184966
184967
184968
184969
184970
184971
184972
184973
184974
184975
184976
184977
184978
184979
184980
184981
184982
184983
184984
184985
184986
184987
184988
184989
184990
184991
184992
184993
184994
184995
184996
184997
184998
184999
185000
185001
185002
185003
185004
185005
185006
185007
185008
185009
185010
185011
185012
185013
185014
185015
185016
185017
185018
185019
185020
185021
185022
185023
185024
185025
185026
185027
185028
185029
185030
185031
185032
185033
185034
185035
185036
185037
185038
185039
185040
185041
185042
185043
185044
185045
185046
185047
185048
185049
185050
185051
185052
185053
185054
185055
185056
185057
185058
185059
185060
185061
185062
185063
185064
185065
185066
185067
185068
185069
185070
185071
185072
185073
185074
185075
185076
185077
185078
185079
185080
185081
185082
185083
185084
185085
185086
185087
185088
185089
185090
185091
185092
185093
185094
185095
185096
185097
185098
185099
185100
185101
185102
185103
185104
185105
185106
185107
185108
185109
185110
185111
185112
185113
185114
185115
185116
185117
185118
185119
185120
185121
185122
185123
185124
185125
185126
185127
185128
185129
185130
185131
185132
185133
185134
185135
185136
185137
185138
185139
185140
185141
185142
185143
185144
185145
185146
185147
185148
185149
185150
185151
185152
185153
185154
185155
185156
185157
185158
185159
185160
185161
185162
185163
185164
185165
185166
185167
185168
185169
185170
185171
185172
185173
185174
185175
185176
185177
185178
185179
185180
185181
185182
185183
185184
185185
185186
185187
185188
185189
185190
185191
185192
185193
185194
185195
185196
185197
185198
185199
185200
185201
185202
185203
185204
185205
185206
185207
185208
185209
185210
185211
185212
185213
185214
185215
185216
185217
185218
185219
185220
185221
185222
185223
185224
185225
185226
185227
185228
185229
185230
185231
185232
185233
185234
185235
185236
185237
185238
185239
185240
185241
185242
185243
185244
185245
185246
185247
185248
185249
185250
185251
185252
185253
185254
185255
185256
185257
185258
185259
185260
185261
185262
185263
185264
185265
185266
185267
185268
185269
185270
185271
185272
185273
185274
185275
185276
185277
185278
185279
185280
185281
185282
185283
185284
185285
185286
185287
185288
185289
185290
185291
185292
185293
185294
185295
185296
185297
185298
185299
185300
185301
185302
185303
185304
185305
185306
185307
185308
185309
185310
185311
185312
185313
185314
185315
185316
185317
185318
185319
185320
185321
185322
185323
185324
185325
185326
185327
185328
185329
185330
185331
185332
185333
185334
185335
185336
185337
185338
185339
185340
185341
185342
185343
185344
185345
185346
185347
185348
185349
185350
185351
185352
185353
185354
185355
185356
185357
185358
185359
185360
185361
185362
185363
185364
185365
185366
185367
185368
185369
185370
185371
185372
185373
185374
185375
185376
185377
185378
185379
185380
185381
185382
185383
185384
185385
185386
185387
185388
185389
185390
185391
185392
185393
185394
185395
185396
185397
185398
185399
185400
185401
185402
185403
185404
185405
185406
185407
185408
185409
185410
185411
185412
185413
185414
185415
185416
185417
185418
185419
185420
185421
185422
185423
185424
185425
185426
185427
185428
185429
185430
185431
185432
185433
185434
185435
185436
185437
185438
185439
185440
185441
185442
185443
185444
185445
185446
185447
185448
185449
185450
185451
185452
185453
185454
185455
185456
185457
185458
185459
185460
185461
185462
185463
185464
185465
185466
185467
185468
185469
185470
185471
185472
185473
185474
185475
185476
185477
185478
185479
185480
185481
185482
185483
185484
185485
185486
185487
185488
185489
185490
185491
185492
185493
185494
185495
185496
185497
185498
185499
185500
185501
185502
185503
185504
185505
185506
185507
185508
185509
185510
185511
185512
185513
185514
185515
185516
185517
185518
185519
185520
185521
185522
185523
185524
185525
185526
185527
185528
185529
185530
185531
185532
185533
185534
185535
185536
185537
185538
185539
185540
185541
185542
185543
185544
185545
185546
185547
185548
185549
185550
185551
185552
185553
185554
185555
185556
185557
185558
185559
185560
185561
185562
185563
185564
185565
185566
185567
185568
185569
185570
185571
185572
185573
185574
185575
185576
185577
185578
185579
185580
185581
185582
185583
185584
185585
185586
185587
185588
185589
185590
185591
185592
185593
185594
185595
185596
185597
185598
185599
185600
185601
185602
185603
185604
185605
185606
185607
185608
185609
185610
185611
185612
185613
185614
185615
185616
185617
185618
185619
185620
185621
185622
185623
185624
185625
185626
185627
185628
185629
185630
185631
185632
185633
185634
185635
185636
185637
185638
185639
185640
185641
185642
185643
185644
185645
185646
185647
185648
185649
185650
185651
185652
185653
185654
185655
185656
185657
185658
185659
185660
185661
185662
185663
185664
185665
185666
185667
185668
185669
185670
185671
185672
185673
185674
185675
185676
185677
185678
185679
185680
185681
185682
185683
185684
185685
185686
185687
185688
185689
185690
185691
185692
185693
185694
185695
185696
185697
185698
185699
185700
185701
185702
185703
185704
185705
185706
185707
185708
185709
185710
185711
185712
185713
185714
185715
185716
185717
185718
185719
185720
185721
185722
185723
185724
185725
185726
185727
185728
185729
185730
185731
185732
185733
185734
185735
185736
185737
185738
185739
185740
185741
185742
185743
185744
185745
185746
185747
185748
185749
185750
185751
185752
185753
185754
185755
185756
185757
185758
185759
185760
185761
185762
185763
185764
185765
185766
185767
185768
185769
185770
185771
185772
185773
185774
185775
185776
185777
185778
185779
185780
185781
185782
185783
185784
185785
185786
185787
185788
185789
185790
185791
185792
185793
185794
185795
185796
185797
185798
185799
185800
185801
185802
185803
185804
185805
185806
185807
185808
185809
185810
185811
185812
185813
185814
185815
185816
185817
185818
185819
185820
185821
185822
185823
185824
185825
185826
185827
185828
185829
185830
185831
185832
185833
185834
185835
185836
185837
185838
185839
185840
185841
185842
185843
185844
185845
185846
185847
185848
185849
185850
185851
185852
185853
185854
185855
185856
185857
185858
185859
185860
185861
185862
185863
185864
185865
185866
185867
185868
185869
185870
185871
185872
185873
185874
185875
185876
185877
185878
185879
185880
185881
185882
185883
185884
185885
185886
185887
185888
185889
185890
185891
185892
185893
185894
185895
185896
185897
185898
185899
185900
185901
185902
185903
185904
185905
185906
185907
185908
185909
185910
185911
185912
185913
185914
185915
185916
185917
185918
185919
185920
185921
185922
185923
185924
185925
185926
185927
185928
185929
185930
185931
185932
185933
185934
185935
185936
185937
185938
185939
185940
185941
185942
185943
185944
185945
185946
185947
185948
185949
185950
185951
185952
185953
185954
185955
185956
185957
185958
185959
185960
185961
185962
185963
185964
185965
185966
185967
185968
185969
185970
185971
185972
185973
185974
185975
185976
185977
185978
185979
185980
185981
185982
185983
185984
185985
185986
185987
185988
185989
185990
185991
185992
185993
185994
185995
185996
185997
185998
185999
186000
186001
186002
186003
186004
186005
186006
186007
186008
186009
186010
186011
186012
186013
186014
186015
186016
186017
186018
186019
186020
186021
186022
186023
186024
186025
186026
186027
186028
186029
186030
186031
186032
186033
186034
186035
186036
186037
186038
186039
186040
186041
186042
186043
186044
186045
186046
186047
186048
186049
186050
186051
186052
186053
186054
186055
186056
186057
186058
186059
186060
186061
186062
186063
186064
186065
186066
186067
186068
186069
186070
186071
186072
186073
186074
186075
186076
186077
186078
186079
186080
186081
186082
186083
186084
186085
186086
186087
186088
186089
186090
186091
186092
186093
186094
186095
186096
186097
186098
186099
186100
186101
186102
186103
186104
186105
186106
186107
186108
186109
186110
186111
186112
186113
186114
186115
186116
186117
186118
186119
186120
186121
186122
186123
186124
186125
186126
186127
186128
186129
186130
186131
186132
186133
186134
186135
186136
186137
186138
186139
186140
186141
186142
186143
186144
186145
186146
186147
186148
186149
186150
186151
186152
186153
186154
186155
186156
186157
186158
186159
186160
186161
186162
186163
186164
186165
186166
186167
186168
186169
186170
186171
186172
186173
186174
186175
186176
186177
186178
186179
186180
186181
186182
186183
186184
186185
186186
186187
186188
186189
186190
186191
186192
186193
186194
186195
186196
186197
186198
186199
186200
186201
186202
186203
186204
186205
186206
186207
186208
186209
186210
186211
186212
186213
186214
186215
186216
186217
186218
186219
186220
186221
186222
186223
186224
186225
186226
186227
186228
186229
186230
186231
186232
186233
186234
186235
186236
186237
186238
186239
186240
186241
186242
186243
186244
186245
186246
186247
186248
186249
186250
186251
186252
186253
186254
186255
186256
186257
186258
186259
186260
186261
186262
186263
186264
186265
186266
186267
186268
186269
186270
186271
186272
186273
186274
186275
186276
186277
186278
186279
186280
186281
186282
186283
186284
186285
186286
186287
186288
186289
186290
186291
186292
186293
186294
186295
186296
186297
186298
186299
186300
186301
186302
186303
186304
186305
186306
186307
186308
186309
186310
186311
186312
186313
186314
186315
186316
186317
186318
186319
186320
186321
186322
186323
186324
186325
186326
186327
186328
186329
186330
186331
186332
186333
186334
186335
186336
186337
186338
186339
186340
186341
186342
186343
186344
186345
186346
186347
186348
186349
186350
186351
186352
186353
186354
186355
186356
186357
186358
186359
186360
186361
186362
186363
186364
186365
186366
186367
186368
186369
186370
186371
186372
186373
186374
186375
186376
186377
186378
186379
186380
186381
186382
186383
186384
186385
186386
186387
186388
186389
186390
186391
186392
186393
186394
186395
186396
186397
186398
186399
186400
186401
186402
186403
186404
186405
186406
186407
186408
186409
186410
186411
186412
186413
186414
186415
186416
186417
186418
186419
186420
186421
186422
186423
186424
186425
186426
186427
186428
186429
186430
186431
186432
186433
186434
186435
186436
186437
186438
186439
186440
186441
186442
186443
186444
186445
186446
186447
186448
186449
186450
186451
186452
186453
186454
186455
186456
186457
186458
186459
186460
186461
186462
186463
186464
186465
186466
186467
186468
186469
186470
186471
186472
186473
186474
186475
186476
186477
186478
186479
186480
186481
186482
186483
186484
186485
186486
186487
186488
186489
186490
186491
186492
186493
186494
186495
186496
186497
186498
186499
186500
186501
186502
186503
186504
186505
186506
186507
186508
186509
186510
186511
186512
186513
186514
186515
186516
186517
186518
186519
186520
186521
186522
186523
186524
186525
186526
186527
186528
186529
186530
186531
186532
186533
186534
186535
186536
186537
186538
186539
186540
186541
186542
186543
186544
186545
186546
186547
186548
186549
186550
186551
186552
186553
186554
186555
186556
186557
186558
186559
186560
186561
186562
186563
186564
186565
186566
186567
186568
186569
186570
186571
186572
186573
186574
186575
186576
186577
186578
186579
186580
186581
186582
186583
186584
186585
186586
186587
186588
186589
186590
186591
186592
186593
186594
186595
186596
186597
186598
186599
186600
186601
186602
186603
186604
186605
186606
186607
186608
186609
186610
186611
186612
186613
186614
186615
186616
186617
186618
186619
186620
186621
186622
186623
186624
186625
186626
186627
186628
186629
186630
186631
186632
186633
186634
186635
186636
186637
186638
186639
186640
186641
186642
186643
186644
186645
186646
186647
186648
186649
186650
186651
186652
186653
186654
186655
186656
186657
186658
186659
186660
186661
186662
186663
186664
186665
186666
186667
186668
186669
186670
186671
186672
186673
186674
186675
186676
186677
186678
186679
186680
186681
186682
186683
186684
186685
186686
186687
186688
186689
186690
186691
186692
186693
186694
186695
186696
186697
186698
186699
186700
186701
186702
186703
186704
186705
186706
186707
186708
186709
186710
186711
186712
186713
186714
186715
186716
186717
186718
186719
186720
186721
186722
186723
186724
186725
186726
186727
186728
186729
186730
186731
186732
186733
186734
186735
186736
186737
186738
186739
186740
186741
186742
186743
186744
186745
186746
186747
186748
186749
186750
186751
186752
186753
186754
186755
186756
186757
186758
186759
186760
186761
186762
186763
186764
186765
186766
186767
186768
186769
186770
186771
186772
186773
186774
186775
186776
186777
186778
186779
186780
186781
186782
186783
186784
186785
186786
186787
186788
186789
186790
186791
186792
186793
186794
186795
186796
186797
186798
186799
186800
186801
186802
186803
186804
186805
186806
186807
186808
186809
186810
186811
186812
186813
186814
186815
186816
186817
186818
186819
186820
186821
186822
186823
186824
186825
186826
186827
186828
186829
186830
186831
186832
186833
186834
186835
186836
186837
186838
186839
186840
186841
186842
186843
186844
186845
186846
186847
186848
186849
186850
186851
186852
186853
186854
186855
186856
186857
186858
186859
186860
186861
186862
186863
186864
186865
186866
186867
186868
186869
186870
186871
186872
186873
186874
186875
186876
186877
186878
186879
186880
186881
186882
186883
186884
186885
186886
186887
186888
186889
186890
186891
186892
186893
186894
186895
186896
186897
186898
186899
186900
186901
186902
186903
186904
186905
186906
186907
186908
186909
186910
186911
186912
186913
186914
186915
186916
186917
186918
186919
186920
186921
186922
186923
186924
186925
186926
186927
186928
186929
186930
186931
186932
186933
186934
186935
186936
186937
186938
186939
186940
186941
186942
186943
186944
186945
186946
186947
186948
186949
186950
186951
186952
186953
186954
186955
186956
186957
186958
186959
186960
186961
186962
186963
186964
186965
186966
186967
186968
186969
186970
186971
186972
186973
186974
186975
186976
186977
186978
186979
186980
186981
186982
186983
186984
186985
186986
186987
186988
186989
186990
186991
186992
186993
186994
186995
186996
186997
186998
186999
187000
187001
187002
187003
187004
187005
187006
187007
187008
187009
187010
187011
187012
187013
187014
187015
187016
187017
187018
187019
187020
187021
187022
187023
187024
187025
187026
187027
187028
187029
187030
187031
187032
187033
187034
187035
187036
187037
187038
187039
187040
187041
187042
187043
187044
187045
187046
187047
187048
187049
187050
187051
187052
187053
187054
187055
187056
187057
187058
187059
187060
187061
187062
187063
187064
187065
187066
187067
187068
187069
187070
187071
187072
187073
187074
187075
187076
187077
187078
187079
187080
187081
187082
187083
187084
187085
187086
187087
187088
187089
187090
187091
187092
187093
187094
187095
187096
187097
187098
187099
187100
187101
187102
187103
187104
187105
187106
187107
187108
187109
187110
187111
187112
187113
187114
187115
187116
187117
187118
187119
187120
187121
187122
187123
187124
187125
187126
187127
187128
187129
187130
187131
187132
187133
187134
187135
187136
187137
187138
187139
187140
187141
187142
187143
187144
187145
187146
187147
187148
187149
187150
187151
187152
187153
187154
187155
187156
187157
187158
187159
187160
187161
187162
187163
187164
187165
187166
187167
187168
187169
187170
187171
187172
187173
187174
187175
187176
187177
187178
187179
187180
187181
187182
187183
187184
187185
187186
187187
187188
187189
187190
187191
187192
187193
187194
187195
187196
187197
187198
187199
187200
187201
187202
187203
187204
187205
187206
187207
187208
187209
187210
187211
187212
187213
187214
187215
187216
187217
187218
187219
187220
187221
187222
187223
187224
187225
187226
187227
187228
187229
187230
187231
187232
187233
187234
187235
187236
187237
187238
187239
187240
187241
187242
187243
187244
187245
187246
187247
187248
187249
187250
187251
187252
187253
187254
187255
187256
187257
187258
187259
187260
187261
187262
187263
187264
187265
187266
187267
187268
187269
187270
187271
187272
187273
187274
187275
187276
187277
187278
187279
187280
187281
187282
187283
187284
187285
187286
187287
187288
187289
187290
187291
187292
187293
187294
187295
187296
187297
187298
187299
187300
187301
187302
187303
187304
187305
187306
187307
187308
187309
187310
187311
187312
187313
187314
187315
187316
187317
187318
187319
187320
187321
187322
187323
187324
187325
187326
187327
187328
187329
187330
187331
187332
187333
187334
187335
187336
187337
187338
187339
187340
187341
187342
187343
187344
187345
187346
187347
187348
187349
187350
187351
187352
187353
187354
187355
187356
187357
187358
187359
187360
187361
187362
187363
187364
187365
187366
187367
187368
187369
187370
187371
187372
187373
187374
187375
187376
187377
187378
187379
187380
187381
187382
187383
187384
187385
187386
187387
187388
187389
187390
187391
187392
187393
187394
187395
187396
187397
187398
187399
187400
187401
187402
187403
187404
187405
187406
187407
187408
187409
187410
187411
187412
187413
187414
187415
187416
187417
187418
187419
187420
187421
187422
187423
187424
187425
187426
187427
187428
187429
187430
187431
187432
187433
187434
187435
187436
187437
187438
187439
187440
187441
187442
187443
187444
187445
187446
187447
187448
187449
187450
187451
187452
187453
187454
187455
187456
187457
187458
187459
187460
187461
187462
187463
187464
187465
187466
187467
187468
187469
187470
187471
187472
187473
187474
187475
187476
187477
187478
187479
187480
187481
187482
187483
187484
187485
187486
187487
187488
187489
187490
187491
187492
187493
187494
187495
187496
187497
187498
187499
187500
187501
187502
187503
187504
187505
187506
187507
187508
187509
187510
187511
187512
187513
187514
187515
187516
187517
187518
187519
187520
187521
187522
187523
187524
187525
187526
187527
187528
187529
187530
187531
187532
187533
187534
187535
187536
187537
187538
187539
187540
187541
187542
187543
187544
187545
187546
187547
187548
187549
187550
187551
187552
187553
187554
187555
187556
187557
187558
187559
187560
187561
187562
187563
187564
187565
187566
187567
187568
187569
187570
187571
187572
187573
187574
187575
187576
187577
187578
187579
187580
187581
187582
187583
187584
187585
187586
187587
187588
187589
187590
187591
187592
187593
187594
187595
187596
187597
187598
187599
187600
187601
187602
187603
187604
187605
187606
187607
187608
187609
187610
187611
187612
187613
187614
187615
187616
187617
187618
187619
187620
187621
187622
187623
187624
187625
187626
187627
187628
187629
187630
187631
187632
187633
187634
187635
187636
187637
187638
187639
187640
187641
187642
187643
187644
187645
187646
187647
187648
187649
187650
187651
187652
187653
187654
187655
187656
187657
187658
187659
187660
187661
187662
187663
187664
187665
187666
187667
187668
187669
187670
187671
187672
187673
187674
187675
187676
187677
187678
187679
187680
187681
187682
187683
187684
187685
187686
187687
187688
187689
187690
187691
187692
187693
187694
187695
187696
187697
187698
187699
187700
187701
187702
187703
187704
187705
187706
187707
187708
187709
187710
187711
187712
187713
187714
187715
187716
187717
187718
187719
187720
187721
187722
187723
187724
187725
187726
187727
187728
187729
187730
187731
187732
187733
187734
187735
187736
187737
187738
187739
187740
187741
187742
187743
187744
187745
187746
187747
187748
187749
187750
187751
187752
187753
187754
187755
187756
187757
187758
187759
187760
187761
187762
187763
187764
187765
187766
187767
187768
187769
187770
187771
187772
187773
187774
187775
187776
187777
187778
187779
187780
187781
187782
187783
187784
187785
187786
187787
187788
187789
187790
187791
187792
187793
187794
187795
187796
187797
187798
187799
187800
187801
187802
187803
187804
187805
187806
187807
187808
187809
187810
187811
187812
187813
187814
187815
187816
187817
187818
187819
187820
187821
187822
187823
187824
187825
187826
187827
187828
187829
187830
187831
187832
187833
187834
187835
187836
187837
187838
187839
187840
187841
187842
187843
187844
187845
187846
187847
187848
187849
187850
187851
187852
187853
187854
187855
187856
187857
187858
187859
187860
187861
187862
187863
187864
187865
187866
187867
187868
187869
187870
187871
187872
187873
187874
187875
187876
187877
187878
187879
187880
187881
187882
187883
187884
187885
187886
187887
187888
187889
187890
187891
187892
187893
187894
187895
187896
187897
187898
187899
187900
187901
187902
187903
187904
187905
187906
187907
187908
187909
187910
187911
187912
187913
187914
187915
187916
187917
187918
187919
187920
187921
187922
187923
187924
187925
187926
187927
187928
187929
187930
187931
187932
187933
187934
187935
187936
187937
187938
187939
187940
187941
187942
187943
187944
187945
187946
187947
187948
187949
187950
187951
187952
187953
187954
187955
187956
187957
187958
187959
187960
187961
187962
187963
187964
187965
187966
187967
187968
187969
187970
187971
187972
187973
187974
187975
187976
187977
187978
187979
187980
187981
187982
187983
187984
187985
187986
187987
187988
187989
187990
187991
187992
187993
187994
187995
187996
187997
187998
187999
188000
188001
188002
188003
188004
188005
188006
188007
188008
188009
188010
188011
188012
188013
188014
188015
188016
188017
188018
188019
188020
188021
188022
188023
188024
188025
188026
188027
188028
188029
188030
188031
188032
188033
188034
188035
188036
188037
188038
188039
188040
188041
188042
188043
188044
188045
188046
188047
188048
188049
188050
188051
188052
188053
188054
188055
188056
188057
188058
188059
188060
188061
188062
188063
188064
188065
188066
188067
188068
188069
188070
188071
188072
188073
188074
188075
188076
188077
188078
188079
188080
188081
188082
188083
188084
188085
188086
188087
188088
188089
188090
188091
188092
188093
188094
188095
188096
188097
188098
188099
188100
188101
188102
188103
188104
188105
188106
188107
188108
188109
188110
188111
188112
188113
188114
188115
188116
188117
188118
188119
188120
188121
188122
188123
188124
188125
188126
188127
188128
188129
188130
188131
188132
188133
188134
188135
188136
188137
188138
188139
188140
188141
188142
188143
188144
188145
188146
188147
188148
188149
188150
188151
188152
188153
188154
188155
188156
188157
188158
188159
188160
188161
188162
188163
188164
188165
188166
188167
188168
188169
188170
188171
188172
188173
188174
188175
188176
188177
188178
188179
188180
188181
188182
188183
188184
188185
188186
188187
188188
188189
188190
188191
188192
188193
188194
188195
188196
188197
188198
188199
188200
188201
188202
188203
188204
188205
188206
188207
188208
188209
188210
188211
188212
188213
188214
188215
188216
188217
188218
188219
188220
188221
188222
188223
188224
188225
188226
188227
188228
188229
188230
188231
188232
188233
188234
188235
188236
188237
188238
188239
188240
188241
188242
188243
188244
188245
188246
188247
188248
188249
188250
188251
188252
188253
188254
188255
188256
188257
188258
188259
188260
188261
188262
188263
188264
188265
188266
188267
188268
188269
188270
188271
188272
188273
188274
188275
188276
188277
188278
188279
188280
188281
188282
188283
188284
188285
188286
188287
188288
188289
188290
188291
188292
188293
188294
188295
188296
188297
188298
188299
188300
188301
188302
188303
188304
188305
188306
188307
188308
188309
188310
188311
188312
188313
188314
188315
188316
188317
188318
188319
188320
188321
188322
188323
188324
188325
188326
188327
188328
188329
188330
188331
188332
188333
188334
188335
188336
188337
188338
188339
188340
188341
188342
188343
188344
188345
188346
188347
188348
188349
188350
188351
188352
188353
188354
188355
188356
188357
188358
188359
188360
188361
188362
188363
188364
188365
188366
188367
188368
188369
188370
188371
188372
188373
188374
188375
188376
188377
188378
188379
188380
188381
188382
188383
188384
188385
188386
188387
188388
188389
188390
188391
188392
188393
188394
188395
188396
188397
188398
188399
188400
188401
188402
188403
188404
188405
188406
188407
188408
188409
188410
188411
188412
188413
188414
188415
188416
188417
188418
188419
188420
188421
188422
188423
188424
188425
188426
188427
188428
188429
188430
188431
188432
188433
188434
188435
188436
188437
188438
188439
188440
188441
188442
188443
188444
188445
188446
188447
188448
188449
188450
188451
188452
188453
188454
188455
188456
188457
188458
188459
188460
188461
188462
188463
188464
188465
188466
188467
188468
188469
188470
188471
188472
188473
188474
188475
188476
188477
188478
188479
188480
188481
188482
188483
188484
188485
188486
188487
188488
188489
188490
188491
188492
188493
188494
188495
188496
188497
188498
188499
188500
188501
188502
188503
188504
188505
188506
188507
188508
188509
188510
188511
188512
188513
188514
188515
188516
188517
188518
188519
188520
188521
188522
188523
188524
188525
188526
188527
188528
188529
188530
188531
188532
188533
188534
188535
188536
188537
188538
188539
188540
188541
188542
188543
188544
188545
188546
188547
188548
188549
188550
188551
188552
188553
188554
188555
188556
188557
188558
188559
188560
188561
188562
188563
188564
188565
188566
188567
188568
188569
188570
188571
188572
188573
188574
188575
188576
188577
188578
188579
188580
188581
188582
188583
188584
188585
188586
188587
188588
188589
188590
188591
188592
188593
188594
188595
188596
188597
188598
188599
188600
188601
188602
188603
188604
188605
188606
188607
188608
188609
188610
188611
188612
188613
188614
188615
188616
188617
188618
188619
188620
188621
188622
188623
188624
188625
188626
188627
188628
188629
188630
188631
188632
188633
188634
188635
188636
188637
188638
188639
188640
188641
188642
188643
188644
188645
188646
188647
188648
188649
188650
188651
188652
188653
188654
188655
188656
188657
188658
188659
188660
188661
188662
188663
188664
188665
188666
188667
188668
188669
188670
188671
188672
188673
188674
188675
188676
188677
188678
188679
188680
188681
188682
188683
188684
188685
188686
188687
188688
188689
188690
188691
188692
188693
188694
188695
188696
188697
188698
188699
188700
188701
188702
188703
188704
188705
188706
188707
188708
188709
188710
188711
188712
188713
188714
188715
188716
188717
188718
188719
188720
188721
188722
188723
188724
188725
188726
188727
188728
188729
188730
188731
188732
188733
188734
188735
188736
188737
188738
188739
188740
188741
188742
188743
188744
188745
188746
188747
188748
188749
188750
188751
188752
188753
188754
188755
188756
188757
188758
188759
188760
188761
188762
188763
188764
188765
188766
188767
188768
188769
188770
188771
188772
188773
188774
188775
188776
188777
188778
188779
188780
188781
188782
188783
188784
188785
188786
188787
188788
188789
188790
188791
188792
188793
188794
188795
188796
188797
188798
188799
188800
188801
188802
188803
188804
188805
188806
188807
188808
188809
188810
188811
188812
188813
188814
188815
188816
188817
188818
188819
188820
188821
188822
188823
188824
188825
188826
188827
188828
188829
188830
188831
188832
188833
188834
188835
188836
188837
188838
188839
188840
188841
188842
188843
188844
188845
188846
188847
188848
188849
188850
188851
188852
188853
188854
188855
188856
188857
188858
188859
188860
188861
188862
188863
188864
188865
188866
188867
188868
188869
188870
188871
188872
188873
188874
188875
188876
188877
188878
188879
188880
188881
188882
188883
188884
188885
188886
188887
188888
188889
188890
188891
188892
188893
188894
188895
188896
188897
188898
188899
188900
188901
188902
188903
188904
188905
188906
188907
188908
188909
188910
188911
188912
188913
188914
188915
188916
188917
188918
188919
188920
188921
188922
188923
188924
188925
188926
188927
188928
188929
188930
188931
188932
188933
188934
188935
188936
188937
188938
188939
188940
188941
188942
188943
188944
188945
188946
188947
188948
188949
188950
188951
188952
188953
188954
188955
188956
188957
188958
188959
188960
188961
188962
188963
188964
188965
188966
188967
188968
188969
188970
188971
188972
188973
188974
188975
188976
188977
188978
188979
188980
188981
188982
188983
188984
188985
188986
188987
188988
188989
188990
188991
188992
188993
188994
188995
188996
188997
188998
188999
189000
189001
189002
189003
189004
189005
189006
189007
189008
189009
189010
189011
189012
189013
189014
189015
189016
189017
189018
189019
189020
189021
189022
189023
189024
189025
189026
189027
189028
189029
189030
189031
189032
189033
189034
189035
189036
189037
189038
189039
189040
189041
189042
189043
189044
189045
189046
189047
189048
189049
189050
189051
189052
189053
189054
189055
189056
189057
189058
189059
189060
189061
189062
189063
189064
189065
189066
189067
189068
189069
189070
189071
189072
189073
189074
189075
189076
189077
189078
189079
189080
189081
189082
189083
189084
189085
189086
189087
189088
189089
189090
189091
189092
189093
189094
189095
189096
189097
189098
189099
189100
189101
189102
189103
189104
189105
189106
189107
189108
189109
189110
189111
189112
189113
189114
189115
189116
189117
189118
189119
189120
189121
189122
189123
189124
189125
189126
189127
189128
189129
189130
189131
189132
189133
189134
189135
189136
189137
189138
189139
189140
189141
189142
189143
189144
189145
189146
189147
189148
189149
189150
189151
189152
189153
189154
189155
189156
189157
189158
189159
189160
189161
189162
189163
189164
189165
189166
189167
189168
189169
189170
189171
189172
189173
189174
189175
189176
189177
189178
189179
189180
189181
189182
189183
189184
189185
189186
189187
189188
189189
189190
189191
189192
189193
189194
189195
189196
189197
189198
189199
189200
189201
189202
189203
189204
189205
189206
189207
189208
189209
189210
189211
189212
189213
189214
189215
189216
189217
189218
189219
189220
189221
189222
189223
189224
189225
189226
189227
189228
189229
189230
189231
189232
189233
189234
189235
189236
189237
189238
189239
189240
189241
189242
189243
189244
189245
189246
189247
189248
189249
189250
189251
189252
189253
189254
189255
189256
189257
189258
189259
189260
189261
189262
189263
189264
189265
189266
189267
189268
189269
189270
189271
189272
189273
189274
189275
189276
189277
189278
189279
189280
189281
189282
189283
189284
189285
189286
189287
189288
189289
189290
189291
189292
189293
189294
189295
189296
189297
189298
189299
189300
189301
189302
189303
189304
189305
189306
189307
189308
189309
189310
189311
189312
189313
189314
189315
189316
189317
189318
189319
189320
189321
189322
189323
189324
189325
189326
189327
189328
189329
189330
189331
189332
189333
189334
189335
189336
189337
189338
189339
189340
189341
189342
189343
189344
189345
189346
189347
189348
189349
189350
189351
189352
189353
189354
189355
189356
189357
189358
189359
189360
189361
189362
189363
189364
189365
189366
189367
189368
189369
189370
189371
189372
189373
189374
189375
189376
189377
189378
189379
189380
189381
189382
189383
189384
189385
189386
189387
189388
189389
189390
189391
189392
189393
189394
189395
189396
189397
189398
189399
189400
189401
189402
189403
189404
189405
189406
189407
189408
189409
189410
189411
189412
189413
189414
189415
189416
189417
189418
189419
189420
189421
189422
189423
189424
189425
189426
189427
189428
189429
189430
189431
189432
189433
189434
189435
189436
189437
189438
189439
189440
189441
189442
189443
189444
189445
189446
189447
189448
189449
189450
189451
189452
189453
189454
189455
189456
189457
189458
189459
189460
189461
189462
189463
189464
189465
189466
189467
189468
189469
189470
189471
189472
189473
189474
189475
189476
189477
189478
189479
189480
189481
189482
189483
189484
189485
189486
189487
189488
189489
189490
189491
189492
189493
189494
189495
189496
189497
189498
189499
189500
189501
189502
189503
189504
189505
189506
189507
189508
189509
189510
189511
189512
189513
189514
189515
189516
189517
189518
189519
189520
189521
189522
189523
189524
189525
189526
189527
189528
189529
189530
189531
189532
189533
189534
189535
189536
189537
189538
189539
189540
189541
189542
189543
189544
189545
189546
189547
189548
189549
189550
189551
189552
189553
189554
189555
189556
189557
189558
189559
189560
189561
189562
189563
189564
189565
189566
189567
189568
189569
189570
189571
189572
189573
189574
189575
189576
189577
189578
189579
189580
189581
189582
189583
189584
189585
189586
189587
189588
189589
189590
189591
189592
189593
189594
189595
189596
189597
189598
189599
189600
189601
189602
189603
189604
189605
189606
189607
189608
189609
189610
189611
189612
189613
189614
189615
189616
189617
189618
189619
189620
189621
189622
189623
189624
189625
189626
189627
189628
189629
189630
189631
189632
189633
189634
189635
189636
189637
189638
189639
189640
189641
189642
189643
189644
189645
189646
189647
189648
189649
189650
189651
189652
189653
189654
189655
189656
189657
189658
189659
189660
189661
189662
189663
189664
189665
189666
189667
189668
189669
189670
189671
189672
189673
189674
189675
189676
189677
189678
189679
189680
189681
189682
189683
189684
189685
189686
189687
189688
189689
189690
189691
189692
189693
189694
189695
189696
189697
189698
189699
189700
189701
189702
189703
189704
189705
189706
189707
189708
189709
189710
189711
189712
189713
189714
189715
189716
189717
189718
189719
189720
189721
189722
189723
189724
189725
189726
189727
189728
189729
189730
189731
189732
189733
189734
189735
189736
189737
189738
189739
189740
189741
189742
189743
189744
189745
189746
189747
189748
189749
189750
189751
189752
189753
189754
189755
189756
189757
189758
189759
189760
189761
189762
189763
189764
189765
189766
189767
189768
189769
189770
189771
189772
189773
189774
189775
189776
189777
189778
189779
189780
189781
189782
189783
189784
189785
189786
189787
189788
189789
189790
189791
189792
189793
189794
189795
189796
189797
189798
189799
189800
189801
189802
189803
189804
189805
189806
189807
189808
189809
189810
189811
189812
189813
189814
189815
189816
189817
189818
189819
189820
189821
189822
189823
189824
189825
189826
189827
189828
189829
189830
189831
189832
189833
189834
189835
189836
189837
189838
189839
189840
189841
189842
189843
189844
189845
189846
189847
189848
189849
189850
189851
189852
189853
189854
189855
189856
189857
189858
189859
189860
189861
189862
189863
189864
189865
189866
189867
189868
189869
189870
189871
189872
189873
189874
189875
189876
189877
189878
189879
189880
189881
189882
189883
189884
189885
189886
189887
189888
189889
189890
189891
189892
189893
189894
189895
189896
189897
189898
189899
189900
189901
189902
189903
189904
189905
189906
189907
189908
189909
189910
189911
189912
189913
189914
189915
189916
189917
189918
189919
189920
189921
189922
189923
189924
189925
189926
189927
189928
189929
189930
189931
189932
189933
189934
189935
189936
189937
189938
189939
189940
189941
189942
189943
189944
189945
189946
189947
189948
189949
189950
189951
189952
189953
189954
189955
189956
189957
189958
189959
189960
189961
189962
189963
189964
189965
189966
189967
189968
189969
189970
189971
189972
189973
189974
189975
189976
189977
189978
189979
189980
189981
189982
189983
189984
189985
189986
189987
189988
189989
189990
189991
189992
189993
189994
189995
189996
189997
189998
189999
190000
190001
190002
190003
190004
190005
190006
190007
190008
190009
190010
190011
190012
190013
190014
190015
190016
190017
190018
190019
190020
190021
190022
190023
190024
190025
190026
190027
190028
190029
190030
190031
190032
190033
190034
190035
190036
190037
190038
190039
190040
190041
190042
190043
190044
190045
190046
190047
190048
190049
190050
190051
190052
190053
190054
190055
190056
190057
190058
190059
190060
190061
190062
190063
190064
190065
190066
190067
190068
190069
190070
190071
190072
190073
190074
190075
190076
190077
190078
190079
190080
190081
190082
190083
190084
190085
190086
190087
190088
190089
190090
190091
190092
190093
190094
190095
190096
190097
190098
190099
190100
190101
190102
190103
190104
190105
190106
190107
190108
190109
190110
190111
190112
190113
190114
190115
190116
190117
190118
190119
190120
190121
190122
190123
190124
190125
190126
190127
190128
190129
190130
190131
190132
190133
190134
190135
190136
190137
190138
190139
190140
190141
190142
190143
190144
190145
190146
190147
190148
190149
190150
190151
190152
190153
190154
190155
190156
190157
190158
190159
190160
190161
190162
190163
190164
190165
190166
190167
190168
190169
190170
190171
190172
190173
190174
190175
190176
190177
190178
190179
190180
190181
190182
190183
190184
190185
190186
190187
190188
190189
190190
190191
190192
190193
190194
190195
190196
190197
190198
190199
190200
190201
190202
190203
190204
190205
190206
190207
190208
190209
190210
190211
190212
190213
190214
190215
190216
190217
190218
190219
190220
190221
190222
190223
190224
190225
190226
190227
190228
190229
190230
190231
190232
190233
190234
190235
190236
190237
190238
190239
190240
190241
190242
190243
190244
190245
190246
190247
190248
190249
190250
190251
190252
190253
190254
190255
190256
190257
190258
190259
190260
190261
190262
190263
190264
190265
190266
190267
190268
190269
190270
190271
190272
190273
190274
190275
190276
190277
190278
190279
190280
190281
190282
190283
190284
190285
190286
190287
190288
190289
190290
190291
190292
190293
190294
190295
190296
190297
190298
190299
190300
190301
190302
190303
190304
190305
190306
190307
190308
190309
190310
190311
190312
190313
190314
190315
190316
190317
190318
190319
190320
190321
190322
190323
190324
190325
190326
190327
190328
190329
190330
190331
190332
190333
190334
190335
190336
190337
190338
190339
190340
190341
190342
190343
190344
190345
190346
190347
190348
190349
190350
190351
190352
190353
190354
190355
190356
190357
190358
190359
190360
190361
190362
190363
190364
190365
190366
190367
190368
190369
190370
190371
190372
190373
190374
190375
190376
190377
190378
190379
190380
190381
190382
190383
190384
190385
190386
190387
190388
190389
190390
190391
190392
190393
190394
190395
190396
190397
190398
190399
190400
190401
190402
190403
190404
190405
190406
190407
190408
190409
190410
190411
190412
190413
190414
190415
190416
190417
190418
190419
190420
190421
190422
190423
190424
190425
190426
190427
190428
190429
190430
190431
190432
190433
190434
190435
190436
190437
190438
190439
190440
190441
190442
190443
190444
190445
190446
190447
190448
190449
190450
190451
190452
190453
190454
190455
190456
190457
190458
190459
190460
190461
190462
190463
190464
190465
190466
190467
190468
190469
190470
190471
190472
190473
190474
190475
190476
190477
190478
190479
190480
190481
190482
190483
190484
190485
190486
190487
190488
190489
190490
190491
190492
190493
190494
190495
190496
190497
190498
190499
190500
190501
190502
190503
190504
190505
190506
190507
190508
190509
190510
190511
190512
190513
190514
190515
190516
190517
190518
190519
190520
190521
190522
190523
190524
190525
190526
190527
190528
190529
190530
190531
190532
190533
190534
190535
190536
190537
190538
190539
190540
190541
190542
190543
190544
190545
190546
190547
190548
190549
190550
190551
190552
190553
190554
190555
190556
190557
190558
190559
190560
190561
190562
190563
190564
190565
190566
190567
190568
190569
190570
190571
190572
190573
190574
190575
190576
190577
190578
190579
190580
190581
190582
190583
190584
190585
190586
190587
190588
190589
190590
190591
190592
190593
190594
190595
190596
190597
190598
190599
190600
190601
190602
190603
190604
190605
190606
190607
190608
190609
190610
190611
190612
190613
190614
190615
190616
190617
190618
190619
190620
190621
190622
190623
190624
190625
190626
190627
190628
190629
190630
190631
190632
190633
190634
190635
190636
190637
190638
190639
190640
190641
190642
190643
190644
190645
190646
190647
190648
190649
190650
190651
190652
190653
190654
190655
190656
190657
190658
190659
190660
190661
190662
190663
190664
190665
190666
190667
190668
190669
190670
190671
190672
190673
190674
190675
190676
190677
190678
190679
190680
190681
190682
190683
190684
190685
190686
190687
190688
190689
190690
190691
190692
190693
190694
190695
190696
190697
190698
190699
190700
190701
190702
190703
190704
190705
190706
190707
190708
190709
190710
190711
190712
190713
190714
190715
190716
190717
190718
190719
190720
190721
190722
190723
190724
190725
190726
190727
190728
190729
190730
190731
190732
190733
190734
190735
190736
190737
190738
190739
190740
190741
190742
190743
190744
190745
190746
190747
190748
190749
190750
190751
190752
190753
190754
190755
190756
190757
190758
190759
190760
190761
190762
190763
190764
190765
190766
190767
190768
190769
190770
190771
190772
190773
190774
190775
190776
190777
190778
190779
190780
190781
190782
190783
190784
190785
190786
190787
190788
190789
190790
190791
190792
190793
190794
190795
190796
190797
190798
190799
190800
190801
190802
190803
190804
190805
190806
190807
190808
190809
190810
190811
190812
190813
190814
190815
190816
190817
190818
190819
190820
190821
190822
190823
190824
190825
190826
190827
190828
190829
190830
190831
190832
190833
190834
190835
190836
190837
190838
190839
190840
190841
190842
190843
190844
190845
190846
190847
190848
190849
190850
190851
190852
190853
190854
190855
190856
190857
190858
190859
190860
190861
190862
190863
190864
190865
190866
190867
190868
190869
190870
190871
190872
190873
190874
190875
190876
190877
190878
190879
190880
190881
190882
190883
190884
190885
190886
190887
190888
190889
190890
190891
190892
190893
190894
190895
190896
190897
190898
190899
190900
190901
190902
190903
190904
190905
190906
190907
190908
190909
190910
190911
190912
190913
190914
190915
190916
190917
190918
190919
190920
190921
190922
190923
190924
190925
190926
190927
190928
190929
190930
190931
190932
190933
190934
190935
190936
190937
190938
190939
190940
190941
190942
190943
190944
190945
190946
190947
190948
190949
190950
190951
190952
190953
190954
190955
190956
190957
190958
190959
190960
190961
190962
190963
190964
190965
190966
190967
190968
190969
190970
190971
190972
190973
190974
190975
190976
190977
190978
190979
190980
190981
190982
190983
190984
190985
190986
190987
190988
190989
190990
190991
190992
190993
190994
190995
190996
190997
190998
190999
191000
191001
191002
191003
191004
191005
191006
191007
191008
191009
191010
191011
191012
191013
191014
191015
191016
191017
191018
191019
191020
191021
191022
191023
191024
191025
191026
191027
191028
191029
191030
191031
191032
191033
191034
191035
191036
191037
191038
191039
191040
191041
191042
191043
191044
191045
191046
191047
191048
191049
191050
191051
191052
191053
191054
191055
191056
191057
191058
191059
191060
191061
191062
191063
191064
191065
191066
191067
191068
191069
191070
191071
191072
191073
191074
191075
191076
191077
191078
191079
191080
191081
191082
191083
191084
191085
191086
191087
191088
191089
191090
191091
191092
191093
191094
191095
191096
191097
191098
191099
191100
191101
191102
191103
191104
191105
191106
191107
191108
191109
191110
191111
191112
191113
191114
191115
191116
191117
191118
191119
191120
191121
191122
191123
191124
191125
191126
191127
191128
191129
191130
191131
191132
191133
191134
191135
191136
191137
191138
191139
191140
191141
191142
191143
191144
191145
191146
191147
191148
191149
191150
191151
191152
191153
191154
191155
191156
191157
191158
191159
191160
191161
191162
191163
191164
191165
191166
191167
191168
191169
191170
191171
191172
191173
191174
191175
191176
191177
191178
191179
191180
191181
191182
191183
191184
191185
191186
191187
191188
191189
191190
191191
191192
191193
191194
191195
191196
191197
191198
191199
191200
191201
191202
191203
191204
191205
191206
191207
191208
191209
191210
191211
191212
191213
191214
191215
191216
191217
191218
191219
191220
191221
191222
191223
191224
191225
191226
191227
191228
191229
191230
191231
191232
191233
191234
191235
191236
191237
191238
191239
191240
191241
191242
191243
191244
191245
191246
191247
191248
191249
191250
191251
191252
191253
191254
191255
191256
191257
191258
191259
191260
191261
191262
191263
191264
191265
191266
191267
191268
191269
191270
191271
191272
191273
191274
191275
191276
191277
191278
191279
191280
191281
191282
191283
191284
191285
191286
191287
191288
191289
191290
191291
191292
191293
191294
191295
191296
191297
191298
191299
191300
191301
191302
191303
191304
191305
191306
191307
191308
191309
191310
191311
191312
191313
191314
191315
191316
191317
191318
191319
191320
191321
191322
191323
191324
191325
191326
191327
191328
191329
191330
191331
191332
191333
191334
191335
191336
191337
191338
191339
191340
191341
191342
191343
191344
191345
191346
191347
191348
191349
191350
191351
191352
191353
191354
191355
191356
191357
191358
191359
191360
191361
191362
191363
191364
191365
191366
191367
191368
191369
191370
191371
191372
191373
191374
191375
191376
191377
191378
191379
191380
191381
191382
191383
191384
191385
191386
191387
191388
191389
191390
191391
191392
191393
191394
191395
191396
191397
191398
191399
191400
191401
191402
191403
191404
191405
191406
191407
191408
191409
191410
191411
191412
191413
191414
191415
191416
191417
191418
191419
191420
191421
191422
191423
191424
191425
191426
191427
191428
191429
191430
191431
191432
191433
191434
191435
191436
191437
191438
191439
191440
191441
191442
191443
191444
191445
191446
191447
191448
191449
191450
191451
191452
191453
191454
191455
191456
191457
191458
191459
191460
191461
191462
191463
191464
191465
191466
191467
191468
191469
191470
191471
191472
191473
191474
191475
191476
191477
191478
191479
191480
191481
191482
191483
191484
191485
191486
191487
191488
191489
191490
191491
191492
191493
191494
191495
191496
191497
191498
191499
191500
191501
191502
191503
191504
191505
191506
191507
191508
191509
191510
191511
191512
191513
191514
191515
191516
191517
191518
191519
191520
191521
191522
191523
191524
191525
191526
191527
191528
191529
191530
191531
191532
191533
191534
191535
191536
191537
191538
191539
191540
191541
191542
191543
191544
191545
191546
191547
191548
191549
191550
191551
191552
191553
191554
191555
191556
191557
191558
191559
191560
191561
191562
191563
191564
191565
191566
191567
191568
191569
191570
191571
191572
191573
191574
191575
191576
191577
191578
191579
191580
191581
191582
191583
191584
191585
191586
191587
191588
191589
191590
191591
191592
191593
191594
191595
191596
191597
191598
191599
191600
191601
191602
191603
191604
191605
191606
191607
191608
191609
191610
191611
191612
191613
191614
191615
191616
191617
191618
191619
191620
191621
191622
191623
191624
191625
191626
191627
191628
191629
191630
191631
191632
191633
191634
191635
191636
191637
191638
191639
191640
191641
191642
191643
191644
191645
191646
191647
191648
191649
191650
191651
191652
191653
191654
191655
191656
191657
191658
191659
191660
191661
191662
191663
191664
191665
191666
191667
191668
191669
191670
191671
191672
191673
191674
191675
191676
191677
191678
191679
191680
191681
191682
191683
191684
191685
191686
191687
191688
191689
191690
191691
191692
191693
191694
191695
191696
191697
191698
191699
191700
191701
191702
191703
191704
191705
191706
191707
191708
191709
191710
191711
191712
191713
191714
191715
191716
191717
191718
191719
191720
191721
191722
191723
191724
191725
191726
191727
191728
191729
191730
191731
191732
191733
191734
191735
191736
191737
191738
191739
191740
191741
191742
191743
191744
191745
191746
191747
191748
191749
191750
191751
191752
191753
191754
191755
191756
191757
191758
191759
191760
191761
191762
191763
191764
191765
191766
191767
191768
191769
191770
191771
191772
191773
191774
191775
191776
191777
191778
191779
191780
191781
191782
191783
191784
191785
191786
191787
191788
191789
191790
191791
191792
191793
191794
191795
191796
191797
191798
191799
191800
191801
191802
191803
191804
191805
191806
191807
191808
191809
191810
191811
191812
191813
191814
191815
191816
191817
191818
191819
191820
191821
191822
191823
191824
191825
191826
191827
191828
191829
191830
191831
191832
191833
191834
191835
191836
191837
191838
191839
191840
191841
191842
191843
191844
191845
191846
191847
191848
191849
191850
191851
191852
191853
191854
191855
191856
191857
191858
191859
191860
191861
191862
191863
191864
191865
191866
191867
191868
191869
191870
191871
191872
191873
191874
191875
191876
191877
191878
191879
191880
191881
191882
191883
191884
191885
191886
191887
191888
191889
191890
191891
191892
191893
191894
191895
191896
191897
191898
191899
191900
191901
191902
191903
191904
191905
191906
191907
191908
191909
191910
191911
191912
191913
191914
191915
191916
191917
191918
191919
191920
191921
191922
191923
191924
191925
191926
191927
191928
191929
191930
191931
191932
191933
191934
191935
191936
191937
191938
191939
191940
191941
191942
191943
191944
191945
191946
191947
191948
191949
191950
191951
191952
191953
191954
191955
191956
191957
191958
191959
191960
191961
191962
191963
191964
191965
191966
191967
191968
191969
191970
191971
191972
191973
191974
191975
191976
191977
191978
191979
191980
191981
191982
191983
191984
191985
191986
191987
191988
191989
191990
191991
191992
191993
191994
191995
191996
191997
191998
191999
192000
192001
192002
192003
192004
192005
192006
192007
192008
192009
192010
192011
192012
192013
192014
192015
192016
192017
192018
192019
192020
192021
192022
192023
192024
192025
192026
192027
192028
192029
192030
192031
192032
192033
192034
192035
192036
192037
192038
192039
192040
192041
192042
192043
192044
192045
192046
192047
192048
192049
192050
192051
192052
192053
192054
192055
192056
192057
192058
192059
192060
192061
192062
192063
192064
192065
192066
192067
192068
192069
192070
192071
192072
192073
192074
192075
192076
192077
192078
192079
192080
192081
192082
192083
192084
192085
192086
192087
192088
192089
192090
192091
192092
192093
192094
192095
192096
192097
192098
192099
192100
192101
192102
192103
192104
192105
192106
192107
192108
192109
192110
192111
192112
192113
192114
192115
192116
192117
192118
192119
192120
192121
192122
192123
192124
192125
192126
192127
192128
192129
192130
192131
192132
192133
192134
192135
192136
192137
192138
192139
192140
192141
192142
192143
192144
192145
192146
192147
192148
192149
192150
192151
192152
192153
192154
192155
192156
192157
192158
192159
192160
192161
192162
192163
192164
192165
192166
192167
192168
192169
192170
192171
192172
192173
192174
192175
192176
192177
192178
192179
192180
192181
192182
192183
192184
192185
192186
192187
192188
192189
192190
192191
192192
192193
192194
192195
192196
192197
192198
192199
192200
192201
192202
192203
192204
192205
192206
192207
192208
192209
192210
192211
192212
192213
192214
192215
192216
192217
192218
192219
192220
192221
192222
192223
192224
192225
192226
192227
192228
192229
192230
192231
192232
192233
192234
192235
192236
192237
192238
192239
192240
192241
192242
192243
192244
192245
192246
192247
192248
192249
192250
192251
192252
192253
192254
192255
192256
192257
192258
192259
192260
192261
192262
192263
192264
192265
192266
192267
192268
192269
192270
192271
192272
192273
192274
192275
192276
192277
192278
192279
192280
192281
192282
192283
192284
192285
192286
192287
192288
192289
192290
192291
192292
192293
192294
192295
192296
192297
192298
192299
192300
192301
192302
192303
192304
192305
192306
192307
192308
192309
192310
192311
192312
192313
192314
192315
192316
192317
192318
192319
192320
192321
192322
192323
192324
192325
192326
192327
192328
192329
192330
192331
192332
192333
192334
192335
192336
192337
192338
192339
192340
192341
192342
192343
192344
192345
192346
192347
192348
192349
192350
192351
192352
192353
192354
192355
192356
192357
192358
192359
192360
192361
192362
192363
192364
192365
192366
192367
192368
192369
192370
192371
192372
192373
192374
192375
192376
192377
192378
192379
192380
192381
192382
192383
192384
192385
192386
192387
192388
192389
192390
192391
192392
192393
192394
192395
192396
192397
192398
192399
192400
192401
192402
192403
192404
192405
192406
192407
192408
192409
192410
192411
192412
192413
192414
192415
192416
192417
192418
192419
192420
192421
192422
192423
192424
192425
192426
192427
192428
192429
192430
192431
192432
192433
192434
192435
192436
192437
192438
192439
192440
192441
192442
192443
192444
192445
192446
192447
192448
192449
192450
192451
192452
192453
192454
192455
192456
192457
192458
192459
192460
192461
192462
192463
192464
192465
192466
192467
192468
192469
192470
192471
192472
192473
192474
192475
192476
192477
192478
192479
192480
192481
192482
192483
192484
192485
192486
192487
192488
192489
192490
192491
192492
192493
192494
192495
192496
192497
192498
192499
192500
192501
192502
192503
192504
192505
192506
192507
192508
192509
192510
192511
192512
192513
192514
192515
192516
192517
192518
192519
192520
192521
192522
192523
192524
192525
192526
192527
192528
192529
192530
192531
192532
192533
192534
192535
192536
192537
192538
192539
192540
192541
192542
192543
192544
192545
192546
192547
192548
192549
192550
192551
192552
192553
192554
192555
192556
192557
192558
192559
192560
192561
192562
192563
192564
192565
192566
192567
192568
192569
192570
192571
192572
192573
192574
192575
192576
192577
192578
192579
192580
192581
192582
192583
192584
192585
192586
192587
192588
192589
192590
192591
192592
192593
192594
192595
192596
192597
192598
192599
192600
192601
192602
192603
192604
192605
192606
192607
192608
192609
192610
192611
192612
192613
192614
192615
192616
192617
192618
192619
192620
192621
192622
192623
192624
192625
192626
192627
192628
192629
192630
192631
192632
192633
192634
192635
192636
192637
192638
192639
192640
192641
192642
192643
192644
192645
192646
192647
192648
192649
192650
192651
192652
192653
192654
192655
192656
192657
192658
192659
192660
192661
192662
192663
192664
192665
192666
192667
192668
192669
192670
192671
192672
192673
192674
192675
192676
192677
192678
192679
192680
192681
192682
192683
192684
192685
192686
192687
192688
192689
192690
192691
192692
192693
192694
192695
192696
192697
192698
192699
192700
192701
192702
192703
192704
192705
192706
192707
192708
192709
192710
192711
192712
192713
192714
192715
192716
192717
192718
192719
192720
192721
192722
192723
192724
192725
192726
192727
192728
192729
192730
192731
192732
192733
192734
192735
192736
192737
192738
192739
192740
192741
192742
192743
192744
192745
192746
192747
192748
192749
192750
192751
192752
192753
192754
192755
192756
192757
192758
192759
192760
192761
192762
192763
192764
192765
192766
192767
192768
192769
192770
192771
192772
192773
192774
192775
192776
192777
192778
192779
192780
192781
192782
192783
192784
192785
192786
192787
192788
192789
192790
192791
192792
192793
192794
192795
192796
192797
192798
192799
192800
192801
192802
192803
192804
192805
192806
192807
192808
192809
192810
192811
192812
192813
192814
192815
192816
192817
192818
192819
192820
192821
192822
192823
192824
192825
192826
192827
192828
192829
192830
192831
192832
192833
192834
192835
192836
192837
192838
192839
192840
192841
192842
192843
192844
192845
192846
192847
192848
192849
192850
192851
192852
192853
192854
192855
192856
192857
192858
192859
192860
192861
192862
192863
192864
192865
192866
192867
192868
192869
192870
192871
192872
192873
192874
192875
192876
192877
192878
192879
192880
192881
192882
192883
192884
192885
192886
192887
192888
192889
192890
192891
192892
192893
192894
192895
192896
192897
192898
192899
192900
192901
192902
192903
192904
192905
192906
192907
192908
192909
192910
192911
192912
192913
192914
192915
192916
192917
192918
192919
192920
192921
192922
192923
192924
192925
192926
192927
192928
192929
192930
192931
192932
192933
192934
192935
192936
192937
192938
192939
192940
192941
192942
192943
192944
192945
192946
192947
192948
192949
192950
192951
192952
192953
192954
192955
192956
192957
192958
192959
192960
192961
192962
192963
192964
192965
192966
192967
192968
192969
192970
192971
192972
192973
192974
192975
192976
192977
192978
192979
192980
192981
192982
192983
192984
192985
192986
192987
192988
192989
192990
192991
192992
192993
192994
192995
192996
192997
192998
192999
193000
193001
193002
193003
193004
193005
193006
193007
193008
193009
193010
193011
193012
193013
193014
193015
193016
193017
193018
193019
193020
193021
193022
193023
193024
193025
193026
193027
193028
193029
193030
193031
193032
193033
193034
193035
193036
193037
193038
193039
193040
193041
193042
193043
193044
193045
193046
193047
193048
193049
193050
193051
193052
193053
193054
193055
193056
193057
193058
193059
193060
193061
193062
193063
193064
193065
193066
193067
193068
193069
193070
193071
193072
193073
193074
193075
193076
193077
193078
193079
193080
193081
193082
193083
193084
193085
193086
193087
193088
193089
193090
193091
193092
193093
193094
193095
193096
193097
193098
193099
193100
193101
193102
193103
193104
193105
193106
193107
193108
193109
193110
193111
193112
193113
193114
193115
193116
193117
193118
193119
193120
193121
193122
193123
193124
193125
193126
193127
193128
193129
193130
193131
193132
193133
193134
193135
193136
193137
193138
193139
193140
193141
193142
193143
193144
193145
193146
193147
193148
193149
193150
193151
193152
193153
193154
193155
193156
193157
193158
193159
193160
193161
193162
193163
193164
193165
193166
193167
193168
193169
193170
193171
193172
193173
193174
193175
193176
193177
193178
193179
193180
193181
193182
193183
193184
193185
193186
193187
193188
193189
193190
193191
193192
193193
193194
193195
193196
193197
193198
193199
193200
193201
193202
193203
193204
193205
193206
193207
193208
193209
193210
193211
193212
193213
193214
193215
193216
193217
193218
193219
193220
193221
193222
193223
193224
193225
193226
193227
193228
193229
193230
193231
193232
193233
193234
193235
193236
193237
193238
193239
193240
193241
193242
193243
193244
193245
193246
193247
193248
193249
193250
193251
193252
193253
193254
193255
193256
193257
193258
193259
193260
193261
193262
193263
193264
193265
193266
193267
193268
193269
193270
193271
193272
193273
193274
193275
193276
193277
193278
193279
193280
193281
193282
193283
193284
193285
193286
193287
193288
193289
193290
193291
193292
193293
193294
193295
193296
193297
193298
193299
193300
193301
193302
193303
193304
193305
193306
193307
193308
193309
193310
193311
193312
193313
193314
193315
193316
193317
193318
193319
193320
193321
193322
193323
193324
193325
193326
193327
193328
193329
193330
193331
193332
193333
193334
193335
193336
193337
193338
193339
193340
193341
193342
193343
193344
193345
193346
193347
193348
193349
193350
193351
193352
193353
193354
193355
193356
193357
193358
193359
193360
193361
193362
193363
193364
193365
193366
193367
193368
193369
193370
193371
193372
193373
193374
193375
193376
193377
193378
193379
193380
193381
193382
193383
193384
193385
193386
193387
193388
193389
193390
193391
193392
193393
193394
193395
193396
193397
193398
193399
193400
193401
193402
193403
193404
193405
193406
193407
193408
193409
193410
193411
193412
193413
193414
193415
193416
193417
193418
193419
193420
193421
193422
193423
193424
193425
193426
193427
193428
193429
193430
193431
193432
193433
193434
193435
193436
193437
193438
193439
193440
193441
193442
193443
193444
193445
193446
193447
193448
193449
193450
193451
193452
193453
193454
193455
193456
193457
193458
193459
193460
193461
193462
193463
193464
193465
193466
193467
193468
193469
193470
193471
193472
193473
193474
193475
193476
193477
193478
193479
193480
193481
193482
193483
193484
193485
193486
193487
193488
193489
193490
193491
193492
193493
193494
193495
193496
193497
193498
193499
193500
193501
193502
193503
193504
193505
193506
193507
193508
193509
193510
193511
193512
193513
193514
193515
193516
193517
193518
193519
193520
193521
193522
193523
193524
193525
193526
193527
193528
193529
193530
193531
193532
193533
193534
193535
193536
193537
193538
193539
193540
193541
193542
193543
193544
193545
193546
193547
193548
193549
193550
193551
193552
193553
193554
193555
193556
193557
193558
193559
193560
193561
193562
193563
193564
193565
193566
193567
193568
193569
193570
193571
193572
193573
193574
193575
193576
193577
193578
193579
193580
193581
193582
193583
193584
193585
193586
193587
193588
193589
193590
193591
193592
193593
193594
193595
193596
193597
193598
193599
193600
193601
193602
193603
193604
193605
193606
193607
193608
193609
193610
193611
193612
193613
193614
193615
193616
193617
193618
193619
193620
193621
193622
193623
193624
193625
193626
193627
193628
193629
193630
193631
193632
193633
193634
193635
193636
193637
193638
193639
193640
193641
193642
193643
193644
193645
193646
193647
193648
193649
193650
193651
193652
193653
193654
193655
193656
193657
193658
193659
193660
193661
193662
193663
193664
193665
193666
193667
193668
193669
193670
193671
193672
193673
193674
193675
193676
193677
193678
193679
193680
193681
193682
193683
193684
193685
193686
193687
193688
193689
193690
193691
193692
193693
193694
193695
193696
193697
193698
193699
193700
193701
193702
193703
193704
193705
193706
193707
193708
193709
193710
193711
193712
193713
193714
193715
193716
193717
193718
193719
193720
193721
193722
193723
193724
193725
193726
193727
193728
193729
193730
193731
193732
193733
193734
193735
193736
193737
193738
193739
193740
193741
193742
193743
193744
193745
193746
193747
193748
193749
193750
193751
193752
193753
193754
193755
193756
193757
193758
193759
193760
193761
193762
193763
193764
193765
193766
193767
193768
193769
193770
193771
193772
193773
193774
193775
193776
193777
193778
193779
193780
193781
193782
193783
193784
193785
193786
193787
193788
193789
193790
193791
193792
193793
193794
193795
193796
193797
193798
193799
193800
193801
193802
193803
193804
193805
193806
193807
193808
193809
193810
193811
193812
193813
193814
193815
193816
193817
193818
193819
193820
193821
193822
193823
193824
193825
193826
193827
193828
193829
193830
193831
193832
193833
193834
193835
193836
193837
193838
193839
193840
193841
193842
193843
193844
193845
193846
193847
193848
193849
193850
193851
193852
193853
193854
193855
193856
193857
193858
193859
193860
193861
193862
193863
193864
193865
193866
193867
193868
193869
193870
193871
193872
193873
193874
193875
193876
193877
193878
193879
193880
193881
193882
193883
193884
193885
193886
193887
193888
193889
193890
193891
193892
193893
193894
193895
193896
193897
193898
193899
193900
193901
193902
193903
193904
193905
193906
193907
193908
193909
193910
193911
193912
193913
193914
193915
193916
193917
193918
193919
193920
193921
193922
193923
193924
193925
193926
193927
193928
193929
193930
193931
193932
193933
193934
193935
193936
193937
193938
193939
193940
193941
193942
193943
193944
193945
193946
193947
193948
193949
193950
193951
193952
193953
193954
193955
193956
193957
193958
193959
193960
193961
193962
193963
193964
193965
193966
193967
193968
193969
193970
193971
193972
193973
193974
193975
193976
193977
193978
193979
193980
193981
193982
193983
193984
193985
193986
193987
193988
193989
193990
193991
193992
193993
193994
193995
193996
193997
193998
193999
194000
194001
194002
194003
194004
194005
194006
194007
194008
194009
194010
194011
194012
194013
194014
194015
194016
194017
194018
194019
194020
194021
194022
194023
194024
194025
194026
194027
194028
194029
194030
194031
194032
194033
194034
194035
194036
194037
194038
194039
194040
194041
194042
194043
194044
194045
194046
194047
194048
194049
194050
194051
194052
194053
194054
194055
194056
194057
194058
194059
194060
194061
194062
194063
194064
194065
194066
194067
194068
194069
194070
194071
194072
194073
194074
194075
194076
194077
194078
194079
194080
194081
194082
194083
194084
194085
194086
194087
194088
194089
194090
194091
194092
194093
194094
194095
194096
194097
194098
194099
194100
194101
194102
194103
194104
194105
194106
194107
194108
194109
194110
194111
194112
194113
194114
194115
194116
194117
194118
194119
194120
194121
194122
194123
194124
194125
194126
194127
194128
194129
194130
194131
194132
194133
194134
194135
194136
194137
194138
194139
194140
194141
194142
194143
194144
194145
194146
194147
194148
194149
194150
194151
194152
194153
194154
194155
194156
194157
194158
194159
194160
194161
194162
194163
194164
194165
194166
194167
194168
194169
194170
194171
194172
194173
194174
194175
194176
194177
194178
194179
194180
194181
194182
194183
194184
194185
194186
194187
194188
194189
194190
194191
194192
194193
194194
194195
194196
194197
194198
194199
194200
194201
194202
194203
194204
194205
194206
194207
194208
194209
194210
194211
194212
194213
194214
194215
194216
194217
194218
194219
194220
194221
194222
194223
194224
194225
194226
194227
194228
194229
194230
194231
194232
194233
194234
194235
194236
194237
194238
194239
194240
194241
194242
194243
194244
194245
194246
194247
194248
194249
194250
194251
194252
194253
194254
194255
194256
194257
194258
194259
194260
194261
194262
194263
194264
194265
194266
194267
194268
194269
194270
194271
194272
194273
194274
194275
194276
194277
194278
194279
194280
194281
194282
194283
194284
194285
194286
194287
194288
194289
194290
194291
194292
194293
194294
194295
194296
194297
194298
194299
194300
194301
194302
194303
194304
194305
194306
194307
194308
194309
194310
194311
194312
194313
194314
194315
194316
194317
194318
194319
194320
194321
194322
194323
194324
194325
194326
194327
194328
194329
194330
194331
194332
194333
194334
194335
194336
194337
194338
194339
194340
194341
194342
194343
194344
194345
194346
194347
194348
194349
194350
194351
194352
194353
194354
194355
194356
194357
194358
194359
194360
194361
194362
194363
194364
194365
194366
194367
194368
194369
194370
194371
194372
194373
194374
194375
194376
194377
194378
194379
194380
194381
194382
194383
194384
194385
194386
194387
194388
194389
194390
194391
194392
194393
194394
194395
194396
194397
194398
194399
194400
194401
194402
194403
194404
194405
194406
194407
194408
194409
194410
194411
194412
194413
194414
194415
194416
194417
194418
194419
194420
194421
194422
194423
194424
194425
194426
194427
194428
194429
194430
194431
194432
194433
194434
194435
194436
194437
194438
194439
194440
194441
194442
194443
194444
194445
194446
194447
194448
194449
194450
194451
194452
194453
194454
194455
194456
194457
194458
194459
194460
194461
194462
194463
194464
194465
194466
194467
194468
194469
194470
194471
194472
194473
194474
194475
194476
194477
194478
194479
194480
194481
194482
194483
194484
194485
194486
194487
194488
194489
194490
194491
194492
194493
194494
194495
194496
194497
194498
194499
194500
194501
194502
194503
194504
194505
194506
194507
194508
194509
194510
194511
194512
194513
194514
194515
194516
194517
194518
194519
194520
194521
194522
194523
194524
194525
194526
194527
194528
194529
194530
194531
194532
194533
194534
194535
194536
194537
194538
194539
194540
194541
194542
194543
194544
194545
194546
194547
194548
194549
194550
194551
194552
194553
194554
194555
194556
194557
194558
194559
194560
194561
194562
194563
194564
194565
194566
194567
194568
194569
194570
194571
194572
194573
194574
194575
194576
194577
194578
194579
194580
194581
194582
194583
194584
194585
194586
194587
194588
194589
194590
194591
194592
194593
194594
194595
194596
194597
194598
194599
194600
194601
194602
194603
194604
194605
194606
194607
194608
194609
194610
194611
194612
194613
194614
194615
194616
194617
194618
194619
194620
194621
194622
194623
194624
194625
194626
194627
194628
194629
194630
194631
194632
194633
194634
194635
194636
194637
194638
194639
194640
194641
194642
194643
194644
194645
194646
194647
194648
194649
194650
194651
194652
194653
194654
194655
194656
194657
194658
194659
194660
194661
194662
194663
194664
194665
194666
194667
194668
194669
194670
194671
194672
194673
194674
194675
194676
194677
194678
194679
194680
194681
194682
194683
194684
194685
194686
194687
194688
194689
194690
194691
194692
194693
194694
194695
194696
194697
194698
194699
194700
194701
194702
194703
194704
194705
194706
194707
194708
194709
194710
194711
194712
194713
194714
194715
194716
194717
194718
194719
194720
194721
194722
194723
194724
194725
194726
194727
194728
194729
194730
194731
194732
194733
194734
194735
194736
194737
194738
194739
194740
194741
194742
194743
194744
194745
194746
194747
194748
194749
194750
194751
194752
194753
194754
194755
194756
194757
194758
194759
194760
194761
194762
194763
194764
194765
194766
194767
194768
194769
194770
194771
194772
194773
194774
194775
194776
194777
194778
194779
194780
194781
194782
194783
194784
194785
194786
194787
194788
194789
194790
194791
194792
194793
194794
194795
194796
194797
194798
194799
194800
194801
194802
194803
194804
194805
194806
194807
194808
194809
194810
194811
194812
194813
194814
194815
194816
194817
194818
194819
194820
194821
194822
194823
194824
194825
194826
194827
194828
194829
194830
194831
194832
194833
194834
194835
194836
194837
194838
194839
194840
194841
194842
194843
194844
194845
194846
194847
194848
194849
194850
194851
194852
194853
194854
194855
194856
194857
194858
194859
194860
194861
194862
194863
194864
194865
194866
194867
194868
194869
194870
194871
194872
194873
194874
194875
194876
194877
194878
194879
194880
194881
194882
194883
194884
194885
194886
194887
194888
194889
194890
194891
194892
194893
194894
194895
194896
194897
194898
194899
194900
194901
194902
194903
194904
194905
194906
194907
194908
194909
194910
194911
194912
194913
194914
194915
194916
194917
194918
194919
194920
194921
194922
194923
194924
194925
194926
194927
194928
194929
194930
194931
194932
194933
194934
194935
194936
194937
194938
194939
194940
194941
194942
194943
194944
194945
194946
194947
194948
194949
194950
194951
194952
194953
194954
194955
194956
194957
194958
194959
194960
194961
194962
194963
194964
194965
194966
194967
194968
194969
194970
194971
194972
194973
194974
194975
194976
194977
194978
194979
194980
194981
194982
194983
194984
194985
194986
194987
194988
194989
194990
194991
194992
194993
194994
194995
194996
194997
194998
194999
195000
195001
195002
195003
195004
195005
195006
195007
195008
195009
195010
195011
195012
195013
195014
195015
195016
195017
195018
195019
195020
195021
195022
195023
195024
195025
195026
195027
195028
195029
195030
195031
195032
195033
195034
195035
195036
195037
195038
195039
195040
195041
195042
195043
195044
195045
195046
195047
195048
195049
195050
195051
195052
195053
195054
195055
195056
195057
195058
195059
195060
195061
195062
195063
195064
195065
195066
195067
195068
195069
195070
195071
195072
195073
195074
195075
195076
195077
195078
195079
195080
195081
195082
195083
195084
195085
195086
195087
195088
195089
195090
195091
195092
195093
195094
195095
195096
195097
195098
195099
195100
195101
195102
195103
195104
195105
195106
195107
195108
195109
195110
195111
195112
195113
195114
195115
195116
195117
195118
195119
195120
195121
195122
195123
195124
195125
195126
195127
195128
195129
195130
195131
195132
195133
195134
195135
195136
195137
195138
195139
195140
195141
195142
195143
195144
195145
195146
195147
195148
195149
195150
195151
195152
195153
195154
195155
195156
195157
195158
195159
195160
195161
195162
195163
195164
195165
195166
195167
195168
195169
195170
195171
195172
195173
195174
195175
195176
195177
195178
195179
195180
195181
195182
195183
195184
195185
195186
195187
195188
195189
195190
195191
195192
195193
195194
195195
195196
195197
195198
195199
195200
195201
195202
195203
195204
195205
195206
195207
195208
195209
195210
195211
195212
195213
195214
195215
195216
195217
195218
195219
195220
195221
195222
195223
195224
195225
195226
195227
195228
195229
195230
195231
195232
195233
195234
195235
195236
195237
195238
195239
195240
195241
195242
195243
195244
195245
195246
195247
195248
195249
195250
195251
195252
195253
195254
195255
195256
195257
195258
195259
195260
195261
195262
195263
195264
195265
195266
195267
195268
195269
195270
195271
195272
195273
195274
195275
195276
195277
195278
195279
195280
195281
195282
195283
195284
195285
195286
195287
195288
195289
195290
195291
195292
195293
195294
195295
195296
195297
195298
195299
195300
195301
195302
195303
195304
195305
195306
195307
195308
195309
195310
195311
195312
195313
195314
195315
195316
195317
195318
195319
195320
195321
195322
195323
195324
195325
195326
195327
195328
195329
195330
195331
195332
195333
195334
195335
195336
195337
195338
195339
195340
195341
195342
195343
195344
195345
195346
195347
195348
195349
195350
195351
195352
195353
195354
195355
195356
195357
195358
195359
195360
195361
195362
195363
195364
195365
195366
195367
195368
195369
195370
195371
195372
195373
195374
195375
195376
195377
195378
195379
195380
195381
195382
195383
195384
195385
195386
195387
195388
195389
195390
195391
195392
195393
195394
195395
195396
195397
195398
195399
195400
195401
195402
195403
195404
195405
195406
195407
195408
195409
195410
195411
195412
195413
195414
195415
195416
195417
195418
195419
195420
195421
195422
195423
195424
195425
195426
195427
195428
195429
195430
195431
195432
195433
195434
195435
195436
195437
195438
195439
195440
195441
195442
195443
195444
195445
195446
195447
195448
195449
195450
195451
195452
195453
195454
195455
195456
195457
195458
195459
195460
195461
195462
195463
195464
195465
195466
195467
195468
195469
195470
195471
195472
195473
195474
195475
195476
195477
195478
195479
195480
195481
195482
195483
195484
195485
195486
195487
195488
195489
195490
195491
195492
195493
195494
195495
195496
195497
195498
195499
195500
195501
195502
195503
195504
195505
195506
195507
195508
195509
195510
195511
195512
195513
195514
195515
195516
195517
195518
195519
195520
195521
195522
195523
195524
195525
195526
195527
195528
195529
195530
195531
195532
195533
195534
195535
195536
195537
195538
195539
195540
195541
195542
195543
195544
195545
195546
195547
195548
195549
195550
195551
195552
195553
195554
195555
195556
195557
195558
195559
195560
195561
195562
195563
195564
195565
195566
195567
195568
195569
195570
195571
195572
195573
195574
195575
195576
195577
195578
195579
195580
195581
195582
195583
195584
195585
195586
195587
195588
195589
195590
195591
195592
195593
195594
195595
195596
195597
195598
195599
195600
195601
195602
195603
195604
195605
195606
195607
195608
195609
195610
195611
195612
195613
195614
195615
195616
195617
195618
195619
195620
195621
195622
195623
195624
195625
195626
195627
195628
195629
195630
195631
195632
195633
195634
195635
195636
195637
195638
195639
195640
195641
195642
195643
195644
195645
195646
195647
195648
195649
195650
195651
195652
195653
195654
195655
195656
195657
195658
195659
195660
195661
195662
195663
195664
195665
195666
195667
195668
195669
195670
195671
195672
195673
195674
195675
195676
195677
195678
195679
195680
195681
195682
195683
195684
195685
195686
195687
195688
195689
195690
195691
195692
195693
195694
195695
195696
195697
195698
195699
195700
195701
195702
195703
195704
195705
195706
195707
195708
195709
195710
195711
195712
195713
195714
195715
195716
195717
195718
195719
195720
195721
195722
195723
195724
195725
195726
195727
195728
195729
195730
195731
195732
195733
195734
195735
195736
195737
195738
195739
195740
195741
195742
195743
195744
195745
195746
195747
195748
195749
195750
195751
195752
195753
195754
195755
195756
195757
195758
195759
195760
195761
195762
195763
195764
195765
195766
195767
195768
195769
195770
195771
195772
195773
195774
195775
195776
195777
195778
195779
195780
195781
195782
195783
195784
195785
195786
195787
195788
195789
195790
195791
195792
195793
195794
195795
195796
195797
195798
195799
195800
195801
195802
195803
195804
195805
195806
195807
195808
195809
195810
195811
195812
195813
195814
195815
195816
195817
195818
195819
195820
195821
195822
195823
195824
195825
195826
195827
195828
195829
195830
195831
195832
195833
195834
195835
195836
195837
195838
195839
195840
195841
195842
195843
195844
195845
195846
195847
195848
195849
195850
195851
195852
195853
195854
195855
195856
195857
195858
195859
195860
195861
195862
195863
195864
195865
195866
195867
195868
195869
195870
195871
195872
195873
195874
195875
195876
195877
195878
195879
195880
195881
195882
195883
195884
195885
195886
195887
195888
195889
195890
195891
195892
195893
195894
195895
195896
195897
195898
195899
195900
195901
195902
195903
195904
195905
195906
195907
195908
195909
195910
195911
195912
195913
195914
195915
195916
195917
195918
195919
195920
195921
195922
195923
195924
195925
195926
195927
195928
195929
195930
195931
195932
195933
195934
195935
195936
195937
195938
195939
195940
195941
195942
195943
195944
195945
195946
195947
195948
195949
195950
195951
195952
195953
195954
195955
195956
195957
195958
195959
195960
195961
195962
195963
195964
195965
195966
195967
195968
195969
195970
195971
195972
195973
195974
195975
195976
195977
195978
195979
195980
195981
195982
195983
195984
195985
195986
195987
195988
195989
195990
195991
195992
195993
195994
195995
195996
195997
195998
195999
196000
196001
196002
196003
196004
196005
196006
196007
196008
196009
196010
196011
196012
196013
196014
196015
196016
196017
196018
196019
196020
196021
196022
196023
196024
196025
196026
196027
196028
196029
196030
196031
196032
196033
196034
196035
196036
196037
196038
196039
196040
196041
196042
196043
196044
196045
196046
196047
196048
196049
196050
196051
196052
196053
196054
196055
196056
196057
196058
196059
196060
196061
196062
196063
196064
196065
196066
196067
196068
196069
196070
196071
196072
196073
196074
196075
196076
196077
196078
196079
196080
196081
196082
196083
196084
196085
196086
196087
196088
196089
196090
196091
196092
196093
196094
196095
196096
196097
196098
196099
196100
196101
196102
196103
196104
196105
196106
196107
196108
196109
196110
196111
196112
196113
196114
196115
196116
196117
196118
196119
196120
196121
196122
196123
196124
196125
196126
196127
196128
196129
196130
196131
196132
196133
196134
196135
196136
196137
196138
196139
196140
196141
196142
196143
196144
196145
196146
196147
196148
196149
196150
196151
196152
196153
196154
196155
196156
196157
196158
196159
196160
196161
196162
196163
196164
196165
196166
196167
196168
196169
196170
196171
196172
196173
196174
196175
196176
196177
196178
196179
196180
196181
196182
196183
196184
196185
196186
196187
196188
196189
196190
196191
196192
196193
196194
196195
196196
196197
196198
196199
196200
196201
196202
196203
196204
196205
196206
196207
196208
196209
196210
196211
196212
196213
196214
196215
196216
196217
196218
196219
196220
196221
196222
196223
196224
196225
196226
196227
196228
196229
196230
196231
196232
196233
196234
196235
196236
196237
196238
196239
196240
196241
196242
196243
196244
196245
196246
196247
196248
196249
196250
196251
196252
196253
196254
196255
196256
196257
196258
196259
196260
196261
196262
196263
196264
196265
196266
196267
196268
196269
196270
196271
196272
196273
196274
196275
196276
196277
196278
196279
196280
196281
196282
196283
196284
196285
196286
196287
196288
196289
196290
196291
196292
196293
196294
196295
196296
196297
196298
196299
196300
196301
196302
196303
196304
196305
196306
196307
196308
196309
196310
196311
196312
196313
196314
196315
196316
196317
196318
196319
196320
196321
196322
196323
196324
196325
196326
196327
196328
196329
196330
196331
196332
196333
196334
196335
196336
196337
196338
196339
196340
196341
196342
196343
196344
196345
196346
196347
196348
196349
196350
196351
196352
196353
196354
196355
196356
196357
196358
196359
196360
196361
196362
196363
196364
196365
196366
196367
196368
196369
196370
196371
196372
196373
196374
196375
196376
196377
196378
196379
196380
196381
196382
196383
196384
196385
196386
196387
196388
196389
196390
196391
196392
196393
196394
196395
196396
196397
196398
196399
196400
196401
196402
196403
196404
196405
196406
196407
196408
196409
196410
196411
196412
196413
196414
196415
196416
196417
196418
196419
196420
196421
196422
196423
196424
196425
196426
196427
196428
196429
196430
196431
196432
196433
196434
196435
196436
196437
196438
196439
196440
196441
196442
196443
196444
196445
196446
196447
196448
196449
196450
196451
196452
196453
196454
196455
196456
196457
196458
196459
196460
196461
196462
196463
196464
196465
196466
196467
196468
196469
196470
196471
196472
196473
196474
196475
196476
196477
196478
196479
196480
196481
196482
196483
196484
196485
196486
196487
196488
196489
196490
196491
196492
196493
196494
196495
196496
196497
196498
196499
196500
196501
196502
196503
196504
196505
196506
196507
196508
196509
196510
196511
196512
196513
196514
196515
196516
196517
196518
196519
196520
196521
196522
196523
196524
196525
196526
196527
196528
196529
196530
196531
196532
196533
196534
196535
196536
196537
196538
196539
196540
196541
196542
196543
196544
196545
196546
196547
196548
196549
196550
196551
196552
196553
196554
196555
196556
196557
196558
196559
196560
196561
196562
196563
196564
196565
196566
196567
196568
196569
196570
196571
196572
196573
196574
196575
196576
196577
196578
196579
196580
196581
196582
196583
196584
196585
196586
196587
196588
196589
196590
196591
196592
196593
196594
196595
196596
196597
196598
196599
196600
196601
196602
196603
196604
196605
196606
196607
196608
196609
196610
196611
196612
196613
196614
196615
196616
196617
196618
196619
196620
196621
196622
196623
196624
196625
196626
196627
196628
196629
196630
196631
196632
196633
196634
196635
196636
196637
196638
196639
196640
196641
196642
196643
196644
196645
196646
196647
196648
196649
196650
196651
196652
196653
196654
196655
196656
196657
196658
196659
196660
196661
196662
196663
196664
196665
196666
196667
196668
196669
196670
196671
196672
196673
196674
196675
196676
196677
196678
196679
196680
196681
196682
196683
196684
196685
196686
196687
196688
196689
196690
196691
196692
196693
196694
196695
196696
196697
196698
196699
196700
196701
196702
196703
196704
196705
196706
196707
196708
196709
196710
196711
196712
196713
196714
196715
196716
196717
196718
196719
196720
196721
196722
196723
196724
196725
196726
196727
196728
196729
196730
196731
196732
196733
196734
196735
196736
196737
196738
196739
196740
196741
196742
196743
196744
196745
196746
196747
196748
196749
196750
196751
196752
196753
196754
196755
196756
196757
196758
196759
196760
196761
196762
196763
196764
196765
196766
196767
196768
196769
196770
196771
196772
196773
196774
196775
196776
196777
196778
196779
196780
196781
196782
196783
196784
196785
196786
196787
196788
196789
196790
196791
196792
196793
196794
196795
196796
196797
196798
196799
196800
196801
196802
196803
196804
196805
196806
196807
196808
196809
196810
196811
196812
196813
196814
196815
196816
196817
196818
196819
196820
196821
196822
196823
196824
196825
196826
196827
196828
196829
196830
196831
196832
196833
196834
196835
196836
196837
196838
196839
196840
196841
196842
196843
196844
196845
196846
196847
196848
196849
196850
196851
196852
196853
196854
196855
196856
196857
196858
196859
196860
196861
196862
196863
196864
196865
196866
196867
196868
196869
196870
196871
196872
196873
196874
196875
196876
196877
196878
196879
196880
196881
196882
196883
196884
196885
196886
196887
196888
196889
196890
196891
196892
196893
196894
196895
196896
196897
196898
196899
196900
196901
196902
196903
196904
196905
196906
196907
196908
196909
196910
196911
196912
196913
196914
196915
196916
196917
196918
196919
196920
196921
196922
196923
196924
196925
196926
196927
196928
196929
196930
196931
196932
196933
196934
196935
196936
196937
196938
196939
196940
196941
196942
196943
196944
196945
196946
196947
196948
196949
196950
196951
196952
196953
196954
196955
196956
196957
196958
196959
196960
196961
196962
196963
196964
196965
196966
196967
196968
196969
196970
196971
196972
196973
196974
196975
196976
196977
196978
196979
196980
196981
196982
196983
196984
196985
196986
196987
196988
196989
196990
196991
196992
196993
196994
196995
196996
196997
196998
196999
197000
197001
197002
197003
197004
197005
197006
197007
197008
197009
197010
197011
197012
197013
197014
197015
197016
197017
197018
197019
197020
197021
197022
197023
197024
197025
197026
197027
197028
197029
197030
197031
197032
197033
197034
197035
197036
197037
197038
197039
197040
197041
197042
197043
197044
197045
197046
197047
197048
197049
197050
197051
197052
197053
197054
197055
197056
197057
197058
197059
197060
197061
197062
197063
197064
197065
197066
197067
197068
197069
197070
197071
197072
197073
197074
197075
197076
197077
197078
197079
197080
197081
197082
197083
197084
197085
197086
197087
197088
197089
197090
197091
197092
197093
197094
197095
197096
197097
197098
197099
197100
197101
197102
197103
197104
197105
197106
197107
197108
197109
197110
197111
197112
197113
197114
197115
197116
197117
197118
197119
197120
197121
197122
197123
197124
197125
197126
197127
197128
197129
197130
197131
197132
197133
197134
197135
197136
197137
197138
197139
197140
197141
197142
197143
197144
197145
197146
197147
197148
197149
197150
197151
197152
197153
197154
197155
197156
197157
197158
197159
197160
197161
197162
197163
197164
197165
197166
197167
197168
197169
197170
197171
197172
197173
197174
197175
197176
197177
197178
197179
197180
197181
197182
197183
197184
197185
197186
197187
197188
197189
197190
197191
197192
197193
197194
197195
197196
197197
197198
197199
197200
197201
197202
197203
197204
197205
197206
197207
197208
197209
197210
197211
197212
197213
197214
197215
197216
197217
197218
197219
197220
197221
197222
197223
197224
197225
197226
197227
197228
197229
197230
197231
197232
197233
197234
197235
197236
197237
197238
197239
197240
197241
197242
197243
197244
197245
197246
197247
197248
197249
197250
197251
197252
197253
197254
197255
197256
197257
197258
197259
197260
197261
197262
197263
197264
197265
197266
197267
197268
197269
197270
197271
197272
197273
197274
197275
197276
197277
197278
197279
197280
197281
197282
197283
197284
197285
197286
197287
197288
197289
197290
197291
197292
197293
197294
197295
197296
197297
197298
197299
197300
197301
197302
197303
197304
197305
197306
197307
197308
197309
197310
197311
197312
197313
197314
197315
197316
197317
197318
197319
197320
197321
197322
197323
197324
197325
197326
197327
197328
197329
197330
197331
197332
197333
197334
197335
197336
197337
197338
197339
197340
197341
197342
197343
197344
197345
197346
197347
197348
197349
197350
197351
197352
197353
197354
197355
197356
197357
197358
197359
197360
197361
197362
197363
197364
197365
197366
197367
197368
197369
197370
197371
197372
197373
197374
197375
197376
197377
197378
197379
197380
197381
197382
197383
197384
197385
197386
197387
197388
197389
197390
197391
197392
197393
197394
197395
197396
197397
197398
197399
197400
197401
197402
197403
197404
197405
197406
197407
197408
197409
197410
197411
197412
197413
197414
197415
197416
197417
197418
197419
197420
197421
197422
197423
197424
197425
197426
197427
197428
197429
197430
197431
197432
197433
197434
197435
197436
197437
197438
197439
197440
197441
197442
197443
197444
197445
197446
197447
197448
197449
197450
197451
197452
197453
197454
197455
197456
197457
197458
197459
197460
197461
197462
197463
197464
197465
197466
197467
197468
197469
197470
197471
197472
197473
197474
197475
197476
197477
197478
197479
197480
197481
197482
197483
197484
197485
197486
197487
197488
197489
197490
197491
197492
197493
197494
197495
197496
197497
197498
197499
197500
197501
197502
197503
197504
197505
197506
197507
197508
197509
197510
197511
197512
197513
197514
197515
197516
197517
197518
197519
197520
197521
197522
197523
197524
197525
197526
197527
197528
197529
197530
197531
197532
197533
197534
197535
197536
197537
197538
197539
197540
197541
197542
197543
197544
197545
197546
197547
197548
197549
197550
197551
197552
197553
197554
197555
197556
197557
197558
197559
197560
197561
197562
197563
197564
197565
197566
197567
197568
197569
197570
197571
197572
197573
197574
197575
197576
197577
197578
197579
197580
197581
197582
197583
197584
197585
197586
197587
197588
197589
197590
197591
197592
197593
197594
197595
197596
197597
197598
197599
197600
197601
197602
197603
197604
197605
197606
197607
197608
197609
197610
197611
197612
197613
197614
197615
197616
197617
197618
197619
197620
197621
197622
197623
197624
197625
197626
197627
197628
197629
197630
197631
197632
197633
197634
197635
197636
197637
197638
197639
197640
197641
197642
197643
197644
197645
197646
197647
197648
197649
197650
197651
197652
197653
197654
197655
197656
197657
197658
197659
197660
197661
197662
197663
197664
197665
197666
197667
197668
197669
197670
197671
197672
197673
197674
197675
197676
197677
197678
197679
197680
197681
197682
197683
197684
197685
197686
197687
197688
197689
197690
197691
197692
197693
197694
197695
197696
197697
197698
197699
197700
197701
197702
197703
197704
197705
197706
197707
197708
197709
197710
197711
197712
197713
197714
197715
197716
197717
197718
197719
197720
197721
197722
197723
197724
197725
197726
197727
197728
197729
197730
197731
197732
197733
197734
197735
197736
197737
197738
197739
197740
197741
197742
197743
197744
197745
197746
197747
197748
197749
197750
197751
197752
197753
197754
197755
197756
197757
197758
197759
197760
197761
197762
197763
197764
197765
197766
197767
197768
197769
197770
197771
197772
197773
197774
197775
197776
197777
197778
197779
197780
197781
197782
197783
197784
197785
197786
197787
197788
197789
197790
197791
197792
197793
197794
197795
197796
197797
197798
197799
197800
197801
197802
197803
197804
197805
197806
197807
197808
197809
197810
197811
197812
197813
197814
197815
197816
197817
197818
197819
197820
197821
197822
197823
197824
197825
197826
197827
197828
197829
197830
197831
197832
197833
197834
197835
197836
197837
197838
197839
197840
197841
197842
197843
197844
197845
197846
197847
197848
197849
197850
197851
197852
197853
197854
197855
197856
197857
197858
197859
197860
197861
197862
197863
197864
197865
197866
197867
197868
197869
197870
197871
197872
197873
197874
197875
197876
197877
197878
197879
197880
197881
197882
197883
197884
197885
197886
197887
197888
197889
197890
197891
197892
197893
197894
197895
197896
197897
197898
197899
197900
197901
197902
197903
197904
197905
197906
197907
197908
197909
197910
197911
197912
197913
197914
197915
197916
197917
197918
197919
197920
197921
197922
197923
197924
197925
197926
197927
197928
197929
197930
197931
197932
197933
197934
197935
197936
197937
197938
197939
197940
197941
197942
197943
197944
197945
197946
197947
197948
197949
197950
197951
197952
197953
197954
197955
197956
197957
197958
197959
197960
197961
197962
197963
197964
197965
197966
197967
197968
197969
197970
197971
197972
197973
197974
197975
197976
197977
197978
197979
197980
197981
197982
197983
197984
197985
197986
197987
197988
197989
197990
197991
197992
197993
197994
197995
197996
197997
197998
197999
198000
198001
198002
198003
198004
198005
198006
198007
198008
198009
198010
198011
198012
198013
198014
198015
198016
198017
198018
198019
198020
198021
198022
198023
198024
198025
198026
198027
198028
198029
198030
198031
198032
198033
198034
198035
198036
198037
198038
198039
198040
198041
198042
198043
198044
198045
198046
198047
198048
198049
198050
198051
198052
198053
198054
198055
198056
198057
198058
198059
198060
198061
198062
198063
198064
198065
198066
198067
198068
198069
198070
198071
198072
198073
198074
198075
198076
198077
198078
198079
198080
198081
198082
198083
198084
198085
198086
198087
198088
198089
198090
198091
198092
198093
198094
198095
198096
198097
198098
198099
198100
198101
198102
198103
198104
198105
198106
198107
198108
198109
198110
198111
198112
198113
198114
198115
198116
198117
198118
198119
198120
198121
198122
198123
198124
198125
198126
198127
198128
198129
198130
198131
198132
198133
198134
198135
198136
198137
198138
198139
198140
198141
198142
198143
198144
198145
198146
198147
198148
198149
198150
198151
198152
198153
198154
198155
198156
198157
198158
198159
198160
198161
198162
198163
198164
198165
198166
198167
198168
198169
198170
198171
198172
198173
198174
198175
198176
198177
198178
198179
198180
198181
198182
198183
198184
198185
198186
198187
198188
198189
198190
198191
198192
198193
198194
198195
198196
198197
198198
198199
198200
198201
198202
198203
198204
198205
198206
198207
198208
198209
198210
198211
198212
198213
198214
198215
198216
198217
198218
198219
198220
198221
198222
198223
198224
198225
198226
198227
198228
198229
198230
198231
198232
198233
198234
198235
198236
198237
198238
198239
198240
198241
198242
198243
198244
198245
198246
198247
198248
198249
198250
198251
198252
198253
198254
198255
198256
198257
198258
198259
198260
198261
198262
198263
198264
198265
198266
198267
198268
198269
198270
198271
198272
198273
198274
198275
198276
198277
198278
198279
198280
198281
198282
198283
198284
198285
198286
198287
198288
198289
198290
198291
198292
198293
198294
198295
198296
198297
198298
198299
198300
198301
198302
198303
198304
198305
198306
198307
198308
198309
198310
198311
198312
198313
198314
198315
198316
198317
198318
198319
198320
198321
198322
198323
198324
198325
198326
198327
198328
198329
198330
198331
198332
198333
198334
198335
198336
198337
198338
198339
198340
198341
198342
198343
198344
198345
198346
198347
198348
198349
198350
198351
198352
198353
198354
198355
198356
198357
198358
198359
198360
198361
198362
198363
198364
198365
198366
198367
198368
198369
198370
198371
198372
198373
198374
198375
198376
198377
198378
198379
198380
198381
198382
198383
198384
198385
198386
198387
198388
198389
198390
198391
198392
198393
198394
198395
198396
198397
198398
198399
198400
198401
198402
198403
198404
198405
198406
198407
198408
198409
198410
198411
198412
198413
198414
198415
198416
198417
198418
198419
198420
198421
198422
198423
198424
198425
198426
198427
198428
198429
198430
198431
198432
198433
198434
198435
198436
198437
198438
198439
198440
198441
198442
198443
198444
198445
198446
198447
198448
198449
198450
198451
198452
198453
198454
198455
198456
198457
198458
198459
198460
198461
198462
198463
198464
198465
198466
198467
198468
198469
198470
198471
198472
198473
198474
198475
198476
198477
198478
198479
198480
198481
198482
198483
198484
198485
198486
198487
198488
198489
198490
198491
198492
198493
198494
198495
198496
198497
198498
198499
198500
198501
198502
198503
198504
198505
198506
198507
198508
198509
198510
198511
198512
198513
198514
198515
198516
198517
198518
198519
198520
198521
198522
198523
198524
198525
198526
198527
198528
198529
198530
198531
198532
198533
198534
198535
198536
198537
198538
198539
198540
198541
198542
198543
198544
198545
198546
198547
198548
198549
198550
198551
198552
198553
198554
198555
198556
198557
198558
198559
198560
198561
198562
198563
198564
198565
198566
198567
198568
198569
198570
198571
198572
198573
198574
198575
198576
198577
198578
198579
198580
198581
198582
198583
198584
198585
198586
198587
198588
198589
198590
198591
198592
198593
198594
198595
198596
198597
198598
198599
198600
198601
198602
198603
198604
198605
198606
198607
198608
198609
198610
198611
198612
198613
198614
198615
198616
198617
198618
198619
198620
198621
198622
198623
198624
198625
198626
198627
198628
198629
198630
198631
198632
198633
198634
198635
198636
198637
198638
198639
198640
198641
198642
198643
198644
198645
198646
198647
198648
198649
198650
198651
198652
198653
198654
198655
198656
198657
198658
198659
198660
198661
198662
198663
198664
198665
198666
198667
198668
198669
198670
198671
198672
198673
198674
198675
198676
198677
198678
198679
198680
198681
198682
198683
198684
198685
198686
198687
198688
198689
198690
198691
198692
198693
198694
198695
198696
198697
198698
198699
198700
198701
198702
198703
198704
198705
198706
198707
198708
198709
198710
198711
198712
198713
198714
198715
198716
198717
198718
198719
198720
198721
198722
198723
198724
198725
198726
198727
198728
198729
198730
198731
198732
198733
198734
198735
198736
198737
198738
198739
198740
198741
198742
198743
198744
198745
198746
198747
198748
198749
198750
198751
198752
198753
198754
198755
198756
198757
198758
198759
198760
198761
198762
198763
198764
198765
198766
198767
198768
198769
198770
198771
198772
198773
198774
198775
198776
198777
198778
198779
198780
198781
198782
198783
198784
198785
198786
198787
198788
198789
198790
198791
198792
198793
198794
198795
198796
198797
198798
198799
198800
198801
198802
198803
198804
198805
198806
198807
198808
198809
198810
198811
198812
198813
198814
198815
198816
198817
198818
198819
198820
198821
198822
198823
198824
198825
198826
198827
198828
198829
198830
198831
198832
198833
198834
198835
198836
198837
198838
198839
198840
198841
198842
198843
198844
198845
198846
198847
198848
198849
198850
198851
198852
198853
198854
198855
198856
198857
198858
198859
198860
198861
198862
198863
198864
198865
198866
198867
198868
198869
198870
198871
198872
198873
198874
198875
198876
198877
198878
198879
198880
198881
198882
198883
198884
198885
198886
198887
198888
198889
198890
198891
198892
198893
198894
198895
198896
198897
198898
198899
198900
198901
198902
198903
198904
198905
198906
198907
198908
198909
198910
198911
198912
198913
198914
198915
198916
198917
198918
198919
198920
198921
198922
198923
198924
198925
198926
198927
198928
198929
198930
198931
198932
198933
198934
198935
198936
198937
198938
198939
198940
198941
198942
198943
198944
198945
198946
198947
198948
198949
198950
198951
198952
198953
198954
198955
198956
198957
198958
198959
198960
198961
198962
198963
198964
198965
198966
198967
198968
198969
198970
198971
198972
198973
198974
198975
198976
198977
198978
198979
198980
198981
198982
198983
198984
198985
198986
198987
198988
198989
198990
198991
198992
198993
198994
198995
198996
198997
198998
198999
199000
199001
199002
199003
199004
199005
199006
199007
199008
199009
199010
199011
199012
199013
199014
199015
199016
199017
199018
199019
199020
199021
199022
199023
199024
199025
199026
199027
199028
199029
199030
199031
199032
199033
199034
199035
199036
199037
199038
199039
199040
199041
199042
199043
199044
199045
199046
199047
199048
199049
199050
199051
199052
199053
199054
199055
199056
199057
199058
199059
199060
199061
199062
199063
199064
199065
199066
199067
199068
199069
199070
199071
199072
199073
199074
199075
199076
199077
199078
199079
199080
199081
199082
199083
199084
199085
199086
199087
199088
199089
199090
199091
199092
199093
199094
199095
199096
199097
199098
199099
199100
199101
199102
199103
199104
199105
199106
199107
199108
199109
199110
199111
199112
199113
199114
199115
199116
199117
199118
199119
199120
199121
199122
199123
199124
199125
199126
199127
199128
199129
199130
199131
199132
199133
199134
199135
199136
199137
199138
199139
199140
199141
199142
199143
199144
199145
199146
199147
199148
199149
199150
199151
199152
199153
199154
199155
199156
199157
199158
199159
199160
199161
199162
199163
199164
199165
199166
199167
199168
199169
199170
199171
199172
199173
199174
199175
199176
199177
199178
199179
199180
199181
199182
199183
199184
199185
199186
199187
199188
199189
199190
199191
199192
199193
199194
199195
199196
199197
199198
199199
199200
199201
199202
199203
199204
199205
199206
199207
199208
199209
199210
199211
199212
199213
199214
199215
199216
199217
199218
199219
199220
199221
199222
199223
199224
199225
199226
199227
199228
199229
199230
199231
199232
199233
199234
199235
199236
199237
199238
199239
199240
199241
199242
199243
199244
199245
199246
199247
199248
199249
199250
199251
199252
199253
199254
199255
199256
199257
199258
199259
199260
199261
199262
199263
199264
199265
199266
199267
199268
199269
199270
199271
199272
199273
199274
199275
199276
199277
199278
199279
199280
199281
199282
199283
199284
199285
199286
199287
199288
199289
199290
199291
199292
199293
199294
199295
199296
199297
199298
199299
199300
199301
199302
199303
199304
199305
199306
199307
199308
199309
199310
199311
199312
199313
199314
199315
199316
199317
199318
199319
199320
199321
199322
199323
199324
199325
199326
199327
199328
199329
199330
199331
199332
199333
199334
199335
199336
199337
199338
199339
199340
199341
199342
199343
199344
199345
199346
199347
199348
199349
199350
199351
199352
199353
199354
199355
199356
199357
199358
199359
199360
199361
199362
199363
199364
199365
199366
199367
199368
199369
199370
199371
199372
199373
199374
199375
199376
199377
199378
199379
199380
199381
199382
199383
199384
199385
199386
199387
199388
199389
199390
199391
199392
199393
199394
199395
199396
199397
199398
199399
199400
199401
199402
199403
199404
199405
199406
199407
199408
199409
199410
199411
199412
199413
199414
199415
199416
199417
199418
199419
199420
199421
199422
199423
199424
199425
199426
199427
199428
199429
199430
199431
199432
199433
199434
199435
199436
199437
199438
199439
199440
199441
199442
199443
199444
199445
199446
199447
199448
199449
199450
199451
199452
199453
199454
199455
199456
199457
199458
199459
199460
199461
199462
199463
199464
199465
199466
199467
199468
199469
199470
199471
199472
199473
199474
199475
199476
199477
199478
199479
199480
199481
199482
199483
199484
199485
199486
199487
199488
199489
199490
199491
199492
199493
199494
199495
199496
199497
199498
199499
199500
199501
199502
199503
199504
199505
199506
199507
199508
199509
199510
199511
199512
199513
199514
199515
199516
199517
199518
199519
199520
199521
199522
199523
199524
199525
199526
199527
199528
199529
199530
199531
199532
199533
199534
199535
199536
199537
199538
199539
199540
199541
199542
199543
199544
199545
199546
199547
199548
199549
199550
199551
199552
199553
199554
199555
199556
199557
199558
199559
199560
199561
199562
199563
199564
199565
199566
199567
199568
199569
199570
199571
199572
199573
199574
199575
199576
199577
199578
199579
199580
199581
199582
199583
199584
199585
199586
199587
199588
199589
199590
199591
199592
199593
199594
199595
199596
199597
199598
199599
199600
199601
199602
199603
199604
199605
199606
199607
199608
199609
199610
199611
199612
199613
199614
199615
199616
199617
199618
199619
199620
199621
199622
199623
199624
199625
199626
199627
199628
199629
199630
199631
199632
199633
199634
199635
199636
199637
199638
199639
199640
199641
199642
199643
199644
199645
199646
199647
199648
199649
199650
199651
199652
199653
199654
199655
199656
199657
199658
199659
199660
199661
199662
199663
199664
199665
199666
199667
199668
199669
199670
199671
199672
199673
199674
199675
199676
199677
199678
199679
199680
199681
199682
199683
199684
199685
199686
199687
199688
199689
199690
199691
199692
199693
199694
199695
199696
199697
199698
199699
199700
199701
199702
199703
199704
199705
199706
199707
199708
199709
199710
199711
199712
199713
199714
199715
199716
199717
199718
199719
199720
199721
199722
199723
199724
199725
199726
199727
199728
199729
199730
199731
199732
199733
199734
199735
199736
199737
199738
199739
199740
199741
199742
199743
199744
199745
199746
199747
199748
199749
199750
199751
199752
199753
199754
199755
199756
199757
199758
199759
199760
199761
199762
199763
199764
199765
199766
199767
199768
199769
199770
199771
199772
199773
199774
199775
199776
199777
199778
199779
199780
199781
199782
199783
199784
199785
199786
199787
199788
199789
199790
199791
199792
199793
199794
199795
199796
199797
199798
199799
199800
199801
199802
199803
199804
199805
199806
199807
199808
199809
199810
199811
199812
199813
199814
199815
199816
199817
199818
199819
199820
199821
199822
199823
199824
199825
199826
199827
199828
199829
199830
199831
199832
199833
199834
199835
199836
199837
199838
199839
199840
199841
199842
199843
199844
199845
199846
199847
199848
199849
199850
199851
199852
199853
199854
199855
199856
199857
199858
199859
199860
199861
199862
199863
199864
199865
199866
199867
199868
199869
199870
199871
199872
199873
199874
199875
199876
199877
199878
199879
199880
199881
199882
199883
199884
199885
199886
199887
199888
199889
199890
199891
199892
199893
199894
199895
199896
199897
199898
199899
199900
199901
199902
199903
199904
199905
199906
199907
199908
199909
199910
199911
199912
199913
199914
199915
199916
199917
199918
199919
199920
199921
199922
199923
199924
199925
199926
199927
199928
199929
199930
199931
199932
199933
199934
199935
199936
199937
199938
199939
199940
199941
199942
199943
199944
199945
199946
199947
199948
199949
199950
199951
199952
199953
199954
199955
199956
199957
199958
199959
199960
199961
199962
199963
199964
199965
199966
199967
199968
199969
199970
199971
199972
199973
199974
199975
199976
199977
199978
199979
199980
199981
199982
199983
199984
199985
199986
199987
199988
199989
199990
199991
199992
199993
199994
199995
199996
199997
199998
199999
200000
200001
200002
200003
200004
200005
200006
200007
200008
200009
200010
200011
200012
200013
200014
200015
200016
200017
200018
200019
200020
200021
200022
200023
200024
200025
200026
200027
200028
200029
200030
200031
200032
200033
200034
200035
200036
200037
200038
200039
200040
200041
200042
200043
200044
200045
200046
200047
200048
200049
200050
200051
200052
200053
200054
200055
200056
200057
200058
200059
200060
200061
200062
200063
200064
200065
200066
200067
200068
200069
200070
200071
200072
200073
200074
200075
200076
200077
200078
200079
200080
200081
200082
200083
200084
200085
200086
200087
200088
200089
200090
200091
200092
200093
200094
200095
200096
200097
200098
200099
200100
200101
200102
200103
200104
200105
200106
200107
200108
200109
200110
200111
200112
200113
200114
200115
200116
200117
200118
200119
200120
200121
200122
200123
200124
200125
200126
200127
200128
200129
200130
200131
200132
200133
200134
200135
200136
200137
200138
200139
200140
200141
200142
200143
200144
200145
200146
200147
200148
200149
200150
200151
200152
200153
200154
200155
200156
200157
200158
200159
200160
200161
200162
200163
200164
200165
200166
200167
200168
200169
200170
200171
200172
200173
200174
200175
200176
200177
200178
200179
200180
200181
200182
200183
200184
200185
200186
200187
200188
200189
200190
200191
200192
200193
200194
200195
200196
200197
200198
200199
200200
200201
200202
200203
200204
200205
200206
200207
200208
200209
200210
200211
200212
200213
200214
200215
200216
200217
200218
200219
200220
200221
200222
200223
200224
200225
200226
200227
200228
200229
200230
200231
200232
200233
200234
200235
200236
200237
200238
200239
200240
200241
200242
200243
200244
200245
200246
200247
200248
200249
200250
200251
200252
200253
200254
200255
200256
200257
200258
200259
200260
200261
200262
200263
200264
200265
200266
200267
200268
200269
200270
200271
200272
200273
200274
200275
200276
200277
200278
200279
200280
200281
200282
200283
200284
200285
200286
200287
200288
200289
200290
200291
200292
200293
200294
200295
200296
200297
200298
200299
200300
200301
200302
200303
200304
200305
200306
200307
200308
200309
200310
200311
200312
200313
200314
200315
200316
200317
200318
200319
200320
200321
200322
200323
200324
200325
200326
200327
200328
200329
200330
200331
200332
200333
200334
200335
200336
200337
200338
200339
200340
200341
200342
200343
200344
200345
200346
200347
200348
200349
200350
200351
200352
200353
200354
200355
200356
200357
200358
200359
200360
200361
200362
200363
200364
200365
200366
200367
200368
200369
200370
200371
200372
200373
200374
200375
200376
200377
200378
200379
200380
200381
200382
200383
200384
200385
200386
200387
200388
200389
200390
200391
200392
200393
200394
200395
200396
200397
200398
200399
200400
200401
200402
200403
200404
200405
200406
200407
200408
200409
200410
200411
200412
200413
200414
200415
200416
200417
200418
200419
200420
200421
200422
200423
200424
200425
200426
200427
200428
200429
200430
200431
200432
200433
200434
200435
200436
200437
200438
200439
200440
200441
200442
200443
200444
200445
200446
200447
200448
200449
200450
200451
200452
200453
200454
200455
200456
200457
200458
200459
200460
200461
200462
200463
200464
200465
200466
200467
200468
200469
200470
200471
200472
200473
200474
200475
200476
200477
200478
200479
200480
200481
200482
200483
200484
200485
200486
200487
200488
200489
200490
200491
200492
200493
200494
200495
200496
200497
200498
200499
200500
200501
200502
200503
200504
200505
200506
200507
200508
200509
200510
200511
200512
200513
200514
200515
200516
200517
200518
200519
200520
200521
200522
200523
200524
200525
200526
200527
200528
200529
200530
200531
200532
200533
200534
200535
200536
200537
200538
200539
200540
200541
200542
200543
200544
200545
200546
200547
200548
200549
200550
200551
200552
200553
200554
200555
200556
200557
200558
200559
200560
200561
200562
200563
200564
200565
200566
200567
200568
200569
200570
200571
200572
200573
200574
200575
200576
200577
200578
200579
200580
200581
200582
200583
200584
200585
200586
200587
200588
200589
200590
200591
200592
200593
200594
200595
200596
200597
200598
200599
200600
200601
200602
200603
200604
200605
200606
200607
200608
200609
200610
200611
200612
200613
200614
200615
200616
200617
200618
200619
200620
200621
200622
200623
200624
200625
200626
200627
200628
200629
200630
200631
200632
200633
200634
200635
200636
200637
200638
200639
200640
200641
200642
200643
200644
200645
200646
200647
200648
200649
200650
200651
200652
200653
200654
200655
200656
200657
200658
200659
200660
200661
200662
200663
200664
200665
200666
200667
200668
200669
200670
200671
200672
200673
200674
200675
200676
200677
200678
200679
200680
200681
200682
200683
200684
200685
200686
200687
200688
200689
200690
200691
200692
200693
200694
200695
200696
200697
200698
200699
200700
200701
200702
200703
200704
200705
200706
200707
200708
200709
200710
200711
200712
200713
200714
200715
200716
200717
200718
200719
200720
200721
200722
200723
200724
200725
200726
200727
200728
200729
200730
200731
200732
200733
200734
200735
200736
200737
200738
200739
200740
200741
200742
200743
200744
200745
200746
200747
200748
200749
200750
200751
200752
200753
200754
200755
200756
200757
200758
200759
200760
200761
200762
200763
200764
200765
200766
200767
200768
200769
200770
200771
200772
200773
200774
200775
200776
200777
200778
200779
200780
200781
200782
200783
200784
200785
200786
200787
200788
200789
200790
200791
200792
200793
200794
200795
200796
200797
200798
200799
200800
200801
200802
200803
200804
200805
200806
200807
200808
200809
200810
200811
200812
200813
200814
200815
200816
200817
200818
200819
200820
200821
200822
200823
200824
200825
200826
200827
200828
200829
200830
200831
200832
200833
200834
200835
200836
200837
200838
200839
200840
200841
200842
200843
200844
200845
200846
200847
200848
200849
200850
200851
200852
200853
200854
200855
200856
200857
200858
200859
200860
200861
200862
200863
200864
200865
200866
200867
200868
200869
200870
200871
200872
200873
200874
200875
200876
200877
200878
200879
200880
200881
200882
200883
200884
200885
200886
200887
200888
200889
200890
200891
200892
200893
200894
200895
200896
200897
200898
200899
200900
200901
200902
200903
200904
200905
200906
200907
200908
200909
200910
200911
200912
200913
200914
200915
200916
200917
200918
200919
200920
200921
200922
200923
200924
200925
200926
200927
200928
200929
200930
200931
200932
200933
200934
200935
200936
200937
200938
200939
200940
200941
200942
200943
200944
200945
200946
200947
200948
200949
200950
200951
200952
200953
200954
200955
200956
200957
200958
200959
200960
200961
200962
200963
200964
200965
200966
200967
200968
200969
200970
200971
200972
200973
200974
200975
200976
200977
200978
200979
200980
200981
200982
200983
200984
200985
200986
200987
200988
200989
200990
200991
200992
200993
200994
200995
200996
200997
200998
200999
201000
201001
201002
201003
201004
201005
201006
201007
201008
201009
201010
201011
201012
201013
201014
201015
201016
201017
201018
201019
201020
201021
201022
201023
201024
201025
201026
201027
201028
201029
201030
201031
201032
201033
201034
201035
201036
201037
201038
201039
201040
201041
201042
201043
201044
201045
201046
201047
201048
201049
201050
201051
201052
201053
201054
201055
201056
201057
201058
201059
201060
201061
201062
201063
201064
201065
201066
201067
201068
201069
201070
201071
201072
201073
201074
201075
201076
201077
201078
201079
201080
201081
201082
201083
201084
201085
201086
201087
201088
201089
201090
201091
201092
201093
201094
201095
201096
201097
201098
201099
201100
201101
201102
201103
201104
201105
201106
201107
201108
201109
201110
201111
201112
201113
201114
201115
201116
201117
201118
201119
201120
201121
201122
201123
201124
201125
201126
201127
201128
201129
201130
201131
201132
201133
201134
201135
201136
201137
201138
201139
201140
201141
201142
201143
201144
201145
201146
201147
201148
201149
201150
201151
201152
201153
201154
201155
201156
201157
201158
201159
201160
201161
201162
201163
201164
201165
201166
201167
201168
201169
201170
201171
201172
201173
201174
201175
201176
201177
201178
201179
201180
201181
201182
201183
201184
201185
201186
201187
201188
201189
201190
201191
201192
201193
201194
201195
201196
201197
201198
201199
201200
201201
201202
201203
201204
201205
201206
201207
201208
201209
201210
201211
201212
201213
201214
201215
201216
201217
201218
201219
201220
201221
201222
201223
201224
201225
201226
201227
201228
201229
201230
201231
201232
201233
201234
201235
201236
201237
201238
201239
201240
201241
201242
201243
201244
201245
201246
201247
201248
201249
201250
201251
201252
201253
201254
201255
201256
201257
201258
201259
201260
201261
201262
201263
201264
201265
201266
201267
201268
201269
201270
201271
201272
201273
201274
201275
201276
201277
201278
201279
201280
201281
201282
201283
201284
201285
201286
201287
201288
201289
201290
201291
201292
201293
201294
201295
201296
201297
201298
201299
201300
201301
201302
201303
201304
201305
201306
201307
201308
201309
201310
201311
201312
201313
201314
201315
201316
201317
201318
201319
201320
201321
201322
201323
201324
201325
201326
201327
201328
201329
201330
201331
201332
201333
201334
201335
201336
201337
201338
201339
201340
201341
201342
201343
201344
201345
201346
201347
201348
201349
201350
201351
201352
201353
201354
201355
201356
201357
201358
201359
201360
201361
201362
201363
201364
201365
201366
201367
201368
201369
201370
201371
201372
201373
201374
201375
201376
201377
201378
201379
201380
201381
201382
201383
201384
201385
201386
201387
201388
201389
201390
201391
201392
201393
201394
201395
201396
201397
201398
201399
201400
201401
201402
201403
201404
201405
201406
201407
201408
201409
201410
201411
201412
201413
201414
201415
201416
201417
201418
201419
201420
201421
201422
201423
201424
201425
201426
201427
201428
201429
201430
201431
201432
201433
201434
201435
201436
201437
201438
201439
201440
201441
201442
201443
201444
201445
201446
201447
201448
201449
201450
201451
201452
201453
201454
201455
201456
201457
201458
201459
201460
201461
201462
201463
201464
201465
201466
201467
201468
201469
201470
201471
201472
201473
201474
201475
201476
201477
201478
201479
201480
201481
201482
201483
201484
201485
201486
201487
201488
201489
201490
201491
201492
201493
201494
201495
201496
201497
201498
201499
201500
201501
201502
201503
201504
201505
201506
201507
201508
201509
201510
201511
201512
201513
201514
201515
201516
201517
201518
201519
201520
201521
201522
201523
201524
201525
201526
201527
201528
201529
201530
201531
201532
201533
201534
201535
201536
201537
201538
201539
201540
201541
201542
201543
201544
201545
201546
201547
201548
201549
201550
201551
201552
201553
201554
201555
201556
201557
201558
201559
201560
201561
201562
201563
201564
201565
201566
201567
201568
201569
201570
201571
201572
201573
201574
201575
201576
201577
201578
201579
201580
201581
201582
201583
201584
201585
201586
201587
201588
201589
201590
201591
201592
201593
201594
201595
201596
201597
201598
201599
201600
201601
201602
201603
201604
201605
201606
201607
201608
201609
201610
201611
201612
201613
201614
201615
201616
201617
201618
201619
201620
201621
201622
201623
201624
201625
201626
201627
201628
201629
201630
201631
201632
201633
201634
201635
201636
201637
201638
201639
201640
201641
201642
201643
201644
201645
201646
201647
201648
201649
201650
201651
201652
201653
201654
201655
201656
201657
201658
201659
201660
201661
201662
201663
201664
201665
201666
201667
201668
201669
201670
201671
201672
201673
201674
201675
201676
201677
201678
201679
201680
201681
201682
201683
201684
201685
201686
201687
201688
201689
201690
201691
201692
201693
201694
201695
201696
201697
201698
201699
201700
201701
201702
201703
201704
201705
201706
201707
201708
201709
201710
201711
201712
201713
201714
201715
201716
201717
201718
201719
201720
201721
201722
201723
201724
201725
201726
201727
201728
201729
201730
201731
201732
201733
201734
201735
201736
201737
201738
201739
201740
201741
201742
201743
201744
201745
201746
201747
201748
201749
201750
201751
201752
201753
201754
201755
201756
201757
201758
201759
201760
201761
201762
201763
201764
201765
201766
201767
201768
201769
201770
201771
201772
201773
201774
201775
201776
201777
201778
201779
201780
201781
201782
201783
201784
201785
201786
201787
201788
201789
201790
201791
201792
201793
201794
201795
201796
201797
201798
201799
201800
201801
201802
201803
201804
201805
201806
201807
201808
201809
201810
201811
201812
201813
201814
201815
201816
201817
201818
201819
201820
201821
201822
201823
201824
201825
201826
201827
201828
201829
201830
201831
201832
201833
201834
201835
201836
201837
201838
201839
201840
201841
201842
201843
201844
201845
201846
201847
201848
201849
201850
201851
201852
201853
201854
201855
201856
201857
201858
201859
201860
201861
201862
201863
201864
201865
201866
201867
201868
201869
201870
201871
201872
201873
201874
201875
201876
201877
201878
201879
201880
201881
201882
201883
201884
201885
201886
201887
201888
201889
201890
201891
201892
201893
201894
201895
201896
201897
201898
201899
201900
201901
201902
201903
201904
201905
201906
201907
201908
201909
201910
201911
201912
201913
201914
201915
201916
201917
201918
201919
201920
201921
201922
201923
201924
201925
201926
201927
201928
201929
201930
201931
201932
201933
201934
201935
201936
201937
201938
201939
201940
201941
201942
201943
201944
201945
201946
201947
201948
201949
201950
201951
201952
201953
201954
201955
201956
201957
201958
201959
201960
201961
201962
201963
201964
201965
201966
201967
201968
201969
201970
201971
201972
201973
201974
201975
201976
201977
201978
201979
201980
201981
201982
201983
201984
201985
201986
201987
201988
201989
201990
201991
201992
201993
201994
201995
201996
201997
201998
201999
202000
202001
202002
202003
202004
202005
202006
202007
202008
202009
202010
202011
202012
202013
202014
202015
202016
202017
202018
202019
202020
202021
202022
202023
202024
202025
202026
202027
202028
202029
202030
202031
202032
202033
202034
202035
202036
202037
202038
202039
202040
202041
202042
202043
202044
202045
202046
202047
202048
202049
202050
202051
202052
202053
202054
202055
202056
202057
202058
202059
202060
202061
202062
202063
202064
202065
202066
202067
202068
202069
202070
202071
202072
202073
202074
202075
202076
202077
202078
202079
202080
202081
202082
202083
202084
202085
202086
202087
202088
202089
202090
202091
202092
202093
202094
202095
202096
202097
202098
202099
202100
202101
202102
202103
202104
202105
202106
202107
202108
202109
202110
202111
202112
202113
202114
202115
202116
202117
202118
202119
202120
202121
202122
202123
202124
202125
202126
202127
202128
202129
202130
202131
202132
202133
202134
202135
202136
202137
202138
202139
202140
202141
202142
202143
202144
202145
202146
202147
202148
202149
202150
202151
202152
202153
202154
202155
202156
202157
202158
202159
202160
202161
202162
202163
202164
202165
202166
202167
202168
202169
202170
202171
202172
202173
202174
202175
202176
202177
202178
202179
202180
202181
202182
202183
202184
202185
202186
202187
202188
202189
202190
202191
202192
202193
202194
202195
202196
202197
202198
202199
202200
202201
202202
202203
202204
202205
202206
202207
202208
202209
202210
202211
202212
202213
202214
202215
202216
202217
202218
202219
202220
202221
202222
202223
202224
202225
202226
202227
202228
202229
202230
202231
202232
202233
202234
202235
202236
202237
202238
202239
202240
202241
202242
202243
202244
202245
202246
202247
202248
202249
202250
202251
202252
202253
202254
202255
202256
202257
202258
202259
202260
202261
202262
202263
202264
202265
202266
202267
202268
202269
202270
202271
202272
202273
202274
202275
202276
202277
202278
202279
202280
202281
202282
202283
202284
202285
202286
202287
202288
202289
202290
202291
202292
202293
202294
202295
202296
202297
202298
202299
202300
202301
202302
202303
202304
202305
202306
202307
202308
202309
202310
202311
202312
202313
202314
202315
202316
202317
202318
202319
202320
202321
202322
202323
202324
202325
202326
202327
202328
202329
202330
202331
202332
202333
202334
202335
202336
202337
202338
202339
202340
202341
202342
202343
202344
202345
202346
202347
202348
202349
202350
202351
202352
202353
202354
202355
202356
202357
202358
202359
202360
202361
202362
202363
202364
202365
202366
202367
202368
202369
202370
202371
202372
202373
202374
202375
202376
202377
202378
202379
202380
202381
202382
202383
202384
202385
202386
202387
202388
202389
202390
202391
202392
202393
202394
202395
202396
202397
202398
202399
202400
202401
202402
202403
202404
202405
202406
202407
202408
202409
202410
202411
202412
202413
202414
202415
202416
202417
202418
202419
202420
202421
202422
202423
202424
202425
202426
202427
202428
202429
202430
202431
202432
202433
202434
202435
202436
202437
202438
202439
202440
202441
202442
202443
202444
202445
202446
202447
202448
202449
202450
202451
202452
202453
202454
202455
202456
202457
202458
202459
202460
202461
202462
202463
202464
202465
202466
202467
202468
202469
202470
202471
202472
202473
202474
202475
202476
202477
202478
202479
202480
202481
202482
202483
202484
202485
202486
202487
202488
202489
202490
202491
202492
202493
202494
202495
202496
202497
202498
202499
202500
202501
202502
202503
202504
202505
202506
202507
202508
202509
202510
202511
202512
202513
202514
202515
202516
202517
202518
202519
202520
202521
202522
202523
202524
202525
202526
202527
202528
202529
202530
202531
202532
202533
202534
202535
202536
202537
202538
202539
202540
202541
202542
202543
202544
202545
202546
202547
202548
202549
202550
202551
202552
202553
202554
202555
202556
202557
202558
202559
202560
202561
202562
202563
202564
202565
202566
202567
202568
202569
202570
202571
202572
202573
202574
202575
202576
202577
202578
202579
202580
202581
202582
202583
202584
202585
202586
202587
202588
202589
202590
202591
202592
202593
202594
202595
202596
202597
202598
202599
202600
202601
202602
202603
202604
202605
202606
202607
202608
202609
202610
202611
202612
202613
202614
202615
202616
202617
202618
202619
202620
202621
202622
202623
202624
202625
202626
202627
202628
202629
202630
202631
202632
202633
202634
202635
202636
202637
202638
202639
202640
202641
202642
202643
202644
202645
202646
202647
202648
202649
202650
202651
202652
202653
202654
202655
202656
202657
202658
202659
202660
202661
202662
202663
202664
202665
202666
202667
202668
202669
202670
202671
202672
202673
202674
202675
202676
202677
202678
202679
202680
202681
202682
202683
202684
202685
202686
202687
202688
202689
202690
202691
202692
202693
202694
202695
202696
202697
202698
202699
202700
202701
202702
202703
202704
202705
202706
202707
202708
202709
202710
202711
202712
202713
202714
202715
202716
202717
202718
202719
202720
202721
202722
202723
202724
202725
202726
202727
202728
202729
202730
202731
202732
202733
202734
202735
202736
202737
202738
202739
202740
202741
202742
202743
202744
202745
202746
202747
202748
202749
202750
202751
202752
202753
202754
202755
202756
202757
202758
202759
202760
202761
202762
202763
202764
202765
202766
202767
202768
202769
202770
202771
202772
202773
202774
202775
202776
202777
202778
202779
202780
202781
202782
202783
202784
202785
202786
202787
202788
202789
202790
202791
202792
202793
202794
202795
202796
202797
202798
202799
202800
202801
202802
202803
202804
202805
202806
202807
202808
202809
202810
202811
202812
202813
202814
202815
202816
202817
202818
202819
202820
202821
202822
202823
202824
202825
202826
202827
202828
202829
202830
202831
202832
202833
202834
202835
202836
202837
202838
202839
202840
202841
202842
202843
202844
202845
202846
202847
202848
202849
202850
202851
202852
202853
202854
202855
202856
202857
202858
202859
202860
202861
202862
202863
202864
202865
202866
202867
202868
202869
202870
202871
202872
202873
202874
202875
202876
202877
202878
202879
202880
202881
202882
202883
202884
202885
202886
202887
202888
202889
202890
202891
202892
202893
202894
202895
202896
202897
202898
202899
202900
202901
202902
202903
202904
202905
202906
202907
202908
202909
202910
202911
202912
202913
202914
202915
202916
202917
202918
202919
202920
202921
202922
202923
202924
202925
202926
202927
202928
202929
202930
202931
202932
202933
202934
202935
202936
202937
202938
202939
202940
202941
202942
202943
202944
202945
202946
202947
202948
202949
202950
202951
202952
202953
202954
202955
202956
202957
202958
202959
202960
202961
202962
202963
202964
202965
202966
202967
202968
202969
202970
202971
202972
202973
202974
202975
202976
202977
202978
202979
202980
202981
202982
202983
202984
202985
202986
202987
202988
202989
202990
202991
202992
202993
202994
202995
202996
202997
202998
202999
203000
203001
203002
203003
203004
203005
203006
203007
203008
203009
203010
203011
203012
203013
203014
203015
203016
203017
203018
203019
203020
203021
203022
203023
203024
203025
203026
203027
203028
203029
203030
203031
203032
203033
203034
203035
203036
203037
203038
203039
203040
203041
203042
203043
203044
203045
203046
203047
203048
203049
203050
203051
203052
203053
203054
203055
203056
203057
203058
203059
203060
203061
203062
203063
203064
203065
203066
203067
203068
203069
203070
203071
203072
203073
203074
203075
203076
203077
203078
203079
203080
203081
203082
203083
203084
203085
203086
203087
203088
203089
203090
203091
203092
203093
203094
203095
203096
203097
203098
203099
203100
203101
203102
203103
203104
203105
203106
203107
203108
203109
203110
203111
203112
203113
203114
203115
203116
203117
203118
203119
203120
203121
203122
203123
203124
203125
203126
203127
203128
203129
203130
203131
203132
203133
203134
203135
203136
203137
203138
203139
203140
203141
203142
203143
203144
203145
203146
203147
203148
203149
203150
203151
203152
203153
203154
203155
203156
203157
203158
203159
203160
203161
203162
203163
203164
203165
203166
203167
203168
203169
203170
203171
203172
203173
203174
203175
203176
203177
203178
203179
203180
203181
203182
203183
203184
203185
203186
203187
203188
203189
203190
203191
203192
203193
203194
203195
203196
203197
203198
203199
203200
203201
203202
203203
203204
203205
203206
203207
203208
203209
203210
203211
203212
203213
203214
203215
203216
203217
203218
203219
203220
203221
203222
203223
203224
203225
203226
203227
203228
203229
203230
203231
203232
203233
203234
203235
203236
203237
203238
203239
203240
203241
203242
203243
203244
203245
203246
203247
203248
203249
203250
203251
203252
203253
203254
203255
203256
203257
203258
203259
203260
203261
203262
203263
203264
203265
203266
203267
203268
203269
203270
203271
203272
203273
203274
203275
203276
203277
203278
203279
203280
203281
203282
203283
203284
203285
203286
203287
203288
203289
203290
203291
203292
203293
203294
203295
203296
203297
203298
203299
203300
203301
203302
203303
203304
203305
203306
203307
203308
203309
203310
203311
203312
203313
203314
203315
203316
203317
203318
203319
203320
203321
203322
203323
203324
203325
203326
203327
203328
203329
203330
203331
203332
203333
203334
203335
203336
203337
203338
203339
203340
203341
203342
203343
203344
203345
203346
203347
203348
203349
203350
203351
203352
203353
203354
203355
203356
203357
203358
203359
203360
203361
203362
203363
203364
203365
203366
203367
203368
203369
203370
203371
203372
203373
203374
203375
203376
203377
203378
203379
203380
203381
203382
203383
203384
203385
203386
203387
203388
203389
203390
203391
203392
203393
203394
203395
203396
203397
203398
203399
203400
203401
203402
203403
203404
203405
203406
203407
203408
203409
203410
203411
203412
203413
203414
203415
203416
203417
203418
203419
203420
203421
203422
203423
203424
203425
203426
203427
203428
203429
203430
203431
203432
203433
203434
203435
203436
203437
203438
203439
203440
203441
203442
203443
203444
203445
203446
203447
203448
203449
203450
203451
203452
203453
203454
203455
203456
203457
203458
203459
203460
203461
203462
203463
203464
203465
203466
203467
203468
203469
203470
203471
203472
203473
203474
203475
203476
203477
203478
203479
203480
203481
203482
203483
203484
203485
203486
203487
203488
203489
203490
203491
203492
203493
203494
203495
203496
203497
203498
203499
203500
203501
203502
203503
203504
203505
203506
203507
203508
203509
203510
203511
203512
203513
203514
203515
203516
203517
203518
203519
203520
203521
203522
203523
203524
203525
203526
203527
203528
203529
203530
203531
203532
203533
203534
203535
203536
203537
203538
203539
203540
203541
203542
203543
203544
203545
203546
203547
203548
203549
203550
203551
203552
203553
203554
203555
203556
203557
203558
203559
203560
203561
203562
203563
203564
203565
203566
203567
203568
203569
203570
203571
203572
203573
203574
203575
203576
203577
203578
203579
203580
203581
203582
203583
203584
203585
203586
203587
203588
203589
203590
203591
203592
203593
203594
203595
203596
203597
203598
203599
203600
203601
203602
203603
203604
203605
203606
203607
203608
203609
203610
203611
203612
203613
203614
203615
203616
203617
203618
203619
203620
203621
203622
203623
203624
203625
203626
203627
203628
203629
203630
203631
203632
203633
203634
203635
203636
203637
203638
203639
203640
203641
203642
203643
203644
203645
203646
203647
203648
203649
203650
203651
203652
203653
203654
203655
203656
203657
203658
203659
203660
203661
203662
203663
203664
203665
203666
203667
203668
203669
203670
203671
203672
203673
203674
203675
203676
203677
203678
203679
203680
203681
203682
203683
203684
203685
203686
203687
203688
203689
203690
203691
203692
203693
203694
203695
203696
203697
203698
203699
203700
203701
203702
203703
203704
203705
203706
203707
203708
203709
203710
203711
203712
203713
203714
203715
203716
203717
203718
203719
203720
203721
203722
203723
203724
203725
203726
203727
203728
203729
203730
203731
203732
203733
203734
203735
203736
203737
203738
203739
203740
203741
203742
203743
203744
203745
203746
203747
203748
203749
203750
203751
203752
203753
203754
203755
203756
203757
203758
203759
203760
203761
203762
203763
203764
203765
203766
203767
203768
203769
203770
203771
203772
203773
203774
203775
203776
203777
203778
203779
203780
203781
203782
203783
203784
203785
203786
203787
203788
203789
203790
203791
203792
203793
203794
203795
203796
203797
203798
203799
203800
203801
203802
203803
203804
203805
203806
203807
203808
203809
203810
203811
203812
203813
203814
203815
203816
203817
203818
203819
203820
203821
203822
203823
203824
203825
203826
203827
203828
203829
203830
203831
203832
203833
203834
203835
203836
203837
203838
203839
203840
203841
203842
203843
203844
203845
203846
203847
203848
203849
203850
203851
203852
203853
203854
203855
203856
203857
203858
203859
203860
203861
203862
203863
203864
203865
203866
203867
203868
203869
203870
203871
203872
203873
203874
203875
203876
203877
203878
203879
203880
203881
203882
203883
203884
203885
203886
203887
203888
203889
203890
203891
203892
203893
203894
203895
203896
203897
203898
203899
203900
203901
203902
203903
203904
203905
203906
203907
203908
203909
203910
203911
203912
203913
203914
203915
203916
203917
203918
203919
203920
203921
203922
203923
203924
203925
203926
203927
203928
203929
203930
203931
203932
203933
203934
203935
203936
203937
203938
203939
203940
203941
203942
203943
203944
203945
203946
203947
203948
203949
203950
203951
203952
203953
203954
203955
203956
203957
203958
203959
203960
203961
203962
203963
203964
203965
203966
203967
203968
203969
203970
203971
203972
203973
203974
203975
203976
203977
203978
203979
203980
203981
203982
203983
203984
203985
203986
203987
203988
203989
203990
203991
203992
203993
203994
203995
203996
203997
203998
203999
204000
204001
204002
204003
204004
204005
204006
204007
204008
204009
204010
204011
204012
204013
204014
204015
204016
204017
204018
204019
204020
204021
204022
204023
204024
204025
204026
204027
204028
204029
204030
204031
204032
204033
204034
204035
204036
204037
204038
204039
204040
204041
204042
204043
204044
204045
204046
204047
204048
204049
204050
204051
204052
204053
204054
204055
204056
204057
204058
204059
204060
204061
204062
204063
204064
204065
204066
204067
204068
204069
204070
204071
204072
204073
204074
204075
204076
204077
204078
204079
204080
204081
204082
204083
204084
204085
204086
204087
204088
204089
204090
204091
204092
204093
204094
204095
204096
204097
204098
204099
204100
204101
204102
204103
204104
204105
204106
204107
204108
204109
204110
204111
204112
204113
204114
204115
204116
204117
204118
204119
204120
204121
204122
204123
204124
204125
204126
204127
204128
204129
204130
204131
204132
204133
204134
204135
204136
204137
204138
204139
204140
204141
204142
204143
204144
204145
204146
204147
204148
204149
204150
204151
204152
204153
204154
204155
204156
204157
204158
204159
204160
204161
204162
204163
204164
204165
204166
204167
204168
204169
204170
204171
204172
204173
204174
204175
204176
204177
204178
204179
204180
204181
204182
204183
204184
204185
204186
204187
204188
204189
204190
204191
204192
204193
204194
204195
204196
204197
204198
204199
204200
204201
204202
204203
204204
204205
204206
204207
204208
204209
204210
204211
204212
204213
204214
204215
204216
204217
204218
204219
204220
204221
204222
204223
204224
204225
204226
204227
204228
204229
204230
204231
204232
204233
204234
204235
204236
204237
204238
204239
204240
204241
204242
204243
204244
204245
204246
204247
204248
204249
204250
204251
204252
204253
204254
204255
204256
204257
204258
204259
204260
204261
204262
204263
204264
204265
204266
204267
204268
204269
204270
204271
204272
204273
204274
204275
204276
204277
204278
204279
204280
204281
204282
204283
204284
204285
204286
204287
204288
204289
204290
204291
204292
204293
204294
204295
204296
204297
204298
204299
204300
204301
204302
204303
204304
204305
204306
204307
204308
204309
204310
204311
204312
204313
204314
204315
204316
204317
204318
204319
204320
204321
204322
204323
204324
204325
204326
204327
204328
204329
204330
204331
204332
204333
204334
204335
204336
204337
204338
204339
204340
204341
204342
204343
204344
204345
204346
204347
204348
204349
204350
204351
204352
204353
204354
204355
204356
204357
204358
204359
204360
204361
204362
204363
204364
204365
204366
204367
204368
204369
204370
204371
204372
204373
204374
204375
204376
204377
204378
204379
204380
204381
204382
204383
204384
204385
204386
204387
204388
204389
204390
204391
204392
204393
204394
204395
204396
204397
204398
204399
204400
204401
204402
204403
204404
204405
204406
204407
204408
204409
204410
204411
204412
204413
204414
204415
204416
204417
204418
204419
204420
204421
204422
204423
204424
204425
204426
204427
204428
204429
204430
204431
204432
204433
204434
204435
204436
204437
204438
204439
204440
204441
204442
204443
204444
204445
204446
204447
204448
204449
204450
204451
204452
204453
204454
204455
204456
204457
204458
204459
204460
204461
204462
204463
204464
204465
204466
204467
204468
204469
204470
204471
204472
204473
204474
204475
204476
204477
204478
204479
204480
204481
204482
204483
204484
204485
204486
204487
204488
204489
204490
204491
204492
204493
204494
204495
204496
204497
204498
204499
204500
204501
204502
204503
204504
204505
204506
204507
204508
204509
204510
204511
204512
204513
204514
204515
204516
204517
204518
204519
204520
204521
204522
204523
204524
204525
204526
204527
204528
204529
204530
204531
204532
204533
204534
204535
204536
204537
204538
204539
204540
204541
204542
204543
204544
204545
204546
204547
204548
204549
204550
204551
204552
204553
204554
204555
204556
204557
204558
204559
204560
204561
204562
204563
204564
204565
204566
204567
204568
204569
204570
204571
204572
204573
204574
204575
204576
204577
204578
204579
204580
204581
204582
204583
204584
204585
204586
204587
204588
204589
204590
204591
204592
204593
204594
204595
204596
204597
204598
204599
204600
204601
204602
204603
204604
204605
204606
204607
204608
204609
204610
204611
204612
204613
204614
204615
204616
204617
204618
204619
204620
204621
204622
204623
204624
204625
204626
204627
204628
204629
204630
204631
204632
204633
204634
204635
204636
204637
204638
204639
204640
204641
204642
204643
204644
204645
204646
204647
204648
204649
204650
204651
204652
204653
204654
204655
204656
204657
204658
204659
204660
204661
204662
204663
204664
204665
204666
204667
204668
204669
204670
204671
204672
204673
204674
204675
204676
204677
204678
204679
204680
204681
204682
204683
204684
204685
204686
204687
204688
204689
204690
204691
204692
204693
204694
204695
204696
204697
204698
204699
204700
204701
204702
204703
204704
204705
204706
204707
204708
204709
204710
204711
204712
204713
204714
204715
204716
204717
204718
204719
204720
204721
204722
204723
204724
204725
204726
204727
204728
204729
204730
204731
204732
204733
204734
204735
204736
204737
204738
204739
204740
204741
204742
204743
204744
204745
204746
204747
204748
204749
204750
204751
204752
204753
204754
204755
204756
204757
204758
204759
204760
204761
204762
204763
204764
204765
204766
204767
204768
204769
204770
204771
204772
204773
204774
204775
204776
204777
204778
204779
204780
204781
204782
204783
204784
204785
204786
204787
204788
204789
204790
204791
204792
204793
204794
204795
204796
204797
204798
204799
204800
204801
204802
204803
204804
204805
204806
204807
204808
204809
204810
204811
204812
204813
204814
204815
204816
204817
204818
204819
204820
204821
204822
204823
204824
204825
204826
204827
204828
204829
204830
204831
204832
204833
204834
204835
204836
204837
204838
204839
204840
204841
204842
204843
204844
204845
204846
204847
204848
204849
204850
204851
204852
204853
204854
204855
204856
204857
204858
204859
204860
204861
204862
204863
204864
204865
204866
204867
204868
204869
204870
204871
204872
204873
204874
204875
204876
204877
204878
204879
204880
204881
204882
204883
204884
204885
204886
204887
204888
204889
204890
204891
204892
204893
204894
204895
204896
204897
204898
204899
204900
204901
204902
204903
204904
204905
204906
204907
204908
204909
204910
204911
204912
204913
204914
204915
204916
204917
204918
204919
204920
204921
204922
204923
204924
204925
204926
204927
204928
204929
204930
204931
204932
204933
204934
204935
204936
204937
204938
204939
204940
204941
204942
204943
204944
204945
204946
204947
204948
204949
204950
204951
204952
204953
204954
204955
204956
204957
204958
204959
204960
204961
204962
204963
204964
204965
204966
204967
204968
204969
204970
204971
204972
204973
204974
204975
204976
204977
204978
204979
204980
204981
204982
204983
204984
204985
204986
204987
204988
204989
204990
204991
204992
204993
204994
204995
204996
204997
204998
204999
205000
205001
205002
205003
205004
205005
205006
205007
205008
205009
205010
205011
205012
205013
205014
205015
205016
205017
205018
205019
205020
205021
205022
205023
205024
205025
205026
205027
205028
205029
205030
205031
205032
205033
205034
205035
205036
205037
205038
205039
205040
205041
205042
205043
205044
205045
205046
205047
205048
205049
205050
205051
205052
205053
205054
205055
205056
205057
205058
205059
205060
205061
205062
205063
205064
205065
205066
205067
205068
205069
205070
205071
205072
205073
205074
205075
205076
205077
205078
205079
205080
205081
205082
205083
205084
205085
205086
205087
205088
205089
205090
205091
205092
205093
205094
205095
205096
205097
205098
205099
205100
205101
205102
205103
205104
205105
205106
205107
205108
205109
205110
205111
205112
205113
205114
205115
205116
205117
205118
205119
205120
205121
205122
205123
205124
205125
205126
205127
205128
205129
205130
205131
205132
205133
205134
205135
205136
205137
205138
205139
205140
205141
205142
205143
205144
205145
205146
205147
205148
205149
205150
205151
205152
205153
205154
205155
205156
205157
205158
205159
205160
205161
205162
205163
205164
205165
205166
205167
205168
205169
205170
205171
205172
205173
205174
205175
205176
205177
205178
205179
205180
205181
205182
205183
205184
205185
205186
205187
205188
205189
205190
205191
205192
205193
205194
205195
205196
205197
205198
205199
205200
205201
205202
205203
205204
205205
205206
205207
205208
205209
205210
205211
205212
205213
205214
205215
205216
205217
205218
205219
205220
205221
205222
205223
205224
205225
205226
205227
205228
205229
205230
205231
205232
205233
205234
205235
205236
205237
205238
205239
205240
205241
205242
205243
205244
205245
205246
205247
205248
205249
205250
205251
205252
205253
205254
205255
205256
205257
205258
205259
205260
205261
205262
205263
205264
205265
205266
205267
205268
205269
205270
205271
205272
205273
205274
205275
205276
205277
205278
205279
205280
205281
205282
205283
205284
205285
205286
205287
205288
205289
205290
205291
205292
205293
205294
205295
205296
205297
205298
205299
205300
205301
205302
205303
205304
205305
205306
205307
205308
205309
205310
205311
205312
205313
205314
205315
205316
205317
205318
205319
205320
205321
205322
205323
205324
205325
205326
205327
205328
205329
205330
205331
205332
205333
205334
205335
205336
205337
205338
205339
205340
205341
205342
205343
205344
205345
205346
205347
205348
205349
205350
205351
205352
205353
205354
205355
205356
205357
205358
205359
205360
205361
205362
205363
205364
205365
205366
205367
205368
205369
205370
205371
205372
205373
205374
205375
205376
205377
205378
205379
205380
205381
205382
205383
205384
205385
205386
205387
205388
205389
205390
205391
205392
205393
205394
205395
205396
205397
205398
205399
205400
205401
205402
205403
205404
205405
205406
205407
205408
205409
205410
205411
205412
205413
205414
205415
205416
205417
205418
205419
205420
205421
205422
205423
205424
205425
205426
205427
205428
205429
205430
205431
205432
205433
205434
205435
205436
205437
205438
205439
205440
205441
205442
205443
205444
205445
205446
205447
205448
205449
205450
205451
205452
205453
205454
205455
205456
205457
205458
205459
205460
205461
205462
205463
205464
205465
205466
205467
205468
205469
205470
205471
205472
205473
205474
205475
205476
205477
205478
205479
205480
205481
205482
205483
205484
205485
205486
205487
205488
205489
205490
205491
205492
205493
205494
205495
205496
205497
205498
205499
205500
205501
205502
205503
205504
205505
205506
205507
205508
205509
205510
205511
205512
205513
205514
205515
205516
205517
205518
205519
205520
205521
205522
205523
205524
205525
205526
205527
205528
205529
205530
205531
205532
205533
205534
205535
205536
205537
205538
205539
205540
205541
205542
205543
205544
205545
205546
205547
205548
205549
205550
205551
205552
205553
205554
205555
205556
205557
205558
205559
205560
205561
205562
205563
205564
205565
205566
205567
205568
205569
205570
205571
205572
205573
205574
205575
205576
205577
205578
205579
205580
205581
205582
205583
205584
205585
205586
205587
205588
205589
205590
205591
205592
205593
205594
205595
205596
205597
205598
205599
205600
205601
205602
205603
205604
205605
205606
205607
205608
205609
205610
205611
205612
205613
205614
205615
205616
205617
205618
205619
205620
205621
205622
205623
205624
205625
205626
205627
205628
205629
205630
205631
205632
205633
205634
205635
205636
205637
205638
205639
205640
205641
205642
205643
205644
205645
205646
205647
205648
205649
205650
205651
205652
205653
205654
205655
205656
205657
205658
205659
205660
205661
205662
205663
205664
205665
205666
205667
205668
205669
205670
205671
205672
205673
205674
205675
205676
205677
205678
205679
205680
205681
205682
205683
205684
205685
205686
205687
205688
205689
205690
205691
205692
205693
205694
205695
205696
205697
205698
205699
205700
205701
205702
205703
205704
205705
205706
205707
205708
205709
205710
205711
205712
205713
205714
205715
205716
205717
205718
205719
205720
205721
205722
205723
205724
205725
205726
205727
205728
205729
205730
205731
205732
205733
205734
205735
205736
205737
205738
205739
205740
205741
205742
205743
205744
205745
205746
205747
205748
205749
205750
205751
205752
205753
205754
205755
205756
205757
205758
205759
205760
205761
205762
205763
205764
205765
205766
205767
205768
205769
205770
205771
205772
205773
205774
205775
205776
205777
205778
205779
205780
205781
205782
205783
205784
205785
205786
205787
205788
205789
205790
205791
205792
205793
205794
205795
205796
205797
205798
205799
205800
205801
205802
205803
205804
205805
205806
205807
205808
205809
205810
205811
205812
205813
205814
205815
205816
205817
205818
205819
205820
205821
205822
205823
205824
205825
205826
205827
205828
205829
205830
205831
205832
205833
205834
205835
205836
205837
205838
205839
205840
205841
205842
205843
205844
205845
205846
205847
205848
205849
205850
205851
205852
205853
205854
205855
205856
205857
205858
205859
205860
205861
205862
205863
205864
205865
205866
205867
205868
205869
205870
205871
205872
205873
205874
205875
205876
205877
205878
205879
205880
205881
205882
205883
205884
205885
205886
205887
205888
205889
205890
205891
205892
205893
205894
205895
205896
205897
205898
205899
205900
205901
205902
205903
205904
205905
205906
205907
205908
205909
205910
205911
205912
205913
205914
205915
205916
205917
205918
205919
205920
205921
205922
205923
205924
205925
205926
205927
205928
205929
205930
205931
205932
205933
205934
205935
205936
205937
205938
205939
205940
205941
205942
205943
205944
205945
205946
205947
205948
205949
205950
205951
205952
205953
205954
205955
205956
205957
205958
205959
205960
205961
205962
205963
205964
205965
205966
205967
205968
205969
205970
205971
205972
205973
205974
205975
205976
205977
205978
205979
205980
205981
205982
205983
205984
205985
205986
205987
205988
205989
205990
205991
205992
205993
205994
205995
205996
205997
205998
205999
206000
206001
206002
206003
206004
206005
206006
206007
206008
206009
206010
206011
206012
206013
206014
206015
206016
206017
206018
206019
206020
206021
206022
206023
206024
206025
206026
206027
206028
206029
206030
206031
206032
206033
206034
206035
206036
206037
206038
206039
206040
206041
206042
206043
206044
206045
206046
206047
206048
206049
206050
206051
206052
206053
206054
206055
206056
206057
206058
206059
206060
206061
206062
206063
206064
206065
206066
206067
206068
206069
206070
206071
206072
206073
206074
206075
206076
206077
206078
206079
206080
206081
206082
206083
206084
206085
206086
206087
206088
206089
206090
206091
206092
206093
206094
206095
206096
206097
206098
206099
206100
206101
206102
206103
206104
206105
206106
206107
206108
206109
206110
206111
206112
206113
206114
206115
206116
206117
206118
206119
206120
206121
206122
206123
206124
206125
206126
206127
206128
206129
206130
206131
206132
206133
206134
206135
206136
206137
206138
206139
206140
206141
206142
206143
206144
206145
206146
206147
206148
206149
206150
206151
206152
206153
206154
206155
206156
206157
206158
206159
206160
206161
206162
206163
206164
206165
206166
206167
206168
206169
206170
206171
206172
206173
206174
206175
206176
206177
206178
206179
206180
206181
206182
206183
206184
206185
206186
206187
206188
206189
206190
206191
206192
206193
206194
206195
206196
206197
206198
206199
206200
206201
206202
206203
206204
206205
206206
206207
206208
206209
206210
206211
206212
206213
206214
206215
206216
206217
206218
206219
206220
206221
206222
206223
206224
206225
206226
206227
206228
206229
206230
206231
206232
206233
206234
206235
206236
206237
206238
206239
206240
206241
206242
206243
206244
206245
206246
206247
206248
206249
206250
206251
206252
206253
206254
206255
206256
206257
206258
206259
206260
206261
206262
206263
206264
206265
206266
206267
206268
206269
206270
206271
206272
206273
206274
206275
206276
206277
206278
206279
206280
206281
206282
206283
206284
206285
206286
206287
206288
206289
206290
206291
206292
206293
206294
206295
206296
206297
206298
206299
206300
206301
206302
206303
206304
206305
206306
206307
206308
206309
206310
206311
206312
206313
206314
206315
206316
206317
206318
206319
206320
206321
206322
206323
206324
206325
206326
206327
206328
206329
206330
206331
206332
206333
206334
206335
206336
206337
206338
206339
206340
206341
206342
206343
206344
206345
206346
206347
206348
206349
206350
206351
206352
206353
206354
206355
206356
206357
206358
206359
206360
206361
206362
206363
206364
206365
206366
206367
206368
206369
206370
206371
206372
206373
206374
206375
206376
206377
206378
206379
206380
206381
206382
206383
206384
206385
206386
206387
206388
206389
206390
206391
206392
206393
206394
206395
206396
206397
206398
206399
206400
206401
206402
206403
206404
206405
206406
206407
206408
206409
206410
206411
206412
206413
206414
206415
206416
206417
206418
206419
206420
206421
206422
206423
206424
206425
206426
206427
206428
206429
206430
206431
206432
206433
206434
206435
206436
206437
206438
206439
206440
206441
206442
206443
206444
206445
206446
206447
206448
206449
206450
206451
206452
206453
206454
206455
206456
206457
206458
206459
206460
206461
206462
206463
206464
206465
206466
206467
206468
206469
206470
206471
206472
206473
206474
206475
206476
206477
206478
206479
206480
206481
206482
206483
206484
206485
206486
206487
206488
206489
206490
206491
206492
206493
206494
206495
206496
206497
206498
206499
206500
206501
206502
206503
206504
206505
206506
206507
206508
206509
206510
206511
206512
206513
206514
206515
206516
206517
206518
206519
206520
206521
206522
206523
206524
206525
206526
206527
206528
206529
206530
206531
206532
206533
206534
206535
206536
206537
206538
206539
206540
206541
206542
206543
206544
206545
206546
206547
206548
206549
206550
206551
206552
206553
206554
206555
206556
206557
206558
206559
206560
206561
206562
206563
206564
206565
206566
206567
206568
206569
206570
206571
206572
206573
206574
206575
206576
206577
206578
206579
206580
206581
206582
206583
206584
206585
206586
206587
206588
206589
206590
206591
206592
206593
206594
206595
206596
206597
206598
206599
206600
206601
206602
206603
206604
206605
206606
206607
206608
206609
206610
206611
206612
206613
206614
206615
206616
206617
206618
206619
206620
206621
206622
206623
206624
206625
206626
206627
206628
206629
206630
206631
206632
206633
206634
206635
206636
206637
206638
206639
206640
206641
206642
206643
206644
206645
206646
206647
206648
206649
206650
206651
206652
206653
206654
206655
206656
206657
206658
206659
206660
206661
206662
206663
206664
206665
206666
206667
206668
206669
206670
206671
206672
206673
206674
206675
206676
206677
206678
206679
206680
206681
206682
206683
206684
206685
206686
206687
206688
206689
206690
206691
206692
206693
206694
206695
206696
206697
206698
206699
206700
206701
206702
206703
206704
206705
206706
206707
206708
206709
206710
206711
206712
206713
206714
206715
206716
206717
206718
206719
206720
206721
206722
206723
206724
206725
206726
206727
206728
206729
206730
206731
206732
206733
206734
206735
206736
206737
206738
206739
206740
206741
206742
206743
206744
206745
206746
206747
206748
206749
206750
206751
206752
206753
206754
206755
206756
206757
206758
206759
206760
206761
206762
206763
206764
206765
206766
206767
206768
206769
206770
206771
206772
206773
206774
206775
206776
206777
206778
206779
206780
206781
206782
206783
206784
206785
206786
206787
206788
206789
206790
206791
206792
206793
206794
206795
206796
206797
206798
206799
206800
206801
206802
206803
206804
206805
206806
206807
206808
206809
206810
206811
206812
206813
206814
206815
206816
206817
206818
206819
206820
206821
206822
206823
206824
206825
206826
206827
206828
206829
206830
206831
206832
206833
206834
206835
206836
206837
206838
206839
206840
206841
206842
206843
206844
206845
206846
206847
206848
206849
206850
206851
206852
206853
206854
206855
206856
206857
206858
206859
206860
206861
206862
206863
206864
206865
206866
206867
206868
206869
206870
206871
206872
206873
206874
206875
206876
206877
206878
206879
206880
206881
206882
206883
206884
206885
206886
206887
206888
206889
206890
206891
206892
206893
206894
206895
206896
206897
206898
206899
206900
206901
206902
206903
206904
206905
206906
206907
206908
206909
206910
206911
206912
206913
206914
206915
206916
206917
206918
206919
206920
206921
206922
206923
206924
206925
206926
206927
206928
206929
206930
206931
206932
206933
206934
206935
206936
206937
206938
206939
206940
206941
206942
206943
206944
206945
206946
206947
206948
206949
206950
206951
206952
206953
206954
206955
206956
206957
206958
206959
206960
206961
206962
206963
206964
206965
206966
206967
206968
206969
206970
206971
206972
206973
206974
206975
206976
206977
206978
206979
206980
206981
206982
206983
206984
206985
206986
206987
206988
206989
206990
206991
206992
206993
206994
206995
206996
206997
206998
206999
207000
207001
207002
207003
207004
207005
207006
207007
207008
207009
207010
207011
207012
207013
207014
207015
207016
207017
207018
207019
207020
207021
207022
207023
207024
207025
207026
207027
207028
207029
207030
207031
207032
207033
207034
207035
207036
207037
207038
207039
207040
207041
207042
207043
207044
207045
207046
207047
207048
207049
207050
207051
207052
207053
207054
207055
207056
207057
207058
207059
207060
207061
207062
207063
207064
207065
207066
207067
207068
207069
207070
207071
207072
207073
207074
207075
207076
207077
207078
207079
207080
207081
207082
207083
207084
207085
207086
207087
207088
207089
207090
207091
207092
207093
207094
207095
207096
207097
207098
207099
207100
207101
207102
207103
207104
207105
207106
207107
207108
207109
207110
207111
207112
207113
207114
207115
207116
207117
207118
207119
207120
207121
207122
207123
207124
207125
207126
207127
207128
207129
207130
207131
207132
207133
207134
207135
207136
207137
207138
207139
207140
207141
207142
207143
207144
207145
207146
207147
207148
207149
207150
207151
207152
207153
207154
207155
207156
207157
207158
207159
207160
207161
207162
207163
207164
207165
207166
207167
207168
207169
207170
207171
207172
207173
207174
207175
207176
207177
207178
207179
207180
207181
207182
207183
207184
207185
207186
207187
207188
207189
207190
207191
207192
207193
207194
207195
207196
207197
207198
207199
207200
207201
207202
207203
207204
207205
207206
207207
207208
207209
207210
207211
207212
207213
207214
207215
207216
207217
207218
207219
207220
207221
207222
207223
207224
207225
207226
207227
207228
207229
207230
207231
207232
207233
207234
207235
207236
207237
207238
207239
207240
207241
207242
207243
207244
207245
207246
207247
207248
207249
207250
207251
207252
207253
207254
207255
207256
207257
207258
207259
207260
207261
207262
207263
207264
207265
207266
207267
207268
207269
207270
207271
207272
207273
207274
207275
207276
207277
207278
207279
207280
207281
207282
207283
207284
207285
207286
207287
207288
207289
207290
207291
207292
207293
207294
207295
207296
207297
207298
207299
207300
207301
207302
207303
207304
207305
207306
207307
207308
207309
207310
207311
207312
207313
207314
207315
207316
207317
207318
207319
207320
207321
207322
207323
207324
207325
207326
207327
207328
207329
207330
207331
207332
207333
207334
207335
207336
207337
207338
207339
207340
207341
207342
207343
207344
207345
207346
207347
207348
207349
207350
207351
207352
207353
207354
207355
207356
207357
207358
207359
207360
207361
207362
207363
207364
207365
207366
207367
207368
207369
207370
207371
207372
207373
207374
207375
207376
207377
207378
207379
207380
207381
207382
207383
207384
207385
207386
207387
207388
207389
207390
207391
207392
207393
207394
207395
207396
207397
207398
207399
207400
207401
207402
207403
207404
207405
207406
207407
207408
207409
207410
207411
207412
207413
207414
207415
207416
207417
207418
207419
207420
207421
207422
207423
207424
207425
207426
207427
207428
207429
207430
207431
207432
207433
207434
207435
207436
207437
207438
207439
207440
207441
207442
207443
207444
207445
207446
207447
207448
207449
207450
207451
207452
207453
207454
207455
207456
207457
207458
207459
207460
207461
207462
207463
207464
207465
207466
207467
207468
207469
207470
207471
207472
207473
207474
207475
207476
207477
207478
207479
207480
207481
207482
207483
207484
207485
207486
207487
207488
207489
207490
207491
207492
207493
207494
207495
207496
207497
207498
207499
207500
207501
207502
207503
207504
207505
207506
207507
207508
207509
207510
207511
207512
207513
207514
207515
207516
207517
207518
207519
207520
207521
207522
207523
207524
207525
207526
207527
207528
207529
207530
207531
207532
207533
207534
207535
207536
207537
207538
207539
207540
207541
207542
207543
207544
207545
207546
207547
207548
207549
207550
207551
207552
207553
207554
207555
207556
207557
207558
207559
207560
207561
207562
207563
207564
207565
207566
207567
207568
207569
207570
207571
207572
207573
207574
207575
207576
207577
207578
207579
207580
207581
207582
207583
207584
207585
207586
207587
207588
207589
207590
207591
207592
207593
207594
207595
207596
207597
207598
207599
207600
207601
207602
207603
207604
207605
207606
207607
207608
207609
207610
207611
207612
207613
207614
207615
207616
207617
207618
207619
207620
207621
207622
207623
207624
207625
207626
207627
207628
207629
207630
207631
207632
207633
207634
207635
207636
207637
207638
207639
207640
207641
207642
207643
207644
207645
207646
207647
207648
207649
207650
207651
207652
207653
207654
207655
207656
207657
207658
207659
207660
207661
207662
207663
207664
207665
207666
207667
207668
207669
207670
207671
207672
207673
207674
207675
207676
207677
207678
207679
207680
207681
207682
207683
207684
207685
207686
207687
207688
207689
207690
207691
207692
207693
207694
207695
207696
207697
207698
207699
207700
207701
207702
207703
207704
207705
207706
207707
207708
207709
207710
207711
207712
207713
207714
207715
207716
207717
207718
207719
207720
207721
207722
207723
207724
207725
207726
207727
207728
207729
207730
207731
207732
207733
207734
207735
207736
207737
207738
207739
207740
207741
207742
207743
207744
207745
207746
207747
207748
207749
207750
207751
207752
207753
207754
207755
207756
207757
207758
207759
207760
207761
207762
207763
207764
207765
207766
207767
207768
207769
207770
207771
207772
207773
207774
207775
207776
207777
207778
207779
207780
207781
207782
207783
207784
207785
207786
207787
207788
207789
207790
207791
207792
207793
207794
207795
207796
207797
207798
207799
207800
207801
207802
207803
207804
207805
207806
207807
207808
207809
207810
207811
207812
207813
207814
207815
207816
207817
207818
207819
207820
207821
207822
207823
207824
207825
207826
207827
207828
207829
207830
207831
207832
207833
207834
207835
207836
207837
207838
207839
207840
207841
207842
207843
207844
207845
207846
207847
207848
207849
207850
207851
207852
207853
207854
207855
207856
207857
207858
207859
207860
207861
207862
207863
207864
207865
207866
207867
207868
207869
207870
207871
207872
207873
207874
207875
207876
207877
207878
207879
207880
207881
207882
207883
207884
207885
207886
207887
207888
207889
207890
207891
207892
207893
207894
207895
207896
207897
207898
207899
207900
207901
207902
207903
207904
207905
207906
207907
207908
207909
207910
207911
207912
207913
207914
207915
207916
207917
207918
207919
207920
207921
207922
207923
207924
207925
207926
207927
207928
207929
207930
207931
207932
207933
207934
207935
207936
207937
207938
207939
207940
207941
207942
207943
207944
207945
207946
207947
207948
207949
207950
207951
207952
207953
207954
207955
207956
207957
207958
207959
207960
207961
207962
207963
207964
207965
207966
207967
207968
207969
207970
207971
207972
207973
207974
207975
207976
207977
207978
207979
207980
207981
207982
207983
207984
207985
207986
207987
207988
207989
207990
207991
207992
207993
207994
207995
207996
207997
207998
207999
208000
208001
208002
208003
208004
208005
208006
208007
208008
208009
208010
208011
208012
208013
208014
208015
208016
208017
208018
208019
208020
208021
208022
208023
208024
208025
208026
208027
208028
208029
208030
208031
208032
208033
208034
208035
208036
208037
208038
208039
208040
208041
208042
208043
208044
208045
208046
208047
208048
208049
208050
208051
208052
208053
208054
208055
208056
208057
208058
208059
208060
208061
208062
208063
208064
208065
208066
208067
208068
208069
208070
208071
208072
208073
208074
208075
208076
208077
208078
208079
208080
208081
208082
208083
208084
208085
208086
208087
208088
208089
208090
208091
208092
208093
208094
208095
208096
208097
208098
208099
208100
208101
208102
208103
208104
208105
208106
208107
208108
208109
208110
208111
208112
208113
208114
208115
208116
208117
208118
208119
208120
208121
208122
208123
208124
208125
208126
208127
208128
208129
208130
208131
208132
208133
208134
208135
208136
208137
208138
208139
208140
208141
208142
208143
208144
208145
208146
208147
208148
208149
208150
208151
208152
208153
208154
208155
208156
208157
208158
208159
208160
208161
208162
208163
208164
208165
208166
208167
208168
208169
208170
208171
208172
208173
208174
208175
208176
208177
208178
208179
208180
208181
208182
208183
208184
208185
208186
208187
208188
208189
208190
208191
208192
208193
208194
208195
208196
208197
208198
208199
208200
208201
208202
208203
208204
208205
208206
208207
208208
208209
208210
208211
208212
208213
208214
208215
208216
208217
208218
208219
208220
208221
208222
208223
208224
208225
208226
208227
208228
208229
208230
208231
208232
208233
208234
208235
208236
208237
208238
208239
208240
208241
208242
208243
208244
208245
208246
208247
208248
208249
208250
208251
208252
208253
208254
208255
208256
208257
208258
208259
208260
208261
208262
208263
208264
208265
208266
208267
208268
208269
208270
208271
208272
208273
208274
208275
208276
208277
208278
208279
208280
208281
208282
208283
208284
208285
208286
208287
208288
208289
208290
208291
208292
208293
208294
208295
208296
208297
208298
208299
208300
208301
208302
208303
208304
208305
208306
208307
208308
208309
208310
208311
208312
208313
208314
208315
208316
208317
208318
208319
208320
208321
208322
208323
208324
208325
208326
208327
208328
208329
208330
208331
208332
208333
208334
208335
208336
208337
208338
208339
208340
208341
208342
208343
208344
208345
208346
208347
208348
208349
208350
208351
208352
208353
208354
208355
208356
208357
208358
208359
208360
208361
208362
208363
208364
208365
208366
208367
208368
208369
208370
208371
208372
208373
208374
208375
208376
208377
208378
208379
208380
208381
208382
208383
208384
208385
208386
208387
208388
208389
208390
208391
208392
208393
208394
208395
208396
208397
208398
208399
208400
208401
208402
208403
208404
208405
208406
208407
208408
208409
208410
208411
208412
208413
208414
208415
208416
208417
208418
208419
208420
208421
208422
208423
208424
208425
208426
208427
208428
208429
208430
208431
208432
208433
208434
208435
208436
208437
208438
208439
208440
208441
208442
208443
208444
208445
208446
208447
208448
208449
208450
208451
208452
208453
208454
208455
208456
208457
208458
208459
208460
208461
208462
208463
208464
208465
208466
208467
208468
208469
208470
208471
208472
208473
208474
208475
208476
208477
208478
208479
208480
208481
208482
208483
208484
208485
208486
208487
208488
208489
208490
208491
208492
208493
208494
208495
208496
208497
208498
208499
208500
208501
208502
208503
208504
208505
208506
208507
208508
208509
208510
208511
208512
208513
208514
208515
208516
208517
208518
208519
208520
208521
208522
208523
208524
208525
208526
208527
208528
208529
208530
208531
208532
208533
208534
208535
208536
208537
208538
208539
208540
208541
208542
208543
208544
208545
208546
208547
208548
208549
208550
208551
208552
208553
208554
208555
208556
208557
208558
208559
208560
208561
208562
208563
208564
208565
208566
208567
208568
208569
208570
208571
208572
208573
208574
208575
208576
208577
208578
208579
208580
208581
208582
208583
208584
208585
208586
208587
208588
208589
208590
208591
208592
208593
208594
208595
208596
208597
208598
208599
208600
208601
208602
208603
208604
208605
208606
208607
208608
208609
208610
208611
208612
208613
208614
208615
208616
208617
208618
208619
208620
208621
208622
208623
208624
208625
208626
208627
208628
208629
208630
208631
208632
208633
208634
208635
208636
208637
208638
208639
208640
208641
208642
208643
208644
208645
208646
208647
208648
208649
208650
208651
208652
208653
208654
208655
208656
208657
208658
208659
208660
208661
208662
208663
208664
208665
208666
208667
208668
208669
208670
208671
208672
208673
208674
208675
208676
208677
208678
208679
208680
208681
208682
208683
208684
208685
208686
208687
208688
208689
208690
208691
208692
208693
208694
208695
208696
208697
208698
208699
208700
208701
208702
208703
208704
208705
208706
208707
208708
208709
208710
208711
208712
208713
208714
208715
208716
208717
208718
208719
208720
208721
208722
208723
208724
208725
208726
208727
208728
208729
208730
208731
208732
208733
208734
208735
208736
208737
208738
208739
208740
208741
208742
208743
208744
208745
208746
208747
208748
208749
208750
208751
208752
208753
208754
208755
208756
208757
208758
208759
208760
208761
208762
208763
208764
208765
208766
208767
208768
208769
208770
208771
208772
208773
208774
208775
208776
208777
208778
208779
208780
208781
208782
208783
208784
208785
208786
208787
208788
208789
208790
208791
208792
208793
208794
208795
208796
208797
208798
208799
208800
208801
208802
208803
208804
208805
208806
208807
208808
208809
208810
208811
208812
208813
208814
208815
208816
208817
208818
208819
208820
208821
208822
208823
208824
208825
208826
208827
208828
208829
208830
208831
208832
208833
208834
208835
208836
208837
208838
208839
208840
208841
208842
208843
208844
208845
208846
208847
208848
208849
208850
208851
208852
208853
208854
208855
208856
208857
208858
208859
208860
208861
208862
208863
208864
208865
208866
208867
208868
208869
208870
208871
208872
208873
208874
208875
208876
208877
208878
208879
208880
208881
208882
208883
208884
208885
208886
208887
208888
208889
208890
208891
208892
208893
208894
208895
208896
208897
208898
208899
208900
208901
208902
208903
208904
208905
208906
208907
208908
208909
208910
208911
208912
208913
208914
208915
208916
208917
208918
208919
208920
208921
208922
208923
208924
208925
208926
208927
208928
208929
208930
208931
208932
208933
208934
208935
208936
208937
208938
208939
208940
208941
208942
208943
208944
208945
208946
208947
208948
208949
208950
208951
208952
208953
208954
208955
208956
208957
208958
208959
208960
208961
208962
208963
208964
208965
208966
208967
208968
208969
208970
208971
208972
208973
208974
208975
208976
208977
208978
208979
208980
208981
208982
208983
208984
208985
208986
208987
208988
208989
208990
208991
208992
208993
208994
208995
208996
208997
208998
208999
209000
209001
209002
209003
209004
209005
209006
209007
209008
209009
209010
209011
209012
209013
209014
209015
209016
209017
209018
209019
209020
209021
209022
209023
209024
209025
209026
209027
209028
209029
209030
209031
209032
209033
209034
209035
209036
209037
209038
209039
209040
209041
209042
209043
209044
209045
209046
209047
209048
209049
209050
209051
209052
209053
209054
209055
209056
209057
209058
209059
209060
209061
209062
209063
209064
209065
209066
209067
209068
209069
209070
209071
209072
209073
209074
209075
209076
209077
209078
209079
209080
209081
209082
209083
209084
209085
209086
209087
209088
209089
209090
209091
209092
209093
209094
209095
209096
209097
209098
209099
209100
209101
209102
209103
209104
209105
209106
209107
209108
209109
209110
209111
209112
209113
209114
209115
209116
209117
209118
209119
209120
209121
209122
209123
209124
209125
209126
209127
209128
209129
209130
209131
209132
209133
209134
209135
209136
209137
209138
209139
209140
209141
209142
209143
209144
209145
209146
209147
209148
209149
209150
209151
209152
209153
209154
209155
209156
209157
209158
209159
209160
209161
209162
209163
209164
209165
209166
209167
209168
209169
209170
209171
209172
209173
209174
209175
209176
209177
209178
209179
209180
209181
209182
209183
209184
209185
209186
209187
209188
209189
209190
209191
209192
209193
209194
209195
209196
209197
209198
209199
209200
209201
209202
209203
209204
209205
209206
209207
209208
209209
209210
209211
209212
209213
209214
209215
209216
209217
209218
209219
209220
209221
209222
209223
209224
209225
209226
209227
209228
209229
209230
209231
209232
209233
209234
209235
209236
209237
209238
209239
209240
209241
209242
209243
209244
209245
209246
209247
209248
209249
209250
209251
209252
209253
209254
209255
209256
209257
209258
209259
209260
209261
209262
209263
209264
209265
209266
209267
209268
209269
209270
209271
209272
209273
209274
209275
209276
209277
209278
209279
209280
209281
209282
209283
209284
209285
209286
209287
209288
209289
209290
209291
209292
209293
209294
209295
209296
209297
209298
209299
209300
209301
209302
209303
209304
209305
209306
209307
209308
209309
209310
209311
209312
209313
209314
209315
209316
209317
209318
209319
209320
209321
209322
209323
209324
209325
209326
209327
209328
209329
209330
209331
209332
209333
209334
209335
209336
209337
209338
209339
209340
209341
209342
209343
209344
209345
209346
209347
209348
209349
209350
209351
209352
209353
209354
209355
209356
209357
209358
209359
209360
209361
209362
209363
209364
209365
209366
209367
209368
209369
209370
209371
209372
209373
209374
209375
209376
209377
209378
209379
209380
209381
209382
209383
209384
209385
209386
209387
209388
209389
209390
209391
209392
209393
209394
209395
209396
209397
209398
209399
209400
209401
209402
209403
209404
209405
209406
209407
209408
209409
209410
209411
209412
209413
209414
209415
209416
209417
209418
209419
209420
209421
209422
209423
209424
209425
209426
209427
209428
209429
209430
209431
209432
209433
209434
209435
209436
209437
209438
209439
209440
209441
209442
209443
209444
209445
209446
209447
209448
209449
209450
209451
209452
209453
209454
209455
209456
209457
209458
209459
209460
209461
209462
209463
209464
209465
209466
209467
209468
209469
209470
209471
209472
209473
209474
209475
209476
209477
209478
209479
209480
209481
209482
209483
209484
209485
209486
209487
209488
209489
209490
209491
209492
209493
209494
209495
209496
209497
209498
209499
209500
209501
209502
209503
209504
209505
209506
209507
209508
209509
209510
209511
209512
209513
209514
209515
209516
209517
209518
209519
209520
209521
209522
209523
209524
209525
209526
209527
209528
209529
209530
209531
209532
209533
209534
209535
209536
209537
209538
209539
209540
209541
209542
209543
209544
209545
209546
209547
209548
209549
209550
209551
209552
209553
209554
209555
209556
209557
209558
209559
209560
209561
209562
209563
209564
209565
209566
209567
209568
209569
209570
209571
209572
209573
209574
209575
209576
209577
209578
209579
209580
209581
209582
209583
209584
209585
209586
209587
209588
209589
209590
209591
209592
209593
209594
209595
209596
209597
209598
209599
209600
209601
209602
209603
209604
209605
209606
209607
209608
209609
209610
209611
209612
209613
209614
209615
209616
209617
209618
209619
209620
209621
209622
209623
209624
209625
209626
209627
209628
209629
209630
209631
209632
209633
209634
209635
209636
209637
209638
209639
209640
209641
209642
209643
209644
209645
209646
209647
209648
209649
209650
209651
209652
209653
209654
209655
209656
209657
209658
209659
209660
209661
209662
209663
209664
209665
209666
209667
209668
209669
209670
209671
209672
209673
209674
209675
209676
209677
209678
209679
209680
209681
209682
209683
209684
209685
209686
209687
209688
209689
209690
209691
209692
209693
209694
209695
209696
209697
209698
209699
209700
209701
209702
209703
209704
209705
209706
209707
209708
209709
209710
209711
209712
209713
209714
209715
209716
209717
209718
209719
209720
209721
209722
209723
209724
209725
209726
209727
209728
209729
209730
209731
209732
209733
209734
209735
209736
209737
209738
209739
209740
209741
209742
209743
209744
209745
209746
209747
209748
209749
209750
209751
209752
209753
209754
209755
209756
209757
209758
209759
209760
209761
209762
209763
209764
209765
209766
209767
209768
209769
209770
209771
209772
209773
209774
209775
209776
209777
209778
209779
209780
209781
209782
209783
209784
209785
209786
209787
209788
209789
209790
209791
209792
209793
209794
209795
209796
209797
209798
209799
209800
209801
209802
209803
209804
209805
209806
209807
209808
209809
209810
209811
209812
209813
209814
209815
209816
209817
209818
209819
209820
209821
209822
209823
209824
209825
209826
209827
209828
209829
209830
209831
209832
209833
209834
209835
209836
209837
209838
209839
209840
209841
209842
209843
209844
209845
209846
209847
209848
209849
209850
209851
209852
209853
209854
209855
209856
209857
209858
209859
209860
209861
209862
209863
209864
209865
209866
209867
209868
209869
209870
209871
209872
209873
209874
209875
209876
209877
209878
209879
209880
209881
209882
209883
209884
209885
209886
209887
209888
209889
209890
209891
209892
209893
209894
209895
209896
209897
209898
209899
209900
209901
209902
209903
209904
209905
209906
209907
209908
209909
209910
209911
209912
209913
209914
209915
209916
209917
209918
209919
209920
209921
209922
209923
209924
209925
209926
209927
209928
209929
209930
209931
209932
209933
209934
209935
209936
209937
209938
209939
209940
209941
209942
209943
209944
209945
209946
209947
209948
209949
209950
209951
209952
209953
209954
209955
209956
209957
209958
209959
209960
209961
209962
209963
209964
209965
209966
209967
209968
209969
209970
209971
209972
209973
209974
209975
209976
209977
209978
209979
209980
209981
209982
209983
209984
209985
209986
209987
209988
209989
209990
209991
209992
209993
209994
209995
209996
209997
209998
209999
210000
210001
210002
210003
210004
210005
210006
210007
210008
210009
210010
210011
210012
210013
210014
210015
210016
210017
210018
210019
210020
210021
210022
210023
210024
210025
210026
210027
210028
210029
210030
210031
210032
210033
210034
210035
210036
210037
210038
210039
210040
210041
210042
210043
210044
210045
210046
210047
210048
210049
210050
210051
210052
210053
210054
210055
210056
210057
210058
210059
210060
210061
210062
210063
210064
210065
210066
210067
210068
210069
210070
210071
210072
210073
210074
210075
210076
210077
210078
210079
210080
210081
210082
210083
210084
210085
210086
210087
210088
210089
210090
210091
210092
210093
210094
210095
210096
210097
210098
210099
210100
210101
210102
210103
210104
210105
210106
210107
210108
210109
210110
210111
210112
210113
210114
210115
210116
210117
210118
210119
210120
210121
210122
210123
210124
210125
210126
210127
210128
210129
210130
210131
210132
210133
210134
210135
210136
210137
210138
210139
210140
210141
210142
210143
210144
210145
210146
210147
210148
210149
210150
210151
210152
210153
210154
210155
210156
210157
210158
210159
210160
210161
210162
210163
210164
210165
210166
210167
210168
210169
210170
210171
210172
210173
210174
210175
210176
210177
210178
210179
210180
210181
210182
210183
210184
210185
210186
210187
210188
210189
210190
210191
210192
210193
210194
210195
210196
210197
210198
210199
210200
210201
210202
210203
210204
210205
210206
210207
210208
210209
210210
210211
210212
210213
210214
210215
210216
210217
210218
210219
210220
210221
210222
210223
210224
210225
210226
210227
210228
210229
210230
210231
210232
210233
210234
210235
210236
210237
210238
210239
210240
210241
210242
210243
210244
210245
210246
210247
210248
210249
210250
210251
210252
210253
210254
210255
210256
210257
210258
210259
210260
210261
210262
210263
210264
210265
210266
210267
210268
210269
210270
210271
210272
210273
210274
210275
210276
210277
210278
210279
210280
210281
210282
210283
210284
210285
210286
210287
210288
210289
210290
210291
210292
210293
210294
210295
210296
210297
210298
210299
210300
210301
210302
210303
210304
210305
210306
210307
210308
210309
210310
210311
210312
210313
210314
210315
210316
210317
210318
210319
210320
210321
210322
210323
210324
210325
210326
210327
210328
210329
210330
210331
210332
210333
210334
210335
210336
210337
210338
210339
210340
210341
210342
210343
210344
210345
210346
210347
210348
210349
210350
210351
210352
210353
210354
210355
210356
210357
210358
210359
210360
210361
210362
210363
210364
210365
210366
210367
210368
210369
210370
210371
210372
210373
210374
210375
210376
210377
210378
210379
210380
210381
210382
210383
210384
210385
210386
210387
210388
210389
210390
210391
210392
210393
210394
210395
210396
210397
210398
210399
210400
210401
210402
210403
210404
210405
210406
210407
210408
210409
210410
210411
210412
210413
210414
210415
210416
210417
210418
210419
210420
210421
210422
210423
210424
210425
210426
210427
210428
210429
210430
210431
210432
210433
210434
210435
210436
210437
210438
210439
210440
210441
210442
210443
210444
210445
210446
210447
210448
210449
210450
210451
210452
210453
210454
210455
210456
210457
210458
210459
210460
210461
210462
210463
210464
210465
210466
210467
210468
210469
210470
210471
210472
210473
210474
210475
210476
210477
210478
210479
210480
210481
210482
210483
210484
210485
210486
210487
210488
210489
210490
210491
210492
210493
210494
210495
210496
210497
210498
210499
210500
210501
210502
210503
210504
210505
210506
210507
210508
210509
210510
210511
210512
210513
210514
210515
210516
210517
210518
210519
210520
210521
210522
210523
210524
210525
210526
210527
210528
210529
210530
210531
210532
210533
210534
210535
210536
210537
210538
210539
210540
210541
210542
210543
210544
210545
210546
210547
210548
210549
210550
210551
210552
210553
210554
210555
210556
210557
210558
210559
210560
210561
210562
210563
210564
210565
210566
210567
210568
210569
210570
210571
210572
210573
210574
210575
210576
210577
210578
210579
210580
210581
210582
210583
210584
210585
210586
210587
210588
210589
210590
210591
210592
210593
210594
210595
210596
210597
210598
210599
210600
210601
210602
210603
210604
210605
210606
210607
210608
210609
210610
210611
210612
210613
210614
210615
210616
210617
210618
210619
210620
210621
210622
210623
210624
210625
210626
210627
210628
210629
210630
210631
210632
210633
210634
210635
210636
210637
210638
210639
210640
210641
210642
210643
210644
210645
210646
210647
210648
210649
210650
210651
210652
210653
210654
210655
210656
210657
210658
210659
210660
210661
210662
210663
210664
210665
210666
210667
210668
210669
210670
210671
210672
210673
210674
210675
210676
210677
210678
210679
210680
210681
210682
210683
210684
210685
210686
210687
210688
210689
210690
210691
210692
210693
210694
210695
210696
210697
210698
210699
210700
210701
210702
210703
210704
210705
210706
210707
210708
210709
210710
210711
210712
210713
210714
210715
210716
210717
210718
210719
210720
210721
210722
210723
210724
210725
210726
210727
210728
210729
210730
210731
210732
210733
210734
210735
210736
210737
210738
210739
210740
210741
210742
210743
210744
210745
210746
210747
210748
210749
210750
210751
210752
210753
210754
210755
210756
210757
210758
210759
210760
210761
210762
210763
210764
210765
210766
210767
210768
210769
210770
210771
210772
210773
210774
210775
210776
210777
210778
210779
210780
210781
210782
210783
210784
210785
210786
210787
210788
210789
210790
210791
210792
210793
210794
210795
210796
210797
210798
210799
210800
210801
210802
210803
210804
210805
210806
210807
210808
210809
210810
210811
210812
210813
210814
210815
210816
210817
210818
210819
210820
210821
210822
210823
210824
210825
210826
210827
210828
210829
210830
210831
210832
210833
210834
210835
210836
210837
210838
210839
210840
210841
210842
210843
210844
210845
210846
210847
210848
210849
210850
210851
210852
210853
210854
210855
210856
210857
210858
210859
210860
210861
210862
210863
210864
210865
210866
210867
210868
210869
210870
210871
210872
210873
210874
210875
210876
210877
210878
210879
210880
210881
210882
210883
210884
210885
210886
210887
210888
210889
210890
210891
210892
210893
210894
210895
210896
210897
210898
210899
210900
210901
210902
210903
210904
210905
210906
210907
210908
210909
210910
210911
210912
210913
210914
210915
210916
210917
210918
210919
210920
210921
210922
210923
210924
210925
210926
210927
210928
210929
210930
210931
210932
210933
210934
210935
210936
210937
210938
210939
210940
210941
210942
210943
210944
210945
210946
210947
210948
210949
210950
210951
210952
210953
210954
210955
210956
210957
210958
210959
210960
210961
210962
210963
210964
210965
210966
210967
210968
210969
210970
210971
210972
210973
210974
210975
210976
210977
210978
210979
210980
210981
210982
210983
210984
210985
210986
210987
210988
210989
210990
210991
210992
210993
210994
210995
210996
210997
210998
210999
211000
211001
211002
211003
211004
211005
211006
211007
211008
211009
211010
211011
211012
211013
211014
211015
211016
211017
211018
211019
211020
211021
211022
211023
211024
211025
211026
211027
211028
211029
211030
211031
211032
211033
211034
211035
211036
211037
211038
211039
211040
211041
211042
211043
211044
211045
211046
211047
211048
211049
211050
211051
211052
211053
211054
211055
211056
211057
211058
211059
211060
211061
211062
211063
211064
211065
211066
211067
211068
211069
211070
211071
211072
211073
211074
211075
211076
211077
211078
211079
211080
211081
211082
211083
211084
211085
211086
211087
211088
211089
211090
211091
211092
211093
211094
211095
211096
211097
211098
211099
211100
211101
211102
211103
211104
211105
211106
211107
211108
211109
211110
211111
211112
211113
211114
211115
211116
211117
211118
211119
211120
211121
211122
211123
211124
211125
211126
211127
211128
211129
211130
211131
211132
211133
211134
211135
211136
211137
211138
211139
211140
211141
211142
211143
211144
211145
211146
211147
211148
211149
211150
211151
211152
211153
211154
211155
211156
211157
211158
211159
211160
211161
211162
211163
211164
211165
211166
211167
211168
211169
211170
211171
211172
211173
211174
211175
211176
211177
211178
211179
211180
211181
211182
211183
211184
211185
211186
211187
211188
211189
211190
211191
211192
211193
211194
211195
211196
211197
211198
211199
211200
211201
211202
211203
211204
211205
211206
211207
211208
211209
211210
211211
211212
211213
211214
211215
211216
211217
211218
211219
211220
211221
211222
211223
211224
211225
211226
211227
211228
211229
211230
211231
211232
211233
211234
211235
211236
211237
211238
211239
211240
211241
211242
211243
211244
211245
211246
211247
211248
211249
211250
211251
211252
211253
211254
211255
211256
211257
211258
211259
211260
211261
211262
211263
211264
211265
211266
211267
211268
211269
211270
211271
211272
211273
211274
211275
211276
211277
211278
211279
211280
211281
211282
211283
211284
211285
211286
211287
211288
211289
211290
211291
211292
211293
211294
211295
211296
211297
211298
211299
211300
211301
211302
211303
211304
211305
211306
211307
211308
211309
211310
211311
211312
211313
211314
211315
211316
211317
211318
211319
211320
211321
211322
211323
211324
211325
211326
211327
211328
211329
211330
211331
211332
211333
211334
211335
211336
211337
211338
211339
211340
211341
211342
211343
211344
211345
211346
211347
211348
211349
211350
211351
211352
211353
211354
211355
211356
211357
211358
211359
211360
211361
211362
211363
211364
211365
211366
211367
211368
211369
211370
211371
211372
211373
211374
211375
211376
211377
211378
211379
211380
211381
211382
211383
211384
211385
211386
211387
211388
211389
211390
211391
211392
211393
211394
211395
211396
211397
211398
211399
211400
211401
211402
211403
211404
211405
211406
211407
211408
211409
211410
211411
211412
211413
211414
211415
211416
211417
211418
211419
211420
211421
211422
211423
211424
211425
211426
211427
211428
211429
211430
211431
211432
211433
211434
211435
211436
211437
211438
211439
211440
211441
211442
211443
211444
211445
211446
211447
211448
211449
211450
211451
211452
211453
211454
211455
211456
211457
211458
211459
211460
211461
211462
211463
211464
211465
211466
211467
211468
211469
211470
211471
211472
211473
211474
211475
211476
211477
211478
211479
211480
211481
211482
211483
211484
211485
211486
211487
211488
211489
211490
211491
211492
211493
211494
211495
211496
211497
211498
211499
211500
211501
211502
211503
211504
211505
211506
211507
211508
211509
211510
211511
211512
211513
211514
211515
211516
211517
211518
211519
211520
211521
211522
211523
211524
211525
211526
211527
211528
211529
211530
211531
211532
211533
211534
211535
211536
211537
211538
211539
211540
211541
211542
211543
211544
211545
211546
211547
211548
211549
211550
211551
211552
211553
211554
211555
211556
211557
211558
211559
211560
211561
211562
211563
211564
211565
211566
211567
211568
211569
211570
211571
211572
211573
211574
211575
211576
211577
211578
211579
211580
211581
211582
211583
211584
211585
211586
211587
211588
211589
211590
211591
211592
211593
211594
211595
211596
211597
211598
211599
211600
211601
211602
211603
211604
211605
211606
211607
211608
211609
211610
211611
211612
211613
211614
211615
211616
211617
211618
211619
211620
211621
211622
211623
211624
211625
211626
211627
211628
211629
211630
211631
211632
211633
211634
211635
211636
211637
211638
211639
211640
211641
211642
211643
211644
211645
211646
211647
211648
211649
211650
211651
211652
211653
211654
211655
211656
211657
211658
211659
211660
211661
211662
211663
211664
211665
211666
211667
211668
211669
211670
211671
211672
211673
211674
211675
211676
211677
211678
211679
211680
211681
211682
211683
211684
211685
211686
211687
211688
211689
211690
211691
211692
211693
211694
211695
211696
211697
211698
211699
211700
211701
211702
211703
211704
211705
211706
211707
211708
211709
211710
211711
211712
211713
211714
211715
211716
211717
211718
211719
211720
211721
211722
211723
211724
211725
211726
211727
211728
211729
211730
211731
211732
211733
211734
211735
211736
211737
211738
211739
211740
211741
211742
211743
211744
211745
211746
211747
211748
211749
211750
211751
211752
211753
211754
211755
211756
211757
211758
211759
211760
211761
211762
211763
211764
211765
211766
211767
211768
211769
211770
211771
211772
211773
211774
211775
211776
211777
211778
211779
211780
211781
211782
211783
211784
211785
211786
211787
211788
211789
211790
211791
211792
211793
211794
211795
211796
211797
211798
211799
211800
211801
211802
211803
211804
211805
211806
211807
211808
211809
211810
211811
211812
211813
211814
211815
211816
211817
211818
211819
211820
211821
211822
211823
211824
211825
211826
211827
211828
211829
211830
211831
211832
211833
211834
211835
211836
211837
211838
211839
211840
211841
211842
211843
211844
211845
211846
211847
211848
211849
211850
211851
211852
211853
211854
211855
211856
211857
211858
211859
211860
211861
211862
211863
211864
211865
211866
211867
211868
211869
211870
211871
211872
211873
211874
211875
211876
211877
211878
211879
211880
211881
211882
211883
211884
211885
211886
211887
211888
211889
211890
211891
211892
211893
211894
211895
211896
211897
211898
211899
211900
211901
211902
211903
211904
211905
211906
211907
211908
211909
211910
211911
211912
211913
211914
211915
211916
211917
211918
211919
211920
211921
211922
211923
211924
211925
211926
211927
211928
211929
211930
211931
211932
211933
211934
211935
211936
211937
211938
211939
211940
211941
211942
211943
211944
211945
211946
211947
211948
211949
211950
211951
211952
211953
211954
211955
211956
211957
211958
211959
211960
211961
211962
211963
211964
211965
211966
211967
211968
211969
211970
211971
211972
211973
211974
211975
211976
211977
211978
211979
211980
211981
211982
211983
211984
211985
211986
211987
211988
211989
211990
211991
211992
211993
211994
211995
211996
211997
211998
211999
212000
212001
212002
212003
212004
212005
212006
212007
212008
212009
212010
212011
212012
212013
212014
212015
212016
212017
212018
212019
212020
212021
212022
212023
212024
212025
212026
212027
212028
212029
212030
212031
212032
212033
212034
212035
212036
212037
212038
212039
212040
212041
212042
212043
212044
212045
212046
212047
212048
212049
212050
212051
212052
212053
212054
212055
212056
212057
212058
212059
212060
212061
212062
212063
212064
212065
212066
212067
212068
212069
212070
212071
212072
212073
212074
212075
212076
212077
212078
212079
212080
212081
212082
212083
212084
212085
212086
212087
212088
212089
212090
212091
212092
212093
212094
212095
212096
212097
212098
212099
212100
212101
212102
212103
212104
212105
212106
212107
212108
212109
212110
212111
212112
212113
212114
212115
212116
212117
212118
212119
212120
212121
212122
212123
212124
212125
212126
212127
212128
212129
212130
212131
212132
212133
212134
212135
212136
212137
212138
212139
212140
212141
212142
212143
212144
212145
212146
212147
212148
212149
212150
212151
212152
212153
212154
212155
212156
212157
212158
212159
212160
212161
212162
212163
212164
212165
212166
212167
212168
212169
212170
212171
212172
212173
212174
212175
212176
212177
212178
212179
212180
212181
212182
212183
212184
212185
212186
212187
212188
212189
212190
212191
212192
212193
212194
212195
212196
212197
212198
212199
212200
212201
212202
212203
212204
212205
212206
212207
212208
212209
212210
212211
212212
212213
212214
212215
212216
212217
212218
212219
212220
212221
212222
212223
212224
212225
212226
212227
212228
212229
212230
212231
212232
212233
212234
212235
212236
212237
212238
212239
212240
212241
212242
212243
212244
212245
212246
212247
212248
212249
212250
212251
212252
212253
212254
212255
212256
212257
212258
212259
212260
212261
212262
212263
212264
212265
212266
212267
212268
212269
212270
212271
212272
212273
212274
212275
212276
212277
212278
212279
212280
212281
212282
212283
212284
212285
212286
212287
212288
212289
212290
212291
212292
212293
212294
212295
212296
212297
212298
212299
212300
212301
212302
212303
212304
212305
212306
212307
212308
212309
212310
212311
212312
212313
212314
212315
212316
212317
212318
212319
212320
212321
212322
212323
212324
212325
212326
212327
212328
212329
212330
212331
212332
212333
212334
212335
212336
212337
212338
212339
212340
212341
212342
212343
212344
212345
212346
212347
212348
212349
212350
212351
212352
212353
212354
212355
212356
212357
212358
212359
212360
212361
212362
212363
212364
212365
212366
212367
212368
212369
212370
212371
212372
212373
212374
212375
212376
212377
212378
212379
212380
212381
212382
212383
212384
212385
212386
212387
212388
212389
212390
212391
212392
212393
212394
212395
212396
212397
212398
212399
212400
212401
212402
212403
212404
212405
212406
212407
212408
212409
212410
212411
212412
212413
212414
212415
212416
212417
212418
212419
212420
212421
212422
212423
212424
212425
212426
212427
212428
212429
212430
212431
212432
212433
212434
212435
212436
212437
212438
212439
212440
212441
212442
212443
212444
212445
212446
212447
212448
212449
212450
212451
212452
212453
212454
212455
212456
212457
212458
212459
212460
212461
212462
212463
212464
212465
212466
212467
212468
212469
212470
212471
212472
212473
212474
212475
212476
212477
212478
212479
212480
212481
212482
212483
212484
212485
212486
212487
212488
212489
212490
212491
212492
212493
212494
212495
212496
212497
212498
212499
212500
212501
212502
212503
212504
212505
212506
212507
212508
212509
212510
212511
212512
212513
212514
212515
212516
212517
212518
212519
212520
212521
212522
212523
212524
212525
212526
212527
212528
212529
212530
212531
212532
212533
212534
212535
212536
212537
212538
212539
212540
212541
212542
212543
212544
212545
212546
212547
212548
212549
212550
212551
212552
212553
212554
212555
212556
212557
212558
212559
212560
212561
212562
212563
212564
212565
212566
212567
212568
212569
212570
212571
212572
212573
212574
212575
212576
212577
212578
212579
212580
212581
212582
212583
212584
212585
212586
212587
212588
212589
212590
212591
212592
212593
212594
212595
212596
212597
212598
212599
212600
212601
212602
212603
212604
212605
212606
212607
212608
212609
212610
212611
212612
212613
212614
212615
212616
212617
212618
212619
212620
212621
212622
212623
212624
212625
212626
212627
212628
212629
212630
212631
212632
212633
212634
212635
212636
212637
212638
212639
212640
212641
212642
212643
212644
212645
212646
212647
212648
212649
212650
212651
212652
212653
212654
212655
212656
212657
212658
212659
212660
212661
212662
212663
212664
212665
212666
212667
212668
212669
212670
212671
212672
212673
212674
212675
212676
212677
212678
212679
212680
212681
212682
212683
212684
212685
212686
212687
212688
212689
212690
212691
212692
212693
212694
212695
212696
212697
212698
212699
212700
212701
212702
212703
212704
212705
212706
212707
212708
212709
212710
212711
212712
212713
212714
212715
212716
212717
212718
212719
212720
212721
212722
212723
212724
212725
212726
212727
212728
212729
212730
212731
212732
212733
212734
212735
212736
212737
212738
212739
212740
212741
212742
212743
212744
212745
212746
212747
212748
212749
212750
212751
212752
212753
212754
212755
212756
212757
212758
212759
212760
212761
212762
212763
212764
212765
212766
212767
212768
212769
212770
212771
212772
212773
212774
212775
212776
212777
212778
212779
212780
212781
212782
212783
212784
212785
212786
212787
212788
212789
212790
212791
212792
212793
212794
212795
212796
212797
212798
212799
212800
212801
212802
212803
212804
212805
212806
212807
212808
212809
212810
212811
212812
212813
212814
212815
212816
212817
212818
212819
212820
212821
212822
212823
212824
212825
212826
212827
212828
212829
212830
212831
212832
212833
212834
212835
212836
212837
212838
212839
212840
212841
212842
212843
212844
212845
212846
212847
212848
212849
212850
212851
212852
212853
212854
212855
212856
212857
212858
212859
212860
212861
212862
212863
212864
212865
212866
212867
212868
212869
212870
212871
212872
212873
212874
212875
212876
212877
212878
212879
212880
212881
212882
212883
212884
212885
212886
212887
212888
212889
212890
212891
212892
212893
212894
212895
212896
212897
212898
212899
212900
212901
212902
212903
212904
212905
212906
212907
212908
212909
212910
212911
212912
212913
212914
212915
212916
212917
212918
212919
212920
212921
212922
212923
212924
212925
212926
212927
212928
212929
212930
212931
212932
212933
212934
212935
212936
212937
212938
212939
212940
212941
212942
212943
212944
212945
212946
212947
212948
212949
212950
212951
212952
212953
212954
212955
212956
212957
212958
212959
212960
212961
212962
212963
212964
212965
212966
212967
212968
212969
212970
212971
212972
212973
212974
212975
212976
212977
212978
212979
212980
212981
212982
212983
212984
212985
212986
212987
212988
212989
212990
212991
212992
212993
212994
212995
212996
212997
212998
212999
213000
213001
213002
213003
213004
213005
213006
213007
213008
213009
213010
213011
213012
213013
213014
213015
213016
213017
213018
213019
213020
213021
213022
213023
213024
213025
213026
213027
213028
213029
213030
213031
213032
213033
213034
213035
213036
213037
213038
213039
213040
213041
213042
213043
213044
213045
213046
213047
213048
213049
213050
213051
213052
213053
213054
213055
213056
213057
213058
213059
213060
213061
213062
213063
213064
213065
213066
213067
213068
213069
213070
213071
213072
213073
213074
213075
213076
213077
213078
213079
213080
213081
213082
213083
213084
213085
213086
213087
213088
213089
213090
213091
213092
213093
213094
213095
213096
213097
213098
213099
213100
213101
213102
213103
213104
213105
213106
213107
213108
213109
213110
213111
213112
213113
213114
213115
213116
213117
213118
213119
213120
213121
213122
213123
213124
213125
213126
213127
213128
213129
213130
213131
213132
213133
213134
213135
213136
213137
213138
213139
213140
213141
213142
213143
213144
213145
213146
213147
213148
213149
213150
213151
213152
213153
213154
213155
213156
213157
213158
213159
213160
213161
213162
213163
213164
213165
213166
213167
213168
213169
213170
213171
213172
213173
213174
213175
213176
213177
213178
213179
213180
213181
213182
213183
213184
213185
213186
213187
213188
213189
213190
213191
213192
213193
213194
213195
213196
213197
213198
213199
213200
213201
213202
213203
213204
213205
213206
213207
213208
213209
213210
213211
213212
213213
213214
213215
213216
213217
213218
213219
213220
213221
213222
213223
213224
213225
213226
213227
213228
213229
213230
213231
213232
213233
213234
213235
213236
213237
213238
213239
213240
213241
213242
213243
213244
213245
213246
213247
213248
213249
213250
213251
213252
213253
213254
213255
213256
213257
213258
213259
213260
213261
213262
213263
213264
213265
213266
213267
213268
213269
213270
213271
213272
213273
213274
213275
213276
213277
213278
213279
213280
213281
213282
213283
213284
213285
213286
213287
213288
213289
213290
213291
213292
213293
213294
213295
213296
213297
213298
213299
213300
213301
213302
213303
213304
213305
213306
213307
213308
213309
213310
213311
213312
213313
213314
213315
213316
213317
213318
213319
213320
213321
213322
213323
213324
213325
213326
213327
213328
213329
213330
213331
213332
213333
213334
213335
213336
213337
213338
213339
213340
213341
213342
213343
213344
213345
213346
213347
213348
213349
213350
213351
213352
213353
213354
213355
213356
213357
213358
213359
213360
213361
213362
213363
213364
213365
213366
213367
213368
213369
213370
213371
213372
213373
213374
213375
213376
213377
213378
213379
213380
213381
213382
213383
213384
213385
213386
213387
213388
213389
213390
213391
213392
213393
213394
213395
213396
213397
213398
213399
213400
213401
213402
213403
213404
213405
213406
213407
213408
213409
213410
213411
213412
213413
213414
213415
213416
213417
213418
213419
213420
213421
213422
213423
213424
213425
213426
213427
213428
213429
213430
213431
213432
213433
213434
213435
213436
213437
213438
213439
213440
213441
213442
213443
213444
213445
213446
213447
213448
213449
213450
213451
213452
213453
213454
213455
213456
213457
213458
213459
213460
213461
213462
213463
213464
213465
213466
213467
213468
213469
213470
213471
213472
213473
213474
213475
213476
213477
213478
213479
213480
213481
213482
213483
213484
213485
213486
213487
213488
213489
213490
213491
213492
213493
213494
213495
213496
213497
213498
213499
213500
213501
213502
213503
213504
213505
213506
213507
213508
213509
213510
213511
213512
213513
213514
213515
213516
213517
213518
213519
213520
213521
213522
213523
213524
213525
213526
213527
213528
213529
213530
213531
213532
213533
213534
213535
213536
213537
213538
213539
213540
213541
213542
213543
213544
213545
213546
213547
213548
213549
213550
213551
213552
213553
213554
213555
213556
213557
213558
213559
213560
213561
213562
213563
213564
213565
213566
213567
213568
213569
213570
213571
213572
213573
213574
213575
213576
213577
213578
213579
213580
213581
213582
213583
213584
213585
213586
213587
213588
213589
213590
213591
213592
213593
213594
213595
213596
213597
213598
213599
213600
213601
213602
213603
213604
213605
213606
213607
213608
213609
213610
213611
213612
213613
213614
213615
213616
213617
213618
213619
213620
213621
213622
213623
213624
213625
213626
213627
213628
213629
213630
213631
213632
213633
213634
213635
213636
213637
213638
213639
213640
213641
213642
213643
213644
213645
213646
213647
213648
213649
213650
213651
213652
213653
213654
213655
213656
213657
213658
213659
213660
213661
213662
213663
213664
213665
213666
213667
213668
213669
213670
213671
213672
213673
213674
213675
213676
213677
213678
213679
213680
213681
213682
213683
213684
213685
213686
213687
213688
213689
213690
213691
213692
213693
213694
213695
213696
213697
213698
213699
213700
213701
213702
213703
213704
213705
213706
213707
213708
213709
213710
213711
213712
213713
213714
213715
213716
213717
213718
213719
213720
213721
213722
213723
213724
213725
213726
213727
213728
213729
213730
213731
213732
213733
213734
213735
213736
213737
213738
213739
213740
213741
213742
213743
213744
213745
213746
213747
213748
213749
213750
213751
213752
213753
213754
213755
213756
213757
213758
213759
213760
213761
213762
213763
213764
213765
213766
213767
213768
213769
213770
213771
213772
213773
213774
213775
213776
213777
213778
213779
213780
213781
213782
213783
213784
213785
213786
213787
213788
213789
213790
213791
213792
213793
213794
213795
213796
213797
213798
213799
213800
213801
213802
213803
213804
213805
213806
213807
213808
213809
213810
213811
213812
213813
213814
213815
213816
213817
213818
213819
213820
213821
213822
213823
213824
213825
213826
213827
213828
213829
213830
213831
213832
213833
213834
213835
213836
213837
213838
213839
213840
213841
213842
213843
213844
213845
213846
213847
213848
213849
213850
213851
213852
213853
213854
213855
213856
213857
213858
213859
213860
213861
213862
213863
213864
213865
213866
213867
213868
213869
213870
213871
213872
213873
213874
213875
213876
213877
213878
213879
213880
213881
213882
213883
213884
213885
213886
213887
213888
213889
213890
213891
213892
213893
213894
213895
213896
213897
213898
213899
213900
213901
213902
213903
213904
213905
213906
213907
213908
213909
213910
213911
213912
213913
213914
213915
213916
213917
213918
213919
213920
213921
213922
213923
213924
213925
213926
213927
213928
213929
213930
213931
213932
213933
213934
213935
213936
213937
213938
213939
213940
213941
213942
213943
213944
213945
213946
213947
213948
213949
213950
213951
213952
213953
213954
213955
213956
213957
213958
213959
213960
213961
213962
213963
213964
213965
213966
213967
213968
213969
213970
213971
213972
213973
213974
213975
213976
213977
213978
213979
213980
213981
213982
213983
213984
213985
213986
213987
213988
213989
213990
213991
213992
213993
213994
213995
213996
213997
213998
213999
214000
214001
214002
214003
214004
214005
214006
214007
214008
214009
214010
214011
214012
214013
214014
214015
214016
214017
214018
214019
214020
214021
214022
214023
214024
214025
214026
214027
214028
214029
214030
214031
214032
214033
214034
214035
214036
214037
214038
214039
214040
214041
214042
214043
214044
214045
214046
214047
214048
214049
214050
214051
214052
214053
214054
214055
214056
214057
214058
214059
214060
214061
214062
214063
214064
214065
214066
214067
214068
214069
214070
214071
214072
214073
214074
214075
214076
214077
214078
214079
214080
214081
214082
214083
214084
214085
214086
214087
214088
214089
214090
214091
214092
214093
214094
214095
214096
214097
214098
214099
214100
214101
214102
214103
214104
214105
214106
214107
214108
214109
214110
214111
214112
214113
214114
214115
214116
214117
214118
214119
214120
214121
214122
214123
214124
214125
214126
214127
214128
214129
214130
214131
214132
214133
214134
214135
214136
214137
214138
214139
214140
214141
214142
214143
214144
214145
214146
214147
214148
214149
214150
214151
214152
214153
214154
214155
214156
214157
214158
214159
214160
214161
214162
214163
214164
214165
214166
214167
214168
214169
214170
214171
214172
214173
214174
214175
214176
214177
214178
214179
214180
214181
214182
214183
214184
214185
214186
214187
214188
214189
214190
214191
214192
214193
214194
214195
214196
214197
214198
214199
214200
214201
214202
214203
214204
214205
214206
214207
214208
214209
214210
214211
214212
214213
214214
214215
214216
214217
214218
214219
214220
214221
214222
214223
214224
214225
214226
214227
214228
214229
214230
214231
214232
214233
214234
214235
214236
214237
214238
214239
214240
214241
214242
214243
214244
214245
214246
214247
214248
214249
214250
214251
214252
214253
214254
214255
214256
214257
214258
214259
214260
214261
214262
214263
214264
214265
214266
214267
214268
214269
214270
214271
214272
214273
214274
214275
214276
214277
214278
214279
214280
214281
214282
214283
214284
214285
214286
214287
214288
214289
214290
214291
214292
214293
214294
214295
214296
214297
214298
214299
214300
214301
214302
214303
214304
214305
214306
214307
214308
214309
214310
214311
214312
214313
214314
214315
214316
214317
214318
214319
214320
214321
214322
214323
214324
214325
214326
214327
214328
214329
214330
214331
214332
214333
214334
214335
214336
214337
214338
214339
214340
214341
214342
214343
214344
214345
214346
214347
214348
214349
214350
214351
214352
214353
214354
214355
214356
214357
214358
214359
214360
214361
214362
214363
214364
214365
214366
214367
214368
214369
214370
214371
214372
214373
214374
214375
214376
214377
214378
214379
214380
214381
214382
214383
214384
214385
214386
214387
214388
214389
214390
214391
214392
214393
214394
214395
214396
214397
214398
214399
214400
214401
214402
214403
214404
214405
214406
214407
214408
214409
214410
214411
214412
214413
214414
214415
214416
214417
214418
214419
214420
214421
214422
214423
214424
214425
214426
214427
214428
214429
214430
214431
214432
214433
214434
214435
214436
214437
214438
214439
214440
214441
214442
214443
214444
214445
214446
214447
214448
214449
214450
214451
214452
214453
214454
214455
214456
214457
214458
214459
214460
214461
214462
214463
214464
214465
214466
214467
214468
214469
214470
214471
214472
214473
214474
214475
214476
214477
214478
214479
214480
214481
214482
214483
214484
214485
214486
214487
214488
214489
214490
214491
214492
214493
214494
214495
214496
214497
214498
214499
214500
214501
214502
214503
214504
214505
214506
214507
214508
214509
214510
214511
214512
214513
214514
214515
214516
214517
214518
214519
214520
214521
214522
214523
214524
214525
214526
214527
214528
214529
214530
214531
214532
214533
214534
214535
214536
214537
214538
214539
214540
214541
214542
214543
214544
214545
214546
214547
214548
214549
214550
214551
214552
214553
214554
214555
214556
214557
214558
214559
214560
214561
214562
214563
214564
214565
214566
214567
214568
214569
214570
214571
214572
214573
214574
214575
214576
214577
214578
214579
214580
214581
214582
214583
214584
214585
214586
214587
214588
214589
214590
214591
214592
214593
214594
214595
214596
214597
214598
214599
214600
214601
214602
214603
214604
214605
214606
214607
214608
214609
214610
214611
214612
214613
214614
214615
214616
214617
214618
214619
214620
214621
214622
214623
214624
214625
214626
214627
214628
214629
214630
214631
214632
214633
214634
214635
214636
214637
214638
214639
214640
214641
214642
214643
214644
214645
214646
214647
214648
214649
214650
214651
214652
214653
214654
214655
214656
214657
214658
214659
214660
214661
214662
214663
214664
214665
214666
214667
214668
214669
214670
214671
214672
214673
214674
214675
214676
214677
214678
214679
214680
214681
214682
214683
214684
214685
214686
214687
214688
214689
214690
214691
214692
214693
214694
214695
214696
214697
214698
214699
214700
214701
214702
214703
214704
214705
214706
214707
214708
214709
214710
214711
214712
214713
214714
214715
214716
214717
214718
214719
214720
214721
214722
214723
214724
214725
214726
214727
214728
214729
214730
214731
214732
214733
214734
214735
214736
214737
214738
214739
214740
214741
214742
214743
214744
214745
214746
214747
214748
214749
214750
214751
214752
214753
214754
214755
214756
214757
214758
214759
214760
214761
214762
214763
214764
214765
214766
214767
214768
214769
214770
214771
214772
214773
214774
214775
214776
214777
214778
214779
214780
214781
214782
214783
214784
214785
214786
214787
214788
214789
214790
214791
214792
214793
214794
214795
214796
214797
214798
214799
214800
214801
214802
214803
214804
214805
214806
214807
214808
214809
214810
214811
214812
214813
214814
214815
214816
214817
214818
214819
214820
214821
214822
214823
214824
214825
214826
214827
214828
214829
214830
214831
214832
214833
214834
214835
214836
214837
214838
214839
214840
214841
214842
214843
214844
214845
214846
214847
214848
214849
214850
214851
214852
214853
214854
214855
214856
214857
214858
214859
214860
214861
214862
214863
214864
214865
214866
214867
214868
214869
214870
214871
214872
214873
214874
214875
214876
214877
214878
214879
214880
214881
214882
214883
214884
214885
214886
214887
214888
214889
214890
214891
214892
214893
214894
214895
214896
214897
214898
214899
214900
214901
214902
214903
214904
214905
214906
214907
214908
214909
214910
214911
214912
214913
214914
214915
214916
214917
214918
214919
214920
214921
214922
214923
214924
214925
214926
214927
214928
214929
214930
214931
214932
214933
214934
214935
214936
214937
214938
214939
214940
214941
214942
214943
214944
214945
214946
214947
214948
214949
214950
214951
214952
214953
214954
214955
214956
214957
214958
214959
214960
214961
214962
214963
214964
214965
214966
214967
214968
214969
214970
214971
214972
214973
214974
214975
214976
214977
214978
214979
214980
214981
214982
214983
214984
214985
214986
214987
214988
214989
214990
214991
214992
214993
214994
214995
214996
214997
214998
214999
215000
215001
215002
215003
215004
215005
215006
215007
215008
215009
215010
215011
215012
215013
215014
215015
215016
215017
215018
215019
215020
215021
215022
215023
215024
215025
215026
215027
215028
215029
215030
215031
215032
215033
215034
215035
215036
215037
215038
215039
215040
215041
215042
215043
215044
215045
215046
215047
215048
215049
215050
215051
215052
215053
215054
215055
215056
215057
215058
215059
215060
215061
215062
215063
215064
215065
215066
215067
215068
215069
215070
215071
215072
215073
215074
215075
215076
215077
215078
215079
215080
215081
215082
215083
215084
215085
215086
215087
215088
215089
215090
215091
215092
215093
215094
215095
215096
215097
215098
215099
215100
215101
215102
215103
215104
215105
215106
215107
215108
215109
215110
215111
215112
215113
215114
215115
215116
215117
215118
215119
215120
215121
215122
215123
215124
215125
215126
215127
215128
215129
215130
215131
215132
215133
215134
215135
215136
215137
215138
215139
215140
215141
215142
215143
215144
215145
215146
215147
215148
215149
215150
215151
215152
215153
215154
215155
215156
215157
215158
215159
215160
215161
215162
215163
215164
215165
215166
215167
215168
215169
215170
215171
215172
215173
215174
215175
215176
215177
215178
215179
215180
215181
215182
215183
215184
215185
215186
215187
215188
215189
215190
215191
215192
215193
215194
215195
215196
215197
215198
215199
215200
215201
215202
215203
215204
215205
215206
215207
215208
215209
215210
215211
215212
215213
215214
215215
215216
215217
215218
215219
215220
215221
215222
215223
215224
215225
215226
215227
215228
215229
215230
215231
215232
215233
215234
215235
215236
215237
215238
215239
215240
215241
215242
215243
215244
215245
215246
215247
215248
215249
215250
215251
215252
215253
215254
215255
215256
215257
215258
215259
215260
215261
215262
215263
215264
215265
215266
215267
215268
215269
215270
215271
215272
215273
215274
215275
215276
215277
215278
215279
215280
215281
215282
215283
215284
215285
215286
215287
215288
215289
215290
215291
215292
215293
215294
215295
215296
215297
215298
215299
215300
215301
215302
215303
215304
215305
215306
215307
215308
215309
215310
215311
215312
215313
215314
215315
215316
215317
215318
215319
215320
215321
215322
215323
215324
215325
215326
215327
215328
215329
215330
215331
215332
215333
215334
215335
215336
215337
215338
215339
215340
215341
215342
215343
215344
215345
215346
215347
215348
215349
215350
215351
215352
215353
215354
215355
215356
215357
215358
215359
215360
215361
215362
215363
215364
215365
215366
215367
215368
215369
215370
215371
215372
215373
215374
215375
215376
215377
215378
215379
215380
215381
215382
215383
215384
215385
215386
215387
215388
215389
215390
215391
215392
215393
215394
215395
215396
215397
215398
215399
215400
215401
215402
215403
215404
215405
215406
215407
215408
215409
215410
215411
215412
215413
215414
215415
215416
215417
215418
215419
215420
215421
215422
215423
215424
215425
215426
215427
215428
215429
215430
215431
215432
215433
215434
215435
215436
215437
215438
215439
215440
215441
215442
215443
215444
215445
215446
215447
215448
215449
215450
215451
215452
215453
215454
215455
215456
215457
215458
215459
215460
215461
215462
215463
215464
215465
215466
215467
215468
215469
215470
215471
215472
215473
215474
215475
215476
215477
215478
215479
215480
215481
215482
215483
215484
215485
215486
215487
215488
215489
215490
215491
215492
215493
215494
215495
215496
215497
215498
215499
215500
215501
215502
215503
215504
215505
215506
215507
215508
215509
215510
215511
215512
215513
215514
215515
215516
215517
215518
215519
215520
215521
215522
215523
215524
215525
215526
215527
215528
215529
215530
215531
215532
215533
215534
215535
215536
215537
215538
215539
215540
215541
215542
215543
215544
215545
215546
215547
215548
215549
215550
215551
215552
215553
215554
215555
215556
215557
215558
215559
215560
215561
215562
215563
215564
215565
215566
215567
215568
215569
215570
215571
215572
215573
215574
215575
215576
215577
215578
215579
215580
215581
215582
215583
215584
215585
215586
215587
215588
215589
215590
215591
215592
215593
215594
215595
215596
215597
215598
215599
215600
215601
215602
215603
215604
215605
215606
215607
215608
215609
215610
215611
215612
215613
215614
215615
215616
215617
215618
215619
215620
215621
215622
215623
215624
215625
215626
215627
215628
215629
215630
215631
215632
215633
215634
215635
215636
215637
215638
215639
215640
215641
215642
215643
215644
215645
215646
215647
215648
215649
215650
215651
215652
215653
215654
215655
215656
215657
215658
215659
215660
215661
215662
215663
215664
215665
215666
215667
215668
215669
215670
215671
215672
215673
215674
215675
215676
215677
215678
215679
215680
215681
215682
215683
215684
215685
215686
215687
215688
215689
215690
215691
215692
215693
215694
215695
215696
215697
215698
215699
215700
215701
215702
215703
215704
215705
215706
215707
215708
215709
215710
215711
215712
215713
215714
215715
215716
215717
215718
215719
215720
215721
215722
215723
215724
215725
215726
215727
215728
215729
215730
215731
215732
215733
215734
215735
215736
215737
215738
215739
215740
215741
215742
215743
215744
215745
215746
215747
215748
215749
215750
215751
215752
215753
215754
215755
215756
215757
215758
215759
215760
215761
215762
215763
215764
215765
215766
215767
215768
215769
215770
215771
215772
215773
215774
215775
215776
215777
215778
215779
215780
215781
215782
215783
215784
215785
215786
215787
215788
215789
215790
215791
215792
215793
215794
215795
215796
215797
215798
215799
215800
215801
215802
215803
215804
215805
215806
215807
215808
215809
215810
215811
215812
215813
215814
215815
215816
215817
215818
215819
215820
215821
215822
215823
215824
215825
215826
215827
215828
215829
215830
215831
215832
215833
215834
215835
215836
215837
215838
215839
215840
215841
215842
215843
215844
215845
215846
215847
215848
215849
215850
215851
215852
215853
215854
215855
215856
215857
215858
215859
215860
215861
215862
215863
215864
215865
215866
215867
215868
215869
215870
215871
215872
215873
215874
215875
215876
215877
215878
215879
215880
215881
215882
215883
215884
215885
215886
215887
215888
215889
215890
215891
215892
215893
215894
215895
215896
215897
215898
215899
215900
215901
215902
215903
215904
215905
215906
215907
215908
215909
215910
215911
215912
215913
215914
215915
215916
215917
215918
215919
215920
215921
215922
215923
215924
215925
215926
215927
215928
215929
215930
215931
215932
215933
215934
215935
215936
215937
215938
215939
215940
215941
215942
215943
215944
215945
215946
215947
215948
215949
215950
215951
215952
215953
215954
215955
215956
215957
215958
215959
215960
215961
215962
215963
215964
215965
215966
215967
215968
215969
215970
215971
215972
215973
215974
215975
215976
215977
215978
215979
215980
215981
215982
215983
215984
215985
215986
215987
215988
215989
215990
215991
215992
215993
215994
215995
215996
215997
215998
215999
216000
216001
216002
216003
216004
216005
216006
216007
216008
216009
216010
216011
216012
216013
216014
216015
216016
216017
216018
216019
216020
216021
216022
216023
216024
216025
216026
216027
216028
216029
216030
216031
216032
216033
216034
216035
216036
216037
216038
216039
216040
216041
216042
216043
216044
216045
216046
216047
216048
216049
216050
216051
216052
216053
216054
216055
216056
216057
216058
216059
216060
216061
216062
216063
216064
216065
216066
216067
216068
216069
216070
216071
216072
216073
216074
216075
216076
216077
216078
216079
216080
216081
216082
216083
216084
216085
216086
216087
216088
216089
216090
216091
216092
216093
216094
216095
216096
216097
216098
216099
216100
216101
216102
216103
216104
216105
216106
216107
216108
216109
216110
216111
216112
216113
216114
216115
216116
216117
216118
216119
216120
216121
216122
216123
216124
216125
216126
216127
216128
216129
216130
216131
216132
216133
216134
216135
216136
216137
216138
216139
216140
216141
216142
216143
216144
216145
216146
216147
216148
216149
216150
216151
216152
216153
216154
216155
216156
216157
216158
216159
216160
216161
216162
216163
216164
216165
216166
216167
216168
216169
216170
216171
216172
216173
216174
216175
216176
216177
216178
216179
216180
216181
216182
216183
216184
216185
216186
216187
216188
216189
216190
216191
216192
216193
216194
216195
216196
216197
216198
216199
216200
216201
216202
216203
216204
216205
216206
216207
216208
216209
216210
216211
216212
216213
216214
216215
216216
216217
216218
216219
216220
216221
216222
216223
216224
216225
216226
216227
216228
216229
216230
216231
216232
216233
216234
216235
216236
216237
216238
216239
216240
216241
216242
216243
216244
216245
216246
216247
216248
216249
216250
216251
216252
216253
216254
216255
216256
216257
216258
216259
216260
216261
216262
216263
216264
216265
216266
216267
216268
216269
216270
216271
216272
216273
216274
216275
216276
216277
216278
216279
216280
216281
216282
216283
216284
216285
216286
216287
216288
216289
216290
216291
216292
216293
216294
216295
216296
216297
216298
216299
216300
216301
216302
216303
216304
216305
216306
216307
216308
216309
216310
216311
216312
216313
216314
216315
216316
216317
216318
216319
216320
216321
216322
216323
216324
216325
216326
216327
216328
216329
216330
216331
216332
216333
216334
216335
216336
216337
216338
216339
216340
216341
216342
216343
216344
216345
216346
216347
216348
216349
216350
216351
216352
216353
216354
216355
216356
216357
216358
216359
216360
216361
216362
216363
216364
216365
216366
216367
216368
216369
216370
216371
216372
216373
216374
216375
216376
216377
216378
216379
216380
216381
216382
216383
216384
216385
216386
216387
216388
216389
216390
216391
216392
216393
216394
216395
216396
216397
216398
216399
216400
216401
216402
216403
216404
216405
216406
216407
216408
216409
216410
216411
216412
216413
216414
216415
216416
216417
216418
216419
216420
216421
216422
216423
216424
216425
216426
216427
216428
216429
216430
216431
216432
216433
216434
216435
216436
216437
216438
216439
216440
216441
216442
216443
216444
216445
216446
216447
216448
216449
216450
216451
216452
216453
216454
216455
216456
216457
216458
216459
216460
216461
216462
216463
216464
216465
216466
216467
216468
216469
216470
216471
216472
216473
216474
216475
216476
216477
216478
216479
216480
216481
216482
216483
216484
216485
216486
216487
216488
216489
216490
216491
216492
216493
216494
216495
216496
216497
216498
216499
216500
216501
216502
216503
216504
216505
216506
216507
216508
216509
216510
216511
216512
216513
216514
216515
216516
216517
216518
216519
216520
216521
216522
216523
216524
216525
216526
216527
216528
216529
216530
216531
216532
216533
216534
216535
216536
216537
216538
216539
216540
216541
216542
216543
216544
216545
216546
216547
216548
216549
216550
216551
216552
216553
216554
216555
216556
216557
216558
216559
216560
216561
216562
216563
216564
216565
216566
216567
216568
216569
216570
216571
216572
216573
216574
216575
216576
216577
216578
216579
216580
216581
216582
216583
216584
216585
216586
216587
216588
216589
216590
216591
216592
216593
216594
216595
216596
216597
216598
216599
216600
216601
216602
216603
216604
216605
216606
216607
216608
216609
216610
216611
216612
216613
216614
216615
216616
216617
216618
216619
216620
216621
216622
216623
216624
216625
216626
216627
216628
216629
216630
216631
216632
216633
216634
216635
216636
216637
216638
216639
216640
216641
216642
216643
216644
216645
216646
216647
216648
216649
216650
216651
216652
216653
216654
216655
216656
216657
216658
216659
216660
216661
216662
216663
216664
216665
216666
216667
216668
216669
216670
216671
216672
216673
216674
216675
216676
216677
216678
216679
216680
216681
216682
216683
216684
216685
216686
216687
216688
216689
216690
216691
216692
216693
216694
216695
216696
216697
216698
216699
216700
216701
216702
216703
216704
216705
216706
216707
216708
216709
216710
216711
216712
216713
216714
216715
216716
216717
216718
216719
216720
216721
216722
216723
216724
216725
216726
216727
216728
216729
216730
216731
216732
216733
216734
216735
216736
216737
216738
216739
216740
216741
216742
216743
216744
216745
216746
216747
216748
216749
216750
216751
216752
216753
216754
216755
216756
216757
216758
216759
216760
216761
216762
216763
216764
216765
216766
216767
216768
216769
216770
216771
216772
216773
216774
216775
216776
216777
216778
216779
216780
216781
216782
216783
216784
216785
216786
216787
216788
216789
216790
216791
216792
216793
216794
216795
216796
216797
216798
216799
216800
216801
216802
216803
216804
216805
216806
216807
216808
216809
216810
216811
216812
216813
216814
216815
216816
216817
216818
216819
216820
216821
216822
216823
216824
216825
216826
216827
216828
216829
216830
216831
216832
216833
216834
216835
216836
216837
216838
216839
216840
216841
216842
216843
216844
216845
216846
216847
216848
216849
216850
216851
216852
216853
216854
216855
216856
216857
216858
216859
216860
216861
216862
216863
216864
216865
216866
216867
216868
216869
216870
216871
216872
216873
216874
216875
216876
216877
216878
216879
216880
216881
216882
216883
216884
216885
216886
216887
216888
216889
216890
216891
216892
216893
216894
216895
216896
216897
216898
216899
216900
216901
216902
216903
216904
216905
216906
216907
216908
216909
216910
216911
216912
216913
216914
216915
216916
216917
216918
216919
216920
216921
216922
216923
216924
216925
216926
216927
216928
216929
216930
216931
216932
216933
216934
216935
216936
216937
216938
216939
216940
216941
216942
216943
216944
216945
216946
216947
216948
216949
216950
216951
216952
216953
216954
216955
216956
216957
216958
216959
216960
216961
216962
216963
216964
216965
216966
216967
216968
216969
216970
216971
216972
216973
216974
216975
216976
216977
216978
216979
216980
216981
216982
216983
216984
216985
216986
216987
216988
216989
216990
216991
216992
216993
216994
216995
216996
216997
216998
216999
217000
217001
217002
217003
217004
217005
217006
217007
217008
217009
217010
217011
217012
217013
217014
217015
217016
217017
217018
217019
217020
217021
217022
217023
217024
217025
217026
217027
217028
217029
217030
217031
217032
217033
217034
217035
217036
217037
217038
217039
217040
217041
217042
217043
217044
217045
217046
217047
217048
217049
217050
217051
217052
217053
217054
217055
217056
217057
217058
217059
217060
217061
217062
217063
217064
217065
217066
217067
217068
217069
217070
217071
217072
217073
217074
217075
217076
217077
217078
217079
217080
217081
217082
217083
217084
217085
217086
217087
217088
217089
217090
217091
217092
217093
217094
217095
217096
217097
217098
217099
217100
217101
217102
217103
217104
217105
217106
217107
217108
217109
217110
217111
217112
217113
217114
217115
217116
217117
217118
217119
217120
217121
217122
217123
217124
217125
217126
217127
217128
217129
217130
217131
217132
217133
217134
217135
217136
217137
217138
217139
217140
217141
217142
217143
217144
217145
217146
217147
217148
217149
217150
217151
217152
217153
217154
217155
217156
217157
217158
217159
217160
217161
217162
217163
217164
217165
217166
217167
217168
217169
217170
217171
217172
217173
217174
217175
217176
217177
217178
217179
217180
217181
217182
217183
217184
217185
217186
217187
217188
217189
217190
217191
217192
217193
217194
217195
217196
217197
217198
217199
217200
217201
217202
217203
217204
217205
217206
217207
217208
217209
217210
217211
217212
217213
217214
217215
217216
217217
217218
217219
217220
217221
217222
217223
217224
217225
217226
217227
217228
217229
217230
217231
217232
217233
217234
217235
217236
217237
217238
217239
217240
217241
217242
217243
217244
217245
217246
217247
217248
217249
217250
217251
217252
217253
217254
217255
217256
217257
217258
217259
217260
217261
217262
217263
217264
217265
217266
217267
217268
217269
217270
217271
217272
217273
217274
217275
217276
217277
217278
217279
217280
217281
217282
217283
217284
217285
217286
217287
217288
217289
217290
217291
217292
217293
217294
217295
217296
217297
217298
217299
217300
217301
217302
217303
217304
217305
217306
217307
217308
217309
217310
217311
217312
217313
217314
217315
217316
217317
217318
217319
217320
217321
217322
217323
217324
217325
217326
217327
217328
217329
217330
217331
217332
217333
217334
217335
217336
217337
217338
217339
217340
217341
217342
217343
217344
217345
217346
217347
217348
217349
217350
217351
217352
217353
217354
217355
217356
217357
217358
217359
217360
217361
217362
217363
217364
217365
217366
217367
217368
217369
217370
217371
217372
217373
217374
217375
217376
217377
217378
217379
217380
217381
217382
217383
217384
217385
217386
217387
217388
217389
217390
217391
217392
217393
217394
217395
217396
217397
217398
217399
217400
217401
217402
217403
217404
217405
217406
217407
217408
217409
217410
217411
217412
217413
217414
217415
217416
217417
217418
217419
217420
217421
217422
217423
217424
217425
217426
217427
217428
217429
217430
217431
217432
217433
217434
217435
217436
217437
217438
217439
217440
217441
217442
217443
217444
217445
217446
217447
217448
217449
217450
217451
217452
217453
217454
217455
217456
217457
217458
217459
217460
217461
217462
217463
217464
217465
217466
217467
217468
217469
217470
217471
217472
217473
217474
217475
217476
217477
217478
217479
217480
217481
217482
217483
217484
217485
217486
217487
217488
217489
217490
217491
217492
217493
217494
217495
217496
217497
217498
217499
217500
217501
217502
217503
217504
217505
217506
217507
217508
217509
217510
217511
217512
217513
217514
217515
217516
217517
217518
217519
217520
217521
217522
217523
217524
217525
217526
217527
217528
217529
217530
217531
217532
217533
217534
217535
217536
217537
217538
217539
217540
217541
217542
217543
217544
217545
217546
217547
217548
217549
217550
217551
217552
217553
217554
217555
217556
217557
217558
217559
217560
217561
217562
217563
217564
217565
217566
217567
217568
217569
217570
217571
217572
217573
217574
217575
217576
217577
217578
217579
217580
217581
217582
217583
217584
217585
217586
217587
217588
217589
217590
217591
217592
217593
217594
217595
217596
217597
217598
217599
217600
217601
217602
217603
217604
217605
217606
217607
217608
217609
217610
217611
217612
217613
217614
217615
217616
217617
217618
217619
217620
217621
217622
217623
217624
217625
217626
217627
217628
217629
217630
217631
217632
217633
217634
217635
217636
217637
217638
217639
217640
217641
217642
217643
217644
217645
217646
217647
217648
217649
217650
217651
217652
217653
217654
217655
217656
217657
217658
217659
217660
217661
217662
217663
217664
217665
217666
217667
217668
217669
217670
217671
217672
217673
217674
217675
217676
217677
217678
217679
217680
217681
217682
217683
217684
217685
217686
217687
217688
217689
217690
217691
217692
217693
217694
217695
217696
217697
217698
217699
217700
217701
217702
217703
217704
217705
217706
217707
217708
217709
217710
217711
217712
217713
217714
217715
217716
217717
217718
217719
217720
217721
217722
217723
217724
217725
217726
217727
217728
217729
217730
217731
217732
217733
217734
217735
217736
217737
217738
217739
217740
217741
217742
217743
217744
217745
217746
217747
217748
217749
217750
217751
217752
217753
217754
217755
217756
217757
217758
217759
217760
217761
217762
217763
217764
217765
217766
217767
217768
217769
217770
217771
217772
217773
217774
217775
217776
217777
217778
217779
217780
217781
217782
217783
217784
217785
217786
217787
217788
217789
217790
217791
217792
217793
217794
217795
217796
217797
217798
217799
217800
217801
217802
217803
217804
217805
217806
217807
217808
217809
217810
217811
217812
217813
217814
217815
217816
217817
217818
217819
217820
217821
217822
217823
217824
217825
217826
217827
217828
217829
217830
217831
217832
217833
217834
217835
217836
217837
217838
217839
217840
217841
217842
217843
217844
217845
217846
217847
217848
217849
217850
217851
217852
217853
217854
217855
217856
217857
217858
217859
217860
217861
217862
217863
217864
217865
217866
217867
217868
217869
217870
217871
217872
217873
217874
217875
217876
217877
217878
217879
217880
217881
217882
217883
217884
217885
217886
217887
217888
217889
217890
217891
217892
217893
217894
217895
217896
217897
217898
217899
217900
217901
217902
217903
217904
217905
217906
217907
217908
217909
217910
217911
217912
217913
217914
217915
217916
217917
217918
217919
217920
217921
217922
217923
217924
217925
217926
217927
217928
217929
217930
217931
217932
217933
217934
217935
217936
217937
217938
217939
217940
217941
217942
217943
217944
217945
217946
217947
217948
217949
217950
217951
217952
217953
217954
217955
217956
217957
217958
217959
217960
217961
217962
217963
217964
217965
217966
217967
217968
217969
217970
217971
217972
217973
217974
217975
217976
217977
217978
217979
217980
217981
217982
217983
217984
217985
217986
217987
217988
217989
217990
217991
217992
217993
217994
217995
217996
217997
217998
217999
218000
218001
218002
218003
218004
218005
218006
218007
218008
218009
218010
218011
218012
218013
218014
218015
218016
218017
218018
218019
218020
218021
218022
218023
218024
218025
218026
218027
218028
218029
218030
218031
218032
218033
218034
218035
218036
218037
218038
218039
218040
218041
218042
218043
218044
218045
218046
218047
218048
218049
218050
218051
218052
218053
218054
218055
218056
218057
218058
218059
218060
218061
218062
218063
218064
218065
218066
218067
218068
218069
218070
218071
218072
218073
218074
218075
218076
218077
218078
218079
218080
218081
218082
218083
218084
218085
218086
218087
218088
218089
218090
218091
218092
218093
218094
218095
218096
218097
218098
218099
218100
218101
218102
218103
218104
218105
218106
218107
218108
218109
218110
218111
218112
218113
218114
218115
218116
218117
218118
218119
218120
218121
218122
218123
218124
218125
218126
218127
218128
218129
218130
218131
218132
218133
218134
218135
218136
218137
218138
218139
218140
218141
218142
218143
218144
218145
218146
218147
218148
218149
218150
218151
218152
218153
218154
218155
218156
218157
218158
218159
218160
218161
218162
218163
218164
218165
218166
218167
218168
218169
218170
218171
218172
218173
218174
218175
218176
218177
218178
218179
218180
218181
218182
218183
218184
218185
218186
218187
218188
218189
218190
218191
218192
218193
218194
218195
218196
218197
218198
218199
218200
218201
218202
218203
218204
218205
218206
218207
218208
218209
218210
218211
218212
218213
218214
218215
218216
218217
218218
218219
218220
218221
218222
218223
218224
218225
218226
218227
218228
218229
218230
218231
218232
218233
218234
218235
218236
218237
218238
218239
218240
218241
218242
218243
218244
218245
218246
218247
218248
218249
218250
218251
218252
218253
218254
218255
218256
218257
218258
218259
218260
218261
218262
218263
218264
218265
218266
218267
218268
218269
218270
218271
218272
218273
218274
218275
218276
218277
218278
218279
218280
218281
218282
218283
218284
218285
218286
218287
218288
218289
218290
218291
218292
218293
218294
218295
218296
218297
218298
218299
218300
218301
218302
218303
218304
218305
218306
218307
218308
218309
218310
218311
218312
218313
218314
218315
218316
218317
218318
218319
218320
218321
218322
218323
218324
218325
218326
218327
218328
218329
218330
218331
218332
218333
218334
218335
218336
218337
218338
218339
218340
218341
218342
218343
218344
218345
218346
218347
218348
218349
218350
218351
218352
218353
218354
218355
218356
218357
218358
218359
218360
218361
218362
218363
218364
218365
218366
218367
218368
218369
218370
218371
218372
218373
218374
218375
218376
218377
218378
218379
218380
218381
218382
218383
218384
218385
218386
218387
218388
218389
218390
218391
218392
218393
218394
218395
218396
218397
218398
218399
218400
218401
218402
218403
218404
218405
218406
218407
218408
218409
218410
218411
218412
218413
218414
218415
218416
218417
218418
218419
218420
218421
218422
218423
218424
218425
218426
218427
218428
218429
218430
218431
218432
218433
218434
218435
218436
218437
218438
218439
218440
218441
218442
218443
218444
218445
218446
218447
218448
218449
218450
218451
218452
218453
218454
218455
218456
218457
218458
218459
218460
218461
218462
218463
218464
218465
218466
218467
218468
218469
218470
218471
218472
218473
218474
218475
218476
218477
218478
218479
218480
218481
218482
218483
218484
218485
218486
218487
218488
218489
218490
218491
218492
218493
218494
218495
218496
218497
218498
218499
218500
218501
218502
218503
218504
218505
218506
218507
218508
218509
218510
218511
218512
218513
218514
218515
218516
218517
218518
218519
218520
218521
218522
218523
218524
218525
218526
218527
218528
218529
218530
218531
218532
218533
218534
218535
218536
218537
218538
218539
218540
218541
218542
218543
218544
218545
218546
218547
218548
218549
218550
218551
218552
218553
218554
218555
218556
218557
218558
218559
218560
218561
218562
218563
218564
218565
218566
218567
218568
218569
218570
218571
218572
218573
218574
218575
218576
218577
218578
218579
218580
218581
218582
218583
218584
218585
218586
218587
218588
218589
218590
218591
218592
218593
218594
218595
218596
218597
218598
218599
218600
218601
218602
218603
218604
218605
218606
218607
218608
218609
218610
218611
218612
218613
218614
218615
218616
218617
218618
218619
218620
218621
218622
218623
218624
218625
218626
218627
218628
218629
218630
218631
218632
218633
218634
218635
218636
218637
218638
218639
218640
218641
218642
218643
218644
218645
218646
218647
218648
218649
218650
218651
218652
218653
218654
218655
218656
218657
218658
218659
218660
218661
218662
218663
218664
218665
218666
218667
218668
218669
218670
218671
218672
218673
218674
218675
218676
218677
218678
218679
218680
218681
218682
218683
218684
218685
218686
218687
218688
218689
218690
218691
218692
218693
218694
218695
218696
218697
218698
218699
218700
218701
218702
218703
218704
218705
218706
218707
218708
218709
218710
218711
218712
218713
218714
218715
218716
218717
218718
218719
218720
218721
218722
218723
218724
218725
218726
218727
218728
218729
218730
218731
218732
218733
218734
218735
218736
218737
218738
218739
218740
218741
218742
218743
218744
218745
218746
218747
218748
218749
218750
218751
218752
218753
218754
218755
218756
218757
218758
218759
218760
218761
218762
218763
218764
218765
218766
218767
218768
218769
218770
218771
218772
218773
218774
218775
218776
218777
218778
218779
218780
218781
218782
218783
218784
218785
218786
218787
218788
218789
218790
218791
218792
218793
218794
218795
218796
218797
218798
218799
218800
218801
218802
218803
218804
218805
218806
218807
218808
218809
218810
218811
218812
218813
218814
218815
218816
218817
218818
218819
218820
218821
218822
218823
218824
218825
218826
218827
218828
218829
218830
218831
218832
218833
218834
218835
218836
218837
218838
218839
218840
218841
218842
218843
218844
218845
218846
218847
218848
218849
218850
218851
218852
218853
218854
218855
218856
218857
218858
218859
218860
218861
218862
218863
218864
218865
218866
218867
218868
218869
218870
218871
218872
218873
218874
218875
218876
218877
218878
218879
218880
218881
218882
218883
218884
218885
218886
218887
218888
218889
218890
218891
218892
218893
218894
218895
218896
218897
218898
218899
218900
218901
218902
218903
218904
218905
218906
218907
218908
218909
218910
218911
218912
218913
218914
218915
218916
218917
218918
218919
218920
218921
218922
218923
218924
218925
218926
218927
218928
218929
218930
218931
218932
218933
218934
218935
218936
218937
218938
218939
218940
218941
218942
218943
218944
218945
218946
218947
218948
218949
218950
218951
218952
218953
218954
218955
218956
218957
218958
218959
218960
218961
218962
218963
218964
218965
218966
218967
218968
218969
218970
218971
218972
218973
218974
218975
218976
218977
218978
218979
218980
218981
218982
218983
218984
218985
218986
218987
218988
218989
218990
218991
218992
218993
218994
218995
218996
218997
218998
218999
219000
219001
219002
219003
219004
219005
219006
219007
219008
219009
219010
219011
219012
219013
219014
219015
219016
219017
219018
219019
219020
219021
219022
219023
219024
219025
219026
219027
219028
219029
219030
219031
219032
219033
219034
219035
219036
219037
219038
219039
219040
219041
219042
219043
219044
219045
219046
219047
219048
219049
219050
219051
219052
219053
219054
219055
219056
219057
219058
219059
219060
219061
219062
219063
219064
219065
219066
219067
219068
219069
219070
219071
219072
219073
219074
219075
219076
219077
219078
219079
219080
219081
219082
219083
219084
219085
219086
219087
219088
219089
219090
219091
219092
219093
219094
219095
219096
219097
219098
219099
219100
219101
219102
219103
219104
219105
219106
219107
219108
219109
219110
219111
219112
219113
219114
219115
219116
219117
219118
219119
219120
219121
219122
219123
219124
219125
219126
219127
219128
219129
219130
219131
219132
219133
219134
219135
219136
219137
219138
219139
219140
219141
219142
219143
219144
219145
219146
219147
219148
219149
219150
219151
219152
219153
219154
219155
219156
219157
219158
219159
219160
219161
219162
219163
219164
219165
219166
219167
219168
219169
219170
219171
219172
219173
219174
219175
219176
219177
219178
219179
219180
219181
219182
219183
219184
219185
219186
219187
219188
219189
219190
219191
219192
219193
219194
219195
219196
219197
219198
219199
219200
219201
219202
219203
219204
219205
219206
219207
219208
219209
219210
219211
219212
219213
219214
219215
219216
219217
219218
219219
219220
219221
219222
219223
219224
219225
219226
219227
219228
219229
219230
219231
219232
219233
219234
219235
219236
219237
219238
219239
219240
219241
219242
219243
219244
219245
219246
219247
219248
219249
219250
219251
219252
219253
219254
219255
219256
219257
219258
219259
219260
219261
219262
219263
219264
219265
219266
219267
219268
219269
219270
219271
219272
219273
219274
219275
219276
219277
219278
219279
219280
219281
219282
219283
219284
219285
219286
219287
219288
219289
219290
219291
219292
219293
219294
219295
219296
219297
219298
219299
219300
219301
219302
219303
219304
219305
219306
219307
219308
219309
219310
219311
219312
219313
219314
219315
219316
219317
219318
219319
219320
219321
219322
219323
219324
219325
219326
219327
219328
219329
219330
219331
219332
219333
219334
219335
219336
219337
219338
219339
219340
219341
219342
219343
219344
219345
219346
219347
219348
219349
219350
219351
219352
219353
219354
219355
219356
219357
219358
219359
219360
219361
219362
219363
219364
219365
219366
219367
219368
219369
219370
219371
219372
219373
219374
219375
219376
219377
219378
219379
219380
219381
219382
219383
219384
219385
219386
219387
219388
219389
219390
219391
219392
219393
219394
219395
219396
219397
219398
219399
219400
219401
219402
219403
219404
219405
219406
219407
219408
219409
219410
219411
219412
219413
219414
219415
219416
219417
219418
219419
219420
219421
219422
219423
219424
219425
219426
219427
219428
219429
219430
219431
219432
219433
219434
219435
219436
219437
219438
219439
219440
219441
219442
219443
219444
219445
219446
219447
219448
219449
219450
219451
219452
219453
219454
219455
219456
219457
219458
219459
219460
219461
219462
219463
219464
219465
219466
219467
219468
219469
219470
219471
219472
219473
219474
219475
219476
219477
219478
219479
219480
219481
219482
219483
219484
219485
219486
219487
219488
219489
219490
219491
219492
219493
219494
219495
219496
219497
219498
219499
219500
219501
219502
219503
219504
219505
219506
219507
219508
219509
219510
219511
219512
219513
219514
219515
219516
219517
219518
219519
219520
219521
219522
219523
219524
219525
219526
219527
219528
219529
219530
219531
219532
219533
219534
219535
219536
219537
219538
219539
219540
219541
219542
219543
219544
219545
219546
219547
219548
219549
219550
219551
219552
219553
219554
219555
219556
219557
219558
219559
219560
219561
219562
219563
219564
219565
219566
219567
219568
219569
219570
219571
219572
219573
219574
219575
219576
219577
219578
219579
219580
219581
219582
219583
219584
219585
219586
219587
219588
219589
219590
219591
219592
219593
219594
219595
219596
219597
219598
219599
219600
219601
219602
219603
219604
219605
219606
219607
219608
219609
219610
219611
219612
219613
219614
219615
219616
219617
219618
219619
219620
219621
219622
219623
219624
219625
219626
219627
219628
219629
219630
219631
219632
219633
219634
219635
219636
219637
219638
219639
219640
219641
219642
219643
219644
219645
219646
219647
219648
219649
219650
219651
219652
219653
219654
219655
219656
219657
219658
219659
219660
219661
219662
219663
219664
219665
219666
219667
219668
219669
219670
219671
219672
219673
219674
219675
219676
219677
219678
219679
219680
219681
219682
219683
219684
219685
219686
219687
219688
219689
219690
219691
219692
219693
219694
219695
219696
219697
219698
219699
219700
219701
219702
219703
219704
219705
219706
219707
219708
219709
219710
219711
219712
219713
219714
219715
219716
219717
219718
219719
219720
219721
219722
219723
219724
219725
219726
219727
219728
219729
219730
219731
219732
219733
219734
219735
219736
219737
219738
219739
219740
219741
219742
219743
219744
219745
219746
219747
219748
219749
219750
219751
219752
219753
219754
219755
219756
219757
219758
219759
219760
219761
219762
219763
219764
219765
219766
219767
219768
219769
219770
219771
219772
219773
219774
219775
219776
219777
219778
219779
219780
219781
219782
219783
219784
219785
219786
219787
219788
219789
219790
219791
219792
219793
219794
219795
219796
219797
219798
219799
219800
219801
219802
219803
219804
219805
219806
219807
219808
219809
219810
219811
219812
219813
219814
219815
219816
219817
219818
219819
219820
219821
219822
219823
219824
219825
219826
219827
219828
219829
219830
219831
219832
219833
219834
219835
219836
219837
219838
219839
219840
219841
219842
219843
219844
219845
219846
219847
219848
219849
219850
219851
219852
219853
219854
219855
219856
219857
219858
219859
219860
219861
219862
219863
219864
219865
219866
219867
219868
219869
219870
219871
219872
219873
219874
219875
219876
219877
219878
219879
219880
219881
219882
219883
219884
219885
219886
219887
219888
219889
219890
219891
219892
219893
219894
219895
219896
219897
219898
219899
219900
219901
219902
219903
219904
219905
219906
219907
219908
219909
219910
219911
219912
219913
219914
219915
219916
219917
219918
219919
219920
219921
219922
219923
219924
219925
219926
219927
219928
219929
219930
219931
219932
219933
219934
219935
219936
219937
219938
219939
219940
219941
219942
219943
219944
219945
219946
219947
219948
219949
219950
219951
219952
219953
219954
219955
219956
219957
219958
219959
219960
219961
219962
219963
219964
219965
219966
219967
219968
219969
219970
219971
219972
219973
219974
219975
219976
219977
219978
219979
219980
219981
219982
219983
219984
219985
219986
219987
219988
219989
219990
219991
219992
219993
219994
219995
219996
219997
219998
219999
220000
220001
220002
220003
220004
220005
220006
220007
220008
220009
220010
220011
220012
220013
220014
220015
220016
220017
220018
220019
220020
220021
220022
220023
220024
220025
220026
220027
220028
220029
220030
220031
220032
220033
220034
220035
220036
220037
220038
220039
220040
220041
220042
220043
220044
220045
220046
220047
220048
220049
220050
220051
220052
220053
220054
220055
220056
220057
220058
220059
220060
220061
220062
220063
220064
220065
220066
220067
220068
220069
220070
220071
220072
220073
220074
220075
220076
220077
220078
220079
220080
220081
220082
220083
220084
220085
220086
220087
220088
220089
220090
220091
220092
220093
220094
220095
220096
220097
220098
220099
220100
220101
220102
220103
220104
220105
220106
220107
220108
220109
220110
220111
220112
220113
220114
220115
220116
220117
220118
220119
220120
220121
220122
220123
220124
220125
220126
220127
220128
220129
220130
220131
220132
220133
220134
220135
220136
220137
220138
220139
220140
220141
220142
220143
220144
220145
220146
220147
220148
220149
220150
220151
220152
220153
220154
220155
220156
220157
220158
220159
220160
220161
220162
220163
220164
220165
220166
220167
220168
220169
220170
220171
220172
220173
220174
220175
220176
220177
220178
220179
220180
220181
220182
220183
220184
220185
220186
220187
220188
220189
220190
220191
220192
220193
220194
220195
220196
220197
220198
220199
220200
220201
220202
220203
220204
220205
220206
220207
220208
220209
220210
220211
220212
220213
220214
220215
220216
220217
220218
220219
220220
220221
220222
220223
220224
220225
220226
220227
220228
220229
220230
220231
220232
220233
220234
220235
220236
220237
220238
220239
220240
220241
220242
220243
220244
220245
220246
220247
220248
220249
220250
220251
220252
220253
220254
220255
220256
220257
220258
220259
220260
220261
220262
220263
220264
220265
220266
220267
220268
220269
220270
220271
220272
220273
220274
220275
220276
220277
220278
220279
220280
220281
220282
220283
220284
220285
220286
220287
220288
220289
220290
220291
220292
220293
220294
220295
220296
220297
220298
220299
220300
220301
220302
220303
220304
220305
220306
220307
220308
220309
220310
220311
220312
220313
220314
220315
220316
220317
220318
220319
220320
220321
220322
220323
220324
220325
220326
220327
220328
220329
220330
220331
220332
220333
220334
220335
220336
220337
220338
220339
220340
220341
220342
220343
220344
220345
220346
220347
220348
220349
220350
220351
220352
220353
220354
220355
220356
220357
220358
220359
220360
220361
220362
220363
220364
220365
220366
220367
220368
220369
220370
220371
220372
220373
220374
220375
220376
220377
220378
220379
220380
220381
220382
220383
220384
220385
220386
220387
220388
220389
220390
220391
220392
220393
220394
220395
220396
220397
220398
220399
220400
220401
220402
220403
220404
220405
220406
220407
220408
220409
220410
220411
220412
220413
220414
220415
220416
220417
220418
220419
220420
220421
220422
220423
220424
220425
220426
220427
220428
220429
220430
220431
220432
220433
220434
220435
220436
220437
220438
220439
220440
220441
220442
220443
220444
220445
220446
220447
220448
220449
220450
220451
220452
220453
220454
220455
220456
220457
220458
220459
220460
220461
220462
220463
220464
220465
220466
220467
220468
220469
220470
220471
220472
220473
220474
220475
220476
220477
220478
220479
220480
220481
220482
220483
220484
220485
220486
220487
220488
220489
220490
220491
220492
220493
220494
220495
220496
220497
220498
220499
220500
220501
220502
220503
220504
220505
220506
220507
220508
220509
220510
220511
220512
220513
220514
220515
220516
220517
220518
220519
220520
220521
220522
220523
220524
220525
220526
220527
220528
220529
220530
220531
220532
220533
220534
220535
220536
220537
220538
220539
220540
220541
220542
220543
220544
220545
220546
220547
220548
220549
220550
220551
220552
220553
220554
220555
220556
220557
220558
220559
220560
220561
220562
220563
220564
220565
220566
220567
220568
220569
220570
220571
220572
220573
220574
220575
220576
220577
220578
220579
220580
220581
220582
220583
220584
220585
220586
220587
220588
220589
220590
220591
220592
220593
220594
220595
220596
220597
220598
220599
220600
220601
220602
220603
220604
220605
220606
220607
220608
220609
220610
220611
220612
220613
220614
220615
220616
220617
220618
220619
220620
220621
220622
220623
220624
220625
220626
220627
220628
220629
220630
220631
220632
220633
220634
220635
220636
220637
220638
220639
220640
220641
220642
220643
220644
220645
220646
220647
220648
220649
220650
220651
220652
220653
220654
220655
220656
220657
220658
220659
220660
220661
220662
220663
220664
220665
220666
220667
220668
220669
220670
220671
220672
220673
220674
220675
220676
220677
220678
220679
220680
220681
220682
220683
220684
220685
220686
220687
220688
220689
220690
220691
220692
220693
220694
220695
220696
220697
220698
220699
220700
220701
220702
220703
220704
220705
220706
220707
220708
220709
220710
220711
220712
220713
220714
220715
220716
220717
220718
220719
220720
220721
220722
220723
220724
220725
220726
220727
220728
220729
220730
220731
220732
220733
220734
220735
220736
220737
220738
220739
220740
220741
220742
220743
220744
220745
220746
220747
220748
220749
220750
220751
220752
220753
220754
220755
220756
220757
220758
220759
220760
220761
220762
220763
220764
220765
220766
220767
220768
220769
220770
220771
220772
220773
220774
220775
220776
220777
220778
220779
220780
220781
220782
220783
220784
220785
220786
220787
220788
220789
220790
220791
220792
220793
220794
220795
220796
220797
220798
220799
220800
220801
220802
220803
220804
220805
220806
220807
220808
220809
220810
220811
220812
220813
220814
220815
220816
220817
220818
220819
220820
220821
220822
220823
220824
220825
220826
220827
220828
220829
220830
220831
220832
220833
220834
220835
220836
220837
220838
220839
220840
220841
220842
220843
220844
220845
220846
220847
220848
220849
220850
220851
220852
220853
220854
220855
220856
220857
220858
220859
220860
220861
220862
220863
220864
220865
220866
220867
220868
220869
220870
220871
220872
220873
220874
220875
220876
220877
220878
220879
220880
220881
220882
220883
220884
220885
220886
220887
220888
220889
220890
220891
220892
220893
220894
220895
220896
220897
220898
220899
220900
220901
220902
220903
220904
220905
220906
220907
220908
220909
220910
220911
220912
220913
220914
220915
220916
220917
220918
220919
220920
220921
220922
220923
220924
220925
220926
220927
220928
220929
220930
220931
220932
220933
220934
220935
220936
220937
220938
220939
220940
220941
220942
220943
220944
220945
220946
220947
220948
220949
220950
220951
220952
220953
220954
220955
220956
220957
220958
220959
220960
220961
220962
220963
220964
220965
220966
220967
220968
220969
220970
220971
220972
220973
220974
220975
220976
220977
220978
220979
220980
220981
220982
220983
220984
220985
220986
220987
220988
220989
220990
220991
220992
220993
220994
220995
220996
220997
220998
220999
221000
221001
221002
221003
221004
221005
221006
221007
221008
221009
221010
221011
221012
221013
221014
221015
221016
221017
221018
221019
221020
221021
221022
221023
221024
221025
221026
221027
221028
221029
221030
221031
221032
221033
221034
221035
221036
221037
221038
221039
221040
221041
221042
221043
221044
221045
221046
221047
221048
221049
221050
221051
221052
221053
221054
221055
221056
221057
221058
221059
221060
221061
221062
221063
221064
221065
221066
221067
221068
221069
221070
221071
221072
221073
221074
221075
221076
221077
221078
221079
221080
221081
221082
221083
221084
221085
221086
221087
221088
221089
221090
221091
221092
221093
221094
221095
221096
221097
221098
221099
221100
221101
221102
221103
221104
221105
221106
221107
221108
221109
221110
221111
221112
221113
221114
221115
221116
221117
221118
221119
221120
221121
221122
221123
221124
221125
221126
221127
221128
221129
221130
221131
221132
221133
221134
221135
221136
221137
221138
221139
221140
221141
221142
221143
221144
221145
221146
221147
221148
221149
221150
221151
221152
221153
221154
221155
221156
221157
221158
221159
221160
221161
221162
221163
221164
221165
221166
221167
221168
221169
221170
221171
221172
221173
221174
221175
221176
221177
221178
221179
221180
221181
221182
221183
221184
221185
221186
221187
221188
221189
221190
221191
221192
221193
221194
221195
221196
221197
221198
221199
221200
221201
221202
221203
221204
221205
221206
221207
221208
221209
221210
221211
221212
221213
221214
221215
221216
221217
221218
221219
221220
221221
221222
221223
221224
221225
221226
221227
221228
221229
221230
221231
221232
221233
221234
221235
221236
221237
221238
221239
221240
221241
221242
221243
221244
221245
221246
221247
221248
221249
221250
221251
221252
221253
221254
221255
221256
221257
221258
221259
221260
221261
221262
221263
221264
221265
221266
221267
221268
221269
221270
221271
221272
221273
221274
221275
221276
221277
221278
221279
221280
221281
221282
221283
221284
221285
221286
221287
221288
221289
221290
221291
221292
221293
221294
221295
221296
221297
221298
221299
221300
221301
221302
221303
221304
221305
221306
221307
221308
221309
221310
221311
221312
221313
221314
221315
221316
221317
221318
221319
221320
221321
221322
221323
221324
221325
221326
221327
221328
221329
221330
221331
221332
221333
221334
221335
221336
221337
221338
221339
221340
221341
221342
221343
221344
221345
221346
221347
221348
221349
221350
221351
221352
221353
221354
221355
221356
221357
221358
221359
221360
221361
221362
221363
221364
221365
221366
221367
221368
221369
221370
221371
221372
221373
221374
221375
221376
221377
221378
221379
221380
221381
221382
221383
221384
221385
221386
221387
221388
221389
221390
221391
221392
221393
221394
221395
221396
221397
221398
221399
221400
221401
221402
221403
221404
221405
221406
221407
221408
221409
221410
221411
221412
221413
221414
221415
221416
221417
221418
221419
221420
221421
221422
221423
221424
221425
221426
221427
221428
221429
221430
221431
221432
221433
221434
221435
221436
221437
221438
221439
221440
221441
221442
221443
221444
221445
221446
221447
221448
221449
221450
221451
221452
221453
221454
221455
221456
221457
221458
221459
221460
221461
221462
221463
221464
221465
221466
221467
221468
221469
221470
221471
221472
221473
221474
221475
221476
221477
221478
221479
221480
221481
221482
221483
221484
221485
221486
221487
221488
221489
221490
221491
221492
221493
221494
221495
221496
221497
221498
221499
221500
221501
221502
221503
221504
221505
221506
221507
221508
221509
221510
221511
221512
221513
221514
221515
221516
221517
221518
221519
221520
221521
221522
221523
221524
221525
221526
221527
221528
221529
221530
221531
221532
221533
221534
221535
221536
221537
221538
221539
221540
221541
221542
221543
221544
221545
221546
221547
221548
221549
221550
221551
221552
221553
221554
221555
221556
221557
221558
221559
221560
221561
221562
221563
221564
221565
221566
221567
221568
221569
221570
221571
221572
221573
221574
221575
221576
221577
221578
221579
221580
221581
221582
221583
221584
221585
221586
221587
221588
221589
221590
221591
221592
221593
221594
221595
221596
221597
221598
221599
221600
221601
221602
221603
221604
221605
221606
221607
221608
221609
221610
221611
221612
221613
221614
221615
221616
221617
221618
221619
221620
221621
221622
221623
221624
221625
221626
221627
221628
221629
221630
221631
221632
221633
221634
221635
221636
221637
221638
221639
221640
221641
221642
221643
221644
221645
221646
221647
221648
221649
221650
221651
221652
221653
221654
221655
221656
221657
221658
221659
221660
221661
221662
221663
221664
221665
221666
221667
221668
221669
221670
221671
221672
221673
221674
221675
221676
221677
221678
221679
221680
221681
221682
221683
221684
221685
221686
221687
221688
221689
221690
221691
221692
221693
221694
221695
221696
221697
221698
221699
221700
221701
221702
221703
221704
221705
221706
221707
221708
221709
221710
221711
221712
221713
221714
221715
221716
221717
221718
221719
221720
221721
221722
221723
221724
221725
221726
221727
221728
221729
221730
221731
221732
221733
221734
221735
221736
221737
221738
221739
221740
221741
221742
221743
221744
221745
221746
221747
221748
221749
221750
221751
221752
221753
221754
221755
221756
221757
221758
221759
221760
221761
221762
221763
221764
221765
221766
221767
221768
221769
221770
221771
221772
221773
221774
221775
221776
221777
221778
221779
221780
221781
221782
221783
221784
221785
221786
221787
221788
221789
221790
221791
221792
221793
221794
221795
221796
221797
221798
221799
221800
221801
221802
221803
221804
221805
221806
221807
221808
221809
221810
221811
221812
221813
221814
221815
221816
221817
221818
221819
221820
221821
221822
221823
221824
221825
221826
221827
221828
221829
221830
221831
221832
221833
221834
221835
221836
221837
221838
221839
221840
221841
221842
221843
221844
221845
221846
221847
221848
221849
221850
221851
221852
221853
221854
221855
221856
221857
221858
221859
221860
221861
221862
221863
221864
221865
221866
221867
221868
221869
221870
221871
221872
221873
221874
221875
221876
221877
221878
221879
221880
221881
221882
221883
221884
221885
221886
221887
221888
221889
221890
221891
221892
221893
221894
221895
221896
221897
221898
221899
221900
221901
221902
221903
221904
221905
221906
221907
221908
221909
221910
221911
221912
221913
221914
221915
221916
221917
221918
221919
221920
221921
221922
221923
221924
221925
221926
221927
221928
221929
221930
221931
221932
221933
221934
221935
221936
221937
221938
221939
221940
221941
221942
221943
221944
221945
221946
221947
221948
221949
221950
221951
221952
221953
221954
221955
221956
221957
221958
221959
221960
221961
221962
221963
221964
221965
221966
221967
221968
221969
221970
221971
221972
221973
221974
221975
221976
221977
221978
221979
221980
221981
221982
221983
221984
221985
221986
221987
221988
221989
221990
221991
221992
221993
221994
221995
221996
221997
221998
221999
222000
222001
222002
222003
222004
222005
222006
222007
222008
222009
222010
222011
222012
222013
222014
222015
222016
222017
222018
222019
222020
222021
222022
222023
222024
222025
222026
222027
222028
222029
222030
222031
222032
222033
222034
222035
222036
222037
222038
222039
222040
222041
222042
222043
222044
222045
222046
222047
222048
222049
222050
222051
222052
222053
222054
222055
222056
222057
222058
222059
222060
222061
222062
222063
222064
222065
222066
222067
222068
222069
222070
222071
222072
222073
222074
222075
222076
222077
222078
222079
222080
222081
222082
222083
222084
222085
222086
222087
222088
222089
222090
222091
222092
222093
222094
222095
222096
222097
222098
222099
222100
222101
222102
222103
222104
222105
222106
222107
222108
222109
222110
222111
222112
222113
222114
222115
222116
222117
222118
222119
222120
222121
222122
222123
222124
222125
222126
222127
222128
222129
222130
222131
222132
222133
222134
222135
222136
222137
222138
222139
222140
222141
222142
222143
222144
222145
222146
222147
222148
222149
222150
222151
222152
222153
222154
222155
222156
222157
222158
222159
222160
222161
222162
222163
222164
222165
222166
222167
222168
222169
222170
222171
222172
222173
222174
222175
222176
222177
222178
222179
222180
222181
222182
222183
222184
222185
222186
222187
222188
222189
222190
222191
222192
222193
222194
222195
222196
222197
222198
222199
222200
222201
222202
222203
222204
222205
222206
222207
222208
222209
222210
222211
222212
222213
222214
222215
222216
222217
222218
222219
222220
222221
222222
222223
222224
222225
222226
222227
222228
222229
222230
222231
222232
222233
222234
222235
222236
222237
222238
222239
222240
222241
222242
222243
222244
222245
222246
222247
222248
222249
222250
222251
222252
222253
222254
222255
222256
222257
222258
222259
222260
222261
222262
222263
222264
222265
222266
222267
222268
222269
222270
222271
222272
222273
222274
222275
222276
222277
222278
222279
222280
222281
222282
222283
222284
222285
222286
222287
222288
222289
222290
222291
222292
222293
222294
222295
222296
222297
222298
222299
222300
222301
222302
222303
222304
222305
222306
222307
222308
222309
222310
222311
222312
222313
222314
222315
222316
222317
222318
222319
222320
222321
222322
222323
222324
222325
222326
222327
222328
222329
222330
222331
222332
222333
222334
222335
222336
222337
222338
222339
222340
222341
222342
222343
222344
222345
222346
222347
222348
222349
222350
222351
222352
222353
222354
222355
222356
222357
222358
222359
222360
222361
222362
222363
222364
222365
222366
222367
222368
222369
222370
222371
222372
222373
222374
222375
222376
222377
222378
222379
222380
222381
222382
222383
222384
222385
222386
222387
222388
222389
222390
222391
222392
222393
222394
222395
222396
222397
222398
222399
222400
222401
222402
222403
222404
222405
222406
222407
222408
222409
222410
222411
222412
222413
222414
222415
222416
222417
222418
222419
222420
222421
222422
222423
222424
222425
222426
222427
222428
222429
222430
222431
222432
222433
222434
222435
222436
222437
222438
222439
222440
222441
222442
222443
222444
222445
222446
222447
222448
222449
222450
222451
222452
222453
222454
222455
222456
222457
222458
222459
222460
222461
222462
222463
222464
222465
222466
222467
222468
222469
222470
222471
222472
222473
222474
222475
222476
222477
222478
222479
222480
222481
222482
222483
222484
222485
222486
222487
222488
222489
222490
222491
222492
222493
222494
222495
222496
222497
222498
222499
222500
222501
222502
222503
222504
222505
222506
222507
222508
222509
222510
222511
222512
222513
222514
222515
222516
222517
222518
222519
222520
222521
222522
222523
222524
222525
222526
222527
222528
222529
222530
222531
222532
222533
222534
222535
222536
222537
222538
222539
222540
222541
222542
222543
222544
222545
222546
222547
222548
222549
222550
222551
222552
222553
222554
222555
222556
222557
222558
222559
222560
222561
222562
222563
222564
222565
222566
222567
222568
222569
222570
222571
222572
222573
222574
222575
222576
222577
222578
222579
222580
222581
222582
222583
222584
222585
222586
222587
222588
222589
222590
222591
222592
222593
222594
222595
222596
222597
222598
222599
222600
222601
222602
222603
222604
222605
222606
222607
222608
222609
222610
222611
222612
222613
222614
222615
222616
222617
222618
222619
222620
222621
222622
222623
222624
222625
222626
222627
222628
222629
222630
222631
222632
222633
222634
222635
222636
222637
222638
222639
222640
222641
222642
222643
222644
222645
222646
222647
222648
222649
222650
222651
222652
222653
222654
222655
222656
222657
222658
222659
222660
222661
222662
222663
222664
222665
222666
222667
222668
222669
222670
222671
222672
222673
222674
222675
222676
222677
222678
222679
222680
222681
222682
222683
222684
222685
222686
222687
222688
222689
222690
222691
222692
222693
222694
222695
222696
222697
222698
222699
222700
222701
222702
222703
222704
222705
222706
222707
222708
222709
222710
222711
222712
222713
222714
222715
222716
222717
222718
222719
222720
222721
222722
222723
222724
222725
222726
222727
222728
222729
222730
222731
222732
222733
222734
222735
222736
222737
222738
222739
222740
222741
222742
222743
222744
222745
222746
222747
222748
222749
222750
222751
222752
222753
222754
222755
222756
222757
222758
222759
222760
222761
222762
222763
222764
222765
222766
222767
222768
222769
222770
222771
222772
222773
222774
222775
222776
222777
222778
222779
222780
222781
222782
222783
222784
222785
222786
222787
222788
222789
222790
222791
222792
222793
222794
222795
222796
222797
222798
222799
222800
222801
222802
222803
222804
222805
222806
222807
222808
222809
222810
222811
222812
222813
222814
222815
222816
222817
222818
222819
222820
222821
222822
222823
222824
222825
222826
222827
222828
222829
222830
222831
222832
222833
222834
222835
222836
222837
222838
222839
222840
222841
222842
222843
222844
222845
222846
222847
222848
222849
222850
222851
222852
222853
222854
222855
222856
222857
222858
222859
222860
222861
222862
222863
222864
222865
222866
222867
222868
222869
222870
222871
222872
222873
222874
222875
222876
222877
222878
222879
222880
222881
222882
222883
222884
222885
222886
222887
222888
222889
222890
222891
222892
222893
222894
222895
222896
222897
222898
222899
222900
222901
222902
222903
222904
222905
222906
222907
222908
222909
222910
222911
222912
222913
222914
222915
222916
222917
222918
222919
222920
222921
222922
222923
222924
222925
222926
222927
222928
222929
222930
222931
222932
222933
222934
222935
222936
222937
222938
222939
222940
222941
222942
222943
222944
222945
222946
222947
222948
222949
222950
222951
222952
222953
222954
222955
222956
222957
222958
222959
222960
222961
222962
222963
222964
222965
222966
222967
222968
222969
222970
222971
222972
222973
222974
222975
222976
222977
222978
222979
222980
222981
222982
222983
222984
222985
222986
222987
222988
222989
222990
222991
222992
222993
222994
222995
222996
222997
222998
222999
223000
223001
223002
223003
223004
223005
223006
223007
223008
223009
223010
223011
223012
223013
223014
223015
223016
223017
223018
223019
223020
223021
223022
223023
223024
223025
223026
223027
223028
223029
223030
223031
223032
223033
223034
223035
223036
223037
223038
223039
223040
223041
223042
223043
223044
223045
223046
223047
223048
223049
223050
223051
223052
223053
223054
223055
223056
223057
223058
223059
223060
223061
223062
223063
223064
223065
223066
223067
223068
223069
223070
223071
223072
223073
223074
223075
223076
223077
223078
223079
223080
223081
223082
223083
223084
223085
223086
223087
223088
223089
223090
223091
223092
223093
223094
223095
223096
223097
223098
223099
223100
223101
223102
223103
223104
223105
223106
223107
223108
223109
223110
223111
223112
223113
223114
223115
223116
223117
223118
223119
223120
223121
223122
223123
223124
223125
223126
223127
223128
223129
223130
223131
223132
223133
223134
223135
223136
223137
223138
223139
223140
223141
223142
223143
223144
223145
223146
223147
223148
223149
223150
223151
223152
223153
223154
223155
223156
223157
223158
223159
223160
223161
223162
223163
223164
223165
223166
223167
223168
223169
223170
223171
223172
223173
223174
223175
223176
223177
223178
223179
223180
223181
223182
223183
223184
223185
223186
223187
223188
223189
223190
223191
223192
223193
223194
223195
223196
223197
223198
223199
223200
223201
223202
223203
223204
223205
223206
223207
223208
223209
223210
223211
223212
223213
223214
223215
223216
223217
223218
223219
223220
223221
223222
223223
223224
223225
223226
223227
223228
223229
223230
223231
223232
223233
223234
223235
223236
223237
223238
223239
223240
223241
223242
223243
223244
223245
223246
223247
223248
223249
223250
223251
223252
223253
223254
223255
223256
223257
223258
223259
223260
223261
223262
223263
223264
223265
223266
223267
223268
223269
223270
223271
223272
223273
223274
223275
223276
223277
223278
223279
223280
223281
223282
223283
223284
223285
223286
223287
223288
223289
223290
223291
223292
223293
223294
223295
223296
223297
223298
223299
223300
223301
223302
223303
223304
223305
223306
223307
223308
223309
223310
223311
223312
223313
223314
223315
223316
223317
223318
223319
223320
223321
223322
223323
223324
223325
223326
223327
223328
223329
223330
223331
223332
223333
223334
223335
223336
223337
223338
223339
223340
223341
223342
223343
223344
223345
223346
223347
223348
223349
223350
223351
223352
223353
223354
223355
223356
223357
223358
223359
223360
223361
223362
223363
223364
223365
223366
223367
223368
223369
223370
223371
223372
223373
223374
223375
223376
223377
223378
223379
223380
223381
223382
223383
223384
223385
223386
223387
223388
223389
223390
223391
223392
223393
223394
223395
223396
223397
223398
223399
223400
223401
223402
223403
223404
223405
223406
223407
223408
223409
223410
223411
223412
223413
223414
223415
223416
223417
223418
223419
223420
223421
223422
223423
223424
223425
223426
223427
223428
223429
223430
223431
223432
223433
223434
223435
223436
223437
223438
223439
223440
223441
223442
223443
223444
223445
223446
223447
223448
223449
223450
223451
223452
223453
223454
223455
223456
223457
223458
223459
223460
223461
223462
223463
223464
223465
223466
223467
223468
223469
223470
223471
223472
223473
223474
223475
223476
223477
223478
223479
223480
223481
223482
223483
223484
223485
223486
223487
223488
223489
223490
223491
223492
223493
223494
223495
223496
223497
223498
223499
223500
223501
223502
223503
223504
223505
223506
223507
223508
223509
223510
223511
223512
223513
223514
223515
223516
223517
223518
223519
223520
223521
223522
223523
223524
223525
223526
223527
223528
223529
223530
223531
223532
223533
223534
223535
223536
223537
223538
223539
223540
223541
223542
223543
223544
223545
223546
223547
223548
223549
223550
223551
223552
223553
223554
223555
223556
223557
223558
223559
223560
223561
223562
223563
223564
223565
223566
223567
223568
223569
223570
223571
223572
223573
223574
223575
223576
223577
223578
223579
223580
223581
223582
223583
223584
223585
223586
223587
223588
223589
223590
223591
223592
223593
223594
223595
223596
223597
223598
223599
223600
223601
223602
223603
223604
223605
223606
223607
223608
223609
223610
223611
223612
223613
223614
223615
223616
223617
223618
223619
223620
223621
223622
223623
223624
223625
223626
223627
223628
223629
223630
223631
223632
223633
223634
223635
223636
223637
223638
223639
223640
223641
223642
223643
223644
223645
223646
223647
223648
223649
223650
223651
223652
223653
223654
223655
223656
223657
223658
223659
223660
223661
223662
223663
223664
223665
223666
223667
223668
223669
223670
223671
223672
223673
223674
223675
223676
223677
223678
223679
223680
223681
223682
223683
223684
223685
223686
223687
223688
223689
223690
223691
223692
223693
223694
223695
223696
223697
223698
223699
223700
223701
223702
223703
223704
223705
223706
223707
223708
223709
223710
223711
223712
223713
223714
223715
223716
223717
223718
223719
223720
223721
223722
223723
223724
223725
223726
223727
223728
223729
223730
223731
223732
223733
223734
223735
223736
223737
223738
223739
223740
223741
223742
223743
223744
223745
223746
223747
223748
223749
223750
223751
223752
223753
223754
223755
223756
223757
223758
223759
223760
223761
223762
223763
223764
223765
223766
223767
223768
223769
223770
223771
223772
223773
223774
223775
223776
223777
223778
223779
223780
223781
223782
223783
223784
223785
223786
223787
223788
223789
223790
223791
223792
223793
223794
223795
223796
223797
223798
223799
223800
223801
223802
223803
223804
223805
223806
223807
223808
223809
223810
223811
223812
223813
223814
223815
223816
223817
223818
223819
223820
223821
223822
223823
223824
223825
223826
223827
223828
223829
223830
223831
223832
223833
223834
223835
223836
223837
223838
223839
223840
223841
223842
223843
223844
223845
223846
223847
223848
223849
223850
223851
223852
223853
223854
223855
223856
223857
223858
223859
223860
223861
223862
223863
223864
223865
223866
223867
223868
223869
223870
223871
223872
223873
223874
223875
223876
223877
223878
223879
223880
223881
223882
223883
223884
223885
223886
223887
223888
223889
223890
223891
223892
223893
223894
223895
223896
223897
223898
223899
223900
223901
223902
223903
223904
223905
223906
223907
223908
223909
223910
223911
223912
223913
223914
223915
223916
223917
223918
223919
223920
223921
223922
223923
223924
223925
223926
223927
223928
223929
223930
223931
223932
223933
223934
223935
223936
223937
223938
223939
223940
223941
223942
223943
223944
223945
223946
223947
223948
223949
223950
223951
223952
223953
223954
223955
223956
223957
223958
223959
223960
223961
223962
223963
223964
223965
223966
223967
223968
223969
223970
223971
223972
223973
223974
223975
223976
223977
223978
223979
223980
223981
223982
223983
223984
223985
223986
223987
223988
223989
223990
223991
223992
223993
223994
223995
223996
223997
223998
223999
224000
224001
224002
224003
224004
224005
224006
224007
224008
224009
224010
224011
224012
224013
224014
224015
224016
224017
224018
224019
224020
224021
224022
224023
224024
224025
224026
224027
224028
224029
224030
224031
224032
224033
224034
224035
224036
224037
224038
224039
224040
224041
224042
224043
224044
224045
224046
224047
224048
224049
224050
224051
224052
224053
224054
224055
224056
224057
224058
224059
224060
224061
224062
224063
224064
224065
224066
224067
224068
224069
224070
224071
224072
224073
224074
224075
224076
224077
224078
224079
224080
224081
224082
224083
224084
224085
224086
224087
224088
224089
224090
224091
224092
224093
224094
224095
224096
224097
224098
224099
224100
224101
224102
224103
224104
224105
224106
224107
224108
224109
224110
224111
224112
224113
224114
224115
224116
224117
224118
224119
224120
224121
224122
224123
224124
224125
224126
224127
224128
224129
224130
224131
224132
224133
224134
224135
224136
224137
224138
224139
224140
224141
224142
224143
224144
224145
224146
224147
224148
224149
224150
224151
224152
224153
224154
224155
224156
224157
224158
224159
224160
224161
224162
224163
224164
224165
224166
224167
224168
224169
224170
224171
224172
224173
224174
224175
224176
224177
224178
224179
224180
224181
224182
224183
224184
224185
224186
224187
224188
224189
224190
224191
224192
224193
224194
224195
224196
224197
224198
224199
224200
224201
224202
224203
224204
224205
224206
224207
224208
224209
224210
224211
224212
224213
224214
224215
224216
224217
224218
224219
224220
224221
224222
224223
224224
224225
224226
224227
224228
224229
224230
224231
224232
224233
224234
224235
224236
224237
224238
224239
224240
224241
224242
224243
224244
224245
224246
224247
224248
224249
224250
224251
224252
224253
224254
224255
224256
224257
224258
224259
224260
224261
224262
224263
224264
224265
224266
224267
224268
224269
224270
224271
224272
224273
224274
224275
224276
224277
224278
224279
224280
224281
224282
224283
224284
224285
224286
224287
224288
224289
224290
224291
224292
224293
224294
224295
224296
224297
224298
224299
224300
224301
224302
224303
224304
224305
224306
224307
224308
224309
224310
224311
224312
224313
224314
224315
224316
224317
224318
224319
224320
224321
224322
224323
224324
224325
224326
224327
224328
224329
224330
224331
224332
224333
224334
224335
224336
224337
224338
224339
224340
224341
224342
224343
224344
224345
224346
224347
224348
224349
224350
224351
224352
224353
224354
224355
224356
224357
224358
224359
224360
224361
224362
224363
224364
224365
224366
224367
224368
224369
224370
224371
224372
224373
224374
224375
224376
224377
224378
224379
224380
224381
224382
224383
224384
224385
224386
224387
224388
224389
224390
224391
224392
224393
224394
224395
224396
224397
224398
224399
224400
224401
224402
224403
224404
224405
224406
224407
224408
224409
224410
224411
224412
224413
224414
224415
224416
224417
224418
224419
224420
224421
224422
224423
224424
224425
224426
224427
224428
224429
224430
224431
224432
224433
224434
224435
224436
224437
224438
224439
224440
224441
224442
224443
224444
224445
224446
224447
224448
224449
224450
224451
224452
224453
224454
224455
224456
224457
224458
224459
224460
224461
224462
224463
224464
224465
224466
224467
224468
224469
224470
224471
224472
224473
224474
224475
224476
224477
224478
224479
224480
224481
224482
224483
224484
224485
224486
224487
224488
224489
224490
224491
224492
224493
224494
224495
224496
224497
224498
224499
224500
224501
224502
224503
224504
224505
224506
224507
224508
224509
224510
224511
224512
224513
224514
224515
224516
224517
224518
224519
224520
224521
224522
224523
224524
224525
224526
224527
224528
224529
224530
224531
224532
224533
224534
224535
224536
224537
224538
224539
224540
224541
224542
224543
224544
224545
224546
224547
224548
224549
224550
224551
224552
224553
224554
224555
224556
224557
224558
224559
224560
224561
224562
224563
224564
224565
224566
224567
224568
224569
224570
224571
224572
224573
224574
224575
224576
224577
224578
224579
224580
224581
224582
224583
224584
224585
224586
224587
224588
224589
224590
224591
224592
224593
224594
224595
224596
224597
224598
224599
224600
224601
224602
224603
224604
224605
224606
224607
224608
224609
224610
224611
224612
224613
224614
224615
224616
224617
224618
224619
224620
224621
224622
224623
224624
224625
224626
224627
224628
224629
224630
224631
224632
224633
224634
224635
224636
224637
224638
224639
224640
224641
224642
224643
224644
224645
224646
224647
224648
224649
224650
224651
224652
224653
224654
224655
224656
224657
224658
224659
224660
224661
224662
224663
224664
224665
224666
224667
224668
224669
224670
224671
224672
224673
224674
224675
224676
224677
224678
224679
224680
224681
224682
224683
224684
224685
224686
224687
224688
224689
224690
224691
224692
224693
224694
224695
224696
224697
224698
224699
224700
224701
224702
224703
224704
224705
224706
224707
224708
224709
224710
224711
224712
224713
224714
224715
224716
224717
224718
224719
224720
224721
224722
224723
224724
224725
224726
224727
224728
224729
224730
224731
224732
224733
224734
224735
224736
224737
224738
224739
224740
224741
224742
224743
224744
224745
224746
224747
224748
224749
224750
224751
224752
224753
224754
224755
224756
224757
224758
224759
224760
224761
224762
224763
224764
224765
224766
224767
224768
224769
224770
224771
224772
224773
224774
224775
224776
224777
224778
224779
224780
224781
224782
224783
224784
224785
224786
224787
224788
224789
224790
224791
224792
224793
224794
224795
224796
224797
224798
224799
224800
224801
224802
224803
224804
224805
224806
224807
224808
224809
224810
224811
224812
224813
224814
224815
224816
224817
224818
224819
224820
224821
224822
224823
224824
224825
224826
224827
224828
224829
224830
224831
224832
224833
224834
224835
224836
224837
224838
224839
224840
224841
224842
224843
224844
224845
224846
224847
224848
224849
224850
224851
224852
224853
224854
224855
224856
224857
224858
224859
224860
224861
224862
224863
224864
224865
224866
224867
224868
224869
224870
224871
224872
224873
224874
224875
224876
224877
224878
224879
224880
224881
224882
224883
224884
224885
224886
224887
224888
224889
224890
224891
224892
224893
224894
224895
224896
224897
224898
224899
224900
224901
224902
224903
224904
224905
224906
224907
224908
224909
224910
224911
224912
224913
224914
224915
224916
224917
224918
224919
224920
224921
224922
224923
224924
224925
224926
224927
224928
224929
224930
224931
224932
224933
224934
224935
224936
224937
224938
224939
224940
224941
224942
224943
224944
224945
224946
224947
224948
224949
224950
224951
224952
224953
224954
224955
224956
224957
224958
224959
224960
224961
224962
224963
224964
224965
224966
224967
224968
224969
224970
224971
224972
224973
224974
224975
224976
224977
224978
224979
224980
224981
224982
224983
224984
224985
224986
224987
224988
224989
224990
224991
224992
224993
224994
224995
224996
224997
224998
224999
225000
225001
225002
225003
225004
225005
225006
225007
225008
225009
225010
225011
225012
225013
225014
225015
225016
225017
225018
225019
225020
225021
225022
225023
225024
225025
225026
225027
225028
225029
225030
225031
225032
225033
225034
225035
225036
225037
225038
225039
225040
225041
225042
225043
225044
225045
225046
225047
225048
225049
225050
225051
225052
225053
225054
225055
225056
225057
225058
225059
225060
225061
225062
225063
225064
225065
225066
225067
225068
225069
225070
225071
225072
225073
225074
225075
225076
225077
225078
225079
225080
225081
225082
225083
225084
225085
225086
225087
225088
225089
225090
225091
225092
225093
225094
225095
225096
225097
225098
225099
225100
225101
225102
225103
225104
225105
225106
225107
225108
225109
225110
225111
225112
225113
225114
225115
225116
225117
225118
225119
225120
225121
225122
225123
225124
225125
225126
225127
225128
225129
225130
225131
225132
225133
225134
225135
225136
225137
225138
225139
225140
225141
225142
225143
225144
225145
225146
225147
225148
225149
225150
225151
225152
225153
225154
225155
225156
225157
225158
225159
225160
225161
225162
225163
225164
225165
225166
225167
225168
225169
225170
225171
225172
225173
225174
225175
225176
225177
225178
225179
225180
225181
225182
225183
225184
225185
225186
225187
225188
225189
225190
225191
225192
225193
225194
225195
225196
225197
225198
225199
225200
225201
225202
225203
225204
225205
225206
225207
225208
225209
225210
225211
225212
225213
225214
225215
225216
225217
225218
225219
225220
225221
225222
225223
225224
225225
225226
225227
225228
225229
225230
225231
225232
225233
225234
225235
225236
225237
225238
225239
225240
225241
225242
225243
225244
225245
225246
225247
225248
225249
225250
225251
225252
225253
225254
225255
225256
225257
225258
225259
225260
225261
225262
225263
225264
225265
225266
225267
225268
225269
225270
225271
225272
225273
225274
225275
225276
225277
225278
225279
225280
225281
225282
225283
225284
225285
225286
225287
225288
225289
225290
225291
225292
225293
225294
225295
225296
225297
225298
225299
225300
225301
225302
225303
225304
225305
225306
225307
225308
225309
225310
225311
225312
225313
225314
225315
225316
225317
225318
225319
225320
225321
225322
225323
225324
225325
225326
225327
225328
225329
225330
225331
225332
225333
225334
225335
225336
225337
225338
225339
225340
225341
225342
225343
225344
225345
225346
225347
225348
225349
225350
225351
225352
225353
225354
225355
225356
225357
225358
225359
225360
225361
225362
225363
225364
225365
225366
225367
225368
225369
225370
225371
225372
225373
225374
225375
225376
225377
225378
225379
225380
225381
225382
225383
225384
225385
225386
225387
225388
225389
225390
225391
225392
225393
225394
225395
225396
225397
225398
225399
225400
225401
225402
225403
225404
225405
225406
225407
225408
225409
225410
225411
225412
225413
225414
225415
225416
225417
225418
225419
225420
225421
225422
225423
225424
225425
225426
225427
225428
225429
225430
225431
225432
225433
225434
225435
225436
225437
225438
225439
225440
225441
225442
225443
225444
225445
225446
225447
225448
225449
225450
225451
225452
225453
225454
225455
225456
225457
225458
225459
225460
225461
225462
225463
225464
225465
225466
225467
225468
225469
225470
225471
225472
225473
225474
225475
225476
225477
225478
225479
225480
225481
225482
225483
225484
225485
225486
225487
225488
225489
225490
225491
225492
225493
225494
225495
225496
225497
225498
225499
225500
225501
225502
225503
225504
225505
225506
225507
225508
225509
225510
225511
225512
225513
225514
225515
225516
225517
225518
225519
225520
225521
225522
225523
225524
225525
225526
225527
225528
225529
225530
225531
225532
225533
225534
225535
225536
225537
225538
225539
225540
225541
225542
225543
225544
225545
225546
225547
225548
225549
225550
225551
225552
225553
225554
225555
225556
225557
225558
225559
225560
225561
225562
225563
225564
225565
225566
225567
225568
225569
225570
225571
225572
225573
225574
225575
225576
225577
225578
225579
225580
225581
225582
225583
225584
225585
225586
225587
225588
225589
225590
225591
225592
225593
225594
225595
225596
225597
225598
225599
225600
225601
225602
225603
225604
225605
225606
225607
225608
225609
225610
225611
225612
225613
225614
225615
225616
225617
225618
225619
225620
225621
225622
225623
225624
225625
225626
225627
225628
225629
225630
225631
225632
225633
225634
225635
225636
225637
225638
225639
225640
225641
225642
225643
225644
225645
225646
225647
225648
225649
225650
225651
225652
225653
225654
225655
225656
225657
225658
225659
225660
225661
225662
225663
225664
225665
225666
225667
225668
225669
225670
225671
225672
225673
225674
225675
225676
225677
225678
225679
225680
225681
225682
225683
225684
225685
225686
225687
225688
225689
225690
225691
225692
225693
225694
225695
225696
225697
225698
225699
225700
225701
225702
225703
225704
225705
225706
225707
225708
225709
225710
225711
225712
225713
225714
225715
225716
225717
225718
225719
225720
225721
225722
225723
225724
225725
225726
225727
225728
225729
225730
225731
225732
225733
225734
225735
225736
225737
225738
225739
225740
225741
225742
225743
225744
225745
225746
225747
225748
225749
225750
225751
225752
225753
225754
225755
225756
225757
225758
225759
225760
225761
225762
225763
225764
225765
225766
225767
225768
225769
225770
225771
225772
225773
225774
225775
225776
225777
225778
225779
225780
225781
225782
225783
225784
225785
225786
225787
225788
225789
225790
225791
225792
225793
225794
225795
225796
225797
225798
225799
225800
225801
225802
225803
225804
225805
225806
225807
225808
225809
225810
225811
225812
225813
225814
225815
225816
225817
225818
225819
225820
225821
225822
225823
225824
225825
225826
225827
225828
225829
225830
225831
225832
225833
225834
225835
225836
225837
225838
225839
225840
225841
225842
225843
225844
225845
225846
225847
225848
225849
225850
225851
225852
225853
225854
225855
225856
225857
225858
225859
225860
225861
225862
225863
225864
225865
225866
225867
225868
225869
225870
225871
225872
225873
225874
225875
225876
225877
225878
225879
225880
225881
225882
225883
225884
225885
225886
225887
225888
225889
225890
225891
225892
225893
225894
225895
225896
225897
225898
225899
225900
225901
225902
225903
225904
225905
225906
225907
225908
225909
225910
225911
225912
225913
225914
225915
225916
225917
225918
225919
225920
225921
225922
225923
225924
225925
225926
225927
225928
225929
225930
225931
225932
225933
225934
225935
225936
225937
225938
225939
225940
225941
225942
225943
225944
225945
225946
225947
225948
225949
225950
225951
225952
225953
225954
225955
225956
225957
225958
225959
225960
225961
225962
225963
225964
225965
225966
225967
225968
225969
225970
225971
225972
225973
225974
225975
225976
225977
225978
225979
225980
225981
225982
225983
225984
225985
225986
225987
225988
225989
225990
225991
225992
225993
225994
225995
225996
225997
225998
225999
226000
226001
226002
226003
226004
226005
226006
226007
226008
226009
226010
226011
226012
226013
226014
226015
226016
226017
226018
226019
226020
226021
226022
226023
226024
226025
226026
226027
226028
226029
226030
226031
226032
226033
226034
226035
226036
226037
226038
226039
226040
226041
226042
226043
226044
226045
226046
226047
226048
226049
226050
226051
226052
226053
226054
226055
226056
226057
226058
226059
226060
226061
226062
226063
226064
226065
226066
226067
226068
226069
226070
226071
226072
226073
226074
226075
226076
226077
226078
226079
226080
226081
226082
226083
226084
226085
226086
226087
226088
226089
226090
226091
226092
226093
226094
226095
226096
226097
226098
226099
226100
226101
226102
226103
226104
226105
226106
226107
226108
226109
226110
226111
226112
226113
226114
226115
226116
226117
226118
226119
226120
226121
226122
226123
226124
226125
226126
226127
226128
226129
226130
226131
226132
226133
226134
226135
226136
226137
226138
226139
226140
226141
226142
226143
226144
226145
226146
226147
226148
226149
226150
226151
226152
226153
226154
226155
226156
226157
226158
226159
226160
226161
226162
226163
226164
226165
226166
226167
226168
226169
226170
226171
226172
226173
226174
226175
226176
226177
226178
226179
226180
226181
226182
226183
226184
226185
226186
226187
226188
226189
226190
226191
226192
226193
226194
226195
226196
226197
226198
226199
226200
226201
226202
226203
226204
226205
226206
226207
226208
226209
226210
226211
226212
226213
226214
226215
226216
226217
226218
226219
226220
226221
226222
226223
226224
226225
226226
226227
226228
226229
226230
226231
226232
226233
226234
226235
226236
226237
226238
226239
226240
226241
226242
226243
226244
226245
226246
226247
226248
226249
226250
226251
226252
226253
226254
226255
226256
226257
226258
226259
226260
226261
226262
226263
226264
226265
226266
226267
226268
226269
226270
226271
226272
226273
226274
226275
226276
226277
226278
226279
226280
226281
226282
226283
226284
226285
226286
226287
226288
226289
226290
226291
226292
226293
226294
226295
226296
226297
226298
226299
226300
226301
226302
226303
226304
226305
226306
226307
226308
226309
226310
226311
226312
226313
226314
226315
226316
226317
226318
226319
226320
226321
226322
226323
226324
226325
226326
226327
226328
226329
226330
226331
226332
226333
226334
226335
226336
226337
226338
226339
226340
226341
226342
226343
226344
226345
226346
226347
226348
226349
226350
226351
226352
226353
226354
226355
226356
226357
226358
226359
226360
226361
226362
226363
226364
226365
226366
226367
226368
226369
226370
226371
226372
226373
226374
226375
226376
226377
226378
226379
226380
226381
226382
226383
226384
226385
226386
226387
226388
226389
226390
226391
226392
226393
226394
226395
226396
226397
226398
226399
226400
226401
226402
226403
226404
226405
226406
226407
226408
226409
226410
226411
226412
226413
226414
226415
226416
226417
226418
226419
226420
226421
226422
226423
226424
226425
226426
226427
226428
226429
226430
226431
226432
226433
226434
226435
226436
226437
226438
226439
226440
226441
226442
226443
226444
226445
226446
226447
226448
226449
226450
226451
226452
226453
226454
226455
226456
226457
226458
226459
226460
226461
226462
226463
226464
226465
226466
226467
226468
226469
226470
226471
226472
226473
226474
226475
226476
226477
226478
226479
226480
226481
226482
226483
226484
226485
226486
226487
226488
226489
226490
226491
226492
226493
226494
226495
226496
226497
226498
226499
226500
226501
226502
226503
226504
226505
226506
226507
226508
226509
226510
226511
226512
226513
226514
226515
226516
226517
226518
226519
226520
226521
226522
226523
226524
226525
226526
226527
226528
226529
226530
226531
226532
226533
226534
226535
226536
226537
226538
226539
226540
226541
226542
226543
226544
226545
226546
226547
226548
226549
226550
226551
226552
226553
226554
226555
226556
226557
226558
226559
226560
226561
226562
226563
226564
226565
226566
226567
226568
226569
226570
226571
226572
226573
226574
226575
226576
226577
226578
226579
226580
226581
226582
226583
226584
226585
226586
226587
226588
226589
226590
226591
226592
226593
226594
226595
226596
226597
226598
226599
226600
226601
226602
226603
226604
226605
226606
226607
226608
226609
226610
226611
226612
226613
226614
226615
226616
226617
226618
226619
226620
226621
226622
226623
226624
226625
226626
226627
226628
226629
226630
226631
226632
226633
226634
226635
226636
226637
226638
226639
226640
226641
226642
226643
226644
226645
226646
226647
226648
226649
226650
226651
226652
226653
226654
226655
226656
226657
226658
226659
226660
226661
226662
226663
226664
226665
226666
226667
226668
226669
226670
226671
226672
226673
226674
226675
226676
226677
226678
226679
226680
226681
226682
226683
226684
226685
226686
226687
226688
226689
226690
226691
226692
226693
226694
226695
226696
226697
226698
226699
226700
226701
226702
226703
226704
226705
226706
226707
226708
226709
226710
226711
226712
226713
226714
226715
226716
226717
226718
226719
226720
226721
226722
226723
226724
226725
226726
226727
226728
226729
226730
226731
226732
226733
226734
226735
226736
226737
226738
226739
226740
226741
226742
226743
226744
226745
226746
226747
226748
226749
226750
226751
226752
226753
226754
226755
226756
226757
226758
226759
226760
226761
226762
226763
226764
226765
226766
226767
226768
226769
226770
226771
226772
226773
226774
226775
226776
226777
226778
226779
226780
226781
226782
226783
226784
226785
226786
226787
226788
226789
226790
226791
226792
226793
226794
226795
226796
226797
226798
226799
226800
226801
226802
226803
226804
226805
226806
226807
226808
226809
226810
226811
226812
226813
226814
226815
226816
226817
226818
226819
226820
226821
226822
226823
226824
226825
226826
226827
226828
226829
226830
226831
226832
226833
226834
226835
226836
226837
226838
226839
226840
226841
226842
226843
226844
226845
226846
226847
226848
226849
226850
226851
226852
226853
226854
226855
226856
226857
226858
226859
226860
226861
226862
226863
226864
226865
226866
226867
226868
226869
226870
226871
226872
226873
226874
226875
226876
226877
226878
226879
226880
226881
226882
226883
226884
226885
226886
226887
226888
226889
226890
226891
226892
226893
226894
226895
226896
226897
226898
226899
226900
226901
226902
226903
226904
226905
226906
226907
226908
226909
226910
226911
226912
226913
226914
226915
226916
226917
226918
226919
226920
226921
226922
226923
226924
226925
226926
226927
226928
226929
226930
226931
226932
226933
226934
226935
226936
226937
226938
226939
226940
226941
226942
226943
226944
226945
226946
226947
226948
226949
226950
226951
226952
226953
226954
226955
226956
226957
226958
226959
226960
226961
226962
226963
226964
226965
226966
226967
226968
226969
226970
226971
226972
226973
226974
226975
226976
226977
226978
226979
226980
226981
226982
226983
226984
226985
226986
226987
226988
226989
226990
226991
226992
226993
226994
226995
226996
226997
226998
226999
227000
227001
227002
227003
227004
227005
227006
227007
227008
227009
227010
227011
227012
227013
227014
227015
227016
227017
227018
227019
227020
227021
227022
227023
227024
227025
227026
227027
227028
227029
227030
227031
227032
227033
227034
227035
227036
227037
227038
227039
227040
227041
227042
227043
227044
227045
227046
227047
227048
227049
227050
227051
227052
227053
227054
227055
227056
227057
227058
227059
227060
227061
227062
227063
227064
227065
227066
227067
227068
227069
227070
227071
227072
227073
227074
227075
227076
227077
227078
227079
227080
227081
227082
227083
227084
227085
227086
227087
227088
227089
227090
227091
227092
227093
227094
227095
227096
227097
227098
227099
227100
227101
227102
227103
227104
227105
227106
227107
227108
227109
227110
227111
227112
227113
227114
227115
227116
227117
227118
227119
227120
227121
227122
227123
227124
227125
227126
227127
227128
227129
227130
227131
227132
227133
227134
227135
227136
227137
227138
227139
227140
227141
227142
227143
227144
227145
227146
227147
227148
227149
227150
227151
227152
227153
227154
227155
227156
227157
227158
227159
227160
227161
227162
227163
227164
227165
227166
227167
227168
227169
227170
227171
227172
227173
227174
227175
227176
227177
227178
227179
227180
227181
227182
227183
227184
227185
227186
227187
227188
227189
227190
227191
227192
227193
227194
227195
227196
227197
227198
227199
227200
227201
227202
227203
227204
227205
227206
227207
227208
227209
227210
227211
227212
227213
227214
227215
227216
227217
227218
227219
227220
227221
227222
227223
227224
227225
227226
227227
227228
227229
227230
227231
227232
227233
227234
227235
227236
227237
227238
227239
227240
227241
227242
227243
227244
227245
227246
227247
227248
227249
227250
227251
227252
227253
227254
227255
227256
227257
227258
227259
227260
227261
227262
227263
227264
227265
227266
227267
227268
227269
227270
227271
227272
227273
227274
227275
227276
227277
227278
227279
227280
227281
227282
227283
227284
227285
227286
227287
227288
227289
227290
227291
227292
227293
227294
227295
227296
227297
227298
227299
227300
227301
227302
227303
227304
227305
227306
227307
227308
227309
227310
227311
227312
227313
227314
227315
227316
227317
227318
227319
227320
227321
227322
227323
227324
227325
227326
227327
227328
227329
227330
227331
227332
227333
227334
227335
227336
227337
227338
227339
227340
227341
227342
227343
227344
227345
227346
227347
227348
227349
227350
227351
227352
227353
227354
227355
227356
227357
227358
227359
227360
227361
227362
227363
227364
227365
227366
227367
227368
227369
227370
227371
227372
227373
227374
227375
227376
227377
227378
227379
227380
227381
227382
227383
227384
227385
227386
227387
227388
227389
227390
227391
227392
227393
227394
227395
227396
227397
227398
227399
227400
227401
227402
227403
227404
227405
227406
227407
227408
227409
227410
227411
227412
227413
227414
227415
227416
227417
227418
227419
227420
227421
227422
227423
227424
227425
227426
227427
227428
227429
227430
227431
227432
227433
227434
227435
227436
227437
227438
227439
227440
227441
227442
227443
227444
227445
227446
227447
227448
227449
227450
227451
227452
227453
227454
227455
227456
227457
227458
227459
227460
227461
227462
227463
227464
227465
227466
227467
227468
227469
227470
227471
227472
227473
227474
227475
227476
227477
227478
227479
227480
227481
227482
227483
227484
227485
227486
227487
227488
227489
227490
227491
227492
227493
227494
227495
227496
227497
227498
227499
227500
227501
227502
227503
227504
227505
227506
227507
227508
227509
227510
227511
227512
227513
227514
227515
227516
227517
227518
227519
227520
227521
227522
227523
227524
227525
227526
227527
227528
227529
227530
227531
227532
227533
227534
227535
227536
227537
227538
227539
227540
227541
227542
227543
227544
227545
227546
227547
227548
227549
227550
227551
227552
227553
227554
227555
227556
227557
227558
227559
227560
227561
227562
227563
227564
227565
227566
227567
227568
227569
227570
227571
227572
227573
227574
227575
227576
227577
227578
227579
227580
227581
227582
227583
227584
227585
227586
227587
227588
227589
227590
227591
227592
227593
227594
227595
227596
227597
227598
227599
227600
227601
227602
227603
227604
227605
227606
227607
227608
227609
227610
227611
227612
227613
227614
227615
227616
227617
227618
227619
227620
227621
227622
227623
227624
227625
227626
227627
227628
227629
227630
227631
227632
227633
227634
227635
227636
227637
227638
227639
227640
227641
227642
227643
227644
227645
227646
227647
227648
227649
227650
227651
227652
227653
227654
227655
227656
227657
227658
227659
227660
227661
227662
227663
227664
227665
227666
227667
227668
227669
227670
227671
227672
227673
227674
227675
227676
227677
227678
227679
227680
227681
227682
227683
227684
227685
227686
227687
227688
227689
227690
227691
227692
227693
227694
227695
227696
227697
227698
227699
227700
227701
227702
227703
227704
227705
227706
227707
227708
227709
227710
227711
227712
227713
227714
227715
227716
227717
227718
227719
227720
227721
227722
227723
227724
227725
227726
227727
227728
227729
227730
227731
227732
227733
227734
227735
227736
227737
227738
227739
227740
227741
227742
227743
227744
227745
227746
227747
227748
227749
227750
227751
227752
227753
227754
227755
227756
227757
227758
227759
227760
227761
227762
227763
227764
227765
227766
227767
227768
227769
227770
227771
227772
227773
227774
227775
227776
227777
227778
227779
227780
227781
227782
227783
227784
227785
227786
227787
227788
227789
227790
227791
227792
227793
227794
227795
227796
227797
227798
227799
227800
227801
227802
227803
227804
227805
227806
227807
227808
227809
227810
227811
227812
227813
227814
227815
227816
227817
227818
227819
227820
227821
227822
227823
227824
227825
227826
227827
227828
227829
227830
227831
227832
227833
227834
227835
227836
227837
227838
227839
227840
227841
227842
227843
227844
227845
227846
227847
227848
227849
227850
227851
227852
227853
227854
227855
227856
227857
227858
227859
227860
227861
227862
227863
227864
227865
227866
227867
227868
227869
227870
227871
227872
227873
227874
227875
227876
227877
227878
227879
227880
227881
227882
227883
227884
227885
227886
227887
227888
227889
227890
227891
227892
227893
227894
227895
227896
227897
227898
227899
227900
227901
227902
227903
227904
227905
227906
227907
227908
227909
227910
227911
227912
227913
227914
227915
227916
227917
227918
227919
227920
227921
227922
227923
227924
227925
227926
227927
227928
227929
227930
227931
227932
227933
227934
227935
227936
227937
227938
227939
227940
227941
227942
227943
227944
227945
227946
227947
227948
227949
227950
227951
227952
227953
227954
227955
227956
227957
227958
227959
227960
227961
227962
227963
227964
227965
227966
227967
227968
227969
227970
227971
227972
227973
227974
227975
227976
227977
227978
227979
227980
227981
227982
227983
227984
227985
227986
227987
227988
227989
227990
227991
227992
227993
227994
227995
227996
227997
227998
227999
228000
228001
228002
228003
228004
228005
228006
228007
228008
228009
228010
228011
228012
228013
228014
228015
228016
228017
228018
228019
228020
228021
228022
228023
228024
228025
228026
228027
228028
228029
228030
228031
228032
228033
228034
228035
228036
228037
228038
228039
228040
228041
228042
228043
228044
228045
228046
228047
228048
228049
228050
228051
228052
228053
228054
228055
228056
228057
228058
228059
228060
228061
228062
228063
228064
228065
228066
228067
228068
228069
228070
228071
228072
228073
228074
228075
228076
228077
228078
228079
228080
228081
228082
228083
228084
228085
228086
228087
228088
228089
228090
228091
228092
228093
228094
228095
228096
228097
228098
228099
228100
228101
228102
228103
228104
228105
228106
228107
228108
228109
228110
228111
228112
228113
228114
228115
228116
228117
228118
228119
228120
228121
228122
228123
228124
228125
228126
228127
228128
228129
228130
228131
228132
228133
228134
228135
228136
228137
228138
228139
228140
228141
228142
228143
228144
228145
228146
228147
228148
228149
228150
228151
228152
228153
228154
228155
228156
228157
228158
228159
228160
228161
228162
228163
228164
228165
228166
228167
228168
228169
228170
228171
228172
228173
228174
228175
228176
228177
228178
228179
228180
228181
228182
228183
228184
228185
228186
228187
228188
228189
228190
228191
228192
228193
228194
228195
228196
228197
228198
228199
228200
228201
228202
228203
228204
228205
228206
228207
228208
228209
228210
228211
228212
228213
228214
228215
228216
228217
228218
228219
228220
228221
228222
228223
228224
228225
228226
228227
228228
228229
228230
228231
228232
228233
228234
228235
228236
228237
228238
228239
228240
228241
228242
228243
228244
228245
228246
228247
228248
228249
228250
228251
228252
228253
228254
228255
228256
228257
228258
228259
228260
228261
228262
228263
228264
228265
228266
228267
228268
228269
228270
228271
228272
228273
228274
228275
228276
228277
228278
228279
228280
228281
228282
228283
228284
228285
228286
228287
228288
228289
228290
228291
228292
228293
228294
228295
228296
228297
228298
228299
228300
228301
228302
228303
228304
228305
228306
228307
228308
228309
228310
228311
228312
228313
228314
228315
228316
228317
228318
228319
228320
228321
228322
228323
228324
228325
228326
228327
228328
228329
228330
228331
228332
228333
228334
228335
228336
228337
228338
228339
228340
228341
228342
228343
228344
228345
228346
228347
228348
228349
228350
228351
228352
228353
228354
228355
228356
228357
228358
228359
228360
228361
228362
228363
228364
228365
228366
228367
228368
228369
228370
228371
228372
228373
228374
228375
228376
228377
228378
228379
228380
228381
228382
228383
228384
228385
228386
228387
228388
228389
228390
228391
228392
228393
228394
228395
228396
228397
228398
228399
228400
228401
228402
228403
228404
228405
228406
228407
228408
228409
228410
228411
228412
228413
228414
228415
228416
228417
228418
228419
228420
228421
228422
228423
228424
228425
228426
228427
228428
228429
228430
228431
228432
228433
228434
228435
228436
228437
228438
228439
228440
228441
228442
228443
228444
228445
228446
228447
228448
228449
228450
228451
228452
228453
228454
228455
228456
228457
228458
228459
228460
228461
228462
228463
228464
228465
228466
228467
228468
228469
228470
228471
228472
228473
228474
228475
228476
228477
228478
228479
228480
228481
228482
228483
228484
228485
228486
228487
228488
228489
228490
228491
228492
228493
228494
228495
228496
228497
228498
228499
228500
228501
228502
228503
228504
228505
228506
228507
228508
228509
228510
228511
228512
228513
228514
228515
228516
228517
228518
228519
228520
228521
228522
228523
228524
228525
228526
228527
228528
228529
228530
228531
228532
228533
228534
228535
228536
228537
228538
228539
228540
228541
228542
228543
228544
228545
228546
228547
228548
228549
228550
228551
228552
228553
228554
228555
228556
228557
228558
228559
228560
228561
228562
228563
228564
228565
228566
228567
228568
228569
228570
228571
228572
228573
228574
228575
228576
228577
228578
228579
228580
228581
228582
228583
228584
228585
228586
228587
228588
228589
228590
228591
228592
228593
228594
228595
228596
228597
228598
228599
228600
228601
228602
228603
228604
228605
228606
228607
228608
228609
228610
228611
228612
228613
228614
228615
228616
228617
228618
228619
228620
228621
228622
228623
228624
228625
228626
228627
228628
228629
228630
228631
228632
228633
228634
228635
228636
228637
228638
228639
228640
228641
228642
228643
228644
228645
228646
228647
228648
228649
228650
228651
228652
228653
228654
228655
228656
228657
228658
228659
228660
228661
228662
228663
228664
228665
228666
228667
228668
228669
228670
228671
228672
228673
228674
228675
228676
228677
228678
228679
228680
228681
228682
228683
228684
228685
228686
228687
228688
228689
228690
228691
228692
228693
228694
228695
228696
228697
228698
228699
228700
228701
228702
228703
228704
228705
228706
228707
228708
228709
228710
228711
228712
228713
228714
228715
228716
228717
228718
228719
228720
228721
228722
228723
228724
228725
228726
228727
228728
228729
228730
228731
228732
228733
228734
228735
228736
228737
228738
228739
228740
228741
228742
228743
228744
228745
228746
228747
228748
228749
228750
228751
228752
228753
228754
228755
228756
228757
228758
228759
228760
228761
228762
228763
228764
228765
228766
228767
228768
228769
228770
228771
228772
228773
228774
228775
228776
228777
228778
228779
228780
228781
228782
228783
228784
228785
228786
228787
228788
228789
228790
228791
228792
228793
228794
228795
228796
228797
228798
228799
228800
228801
228802
228803
228804
228805
228806
228807
228808
228809
228810
228811
228812
228813
228814
228815
228816
228817
228818
228819
228820
228821
228822
228823
228824
228825
228826
228827
228828
228829
228830
228831
228832
228833
228834
228835
228836
228837
228838
228839
228840
228841
228842
228843
228844
228845
228846
228847
228848
228849
228850
228851
228852
228853
228854
228855
228856
228857
228858
228859
228860
228861
228862
228863
228864
228865
228866
228867
228868
228869
228870
228871
228872
228873
228874
228875
228876
228877
228878
228879
228880
228881
228882
228883
228884
228885
228886
228887
228888
228889
228890
228891
228892
228893
228894
228895
228896
228897
228898
228899
228900
228901
228902
228903
228904
228905
228906
228907
228908
228909
228910
228911
228912
228913
228914
228915
228916
228917
228918
228919
228920
228921
228922
228923
228924
228925
228926
228927
228928
228929
228930
228931
228932
228933
228934
228935
228936
228937
228938
228939
228940
228941
228942
228943
228944
228945
228946
228947
228948
228949
228950
228951
228952
228953
228954
228955
228956
228957
228958
228959
228960
228961
228962
228963
228964
228965
228966
228967
228968
228969
228970
228971
228972
228973
228974
228975
228976
228977
228978
228979
228980
228981
228982
228983
228984
228985
228986
228987
228988
228989
228990
228991
228992
228993
228994
228995
228996
228997
228998
228999
229000
229001
229002
229003
229004
229005
229006
229007
229008
229009
229010
229011
229012
229013
229014
229015
229016
229017
229018
229019
229020
229021
229022
229023
229024
229025
229026
229027
229028
229029
229030
229031
229032
229033
229034
229035
229036
229037
229038
229039
229040
229041
229042
229043
229044
229045
229046
229047
229048
229049
229050
229051
229052
229053
229054
229055
229056
229057
229058
229059
229060
229061
229062
229063
229064
229065
229066
229067
229068
229069
229070
229071
229072
229073
229074
229075
229076
229077
229078
229079
229080
229081
229082
229083
229084
229085
229086
229087
229088
229089
229090
229091
229092
229093
229094
229095
229096
229097
229098
229099
229100
229101
229102
229103
229104
229105
229106
229107
229108
229109
229110
229111
229112
229113
229114
229115
229116
229117
229118
229119
229120
229121
229122
229123
229124
229125
229126
229127
229128
229129
229130
229131
229132
229133
229134
229135
229136
229137
229138
229139
229140
229141
229142
229143
229144
229145
229146
229147
229148
229149
229150
229151
229152
229153
229154
229155
229156
229157
229158
229159
229160
229161
229162
229163
229164
229165
229166
229167
229168
229169
229170
229171
229172
229173
229174
229175
229176
229177
229178
229179
229180
229181
229182
229183
229184
229185
229186
229187
229188
229189
229190
229191
229192
229193
229194
229195
229196
229197
229198
229199
229200
229201
229202
229203
229204
229205
229206
229207
229208
229209
229210
229211
229212
229213
229214
229215
229216
229217
229218
229219
229220
229221
229222
229223
229224
229225
229226
229227
229228
229229
229230
229231
229232
229233
229234
229235
229236
229237
229238
229239
229240
229241
229242
229243
229244
229245
229246
229247
229248
229249
229250
229251
229252
229253
229254
229255
229256
229257
229258
229259
229260
229261
229262
229263
229264
229265
229266
229267
229268
229269
229270
229271
229272
229273
229274
229275
229276
229277
229278
229279
229280
229281
229282
229283
229284
229285
229286
229287
229288
229289
229290
229291
229292
229293
229294
229295
229296
229297
229298
229299
229300
229301
229302
229303
229304
229305
229306
229307
229308
229309
229310
229311
229312
229313
229314
229315
229316
229317
229318
229319
229320
229321
229322
229323
229324
229325
229326
229327
229328
229329
229330
229331
229332
229333
229334
229335
229336
229337
229338
229339
229340
229341
229342
229343
229344
229345
229346
229347
229348
229349
229350
229351
229352
229353
229354
229355
229356
229357
229358
229359
229360
229361
229362
229363
229364
229365
229366
229367
229368
229369
229370
229371
229372
229373
229374
229375
229376
229377
229378
229379
229380
229381
229382
229383
229384
229385
229386
229387
229388
229389
229390
229391
229392
229393
229394
229395
229396
229397
229398
229399
229400
229401
229402
229403
229404
229405
229406
229407
229408
229409
229410
229411
229412
229413
229414
229415
229416
229417
229418
229419
229420
229421
229422
229423
229424
229425
229426
229427
229428
229429
229430
229431
229432
229433
229434
229435
229436
229437
229438
229439
229440
229441
229442
229443
229444
229445
229446
229447
229448
229449
229450
229451
229452
229453
229454
229455
229456
229457
229458
229459
229460
229461
229462
229463
229464
229465
229466
229467
229468
229469
229470
229471
229472
229473
229474
229475
229476
229477
229478
229479
229480
229481
229482
229483
229484
229485
229486
229487
229488
229489
229490
229491
229492
229493
229494
229495
229496
229497
229498
229499
229500
229501
229502
229503
229504
229505
229506
229507
229508
229509
229510
229511
229512
229513
229514
229515
229516
229517
229518
229519
229520
229521
229522
229523
229524
229525
229526
229527
229528
229529
229530
229531
229532
229533
229534
229535
229536
229537
229538
229539
229540
229541
229542
229543
229544
229545
229546
229547
229548
229549
229550
229551
229552
229553
229554
229555
229556
229557
229558
229559
229560
229561
229562
229563
229564
229565
229566
229567
229568
229569
229570
229571
229572
229573
229574
229575
229576
229577
229578
229579
229580
229581
229582
229583
229584
229585
229586
229587
229588
229589
229590
229591
229592
229593
229594
229595
229596
229597
229598
229599
229600
229601
229602
229603
229604
229605
229606
229607
229608
229609
229610
229611
229612
229613
229614
229615
229616
229617
229618
229619
229620
229621
229622
229623
229624
229625
229626
229627
229628
229629
229630
229631
229632
229633
229634
229635
229636
229637
229638
229639
229640
229641
229642
229643
229644
229645
229646
229647
229648
229649
229650
229651
229652
229653
229654
229655
229656
229657
229658
229659
229660
229661
229662
229663
229664
229665
229666
229667
229668
229669
229670
229671
229672
229673
229674
229675
229676
229677
229678
229679
229680
229681
229682
229683
229684
229685
229686
229687
229688
229689
229690
229691
229692
229693
229694
229695
229696
229697
229698
229699
229700
229701
229702
229703
229704
229705
229706
229707
229708
229709
229710
229711
229712
229713
229714
229715
229716
229717
229718
229719
229720
229721
229722
229723
229724
229725
229726
229727
229728
229729
229730
229731
229732
229733
229734
229735
229736
229737
229738
229739
229740
229741
229742
229743
229744
229745
229746
229747
229748
229749
229750
229751
229752
229753
229754
229755
229756
229757
229758
229759
229760
229761
229762
229763
229764
229765
229766
229767
229768
229769
229770
229771
229772
229773
229774
229775
229776
229777
229778
229779
229780
229781
229782
229783
229784
229785
229786
229787
229788
229789
229790
229791
229792
229793
229794
229795
229796
229797
229798
229799
229800
229801
229802
229803
229804
229805
229806
229807
229808
229809
229810
229811
229812
229813
229814
229815
229816
229817
229818
229819
229820
229821
229822
229823
229824
229825
229826
229827
229828
229829
229830
229831
229832
229833
229834
229835
229836
229837
229838
229839
229840
229841
229842
229843
229844
229845
229846
229847
229848
229849
229850
229851
229852
229853
229854
229855
229856
229857
229858
229859
229860
229861
229862
229863
229864
229865
229866
229867
229868
229869
229870
229871
229872
229873
229874
229875
229876
229877
229878
229879
229880
229881
229882
229883
229884
229885
229886
229887
229888
229889
229890
229891
229892
229893
229894
229895
229896
229897
229898
229899
229900
229901
229902
229903
229904
229905
229906
229907
229908
229909
229910
229911
229912
229913
229914
229915
229916
229917
229918
229919
229920
229921
229922
229923
229924
229925
229926
229927
229928
229929
229930
229931
229932
229933
229934
229935
229936
229937
229938
229939
229940
229941
229942
229943
229944
229945
229946
229947
229948
229949
229950
229951
229952
229953
229954
229955
229956
229957
229958
229959
229960
229961
229962
229963
229964
229965
229966
229967
229968
229969
229970
229971
229972
229973
229974
229975
229976
229977
229978
229979
229980
229981
229982
229983
229984
229985
229986
229987
229988
229989
229990
229991
229992
229993
229994
229995
229996
229997
229998
229999
230000
230001
230002
230003
230004
230005
230006
230007
230008
230009
230010
230011
230012
230013
230014
230015
230016
230017
230018
230019
230020
230021
230022
230023
230024
230025
230026
230027
230028
230029
230030
230031
230032
230033
230034
230035
230036
230037
230038
230039
230040
230041
230042
230043
230044
230045
230046
230047
230048
230049
230050
230051
230052
230053
230054
230055
230056
230057
230058
230059
230060
230061
230062
230063
230064
230065
230066
230067
230068
230069
230070
230071
230072
230073
230074
230075
230076
230077
230078
230079
230080
230081
230082
230083
230084
230085
230086
230087
230088
230089
230090
230091
230092
230093
230094
230095
230096
230097
230098
230099
230100
230101
230102
230103
230104
230105
230106
230107
230108
230109
230110
230111
230112
230113
230114
230115
230116
230117
230118
230119
230120
230121
230122
230123
230124
230125
230126
230127
230128
230129
230130
230131
230132
230133
230134
230135
230136
230137
230138
230139
230140
230141
230142
230143
230144
230145
230146
230147
230148
230149
230150
230151
230152
230153
230154
230155
230156
230157
230158
230159
230160
230161
230162
230163
230164
230165
230166
230167
230168
230169
230170
230171
230172
230173
230174
230175
230176
230177
230178
230179
230180
230181
230182
230183
230184
230185
230186
230187
230188
230189
230190
230191
230192
230193
230194
230195
230196
230197
230198
230199
230200
230201
230202
230203
230204
230205
230206
230207
230208
230209
230210
230211
230212
230213
230214
230215
230216
230217
230218
230219
230220
230221
230222
230223
230224
230225
230226
230227
230228
230229
230230
230231
230232
230233
230234
230235
230236
230237
230238
230239
230240
230241
230242
230243
230244
230245
230246
230247
230248
230249
230250
230251
230252
230253
230254
230255
230256
230257
230258
230259
230260
230261
230262
230263
230264
230265
230266
230267
230268
230269
230270
230271
230272
230273
230274
230275
230276
230277
230278
230279
230280
230281
230282
230283
230284
230285
230286
230287
230288
230289
230290
230291
230292
230293
230294
230295
230296
230297
230298
230299
230300
230301
230302
230303
230304
230305
230306
230307
230308
230309
230310
230311
230312
230313
230314
230315
230316
230317
230318
230319
230320
230321
230322
230323
230324
230325
230326
230327
230328
230329
230330
230331
230332
230333
230334
230335
230336
230337
230338
230339
230340
230341
230342
230343
230344
230345
230346
230347
230348
230349
230350
230351
230352
230353
230354
230355
230356
230357
230358
230359
230360
230361
230362
230363
230364
230365
230366
230367
230368
230369
230370
230371
230372
230373
230374
230375
230376
230377
230378
230379
230380
230381
230382
230383
230384
230385
230386
230387
230388
230389
230390
230391
230392
230393
230394
230395
230396
230397
230398
230399
230400
230401
230402
230403
230404
230405
230406
230407
230408
230409
230410
230411
230412
230413
230414
230415
230416
230417
230418
230419
230420
230421
230422
230423
230424
230425
230426
230427
230428
230429
230430
230431
230432
230433
230434
230435
230436
230437
230438
230439
230440
230441
230442
230443
230444
230445
230446
230447
230448
230449
230450
230451
230452
230453
230454
230455
230456
230457
230458
230459
230460
230461
230462
230463
230464
230465
230466
230467
230468
230469
230470
230471
230472
230473
230474
230475
230476
230477
230478
230479
230480
230481
230482
230483
230484
230485
230486
230487
230488
230489
230490
230491
230492
230493
230494
230495
230496
230497
230498
230499
230500
230501
230502
230503
230504
230505
230506
230507
230508
230509
230510
230511
230512
230513
230514
230515
230516
230517
230518
230519
230520
230521
230522
230523
230524
230525
230526
230527
230528
230529
230530
230531
230532
230533
230534
230535
230536
230537
230538
230539
230540
230541
230542
230543
230544
230545
230546
230547
230548
230549
230550
230551
230552
230553
230554
230555
230556
230557
230558
230559
230560
230561
230562
230563
230564
230565
230566
230567
230568
230569
230570
230571
230572
230573
230574
230575
230576
230577
230578
230579
230580
230581
230582
230583
230584
230585
230586
230587
230588
230589
230590
230591
230592
230593
230594
230595
230596
230597
230598
230599
230600
230601
230602
230603
230604
230605
230606
230607
230608
230609
230610
230611
230612
230613
230614
230615
230616
230617
230618
230619
230620
230621
230622
230623
230624
230625
230626
230627
230628
230629
230630
230631
230632
230633
230634
230635
230636
230637
230638
230639
230640
230641
230642
230643
230644
230645
230646
230647
230648
230649
230650
230651
230652
230653
230654
230655
230656
230657
230658
230659
230660
230661
230662
230663
230664
230665
230666
230667
230668
230669
230670
230671
230672
230673
230674
230675
230676
230677
230678
230679
230680
230681
230682
230683
230684
230685
230686
230687
230688
230689
230690
230691
230692
230693
230694
230695
230696
230697
230698
230699
230700
230701
230702
230703
230704
230705
230706
230707
230708
230709
230710
230711
230712
230713
230714
230715
230716
230717
230718
230719
230720
230721
230722
230723
230724
230725
230726
230727
230728
230729
230730
230731
230732
230733
230734
230735
230736
230737
230738
230739
230740
230741
230742
230743
230744
230745
230746
230747
230748
230749
230750
230751
230752
230753
230754
230755
230756
230757
230758
230759
230760
230761
230762
230763
230764
230765
230766
230767
230768
230769
230770
230771
230772
230773
230774
230775
230776
230777
230778
230779
230780
230781
230782
230783
230784
230785
230786
230787
230788
230789
230790
230791
230792
230793
230794
230795
230796
230797
230798
230799
230800
230801
230802
230803
230804
230805
230806
230807
230808
230809
230810
230811
230812
230813
230814
230815
230816
230817
230818
230819
230820
230821
230822
230823
230824
230825
230826
230827
230828
230829
230830
230831
230832
230833
230834
230835
230836
230837
230838
230839
230840
230841
230842
230843
230844
230845
230846
230847
230848
230849
230850
230851
230852
230853
230854
230855
230856
230857
230858
230859
230860
230861
230862
230863
230864
230865
230866
230867
230868
230869
230870
230871
230872
230873
230874
230875
230876
230877
230878
230879
230880
230881
230882
230883
230884
230885
230886
230887
230888
230889
230890
230891
230892
230893
230894
230895
230896
230897
230898
230899
230900
230901
230902
230903
230904
230905
230906
230907
230908
230909
230910
230911
230912
230913
230914
230915
230916
230917
230918
230919
230920
230921
230922
230923
230924
230925
230926
230927
230928
230929
230930
230931
230932
230933
230934
230935
230936
230937
230938
230939
230940
230941
230942
230943
230944
230945
230946
230947
230948
230949
230950
230951
230952
230953
230954
230955
230956
230957
230958
230959
230960
230961
230962
230963
230964
230965
230966
230967
230968
230969
230970
230971
230972
230973
230974
230975
230976
230977
230978
230979
230980
230981
230982
230983
230984
230985
230986
230987
230988
230989
230990
230991
230992
230993
230994
230995
230996
230997
230998
230999
231000
231001
231002
231003
231004
231005
231006
231007
231008
231009
231010
231011
231012
231013
231014
231015
231016
231017
231018
231019
231020
231021
231022
231023
231024
231025
231026
231027
231028
231029
231030
231031
231032
231033
231034
231035
231036
231037
231038
231039
231040
231041
231042
231043
231044
231045
231046
231047
231048
231049
231050
231051
231052
231053
231054
231055
231056
231057
231058
231059
231060
231061
231062
231063
231064
231065
231066
231067
231068
231069
231070
231071
231072
231073
231074
231075
231076
231077
231078
231079
231080
231081
231082
231083
231084
231085
231086
231087
231088
231089
231090
231091
231092
231093
231094
231095
231096
231097
231098
231099
231100
231101
231102
231103
231104
231105
231106
231107
231108
231109
231110
231111
231112
231113
231114
231115
231116
231117
231118
231119
231120
231121
231122
231123
231124
231125
231126
231127
231128
231129
231130
231131
231132
231133
231134
231135
231136
231137
231138
231139
231140
231141
231142
231143
231144
231145
231146
231147
231148
231149
231150
231151
231152
231153
231154
231155
231156
231157
231158
231159
231160
231161
231162
231163
231164
231165
231166
231167
231168
231169
231170
231171
231172
231173
231174
231175
231176
231177
231178
231179
231180
231181
231182
231183
231184
231185
231186
231187
231188
231189
231190
231191
231192
231193
231194
231195
231196
231197
231198
231199
231200
231201
231202
231203
231204
231205
231206
231207
231208
231209
231210
231211
231212
231213
231214
231215
231216
231217
231218
231219
231220
231221
231222
231223
231224
231225
231226
231227
231228
231229
231230
231231
231232
231233
231234
231235
231236
231237
231238
231239
231240
231241
231242
231243
231244
231245
231246
231247
231248
231249
231250
231251
231252
231253
231254
231255
231256
231257
231258
231259
231260
231261
231262
231263
231264
231265
231266
231267
231268
231269
231270
231271
231272
231273
231274
231275
231276
231277
231278
231279
231280
231281
231282
231283
231284
231285
231286
231287
231288
231289
231290
231291
231292
231293
231294
231295
231296
231297
231298
231299
231300
231301
231302
231303
231304
231305
231306
231307
231308
231309
231310
231311
231312
231313
231314
231315
231316
231317
231318
231319
231320
231321
231322
231323
231324
231325
231326
231327
231328
231329
231330
231331
231332
231333
231334
231335
231336
231337
231338
231339
231340
231341
231342
231343
231344
231345
231346
231347
231348
231349
231350
231351
231352
231353
231354
231355
231356
231357
231358
231359
231360
231361
231362
231363
231364
231365
231366
231367
231368
231369
231370
231371
231372
231373
231374
231375
231376
231377
231378
231379
231380
231381
231382
231383
231384
231385
231386
231387
231388
231389
231390
231391
231392
231393
231394
231395
231396
231397
231398
231399
231400
231401
231402
231403
231404
231405
231406
231407
231408
231409
231410
231411
231412
231413
231414
231415
231416
231417
231418
231419
231420
231421
231422
231423
231424
231425
231426
231427
231428
231429
231430
231431
231432
231433
231434
231435
231436
231437
231438
231439
231440
231441
231442
231443
231444
231445
231446
231447
231448
231449
231450
231451
231452
231453
231454
231455
231456
231457
231458
231459
231460
231461
231462
231463
231464
231465
231466
231467
231468
231469
231470
231471
231472
231473
231474
231475
231476
231477
231478
231479
231480
231481
231482
231483
231484
231485
231486
231487
231488
231489
231490
231491
231492
231493
231494
231495
231496
231497
231498
231499
231500
231501
231502
231503
231504
231505
231506
231507
231508
231509
231510
231511
231512
231513
231514
231515
231516
231517
231518
231519
231520
231521
231522
231523
231524
231525
231526
231527
231528
231529
231530
231531
231532
231533
231534
231535
231536
231537
231538
231539
231540
231541
231542
231543
231544
231545
231546
231547
231548
231549
231550
231551
231552
231553
231554
231555
231556
231557
231558
231559
231560
231561
231562
231563
231564
231565
231566
231567
231568
231569
231570
231571
231572
231573
231574
231575
231576
231577
231578
231579
231580
231581
231582
231583
231584
231585
231586
231587
231588
231589
231590
231591
231592
231593
231594
231595
231596
231597
231598
231599
231600
231601
231602
231603
231604
231605
231606
231607
231608
231609
231610
231611
231612
231613
231614
231615
231616
231617
231618
231619
231620
231621
231622
231623
231624
231625
231626
231627
231628
231629
231630
231631
231632
231633
231634
231635
231636
231637
231638
231639
231640
231641
231642
231643
231644
231645
231646
231647
231648
231649
231650
231651
231652
231653
231654
231655
231656
231657
231658
231659
231660
231661
231662
231663
231664
231665
231666
231667
231668
231669
231670
231671
231672
231673
231674
231675
231676
231677
231678
231679
231680
231681
231682
231683
231684
231685
231686
231687
231688
231689
231690
231691
231692
231693
231694
231695
231696
231697
231698
231699
231700
231701
231702
231703
231704
231705
231706
231707
231708
231709
231710
231711
231712
231713
231714
231715
231716
231717
231718
231719
231720
231721
231722
231723
231724
231725
231726
231727
231728
231729
231730
231731
231732
231733
231734
231735
231736
231737
231738
231739
231740
231741
231742
231743
231744
231745
231746
231747
231748
231749
231750
231751
231752
231753
231754
231755
231756
231757
231758
231759
231760
231761
231762
231763
231764
231765
231766
231767
231768
231769
231770
231771
231772
231773
231774
231775
231776
231777
231778
231779
231780
231781
231782
231783
231784
231785
231786
231787
231788
231789
231790
231791
231792
231793
231794
231795
231796
231797
231798
231799
231800
231801
231802
231803
231804
231805
231806
231807
231808
231809
231810
231811
231812
231813
231814
231815
231816
231817
231818
231819
231820
231821
231822
231823
231824
231825
231826
231827
231828
231829
231830
231831
231832
231833
231834
231835
231836
231837
231838
231839
231840
231841
231842
231843
231844
231845
231846
231847
231848
231849
231850
231851
231852
231853
231854
231855
231856
231857
231858
231859
231860
231861
231862
231863
231864
231865
231866
231867
231868
231869
231870
231871
231872
231873
231874
231875
231876
231877
231878
231879
231880
231881
231882
231883
231884
231885
231886
231887
231888
231889
231890
231891
231892
231893
231894
231895
231896
231897
231898
231899
231900
231901
231902
231903
231904
231905
231906
231907
231908
231909
231910
231911
231912
231913
231914
231915
231916
231917
231918
231919
231920
231921
231922
231923
231924
231925
231926
231927
231928
231929
231930
231931
231932
231933
231934
231935
231936
231937
231938
231939
231940
231941
231942
231943
231944
231945
231946
231947
231948
231949
231950
231951
231952
231953
231954
231955
231956
231957
231958
231959
231960
231961
231962
231963
231964
231965
231966
231967
231968
231969
231970
231971
231972
231973
231974
231975
231976
231977
231978
231979
231980
231981
231982
231983
231984
231985
231986
231987
231988
231989
231990
231991
231992
231993
231994
231995
231996
231997
231998
231999
232000
232001
232002
232003
232004
232005
232006
232007
232008
232009
232010
232011
232012
232013
232014
232015
232016
232017
232018
232019
232020
232021
232022
232023
232024
232025
232026
232027
232028
232029
232030
232031
232032
232033
232034
232035
232036
232037
232038
232039
232040
232041
232042
232043
232044
232045
232046
232047
232048
232049
232050
232051
232052
232053
232054
232055
232056
232057
232058
232059
232060
232061
232062
232063
232064
232065
232066
232067
232068
232069
232070
232071
232072
232073
232074
232075
232076
232077
232078
232079
232080
232081
232082
232083
232084
232085
232086
232087
232088
232089
232090
232091
232092
232093
232094
232095
232096
232097
232098
232099
232100
232101
232102
232103
232104
232105
232106
232107
232108
232109
232110
232111
232112
232113
232114
232115
232116
232117
232118
232119
232120
232121
232122
232123
232124
232125
232126
232127
232128
232129
232130
232131
232132
232133
232134
232135
232136
232137
232138
232139
232140
232141
232142
232143
232144
232145
232146
232147
232148
232149
232150
232151
232152
232153
232154
232155
232156
232157
232158
232159
232160
232161
232162
232163
232164
232165
232166
232167
232168
232169
232170
232171
232172
232173
232174
232175
232176
232177
232178
232179
232180
232181
232182
232183
232184
232185
232186
232187
232188
232189
232190
232191
232192
232193
232194
232195
232196
232197
232198
232199
232200
232201
232202
232203
232204
232205
232206
232207
232208
232209
232210
232211
232212
232213
232214
232215
232216
232217
232218
232219
232220
232221
232222
232223
232224
232225
232226
232227
232228
232229
232230
232231
232232
232233
232234
232235
232236
232237
232238
232239
232240
232241
232242
232243
232244
232245
232246
232247
232248
232249
232250
232251
232252
232253
232254
232255
232256
232257
232258
232259
232260
232261
232262
232263
232264
232265
232266
232267
232268
232269
232270
232271
232272
232273
232274
232275
232276
232277
232278
232279
232280
232281
232282
232283
232284
232285
232286
232287
232288
232289
232290
232291
232292
232293
232294
232295
232296
232297
232298
232299
232300
232301
232302
232303
232304
232305
232306
232307
232308
232309
232310
232311
232312
232313
232314
232315
232316
232317
232318
232319
232320
232321
232322
232323
232324
232325
232326
232327
232328
232329
232330
232331
232332
232333
232334
232335
232336
232337
232338
232339
232340
232341
232342
232343
232344
232345
232346
232347
232348
232349
232350
232351
232352
232353
232354
232355
232356
232357
232358
232359
232360
232361
232362
232363
232364
232365
232366
232367
232368
232369
232370
232371
232372
232373
232374
232375
232376
232377
232378
232379
232380
232381
232382
232383
232384
232385
232386
232387
232388
232389
232390
232391
232392
232393
232394
232395
232396
232397
232398
232399
232400
232401
232402
232403
232404
232405
232406
232407
232408
232409
232410
232411
232412
232413
232414
232415
232416
232417
232418
232419
232420
232421
232422
232423
232424
232425
232426
232427
232428
232429
232430
232431
232432
232433
232434
232435
232436
232437
232438
232439
232440
232441
232442
232443
232444
232445
232446
232447
232448
232449
232450
232451
232452
232453
232454
232455
232456
232457
232458
232459
232460
232461
232462
232463
232464
232465
232466
232467
232468
232469
232470
232471
232472
232473
232474
232475
232476
232477
232478
232479
232480
232481
232482
232483
232484
232485
232486
232487
232488
232489
232490
232491
232492
232493
232494
232495
232496
232497
232498
232499
232500
232501
232502
232503
232504
232505
232506
232507
232508
232509
232510
232511
232512
232513
232514
232515
232516
232517
232518
232519
232520
232521
232522
232523
232524
232525
232526
232527
232528
232529
232530
232531
232532
232533
232534
232535
232536
232537
232538
232539
232540
232541
232542
232543
232544
232545
232546
232547
232548
232549
232550
232551
232552
232553
232554
232555
232556
232557
232558
232559
232560
232561
232562
232563
232564
232565
232566
232567
232568
232569
232570
232571
232572
232573
232574
232575
232576
232577
232578
232579
232580
232581
232582
232583
232584
232585
232586
232587
232588
232589
232590
232591
232592
232593
232594
232595
232596
232597
232598
232599
232600
232601
232602
232603
232604
232605
232606
232607
232608
232609
232610
232611
232612
232613
232614
232615
232616
232617
232618
232619
232620
232621
232622
232623
232624
232625
232626
232627
232628
232629
232630
232631
232632
232633
232634
232635
232636
232637
232638
232639
232640
232641
232642
232643
232644
232645
232646
232647
232648
232649
232650
232651
232652
232653
232654
232655
232656
232657
232658
232659
232660
232661
232662
232663
232664
232665
232666
232667
232668
232669
232670
232671
232672
232673
232674
232675
232676
232677
232678
232679
232680
232681
232682
232683
232684
232685
232686
232687
232688
232689
232690
232691
232692
232693
232694
232695
232696
232697
232698
232699
232700
232701
232702
232703
232704
232705
232706
232707
232708
232709
232710
232711
232712
232713
232714
232715
232716
232717
232718
232719
232720
232721
232722
232723
232724
232725
232726
232727
232728
232729
232730
232731
232732
232733
232734
232735
232736
232737
232738
232739
232740
232741
232742
232743
232744
232745
232746
232747
232748
232749
232750
232751
232752
232753
232754
232755
232756
232757
232758
232759
232760
232761
232762
232763
232764
232765
232766
232767
232768
232769
232770
232771
232772
232773
232774
232775
232776
232777
232778
232779
232780
232781
232782
232783
232784
232785
232786
232787
232788
232789
232790
232791
232792
232793
232794
232795
232796
232797
232798
232799
232800
232801
232802
232803
232804
232805
232806
232807
232808
232809
232810
232811
232812
232813
232814
232815
232816
232817
232818
232819
232820
232821
232822
232823
232824
232825
232826
232827
232828
232829
232830
232831
232832
232833
232834
232835
232836
232837
232838
232839
232840
232841
232842
232843
232844
232845
232846
232847
232848
232849
232850
232851
232852
232853
232854
232855
232856
232857
232858
232859
232860
232861
232862
232863
232864
232865
232866
232867
232868
232869
232870
232871
232872
232873
232874
232875
232876
232877
232878
232879
232880
232881
232882
232883
232884
232885
232886
232887
232888
232889
232890
232891
232892
232893
232894
232895
232896
232897
232898
232899
232900
232901
232902
232903
232904
232905
232906
232907
232908
232909
232910
232911
232912
232913
232914
232915
232916
232917
232918
232919
232920
232921
232922
232923
232924
232925
232926
232927
232928
232929
232930
232931
232932
232933
232934
232935
232936
232937
232938
232939
232940
232941
232942
232943
232944
232945
232946
232947
232948
232949
232950
232951
232952
232953
232954
232955
232956
232957
232958
232959
232960
232961
232962
232963
232964
232965
232966
232967
232968
232969
232970
232971
232972
232973
232974
232975
232976
232977
232978
232979
232980
232981
232982
232983
232984
232985
232986
232987
232988
232989
232990
232991
232992
232993
232994
232995
232996
232997
232998
232999
233000
233001
233002
233003
233004
233005
233006
233007
233008
233009
233010
233011
233012
233013
233014
233015
233016
233017
233018
233019
233020
233021
233022
233023
233024
233025
233026
233027
233028
233029
233030
233031
233032
233033
233034
233035
233036
233037
233038
233039
233040
233041
233042
233043
233044
233045
233046
233047
233048
233049
233050
233051
233052
233053
233054
233055
233056
233057
233058
233059
233060
233061
233062
233063
233064
233065
233066
233067
233068
233069
233070
233071
233072
233073
233074
233075
233076
233077
233078
233079
233080
233081
233082
233083
233084
233085
233086
233087
233088
233089
233090
233091
233092
233093
233094
233095
233096
233097
233098
233099
233100
233101
233102
233103
233104
233105
233106
233107
233108
233109
233110
233111
233112
233113
233114
233115
233116
233117
233118
233119
233120
233121
233122
233123
233124
233125
233126
233127
233128
233129
233130
233131
233132
233133
233134
233135
233136
233137
233138
233139
233140
233141
233142
233143
233144
233145
233146
233147
233148
233149
233150
233151
233152
233153
233154
233155
233156
233157
233158
233159
233160
233161
233162
233163
233164
233165
233166
233167
233168
233169
233170
233171
233172
233173
233174
233175
233176
233177
233178
233179
233180
233181
233182
233183
233184
233185
233186
233187
233188
233189
233190
233191
233192
233193
233194
233195
233196
233197
233198
233199
233200
233201
233202
233203
233204
233205
233206
233207
233208
233209
233210
233211
233212
233213
233214
233215
233216
233217
233218
233219
233220
233221
233222
233223
233224
233225
233226
233227
233228
233229
233230
233231
233232
233233
233234
233235
233236
233237
233238
233239
233240
233241
233242
233243
233244
233245
233246
233247
233248
233249
233250
233251
233252
233253
233254
233255
233256
233257
233258
233259
233260
233261
233262
233263
233264
233265
233266
233267
233268
233269
233270
233271
233272
233273
233274
233275
233276
233277
233278
233279
233280
233281
233282
233283
233284
233285
233286
233287
233288
233289
233290
233291
233292
233293
233294
233295
233296
233297
233298
233299
233300
233301
233302
233303
233304
233305
233306
233307
233308
233309
233310
233311
233312
233313
233314
233315
233316
233317
233318
233319
233320
233321
233322
233323
233324
233325
233326
233327
233328
233329
233330
233331
233332
233333
233334
233335
233336
233337
233338
233339
233340
233341
233342
233343
233344
233345
233346
233347
233348
233349
233350
233351
233352
233353
233354
233355
233356
233357
233358
233359
233360
233361
233362
233363
233364
233365
233366
233367
233368
233369
233370
233371
233372
233373
233374
233375
233376
233377
233378
233379
233380
233381
233382
233383
233384
233385
233386
233387
233388
233389
233390
233391
233392
233393
233394
233395
233396
233397
233398
233399
233400
233401
233402
233403
233404
233405
233406
233407
233408
233409
233410
233411
233412
233413
233414
233415
233416
233417
233418
233419
233420
233421
233422
233423
233424
233425
233426
233427
233428
233429
233430
233431
233432
233433
233434
233435
233436
233437
233438
233439
233440
233441
233442
233443
233444
233445
233446
233447
233448
233449
233450
233451
233452
233453
233454
233455
233456
233457
233458
233459
233460
233461
233462
233463
233464
233465
233466
233467
233468
233469
233470
233471
233472
233473
233474
233475
233476
233477
233478
233479
233480
233481
233482
233483
233484
233485
233486
233487
233488
233489
233490
233491
233492
233493
233494
233495
233496
233497
233498
233499
233500
233501
233502
233503
233504
233505
233506
233507
233508
233509
233510
233511
233512
233513
233514
233515
233516
233517
233518
233519
233520
233521
233522
233523
233524
233525
233526
233527
233528
233529
233530
233531
233532
233533
233534
233535
233536
233537
233538
233539
233540
233541
233542
233543
233544
233545
233546
233547
233548
233549
233550
233551
233552
233553
233554
233555
233556
233557
233558
233559
233560
233561
233562
233563
233564
233565
233566
233567
233568
233569
233570
233571
233572
233573
233574
233575
233576
233577
233578
233579
233580
233581
233582
233583
233584
233585
233586
233587
233588
233589
233590
233591
233592
233593
233594
233595
233596
233597
233598
233599
233600
233601
233602
233603
233604
233605
233606
233607
233608
233609
233610
233611
233612
233613
233614
233615
233616
233617
233618
233619
233620
233621
233622
233623
233624
233625
233626
233627
233628
233629
233630
233631
233632
233633
233634
233635
233636
233637
233638
233639
233640
233641
233642
233643
233644
233645
233646
233647
233648
233649
233650
233651
233652
233653
233654
233655
233656
233657
233658
233659
233660
233661
233662
233663
233664
233665
233666
233667
233668
233669
233670
233671
233672
233673
233674
233675
233676
233677
233678
233679
233680
233681
233682
233683
233684
233685
233686
233687
233688
233689
233690
233691
233692
233693
233694
233695
233696
233697
233698
233699
233700
233701
233702
233703
233704
233705
233706
233707
233708
233709
233710
233711
233712
233713
233714
233715
233716
233717
233718
233719
233720
233721
233722
233723
233724
233725
233726
233727
233728
233729
233730
233731
233732
233733
233734
233735
233736
233737
233738
233739
233740
233741
233742
233743
233744
233745
233746
233747
233748
233749
233750
233751
233752
233753
233754
233755
233756
233757
233758
233759
233760
233761
233762
233763
233764
233765
233766
233767
233768
233769
233770
233771
233772
233773
233774
233775
233776
233777
233778
233779
233780
233781
233782
233783
233784
233785
233786
233787
233788
233789
233790
233791
233792
233793
233794
233795
233796
233797
233798
233799
233800
233801
233802
233803
233804
233805
233806
233807
233808
233809
233810
233811
233812
233813
233814
233815
233816
233817
233818
233819
233820
233821
233822
233823
233824
233825
233826
233827
233828
233829
233830
233831
233832
233833
233834
233835
233836
233837
233838
233839
233840
233841
233842
233843
233844
233845
233846
233847
233848
233849
233850
233851
233852
233853
233854
233855
233856
233857
233858
233859
233860
233861
233862
233863
233864
233865
233866
233867
233868
233869
233870
233871
233872
233873
233874
233875
233876
233877
233878
233879
233880
233881
233882
233883
233884
233885
233886
233887
233888
233889
233890
233891
233892
233893
233894
233895
233896
233897
233898
233899
233900
233901
233902
233903
233904
233905
233906
233907
233908
233909
233910
233911
233912
233913
233914
233915
233916
233917
233918
233919
233920
233921
233922
233923
233924
233925
233926
233927
233928
233929
233930
233931
233932
233933
233934
233935
233936
233937
233938
233939
233940
233941
233942
233943
233944
233945
233946
233947
233948
233949
233950
233951
233952
233953
233954
233955
233956
233957
233958
233959
233960
233961
233962
233963
233964
233965
233966
233967
233968
233969
233970
233971
233972
233973
233974
233975
233976
233977
233978
233979
233980
233981
233982
233983
233984
233985
233986
233987
233988
233989
233990
233991
233992
233993
233994
233995
233996
233997
233998
233999
234000
234001
234002
234003
234004
234005
234006
234007
234008
234009
234010
234011
234012
234013
234014
234015
234016
234017
234018
234019
234020
234021
234022
234023
234024
234025
234026
234027
234028
234029
234030
234031
234032
234033
234034
234035
234036
234037
234038
234039
234040
234041
234042
234043
234044
234045
234046
234047
234048
234049
234050
234051
234052
234053
234054
234055
234056
234057
234058
234059
234060
234061
234062
234063
234064
234065
234066
234067
234068
234069
234070
234071
234072
234073
234074
234075
234076
234077
234078
234079
234080
234081
234082
234083
234084
234085
234086
234087
234088
234089
234090
234091
234092
234093
234094
234095
234096
234097
234098
234099
234100
234101
234102
234103
234104
234105
234106
234107
234108
234109
234110
234111
234112
234113
234114
234115
234116
234117
234118
234119
234120
234121
234122
234123
234124
234125
234126
234127
234128
234129
234130
234131
234132
234133
234134
234135
234136
234137
234138
234139
234140
234141
234142
234143
234144
234145
234146
234147
234148
234149
234150
234151
234152
234153
234154
234155
234156
234157
234158
234159
234160
234161
234162
234163
234164
234165
234166
234167
234168
234169
234170
234171
234172
234173
234174
234175
234176
234177
234178
234179
234180
234181
234182
234183
234184
234185
234186
234187
234188
234189
234190
234191
234192
234193
234194
234195
234196
234197
234198
234199
234200
234201
234202
234203
234204
234205
234206
234207
234208
234209
234210
234211
234212
234213
234214
234215
234216
234217
234218
234219
234220
234221
234222
234223
234224
234225
234226
234227
234228
234229
234230
234231
234232
234233
234234
234235
234236
234237
234238
234239
234240
234241
234242
234243
234244
234245
234246
234247
234248
234249
234250
234251
234252
234253
234254
234255
234256
234257
234258
234259
234260
234261
234262
234263
234264
234265
234266
234267
234268
234269
234270
234271
234272
234273
234274
234275
234276
234277
234278
234279
234280
234281
234282
234283
234284
234285
234286
234287
234288
234289
234290
234291
234292
234293
234294
234295
234296
234297
234298
234299
234300
234301
234302
234303
234304
234305
234306
234307
234308
234309
234310
234311
234312
234313
234314
234315
234316
234317
234318
234319
234320
234321
234322
234323
234324
234325
234326
234327
234328
234329
234330
234331
234332
234333
234334
234335
234336
234337
234338
234339
234340
234341
234342
234343
234344
234345
234346
234347
234348
234349
234350
234351
234352
234353
234354
234355
234356
234357
234358
234359
234360
234361
234362
234363
234364
234365
234366
234367
234368
234369
234370
234371
234372
234373
234374
234375
234376
234377
234378
234379
234380
234381
234382
234383
234384
234385
234386
234387
234388
234389
234390
234391
234392
234393
234394
234395
234396
234397
234398
234399
234400
234401
234402
234403
234404
234405
234406
234407
234408
234409
234410
234411
234412
234413
234414
234415
234416
234417
234418
234419
234420
234421
234422
234423
234424
234425
234426
234427
234428
234429
234430
234431
234432
234433
234434
234435
234436
234437
234438
234439
234440
234441
234442
234443
234444
234445
234446
234447
234448
234449
234450
234451
234452
234453
234454
234455
234456
234457
234458
234459
234460
234461
234462
234463
234464
234465
234466
234467
234468
234469
234470
234471
234472
234473
234474
234475
234476
234477
234478
234479
234480
234481
234482
234483
234484
234485
234486
234487
234488
234489
234490
234491
234492
234493
234494
234495
234496
234497
234498
234499
234500
234501
234502
234503
234504
234505
234506
234507
234508
234509
234510
234511
234512
234513
234514
234515
234516
234517
234518
234519
234520
234521
234522
234523
234524
234525
234526
234527
234528
234529
234530
234531
234532
234533
234534
234535
234536
234537
234538
234539
234540
234541
234542
234543
234544
234545
234546
234547
234548
234549
234550
234551
234552
234553
234554
234555
234556
234557
234558
234559
234560
234561
234562
234563
234564
234565
234566
234567
234568
234569
234570
234571
234572
234573
234574
234575
234576
234577
234578
234579
234580
234581
234582
234583
234584
234585
234586
234587
234588
234589
234590
234591
234592
234593
234594
234595
234596
234597
234598
234599
234600
234601
234602
234603
234604
234605
234606
234607
234608
234609
234610
234611
234612
234613
234614
234615
234616
234617
234618
234619
234620
234621
234622
234623
234624
234625
234626
234627
234628
234629
234630
234631
234632
234633
234634
234635
234636
234637
234638
234639
234640
234641
234642
234643
234644
234645
234646
234647
234648
234649
234650
234651
234652
234653
234654
234655
234656
234657
234658
234659
234660
234661
234662
234663
234664
234665
234666
234667
234668
234669
234670
234671
234672
234673
234674
234675
234676
234677
234678
234679
234680
234681
234682
234683
234684
234685
234686
234687
234688
234689
234690
234691
234692
234693
234694
234695
234696
234697
234698
234699
234700
234701
234702
234703
234704
234705
234706
234707
234708
234709
234710
234711
234712
234713
234714
234715
234716
234717
234718
234719
234720
234721
234722
234723
234724
234725
234726
234727
234728
234729
234730
234731
234732
234733
234734
234735
234736
234737
234738
234739
234740
234741
234742
234743
234744
234745
234746
234747
234748
234749
234750
234751
234752
234753
234754
234755
234756
234757
234758
234759
234760
234761
234762
234763
234764
234765
234766
234767
234768
234769
234770
234771
234772
234773
234774
234775
234776
234777
234778
234779
234780
234781
234782
234783
234784
234785
234786
234787
234788
234789
234790
234791
234792
234793
234794
234795
234796
234797
234798
234799
234800
234801
234802
234803
234804
234805
234806
234807
234808
234809
234810
234811
234812
234813
234814
234815
234816
234817
234818
234819
234820
234821
234822
234823
234824
234825
234826
234827
234828
234829
234830
234831
234832
234833
234834
234835
234836
234837
234838
234839
234840
234841
234842
234843
234844
234845
234846
234847
234848
234849
234850
234851
234852
234853
234854
234855
234856
234857
234858
234859
234860
234861
234862
234863
234864
234865
234866
234867
234868
234869
234870
234871
234872
234873
234874
234875
234876
234877
234878
234879
234880
234881
234882
234883
234884
234885
234886
234887
234888
234889
234890
234891
234892
234893
234894
234895
234896
234897
234898
234899
234900
234901
234902
234903
234904
234905
234906
234907
234908
234909
234910
234911
234912
234913
234914
234915
234916
234917
234918
234919
234920
234921
234922
234923
234924
234925
234926
234927
234928
234929
234930
234931
234932
234933
234934
234935
234936
234937
234938
234939
234940
234941
234942
234943
234944
234945
234946
234947
234948
234949
234950
234951
234952
234953
234954
234955
234956
234957
234958
234959
234960
234961
234962
234963
234964
234965
234966
234967
234968
234969
234970
234971
234972
234973
234974
234975
234976
234977
234978
234979
234980
234981
234982
234983
234984
234985
234986
234987
234988
234989
234990
234991
234992
234993
234994
234995
234996
234997
234998
234999
235000
235001
235002
235003
235004
235005
235006
235007
235008
235009
235010
235011
235012
235013
235014
235015
235016
235017
235018
235019
235020
235021
235022
235023
235024
235025
235026
235027
235028
235029
235030
235031
235032
235033
235034
235035
235036
235037
235038
235039
235040
235041
235042
235043
235044
235045
235046
235047
235048
235049
235050
235051
235052
235053
235054
235055
235056
235057
235058
235059
235060
235061
235062
235063
235064
235065
235066
235067
235068
235069
235070
235071
235072
235073
235074
235075
235076
235077
235078
235079
235080
235081
235082
235083
235084
235085
235086
235087
235088
235089
235090
235091
235092
235093
235094
235095
235096
235097
235098
235099
235100
235101
235102
235103
235104
235105
235106
235107
235108
235109
235110
235111
235112
235113
235114
235115
235116
235117
235118
235119
235120
235121
235122
235123
235124
235125
235126
235127
235128
235129
235130
235131
235132
235133
235134
235135
235136
235137
235138
235139
235140
235141
235142
235143
235144
235145
235146
235147
235148
235149
235150
235151
235152
235153
235154
235155
235156
235157
235158
235159
235160
235161
235162
235163
235164
235165
235166
235167
235168
235169
235170
235171
235172
235173
235174
235175
235176
235177
235178
235179
235180
235181
235182
235183
235184
235185
235186
235187
235188
235189
235190
235191
235192
235193
235194
235195
235196
235197
235198
235199
235200
235201
235202
235203
235204
235205
235206
235207
235208
235209
235210
235211
235212
235213
235214
235215
235216
235217
235218
235219
235220
235221
235222
235223
235224
235225
235226
235227
235228
235229
235230
235231
235232
235233
235234
235235
235236
235237
235238
235239
235240
235241
235242
235243
235244
235245
235246
235247
235248
235249
235250
235251
235252
235253
235254
235255
235256
235257
235258
235259
235260
235261
235262
235263
235264
235265
235266
235267
235268
235269
235270
235271
235272
235273
235274
235275
235276
235277
235278
235279
235280
235281
235282
235283
235284
235285
235286
235287
235288
235289
235290
235291
235292
235293
235294
235295
235296
235297
235298
235299
235300
235301
235302
235303
235304
235305
235306
235307
235308
235309
235310
235311
235312
235313
235314
235315
235316
235317
235318
235319
235320
235321
235322
235323
235324
235325
235326
235327
235328
235329
235330
235331
235332
235333
235334
235335
235336
235337
235338
235339
235340
235341
235342
235343
235344
235345
235346
235347
235348
235349
235350
235351
235352
235353
235354
235355
235356
235357
235358
235359
235360
235361
235362
235363
235364
235365
235366
235367
235368
235369
235370
235371
235372
235373
235374
235375
235376
235377
235378
235379
235380
235381
235382
235383
235384
235385
235386
235387
235388
235389
235390
235391
235392
235393
235394
235395
235396
235397
235398
235399
235400
235401
235402
235403
235404
235405
235406
235407
235408
235409
235410
235411
235412
235413
235414
235415
235416
235417
235418
235419
235420
235421
235422
235423
235424
235425
235426
235427
235428
235429
235430
235431
235432
235433
235434
235435
235436
235437
235438
235439
235440
235441
235442
235443
235444
235445
235446
235447
235448
235449
235450
235451
235452
235453
235454
235455
235456
235457
235458
235459
235460
235461
235462
235463
235464
235465
235466
235467
235468
235469
235470
235471
235472
235473
235474
235475
235476
235477
235478
235479
235480
235481
235482
235483
235484
235485
235486
235487
235488
235489
235490
235491
235492
235493
235494
235495
235496
235497
235498
235499
235500
235501
235502
235503
235504
235505
235506
235507
235508
235509
235510
235511
235512
235513
235514
235515
235516
235517
235518
235519
235520
235521
235522
235523
235524
235525
235526
235527
235528
235529
235530
235531
235532
235533
235534
235535
235536
235537
235538
235539
235540
235541
235542
235543
235544
235545
235546
235547
235548
235549
235550
235551
235552
235553
235554
235555
235556
235557
235558
235559
235560
235561
235562
235563
235564
235565
235566
235567
235568
235569
235570
235571
235572
235573
235574
235575
235576
235577
235578
235579
235580
235581
235582
235583
235584
235585
235586
235587
235588
235589
235590
235591
235592
235593
235594
235595
235596
235597
235598
235599
235600
235601
235602
235603
235604
235605
235606
235607
235608
235609
235610
235611
235612
235613
235614
235615
235616
235617
235618
235619
235620
235621
235622
235623
235624
235625
235626
235627
235628
235629
235630
235631
235632
235633
235634
235635
235636
235637
235638
235639
235640
235641
235642
235643
235644
235645
235646
235647
235648
235649
235650
235651
235652
235653
235654
235655
235656
235657
235658
235659
235660
235661
235662
235663
235664
235665
235666
235667
235668
235669
235670
235671
235672
235673
235674
235675
235676
235677
235678
235679
235680
235681
235682
235683
235684
235685
235686
235687
235688
235689
235690
235691
235692
235693
235694
235695
235696
235697
235698
235699
235700
235701
235702
235703
235704
235705
235706
235707
235708
235709
235710
235711
235712
235713
235714
235715
235716
235717
235718
235719
235720
235721
235722
235723
235724
235725
235726
235727
235728
235729
235730
235731
235732
235733
235734
235735
235736
235737
235738
235739
235740
235741
235742
235743
235744
235745
235746
235747
235748
235749
235750
235751
235752
235753
235754
235755
235756
235757
235758
235759
235760
235761
235762
235763
235764
235765
235766
235767
235768
235769
235770
235771
235772
235773
235774
235775
235776
235777
235778
235779
235780
235781
235782
235783
235784
235785
235786
235787
235788
235789
235790
235791
235792
235793
235794
235795
235796
235797
235798
235799
235800
235801
235802
235803
235804
235805
235806
235807
235808
235809
235810
235811
235812
235813
235814
235815
235816
235817
235818
235819
235820
235821
235822
235823
235824
235825
235826
235827
235828
235829
235830
235831
235832
235833
235834
235835
235836
235837
235838
235839
235840
235841
235842
235843
235844
235845
235846
235847
235848
235849
235850
235851
235852
235853
235854
235855
235856
235857
235858
235859
235860
235861
235862
235863
235864
235865
235866
235867
235868
235869
235870
235871
235872
235873
235874
235875
235876
235877
235878
235879
235880
235881
235882
235883
235884
235885
235886
235887
235888
235889
235890
235891
235892
235893
235894
235895
235896
235897
235898
235899
235900
235901
235902
235903
235904
235905
235906
235907
235908
235909
235910
235911
235912
235913
235914
235915
235916
235917
235918
235919
235920
235921
235922
235923
235924
235925
235926
235927
235928
235929
235930
235931
235932
235933
235934
235935
235936
235937
235938
235939
235940
235941
235942
235943
235944
235945
235946
235947
235948
235949
235950
235951
235952
235953
235954
235955
235956
235957
235958
235959
235960
235961
235962
235963
235964
235965
235966
235967
235968
235969
235970
235971
235972
235973
235974
235975
235976
235977
235978
235979
235980
235981
235982
235983
235984
235985
235986
235987
235988
235989
235990
235991
235992
235993
235994
235995
235996
235997
235998
235999
236000
236001
236002
236003
236004
236005
236006
236007
236008
236009
236010
236011
236012
236013
236014
236015
236016
236017
236018
236019
236020
236021
236022
236023
236024
236025
236026
236027
236028
236029
236030
236031
236032
236033
236034
236035
236036
236037
236038
236039
236040
236041
236042
236043
236044
236045
236046
236047
236048
236049
236050
236051
236052
236053
236054
236055
236056
236057
236058
236059
236060
236061
236062
236063
236064
236065
236066
236067
236068
236069
236070
236071
236072
236073
236074
236075
236076
236077
236078
236079
236080
236081
236082
236083
236084
236085
236086
236087
236088
236089
236090
236091
236092
236093
236094
236095
236096
236097
236098
236099
236100
236101
236102
236103
236104
236105
236106
236107
236108
236109
236110
236111
236112
236113
236114
236115
236116
236117
236118
236119
236120
236121
236122
236123
236124
236125
236126
236127
236128
236129
236130
236131
236132
236133
236134
236135
236136
236137
236138
236139
236140
236141
236142
236143
236144
236145
236146
236147
236148
236149
236150
236151
236152
236153
236154
236155
236156
236157
236158
236159
236160
236161
236162
236163
236164
236165
236166
236167
236168
236169
236170
236171
236172
236173
236174
236175
236176
236177
236178
236179
236180
236181
236182
236183
236184
236185
236186
236187
236188
236189
236190
236191
236192
236193
236194
236195
236196
236197
236198
236199
236200
236201
236202
236203
236204
236205
236206
236207
236208
236209
236210
236211
236212
236213
236214
236215
236216
236217
236218
236219
236220
236221
236222
236223
236224
236225
236226
236227
236228
236229
236230
236231
236232
236233
236234
236235
236236
236237
236238
236239
236240
236241
236242
236243
236244
236245
236246
236247
236248
236249
236250
236251
236252
236253
236254
236255
236256
236257
236258
236259
236260
236261
236262
236263
236264
236265
236266
236267
236268
236269
236270
236271
236272
236273
236274
236275
236276
236277
236278
236279
236280
236281
236282
236283
236284
236285
236286
236287
236288
236289
236290
236291
236292
236293
236294
236295
236296
236297
236298
236299
236300
236301
236302
236303
236304
236305
236306
236307
236308
236309
236310
236311
236312
236313
236314
236315
236316
236317
236318
236319
236320
236321
236322
236323
236324
236325
236326
236327
236328
236329
236330
236331
236332
236333
236334
236335
236336
236337
236338
236339
236340
236341
236342
236343
236344
236345
236346
236347
236348
236349
236350
236351
236352
236353
236354
236355
236356
236357
236358
236359
236360
236361
236362
236363
236364
236365
236366
236367
236368
236369
236370
236371
236372
236373
236374
236375
236376
236377
236378
236379
236380
236381
236382
236383
236384
236385
236386
236387
236388
236389
236390
236391
236392
236393
236394
236395
236396
236397
236398
236399
236400
236401
236402
236403
236404
236405
236406
236407
236408
236409
236410
236411
236412
236413
236414
236415
236416
236417
236418
236419
236420
236421
236422
236423
236424
236425
236426
236427
236428
236429
236430
236431
236432
236433
236434
236435
236436
236437
236438
236439
236440
236441
236442
236443
236444
236445
236446
236447
236448
236449
236450
236451
236452
236453
236454
236455
236456
236457
236458
236459
236460
236461
236462
236463
236464
236465
236466
236467
236468
236469
236470
236471
236472
236473
236474
236475
236476
236477
236478
236479
236480
236481
236482
236483
236484
236485
236486
236487
236488
236489
236490
236491
236492
236493
236494
236495
236496
236497
236498
236499
236500
236501
236502
236503
236504
236505
236506
236507
236508
236509
236510
236511
236512
236513
236514
236515
236516
236517
236518
236519
236520
236521
236522
236523
236524
236525
236526
236527
236528
236529
236530
236531
236532
236533
236534
236535
236536
236537
236538
236539
236540
236541
236542
236543
236544
236545
236546
236547
236548
236549
236550
236551
236552
236553
236554
236555
236556
236557
236558
236559
236560
236561
236562
236563
236564
236565
236566
236567
236568
236569
236570
236571
236572
236573
236574
236575
236576
236577
236578
236579
236580
236581
236582
236583
236584
236585
236586
236587
236588
236589
236590
236591
236592
236593
236594
236595
236596
236597
236598
236599
236600
236601
236602
236603
236604
236605
236606
236607
236608
236609
236610
236611
236612
236613
236614
236615
236616
236617
236618
236619
236620
236621
236622
236623
236624
236625
236626
236627
236628
236629
236630
236631
236632
236633
236634
236635
236636
236637
236638
236639
236640
236641
236642
236643
236644
236645
236646
236647
236648
236649
236650
236651
236652
236653
236654
236655
236656
236657
236658
236659
236660
236661
236662
236663
236664
236665
236666
236667
236668
236669
236670
236671
236672
236673
236674
236675
236676
236677
236678
236679
236680
236681
236682
236683
236684
236685
236686
236687
236688
236689
236690
236691
236692
236693
236694
236695
236696
236697
236698
236699
236700
236701
236702
236703
236704
236705
236706
236707
236708
236709
236710
236711
236712
236713
236714
236715
236716
236717
236718
236719
236720
236721
236722
236723
236724
236725
236726
236727
236728
236729
236730
236731
236732
236733
236734
236735
236736
236737
236738
236739
236740
236741
236742
236743
236744
236745
236746
236747
236748
236749
236750
236751
236752
236753
236754
236755
236756
236757
236758
236759
236760
236761
236762
236763
236764
236765
236766
236767
236768
236769
236770
236771
236772
236773
236774
236775
236776
236777
236778
236779
236780
236781
236782
236783
236784
236785
236786
236787
236788
236789
236790
236791
236792
236793
236794
236795
236796
236797
236798
236799
236800
236801
236802
236803
236804
236805
236806
236807
236808
236809
236810
236811
236812
236813
236814
236815
236816
236817
236818
236819
236820
236821
236822
236823
236824
236825
236826
236827
236828
236829
236830
236831
236832
236833
236834
236835
236836
236837
236838
236839
236840
236841
236842
236843
236844
236845
236846
236847
236848
236849
236850
236851
236852
236853
236854
236855
236856
236857
236858
236859
236860
236861
236862
236863
236864
236865
236866
236867
236868
236869
236870
236871
236872
236873
236874
236875
236876
236877
236878
236879
236880
236881
236882
236883
236884
236885
236886
236887
236888
236889
236890
236891
236892
236893
236894
236895
236896
236897
236898
236899
236900
236901
236902
236903
236904
236905
236906
236907
236908
236909
236910
236911
236912
236913
236914
236915
236916
236917
236918
236919
236920
236921
236922
236923
236924
236925
236926
236927
236928
236929
236930
236931
236932
236933
236934
236935
236936
236937
236938
236939
236940
236941
236942
236943
236944
236945
236946
236947
236948
236949
236950
236951
236952
236953
236954
236955
236956
236957
236958
236959
236960
236961
236962
236963
236964
236965
236966
236967
236968
236969
236970
236971
236972
236973
236974
236975
236976
236977
236978
236979
236980
236981
236982
236983
236984
236985
236986
236987
236988
236989
236990
236991
236992
236993
236994
236995
236996
236997
236998
236999
237000
237001
237002
237003
237004
237005
237006
237007
237008
237009
237010
237011
237012
237013
237014
237015
237016
237017
237018
237019
237020
237021
237022
237023
237024
237025
237026
237027
237028
237029
237030
237031
237032
237033
237034
237035
237036
237037
237038
237039
237040
237041
237042
237043
237044
237045
237046
237047
237048
237049
237050
237051
237052
237053
237054
237055
237056
237057
237058
237059
237060
237061
237062
237063
237064
237065
237066
237067
237068
237069
237070
237071
237072
237073
237074
237075
237076
237077
237078
237079
237080
237081
237082
237083
237084
237085
237086
237087
237088
237089
237090
237091
237092
237093
237094
237095
237096
237097
237098
237099
237100
237101
237102
237103
237104
237105
237106
237107
237108
237109
237110
237111
237112
237113
237114
237115
237116
237117
237118
237119
237120
237121
237122
237123
237124
237125
237126
237127
237128
237129
237130
237131
237132
237133
237134
237135
237136
237137
237138
237139
237140
237141
237142
237143
237144
237145
237146
237147
237148
237149
237150
237151
237152
237153
237154
237155
237156
237157
237158
237159
237160
237161
237162
237163
237164
237165
237166
237167
237168
237169
237170
237171
237172
237173
237174
237175
237176
237177
237178
237179
237180
237181
237182
237183
237184
237185
237186
237187
237188
237189
237190
237191
237192
237193
237194
237195
237196
237197
237198
237199
237200
237201
237202
237203
237204
237205
237206
237207
237208
237209
237210
237211
237212
237213
237214
237215
237216
237217
237218
237219
237220
237221
237222
237223
237224
237225
237226
237227
237228
237229
237230
237231
237232
237233
237234
237235
237236
237237
237238
237239
237240
237241
237242
237243
237244
237245
237246
237247
237248
237249
237250
237251
237252
237253
237254
237255
237256
237257
237258
237259
237260
237261
237262
237263
237264
237265
237266
237267
237268
237269
237270
237271
237272
237273
237274
237275
237276
237277
237278
237279
237280
237281
237282
237283
237284
237285
237286
237287
237288
237289
237290
237291
237292
237293
237294
237295
237296
237297
237298
237299
237300
237301
237302
237303
237304
237305
237306
237307
237308
237309
237310
237311
237312
237313
237314
237315
237316
237317
237318
237319
237320
237321
237322
237323
237324
237325
237326
237327
237328
237329
237330
237331
237332
237333
237334
237335
237336
237337
237338
237339
237340
237341
237342
237343
237344
237345
237346
237347
237348
237349
237350
237351
237352
237353
237354
237355
237356
237357
237358
237359
237360
237361
237362
237363
237364
237365
237366
237367
237368
237369
237370
237371
237372
237373
237374
237375
237376
237377
237378
237379
237380
237381
237382
237383
237384
237385
237386
237387
237388
237389
237390
237391
237392
237393
237394
237395
237396
237397
237398
237399
237400
237401
237402
237403
237404
237405
237406
237407
237408
237409
237410
237411
237412
237413
237414
237415
237416
237417
237418
237419
237420
237421
237422
237423
237424
237425
237426
237427
237428
237429
237430
237431
237432
237433
237434
237435
237436
237437
237438
237439
237440
237441
237442
237443
237444
237445
237446
237447
237448
237449
237450
237451
237452
237453
237454
237455
237456
237457
237458
237459
237460
237461
237462
237463
237464
237465
237466
237467
237468
237469
237470
237471
237472
237473
237474
237475
237476
237477
237478
237479
237480
237481
237482
237483
237484
237485
237486
237487
237488
237489
237490
237491
237492
237493
237494
237495
237496
237497
237498
237499
237500
237501
237502
237503
237504
237505
237506
237507
237508
237509
237510
237511
237512
237513
237514
237515
237516
237517
237518
237519
237520
237521
237522
237523
237524
237525
237526
237527
237528
237529
237530
237531
237532
237533
237534
237535
237536
237537
237538
237539
237540
237541
237542
237543
237544
237545
237546
237547
237548
237549
237550
237551
237552
237553
237554
237555
237556
237557
237558
237559
237560
237561
237562
237563
237564
237565
237566
237567
237568
237569
237570
237571
237572
237573
237574
237575
237576
237577
237578
237579
237580
237581
237582
237583
237584
237585
237586
237587
237588
237589
237590
237591
237592
237593
237594
237595
237596
237597
237598
237599
237600
237601
237602
237603
237604
237605
237606
237607
237608
237609
237610
237611
237612
237613
237614
237615
237616
237617
237618
237619
237620
237621
237622
237623
237624
237625
237626
237627
237628
237629
237630
237631
237632
237633
237634
237635
237636
237637
237638
237639
237640
237641
237642
237643
237644
237645
237646
237647
237648
237649
237650
237651
237652
237653
237654
237655
237656
237657
237658
237659
237660
237661
237662
237663
237664
237665
237666
237667
237668
237669
237670
237671
237672
237673
237674
237675
237676
237677
237678
237679
237680
237681
237682
237683
237684
237685
237686
237687
237688
237689
237690
237691
237692
237693
237694
237695
237696
237697
237698
237699
237700
237701
237702
237703
237704
237705
237706
237707
237708
237709
237710
237711
237712
237713
237714
237715
237716
237717
237718
237719
237720
237721
237722
237723
237724
237725
237726
237727
237728
237729
237730
237731
237732
237733
237734
237735
237736
237737
237738
237739
237740
237741
237742
237743
237744
237745
237746
237747
237748
237749
237750
237751
237752
237753
237754
237755
237756
237757
237758
237759
237760
237761
237762
237763
237764
237765
237766
237767
237768
237769
237770
237771
237772
237773
237774
237775
237776
237777
237778
237779
237780
237781
237782
237783
237784
237785
237786
237787
237788
237789
237790
237791
237792
237793
237794
237795
237796
237797
237798
237799
237800
237801
237802
237803
237804
237805
237806
237807
237808
237809
237810
237811
237812
237813
237814
237815
237816
237817
237818
237819
237820
237821
237822
237823
237824
237825
237826
237827
237828
237829
237830
237831
237832
237833
237834
237835
237836
237837
237838
237839
237840
237841
237842
237843
237844
237845
237846
237847
237848
237849
237850
237851
237852
237853
237854
237855
237856
237857
237858
237859
237860
237861
237862
237863
237864
237865
237866
237867
237868
237869
237870
237871
237872
237873
237874
237875
237876
237877
237878
237879
237880
237881
237882
237883
237884
237885
237886
237887
237888
237889
237890
237891
237892
237893
237894
237895
237896
237897
237898
237899
237900
237901
237902
237903
237904
237905
237906
237907
237908
237909
237910
237911
237912
237913
237914
237915
237916
237917
237918
237919
237920
237921
237922
237923
237924
237925
237926
237927
237928
237929
237930
237931
237932
237933
237934
237935
237936
237937
237938
237939
237940
237941
237942
237943
237944
237945
237946
237947
237948
237949
237950
237951
237952
237953
237954
237955
237956
237957
237958
237959
237960
237961
237962
237963
237964
237965
237966
237967
237968
237969
237970
237971
237972
237973
237974
237975
237976
237977
237978
237979
237980
237981
237982
237983
237984
237985
237986
237987
237988
237989
237990
237991
237992
237993
237994
237995
237996
237997
237998
237999
238000
238001
238002
238003
238004
238005
238006
238007
238008
238009
238010
238011
238012
238013
238014
238015
238016
238017
238018
238019
238020
238021
238022
238023
238024
238025
238026
238027
238028
238029
238030
238031
238032
238033
238034
238035
238036
238037
238038
238039
238040
238041
238042
238043
238044
238045
238046
238047
238048
238049
238050
238051
238052
238053
238054
238055
238056
238057
238058
238059
238060
238061
238062
238063
238064
238065
238066
238067
238068
238069
238070
238071
238072
238073
238074
238075
238076
238077
238078
238079
238080
238081
238082
238083
238084
238085
238086
238087
238088
238089
238090
238091
238092
238093
238094
238095
238096
238097
238098
238099
238100
238101
238102
238103
238104
238105
238106
238107
238108
238109
238110
238111
238112
238113
238114
238115
238116
238117
238118
238119
238120
238121
238122
238123
238124
238125
238126
238127
238128
238129
238130
238131
238132
238133
238134
238135
238136
238137
238138
238139
238140
238141
238142
238143
238144
238145
238146
238147
238148
238149
238150
238151
238152
238153
238154
238155
238156
238157
238158
238159
238160
238161
238162
238163
238164
238165
238166
238167
238168
238169
238170
238171
238172
238173
238174
238175
238176
238177
238178
238179
238180
238181
238182
238183
238184
238185
238186
238187
238188
238189
238190
238191
238192
238193
238194
238195
238196
238197
238198
238199
238200
238201
238202
238203
238204
238205
238206
238207
238208
238209
238210
238211
238212
238213
238214
238215
238216
238217
238218
238219
238220
238221
238222
238223
238224
238225
238226
238227
238228
238229
238230
238231
238232
238233
238234
238235
238236
238237
238238
238239
238240
238241
238242
238243
238244
238245
238246
238247
238248
238249
238250
238251
238252
238253
238254
238255
238256
238257
238258
238259
238260
238261
238262
238263
238264
238265
238266
238267
238268
238269
238270
238271
238272
238273
238274
238275
238276
238277
238278
238279
238280
238281
238282
238283
238284
238285
238286
238287
238288
238289
238290
238291
238292
238293
238294
238295
238296
238297
238298
238299
238300
238301
238302
238303
238304
238305
238306
238307
238308
238309
238310
238311
238312
238313
238314
238315
238316
238317
238318
238319
238320
238321
238322
238323
238324
238325
238326
238327
238328
238329
238330
238331
238332
238333
238334
238335
238336
238337
238338
238339
238340
238341
238342
238343
238344
238345
238346
238347
238348
238349
238350
238351
238352
238353
238354
238355
238356
238357
238358
238359
238360
238361
238362
238363
238364
238365
238366
238367
238368
238369
238370
238371
238372
238373
238374
238375
238376
238377
238378
238379
238380
238381
238382
238383
238384
238385
238386
238387
238388
238389
238390
238391
238392
238393
238394
238395
238396
238397
238398
238399
238400
238401
238402
238403
238404
238405
238406
238407
238408
238409
238410
238411
238412
238413
238414
238415
238416
238417
238418
238419
238420
238421
238422
238423
238424
238425
238426
238427
238428
238429
238430
238431
238432
238433
238434
238435
238436
238437
238438
238439
238440
238441
238442
238443
238444
238445
238446
238447
238448
238449
238450
238451
238452
238453
238454
238455
238456
238457
238458
238459
238460
238461
238462
238463
238464
238465
238466
238467
238468
238469
238470
238471
238472
238473
238474
238475
238476
238477
238478
238479
238480
238481
238482
238483
238484
238485
238486
238487
238488
238489
238490
238491
238492
238493
238494
238495
238496
238497
238498
238499
238500
238501
238502
238503
238504
238505
238506
238507
238508
238509
238510
238511
238512
238513
238514
238515
238516
238517
238518
238519
238520
238521
238522
238523
238524
238525
238526
238527
238528
238529
238530
238531
238532
238533
238534
238535
238536
238537
238538
238539
238540
238541
238542
238543
238544
238545
238546
238547
238548
238549
238550
238551
238552
238553
238554
238555
238556
238557
238558
238559
238560
238561
238562
238563
238564
238565
238566
238567
238568
238569
238570
238571
238572
238573
238574
238575
238576
238577
238578
238579
238580
238581
238582
238583
238584
238585
238586
238587
238588
238589
238590
238591
238592
238593
238594
238595
238596
238597
238598
238599
238600
238601
238602
238603
238604
238605
238606
238607
238608
238609
238610
238611
238612
238613
238614
238615
238616
238617
238618
238619
238620
238621
238622
238623
238624
238625
238626
238627
238628
238629
238630
238631
238632
238633
238634
238635
238636
238637
238638
238639
238640
238641
238642
238643
238644
238645
238646
238647
238648
238649
238650
238651
238652
238653
238654
238655
238656
238657
238658
238659
238660
238661
238662
238663
238664
238665
238666
238667
238668
238669
238670
238671
238672
238673
238674
238675
238676
238677
238678
238679
238680
238681
238682
238683
238684
238685
238686
238687
238688
238689
238690
238691
238692
238693
238694
238695
238696
238697
238698
238699
238700
238701
238702
238703
238704
238705
238706
238707
238708
238709
238710
238711
238712
238713
238714
238715
238716
238717
238718
238719
238720
238721
238722
238723
238724
238725
238726
238727
238728
238729
238730
238731
238732
238733
238734
238735
238736
238737
238738
238739
238740
238741
238742
238743
238744
238745
238746
238747
238748
238749
238750
238751
238752
238753
238754
238755
238756
238757
238758
238759
238760
238761
238762
238763
238764
238765
238766
238767
238768
238769
238770
238771
238772
238773
238774
238775
238776
238777
238778
238779
238780
238781
238782
238783
238784
238785
238786
238787
238788
238789
238790
238791
238792
238793
238794
238795
238796
238797
238798
238799
238800
238801
238802
238803
238804
238805
238806
238807
238808
238809
238810
238811
238812
238813
238814
238815
238816
238817
238818
238819
238820
238821
238822
238823
238824
238825
238826
238827
238828
238829
238830
238831
238832
238833
238834
238835
238836
238837
238838
238839
238840
238841
238842
238843
238844
238845
238846
238847
238848
238849
238850
238851
238852
238853
238854
238855
238856
238857
238858
238859
238860
238861
238862
238863
238864
238865
238866
238867
238868
238869
238870
238871
238872
238873
238874
238875
238876
238877
238878
238879
238880
238881
238882
238883
238884
238885
238886
238887
238888
238889
238890
238891
238892
238893
238894
238895
238896
238897
238898
238899
238900
238901
238902
238903
238904
238905
238906
238907
238908
238909
238910
238911
238912
238913
238914
238915
238916
238917
238918
238919
238920
238921
238922
238923
238924
238925
238926
238927
238928
238929
238930
238931
238932
238933
238934
238935
238936
238937
238938
238939
238940
238941
238942
238943
238944
238945
238946
238947
238948
238949
238950
238951
238952
238953
238954
238955
238956
238957
238958
238959
238960
238961
238962
238963
238964
238965
238966
238967
238968
238969
238970
238971
238972
238973
238974
238975
238976
238977
238978
238979
238980
238981
238982
238983
238984
238985
238986
238987
238988
238989
238990
238991
238992
238993
238994
238995
238996
238997
238998
238999
239000
239001
239002
239003
239004
239005
239006
239007
239008
239009
239010
239011
239012
239013
239014
239015
239016
239017
239018
239019
239020
239021
239022
239023
239024
239025
239026
239027
239028
239029
239030
239031
239032
239033
239034
239035
239036
239037
239038
239039
239040
239041
239042
239043
239044
239045
239046
239047
239048
239049
239050
239051
239052
239053
239054
239055
239056
239057
239058
239059
239060
239061
239062
239063
239064
239065
239066
239067
239068
239069
239070
239071
239072
239073
239074
239075
239076
239077
239078
239079
239080
239081
239082
239083
239084
239085
239086
239087
239088
239089
239090
239091
239092
239093
239094
239095
239096
239097
239098
239099
239100
239101
239102
239103
239104
239105
239106
239107
239108
239109
239110
239111
239112
239113
239114
239115
239116
239117
239118
239119
239120
239121
239122
239123
239124
239125
239126
239127
239128
239129
239130
239131
239132
239133
239134
239135
239136
239137
239138
239139
239140
239141
239142
239143
239144
239145
239146
239147
239148
239149
239150
239151
239152
239153
239154
239155
239156
239157
239158
239159
239160
239161
239162
239163
239164
239165
239166
239167
239168
239169
239170
239171
239172
239173
239174
239175
239176
239177
239178
239179
239180
239181
239182
239183
239184
239185
239186
239187
239188
239189
239190
239191
239192
239193
239194
239195
239196
239197
239198
239199
239200
239201
239202
239203
239204
239205
239206
239207
239208
239209
239210
239211
239212
239213
239214
239215
239216
239217
239218
239219
239220
239221
239222
239223
239224
239225
239226
239227
239228
239229
239230
239231
239232
239233
239234
239235
239236
239237
239238
239239
239240
239241
239242
239243
239244
239245
239246
239247
239248
239249
239250
239251
239252
239253
239254
239255
239256
239257
239258
239259
239260
239261
239262
239263
239264
239265
239266
239267
239268
239269
239270
239271
239272
239273
239274
239275
239276
239277
239278
239279
239280
239281
239282
239283
239284
239285
239286
239287
239288
239289
239290
239291
239292
239293
239294
239295
239296
239297
239298
239299
239300
239301
239302
239303
239304
239305
239306
239307
239308
239309
239310
239311
239312
239313
239314
239315
239316
239317
239318
239319
239320
239321
239322
239323
239324
239325
239326
239327
239328
239329
239330
239331
239332
239333
239334
239335
239336
239337
239338
239339
239340
239341
239342
239343
239344
239345
239346
239347
239348
239349
239350
239351
239352
239353
239354
239355
239356
239357
239358
239359
239360
239361
239362
239363
239364
239365
239366
239367
239368
239369
239370
239371
239372
239373
239374
239375
239376
239377
239378
239379
239380
239381
239382
239383
239384
239385
239386
239387
239388
239389
239390
239391
239392
239393
239394
239395
239396
239397
239398
239399
239400
239401
239402
239403
239404
239405
239406
239407
239408
239409
239410
239411
239412
239413
239414
239415
239416
239417
239418
239419
239420
239421
239422
239423
239424
239425
239426
239427
239428
239429
239430
239431
239432
239433
239434
239435
239436
239437
239438
239439
239440
239441
239442
239443
239444
239445
239446
239447
239448
239449
239450
239451
239452
239453
239454
239455
239456
239457
239458
239459
239460
239461
239462
239463
239464
239465
239466
239467
239468
239469
239470
239471
239472
239473
239474
239475
239476
239477
239478
239479
239480
239481
239482
239483
239484
239485
239486
239487
239488
239489
239490
239491
239492
239493
239494
239495
239496
239497
239498
239499
239500
239501
239502
239503
239504
239505
239506
239507
239508
239509
239510
239511
239512
239513
239514
239515
239516
239517
239518
239519
239520
239521
239522
239523
239524
239525
239526
239527
239528
239529
239530
239531
239532
239533
239534
239535
239536
239537
239538
239539
239540
239541
239542
239543
239544
239545
239546
239547
239548
239549
239550
239551
239552
239553
239554
239555
239556
239557
239558
239559
239560
239561
239562
239563
239564
239565
239566
239567
239568
239569
239570
239571
239572
239573
239574
239575
239576
239577
239578
239579
239580
239581
239582
239583
239584
239585
239586
239587
239588
239589
239590
239591
239592
239593
239594
239595
239596
239597
239598
239599
239600
239601
239602
239603
239604
239605
239606
239607
239608
239609
239610
239611
239612
239613
239614
239615
239616
239617
239618
239619
239620
239621
239622
239623
239624
239625
239626
239627
239628
239629
239630
239631
239632
239633
239634
239635
239636
239637
239638
239639
239640
239641
239642
239643
239644
239645
239646
239647
239648
239649
239650
239651
239652
239653
239654
239655
239656
239657
239658
239659
239660
239661
239662
239663
239664
239665
239666
239667
239668
239669
239670
239671
239672
239673
239674
239675
239676
239677
239678
239679
239680
239681
239682
239683
239684
239685
239686
239687
239688
239689
239690
239691
239692
239693
239694
239695
239696
239697
239698
239699
239700
239701
239702
239703
239704
239705
239706
239707
239708
239709
239710
239711
239712
239713
239714
239715
239716
239717
239718
239719
239720
239721
239722
239723
239724
239725
239726
239727
239728
239729
239730
239731
239732
239733
239734
239735
239736
239737
239738
239739
239740
239741
239742
239743
239744
239745
239746
239747
239748
239749
239750
239751
239752
239753
239754
239755
239756
239757
239758
239759
239760
239761
239762
239763
239764
239765
239766
239767
239768
239769
239770
239771
239772
239773
239774
239775
239776
239777
239778
239779
239780
239781
239782
239783
239784
239785
239786
239787
239788
239789
239790
239791
239792
239793
239794
239795
239796
239797
239798
239799
239800
239801
239802
239803
239804
239805
239806
239807
239808
239809
239810
239811
239812
239813
239814
239815
239816
239817
239818
239819
239820
239821
239822
239823
239824
239825
239826
239827
239828
239829
239830
239831
239832
239833
239834
239835
239836
239837
239838
239839
239840
239841
239842
239843
239844
239845
239846
239847
239848
239849
239850
239851
239852
239853
239854
239855
239856
239857
239858
239859
239860
239861
239862
239863
239864
239865
239866
239867
239868
239869
239870
239871
239872
239873
239874
239875
239876
239877
239878
239879
239880
239881
239882
239883
239884
239885
239886
239887
239888
239889
239890
239891
239892
239893
239894
239895
239896
239897
239898
239899
239900
239901
239902
239903
239904
239905
239906
239907
239908
239909
239910
239911
239912
239913
239914
239915
239916
239917
239918
239919
239920
239921
239922
239923
239924
239925
239926
239927
239928
239929
239930
239931
239932
239933
239934
239935
239936
239937
239938
239939
239940
239941
239942
239943
239944
239945
239946
239947
239948
239949
239950
239951
239952
239953
239954
239955
239956
239957
239958
239959
239960
239961
239962
239963
239964
239965
239966
239967
239968
239969
239970
239971
239972
239973
239974
239975
239976
239977
239978
239979
239980
239981
239982
239983
239984
239985
239986
239987
239988
239989
239990
239991
239992
239993
239994
239995
239996
239997
239998
239999
240000
240001
240002
240003
240004
240005
240006
240007
240008
240009
240010
240011
240012
240013
240014
240015
240016
240017
240018
240019
240020
240021
240022
240023
240024
240025
240026
240027
240028
240029
240030
240031
240032
240033
240034
240035
240036
240037
240038
240039
240040
240041
240042
240043
240044
240045
240046
240047
240048
240049
240050
240051
240052
240053
240054
240055
240056
240057
240058
240059
240060
240061
240062
240063
240064
240065
240066
240067
240068
240069
240070
240071
240072
240073
240074
240075
240076
240077
240078
240079
240080
240081
240082
240083
240084
240085
240086
240087
240088
240089
240090
240091
240092
240093
240094
240095
240096
240097
240098
240099
240100
240101
240102
240103
240104
240105
240106
240107
240108
240109
240110
240111
240112
240113
240114
240115
240116
240117
240118
240119
240120
240121
240122
240123
240124
240125
240126
240127
240128
240129
240130
240131
240132
240133
240134
240135
240136
240137
240138
240139
240140
240141
240142
240143
240144
240145
240146
240147
240148
240149
240150
240151
240152
240153
240154
240155
240156
240157
240158
240159
240160
240161
240162
240163
240164
240165
240166
240167
240168
240169
240170
240171
240172
240173
240174
240175
240176
240177
240178
240179
240180
240181
240182
240183
240184
240185
240186
240187
240188
240189
240190
240191
240192
240193
240194
240195
240196
240197
240198
240199
240200
240201
240202
240203
240204
240205
240206
240207
240208
240209
240210
240211
240212
240213
240214
240215
240216
240217
240218
240219
240220
240221
240222
240223
240224
240225
240226
240227
240228
240229
240230
240231
240232
240233
240234
240235
240236
240237
240238
240239
240240
240241
240242
240243
240244
240245
240246
240247
240248
240249
240250
240251
240252
240253
240254
240255
240256
240257
240258
240259
240260
240261
240262
240263
240264
240265
240266
240267
240268
240269
240270
240271
240272
240273
240274
240275
240276
240277
240278
240279
240280
240281
240282
240283
240284
240285
240286
240287
240288
240289
240290
240291
240292
240293
240294
240295
240296
240297
240298
240299
240300
240301
240302
240303
240304
240305
240306
240307
240308
240309
240310
240311
240312
240313
240314
240315
240316
240317
240318
240319
240320
240321
240322
240323
240324
240325
240326
240327
240328
240329
240330
240331
240332
240333
240334
240335
240336
240337
240338
240339
240340
240341
240342
240343
240344
240345
240346
240347
240348
240349
240350
240351
240352
240353
240354
240355
240356
240357
240358
240359
240360
240361
240362
240363
240364
240365
240366
240367
240368
240369
240370
240371
240372
240373
240374
240375
240376
240377
240378
240379
240380
240381
240382
240383
240384
240385
240386
240387
240388
240389
240390
240391
240392
240393
240394
240395
240396
240397
240398
240399
240400
240401
240402
240403
240404
240405
240406
240407
240408
240409
240410
240411
240412
240413
240414
240415
240416
240417
240418
240419
240420
240421
240422
240423
240424
240425
240426
240427
240428
240429
240430
240431
240432
240433
240434
240435
240436
240437
240438
240439
240440
240441
240442
240443
240444
240445
240446
240447
240448
240449
240450
240451
240452
240453
240454
240455
240456
240457
240458
240459
240460
240461
240462
240463
240464
240465
240466
240467
240468
240469
240470
240471
240472
240473
240474
240475
240476
240477
240478
240479
240480
240481
240482
240483
240484
240485
240486
240487
240488
240489
240490
240491
240492
240493
240494
240495
240496
240497
240498
240499
240500
240501
240502
240503
240504
240505
240506
240507
240508
240509
240510
240511
240512
240513
240514
240515
240516
240517
240518
240519
240520
240521
240522
240523
240524
240525
240526
240527
240528
240529
240530
240531
240532
240533
240534
240535
240536
240537
240538
240539
240540
240541
240542
240543
240544
240545
240546
240547
240548
240549
240550
240551
240552
240553
240554
240555
240556
240557
240558
240559
240560
240561
240562
240563
240564
240565
240566
240567
240568
240569
240570
240571
240572
240573
240574
240575
240576
240577
240578
240579
240580
240581
240582
240583
240584
240585
240586
240587
240588
240589
240590
240591
240592
240593
240594
240595
240596
240597
240598
240599
240600
240601
240602
240603
240604
240605
240606
240607
240608
240609
240610
240611
240612
240613
240614
240615
240616
240617
240618
240619
240620
240621
240622
240623
240624
240625
240626
240627
240628
240629
240630
240631
240632
240633
240634
240635
240636
240637
240638
240639
240640
240641
240642
240643
240644
240645
240646
240647
240648
240649
240650
240651
240652
240653
240654
240655
240656
240657
240658
240659
240660
240661
240662
240663
240664
240665
240666
240667
240668
240669
240670
240671
240672
240673
240674
240675
240676
240677
240678
240679
240680
240681
240682
240683
240684
240685
240686
240687
240688
240689
240690
240691
240692
240693
240694
240695
240696
240697
240698
240699
240700
240701
240702
240703
240704
240705
240706
240707
240708
240709
240710
240711
240712
240713
240714
240715
240716
240717
240718
240719
240720
240721
240722
240723
240724
240725
240726
240727
240728
240729
240730
240731
240732
240733
240734
240735
240736
240737
240738
240739
240740
240741
240742
240743
240744
240745
240746
240747
240748
240749
240750
240751
240752
240753
240754
240755
240756
240757
240758
240759
240760
240761
240762
240763
240764
240765
240766
240767
240768
240769
240770
240771
240772
240773
240774
240775
240776
240777
240778
240779
240780
240781
240782
240783
240784
240785
240786
240787
240788
240789
240790
240791
240792
240793
240794
240795
240796
240797
240798
240799
240800
240801
240802
240803
240804
240805
240806
240807
240808
240809
240810
240811
240812
240813
240814
240815
240816
240817
240818
240819
240820
240821
240822
240823
240824
240825
240826
240827
240828
240829
240830
240831
240832
240833
240834
240835
240836
240837
240838
240839
240840
240841
240842
240843
240844
240845
240846
240847
240848
240849
240850
240851
240852
240853
240854
240855
240856
240857
240858
240859
240860
240861
240862
240863
240864
240865
240866
240867
240868
240869
240870
240871
240872
240873
240874
240875
240876
240877
240878
240879
240880
240881
240882
240883
240884
240885
240886
240887
240888
240889
240890
240891
240892
240893
240894
240895
240896
240897
240898
240899
240900
240901
240902
240903
240904
240905
240906
240907
240908
240909
240910
240911
240912
240913
240914
240915
240916
240917
240918
240919
240920
240921
240922
240923
240924
240925
240926
240927
240928
240929
240930
240931
240932
240933
240934
240935
240936
240937
240938
240939
240940
240941
240942
240943
240944
240945
240946
240947
240948
240949
240950
240951
240952
240953
240954
240955
240956
240957
240958
240959
240960
240961
240962
240963
240964
240965
240966
240967
240968
240969
240970
240971
240972
240973
240974
240975
240976
240977
240978
240979
240980
240981
240982
240983
240984
240985
240986
240987
240988
240989
240990
240991
240992
240993
240994
240995
240996
240997
240998
240999
241000
241001
241002
241003
241004
241005
241006
241007
241008
241009
241010
241011
241012
241013
241014
241015
241016
241017
241018
241019
241020
241021
241022
241023
241024
241025
241026
241027
241028
241029
241030
241031
241032
241033
241034
241035
241036
241037
241038
241039
241040
241041
241042
241043
241044
241045
241046
241047
241048
241049
241050
241051
241052
241053
241054
241055
241056
241057
241058
241059
241060
241061
241062
241063
241064
241065
241066
241067
241068
241069
241070
241071
241072
241073
241074
241075
241076
241077
241078
241079
241080
241081
241082
241083
241084
241085
241086
241087
241088
241089
241090
241091
241092
241093
241094
241095
241096
241097
241098
241099
241100
241101
241102
241103
241104
241105
241106
241107
241108
241109
241110
241111
241112
241113
241114
241115
241116
241117
241118
241119
241120
241121
241122
241123
241124
241125
241126
241127
241128
241129
241130
241131
241132
241133
241134
241135
241136
241137
241138
241139
241140
241141
241142
241143
241144
241145
241146
241147
241148
241149
241150
241151
241152
241153
241154
241155
241156
241157
241158
241159
241160
241161
241162
241163
241164
241165
241166
241167
241168
241169
241170
241171
241172
241173
241174
241175
241176
241177
241178
241179
241180
241181
241182
241183
241184
241185
241186
241187
241188
241189
241190
241191
241192
241193
241194
241195
241196
241197
241198
241199
241200
241201
241202
241203
241204
241205
241206
241207
241208
241209
241210
241211
241212
241213
241214
241215
241216
241217
241218
241219
241220
241221
241222
241223
241224
241225
241226
241227
241228
241229
241230
241231
241232
241233
241234
241235
241236
241237
241238
241239
241240
241241
241242
241243
241244
241245
241246
241247
241248
241249
241250
241251
241252
241253
241254
241255
241256
241257
241258
241259
241260
241261
241262
241263
241264
241265
241266
241267
241268
241269
241270
241271
241272
241273
241274
241275
241276
241277
241278
241279
241280
241281
241282
241283
241284
241285
241286
241287
241288
241289
241290
241291
241292
241293
241294
241295
241296
241297
241298
241299
241300
241301
241302
241303
241304
241305
241306
241307
241308
241309
241310
241311
241312
241313
241314
241315
241316
241317
241318
241319
241320
241321
241322
241323
241324
241325
241326
241327
241328
241329
241330
241331
241332
241333
241334
241335
241336
241337
241338
241339
241340
241341
241342
241343
241344
241345
241346
241347
241348
241349
241350
241351
241352
241353
241354
241355
241356
241357
241358
241359
241360
241361
241362
241363
241364
241365
241366
241367
241368
241369
241370
241371
241372
241373
241374
241375
241376
241377
241378
241379
241380
241381
241382
241383
241384
241385
241386
241387
241388
241389
241390
241391
241392
241393
241394
241395
241396
241397
241398
241399
241400
241401
241402
241403
241404
241405
241406
241407
241408
241409
241410
241411
241412
241413
241414
241415
241416
241417
241418
241419
241420
241421
241422
241423
241424
241425
241426
241427
241428
241429
241430
241431
241432
241433
241434
241435
241436
241437
241438
241439
241440
241441
241442
241443
241444
241445
241446
241447
241448
241449
241450
241451
241452
241453
241454
241455
241456
241457
241458
241459
241460
241461
241462
241463
241464
241465
241466
241467
241468
241469
241470
241471
241472
241473
241474
241475
241476
241477
241478
241479
241480
241481
241482
241483
241484
241485
241486
241487
241488
241489
241490
241491
241492
241493
241494
241495
241496
241497
241498
241499
241500
241501
241502
241503
241504
241505
241506
241507
241508
241509
241510
241511
241512
241513
241514
241515
241516
241517
241518
241519
241520
241521
241522
241523
241524
241525
241526
241527
241528
241529
241530
241531
241532
241533
241534
241535
241536
241537
241538
241539
241540
241541
241542
241543
241544
241545
241546
241547
241548
241549
241550
241551
241552
241553
241554
241555
241556
241557
241558
241559
241560
241561
241562
241563
241564
241565
241566
241567
241568
241569
241570
241571
241572
241573
241574
241575
241576
241577
241578
241579
241580
241581
241582
241583
241584
241585
241586
241587
241588
241589
241590
241591
241592
241593
241594
241595
241596
241597
241598
241599
241600
241601
241602
241603
241604
241605
241606
241607
241608
241609
241610
241611
241612
241613
241614
241615
241616
241617
241618
241619
241620
241621
241622
241623
241624
241625
241626
241627
241628
241629
241630
241631
241632
241633
241634
241635
241636
241637
241638
241639
241640
241641
241642
241643
241644
241645
241646
241647
241648
241649
241650
241651
241652
241653
241654
241655
241656
241657
241658
241659
241660
241661
241662
241663
241664
241665
241666
241667
241668
241669
241670
241671
241672
241673
241674
241675
241676
241677
241678
241679
241680
241681
241682
241683
241684
241685
241686
241687
241688
241689
241690
241691
241692
241693
241694
241695
241696
241697
241698
241699
241700
241701
241702
241703
241704
241705
241706
241707
241708
241709
241710
241711
241712
241713
241714
241715
241716
241717
241718
241719
241720
241721
241722
241723
241724
241725
241726
241727
241728
241729
241730
241731
241732
241733
241734
241735
241736
241737
241738
241739
241740
241741
241742
241743
241744
241745
241746
241747
241748
241749
241750
241751
241752
241753
241754
241755
241756
241757
241758
241759
241760
241761
241762
241763
241764
241765
241766
241767
241768
241769
241770
241771
241772
241773
241774
241775
241776
241777
241778
241779
241780
241781
241782
241783
241784
241785
241786
241787
241788
241789
241790
241791
241792
241793
241794
241795
241796
241797
241798
241799
241800
241801
241802
241803
241804
241805
241806
241807
241808
241809
241810
241811
241812
241813
241814
241815
241816
241817
241818
241819
241820
241821
241822
241823
241824
241825
241826
241827
241828
241829
241830
241831
241832
241833
241834
241835
241836
241837
241838
241839
241840
241841
241842
241843
241844
241845
241846
241847
241848
241849
241850
241851
241852
241853
241854
241855
241856
241857
241858
241859
241860
241861
241862
241863
241864
241865
241866
241867
241868
241869
241870
241871
241872
241873
241874
241875
241876
241877
241878
241879
241880
241881
241882
241883
241884
241885
241886
241887
241888
241889
241890
241891
241892
241893
241894
241895
241896
241897
241898
241899
241900
241901
241902
241903
241904
241905
241906
241907
241908
241909
241910
241911
241912
241913
241914
241915
241916
241917
241918
241919
241920
241921
241922
241923
241924
241925
241926
241927
241928
241929
241930
241931
241932
241933
241934
241935
241936
241937
241938
241939
241940
241941
241942
241943
241944
241945
241946
241947
241948
241949
241950
241951
241952
241953
241954
241955
241956
241957
241958
241959
241960
241961
241962
241963
241964
241965
241966
241967
241968
241969
241970
241971
241972
241973
241974
241975
241976
241977
241978
241979
241980
241981
241982
241983
241984
241985
241986
241987
241988
241989
241990
241991
241992
241993
241994
241995
241996
241997
241998
241999
242000
242001
242002
242003
242004
242005
242006
242007
242008
242009
242010
242011
242012
242013
242014
242015
242016
242017
242018
242019
242020
242021
242022
242023
242024
242025
242026
242027
242028
242029
242030
242031
242032
242033
242034
242035
242036
242037
242038
242039
242040
242041
242042
242043
242044
242045
242046
242047
242048
242049
242050
242051
242052
242053
242054
242055
242056
242057
242058
242059
242060
242061
242062
242063
242064
242065
242066
242067
242068
242069
242070
242071
242072
242073
242074
242075
242076
242077
242078
242079
242080
242081
242082
242083
242084
242085
242086
242087
242088
242089
242090
242091
242092
242093
242094
242095
242096
242097
242098
242099
242100
242101
242102
242103
242104
242105
242106
242107
242108
242109
242110
242111
242112
242113
242114
242115
242116
242117
242118
242119
242120
242121
242122
242123
242124
242125
242126
242127
242128
242129
242130
242131
242132
242133
242134
242135
242136
242137
242138
242139
242140
242141
242142
242143
242144
242145
242146
242147
242148
242149
242150
242151
242152
242153
242154
242155
242156
242157
242158
242159
242160
242161
242162
242163
242164
242165
242166
242167
242168
242169
242170
242171
242172
242173
242174
242175
242176
242177
242178
242179
242180
242181
242182
242183
242184
242185
242186
242187
242188
242189
242190
242191
242192
242193
242194
242195
242196
242197
242198
242199
242200
242201
242202
242203
242204
242205
242206
242207
242208
242209
242210
242211
242212
242213
242214
242215
242216
242217
242218
242219
242220
242221
242222
242223
242224
242225
242226
242227
242228
242229
242230
242231
242232
242233
242234
242235
242236
242237
242238
242239
242240
242241
242242
242243
242244
242245
242246
242247
242248
242249
242250
242251
242252
242253
242254
242255
242256
242257
242258
242259
242260
242261
242262
242263
242264
242265
242266
242267
242268
242269
242270
242271
242272
242273
242274
242275
242276
242277
242278
242279
242280
242281
242282
242283
242284
242285
242286
242287
242288
242289
242290
242291
242292
242293
242294
242295
242296
242297
242298
242299
242300
242301
242302
242303
242304
242305
242306
242307
242308
242309
242310
242311
242312
242313
242314
242315
242316
242317
242318
242319
242320
242321
242322
242323
242324
242325
242326
242327
242328
242329
242330
242331
242332
242333
242334
242335
242336
242337
242338
242339
242340
242341
242342
242343
242344
242345
242346
242347
242348
242349
242350
242351
242352
242353
242354
242355
242356
242357
242358
242359
242360
242361
242362
242363
242364
242365
242366
242367
242368
242369
242370
242371
242372
242373
242374
242375
242376
242377
242378
242379
242380
242381
242382
242383
242384
242385
242386
242387
242388
242389
242390
242391
242392
242393
242394
242395
242396
242397
242398
242399
242400
242401
242402
242403
242404
242405
242406
242407
242408
242409
242410
242411
242412
242413
242414
242415
242416
242417
242418
242419
242420
242421
242422
242423
242424
242425
242426
242427
242428
242429
242430
242431
242432
242433
242434
242435
242436
242437
242438
242439
242440
242441
242442
242443
242444
242445
242446
242447
242448
242449
242450
242451
242452
242453
242454
242455
242456
242457
242458
242459
242460
242461
242462
242463
242464
242465
242466
242467
242468
242469
242470
242471
242472
242473
242474
242475
242476
242477
242478
242479
242480
242481
242482
242483
242484
242485
242486
242487
242488
242489
242490
242491
242492
242493
242494
242495
242496
242497
242498
242499
242500
242501
242502
242503
242504
242505
242506
242507
242508
242509
242510
242511
242512
242513
242514
242515
242516
242517
242518
242519
242520
242521
242522
242523
242524
242525
242526
242527
242528
242529
242530
242531
242532
242533
242534
242535
242536
242537
242538
242539
242540
242541
242542
242543
242544
242545
242546
242547
242548
242549
242550
242551
242552
242553
242554
242555
242556
242557
242558
242559
242560
242561
242562
242563
242564
242565
242566
242567
242568
242569
242570
242571
242572
242573
242574
242575
242576
242577
242578
242579
242580
242581
242582
242583
242584
242585
242586
242587
242588
242589
242590
242591
242592
242593
242594
242595
242596
242597
242598
242599
242600
242601
242602
242603
242604
242605
242606
242607
242608
242609
242610
242611
242612
242613
242614
242615
242616
242617
242618
242619
242620
242621
242622
242623
242624
242625
242626
242627
242628
242629
242630
242631
242632
242633
242634
242635
242636
242637
242638
242639
242640
242641
242642
242643
242644
242645
242646
242647
242648
242649
242650
242651
242652
242653
242654
242655
242656
242657
242658
242659
242660
242661
242662
242663
242664
242665
242666
242667
242668
242669
242670
242671
242672
242673
242674
242675
242676
242677
242678
242679
242680
242681
242682
242683
242684
242685
242686
242687
242688
242689
242690
242691
242692
242693
242694
242695
242696
242697
242698
242699
242700
242701
242702
242703
242704
242705
242706
242707
242708
242709
242710
242711
242712
242713
242714
242715
242716
242717
242718
242719
242720
242721
242722
242723
242724
242725
242726
242727
242728
242729
242730
242731
242732
242733
242734
242735
242736
242737
242738
242739
242740
242741
242742
242743
242744
242745
242746
242747
242748
242749
242750
242751
242752
242753
242754
242755
242756
242757
242758
242759
242760
242761
242762
242763
242764
242765
242766
242767
242768
242769
242770
242771
242772
242773
242774
242775
242776
242777
242778
242779
242780
242781
242782
242783
242784
242785
242786
242787
242788
242789
242790
242791
242792
242793
242794
242795
242796
242797
242798
242799
242800
242801
242802
242803
242804
242805
242806
242807
242808
242809
242810
242811
242812
242813
242814
242815
242816
242817
242818
242819
242820
242821
242822
242823
242824
242825
242826
242827
242828
242829
242830
242831
242832
242833
242834
242835
242836
242837
242838
242839
242840
242841
242842
242843
242844
242845
242846
242847
242848
242849
242850
242851
242852
242853
242854
242855
242856
242857
242858
242859
242860
242861
242862
242863
242864
242865
242866
242867
242868
242869
242870
242871
242872
242873
242874
242875
242876
242877
242878
242879
242880
242881
242882
242883
242884
242885
242886
242887
242888
242889
242890
242891
242892
242893
242894
242895
242896
242897
242898
242899
242900
242901
242902
242903
242904
242905
242906
242907
242908
242909
242910
242911
242912
242913
242914
242915
242916
242917
242918
242919
242920
242921
242922
242923
242924
242925
242926
242927
242928
242929
242930
242931
242932
242933
242934
242935
242936
242937
242938
242939
242940
242941
242942
242943
242944
242945
242946
242947
242948
242949
242950
242951
242952
242953
242954
242955
242956
242957
242958
242959
242960
242961
242962
242963
242964
242965
242966
242967
242968
242969
242970
242971
242972
242973
242974
242975
242976
242977
242978
242979
242980
242981
242982
242983
242984
242985
242986
242987
242988
242989
242990
242991
242992
242993
242994
242995
242996
242997
242998
242999
243000
243001
243002
243003
243004
243005
243006
243007
243008
243009
243010
243011
243012
243013
243014
243015
243016
243017
243018
243019
243020
243021
243022
243023
243024
243025
243026
243027
243028
243029
243030
243031
243032
243033
243034
243035
243036
243037
243038
243039
243040
243041
243042
243043
243044
243045
243046
243047
243048
243049
243050
243051
243052
243053
243054
243055
243056
243057
243058
243059
243060
243061
243062
243063
243064
243065
243066
243067
243068
243069
243070
243071
243072
243073
243074
243075
243076
243077
243078
243079
243080
243081
243082
243083
243084
243085
243086
243087
243088
243089
243090
243091
243092
243093
243094
243095
243096
243097
243098
243099
243100
243101
243102
243103
243104
243105
243106
243107
243108
243109
243110
243111
243112
243113
243114
243115
243116
243117
243118
243119
243120
243121
243122
243123
243124
243125
243126
243127
243128
243129
243130
243131
243132
243133
243134
243135
243136
243137
243138
243139
243140
243141
243142
243143
243144
243145
243146
243147
243148
243149
243150
243151
243152
243153
243154
243155
243156
243157
243158
243159
243160
243161
243162
243163
243164
243165
243166
243167
243168
243169
243170
243171
243172
243173
243174
243175
243176
243177
243178
243179
243180
243181
243182
243183
243184
243185
243186
243187
243188
243189
243190
243191
243192
243193
243194
243195
243196
243197
243198
243199
243200
243201
243202
243203
243204
243205
243206
243207
243208
243209
243210
243211
243212
243213
243214
243215
243216
243217
243218
243219
243220
243221
243222
243223
243224
243225
243226
243227
243228
243229
243230
243231
243232
243233
243234
243235
243236
243237
243238
243239
243240
243241
243242
243243
243244
243245
243246
243247
243248
243249
243250
243251
243252
243253
243254
243255
243256
243257
243258
243259
243260
243261
243262
243263
243264
243265
243266
243267
243268
243269
243270
243271
243272
243273
243274
243275
243276
243277
243278
243279
243280
243281
243282
243283
243284
243285
243286
243287
243288
243289
243290
243291
243292
243293
243294
243295
243296
243297
243298
243299
243300
243301
243302
243303
243304
243305
243306
243307
243308
243309
243310
243311
243312
243313
243314
243315
243316
243317
243318
243319
243320
243321
243322
243323
243324
243325
243326
243327
243328
243329
243330
243331
243332
243333
243334
243335
243336
243337
243338
243339
243340
243341
243342
243343
243344
243345
243346
243347
243348
243349
243350
243351
243352
243353
243354
243355
243356
243357
243358
243359
243360
243361
243362
243363
243364
243365
243366
243367
243368
243369
243370
243371
243372
243373
243374
243375
243376
243377
243378
243379
243380
243381
243382
243383
243384
243385
243386
243387
243388
243389
243390
243391
243392
243393
243394
243395
243396
243397
243398
243399
243400
243401
243402
243403
243404
243405
243406
243407
243408
243409
243410
243411
243412
243413
243414
243415
243416
243417
243418
243419
243420
243421
243422
243423
243424
243425
243426
243427
243428
243429
243430
243431
243432
243433
243434
243435
243436
243437
243438
243439
243440
243441
243442
243443
243444
243445
243446
243447
243448
243449
243450
243451
243452
243453
243454
243455
243456
243457
243458
243459
243460
243461
243462
243463
243464
243465
243466
243467
243468
243469
243470
243471
243472
243473
243474
243475
243476
243477
243478
243479
243480
243481
243482
243483
243484
243485
243486
243487
243488
243489
243490
243491
243492
243493
243494
243495
243496
243497
243498
243499
243500
243501
243502
243503
243504
243505
243506
243507
243508
243509
243510
243511
243512
243513
243514
243515
243516
243517
243518
243519
243520
243521
243522
243523
243524
243525
243526
243527
243528
243529
243530
243531
243532
243533
243534
243535
243536
243537
243538
243539
243540
243541
243542
243543
243544
243545
243546
243547
243548
243549
243550
243551
243552
243553
243554
243555
243556
243557
243558
243559
243560
243561
243562
243563
243564
243565
243566
243567
243568
243569
243570
243571
243572
243573
243574
243575
243576
243577
243578
243579
243580
243581
243582
243583
243584
243585
243586
243587
243588
243589
243590
243591
243592
243593
243594
243595
243596
243597
243598
243599
243600
243601
243602
243603
243604
243605
243606
243607
243608
243609
243610
243611
243612
243613
243614
243615
243616
243617
243618
243619
243620
243621
243622
243623
243624
243625
243626
243627
243628
243629
243630
243631
243632
243633
243634
243635
243636
243637
243638
243639
243640
243641
243642
243643
243644
243645
243646
243647
243648
243649
243650
243651
243652
243653
243654
243655
243656
243657
243658
243659
243660
243661
243662
243663
243664
243665
243666
243667
243668
243669
243670
243671
243672
243673
243674
243675
243676
243677
243678
243679
243680
243681
243682
243683
243684
243685
243686
243687
243688
243689
243690
243691
243692
243693
243694
243695
243696
243697
243698
243699
243700
243701
243702
243703
243704
243705
243706
243707
243708
243709
243710
243711
243712
243713
243714
243715
243716
243717
243718
243719
243720
243721
243722
243723
243724
243725
243726
243727
243728
243729
243730
243731
243732
243733
243734
243735
243736
243737
243738
243739
243740
243741
243742
243743
243744
243745
243746
243747
243748
243749
243750
243751
243752
243753
243754
243755
243756
243757
243758
243759
243760
243761
243762
243763
243764
243765
243766
243767
243768
243769
243770
243771
243772
243773
243774
243775
243776
243777
243778
243779
243780
243781
243782
243783
243784
243785
243786
243787
243788
243789
243790
243791
243792
243793
243794
243795
243796
243797
243798
243799
243800
243801
243802
243803
243804
243805
243806
243807
243808
243809
243810
243811
243812
243813
243814
243815
243816
243817
243818
243819
243820
243821
243822
243823
243824
243825
243826
243827
243828
243829
243830
243831
243832
243833
243834
243835
243836
243837
243838
243839
243840
243841
243842
243843
243844
243845
243846
243847
243848
243849
243850
243851
243852
243853
243854
243855
243856
243857
243858
243859
243860
243861
243862
243863
243864
243865
243866
243867
243868
243869
243870
243871
243872
243873
243874
243875
243876
243877
243878
243879
243880
243881
243882
243883
243884
243885
243886
243887
243888
243889
243890
243891
243892
243893
243894
243895
243896
243897
243898
243899
243900
243901
243902
243903
243904
243905
243906
243907
243908
243909
243910
243911
243912
243913
243914
243915
243916
243917
243918
243919
243920
243921
243922
243923
243924
243925
243926
243927
243928
243929
243930
243931
243932
243933
243934
243935
243936
243937
243938
243939
243940
243941
243942
243943
243944
243945
243946
243947
243948
243949
243950
243951
243952
243953
243954
243955
243956
243957
243958
243959
243960
243961
243962
243963
243964
243965
243966
243967
243968
243969
243970
243971
243972
243973
243974
243975
243976
243977
243978
243979
243980
243981
243982
243983
243984
243985
243986
243987
243988
243989
243990
243991
243992
243993
243994
243995
243996
243997
243998
243999
244000
244001
244002
244003
244004
244005
244006
244007
244008
244009
244010
244011
244012
244013
244014
244015
244016
244017
244018
244019
244020
244021
244022
244023
244024
244025
244026
244027
244028
244029
244030
244031
244032
244033
244034
244035
244036
244037
244038
244039
244040
244041
244042
244043
244044
244045
244046
244047
244048
244049
244050
244051
244052
244053
244054
244055
244056
244057
244058
244059
244060
244061
244062
244063
244064
244065
244066
244067
244068
244069
244070
244071
244072
244073
244074
244075
244076
244077
244078
244079
244080
244081
244082
244083
244084
244085
244086
244087
244088
244089
244090
244091
244092
244093
244094
244095
244096
244097
244098
244099
244100
244101
244102
244103
244104
244105
244106
244107
244108
244109
244110
244111
244112
244113
244114
244115
244116
244117
244118
244119
244120
244121
244122
244123
244124
244125
244126
244127
244128
244129
244130
244131
244132
244133
244134
244135
244136
244137
244138
244139
244140
244141
244142
244143
244144
244145
244146
244147
244148
244149
244150
244151
244152
244153
244154
244155
244156
244157
244158
244159
244160
244161
244162
244163
244164
244165
244166
244167
244168
244169
244170
244171
244172
244173
244174
244175
244176
244177
244178
244179
244180
244181
244182
244183
244184
244185
244186
244187
244188
244189
244190
244191
244192
244193
244194
244195
244196
244197
244198
244199
244200
244201
244202
244203
244204
244205
244206
244207
244208
244209
244210
244211
244212
244213
244214
244215
244216
244217
244218
244219
244220
244221
244222
244223
244224
244225
244226
244227
244228
244229
244230
244231
244232
244233
244234
244235
244236
244237
244238
244239
244240
244241
244242
244243
244244
244245
244246
244247
244248
244249
244250
244251
244252
244253
244254
244255
244256
244257
244258
244259
244260
244261
244262
244263
244264
244265
244266
244267
244268
244269
244270
244271
244272
244273
244274
244275
244276
244277
244278
244279
244280
244281
244282
244283
244284
244285
244286
244287
244288
244289
244290
244291
244292
244293
244294
244295
244296
244297
244298
244299
244300
244301
244302
244303
244304
244305
244306
244307
244308
244309
244310
244311
244312
244313
244314
244315
244316
244317
244318
244319
244320
244321
244322
244323
244324
244325
244326
244327
244328
244329
244330
244331
244332
244333
244334
244335
244336
244337
244338
244339
244340
244341
244342
244343
244344
244345
244346
244347
244348
244349
244350
244351
244352
244353
244354
244355
244356
244357
244358
244359
244360
244361
244362
244363
244364
244365
244366
244367
244368
244369
244370
244371
244372
244373
244374
244375
244376
244377
244378
244379
244380
244381
244382
244383
244384
244385
244386
244387
244388
244389
244390
244391
244392
244393
244394
244395
244396
244397
244398
244399
244400
244401
244402
244403
244404
244405
244406
244407
244408
244409
244410
244411
244412
244413
244414
244415
244416
244417
244418
244419
244420
244421
244422
244423
244424
244425
244426
244427
244428
244429
244430
244431
244432
244433
244434
244435
244436
244437
244438
244439
244440
244441
244442
244443
244444
244445
244446
244447
244448
244449
244450
244451
244452
244453
244454
244455
244456
244457
244458
244459
244460
244461
244462
244463
244464
244465
244466
244467
244468
244469
244470
244471
244472
244473
244474
244475
244476
244477
244478
244479
244480
244481
244482
244483
244484
244485
244486
244487
244488
244489
244490
244491
244492
244493
244494
244495
244496
244497
244498
244499
244500
244501
244502
244503
244504
244505
244506
244507
244508
244509
244510
244511
244512
244513
244514
244515
244516
244517
244518
244519
244520
244521
244522
244523
244524
244525
244526
244527
244528
244529
244530
244531
244532
244533
244534
244535
244536
244537
244538
244539
244540
244541
244542
244543
244544
244545
244546
244547
244548
244549
244550
244551
244552
244553
244554
244555
244556
244557
244558
244559
244560
244561
244562
244563
244564
244565
244566
244567
244568
244569
244570
244571
244572
244573
244574
244575
244576
244577
244578
244579
244580
244581
244582
244583
244584
244585
244586
244587
244588
244589
244590
244591
244592
244593
244594
244595
244596
244597
244598
244599
244600
244601
244602
244603
244604
244605
244606
244607
244608
244609
244610
244611
244612
244613
244614
244615
244616
244617
244618
244619
244620
244621
244622
244623
244624
244625
244626
244627
244628
244629
244630
244631
244632
244633
244634
244635
244636
244637
244638
244639
244640
244641
244642
244643
244644
244645
244646
244647
244648
244649
244650
244651
244652
244653
244654
244655
244656
244657
244658
244659
244660
244661
244662
244663
244664
244665
244666
244667
244668
244669
244670
244671
244672
244673
244674
244675
244676
244677
244678
244679
244680
244681
244682
244683
244684
244685
244686
244687
244688
244689
244690
244691
244692
244693
244694
244695
244696
244697
244698
244699
244700
244701
244702
244703
244704
244705
244706
244707
244708
244709
244710
244711
244712
244713
244714
244715
244716
244717
244718
244719
244720
244721
244722
244723
244724
244725
244726
244727
244728
244729
244730
244731
244732
244733
244734
244735
244736
244737
244738
244739
244740
244741
244742
244743
244744
244745
244746
244747
244748
244749
244750
244751
244752
244753
244754
244755
244756
244757
244758
244759
244760
244761
244762
244763
244764
244765
244766
244767
244768
244769
244770
244771
244772
244773
244774
244775
244776
244777
244778
244779
244780
244781
244782
244783
244784
244785
244786
244787
244788
244789
244790
244791
244792
244793
244794
244795
244796
244797
244798
244799
244800
244801
244802
244803
244804
244805
244806
244807
244808
244809
244810
244811
244812
244813
244814
244815
244816
244817
244818
244819
244820
244821
244822
244823
244824
244825
244826
244827
244828
244829
244830
244831
244832
244833
244834
244835
244836
244837
244838
244839
244840
244841
244842
244843
244844
244845
244846
244847
244848
244849
244850
244851
244852
244853
244854
244855
244856
244857
244858
244859
244860
244861
244862
244863
244864
244865
244866
244867
244868
244869
244870
244871
244872
244873
244874
244875
244876
244877
244878
244879
244880
244881
244882
244883
244884
244885
244886
244887
244888
244889
244890
244891
244892
244893
244894
244895
244896
244897
244898
244899
244900
244901
244902
244903
244904
244905
244906
244907
244908
244909
244910
244911
244912
244913
244914
244915
244916
244917
244918
244919
244920
244921
244922
244923
244924
244925
244926
244927
244928
244929
244930
244931
244932
244933
244934
244935
244936
244937
244938
244939
244940
244941
244942
244943
244944
244945
244946
244947
244948
244949
244950
244951
244952
244953
244954
244955
244956
244957
244958
244959
244960
244961
244962
244963
244964
244965
244966
244967
244968
244969
244970
244971
244972
244973
244974
244975
244976
244977
244978
244979
244980
244981
244982
244983
244984
244985
244986
244987
244988
244989
244990
244991
244992
244993
244994
244995
244996
244997
244998
244999
245000
245001
245002
245003
245004
245005
245006
245007
245008
245009
245010
245011
245012
245013
245014
245015
245016
245017
245018
245019
245020
245021
245022
245023
245024
245025
245026
245027
245028
245029
245030
245031
245032
245033
245034
245035
245036
245037
245038
245039
245040
245041
245042
245043
245044
245045
245046
245047
245048
245049
245050
245051
245052
245053
245054
245055
245056
245057
245058
245059
245060
245061
245062
245063
245064
245065
245066
245067
245068
245069
245070
245071
245072
245073
245074
245075
245076
245077
245078
245079
245080
245081
245082
245083
245084
245085
245086
245087
245088
245089
245090
245091
245092
245093
245094
245095
245096
245097
245098
245099
245100
245101
245102
245103
245104
245105
245106
245107
245108
245109
245110
245111
245112
245113
245114
245115
245116
245117
245118
245119
245120
245121
245122
245123
245124
245125
245126
245127
245128
245129
245130
245131
245132
245133
245134
245135
245136
245137
245138
245139
245140
245141
245142
245143
245144
245145
245146
245147
245148
245149
245150
245151
245152
245153
245154
245155
245156
245157
245158
245159
245160
245161
245162
245163
245164
245165
245166
245167
245168
245169
245170
245171
245172
245173
245174
245175
245176
245177
245178
245179
245180
245181
245182
245183
245184
245185
245186
245187
245188
245189
245190
245191
245192
245193
245194
245195
245196
245197
245198
245199
245200
245201
245202
245203
245204
245205
245206
245207
245208
245209
245210
245211
245212
245213
245214
245215
245216
245217
245218
245219
245220
245221
245222
245223
245224
245225
245226
245227
245228
245229
245230
245231
245232
245233
245234
245235
245236
245237
245238
245239
245240
245241
245242
245243
245244
245245
245246
245247
245248
245249
245250
245251
245252
245253
245254
245255
245256
245257
245258
245259
245260
245261
245262
245263
245264
245265
245266
245267
245268
245269
245270
245271
245272
245273
245274
245275
245276
245277
245278
245279
245280
245281
245282
245283
245284
245285
245286
245287
245288
245289
245290
245291
245292
245293
245294
245295
245296
245297
245298
245299
245300
245301
245302
245303
245304
245305
245306
245307
245308
245309
245310
245311
245312
245313
245314
245315
245316
245317
245318
245319
245320
245321
245322
245323
245324
245325
245326
245327
245328
245329
245330
245331
245332
245333
245334
245335
245336
245337
245338
245339
245340
245341
245342
245343
245344
245345
245346
245347
245348
245349
245350
245351
245352
245353
245354
245355
245356
245357
245358
245359
245360
245361
245362
245363
245364
245365
245366
245367
245368
245369
245370
245371
245372
245373
245374
245375
245376
245377
245378
245379
245380
245381
245382
245383
245384
245385
245386
245387
245388
245389
245390
245391
245392
245393
245394
245395
245396
245397
245398
245399
245400
245401
245402
245403
245404
245405
245406
245407
245408
245409
245410
245411
245412
245413
245414
245415
245416
245417
245418
245419
245420
245421
245422
245423
245424
245425
245426
245427
245428
245429
245430
245431
245432
245433
245434
245435
245436
245437
245438
245439
245440
245441
245442
245443
245444
245445
245446
245447
245448
245449
245450
245451
245452
245453
245454
245455
245456
245457
245458
245459
245460
245461
245462
245463
245464
245465
245466
245467
245468
245469
245470
245471
245472
245473
245474
245475
245476
245477
245478
245479
245480
245481
245482
245483
245484
245485
245486
245487
245488
245489
245490
245491
245492
245493
245494
245495
245496
245497
245498
245499
245500
245501
245502
245503
245504
245505
245506
245507
245508
245509
245510
245511
245512
245513
245514
245515
245516
245517
245518
245519
245520
245521
245522
245523
245524
245525
245526
245527
245528
245529
245530
245531
245532
245533
245534
245535
245536
245537
245538
245539
245540
245541
245542
245543
245544
245545
245546
245547
245548
245549
245550
245551
245552
245553
245554
245555
245556
245557
245558
245559
245560
245561
245562
245563
245564
245565
245566
245567
245568
245569
245570
245571
245572
245573
245574
245575
245576
245577
245578
245579
245580
245581
245582
245583
245584
245585
245586
245587
245588
245589
245590
245591
245592
245593
245594
245595
245596
245597
245598
245599
245600
245601
245602
245603
245604
245605
245606
245607
245608
245609
245610
245611
245612
245613
245614
245615
245616
245617
245618
245619
245620
245621
245622
245623
245624
245625
245626
245627
245628
245629
245630
245631
245632
245633
245634
245635
245636
245637
245638
245639
245640
245641
245642
245643
245644
245645
245646
245647
245648
245649
245650
245651
245652
245653
245654
245655
245656
245657
245658
245659
245660
245661
245662
245663
245664
245665
245666
245667
245668
245669
245670
245671
245672
245673
245674
245675
245676
245677
245678
245679
245680
245681
245682
245683
245684
245685
245686
245687
245688
245689
245690
245691
245692
245693
245694
245695
245696
245697
245698
245699
245700
245701
245702
245703
245704
245705
245706
245707
245708
245709
245710
245711
245712
245713
245714
245715
245716
245717
245718
245719
245720
245721
245722
245723
245724
245725
245726
245727
245728
245729
245730
245731
245732
245733
245734
245735
245736
245737
245738
245739
245740
245741
245742
245743
245744
245745
245746
245747
245748
245749
245750
245751
245752
245753
245754
245755
245756
245757
245758
245759
245760
245761
245762
245763
245764
245765
245766
245767
245768
245769
245770
245771
245772
245773
245774
245775
245776
245777
245778
245779
245780
245781
245782
245783
245784
245785
245786
245787
245788
245789
245790
245791
245792
245793
245794
245795
245796
245797
245798
245799
245800
245801
245802
245803
245804
245805
245806
245807
245808
245809
245810
245811
245812
245813
245814
245815
245816
245817
245818
245819
245820
245821
245822
245823
245824
245825
245826
245827
245828
245829
245830
245831
245832
245833
245834
245835
245836
245837
245838
245839
245840
245841
245842
245843
245844
245845
245846
245847
245848
245849
245850
245851
245852
245853
245854
245855
245856
245857
245858
245859
245860
245861
245862
245863
245864
245865
245866
245867
245868
245869
245870
245871
245872
245873
245874
245875
245876
245877
245878
245879
245880
245881
245882
245883
245884
245885
245886
245887
245888
245889
245890
245891
245892
245893
245894
245895
245896
245897
245898
245899
245900
245901
245902
245903
245904
245905
245906
245907
245908
245909
245910
245911
245912
245913
245914
245915
245916
245917
245918
245919
245920
245921
245922
245923
245924
245925
245926
245927
245928
245929
245930
245931
245932
245933
245934
245935
245936
245937
245938
245939
245940
245941
245942
245943
245944
245945
245946
245947
245948
245949
245950
245951
245952
245953
245954
245955
245956
245957
245958
245959
245960
245961
245962
245963
245964
245965
245966
245967
245968
245969
245970
245971
245972
245973
245974
245975
245976
245977
245978
245979
245980
245981
245982
245983
245984
245985
245986
245987
245988
245989
245990
245991
245992
245993
245994
245995
245996
245997
245998
245999
246000
246001
246002
246003
246004
246005
246006
246007
246008
246009
246010
246011
246012
246013
246014
246015
246016
246017
246018
246019
246020
246021
246022
246023
246024
246025
246026
246027
246028
246029
246030
246031
246032
246033
246034
246035
246036
246037
246038
246039
246040
246041
246042
246043
246044
246045
246046
246047
246048
246049
246050
246051
246052
246053
246054
246055
246056
246057
246058
246059
246060
246061
246062
246063
246064
246065
246066
246067
246068
246069
246070
246071
246072
246073
246074
246075
246076
246077
246078
246079
246080
246081
246082
246083
246084
246085
246086
246087
246088
246089
246090
246091
246092
246093
246094
246095
246096
246097
246098
246099
246100
246101
246102
246103
246104
246105
246106
246107
246108
246109
246110
246111
246112
246113
246114
246115
246116
246117
246118
246119
246120
246121
246122
246123
246124
246125
246126
246127
246128
246129
246130
246131
246132
246133
246134
246135
246136
246137
246138
246139
246140
246141
246142
246143
246144
246145
246146
246147
246148
246149
246150
246151
246152
246153
246154
246155
246156
246157
246158
246159
246160
246161
246162
246163
246164
246165
246166
246167
246168
246169
246170
246171
246172
246173
246174
246175
246176
246177
246178
246179
246180
246181
246182
246183
246184
246185
246186
246187
246188
246189
246190
246191
246192
246193
246194
246195
246196
246197
246198
246199
246200
246201
246202
246203
246204
246205
246206
246207
246208
246209
246210
246211
246212
246213
246214
246215
246216
246217
246218
246219
246220
246221
246222
246223
246224
246225
246226
246227
246228
246229
246230
246231
246232
246233
246234
246235
246236
246237
246238
246239
246240
246241
246242
246243
246244
246245
246246
246247
246248
246249
246250
246251
246252
246253
246254
246255
246256
246257
246258
246259
246260
246261
246262
246263
246264
246265
246266
246267
246268
246269
246270
246271
246272
246273
246274
246275
246276
246277
246278
246279
246280
246281
246282
246283
246284
246285
246286
246287
246288
246289
246290
246291
246292
246293
246294
246295
246296
246297
246298
246299
246300
246301
246302
246303
246304
246305
246306
246307
246308
246309
246310
246311
246312
246313
246314
246315
246316
246317
246318
246319
246320
246321
246322
246323
246324
246325
246326
246327
246328
246329
246330
246331
246332
246333
246334
246335
246336
246337
246338
246339
246340
246341
246342
246343
246344
246345
246346
246347
246348
246349
246350
246351
246352
246353
246354
246355
246356
246357
246358
246359
246360
246361
246362
246363
246364
246365
246366
246367
246368
246369
246370
246371
246372
246373
246374
246375
246376
246377
246378
246379
246380
246381
246382
246383
246384
246385
246386
246387
246388
246389
246390
246391
246392
246393
246394
246395
246396
246397
246398
246399
246400
246401
246402
246403
246404
246405
246406
246407
246408
246409
246410
246411
246412
246413
246414
246415
246416
246417
246418
246419
246420
246421
246422
246423
246424
246425
246426
246427
246428
246429
246430
246431
246432
246433
246434
246435
246436
246437
246438
246439
246440
246441
246442
246443
246444
246445
246446
246447
246448
246449
246450
246451
246452
246453
246454
246455
246456
246457
246458
246459
246460
246461
246462
246463
246464
246465
246466
246467
246468
246469
246470
246471
246472
246473
246474
246475
246476
246477
246478
246479
246480
246481
246482
246483
246484
246485
246486
246487
246488
246489
246490
246491
246492
246493
246494
246495
246496
246497
246498
246499
246500
246501
246502
246503
246504
246505
246506
246507
246508
246509
246510
246511
246512
246513
246514
246515
246516
246517
246518
246519
246520
246521
246522
246523
246524
246525
246526
246527
246528
246529
246530
246531
246532
246533
246534
246535
246536
246537
246538
246539
246540
246541
246542
246543
246544
246545
246546
246547
246548
246549
246550
246551
246552
246553
246554
246555
246556
246557
246558
246559
246560
246561
246562
246563
246564
246565
246566
246567
246568
246569
246570
246571
246572
246573
246574
246575
246576
246577
246578
246579
246580
246581
246582
246583
246584
246585
246586
246587
246588
246589
246590
246591
246592
246593
246594
246595
246596
246597
246598
246599
246600
246601
246602
246603
246604
246605
246606
246607
246608
246609
246610
246611
246612
246613
246614
246615
246616
246617
246618
246619
246620
246621
246622
246623
246624
246625
246626
246627
246628
246629
246630
246631
246632
246633
246634
246635
246636
246637
246638
246639
246640
246641
246642
246643
246644
246645
246646
246647
246648
246649
246650
246651
246652
246653
246654
246655
246656
246657
246658
246659
246660
246661
246662
246663
246664
246665
246666
246667
246668
246669
246670
246671
246672
246673
246674
246675
246676
246677
246678
246679
246680
246681
246682
246683
246684
246685
246686
246687
246688
246689
246690
246691
246692
246693
246694
246695
246696
246697
246698
246699
246700
246701
246702
246703
246704
246705
246706
246707
246708
246709
246710
246711
246712
246713
246714
246715
246716
246717
246718
246719
246720
246721
246722
246723
246724
246725
246726
246727
246728
246729
246730
246731
246732
246733
246734
246735
246736
246737
246738
246739
246740
246741
246742
246743
246744
246745
246746
246747
246748
246749
246750
246751
246752
246753
246754
246755
246756
246757
246758
246759
246760
246761
246762
246763
246764
246765
246766
246767
246768
246769
246770
246771
246772
246773
246774
246775
246776
246777
246778
246779
246780
246781
246782
246783
246784
246785
246786
246787
246788
246789
246790
246791
246792
246793
246794
246795
246796
246797
246798
246799
246800
246801
246802
246803
246804
246805
246806
246807
246808
246809
246810
246811
246812
246813
246814
246815
246816
246817
246818
246819
246820
246821
246822
246823
246824
246825
246826
246827
246828
246829
246830
246831
246832
246833
246834
246835
246836
246837
246838
246839
246840
246841
246842
246843
246844
246845
246846
246847
246848
246849
246850
246851
246852
246853
246854
246855
246856
246857
246858
246859
246860
246861
246862
246863
246864
246865
246866
246867
246868
246869
246870
246871
246872
246873
246874
246875
246876
246877
246878
246879
246880
246881
246882
246883
246884
246885
246886
246887
246888
246889
246890
246891
246892
246893
246894
246895
246896
246897
246898
246899
246900
246901
246902
246903
246904
246905
246906
246907
246908
246909
246910
246911
246912
246913
246914
246915
246916
246917
246918
246919
246920
246921
246922
246923
246924
246925
246926
246927
246928
246929
246930
246931
246932
246933
246934
246935
246936
246937
246938
246939
246940
246941
246942
246943
246944
246945
246946
246947
246948
246949
246950
246951
246952
246953
246954
246955
246956
246957
246958
246959
246960
246961
246962
246963
246964
246965
246966
246967
246968
246969
246970
246971
246972
246973
246974
246975
246976
246977
246978
246979
246980
246981
246982
246983
246984
246985
246986
246987
246988
246989
246990
246991
246992
246993
246994
246995
246996
246997
246998
246999
247000
247001
247002
247003
247004
247005
247006
247007
247008
247009
247010
247011
247012
247013
247014
247015
247016
247017
247018
247019
247020
247021
247022
247023
247024
247025
247026
247027
247028
247029
247030
247031
247032
247033
247034
247035
247036
247037
247038
247039
247040
247041
247042
247043
247044
247045
247046
247047
247048
247049
247050
247051
247052
247053
247054
247055
247056
247057
247058
247059
247060
247061
247062
247063
247064
247065
247066
247067
247068
247069
247070
247071
247072
247073
247074
247075
247076
247077
247078
247079
247080
247081
247082
247083
247084
247085
247086
247087
247088
247089
247090
247091
247092
247093
247094
247095
247096
247097
247098
247099
247100
247101
247102
247103
247104
247105
247106
247107
247108
247109
247110
247111
247112
247113
247114
247115
247116
247117
247118
247119
247120
247121
247122
247123
247124
247125
247126
247127
247128
247129
247130
247131
247132
247133
247134
247135
247136
247137
247138
247139
247140
247141
247142
247143
247144
247145
247146
247147
247148
247149
247150
247151
247152
247153
247154
247155
247156
247157
247158
247159
247160
247161
247162
247163
247164
247165
247166
247167
247168
247169
247170
247171
247172
247173
247174
247175
247176
247177
247178
247179
247180
247181
247182
247183
247184
247185
247186
247187
247188
247189
247190
247191
247192
247193
247194
247195
247196
247197
247198
247199
247200
247201
247202
247203
247204
247205
247206
247207
247208
247209
247210
247211
247212
247213
247214
247215
247216
247217
247218
247219
247220
247221
247222
247223
247224
247225
247226
247227
247228
247229
247230
247231
247232
247233
247234
247235
247236
247237
247238
247239
247240
247241
247242
247243
247244
247245
247246
247247
247248
247249
247250
247251
247252
247253
247254
247255
247256
247257
247258
247259
247260
247261
247262
247263
247264
247265
247266
247267
247268
247269
247270
247271
247272
247273
247274
247275
247276
247277
247278
247279
247280
247281
247282
247283
247284
247285
247286
247287
247288
247289
247290
247291
247292
247293
247294
247295
247296
247297
247298
247299
247300
247301
247302
247303
247304
247305
247306
247307
247308
247309
247310
247311
247312
247313
247314
247315
247316
247317
247318
247319
247320
247321
247322
247323
247324
247325
247326
247327
247328
247329
247330
247331
247332
247333
247334
247335
247336
247337
247338
247339
247340
247341
247342
247343
247344
247345
247346
247347
247348
247349
247350
247351
247352
247353
247354
247355
247356
247357
247358
247359
247360
247361
247362
247363
247364
247365
247366
247367
247368
247369
247370
247371
247372
247373
247374
247375
247376
247377
247378
247379
247380
247381
247382
247383
247384
247385
247386
247387
247388
247389
247390
247391
247392
247393
247394
247395
247396
247397
247398
247399
247400
247401
247402
247403
247404
247405
247406
247407
247408
247409
247410
247411
247412
247413
247414
247415
247416
247417
247418
247419
247420
247421
247422
247423
247424
247425
247426
247427
247428
247429
247430
247431
247432
247433
247434
247435
247436
247437
247438
247439
247440
247441
247442
247443
247444
247445
247446
247447
247448
247449
247450
247451
247452
247453
247454
247455
247456
247457
247458
247459
247460
247461
247462
247463
247464
247465
247466
247467
247468
247469
247470
247471
247472
247473
247474
247475
247476
247477
247478
247479
247480
247481
247482
247483
247484
247485
247486
247487
247488
247489
247490
247491
247492
247493
247494
247495
247496
247497
247498
247499
247500
247501
247502
247503
247504
247505
247506
247507
247508
247509
247510
247511
247512
247513
247514
247515
247516
247517
247518
247519
247520
247521
247522
247523
247524
247525
247526
247527
247528
247529
247530
247531
247532
247533
247534
247535
247536
247537
247538
247539
247540
247541
247542
247543
247544
247545
247546
247547
247548
247549
247550
247551
247552
247553
247554
247555
247556
247557
247558
247559
247560
247561
247562
247563
247564
247565
247566
247567
247568
247569
247570
247571
247572
247573
247574
247575
247576
247577
247578
247579
247580
247581
247582
247583
247584
247585
247586
247587
247588
247589
247590
247591
247592
247593
247594
247595
247596
247597
247598
247599
247600
247601
247602
247603
247604
247605
247606
247607
247608
247609
247610
247611
247612
247613
247614
247615
247616
247617
247618
247619
247620
247621
247622
247623
247624
247625
247626
247627
247628
247629
247630
247631
247632
247633
247634
247635
247636
247637
247638
247639
247640
247641
247642
247643
247644
247645
247646
247647
247648
247649
247650
247651
247652
247653
247654
247655
247656
247657
247658
247659
247660
247661
247662
247663
247664
247665
247666
247667
247668
247669
247670
247671
247672
247673
247674
247675
247676
247677
247678
247679
247680
247681
247682
247683
247684
247685
247686
247687
247688
247689
247690
247691
247692
247693
247694
247695
247696
247697
247698
247699
247700
247701
247702
247703
247704
247705
247706
247707
247708
247709
247710
247711
247712
247713
247714
247715
247716
247717
247718
247719
247720
247721
247722
247723
247724
247725
247726
247727
247728
247729
247730
247731
247732
247733
247734
247735
247736
247737
247738
247739
247740
247741
247742
247743
247744
247745
247746
247747
247748
247749
247750
247751
247752
247753
247754
247755
247756
247757
247758
247759
247760
247761
247762
247763
247764
247765
247766
247767
247768
247769
247770
247771
247772
247773
247774
247775
247776
247777
247778
247779
247780
247781
247782
247783
247784
247785
247786
247787
247788
247789
247790
247791
247792
247793
247794
247795
247796
247797
247798
247799
247800
247801
247802
247803
247804
247805
247806
247807
247808
247809
247810
247811
247812
247813
247814
247815
247816
247817
247818
247819
247820
247821
247822
247823
247824
247825
247826
247827
247828
247829
247830
247831
247832
247833
247834
247835
247836
247837
247838
247839
247840
247841
247842
247843
247844
247845
247846
247847
247848
247849
247850
247851
247852
247853
247854
247855
247856
247857
247858
247859
247860
247861
247862
247863
247864
247865
247866
247867
247868
247869
247870
247871
247872
247873
247874
247875
247876
247877
247878
247879
247880
247881
247882
247883
247884
247885
247886
247887
247888
247889
247890
247891
247892
247893
247894
247895
247896
247897
247898
247899
247900
247901
247902
247903
247904
247905
247906
247907
247908
247909
247910
247911
247912
247913
247914
247915
247916
247917
247918
247919
247920
247921
247922
247923
247924
247925
247926
247927
247928
247929
247930
247931
247932
247933
247934
247935
247936
247937
247938
247939
247940
247941
247942
247943
247944
247945
247946
247947
247948
247949
247950
247951
247952
247953
247954
247955
247956
247957
247958
247959
247960
247961
247962
247963
247964
247965
247966
247967
247968
247969
247970
247971
247972
247973
247974
247975
247976
247977
247978
247979
247980
247981
247982
247983
247984
247985
247986
247987
247988
247989
247990
247991
247992
247993
247994
247995
247996
247997
247998
247999
248000
248001
248002
248003
248004
248005
248006
248007
248008
248009
248010
248011
248012
248013
248014
248015
248016
248017
248018
248019
248020
248021
248022
248023
248024
248025
248026
248027
248028
248029
248030
248031
248032
248033
248034
248035
248036
248037
248038
248039
248040
248041
248042
248043
248044
248045
248046
248047
248048
248049
248050
248051
248052
248053
248054
248055
248056
248057
248058
248059
248060
248061
248062
248063
248064
248065
248066
248067
248068
248069
248070
248071
248072
248073
248074
248075
248076
248077
248078
248079
248080
248081
248082
248083
248084
248085
248086
248087
248088
248089
248090
248091
248092
248093
248094
248095
248096
248097
248098
248099
248100
248101
248102
248103
248104
248105
248106
248107
248108
248109
248110
248111
248112
248113
248114
248115
248116
248117
248118
248119
248120
248121
248122
248123
248124
248125
248126
248127
248128
248129
248130
248131
248132
248133
248134
248135
248136
248137
248138
248139
248140
248141
248142
248143
248144
248145
248146
248147
248148
248149
248150
248151
248152
248153
248154
248155
248156
248157
248158
248159
248160
248161
248162
248163
248164
248165
248166
248167
248168
248169
248170
248171
248172
248173
248174
248175
248176
248177
248178
248179
248180
248181
248182
248183
248184
248185
248186
248187
248188
248189
248190
248191
248192
248193
248194
248195
248196
248197
248198
248199
248200
248201
248202
248203
248204
248205
248206
248207
248208
248209
248210
248211
248212
248213
248214
248215
248216
248217
248218
248219
248220
248221
248222
248223
248224
248225
248226
248227
248228
248229
248230
248231
248232
248233
248234
248235
248236
248237
248238
248239
248240
248241
248242
248243
248244
248245
248246
248247
248248
248249
248250
248251
248252
248253
248254
248255
248256
248257
248258
248259
248260
248261
248262
248263
248264
248265
248266
248267
248268
248269
248270
248271
248272
248273
248274
248275
248276
248277
248278
248279
248280
248281
248282
248283
248284
248285
248286
248287
248288
248289
248290
248291
248292
248293
248294
248295
248296
248297
248298
248299
248300
248301
248302
248303
248304
248305
248306
248307
248308
248309
248310
248311
248312
248313
248314
248315
248316
248317
248318
248319
248320
248321
248322
248323
248324
248325
248326
248327
248328
248329
248330
248331
248332
248333
248334
248335
248336
248337
248338
248339
248340
248341
248342
248343
248344
248345
248346
248347
248348
248349
248350
248351
248352
248353
248354
248355
248356
248357
248358
248359
248360
248361
248362
248363
248364
248365
248366
248367
248368
248369
248370
248371
248372
248373
248374
248375
248376
248377
248378
248379
248380
248381
248382
248383
248384
248385
248386
248387
248388
248389
248390
248391
248392
248393
248394
248395
248396
248397
248398
248399
248400
248401
248402
248403
248404
248405
248406
248407
248408
248409
248410
248411
248412
248413
248414
248415
248416
248417
248418
248419
248420
248421
248422
248423
248424
248425
248426
248427
248428
248429
248430
248431
248432
248433
248434
248435
248436
248437
248438
248439
248440
248441
248442
248443
248444
248445
248446
248447
248448
248449
248450
248451
248452
248453
248454
248455
248456
248457
248458
248459
248460
248461
248462
248463
248464
248465
248466
248467
248468
248469
248470
248471
248472
248473
248474
248475
248476
248477
248478
248479
248480
248481
248482
248483
248484
248485
248486
248487
248488
248489
248490
248491
248492
248493
248494
248495
248496
248497
248498
248499
248500
248501
248502
248503
248504
248505
248506
248507
248508
248509
248510
248511
248512
248513
248514
248515
248516
248517
248518
248519
248520
248521
248522
248523
248524
248525
248526
248527
248528
248529
248530
248531
248532
248533
248534
248535
248536
248537
248538
248539
248540
248541
248542
248543
248544
248545
248546
248547
248548
248549
248550
248551
248552
248553
248554
248555
248556
248557
248558
248559
248560
248561
248562
248563
248564
248565
248566
248567
248568
248569
248570
248571
248572
248573
248574
248575
248576
248577
248578
248579
248580
248581
248582
248583
248584
248585
248586
248587
248588
248589
248590
248591
248592
248593
248594
248595
248596
248597
248598
248599
248600
248601
248602
248603
248604
248605
248606
248607
248608
248609
248610
248611
248612
248613
248614
248615
248616
248617
248618
248619
248620
248621
248622
248623
248624
248625
248626
248627
248628
248629
248630
248631
248632
248633
248634
248635
248636
248637
248638
248639
248640
248641
248642
248643
248644
248645
248646
248647
248648
248649
248650
248651
248652
248653
248654
248655
248656
248657
248658
248659
248660
248661
248662
248663
248664
248665
248666
248667
248668
248669
248670
248671
248672
248673
248674
248675
248676
248677
248678
248679
248680
248681
248682
248683
248684
248685
248686
248687
248688
248689
248690
248691
248692
248693
248694
248695
248696
248697
248698
248699
248700
248701
248702
248703
248704
248705
248706
248707
248708
248709
248710
248711
248712
248713
248714
248715
248716
248717
248718
248719
248720
248721
248722
248723
248724
248725
248726
248727
248728
248729
248730
248731
248732
248733
248734
248735
248736
248737
248738
248739
248740
248741
248742
248743
248744
248745
248746
248747
248748
248749
248750
248751
248752
248753
248754
248755
248756
248757
248758
248759
248760
248761
248762
248763
248764
248765
248766
248767
248768
248769
248770
248771
248772
248773
248774
248775
248776
248777
248778
248779
248780
248781
248782
248783
248784
248785
248786
248787
248788
248789
248790
248791
248792
248793
248794
248795
248796
248797
248798
248799
248800
248801
248802
248803
248804
248805
248806
248807
248808
248809
248810
248811
248812
248813
248814
248815
248816
248817
248818
248819
248820
248821
248822
248823
248824
248825
248826
248827
248828
248829
248830
248831
248832
248833
248834
248835
248836
248837
248838
248839
248840
248841
248842
248843
248844
248845
248846
248847
248848
248849
248850
248851
248852
248853
248854
248855
248856
248857
248858
248859
248860
248861
248862
248863
248864
248865
248866
248867
248868
248869
248870
248871
248872
248873
248874
248875
248876
248877
248878
248879
248880
248881
248882
248883
248884
248885
248886
248887
248888
248889
248890
248891
248892
248893
248894
248895
248896
248897
248898
248899
248900
248901
248902
248903
248904
248905
248906
248907
248908
248909
248910
248911
248912
248913
248914
248915
248916
248917
248918
248919
248920
248921
248922
248923
248924
248925
248926
248927
248928
248929
248930
248931
248932
248933
248934
248935
248936
248937
248938
248939
248940
248941
248942
248943
248944
248945
248946
248947
248948
248949
248950
248951
248952
248953
248954
248955
248956
248957
248958
248959
248960
248961
248962
248963
248964
248965
248966
248967
248968
248969
248970
248971
248972
248973
248974
248975
248976
248977
248978
248979
248980
248981
248982
248983
248984
248985
248986
248987
248988
248989
248990
248991
248992
248993
248994
248995
248996
248997
248998
248999
249000
249001
249002
249003
249004
249005
249006
249007
249008
249009
249010
249011
249012
249013
249014
249015
249016
249017
249018
249019
249020
249021
249022
249023
249024
249025
249026
249027
249028
249029
249030
249031
249032
249033
249034
249035
249036
249037
249038
249039
249040
249041
249042
249043
249044
249045
249046
249047
249048
249049
249050
249051
249052
249053
249054
249055
249056
249057
249058
249059
249060
249061
249062
249063
249064
249065
249066
249067
249068
249069
249070
249071
249072
249073
249074
249075
249076
249077
249078
249079
249080
249081
249082
249083
249084
249085
249086
249087
249088
249089
249090
249091
249092
249093
249094
249095
249096
249097
249098
249099
249100
249101
249102
249103
249104
249105
249106
249107
249108
249109
249110
249111
249112
249113
249114
249115
249116
249117
249118
249119
249120
249121
249122
249123
249124
249125
249126
249127
249128
249129
249130
249131
249132
249133
249134
249135
249136
249137
249138
249139
249140
249141
249142
249143
249144
249145
249146
249147
249148
249149
249150
249151
249152
249153
249154
249155
249156
249157
249158
249159
249160
249161
249162
249163
249164
249165
249166
249167
249168
249169
249170
249171
249172
249173
249174
249175
249176
249177
249178
249179
249180
249181
249182
249183
249184
249185
249186
249187
249188
249189
249190
249191
249192
249193
249194
249195
249196
249197
249198
249199
249200
249201
249202
249203
249204
249205
249206
249207
249208
249209
249210
249211
249212
249213
249214
249215
249216
249217
249218
249219
249220
249221
249222
249223
249224
249225
249226
249227
249228
249229
249230
249231
249232
249233
249234
249235
249236
249237
249238
249239
249240
249241
249242
249243
249244
249245
249246
249247
249248
249249
249250
249251
249252
249253
249254
249255
249256
249257
249258
249259
249260
249261
249262
249263
249264
249265
249266
249267
249268
249269
249270
249271
249272
249273
249274
249275
249276
249277
249278
249279
249280
249281
249282
249283
249284
249285
249286
249287
249288
249289
249290
249291
249292
249293
249294
249295
249296
249297
249298
249299
249300
249301
249302
249303
249304
249305
249306
249307
249308
249309
249310
249311
249312
249313
249314
249315
249316
249317
249318
249319
249320
249321
249322
249323
249324
249325
249326
249327
249328
249329
249330
249331
249332
249333
249334
249335
249336
249337
249338
249339
249340
249341
249342
249343
249344
249345
249346
249347
249348
249349
249350
249351
249352
249353
249354
249355
249356
249357
249358
249359
249360
249361
249362
249363
249364
249365
249366
249367
249368
249369
249370
249371
249372
249373
249374
249375
249376
249377
249378
249379
249380
249381
249382
249383
249384
249385
249386
249387
249388
249389
249390
249391
249392
249393
249394
249395
249396
249397
249398
249399
249400
249401
249402
249403
249404
249405
249406
249407
249408
249409
249410
249411
249412
249413
249414
249415
249416
249417
249418
249419
249420
249421
249422
249423
249424
249425
249426
249427
249428
249429
249430
249431
249432
249433
249434
249435
249436
249437
249438
249439
249440
249441
249442
249443
249444
249445
249446
249447
249448
249449
249450
249451
249452
249453
249454
249455
249456
249457
249458
249459
249460
249461
249462
249463
249464
249465
249466
249467
249468
249469
249470
249471
249472
249473
249474
249475
249476
249477
249478
249479
249480
249481
249482
249483
249484
249485
249486
249487
249488
249489
249490
249491
249492
249493
249494
249495
249496
249497
249498
249499
249500
249501
249502
249503
249504
249505
249506
249507
249508
249509
249510
249511
249512
249513
249514
249515
249516
249517
249518
249519
249520
249521
249522
249523
249524
249525
249526
249527
249528
249529
249530
249531
249532
249533
249534
249535
249536
249537
249538
249539
249540
249541
249542
249543
249544
249545
249546
249547
249548
249549
249550
249551
249552
249553
249554
249555
249556
249557
249558
249559
249560
249561
249562
249563
249564
249565
249566
249567
249568
249569
249570
249571
249572
249573
249574
249575
249576
249577
249578
249579
249580
249581
249582
249583
249584
249585
249586
249587
249588
249589
249590
249591
249592
249593
249594
249595
249596
249597
249598
249599
249600
249601
249602
249603
249604
249605
249606
249607
249608
249609
249610
249611
249612
249613
249614
249615
249616
249617
249618
249619
249620
249621
249622
249623
249624
249625
249626
249627
249628
249629
249630
249631
249632
249633
249634
249635
249636
249637
249638
249639
249640
249641
249642
249643
249644
249645
249646
249647
249648
249649
249650
249651
249652
249653
249654
249655
249656
249657
249658
249659
249660
249661
249662
249663
249664
249665
249666
249667
249668
249669
249670
249671
249672
249673
249674
249675
249676
249677
249678
249679
249680
249681
249682
249683
249684
249685
249686
249687
249688
249689
249690
249691
249692
249693
249694
249695
249696
249697
249698
249699
249700
249701
249702
249703
249704
249705
249706
249707
249708
249709
249710
249711
249712
249713
249714
249715
249716
249717
249718
249719
249720
249721
249722
249723
249724
249725
249726
249727
249728
249729
249730
249731
249732
249733
249734
249735
249736
249737
249738
249739
249740
249741
249742
249743
249744
249745
249746
249747
249748
249749
249750
249751
249752
249753
249754
249755
249756
249757
249758
249759
249760
249761
249762
249763
249764
249765
249766
249767
249768
249769
249770
249771
249772
249773
249774
249775
249776
249777
249778
249779
249780
249781
249782
249783
249784
249785
249786
249787
249788
249789
249790
249791
249792
249793
249794
249795
249796
249797
249798
249799
249800
249801
249802
249803
249804
249805
249806
249807
249808
249809
249810
249811
249812
249813
249814
249815
249816
249817
249818
249819
249820
249821
249822
249823
249824
249825
249826
249827
249828
249829
249830
249831
249832
249833
249834
249835
249836
249837
249838
249839
249840
249841
249842
249843
249844
249845
249846
249847
249848
249849
249850
249851
249852
249853
249854
249855
249856
249857
249858
249859
249860
249861
249862
249863
249864
249865
249866
249867
249868
249869
249870
249871
249872
249873
249874
249875
249876
249877
249878
249879
249880
249881
249882
249883
249884
249885
249886
249887
249888
249889
249890
249891
249892
249893
249894
249895
249896
249897
249898
249899
249900
249901
249902
249903
249904
249905
249906
249907
249908
249909
249910
249911
249912
249913
249914
249915
249916
249917
249918
249919
249920
249921
249922
249923
249924
249925
249926
249927
249928
249929
249930
249931
249932
249933
249934
249935
249936
249937
249938
249939
249940
249941
249942
249943
249944
249945
249946
249947
249948
249949
249950
249951
249952
249953
249954
249955
249956
249957
249958
249959
249960
249961
249962
249963
249964
249965
249966
249967
249968
249969
249970
249971
249972
249973
249974
249975
249976
249977
249978
249979
249980
249981
249982
249983
249984
249985
249986
249987
249988
249989
249990
249991
249992
249993
249994
249995
249996
249997
249998
249999
250000
250001
250002
250003
250004
250005
250006
250007
250008
250009
250010
250011
250012
250013
250014
250015
250016
250017
250018
250019
250020
250021
250022
250023
250024
250025
250026
250027
250028
250029
250030
250031
250032
250033
250034
250035
250036
250037
250038
250039
250040
250041
250042
250043
250044
250045
250046
250047
250048
250049
250050
250051
250052
250053
250054
250055
250056
250057
250058
250059
250060
250061
250062
250063
250064
250065
250066
250067
250068
250069
250070
250071
250072
250073
250074
250075
250076
250077
250078
250079
250080
250081
250082
250083
250084
250085
250086
250087
250088
250089
250090
250091
250092
250093
250094
250095
250096
250097
250098
250099
250100
250101
250102
250103
250104
250105
250106
250107
250108
250109
250110
250111
250112
250113
250114
250115
250116
250117
250118
250119
250120
250121
250122
250123
250124
250125
250126
250127
250128
250129
250130
250131
250132
250133
250134
250135
250136
250137
250138
250139
250140
250141
250142
250143
250144
250145
250146
250147
250148
250149
250150
250151
250152
250153
250154
250155
250156
250157
250158
250159
250160
250161
250162
250163
250164
250165
250166
250167
250168
250169
250170
250171
250172
250173
250174
250175
250176
250177
250178
250179
250180
250181
250182
250183
250184
250185
250186
250187
250188
250189
250190
250191
250192
250193
250194
250195
250196
250197
250198
250199
250200
250201
250202
250203
250204
250205
250206
250207
250208
250209
250210
250211
250212
250213
250214
250215
250216
250217
250218
250219
250220
250221
250222
250223
250224
250225
250226
250227
250228
250229
250230
250231
250232
250233
250234
250235
250236
250237
250238
250239
250240
250241
250242
250243
250244
250245
250246
250247
250248
250249
250250
250251
250252
250253
250254
250255
250256
250257
250258
250259
250260
250261
250262
250263
250264
250265
250266
250267
250268
250269
250270
250271
250272
250273
250274
250275
250276
250277
250278
250279
250280
250281
250282
250283
250284
250285
250286
250287
250288
250289
250290
250291
250292
250293
250294
250295
250296
250297
250298
250299
250300
250301
250302
250303
250304
250305
250306
250307
250308
250309
250310
250311
250312
250313
250314
250315
250316
250317
250318
250319
250320
250321
250322
250323
250324
250325
250326
250327
250328
250329
250330
250331
250332
250333
250334
250335
250336
250337
250338
250339
250340
250341
250342
250343
250344
250345
250346
250347
250348
250349
250350
250351
250352
250353
250354
250355
250356
250357
250358
250359
250360
250361
250362
250363
250364
250365
250366
250367
250368
250369
250370
250371
250372
250373
250374
250375
250376
250377
250378
250379
250380
250381
250382
250383
250384
250385
250386
250387
250388
250389
250390
250391
250392
250393
250394
250395
250396
250397
250398
250399
250400
250401
250402
250403
250404
250405
250406
250407
250408
250409
250410
250411
250412
250413
250414
250415
250416
250417
250418
250419
250420
250421
250422
250423
250424
250425
250426
250427
250428
250429
250430
250431
250432
250433
250434
250435
250436
250437
250438
250439
250440
250441
250442
250443
250444
250445
250446
250447
250448
250449
250450
250451
250452
250453
250454
250455
250456
250457
250458
250459
250460
250461
250462
250463
250464
250465
250466
250467
250468
250469
250470
250471
250472
250473
250474
250475
250476
250477
250478
250479
250480
250481
250482
250483
250484
250485
250486
250487
250488
250489
250490
250491
250492
250493
250494
250495
250496
250497
250498
250499
250500
250501
250502
250503
250504
250505
250506
250507
250508
250509
250510
250511
250512
250513
250514
250515
250516
250517
250518
250519
250520
250521
250522
250523
250524
250525
250526
250527
250528
250529
250530
250531
250532
250533
250534
250535
250536
250537
250538
250539
250540
250541
250542
250543
250544
250545
250546
250547
250548
250549
250550
250551
250552
250553
250554
250555
250556
250557
250558
250559
250560
250561
250562
250563
250564
250565
250566
250567
250568
250569
250570
250571
250572
250573
250574
250575
250576
250577
250578
250579
250580
250581
250582
250583
250584
250585
250586
250587
250588
250589
250590
250591
250592
250593
250594
250595
250596
250597
250598
250599
250600
250601
250602
250603
250604
250605
250606
250607
250608
250609
250610
250611
250612
250613
250614
250615
250616
250617
250618
250619
250620
250621
250622
250623
250624
250625
250626
250627
250628
250629
250630
250631
250632
250633
250634
250635
250636
250637
250638
250639
250640
250641
250642
250643
250644
250645
250646
250647
250648
250649
250650
250651
250652
250653
250654
250655
250656
250657
250658
250659
250660
250661
250662
250663
250664
250665
250666
250667
250668
250669
250670
250671
250672
250673
250674
250675
250676
250677
250678
250679
250680
250681
250682
250683
250684
250685
250686
250687
250688
250689
250690
250691
250692
250693
250694
250695
250696
250697
250698
250699
250700
250701
250702
250703
250704
250705
250706
250707
250708
250709
250710
250711
250712
250713
250714
250715
250716
250717
250718
250719
250720
250721
250722
250723
250724
250725
250726
250727
250728
250729
250730
250731
250732
250733
250734
250735
250736
250737
250738
250739
250740
250741
250742
250743
250744
250745
250746
250747
250748
250749
250750
250751
250752
250753
250754
250755
250756
250757
250758
250759
250760
250761
250762
250763
250764
250765
250766
250767
250768
250769
250770
250771
250772
250773
250774
250775
250776
250777
250778
250779
250780
250781
250782
250783
250784
250785
250786
250787
250788
250789
250790
250791
250792
250793
250794
250795
250796
250797
250798
250799
250800
250801
250802
250803
250804
250805
250806
250807
250808
250809
250810
250811
250812
250813
250814
250815
250816
250817
250818
250819
250820
250821
250822
250823
250824
250825
250826
250827
250828
250829
250830
250831
250832
250833
250834
250835
250836
250837
250838
250839
250840
250841
250842
250843
250844
250845
250846
250847
250848
250849
250850
250851
250852
250853
250854
250855
250856
250857
250858
250859
250860
250861
250862
250863
250864
250865
250866
250867
250868
250869
250870
250871
250872
250873
250874
250875
250876
250877
250878
250879
250880
250881
250882
250883
250884
250885
250886
250887
250888
250889
250890
250891
250892
250893
250894
250895
250896
250897
250898
250899
250900
250901
250902
250903
250904
250905
250906
250907
250908
250909
250910
250911
250912
250913
250914
250915
250916
250917
250918
250919
250920
250921
250922
250923
250924
250925
250926
250927
250928
250929
250930
250931
250932
250933
250934
250935
250936
250937
250938
250939
250940
250941
250942
250943
250944
250945
250946
250947
250948
250949
250950
250951
250952
250953
250954
250955
250956
250957
250958
250959
250960
250961
250962
250963
250964
250965
250966
250967
250968
250969
250970
250971
250972
250973
250974
250975
250976
250977
250978
250979
250980
250981
250982
250983
250984
250985
250986
250987
250988
250989
250990
250991
250992
250993
250994
250995
250996
250997
250998
250999
251000
251001
251002
251003
251004
251005
251006
251007
251008
251009
251010
251011
251012
251013
251014
251015
251016
251017
251018
251019
251020
251021
251022
251023
251024
251025
251026
251027
251028
251029
251030
251031
251032
251033
251034
251035
251036
251037
251038
251039
251040
251041
251042
251043
251044
251045
251046
251047
251048
251049
251050
251051
251052
251053
251054
251055
251056
251057
251058
251059
251060
251061
251062
251063
251064
251065
251066
251067
251068
251069
251070
251071
251072
251073
251074
251075
251076
251077
251078
251079
251080
251081
251082
251083
251084
251085
251086
251087
251088
251089
251090
251091
251092
251093
251094
251095
251096
251097
251098
251099
251100
251101
251102
251103
251104
251105
251106
251107
251108
251109
251110
251111
251112
251113
251114
251115
251116
251117
251118
251119
251120
251121
251122
251123
251124
251125
251126
251127
251128
251129
251130
251131
251132
251133
251134
251135
251136
251137
251138
251139
251140
251141
251142
251143
251144
251145
251146
251147
251148
251149
251150
251151
251152
251153
251154
251155
251156
251157
251158
251159
251160
251161
251162
251163
251164
251165
251166
251167
251168
251169
251170
251171
251172
251173
251174
251175
251176
251177
251178
251179
251180
251181
251182
251183
251184
251185
251186
251187
251188
251189
251190
251191
251192
251193
251194
251195
251196
251197
251198
251199
251200
251201
251202
251203
251204
251205
251206
251207
251208
251209
251210
251211
251212
251213
251214
251215
251216
251217
251218
251219
251220
251221
251222
251223
251224
251225
251226
251227
251228
251229
251230
251231
251232
251233
251234
251235
251236
251237
251238
251239
251240
251241
251242
251243
251244
251245
251246
251247
251248
251249
251250
251251
251252
251253
251254
251255
251256
251257
251258
251259
251260
251261
251262
251263
251264
251265
251266
251267
251268
251269
251270
251271
251272
251273
251274
251275
251276
251277
251278
251279
251280
251281
251282
251283
251284
251285
251286
251287
251288
251289
251290
251291
251292
251293
251294
251295
251296
251297
251298
251299
251300
251301
251302
251303
251304
251305
251306
251307
251308
251309
251310
251311
251312
251313
251314
251315
251316
251317
251318
251319
251320
251321
251322
251323
251324
251325
251326
251327
251328
251329
251330
251331
251332
251333
251334
251335
251336
251337
251338
251339
251340
251341
251342
251343
251344
251345
251346
251347
251348
251349
251350
251351
251352
251353
251354
251355
251356
251357
251358
251359
251360
251361
251362
251363
251364
251365
251366
251367
251368
251369
251370
251371
251372
251373
251374
251375
251376
251377
251378
251379
251380
251381
251382
251383
251384
251385
251386
251387
251388
251389
251390
251391
251392
251393
251394
251395
251396
251397
251398
251399
251400
251401
251402
251403
251404
251405
251406
251407
251408
251409
251410
251411
251412
251413
251414
251415
251416
251417
251418
251419
251420
251421
251422
251423
251424
251425
251426
251427
251428
251429
251430
251431
251432
251433
251434
251435
251436
251437
251438
251439
251440
251441
251442
251443
251444
251445
251446
251447
251448
251449
251450
251451
251452
251453
251454
251455
251456
251457
251458
251459
251460
251461
251462
251463
251464
251465
251466
251467
251468
251469
251470
251471
251472
251473
251474
251475
251476
251477
251478
251479
251480
251481
251482
251483
251484
251485
251486
251487
251488
251489
251490
251491
251492
251493
251494
251495
251496
251497
251498
251499
251500
251501
251502
251503
251504
251505
251506
251507
251508
251509
251510
251511
251512
251513
251514
251515
251516
251517
251518
251519
251520
251521
251522
251523
251524
251525
251526
251527
251528
251529
251530
251531
251532
251533
251534
251535
251536
251537
251538
251539
251540
251541
251542
251543
251544
251545
251546
251547
251548
251549
251550
251551
251552
251553
251554
251555
251556
251557
251558
251559
251560
251561
251562
251563
251564
251565
251566
251567
251568
251569
251570
251571
251572
251573
251574
251575
251576
251577
251578
251579
251580
251581
251582
251583
251584
251585
251586
251587
251588
251589
251590
251591
251592
251593
251594
251595
251596
251597
251598
251599
251600
251601
251602
251603
251604
251605
251606
251607
251608
251609
251610
251611
251612
251613
251614
251615
251616
251617
251618
251619
251620
251621
251622
251623
251624
251625
251626
251627
251628
251629
251630
251631
251632
251633
251634
251635
251636
251637
251638
251639
251640
251641
251642
251643
251644
251645
251646
251647
251648
251649
251650
251651
251652
251653
251654
251655
251656
251657
251658
251659
251660
251661
251662
251663
251664
251665
251666
251667
251668
251669
251670
251671
251672
251673
251674
251675
251676
251677
251678
251679
251680
251681
251682
251683
251684
251685
251686
251687
251688
251689
251690
251691
251692
251693
251694
251695
251696
251697
251698
251699
251700
251701
251702
251703
251704
251705
251706
251707
251708
251709
251710
251711
251712
251713
251714
251715
251716
251717
251718
251719
251720
251721
251722
251723
251724
251725
251726
251727
251728
251729
251730
251731
251732
251733
251734
251735
251736
251737
251738
251739
251740
251741
251742
251743
251744
251745
251746
251747
251748
251749
251750
251751
251752
251753
251754
251755
251756
251757
251758
251759
251760
251761
251762
251763
251764
251765
251766
251767
251768
251769
251770
251771
251772
251773
251774
251775
251776
251777
251778
251779
251780
251781
251782
251783
251784
251785
251786
251787
251788
251789
251790
251791
251792
251793
251794
251795
251796
251797
251798
251799
251800
251801
251802
251803
251804
251805
251806
251807
251808
251809
251810
251811
251812
251813
251814
251815
251816
251817
251818
251819
251820
251821
251822
251823
251824
251825
251826
251827
251828
251829
251830
251831
251832
251833
251834
251835
251836
251837
251838
251839
251840
251841
251842
251843
251844
251845
251846
251847
251848
251849
251850
251851
251852
251853
251854
251855
251856
251857
251858
251859
251860
251861
251862
251863
251864
251865
251866
251867
251868
251869
251870
251871
251872
251873
251874
251875
251876
251877
251878
251879
251880
251881
251882
251883
251884
251885
251886
251887
251888
251889
251890
251891
251892
251893
251894
251895
251896
251897
251898
251899
251900
251901
251902
251903
251904
251905
251906
251907
251908
251909
251910
251911
251912
251913
251914
251915
251916
251917
251918
251919
251920
251921
251922
251923
251924
251925
251926
251927
251928
251929
251930
251931
251932
251933
251934
251935
251936
251937
251938
251939
251940
251941
251942
251943
251944
251945
251946
251947
251948
251949
251950
251951
251952
251953
251954
251955
251956
251957
251958
251959
251960
251961
251962
251963
251964
251965
251966
251967
251968
251969
251970
251971
251972
251973
251974
251975
251976
251977
251978
251979
251980
251981
251982
251983
251984
251985
251986
251987
251988
251989
251990
251991
251992
251993
251994
251995
251996
251997
251998
251999
252000
252001
252002
252003
252004
252005
252006
252007
252008
252009
252010
252011
252012
252013
252014
252015
252016
252017
252018
252019
252020
252021
252022
252023
252024
252025
252026
252027
252028
252029
252030
252031
252032
252033
252034
252035
252036
252037
252038
252039
252040
252041
252042
252043
252044
252045
252046
252047
252048
252049
252050
252051
252052
252053
252054
252055
252056
252057
252058
252059
252060
252061
252062
252063
252064
252065
252066
252067
252068
252069
252070
252071
252072
252073
252074
252075
252076
252077
252078
252079
252080
252081
252082
252083
252084
252085
252086
252087
252088
252089
252090
252091
252092
252093
252094
252095
252096
252097
252098
252099
252100
252101
252102
252103
252104
252105
252106
252107
252108
252109
252110
252111
252112
252113
252114
252115
252116
252117
252118
252119
252120
252121
252122
252123
252124
252125
252126
252127
252128
252129
252130
252131
252132
252133
252134
252135
252136
252137
252138
252139
252140
252141
252142
252143
252144
252145
252146
252147
252148
252149
252150
252151
252152
252153
252154
252155
252156
252157
252158
252159
252160
252161
252162
252163
252164
252165
252166
252167
252168
252169
252170
252171
252172
252173
252174
252175
252176
252177
252178
252179
252180
252181
252182
252183
252184
252185
252186
252187
252188
252189
252190
252191
252192
252193
252194
252195
252196
252197
252198
252199
252200
252201
252202
252203
252204
252205
252206
252207
252208
252209
252210
252211
252212
252213
252214
252215
252216
252217
252218
252219
252220
252221
252222
252223
252224
252225
252226
252227
252228
252229
252230
252231
252232
252233
252234
252235
252236
252237
252238
252239
252240
252241
252242
252243
252244
252245
252246
252247
252248
252249
252250
252251
252252
252253
252254
252255
252256
252257
252258
252259
252260
252261
252262
252263
252264
252265
252266
252267
252268
252269
252270
252271
252272
252273
252274
252275
252276
252277
252278
252279
252280
252281
252282
252283
252284
252285
252286
252287
252288
252289
252290
252291
252292
252293
252294
252295
252296
252297
252298
252299
252300
252301
252302
252303
252304
252305
252306
252307
252308
252309
252310
252311
252312
252313
252314
252315
252316
252317
252318
252319
252320
252321
252322
252323
252324
252325
252326
252327
252328
252329
252330
252331
252332
252333
252334
252335
252336
252337
252338
252339
252340
252341
252342
252343
252344
252345
252346
252347
252348
252349
252350
252351
252352
252353
252354
252355
252356
252357
252358
252359
252360
252361
252362
252363
252364
252365
252366
252367
252368
252369
252370
252371
252372
252373
252374
252375
252376
252377
252378
252379
252380
252381
252382
252383
252384
252385
252386
252387
252388
252389
252390
252391
252392
252393
252394
252395
252396
252397
252398
252399
252400
252401
252402
252403
252404
252405
252406
252407
252408
252409
252410
252411
252412
252413
252414
252415
252416
252417
252418
252419
252420
252421
252422
252423
252424
252425
252426
252427
252428
252429
252430
252431
252432
252433
252434
252435
252436
252437
252438
252439
252440
252441
252442
252443
252444
252445
252446
252447
252448
252449
252450
252451
252452
252453
252454
252455
252456
252457
252458
252459
252460
252461
252462
252463
252464
252465
252466
252467
252468
252469
252470
252471
252472
252473
252474
252475
252476
252477
252478
252479
252480
252481
252482
252483
252484
252485
252486
252487
252488
252489
252490
252491
252492
252493
252494
252495
252496
252497
252498
252499
252500
252501
252502
252503
252504
252505
252506
252507
252508
252509
252510
252511
252512
252513
252514
252515
252516
252517
252518
252519
252520
252521
252522
252523
252524
252525
252526
252527
252528
252529
252530
252531
252532
252533
252534
252535
252536
252537
252538
252539
252540
252541
252542
252543
252544
252545
252546
252547
252548
252549
252550
252551
252552
252553
252554
252555
252556
252557
252558
252559
252560
252561
252562
252563
252564
252565
252566
252567
252568
252569
252570
252571
252572
252573
252574
252575
252576
252577
252578
252579
252580
252581
252582
252583
252584
252585
252586
252587
252588
252589
252590
252591
252592
252593
252594
252595
252596
252597
252598
252599
252600
252601
252602
252603
252604
252605
252606
252607
252608
252609
252610
252611
252612
252613
252614
252615
252616
252617
252618
252619
252620
252621
252622
252623
252624
252625
252626
252627
252628
252629
252630
252631
252632
252633
252634
252635
252636
252637
252638
252639
252640
252641
252642
252643
252644
252645
252646
252647
252648
252649
252650
252651
252652
252653
252654
252655
252656
252657
252658
252659
252660
252661
252662
252663
252664
252665
252666
252667
252668
252669
252670
252671
252672
252673
252674
252675
252676
252677
252678
252679
252680
252681
252682
252683
252684
252685
252686
252687
252688
252689
252690
252691
252692
252693
252694
252695
252696
252697
252698
252699
252700
252701
252702
252703
252704
252705
252706
252707
252708
252709
252710
252711
252712
252713
252714
252715
252716
252717
252718
252719
252720
252721
252722
252723
252724
252725
252726
252727
252728
252729
252730
252731
252732
252733
252734
252735
252736
252737
252738
252739
252740
252741
252742
252743
252744
252745
252746
252747
252748
252749
252750
252751
252752
252753
252754
252755
252756
252757
252758
252759
252760
252761
252762
252763
252764
252765
252766
252767
252768
252769
252770
252771
252772
252773
252774
252775
252776
252777
252778
252779
252780
252781
252782
252783
252784
252785
252786
252787
252788
252789
252790
252791
252792
252793
252794
252795
252796
252797
252798
252799
252800
252801
252802
252803
252804
252805
252806
252807
252808
252809
252810
252811
252812
252813
252814
252815
252816
252817
252818
252819
252820
252821
252822
252823
252824
252825
252826
252827
252828
252829
252830
252831
252832
252833
252834
252835
252836
252837
252838
252839
252840
252841
252842
252843
252844
252845
252846
252847
252848
252849
252850
252851
252852
252853
252854
252855
252856
252857
252858
252859
252860
252861
252862
252863
252864
252865
252866
252867
252868
252869
252870
252871
252872
252873
252874
252875
252876
252877
252878
252879
252880
252881
252882
252883
252884
252885
252886
252887
252888
252889
252890
252891
252892
252893
252894
252895
252896
252897
252898
252899
252900
252901
252902
252903
252904
252905
252906
252907
252908
252909
252910
252911
252912
252913
252914
252915
252916
252917
252918
252919
252920
252921
252922
252923
252924
252925
252926
252927
252928
252929
252930
252931
252932
252933
252934
252935
252936
252937
252938
252939
252940
252941
252942
252943
252944
252945
252946
252947
252948
252949
252950
252951
252952
252953
252954
252955
252956
252957
252958
252959
252960
252961
252962
252963
252964
252965
252966
252967
252968
252969
252970
252971
252972
252973
252974
252975
252976
252977
252978
252979
252980
252981
252982
252983
252984
252985
252986
252987
252988
252989
252990
252991
252992
252993
252994
252995
252996
252997
252998
252999
253000
253001
253002
253003
253004
253005
253006
253007
253008
253009
253010
253011
253012
253013
253014
253015
253016
253017
253018
253019
253020
253021
253022
253023
253024
253025
253026
253027
253028
253029
253030
253031
253032
253033
253034
253035
253036
253037
253038
253039
253040
253041
253042
253043
253044
253045
253046
253047
253048
253049
253050
253051
253052
253053
253054
253055
253056
253057
253058
253059
253060
253061
253062
253063
253064
253065
253066
253067
253068
253069
253070
253071
253072
253073
253074
253075
253076
253077
253078
253079
253080
253081
253082
253083
253084
253085
253086
253087
253088
253089
253090
253091
253092
253093
253094
253095
253096
253097
253098
253099
253100
253101
253102
253103
253104
253105
253106
253107
253108
253109
253110
253111
253112
253113
253114
253115
253116
253117
253118
253119
253120
253121
253122
253123
253124
253125
253126
253127
253128
253129
253130
253131
253132
253133
253134
253135
253136
253137
253138
253139
253140
253141
253142
253143
253144
253145
253146
253147
253148
253149
253150
253151
253152
253153
253154
253155
253156
253157
253158
253159
253160
253161
253162
253163
253164
253165
253166
253167
253168
253169
253170
253171
253172
253173
253174
253175
253176
253177
253178
253179
253180
253181
253182
253183
253184
253185
253186
253187
253188
253189
253190
253191
253192
253193
253194
253195
253196
253197
253198
253199
253200
253201
253202
253203
253204
253205
253206
253207
253208
253209
253210
253211
253212
253213
253214
253215
253216
253217
253218
253219
253220
253221
253222
253223
253224
253225
253226
253227
253228
253229
253230
253231
253232
253233
253234
253235
253236
253237
253238
253239
253240
253241
253242
253243
253244
253245
253246
253247
253248
253249
253250
253251
253252
253253
253254
253255
253256
253257
253258
253259
253260
253261
253262
253263
253264
253265
253266
253267
253268
253269
253270
253271
253272
253273
253274
253275
253276
253277
253278
253279
253280
253281
253282
253283
253284
253285
253286
253287
253288
253289
253290
253291
253292
253293
253294
253295
253296
253297
253298
253299
253300
253301
253302
253303
253304
253305
253306
253307
253308
253309
253310
253311
253312
253313
253314
253315
253316
253317
253318
253319
253320
253321
253322
253323
253324
253325
253326
253327
253328
253329
253330
253331
253332
253333
253334
253335
253336
253337
253338
253339
253340
253341
253342
253343
253344
253345
253346
253347
253348
253349
253350
253351
253352
253353
253354
253355
253356
253357
253358
253359
253360
253361
253362
253363
253364
253365
253366
253367
253368
253369
253370
253371
253372
253373
253374
253375
253376
253377
253378
253379
253380
253381
253382
253383
253384
253385
253386
253387
253388
253389
253390
253391
253392
253393
253394
253395
253396
253397
253398
253399
253400
253401
253402
253403
253404
253405
253406
253407
253408
253409
253410
253411
253412
253413
253414
253415
253416
253417
253418
253419
253420
253421
253422
253423
253424
253425
253426
253427
253428
253429
253430
253431
253432
253433
253434
253435
253436
253437
253438
253439
253440
253441
253442
253443
253444
253445
253446
253447
253448
253449
253450
253451
253452
253453
253454
253455
253456
253457
253458
253459
253460
253461
253462
253463
253464
253465
253466
253467
253468
253469
253470
253471
253472
253473
253474
253475
253476
253477
253478
253479
253480
253481
253482
253483
253484
253485
253486
253487
253488
253489
253490
253491
253492
253493
253494
253495
253496
253497
253498
253499
253500
253501
253502
253503
253504
253505
253506
253507
253508
253509
253510
253511
253512
253513
253514
253515
253516
253517
253518
253519
253520
253521
253522
253523
253524
253525
253526
253527
253528
253529
253530
253531
253532
253533
253534
253535
253536
253537
253538
253539
253540
253541
253542
253543
253544
253545
253546
253547
253548
253549
253550
253551
253552
253553
253554
253555
253556
253557
253558
253559
253560
253561
253562
253563
253564
253565
253566
253567
253568
253569
253570
253571
253572
253573
253574
253575
253576
253577
253578
253579
253580
253581
253582
253583
253584
253585
253586
253587
253588
253589
253590
253591
253592
253593
253594
253595
253596
253597
253598
253599
253600
253601
253602
253603
253604
253605
253606
253607
253608
253609
253610
253611
253612
253613
253614
253615
253616
253617
253618
253619
253620
253621
253622
253623
253624
253625
253626
253627
253628
253629
253630
253631
253632
253633
253634
253635
253636
253637
253638
253639
253640
253641
253642
253643
253644
253645
253646
253647
253648
253649
253650
253651
253652
253653
253654
253655
253656
253657
253658
253659
253660
253661
253662
253663
253664
253665
253666
253667
253668
253669
253670
253671
253672
253673
253674
253675
253676
253677
253678
253679
253680
253681
253682
253683
253684
253685
253686
253687
253688
253689
253690
253691
253692
253693
253694
253695
253696
253697
253698
253699
253700
253701
253702
253703
253704
253705
253706
253707
253708
253709
253710
253711
253712
253713
253714
253715
253716
253717
253718
253719
253720
253721
253722
253723
253724
253725
253726
253727
253728
253729
253730
253731
253732
253733
253734
253735
253736
253737
253738
253739
253740
253741
253742
253743
253744
253745
253746
253747
253748
253749
253750
253751
253752
253753
253754
253755
253756
253757
253758
253759
253760
253761
253762
253763
253764
253765
253766
253767
253768
253769
253770
253771
253772
253773
253774
253775
253776
253777
253778
253779
253780
253781
253782
253783
253784
253785
253786
253787
253788
253789
253790
253791
253792
253793
253794
253795
253796
253797
253798
253799
253800
253801
253802
253803
253804
253805
253806
253807
253808
253809
253810
253811
253812
253813
253814
253815
253816
253817
253818
253819
253820
253821
253822
253823
253824
253825
253826
253827
253828
253829
253830
253831
253832
253833
253834
253835
253836
253837
253838
253839
253840
253841
253842
253843
253844
253845
253846
253847
253848
253849
253850
253851
253852
253853
253854
253855
253856
253857
253858
253859
253860
253861
253862
253863
253864
253865
253866
253867
253868
253869
253870
253871
253872
253873
253874
253875
253876
253877
253878
253879
253880
253881
253882
253883
253884
253885
253886
253887
253888
253889
253890
253891
253892
253893
253894
253895
253896
253897
253898
253899
253900
253901
253902
253903
253904
253905
253906
253907
253908
253909
253910
253911
253912
253913
253914
253915
253916
253917
253918
253919
253920
253921
253922
253923
253924
253925
253926
253927
253928
253929
253930
253931
253932
253933
253934
253935
253936
253937
253938
253939
253940
253941
253942
253943
253944
253945
253946
253947
253948
253949
253950
253951
253952
253953
253954
253955
253956
253957
253958
253959
253960
253961
253962
253963
253964
253965
253966
253967
253968
253969
253970
253971
253972
253973
253974
253975
253976
253977
253978
253979
253980
253981
253982
253983
253984
253985
253986
253987
253988
253989
253990
253991
253992
253993
253994
253995
253996
253997
253998
253999
254000
254001
254002
254003
254004
254005
254006
254007
254008
254009
254010
254011
254012
254013
254014
254015
254016
254017
254018
254019
254020
254021
254022
254023
254024
254025
254026
254027
254028
254029
254030
254031
254032
254033
254034
254035
254036
254037
254038
254039
254040
254041
254042
254043
254044
254045
254046
254047
254048
254049
254050
254051
254052
254053
254054
254055
254056
254057
254058
254059
254060
254061
254062
254063
254064
254065
254066
254067
254068
254069
254070
254071
254072
254073
254074
254075
254076
254077
254078
254079
254080
254081
254082
254083
254084
254085
254086
254087
254088
254089
254090
254091
254092
254093
254094
254095
254096
254097
254098
254099
254100
254101
254102
254103
254104
254105
254106
254107
254108
254109
254110
254111
254112
254113
254114
254115
254116
254117
254118
254119
254120
254121
254122
254123
254124
254125
254126
254127
254128
254129
254130
254131
254132
254133
254134
254135
254136
254137
254138
254139
254140
254141
254142
254143
254144
254145
254146
254147
254148
254149
254150
254151
254152
254153
254154
254155
254156
254157
254158
254159
254160
254161
254162
254163
254164
254165
254166
254167
254168
254169
254170
254171
254172
254173
254174
254175
254176
254177
254178
254179
254180
254181
254182
254183
254184
254185
254186
254187
254188
254189
254190
254191
254192
254193
254194
254195
254196
254197
254198
254199
254200
254201
254202
254203
254204
254205
254206
254207
254208
254209
254210
254211
254212
254213
254214
254215
254216
254217
254218
254219
254220
254221
254222
254223
254224
254225
254226
254227
254228
254229
254230
254231
254232
254233
254234
254235
254236
254237
254238
254239
254240
254241
254242
254243
254244
254245
254246
254247
254248
254249
254250
254251
254252
254253
254254
254255
254256
254257
254258
254259
254260
254261
254262
254263
254264
254265
254266
254267
254268
254269
254270
254271
254272
254273
254274
254275
254276
254277
254278
254279
254280
254281
254282
254283
254284
254285
254286
254287
254288
254289
254290
254291
254292
254293
254294
254295
254296
254297
254298
254299
254300
254301
254302
254303
254304
254305
254306
254307
254308
254309
254310
254311
254312
254313
254314
254315
254316
254317
254318
254319
254320
254321
254322
254323
254324
254325
254326
254327
254328
254329
254330
254331
254332
254333
254334
254335
254336
254337
254338
254339
254340
254341
254342
254343
254344
254345
254346
254347
254348
254349
254350
254351
254352
254353
254354
254355
254356
254357
254358
254359
254360
254361
254362
254363
254364
254365
254366
254367
254368
254369
254370
254371
254372
254373
254374
254375
254376
254377
254378
254379
254380
254381
254382
254383
254384
254385
254386
254387
254388
254389
254390
254391
254392
254393
254394
254395
254396
254397
254398
254399
254400
254401
254402
254403
254404
254405
254406
254407
254408
254409
254410
254411
254412
254413
254414
254415
254416
254417
254418
254419
254420
254421
254422
254423
254424
254425
254426
254427
254428
254429
254430
254431
254432
254433
254434
254435
254436
254437
254438
254439
254440
254441
254442
254443
254444
254445
254446
254447
254448
254449
254450
254451
254452
254453
254454
254455
254456
254457
254458
254459
254460
254461
254462
254463
254464
254465
254466
254467
254468
254469
254470
254471
254472
254473
254474
254475
254476
254477
254478
254479
254480
254481
254482
254483
254484
254485
254486
254487
254488
254489
254490
254491
254492
254493
254494
254495
254496
254497
254498
254499
254500
254501
254502
254503
254504
254505
254506
254507
254508
254509
254510
254511
254512
254513
254514
254515
254516
254517
254518
254519
254520
254521
254522
254523
254524
254525
254526
254527
254528
254529
254530
254531
254532
254533
254534
254535
254536
254537
254538
254539
254540
254541
254542
254543
254544
254545
254546
254547
254548
254549
254550
254551
254552
254553
254554
254555
254556
254557
254558
254559
254560
254561
254562
254563
254564
254565
254566
254567
254568
254569
254570
254571
254572
254573
254574
254575
254576
254577
254578
254579
254580
254581
254582
254583
254584
254585
254586
254587
254588
254589
254590
254591
254592
254593
254594
254595
254596
254597
254598
254599
254600
254601
254602
254603
254604
254605
254606
254607
254608
254609
254610
254611
254612
254613
254614
254615
254616
254617
254618
254619
254620
254621
254622
254623
254624
254625
254626
254627
254628
254629
254630
254631
254632
254633
254634
254635
254636
254637
254638
254639
254640
254641
254642
254643
254644
254645
254646
254647
254648
254649
254650
254651
254652
254653
254654
254655
254656
254657
254658
254659
254660
254661
254662
254663
254664
254665
254666
254667
254668
254669
254670
254671
254672
254673
254674
254675
254676
254677
254678
254679
254680
254681
254682
254683
254684
254685
254686
254687
254688
254689
254690
254691
254692
254693
254694
254695
254696
254697
254698
254699
254700
254701
254702
254703
254704
254705
254706
254707
254708
254709
254710
254711
254712
254713
254714
254715
254716
254717
254718
254719
254720
254721
254722
254723
254724
254725
254726
254727
254728
254729
254730
254731
254732
254733
254734
254735
254736
254737
254738
254739
254740
254741
254742
254743
254744
254745
254746
254747
254748
254749
254750
254751
254752
254753
254754
254755
254756
254757
254758
254759
254760
254761
254762
254763
254764
254765
254766
254767
254768
254769
254770
254771
254772
254773
254774
254775
254776
254777
254778
254779
254780
254781
254782
254783
254784
254785
254786
254787
254788
254789
254790
254791
254792
254793
254794
254795
254796
254797
254798
254799
254800
254801
254802
254803
254804
254805
254806
254807
254808
254809
254810
254811
254812
254813
254814
254815
254816
254817
254818
254819
254820
254821
254822
254823
254824
254825
254826
254827
254828
254829
254830
254831
254832
254833
254834
254835
254836
254837
254838
254839
254840
254841
254842
254843
254844
254845
254846
254847
254848
254849
254850
254851
254852
254853
254854
254855
254856
254857
254858
254859
254860
254861
254862
254863
254864
254865
254866
254867
254868
254869
254870
254871
254872
254873
254874
254875
254876
254877
254878
254879
254880
254881
254882
254883
254884
254885
254886
254887
254888
254889
254890
254891
254892
254893
254894
254895
254896
254897
254898
254899
254900
254901
254902
254903
254904
254905
254906
254907
254908
254909
254910
254911
254912
254913
254914
254915
254916
254917
254918
254919
254920
254921
254922
254923
254924
254925
254926
254927
254928
254929
254930
254931
254932
254933
254934
254935
254936
254937
254938
254939
254940
254941
254942
254943
254944
254945
254946
254947
254948
254949
254950
254951
254952
254953
254954
254955
254956
254957
254958
254959
254960
254961
254962
254963
254964
254965
254966
254967
254968
254969
254970
254971
254972
254973
254974
254975
254976
254977
254978
254979
254980
254981
254982
254983
254984
254985
254986
254987
254988
254989
254990
254991
254992
254993
254994
254995
254996
254997
254998
254999
255000
255001
255002
255003
255004
255005
255006
255007
255008
255009
255010
255011
255012
255013
255014
255015
255016
255017
255018
255019
255020
255021
255022
255023
255024
255025
255026
255027
255028
255029
255030
255031
255032
255033
255034
255035
255036
255037
255038
255039
255040
255041
255042
255043
255044
255045
255046
255047
255048
255049
255050
255051
255052
255053
255054
255055
255056
255057
255058
255059
255060
255061
255062
255063
255064
255065
255066
255067
255068
255069
255070
255071
255072
255073
255074
255075
255076
255077
255078
255079
255080
255081
255082
255083
255084
255085
255086
255087
255088
255089
255090
255091
255092
255093
255094
255095
255096
255097
255098
255099
255100
255101
255102
255103
255104
255105
255106
255107
255108
255109
255110
255111
255112
255113
255114
255115
255116
255117
255118
255119
255120
255121
255122
255123
255124
255125
255126
255127
255128
255129
255130
255131
255132
255133
255134
255135
255136
255137
255138
255139
255140
255141
255142
255143
255144
255145
255146
255147
255148
255149
255150
255151
255152
255153
255154
255155
255156
255157
255158
255159
255160
255161
255162
255163
255164
255165
255166
255167
255168
255169
255170
255171
255172
255173
255174
255175
255176
255177
255178
255179
255180
255181
255182
255183
255184
255185
255186
255187
255188
255189
255190
255191
255192
255193
255194
255195
255196
255197
255198
255199
255200
255201
255202
255203
255204
255205
255206
255207
255208
255209
255210
255211
255212
255213
255214
255215
255216
255217
255218
255219
255220
255221
255222
255223
255224
255225
255226
255227
255228
255229
255230
255231
255232
255233
255234
255235
255236
255237
255238
255239
255240
255241
255242
255243
255244
255245
255246
255247
255248
255249
255250
255251
255252
255253
255254
255255
255256
255257
255258
255259
255260
255261
255262
255263
255264
255265
255266
255267
255268
255269
255270
255271
255272
255273
255274
255275
255276
255277
255278
255279
255280
255281
255282
255283
255284
255285
255286
255287
255288
255289
255290
255291
255292
255293
255294
255295
255296
255297
255298
255299
255300
255301
255302
255303
255304
255305
255306
255307
255308
255309
255310
255311
255312
255313
255314
255315
255316
255317
255318
255319
255320
255321
255322
255323
255324
255325
255326
255327
255328
255329
255330
255331
255332
255333
255334
255335
255336
255337
255338
255339
255340
255341
255342
255343
255344
255345
255346
255347
255348
255349
255350
255351
255352
255353
255354
255355
255356
255357
255358
255359
255360
255361
255362
255363
255364
255365
255366
255367
255368
255369
255370
255371
255372
255373
255374
255375
255376
255377
255378
255379
255380
255381
255382
255383
255384
255385
255386
255387
255388
255389
255390
255391
255392
255393
255394
255395
255396
255397
255398
255399
255400
255401
255402
255403
255404
255405
255406
255407
255408
255409
255410
255411
255412
255413
255414
255415
255416
255417
255418
255419
255420
255421
255422
255423
255424
255425
255426
255427
255428
255429
255430
255431
255432
255433
255434
255435
255436
255437
255438
255439
255440
255441
255442
255443
255444
255445
255446
255447
255448
255449
255450
255451
255452
255453
255454
255455
255456
255457
255458
255459
255460
255461
255462
255463
255464
255465
255466
255467
255468
255469
255470
255471
255472
255473
255474
255475
255476
255477
255478
255479
255480
255481
255482
255483
255484
255485
255486
255487
255488
255489
255490
255491
255492
255493
255494
255495
255496
255497
255498
255499
255500
255501
255502
255503
255504
255505
255506
255507
255508
255509
255510
255511
255512
255513
255514
255515
255516
255517
255518
255519
255520
255521
255522
255523
255524
255525
255526
255527
255528
255529
255530
255531
255532
255533
255534
255535
255536
255537
255538
255539
255540
255541
255542
255543
255544
255545
255546
255547
255548
255549
255550
255551
255552
255553
255554
255555
255556
255557
255558
255559
255560
255561
255562
255563
255564
255565
255566
255567
255568
255569
255570
255571
255572
255573
255574
255575
255576
255577
255578
255579
255580
255581
255582
255583
255584
255585
255586
255587
255588
255589
255590
255591
255592
255593
255594
255595
255596
255597
255598
255599
255600
255601
255602
255603
255604
255605
255606
255607
255608
255609
255610
255611
255612
255613
255614
255615
255616
255617
255618
255619
255620
255621
255622
255623
255624
255625
255626
255627
255628
255629
255630
255631
255632
255633
255634
255635
255636
255637
255638
255639
255640
255641
255642
255643
255644
255645
255646
255647
255648
255649
255650
255651
255652
255653
255654
255655
255656
255657
255658
255659
255660
255661
255662
255663
255664
255665
255666
255667
255668
255669
255670
255671
255672
255673
255674
255675
255676
255677
255678
255679
255680
255681
255682
255683
255684
255685
255686
255687
255688
255689
255690
255691
255692
255693
255694
255695
255696
255697
255698
255699
255700
255701
255702
255703
255704
255705
255706
255707
255708
255709
255710
255711
255712
255713
255714
255715
255716
255717
255718
255719
255720
255721
255722
255723
255724
255725
255726
255727
255728
255729
255730
255731
255732
255733
255734
255735
255736
255737
255738
255739
255740
255741
255742
255743
255744
255745
255746
255747
255748
255749
255750
255751
255752
255753
255754
255755
255756
255757
255758
255759
255760
255761
255762
255763
255764
255765
255766
255767
255768
255769
255770
255771
255772
255773
255774
255775
255776
255777
255778
255779
255780
255781
255782
255783
255784
255785
255786
255787
255788
255789
255790
255791
255792
255793
255794
255795
255796
255797
255798
255799
255800
255801
255802
255803
255804
255805
255806
255807
255808
255809
255810
255811
255812
255813
255814
255815
255816
255817
255818
255819
255820
255821
255822
255823
255824
255825
255826
255827
255828
255829
255830
255831
255832
255833
255834
255835
255836
255837
255838
255839
255840
255841
255842
255843
255844
255845
255846
255847
255848
255849
255850
255851
255852
255853
255854
255855
255856
255857
255858
255859
255860
255861
255862
255863
255864
255865
255866
255867
255868
255869
255870
255871
255872
255873
255874
255875
255876
255877
255878
255879
255880
255881
255882
255883
255884
255885
255886
255887
255888
255889
255890
255891
255892
255893
255894
255895
255896
255897
255898
255899
255900
255901
255902
255903
255904
255905
255906
255907
255908
255909
255910
255911
255912
255913
255914
255915
255916
255917
255918
255919
255920
255921
255922
255923
255924
255925
255926
255927
255928
255929
255930
255931
255932
255933
255934
255935
255936
255937
255938
255939
255940
255941
255942
255943
255944
255945
255946
255947
255948
255949
255950
255951
255952
255953
255954
255955
255956
255957
255958
255959
255960
255961
255962
255963
255964
255965
255966
255967
255968
255969
255970
255971
255972
255973
255974
255975
255976
255977
255978
255979
255980
255981
255982
255983
255984
255985
255986
255987
255988
255989
255990
255991
255992
255993
255994
255995
255996
255997
255998
255999
256000
256001
256002
256003
256004
256005
256006
256007
256008
256009
256010
256011
256012
256013
256014
256015
256016
256017
256018
256019
256020
256021
256022
256023
256024
256025
256026
256027
256028
256029
256030
256031
256032
256033
256034
256035
256036
256037
256038
256039
256040
256041
256042
256043
256044
256045
256046
256047
256048
256049
256050
256051
256052
256053
256054
256055
256056
256057
256058
256059
256060
256061
256062
256063
256064
256065
256066
256067
256068
256069
256070
256071
256072
256073
256074
256075
256076
256077
256078
256079
256080
256081
256082
256083
256084
256085
256086
256087
256088
256089
256090
256091
256092
256093
256094
256095
256096
256097
256098
256099
256100
256101
256102
256103
256104
256105
256106
256107
256108
256109
256110
256111
256112
256113
256114
256115
256116
256117
256118
256119
256120
256121
256122
256123
256124
256125
256126
256127
256128
256129
256130
256131
256132
256133
256134
256135
256136
256137
256138
256139
256140
256141
256142
256143
256144
256145
256146
256147
256148
256149
256150
256151
256152
256153
256154
256155
256156
256157
256158
256159
256160
256161
256162
256163
256164
256165
256166
256167
256168
256169
256170
256171
256172
256173
256174
256175
256176
256177
256178
256179
256180
256181
256182
256183
256184
256185
256186
256187
256188
256189
256190
256191
256192
256193
256194
256195
256196
256197
256198
256199
256200
256201
256202
256203
256204
256205
256206
256207
256208
256209
256210
256211
256212
256213
256214
256215
256216
256217
256218
256219
256220
256221
256222
256223
256224
256225
256226
256227
256228
256229
256230
256231
256232
256233
256234
256235
256236
256237
256238
256239
256240
256241
256242
256243
256244
256245
256246
256247
256248
256249
256250
256251
256252
256253
256254
256255
256256
256257
256258
256259
256260
256261
256262
256263
256264
256265
256266
256267
256268
256269
256270
256271
256272
256273
256274
256275
256276
256277
256278
256279
256280
256281
256282
256283
256284
256285
256286
256287
256288
256289
256290
256291
256292
256293
256294
256295
256296
256297
256298
256299
256300
256301
256302
256303
256304
256305
256306
256307
256308
256309
256310
256311
256312
256313
256314
256315
256316
256317
256318
256319
256320
256321
256322
256323
256324
256325
256326
256327
256328
256329
256330
256331
256332
256333
256334
256335
256336
256337
256338
256339
256340
256341
256342
256343
256344
256345
256346
256347
256348
256349
256350
256351
256352
256353
256354
256355
256356
256357
256358
256359
256360
256361
256362
256363
256364
256365
256366
256367
256368
256369
256370
256371
256372
256373
256374
256375
256376
256377
256378
256379
256380
256381
256382
256383
256384
256385
256386
256387
256388
256389
256390
256391
256392
256393
256394
256395
256396
256397
256398
256399
256400
256401
256402
256403
256404
256405
256406
256407
256408
256409
256410
256411
256412
256413
256414
256415
256416
256417
256418
256419
256420
256421
256422
256423
256424
256425
256426
256427
256428
256429
256430
256431
256432
256433
256434
256435
256436
256437
256438
256439
256440
256441
256442
256443
256444
256445
256446
256447
256448
256449
256450
256451
256452
256453
256454
256455
256456
256457
256458
256459
256460
256461
256462
256463
256464
256465
256466
256467
256468
256469
256470
256471
256472
256473
256474
256475
256476
256477
256478
256479
256480
256481
256482
256483
256484
256485
256486
256487
256488
256489
256490
256491
256492
256493
256494
256495
256496
256497
256498
256499
256500
256501
256502
256503
256504
256505
256506
256507
256508
256509
256510
256511
256512
256513
256514
256515
256516
256517
256518
256519
256520
256521
256522
256523
256524
256525
256526
256527
256528
256529
256530
256531
256532
256533
256534
256535
256536
256537
256538
256539
256540
256541
256542
256543
256544
256545
256546
256547
256548
256549
256550
256551
256552
256553
256554
256555
256556
256557
256558
256559
256560
256561
256562
256563
256564
256565
256566
256567
256568
256569
256570
256571
256572
256573
256574
256575
256576
256577
256578
256579
256580
256581
256582
256583
256584
256585
256586
256587
256588
256589
256590
256591
256592
256593
256594
256595
256596
256597
256598
256599
256600
256601
256602
256603
256604
256605
256606
256607
256608
256609
256610
256611
256612
256613
256614
256615
256616
256617
256618
256619
256620
256621
256622
256623
256624
256625
256626
256627
256628
256629
256630
256631
256632
256633
256634
256635
256636
256637
256638
256639
256640
256641
256642
256643
256644
256645
256646
256647
256648
256649
256650
256651
256652
256653
256654
256655
256656
256657
256658
256659
256660
256661
256662
256663
256664
256665
256666
256667
256668
256669
256670
256671
256672
256673
256674
256675
256676
256677
256678
256679
256680
256681
256682
256683
256684
256685
256686
256687
256688
256689
256690
256691
256692
256693
256694
256695
256696
256697
256698
256699
256700
256701
256702
256703
256704
256705
256706
256707
256708
256709
256710
256711
256712
256713
256714
256715
256716
256717
256718
256719
256720
256721
256722
256723
256724
256725
256726
256727
256728
256729
256730
256731
256732
256733
256734
256735
256736
256737
256738
256739
256740
256741
256742
256743
256744
256745
256746
256747
256748
256749
256750
256751
256752
256753
256754
256755
256756
256757
256758
256759
256760
256761
256762
256763
256764
256765
256766
256767
256768
256769
256770
256771
256772
256773
256774
256775
256776
256777
256778
256779
256780
256781
256782
256783
256784
256785
256786
256787
256788
256789
256790
256791
256792
256793
256794
256795
256796
256797
256798
256799
256800
256801
256802
256803
256804
256805
256806
256807
256808
256809
256810
256811
256812
256813
256814
256815
256816
256817
256818
256819
256820
256821
256822
256823
256824
256825
256826
256827
256828
256829
256830
256831
256832
256833
256834
256835
256836
256837
256838
256839
256840
256841
256842
256843
256844
256845
256846
256847
256848
256849
256850
256851
256852
256853
256854
256855
256856
256857
256858
256859
256860
256861
256862
256863
256864
256865
256866
256867
256868
256869
256870
256871
256872
256873
256874
256875
256876
256877
256878
256879
256880
256881
256882
256883
256884
256885
256886
256887
256888
256889
256890
256891
256892
256893
256894
256895
256896
256897
256898
256899
256900
256901
256902
256903
256904
256905
256906
256907
256908
256909
256910
256911
256912
256913
256914
256915
256916
256917
256918
256919
256920
256921
256922
256923
256924
256925
256926
256927
256928
256929
256930
256931
256932
256933
256934
256935
256936
256937
256938
256939
256940
256941
256942
256943
256944
256945
256946
256947
256948
256949
256950
256951
256952
256953
256954
256955
256956
256957
256958
256959
256960
256961
256962
256963
256964
256965
256966
256967
256968
256969
256970
256971
256972
256973
256974
256975
256976
256977
256978
256979
256980
256981
256982
256983
256984
256985
256986
256987
256988
256989
256990
256991
256992
256993
256994
256995
256996
256997
256998
256999
257000
257001
257002
257003
257004
257005
257006
257007
257008
257009
257010
257011
257012
257013
257014
257015
257016
257017
257018
257019
257020
257021
257022
257023
257024
257025
257026
257027
257028
257029
257030
257031
257032
257033
257034
257035
257036
257037
257038
257039
257040
257041
257042
257043
257044
257045
257046
257047
257048
257049
257050
257051
257052
257053
257054
257055
257056
257057
257058
257059
257060
257061
257062
257063
257064
257065
257066
257067
257068
257069
257070
257071
257072
257073
257074
257075
257076
257077
257078
257079
257080
257081
257082
257083
257084
257085
257086
257087
257088
257089
257090
257091
257092
257093
257094
257095
257096
257097
257098
257099
257100
257101
257102
257103
257104
257105
257106
257107
257108
257109
257110
257111
257112
257113
257114
257115
257116
257117
257118
257119
257120
257121
257122
257123
257124
257125
257126
257127
257128
257129
257130
257131
257132
257133
257134
257135
257136
257137
257138
257139
257140
257141
257142
257143
257144
257145
257146
257147
257148
257149
257150
257151
257152
257153
257154
257155
257156
257157
257158
257159
257160
257161
257162
257163
257164
257165
257166
257167
257168
257169
257170
257171
257172
257173
257174
257175
257176
257177
257178
257179
257180
257181
257182
257183
257184
257185
257186
257187
257188
257189
257190
257191
257192
257193
257194
257195
257196
257197
257198
257199
257200
257201
257202
257203
257204
257205
257206
257207
257208
257209
257210
257211
257212
257213
257214
257215
257216
257217
257218
257219
257220
257221
257222
257223
257224
257225
257226
257227
257228
257229
257230
257231
257232
257233
257234
257235
257236
257237
257238
257239
257240
257241
257242
257243
257244
257245
257246
257247
257248
257249
257250
257251
257252
257253
257254
257255
257256
257257
257258
257259
257260
257261
257262
257263
257264
257265
257266
257267
257268
257269
257270
257271
257272
257273
257274
257275
257276
257277
257278
257279
257280
257281
257282
257283
257284
257285
257286
257287
257288
257289
257290
257291
257292
257293
257294
257295
257296
257297
257298
257299
257300
257301
257302
257303
257304
257305
257306
257307
257308
257309
257310
257311
257312
257313
257314
257315
257316
257317
257318
257319
257320
257321
257322
257323
257324
257325
257326
257327
257328
257329
257330
257331
257332
257333
257334
257335
257336
257337
257338
257339
257340
257341
257342
257343
257344
257345
257346
257347
257348
257349
257350
257351
257352
257353
257354
257355
257356
257357
257358
257359
257360
257361
257362
257363
257364
257365
257366
257367
257368
257369
257370
257371
257372
257373
257374
257375
257376
257377
257378
257379
257380
257381
257382
257383
257384
257385
257386
257387
257388
257389
257390
257391
257392
257393
257394
257395
257396
257397
257398
257399
257400
257401
257402
257403
257404
257405
257406
257407
257408
257409
257410
257411
257412
257413
257414
257415
257416
257417
257418
257419
257420
257421
257422
257423
257424
257425
257426
257427
257428
257429
257430
257431
257432
257433
257434
257435
257436
257437
257438
257439
257440
257441
257442
257443
257444
257445
257446
257447
257448
257449
257450
257451
257452
257453
257454
257455
257456
257457
257458
257459
257460
257461
257462
257463
257464
257465
257466
257467
257468
257469
257470
257471
257472
257473
257474
257475
257476
257477
257478
257479
257480
257481
257482
257483
257484
257485
257486
257487
257488
257489
257490
257491
257492
257493
257494
257495
257496
257497
257498
257499
257500
257501
257502
257503
257504
257505
257506
257507
257508
257509
257510
257511
257512
257513
257514
257515
257516
257517
257518
257519
257520
257521
257522
257523
257524
257525
257526
257527
257528
257529
257530
257531
257532
257533
257534
257535
257536
257537
257538
257539
257540
257541
257542
257543
257544
257545
257546
257547
257548
257549
257550
257551
257552
257553
257554
257555
257556
257557
257558
257559
257560
257561
257562
257563
257564
257565
257566
257567
257568
257569
257570
257571
257572
257573
257574
257575
257576
257577
257578
257579
257580
257581
257582
257583
257584
257585
257586
257587
257588
257589
257590
257591
257592
257593
257594
257595
257596
257597
257598
257599
257600
257601
257602
257603
257604
257605
257606
257607
257608
257609
257610
257611
257612
257613
257614
257615
257616
257617
257618
257619
257620
257621
257622
257623
257624
257625
257626
257627
257628
257629
257630
257631
257632
257633
257634
257635
257636
257637
257638
257639
257640
257641
257642
257643
257644
257645
257646
257647
257648
257649
257650
257651
257652
257653
257654
257655
257656
257657
257658
257659
257660
257661
257662
257663
257664
257665
257666
257667
257668
257669
257670
257671
257672
257673
257674
257675
257676
257677
257678
257679
257680
257681
257682
257683
257684
257685
257686
257687
257688
257689
257690
257691
257692
257693
257694
257695
257696
257697
257698
257699
257700
257701
257702
257703
257704
257705
257706
257707
257708
257709
257710
257711
257712
257713
257714
257715
257716
257717
257718
257719
257720
257721
257722
257723
257724
257725
257726
257727
257728
257729
257730
257731
257732
257733
257734
257735
257736
257737
257738
257739
257740
257741
257742
257743
257744
257745
257746
257747
257748
257749
257750
257751
257752
257753
257754
257755
257756
257757
257758
257759
257760
257761
257762
257763
257764
257765
257766
257767
257768
257769
257770
257771
257772
257773
257774
257775
257776
257777
257778
257779
257780
257781
257782
257783
257784
257785
257786
257787
257788
257789
257790
257791
257792
257793
257794
257795
257796
257797
257798
257799
257800
257801
257802
257803
257804
257805
257806
257807
257808
257809
257810
257811
257812
257813
257814
257815
257816
257817
257818
257819
257820
257821
257822
257823
257824
257825
257826
257827
257828
257829
257830
257831
257832
257833
257834
257835
257836
257837
257838
257839
257840
257841
257842
257843
257844
257845
257846
257847
257848
257849
257850
257851
257852
257853
257854
257855
257856
257857
257858
257859
257860
257861
257862
257863
257864
257865
257866
257867
257868
257869
257870
257871
257872
257873
257874
257875
257876
257877
257878
257879
257880
257881
257882
257883
257884
257885
257886
257887
257888
257889
257890
257891
257892
257893
257894
257895
257896
257897
257898
257899
257900
257901
257902
257903
257904
257905
257906
257907
257908
257909
257910
257911
257912
257913
257914
257915
257916
257917
257918
257919
257920
257921
257922
257923
257924
257925
257926
257927
257928
257929
257930
257931
257932
257933
257934
257935
257936
257937
257938
257939
257940
257941
257942
257943
257944
257945
257946
257947
257948
257949
257950
257951
257952
257953
257954
257955
257956
257957
257958
257959
257960
257961
257962
257963
257964
257965
257966
257967
257968
257969
257970
257971
257972
257973
257974
257975
257976
257977
257978
257979
257980
257981
257982
257983
257984
257985
257986
257987
257988
257989
257990
257991
257992
257993
257994
257995
257996
257997
257998
257999
258000
258001
258002
258003
258004
258005
258006
258007
258008
258009
258010
258011
258012
258013
258014
258015
258016
258017
258018
258019
258020
258021
258022
258023
258024
258025
258026
258027
258028
258029
258030
258031
258032
258033
258034
258035
258036
258037
258038
258039
258040
258041
258042
258043
258044
258045
258046
258047
258048
258049
258050
258051
258052
258053
258054
258055
258056
258057
258058
258059
258060
258061
258062
258063
258064
258065
258066
258067
258068
258069
258070
258071
258072
258073
258074
258075
258076
258077
258078
258079
258080
258081
258082
258083
258084
258085
258086
258087
258088
258089
258090
258091
258092
258093
258094
258095
258096
258097
258098
258099
258100
258101
258102
258103
258104
258105
258106
258107
258108
258109
258110
258111
258112
258113
258114
258115
258116
258117
258118
258119
258120
258121
258122
258123
258124
258125
258126
258127
258128
258129
258130
258131
258132
258133
258134
258135
258136
258137
258138
258139
258140
258141
258142
258143
258144
258145
258146
258147
258148
258149
258150
258151
258152
258153
258154
258155
258156
258157
258158
258159
258160
258161
258162
258163
258164
258165
258166
258167
258168
258169
258170
258171
258172
258173
258174
258175
258176
258177
258178
258179
258180
258181
258182
258183
258184
258185
258186
258187
258188
258189
258190
258191
258192
258193
258194
258195
258196
258197
258198
258199
258200
258201
258202
258203
258204
258205
258206
258207
258208
258209
258210
258211
258212
258213
258214
258215
258216
258217
258218
258219
258220
258221
258222
258223
258224
258225
258226
258227
258228
258229
258230
258231
258232
258233
258234
258235
258236
258237
258238
258239
258240
258241
258242
258243
258244
258245
258246
258247
258248
258249
258250
258251
258252
258253
258254
258255
258256
258257
258258
258259
258260
258261
258262
258263
258264
258265
258266
258267
258268
258269
258270
258271
258272
258273
258274
258275
258276
258277
258278
258279
258280
258281
258282
258283
258284
258285
258286
258287
258288
258289
258290
258291
258292
258293
258294
258295
258296
258297
258298
258299
258300
258301
258302
258303
258304
258305
258306
258307
258308
258309
258310
258311
258312
258313
258314
258315
258316
258317
258318
258319
258320
258321
258322
258323
258324
258325
258326
258327
258328
258329
258330
258331
258332
258333
258334
258335
258336
258337
258338
258339
258340
258341
258342
258343
258344
258345
258346
258347
258348
258349
258350
258351
258352
258353
258354
258355
258356
258357
258358
258359
258360
258361
258362
258363
258364
258365
258366
258367
258368
258369
258370
258371
258372
258373
258374
258375
258376
258377
258378
258379
258380
258381
258382
258383
258384
258385
258386
258387
258388
258389
258390
258391
258392
258393
258394
258395
258396
258397
258398
258399
258400
258401
258402
258403
258404
258405
258406
258407
258408
258409
258410
258411
258412
258413
258414
258415
258416
258417
258418
258419
258420
258421
258422
258423
258424
258425
258426
258427
258428
258429
258430
258431
258432
258433
258434
258435
258436
258437
258438
258439
258440
258441
258442
258443
258444
258445
258446
258447
258448
258449
258450
258451
258452
258453
258454
258455
258456
258457
258458
258459
258460
258461
258462
258463
258464
258465
258466
258467
258468
258469
258470
258471
258472
258473
258474
258475
258476
258477
258478
258479
258480
258481
258482
258483
258484
258485
258486
258487
258488
258489
258490
258491
258492
258493
258494
258495
258496
258497
258498
258499
258500
258501
258502
258503
258504
258505
258506
258507
258508
258509
258510
258511
258512
258513
258514
258515
258516
258517
258518
258519
258520
258521
258522
258523
258524
258525
258526
258527
258528
258529
258530
258531
258532
258533
258534
258535
258536
258537
258538
258539
258540
258541
258542
258543
258544
258545
258546
258547
258548
258549
258550
258551
258552
258553
258554
258555
258556
258557
258558
258559
258560
258561
258562
258563
258564
258565
258566
258567
258568
258569
258570
258571
258572
258573
258574
258575
258576
258577
258578
258579
258580
258581
258582
258583
258584
258585
258586
258587
258588
258589
258590
258591
258592
258593
258594
258595
258596
258597
258598
258599
258600
258601
258602
258603
258604
258605
258606
258607
258608
258609
258610
258611
258612
258613
258614
258615
258616
258617
258618
258619
258620
258621
258622
258623
258624
258625
258626
258627
258628
258629
258630
258631
258632
258633
258634
258635
258636
258637
258638
258639
258640
258641
258642
258643
258644
258645
258646
258647
258648
258649
258650
258651
258652
258653
258654
258655
258656
258657
258658
258659
258660
258661
258662
258663
258664
258665
258666
258667
258668
258669
258670
258671
258672
258673
258674
258675
258676
258677
258678
258679
258680
258681
258682
258683
258684
258685
258686
258687
258688
258689
258690
258691
258692
258693
258694
258695
258696
258697
258698
258699
258700
258701
258702
258703
258704
258705
258706
258707
258708
258709
258710
258711
258712
258713
258714
258715
258716
258717
258718
258719
258720
258721
258722
258723
258724
258725
258726
258727
258728
258729
258730
258731
258732
258733
258734
258735
258736
258737
258738
258739
258740
258741
258742
258743
258744
258745
258746
258747
258748
258749
258750
258751
258752
258753
258754
258755
258756
258757
258758
258759
258760
258761
258762
258763
258764
258765
258766
258767
258768
258769
258770
258771
258772
258773
258774
258775
258776
258777
258778
258779
258780
258781
258782
258783
258784
258785
258786
258787
258788
258789
258790
258791
258792
258793
258794
258795
258796
258797
258798
258799
258800
258801
258802
258803
258804
258805
258806
258807
258808
258809
258810
258811
258812
258813
258814
258815
258816
258817
258818
258819
258820
258821
258822
258823
258824
258825
258826
258827
258828
258829
258830
258831
258832
258833
258834
258835
258836
258837
258838
258839
258840
258841
258842
258843
258844
258845
258846
258847
258848
258849
258850
258851
258852
258853
258854
258855
258856
258857
258858
258859
258860
258861
258862
258863
258864
258865
258866
258867
258868
258869
258870
258871
258872
258873
258874
258875
258876
258877
258878
258879
258880
258881
258882
258883
258884
258885
258886
258887
258888
258889
258890
258891
258892
258893
258894
258895
258896
258897
258898
258899
258900
258901
258902
258903
258904
258905
258906
258907
258908
258909
258910
258911
258912
258913
258914
258915
258916
258917
258918
258919
258920
258921
258922
258923
258924
258925
258926
258927
258928
258929
258930
258931
258932
258933
258934
258935
258936
258937
258938
258939
258940
258941
258942
258943
258944
258945
258946
258947
258948
258949
258950
258951
258952
258953
258954
258955
258956
258957
258958
258959
258960
258961
258962
258963
258964
258965
258966
258967
258968
258969
258970
258971
258972
258973
258974
258975
258976
258977
258978
258979
258980
258981
258982
258983
258984
258985
258986
258987
258988
258989
258990
258991
258992
258993
258994
258995
258996
258997
258998
258999
259000
259001
259002
259003
259004
259005
259006
259007
259008
259009
259010
259011
259012
259013
259014
259015
259016
259017
259018
259019
259020
259021
259022
259023
259024
259025
259026
259027
259028
259029
259030
259031
259032
259033
259034
259035
259036
259037
259038
259039
259040
259041
259042
259043
259044
259045
259046
259047
259048
259049
259050
259051
259052
259053
259054
259055
259056
259057
259058
259059
259060
259061
259062
259063
259064
259065
259066
259067
259068
259069
259070
259071
259072
259073
259074
259075
259076
259077
259078
259079
259080
259081
259082
259083
259084
259085
259086
259087
259088
259089
259090
259091
259092
259093
259094
259095
259096
259097
259098
259099
259100
259101
259102
259103
259104
259105
259106
259107
259108
259109
259110
259111
259112
259113
259114
259115
259116
259117
259118
259119
259120
259121
259122
259123
259124
259125
259126
259127
259128
259129
259130
259131
259132
259133
259134
259135
259136
259137
259138
259139
259140
259141
259142
259143
259144
259145
259146
259147
259148
259149
259150
259151
259152
259153
259154
259155
259156
259157
259158
259159
259160
259161
259162
259163
259164
259165
259166
259167
259168
259169
259170
259171
259172
259173
259174
259175
259176
259177
259178
259179
259180
259181
259182
259183
259184
259185
259186
259187
259188
259189
259190
259191
259192
259193
259194
259195
259196
259197
259198
259199
259200
259201
259202
259203
259204
259205
259206
259207
259208
259209
259210
259211
259212
259213
259214
259215
259216
259217
259218
259219
259220
259221
259222
259223
259224
259225
259226
259227
259228
259229
259230
259231
259232
259233
259234
259235
259236
259237
259238
259239
259240
259241
259242
259243
259244
259245
259246
259247
259248
259249
259250
259251
259252
259253
259254
259255
259256
259257
259258
259259
259260
259261
259262
259263
259264
259265
259266
259267
259268
259269
259270
259271
259272
259273
259274
259275
259276
259277
259278
259279
259280
259281
259282
259283
259284
259285
259286
259287
259288
259289
259290
259291
259292
259293
259294
259295
259296
259297
259298
259299
259300
259301
259302
259303
259304
259305
259306
259307
259308
259309
259310
259311
259312
259313
259314
259315
259316
259317
259318
259319
259320
259321
259322
259323
259324
259325
259326
259327
259328
259329
259330
259331
259332
259333
259334
259335
259336
259337
259338
259339
259340
259341
259342
259343
259344
259345
259346
259347
259348
259349
259350
259351
259352
259353
259354
259355
259356
259357
259358
259359
259360
259361
259362
259363
259364
259365
259366
259367
259368
259369
259370
259371
259372
259373
259374
259375
259376
259377
259378
259379
259380
259381
259382
259383
259384
259385
259386
259387
259388
259389
259390
259391
259392
259393
259394
259395
259396
259397
259398
259399
259400
259401
259402
259403
259404
259405
259406
259407
259408
259409
259410
259411
259412
259413
259414
259415
259416
259417
259418
259419
259420
259421
259422
259423
259424
259425
259426
259427
259428
259429
259430
259431
259432
259433
259434
259435
259436
259437
259438
259439
259440
259441
259442
259443
259444
259445
259446
259447
259448
259449
259450
259451
259452
259453
259454
259455
259456
259457
259458
259459
259460
259461
259462
259463
259464
259465
259466
259467
259468
259469
259470
259471
259472
259473
259474
259475
259476
259477
259478
259479
259480
259481
259482
259483
259484
259485
259486
259487
259488
259489
259490
259491
259492
259493
259494
259495
259496
259497
259498
259499
259500
259501
259502
259503
259504
259505
259506
259507
259508
259509
259510
259511
259512
259513
259514
259515
259516
259517
259518
259519
259520
259521
259522
259523
259524
259525
259526
259527
259528
259529
259530
259531
259532
259533
259534
259535
259536
259537
259538
259539
259540
259541
259542
259543
259544
259545
259546
259547
259548
259549
259550
259551
259552
259553
259554
259555
259556
259557
259558
259559
259560
259561
259562
259563
259564
259565
259566
259567
259568
259569
259570
259571
259572
259573
259574
259575
259576
259577
259578
259579
259580
259581
259582
259583
259584
259585
259586
259587
259588
259589
259590
259591
259592
259593
259594
259595
259596
259597
259598
259599
259600
259601
259602
259603
259604
259605
259606
259607
259608
259609
259610
259611
259612
259613
259614
259615
259616
259617
259618
259619
259620
259621
259622
259623
259624
259625
259626
259627
259628
259629
259630
259631
259632
259633
259634
259635
259636
259637
259638
259639
259640
259641
259642
259643
259644
259645
259646
259647
259648
259649
259650
259651
259652
259653
259654
259655
259656
259657
259658
259659
259660
259661
259662
259663
259664
259665
259666
259667
259668
259669
259670
259671
259672
259673
259674
259675
259676
259677
259678
259679
259680
259681
259682
259683
259684
259685
259686
259687
259688
259689
259690
259691
259692
259693
259694
259695
259696
259697
259698
259699
259700
259701
259702
259703
259704
259705
259706
259707
259708
259709
259710
259711
259712
259713
259714
259715
259716
259717
259718
259719
259720
259721
259722
259723
259724
259725
259726
259727
259728
259729
259730
259731
259732
259733
259734
259735
259736
259737
259738
259739
259740
259741
259742
259743
259744
259745
259746
259747
259748
259749
259750
259751
259752
259753
259754
259755
259756
259757
259758
259759
259760
259761
259762
259763
259764
259765
259766
259767
259768
259769
259770
259771
259772
259773
259774
259775
259776
259777
259778
259779
259780
259781
259782
259783
259784
259785
259786
259787
259788
259789
259790
259791
259792
259793
259794
259795
259796
259797
259798
259799
259800
259801
259802
259803
259804
259805
259806
259807
259808
259809
259810
259811
259812
259813
259814
259815
259816
259817
259818
259819
259820
259821
259822
259823
259824
259825
259826
259827
259828
259829
259830
259831
259832
259833
259834
259835
259836
259837
259838
259839
259840
259841
259842
259843
259844
259845
259846
259847
259848
259849
259850
259851
259852
259853
259854
259855
259856
259857
259858
259859
259860
259861
259862
259863
259864
259865
259866
259867
259868
259869
259870
259871
259872
259873
259874
259875
259876
259877
259878
259879
259880
259881
259882
259883
259884
259885
259886
259887
259888
259889
259890
259891
259892
259893
259894
259895
259896
259897
259898
259899
259900
259901
259902
259903
259904
259905
259906
259907
259908
259909
259910
259911
259912
259913
259914
259915
259916
259917
259918
259919
259920
259921
259922
259923
259924
259925
259926
259927
259928
259929
259930
259931
259932
259933
259934
259935
259936
259937
259938
259939
259940
259941
259942
259943
259944
259945
259946
259947
259948
259949
259950
259951
259952
259953
259954
259955
259956
259957
259958
259959
259960
259961
259962
259963
259964
259965
259966
259967
259968
259969
259970
259971
259972
259973
259974
259975
259976
259977
259978
259979
259980
259981
259982
259983
259984
259985
259986
259987
259988
259989
259990
259991
259992
259993
259994
259995
259996
259997
259998
259999
260000
260001
260002
260003
260004
260005
260006
260007
260008
260009
260010
260011
260012
260013
260014
260015
260016
260017
260018
260019
260020
260021
260022
260023
260024
260025
260026
260027
260028
260029
260030
260031
260032
260033
260034
260035
260036
260037
260038
260039
260040
260041
260042
260043
260044
260045
260046
260047
260048
260049
260050
260051
260052
260053
260054
260055
260056
260057
260058
260059
260060
260061
260062
260063
260064
260065
260066
260067
260068
260069
260070
260071
260072
260073
260074
260075
260076
260077
260078
260079
260080
260081
260082
260083
260084
260085
260086
260087
260088
260089
260090
260091
260092
260093
260094
260095
260096
260097
260098
260099
260100
260101
260102
260103
260104
260105
260106
260107
260108
260109
260110
260111
260112
260113
260114
260115
260116
260117
260118
260119
260120
260121
260122
260123
260124
260125
260126
260127
260128
260129
260130
260131
260132
260133
260134
260135
260136
260137
260138
260139
260140
260141
260142
260143
260144
260145
260146
260147
260148
260149
260150
260151
260152
260153
260154
260155
260156
260157
260158
260159
260160
260161
260162
260163
260164
260165
260166
260167
260168
260169
260170
260171
260172
260173
260174
260175
260176
260177
260178
260179
260180
260181
260182
260183
260184
260185
260186
260187
260188
260189
260190
260191
260192
260193
260194
260195
260196
260197
260198
260199
260200
260201
260202
260203
260204
260205
260206
260207
260208
260209
260210
260211
260212
260213
260214
260215
260216
260217
260218
260219
260220
260221
260222
260223
260224
260225
260226
260227
260228
260229
260230
260231
260232
260233
260234
260235
260236
260237
260238
260239
260240
260241
260242
260243
260244
260245
260246
260247
260248
260249
260250
260251
260252
260253
260254
260255
260256
260257
260258
260259
260260
260261
260262
260263
260264
260265
260266
260267
260268
260269
260270
260271
260272
260273
260274
260275
260276
260277
260278
260279
260280
260281
260282
260283
260284
260285
260286
260287
260288
260289
260290
260291
260292
260293
260294
260295
260296
260297
260298
260299
260300
260301
260302
260303
260304
260305
260306
260307
260308
260309
260310
260311
260312
260313
260314
260315
260316
260317
260318
260319
260320
260321
260322
260323
260324
260325
260326
260327
260328
260329
260330
260331
260332
260333
260334
260335
260336
260337
260338
260339
260340
260341
260342
260343
260344
260345
260346
260347
260348
260349
260350
260351
260352
260353
260354
260355
260356
260357
260358
260359
260360
260361
260362
260363
260364
260365
260366
260367
260368
260369
260370
260371
260372
260373
260374
260375
260376
260377
260378
260379
260380
260381
260382
260383
260384
260385
260386
260387
260388
260389
260390
260391
260392
260393
260394
260395
260396
260397
260398
260399
260400
260401
260402
260403
260404
260405
260406
260407
260408
260409
260410
260411
260412
260413
260414
260415
260416
260417
260418
260419
260420
260421
260422
260423
260424
260425
260426
260427
260428
260429
260430
260431
260432
260433
260434
260435
260436
260437
260438
260439
260440
260441
260442
260443
260444
260445
260446
260447
260448
260449
260450
260451
260452
260453
260454
260455
260456
260457
260458
260459
260460
260461
260462
260463
260464
260465
260466
260467
260468
260469
260470
260471
260472
260473
260474
260475
260476
260477
260478
260479
260480
260481
260482
260483
260484
260485
260486
260487
260488
260489
260490
260491
260492
260493
260494
260495
260496
260497
260498
260499
260500
260501
260502
260503
260504
260505
260506
260507
260508
260509
260510
260511
260512
260513
260514
260515
260516
260517
260518
260519
260520
260521
260522
260523
260524
260525
260526
260527
260528
260529
260530
260531
260532
260533
260534
260535
260536
260537
260538
260539
260540
260541
260542
260543
260544
260545
260546
260547
260548
260549
260550
260551
260552
260553
260554
260555
260556
260557
260558
260559
260560
260561
260562
260563
260564
260565
260566
260567
260568
260569
260570
260571
260572
260573
260574
260575
260576
260577
260578
260579
260580
260581
260582
260583
260584
260585
260586
260587
260588
260589
260590
260591
260592
260593
260594
260595
260596
260597
260598
260599
260600
260601
260602
260603
260604
260605
260606
260607
260608
260609
260610
260611
260612
260613
260614
260615
260616
260617
260618
260619
260620
260621
260622
260623
260624
260625
260626
260627
260628
260629
260630
260631
260632
260633
260634
260635
260636
260637
260638
260639
260640
260641
260642
260643
260644
260645
260646
260647
260648
260649
260650
260651
260652
260653
260654
260655
260656
260657
260658
260659
260660
260661
260662
260663
260664
260665
260666
260667
260668
260669
260670
260671
260672
260673
260674
260675
260676
260677
260678
260679
260680
260681
260682
260683
260684
260685
260686
260687
260688
260689
260690
260691
260692
260693
260694
260695
260696
260697
260698
260699
260700
260701
260702
260703
260704
260705
260706
260707
260708
260709
260710
260711
260712
260713
260714
260715
260716
260717
260718
260719
260720
260721
260722
260723
260724
260725
260726
260727
260728
260729
260730
260731
260732
260733
260734
260735
260736
260737
260738
260739
260740
260741
260742
260743
260744
260745
260746
260747
260748
260749
260750
260751
260752
260753
260754
260755
260756
260757
260758
260759
260760
260761
260762
260763
260764
260765
260766
260767
260768
260769
260770
260771
260772
260773
260774
260775
260776
260777
260778
260779
260780
260781
260782
260783
260784
260785
260786
260787
260788
260789
260790
260791
260792
260793
260794
260795
260796
260797
260798
260799
260800
260801
260802
260803
260804
260805
260806
260807
260808
260809
260810
260811
260812
260813
260814
260815
260816
260817
260818
260819
260820
260821
260822
260823
260824
260825
260826
260827
260828
260829
260830
260831
260832
260833
260834
260835
260836
260837
260838
260839
260840
260841
260842
260843
260844
260845
260846
260847
260848
260849
260850
260851
260852
260853
260854
260855
260856
260857
260858
260859
260860
260861
260862
260863
260864
260865
260866
260867
260868
260869
260870
260871
260872
260873
260874
260875
260876
260877
260878
260879
260880
260881
260882
260883
260884
260885
260886
260887
260888
260889
260890
260891
260892
260893
260894
260895
260896
260897
260898
260899
260900
260901
260902
260903
260904
260905
260906
260907
260908
260909
260910
260911
260912
260913
260914
260915
260916
260917
260918
260919
260920
260921
260922
260923
260924
260925
260926
260927
260928
260929
260930
260931
260932
260933
260934
260935
260936
260937
260938
260939
260940
260941
260942
260943
260944
260945
260946
260947
260948
260949
260950
260951
260952
260953
260954
260955
260956
260957
260958
260959
260960
260961
260962
260963
260964
260965
260966
260967
260968
260969
260970
260971
260972
260973
260974
260975
260976
260977
260978
260979
260980
260981
260982
260983
260984
260985
260986
260987
260988
260989
260990
260991
260992
260993
260994
260995
260996
260997
260998
260999
261000
261001
261002
261003
261004
261005
261006
261007
261008
261009
261010
261011
261012
261013
261014
261015
261016
261017
261018
261019
261020
261021
261022
261023
261024
261025
261026
261027
261028
261029
261030
261031
261032
261033
261034
261035
261036
261037
261038
261039
261040
261041
261042
261043
261044
261045
261046
261047
261048
261049
261050
261051
261052
261053
261054
261055
261056
261057
261058
261059
261060
261061
261062
261063
261064
261065
261066
261067
261068
261069
261070
261071
261072
261073
261074
261075
261076
261077
261078
261079
261080
261081
261082
261083
261084
261085
261086
261087
261088
261089
261090
261091
261092
261093
261094
261095
261096
261097
261098
261099
261100
261101
261102
261103
261104
261105
261106
261107
261108
261109
261110
261111
261112
261113
261114
261115
261116
261117
261118
261119
261120
261121
261122
261123
261124
261125
261126
261127
261128
261129
261130
261131
261132
261133
261134
261135
261136
261137
261138
261139
261140
261141
261142
261143
261144
261145
261146
261147
261148
261149
261150
261151
261152
261153
261154
261155
261156
261157
261158
261159
261160
261161
261162
261163
261164
261165
261166
261167
261168
261169
261170
261171
261172
261173
261174
261175
261176
261177
261178
261179
261180
261181
261182
261183
261184
261185
261186
261187
261188
261189
261190
261191
261192
261193
261194
261195
261196
261197
261198
261199
261200
261201
261202
261203
261204
261205
261206
261207
261208
261209
261210
261211
261212
261213
261214
261215
261216
261217
261218
261219
261220
261221
261222
261223
261224
261225
261226
261227
261228
261229
261230
261231
261232
261233
261234
261235
261236
261237
261238
261239
261240
261241
261242
261243
261244
261245
261246
261247
261248
261249
261250
261251
261252
261253
261254
261255
261256
261257
261258
261259
261260
261261
261262
261263
261264
261265
261266
261267
261268
261269
261270
261271
261272
261273
261274
261275
261276
261277
261278
261279
261280
261281
261282
261283
261284
261285
261286
261287
261288
261289
261290
261291
261292
261293
261294
261295
261296
261297
261298
261299
261300
261301
261302
261303
261304
261305
261306
261307
261308
261309
261310
261311
261312
261313
261314
261315
261316
261317
261318
261319
261320
261321
261322
261323
261324
261325
261326
261327
261328
261329
261330
261331
261332
261333
261334
261335
261336
261337
261338
261339
261340
261341
261342
261343
261344
261345
261346
261347
261348
261349
261350
261351
261352
261353
261354
261355
261356
261357
261358
261359
261360
261361
261362
261363
261364
261365
261366
261367
261368
261369
261370
261371
261372
261373
261374
261375
261376
261377
261378
261379
261380
261381
261382
261383
261384
261385
261386
261387
261388
261389
261390
261391
261392
261393
261394
261395
261396
261397
261398
261399
261400
261401
261402
261403
261404
261405
261406
261407
261408
261409
261410
261411
261412
261413
261414
261415
261416
261417
261418
261419
261420
261421
261422
261423
261424
261425
261426
261427
261428
261429
261430
261431
261432
261433
261434
261435
261436
261437
261438
261439
261440
261441
261442
261443
261444
261445
261446
261447
261448
261449
261450
261451
261452
261453
261454
261455
261456
261457
261458
261459
261460
261461
261462
261463
261464
261465
261466
261467
261468
261469
261470
261471
261472
261473
261474
261475
261476
261477
261478
261479
261480
261481
261482
261483
261484
261485
261486
261487
261488
261489
261490
261491
261492
261493
261494
261495
261496
261497
261498
261499
261500
261501
261502
261503
261504
261505
261506
261507
261508
261509
261510
261511
261512
261513
261514
261515
261516
261517
261518
261519
261520
261521
261522
261523
261524
261525
261526
261527
261528
261529
261530
261531
261532
261533
261534
261535
261536
261537
261538
261539
261540
261541
261542
261543
261544
261545
261546
261547
261548
261549
261550
261551
261552
261553
261554
261555
261556
261557
261558
261559
261560
261561
261562
261563
261564
261565
261566
261567
261568
261569
261570
261571
261572
261573
261574
261575
261576
261577
261578
261579
261580
261581
261582
261583
261584
261585
261586
261587
261588
261589
261590
261591
261592
261593
261594
261595
261596
261597
261598
261599
261600
261601
261602
261603
261604
261605
261606
261607
261608
261609
261610
261611
261612
261613
261614
261615
261616
261617
261618
261619
261620
261621
261622
261623
261624
261625
261626
261627
261628
261629
261630
261631
261632
261633
261634
261635
261636
261637
261638
261639
261640
261641
261642
261643
261644
261645
261646
261647
261648
261649
261650
261651
261652
261653
261654
261655
261656
261657
261658
261659
261660
261661
261662
261663
261664
261665
261666
261667
261668
261669
261670
261671
261672
261673
261674
261675
261676
261677
261678
261679
261680
261681
261682
261683
261684
261685
261686
261687
261688
261689
261690
261691
261692
261693
261694
261695
261696
261697
261698
261699
261700
261701
261702
261703
261704
261705
261706
261707
261708
261709
261710
261711
261712
261713
261714
261715
261716
261717
261718
261719
261720
261721
261722
261723
261724
261725
261726
261727
261728
261729
261730
261731
261732
261733
261734
261735
261736
261737
261738
261739
261740
261741
261742
261743
261744
261745
261746
261747
261748
261749
261750
261751
261752
261753
261754
261755
261756
261757
261758
261759
261760
261761
261762
261763
261764
261765
261766
261767
261768
261769
261770
261771
261772
261773
261774
261775
261776
261777
261778
261779
261780
261781
261782
261783
261784
261785
261786
261787
261788
261789
261790
261791
261792
261793
261794
261795
261796
261797
261798
261799
261800
261801
261802
261803
261804
261805
261806
261807
261808
261809
261810
261811
261812
261813
261814
261815
261816
261817
261818
261819
261820
261821
261822
261823
261824
261825
261826
261827
261828
261829
261830
261831
261832
261833
261834
261835
261836
261837
261838
261839
261840
261841
261842
261843
261844
261845
261846
261847
261848
261849
261850
261851
261852
261853
261854
261855
261856
261857
261858
261859
261860
261861
261862
261863
261864
261865
261866
261867
261868
261869
261870
261871
261872
261873
261874
261875
261876
261877
261878
261879
261880
261881
261882
261883
261884
261885
261886
261887
261888
261889
261890
261891
261892
261893
261894
261895
261896
261897
261898
261899
261900
261901
261902
261903
261904
261905
261906
261907
261908
261909
261910
261911
261912
261913
261914
261915
261916
261917
261918
261919
261920
261921
261922
261923
261924
261925
261926
261927
261928
261929
261930
261931
261932
261933
261934
261935
261936
261937
261938
261939
261940
261941
261942
261943
261944
261945
261946
261947
261948
261949
261950
261951
261952
261953
261954
261955
261956
261957
261958
261959
261960
261961
261962
261963
261964
261965
261966
261967
261968
261969
261970
261971
261972
261973
261974
261975
261976
261977
261978
261979
261980
261981
261982
261983
261984
261985
261986
261987
261988
261989
261990
261991
261992
261993
261994
261995
261996
261997
261998
261999
262000
262001
262002
262003
262004
262005
262006
262007
262008
262009
262010
262011
262012
262013
262014
262015
262016
262017
262018
262019
262020
262021
262022
262023
262024
262025
262026
262027
262028
262029
262030
262031
262032
262033
262034
262035
262036
262037
262038
262039
262040
262041
262042
262043
262044
262045
262046
262047
262048
262049
262050
262051
262052
262053
262054
262055
262056
262057
262058
262059
262060
262061
262062
262063
262064
262065
262066
262067
262068
262069
262070
262071
262072
262073
262074
262075
262076
262077
262078
262079
262080
262081
262082
262083
262084
262085
262086
262087
262088
262089
262090
262091
262092
262093
262094
262095
262096
262097
262098
262099
262100
262101
262102
262103
262104
262105
262106
262107
262108
262109
262110
262111
262112
262113
262114
262115
262116
262117
262118
262119
262120
262121
262122
262123
262124
262125
262126
262127
262128
262129
262130
262131
262132
262133
262134
262135
262136
262137
262138
262139
262140
262141
262142
262143
262144
262145
262146
262147
262148
262149
262150
262151
262152
262153
262154
262155
262156
262157
262158
262159
262160
262161
262162
262163
262164
262165
262166
262167
262168
262169
262170
262171
262172
262173
262174
262175
262176
262177
262178
262179
262180
262181
262182
262183
262184
262185
262186
262187
262188
262189
262190
262191
262192
262193
262194
262195
262196
262197
262198
262199
262200
262201
262202
262203
262204
262205
262206
262207
262208
262209
262210
262211
262212
262213
262214
262215
262216
262217
262218
262219
262220
262221
262222
262223
262224
262225
262226
262227
262228
262229
262230
262231
262232
262233
262234
262235
262236
262237
262238
262239
262240
262241
262242
262243
262244
262245
262246
262247
262248
262249
262250
262251
262252
262253
262254
262255
262256
262257
262258
262259
262260
262261
262262
262263
262264
262265
262266
262267
262268
262269
262270
262271
262272
262273
262274
262275
262276
262277
262278
262279
262280
262281
262282
262283
262284
262285
262286
262287
262288
262289
262290
262291
262292
262293
262294
262295
262296
262297
262298
262299
262300
262301
262302
262303
262304
262305
262306
262307
262308
262309
262310
262311
262312
262313
262314
262315
262316
262317
262318
262319
262320
262321
262322
262323
262324
262325
262326
262327
262328
262329
262330
262331
262332
262333
262334
262335
262336
262337
262338
262339
262340
262341
262342
262343
262344
262345
262346
262347
262348
262349
262350
262351
262352
262353
262354
262355
262356
262357
262358
262359
262360
262361
262362
262363
262364
262365
262366
262367
262368
262369
262370
262371
262372
262373
262374
262375
262376
262377
262378
262379
262380
262381
262382
262383
262384
262385
262386
262387
262388
262389
262390
262391
262392
262393
262394
262395
262396
262397
262398
262399
262400
262401
262402
262403
262404
262405
262406
262407
262408
262409
262410
262411
262412
262413
262414
262415
262416
262417
262418
262419
262420
262421
262422
262423
262424
262425
262426
262427
262428
262429
262430
262431
262432
262433
262434
262435
262436
262437
262438
262439
262440
262441
262442
262443
262444
262445
262446
262447
262448
262449
262450
262451
262452
262453
262454
262455
262456
262457
262458
262459
262460
262461
262462
262463
262464
262465
262466
262467
262468
262469
262470
262471
262472
262473
262474
262475
262476
262477
262478
262479
262480
262481
262482
262483
262484
262485
262486
262487
262488
262489
262490
262491
262492
262493
262494
262495
262496
262497
262498
262499
262500
262501
262502
262503
262504
262505
262506
262507
262508
262509
262510
262511
262512
262513
262514
262515
262516
262517
262518
262519
262520
262521
262522
262523
262524
262525
262526
262527
262528
262529
262530
262531
262532
262533
262534
262535
262536
262537
262538
262539
262540
262541
262542
262543
262544
262545
262546
262547
262548
262549
262550
262551
262552
262553
262554
262555
262556
262557
262558
262559
262560
262561
262562
262563
262564
262565
262566
262567
262568
262569
262570
262571
262572
262573
262574
262575
262576
262577
262578
262579
262580
262581
262582
262583
262584
262585
262586
262587
262588
262589
262590
262591
262592
262593
262594
262595
262596
262597
262598
262599
262600
262601
262602
262603
262604
262605
262606
262607
262608
262609
262610
262611
262612
262613
262614
262615
262616
262617
262618
262619
262620
262621
262622
262623
262624
262625
262626
262627
262628
262629
262630
262631
262632
262633
262634
262635
262636
262637
262638
262639
262640
262641
262642
262643
262644
262645
262646
262647
262648
262649
262650
262651
262652
262653
262654
262655
262656
262657
262658
262659
262660
262661
262662
262663
262664
262665
262666
262667
262668
262669
262670
262671
262672
262673
262674
262675
262676
262677
262678
262679
262680
262681
262682
262683
262684
262685
262686
262687
262688
262689
262690
262691
262692
262693
262694
262695
262696
262697
262698
262699
262700
262701
262702
262703
262704
262705
262706
262707
262708
262709
262710
262711
262712
262713
262714
262715
262716
262717
262718
262719
262720
262721
262722
262723
262724
262725
262726
262727
262728
262729
262730
262731
262732
262733
262734
262735
262736
262737
262738
262739
262740
262741
262742
262743
262744
262745
262746
262747
262748
262749
262750
262751
262752
262753
262754
262755
262756
262757
262758
262759
262760
262761
262762
262763
262764
262765
262766
262767
262768
262769
262770
262771
262772
262773
262774
262775
262776
262777
262778
262779
262780
262781
262782
262783
262784
262785
262786
262787
262788
262789
262790
262791
262792
262793
262794
262795
262796
262797
262798
262799
262800
262801
262802
262803
262804
262805
262806
262807
262808
262809
262810
262811
262812
262813
262814
262815
262816
262817
262818
262819
262820
262821
262822
262823
262824
262825
262826
262827
262828
262829
262830
262831
262832
262833
262834
262835
262836
262837
262838
262839
262840
262841
262842
262843
262844
262845
262846
262847
262848
262849
262850
262851
262852
262853
262854
262855
262856
262857
262858
262859
262860
262861
262862
262863
262864
262865
262866
262867
262868
262869
262870
262871
262872
262873
262874
262875
262876
262877
262878
262879
262880
262881
262882
262883
262884
262885
262886
262887
262888
262889
262890
262891
262892
262893
262894
262895
262896
262897
262898
262899
262900
262901
262902
262903
262904
262905
262906
262907
262908
262909
262910
262911
262912
262913
262914
262915
262916
262917
262918
262919
262920
262921
262922
262923
262924
262925
262926
262927
262928
262929
262930
262931
262932
262933
262934
262935
262936
262937
262938
262939
262940
262941
262942
262943
262944
262945
262946
262947
262948
262949
262950
262951
262952
262953
262954
262955
262956
262957
262958
262959
262960
262961
262962
262963
262964
262965
262966
262967
262968
262969
262970
262971
262972
262973
262974
262975
262976
262977
262978
262979
262980
262981
262982
262983
262984
262985
262986
262987
262988
262989
262990
262991
262992
262993
262994
262995
262996
262997
262998
262999
263000
263001
263002
263003
263004
263005
263006
263007
263008
263009
263010
263011
263012
263013
263014
263015
263016
263017
263018
263019
263020
263021
263022
263023
263024
263025
263026
263027
263028
263029
263030
263031
263032
263033
263034
263035
263036
263037
263038
263039
263040
263041
263042
263043
263044
263045
263046
263047
263048
263049
263050
263051
263052
263053
263054
263055
263056
263057
263058
263059
263060
263061
263062
263063
263064
263065
263066
263067
263068
263069
263070
263071
263072
263073
263074
263075
263076
263077
263078
263079
263080
263081
263082
263083
263084
263085
263086
263087
263088
263089
263090
263091
263092
263093
263094
263095
263096
263097
263098
263099
263100
263101
263102
263103
263104
263105
263106
263107
263108
263109
263110
263111
263112
263113
263114
263115
263116
263117
263118
263119
263120
263121
263122
263123
263124
263125
263126
263127
263128
263129
263130
263131
263132
263133
263134
263135
263136
263137
263138
263139
263140
263141
263142
263143
263144
263145
263146
263147
263148
263149
263150
263151
263152
263153
263154
263155
263156
263157
263158
263159
263160
263161
263162
263163
263164
263165
263166
263167
263168
263169
263170
263171
263172
263173
263174
263175
263176
263177
263178
263179
263180
263181
263182
263183
263184
263185
263186
263187
263188
263189
263190
263191
263192
263193
263194
263195
263196
263197
263198
263199
263200
263201
263202
263203
263204
263205
263206
263207
263208
263209
263210
263211
263212
263213
263214
263215
263216
263217
263218
263219
263220
263221
263222
263223
263224
263225
263226
263227
263228
263229
263230
263231
263232
263233
263234
263235
263236
263237
263238
263239
263240
263241
263242
263243
263244
263245
263246
263247
263248
263249
263250
263251
263252
263253
263254
263255
263256
263257
263258
263259
263260
263261
263262
263263
263264
263265
263266
263267
263268
263269
263270
263271
263272
263273
263274
263275
263276
263277
263278
263279
263280
263281
263282
263283
263284
263285
263286
263287
263288
263289
263290
263291
263292
263293
263294
263295
263296
263297
263298
263299
263300
263301
263302
263303
263304
263305
263306
263307
263308
263309
263310
263311
263312
263313
263314
263315
263316
263317
263318
263319
263320
263321
263322
263323
263324
263325
263326
263327
263328
263329
263330
263331
263332
263333
263334
263335
263336
263337
263338
263339
263340
263341
263342
263343
263344
263345
263346
263347
263348
263349
263350
263351
263352
263353
263354
263355
263356
263357
263358
263359
263360
263361
263362
263363
263364
263365
263366
263367
263368
263369
263370
263371
263372
263373
263374
263375
263376
263377
263378
263379
263380
263381
263382
263383
263384
263385
263386
263387
263388
263389
263390
263391
263392
263393
263394
263395
263396
263397
263398
263399
263400
263401
263402
263403
263404
263405
263406
263407
263408
263409
263410
263411
263412
263413
263414
263415
263416
263417
263418
263419
263420
263421
263422
263423
263424
263425
263426
263427
263428
263429
263430
263431
263432
263433
263434
263435
263436
263437
263438
263439
263440
263441
263442
263443
263444
263445
263446
263447
263448
263449
263450
263451
263452
263453
263454
263455
263456
263457
263458
263459
263460
263461
263462
263463
263464
263465
263466
263467
263468
263469
263470
263471
263472
263473
263474
263475
263476
263477
263478
263479
263480
263481
263482
263483
263484
263485
263486
263487
263488
263489
263490
263491
263492
263493
263494
263495
263496
263497
263498
263499
263500
263501
263502
263503
263504
263505
263506
263507
263508
263509
263510
263511
263512
263513
263514
263515
263516
263517
263518
263519
263520
263521
263522
263523
263524
263525
263526
263527
263528
263529
263530
263531
263532
263533
263534
263535
263536
263537
263538
263539
263540
263541
263542
263543
263544
263545
263546
263547
263548
263549
263550
263551
263552
263553
263554
263555
263556
263557
263558
263559
263560
263561
263562
263563
263564
263565
263566
263567
263568
263569
263570
263571
263572
263573
263574
263575
263576
263577
263578
263579
263580
263581
263582
263583
263584
263585
263586
263587
263588
263589
263590
263591
263592
263593
263594
263595
263596
263597
263598
263599
263600
263601
263602
263603
263604
263605
263606
263607
263608
263609
263610
263611
263612
263613
263614
263615
263616
263617
263618
263619
263620
263621
263622
263623
263624
263625
263626
263627
263628
263629
263630
263631
263632
263633
263634
263635
263636
263637
263638
263639
263640
263641
263642
263643
263644
263645
263646
263647
263648
263649
263650
263651
263652
263653
263654
263655
263656
263657
263658
263659
263660
263661
263662
263663
263664
263665
263666
263667
263668
263669
263670
263671
263672
263673
263674
263675
263676
263677
263678
263679
263680
263681
263682
263683
263684
263685
263686
263687
263688
263689
263690
263691
263692
263693
263694
263695
263696
263697
263698
263699
263700
263701
263702
263703
263704
263705
263706
263707
263708
263709
263710
263711
263712
263713
263714
263715
263716
263717
263718
263719
263720
263721
263722
263723
263724
263725
263726
263727
263728
263729
263730
263731
263732
263733
263734
263735
263736
263737
263738
263739
263740
263741
263742
263743
263744
263745
263746
263747
263748
263749
263750
263751
263752
263753
263754
263755
263756
263757
263758
263759
263760
263761
263762
263763
263764
263765
263766
263767
263768
263769
263770
263771
263772
263773
263774
263775
263776
263777
263778
263779
263780
263781
263782
263783
263784
263785
263786
263787
263788
263789
263790
263791
263792
263793
263794
263795
263796
263797
263798
263799
263800
263801
263802
263803
263804
263805
263806
263807
263808
263809
263810
263811
263812
263813
263814
263815
263816
263817
263818
263819
263820
263821
263822
263823
263824
263825
263826
263827
263828
263829
263830
263831
263832
263833
263834
263835
263836
263837
263838
263839
263840
263841
263842
263843
263844
263845
263846
263847
263848
263849
263850
263851
263852
263853
263854
263855
263856
263857
263858
263859
263860
263861
263862
263863
263864
263865
263866
263867
263868
263869
263870
263871
263872
263873
263874
263875
263876
263877
263878
263879
263880
263881
263882
263883
263884
263885
263886
263887
263888
263889
263890
263891
263892
263893
263894
263895
263896
263897
263898
263899
263900
263901
263902
263903
263904
263905
263906
263907
263908
263909
263910
263911
263912
263913
263914
263915
263916
263917
263918
263919
263920
263921
263922
263923
263924
263925
263926
263927
263928
263929
263930
263931
263932
263933
263934
263935
263936
263937
263938
263939
263940
263941
263942
263943
263944
263945
263946
263947
263948
263949
263950
263951
263952
263953
263954
263955
263956
263957
263958
263959
263960
263961
263962
263963
263964
263965
263966
263967
263968
263969
263970
263971
263972
263973
263974
263975
263976
263977
263978
263979
263980
263981
263982
263983
263984
263985
263986
263987
263988
263989
263990
263991
263992
263993
263994
263995
263996
263997
263998
263999
264000
264001
264002
264003
264004
264005
264006
264007
264008
264009
264010
264011
264012
264013
264014
264015
264016
264017
264018
264019
264020
264021
264022
264023
264024
264025
264026
264027
264028
264029
264030
264031
264032
264033
264034
264035
264036
264037
264038
264039
264040
264041
264042
264043
264044
264045
264046
264047
264048
264049
264050
264051
264052
264053
264054
264055
264056
264057
264058
264059
264060
264061
264062
264063
264064
264065
264066
264067
264068
264069
264070
264071
264072
264073
264074
264075
264076
264077
264078
264079
264080
264081
264082
264083
264084
264085
264086
264087
264088
264089
264090
264091
264092
264093
264094
264095
264096
264097
264098
264099
264100
264101
264102
264103
264104
264105
264106
264107
264108
264109
264110
264111
264112
264113
264114
264115
264116
264117
264118
264119
264120
264121
264122
264123
264124
264125
264126
264127
264128
264129
264130
264131
264132
264133
264134
264135
264136
264137
264138
264139
264140
264141
264142
264143
264144
264145
264146
264147
264148
264149
264150
264151
264152
264153
264154
264155
264156
264157
264158
264159
264160
264161
264162
264163
264164
264165
264166
264167
264168
264169
264170
264171
264172
264173
264174
264175
264176
264177
264178
264179
264180
264181
264182
264183
264184
264185
264186
264187
264188
264189
264190
264191
264192
264193
264194
264195
264196
264197
264198
264199
264200
264201
264202
264203
264204
264205
264206
264207
264208
264209
264210
264211
264212
264213
264214
264215
264216
264217
264218
264219
264220
264221
264222
264223
264224
264225
264226
264227
264228
264229
264230
264231
264232
264233
264234
264235
264236
264237
264238
264239
264240
264241
264242
264243
264244
264245
264246
264247
264248
264249
264250
264251
264252
264253
264254
264255
264256
264257
264258
264259
264260
264261
264262
264263
264264
264265
264266
264267
264268
264269
264270
264271
264272
264273
264274
264275
264276
264277
264278
264279
264280
264281
264282
264283
264284
264285
264286
264287
264288
264289
264290
264291
264292
264293
264294
264295
264296
264297
264298
264299
264300
264301
264302
264303
264304
264305
264306
264307
264308
264309
264310
264311
264312
264313
264314
264315
264316
264317
264318
264319
264320
264321
264322
264323
264324
264325
264326
264327
264328
264329
264330
264331
264332
264333
264334
264335
264336
264337
264338
264339
264340
264341
264342
264343
264344
264345
264346
264347
264348
264349
264350
264351
264352
264353
264354
264355
264356
264357
264358
264359
264360
264361
264362
264363
264364
264365
264366
264367
264368
264369
264370
264371
264372
264373
264374
264375
264376
264377
264378
264379
264380
264381
264382
264383
264384
264385
264386
264387
264388
264389
264390
264391
264392
264393
264394
264395
264396
264397
264398
264399
264400
264401
264402
264403
264404
264405
264406
264407
264408
264409
264410
264411
264412
264413
264414
264415
264416
264417
264418
264419
264420
264421
264422
264423
264424
264425
264426
264427
264428
264429
264430
264431
264432
264433
264434
264435
264436
264437
264438
264439
264440
264441
264442
264443
264444
264445
264446
264447
264448
264449
264450
264451
264452
264453
264454
264455
264456
264457
264458
264459
264460
264461
264462
264463
264464
264465
264466
264467
264468
264469
264470
264471
264472
264473
264474
264475
264476
264477
264478
264479
264480
264481
264482
264483
264484
264485
264486
264487
264488
264489
264490
264491
264492
264493
264494
264495
264496
264497
264498
264499
264500
264501
264502
264503
264504
264505
264506
264507
264508
264509
264510
264511
264512
264513
264514
264515
264516
264517
264518
264519
264520
264521
264522
264523
264524
264525
264526
264527
264528
264529
264530
264531
264532
264533
264534
264535
264536
264537
264538
264539
264540
264541
264542
264543
264544
264545
264546
264547
264548
264549
264550
264551
264552
264553
264554
264555
264556
264557
264558
264559
264560
264561
264562
264563
264564
264565
264566
264567
264568
264569
264570
264571
264572
264573
264574
264575
264576
264577
264578
264579
264580
264581
264582
264583
264584
264585
264586
264587
264588
264589
264590
264591
264592
264593
264594
264595
264596
264597
264598
264599
264600
264601
264602
264603
264604
264605
264606
264607
264608
264609
264610
264611
264612
264613
264614
264615
264616
264617
264618
264619
264620
264621
264622
264623
264624
264625
264626
264627
264628
264629
264630
264631
264632
264633
264634
264635
264636
264637
264638
264639
264640
264641
264642
264643
264644
264645
264646
264647
264648
264649
264650
264651
264652
264653
264654
264655
264656
264657
264658
264659
264660
264661
264662
264663
264664
264665
264666
264667
264668
264669
264670
264671
264672
264673
264674
264675
264676
264677
264678
264679
264680
264681
264682
264683
264684
264685
264686
264687
264688
264689
264690
264691
264692
264693
264694
264695
264696
264697
264698
264699
264700
264701
264702
264703
264704
264705
264706
264707
264708
264709
264710
264711
264712
264713
264714
264715
264716
264717
264718
264719
264720
264721
264722
264723
264724
264725
264726
264727
264728
264729
264730
264731
264732
264733
264734
264735
264736
264737
264738
264739
264740
264741
264742
264743
264744
264745
264746
264747
264748
264749
264750
264751
264752
264753
264754
264755
264756
264757
264758
264759
264760
264761
264762
264763
264764
264765
264766
264767
264768
264769
264770
264771
264772
264773
264774
264775
264776
264777
264778
264779
264780
264781
264782
264783
264784
264785
264786
264787
264788
264789
264790
264791
264792
264793
264794
264795
264796
264797
264798
264799
264800
264801
264802
264803
264804
264805
264806
264807
264808
264809
264810
264811
264812
264813
264814
264815
264816
264817
264818
264819
264820
264821
264822
264823
264824
264825
264826
264827
264828
264829
264830
264831
264832
264833
264834
264835
264836
264837
264838
264839
264840
264841
264842
264843
264844
264845
264846
264847
264848
264849
264850
264851
264852
264853
264854
264855
264856
264857
264858
264859
264860
264861
264862
264863
264864
264865
264866
264867
264868
264869
264870
264871
264872
264873
264874
264875
264876
264877
264878
264879
264880
264881
264882
264883
264884
264885
264886
264887
264888
264889
264890
264891
264892
264893
264894
264895
264896
264897
264898
264899
264900
264901
264902
264903
264904
264905
264906
264907
264908
264909
264910
264911
264912
264913
264914
264915
264916
264917
264918
264919
264920
264921
264922
264923
264924
264925
264926
264927
264928
264929
264930
264931
264932
264933
264934
264935
264936
264937
264938
264939
264940
264941
264942
264943
264944
264945
264946
264947
264948
264949
264950
264951
264952
264953
264954
264955
264956
264957
264958
264959
264960
264961
264962
264963
264964
264965
264966
264967
264968
264969
264970
264971
264972
264973
264974
264975
264976
264977
264978
264979
264980
264981
264982
264983
264984
264985
264986
264987
264988
264989
264990
264991
264992
264993
264994
264995
264996
264997
264998
264999
265000
265001
265002
265003
265004
265005
265006
265007
265008
265009
265010
265011
265012
265013
265014
265015
265016
265017
265018
265019
265020
265021
265022
265023
265024
265025
265026
265027
265028
265029
265030
265031
265032
265033
265034
265035
265036
265037
265038
265039
265040
265041
265042
265043
265044
265045
265046
265047
265048
265049
265050
265051
265052
265053
265054
265055
265056
265057
265058
265059
265060
265061
265062
265063
265064
265065
265066
265067
265068
265069
265070
265071
265072
265073
265074
265075
265076
265077
265078
265079
265080
265081
265082
265083
265084
265085
265086
265087
265088
265089
265090
265091
265092
265093
265094
265095
265096
265097
265098
265099
265100
265101
265102
265103
265104
265105
265106
265107
265108
265109
265110
265111
265112
265113
265114
265115
265116
265117
265118
265119
265120
265121
265122
265123
265124
265125
265126
265127
265128
265129
265130
265131
265132
265133
265134
265135
265136
265137
265138
265139
265140
265141
265142
265143
265144
265145
265146
265147
265148
265149
265150
265151
265152
265153
265154
265155
265156
265157
265158
265159
265160
265161
265162
265163
265164
265165
265166
265167
265168
265169
265170
265171
265172
265173
265174
265175
265176
265177
265178
265179
265180
265181
265182
265183
265184
265185
265186
265187
265188
265189
265190
265191
265192
265193
265194
265195
265196
265197
265198
265199
265200
265201
265202
265203
265204
265205
265206
265207
265208
265209
265210
265211
265212
265213
265214
265215
265216
265217
265218
265219
265220
265221
265222
265223
265224
265225
265226
265227
265228
265229
265230
265231
265232
265233
265234
265235
265236
265237
265238
265239
265240
265241
265242
265243
265244
265245
265246
265247
265248
265249
265250
265251
265252
265253
265254
265255
265256
265257
265258
265259
265260
265261
265262
265263
265264
265265
265266
265267
265268
265269
265270
265271
265272
265273
265274
265275
265276
265277
265278
265279
265280
265281
265282
265283
265284
265285
265286
265287
265288
265289
265290
265291
265292
265293
265294
265295
265296
265297
265298
265299
265300
265301
265302
265303
265304
265305
265306
265307
265308
265309
265310
265311
265312
265313
265314
265315
265316
265317
265318
265319
265320
265321
265322
265323
265324
265325
265326
265327
265328
265329
265330
265331
265332
265333
265334
265335
265336
265337
265338
265339
265340
265341
265342
265343
265344
265345
265346
265347
265348
265349
265350
265351
265352
265353
265354
265355
265356
265357
265358
265359
265360
265361
265362
265363
265364
265365
265366
265367
265368
265369
265370
265371
265372
265373
265374
265375
265376
265377
265378
265379
265380
265381
265382
265383
265384
265385
265386
265387
265388
265389
265390
265391
265392
265393
265394
265395
265396
265397
265398
265399
265400
265401
265402
265403
265404
265405
265406
265407
265408
265409
265410
265411
265412
265413
265414
265415
265416
265417
265418
265419
265420
265421
265422
265423
265424
265425
265426
265427
265428
265429
265430
265431
265432
265433
265434
265435
265436
265437
265438
265439
265440
265441
265442
265443
265444
265445
265446
265447
265448
265449
265450
265451
265452
265453
265454
265455
265456
265457
265458
265459
265460
265461
265462
265463
265464
265465
265466
265467
265468
265469
265470
265471
265472
265473
265474
265475
265476
265477
265478
265479
265480
265481
265482
265483
265484
265485
265486
265487
265488
265489
265490
265491
265492
265493
265494
265495
265496
265497
265498
265499
265500
265501
265502
265503
265504
265505
265506
265507
265508
265509
265510
265511
265512
265513
265514
265515
265516
265517
265518
265519
265520
265521
265522
265523
265524
265525
265526
265527
265528
265529
265530
265531
265532
265533
265534
265535
265536
265537
265538
265539
265540
265541
265542
265543
265544
265545
265546
265547
265548
265549
265550
265551
265552
265553
265554
265555
265556
265557
265558
265559
265560
265561
265562
265563
265564
265565
265566
265567
265568
265569
265570
265571
265572
265573
265574
265575
265576
265577
265578
265579
265580
265581
265582
265583
265584
265585
265586
265587
265588
265589
265590
265591
265592
265593
265594
265595
265596
265597
265598
265599
265600
265601
265602
265603
265604
265605
265606
265607
265608
265609
265610
265611
265612
265613
265614
265615
265616
265617
265618
265619
265620
265621
265622
265623
265624
265625
265626
265627
265628
265629
265630
265631
265632
265633
265634
265635
265636
265637
265638
265639
265640
265641
265642
265643
265644
265645
265646
265647
265648
265649
265650
265651
265652
265653
265654
265655
265656
265657
265658
265659
265660
265661
265662
265663
265664
265665
265666
265667
265668
265669
265670
265671
265672
265673
265674
265675
265676
265677
265678
265679
265680
265681
265682
265683
265684
265685
265686
265687
265688
265689
265690
265691
265692
265693
265694
265695
265696
265697
265698
265699
265700
265701
265702
265703
265704
265705
265706
265707
265708
265709
265710
265711
265712
265713
265714
265715
265716
265717
265718
265719
265720
265721
265722
265723
265724
265725
265726
265727
265728
265729
265730
265731
265732
265733
265734
265735
265736
265737
265738
265739
265740
265741
265742
265743
265744
265745
265746
265747
265748
265749
265750
265751
265752
265753
265754
265755
265756
265757
265758
265759
265760
265761
265762
265763
265764
265765
265766
265767
265768
265769
265770
265771
265772
265773
265774
265775
265776
265777
265778
265779
265780
265781
265782
265783
265784
265785
265786
265787
265788
265789
265790
265791
265792
265793
265794
265795
265796
265797
265798
265799
265800
265801
265802
265803
265804
265805
265806
265807
265808
265809
265810
265811
265812
265813
265814
265815
265816
265817
265818
265819
265820
265821
265822
265823
265824
265825
265826
265827
265828
265829
265830
265831
265832
265833
265834
265835
265836
265837
265838
265839
265840
265841
265842
265843
265844
265845
265846
265847
265848
265849
265850
265851
265852
265853
265854
265855
265856
265857
265858
265859
265860
265861
265862
265863
265864
265865
265866
265867
265868
265869
265870
265871
265872
265873
265874
265875
265876
265877
265878
265879
265880
265881
265882
265883
265884
265885
265886
265887
265888
265889
265890
265891
265892
265893
265894
265895
265896
265897
265898
265899
265900
265901
265902
265903
265904
265905
265906
265907
265908
265909
265910
265911
265912
265913
265914
265915
265916
265917
265918
265919
265920
265921
265922
265923
265924
265925
265926
265927
265928
265929
265930
265931
265932
265933
265934
265935
265936
265937
265938
265939
265940
265941
265942
265943
265944
265945
265946
265947
265948
265949
265950
265951
265952
265953
265954
265955
265956
265957
265958
265959
265960
265961
265962
265963
265964
265965
265966
265967
265968
265969
265970
265971
265972
265973
265974
265975
265976
265977
265978
265979
265980
265981
265982
265983
265984
265985
265986
265987
265988
265989
265990
265991
265992
265993
265994
265995
265996
265997
265998
265999
266000
266001
266002
266003
266004
266005
266006
266007
266008
266009
266010
266011
266012
266013
266014
266015
266016
266017
266018
266019
266020
266021
266022
266023
266024
266025
266026
266027
266028
266029
266030
266031
266032
266033
266034
266035
266036
266037
266038
266039
266040
266041
266042
266043
266044
266045
266046
266047
266048
266049
266050
266051
266052
266053
266054
266055
266056
266057
266058
266059
266060
266061
266062
266063
266064
266065
266066
266067
266068
266069
266070
266071
266072
266073
266074
266075
266076
266077
266078
266079
266080
266081
266082
266083
266084
266085
266086
266087
266088
266089
266090
266091
266092
266093
266094
266095
266096
266097
266098
266099
266100
266101
266102
266103
266104
266105
266106
266107
266108
266109
266110
266111
266112
266113
266114
266115
266116
266117
266118
266119
266120
266121
266122
266123
266124
266125
266126
266127
266128
266129
266130
266131
266132
266133
266134
266135
266136
266137
266138
266139
266140
266141
266142
266143
266144
266145
266146
266147
266148
266149
266150
266151
266152
266153
266154
266155
266156
266157
266158
266159
266160
266161
266162
266163
266164
266165
266166
266167
266168
266169
266170
266171
266172
266173
266174
266175
266176
266177
266178
266179
266180
266181
266182
266183
266184
266185
266186
266187
266188
266189
266190
266191
266192
266193
266194
266195
266196
266197
266198
266199
266200
266201
266202
266203
266204
266205
266206
266207
266208
266209
266210
266211
266212
266213
266214
266215
266216
266217
266218
266219
266220
266221
266222
266223
266224
266225
266226
266227
266228
266229
266230
266231
266232
266233
266234
266235
266236
266237
266238
266239
266240
266241
266242
266243
266244
266245
266246
266247
266248
266249
266250
266251
266252
266253
266254
266255
266256
266257
266258
266259
266260
266261
266262
266263
266264
266265
266266
266267
266268
266269
266270
266271
266272
266273
266274
266275
266276
266277
266278
266279
266280
266281
266282
266283
266284
266285
266286
266287
266288
266289
266290
266291
266292
266293
266294
266295
266296
266297
266298
266299
266300
266301
266302
266303
266304
266305
266306
266307
266308
266309
266310
266311
266312
266313
266314
266315
266316
266317
266318
266319
266320
266321
266322
266323
266324
266325
266326
266327
266328
266329
266330
266331
266332
266333
266334
266335
266336
266337
266338
266339
266340
266341
266342
266343
266344
266345
266346
266347
266348
266349
266350
266351
266352
266353
266354
266355
266356
266357
266358
266359
266360
266361
266362
266363
266364
266365
266366
266367
266368
266369
266370
266371
266372
266373
266374
266375
266376
266377
266378
266379
266380
266381
266382
266383
266384
266385
266386
266387
266388
266389
266390
266391
266392
266393
266394
266395
266396
266397
266398
266399
266400
266401
266402
266403
266404
266405
266406
266407
266408
266409
266410
266411
266412
266413
266414
266415
266416
266417
266418
266419
266420
266421
266422
266423
266424
266425
266426
266427
266428
266429
266430
266431
266432
266433
266434
266435
266436
266437
266438
266439
266440
266441
266442
266443
266444
266445
266446
266447
266448
266449
266450
266451
266452
266453
266454
266455
266456
266457
266458
266459
266460
266461
266462
266463
266464
266465
266466
266467
266468
266469
266470
266471
266472
266473
266474
266475
266476
266477
266478
266479
266480
266481
266482
266483
266484
266485
266486
266487
266488
266489
266490
266491
266492
266493
266494
266495
266496
266497
266498
266499
266500
266501
266502
266503
266504
266505
266506
266507
266508
266509
266510
266511
266512
266513
266514
266515
266516
266517
266518
266519
266520
266521
266522
266523
266524
266525
266526
266527
266528
266529
266530
266531
266532
266533
266534
266535
266536
266537
266538
266539
266540
266541
266542
266543
266544
266545
266546
266547
266548
266549
266550
266551
266552
266553
266554
266555
266556
266557
266558
266559
266560
266561
266562
266563
266564
266565
266566
266567
266568
266569
266570
266571
266572
266573
266574
266575
266576
266577
266578
266579
266580
266581
266582
266583
266584
266585
266586
266587
266588
266589
266590
266591
266592
266593
266594
266595
266596
266597
266598
266599
266600
266601
266602
266603
266604
266605
266606
266607
266608
266609
266610
266611
266612
266613
266614
266615
266616
266617
266618
266619
266620
266621
266622
266623
266624
266625
266626
266627
266628
266629
266630
266631
266632
266633
266634
266635
266636
266637
266638
266639
266640
266641
266642
266643
266644
266645
266646
266647
266648
266649
266650
266651
266652
266653
266654
266655
266656
266657
266658
266659
266660
266661
266662
266663
266664
266665
266666
266667
266668
266669
266670
266671
266672
266673
266674
266675
266676
266677
266678
266679
266680
266681
266682
266683
266684
266685
266686
266687
266688
266689
266690
266691
266692
266693
266694
266695
266696
266697
266698
266699
266700
266701
266702
266703
266704
266705
266706
266707
266708
266709
266710
266711
266712
266713
266714
266715
266716
266717
266718
266719
266720
266721
266722
266723
266724
266725
266726
266727
266728
266729
266730
266731
266732
266733
266734
266735
266736
266737
266738
266739
266740
266741
266742
266743
266744
266745
266746
266747
266748
266749
266750
266751
266752
266753
266754
266755
266756
266757
266758
266759
266760
266761
266762
266763
266764
266765
266766
266767
266768
266769
266770
266771
266772
266773
266774
266775
266776
266777
266778
266779
266780
266781
266782
266783
266784
266785
266786
266787
266788
266789
266790
266791
266792
266793
266794
266795
266796
266797
266798
266799
266800
266801
266802
266803
266804
266805
266806
266807
266808
266809
266810
266811
266812
266813
266814
266815
266816
266817
266818
266819
266820
266821
266822
266823
266824
266825
266826
266827
266828
266829
266830
266831
266832
266833
266834
266835
266836
266837
266838
266839
266840
266841
266842
266843
266844
266845
266846
266847
266848
266849
266850
266851
266852
266853
266854
266855
266856
266857
266858
266859
266860
266861
266862
266863
266864
266865
266866
266867
266868
266869
266870
266871
266872
266873
266874
266875
266876
266877
266878
266879
266880
266881
266882
266883
266884
266885
266886
266887
266888
266889
266890
266891
266892
266893
266894
266895
266896
266897
266898
266899
266900
266901
266902
266903
266904
266905
266906
266907
266908
266909
266910
266911
266912
266913
266914
266915
266916
266917
266918
266919
266920
266921
266922
266923
266924
266925
266926
266927
266928
266929
266930
266931
266932
266933
266934
266935
266936
266937
266938
266939
266940
266941
266942
266943
266944
266945
266946
266947
266948
266949
266950
266951
266952
266953
266954
266955
266956
266957
266958
266959
266960
266961
266962
266963
266964
266965
266966
266967
266968
266969
266970
266971
266972
266973
266974
266975
266976
266977
266978
266979
266980
266981
266982
266983
266984
266985
266986
266987
266988
266989
266990
266991
266992
266993
266994
266995
266996
266997
266998
266999
267000
267001
267002
267003
267004
267005
267006
267007
267008
267009
267010
267011
267012
267013
267014
267015
267016
267017
267018
267019
267020
267021
267022
267023
267024
267025
267026
267027
267028
267029
267030
267031
267032
267033
267034
267035
267036
267037
267038
267039
267040
267041
267042
267043
267044
267045
267046
267047
267048
267049
267050
267051
267052
267053
267054
267055
267056
267057
267058
267059
267060
267061
267062
267063
267064
267065
267066
267067
267068
267069
267070
267071
267072
267073
267074
267075
267076
267077
267078
267079
267080
267081
267082
267083
267084
267085
267086
267087
267088
267089
267090
267091
267092
267093
267094
267095
267096
267097
267098
267099
267100
267101
267102
267103
267104
267105
267106
267107
267108
267109
267110
267111
267112
267113
267114
267115
267116
267117
267118
267119
267120
267121
267122
267123
267124
267125
267126
267127
267128
267129
267130
267131
267132
267133
267134
267135
267136
267137
267138
267139
267140
267141
267142
267143
267144
267145
267146
267147
267148
267149
267150
267151
267152
267153
267154
267155
267156
267157
267158
267159
267160
267161
267162
267163
267164
267165
267166
267167
267168
267169
267170
267171
267172
267173
267174
267175
267176
267177
267178
267179
267180
267181
267182
267183
267184
267185
267186
267187
267188
267189
267190
267191
267192
267193
267194
267195
267196
267197
267198
267199
267200
267201
267202
267203
267204
267205
267206
267207
267208
267209
267210
267211
267212
267213
267214
267215
267216
267217
267218
267219
267220
267221
267222
267223
267224
267225
267226
267227
267228
267229
267230
267231
267232
267233
267234
267235
267236
267237
267238
267239
267240
267241
267242
267243
267244
267245
267246
267247
267248
267249
267250
267251
267252
267253
267254
267255
267256
267257
267258
267259
267260
267261
267262
267263
267264
267265
267266
267267
267268
267269
267270
267271
267272
267273
267274
267275
267276
267277
267278
267279
267280
267281
267282
267283
267284
267285
267286
267287
267288
267289
267290
267291
267292
267293
267294
267295
267296
267297
267298
267299
267300
267301
267302
267303
267304
267305
267306
267307
267308
267309
267310
267311
267312
267313
267314
267315
267316
267317
267318
267319
267320
267321
267322
267323
267324
267325
267326
267327
267328
267329
267330
267331
267332
267333
267334
267335
267336
267337
267338
267339
267340
267341
267342
267343
267344
267345
267346
267347
267348
267349
267350
267351
267352
267353
267354
267355
267356
267357
267358
267359
267360
267361
267362
267363
267364
267365
267366
267367
267368
267369
267370
267371
267372
267373
267374
267375
267376
267377
267378
267379
267380
267381
267382
267383
267384
267385
267386
267387
267388
267389
267390
267391
267392
267393
267394
267395
267396
267397
267398
267399
267400
267401
267402
267403
267404
267405
267406
267407
267408
267409
267410
267411
267412
267413
267414
267415
267416
267417
267418
267419
267420
267421
267422
267423
267424
267425
267426
267427
267428
267429
267430
267431
267432
267433
267434
267435
267436
267437
267438
267439
267440
267441
267442
267443
267444
267445
267446
267447
267448
267449
267450
267451
267452
267453
267454
267455
267456
267457
267458
267459
267460
267461
267462
267463
267464
267465
267466
267467
267468
267469
267470
267471
267472
267473
267474
267475
267476
267477
267478
267479
267480
267481
267482
267483
267484
267485
267486
267487
267488
267489
267490
267491
267492
267493
267494
267495
267496
267497
267498
267499
267500
267501
267502
267503
267504
267505
267506
267507
267508
267509
267510
267511
267512
267513
267514
267515
267516
267517
267518
267519
267520
267521
267522
267523
267524
267525
267526
267527
267528
267529
267530
267531
267532
267533
267534
267535
267536
267537
267538
267539
267540
267541
267542
267543
267544
267545
267546
267547
267548
267549
267550
267551
267552
267553
267554
267555
267556
267557
267558
267559
267560
267561
267562
267563
267564
267565
267566
267567
267568
267569
267570
267571
267572
267573
267574
267575
267576
267577
267578
267579
267580
267581
267582
267583
267584
267585
267586
267587
267588
267589
267590
267591
267592
267593
267594
267595
267596
267597
267598
267599
267600
267601
267602
267603
267604
267605
267606
267607
267608
267609
267610
267611
267612
267613
267614
267615
267616
267617
267618
267619
267620
267621
267622
267623
267624
267625
267626
267627
267628
267629
267630
267631
267632
267633
267634
267635
267636
267637
267638
267639
267640
267641
267642
267643
267644
267645
267646
267647
267648
267649
267650
267651
267652
267653
267654
267655
267656
267657
267658
267659
267660
267661
267662
267663
267664
267665
267666
267667
267668
267669
267670
267671
267672
267673
267674
267675
267676
267677
267678
267679
267680
267681
267682
267683
267684
267685
267686
267687
267688
267689
267690
267691
267692
267693
267694
267695
267696
267697
267698
267699
267700
267701
267702
267703
267704
267705
267706
267707
267708
267709
267710
267711
267712
267713
267714
267715
267716
267717
267718
267719
267720
267721
267722
267723
267724
267725
267726
267727
267728
267729
267730
267731
267732
267733
267734
267735
267736
267737
267738
267739
267740
267741
267742
267743
267744
267745
267746
267747
267748
267749
267750
267751
267752
267753
267754
267755
267756
267757
267758
267759
267760
267761
267762
267763
267764
267765
267766
267767
267768
267769
267770
267771
267772
267773
267774
267775
267776
267777
267778
267779
267780
267781
267782
267783
267784
267785
267786
267787
267788
267789
267790
267791
267792
267793
267794
267795
267796
267797
267798
267799
267800
267801
267802
267803
267804
267805
267806
267807
267808
267809
267810
267811
267812
267813
267814
267815
267816
267817
267818
267819
267820
267821
267822
267823
267824
267825
267826
267827
267828
267829
267830
267831
267832
267833
267834
267835
267836
267837
267838
267839
267840
267841
267842
267843
267844
267845
267846
267847
267848
267849
267850
267851
267852
267853
267854
267855
267856
267857
267858
267859
267860
267861
267862
267863
267864
267865
267866
267867
267868
267869
267870
267871
267872
267873
267874
267875
267876
267877
267878
267879
267880
267881
267882
267883
267884
267885
267886
267887
267888
267889
267890
267891
267892
267893
267894
267895
267896
267897
267898
267899
267900
267901
267902
267903
267904
267905
267906
267907
267908
267909
267910
267911
267912
267913
267914
267915
267916
267917
267918
267919
267920
267921
267922
267923
267924
267925
267926
267927
267928
267929
267930
267931
267932
267933
267934
267935
267936
267937
267938
267939
267940
267941
267942
267943
267944
267945
267946
267947
267948
267949
267950
267951
267952
267953
267954
267955
267956
267957
267958
267959
267960
267961
267962
267963
267964
267965
267966
267967
267968
267969
267970
267971
267972
267973
267974
267975
267976
267977
267978
267979
267980
267981
267982
267983
267984
267985
267986
267987
267988
267989
267990
267991
267992
267993
267994
267995
267996
267997
267998
267999
268000
268001
268002
268003
268004
268005
268006
268007
268008
268009
268010
268011
268012
268013
268014
268015
268016
268017
268018
268019
268020
268021
268022
268023
268024
268025
268026
268027
268028
268029
268030
268031
268032
268033
268034
268035
268036
268037
268038
268039
268040
268041
268042
268043
268044
268045
268046
268047
268048
268049
268050
268051
268052
268053
268054
268055
268056
268057
268058
268059
268060
268061
268062
268063
268064
268065
268066
268067
268068
268069
268070
268071
268072
268073
268074
268075
268076
268077
268078
268079
268080
268081
268082
268083
268084
268085
268086
268087
268088
268089
268090
268091
268092
268093
268094
268095
268096
268097
268098
268099
268100
268101
268102
268103
268104
268105
268106
268107
268108
268109
268110
268111
268112
268113
268114
268115
268116
268117
268118
268119
268120
268121
268122
268123
268124
268125
268126
268127
268128
268129
268130
268131
268132
268133
268134
268135
268136
268137
268138
268139
268140
268141
268142
268143
268144
268145
268146
268147
268148
268149
268150
268151
268152
268153
268154
268155
268156
268157
268158
268159
268160
268161
268162
268163
268164
268165
268166
268167
268168
268169
268170
268171
268172
268173
268174
268175
268176
268177
268178
268179
268180
268181
268182
268183
268184
268185
268186
268187
268188
268189
268190
268191
268192
268193
268194
268195
268196
268197
268198
268199
268200
268201
268202
268203
268204
268205
268206
268207
268208
268209
268210
268211
268212
268213
268214
268215
268216
268217
268218
268219
268220
268221
268222
268223
268224
268225
268226
268227
268228
268229
268230
268231
268232
268233
268234
268235
268236
268237
268238
268239
268240
268241
268242
268243
268244
268245
268246
268247
268248
268249
268250
268251
268252
268253
268254
268255
268256
268257
268258
268259
268260
268261
268262
268263
268264
268265
268266
268267
268268
268269
268270
268271
268272
268273
268274
268275
268276
268277
268278
268279
268280
268281
268282
268283
268284
268285
268286
268287
268288
268289
268290
268291
268292
268293
268294
268295
268296
268297
268298
268299
268300
268301
268302
268303
268304
268305
268306
268307
268308
268309
268310
268311
268312
268313
268314
268315
268316
268317
268318
268319
268320
268321
268322
268323
268324
268325
268326
268327
268328
268329
268330
268331
268332
268333
268334
268335
268336
268337
268338
268339
268340
268341
268342
268343
268344
268345
268346
268347
268348
268349
268350
268351
268352
268353
268354
268355
268356
268357
268358
268359
268360
268361
268362
268363
268364
268365
268366
268367
268368
268369
268370
268371
268372
268373
268374
268375
268376
268377
268378
268379
268380
268381
268382
268383
268384
268385
268386
268387
268388
268389
268390
268391
268392
268393
268394
268395
268396
268397
268398
268399
268400
268401
268402
268403
268404
268405
268406
268407
268408
268409
268410
268411
268412
268413
268414
268415
268416
268417
268418
268419
268420
268421
268422
268423
268424
268425
268426
268427
268428
268429
268430
268431
268432
268433
268434
268435
268436
268437
268438
268439
268440
268441
268442
268443
268444
268445
268446
268447
268448
268449
268450
268451
268452
268453
268454
268455
268456
268457
268458
268459
268460
268461
268462
268463
268464
268465
268466
268467
268468
268469
268470
268471
268472
268473
268474
268475
268476
268477
268478
268479
268480
268481
268482
268483
268484
268485
268486
268487
268488
268489
268490
268491
268492
268493
268494
268495
268496
268497
268498
268499
268500
268501
268502
268503
268504
268505
268506
268507
268508
268509
268510
268511
268512
268513
268514
268515
268516
268517
268518
268519
268520
268521
268522
268523
268524
268525
268526
268527
268528
268529
268530
268531
268532
268533
268534
268535
268536
268537
268538
268539
268540
268541
268542
268543
268544
268545
268546
268547
268548
268549
268550
268551
268552
268553
268554
268555
268556
268557
268558
268559
268560
268561
268562
268563
268564
268565
268566
268567
268568
268569
268570
268571
268572
268573
268574
268575
268576
268577
268578
268579
268580
268581
268582
268583
268584
268585
268586
268587
268588
268589
268590
268591
268592
268593
268594
268595
268596
268597
268598
268599
268600
268601
268602
268603
268604
268605
268606
268607
268608
268609
268610
268611
268612
268613
268614
268615
268616
268617
268618
268619
268620
268621
268622
268623
268624
268625
268626
268627
268628
268629
268630
268631
268632
268633
268634
268635
268636
268637
268638
268639
268640
268641
268642
268643
268644
268645
268646
268647
268648
268649
268650
268651
268652
268653
268654
268655
268656
268657
268658
268659
268660
268661
268662
268663
268664
268665
268666
268667
268668
268669
268670
268671
268672
268673
268674
268675
268676
268677
268678
268679
268680
268681
268682
268683
268684
268685
268686
268687
268688
268689
268690
268691
268692
268693
268694
268695
268696
268697
268698
268699
268700
268701
268702
268703
268704
268705
268706
268707
268708
268709
268710
268711
268712
268713
268714
268715
268716
268717
268718
268719
268720
268721
268722
268723
268724
268725
268726
268727
268728
268729
268730
268731
268732
268733
268734
268735
268736
268737
268738
268739
268740
268741
268742
268743
268744
268745
268746
268747
268748
268749
268750
268751
268752
268753
268754
268755
268756
268757
268758
268759
268760
268761
268762
268763
268764
268765
268766
268767
268768
268769
268770
268771
268772
268773
268774
268775
268776
268777
268778
268779
268780
268781
268782
268783
268784
268785
268786
268787
268788
268789
268790
268791
268792
268793
268794
268795
268796
268797
268798
268799
268800
268801
268802
268803
268804
268805
268806
268807
268808
268809
268810
268811
268812
268813
268814
268815
268816
268817
268818
268819
268820
268821
268822
268823
268824
268825
268826
268827
268828
268829
268830
268831
268832
268833
268834
268835
268836
268837
268838
268839
268840
268841
268842
268843
268844
268845
268846
268847
268848
268849
268850
268851
268852
268853
268854
268855
268856
268857
268858
268859
268860
268861
268862
268863
268864
268865
268866
268867
268868
268869
268870
268871
268872
268873
268874
268875
268876
268877
268878
268879
268880
268881
268882
268883
268884
268885
268886
268887
268888
268889
268890
268891
268892
268893
268894
268895
268896
268897
268898
268899
268900
268901
268902
268903
268904
268905
268906
268907
268908
268909
268910
268911
268912
268913
268914
268915
268916
268917
268918
268919
268920
268921
268922
268923
268924
268925
268926
268927
268928
268929
268930
268931
268932
268933
268934
268935
268936
268937
268938
268939
268940
268941
268942
268943
268944
268945
268946
268947
268948
268949
268950
268951
268952
268953
268954
268955
268956
268957
268958
268959
268960
268961
268962
268963
268964
268965
268966
268967
268968
268969
268970
268971
268972
268973
268974
268975
268976
268977
268978
268979
268980
268981
268982
268983
268984
268985
268986
268987
268988
268989
268990
268991
268992
268993
268994
268995
268996
268997
268998
268999
269000
269001
269002
269003
269004
269005
269006
269007
269008
269009
269010
269011
269012
269013
269014
269015
269016
269017
269018
269019
269020
269021
269022
269023
269024
269025
269026
269027
269028
269029
269030
269031
269032
269033
269034
269035
269036
269037
269038
269039
269040
269041
269042
269043
269044
269045
269046
269047
269048
269049
269050
269051
269052
269053
269054
269055
269056
269057
269058
269059
269060
269061
269062
269063
269064
269065
269066
269067
269068
269069
269070
269071
269072
269073
269074
269075
269076
269077
269078
269079
269080
269081
269082
269083
269084
269085
269086
269087
269088
269089
269090
269091
269092
269093
269094
269095
269096
269097
269098
269099
269100
269101
269102
269103
269104
269105
269106
269107
269108
269109
269110
269111
269112
269113
269114
269115
269116
269117
269118
269119
269120
269121
269122
269123
269124
269125
269126
269127
269128
269129
269130
269131
269132
269133
269134
269135
269136
269137
269138
269139
269140
269141
269142
269143
269144
269145
269146
269147
269148
269149
269150
269151
269152
269153
269154
269155
269156
269157
269158
269159
269160
269161
269162
269163
269164
269165
269166
269167
269168
269169
269170
269171
269172
269173
269174
269175
269176
269177
269178
269179
269180
269181
269182
269183
269184
269185
269186
269187
269188
269189
269190
269191
269192
269193
269194
269195
269196
269197
269198
269199
269200
269201
269202
269203
269204
269205
269206
269207
269208
269209
269210
269211
269212
269213
269214
269215
269216
269217
269218
269219
269220
269221
269222
269223
269224
269225
269226
269227
269228
269229
269230
269231
269232
269233
269234
269235
269236
269237
269238
269239
269240
269241
269242
269243
269244
269245
269246
269247
269248
269249
269250
269251
269252
269253
269254
269255
269256
269257
269258
269259
269260
269261
269262
269263
269264
269265
269266
269267
269268
269269
269270
269271
269272
269273
269274
269275
269276
269277
269278
269279
269280
269281
269282
269283
269284
269285
269286
269287
269288
269289
269290
269291
269292
269293
269294
269295
269296
269297
269298
269299
269300
269301
269302
269303
269304
269305
269306
269307
269308
269309
269310
269311
269312
269313
269314
269315
269316
269317
269318
269319
269320
269321
269322
269323
269324
269325
269326
269327
269328
269329
269330
269331
269332
269333
269334
269335
269336
269337
269338
269339
269340
269341
269342
269343
269344
269345
269346
269347
269348
269349
269350
269351
269352
269353
269354
269355
269356
269357
269358
269359
269360
269361
269362
269363
269364
269365
269366
269367
269368
269369
269370
269371
269372
269373
269374
269375
269376
269377
269378
269379
269380
269381
269382
269383
269384
269385
269386
269387
269388
269389
269390
269391
269392
269393
269394
269395
269396
269397
269398
269399
269400
269401
269402
269403
269404
269405
269406
269407
269408
269409
269410
269411
269412
269413
269414
269415
269416
269417
269418
269419
269420
269421
269422
269423
269424
269425
269426
269427
269428
269429
269430
269431
269432
269433
269434
269435
269436
269437
269438
269439
269440
269441
269442
269443
269444
269445
269446
269447
269448
269449
269450
269451
269452
269453
269454
269455
269456
269457
269458
269459
269460
269461
269462
269463
269464
269465
269466
269467
269468
269469
269470
269471
269472
269473
269474
269475
269476
269477
269478
269479
269480
269481
269482
269483
269484
269485
269486
269487
269488
269489
269490
269491
269492
269493
269494
269495
269496
269497
269498
269499
269500
269501
269502
269503
269504
269505
269506
269507
269508
269509
269510
269511
269512
269513
269514
269515
269516
269517
269518
269519
269520
269521
269522
269523
269524
269525
269526
269527
269528
269529
269530
269531
269532
269533
269534
269535
269536
269537
269538
269539
269540
269541
269542
269543
269544
269545
269546
269547
269548
269549
269550
269551
269552
269553
269554
269555
269556
269557
269558
269559
269560
269561
269562
269563
269564
269565
269566
269567
269568
269569
269570
269571
269572
269573
269574
269575
269576
269577
269578
269579
269580
269581
269582
269583
269584
269585
269586
269587
269588
269589
269590
269591
269592
269593
269594
269595
269596
269597
269598
269599
269600
269601
269602
269603
269604
269605
269606
269607
269608
269609
269610
269611
269612
269613
269614
269615
269616
269617
269618
269619
269620
269621
269622
269623
269624
269625
269626
269627
269628
269629
269630
269631
269632
269633
269634
269635
269636
269637
269638
269639
269640
269641
269642
269643
269644
269645
269646
269647
269648
269649
269650
269651
269652
269653
269654
269655
269656
269657
269658
269659
269660
269661
269662
269663
269664
269665
269666
269667
269668
269669
269670
269671
269672
269673
269674
269675
269676
269677
269678
269679
269680
269681
269682
269683
269684
269685
269686
269687
269688
269689
269690
269691
269692
269693
269694
269695
269696
269697
269698
269699
269700
269701
269702
269703
269704
269705
269706
269707
269708
269709
269710
269711
269712
269713
269714
269715
269716
269717
269718
269719
269720
269721
269722
269723
269724
269725
269726
269727
269728
269729
269730
269731
269732
269733
269734
269735
269736
269737
269738
269739
269740
269741
269742
269743
269744
269745
269746
269747
269748
269749
269750
269751
269752
269753
269754
269755
269756
269757
269758
269759
269760
269761
269762
269763
269764
269765
269766
269767
269768
269769
269770
269771
269772
269773
269774
269775
269776
269777
269778
269779
269780
269781
269782
269783
269784
269785
269786
269787
269788
269789
269790
269791
269792
269793
269794
269795
269796
269797
269798
269799
269800
269801
269802
269803
269804
269805
269806
269807
269808
269809
269810
269811
269812
269813
269814
269815
269816
269817
269818
269819
269820
269821
269822
269823
269824
269825
269826
269827
269828
269829
269830
269831
269832
269833
269834
269835
269836
269837
269838
269839
269840
269841
269842
269843
269844
269845
269846
269847
269848
269849
269850
269851
269852
269853
269854
269855
269856
269857
269858
269859
269860
269861
269862
269863
269864
269865
269866
269867
269868
269869
269870
269871
269872
269873
269874
269875
269876
269877
269878
269879
269880
269881
269882
269883
269884
269885
269886
269887
269888
269889
269890
269891
269892
269893
269894
269895
269896
269897
269898
269899
269900
269901
269902
269903
269904
269905
269906
269907
269908
269909
269910
269911
269912
269913
269914
269915
269916
269917
269918
269919
269920
269921
269922
269923
269924
269925
269926
269927
269928
269929
269930
269931
269932
269933
269934
269935
269936
269937
269938
269939
269940
269941
269942
269943
269944
269945
269946
269947
269948
269949
269950
269951
269952
269953
269954
269955
269956
269957
269958
269959
269960
269961
269962
269963
269964
269965
269966
269967
269968
269969
269970
269971
269972
269973
269974
269975
269976
269977
269978
269979
269980
269981
269982
269983
269984
269985
269986
269987
269988
269989
269990
269991
269992
269993
269994
269995
269996
269997
269998
269999
270000
270001
270002
270003
270004
270005
270006
270007
270008
270009
270010
270011
270012
270013
270014
270015
270016
270017
270018
270019
270020
270021
270022
270023
270024
270025
270026
270027
270028
270029
270030
270031
270032
270033
270034
270035
270036
270037
270038
270039
270040
270041
270042
270043
270044
270045
270046
270047
270048
270049
270050
270051
270052
270053
270054
270055
270056
270057
270058
270059
270060
270061
270062
270063
270064
270065
270066
270067
270068
270069
270070
270071
270072
270073
270074
270075
270076
270077
270078
270079
270080
270081
270082
270083
270084
270085
270086
270087
270088
270089
270090
270091
270092
270093
270094
270095
270096
270097
270098
270099
270100
270101
270102
270103
270104
270105
270106
270107
270108
270109
270110
270111
270112
270113
270114
270115
270116
270117
270118
270119
270120
270121
270122
270123
270124
270125
270126
270127
270128
270129
270130
270131
270132
270133
270134
270135
270136
270137
270138
270139
270140
270141
270142
270143
270144
270145
270146
270147
270148
270149
270150
270151
270152
270153
270154
270155
270156
270157
270158
270159
270160
270161
270162
270163
270164
270165
270166
270167
270168
270169
270170
270171
270172
270173
270174
270175
270176
270177
270178
270179
270180
270181
270182
270183
270184
270185
270186
270187
270188
270189
270190
270191
270192
270193
270194
270195
270196
270197
270198
270199
270200
270201
270202
270203
270204
270205
270206
270207
270208
270209
270210
270211
270212
270213
270214
270215
270216
270217
270218
270219
270220
270221
270222
270223
270224
270225
270226
270227
270228
270229
270230
270231
270232
270233
270234
270235
270236
270237
270238
270239
270240
270241
270242
270243
270244
270245
270246
270247
270248
270249
270250
270251
270252
270253
270254
270255
270256
270257
270258
270259
270260
270261
270262
270263
270264
270265
270266
270267
270268
270269
270270
270271
270272
270273
270274
270275
270276
270277
270278
270279
270280
270281
270282
270283
270284
270285
270286
270287
270288
270289
270290
270291
270292
270293
270294
270295
270296
270297
270298
270299
270300
270301
270302
270303
270304
270305
270306
270307
270308
270309
270310
270311
270312
270313
270314
270315
270316
270317
270318
270319
270320
270321
270322
270323
270324
270325
270326
270327
270328
270329
270330
270331
270332
270333
270334
270335
270336
270337
270338
270339
270340
270341
270342
270343
270344
270345
270346
270347
270348
270349
270350
270351
270352
270353
270354
270355
270356
270357
270358
270359
270360
270361
270362
270363
270364
270365
270366
270367
270368
270369
270370
270371
270372
270373
270374
270375
270376
270377
270378
270379
270380
270381
270382
270383
270384
270385
270386
270387
270388
270389
270390
270391
270392
270393
270394
270395
270396
270397
270398
270399
270400
270401
270402
270403
270404
270405
270406
270407
270408
270409
270410
270411
270412
270413
270414
270415
270416
270417
270418
270419
270420
270421
270422
270423
270424
270425
270426
270427
270428
270429
270430
270431
270432
270433
270434
270435
270436
270437
270438
270439
270440
270441
270442
270443
270444
270445
270446
270447
270448
270449
270450
270451
270452
270453
270454
270455
270456
270457
270458
270459
270460
270461
270462
270463
270464
270465
270466
270467
270468
270469
270470
270471
270472
270473
270474
270475
270476
270477
270478
270479
270480
270481
270482
270483
270484
270485
270486
270487
270488
270489
270490
270491
270492
270493
270494
270495
270496
270497
270498
270499
270500
270501
270502
270503
270504
270505
270506
270507
270508
270509
270510
270511
270512
270513
270514
270515
270516
270517
270518
270519
270520
270521
270522
270523
270524
270525
270526
270527
270528
270529
270530
270531
270532
270533
270534
270535
270536
270537
270538
270539
270540
270541
270542
270543
270544
270545
270546
270547
270548
270549
270550
270551
270552
270553
270554
270555
270556
270557
270558
270559
270560
270561
270562
270563
270564
270565
270566
270567
270568
270569
270570
270571
270572
270573
270574
270575
270576
270577
270578
270579
270580
270581
270582
270583
270584
270585
270586
270587
270588
270589
270590
270591
270592
270593
270594
270595
270596
270597
270598
270599
270600
270601
270602
270603
270604
270605
270606
270607
270608
270609
270610
270611
270612
270613
270614
270615
270616
270617
270618
270619
270620
270621
270622
270623
270624
270625
270626
270627
270628
270629
270630
270631
270632
270633
270634
270635
270636
270637
270638
270639
270640
270641
270642
270643
270644
270645
270646
270647
270648
270649
270650
270651
270652
270653
270654
270655
270656
270657
270658
270659
270660
270661
270662
270663
270664
270665
270666
270667
270668
270669
270670
270671
270672
270673
270674
270675
270676
270677
270678
270679
270680
270681
270682
270683
270684
270685
270686
270687
270688
270689
270690
270691
270692
270693
270694
270695
270696
270697
270698
270699
270700
270701
270702
270703
270704
270705
270706
270707
270708
270709
270710
270711
270712
270713
270714
270715
270716
270717
270718
270719
270720
270721
270722
270723
270724
270725
270726
270727
270728
270729
270730
270731
270732
270733
270734
270735
270736
270737
270738
270739
270740
270741
270742
270743
270744
270745
270746
270747
270748
270749
270750
270751
270752
270753
270754
270755
270756
270757
270758
270759
270760
270761
270762
270763
270764
270765
270766
270767
270768
270769
270770
270771
270772
270773
270774
270775
270776
270777
270778
270779
270780
270781
270782
270783
270784
270785
270786
270787
270788
270789
270790
270791
270792
270793
270794
270795
270796
270797
270798
270799
270800
270801
270802
270803
270804
270805
270806
270807
270808
270809
270810
270811
270812
270813
270814
270815
270816
270817
270818
270819
270820
270821
270822
270823
270824
270825
270826
270827
270828
270829
270830
270831
270832
270833
270834
270835
270836
270837
270838
270839
270840
270841
270842
270843
270844
270845
270846
270847
270848
270849
270850
270851
270852
270853
270854
270855
270856
270857
270858
270859
270860
270861
270862
270863
270864
270865
270866
270867
270868
270869
270870
270871
270872
270873
270874
270875
270876
270877
270878
270879
270880
270881
270882
270883
270884
270885
270886
270887
270888
270889
270890
270891
270892
270893
270894
270895
270896
270897
270898
270899
270900
270901
270902
270903
270904
270905
270906
270907
270908
270909
270910
270911
270912
270913
270914
270915
270916
270917
270918
270919
270920
270921
270922
270923
270924
270925
270926
270927
270928
270929
270930
270931
270932
270933
270934
270935
270936
270937
270938
270939
270940
270941
270942
270943
270944
270945
270946
270947
270948
270949
270950
270951
270952
270953
270954
270955
270956
270957
270958
270959
270960
270961
270962
270963
270964
270965
270966
270967
270968
270969
270970
270971
270972
270973
270974
270975
270976
270977
270978
270979
270980
270981
270982
270983
270984
270985
270986
270987
270988
270989
270990
270991
270992
270993
270994
270995
270996
270997
270998
270999
271000
271001
271002
271003
271004
271005
271006
271007
271008
271009
271010
271011
271012
271013
271014
271015
271016
271017
271018
271019
271020
271021
271022
271023
271024
271025
271026
271027
271028
271029
271030
271031
271032
271033
271034
271035
271036
271037
271038
271039
271040
271041
271042
271043
271044
271045
271046
271047
271048
271049
271050
271051
271052
271053
271054
271055
271056
271057
271058
271059
271060
271061
271062
271063
271064
271065
271066
271067
271068
271069
271070
271071
271072
271073
271074
271075
271076
271077
271078
271079
271080
271081
271082
271083
271084
271085
271086
271087
271088
271089
271090
271091
271092
271093
271094
271095
271096
271097
271098
271099
271100
271101
271102
271103
271104
271105
271106
271107
271108
271109
271110
271111
271112
271113
271114
271115
271116
271117
271118
271119
271120
271121
271122
271123
271124
271125
271126
271127
271128
271129
271130
271131
271132
271133
271134
271135
271136
271137
271138
271139
271140
271141
271142
271143
271144
271145
271146
271147
271148
271149
271150
271151
271152
271153
271154
271155
271156
271157
271158
271159
271160
271161
271162
271163
271164
271165
271166
271167
271168
271169
271170
271171
271172
271173
271174
271175
271176
271177
271178
271179
271180
271181
271182
271183
271184
271185
271186
271187
271188
271189
271190
271191
271192
271193
271194
271195
271196
271197
271198
271199
271200
271201
271202
271203
271204
271205
271206
271207
271208
271209
271210
271211
271212
271213
271214
271215
271216
271217
271218
271219
271220
271221
271222
271223
271224
271225
271226
271227
271228
271229
271230
271231
271232
271233
271234
271235
271236
271237
271238
271239
271240
271241
271242
271243
271244
271245
271246
271247
271248
271249
271250
271251
271252
271253
271254
271255
271256
271257
271258
271259
271260
271261
271262
271263
271264
271265
271266
271267
271268
271269
271270
271271
271272
271273
271274
271275
271276
271277
271278
271279
271280
271281
271282
271283
271284
271285
271286
271287
271288
271289
271290
271291
271292
271293
271294
271295
271296
271297
271298
271299
271300
271301
271302
271303
271304
271305
271306
271307
271308
271309
271310
271311
271312
271313
271314
271315
271316
271317
271318
271319
271320
271321
271322
271323
271324
271325
271326
271327
271328
271329
271330
271331
271332
271333
271334
271335
271336
271337
271338
271339
271340
271341
271342
271343
271344
271345
271346
271347
271348
271349
271350
271351
271352
271353
271354
271355
271356
271357
271358
271359
271360
271361
271362
271363
271364
271365
271366
271367
271368
271369
271370
271371
271372
271373
271374
271375
271376
271377
271378
271379
271380
271381
271382
271383
271384
271385
271386
271387
271388
271389
271390
271391
271392
271393
271394
271395
271396
271397
271398
271399
271400
271401
271402
271403
271404
271405
271406
271407
271408
271409
271410
271411
271412
271413
271414
271415
271416
271417
271418
271419
271420
271421
271422
271423
271424
271425
271426
271427
271428
271429
271430
271431
271432
271433
271434
271435
271436
271437
271438
271439
271440
271441
271442
271443
271444
271445
271446
271447
271448
271449
271450
271451
271452
271453
271454
271455
271456
271457
271458
271459
271460
271461
271462
271463
271464
271465
271466
271467
271468
271469
271470
271471
271472
271473
271474
271475
271476
271477
271478
271479
271480
271481
271482
271483
271484
271485
271486
271487
271488
271489
271490
271491
271492
271493
271494
271495
271496
271497
271498
271499
271500
271501
271502
271503
271504
271505
271506
271507
271508
271509
271510
271511
271512
271513
271514
271515
271516
271517
271518
271519
271520
271521
271522
271523
271524
271525
271526
271527
271528
271529
271530
271531
271532
271533
271534
271535
271536
271537
271538
271539
271540
271541
271542
271543
271544
271545
271546
271547
271548
271549
271550
271551
271552
271553
271554
271555
271556
271557
271558
271559
271560
271561
271562
271563
271564
271565
271566
271567
271568
271569
271570
271571
271572
271573
271574
271575
271576
271577
271578
271579
271580
271581
271582
271583
271584
271585
271586
271587
271588
271589
271590
271591
271592
271593
271594
271595
271596
271597
271598
271599
271600
271601
271602
271603
271604
271605
271606
271607
271608
271609
271610
271611
271612
271613
271614
271615
271616
271617
271618
271619
271620
271621
271622
271623
271624
271625
271626
271627
271628
271629
271630
271631
271632
271633
271634
271635
271636
271637
271638
271639
271640
271641
271642
271643
271644
271645
271646
271647
271648
271649
271650
271651
271652
271653
271654
271655
271656
271657
271658
271659
271660
271661
271662
271663
271664
271665
271666
271667
271668
271669
271670
271671
271672
271673
271674
271675
271676
271677
271678
271679
271680
271681
271682
271683
271684
271685
271686
271687
271688
271689
271690
271691
271692
271693
271694
271695
271696
271697
271698
271699
271700
271701
271702
271703
271704
271705
271706
271707
271708
271709
271710
271711
271712
271713
271714
271715
271716
271717
271718
271719
271720
271721
271722
271723
271724
271725
271726
271727
271728
271729
271730
271731
271732
271733
271734
271735
271736
271737
271738
271739
271740
271741
271742
271743
271744
271745
271746
271747
271748
271749
271750
271751
271752
271753
271754
271755
271756
271757
271758
271759
271760
271761
271762
271763
271764
271765
271766
271767
271768
271769
271770
271771
271772
271773
271774
271775
271776
271777
271778
271779
271780
271781
271782
271783
271784
271785
271786
271787
271788
271789
271790
271791
271792
271793
271794
271795
271796
271797
271798
271799
271800
271801
271802
271803
271804
271805
271806
271807
271808
271809
271810
271811
271812
271813
271814
271815
271816
271817
271818
271819
271820
271821
271822
271823
271824
271825
271826
271827
271828
271829
271830
271831
271832
271833
271834
271835
271836
271837
271838
271839
271840
271841
271842
271843
271844
271845
271846
271847
271848
271849
271850
271851
271852
271853
271854
271855
271856
271857
271858
271859
271860
271861
271862
271863
271864
271865
271866
271867
271868
271869
271870
271871
271872
271873
271874
271875
271876
271877
271878
271879
271880
271881
271882
271883
271884
271885
271886
271887
271888
271889
271890
271891
271892
271893
271894
271895
271896
271897
271898
271899
271900
271901
271902
271903
271904
271905
271906
271907
271908
271909
271910
271911
271912
271913
271914
271915
271916
271917
271918
271919
271920
271921
271922
271923
271924
271925
271926
271927
271928
271929
271930
271931
271932
271933
271934
271935
271936
271937
271938
271939
271940
271941
271942
271943
271944
271945
271946
271947
271948
271949
271950
271951
271952
271953
271954
271955
271956
271957
271958
271959
271960
271961
271962
271963
271964
271965
271966
271967
271968
271969
271970
271971
271972
271973
271974
271975
271976
271977
271978
271979
271980
271981
271982
271983
271984
271985
271986
271987
271988
271989
271990
271991
271992
271993
271994
271995
271996
271997
271998
271999
272000
272001
272002
272003
272004
272005
272006
272007
272008
272009
272010
272011
272012
272013
272014
272015
272016
272017
272018
272019
272020
272021
272022
272023
272024
272025
272026
272027
272028
272029
272030
272031
272032
272033
272034
272035
272036
272037
272038
272039
272040
272041
272042
272043
272044
272045
272046
272047
272048
272049
272050
272051
272052
272053
272054
272055
272056
272057
272058
272059
272060
272061
272062
272063
272064
272065
272066
272067
272068
272069
272070
272071
272072
272073
272074
272075
272076
272077
272078
272079
272080
272081
272082
272083
272084
272085
272086
272087
272088
272089
272090
272091
272092
272093
272094
272095
272096
272097
272098
272099
272100
272101
272102
272103
272104
272105
272106
272107
272108
272109
272110
272111
272112
272113
272114
272115
272116
272117
272118
272119
272120
272121
272122
272123
272124
272125
272126
272127
272128
272129
272130
272131
272132
272133
272134
272135
272136
272137
272138
272139
272140
272141
272142
272143
272144
272145
272146
272147
272148
272149
272150
272151
272152
272153
272154
272155
272156
272157
272158
272159
272160
272161
272162
272163
272164
272165
272166
272167
272168
272169
272170
272171
272172
272173
272174
272175
272176
272177
272178
272179
272180
272181
272182
272183
272184
272185
272186
272187
272188
272189
272190
272191
272192
272193
272194
272195
272196
272197
272198
272199
272200
272201
272202
272203
272204
272205
272206
272207
272208
272209
272210
272211
272212
272213
272214
272215
272216
272217
272218
272219
272220
272221
272222
272223
272224
272225
272226
272227
272228
272229
272230
272231
272232
272233
272234
272235
272236
272237
272238
272239
272240
272241
272242
272243
272244
272245
272246
272247
272248
272249
272250
272251
272252
272253
272254
272255
272256
272257
272258
272259
272260
272261
272262
272263
272264
272265
272266
272267
272268
272269
272270
272271
272272
272273
272274
272275
272276
272277
272278
272279
272280
272281
272282
272283
272284
272285
272286
272287
272288
272289
272290
272291
272292
272293
272294
272295
272296
272297
272298
272299
272300
272301
272302
272303
272304
272305
272306
272307
272308
272309
272310
272311
272312
272313
272314
272315
272316
272317
272318
272319
272320
272321
272322
272323
272324
272325
272326
272327
272328
272329
272330
272331
272332
272333
272334
272335
272336
272337
272338
272339
272340
272341
272342
272343
272344
272345
272346
272347
272348
272349
272350
272351
272352
272353
272354
272355
272356
272357
272358
272359
272360
272361
272362
272363
272364
272365
272366
272367
272368
272369
272370
272371
272372
272373
272374
272375
272376
272377
272378
272379
272380
272381
272382
272383
272384
272385
272386
272387
272388
272389
272390
272391
272392
272393
272394
272395
272396
272397
272398
272399
272400
272401
272402
272403
272404
272405
272406
272407
272408
272409
272410
272411
272412
272413
272414
272415
272416
272417
272418
272419
272420
272421
272422
272423
272424
272425
272426
272427
272428
272429
272430
272431
272432
272433
272434
272435
272436
272437
272438
272439
272440
272441
272442
272443
272444
272445
272446
272447
272448
272449
272450
272451
272452
272453
272454
272455
272456
272457
272458
272459
272460
272461
272462
272463
272464
272465
272466
272467
272468
272469
272470
272471
272472
272473
272474
272475
272476
272477
272478
272479
272480
272481
272482
272483
272484
272485
272486
272487
272488
272489
272490
272491
272492
272493
272494
272495
272496
272497
272498
272499
272500
272501
272502
272503
272504
272505
272506
272507
272508
272509
272510
272511
272512
272513
272514
272515
272516
272517
272518
272519
272520
272521
272522
272523
272524
272525
272526
272527
272528
272529
272530
272531
272532
272533
272534
272535
272536
272537
272538
272539
272540
272541
272542
272543
272544
272545
272546
272547
272548
272549
272550
272551
272552
272553
272554
272555
272556
272557
272558
272559
272560
272561
272562
272563
272564
272565
272566
272567
272568
272569
272570
272571
272572
272573
272574
272575
272576
272577
272578
272579
272580
272581
272582
272583
272584
272585
272586
272587
272588
272589
272590
272591
272592
272593
272594
272595
272596
272597
272598
272599
272600
272601
272602
272603
272604
272605
272606
272607
272608
272609
272610
272611
272612
272613
272614
272615
272616
272617
272618
272619
272620
272621
272622
272623
272624
272625
272626
272627
272628
272629
272630
272631
272632
272633
272634
272635
272636
272637
272638
272639
272640
272641
272642
272643
272644
272645
272646
272647
272648
272649
272650
272651
272652
272653
272654
272655
272656
272657
272658
272659
272660
272661
272662
272663
272664
272665
272666
272667
272668
272669
272670
272671
272672
272673
272674
272675
272676
272677
272678
272679
272680
272681
272682
272683
272684
272685
272686
272687
272688
272689
272690
272691
272692
272693
272694
272695
272696
272697
272698
272699
272700
272701
272702
272703
272704
272705
272706
272707
272708
272709
272710
272711
272712
272713
272714
272715
272716
272717
272718
272719
272720
272721
272722
272723
272724
272725
272726
272727
272728
272729
272730
272731
272732
272733
272734
272735
272736
272737
272738
272739
272740
272741
272742
272743
272744
272745
272746
272747
272748
272749
272750
272751
272752
272753
272754
272755
272756
272757
272758
272759
272760
272761
272762
272763
272764
272765
272766
272767
272768
272769
272770
272771
272772
272773
272774
272775
272776
272777
272778
272779
272780
272781
272782
272783
272784
272785
272786
272787
272788
272789
272790
272791
272792
272793
272794
272795
272796
272797
272798
272799
272800
272801
272802
272803
272804
272805
272806
272807
272808
272809
272810
272811
272812
272813
272814
272815
272816
272817
272818
272819
272820
272821
272822
272823
272824
272825
272826
272827
272828
272829
272830
272831
272832
272833
272834
272835
272836
272837
272838
272839
272840
272841
272842
272843
272844
272845
272846
272847
272848
272849
272850
272851
272852
272853
272854
272855
272856
272857
272858
272859
272860
272861
272862
272863
272864
272865
272866
272867
272868
272869
272870
272871
272872
272873
272874
272875
272876
272877
272878
272879
272880
272881
272882
272883
272884
272885
272886
272887
272888
272889
272890
272891
272892
272893
272894
272895
272896
272897
272898
272899
272900
272901
272902
272903
272904
272905
272906
272907
272908
272909
272910
272911
272912
272913
272914
272915
272916
272917
272918
272919
272920
272921
272922
272923
272924
272925
272926
272927
272928
272929
272930
272931
272932
272933
272934
272935
272936
272937
272938
272939
272940
272941
272942
272943
272944
272945
272946
272947
272948
272949
272950
272951
272952
272953
272954
272955
272956
272957
272958
272959
272960
272961
272962
272963
272964
272965
272966
272967
272968
272969
272970
272971
272972
272973
272974
272975
272976
272977
272978
272979
272980
272981
272982
272983
272984
272985
272986
272987
272988
272989
272990
272991
272992
272993
272994
272995
272996
272997
272998
272999
273000
273001
273002
273003
273004
273005
273006
273007
273008
273009
273010
273011
273012
273013
273014
273015
273016
273017
273018
273019
273020
273021
273022
273023
273024
273025
273026
273027
273028
273029
273030
273031
273032
273033
273034
273035
273036
273037
273038
273039
273040
273041
273042
273043
273044
273045
273046
273047
273048
273049
273050
273051
273052
273053
273054
273055
273056
273057
273058
273059
273060
273061
273062
273063
273064
273065
273066
273067
273068
273069
273070
273071
273072
273073
273074
273075
273076
273077
273078
273079
273080
273081
273082
273083
273084
273085
273086
273087
273088
273089
273090
273091
273092
273093
273094
273095
273096
273097
273098
273099
273100
273101
273102
273103
273104
273105
273106
273107
273108
273109
273110
273111
273112
273113
273114
273115
273116
273117
273118
273119
273120
273121
273122
273123
273124
273125
273126
273127
273128
273129
273130
273131
273132
273133
273134
273135
273136
273137
273138
273139
273140
273141
273142
273143
273144
273145
273146
273147
273148
273149
273150
273151
273152
273153
273154
273155
273156
273157
273158
273159
273160
273161
273162
273163
273164
273165
273166
273167
273168
273169
273170
273171
273172
273173
273174
273175
273176
273177
273178
273179
273180
273181
273182
273183
273184
273185
273186
273187
273188
273189
273190
273191
273192
273193
273194
273195
273196
273197
273198
273199
273200
273201
273202
273203
273204
273205
273206
273207
273208
273209
273210
273211
273212
273213
273214
273215
273216
273217
273218
273219
273220
273221
273222
273223
273224
273225
273226
273227
273228
273229
273230
273231
273232
273233
273234
273235
273236
273237
273238
273239
273240
273241
273242
273243
273244
273245
273246
273247
273248
273249
273250
273251
273252
273253
273254
273255
273256
273257
273258
273259
273260
273261
273262
273263
273264
273265
273266
273267
273268
273269
273270
273271
273272
273273
273274
273275
273276
273277
273278
273279
273280
273281
273282
273283
273284
273285
273286
273287
273288
273289
273290
273291
273292
273293
273294
273295
273296
273297
273298
273299
273300
273301
273302
273303
273304
273305
273306
273307
273308
273309
273310
273311
273312
273313
273314
273315
273316
273317
273318
273319
273320
273321
273322
273323
273324
273325
273326
273327
273328
273329
273330
273331
273332
273333
273334
273335
273336
273337
273338
273339
273340
273341
273342
273343
273344
273345
273346
273347
273348
273349
273350
273351
273352
273353
273354
273355
273356
273357
273358
273359
273360
273361
273362
273363
273364
273365
273366
273367
273368
273369
273370
273371
273372
273373
273374
273375
273376
273377
273378
273379
273380
273381
273382
273383
273384
273385
273386
273387
273388
273389
273390
273391
273392
273393
273394
273395
273396
273397
273398
273399
273400
273401
273402
273403
273404
273405
273406
273407
273408
273409
273410
273411
273412
273413
273414
273415
273416
273417
273418
273419
273420
273421
273422
273423
273424
273425
273426
273427
273428
273429
273430
273431
273432
273433
273434
273435
273436
273437
273438
273439
273440
273441
273442
273443
273444
273445
273446
273447
273448
273449
273450
273451
273452
273453
273454
273455
273456
273457
273458
273459
273460
273461
273462
273463
273464
273465
273466
273467
273468
273469
273470
273471
273472
273473
273474
273475
273476
273477
273478
273479
273480
273481
273482
273483
273484
273485
273486
273487
273488
273489
273490
273491
273492
273493
273494
273495
273496
273497
273498
273499
273500
273501
273502
273503
273504
273505
273506
273507
273508
273509
273510
273511
273512
273513
273514
273515
273516
273517
273518
273519
273520
273521
273522
273523
273524
273525
273526
273527
273528
273529
273530
273531
273532
273533
273534
273535
273536
273537
273538
273539
273540
273541
273542
273543
273544
273545
273546
273547
273548
273549
273550
273551
273552
273553
273554
273555
273556
273557
273558
273559
273560
273561
273562
273563
273564
273565
273566
273567
273568
273569
273570
273571
273572
273573
273574
273575
273576
273577
273578
273579
273580
273581
273582
273583
273584
273585
273586
273587
273588
273589
273590
273591
273592
273593
273594
273595
273596
273597
273598
273599
273600
273601
273602
273603
273604
273605
273606
273607
273608
273609
273610
273611
273612
273613
273614
273615
273616
273617
273618
273619
273620
273621
273622
273623
273624
273625
273626
273627
273628
273629
273630
273631
273632
273633
273634
273635
273636
273637
273638
273639
273640
273641
273642
273643
273644
273645
273646
273647
273648
273649
273650
273651
273652
273653
273654
273655
273656
273657
273658
273659
273660
273661
273662
273663
273664
273665
273666
273667
273668
273669
273670
273671
273672
273673
273674
273675
273676
273677
273678
273679
273680
273681
273682
273683
273684
273685
273686
273687
273688
273689
273690
273691
273692
273693
273694
273695
273696
273697
273698
273699
273700
273701
273702
273703
273704
273705
273706
273707
273708
273709
273710
273711
273712
273713
273714
273715
273716
273717
273718
273719
273720
273721
273722
273723
273724
273725
273726
273727
273728
273729
273730
273731
273732
273733
273734
273735
273736
273737
273738
273739
273740
273741
273742
273743
273744
273745
273746
273747
273748
273749
273750
273751
273752
273753
273754
273755
273756
273757
273758
273759
273760
273761
273762
273763
273764
273765
273766
273767
273768
273769
273770
273771
273772
273773
273774
273775
273776
273777
273778
273779
273780
273781
273782
273783
273784
273785
273786
273787
273788
273789
273790
273791
273792
273793
273794
273795
273796
273797
273798
273799
273800
273801
273802
273803
273804
273805
273806
273807
273808
273809
273810
273811
273812
273813
273814
273815
273816
273817
273818
273819
273820
273821
273822
273823
273824
273825
273826
273827
273828
273829
273830
273831
273832
273833
273834
273835
273836
273837
273838
273839
273840
273841
273842
273843
273844
273845
273846
273847
273848
273849
273850
273851
273852
273853
273854
273855
273856
273857
273858
273859
273860
273861
273862
273863
273864
273865
273866
273867
273868
273869
273870
273871
273872
273873
273874
273875
273876
273877
273878
273879
273880
273881
273882
273883
273884
273885
273886
273887
273888
273889
273890
273891
273892
273893
273894
273895
273896
273897
273898
273899
273900
273901
273902
273903
273904
273905
273906
273907
273908
273909
273910
273911
273912
273913
273914
273915
273916
273917
273918
273919
273920
273921
273922
273923
273924
273925
273926
273927
273928
273929
273930
273931
273932
273933
273934
273935
273936
273937
273938
273939
273940
273941
273942
273943
273944
273945
273946
273947
273948
273949
273950
273951
273952
273953
273954
273955
273956
273957
273958
273959
273960
273961
273962
273963
273964
273965
273966
273967
273968
273969
273970
273971
273972
273973
273974
273975
273976
273977
273978
273979
273980
273981
273982
273983
273984
273985
273986
273987
273988
273989
273990
273991
273992
273993
273994
273995
273996
273997
273998
273999
274000
274001
274002
274003
274004
274005
274006
274007
274008
274009
274010
274011
274012
274013
274014
274015
274016
274017
274018
274019
274020
274021
274022
274023
274024
274025
274026
274027
274028
274029
274030
274031
274032
274033
274034
274035
274036
274037
274038
274039
274040
274041
274042
274043
274044
274045
274046
274047
274048
274049
274050
274051
274052
274053
274054
274055
274056
274057
274058
274059
274060
274061
274062
274063
274064
274065
274066
274067
274068
274069
274070
274071
274072
274073
274074
274075
274076
274077
274078
274079
274080
274081
274082
274083
274084
274085
274086
274087
274088
274089
274090
274091
274092
274093
274094
274095
274096
274097
274098
274099
274100
274101
274102
274103
274104
274105
274106
274107
274108
274109
274110
274111
274112
274113
274114
274115
274116
274117
274118
274119
274120
274121
274122
274123
274124
274125
274126
274127
274128
274129
274130
274131
274132
274133
274134
274135
274136
274137
274138
274139
274140
274141
274142
274143
274144
274145
274146
274147
274148
274149
274150
274151
274152
274153
274154
274155
274156
274157
274158
274159
274160
274161
274162
274163
274164
274165
274166
274167
274168
274169
274170
274171
274172
274173
274174
274175
274176
274177
274178
274179
274180
274181
274182
274183
274184
274185
274186
274187
274188
274189
274190
274191
274192
274193
274194
274195
274196
274197
274198
274199
274200
274201
274202
274203
274204
274205
274206
274207
274208
274209
274210
274211
274212
274213
274214
274215
274216
274217
274218
274219
274220
274221
274222
274223
274224
274225
274226
274227
274228
274229
274230
274231
274232
274233
274234
274235
274236
274237
274238
274239
274240
274241
274242
274243
274244
274245
274246
274247
274248
274249
274250
274251
274252
274253
274254
274255
274256
274257
274258
274259
274260
274261
274262
274263
274264
274265
274266
274267
274268
274269
274270
274271
274272
274273
274274
274275
274276
274277
274278
274279
274280
274281
274282
274283
274284
274285
274286
274287
274288
274289
274290
274291
274292
274293
274294
274295
274296
274297
274298
274299
274300
274301
274302
274303
274304
274305
274306
274307
274308
274309
274310
274311
274312
274313
274314
274315
274316
274317
274318
274319
274320
274321
274322
274323
274324
274325
274326
274327
274328
274329
274330
274331
274332
274333
274334
274335
274336
274337
274338
274339
274340
274341
274342
274343
274344
274345
274346
274347
274348
274349
274350
274351
274352
274353
274354
274355
274356
274357
274358
274359
274360
274361
274362
274363
274364
274365
274366
274367
274368
274369
274370
274371
274372
274373
274374
274375
274376
274377
274378
274379
274380
274381
274382
274383
274384
274385
274386
274387
274388
274389
274390
274391
274392
274393
274394
274395
274396
274397
274398
274399
274400
274401
274402
274403
274404
274405
274406
274407
274408
274409
274410
274411
274412
274413
274414
274415
274416
274417
274418
274419
274420
274421
274422
274423
274424
274425
274426
274427
274428
274429
274430
274431
274432
274433
274434
274435
274436
274437
274438
274439
274440
274441
274442
274443
274444
274445
274446
274447
274448
274449
274450
274451
274452
274453
274454
274455
274456
274457
274458
274459
274460
274461
274462
274463
274464
274465
274466
274467
274468
274469
274470
274471
274472
274473
274474
274475
274476
274477
274478
274479
274480
274481
274482
274483
274484
274485
274486
274487
274488
274489
274490
274491
274492
274493
274494
274495
274496
274497
274498
274499
274500
274501
274502
274503
274504
274505
274506
274507
274508
274509
274510
274511
274512
274513
274514
274515
274516
274517
274518
274519
274520
274521
274522
274523
274524
274525
274526
274527
274528
274529
274530
274531
274532
274533
274534
274535
274536
274537
274538
274539
274540
274541
274542
274543
274544
274545
274546
274547
274548
274549
274550
274551
274552
274553
274554
274555
274556
274557
274558
274559
274560
274561
274562
274563
274564
274565
274566
274567
274568
274569
274570
274571
274572
274573
274574
274575
274576
274577
274578
274579
274580
274581
274582
274583
274584
274585
274586
274587
274588
274589
274590
274591
274592
274593
274594
274595
274596
274597
274598
274599
274600
274601
274602
274603
274604
274605
274606
274607
274608
274609
274610
274611
274612
274613
274614
274615
274616
274617
274618
274619
274620
274621
274622
274623
274624
274625
274626
274627
274628
274629
274630
274631
274632
274633
274634
274635
274636
274637
274638
274639
274640
274641
274642
274643
274644
274645
274646
274647
274648
274649
274650
274651
274652
274653
274654
274655
274656
274657
274658
274659
274660
274661
274662
274663
274664
274665
274666
274667
274668
274669
274670
274671
274672
274673
274674
274675
274676
274677
274678
274679
274680
274681
274682
274683
274684
274685
274686
274687
274688
274689
274690
274691
274692
274693
274694
274695
274696
274697
274698
274699
274700
274701
274702
274703
274704
274705
274706
274707
274708
274709
274710
274711
274712
274713
274714
274715
274716
274717
274718
274719
274720
274721
274722
274723
274724
274725
274726
274727
274728
274729
274730
274731
274732
274733
274734
274735
274736
274737
274738
274739
274740
274741
274742
274743
274744
274745
274746
274747
274748
274749
274750
274751
274752
274753
274754
274755
274756
274757
274758
274759
274760
274761
274762
274763
274764
274765
274766
274767
274768
274769
274770
274771
274772
274773
274774
274775
274776
274777
274778
274779
274780
274781
274782
274783
274784
274785
274786
274787
274788
274789
274790
274791
274792
274793
274794
274795
274796
274797
274798
274799
274800
274801
274802
274803
274804
274805
274806
274807
274808
274809
274810
274811
274812
274813
274814
274815
274816
274817
274818
274819
274820
274821
274822
274823
274824
274825
274826
274827
274828
274829
274830
274831
274832
274833
274834
274835
274836
274837
274838
274839
274840
274841
274842
274843
274844
274845
274846
274847
274848
274849
274850
274851
274852
274853
274854
274855
274856
274857
274858
274859
274860
274861
274862
274863
274864
274865
274866
274867
274868
274869
274870
274871
274872
274873
274874
274875
274876
274877
274878
274879
274880
274881
274882
274883
274884
274885
274886
274887
274888
274889
274890
274891
274892
274893
274894
274895
274896
274897
274898
274899
274900
274901
274902
274903
274904
274905
274906
274907
274908
274909
274910
274911
274912
274913
274914
274915
274916
274917
274918
274919
274920
274921
274922
274923
274924
274925
274926
274927
274928
274929
274930
274931
274932
274933
274934
274935
274936
274937
274938
274939
274940
274941
274942
274943
274944
274945
274946
274947
274948
274949
274950
274951
274952
274953
274954
274955
274956
274957
274958
274959
274960
274961
274962
274963
274964
274965
274966
274967
274968
274969
274970
274971
274972
274973
274974
274975
274976
274977
274978
274979
274980
274981
274982
274983
274984
274985
274986
274987
274988
274989
274990
274991
274992
274993
274994
274995
274996
274997
274998
274999
275000
275001
275002
275003
275004
275005
275006
275007
275008
275009
275010
275011
275012
275013
275014
275015
275016
275017
275018
275019
275020
275021
275022
275023
275024
275025
275026
275027
275028
275029
275030
275031
275032
275033
275034
275035
275036
275037
275038
275039
275040
275041
275042
275043
275044
275045
275046
275047
275048
275049
275050
275051
275052
275053
275054
275055
275056
275057
275058
275059
275060
275061
275062
275063
275064
275065
275066
275067
275068
275069
275070
275071
275072
275073
275074
275075
275076
275077
275078
275079
275080
275081
275082
275083
275084
275085
275086
275087
275088
275089
275090
275091
275092
275093
275094
275095
275096
275097
275098
275099
275100
275101
275102
275103
275104
275105
275106
275107
275108
275109
275110
275111
275112
275113
275114
275115
275116
275117
275118
275119
275120
275121
275122
275123
275124
275125
275126
275127
275128
275129
275130
275131
275132
275133
275134
275135
275136
275137
275138
275139
275140
275141
275142
275143
275144
275145
275146
275147
275148
275149
275150
275151
275152
275153
275154
275155
275156
275157
275158
275159
275160
275161
275162
275163
275164
275165
275166
275167
275168
275169
275170
275171
275172
275173
275174
275175
275176
275177
275178
275179
275180
275181
275182
275183
275184
275185
275186
275187
275188
275189
275190
275191
275192
275193
275194
275195
275196
275197
275198
275199
275200
275201
275202
275203
275204
275205
275206
275207
275208
275209
275210
275211
275212
275213
275214
275215
275216
275217
275218
275219
275220
275221
275222
275223
275224
275225
275226
275227
275228
275229
275230
275231
275232
275233
275234
275235
275236
275237
275238
275239
275240
275241
275242
275243
275244
275245
275246
275247
275248
275249
275250
275251
275252
275253
275254
275255
275256
275257
275258
275259
275260
275261
275262
275263
275264
275265
275266
275267
275268
275269
275270
275271
275272
275273
275274
275275
275276
275277
275278
275279
275280
275281
275282
275283
275284
275285
275286
275287
275288
275289
275290
275291
275292
275293
275294
275295
275296
275297
275298
275299
275300
275301
275302
275303
275304
275305
275306
275307
275308
275309
275310
275311
275312
275313
275314
275315
275316
275317
275318
275319
275320
275321
275322
275323
275324
275325
275326
275327
275328
275329
275330
275331
275332
275333
275334
275335
275336
275337
275338
275339
275340
275341
275342
275343
275344
275345
275346
275347
275348
275349
275350
275351
275352
275353
275354
275355
275356
275357
275358
275359
275360
275361
275362
275363
275364
275365
275366
275367
275368
275369
275370
275371
275372
275373
275374
275375
275376
275377
275378
275379
275380
275381
275382
275383
275384
275385
275386
275387
275388
275389
275390
275391
275392
275393
275394
275395
275396
275397
275398
275399
275400
275401
275402
275403
275404
275405
275406
275407
275408
275409
275410
275411
275412
275413
275414
275415
275416
275417
275418
275419
275420
275421
275422
275423
275424
275425
275426
275427
275428
275429
275430
275431
275432
275433
275434
275435
275436
275437
275438
275439
275440
275441
275442
275443
275444
275445
275446
275447
275448
275449
275450
275451
275452
275453
275454
275455
275456
275457
275458
275459
275460
275461
275462
275463
275464
275465
275466
275467
275468
275469
275470
275471
275472
275473
275474
275475
275476
275477
275478
275479
275480
275481
275482
275483
275484
275485
275486
275487
275488
275489
275490
275491
275492
275493
275494
275495
275496
275497
275498
275499
275500
275501
275502
275503
275504
275505
275506
275507
275508
275509
275510
275511
275512
275513
275514
275515
275516
275517
275518
275519
275520
275521
275522
275523
275524
275525
275526
275527
275528
275529
275530
275531
275532
275533
275534
275535
275536
275537
275538
275539
275540
275541
275542
275543
275544
275545
275546
275547
275548
275549
275550
275551
275552
275553
275554
275555
275556
275557
275558
275559
275560
275561
275562
275563
275564
275565
275566
275567
275568
275569
275570
275571
275572
275573
275574
275575
275576
275577
275578
275579
275580
275581
275582
275583
275584
275585
275586
275587
275588
275589
275590
275591
275592
275593
275594
275595
275596
275597
275598
275599
275600
275601
275602
275603
275604
275605
275606
275607
275608
275609
275610
275611
275612
275613
275614
275615
275616
275617
275618
275619
275620
275621
275622
275623
275624
275625
275626
275627
275628
275629
275630
275631
275632
275633
275634
275635
275636
275637
275638
275639
275640
275641
275642
275643
275644
275645
275646
275647
275648
275649
275650
275651
275652
275653
275654
275655
275656
275657
275658
275659
275660
275661
275662
275663
275664
275665
275666
275667
275668
275669
275670
275671
275672
275673
275674
275675
275676
275677
275678
275679
275680
275681
275682
275683
275684
275685
275686
275687
275688
275689
275690
275691
275692
275693
275694
275695
275696
275697
275698
275699
275700
275701
275702
275703
275704
275705
275706
275707
275708
275709
275710
275711
275712
275713
275714
275715
275716
275717
275718
275719
275720
275721
275722
275723
275724
275725
275726
275727
275728
275729
275730
275731
275732
275733
275734
275735
275736
275737
275738
275739
275740
275741
275742
275743
275744
275745
275746
275747
275748
275749
275750
275751
275752
275753
275754
275755
275756
275757
275758
275759
275760
275761
275762
275763
275764
275765
275766
275767
275768
275769
275770
275771
275772
275773
275774
275775
275776
275777
275778
275779
275780
275781
275782
275783
275784
275785
275786
275787
275788
275789
275790
275791
275792
275793
275794
275795
275796
275797
275798
275799
275800
275801
275802
275803
275804
275805
275806
275807
275808
275809
275810
275811
275812
275813
275814
275815
275816
275817
275818
275819
275820
275821
275822
275823
275824
275825
275826
275827
275828
275829
275830
275831
275832
275833
275834
275835
275836
275837
275838
275839
275840
275841
275842
275843
275844
275845
275846
275847
275848
275849
275850
275851
275852
275853
275854
275855
275856
275857
275858
275859
275860
275861
275862
275863
275864
275865
275866
275867
275868
275869
275870
275871
275872
275873
275874
275875
275876
275877
275878
275879
275880
275881
275882
275883
275884
275885
275886
275887
275888
275889
275890
275891
275892
275893
275894
275895
275896
275897
275898
275899
275900
275901
275902
275903
275904
275905
275906
275907
275908
275909
275910
275911
275912
275913
275914
275915
275916
275917
275918
275919
275920
275921
275922
275923
275924
275925
275926
275927
275928
275929
275930
275931
275932
275933
275934
275935
275936
275937
275938
275939
275940
275941
275942
275943
275944
275945
275946
275947
275948
275949
275950
275951
275952
275953
275954
275955
275956
275957
275958
275959
275960
275961
275962
275963
275964
275965
275966
275967
275968
275969
275970
275971
275972
275973
275974
275975
275976
275977
275978
275979
275980
275981
275982
275983
275984
275985
275986
275987
275988
275989
275990
275991
275992
275993
275994
275995
275996
275997
275998
275999
276000
276001
276002
276003
276004
276005
276006
276007
276008
276009
276010
276011
276012
276013
276014
276015
276016
276017
276018
276019
276020
276021
276022
276023
276024
276025
276026
276027
276028
276029
276030
276031
276032
276033
276034
276035
276036
276037
276038
276039
276040
276041
276042
276043
276044
276045
276046
276047
276048
276049
276050
276051
276052
276053
276054
276055
276056
276057
276058
276059
276060
276061
276062
276063
276064
276065
276066
276067
276068
276069
276070
276071
276072
276073
276074
276075
276076
276077
276078
276079
276080
276081
276082
276083
276084
276085
276086
276087
276088
276089
276090
276091
276092
276093
276094
276095
276096
276097
276098
276099
276100
276101
276102
276103
276104
276105
276106
276107
276108
276109
276110
276111
276112
276113
276114
276115
276116
276117
276118
276119
276120
276121
276122
276123
276124
276125
276126
276127
276128
276129
276130
276131
276132
276133
276134
276135
276136
276137
276138
276139
276140
276141
276142
276143
276144
276145
276146
276147
276148
276149
276150
276151
276152
276153
276154
276155
276156
276157
276158
276159
276160
276161
276162
276163
276164
276165
276166
276167
276168
276169
276170
276171
276172
276173
276174
276175
276176
276177
276178
276179
276180
276181
276182
276183
276184
276185
276186
276187
276188
276189
276190
276191
276192
276193
276194
276195
276196
276197
276198
276199
276200
276201
276202
276203
276204
276205
276206
276207
276208
276209
276210
276211
276212
276213
276214
276215
276216
276217
276218
276219
276220
276221
276222
276223
276224
276225
276226
276227
276228
276229
276230
276231
276232
276233
276234
276235
276236
276237
276238
276239
276240
276241
276242
276243
276244
276245
276246
276247
276248
276249
276250
276251
276252
276253
276254
276255
276256
276257
276258
276259
276260
276261
276262
276263
276264
276265
276266
276267
276268
276269
276270
276271
276272
276273
276274
276275
276276
276277
276278
276279
276280
276281
276282
276283
276284
276285
276286
276287
276288
276289
276290
276291
276292
276293
276294
276295
276296
276297
276298
276299
276300
276301
276302
276303
276304
276305
276306
276307
276308
276309
276310
276311
276312
276313
276314
276315
276316
276317
276318
276319
276320
276321
276322
276323
276324
276325
276326
276327
276328
276329
276330
276331
276332
276333
276334
276335
276336
276337
276338
276339
276340
276341
276342
276343
276344
276345
276346
276347
276348
276349
276350
276351
276352
276353
276354
276355
276356
276357
276358
276359
276360
276361
276362
276363
276364
276365
276366
276367
276368
276369
276370
276371
276372
276373
276374
276375
276376
276377
276378
276379
276380
276381
276382
276383
276384
276385
276386
276387
276388
276389
276390
276391
276392
276393
276394
276395
276396
276397
276398
276399
276400
276401
276402
276403
276404
276405
276406
276407
276408
276409
276410
276411
276412
276413
276414
276415
276416
276417
276418
276419
276420
276421
276422
276423
276424
276425
276426
276427
276428
276429
276430
276431
276432
276433
276434
276435
276436
276437
276438
276439
276440
276441
276442
276443
276444
276445
276446
276447
276448
276449
276450
276451
276452
276453
276454
276455
276456
276457
276458
276459
276460
276461
276462
276463
276464
276465
276466
276467
276468
276469
276470
276471
276472
276473
276474
276475
276476
276477
276478
276479
276480
276481
276482
276483
276484
276485
276486
276487
276488
276489
276490
276491
276492
276493
276494
276495
276496
276497
276498
276499
276500
276501
276502
276503
276504
276505
276506
276507
276508
276509
276510
276511
276512
276513
276514
276515
276516
276517
276518
276519
276520
276521
276522
276523
276524
276525
276526
276527
276528
276529
276530
276531
276532
276533
276534
276535
276536
276537
276538
276539
276540
276541
276542
276543
276544
276545
276546
276547
276548
276549
276550
276551
276552
276553
276554
276555
276556
276557
276558
276559
276560
276561
276562
276563
276564
276565
276566
276567
276568
276569
276570
276571
276572
276573
276574
276575
276576
276577
276578
276579
276580
276581
276582
276583
276584
276585
276586
276587
276588
276589
276590
276591
276592
276593
276594
276595
276596
276597
276598
276599
276600
276601
276602
276603
276604
276605
276606
276607
276608
276609
276610
276611
276612
276613
276614
276615
276616
276617
276618

2025-07-27  Nick Clifton  <nickc@redhat.com>

	Oops - test files accidentally omitted from previous deltas

2025-07-27  Indu Bhagat  <indu.bhagat@oracle.com>

	[PATCH] doc: sframe: mention errata 1 of SFrame version 2
	With the changes of an added flag SFRAME_F_FDE_FUNC_START_PCREL, s390x
	support and new section type SHT_GNU_SFRAME, indicate that this document
	specifies the errata 1 of SFrame version 2.  This will help distinguish
	the document / specification better from previous releases.

	libsframe/doc/
		* sframe-spec.texi: Mention errata 1 of SFrame version 2.

2025-07-27  Indu Bhagat  <indu.bhagat@oracle.com>

	[PATCH] readelf: objdump: sframe: fix dumping with section name
	Fix PR binutils/33186 - No SFrame dump if section name is not .sframe

	When the section name is not ".sframe", ensure that readelf and objdump
	are able to dump a section of type SHT_GNU_SFRAME and not fail if the
	user specifies the new section name.

	For objdump, in dump_dwarf_section (), use the match string of ".sframe"
	to find the corresponding debug_displays[] item for SFrame section.
	Doing this ensures that any call to dump_dwarf_section () with the
	section pointing to the SFrame section (with name possibly different
	from ".sframe") will successfully dump the SFrame section.

	If the SFrame section is named anything but ".sframe", and user does not
	specify the name of the SFrame section either, the documented behaviour
	is that the default section name is assumed to be ".sframe".  So the
	following (albeit counter intuitive) is expected at this time:

	$ readelf -S sort | grep sframe
	  [NN] .sframe2          GNU_SFRAME       0000000000NNNNNN  0000NNNN

	(Note section name .sframe2).

	$ objdump --sframe sort

	sort:     file format elf64-x86-64

	No .sframe section present

	(Similarly for readelf as well).

	For objdump, set dump_sframe_section_name to ".sframe" if user specifies
	no section name.  In the error checking done in dump_sframe_section, add
	the case when user specifies a valid section name but one that does not
	contain SFrame section data.  For sections generated with Binutils >=
	2.45, this can be checked with section type of SHT_GNU_SFRAME.
	Previously these sections were SHT_PROGBITS with name ".sframe".

	Similar changes in readelf.

	Add a test each for objdump and readelf to dump a renamed section.  Use
	gas_sframe_check to limit the execution of these tests only when a gas
	supporting SFrame format is present.

	binutils/
		PR binutils/33186
		* objdump.c (dump_dwarf_section): Set match to ".sframe" which
		corresponds to the name in the debug_displays[] entry for
		SFrame section.
		(dump_sframe_section): Check if the user specified section name
		contains SFrame data.
		(main): Set default section name to ".sframe".
		* readelf.c (display_debug_section): Adjust checks to find the
		debug_diplays[] item for the input arg SFrame section.
		Use id instead of i, as it is more readable.

	binutils/testsuite/
		PR binutils/33186
		* binutils-all/x86-64/objdump-sframe-01.d: New test.
		* binutils-all/x86-64/readelf-sframe-01.d: New test.
		* binutils-all/x86-64/sframe-func.s: New test.

2025-07-27  Indu Bhagat  <indu.bhagat@oracle.com>

	[PATCH] gas: sframe: command line option takes precedence over gas directive to emit .sframe section.
	Fix PR gas/33175 sframe: --gsframe=no does not disable when .cfi_sections directive with .sframe

	--gsframe=no should also disable generation of SFrame section when explicit CFI directive: .cfi_sections .sframe is specified in the input.
	This means we need to track whether SFrame generation was explicitly disabled by the user.
	Introduce a new enum to facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and GEN_SFRAME_DISABLED.
	While fixing the bug by adding the enum, keep the upcoming requirement in mind: we will also need to disambiguate between --enable-default-sframe and user-specified --gsframe/--gsframe=yes.
	The intent is to not display SFrame related warnings or errors like:   as_bad (_(".sframe not supported for target")); for unsupported targets if --enable-default-sframe is in effect.
	This implies we need to have a four state enum ( GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED, GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED) gas

2025-07-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-25  Alice Carlotti  <alice.carlotti@arm.com>

	gas/NEWS: Add AArch64 updates

2025-07-25  Alice Carlotti  <alice.carlotti@arm.com>

	gas/doc: Update AArch64 Architecture Extensions
	Add faminmax, move a couple of misplaced entries, and improve a few
	other entries.

	The documentation now lists every recognised extension name, with the
	exception of a couple of aliases that are deliberately undocumented.

2025-07-25  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Fix sve2p2/sme2p2 dependencies
	Change dependency on sve2/sme2 to sve2p1/sme2p1.

2025-07-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	ld: Force SHELL=/bin/bash in ld for Solaris [PR32580]
	As described in PR ld/32580, when using SHELL=/bin/sh or /bin/ksh on
	Solaris, the generated linker scripts get corrupted.  So far, the only
	workaround is to enforce /bin/bash instead.

	This is a major nuisance for developers and users alike, so this patch
	automates this by overriding SHELL in ld/configure.ac.

	Tested on amd64-pc-solaris2.11 in three configurations:

	* CONFIG_SHELL unset

	* CONFIG_SHELL=/bin/ksh

	* CONFIG_SHELL='/bin/bash --norc'

	In the first two cases, SHELL was set to /bin/bash as desired, while in
	the third it was left unchanged.

	2025-07-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

		ld:
		PR ld/32580
		* configure.ac <*-*-solaris2*>: Enforce SHELL=/bin/bash.
		* configure: Regenerate.

	(cherry picked from commit 96ad2fd3c0c0414110fe58ed4ee511f49768fa3d)

2025-07-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-24  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: fix PR gas/33170
	SFrame generation code assumes that since DW_CFA_restore means
	restoration of the state of the register to the one at the beginning of
	the function, there must be a state to restore to (hence the gas_assert
	(cie_fre)).

	This assumption needs adjustment.  DW_CFA_restore may be present in the
	very beginning of a (e.g., cold) function, with no initialized state for
	SFrame functions to restore to.

	gas/
		PR gas/33170
		* gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if
		CIE FRE is not yet setup.
	gas/testsuite/
		PR gas/33170
		* gas/cfi-sframe/cfi-sframe.exp: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.

	(cherry picked from commit 83eeaf917873a550656faf9a38cd14e0f4c521b1)

2025-07-24  H.J. Lu  <hjl.tools@gmail.com>

	strip: Properly handle LLVM IR bitcode
	commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Sun May 4 05:12:46 2025 +0800

	    strip: Add GCC LTO IR support

	added "-R .gnu.lto_.*" to strip to remove all GCC LTO sections.  When
	"-R .gnu.lto_.*" is used, the plugin target is ignored so that all LTO
	sections are stripped as the regular sections.  It works for the slim
	GCC LTO IR since the GCC LTO IR is stored in the regular sections.  When
	the plugin target is ignored, the GCC LTO IR can be recognized as the
	normal object files.  But it doesn't work for the slim LLVM IR which
	is stored in a standalone file.

	1. Add bfd_check_format_matches_lto and bfd_check_format_lto to take an
	argument, lto_sections_removed, to indicate if all LTO sections should
	be removed.
	2. Update strip to always enable the plugin target so that the plugin
	target is enabled when checking for bfd_archive.
	3. Update strip to ignore the plugin target for bfd_object when all LTO
	sections should be removed.  If the object is unknown, copy it as an
	unknown file without any messages.
	4. Treat the "-R .llvm.lto" strip option as removing all LTO sections.

	bfd/

		PR binutils/33198
		* format.c (bfd_check_format_lto): New function.
		(bfd_check_format): Call bfd_check_format_matches_lto.
		(bfd_check_format_matches): Renamed to ...
		(bfd_check_format_matches_lto): This.  Add an argument,
		lto_sections_removed, to indicate if all LTO sections should be
		removed and don't match the plugin target if lto_sections_removed
		is true.
		(bfd_check_format_matches): Call bfd_check_format_matches_lto.
		* bfd-in2.h: Regenerated.

	binutils/

		PR binutils/33198
		* objcopy.c (copy_archive): Call bfd_check_format_lto, instead
		of bfd_check_format, and pass lto_sections_removed.  Remove the
		non-fatal message on unknown element since it will be copied as
		an unknown file.
		(copy_file): Don't check lto_sections_removed when enabling LTO
		plugin in strip.
		(copy_file): Ignore the plugin target first if all LTO sections
		should be removed.  Try with the plugin target next if ignoring
		the plugin target failed to match the format.
		(strip_main): Also set lto_sections_removed for -R .llvm.lto.
		* testsuite/binutils-all/x86-64/pr33198.c: New file.
		* testsuite/binutils-all/x86-64/x86-64.exp (run_pr33198_test):
		New.
		Run binutils/33198 tests.
		* testsuite/lib/binutils-common.exp (llvm_plug_opt): New.
		(CLANG_FOR_TARGET): New.  Set to "clang" for native build if
		"clang -v" reports "clang version".

	(cherry picked from commit f752be8f916efa70aea9c2e4f664c75690fd136c)

2025-07-24  Alan Modra  <amodra@gmail.com>

	PR 33197 [AVR] Incorrect syntax in generated ldscript
	Rearrange scripttempl/avr.sc to avoid oddities of shells expanding
	${RELOCATING+stuff} in here documents where "stuff" contains quoted
	strings.  Also I think it is better to avoid multi-line "stuff" as it
	can be tricky to spot the ending brace.

	(cherry picked from commit ae114fb523efe908f9e807359e2f494ee64d2801)

2025-07-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-22  Nick Clifton  <nickc@redhat.com>

	Updated translations for various sub-directories

2025-07-22  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	ld: Rename a file on Windows fails if target already exists
	To rename a file on Windows, the target name cannot exist. Removing file
	prior to renaming ensures this is handled.
	To remove a file on Windows, the file cannot be open. Closing the bfd
	handle ensures this is handled.
	Moved call to free on isympp / osympp to after bfd is closed to align
	with comment earlier in the cmdline_add_object_only_section function.

	(cherry picked from commit 233cd5946413108bf4902b22a9cb23ad0a468f5e)

2025-07-21  Dmitrii Bordukov  <dabordukov@gmail.com>

	gprofng: do not skip weak symbols
	PR gprofng/33151

	gprofng ignores functions that are compiled as weak symbols. This
	heavily affects C++ class methods that are always compiled by g++
	and clang++ as weak symbols. In this case 'gprofng display text'
	just displays <static>@ADDRESS(<FILENAME>) instead of proper method
	name.

	The bug has been introduced in the commit 470a0288a818.

2025-07-18  Alan Modra  <amodra@gmail.com>

	Remove sframe relocs against discarded sections
	Commit d7f343eaad3f testsuite change resulted in a regression for
	s390x-linux.  This extends the x86_64 fix to other targets.

		PR ld/33156
		* elf-bfd.h (RELOC_AGAINST_DISCARDED_SECTION): Remove .sframe
		relocs too.

	(cherry picked from commit fcf7470408aa0508fbe99abb99547757a348383d)

2025-07-17  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: relax the assertion limit for fre_start_addr
	Fix PR ld/33131 Failed assertion when linking gccgo

	Make amendments in both sframe_decoder_get_fre and
	sframe_encoder_add_fre.

	Since GNU as and the dw2gencfi code generally accepts such CFI, its best
	to allow in SFrame FREs too.

	libsframe/
		PR ld/33131.
		* sframe.c (sframe_decoder_get_fre): Relax the assertion a bit.
		(sframe_encoder_add_fre): Likewise.

	(cherry picked from commit 387efef5fef727cbe52099dcd5012905c4205be3)

2025-07-16  Sam James  <sam@gentoo.org>

	gas: improve --gsframe documentation
	I omitted documentation in 8aad677a12832885acd5be1de8f41e740b8e713d in
	error. Rectify that with:
	1) changing ---help to mention bare `--gsframe` too, as we're not
	   getting rid of that;

	2) adding the new --gsframe=[no|yes] form to as.texi.

		PR gas/33125
		* gas/as.c (parse_args): Tweak --gsframe= help text.
		* gas/doc/as.texi: Document --gsframe=[no|yes].

	(cherry picked from commit 50c1c57426db6e1c7b44b4d05f0b07fcba91f890)

2025-07-16  H.J. Lu  <hjl.tools@gmail.com>

	gas: Re-indent case OPTION_SFRAME:
		PR gas/33125
		* gas/as.c (parse_args): Re-indent case OPTION_SFRAME:

	(cherry picked from commit 1535d2a0ce4e474f1a42e8b8720de01b7dc1f656)

2025-07-16  Sam James  <sam@gentoo.org>

	gas: support --gsframe=no
	Being able to explicitly disable SFrames on the command line is useful,
	especially when looking at a gas that enables SFrames by default. The
	binutils testsuite will benefit from this as there's testcases that don't
	expect their presence.

	In summary:
	* Nothing is passed       => no SFrames (no change from before)
	* --gsframe is passed     => SFrames    (no change from before)
	* --gsframe=yes is passed => SFrames    (previously rejected)
	* --gsframe-no  is passed => no SFrames (previously rejected)

		PR gas/33125
		* gas/as.c (parse_args): Accept --gsframe=no, --gsframe=yes.

	(cherry picked from commit 8aad677a12832885acd5be1de8f41e740b8e713d)

2025-07-16  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Remove sframe relocs against discarded sections
	Since unlike eh_frame editing code, sframe editing code keeps
	R_X86_64_NONE reloc as is, its r_offset is wrong, we must not
	generate R_X86_64_NONE reloc in sframe section against discarded
	sections for "ld -r".

	bfd/

		PR ld/33156
		* elf64-x86-64.c (elf_x86_64_relocate_section): Also remove
		sframe relocations against discarded sections for "ld -r".

	ld/

		PR ld/33156
		* testsuite/ld-elf/eh-group.exp (as_gsframe): New.
		Assemble eh-group.o with $as_gsframe.

	(cherry picked from commit d7f343eaad3f34c76657b9996e6253b4f9a218d5)

2025-07-16  H.J. Lu  <hjl.tools@gmail.com>

	sframe: Allow input R_*_NONE relocations
	"ld -r" generates R_*_NONE relocations in sframe section if input
	relocations in sframe section are against discarded section.  Allow
	input R_*_NONE relocations if there are more relocation entries than
	SFrame entries, instead of assuming number of SFrame entries == number
	of relocation entries.

	bfd/

		PR ld/33127
		* elf-sframe.c (sframe_decoder_init_func_bfdinfo): Allow input
		R_*_NONE relocations if there are more relocation entries than
		SFrame entries.

	ld/

		PR ld/33127
		* testsuite/ld-x86-64/sframe-reloc-2a.s: New file.
		* testsuite/ld-x86-64/sframe-reloc-2b.s: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run PR ld/33127 tests.

	(cherry picked from commit 5f9bf0cf711a153a0a20d6ff88181e9a6775bdba)

2025-07-16  H.J. Lu  <hjl.tools@gmail.com>

	ld: Clear map_head_is_link_order for .gnu_object_only
	Clear map_head_is_link_order when generating .gnu_object_only section so
	that lang_add_section can add new sections and .sframe sections will be
	properly merged by _bfd_elf_merge_section_sframe.

		PR ld/33146
		* ldlang.c (cmdline_emit_object_only_section): Clear
		map_head_is_link_order.
		* testsuite/ld-plugin/lto.exp (as_gsframe): New.
		(lto_link_tests): Add $as_gsframe to compile lto-4b.o and
		lto-4c.o.

	(cherry picked from commit 939eb467b21de5d18ee703755fb9704a525cfe21)

2025-07-16  Alan Modra  <amodra@gmail.com>

	Re: gas: Move gas_sframe_check to binutils-common.exp
	PR ld/33146

	Correct TCL errors trying to access error output file in commit
	ef7a634dc01d.  In fact, get rid of the output file test entirely since
	gas exit status is sufficient.

	Also there is no need to firstly check for ELF support.

	Set check_as_sframe_result, and remove ld-lib.exp check_as_sframe.

	(cherry picked from commit a57a3a169ea9ec79977949c9c8dccd3a2a615fae)

2025-07-16  H.J. Lu  <hjl.tools@gmail.com>

	gas: Move gas_sframe_check to binutils-common.exp
	Move gas_sframe_check to binutils-common.exp so that it can be used in
	linker tests to check if a target assembler supports --gsframe.

	binutils/

		PR ld/33146
		* testsuite/lib/binutils-common.exp (gas_sframe_check): Moved
		from cfi-sframe.exp.  Replace gas_host_run with remote_exec.

	gas/

		PR ld/33146
		* testsuite/gas/cfi-sframe/cfi-sframe.exp (gas_sframe_check):
		Moved to binutils-common.exp.

	(cherry picked from commit ef7a634dc01df3d78f208c93316b52937d3fe8f4)

2025-07-15  Alan Modra  <amodra@gmail.com>

	s390x sframe regressions
	Commit 6ab3f09a682a resulted in regressions.
	s390x-linux-gnu  FAIL: SFrame simple link
	s390x-linux-gnu  FAIL: SFrame for plt0 and pltN

	Commit 939eb467b21d exposed the problem further.
	s390x-linux-gnu  FAIL: LTO 4a
	s390x-linux-gnu  FAIL: LTO 4c
	s390x-linux-gnu  FAIL: LTO 4d

		* elf64-s390.c (elf_s390_create_dynamic_sections): Set plt_sframe
		ELF section type.

	Reviewed-by: Jens Remus <jremus@linux.ibm.com>
	(cherry picked from commit 168c017e206894effdefa919bff29880165fae13)

2025-07-15  Nick Clifton  <nickc@redhat.com>

	Updated translations for various sub-directories

2025-07-15  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	Only parse attributes in ELF sections with the SHT_GNU_ATTRIBUTES type if the OS is not Solaris.  Set the is_solaris flag for Sparc solaris architectures
	PR 33153

2025-07-14  Nick Clifton  <nickc@redhat.com>

	Updated Ukranian translation for the opcodes sub-directory

	Updated Ukranian translation for the binutils sub-directory

	Updated Spanish translation for the gas sub-directory

2025-07-14  Nelson Chu  <nelson@rivosinc.com>

	gas/NEWS: Corrected the information about mapping symbol $x for risc-v

2025-07-14  Aaron Griffith  <aargri@gmail.com>

	gas: accept leading zeros on dollar local labels in z80 sdcc compat mode
	SDCC assembly output uses 5-digit numeric dollar sign labels, padded
	with zeros. Commit 226749d made these invalid, and broke the Z80 SDCC
	compatibility mode in GAS.

	https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b

	This restores SDCC compatibility by replacing the leading zeros with
	spaces when inside dollar local labels and when SDCC compatibility is
	enabled. It also restores the SDCC test case to represent actual
	syntax emitted by SDCC, and adds a note explaining the purpose of
	the test.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33030

2025-07-13  Nick Clifton  <nickc@redhat.com>

	Fix compile time warning message about optarg parameter shadowing global variable

	Update version number on 2.45 branch

	Add markers for 2.45 branch

2025-07-13  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Work around GCC ipa-modref bug
	PR mi/32571 reports the following problem:
	...
	$ gdb -q -batch -ex "b bla.c:100"
	<random output>
	Make breakpoint pending on future shared library load? (y or [n]) \
	  [answered N; input not from terminal]
	...
	while this is expected:
	...
	$ gdb -q -batch -ex "b bla.c:100"
	No symbol table is loaded.  Use the "file" command.
	Make breakpoint pending on future shared library load? (y or [n]) \
	  [answered N; input not from terminal]
	...

	A few factors in reproducing this are building gdb using gcc 14,
	"-O2 -flto=auto" and --disable-nls.  For more details, see the PR.

	This turns out to be caused by a GCC PR [1], more specifically a problem in
	ipa-modref.

	Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
	assuming the GCC 16.1 release will contain a fix.

	Tested on aarch64-linux and x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987

2025-07-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-12  Aaron Griffith  <aargri@gmail.com>

	gdb: add Aaron Griffith to gdb/MAINTAINERS

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	ld/aarch64elf: add support for DT_AARCH64_MEMTAG_STACK dynamic tag
	Add new command line option -z memtag-stack for aarch64 elf.  This
	option instructs the linker to generate the necessary dynamic tag
	DT_AARCH64_MEMTAG_STACK, which the dynamic loader can then use to
	protect the stack memory with PROT_MTE.  Linker issues an
	'unrecognized option' error when -z memtag-stack is specified for
	non-aarch64 based emulations.

	readelf displays the dynamic tag when present:

	$ readelf -d <exectutable>
	Dynamic section at offset 0xfdd8 contains XX entries:
	Tag        Type                         Name/Value
	0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
	0x000000000000000c (INIT)               0x400520
	0x000000000000000d (FINI)               0x400b64
	0x0000000000000019 (INIT_ARRAY)         0x41fdc8
	...                 ...                 ...
	0x000000007000000c (AARCH64_MEMTAG_STACK) 0x1
	...                 ...                 ...

	ChangeLog:

	        * bfd/elfnn-aarch64.c (elfNN_aarch64_late_size_sections): Emit
		DT_AARCH64_MEMTAG_STACK dynamic tag.
	        * bfd/elfxx-aarch64.h (struct aarch64_memtag_opts): Add new
		member for tracking whether stack access uses MTE insns.
	        * binutils/readelf.c (get_aarch64_dynamic_type): Handle
		DT_AARCH64_MEMTAG_STACK.
	        * ld/emultempl/aarch64elf.em: Add new command line option.
	        * ld/ld.texi: Add documentation for -z memtag-stack.
	        * ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test.
	        * ld/testsuite/ld-aarch64/dt-memtag-stack.d: New test.

	include/ChangeLog:

	        * elf/aarch64.h (DT_AARCH64_MEMTAG_STACK): New definition.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	ld/aarch64elf: add support for DT_AARCH64_MEMTAG_MODE dynamic tag
	Add new command line option -z memtag-mode=<mode> to aarch64 elf,
	where <mode> can be one of none, sync, or async.  For mode of sync or
	async, a DT_AARCH64_MEMTAG_MODE dynamic tag with a value of 0 or 1
	respectively is emitted.

	readelf displays the dynamic tag when present:

	$ readelf -d <exectutable>
	Dynamic section at offset 0xfdd8 contains XX entries:
	  Tag        Type                         Name/Value
	 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
	 0x000000000000000c (INIT)               0x400520
	 0x000000000000000d (FINI)               0x400b64
	 0x0000000000000019 (INIT_ARRAY)         0x41fdc8
	 ...                 ...                 ...
	 0x0000000070000009 (AARCH64_MEMTAG_MODE) 0x1
	 ...                 ...                 ...

	Note that this patch doesn't add support for the "asymm" MTE mode,
	which is an Armv8.7 extension.

	ChangeLog:

	        * bfd/elfnn-aarch64.c (struct elf_aarch64_link_hash_table): Add
		new member for memtag properties.
	        (bfd_elfNN_aarch64_set_options): New argument to pass memtag
		properties.
		(elfNN_aarch64_late_size_sections): Emit DT_AARCH64_MEMTAG_MODE
		dynamic tag.
	        * bfd/elfxx-aarch64.h: New definition for the various memtag
		properties.
	        * binutils/readelf.c (get_aarch64_dynamic_type): Handle
		DT_AARCH64_MEMTAG_MODE.
	        * ld/emultempl/aarch64elf.em: Likewise.
	        * ld/ld.texi: Add documentation for the new option
		-z memtag-mode.
	        * ld/testsuite/ld-aarch64/aarch64-elf.exp: New test.
	        * ld/testsuite/ld-aarch64/dt-memtag.d: New test.
	        * ld/testsuite/ld-aarch64/dt-memtag-mode.s: New test.

	include/ChangeLog:

	        * elf/aarch64.h (DT_AARCH64_MEMTAG_MODE): New definition.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	ld: aarch64: make EH Frame parsing aware of augmentation char 'G'
	As per the DWARF for the Arm 64-bit Architecture (AArch64)
	specification, the augmentation char 'G' indicates that associated
	frames may modify MTE tags on the stack space they use.

	Add knowledge of the 'G' augmentation char to the EH Frame parsing
	code.

	ChangeLog:

	        * bfd/elf-eh-frame.c (_bfd_elf_parse_eh_frame): Accommodate
		augmentation char 'G'.
	        * ld/testsuite/ld-aarch64/aarch64-elf.exp: New test.
	        * ld/testsuite/ld-aarch64/mte-tagged-frame-bar.s: New test.
	        * ld/testsuite/ld-aarch64/mte-tagged-frame-foo.s: New test.
	        * ld/testsuite/ld-aarch64/mte-tagged-frame.d: New test.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: aarch64: suppport CFI directive .cfi_mte_tagged_frame
	Process a new aarch64-specific CFI directive: .cfi_mte_tagged_frame
	(LLVM uses this CFI directive already).  The CFI directive, when
	present for a function, indicates that the stack frame for the
	function may modify the MTE tags of the stack space it uses.  The
	assembler emits char 'G' in the CIE augmentation string to indicate
	the same.

	ChangeLog:

	        * gas/config/tc-aarch64.c (s_aarch64_mte_tagged_frame): New
		definition.
	        * gas/config/tc-aarch64.h (tc_fde_entry_extras): Add
		memtag_frame_p.
	        (tc_cie_entry_extras): Likewise.
	        (tc_fde_entry_init_extra): Likewise.
	        (tc_cie_fde_equivalent_extra): Likewise.
	        (tc_cie_entry_init_extra): Likewise.
	        * gas/doc/c-aarch64.texi: Add documentation for
		.cfi_mte_tagged_frame directive.
	        * gas/testsuite/gas/aarch64/mte_tagged_stack.d: New test.
	        * gas/testsuite/gas/aarch64/mte_tagged_stack.s: New test.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	binutils: make read_cie aware of new augmentation char 'G'
	This allows objdump/readelf to dump DWARF/EH Frame info when the stack
	frame makes use of MTE tagging.

	ChangeLog:

	        * binutils/dwarf.c (is_aarch64_augmentation): Add handling for augmentation
		char 'G'.

	---
	[No change in V3]

2025-07-12  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bfd: fix recognition of arch-specific augmentations
	This patch fixes _bfd_elf_parse_eh_frame so it will not recognize
	machine/architecture specific augmentation characters in EH Frame
	CFIs.

	Regtested in x86_64-linux-gnu and aarch64-linux-gnu.

	bfd/ChangeLog:

		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Recognize augmentation
		'B' only if targetting aarch64.

2025-07-12  Jose E. Marchesi  <jose.marchesi@oracle.com>

	binutils: factorize handling of arch-specific DWARF augmentations
	This patch factorizes the handling of architecture/machine specific
	augmentation characters in CIEs.

	Based on an idea proposed by Richard Earnshaw.

	binutils/ChangeLog:

		* dwarf.c (is_mach_augmentation_ftype): New type.
		(is_mach_augmentation): New variable.
		(is_nomach_augmentation): New function.
		(is_aarch64_augmentation): Likewise.
		(init_dwarf_by_elf_machine_code): Set is_mach_augmentation as
		appropriate.
		(init_dwarf_by_bfd_arch_and_mach): Likewise.
		(read_cie): Handle architecture-specific augmentation characters
		in a generic way.

2025-07-12  Jose E. Marchesi  <jose.marchesi@oracle.com>

	binutils: generalize init_dwarf_regnames_by_* functions
	This patch renames the functions:

	  init_dwarf_regnames_by_elf_machine_code
	  init_dwarf_regnames_by_bfd_arch_and_mach

	to

	  init_dwarf_by_elf_machine_code
	  init_dwarf_by_bfd_arch_and_mach

	The idea is to start using these functions to perform general
	architecture/machine specific initializations beyond register names.

	Regtested in x86_64-linux-gnu and aarch64-linux-gnu targets.

	binutils/ChangeLog:

		* dwarf.c (init_dwarf_regnames_by_elf_machine_code): Rename to
		init_dwarf_by_elf_machine_code.
		(init_dwarf_regnames_by_bfd_arch_and_mach): Rename to
		init_dwarf_by_bfd_arch_and_mach.
		* dwarf.h: Adjust prototypes accordingly.
		* readelf.c (process_file_header): Adjust call to
		init_dwarf_regnames_by_elf_machine_code accordingly.
		* objdump.c (dump_dwarf): Adjust call to
		init_dwarf_regnames_by_bfd_arch_and_mach accordingly.

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Add support for --march=armv9.6-a

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Disable sysreg guards by default
	Add a new flag -menable-sysreg-checking to restore previous behaviour.
	This existing behaviour is quite inconsistent, so the gating will
	probably be updated in the future.  (In particular, many system
	registers are currently gated with the architecture version they were
	released with instead of the lower architecture version that they
	actually require).

	This patch retains the +d128 requirement for msrr/mrrs.

	Co-Authored-By: Srinath Parvathaneni <srinath.parvathaneni@arm.com>

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Add missing F_STRICT flags
	By default, NIL qualifiers are treated as matching any qualifier when
	checking operand constraints.  For many SVE instructions, this would
	allow operands with missing type suffixes to be assembled as if they had
	any explicit type specified.  To prevent this, the F_STRICT flag is used
	to specify that NIL qualifiers should match only NIL qualifiers.

	Unfortunately, several SVE instructions incorrectly omitted this
	F_STRICT flag.  The bug has existed in the *MATMUL_SVE* macros since
	they were added in 2019.  The macro LUT_SVE2_INSN was added last year,
	and the other incorrect macros are new in this release.

	LUTv2_SME2_INSN and LUTv2_SME2p1_INSN were not actually broken, because
	we reject untyped vector lists already during parsing.  However, I have
	added the F_STRICT flag here anyway, since this is more consistent and
	would be more robust if those operands start accepting untyped vector
	lists in the future.  The new luti4 tests are the only ones that were
	already rejected before this change.

	BFLOAT16_SVE_INSN has been unused since it was originally added, so I
	just deleted the macro.

	The SVE LUT instructions were using the lut instruction class, which
	has special handling only for SIMD operands, and isn't recognised by
	aarch64_decode_variant_using_iclass (which sets the qualifiers during
	decode for most SVE instructions).  To prevent these instructions
	failing to disassemble, I changed their instruction class to sve_misc.

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Remove redundant feature requirements
	Many instructions explicitly specified SVE/SVE2/SME/SME2 as a required
	feature when it was already implied by another required feature (at
	least while the SME->SVE2 implication is retained internally).  These
	redundant features were used to determine both the valid symbol names
	for immediate operands, and the choice of error message for invalid
	movprfx sequences.  Those two scenarios no longer use architecture
	features, so the redundant features are now truly redundant.

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Use operand class to select movprfx error
	Previously the choice of error message for an invalid movprfx sequence
	used the architecture requirements to determine whether an instruction
	was an SVE instruction or not.  This meant specifying SVE or SVE2 as an
	explicit architecture requirement for all SVE instructions, even when
	this was already implied by another feature.  As more architecture
	features are added and with the partial removal of the SME->SVE2
	dependency, these extra feature requirements were getting messier and
	easier to forget.

	Instead, we now look at the operand types.  If there is an SVE_REG,
	SVE_REGLIST or PRED_REG operand, then we treat the instruction as an SVE
	instruction.  This does change behaviour slightly, but it only affects
	the choice of error message and the new choice should be a bit more
	consistent.

	There is one testsuite update required, because Ezra's SVE_AES2 patch
	temporarily broke classification of FEAT_SVE_AES instructions.  This
	patch restores the original behaviour.

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Refactor exclusion of reg names in immediates
	When parsing immediate values, register names should not be
	misinterpreted as symbols.  However, for backwards compatibility we need
	to permit some newer register names within older instructions.  The
	current mechanism for doing so depends on the list of explicit
	architecture requirements for the instructions, which is fragile and
	easy to forget, and grows increasingly messy as more architecture
	features are added.

	This patch add explicit flags to each opcode to indicate which set of
	register names is disallowed in each instance.  These flags are
	mandatory for all opcodes with immediate operands, which ensures that
	the choice of disallowed names will always be deliberate and explicit.

	This patch should have no functional change.

2025-07-12  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Remove redundant ORs with 0

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: bump version to 2.0
	Remove LIBSFRAME_1.1, LIBSFRAME_1.0 nodes and add a new LIBSFRAME_2.0
	node (non-inheritance version) to create new global versioned symbols.
	Also announce libsframe.so.2 in NEWS.

	New APIs:
	     sframe_decoder_get_flags;
	     sframe_decoder_get_offsetof_fde_start_addr;
	     sframe_encoder_get_flags;
	     sframe_encoder_get_offsetof_fde_start_addr;

	Removed APIs: (already deprecated since X-2 release)
	     sframe_get_funcdesc_with_addr;

	APIs with changed semantics:
	     sframe_decoder_get_funcdesc_v2;
	     sframe_encoder_add_funcdesc_v2;
	     sframe_encoder_write;

	lisbframe/
		* libsframe.ver: Define new LIBSFRAME_2.0.
		* libtool-version: Bump the 'current' numeral to indicate a binary
		incompatible release.
	include/
		* sframe-api.h (sframe_get_funcdesc_with_addr): Remove
		deprecated interface.
	libsframe/
		* sframe.c (sframe_get_funcdesc_with_addr): Likewise.
	binutils/
		* NEWS: Announce new versioned release of libsframe.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fixup comment and minor style issues
	Also, use ATTRIBUTE_UNUSED consistently.

	libsframe/
		* sframe.c (sframe_encoder_add_funcdesc): Fix function-level
		comment and use ATTRIBUTE_UNUSED consistently.
		(sframe_encoder_add_funcdesc_v2): Use ATTRIBUTE_UNUSED
		consistently.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: elf: binutils: add new section type SHT_GNU_SFRAME
	So far, SFrame sections were of type SHT_PROGBITS.

	As per ELF specification, SHT_PROGBITS indicates that the section holds
	information defined by the program, whose format and meaning are
	determined solely by the program.

	On the linker side, SHT_PROGBITS should be reserved for the simple "cat
	contents after applying relocs" semantics.

	Currently, the only way to know that a section contains SFrame stack
	trace data is if consumer checks for section name.  Such a check for
	section name is not quite conformant to ELF principles.

	Some of this was discussed here
	https://sourceware.org/pipermail/binutils/2025-March/140181.html

	With this change, the SFrame sections generated by gas, ld will have
	section type set to SHT_GNU_SFRAME.   The new section type is defined in
	the SHT_LOOS/SHT_HIOS space.  The SFrame parsing routine
	_bfd_elf_parse_sframe () now admits sections only when the the section
	type is SHT_GNU_SFRAME.

	No special handling / validation is done at the moment for the case of
	manual creation of SFrame sections via obj_elf_section ().  Add function
	level comments for now to add a note about this.

	Although the default handling for (sh_type >= SHT_LOOS && sh_type <=
	SHT_HIOS) is sufficient when SHT_GNU_SFRAME is in that range, it makes
	sense to add it as a case of its own.

	bfd/
		* elf-sframe.c (_bfd_elf_parse_sframe): Check if section type is
		SHT_GNU_SFRAME.
		(_bfd_elf_set_section_sframe): Set SHT_GNU_SFRAME for output
		SFrame section.
		* elflink.c (obj_elf_section): Use section type for check
		instead of section name.
		* elfxx-x86.c: Set SHT_GNU_SFRAME for SFrame sections for
		.plt* sections.
		* elf.c (bfd_section_from_shdr): Add case for SHT_GNU_SFRAME.
	binutils/
		* readelf.c (get_os_specific_section_type_name): Add
		SHT_GNU_SFRAME.
	gas/
		* NEWS: Announce emitted SFrame sections have SHT_GNU_SFRAME
		set.
		* config/obj-elf.c (obj_elf_attach_to_group): Add comments to
		indicate no special handling for SFrame yet.
		* dw2gencfi.c (cfi_finish): Set SHT_GNU_SFRAME for emitted
		SFrame section.
	ld/
		* NEWS: Announce emitted SFrame sections have SHT_GNU_SFRAME
		set.
	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Add new test.
		* gas/cfi-sframe/cfi-sframe-common-1b.d: New test.
		* gas/cfi-sframe/cfi-sframe-common-1b.s: New test.
	include/
		* elf/common.h (SHT_GNU_SFRAME): Add new section type for SFrame
		stack trace information.
	libsframe/doc/
		* sframe-spec.texi: Add expected ELF section type.

2025-07-12  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: guard block with support_sframe_p
	SFrame is generated for ELF targets only.  Guard the block with
	support_sframe_p like others for consistency.

	Also, in a later commit, we would like to do a:
	  elf_section_type (sframe_seg) = SHT_GNU_SFRAME;

	This cannot be done for non-ELF targets, hence the need to guard with
	some pre-processor conditional to enable it for only OBJ_ELF.  Guarding
	with support_sframe_p works for now, because those targets that support
	SFrame define support_sframe_p:
	  - x86_64 and aarch64 define support_sframe_p when OBJ_ELF is defined
	  - s390x has no non-LEF target.

	We continue to issue an error on targets where SFrame is not supported:
	    .sframe not supported for target

	gas/
		* dw2gencfi.c (cfi_finish): Guard with support_sframe_p.
		(support_sframe_p): Remove stub to define to false for backends
		not supporting SFrame.

2025-07-12  WANG Xuerui  <git@xen0n.name>

	{binutils, gas, ld}/NEWS: Announce LoongArch changes in 2.45

2025-07-12  WANG Xuerui  <git@xen0n.name>

	LoongArch: Un-skip cross-segment alignment compensation during relax pass 2
	It turned out wrong to skip compensating for segment alignment if the
	current section is closed for deletion, as my recent system update with
	binutils trunk revealed link failures of many high-profile packages such
	as ffmpeg, numpy and wxGTK -- the dreaded "relocation truncated to fit"
	errors regarding improperly produced R_LARCH_PCREL20_S2.

	As it's near 2.45 branching time, revert the problematic change and
	XFAIL the original test case for now.

	Suggested-by: Xi Ruoyao <xry111@xry111.site>

2025-07-12  Alan Modra  <amodra@gmail.com>

	MIPS: Fix linker for REL TLS HI16/LO16 relocs
	With REL targets TLS HI16/LO16 relocations need to combine the low part
	with the high part just as all the remaining HI16/LO16 relocations, so
	as to determine the borrow in calculation correctly.

	2025-07-12  Alan Modra  <amodra@gmail.com>

	bfd/
		PR 19977
		* elfxx-mips.c (tls_hi16_reloc_p): New function.
		(mips_elf_add_lo16_rel_addend): Handle tls relocs.
		(_bfd_mips_elf_relocate_section): Likewise.

	2025-07-12  Maciej W. Rozycki  <macro@orcam.me.uk>

	ld/
		PR 19977
		* testsuite/ld-mips-elf/pr19977.d: New test.
		* testsuite/ld-mips-elf/pr19977-mips16.d: New test.
		* testsuite/ld-mips-elf/pr19977-micromips.d: New test.
		* testsuite/ld-mips-elf/pr19977-r.d: New test.
		* testsuite/ld-mips-elf/pr19977-r-mips16.d: New test.
		* testsuite/ld-mips-elf/pr19977-r-micromips.d: New test.
		* testsuite/ld-mips-elf/pr19977-r.s: New test source.
		* testsuite/ld-mips-elf/pr19977.ld: New test linker script.
		* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.

2025-07-12  Alan Modra  <amodra@gmail.com>

	MIPS: Correct HI/LO rel reloc howto special_function entries
	This corrects the DTPREL_HI16/LO16 and TPREL_HI16/LO16 howtos to use
	_bfd_mips_elf_{hi,lo}16_reloc special functions, in order to support
	addends outside the range [0,32767] on these relocations.

	R_MIPS_GOT_HI16, R_MIPS_GOT_LO16, R_MIPS_CALL_HI16 and R_MIPS_CALL_LO16
	are left alone as it seems that we (quite reasonably) only support
	zero addends for those relocs.

		PR 19977
	bfd/
		* elf32-mips.c (elf_mips_howto_table_rel): Set special_function
		to _bfd_mips_elf_hi16_reloc for R_MIPS_TLS_DTPREL_HI16 and
		R_MIPS_TLS_TPREL_HI16.  Set special_function to
		_bfd_mips_elf_lo16_reloc for R_MIPS_TLS_DTPREL_LO16 and
		R_MIPS_TLS_TPREL_LO16
		(elf_mips16_howto_table_rel): Likewise for
		R_MIPS16_TLS_DTPREL_HI16, R_MIPS16_TLS_DTPREL_LO16,
		R_MIPS16_TLS_TPREL_HI16 and R_MIPS16_TLS_TPREL_LO16.
		(elf_micromips_howto_table_rel): Likewise for
		R_MICROMIPS_TLS_DTPREL_HI16, R_MICROMIPS_TLS_DTPREL_LO16,
		R_MICROMIPS_TLS_TPREL_HI16 and R_MICROMIPS_TLS_TPREL_LO16.
		* elf64-mips.c (mips_elf64_howto_table_rel): Similarly.
		(mips16_elf64_howto_table_rel): Similarly.
		(micromips_elf64_howto_table_rel): Similarly.
		* elfn32-mips.c: As for elf64-mips.c.
	gas/
		* testsuite/gas/mips/pr19977.d,
		* testsuite/gas/mips/pr19977.s: New test.
		* testsuite/gas/mips/mips.exp: Run it.

2025-07-12  Maciej W. Rozycki  <macro@orcam.me.uk>

	PR 19977: MIPS: Add missing pairing for REL PCHI/PCLO relocations
	Just as with all HI/LO 16-bit partial relocations the newly-introduced
	MIPSr6 PC-relative R_MIPS_PCHI16 and R_MIPS_PCLO16 relocations require
	pairing for correct borrow propagation from the low part to the high
	part with REL targets, another case for PR 19977.

	Unlike with absolute relocation, there is a complication here in that
	both parts represent a calculation that is relative to the PC at the
	individual relocation's location rather than both referring to the
	location of the R_MIPS_PCHI16 relocation, normally applied to an AUIPC
	instruction, the location of which is used for the run-time calculation
	executed by hardware.

	To take this semantics into account, the addend of the R_MIPS_PCLO16
	relocation matching a given R_MIPS_PCHI16 relocation is expected to be
	adjusted in the source assembly file for the distance between the two
	relocations in a single pair, so that once both relocations have been
	calculated by the linker, the expression calculated at run time is such
	as if the combined 32-bit immediate was added at the location of the
	AUIPC instruction.

	So for matching R_MIPS_PCHI16 and R_MIPS_PCLO16 relocations into pairs
	GAS needs to check for the distance between the two relocations to be
	equal to the difference between the addends supplied, and then the
	linker has to subtract the low part of the distance between the two
	relocations from the low part in calculating the high part, so as to
	factor in any borrow.

	A further complication is that `_bfd_mips_elf_lo16_reloc' handler is
	supplied with the addend differently depending on whether it has been
	called by GAS via `bfd_install_relocation', or by the generic linker via
	`bfd_perform_relocation'.  In the former case the addend is supplied
	with the relocation itself while in the latter one it comes from the
	field being relocated.

	We currently ignore the addend supplied with the relocation and it works
	for calculating absolute high-part relocations, because the same addend
	has been previously supplied with them when `_bfd_mips_elf_hi16_reloc'
	was called, however this approach does not work for the PC-relative case
	because as noted above the low-part addend is different and we need to
	consistently apply the distance adjustment both with GAS and LD.

	Since the supplied addend and one retrieved from field being relocated
	won't ever be both nonzero, just use the sum of the two values.

	The low-part addend in `mips_elf_add_lo16_rel_addend' always comes from
	the field being relocated, so there's no complication there, we just
	need to apply the same adjustment.

	New linker test cases verify that the same ultimate machine code is
	produced both for ELF and S-record output formats, ensuring that the
	both the MIPS/ELF linker and the generic linker behave in the correct
	way, consistent with each other.

2025-07-12  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/BFD: Use helper function for LO relocation sign-extension
	A calculation for LO relocations has been recently fixed with commit
	ce08b3bb19b3 ("MIPS/BFD: Fix RELA handling of borrow in the generic
	linker"), however it was missed that for the updated arithmetic we
	already have a helper function available, `_bfd_mips_elf_sign_extend'.

	Replace the open-coded statement then with an equivalent call to said
	function.  No functional change.

2025-07-12  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Remove duplicate HI/LO relocation test dump files
	There are only nonessential differences between corresponding o32 and
	n32 HI/LO relocation test dump files, so reduce the number of files by
	reusing the same dump between the two ABIs.  Adjust test naming, also
	for the n64 ABI, for consistency with other tests.

2025-07-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-11  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: fix PR libsframe/33140
	Commit 0d4d5a2633f missed some necessary adjustments to the testcase
	after rebase.  SFrame FDE function start address data is now an offset
	in PCREL encoding; reflect with a new flag SFRAME_F_FDE_START_ADDR_PCREL
	in the header.

	Adjust the newly added testcase.

	PR libsframe/33140 SFrame test failures on x86-64

	libsframe/testsuite/
		* libsframe.find/plt-findfre-2.c: Adjust for the new FDE func
		start addr encoding.

2025-07-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove two unused includes of gdbcore.h
	clangd claims they are unused.

	Change-Id: I3c5e16279ff3b59679b8262a9d24a6e515a718f5

2025-07-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix formatting in solib.c
	There are many instances of `_ (...)` that should be `_(...)`, fix them.

	Change-Id: I9715019c9b62b72208b4849f3cfd531964480dd2

2025-07-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-svr4: use program space from solib in find_debug_base_for_solib
	Instead of using the current global program space, I think it makes
	sense to fetch the program space from the solib.  The comment for
	solib::objfile indicates that it may be nullptr (which is true), but in
	this case, the callers (all in
	svr4_iterate_over_objfiles_in_search_order) find the solib from an
	objfile, so we know that solib::objfile (the link in the opposite
	direction) is set for these solibs at this point.

	Change-Id: I75037d0b2c39ab1b3a3792432be134e200438efe
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: Add support for more vmov-style instructions
	This commit adds support for a few more vmov instructions:
	* VMOV[LH|HL]PS
	* VMOVLPD
	* VMOVHP[S|D]
	* VMOVDDUP

	And associated tests. The testsuite had some minor re-working, adding a
	function to zero buffers, to make later tests less fragile.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for AVX conversion instructions.
	WIP

	This commit adds support for instructions to convert from one type to
	another, which are in the form:
	* VCVTDQ2[PS|PD]
	* VCVTPS2[DQ|PD]
	* VCVTPD2[PS|DQ]
	* VCVTSD2[SI|SS]
	* VCVTSI2[SS|SD]
	* VCVTSS2[SD|SI]
	* VCVTTP[S|D]2DQ
	* VCVTTS[S|D]2SI

	It also adds support to vpsadbw, since it was trivial and only one
	instruction. Finally, I have slightly reorder the case statements to
	keep them in numerical order.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for 'pack' AVX instructions
	This commit adds support for the following instructions VPACK[S|U]S[WB|DW] and associated tests.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for comis instructions
	This commit adds support for the following instructions:
	* VCOMIS[S|D]
	* VUCOMIS[S|D]

	And associanted tests.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for AVX blend instructions
	This commit supports for the following instructions:
	* VBLENDP[S|D]
	* VBLENDVP[S|D]
	* VPBLEND[D|W|VB]

	and test them.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support to vinsert and vextract instructions
	This patch adds support for the following instructions:
	* VEXTRACT[F128|I128|PS]
	* VINSERT[F128|I128|PS]
	* VPEXTR[B|W|D|Q]

	And associated test. For some reason, it seems that the extract
	instructions deal with the output register as though it was the first
	source register, so they use ModRM.r/m and VEX.B, instead of the usual
	ModRM.reg and VEX.R. This meant that the opcode collision with
	vbroadcastsd wasn't trivial. It can be easily solved by checking the
	VEX.map_select field, so soslving it was very easy.

	The VPEXTR instructions had several complicated collisions, and notably,
	vpextrw to a register works completely different to any other
	instruction in the family, so the code is messy, but it should be
	correct.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for more AVX broadcast instructions
	This commit adds support for 3 instructions:
	* VBROADCASTSS
	* VBROADCASTSD
	* VBROADCASTF128

	and extends the function vpbroadcast_test to include these.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for permutation instructions
	This commit adds recording support for the following instructions:
	* VPERM2[I|F]128
	* VPERM[D|Q|PD|PS]
	* VPERMILP[S|D]

	And associated tests.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for AVX/AVX2 shuffle instructions
	This commit adds support for the following instructions:
	* VPSHUF[B|D|HW|LW]
	* VSHUFP[S|D]

	and the associated test.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: Add support for AVX/AVX2 shift instructions
	This commit adds record-full support to the following instructions:

	* VPSLL[W|D|Q|DQ]
	* VPSRL[W|D|Q|DQ]
	* VPSRA[W|D]

	With both dynamic and constant shifts, and the associated tests.
	Notably, vpsraq is not available for AVX or AVX2 instruction sets, only
	AVX512. vpsradq does not seem to be available with any instruction set.

2025-07-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: support more AVX arithmetic instructions
	This commit adds support to the following AVX/AVX2 instructions:
	* VPADD[B|W|D|Q]
	* VPMUL[LW|LD|HW|HUW|UDQ]
	* VXORP[S|D]
	* VPAND[|N]

	This required some reworking on the loop that processes instruction
	prefixes, because the opcode for VPMULLD overlapped with a valid
	instruction prefix. To fix that, rather than using "goto out_prefixes",
	this commit changes the infinite loop to only run while we don't find
	another VEX prefix. That should be OK, as the intel manual (page 526 on
	the March 2024 edition) says that the VEX prefix is always the last one.

2025-07-11  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_SVE_AES2
	FEAT_SVE_AES2 implements the SVE multi-vector Advanced Encryption
	Standard and 128-bit destination element polynomial multiply long
	instructions, when the PE is not in Streaming SVE mode.

	aarch64: Support for FEAT_LSUI
	FEAT_LSUI introduces unprivileged variants of load and store instructions so
	that clearing PSTATE.PAN is never required in privileged software.

2025-07-11  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_PCDPHINT
	FEAT_PCDPHINT - Producer-consumer data placement hints - is an optional
	ISA extension that provides hint instructions to indicate:
	- a store in the current execution thread is generating data at a specific
	location, which a thread of execution on one or more other observers is
	waiting on.
	- the thread of execution on the current PE will read a location that may not
	yet have been written with the value to be consumed.

	This extension introduces:
	- STSHH, a hint instruction, with operands (policies) keep and strm
	- PRFM *IR*, a new prefetch memory operand.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Announce s390 64-bit (s390x) SFrame V2 support in binutils
	The preceding commits add s390 64-bit (s390x) support in binutils to
	generate SFrame stack trace information (.sframe section) in the
	assembler from CFI directives (with option --gsframe), generate .sframe
	section for linker-generated .plt section in the linker, and dump SFrame
	information in objdump and readelf (with option --sframe).

	binutils/
		* NEWS: Announce s390 64-bit (s390x) SFrame V2 support in
		as, ld, objdump, and readelf.

	gas/
		* NEWS: Update s390 64-bit (s390x) SFrame V2 support in
		assembler.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: sframe: Test handling of .cfi_def_cfa_register
	Port x86-64 test for handling of .cfi_def_cfa_register from commit
	3602da6fa285 ("gas: sframe: fix handling of .cfi_def_cfa_register")
	to s390x.

	gas/testsuite/
		PR gas/32879
		* gas/cfi-sframe/cfi-sframe.exp: Add new test for handling of
		.cfi_def_cfa_register on s390x.
		* gas/cfi-sframe/cfi-sframe-s390x-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-3.s: Likewise.

	Bug: https://sourceware.org/PR32879

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Store SFrame CFA offset adjusted and scaled down
	In SFrame V2 the size of the offsets following an SFrame FRE can be
	either signed 8-bit, 16-bit, or 32-bit integer, with the largest offset
	determining their size:
	  1. CFA offset from CFA base register
	  2. RA (stack save slot) offset from CFA, usually -48 on s390x if saved
	  3. FP (stack save slot) offset from CFA, usually -72 on s390x if saved
	The FP and RA offsets from CFA, when FP/RA saved on the stack, usually
	have fixed values that fit into signed 8-bit SFrame offsets.  Likewise
	the DWARF register numbers on s390x of general registers (GR; 0-15) and
	floating-point registers (FPR; 16-31), when FP/RA saved in registers.
	With that the CFA offset from CFA base register has the greatest impact
	on the signed SFrame offset size.

	The s390x ELF ABI defines the stack pointer (SP) to be 8-byte aligned
	[1] and the CFA as SP at call site + 160 [2].  The CFA offset from CFA
	base register is therefore always a multiple of 8.

	On s390x store the SFrame CFA offset from CFA base register scaled down
	by the s390x-specific CFA alignment factor of 8, in addition to the
	adjustment by the s390x-specific CFA adjustment of -160, to further
	improve the use of signed 8-bit SFrame offsets.  This is similar to the
	DWARF data alignment factor getting factored out from certain offsets
	stored in DWARF CFI.

	[1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame
	     Allocation", https://github.com/IBM/s390x-abi/releases
	[2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
	     https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88

	include/
		* sframe.h (SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR): Define
		s390x-specific CFA offset alignment factor.
		(SFRAME_V2_S390X_CFA_OFFSET_ENCODE,
		SFRAME_V2_S390X_CFA_OFFSET_DECODE): Scale down/up by
		SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR.

	libsframe/
		* doc/sframe-spec.texi (s390x,
		SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR): Document s390x-
		specific CFA offset alignment factor.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Store SFrame CFA offset adjusted
	In SFrame V2 the size of the offsets following an SFrame FRE can be
	either signed 8-bit, 16-bit, or 32-bit integer, with the largest offset
	determining their size:
	  1. CFA offset from CFA base register
	  2. RA (stack save slot) offset from CFA, usually -48 on s390x if saved
	  3. FP (stack save slot) offset from CFA, usually -72 on s390x if saved
	The FP and RA offsets from CFA, when FP/RA saved on the stack, usually
	have fixed values that fit into signed 8-bit SFrame offsets.  Likewise
	the DWARF register numbers on s390x of general registers (GR; 0-15) and
	floating-point registers (FPR; 16-31), when FP/RA saved in registers.
	With that the CFA offset from CFA base register has the greatest impact
	on the signed SFrame offset size.

	The s390x ELF ABI [1] defines the CFA as stack pointer (SP) at call
	site +160. [2]  Therefore the minimum CFA offset from CFA base register
	on s390x is 160.  This does not fit into a signed 8-bit integer and
	therefore effectively prevents any use of signed 8-bit SFrame offsets
	on s390x.

	For s390x store the CFA offset from CFA base register adjusted by -160
	to enable the use of signed 8-bit SFrame offsets.

	[1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases
	[2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
	     https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88

	include/
		* sframe.h (SFRAME_S390X_CFA_OFFSET_ADJUSTMENT): Define
		s390x-specific CFA offset adjustment.
		(SFRAME_V2_S390X_CFA_OFFSET_ENCODE,
		SFRAME_V2_S390X_CFA_OFFSET_DECODE): New s390x-specific
		macros.  Use SFRAME_S390X_CFA_OFFSET_ADJUSTMENT to en-/decode
		CFA offset.

	bfd/
		* elf64-s390.c (elf_s390x_sframe_plt_fre): Use
		SFRAME_V2_S390X_CFA_OFFSET_ENCODE on CFA offset to store it
		adjusted and switch to 8-bit offsets.

	gas/
		* gen-sframe.c (sframe_fre_set_cfa_offset): For s390x use
		SFRAME_V2_S390X_CFA_OFFSET_ENCODE on CFA offset to store it
		adjusted.
		(sframe_fre_get_cfa_offset): New helper.  For s390x use
		SFRAME_V2_S390X_CFA_OFFSET_DECODE on CFA offset to undo its
		adjustment.
		(sframe_xlate_do_def_cfa_register): Use new helper
		sframe_fre_get_cfa_offset.

	libsframe/
		* sframe.c (sframe_fre_get_cfa_offset): For s390x use
		SFRAME_V2_S390X_CFA_OFFSET_DECODE on CFA offset to undo its
		adjustment.
		* doc/sframe-spec.texi (s390x,
		SFRAME_S390X_CFA_OFFSET_ADJUSTMENT,
		SFRAME_V2_S390X_CFA_OFFSET_ENCODE,
		SFRAME_V2_S390X_CFA_OFFSET_DECODE): Document s390x-specific
		adjustment of CFA offset.

	libsframe/testsuite/
		* libsframe.find/plt-findfre-2.c (add_plt0_fde, add_pltn_fde):
		Use SFRAME_V2_S390X_CFA_OFFSET_ENCODE to enable use of 1-byte
		SFrame offsets.

	Suggested-by: Indu Bhagat <indu.bhagat@oracle.com>

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	libsframe: Add test for PLT0 and PLTN with only one FRE each
	On s390x the PLT0 and PLTN entries are described with one SFrame FRE
	each.  Add a test case for this particularity.

	libsframe/testsuite/
		* libsframe.find/find.exp (plt-findfre-2): Add new test.
		* libsframe.find/plt-findfre-2.c: New test for PLT0 and PLTN
		with only one FRE each.
		* libsframe.find/local.mk (plt-findfre-2): Add new test.

	libsframe/
		* Makefile.in: Regenerate.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Add SFrame stack trace information for .plt section
	Enable SFrame stack tracing through PLT entries.  Based on x86-64.

	On s390x both PLT0 and PLTn entries are 32-bytes in size.  Their code
	neither alters the stack pointer (SP), frame pointer (FP), nor return
	address (RA) registers.  Therefore the PLT0 can be represented using
	a SFrame FDE of type PCINC with a single SFrame FRE and the PLTn can
	be represented using a SFrame FDE of type PCMASK, with a repetition
	block size of 32 (PLTn size), and a single SFrame FRE.

	Note that as both the PLT0 entry and the PLTn entries have equal size
	and could both be represented using the identical SFrame FRE, the whole
	.plt section on s390x could be represented using a single SFrame FDE of
	type PCMASK, with a repetition block size of 32 (PLT0 and PLTn size),
	and a single SFrame FRE.  Keep the x86-64 logic with separate SFrame
	FDEs for PLT0 and PLTn, to ease potential generalization of the .sframe
	for .plt generation logic among architectures.

	bfd/
		* elf64-s390.c: Include sframe.h and sframe-api.h.
		(PLT_SFRAME_FDE_START_OFFSET, SFRAME_PLT0_MAX_NUM_FRES,
		SFRAME_PLTN_MAX_NUM_FRES, elf_s390x_sframe_plt_fre,
		elf_s390x_sframe_plt): New .sframe template for .plt section.
		(elf_s390_link_hash_table): Add plt_cfe_ctx, plt_sframe, and
		sframe_plt fields.
		(_bfd_s390_elf_create_sframe_plt): New function.  Fill in
		.sframe section for .plt section.
		(_bfd_s390_elf_write_sframe_plt): New function.  Write .sframe
		section.
		(elf_s390_create_dynamic_sections): Create .sframe section for
		.plt section.
		(elf_s390_late_size_sections): Call
		_bfd_s390_elf_create_sframe_plt and
		_bfd_s390_elf_write_sframe_plt.
		(elf_s390_finish_dynamic_sections): Write .plt section start
		into .sframe FDE covering .plt section.  Call
		_bfd_elf_merge_section_sframe on htab->plt_sframe.

	ld/
		* NEWS: Add news entry.

	ld/testsuite/
		* ld-s390/s390.exp: Add new test.
		* ld-s390/sframe-plt-1.d: New linker-generated .sframe for .plt
		test.
		* ld-s390/sframe-simple-1.d: Adjust expected test output due to
		linker-generated .sframe for .plt.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Represent FP without RA saved in SFrame
	If an architecture uses both SFrame RA and FP tracking SFrame assumes
	that the RA offset is the 2nd offset and the FP offset is the 3rd offset
	following a SFrame FRE.  An architecture does not necessarily need to
	save both on the stack (or in register) at the same time or even at all.
	SFrame cannot represent FP without RA saved on stack (or in a register),
	since it cannot distinguish whether the 2nd offset is the RA or FP
	offset.

	For s390x use an invalid SFrame RA offset from CFA value of zero as
	padding to represent the FP being saved when the RA is not saved.  This
	aligns with the existing invalid SFrame fixed RA offset from CFA value
	of zero.  In a stack tracer this then also naturally falls into place,
	as it can skip restoring the RA in the topmost frame, if both the fixed
	RA offset (from SFrame header) and the RA offset (from FDE) are zero,
	without any need to test architecture-specific flags.

	include/
		* sframe.h (SFRAME_FRE_RA_OFFSET_INVALID): New define.  Used as
		padding offset.
		* sframe-api.h (sframe_fre_get_ra_offset): Add comment that for
		s390x an offset value of SFRAME_FRE_RA_OFFSET_INVALID indicates
		that the RA is not saved.

	gas/
		* gen-sframe.c (get_fre_num_offsets): For s390x account padding
		RA offset, if FP without RA saved.
		(sframe_get_fre_offset_size): Likewise.
		(output_sframe_row_entry): For s390x write a padding RA offset,
		if FP without RA needs to be represented.
		(sframe_do_fde): Enable FP without RA saved to be represented
		on s390x.

	libsframe/
		* sframe.c (sframe_fre_get_ra_offset): Add comment that for
		s390x an offset value of SFRAME_FRE_RA_OFFSET_INVALID indicates
		that the RA is not saved.
		* sframe-dump.c (dump_sframe_func_with_fres): Treat invalid
		RA offsets as if they were undefined.  Display them as "U"
		to distinguish them.
		* doc/sframe-spec.texi (s390x): Document s390x-specific use of
		SFRAME_FRE_RA_OFFSET_INVALID to represent FP without RA saved.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Rename s390x-specific tests.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.s: Rename
		to ...
		* cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-2.s: This.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-2.d: Likewise.
		Update test verification pattern accordingly.
		* cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.s: Rename
		to ...
		* cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-2.s: This.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-2.d: Likewise.
		Update test verification pattern accordingly.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Represent FP/RA saved in register in SFrame
	GCC on s390x, when in a leaf function, can be observed to save the
	frame pointer (FP) and/or return address (RA) register in a floating-
	point registers (FPR) instead of on the stack.  This is declared using
	the following CFI directive:

	  .cfi_register <fp/ra-regnum>, <fpr-regnum>

	SFrame cannot represent the FP and/or RA being saved in another
	register.  It does only track the CFA base register (SP/FP), CFA offset
	from CFA base register, and FP and RA save area offsets from CFA.

	On s390x the FP and/or RA are only saved in another FPR when in a leaf
	function.  That is a function that does not call any other function.
	Therefore it can ever only be the topmost function in a call chain.
	An unwinder by default has access to all registers of the function that
	is the topmost on the call stack.  Therefore no further information
	is required to restore FP/RA from the FPR.

	Represent FP/RA saved in another register on s390x, by encoding the
	DWARF register number shifted by one to the left with the least-
	significant bit set in the offset as follows:

	  offset = (regnum << 1) | 1

	The use of the least-significant bit of the offset as indication is
	possible, as the stack pointer (SP), the CFA, and any register save
	area slots are 8-byte aligned according to the s390x ELF ABI:
	- The stack pointer (SP) "shall maintain an 8-byte alignment". [1]
	- The CFA is defined as SP at call site +160. [2]
	- Pointers and 8-byte integers, such as general register values, must
	  be 8-byte aligned. [3]
	SFrame FP and RA stack offsets must therefore always be a multiple of
	8 on s390x.  Note that for the same reason the DWARF data alignment
	factor is -8 on s390x (see DWARF2_CIE_DATA_ALIGNMENT).

	Add s390x-specific SFrame (error) tests for FP/RA saved in FPRs in leaf
	function.

	[1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame
	     Allocation", https://github.com/IBM/s390x-abi/releases
	[2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
	     https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88
	[3]: s390x ELF ABI, section "Fundamental Types", table "Scalar types",
	     https://github.com/IBM/s390x-abi/releases

	include/
		* sframe.h (SFRAME_V2_S390X_OFFSET_IS_REGNUM): New s390x-
		specific macro to test whether an SFrame FP/RA offset is a DWARF
		register number.
		(SFRAME_V2_S390X_OFFSET_ENCODE_REGNUM): New s390x-specific macro
		to encode a DWARF register number into an SFrame FP/RA offset.
		(SFRAME_V2_S390X_OFFSET_DECODE_REGNUM): New s390x-specific macro
		to decode an SFrame FP/RA offset into a DWARF register number.
		* sframe-api.h (sframe_fre_get_fp_offset,
		sframe_fre_get_fp_offset): Add comment that for s390x the offset
		may be an encoded register number.

	gas/
		* gen-sframe.c (s390_sframe_xlate_do_register): New S390-
		specific function.  Uses SFRAME_V2_S390X_OFFSET_ENCODE_REGNUM to
		represent FP/RA saved in another register on s390x.
		(sframe_xlate_do_register): Invoke s390_sframe_xlate_do_register
		on s390x.

	libsframe/
		* sframe.c (sframe_fre_get_fp_offset, sframe_fre_get_fp_offset):
		Add comment that for s390x the offset may be an encoded register
		number.
		* sframe-dump.c (is_sframe_abi_arch_s390x): New helper to test
		whether ABI/arch is s390x.
		(dump_sframe_func_with_fres): Use
		SFRAME_V2_S390X_OFFSET_IS_REGNUM and
		SFRAME_V2_S390X_OFFSET_DECODE_REGNUM to dump FP/RA saved in
		another register on s390x.
		* doc/sframe-spec.texi (s390x): Document s390x-specific
		representation of FP/RA saved in another register.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Update s390x-specific SFrame
		(error) tests.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.s: Rename
		to ...
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.d:
		Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-1.s: This.  Test
		no longer triggers a warning, as SFrame can represent FP and RA
		saved in registers.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: Test
		now triggers a different warning, as SFrame can represent FP and
		RA saved in registers, but not FP without RA saved in register.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Initial support to generate .sframe from CFI directives in assembler
	This introduces initial support to generate .sframe from CFI directives
	in assembler on s390 64-bit (s390x).  Due to SFrame V2 format
	limitations it has the following limitations, some of them getting
	addressed by subsequent patches, which cause generation of SFrame FDE
	to be skipped:

	- SFrame FP/RA tracking only supports register contents being saved on
	  the stack (i.e. .cfi_offset).  It does not support FP/RA register
	  contents being saved in other registers (i.e. .cfi_register).  GCC on
	  s390x can be observed to save the FP/RA register contents in floating-
	  point registers, but only in leaf functions.
	  This issue is detailed further and resolved in the subsequent commit
	  "s390: Represent FP/RA saved in register in SFrame".

	- SFrame FP/RA tracking cannot represent FP without RA saved.  This is
	  because the format assumes SFrame FDE offset2 to be the RA offset, if
	  there are two offsets, and offset3 to be the FP offset, if there are
	  three offsets.  There is no mean to distinguish whether offset2 is the
	  RA or FP offset, if there are only two offsets.
	  This issue is detailed further and resolved in the subsequent commit
	  "s390: Represent FP without RA saved in SFrame".

	- SFrame assumes a dedicated FP register number.  The s390x ELF ABI [1]
	  does only designate register 11 as preferred FP register number.  In
	  general GCC and Clang on s390x use register 11 as frame pointer.
	  GCC on s390x can be observed to use register 14 as frame pointer in
	  the stack clash protector in the function prologue.
	  glibc on s390x contains hand-written assembler code that uses
	  register 12 as frame pointer.

	This s390x support is largely based on the AArch64 support from commit
	b52c4ee46657 ("gas: generate .sframe from CFI directives").

	The SFrame ABI/arch identifier SFRAME_ABI_S390X_ENDIAN_BIG is introduced
	for s390x and added to the SFrame format specification.

	The s390x ELF ABI [1] specifies the following C calling conventions for
	s390x architecture:
	- Register 15 is the stack pointer (SP).
	- Register 14 contains the return address (RA) at function entry.
	- There is no dedicated frame pointer register.  Register 11 is the
	  preferred frame pointer (FP). [2]  GCC and Clang in general use
	  register 11 as frame pointer.
	- The CFA is defined as SP at call site +160. [3]  The SP at call site
	  can therefore be derived from the CFA using a SP value offset from CFA
	  of -160.

	The s390x ELF ABI [1] does not assign any standard save slot to each
	register in the register save area of a stack frame.  Neither the
	return address (RA, r14) nor preferred frame pointer (FP, r11)
	necessarily need to be saved.  Therefore SFrame RA and FP tracking is
	used.

	Support for SFrame on s390 is only enabled for the 64-bit s390x ELF ABI
	(z/Architecture with 64-bit addressing mode).  It is disabled for the
	32-bit s390 ELF ABI (ESA/390 or z/Architecture with 32-bit addressing
	mode).

	s390x-specific SFrame assembler and linker tests are added, including
	error tests for use of a non-preferred frame pointer (FP) register and
	specification of a non-default return address (RA) register.

	[1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases
	[2]: s390x ELF ABI, commit f00421825979 ("Add information about the frame
	     pointer register"),
	     https://github.com/IBM/s390x-abi/commit/f00421825979
	[3]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
	     https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88

	include/
		* sframe.h: Add reference to s390x architecture in comments.
		(SFRAME_ABI_S390X_ENDIAN_BIG): Define SFrame ABI/arch identifier
		for s390x.
		(SFRAME_S390X_SP_VAL_OFFSET): Define s390x-specific SP value
		offset from CFA.

	libsframe/
		* sframe.c (need_swapping): Add SFRAME_ABI_S390X_ENDIAN_BIG.
		* doc/sframe-spec.texi (SFRAME_ABI_S390X_ENDIAN_BIG, s390x,
		SFRAME_S390X_SP_VAL_OFFSET): Document SFrame ABI/arch identifier
		for s390x, add references to s390x architecture, and document
		s390x-specifics, such as the SP value offset from CFA of -160.

	gas/
		* config/tc-s390.h: s390x support to generate .sframe from CFI
		directives in assembler.
		(support_sframe_p): Define.
		(SFRAME_CFA_SP_REG, SFRAME_CFA_FP_REG, SFRAME_CFA_RA_REG):
		Define.
		(sframe_ra_tracking_p): Define.
		(sframe_cfa_ra_offset): Define.
		(sframe_get_abi_arch): Define.
		* config/tc-s390.c: s390x support to generate .sframe from CFI
		directives in assembler.
		(s390_sframe_cfa_sp_reg, s390_sframe_cfa_fp_reg,
		s390_sframe_cfa_ra_reg): New.  Initialize to DWARF register
		numbers of stack pointer (SP, r15), preferred frame pointer
		(FP, r11), and return address (RA, r14) registers.
		(s390_support_sframe_p): New function.  Return true if s390x.
		(s390_sframe_ra_tracking_p): New function.  Return true.
		(s390_sframe_cfa_ra_offset): New function.  Return
		SFRAME_CFA_FIXED_RA_INVALID.
		(s390_sframe_get_abi_arch): New function.  Return
		SFRAME_ABI_S390X_ENDIAN_BIG if s390x, otherwise zero.
		* gen-sframe.c: Add reference to s390x architecture in comments.
		(sframe_xlate_do_val_offset): Add support for s390x-specific
		SFRAME_S390X_SP_VAL_OFFSET.
		* NEWS: Add news entry.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Enable common SFrame tests for
		s390x.  Add s390x-specific SFrame (error) tests.
		* gas/cfi-sframe/cfi-sframe-s390x-1.d: New s390x-specific SFrame
		test.
		* gas/cfi-sframe/cfi-sframe-s390x-1.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-2.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-err-1.d: New s390x-specific
		SFrame error test that uses a non-default frame-pointer register
		as CFA base register.
		* gas/cfi-sframe/cfi-sframe-s390x-err-1.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-err-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-err-2.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-err-3.d: New s390x-specific
		SFrame error test that uses a non-default return address
		register.
		* gas/cfi-sframe/cfi-sframe-s390x-err-3.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-1.d: New s390x-
		specific SFrame test that saves RA and FP individually on the
		stack.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-1.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.d: New
		s390x-specific SFrame error test that saves FP and RA
		individually, to trigger FP without RA saved.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.s: Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: New
		s390x-specific SFrame error test that saves FP and RA
		individually in registers.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.s:
		Likewise.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.d: New
		s390x-specific SFrame error test that saves RA and FP
		individually in registers.
		* gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.s:
		Likewise.

	ld/testsuite/
		* ld-s390/s390.exp: Add simple SFrame test.
		* ld-s390/sframe-simple-1.d: New simple SFrame test.
		* ld-s390/sframe-bar.s: Likewise.
		* ld-s390/sframe-foo.s: Likewise.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	s390: Explicitly list linker dump tests
	Generating the linker dump test list using file globbing makes it
	difficult to exclude specific tests under certain circumstances.  List
	them explicitly instead.  This enables to add tests in the future that
	can be excluded.  While at it reorganize how s390 linker tests get
	run for s390x.

	ld/testsuite/
		* ld-s390/s390.exp: Reorganize and explicitly list linker dump
		tests.

2025-07-11  Jens Remus  <jremus@linux.ibm.com>

	sframe: Ignore section padding when converting endianness
	The .sframe section may have a trailing padding due to the architecture-
	specific default section alignment.  Do not treat this padding as error
	when converting between target and host endianness.

	This can be observed when building Binutils with SFrame s390x support on
	x86-64 for s390x using configure option "--target=s390x-ibm-linux-gnu"
	and running the GAS test suite.

	While at it reuse the determined SFrame section header size.

	libsframe/
		* sframe.c (flip_sframe): Ignore .sframe section padding.  Reuse
		SFrame header size.

	Reported-by: Indu Bhagat <indu.bhagat@oracle.com>

2025-07-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-10  Alan Modra  <amodra@gmail.com>

	AM_PO_SUBDIRS
	Swap AM_PO_SUBDIRS and ZW_GNU_GETTEXT_SISTER_DIR lines in
	*/configure.ac.  ZW_GNU_GETTEXT_SISTER_DIR indirectly invokes
	AC_REQUIRE(AM_PO_SUBDIRS) so results in AM_PO_SUBDIRS being emitted
	before ZW_GNU_GETTEXT_SISTER_DIR if it hasn't already been invoked.

2025-07-10  Alan Modra  <amodra@gmail.com>

	gas v850 md_convert_frag
	The v850 md_convert_frag function oddly calls subseg_change twice
	(commit 1cd986c58543).  Neither call is needed, because that is done
	in size_seg.

	Convert the fr_opcode fixup field back (to an opindex, not fx_r_type)
	using a cast rather than a union, since we used casts when setting up
	those values.  I guess the union was added to silence compiler
	warnings about wrong-size casts, but unfortunately results in the
	wrong value being retrieved on big-endian hosts.

	Change "buffer" to a char* as there is no need to make it an
	unsigned char*, and that way requires fewer casts.  Finally, fix
	formatting and use uintptr_t when make the rs_machine_dependent frags.

	Remove subseg_change calls from cr16, crx, mn10200, mn10300, and sh
	md_convert_frag too.

2025-07-10  Alan Modra  <amodra@gmail.com>

	union alpha_macro_arg
	Rename the old enum alpha_macro_arg to alpha_macro_argset, and create
	a union alpha_macro_arg to use in all the alpha_macro.emit functions.
	This avoids intptr_t casts on retrieving index values and void* casts
	on storing them in the alpha_macros array.

2025-07-10  Nelson Chu  <nelson@rivosinc.com>

	sim: riscv: Fix build issue due to INSN_CLASS_C was changed to INSN_CLASS_ZCA

2025-07-10  Matthieu Longo  <matthieu.longo@arm.com>

	libiberty: sync with gcc
	Import the following commits from GCC as of r16-2170-g2f2e9bcfb0fd9c:
		0fd98b6f9f2 libiberty: add routines to handle type-sensitive doubly linked lists

2025-07-10  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Fixed wrong imply result for zce when -march=rv32id_zce
	The entry of "zce imply zcf" needs check_implicit_for_zcf, so it needs to be
	placed after the entries of "whatever imply f".  Otherwise the implicit zcf
	may be missed.  Also merge the march-implu-zce* testcases into imply testcases.

2025-07-10  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Clarify the imply rule of c
	This also fix the imply result for .option rvc.

	Imply zcf when c and f and rv32
	Imply zcd when c and d
	Imply zca when c

	Changed INSN_CLASS_C to INSN_CLASS_ZCA
	Changed INSN_CLASS_F_AND_C to INSN_CLASS_ZCF
	Changed INSN_CLASS_D_AND_C to INSN_CLASS_ZCD
	Changed INSN_CLASS_ZIHINTNTL_AND_C to INSN_CLASS_ZIHINTNTL_AND_ZCA

2025-07-10  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Deprecate ".option arch, -ext" for users due to its controversial use
	Before we figure out the whole remove situations for ".option arch, -ext", and
	have any RISC-V public spec defines it, we should just deprecate it.

2025-07-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-09  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: ld: sframe: add new internal header
	for SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS.

	The intention of creating an abstraction like
	SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS is to address the concern that there
	should be a central place to enforce harmonious flags between GNU as and
	ld.  At the moment, the only flag that needs to be enforced is
	SFRAME_F_FDE_FUNC_START_PCREL.

	sframe.h and sframe-api.h are installed headers by libsframe for the
	specification and implementation respectively.  Adding a definition like
	SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS does not fit in either.  Create a
	new internal header instead to keep the definition uncoupled from
	sframe.h and sframe-api.h.  Rename the previously added
	SFRAME_F_LD_MUSTHAVE_FLAGS to define the new
	SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS.

	bfd/
		* elf-sframe.c (_bfd_elf_merge_section_sframe): Use the new
		internal header and SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS.
	gas/
		* gen-sframe.c (output_sframe_internal): Likewise.
	include/
		* sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): Move from..
		* sframe-internal.h: ..to here.  New file.

2025-07-09  Alan Modra  <amodra@gmail.com>

	Merge init_private_section_data with copy_private_section_data
	init_private_section_data is used by the linker and is a special case
	of copy_private_section_data that copies a reduced set of section data
	from input to output.  Merge the two functions, adding a link_info
	param to copy_private_section_data and remove init_private_section_data.

	gas remove assorted unnecessary casts
	This continues the saga of removing unnecessary casts, and making
	small code tidies in gas.  Hopefully this sees the last of K&R
	anachronisms.

	gas standardise md_section_align
	The point here is that when valueT is 64 bits and int is 32 bits,
	1 << align doesn't work for shifts larger than the size of int.  (Not
	that anyone is likely to use such large alignments in real code.)

	gas function arg casts
	This patch removes more unnecessary arg casts in various function
	calls.

	gas fixups
	Remove unnecessary arg casts in fix_new and similar calls.

	gas char/unsigned char casts
	This patch removes many unneeded casts to char or unsigned char.  It's
	worth noting that safe-ctype.h macros ISDIGIT and the like cope with
	either signed or unsigned char.
	In some cases a cast to unsigned char is replaced by anding with 0xff,
	which accomplishes the same thing but doesn't rely on char being eight
	bits.  The patch also removes pointer casts, and a few unsigned char
	pointer variables.

	gas alpha sign extension macros
	Use standard sign extend and range checking using unsigned
	expressions that don't rely on implementation defined right shifts or
	size of short and int.

2025-07-09  Alan Modra  <amodra@gmail.com>

	gas md_number_to_chars
	Calls to md_number_to_chars don't need to cast their value arg (*).
	Remove those casts.  avr_output_property_recode made a call to
	md_number_to_chars with size of 1.  Simplify that.  tc-bpf.c
	md_convert_frag used write_insn_bytes that simply copied input to
	output.  Dispense with that nonsense, and similarly in a couple of
	other places where md_number_to_chars was called with size 1.

	*) unless the value arg is an expression that needs a cast, eg. tic54x
	   emit_insn where the shift left could trigger signed overflow UB
	   without a cast.

2025-07-09  Alan Modra  <amodra@gmail.com>

	z8k opcode_entry_type
	z8k opcode_entry_type.func is never used as a function pointer, only
	as a pointer to a pseudo_typeS.  Change it to a void*.

	gas various other void* casts
	This removes assorted unneeded casts of void* pointers, and casts when
	passing args to void* parameters or storing to void* pointers.  The
	patch also changes obj-coff.c stack_push to take a void* parameter,
	and replaces an odd memcpy in tc-metag.c find_insn_templates with a
	simple assignment.

	gas various other const pointer changes
	This removes a bunch of casts involving const pointers, in some cases
	by making variables const pointers so a cast is not needed.  In a
	couple of places the cast hid errors with "&array" written rather than
	"array", see iq2000_macro_defs and s_pru_align.  tc-xgate.c cmp_opcode
	is changed to be the standard qsort predicate to avoid a function
	cast.

	gas d30v_insn plus other non-const pointers
	d30v has a bunch of casts that are only needed due to various types
	missing a const.  Fix that.

	gas alloc casts
	All of the various memory allocation function return a "void *"
	pointer, which needs no cast to assign to other pointer types.

	gas bfd_put and bfd_get arg casts
	bfd_{h_,}put_* and bfd_{h_,}get_* have "void *" pointer params
	nowadays.  We don't need casts on their pointer args.  We also don't
	need to cast values passed to bfd_put.

	gas NULL casts
	This removes many unnecessary NULL casts.  I'm also adding a few arg
	casts in concat calls, to make the code consistent.  Advice from quite
	a few years ago was that it's better to use the exact type for args
	corresponding to function ellipses, in case NULL is defined as plain
	0.  (I think that happened with some early 64-bit systems.  Plain NULL
	ought to be OK nowadays.)

	gas s3_FAIL and s7_FAIL
	s3_FAIL is defined as 0x80000000 which is unsigned, but everywhere it
	is used it is cast to int.  Get rid of that silliness, and likewise
	for s7_FAIL.

	gas more enum casts
	Remove more unnecessary enum casts.

	gas bfd_reloc_code_real_type
	Enumeration constants are integer types, so there should be no need to
	cast such constants to int in expressions.  (Perhaps some older gccs
	warned, I checked back to gcc-4.5.)  Remove some of those unnecessary
	casts.  Also remove unnecessary casts to bfd_reloc_code_real_type.

	gas add_ecoff_symbol
		* ecoff.c: Remove unnecessary arg casts in add_ecoff_symbol
		calls throughout file.

2025-07-09  Alan Modra  <amodra@gmail.com>

	gas frag_var
	Many frag_var calls have unnecessary casts on arguments, no doubt from
	the days when binutils was written for K&R C.  (ie. functions were not
	prototyped so you needed to cast anything that didn't match the
	expected type after default promotions, as you still do for args
	matching a function ellipsis.)  Remove those casts.

		* config/tc-alpha.c (s_alpha_comm): Use offset_T for cur_size
		to avoid need for casts.  Remove casts from frag_var args.
		* config/tc-ia64.c (obj_elf_vms_common): Remove casts from
		frag_var args.
		* config/tc-m32r.c (m32r_scomm): Likewise.
		* config/tc-m68hc11.c (build_jump_insn): Likewise.
		(build_dbranch_insn): Likewise.
		* config/tc-m68k.c (md_assemble): Likewise.
		* config/tc-microblaze.c (microblaze_s_lcomm): Likewise.
		* config/tc-mmix.c (s_loc): Likewise.
		* config/tc-ppc.c (ppc_elf_lcomm, ppc_comm): Likewise.
		* config/tc-score.c (s3_s_score_lcomm): Likewise.
		* config/tc-score7.c (s7_s_score_lcomm): Likewise.
		* config/tc-sh.c (sh_cons_align): Likewise.
		* config/tc-sparc.c (s_reserve, s_common): Likewise.
		(sparc_cons_align): Likewise.
		* config/tc-tic4x.c (tic4x_seg_alloc, tic4x_bss): Likewise.
		* config/tc-tic54x.c (tic54x_bss, tic54x_space): Likewise.
		(tic54x_usect, tic54x_field): Likewise.
		* config/tc-tic6x.c (s_tic6x_scomm): Likewise.
		* config/tc-v850.c (v850_offset, v850_comm): Likewise.
		* frags.c (frag_align, frag_align_pattern, frag_align_code): Likewise.
		* gen-sframe.c (output_sframe_row_entry): Likewise.
		(output_sframe_funcdesc): Likewise.
		* read.c (s_fill, do_org, s_space, emit_leb128_expr): Likewise.
		* symbols.c (colon)): Likewise.

2025-07-09  Alan Modra  <amodra@gmail.com>

	gas pointer to int and vice versa
	Use "intptr_t" or "uintptr_t" for these conversions, not "long" which
	is wrong on LLP64 systems, or "size_t" which is better but still not
	the correct type.

		* config/tc-alpha.c (emit_ldXu, emit_ldX, emit_uldXu, emit_uldX),
		(emit_stX, emit_ustX, emit_sextX): Use correct type when
		converting vlgsize pointer to in.  Use "int" rather than
		"long" for result.
		* config/tc-ia64.c (generate_unwind_image): Use intptr_t cast
		when passing personality_routine to frag_var.
		* config/tc-ppc.c (ppc_frob_symbol <coff>): Use uintptr_t cast
		when converting symbol pointer to valueT.
		* config/tc-v850.c (md_assemble): Use intptr_t cast when
		loading integer opindex.

2025-07-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-08  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Add support for FEAT_SVE2p2 and FEAT_SME2p2

	aarch64: Reorder virtual feature dependencies
	This will improve readability when more combinations of "SVE* or SME*"
	are added.

2025-07-08  First Last  <ghodawalaaman2@disroot.org>

	gdb/reverse: Add 2 AVX instructions VADDSUBPS and VADDSUBPD
	add support to recording 2 missing AVX instructions: vaddsubps and vaddsubpd, and add associated tests.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-07-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: support external debug info
	Use bfd_follow_gnu_debuglink() and bfd_follow_gnu_debugaltlink() to find files
	with debug info.
	If necessary, gprofng-archive copies these files to EXP/archives.

	For each executable, gprofng creates the Elf class twice.
	One of them was a memory leak.
	Fixed this by adding a new argument to Stabs::Stabs().

	gprofng/ChangeLog
	2025-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32147
		PR 30194
		* src/Disasm.cc (get_funcname_in_plt): Use the executable file instead
		of the debug information file.
		* src/Dwarf.h: Define debug_alt_strSec.
		* src/DwarfLib.cc: Add support for DW_FORM_GNU_ref_alt,
		DW_FORM_GNU_strp_alt.
		* src/Elf.h (find_gnu_debug_files, get_dwr_section): New functions.
		* src/Elf.cc: Likewise.
		* src/Experiment.cc (copy_file): Add the const qualifier.
		* src/Experiment.h: Likewise.
		* src/LoadObject.cc (get_elf, openDebugInfo): Find files with debug info.
		* src/LoadObject.h: Remove unused variables.
		* src/Module.cc: Remove an argument in openDebugInfo().
		* src/Stabs.cc (Stabs::Stabs): Add the Elf* argument.
		* src/Stabs.h: Likewise.
		* src/gp-archive.cc: Archive files with debug info.
		* src/gp-archive.h (archive_file): New function.

2025-07-08  Tom Tromey  <tromey@adacore.com>

	Fix wchar.exp test case per review
	A recent patch of mine modified wchar.exp, but I failed to notice one
	part of the review.  This patch updates the code to conform to the
	review comments.

2025-07-08  Nick Clifton  <nickc@redhat.com>

	New Malay translation for bfd/ and new Spanish translation for gas/

2025-07-08  Mark Goncharov  <mark.goncharov@syntacore.com>

	RISC-V: Fix libpath_suffix selection for ldscript
	When building a cross-compiler ld for RISC-V Linux systems, you can specify
	target=riscv64*-linux* to create a linker that supports both 32-bit
	(-march=rv32*) and 64-bit (-march=rv64*) architectures.  The specified -march
	value populates the EMULATION_NAME variable, which determines the default
	linker script selection.  For proper riscv64 target support, the build process
	must prepare both elf32lriscv* and elf64lriscv* linker scripts.  These should
	align with the standard RISC-V Linux sysroot directory structure.

2025-07-08  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Fixed mapping symbol for .option norvc directive

	RISC-V: Fixed dis-assembler to set correct xlen from mapping symbol

	RISC-V: Fixed that .option push/pop won't recover the xlen

	RISC-V: Added testcase to show the current rvc and xlen problems

2025-07-08  Linsen Zhou  <i@lin.moe>

	RISC-V: Bind defined symbol locally in PIE
	Reference commit 1dcb9720d62cd053a72c31881b7724ce9f74332c

	bfd/
		* elfnn-riscv.c (RISCV_COPY_INPUT_RELOC): Bind defined symbol
		locally in PIE.

	ld/
		* testsuite/ld-riscv-elf/pie-bind-locally-a.s: New test source.
		* testsuite/ld-riscv-elf/pie-bind-locally-b.s: Likewise.
		* testsuite/ld-riscv-elf/pie-bind-locally-rv32.d: New testcase.
		* testsuite/ld-riscv-elf/pie-bind-locally-rv64.d: Likewise.

2025-07-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove ElfReloc class and unused functions and declarations
	class ElfReloc is not used after we started use libbfd.
	Removed ElfReloc and other unused declarations.

	gprofng/ChangeLog
	2025-07-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Disasm.cc: Remove unused functions and variables.
		* src/Disasm.h: Likewise.
		* src/Dwarf.cc: Likewise.
		* src/DwarfLib.cc: Likewise.
		* src/DwarfLib.h: Likewise.
		* src/Elf.cc: Likewise.
		* src/Elf.h: Likewise.
		* src/Stabs.cc: Likewise.
		* src/Stabs.h: Likewise.

2025-07-07  Tom Tromey  <tromey@adacore.com>

	Correctly handle L'\\'
	Hannes filed a bug that pointed out that:

	    print L'\\'

	... did not work correctly.  The bug is in convert_escape, which
	simply transcribes the backslash character, rather than convert it
	between encodings.

	This patch fixes the error.  I also turned a macro into a lambda to
	clean up this code a little.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33124
	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Tested-By: Hannes Domani <ssbssa@yahoo.de>

2025-07-07  WANG Xuerui  <git@xen0n.name>

	LoongArch: Allow to relax instructions into NOPs after handling alignment
	Right now, LoongArch linker relaxation is 2-pass, since after alignment
	is done, byte deletion can no longer happen. However, as the alignment
	pass also shrinks text sections, new relaxation chances may well be
	created after alignment is done. Although at this point we can no longer
	delete unused instructions without disturbing alignment, we can still
	replace them with NOPs; popular LoongArch micro-architectures can
	eliminate NOPs during execution, so we can expect a (very) slight
	performance improvement from those late-created relaxation chances.

	To achieve this, the number of relax passes is raised to 3 for
	LoongArch, and every relaxation handler except loongarch_relax_align is
	migrated to a new helper loongarch_relax_delete_or_nop, that either
	deletes bytes or fills the bytes to be "deleted" with NOPs, depending on
	whether the containing section already has undergone alignment. Also,
	since no byte can be deleted during this relax pass, in the pass the
	pending_delete_ops structure is no longer allocated, and
	loongarch_calc_relaxed_addr(x) degrades to the trivial "return x" in
	this case.

	In addition, previously when calculating distances to symbols, an
	extra segment alignment must be considered, because alignment may
	increase distance between sites. However in the newly added 3rd pass
	code size can no longer increase for "closed" sections, so we can skip
	the adjustment for them to allow for a few more relaxation chances.

	A simple way to roughly measure this change's effectiveness is to check
	how many pcalau12i + addi.d pairs are relaxed into pcaddi's. Taking a
	Firefox 140.0.2 test build of mine as an example:

	Before: 47842 pcaddi's in libxul.so
	After: 48089

	This is a 0.5% increase, which is kind of acceptable for a peephole
	optimization like this; of which 9 are due to the "relax"ed symbol
	distance treatment.

2025-07-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-06  Jens Remus  <jremus@linux.ibm.com>

	ld: bfd: sframe: Update section size also for relocatable links
	For relocatable links the output .sframe section size may be wrong.
	This can be observed when dumping the SFrame information from the x86-64
	sframe-reloc-1 test:

	Name              Address          Off    Size
	.sframe           0000000000000000 000110 00007f

	Offset            Type               Symbol's Value  Symbol's Name + Addend
	000000000000001c  R_X86_64_PC32      0000000000000000 .text + 1c
	0000000000000030  R_X86_64_PC32      0000000000000000 .text + 65

	0x00000000 e2de0201 0300f800 02000000 08000000 ................
	0x00000010 1e000000 00000000 28000000 00000000 ........(.......
	0x00000020 35000000 00000000 04000000 00000000 5...............
	0x00000030 00000000 25000000 0f000000 04000000 ....%...........
	            offset 1st FRE---^^^^^^^^ ^^^^^^^^---number of FREs
	0x00000040 00000000 00030801 0510f004 0410f034 ...............4
	FDE info---^^      | begin of FDEs
	0x00000050 0508f000 03080105 10f00404 10f02405 ..............$.
	                 11111112222222223333333334444---FRE 1, 2, 3, 4
	0x00000060 08f00000 00000000 00000000 00000000 ................
	           4444^^^^...
	0x00000070 00000000 00000000 00000000 000000   ...............
	                                   ...^^^^^^---excessive section

	When running the x86-64 test cross build on a big-endian system, such
	as s390x, objdump and readelf fail to dump the SFrame information with
	the following error message:

	Error: SFrame decode failure: Buffer does not contain SFrame data.

	This is because the following check in flip_sframe() fails, which gets
	only invoked if the endianness of the SFrame data is different from the
	host system one:

	/* All FDEs and FREs must have been endian flipped by now.  */
	if ((j != ihp->sfh_num_fres) || (bytes_flipped != (buf_size - hdrsz)))
	                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	With:
	j=8, ihp->sfh_num_fres=8, bytes_flipped=70, buf_size=127, hdrsz=28

	While at it, remove the incorrect code comment.  There is no
	relationship between "do not update size" and the fact that the
	"contents have not been relocated".

	bfd/
		* elf-sframe.c (_bfd_elf_write_section_sframe): Update section
		size also for relocatable links.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	NEWS: sframe: mention new semantics for SFrame FDE function start addr
	The SFrame FDE's function start address is always emitted as follows by
	GAS and ld:  it is the offset of the start PC of the respective function
	from the FDE field itself.

	GAS and ld will emit a flag SFRAME_F_FDE_FUNC_START_PCREL set to 1
	when emitting the field in this encoding.

		* binutils/NEWS: Announce the change of encoding for SFrame FDE
		  func start addr field.
	        * gas/NEWS: Announce the emission of new flag
		  SFRAME_F_FDE_FUNC_START_PCREL.
	        * ld/NEWS: Likewise.  Relocatable links are now fixed.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	ld: bfd: sframe: fix incorrect r_offset in RELA entries
	PR/32666  Incorrect .rela.sframe when using ld -r

	Input SFrame sections are merged using _bfd_elf_merge_section_sframe (),
	which clubs all SFrame FDEs together in one blob and all SFrame FREs in
	another.  This, of course, means the offset of an SFrame FDE in the output
	section cannot be simply derived from the output_offset of the sections.

	Fix this by providing _bfd_elf_sframe_section_offset () which returns
	the new offset of the SFrame FDE in the merged SFrame section.

	Unlike EH_Frame sections, which also use the _bfd_elf_section_offset (),
	to update the r_offset, SFrame sections have distinct merging semantics.
	In case of SFrame, the SFrame FDE will not simply sit at location
	"sec->output_offset + offset of SFrame FDE in sec".  Recall that information
	layout in an SFrame section is as follows:
	   SFrame Header
	   SFrame FDE 1
	   SFrame FDE 2
	   ...
	   SFrame FDEn
	   SFrame FREs (Frame Row Entries)
	Note how the SFrame FDEs and SFrame FREs are clubber together in groups
	of their own.

	Next, also note how the elf_link_input_bfd () does a:
	            irela->r_offset += o->output_offset;
	This, however, needs to be avoided for SFrame sections because the
	placement of all FDEs is at the beginning of the section.  So, rather than
	conditionalizing this as follows:
	          if (o->sec_info_type != SEC_INFO_TYPE_SFRAME)
	            irela->r_offset += o->output_offset;
	the implementation in _bfd_elf_sframe_section_offset () does a reverse
	adjustment, so that the generic parts of the linking process in
	elf_link_input_bfd () are not made to do SFrame specific adjustments.

	Add a new enum to track the current state of the SFrame input section
	during the linking process (SFRAME_SEC_DECODED, SFRAME_SEC_MERGED) for
	each input SFrame section.  This is then used to assert an assumption
	that _bfd_elf_sframe_section_offset () is being used on an input SFrame
	sections which have not been merged (via
	_bfd_elf_merge_section_sframe ()) yet.

	bfd/
	        * elf-bfd.h: New declaration.
	        * elf-sframe.c (_bfd_elf_sframe_section_offset): New definition.
	        * elf.c (_bfd_elf_section_offset): Adjust offset if SFrame
		section.
	ld/testsuite/
	        * ld-x86-64/x86-64.exp: New test.
	        * ld-x86-64/sframe-reloc-1.d: New test.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	bfd: gas: ld: libsframe: adopt new encoding for FDE func start addr field
	This patch convenes a set of changes in bfd, gas, ld, libsframe towards
	moving to the new encoding for the 'sfde_func_start_address' field in
	SFrame FDE.

	First, gas must now mark all SFrame sections with the new flag
	SFRAME_F_FDE_FUNC_START_PCREL.  gas was already emitting the field
	in the said encoding.

		* gas/gen-sframe.c (output_sframe_internal): Emit the flag
		SFRAME_F_FDE_FUNC_START_PCREL.

	Similarly for ld, adopt the new semantics of sfde_func_start_address
	consistently.  This means:
	  - When merging SFrame sections, check that all input SFrame sections
	    have the SFRAME_F_FDE_FUNC_START_PCREL flag set.  If the check
	    fails, ld errors out.
	  - When merging SFrame sections, keep even the in-memory contents of
	    the FDE function start address (buffer passed to libsframe
	    sframe_encoder_write () for writing out) encoded in the new
	    semantics.  While it is, in theory, possible that instead of doing this
	    change here, we adjust the value of sfde_func_start_address at the final
	    write (sframe_encoder_write) time.  But latter is not favorable for
	    maintenanance and may be generally confusing for developers.
	  - When creating SFrame for PLT entries, emit flag
	    SFRAME_F_FDE_FUNC_START_PCREL.

	include/
	        * sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): New definition.
	bfd/
		* elf-sframe.c (_bfd_elf_merge_section_sframe): Check for flag
		combinatation SFRAME_F_LD_MUSTHAVE_FLAGS set for all input and
		output SFrame sections.  If not, error out.  Also, adopt the new
	        semantics of function start address encoding.
		* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Emit flag
		SFRAME_F_FDE_FUNC_START_PCREL.

	Next, for dumping SFrame sections, now that we are emitting the same
	encoding in GAS, non-relocatable and relocatable SFrame links, it is the
	time to set relocate to TRUE in debug_displays[].

	binutils/
		* dwarf.c (struct dwarf_section_display): Allow sframe sections
		  to now be relocated.
	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Update the
		test.  Relocatable SFrame sections now display non-zero value
		(appropriate function start address).

	Now, as the SFrame sections on-disk and in-memory use the new semantics of
	sfde_func_start_address encoding (i.e., function start address is the
	offset from the sfde_func_start_address field to the start PC), the
	calculation to make it human readable (i.e., relatable to the addresses
	in .text sections) needs adjustment.

	libsframe/
		* sframe-dump.c (dump_sframe_func_with_fres): Adjust the
		function start address for dumping.

	Now that both the emission of the new encoding, and the relocation of
	sections before dumping them is in place, it is time to adjust the
	testcases.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe-aarch64-1.d: Update expected output
		to include SFRAME_F_FDE_FUNC_START_PCREL instead of NONE.
		* gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-aarch64-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-aarch64-4.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-10.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-11.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-9.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: Likewise.
		* gas/cfi-sframe/common-empty-1.d: Likewise.
		* gas/cfi-sframe/common-empty-2.d: Likewise.
		* gas/cfi-sframe/common-empty-3.d: Likewise.
		* gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise.
		* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.
	ld/testsuite/
		* ld-aarch64/sframe-simple-1.d: Update expected output to
		include SFRAME_F_FDE_FUNC_START_PCREL.
		* ld-x86-64/sframe-ibt-plt-1.d: Likewise.
		* ld-x86-64/sframe-plt-1.d: Likewise.
		* ld-x86-64/sframe-pltgot-1.d: Likewise.
		* ld-x86-64/sframe-pltgot-2.d: Likewise.
		* ld-x86-64/sframe-simple-1.d: Likewise.

	Naturally, the change of semantics for 'SFrame FDE function start address'
	has consequences on the implementation in libsframe.  As per the new
	semantics:
	  - Function start address in the SFrame FDE (sfde_func_start_address)
	    is an offset from the FDE function start address field to the start
	    PC of the associated function.

	Note that, the libsframe library brings the SFrame section contents into
	its own memory to create a sframe_decoder_ctx object via sframe_decode
	().  Many internal and user-interfacing APIs then may use
	sframe_decoder_ctx object to interact and fulfill the work.

	In context of changing semantics for sfde_func_start_address, following
	relevant examples may help understand the impact:
	  - sframe_find_fre () finds a the SFrame stack trace data (SFrame FRE)
	    given a lookup offset (offset of lookup_pc from the start of SFrame
	    section).  Now that the sfde_func_start_address includes the
	    distance from the sfde_func_start_address field to the start of
	    SFrame section itself, the comparison checks of
	    sfde_func_start_address with the incoming lookup offset need
	    adjustment.
	  - Some internal functions (sframe_get_funcdesc_with_addr_internal ()
	    finds SFrame FDE by using binary seach comparing
	    sfde_func_start_address fields, etc.) need adjustments.
	  - sframe_encoder_write () sorts the SFrame FDEs before writing out
	    the SFrame data.  Sorting of SFrame FDE via the internal function
	    sframe_sort_funcdesc() needs adjustments: the new encoding of
	    sfde_func_start_address means the distances are not from the same
	    anchor, so cannot be sorted directly.

	This patch takes the approach of adding a new internal function:
	  - sframe_decoder_get_secrel_func_start_addr (): This function returns
	    the offset of the start PC of the function from the start of SFrame
	    section, i.e., it gives a section-relative offset.

	As the sframe_decoder_get_secrel_func_start_addr () API needs the value
	of the function index in the FDE list, another internal API needs
	sframe_fre_check_range_p () adjustments too.

	Sorting the FDEs (via sframe_sort_funcdesc ()) is done by first bringing
	all offsets in sfde_func_start_address relative to start of SFrame
	section, followed by sorting, and then readjusting the offsets accroding
	to the new position in the FDE list.

	libsframe/
		* sframe.c (sframe_decoder_get_secrel_func_start_addr): New
		static function.
	        (sframe_fre_check_range_p): Adjust the interface a bit.
		(sframe_get_funcdesc_with_addr_internal): Use
		sframe_decoder_get_secrel_func_start_addr () when comparing
		sfde_func_start_address with user input offset.
	        (sframe_find_fre): Adopt the new semantics.
	        (sframe_sort_funcdesc): Likewise.

	For the libsframe testsuite, use the new encoding for FDE func start
	addr: distance between the FDE sfde_func_start_address field and the
	start PC of the function itself.

	Use SFRAME_F_FDE_FUNC_START_PCREL flag, though the sframe_encode ()
	interface in libsframe applies no sanity checks for the encoding itself.

	libsframe/testsuite/
		* libsframe.find/findfre-1.c: Adjust to use the new
		SFRAME_F_FDE_FUNC_START_PCREL specific encoding.
		* libsframe.find/findfunc-1.c: Likewise.
		* libsframe.find/plt-findfre-1.c: Likewise.
		* libsframe/testsuite/libsframe.decode/DATA2: Update data file
		due to usage of new SFRAME_F_FDE_FUNC_START_PCREL flag.
		* libsframe/testsuite/libsframe.encode/encode-1.c: Use flag
		SFRAME_F_FDE_FUNC_START_PCREL.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	objdump, readelf: sframe: apply relocations before textual dump
	PR libsframe/32589 - function start address is zero in SFrame section dump

	Currently, readelf and objdump display the SFrame sections in ET_REL
	object files with function start addresses of each function as 0.  This
	makes it difficult to correlate SFrame stack trace information with the
	individual functions in the object file.

	For objdump, use the dump_dwarf () interface to dump SFrame section.
	Similarly, for readelf, use the display_debug_section () interface to
	dump SFrame section.  These existing interfaces (for DWARF debug
	sections) already support relocating the section contents before
	dumping, so lets use them for SFrame sections as well.

	When adding a new entry for SFrame in debug_option_table[], use char
	'nil' and the option name of "sframe-internal-only".  This is done so
	that there is no additional (unnecessary) user-exposed ways of dumping
	SFrame sections.  Additionally, we explicitly disallow the
	"sframe-internal-only" from external/user input in --dwarf (objdump).
	Similarly, "sframe-internal-only" is explicitly matched and disallowed
	from --debug-dump (readelf).

	For objdump and readelf, we continue to keep the same error messaging as
	earlier:

	  $ objdump --sframe=sframe bubble_sort.o
	  ...
	  No sframe section present

	  $ objdump --sframe=.sfram bubble_sort.o
	  ...
	  No .sfram section present

	  $ objdump --sframe=sframe-internal-only sort
	  ...
	  No sframe-internal-only section present

	Similarly for readelf:

	  $ readelf --sframe= bubble_sort.o
	  readelf: Error: Section name must be provided
	  $ readelf --sframe=.sfram bubble_sort.o
	  readelf: Warning: Section '.sfram' was not dumped because it does not exist
	  $ readelf --sframe=sframe bubble_sort.o
	  readelf: Warning: Section 'sframe' was not dumped because it does not exist

	PS: Note how this patch adds a new entry to debug_displays[] with a
	    relocate value set to FALSE.  This will be set to TRUE in a subsequent
	    patch ("bfd: gas: ld: libsframe: emit func start addr field as an offset
	    from FDE") when fixes are made to emit the value of the
	    'sfde_func_start_address' field in the new encoding
	    SFRAME_F_FDE_FUNC_START_PCREL across gas and ld.

	binutils/
		* dwarf.c (display_sframe): New definition.
		(dwarf_select_sections_all): Enable SFrame section too.
		(struct dwarf_section_display): Add entry for SFrame section.
		* dwarf.h (enum dwarf_section_display_enum): Add enumerator for
		SFrame.
		* objdump.c (dump_section_sframe): Remove.
		(dump_sframe_section): Add new definition.
		(dump_bfd): Use dump_sframe_section.
		* binutils/readelf.c (dump_section_as_sframe): Remove.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	include: sframe: doc: define new flag SFRAME_F_FDE_FUNC_START_PCREL
	Add a new flag SFRAME_F_FDE_FUNC_START_PCREL to SFrame stack trace
	format.  If set, this flag indicates that the function start address
	field (sfde_func_start_address) is the offset to the function start
	address from the SFrame FDE function start address field itself.

	Such an encoding is friendlier to the exisitng PC-REL relocations
	available in the ABIs supported in SFrame: AMD64 (R_X86_64_PC32) and
	AArch64 (R_AARCH64_PREL32).  In subsequent patches, we will make the
	implementation in gas and ld to both:
	  - emit the values in the same (above-mentioned) encoding uniformly.
	  - set the flag SFRAME_F_FDE_FUNC_START_PCREL in the SFrame header
	    for consumers to be able to distinguish.

	Define SFRAME_V2_F_ALL_FLAGS in sframe.h to help keep the implementation
	less error-prone by keeping a set of all defined flags at a central
	place.  Adjust the check in sframe_header_sanity_check_p () to use the
	SFRAME_V2_F_ALL_FLAGS instead.

	Add documentation for SFRAME_F_FDE_FUNC_START_PCREL.  Update the
	documentation about the encoding of the sfde_func_start_address field.

	Also, update the section "Changes from Version 1 to Version 2" to
	include the specification of the new flag SFRAME_F_FDE_FUNC_START_PCREL
	as an erratum to the SFrame Version 2 specification.

	include/
	        * sframe.h (SFRAME_F_FDE_FUNC_START_PCREL): New definition.
	        (SFRAME_V2_F_ALL_FLAGS): Likewise.
	libsframe/
		* sframe-dump.c (dump_sframe_header_flags): Update to include
		the new flag SFRAME_F_FDE_FUNC_START_PCREL.
		* sframe.c (sframe_header_sanity_check_p): Use
		SFRAME_V2_F_ALL_FLAGS.
	libsframe/doc/
		* sframe-spec.texi: Add details about the new flag.  Also update
		the defails about the sfde_func_start_address encoding.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	include: libsframe: add APIs for offsetof FDE func start addr field
	These APIs will be later used by the linker to arrange SFrame FDEs in
	the output SFrame section.

	include/
	        * sframe-api.h (sframe_decoder_get_offsetof_fde_start_addr): New
		declaration.
	        (sframe_encoder_get_offsetof_fde_start_addr): Likewise.

	libsframe/
	        * libsframe.ver: List the new APIs.
	        * sframe.c (sframe_decoder_get_offsetof_fde_start_addr): New
		definition.
	        (sframe_encoder_get_offsetof_fde_start_addr): Likewise.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: refactor code for dumping section flags
	To prepare code for accommodating new flag additions easily as the
	format evolves.

	libsframe/
	        * sframe-dump.c (SFRAME_HEADER_FLAGS_STR_MAX_LEN): Remove.
	        (dump_sframe_header_flags): .. to here. New definition.
	        (PRINT_FLAG): New definition.
	        (dump_sframe_header): Move some implementation from here ..

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	include: libsframe: add APIs for SFrame header flags
	Add new APIs, one each for getting flags from the SFrame decoder and
	SFrame encoder context objects respectively.

	These will later be used by the linker to uniformly access the flags,
	given the SFrame decoder and SFrame encoder objects.

	Use the new API, where applicable, within libsframe.

	include/
	        * sframe-api.h (sframe_decoder_get_flags): New declaration.
	        (sframe_encoder_get_flags): Likewise.
	libsframe/
		* libsframe.ver: List new APIs.
	        * sframe.c (sframe_decoder_get_flags): New definition.
		(sframe_encoder_get_flags): Likewise.
	        (sframe_get_funcdesc_with_addr_internal): Use the new API.
	        (sframe_encoder_get_flags): Likewise.
	        (sframe_encoder_write_sframe): Likewise.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Remove empty pic-and-nonpic-1-r6.s file
	It was never used, pushed by mistake along with pic-and-nonpic-1a-r6.s.

2025-07-06  Alan Modra  <amodra@gmail.com>

	MIPS: Correct HI/LO rela reloc howto special_function entries
	The patch corrects the mips16 and micromips rela tables to *not*
	use _bfd_mips_elf_{hi,lo}16_reloc.  These special functions are
	inappropriate for RELA relocs where addends are in the reloc rather
	than in the section contents.  See corresponding rela R_MIPS howtos.

	bfd/
		* elf64-mips.c (mips16_elf64_howto_table_rela)
		<R_MIPS16_HI16, R_MIPS16_LO16>: Use _bfd_mips_elf_generic_reloc
		special_function.
		(micromips_elf64_howto_table_rela)
		<R_MICROMIPS_HI16, R_MICROMIPS_LO16>: Similarly.
		* elfn32-mips.c: As for elf64-mips.c.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/BFD: Fix RELA handling of borrow in the generic linker
	Fix an issue with `_bfd_mips_elf_generic_reloc' not taking into account
	any borrow from the lower part in the handling of relocations of the
	HI/LO kind and resulting in incorrect calculations made for RELA targets
	in the generic used for non-ELF output such as S-records.  This doesn't
	trigger for REL targets because they call `_bfd_mips_elf_generic_reloc'
	indirectly from `_bfd_mips_elf_lo16_reloc' so as to obtain a complete
	32-bit addend from relocation pairs and in calculating the addend the
	latter function uses a hack to work around the lack of borrow handling
	in the former function.

	The MIPS/ELF linker is unaffected as it uses its own calculations.

	Correct the calculation of the relevant partial relocations made in
	`_bfd_mips_elf_generic_reloc' then to take the borrow into account and
	remove the hack from `_bfd_mips_elf_lo16_reloc' as no longer needed.

	Add generic linker test cases accordingly expecting the same disassembly
	from srec output produced as from ELF output produced by the MIPS/ELF
	linker.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/testsuite: Expand GAS and LD HI/LO relocation coverage
	Expand test coverage for HI/LO relocation handling and add conventional
	MIPS and microMIPS GAS tests as well as conventional MIPS, microMIPS,
	and MIPS16e2 LD tests, covering R_MIPS_HI16, R_MIPS_LO16, R_MIPS16_HI16,
	R_MIPS16_LO16, R_MICROMIPS_HI16, and R_MICROMIPS_LO16 relocations, as
	well as 64-bit R_MIPS_HIGHEST, R_MIPS_HIGHER, R_MICROMIPS_HIGHEST, and
	R_MICROMIPS_HIGHER relocations.

	Modify the linker script so as to retain the `.MIPS.abiflags' section so
	as to disassemble MIPS16e2 code correctly, as MIPS16e2 ASE information
	is only carried in that section and not in ELF file header's `e_flags'.

	MIPS16e2 and microMIPS code requires at least the MIPS32r2 ISA (or the
	MIPS64r2 one for the n32 and n64 ABIs), which is incompatible with the
	`mips:5900' linker output architecture and causes link failures such as:

	./ld-new: tmpdir/mips-hilo1.o: linking mips:isa32r2 module with previous mips:5900 modules
	./ld-new: failed to merge target specific data of file tmpdir/mips-hilo1.o

	Therefore exclude `mips*el-ps2-elf*' targets from microMIPS and MIPS16e2
	LD testing.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Switch mips16-hilo tests to new disassembly format
	Switch the o32 and n32 mips16-hilo MIPS LD tests to the new disassembly
	format, to reduce discrepancies in output in preparation to reuse for
	generic linker tests.

	Taking the first line of disassembly output as an example the difference
	is:

	00500000 <stuff> 6c00      	li	a0,0

	vs:

	0x0000000000500000 6c00      	li	a0,0

	for ELF and srec input respectively with the currently used older format
	requested with `--prefix-addresses', but with the new disassembly format
	it is exactly the same between the two input formats and no information
	that we need is lost in the transition:

	  500000:	6c00      	li	a0,0

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Remove symbol table output from mips16-hilo tests
	The o32 and n32 mips16-hilo MIPS LD tests request symbol table output
	only to discard it in matching.  The symbol table is not relevant to
	these tests, so remove it from output requested and adjust matching
	patterns accordingly.

	MIPS/testsuite: Fix %hi usage across MIPS16 GAS/LD tests
	Fix a couple of places in MIPS GAS and LD R_MIPS16_HI16/R_MIPS16_LO16
	relocation tests where the %hi operator has been incorrectly used, but
	the %lo operator is expected to complement the preceding %hi operation.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix mips16-hilo IRIX 6 emulation failures
	IRIX 6 emulations place external small common symbols in the regular
	common section instead of the small common section.  With mips16-hilo
	test this leads to a different symbol assignment to memory locations
	between o32 and n32 ABIs, as follows:

	--- o32.map
	+++ n32.map
	@@ -46,23 +46,22 @@
	  *(.sdata)
	                 0x00765430                        . = 0x765430

	-.bss            0x00765430      0x7d8
	+.bss            0x00765430      0x7d9
	  *(.bss)
	  .bss           0x00765430      0x3f0 tmpdir/mips16-hilo.o
	  .bss           0x00765820        0x0 tmpdir/mips16-hilo1.o
	  *(COMMON)
	- COMMON         0x00765820      0x3e8 tmpdir/mips16-hilo.o
	+ COMMON         0x00765820      0x3e9 tmpdir/mips16-hilo.o
	                 0x00765820                big_external_common
	+                0x00765c08                small_external_common

	-.sbss           0x00765c08        0x2
	+.sbss           0x00765c09        0x1
	  *(.sbss)
	- .sbss          0x00765c08        0x1 tmpdir/mips16-hilo.o
	+ .sbss          0x00765c09        0x1 tmpdir/mips16-hilo.o
	  *(.scommon)
	- .scommon       0x00765c09        0x1 tmpdir/mips16-hilo.o
	-                0x00765c09                small_external_common

	 /DISCARD/
	  *(*)
	 LOAD tmpdir/mips16-hilo.o
	 LOAD tmpdir/mips16-hilo1.o
	-OUTPUT(tmpdir/dump elf32-bigmips)
	+OUTPUT(tmpdir/dump elf32-nbigmips)

	which in turn causes a testsuite regression.  Since the specific mapping
	of symbols does not matter for the scope of the test, reorder the small
	common section ahead of SBSS, so that the `small_external_common' symbol
	ends up in the same place regardless of whether via the regular common
	section or the small common section.  Adjust embedded addresses in the
	disassembly expected accordingly, removing the regression concerned:

	mips-sgi-irix6  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
	mips64el-ps2-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Unify o32/n32 mips16-hilo test output
	The mips16-hilo MIPS LD test case is supposed to produce the same final
	linked output regardless of whether the o32 or n32 ABI has been chosen
	for assembly.  Reuse o32 output for the n32 test then.

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Set architecture for MIPS16 HI/LO tests
	Remove regressions across MIPSr6 targets with the MIPS16 HI/LO tests,
	which are incompatible with the default architecture of these targets:

	mips-img-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mips-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mips64-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mips64-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
	mips64el-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mips64el-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
	mipsel-img-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsel-img-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa32r6-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa32r6-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa32r6el-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa32r6el-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6-linux-gnuabi64  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6el-elf  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6el-linux-gnuabi64  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
	mipsisa64r6el-linux  -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs

2025-07-06  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Cover microMIPS HI/LO relocation pairing
	Add a GAS test case for R_MICROMIPS_HI16/R_MICROMIPS_LO16 REL relocation
	pairing, analogous to one for R_MIPS16_HI16/R_MIPS16_LO16 relocations.

	MIPS/GAS/testsuite: Remove useless whitespace from mips16-hilo-match test
	Remove trailing whitespace and extraneous new-line characters from
	mips16-hilo-match.d test case.

2025-07-06  Alan Modra  <amodra@gmail.com>

	gas pending_bundle_size assert
	oss-fuzz managed to trigger this assert, by assembling directives in
	the absolute section.  Avoid this using similar code to that in
	frags.c:frag_new (commit 2dc2dfa7d7a5).

	gas bundle support
	Use valueT when calculating sizes, since fr_fix is that type.
	unsigned int was fine for sane code, but can lose to fuzzed input.

	ubsan: gas resolve_symbol_value
	Avoid signed overflow when resolving constant +/- constant.

2025-07-06  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fix error code in sframe_decode
	When sanity check of SFrame header fails, set error code to
	SFRAME_ERR_BUF_INVAL instead of the current SFRAME_ERR_NOMEM.

2025-07-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-05  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix selftest scoped_mmap on freebsd
	On x86_64-freebsd, I run into:
	...
	$ gdb -q -batch -ex "maint selftest scoped_mmap"
	Running selftest scoped_mmap.
	Self test failed: self-test failed at scoped_mmap-selftests.c:50

	Failures:
	  scoped_mmap

	Ran 1 unit tests, 1 failed
	...

	The problem is that this call:
	...
	    ::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE,
				 MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
	...
	returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0.

	If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd.  On linux, fd is
	ignored but -1 is recommended for portability.

	Fix this by using fd == -1 instead.

	Tested x86_64-freebsd and x86_64-linux.

2025-07-05  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix doc string of kvm pcb/proc command
	On x86_64-freebsd, I ran into:
	...
	$ gdb -q -batch -ex "maint selftest help_doc_invariants"
	Running selftest help_doc_invariants.
	help doc broken invariant: command 'kvm pcb' help doc first line is not \
	  terminated with a '.' character
	Self test failed: self-test failed at command-def-selftests.c:120

	Failures:
	  help_doc_invariants

	Ran 1 unit tests, 1 failed
	...

	Fix this by adding the missing terminating dot.

	Likewise for the kvm proc command.

	Tested on x86_64-freebsd.

2025-07-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: create gdb.sum/gdb.log summary after using check-all-boards
	Use the contrib/dg-extract-results.sh script to create a gdb.sum and
	gdb.log summary after running the check-all-boards make target.

	Having the results from all the boards merged into a single file
	isn't (maybe) the most useful, but it isn't a bad thing.  However, the
	great thing about merge the results is that the totals are also
	merged.

	The 'check-all-boards' recipe can then extract these totals, just as
	we do for the normal 'check' recipe, this makes is much easier to
	spot if there are any unexpected failures when using
	'check-all-boards'.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-07-05  Andrew Burgess  <aburgess@redhat.com>

	contrib: sync dg-extract-results.{sh,py} with GCC
	Sync the dg-extract-results.{sh,py} scripts with GCC, up to commit
	4e9104ae5455a3c02c2a7e07f52e6bc574cc761d.

	This extends the dg-extract-results scripts to handle GDB's
	'unexpected core files' count.

	contrib/ChangeLog:

		* dg-extract-results.py: Handle GDB's unexpected core file count.
		* dg-extract-results.sh: Likewise.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-07-05  Pietro Monteiro  <pietro@sociotechnical.xyz>

	sim: ppc: use correct macros
	AC_STRUCT_ST_* are the names of the autoconf macros, the C
	preprocessor macros defined by autoconf/authoeader are
	HAVE_STRUCT_STAT_ST_*.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-07-05  Pietro Monteiro  <pietro@sociotechnical.xyz>

	sim: configury: fix obsolete macros
	Running `autoreconf -vf -Wall' in the sim directory shows errors about the use
	of obsolete macros.  This patch fix the issues with macros used or defined in
	the sim directory.  However, it doesn't fix all warnings.  There's 1 autoconf
	warning  from `config/pkg.m4', and many automake warnings about target
	shadowing.  It cuts a lot of the noise down and makes an upgrade to
	autoconf 2.71+ easier.

	- Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997

	- Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203

	- Replace AC_ERROR by AC_MSG_ERROR
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fERROR-2034

	- Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213

	- Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176

	- Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180

	- Remove AC_STRUCT_ST_BLOCKS.  It is not obsolete, but it's already covered by a
	AC_CHECK_MEMBERS call.

	- Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER}
	  https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
	Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693

	Approved-By: Tom Tromey <tom@tromey.com>

2025-07-05  Pietro Monteiro  <pietro@sociotechnical.xyz>

	gdb: add Pietro Monteiro to gdb/MAINTAINERS

2025-07-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-04  Jan Beulich  <jbeulich@suse.com>

	gas: introduce .errif and .warnif
	Rather than having people resort to indirect means to issue a certain
	kind of diagnostic conditionally upon an expression which can (or
	should) only be evaluated when all sections were sized and all symbols
	had their final values established, provide directives to directly
	achieve this.

2025-07-04  Jan Beulich  <jbeulich@suse.com>

	gas: add a means to programmatically determine the assembler version
	It has been more than once that I would have wanted to have a way to
	know the gas version in assembly sources, perhaps for use with .if. Add
	such a pre-defined symbol, introducing the common pattern GAS(<symbol>)
	for any such symbols. The use of parentheses is to keep the risk of
	collisions with users' symbols as low as possible. (Possible future
	arch-specific symbols may want to use GAS(<arch>:<symbol>).)

	Similarly permit determining whether the assembler is a released
	version. The exact value probably isn't of much use, it's more the
	defined-ness that one might care about. Yet the symbol needs to have
	some value anyway.

	While by default pre-defined symbols won't be emitted to the symbol
	table, introduce -emit-local-absolute to allow requesting this. Re-
	purpose flag_strip_local_absolute to become tristate, with a negative
	value indicating to also emit pre-defined symbols.

2025-07-04  Jan Beulich  <jbeulich@suse.com>

	cris/testsuite: don't use --em=
	Using such abbreviations is fine when written on an interactive command
	line by a human. In scripts and alike, doing so risks colliding with
	later option additions, as is about to occur for gas: Shortly there'll
	be --emit-local-absolute.

2025-07-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/linux-nat: initialize lwp_info::syscall_state
	When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan,
	I get:

	    /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind'
	    ERROR: GDB process no longer exists
	    GDB process exited with wait status 3026417 exp9 0 1
	    UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork

	The error happens here:

	    #0  __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
	    #1  0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=<optimized out>, Val=<optimized out>) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551
	    #2  0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906
	    #3  0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044
	    #4  0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381
	    #5  0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607
	    #6  0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 <the_thread_db_target>, ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398
	    #7  0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593

	I believe the problem is that lwp_info::syscall_state is never
	initialized.  Fix that by initializing it with TARGET_WAITKIND_IGNORE.
	This is the value we use elsewhere when resetting this field to mean
	"not stopped at a syscall".

	Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb
	Approved-By: Tom Tromey <tom@tromey.com>

2025-07-03  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	bfd/aarch64-linux: Support reading and writing the GCS core file note
	Reviewed-By: Luis Machado <luis.machado@arm.com>

2025-07-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: remove spurious whitespace in gdb.python/py-symbol.exp
	Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536

2025-07-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/alpha-tdep: add empty line
	This was suggested in review, to separate the comment from the following
	code.

	Change-Id: I077ad4545ee5ef1d362dcfacf585400e26dfdb29

2025-07-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-02  Yodel Eldar  <yodel.eldar@gmail.com>

	gdb/alpha: Redefine fpcr with fpcr_flags type
	This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr.

	For details on the floating-point control register (fpcr), please see
	the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it
	consists of a 64-bit bitfield with most bits reserved/unused. All but a
	pair of the used bits are boolean flags; the exception, DYN_RM, is a
	2-bit enum indicating the IEEE rounding mode and is defined as a
	dyn_rm_enum type in the target description annex.

	[1] https://archive.org/details/dec-alpha_arch_ref

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: Iea54c9e201faae6147a03de124b0368752bce060

2025-07-02  Yodel Eldar  <yodel.eldar@gmail.com>

	gdb/alpha: Add target description support
	This commit adds target description support for Alpha.

	The target description obviates the alpha_register_type and
	alpha_register_name functions in alpha-tdep.c. Removal of
	alpha_register_reggroup_p was considered but ultimately abandoned,
	because the "info regs" command would no longer omit the zero, fpcr, and
	unique registers from its output (they are neither vector nor float
	types).

	Register types in the target description annex match the types that the
	alpha_register_type function returned.

	The locally defined register_names array was moved out of
	alpha_register_name and renamed to alpha_register_names as a static
	global; calls to alpha_register_name have been replaced with direct
	access of the array.

	The patch follows the code pattern outlined in the following GDB
	Internals Wiki entry:

	https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: If4b25a891228388519074a31a682e33358c71063

2025-07-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use support_displaced_stepping in gdb.arch/amd64-disp-step-avx.exp
	In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
	on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
	I found support_displaced_stepping, which seems more appropriate and
	descriptive.

	Fix this by requiring support_displaced_stepping instead.

	Tested on x86_64-freebsd.

2025-07-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd
	With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
	...
	(gdb) continue
	Continuing.

	Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
	35		nop
	(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
	...

	This happens while executing this bit of the test-case:
	...
	    # Turn "debug displaced" on to make sure a displaced step is actually
	    # executed, not an inline step.
	    gdb_test_no_output "set debug displaced on"

	    gdb_test "continue" \
		"Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \
		"continue to ${test_end_label}"
	...

	The problem is that on x86_64, displaced stepping is only supported for linux.
	Consequently, the "prepared successfully" message is missing.

	Fix this by requiring linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	Tested on x86_64-freebsd.

2025-07-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-07-01  Tom Tromey  <tom@tromey.com>

	Fix handling of terminal escape sequences in TUI
	A user noticed that if the remote sends terminal escape sequences from
	the "monitor" command, then these will not be correctly displayed when
	in TUI mode.

	I tracked this down to remote.c emitting one character at a time --
	something the TUI output functions did not handle correctly.

	I decided in the end to fix in this in the ui-file layer, because the
	same bug seems to affect logging and, as is evidenced by the test case
	in this patch, Python output in TUI mode.

	The idea is simple: buffer escape sequences until they are either
	complete or cannot possibly be recognized by gdb.

	Regression tested on x86-64 Fedora 40.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-07-01  Jens Remus  <jremus@linux.ibm.com>

	x86: ld: sframe: Remove SFrame NULL FRE template
	A SFrame NULL FRE template is used as NULL value in some but not all
	instances to initialize unused elements of SFrame FRE pointer arrays of
	fixed size.  Additionally it is erroneously used as SFrame FRE template
	for PLT GOT entries.

	Define a separate SFrame FRE template for PLT GOT entries with the same
	properties as the SFrame NULL FRE and use that for all PLT GOT entries.
	Remove the SFrame NULL FRE template, as initialization of unused array
	elements is not required, as demonstrated by the instances where it was
	not done.

	bfd/
		* elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove.
		(elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for
		PLT GOT entries.
		(elf_x86_64_sframe_non_lazy_plt,
		elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused
		FRE array elements with elf_x86_64_sframe_null_fre.  Use
		elf_x86_64_sframe_pltgot_fre1 for PLT GOT.
		(elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use
		elf_x86_64_sframe_pltgot_fre1 for PLT GOT.

2025-07-01  Bruce McCulloch  <bruce.mcculloch@oracle.com>

	libctf: doc: add __float128 and SIMD vector classification to spec.
	This patch adds two additional distinct types (__float128 and the SIMD
	vector type generated from the vector_size attribute) to the umbrella of
	two existing types (long double and array, respectively). These types
	were previously invalid, producing CTF_K_UNKNOWN in the case of
	__float128 or a float in the case of the SIMD vector. This patch will
	cleanly allow these types to be represented more accurately without
	breaking back-compat.

	Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

2025-07-01  Nick Alcock  <nick.alcock@oracle.com>

	libctf: add root-visibility-addition test
	libctf/
		* testsuite/libctf-writable/ctf-nonroot-addition.*: New test.

2025-07-01  Nick Alcock  <nick.alcock@oracle.com>

	libctf: create: check the right root-visible flag when adding enumerands
	The root-visible flag we're dealing with here is directly out of the dict,
	not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT
	or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero
	otherwise.  Fix the test.

	libctf/
		* ctf-create.c (ctf_add_enumerator): Fix root-visibility test.

2025-07-01  Nick Alcock  <nick.alcock@oracle.com>

	libctf: create: addition of non-root types should not return root types
	If you add a non-root type to a dict, you should always get a new, unique
	type ID back, even if a root-visible type with the same name already exists.
	Unfortunately, if the root-visible type is a forward, and you're adding a
	non-root-visible struct, union, or enum, the machinery to detect forwards
	and promote them to the concrete type fires in this case and returns the
	root-visible type!  If this is an enum being inserted hidden because its
	enumerands conflict with some other enum, this will lead to failure later
	on: in any case, it's seriously counterintuitive to add a non-root- visible
	type and get a root-visible one instead.

	Fix this by checking the root-visible flag properly and only checking for
	forwards if this type is root-visible.  (This may lead to a certain degree
	of proliferation of non-root-visible forwards: we can add a cleanup pass for
	those later if needed.)

	libctf/
		* ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when
		doing forward promotion.
		(ctf_add_union_sized): Likewise.
		(ctf_add_enum): Likewise.

	Reviewed-by: Bruce McCulloch <bruce.mcculloch@oracle.com>

2025-07-01  Alan Modra  <amodra@gmail.com>

	MIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16
	In rela howtos these relocations should not be using
	_bfd_mips_elf_got16_reloc.  That special function is for extracting
	addends from section contents, and only for that (ie. it doesn't
	subtract gp).  Make these rela howtos like the corresponding
	R_MIPS_GOT16 rela howto.

		* elf64-mips.c (mips16_elf64_howto_table_rela <R_MIPS16_GOT16>):
		Use _bfd_mips_elf_generic_reloc.
		(micromips_elf64_howto_table_rela <R_MICROMIPS_GOT16>): Likewise.
		* elfn32-mips.c (elf_mips16_howto_table_rela <R_MIPS16_GOT16>):
		Likewise.
		(elf_micromips_howto_table_rela <R_MICROMIPS_GOT16>): Likewise.

2025-07-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-30  WANG Xuerui  <git@xen0n.name>

	RISC-V: [gprofng] Allow building gprofng without asm/hwprobe.h
	The code is actually able to gracefully fallback if the syscall number
	of riscv_hwprobe is not available at build time, but it still depended
	on the <asm/hwprobe.h> header unconditionally. In certain environments
	such as one of crosstool-NG's Canadian Cross build step (binutils for
	host), or one with very outdated kernel headers, the header will not be
	present, causing the build to fail.

	While the relevant projects/environments should be fixed nevertheless,
	a configure-time check for <asm/hwprobe.h> is helpful for fixing gprofng
	builds with released versions of ct-ng etc.

2025-06-30  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix typos in binutils/dwarf.c
	binutils/ChangeLog
	2025-06-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* dwarf.c: Change "/usrlib64/debug/usr" to "/usr/lib64/debug/usr/" and
		.gun_debugaltlink to .gnu_debugaltlink.

2025-06-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPAT
	When building without expat, we get a missing make_target_solib_ops
	error:

	    /usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()':
	    /home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()'

	Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33118
	Change-Id: I76fe4698c6b71bd76096e6cdcbacf8de42a3eb43
	Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2025-06-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-28  H.J. Lu  <hjl.tools@gmail.com>

	x86-64.exp: Correct pr26808.dump to pr27708.dump
	Change

	verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr26808.dump" 1

	to

	verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr27708.dump" 1

		* testsuite/binutils-all/x86-64/x86-64.exp: Correct pr26808.dump
		to pr27708.dump.

2025-06-28  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Add "maint set console-translation-mode <binary|text>" command
	On MSYS2, say we record a brief gdb session using TERM=dumb script:
	...
	$ gdb -q
	(gdb) print 1
	$1 = 1
	(gdb) q
	...

	When looking at the resulting typescript, we notice something odd:
	...
	$ gdb -q^M
	(gdb) print 1^M
	$1 = 1^M^M
	(gdb) q^M
	...

	For some reason, we have "$1 = 1\r\r\n(gdb) ".

	Looking at the documentation of _setmode [1], it mentions translation mode
	_O_TEXT as a mode in which "\n" is translated into "\r\n" on output.

	So, it looks like this translation happens twice.

	Add a command "maint set console-translation-mode <binary|text>" command that
	allows us to set the translation mode of stdout/stderr to binary, such that we
	get instead:
	...
	$ gdb -q -ex "maint set console-translation-mode binary"^M
	(gdb) print 1^M
	$1 = 1^M
	(gdb) q^M
	...

	Since we run into this in the testsuite, add
	"maint set console-translation-mode binary" to INTERNAL_GDBFLAGS.

	Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre
	Muller.

	Compared to that proposal, I dropped the name testsuite-mode, because the
	behaviour is not specific to the testsuite.

	Also I chose values binary/text instead of on/off because eventually there may
	be other translation mode values that we need [4].

	Co-Authored-By: Pierre Muller <muller@sourceware.org>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

	[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
	[2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html
	[3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
	[4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants

2025-06-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-27  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: maint: Fix build on FreeBSD
	While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
	I hit this warning converted to an error:

	In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
	/home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
	   64 |   long m_start_space;
	      |        ^
	1 error generated.
	gmake[2]: *** [Makefile:1973: maint.o] Error 1

	I used the default compiler on this system:

	$ c++ --version
	FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
	Target: aarch64-unknown-freebsd14.3
	Thread model: posix
	InstalledDir: /usr/bin

	The problem is that the only two places that use m_start_space are
	guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
	it.

	Build-tested on aarch64-unknown-freebsd14.3.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-26  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/solib: C++ify solib_ops
	Convert solib_ops into an abstract base class (with abstract methods,
	some of them with default implementations) and convert all the existing
	solib_ops instances to solib_ops derived classes / implementations.

	Prior to this patch, solib_ops is a structure holding function pointers,
	of which there are only a handful of global instances (in the
	`solib-*.c` files).  When passing an `solib_ops *` around, it's a
	pointer to one of these instances.  After this patch, there are no more
	global solib_ops instances.  Instances are created as needed and stored
	in struct program_space.  These instances could eventually be made to
	contain the program space-specific data, which is currently kept in
	per-program space registries (I have some pending patches for that).

	Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a
	pointer to the appropriate solib_ops implementation for the gdbarch.
	This is replaced with the `gdbarch_make_solib_ops` method, which returns
	a new instance of the appropriate solib_ops implementation for this
	gdbarch.  This requires introducing some factory functions for the
	various solib_ops implementation, to be used as `gdbarch_make_solib_ops`
	callbacks.  For instance:

	    solib_ops_up
	    make_linux_ilp32_svr4_solib_ops ()
	    {
	      return std::make_unique<linux_ilp32_svr4_solib_ops> ();
	    }

	The previous code is full of cases of tdep files copying some base
	solib_ops implementation, and overriding one or more function pointer
	(see ppc_linux_init_abi, for instance).  I tried to convert all of this
	is a class hierarchy.  I like that it's now possible to get a good
	static view of all the existing solib_ops variants.  The hierarchy looks
	like this:

	    solib_ops
	    ├── aix_solib_ops
	    ├── darwin_solib_ops
	    ├── dsbt_solib_ops
	    ├── frv_solib_ops
	    ├── rocm_solib_ops
	    ├── svr4_solib_ops
	    │   ├── ilp32_svr4_solib_ops
	    │   ├── lp64_svr4_solib_ops
	    │   ├── linux_ilp32_svr4_solib_ops
	    │   │   ├── mips_linux_ilp32_svr4_solib_ops
	    │   │   └── ppc_linux_ilp32_svr4_solib_ops
	    │   ├── linux_lp64_svr4_solib_ops
	    │   │   └── mips_linux_lp64_svr4_solib_ops
	    │   ├── mips_nbsd_ilp32_svr4_solib_ops
	    │   ├── mips_nbsd_lp64_svr4_solib_ops
	    │   ├── mips_fbsd_ilp32_svr4_solib_ops
	    │   └── mips_fbsd_lp64_svr4_solib_ops
	    └── target_solib_ops
	        └── windows_solib_ops

	The solib-svr4 code has per-arch specialization to provide a
	link_map_offsets, containing the offsets of the interesting fields in
	`struct link_map` on that particular architecture.  Prior to this patch,
	arches would set a callback returning the appropriate link_map_offsets
	by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened
	to set the gdbarch's so_ops to `&svr_so_ops`.  I converted this to an
	abstract virtual method of `struct svr4_solib_ops`, meaning that all
	classes deriving from svr4_solib_ops must provide a method returning the
	appropriate link_map_offsets for the architecture.  I renamed
	`set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`.  This
	function is still necessary because it also calls
	set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for
	that, we could get rid of it.

	There is an instance of CRTP in mips-linux-tdep.c, because both
	mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need
	to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops
	and linux_lp64_svr4_solib_ops), but they both want to override the
	in_dynsym_resolve_code method with the same implementation.

	The solib_ops::supports_namespaces method is new: the support for
	namespaces was previously predicated by the presence or absence of a
	find_solib_ns method.  It now needs to be explicit.

	There is a new progspace::release_solib_ops method, which is only needed
	for rocm_solib_ops.  For the moment, rocm_solib_ops replaces and wraps
	the existing svr4_solib_ops instance, in order to combine the results of
	the two.  The plan is to have a subsequent patch to allow program spaces to have
	multiple solib_ops, removing the need for release_solib_ops.

	Speaking of rocm_solib_ops: it previously overrode only a few methods by
	copying svr4_solib_ops and overwriting some function pointers.  Now, it
	needs to implement all the methods that svr4_solib_ops implements, in
	order to forward the call.  Otherwise, the default solib_ops method
	would be called, hiding the svr4_solib_ops implementation.  Again, this
	can be removed once we have support for multiple solib_ops in a
	program_space.

	There is also a small change in how rocm_solib_ops is activated.  Prior
	to this patch, it's done at the end of rocm_update_solib_list.  Since it
	overrides the function pointer in the static svr4_solib_ops, and then
	overwrites the host gdbarch, so_ops field, it's something that happens
	only once.  After the patch though, we need to set rocm_solib_ops in all
	the program spaces that appear.  We do this in
	rocm_solib_target_inferior_created and in the new
	rocm_solib_target_inferior_execd.  After this, I will explore doing a
	change where rocm_solib_ops is only set when we detect the ROCm runtime
	is loaded.

	Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9
	Approved-By: Pedro Alves <pedro@palves.net>

2025-06-26  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/progspace: add solib_ops pointer in program_space
	The subsequent C++ification patch in this series will allocate one
	instance of solib_ops per program space.  That instance will be held in
	struct program_space.  As a small step towards this, add an `solib_ops
	*` field to `struct program_space`.  This field represents the solib_ops
	currently used to manage the solibs in that program space.  Initialize
	it with the result of `gdbarch_so_ops` in `post_create_inferior`, and
	use it whenever we need to do some solib stuff, rather than using
	`gdbarch_so_ops` directly.

	The difficulty here is knowing when exactly to set and unset the solib
	ops.  What I have here passes the testsuite on Linux, but with more
	testing we will probably discover more spots where it's needed.

	The C++ification patch will turn this field into a unique pointer.

	With this patch, the message we get when running "info
	linker-namespaces" becomes always the same, so update the test in
	gdb.base/dlmopen-ns-ids.exp.

	Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-06-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: use solib::ops for operations that concern a single solib
	For operations that concern a single solib, use the solib_ops backlink
	added in the previous patch (solib::ops), instead of using the solib_ops
	from the gdbarch.  This is a small / easy step towards not using
	gdbarch_so_ops, which is necessary for the C++ification patch later in
	this series.

	There is no change in behavior expected.

	Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff
	Approved-By: Pedro Alves <pedro@palves.net>

2025-06-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: add solib -> solib_ops backlink
	The subsequent C++ification commit makes it so that one struct solib_ops
	is instantiated for each program space.  For some operations, it will
	then become necessary to be able to get the right solib_ops instance
	from a given solib.  Add an solib -> solib_ops backlink for that.

	Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4
	Approved-By: Pedro Alves <pedro@palves.net>

2025-06-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: fix formatting of "info linker-namespaces" error message
	Add spaces after the first period and add a period at the end, resulting
	in:

	    (gdb) info linker-namespaces
	    ❌️ Current inferior does not support linker namespaces.  Use "info sharedlibrary" instead.

	Change-Id: Ib3f1647cedcdb68852a3c63df26ea3e6f791b1b1
	Approved-By: Pedro Alves <pedro@palves.net>

2025-06-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: check that "info shared" and "info linker-namespaces" before running don't crash
	While writing my solib_ops C++ification series, I broke this, and it
	didn't seem to be caught by the testsuite.  Add a test for those.

	The exact message for "info linker-namespaces" varies depending on the
	solib_ops of the target architecture (whether ops->num_active_namespaces
	is nullptr or not).  For now, just accept any message (a crash will
	still be caught).  A later patch in this series will make the message
	consistent and update this test.

	Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683
	Approved-By: Pedro Alves <pedro@palves.net>

2025-06-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: need to know that experiment was created on big-endian machine
	gprofng/ChangeLog
	2025-06-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* configure.ac: Add AC_C_BIGENDIAN.
		* common/config.h.in: Rebuild.
		* configure: Rebuild.
		* libcollector/collector.c (log_header_write): Save big-endian flag.
		* src/DbeSession.h (is_bigendian): New function.
		* src/DbeSession.cc: Likewise.
		* src/Experiment.cc: Set 'bigendian' and 'need_swap_endian'.
		* src/Experiment.h: New field 'bigendian'.
		* src/LoadObject.cc: Remove an unused variable.
		* src/LoadObject.h: Likewise.

2025-06-26  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove some stray "void"
	Fix these little typos from commit 5fe70629ceaf ("Change file
	initialization to use INIT_GDB_FILE macro").

	Change-Id: Ib9ae29988dfda1165de47467087f154624916629

2025-06-26  Nick Clifton  <nickc@redhat.com>

	Updated Spanish translations for opcodes and gas

2025-06-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: handle failure to start process for later attach test
	Commit:

	  commit b23903836007d1acaf7f8c059ab000ee83fcebfa
	  Date:   Tue Mar 21 13:01:26 2023 +0100

	      gdb: linux-namespaces: enter user namespace when appropriate

	added a new test gdb.base/user-namespace-attach.exp.  It has been
	reported that this test will sometimes fail, like this:

	  (gdb) attach 184732
	  Attaching to process 184732
	  warning: process 184732 is a zombie - the process has already terminated
	  ptrace: Operation not permitted.
	  (gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior

	the test tries to run the 'unshare' application.  Sometimes though,
	the application is present, but the set of flags used is not
	supported (maybe due to restrictions on the local machine), so we see
	behaviour like this:

	  $ unshare --mount --map-root-user /bin/true; echo $?
	  unshare: unshare failed: Operation not permitted
	  1

	Handle this case by first running 'unshare' with the same flags, but
	using '/bin/true', if this fails then assume the flags are not
	supported, and skip the test.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108

2025-06-26  Tom Tromey  <tromey@adacore.com>

	Change file initialization to use INIT_GDB_FILE macro
	This patch introduces a new macro, INIT_GDB_FILE.  This is used to
	replace the current "_initialize_" idiom when introducing a per-file
	initialization function.  That is, rather than write:

	    void _initialize_something ();
	    void
	    _initialize_something ()
	    {
	       ...
	    }

	... now you would write:

	    INIT_GDB_FILE (something)
	    {
	       ...
	    }

	The macro handles both the declaration and definition of the function.

	The point of this approach is that it makes it harder to accidentally
	cause an initializer to be omitted; see commit 2711e475 ("Ensure
	cooked_index_entry self-tests are run").  Specifically, the regexp now
	used by make-init-c seems harder to trick.

	New in v2: un-did some erroneous changes made by the script.

	The bulk of this patch was written by script.
	Regression tested on x86-64 Fedora 41.

2025-06-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add supports for FEAT_PoPS feature and DC instructions.
	This patch add support for FEAT_PoPS feature which can be enabled
	through +pops command line flag.

	This patch also adds support for following DC instructions and the
	spec can be found here [1].
	1. "dc cigdvaps" enabled on passing +memtag+pops command line flags.
	2. "dc civaps" enabled on passing +pops command line flag.

	[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Instructions?lang=en

2025-06-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove final m_stream->emit_style_escape calls from pager_file
	After the last commit there were still a couple of calls to
	m_stream->emit_style_escape in the pager_file class.  As discussed in
	the last commit, these are likely wrong, but I'd not been able to
	produce any bugs because of them.

	The reason why there are no bugs is that these calls are, I think,
	entirely redundant.  Consider this block:

	      if (m_wrap_column)
		{
		  /* We are about to insert a newline at an historic
		     location in the WRAP_BUFFER.  Before we do we want to
		     restore the default style.  To know if we actually
		     need to insert an escape sequence we must restore the
		     current applied style to how it was at the WRAP_COLUMN
		     location.  */
		  m_applied_style = m_wrap_style;
		  m_stream->emit_style_escape (ui_file_style ());
		  /* If we aren't actually wrapping, don't output
		     newline -- if chars_per_line is right, we
		     probably just overflowed anyway; if it's wrong,
		     let us keep going.  */
		  m_stream->puts ("\n");
		}

	What we know (see previous commit) is that the call:

	  m_stream->emit_style_escape (ui_file_style ());

	is dangerous as m_stream->m_applied_style is going to be out of sync
	with its current state.  Actually, m_stream->m_applied_style is likely
	to be the default style as it is not updated elsewhere.  So why does
	this not cause problems?

	Well, GDB's style output is always done in tightly scoped regions.
	That means if we want to print some styled output, and then apply a
	wrap point the code might look like this:

	  fprintf_styled (gdb_stdout, file_name_style, "some text");
	  gdb_stdout->wrap_here (4);

	But, after printing 'some text', the style of gdb_stdout will have
	returned to the default style.

	My claim is that, whenever we encounter a wrap_here call, the stream
	in question will _always_ have been returned to the default style.

	This means that, in the block above, the call:

	  m_stream->emit_style_escape (ui_file_style ());

	will never emit anything because it depends on a check against
	m_stream->m_applied_style, which will always mean that the above call
	does nothing.  But that's OK.  By chance, we'll have always placed the
	stream into a default style state anyway, so no harm done.

	Similarly, the other call:

	  /* Having finished inserting the wrapping we should
	     restore the style as it was at the WRAP_COLUMN.  */
	  m_stream->emit_style_escape (m_wrap_style);

	Tries to return m_stream to the state it was in at the point of the
	wrap_here call.  But, as described above, this will always be the
	default style, so the above call will do nothing, but that just
	happens to be exactly what we want!

	So what does this commit do?

	Well, I "fix" the above code by removing the
	m_stream->emit_style_escape calls and replacing them with calls to
	puts, passing in the escape sequence for the required style, but only
	if the m_stream style as tracked by pager_file::m_stream_style
	indicates this is needed.

	Got the reasons given above, this should mean there is no change after
	this patch.  We still shouldn't be emitting any extra escape
	sequences.  But, should we ever manage to get into a state where we
	call wrap_here with a stream in a style other than the default, then
	this should mean things work as expected.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: styling fixes around and for the pagination prompt
	This commit fixes a couple of issues relating to the pagination
	prompt and styling.  The pagination prompt is this one:

	  --Type <RET> for more, q to quit, c to continue without paging--

	I did try to split this into multiple patches, based on the three
	issues I describe below, but in the end, the fixes were all too
	interconnected, so it ended up as one patch that makes two related,
	but slightly different changes:

	  1. Within the pager_file class, relying on the m_applied_style
	  attribute of the wrapped m_stream, as is done when calling
	  m_stream->emit_style_escape, is not correct, so stop doing that, and

	  2. Failing to update m_applied_style within the pager_file class can
	  leave that attribute out of date, which can then lead to styling
	  errors later on, so ensure m_applied_style is always updated.

	The problems I have seen are:

	  1. After quitting from a pagination prompt, the next command can
	  incorrectly style its output.  This was reported as bug PR
	  gdb/31033, and is fixed by this commit.

	  2. The pagination prompt itself could be styled.  The pagination
	  prompt should always be shown in the default style.

	  3. After continuing the output at a pagination prompt, GDB can fail
	  to restore the default style the next time the output (within the
	  same command) switches back to the default style.

	There are tests for all these issues as part of this patch.

	The pager_file class is a sub-class of wrapped_file, this means that a
	pager_file is itself a ui_file, while it also manages a pointer to a
	ui_file object (called m_stream).  An instance of pager_file can be
	installed as the gdb_stdout ui_file object.

	Output sent to a pager_file is stored within an internal
	buffer (called m_wrap_buffer) until we have a complete line, when the
	content is flushed to the wrapped m_stream.  If sufficient lines have
	been written out then the pager_file will present the pagination
	prompt and allow the user to continue viewing output, or quit the
	current command.

	As a pager_file is a ui_file, it has an m_applied_style member
	variable.

	The managed stream (m_stream) is also a ui_file, and so also has an
	m_applied_style member variable.

	In some places within the pager_file class we attempt to change the
	current style of the m_stream using calls like this:

	  m_stream->emit_style_escape (style);

	See pager_file::emit_style_escape, pager_file::prompt_for_continue,
	and pager_file::puts.  These calls will end up in
	ui_file::emit_style_escape, which tries to skip emitting unnecessary
	style escapes by checking if the requested style matches the current
	m_applied_style value.

	The m_applied_style value is updated by calls to the emit_style_escape
	function.

	The problem here is that most of the time pager_file doesn't change
	the style of m_stream by calling m_stream->emit_style_escape.  Most of
	the time, style changes are performed by pager_file writing the escape
	sequence into m_wrap_buffer, and then later flushing this buffer to
	m_stream by calling m_stream->puts.

	It has to be done this way.  Calling m_stream->emit_style_escape
	would, if it actually changed the style, immediately change the style
	by emitting an escape sequence.  But pager_file doesn't want that, it
	wants the style change to happen later, when m_wrap_buffer is
	flushed.

	To avoid excessive style escape sequences being written into
	m_wrap_buffer, the pager_file::m_applied_style performs a function
	similar to the m_applied_style within m_stream, it tracks the current
	style for the end of m_wrap_buffer, and only allows style escape
	sequences to be emitted if the style is actually changing.

	However, a consequence of this is the m_applied_style within m_stream,
	is not updated, which means it will be out of sync with the actual
	current style of m_stream.  If we then try to make a call to
	m_stream->emit_style_escape, if the style we are changing too happens
	to match the out of date style in m_stream->m_applied_style, then the
	style change will be ignored.

	And this is indeed what we see in pager_file::prompt_for_continue with
	the call:

	  m_stream->emit_style_escape (ui_file_style ());

	As m_stream->m_applied_style is not being updated, it will always be
	the default style, however m_stream itself might not actually be in
	the default style.  This call then will not emit an escape sequence as
	the desired style matches the out of date m_applied_style.

	The fix in this case is to call m_stream->puts directly, passing in
	the escape sequence for the desired style.  This will result in an
	immediate change of style for m_stream, which fixes some of the
	problems described above.

	In fact, given that m_stream's m_applied_style is always going to be
	out of sync, I think we should change all of the
	m_stream->emit_style_escape calls to instead call m_stream->puts.

	However, just changing to use puts doesn't fix all the problems.

	I found that, if I run 'apropos time', then quit at the first
	pagination prompt.  If for the next command I run 'maintenance time' I
	see the expected output:

	  "maintenance time" takes a numeric argument.

	However, everything after the first double quote is given the command
	name style rather than only styling the text between the double
	quotes.

	Here is GDB's stack while printing the above output:

	  #2  0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754
	  #3  0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73
	  #4  0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905
	  #5  0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945
	  #6  0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128

	The interesting frames here are #3, in here `this` is the pager_file
	for GDB's stdout, and this passes its m_applied_style to frame #2 as
	the `in_style` argument.

	If the m_applied_style is wrong, then frame #2 will believe that the
	wrong style is currently in use as the default style, and so, after
	printing 'maintenance time' GDB will switch back to the wrong style.

	So the question is, why is pager_file::m_applied_style wrong?

	In pager_file::prompt_for_continue, there is an attempt to switch back
	to the default style using:

	  m_stream->emit_style_escape (ui_file_style ());

	If this is changed to a puts call (see above) then this still leaves
	pager_file::m_applied_style out of date.

	The right fix in this case is, I think, to instead do this:

	  this->emit_style_escape (ui_file_style ());

	this will update pager_file::m_applied_style, and also send the
	default style to m_stream using a puts call.

	While writing the tests I noticed that I was getting unnecessary style
	reset sequences emitted.

	The problem is that, around pagination, we don't really know what
	style is currently applied to m_stream.  The
	pager_file::m_applied_style tracks the style at the end of
	m_wrap_buffer, but this can run ahead of the current m_stream style.
	For example, if the screen is currently full, such that the next
	character of output will trigger the pagination prompt, if the next
	call is actually to pager_file::emit_style_escape, then
	pager_file::m_applied_style will be updated, but the style of m_stream
	will remain unchanged.  When the next character is written to
	pager_file::puts then the pagination prompt will be presented, and GDB
	will try to switch m_stream back to the default style.  Whether an
	escape is emitted or not will depend on the m_applied_style value,
	which we know is different than the actual style of m_stream.

	It is, after all, only when m_wrap_buffer is flushed to m_stream that
	the style of m_stream actually change.

	And so, this commit also adds pager_file::m_stream_style.  This new
	variable tracks the current style of m_stream.  This really is a
	replacement for m_stream's ui_file::m_applied_style, which is not
	accessible from pager_file.

	When content is flushed from m_wrap_buffer to m_stream then the
	current value of pager_file::m_applied_style becomes the current style
	of m_stream.  But, when m_wrap_buffer is filling up, but before it is
	flushed, then pager_file::m_applied_style can change, but
	m_stream_style will remain unchanged.

	Now in pager_file::emit_style_escape we are able to skip some of the
	direct calls to m_stream->puts() used to emit style escapes.

	After all this there are still a few calls to
	m_stream->emit_style_escape().  These are all in the wrap_here support
	code.  I think that these calls are technically broken, but don't
	actually cause any issues due to the way styling works in GDB.  I
	certainly haven't been able to trigger any bugs from these calls yet.
	I plan to "fix" these in the next commit just for completeness.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31033

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-warning.exp with python 3.6
	On openSUSE Tumbleweed (with python 3.13), I get:
	...
	(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
	python gdb.warning()^M
	Python Exception <class 'TypeError'>: \
	  function missing required argument 'text' (pos 1)^M
	Error occurred in Python: function missing required argument 'text' (pos 1)^M
	(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning()
	...

	But on openSUSE Leap 15.6 (with python 3.6), I get instead:
	...
	(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
	python gdb.warning()^M
	Python Exception <class 'TypeError'>: \
	  Required argument 'text' (pos 1) not found^M
	Error occurred in Python: Required argument 'text' (pos 1) not found^M
	(gdb) FAIL: gdb.python/py-warning.exp: python gdb.warning()
	...

	Fix this by updating the regexp.

	Tested on x86_64-linux.

	PR testsuite/33104
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33104

2025-06-25  Matthieu Longo  <matthieu.longo@arm.com>

	readelf: invalid error message triggered when last tag is an empty string
	Disclaimer: this issue cannot occur with Object Attributes v1 (OAv1) while
	using the GNU binutils because a value of '\0' (empty string) for a tag
	with a string value is considered as the default value for the attribute,
	and consequently is eliminated by gas from the output object file during
	the serialization.

	An empty string is a valid value for a NTBS tag in both OAv1 and OAv2 [1]
	cases. However, contrarily to OAv1, a OAv2 subsection can be required and
	so, tags in this subsection might have to be present even if the value is
	the default. To comply with this requirement, the OAv2 serializer won't
	drop the default values.

	In the case where a NTBS tag has the value '\0' and is last in the object
	attributes section, the current code in readelf used for dumping the object
	attributes incorrectly detects an overflow, and prints out an error message
	for a corrupted string tag.

	This patch fixes the detection of the overflow so that it now accept an
	empty string in the last tag of the object attributes section.

	It also fixes the previous tests for the empty NTBS case and the non-null
	terminated string one. The fix was also tested in the context of OAv2's
	patch series [1] where the issue was originally detected. No regression
	was found.

	[1]: https://inbox.sourceware.org/binutils/20250509151319.88725-1-matthieu
	     .longo@arm.com/

2025-06-25  Matthieu Longo  <matthieu.longo@arm.com>

	arm testsuite: add two corner cases for EABI string attributes
	The current testsuite for gas/readelf lacked two tests for EABI build
	attributes:
	- one when the final attribute is an empty string.
	- one when the final attribute is a string missing the NULL terminator.

	Those two issues cannot occur with Object Attributes v1 (OAv1) sections
	created by the GNU binutils. Indeed a value of '\0' (empty string) for a
	tag with a string value is considered as the default value for the
	attribute, and consequently is eliminated by Gas from the output object
	file during the serialization.
	However, readelf should be able to process correctly files of an unknown
	origin that could contain those two use cases.

	This patch adds the two tests mentioned above. The first one is marked
	as XFAIL because the empty string is not processed correctly by readelf
	when it is in the last position. The second one passes, but simply print
	out "[...]" without mentioning that the NTBS is corrupted.

	A following patch will fix the bug in readelf, and will amend the newly
	introduced tests.

2025-06-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/infcall-failure.exp on freebsd
	On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get:
	...
	(gdb) continue
	Continuing.

	Program received signal SIGSEGV, Segmentation fault.
	Address not mapped to object.
	0x0000000000400522 in func_segfault () at infcall-failure.c:24
	24	  return *p;	/* Segfault here.  */
	Error in testing condition for breakpoint 2:
	The program being debugged was signaled while in a function called from GDB.
	GDB remains in the frame where the signal was received.
	To change this behavior use "set unwind-on-signal on".
	Evaluation of the expression containing the function
	(func_segfault) will be abandoned.
	When the function is done executing, GDB will silently stop.
	(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
	  run_cond_hits_segfault_test: continue
	...

	The problem is that the regexp in the test-case doesn't expect the
	"Address not mapped to object." bit.

	Fix this by updating the regexp.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	Tested on x86_64-freebsd and x86_64-linux.

2025-06-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-24  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Profiles RVA/B23S64 support.
	This patch adds support for the RISC-V Profiles RVA23S64 and RVB23S64.

	Version log:
	Fix wrong test for rvb23s.

	bfd/ChangeLog:

		* elfxx-riscv.c: New Profiles.

	gas/ChangeLog:

		* testsuite/gas/riscv/attribute-rva23s.d: New test.
		* testsuite/gas/riscv/attribute-rvb23s.d: New test.

2025-06-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.dap/log-message.exp more robust
	PR testsuite/31831 reports the following failure in the
	gdb.dap/log-message.exp test-case (formatted for readability):
	...
	{ "type": "event",
	  "event": "output",
	  "body": {
	    "category": "stdout",
	    "output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n"
	  },
	  "seq": 13
	}
	FAIL: $exp: logging output (checking body category)
	...
	for a gdb 14.2 based package.

	The output event listed above is a result from the setBreakpoints request.

	The test-case issues the setBreakpoints request and waits for the
	corresponding response, but doesn't wait for the output event, and
	consequently the output event is read by:
	...
	dap_wait_for_event_and_check "logging output" output \
	    {body category} console \
	    {body output} "got 23 - 23 = 0"
	...
	which triggers the failure.

	I'm not able to reproduce this, but it looks worth fixing regardless.

	We're fixing this on trunk though, and the output event looks different, and
	there's one more output event:
	...
	{ "type": "event",
	  "event": "output",
	  "body": {
	    "category": "stdout",
	    "output": "No source file named log-message.c.\n"
	  },
	  "seq": 4
	}
	{ "type": "event",
	  "event": "output",
	  "body": {
	    "category": "stdout",
	    "output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n"
	  },
	  "seq": 5
	}
	...

	Fix this by waiting for these two output events, making the test-case a bit
	more robust.

	It is possible that one or both of these output events will be read by
	dap_check_request_and_response "set breakpoint", and in that case restashing
	them (for which there's currently no infrastructure) would be an easy way of
	handling this.  But I haven't been able to trigger that, so I'm leaving that
	for if and when it does.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831

2025-06-24  Tom Tromey  <tromey@adacore.com>

	Allow DAP "threads" request when inferior is running
	A user pointed out that DAP allows the "threads" request to work when
	the inferior is running.  This is documented in the overview, not the
	specification.

	While looking into this, I found a few other issues:

	* The _thread_name function was not marked @in_gdb_thread.
	  This isn't very important but is still an oversight.

	* DAP requires all threads to have a name -- the field is not optional
	  in the "Thread" type.

	* There was no test examining events resulting from the inferior
	  printing to stdout.

	This patch fixes all these problems.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33080

2025-06-24  Tom Tromey  <tromey@adacore.com>

	Use "MS" for .debug_str
	I changed my system linker to 'mold', but then I saw some gdb test
	failures.  This patch fixes a subset of the failures.

	dw2-strp.exp was failing, and investigating showed that there were two
	.debug_str sections.  I tracked this down to the .S file not using the
	correct section flags.

	This patch fixes this problem, plus the other instances I could find.
	(Strangely, these did not all cause problems, however.)  I also
	changed the DWARF assembler to always use these flags for .debug_str.

2025-06-24  Jan Beulich  <jbeulich@suse.com>

	gas/doc: -v / -version / --version / --verbose
	Split -v from -version/--version. They aren't the same; -v long form is
	--verbose, which so far wasn't mentioned at all.

2025-06-24  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Update Profiles string in RV23.
	Update the Profiles string in RV23 to include the extensions 'b' and 'supm'.

	bfd/ChangeLog:

		* elfxx-riscv.c: Update Profiles string in RV23.

	gas/ChangeLog:

		* testsuite/gas/riscv/attribute-19.d: Update test string.
		* testsuite/gas/riscv/attribute-20.d: Ditto.

2025-06-24  Nelson Chu  <nelson@rivosinc.com>

	gas/NEWS: Updated for RISC-V

	ld/NEWS,binutils/NEWS: Updated supports for RISC-V zicfiss and zicfilp

	RISC-V: Fxied failed testsuites when building rv32-linux

2025-06-24  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Support for unlabeled landing pad PLT generation
	This patch adds support for generating unlabeled landing pad PLT entries
	for the RISC-V architecture. Unlabeled landing pad will place a LPAD
	instruction at the PLT entry and PLT header, also PLT header will have
	few changes due to the offset is different from the original one.

	Ref: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417

2025-06-24  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Implment the merge logic for GNU_PROPERTY_RISCV_FEATURE_1_AND
	GNU_PROPERTY_RISCV_FEATURE_1_AND will perform a bitwise AND operation
	on the properties of the input files.

2025-06-24  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Add GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED
	This patch adds two new GNU properties for RISC-V:
	GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED.

	We only add readelf and define the properties in this patch.

	Ref: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417

2025-06-24  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Refactor PLT generation
	The goal of this refactor is to improve the possiblity of having
	different PLT generation code for different RISC-V ABIs. The changes
	include:
	- Extract PLT generation logic into individual functions.
	- Keep the PLT generation data in riscv_elf_link_hash_table.

	In the following patches, we will use this framework to implement
	different PLT.

2025-06-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-23  Pawel Kupczak  <pawel.kupczak@intel.com>

	gdb: return after stack alignment skip if current_pc is reached
	Make sure we bail out early from amd64_analyze_prologue if CURRENT_PC
	is reached to avoid unnecessary call to amd64_analyze_frame_setup.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-23  Pawel Kupczak  <pawel.kupczak@intel.com>

	gdb: correct endbr64 instruction handling in amd64_analyze_prologue
	Compilers can put a sequence aligning the stack at the entry of a
	function.  However with -fcf-protection enabled, "endbr64" is
	generated before.  Current implementation of amd64 prologue analyzer
	first checks for stack alignment and then for "endbr64", which is not
	correct.  This behavior was introduced with patch "gdb: handle endbr64
	instruction in amd64_analyze_prologue".  In case both are generated,
	prologue will not be skipped.  This patch swaps the order so that
	"endbr64" is checked first and adds a regression test.  i386-tdep
	implementation also already had those checked in the correct order,
	that is stack alignment is after endbr64.

	Given such source compiled with gcc 11.4.0 via:
	gcc -O0 main.c -o main

	```
		#include <alloca.h>

		void
		foo (int id)
		{
		  volatile __attribute__ ((__aligned__ (64))) int a;
		  volatile char *p = (char *) alloca (id * 12);
		  p[2] = 'b';
		}

		int
		main (int argc, char **argv)
		{
		  foo (argc + 1);
		  return 1;
		}
	```

	we get such function entry for foo (generated with objdump -d):
	```
	0000000000001149 <foo>:
	    1149:       f3 0f 1e fa             endbr64
	    114d:       4c 8d 54 24 08          lea    0x8(%rsp),%r10
	    1152:       48 83 e4 c0             and    $0xffffffffffffffc0,%rsp
	    1156:       41 ff 72 f8             push   -0x8(%r10)
	    115a:       55                      push   %rbp
	    115b:       48 89 e5                mov    %rsp,%rbp
	    115e:       41 52                   push   %r10
	    1160:       48 81 ec a8 00 00 00    sub    $0xa8,%rsp
	    1167:       89 7d 8c                mov    %edi,-0x74(%rbp)
	...
	```

	The 3 instructions following endbr64 align the stack.  If we were to set
	a breakpoint on foo, gdb would set it at function's entry:
	```
	(gdb) b foo
	Breakpoint 1 at 0x1149
	(gdb) r
	...
	Breakpoint 1, 0x0000555555555149 in foo ()
	(gdb) disassemble
	Dump of assembler code for function foo:
	=> 0x0000555555555149 <+0>:     endbr64
	   0x000055555555514d <+4>:     lea    0x8(%rsp),%r10
	   0x0000555555555152 <+9>:     and    $0xffffffffffffffc0,%rsp
	   0x0000555555555156 <+13>:    push   -0x8(%r10)
	   0x000055555555515a <+17>:    push   %rbp
	   0x000055555555515b <+18>:    mov    %rsp,%rbp
	   0x000055555555515e <+21>:    push   %r10
	   0x0000555555555160 <+23>:    sub    $0xa8,%rsp
	   0x0000555555555167 <+30>:    mov    %edi,-0x74(%rbp)
	...
	```

	With this patch fixing the order of checked instructions, gdb can
	properly analyze the prologue:
	```
	(gdb) b foo
	Breakpoint 1 at 0x115e
	(gdb) r
	...
	Breakpoint 1, 0x000055555555515e in foo ()
	(gdb) disassemble
	Dump of assembler code for function foo:
	   0x0000555555555149 <+0>:     endbr64
	   0x000055555555514d <+4>:     lea    0x8(%rsp),%r10
	   0x0000555555555152 <+9>:     and    $0xffffffffffffffc0,%rsp
	   0x0000555555555156 <+13>:    push   -0x8(%r10)
	   0x000055555555515a <+17>:    push   %rbp
	   0x000055555555515b <+18>:    mov    %rsp,%rbp
	=> 0x000055555555515e <+21>:    push   %r10
	   0x0000555555555160 <+23>:    sub    $0xa8,%rsp
	   0x0000555555555167 <+30>:    mov    %edi,-0x74(%rbp)
	...
	```

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-23  Pawel Kupczak  <pawel.kupczak@intel.com>

	gdb: refactor amd64_analyze_prologue
	Refactor amd64_analyze_prologue so it clearly reflects what is the order
	of operations in the prologue that we expect to encounter, as is the
	case for i386's implementation.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: use TESTS from make-check-all.sh
	Update the make-check-all.sh script to use TESTS rather than passing
	the test names within RUNTESTFLAGS.  This addresses the following
	issue:

	I was running some tests like this:

	  make -C gdb check-all-boards TESTS="gdb.base/break*.exp"

	And I was finding that I would get lots of DUPLICATE test results,
	which is not what I expected.

	What's happening here is that the 'make check-all-boards' rule runs
	the 'make-check-all.sh' script, which then runs 'make check' with
	various board files.

	However, passing TESTS=... to the initial 'make check-all-boards'
	command invocation automatically causes the TESTS value to be added to
	the MAKEFLAGS environment variable, this is then picked up by the
	later calls to 'make check'.

	Now, in GDB's testfile/Makefile, we check for TESTS, and if this is
	set, we expand the value and set `expanded_tests_or_none`.  Otherwise,
	if TESTS is not set, expanded_tests_or_none is left empty.

	Finally, when handling 'make check', the value of
	`expanded_tests_or_none` is passed through to dejagnu, along with the
	RUNTESTFLAGS value.

	What this means is that, when make-check-all.sh passes the test names
	in the RUNTESTFLAGS, then dejagnu ends up seeing the list of tests
	twice, once from RUNTESTFLAGS, and once from expanded_tests_or_none,
	and this is why I was seeing duplicate testnames.

	The easiest fix for the above is to have make-check-all.sh pass the
	test names using TESTS="...", this will override the TESTS="..." value
	already present in MAKEFLAGS, and means dejagnu will see the test
	names just once.

	Additionally, this is a start towards allowing parallel test running
	from the make-check-all.sh script.  Parallel test running only works
	if the test names are passed in TESTS, and not in RUNTESTFLAGS.
	Currently, in testsuite/Makefile, if RUNTESTFLAGS is not empty, then
	we force single threaded test running.  But with this change, at least
	for the `local` board, we can now benefit from multi-threaded test
	running, as this board has an empty RUNTESTFLAGS now.  For the other
	boards we'd need to set FORCE_PARALLEL in order to benefit from
	parallel test running, but we'll need to double check that all the
	board files actually support parallel test running first, so I'm
	leaving that for another day.

2025-06-23  H.J. Lu  <hjl.tools@gmail.com>

	objcopy: Don't extend the output section size
	Since the output section contents are copied from the input, don't
	extend the output section size beyond the input section size.

		PR binutils/33049
		* objcopy.c (copy_section): Don't extend the output section
		size beyond the input section size.

2025-06-23  H.J. Lu  <hjl.tools@gmail.com>

	elf: Report corrupted group section
	Report corrupted group section instead of trying to recover.

		PR binutils/33050
		* elf.c (bfd_elf_set_group_contents): Report corrupted group
		section.

2025-06-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: filename completion for pipe command -- the shell command bit
	This commit adds filename completion for the shell command part of
	the pipe command.  This is a follow on from this commit:

	  commit 036e5c0c9121d0ac691dbf408a3bdf2bf3501d0f
	  Date:   Mon May 19 20:54:54 2025 +0100

	      gdb: use quoted filename completion for the shell command

	which fixed the completion for the 'shell' command itself.

	Like with the 'shell' command, we don't offer completions of command
	names pulled from $PATH, we just offer filename completion, which is
	often useful for arguments being passed to commands.  Maybe in the
	future we could add completion for command names too (for both 'pipe'
	and the 'shell' command), but that is left for a future commit.

	There's some additional testing.

2025-06-23  Benjamin Berg  <benjamin@sipsolutions.net>

	gdb: linux-namespaces: enter user namespace when appropriate
	The use of user namespaces is required for normal users to use mount
	namespaces.  Consider trying this as an unprivileged user:

	  $ unshare --mount /bin/true
	  unshare: unshare failed: Operation not permitted

	The problem here is that an unprivileged user doesn't have the
	required permissions to create a new mount namespace.  If, instead, we
	do this:

	  $ unshare --mount --map-root-user /bin/true

	then this will succeed.  The new option causes unshare to create a
	user namespace in which the unprivileged user is mapped to UID/GID 0,
	and so gains all privileges (inside the namespace), the user is then
	able to create the mount namespace as required.

	So, how does this relate to GDB?

	When a user attaches to a process running in a separate mount
	namespace, GDB makes use of a separate helper process (see
	linux_mntns_get_helper in nat/linux-namespaces.c), which will then use
	the `setns` function to enter (or try to enter) the mount namespace of
	the process GDB is attaching too.  The helper process will then handle
	file I/O requests received from GDB, and return the results back to
	GDB, this allows GDB to access files within the mount namespace.

	The problem here is that, switching to a mount namespace requires that
	a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within
	its user namespace (actually it's a little more complex, see 'man 2
	setns').  Assuming GDB is running as an unprivileged user, then GDB
	will not have the required permissions.

	However, if GDB enters the user namespace that the `unshare` process
	created, then the current user will be mapped to UID/GID 0, and will
	have the required permissions.

	And so, this patch extends linux_mntns_access_fs (in
	nat/linux-namespace.c) to first try and switch to the user namespace
	of the inferior before trying to switch to the mount namespace.  If
	the inferior does have a user namespace, and does have elevated
	privileges within that namespace, then this first switch by GDB will
	mean that the second step, into the mount namespace, will succeed.

	If there is no user namespace, or the inferior doesn't have elevated
	privileges within the user namespace, then the switch into the mount
	namespace will fail, just as it currently does, and the user will need
	to give elevated privileges to GDB via some other mechanism (e.g. run
	as root).

	This work was originally posted here:

	  https://inbox.sourceware.org/gdb-patches/20230321120126.1418012-1-benjamin@sipsolutions.net

	I (Andrew Burgess) have made some cleanups to the code to comply with
	GDB's coding standard, and the test is entirely mine.  This commit
	message is also entirely mine -- the original message was very terse
	and required the reader to understand how the various namespaces
	work and interact.  The above is my attempt to document what I now
	understand about the problem being fixed.

	I've left the original author in place as the core of the GDB change
	itself is largely as originally presented, but any inaccuracies in the
	commit message, or problems with the test, are all mine.

	Co-Authored-by: Andrew Burgess <aburgess@redhat.com>

2025-06-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: only use /proc/PID/exe for local f/s with no sysroot
	This commit works around a problem introduced by commit:

	  commit e58beedf2c8a1e0c78e0f57aeab3934de9416bfc
	  Date:   Tue Jan 23 16:00:59 2024 +0000

	      gdb: attach to a process when the executable has been deleted

	The above commit extended GDB for Linux, so that, of the executable
	for a process had been deleted, GDB would instead try to use
	/proc/PID/exe as the executable.

	This worked by updating linux_proc_pid_to_exec_file to introduce the
	/proc/PID/exe fallback.  However, the result of
	linux_proc_pid_to_exec_file is then passed to exec_file_find to
	actually find the executable, and exec_file_find, will take into
	account the sysroot.  In addition, if GDB is attaching to a process in
	a different MNT and/or PID namespace then the executable lookup is
	done within that namespace.

	This all means two things:

	  1. Just because linux_proc_pid_to_exec_file cannot see the
	     executable doesn't mean that GDB is actually going to fail to
	     find the executable, and

	  2. returning /proc/PID/exe isn't useful if we know GDB is then going
	     to look for this within a sysroot, or within some other
	     namespace (where PIDs might be different).

	There was an initial attempt to fix this issue here:

	  https://inbox.sourceware.org/gdb-patches/20250511141517.2455092-4-kilger@sec.in.tum.de/

	This proposal addresses the issue in PR gdb/32955, which is all about
	the namespace side of the problem.  The fix in this original proposal
	is to check the MNT namespace inside linux_proc_pid_to_exec_file, and
	for the namespace problem this is fine.  But we should also consider
	the sysroot problem.

	And for the sysroot problem, the fix cannot fully live inside
	linux_proc_pid_to_exec_file, as linux_proc_pid_to_exec_file is shared
	between GDB and gdbserver, and gdbserver has no sysroot.

	And so, I propose a slightly bigger change.

	Now, linux_proc_pid_to_exec_file takes a flag which indicates if
	GDB (or gdbserver) will look for the inferior executable in the
	local file system, where local means the same file system as GDB (or
	gdbserver) is running in.

	This local file system check is true if:

	  1. The MNT namespace of the inferior is the same as for GDB, and

	  2. for GDB only, the sysroot must either be empty, or 'target:'.

	If the local file system check is false then GDB (or gdbserver) is
	going to look elsewhere for the inferior executable, and so, falling
	back to /proc/PID/exe should not be done, as GDB will end up looking
	for this file in the sysroot, or within the alternative MNT
	namespace (which in also likely to be a different PID namespace).

	Now this is all a bit of a shame really.  It would be nice if
	linux_proc_pid_to_exec_file could return /proc/PID/exe in such a way
	that exec_file_find would know that the file should NOT be looked for
	in the sysroot, or in the alternative namespace.  But fixing that
	problem would be a much bigger change, so for now lets just disable
	the /proc/PID/exe fallback for cases where it might not work.

	For testing, the sysroot case is now tested.

	I don't believe we have any alternative namespace testing.  It would
	certainly be interesting to add some, but I'm not proposing any with
	this patch, so the code for checking the MNT namespace has been tested
	manually by me, but isn't covered by a new test I'm adding here.

	Author of the original fix is listed as co-author here.  Credit for
	identifying the original problem, and proposing a solution belongs to
	them.

	Co-Authored-By: Fabian Kilger <kilger@sec.in.tum.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32955

2025-06-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: better warning when attaching, and executable is unknown
	Currently, when attaching to a process, if the user hasn't told GDB
	which executable they are going to be debugging, GDB will try to
	figure out the executable from the running process.

	There are two (for this patch) interesting places where this can fail,
	both in exec_file_locate_attach.

	First GDB calls target_pid_to_exec_file, this does target specific
	"stuff" to find the name of the executable file.  If this returns NULL
	then GDB will give a warning and return.

	After this we need to "find" the executable.  This is where we apply
	things like the sysroot in order to transform the executable path.
	This is done by calling exec_file_find, and this too can return NULL
	to indicate that the executable couldn't be found.

	Currently, if exec_file_find returns NULL then GDB doesn't give a
	warning, instead we push on and call try_open_exec_file passing in the
	NULL pointer as the filename string.  This has the effect of removing
	the current executable from the current program space.

	However, exec_file_locate_attach already checks there is no executable
	attached to the current program space.  If there was, then there would
	be no need to try and lookup the executable from the running process.
	So calling try_open_exec_file with a NULL string is, I claim,
	pointless.

	But worse, calling try_open_exec_file with a NULL string means that
	GDB prints the message: "No executable file now.", which, while
	correct, isn't (I think) very helpful.  To me this message indicates
	that we've moved from a state of having an executable to a state of
	not having one, which isn't correct.

	I think we should introduce a new warning in exec_file_locate_attach,
	which is printed if the executable cannot be found.

	So, before this patch GDB's output looked like this:

	  (gdb) attach 12345
	  Attaching to process 12345
	  No executable file now.
	  warning: Could not load vsyscall page because no executable was specified
	  0x00007f0978b94557 in ?? ()
	  (gdb)

	After this patch the output now looks like this:

	  (gdb) attach 12345
	  Attaching to process 12345
	  No executable has been specified, and target executable /tmp/my-exec (deleted) could not be found.  Try using the "file" command.
	  warning: Could not load vsyscall page because no executable was specified
	  0x00007f0978b94557 in ?? ()
	  (gdb)

	This warning includes the name of the file that GDB was looking for,
	and gives a hint that the 'file' command should be used to tell GDB
	which executable is being debugged.  Much better.

	There's no test for this change in this commit.  The next commit fixes
	another (semi-related) bug, and includes a test that checks for this
	warning string.

2025-06-23  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: include sys/stat.h for 'struct stat'
	Tom de Vries reported a build failure on x86_64-w64-mingw32 after
	commit:

	  commit bd389c9515d240f55b117075b43184efdea41287
	  Date:   Wed Jun 11 22:52:16 2025 +0200

	      gdb: implement linux namespace support for fileio_lstat and vFile::lstat

	The build failure looks like this:

	  ../../src/gdbserver/hostio.cc: In function 'void handle_lstat(char*, int*)':
	  ../../src/gdbserver/hostio.cc:544:63: error: cannot convert '_stat64*' to 'stat*'
	    544 |     ret = the_target->multifs_lstat (hostio_fs_pid, filename, &st);
	        |                                                               ^~~
	        |                                                               |
	        |                                                               _stat64*
	  In file included from ./../../src/gdbserver/server.h:58,
	                   from <command-line>:
	  ./../../src/gdbserver/target.h:448:74: note:   initializing argument 3 of 'virtual int process_stratum_target::multifs_lstat(int, const char*, stat*)'
	    448 |   virtual int multifs_lstat (int pid, const char *filename, struct stat *sb);
	        |                                                             ~~~~~~~~~~~~~^~

	The problem is that in sys/stat.h for mingw, 'stat' is #defined to
	_stat64, but target.h doesn't include sys/stat.h, and so doesn't see
	this #define.

	However, target.h does, by luck, manages to see the actual definition
	of 'struct stat', which isn't in sys/stat.h itself, but is in some
	other header that just happens to be pulled in by chance.

	As a result of all this, the declaration of
	process_stratum_target::multifs_lstat in target.h uses 'struct stat'
	for its argument type, while the call in hostio.cc, uses 'struct
	_stat64' as its argument type, which causes the build error seen
	above.

	The fix is to include sys/stat.h in target.h so that the declaration's
	argument type will change to 'struct _stat64' (via the #define).

2025-06-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-21  Stafford Horne  <shorne@gmail.com>

	or1k: Fix disassembly for little-endian binaries
	There are some OpenRISC CPUs that have their binaries stored in
	little-endian format.  Using objdump to disassemble these is
	problematic, as some instructions fail to disassemble, for example:

	    objdump -D -b binary -EB -m or1k test_be.bin

	       0:	18 60 07 27 	l.movhi r3,0x727
	       4:	a8 63 0e 00 	l.ori r3,r3,0xe00
	       8:	9c 63 ff ff 	l.addi r3,r3,-1
	       c:	bc 43 00 00 	l.sfgtui r3,0
	      10:	13 ff ff fe 	l.bf 0x8
	      14:	44 00 48 00 	l.jr r9

	    objdump -D -b binary -EL -m or1k test_le.bin

	       0:	27 07 60 18 	*unknown*
	       4:	00 0e 63 a8 	l.ori r3,r3,0xe00
	       8:	ff ff 63 9c 	*unknown*
	       c:	00 00 43 bc 	l.sfgtui r3,0
	      10:	fe ff ff 13 	*unknown*
	      14:	00 48 00 44 	l.jr r9

	It was found that the hash function was using the still little-endian
	buffer to extract the opcode used for the hash lookup.  This didn't work
	as it was pulling the wrong hashcode causing instruction lookup to fail.

	Fix the hash function by using the normalized/byte-swapped value instead
	of the buffer.

2025-06-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-20  Aleksandar Rikalo  <arikalo@gmail.com>

	gdbsupport: Use xsnprintf() instead of strcat() in print-utils
	Theoretically, in functions core_addr_to_string_nz() and
	core_addr_to_string(), strcat() can overflow, so use a safe
	approach using xsnprintf().

	Change-Id: Ib9437450b3634dc35077234f462a03a8640242d4

2025-06-20  Aleksandar Rikalo  <arikalo@gmail.com>

	gdb: Remove redundant null check
	This patch simplifies the code at two points by removing redundant
	null checks.  There is no functional impact.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Pedro Alves <pedro@palves.net>
	Change-Id: I76e1c7fad00e8fcb24ced7bfd75d19cdd6266c32

2025-06-20  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Support 2024 Debug Architecture system registers.
	This patch adds support for following system registers and the spec
	can be found here[1].
	1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE
	   and Armv9.5-A architecture and these are enabled by passing
	   -march=armv9.5-a+profile.
	2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture
	   and these are enabled by passing -march=armv9.5-a.
	3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing
	   -march=armv8.8-a.

	[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Registers?lang=en

2025-06-20  Kirill Radkin  <kirill.radkin@syntacore.com>

	gdbserver: Update require_int function to parse offset for pread packet
	Currently gdbserver uses the require_int() function to parse the
	requested offset (in vFile::pread packet and the like).  This function
	allows integers up to 0x7fffffff (to fit in 32-bit int), however the
	offset (for the pread system call) has an off_t type which can be
	larger than 32-bit.

	This patch allows require_int() function to parse offset up to the
	maximum value implied by the off_t type.

	Approved-By: Pedro Alves <pedro@palves.net>
	Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c

2025-06-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: run isort on gdb.server/fileio-packets.py
	`pre-commit run --all-files` found this.

	Change-Id: I8db09b12cf184d32351ff2c579bdaa8cf6f80ac3

2025-06-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: change CUs -> units in print_stats
	Change the messages to reflect that these numbers includes type units,
	not only compile units.

	Change-Id: Id2f511d4666e5cf92112be917d72ff76791b7e1d
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-06-19  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_LSFE
	FEAT_LSFE - Large System Float Extension - implements A64 base atomic
	floating-point in-memory instructions.

2025-06-19  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_SVE_F16F32MM, FEAT_F8F16M, FEAT_F8F32MM
	FEAT_SVE_F16F32MM introduces the SVE half-precision floating-point
	matrix multiply-accumulate to single-precision instruction.

	FEAT_F8F32MM introduces the Advanced SIMD 8-bit floating-point matrix
	multiply-accumulate to single-precision instruction.

	FEAT_F8F16MM introduces the Advanced SIMD 8-bit floating-point matrix
	multiply-accumulate to half-precision instruction.

2025-06-19  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_CMPBR
	FEAT_CMPBR - Compare and branch instructions. This patch adds these
	instructions:
	- CB<CC> (register)
	- CB<CC> (immediate)
	- CBH<CC>
	- CBB<CC>

	where CC is one of the following:
	- EQ
	- NE
	- GT
	- GE
	- LT
	- LE
	- HI
	- HS
	- LO
	- LS

2025-06-19  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Add occmo flag for FEAT_OCCMO
	FEAT_OCCMO support was introduced, but the feature flags were missing.
	This patch adds these flags, as well as splitting up the tests to test
	occmo vs occmo+memtag operands.

	aarch64: Support for FEAT_SVE_BFSCALE
	FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in
	Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also
	introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE
	and BFMUL.

2025-06-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: introduce gdb.warning() function
	This commit adds a new gdb.warning() function.  This function takes a
	string and then calls GDB's internal warning() function.  This will
	display the string as a warning.

	Using gdb.warning() means that the message will get the new emoji
	prefix if the user has that feature turned on.  Also, the message will
	be sent to gdb.STDERR without the user having to remember to print to
	the correct stream.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-18  WANG Xuerui  <git@xen0n.name>

	LoongArch: Batch-delete bytes at the end of each relax trip
	Previously, memmove and reloc/symbol adjustments happened at each
	loongarch_relax_delete_bytes() call, which is O(n^2) time complexity and
	leads to unacceptable (multiple hours) linking times for certain inputs
	with huge number of relaxable sites -- see the linked issue for details.

	To get rid of the quadratic behavior, defer all delete ops to the end of
	each relax trip, with the buffer implemented with the splay tree from
	libiberty. The individual relaxation handlers are converted to handle
	symbol values and relocation offsets as if all preceding deletions
	actually happened, by querying a cumulative offset from the splay tree;
	the accesses should be efficient because they are mostly sequential
	during a relaxation trip. The exact relaxation behavior remains largely
	unchanged.

	Example running times before and after the change with the test case in
	the linked issue (mypy transpiled C), cross-linking on Threadripper
	3990X:
	Before: 4192.80s user 1.09s system 98% cpu 1:10:53.52 total
	After:  1.76s user 0.74s system 98% cpu 2.539 total - ~1/2382 the time!

	Also tested with binutils (bootstrapping self), CPython 3.14 and LLVM
	20.1.6; all passed the respective test suites.

	Link: https://github.com/loongson-community/discussions/issues/56

2025-06-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-17  Fabian Kilger  <kilger@sec.in.tum.de>

	gdb: query inferior's filesystem for build-id debug files
	This fixes a bug related to build-id files with linux namespaces.
	Specifically, we expect the debug files to be present inside the container,
	thus the container filesystem should be queried if the program is running
	inside one.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-17  Fabian Kilger  <kilger@sec.in.tum.de>

	gdb: implement linux namespace support for fileio_lstat and vFile::lstat
	The new algorithm to look for a build-id-based debug file
	(introduced by commit 22836ca88591ac7efacf06d5b6db191763fd8aba)
	makes use of fileio_lstat. As lstat was not supported by
	linux-namespace.c, all lstat calls would be performed on the host
	and not inside the namespace.  Fixed by adding namespace lstat
	support.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-17  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: fix vFile:stat to actually use 'stat'
	This commit continues the work of the previous two commits.

	In the following commits I added the target_fileio_stat function, and
	the target_ops::fileio_stat member function:

	  * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
	  * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
	  * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
	  * 22836ca8859 gdb: check for multiple matching build-id files

	Unfortunately I messed up, despite being called 'stat' these function
	actually performed an 'lstat'.  The 'lstat' is the correct (required)
	implementation, it's the naming that is wrong.

	Additionally, to support remote targets, these commit added the
	vFile::stat packet, which again, performed an 'lstat'.

	In the previous two commits I changed the GDB code to replace 'stat'
	with 'lstat' in the fileio function names.  I then added a new
	vFile:lstat packet which GDB now uses instead of vFile:stat.

	And that just leaves the vFile:stat packet which is, right now,
	performing an 'lstat'.

	Now, clearly when I wrote this code I fully intended for this packet
	to perform an lstat, it's the lstat that I needed.  But now, I think,
	we should "fix" vFile:stat to actually perform a 'stat'.

	This is risky.  This is a change in remote protocol behaviour.

	Reasons why this might be OK:

	  - vFile:stat was only added in GDB 16, so it's not been "in the
	    wild" for too long yet.  If we're quick, we might be able to "fix"
	    this before anyone realises I messed up.

	  - The documentation for vFile:stat is pretty vague.  It certainly
	    doesn't explicitly say "this does an lstat".  Most implementers
	    would (I think), given the name, start by assuming this should be
	    a 'stat' (given the name).  Only if they ran the full GDB
	    testsuite, or examined GDB's implementation, would they know to
	    use lstat.

	Reasons why this might not be OK:

	  - Some other debug client could be connecting to gdbserver, sending
	    vFile:stat and expecting to get lstat behaviour.  This would break
	    after this patch.

	  - Some other remote server might have implemented vFile:stat
	    support, and either figured out, or copied, the lstat behaviour
	    from gdbserver.  This remote server would technically be wrong
	    after this commit, but as GDB no longer uses vFile:stat, then this
	    will only become a problem if/when GDB or some other client starts
	    to use vFile:stat in the future.

	Given the vague documentation for vFile:stat, and that it was only
	added in GDB 16, I think we should fix it now to perform a 'stat', and
	that is what this commit does.

	The change in behaviour is documented in the NEWS file.  I've improved
	the vFile:stat documentation in the manual to better explain what is
	expected from this packet, and I've extended the existing test to
	cover vFile:stat.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-17  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: add vFile:lstat packet support
	In the following commits I added the target_fileio_stat function, and
	the target_ops::fileio_stat member function:

	  * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
	  * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
	  * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
	  * 22836ca8859 gdb: check for multiple matching build-id files

	Unfortunately I messed up, despite being called 'stat' these function
	actually performed an 'lstat'.  The 'lstat' is the correct (required)
	implementation, it's the naming that is wrong.

	In the previous commit I fixed the naming within GDB, renaming 'stat'
	to 'lstat' throughout.

	However, in order to support target_fileio_stat (as was) on remote
	targets, the above patches added the vFile:stat packet, which actually
	performed an 'lstat' call.  This is really quite unfortunate, and I'd
	like to do as much as I can to try and clean up this mess.  But I'm
	mindful that changing packets is not really the done thing.

	So, this commit doesn't change anything.

	Instead, this commit adds vFile:lstat as a new packet.

	Currently, this packet is handled identically as vFile:stat, the
	packet performs an 'lstat' call.

	I then update GDB to send the new vFile:lstat instead of vFile:stat
	for the remote_target::fileio_lstat implementation.

	After this commit GDB will never send the vFile:stat packet.

	However, I have retained the 'set remote hostio-stat-packet' control
	flag, just in case someone was trying to set this somewhere.

	Then there's one test in the testsuite which used to disable the
	vFile:stat packet, that test is updated to now disable vFile:lstat.

	There's a new test that does a more direct test of vFile:lstat.  This
	new test can be extended to also test vFile:stat, but that is left for
	the next commit.

	And so, after this commit, GDB sends the new vFile:lstat packet in
	order to implement target_ops::fileio_lstat.  The new packet is more
	clearly documented than vFile:stat is.  But critically, this change
	doesn't risk breaking any other clients or servers that implement
	GDB's remote protocol.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: rename target_fileio_stat to target_fileio_lstat
	In the following commits I added the target_fileio_stat function, and
	the target_ops::fileio_stat member function:

	  * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
	  * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
	  * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
	  * 22836ca8859 gdb: check for multiple matching build-id files

	Unfortunately, I messed up when adding this API.  The actual
	underlying call is lstat, not stat.

	This commit tries to clear up some of the confusion by renaming things
	to target_fileio_lstat and target_ops::fileio_lstat.

	After this change the function names now match the underlying
	implementation.

	One problem remains though.  In order to support target_fileio_stat
	for remote target the above patches added the vFile:stat packet to GDB
	and gdbserver.  The implementation of this packet still does an lstat
	though, which is a bit of a shame.  I'm going to try and fix that in
	later commits.

	This commit is just a rename within GDB, there should be no user
	visible changes.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename get_cu -> get_unit
	This method returns type units too, so "get_unit" is a better name.

	Change-Id: I6ec9de3f783637a3e206bcaaec96a4e00b4b7d31
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-17  oltolm  <oleg.tolmatcev@gmail.com>

	gdb/dap: allow more requests when the process is running
	Makes it possible to set and remove other types of breakpoints while the
	process is running. Makes debugging more convenient.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-17  Timur  <timurgol007@gmail.com>

	gdb/record: Support csrrci instruction in risc-v
	During testing csr instructions in risc-v, it occurs that instruction csrrci
	is unsupported for recording process and there is such warning:
	'warning: Currently this instruction with len 4(100174f3) is unsupported', so
	recording failed. This patch fixes this error.

2025-06-17  timurgol007  <timurgol007@gmail.com>

	gdb: add Timur Golubovich to gdb/MAINTAINERS

2025-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set interactive-mode to on
	With MSYS2 and test-case gdb.ada/assign_1.exp, we get:
	...
	(gdb) dir^M
	Reinitialize source path to empty? (y or n) \
	  [answered Y; input not from terminal]^M^M
	Source directories searched: $cdir;$cwd^M^M
	(gdb)
	...

	GDB automatically answers the query, because interactive-mode is off:
	...
	(gdb) show interactive-mode^M
	Debugger's interactive mode is auto (currently off).^M^M
	...

	The correct value is on, because GDB was started in a terminal.

	For some reason, the auto value of interactive-mode is off instead.  According
	to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite
	as an interactive setup.

	Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that
	we get:
	...
	(gdb) dir^M
	Reinitialize source path to empty? (y or n) y^M
	Source directories searched: $cdir;$cwd^M^M
	(gdb)
	...
	and no longer need fixes like commit be740e7cc62 ("testsuite: skip
	confirmation in 'gdb_reinitialize_dir'")

	The fix is essentially the same as in aforementioned patch.

	For consistency, we apply the fix for all platforms.

	Co-Authored-By: Pierre Muller <muller@sourceware.org>
	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html

2025-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set TERM to dumb by default
	With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I
	get:
	...
	builtin_spawn gdb -q ...
	^[[6n(gdb) ERROR: GDB never initialized.
	...

	This is not specific to gdb, other tools produce the same CSI sequence, and
	consequently we run into trouble in other places (like get_compiler_info).

	Fix this by default-setting TERM to dumb.

	We do this for all platforms, to avoid test-cases passing on one platform but
	failing on another.

	For test-cases that set TERM to something other than dumb, handle the CSI
	sequence in default_gdb_start.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/33072
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072

2025-06-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-16  Indu Bhagat  <indu.bhagat@oracle.com>

	bfd: fix a minor typo

2025-06-16  Guinevere Larsen  <guinevere@redhat.com>

	gdb/doc: Explain linker namespaces
	Recent GDB commits added more features related to linker namespaces and
	documented them on the manual, but did not add a convenient way for a
	user to understand what they are. This commit adds a quick explanation
	of what they are.

	It also fixes the inconsistency of using "linker namespaces" and
	"linkage namespaces", by always using the first form to avoid user
	confusion.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2025-06-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: remove stray comma from gdb.flush description
	Remove comma from: gdb.flush([, stream]) .  I suspect this was a copy
	and paste from gdb.write(string [, stream]) where the comma is
	correct.

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: disable forward progress requirement in amd_dbgapi_target_breakpoint::check_status
	ROCgdb handles target events very slowly when running a test case like
	this, where a breakpoint is preset on HipTest::vectorADD:

	    for (int i=0; i < numDevices; ++i) {
	      HIPCHECK(hipSetDevice(i));
	      hipLaunchKernelGGL(HipTest::vectorADD, dim3(blocks), dim3(threadsPerBlock), 0, stream[i],
	                        static_cast<const int*>(A_d[i]), static_cast<const int*>(B_d[i]), C_d[i], N);
	    }

	What happens is:

	 - A kernel is launched
	 - The internal runtime breakpoint is hit during the second
	   hipLaunchKernelGGL call, which causes
	   amd_dbgapi_target_breakpoint::check_status to be called
	 - Meanwhile, all waves of the kernel hit the breakpoint on vectorADD
	 - amd_dbgapi_target_breakpoint::check_status calls process_event_queue,
	   which pulls the thousand of breakpoint hit events from the kernel
	 - As part of handling the breakpoint hit events, we write the PC of the
	   waves that stopped to decrement it.  Because the forward progress
	   requirement is not disabled, this causes a suspend/resume of the
	   queue each time, which is time-consuming.

	The stack trace where this all happens is:

	    #32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587
	    #33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 <the_amd_dbgapi_target>, regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504
	    #34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973
	    #35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890
	    #36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915
	    #37 0x0000555559fc3ca5 in regcache::cooked_write<unsigned long, void> (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850
	    #38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858
	    #39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460
	    #40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873
	    #41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006
	    #42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890
	    #43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126
	    #44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169
	    #45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621
	    #46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750
	    #47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42
	    #48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513

	Fix that performance problem by disabling the forward progress
	requirement in amd_dbgapi_target_breakpoint::check_status, before
	calling process_event_queue, so that we can process all events
	efficiently.

	Since the same performance problem could theoritically happen any time
	process_event_queue is called with forward progress requirement enabled,
	add an assert to ensure that forward progress requirement is disabled
	when process_event_queue is invoked.  This makes it necessary to add a
	require_forward_progress call to amd_dbgapi_finalize_core_attach.  It
	looks a bit strange, since core files don't have execution, but it
	doesn't hurt.

	Add a test that replicates this scenario.  The test launches a kernel
	that hits a breakpoint (with an always false condition) repeatedly.
	Meanwhile, the host process loads an unloads a code object, causing
	check_status to be called.

	Bug: SWDEV-482511
	Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec
	Approved-by: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: factor out require_forward_progress overload to target one inferior
	A following patch will want to call require_forward_progress for a given
	inferior.  Extract a new require_forward_progress overload from the
	existing require_forward_progress function that targets a specific
	inferior.

	Change-Id: I54f42b83eb8443d4d91747ffbc86eaeb017f1e49
	Approved-by: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_one_event
	Pass the amd_dbgapi_inferior_info object from process_event_queue to
	process_one_event.  Since process_event_queue pulls events for one
	specific inferior, we know for which inferior the event is.  This
	removes the need for process_one_event to do two dbgapi calls to get the
	relevant pid.  If also removes one inferior lookup.

	Change-Id: I22927e4b6251513eb3be95785082058aa3d09954
	Approved-by: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_event_queue
	A following patch will make process_event_queue access a field of
	amd_dbgapi_inferior_info.  Prepare for this by making
	process_event_queue accept an amd_dbgapi_inferior_info object, instead
	of a process id.

	Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b
	Approved-by: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: add assert in require_forward_progress
	I didn't have a problem in this area, but it seems to me that this
	pre-condition should always hold.  We should only disable forward
	progress requirement if the target says it's ok to do so.  Otherwise, we
	could get in a situation where we wait for events from amd-dbgapi, which
	will never arrive, because amd-dbgapi didn't actually resume things.

	Change-Id: Ifc49f55c7874924b7c47888b8391a07a01d960fc
	Approved-by: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: remove unnecessary AMD_DBGAPI_EVENT_KIND_NONE argument
	Rely on the default value.

	Change-Id: I08c683de005806c5c5d29ed7f9b0c6de81b49a01
	Approved-By: Lancelot Six <lancelot.six@amd.com>

2025-06-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-source-styling-2.exp with TERM=dumb
	When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I
	get:
	...
	(gdb) set style enabled on^M
	warning: The current terminal doesn't support styling. \
	  Styled output might not appear as expected.^M
	(gdb) FAIL: $exp: set style enabled on
	...

	Fix this by using with_ansi_styling_terminal on clean_restart.

	Tested on x86_64-linux.

2025-06-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-14  H.J. Lu  <hjl.tools@gmail.com>

	objcopy: Correctly check archive element for LTO IR
	commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Sun May 4 05:12:46 2025 +0800

	    strip: Add GCC LTO IR support

	added:

	@@ -3744,6 +3768,12 @@ copy_archive (bfd *ibfd, bfd *obfd, const char
	*output_target,
	     goto cleanup_and_exit;
	   }

	+#if BFD_SUPPORTS_PLUGINS
	+      /* Copy LTO IR file as unknown object.  */
	+      if (bfd_plugin_target_p (ibfd->xvec))
	                                ^^^^ A typo, should be this_element.
	+  ok_object = false;
	+      else
	+#endif
	       if (ok_object)
	   {
	     ok = copy_object (this_element, output_element, input_arch);

	to check if the archive element is a LTO IR file.  "ibfd" is the archive
	BFD.  "this_element" should be used to check for LTO IR in the archive
	element.  Fix it by replacing "ibfd" with "this_element".

		PR binutils/33078
		* objcopy.c (copy_archive): Correctly check archive element for
		LTO IR.
		* testsuite/binutils-all/objcopy.exp (strip_test_archive): New.
		Run strip_test_archive.

2025-06-14  Jeremy Bryant  <jb@jeremybryant.net>

	* gdb/doc/gdb.texinfo (Emacs): Refer to Emacs manual
	The manual section on using GDB under Emacs is out-of-date and
	duplicates existing and comprehensive documentation in the Emacs
	manual.

	Replace the section by a short introduction and reference.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2025-06-14  Stafford Horne  <shorne@gmail.com>

	or1k: Add support for numcores and coreid sprs
	These are needed when running GCC tests for newlib toolchains built with
	multicore support.  Without these SPRs we get the following warnings
	when running tests.

	    spawn or1k-elf-run ./20000112-1.exe^M
	    WARNING: l.mfspr with invalid SPR address 0x80^M
	    WARNING: l.mfspr with invalid SPR address 0x81^M
	    WARNING: l.mfspr with invalid SPR address 0x81^M
	    WARNING: l.mfspr with invalid SPR address 0x81^M

	Support is added by defining the SPRs in the cgen machine definition and
	regenerating the machine code.  In or1k/or1k.c we initialize NUMCORES to
	1 and COREID to 0 as the sim has only one CPU.  In or1k/traps.c we allow
	returning the NUMCORES and COREID spr values in the mfspr function.

2025-06-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-13  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: make gdb::parallel_for_each's n parameter a template parameter
	This value will likely never change at runtime, so we might as well make
	it a template parameter.  This has the "advantage" of being able to
	remove the unnecessary param from gdb::sequential_for_each.

	Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-13  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: re-work parallel-for-selftests.c
	I find this file difficult to work with and modify, due to how it uses
	the preprocessor to include itself, to generate variations of the test
	functions.  Change it to something a bit more C++-y, with a test
	function that accepts a callback to invoke the foreach function under
	test.

	Change-Id: Ibf1e2907380a88a4f8e4b4b88df2b0dfd0e9b6c8

2025-06-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make cooked_index_flag's to_string handle IS_SYNTHESIZED
	Change-Id: Iaac252aa2abbe169153e79b84f956cda172c69d1

2025-06-13  Jan Beulich  <jbeulich@suse.com>

	x86: don't constrain %axl/%cxl
	They can be used like their %al/%cl counterparts everywhere else;
	there's no apparent reason why they shouldn't be usable as accumulator /
	shift count respectively. Enforcing such a restriction only makes
	writing heavily macro-ized code more cumbersome.

2025-06-13  Jan Beulich  <jbeulich@suse.com>

	x86: swap operands in OUT-with-immediate template
	In a number of places we assume that immediates come first in the set of
	operands. It is mere luck that so far OUT, having operands the other way
	around, wasn't negatively impacted by this.

	Leverage this to have a few loops start from the first non-immediate
	operand (or in one case to stop there). Note, however, that
	process_immext() inserts an immediate last, so especially all output_*()
	functions cannot be changed in the same way.

2025-06-13  H.J. Lu  <hjl.tools@gmail.com>

	elf: Return false if output_section is NULL
	Return false if output_section is NULL so that on input

	https://sourceware.org/bugzilla/attachment.cgi?id=16131

	objcopy generates

	objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3]
	objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3]
	objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879
	objcopy: /tmp/stv73zYw/OrcError.cpp.o[.text._ZN4llvm3orc8orcErrorENS0_12OrcErrorCodeE]: bad value

	instead of

	objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3]
	objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3]
	objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879
	Segmentation fault (core dumped)

		PR binutils/33075
		* elf.c (elf_map_symbols): Return false if output_section is
		NULL.

2025-06-13  Jan Beulich  <jbeulich@suse.com>

	x86: refine UD<n> kind-of-insns
	While documentation of these continues to be lacking sufficient detail,
	it is becoming increasingly clear that in 66f1eba0b7e8 ("x86: correct
	UDn") I went too far with requiring operands, to populate a ModR/M byte.
	AMD hardware appears to always behave as indicated as "may" in PM 3.36,
	which for all practical purposes means there's no ModR/M byte. The SDM
	(rev 087) indicates that such behavior can occur on older hardware for
	UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while
	newly adding such a form also for UD0. Because of the ambiguity, there's
	no good/easy way of handling both possibilities in the disassembler,
	which hence remains unaltered.

	Further, from all information I'm able to gather, the 0F opcode space
	was only introduced with the i286; bump the minimal hardware requirement
	for all UD<n> accordingly.

2025-06-13  Jan Beulich  <jbeulich@suse.com>

	gas: switch convert_to_bignum() to taking just an expression
	Both callers, despite spelling things differently, now pass the same
	input for its 2nd parameter. Therefore, as was supposed to be the case
	anyway, this 2nd parameter isn't needed anymore - the function can
	calculate "sign" all by itself from the incoming expression. Instead
	make the function return the resulting value, for emit_expr_with_reloc()
	to consume for setting its "extra_digit" local variable.

2025-06-13  Jan Beulich  <jbeulich@suse.com>

	gas: also maintain signed-ness for O_big expressions
	Interestingly emit_leb128_expr() already assumes X_unsigned is properly
	set for O_big. Adjust its conversion-to-bignum to respect the incoming
	flag, and have convert_to_bignum() correctly set it on output.

	It further can't be quite right that convert_to_bignum() depends on
	anything other than the incoming expression. Therefore adjust
	emit_expr_with_reloc() to be in line with the other invocation.

	This also requires an adjustment for SH, which really should have been
	part of 762acf217c40 ("gas: maintain O_constant signedness in more
	cases").

2025-06-13  Jeremy Drake  <sourceware-bugzilla@jdrake.com>

	bfd: populate delay import directory in PE header
	Previously, the delay import table was constructed but its rva and size
	were never put into the PE optional header.

	dlltool: respect use-nul-prefixed-import-tables option for delaylib
	Noticed the extra zeros while inspecting the output.

	ld,dlltool: move read-only delayimp data into .rdata
	This allows the delay IAT to be in its own section with nothing else, as
	required by IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION, documented at
	https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#load-configuration-layout

2025-06-13  LIU Hao  <lh_mouse@126.com>
	    Jeremy Drake  <sourceware-bugzilla@jdrake.com>

	bfd,ld,dlltool: Emit delay-load import data into its own section
	A delay-import symbol (of a function) is resolved when a call to it is made.
	The delay loader may overwrite the `__imp_` pointer to the actual function
	after it has been resolved, which requires the pointer itself be in a
	writeable section.

	Previously it was placed in the ordinary Import Address Table (IAT), which
	is emitted into the `.idata` section, which had been changed to read-only
	in db00f6c3aceabbf03acdb69e74b59b2d2b043cd7, which caused segmentation
	faults when functions from delay-import library were called.  This is
	PR 32675.

	This commit makes DLLTOOL emit delay-import IAT into `.didat`, as specified
	by Microsoft. Most of the code is copied from `.idata`, except that this
	section is writeable.  As a side-effect of this, PR 14339 is also fixed.

	Using this DEF:

	   ```
	   ; ws2_32.def
	   LIBRARY "WS2_32.DLL"
	   EXPORTS
	     WSAGetLastError
	   ```

	and this C program:

	   ```
	   // delay.c
	   #define WIN32_LEAN_AND_MEAN 1
	   #include <windows.h>
	   #include <stdio.h>

	   /////////////////////////////////////////////////////////
	   // User code
	   /////////////////////////////////////////////////////////

	   DWORD WINAPI WSAGetLastError(void);
	   extern PVOID __imp_WSAGetLastError;

	   int
	   main(void)
	     {
	       fprintf(stderr, "before delay load, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError);
	       SetLastError(123);
	       fprintf(stderr, "WSAGetLastError() = %d\n", WSAGetLastError());
	       fprintf(stderr, "after delay load, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError);
	       __imp_WSAGetLastError = (PVOID) 1234567;
	       fprintf(stderr, "after plain write, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError);
	     }

	   /////////////////////////////////////////////////////////
	   // Overridden `__delayLoadHelper2` facility
	   /////////////////////////////////////////////////////////

	   extern char __ImageBase[];
	   PVOID WINAPI ResolveDelayLoadedAPI(PVOID ParentModuleBase, LPCVOID DelayloadDescriptor,
	                                      PVOID FailureDllHook, PVOID FailureSystemHook,
	                                      FARPROC* ThunkAddress, ULONG Flags);
	   FARPROC WINAPI DelayLoadFailureHook(LPCSTR name, LPCSTR function);

	   FARPROC WINAPI __delayLoadHelper2(LPCVOID pidd, FARPROC* ppfnIATEntry)
	   {
	     return ResolveDelayLoadedAPI(&__ImageBase, pidd, NULL, (PVOID) DelayLoadFailureHook,
	                                  ppfnIATEntry, 0);
	   }
	   ```

	This program used to crash:

	   ```
	   $ dlltool -nn -d ws2_32.def -y delay_ws2_32.a
	   $ gcc -g delay.c delay_ws2_32.a -o delay.exe
	   $ ./delay.exe
	   before delay load, __imp_WSAGetLastError = 00007FF6937215C6
	   Segmentation fault
	   ```

	After this commit, it loads and calls `WSAGetLastError()` properly, and
	`__imp_WSAGetLastError` is writeable:

	   ```
	   $ dlltool -nn -d ws2_32.def -y delay_ws2_32.a
	   $ gcc -g delay.c delay_ws2_32.a -o delay.exe
	   $ ./delay.exe
	   before delay load, __imp_WSAGetLastError = 00007FF76E2215C6
	   WSAGetLastError() = 123
	   after delay load, __imp_WSAGetLastError = 00007FFF191FA720
	   after plain write, __imp_WSAGetLastError = 000000000012D687
	   ```

	Reference: https://learn.microsoft.com/en-us/windows/win32/secbp/pe-metadata#import-handling

2025-06-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-12  Tom Tromey  <tromey@adacore.com>

	Minor grammar fix in DAP comment
	I noticed a minor grammer issue in a comment in DAP.

2025-06-12  Klaus Gerlicher  <klaus.gerlicher@intel.com>

	gdb, linespec: avoid multiple locations with same PC
	Setting a BP on a line like this would incorrectly yield two BP locations:

	01 void two () { {int var = 0;} }

	(gdb) break 1
	Breakpoint 1 at 0x1164: main.cpp:1. (2 locations)

	(gdb) info breakpoints
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   <MULTIPLE>
	1.1                         y   0x0000000000001164 in two() at main.cpp:1
	1.2                         y   0x0000000000001164 in two() at main.cpp:1

	In this case decode_digits_ordinary () returns two SALs, exactly matching the
	requested line.  One for the entry PC and one for the prologue end PC.  This
	was
	tested with GCC, CLANG and ICPX.  Subsequent code tries to skip the prologue
	on these PCs, which in turn makes them the same.

	To fix this, ignore SALs with the same PC and program space when adding to the
	list of SALs.

	This will then properly set only one location:

	(gdb) break 1
	Breakpoint 1 at 0x1164: file main.cpp, line 1

	(gdb) info breakpoints
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   0x0000000000001164 in two() at main.cpp:1

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: convert linux-namespaces debug to the new(er) debug scheme
	Convert 'set debug linux-namespaces' to the new(er) debug scheme.  As
	part of this change I converted the mnsh_debug_print_message function,
	which previously printed its output, to instead return a std::string,
	this string is then printed using linux_namespaces_debug_printf.  The
	mnsh_debug_print_message function is only used as part of the debug
	output.

	I also updated one place in the code where debug_linux_namespaces, the
	debug control variable, which is a boolean, was assigned an integer.

	When debug is turned on then clearly the output is now different, but
	in all other cases, there should be no user visible change in GDB
	after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-12  Richard Ball  <Richard.Ball@arm.com>

	aarch64: Add support for FEAT_FPRCVT
	FEAT_FPRCVT introduces new versions of previous instructions.
	The instructions are used to convert between floating points and
	Integers. These new versions take as operands SIMD&FP registers
	for both the source and destination register. FEAT_FPRCVT also
	enables the use of some existing AdvSIMD instructions in
	streaming mode. However, no changes are needed in gas to support this.

2025-06-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-11  Aaron Griffith  <aargri@gmail.com>

	gdb: fix size of z80 "add ii,rr" and "ld (ii+d),n" instructions
	The tables in z80-tdep.c previously either gave these instructions the
	wrong size, or failed to recognize them by using the wrong masks, or
	both. The fixed instructions alongside their representation in octal are:

	* add ii,rr:   [0335] 00r1 (where r & 1 == 1)
	               [0375] 00r1
	* ld (ii+d,n): [0335] 0066 <d> <n>
	               [0375] 0066 <d> <n>

	Prefix bytes inside [] do not count towards instruction length in
	these tables.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33066
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-11  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: doc: Improve AArch64 subsubsection titles and index entries in gdb.texinfo
	Remove period from subsubsection titles in the AArch64 configuration-specific
	subsection, and expand acronyms.

	Regarding @cindex entries, remove periods and standardise their order
	and the position of "AArch64" to make it easier to find them by
	using the index-searching commands of Info readers that offer TAB
	completion.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2025-06-11  Matthieu Longo  <matthieu.longo@arm.com>

	Arm tests: reduce objdump's output and improve some matching patterns
	Linker scripts can change the sections order in the output. Some matching
	patterns in tests try to detect the end of a section by detecting the
	beginning of the next one. However, they mistakenly enforce the name of
	the next section without any need. This caused the tests to break due to
	minor changes to the linker scripts.

	This patch adds '-j <interesting-section>' to the arguments of objdump
	to dump only relevant information for the tests. This removed the issue
	related to the ordering of the sections. The matching patterns were also
	made stricter to match better the expected output.

2025-06-11  Pedro Alves  <pedro@palves.net>

	gdb testsuite: Introduce allow_multi_inferior_tests and use it throughout
	The Windows port does not support multi-process debugging.  Testcases
	that want to exercise multi-process currently FAIL and some hit
	cascading timeouts.  Add a new allow_multi_inferior_tests procedure,
	meant to be used with require, and sprinkle it throughout testcases as
	needed.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb

2025-06-11  Pedro Alves  <pedro@palves.net>

	gdb testsuite: Introduce allow_fork_tests and use it throughout
	Cygwin debugging does not support follow fork.  There is currently no
	interface between the debugger and the Cygwin runtime to be able to
	intercept forks and execs.  Consequently, testcases that try to
	exercise fork/exec all FAIL, and several hit long cascading timeouts.

	Add a new allow_fork_tests procedure, meant to be used with require,
	and sprinkle it throughout testcases that exercise fork.

	Note that some tests currently are skipped on targets other than
	Linux, with something like:

	 # Until "set follow-fork-mode" and "catch vfork" are implemented on
	 # other targets...
	 #
	 if {![istarget "*-linux*"]} {
	     continue
	 }

	However, some BSD ports also support fork debugging nowadays, and the
	testcases were never adjusted...  That is why the new allow_fork_tests
	procedure doesn't look for linux.

	With this patch, on Cygwin, I get this:

	 $ make check TESTS="*/*fork*.exp"

	 ...
			 === gdb Summary ===

	 # of expected passes            6
	 # of untested testcases         1
	 # of unsupported tests          31

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978

2025-06-11  Pedro Alves  <pedro@palves.net>

	gdb.multi/attach-no-multi-process.exp: Detect no remote non-stop
	Running gdb.multi/attach-no-multi-process.exp on Cygwin, where
	GDBserver does not support non-stop mode, I see:

	 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads
	 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
	 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)

	Let's ignore the first "info threads" fail.  The timeouts look like
	this:

	 builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346
	 Listening on port 2346
	 target extended-remote localhost:2346
	 Remote debugging using localhost:2346
	 Non-stop mode requested, but remote does not support non-stop
	 (gdb) gdb_do_cache: can_spawn_for_attach (  )
	 builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process
	 attach 14540
	 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
	 info threads
	 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)

	Note the "Non-stop mode requested, but remote does not support
	non-stop" line.

	The intro to gdb_target_cmd_ext says:

	 # gdb_target_cmd_ext
	 # Send gdb the "target" command.  Returns 0 on success, 1 on failure, 2 on
	 # unsupported.

	That's perfect here, we can just use gdb_target_cmd_ext instead of
	gdb_target_cmd, and check for 2 (unsupported).  That's what this patch
	does.

	However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the
	case where the remote target says it does not support non-stop.  That
	is also fixed by this patch.

	With this, we no longer get those timeout fails.  We get instead:

	 target extended-remote localhost:2346
	 Remote debugging using localhost:2346
	 Non-stop mode requested, but remote does not support non-stop
	 (gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236

2025-06-11  Pedro Alves  <pedro@palves.net>

	Convert gdb.base/watchpoint-hw-attach.exp to spawn_wait_for_attach
	On Cygwin, starting an inferior under GDB, and detaching it, quitting
	GDB, and then closing the shell, like so:

	  (gdb) start
	  (gdb) detach
	  (gdb) quit
	  # close shell

	... hangs the parent shell of GDB (not GDB!) until the inferior
	process that was detached (as it is still using the same terminal GDB
	was using) exits too.

	This leads to odd failures in gdb.base/watchpoint-hw-attach.exp like
	so:

	 detach
	 Detaching from program: .../outputs/gdb.base/watchpoint-hw-attach/watchpoint-hw-attach, process 16580
	 [Inferior 1 (process 16580) detached]
	 (gdb) FAIL: gdb.base/watchpoint-hw-attach.exp: detach

	Fix this by converting the testcase to spawn the inferior outside GDB,
	with spawn_wait_for_attach.

	With this patch, the testcase passes cleanly on Cygwin, for me.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I8e3884073a510d6fd2fff611e1d26fc808adc4fa

2025-06-11  dongjianqiang (A)  <dongjianqiang2@huawei.com>

	ld: arm32: fix segfault when linking foreign BFDs [PR32870]
	PR ld/32870

	The linker may occasionally need to process a BFD that is from a
	non-Arm architecture.  There will not be any Arm-specific tdata in
	that case, so skip such BFDs when looking for iplt information as the
	necessary tdata will not be present.

2025-06-11  Tom Tromey  <tromey@adacore.com>

	Fix Solaris build
	Commit 58984e4a ("Use gdb::function_view in iterate_over_threads")
	broke the Solaris build.  This patch attempts to fix it, changing
	find_signalled_thread to have the correct signature, and correcting a
	couple of problems in sol_thread_target::get_ada_task_ptid.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33073

2025-06-11  Jan Beulich  <jbeulich@suse.com>

	ld/PE: special-case relocation types only for COFF inputs
	In 72cd2c709779 ("ld/PE: no base relocs for section (relative) ones") I
	made a pre-existing problem quite a bit worse: When looking at a
	relocation's (numerical) howto->type, that value is meaningful only if
	the object was of corresponding COFF type. ELF objects in particular
	have their own enumeration. As it stands, specifically the not entirely
	unusual R_X86_64_32 and R_X86_64_32S did no longer have relocations
	emitted for them, due to matching R_AMD64_SECTION and R_AMD64_SECREL in
	value respectively.

	arm: ignore inapplicable .arch=no...
	Unlike for command line options, where a base architecture needs to be
	provided explicitly, the .arch directive doesn't have such a
	requirement. Therefore it is odd that disabling of an inapplicable
	extension isn't silently ignored; claiming "not allowed for the current
	base architecture" is at best misleading. Alter the error path to emit a
	more "soft" diagnostic in that case instead.

2025-06-11  Matthieu Longo  <matthieu.longo@arm.com>

	AArch64 variant PCS tests: remove RWX permissions on segments
	The symbols of variant PCS functions require special handling. The variant PCS
	tests check both the relocation information and the markings in the symbol table.
	Those tests dump a lot of addresses, so a custom linker script, variant_pcs.ld
	was used to control reliably the addresses of the sections.

	However, the linker script does not provide information enough to the linker to
	assess the right set of permisssions on segments (i.e. Read/Write/Execute).
	This insufficiency caused the linker to bundle all the sections in a same segment
	with the union of all the required permissions, i.e. RWX.
	A segment with such lax permissions constitutes a security hole, so the linker
	emits the following warning message:
	    <ELF file> has a LOAD segment with RWX permissions.
	This warning message is noisy in the tests, and has no reason to exist.

	This issue can be addressed in two ways:
	- either by providing the right set of permissions on a section so that the
	  linker assigns them to a segment with compatible permissions.
	- or by providing alignment constraints so that the linker can move the sections
	  automatically to a new segment and set the right permission for non-executable
	  data.

	The second option seems to be the preferred approach, even if not explicitly
	recommended. Examples of linker scripts for AArch64 are available at [1].
	This patch reorganizes the linker script to eliminate RWX segments by changing
	the order of the sections and their offset. The tests needed to be amended to
	match the new addresses.

	[1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in
	     -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when
	     -building-an-executable?lang=en

2025-06-11  Matthieu Longo  <matthieu.longo@arm.com>

	AArch64 BTI/PAC PLT tests: remove RWX permissions on segments
	The bti-far.ld and bti-plt.ld scripts don't provide information enough to the
	linker to assess the right set of permisssions on segments (i.e. Read/Write/Execute).
	This insufficiency caused the linker to bundle all the sections in a same segment
	with the union of all the required permissions, i.e. RWX.
	A segment with such lax permissions constitutes a security hole, so the linker
	emits the following warning message:
	    <ELF file> has a LOAD segment with RWX permissions.
	This warning message is noisy in the tests, and has no reason to exist.

	This issue can be addressed in two ways:
	- either by providing the right set of permissions on a section so that the
	  linker assigns them to a segment with compatible permissions.
	- or by providing alignment constraints so that the linker can move the sections
	  automatically to a new segment and set the right permission for non-executable
	  data.

	The second option seems to be the preferred approach, even if not explicitly
	recommended. Examples of linker scripts for AArch64 are available at [1].
	The fixes in bti-far.ld and bti-plt.ld are the same, except that bti-far.ld also
	contains a ".far" section, to make sure that it generates the trampolines correctly.

	[1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in
	     -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when
	     -building-an-executable?lang=en

2025-06-11  Matthieu Longo  <matthieu.longo@arm.com>

	AArch64 tests: remove RWX permissions on segments
	aarch64.ld is the linker script used by most of the relocation tests in AArch64
	testsuite. The script does not provide information enough to the linker to assess
	the right set of permisssions on segments (i.e. Read/Write/Execute).
	This insufficiency caused the linker to bundle all the sections in a same segment
	with the union of all the required permissions, i.e. RWX.
	A segment with such lax permissions constitutes a security hole, so the linker
	emits the following warning message:
	    <ELF file> has a LOAD segment with RWX permissions.
	This warning message is noisy in the tests, and has no reason to exist.

	This issue can be addressed in two ways:
	- either by providing the right set of permissions on a section so that the
	  linker assigns them to a segment with compatible permissions.
	- or by providing alignment constraints so that the linker can move the sections
	  automatically to a new segment and set the right permission for non-executable
	  data.

	The second option seems to be the preferred approach, even if not explicitly
	recommended. Examples of linker scripts for AArch64 are available at [1].

	[1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in
	     -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when
	     -building-an-executable?lang=en

2025-06-11  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Add system registers for 2024 MPAM extension
	This patch adds support for new system registers introduced in the
	2024 MPAM extension (Memory Partitioning and Monitoring):

	Available in Armv9.3-A:
	  MPAMBW0_EL1,
	  MPAMBW1_EL1,
	  MPAMBW1_EL12,
	  MPAMBW2_EL2,
	  MPAMBW3_EL3,
	  MPAMBWCAP_EL2,
	  MPAMBWIDR_EL1

	Available in Armv9.3-A with SME:
	  MPAMBWSM_EL1

	The details can be found in [1].

	[1]: https://developer.arm.com/documentation/ddi0601/latest

2025-06-11  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Add definitions for missing architecture bits
	Complete macros for feature bits for v9.1-A, v9.2-A, v9.3-A,
	and v9.4-A.

2025-06-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-10  Alan Modra  <amodra@gmail.com>

	gas md_apply_fix value casts
	These are all innocuous but unneeded.  pdp11 and ppc are only formatting.

	gas md_apply_fix bad casts
	ns32k and z8k cast a valueT pointer to a long pointer when loading
	md_apply_fix's value.  That's quite wrong if the types have different
	sizes, as they may eg. on a 32-bit host with 64-bit bfd support.
	sparc also loads the value via a cast pointer, but at least in that
	case the cast is to the same size pointer.  None of these casts are
	needed.  Get rid of them.

2025-06-10  Alan Modra  <amodra@gmail.com>

	loongarch gcc-4.5 build fixes
	Yet another case of missing fields in struct initialisation, which
	I've replaced with a memset, and some complaints about identifiers
	shadowing global declarations.  Fixing the shadowing in
	loongarch-parse.y is easy.  This one isn't so easy:
	gas/expr.c: In function 'expr':
	gas/expr.c:1891:12: error: declaration of 'is_unsigned' shadows a global declaration
	include/opcode/loongarch.h:224:14: error: shadowed declaration is here

	opcode/loongarch.h declares lots of stuff that shouldn't be made
	available to generic gas code, so I've removed that header from
	tc-loongarch.h and moved the parts of TC_FORCE_RELOCATION_SUB_LOCAL
	and TC_FORCE_RELOCATION_SUB_LOCAL that need LARCH_opts to functions
	in tc-loongarch.c

		* config/loongarch-parse.y (loongarch_parse_expr): Rename
	        param to avoid shadowing.
		* config/tc-loongarch.c (loongarch_assemble_INSNs): Use memset
		rather than struct initialisation.
		(loongarch_force_relocation_sub_local): New function.
		(loongarch_force_relocation_sub_same): Likewise.
		* config/tc-loongarch.h: Don't include opcode/loongarch.h.
		(loongarch_force_relocation_sub_local): Declare, and..
		(TC_FORCE_RELOCATION_SUB_LOCAL): ..use here.
		(loongarch_force_relocation_sub_same): Declare, and..
		(TC_FORCE_RELOCATION_SUB_SAME): ..use here.

2025-06-10  Alan Modra  <amodra@gmail.com>

	kvx gcc-4.5 build fixes
	More missing struct initialisers, for expressionS vars that in this
	case don't need to be initialised.  Also an error: redefinition of
	typedef 'symbolS'.  OK, so don't use a typedef.

	csky gcc-4.5 build fix
	gcc-4.5 warns about missing csky_cpus struct initialisers.  Fix that
	by providing everything in the init macros and the zero sentinel,
	rather than just a single {0} as allowed by C99.

	gas m68hc11 use standard qsort predicate signature
	Avoid a function cast when using cmp_opcode with qsort.

	Re: Further rs_code_align support refinement
	Don't write the repeating nop pattern if it won't be used for alpha
	handle_align too.

2025-06-10  Alan Modra  <amodra@gmail.com>

	gas: xtensa build failure with --enable-64-bit-bfd
	A 32-bit host with --enable-64-bit-bfd --target=xtensa-lx106-elf give:
	gas/config/tc-xtensa.c: In function ‘xg_get_best_chain_entry’:
	gas/config/tc-xtensa.c:7689:11: error: absolute value function ‘labs’ given an argument of type ‘offsetT’ {aka ‘long long int’} but has parameter of type ‘long int’ which may cause truncation of value [-Werror=absolute-value]
	 7689 |       if (labs (off) >= J_RANGE - J_MARGIN)
	      |           ^~~~

	Let's not use labs.  Unlike labs vma_abs deliberately returns an
	unsigned value, and does the negation in an unsigned type so that
	signed overflow can't happen.

		* config/tc-xtensa.c (vma_abs): New function.
		(xg_get_best_chain_entry, xg_get_fulcrum, xg_find_best_trampoline),
		(xg_is_relaxable_fixup): Use in place of labs.

2025-06-10  Alan Modra  <amodra@gmail.com>

	dlltool invalid free
	This is a followup to commt 619f863c55ca "dlltool memory leaks".
	The name passed to def_name is freed, so if missing we can't just
	use "".  strdup it.

		* defparse.y (opt_name): xstrdup empty string.

2025-06-10  Matthieu Longo  <matthieu.longo@arm.com>

	AArch64, Arm and TIC6x tests: fix typo in linker scripts
	The linker scripts for AArch64 and TIC6x were probably originally copied from
	Arm testsuite, and contain the same typo in the name of the attributes section.

	This patch fixes the typo across all the testsuites.

2025-06-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf2: remove erroneous comment in open_and_init_dwo_file
	When writing commit 28f15782adab ("gdb/dwarf: read multiple .debug_info.dwo
	sections"), I initially thought that the gcc behavior of producing multiple
	.debug_info.dwo sections was a bug (it is not).  I updated the commit
	message, but it looks like this comment stayed.  Remove it, since it can
	be misleading.

	Change-Id: I027712d44b778e836f41afbfafab993da02726ef
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-10  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Smrnmi extension imply relation.
	This patch adds the dependency of Smrnmi extension on Zicsr extension.

	bfd/ChangeLog:

		* elfxx-riscv.c: New imply.

	gas/ChangeLog:

		* testsuite/gas/riscv/imply.d: New test check.
		* testsuite/gas/riscv/imply.s: New imply test.

2025-06-10  Dongyan Chen  <chendongyan@isrc.iscas.ac.cn>

	RISC-V: Add support for svvptc extension.
	This implements the svvptc extensons, version 1.0[1].

	[1] https://github.com/riscv/riscv-svvptc

	bfd/ChangeLog:

		* elfxx-riscv.c: New extension.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.

2025-06-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-svr4: remove svr4_have_link_map_offsets
	While C++ifying the solib code, I concluded that all arches that use
	SVR4 libraries do provide link map offsets, so I think this function is
	unnecessary now.

	Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-09  Pedro Alves  <pedro@palves.net>

	Adjust gdb.cp/cpexprs.exp for Cygwin
	Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see:

	 break base::~base
	 Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135.
	 (gdb) continue
	 Continuing.

	 Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
	 135	  ~base (void) { } // base::~base
	 (gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base

	Here, the breakpoint only got one location because both the in-charge
	and the not-in-charge dtors are identical and got the same address:

	 $ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base"
	 ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
	 ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()

	While on Cygwin, we get two locations for the same breakpoint, which
	the testcase isn't expecting:

	 break base::~base
	 Breakpoint 117 at 0x100402678: base::~base. (2 locations)
	 (gdb) continue
	 Continuing.

	 Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
	 135	  ~base (void) { } // base::~base
	 (gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base

	We got two locations because the in-charge and the not-in-charge dtors
	have different addresses:

	 $ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base"
	 outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base()
	 outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base()

	On Cygwin, we also see the typical failure due to not expecting the
	inferior to be multi-threaded:

	  (gdb) continue
	  Continuing.
	  [New Thread 628.0xe08]

	  Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336
	  336	  derived d;
	  (gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd

	Both issues are fixed by this patch, and now the testcase passes
	cleanly on Cygwin, for me.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1

2025-06-09  Pedro Alves  <pedro@palves.net>

	gdb.threads/thread-execl, don't re-exec forever
	I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that
	surprising since we can't follow-exec on Cygwin).  Looking at the
	process list running on the machine, we end up with a thread-execl.exe
	process constantly respawning another process [1].

	We see the same constant-reexec if we launch gdb.thread/thread-execl
	manually on the shell:

	 $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
	 # * doesn't exit, constantly re-execing *
	 ^C

	Prevent this leftover constantly-re-execing scenario by making the
	testcase program only exec once.  We now get:

	  $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
	  $   # exits immediately after one exec.

	On Cygwin, the testcase now fails reasonably quickly, and doesn't
	leave stale processes behind.

	Still passes cleanly on x86-64 GNU/Linux.

	[1] Cygwin's exec emulation spawns a new Windows process for the new
	image.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb

2025-06-09  Pedro Alves  <pedro@palves.net>

	Support core dumping testcases with Cygwin's dumper
	Cygwin supports dumping ELF cores via a dumper.exe utility, see
	https://www.cygwin.com/cygwin-ug-net/dumper.html.

	When I run a testcase that has the "kernel" generate a corefile, like
	gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and
	generates an ELF core file, however, the testsuite doesn't find the
	generated core:

	 Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ...
	 WARNING: can't generate a core file - core tests suppressed - check ulimit -c

	The file is correctly put under $coredir, e.g., like so:

	  outputs/gdb.base/corefile/coredir.8926/corefile.exe.core

	The problem is in this line in core_find:

	  foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {

	Note that that isn't looking for "${binfile}.core" inside
	${coredir}...  That is fixed in this patch.

	However, that still isn't sufficient for Cygwin + dumper, as in that
	case the core is going to be called foo.exe.core, not foo.core.  Fix
	that by looking for foo.exe.core in the core dir as well.

	With this, gdb.base/corefile.exp and other tests that use core_find
	now run.  They don't pass cleanly, but at least now they're exercised.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e

2025-06-09  Pedro Alves  <pedro@palves.net>

	Adjust gdb.base/sigall.exp for Cygwin
	The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently.

	From:

	 Thread 1 "sigall" received signal SIGPWR, Power fail/restart.
	 0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
	 (gdb) FAIL: gdb.base/sigall.exp: get signal LOST

	we see two issues.  The test is expecting "Program received ..." which
	only appears if the inferior is single-threaded.  All Cygwin inferiors
	are multi-threaded, because both Windows and the Cygwin runtime spawn
	a few helper threads.

	And then, SIGLOST is the same as SIGPWR on Cygwin.  The testcase
	already knows to treat them the same on SPARC64 GNU/Linux.  We just
	need to extend the relevant code to treat Cygwin the same.

	With this, the test passes cleanly on Cygwin.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667

2025-06-09  Pedro Alves  <pedro@palves.net>

	Adjust gdb.arch/amd64-watchpoint-downgrade.exp for Cygwin
	The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the
	output of debugging a single-thread program, like so, on e.g.,
	GNU/Linux:

	 starti
	 Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
	 warning: watchpoint 1 downgraded to software watchpoint

	 Program stopped.
	 0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2

	However, on Cygwin, where all inferiors are multi-threaded (because
	both Windows and the Cygwin runtime spawn a few helper threads), we
	get:

	 starti
	 Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
	 [New Thread 4652.0x17e4]
	 warning: watchpoint 1 downgraded to software watchpoint

	 Thread 1 stopped.
	 0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll

	This commit adjusts the testcase to work with either output.

	(Note GDB may print a thread name after the thread number.)

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c

2025-06-09  Pedro Alves  <pedro@palves.net>

	Adjust gdb.base/bp-permanent.exp for Cygwin
	On Cygwin, all inferiors are multi-threaded, because both Windows and
	the Cygwin runtime spawn a few helper threads.  Adjust the
	gdb.base/bp-permanent.exp testcase to work with either single- or
	multi-threaded inferiors.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2

2025-06-09  Pedro Alves  <pedro@palves.net>

	Adjust gdb.base/bp-cond-failure.exp for Cygwin
	Currently on Cygwin, I get:

	 Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ...
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue
	 FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue

	On GNU/Linux, we see:

	 Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
	 21        return 0;     /* Multi-location breakpoint here.  */
	 (gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue

	While on Cygwin, we see:

	 Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
	 21        return 0;     /* Multi-location breakpoint here.  */
	 (gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue

	The difference is the "Thread 1" part in the beginning of the quoted
	output.  It appears on Cygwin, but not on Linux.  That's because on
	Cygwin, all inferiors are multi-threaded, because both Windows and the
	Cygwin runtime spawn a few helper threads.

	Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to
	work with either single- or multi-threaded inferiors.

	The testcase passes cleanly for me after this.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349

2025-06-09  Alice Carlotti  <alice.carlotti@arm.com>

	MAINTAINERS: Add myself as an AArch64 maintainer

2025-06-09  Richard Earnshaw  <rearnsha@arm.com>

	aarch64: Increase the number of feature words to 3
	Now that most of the effort of updating the number of feature words is
	handled by macros, add an additional one, taking the number of
	supported features to 192.

2025-06-09  Richard Earnshaw  <rearnsha@arm.com>

	aarch64: use macro trickery to automate feature array size replication
	There are quite a few macros that need to be changed when we need to
	increase the number of words in the features data structure.  With
	some macro trickery we can automate most of this so that a single
	macro needs to be updated.

	With C2X we could probably do even better by using recursion, but this
	is still a much better situation than we had previously.

	A static assertion is used to ensure that there is always enough space
	in the flags macro for the number of feature bits we need to support.

2025-06-09  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Fix typos in opcode headers

2025-06-09  Alan Modra  <amodra@gmail.com>

	change some listing.c variables to unsigned.
	The values are unsigned, and changing the types allows some casts to
	be removed.

2025-06-09  Alan Modra  <amodra@gmail.com>

	dwarf2dbg.c line_entry.next assert
	I was puzzling over how it was correct to cast what is clearly a
	struct line_entry** pointer to a struct line_entry* pointer for a
	few moments, and was going to write a comment but then decided we
	really don't require the "next" pointer to be where it is.  Replace
	the assert with an inline function that does any necessary pointer
	adjustments.

		* dwarf2dbg.c (line_entry.next): Delete static assertion.
		(line_entry_at_tail): New inline function.
		(dwarf2_gen_line_info_1, dwarf2_finish): Replace casts in
		set_or_check_view arguments with line_entry_at_tail.

2025-06-09  Alan Modra  <amodra@gmail.com>

	str_hash_find casts
	Putting an explicit cast on the void* return from str_hash_find isn't
	necessary and doesn't add much to code clarity.  In other cases, poor
	choice of function parameter types, eg. "void *value" in
	tc-aarch64.c checked_hash_insert rather than "const void *value" leads
	to needing (void *) casts all over the place just to cast away const.
	Fix that by correcting the parameter type.  (And it really is a const,
	the function and str_hash_insert don't modify the strings.)
	This patch also removes some unnecessary casts in hash.c

2025-06-09  Alan Modra  <amodra@gmail.com>

	str_hash_find_int
	This changes the internal representation of string_tuple.value from
	a void* to an intptr_t, removing any concerns that code wanting to
	store an integer value will use values that are trap encodings or
	suchlike for a pointer.  The ISO C standard says any void* can be
	converted to intptr_t and back again and will compare equal to the
	original pointer.  It does *not* say any intptr_t can be converted to
	void* and back again to get the original integer..

	Two new functions, str_hash_find_int and str_hash_insert_int are
	provided for handling integer values.  str_hash_find_int returns
	(intptr_t) -1 on failing to find the key string.

	Most target code need minimal changes to use the new interface, but
	some simplification is possible since now a zero can be stored and
	differentiated from the NULL "can't find" return.  (Yes, that means
	(intptr_t) -1 can't be stored.)

	I've changed the avr_no_sreg_hash dummy value to zero, and the
	loongarch register numbers don't need to be incremented.  loongarch
	also doesn't need to store an empty key string (if it ever did).

2025-06-09  Alan Modra  <amodra@gmail.com>

	metag build error
	gas/config/tc-metag.c: In function ‘parse_dsp_addr’:
	gas/config/tc-metag.c:4386:29: error: ‘regs[0]’ may be used uninitialized [-Werror=maybe-uninitialized]
	 4386 |   if (!is_addr_unit (regs[0]->unit) &&
	      |                      ~~~~~~~^~~~~~

	It looks like regs_read can be zero with "l" non-NULL, so this gcc
	complaint is accurate.

		* config/tc-metag.c (parse_dsp_addr, parse_dget_set): Check
		regs_read.

2025-06-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix buildbreaker in hardwire_setbaudrate
	When building on x86_64-cygwin, I run into:
	...
	In file included from gdbsupport/common-defs.h:203,
	                 from gdb/defs.h:26,
	                 from <command-line>:
	gdb/ser-unix.c: In function ‘void hardwire_setbaudrate(serial*, int)’:
	gdbsupport/gdb_locale.h:28:20: error: expected ‘)’ before ‘gettext’
	   28 | # define _(String) gettext (String)
	      |                    ^~~~~~~
	gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
	   43 |   internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
	      |                                           ^
	gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
	  590 |       gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
	      |       ^~~~~~~~~~~~~~~~~~~~~~
	gdb/ser-unix.c:590:31: note: in expansion of macro ‘_’
	  590 |       gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
	      |                               ^
	gdbsupport/gdb_locale.h:28:28: note: to match this ‘(’
	   28 | # define _(String) gettext (String)
	      |                            ^
	gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
	   43 |   internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
	      |                                           ^
	gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
	  590 |       gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
	      |       ^~~~~~~~~~~~~~~~~~~~~~
	...

	Fix this by dropping the unneeded _() on the gdb_assert_not_reached argument.

	PR build/33064
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33064

2025-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/dyn-bit-offset.exp on s390x
	On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get:
	...
	(gdb) print spr^M
	$1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M
	(gdb) FAIL: $exp: print spr
	print spr.field^M
	$2 = -6^M
	(gdb) FAIL: $exp: print spr.field
	...

	On x86_64-linux, with the same compiler version I get:
	...
	(gdb) print spr^M
	$1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M
	(gdb) XFAIL: $exp: print spr
	print spr.field^M
	$2 = -4^M
	(gdb) PASS: $exp: print spr.field
	...

	In both cases, we're hitting the same compiler problem, but it manifests
	differently on little and big endian.

	Make sure the values seen for both little and big endian trigger xfails
	for both tests.

	Printing spr.field gives the expected value -4 for x86_64, but that's an
	accident.  Change the actual spr.field value to -5, to make sure
	that we get the same number of xfails on x86_64 and s390x.

	Finally, make the xfails conditional on the compiler version.

	Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	PR testsuite/33042
	https://sourceware.org/bugzilla/show_bug.cgi?id=33042

2025-06-07  Georg-Johann Lay  <avr@gjlay.de>

	AVR: ld/32968 - Assert that .progmem data resides in the lower 64 KiB.
	This patch locates the linker stubs / trampolines *after* all the .progmem
	sections.  This is the natural placement since progmem data has to reside
	in the lower 64 KiB (it is accessed using LPM), whereas the linker stubs
	are only required to be located in the lower 128 KiB of program memory.
	(They must be in the range of EICALL / EIJMP with EIND = 0.)

	The current location of the linker stubs was motivated by an invalid test
	case from PR13812 that allocates more than 64 KiB of progmem data.

	The patch adds an assertion that makes sure that no progmem data is
	allocated past 0xffff.

	Data that is accessed using ELPM should be located to .progmemx so that
	no .progmem addresses are wasted.  .progmemx was introduced in 2017 and
	is used by __memx, __flashx and by the current AVR-LibC.
	(The compiler uses .jumptables.gcc for its jump dispatch tables since
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 / GCC v4.9.2).

		PR ld/32968
	ld/
		* scripttempl/avr.sc: Move the trampolines section after the
		.progmem sections.  Assert that .progmem is in the lower 64 KiB.

2025-06-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/guile: fix memory leak in gdbscm_parse_command_name
	For reference see the previous commit.

	Fix a memory leak in gdbscm_parse_command_name when a guile exception
	is thrown.  To reveal the memory leak I placed the following content
	into a file 'leak.scm':

	  (use-modules (gdb))
	  (register-command!
	   (make-command
	    "break cmd"
	    #:command-class COMMAND_OBSCURE
	    #:invoke (lambda (self arg from-tty)
	               (display "Hello World"))))

	Then in GDB:

	  (gdb) source leak.scm
	  ERROR: In procedure register-command!:
	  In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd"
	  Error while executing Scheme code.

	Running this under valgrind reveals a memory leak for 'result' and
	'prefix_text' from gdbscm_parse_command_name.

	Another leak can be revealed with this input script:

	  (use-modules (gdb))
	  (register-command!
	   (make-command
	    "unknown-prefix cmd"
	    #:command-class COMMAND_OBSCURE
	    #:invoke (lambda (self arg from-tty)
	               (display "Hello World"))))

	This one occurs earlier in gdbscm_parse_command_name, and now only
	'result' leaks.

	The problem is that, when guile throws an exception then a longjmp is
	performed from the function that raise the exception back to the guile
	run-time.  A consequence of this is that no function local destructors
	will be run.

	In gdbscm_parse_command_name, this means that the two function locals
	`result` and `prefix_text` will not have their destructors run, and
	any memory managed by these objects will be leaked.

	Fix this by assigning nullptr to these two function locals before
	throwing an exception.  This will cause the managed memory to be
	deallocated.

	I could have implemented a fix that made use of Guile's dynwind
	mechanism to register a cleanup callback, however, this felt like
	overkill.  At the point the exception is being thrown we know that we
	no longer need the managed memory, so we might as well just free the
	memory at that point.

	With this fix in place, the two leaks are now fixed in the valgrind
	output.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python/guile: remove some explicit calls to xmalloc
	In gdbpy_parse_command_name (python/py-cmd.c) there is a call to
	xmalloc that can easily be replaced with a call to
	make_unique_xstrndup, which makes the code easier to read (I think).

	In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be
	applied to remove an identical xmalloc call.  And there is an
	additional xmalloc call, which can also be replaced with
	make_unique_xstrndup in the same way.

	The second xmalloc call in gdbscm_parse_command_name was also present
	in gdbpy_parse_command_name at one point, but was replaced with a use
	of std::string by this commit:

	  commit 075c55e0cc0a68eeab777027213c2f545618e844
	  Date:   Wed Dec 26 11:05:57 2018 -0700

	      Remove more calls to xfree from Python

	I haven't changed the gdbscm_parse_command_name to use std::string
	though, as that doesn't work well with the guile exception model.
	Guile exceptions work by performing a longjmp from the function that
	raises the exception, back to the guile run-time.  The consequence of
	this is that destructors are not run.  For example, if
	gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any
	function local objects in gdbscm_parse_command_name will not have
	their destructors called.

	What this means is that, for the existing `result` and `prefix_text`
	locals, any allocated memory managed by these objects will be leaked
	if an exception is called.  However, fixing this is pretty easy, one
	way is to just assign nullptr to these locals before raising the
	exception, this would cause the allocated memory to be released.

	But for std::string it is harder to ensure that the managed memory has
	actually been released.  We can call std::string::clear() and then
	maybe std::string::shrink_to_fit(), but this is still not guaranteed
	to release any managed memory.  In fact, I believe the only way to
	ensure all managed memory is released, is to call the std::string
	destructor.

	And so, for functions that can throw a guile exception, it is easier
	to just avoid std::string.

	As for the memory leak that I identify above; I'll fix that in a
	follow on commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-06  Guinevere Larsen  <guinevere@redhat.com>

	gdb/solib: make _linker_namespace use selected frame
	When the convenience variable $_linker_namespace was introduced, I meant
	for it to print the namespace of the frame that where the user was
	stopped. However, due to confusing what "current_frame" and
	"selected_frame" meant, it instead printed the namespace of the
	lowermost frame.

	This commit updates the code to follow my original intent. Since the
	variable was never in a GDB release, updating the behavior should not
	cause any disruption. It also adds a test to verify the functionality.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-06  Indu Bhagat  <indu.bhagat@oracle.com>

	bfd: sframe: fix typo in comments
	bfd/
		* elflink.c (elf_link_input_bfd): Replace ctf frame with SFrame.

2025-06-06  Alexey Lapshin  <alexey.lapshin@espressif.com>

	gdb: unix: allow to use custom baud rate
	Modern unix systems allow to set custom baud rate instead of predefined in termios.h.

	- To use this in Linux it must have BOTHER macro in "asm/termio.h"
	- MacOS could handle this using IOSSIOSPEED passed to ioctl()

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7

2025-06-06  Alexey Lapshin  <alexey.lapshin@espressif.com>

	gdb: unix: extend supported baudrate B_codes
	Added B_codes that may be supported in some unix systems

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I48624d6573dc6c72e26818dd44b24182c1dabb70

2025-06-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: remove one xfree
	Replace a manual xfree with unique_xmalloc_ptr.

	Change-Id: Id4d2065e3294c4761fe3c852962360712b53d7a8
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)

2025-06-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-rocm: remove one xfree
	Replace a manual xfree with unique_xmalloc_ptr.

	Change-Id: I12a20106545905f1a80d069fc0555812cc3d6680
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)

2025-06-06  Tom Tromey  <tromey@adacore.com>

	Fix regression with DW_AT_bit_offset handling
	Internal AdaCore testing using -gdwarf-4 found a spot where GCC will
	emit a negative DW_AT_bit_offset.  However, my recent signed/unsigned
	changes assumed that this value had to be positive.

	I feel this bug somewhat invalidates my previous thinking about how
	DWARF attributes should be handled.

	In particular, both GCC and LLVM at understand that a negative bit
	offset can be generated -- but for positive offsets they might use a
	smaller "data" form, which is expected not to be sign-extended.  LLVM
	has similar code but GCC does:

	  if (bit_offset < 0)
	    add_AT_int (die, DW_AT_bit_offset, bit_offset);
	  else
	    add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset);

	What this means is that this attribute is "signed but default
	unsigned".

	To fix this, I've added a new attribute::confused_constant method.
	This should be used when a constant value might be signed, but where
	narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension.

	I examined the GCC and LLVM DWARF writers to come up with the list of
	attributes where this applies, namely DW_AT_bit_offset,
	DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM
	always emits it as unsigned, so we're safe here).

	This patch corrects the bug and imports the relevant test case.

	Regression tested on x86-64 Fedora 41.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
	Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: prevent assertion after 'set debug breakpoint on'
	Turns out that using 'set debug breakpoint on' will trigger an
	assertion for 'catch' style breakpoints, e.g.:

	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) catch exec
	  Catchpoint 1 (exec)
	  (gdb) set debug breakpoint on
	  (gdb) start
	  [breakpoint] dump_condition_tokens: Tokens: { INFERIOR: "1" }
	  Temporary breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
	  [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
	  Starting program: /tmp/hello.x
	  [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
	  ../../gdb-16.1/gdb/gdbarch-gen.c:1764: internal-error: gdbarch_addr_bit: Assertion `gdbarch != NULL' failed.
	  .... etc ...

	The problem is that catch breakpoints don't set the
	bp_location::gdbarch member variable, they a "dummy" location added
	with a call to add_dummy_location (breakpoint.c).

	The breakpoint_location_address_str function (which is only used for
	breakpoint debug output) relies on bp_location::gdbarch being set in
	order to call the paddress function.

	I considered trying to ensure that the bp_location::gdbarch variable
	is always set to sane value.  For example, in add_dummy_location I
	tried copying the gdbarch from the breakpoint object, and this does
	work for the catchpoint case, but for some of the watchpoint cases,
	even the breakpoint object has no gdbarch value set.

	Now this seemed a little suspect, but, the more I thought about it, I
	wondered if "fixing" the gdbarch was allowing me to solve the wrong
	problem.

	If the gdbarch was set, then this would allow us to print the address
	field of the bp_location, which is going to be 0, after all, as this
	is a dummy location, which has no address.

	But does it really make sense to print the address 0?  For some
	targets, 0 is a valid address.  But that wasn't an address we actually
	selected, it's just the default value for dummy locations.

	And we already have a helper function bl_address_is_meaningful, which
	returns false for dummy locations.

	So, I propose that in breakpoint_location_address_str, we use
	bl_address_is_meaningful to detect dummy locations, and skip the
	address printing code in that case.

	For testing, I temporarily changed insert_bp_location so that
	breakpoint_location_address_str was always called, even when
	breakpoint debugging was off.  I then ran the whole testsuite.
	Without the fixes included in this commit I saw lots of assertion
	failures, but with the fixes from this commit in place, I now see no
	assertion failures.

	I've added a new test which reveals the original assertion failure.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-06  Guinevere Larsen  <guinevere@redhat.com>

	gdb/configure: Fix POSIX non-compliance
	My recent GDB commit:

	    commit 4b42385c470c5f72f158f382f4d9c36f927aa84f
	    Author: Guinevere Larsen <guinevere@redhat.com>
	    Date:   Wed Feb 12 08:25:46 2025 -0300
	    gdb: Make dwarf support optional at compile time

	Introduced a change that made the configure script not POSIX compliant,
	by using fallthrough in some case statements. This commit reworks that
	part of the change to only use if statements, so that no code is
	duplicated but things remain POSIX compliant.

	Reviewed-by: Sam James <sam@gentoo.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-06  Pedro Alves  <pedro@palves.net>

	Make default_gdb_exit resilient to failed closes
	For some reason, when testing GDB on Cygwin, I get:

	 child process exited abnormally
	     while executing
	 "exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)""
	     (procedure "close_wait_program" line 20)
	     invoked from within
	 "close_wait_program $shell_id $pid"
	     (procedure "standard_close" line 23)
	     invoked from within
	 "standard_close "Windows-ROCm""
	     ("eval" body line 1)
	     invoked from within
	 "eval ${try}_${proc} \"$dest\" $args"
	     (procedure "call_remote" line 42)
	     invoked from within
	 "call_remote "" close $host"
	     (procedure "remote_close" line 3)
	     invoked from within
	 "remote_close host"
	     (procedure "log_and_exit" line 30)
	     invoked from within
	 "log_and_exit"

	When that happens from within clean_restart, clean_restart doesn't
	clear the gdb_spawn_id variable, and then when clean_restart starts up
	a new GDB, that sees that gdb_spawn_id is already set, so it doesn't
	actually spawn a new GDB, and so clean_restart happens to reuse the
	same GDB (!).  Many tests happen to actually work OK with this, but
	some don't, and the failure modes can be head-scratching.

	Of course, the failure to close GDB should be fixed, but when it
	happens, I think it's good to not end up with the current weird state.
	Connecting the "child process exit abnormally" errors at the end of a
	testcase run with weird FAILs in other testcases took me a while (as
	in, weeks!), it wasn't obvious to me immediately.

	Thus, this patch makes default_gdb_exit more resilient to failed
	closes, so that gdb_spawn_id is unset even is closing GDB fails, and
	we move on to start a new GDB.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2

2025-06-06  Pedro Alves  <pedro@palves.net>

	gdb_test_multiple: Anchor prompt match if -lbl
	The testcase added by this patch has a gdb_test_multiple call that
	wants to match different lines of output that all have a common
	prefix, and do different actions on each.  Instead of a single regular
	expression with alternatives, it's clearer code if the different
	expressions are handled with different "-re", like so:

	  gdb_test_multiple "command" "" -lbl {
	     -re "^command(?=\r\n)" {
		 exp_continue
	     }
	     -re "^\r\nprefix foo(?=\r\n)" {
		 # Some action for "foo".
		 exp_continue
	     }
	     -re "^\r\nprefix bar(?=\r\n)" {
		 # Some action for "bar".
		 exp_continue
	     }
	     -re "^\r\nprefix \[^\r\n\]*(?=\r\n)" {
		 # Some action for all others.
		 exp_continue
	     }
	     -re "^\r\n$::gdb_prompt $" {
		 gdb_assert {$all_prefixes_were_seen} $gdb_test_name
	     }
	  }

	Above, the leading anchors in the "^\r\nprefix..." matches are needed
	to avoid too-eager matching due to the common prefix.  Without the
	anchors, if the expect output buffer happens to contain at least:

	  "\r\nprefix xxx\r\nprefix foo\r\n"

	... then the "prefix foo" pattern match inadvertently consumes the
	first "prefix xxx" line.

	Without the anchor in the prompt match, like:

	  -re "\r\n$::gdb_prompt $" {
	      gdb_assert {$all_prefixes_were_seen} $gdb_test_name
	  }

	Or the equivalent:

	  -re -wrap "" {
	      gdb_assert {$all_prefixes_were_seen} $gdb_test_name
	  }

	... then if the expect buffer contains:

	  "\r\nmeant-to-be-matched-by-lbl\r\nprefix foo\r\n$gdb_prompt "

	... then the prompt regexp matches this, consuming the "prefix" line
	inadvertently, and we get a FAIL.  The built-in regexp matcher for
	-lbl doesn't get a chance to match the
	"\r\nmeant-to-be-matched-by-lbl\r\n" part, because the built-in prompt
	match appears first within gdb_test_multiple.

	By adding the anchor to the prompt regexp, we avoid that problem.

	However, the same expect output buffer contents will still match the
	built-in prompt regexp.  That is what is fixed by this patch.  It
	makes it so that if -lbl is specified, the built-in prompt regexp has
	a leading anchor.

	Original idea for turning this into a gdb.testsuite/ testcase by Tom
	de Vries <tdevries@suse.de>.

	Approved-By: Tom de Vries <tdevries@suse.de>
	Change-Id: Ic2571ec793d856a89ee0d533ec363e2ac6036ea2

2025-06-06  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix typo in gdb/break-catch-syscall.c
	Fix typo "if the feature if supported" -> "if the feature is supported".

2025-06-06  Jan Beulich  <jbeulich@suse.com>

	x86/Solaris: cope with new HANDLE_ALIGN behavior
	Extend the expectation adjustments done by 83d94ae428b1 ("tidy x86
	HANDLE_ALIGN") to the Solaris clone of an affected testcase.

2025-06-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.multi/attach-while-running.exp
	With test-case gdb.multi/attach-while-running.exp usually I get:
	...
	(gdb) run &^M
	Starting program: attach-while-running ^M
	(gdb) PASS: $exp: run &
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	add-inferior^M
	[New inferior 2]^M
	Added inferior 2 on connection 1 (native)^M
	(gdb) PASS: $exp: add-inferior
	...
	or:
	...
	(gdb) run &
	Starting program: attach-while-running
	(gdb) PASS: $exp: run &
	add-inferior
	[New inferior 2]
	Added inferior 2 on connection 1 (native)
	(gdb) PASS: $exp: add-inferior
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib64/libthread_db.so.1".
	...
	but sometimes I run into:
	...
	(gdb) run &
	Starting program: attach-while-running
	(gdb) PASS: $exp: run &
	add-inferior
	[New inferior 2]
	Added inferior 2 on connection 1 (native)
	(gdb) [Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib64/libthread_db.so.1".
	FAIL: $exp: add-inferior (timeout)
	...

	Fix this by using -no-prompt-anchor.

	Tested on x86_64-linux.

2025-06-06  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Don't call WaitForSingleObject with INFINITE arg
	I decided to try to build and test gdb on Windows.

	I found a page on the wiki [1] suggesting three ways of building gdb:
	- MinGW,
	- MinGW on Cygwin, and
	- Cygwin.

	I picked Cygwin, because I've used it before (though not recently).

	I managed to install Cygwin and sufficient packages to build gdb and start the
	testsuite.

	However, testsuite progress ground to a halt at gdb.base/branch-to-self.exp.
	[ AFAICT, similar problems reported here [2]. ]

	I managed to reproduce this hang by running just the test-case.

	I attempted to kill the hanging processes by:
	- first killing the inferior process, using the cygwin "kill -9" command, and
	- then killing the gdb process, likewise.

	But the gdb process remained, and I had to point-and-click my way through task
	manager to actually kill the gdb process.

	I investigated this by attaching to the hanging gdb process.  Looking at the
	main thread, I saw it was stopped in a call to WaitForSingleObject, with
	the dwMilliseconds parameter set to INFINITE.

	The backtrace in more detail:
	...
	(gdb) bt
	 #0  0x00007fff196fc044 in ntdll!ZwWaitForSingleObject () from
	     /cygdrive/c/windows/SYSTEM32/ntdll.dll
	 #1  0x00007fff16bbcdcf in WaitForSingleObjectEx () from
	     /cygdrive/c/windows/System32/KERNELBASE.dll
	 #2  0x0000000100998065 in wait_for_single (handle=0x1b8, howlong=4294967295) at
	     gdb/windows-nat.c:435
	 #3  0x0000000100999aa7 in
	     windows_nat_target::do_synchronously(gdb::function_view<bool ()>)
	       (this=this@entry=0xa001c6fe0, func=...) at gdb/windows-nat.c:487
	 #4  0x000000010099a7fb in windows_nat_target::wait_for_debug_event_main_thread
	     (event=<optimized out>, this=0xa001c6fe0)
	     at gdb/../gdbsupport/function-view.h:296
	 #5  windows_nat_target::kill (this=0xa001c6fe0) at gdb/windows-nat.c:2917
	 #6  0x00000001008f2f86 in target_kill () at gdb/target.c:901
	 #7  0x000000010091fc46 in kill_or_detach (from_tty=0, inf=0xa000577d0)
	     at gdb/top.c:1658
	 #8  quit_force (exit_arg=<optimized out>, from_tty=from_tty@entry=0)
	     at gdb/top.c:1759
	 #9  0x00000001004f9ea8 in quit_command (args=args@entry=0x0,
	     from_tty=from_tty@entry=0) at gdb/cli/cli-cmds.c:483
	 #10 0x000000010091c6d0 in quit_cover () at gdb/top.c:295
	 #11 0x00000001005e3d8a in async_disconnect (arg=<optimized out>)
	     at gdb/event-top.c:1496
	 #12 0x0000000100499c45 in invoke_async_signal_handlers ()
	     at gdb/async-event.c:233
	 #13 0x0000000100eb23d6 in gdb_do_one_event (mstimeout=mstimeout@entry=-1)
	     at gdbsupport/event-loop.cc:198
	 #14 0x00000001006df94a in interp::do_one_event (mstimeout=-1,
	     this=<optimized out>) at gdb/interps.h:87
	 #15 start_event_loop () at gdb/main.c:402
	 #16 captured_command_loop () at gdb/main.c:466
	 #17 0x00000001006e2865 in captured_main (data=0x7ffffcba0) at gdb/main.c:1346
	 #18 gdb_main (args=args@entry=0x7ffffcc10) at gdb/main.c:1365
	 #19 0x0000000100f98c70 in main (argc=10, argv=0xa000129f0) at gdb/gdb.c:38
	...

	In the docs [3], I read that using an INFINITE argument to WaitForSingleObject
	might cause a system deadlock.

	This prompted me to try this simple change in wait_for_single:
	...
	   while (true)
	     {
	-      DWORD r = WaitForSingleObject (handle, howlong);
	+      DWORD r = WaitForSingleObject (handle,
	+                                     howlong == INFINITE ? 100 : howlong);
	+      if (howlong == INFINITE && r == WAIT_TIMEOUT)
	+        continue;
	...
	with the timeout of 0.1 second estimated to be:
	- small enough for gdb to feel reactive, and
	- big enough not to consume too much cpu cycles with looping.

	And indeed, the test-case, while still failing, now finishes in ~50 seconds.

	While there may be an underlying bug that triggers this behaviour, the failure
	mode is so severe that I consider it a bug in itself.

	Fix this by avoiding calling WaitForSingleObject with INFINITE argument.

	Tested on x86_64-cygwin, by running the testsuite past the test-case.

	Approved-By: Pedro Alves <pedro@palves.net>

	PR tdep/32894
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32894

	[1] https://sourceware.org/gdb/wiki/BuildingOnWindows
	[2] https://sourceware.org/pipermail/gdb-patches/2025-May/217949.html
	[3] https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject

2025-06-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-svr4: make svr4_info::debug_loader_name an std::string
	Remove some manual memory management.

	Change-Id: I9c752d35a70e3659509fed57df1c9a8d27ecc742
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-05  Guinevere Larsen  <guinevere@redhat.com>

	gdb/solib: rename convenience variable to _linker_namespace
	Based on feedback from IRC and PR solib/32959, this commit renames the
	recently introduced convenience variable $_current_linker_namespace to
	the shorter name $_linker_namespace. This makes it more in line with
	existing convenience variables such as $_thread and $_inferior, and
	faster to type.

	It should be ok to simply change the name because the variable was never
	released to the public, so there should be no existing scripts depending
	on the name.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32959
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-05  Guinevere Larsen  <guinevere@redhat.com>

	gdb/solib: Change type of convenience variable _current_linker_namespace
	Based on IRC feedback since commit 6a0da68c036a85a46415aa0dada2421eee7c2269

	    gdb: add convenience variables around linker namespace debugging

	This commit changes the type of the _current_linker_namespace variable
	to be a simple integer. This makes it easier to use for expressions,
	like breakpoint conditions or printing from a specific namespace once
	that is supported, at the cost of making namespace IDs slightly less
	consistent.

	This is based on PR solib/32960, where no negative feedback was given
	for the suggestion.

	The commit also changes the usage of "linkage namespaces" to "linker
	namespaces" in the NEWS file, to reduce chance of confusion from an end
	user.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32960
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-05  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/bp-permanent.exp with gcc 15
	With test-case gdb.base/bp-permanent.exp and gcc 15 I run into:
	...
	gdb compile failed, bp-permanent.c: In function 'test_signal_nested':
	bp-permanent.c:118:20: error: passing argument 2 of 'signal' from \
	  incompatible pointer type [-Wincompatible-pointer-types]
	  118 |   signal (SIGALRM, test_signal_nested_handler);
	      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
	      |                    |
	      |                    void (*)(void)
	In file included from bp-permanent.c:20:
	/usr/include/signal.h:88:57: note: expected '__sighandler_t' \
	  {aka 'void (*)(int)'} but argument is of type 'void (*)(void)'
	...

	Fix this by adding an int parameter to test_signal_nested_handler.

	Tested on x86_64-linux.

	PR testsuite/32756
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756

2025-06-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-04  Nick Alcock  <nick.alcock@oracle.com>

	libctf: use __attribute__((__gnu_printf__)) where appropriate
	We don't use any GNU-specific printf args, but this prevents warnings about
	%z, observed on MinGW even though every libc anyone is likely to use there
	supports %z perfectly well, and we're not stopping using it just because
	MinGW complains.  Doing this means we stand more chance of seeing *actual*
	problems on such platforms without them being drowned in noise.

	We turn this off on clang, which doesn't support __gnu_printf__.

	Suggested by Eli Zaretskii.

	libctf/
		PR libctf/31863
		* ctf-impl.h (_libctf_printflike_): Use __gnu_printf__.

2025-06-04  Nick Alcock  <nick.alcock@oracle.com>

	libctf, dedup: reclaim space wasted by duplicate hidden types
	In normal deduplicating links, we insert every type (identified by its
	unique hash) precisely once.  But conflicting types appear in multiple
	dicts, so for those, we loop, inserting them into every target dict
	in turn (each corresponding to an input dict that type appears in).
	But in cu-mapped links, some of those dicts may have been merged into
	one: now that we are hiding duplicate conflicting types more
	aggressively in such links, we are getting duplicate identical hidden
	types turning up in large numbers.

	Fix this by eliminating them in cu-mapping phase 1 (the phase in which this
	merging takes place), by checking to see if a type with this hash has
	already been inserted in this dict and skipping it if so.  This is
	redundant and a waste of time in other cu-mapping phases and in normal
	links, but in cu-mapped links it saves a few tens to hundreds of kilobytes
	in kernel-sized links.

	libctf/
		PR libctf/33047
		* ctf-dedup.c (ctf_dedup_emit_type): Check for already-emitted
		types in cu-mapping phase 1.

2025-06-04  Nick Alcock  <nick.alcock@oracle.com>

	libctf: dedup: preserve non-root flag across normal links
	The previous commits dropped preservation of the non-root flag in ctf_link
	and arranged to use it somewhat differently to track conflicting types in
	cu-mapped CUs when doing cu-mapped links.  This was necessary to prevent
	entirely spuriously hidden types from appearing on the output of such links.

	Bring it (and the test for it) back.  The problem with the previous design
	was that it implicitly assumed that the non-root flag it saw on the input
	was always meant to be preserved (when in the final phase of cu-mapped links
	it merely means that conflicting types were found in intermediate links),
	and also that it could figure out what the non-root flag on the input was by
	sucking in the non-root flag of the input type corresponding to an output in
	the output mapping (which maps type hashes to a corresponding type on some
	input).

	This method of getting properties of the input type *does* work *if* that
	property was one of those hashed by the ctf_dedup_hash_type process.  In
	that case, every type with a given hash will have the same value for all
	hashed-in properties, so it doesn't matter which one is consulted (the
	output mapping points at an arbitrary one of those input types).  But the
	non-root flag is explicitly *not* hashed in: as a comment in
	ctf_dedup_rhash_type notes, being non-root is not a property of a type, and
	two types (one non-root, one not) can perfectly well be the same type even
	though one is visible and one isn't.  So just copying the non-root flag from
	the output mapping's idea of the input type will copy in a value that is not
	stabilized by the hash, so is more-or-less random!

	So we cannot do that.  We have to do something else, which means we have to
	decide what to do if two identical types with different nonroot flag values
	pop up.  The most sensible thing to do is probably to say that if all
	instances of a type are non-root-visible, the linked output should also be
	non-root-visible: any root-visible types in that set, and the output type is
	root-visible again.

	We implement this with a new cd_nonroot_consistency dynhash, which maps type
	hashes to the value 0 ("all instances root-visible"), 1 ("all instances
	non-root-visible") or 2 ("inconsistent").  After hashing is over, we save a
	bit of memory by deleting everything from this hashtab that doesn't have a
	value of 1 ("non-root-visible"), then use this to decide whether to emit any
	given type as non-root-visible or not.

	However... that's not quite enough.  In cu-mapped links, we want to
	disregard this whole thing because we just hide everything -- but in phase
	2, when we take the smushed-together CUs resulting from phase 1 and
	deduplicate them against each other, we want to do what the previous commits
	implemented and ignore the non-root flag entirely, instead falling back to
	preventing clashes by hiding anything that would be considered conflicting.
	We extend the existing cu_mapped parameter to various bits of ctf_dedup so
	that it is now tristate: 0 means a normal link, 1 means the smush-it-
	together phase of cu-mapped links, and 2 means the final phase of cu-mapped
	links.  We do the hide-conflicting stuff only in phase 2, meaning that
	normal links by GNU ld can always respect the value of the nonroot flag put
	on types in the input.

	(One extra thing added as part of this: you can now efficiently delete the
	last value returned by ctf_dynhash_next() by calling
	ctf_dynhash_next_remove.)

	We bring back the ctf-nonroot-linking test with one tweak: linking now works
	on mingw as long as you're using the ucrt libc, so re-enable it for better
	test coverage on that platform.

	libctf/
		PR libctf/33047
		* ctf-hash.c (ctf_dynhash_next_remove): New.
		* ctf-impl.h (struct ctf_dedup) [cd_nonroot_consistency]: New.
		* ctf-link.c (ctf_link_deduplicating):  Differentiate between
		cu-mapped and non-cu-mapped links, even in the final phase.
		* ctf-dedup.c (ctf_dedup_hash_type): Callback prototype addition.
		Get the non-root flag and pass it down.
		(ctf_dedup_rhash_type): Callback prototype addition. Document
		restrictions on use of the nonroot flag.
		(ctf_dedup_populate_mappings): Populate cd_nonroot_consistency.
		(ctf_dedup_hash_type_fini): New function: delete now-unnecessary
		values from cd_nonroot_consistency.
		(ctf_dedup_init): Initialize it.
		(ctf_dedup_fini): Destroy it.
		(ctf_dedup): cu_mapping is now cu_mapping_phase.  Call
		ctf_dedup_hash_type_fini.
		(ctf_dedup_emit_type): Use cu_mapping_phase and
		cd_nonroot_consistency to propagate the non-root flag into outputs
		for normal links, and to do name-based conflict checking only for
		phase 2 of cu-mapped links.
		(ctf_dedup_emit): cu_mapping is now cu_mapping_phase.  Adjust
		assertion accordingly.
		* testsuite/libctf-writable/ctf-nonroot-linking.c: Bring back.
		* testsuite/libctf-writable/ctf-nonroot-linking.lk: Likewise.

2025-06-04  Nick Alcock  <nick.alcock@oracle.com>

	libctf: dedup: improve hiding of conflicting types in the same dict
	If types are conflicting, they are usually moved into separate child dicts
	-- but not always.  If they are added to the same dict by the cu-mapping
	mechanism (as used e.g. for multi-TU kernel modules), we can easily end
	up adding multiple conflicting types with the same name to the same dict.

	The mechanism used for turning on the non-root-visible flag in order to do
	this had a kludge attached which always hid types with the same name,
	whether or not they were conflicting.  This is unnecessary and can hide
	types that should not be hidden, as well as hiding bugs.  Remove it, and
	replace it with two different approaches:

	 - for everything but cu-mapped links (the in-memory first phase of a link
	   with ctf_link_add_cu_mapping in force), check for duplicate names if
	   types are conflicting, and mark them as hidden if the names are found.
	   This will never happen in normal links (in an upcoming commit we will
	   suppress doing even this much in such cases).

	 - for cu-mapped links, the only case that merges multiple distinct target
	   dicts into one, we apply a big hammer and simply hide everything!  The
	   non-root flag will be ignored in the next link phase anyway (which dedups
	   the cu-mapped pieces against each other), and this way we can be sure
	   that merging multiple types cannot incur name clashes at this stage.

	The result seems to work: the only annoyance is that when enums with
	conflicting enumerators are found in a single cu-mapped child (so, really
	multiple merged children), you may end up with every instance of that enum
	being hidden for reasons of conflictingness.  I don't see a real way to
	avoid that.

	libctf/
		PR libctf/33047
		* ctf-dedup.c (ctf_dedup_emit_type): Only consider non
		conflicting types.  Improve type hiding in the presence of clashing
		enumerators.  Hide everything when doing a cu-mapped link: they will
		be unhidden by the next link pass if nonconflicting.

2025-06-04  Nick Alcock  <nick.alcock@oracle.com>

	Revert "libctf: fix linking of non-root-visible types"
	This reverts commit 87b2f673102884d7c69144c85a26ed5dbaa4f86a.

	It is based on a misconception, that hidden types in the deduplicator
	input should always be hidden in the output.  For cu-mapped links,
	and final links following cu-mapped links, this is not true: we want
	to hide inputs if they were conflicting on the output and no more.

	We will reintroduce the testcase once a better fix is found.

	libctf/
		PR libctf/33047
		* ctf-dedup.c (ctf_dedup_emit_type): Don't respect the nonroot flag.
		* testsuite/libctf-writable/ctf-nonroot-linking.c: Removed.
		* testsuite/libctf-writable/ctf-nonroot-linking.lk: Removed.

2025-06-04  Dmitry Chestnykh  <dm.chestnykh@gmail.com>

	aarch64: Support id_aa64fpfr0_el1, id_aa64pfr2_el1

2025-06-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/python/guile: fix segfault from nested prefix command creation
	A commit I recently pushed:

	  commit 0b5023cc71d3af8b18e10e6599a3f9381bc15265
	  Date:   Sat Apr 12 09:15:53 2025 +0100

	      gdb/python/guile: user created prefix commands get help list

	can trigger a segfault if a user tries to create nested prefix
	commands.  For example, this will trigger a crash:

	  (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE)
	  (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE)

	  Fatal signal: Segmentation fault
	  ... etc ...

	If the user adds an actual parameter under 'prefix-1' before creating
	'prefix-2', then everything is fine:

	  (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE)
	  (gdb) python gdb.Parameter('prefix-1 param-1', gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
	  (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE)

	The mistake in the above patch is in how gdbpy_parse_command_name is
	used.  The BASE_LIST output argument from this function points to the
	list of commands for the prefix, not to the prefix command itself.

	So when gdbpy_parse_command_name is called for 'prefix-1 prefix-2',
	BASE_LIST points to the list of commands associated with 'prefix-1',
	not to the actual 'prefix-1' cmd_list_element.

	Back in cmdpy_init, from where gdbpy_parse_command_name was called, I
	was walking back from the first entry in BASE_LIST to figure out if
	this was a "show" prefix command or not.  However, if BASE_LIST is
	empty then there is no first item, and this would trigger the
	segfault.

	The solution it to extend gdbpy_parse_command_name to also return the
	prefix cmd_list_element in addition to the existing values.  With this
	done, and cmdpy_init updated, the segfault is now avoided.

	There's a new test that would trigger the crash without the patch.

	And, of course, the above commit also broke guile in the exact same
	way.  And the fix is exactly the same.  And there's a guile test too.

	NOTE: We should investigate possibly sharing some of this boiler plate
	helper code between Python and Guile.  But not in this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/exec-invalid-sysroot.exp
	Since commit d462550c91c ("gdb/testsuite: also compile foll-exec.exp as C++"),
	we run into:
	...
	Running gdb.base/exec-invalid-sysroot.exp ...
	gdb compile failed, foll-exec.c: In function 'main':
	foll-exec.c:35:52: error: 'EXECD_PROG' undeclared (first use in this function)
	   printf ("foll-exec is about to execlp(%s)...\n", EXECD_PROG);
	                                                    ^~~~~~~~~~
	foll-exec.c:35:52: note: each undeclared identifier is reported only once \
	  for each function it appears in
	...

	Fix this by default-defining EXECD_PROG to "execd-prog".

	Tested on x86_64-linux.

2025-06-04  Rui Ueyama  <ruiu@cs.stanford.edu>

	Reject compressed sections exceding 4 GiB on LLP64 machines
	According to the zlib FAQ (*1), zlib does not support compressed data
	larger than 4 GiB when the compiler's long type is 32 bits. Therefore,
	we need to report an error if a zlib-compressed debug section exceeds
	4 GiB on LLP64 machines.

	(*1) https://zlib.net/zlib_faq.html#faq32

2025-06-04  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: fix PR libsframe/33051
	Fix PR libsframe/Bug 33051 - ASAN: heap-buffer-overflow
	../../src/libsframe/sframe.c:1054 in
	sframe_get_funcdesc_with_addr_internal

	The previous commit 9d2a24349e2 (libsframe: correct binary search for
	SFrame FDE) adapted the binary search logic in
	sframe_get_funcdesc_with_addr_internal.  Adjusting the upper end of the
	search index was missed.

	The search must only be done for FDEs starting at index 0 and up until
	num_fdes - 1.  Prior logic of searching (before commit 9d2a24349e2) was
	a bit different.

	libsframe/
		* sframe.c: Use the correct high index.

2025-06-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: also compile foll-exec.exp as C++
	For a long time, Fedora GDB has carried a test that performs some
	basic testing that GDB can handle 'catch exec' related commands for a
	C++ executable.

	The exact motivation for this test has been lost in the mists of time,
	but looking at the test script, the concern seems to be that GDB would
	have problems inserting C++ related internal breakpoints if a non C++
	process is execd from a C++ one.

	There's no actual GDB fix associated with the Fedora test.  This
	usually means that the issue was fixed upstream long ago.  This patch
	does seem to date from around 2010ish (or maybe earlier).

	Having a look through the upstream tests, I cannot see anything that
	covers this sort of thing (C++ to C exec calls), and I figure it
	cannot hurt to have some additional testing in this area, and so I
	wrote this patch.

	I've taken the existing foll-exec.exp test, which compiles a C
	executable and then execs a different C executable, and split it into
	two copies.

	We now have foll-exec-c.exp and foll-exec-c++.exp.  These tests
	compile a C and C++ executable respectively.  Then within each of
	these scripts both a C and C++ helper application is built, which can
	then be execd from the main test executable.

	And so, we now cover 4 cases, the initial executable can be C or C++,
	and the execd process can be C or C++.

	As expected, everything passes.  This is just increasing test
	coverage.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Make dwarf support optional at compile time
	This commit allows a user to enable or disable dwarf support at
	compilation time. To do that, a new configure option is introduced, in
	the form of --enable-gdb-dwarf-support (and the accompanying --disable
	version). By default, dwarf support is enabled, so no behavior changes
	occur if a user doesn't use the new feature. If support is disabled, no
	.c files inside the dwarf2/ subfolder will be compiled into the final
	binary.

	To achieve this, this commit also introduces the new macro
	DWARF_FORMAT_AVAILABLE, which guards the definitions of functions
	exported from the dwarf reader. If the macro is not defined, there are a
	couple behaviors that exported functions may have:
	* no-ops: several functions are used to register things at
	  initialization time, like unwinders. These are turned into no-ops
	  because the user hasn't attempted to read DWARF yet, there's no point
	  in warning that DWARF is unavailable.
	* warnings: similar to the previous commit, if dwarf would be read or
	  used, the funciton will emit the warning "No dwarf support available."
	* throw exceptions: If the code that calls a function expects an
	  exceptin in case of errors, and has a try-catch block, an error with
	  the previous message is thrown.

	I believe that the changed functions should probalby be moved to the
	dwarf2/public.h header, but that require a much larger refactor, so it
	is left as a future improvement.

	Finally, the --enable-gdb-compile configure option has been slightly
	changed, since compile requires dwarf support. If compile was requested
	and dwarf was disabled, configure will throw an error. If the option was
	not used, support will follow what was requested for dwarf (warning the
	user of what is decided).

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb: wrap mdebug debuginfo reading in ifdefs
	This commit aims to allow a user to enable or disable mdebug support at
	compilation time. To do that, a new configure option is added, called
	--enable-gdb-mdebug-support (and the accompanying --disable version). By
	default, support is enabled, and if a user decides to disable support,
	the file mdebugread.c won't be compiled in the final binary, and the
	macro MDEBUG_FORMAT_AVAILABLE won't be defined.

	That macro is used to control the definitions of mdebug reading, either
	the actual definition in mdebugread.c, or a static inline version that
	only emits the following warning:

	> No mdebug support available.

	Ideally, we'd like to guard the entirity of mdebugread in the macro, but
	the alpha-mdebug-tdep file uses those directly, and I don't think we
	should restrict alpha hosts to requiring that debug format compiled in,
	nor do I understand the tdep file enough to be comfortable disentangling
	the requirements.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-06-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Use multiple minimal_symbol_readers in mipscoff_symfile_read
	Currently, mipscoff_symfile_read uses a single minimal_symbol_reader to
	get all minimal symbols from mdebug-formatted debuginfo, and from
	alphacoff. This pattern has been around since minimal_symbol_reader has
	been introduced, and from own research, there's no need to use the same
	reader. This made it so mipscoff_symfile_read could call
	mdebug_build_psymtabs directly, since the latter needs a reference to
	the minsym reader object. The issue is that future commits need a
	unified entrance point to read debuginfo, and this pattern is very
	different to how elf does mdebug reading.

	In fact, the elf mdebug reader does some preparatory steps and then
	calls mdebug_build_psymtabs, so what the mips version does is just
	spread these preparatory steps through the mipscoff function instead.

	To make it easier for future commits to query debuginfo support
	dynamically (as opposed to assuming things at compile time), this commit
	introduces a new mipsmdebug_build_psymtabs function, which does similar
	preparatory steps as elfmdebug_build_psymtabs. It is added to
	mdebugread.c to help with maintaining a separation between reading an
	objfile (in mipsread.c) and its debuginfo (mdebug), so that in the
	future we have an easier time selectively disabling debuginfo formats
	at compilation time. This should have no visible changes for the end
	user.

	The new function must receive the pointers to ecoff_debug_swap and
	ecoff_debug_info because finding those structures based on the bfd
	object necessitates including the headers libcoff.h and libecoff.h,
	and those headers can't be included at the same time as libaout.h
	- which mdebugread.c already uses.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-06-03  Nick Clifton  <nickc@redhat.com>

	Add checks for illegal symbol binding and type values when reading ELF symbols.
	PR 33019

2025-06-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/python/guile: user created prefix commands get help list
	Consider GDB's builtin prefix set/show prefix sub-commands, if they
	are invoked with no sub-command name then they work like this:

	  (gdb) show print
	  print address:  Printing of addresses is on.
	  print array:  Pretty formatting of arrays is off.
	  print array-indexes:  Printing of array indexes is off.
	  print asm-demangle:  Demangling of C++/ObjC names in disassembly listings is off.
	  ... cut lots of lines ...
	  (gdb) set print
	  List of set print subcommands:

	  set print address -- Set printing of addresses.
	  set print array -- Set pretty formatting of arrays.
	  set print array-indexes -- Set printing of array indexes.
	  set print asm-demangle -- Set demangling of C++/ObjC names in disassembly listings.
	  ... cut lots of lines ...

	  Type "help set print" followed by set print subcommand name for full documentation.
	  Type "apropos word" to search for commands related to "word".
	  Type "apropos -v word" for full documentation of commands related to "word".
	  Command name abbreviations are allowed if unambiguous.
	  (gdb)

	That is 'show print' lists the values of all settings under the
	'print' prefix, and 'set print' lists the help text for all settings
	under the 'set print' prefix.

	Now, if we try to create something similar using the Python API:

	  (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE)
	  (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN)
	  (gdb) show my-prefix
	  (gdb) set my-prefix

	Neither 'show my-prefix' or 'set my-prefix' gives us the same details
	relating to the sub-commands that we get with the builtin prefix
	commands.

	This commit aims to address this.

	Currently, in cmdpy_init, when a new command is created, we always set
	the commands callback function to cmdpy_function.  It is within
	cmdpy_function that we spot that the command is a prefix command, and
	that there is no gdb.Command.invoke method, and so return early.

	This commit changes things so that the rules are now:

	  1. For NON prefix commands, we continue to use cmdpy_function.
	  2. For prefix commands that do have a gdb.Command.invoke
	     method (i.e. can handle unknown sub-commands), continue to use
	     cmdpy_function.
	  3. For all other prefix commands, don't use cmdpy_function, instead
	     use GDB's normal callback function for set/show prefixes.

	This requires splitting the current call to add_prefix_cmd into either
	a call to add_prefix_cmd, add_show_prefix_cmd, or
	add_basic_prefix_cmd, as appropriate.

	After these changes, we now see this:

	  (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE)     │
	  (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN)
	  (gdb) show my-prefix                                                │
	  my-prefix foo:  The current value of 'my-prefix foo' is "off".
	  (gdb) set my-prefix
	  List of "set my-prefix" subcommands:

	  set my-prefix foo -- Set the current value of 'my-prefix foo'.

	  Type "help set my-prefix" followed by subcommand name for full documentation.
	  Type "apropos word" to search for commands related to "word".
	  Type "apropos -v word" for full documentation of commands related to "word".
	  Command name abbreviations are allowed if unambiguous.
	  (gdb)

	Which matches how a prefix defined within GDB would act.

	I have made the same changes to the Guile API.

2025-06-03  Tom Tromey  <tromey@adacore.com>

	Clean up comment in dw2-ranges-psym-warning.exp
	This removes a trailing backslash from a comment in
	dw2-ranges-psym-warning.exp.  This backslash causes Emacs to try to
	reindent the next line.  This happens because comments are weird in
	Tcl -- they are not exactly syntactic and the backslash still acts as
	a line-continuation marker here.

2025-06-03  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: doc: add date to the pdf output
	libsframe/doc/
		* sframe-spec.texi: Include date with each publication.

2025-06-03  Tom Tromey  <tromey@adacore.com>

	Handle dynamic DW_AT_data_bit_offset
	In Ada, a field can have a dynamic bit offset in its enclosing record.

	In DWARF 3, this was handled using a dynamic
	DW_AT_data_member_location, combined with a DW_AT_bit_offset -- this
	combination worked out ok because in practice GNAT only needs a
	dynamic byte offset with a fixed offset within the byte.

	However, this approach was deprecated in DWARF 4 and then removed in
	DWARF 5.  No replacement approach was given, meaning that in strict
	mode there is no way to express this.

	This is a DWARF bug, see

	    https://dwarfstd.org/issues/250501.1.html

	In a discussion on the DWARF mailing list, a couple people mentioned
	that compilers could use the obvious extension of a dynamic
	DW_AT_data_bit_offset.  I've implemented this for LLVM:

	    https://github.com/llvm/llvm-project/pull/141106

	In preparation for that landing, this patch implements support for
	this construct in gdb.

	New in v2: renamed some constants and added a helper method, per
	Simon's review.

	New in v3: more renamings.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: support zero inode in generate-core-file command
	It is possible, when creating a shared memory segment (i.e. with
	shmget), that the id of the segment will be zero.

	When looking at the segment in /proc/PID/smaps, the inode field of the
	entry holds the shared memory segment id.

	And so, it can be the case that an entry (in the smaps file) will have
	an inode of zero.

	When GDB generates a core file, with the generate-core-file (or its
	gcore alias) command, the shared memory segment should be written into
	the core file.

	Fedora GDB has, since 2008, carried a patch that tests this case.
	There is no fix for GDB associated with the test, and unfortunately,
	the motivation for the test has been lost to the mists of time.  This
	likely means that a fix was merged upstream without a suitable test,
	but I've not been able to find and relevant commit.  The test seems to
	be checking that the shared memory segment with id zero, is being
	written to the core file.

	While looking at this test and trying to work out if it should be
	posted upstream, I saw that GDB does appear to write the shared memory
	segment into the core file (as expected), which is good.  However, GDB
	still isn't getting this case exactly right, there appears to be no
	NT_FILE entry for the shared memory mapping if the mapping had an id
	of zero.

	In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via
	the gdbarch_find_memory_regions call) to correctly write the shared
	memory segment into the core file, however, in
	linux_make_mappings_corefile_notes, when we use
	linux_find_memory_regions_full to create the NT_FILE note, we call
	back in to dump_note_entry_p for each mapping, and in here we reject
	any mapping with a zero inode.

	The result of this, is that, for a shared memory segment with a
	non-zero id, after loading the core file, the shared memory segment
	will appear in the 'proc info mappings' output.  But, for a shared
	memory segment with a zero id, the segment will not appear in the
	'proc info mappings' output.

	I initially tried just dropping the inode check in this function (see
	previous commit 1e21c846c27, which I then reverted in commit
	998165ba99a.

	The problem with dropping the inode check is that the special kernel
	mappings, e.g. '[vvar]' would now get a NT_FILE entry.  In fact, any
	special entry except '[vdso]' and '[vsyscall]' which are specifically
	checked for in dump_note_entry_p would get a NT_FILE entry, which is
	not correct.

	So, instead, I propose that if the inode is zero, and the filename
	starts with '[' and finished with ']' then we should not create a
	NT_FILE entry.  But otherwise a zero inode should not prevent a
	NT_FILE entry being created.

	The test for this change is a bit tricky.  The original Fedora
	test (mentioned above) has a loop that tries to grab the shared memory
	mapping with id zero.  This was, unfortunately, not very reliable.

	I tried to make this more reliable by going multi-threaded, and
	waiting for longer, see my proposal here:

	  https://inbox.sourceware.org/gdb-patches/0d389b435cbb0924335adbc9eba6cf30b4a2c4ee.1741776651.git.aburgess@redhat.com

	But this was still not great.  On further testing this was only
	passing (i.e. managing to find the shared memory mapping with id zero)
	about 60% of the time.

	However, I realised that GDB finds the shared memory id by reading the
	/proc/PID/smaps file.  But we don't really _need_ the shared memory id
	for anything, we just use the value (as an inode) to decide if the
	segment should be included in the core file or not.  The id isn't even
	written to the core file.  So, if we could intercept the read of the
	smaps file, then maybe, we could lie to GDB, and tell it that the id
	was zero, and then see how GDB handles this.

	And luckily, we can do that using a preload library!

	We already have a test that uses a preload library to modify GDB, see
	gdb.threads/attach-slow-waitpid.exp.

	So, I have created a new preload library.  This one intercepts open,
	open64, close, read, and pread.  When GDB attempts to open
	/proc/PID/smaps, the library spots this and loads the file contents
	into a memory buffer.  The buffer is then modified to change the id of
	any shared memory mapping to zero.  Any reads from this file are
	served from the modified memory buffer.

	I tested on x86-64, AArch64, PPC, s390, and ARM, all running various
	versions of GNU/Linux.  The requirement for open64() came from my ARM
	testing.  The other targets used plain open().

	And so, the test is now simple.  Start GDB with the preload library in
	place, start the inferior and generate a core file.  Then restart GDB,
	load the core file, and check the shared memory mapping was included.
	This test will fail with an unpatched GDB, and succeed with the patch
	applied.

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-06-03  Piotr Rudnicki  <piotr.rudnicki@intel.com>

	gdb: handle struct and union types in evaluate_subexp_for_address_base
	Suppose a function returns a struct and a method of that struct is
	called.  E.g.:

	  struct S
	  {
	    int a;
	    int get () { return a; }
	  };

	  S f ()
	  {
	    S s;
	    s.a = 42;
	    return s;
	  }

	  ...
	  int z = f().get();
	  ...

	GDB is able to evaluate the expression:

	  (gdb) print f().get()
	  $1 = 42

	However, type-checking the expression fails:

	  (gdb) ptype f().get()
	  Attempt to take address of value not located in memory.

	This happens because the `get` function takes an implicit `this`
	pointer, which in this case is the value returned by `f()`, and GDB
	wants to get an address for that value, as if passing the implicit
	this pointer.  However, during type-checking, the struct value
	returned by `f()` is a `not_lval`.

	A similar issue exists for union types, where methods called on
	temporary union objects would fail type-checking in the same way.

	Address the problems by handling `TYPE_CODE_STRUCT` and
	`TYPE_CODE_UNION` in `evaluate_subexp_for_address_base`.

	With this change, for struct's method call, we get

	  (gdb) ptype f().get()
	  type = int

	Add new test cases to file gdb.cp/chained-calls.exp to test this change.

	Regression-tested in X86-64 Linux.

2025-06-03  Piotr Rudnicki  <piotr.rudnicki@intel.com>

	gdb: remove unused argument in evaluate_subexp_for_address_base
	Remove the unused 'struct expression *exp' parameter from
	evaluate_subexp_for_address_base and also do some format cleanup.

2025-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Use captured per_command_time in worker threads
	With test-case gdb.base/maint.exp, I ran into:
	...
	(gdb) file maint^M
	Reading symbols from maint...^M
	(gdb) mt set per-command on^M
	(gdb) Time for "DWARF indexing worker": ...^M
	Time for "DWARF indexing worker": ...^M
	Time for "DWARF indexing worker": ...^M
	Time for "DWARF indexing worker": ...^M
	Time for "DWARF skeletonless type units": ...^M
	Time for "DWARF add parent map": ...^M
	Time for "DWARF finalize worker": ...^M
	Time for "DWARF finalize worker": ...^M
	Time for "DWARF finalize worker": ...^M
	Time for "DWARF finalize worker": ...^M
	Time for "DWARF finalize worker": ...^M
	FAIL: $exp: warnings: per-command: mt set per-command on (timeout)
	mt set per-command off^M
	2025-05-31 09:33:44.711 - command started^M
	(gdb) PASS: $exp: warnings: per-command: mt set per-command off
	...

	I didn't manage to reproduce this by rerunning the test-case, but it's fairly
	easy to reproduce using a file with more debug info, for instance gdb:
	...
	$ gdb -q -batch -ex "file build/gdb/gdb" -ex "mt set per-command on"
	...

	Due to the default "mt dwarf synchronous" == off, the file command starts
	building the cooked index in the background, and returns immediately without
	waiting for the result.

	The subsequent "mt set per-command on" implies "mt set per-command time on",
	which switches on displaying of per-command execution time.

	The "Time for" lines are the result of those two commands, but these lines
	shouldn't be there because "mt per-command time" == off at the point of
	issuing the file command.

	Fix this by capturing the per_command_time variable, and using the captured
	value instead.

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

	PR cli/33039
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33039

2025-06-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2: update call_site::target comment
	This comment refers to the field location kind enum, even though call
	sites were moved to their own enum in 7eb21cc70224 ("Change
	call_site_target to use custom type and enum").  Update it.

	Change-Id: I089923170c919853efb2946529221a4b55e720c1

2025-06-02  Andrew Burgess  <aburgess@redhat.com>

	gdb: use quoted filename completion for the shell command
	With the quoted filename completion work that I did last year the
	deprecated_filename_completer function will now only complete a single
	word as a filename, for example:

	  (gdb) save breakpoints /tm<TAB>

	The 'save breakpoints' command uses the deprecated_filename_completer
	completion function.  In the above '/tm' will complete to '/tmp/' as
	expected.  However, if you try this:

	  (gdb) save breakpoints /tmp/ /tm<TAB>

	The second '/tm' will not complete for GDB 16.x, but will complete
	with GDB 15.x as GDB 15.x is before my changes were merged.

	What's actually happening here is that, before my changes, the
	filename completion was breaking words on white space, so in the above
	the first '/tmp/' and the second '/tm' are seen as separate words for
	completion, the second word is therefore seen as the start of a new
	filename.

	After my changes, deprecated_filename_completer allows spaces to be
	part of the filename, so in the above, GDB is actually trying to
	complete a filename '/tmp/ /tm' which likely doesn't exist, and so
	completion stops.

	This change for how deprecated_filename_completer works makes sense,
	commands like 'save breakpoints' take their complete command arguments
	and treat it as a single filename, so given this:

	  (gdb) save breakpoints /tmp/ /tm<ENTER>

	GDB really will try to save breakpoints to a file called '/tmp/ /tm',
	weird as that may seem.  How GDB interprets the command arguments
	didn't change with my completion patches, I simply brought completion
	into line with how GDB interprets the arguments.

	The patches I'm talking about here are this set:

	  * 4076f962e8c gdb: split apart two different types of filename completion
	  * dc22ab49e9b gdb: deprecated filename_completer and associated functions
	  * 35036875913 gdb: improve escaping when completing filenames
	  * 1d1df753977 gdb: move display of completion results into completion_result class
	  * bbbfe4af4fb gdb: simplify completion_result::print_matches
	  * 2bebc9ee270 gdb: add match formatter mechanism for 'complete' command output
	  * f2f866c6ca8 gdb: apply escaping to filenames in 'complete' results
	  * 8f87fcb1daf gdb: improve gdb_rl_find_completion_word for quoted words
	  * 67b8e30af90 gdb: implement readline rl_directory_rewrite_hook callback
	  * 1be3b2e82f7 gdb: extend completion of quoted filenames to work in brkchars phase
	  * 9dedc2ac713 gdb: fix for completing a second filename for a command
	  * 4339a3ffc39 gdb: fix filename completion in the middle of a line

	Bug PR gdb/32982 identifies a problem with the shell command;
	completion broke between 15.x and 16.x.  The shell command also uses
	deprecated_filename_completer for completion.  But consider a shell
	command line:

	  (gdb) shell ls /tm<TAB>

	The arguments to the shell command are 'ls /tm' at the point <TAB> is
	pressed.  Under the old 15.x completion GDB would split the words on
	white space and then try to complete '/tm' as a filename.

	Under the 16.x model, GDB completes all the arguments as a single
	filename, that is 'ls /tm', which is unlikely to match any filenames,
	and so completion fails.

	The fix is to write a custom completion function for the shell_command
	function (cli/cli-cmds.c), this custom completion function will skip
	forward to find the last word in the arguments, and then try to
	complete that, so in the above example, GDB will skip over 'ls ', and
	then tries to complete '/tm', which is exactly what we want.

	Given that the filenames passed to the shell command are forwarded to
	an actual shell, I have switched over the new quoted filename
	completion function for the shell command, this means that white space
	within a filename will be escaped with a backslash by the completion
	function, which is likely what the user wants, this means the filename
	will arrive in the (actual) shell as a single word, rather than
	splitting on white space and arriving as two words.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32982

	Reviewed-By: Tom Tromey <tom@tromey.com>

2025-06-02  Tom Tromey  <tromey@adacore.com>

	Fix DAP defer_stop_events implementation
	DAP requests have a "defer_stop_events" option that is intended to
	defer the emission of any "stopped" event until after the current
	request completes.  This was needed to handle async continues like
	"finish &".

	However, I noticed that sometimes DAP tests can fail, because a stop
	event does arrive before the response to the "stepOut" request.  I've
	only noticed this when the machine is fairly loaded -- for instance
	when I'm regression-testing a series, it may occur in some of the
	tests mid-series.

	I believe the problem is that the implementation in the "request"
	function is incorrect -- the flag is set when "request" is invoked,
	but instead it must be deferred until the request itself is run.  That
	is, the setting must be captured in one of the wrapper functions.

	Following up on this, Simon pointed out that introducing a delay
	before sending a request's response will cause test case failures.
	That is, there's a race here that is normally hidden.

	Investigation showed that that deferred requests can't force event
	deferral.  This patch implements this; but more testing showed many
	more race failures.  Some of these are due to how the test suite is
	written.

	Anyway, in the end I took the radical approach of deferring all events
	by default.  Most DAP requests are asynchronous by nature, so this
	seemed ok.  The only case I found that really required this is
	pause.exp, where the test (rightly) expects to see a 'continued' event
	while performing an inferior function call.

	I went through all events and all requests and tried to convince
	myself that this patch will cause acceptable behavior in every case.
	However, it's hard to be completely sure about this approach.  Maybe
	there are cases that do still need an event before the response, but
	we just don't have tests for them.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32685
	Acked-By: Simon Marchi <simon.marchi@efficios.com>

2025-06-02  Patrick Monnerat  <patrick@monnerat.net>

	gdb: introduce a per-interpreter event servicing method
	This allows an interpreter to override internal calls to
	gdb_do_one_event in case the former needs to handle alternate event
	sources.

	The default action is to call gdb_do_one_event and this is not overriden
	in current internal interpreters. However this feature allows to easily
	embed Tcl/Tk in insight that needs to concurrently handle Tcl events for
	GUI handling.

	In all cases, an interpreter event servicing method must call
	gdb_do_one_event at some point.

	All internal event servicing calls from gdb now direct to the
	interpreter-specific method rather than gdb_do_one_event itself.

2025-06-02  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Reimplement F405 fix
	At commit 34b0776fd73^, flake8 reports the following F405 warnings:
	...
	$ pre-commit run flake8 --file gdb/python/lib/gdb/__init__.py
	flake8...................................................................Failed
	- hook id: flake8
	- exit code: 1

	F405 'flush' may be undefined, or defined from star imports: _gdb
	F405 'write' may be undefined, or defined from star imports: _gdb
	F405 'STDOUT' may be undefined, or defined from star imports: _gdb
	F405 'STDERR' may be undefined, or defined from star imports: _gdb
	  ...
	F405 'selected_inferior' may be undefined, or defined from star imports: _gdb
	F405 'execute' may be undefined, or defined from star imports: _gdb
	F405 'parameter' may be undefined, or defined from star imports: _gdb
	...

	The F405s are addressed by commit 34b0776fd73 ('Suppress some "undefined"
	warnings from flake8').

	The problem indicated by the first F405 is that the use of flush here:
	...
	class _GdbFile(object):
	     ...
	    def flush(self):
	        flush(stream=self.stream)
	...
	cannot be verified by flake8.  It concludes that either, flush is undefined,
	or it is defined by this "star import":
	...
	from _gdb import *  # noqa: F401,F403
	...

	In this particular case, indeed flush is defined by the star import.

	This can be addressed by simply adding:
	...
	        flush(stream=self.stream)  # noqa: F405
	...
	but that has only effect for flake8, so other analyzers may report the same
	problem.

	The commit 34b0776fd73 addresses it instead by adding an "import _gdb" and
	adding a "_gdb." prefix:
	...
	        _gdb.flush(stream=self.stream)
	...

	This introduces a second way to specify _gdb names, but the first one still
	remains, and occasionally someone will use the first one, which then requires
	fixing once flake8 is run [1].

	While this works to silence the warnings, there is a problem: if a developer
	makes a typo:
	...
	        _gdb.flash(stream=self.stream)
	...
	this is not detected by flake8.

	This matters because although the python import already complains:
	...
	$ gdb -q -batch -ex "python import gdb"
	Exception ignored in: <gdb._GdbFile object at 0x7f6186d4d7f0>
	Traceback (most recent call last):
	  File "__init__.py", line 63, in flush
	    _gdb.flash(stream=self.stream)
	AttributeError: module '_gdb' has no attribute 'flash'
	...
	that doesn't trigger if the code is hidden behind some control flow:
	...
		if _var_mostly_false:
		    flash(stream=self.stream)
	...

	Instead, fix the F405s by reverting commit 34b0776fd73 and adding a second
	import of _gdb alongside the star import which lists the names used locally:
	...
	 from _gdb import *  # noqa: F401,F403
	+from _gdb import (
	+    STDERR,
	+    STDOUT,
	+    Command,
	+    execute,
	+    flush,
	+    parameter,
	+    selected_inferior,
	+    write,
	+)
	...

	This gives the following warnings for the flash typo:
	...
	31:1: F401 '_gdb.flush' imported but unused
	70:5: F811 redefinition of unused 'flush' from line 31
	71:9: F405 'flash' may be undefined, or defined from star imports: _gdb
	...

	The benefits of this approach compared to the previous one are that:
	- the typo is noticed, and
	- when using a new name, the F405 fix needs to be done once (by adding it to
	  the explicit import list), while previously the fix had to be applied to
	  each use (by adding the "_gdb." prefix).

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] Commit 475799b692e ("Fix some pre-commit nits in gdb/__init__.py")

2025-06-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-06-01  Tom Tromey  <tom@tromey.com>

	Have bfd_thread_init fail when thread-local storage is unavailable
	If thread-local storage is unavailable, bfd_thread_init should fail,
	because in this case BFD can't be used from multiple threads -- it
	relies on TLS working.

2025-06-01  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.ada/finish-var-size.exp on ppc64le-linux
	On openSUSE Tumbleweed ppc64le-linux using gcc 14.3.0, with a gdb 16.3 based
	package and test-case gdb.ada/finish-var-size.exp, I run into:
	...
	(gdb) finish^M
	Run till exit from #0  pck.get (value=true) at pck.adb:19^M
	0x0000000100004a20 in p () at finish-var-size/p.adb:18^M
	18        V : Result_T := Get (True);^M
	Value returned is $1 = <error reading variable: \
	  Cannot access memory at address 0x0>^M
	(gdb) FAIL: gdb.ada/finish-var-size.exp: finish
	...

	Function pck.get returns type Result_T:
	...
	  type Array_Type is array (1 .. 64) of Integer;

	  type Maybe_Array (Defined : Boolean := False) is
	    record
	      Arr : Array_Type;
	      Arr2 : Array_Type;
	    end record;

	  type Result_T (Defined : Boolean := False) is
	    record
	      case Defined is
	        when False =>
	          Arr : Maybe_Array;
	        when True =>
	          Payload : Boolean;
	      end case;
	    end record;
	...
	and uses r3 as address of the return value, which means
	RETURN_VALUE_STRUCT_CONVENTION, but while executing finish_command we do:
	...
	      return_value
		= gdbarch_return_value_as_value (gdbarch,
	                                         read_var_value (sm->function, nullptr,
	                                                         callee_frame),
	                                         val_type, nullptr, nullptr, nullptr);
	...
	and get:
	...
	(gdb) p return_value
	$1 = RETURN_VALUE_REGISTER_CONVENTION
	...

	This is caused by this check in ppc64_sysv_abi_return_value:
	...
	   /* In the ELFv2 ABI, aggregate types of up to 16 bytes are
	      returned in registers r3:r4.  */
	   if (tdep->elf_abi == POWERPC_ELF_V2
	       && valtype->length () <= 16
	...
	which succeeds because valtype->length () == 0.

	Fix this by also checking for !TYPE_HAS_DYNAMIC_LENGTH (valtype).

	[ I also tested a version of this patch using "!is_dynamic_type (valtype)"
	instead, but ran into a regression in test-case gdb.ada/variant-record.exp,
	because type T:
	...
	    Length : constant Positive := 8;
	    subtype Name_T is String (1 .. Length);

	    type A_Record_T is
	      record
	        X1 : Natural;
	        X2 : Natural;
	      end record;

	    type Yes_No_T is (Yes, No);
	    type T (Well : Yes_No_T := Yes) is
	      record
		case Well is
	          when Yes =>
	            Name : Name_T;
	          when No =>
	            Unique_Name : A_Record_T;
		end case;
	      end record;
	...
	while being dynamic, also has a non-zero size, and is small enough to be
	returned in registers r3:r4. ]

	Fixing this causes the test-case to fail with the familiar:
	...
	warning: Cannot determine the function return value.
	Try compiling with -fvar-tracking.
	...
	and indeed using -fvar-tracking makes the test-case pass.

	Tested on ppc64le-linux.

	PR tdep/33000
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33000

2025-06-01  Alan Modra  <amodra@gmail.com>

	weakref gas internal error
	This horrible testcase (cleaned up from oss-fuzz)
	 r=x*2
	 x=r-r
	 .weakref r,x
	 r=r-5
	triggers resolve_symbol_value "gas_assert (final_val == 0)" in weakref
	handling.

		* read.c (assign_symbol): Clear weakrefr.

2025-06-01  Alan Modra  <amodra@gmail.com>

	decompress_contents: fuss over 32-bit long
	Some 64-bit compilers have a 32-bit long, which could result in an
	endless loop if uncompressed_size is larger than 4G.

2025-06-01  Rui Ueyama  <rui314@gmail.com>

	PR 33033, Support compressed debug sections larger than 4 GiB
	z_stream's avail_in and avail_out are defined as "unsigned int", so it
	cannot decode an entire compressed stream in one pass if the stream is
	larger than 4 GiB. The simplest solution to this problem is to use zlib's
	convenient uncompress2() function, which handles the details for us.

2025-06-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-31  Tom Tromey  <tom@tromey.com>

	Do not allocate macro_scope on the heap
	I noticed that there's no particular reason to allocate the
	macro_scope objects on the heap.  They can be passed around by value
	just as easily.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-31  Tom Tromey  <tom@tromey.com>

	Define TLS in bfd.c if not already defined
	If configure decides that thread-local storage isn't available, it
	does not define "TLS".  However, this is used unconditionally in a
	definition.  So, define it if it isn't already defined.

2025-05-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-30  Alan Modra  <amodra@gmail.com>

	PR 33020 segv in _bfd_elf_strtab_offset
	The PR fuzzer testcase creates a SHT_NOBITS .debug_info section, then
	triggers a bug in --compress-debug-sections=zlib whereby sh_name is
	set to -1 in elf_fake_sections as a flag to indicate the name is not
	set yet (may change to zdebug_*), but the section never hits the debug
	compression code in assign_file_positions_for_non_load_sections that
	is responsible for setting sh_name.

		PR 33020
		* elf.c (_bfd_elf_init_reloc_shdr): Rename delay_st_name_p
		param to delay_sh_name_p.
		(elf_fake_sections): Rename delay_st_name_p to delay_sh_name_p.
		Don't set delay_sh_name_p for no contents debug sections.

2025-05-30  Alan Modra  <amodra@gmail.com>

	Revert "Replace assertions with error return values, thus ensuring an illegal memory access does not occur."
	This reverts commit 429fb15134cfbdafe2b203086ee05d827726b63b.

2025-05-30  Andrew Pinski  <quic_apinski@quicinc.com>

	gprofng: Use __x86_64__ instead of __x86_64
	With some compilers, only __x86_64__ is defined so use that
	instead of __x86_64.

	gprofng/ChangeLog
	2025-05-30  Andrew Pinski  <quic_apinski@quicinc.com>
		* common/core_pcbe.c: s/__x86_64/__x86_64__/.
		* common/cpu_frequency.h: Likewise.
		* common/cpuid.c: Likewise.
		* common/gp-defs.h: Likewise.
		* common/hwctable.c: Likewise.
		* libcollector/libcol-i386-dis.c: Likewise.
		* libcollector/libcol_util.h: Likewise.

2025-05-30  Tom Tromey  <tromey@adacore.com>

	Remove some Rust expression helpers
	When I did the big expression conversion, I left some helper functions
	lying around, primarily because the conversion was already quite large
	and I didn't want to add on.

	This patch removes a couple such helpers, turning them into methods on
	the appropriate operation objects.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix DW_AT_compile_unit -> DW_TAG_compile_unit in comment
	While (mistakenly) grepping for DW_AT_compile_unit, I found this typo.

	Change-Id: I04d97d7b1b27eacfca9da3853711b6092d330575

2025-05-30  Nick Clifton  <nickc@redhat.com>

	Prevent illegal memory access when generating map file entries for ifuncs removed by garbage collection

2025-05-30  Tom Tromey  <tromey@adacore.com>

	Require Python 3.4
	I believe we previously agreed that the minimum supported Python
	version should be 3.4.  This patch makes this change, harmonizing the
	documentation (which was inconsistent about the minimum version) and
	the code.

	New in v2: rebased, and removed a pre-3.4 workaround from __init__.py.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Acked-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31870

2025-05-30  Nick Clifton  <nickc@redhat.com>

	Replace assertions with error return values, thus ensuring an illegal memory access does not occur.
	PR 33020

	Updated Malay translation for the bfd/ sub-directory

2025-05-30  Alan Modra  <amodra@gmail.com>

	elf symbol size
	This changes elf_obj_sy.size from being malloc'd to being on the notes
	obstack.  That means no code needs to free these expressions, which in
	turn means that the size expression can be shared when cloning
	symbols.  Nothing modifies the size expressions except when resolving.
	In all cases I could see, if the size changes the entire expression is
	replaced.

	The patch also extracts code from elf_copy_symbol_attributes into a
	separate function for use by riscv and aarch64.

		* config/obj-elf.c (elf_obj_symbol_clone_hook): Delete.
		(elf_copy_symbol_size): New function, extracted and modified from..
		(elf_copy_symbol_attributes): ..here.
		(obj_elf_size): Don't free size and use notes_alloc.
		(elf_frob_symbol): Don't free size.
		(elf_format_ops): Zero symbol_clone_hook.
		* config/obj-elf.h (elf_obj_symbol_clone_hook): Delete.
		(obj_symbol_clone_hook): Don't define.
		(elf_copy_symbol_size): Declare.
		* config/tc-aarch64.c (aarch64_elf_copy_symbol_attributes): Delete.
		* config/tc-aarch64.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as
		elf_copy_symbol_size.
		* config/tc-alpha.c (s_alpha_end): notes_alloc symbol size exp.
		* config/tc-ia64.c (dot_endp): Likewise.
		* config/tc-kvx.c (kvx_endp): Likewise.
		* config/tc-mips.c (s_mips_end): Likewise.
		* config/tc-riscv.c (riscv_elf_copy_symbol_attributes): Delete.
		* config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as
		elf_copy_symbol_size.

2025-05-30  Alan Modra  <amodra@gmail.com>

	gas symbol_remove
	If a symbol is at the start of the symbol chain then symbol_rootP
	points at the symbol and symbol->x->previous is NULL.  Testing either
	condition is sufficient, there is no need to test both.  Similarly for
	the symbol at the end of the symbol chain.

	I'm testing the previous/next pointer because it's most likely that
	the symbol is not at the start/finish of the chain and thus we need to
	use that pointer.

		* symbols.c (symbol_remove): Tidy list handling.
		(symbol_append, symbol_clone, symbol_insert): Likewise.

2025-05-30  Alan Modra  <amodra@gmail.com>

	Reduce rs_align_code memory for small alignments
	On x86, MAX_MEM_FOR_RS_ALIGN_CODE is 35, when the most common
	alignment is 2**3 or 2**4, where the max memory required for the
	alignment nops is 7 and 15 bytes respectively.  So there is some
	memory wasted since commit 83d94ae428b1.  It's not a large amount,
	especially considering that frag overhead on x86_46 is 144 bytes,
	but even so I'd rather not be blamed for increasing gas memory usage.

	So to reduce the memory we'd like to take the alignment into
	consideration when initialising an rs_align_code frag.  The only
	difficulty here is start_bundle making an rs_align_code frag with an
	alignment of zero initially, then later increasing the alignment.  We
	change that to use the bundle alignment when setting up the frag.  I
	think that is sufficient as bundle_align_p2 can't change in the middle
	of a start_bundle/finish_bundle sequence.

	I haven't modified any targets other than x86 in this patch.  Most
	won't benefit much due to using fairly small MAX_MEM_FOR_RS_ALIGN_CODE.

		* read.c (start_bundle): Create rs_align_code frag with
		bundle_align_p2 alignment, then set to zero alignment.
		(finish_bundle): Adjust comment.
		* frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Pass p2align and max
		to macro.
		* config/tc-i386.h (HANDLE_ALIGN): Assert that max_bytes is
		sufficient for nop padding.
		(max_mem_for_rs_align_code): New inline function.
		(MAX_MEM_FOR_RS_ALIGN_CODE): Use it.
		* config/tc-aarch64.h: Adjust MAX_MEM_FOR_RS_ALIGN_CODE.
		* config/tc-alpha.h: Likewise.
		* config/tc-arc.h: Likewise.
		* config/tc-arm.h: Likewise.
		* config/tc-epiphany.h: Likewise.
		* config/tc-frv.h: Likewise.
		* config/tc-ia64.h: Likewise.
		* config/tc-kvx.h: Likewise.
		* config/tc-loongarch.h: Likewise.
		* config/tc-m32r.h: Likewise.
		* config/tc-metag.h: Likewise.
		* config/tc-mips.h: Likewise.
		* config/tc-nds32.h: Likewise.
		* config/tc-ppc.h: Likewise.
		* config/tc-riscv.h: Likewise.
		* config/tc-rl78.h: Likewise.
		* config/tc-rx.h: Likewise.
		* config/tc-score.h: Likewise.
		* config/tc-sh.h: Likewise.
		* config/tc-sparc.h: Likewise.
		* config/tc-spu.h: Likewise.
		* config/tc-tilegx.h: Likewise.
		* config/tc-tilepro.h: Likewise.
		* config/tc-visium.h: Likewise.
		* config/tc-xtensa.h: Likewise.

2025-05-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-29  Guinevere Larsen  <guinevere@redhat.com>

	gdb: update corner case when canonicalizing riscv syscall names
	The script syscalls/riscv-canonicalize-syscall-gen.py has been recently
	introduced to help support record-full in riscv systems.  However, it
	was developed before commit 432eca4113d5748ad284a068873455f9962b44fe,
	which made the GDB enum more consistent, which forced the python script
	to have a corner case for the "gdb_old_mmap" case.

	Since the aforementioned commit has already been merged, we need to
	update the special case for the mmap syscall. A special case is still
	needed because the script would expect that the glibc sources call the
	syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which
	happens unfortunately.

	This commit doesn't change the .c file because it was already fixed by a
	different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was
	pushed as obvious to fix the build issues.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-29  Jorenar  <dev@jorenar.com>

	gdb/dap: fix completion request for empty strings
	When DAP completion requests receives empty string to complete,
	the script crashes due trying to access element -1 from list
	being a result of `text.splitlines()` (which for `text == ""`
	evaluates into empty list).

	This patch adds simple check if `text` is populated, and when it
	is not, skips transformations and assigns correct result directly.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb, gdbsupport: fix all `;;` instances
	I forgot to fix a `;;` typo when pushing a previous patch.  Fix it, and
	fix all the other instances I could find in the code base.

	Change-Id: I298f9ffb1a5157925076ef67b439579b1aeeaa2b

2025-05-29  Pedro Alves  <pedro@palves.net>

	Fix build when RUSAGE_THREAD is not available & add warning
	Building current GDB on Cygwin, fails like so:

	 /home/pedro/gdb/src/gdbsupport/run-time-clock.cc: In function ‘void get_run_time(user_cpu_time_clock::time_point&, system_cpu_time_clock::time_point&, run_time_scope ’:
	 /home/pedro/gdb/src/gdbsupport/run-time-clock.cc:52:13: error: ‘RUSAGE_THREAD’ was not declared in this scope; did you mean ‘SIGEV_THREAD’?
	    52 |       who = RUSAGE_THREAD;
	       |             ^~~~~~~~~~~~~
	       |             SIGEV_THREAD

	Cygwin does not implement RUSAGE_THREAD.  Googling around, I see
	Cygwin is not alone, other platforms don't support it either.  For
	example, here is someone suggesting an alternative for darwin/macos:
	https://stackoverflow.com/questions/5652463/equivalent-to-rusage-thread-darwin

	Fix this by falling back to process scope if thread scope can't be
	supported.  I chose this instead of returning zero usage or some other
	constant, because if gdb is built without threading support, then
	process-scope run time usage is the right info to return.

	But instead of falling back silently, print a warning (just once),
	like so:

	 (gdb) maint set per-command time on
	 ⚠️ warning: per-thread run time information not available on this platform

	... so that developers on other platforms at least have a hint
	upfront.

	This new warning also shows on platforms that don't have getrusage in
	the first place, but does not show if the build doesn't support
	threading at all.

	New tests are added to gdb.base/maint.exp, to expect the warning, and
	also to ensure other "mt per-command" sub commands don't trigger the
	new warning.

	Change-Id: Ie01b916b62f87006f855e31594a5ac7cf09e4c02
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/solib: make solib_ops::solib_create_inferior_hook optional
	The solib-target implementation of solib_create_inferior_hook is empty.
	Make that method / function pointer optional.

	Change-Id: Ie27b8d2c4fc6df74069ac8f88fbe69cf88a6662d
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: make solib_ops::in_dynsym_resolve_code optional
	Two solib ops implementations have dummy implementations for the
	in_dynsym_resolve_code callback.  Make it optional, to avoid this.

	Change-Id: I786776fb82ce1b96335a97713fbfe8074c84c00c
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: make implementation of solib_ops::open_symbol_file_object optional
	The only solib implementation that implements open_symbol_file_object is
	SVR4.  All others just return 0.  Make it optional, to avoid having
	these empty functions.

	Change-Id: I835197a73323d39231d071f9a9eaac2553f10726
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: boolify in_dynsym_resolve_code functions
	Change-Id: I66f5986e1a2452e3817f326d908b2e49f99e2fc6
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: move solist.h content to solib.h
	I don't think that the file solist.h is useful.  It would make sense to
	have `struct solib` in solib.h.  And then, all that would remain is
	`struct solib_ops` and some solib-related function declarations.  So,
	move it all to solib.h.

	Change-Id: I20ecf19787c378066f2c7a6a8a737c1db7c55d9a
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/progspace: rename progspace::so_list, make private
	Rename the field to m_solib_list, make it private.  Update users to go
	through the accessor.

	Change-Id: Id720c3a0b1781f4acf31e0dc626f1bd23ed8b39a
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix stale references to so_list
	Adjust some comments and function names that refer to the ancient
	so_list type.

	Update some other stale comments in solib-svr4.c at the same time.

	Change-Id: Ia42efa6554d0cc6abb4183b6bffc96c6358c5735
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: remove so_ prefix from so_name and so_original_name
	The `so_` prefix is unnecessary here, it's already clear by the fact
	that they are field of the solib type (and previously so_list).

	Change-Id: I2c6773afc121d7631901e602913ea8a068840d0b
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-28  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Note errors in process_skeletonless_type_units
	With a hello world a.out, and using the compiler flags from target board
	dwarf5-fission-debug-types:
	...
	$ gcc -gdwarf-5 -fdebug-types-section -gsplit-dwarf ~/data/hello.c
	...
	I run into:
	...
	$ gdb -q -batch a.out
	terminate called after throwing an instance of 'gdb_exception_error'
	...

	What happens is that an error is thrown due to invalid dwarf, but the error is
	not caught, causing gdb to terminate.

	In a way, this is a duplicate of PR32861, in the sense that we no longer run
	into this after:
	- applying the proposed patch (work around compiler bug), or
	- using gcc 9 or newer (compiler bug fixed).

	But in this case, the failure mode is worse than in PR32861.

	Fix this by catching the error in
	cooked_index_worker_debug_info::process_skeletonless_type_units.

	With the patch, we get instead:
	...
	$ gdb -q -batch a.out
	Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \
	  .debug_str.dwo section in CU at offset 0x0 [in module a.out]
	...

	While we're at it, absorb the common use of
	cooked_index_worker_result::note_error:
	...
	  try
	    {
	      ...
	    }
	  catch (gdb_exception &exc)
	    {
	      (...).note_error (std::move (exc));
	    }
	...
	into the method and rename it to catch_error, resulting in more compact code
	for the fix:
	...
	  (...).catch_error ([&] ()
	    {
	      ...
	    });
	...

	While we're at it, also use it in
	cooked_index_worker_debug_info::process_units which looks like it needs the
	same fix.

	Tested on x86_64-linux.

	PR symtab/32979
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32979

2025-05-28  Alan Modra  <amodra@gmail.com>

	elfedit: segv with --enable-x86-feature
		PR 33024
		PR 33025
		* elfedit.c (update_gnu_property): Sanity check program headers.

	Further rs_code_align support refinement
	Don't write the repeating nop pattern if it won't be used.

2025-05-28  Alexandra Hájková  <ahajkova@redhat.com>

	Call restore_original_signal_state after GDB forks.
	When I run GDB under Valgrind, GDB seems to segfault
	displaying:

	Fatal signal: Segmentation fault
	----- Backtrace -----
	0x2803f7 ???
	0x3c9696 ???
	0x3c9899 ???
	0x55f8fcf ???
	0x486c000 ???
	---------------------
	A fatal error internal to GDB has been detected, further
	debugging is not possible.  GDB will now terminate.

	This is a bug, please report it.  For instructions, see:
	<https://www.gnu.org/software/gdb/bugs/>.

	warning: linux_ptrace_test_ret_to_nx: PC 0x5821c09d is neither near return address 0x486c000 nor is the return instruction 0x4f8f4a!

	but then, acts like nothing happened and excutes normally. This is
	because it's the child from linux_ptrace_test_ret_to_nx that
	segfaults and parent GDB carries on normally. Restore the original
	signal states to not to print confusing backtrace. After restoring,
	only such warning is displayed:

	warning: linux_ptrace_test_ret_to_nx: WSTOPSIG 19 is neither SIGTRAP nor SIGSEGV!

2025-05-28  Alan Modra  <amodra@gmail.com>

	PR 33029 segv in dwarf2_finish with --gdwarf-5
	Specifying --gdwarf-5 with a source lacking a ".file 0" directive
	results in this segfault.

		* dwarf2dbg.c (out_debug_str): Use files[1] if files[0] is
		empty regardless of dwarf level.

2025-05-28  Alan Modra  <amodra@gmail.com>

	PR 33023 memory leak in objdump when specifying --endian
		* objdump.c (disassemble_data): Free modified xvec and replace
		original.

	PR 33021, buffer overflow in write_dwarf_eh_frame_hdr
		* elf-eh-frame.c (write_dwarf_eh_frame_hdr): Use size of
		contents, not section size, in bfd_set_section_contents call.

	PR 33018 segv in elf_x86_64_scan_relocs
		* elf64-x86-64.c (elf_x86_64_scan_relocs): Error on NULL howto.
		Use bfd_reloc_offset_in_range.

2025-05-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make objfile_has_full_symbols and objfile_has_symbols methods of objfile
	They seem like good candidates to become methods, just like
	objfile::has_partial_symbols.

	Change-Id: Ic6df83012629c1137708b8ceb327f9868d8abcb5
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-27  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Clarify -lbl option in gdb_test_multiple
	I was a bit confused about the -lbl option in gdb_test_multiple, and needed
	to read its implementation to determine that it would be useful for my
	needs.  Explicitly mention what the option does and why it's useful to
	hopefully help other developers.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-27  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Fix flakiness in gdb.base/default.exp
	The Linaro CI runs the GDB testsuite using the read1 tool, which
	significantly increases the time it takes DejaGNU to read inferior output.
	On top of that sometimes the test machine has higher than normal load,
	which causes tests to run even slower.

	Because gdb.base/default.exp tests some verbose commands such as "info
	set", it sometimes times out while waiting for the complete command
	output when running in the Linaro CI environment.

	Fix this problem by consuming each line of output from the most verbose
	commands with gdb_test_multiple's -lbl (line-by-line) option — which
	causes DejaGNU to reset the timeout after each match — and also by
	breaking up regular expressions that try to match more than 2000
	characters (the default Expect buffer size) in one go into multiple
	matches.

	Some tests use the same regular expression, so I created a procedure for
	them.  This is the case for "i" / "info", "info set" / "show", and "set
	print" tests.

	The tests for "show print" don't actually test their output, so this
	patch improves them by checking some lines of the output.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-27  Alan Modra  <amodra@gmail.com>

	ALPHA_R_OP_STORE
	In commit db4ab410dec3 I rewrote OP_STORE handling to support writing
	near the end of a section.  The rewrite had some bugs, fixed in commit
	3e02c4891dcb.  However I wasn't entirely happy with the code writing
	the bitfield:
	- it doesn't support 64-bit fields with a bit offset,
	- the code is duplicated and inelegant,
	- the stack ought to be popped whenever seeing one of these relocs,
	  even if the reloc can't be applied.
	This patch fixes all of the above.

	In addition, it is clear from the OP_STORE description in the ABI that
	a 64-bit field is encoded as 0 in r_size, so I've decoded that in
	alpha_ecoff_swap_reloc_in.  The aborts there are not appropriate as
	they can be triggered by user input (fuzzed object files).  Also,
	stack underflow wasn't checked in alpha_relocate_section.

		* coff-alpha.c (alpha_ecoff_swap_reloc_in): Replace aborts
		with asserts.  Decode ALPHA_R_OP_STORE r_size of zero.
		(write_bit_field): New function.
		(alpha_ecoff_get_relocated_section_contents): Use it.
		(alpha_relocate_section): Here too.  Catch stack underflow.

2025-05-26  Jens Remus  <jremus@linux.ibm.com>

	libsframe: handle SFrame FRE start/end IP offsets as unsigned
	The SFrame FRE start address (fre_start_addr) is defined as unsigned
	32-bit integer, as it is an offset from SFrame FDE function start
	address (sfde_func_start_address) and functions only grow upwards
	(towards higher addresses).

	The SFrame FRE start IP offset is a synonym to the SFrame FRE start
	address.  The SFrame FRE end IP offset is either the value of the
	subsequent FDE start address minus one, if that exists, or the FDE
	function size minus one otherwise.  Both should therefore be handled
	as unsigned 32-bit integer.

	In libsframe the "lookup PC" (pc) and SFrame FDE function start address
	(sfde_func_start_address) are both signed integers, as they are actually
	offsets from the SFrame section.  The unsigned FDE start/end IP offsets
	may therefore only be safely compared against the offset of the lookup
	PC from FDE function start address if the FDE function start address is
	lower or equal to the lookup PC, as this guarantees the offset to be
	always positive:

	Given:

	  lookup_pc = pc - sframe_addr

	  sfde_func_start_address = func_start_addr - sframe_addr

	If the FDE function start address is lower or equal than the lookup PC,
	which both are signed offsets from SFrame section, then the function
	start address is also lower or equal to the PC, which are both unsigned:

	  sfde_func_start_address <= lookup_pc
	  func_start_addr - sframe_addr <= pc - sframe_addr
	  func_start_addr <= pc

	With that the offset of the lookup PC from FDE function start address
	(lookup_pc - sfde_func_start_address) must always be positive, if
	FDE function start address is lower or equal to the lookup PC:

	  lookup_pc - sfde_func_start_address
	  = pc - sframe_addr - (func_start_addr - sframe_addr)
	  = pc - func_start_addr

	libsframe/
		* sframe.c (sframe_find_fre): Define and handle start_ip_offset
		and end_ip_offset as unsigned (same as FRE fre_start_addr).
		(sframe_fre_check_range_p): Likewise.  Define PC offset (from
		function start address) as unsigned.

2025-05-26  Jens Remus  <jremus@linux.ibm.com>

	libsframe: stop search for SFrame FRE if its start IP is greater than PC
	The SFrame FREs for an SFrame FDE are sorted on their start address.
	Therefore the linear search for a matching SFrame FRE can be stopped,
	if its start address is greater than the searched for PC.

	libsframe/
		* sframe.c (sframe_find_fre): Stop search if FRE's start IP is
		greater than PC.

2025-05-26  Jens Remus  <jremus@linux.ibm.com>

	libsframe: correct binary search for SFrame FDE
	sframe_get_funcdesc_with_addr_internal erroneously returns the last FDE,
	if its function start address is lower than the searched for address.

	Simplify the binary search for a SFrame FDE for a given address.  Only
	return an FDE, if the searched for address is within the bounds of the
	FDE function start address and function size.

	libsframe/
		* sframe.c (sframe_get_funcdesc_with_addr_internal): Correct
		binary search for SFrame FDE.

	libsframe/testsuite/
		* libsframe.find/plt-findfre-1.c: Add test for out of range
		PLT6.

2025-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: improve findfunc-1 testcase
	The testcase had usages of some magic numbers, making it difficult to
	keep up when format changes come along.

	libsframe/testsuite/
		* libsframe.find/findfunc-1.c: Restructure a bit.  Run test for two
		ways of placement of .sframe and .text.

2025-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: improve findfre-1 testcase
	The testcase had usages of some magic numbers, making it difficult to
	keep up when format changes come along.

	libsframe/testsuite/
		* libsframe.find/findfre-1.c: Restructure a bit.  Run test for two
		ways of placement of .sframe and .text.

2025-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fix issue finding FRE in PCMASK type SFrame FDEs
	SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK are used for repetitive code
	patterns, e.g., pltN entries.  For SFrame FDEs of type
	SFRAME_FDE_TYPE_PCMASK, sframe_fre_check_range_p erroneously tested the
	given PC instead of the masked PC offset from function start address.
	Therefore it only worked correctly by chance, e.g., if the function start
	address was aligned on the repetition block size.

	For regular SFrame FDEs the PC offset from function start address must
	be within a SFrame FRE's start IP offset and end IP offset.  For SFrame
	FDEs of type SFRAME_FDE_TYPE_PCMASK, the masked PC offset must be within
	that range.

	SFrame FRE start/end IP offsets are relative to the SFrame FDE function
	start address. For regular SFrame FDEs, the PC offset from function
	start address must be within a SFrame FRE's start IP offset and end IP
	offset.  For SFRAME_FDE_TYPE_PCMASK type FDEs, the masked PC offset must
	be within that range.

	Exercise the testcase for a variety of placements; without the fix some
	of these tests will fail.  Also, make the testcase itself easier to
	follow by adding appropriate vars where applicable.

	libsframe/
		* sframe.c (sframe_fre_check_range_p): Fix logic for
		SFRAME_FDE_TYPE_PCMASK type FDE.
	libsframe/testsuite/
		* libsframe.find/plt-findfre-1.c: Adjust the test for a variety
		of placements of .sframe and .plt.

	Co-Authored-by: Jens Remus <jremus@linux.ibm.com>

2025-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: handle .cfi_same_value
	Fix PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas

	As per documentation, .cfi_same_value indicates that the current value
	of register is the same like in the previous frame, i.e. no restoration
	needed.

	gas/
		* gen-sframe.c (sframe_xlate_do_same_value): New definition.
		(sframe_do_cfi_insn): Handle DW_CFA_same_value.
	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
		* gas/cfi-sframe/cfi-sframe-common-11.d: New test.
		* gas/cfi-sframe/cfi-sframe-common-11.s: New test.

2025-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb] Factor out compare_pointers
	Factor out compare_pointers, use it in compare_symbols and compare_msymbols,
	and add comments about unstable sorting result.

	Tested on x86_64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb] Partially stabilize sort in compare_{symbols,msymbols}
	In compare_symbols in gdb/linespec.c:
	...
	  uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace ();
	  uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace ();

	  if (uia < uib)
	    return true;
	  if (uia > uib)
	     return false;
	...
	we compare pointers to struct program_space, which gives unstable sorting
	results.

	The assumption is that this doesn't matter, but as PR32202 demonstrates,
	sometimes it does.

	While PR32202 is fixed elsewhere, it seems like a good idea to stabilize this
	comparison, because it comes at a small cost and possibly prevents
	hard-to-reproduce user-visible ordering issues.

	Fix this by comparing the program space IDs instead of the pointers.

	Likewise in compare_msymbols.

	Tested on x86_64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb/breakpoints] Stabilize info breakpoints output
	With test-case gdb.multi/pending-bp-del-inferior.exp, occasionally I run into:
	...
	(gdb) info breakpoints^M
	Num     Type           Disp Enb Address    What^M
	3       dprintf        keep y   <MULTIPLE> ^M
	        printf "in foo"^M
	3.1                         y   0x004004dc in foo at $c:21 inf 2^M
	3.2                         y   0x004004dc in foo at $c:21 inf 1^M
	(gdb) FAIL: $exp: bp_pending=false: info breakpoints before inferior removal
	...

	The FAIL happens because the test-case expects:
	- breakpoint location 3.1 to be in inferior 1, and
	- breakpoint location 3.2 to be in inferior 2
	but it's the other way around.

	I managed to reproduce this with a trigger patch in
	compare_symbols from gdb/linespec.c:
	...
	   uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace ();
	   uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace ();

	-  if (uia < uib)
	+  if (uia > uib)
	     return true;
	-  if (uia > uib)
	+  if (uia < uib)
	     return false;
	...

	The order enforced by compare_symbols shows up in the "info breakpoints"
	output because breakpoint::add_location doesn't enforce an ordering for equal
	addresses:
	...
	  auto ub = std::upper_bound (m_locations.begin (), m_locations.end (),
				      loc,
				      [] (const bp_location &left,
					  const bp_location &right)
					{ return left.address < right.address; });
	   m_locations.insert (ub, loc);
	...

	Fix this by using new function bp_location_is_less_than
	(forwarding to bp_location_ptr_is_less_than) in breakpoint::add_location.

	Tested on x86_64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

	PR gdb/32202
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32202

2025-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb/breakpoints] Rename bp_location_is_less_than to bp_location_ptr_is_less_than
	In breakpoint.c, we have:
	...
	/* A comparison function for bp_location AP and BP being interfaced to
	   std::sort.  Sort elements primarily by their ADDRESS (no matter what
	   bl_address_is_meaningful says), secondarily by ordering first
	   permanent elements and tertiarily just ensuring the array is sorted
	   stable way despite std::sort being an unstable algorithm.  */

	static int
	bp_location_is_less_than (const bp_location *a, const bp_location *b)
	...

	There are few problems here:
	- the return type is int.  While std::sort allows this, because int is
	  convertible to bool, it's clearer to use bool directly,
	- it's not abundantly clear from either function name or comment that we can
	  use this to sort std::vector<bp_location *> but not
	  std::vector<bp_location>, and
	- the comment mentions AP and BP, but there are no such parameters.

	Fix this by:
	- changing the return type to bool,
	- renaming the function to bp_location_ptr_is_less_than and mentioning
	  std::vector<bp_location *> in the comment, and
	- updating the comment to use the correct parameter names.

	Tested on x86_64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-26  Janne Ramstedt  <janne.ramstedt@aniway.fi>

	alpha, bfd: Fixes for ALPHA_R_OP_STORE
	ALPHA_R_OP_STORE copies one byte too many and also will cause out of
	range error when it tries to copy from the end of section.  Since
	"endbyte" is already rounded to next full byte, there is enough bits
	to copy and the additional "+ 1" is erroneous in bytes count.  I also
	believe size is incorrectly decreased.

2025-05-26  Markus Metzger  <markus.t.metzger@intel.com>

	gdb, btrace: remove record_btrace_target::supports_*()
	Let's not introduce support for breakpoint types the target beneath does
	not support, even though we could while replaying.

	Otherwise, users may set breakpoints during replay that then couldn't be
	inserted into the target when switching back to recording.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-26  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: overflow and underflow checks for R_LARCH_32_PCREL
	Relocation overflows can silently write incorrect value to
	the file, so overflow checks are added to avoid this.

2025-05-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-svr4: check that solib is SVR4 in tls_maybe_fill_slot and tls_maybe_erase_slot
	Functions tls_maybe_fill_slot and tls_maybe_erase_slot blindly assume
	that the passe solibs come from solib-svr4.  This is not always the
	case, because they are called even on the systems where the solib
	implementation isn't solib-svr4.  Add some checks to return early in
	that case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32990
	Change-Id: I0a281e1f4826aa1914460c2213f0fae1bdc9af7c
	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use local addrmap_mutable in addrmap selftest
	There is no need to allocate the addrmap_mutable on the heap.

	Change-Id: Ia6ec17101a44ae5eaffbf3382c9639414ce5343e
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: turn CHECK_ADDRMAP_FIND into a function
	Replace the macro with a function.  I don't see a need to use a macro
	here, a function is easier to read.

	Change-Id: I22370040cb546470498d64939b246b03700af398
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-24  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix unused var in lookup_dwo_unit_in_dwp
	On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
	...
	gdb/dwarf2/read.c: In function ‘dwo_unit* lookup_dwo_unit_in_dwp()’:
	gdb/dwarf2/read.c:7403:22: error: unused variable ‘inserted’ \
	  [-Werror=unused-variable]
	    auto [it, inserted] = dwo_unit_set.emplace (std::move (dwo_unit));
	                      ^
	...

	Fix this by dropping the unused variable.

	Tested on x86_64-linux, by completing a build.

2025-05-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: guard <mutex> include with CXX_STD_THREAD
	Change-Id: I4335fbfdabe49778fe37b08689eec59be94c424b

2025-05-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/NEWS: minor white space fix
	Spotted a small white space mistake in the NEWS file.  Fixed.

2025-05-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: include <mutex> in dwarf2/read.h
	The buildbot pointed out this compilation failure on AlmaLinux, with g++
	8.5.0, which is not seen on more recent systems:

	     CXX    gdbtypes.o
	    In file included from ../../binutils-gdb/gdb/gdbtypes.c:39:
	    ../../binutils-gdb/gdb/dwarf2/read.h:639:8: error: ‘mutex’ in namespace ‘std’ does not name a type
	       std::mutex dwo_files_lock;
	            ^~~~~
	    ../../binutils-gdb/gdb/dwarf2/read.h:639:3: note: ‘std::mutex’ is defined in header ‘<mutex>’; did you forget to ‘#include <mutex>’?
	    ../../binutils-gdb/gdb/dwarf2/read.h:35:1:
	    +#include <mutex>

	    ../../binutils-gdb/gdb/dwarf2/read.h:639:3:
	       std::mutex dwo_files_lock;
	       ^~~

	Fix it by including <mutex> in dwarf2/read.h.

	Change-Id: Iba334a3dad217c86841a5e804d0f386876f5ff2f

2025-05-23  Tom de Vries  <tdevries@suse.de>

	[gdb] Make make-init-c more robust
	In commit 2711e4754fc ("Ensure cooked_index_entry self-tests are run"), we
	rewrite the function definition of _initialize_dwarf2_entry into a normal
	form that allows the make-init-c script to detect it:
	...
	 void _initialize_dwarf2_entry ();
	-void _initialize_dwarf2_entry ()
	+void
	+_initialize_dwarf2_entry ()
	...

	Update make-init-c to also detect the "void _initialize_dwarf2_entry ()"
	variant.

	Tested on x86_64-linux, by reverting commit 2711e4754fc, rebuilding and
	checking that build/gdb/init.c doesn't change.

2025-05-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/fission-dw-form-strx.exp
	Add a dwarf assembly test-case using a DW_FORM_strx in a .dwo file.

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: split dwo_lock in more granular locks
	The dwo_lock mutex is used to synchronize access to some dwo/dwp-related
	data structures, such as dwarf2_per_bfd::dwo_files and
	dwp_file::loaded_{cus,tus}.  Right now the scope of the lock is kind of
	coarse.  It is taken in the top-level lookup_dwo_unit function, and held
	while the thread:

	 - looks up an existing dwo_file in the per-bfd hash table for the given
	   id/signature
	 - if there's no existing dwo_file, attempt to find a .dwo file, open
	   it, build the list of units it contains
	 - if a new dwo_file was created, insert it in the per-bfd hash table
	 - look up the desired unit in the dwo_file

	And something similar for the dwp code path.  This means that two
	indexing thread can't read in two dwo files simultaneously.  This isn't
	ideal in terms of parallelism.

	This patch breaks this lock into 3 more fine grained locks:

	 - one lock to access dwarf2_per_bfd::dwo_files
	 - one lock to access dwp_file::loaded_{cus,tus}
	 - one lock in try_open_dwop_file, where we do two operations that
	   aren't thread safe (bfd_check_format and gdb_bfd_record_inclusion)

	Unfortunately I don't see a clear speedup on my computer with 8 threads.
	But the change shouldn't hurt, in theory, and hopefully this can be a
	piece that helps in making GDB scale better on machines with many cores
	(if we ever bump the max number of worker threads).

	This patch uses "double-checked locking" to avoid holding the lock(s)
	for the whole duration of reading in dwo files.  The idea is, when
	looking up a dwo with a given name:

	 - with the lock held, check for an existing dwo_file with that name in
	   dwarf2_per_bfd::dwo_files, if found return it
	 - if not found, drop the lock, load the dwo file and create a dwo_file
	   describing it
	 - with the lock held, attempt to insert the new dwo_file in
	   dwarf2_per_bfd::dwo_files.  If an entry exists, it means another
	   thread simultaneously created an equivalent dwo_file, but won the
	   race.  Drop the new dwo_file and use the existing one.  The new
	   dwo_file is automatically deleted, because it is help by a unique_ptr
	   and the insertion into the unordered_set fails.

	Note that it shouldn't normally happen for two threads to look up a dwo
	file with the same name, since different units will point to different
	dwo files.  But it were to happen, we handle it.  This way of doing
	things allows two threads to read in two different dwo files
	simulatenously, which in theory should help get better parallelism.  The
	same technique is used for dwp_file::loaded_{cus,tus}.

	I have some local CI jobs that run the fission and fission-dwp boards,
	and I haven't seen regressions.  In addition to the regular testing, I
	ran a few tests using those boards on a ThreadSanitizer build of GDB.

	Change-Id: I625c98b0aa97b47d5ee59fe22a137ad0eafc8c25
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2025-05-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: allocate DWP dwarf2_section_info with new
	For the same reason as explained in the previous patch (allocations on
	obstacks aren't thread-safe), change the allocation of
	dwarf2_section_info object for dwo files within dwp files to use "new".

	The dwo_file::section object is not always owned by the dwo_file, so
	introduce a new "dwo_file::section_holder" object that is only set when
	the dwo_file owns the dwarf2_section_info.

	Change-Id: I74c4608573c7a435bf3dadb83f96a805d21798a2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: allocate dwo_unit with new
	The following patch reduces the duration where the dwo_lock mutex is
	taken.  One operation that is not thread safe is the allocation on
	dwo_units on the per_bfd obstack:

	    dwo_unit *dwo_unit = OBSTACK_ZALLOC (&per_bfd->obstack, struct dwo_unit);

	We could take the lock around this allocation, but I think it's just
	easier to avoid the problem by having the dwo_unit objects allocated
	with "new".

	Change-Id: Ida04f905cb7941a8826e6078ed25dbcf57674090
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-23  Tom Tromey  <tom@tromey.com>

	Handle an argument-less operator in the C++ name parser
	While debugging a new failure in my long-suffering "search-in-psyms"
	series, I found that the C++ name canonicalizer did not handle a case
	like "some_name::operator new []".  This should remove the space,
	resulting in "some_name::operator new[]" -- but does not.

	This happens because the parser requires an operator to be followed by
	argument types.  That is, it's expected.

	However, it seems to me that we do want to be able to canonicalize a
	name like this.  It will appear in the DWARF as a DW_AT_name, and
	furthermore it could be entered by the user.

	This patch fixes this problem by changing the grammar to supply the
	"()" itself, then removing the trailing "()" when changing to string
	form (in the functions that matter).

	This isn't ideal -- it might miss a very obscure case involving the
	gdb extension of providing fully-qualified names for function-local
	statics -- but it improves the situation at least.

	It's possible a better solution might be to rewrite the name
	canonicalizer.  I was wondering if this could perhaps be done without
	reference to the grammar -- just by examining the tokens.  However,
	that's much more involved.

	Let me know what you think.

	Regression tested on x86-64 Fedora 40.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32939
	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-05-23  Nick Alcock  <nick.alcock@oracle.com>

	libctf: archive, open: when opening, always set errp to something
	ctf_arc_import_parent, called by the cached-opening machinery used by
	ctf_archive_next and archive-wide lookup functions like
	ctf_arc_lookup_symbol, has an err-pointer parameter like all other opening
	functions.  Unfortunately it unconditionally initializes it whenever
	provided, even if there was no error, which can lead to its being
	initialized to an uninitialized value.  This is not technically an
	API-contract violation, since we don't define what happens to the error
	value except when an error happens, but it is still unpleasant.

	Initialize it only when there is an actual error, so we never initialize it
	to an uninitialized value.

	While we're at it, improve all the opening pathways: on success, set errp to
	0, rather than leaving it what it was, reducing the likelihood of
	uninitialized error param returns in callers too.  (This is inconsistent
	with the treatment of ctf_errno(), but the err value being a parameter
	passed in from outside makes the divergence acceptable: in open functions,
	you're never going to be overwriting some old error value someone might want
	to keep around across multiple calls, some of which are successful and some
	of which are not.)

	Soup up existing tests to verify all this.

	Thanks to Bruce McCulloch for the original patch, and Stephen Brennan for
	the report.

	libctf/
		PR libctf/32903
		* ctf-archive.c (ctf_arc_open_internal): Zero errp on success.
		(ctf_dict_open_sections): Zero errp at the start.
		(ctf_arc_import_parent): Intialize err.
		* ctf-open.c (ctf_bufopen): Zero errp at the start.
		* testsuite/libctf-lookup/add-to-opened.c: Make sure one-element
		archive opens update errp.
		* testsuite/libctf-writable/ctf-compressed.c: Make sure real archive
		opens update errp.

2025-05-23  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add support for RISC-V Profiles 23.
	This patch adds support for RISC-V RVA23 and RVB23 Profiles[1].

	[1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified

	bfd/ChangeLog:

		* elfxx-riscv.c: New profiles.

	gas/ChangeLog:

		* testsuite/gas/riscv/attribute-19.d: New test.
		* testsuite/gas/riscv/attribute-20.d: New test.

2025-05-23  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add support for RISC-V Profiles 20/22.
	This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
	enabling developers to utilize these profiles through the -march option.

	[1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0

	bfd/ChangeLog:

		* elfxx-riscv.c (struct riscv_profiles): New struct.
		(riscv_parse_extensions): New argument.
		(riscv_find_profiles): New checking function.
		(riscv_parse_subset): Add Profiles handler.

	gas/ChangeLog:

		* NEWS: Add RISC-V Profiles.
		* doc/as.texi: Update -march input type.
		* doc/c-riscv.texi: Ditto.
		* testsuite/gas/riscv/option-arch-fail.l: Modify hint info.
		* testsuite/gas/riscv/attribute-17.d: New test.
		* testsuite/gas/riscv/attribute-18.d: New test.
		* testsuite/gas/riscv/march-fail-rvi20u64v.d: New test.
		* testsuite/gas/riscv/march-fail-rvi20u64v.l: New test.

2025-05-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-23  QBos07  <qubos@outlook.de>

	PR 3298 Fix SuperH relaxation overriding wrong intruction
	when doing load store switching it wrongly adjusts the address of the
	R_SH_USES reloc and not the actual offset from that instruction. This is
	an issue if the pc-relative function call relaxation gets done in a
	later pass wich will result in overriding the wrong instruction.

2025-05-22  Alan Modra  <amodra@gmail.com>

	rs_fill_nop and md_generate_nops
	Make rs_fill_nop behave like rs_fill in using a repeat count
	(fr_offset) to emit fr_var length repeated nop patterns.  Besides
	being more elegant, this reduces memory required for large .nops
	directives.

		* as.h (rs_fill_nop): Update comment.
		* config/tc-i386.c (i386_generate_nops): Handle rs_fill_nop as
		for rs_align_code.
		* config/tc-i386.h (MAX_MEM_FOR_RS_SPACE_NOP): Define.
		* listing.c (calc_hex): Handle rs_fill_nop as for rs_fill.
		* read.c (MAX_MEM_FOR_RS_SPACE_NOP): Define.
		(s_nops): Use MAX_MEM_FOR_RS_SPACE_NOP setting up frag.
		* write.c (write_contents): Call md_generate_nops for rs_fill_nop
		before the fr_fix part is written, so that rs_fill_nop can be
		handled as for rs_fill.

2025-05-22  Alan Modra  <amodra@gmail.com>

	Re: gas .align limit
	Now that rs_align_code has been corrected for all targets, put the
	.align limit back to bits_per_address-1.  Also fix a comment.

		* frags.h (fr_var): Correct comment.
		* read.c (TC_ALIGN_LIMIT): Revert commit ff4c03516c change.

2025-05-22  Alan Modra  <amodra@gmail.com>

	tidy x86 HANDLE_ALIGN
	Reduce memory requirement for .align in code.

	I've changed some of the tests to use "clc" rather than "nop", so that
	code emitted by .p2align can be clearly seen.

		* config/tc-i386.c (i386_output_nops): Merge into..
		(i386_generate_nops): ..here.  Put shorter nop first.  For
		rs_align_code make use of the fact that the last fr_var bytes
		are output repeatedly rather than repeating them here.
		* config/tc-i386.h (HANDLE_ALIGN): Don't test max_bytes.
		(MAX_MEM_FOR_RS_ALIGN_CODE): Update.
		* testsuite/gas/i386/nops-1.s,
		* testsuite/gas/i386/nops-2.s,
		* testsuite/gas/i386/nops-3.s,
		* testsuite/gas/i386/nops-4.s,
		* testsuite/gas/i386/nops16-1.s: Replace "nop" with "clc".
		* testsuite/gas/i386/align-branch-6.d,
		* testsuite/gas/i386/nop-1-suffix.d,
		* testsuite/gas/i386/nop-1.d,
		* testsuite/gas/i386/nop-1.l,
		* testsuite/gas/i386/nop-2.d,
		* testsuite/gas/i386/nop-4.d,
		* testsuite/gas/i386/nop-5.d,
		* testsuite/gas/i386/nops-1-core2.d,
		* testsuite/gas/i386/nops-1.d,
		* testsuite/gas/i386/nops-10.d,
		* testsuite/gas/i386/nops-2.d,
		* testsuite/gas/i386/nops-3.d,
		* testsuite/gas/i386/nops-4.d,
		* testsuite/gas/i386/nops-4a-i686.d,
		* testsuite/gas/i386/nops-5.d,
		* testsuite/gas/i386/nops-6.d,
		* testsuite/gas/i386/nops-7.d,
		* testsuite/gas/i386/nops-9.d,
		* testsuite/gas/i386/nops16-1.d,
		* testsuite/gas/i386/x86-64-align-branch-6.d,
		* testsuite/gas/i386/x86-64-nop-1.d,
		* testsuite/gas/i386/x86-64-nop-5.d,
		* testsuite/gas/i386/x86-64-nops-1-core2.d,
		* testsuite/gas/i386/x86-64-nops-1-pentium.d,
		* testsuite/gas/i386/x86-64-nops-1.d,
		* testsuite/gas/i386/x86-64-nops-2.d,
		* testsuite/gas/i386/x86-64-nops-3.d,
		* testsuite/gas/i386/x86-64-nops-4-core2.d,
		* testsuite/gas/i386/x86-64-nops-4.d,
		* testsuite/gas/i386/x86-64-nops-5.d,
		* testsuite/gas/i386/x86-64-nops-6.d,
		* testsuite/gas/i386/x86-64-nops-7.d: Adjust to suit.

2025-05-22  Alan Modra  <amodra@gmail.com>

	tidy target HANDLE_ALIGN
	avr, kvx, metag, mn10300, nds32, v850, visium, and wasm32 targets
	defined HANDLE_ALIGN without defining MAX_MEM_FOR_RS_ALIGN_CODE.  This
	can result in a rather large chunk of memory being allocated.  Fix
	that by a combination of changing the default allocation to one byte
	and/or defining a target MAX_MEM_FOR_RS_ALIGN_CODE.

	arm wanted to write out the entire set of nops, and limited allowed
	code alignment to 64 bytes to prevent large memory allocations.
	Fix that by making use of the fact that rs_align_code frags repeat
	fr_var bytes at fr_literal + fr_fix to fill out the required area.
	Fix metag, nds32 and kvx too, which it seems copied either arm or x86
	in similarly not making use of repeating patterns.

	It's worth mentioning that my tidy to kvx changed the order of nop
	bundles, placing a short bundle first rather than last.

	epiphany was totally broken in that uninitialised data was written out
	for any alignment requiring more than three bytes of fill.

	ppc created a new frag to handle a branch over a large number of nops.
	This saves 4 bytes per rs_align_code frag, and most times the branch
	isn't used so it is generally a win for memory usage, but I figured
	the extra code complexity wasn't worth it.  So that code of mine goes.
	visium copied the same scheme, so that goes too.

	This leaves x86 as the only target making large allocations for
	alignment frags.

		* frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Default to 1.
		* config/tc-aarch64.c (aarch64_handle_align): Remove always true
		condition.
		* config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Move to be
		adjacent to HANDLE_ALIGN define.
		* config/tc-arm.c (arm_handle_align): Allow alignment of more
		than MAX_MEM_FOR_RS_ALIGN_CODE bytes.  Just write one repeat
		of nop pattern to frag.
		(arm_frag_align_code): Delete function.
		* config/tc-arm.h (MAX_MEM_ALIGNMENT_BYTES): Don't define.
		(MAX_MEM_FOR_RS_ALIGN_CODE): Set to 7.
		(md_do_align): Don't define.
		(arm_frag_align_code): Don't declare.
		* config/tc-epiphany.c (epiphany_handle_align): Correct frag
		so that nop_pattern repeats rather than random data.
		* config/tc-epiphany.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
		* config/tc-kvx.c (kvx_make_nops): Merge into..
		(kvx_handle_align): ..here.  Put short nop bundle first,
		followed by repeated full nop bundle.
		* config/tc-kvx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
		* config/tc-m32c.h (HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE):
		Don't define.
		* config/tc-metag.c (metag_handle_align): Just write one
		repeat of nop pattern to frag.
		* config/tc-metag.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
		* config/tc-nds32.c (nds32_handle_align): Just write one
		repeat of nop pattern to frag.
		* config/tc-nds32.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
		* config/tc-ppc.c (ppc_handle_align): Don't make a new frag
		for branch.
		* config/tc-ppc.h (MAX_MEM_FOR_RS_ALIGN_CODE): Increase to 8.
		* config/tc-visium.c (visium_handle_align): Don't make a new
		frag for branch.
		* config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define.
		* config/tc-wasm32.h (HANDLE_ALIGN): Don't define.
		* testsuite/gas/epiphany/nop.d,
		* testsuite/gas/epiphany/nop.s: New test.
		* testsuite/gas/epiphany/allinsn.exp: Run it.
		* testsuite/gas/kvx/nop-align.d: Adjust.

2025-05-22  Andrew Burgess  <aburgess@redhat.com>

	gdb: reorder checks in validate_exec_file
	While reviewing another patch I was briefly confused by a call to
	target_pid_to_exec_file coming from validate_exec_file while attaching
	to a process when I had not previously set an executable.

	The current order of actions in validate_exec_file is:

	  1. Get name of current executable.
	  2. Get name of executable from the current inferior.
	  3. If either of (1) or (2) return NULL, then there's nothing to
	     check, early return.

	I think it would be cleaner if we instead did this:

	  1. Get name of current executable.
	  3. If (1) returned NULL then there's nothing to check, early return.
	  3. Get name of executable from the current inferior.
	  4. If (3) returned NULL then there's nothing to check, early return.

	This does mean there's an extra step, but I don't think the code is
	any more complex really, and we now avoid trying to extract the name
	of the executable from the current inferior unless we really need it.
	This avoids the target_pid_to_exec_file call that I was seeing, which
	for remote targets does avoid a packet round trip (not that I'm
	selling this as an "optimisation", just noting the change).

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-22  Tom Tromey  <tromey@adacore.com>

	Ensure cooked_index_entry self-tests are run
	While looking at code coverage for gdb, I noticed that the
	cooked_index_entry self-tests were not run.  I tracked this down to a
	formatting error in cooked-index-entry.c.

	I suspect it might be better to use a macro to define these
	initialization functions.  That would probably remove the possibility
	for this kind of error.

2025-05-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix 32892 source line level information not available with "-g -O2"
	gprofng did not read the .debug_rnglists section for dwarf-5.
	Another problem was that gprofng ignored DW_AT_abstract_origin
	As a result, gprofng skiped Dwarf for all functions declared as:
	   <1><e18b>: Abbrev Number: 43 (DW_TAG_subprogram)
	      <e18c>   DW_AT_abstract_origin: <0xe168>
	      <e190>   DW_AT_linkage_name:  _ZN10Bool_ArrayD2Ev

	gprofng/ChangeLog
	2025-05-19  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32892
		* src/Dwarf.cc: Read the .debug_rnglists section.
		Support DW_AT_abstract_origin.
		* src/Dwarf.h: Likewise.
		* src/DwarfLib.cc: Likewise.
		* src/DwarfLib.h: Likewise.
		* src/LoadObject.cc (dump_functions): Print mangled names for aliases.
		* src/Stabs.cc (fixSymtabAlias): Set 'alias' correctly.
		* src/Symbol.cc (find_symbols): Add argument where to collect symbols.
		* src/Symbol.h: Likewise.

2025-05-22  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add support for Smcdeleg and Ssccfg extensions.
	This patch rebases the original patch from Nelson's implement[1].

	Added new extension Smcdeleg and Ssccfg with a new CSR, scountinhibit.[2]

	Co-Authored-By: Nelson Chu  <nelson@rivosinc.com>
	Co-Authored-By: Jiawei Chen <jiawei@iscas.ac.cn>

	[1] https://patchwork.sourceware.org/project/binutils/patch/20240620045359.47513-1-nelson@rivosinc.com/
	[2] https://github.com/riscvarchive/riscv-smcdeleg-ssccfg/releases/tag/v1.0.0

	bfd/ChangeLog:

		* elfxx-riscv.c: New extensions.

	gas/ChangeLog:

		* NEWS: Mention new extensions.
		* config/tc-riscv.c (enum riscv_csr_class): New CSR class.
		(riscv_csr_address): Add support for Ssccfg.
		* testsuite/gas/riscv/csr-version-1p10.d: New test for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p10.l: New warning for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p11.d: New test for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p11.l: New warning for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p12.d: New test for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p12.l: New warning for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p13.d: New test for Ssccfg CSR.
		* testsuite/gas/riscv/csr-version-1p13.l: New warning for Ssccfg CSR.
		* testsuite/gas/riscv/csr.s: New Ssccfg CSR.
		* testsuite/gas/riscv/imply.d: New imply check.
		* testsuite/gas/riscv/imply.s: New implies.
		* testsuite/gas/riscv/march-help.l: New helping info.

	include/ChangeLog:

	        * opcode/riscv-opc.h (CSR_SCOUNTINHIBIT): New CSR address.
	        (DECLARE_CSR): Add Ssccfg CSR.

2025-05-22  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Warning about incorrect 3rd argument of .align
	344b1e0f5f7 Introduced range-check 3rd argument of .align, incorrect
	value are not converted silently. added warning message to fix regression.

2025-05-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-22  Alan Modra  <amodra@gmail.com>

	ubsan: integer overflow in tc-i386.c:offset_in_range
	or $9223372036854775808,%eax
	runtime error: negation of -9223372036854775808 cannot be represented
	in type 'offsetT' (aka 'long'); cast to an unsigned type to negate
	this value to itself

		* config/tc-i386.c (offset_in_range): Avoid signed overflow.

2025-05-21  Tom Tromey  <tromey@adacore.com>

	Minor spelling fixes in gdb directory
	I ran codespell on the gdb directory and fixed a number of minor
	problems.  In a couple cases I replaced a "gdb spelling" (e.g.,
	"readin") with an English one ("reading") where it seemed harmless.

	I also added "Synopsis" as an accepted spelling.

	gdb is nowhere near codespell-clean.

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-05-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh
	I forgot to run test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp with
	make-check-all.sh, and consequently failed to notice that it fails with for
	instance target board fission-dwp.

	The test-case does:
	...
	source $srcdir/$subdir/dw-form-strx.exp.tcl
	...
	and in that tcl file, prepare_for_testing fails, so a -1 is returned, but
	that is ignored by the source command.

	Fix this by using require, but rather that testing the result of the source
	command, communicate success by setting a global variable
	prepare_for_testing_done.

	Likewise in gdb.dwarf2/dw-form-strx.exp.

	Also, the test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp fails for target
	board readnow, because the DWARF error occurs during a different command than
	expected.

	Fix this by just skipping the test-case in that case.

	Tested on x86_64-linux.

	Reported-by: Simon Marchi <simark@simark.ca>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.debuginfod codespell-clean
	Make gdb.debuginfod codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.guile codespell-clean
	Make gdb.guile codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.mi codespell-clean
	Make gdb.mi codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.opt codespell-clean
	Make gdb.opt codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.pascal codespell-clean
	Make gdb.pascal codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.reverse codespell-clean
	Make gdb.reverse codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.rocm codespell-clean
	Make gdb.rocm codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.stabs codespell-clean
	Make gdb.stabs codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.xml codespell-clean
	Make gdb.xml codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.tui codespell-clean
	Make gdb.tui codespell-clean and add the dir to the pre-commit
	configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdbsever typo
	I noticed a typo in the testsuite, twice: gdbsever.  Fix these.

	Codespell doesn't detect it, so add a new file
	gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver
	entry, and update gdb/contrib/setup.cfg to use it.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Tom de Vries  <tdevries@suse.de>

	[pre-commit] Add codespell-clean gdb/testsuite dirs
	The following gdb/testsuite subdirs are codespell-clean:
	...
	$ for d in gdb/testsuite/gdb.*; do \
	      echo -n "$d:"; \
	      codespell --config ./gdb/contrib/setup.cfg $d \
	          | wc -l; \
	  done 2>&1 \
	  | grep :0
	gdb/testsuite/gdb.ctf:0
	gdb/testsuite/gdb.dap:0
	gdb/testsuite/gdb.gdb:0
	gdb/testsuite/gdb.go:0
	gdb/testsuite/gdb.modula2:0
	gdb/testsuite/gdb.objc:0
	gdb/testsuite/gdb.opencl:0
	gdb/testsuite/gdb.perf:0
	gdb/testsuite/gdb.replay:0
	gdb/testsuite/gdb.server:0
	gdb/testsuite/gdb.testsuite:0
	...

	Add them to the pre-commit configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-20  Andreas Schwab  <schwab@suse.de>

	libiberty: sync with gcc
	Import the following commits from GCC as of r16-614-g9d039eff453f77:
		31dd621796f libiberty: add ldirname function
		f3d07779fdb libiberty: Append <libgen.h> to AC_CHECK_DECLS [PR119218].
		90183362524 libiberty, gcc: Add memrchr to libiberty and use it [PR119283].
		43717ee9064 libiberty: Fix off-by-one when collecting range expression

2025-05-20  Alan Modra  <amodra@gmail.com>

	ubsan: undefined shift in loongarch_elf_add_sub_reloc_uleb128
	An oss-fuzz testcase found:
	runtime error: shift exponent 140 is too large for 32-bit type 'int'
	OK, that's just a completely silly uleb, but we ought to be able to
	handle 64 bits here.

		* elfxx-loongarch.c (loongarch_elf_add_sub_reloc_uleb128): Formatting.
		Don't left shift int.  Avoid shifts larger than bits in a bfd_vma.

2025-05-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-19  Dimitar Dimitrov  <dimitar@dinux.eu>

	sim: testsuite: Fix build with host GCC15
	Simulator testsuite build started failing with host GCC-15:

	  bits-tst.c:323:1: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
	  bits-tst.c: In function ‘main’:
	  bits-tst.c:323:1: error: old-style function definition [-Werror=old-style-definition]

	Fix by including string.h to get the required prototypes, and changing
	main's declaration to modern C.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-19  Alan Modra  <amodra@gmail.com>

	ubsan: integer overflow in s_fill
	Silence ubsan warning.  We don't worry about wrap-around in most
	places that adjust abs_section_offset, so don't fuss over an overflow
	in the multiplication here.

		* read.c (s_fill): Replace "long" vars with offsetT and valueT.
		Avoid signed overflow calculating abs_section_offset.

2025-05-19  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add implication from the XTheadZvamo extension
	T-Head/XuanTie's vector extension documentation states that their vector
	extensions are based on the standard vector extension draft,
	version 0.7.1.

	In that draft, it is rare to see dependencies between extensions as
	in the ratified version ... except: "Zvamo" -> "Zaamo".

	cf. <https://github.com/riscvarchive/riscv-v-spec/releases/tag/0.7.1>

	> If vector AMO instructions are supported, then the scalar Zaamo
	> instructions (atomic operations from the standard A extension)
	> must be present.

	Note that using the words like "imply" or "depend" for extensions
	weren't a common practice to represent dependencies between extensions
	at the time the documentation was created.

	The "Zaamo" was not ratified as an extension at the time but this is a
	subset of the "A" extension and defines scalar AMO operations (while
	"Zvamo" -- NOT in the ratified specification -- defines vector AMO ops).

	The important part is that the T-Head/XuanTie's documentation just
	states that the "Zvamo" (draft) extension is renamed to "XTheadZvamo".
	It means, this implication should have been preserved in some way.

	> The extension Zvamo is renamed to XTheadZvamo.

	cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add implication
		"XTheadZvamo" -> "Zaamo".

	gas/ChangeLog:

		* testsuite/gas/riscv/imply.s: Add "XTheadZvamo" implication.
		* testsuite/gas/riscv/imply.d: Ditto.

2025-05-19  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add implicit dependency to the XTheadVector extension
	While this dependency is not directly stated in the documentation,
	the XTheadVector extension cannot work without the Zicsr extension
	(the documentation does not specify CSR access instruction subset
	either as in the Zkr extension or the seed CSR section in the manual).

	Also, making an implication to the Zicsr extension is in parity with
	the ratified vector extensions (in GNU Binutils, the Zve32x extension --
	a dependency of V -- depends on the Zvl32b and Zicsr extensions).

	This commit adds this implicit dependency.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add implicit
		dependency "XTheadVector" -> "Zicsr".

	gas/ChangeLog:

		* testsuite/gas/riscv/imply.s: Add implicit "XTheadVector"
		dependency to the "Zicsr" extension.
		* testsuite/gas/riscv/imply.d: Ditto.

2025-05-19  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Wider conflicts with the XTheadVector extension
	T-Head/XuanTie's "XTheadVector" is based on a draft version of the now
	standard vector extensions and it conflicts with not just the "V"
	extension but all of its subsets.

	This commit makes "XTheadVector" conflict with the "Zve32x" extension,
	which is the smallest subset of the standard vector extensions.  Still,
	a reference to "V" is preserved in the error message
	as the documentation suggests:

	> Therefore, the XTheadVector extension and the V extension are
	> in conflict.

	cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc>

	Note that, instructions in the "XTHeadZvamo" extension currently has
	no conflicts with other extensions, even after addition of the "Zabha"
	extension.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_check_conflicts):
		Make "XTheadVector" conflict with not just "V" but its subsets.

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector-fail.d: Test a vector
		subset "Zve32x" to test failures.
		* testsuite/gas/riscv/x-thead-vector-fail.l: Reflect change
		in the error message.

2025-05-19  Jens Remus  <jremus@linux.ibm.com>

	s390: Simplify test for absolute symbol
	Simplify the test whether a symbol is absolute, by using the helper
	bfd_is_abs_symbol.

	bfd/
		* elf64-s390.c (elf_s390_relocate_section): Use
		bfd_is_abs_symbol to test whether symbol is absolute.

2025-05-19  Jens Remus  <jremus@linux.ibm.com>

	s390: Prevent GOT access rewrite for misaligned symbols
	Dereferences of GOT slots with lgrl or lg for global symbols are
	rewritten to larl to get get rid of the extra memory access.  However
	this is invalid for:

	- symbols marked for absolute addressing
	- symbols at odd addresses (larl can handle only even addresses)

	Commit e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain
	symbols") added checks for the above.  But instead of checking the
	address of a symbol for being halfword aligned, it tries to deduce
	this from whether the symbol value and section the symbol is defined
	in are halfword aligned.  The way it is done has two issues:

	1. The use of bfd_section_from_elf_index to obtain the section the
	   symbol is defined in may not return the one that remains in the
	   output.  For instance for COMDAT sections getting deduplicated
	   the section retrieved using bfd_section_from_elf_index may not be
	   the same as h->root.u.def.section.  If COMDAT sections of same
	   group signature have different alignment properties the wrong
	   one may be checked. This may then lead to an erroneous rewrite
	   of lgrl %rX, sym@GOTENT to larl %rX, sym, although the symbol in
	   the remaining section is not properly aligned, triggering an
	   "relocation for misaligned symbol" error at link-time.

	   This may for instance occur when mixing C++ modules compiled with
	   GCC and Clang, as GCC emits a 2-byte alignment and Clang a 1-byte
	   alignment for COMDAT sections containing type information:

	     $ cat sample.cpp
	     #include <typeinfo>
	     struct A {};
	     const std::type_info &q() { return typeid(A); }

	     $ g++ -c sample.cpp -o sample_gcc.o
	     $ clang++ -c sample.cpp -o sample_clang.o
	     $ readelf -WS sample_gcc.o sample_clang.o

	     Produces (reformatted and reduced):
	     File           Name           Off    Size   ES Flg Lk Inf Al
	     sample_gcc.o   .rodata._ZTS1A 000080 000004 00  AG  0   0  2
	     sample_clang.o .rodata._ZTS1A 000058 000003 00  AG  0   0  1

	2. The symbol may end up at an even address, if both the symbol value
	   and the section defining the symbol are 1-byte aligned.  While this
	   does not trigger an error, it fails an opportunity to rewrite a GOT
	   access.

	   In a Linux Kernel build this causes ~15k GOT accesses using lgrl to
	   be skipped to be rewritten to larl.

	Resolve both issues by simply checking whether the symbol address is
	halfword aligned.  Do not check the symbol value nor section defining
	the symbol for halfword alignment.

	bfd/
		PR ld/32969
		* elf64-s390.c (elf_s390_relocate_section): Only rewrite
		lgrl/lg from GOT to larl if symbol address is halfword aligned.

	ld/testsuite/
		PR ld/32969
		* ld-s390/s390.exp (pr32969_64-1, pr32969_64-2): Add tests for
		rewrite of GOT access when COMDAT section deduplication is
		involved.
		* ld-s390/pr32969_64-1.dd: New test for rewrite of GOT access
		when COMDAT section deduplication is involved.
		* ld-s390/pr32969_64-2.dd: Likewise.
		* ld-s390/pr32969a.s: Likewise.
		* ld-s390/pr32969b.s: Likewise.
		* ld-s390/pr32969c.s: Likewise.

	Bug: https://sourceware.org/PR32969
	Fixes: e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain symbols")
	Reported-by: Ilya Leoshkevich <iii@linux.ibm.com>

2025-05-19  Jens Remus  <jremus@linux.ibm.com>

	s390: Improve diagnostic for reloc against misaligned sym
	Report the BFD in which a misaligned symbol is defined in the error
	message.  This complements commit 906f69cf65da ("IBM zSystems: Issue
	error for *DBL relocs on misaligned symbols").  While at it reword
	the error message.

	Old error message text (re-wrapped):
	<sec-bfd>(<sec>+<off>): misaligned symbol `<sym>' (<addr>) for
	                        relocation <rel>

	New error message text (re-wrapped):
	<sec-bfd>(<sec>+<off>): relocation <rel> against misaligned symbol
	                        `<sym>' (<addr>) in <sym-bfd>

	Note that the linker tests do not require to be updated, as they match
	against the pattern ".*misaligned symbol.*", which has not changed in
	the error message.

	bfd/
		PR ld/32969
		* elf64-s390.c (elf_s390_relocate_section): Report BFD
		in which a misaligned symbol is defined in error message.

	Bug: https://sourceware.org/PR32969
	Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>

2025-05-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: handle .cfi_undefined
	Fix PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas

	In context of SFrame generation, it is incorrect to simply ignore all
	.cfi_undefined.  We may ignore only those .cfi_undefined which are for
	registers of no interest (similar to whats done for other CFI
	directives).

	gas/
	        * gen-sframe.c (sframe_xlate_do_cfi_undefined): New definition.
	        (sframe_do_cfi_insn): Handle .cfi_undefined.
	gas/testsuite/
	        * gas/cfi-sframe/cfi-sframe.exp: Add new tests.
	        * gas/cfi-sframe/cfi-sframe-common-10.d: New test.
	        * gas/cfi-sframe/cfi-sframe-common-10.s: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.s: New test.

2025-05-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: reword diagnostic to address ambiguity
	The current warning text of "skipping SFrame FDE" does not unabiguously
	indicate that the SFrame FDE is not generated in the output section.
	Reword the diagnostic to say "no SFrame FDE emitted" as requested.

	Adjust the testcases for the updated warning.

2025-05-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: i386: have the backend specify the RA too
	To process some CFI directives like .cfi_undefined and .cfi_same_value,
	it is necessary for correctness to detect all cases when the register
	used is one of SP, FP or RA.

	Currently, the backends needed to specify the SFRAME_CFA_RA_REG only in
	the case of those ABIs where RA tracking was necessary, e.g. AArch64.
	For AMD64, since the return address is always at a fixed offset from the
	CFA, RA tracking was disabled.

	The backends must now specify the applicable return address register via
	SFRAME_CFA_RA_REG.  This is necessary so that SFrame generation code can
	then properly handle the cases when RA is used like so:
	   .cfi_undefined <RA>
	or,
	   .cfi_same_value <RA>

	Detecting these cases is necessary for correctness.  E.g., on AMD64, we
	need to skip FDE generation as the above constructs cannot be
	represented in SFrame yet.

	This change is a prerequisite to fixing the two PRs:

	PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas
	PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas

	In the SFrame generation code in gen-sframe.c, instead of using
	SFRAME_FRE_RA_TRACKING ifdef's, we now simply rely on the API
	sframe_ra_tracking_p () to detect if RA-tracking is enabled for the
	target.

	While at it, use const variables for x86 backend.

	ChangeLog:

	        * gas/config/tc-i386.c (x86_sframe_cfa_ra_reg): New definition.
	        * gas/config/tc-i386.h (REG_RA): New definition.
		(SFRAME_CFA_RA_REG): New declaration.
	        * gas/gen-sframe.c (SFRAME_FRE_RA_TRACKING): Remove.

2025-05-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-18  Christina Schimpe  <christina.schimpe@intel.com>

	bfd: Handle note of type NT_X86_SHSTK

2025-05-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-16  Tom Tromey  <tromey@adacore.com>

	Update comment for find_field_create_baton
	Andrew pointed out that a recent commit neglected to update the
	comment for find_field_create_baton.  This patch fixes the oversight.

2025-05-16  Alan Modra  <amodra@gmail.com>

	ubsan: emit_inc_line_addr integer overflow
	Commit 07cf922195d1 fixed the one in size_inc_line_addr.  Silly me
	missed the identical overflow in emit_inc_line_addr

2025-05-16  Alan Modra  <amodra@gmail.com>

	gas .align limit
	At the moment we allow alignment of up to half the address space,
	which is stupidly large and results in OOM on x86_64.  Change that to
	1G alignment in text sections.  Also fix the warning message on
	exceeding max allowed alignment.

		* read.c (TC_ALIGN_LIMIT): Limit to 30 in text sections.
		(s_align): Correct "alignment too large" value.

2025-05-16  Alan Modra  <amodra@gmail.com>

	ld testsuite fail with --disable-plugins
		* testsuite/config/default.exp (dep_plug_opt): Don't set unless
		check_plugin_api_available returns true.

2025-05-16  Jan Beulich  <jbeulich@suse.com>

	gas: adjust a comparison in s_align()
	In 344b1e0f5f79 ("gas: range-check 3rd argument of .align et al") I
	neglected to consider compilers which warn about signed/unsigned
	mismatches in comparisons (which is somewhat odd when the signed value is
	already known to be non-negative).

	gas: range-check 3rd argument of .align et al
	Negative values would have been silently converted to large positive
	ones, which may not be the user's intention. Similarly overly large
	values would have been silently truncated. Warn them instead, and zap
	such values.

2025-05-16  Collin Funk  <collin.funk1@gmail.com>

	ld/doc: Remove '.info' suffix in @ref, etc
	Texinfo 7.2 began showing warnings like:

	    ld.texi:1026: warning: do not set .info suffix in reference for manual `gcc.info'
	    ld.texi:9689: warning: do not set .info suffix in reference for manual `binutils.info'

	The Texinfo developers plan to stop removing the '.info' suffix
	internally in a future release so without this patch the references will
	break in the future.

2025-05-16  Collin Funk  <collin.funk1@gmail.com>

	binutils/doc: Remove '.info' suffix in @ref, etc
	Texinfo 7.2 began showing warnings like:

	    binutils.texi:882: warning: do not set .info suffix in reference for manual `ld.info'
	    binutils.texi:1365: warning: do not set .info suffix in reference for manual `ld.info'

	The Texinfo developers plan to stop removing the '.info' suffix
	internally in a future release so without this patch the references will
	break in the future.

2025-05-16  Jan Beulich  <jbeulich@suse.com>

	x86: improve matching diagnostics when %st is involved
	Diagnosing operand size vs operand type mismatches doesn't work very
	well when GPRs and FPRs are in the same register class, distinguished
	just by size. Introduce a separate RegFP class.

	x86: move Anysize check in operand_size_match()
	Anysize is applicable to memory operands only. Move the check to where
	memory operands are handled. (The RegSIMD part there was questionable
	altogether.)

	x86: improve matching diagnostics when "accumulator" registers are involved
	In templates, the expectation of an "accumulator" register to be used is
	expressed solely by operand size; there's no "class" specifier there.
	Hence operand_size_match() is too eager in invoking
	match_{operand,simd}_size(), resulting in "operand size mismatch" errors
	when it's the type (of register), not the size that's wrong.
	Interestingly adjustments there alone lead to no error at all then: To
	"compensate", operand_type_match() needs to disambiguate register types
	when register instances are specified in the template (matching the
	actual operand), by checking a match (overlap) in operand sizes.

	x86: fold Accum checking in operand_size_match()
	There's little point invoking match_{operand,simd}_size() twice per
	loop; in fact the SIMD case with D set simply doesn't exist. Amend the
	checks by one looking at the given operand, just like we already have
	been doing for memory ones.

2025-05-16  Jan Beulich  <jbeulich@suse.com>

	x86: improve matching diagnostics
	Many times in the past I was puzzled by seeing "operand size mismatch"
	when really "operand type mismatch" would be far more appropriate. As it
	turns out, there were at least two flaws: In the single operand case we
	didn't propagate i.error to match_template()'s local specific_error when
	noticing a type mismatch. And then operand_size_match() was too eager in
	invoking match_mem_size(): Especially the Unspecified attribute can get
	in the way there when the expected operand isn't a memory one (and hence
	Unspecified would not be set in the operand template, whereas it's
	uniformly set for memory operands in AT&T syntax).

	(In the x86-64-lkgs-inval testcase the particular error for the two
	bogus Intel syntax forms doesn't really matter; all we ought to care
	about there isthat there is _some_ error.)

2025-05-16  Jan Beulich  <jbeulich@suse.com>

	x86: drop bogus accumulator check
	Accum is an "instance", not a "class". With present enumerator values of
	Reg and Accum, the 2nd check simply did the same as the first. In fact
	checking for the accumulator (%rax) isn't necessary here at all, because
	there's no case where an individual template would permit alternatively
	a memory operand or the (qword) accumulator; only "any GPR" is ever
	being paired with "memory".

2025-05-16  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: check offsets when linker relaxation is disabled
	The assembler partially relied on the linker to check whether the
	offset is valid.  However, some optimization logic (added later)
	removes relocations relative to local symbols without checking offsets.

	For instance, it caused following code to silently emit wrong jumps
	(to the jump instruction "." itself) without relocations:

	> .option norelax
	> j .+0x200000   # J (or JAL) instruction cannot encode this offset.
	> j .+1          # Jump to odd address is not valid.

	This commit adds offset checks where necessary.

	gas/ChangeLog:

		* config/tc-riscv.c (md_apply_fix): Check offsets when the
		relocation relative to a local symbol is being optimized out.
		* testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure
		case where the branch offset is invalid.
		* testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto.
		* testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto.
		* testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case.
		* testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto.
		* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure
		case only on RV64 where the PC-relative offset exceed limits.
		* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto.
		* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto.
		* testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test
		case for RV32 so that no errors occur.
		* testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case.
		* testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto.

2025-05-16  dysun  <sundongya@nucleisys.com>

	RISC-V: Add zilsd & zclsd support
	Ref: https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc


	Co-developed-by: LIU Xu <liuxu@nucleisys.com>
	Co-developed-by: ZHAO Fujin <zhaofujin@nucleisys.com>

2025-05-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: avoid creating more symbols than necessary for FRE offset
	Each SFrame FDE contains an offset to the start of its respective SFrame
	FREs in the sfde_func_start_fre_off field.  To generate this offset,
	fre_symbols[] array is being used.  The number of elements of this array
	is currently set to the total number of SFrame FREs in the entire SFrame
	section.  This is more than unnecessary.  We only need to track as many
	points as the number of SFrame FDEs.

	gas/
		* gen-sframe.c (output_sframe_internal):  Size fde_fre_symbols
		with the number of SFrame FDEs.

2025-05-15  Tom Tromey  <tromey@adacore.com>

	Fix regression with dynamic array bounds
	Kévin discovered that commit ba005d32b0f ("Handle dynamic field
	properties") regressed a test in the internal AdaCore test suite.

	The problem here is that, when writing that patch, I did not consider
	the case where an array type's bounds might come from a member of a
	structure -- but where the array is not defined in the structure's
	scope.

	In this scenario the field-resolution logic would trip this condition:

	  /* Defensive programming in case we see unusual DWARF.  */
	  if (fi == nullptr)
	    return nullptr;

	This patch reworks this area, partly backing out that commit, and
	fixes the problem.

	In the new code, I chose to simply duplicate the field's location
	information.  This isn't totally ideal, in that it might result in
	multiple copies of a baton.  However, this seemed nicer than tracking
	the DIE/field correspondence for every field in every CU -- my
	thinking here is that this particular dynamic scenario is relatively
	rare overall.  Also, if the baton cost does prove onerous, we could
	intern the batons somewhere.

	Regression tested on x86-64 Fedora 41.  I also tested this using the
	AdaCore internal test suite.

	Tested-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-15  Andreas Schwab  <schwab@suse.de>

	ld: rename ldirname to stat_ldirname
	It conflicts with the ldirname function that will be added in the next
	libiberty sync.

	ld/:
		* ldlang.c (stat_ldirname): Rename from ldirname, all uses
		changed.

2025-05-15  Andreas Schwab  <schwab@suse.de>

	gdb: rename ldirname to gdb_ldirname
	It conflicts with the ldirname function that will be added in the next
	libiberty sync.

2025-05-15  H.J. Lu  <hjl.tools@gmail.com>

	binutils: Don't complain plugin with all LTO sections removed
	When all LTO sections have been removed, the BFD lto_type is set to
	lto_non_ir_object by bfd_set_lto_type.  In this case, don't complain
	needing a plugin when seeing a LTO slim symbol.

	bfd/

		PR binutils/32967
		* archive.c (_bfd_compute_and_write_armap): Call
		bfd_lto_slim_symbol_p to check LTO slim symbol.
		* bfd-in2.h: Generated.
		* bfd.c (bfd_lto_slim_symbol_p): New.

	binutils/

		PR binutils/32967
		* nm.c (filter_symbols): Call bfd_lto_slim_symbol_p to check
		LTO slim symbol.

	ld/

		PR binutils/32967
		* testsuite/ld-plugin/lto-binutils.exp: Run PR binutils/32967
		tests.
		* testsuite/ld-plugin/strip-1a-s-all.nd: New file.

2025-05-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-15  Alan Modra  <amodra@gmail.com>

	gas .file 0 vs. dwarf5
	Support added in commit 3417bfca676f for dwarf5 directory table 0
	assumed that .file 0 was always the first debug .file directive.
	That's not necessarily true.

		* dwarf2dbg.c (get_directory_table_entry): Don't assume entry
	        1 is available after putting DW_AT_comp_dir in entry 0.  Pass
		pwd as file0_dirname to recursive call to avoid another
	        getpwd in the case file0_dirname is NULL.

2025-05-14  Rohr, Stephan  <stephan.rohr@intel.com>

	testsuite: fix gdb_exit for MinGW target
	GDB is not properly exited via 'remote_close host' when running the
	testsuite in a MinGW environment.  Use the 'quit' command to properly
	exit the GDB debugging session.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-14  Rohr, Stephan  <stephan.rohr@intel.com>

	testsuite: get windows PID on MinGW target
	Also translate the MinGW PID to the Windows PID when running on a MinGW
	target.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-14  Tom Tromey  <tromey@adacore.com>

	Fix create_breakpoint_parse_arg_string self-test
	The emoji patch broke the create_breakpoint_parse_arg_string self-test
	when gdb is running on a suitable terminal.  The problem is that the
	test case doesn't take the error prefix string into account.

	This patch fixes the test by having it compare the exception message
	directly, rather than relying on the result of exception_print.  I did
	try a different approach, of having the test mimic exception_print,
	but this one seemed cleaner to me.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-14  Tom Tromey  <tromey@adacore.com>

	Add initializers to field_of_this_result
	This adds initializers to field_of_this_result, so that certain spots
	don't have to memset it.  This approach seems safer and cleaner.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-14  Tom Tromey  <tromey@adacore.com>

	Fix some pre-commit nits in gdb/__init__.py
	I noticed that pre-commit has some complaints (flake8 and codespell)
	about gdb/__init__.py.  This patch fixes these.

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-05-14  Alan Modra  <amodra@gmail.com>

	resbin: don't pass NULL as printf %s arg
	Fix three place where a NULL could be passed to "toosmall".

2025-05-14  Alan Modra  <amodra@gmail.com>

	gas .file sanity check
	Currently we allow insane file numbers that cause gas to allocate up
	to 4G of memory for a file array.  Trim that a little to 1G (which
	still allows insane file numbers up to 33554431), and tidy function
	parameter types so that we only need one file number sanity check.

		* dwarf2dbg.c (assign_file_to_slot): Take a valueT file number.
		Reduce max files array size.
		(allocate_filename_to_slot): Take a valueT file number.
		(dwarf2_directive_filename): Don't duplicate file number
		sanity check here.

2025-05-14  Richard Earnshaw  <rearnsha@arm.com>

	Remove Marcus Shawcroft from the MAINTAINERS file
	Marcus has resigned from the project.

2025-05-14  H.J. Lu  <hjl.tools@gmail.com>

	ld/testsuite: Use $plug_opt for --plugin option
	Use $plug_opt for --plugin usage, instead of running:

	run_host_cmd "$CC_FOR_TARGET" "-print-prog-name=liblto_plugin.so"

		PR binutils/21479
		* testsuite/ld-plugin/lto-binutils.exp (lto_plugin): Removed.
		Replace "--plugin $lto_plugin" with $plug_opt.
		* testsuite/ld-plugin/lto.exp (lto_plugin): Removed.
		Replace "--plugin $lto_plugin" with $plug_opt.

2025-05-14  Matthieu Longo  <matthieu.longo@arm.com>

	Remove annoying spaces from objcopy.exp

	Remove annoying spaces from bfd/elfxx-aarch64.c

	Remove annoying space from gas/config/obj-elf.c

2025-05-14  H.J. Lu  <hjl.tools@gmail.com>

	strip: Add GCC LTO IR support
	Add GCC LTO IR support to strip by copying GCC LTO IR input as unknown
	object file.  Don't enable LTO plugin in strip unless all LTO sections
	should be removed, assuming all LTO sections will be removed with
	-R .gnu.lto_.*.  Add linker LTO tests for strip with --strip-unneeded
	and GCC LTO IR inputs.

	binutils/

		PR binutils/21479
		* objcopy.c: Include "plugin-api.h" and "plugin.h".
		(lto_sections_removed): New.
		(command_line_switch): Add OPTION_PLUGIN.
		(strip_options): Likewise.
		(strip_usage): Display "--plugin NAME".
		(copy_unknown_file): New function.
		(copy_unknown_object): Call copy_unknown_file.
		(copy_archive): Copy input LTO IR member as unknown object.
		(copy_file): Set input target to "plugin" for strip if it is
		unset unless all LTO sections should be removed.  Copy input
		LTO IR file as unknown file.
		(strip_main): Call bfd_plugin_set_program_name. Handle
		OPTION_PLUGIN.  Set lto_sections_removed to true if all GCC
		LTO sections should be removed.
		* doc/binutils.texi: Document --plugin for strip.

	ld/

		PR binutils/21479
		* testsuite/ld-plugin/lto-binutils.exp: New file.
		* testsuite/ld-plugin/strip-1a-fat.c: Likewise.
		* testsuite/ld-plugin/strip-1a-fat.rd: Likewise.
		* testsuite/ld-plugin/strip-1b-fat.c: Likewise.
		* testsuite/ld-plugin/strip-1b-fat.rd: Likewise.
		* testsuite/ld-plugin/strip-1a.c: Likewise.
		* testsuite/ld-plugin/strip-1b.c: Likewise.
		* testsuite/lib/ld-lib.exp (run_cc_link_tests): Add optional
		trailing ld options.

2025-05-14  Sam James  <sam@gentoo.org>

	ld: fix C23 issue in vers7 test
	This test is UNSUPPORTED on arm64 with GCC 15 (which defaults to -std=gnu23)
	because it now prototypes "no arguments".

		PR ld/32546
		* ld-elfvers/vers7.c: Fix function definitions for C23.

2025-05-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-13  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Replace incorrect comment
	The comment explaining the placement of the cfinv entry before the
	generic msr entry in the opcode table was incorrect.  The issue is
	unrelated to the all ones bitmask for cfinv, and is actually due the
	large number of architectural aliases of the msr instruction.

2025-05-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: new gdb.ParameterPrefix class
	This commit adds a new gdb.ParameterPrefix class to GDB's Python API.

	When creating multiple gdb.Parameters, it is often desirable to group
	these together under a sub-command, for example, 'set print' has lots
	of parameters nested under it, like 'set print address', and 'set
	print symbol'.  In the Python API the 'print' part of these commands
	are called prefix commands, and are created using gdb.Command objects.

	However, as parameters are set via the 'set ....' command list, and
	shown through the 'show ....' command list, creating a prefix for a
	parameter usually requires two prefix commands to be created, one for
	the 'set' command, and one for the 'show' command.

	This often leads to some duplication, or at the very least, each user
	will end up creating their own helper class to simplify creation of
	the two prefix commands.

	This commit adds a new gdb.ParameterPrefix class.  Creating a single
	instance of this class will create both the 'set' and 'show' prefix
	commands, which can then be used while creating the gdb.Parameter.

	Here is an example of it in use:

	  gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE)

	This adds 'set my-prefix' and 'show my-prefix', both of which are
	prefix commands.  The user can then add gdb.Parameter objects under
	these prefixes.

	The gdb.ParameterPrefix initialise method also supports documentation
	strings, so we can write:

	  gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
	      "Configuration setting relating to my special extension.")

	which will set the documentation string for the prefix command.

	Also, it is possible to support prefix commands that use the `invoke`
	functionality to handle unknown sub-commands.  This is done by
	sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
	'invoke_show' to handle the 'set' or 'show' prefix command
	respectively.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-05-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/guile: generate general description string for parameters
	This commit builds on the previous one, and auto-generates a general
	description string for parameters defined via the Guile API.  This
	brings the Guile API closer inline with the Python API.  It is worth
	reading the previous commit to see some motivating examples.

	This commit updates get_doc_string in guile/scm-param.c to allow for
	the generation of a general description string.  Then in
	gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is
	used to generate a suitable default.

	This does invalidate (and so the commit removes) this comment that was
	in gdbscm_make_parameter:

	  /* If doc is NULL, leave it NULL.  See add_setshow_cmd_full.  */

	First, Python already does exactly what I'm proposing here, and has
	done for a while, with no issues reported.  And second, I've gone and
	read add_setshow_cmd_full, and some of the functions it calls, and can
	see no reasoning behind this comment...

	... well, there is one reason that I can think of, but I'll discuss
	that more below.

	With this commit, if I define a parameter like this:

	  (use-modules (gdb))
	  (register-parameter! (make-parameter
	                        "print test"
	                        #:command-class COMMAND_NONE
	                        #:parameter-type PARAM_BOOLEAN))

	Then, in GDB, I now see this behaviour:

	  (gdb) help show print test
	  Show the current value of 'print test'.
	  This command is not documented.
	  (gdb) help set print test
	  Set the current value of 'print test'.
	  This command is not documented.
	  (gdb)

	The two 'This command is not documented.' lines are new.  This output
	is what we get from a similarly defined parameter using the Python
	API (see the previous commit for an example).

	I mentioned above that I can think of one reason for the (now deleted)
	comment in gdbscm_make_parameter about leaving the doc field as NULL,
	and that is this: consider the following GDB behaviour:

	  (gdb) help show style filename foreground
	  Show the foreground color for this property.
	  (gdb)

	Notice there is only a single line of output.  If I want to get the
	same behaviour from a parameter defined in Guile, I might try skipping
	the #:doc argument, but (after this commit), if I do that, GDB will
	auto-generate some text for me, giving two lines of output (see
	above).

	So, next, maybe I try setting #:doc to the empty string, but if I do
	that, then I get this:

	  (use-modules (gdb))
	  (register-parameter! (make-parameter
	                        "print test"
				#:doc ""
	                        #:command-class COMMAND_NONE
	                        #:parameter-type PARAM_BOOLEAN))

	  (gdb) help show print test
	  Show the current value of 'print test'.

	  (gdb)

	Notice the blank line, that's not what I wanted.  In fact, the only
	way to get rid of the second line is to leave the 'doc' variable as
	NULL in gdbscm_make_parameter, which, due to the new auto-generation,
	is no longer possible.

	This issue also existed in the Python API, and was addressed in
	commit:

	  commit 4b68d4ac98aec7cb73a4b276ac7dd38d112786b4
	  Date:   Fri Apr 11 23:45:51 2025 +0100

	      gdb/python: allow empty gdb.Parameter.__doc__ string

	After this commit, an empty __doc__ string for a gdb.Parameter is
	translated into a NULL pointer passed to the add_setshow_* command,
	which means the second line of output is completely skipped.

	And this commit includes the same solution for the Guile API.  Now,
	with this commit, and the Guile parameter using an empty '#:doc'
	string, GDB has the following behaviour:

	  (gdb) help show print test
	  Show the current value of 'print test'.
	  (gdb)

	This matches the output for a similarly defined parameter in Python.

2025-05-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/guile: improve auto-generated strings for parameters
	Consider this user defined parameter created in Python:

	  class test_param(gdb.Parameter):
	     def __init__(self, name):
	        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
	        self.value = True

	  test_param('print test')

	If this is loaded into GDB, then we observe the following behaviour:

	  (gdb) show print test
	  The current value of 'print test' is "on".
	  (gdb) help show print test
	  Show the current value of 'print test'.
	  This command is not documented.
	  (gdb) help set print test
	  Set the current value of 'print test'.
	  This command is not documented.
	  (gdb)

	If we now define the same parameter using Guile:

	  (use-modules (gdb))
	  (register-parameter! (make-parameter
	                        "print test"
	                        #:command-class COMMAND_NONE
	                        #:parameter-type PARAM_BOOLEAN))

	And load this into a fresh GDB session, we see the following:

	  (gdb) show print test
	  Command is not documented is off.
	  (gdb) help show print test
	  This command is not documented.
	  (gdb) help set print test
	  This command is not documented.
	  (gdb)

	The output of 'show print test' doesn't make much sense, and is
	certainly worse than the Python equivalent.  For both the 'help'
	commands it appears as if the first line is missing, but what is
	actually happening is that the first line has become 'This command is
	not documented.', and the second line is then missing.

	The problems can all be traced back to 'get_doc_string' in
	guile/scm-param.c.  This is the guile version of this function.  There
	is a similar function in python/py-param.c, however, the Python
	version returns one of three different strings depending on the use
	case.  In contrast, the Guile version just returns 'This command is
	not documented.' in all cases.

	The three cases that the Python code handles are, the 'set' string,
	the 'show' string, and the general 'description' string.

	Right now the Guile get_doc_string only returns the general
	'description' string, which is funny, because, in
	gdbscm_make_parameter, where get_doc_string is used, the one case that
	we currently don't need is the general 'description' string.  Instead,
	right now, the general 'description' string is used for both the 'set'
	and 'show' cases.

	In this commit I plan to bring the Guile API a little more inline with
	the Python API.  I will update get_doc_string (in scm-param.c) to
	return either a 'set' or 'show' string, and gdbscm_make_parameter will
	make use of these strings.

	The changes to the Guile get_doc_string are modelled on the Python
	version of this function.  It is also worth checking out the next
	commit, which is related, and helps motivate how the changes have been
	implemented in this commit.

	After this commit, the same Guile parameter description shown above,
	now gives this behaviour:

	  (gdb) show print test
	  The current value of 'print test' is off.
	  (gdb) help show print test
	  Show the current value of 'print test'.
	  (gdb) help set print test
	  Set the current value of 'print test'.
	  (gdb)

	The 'show print test' output now matches the Python behaviour, and is
	much more descriptive.  The set and show 'help' output are now missing
	the second line when compared to the Python output, but the first line
	is now correct, and I think this is better than the previous Guile
	output.

	In the next commit I'll address the problem of the missing second
	line.

	Existing tests have been updated to expect the new output.

2025-05-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: allow empty gdb.Parameter.__doc__ string
	I was recently attempting to create some parameters via the Python
	API.  I wanted these parameters to appear similar to how GDB handles
	the existing 'style' parameters.

	Specifically, I was interested in this behaviour:

	  (gdb) help show style filename foreground
	  Show the foreground color for this property.
	  (gdb) help set style filename foreground
	  Set the foreground color for this property.
	  (gdb)

	Notice how each 'help' command only gets a single line of output.

	I tried to reproduce this behaviour via the Python API and was unable.

	The problem is that, in order to get just a single line of output like
	this, the style parameters are registered with a call to
	add_setshow_color_cmd with the 'help_doc' being passed as nullptr.

	On the Python side, when parameters are created, the 'help_doc' is
	obtained with a call to get_doc_string (python/py-param.c).  This
	function either returns the __doc__ string, or a default string: "This
	command is not documented.".

	To avoid returning the default we could try setting __doc__ to an
	empty string, but setting this field to any string means that GDB
	prints a line for that string, like this:

	  class test_param(gdb.Parameter):
	     __doc__ = ""
	     def __init__(self, name):
	        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
	        self.value = True

	  test_param('print test')

	Then in GDB:

	  (gdb) help set print test
	  Set the current value of 'print test'.

	  (gdb)

	The blank line is the problem I'd like to solve.

	This commit makes a couple of changes to how parameter doc strings are
	handled.

	If the doc string is set to an empty string, then GDB now converts
	this to nullptr, which removes the blank line problem, the new
	behaviour in GDB (for the above `test_param`) is:

	  (gdb) help set print test
	  Set the current value of 'print test'.
	  (gdb)

	Next, I noticed that if the set/show docs are set to empty strings,
	then the results are less than ideal:

	  class test_param(gdb.Parameter):
	     set_doc = ""
	     def __init__(self, name):
	        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
	        self.value = True

	  test_param('print test')

	And in GDB:

	  (gdb) help set print test

	  This command is not documented.
	  (gdb)

	So, if the set/show docs are the empty string, GDB now forces these to
	be the default string instead, the new behaviour in GDB is:

	  (gdb) help set print test
	  Set the current value of 'print test'.
	  This command is not documented.
	  (gdb)

	I've added some additional asserts; the set/show docs should always be
	non-empty strings, which I believe is the case after this commit.  And
	the 'doc' string returned from get_doc_string should never nullptr,
	but could be empty.

	There are new tests to cover all these changes.

2025-05-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python/guile: check for invalid prefixes in Command/Parameter creation
	The manual for gdb.Parameter says:

	  If NAME consists of multiple words, and no prefix parameter group
	  can be found, an exception is raised.

	This makes sense; we cannot create a parameter within a prefix group,
	if the prefix doesn't exist.  And this almost works, so:

	  (gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
	  Python Exception <class 'RuntimeError'>: Could not find command prefix xxx.
	  Error occurred in Python: Could not find command prefix xxx.

	The prefix 'xxx' doesn't exist, and we get an error.  But, if we try
	multiple levels of prefix:

	  (gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)

	This completes without error, however, we didn't get what we were
	maybe expecting:

	  (gdb) show print xxx foo
	  Undefined show print command: "xxx foo".  Try "help show print".

	But we did get:

	  (gdb) show print foo
	  The current value of 'print foo' is "off".

	GDB stopped scanning the prefix string at the unknown 'xxx', and just
	created the parameter there.  I don't think this makes sense, nor is
	it inline with the manual.

	An identical problem exists with gdb.Command creation; GDB stops
	parsing the prefix at the first unknown prefix, and just creates the
	command there.  The manual for gdb.Command says:

	  NAME is the name of the command.  If NAME consists of multiple
	  words, then the initial words are looked for as prefix commands.
	  In this case, if one of the prefix commands does not exist, an
	  exception is raised.

	So again, the correct action is, I believe, to raise an exception.

	The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB
	calls lookup_cmd_1 to look through the prefix string and return the
	last prefix group.  If the very first prefix word is invalid then
	lookup_cmd_1 returns NULL, and this case is handled.  However, if
	there is a valid prefix, followed by an invalid prefix, then
	lookup_cmd_1 will return a pointer to the last valid prefix list, and
	will update the input argument to point to the start of the invalid
	prefix word.  This final case, where the input is left pointing to an
	unknown prefix, was previously not handled.

	I've fixed gdbpy_parse_command_name, and added tests for command and
	parameter creation to cover this case.

	The exact same error is present in the guile API too.  The guile
	documentation for make-parameter and make-command says the same things
	about unknown prefixes resulting in an exception, but the same error
	is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've
	fixed that too, and added some tests.

2025-05-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: skip broken .debug_macro.dwo
	Running gdb.base/errno.exp with gcc <= 13 with split DWARF results in:

	    $ make check TESTS="gdb.base/errno.exp" RUNTESTFLAGS="CC_FOR_TARGET=gcc-13 --target_board=fission"
	    (gdb) break -qualified main
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7549: internal-error: locate_dwo_sections: Assertion `!dw_sect->readin' failed.
	    A problem internal to GDB has been detected,
	    further debugging may prove unreliable.
	    ...
	    FAIL: gdb.base/errno.exp: macros: gdb_breakpoint: set breakpoint at main (GDB internal error)

	The assert being hit has been added in 28f15782adab ("gdb/dwarf: read
	multiple .debug_info.dwo sections"), but it merely exposed an existing
	problem.

	gcc versions <= 13 are affected by this bug:

	  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

	Basically, it produces .dwo files with multiple .debug_macro.dwo
	sections, with some unresolved links between them.  I think that this
	macro debug info is unusable, and all we can do is ignore it.

	In locate_dwo_sections, if we detect a second .debug_macro.dwo section,
	forget about the previous .debug_macro.dwo and any subsequent one.  This
	will effectively make it as if the macro debug info wasn't there at all.

	The errno test seems happy with it:

	    # of expected passes            84
	    # of expected failures          8

	Change-Id: I6489b4713954669bf69f6e91865063ddcd1ac2c8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: move loops into locate_dw{o,z}_sections
	For a subsequent patch, it would be easier if the loop over sections
	inside locate_dwo_sections (I want to maintain some state for the
	duration of the loop).  Move the for loop in there.  And because
	locate_dwz_sections is very similar, modify that one too, to keep both
	in sync.

	Change-Id: I90b3d44184910cc2d86af265bb4b41828a5d2c2e
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-12  oltolm  <oleg.tolmatcev@gmail.com>

	gdb/dap: fix decode_source
	The documentation for the Source interface says

	   * The path of the source to be shown in the UI.
	   * It is only used to locate and load the content of the source if no
	   * `sourceReference` is specified (or its value is 0).

	but the code used `path` first. I fixed it to use `sourceReference` first.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-12  Keith Seitz  <keiths@redhat.com>

	[PATCH] Add syscall tests when following/detaching from fork
	breakpoints/13457 discusses issues with syscall catchpoints when
	following forks, lamenting that there is no coverage for the
	various permutations of `follow-fork-mode' and `detach-on-fork'.

	This is an attempt to try and cover some of this ground. Unfortunately
	the state of syscall support when detaching after the fork is
	very, very inconsistent across various architectures. [I've tested
	extensively Fedora/RHEL platforms.]

	Right now, the only reliable platform to run tests on is x86_64/i?86
	for the specific case where we do not detach from the fork. Consequently,
	this patch limits testing to those architectures.

	I have updated breakpoints/13457 with my findings on failures with the
	detaching case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-05-12  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_RME_GPC3
	FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
	a method for defining a set of windows in the memory map for which
	Granule Protection Checks are skipped, and instead applies a set of
	default settings associated with the window.

	This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
	access this sysreg since this feature is optional from armv9.5-a.

2025-05-12  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Support for FEAT_OCCMO
	FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
	system instructions that provides software with a mechanism to publish
	writes to the Outer cache level.

2025-05-12  Patrick Monnerat  <patrick@monnerat.net>

	gdbsupport/event-loop: do not truncate poll timeouts to lower second
	In update_wait_timeout function, microseconds were not taken into account
	in poll timeout computation, resulting in 100% cpu time consumption in
	the event loop while waiting for a sub-second timeout.

	The bug has been introduced in commit c2c6d25.

	This patch adds the microseconds converted to milliseconds in poll
	timeout computation. Conversion by excess (ceil) is performed to
	avoid the same problem with sub-millisecond timeouts too.

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: pass std::string from linux_find_memory_regions_full
	Update linux_find_memory_region_ftype to take 'const std::string &'
	instead of 'const char *', update the two functions which are passed
	as callbacks to linux_find_memory_regions_full.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove unnecessary function declaration
	There's no need to declare a function immediately before its
	definition.  Lets not do that.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: move extra checks into dump_note_entry_p
	Now that dump_note_entry_p is always called (see previous commit), we
	can move some of the checks out of linux_make_mappings_callback into
	dump_note_entry_p.

	The checks only exist in linux_make_mappings_callback because, before
	the previous commit, we couldn't be sure that dump_note_entry_p would
	be called or not, so linux_make_mappings_callback had to run its own
	checks.

	Now that dump_note_entry_p is always called we can rely on that
	function to filter out which mappings should result in an NT_FILE
	entry, and linux_make_mappings_callback can just create an entry for
	everything it is passed.

	As a result of this change I was able to remove the inode argument
	from linux_make_mappings_callback and
	linux_find_memory_regions_thunk.  The inode check has now moved to
	dump_note_entry_p.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: always call should_dump_mapping_p during core file creation
	This commit moves the logic for whether should_dump_mapping_p is
	called out of linux_find_memory_regions_full and pushes it down into
	the two callback functions that are used as the should_dump_mapping_p
	callback; `dump_mapping_p` and `dump_note_entry_p`.

	Older Linux kernels don't make the 'Anonymous' information available
	in the smaps file, and currently, GDB handles this by not calling the
	should_dump_mapping_p callback in linux_find_memory_regions_full,
	instead the answer is hard-coded to true.

	This is (maybe) fine for dump_mapping_p, but for dump_note_entry_p,
	this choice makes little sense.  The dump_note_entry_p function
	doesn't even use the anonymous mapping information.

	I propose that the 'has_anonymous' check should be moved out of
	linux_find_memory_regions_full, and pushed into dump_mapping_p.  Then
	in dump_note_entry_p there will be no has_anonymous check; it just
	isn't needed.

	This allows linux_find_memory_regions_full to be simplified a little,
	and will allow some additional clean ups in
	linux_make_mappings_callback, which is the partner function to
	dump_note_entry_p (see linux_make_mappings_corefile_notes), now that
	we know dump_note_entry_p is always called.  This follow on clean up
	will be done in a later commit in this series.

	Looking at dump_mapping_p, I do wonder if the ::has_anonymous check
	could be moved later in the function.  The first few checks in
	dump_mapping_p don't rely on the anonymous information, so running
	them might give better results.  However, the lack of the anonymous
	information is only for older kernels, so testing any changes in this
	area would likely require spinning up an older kernel, and as the
	years pass, we likely care about this case less.  So for now I've left
	the ::has_anonymous check as the first thing in dump_mapping_p as this
	keeps the existing behaviour.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: pass struct smaps_data to linux_dump_mapping_p_ftype
	Simplify the argument passing in linux_find_memory_regions_full when
	calling the should_dump_mapping_p callback.  Instead of pulling all
	the components from the smaps_data object and passing them separately,
	just pass the smaps_data object.

	I think this change is justified on its own; the code seems cleaner,
	and easier to read to my eye.  But additionally, in a later commit in
	this series I want to pass smaps_data::has_anonymous to the
	should_dump_mapping_p callback, which would mean adding yet another
	argument, and I think the argument list is already long enough.
	Changing the function now to pass the smaps_data object means that I
	will already have the ::has_anonymous field available in the later
	commit.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: use bool more in linux-tdep.c
	Convert linux_dump_mapping_p_ftype to return a bool, and then update
	everything that is needed to handle the fallout from this change.

	There should be no user visible changes from this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: add '-stopped' and '-running' options to "info threads"
	Add two options to "info threads": `-stopped` and `-running`.

	The purpose of these options is to filter the output of the command.
	The `-stopped` option means "print stopped threads only" and,
	similarly, `-running` means "print the running threads only".  When
	both options are provided by the user, the indication is that the user
	wants the union.  That is, the output contains both stopped and
	running threads.

	Suppose we have an application with 5 threads, 2 of which have hit a
	breakpoint.  The "info threads" command in the non-stop mode gives:

	  (gdb) info threads
	    Id   Target Id             Frame
	  * 1    Thread 0x7ffff7d99740 (running)
	    2    Thread 0x7ffff7d98700 something () at file.c:30
	    3    Thread 0x7ffff7597700 (running)
	    4    Thread 0x7ffff6d96700 something () at file.c:30
	    5    Thread 0x7ffff6595700 (running)
	  (gdb)

	Using the "-stopped" flag, we get

	  (gdb) info threads -stopped
	    Id   Target Id             Frame
	    2    Thread 0x7ffff7d98700 something () at file.c:30
	    4    Thread 0x7ffff6d96700 something () at file.c:30
	  (gdb)

	Using the "-running" flag, we get

	  (gdb) info threads -running
	    Id   Target Id             Frame
	  * 1    Thread 0x7ffff7d99740 (running)
	    3    Thread 0x7ffff7597700 (running)
	    5    Thread 0x7ffff6595700 (running)
	  (gdb)

	Using both flags prints all:

	  (gdb) info threads -stopped -running
	    Id   Target Id             Frame
	  * 1    Thread 0x7ffff7d99740 (running)
	    2    Thread 0x7ffff7d98700 something () at file.c:30
	    3    Thread 0x7ffff7597700 (running)
	    4    Thread 0x7ffff6d96700 something () at file.c:30
	    5    Thread 0x7ffff6595700 (running)
	  (gdb)

	When combined with a thread ID, filtering applies to those threads that
	are matched by the ID.

	  (gdb) info threads 3
	    Id   Target Id             Frame
	    3    Thread 0x7ffff7597700 (running)
	  (gdb) info threads -stopped 3
	  No threads matched.
	  (gdb)

	Regression-tested on X86_64 Linux.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-by: Pedro Alves <pedro@palves.net

2025-05-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: update "info threads" output when no threads match the arguments
	If "info threads" is provided with the thread ID argument but no such
	threads matching the thread ID(s) are found, GDB prints

	  No threads match '<ID...>'.

	Update this output to the more generalized

	  No threads matched.

	The intention is that the next patch, and potentially future ones,
	will extend the command with more filter/match arguments.  We cannot
	customize the output to each such argument.  Hence, be more generic.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-by: Pedro Alves <pedro@palves.net

2025-05-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: pass info_threads_opts to print_thread_info_1
	The "info threads" command tracks its options in a struct named
	'info_threads_opts', which currently has only one option.  Pass the
	whole options object to helper functions, instead of passing
	the option value individually.  This is a refactoring to make adding
	more options easier.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-by: Pedro Alves <pedro@palves.net

2025-05-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-11  Alan Modra  <amodra@gmail.com>

	ubsan: size_inc_line_addr integer overflow
	Fix a fuzzer testcase where a large positive line_delta causes signed
	overflow when subtracting -5.  Signed overflow is perfectly OK here.

2025-05-11  Alan Modra  <amodra@gmail.com>

	msan: use of uninitialised data in get_cie_info
	This completely bogus oss-fuzz x86 testcase results in a read from an
	uninitialised (at the time check_eh_frame is called) part of an insn
	frag:
	 .section .debug_frame
	 orl $1,x
	 .long x
	 .uleb128 0,x,0
	x:

	Fix the problem by verifying the assumption in get_cie_info that a CIE
	starts at the beginning of .eh_frame or .debug_frame.  Or at least
	exclude silliness involving instructions placed there.  That seems a
	useful sanity check.  Also sanity check sizes of initial FDE fields.

	Yes, this doesn't completely stop the problem since you could place an
	insn with a relocated field later in the CIE.  If fuzzers find such a
	testcase I'll ignore it.

		* ehopt.c (struct cie_info): Add "f" field.
		(get_cie_info): Return a bool.  Verify frag at start of chain
		is one with the CIE size found by check_eh_frame.
		(check_eh_frame): Save CIE start frag.  Only accept 4 or 8
		byte fields in state_saw_size, state_saw_cie_offset and
		state_saw_pc_begin.  Formatting.  Localise "fix" variable.

2025-05-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-10  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: LoongArch: Emulate floating-point branch instructions
	Add bceqz and bcnez cases in loongarch_insn_is_cond_branch() and
	loongarch_next_pc() to emulate floating-point branch instructions.

	Here are the references:

	https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_bceqz_bcnez
	https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#table-table-of-instruction-encoding

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-05-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-10  Peter Bergner  <bergner@tenstorrent.com>

	MAINTAINERS: Update my email address
	Update my email address and move up Surya's name as the main PPC contact.

2025-05-09  Tom Tromey  <tromey@adacore.com>

	Fix two comments in cli-style.c
	I noticed that a couple of new comments in cli-style.c mentioned the
	wrong command name.  This patch fixes the comments.

	Move "show style sources" documentation
	I noticed that I had inadvertently put the "set style warning-prefix"
	documentation between the paragraph for "set style sources" and the
	paragraph for "show style sources".  This patch moves the latter up a
	bit to clean this up.

2025-05-09  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Mark predicate-as-counter pseudo instructions
	Using explicit pseudo aliases is clearer and more consistent with other
	instruction aliases.

	This does not change behaviour.  For the non-alias instructions
	(everything except mov) we already picked the first matching entry for
	disassembly by default.  For mov we picked the last matching aliased
	entry, which remained the original alias since do_misc_decoding doesn't
	recognise OP_MOV_PN_PN.

2025-05-09  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Mark clearbhb as a pseudo instruction
	This was an early name for the clrbhb hint instruction.  Some software
	was written with the old name before it was renamed, so we support it
	for assembly but should never use it in disassembly.

	This patch has no functional change, because we already pick (by
	default) the last matching alias in the opcode table, and clrbhb is
	listed later than clearbhb.

2025-05-09  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Merge dgh tests into system.d

	aarch64: Fix dgh disassembly

	aarch64: Mark SME mova aliases
	This will only change behaviour during disassembly with -M no-aliases.

	aarch64: Mark rev64 as a pseudo instruction
	This is more natural than raising the priority of rev with F_P1, and
	is functionally equivalent.

	aarch64: Add new test original-missing-misc.d
	This test file includes all the remaining untested instructions that
	weren't part of a larger group of new or existing tests.

	aarch64: Add new test mov-wide.d
	Only movn was previously untested.

	aarch64: Add new test exception-generation.d
	svc and dcps* were already tested, but are included here as part of the
	same encoding group.

	aarch64: Add new test conditional-compare.d
	The register form of ccmp was already tested.

	aarch64: Add new test branch-cond-pseudos.d
	beq, bne, bcs and bcc were already tested, and bge and ble are also used
	in scfi tests.

	aarch64: Add new test ldst-unpriv.d
	All instructions were previously untested.

	aarch64: Add new test ldst-extend-general.d
	All instructions were previously untested.

	aarch64: Add new test dp-general-two-source.d
	lsl was already tested but is included here as part of the same encoding
	group.

	aarch64: Add new test dp-general-one-source.d
	rev16 and the 64-bit rev/rev64 instructions were already tested, but are
	included here as part of the same encoding group.

	aarch64: Add new test addsub-carry.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-scalar-doubling-mul.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-scalar-two-reg-misc.d
	sqabs, sqneg, abs and neg were already tested, but are included here as
	part of the same encoding group.

	aarch64: Add new test advsimd-scalar-shift-immediate.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-scalar-three-same.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-copy.d
	Only smov and the second dup variant were previously untested.  However,
	the only test for umov was a disassembly test with -M no-aliases, and
	the first dup variant was only tested in assembly in diagnostic.d with
	the non-architectural syntax `dup v0.2d, v1.2d[0]`.

	aarch64: Add new test advsimd-permute.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-modified-immediate.d
	All instructions (7 opcode table entries) were previously untested.

	aarch64: Add new test advsimd-two-reg-misc-hilo.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-two-reg-misc.d
	sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was
	already assembled in an error test (sve-reg-diagnostic.d), but they are
	all included here as part of the same encoding group.

	aarch64: Add new test advsimd-mul-element.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-widening-narrowing.d
	All instructions were previously untested.

	aarch64: Add new test advsimd-three-same.d
	All instructions except orr/mov were previously untested.

	aarch64: Add missing widening fmops test
	Also remove the valid instructions from the test for invalid
	instructions - this meant that the instruction was previously being
	tested for assembly but not disassembly.

	aarch64: Add tests for fabd, urecpe and ursqrt
	Other instructions in the encoding group are tested in advsimd-fp16.d,
	so add these instructions to the existing test file.

	aarch64: Add tests for fcvt, fcvtzs and fcvtzu
	Other instructions in the encoding group are tested in float-fp16.d, so
	add these instructions to the existing test file.

	aarch64: Add tests for csdb and eret to system.d

	aarch64: Add test for ands and bics
	The other instructions in the encoding group are tested in shifted.d, so
	add these to the existing test file.

	aarch64: Adjust float-fp16.d test patterns
	Adjust the test to match instruction addresses of any length.

	aarch64: Adjust advsimd-fp16.d test patterns
	Adjust the test to match instruction addresses of any length, and escape
	literal '.' characters for a stricter match.

	aarch64: Adjust shifted.d test patterns
	Adjust the test to match any instruction addresses, so that the test can
	be extended more easily.

	aarch64: Eliminate AARCH64_OPND_SVE_ADDR_R
	Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept
	implicit XZR offsets.  Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands
	to support instructions where an XZR offset is allowed but must be
	specified explicitly.  This allows the removal of the duplicate opcode
	table entries using AARCH64_OPND_SVE_ADDR_R.

2025-05-09  Alice Carlotti  <alice.carlotti@arm.com>

	aarch64: Disallow invalid SVE addressing modes
	The fix for PR22988 in 2018 added a new operand AARCH64_OPND_SVE_ADDR_R
	to support implicit XZR offsets, but this fix had several flaws that
	meant it accepted several invalid addressing modes:

	1. The base register type wasn't properly checked when the optional
	register offset was omitted.  This meant that
	  ldff1b {z1.s}, p1/z,[z1.d]
	was parsed as if it were
	  ldff1b z1.d, p1/z, [x1.d, xzr].

	2. The explicit offset parsing didn't include a shift type, so the new
	operand would incorrectly parse
	  ldff1h{z0.s}, p0/z, [x0, x0]
	as if it were
	  ldff1h{z0.s}, p0/z, [x0, x0, lsl #1].

	3. Regardless of the above correctness issues, support for implicit
	offsets should have been added by amending the operands in the existing
	opcode table entries, instead of adding new duplicate table entires.

	Issue 1 can be fixed by using an "if" instead of an "else if" in
	parse_operands, while issue 2 can be fixed by failing when the first
	condition is false.  This patch applies just these two fixes, leaving
	issue 3 to be addressed in a subsequent more invasive patch.

	The instructions removed from the test sme-5.d are architecturally
	invalid. The new tests cover all of the affected ldff1 variants; the
	issue also affected SME ZA ld1*/st1* instructions using the same operand
	type.

2025-05-09  Jerry Zhang Jian  <jerry.zhangjian@sifive.com>
	    Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Support Zce 1.0
	Zce is the extension defined in code-size-reduction

	Ref: https://github.com/riscvarchive/riscv-code-size-reduction

2025-05-09  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Base for complex extension implications
	Thanks to the commit 48558a5e5471 ("RISC-V: Allow nested implications for
	extensions"), we can write complex extension implications in theory.
	However, to actually do that, we need to pass more information to
	check_func.

	For example, we want to imply 'Zcf' from 'F' if and only if the 'Zce'
	extension is also enabled and XLEN is 32.  Passing rps is a way to
	enable this.

	This commit prepares for such complex extension implications.

2025-05-09  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add augmented hypervisor extension 'sha' support.
	The augmented hypervisor extension 'sha'[1] is a new profile-defined extension
	that captures the full set of features that are mandated to be supported along
	with the H extension.

	https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile

	bfd/ChangeLog:

			* elfxx-riscv.c: New extension and implies.

	gas/ChangeLog:

			* NEWS: New extension.
			* testsuite/gas/riscv/imply.d: New test for sha.
			* testsuite/gas/riscv/imply.s: Ditto.
			* testsuite/gas/riscv/march-help.l: New extension.

2025-05-09  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Privileged Architecture 1.13 CSRs.
	This patch support RISC-V Privileged Architecture 1.13 CSRs 'medelegh' and
	'hedelegh'. More details between 1.12 and 1.13 see [1].

	[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/priv-preface.adoc

	Version log: Remove gas/po changes.

	bfd/ChangeLog:

	        * cpu-riscv.c: New option.
	        * cpu-riscv.h (enum riscv_spec_class): Ditto.

	binutils/ChangeLog:

	        * doc/binutils.texi: New option.

	gas/ChangeLog:

	        * NEWS: Add priv-1.13 support.
	        * config/tc-riscv.c: New option.
	        * configure: Ditto.
	        * configure.ac: Ditto.
	        * testsuite/gas/riscv/csr-version-1p10.d: New CSR.
	        * testsuite/gas/riscv/csr-version-1p10.l: New warning.
	        * testsuite/gas/riscv/csr-version-1p11.d: New CSR.
	        * testsuite/gas/riscv/csr-version-1p11.l: New warning.
	        * testsuite/gas/riscv/csr-version-1p12.d: New CSR.
	        * testsuite/gas/riscv/csr-version-1p12.l: New warning.
	        * testsuite/gas/riscv/csr.s: New CSR.
	        * testsuite/gas/riscv/attribute-15.d: New test.
	        * testsuite/gas/riscv/attribute-16.d: New test.
	        * testsuite/gas/riscv/csr-version-1p13.d: New test.
	        * testsuite/gas/riscv/csr-version-1p13.l: New test.

	include/ChangeLog:

	        * opcode/riscv-opc.h (CSR_MEDELEGH): New CSR.
	        (CSR_HEDELEGH): Ditto.
	        (DECLARE_CSR): Ditto.

2025-05-09  Chao-ying Fu  <cfu@wavecomp.com>

	RISC-V: Added vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp
	Spec:
	https://mips.com/wp-content/uploads/2025/03/P8700-F_Programmers_Reference_Manual_Rev1.82_3-19-2025.pdf

	Added MIPS vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp
	with verison 1.0.

	Passed binutils testsuites of targets elf32/elf64/linux32/linux64.

2025-05-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-08  Tom Tromey  <tom@tromey.com>

	Change substitute_path_component to use std::string
	This changes substitute_path_component to use std::string and
	std::string_view, simplifying it greatly and removing some manual
	memory management.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-08  Tom Tromey  <tom@tromey.com>

	Move substitute_path_component
	This moves substitute_path_component out of utils.c.  I considered
	making a new file for this (still could if someone wants that), but
	since the only caller is in auto-load.c, I moved it there instead.

	I've also moved the tests into auto-load.c as well.  This way
	substitute_path_component can be static.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-08  Alan Modra  <amodra@gmail.com>

	windres: buffer overflow
	bin_to_res_menuexitems can be called with random data offsets (and thus
	remaining lengths), confusing code that expects 4-byte aligned data.
	Prevent an item length adjustment for alignment exceeding the
	remaining length and then overflowing.

	Remove unnecessary use of pragma once in pr25618 test

2025-05-07  Jens Remus  <jremus@linux.ibm.com>

	s390: Fix format specifier for VR in disassembler
	Vector register (VR) numbers are unsigned.  Use format specifier %u
	instead of %i.

	Reported-by: Florian Krohm <flo2030@eich-krohm.de>

2025-05-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-06  Tom Tromey  <tom@tromey.com>

	Do not set yydebug in cp-name-parser.y
	This reverts the change to cp-name-parser.y, avoiding a TSan report.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-05-06  Tom Tromey  <tom@tromey.com>

	Remove kfail from templates.exp
	templates.exp has one remaining kfail.  However, the output in
	question has been stabilized ever since the cp-name-parser.y work --
	the test just wasn't updated.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8617
	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-05-06  Tom Tromey  <tom@tromey.com>

	Rewrite bug references in templates.exp
	templates.exp has many kfails that refer to old GNATS bug numbers.
	This patch updates them to refer to Bugzilla instead.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-05-06  Andrew Burgess  <aburgess@redhat.com>

	Revert "gdb: support zero inode in generate-core-file command"
	This reverts commit 1e21c846c275fc6e387ca903a129096be2a53d0b.

	This change was causing unexpected mappings to be included in the core
	files generated by GDB, which was triggering warnings when GDB opened
	a core file, like this:

	  warning: Can't open file [stack] during file-backed mapping note processing

	  warning: Can't open file [vvar] during file-backed mapping note processing

	For now I'm reverting the above commit and will come to the list again
	when I have a solution that addresses the original issue without also
	including the unexpected mappings.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Handle field with dynamic bit offset
	I discovered that GCC emitted incorrect DWARF for the test case
	included in this patch.  Eric wrote a fix for GCC, but then he found
	that gdb crashed on the resulting file.

	This test has a field that is at a non-constant bit offset from the
	start of the type.  DWARF 5 does not allow for this situation (I've
	sent a report to the DWARF list), but DWARF 3 did allow for this via a
	combination of an expression for the byte offset and then the use of
	DW_AT_bit_offset.  This looks like:

	 <5><117a>: Abbrev Number: 17 (DW_TAG_member)
	    <117b>   DW_AT_name        : (indirect string, offset: 0x1959): another_field
	...
	    <1188>   DW_AT_bit_offset  : 6
	    <1189>   DW_AT_data_member_location: 6 byte block: 99 3d 1 0 0 22 	(DW_OP_call4: <0x1193>; DW_OP_plus)
	...
	 <3><1193>: Abbrev Number: 2 (DW_TAG_dwarf_procedure)
	    <1194>   DW_AT_location    : 15 byte block: 97 94 1 37 1a 32 1e 23 7 38 1b 31 1c 23 3 	(DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_lit7; DW_OP_and; DW_OP_lit2; DW_OP_mul; DW_OP_plus_uconst: 7; DW_OP_lit8; DW_OP_div; DW_OP_lit1; DW_OP_minus; DW_OP_plus_uconst: 3)

	Now, that combination is not fully general, in that the bit offset
	must be a constant -- only the byte offset may really vary.  However,
	I couldn't come up with a situation where full generality is needed,
	mainly because GNAT won't seem to pack fields into the padding of a
	variable-length array.

	Meanwhile, the reason for the gdb crash is that the code handling
	DW_AT_bit_offset assumes that the byte offset is a constant.  This
	causes an assertion failure.

	This patch arranges for DW_AT_bit_offset to be applied during field
	resolution, when needed.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Introduce apply_bit_offset_to_field helper function
	This patch makes a new function, apply_bit_offset_to_field, that is
	used to handle the logic of DW_AT_bit_offset.  Currently there is just
	a single caller, but the next patch will change this.

	Use OBSTACK_ZALLOC when allocating batons
	I found some places in dwarf2/read.c that allocate a location baton,
	but fail to initialize one of the fields.  It seems safer to me to use
	OBSTACK_ZALLOC here, so this patch makes this change.  This will be
	useful in a subsequent patch as well, where a new field is added to
	one of the batons.

	Clean up handle_member_location
	This removes a redundant check from handle_member_location, and also
	changes the complaint -- currently it will issue the "complex
	location" complaint, but really what is happening here is an
	unrecognized form.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Handle dynamic field properties
	I found a situation where gdb could not properly decode an Ada type.
	In this first scenario, the discriminant of a type is a bit-field.
	PROP_ADDR_OFFSET does not handle this situation, because it only
	allows an offset -- not a bit-size.

	My original approach to this just added a bit size as well, but after
	some discussion with Eric Botcazou, we found another failing case: a
	tagged type can have a second discriminant that appears at a variable
	offset.

	So, this patch changes this code to accept a general 'struct field'
	instead of trying to replicate the field-finding machinery by itself.

	This is handled at property-evaluation time by simply using a 'field'
	and resolving its dynamic properties.  Then the usual field-extraction
	function is called to get the value.

	Because the baton now just holds a field, I renamed PROP_ADDR_OFFSET
	to PROP_FIELD.

	The DWARF reader now defers filling in the property baton until the
	fields have been attached to the type.

	Finally, I noticed that if the discriminant field has a biased
	representation, then unpack_field_as_long would not handle this
	either.  This bug is also fixed here, and the test case checks this.

	Regression tested on x86-64 Fedora 41.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Add new unpack_field_as_long overload
	This introduces a new unpack_field_as_long that takes the field object
	directly, rather than a type and an index.  This will be used in the
	next patch.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Add resolve_dynamic_field
	The final patch in this series will change one dynamic property
	approach to use a struct field rather than an offset and a field type.
	This is convenient because the reference in DWARF is indeed to a field
	-- and this approach lets us reuse the field-extraction logic that
	already exists in gdb.

	However, the field in question may have dynamic properties which must
	be resolved before it can be used.  This patch prepares for this by
	introducing a separate resolve_dynamic_field function.

	This patch should cause no visible changes to behavior.

2025-05-06  Tom Tromey  <tromey@adacore.com>

	Constify property_addr_info
	This changes most places to use a const property_addr_info.  This
	seems more correct to me because normally the user of a
	property_addr_info should not modify it.  Furthermore, some functions
	already take a const object, and for a subsequent patch it is
	convenient if other functions do as well.

2025-05-06  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: Add require allow_hipcc_tests in gdb.rocm/mi-attach.exp
	The gdb.rocm/mi-attach.exp test is missing a proper `require` check to
	ensure that the current configuration can run ROCm tests.  This issue
	has been reported by Baris.

	This patch adds the missing `allow_hipcc_tests` requirement, and also
	adds `load_lib rocm.exp` to enable this test.

	Change-Id: Ie136adfc2d0854268b92af5c4df2dd0334dce259
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: support zero inode in generate-core-file command
	It is possible, when creating a shared memory segment (i.e. with
	shmget), that the id of the segment will be zero.

	When looking at the segment in /proc/PID/smaps, the inode field of the
	entry holds the shared memory segment id.

	And so, it can be the case that an entry (in the smaps file) will have
	an inode of zero.

	When GDB generates a core file, with the generate-core-file (or its
	gcore alias) command, the shared memory segment should be written into
	the core file.

	Fedora GDB has, since 2008, carried a patch that tests this case.
	There is no fix for GDB associated with the test, and unfortunately,
	the motivation for the test has been lost to the mists of time.  This
	likely means that a fix was merged upstream without a suitable test,
	but I've not been able to find and relevant commit.  The test seems to
	be checking that the shared memory segment with id zero, is being
	written to the core file.

	While looking at this test and trying to work out if it should be
	posted upstream, I saw that GDB does appear to write the shared memory
	segment into the core file (as expected), which is good.  However, GDB
	still isn't getting this case exactly right.

	In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via
	the gdbarch_find_memory_regions call) to correctly write the shared
	memory segment into the core file, however, in
	linux_make_mappings_corefile_notes, when we use
	linux_find_memory_regions_full to create the NT_FILE note, we call
	back into linux_make_mappings_callback for each mapping, and in here
	we reject any mapping with a zero inode.

	The result of this, is that, for a shared memory segment with a
	non-zero id, after loading the core file, the shared memory segment
	will appear in the 'proc info mappings' output.  But, for a shared
	memory segment with a zero id, the segment will not appear in the
	'proc info mappings' output.

	I propose fixing this by not checking the inode in
	linux_make_mappings_callback.  The inode check was in place since the
	code was originally added in commit 451b7c33cb3c9ec6272c36870 (in
	2012).

	The test for this bug, based on the original Fedora patch, can be
	found on the mailing list here:

	  https://inbox.sourceware.org/gdb-patches/0d389b435cbb0924335adbc9eba6cf30b4a2c4ee.1741776651.git.aburgess@redhat.com

	I have not committed this test into the tree though because the test
	was just too unreliable.  User space doesn't have any control over the
	shared memory id, so all we can do is spam out requests for new shared
	memory segments and hope that we eventually get the zero id.

	Obviously, this can fail; the zero id might already be in use by some
	long running process, or the kernel, for whatever reason, might choose
	to never allocate the zero id.  The test I posted (see above thread)
	did work more than 50% of the time, but it was far closer to a 50%
	success rate than 100%, and I really don't like introducing unreliable
	tests.

2025-05-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add gcore_cmd_available predicate proc
	Add a new gcore_cmd_available predicate proc that can be used in a
	'requires' line, and make use of it in a few tests.

	All of the tests I have modified call gdb_gcore_cmd as one of their
	first actions and exit if the gcore command is not available, so it
	makes sense (I think) to move the gcore command check into a requires
	call.

	There should be no change in what is actually run after this commit.

2025-05-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python/guile: check if styling is disabled in Color.escape_sequence
	I noticed that the gdb.Color.escape_sequence() method would produce an
	escape sequence even when styling is disabled.

	I think this is the wrong choice.  Ideally, when styling is
	disabled (e.g. with 'set style enabled off'), GDB should not be
	producing styled output.

	If a GDB extension is using gdb.Color to apply styling to the output,
	then currently, the extension should be checking 'show style enabled'
	any time Color.escape_sequence() is used.  This means lots of code
	duplication, and the possibility that some locations will be missed,
	which means disabling styling no longer does what it says.

	I propose that Color.escape_sequence() should return the empty string
	if styling is disabled.  A Python extension can then do:

	  python
	  c_none = gdb.Color('none')
	  c_red = gdb.Color('red')
	  print(c_red.escape_sequence(True)
	        + "Text in red."
	        + c_none.escape_sequence(True))
	  end

	If styling is enable this will print some red text.  And if styling is
	disabled, then it will print text in the terminal's default color.

	I have applied the same fix to the guile API.

	I have extended the tests to cover this case.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-06  Alan Modra  <amodra@gmail.com>

	gas: input_scrub buffers
	This tidies freeing of input_scrub buffers on failure paths, making
	input_scrub_end iterate over any input_scrub_push'd files or string
	buffers to clean up memory.

		* input-scrub.c (input_scrub_free): New function.
		(input_scrub_pop): Call it rather than input_scrub_end.
		(input_scrub_end): Iterate over next_saved_file freeing
		buffers.
		(input_scrub_next_buffer): Move sb_kill to input_scrub_free.

2025-05-06  Alan Modra  <amodra@gmail.com>

	windres_get_* functions
	windres_get_32 and similar have a length parameter that in most cases
	is just the required length, so it is redundant.  The few cases where
	a variable length is passed are all in resrc.c.  So, get rid of the
	length parameter and introduce wrappers in resrc.c to check the
	length.

2025-05-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-05  Tom Tromey  <tromey@adacore.com>

	Fix sign of Ada rational constants
	My earlier patch commit 0c03db90 ("Use correct sign in get_mpz") was
	(very) incorrect.  It changed get_mpz to check for a strict sign when
	examining part of an Ada rational constant.  However, in Ada the
	"delta" for a fixed-point type must be positive, and so the components
	of the rational representation will be positive.

	This patch corrects the error.  It also renames the get_mpz function,
	in case anyone is tempted to reuse this code for another purpose.

	Finally, this pulls over the test from the internal AdaCore test suite
	that found this issue.

2025-05-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove unused functions, duplicate macros
	class Reloc is not used after commit
	13f614be23a gprofng: Refactor readSymSec for using BFD's asymbol struct

	Many common macros were defined in different sources.
	Sometimes a macro was used, sometimes a macros value was used.
	Removed unused macros and include files.

	gprofng/ChangeLog
	2025-05-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* common/gp-experiment.h: Define variables that are passed to
		libcollector. Remove unused macros.
		* libcollector/collector.c: Cleanup macros.
		* libcollector/descendants.h: Likewise.
		* libcollector/envmgmt.c: Likewise.
		* libcollector/linetrace.c: Likewise.
		* src/collect.h: Likewise.
		* src/envsets.cc: Likewise.
		* src/gp-collect-app.cc: Likewise.
		* src/Stabs.cc: Remove class Reloc.
		* src/Stabs.h: Likewise.
		* src/ipcio.cc: Remove unused include files.

2025-05-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix 32892 source line level information not available with "-g -O2"
	gprofng ignored DW_AT_specification.
	As a result, gprofng skiped Dwarf for all functions declared as:
	  < 2>:<0x0000f725> DW_TAG_subprogram(46)
	      DW_AT_linkage_name(110)     "func_name"
	      DW_AT_declaration*(60)      0x1 (1)
	  < 1>:<0x00015acc> DW_TAG_subprogram(46)
	       DW_AT_specification(71)    0xf725 (63269)

	Another problem was that gprofng ignored DW_AT_ranges.
	As a result, many functions are mapped to the <Unknown> module.

	gprofng/ChangeLog
	2025-05-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32892
		* src/Dwarf.cc: Handle DW_AT_specification and DW_AT_ranges.
		* src/DwarfLib.cc: Likewise.
		* src/DwarfLib.h: Likewise.
		* src/Dwarf.h (get_ranges): New function.
		* src/Stabs.h (get_symbols): New function.
		* src/Stabs.cc: Move Symbol class to src/Symbol.cc.
		* src/Symbol.cc: New file.
		* src/Symbol.h: New file.
		* src/Makefile.am: Add Symbol.cc in build.
		* src/Makefile.in: Rebuild.
		* src/LoadObject.cc (dump_functions): Improve output for -dfunc option.

2025-05-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.tui/tui-layout-asm.exp
	On x86_64-cygwin, with test-case gdb.tui/tui-layout-asm.exp I run into:
	...
	WARNING: The following failure is probably due to the TUI window
	         width.  See the comments in the test script for more
	         details.
	FAIL: $exp: scroll to end of assembler (scroll failed)
	...

	The problem is as follows.

	On the TUI screen, we have:
	1 | 0x1004010ff <__gdb_set_unbuffered_output+95> nop                         |
	2 | 0x100401100 <__cxa_atexit>                   jmp *0x6fc2(%rip) # 0x10040 |
	...

	We send the down key, which should have the effect of scrolling up.  So, we
	expect that the second line moves to the first line.

	That seems to be the case indeed:
	...
	1 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x1004080c8 <__imp___cxa_ |
	...
	but the line has changed somewhat, so the matching fails.

	We could increase the width of the screen, as suggested in the test-case, but
	I think that approach is fragile.

	Instead, fix this by relaxing the matching: just check that the line before
	scrolling is fully contained in the line after scrolling, or the other way
	around.

	Doing so gets us the next failure:
	...
	FAIL: $exp: scroll to end of assembler (too much assembler)
	...

	The test-case states:
	...
	    if { $down_count > 250 } {
		# Maybe we should accept this as a pass in case a target
		# really does have loads of assembler to scroll through.
		fail "$testname (too much assembler)"
	...
	and I agree, so fix this by issuing a pass.

	This results in the test-case taking ~20 seconds, so reduce the maximum number
	of scrolls from 250 to 25, bringing that down to ~10 seconds.

	Tested on x86_64-cygwin and x86_64-linux.

	PR testsuite/32898
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32898

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Throw DWARF error on out-of-bounds DW_FORM_strx
	With the test-case contained in the patch, and gdb build with
	-fsanitize=address we get:
	...
	==23678==ERROR: AddressSanitizer: heap-buffer-overflow ...^M
	READ of size 1 at 0x6020000c30dc thread T3^[[1m^[[0m^M
	ptype global_var^M
	    #0 0x2c6a40b in bfd_getl32 bfd/libbfd.c:846^M
	    #1 0x168f96c in read_str_index gdb/dwarf2/read.c:15349^M
	...

	The executable contains an out-of-bounds DW_FORM_strx attribute:
	...
	$ readelf -wi $exec
	<2eb>   DW_AT_name        :readelf: Warning: string index of 1 converts to \
	  an offset of 0xc which is too big for section .debug_str
	 (indexed string: 0x1): <string index too big>
	...
	and read_str_index doesn't check for this:
	...
	  info_ptr = (str_offsets_section->buffer
		      + str_offsets_base
		      + str_index * offset_size);
	   if (offset_size == 4)
	     str_offset = bfd_get_32 (abfd, info_ptr);
	...
	and consequently reads out-of-bounds.

	Fix this in read_str_index by checking for the out-of-bounds condition and
	throwing a DWARF error:
	...
	(gdb) ptype global_var
	DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \
	  outside of .debug_str_offsets section in CU at offset 0x2d7 \
	  [in module dw-form-strx-out-of-bounds]
	No symbol "global_var" in current context.
	(gdb)
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/dw-form-strx.exp
	Add a test-case using DW_FORM_strx.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Reimplement phex and phex_nz as templates
	Gdbsupport functions phex and phex_nz have a parameter sizeof_l:
	...
	extern const char *phex (ULONGEST l, int sizeof_l);
	extern const char *phex_nz (ULONGEST l, int sizeof_l);
	...
	and a lot of calls use:
	...
	  phex (l, sizeof (l))
	...

	Make this easier by reimplementing the functions as a template, allowing us to
	simply write:
	...
	  phex (l)
	...

	Simplify existing code using:
	...
	$ find gdb* -type f \
	    | xargs sed -i 's/phex (\([^,]*\), sizeof (\1))/phex (\1)/'
	$ find gdb* -type f \
	    | xargs sed -i 's/phex_nz (\([^,]*\), sizeof (\1))/phex_nz (\1)/'
	...
	and manually review:
	...
	$ find gdb* -type f | xargs grep "phex (.*, sizeof.*)"
	$ find gdb* -type f | xargs grep "phex_nz (.*, sizeof.*)"
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-02  Tom Tromey  <tromey@adacore.com>

	Use emoji to indicate errors and warnings
	This patch adds, at long last, some emoji output to gdb.  In
	particular, warnings are indicated with the U+26A0 (WARNING SIGN), and
	errors with U+274C (CROSS MARK).

	There is a new setting to control whether emoji output can be used.
	It defaults to "auto", which means emoji will be used if the host
	charset is UTF-8.  Note that disabling styling will also disable
	emoji, handy for traditionalists.

	I've refactored mingw console output a little, so that emoji will not
	be printed to the console.  Note the previous code here was a bit
	strange in that it assumed that the first use of gdb_console_fputs
	would be to stdout.

	This version lets the user control the prefixes directly, so different
	emoji can be chosen if desired.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-02  Chris Packham  <judge.packham@gmail.com>

	readline/tcap.h: Update definitions for C23
	C23 changes how function definitions like int `int tputs ()` are
	interpreted. In older standards this meant that the function arguments
	are unknown. In C23 this is interpreted as `int tputs (void)` so now
	when we compile with GCC15 (which defaults to -std=gnu23) we get an
	error such as

	  readline/display.c:2839:17: error: too many arguments to function 'tputs'; expected 0, have 3

	Add the function arguments for tgetent(), tgetflag(), tgetnum(),
	tgetstr(), tputs() and tgoto().

	Approved-By: Tom Tromey <tom@tromey.com>

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.reverse/time-reverse.exp timeout
	After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with
	test-case gdb.reverse/time-reverse.exp I run into:
	...
	(gdb) continue^M
	Continuing.^M
	FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout)
	...

	The problem is that instruction stepping gets stuck in a loop with this call
	stack: time -> __GI___clock_gettime -> __kernel_clock_gettime ->
	__cvdso_clock_gettime.

	This is not specific to fsanitize=thread, it just makes gdb slow, which makes
	instruction stepping slow, which results in the application getting stuck.

	I ran into this as well with a regular gdb build on a 32-bit i686 laptop with
	1GB of memory, an inherently slow setup.  In that instance, I was able to
	observe that the loop we're stuck in is the outer loop in do_coarse in linux
	kernel source lib/vdso/gettimeofday.c.

	Fix this by setting "record full insn-number-max" to 2000, and handling
	running into the limit.

	Initially I tried the approach of using "stepi 2000" instead of continue, but
	that made the issue more likely to show up (for instance, I observed it after
	building gdb with -O0 on aarch64-linux).

	Tested on aarch64-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

	PR testsuite/32678
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.reverse/time-reverse.exp more robust
	I noticed that test-case gdb.reverse/time-reverse.exp contains:
	...
	    if [supports_process_record] {
	        # Activate process record/replay
	        gdb_test_no_output "record" "turn on process record"
	...

	So I tried out forcing supports_process_record to 0, and got:
	...
	FAIL: gdb.reverse/time-reverse.exp: mode=syscall: info record
	FAIL: gdb.reverse/time-reverse.exp: mode=syscall: reverse to marker1
	FAIL: gdb.reverse/time-reverse.exp: mode=syscall: check time record
	FAIL: gdb.reverse/time-reverse.exp: mode=c: info record
	FAIL: gdb.reverse/time-reverse.exp: mode=c: reverse to marker1
	FAIL: gdb.reverse/time-reverse.exp: mode=c: check time record
	...

	Fix this by requiring supports_process_record alongside supports_reverse.

	I also noticed when running make-check-all.sh that there were a lot of failures
	with target board dwarf5-fission-debug-types.

	Fix this by not ignoring the result of "runto marker1".

	Then I noticed that $srcfile is used as a regexp.  Fix this by applying
	string_to_regexp.

	Tested on x86_64-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-05-02  Tom Tromey  <tromey@adacore.com>

	Minor changes to Ada tests for gnat-llvm
	I found a few more spots where a minor modification to a test lets it
	pass with gnat-llvm:

	* For array_subcript_addr, gnat-llvm was not putting the array into
	  memory.  Making the array larger works around this.

	* For bp_inlined_func, it is normal for gnat-llvm to sometimes emit a
	  call to an out-of-line copy of the function, so accept this.

	* For null_overload and type-tick-size, I've applied the usual fix for
	  keeping an unused local variable alive.

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.threads/inf-thr-count.exp more readable
	While investigating a timeout in gdb.threads/inf-thr-count.exp I noticed that
	it uses quite some escaping, resulting in hard-to-parse regexps like
	"\\\$$::decimal".

	Fix this by reducing the escaping using:
	- quoting strings using {} instead of "", and
	- string_to_regexp.

	Also use multi_line to split up long multi-line regexps.

	Tested on x86_64-linux.

2025-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.threads/inf-thr-count.exp
	With test-case gdb.threads/inf-thr-count.exp, check-readmore and
	READMORE_SLEEP=1000 I run into:
	...
	(gdb) set variable spin = 0^M
	(gdb) ^M
	Thread 1 "inf-thr-count" hit Breakpoint 2, breakpt () at /data/vries/gdb/src/gdb/testsuite/gdb.threads/inf-thr-count.c:49^M
	49      }^M
	FAIL: gdb.threads/inf-thr-count.exp: set 'spin' flag to allow main thread to exit (timeout)
	PASS: gdb.threads/inf-thr-count.exp: wait for main thread to stop
	...

	Fix this by using -no-prompt-anchor.

	Tested on x86_64-linux.

2025-05-02  Jan Beulich  <jbeulich@suse.com>

	aarch64: drop stray newlines
	as_bad() already emits a newline; having extra ones leads to somewhat
	distorted diagnostics.

	arm: drop stray newlines
	Both as_bad() and as_warn() already emit a newline; having extra ones
	leads to somewhat distorted diagnostics.

	COFF: correct function auxiliary symbol data clearing
	It's unclear why the array part of the union was used there, when we're
	dealing with a function. Originally, when 32-bit hosts and targets were
	prevailing, the memset() in question ended up clearing the entire x_fcn,
	while for 64-bit hosts/targets only x_lnnoptr would have been cleared.
	Then a2c7ca15a560 ("Use stdint types in coff internal_auxent") made
	things consistent, but imo in the wrong direction (and likely
	unintentionally). Go back to what apparently was meant originally, using
	the correct part of the union now.

2025-05-02  Jan Beulich  <jbeulich@suse.com>

	COFF: function auxiliary symbols
	For one at least x86 gcc emits .def/.endef for functions, but no 2nd
	pair to designate their ends (sizes). While we can't recover the sizes,
	we can at least properly establish the chain of function symbols, which
	of course requires to emit auxiliary symbols for every function symbol
	even when there's no C_EFCN: We simply shouldn't be making their
	insertion conditional upon there not being a function processing of
	which is "in progress".

	In fact it was wrong to assign dual purpose to {,next_}set_end:
	Functions don't have "ends" set, but links to the next one. The same
	symbol table entry can serve both as an end marker and be a part of the
	chain of (defined) functions; this can't be expressed by a single static
	variable. Use what (again) becomes last_functionP for this purpose,
	along with tracking what symbol C_EFCN should apply to.

	This then allows to undo exposing of the respective (supposedly static)
	tracking variable, which PPC's XCOFF handling had introduced. Also
	rename it back to what it was before its exposure.

	For now the new testcases are XFAIL for Arm64 since there, unlike for
	Arm32, mapping symbols are emitted for COFF, too.

2025-05-02  Jan Beulich  <jbeulich@suse.com>

	gas: add new COFF-specific subdir in testsuite
	... and move the cofftag testcase there (from all/). Just like we have
	one for ELF.

	Arm/COFF: accept .def outside of CCS mode
	There's no reason to reject this common COFF directive when it doesn't
	have any other meaning.

2025-05-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-05-01  Alan Modra  <amodra@gmail.com>

	asan: null pointer as arg 2 of memcpy
	Replace xmalloc+memcpy+free with xrealloc, avoiding the asan warning
	on the initial allocation where we had memcpy(p,0,0).

		* cg_arcs.c (arc_add): Use xrealloc.

2025-05-01  H.J. Lu  <hjl.tools@gmail.com>

	dwarf: Properly check holes in .debug_ranges/debug_rnglists
	Don't warn if the offset of the first entry in .debug_rnglists starts
	right after the header.  Warn holes in .debug_ranges and debug_rnglists
	sections only if the last end pointer isn't the same as the current
	start pointer.

		PR binutils/32927
		* dwarf.c (display_debug_ranges_list): Return the pointer to the
		end.
		(display_debug_ranges): Don't warn if the offset of the first
		entry in .debug_rnglists starts right after the header.  Warn a
		hole only if the last end pointer is the same as the next pointer.
		* testsuite/binutils-all/x86-64/dwarf4.s: New file.
		* testsuite/binutils-all/x86-64/dwarf5.s: Likewise.
		* testsuite/binutils-all/x86-64/pr32927-1.d: Likewise.
		* testsuite/binutils-all/x86-64/pr32927-2.d: Likewise.

	Co-Authored-By: Alan Modra <amodra@gmail.com>

2025-05-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-30  Guinevere Larsen  <guinevere@redhat.com>

	gdb/progspace: fix formatting issue
	The previous commit had a small styling issue that I forgot to fix
	before pushing. This commit fixes the styling issue.

2025-04-30  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Stop exec_close looking like a UAF weakness
	A recent static analyzer run flagged that program_space::exec_close
	could be using a pointer after it has been freed. This is not true, as
	the pointer is never dereferenced, the address is used for comparisons.

	However, to avoid false positives from static analyzers (or bogus
	security bugs), this commit makes the code stop looking like a UAF by
	moving the unique_ptr into a local unique_ptr, so that there is no way
	someone would think memory could be used after being freed.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't compile read1.so with -fsanitize
	After building gdb with:
	...
	CFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread -fno-exceptions
	CXXFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread
	...
	when doing:
	...
	$ cd build/gdb
	$ make check-read1 RUNTESTFLAGS=gdb.threads/clone-attach-detach.exp
	...
	I run into:
	...
	Running /data/vries/gdb/src/gdb/testsuite/gdb.threads/clone-attach-detach.exp ...
	ThreadSanitizer:DEADLYSIGNAL
	==4799==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 \
	  (pc 0x7f636029a947 bp 0x7f635dfbf090 sp 0x7f635dfbf028 T4824)
	==4799==The signal is caused by a READ memory access.
	==4799==Hint: address points to the zero page.
	ThreadSanitizer:DEADLYSIGNAL
	ThreadSanitizer: nested bug in the same thread, aborting.
	...

	This doesn't happen when doing the same from build/gdb/testsuite, because
	CFLAGS doesn't get propagated from build/gdb.

	I'm not sure what is the root cause here, but when building with
	-fsanitize, I'm interested in running the sanitizer on gdb, not on testsuite
	utility libraries that are used with expect.

	Fix this by skipping -fsanitize when compiling read1.so and readmore.so.

	Tested on x86_64-linux, by rebuilding read1.so and running the test-case.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle asm frame in gdb.python/py-missing-objfile.exp
	On arm-linux, with test-case gdb.python/py-missing-objfile.exp I get:
	...
	(gdb) whatis global_exec_var^M
	type = volatile exec_type^M
	(gdb) FAIL: $exp: initial sanity check: whatis global_exec_var
	...
	instead of the expected "type = volatile struct exec_type".

	The problem is that the current language is ASM instead of C, because the
	inner frame at the point of the core dump has language ASM:
	...
	 #0  __libc_do_syscall () at libc-do-syscall.S:47
	 #1  0xf7882920 in __pthread_kill_implementation () at pthread_kill.c:43
	 #2  0xf784df22 in __GI_raise (sig=sig@entry=6) at raise.c:26
	 #3  0xf783f03e in __GI_abort () at abort.c:73
	 #4  0x009b0538 in dump_core () at py-missing-objfile.c:34
	 #5  0x009b0598 in main () at py-missing-objfile.c:46
	...

	Fix this by manually setting the language to C.

	Tested on arm-linux and x86_64-linux.

	PR testsuite/32445
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32445

2025-04-30  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix Wformat errors in gdb/riscv-tdep.c
	When building gdb with --enable-targets=all on arm-linux, I run into:
	...
	gdb/riscv-tdep.c: In function ‘bool try_read(regcache*, int, ULONGEST&)’:
	gdb/riscv-tdep.c:4887:18: error: format ‘%lx’ expects argument of type \
	  ‘long unsigned int’, but argument 2 has type ‘ULONGEST’ \
	  {aka ‘long long unsigned int’} [-Werror=format=]
	 4887 |       warning (_("Can not read at address %lx"), addr);
	      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	...
	and a few more Wformat errors, due to commit b9c7eed0c24 ("This commit adds
	record full support for rv64gc instruction set").

	Fix these by using hex_string.

	Tested by completing a build on arm-linux.

2025-04-30  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Mark fgt.*/fge.* as instruction alias
	They are instruction alias, but not mark correctly, and seems like we
	don't have a good way to verify that since the disassembler doesn't
	disassemble instruction into alias.

	[1] https://github.com/riscv-non-isa/riscv-asm-manual/pull/124

2025-04-30  Alan Modra  <amodra@gmail.com>

	PR 32896 testcase
	Modify it a little to run on more targets.

	kvxelf.em: translate error messages
	gettext calls were missing.  Fix that, and change a couple of einfo
	calls to fatal.

2025-04-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: change a bunch of functions to be methods of cooked_index_worker_debug_info
	Move a few functions exclusively used to process units to become methods
	of cooked_index_worker_debug_info.  Rename them to a more consistent
	name scheme, which gets rid of outdated naming.  The comments were also
	quite outdated.

	Change-Id: I2e7dcc2e4ff372007dcb4f6c3d34187c9cc2da05
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: move cooked_index_worker_debug_info up
	The next patch moves some functions to be methods of
	cooked_index_worker_debug_info.  Move cooked_index_worker_debug_info
	above those functions, to make that easier (methods can't be defined
	before the class declaration).

	Change-Id: I7723cb42efadb2cc86f2227b3c2fb275e2d620f9
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: clean up some cutu_reader::is_dummy() calls
	This patch tries to standardize the places where we check if units are
	dummy.  When checking if a unit is dummy, it is not necessary to check
	for some other conditions.

	 - cutu_reader::is_dummy() is a superset of cutu_reader::cu() returning
	   nullptr, so it's not necessary to check if the cu method return
	   nullptr if also checking if the unit is dummy.
	 - cutu_reader::is_dummy() is a superset of cutu_reader::top_level_die()
	   returning nullptr, so same deal.

	Remove some spots that check for these conditions in addition to
	cutu_reader::is_dummy().

	In addition, also remove the checks for:

	    !new_reader->top_level_die ()->has_children

	in cooked_indexer::ensure_cu_exists.  IMO, it is not useful to special
	case the units having a single DIE.  Especially in this function, which
	deals with importing things from another unit, a unit with a single DIE
	would be an edge case that should not happen with good debug info.  I
	think it's preferable to have simpler code.

	Change-Id: I4529d7b3a0bd2891a60f41671de8cfd3114adb4a
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: avoid cutu_reader moves
	In process_psymtab_comp_unit and ensure_cu_exists, we create a temporary
	cutu_reader on the stack, then move it to a heap allocated cutu_reader
	once we confirmed the unit is not dummy.  I think it's unnecessary to
	create a temporary cutu_reader.  The only downside of not doing so is that if it
	ends up that the CU is dummy, we made an allocation/deallocation for
	nothing.  Dummy CUs are a rare thing, it shouldn't change anything.

	This allows removing the cutu_reader move constructor.

	Change-Id: I44742d471c495055ee46db41c0e7bdfbd2d5c0b7
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: read multiple .debug_info.dwo sections
	When building with gcc, with flags -gdwarf-5, -gsplit-dwarf and
	-fdebug-types-section, the resulting .dwo files contain multiple
	.debug_info.dwo sections.  One for each type unit and one for the
	compile unit.  This is correct, as per DWARF 5, section F.2.3 ("Contents
	of the Split DWARF Object Files"):

	    The split DWARF object files each contain the following sections:

	        ...
	        .debug_info.dwo (for the compilation unit)
	        .debug_info.dwo (one COMDAT section for each type unit)
		...

	GDB currently assumes that there is a single .debug_info.dwo section,
	causing unpredictable behavior.  For example, sometimes this crash:

	    ==81781==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x508000007a71 at pc 0x58704d32a59c bp 0x7ffc0acc0bb0 sp 0x7ffc0acc0ba0
	    READ of size 1 at 0x508000007a71 thread T0
	        #0 0x58704d32a59b in bfd_getl32 /home/smarchi/src/binutils-gdb/bfd/libbfd.c:846
	        #1 0x58704ae62dce in read_initial_length(bfd*, unsigned char const*, unsigned int*, bool) /home/smarchi/src/binutils-gdb/gdb/dwarf2/leb.c:92
	        #2 0x58704aaf76bf in read_comp_unit_head(comp_unit_head*, unsigned char const*, dwarf2_section_info*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:47
	        #3 0x58704aaf8f97 in read_and_check_comp_unit_head(dwarf2_per_objfile*, comp_unit_head*, dwarf2_section_info*, dwarf2_section_info*, unsigned char const*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:193
	        #4 0x58704b022908 in create_dwo_unit_hash_tables /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6233
	        #5 0x58704b0334a5 in open_and_init_dwo_file /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7588
	        #6 0x58704b03965a in lookup_dwo_cutu /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7935
	        #7 0x58704b03a5b1 in lookup_dwo_comp_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8009
	        #8 0x58704aff5b70 in lookup_dwo_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2802

	The first time that locate_dwo_sections gets called for a
	.debug_info.dwo section, dwo_sections::info gets initialized properly.
	The second time it gets called for a .debug_info.dwo section, the size
	field in dwo_sections::info gets overwritten with the size of the second
	section.  But the buffer remains pointing to the contents of the first
	section, because the section is already "read in".  So the size does not
	match the buffer.  And even if it did, we would only keep the
	information about one .debug_info.dwo, out of the many.

	First, add an assert in locate_dwo_sections to make sure we don't
	try to fill in a dwo section info twice.  Add the assert to other
	functions with the same pattern, while at it.

	Then, change dwo_sections::info to be a vector of sections (just like we
	do for type sections).  Update locate_dwo_sections to append to that
	vector when seeing a new .debug_info.dwo section.  Update
	open_and_init_dwo_file to read the units from each section.

	The problem can be observed by running some tests with the
	dwarf5-fission-debug-types target board.  For example,
	gdb.base/condbreak.exp crashes (with the ASan failure shown above)
	before the patch and passes after).

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119766

	Change-Id: Iedf275768b6057dee4b1542396714f3d89903cf3
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-04-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: scan .debug_info.dwo just once
	When building -gsplit-dwarf and -fdebug-types-section in DWARF 5, the
	resulting .dwo files will typically have a .debug_info.dwo section with
	multiple type units followed by one compile unit:

	    $ llvm-dwarfdump -F -color a-test.dwo | grep ' Unit'
	    0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector<int, std::allocator<int> >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4)
	    0x000008a4: Type Unit: length = 0x00000099, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'allocator<int>', type_signature = 0x496a8791a842701b, type_offset = 0x0023 (next unit at 0x00000941)
	    ...
	    0x000015c1: Compile Unit: length = 0x00000f58, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0xe8e359820d1c5803 (next unit at 0x0000251d)

	In open_and_init_dwo_file, we call create_dwo_cus_hash_table, which
	scans the section, looking for compile units, then call
	create_dwo_debug_types_hash_table, which scans the section again,
	looking for type units.  It would make more sense to scan the section
	just once and handle both compile and type units at the same time.

	To achieve this, add create_dwo_unit_hash_tables, which knows how to
	handle both unit kinds in a single scan.  It replaces
	create_dwo_cus_hash_table and create_dwo_debug_type_hash_table.  Change
	open_and_init_dwo_file to call it.

	Note that I removed the DWARF version check in open_and_init_dwo_file
	when processing .debug_type.dwo sections: in DWARF 5, the
	.debug_type.dwo sections will just not exist, so the
	`dwo_file->sections.types` vector will be empty.

	Change-Id: I6e51d0ca06c258e0bf0e59927d62ae2df314a162
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: scan DWARF 5 DWO CUs by just reading the header
	create_dwo_cus_hash_table is implemented by creating a cutu_reader
	(which is somewhat heavy) for all units in a .dwo file.  The purpose of
	this cutu_reader is to be able to get the DWO ID, if it is specified by
	a DW_AT_GNU_dwo_id attribute.

	In DWARF 5, however, the DWO ID is available in the CU header.  We can
	access it without accessing the DIEs, by just reading the header, which
	is more lightweight.  Add a new code path to create_dwo_cus_hash_table
	that does that.  The logic is copied from
	create_dwo_debug_type_hash_table, which does this already.

	This change helps circumvent a performance problem I want to fix (the
	same I was trying to fix in this patch [1]) when loading a file built
	with -gdwarf-5, -gsplit-dwarf and -fdebug-types-section.  In this
	configuration, the produced .dwo files contain one compile unit and many
	type units each.  All units in a given .dwo share the same abbrev table.
	Creating a cutu_reader for each unit meant re-reading the same abbrev
	table over and over.  What's particularly bad is that this is done with
	the dwo_lock held, preventing other indexing threads from making
	progress.

	To give a rough idea, here's the time take by each worker to index units
	before this patch (on a rather large program):

	    Time for "DWARF indexing worker": wall 18.627, user 0.885, sys 0.042, user+sys 0.927, 5.0 % CPU
	    Time for "DWARF indexing worker": wall 18.888, user 0.862, sys 0.042, user+sys 0.904, 4.8 % CPU
	    Time for "DWARF indexing worker": wall 19.172, user 1.848, sys 0.069, user+sys 1.917, 10.0 % CPU
	    Time for "DWARF indexing worker": wall 19.297, user 1.544, sys 0.051, user+sys 1.595, 8.3 % CPU
	    Time for "DWARF indexing worker": wall 19.545, user 3.408, sys 0.084, user+sys 3.492, 17.9 % CPU
	    Time for "DWARF indexing worker": wall 19.759, user 4.221, sys 0.117, user+sys 4.338, 22.0 % CPU
	    Time for "DWARF indexing worker": wall 19.789, user 4.187, sys 0.105, user+sys 4.292, 21.7 % CPU
	    Time for "DWARF indexing worker": wall 19.825, user 4.933, sys 0.135, user+sys 5.068, 25.6 % CPU

	And the times with this patch:

	    Time for "DWARF indexing worker": wall 0.163, user 0.089, sys 0.029, user+sys 0.118, 72.4 % CPU
	    Time for "DWARF indexing worker": wall 0.176, user 0.096, sys 0.041, user+sys 0.137, 77.8 % CPU
	    Time for "DWARF indexing worker": wall 0.265, user 0.167, sys 0.054, user+sys 0.221, 83.4 % CPU
	    Time for "DWARF indexing worker": wall 0.353, user 0.257, sys 0.060, user+sys 0.317, 89.8 % CPU
	    Time for "DWARF indexing worker": wall 0.524, user 0.399, sys 0.088, user+sys 0.487, 92.9 % CPU
	    Time for "DWARF indexing worker": wall 0.648, user 0.517, sys 0.107, user+sys 0.624, 96.3 % CPU
	    Time for "DWARF indexing worker": wall 0.657, user 0.523, sys 0.107, user+sys 0.630, 95.9 % CPU
	    Time for "DWARF indexing worker": wall 0.753, user 0.612, sys 0.120, user+sys 0.732, 97.2 % CPU

	[1] https://inbox.sourceware.org/gdb-patches/20250326200002.136200-8-simon.marchi@efficios.com/

	Change-Id: I34a422577e4c3ad7d478ec6df12a0e44d284c249
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: replace some "compile unit" terminology with "unit"
	In DWARF 5 (and even previous versions, with type units), compile units
	are just one type of units.  In many places, we still use "compile
	units" when in reality it would be better to talk about "units" (unless
	we specifically want to talk about compile units).

	Rename comp-unit-head.{c.h} to unit-head.{c,h}, and do a big pass of
	renames in it to remove the specific mentions of compile units, where in
	fact we want to talk about units in general.

	Change-Id: Ia06c90ccb25756c366f269a12620f2f7c8378adb
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add some scoped_time_its to profile startup time
	I'm investigating some issues where GDB takes a lot of time to start
	up (read: for the DWARF index to be ready to do anything useful).
	Adding those scoped_time_it instances helped me gain some insights about
	where GDB spends time.  I think they would be useful to have upstream,
	to make investigating future problems easier.  It would also be useful
	to be able to give some numbers in the commit messages.

	Here's an example of what GDB outputs:

	    Time for "minsyms install worker": wall 0.045, user 0.040, sys 0.004, user+sys 0.044, 97.8 % CPU
	    Time for "minsyms install worker": wall 0.511, user 0.457, sys 0.048, user+sys 0.505, 98.8 % CPU
	    Time for "minsyms install worker": wall 1.513, user 1.389, sys 0.111, user+sys 1.500, 99.1 % CPU
	    Time for "minsyms install worker": wall 1.688, user 1.451, sys 0.102, user+sys 1.553, 92.0 % CPU
	    Time for "minsyms install worker": wall 1.897, user 1.518, sys 0.089, user+sys 1.607, 84.7 % CPU
	    Time for "minsyms install worker": wall 2.811, user 2.558, sys 0.231, user+sys 2.789, 99.2 % CPU
	    Time for "minsyms install worker": wall 3.257, user 3.049, sys 0.188, user+sys 3.237, 99.4 % CPU
	    Time for "minsyms install worker": wall 3.617, user 3.089, sys 0.211, user+sys 3.300, 91.2 % CPU
	    Time for "DWARF indexing worker": wall 19.517, user 0.894, sys 0.075, user+sys 0.969, 5.0 % CPU
	    Time for "DWARF indexing worker": wall 19.807, user 0.891, sys 0.086, user+sys 0.977, 4.9 % CPU
	    Time for "DWARF indexing worker": wall 20.270, user 1.559, sys 0.119, user+sys 1.678, 8.3 % CPU
	    Time for "DWARF indexing worker": wall 20.329, user 1.878, sys 0.147, user+sys 2.025, 10.0 % CPU
	    Time for "DWARF indexing worker": wall 20.848, user 3.483, sys 0.224, user+sys 3.707, 17.8 % CPU
	    Time for "DWARF indexing worker": wall 21.088, user 4.285, sys 0.295, user+sys 4.580, 21.7 % CPU
	    Time for "DWARF indexing worker": wall 21.109, user 4.501, sys 0.274, user+sys 4.775, 22.6 % CPU
	    Time for "DWARF indexing worker": wall 21.198, user 5.087, sys 0.319, user+sys 5.406, 25.5 % CPU
	    Time for "DWARF skeletonless type units": wall 4.024, user 3.858, sys 0.115, user+sys 3.973, 98.7 % CPU
	    Time for "DWARF add parent map": wall 0.092, user 0.086, sys 0.004, user+sys 0.090, 97.8 % CPU
	    Time for "DWARF finalize worker": wall 0.278, user 0.241, sys 0.009, user+sys 0.250, 89.9 % CPU
	    Time for "DWARF finalize worker": wall 0.307, user 0.304, sys 0.000, user+sys 0.304, 99.0 % CPU
	    Time for "DWARF finalize worker": wall 0.727, user 0.719, sys 0.000, user+sys 0.719, 98.9 % CPU
	    Time for "DWARF finalize worker": wall 0.913, user 0.901, sys 0.003, user+sys 0.904, 99.0 % CPU
	    Time for "DWARF finalize worker": wall 0.776, user 0.767, sys 0.004, user+sys 0.771, 99.4 % CPU
	    Time for "DWARF finalize worker": wall 1.897, user 1.869, sys 0.006, user+sys 1.875, 98.8 % CPU
	    Time for "DWARF finalize worker": wall 2.534, user 2.512, sys 0.005, user+sys 2.517, 99.3 % CPU
	    Time for "DWARF finalize worker": wall 2.607, user 2.583, sys 0.006, user+sys 2.589, 99.3 % CPU
	    Time for "DWARF finalize worker": wall 3.142, user 3.094, sys 0.022, user+sys 3.116, 99.2 % CPU

	Change-Id: I9453589b9005c3226499428ae9cab9f4a8c22904
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add scoped_time_it
	New in v2:

	 - actually use m_enabled in the constructor and destructor
	 - output using gdb_stdlog->write_async_safe instead of gdb_printf

	scoped_time_it is a small utility that measures and prints how much time
	a given thread spent in a given scope.  Similar to the time(1) command,
	it prints the time spent in user mode, system mode, and the wall clock
	time.  It also prints the CPU utilization percentage, which is:

	  (user + sys) / wall

	This can help spot cases where the workload is not well balanced between
	workers, or the CPU utilization is not optimal (perhaps due to
	contention around a lock for example).

	To use it, just add it in some scope.  For instance, a subsequent patch
	adds it here:

	      workers.add_task ([this, task_count, iter, last] ()
		{
		  scoped_time_it time_it ("DWARF indexing worker");
		  process_cus (task_count, iter, last);
		});

	On destruction, if enabled, it prints a line showing the time spent by
	that thread, similar to what time(1) prints.

	The example above prints this (one line for each worker thread):

	    Time for "DWARF indexing worker": wall 0.173, user 0.120, sys 0.034, user+sys 0.154, 89.0 % CPU
	    Time for "DWARF indexing worker": wall 0.211, user 0.144, sys 0.047, user+sys 0.191, 90.5 % CPU
	    Time for "DWARF indexing worker": wall 0.368, user 0.295, sys 0.057, user+sys 0.352, 95.7 % CPU
	    Time for "DWARF indexing worker": wall 0.445, user 0.361, sys 0.072, user+sys 0.433, 97.3 % CPU
	    Time for "DWARF indexing worker": wall 0.592, user 0.459, sys 0.113, user+sys 0.572, 96.6 % CPU
	    Time for "DWARF indexing worker": wall 0.739, user 0.608, sys 0.115, user+sys 0.723, 97.8 % CPU
	    Time for "DWARF indexing worker": wall 0.831, user 0.677, sys 0.140, user+sys 0.817, 98.3 % CPU
	    Time for "DWARF indexing worker": wall 0.949, user 0.789, sys 0.144, user+sys 0.933, 98.3 % CPU

	The object is only enabled if per_command_time (controlled by "maint set
	per-command time") is true at construction time.  I wanted to avoid
	adding a new command for now, but eventually if there are too many
	scoped_time_it around the code base and we want to be able to enabled
	them selectively (e.g. just the ones in the DWARF reader, or in the
	symbol searching functions, etc), we could have a dedicated command for
	that.

	I added this functionality to GDB because it relies on gdb_printf and
	per_command_time, but if we ever need it in gdbsupport, I'm sure we
	could find a way to put it there.

	Change-Id: I5416ac1448f960f44d85f8449943d994198a271e
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: move run_time_clock::now(user, system) out of run_time_clock
	It is completely unrelated to run_time_clock, so I don't think it makes
	sense to have it as a static function there.

	Move it to be a free function named "get_run_time".

	Change-Id: I0c3e4d3cc44ca37e523c94d72f7cd66add95645e
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Tom Tromey  <tromey@adacore.com>

	Handle base type without DW_AT_byte_size
	DWARF says that a base type can have DW_AT_bit_size, without
	DW_AT_byte_size.  However, gdb does not correctly handle this; in
	fact, it crashes, as pointed out in this LLVM merge request:

	    https://github.com/llvm/llvm-project/pull/137123

	This patch reworks the base type size logic a bit to handle this
	situation.

	Tested-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-29  Keith Seitz  <keiths@redhat.com>

	[gdb/contrib] Add script to license check new files
	While reading through gdb-patches backlog after a return
	from PTO, I noticed that a newly added file was licensed
	with "MIT", and that license was not listed in Fedora's
	gdb.spec file. [Fedora no longer supports "effective"
	licenses.]

	That lead me to this simple script which generates a list
	of all the newly added files between two given commits and
	scans these files for licenses.

	Example usage:
	bash$ cd /path/to/binutils-gdb/gdb
	bash$ ./contrib/license-check-new-files.sh -s gdb-15-branchpoint gdb-16-branchpoint
	Scanning directories gdb*/...
	gdb/contrib/common-misspellings.txt: no longer in repo?
	gdb/contrib/spellcheck.sh: no longer in repo?
	gdbsupport/unordered_dense.h: MIT

	I don't think anything in here is Fedora- or RPM-specific,
	so I'd like to submit this for consideration for inclusion
	in contrib/.  I believe other distros may find it useful.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Jeremy Bryant  <jb@jeremybryant.net>

	Change acronym BFD to Binary File Descriptor.
	This fixes a typo in gdb/README.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/ptype.exp with gcc 15
	With test-case gdb.base/ptype.exp and gcc 15 I run into:
	...
	(gdb) ptype old_fptr^M
	type = double (*)(void)^M
	(gdb) FAIL: $exp: ptype old_fptr (compiler doesn't emit unprototyped types)
	...

	Since C23, non-prototype function declarations are no longer supported, so
	"double (*old_fptr) ()" is interpreted as "double (*old_fptr) (void)".

	We could try to fix this by detecting the language dialect used, and accepting
	the output in that case, but that feels fragile.

	We could try to fix this by hard-coding the language dialect, but that doesn't
	work for all compilers.

	So instead, we opt for the simplest solution: just accept this output, and
	produce a pass.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/32756
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-objfile.exp with gcc 15
	When running test-case gdb.python/py-objfile.exp with gcc 15, we get:
	...
	(gdb) p main^M
	$2 = {int (void)} 0x40066c <main>^M
	(gdb) FAIL: $exp: print main with debug info
	...

	The source file declares main as "int main ()"
	...
	and until C23 this meant a non-prototype function declaration and we'd have:
	...
	(gdb) p main^M
	$2 = {int ()} 0x40066c <main>^M
	...

	However, starting C23 "int main ()" is simply equivalent to "int main (void)".

	Fix this by:
	- declaring main as "int main (void)" in the test-case, and
	- updating the regexp to expect an "int (void)" prototype.

	Likewise in gdb.base/jit-bfd-name.exp.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/32756
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't use string_to_regexp twice in gdb.base/options.exp
	In test-case gdb.base/options.exp, in proc test_completer_recognizes we have:
	...
	    set expected_re [string_to_regexp $input_line]
	    test_gdb_complete_unique $input_line $expected_re
	...

	However, the first thing we do in proc test_gdb_complete_unique	is to apply
	string_to_regexp to the second argument:
	...
	proc test_gdb_complete_unique {
	  input_line
	  complete_line
	  {append_char " "}
	  {max_completions false}
	  {testname ""}
	} {
	    set complete_line_re [string_to_regexp $complete_line]
	    test_gdb_complete_unique_re \
	         $input_line \
		 $complete_line_re \
		 $append_char \
		 $max_completions\
		 $testname
	}
	...

	This happens to not cause any FAILs at the moment, but this should be done
	only once.

	Fix this not using string_to_regexp in proc test_completer_recognizes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle nullptr gdb_std{err,out} in {gdbpy,ioscm}_flush
	Using the trigger patch described in the previous commit, I get:
	...
	$ gdb
	(gdb) <q>error detected on stdin

	Fatal signal: Segmentation fault
	----- Backtrace -----
	0x64c7b3 gdb_internal_backtrace_1
		/data/vries/gdb/src/gdb/bt-utils.c:127
	0x64c937 _Z22gdb_internal_backtracev
		/data/vries/gdb/src/gdb/bt-utils.c:196
	0x94db83 handle_fatal_signal
		/data/vries/gdb/src/gdb/event-top.c:1021
	0x94dd48 handle_sigsegv
		/data/vries/gdb/src/gdb/event-top.c:1098
	0x7f372be578ff ???
	0x10b7c0a _Z9gdb_flushP7ui_file
		/data/vries/gdb/src/gdb/utils.c:1527
	0xd4b938 gdbpy_flush
		/data/vries/gdb/src/gdb/python/python.c:1624
	0x7f372d73b276 _PyCFunction_FastCallDict
		Objects/methodobject.c:231
	0x7f372d73b276 _PyCFunction_FastCallKeywords
		Objects/methodobject.c:294
	0x7f372d794a09 call_function
		Python/ceval.c:4851
	0x7f372d78e838 _PyEval_EvalFrameDefault
		Python/ceval.c:3351
	0x7f372d796e6e PyEval_EvalFrameEx
		Python/ceval.c:754
	0x7f372d796e6e _PyFunction_FastCall
		Python/ceval.c:4933
	0x7f372d796e6e _PyFunction_FastCallDict
		Python/ceval.c:5035
	0x7f372d6fefc8 _PyObject_FastCallDict
		Objects/abstract.c:2310
	0x7f372d6fefc8 _PyObject_Call_Prepend
		Objects/abstract.c:2373
	0x7f372d6fe162 _PyObject_FastCallDict
		Objects/abstract.c:2331
	0x7f372d700705 callmethod
		Objects/abstract.c:2583
	0x7f372d700705 _PyObject_CallMethodId
		Objects/abstract.c:2640
	0x7f372d812a41 flush_std_files
		Python/pylifecycle.c:699
	0x7f372d81281d Py_FinalizeEx
		Python/pylifecycle.c:768
	0xd4d49b finalize_python
		/data/vries/gdb/src/gdb/python/python.c:2308
	0x9587eb _Z17ext_lang_shutdownv
		/data/vries/gdb/src/gdb/extension.c:330
	0xfd98df _Z10quit_forcePii
		/data/vries/gdb/src/gdb/top.c:1817
	0x6b3080 _Z12quit_commandPKci
		/data/vries/gdb/src/gdb/cli/cli-cmds.c:483
	0x1056577 stdin_event_handler
		/data/vries/gdb/src/gdb/ui.c:131
	0x1986970 handle_file_event
		/data/vries/gdb/src/gdbsupport/event-loop.cc:551
	0x1986f4b gdb_wait_for_event
		/data/vries/gdb/src/gdbsupport/event-loop.cc:672
	0x1985e0c _Z16gdb_do_one_eventi
		/data/vries/gdb/src/gdbsupport/event-loop.cc:263
	0xb66f2e start_event_loop
		/data/vries/gdb/src/gdb/main.c:402
	0xb670ba captured_command_loop
		/data/vries/gdb/src/gdb/main.c:466
	0xb68b9b captured_main
		/data/vries/gdb/src/gdb/main.c:1344
	0xb68c44 _Z8gdb_mainP18captured_main_args
		/data/vries/gdb/src/gdb/main.c:1363
	0x41a3b1 main
		/data/vries/gdb/src/gdb/gdb.c:38
	---------------------
	A fatal error internal to GDB has been detected, further
	debugging is not possible.  GDB will now terminate.

	This is a bug, please report it.  For instructions, see:
	<https://www.gnu.org/software/gdb/bugs/>.

	Segmentation fault (core dumped)
	$ q
	...

	Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and
	likewise in ioscm_flush) such that we get instead:
	...
	$ gdb
	(gdb) <q>error detected on stdin
	$ q
	...

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix sig_write for null gdb_stderr
	When running test-case gdb.tui/tui-layout-asm.exp with target board
	dwarf5-fission-debug-types, the test-case fails and I get a core dump:
	...
	 # of unexpected core files      1
	...

	Looking at the backtrace of the core file, what seems to be happening is that:
	- gdbpy_flush attempts to flush gdb_stdout, which is nullptr
	- that causes a segfault
	- gdb intercepts this and starts to handle it using handle_fatal_signal
	- handle_fatal_signal calls sig_write, which attempts to write to gdb_stderr,
	  which is nullptr,
	- that causes another segfault
	- gdb exits

	I managed to reproduce the problem by the following trigger patch in
	stdin_event_handler:
	...
	-  if (error)
	+  if (1 || error)
	     {
	       current_ui = main_ui;
	       ui->unregister_file_handler ();
	-      if (main_ui == ui)
	+      if (1 || main_ui == ui)
	 	{
	 	  gdb_printf (gdb_stderr, _("error detected on stdin\n"));
	+	  gdb_stderr = nullptr;
	+	  gdb_stdout = nullptr;
	+	  gdb_stdlog = nullptr;
	 	  quit_command ((char *) 0, 0);
	 	}
	...
	which gives us:
	...
	$ gdb
	(gdb) <q>error detected on stdin
	Segmentation fault (core dumped)
	$ q
	...

	Fix sig_write to handle the case that gdb_stderr == nullptr, such that we get
	instead:
	...
	$ gdb
	(gdb) <q>error detected on stdin

	Fatal signal: Segmentation fault
	----- Backtrace -----
	  ...
	---------------------
	A fatal error internal to GDB has been detected, further
	debugging is not possible.  GDB will now terminate.

	This is a bug, please report it.  For instructions, see:
	<https://www.gnu.org/software/gdb/bugs/>.

	Segmentation fault (core dumped)
	$ q
	...

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb] Factor out sig_write
	Lambda function sig_write:
	...
	  const auto sig_write = [] (const char *msg) -> void
	  {
	    gdb_stderr->write_async_safe (msg, strlen (msg));
	  }
	...
	is defined a few times.

	Factor this out into a regular function.

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-29  H.J. Lu  <hjl.tools@gmail.com>

	elf: Properly set sh_offset for .tbss sections
	Set sh_offset for .tbss sections to their nominal offset after aligning.
	They are not loaded from disk so the value doesn't really matter, except
	when the .tbss section is the first one in a PT_TLS segment.  In that
	case, it sets the p_offset for the PT_TLS segment, which according to
	the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align.

	bfd/

		PR ld/32896
		* elf.c (assign_file_positions_for_load_sections): Properly set
		sh_offset for .tbss sections.

	ld/

		PR ld/32896
		* testsuite/ld-elf/tbss4.d: New file.
		* testsuite/ld-elf/tbss4.s: Likewise.

2025-04-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng not reading references correctly in Dwarf
	Fixed as specified in the DWARF standard:
	 The first type of reference can identify any debugging information entry
	 within the containing unit. This type of reference is an offset from the first
	 byte of the compilation header for the compilation unit containing
	 the reference. There are five forms for this type of reference.
	 There are fixed length forms for one, two, four and eight byte offsets
	 (respectively, DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, and DW_FORM_ref8).
	 There is also an unsigned variable length offset encoded form that uses
	 unsigned LEB128 numbers (DW_FORM_ref_udata).

	gprofng/ChangeLog
	2025-04-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/DwarfLib.cc (set_die): Handling DWARF references (DW_FORM_ref1,
		DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata).
		* src/Dwarf.cc: Likewise.

2025-04-29  H.J. Lu  <hjl.tools@gmail.com>

	dwarf: Dump .debug_loclists only for DWARF-5
	.debug_loclists section is loaded into debug_information as DWARF-5 debug
	info and .debug_loc section is loaded into debug_information as pre-DWARF-5
	debug info.  When dumping .debug_loc section, we should only process
	pre-DWARF-5 debug info in debug_information.  When dumping .debug_loclists
	section, we should only process DWARF-5 info in debug_information.

	binutils/

		PR binutils/32809
		* dwarf.c (display_debug_loc): Dump .debug_loclists only for
		DWARF-5.

	ld/

		PR binutils/32809
		* testsuite/ld-x86-64/dwarf4.s: New file.
		* testsuite/ld-x86-64/dwarf5a.s: Likewise.
		* testsuite/ld-x86-64/dwarf5b.s: Likewise.
		* testsuite/ld-x86-64/pr32809.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run pr32809.

2025-04-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-28  Tom Tromey  <tom@tromey.com>

	Fix "set debug parser"
	While debugging my longer series, I discovered that I broken "set
	debug parser" a couple years ago.  This patch fixes it and adds a
	minimal test case so that it, hopefully, will not break again.

	This patch also adds parser debugging to the C++ name canonicalizer.

	Thanks to Tom de Vries for fixing the test case.

2025-04-28  Maciej W. Rozycki  <macro@redhat.com>

	Regenerate more configury files for 64-bit BFD detection fix
	The fix for 64-bit BFD detection omitted the regeneration of a bunch
	of configury files; fix that.

2025-04-28  Maciej W. Rozycki  <macro@redhat.com>

	Fix 64-bit BFD detection causing build failures
	We have a discrepancy with 64-bit BFD handling across our component
	subdirectories leading to link failures such as:

	ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
	ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
	ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
	ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
	[...]

	with some configurations having a 32-bit host and 64-bit BFD, such as:
	`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
	This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
	other subdirectorses and has been a regression from commit 1d5269c994bf
	("unify 64-bit bfd checks").

	For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
	combined with this logic in bfd/configure.ac:

	case ${host64}-${target64}-${want64} in
	  *true*)
	    wordsize=64
	    bfd64_libs='$(BFD64_LIBS)'
	    all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
	    [...]
	    ;;
	  false-false-false)
	    wordsize=32
	    all_backends='$(BFD32_BACKENDS)'
	    ;;
	esac

	where the value of ${wordsize} switches between 32-bit and 64-bit BFD
	via these pieces:

	#define BFD_ARCH_SIZE @wordsize@

	and:

	#if BFD_ARCH_SIZE >= 64
	#define BFD64
	#endif

	in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".

	Then ${host64} is determined in bfd/configure.ac from the host's word
	size, via the host's pointer size:

	if test "x${ac_cv_sizeof_void_p}" = "x8"; then
	  host64=true
	fi

	And ${target64} is determined in bfd/configure.ac from the target's word
	size:

	    if test ${target_size} = 64; then
		target64=true
	    fi

	Where multiple targets have been requested with `--enable-targets=all'
	the presence of any 64-bit target will set "true" here.

	Finally ${want64} is set according to `--enable-64-bit-bfd' user option
	with an arrangement involving BFD_64_BIT:

	BFD_64_BIT
	if test $enable_64_bit_bfd = yes ; then
	  want64=true
	else
	  want64=false
	fi

	which also, redundantly, checks and sets its result upon the host's word
	size.  Lastly ${want64} is also selectively set by target fragments in
	bfd/config.bfd, which mostly if not completely overlaps with ${target64}
	setting as described above.

	Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
	notice that BFD is 64-bit and do not enable their 64-bit handling where
	the host requested is 32-bit and 64-bit BFD has been enabled other than
	with `--enable-64-bit-bfd'.  One consequence is opcodes/disassemble.c
	enables calls to its numerous own 64-bit backends by checking the BFD64
	macro from "bfd.h", however does not actually enable said backends in
	its Makefile.  Hence the link errors quoted above.

	Address the problem then by moving the `--enable-64-bit-bfd' option back
	to bfd/configure.ac and remove the call to BFD_64_BIT from there and
	then rewrite the macro in terms of checking for the presence of BFD64
	macro in "bfd.h", which is the canonical way of determining whether BFD
	is 64-bit or not.

	Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
	fragment used to before the problematic commit:

	    if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then

	run the preprocessor on "bfd.h", which allows to invoke the macro from
	configure.ac files placed in subdirectories located at deeper levels, by
	relying on the preprocessor's search path.

	This requires however that the invokers rely on `all-bfd' rather than
	`configure-bfd' for their `configure' invocation stage, because "bfd.h"
	is made by `make all' rather than `configure' in bfd/.

	Do not cache the result of this check however, as reconfiguring a tree
	such as to flip `--enable-64-bit-bfd' on or to change a secondary target
	may affect BFD64 and we have no access to information about secondary
	targets in BFD_64_BIT.

	Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
	anywhere.

	Last but not least remove the hack from gdb/configure.ac to fail builds
	for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
	but `--enable-64-bit-bfd' has not as it's no longer needed.  Such builds
	complete successfully now, having enabled 64-bit BFD implicitly.

	Tested-By: Guinevere Larsen <guinevere@redhat.com>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Alan Modra <amodra@gmail.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Avoid generating gdb_leak_detector.cpython-<n>.pyc
	After running test-case gdb.python/py-color-leak.exp in a container where I
	don't have PYTHONDONTWRITEBYTECODE set, I get:
	...
	$ ls src/gdb/testsuite/gdb.python/__pycache__/
	gdb_leak_detector.cpython-313.pyc
	...

	Fix this by setting sys.dont_write_bytecode to True in the python scripts
	importing the module.

	Tested on x86_64-linux.

2025-04-28  Surya Kumari Jangala  <jskumari@linux.ibm.com>

	Update binutils/MAINTAINERS for PPC
	binutils/
		* MAINTAINERS: Add myself as PPC maintainer.

2025-04-28  Surya Kumari Jangala  <jskumari@linux.ibm.com>

	PowerPC: Support for Prefixed Add Immediate Shifted Instruction (RFC02686)
	opcodes/
		* ppc-opc.c (insert_si32, extract_si32, insert_nsi32,
		extract_nsi32): New functions.
		(SI32, NSI32, P_D_SI32_MASK, P_DRAPCREL_SI32_MASK): New macros.
		(IMM32): Update for new macros.
		(powerpc_opcodes): Add plis, paddis, psubis.

	gas/
		* testsuite/gas/ppc/future.s: New test.
		* testsuite/gas/ppc/future.d: Likewise.

2025-04-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-26  Tom Tromey  <tromey@adacore.com>

	Add "maint canonicalize" command
	This adds a new "maint canonicalize" command that can be used to see
	the canonical form of a C++ name.  I've needed this a few times when
	debugging gdb.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-04-26  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add codespell:ignore-begin/ignore-end (disabled)
	It would be useful to tell codespell to ignore blocks of code.

	A feature ignore-multiline-regex exists, which can be used to implement this:
	...
	$ codespell --ignore-multiline-regex \
	    'codespell:ignore-begin.*codespell:ignore-end'
	...

	Unfortunately there's a bug in codespell where using -w in
	combination with --ignore-multiline-regex drops all newlines in the updated
	file.

	In absence of a fix, commit this solution disabled, to locally document the
	current state of this feature.

2025-04-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-25  Tom Tromey  <tromey@adacore.com>

	Fix d10v sim build with GCC 15
	The d10v sim fails when built with GCC 15.  From the bug:

	d10v/table.c:171:17: error: initialization of ‘void (*)(struct sim_state *, SIM_CPU *)’ {aka ‘void (*)(struct sim_state *, struct _sim_cpu *)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
	  171 | { 0,0,0,0,0,0,0,(void (*)())0,0,{0,0,0}},
	      |                 ^
	d10v/table.c:171:17: note: (near initialization for ‘Simops[165].func’)

	The bug here is that this is the wrong function pointer type.  Since
	'0' is perfectly fine here, this patch simply removes the cast.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32900
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-25  Tom de Vries  <tdevries@suse.de>

	[pre-commit] Add codespell-log commit-msg hook
	Now that we're using codespell to check spelling in gdb files, can we use
	codespell to bring this spelling warning:
	...
	$ echo usuable | codespell -
	1: usuable
		usuable ==> usable
	...
	to:
	...
	$ git commit -a -m "Usuable stuff"
	...
	?

	First, let's look at a straightforward commit-msg hook implementation:
	...
	    - id: codespell
	      name: codespell-commit-msg
	      verbose: true
	      always_run: true
	      stages: [commit-msg]
	...
	installed using:
	...
	$ pre-commit install -t commit-msg
	...

	When trying the commit, we get:
	...
	$ echo "/* bla */" >> gdb/gdb.c
	$ git commit -a -m "Usuable stuff"
	black................................................(no files to check)Skipped
	flake8...............................................(no files to check)Skipped
	isort................................................(no files to check)Skipped
	codespell............................................(no files to check)Skipped
	check-include-guards.................................(no files to check)Skipped
	black................................................(no files to check)Skipped
	flake8...............................................(no files to check)Skipped
	codespell............................................(no files to check)Skipped
	codespell-commit-msg.....................................................Failed
	- hook id: codespell
	- duration: 0.06s
	- exit code: 65

	.git/COMMIT_EDITMSG:1: Usuable ==> Usable

	check-include-guards.................................(no files to check)Skipped
	$
	...

	The commit was aborted, but the commit message is still there:
	...
	$ cat .git/COMMIT_EDITMSG
	Usuable stuff
	...

	We can retry and edit the commit message to clean up the typo:
	...
	$ git commit -e -F .git/COMMIT_EDITMSG -a
	...
	but it's a bit cumbersome.

	Furthermore, say we fix a typo and want to document this in the commit log, and
	do:
	...
	$ git commit -m "Fixed typo: useable -> usable" -a
	...

	This commit cannot succeed, unless we add a codespell ignore tag, which feels
	like taking it too far.

	Both these problems can be addressed by setting things up in such a way that
	the commit always succeeds, and codespell output is shown as a hint.

	Ideally, we'd tell to pre-commit to implement this using some setting, but
	there doesn't seem to be one.

	So we use some indirection.  Instead of using native codespell, use a local
	hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit,
	which calls codespell.

	Using this approach, we get:
	...
	$ echo "/* bla */" >> gdb/gdb.c
	$ git commit -a -m "Usuable stuff"
	black................................................(no files to check)Skipped
	flake8...............................................(no files to check)Skipped
	isort................................................(no files to check)Skipped
	codespell............................................(no files to check)Skipped
	check-include-guards.................................(no files to check)Skipped
	black................................................(no files to check)Skipped
	flake8...............................................(no files to check)Skipped
	codespell............................................(no files to check)Skipped
	check-include-guards.................................(no files to check)Skipped
	codespell-log............................................................Passed
	- hook id: codespell-log
	- duration: 0.18s

	codespell-log-internal...................................................Failed
	- hook id: codespell
	- exit code: 65

	.git/COMMIT_EDITMSG:1: Usuable ==> Usable

	[codespell/codespell-log-2 d081bd25a40] Usuable stuff
	 1 file changed, 1 insertion(+)
	$
	...

	This is obviously convoluted, but it works.  Perhaps we can propose a
	pre-commit improvement (always_pass) and simplify this eventually.

	Checked new script codespell-log.sh with shell-check.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-25  Guinevere Larsen  <guinevere@redhat.com>

	gdb: fix 32 bit build
	The recent commit dbbb9cfd3708a5b09b449c6cbc4d74dfec13904d added a
	message using %ld to print an std::vector::size, which is of size_t
	type. on 64 bit machines, size_t will be an unsigned long int, making
	%ld work just fine, but on 32 bit ones, size_t will be unsigned int,
	which causes the build to fail.

	This commit fixes that by using %zu instead.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32901
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-25  Guinevere Larsen  <guinevere@redhat.com>

	Revert "gdb: update corner case when canonicalizing riscv syscall names"
	This reverts commit b2aba1ce1326df73c03641e1cb01d2c5aa577015.
	That commit was pushed in error, as I confused which patch was approved
	in the list

2025-04-25  Pali Roh?r  <pali@kernel.org>

	BFD linker: Allow target backends to provide alternate entry names.
	PR 30144

2025-04-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: add dwarf2_cu::find_die method
	I added this small helper method in the series I'm writing, to make
	finding a DIE by section offset a bit nicer than using the unordered_set
	methods.  It doesn't have any dependencies, so I thought I would submit
	it on its own.

	Change-Id: If7313194ab09d9bd6d6a52c24eb6fd9a9c1b76e0
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: add missing include guard to remote-args.h
	Also, fix a type in "namespace".

	Change-Id: I3e5d1d49c765a035217437c0635b12dc28e41bf6

2025-04-24  Simon Marchi  <simon.marchi@polymtl.ca>

	pre-commit autoupdate
	Run `pre-commit autoupdate`.  This brings in new versions of isort and
	flake8.

	Change-Id: I55f8b51b100e090e9a210338f46e10cf131a4aa7
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix some flake8 F824 warnings
	flake8 7.2.0 appears to have this new warning:

	    F824: global name / nonlocal name is unused: name is never assigned in scope

	It points out a few places in our code base where "global" is not
	necessary, fix them.

	Change-Id: Ia6fb08686977559726fefe2a5bb95d8dcb298bb0
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use correct sign extension for enumeration types
	This changes update_enumeration_type_from_children to use the correct
	sign-extension method on the attribute.  The logic here is a bit
	complicated: if the enum has an underlying type, then we use that
	type's signed-ness to interpret attributes; otherwise we must assume
	attributes are encoded as signed values.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use bool in update_enumeration_type_from_children
	This is just a small preliminary cleanup to use 'bool' in
	update_enumeration_type_from_children.

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Remove dead code from dwarf2_const_value_data
	dwarf2_const_value_data checks the size of the data like so:

	   if (bits < sizeof (*value) * 8)
	...
	  else if (bits == sizeof (*value) * 8)
	...
	   else
	...

	However, 'bits' can only be 8, 16, 32, or 64.  And, because 'value' is
	a LONGEST, which is alwasy 64-bit, the final 'else' can never be
	taken.

	This patch removes the dead code.  And, because this was the only
	reason for a non-void return value, the return type is changed as
	well.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::signed_constant in attribute::as_boolean
	This changes attribute::as_boolean to use attribute::signed_constant.
	This is maybe overkill but lets any reasonable constant form through.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use correct sign for variant part discriminants
	The discriminant value for a variant part may be signed or unsigned,
	depending on the type of the variant.  This patch changes the DWARF
	reader to delay interpretation of the relevant attribute until the
	signed-ness is known.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use correct sign in get_mpz
	This changes dwarf2/read.c:get_mpz to use the correct sign-extension
	function.  Normally a rational constant uses signed values, but a
	purely unsigned form also seems fine here.  This adds a new
	attribute::form_is_strictly_unsigned, which is more precise than
	form_is_unsigned (which accepts a lot of forms that aren't really for
	ordinary constants).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::unsigned_constant for DW_AT_data_member_location
	This changes the DWARF reader to use attribute::unsigned_constant for
	DW_AT_data_member_location.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::unsigned_constant for DW_AT_data_bit_offset
	This changes the DWARF reader to use attribute::unsigned_constant when
	examining DW_AT_data_bit_offset.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use correct sign for DW_AT_GNU_bias
	DW_AT_GNU_bias may be signed or unsigned, depending on the underlying
	type.  This patch changes the DWARF reader to examine the type before
	decoding the attribute.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::unsigned_constant for DW_AT_bit_stride
	DW_AT_bit_stride uses an unsigned constant, so make this explicit in
	the reader.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::signed_constant for fixed-point scale
	This changes the DWARF reader to use attribute::signed_constant for
	DW_AT_binary_scale and DW_AT_decimal_scale.  (FWIW these were the
	attributes that first lead me to find this problem.)

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Introduce attribute::signed_constant
	This introduces a new method, attribute::signed_constant.  This should
	be used wherever DWARF specifies a signed integer constant, or where
	this is implied by the context.  It properly handles sign-extension
	for DW_FORM_data*.

	To my surprise, there doesn't seem to be a pre-existing sign-extension
	function.  I've added one to common-utils.h alongside the align
	functions.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Use attribute::unsigned_constant for sizes
	This changes the DWARF reader to use attribute::unsigned_constant for
	DW_AT_bit_size, DW_AT_byte_size, DW_AT_data_byte_size, and
	DW_AT_string_length.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680

2025-04-24  Guinevere Larsen  <guinevere@redhat.com>

	gdb: update corner case when canonicalizing riscv syscall names
	The script syscalls/riscv-canonicalize-syscall-gen.py has been recently
	introduced to help support record-full in riscv systems.  However, it
	was developed before commit 432eca4113d5748ad284a068873455f9962b44fe,
	which made the GDB enum more consistent, which forced the python script
	to have a corner case for the "gdb_old_mmap" case.

	Since the aforementioned commit has already been merged, we need to
	update the special case for the mmap syscall. A special case is still
	needed because the script would expect that the glibc sources call the
	syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which
	happens unfortunately.

	This commit doesn't change the .c file because it was already fixed by a
	different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was
	pushed as obvious to fix the build issues.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Tom Tromey  <tromey@adacore.com>

	Fix documentation for gdb.blocked_signals
	gdb exports a context manager named gdb.blocked_signals, but the
	documentation erroneously refers to it as gdb.block_signals.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32891
	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	New test - gdb.base/tls-dlobj.exp
	This test exercises musl_link_map_to_tls_module_id() and
	glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c.

	Prior to writing this test, I had only written what is now named
	'musl_link_map_to_tls_module_id' and it worked for both GLIBC and
	MUSL.  Once I wrote this new test, tls-dlobj.exp, there were a number
	of tests which didn't work with GLIBC.  This led me to write a
	GLIBC-specific link map to module id function, i.e,
	'glibc_link_map_to_tls_module_id'.

	It only has one compilation scenario, in which the pthread(s) library
	is used - as noted in a comment, it became too much of a hassle to try
	to KFAIL things, though it certainly could have been done in much the
	same was as was done in gdb.base/multiobj.exp.  It didn't seem that
	important to do so, however, since I believe that the other tests
	have adequate coverage for different compilation scenarios.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	New test - gdb.base/tls-multiobj.exp
	This test exercises GDB's internal TLS support when both the main
	program and several shared libraries have TLS variables.  It also
	tests existing (non-internal) TLS support too.

	It tests using two compilation scenarios, "default", in which
	libpthread is not linked with the program and libraries as well
	as one which does use libpthread.

	It tests link map address to module id mapping code in GDB
	in addition to the ability of GDB to traverse TLS data structures
	with several libraries in play.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	New test - gdb.base/tls-nothreads.exp
	This commit introduces a new test, gdb.base/tls-nothreads.exp.

	It has a test case, a C file, which has several TLS variables in the
	main program, which, once compiled and linked, should end up (in ELF
	files) in .tdata and .tbss.  The test compiles the program in a number
	of different ways, making sure that each variable is accessible
	regardless of how it was compiled.

	Note that some of the compilation scenarios end up with a statically
	linked executable.  Prior to this series of commits, accessing TLS
	variables from a statically linked program on Linux did not work.
	For certain targets (x86_64, aarch64, s390x, riscv, and ppc64),
	all on Linux, support has been added to GDB for accessing thread
	local storage in statically linked executables.  This test is
	important for testing those build scenarios.

	But it's also important to make sure that GDB's internal TLS support
	works for other scenarios too.  In order to accomplish that, the
	tests are also run in a mode which forces the internal support to
	be used.

	It also adds a new file, gdb.base/tls-common.exp.tcl, which includes
	some common definitions used by the three new TLS tests, including
	the one added by this commit.  In particular, it sets a TCL variable,
	'internal_tls_linux_targets' which list the targets mentioned earlier.
	This means that as internal TLS support is added for other targets,
	the target should be listed in just one file as opposed to three
	(or more if other tests using tls-common.exp.tcl are added).

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Delete disabled i386 internal TLS support
	As mentioned in the previous commit, this commit deletes the disabled
	code which could be used to implement internal TLS support for the
	i386 target.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Internal, but disabled, TLS support for i386
	This commit shows how internal TLS address lookup support could
	be implemented for the i386 target.

	Unfortunately, it doesn't work due to I386_GSBASE_REGNUM being
	unavailable for Linux targets.  I looked at trying to access the
	gsbase register via PTRACE_GET_THREAD_AREA, but did not understand
	it well enough to finish it.  Since the i386 target is much less
	important than it used to be, I gave up working on it.

	I don't want to leave this disabled code in our sources, so I
	will delete it in the next commit, however, this commit will be
	in our git repo, so it'll be available for someone with sufficient
	interest in the i386 target to look at.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
	For each architecture, aarch64, x86_64, riscv, ppc64, and s390x,
	this commit defines a suitable 'get_tls_dtv_addr' method and,
	when necessary, a 'get_tls_dtp_offset' method.

	It also registers svr4_tls_get_thread_local_address, defined in
	svr4-tls-tdep.c (in an earlier commit), as the
	get_thread_local_address gdbarch method.  It also registers its
	architecture specific code using svr4_tls_register_tls_methods().

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Implement internal TLS address lookup for select Linux targets
	This commit adds non-architecture-specific support for internal TLS
	address lookup for targets which register their support with the new
	file svr4-tls-tdep.c.  By "internal", I mean support which does not
	rely on libthread_db.  Knowledge of how to traverse TLS data
	structures is contained in this commit along with the next commit
	containing architecture specific knowledge regarding TLS offsets,
	registers, and such.

	The new function 'svr4_tls_get_thread_local_address' is a gdbarch method.
	It should be passed as an argument to
	set_gdbarch_get_thread_local_address in architecture specific
	<arch>-linux-tdep.c files which wish to offer internal TLS support.

	The architecture specific tdep files need to define a get_tls_dtv_addr
	method - as the name suggests, it needs to return the address of the
	DTV (dynamic thread vector) via architecture specific means.  This
	usually entails fetching the thread pointer via a register or registers
	assigned to this purpose, and then using that value to locate the
	address of the DTV from within the TCB (thread control block).

	Additionally, some architectures also need to provide a DTP offset,
	which is used by the MUSL C library to adjust the value obtained
	from a DTV entry to that of the start of the TLS block for a particular
	thread.  This is provided, when necessary, by a get_tls_dtp_offset
	method.

	Both methods, get_tls_dtv_addr and get_tls_dtp_offset, are registered
	with data structures maintained by linux-tdep.c via the new function
	svr4_tls_register_tls_methods().  Thus, for example, on RISC-V,
	riscv_linux_init_abi() will make the following two calls, the first
	for registering the internal get_thread_local_address gdbarch method
	and the second for registering riscv-specific methods for obtaining
	the DTV address and DTP offset:

	  set_gdbarch_get_thread_local_address (gdbarch,
						svr4_tls_get_thread_local_address);
	  svr4_tls_register_tls_methods (info, gdbarch, riscv_linux_get_tls_dtv_addr,
					 riscv_linux_get_tls_dtp_offset);

	Internal TLS support is provided for two C libraries, GLIBC, and MUSL.
	Details for accessing the various TLS data structures differ between
	these libraries.  As a consequence, linux-tdep.h defines a new enum,
	svr4_tls_libc, with values svr4_tls_libc_unknown, svr4_tls_libc_musl,
	and svr4_tls_libc_glibc.  A new static function libc_tls_sniffer uses
	heuristics to (try to) decide whether a program was linked against
	GLIBC or MUSL.  Working out what the heuristics should be, especially
	for statically linked binaries, turned out to be harder than I thought
	it would be.

	A new maintenance setting, force-internal-tls-address-lookup, has been
	added, which, when set to 'on', will (as the name suggests) force the
	internal TLS lookup mechanisms to be used.  Otherwise, if thread_db
	support is available (via the thread stratum), that will be preferred
	since it should be more accurate.  I expect that this setting will be
	mostly used by test cases in the GDB test suite.  The new test cases
	that are part of this series all use it, with iterations using both
	'on' and 'off' for all of the tests therein.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Track and fetch TLS module ids for MUSL and GLIBC
	This commit adds, to solib-svr4.h and solib-svr4.c, functions
	glibc_link_map_to_tls_module_id and musl_link_map_to_tls_module_id for
	use with callers in a new file svr4-tls-tdep.c (which is not in this
	commit).  It adds a number of helper functions for implementing link
	map to module id support.

	It also renames existing function 'find_program_interpreter' to
	'svr4_find_program_interpreter' and makes it visible to other source
	files within GDB.  It will be used in the libc sniffing code in
	svr4-tls-tdep.c in a later commit in this series.  The libc sniffer is
	needed in order to know which link map to module id function to call
	as the method for determining module ids differs between libc /
	dynamic linker implementations.  These details are discussed in
	comments in the patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Allow TLS access to work in gdb.server/no-thread-db.exp
	The patches later in the series add GDB-internal TLS support for
	certain targets.  This commit updates the "print foo" test in
	gdb.server/no-thread-db.exp to accept either a TLS failure (when
	libthread_db isn't available) or printing the correct answer, which
	will occur when GDB's internal TLS address resolution can be used.

	I'm making this change prior to the commits which actually add
	the GDB-internal TLS support in order to avoid tripping regression
	testers.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Kevin Buettner  <kevinb@redhat.com>

	Don't attempt to find TLS address when target has no registers
	This commit fixes two bugs, one of which is Bug 25807, which occurs
	when target_translate_tls_address() is called from
	language_defn::read_var_value in findvar.c.  I found it while testing on
	aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local
	into a FAIL due to a GDB internal error.  Now, with this commit in place,
	the KFAIL/FAIL turns into a PASS.

	In addition to the existing test just noted, I've also added a test to
	the new test case gdb.base/tls-nothreads.exp.  It'll be tested, using
	different scenarios, up to 8 times:

	PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: after exit: print tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: after exit: print tls_tbss_1

	There is a related problem that occurs when target_translate_tls_address
	is called from find_minsym_type_and_address() in minsyms.c.  It can be
	observed when debugging a program without debugging symbols when the
	program is not executing.  I've written a new test for this, but it's
	(also) included in the new test case gdb.base/tls-nothreads.exp, found
	later in this series.  Depending on the target, it can run up to 8
	times using different scenarios.  E.g., on aarch64, I'm seeing these
	PASSes, all of which test this change:

	PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
	PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1

	In an earlier version of this commit (v4), I was checking whether the
	target has registers in language_defn::read_var_value in findvar.c and
	in find_minsym_type_and_address in minsyms.c, printing suitable error
	messages in each case.  In his review of this commit for the v4
	series, Tom Tromey asked whether it would be better to do this check
	in target_translate_tls_address.  I had considered doing that for the
	v4 (and earlier) series, but I wanted to print slightly different
	messages at each check.  Also, read_var_value in findvar.c was already
	printing a message in some cases and I had arranged for the later
	check in that function to match the original message.

	However, while I had added a target-has-registers check at two of the
	call sites for target_translate_tls_address, I hadn't added it at the
	third call site which is in dwarf_expr_context::execute_stack_op() in
	dwarf2/expr.c.  I believe that in most cases, this is handled by the
	early check in language_defn::read_var_value...

	  else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ())
	    error (_("Cannot read `%s' without registers"), var->print_name ());

	...but it's entirely possible that dwarf_expr_context::execute_stack_op()
	might get called in some other context.  So it makes sense to do the
	target-has-registers check for that case too.  And rather than add yet
	another check at that call site, I decided that moving the check and
	error message to target_translate_tls_address makes sense.

	I had to make the error messages that it prints somewhat more generic.
	In particular, when called from language_defn::read_var_value, the
	message printed by target_translate_tls_address no longer matches the
	earlier message that could be printed (as shown above).  That meant
	that the test cases which check for this message, gdb.threads/tls.exp,
	and gdb.base/tls-nothreads.exp had to be adjusted to account for the
	new message.  Also, I think it's valuable to the user to know (if
	possible) the name of the variable that caused the error, so I've
	added an optional parameter to target_translate_tls_address, providing
	the name of the variable, if it's known.  Therefore, the message
	that's printed when the target-has-registers test fails is one of the
	following:

	When the TLS variable isn't known (due to being called from
	dwarf_expr_context::execute_stack_op):

	    "Cannot translate TLS address without registers"

	When the TLS variable is known (from either of the other two call sites
	for target_translate_tls_address):

	    "Cannot find address of TLS symbol `%s' without registers"

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807
	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix completion of anonymous struct members
	Completing fields inside an anonymous struct does not work.  With:

	    struct commit_counters_hot {
	    	union {
	    		struct {
	    			long owner;
	    		};
	    		char padding[16];
	    	};
	    };

	I get:

	    (gdb) complete print cc_hot.
	    print cc_hot.padding

	After this patch, I get:

	    (gdb) complete print cc_hot.
	    print cc_hot.owner
	    print cc_hot.padding

	Update break1.c to include an anonymous struct.  The tests that complete
	"z_field" inside gdb.base/completion.exp would start to fail without the
	fix.

	Change-Id: I46b65a95ad16b0825de58dfa241777fe57acc361
	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-04-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix some Python files formatting
	Running `pre-commit run --all-files` introduces these fixes.

	Change-Id: I2e363fdf988b66d83008265b3ca8d1120f84b95d

2025-04-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: add remote argument passing unit tests
	This commit adds some remote argument passing unit tests.  There are
	not many tests right now -- there are known bugs in the remote
	argument passing mechanism (see PR gdb/28392) -- but some simple cases
	are covered here, and I plan to add additional tests once I've fixed
	more of the problems with the existing argument handling code.

	The tests take an inferior argument string, this is the string that
	GDB would carry around as inferior::m_args.  This string is then split
	using gdb::remote_args::split, this gives a vector of strings, these
	are the strings that are passed over the remote protocol.  These split
	strings are validated as part of the test.

	The split strings are then combined using gdb::remote_args::join which
	gives the inferior argument string that gdbserver will use, this is
	held in server.cc as program_args, this joined string is then checked
	as part of the test.

	There are no changes to GDB's behaviour as part of this commit, other
	than adding the new tests which can be run with:

	  (gdb) maintenance selftest remote-args
	  Running selftest remote-args.
	  Ran 1 unit tests, 0 failed

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-04-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: move remote arg splitting and joining into gdbsupport/
	This is a refactoring commit.  When passing inferior arguments to
	gdbserver we have two actions that need to be performed, splitting and
	joining.

	On the GDB side, we take the inferior arguments, a single string, and
	split the string into a list of individual arguments.  These are then
	sent to gdbserver over the remote protocol.

	On the gdbserver side we receive the list of individual arguments and
	join these back together into a single inferior argument string.

	In the next commit I plan to add some unit testing for this remote
	argument passing process.  Ideally, for unit testing, we need the code
	being tested to be located in some easily callable function, rather
	than being inline at the site of use.

	So in this commit I propose to move the splitting and joining logic
	out into a separate file, we can then use this within GDB and
	gdbserver when passing arguments between GDB and gdbserver, but we can
	also call the same functions for some unit testing.

	In this commit I'm not adding the unit tests, they will be added next,
	so for now there should be no user visible changes after this commit.

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-04-24  Claudiu Zissulescu  <claudiu.zissulescu-ianculescu@oracle.com>

	gas: sframe: fix handling of .cfi_def_cfa_register
	Fix PR gas/32879 sframe: Assembler internal error when translating
	cfi_def_cfa_register

	As per the documentation, .cfi_def_cfa_register modifies a rule for
	computing CFA; the register is updated, but the offset remains the same.

	While translating .cfi_def_cfa_register into SFrame context, we use the
	information from last translated FRE to set the CFA offset. However,
	there may be cases when the last translated FRE is empty.  Use last FRE
	only if available.

2025-04-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: keyword arguments for gdb.Color.escape_sequence
	GDB's Python documentation does make it clear that keywords arguments
	are supported for functions that take 2 or more arguments.  The
	documentation makes no promise for keyword argument support on
	functions that only take a single argument.

	That said, I'm a fan of keyword arguments, I think they help document
	the code, and make intentions clearer, even for single argument
	functions.

	As I'm changing gdb.Color anyway (see previous commit), I'd like to
	add keyword argument support to gdb.Color.escape_sequence, even though
	this is a single argument method.  This should be harmless for anyone
	who doesn't want to use keywords, but adds the option for those of us
	that do.

	I've also removed a redundant check that the 'self' argument was a
	gdb.Color object; Python already ensures this is the case.

	And I have folded the check that the single argument is a bool into
	the gdb_PyArg_ParseTupleAndKeywords call, this means that the error
	message will include the incorrect type name now, which should make
	debugging issues easier.

	Tests have been extended to cover both cases -- it appears the
	incorrect argument type error was not previously tested, so it is
	now.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: keyword args for Color.__init__
	GDB's Python API documentation is clear:

	     Functions and methods which have two or more optional arguments allow
	  them to be specified using keyword syntax.

	The gdb.Color.__init__ method matches this description, but doesn't
	support keyword arguments.

	This commit fixes this by adding keyword argument support.

	There's a new test to cover this functionality.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: tweaks to documentation for gdb.Color
	While reading through the documentation for the new gdb.Color class I
	spotted a couple of things which I thought could be improved:

	  * I replaced @code{Color} with @code{gdb.Color}.  Most of the other
	    classes are referenced with the 'gdb.' prefix, so this makes
	    gdb.Color consistent.  Including the 'gdb.' prefix makes it far
	    easier to search the documentation to find relevant content.  And
	    finally, my understanding is that usually in Python code, the
	    class would be written as 'gdb.Color' unless the user specifically
	    pulls 'Color' into the current scope using 'from gdb import
	    Color'.

	  * Replace 'colorspace' with 'color space'.  There was already a use
	    of the two word form in the documentation (for gdb.Color), so this
	    just makes things consistent.

	  * Removed use of @var on two @defun lines.  No other @defun lines
	    use @var, so the use of @var here was making the output
	    inconsistent, e.g. in the 'info' output, @var causes the string to
	    be capitalised.

	  * Rename the 'color-space' argument to 'color_space' for
	    Color.__init__.  In the next commit I plan to add Python keyword
	    argument support to this function, which means the argument name
	    needs to be a valid keyword (i.e. must not contain the '-'
	    character).

	  * Added a pointer to where the @samp{COLORSPACE_} constants can be
	    found.  These constants are referenced before they are defined in
	    the documentation, which is fine, but I think it is a good idea to
	    let the user know where the constants can be found when we first
	    reference them.

	  * Remove use of 'self' for the Color.escape_sequence documentation.
	    There are a few functions that do include 'self' as an argument (I
	    think this is a mistake) but the vast majority don't.  I think not
	    including 'self' is the better approach; a user wouldn't be
	    expected to explicitly pass 'self', this is done automatically by
	    Python as a result of calling the method on an object.  So I've
	    removed the reference to 'self' from this method.

	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: don't use PyObject_IsInstance in py-unwind.c
	I've been reviewing all uses of PyObject_IsInstance, and I believe
	that the use of PyObject_IsInstance in py-unwind.c is not entirely
	correct.  The use of PyObject_IsInstance is in this code in
	frame_unwind_python::sniff:

	  if (PyObject_IsInstance (pyo_unwind_info,
				   (PyObject *) &unwind_info_object_type) <= 0)
	    error (_("A Unwinder should return gdb.UnwindInfo instance."));

	The problem is that PyObject_IsInstance can return -1 to indicate an
	error, in which case a Python error will have been set.  Now, the
	above code appears to handle this case, it checks for '<= 0', however,
	frame_unwind_python::sniff has this near the start:

	  gdbpy_enter enter_py (gdbarch);

	And looking in python.c at 'gdbpy_enter::~gdbpy_enter ()', you'll
	notice that if an error is set then the error is printed, but also, we
	get a warning about an unhandled Python exception.  Clearly, all
	exceptions should have been handled by the time the gdbpy_enter
	destructor is called.

	I've added a test as part of this commit that exposes this problem,
	the current output is:

	  (gdb) backtrace
	  Python Exception <class 'RuntimeError'>: error in Blah.__class__
	  warning: internal error: Unhandled Python exception
	  Python Exception <class 'gdb.error'>: A Unwinder should return gdb.UnwindInfo instance.
	  #0  corrupt_frame_inner () at /home/andrew/projects/binutils-gdb/build.dev-g/gdb/testsuite/../../../src.dev-g/gdb/test>
	  (gdb)

	An additional observation is that we use PyObject_IsInstance to check
	that the return value is a gdb.UnwindInfo, or a sub-class.  However,
	gdb.UnwindInfo lacks the Py_TPFLAGS_BASETYPE flag, and so cannot be
	sub-classed.  As such, PyObject_IsInstance is not really needed, we
	could use PyObject_TypeCheck instead.  The PyObject_TypeCheck function
	only returns 0 or 1, there is no -1 error case.  Switching to
	PyObject_TypeCheck then, fixes the above problem.

	There's a new test that exposes the problems that originally existed.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: don't use PyObject_IsInstance in py-registers.c
	In python/py-registers.c we make use of PyObject_IsInstance.  The
	PyObject_IsInstance can return -1 for an error, 0 for false, or 1 for
	true.

	In py-registers.c we treat the return value from PyObject_IsInstance
	as a boolean, which means both -1 and 1 will be treated as true.

	If PyObject_IsInstance returns -1 for an error, this will be treated
	as true, we will then invoke undefined behaviour as the pyo_reg_id
	object will be treated as a gdb.RegisterDescriptor, even though it
	might not be.

	I noticed that the gdb.RegisterDescriptor class does not have the
	Py_TPFLAGS_BASETYPE flag, and therefore cannot be inherited from.  As
	such, using PyObject_IsInstance is not necessary, we can use
	PyObject_TypeCheck instead.  The PyObject_TypeCheck function only
	returns 0 or 1, so we don't need to worry about the error case.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: split gdb.dwarf2/macro-source-path.exp
	Because it runs so many variations, the test
	gdb.dwarf2/macro-source-path.exp takes about 2:40 minutes to run for me,
	in a non-optimized build.  These days I often run all tests under
	gdb.dwarf2, as a sanity test for my changes, and so I often have to wait
	for this test to complete.

	Split the test, to allow it to complete faster when running the
	testsuite in parallel.  After this patch, running all the
	gdb.dwarf2/macro-source-path-*.exp tests in parallel takes me about 1
	minute.  It's more that I would expect, I would expect the time to be
	divided by nearly 5, but it's already better than what we have now.

	Change-Id: I07e4e1f234cf57d9b0c1c027f08061615714a4d5
	Acked-By: Tom de Vries <tdevries@suse.de>

2025-04-23  Timur  <timurgol007@gmail.com>

	gdb: fix riscv record-full push
	When I (Guinevere) pushed commit
	b9c7eed0c2409fc640129a38d80a2bf1212b464a I accidentally used an outdated
	version of the patch. This current patch fixes the importation of that
	patch based on the actually approved version instead.

2025-04-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp
	With a gdb 16.2 based package, I ran into:
	...
	(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: input still accepted
	interrupt
	(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: interrupt
	set var do_wait=0
	(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: set var do_wait=0
	continue&
	Cannot execute this command while the selected thread is running.
	(gdb)
	Program received signal SIGINT, Interrupt.
	PASS: gdb.base/bg-execution-repeat.exp: c 1&: continue&
	0x00007ffff7cf1503 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
	FAIL: gdb.base/bg-execution-repeat.exp: c 1&: breakpoint hit 2 (timeout)
	...

	Fix this by waiting for "Program received signal SIGINT, Interrupt" after
	issuing the interrupt command.

	Tested on x86_64-linux.

2025-04-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: don't use PyObject_IsInstance in gdbpy_is_color
	The gdbpy_is_color function uses PyObject_IsInstance, and converts the
	return from PyObject_IsInstance to a bool.

	Unfortunately, PyObject_IsInstance can return -1, 0, or 1, for error,
	failure, or success respectively.  When converting to a bool both -1
	and 1 will convert to true.

	Additionally, when PyObject_IsInstance returns -1 an error will be
	set.

	What this means is that, if gdbpy_is_color is called with a non
	gdb.Color object, and the PyObject_IsInstance check raises an error,
	then (a) GDB will continue as if the object is a gdb.Color object,
	which is likely going to invoke undefined behaviour, see
	gdbpy_get_color for example, and (b) when GDB eventually returns to
	the Python interpreter, due to an error being set, we'll see:

	  Python Exception <class 'SystemError'>: PyEval_EvalFrameEx returned a result with an error set
	  Error occurred in Python: PyEval_EvalFrameEx returned a result with an error set

	However, after the previous commit, gdb.Color can no longer be
	sub-classed, this means that fixing the above problems is easy, we can
	replace the PyObject_IsInstance check with a PyObject_TypeCheck, the
	PyObject_TypeCheck function only returns 0 or 1, there's no -1 error
	case.

	It's also worth noting that PyObject_TypeCheck is the function that is
	more commonly used within GDB's Python API implementation, include the
	py-color.c use there were only 4 PyObject_IsInstance uses.  Of the
	remaining 3, 2 are fine, and one other (in py-disasm.c) is also
	wrong.  I'll address that in a separate patch.

	There's also a new test included which exposes the above issue.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.Color
	Remove the Py_TPFLAGS_BASETYPE flag from the gdb.Color type.  This
	effectively makes gdb.Color final; users can no longer create classes
	that inherit from gdb.Color.

	Right now I cannot think of any cases where inheritance would be
	needed over composition for a simple type like gdb.Color.  If I'm
	wrong, then it's easy to add Py_TPFLAGS_BASETYPE back in later, this
	would be an extension of the API.  But it's much harder to remove the
	flag later as that might break existing user code (note: there has
	been no release of GDB yet that includes the gdb.Color type).

	Introducing this restriction makes the next commit easier.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: stop using PyObject_IsInstance in py-disasm.c
	The PyObject_IsInstance function can return -1 for errors, 0 to
	indicate false, and 1 to indicate true.

	I noticed in python/py-disasm.c that we treat the result of
	PyObject_IsInstance as a bool.  This means that if PyObject_IsInstance
	returns -1, then this will be treated as true.  The consequence of
	this is that we will invoke undefined behaviour by treating the result
	from the _print_insn call as if it was a DisassemblerResult object,
	even though PyObject_IsInstance raised an error, and the result might
	not be of the required type.

	I could fix this by taking the -1 result into account, however,
	gdb.DisassemblerResult cannot be sub-classed, the type doesn't have
	the Py_TPFLAGS_BASETYPE flag.  As such, we can switch to using
	PyObject_TypeCheck instead, which only return 0 or 1, with no error
	case.

	I have also taken the opportunity to improve the error message emitted
	if the result has the wrong type.  Better error message make debugging
	issues easier.

	I've added a test which exposes the problem when using
	PyObject_IsInstance, and I've updated the existing test for the
	improved error message.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-23  Guinevere Larsen  <guinevere@redhat.com>

	gdb: fix building with all targets
	Commit b9c7eed0c2409fc640129a38d80a2bf1212b464a recently introduced
	a build failure, because the file gdb/riscv-canonicalize-syscall-gen.c
	hasn't been added to the ALL_64_TARGET_OBS variable in the makefile,
	leading to a linker issue.  This commit fixes that.

	Also, turns out, the new file was slightly outdated, as the gdb_old_mmap
	syscall has been renamed to gdb_sys_old_mmap in commit
	432eca4113d5748ad284a068873455f9962b44fe.  This commit also fixes that
	on the generated file itself, to quickly fix the build. A followup
	commit will fix the python file responsible for generating the .c file.

2025-04-23  Guinevere Larsen  <guinevere@redhat.com>

	GDB: Introduce "info linker-namespaces" command
	Continuing to improve GDB's ability to debug linker namespaces, this
	commit adds the command "info linker- namespaces". The command is
	similar to "info sharedlibrary" but focused on improved readability
	when the inferior has multiple linker namespaces active. This command
	can be used in 2 different ways, with or without an argument.

	When called without argument, the command will print the number of
	namespaces, and for each active namespace, it's identifier, how many
	libraries are loaded in it, and all the libraries (in a similar table to
	what "info sharedlibrary" shows). As an example, this is what GDB's
	output could look like:

	  (gdb) info linker-namespaces
	  There are 2 linker namespaces loaded
	  There are 3 libraries loaded in linker namespace [[0]]
	  Displaying libraries for linker namespace [[0]]:
	  From                To                  Syms Read   Shared Object Library
	  0x00007ffff7fc6000  0x00007ffff7fff000  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7ebc000  0x00007ffff7fa2000  Yes (*)     /lib64/libm.so.6
	  0x00007ffff7cc9000  0x00007ffff7ebc000  Yes (*)     /lib64/libc.so.6
	  (*): Shared library is missing debugging information.

	  There are 4 libraries loaded in linker namespace [[1]]
	  Displaying libraries for linker namespace [[1]]:
	  From                To                  Syms Read   Shared Object Library
	  0x00007ffff7fc6000  0x00007ffff7fff000  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7fb9000  0x00007ffff7fbe000  Yes         gdb.base/dlmopen-ns-ids/dlmopen-lib.so
	  0x00007ffff7bc4000  0x00007ffff7caa000  Yes (*)     /lib64/libm.so.6
	  0x00007ffff79d1000  0x00007ffff7bc4000  Yes (*)     /lib64/libc.so.6
	  (*): Shared library is missing debugging information.

	When called with an argument, the argument must be a namespace
	identifier (either with or without the square brackets decorators). In
	this situation, the command will truncate the output to only show the
	relevant information for the requested namespace. For example:

	  (gdb) info linker-namespaces 0
	  There are 3 libraries loaded in linker namespace [[0]]
	  Displaying libraries for linker namespace [[0]]:
	  From                To                  Syms Read   Shared Object Library
	  0x00007ffff7fc6000  0x00007ffff7fff000  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7ebc000  0x00007ffff7fa2000  Yes (*)     /lib64/libm.so.6
	  0x00007ffff7cc9000  0x00007ffff7ebc000  Yes (*)     /lib64/libc.so.6
	  (*): Shared library is missing debugging information.

	The test gdb.base/dlmopen-ns-id.exp has been extended to test this new
	command.  Because some gcc and glibc defaults can change between
	systems, we are not guaranteed to always have libc and libm loaded in a
	namespace, so we can't guarantee the number of libraries, but the range
	of the result is 2, so we can still check for glaring issues.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-23  Guinevere Larsen  <guinevere@redhat.com>

	gdb: factor out printing a table of solibs for info sharedlibrary
	The next patch will add a new command that will print libraries in a
	manner very similar to the existing "info sharedlibrary" command. To
	make that patch simpler to review, this commit does the bulk of
	refactoring work, since it ends up being a non-trivial diff to review.

	No functional changes are expected after this commit.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-23  Guinevere Larsen  <guinevere@redhat.com>

	gdb: add convenience variables around linker namespace debugging
	This commit adds 2 simple built-in convenience variables to help users
	debug an inferior with multiple linker namespaces. The first is
	$_active_linker_namespaces, which just counts how many namespaces have SOs
	loaded onto them. The second is $_current_linker_namespace, and it tracks
	which namespace the current location in the inferior belongs to.

	This commit also introduces a test ensuring that we track namespaces
	correctly, and that a user can use the $_current_linker_namespace
	variable to set a conditional breakpoint, while linespec changes aren't
	finalized to make it more convenient.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-23  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: print target in print_target_wait_results
	Extend `print_target_wait_results` to print the target from which the
	wait result came.

	Approved-By: Pedro Alves <pedro@palves.net>

2025-04-23  Timur  <timurgol007@gmail.com>

	This commit adds record full support for rv64gc instruction set
	It includes changes to the following files:
	- gdb/riscv-linux-tdep.c, gdb/riscv-linux-tdep.h: adds facilities to record
	syscalls.
	- gdb/riscv-tdep.c, gdb/riscv-tdep.h: adds facilities to record execution of
	rv64gc instructions.
	- gdb/configure.tgt: adds new files for compilation.
	- gdb/testsuite/lib/gdb.exp: enables testing of full record mode for RISC-V
	targets.
	- gdb/syscalls/riscv-canonicalize-syscall-gen.py: a script to generate
	function that canonicalizes RISC-V syscall. This script can simplify support
	for syscalls on rv32 and rv64 system (currently support only for rv64).  To
	use this script you need to pass a path to a file with syscalls description
	from riscv-glibc (example is in the help message). The script produces a
	mapping from syscall names to gdb_syscall enum.
	- gdb/riscv-canonicalize-syscall.c: the file generated by the previous script.
	- gdb/doc/gdb.texinfo: notification that record mode is enabled in RISC-V.
	- gdb/NEWS: notification of new functionality.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-04-23  Sam James  <sam@gentoo.org>

	gdb: fix bashism in configure.ac
	Use '=', not '==', as configure has a #!/bin/sh shebang and must work
	with non-bash shells.

	Fixes: c4375bc51c861dfa384a01bdb2e460e115710bf9

2025-04-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add selftest disassemble-s390x
	In commit a98a6fa2d8e ("s390: Add arch15 instructions"), support for
	new instructions was added to libopcodes, but the added tests only exercise
	this for gas.

	Add a unit test disassemble-s390x that checks gdb's ability to
	disassemble one of these instructions:
	...
	$ gdb -q -batch -ex "maint selftest -v disassemble-s390x"
	Running selftest disassemble-s390x.
	0xb9 0x68 0x00 0x03 -> clzg	%r0,%r3
	Ran 1 unit tests, 0 failed
	...

	Tested on x86_64-linux and s390x-linux.

2025-04-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Update regexp in gdb.debuginfod/fetch_src_and_symbols.exp
	Since commit 7b80401da00 ("Handle DWARF 5 separate debug sections"), test-case
	gdb.debuginfod/fetch_src_and_symbols.exp fails here:
	...
	(gdb) file fetch_src_and_symbols_alt.o^M
	Reading symbols from fetch_src_and_symbols_alt.o...^M
	warning: could not find supplementary DWARF file \
	  (fetch_src_and_symbols_dwz.o) for fetch_src_and_symbols_alt.o^M
	(gdb) FAIL: $exp: no_url: file fetch_src_and_symbols_alt.o
	...
	because this is expected:
	...
	(gdb) file fetch_src_and_symbols_alt.o^M
	Reading symbols from fetch_src_and_symbols_alt.o...^M
	warning: could not find '.gnu_debugaltlink' file for \
	  fetch_src_and_symbols_alt.o^M
	(gdb) PASS: $exp: no_url: file fetch_src_and_symbols_alt.o
	...

	Fix this by updating the regexp.

	Tested on x86_64-linux.

2025-04-23  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Add test for divide by zero in instructions
	Added tests for division/modulo by zero for instruction expressions.

2025-04-23  Alan Modra  <amodra@gmail.com>

	string merge section map output
	This fixes an inconsistency in the linker map file, where string merge
	sections (other than the first) kept their sizes.  String merge
	sections of like entsize all are accounted in the fisrt string merge
	section size.

		* ldlang.c (print_input_section): Print SEC_EXCLUDE section size
		as zero.

2025-04-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-23  Alan Modra  <amodra@gmail.com>

	PR 32603 followup, remove %F from einfo
	No uses of %F remain.

		* ldmisc.c (vfinfo): Remove %F handling.

2025-04-22  Tom Tromey  <tom@tromey.com>

	Add "-5" flag to cc-with-tweaks
	This adds a "-5" flag to cc-with-tweaks, mirroring dwz's "-5" flag,
	and also adds a new cc-with-dwz-5 target board.

	The "-5" flag tells dwz to use the DWARF 5 .debug_sup section in
	multi-file mode.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808

2025-04-22  Tom Tromey  <tom@tromey.com>

	Handle DWARF 5 separate debug sections
	DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in
	multi-file mode.  This is handled via some new forms, and a new
	.debug_sup section.

	This patch adds support for this to gdb.  It is largely
	straightforward, I think, though one oddity is that I chose not to
	have this code search the system build-id directories for the
	supplementary file.  My feeling was that, while it makes sense for a
	distro to unify the build-id concept with the hash stored in the
	.debug_sup section, there's no intrinsic need to do so.

	This in turn means that a few tests -- for example those that test the
	index cache -- will not work in this mode.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808
	Acked-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-22  Tom Tromey  <tom@tromey.com>

	Remove 'read' call from dwz_file::read_string
	dwz_file::read_string calls 'read' on the section, but this isn't
	needed as the sections have all been pre-read.

	This patch makes this change, and refactors dwz_file a bit to make
	this more obvious -- by making it clear that only the "static
	constructor" can create a dwz_file.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix incorrect comment in py-color.exp
	There was a comment in gdb.python/py-color.exp that was probably left
	over from a copy & paste, it incorrectly described what the test
	script was testing.

	Fixed in this commit.

	There's no change in what is tested with this commit.

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: address some coding style issues in py-color.c
	A few minor GNU/GDB coding style issues in py-color.c:

	  - Space after '&' reference operator in one place.
	  - Some excessive indentation on a couple of lines.
	  - Spaces after '!' logical negation operator.
	  - Using a pointer as a bool in a couple of places.

	There should be no functional changes after this commit.

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove stray white space in error message
	Spotted a stray white space at the end of an error message.  Removed,
	and updated the py-breakpoint.exp test to check this case.

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: use @samp{} in Python docs
	In this review:

	  https://inbox.sourceware.org/gdb-patches/86sem6ase5.fsf@gnu.org

	it was pointed out that I should use @samp{} around some text I was
	adding to the documentation.  However, the offending snippet of
	documentation was something I copied from elsewhere in python.texi.
	This commit fixes the original to use @samp{}.

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: fix memory leak of gdb.Color objects
	I noticed that this commit:

	  commit 6447969d0ac774b6dec0f95a0d3d27c27d158690
	  Date:   Sat Oct 5 22:27:44 2024 +0300

	      Add an option with a color type.

	has an unnecessary `Py_INCREF (self);` in gdb.Color.__init__.  This
	means that the reference count on all gdb.Color objects (that pass
	through __init__) will be +1 from where they should normally be, and
	this will stop the gdb.Color objects from being deallocated.

	Fix by removing the Py_INCREF call.

	Add a test which exposes the memory leak.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: restructure the existing memory leak tests
	We currently have two memory leak tests in gdb.python/ and there's a
	lot of duplication between these two.

	In the next commit I'd like to add yet another memory leak test, which
	would mean a third set of scripts which duplicate the existing two.
	And three is where I draw the line.

	This commit factors out the core of the memory leak tests into a new
	module gdb_leak_detector.py, which can then be imported by each
	tests's Python file in order to make writing the memory leak tests
	easier.

	I've also added a helper function to lib/gdb-python.exp which captures
	some of the common steps needed in the TCL file in order to run a
	memory leak test.

	Finally, I use this new infrastructure to rewrite the two existing
	memory leak tests.

	What I considered, but ultimately didn't do, is merge the two memory
	leak tests into a single TCL script.  I did consider this, and for the
	existing tests this would be possible, but future tests might require
	different enough setup that this might not be possible for all future
	tests, and now that we have helper functions in a central location,
	the each individual test is actually pretty small now, so leaving them
	separate seemed OK.

	There should be no change in what is actually being tested after this
	commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-22  Tom Tromey  <tom@tromey.com>

	Remove ui_file::reset_style
	ui_file::reset_style doesn't seem to be needed.  This patch removes
	it.  Regression tested on x86-64 Fedora 40.

2025-04-22  ZENG Hao  <c@cyano.cn>

	gdb: fix ui-style regex initializing order
	This fixes a crash on Windows NT 4.0, where windows-nat failed dynamic loading
	some Win32 functions and print a warning message with styled string, which
	depends on ui-style regex. By using `compiled_regex` constructor, the regex is
	guaranteed to be initialized before `_initialize_xxx` functions.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-22  Jens Remus  <jremus@linux.ibm.com>

	gas: sframe: Fix typo in comment on SFrame identifier
	gas/config/
		* tc-aarch64.c (aarch64_sframe_get_abi_arch): Fix typo in
		comment on SFrame identifier.
		* tc-aarch64.h (aarch64_sframe_get_abi_arch,
		sframe_get_abi_arch): Likewise.
		* tc-i386.c (x86_sframe_get_abi_arch): Likewise.
		* tc-i386.h (x86_sframe_get_abi_arch, sframe_get_abi_arch):
		Likewise.

	Reported-by: Indu Bhagat <indu.bhagat@oracle.com>

2025-04-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix 32889 Typo in documentation
	gprofng/ChangeLog
	2025-04-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* doc/gprofng_ug.texi: Fix typo.

2025-04-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix 32886 wrong mapping from instruction to line number
	On Intel, gprofng should adjusts return addresses, including user leaf functions.

	gprofng/ChangeLog
	2025-04-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/CallStack.cc (add_stack): Adjust return addresses on Intel.

2025-04-22  Michael J. Eager  <eager@eagercon.com>

	MicroBlaze: Make sure we see memory breakpoints before reading
	For linux target, when trying to run a program from gdb, the
	following defect is seen:

	Program received signal SIGILL, Illegal instruction.
	0x48004674 in _dl_debug_state () from target:/lib/ld.so.1

	* microblaze-linux-tdep.c (microblaze_linux_memory_remove_breakpoint):
	  Call make_scoped_restore_show_memory_breakpoints

2025-04-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-21  Alan Modra  <amodra@gmail.com>

	avoid bogus format-overflow error
	Seen on x86_64-linux Ubuntu 24.04.2 using gcc-13.3.0 with
	CFLAGS="-m32 -g -O2 -fsanitize=address,undefined"

	In function ‘sprintf’,
	    inlined from ‘s_mri_for’ at gas/config/tc-m68k.c:6941:5:
	/usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
	   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
	      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	   31 |                                   __glibc_objsize (__s), __fmt,
	      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	   32 |                                   __va_arg_pack ());
	      |                                   ~~~~~~~~~~~~~~~~~

	Rewrite the code without sprintf, as in other parts of s_mri_for.
	See also commit 760fb390fd4c and following commits.

	Note that adding -D_FORTIFY_SOURCE=0 to CFLAGS (which is a good idea
	when building with sanitizers) merely transforms the sprintf_chk error
	here into one regarding plain sprintf.

2025-04-21  Alan Modra  <amodra@gmail.com>

	bfd_check_format_matches error paths
	Tidy early out errors which didn't free matching_vector.  Don't
	bfd_preserve_restore if we get to err_ret from the first
	bfd_preserve_save, which might fail from a memory allocation leaving
	preserve.marker NULL.  Also take bfd_lock a little earlier before
	modifying abfd->format to simplify error return path from a lock
	failure.

	rescoff: close bfd on failure paths
	Also free malloc'd relocs.

2025-04-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: make some more functions methods of cutu_reader
	These are only used by cutu_reader, so make them methods of cutu_reader.
	This makes it a bit more obvious in which context this code is called.

	lookup_dwo_unit_in_dwp can't be made a method of cutu_reader, as it is
	used in another context (lookup_dwp_signatured_type /
	lookup_signatured_type), which happens during CU expansion.

	Change-Id: Ic62c3119dd6ec198411768323aaf640ed165f51b
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: look up .dwp file ahead of time
	get_dwp_file lazily looks for a .dwp file for the given objfile.  It is
	called by indexing workers, when a cutu_reader object looks for a DWO
	file.  It is called with the "dwo_lock" held, meaning that the first
	worker to get there will do the work, while the others will wait at the
	lock.

	I'm trying to reduce the time where this lock is taken and do other
	refactorings to make it easier to reason about the DWARF reader code.
	Moving the lookup of the .dwp file ahead, before we start parallelizing
	work, helps makes things simpler, because we can then assume everywhere
	else that we have already checked for a .dwp file.

	Put the call to open_and_init_dwp_file in dwarf2_has_info, right next to
	where we look up .dwz files.  I used the same try-catch pattern as for
	the .dwz file lookup.

	Change-Id: I615da85f62a66d752607f0dbe9f0372dfa04b86b
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: replace some per_objfile parameters with per_bfd
	Following a previous patch, these functions can accept a per_bfd
	instead of a per_objfile.

	Change-Id: Iacc8924d2e49a05920d9a7fde2f7584f709fbdd2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: pass section to create_dwp_hash_table
	Instead of passing a boolean to create_dwp_hash_table to select the
	section to read, it's simpler to just pass the section.

	Change-Id: Ie043c31e80518239f6403288dcf03f7769c58e8c
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary dwarf2_section_info:::read calls
	The sections would have been read already in
	dwarf2_locate_common_dwp_sections or dwarf2_locate_dwo_sections, with
	this call:

	    dw_sect->read (objfile);

	Change-Id: Ice0ed5d9a2070967826a59b2d6f724451ace22f4
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove per_objfile parameter from read_and_check_comp_unit_head
	It is no longer needed.

	Change-Id: I22b21b12dc9f74a423bca355d4d83f0167e75f34
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove dwarf2_section_info::get_size
	The comment over dwarf2_section_info::get_size says:

	    In other cases, you must call this function, because for compressed
	    sections the size field is not set correctly until the section has
	    been read

	From what I can see (while debugging a test case compiled with -gz on
	Linux), that's not true.  For compressed sections, bfd_section_size
	returns the uncompressed size.  asection::size contains the uncompressed
	size while asection::compressed_size contains the compressed size:

	    (top-gdb) p sec
	    $13 = (asection *) 0x521000119778
	    (top-gdb) p sec.compressed_size
	    $14 = 6191
	    (top-gdb) p sec.size
	    $15 = 12116

	I therefore propose to remove dwarf2_section_info::get_size, as it
	appears that reading in the section is orthogonal to knowing its size.

	If the assumption above is false, it would be nice to document in which
	case it's false.

	I checked the callers, and I don't think that we need to add any
	dwarf2_section_info::read calls to compensate for the fact that get_size
	used to do it.

	Change-Id: I428571e532301d49f1d8242d687e1fcb819b75c1
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-19  Tom Tromey  <tom@tromey.com>

	Remove some obsolete comments from ada-varobj.c
	I noticed a few spots in ada-varobj.c that refer to calling xfree,
	where the type in question has changed to std::string.  This patch
	removes these obsolete comments.

2025-04-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32885 gprofng --help should state where to report bugs
	gprofng/ChangeLog
	2025-04-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/gp-archive.cc: Fix the --help output.
		* src/gp-collect-app.cc: Likewise.
		* src/gp-display-src.cc: Likewise.
		* src/gp-display-text.cc: Likewise.
		* src/gprofng.cc: Likewise.

2025-04-18  Alan Modra  <amodra@gmail.com>

	build error with 32-bit host and 64-bit time_t
	A fix for commit c4fce3ef2927.

	loongarch gas resolving constant expressions
	The test added in commit 4fe96ddaf614 results in an asan complaint:
	loongarch-parse.y:225:16: runtime error: left shift of negative value -1
	To avoid the complaint, perform left shifts as unsigned (which gives
	the same result on 2's complement machines).  Do the same for
	addition, subtraction and multiplication.  Furthermore, warn on
	divide/modulus by zero.

2025-04-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't run to main in gdb.cp/cplusfuncs.exp
	After building gdb with -fsanitize=threads, and running test-case
	gdb.cp/cplusfuncs.exp, I run into a single timeout:
	...
	FAIL: gdb.cp/cplusfuncs.exp: info function operator=( (timeout)
	...
	and the test-case takes 2m33s to finish.

	This is due to expanding CUs from libstdc++.

	After de-installing package libstdc++6-debuginfo, the timeout disappears and
	testing time goes down to 9 seconds.

	Fix this by not running to main, which brings testing time down to 3 seconds.

	With a gdb built without -fsanitize=threads, testing time goes down from 11
	seconds to less than 1 second.

	Tested on x86_64-linux.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-04-17  Tom Tromey  <tromey@adacore.com>

	Clean up value_struct_elt_bitpos
	value_struct_elt_bitpos is weird: it takes an in/out value parameter,
	and it takes an error string parameter.  However, it only has a single
	caller, which never uses the "out" value.

	I think it was done this way to mimic value_struct_elt.  However,
	value_struct_elt is pretty ugly and I don't think it's worth
	imitating.

	This patch cleans up value_struct_elt_bitpos a bit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-17  Yury Khrustalev  <yury.khrustalev@arm.com>

	testsuite: fix typo in bti-plt-1-b.d test
	This test is not supposed to use -z force-bti

	aarch64: ld: add tests for combination of bti and memory-seal
	Both BTI and memory sealing require use of GNU properties and
	we should check that there is no interference.

2025-04-17  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: ld: Fix scanning of GNU properties for AARCH64_FEATURE_1_AND
	Fixes [1]. Previously iteration over GNU properties of an input file
	could stop before reaching GNU_PROPERTY_AARCH64_FEATURE_1_AND which
	would result in incorrect inference of properties of the output file.

	In the particular use case described in [1], the memory seal property
	GNU_PROPERTY_MEMORY_SEAL with number 3, if present in the input file,
	prevented reading information from GNU_PROPERTY_AARCH64_FEATURE_1_AND
	property due to filtering by property number.

	[1] PR32818 https://sourceware.org/bugzilla/show_bug.cgi?id=32818

2025-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/clone-attach-detach.exp
	With test-case gdb.threads/clone-attach-detach.exp I usually get:
	...
	(gdb) attach <pid> &^M
	Attaching to program: clone-attach-detach, process <pid>^M
	[New LWP <lwp>]^M
	(gdb) PASS: $exp: bg attach <n>: attach
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	...
	but sometimes I run into:
	...
	(gdb) attach <pid> &^M
	Attaching to program: clone-attach-detach, process <pid>^M
	[New LWP <lwp>]^M
	(gdb) [Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	FAIL: $exp: bg attach <n>: attach (timeout)
	...

	I managed to reproduce this using make target check-readmore and
	READMORE_SLEEP=100.

	Fix this using -no-prompt-anchor.

	Tested on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix bugs in gdb/copyright.py, make it use glob patterns
	gdb/copyright.py currently changes some files that it shouldn't:

	 - despite having a `gnulib/import` entry in EXCLUDE_LIST, it does
	   change the files under that directory
	 - it is missing `sim/Makefile.in`

	Change the exclude list logic to use glob patterns.  This makes it
	easier to specify exclusions of full directories or files by basename,
	while simplifying the code.

	Merge EXCLUDE_LIST and NOT_FSF_LIST, since there's no fundamental reason
	to keep them separate (they are treated identically).  I kept the
	comment that explains that some files are excluded due to not being
	FSF-licensed.

	Merge EXCLUDE_ALL_LIST in EXCLUDE_LIST, converting the entries to glob
	patterns that match everywhere in the tree (e.g. `**/configure`).

	Tested by running the script on the parent commit of d01e823438c7
	("Update copyright dates to include 2025") and diff'ing the result with
	d01e823438c7.  The only differences are:

	 - the files that we don't want to modify (gnulib/import and
	   sim/Makefile.in)
	 - the files that need to be modified by hand

	Running the script on latest master produces no diff.

	Change-Id: I318dc3bff34e4b3a9b66ea305d0c3872f69cd072
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make typing strict in gdb/copyright.py
	Add `pyright: strict` at the top of the file, then adjust the fallouts.
	This annotation is understood by pyright, and thus any IDE using pyright
	behind the scenes (VSCode and probably others).

	I presume that any GDB developer running this script is using a recent
	enough version of Python, so specify the type annotations using the
	actual types when possible (e.g. `list[str]` instead of
	`typing.List[str]`).  I believe this required Python 3.9.

	Change-Id: I3698e28555e236a03126d4cd010dae4b5647ce48
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-04-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp
	With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a
	timeout:
	...
	(gdb) c 1&
	Will stop next time breakpoint 1 is reached.  Continuing.
	(gdb) PASS: $exp: c 1&: c 1&

	Breakpoint 2, foo () at bg-execution-repeat.c:23
	23        return 0; /* set break here */
	PASS: $exp: c 1&: breakpoint hit 1

	Will stop next time breakpoint 2 is reached.  Continuing.
	(gdb) PASS: $exp: c 1&: repeat bg command
	print 1
	$1 = 1
	(gdb) PASS: $exp: c 1&: input still accepted
	interrupt
	(gdb) PASS: $exp: c 1&: interrupt

	Program received signal SIGINT, Interrupt.
	foo () at bg-execution-repeat.c:24
	24      }
	PASS: $exp: c 1&: interrupt received
	set var do_wait=0
	(gdb) PASS: $exp: c 1&: set var do_wait=0
	continue&
	Continuing.
	(gdb) PASS: $exp: c 1&: continue&
	FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
	...

	I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1"
	in the .c file.

	The timeout happens as follows:
	- with the inferior stopped at main, gdb continues (command c 1&)
	- the inferior hits the breakpoint at foo
	- gdb continues (using the repeat command functionality)
	- the inferior is interrupted
	- inferior variable do_wait gets set to 0.  The assumption here is that the
	  inferior has progressed enough that do_wait is set to 1 at that point, but
	  that happens not to be the case.  Consequently, this has no effect.
	- gdb continues
	- the inferior sets do_wait to 1
	- the inferior enters the wait function, and wait for do_wait to become 0,
	  which never happens.

	Fix this by moving the "do_wait = 1" to before the first call to foo.

	Tested on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2025-04-16  Alan Modra  <amodra@gmail.com>

	buffer overrun in read_coff_res_dir
		* rescoff.c (read_coff_res_dir): Add more sanity checking.
		Tidy and correct existing checks.

	resbin.c formatting fixes
	Also remove unnecessary casts on memory alloc function returns.

	Re: windres: buffer overflow in bin_to_res_toolbar
	Commit 9e68cae4fdfb broke the check I added in commit 4846e543de95.
	Add missing "return NULL".

2025-04-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-16  Tom Tromey  <tom@tromey.com>

	Use gdb::unordered_set for Ada symbol cache
	This changes the Ada symbol cache to use gdb::unordered_set rather
	than an htab.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-15  Tom Tromey  <tom@tromey.com>

	Use gdb::string_set for decoded_names_store
	This patch changes decoded_names_store to use a gdb::string_set rather
	than an htab.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-15  Tom de Vries  <tdevries@suse.de>

	[gdb/ada] Fix gdb.ada/overloads.exp on s390x
	On s390x-linux, with test-case gdb.ada/overloads.exp and gcc 7.5.0 I run into:
	...
	(gdb) print Oload(CA)^M
	Could not find a match for oload^M
	(gdb) FAIL: $exp: print Oload(CA)
	...

	The mismatch happens here in ada_type_match:
	...
	      return ftype->code () == atype->code ();
	...
	with:
	...
	(gdb) p ftype->code ()
	$3 = TYPE_CODE_TYPEDEF
	(gdb) p atype->code ()
	$4 = TYPE_CODE_ARRAY
	...

	At the start of ada_type_match, typedefs are skipped:
	...
	  ftype = ada_check_typedef (ftype);
	  atype = ada_check_typedef (atype);
	...
	but immediately after this, refs are skipped:
	...
	  if (ftype->code () == TYPE_CODE_REF)
	    ftype = ftype->target_type ();
	  if (atype->code () == TYPE_CODE_REF)
	    atype = atype->target_type ();
	...
	which in this case makes ftype a typedef.

	Fix this by using ada_check_typedef after skipping the refs as well.

	Tested on x86_64-linux and s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR ada/32409
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32409

2025-04-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/scalar_storage.exp on s390x
	On s390x-linux, with test-case gdb.ada/scalar_storage.exp we have:
	...
	(gdb) print V_LE^M
	$1 = (value => 126, another_value => 12, color => 3)^M
	(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_LE
	print V_BE^M
	$2 = (value => 125, another_value => 9, color => green)^M
	(gdb) KFAIL: $exp: print V_BE (PRMS: DW_AT_endianity on enum types)
	...

	The KFAIL is incorrect in the sense that gdb is behaving as expected.

	The problem is incorrect debug info, so change this into an xfail.

	Furthermore, extend the xfail to cover V_LE.

	Tested on s390x-linux and x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/32875
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32875

2025-04-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: skip type units in create_dwo_cus_hash_table
	When compiling with -gsplit-dwarf -fdebug-types-section, DWARF 5
	.debug_info.dwo sections may contain some type units:

	    $ llvm-dwarfdump -F -color a-test.dwo | head -n 5
	    a-test.dwo:     file format elf64-x86-64

	    .debug_info.dwo contents:
	    0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector<int, std::allocator<int> >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4)

	In this case, create_dwo_cus_hash_table wrongly creates a dwo_unit for
	it and adds it to dwo_file::cus.  create_dwo_debug_type_hash_table later
	correctly creates a dwo_unit that it puts in dwo_file::tus.

	This can be observed with:

	    $ ./gdb  -nx -q --data-directory=data-directory -ex 'maint set dwarf sync on' -ex "maint set worker-threads 0" -ex "set debug dwarf-read 2" -ex "file a.out" -batch
	    ...
	    [dwarf-read] create_dwo_cus_hash_table: Reading .debug_info.dwo for /home/smarchi/build/binutils-gdb/gdb/a-test.dwo:
	    [dwarf-read] create_dwo_cus_hash_table:   offset 0x0, dwo_id 0xb499dcf29e2928c4
	    [dwarf-read] create_dwo_cus_hash_table:   offset 0x8a4, dwo_id 0x496a8791a842701b
	    [dwarf-read] create_dwo_cus_hash_table:   offset 0x941, dwo_id 0xefd13b3f62ea9fea
	    ...
	    [dwarf-read] create_dwo_debug_type_hash_table: Reading .debug_info.dwo for /home/smarchi/build/binutils-gdb/gdb/a-test.dwo
	    [dwarf-read] create_dwo_debug_type_hash_table:   offset 0x0, signature 0xb499dcf29e2928c4
	    [dwarf-read] create_dwo_debug_type_hash_table:   offset 0x8a4, signature 0x496a8791a842701b
	    [dwarf-read] create_dwo_debug_type_hash_table:   offset 0x941, signature 0xefd13b3f62ea9fea
	    ...

	Fix it by skipping anything that isn't a compile unit in
	create_dwo_cus_hash_table.  After this patch, the debug output of
	create_dwo_cus_hash_table only shows one created dwo_unit, as we expect.

	I couldn't find any user-visible problem related to this, I just noticed
	it while debugging.

	Change-Id: I7dddf766fe1164123b6702027b1beb56114f25b1
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-04-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename some functions to specify "dwo"
	Rename some functions to make it clearer that they are only relevant
	when dealing with DWO files.

	Change-Id: Ia0cd3320bf16ebdbdc3c09d7963f372e6679ef7c
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-04-15  Marek Pikuła  <m.pikula@partner.samsung.com>

	RISC-V: Add missing disassembler option `max`
	The flag already exists but it's not been exposed to user.

2025-04-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-14  Alan Modra  <amodra@gmail.com>

	PR 32871 ld/ldmain.c#L425 incorrect location of #endif
	Fix commit c4fce3ef2927 brace position.

	windres: don't exit so much on errors in read_coff_rsrc
	windres code has the habit of exiting on any error.  That's not so
	bad, but it does make oss-fuzz ineffective when testing windres.  Fix
	many places that print errors and exit to instead print the error and
	pass status up the call chain.  In the process of doing this, I
	noticed write_res_file was calling bfd_close without checking return
	status.  Fixing that resulted in lots of testsuite failures.  The
	problem was a lack of bfd_set_format in windres_open_as_binary, which
	leaves the output file as bfd_unknown format.  As it happens this
	doesn't make any difference in writing the output binary file, except
	for the bfd_close return status.

	windres: buffer overflow in bin_to_res_toolbar
	oss-fuzz testcase manages to hit a buffer overflow.  Sanity check
	by passing the buffer length to bin_to_res_toolbar and ensuring reads
	don't go off the end of the buffer.

	Re: ld: Skip the LTO archive member only for the earlier DSO
	Add -fPIC when compiling the test, to fix complaints on some targets
	about certains relocation not being valid for shared libraries.

2025-04-14  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Add gdb.arch/aarch64-sve-sigunwind.exp
	There's currently no test for unwinding the SVE registers from a signal
	frame, so add one.

	Tested on aarch64-linux-gnu native.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2025-04-14  Jan Beulich  <jbeulich@suse.com>

	ld/PE: restrict non-zero default DLL characteristics to MinGW
	While commit ef6379e16dd1 ("Set the default DLL chracteristics to 0 for
	Cygwin based targets") tried to undo the too broad earlier 514b4e191d5f
	("Change the default characteristics of DLLs built by the linker to more
	secure settings"), it didn't go quite far enough. Apparently the
	assumption was that if it's not MinGW, it must be Cygwin. Whether it
	really is okay to default three of the flags to non-zero on MinGW also
	remains unclear - sadly neither of the commits came with any description
	whatsoever. (Documentation also wasn't updated to indicate the restored
	default.)

	Setting effectively any of the DLL characteristics flags depends on
	properties of the binary being linked. While defaulting to "more secure"
	is a fair goal, it's only the programmer who can know whether their code
	is actually compatible with the respective settings. On the assumption
	that the change of defaults was indeed deliberate (and justifiable) for
	MinGW, limit them to just that. In particular, don't default any of the
	flags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At
	least the mere applicability of the high-entropy-VA bit is pretty
	questionable there in the first place - UEFI applications, after all,
	run in "physical mode", i.e. either unpaged or (where paging is a
	requirement, like for x86-64) direct-mapped.

	The situation is particularly problematic with NX-compat: Many UEFI
	implementations respect the "physical mode" property, where permissions
	can't be enforced anyway. Some, like reportedly OVMF, even have a build
	option to behave either way. Hence successfully testing a UEFI binary on
	any number of systems does not guarantee it won't crash elsewhere if the
	flag is wrongly set.

	Get rid of excess semicolons as well.

2025-04-14  Jan Beulich  <jbeulich@suse.com>

	bfd/ELF/x86: avoid layering violation in link hash table entry init
	There's no reason not to do as the comment says, just like all other
	architectures do when they need custom field: Call the allocation method
	of the "superclass". Which is the ELF one, of which in turn the BFD one
	is the "superclass", dealt with accordingly by
	_bfd_elf_link_hash_newfunc().

	bfd/aout: drop add_one_symbol() hook
	The need for this has disappeared with c65c21e1ffd1 ("various i386-aout
	and i386-coff target removal"), with a few other users having got
	removed just a few days earlier; avoid the unnecessary indirection.

2025-04-14  Jan Beulich  <jbeulich@suse.com>

	bfd/COFF: propagate function size when copying/linking ELF objects
	While COFF, unlike ELF, doesn't have a generic way to express symbol
	size, there is a means to do so for functions. When inputs are ELF,
	propagate function sizes, including the fact that a symbol denotes a
	function, to the output's symbol table.

	Note that this requires hackery (cross-object-format processing) in two
	places - when linking, global symbols are entered into a global hash
	table, and hence relevant information needs to be updated there in that
	case, while otherwise the original symbol structures can be consulted.

	For the setting of ->u.syment.n_type the later writing of the field to
	literal 0 needs to be dropped from coff_write_alien_symbol(). It was
	redundant anyway with an earlier write of the field using C_NUL.

2025-04-14  Jan Beulich  <jbeulich@suse.com>

	x86: move PadLock enumerators
	... to be all in one group. This helps code generation for code like

	      || is_cpu (&i.tm, CpuPadLock)
	      || is_cpu (&i.tm, CpuPadLockRNG2)
	      || is_cpu (&i.tm, CpuPadLockPHE2)
	      || is_cpu (&i.tm, CpuPadLockXMODX)

	that we have (effectively) twice.

2025-04-14  Piotr Rudnicki  <piotr.rudnicki@intel.com>

	gdb: add check for empty array
	With the command before the change, gdb crashes with message:
	(gdb) p 1 == { }
	Fatal signal: Segmentation fault

	After the fix in this commit, gdb shows following message:
	(gdb) p 1 == { }
	size of the array element must not be zero

	Add new test cases to file gdb.base/printcmds.exp to test this change

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: add an assert to cmd_list_element constructor
	The cmd_list_element::doc variable must be non-nullptr, otherwise, in
	`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run
	one of these lines:

	      gdb_puts (c->doc, stream);

	or,

	      gdb_puts (alias->doc, stream);

	as gdb_puts requires that the first argument (the doc string) be
	non-nullptr.

	Better, I think, to assert when the cmd_list_element is created,
	rather than catching an assert later when 'help CMD' is used.

	I only ran into this case when messing with the Python API command
	creation code, I accidentally created a command with a nullptr doc
	string, and only found out when I ran 'help CMD' and got an
	assertion.

	While I'm adding this assertion, I figure I should also assert that
	the command name is not nullptr too.  Looking through cli-decode.c,
	there seems to be plenty of places where we assume a non-nullptr name.

	Built and tested on x86-64 GNU/Linux with an all-targets build; I
	don't see any regressions, so (I hope) there are no commands that
	currently violate this assertion.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-13  WANG Xuerui  <git@xen0n.name>

	LoongArch: Support LA32R aliases rdcnt{vl,vh,id}.w
	These LA32R instructions are in fact special cases of the LA32S/LA64
	rdtime{l,h}.w (with only one output operand instead of two, the other
	one being forced to $zero), but are named differently in the LA32R
	ISA manual nevertheless.

	As the LA32R names are more memorable to a degree (especially for those
	having difficulties remembering which operand corresponds to the node
	ID), support them by making them aliases of the corresponding LA32S/LA64
	instruction respectively, and make them render as such in disassembly.

2025-04-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-12  Piotr Rudnicki  <piotr.rudnicki@intel.com>

	gdb: add Piotr Rudnicki to gdb/MAINTAINERS

2025-04-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: silence some 'Can't open file' warnings from core file loading
	But PR gdb/20126 highlights a case where GDB emits a large number of
	warnings like:

	  warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing
	  warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing
	  warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing
	  warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing
	  ... etc ...

	when opening a core file.  This commit aims to avoid at least some of
	these warnings.

	What we know is that, for at least some of these cases, (e.g. the
	'(deleted)' mappings), the content of the mapping will have been
	written into the core file itself.  As such, the fact that the file
	isn't available ('/SYSV604b7d00' at least is a shared memory mapping),
	isn't really relevant, GDB can still provide access to the mapping, by
	reading the content from the core file itself.

	What I propose is that, when processing the file backed mappings, if
	all of the mappings for a file are covered by segments within the core
	file itself, then there is no need to warn the user that the file
	can't be opened again.  The debug experience should be unchanged, as
	GDB would have read from the in-core mapping anyway.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30126

2025-04-11  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add forward declarations in maint.h
	Editing maint.h with clangd shows some errors about obj_section and
	objfile being unknown.  Add some forward declarations for them.

	Change-Id: Ic4dd12a371198fdf740892254a8f2c1fae2846b9

2025-04-11  Andrew Burgess  <aburgess@redhat.com>

	bfd: fix missing warnings from bfd_check_format_matches
	In PR gdb/31846 the user reported an issue where GDB is unable to find
	the build-id within an ELF, despite the build-id being
	present (confirmed using readelf).

	The user was able to try several different builds of GDB, and in one
	build they observed the warning:

	  warning: BFD: FILENAME: unable to decompress section .debug_info

	But in may other builds of GDB this warning was missing.

	There are, I think, a couple of issues that the user is running into,
	but this patch is about why the above warning is often missing from
	GDB's output.

	I wasn't able to reproduce a corrupted .debug_info section such that
	the above warning would be triggered, but it is pretty easy to patch
	the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that
	the call to bfd_init_section_decompress_status is reported as a
	failure, thus triggering the warning.  There is a patch that achieves
	this in the bug report.

	I did this, and can confirm that on my build of GDB, I don't see the
	above warning, even though I can confirm that the _bfd_error_handler
	call (in _bfd_elf_make_section_from_shdr) is being reached.

	The problem is back in format.c, in bfd_check_format_matches.  This
	function intercepts all the warnings and places them into a
	per_xvec_messages structure.  These warnings are then printed with a
	call to print_and_clear_messages.

	If bfd_check_format_matches finds a single matching format, then
	print_and_clear_messages, will print all warnings associated with that
	single format.

	But if no format matches, print_and_clear_messages will print all the
	warnings, so long as all targets have emitted the same set of
	warnings, and unfortunately, that is not the case for me.

	The warnings are collected by iterating over bfd_target_vector and
	trying each target.  My target happens to be x86_64_elf64_vec, and, as
	expected this target appears in bfd_target_vector.

	However, bfd_target_vector also includes DEFAULT_VECTOR near the top.
	And in my build, DEFAULT_VECTOR is x86_64_elf64_vec.  Thus, for me,
	the x86_64_elf64_vec entry appears twice in bfd_target_vector, this
	means that x86_64_elf64_vec ends up being tried twice, and, as each
	try generates one warning, the x86_64_elf64_vec entry in the
	per_xvec_messages structure, has two warnings, while the other
	per_xvec_messages entries only have one copy of the warning.

	Because of this difference, print_and_clear_messages decides not to
	print any of the warnings, which is not very helpful.

	I considered a few different approaches to fix this issue:

	We could de-duplicate warnings in the per_xvec_messages structure as
	new entries are added.  So for any particular xvec, each time a new
	warning arrives, if the new warning is identical to an existing
	warning, then don't record it.  This might be an interesting change in
	the future, but for now I rejected this solution as it felt like a
	bodge, the duplicate warnings aren't really from a single attempt at
	an xvec, but are from two distinct attempts at the same xvec. And so:

	I wondered if we could remove the duplicate entries from
	bfd_target_vector.  Or if we could avoid processing the same xvec
	twice maybe?  For the single DEFAULT_VECTOR this wouldn't be too hard
	to do, but bfd_target_vector also includes SELECT_VECS, which I think
	could contain more duplicates.  Changing bfd_check_format_matches to
	avoid attempting any duplicate vectors would now require more
	complexity than a single flag, and I felt there was an easier
	solution, which was:

	I propose that within bfd_check_format_matches, within the loop that
	tries each entry from bfd_target_vector, as we switch to each vector
	in turn, we should delete any existing warnings within the
	per_xvec_messages structure for the target vector we are about to try.

	This means that, if we repeat a target, only the last set of warnings
	will survive.

	With this change in place, print_and_clear_messages now sees the same
	set of warnings for each target, and so prints out the warning
	message.

	Additionally, while I was investigating this issue I managed to call
	print_and_clear_messages twice.  This caused a crash because the first
	call to print_and_clear_messages frees all the associated memory, but
	leaves the per_xvec_messages::next field pointing to the now
	deallocated object.  I'd like to propose that we set the next field to
	NULL in print_and_clear_messages.  This clearly isn't needed so long
	as print_and_clear_messages is only called once, but (personally) I
	like to set pointers back to NULL if the object they are pointing to
	is free and the parent object is going to live for some additional
	time.  I can drop this extra change if people don't like it.

	This change doesn't really "fix" PR gdb/31846, but it does mean that
	the warning about being unable to decompress .debug_info should now be
	printed consistently, which is a good thing.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846

	Reviewed-By: Alan Modra <amodra@gmail.com>

2025-04-11  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: fix gdb.base/dlmopen-ns-ids.exp racy test
	The recently included gdb.base/dlmopen-ns-ids.exp test can sometimes
	fail the call to get_integer_valueof when trying to check the namespace
	ID of the fourth dlopened SO, for apparently no reason.

	What's happening is that the call to get_first_so_ns doesn't necessarily
	consume the GDB prompt, and so get_integer_valueof will see the prompt
	immediately and not find the value the test is looking for.

	To fix this, the test was changed so that we consume all of the output
	of the command "info sharedlibrary", but only set the namespace ID for
	the first occurrence of the SO we're looking for.  The command now also
	gets the solib name as a parameter, to reduce the amount of output.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-10  H.J. Lu  <hjl.tools@gmail.com>

	ld: Skip the LTO archive member only for the earlier DSO
	commit 2707d55e539ef323dd14a1293e762bf3d9739ee7
	Author: Michael Matz <matz@suse.de>
	Date:   Mon Mar 31 15:57:08 2025 +0200

	skipped the LTO archive member even when the earlier item is also an
	archive.  Instead, skip the LTO archive member only if the earlier item
	is a shared library.

	bfd/

		PR ld/32846
		PR ld/32854
		* elflink.c (elf_link_add_archive_symbols): Skip the LTO archive
		member only if the earlier item is a shared library.

	ld/

		PR ld/32846
		PR ld/32854
		* testsuite/ld-plugin/lto.exp: Run ld/32846 test.
		* testsuite/ld-plugin/pr32846a.c: New file.
		* testsuite/ld-plugin/pr32846b.c: Likewise.
		* testsuite/ld-plugin/pr32846c.c: Likewise.
		* testsuite/ld-plugin/pr32846d.c: Likewise.
		* testsuite/ld-plugin/pr32846e.c: Likewise.

2025-04-10  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Fix typo in cli-dump.c
	Fix the folowing typo:
	...
	$ codespell --config gdb/contrib/setup.cfg gdb/cli
	gdb/cli/cli-dump.c:400: useable ==> usable
	...
	and add gdb/cli to the pre-commit codespell configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-10  Tom de Vries  <tdevries@suse.de>

	[gdb/unittests] Ignore spellcheck warning in rsp-low-selftests.c
	Ignore the following spellcheck warning:
	...
	$ codespell --config gdb/contrib/setup.cfg gdb/unittests
	gdb/unittests/rsp-low-selftests.c:54: fo ==> of, for, to, do, go
	...
	and add gdb/unittests to the pre-commit codespell configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-10  Tom de Vries  <tdevries@suse.de>

	[gdb/config] Fix codespell warnings
	Fix the following codespell warnings:
	...
	$ codespell --config gdb/contrib/setup.cfg gdb/config
	gdb/config/djgpp/README:178: unitialized ==> uninitialized
	gdb/config/djgpp/djconfig.sh:126: conatain ==> contain
	...
	and add gdb/config to the pre-commit codespell configuration.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-10  Alan Modra  <amodra@gmail.com>

	PR32858 ld segfault on fuzzed object
	We missed one place where it is necessary to check for empty groups.

		PR 32858
		* elflink.c (elf_gc_sweep): Protect against empty group.

2025-04-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/fission-with-type-unit.exp with remote host
	When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote
	host configuration, say host board local-remote-host and target board
	remote-gdbserver-on-localhost, I run into:
	...
	(gdb) maint expand-symtabs^M
	During symbol reading: Could not find DWO CU \
	  fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \
	  [in module /home/remote-host/fission-with-type-unit]^M
	warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \
	  by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M
	(gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs
	...

	Fix this by adding the missing download to remote host of the .dwo file.

	Tested by running make-check-all.sh on x86_64-linux.

2025-04-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-09  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64 tests: escape dot in regex pattern to really match a dot

2025-04-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: fix copyright years in gdb.dwarf2/fission-with-type-unit.{c,exp}
	When writing the test, I copied these copyright entries from another
	file but forgot to adjust the dates, do that now.

	Change-Id: Ie458ad4ec81062b5ef24f78334f3d0920c99b318

2025-04-09  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: fix Makefile.in copyright dates
	Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
	changed the dates in Makefile.in.  Re-run `autoreconf` in the gdbsupport
	directory to fix that up.

	Change-Id: Ifcdb6f2257e7a456439dfc3e7848db934a4b16b4

2025-04-09  Simon Marchi  <simon.marchi@efficios.com>

	sim: fix Makefile.in copyright dates
	Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
	changed the dates in Makefile.in.  Re-run `autoreconf` in the sim
	directory to fix that up.

	Change-Id: Ia02a54e5330d77b490cc7745eee3d281c7888eec

2025-04-09  Simon Marchi  <simon.marchi@efficios.com>

	gnulib: revert copyright date changes in imported files
	Commit d01e823438 ("Update copyright dates to include 2025") changed the
	dates in the gnulib imported source files, it probably shouldn't have.
	Re-run update-gnulib.sh to restore those files.

	gnulib/Makefile.in was also incorrectly modified, running the script
	fixes that too.

	Change-Id: I5d081f3438b9480130a92f59fd9fede33c121f9c

2025-04-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow thread exited message in gdb.threads/infcall-from-bp-cond-simple.exp
	With a gdb 15.2 based package and test-case
	gdb.threads/infcall-from-bp-cond-simple.exp, I ran into:
	...
	Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \
	  infcall-from-bp-cond-simple.c:51
	51        return 1;     /* Nested breakpoint.  */
	Error in testing condition for breakpoint 2:
	The program being debugged stopped while in a function called from GDB.
	Evaluation of the expression containing the function
	(function_with_breakpoint) will be abandoned.
	When the function is done executing, GDB will silently stop.
	[Thread 0x7ffff73fe6c0 (LWP 951822) exited]
	(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
	  run_bp_cond_hits_breakpoint: continue
	...

	The test fails because it doesn't expect the "[Thread ... exited]" message.

	I have tried to reproduce this test failure, both using 15.2 and current
	trunk, but haven't managed.

	Regardless, I think the message is harmless, so allow it to occur, both in
	run_bp_cond_segfaults and run_bp_cond_hits_breakpoint.

	Tested on x86_64-linux.

	PR testsuite/32785
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32785

2025-04-09  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle DW_OP_entry_value at function entry
	On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into:
	...
	(gdb) p sizeof (a)^M
	$2 = <optimized out>^M
	(gdb) FAIL: $exp: o1: printed size of optimized out vla
	...

	The variable a has type 0xbf:
	...
	 <1><bf>: Abbrev Number: 12 (DW_TAG_array_type)
	    <c0>   DW_AT_type        : <0xe3>
	    <c4>   DW_AT_sibling     : <0xdc>
	 <2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type)
	    <c9>   DW_AT_type        : <0xdc>
	    <cd>   DW_AT_upper_bound : 13 byte block:
	                               a3 1 5a 23 1 8 20 24 8 20 26 31 1c
				       (DW_OP_entry_value: (DW_OP_reg10 (a0));
				        DW_OP_plus_uconst: 1; DW_OP_const1u: 32;
					DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
					DW_OP_lit1; DW_OP_minus)
	...
	which has an upper bound using a DW_OP_entry_value, and since the
	corresponding call site contains no information to resolve the value of a0 at
	function entry:
	...
	 <2><6b>: Abbrev Number: 6 (DW_TAG_call_site)
	    <6c>   DW_AT_call_return_pc: 0x638
	    <74>   DW_AT_call_origin : <0x85>
	...
	evaluting the dwarf expression fails, and we get <optimized out>.

	My first thought was to try breaking at *f1 instead of f1 to see if that would
	help, but actually the breakpoint resolved to the same address.

	In other words, the inferior is stopped at function entry.

	Fix this by resolving DW_OP_entry_value when stopped at function entry by
	simply evaluating the expression.

	This handles these two cases (x86_64, using reg rdi):
	- DW_OP_entry_value: (DW_OP_regx: 5 (rdi))
	- DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4)

	Tested on x86_64-linux.

	Tested gdb.base/vla-optimized-out.exp on riscv64-linux.

	Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on
	riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so
	I haven't tested the current version there.

2025-04-09  Jens Remus  <jremus@linux.ibm.com>

	s390: Add support for z17 as CPU name
	So far IBM z17 was identified as arch15.  Add the real name, as it has
	been announced. [1]

	[1]: IBM z17 announcement letter, AD25-0015,
	     https://www.ibm.com/docs/en/announcements/z17-makes-more-possible

	gas/
		* config/tc-s390.c (s390_parse_cpu): Add z17 as alternate CPU
		name for arch15.
		* doc/c-s390.texi: Likewise.
		* doc/as.texi: Likewise.

	opcodes/
		* s390-mkopc.c (main): Add z17 as alternate CPU name for arch15.

2025-04-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Handle ldaex and stlex in {thumb,arm}_deal_with_atomic_sequence_raw
	The Linaro CI reported a regression [1] in test-case
	gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix
	gdb.base/step-over-syscall.exp with glibc 2.41").

	Investigation shows that it's a progression in the sense that the test-case
	fails at a later point than before.

	The cause for the test-case failure is that an atomic sequence
	ldaex/adds/strex is not skipped over when instruction stepping, leading to a
	hang (in the sense of not being able to instruction-step out of the loop
	containing the atomic sequence).

	The arm target does have support for recognizing atomic sequences, but it
	fails because it doesn't recognize the ldaex insn.

	Fix this by:
	- adding a new function ldaex_p which recognizes ldaex instructions, based
	  on information found in opcodes/arm-dis.c, and
	- using ldaex_p in thumb_deal_with_atomic_sequence_raw.

	I was not able to reproduce the failure in its original setting, but I
	was able to do so using a test.c:
	...
	static void exit (int status) {
	  while (1)
	    ;
	}
	void _start (void) {
	  int a = 0;
	  __atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
	  exit (0);
	}
	...
	compiled like this:
	...
	$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
	...
	giving this atomic sequence of 32-bit Thumb-2 instructions:
	...
	   100ce:       e8d3 1fef       ldaex   r1, [r3]
	   100d2:       f101 0101       add.w   r1, r1, #1
	   100d6:       e843 1200       strex   r2, r1, [r3]
	...

	Without the fix, after 100 stepi's we're still in _start (and likewise with
	10.000 stepi's):
	...
	$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
	  ...
	0x000100dc in _start ()
	1: x/i $pc
	=> 0x100dc <_start+26>:	bne.n	0x100ce <_start+12>
	...
	but with the fix we've managed to progress to exit:
	...
	$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
	  ...
	0x000100c0 in exit ()
	1: x/i $pc
	=> 0x100c0 <exit+8>:	b.n	0x100c0 <exit+8>
	...

	Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?

	Adding "-marm" in the compilation line mentioned above gives the following
	atomic sequence:
	...
	   100e4:       e1931e9f        ldaex   r1, [r3]
	   100e8:       e2811001        add     r1, r1, #1
	   100ec:       e1832f91        strex   r2, r1, [r3]
	...
	and gdb already recognizes it as such because of this statement:
	...
	  if ((insn & 0xff9000f0) != 0xe1900090)
	    return {};
	...

	The trouble with this statement is that it requires knowledge of arm
	instruction encoding to understand which cases it does and doesn't cover.

	Note that the corresponding comment only mentions ldrex:
	...
	  /* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
	...
	but evidently at least some forms of ldaex are also detected.

	So, also use ldaex_p in arm_deal_with_atomic_sequence_raw.  This may or may
	not be redundant, but at least ldaex_p is explicit and precise about what it
	supports.

	Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
	__ATOMIC_ACQUIRE in the example above).

	Tested in arm-linux chroot on aarch64-linux.

	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Co-Authored-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/32796
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796

	[1] https://linaro.atlassian.net/browse/GNU-1541

2025-04-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-08  Tom Tromey  <tom@tromey.com>

	Simplify print_doc_line
	print_doc_line uses a static buffer and manually manages memory.  I
	think neither of these is really needed, so this patch rewrites the
	function to use std::string.  The new implementation tries to avoid
	copying when possible.

	Regression tested on x86-64 Fedora 40.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-04-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes in maint.c
	These includes are reported as unused by clangd.

	Change-Id: I1cde043244f9efe350310955b2a02ac874be12b3

2025-04-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2: pass correct dwarf2_cu to lookup_dwo_id in create_cus_hash_table
	Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader")
	introduced a regression when handling files compiled with "-gsplit-dwarf
	-fdebug-types-section" (at least with clang):

	    $ cat test.cpp
	    #include <vector>

	    int main()
	    {
	      std::vector<int> v;
	      return v.size ();
	    }
	    $ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test
	    $ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs"
	    Reading symbols from ./test...
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed.

	In the main file, we have a skeleton CU with a certain DWO ID:

	    0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ...

	In the .dwo file, the first unit is a type unit with a certain type
	signature:

	    0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ...

	and the split compile unit matching the DWO ID from the skeleton from
	the main file comes later:

	    0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ...

	The problem introduced by the aforementioned commit is that when
	creating a dwo_unit structure representing the type unit, we use the
	signature (DWO id) from the skeleton, instead of the signature from the
	type unit's header.  As a result, all dwo_units get created with the
	same signature (the DWO id) and only the first unit gets inserted in the
	hash table.  When looking up the comp unit by DWO ID later on, we
	wrongly find the type unit, and try to expand a type unit as a comp
	unit, hitting the assert.

	Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
	yields a dwarf2_cu built from parsing the type unit's header.  This
	dwarf2_cu contains the comp_unit_header with the correct signature.  Fix
	the code to use `reader.cu ()` again.

	Another thing that enables this bug is the fact that since DWARF 5, type
	and compile units are all in .debug_info, and therefore read by
	create_cus_hash_table, so they both end up in dwo_file::cus.  Type units
	should end up in dwo_file::tus, otherwise they won't be found by
	lookup_dwo_cutu.  This bug hasn't given me trouble so far, so I'm not
	fixing it right now, but it's on my todo list.

	The problem can be seen with some tests, when using the
	dwarf5-fission-debug-types board:

	    $ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
	    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
	    FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)

	But this patch also adds a DWARF assembler-based test that triggers the
	internal error.

	Note that the new test does not use the build_executable_and_dwo_files
	proc, because I found that it is subtly broken and doesn't work to put
	multiple units in a single .dwo file.  The debug abbrev offset field in
	the second unit's header would be 0, when it should have been something
	else.  The problem is that no linking is ever done to generate the .dwo
	file, so the relocation that would apply for this field is never
	applied.  Instead, I generate two DWARF debug infos separately and link
	the .dwo file using gdb_compile, it seems to work fine.

	Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite/dwarf: fix abbrev section name when putting type unit in DWO file
	Fix what looks like a copy paste error resulting in the wrong abbrev
	section name.  The resulting section name in my test was
	".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo".

	Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite/dwarf: add support to generate DWARF 5 split compile units
	Add support to the DWARF assembler to generate DWARF 5 split compile
	units.  The assembler knows how to generate DWARF < 5 split compile
	units (fission), DWARF 5 compile units, but not DWARF 5 split compile
	units.  What's missing is:

	 - using the right unit type in the header: skeleton for the unit in the
	   main file and split_compile for the unit in the DWO file
	 - have a way for the caller to specify the DWO ID that will end up in
	   the unit header

	Add a dwo_id parameter to the cu proc.  In addition to specifying the
	DWO ID, the presence of this parameter tells the assembler to use the
	skeleton or split_compile unit type.

	This is used in a subsequent patch.

	Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: add DWARF 5 + split DWARF + type units board
	I'm currently fixing bugs and performance issues when GDB encounters
	this particular configuration.  Since split DWARF + type units makes GDB
	take some code paths not taken by any other board files, I think it
	deserves to be its own board file.  One particularity is that the
	produced .dwo files have a .debug_info.dwo section that contains some
	ype units, in addition to the compile unit.

	Add that board to make-check-all.sh.

	Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-08  Tom Tromey  <tromey@adacore.com>

	Update copyright dates to include 2025
	This updates the copyright headers to include 2025.  I did this by
	running gdb/copyright.py and then manually modifying a few files as
	noted by the script.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2025-04-08  Alexandra Hájková  <ahajkova@redhat.com>

	Rename set-solib-absolute-prefix.exp to x86-set-solib-absolute-prefix.exp
	and move it from gdb.base to gdb.arch as it's a target specific test.

	Reviewed-by: Maciej W. Rozycki <macro@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-08  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Warn about right shifts of negative numbers
	The GNU Assembler User Guide says that the right shift operator ">>"
	in an expression is the same as the C operator.

	On LoongArch the assembler directives and instructions do not treat
	negative numbers ">>" the same way. The directives treats negative
	numbers ">>" as logical right shifts while the instructions treats them
	as arithmetic right shifts.

	The right shift of negative numbers in the instructions may be changed
	from an arithmetic right shift to a logical right shift in the future,
	and a warning is issued for this.

2025-04-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-07  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Use debug info language to pick pygments lexer
	Consider the following scenario:
	...
	$ cat hello

	int
	main (void)
	{
	  printf ("hello\n");
	  return 0;
	}
	$ gcc -x c hello -g
	$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
	Reading symbols from a.out...
	(gdb) start
	Temporary breakpoint 1 at 0x4005db: file hello, line 6.
	Starting program: /data/vries/gdb/a.out
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib64/libthread_db.so.1".

	Temporary breakpoint 1, main () at hello:6
	6	  printf ("hello\n");
	...

	This doesn't produce highlighting for line 6, because:
	- pygments is used for highlighting instead of source-highlight, and
	- pygments guesses the language for highlighting only based on the filename,
	  which in this case doesn't give a clue.

	Fix this by:
	- adding a language parameter to the extension_language_ops.colorize interface,
	- passing the language as found in the debug info, and
	- using it in gdb.styling.colorize to pick the pygments lexer.

	The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
	different scenario: it compiles a c++ file with a .c extension, and checks
	that c++ highlighting is done instead of c highlighting.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR cli/30966
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966

2025-04-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Don't try deferred curses initialization twice
	I noticed that if deferred curses initialization fails, for instance when
	using TERM=dumb, and we try the same again, we run into the same error:
	...
	$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
	Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
	Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
	...

	I think it's better to try deferred curses initialization only once.

	Fix this by changing bool tui_finish_init into a tribool, and using
	TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we
	get instead:
	...
	$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
	Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
	Cannot enable the TUI
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-07  Michael Matz  <matz@suse.de>

	[lto] Fix symlookup in archives vs shared
	when a shared library defines 'foo@@FOO' (default version),
	a static archive defines 'foo', the shared lib comes in front
	of the archive and under effect of --as-needed, and the requesting
	object file uses LTO, then the link editor was wrongly including
	the definition from the static archive.  It must use the one
	from the shared lib, like in the non-LTO or the --no-as-needed case.
	See the added testcase that would wrongly print "FAIL" before
	this patch.

	The problem stems from several connected problems:
	(1) only the decorated symbol was entered into first_hash (the hash
	    table designed to handle definition order in the pre-LTO-plugin
	    phase of the symbol table walks)
	(2) in the archive symbol walk only the undecorated name would be
	    looked up in first_hash (and hence not found due to (1))
	(3) in the archive symbol walk first_hash would only be consulted
	    when the linker hash table had a defined symbol.  In pre-LTO
	    phase shared lib symbols aren't entered into the linker symbol
	    table.

	So: add also the undecorated name into first_hash when it stems from
	a default version and consult first_hash in the archive walker also
	for currently undefined symbols.  If it has an entry which doesn't
	point to the archive, then it comes from an earlier library (shared or
	static), and so _this_ archive won't provide the definition.

2025-04-07  Alan Modra  <amodra@gmail.com>

	xcoff dynamic symbol string sanity
	Sanity check symbol string table offsets, and tidy structs.  "long"
	isn't a good choice for _l_zeroes and _l_offset since it can be 64
	bits which blows out the size of the symbol struct unnecessarily.
	Also, all of the sizes in internal_ldsym need only be 32 bits, but I
	made them size_t because I didn't want to audit all expressions using
	them for overflow.

	bfd/
		* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_symtab): Sanity
		check symbol _l_offset.
		(xcoff_link_add_dynamic_symbols),
		(xcoff_link_check_dynamic_ar_symbols): Likewise.
	include/
		* coff/xcoff.h (struct internal_ldhdr): Tidy types.
		(struct internal_ldsym): Use uint32_t for _l_zeroes and _l_offset.

2025-04-07  Alan Modra  <amodra@gmail.com>

	xcoff buffer overflow
	Much of the xcoff code is not well protected against fuzzed object file
	attacks.  This sanity checks some values in ".loader".

		* xcofflink.c (xcoff_get_ldhdr): New function.
		(_bfd_xcoff_get_dynamic_symtab_upper_bound),
		(_bfd_xcoff_canonicalize_dynamic_symtab),
		(_bfd_xcoff_get_dynamic_reloc_upper_bound),
		(_bfd_xcoff_canonicalize_dynamic_reloc),
		(xcoff_link_add_dynamic_symbols),
		(xcoff_link_check_dynamic_ar_symbols): Use xcoff_get_ldhdr.

2025-04-07  Alan Modra  <amodra@gmail.com>

	buffer overflow in nds32_elf_do_9_pcrel_reloc
		* elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Properly bounds
		check relocation field.
		(nds32_elf_hi20_reloc, nds32_elf_generic_reloc): Likewise.
		(nds32_elf_final_link_relocate): Likewise.

2025-04-07  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Introduce user-friendly namespace identifier for "info shared"
	GDB has had basic support for linkage namespaces for some time already,
	but only in the sense of managing multiple copies of the same shared
	object being loaded, and a very fragile way to find the correct copy of
	a symbol (see PR shlibs/32054).

	This commit is the first step in improving the user experience around
	multiple namespace support. It introduces a user-friendly identifier for
	namespaces, in the format [[<number>]], that will keep consistent between
	dlmopen and dlclose calls. The plan is for this identifier to be usable
	in expressions like `print [[1]]::var` to find a specific instance of a
	symbol, and so the identifier must not be a valid C++ or Ada namespace
	identifier, otherwise disambiguation becomes a problem. Support for
	those expressions has not been implemented yet, it is only mentioned to
	explain why the identifier looks like this.

	This syntax was chosen based on the C attributes, since nothing in GDB
	uses a similar syntax that could confuse users. Other syntax options
	that were explored were "#<number>" and "@<number>". The former was
	abandoned because when printing a frame, the frame number is also
	printed with #<number>, so in a lot of the context in which that the
	identifier would show up, it appears in a confusing way. The latter
	clashes with the array printing syntax, and I believe that the having
	"@N::foo" working completely differently to "foo@2" would also lead to a
	bad user experience.

	The namespace identifiers are stored via a vector inside svr4_info
	object. The vector stores the address of the r_debug objects used by
	glibc to identify each namespace, and the user-friendly ID is the index
	of the r_debug in the vector. This commit also introduces a set storing
	the indices of active namespaces. The glibc I used to develop this patch
	(glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a
	deactivated namespace, and requesting a new namespace when a namespace
	was previously closed will reuse that namespace. Because of how this is
	implemented, this patch lets GDB easily track the exact namespace IDs
	that the inferior will see.

	Finally, two new solib_ops function pointers were added, find_solib_ns
	and num_active_namespaces, to allow code outside of solib-svr4 to find
	and use the namespace identifiers and the number of namespaces,
	respectively. As a sanity check, the command `info sharedlibrary` has
	been changed to display the namespace identifier when the inferior has
	more than one active namespace. With this final change, a couple of tests
	had to be tweaked to handle the possible new column, and a new test has
	been created to make sure that the column appears and disappears as
	needed, and that GDB can track the value of the LMID for namespaces.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-04-07  Jeremy Drake  <sourceware-bugzilla@jdrake.com>

	bfd: add load config size workaround for i386 XP and earlier
	Per the Microsoft PE documentation, XP and earlier on i686 require the
	Size field to be 64, rather than the actual size as required on other
	architectures.  I have confirmed Windows 11 accepts either 64 or the
	actual size for i386 images, but only the actual size for x86_64 images.

	bfd: fill in PE load config directory entry
	This is filled in with the rva of _load_config_used if defined (much
	like _tls_used), and the size is the first 32-bit value at that symbol.

	bfd: adjust a few error messages
	Rationalize the error messages in _bfd_XXi_final_link_postscript().
	They now all correctly refer to DataDirectory instead of DataDictionary,
	and use unified format strings, so fewer translations are needed.

	bfd: properly use bfd_get_symbol_leading_char() in peXXigen
	This function returns the leading char to use, so we cannot just assume
	it will always be '_' or '\0'.

2025-04-07  Jan Beulich  <jbeulich@suse.com>

	bfd/COFF: drop link_add_one_symbol() hook
	The need for this has disappeared with dc12032bca08 ("Remove m68k-aout
	and m68k-coff support"); avoid the unnecessary indirection.

	Sadly, with ld/pe-dll.c using the wrapper, the removal requires moving
	the declaration out of libcoff.h, to properly export the underlying BFD
	function.

2025-04-07  Jan Beulich  <jbeulich@suse.com>

	nm: fall back to heuristic when ELF symbol has zero size
	Size being set for a symbol isn't a strict requirement in ELF. For ones
	not having their size set, fall back to the same logic as used for non-
	ELF, non-COFF symbols.

	While there switch to using elf_symbol_from() instead of kind of open-
	coding it.

2025-04-07  Jan Beulich  <jbeulich@suse.com>

	nm: also retrieve size for COFF function symbols
	Like ELF for all symbols, COFF can record size for at least function
	ones. Use that - if available - in preference to the distance-to-next-
	symbol heuristic.

	To be able to use the new test there, make TI C54x follow TI C4x in
	providing .sdef to cover for .def already having different meaning.

2025-04-07  Claudiu Zissulescu  <claudiu.zissulescu-ianculescu@oracle.com>

	gprofng: Remove duplicate symbols
	Remove all duplicate symbols which can be in SymLst.  The duplication
	is due to processing of both static and dynamic symbols.  The
	Stabs::removeDupSyms function is called before computing symbol
	aliases.

	Introduce a new vector function (i.e., truncate()), that truncates a
	vector lenght to the given new count.  This functionis used by
	removeDupSyms function.

2025-04-07  Claudiu Zissulescu  <claudiu.zissulescu-ianculescu@oracle.com>

	gprofng: Refactor readSymSec for using BFD's asymbol struct
	This patch refactors a number of gprofng internal functions for using
	more BFD data types and functions.
	Stabs::readSymSec is a function which reads the symbols of an ELF file
	mapping them into an internal structure. To use BFD asymbols, the
	Elf::elf_getsym is changed from custom reading of the symbols from
	.symtab and .dynsym section to BFD enable functions. A new function is
	introduced which returns the number of either static or dynamic symbols,
	named Elf::elf_getSymCount. Both Elf functions are used by
	Stabs::readSymSec refactoring.

	Also, this patch removes reading symbols, SUNW_ldnsym section as it is
	only used by now defunct Studio compiler. However, it adds the reading
	of both static and dynamic symbols, previously, only either one was
	processed.

2025-04-07  Claudiu Zissulescu  <claudiu.zissulescu-ianculescu@oracle.com>

	gprofng: Remove check_Relocs() function
	check_Relocs() function is not anylonger required as it can only
	handle Studio compiler relocs, now defunct. Remove this function.

2025-04-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-06  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdbserver: regcache: Update comment in supply_regblock
	Since commit 84da4a1ea0ae ("gdbserver: refactor the definition and uses of
	supply_regblock") there is no case where supply_regblock is passed a
	nullptr for the BUF argument, and there is even a gdb_assert to make
	sure of it.

	Therefore remove that part of the documentation comment.

2025-04-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-04  Jan Beulich  <jbeulich@suse.com>

	objcopy: also check --file-alignment option argument
	... to be a power of two, just like --section-alignment does.

	binutils: run objcopy set-section-alignment also for COFF
	There's no reason to limit this to just ELF. TI C30 and Z8k don't encode
	section alignment in the section entries though (which can't be quite
	right, or there would need to be another means by which to express
	alignment needs), so --set-section-alignment simply has no effect there.

2025-04-04  Jan Beulich  <jbeulich@suse.com>

	objcopy: constrain --section-alignment to PE binaries again
	PR binutils/32732

	The --set-section-alignment option is what ought to be used on object
	files; --section-alignment should be affecting PE binaries only, and
	only the value stored in the header. Sections don't individually have
	alignment recorded there; see 6f8f6017a0c4 ("PR27567, Linking PE files
	adds alignment section flags to executables").

	Undo the core part of 121a3f4b4f4a ("Update objcopy's
	--section-alignment option so that it sets the alignment flag on..."),
	which includes removing the testcase again, while leaving all secondary
	changes in place. (Note that the testcase did fail anyway for
	i?86-interix, with objdump saying "option -P/--private not supported by
	this file".)

2025-04-04  Jan Beulich  <jbeulich@suse.com>

	ar/objcopy: harmonize .exe suffix stripping
	With it only being the tail of the name which wants checking, using
	lbasename() isn't helpful. Mirror what objcopy.c:main() does to ar.c,
	merely chaning the plain int of the local variable to size_t.

	binutils: properly split ar and ranlib
	By not linking the exact same object file twice, in particular ranlib can
	benefit quite a bit from the compiler eliminating dead code.

	binutils: properly split objcopy and strip
	By not linking the exact same object file twice, in particular strip can
	benefit quite a bit from the compiler eliminating dead code.

2025-04-04  Tom Tromey  <tom@tromey.com>

	Make gdb/guile codespell-clean
	This cleans up the last codespell reports in the Guile directory and
	adds gdb/guile to pre-commit.

	It also tells codespell to ignore URLs.  I think this is warranted
	because many URLs don't really contain words per se; and furthermore
	if any URL-checking is needed at all, it would be for liveness and not
	spelling.

	Also I was wondering why the codespell config is in contrib and not
	gdb/setup.cfg.

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-04  Tom Tromey  <tom@tromey.com>

	Make gdb/python codespell-clean
	This cleans up the last codespell report in the Python directory and
	adds gdb/python to pre-commit.

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename cache -> abbrev_cache
	"cache" is just a bit too generic to be clear.

	Change-Id: I8bf01c5fe84e076af1afd2453b1a115777630271

2025-04-03  Tom Tromey  <tromey@adacore.com>

	Many minor typo fixes
	I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos.
	Most of what remains is trickier, i.e., spots where a somewhat natural
	name of something in the code is flagged as a typo.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-04-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix xfail in gdb.ada/array_of_variant.exp
	In commit af2b87e649b ("[gdb/testsuite] Add xfail for PR gcc/101633"), I added
	an xfail that was controlled by variable old_gcc, triggering the xfail for
	gcc 7 and before, but not for gcc 8 onwards:
	...
	set old_gcc [expr [test_compiler_info {gcc-[0-7]-*}]]
	...

	In commit 1411185a57e ("Introduce and use gnat_version_compare"), this changed
	to:
	...
	set old_gcc [gnat_version_compare <= 7]
	...
	which still triggered the xfail for gcc 7, because of a bug in
	gnat_version_compare.

	After that bug got fixed, the xfail was no longer triggered because the gnatmake
	version is 7.5.0, and [version_compare {7 5 0} <= {7}] == 0.

	We could have the semantics for version_compare where we clip the input
	arguments to the length of the shortest, and so we'd have
	[version_compare {7 5 0} <= {7}] == [version_compare {7} <= {7}] == 1.

	But let's stick with the current version-sort semantics, and fix this by
	using [gnat_version_compare < 8] instead.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.testsuite/version-compare.exp
	Add a test-case gdb.testsuite/version-compare.exp that excercises proc
	version_compare, and a note to proc version_compare that it considers
	v1 < v1.0 instead of v1 == v1.0.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-03  Martin Simmons  <qqxnjvamvxwx@dyxyl.com>

	Fix parsing .debug_aranges section for signed addresses.
	Some architectures, such as MIPS, have signed addresses and this changes
	read_addrmap_from_aranges to record them as signed when required.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32658
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-03  Tom Tromey  <tom@tromey.com>

	Fix pp.rs test for gccrs
	gccrs still can't process all of gdb's Rust tests, but I did manage to
	manually test it on a few.  In addition to filing some bug reports, I
	came up with this patch.

	There are two fixes here.  First, gccrs emits tuple field names as
	integers ("0", "1", etc) whereas rustc uses a leading double
	underscore ("__0", "__1", etc).  This patch changes gdb to accept the
	gccrs output, which IMO makes sense (and for which there's already a
	rustc feature request).

	Second, it changes rust_struct_anon::evaluate to use check_typedef.
	This is a gdb necessity in general, so could be described as an
	oversight; but in this case it works around the gccrs oddity that most
	named types are emitted as DW_TAG_typedef.  I've filed a gccrs bug
	report for that.

2025-04-03  Tom de Vries  <tdevries@suse.de>

	[pre-commit] Add codespell-clean gdb subdirs
	As an alternative to adding the gdb dir to codespell while it's still not
	codespell-clean [1], add gdb subdirs which are codespell-clean.

	Found using:
	...
	$ for d in $(find gdb -maxdepth 1 -type d | egrep -v "testsuite|gdb$"); do \
	      echo -n "$d: "; \
	      codespell --config gdb/contrib/setup.cfg $d 2>/dev/null \
	          | wc -l; \
	  done 2>&1 \
	      | grep ": 0"
	gdb/tui: 0
	gdb/target: 0
	gdb/data-directory: 0
	gdb/po: 0
	gdb/system-gdbinit: 0
	gdb/mi: 0
	gdb/syscalls: 0
	gdb/arch: 0
	gdb/regformats: 0
	gdb/compile: 0
	...

	Verified using:
	...
	$ pre-commit run codespell --all-files
	codespell................................................................Passed
	...

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216781.html

2025-04-03  LIU Hao  <lh_mouse@126.com>

	ld/testsuite/ld-pe: Escape dots in regular expressions

	ld/ChangeLog:
		* testsuite/ld-pe/secidx.d: Escape dots in regular expressions.

2025-04-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-02  Tom Tromey  <tom@tromey.com>

	Clean up cooked_index::done_reading
	The cooked index worker maintains the state for the various state
	transition in the scanner.  It is held by the cooked_index while
	scanning is in progress, then deleted once this has completed.

	I noticed that none of the arguments to cooked_index::done_reading
	were really needed -- the cooked_index already has access to the
	worker should it need it.  Removing these parameters makes the code a
	bit simpler and also cleans up some confusing code around the use of
	the deferred warnings object.

	Regression tested on x86-64 Fedora 40.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-02  Tom Tromey  <tromey@adacore.com>

	Update copyright.py
	copyright.py needed an addition for unordered_dense.h.

	Then, when running it, I saw it complain about some .pyc files I had
	in the source tree.  I don't know why I had these, but the script
	should ignore them.

	For this, Kévin suggested using "git ls-files" to determine which
	files to update -- that should automatically exclude any random files
	in the tree.  This version of the patch makes this change.

	There were complaints about some sim/ppc files that were renamed.
	Ignoring the entire directory seems simpler given the comment.

	I also made a few more minor changes:

	* Removed the 'CVS' exclusion, as this hasn't been relevant in years.

	* Moved the 'copying.c' exclusion to EXCLUDE_LIST

	* Changed the script to run from the top level (we could have it
	  automatically find this if we really wanted).

	After this lands, I plan to run it and check in the result.  The patch
	may be too large (and certainly too uninteresting) to post, so if/when
	this happens I will send a brief note to the list about it.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2: remove unused includes
	Remove some includes reported as unused by clangd.

	Change-Id: I841938c3c6254e4f0d154a1e172c4968ff326333

2025-04-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes in dbxread.c
	Remove includes reported as unused by clangd.

	Change-Id: I12e5cf254d211f42f3cfdab90d1f42a5986e53a3

2025-04-02  Luis Machado  <luis.machado@arm.com>

	Fix gdbserver crashes on SVE/SME-enabled systems
	Commit 51e6b8cfd649013ae16a3d00f1451b2531ba6bc9 fixed a
	regression for SVE/SME registers on gdb's side by using a <= comparison for
	regcache's raw_compare assertion check. We seem to have failed to do the same
	for gdbserver's raw_compare counterpart.

	With the code as it is, I'm seeing a lot of crashes for gdbserver on a machine
	with SVE enabled. For instance, with the following invocation:

	make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.base/break.exp

	Running /work/builds/binutils-gdb/gdb/testsuite/../../../../repos/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
	FAIL: gdb.base/break.exp: test_break: run until function breakpoint
	FAIL: gdb.base/break.exp: test_break: run until breakpoint set at a line number (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(6) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(5) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(4) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(3) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(2) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:function(1) breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until quoted breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: run until file:linenum breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: breakpoint offset +1
	FAIL: gdb.base/break.exp: test_break: step onto breakpoint (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break: setting breakpoint at }
	FAIL: gdb.base/break.exp: test_break: continue to breakpoint at } (the program is no longer running)
	FAIL: gdb.base/break.exp: test_no_break_on_catchpoint: runto: run to main
	FAIL: gdb.base/break.exp: test_break_nonexistent_line: runto: run to main
	FAIL: gdb.base/break.exp: test_break_default: runto: run to main
	FAIL: gdb.base/break.exp: test_break_silent_and_more: runto: run to main
	FAIL: gdb.base/break.exp: test_break_line_convenience_var: runto: run to main
	FAIL: gdb.base/break.exp: test_break_user_call: runto: run to main
	FAIL: gdb.base/break.exp: test_finish_arguments: runto: run to main
	FAIL: gdb.base/break.exp: test_next_with_recursion: kill program
	FAIL: gdb.base/break.exp: test_next_with_recursion: run to factorial(6)
	FAIL: gdb.base/break.exp: test_next_with_recursion: continue to factorial(5) (the program is no longer running)
	FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5)
	FAIL: gdb.base/break.exp: test_next_with_recursion: next to recursive call (the program is no longer running)
	FAIL: gdb.base/break.exp: test_next_with_recursion: next over recursive call (the program is no longer running)
	FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5.1)
	FAIL: gdb.base/break.exp: test_next_with_recursion: continue until exit at recursive next test (the program is no longer running)
	FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until function breakpoint, optimized file
	FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until breakpoint set at small function, optimized file (the program is no longer running)
	FAIL: gdb.base/break.exp: test_rbreak_shlib: rbreak junk

	Adjusting the regcache raw_compare assertion check to use <= fixes
	the problem on aarch64-linux on a SVE-capable system.

	This patch also adds a simple selftest to gdbserver that validates this
	particular case by simulating a raw_compare operation.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32775

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-02  Nick Clifton  <nickc@redhat.com>

	Add optional filename argument to the linker's --stats option, allowing extra resource use information to be reported.

2025-04-02  Alexandra Hajkova  <ahajkova@redhat.com>

	Add gdb.base/set-solib-absolute-prefix.exp
	Compile a 32-bit x86 executable and then stop within a system call.
	Change the sysroot to a non-existent directory, GDB should try (and
	fail) to reload the currently loaded shared libraries.  However, GDB
	should retain the symbols for the vDSO library as that is not loaded
	from the file system.

	Check the backtrace to ensure that the __kernel_vsyscall symbol is
	still in the backtrace, this indicates GDB still has the vDSO
	symbols available.

	This test was present in Fedora for a long time and was
	originally written by Jan Kratochvil for this fix
	829a902da291e72ad17e8c44fa8d9ead3db41b1f.

	Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-04-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-04-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move addrmap::relocate method to addrmap_fixed
	The relocate method of addrmap is unnecessarily virtual.  Only
	addrmap_fixed provides a meaningful implementation.  Move the method to
	addrmap_fixed only and make it non-virtual.

	Change-Id: If61d5e70abc12c17d1e600adf0dd0707e77a6ba2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-01  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Support gdb in codespell section of setup.cfg
	Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg,
	specifically adding files in the skip line.

	This allows us to run codespell from the command line on the gdb dir:
	...
	$ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l
	1665
	...
	without running into warnings in generated files.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Update cooked_index comment
	This updates the cooked_index comment with some notes about object
	lifetimes, in an attempt to make navigating this code a bit simpler.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Add cooked_index_worker::done_reading
	The two readers currently using cooked_index_worker shared some code.
	This patch factors this out into a new "done_reading" method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Remove cooked_index_worker::result_type
	cooked_index_worker::result_type is an ad hoc tuple type used for
	transferring data between phases of the indexer.  It's a bit unwieldy
	and another patch I'm working on would be somewhat nicer without it.

	This patch removes the type.  Now cooked_index_ephemeral objects are
	transferred instead, which is handy because they already hold the
	needed state.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Add addrmap_mutable::clear
	It was convenient to add a 'clear' method to addrmap_mutable.  The
	cleanest way to do this was to change the class to lazily initialize
	its 'tree' member.  This also makes addrmap_mutable::operator= a bit
	less weird.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Update comments from moved methods
	This updates the "See xyz.h" comments for all the methods that were
	moved earlier in this series.  Perhaps I should have removed them
	instead.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Move cooked_index_worker to cooked-index-worker.[ch]
	This moves the cooked_index_worker class to cooked-index-worker.[ch].

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Change includes in cooked-index-worker.h
	This changes cooked-index-worker.h to include the new header files.
	This breaks the circular dependency that would otherwise be introduced
	in the next patch.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Move cooked_index_shard to new files
	This moves cooked_index_shard to a couple of new files,
	dwarf2/cooked-index-shard.[ch].  The rationale is the same as the
	previous patch: cooked-index.h had to be split to enable other
	cleanups.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Move cooked_index_entry to new files
	This moves cooked_index_entry and some related helper code to a couple
	of new files, dwarf2/cooked-index-entry.[ch].

	The main rationale for this is that in order to finish this series and
	remove "cooked_index_worker::result_type", I had to split
	cooked-index.h into multiple parts to avoid circular includes.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Make language_requires_canonicalization 'static'
	language_requires_canonicalization is only called from cooked-index.c,
	so mark it as static.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Rename cooked_index_storage
	This renames cooked_index_storage to cooked_index_worker_result,
	making its function more clear.  It also updates the class comment to
	as well.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Tom Tromey  <tom@tromey.com>

	Rename cooked-index-storage.[ch]
	A discussion with Simon made me realize that cooked_index_storage
	isn't a very clear name, especially now that it's escaped from read.c.
	While it does provide some storage (I guess any object does in a
	sense), it is really a helper for cooked_index_worker -- a temporary
	object that is destroyed after reading has completed.

	This patch renames this file.  Later patches will rename the class and
	move cooked_index_worker here, something I think is reasonable given
	that cooked_index_storage is really something of a helper class for
	cooked_index_worker.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-04-01  Alan Modra  <amodra@gmail.com>

	PR32829, SEGV on objdump function debug_type_samep
	u.kenum is always non-NULL, see debug_make_enum_type.

		PR 32829
		* debug.c (debug_type_samep): Correct incomplete enum test.
		(debug_write_type): Remove dead code.

2025-04-01  Alan Modra  <amodra@gmail.com>

	ubsan: nds32 undefined shift
	Avoid implementation defined behaviour right shift of negative values,
	and undefined behaviour left shift of negative values.  While this
	change might give different results in the top bit of a bfd_vma
	(rightshift is 1), that doesn't matter as only the bottom 8 bits of
	the relocation are used.

		* elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Calculate relocation
		using a bfd_vma type.

2025-04-01  Alan Modra  <amodra@gmail.com>

	Formatting fixes for elf-attrs.c

2025-04-01  Tom Tromey  <tromey@adacore.com>

	Check gnatmake version in gnat_version_compare
	Tom de Vries pointed out that my earlier change to
	gnat_version_compare made it actually test gcc's version -- not
	gnat's.

	This patch changes gnat_version_compare to examine gnatmake's version,
	while preserving the nicer API.

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-04-01  Clément Chigot  <chigot@adacore.com>

	binutils/testsuite: don't tail the same input and output file
	The output file could be created before the input is gathered by tail,
	erasing the later before it's being proceeded.

	This happened on rare cases when performing remote tests on
	Ubuntu 24.04.

2025-04-01  Clément Chigot  <chigot@adacore.com>

	binutils/testsuite: move objdump test output into tmpdir
	"objdump.out" is a testsuite trace and thus should be created within the
	tmpdir.

2025-04-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-31  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	testsuite: fix is_aarch32_target
	Commit

	   c221b2f77080 Testsuite: Add gdb_can_simple_compile

	changed the source file name extension of the test program from .s to .c
	resulting in compile fails.  This, in turn, causes is_aarch32_target
	checks to fail.

	Change the test source from an assembly program to a C program using
	inline assembly.

	is_amd64_regs_target had a similar problem, which was fixed by commit

	    224d30d39365 testsuite: fix is_amd64_regs_target

	This fix — and commit message — are mostly copied from it.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-31  Michael Eager  <eager@eagercon.com>

	gdbserver: Add support for MicroBlaze host microblaze*-*-linux*

2025-03-31  Tom de Vries  <tdevries@suse.de>

	[gdb/record] Make enum gdb_syscall value names consistent
	In enum gdb_syscall, there are 3 entries that do not have the gdb_sys_ prefix
	...
	$ grep gdb_old_ gdb/linux-record.h
	  gdb_old_select = 82,
	  gdb_old_readdir = 89,
	  gdb_old_mmap = 90,
	...
	like all the other entries:
	...
	  gdb_sys_restart_syscall = 0,
	  gdb_sys_exit = 1,
	  gdb_sys_fork = 2,
	  gdb_sys_read = 3,
	...

	The three correspond to these entries in
	arch/x86/entry/syscalls/syscall_32.tbl:
	...
	<number>  <abi>   <name>     <entry point>      [<compat entry point> [noreturn]]
	82        i386    select     sys_old_select     compat_sys_old_select
	89        i386    readdir    sys_old_readdir    compat_sys_old_readdir
	90        i386    mmap       sys_old_mmap       compat_sys_ia32_mmap
	...

	As we can see, the enum uses the entry point name, but without the sys_
	prefix.

	There doesn't seem to be a good reason for this.

	There's another enum value:
	...
	  gdb_sys_old_getrlimit = 76,
	...
	corresponding to:
	...
	76        i386    getrlimit  sys_old_getrlimit  compat_sys_old_getrlimit
	...
	where we do use the sys_ prefix.

	Fix this by consistenly using the gdb_sys_ prefix in enum gdb_syscall.

	No functional changes.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-31  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Remove spellcheck.sh
	Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and
	associated file gdb/contrib/common-misspellings.txt.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-31  Tom de Vries  <tdevries@suse.de>

	[gdb] Check strpbrk against nullptr
	In noticed two occurrences of "if (strpbrk (...))".

	Fix this style issue by checking against nullptr.

2025-03-31  Lancelot SIX  <lancelot.six@amd.com>

	gdbsupport/common-inferior.c: Fix mingw build
	A recent change (512ca2fca4b "gdb: split up
	construct_inferior_arguments") introduced a build failure for mingw:

	      CXX      common-inferior.o
	    .../gdb/gdbsupport/common-inferior.cc: In function ‘std::string escape_characters(const char*, const char*)’:
	    .../gdb/gdbsupport/common-inferior.cc:62:20: error: ‘argv’ was not declared in this scope; did you mean ‘arg’?
	       62 |       if (strpbrk (argv[i], special))
	          |                    ^~~~
	          |                    arg
	    .../gdb/gdbsupport/common-inferior.cc:62:25: error: ‘i’ was not declared in this scope
	       62 |       if (strpbrk (argv[i], special))
	          |                         ^

	This patch fixes that.

	Change-Id: I07ade607bc4516627b433085b07d9d198d8e4b4a
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-03-31  Martin Storsjö  <martin@martin.st>

	ld/PE: Add another mingw UCRT library name to the autoexport exclusion list
	Since 2020, mingw-w64 provides a C runtime import library variant
	named "libucrtapp" too, exclude this one from autoexports like
	the others.

2025-03-31  Tom de Vries  <tdevries@suse.de>

	[pre-commit] Add codespell hook
	Add a pre-commit codespell hook for directories gdbsupport and gdbserver,
	which are codespell-clean:
	...
	$ pre-commit run codespell --all-files
	codespell................................................................Passed
	...

	A non-trivial question is where the codespell configuration goes.

	Currently we have codespell sections in gdbsupport/setup.cfg and
	gdbserver/setup.cfg, but codespell doesn't automatically use those because the
	pre-commit hook runs codespell at the root of the repository.

	A solution would be to replace those 2 setup.cfg files with a setup.cfg in the
	root of the repository.  Not ideal because generally we try to avoid adding
	files related to subdirectories at the root.

	Another solution would be to add two codespell hooks, one using
	--config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and
	add a third one once we start supporting gdb.  Not ideal because it creates
	duplication, but certainly possible.

	I went with the following solution: a setup.cfg file in gdb/contrib (alongside
	codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport.

	So, what can this new setup do for us?  Let's demonstrate by simulating a typo:
	...
	$ echo "/* aways */" >> gdbsupport/agent.cc
	...

	We can check unstaged changes before committing:
	...
	$ pre-commit run codespell --all-files
	codespell................................................................Failed
	- hook id: codespell
	- exit code: 65

	gdbsupport/agent.cc:282: aways ==> always, away
	...

	Likewise, staged changes (no need for the --all-files):
	...
	$ git add gdbsupport/agent.cc
	$ pre-commit run codespell
	codespell................................................................Failed
	- hook id: codespell
	- exit code: 65

	gdbsupport/agent.cc:282: aways ==> always, away
	...

	Or we can try to commit, and run into the codespell failure:
	...
	$ git commit -a
	black................................................(no files to check)Skipped
	flake8...............................................(no files to check)Skipped
	isort................................................(no files to check)Skipped
	codespell................................................................Failed
	- hook id: codespell
	- exit code: 65

	gdbsupport/agent.cc:282: aways ==> always, away

	check-include-guards.................................(no files to check)Skipped
	...
	which makes the commit fail.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-30  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix mmap syscall mapping
	There are a few spots where an mmap system call is mapped onto enum
	gdb_syscall value gdb_sys_mmap2.

	Strictly speaking, this is incorrect.

	Fix this by mapping to enum gdb_syscall value gdb_old_mmap instead.

	No functional changes: both gdb_old_mmap and gdb_sys_mmap2 are handled the
	same in record_linux_system_call.

	Tested by rebuilding on x86_64-linux.

2025-03-30  Tom de Vries  <tdevries@suse.de>

	[gdb] Skip selftest with warning
	With the selftest register_name, we run into a few warning:
	...
	$ gdb -q -batch -ex "maint selftest register_name" 2>&1 \
	    | grep -B1 warning:
	Running selftest register_name::m68hc11.
	warning: No frame soft register found in the symbol table.
	--
	Running selftest register_name::m68hc12.
	warning: No frame soft register found in the symbol table.
	--
	Running selftest register_name::m68hc12:HCS12.
	warning: No frame soft register found in the symbol table.
	...

	We already filter out these architectures in other selftests because of the
	same warning.

	Do the same in this selftest.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-03-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-29  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove disable_breakpoints_in_shlibs function
	I think there is a problem with the disable_breakpoints_in_shlibs
	function: it can disable breakpoint locations without calling
	notify_breakpoint_modified.  This means that the Python API's
	breakpoint_modified event will not trigger, nor will the MI send a
	breakpoint modified event.

	I started looking at disable_breakpoints_in_shlibs because of an
	earlier commit:

	  commit 8c48ec7a6160aed0d1126c623443935e4435cd41
	  Date:   Thu Aug 29 12:34:15 2024 +0100

	      gdb: handle dprintf breakpoints when unloading a shared library

	Currently disable_breakpoints_in_shlibs is only called from one
	location, clear_solib in solib.c.  clear_solib also calls
	notify_solib_unloaded for every solib in the program_space of
	interest, and notify_solib_unloaded will call
	disable_breakpoints_in_unloaded_shlib via the solib_unloaded
	observer.  These two function, disable_breakpoints_in_shlibs and
	disable_breakpoints_in_unloaded_shlib are very similar in what they
	do.

	I think that we can remove the disable_breakpoints_in_shlibs call, and
	instead, tweak how we call disable_breakpoints_in_unloaded_shlib in
	order to get the same end result, except that, after this change, we
	will call notify_breakpoint_modified, which means the Python API event
	will trigger, and the MI events will be emitted.

	All that disable_breakpoints_in_shlibs does is disable some
	breakpoints.

	Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the
	same set of breakpoints, call notify_breakpoint_modified, and
	then (for some breakpoint types) print a message telling the user that
	the breakpoint has been disabled.  However, this function will ignore
	any breakpoints that are already disabled.

	As disable_breakpoints_in_shlibs disables the same set of breakpoints,
	the result of the current code is that disable_breakpoints_in_shlibs
	serves only to prevent the notify_breakpoint_modified call, which I
	think is wrong, and to prevent the user message being printed, which I
	think is reasonable.

	If we remove the disable_breakpoints_in_shlibs call without making any
	additional changes, then we start to see some message printed in cases
	like this:

	  (gdb) start
	  The program being debugged has been started already.
	  Start it from the beginning? (y or n) y
	  warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so"
	  Temporary breakpoint 3 at 0x40113e: file test.c, line 9.
	  Starting program: /tmp/shared-lib-test/test.x

	Notice the 'warning:' line, which is new.  I think this is confusing
	because, in most cases the breakpoint will be enabled again by the
	time the inferior reaches `main` and stops.

	In the future I'm interested in exploring if GDB could be smarter
	about when to print these 'Temporarily disabling breakpoints ...'
	messages so that if the 'start' command does mean a breakpoint is left
	disabled, then the user would be informed.  However, I don't propose
	doing that work immediately, and certainly not in this commit.  For
	now, my intention is to leave things as they are right now, GDB
	doesn't warn about disabling breakpoints during an inferior re-start.

	To achieve this I think we need to pass a new argument to
	disable_breakpoints_in_unloaded_shlib which controls whether we should
	print a message about the breakpoint being disabled or not.  With this
	added we can now silence the warning when the inferior is
	restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called
	from clear_solib), but keep the warning for cases like stepping over a
	dlclose() call in the inferior.

	After this commit, GDB now emits breakpoint modified events (in Python
	and/or MI) when a breakpoint is disabled as a result of all shared
	libraries being unloaded.  This will be visible in two places that I
	can thing of, the 'nosharedlibrary' command, and when an inferior is
	restarted.

2025-03-29  H.J. Lu  <hjl.tools@gmail.com>

	x86: Add {noimm8s} pseudo prefix
	Instruction templates with only sign-extended 8-bit immediate operand
	also have a second template with full-operand-size immediate operand
	under a different opcode.  Add {noimm8s} pseudo prefix to exclude
	templates with only sign-extended 8-bit immediate operand.

	gas/

		PR gas/32811
		* config/tc-i386.c (pseudo_prefixes): Add no_imm8s.
		(operand_size_match): Return false for templates with only sign-
		extended 8-bit immediate operand if {noimm8s} is used.
		(parse_insn): Handle Prefix_NoImm8s.
		* doc/c-i386.texi: Document {noimm8s}.
		* testsuite/gas/i386/pseudos.s: Add tests for {noimm8s}.
		* testsuite/gas/i386/x86-64-pseudos.s: Likewise.
		* testsuite/gas/i386/pseudos.d: Updated.
		* testsuite/gas/i386/x86-64-pseudos.d: Likewise.

	opcodes/

		PR gas/32811
		* opcodes/i386-opc.h (Prefix_NoImm8s): New.
		* i386-opc.tbl: Add {noimm8s} pseudo prefix.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Likewise.

2025-03-29  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Always compile tests with -g
	Always compile gprof testsuite with -g for line number info checked by
	tst-gmon-gprof-l.sh.

		PR gprof/32779
		* testsuite/Makefile.am (GPROF_FLAGS): Add -g.
		(COMPILE): Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS)".
		(LINK) Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS) $(AM_LDFLAGS)
		$(LDFLAGS) -o $@".
		* testsuite/Makefile.in: Regenerated.

2025-03-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: reduce breakpoint-modified events for dprintf b/p
	Consider this backtrace within GDB:

	  #0  notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083
	  #1  0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523
	  #2  0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641
	  #3  0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476
	  #4  0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298

	Whenever breakpoint_re_set is called we re-build the commands that the
	dprintf b/p will execute and store these into the breakpoint.  The
	commands are re-built in update_dprintf_command_list and stored into
	the breakpoint object in breakpoint_set_commands.

	Now sometimes these commands can change, dprintf_breakpoint::re_set
	explains one case where this can occur, and I'm sure there must be
	others.  But in most cases the commands we recalculate will not
	change.  This means that the breakpoint modified event which is
	emitted from breakpoint_set_commands is redundant.

	This commit aims to eliminate the redundant breakpoint modified events
	for dprintf breakpoints.  This is done by adding a commands_equal call
	to the start of breakpoint_set_commands.

	The commands_equal function is a new function which compares two
	command_line objects and returns true if they are identical.  Using
	this function we can check if the new commands passed to
	breakpoint_set_commands are identical to the breakpoint's existing
	commands.  If the new commands are equal then we don't need to change
	anything on the new breakpoint, and the breakpoint modified event can
	be skipped.

	The test for this commit stops at a dlopen() call in the inferior,
	sets up a dprintf breakpoint, then uses 'next' to step over the
	dlopen() call.  When the library loads GDB call breakpoint_re_set,
	which calls dprintf_breakpoint::re_set.  But in this case we don't
	expect the calculated command string to change, so we don't expect to
	see the breakpoint modified event.

2025-03-28  Keith Seitz  <keiths@redhat.com>

	Fix gstack issues
	With commit fb2ded33c1e519659743047ed7817166545b6d91, I added
	Fedora's gstack script to gdb.  Some issues have arisen since
	then, and this patch addresses those issues:

	. As Sam James recently noted[1], PKGVERSION and VERSION
	  need to be quoted.
	. A Fedora user reported the misuse of --readnever, which
	  causes gstack to omit filename and line number information in the
	  backtrace[Red Hat BZ 2354997].

	[1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/
	Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997

2025-03-28  Jens Remus  <jremus@linux.ibm.com>

	x86: Pass $NOPIE_LDFLAGS to undefined weak tests
	Some distributions configure GCC with --enable-default-pie, so that it
	defaults to compile with -fPIE and link with -pie, which is unexpected
	by some of the tests.  Therefore link the PDE test programs with
	$NOPIE_LDFLAGS to disable PIE.

	This complements commit a7eaf017f959 ("Use NOPIE_CFLAGS and
	NOPIE_LDFLAGS to disable PIE").

	ld/testsuite/
		PR ld/21090
		* ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to
		disable PIE for the non-PIE versions of the test.

	Bug: https://sourceware.org/PR21090

2025-03-28  Jens Remus  <jremus@linux.ibm.com>

	ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF visibility tests
	Some distributions configure GCC with --enable-default-pie, so that it
	defaults to compile with -fPIE and link with -pie, which is unexpected
	by the test.  Therefore compile the non-PIC sources with $NOPIE_CFLAGS
	and link the test programs with $NOPIE_LDFLAGS.

	Commit 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added
	$NOPIE_CFLAGS when compiling sh1np.o and sh2np.o.  It missed to add it
	to mainnp.o.

	ld/testsuite/
		PR ld/21090
		* ld-vsb/vsb.exp (visibility_test): Add support for optional
		ldflags argument and use it when linking the test program.
		(mainnp.o): Compile with $NOPIE_CFLAGS.
		(vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS.

	Fixes: 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests")
	Bug: https://sourceware.org/PR21090

2025-03-28  Jens Remus  <jremus@linux.ibm.com>

	ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to even more ELF shared tests
	Some distributions configure GCC with --enable-default-pie, so that it
	defaults to compile with -fPIE and link with -pie, which is unexpected
	by the test.  Therefore compile the non-PIC sources with $NOPIE_CFLAGS
	and link the test programs with $NOPIE_LDFLAGS.

	Commit 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF
	tests") added $NOPIE_CFLAGS when compiling sh1np.o.  It missed to add it
	to sh2np.o and mainnp.o.

	ld/testsuite/
		PR ld/21090
		* ld-shared/shared.exp (shared_test): Add support for optional
		ldflags argument and use it when linking the test program.
		(sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS.
		(shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS.

	Fixes: 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests")
	Bug: https://sourceware.org/PR21090

2025-03-28  Jens Remus  <jremus@linux.ibm.com>

	ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr21964-4
	Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on
	Fedora 41.  The reason is that GCC on Ubuntu is configured with
	--enable-default-pie, so that it defaults to compile with -fPIE
	and link with -pie, which causes the test to erroneously fail.

	ld/testsuite/
		PR ld/21090
		* ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and
		link with $NOPIE_LDFLAGS.

	Bug: https://sourceware.org/PR21090

2025-03-28  Jens Remus  <jremus@linux.ibm.com>

	ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr19719
	Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41
	but not on Ubuntu 24.10.  The reason is that GCC on Ubuntu is configured
	with --enable-default-pie, so that it defaults to compile with -fPIE
	and link with -pie, which hides the test fail.

	ld/testsuite/
		PR ld/21090
		* ld-elf/shared.exp: Compile pr19719 (non-PIE) with
		$NOPIE_CFLAGS and link with $NOPIE_LDFLAGS.

	Bug: https://sourceware.org/PR21090

2025-03-28  Marek Pikuła  <m.pikula@partner.samsung.com>

	RISC-V: Don't show support for 1.9.1 priv spec
	The privileged spec 1.9.1 support was removed since binutils 2.43. The
	linker only recognizes it and then reports a warning that it may
	conflict with other spec versions.

	While the support is removed, binutils should still recognize it, but it
	shouldn't be exposed to the user in `disassember-options` help.

2025-03-28  Marek Pikuła  <m.pikula@partner.samsung.com>

	doc/riscv: Add description of disassembler options
	Up to this point, no mention of RISC-V-specific disassembler options was
	mentioned in binutils documentation. This patch includes description for
	all of the currently supported options.

2025-03-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-27  Craig Blackmore  <craig.blackmore@embecosm.com>
	    Andrew Burgess  <aburgess@redhat.com>

	gdb: Fix assertion failure when inline frame #0 is duplicated
	Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
	the following incorrect backtrace:

	  #0  inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
	  #1  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
	  #2  0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
	  #3  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
	  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
	  (gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1

	The expected output, which we get with `bt`, is:

	  #0  inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
	  #1  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
	  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
	  (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1

	The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
	frame ids having already been computed and stashed.  Unlike other
	frames, frame #0's id does not get computed immediately.

	The test passes with `bt` because when applying python frame filters,
	the call to `bootstrap_python_frame_filters` happens to compute the id
	of frame #0.  When `get_prev_frame_maybe_check_cycle` later tries to
	stash frame #2's id, the cycle is detected.

	The test fails with `bt -no-filters` because frame #0's id has not been
	stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
	frame #2's id which succeeds and the cycle is only detected later when
	trying to stash frame #4's id.  Doing `stepi` after the incorrect
	backtrace would then trigger an assertion failure when trying to stash
	frame #0's id because it is a duplicate of #2's already stashed id.

	In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
	compute and stash its frame id before returning the previous frame.
	This ensures that the id of inline frame 0 has been stashed before
	`get_prev_frame_maybe_check_cycle` is called on older frames.

	The test case has been updated to run both `bt` and `bt -no-filters`.

2025-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Drop two words from codespell-ignore-words.txt
	Tom Tromey mentioned [1] that the words "invokable" and "useable"
	present in codespell-ignore-words.txt should be dropped.

	Do so and fix the following typos:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport
	gdbsupport/common-debug.h:218: invokable ==> invocable
	gdbsupport/event-loop.cc:84: useable ==> usable
	...

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html

2025-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add SME to codespell-ignore-words.txt
	Ignore the following codespell detection:
	...
	$ codespell --config gdbserver/setup.cfg gdbserver
	gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS
	...
	by adding SME to codespell-ignore-words.txt.

	[gdbserver] Fix typo in tracepoint.cc
	Fix a typo:
	...
	$ codespell --config gdbserver/setup.cfg gdbserver/tracepoint.cc
	gdbserver/tracepoint.cc:951: mistakingly ==> mistakenly
	...

	[gdbsupport] Ignore pathc in codespell check in gdb_tilde_expand.cc
	Ignore the following codespell detections:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport
	gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch
	gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch
	...
	by adding codespell:ignore comments.

	[gdbsupport] Fix a typo in common-debug.h
	Fix a typo:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h
	gdbsupport/common-debug.h:109: re-used ==> reused
	...

2025-03-27  oltolm  <oleg.tolmatcev@gmail.com>
	    Simon Farre  <simon.farre.cx@gmail.com>

	gdb/dap - Add CompletionsRequest
	Use GDB/MI command "-complete" to implement.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31140
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp
	In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run
	into:
	...
	(gdb) inferior 2
	[Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)]
	[Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running)
	(gdb) print global_var = 555
	$1 = 555
	(gdb) print global_var
	$2 = 556
	(gdb) FAIL: $exp: all-stop: access mem \
	  (print global_var after writing, inf=2, iter=1)
	...

	I managed to reproduce this on current trunk using a reproducer patch (posted
	in the PR).

	The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix
	gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced
	an increment of global_var at the start of main.

	This created a race between:
	- gdb modifying global_var, and
	- the inferior modifying global_var.

	Fix this by:
	- adding a new empty function setup_done,
	- adding a call to setup_done after the increment of global_var, and
	- rather than running to main, running to setup_done.

	Tested on x86_64-linux.

	PR testsuite/32822
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822

2025-03-27  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Remove AVX10.2 256 bit rounding support
	Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit
	rounding is not that useful because we currently have rounding feature
	directly on E-core now and no need to use 256-bit rounding as somehow
	a workaround. This patch will remove all the support and backport to
	Binutils 2.44.

	gas/ChangeLog:

		* NEWS: Mention support removal.
		* config/tc-i386.c (build_evex_prefix): Remove U bit encode.
		(check_VecOperands): Remove ymm check for rounding.
		(s_insn): Revise .insn comment.
		* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm
		rounding related test.
		* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
		* testsuite/gas/i386/evex.d: Ditto.
		* testsuite/gas/i386/evex.s: Ditto.
		* testsuite/gas/i386/i386.exp: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
		* testsuite/gas/i386/x86-64-evex.d: Ditto.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-rounding-intel.d: Removed.
		* testsuite/gas/i386/avx10_2-rounding-inval.l: Removed.
		* testsuite/gas/i386/avx10_2-rounding-inval.s: Removed.
		* testsuite/gas/i386/avx10_2-rounding.d: Removed.
		* testsuite/gas/i386/avx10_2-rounding.s: Removed.
		* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed.
		* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed.
		* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed.

	opcodes/ChangeLog:

		* i386-dis.c (struct instr_info): Remove U bit.
		(get_valid_dis386): Roll back to APX condition.
		* i386-opc.tbl: Remove ymm rounding support.
		* i386-tbl.h: Regenerated.

2025-03-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-26  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: Force DWARF debuginfo where applicable in AIX systems
	In the AIX systems available for testing in the gcc compile farm, the
	default debug information format is stabs. This is a problem for many
	reasons, mainly that stabs is not as complete as dwarf and stabs is
	being deprecated in the next release. In the current state, we have:
	PASS: 39798
	FAIL: 7405
	When running these tests, I unfortunately didn't have the foresight to
	save the number of unsupported and untested cases.

	To improve testing there, this patch changes the gdb_compile TCL proc, so
	that if we're running tests in AIX, we requested debug info, and we
	haven't explicitly asked for some debuginfo format, gdb_compile will add
	-gdwarf to the compilation line, forcing DWARF to be used. After this
	patch, we get:
	PASS: 74548
	FAIL: 5963

	So not only do we have fewer failures, there are tens of thousands of
	tests that are no longer skipped.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  Jens Remus  <jremus@linux.ibm.com>

	ld: Correct test pr19719 naming mix-up
	The suffix "defined/undefined" in the ld test pr19719 name specifies
	whether weak fun() is defined or undefined is mixed up.

	The test builds an executable and a shared library. The latter in two
	flavors, one with weak fun() defined (libpr19719a.so, "defined") and
	one without weak fun() defined (libpr19719b.so, "undefined").

	The first "Run $exe fun [...]" invocation uses libpr19719b.so as
	libpr19719.so, which is build from dummy.c, which does not define fun.
	Thus fun is undefined during this test run.

	The second "Run $exe fun [...]" invocation uses libpr19719a.so as
	libpr19719.so, which is build from pr19719d.c, which does define fun.
	Thus fun is defined during this test run.

	Correct the test naming mix-up accordingly.

	ld/testsuite/
		* ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming
		mix-up of when weak fun is un-/defined.

2025-03-26  Guinevere Larsen  <guinevere@redhat.com>

	gdb: add configure option to disable compile
	GDB's compile subsystem is deeply tied to GDB's ability to understand
	DWARF. A future patch will add the option to disable DWARF at configure
	time, but for that to work, the compile subsystem will need to be
	entirely disabled as well, so this patch adds that possibility.

	I also think there is motive for a security conscious user to disable
	compile for it's own sake. Considering that the code is quite
	unmaintained, and depends on an equally unmaintained gcc plugin, there
	is a case to be made that this is an unnecessary increase in the attack
	surface if a user knows they won't use the subsystem. Additionally, this
	can make compilation slightly faster and the final binary is around 3Mb
	smaller. But these are all secondary to the main goal of being able to
	disable dwarf at configure time.

	To be able to achieve optional compilation, some of the code that
	interfaces with compile had to be changed. All parts that directly
	called compile things have been wrapped by ifdefs checking for compile
	support.  The file compile/compile.c has been setup in a similar way to
	how python's and guile's main file has been setup, still being compiled
	but only for with placeholder command.

	Finally, to avoid several new errors, a new TCL proc was introduced to
	gdb.exp, allow_compile_tests, which checks if the "compile" command is
	recognized before the inferior is started and otherwise skips the compile
	tests. All tests in the gdb.compile subfolder have been updated to use
	that, and the test gdb.base/filename-completion also uses this. The proc
	skip_compile_feature_tests to recognize when the subsystem has been
	disabled at compile time.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Remove compile-related attributes from struct language
	The following patch will add a configure option to disable the compile
	subsystem at compilation time. To do that, nearly all code that
	interfaces with compile should be confined to the compile sub-folder.

	This commit is the first step, removing the compile-related method from
	the language struct and adding 2 new functions to compile.c that do the
	same job in a slightly different way. Adding things to the language
	struct is a more extendable way to add support for languages, but
	considering compile is quite bit-rotted and questionably supported, I
	don't think it will be extended any time soon, and using ifdefs to
	handle disabling compile with configure felt like a messier solution.

	There should be no visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use reference in cutu_reader::cutu_reader interface
	Change some parameters to be references instead of pointers, when the
	value must not be nullptr.  I'd like to do this more of this kind of
	change, but I have to limit the scope of the change, otherwise there's
	just no end (and some local variables could also be turned into
	references).  So for now, just do it the cutu_reader constructors.

	Change-Id: I9442c6043726981d58f9b141f516c590c0a71bcc
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: update comment of cutu_reader::cutu_reader (the DWO variant)
	The comment on this constructor is really outdated.  Update it to better
	reflect the reality today.

	I'd eventually like to change this cutu_reader constructor not to use
	dwarf2_per_cu, because it seems like an abuse of dwarf2_per_cu just to
	pass 3 values.  But for now, just document the existing behavior.

	Change-Id: Id96db020c361e64d9b0d2f25d51950b206658aa2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove redundant read of dwo_name
	lookup_dwo_unit receives the name of the DWO unit to look up, as read
	from the DW_AT_dwo_name attribute of the skeleton DIE.  But then, it
	doesn't use it:

	    /* Yeah, we look dwo_name up again, but it simplifies the code.  */
	    dwo_name = dwarf2_dwo_name (comp_unit_die, cu);

	Perhaps this comment made sense at some point, but with the code we have
	today, I don't understand it.  It should be fine to use the name passed
	as a parameter, which the caller also obtained by calling
	dwarf2_dwo_name.

	Change-Id: I84723e12726f77e4202d042428ee0eed9962ceb8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-26  WANG Xuerui  <git@xen0n.name>

	LoongArch: Fix disassembly option parsing stopping at the first option
	Turns out the return value of parse_loongarch_dis_option acts as an
	error code, and previously the function always signified failure with
	a non-zero return value, making only the first disassembly option get
	to take effect.

	Fix by adding the missing `return 0`'s to the two success code paths.

2025-03-26  Roland McGrath  <mcgrathr@google.com>

	ld: Support RELRO in aarch64-elf target
	Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so
	enable `-z relro` and related features.  Make aarch64-elf match.
	There is no reason to think that a "generic ELF" target should
	have any particular set of features disabled.

2025-03-26  Jerry Zhang Jian  <jerry.zhangjian@sifive.com>

	RISC-V: add Smrnmi 1.0 instruction support
	Add instruction `mnret' support

	Ref:
	https://github.com/riscv/riscv-isa-manual/blob/bb8b9127f81965eeff2d150c211d1c89376591c4/src/rnmi.adoc
	https://github.com/riscv/riscv-opcodes/blob/946eb673874b3a0f2474d1424dc28bc7ee53c306/extensions/rv_smrnmi

	bfd/ChangeLog:
	    * elfxx-riscv.c: Add new Smrnmi instruction class handling

	gas/ChangeLog:
	    * testsuite/gas/riscv/smrnmi.s: New test for mnret
	    * testsuite/gas/riscv/rmrnmi.d: Likewise

	include/ChangeLog:
	    * opcode/ricsv-opc.h: Add MATCH_MNRET, MASK_MNRET
	    * opcode/riscv.h: Add new instruction class

	opcodes/ChangeLog:
	    * riscv-opc.c: Add `mnret' instruction

2025-03-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: use std::equal_range in cooked_index_shard::find
	Looking at `cooked_index_shard::find`, I thought that we could make a
	small optimization: when finding the upper bound, we already know the
	lower bound.  And we know that the upper bound is >= the lower bound.
	So we could pass `lower` as the first argument of the `std::upper_bound`
	call to cut the part of the search space that is below `lower`.

	It then occured to me that what we do is basically what
	`std::equal_range` is for, so why not use it.  Implementations of
	`std::equal_range` are likely do to things as efficiently as possible.

	Unfortunately, because `cooked_index_entry::compare` is sensitive to the
	order of its parameters, we need to provide two different comparison
	functions (just like we do know, to the lower_bound and upper_bound
	calls).  But I think that the use of equal_range makes it clear what the
	intent of the code is.

	Regression tested using the various DWARF target boards on Debian 12.

	Change-Id: Idfad812fb9abae1b942d81ad9976aeed7c2cf762
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: remove unnecessary comparison in cooked_index_entry::compare
	I believe that the `(mode == MATCH && a == munge ('<'))` part of the
	condition is unnecesary.  Or perhaps I don't understand the algorithm.

	The use of "munge" above effectively makes it so that the template
	portion of names is completely ignored for the sake of the comparison.

	Then, in the condition, this:

	    a == munge ('<')

	is functionally equivalent to

	    a == '\0'

	If `a` is indeed '\0', and `b` is also '\0', then we would have taken
	the earlier branch:

	    if (a == b)
	      return 0;

	If `b` is not '\0', then we won't take this branch and we'll go into the
	final comparison:

	    return a < b ? -1 : 1;

	So, as far as I can see, there is no case where `mode == MATCH`, where
	we're going to use this special `return 0`.

	Regression tested using the various DWARF target boards on Debian 12.

	Change-Id: I5ea0463c1fdbbc1b003de2f0a423fd0073cc9dec
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-25  Nick Clifton  <nickc@redhat.com>

	Delete the ARM sub-directory of the SIM directory.

2025-03-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: move CU check up in cutu_reader::read_cutu_die_from_dwo
	We have this pattern of check in multiple places:

	    /* Skip dummy compilation units.  */
	    if (m_info_ptr >= begin_info_ptr + this_cu->length ()
	        || peek_abbrev_code (abfd, m_info_ptr) == 0)
	      m_dummy_p = true;

	In all places except one (read_cutu_die_from_dwo), this is done after
	reading the unit header but before potentially reading the first DIE.
	The effect is that we consider dummy units that have no DIE at all.
	Either the "data" portion of the unit (the portion after the header) has
	a size of zero, or the first abbrev code is 0, i.e. "end of list".

	According to this old commit I found [1], dummy CUs were used as filler
	for incremental LTO linking.  A comment reads:

	   WARNING: If THIS_CU is a "dummy CU" (used as filler by the incremental
	   linker) then DIE_READER_FUNC will not get called.

	In read_cutu_die_from_dwo, however, this check is done after having read
	the first DIE.  So at the time of the check, m_info_ptr has already been
	advanced just past the first DIE.  As a result, compilations units with
	a single DIE are considered (erroneously, IMO) as dummy.

	In commit aab6de1613df ("gdb/dwarf: fix spurious error when encountering
	dummy CU") [2], I mentioned a real world case where compilation units
	with a single top-level DIE were being considered dummy.  I believe that
	those units should not actually have been treated as dummy.  A CU with
	just one DIE may not be very interesting, but I don't see any reason to
	consider it dummy.

	Move the dummy check above the read_toplevel_die call, and return early
	if the CU is dummy.

	I am 99% convinced that it's not even possible to encounter an empty
	unit here, and considered turning it into an assert (it did pass the
	testsuite).  This function is passed a dwo_unit, and functions that
	create a dwo_unit are:

	 - create_debug_type_hash_table (creates a dwo_unit for each type unit
	   found in a dwo file)
	 - create_cus_hash_table (creates a dwo_unit for each comp unit found in
	   a dwo file)
	 - create_dwo_unit_in_dwp_v1
	 - create_dwo_unit_in_dwp_v2
	 - create_dwo_unit_in_dwp_v5

	In the first two, there are already dummy checks, so we wouldn't even
	get to read_cutu_die_from_dwo for such an empty CU.  However, in the
	last three, there is no such checks, we just trust the dwp file's index
	and create dwo_units out of that.  So I guess it would be possible to
	craft a broken dwp file with a CU that has no DIE.  Out of caution, I
	didn't switch that to an assert, but I also don't really know what would
	be the mode of failure if that were to happen.

	Regtested using the various DWARF target boards on Debian 12.

	[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/dee91e82ae87f379c90fddff8db7c4b54a116609#dd409f60ba6f9c066432dafbda7093ac5eec76d1_3434_3419
	[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/aab6de1613df693059a6a2b505cc8f20d479d109

	Change-Id: I90e6fa205cb2d23ebebeae6ae7806461596f9ace
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: remove cutu_reader::read_cutu_die_from_dwo abbrev table parameter
	This parameter is always used to set cutu_reader::m_dwo_abbrev_table.
	Remove the parameter, and have read_cutu_die_from_dwo set the field
	directly.

	Change-Id: I6c0c7d23591fb2c3d28cdea1befa4e6b379fd0d3
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-24  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64: Add missing FEAT_MEC dc encodings and gate sysregs
	FEAT_MEC support was introduced in [1]. However, the dc instruction was
	missing these encodings:
	- DC CIPAE
	- DC CIGDPAE

	Furthermore, the Arm ARM states that FEAT_MEC is an optional extension,
	introduced for v9.2-a.
	Therefore, these sysregs:
	- MECIDR_EL2
	- MECID_P0_EL2
	- MECID_A0_EL2
	- MECID_P1_EL2
	- MECID_A1_EL2
	- VMECID_P_EL2
	- VMECID_A_EL2
	- MECID_RL_A_EL3

	which were introduced in that commit now require -march=armv9.2-a at the very
	least to be enabled, as well as the dc encodings.

	opcodes/ChangeLog:
		* aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae".
		* aarch64-sys-regs.def: Add V8_7A as a requirement for the above system
		registers.

	gas/testsuite/gas/ChangeLog
		* aarch64/mec-invalid.s: Add .arch directive.
		* aarch64/mec.d: Add .arch directive and check for cipae, cigdpae.
		* aarch64/mec.s: Add MEC data cache operations test.
		* aarch64/mec-arch-bad.d: New test to check for bad arch version.
		* aarch64/mec-arch-bad.l: Above.

	[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3

	Regression tested on aarch64-none-elf

2025-03-24  Tom Tromey  <tromey@adacore.com>

	Introduce gdb_bfd_canonicalize_symtab
	bfd_canonicalize_symtab stores the symbols in the BFD, and returns
	pointers to these.  The ELF reader does not reuse these stored
	symbols, so each call to bfd_canonicalize_symtab causes an allocation.

	This interacts poorly with code like arm_pikeos_osabi_sniffer, which
	searches the BFD symbol when called.

	PR gdb/32758 points out a particularly pathological case: using "maint
	info sections" on a program with a large number of sections (10000)
	will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G.

	I'm not sure BFD always worked this way.  And, fixing BFD was an
	option.  However it seemed maybe better for GDB to adapt, since
	adapting would mean that the fix would apply to all BFD back ends, and
	not just ELF.

	To that end, this patch adds a new gdb_bfd_canonicalize_symtab and
	changes all callers of bfd_canonicalize_symtab to use it instead.
	This new function caches the result in the per-BFD object.

	I looked into having this return a view of "const asymbol *".  However
	both the compile module and machoread modify the returned symbols.
	And while I think this is wrong, I haven't tried to fix this here.

	Regression tested on x86-64 Fedora 40.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758

2025-03-24  Tom Tromey  <tromey@adacore.com>

	Add compile test for color option
	Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)")
	fixed a compilation error in color_option_def when building with
	clang.  It seemed to me that it would be good to add a compile test
	for this code.

2025-03-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-21  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: Test the effect of amdgpu-precise memory
	The gdb.rocm/precise-memory.exp test currently checks that the "amdgpu
	precise-memory" setting can be set.  It does not test that this setting
	has any meaningful effect.

	This patch extends this test to ensure that precise-memory has the
	expected behaviour.

	Change-Id: I58f72a51a566f04fc89114b94ee656c2e7ac35bb
	Approved-by: Pedro Alves <pedro@palves.net>

2025-03-21  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite/lib/rocm: Drop hip_devices_support_precise_memory
	Remove hip_devices_support_precise_memory as this is not used anymore.

	Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967
	Approved-by: Pedro Alves <pedro@palves.net>

2025-03-21  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuise: gdb.rocm/precise-memory.exp to not require hip_devices_support_precise_memory
	The gdb.rocm/precise-memory.exp test adjusts its behaviour based on the
	value returned by hip_devices_support_precise_memory.  This function has
	static assumption regarding HW capabilities, which might not be
	accurate.

	Adjust the test so it does not assume anything about HW capabilities,
	but instead just ensure that GDB behaves consistently.

	Change-Id: Ie1f9c6219b88b94f6d461a254b2ad616b92db6b9
	Approved-by: Pedro Alves <pedro@palves.net>

2025-03-21  Tom Tromey  <tom@tromey.com>

	Introduce die_info::children and use it
	This adds a new die_info::children method.  This returns a range that
	can be used to iterate over a DIE's children.

	Then this goes through and updates all the relevant loops to use
	foreach instead.  This is a net code reduction.

	You'll note that in some places the code was checking the tag as well,
	like:

	      while (child_die && child_die->tag)

	I believe this can't happen and is just a copy-paste oddity from the
	old days.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-21  Tom Tromey  <tom@tromey.com>

	Rename die_info::sibling to die_info::next
	I want to add support for C++ foreach iteration over DIE siblings.

	I considered writing a custom iterator for this, but it would be
	largely identical to the already-existing next_iterator.  I didn't
	want to duplicate the code...

	Then I tried parameterizing next_iterator by having it take an
	optional pointer-to-member template argument.  However, this would
	involve changes in many places, because currently a next_iterator can
	be instantiated before the underlying type is complete.

	So in the end I decided to rename die_info::sibling to die_info::next.
	This name is slightly worse but (1) IMO it isn't really all that bad,
	nobody would have blinked if it was called 'next' in the initial
	patch, and (2) with the change to iteration it is barely used.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-21  Tom Tromey  <tromey@adacore.com>

	Simplify warning_pre_print
	This changes warning_pre_print to not include the text "warning",
	which is now unconditional.  I think this is a bit clearer, and anyway
	it is convenient to support the next patch.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-03-21  Tom Tromey  <tromey@adacore.com>

	Do not use warning_pre_print in linux-thread-db.c
	linux-thread-db.c may print "warning_pre_print" before displaying an
	error message.  This seems like a mistake to me, and furthermore I
	think it's best to be as sparing as possible with uses of
	warning_pre_print, so this patch removes the prefix.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-03-21  Andrew Burgess  <aburgess@redhat.com>

	gdb: check styled status of source cache entries
	Currently GDB's source cache doesn't track whether the entries within
	the cache are styled or not.  This is pretty much fine, the assumption
	is that any time we are fetching source code, we do so in order to
	print it to the terminal, so where possible we always want styling
	applied, and if styling is not applied, then it is because that file
	cannot be styled for some reason.

	Changes to 'set style enabled' cause the source cache to be flushed,
	so future calls to fetch source code will regenerate the cache entries
	with styling enabled or not as appropriate.

	But this all assumes that styling is either on or off, and that
	switching between these two states isn't done very often.

	However, the Python API allows for individual commands to be executed
	with styling turned off via gdb.execute().  See commit:

	  commit e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
	  Date:   Thu Feb 13 15:39:31 2025 +0000

	      gdb/python: new styling argument to gdb.execute

	Currently the source cache doesn't handle this case. Consider this:

	  (gdb) list main
	  ... snip, styled source code displayed here ...
	  (gdb) python gdb.execute("list main", True, False, False)
	  ... snip, styled source code is still shown here ...

	In the second case, the final `False` passed to gdb.execute() is
	asking for unstyled output.

	The problem is that, `get_source_lines` calls `ensure` to prime the
	cache for the file in question, then `extract_lines` just pulls the
	lines of interest from the cached contents.

	In `ensure`, if there is a cache entry for the desired filename, then
	that is considered good enough.  There is no consideration about
	whether the cache entry is styled or not.

	This commit aims to fix this, after this commit, the `ensure` function
	will make sure that the cache entry used by `get_source_lines` is
	styled correctly.

	I think there are two approaches I could take:

	  1. Allow multiple cache entries for a single file, a styled, and
	     non-styled entry.  The `ensure` function would then place the
	     correct cache entry into the last position so that
	     `get_source_lines` would use the correct entry, or

	  2. Have `ensure` recalculate entries if the required styling mode is
	     different to the styling mode of the current entry.

	Approach #1 is better if we are rapidly switching between styling
	modes, while #2 might be better if we want to keep more files in the
	cache and we only rarely switch styling modes.

	In the end I chose approach #2, but the good thing is that the changes
	are all contained within the `ensure` function.  If in the future we
	wanted to change to strategy #1, this could be done transparently to
	the rest of GDB.

	So after this commit, the `ensure` function checks if styling is
	currently possible or not.  If it is not, and the current entry is
	styled, then the current entry only is dropped from the cache, and a
	new, unstyled entry is created.  Likewise, if the current entry is
	non-styled, but styling is required, we drop one entry and
	recalculate.

	With this change in place, I have updated set_style_enabled (in
	cli/cli-style.c) so the source cache is no longer flushed when the
	style settings are changed, the source cache will automatically handle
	changes to the style settings now.

	This problem was discovered in PR gdb/32676.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-21  Jan Beulich  <jbeulich@suse.com>

	strip: don't corrupt PE binary's section/file alignment
	Section and file alignment are supposed to remain unaltered when PE
	binaries are stripped. While this is the case when they're strip-ed
	individually, passing multiple such files to strip would reset the
	two values to their defaults in all but the first of those binaries.

2025-03-21  Jan Beulich  <jbeulich@suse.com>

	aarch64: simplify RCPC3 unpredictable logic
	The original observation was that STILP is warned about when everything
	is fine. Documentation, not just for STILP, says explicitly that
	behavior is identical to respective pre-existing insns (for STILP in
	particular that's STP). With that it's unclear why distinct logic was
	added: Other code can be re-used, simply distinguishing by the number of
	operands. This was diagnostics also end up more consistent.

	Along with adding some STILP uses to the (positive) testcase, also add a
	pair of STLR to similarly demonstrate that the register overlap goes
	without warning when there's no write-back.

2025-03-21  Dongyan Chen  <chendongyan@isrc.iscas.ac.cn>

	RISC-V: Ssnpm, smnpm and smmpm imply zicsr.
	According to the spec[1], imply zicsr for ssnpm, smnpm and smmpm.

	[1] https://github.com/riscv/riscv-j-extension/blob/master/zjpm/instructions.adoc

	bfd/ChangeLog:

		* elfxx-riscv.c: imply zicsr.

2025-03-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-20  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Fix typo in common-inferior.h
	Fix the following typo:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport/
	gdbsupport/common-inferior.h:57: elemets ==> elements
	...

2025-03-20  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Remove the unused pr19636-3d.d
	Remove the unused pr19636-3d.d since static Position Dependent Executable
	doesn't have a dynamic symbol table.

		PR ld/32807
		* testsuite/ld-x86-64/pr19636-3d.d: Removed.

2025-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix typos in gdb.threads/infcall-from-bp-cond-simple.exp
	Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp.

2025-03-20  Tom Tromey  <tromey@adacore.com>

	Fix grammar error in dwarf2/attribute.h
	A recent patch of mine had a comment with bad grammar; apparently I
	didn't finish editing it.  This patch cleans it up.

2025-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing returns in gdb.threads/infcall-from-bp-cond-simple.c
	While investigating PR32785 I noticed a missing return statement in
	worker_func, and compiling with -Wreturn-type showed another in
	function_that_segfaults:
	...
	$ gcc gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c -Wreturn-type
	infcall-from-bp-cond-simple.c: In function ‘function_that_segfaults’:
	infcall-from-bp-cond-simple.c:46:1: warning: \
	  control reaches end of non-void function [-Wreturn-type]
	   46 | }
	      | ^
	infcall-from-bp-cond-simple.c: In function ‘worker_func’:
	infcall-from-bp-cond-simple.c:58:1: warning: \
	  control reaches end of non-void function [-Wreturn-type]
	   58 | }
	      | ^
	...

	Fix these by adding the missing returns.

2025-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix build with gcc 9
	Since commit a691853148f ("gdb/python: introduce gdbpy_registry"), when
	building gdb with gcc 9, I run into:
	...
	In file included from gdb/varobj.c:38:0:
	gdb/python/python-internal.h:1211:47: error: expected ‘;’ before ‘<’ token
	   using StorageKey = typename registry<O>::key<Storage>;
	                                               ^
	...
	due to this code:
	...
	template <typename Storage>
	class gdbpy_registry
	{
	  ...

	  template<typename O>
	  using StorageKey = typename registry<O>::key<Storage>;

	  template<typename O>
	  Storage *get_storage (O *owner, const StorageKey<O> &key) const
	  { ... }

	  ...
	}
	...

	As an experiment, I tried out eliminating the type alias:
	...
	  template<typename O>
	  Storage *get_storage (O *owner,
	                        const typename registry<O>::key<Storage> &key) const
	  { ... }
	...
	and got instead:
	...
	In file included from gdb/varobj.c:38:0:
	gdb/python/python-internal.h:1211:63: error: non-template ‘key’ used as template
	  Storage *get_storage (O *owner,
	                        const typename registry<O>::key<Storage> &key) const
	                                                     ^~~
	gdb/python/python-internal.h:1211:63: note: use ‘registry<O>::template key’ \
	  to indicate that it is a template
	...

	Following that suggestion, I tried:
	...
	  template<typename O>
	  Storage *
	  get_storage (O *owner,
	               const typename registry<O>::template key<Storage> &key) const
	  { ... }
	...
	which fixed the problem.

	Likewise, adding the template keyword in the type alias fixes the original
	problem, so fix it like that.

	Tested on x86_64-linux.

2025-03-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-19  Sam James  <sam@gentoo.org>

	gcore: quote PKGVERSION
	Same as 3bed686102cb14552d2ed1b83336453d7ce0dd47. I didn't hit an issue
	here -- I think because my /bin/sh is dash and gdb-add-index has a /bin/sh
	shebang, while gcore uses bash, but it's still worth fixing (we certainly
	do NOT want this to be an array).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325

2025-03-19  Sam James  <sam@gentoo.org>

	gdb-add-index: quote PKGVERSION
	In Gentoo, we configure our gdb with `--with-pkgversion=` with
	"Gentoo VERSION XXXX" where XXX depends on patching (not that we patch
	gdb really these days) or vanilla.

	Since 71f193a5c1cb02dcde6ac160cdab88e9725862bb, this goes wrong, yielding
	```
	/usr/bin/gdb-add-index: 25: Syntax error: "(" unexpected
	```

	with lines 25-26 being:
	```
	PKGVERSION=(Gentoo 9999 vanilla)
	VERSION=17.0.50.20250319-git
	```

	Quote both assignments (PKGVERSION by necessity, VERSION for consistency
	or symmetry).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: convert gdb.Symtab_and_line to use gdbpy_registry
	This commit converts gdb.Symtab_and_line to use gdbpy_registry for
	lifecycle management.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: convert gdb.Symtab to use gdbpy_registry
	This commit converts gdb.Symtab to use gdbpy_registry for lifecycle
	management. Since gdb.Symtab only holds on the struct symtab * (and
	prev/next links) the default invalidator can be used.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: convert gdb.Type to use gdbpy_registry
	This commit converts gdb.Type to use gdbpy_registry for lifecycle
	management.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: convert gdb.Symbol to use gdbpy_registry
	This commit converts gdb.Symbol to use gdbpy_registry for lifecycle
	management. Since gdb.Symbol only holds on the struct symbol * (and
	prev/next links) the default invalidator can be used.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: introduce gdbpy_registry
	This commit introduces new template class gdbpy_registry to simplify
	Python object lifecycle management. As of now, each of the Python
	object implementations contain its own (copy of) lifecycle management
	code that is largely very similar. The aim of gdbpy_registry is to
	factor out this code into a common (template) class in order to simplify
	the code.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: do not hold on gdb.Type object from gdb.Value
	Previous commit changed type_to_type_object() so each time it is
	called with particular struct value* it returns the same object.

	Therefore there's no longer need to hold on type objects (gdb.Type)
	from struct value_object in order to preserve identity of gdb.Type
	objects held in value_object::type and value_object::dynamic_type
	members. This in turn allowed for some simplification in various
	functions.

	While at it I changed a couple of NULLs to nullptrs.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: preserve identity for gdb.Type objects
	This commit changes type_to_type_object() so that each it is called
	with a particular struct type * it returns the very same gdb.Type
	object.

	This is done in the same way as for gdb.Symtab objects in earlier commit
	("gdb/python: preserve identity for gdb.Symtab objects") except that
	types may be either objfile-owned or arch-owned.

	Prior this commit, arch-owned objects we not put into any list (like
	objfile-owned ones) so they could not be easily looked up. This commit
	changes the code so arch-owned list are put into per-architecture list
	which is then used (solely) for looking up arch-owned gdb.Type.

	Another complication comes from the fact that when objfile is about to
	be freed, associated gdb.Type instances are not merely invalidated
	(like it is done with gdb.Symtab or gdb.Symbol objects) but instead the
	type is copied and the copy is arch-owned. So we need two different
	"deleters", one for objfile-owned types that copies the type (as before)
	and then insert the object to per-architecture list and another one
	for arch-owned types.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_line
	Previous commit changed symtab_to_symtab_object() so each time it is
	called with particula struct symtab* it returns the same object.

	Therefore there's no longer need to hold on symtab object (gdb.Symtab)
	from struct sal_object in order to preserve identity of Symtab object
	held in gdb.Symtab_and_line.symtab property. This in turn allowed for
	some simplification in various functions.

	While at it I changed a couple of NULLs to nullptrs.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: preserve identity for gdb.Symbol objects
	This commit changes symbol_to_symbol_object() so that each it is called
	with a particular struct symbol * it returns the very same gdb.Symbol
	object.

	This is done in the same way as for gdb.Symtab objects in earlier commit
	("gdb/python: preserve identity for gdb.Symtab objects") except that
	symbols may be either objfile-owned or arch-owned.

	Prior this commit, arch-owned objects we not put into any list (like
	objfile-owned ones) so they could not be easily looked up. This commit
	changes the code so arch-owned list are put into per-architecture list
	which is then used (solely) for looking up arch-owned gdb.Symbol.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: preserve identity for gdb.Symtab objects
	This commit changes symtab_to_symtab_object() so that each it is called
	with a particular struct symtab * it returns the very same gdb.Symtab
	object.

	This is done by searching per-objfile linked list of instances and - if
	found - return it rather than creating new gdb.Symtab.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: change set_internalvar_function to take a unique pointer
	This makes the transfer of ownership a bit clearer, even though the
	internal_function is still held with a raw pointer inside internalval.

	Change-Id: Ie8d13270b64737b92291532acfbfcbc992b482b5
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: handle INTERNALVAR_FUNCTION in clear_internalvar
	While checking the list of leaks reported by ASan, I found that
	clear_internalvar doesn't free the internal_function object owned by the
	internalvar when the internalvar is of kind INTERNALVAR_FUNCTION, fix
	that.

	Change-Id: I78f53b83b97bae39370a7b5ba5e1cec70626d66a
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: clear internalvar on destruction
	The data associated to an internalvar is destroyed when changing the
	kind of the internalvar, but not when it is destroyed.  Fix that by
	calling clear_internalvar in ~internalvar.

	A move constructor becomes needed to avoid freeing things multiple times
	when internalvars are moved (and if we forget it, clang helpfully gives
	us a -Wdeprecated-copy-with-user-provided-dtor warning).

	Change-Id: I427718569208fd955ea25e94d341dde356725033
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: C++-ify internal_function
	Change the `name` field to std::string, add constructor.  Remove
	function `create_internal_function`, since it becomes a trivial wrapper
	around the constructor.

	Change-Id: Ifc8b1282c442e1930bcd69d6e140128067e49563
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: new styling argument to gdb.execute
	Currently, gdb.execute emits styled output when the command is sending
	its output to GDB's stdout, and produces unstyled output when the
	output is going to a string.

	But it is not unreasonable that a user might wish to capture styled
	output from a gdb.execute call, for example, the user might want to
	display the styled output are part of some larger UI output block.

	At the same time, I don't think it makes sense to always produce
	styled output when capturing the output in a string; if what the user
	wants is to parse the output, then the style escape sequences make
	this far harder.

	I propose that gdb.execute gain a new argument 'styling'.  When False
	we would always produce unstyled output, and when True we would
	produce styled output if styling is not disabled by some other means.

	For example, if GDB's 'set style enabled' is off, then I think
	gdb.execute() should respect that.  My assumption here is that
	gdb.execute() might be executed by some extension.  If the extension
	thinks "styled output world work here", but the user hates styled
	output, and has turned it off, then the extension should not be
	forcing styled output on the user.

	I chose 'styling' instead of 'styled' as the Python argument name
	because we already use 'styling' in gdb.Value.format_string, and we
	don't use 'styled' anywhere else.  This is only a little bit of
	consistency, but I still think it's a good thing.

	The default for 'styling' will change depending on where the output is
	going.  When gdb.execute is sending the output to GDB's stdout then
	the default for 'styling' is True.  When the output is going to a
	string, then the default for 'styling' will be False.  Not only does
	this match the existing behaviour, but I think this makes sense.  By
	default we assume that output captured in a string is going to be
	parsed, and therefore styling markup is unhelpful, while output going
	to stdout should receive styling.

	This fixes part of the problem described in PR gdb/32676.  That bug
	tries to capture styled source listing in a string, which wasn't
	previously possible.

	There are some additional issues with capturing source code; GDB
	caches the source code in the source code cache.  However, GDB doesn't
	check if the cached content is styled or not.  As a consequence, if
	the first time the source of a file is shown it is unstyled, then the
	cached will hold the unstyled source code, and future requests will
	return that unstyled source.  I'll address this issue in a separate
	patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: show full shared library memory range in 'info sharedlibrary'
	On GNU/Linux (and other targets that use solib-svr4.c) the 'info
	sharedlibrary' command displays the address range for the .text
	section of each library.  This is a fallback behaviour implemented in
	solib_map_sections (in solib.c), for targets which are not able to
	provide any better information.

	The manual doesn't really explain what the address range given means,
	and the .text fallback certainly isn't described.  The manual for
	'info sharedlibrary' just says:

	  'info share REGEX'
	  'info sharedlibrary REGEX'
	       Print the names of the shared libraries which are currently loaded
	       that match REGEX.  If REGEX is omitted then print all shared
	       libraries that are loaded.

	In this commit I propose that we should change GDB so that the full
	library address range is listed for GNU/Linux (and other solib-svr4
	targets).  Though it is certainly useful to know where the .text for a
	library is, not all code is placed into the .text section, and data,
	or course, is stored elsewhere, so the choice of .text, though not a
	crazy default, is still a pretty arbitrary choice.

	We do also have 'maintenance info sections', which can be used to find
	the location of a specific section.  This is of course, a maintenance
	command, but we could make this into a real user command if we wanted,
	so the information lost by this change to 'info sharedlibrary' is
	still available if needed.

	There is one small problem.  After this commit, GDB is still under
	reporting the extents of some libraries, in some cases.

	What I observe is that sometimes, for reasons that I don't currently
	understand, the run-time linker will over allocate memory for the .bss
	like sections, e.g. the ELF says that 1 page is required, but 2 or 4
	pages will be allocated instead.  As a result, GDB will under report
	the extent of the library, with the end address being lower than
	expected.  This isn't always the case though, in many cases the
	allocates are as I would expect, and GDB reports the correct values.

	However, as we have been under reporting for many years, I think this
	update, which gets things a lot closer to reality, is a big step in
	the right direction.  We can always improve the results more later
	on if/when the logic behind the over allocations become clearer.

	For testing I've compared the output of 'info proc mappings' with the
	output of 'info sharedlibrary' (using a script), using GDB to debug
	itself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64,
	and other than the over allocation problem described above, the
	results all look good to me.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-19  Wataru Ashihara  <wsh@iij.ad.jp>

	gdbserver: fix build on NetBSD
	The function remove_thread() was changed to a method in 2500e7d7d (gdbserver:
	make remove_thread a method of process_info).

	Change-Id: I4b2d8a6f84b5329b8d450b268fa9453fe424914e

2025-03-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-18  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: use gdb::unordered_set for cooked_index_storage::m_reader_hash
	Replace an htab with gdb::unordered_set.  I think we could also use the
	dwarf2_per_cu pointer itself as the identity, basically have the
	functional equivalent of:

	  gdb::unordered_map<dwarf2_per_cu *, cutu_reader_up>

	But I kept the existing behavior of using dwarf2_per_cu::index as the
	identity.

	Change-Id: Ief3df9a71ac26ca7c07a7b79ca0c26c9d031c11d
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove type_unit_group
	The type_unit_group is an indirection between a stmt_list_hash (possible
	dwo_unit + line table section offset) and a type_unit_group_unshareable
	that provides no real value.  In dwarf2_per_objfile, we maintain a
	stmt_list_hash -> type_unit_group mapping, and in dwarf2_per_objfile, we
	maintain a type_unit_group_unshareable mapping.  The type_unit_group
	type is empty and only exists to have an identity and to be a link
	between the two mappings.

	This patch changes it so that we have a single stmt_list_hash ->
	type_unit_group_unshareable mapping.

	Regression tested on Debian 12 amd64 with a bunch of DWARF target
	boards.

	Change-Id: I9c5778ecb18963f353e9dd058e0f8152f7d8930c
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use gdb::unordered_map for dwarf2_per_bfd::{quick_file_names_table,type_unit_groups}
	Change these two hash tables to use gdb::unordered_map.  I changed these
	two at the same time because they both use the same key, a
	stmt_list_hash.  Unlike other previous patches that used a
	gdb::unordered_set, use an unordered_map here because the key isn't
	found in the element itself (well, it was before, because of how htab
	works, but it didn't need to be).

	You'll notice that the type_unit_group structure is empty.  That
	structure isn't really needed.  It is removed in the following patch.

	Regression tested on Debian 12 amd64 with a bunch of DWARF target
	boards.

	Change-Id: Iec2289958d0f755cab8198f5b72ecab48358ba11
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Remove is_nonnegative and as_nonnegative
	This removes attribute::is_nonnegative and attribute::as_nonnegative
	in favor of a call to unsigned_constant.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Handle DW_END_default
	I noticed that gdb doesn't handle DW_END_default.  This patch adds
	support for this.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Assume DW_AT_alignment is unsigned
	This changes get_alignment to assume that DW_AT_alignment refers to an
	unsigned value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Assume DW_AT_decl_line is unsigned
	This changes read_decl_line and new_symbol to assume that
	DW_AT_decl_line should refer to an unsigned value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Use form name in complaint in dwarf2_record_block_entry_pc
	This changes dwarf2_record_block_entry_pc to issue a complaint using
	the form name rather than a value.  This seems more correct to me.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Introduce and use attribute::unsigned_constant
	This introduces a new 'unsigned_constant' method on attribute.  This
	method can be used to get the value as an unsigned number.  Unsigned
	scalar forms are handled, and signed scalar forms are handled as well
	provided that the value is non-negative.

	Several spots in the reader that expect small DWARF-defined constants
	are updated to use this new method.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Rename form_is_signed to form_is_strictly_signed
	This renames attribute::form_is_signed to form_is_strictly_signed.  I
	think this more accurately captures what it does: it says whether a
	form will always use signed data -- not whether a form might use
	signed data, which DW_FORM_data* do depending on context.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/enum_cond.exp on arm-linux
	On arm-linux, I run into:
	...
	gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \
	  the output is to use 32-bit enums; use of enum values across objects may fail
	UNTESTED: gdb.base/enum_cond.exp: failed to compile
	...

	Fix this by using -nostdlib.

	Tested on arm-linux and x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: set m_top_level_die directly in read_cutu_die_from_dwo
	read_cutu_die_from_dwo currently returns the dwo's top-level DIE through
	a parameter.  Following the previous patch, all code paths end up
	setting m_top_level_die.  Simplify this by having read_cutu_die_from_dwo
	set m_top_level_die directly.  I think it's easier to understand,
	because there's one less indirection to follow.

	Change-Id: Ib659f1d2e38501a8fe2b5dd0ca2add3ef55e8d60
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: fix spurious error when encountering dummy CU
	I built an application with -gsplit-dwarf (i.e. dwo), and some CUs are
	considered "dummy" by the DWARF reader.  That is, the top-level DIE
	(DW_TAG_compile_unit) does not have any children.  Here's the skeleton:

	    0x0000c0cb: Compile Unit: length = 0x0000001d, format = DWARF32, version = 0x0005, unit_type = DW_UT_skeleton, abbr_offset = 0x529b, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000c0ec)

	    0x0000c0df: DW_TAG_skeleton_unit
	                  DW_AT_stmt_list [DW_FORM_sec_offset]      (0x09dee00f)
	                  DW_AT_dwo_name [DW_FORM_strp]     ("CMakeFiles/lib_crl.dir/crl/dispatch/crl_dispatch_queue.cpp.dwo")
	                  DW_AT_comp_dir [DW_FORM_strp]     ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")
	                  DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)

	And here's the entire debug info in the .dwo file:

	    .debug_info.dwo contents:
	    0x00000000: Compile Unit: length = 0x0000001a, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000001e)

	    0x00000014: DW_TAG_compile_unit
	                  DW_AT_producer [DW_FORM_strx]     ("GNU C++20 14.2.1 20250207 -mno-direct-extern-access -mtune=generic -march=x86-64 -gsplit-dwarf -g3 -gz=none -O2 -std=gnu++20 -fPIC -fno-strict-aliasing")
	                  DW_AT_language [DW_FORM_data1]    (DW_LANG_C_plus_plus_14)
	                  DW_AT_name [DW_FORM_strx] ("/home/simark/src/tdesktop/Telegram/lib_crl/crl/dispatch/crl_dispatch_queue.cpp")
	                  DW_AT_comp_dir [DW_FORM_strx]     ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")

	When loading the binary in GDB, I see some warnings:

	    $ ./gdb -q -nx --data-directory=data-directory -ex 'maint set dwarf sync on' -ex  "file /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop"
	    Reading symbols from /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop...
	    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc0cb
	    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc152
	    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc194
	    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc1b5
	    (gdb)

	It turns out that these errors are not really justified.  What happens
	is:

	 - cutu_reader::read_cutu_die_from_dwo return 0, indicating that the CU
	   is "dummy"
	 - back in cutu_reader::cutu_reader, we omit setting m_top_level_die to
	   the DIE from the dwo file, meaning that m_top_level_die keeps
	   pointing to the DIE from the main file (DW_TAG_skeleton_unit)
	 - later, in cutu_reader::prepare_one_comp_unit, there is a check that
	   m_top_level_die->tag is one of DW_TAG_{compile,partial,type}_unit,
	   which triggers

	My proposal to fix this is to set m_top_level_die even if the CU is
	dummy.  Even if the top-level DIE does not have any children, I don't
	see any reason to leave cutu_reader::m_top_level_die in a different
	state than when the CU is not dummy.

	While at it, set m_dummy_p directly in read_cutu_die_from_dwo, instead
	of returning a value and having the caller do it.  This is all inside
	cutu_reader anyway.

	Change-Id: I483a68a369bb461a8dfa5bf2106ab1d6a0067198
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove create_dwo_cu_reader
	This function, as can be seen by its comment, is a remnant of past
	design.  Inline its content into create_cus_hash_table.

	Change-Id: Id900bae2cdce8f33bf01199fb1d366646effc76e
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-18  Andrew Burgess  <aburgess@redhat.com>

	gdb: split up construct_inferior_arguments
	The function construct_inferior_arguments (gdbsupport/common-inferior.cc)
	currently escapes all special shell characters.  After this commit
	there will be two "levels" of quoting:

	  1. The current "full" quoting, where all posix shell special
	  characters are quoted, and

	  2. a new "reduced" quoting, where only the characters that GDB sees
	  as special (quotes and whitespace) are quoted.

	After this, almost all construct_inferior_arguments calls will use the
	"full" quoting, which is the current quoting.  The "reduced" quoting
	will be used in this commit to restore the behaviour that was lost in
	the previous commit (more details below).

	In the future, the reduced quoting will be useful for some additional
	inferior argument that I have planned.  I already posted my full
	inferior argument work here:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	But that series is pretty long, and wasn't getting reviewed, so I'm
	posted the series in parts now.

	Before the previous commit, GDB behaved like this:

	  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "$FOO".

	Notice that with 'startup-with-shell' off, the argument was left as
	just '$FOO'.  But after the previous commit, this changed to:

	  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "\$FOO".

	Now the '$' is escaped with a backslash.  This commit restores the
	original behaviour, as this is (currently) the only way to unquoted
	shell special characters into arguments from the GDB command line.
	The series that I listed above includes a new command line option for
	GDB which provides a better approach for controlling the quoting of
	special shell characters, but that work requires these patches to be
	merged first.

	I've split out the core of construct_inferior_arguments into the new
	function escape_characters, which takes a set of characters to escape.
	Then the two functions escape_shell_characters and
	escape_gdb_characters call escape_characters with the appropriate
	character sets.

	Finally, construct_inferior_arguments, now takes a boolean which
	indicates if we should perform full shell escaping, or just perform
	the reduced escaping.

	I've updated all uses of construct_inferior_arguments to pass a
	suitable value to indicate what escaping to perform (mostly just
	'true', but one case in main.c is different), also I've updated
	inferior::set_args to take the same boolean flag, and pass it through
	to construct_inferior_arguments.

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-18  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove the !startup_with_shell path from construct_inferior_arguments
	In the commit:

	  commit 0df62bf09ecf242e3a932255d24ee54407b3c593
	  Date:   Fri Oct 22 07:19:33 2021 +0000

	      gdb: Support some escaping of args with startup-with-shell being off

	nat/fork-inferior.c was updated such that when we are starting an
	inferior without a shell we now remove escape characters.  The
	benefits of this are explained in that commit, but having made this
	change we can now make an additional change.

	Currently, in construct_inferior_arguments, when startup_with_shell is
	false we construct the inferior argument string differently than when
	startup_with_shell is true; when true we apply some escaping to
	special shell character, when false we don't.

	This commit simplifies construct_inferior_arguments by removing the
	!startup_with_shell case, and instead we now apply escaping in all
	cases.  This is fine because, thanks to the above commit the escaping
	will be correctly removed again when we call into nat/fork-inferior.c.

	We should think of construct_inferior_arguments and
	nat/fork-inferior.c as needing to cooperate in order for argument
	handling to work correctly.

	construct_inferior_arguments converts a list of separate arguments
	into a single string, and nat/fork-inferior.c splits that single
	string back into a list of arguments.  It is critical that, if
	nat/fork-inferior.c is expecting to remove a "layer" of escapes, then
	construct_inferior_arguments must add that expected "layer",
	otherwise, we end up stripping more escapes than expected.

	The great thing (I think) about the new configuration, is that GDB no
	longer cares about startup_with_shell at the point the arguments are
	being setup.  We only care about startup_with_shell at the point that
	the inferior is started.  This means that a user can set the inferior
	arguments, and then change the startup-with-shell setting, and GDB
	will do what they expect.

	Under the previous system, where construct_inferior_arguments changed
	its behaviour based on startup_with_shell, the user had to change the
	setting, and then set the arguments, otherwise, GDB might not do what
	they expect.

	There is one slight issue with this commit though, which will be
	addressed by the next commit.

	For GDB's native targets construct_inferior_arguments is reached via
	two code paths; first when GDB starts and we combine arguments from
	the command line, and second when the Python API is used to set the
	arguments from a sequence.  It's the command line argument handling
	which we are interested in.

	Consider this:

	  $ gdb --args /tmp/exec '$FOO'
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "\$FOO".

	Notice that the argument has become \$FOO, the '$' is now quoted.

	This is because, by quoting the argument in the shell command that
	started GDB, GDB was passed a literal $FOO with no quotes.  In order
	to ensure that the inferior sees this same value, GDB added the extra
	escape character.  When GDB starts with a shell we pass \$FOO, which
	results in the inferior seeing a literal $FOO.

	But what if the user _actually_ wanted to have the shell GDB uses to
	start the inferior expand $FOO?  Well, it appears this can't be done
	from the command line, but from the GDB prompt we can just do:

	  (gdb) set args $FOO
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "$FOO".

	And now the inferior will see the shell expanded version of $FOO.

	It might seem like we cannot achieve the same result from the GDB
	command line, however, it is possible with this trick:

	  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "$FOO".
	  (gdb) show startup-with-shell
	  Use of shell to start subprocesses is off.

	And now the $FOO is not escaped, but GDB is no longer using a shell to
	start the inferior, however, we can extend our command line like this:

	  $ gdb -eiex 'set startup-with-shell off' \
	        -ex 'set startup-with-shell on' \
		--args /tmp/exec '$FOO'
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "$FOO".
	  (gdb) show startup-with-shell
	  Use of shell to start subprocesses is on.

	Use an early-initialisation option to disable startup-with-shell, this
	is done before command line argument processing, then a normal
	initialisation option turns startup-with-shell back on after GDB has
	processed the command line arguments!

	Is this useful?  Yes, absolutely.  Is this a good user experience?
	Absolutely not.  And I plan to add a new command line option to
	GDB (and gdbserver) that will allow users to achieve the same
	result (this trick doesn't work in gdbserver as there's no
	early-initialisation there) without having to toggle the
	startup-with-shell option.  The new option can be found in the series
	here:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	The problem is that, that series is pretty long, and getting it
	reviewed is just not possible.  So instead I'm posting the individual
	patches in smaller blocks, to make reviews easier.

	So, what's the problem?  Well, by removing the !startup_with_shell
	code path from GDB, there is no longer a construct_inferior_arguments
	code path that doesn't quote inferior arguments, and so there's no
	longer a way, from the command line, to set an unquoted '$FOO' as an
	inferior argument.  Obviously, this can still be done from GDB's CLI
	prompt.

	The trick above is completely untested, so this regression isn't going
	to show up in the testsuite.

	And the breakage is only temporary.  In the next commit I'll add a fix
	which restores the above trick.

	Of course, I hope that this fix will itself, only be temporary.  Once
	the new command line options that I mentioned above are added, then
	the fix I add in the next commit can be removed, and user should start
	using the new command line option.

	After this commit a whole set of tests that were added as xfail in the
	above commit are now passing.

	A change similar to this one can be found in this series:

	  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

	which I reviewed before writing this patch.  I don't think there's any
	one patch in that series that exactly corresponds with this patch
	though, so I've listed the author of the original series as co-author
	on this patch.

	Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-18  Tom Tromey  <tromey@adacore.com>

	Preserve a local variable in a gdb test
	I found another Ada test where LLVM optimizes away an unused local
	variable.  This patch fixes this problem -- but note the test now
	fails for a different (currently expected) reason.

2025-03-18  Nick Clifton  <nickc@redhat.com>

	Updated translations for BFD and BINUTILS sub-directories

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in regcache.c
	This changes a couple spots in regcache.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in tui-io.c
	This changes tui.c to use gdb::unordered_map.  ui_file_style::color is
	changed a little as well; operator< is no longer needed, but a simple
	hash function is added.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set and map in cp-namespace.c
	This changes cp-namespace.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in xml-tdesc.c
	This changes xml-tdesc.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set and map in unit tests
	This changes some unit test code to use gdb:unordered_set and
	gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in target.c
	This changes corelow.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in ravenscar.c
	This changes ravenscar.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set and map in Python layer
	This changes a couple of files in the Python layer to use
	gdb:unordered_set and gdb::unordered_map.  Another use exists but I
	think it is being handled by Jan's series.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set in linux-procfs.c
	This changes linux-procfs.c to use gdb:unordered_set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in linux-nat.c
	This changes one spot in linux-nat.c to use gdb::unordered_map.
	(There are still other spots that could be converted.)

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map for complaints
	This changes the complaints code to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in stap-probe.c
	This changes stap-probe.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in inferior.h
	This changes inferior.h to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in ada-exp.y
	This changes ada-exp.y to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set in symtab.c
	This changes symtab.c to use gdb:unordered_set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in gdb_bfd.c
	This changes gdb_bfd.c to use gdb:unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered map in dictionary.c
	This changes dictionary.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set in breakpoint.c
	This changes breakpoint.c to use gdb:unordered_set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use gdb unordered set and map in corelow.c
	This changes corelow.c to use gdb:unordered_set and
	gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-18  Tom Tromey  <tom@tromey.com>

	Use scoped_fd in linux-nat.c:proc_mem_file
	This changes linux-nat.c:proc_mem_file to use a scoped_fd and fixes up
	the users.  Regression tested on x86-64 Fedora 40.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-03-18  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use SYSCALL_MAP_RENAME for aarch64 and loongarch
	There are currently two functions using macros SYSCALL_MAP and
	UNSUPPORTED_SYSCALL_MAP: aarch64_canonicalize_syscall, and
	loongarch_canonicalize_syscall.

	Here [1] I propose to do the same in i386_canonicalize_syscall, using one
	additional macro: SYSCALL_MAP_RENAME.

	Add the same macro in aarch64_canonicalize_syscall and
	loongarch_canonicalize_syscall, and use it to map aarch64_sys_mmap and
	loongarch_sys_mmap to gdb_sys_mmap2.

	While we're at it:
	- reformat the macro definitions to be more readable,
	- add missing macro undefs in aarch64_canonicalize_syscall, and
	- fix indentation in aarch64_canonicalize_syscall.

	No functional changes.

	Tested by rebuilding on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216230.html

2025-03-18  Jerry Zhang Jian  <jerry.zhangjian@sifive.com>

	RISC-V: Support pointer masking extension 1.0
	- Adding Ssnpm, Smnpm, Smmpm, Sspm, and Supm
	- No new CSR added
	- Pointer masking only applies to RV64
	- Ref: https://github.com/riscv/riscv-j-extension/releases/download/pointer-masking-ratified/pointer-masking-ratified.pdf

2025-03-18  Nelson Chu  <nelson@rivosinc.com>

	gas/NEW: Updated news related to mapping symbol and extensions for risc-v

2025-03-18  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add extension XTheadVdot for T-Head VECTOR vendor extension [1]
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds the additional extension "XTheadVdot" based on the
	"V" extension, and it provides four 8-bit multiply and add with
	32-bit instructions for the "v" extension. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([2]).

	Co-Authored-By: Lifang Xia <lifang_xia@linux.alibaba.com>

	[1] https://github.com/XUANTIE-RV/thead-extension-spec/tree/master/xtheadvdot
	[2] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add support
		for "XTheadVdot" extension.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* doc/c-riscv.texi: Likewise.
		* testsuite/gas/riscv/march-help.l: Likewise.
		* testsuite/gas/riscv/x-thead-vdot.d: New test.
		* testsuite/gas/riscv/x-thead-vdot.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VMAQA_VV): New.
		* opcode/riscv.h (enum riscv_insn_class): Add insn class for
		XTheadVdot.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2025-03-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Avoid parsing arch string repeatedly for dis-assembler
	Since we now always generate $x+isa for now, these would increase the
	dis-assemble time by parsing the same architecture string repeatedly.  We
	already have `arch_str' field into `subset_list' to record the current
	architecture stirng, but it's only useful for assembler, since dis-assembler
	and linker don't need it before.  Now for dis-assembler, we just need to
	update the `arch_str' after parsing the architecture stirng, and then avoid
	parsing repeatedly if the strings are the same.

	RISC-V: Free the returned string of riscv_arch_str if we call it multiple times
	The string returned from riscv_arch_str is allocated by xmalloc, so once we
	called it multiple times, we should keep the newest one for the output elf
	architecture attribute, but free the remaining unused strings.

	RISC-V: Fixed riscv_update_subset1 returning wrong boolean value
	The riscv_update_subset1 returning wrong boolean value if the
	riscv_parse_check_conflicts isn't called, though the current return value
	doesn't really useful.

2025-03-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unused cooked_index::cooked_index parameter
	Following the previous patch, this parameter is now unused.  Remove it.

	Change-Id: I7e96a3ba61ad9a0d6b64f9129aeeb9a8f3da22a7
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: add some -Wunused-* warning flags
	Add a few -Wunused-* diagnostic flags that look useful.  Some are known
	to gcc, some to clang, some to both.  Fix the fallouts.

	-Wunused-const-variable=1 is understood by gcc, but not clang.
	-Wunused-const-variable would be undertsood by both, but for gcc at
	least it would flag the unused const variables in headers.  This doesn't
	make sense to me, because as soon as one source file includes a header
	but doesn't use a const variable defined in that header, it's an error.
	With `=1`, gcc only warns about unused const variable in the main source
	file.  It's not a big deal that clang doesn't understand it though: any
	instance of that problem will be flagged by any gcc build.

	Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: re-format and sort warning flags
	Put them one per line and sort alphabetically.

	Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Andrew Burgess  <aburgess@redhat.com>

	gdb-add-index: add --help and --version options
	Update the gdb-add-index script to offer --help and --version options.

	The script currently accepts the argument '-dwarf-5' with a single
	leading '-'.  As two '--' is more common for long options, the
	preferred argument form is now '--dwarf-5', the docs have been
	updated, and the new help text uses this form.

	For backward compatibility, the old '-dwarf-5' form is still
	accepted.

	The new arguments are '--help' or '-h', but I also accept '-help' for
	consistency with '-dwarf-5'.  And likewise for the version argument.

	Handling of the gdb-add-index script is done basically the same as for
	gcore and gstack; we use config.status to create a .in file within the
	build directory, which is then processed by the Makefile to create the
	final script.

	The difference with gdb-add-index is that I left the original script
	as gdb/contrib/gdb-add-index.sh rather than renaming it to something
	like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are
	handled (though they are not in the contrib directory).

	The reason for this is that the contrib/cc-with-tweaks.sh script looks
	for gdb-add-index.sh within the gdb/contrib/ source directory.

	As the only reason we process gdb-add-index.sh into the build
	directory is to support the PKGVERSION and VERSION variables, allowing
	cc-with-tweaks to continue using the unprocessed version seems
	harmless, and avoids having to change cc-with-tweaks.sh at all.

	I tested that I can still run tests using the cc-with-gdb-index target
	board, and that the installed gdb-add-index script correctly shows a
	version number when asked.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: make cli_styling static within cli/cli-style.c
	The cli_styling variable is controlled by 'set style enabled on|off'
	user setting, and is currently globally visible.

	In a couple of places we access this variable directly, though in
	ui-file.c the accesses are all performed through term_cli_styling(),
	which is a function that wraps checking cli_styling along with a check
	that GDB's terminal supports styling.

	In a future commit, I'd plan to add a new parameter to gdb.execute()
	which will allow styling to be temporarily suppressed.  In an earlier
	proposal, I made gdb.execute() disable styling by changing the value
	of cli_styling, however, this approach has a problem.

	If gdb.execute() is used to run 'show style enabled', the changing
	cli_styling will change what is printed.  Similarly, if gdb.execute()
	is used to execute 'set style enabled on|off' then having
	gdb.execute() save and restore the value of cli_styling will undo the
	adjustment from 'set style enabled ...'.

	So what I plan to do in the future, is add a new control flag which
	can be used to temporarily disable styling.

	To make this new control variable easier to add, lets force everyone
	to call term_cli_styling() to check if styling is enabled or not.  To
	force everyone to use term_cli_styling() this commit makes cli_styling
	static within gdb/cli/cli-style.c.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix typo in NEWS file
	The following commit introduced a typo to the NEW file:

	  commit d21f28a067e94e0ab6548d97f650c14be76bfbde
	  Date:   Sat Mar 15 12:03:50 2025 +0000

	      gdb/python: remove unused argument from builtin_disassemble

	this commit fixes it.

	I've also reworded the NEWS entry a little.  Simon pointed out in
	review that the unused argument was also documented in Python's help()
	output, which I hadn't mentioned in the NEWS entry.  I've updated the
	NEWS entry to just highlight that the now removed argument was never
	mentioned in the manual, I think that's all that really matters.

2025-03-17  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: use gdb::unordered_set for seen_names
	Direct replacement of an htab with a gdb::unordered_set.

	Using a large test program, I see a small but consistent performance
	improvement.  The "file" command time goes on average from 7.88 to 7.73
	seconds (~2%).  To give a rough estimate of the scale of the test
	program, the 8 seen_names hash tables (one for each worker thread) had
	between 173846 and 866961 entries.

	Change-Id: I0157cbd04bb55338bb1fcefd2690aeef52fe3afe
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-17  Lucy Kingsbury  <lucymkingsbury@gmail.com>

	Fix Guile pretty printer display hints
	All 3 valid Guile pretty printer display hints are treated as the
	value "string". As a result, if a printer specifies "array" or
	"map", the output is instead formatted as a string.

	This humble patch corrects the issue.

2025-03-17  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: add gnu property section in nto-stack-note*
	A GNU property section is now always generated when `-z stack-size` is
	passed. This was probably introduced by GNU Property refactoring
	within elfxx-aarch64.c.

2025-03-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-15  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove unused argument from builtin_disassemble
	This commit:

	  commit 15e15b2d9cd3b1db68f99cd3b047352142ddfd1c
	  Date:   Fri Sep 17 18:12:34 2021 +0100

	      gdb/python: implement the print_insn extension language hook

	added the gdb.disassembler.builtin_disassemble Python API function.
	By mistake, the implementation accepted two arguments, the second
	being a "memory_source".

	However, this second argument was never used, it was left over from an
	earlier proposed version of the API.

	Luckily, the only place the unused argument was documented was in the
	NEWS file and in the output of `help(gdb.builtin_disassemble)`, and
	neither of these locations really describe what the argument was, or
	how it would be used.  The manual only describes the first (actually
	used) argument, so I think we are safe enough to delete the unused
	argument.

	This allows some additional cleanup, with the store for the argument
	also being deleted.

	As the NEWS file did originally document the second argument, I have
	added a NEWS entry to explain the argument has now been removed.

	This could potentially break users code if they somehow decided to
	pass a second argument, however, fixing things is as simple as
	removing the second (unused) argument.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-15  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: handle non-utf-8 character from gdb.execute()
	I noticed that it was not possible to return a string containing non
	utf-8 characters using gdb.execute().  For example, using the binary
	from the gdb.python/py-source-styling.exp test:

	  (gdb) file ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling
	  Reading symbols from ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling...
	  (gdb) set style enabled off
	  (gdb) list 26
	  21	  int some_variable = 1234;
	  22
	  23	  /* The following line contains a character that is non-utf-8.  This is a
	  24	     critical part of the test as Python 3 can't convert this into a string
	  25	     using its default mechanism.  */
	  26	  char c[] = "�";		/* List this line.  */
	  27
	  28	  return 0;
	  29	}
	  (gdb) python print(gdb.execute('list 26', to_string=True))
	  Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte
	  Error occurred in Python: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte

	It is necessary to disable styling before the initial 'list 26',
	otherwise the source will be passed through GNU source highlight, and
	GNU source highlight seems to be smart enough to figure out the
	character encoding, and convert it to UTF-8.  This conversion is then
	cached in the source cache, and the later Python gdb.execute call will
	get back a pure UTF-8 string.

	If source styling is disabled, then GDB caches the string without the
	conversion to UTF-8, now the gdb.execute call gets back the string
	with a non-UTF-8 character within it, and Python throws an error
	during its attempt to create a string object.

	I'm not, at this point, proposing a solution that tries to guess the
	source file encoding, though I guess such a thing could be done.
	Instead, I think we should make use of the host_charset(), as set by
	the user with 'set host-charset ....' during the creation of the
	Python string.

	To do this, in execute_gdb_command, we should switch from
	PyUnicode_FromString, which requires the input be a UTF-8 string, to
	using PyUnicode_Decode, which allows GDB to specify the string
	encoding.  We will use host_charset().

	With this done, it is now possible to list the file contents using
	gdb.execute(), with the contents passing through a string:

	  (gdb) set host-charset ISO-8859-1
	  (gdb) python print(gdb.execute('list 26', to_string=True), end='')
	  21	  int some_variable = 1234;
	  22
	  23	  /* The following line contains a character that is non-utf-8.  This is a
	  24	     critical part of the test as Python 3 can't convert this into a string
	  25	     using its default mechanism.  */
	  26	  char c[] = "À";		/* List this line.  */
	  27
	  28	  return 0;
	  29	}
	  (gdb)

	There are already plenty of other places in GDB's Python code where we
	use PyUnicode_Decode to create a string from something that might
	contain user generated content, so I believe this is the correct
	approach.

2025-03-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-14  H.J. Lu  <hjl.tools@gmail.com>

	elf: Clear the SEC_ALLOC bit for NOLOAD note sections
	When generating an ELF output file, if a note section is marked as
	NOLOAD, clear the SEC_ALLOC bit so that it won't be treated as an
	SHF_ALLOC section, like a .bss style section.

		PR ld/32787
		* ld.texi: Update NOLOAD for ELF output files.
		* ldlang.c (lang_add_section): Clear the SEC_ALLOC bit for NOLOAD
		note sections for ELF output files.
		* testsuite/ld-elf/pr32787.d: New file.
		* testsuite/ld-elf/pr32787.t: Likewise.

2025-03-14  Tom Tromey  <tom@tromey.com>

	Remove std::hash specialization
	C++11 initially omitted specialization of std::hash for enumeration
	types, but this was rectified in LWG issue 2148.  This patch removes a
	redundant specialization.  Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: assume that no dwarf2_cu exist when calling load_full_comp_unit
	After staring at the code, I got convinced that it was not possible for
	load_full_comp_unit to be called while a dwarf2_cu object exists in
	per_objfile for this_cu.  If you follow all callers of
	load_full_comp_unit, you can see that all calls to load_full_comp_unit
	(except one, see below) are gated one way or another by the fact that:

	  per_objfile->get_cu (per_cu) == nullptr

	Some calls are gated by maybe_queue_comp_unit returning true.  If it
	returns true, then necessarily the dwarf2_cu is unset for that per_cu.

	The spot that didn't seem to check for whether the dwarf2_cu is already
	set before calling load_full_comp_unit is dw2_do_instantiate_symtab.  It
	didn't trigger when running the testsuite, but I could imagine a made up
	case where the dwarf2_cu would already be set because we looked up a DIE
	reference to it (follow_die_ref) for whatever reason.  Then, something
	would cause the symtab for that CU to be expanded and
	dw2_do_instantiate_symtab to be called.

	I added a check in that function, because it seemed prudent to do so.
	All other load_cu calls are gated by this check, so it makes this call
	look just like the others.

	Finally, because all call sites that use cutu_reader::release_cu pass
	nullptr for `existing_cu` (and therefore cutu_reader creates a new
	dwarf2_cu), we know that cutu_reader::release_cu will always return a
	non-nullptr value.  Add an assert in it and remove checks in
	load_full_comp_unit and read_signatured_type.

	Change-Id: I496be34bd4bf7edfa38d5135cf4bc4ccd960abe2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove existing_cu parameter of load_full_comp_unit
	Following the previous patch, all callers now pass the same thing:

	    per_objfile->get_cu (this_cu)

	Remove that parameter and to the call in the function itself.

	Change-Id: Iafd36b058d7b95efae518bb65035c6a03728b018
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: assume that source_cu->dies is always set in follow_die_offset
	After staring at the code for a while, I got convinced that it's not
	possible for cu->dies to be nullptr in follow_die_offset.  It might be a
	leftover from the psymtab days.

	In most cases, we see that the dwarf2_cu passedas `*ref_cu` has been
	obtained by doing:

	    per_objfile->get_cu (per_cu);

	The only way for a dwarf2_cu to end up in the per_objfile like this is
	through load_full_comp_unit or read_signatured_type.  Both of these
	functions call `reader.read_all_dies ()` (which loads the DIEs in memory
	and assigns dwarf2_cu::dies) before transferring the newly created
	dwarf2_cu to the per_objfile.  So any dwarf2_cu obtained through

	   per_objfile->get_cu (per_cu)

	... will have its DIEs set.

	The only case today I'm aware of of a dwarf2_cu without DIEs is in the
	cooked indexer.  It creates a cutu_reader, but does not call
	read_all_dies.  Instead, it gets the info_ptr from the cutu_reader and
	reads the DIEs from the section buffer directly, on its own.  But this
	is an entirely different code path that doesn't assign dwarf2_cu
	objects to per_objfile.

	So, remove the code path in follow_die_offset that tests for
	`source_cu->dies == NULL`.  I added an assert at the top of the function
	to verify that `source_cu->dies` is always non-nullptr, as a way to
	test my hypothesis.  We could probably get rid of it, but I left it
	there because it doesn't cost much to have it.

	Change-Id: I97f269f092128800850aa5e64eda7032c2edec60
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename local variables in follow_die_offset
	Rename some local variables to better make the distinction between the
	source and target CUs.

	Change-Id: I8b43fac91b8a6f1ca6fd1972846fd6bf28608fe3
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary per_objfile parameter in cooked_indexer::ensure_cu_exists
	The per_objfile object can be obtained from the cutu_reader.  This is
	actually how both callers get it in order to pass it as argument.

	Change-Id: Iac134ded247d841f80ab5ca55dd9055b556410c3
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: remove some _1 suffixes
	These methods don't have (or no longer have) a counterpart without the
	_1 suffix, so remove the suffix.

	Change-Id: Ifdfe4fb3b6b09c6bb9e30c27acf9f9ecbcb207f2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove cutu_reader::keep, add cutu_reader::release_cu
	This is a bit subjective, but I often struggle to understand what
	cutu_reader::keep is meant to do (keep what, where).  Perhaps it's just
	a question of bad naming, but I think it's a bit confusing for
	cutu_reader to transfer the ownership of the dwarf2_cu to the
	per_objfile directly.

	Add the cutu::release_cu method and make the caller of cutu_reader
	transfer the ownership to the per_objfile object.

	Right now, it is theoretically possible for release_cu to return
	nullptr, so I made callers check the return value.  A patch later in
	this series will change release_cu to ensure it always return
	non-nullptr, so those callers will get simplified.

	Change-Id: I3103ff894d1654a95c9d69001073c218501c988a
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: change cutu_reader::read_die_and_siblings to cutu_reader::read_all_dies
	After construction of a cutu_reader, only the top-level DIE has been
	read in memory.  If the caller wants to access the full DIE tree, it
	does:

	    reader.top_level_die ()->child
	      = reader.read_die_and_siblings (reader.top_level_die ());

	I don't really like this poking into cutu_reader's data structures from
	the outside, I would prefer if that work was done by cutu_reader.
	Rename the read_die_and_siblings method to read_all_dies, and do that
	work inside cutu_reader.

	I also moved these operations inside the read_all_dies method:

	    gdb_assert (cu->die_hash.empty ());
	    cu->die_hash.reserve (cu->header.get_length_without_initial () / 12);

	    ...

	    cu->dies = reader.top_level_die ();

	The rationale for this is that read_all_dies (and the functions it
	calls) is responsible for filling the die_hash set.  So I think it makes
	sense for it to do the reserve.

	It is also cutu_reader's job, currently, to create and fill the fields
	of dwarf2_cu.  So I think it makes sense for it to set cu->dies, after
	having read the DIEs in memory.

	Change-Id: I088c2e0b367db7d1f67e8c9e2d5b0d61165292fc
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: access m_info_ptr directly instead of passing info_ptr around
	The few methods of cutu_reader that read DIEs into memory generally
	receive an info_ptr that says where to start reading and return another
	one (either by return value or parameter) indicating where the caller
	should continue reading.

	We can avoid all this passing around by having these methods access
	m_info_ptr directly.  This allows changing some methods that read DIEs
	to return `die_info *`, instead of returning it by parameter, which just
	makes the code simpler to read, I think.

	The only method that meaningfully reads and writes m_info_ptr (except
	the places that initially set it up) is read_full_die_1.  It reads and
	increments m_info_ptr once to read the abbrev and once again to read
	each attribute.  Other methods use it for logging.

	The methods cutu_reader::read_attribute and
	cutu_reader::read_attribute_value do not touch m_info_ptr directly,
	because they are used in cooked-indexer.c, which appears to read some
	things in a non-linear fashion, unlike cutu_reader's DIE-reading
	methods.  The cooked indexer calls cutu_reader::info_ptr to get the
	m_info_ptr value just after the top-level DIE, and then it does its own
	attribute reading after that.

	Change-Id: I251f63d13d453a2827b21349760da033171880e2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: factor out to cutu_reader::skip_one_attribute method
	I was reading cutu_reader::skip_one_die, and thought that the code to
	skip one attribute made it quite difficult to read.  Factor this code
	out to a new method, to get it out of the way.

	As a bonus, it transforms one goto in a recursion call, which is also
	easier to follow.  Unfortunately, I have no idea how to test
	DW_FORM_indirect, as it doesn't seem to appear anywhere in the
	testsuite, and I don't think that compilers often emit that.

	Change-Id: I2257b3e594aafb7c7da52ddd55baa651cefb802f
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove pretend_language parameter from load_full_{comp,type}_unit
	I noticed that load_full_comp_unit and load_full_type_unit didn't use
	their pretend_language parameter.  Remove them, and then remove more
	things that were needed to get the language value to that point,
	including the dwarf2_queue_item field.

	Change-Id: Ie8cb21c54ae49da065a1b0a20bf18ccb93961d1a
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-14  Richard Allen  <rsaxvc@gmail.com>

	gprof: only process line numbers for intersection of vmas and histograms
	Some programs like RTOS firmware may have a large number of symbols.
	The profile information in the profile data file includes histogram
	records, which capture low PC and high PC of program execution.  If all
	histogram records come in the profile data file before any call-graph
	records and basic-block records, we can look up only the line numbers
	within low PC and high PC in histogram records, which reduces processing
	time for such a firmware from ~2 minutes to ~2 seconds.

	Add symbol table access function, get_symtab, get_symtab_direct and
	set_symtab to delay loading the symbol table until its first use.

		* aarch64.c (aarch64_find_call): Call get_symtab to get the
		symbol table pointer
		* alpha.c (alpha_find_call): Likewise.
		* basic_blocks.c (bb_read_rec): Likewise.
		(bb_write_blocks): Likewise.
		(print_exec_counts): Likewise.
		(print_annotated_source): Likewise.
		* call_graph.c (cg_tally): Likewise.
		(cg_write_arcs): Likewise.
		* cg_arcs.c (cycle_link): Likewise.
		(propagate_flags): Likewise.
		(cg_assemble): Likewise.
		* cg_print.c (cg_print): Likewise.
		(cg_print_index): Likewise.
		(cg_print_function_ordering): Likewise.
		* corefile.c: Include "gmon_io.h".
		(core_create_syms_from): Call get_symtab_direct to get the
		symbol table pointer.
		(core_create_function_syms): Likewise.
		(core_create_line_syms): Likewise.  If all histogram records
		come in the profile data file before any call-graph records and
		basic-block records, we can look up only the line numbers within
		low PC and high PC in histogram records.
		* gmon_io.c (gmon_histograms_first): New.
		(gmon_out_read): Set gmon_histograms_first to true if all
		histogram records come first.
		(gmon_out_write): Call get_symtab to get the symbol table
		pointer.
		* hist.c (scale_and_align_entries): Likewise.
		(hist_assign_samples_1): Likewise.
		(hist_print): Likewise.
		* i386.c (i386_find_call): Likewise.
		* mips.c (mips_find_call): Likewise.
		* sparc.c (sparc_find_call): Likewise.
		* sym_ids.c (sym_id_parse): Likewise.
		* vax.c (vax_find_call): Likewise.
		* gmon_io.h (gmon_histograms_first): New.
		* gprof.c (man): Don't create profile info.
		(symtab_init): New.
		* gprof.h (symtab_init): New.
		* symtab.c (symtab): Changed to static.
		(get_symtab_direct): New.
		(get_symtab): Likewise.
		(set_symtab): Likewise.
		* symtab.h (symtab): Removed.
		(get_symtab_direct): New.
		(get_symtab): Likewise.
		(set_symtab): Likewise.

	Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>

2025-03-14  Jan Beulich  <jbeulich@suse.com>

	gas: permit wider-than-byte operands for .cfi_escape
	Some DW_CFA_* and DW_OP_* take wider than byte, but non-LEB128 operands.
	Having to hand-encode such when needing to resort to .cfi_escape isn't
	very helpful.

	gas: permit LEB128 operands for .cfi_escape
	Many DW_CFA_* and DW_OP_* take LEB128 operands. Having to hand-encode
	such when needing to resort to .cfi_escape isn't very helpful.

	gas: make NO_LISTING work again
	Presumably since no target enables this and there's also no configure
	control, builds with NO_LISTING defined didn't really work anymore.
	Convert fallback functions to macros and add #ifndef in a few places.
	(Behavior is different for affected command line options vs directives:
	The former are rejected as unrecognized, while the latter are silently
	ignored. I think that's fair enough.)

	gas: include .cfi_* generated data in listing
	These are data generating directives not overly different from e.g.
	.byte and .long. Whatever (directly) results from should also be
	represented in the listing, if one was requested. It's just that the
	output data is generated much later than the parsing of the directive
	arguments.

2025-03-14  Jan Beulich  <jbeulich@suse.com>

	gas: deal with the need for relocations from .cfi_{escape,fde_data}
	Ignoring return values often isn't a good idea. The Sparc assembler in
	particular would report an internal error if an expression with
	relocation specifier is used with .cfi_escape, when the same works fine
	with .byte. Propagate the relocation indicator up from
	do_parse_cons_expression(), and eventually into emit_expr_with_reloc().

	dot_cfi_fde_data(), only retaining the expression's X_add_number, would
	require further work. Simply report the lack of support there. While
	there, also check that what we were dealt is actually a constant.

2025-03-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix undefined variable in gdb.ada/scalar_storage.exp
	Commit:

	  commit be382ece165eefa3e65f61bfb6b2aa2ee95dd6b4
	  Date:   Wed Feb 12 09:35:26 2025 -0700

	      Check for compiler support in scalar_storage.exp

	Introduced an undefined variable use in gdb.ada/scalar_storage.exp,
	fixed by this commit.

2025-03-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: keep going even if reading macro information fails
	On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:

	    $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"

	I think I stumble on this bug [1], preventing the test from doing
	anything that requires expanding the compilation unit:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
	    Reading symbols from testsuite/outputs/gdb.base/style/style...
	    (gdb) p main
	    DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
	    (gdb)

	The error is thrown here:

	    #0  0x00007ffff693f0a1 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
	    #1  0x0000555569ce6852 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:203
	    #2  0x0000555569ce690f in throw_verror (error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:211
	    #3  0x000055556879c0cb in verror (string=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", args=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdb/utils.c:193
	    #4  0x0000555569cfa88d in error (fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:45
	    #5  0x000055556667dbff in dwarf2_section_info::read_string (this=0x61b000042a08, objfile=0x616000055e80, str_offset=262811, form_name=0x555562886b40 "DW_FORM_strp") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/section.c:211
	    #6  0x00005555662486b7 in dwarf_decode_macro_bytes (per_objfile=0x616000056180, builder=0x614000006040, abfd=0x6120000f4b40, mac_ptr=0x60300004f5be "", mac_end=0x60300004f5bb "\002\004", current_file=0x62100007ad70, lh=0x60f000028bd0, section=0x61700008ba78, section_is_gnu=1, section_is_dwz=0, offset_size=4, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, include_hash=..., cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:511
	    #7  0x000055556624af0e in dwarf_decode_macros (per_objfile=0x616000056180, builder=0x614000006040, section=0x61700008ba78, lh=0x60f000028bd0, offset_size=4, offset=0, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, section_is_gnu=1, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:934
	    #8  0x000055556642cb82 in dwarf_decode_macros (cu=0x61700008b600, offset=0, section_is_gnu=1) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:19435
	    #9  0x000055556639bd12 in read_file_scope (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6366
	    #10 0x0000555566392d99 in process_die (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5310
	    #11 0x0000555566390d72 in process_full_comp_unit (cu=0x61700008b600, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5075

	The exception is then only caught at the event-loop level
	(start_event_loop), causing the whole debug info reading process to be
	aborted.  I think it's a little harsh, considering that a lot of things
	could work even if we failed to read macro information.

	Catch the exception inside read_file_scope, print the exception, and
	carry on.  We could go even more fine-grained: if reading the string for
	one macro definition fails, we could continue reading the macro
	information.  Perhaps it's just that one macro definition that is
	broken.  However, I don't need this level of granularity, so I haven't
	attempted this.  Also, my experience is that macro reading fails when
	the compiler or linker has a bug, in which case pretty much everything
	is messed up.

	With this patch, it now looks like:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
	    Reading symbols from testsuite/outputs/gdb.base/style/style...
	    (gdb) p main
	    While reading section .debug_macro.dwo: DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
	    $1 = {int (int, char **)} 0x684 <main>
	    (gdb)

	In the test I am investigating (gdb.base/style.exp with the fission
	board), it allows more tests to run:

	    -# of expected passes           107
	    -# of unexpected failures       17
	    +# of expected passes           448
	    +# of unexpected failures       19

	Of course, we still see the error about the macro information, and some
	macro-related tests still fail (those would be kfailed ideally), but
	many tests that are not macro-dependent now pass.

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

	Change-Id: I0bdb01f153eff23c63c96ce3f41114bb027e5796
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: fail less catastrophically in gdb.base/style.exp
	On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:

	    $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"

	I think I stumble on this bug [1], preventing to do the
	disassembling that the test needs:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
	    Reading symbols from testsuite/outputs/gdb.base/style/style...
	    (gdb) x/1i *main
	    DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
	    (gdb)

	The regexp in get_single_disassembled_insn fails to match, the insn
	variable doesn't get set, and we get one of those unreadable TCL stack
	traces:

	    ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/style.exp.
	    ERROR: tcl error code TCL READ VARNAME
	    ERROR: can't read "insn": no such variable
	        while executing
	    "return $insn"
	        (procedure "get_single_disassembled_insn" line 4)
	        invoked from within
	    "get_single_disassembled_insn"
	        ("uplevel" body line 18)
	        invoked from within
	    "uplevel 1 $body"
	        invoked from within
	    ...

	Check the return value of the regexp call, return an empty string on
	failure.  Log a failure, so that we have a trace that something went
	wrong, in case the tests done by the caller happen to pass by change.

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

	Change-Id: I5123d4cc0034da85a093a8531a22e972c10d94ca
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-13  Andrew Burgess  <aburgess@redhat.com>

	gcore/doc: fix mistake in the gcore man page
	The gcore man page says that the default prefix for a generated core
	file will be 'gcore', i.e. we'll create files like 'gcore.pid'.  In
	reality the default is 'core'.

	As far as I can tell, the default has been 'core' for years, and the
	docs used to say that the default was 'core', but the docs were
	changed by mistake in commit:

	  commit 129eb0f1f16dc7a49799a024a7bcb109d954a1e7
	  Date:   Fri Jul 27 00:52:23 2018 -0400

	      Improve gcore manpage and clarify "-o" option

	So, lets bring the docs back inline with the code.

	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-03-13  Andrew Burgess  <aburgess@redhat.com>

	gcore: add -h|--help options, and improve help/usage message output
	Like the previous commit, this copies a lot from:

	  commit fb2ded33c1e519659743047ed7817166545b6d91
	  Date:   Fri Dec 20 12:46:11 2024 -0800

	      Add gstack script

	And adds -h | --help options to the gcore script, and smartens up the
	help and usage output messages.

	The usage text is now split over several lines (as it was getting a
	bit long), and an input error suggests using `--help` instead of
	printing the full usage string.

	These changes bring gcore and gstack closer in behaviour.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-03-13  Andrew Burgess  <aburgess@redhat.com>

	gcore: add -v or --version option to show version number
	Based on the work in this commit:

	  commit fb2ded33c1e519659743047ed7817166545b6d91
	  Date:   Fri Dec 20 12:46:11 2024 -0800

	      Add gstack script

	This commit adds a '-v' or '--version' option to the existing gcore
	script.  This new option causes the script to print its version
	number, and then exit.

	I needed to adjust the getopts handling a little in order to support
	the long form '--version' argument, but as this makes gcore more
	consistent with gstack, then this seems like a good thing.

	The usage message is now getting a little long.  Don't worry, I plan
	to clean that up in the next commit.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/record] Fix out-of-bounds write in aarch64_record_asimd_load_store
	After compiling gdb with -fstack-protector-all, and running test-case
	gdb.reverse/getrandom.exp on aarch64-linux, we run into
	"Stack smashing detected" in function aarch64_record_asimd_load_store.

	This is reported in PR record/32784.

	This happens due to an out-of-bounds write to local array record_buf_mem:
	...
	  uint64_t record_buf_mem[24];
	...
	when recording insn:
	...
	B+>0xfffff7ff4d10  st1     {v0.16b-v3.16b}, [x0]
	...

	We can fix this by increasing the array size to 128, but rather than again
	hardcoding a size, reimplement record_buf_mem as std::vector.

	Tested on aarch64-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32784

2025-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/record] Support recording syscall accept4
	While reviewing the enum gdb_syscall entries with values >= 500, I noticed
	that gdb_sys_accept exists, but gdb_sys_accept4 doesn't, while recording
	support is essentially the same, given that the difference in interface is
	only an extra int parameter:
	...
	int accept (int sockfd, struct sockaddr *addr, socklen_t *addrlen);
	int accept4 (int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
	...

	Fix this by:
	- adding gdb_sys_accept4,
	- supporting it in record_linux_system_call alongside gdb_sys_accept, and
	- mapping to gdb_sys_accept4 in various syscall canonicalization functions.

	The usual thing to do before the rewrite of i386_canonicalize_syscall would
	have been to use the value from arch/x86/entry/syscalls/syscall_32.tbl:
	...
	  gdb_sys_accept4 = 364,
	...
	but that's no longer necessary, so instead we use some >= 500 value:
	...
	  gdb_sys_accept4 = 533,
	...
	to steer clear of the space where ppc_canonicalize_syscall and
	s390_canonicalize_syscall do hard-coded number magic.

	Tested on x86_64-linux, with and without target board unix/-m32, and
	aarch64-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Rewrite i386_canonicalize_syscall
	On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case
	gdb.reverse/recvmsg-reverse.exp, I run into:
	...
	(gdb) continue^M
	Continuing.^M
	Process record and replay target doesn't support syscall number 360^M
	Process record: failed to record execution log.^M
	^M
	Program stopped.^M
	0xf7fc5575 in __kernel_vsyscall ()^M
	(gdb) FAIL: $exp: continue to breakpoint: marker2
	...

	The syscall number 360 in i386 is for syscall socketpair, as we can see in
	arch/x86/entry/syscalls/syscall_32.tbl:
	...
	<number>  <abi>  <name>      <entry point>
	360       i386   socketpair  sys_socketpair
	...

	Function i386_canonicalize_syscall assumes that any syscall below 500 maps to
	an identically valued enum in enum gdb_syscall:
	...
	static enum gdb_syscall
	i386_canonicalize_syscall (int syscall)
	{
	  enum { i386_syscall_max = 499 };

	  if (syscall <= i386_syscall_max)
	    return (enum gdb_syscall) syscall;
	  else
	    return gdb_sys_no_syscall;
	}
	...

	However, that's not the case.  The value of gdb_sys_socketpair is not 360,
	but 512:
	...
	enum gdb_syscall {
	  ...
	  gdb_sys_getrandom = 355,
	  gdb_sys_statx = 383,
	  ...
	  gdb_sys_socketpair = 512,
	...

	Consequently, when record_linux_system_call is called with
	syscall == i386_canonicalize_syscall (360), we hit the default case here:
	....
	  switch (syscall)
	    {
	    ...
	    default:
	      gdb_printf (gdb_stderr,
	                  _("Process record and replay target doesn't "
	                    "support syscall number %d\n"), syscall);
	      return -1;
	      break;
	    }
	...
	rather than hitting the case for gdb_sys_socketpair.

	I initially wrote a trivial fix for this, changing the value of
	gdb_sys_socketpair to 360.  However, Andreas Schwab pointed out that there are
	other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that
	make assumptions about specific values of enum gdb_syscall, and fixing this
	for i386 may break things for ppc or s390.

	So instead, I decided to rewrite i386_canonicalize_syscall to match the
	approach taken in aarch64_canonicalize_syscall, which allows
	gdb_sys_socketpair to keep the same value.

	So, fix this by:
	- adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for
	  each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl,
	- using gdb/i386-syscalls.def to define enum i386_syscall, and
	- using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to
	  define the mapping from enum i386_syscall to enum gdb_syscall in
	  i386_canonicalize_syscall.

	I've created the mapping as follows:
	- I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping
	  using SYSCALL_MAP for each syscall,
	- I attempted to compile this and used the compilation errors about
	  non-existing gdb_sys_ values to change those entries to
	  UNSUPPORTED_SYSCALL_MAP, which got me a compiling version,
	- I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to
	  SYSCALL_MAP_RENAME where necessary,
	- I then reviewed syscalls below 500 that mapped to a gdb_syscall value below
	  500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and
	- reviewed the mapping for gdb_syscall entries >= 500.

	On the resulting mapping, I was able to do the following sanity check:
	...
	  for (int i = 0; i < 500; ++i)
	    {
	      int res = i386_canonicalize_syscall (i);
	      if (res == i)
		continue;
	      if (res == -1)
		continue;
	      if (res >= 500)
		continue;
	      gdb_assert_not_reached ("");
	    }
	}
	...
	to make sure that any syscall below 500 either:
	- maps to the same number,
	- is unsupported, or
	- maps to a number >= 500.

	Coming back to our original problem, the socket pair syscall is addressed by
	an entry:
	...
	      SYSCALL_MAP (socketpair);
	...
	which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512).

	Tested on x86_64-linux with target board unix/-m32.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

	PR tdep/32770
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770

2025-03-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use all_units_range in dwarf2_base_index_functions::expand_all_symtabs
	Commit 292041562289 ("gdb/dwarf: use ranged for loop in some spots")
	broke some tests notably gdb.base/maint.exp with the fission board.

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/maint/maint -ex start -ex "maint expand-sym" -batch
	    ...
	    Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/break.c:43
	    43          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
	    /usr/include/c++/14.2.1/debug/safe_iterator.h:392:
	    In function:
	        gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>&
	        gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::operator++()
	        [with _Iterator = gnu_cxx::
	        normal_iterator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*,
	        std::vector<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
	        std::allocator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > >
	        >; _Sequence = std::debug::vector<std::unique_ptr<dwarf2_per_cu,
	        dwarf2_per_cu_deleter> >; _Category = std::forward_iterator_tag]

	    Error: attempt to increment a singular iterator.

	Note that this is caught because I build with -D_GLIBCXX_DEBUG=1.
	Otherwise, it might crash more randomly, or just not crash at all (but
	still be buggy).

	While iterating on the all_units vector, some type units get added
	there:

	    #0  add_type_unit (per_bfd=0x51b000044b80, section=0x50e0000c2280, sect_off=0, length=74, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2576
	    #1  0x00005555618a3a40 in lookup_dwo_signatured_type (cu=0x51700009b580, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2664
	    #2  0x00005555618ee176 in queue_and_load_dwo_tu (dwo_unit=0x521000120e00, cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8329
	    #3  0x00005555618eeafe in queue_and_load_all_dwo_tus (cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8366
	    #4  0x00005555618966a6 in dw2_do_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1695
	    #5  0x00005555618968d4 in dw2_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1719
	    #6  0x000055556189ac3f in dwarf2_base_index_functions::expand_all_symtabs (this=0x502000024390, objfile=0x516000065780) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1977

	This invalidates the iterator in
	dwarf2_base_index_functions::expand_all_symtabs, which is caught by the
	libstdc++ debug mode.

	I'm not entirely sure that it is correct to append type units from dwo
	files to the all_units vector like this.  The
	dwarf2_find_containing_comp_unit function expects a precise ordering of
	the elements of the all_units vector, to be able to do a binary search.
	Appending a type unit at the end at this point certainly doesn't respect
	that ordering.

	For now I'd just like to undo the regression.  Do that by using
	all_units_range in the ranged for loop.  I will keep in mind to
	investigate whether this insertion of type units in all_units after the
	fact really makes sense or not.

	Change-Id: Iec131e59281cf2dbd12d3f3d163b59018fdc54da

2025-03-13  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: remove unused parameter of create_dwo_cu_reader
	Change-Id: I0c5b7591eab8e6616b653be7c04bc75159427ad6

2025-03-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary braces
	Change-Id: I3cd6b932d0dfb4cc07b6d48a1dc9ec35e7bfa03e

2025-03-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use ranged for loop in some spots
	I noticed that these loops could be written to avoid the iteration
	variable `i`.

	Change-Id: I8b58eb9913b6ac8505ee45eb8009ef7027236cb9

2025-03-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-12  Sam James  <sam@gentoo.org>

	gprofng: regenerate Makefile.in
	Needed after 90803ffdcc4d8c3d17566bf8dccadbad312f07a9.

	gprofng/ChangeLog
		* src/Makefile.in: Regenerate.

2025-03-12  Zheng Junjie  <zhengjunjie@iscas.ac.cn>

	gprofng: Fix cross-compilation binary name.
	commit d25ba4596e85da6d8af78c88b5917e14763afbe1 create symbolic link
	no care cross-compilation prefix.

	gprofng/ChangeLog
	2025-02-10  Zheng Junjie  <zhengjunjie@iscas.ac.cn>
		* src/Makefile.am: create symbolic link respect cross-compilation.
		* src/Makefile.in: Rebuild.

2025-03-12  Tom Tromey  <tom@tromey.com>

	Use correct types in string-set.h
	My earlier patch to introduce string-set.h used the wrong type in the
	hash functions.  This patch fixes the error.

2025-03-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes in exceptions.c
	These are reported as unused by clangd.

	Change-Id: I54b3fba4d7a73c955a9a26c0d340a384b2d37b32

2025-03-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove trailing whitespaces in exceptions.c
	Change-Id: Icc7b468b85c09a9721fc9580892c9ad424e0a29a

2025-03-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove include from process-stratum-target.h
	It is reported as unused by clangd.

	Change-Id: I73c03577c521c1b71128409b5cf085a4d1785080

2025-03-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb map in mi-cmds.c
	This changes mi-cmds.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb map in py-connection.c
	This changes py-connection.c to use gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set in dwarf2/aranges.c
	This changes dwarf2/aranges.c to use gdb::unordered_set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set in all_non_exited_process_targets
	This changes all_non_exited_process_targets to return
	gdb::unordered_set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set and map in remote.c
	This changes remote.c to use gdb::unordered_set and
	gdb::unordered_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set and map in mi-main.c
	This changes mi-main.c to use gdb::unordered_set and
	gdb::unordered_map.

	this may change the order of core ids that are emitted, but that seems
	fine as MI generally doesn't guarantee ordering.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb::function_view in iterate_over_threads
	This C++-ifies iterate_over_threads, changing it to accept a
	gdb::function_view and to return bool.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set and map in TUI
	This changes the TUI to use gdb::unordered_map and gdb::unordered_set
	rather than the std:: variants.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom Tromey  <tom@tromey.com>

	Use gdb set and map in source_cache
	This changes source_cache to use gdb::unordered_map and
	gdb::unordered_set rather than the std:: variants.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41
	On openSUSE Tumbleweed, with glibc 2.41, when running test-case
	gdb.base/step-over-syscall.exp I run into:
	...
	(gdb) stepi^M
	0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M
	1: x/i $pc^M
	=> 0x7ffff7cfd09b <__abort_lock_rdlock+29>:     syscall^M
	(gdb) p $eax^M
	$1 = 14^M
	(gdb) FAIL: $exp: fork: displaced=off: syscall number matches
	FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout)
	...

	We're stepi-ing through fork trying to find the fork syscall, but encounter
	another syscall.

	The test-case attempts to handle this:
	...
	      gdb_test_multiple "stepi" "find syscall insn in $syscall" {
	            -re ".*$syscall_insn.*$gdb_prompt $" {
	                # Is the syscall number the correct one?
			if {[syscall_number_matches $syscall]} {
	                    pass $gdb_test_name
	                } else {
			    exp_continue
	                }
	            }
	            -re "x/i .*=>.*\r\n$gdb_prompt $" {
	                incr steps
	                if {$steps == $max_steps} {
	                    fail $gdb_test_name
	                } else {
	                    send_gdb "stepi\n"
	                    exp_continue
	                }
	            }
	        }
	...
	but fails to do so because it issues an exp_continue without issuing a new
	stepi command, and consequently the "find syscall insn in fork" test times
	out.

	Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping
	one syscall would produce:
	...
	FAIL: $exp: fork: displaced=off: syscall number matches
	PASS: $exp: fork: displaced=off: syscall number matches
	DUPLICATE: $exp: fork: displaced=off: syscall number matches
	...

	Fix this by:
	- not producing PASS or FAIL in syscall_number_matches, and
	- issuing stepi when encountering another syscall.

	While we're at it, fix indentation in syscall_number_matches.

	Tested on x86_64-linux, specifically:
	- openSUSE Tumbleweed (glibc 2.41), and
	- openSUSE Leap 15.6 (glibc 2.38).

	PR testsuite/32780
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780

2025-03-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-10  Tom Tromey  <tom@tromey.com>

	Remove pid from test name in gcore-memory-usage.exp
	The new gcore-memory-usage.exp test puts a PID into a test case name,
	causing spurious comparison failures.  This patch changes the test
	name to avoid this.

2025-03-10  Tom Tromey  <tom@tromey.com>

	Add string cache and use it in cooked index
	The cooked index needs to allocate names in some cases -- when
	canonicalizing or when synthesizing Ada package names.  This process
	currently uses a vector of unique_ptrs to manage the memory.

	Another series I'm writing adds another spot where this allocation
	must be done, and examining the result showed that certain names were
	allocated multiple times.

	To clean this up, this patch introduces a string cache object and
	changes the cooked indexer to use it.  I considered using bcache here,
	but bcache doesn't work as nicely with string_view -- because bcache
	is fundamentally memory-based, a temporary copy of the contents must
	be made to ensure that bcache can see the trailing \0.  Furthermore,
	writing a custom class lets us avoid another copy when canonicalizing
	C++ names.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	Revert past commits
	I accidentally pushed my work-in-progress branch... revert that.  Sorry
	for the noise :(.

	The list of commits reverted are:

	    ae2a50a9ae15 attempt to revamp to the CU/TU list
	    e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"
	    6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name
	    32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def
	    b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them
	    30ba74418982 gdb/dwarf: track comp and type units count
	    bedb4e09f292 gdb/dwarf: remove unnecessary braces
	    b4f18de12c77 gdb/dwarf: use ranged for loop in some pots

	Change-Id: I80aed2847025f5b15c16c997680783b39858a703

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	attempt to revamp to the CU/TU list
	Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7

2025-03-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"
	This was useful to me, to debug some problems.

	Before printing cooked index entries, print a list of CUs and TUs.  The
	information printed for each is a bit arbitrary, I took a look at the
	types and printed what seemed relevant.

	An example of output for a CU:

	    [0] ((dwarf2_per_cu_data *) 0x50f000007840)
	    type:       DW_UT_compile
	    offset:     0x0
	    size:       0x1bff
	    artificial: false
	    GDB lang:   c++
	    DWARF lang: DW_LANG_C_plus_plus

	And for a TU:

	    [2] ((signatured_type *) 0x511000040000)
	    type:      DW_UT_type
	    offset:    0x0
	    size:      0x94
	    signature: 0x2e966c0dc94b065b

	I moved the call to cooked_index_functions::wait before printing the
	CU/TU list, otherwise trying to call "maint print objfiles" quickly,
	like this, would lead to an internal error:

	  $ ./gdb  -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig -ex "maint print objfiles"

	This is because dwarf2_per_cu_data::m_unit_type was not yet set, when
	trying to read it.  Waiting for the index to be built ensures that it is
	set, since setting the unit type is done as a side-effect somewhere.

	Change-Id: Ic810ec3bb4d3f5abb481cf1cee9b2954ff4f0874

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: add dwarf_source_language_name
	Add dwarf_source_language_name, to convert a DW_LANG_* constant to
	string.  This will be used in a following patch.

	Change-Id: I552ebd318e2e770d590de5920edbd0b75075c1b7
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	libiberty: move DW_LANG_* definitions to dwarf2.def
	In order to get a "DW_LANG_* to string" function:

	  - move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def
	  - add the necessary macros in dwarf2.h to generate the enumeration
	  - add the necessary macros in dwarfnames.c to generate the "to string"
	    function

	include/ChangeLog:

		* dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then
		undefine.
		(enum dwarf_source_language): Remove.
		(get_DW_LANG_name): Declare.
		* dwarf2.def: Define DW_LANG_* constants.

	libiberty/ChangeLog:

		* dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define
		then undefine.

	Change-Id: I440aa2b1f55c7585d7e44c8fa7c41310b0ef2b3a
	Cc: binutils@sourceware.org

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: move index unit vectors to debug names reader and use them
	Since these vectors contain the CU and TU lists as found in the
	.debug_names header, it seems like they are meant to be used by the
	.debug_names reader when handling a DW_IDX_compile_unit or
	DW_IDX_type_unit attribute.  The value of the attribute would translate
	directly into an index into one of these vectors.

	However there's something fishy: it looks like these vectors aren't
	actually used in practice.  They are used in the
	dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used
	anywhere.

	The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
	dwarf2_per_bfd::get_cu method, assuming that all compile units are
	placed before type units in the dwarf2_per_bfd::all_units vector.  I see
	several problems with that:

	 1. I found out [1] that the dwarf2_per_bfd::all_units didn't always
	    have the CUs before the TUs.  So indexing dwarf2_per_bfd::all_units
	    with that assumption will not work.

	 2. The dwarf2_find_containing_comp_unit function assumes an ordering of
	    units by section offset (among other criteria) in order to do a
	    binary search.  Even though it's probably commonly the case, nothing
	    guarantees that the order of CUs and TUs in the .debug_names header
	    (which defines the indices used to refer to them) will be sorted by
	    section offset.  It's not possible to make
	    dwarf2_find_containing_comp_unit (assuming it wants to do a binary
	    search by section offset) and the DW_IDX_compile_unit /
	    DW_IDX_type_unit handlers use the same vector.

	 3. I have not tested this, but in the presence of a dwz supplementary
	    file, the .debug_names reader should probably not put the units from
	    the main and dwz files in the same vectors to look them up by index.
	    Presumably, if both the main and dwz files have a .debug_names
	    index, they have distinct CU / TU lists.  So, an CU index of 1 in an
	    index entry in the main file would refer to a different CU than an
	    index of 1 in an index entry in the dwz file.  The current code
	    doesn't seem to account for that, it just indexes
	    dwarf2_per_bfd::all_units.

	Since those vectors are kind of specific to the .debug_names reader,
	move them there, in the mapped_debug_names_reader struct.  Then, update
	the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them.

	[1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4

	Change-Id: I3958d70bb3875268143471da745aa09336ab2500

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: track comp and type units count
	A subsequent commit will remove the all_comp_units and all_type_units
	array views, since the all_units vector will no longer be segmented
	between comp and type units.  Some callers still need to know the number
	of each kind, so track that separately.

	Change-Id: I6ef184767a96e5be095bbf9142aa850adbb083ac

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary braces
	Change-Id: If0b38b860e79771a16ea914af3e337fca0ee3a7d

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use ranged for loop in some pots
	I noticed that these loops could be written to avoid the iteration
	variable `i`.

	Change-Id: Ia3717acbbf732f0337870d35ac60fe6400383324

2025-03-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: save DWARF version in dwarf2_loclist_baton, remove it from dwarf2_per_cu
	When running:

	    $ make check TESTS="gdb.cp/cpexprs-debug-types.exp" RUNTESTFLAGS="--target_board=fission"

	I get:

	    (gdb) break -qualified main
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.h:295: internal-error: version: Assertion `m_dwarf_version != 0' failed.

	The problem is that dwarf2_per_cu objects created in the
	read_cutu_die_from_dwo code path never have their DWARF version set.  A
	seemingly obvious solution would be to add a call to
	dwarf2_per_cu::set_version in there (there's a patch in the referenced
	PR that does that).  However, this comment in
	read_comp_units_from_section is a bit scary:

	      /* Init this asap, to avoid a data race in the set_version in
		 cutu_reader::cutu_reader (which may be run in parallel for the cooked
		 index case).  */
	      this_cu->set_version (cu_header.version);

	I don't know if a DWO file can be read while the cooked indexer runs, so
	if it would be a problem here, but I prefer to be safe than sorry.  This
	patch side-steps the problem by deleting the DWARF version from
	dwarf2_per_cu.

	The only users of dwarf2_per_cu::version are the loclists callbacks in
	`loc.c`.  Add the DWARF version to dwarf2_loclist_baton and modify those
	callbacks to get the version from there instead.  Initialize that new
	field in fill_in_loclist_baton.

	I like this approach because there is no version field that is possibly
	unset now.

	I wasn't keen on doing this at first because I thought it would waste
	space, but the dwarf2_loclist_baton has 7 bytes of padding at the end
	anyway, so we might as well use that.

	Cc: Ricky Zhou <ricky@rzhou.org>
	Cc: Tom de Vries <tdevries@suse.de>
	Cc: Tom Tromey <tom@tromey.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309
	Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-10  Tom Tromey  <tromey@adacore.com>

	Use flags enum for cooked_index_entry::full_name
	I found a small bug coming from a couple of  recent patches of mine for
	cooked_index_entry::full_name.

	First, commit aab26529b30 (Add "Ada linkage" mode to
	cooked_index_entry::full_name) added a small hack to optionally
	compute the Ada linkage name.

	Then, commit aab2ac34d7f (Avoid excessive CU expansion on failed
	matches) changed the relevant expand_symtabs_matching implementation
	to use this feature.

	However, the feature was used unconditionally, causing a bad side
	effect: the non-canonical name is now used for all languages, not just
	Ada.  But, for C++ this is wrong.

	Furthermore, consider the declaration of full_name:

	   const char *full_name (struct obstack *storage,
				 bool for_main = false,
				 bool for_ada_linkage = false,
	 			 const char *default_sep = nullptr) const;

	... and then consider this call in cooked_index::dump:

	       gdb_printf ("    qualified:  %s\n",
			  entry->full_name (&temp_storage, false, "::"));

	Oops!  The "::" is silently converted to 'true' here.

	To fix both of these problems, this patch changes full_name to accept
	a flags enum rather than booleans.  This avoids the type-safety
	problem.

	Then, full_name is changed to remove the "Ada" flag when the entry is
	not in fact an Ada symbol.

	Regression tested on x86-64 Fedora 40.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-10  Tom Tromey  <tom@tromey.com>

	Remove eval_op_scope
	eval_op_scope is very similar to
	scope_operation::evaluate_for_address.  This patch combines the two
	into a single method of scope_operation.

	Regression tested on x86-64 Fedora 40.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: rename comp_unit_die to top_level_die
	The name "comp_unit_die" is a bit misleading, because it can also
	represent a type unit (DW_TAG_type_unit).  I think that "top_level_die"
	is clear.

	Change-Id: Ibaac99897f0ac7499f0f82caeed3385e1e6ee870
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: add doc for cutu_reader::is_dummy
	Change-Id: Ifb80557187c12822bdea7ad400c32c3dce968a7f
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-10  Tom Tromey  <tom@tromey.com>

	Fix check-include-guards.py
	I noticed that check-include-guards.py doesn't error in certain
	situations -- but in situations where the --update flag would cause a
	file to be changed.

	This patch changes the script to issue an error for any discrepancy.
	It also fixes the headers that weren't correct.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-10  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Append -l to tst-gmon-gprof-l.sh data files
	Append -l to tst-gmon-gprof-l.sh data files to avoid conflicts with
	tst-gmon-gprof.sh data files.

		* testsuite/tst-gmon-gprof-l.sh (actual): Append -l.
		(expected): Likewise.
		(expected_dot): Likewise.

2025-03-10  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Add a simple test for gprof -l
	Verify that "gprof -l" works properly.

		* testsuite/Makefile.am (check_SCRIPTS): Add tst-gmon-gprof-l.sh.
		* testsuite/Makefile.in: Regenerated.
		* testsuite/tst-gmon-gprof-l.sh: New.

2025-03-10  Alan Modra  <amodra@gmail.com>

	meaningless p_offset for zero p_filesz PT_LOAD
	This patch avoids generating PT_LOAD segments that trip a bug in
	glibc's loader.

		PR 25237
		PR 32763
		* elf.c (assign_file_positions_for_load_sections): Don't put
		p_offset zero for empty PT_LOAD.

2025-03-10  Alan Modra  <amodra@gmail.com>

	Further tidies to bed->p_align code
	align_pagesize was used for two things, reducing p->p_align from
	maxpagesize to the bed->p_align value (section alignment permitting),
	and increasing p->p_align above maxpagesize if section alignment
	required that.  This patch untangles those two, making align_pagesize
	only do the former.  p->p_align is set directly for the latter.  I've
	made that change to p->p_align only when D_PAGED to keep things
	consistent with other early assignments to p->p_align.  p->p_align is
	set later according to section alignment when not D_PAGED.

	I've also moved the place where align_pagesize adjusts p->p_align to
	be with other code setting p->p_align.  That seemed better to me than
	leaving it until the last possible moment.  Note that it isn't
	necessary to have this adjustment done inside a test for a PT_LOAD
	header, since we never set align_pagesize non-zero outside a PT_LOAD
	test.

		* elf.c (assign_file_positions_for_load_sections): Clear
		align_pagesize whenever we have a section alignment more than
		bed->p_align.  Set p->p_align rather than align_pagesize
		when section alignment exceeds maxpagesize.  Assign p->p_align
		from align_pagesize earlier.

2025-03-10  Alan Modra  <amodra@gmail.com>

	Tidy code handling bed->p_align a little.
	No functional changes here, just preparation for the next patch.

		* elf.c (assign_file_positions_for_load_sections): Replace
		p_align_p and p_align with align_pagesize.  Revise comments
		on code handling bed->p_align.

2025-03-10  Jens Remus  <jremus@linux.ibm.com>

	ld: Cleanup sframe_decoder_init_func_bfdinfo use of reloc cookie
	The loop did set cookie->rel to the i-th relocation twice.  At the
	beginning using the loop counter.  At the end by incrementing.  One
	approach is sufficient.

	Change cookie to pointer-to-const, replace cookie->rel by rel,
	initialize before the loop and increment at the end, and merge the
	two assertions (for cookie->rel) into one.

	While at it change sec to pointer-to-const.

	bfd/
		* elf-sframe.c (sframe_decoder_init_func_bfdinfo): Cleanup use
		of relocation cookie.

2025-03-10  Jens Remus  <jremus@linux.ibm.com>

	gas: Use SFrame header and FDE field sizes when generating .sframe
	The use of SFRAME_RELOC_SIZE in generation of SFrame stack trace
	information from CFI directives erroneously suggested that this could
	be used to configure a different relocation size.  But in practice it
	is tied to the SFrame field sizes it is used for and therefore cannot
	be changed.

	Replace the uses of SFRAME_RELOC_SIZE by the size of the respective
	SFrame header and FDE fields when emitting SFrame information.  While
	at it enhance some comments.

	gas/
		* gen-sframe.c (SFRAME_RELOC_SIZE): Delete.
		(sizeof_member): Define.
		(output_sframe_funcdesc): Use size of SFrame FDE fields instead
		of SFRAME_RELOC_SIZE.
		(output_sframe_internal): Use size of SFrame header fields
		instead of SFRAME_RELOC_SIZE.

2025-03-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-09  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR32772, fixed segfault caused by the accidental removal of `h != NULL'
	bfd/
		PR 32772
		* elfnn-riscv.c (riscv_elf_relocate_section): Fixed segfault caused by
		the accidental removal of `h != NULL' when handling a call to an
		undefined weak function.

2025-03-09  Brandon Belew  <brandon.belew@zetier.com>

	Fix segfault if target_fileio_read_alloc fails
	Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
	before dereferencing buffer. This fixes a segfault in the 'gcore'
	command when attached to certain remote targets.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32441
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-03-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-08  Alan Modra  <amodra@gmail.com>

	bfd_elf_parse_attr_section_v1 buffer overflow
	This function has a misleading parameter "contents", which usually
	means an entire section contents is passed.  However in this case the
	actual sections contents plus one is passed, leading to miscalculating
	the end of the buffer.

		* elf-attrs.c (bfd_elf_parse_attr_section_v1): Delete hdr and
		contents param.  Add p and p_end as params.
		(_bfd_elf_parse_attributes): Adjust to suit.

2025-03-08  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Compile tst-gmon.c with -O2 -fno-omit-frame-pointer
	Compile tst-gmon.c with -O2 -fno-omit-frame-pointer to ensure proper call
	graph generation.

		PR gprof/32768
		* configure.ac: Compile tst-gmon.c with -fno-omit-frame-pointer.
		* configure: Regenerated.
		* testsuite/Makefile.am (GPROF_FLAGS): Add -O2
		-fno-omit-frame-pointer.
		(AM_CFLAGS): Removed.
		(COMPILE): Append $(GPROF_FLAGS).
		(LINK): Likewise.
		* testsuite/Makefile.in: Regenerated.

2025-03-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32 for AMD
	When running test-case gdb.base/step-over-syscall.exp with target board
	unix/-m32 on an AMD processor, I run into:
	...
	(gdb) x/2i $pc^M
	=> 0xf7fc9575 <__kernel_vsyscall+5>:    syscall^M
	   0xf7fc9577 <__kernel_vsyscall+7>:    int    $0x80^M
	(gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction
	stepi^M
	[Detaching after fork from child process 65650]^M
	0xf7fc9579 in __kernel_vsyscall ()^M
	1: x/i $pc^M
	=> 0xf7fc9579 <__kernel_vsyscall+9>:    pop    %ebp^M
	(gdb) $exp: fork: displaced=off: stepi fork insn
	print /x $pc^M
	$2 = 0xf7fc9579^M
	(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
	FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall
	...

	The problem is that the syscall returns at the "pop %ebp" insn, while the
	test-case expects it to return at the "int $0x80" insn.

	This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite]
	Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence
	used there used the "sysenter" insn instead of the "syscall" insn.

	Fix this by extending the fix for commit 14852123287 to also handle the
	"syscall" insn.

	Tested on x86_64-linux, both using an AMD and Intel processor.

	PR testsuite/32439
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32439

2025-03-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: call other cutu_reader constructor in ensure_lang and dw2_get_file_names
	PR 32742 shows this failing:

	    $ make check TESTS="gdb.ada/access_to_unbounded_array.exp" RUNTESTFLAGS="--target_board=fission"
	    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.ada/access_to_unbounded_array.exp ...
	    FAIL: gdb.ada/access_to_unbounded_array.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:23 (GDB internal error)

	Or, interactively:

	    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.ada/access_to_unbounded_array/foo-all -ex 'b foo.adb:23' -batch
	    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19567: internal-error: set_lang: Assertion `old_value == language_unknown || old_value == language_minimal || old_value == lang' failed.

	The symptom is that for a given dwarf2_per_cu, the language gets set
	twice.  First, set to `language_ada`, and then, to `language_minimal`.
	It's unexpected for the language of a CU to get changed like this.

	The CU at offset 0x0 in the main file looks like:

	    0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034)

	    0x0000000b: DW_TAG_compile_unit
	                  DW_AT_low_pc [DW_FORM_addr]       (0x000000000000339a)
	                  DW_AT_high_pc [DW_FORM_data8]     (0x0000000000000432)
	                  DW_AT_stmt_list [DW_FORM_sec_offset]      (0x00000000)
	                  DW_AT_GNU_dwo_name [DW_FORM_strp] ("b~foo.dwo")
	                  DW_AT_comp_dir [DW_FORM_strp]     ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
	                  DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)
	                  DW_AT_GNU_addr_base [DW_FORM_sec_offset]  (0x00000000)
	                  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0x277aee54e7bd47f7)

	This refers to the DWO file b~foo.dwo, whose top-level DIE is:

	    .debug_info.dwo contents:
	    0x00000000: Compile Unit: length = 0x00000b63, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000b67)

	    0x0000000b: DW_TAG_compile_unit
	                  DW_AT_producer [DW_FORM_GNU_str_index]    ("GNU Ada 14.2.1 20250207 -fgnat-encodings=minimal -gdwarf-4 -fdebug-types-section -fuse-ld=gold -gnatA -gnatWb -gnatiw -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -gnatws -mtune=generic -march=x86-64")
	                  DW_AT_language [DW_FORM_data1]    (DW_LANG_Ada95)
	                  DW_AT_name [DW_FORM_GNU_str_index]        ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array/b~foo.adb")
	                  DW_AT_comp_dir [DW_FORM_GNU_str_index]    ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
	                  DW_AT_GNU_dwo_id [DW_FORM_data8]  (0xdbeffefab180a2cb)

	The thing to note is that the language attribute is only present in the
	DIE in the DWO file, not on the DIE in the main file.

	The first time the language gets set is here:

	    #0  dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_ada, dw_lang=DW_LANG_Ada95) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
	    #1  0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff10bf2b0, cu=0x51700008e000, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
	    #2  0x000055556159f740 in cutu_reader::cutu_reader (this=0x7ffff10bf2b0, this_cu=0x50f0000044b0, per_objfile=0x516000066080, abbrev_table=0x510000004640, existing_cu=0x0, skip_partial=false, pretend_language=language_minimal, cache=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3371
	    #3  0x00005555615a547a in process_psymtab_comp_unit (this_cu=0x50f0000044b0, per_objfile=0x516000066080, storage=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3799
	    #4  0x00005555615a9292 in cooked_index_worker_debug_info::process_cus (this=0x51700008dc80, task_number=0, first=std::unique_ptr<dwarf2_per_cu> = {...}, end=std::unique_ptr<dwarf2_per_cu> = {...}) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4122

	In this code path (particularly this specific cutu_reader constructir),
	the work is done to find and read the DWO file.  So the language is
	properly identifier as language_ada, all good so far.

	The second time the language gets set is:

	    #0  dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_minimal, dw_lang=0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
	    #1  0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff0f42730, cu=0x517000091b80, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
	    #2  0x00005555615a1822 in cutu_reader::cutu_reader (this=0x7ffff0f42730, this_cu=0x50f0000044b0, per_objfile=0x516000066080, pretend_language=language_minimal, parent_cu=0x0, dwo_file=0x0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3464
	    #3  0x000055556158c850 in dw2_get_file_names (this_cu=0x50f0000044b0, per_objfile=0x516000066080) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1956
	    #4  0x000055556158f4f5 in dw_expand_symtabs_matching_file_matcher (per_objfile=0x516000066080, file_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2157
	    #5  0x00005555616329e2 in cooked_index_functions::expand_symtabs_matching (this=0x50200002ab50, objfile=0x516000065780, file_matcher=..., lookup_name=0x0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=..., lang_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:15912
	    #6  0x0000555562ca8a14 in objfile::map_symtabs_matching_filename (this=0x516000065780, name=0x50200002ad90 "break pck.adb", real_path=0x0, callback=...) at /home/smarchi/src/binutils-gdb/gdb/symfile-debug.c:207
	    #7  0x0000555562d68775 in iterate_over_symtabs (pspace=0x513000005600, name=0x50200002ad90 "break pck.adb", callback=...) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:727

	Here, we use the other cutu_reader constructor, the one that does not
	look up the DWO file for the passed CU.  If a DWO file exists for this
	CU, the caller is expected to pass it as a parameter.  That cutu_reader
	constructor also ends up setting the language of the CU.  But because it
	didn't read the DWO file, it didn't figure out the language is
	language_ada, so it tries to set the language to the default,
	language_minimal.

	A question is: why do we end up trying to set the CU's language is this
	context.  This is completely unrelated to what we're trying to do, that
	is get the file names from the line table.  Setting the language is a
	side-effect of just constructing a cutu_reader, which we need to look up
	attributes in dw2_get_file_names_reader.  There are probably some
	cleanups to be done here, to avoid doing useless work like looking up
	and setting the CU's language when all we need is an object to help
	reading the DIEs and attributes.  But that is future work.

	The same cutu_reader constructor is used in
	`dwarf2_per_cu::ensure_lang`.  Since this is the version of cutu_reader
	that does not look up the DWO file, it will conclude that the language
	is language_minimal and set that as the CU's language.  In other words,
	`dwarf2_per_cu::ensure_lang` will get the language wrong, pretty ironic.

	Fix this by using the other cutu_reader constructor in those two spots.
	Pass `per_objfile->get_cu (this_cu)`, as the `existing_cu` parameter.  I
	think this is necessary, because that constructor has an assert to check
	that if `existing_cu` is nullptr, then there must not be an existing
	`dwarf2_cu` in the per_objfile.

	To avoid getting things wrong like this, I think that the second
	cutu_reader constructor should be reserved for the spots that do pass a
	non-nullptr dwo_file.  The only spot at the moment in
	create_cus_hash_table, where we read multiple units from the same DWO
	file.  In this context, I guess it makes sense for efficiency to get the
	dwo_file once and pass it down to cutu_reader.  For that constructor,
	make the parameters non-optional, add "non-nullptr" asserts, and update
	the code to assume the passed values are not nullptr.

	What I don't know is if this change is problematic thread-wise, if the
	functions I have modified to use the other cutu_reader constructor can
	be called concurrently in worker threads.  If so, I think it would be
	problematic.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32742
	Change-Id: I980d16875b9a43ab90e251504714d0d41165c7c8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-08  Tom Tromey  <tom@tromey.com>

	Avoid excessive CU expansion on failed matches
	PR symtab/31010 points out that something like "ptype INT" will expand
	all CUs in a typical program.  The OP further points out that the
	original patch for PR symtab/30520:

	    https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html

	... did solve the problem, but the patch changed after (my) review and
	reintroduced the bug.

	In cooked_index_functions::expand_symtabs_matching, the final
	component of a split name is compared with the entry's name using the
	usual method of calling get_symbol_name_matcher.

	This code iterates over languages and tries to split the original name
	according to each style.  But, the Ada splitter uses the decoded name
	-- "int".  This causes every C or C++ CU to be expanded.

	Clearly this is wrong.  And, it seems to me that looping over
	languages and trying to guess the splitting style for the input text
	is probably bad.  However, fixing the problem is not so easy (again
	due to Ada).  I've filed a follow-up bug, PR symtab/32733, for this.

	Meanwhile, this patch changes the code to be closer to the
	originally-submitted patch.  This works because the comparison is now
	done between the full name and the "lookup_name_without_params"
	object, which is a less adulterated variant of the original input.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010
	Tested-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-08  Tom Tromey  <tom@tromey.com>

	Use wild matching for lookup_name_info::match_any
	Currently, lookup_name_info::match_any symbol_name_match_type::FULL.
	However, this seems wrong.  Consider the expand_symtabs_matching
	implementation of the cooked index: it compares name components, and
	then if all the components match, it checks:

	  if ((match_type == symbol_name_match_type::FULL
	       || (lang != language_ada
		   && match_type == symbol_name_match_type::EXPRESSION)))
	    {
	      if (parent != nullptr)
		continue;

	That is, if the component-matching loop did not finish, and a full
	match is requested, then fail to match.  This handles cases where the
	index is asked to look up "b::c" but finds "a::b::c".

	However, match_any should match, well, any.  So, it seems to me that
	checking any parent matches is irrelevant -- and therefore this should
	use wild matching.

2025-03-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-07  Tom Tromey  <tom@tromey.com>

	Handle ">>" in cp-name-parser.y
	I noticed that a certain name didn't work correctly when trying to
	remove the parameters.  I put this into lookup_name_info-selftests.c.

	I tracked this down to the fact that cp-name-parser.y doesn't handle
	">>" to end templates.  This patch fixes this in a simple way --
	accepting the "RSH" token where appropriate and then un-pushing a ">".

2025-03-07  Tom Tromey  <tom@tromey.com>

	Minor cleanups to cpname_state
	This changes cpname_state to have a constructor and some inline
	initializers.

2025-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: move cooked_indexer to cooked-indexer.{h,c}
	Move the cooked_indexer class declaration to a new cooked-indexer.h
	file, and the implementation to cooked-indexer.c.

	Change-Id: Ibff3b06045b2af65fa9516097acf732d7c2d9414
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: move cooked_index_storage to cooked-index-storage.{h,c}
	cooked_index_storage is currently declared in `cooked-index.h` and
	implemented in `read.c`.  Move all that to new
	`cooked-index-storage.{h,c}` files.

	Change-Id: I2a07eb446d8a07b15c5664dfe01e3a820cdd45be
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: move cutu_reader to read.h
	In order to move some things outside of read.c, cutu_reader needs to be
	in a header file.

	Change-Id: Ib26d7949c55867848d109332caf2efb1a6e72923
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-07  Georg-Johann Lay  <avr@gjlay.de>

	AVR: gas/32704 - Improve code generation for __gcc_isr.
	The prologue generated by __gcc_isr can be improved in
	situations where:

	* ZERO_REG is needed, and
	* SREG is not clobbered by the ISR, and
	* avr-gcc provides a GPR >= R16 with the Done chunk, and
	* Code generation is for ordinary AVRs (not AVRrc).

	For example, the prologue for

	volatile char var;

	__attribute__((signal)) void __vector_1 (void)
	{
	    var = 1;
	    var = 0;
	}

	may be

	00000000 <__vector_1>:
	   0:	8f 93       	push	r24
	   2:	1f 92       	push	r1
	   4:	80 e0       	ldi	r24, 0
	   6:	18 2e       	mov	r1, r24

	instead of the code as currently generated by GAS:

	00000000 <__vector_1>:
	   0:	1f 92       	push	r1
	   2:	1f b6       	in	r1, SREG
	   4:	1f 92       	push	r1
	   6:	11 24       	clr	r1
	   8:	8f 93       	push	r24

	which consumes more stack, time and code than needed.

	gas/
		PR gas/32704
		PR gas/21683
		* config/tc-avr.c (avr_isr): bool-ize.
		(avr_emit_insn): Emit "mov" code as  MOV R1,<reg>.
		(avr_isr_stack_t): New typedef.
		(avr_emit_push, avr_emit_pop): New static functions.
		(avr_patch_gccisr_frag): Overhaul prologue and epilogue
		generation.

2025-03-07  Nick Clifton  <nickc@redhat.com>

	Fix imm20 range check in MSP430 port of gas

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	gas: don't permit "repeat" expressions with .cfi_{escape,fde_data}
	Repeat counts greater than 1 will emit data directly into the current
	(sub-)section. That's wrong with .cfi_*, which defer data emission until
	much later: N-1 instances of the specified data would not end up in
	.eh_frame (or whatever the section that CFI data was specified to go
	into). Simply disallow "repeat" expressions in such cases.

	gas/listing: drop forward declarations
	These aren't needed (anymore); all static functions are defined before
	their first use.

	gas: centralize declaration of listing_tail
	Besides it being somewhat off to have three decls scattered across the
	code base, it is generally bad practice for the definition of a symbol
	to not also observe its declaration (making sure the two won't go out of
	sync).

	objdump: permit disassembling multiple individual functions
	Compilers may split functions, e.g. into a "hot" and "cold" part, or
	they may emit special case instantiations (e.g. as a result of IPA). It
	can be helpful to be able to disassemble all of the parts or clones in
	one go. Permit using "--disassemble=" multiple times.

	objdump: properly disassemble successive functions of the same name
	... when only their symbol was requested for disassembly. Addressing the
	respective FIXME is as easy as coverting the "else" there to an if()
	with the opposite condition, thus accounting for the disabling the
	original if() may have effected.

2025-03-07  Jan-Benedict Glaw  <jbglaw@lug-owl.de>

	Fix missing int argument warning
	This warning (per -Werror) breaks the build using a recent GCC
	with recent userland.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Support REX2 and EVEX prefix
	The following amd64 insn:
	...
	   0:	67 d5 44 8d 3d 00 00 00 00 lea 0x0(%eip),%r31d
	...
	uses the REX2 prefix [1], which is currently not supported in
	amd64_get_insn_details.

	Add the missing support in amd64_get_insn_details, as well as a corresponding
	unit test.

	Likewise for an amd64 insn using an EVEX prefix [2]:
	...
	   0:	62 f1 7c 48 28 05 00 fc ff ff vmovaps -0x400(%rip),%zmm0
	...

	Tested on x86_64-linux.

	PR tdep/32725
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32725

	[1] https://en.wikipedia.org/wiki/VEX_prefix
	[2] https://en.wikipedia.org/wiki/EVEX_prefix

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix vmovdqu decoding
	PR tdep/31952 reports that displaced stepping over an instruction pointer
	relative insn "vmovdqu 0x20(%rip),%ymm1" gives the wrong results.

	This is caused by misclassification of the insn in amd64_get_insn_details,
	which results in details.modrm_offset == -1, while the instruction in fact
	does have a modrm byte.

	The instruction is encoded as follows:
	...
	  400557:       c5 fe 6f 0d 20 00 00 00    vmovdqu 0x20(%rip),%ymm1
	...
	where:
	- "0xc5 0xfe" is the vex2 prefix,
	- "0x6f" is the opcode,
	- "0x0d" is the modrm byte, and
	- "0x20 0x00 0x00 0x00" is a 32-bit displacement.

	The problem is related to details.opcode_len, which is 1.

	While it is true that the length of the opcode in the insn (0x6f) is 1 byte,
	the vex2 prefix implies that we're encoding an 2-byte opcode beginnning
	with 0x0f [1].

	Consequently, we should be using the twobyte_has_modrm map rather than the
	onebyte_has_modrm map.

	Fix this in amd64_get_insn_details, and add a selftest to check this.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31952

	[1] https://en.wikipedia.org/wiki/VEX_prefix

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Make amd64_get_insn_details more regular
	In amd64_get_insn_details, I found this code with a comment explaining why
	enc_prefix_offset is not set:
	...
	  else if (vex2_prefix_p (*insn))
	    {
	      /* Don't record the offset in this case because this prefix has
		 no REX.B equivalent.  */
	       insn += 2;
	     }
	...
	which I didn't understand until I looked at the only use of enc_prefix_offset,
	in fixup_riprel:
	...
	  /* REX.B should be unset (VEX.!B set) as we were using rip-relative
	     addressing, but ensure it's unset (set for VEX) anyway, tmp_regno
	     is not r8-r15.  */
	  if (insn_details->enc_prefix_offset != -1)
	    {
	      gdb_byte *pfx = &dsc->insn_buf[insn_details->enc_prefix_offset];
	      if (rex_prefix_p (pfx[0]))
		pfx[0] &= ~REX_B;
	      else if (vex3_prefix_p (pfx[0]))
		pfx[1] |= VEX3_NOT_B;
	      else
		gdb_assert_not_reached ("unhandled prefix");
	    }
	...

	Fix this by:
	- setting enc_prefix_offset for the vex2 case in amd64_get_insn_details,
	  making the function more regular and easier to understand, and
	- handling the vex2 case in the "enc_prefix_offset != -1" clause in
	  fixup_riprel.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Add vzeroupper and vzeroall in amd64-insn-decode selftest
	After I posted a tentative patch for PR31952, Alexander Monakov pointed out
	that the patch broke instruction decoding for instructions vzeroall and
	vzeroupper.

	Add selftests for these two instructions in amd64-insn-decode, both using
	vex2 and vex3 prefixes.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Add vex2_to_vex3
	I noticed here [1] that the vex2 prefix is essentially a special case of the
	vex3 prefix, meaning it's possible to rewrite any insn with a vex2 prefix into
	an equivalent one with a vex3 prefix.

	Add function vex2_to_vex3 that does precisely that, in the selftests
	namespace.

	Add a selftest that exercises this function.

	Tested on x86_64-linux.

	[1] https://en.wikipedia.org/wiki/VEX_prefix

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Factor out part of fixup_riprel
	Factor out the part of fixup_riprel that patches the insn, and use it in a
	unit test.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix rip-relative insn handling in amd64_get_used_input_int_reg
	I wanted to add a unit test for an an rip-relative amd64 insn, so I did:
	...
	$ gcc -fPIE hello.c
	...
	and used an rip-relative insn from main:
	...
	  4005db:       48 8d 3d 1e 00 00 00    lea    0x1e(%rip),%rdi
	...

	While writing the unit test, I found that amd64_get_used_input_int_reg returns
	rbp as input register.

	Fix this by using rip_relative_p in amd64_get_used_input_int_reg to handle
	this case.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Factor out rip_relative_p
	Factor out rip_relative_p, and rewrite it to use MODRM_MOD_FIELD and
	MODRM_RM_FIELD.

	No functional changes.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Add amd64-insn-decode selftest
	Add a selftest that checks the results of amd64_get_insn_details and related
	functions for two basic instructions.

	Add a parameter assumptions to amd64_get_used_input_int_regs, to make sure
	that this selftest:
	...
	  /* INSN: add %eax,(%rcx).  */
	  ...
	  SELF_CHECK (amd64_get_used_input_int_regs (&details, false)
		      == ((1 << EAX_REG_NUM) | (1 << ECX_REG_NUM)));
	...
	passes because it found the "%eax" in the insn, rather than passing because of
	this assumption:
	...
	  /* Assume RAX is used.  If not, we'd have to detect opcodes that implicitly
	     use RAX.  */
	  used_regs_mask |= 1 << EAX_REG_NUM;
	...

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Factor out amd64_get_used_input_int_regs
	The function amd64_get_unused_input_int_reg consists of two parts:
	- finding the used int registers in an insn, and
	- picking an unused int register.

	Factor out the first part as new function amd64_get_used_input_int_regs.

	No functional changes.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 3
	While reading amd64_get_unused_input_int_reg, I noticed that it avoids picking
	RSP, which has to do with how the result of the only call to it is going to be
	used.

	Likewise for picking a register in the RAX ... RDI range.

	Fix this by:
	- adding an allowed_regs_mask parameter to amd64_get_unused_input_int_reg, and
	- properly documenting the value of the corresponding argument in fixup_riprel.

	No functional changes.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 2
	I noticed that amd64_get_unused_input_int_reg uses a signed int for a bit
	mask:
	...
	  /* 1 bit for each reg */
	  int used_regs_mask = 0;
	...

	There's an assert:
	...
	  gdb_assert (used_regs_mask < 256);
	...
	which is meant to assert on register numbers >= 8, but if for instance
	sizeof (used_regs_mask) == 4 and used_regs_mask == (1 << 31), then that is not
	caught because of the signedness.

	We could fix this by changing the type to unsigned int, but that only
	guarantees 16 bits in the reg mask.  Intel CPUs with the APX extension support
	32 int registers.

	The implementation of amd64_get_unused_input_int_reg doesn't support analyzing
	registers with register number >= 8 yet, but now that we're changing the type,
	it seems like a good idea to anticipate this.

	Fix this by using uint32_t.

	Likewise, update the loop over the reg mask:
	...
	    for (i = 0; i < 8; ++i)
	      {
		if (! (used_regs_mask & (1 << i)))
		  return i;
	...
	to handle any used_regs_mask value rather than just those for
	register number < 8.

	Tested on x86_64-linux.

2025-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 1
	While reading amd64_get_unused_input_int_reg, I noticed that it first asserts,
	then throws an internal_error if no unused register can be found.

	Looking at the documentation of gdbarch_displaced_step_copy_insn, it seems
	that a failure can be indicated less abruptly, by returning a nullptr.

	Fix this by:
	- returning -1 in case of failure to find an unused register in
	  amd64_get_unused_input_int_reg, and
	- propagating this to amd64_displaced_step_copy_insn.

	Tested on x86_64-linux.

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	gas: leave expression symbols alone when processing equates
	PR gas/32721
	In this bogus piece of code distilled from fuzzing and slightly edited:

		A=%eax|%!
		Y=A
		Z=A
		or $6,Z

	the first of the equates with A on the rhs changes A's section (due to
	the use of S_GET_VALUE()), from expression to register, thus yielding Y
	in the expression section (and X_op being O_symbol), but Z in the
	register section (and X_op being O_register with X_add_value being -1).
	There shouldn't be random O_register expressions, though, for targets
	setting md_register_arithmetic to false. Plus both Y and Z would better
	be exchangeable.

	In pseudo_set() wire handling of O_symbol expressions referencing a
	symbol in the expression section to that of other stuff ending up in
	this section.

	Also avoid bogus O_register expressions to be created, for targets
	setting md_register_arithmetic to false: S_GET_VALUE() would resolve
	any arithmetic, which must not happen for such targets. To be on the
	safe side for such targets, also amend resolve_register(). Correct
	another earlier oversight there too (affecting at least Z80), by using
	the new expr_copy() helper there as well.

	Undo 46b9f07dfe79 ("PR 32721, internal error in
	tc-i386.c:parse_register"), albeit without losing the simplification it
	did.

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	v850: improve linker scripts for relocatable linking
	Quite a few constructs where unconditional when they should take
	$RELOCATING into account. The original observation was that output of
	"ld -r" had .text start at 0x00100000.

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	gas: fold is_end_of_line[] into lex_type[]
	... by way of introducing LEX_EOL and LEX_EOS. As a prereq convert the
	remaining open-coded accesses.

	The Alpha change is actually a functional one: The array slot for '!'
	having been set to 1 is very unlikely to have been correct. 1 means "end
	of line", when surely "end of statement" was always meant.

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	include: drop bout.h
	gas'es obj-bout.c was dropped about 20 years ago, while bfd's bout.c was
	dropped almost 7 years ago. Time for the unused header to go away, too.

	rl78: drop redundant statement separator check
	With the switch to the use of is_end_of_stmt() in 2dd0370c433d
	("rl78: use is_whitespace()") the open-coded checking against
	line_separator_chars[] can be dropped.

	Z8k: use is_end_of_stmt()
	... instead of open-coding it.

	x86: use is_end_of_stmt()
	... instead of open-coding it.

	VAX: use is_end_of_stmt()
	... instead of open-coding it. This also fixes two array underrun
	issues, when plain char is a signed type.

	TILEPro: use is_end_of_stmt()
	... instead of open-coding it. Also convert a variable to plain char
	(allowing to drop two casts), which is how it's actually used.

	Tile-Gx: use is_end_of_stmt()
	... instead of open-coding it. Also convert a variable to plain char
	(allowing to drop two casts), which is how it's actually used.

	C6x: use is_end_of_stmt()
	... instead of open-coding it.

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	C54x: use is_end_of_stmt()
	... instead of open-coding it.

	In tic54x_stringer() this also fixes an array overrun issue: Converting
	plain char to unsigned int could have yielded huge values when plain
	char is a signed type.

	In subsym_substitute() also convert a local variable to plain char, as
	that's what it's really holding (and how it's used everywhere else).

2025-03-07  Jan Beulich  <jbeulich@suse.com>

	C4x: use is_end_of_stmt()
	... instead of open-coding it.

	C30: use is_end_of_stmt()
	... instead of open-coding it.

	Sparc: use is_end_of_stmt()
	... instead of open-coding it. This also fixes two array underrun
	issues, when plain char is a signed type.

	SH: use is_end_of_stmt()
	... instead of open-coding it.

	Score: use is_end_of_stmt()
	... instead of open-coding it.

	RISC-V: use is_end_of_stmt()
	... instead of open-coding it.

	pru: use is_end_of_stmt()
	... instead of open-coding it.

	PPC: use is_end_of_stmt()
	... instead of open-coding it.

	MMIX: use is_end_of_stmt()
	... instead of open-coding it.

	MIPS: use is_end_of_stmt()
	... instead of open-coding it.

	MicroBlaze: use is_end_of_stmt()
	... instead of open-coding it.

	M68k: use is_end_of_stmt()
	... instead of open-coding it.

	M68HC1x: use is_end_of_stmt()
	... instead of open-coding it. With this there's no need for op_end (and
	hence op_start) to be other than pointer to plain char. Which in turn
	eliminates the need for several questionable casts.

	IQ2000: use is_end_of_stmt()
	... instead of open-coding it.

	LoongArch: use is_end_of_stmt()
	... instead of open-coding it.

	HP-PA: use is_end_of_stmt()
	... instead of open-coding it.

	dlx: use is_end_of_stmt()
	... instead of open-coding it.

	C-Sky: use is_end_of_stmt()
	... instead of open-coding it.

	cris: use is_end_of_stmt()
	Fix use of is_end_of_line[] directly instead of through the
	is_end_of_stmt() macro.

	aarch64: use is_end_of_stmt()
	... instead of open-coding it.

	Arm: use is_end_of_stmt()
	... instead of open-coding it. This also fixes an array underrun issue:
	The wrong casting to plain int could have yielded negative values when
	plain char is a signed type.

	Alpha: use is_end_of_stmt()
	... instead of open-coding it. Note that writes to the array need to be
	left alone; they can only be converted when the array is folded into
	lex_type[].

	Mach-O: use is_end_of_stmt()
	... instead of open-coding it.

	ELF: use is_end_of_stmt()
	... instead of open-coding it.

	{,E}COFF: use is_end_of_stmt()
	... instead of open-coding it. Convert a variable's type to plain char
	then as well, as that's what it's really holding (and how it's used
	everywhere else).

2025-03-07  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Update PR gprof/32764 test
	1. Remove gmon.out first before generating it in the configure check.
	2. Make tst-gmon-gprof.out depend on the gprof binary.
	3. Check that gmon.out is non-empty.
	4. Don't include <sys/cdefs.h> in tst-gmon.c.

		PR gprof/32764
		* configure.ac: Remove gmon.out first.
		* configure: Regenerated.
		* testsuite/Makefile.am (tst-gmon-gprof.out): Depend on
		$(GPROF).
		* testsuite/Makefile.in: Regenerated.
		* testsuite/tst-gmon-gprof.sh: Check that gmon.out is non-empty.
		* testsuite/tst-gmon.c: Don't include <sys/cdefs.h>.

2025-03-07  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1
	I got an request about the undefined behaviors, considering the following case,

	$ cat test.c
	void main ()
	{
	  foo();
	}
	$ cat lib.h
	void foo(void);
	$ riscv64-unknown-linux-gnu-gcc test.c
	riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main':
	test.c:(.text+0x8): undefined reference to `foo'
	collect2: error: ld returned 1 exit status
	$ riscv64-unknown-linux-gnu-gcc test.c -Wl,--unresolved-symbols=ignore-in-object-files
	$ qemu-riscv64 a.out
	Segmentation fault (core dumped)

	Testing with x86 and aarch64, they won't get the segfault since they go plt
	for the undefined foo symbol.  So, after applying this patch, I can get the
	following too,

	$ qemu-riscv64 a.out
	a.out: symbol lookup error: a.out: undefined symbol: foo

	The change of this patch should only affect the call behavior, which refer
	to an undefined (weak) symbol, when building an dynamic executable.  I think
	the pic/pie behavior won't be affected as usual.

2025-03-07  H.J. Lu  <hjl.tools@gmail.com>

	gprof: Copy a simple test from glibc
	Copy a simple gprof test from glibc to test the basic gprof functionality.

	1. Tested natively on Linux/x86-64 and Linux/i686.
	2. Tested for the x86_64-solaris cross target without cross-compiler.
	3. Tested for the aarch64-linux-gnu cross target with cross-compiler.

		PR gprof/32764
		* Makefile.am (SUBDIRS): Add testsuite
		* configure.ac (AC_CONFIG_FILES): Removed.
		(AC_OUTPUT): Add Makefile testsuite/Makefile
		po/Makefile.in:po/Make-in.
		(AM_CONDITIONAL): Add NATIVE.
		* Makefile.in: Regenerated.
		* configure: Likewise.
		* testsuite/Makefile.am: New file.
		* testsuite/tst-gmon-gprof.sh: Likewise.
		* testsuite/tst-gmon.c: Likewise.
		* testsuite/Makefile.in: Generated.

2025-03-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-06  Alan Modra  <amodra@gmail.com>

	Re: ld: Add a test for PR ld/25237
	Delete the test.  It doesn't make sense to check a linker hack for
	a meaningless p_offset.

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix typos in NEWS
	Fix typos:
	...
	mainenance ==> maintenance
	epilgoue ==> epilogue
	commnds ==> commands
	readibility ==> readability
	informations ==> information
	throwed ==> threw
	compiletime ==> compile time
	namepace ==> namespace
	reqired ==> required
	explicity ==> explicitly
	reqired ==> required
	...

	[gdb/python] Fix typos
	Fix typos:
	...
	gdb/python/py-framefilter.c:749: indention ==> indentation
	gdb/python/py-framefilter.c:837: indention ==> indentation
	gdb/python/py-lazy-string.c:35: sting ==> string
	gdb/python/py-progspace.c:119: Retun ==> Return
	gdb/python/py-progspace.c:139: Retun ==> Return
	...

	[gdb/python] Fix typos in lib
	Fix typos:
	...
	gdb/python/lib/gdb/disassembler.py:84: dissables ==> disables
	gdb/python/lib/gdb/command/xmethods.py:40: experession ==> expression
	...

	[gdb/guile] Fix typos
	Fix typos:
	...
	gdb/guile/scm-lazy-string.c:41: sting ==> string
	gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy
	...

	[gdb/doc] Fix typos in gdb.texinfo
	Fix typos:
	...
	preprend -> prepend
	wth -> with
	Connnections -> Connections
	...

	[gdb/doc] Fix typos in annotate.texinfo
	Fix typos:
	...
	Dependant ==> Dependent
	...

	[gdb/doc] Fix typos in python.texi
	Fix typos:
	...
	atribute ==> attribute
	...

	[gdb/nat] Fix typos
	Fix typos:
	...
	exising ==> existing
	afer ==> after
	...

	[gdb/tui] Fix typos
	Fix typos:
	...
	gdb/tui/tui.c:64: releated ==> related
	gdb/tui/tui-io.c:50: releated ==> related
	...

	[gdb/cli] Fix typos
	Fix typos:
	...
	gdb/cli/cli-utils.h:85: fuction ==> function
	gdb/cli/cli-decode.c:2457: Ambigous ==> Ambiguous
	...

	[gdb] Fix typos in gdbarch_components.py
	Fix typos in gdbarch_components.py:
	...
	tranformations ==> transformations
	charater ==> character
	Noe -> Note
	...
	and regenerate gdb/gdbarch-gen.h.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Update ada_add_block_renamings for compiler changes
	With the hierarchical name patches to GNAT, ada_add_block_renamings
	must now be updated as well -- the comment there about the supported
	forms of DW_TAG_imported_declaration is no longer correct, and now
	full names must sometimes be constructed during the lookup process.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Add support for hierarchical Ada names
	In the near future, GNAT will start emitting DWARF names in a more
	standard way -- specifically, the package structure will be indicated
	by nested DW_TAG_module DIEs and a given entity will be nested in its
	package and only have a simple name.

	This patch changes gdb to understand this style of naming, while still
	supporting the existing GNAT output.

	A few special cases are needed.  I've commented them.

	The name-computing code for the full DWARF reader is very complicated
	-- much too complicated, in my opinion.  There are already several
	bugs in bugzilla about this (search for "physname"... but there are
	others as well), so I haven't filed any new ones.

	When I started this project, I thought it would solve some memory
	overuse issues we sometimes see from how the index-sharding code
	interacts with the GNAT-specific post-pass.  However, to my surprise,
	the Ada code in gdb relies on some details of symbol naming, and so
	I've had to add code here to synthesize "linkage" names in some cases.
	This is unfortunate, but I think can eventually be fixed; I will file
	a bug to track this issue.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Add "Ada linkage" mode to cooked_index_entry::full_name
	Unfortunately, due to some details of how the Ada support in gdb
	currently works, the DWARF reader will still have to synthesize some
	"full name" entries after the cooked index has been constructed.

	You can see one particular finding related to this in:

	    https://sourceware.org/bugzilla/show_bug.cgi?id=32142

	This patch adds a new flag to cooked_index_entry::full_name to enable
	the construction of these names.

	I hope to redo this part of the Ada support eventually, so that this
	code can be removed and the full-name entries simply not created.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Store new Ada entries in cooked_index_shard::m_entries
	handle_gnat_encoded_entry might create synthetic cooked index entries
	for Ada packages.  These aren't currently kept in m_entries, but it
	seems to me that they should be, particularly because a forthcoming
	GNAT will emit explicit DW_TAG_module for these names -- with this
	change, the indexes will be roughly equivalent regardless of which
	compiler was used.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Handle DW_TAG_module for Ada
	This updates read_module_type to turn DW_TAG_module into a
	TYPE_CODE_NAMESPACE when the CU represents Ada code.

	Note that the GNAT that generates this isn't generally available yet
	and so this shouldn't have an impact on current code.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Add "synthetic" marker for index entries
	Currently, gdb will synthesize DW_TAG_module entries for Ada names.
	These entries are treated specially by the index writer,

	When GNAT starts emitting DW_TAG_module, the special case will be
	incorrect, because there will be non-synthetic DW_TAG_module entries
	in the index.

	This patch arranges to mark the synthetic entries and changes the
	index writer to follow.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Use DW_TAG_module for Ada
	In GCC we decided to use DW_TAG_module to represent Ada packages, so
	make this same decision in gdb.  This also updates tag_matches_domain
	to handle this case.

	Use dwarf2_full_name when computing type names
	This changes a few spots in the DWARF reader to use dwarf2_full_name
	when computing the name of a type.  This gives the correct name when a
	type is nested in a namespace.  This oddity probably wasn't noticed
	before because some of the types in question are either normally
	anonymous in C++ (e.g, array type) or do not appear in a namespace
	(base type).

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Compare unqualified names in ada_identical_enum_types_p
	With the coming changes to GNAT, gdb must compare the unqualified
	names of two enum types.

	Currently, GNAT will fully-qualify enumeration constant names, so for
	instance one might see "enum_with_gap__lit4" as the name.

	GNAT also may emit a copy of an enumeration type when a newtype is
	involved.  E.g., in the arr_acc_idx_w_gap.exp test case, this can
	occur for the base type of this subtype:

	   type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3;

	(Note that the base type of this subrange is anonymous.)

	With some forthcoming changes to GNAT, these names will no longer be
	qualified -- and because the newtype is anonymous, they can't be
	identically qualified.  But, in gdb we still want "lit4" to resolve
	without ambiguity in this scenario.

	The fix is to change ada_identical_enum_types_p to compare unqualified
	enum names.  This will work correctly with both variants of the
	compiler, and with -fgnat-encodings=all as well.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Use ada_identical_enum_types_p in ada_atr_enum_rep
	With the coming changes to GNAT, we may see two distinct but
	equivalent enum types in the DWARF.  In this case, it's better to use
	ada_identical_enum_types_p rather than types_equal when comparing
	these types... something that matters when using 'Enum_Rep.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Fixes to gdb.ada/fun_overload_menu.exp
	This patch applies a few fixes to gdb.ada/fun_overload_menu.exp.

	It adds some comments to the source and uses this to extract line
	numbers.  This is used to ensure that two otherwise-equivalent results
	are in fact different, so that the test really checks that the result
	is correct.

	It also changes the test_menu proc to accept a list of possible
	results.  This lets the test work regardless of the order in which the
	menu items are presented by gdb.

	Finally, like an earlier patch, it changes the test to optionally
	accept unqualified names from gdb.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Allow multiple locations in homonym.exp
	With some forthcoming changes to GNAT, the two Get_Value functions in
	this test case will end up with the same name (with the current GNAT,
	one ends up with a "__2" suffix).  This change will cause one test to
	set multiple breakpoints; this patch changes the test to work with
	either version of the compiler.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Fix type name in ptype-o.exp
	The "Rec" type in ptype-o.exp is currently named "prog__rec" by the
	compiler.  However, with my changes to GNAT, the type will no longer
	have a prefix, as it is local to a procedure.

	Changing this to just use "rec" works fine with the new compiler, but
	then fails with older compilers.  To allow correct operation with both
	compilers, this patch simply moves the type into a new package.  This
	doesn't affect the meaning of the test, which is just ensuring that
	ptype/o works in a certain case.

	Note that the more obvious fix of just using "ptype/o rec" does not
	work with the current GNAT.  I haven't investigated this but I did
	file a bug to track it:

	    https://sourceware.org/bugzilla/show_bug.cgi?id=32169

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Allow unqualified names in Ada tests
	Currently, when a type is declared in a subprogram that isn't part of
	a package, gdb will give this type a qualified name.  E.g., in the
	program for gdb.ada/arr_arr.exp:

	    procedure Foo is
	       type Array2_First is array (24 .. 26) of Integer;

	gdb will name this type 'foo.array2_first'.

	However, with some coming changes to GNAT (and with the remainder of
	this series applied as well), this will no longer happen.  Instead,
	such types will be given their local name.  IMO this makes more sense
	anyway.

	This patch updates most of the Ada tests to allow either form in the
	spots where it matters.  Both are accepted so that the tests continue
	to work with older versions of GNAT.  (A few tests are handled in
	separate patches; this patch only contains the straightforward
	changes.)

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Fix latent crash in ada_variant_discrim_name
	ada_variant_discrim_name does this:

	  for (discrim_end = name + strlen (name) - 6; discrim_end != name;

	If NAME is too short, this will construct an invalid pointer, perhaps
	causing a crash.

	This patch arranges to check the length first.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Allow for anonymous Ada enumeration types
	With some forthcoming changes to GNAT, gdb might see a nameless enum
	in ada_resolve_enum, causing a crash.  This patch allows an anonymous
	enum type to be considered identical to a named type when the contents
	are identical.

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Add a quit to maint_print_all_sections
	If you have many sections, "maint print sections" can take a very long
	time (due to a bug).  If you happen to "c" at the pagination prompt,
	this can't be interrupted.  This patch adds a QUIT to the loop to at
	least allow interruption.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdbserver] Drop abbreviations in gdbserver/xtensa-xtregs.cc
	In gdbserver/xtensa-xtregs.cc, there's a table:
	...
	const xtensa_regtable_t  xtensa_regmap_table[] = {
	  /* gnum,gofs,cpofs,ofs,siz,cp, dbnum,  name */
	  {   44, 176,   0,   0,  4, -1, 0x020c, "scompare1" },
	  { 0 }
	};
	...
	on which codespell triggers:
	...
	$ codespell --config ./gdbserver/setup.cfg gdbserver
	gdbserver/xtensa-xtregs.cc:34: siz ==> size, six
	...

	Fix this by laying out the table in vertical fashion, and using the full field
	names instead of the abbreviations ("size" instead of "siz", "offset" instead
	of "ofs", etc).

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Use 'const' in some gdbarch methods
	This changes a couple of gdbarch methods to use 'const' for an
	"asymbol *" parameter.  These methods shouldn't be modifying the
	underlying symbol in the BFD.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdbserver] Add codespell section in setup.cfg
	Add a codespell section in new config file gdbserver/setup.cfg, similar to the
	one in gdbsupport/setup.cfg.

	There's just one item left:
	...
	$ codespell --config ./gdbserver/setup.cfg gdbserver
	gdbserver/xtensa-xtregs.cc:34: siz ==> size, six
	...

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary `this->` in read.c
	I like using `this->` when it's unclear that the method or field
	accessed is within the current class, but when accessing a private
	member prefixed with `m_`, it's unnecessary, as the prefix makes it
	clear.  Remove some instances of it (some coming from the previous
	patch, other pre-existing) to de-clutter the code a bit.

	Change-Id: Ia83d0bce51d222fa3ac3d756d50170ec6ed12b94
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make all fields of cutu_reader private
	Make all fields of cutu_reader private, then add getters for whatever
	needs to be accessed outside of cutu_reader.  This should help spot
	what's used by cutu_reader itself, and what is used by others.

	Change-Id: I71cb73fffa5d70cc9c7fc68bf74db937e84c2db1
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: pass dwarf2_cu instead of cutu_reader to two functions
	These functions don't need to receive a cutu_reader, they only use it to
	obtain the contained dwarf2_cu, so change them to accept a dwarf2_cu.
	This helps reduce the creep of cutu_reader a little bit.

	Change-Id: Iebb3c4697a4aec638b47423b3ac59077d4fa5090
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: move a bunch of DIE-reading functions to cutu_reader
	With the hope of organizing things better and spotting patterns that
	could lead to simplification, move all these functions to be methods of
	cutu_reader.  At least, this gives a good picture of what the entry
	points for DIE and attribute reading are, by looking at what methods are
	public.

	Right now, my vague understanding of cutu_reader is that it does 3
	things:

	 - it provides means to navigate and read the DIE tree, abstracting
	   things like whether the real content is in a DWO file or not
	 - it builds a dwarf2_cu object, for its own use but also for the use of
	   the caller
	 - it fills in missing details in the passed in dwarf2_per_cu

	In the future, I'd like to separate those concerns.  I think that
	cutu_reader could retain the first one of those concerns, while the
	other two could be done by other classes or functions, perhaps using
	cutu_reader under the hood.

	Change-Id: I04e0d6c864bbc09c7071ac8e9493e1e54c093d68
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: add empty lines in cutu_reader::read_cutu_die_from_dwo comment
	I find it much more readable this way, with one idea per paragraph.

	Change-Id: Ib31b410867c8444e0f3200681881f54f1b8ebea8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make init_cu_die_reader a method of cutu_reader
	init_cu_die_reader is only used inside cutu_reader, to initialize fields
	of cutu_reader, so make it a private method.

	Change-Id: Iaa80d4dbb8d0fa35bcac18ee70e147276874cc1b
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make read_cutu_die_from_dwo a method of cutu_reader
	read_cutu_die_from_dwo is only used as a helper to cutu_reader, so make
	it a private method of cutu_reader.

	Remove the "result_reader" parameter, because it's always "this".

	Change-Id: I7df6162137451c160f0e6bf3539569fcb2421eff
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Add codespell section in setup.cfg
	When running codespell on gdbsupport, we get:
	...
	$ codespell gdbsupport
	gdbsupport/common-debug.h:218: invokable ==> invocable
	gdbsupport/osabi.h:51: configury ==> configurable
	gdbsupport/ChangeLog-2020-2021:344: ro ==> to, row, rob, rod, roe, rot
	gdbsupport/ChangeLog-2020-2021:356: contaning ==> containing
	gdbsupport/common.m4:19: configury ==> configurable
	gdbsupport/Makefile.am:97: configury ==> configurable
	gdbsupport/Makefile.in:811: configury ==> configurable
	gdbsupport/event-loop.cc:84: useable ==> usable
	gdbsupport/configure:15904: assigment ==> assignment
	...

	Some of these files we want to skip in a spell check, because they're
	generated.  We also want to skip ChangeLogs, we don't actively maintain those.

	Add a file gdbsupport/setup.cfg with a codespell section, that skips those
	files.  The choice for setup.cfg (rather than say .codespellrc) comes from the
	presence of gdb/setup.cfg.

	That leaves invokable, configury and useable.  I think configury is a common
	expression in our context, and for invokable and useable I don't manage to
	find out whether they really need rewriting, so I'd rather leave them alone
	for now.

	Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in
	gdbsupport/setup.cfg.

	This makes the directory codespell clean:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport
	$
	...

	Because codespell seems to interpret filenames relative to the working
	directory rather than relative to the config file, and the filename used in
	gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple
	invocation doesn't work:
	...
	$ cd gdbsupport
	$ codespell
	...
	because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt.

	We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but
	likewise that breaks this invocation:
	...
	$ codespell --config gdbsupport/setup.cfg gdbsupport
	...

	I can't decide which one is worse, so I'm sticking with
	gdb/contrib/codespell-ignore-words.txt for now.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary local variable in pager_file::puts
	The lineptr variable isn't really necessary, we can just keep using
	linebuffer, since the original value is linebuffer isn't needed.  Remove
	lineptr, and fix some comparisons to be explicit.

	Change-Id: If2f7df43bf79efd40149e46d5c77f9bc0439f879
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdbserver] Fix some typos
	Fix typos in gdbserver:
	...
	gdbreplay.cc:444: substract ==> subtract
	notif.cc:35: Enque ==> Enqueue
	notif.cc:42: enque ==> enqueue
	i387-fp.cc:233: simplifed ==> simplified
	i387-fp.cc:508: simplifed ==> simplified
	linux-arc-low.cc:221: shoudn't ==> shouldn't
	linux-sparc-low.cc:112: ans ==> and
	linux-ppc-low.cc:1134: Followings ==> Following
	linux-ppc-low.cc:1160: Followings ==> Following
	linux-ppc-low.cc:1193: Followings ==> Following
	linux-ppc-low.cc:1226: Followings ==> Following
	configure.ac:141: defintions ==> definitions
	...

	Regenerate configure from configure.ac using autoconf.

2025-03-06  Tom Tromey  <tom@tromey.com>

	Use "::" as separator for Fortran in cooked index
	This teaches cooked_index_entry::full_name that "::" is the separator
	for Fortran.  I don't know enough Fortran to write a test case for
	this.  However, a different series I am working on has a regression if
	this patch is not applied.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-06  Tom Tromey  <tromey@adacore.com>

	Avoid double-decoding in ada_add_global_exceptions
	I noticed that ada_add_global_exceptions calls ada_decode on
	'search_name' -- and then passes this to name_matches_regex, which
	also calls ada_decode.

	name_matches_regex is also used later, where the result of
	'natural_name ()' is passed to it -- but natural_name also calls
	ada_decode.

	So, I think the call to ada_decode in name_matches_regex is redundant.
	This patch removes it, and turns name_matches_regex into an inner
	function to avoid propagating its use.

	Note that, right now, the DWARF implementation of
	expand_symtabs_matching does not in fact pass an encoded name to this
	callback.  So, this code remains slightly (but currently harmlessly)
	wrong.  expand_symtabs_matching is fixed by another pending series of
	mine.

2025-03-06  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Fix some typos
	Fix typos:
	...
	mentionning -> mentioning
	suppported -> supported
	aligment -> alignment
	...

	[gdb] Fix typos in some selftests
	Fix typos:
	...
	figured on out -> figured one out
	fpr -> for
	hopefuly -> hopefully
	...

2025-03-06  H.J. Lu  <hjl.tools@gmail.com>

	Revert "gprof: only process line numbers for intersection of vmas and histograms"
	This reverts commit b8189cf9e40bd90502c9a2ce0df39dd54419bea4 to fix
	PR gprof/32764:

	https://sourceware.org/bugzilla/show_bug.cgi?id=32764

2025-03-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-05  H.J. Lu  <hjl.tools@gmail.com>

	ld: Update PR ld/25237 test
	1. Skip targets which don't support the .bss section alignment, 1 << 16.
	2. Replace .bss with ".section .bss".
	3. Use ".zero 0xb60000" for targets which pad the section to its alignment.

		PR ld/25237
		* testsuite/ld-elf/pr25237.d: Skip avr-*-* and h8300-*-*.
		Update expected segment size to 0xb60000.
		* testsuite/ld-elf/pr25237.s: Use ".section .bss" and
		".zero 0xb60000".

2025-03-05  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: add test for memory requirements of gcore
	For a long time, Fedora has been carrying an out-of-tree patch with a
	similar test to the one proposed in this patch, that ensures that the
	memory requirements don't grow with the inferior's memory. It's been
	so long that the context for why this test exists has been lost, but
	it looked like it could be interesting for upstream.

	The test runs twice, once with the inferior allocating 4Mb of memory,
	and the other allocating 64Mb. My plan was to find the rate at which
	things increase based on inferior size, and have that tested to ensure
	we're not growing that requirement accidentally, but my testing
	actually showed memory requirements going down as the inferior increases,
	so instead I just hardcoded that we need less than 2Mb for the command,
	and it can be tweaked later if necessary.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: do not handle a NULL linebuffer in pager_file::puts
	This patch [1] has shown that different implementations of ui_file::puts
	handle a NULL line differently.  pager_file::puts handles a NULL
	argument gracefully, as a no-op, while other implementations don't and
	likely crash.  This causes subtle bugs: things will be working until the
	current ui_file is suddenly not a pager_file anymore.  I think it would
	be better to be consistent here, so change pager_file::puts to not
	accept a NULL line.

	A regular test run on Linux shows no regression.

	[1] https://inbox.sourceware.org/gdb-patches/edfe6e17-1c20-4a4c-944f-247ff71b6c10@simark.ca/T/#m864aea10de8ca6fa84757971fcbaf3180e2eaefa

	Change-Id: Ieb465c86cd2c42a248cf481cd174c8622ef6724b
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Tom Tromey  <tom@tromey.com>

	Inconsistent treatment of template parameters in DWARF reader
	I noticed that if you hack some clean_restart calls into
	paramless.exp, the test will fail.  That is, the test currently relies
	on the desired CUs already being expanded when trying to set a
	breakpoint -- which is clearly a bug, the CU expansion state should
	not affect "break".

	I tracked this down to incorrect construction of a lookup_name_info in
	cooked_index_functions::expand_symtabs_matching.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: store dwo_file_up in dwo_file_set
	Heap-allocated dwo_file objects, stored in dwarf2_per_bfd::dwo_files,
	are never freed.  They are created in one of the
	create_dwo_unit_in_dwp_* or lookup_dwo_cutu functions.  I confirmed this
	by running:

	  $ make check TESTS="gdb.cp/anon-ns.exp" RUNTESTFLAGS="--target_board=fission-dwp"
	  $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.cp/anon-ns/anon-ns -ex "p main" -ex "file" -batch

	... and checking the ASan leak report.  I also debugged this invocation
	of GDB, placed a breakpoint on ~dwo_file, and didn't see any hit.

	Change the dwo_file set to hold dwo_file_up objects.  When the
	dwarf2_per_bfd object gets destroyed, dwo_file objects will
	automatically get destroyed.  With this change, I see the related leaks
	disappear in the ASan leak report, and my ~dwo_file breakpoint gets hit
	when debugging GDB.

	Change-Id: Icb38539c3f9e553f3625c625a00fc63dd6e9f3c5
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make dwarf2_per_bfd::dwo_files a gdb::unordered_set
	Change the dwarf2_per_bfd::dwo_files htab to a gdb::unordered_set.

	No behavior change expected, except maybe the failure case in
	lookup_dwo_cutu.  If open_and_init_dwo_file returns nullptr, the
	previous code would leave the slot value empty (nullptr).  Is this
	legit?  With the new hash table, the only thing we can do really is not
	attempt to insert the nullptr value.

	Change-Id: I63992f388b1197e696ded4ea483634e8ae67fce4
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: change htabs holding dwo_unit objects to gdb::unordered_set
	Change a few occurences of htabs holding `dwo_unit *` values, using
	their signature as identity, to gdb::unordered_set.
	allocate_dwo_unit_table and allocate_dwp_loaded_cutus_table appeared to
	create hash tables with identical behavior, so they both use the same
	set type now.

	The only expected change in behavior is that when there are multiple
	units with the same signature, we will now keep the unit previously in
	the set, rather than overwriting it.  But this seems ok, as it's a case
	of bad DWARF.

	Also, in the complaint in create_debug_type_hash_table, I think we
	previously erroneously printed the same sect_off twice.

	Change-Id: I57739977735ee1fd5c7b754107f5624f0621baa5
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unused local variable in create_debug_type_hash_table
	Change-Id: I40679fbe32a8a1a9cced085532c83f06affc294c
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: remove unnecessary parameters to create_{cus,debug_type}_hash_table
	In create_cus_hash_table, we can get the section and hash table from the
	dwo_file directly.

	In create_debug_type_hash_table, we can get the hash table from the
	dwo_file directly - the section varies.

	Change-Id: I1d5ef49df98fe2620e12b83484b28cd7398f24ae
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove die_reader_specs
	die_reader_specs is a relic of some past design, today it only serves as
	(useless) a base class for cutu_reader.  Remove it and move all its
	fields to cutu_reader.

	Change-Id: I5d55018eb8c6e0b828ef5d2f6d09b2047d1a5912
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary parameter of create_cus_hash_table
	We can use `cu->per_objfile` instead of passing down a
	dwarf2_per_objfile explicitly.

	Change-Id: Ie1fd93d9e7a74d09b857f1f0909d7441b79ed893
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary local variable in dw2_get_file_names_reader
	It seems like the lh_cu variable is not necessary, we can just use
	this_cu.

	Change-Id: Ic2ed6ee82faf1fb5d340cd92dc8ef15434b20cb8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-05  Daniel Starke  <daniel-email@gmx.net>

	gdb: fix null pointer dereference on missing PATH variable
	When running "show" with missing PATH variable a null pointer is being
	dereferenced in path_info().

	path_command() correctly checks whether PATH has been set before using it.
	It then calls path_info() which retrieves the variable again but fails to
	perform the null pointer test on it. As a result, the application crashes with
	SIGSEGV on Windows for example.

	Fix this by handling the null pointer case in path_info() accordingly.

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I41ef10f00802d3163793491454190008e78f5dc1

2025-03-05  Tom Tromey  <tom@tromey.com>

	Create dwarf2/parent-map.c
	This creates a new file, dwarf2/parent-map.c, to hold some code
	related to parent maps.  This helps shrink read.c a bit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-05  Tom Tromey  <tom@tromey.com>

	Dump debug names index
	This changes the .debug_names reader to dump the contents of the
	index.  This follows what the cooked index does, and also fixes a
	couple of test failures when run with the debug-names board:
	forward-spec-inter-cu.exp and backward-spec-inter-cu.exp.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-03-05  Nick Clifton  <nickc@redhat.com>

	elfxx-aarch64.c: Replace nested function with a static inline version instead.

2025-03-05  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add a test for PR ld/25237
		PR ld/25237
		* testsuite/ld-elf/pr25237.d: New file.
		* testsuite/ld-elf/pr25237.s: Likewise.

2025-03-05  H.J. Lu  <hjl.tools@gmail.com>

	ld: Pass -Wl,-z,lazy to compiler for i386 lazy binding tests
	Pass -Wl,-z,lazy to compiler for i386 tests which require lazy binding
	to support compilers which default to non-lazy binding.

		PR ld/32762
		* testsuite/ld-i386/i386.exp: Pass -Wl,-z,lazy for
		"Build ifunc-1a with PIE -z ibtplt" test.
		* testsuite/ld-i386/no-plt.exp: Pass -Wl,-z,lazy for
		"Build libno-plt-1b.so", "No PLT (dynamic 1a)",
		"No PLT (dynamic 1b)", "No PLT (dynamic 1c)",
		"No PLT (PIE 1e)", "No PLT (PIE 1f)", "No PLT (PIE 1g)" tests.

2025-03-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-04  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: pass is_dwz to dwarf2_per_cu constructor
	It is always known at construction time whether a dwarf2_per_cu is
	built to represent a unit from a dwz file or not, so pass that
	information through the constructor.

	Change-Id: I278c1894ed606451aad02e830085190bb724c473
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-04  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make dwarf2_get_dwz_file a method of dwarf2_per_bfd
	dwarf2_get_dwz_file looks more or less like a simple getter of
	dwarf2_per_bfd::dwz_file, so make it into a method.

	I typically avoid the `get_` prefix for getters, but that would conflict
	with the field name here.

	Change-Id: Idd0d5b1bd3813babf438b20aac514b19c77cfc18
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-04  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove create_cu_from_index_list
	I noticed that create_cu_from_index_list is only used in
	read-gdb-index.c, so I started by moving it there.  But given that this
	function is use at only one spot and doesn't do much, I opted to inline
	its code in the caller instead.

	Change-Id: Iebe0dc20d345fa70a2f11aa9ff1a04fe26a31407
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-04  Tom Tromey  <tromey@adacore.com>

	Check whether gnatmake can link with -shared
	Currently, gnat-llvm does not ship a shared libgnat.  This patch
	changes the relevant test to check whether linking with -shared
	actually works.

	Check whether gnatmake supports -Og
	gnat-llvm does not support the -Og flag.  This arranges to check for
	this flag before using it.

2025-03-04  Tom Tromey  <tromey@adacore.com>

	Look for -fgnat-encodings option
	gnat-llvm does not support the -fgnat-encodings option, and does not
	emit GNAT encodings at all -- it only supports the equivalent of GCC's
	"minimal" encodings; which is to say, ordinary DWARF.

	This patch changes gdb to test whether gnatmake supports this flag and
	adapt accordingly.  foreach_gnat_encoding is changed to pretend that
	the "minimal" mode is in effect, as some test examine the mode.

2025-03-04  Tom Tromey  <tromey@adacore.com>

	Check -fvar-tracking via ada_simple_compile
	A couple of Ada tests check whether the C compiler supports
	-fvar-tracking.  However, this doesn't really work when using
	gnat-llvm, because that will invoke clang under the hood.  This patch
	arranges to check gnatmake instead, which is more robust even when
	toolchains are mix-and-matched.

	Introduce ada_simple_compile
	This introduces ada_simple_compile, an Ada-specific analog of
	gdb_simple_compile.  gdb_compile_test is split into two procs to make
	this possible.  ada_simple_compile isn't used in this patch but will
	be by later patches in this series.

	Check for compiler support in scalar_storage.exp
	gnat-llvm does not currently handle Scalar_Storage_Order.  This patch
	changes the scalar_storage.exp test to check the compiler error
	messages and report "unsupported" in this case.  This way, the test
	ought to start working automatically if this feature is added to
	gnat-llvm.

2025-03-04  Matthieu Longo  <matthieu.longo@arm.com>

	refactoring elf_find_and_remove_property
	This refactoring focuses primarily on code readability and reuse.
	- Use the already defined _bfd_elf_find_property instead of another
	  raw for-loop.
	- Extract _bfd_elf_remove_property out of the function body.

	refactoring _bfd_elf_get_property
	- Extract _bfd_elf_find_property and _bfd_elf_insert_property from the
	  function's body to improve the code readability.
	- Export _bfd_elf_find_property's symbol as it will be used in a later
	  commit.

	refactoring bfd_linear_search_one_with_gnu_property
	- remove the definition of the search predicate outside of the for loop.
	- change the function's return type to struct to adopt a more functional
	  coding style.

2025-03-04  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: setup_gnu_properties only creates the notes section when none exists
	The creation of .note.gnu.property section should not be based on the
	presence of GNU properties, but rather on whether this section exits
	or not.
	However, there is one exception to this: PR23900 [1]. Old linkers were
	treating .note.gnu.property as a generic note section, so old objects
	might contain properties inside .note instead of .note.gnu.property. In
	this case, the section won't be detected but the properties are still
	parsed. So the absence of the .note.gnu.property section is necessary
	but not enough to create the section. The condition of the creation of
	the section has also to include the absence of GNU properties.

	[1] PR23900: https://sourceware.org/bugzilla/show_bug.cgi?id=23900

2025-03-04  Matthieu Longo  <matthieu.longo@arm.com>

	clean-up bfd/elf-attrs.c: move specific-code to parse object attributes v1 into a new function

	clean-up bfd: rename functions for object attributes v1

	clean-up aarch64: move the name of the build attributes section into include/elf/aarch64.h

	clean-up create_obj_attrs_section: comment about .gnu.attributes VS .gnu.build.attributes

	clean-up: move writing of build attributes section into a function
	- add obj_build_attributes to struct elf_backend_data similarly sframe.
	- new function _bfd_elf_write_section_build_attributes encapsulating the
	  writing of the build attributes section into a function.

2025-03-04  Matthieu Longo  <matthieu.longo@arm.com>

	clean-up readelf: simplify and flatten body of process_attributes
	- use find_section_by_type() instead of a for-loop.
	- reindent the whole function accordingly.
	- move declaration of variables nearer from their usage.
	- prune else branch by using a goto in the error case.

	diff --git a/binutils/readelf.c b/binutils/readelf.c
	index 6d3ec65a8a1..878012da8f0 100644
	--- a/binutils/readelf.c
	+++ b/binutils/readelf.c
	@@ -19268,42 +19268,32 @@ process_attributes (Filedata * filedata,
	                    unsigned char * (* display_pub_attribute) (unsigned char *, const unsigned char * const),
	                    unsigned char * (* display_proc_gnu_attribute) (unsigned char *, unsigned int, const unsigned char * const))
	 {
	-  Elf_Internal_Shdr * sect;
	-  unsigned i;
	-  bool res = true;
	-
	   /* Find the section header so that we get the size.  */
	-  for (i = 0, sect = filedata->section_headers;
	-       i < filedata->file_header.e_shnum;
	-       i++, sect++)
	-    {
	-      unsigned char * contents;
	-      unsigned char * p;
	+  Elf_Internal_Shdr * sect = find_section_by_type (filedata, proc_type);
	+  if (sect == NULL)
	+    sect = find_section_by_type (filedata, SHT_GNU_ATTRIBUTES);

	-      if (sect->sh_type != proc_type && sect->sh_type != SHT_GNU_ATTRIBUTES)
	-       continue;
	+  if (sect == NULL)
	+    /* No section, exit without error.  */
	+    return true;

	-      contents = (unsigned char *) get_data (NULL, filedata, sect->sh_offset, 1,
	-                                             sect->sh_size, _("attributes"));
	+  unsigned char * contents = (unsigned char *)
	+    get_data (NULL, filedata, sect->sh_offset, 1, sect->sh_size, _("attributes"));
	   if (contents == NULL)
	-       {
	-         res = false;
	-         continue;
	-       }
	+    return false;

	-      p = contents;
	+  bool res = true;
	+  unsigned char * p = contents;
	   /* The first character is the version of the attributes.
	      Currently only version 1, (aka 'A') is recognised here.  */
	   if (*p != 'A')
	     {
	       printf (_("Unknown attributes version '%c'(%d) - expecting 'A'\n"), *p, *p);
	       res = false;
	+      goto free_data;
	     }
	-      else
	-       {
	-         uint64_t section_len;

	-         section_len = sect->sh_size - 1;
	+  uint64_t section_len = sect->sh_size - 1;
	   p++;

	   while (section_len > 0)
	@@ -19456,10 +19446,9 @@ process_attributes (Filedata * filedata,
	            attr_len = 0;
	        }
	     }
	-       }

	+free_data:
	   free (contents);
	-    }

	   return res;
	 }

2025-03-04  Matthieu Longo  <matthieu.longo@arm.com>

	clean-up bfd/elf-attrs.c: change return type of uleb128_size to unsigned

	clean-up: fix conflicting symbol with unknown from bfd/elf-bfd.h

	clean-up: fix annoying spaces in binutils/readelf.c

	clean-up: fix annoying spaces in bfd/elf-bfd.h

2025-03-04  Tom Tromey  <tom@tromey.com>

	Display entry offset for .debug_names
	Since commit ad6dde5aaae ("gdb/dwarf: write offset to parent entry for
	DW_IDX_parent"), gdb now emits a .debug_names where the DW_IDX_parent
	attribute refers to the parent entry's offset -- previously, due to
	some confusion in the standard, gdb used the index of the parent's
	name table entry.

	This patch changes the .debug_names display code to display each
	entry's offset.  This makes it easy to refer from a DW_IDX_parent to
	the correct entry.

	The new output looks like this:

	[...]
	Symbol table:
	[  1] circular1: <0><1> DW_TAG_module DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x19> DW_IDX_GNU_language=19
	[...]
	[  6] found: <0x28><2> DW_TAG_subprogram DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x38> DW_IDX_GNU_language=19 DW_IDX_parent=<0x0>

	Here you can see that DW_IDX_parent=0 refers to "circular1: <0>".

2025-03-04  Tom Tromey  <tom@tromey.com>

	Obvious comment fix in cooked-index.h
	I noticed that cooked-index.h still refers to a vector of parent maps,
	but the code itself actually uses a parent_map here.

2025-03-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-03  Alan Modra  <amodra@gmail.com>

	ecoff: check result of stat
		* ecoff.c (_bfd_ecoff_write_armap): Don't use statbuf.st_mtime
		if stat call returns non-zero.  Use ARMAP_TIME_OFFSET rather
		than its expansion.

2025-03-03  Alan Modra  <amodra@gmail.com>

	objdump: is_same_section
	This fixes a deficiency in commit 660df28acfa1, which should have used
	the same logic as that in sym_ok.  Ideally both places would not
	compare section names, but it can be a little tricky to match a
	section in the real object file with a section in a debug file.
	Extend commit 39f0547e554d to use section name, vma and size.

		* objcopy (is_same_section): New function.
		(compare_symbols, sym_ok): Use it here.

2025-03-03  Alan Modra  <amodra@gmail.com>

	rescoff: ensure file is PE
	read_coff_rsrc makes one check on object file contents, the existence
	of a .rsrc section.  It doesn't check that the file is PE but blindly
	accesses bfd pe_data.  Fix that by adding the necessary checks.
	Also, the "resources nest too deep" error isn't an overrun, ie. the
	"address out of bounds" message isn't correct.  Fix that too.

	windres: delete function forward declaraions
	Most of these were not needed, and moving a few functions around
	removes the need for any.

2025-03-03  Alan Modra  <amodra@gmail.com>

	Move BFD_FAKE_SECTION to libbfd.h
	BFD_FAKE_SECTION and its sidekick GLOBAL_SYM_INIT don't need to be
	cluttering bfd.h, and probably shouldn't be used outside bfd/.  To
	make them internal to bfd, make the bfd ecoff small common section
	declaration global so it can be used instead of a duplicate in
	gas/ecoff.c.  Oddly this needs to go in bfd/ecofflink.c rather than
	bfd/ecoff.c as the former is compiled for all targets needing the
	ecoff small common section (some via a call in gas/config/obj-elf.c to
	a function in gas/ecoff.c) while the latter is not.

	While doing this rename ecoff_scom_section to _bfd_ecoff_scom_section
	and remove support for traditional C from GLOBAL_SYM_INIT.

2025-03-03  Tom Tromey  <tom@tromey.com>

	Add language to type unit in debug-names-tu.exp.tcl
	I think debug-names-tu.exp.tcl only passes by accident -- the type
	unit does not have a language, which gdb essentially requires.

	This isn't noticeable right now because the type unit in question is
	expanded in one phase and then the symbol found in another.  However,
	I'm working on a series that would regress this.

	This patch partially fixes the problem by correcting the test case,
	adding the language to the TU.

	Hoewver, it then goes a bit further and arranges for this information
	not to be written to .debug_names.  Whether or not a type should be
	considered "static" seems like something that is purely internal to
	gdb, so this patch has the entry-creation function apply the
	appropriate transform.

	It also may make sense to change the "debug_names" proc in the test
	suite to process attributes more like the ordinary "cu" proc does.

2025-03-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unnecessary abfd parameter in dwarf2_per_bfd::locate_sections
	The parameter `abfd` is always the same as `this->obfd`, there is no
	need to pass it as a parameter.

	Change-Id: If7ad58ad4efdf6b070cbf2b8a73436bd8b452fa6
	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename dwarf2_per_cu_data -> dwarf2_per_cu
	This scratches an itch I had for a while.  I don't know why this struct
	type has "data" in its name.  Others like "dwarf2_per_objfile" and
	"dwarf2_per_bfd" don't.  The primary job of a structure is to hold data,
	there's no need to specify it.  It also makes the name a bit shorter,
	which is always nice.

	Rename related types too.

	Change-Id: Ifb63195ff105809fc15b502f639c0bb4d18a675e
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-03-03  Simon Farre  <simon.farre.cx@gmail.com>

	Bploc should try to return full path
	Compilers often emit relative paths in the line number program,
	relative to the build directory for that compilation unit (if it's
	DWARF>=4 I think).

	Therefore use symtab->fullname() when not null as this seemingly
	has attempted path normalization for the symtab and only
	fall back on symtab->filename which will never be null if that fails.

	This has a much better UX. Applications may choose to expose
	this name as a clickable link to some file, at which point
	a non-normalized and non-absolute path would lead nowhere.

	When I wrote this feature the first time, I don't think this
	relative-to-cu-scheme was as prevalent in the output of gcc/clang
	for DWARF.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-03-03  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Indicate in which languages 'filename'::funcaddr works
	In the docs I read [1]:
	...
	In this section, we discuss operators that you can use in GDB expressions
	regardless of your programming language.

	    ...

	GDB supports these operators, in addition to those common to programming
	languages:

	    ‘::’ allows you to specify a variable in terms of the file or function
	    where it is defined. See Program Variables.
	...

	In fact, this is not supported in Ada:
	...
	(gdb) b *'foo.adb'::foo
	No file or function "foo.adb'".
	(gdb)
	...
	and likewise in a few other working languages.

	Fix this by making this restriction explicit.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

	PR gdb/32753
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32753

	[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Expressions.html

2025-03-03  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Fix address location with file prefix
	In the docs I read [1]:
	...
	Address locations indicate a specific program address.  They have the
	generalized form *address.

	funcaddr

	    An address of a function or procedure derived from its name.
	    ...

	'filename':funcaddr

	    Like funcaddr above, but also specifies the name of the source file
	    explicitly.  This is useful if the name of the function does not specify
	    the function unambiguously, e.g., if there are several functions with
	    identical names in different source files.
	...

	This is incorrect, the notation is in fact 'filename'::funcaddr.

	Fix this by correcting the typo, and add a reference to "variable name
	conflict", where the concept is explained in more detail.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

	PR gdb/32748
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32748

	[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html

2025-03-03  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Don't advertise *&function for pascal and modula-2
	In the docs I read [1]:
	...
	Address locations indicate a specific program address.  They have the
	generalized form *address.

	  ...

	funcaddr

	    An address of a function or procedure derived from its name.
	    ...
	    In Pascal and Modula-2, this is &function.
	...

	I tried "break *&function" for Pascal and Modula-2, and this doesn't work,
	while "break *function" works fine.

	Fix this by updating the documentation to reflect actual behaviour.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

	PR gdb/32754
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32754

	[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html

2025-03-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove some unused includes from printcmd.c
	clangd reports them as unused.

	Change-Id: I50a3c13db128ffe1630364f707d66a24ce11d352

2025-03-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused include from frame.c
	clangd reports it as unused.

	Change-Id: I636e57747d3c42ce6615a14d4cf5dc115628a73d

2025-03-03  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Support ssqosid extension with version 1.0.
	It only add one new CSR: `srmcfg`.

	Ref: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0

2025-03-03  Andrew Oates  <andrew@andrewoates.com>

	RISC-V: Re-define mapping symbol $x to the file elf architecture attribute
	The mapping symbol "$x" without an ISA string "means using ISA
	configuration from ELF attribute."[1].  Currently the code does not
	reset the subset_list.  This means that a previous mapping symbol that
	overrides the ISA string will continue to be used, rather than the
	default string set in the ELF file's .riscv.attributes section.  This
	can cause incorrect or failed instruction decodings.

	In practice, this causes problems when disassembling code generated by
	LLVM, which (unlike gas) does not emit explicit mapping symbols at the
	start of each section.

	This change stores the default architecture string seen at the beginning
	of disassembly in the global parse data struct, and restores that to
	subset_list whenever a bare "$x" symbol is seen.

	[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol

	Before this patch, the mapping-x.s was dumped as,

	00000000 <.text>:
	   0:	00000013          	nop
	   4:	0001                	.insn	2, 0x0001
	   6:	0001                	.insn	2, 0x0001

	Which is caused by the definiation of $x was conflict with the psABI.

2025-03-03  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Stop generating mapping symbol $x, replace with $x<isa>.
	The psABI defined $x to the architecture which is same as the file elf
	attribute.  But GNU defined it to that is same as the previous $x<isa>,
	and always generated $x<isa> at the begining of each section.  That is
	because considering two objects have different architecture in their elf
	attributes, then $x will always be wrong after linking since the merged
	arch string will be changed.  For example, object A with rv32ic and object
	B with rv32ia, $x from A is rv32ic and $x from B is rv32ia, but the final
	output is rv32ica, so $x from A and B need to be updated to rv32ic and
	rv32ia by linker respectively.  I think let linker to do this is not good,
	so in order to follow the psABI, we will stop generating the $x for now.
	Instead, all $x will be replaced with the corresponding $x<isa>.  The
	dis-assembler will also treat $x like what psABI defined.

2025-03-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-02  Richard Allen  <rsaxvc@gmail.com>

	gprof: only process line numbers for intersection of vmas and histograms
	Some programs like RTOS firmware may have a large number of symbols.

	By loading the histograms before loading symbols, we can look up
	only the line numbers that were captured in the histogram file,
	which reduces processing time for such a firmware from ~2 minutes
	to ~2 seconds.

2025-03-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-03-01  Richard Allen  <rsaxvc@gmail.com>

	gprof: fix symbol miscount by merging passes
	Instead of fixing "somebody miscounted" errors,
	this patch combines the core_create_line_syms()
	passes, and dynamically expands the ltab buffer.

	Reducing the number of passes will make future
	optimizations simpler.

2025-03-01  Richard Allen  <rsaxvc@gmail.com>

	gprof: remove unused variables

	gprof: speed up line-by-line for MIPS/PowerPC/RISCV/SuperH
	Roughly halves the number of bfd_find_nearest_line() calls,
	about 40% less time for a few different large ELF files.

	gprof: rename min_insn_size to insn_boundary
	This distinction is important for architecures like Xtensa,
	where 2B and 3B instructions are common, but the correct
	value for instruction iteration is 1B, not 2B.

	gprof: remove ASCII formfeed/0x0C bytes from source code

2025-03-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: add dwarf2_per_bfd::filename and use it where possible
	I noticed we quite often use:

	    bfd_get_filename (per_bfd->obfd)

	Add a shortcut for that.

	Change-Id: I4e33925a481fd44088386510b01936d38e1d7d38
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-28  Andrew Carlotti  <andrew.carlotti@arm.com>

	Add Vim swap files to .gitignore
	This matches the exclusion added to the GCC .gitignore file in 2022.

2025-02-28  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix cv-qualified unnamed struct/union field lookup
	GCC permits not only unnamed structs and unions, but cv-qualified ones.
	Our earlier fix in 6c3a38777b38a2ad87e2b2bcec4567578d1c83ec supported
	unnamed structs and unions, but only unqualified ones.

	Resolving away cvr-quals of nameless fields (and, irrelevantly, typedefs)
	is easy and fixes this problem.

	Tests adjusted accordingly.

	libctf/
		PR libctf/32746
		* ctf-types.c (ctf_member_next): Resolve away cv-quals.
		(ctf_member_info): Likewise.
		* testsuite/libctf-lookup/struct-iteration-ctf.c: Add a cv-qualified
		type or two: make sure to keep a non-qualified one.
		* testsuite/libctf-lookup/struct-iteration.c: Verify consistency
		of ctf_member_next and ctf_member_info.
		* testsuite/libctf-lookup/struct-iteration.lk: Adjust.

	Tested-by: Stephen Brennan <stephen.s.brennan@oracle.com>

2025-02-28  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix slices of slices and of enums
	Slices had a bunch of horrible usability problems.  In particular, while
	towers of cv-quals are resolved away by functions that need to do it, towers
	of cv-quals with slices in the middle are not resolved away by functions
	like ctf_enum_value that can see through slices: resolving volatile -> slice
	-> const -> enum will leave it with a 'const', which will error pointlessly,
	annoying callers, who reasonably expect slices to be more invisible than
	this.  (The user-callable ctf_type_resolve still does not resolve away
	slices, because this is the only way users can see that the slices are there
	at all.)

	This is induced by a fix for another wart: ctf_add_enumerator does not
	resolve anything away at all, so you can't even add enumerators to const or
	volatile enums -- and more problematically, you can't add enumerators to
	enums with an explicit encoding without resolving away the types by hand,
	since ctf_add_enum_encoded works by returning a slice!  ctf_add_enumerator
	now resolves away all of those, so any cvr-or-typedef-or-slice-qual
	terminating in an enum can be added to, exactly as callers likely expect.

	(New tests added.)

	libctf/
		* ctf-create.c (ctf_add_enumerator): Resolve away cvr-qualness.
		* ctf-types.c (ctf_type_resolve_unsliced): Don't terminate at
		the first slice.
		* testsuite/libctf-writable/slice-of-slice.*: New test.

2025-02-28  Nick Alcock  <nick.alcock@oracle.com>

	readelf, objdump: fix ctf dict leak
	ctf_archive_next returns an opened dict, which must be closed by the caller.

	Thanks to Alan Modra for spotting this.

	binutils/
		* objdump.c (dump_ctf): Close dict.
		* readelf.c (dump_section_as_ctf): Likewise.

2025-02-28  Jonas 'Sortie' Termansen  <sortie@maxsi.org>

	Remove unnecessary non-standard & unportable inclusions.
	<memory.h> is not needed and not standardized and is just an alias for
	<string.h>.

	<sys/param.h> is not needed and not standardized and contains a kitchen
	sink of various unportable definitions not agreed upon and best done
	manually or through other headers.

	These fixes are needed to compile binutils on Sortix and other operating
	systems with a strict POSIX.1-2024 libc without obsolete features.

2025-02-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/nostdlib.exp on aarch64
	On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into:
	...
	(gdb) continue^M
	Continuing.^M
	warning: Temporarily disabling breakpoints for unloaded shared library \
	  "/lib/ld-linux-aarch64.so.1"^M
	^M
	Breakpoint 2, _start () at nostdlib.c:20^M
	20      {^M
	(gdb) FAIL: $exp: pie=pie: continue to marker
	...

	This happens as follows:
	- the test-case sets a breakpoint on *_start,
	- the breakpoint resolves to *_start in the executable,
	- the executable is started, and the breakpoint resolves to *_start in the
	  dynamic linker,
	- execution stops at *_start in the dynamic linker,
	- the test-case issues a continue, expecting to continue to the breakpoint on
	  marker,
	- while continuing, the dynamic linker is reported as unloaded,
	- the breakpoint again resolves to *_start in the executable,
	- execution stops at *_start in the executable, and
	- the test-case concludes that it failed to "continue to marker".

	This doesn't happen on x86_64-linux.  There, after the executable is started,
	the breakpoint again resolves to *_start in the exec.

	This is similar to what happens when printing _start.

	On aarch64-linux, we print the _start in the dynamic linker:
	...
	$ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \
	    -ex "b _start" \
	    -ex run \
	    -ex "print _start" \
	    -ex "info break"
	Breakpoint 1 at 0x2bc: file nostdlib.c, line 23.

	Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22
	22      ENTRY (_start)
	$1 = {void (void)} 0xfffff7fd6ac0 <_start>
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   <MULTIPLE>
	        breakpoint already hit 1 time
	1.1                         y   0x0000aaaaaaaa02bc in _start at nostdlib.c:23
	1.2                         y   0x0000fffff7fd6ac0 in _start at dl-start.S:22
	...

	On x86_64-linux, we print the _start in the exec:
	...
	Breakpoint 1 at 0x2c5: file nostdlib.c, line 23.

	Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \
	  /lib64/ld-linux-x86-64.so.2
	$1 = {void (void)} 0x5555555542c1 <_start>
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   <MULTIPLE>
		breakpoint already hit 1 time
	1.1                         y   0x00005555555542c5 in _start at nostdlib.c:23
	1.2                         y   0x00007ffff7fe4f00 <_start>
	...

	The difference may be down to the availability of debug info for the _start in
	the dynamic linker.

	Finally, the described scenario on aarch64-linux is not deterministic.  The
	behavior depends on the dynamic linker being reported as unloaded, which has
	been classified as a GLIBC bug, so that might get fixed.

	Ideally this test-case would stop at both *_start in the executable and the
	dynamic linker, but in absense of a way to specify this reliably (see PR32748),
	fix this by making this a temporary breakpoint, ensuring that the breakpoint
	will only trigger once.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	PR testsuite/32743
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743

2025-02-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: fix some namespace comment formatting
	I noticed a

	  // namespace selftests

	comment, which doesn't follow our comment formatting convention.  I did
	a find & replace to fix all the offenders.

	Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c

2025-02-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: fix failed assertion in dwarf2_find_containing_comp_unit selftest
	Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr
	section") added some asserts in the dwarf2_per_cu_data constructor to
	verify that the passed dwarf2_per_bfd and dwarf2_section_info are not
	nullptr.  However, the dummy dwarf2_per_cu_data objects created in the
	dwarf2_find_containing_comp_unit selftests are passed nullptr for those
	parameters.

	I prefer to keep the asserts in place, as protection for the non-test
	code and as self documentation, so fix this by passing some dummy
	pointers in the test.

	Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-02-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor
	Most of the time, the length of a unit is known when constructing a
	dwarf2_per_cu_data or signatured_type.  Add a construtor parameter for
	it.  In the few cases where it isn't, pass 0, which leaves it unset.

	Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-02-27  Nick Clifton  <nickc@redhat.com>

	Updated translations for bfd and gold

2025-02-27  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Pass -z separate-code to ld for -z mark-plt tests
	Pass -z separate-code to ld for -z mark-plt tests to fix:

	FAIL: ld-x86-64/mark-plt-1a
	FAIL: ld-x86-64/mark-plt-1b
	FAIL: ld-x86-64/mark-plt-1c
	FAIL: ld-x86-64/mark-plt-1d
	FAIL: ld-x86-64/mark-plt-1a-x32
	FAIL: ld-x86-64/mark-plt-1b-x32
	FAIL: ld-x86-64/mark-plt-1c-x32
	FAIL: ld-x86-64/mark-plt-1d-x32

	when binutils is configured with --disable-separate-code.

		* ld-x86-64/mark-plt-1a-x32.d: Pass -z separate-code to ld.
		* ld-x86-64/mark-plt-1a.d: Likewise.
		* ld-x86-64/mark-plt-1b-x32.d: Likewise.
		* ld-x86-64/mark-plt-1b.d: Likewise.
		* ld-x86-64/mark-plt-1c-x32.d: Likewise.
		* ld-x86-64/mark-plt-1c.d: Likewise.
		* ld-x86-64/mark-plt-1d-x32.d: Likewise.
		* ld-x86-64/mark-plt-1d.d: Likewise.

2025-02-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-26  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: partially process DWARF unwind info in CFI_escape
	CFI_escape is most commonly used to include DWARF expressions in the
	unwind information.  One may also use CFI_escape to add OS-specific CFI
	opcodes.  Up until now, SFrame generation process would skip generating
	SFrame FDE at the mere sight of a CFI_escape opcode.

	Fine tune the handling of CFI_escape for SFrame generation by explicitly
	checking for few "harmless" (in context of SFrame generation)
	CFI_escape DWARF info:
	  - DW_CFA_expression affecting registers of no significance to SFrame
	    stack trace info
	  - DW_CFA_value_offset affecting registers of no significance to SFrame
	    stack trace info

	Expose the current cfi_escape_data structure in dw2gencfi.c to the
	relevant header file to allow SFrame generation APIs to use it too.

	Valid unwind info may be split across multiple .cfi_escape directives.
	Conversely, it is also allowed to simply put multiple DWARF expressions
	and/or operations in a single .cfi_escape directive.  Handling all of
	these cases correctly will need parsing/processing that is not deemed
	worth the effort in context of SFrame generation; We continue to skip
	generating SFrame FDE for these cases and warn the user.

	In future, SFrame stack trace format may support non-SP/FP as base
	register (albeit in limited form).  Add an explicit check in
	sframe_xlate_do_escape_expr (to test against the current CFA register)
	to ensure the functionality continues to work.

	Use differentiated warning text in sframe_xlate_do_val_offset to avoid
	confusion to the user as the same function is used for handling
	.cfi_val_offset and .cfi_escape DW_CFA_val_offset,...

	Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64
	and aarch64 (and s390x too).

	gas/
		* gas/dw2gencfi.c (struct cfi_escape_data): Move from ...
		* gas/dw2gencfi.h (struct cfi_escape_data): ... to.
		* gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string
		for .cfi_escape conditionally.
		(sframe_xlate_do_escape_expr): New definition.
		(sframe_xlate_do_escape_val_offset): Likewise.
		(sframe_xlate_do_cfi_escape): Likewise.
		(sframe_do_cfi_insn): Handle CFI_escape explicitly.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
		* gas/cfi-sframe/cfi-sframe-common-9.d: New test.
		* gas/cfi-sframe/cfi-sframe-common-9.s: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test.
		* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test.

2025-02-26  Charlie Jenkins  <charlie@rivosinc.com>

	RISC-V: Fix abort when displaying data and partial instructions
	If data is encountered that is not a power of two, dump all of the data with
	a .<N>byte directive.  The current largest support risc-v instruction length
	is 22, so the data over 22 bytes will be displayed by,
	.insn, 22, ... + .<N-22>byte.

2025-02-26  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: add -z separate-code to sframe x86_64 tests
	Those tests were generated by a linker having "-z separate-code" on by
	default. However, being controlled by a configure option, it can be off
	by default. Forcing the option as part of the tests ensures clean
	results in both cases.

2025-02-26  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix unused var in dwarf2/read.c
	On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
	...
	gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’:
	gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \
	  [-Werror=unused-variable]
	    auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr);
	                               ^
	...

	Fix this by dropping the unused variable.

	Tested on x86_64-linux, by completing a build.

2025-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: fix signature_type created with nullptr section
	Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data
	constructor") introduced a regression when using dwp.  It can be
	reproduced with:

	    $ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp"

	Then, to investigate:

	    $ ./gdb  -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int'
	    Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets...
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info'

	Commit c44ab627b02 removed the assignment of signatured_type::section
	(dwarf2_per_cu_data::section, really) in
	fill_in_sig_entry_from_dwo_entry with the justification that the section
	was already set when constructing the signatured_type.  Well, that was
	true except for one spot in lookup_dwp_signatured_type which passes a
	nullptr section to add_type_unit.

	Fix that by passing the section to add_type_unit in that one spot.  This
	is the same section that would have been set by
	fill_in_sig_entry_from_dwo_entry before.

	Add some asserts in the dwarf2_per_cu_data constructor to verity that
	the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr.

	Change-Id: If27dae6b4727957c96defc058c7e4be31472005b
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739
	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: convert dwarf2_per_bfd::signatured_types to a gdb::unordered_set
	I'd like to add these asserts in dwarf2_per_cu_data's constructor:

	    gdb_assert (per_bfd != nullptr);
	    gdb_assert (section != nullptr);

	However, these dummy instances of signatured_type, used as hash table
	lookup keys, are in the way:

	    signatured_type find_sig_entry (nullptr, nullptr, sect_offset {}, sig);

	This motivated me to convert the dwarf2_per_bfd::signatured_types hash
	table to a gdb::unordered_set.  This allows finding an entry by simply
	passing the signature (an integer) and removes the need to create dummy
	signatured_type objects.

	There is one small unfortunate pessimization:
	lookup_dwo_signatured_type, for instance, does a lookup by signature to
	find an existing signatured_type.  If not found, it adds a new one by
	calling add_type_unit.  The current code passes down the slot where to
	put the new element, avoiding an extra hash when inserting the new
	signatured_type.  With the new code, I don't see a way to do that.  This
	is probably negligible, but it bugs me.  If we used a map of signature
	-> signatured_type, I would see a way, but then it would waste space.

	I see one change in behavior, that is not really important IMO.  In
	read_comp_units_from_section, if duplicate signature type entries are
	detected, the code prior to this patch overwrites the existing
	signatured_type in the hash table with the new one.  With this patch,
	the existing signatured_type is kept: the call to emplace does not
	insert the value if an existing equal value exists.

	Other than that, no behavior change expected.

	Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: change some per-objfile functions to be per-bfd
	I identified the following functions that currently take a
	dwarf2_per_objfile, but could take a less specific dwarf2_per_bfd.

	 - try_open_dwop_file
	 - open_dwo_file
	 - open_dwp_file

	The uses of the per-objfile object in try_open_dwop_file can be replaced
	with equivalent per-bfd ones.

	Change-Id: Ia31fa0b988375e86a715ee863d4ec3c572ce89c0
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use dwz_file::filename in a few spots
	I found a few spots where the existing dwz_file::filename method could
	be used.

	Change-Id: I0522b1e3abbfac2f392f9ec777c37b242ee236d8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move "gdb:function_view" into quick-symbol.h typedefs
	All users of these typedefs use them inside a gdb::function_view.  Move
	the gdb::function_view in the typedefs themselves.  This shortens the
	types in function signatures and helps with readability, IMO.

	Rename them to remove the `_ftype` suffix: this suffix is not as
	relevant in C++ as it was in C.  With function_view, the caller can pass
	more than just a simple "function".  Anyway, I think it's clearer to
	name them after the role the callback has (listener, matcher, etc).

	Adjust some related comments.

	Change-Id: Iaf9f8ede68b51ea9e4d954792e8eb90def8659a6
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: initialize tu_stats fields
	Initialize fields of tu_stats to 0, remove the explicit default
	initialization of dwarf2_per_bfd::tu_stats.

	Change-Id: I98b2d5c4171291a3df2569466559174fb7cf32b6
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-25  Tom Tromey  <tom@tromey.com>

	Remove struct print_one_inferior_data
	struct print_one_inferior_data is not used, so remove it.

2025-02-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove unused include in read.c
	This include is reported as unused by clangd.

	Change-Id: I95b73f85607537551ef54e46551197d1371d621b

2025-02-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: add displaced stepping support
	Implement the target_ops displaced stepping methods to add displaced
	stepping support when debugging AMD GPU programs.  The knowledge of how
	to prepare and finish displaced steps is provided by the amd-dbgapi
	library, so the code here is relatively straightforward.  No need to
	parse instructions or handle fixups, that is done by the lib  We just
	need to remember, for each thread doing a displaced step, the displaced
	stepping id given by the library.

	Add a test to exercise the new functionality.  The compiler generates
	DWARF that GDB doesn't understand yet [1], so trying to step over a
	breakpoint with DWARF present gives:

	    (gdb) si
	    Unhandled dwarf expression opcode 0xe9

	The test purposefully builds the binary without DWARF info to circumvent
	this.

	[1] https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html

	Change-Id: I53f459221a42d4b02a6041eadb8cf554500e2162
	Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)

2025-02-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add target displaced stepping support
	The amd-dbgapi library, used in the AMD GPU port, has the capability to
	prepare and cleanup displaced step operations.  In order to use it, add
	the following target_ops methods:

	 - supports_displaced_step
	 - displaced_step_prepare
	 - displaced_step_finish
	 - displaced_step_restore_all_in_ptid

	Prior to this patch, displaced stepping preparation and cleanup is done
	solely by gdbarches.  Update infrun to use these new target methods
	instead of gdbarch hooks.  To keep the behavior for other architectures
	unchanged, make the default implementations of the new target_ops method
	forward to the thread's gdbarch.

	displaced_step_restore_all_in_ptid won't be needed for the AMD GPU port,
	but was added for completeness.  It would be weird for infrun displaced
	stepping code to call target methods except for that one thing where it
	calls a gdbarch method.

	Since this patch only adds infrastructure, no behavior change is
	expected.

	Change-Id: I07c68dddb5759a55cd137a711d2679eedc0d9285

2025-02-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: use gdb::unordered_map
	Since we have gdb::unordered_map, swap std::unordered_map for that.

	Change-Id: If2ef652fe18c1a440a25cff6131d29e37091bdbe
	Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)

2025-02-25  Ciaran Woodward  <ciaranwoodward@xmos.com>

	Fix mkdir_recursive on windows when CWD is root
	On windows, when creating a directory with an absolute path,
	mkdir_recursive would start by trying to make 'C:'.

	On windows, this has a special meaning, which is "the current
	directory on the C drive". So the first thing it tries to do
	is create the current directory.

	Most of the time, this fails with EEXIST, so the function
	continues as expected. However if the current directory is
	C:/, trying to create that causes EPERM, which causes the
	function to prematurely terminate.

	(The same applies for any drive letter.)

	This patch resolves this issue, by skipping the drive letter
	so that it is never sent to the mkdir call.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-25  Jens Remus  <jremus@linux.ibm.com>

	x86: SFrame FDE for PLT0 does not use repetition block size
	The SFrame FDE for the PLT0 entry is of type PCINC, which does does not
	make use of the type PCMASK repetition block size.  Therefore generate
	the FDE with a repetition block size of zero.

	bfd/
		* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use FDE
		repetition block size of zero for PLT0.

2025-02-25  Ciaran Woodward  <ciaranwoodward@xmos.com>

	gdb/remote: Set the thread of the remote before sending qRcmd.
	GDB allows remotes to implement extension commands which can
	be accessed using the 'monitor' command.

	This allows remotes to implement functionality which does not
	exist in GDB for whatever reason (doesn't make sense, too
	specific to one target, etc.)

	However, before this change, the remote would not necessarily know
	which thread/inferior was currently selected on the GDB client.
	This prevents the implementation of any 'monitor' commands which are
	specific to a single inferior/thread on the remote.

	This is because GDB informs the remote of the current thread
	lazily - only when it is relevant to the RSP command next being
	sent.

	qRcmd is the underlying RSP command used for monitor commands, so
	this change ensures that GDB will update the remote with the
	'current' thread if it has changed since the remote was last
	informed.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/windows: remove disable_breakpoints_in_shlibs call
	I noticed that the disable_breakpoints_in_shlibs function disables
	breakpoints without calling notify_breakpoint_modified.  This commit
	is one step towards fixing this issue.

	There are currently only two uses of disable_breakpoints_in_shlibs,
	one in clear_solib (in solib.c), and the other in
	windows_nat_target::do_initial_windows_stuff (in windows-nat.c).

	I believe that the call in windows-nat.c can be shown to be redundant,
	and therefore can be removed.

	windows_nat_target::do_initial_windows_stuff is called from two
	places: windows_nat_target::attach and
	windows_nat_target::create_inferior, these are the target_ops
	functions used to attach to a running process, or for creating a new
	process, and are only called from attach_command or run_command_1,
	both in infcmd.c.

	Both attach_command and run_command_1 call target_pre_inferior before
	calling the relevant target_ops function.

	In target_pre_inferior, so long as the target doesn't have a global
	solist (and windows doesn't), we always call no_shared_libraries (from
	solib.c), which calls clear_solib (also in solib.c), which in turn
	calls disable_breakpoints_in_shlibs.

	My claim then, is that, any time we reach the
	disable_breakpoints_in_shlibs call in
	windows_nat_target::do_initial_windows_stuff, we will have always have
	called disable_breakpoints_in_shlibs already via clear_solib.

	I think it should be safe to remove the disable_breakpoints_in_shlibs
	call from windows_nat_target::do_initial_windows_stuff.  There should
	be no user visible changes.

	My ultimate goal, which I'll address in follow on commits, is to
	delete disable_breakpoints_in_shlibs completely.  Removing this call
	means that we only have one disable_breakpoints_in_shlibs call
	remaining in GDB.

	Testing for this change has been minimal.  My only Windows build
	machine is not great, and I've never managed to get DejaGNU running in
	that environment.  This commit builds, and a few basic, manual tests
	seem fine, but beyond that, this change is untested.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-25  Tom de Vries  <tdevries@suse.de>

	gdb: don't show incorrect source file in source window
	Consider the test-case sources main.c and foo.c:

	  $ cat main.c
	  extern int foo (void);

	  int
	  main (void)
	  {
	    return foo ();
	  }
	  $ cat foo.c
	  extern int foo (void);

	  int
	  foo (void)
	  {
	    return 0;
	  }

	and main.c compiled with debug info, and foo.c without:

	  $ gcc -g main.c -c
	  $ gcc foo.c -c
	  $ gcc -g main.o foo.o

	In TUI mode, if we run to foo:

	  $ gdb -q a.out -tui -ex "b foo" -ex run

	it gets us "[ No Source Available ]":

	  ┌─main.c─────────────────────────────────────────┐
	  │                                                │
	  │                                                │
	  │                                                │
	  │            [ No Source Available ]             │
	  │                                                │
	  │                                                │
	  └────────────────────────────────────────────────┘
	  (src) In: foo                  L??   PC: 0x400566
	  ...
	  Breakpoint 1, 0x0000000000400566 in foo ()
	  (gdb)

	But after resizing (pressing ctrl-<minus> in the gnome-terminal), we
	get instead the source for main.c:

	  ┌─main.c─────────────────────────────────────────┐
	  │        3 int                                   │
	  │        4 main (void)                           │
	  │        5 {                                     │
	  │        6   return foo ();                      │
	  │        7 }                                     │
	  │                                                │
	  │                                                │
	  └────────────────────────────────────────────────┘
	  (src) In: foo                   L??   PC: 0x400566
	  ...
	  Breakpoint 1, 0x0000000000400566 in foo ()
	  (gdb)

	which is inappropriate because we're stopped in function foo, which is
	not in main.c.

	The problem is that, when the window is resized, GDB ends up calling
	tui_source_window_base::rerender.  The rerender function has three
	cases, one for when the window already has some source code
	content (which is not the case here), a case for when the inferior is
	active, and we have a selected frame (which is the case that applies
	here), and a final case for when the inferior is not running.

	For the case which we end up in, the source code window has no
	content, but the inferior is running, so we have a selected frame, GDB
	calls the get_current_source_symtab_and_line() function to get the
	symtab_and_line for the current location.

	The get_current_source_symtab_and_line() will actually return the last
	recorded symtab and line location, not the current symtab and line
	location.

	What this means, is that, if the current location has no debug
	information, get_current_source_symtab_and_line() will return any
	previously recorded location, or failing that, the default (main)
	location.

	This behaviour of get_current_source_symtab_and_line() also causes
	problems for the 'list' command.  Consider this pure CLI session:

	  (gdb) break foo
	  Breakpoint 1 at 0x40110a
	  (gdb) run
	  Starting program: /tmp/a.out

	  Breakpoint 1, 0x000000000040110a in foo ()
	  (gdb) list
	  1	extern int foo (void);
	  2
	  3	int
	  4	main (void)
	  5	{
	  6	  return foo ();
	  7	}
	  (gdb) list .
	  Insufficient debug info for showing source lines at current PC (0x40110a).
	  (gdb)

	However, if we look at how GDB's TUI updates the source window during
	a normal stop, we see that GDB does a better job of displaying the
	expected contents.  Going back to our original example, when we start
	GDB with:

	  $ gdb -q a.out -tui -ex "b foo" -ex run

	we do get the "[ No Source Available ]" message as expected.  Why is
	that?

	The answer is that, in this case GDB uses tui_show_frame_info to
	update the source window, tui_show_frame_info is called each time a
	prompt is displayed, like this:

	  #0  tui_show_frame_info (fi=...) at ../../src/gdb/tui/tui-status.c:269
	  #1  0x0000000000f55975 in tui_refresh_frame_and_register_information () at ../../src/gdb/tui/tui-hooks.c:118
	  #2  0x0000000000f55ae8 in tui_before_prompt (current_gdb_prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/tui/tui-hooks.c:165
	  #3  0x000000000090ea45 in std::_Function_handler<void(char const*), void (*)(char const*)>::_M_invoke (__functor=..., __args#0=@0x7ffc955106b0: 0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:300
	  #4  0x00000000009020df in std::function<void(char const*)>::operator() (this=0x5281260, __args#0=0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:688
	  #5  0x0000000000901c35 in gdb::observers::observable<char const*>::notify (this=0x31dda00 <gdb::observers::before_prompt>, args#0=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/../gdbsupport/observable.h:166
	  #6  0x00000000008ffed8 in notify_before_prompt (prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/event-top.c:518
	  #7  0x00000000008fff08 in top_level_prompt () at ../../src/gdb/event-top.c:534
	  #8  0x00000000008ffdeb in display_gdb_prompt (new_prompt=0x0) at ../../src/gdb/event-top.c:487

	If we look at how tui_show_frame_info figures out what source to
	display, it doesn't use get_current_source_symtab_and_line(), instead,
	it finds a symtab_and_line directly from a frame_info_pt.  This means
	we are not dependent on get_current_source_symtab_and_line() returning
	the current location (which it does not).

	I propose that we change tui_source_window_base::rerender() so that,
	for the case we are discussing here (the inferior has a selected
	frame, but the source window has no contents), we move away from using
	get_current_source_symtab_and_line(), and instead use find_frame_sal
	instead, like tui_show_frame_info does.

	This means that we will always use the inferior's current location.

	Tested on x86_64-linux.

	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Reported-By: Andrew Burgess <aburgess@redhat.com>
	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32614

2025-02-25  Tom de Vries  <tdevries@suse.de>

	[libctf] Fix warning: @xref should not appear on @multitable line
	When building gdb, I run into:
	...
	ctf-spec.texi:809: warning: @xref should not appear on @multitable line
	...

	The line in question is:
	...
	@multitable {Kind} {@code{CTF_K_VOLATILE}} {Indicates a type that cannot be represented in CTF, or that} {@xref{Pointers typedefs and cvr-quals}}
	...
	which defines a prototype row with 4 columns.

	However, the table only has 3 colums:
	...
	@headitem Kind @tab Macro @tab Purpose
	...

	Fix the warning by removing the item in the prototype row representing a fourth column.

	Tested on aarch64-linux.

	PR libctf/32044
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32044

2025-02-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Exit left-over gdb in gdb.mi/mi-break.exp
	After test-case gdb.mi/mi-break.exp, a gdb instance is left running.

	The test-case starts two instances using mi_clean_restart, one using
	separate-mi-tty.

	For each instance, gdb_exit is called once, from two different locations:
	- mi_clean_restart, and
	- gdb_finish.

	But this doesn't seem to be effective for the separate-mi-tty case.

	Fix this by calling gdb_mi_exit at the end of proc test_break.

	Likewise in a few more more test-case.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/32709
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709

2025-02-24  Kevin Buettner  <kevinb@redhat.com>

	Use ui_out for "info checkpoints"
	In his review of my recent checkpoint work (commit e5501dd4321),
	Andrew Burgess suggested that I use GDB's structured table generation
	mechanism for the "info checkpoints" command.  This patch does
	that.

	Andrew also recommended using print_stack_frame() for the "Frame"
	column.  I tried this, but ran into some problems, which are described
	in a comment in the code.  I got it to mostly work, except for the
	case when the current/active fork is running.  Switching context away
	from and then back to a running fork doesn't work.  It could, perhaps,
	be made to work, but I'm not convinced that the checkpoint facility is
	important enough to expend the effort for this case.  So, instead,
	I simply adapted the existing checkpoint frame printing code to
	use the ui_out machinery instead of gdb_printf.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/styling: only check TERM environment once, during initialisation
	We currently check the TERM environment variable any time we call one
	of the ui_file::can_emit_style_escape() functions.  This seems
	excessive.

	During GDB's startup we also check for the NO_COLOR environment
	variable and disable styling if this is set.

	I propose that we combine these two checks, and perform them just once
	during startup (as the current NO_COLOR check is currently done).  As
	with the NO_COLOR check, if the TERM variable is set to "dumb"
	indicating that styling is not supported then we should just set
	cli_styling to false.

	This does mean that the user can then 'set style enabled on', even for
	a dumb terminal, which was not possible previously.  Before this
	commit the "dumb" terminal check was separate and would prevent
	styling even if 'set style enabled on' was in effect.

	Of course, trying to turn on styling in a dumb terminal might not give
	the results that a user hope for.  And so, I have implemented a check
	in `set_style_enabled`, so in a dumb terminal a user will see this:

	  (gdb) set style enabled on
	  warning: The current terminal doesn't support styling.  Styled output might not appear as expected.

	After which GDB will try to emit styling.  We could, potentially,
	prevent styling being enabled instead of emitting a warning, but I'm
	inclined to let the user turn on styling if they really want to.

	Approved-By: Kevin Buettner <kevinb@redhat.com>
	Acked-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: use correct setting to control asm window styling
	Currently the TUI's asm window uses `source_styling` to control
	styling.  This setting is supposed to be for styling of source files
	though, and the asm window displays disassembler output.

	We have a different setting for this `disassemble_styling`, which is
	controlled with 'set style disassembler enabled on|off'.

	Switch to use the correct control variable.

	I've written a new test for this, but this required some additions to
	the tuiterm library in order to grab character attributes for a screen
	region.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: fix help text for 'set style disassembler enabled'
	The help text for 'set/show style disassembler enable' was output of
	date.  It talks about GDB requiring the Python Pygments library, but
	for many common architectures this is no longer the case, libopcode is
	used for styling.

	The Python Pygments library is still used as a fallback for those
	architectures that libopcode doesn't currently style.

	I've updated the help text to try and explain all this.  The manual
	was already updated.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2025-02-24  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Fix documentation of handle SIGKILL
	Here ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Signals.html ) I
	read:
	...
	GDB has the ability to detect any occurrence of a signal in your program.  You
	can tell GDB in advance what to do for each kind of signal.
	...

	However, here ( https://man7.org/linux/man-pages/man2/ptrace.2.html ) I read:
	...
	While being traced, the tracee will stop each time a signal is
	delivered, even if the signal is being ignored.  (An exception is
	SIGKILL, which has its usual effect.)
	...

	So, it seems to be that for SIGKILL we can't tell GDB in advance what to do.

	Fix the documentation to reflect this.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

	PR gdb/32714
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32714

2025-02-24  Rudnicki, Piotr  <piotr.rudnicki@intel.com>

	gdb, testsuite, rust: fix for empty array
	For the Rust language, to avoid segmentation fault in case of an empty
	array, do not try to copy any elements, but allocate and return
	the empty array immediately.

	With the command before the change, gdb crashes with message:

	(gdb) set lang rust
	(gdb) p [1;0]
	Fatal signal: Segmentation fault

	After the fix in this commit, gdb shows following message:
	(gdb) set lang rust
	(gdb) p [1;0]
	$1 = []

	Update the existing test case gdb.rust/expr.exp to verify the change.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Nick Clifton  <nickc@redhat.com>

	objdump: Inform users if RELR relocs are present in a file when using the -r or -R options and no regular relocs are present.
	PR 32459

2025-02-24  Shahab Vahedi  <shahab.vahedi@amd.com>

	gdb/testsuite/lib/rocm.exp: Fix a typo in a comment
	"Check we have ..." --> "Check if we have ..."

	This is for consistency with the previous comment and
	the code downstream.

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: handle empty locspec when printing breakpoints
	For background reading, please see the previous patch, and the patch
	before that!

	After the last two patches, internal breakpoints can now be marked as
	shlib_disabled if the library in which they are placed is unloaded.

	The patch before last discusses a situation related to the
	gdb.base/nostdlib.exp test, when run on a GNU/Linux glibc based system
	where executables are compiled as PIE by default.

	In this case it is observed that the dynamic linker will actually
	report itself as unloaded (i.e. remove itself from the list of
	currently loaded shared libraries).  This behaviour is likely a bug in
	the dynamic linker, but this behaviour exists in released versions of
	the dynamic linker, so GDB should (if the cost is not too great) be
	changed to handle this situation.

	This commit handles a problem with the 'maint info breakpoints'
	command.

	When the dynamic linker is unloaded the 'shlib event' breakpoint is
	marked as shlib_disabled (i.e. placed into the pending state).  When
	displaying the breakpoint in the 'maint info breakpoints' output, GDB
	will try to print the locspec (location_spec *) as a string

	Unfortunately, the locspec will be nullptr as the internal breakpoints
	are not created via a location_spec, this means that GDB ends up
	trying to call location_sepc::to_string() on a nullptr, resulting in
	undefined behaviour (and a crash).

	For most internal breakpoint types this is not a problem.  If we
	consider bp_longjmp_master for example, if the shared library
	containing a breakpoint of this type is unloaded then first GDB marks
	the breakpoint as shlib_disabled, then after unloading the shared
	library breakpoint_re_set is called, which will delete the internal
	breakpoint, and then try to re-create it (if needed).  As a result,
	the user never gets a change to run 'maint info breakpoints' on a
	bp_longjmp_master breakpoint in the shlib_disabled state.

	But bp_shlib_event and bp_thread_event breakpoints are not deleted and
	recreated like this (see internal_breakpoint::re_set), so it is
	possible, in rare cases, that we could end up trying to view one of
	these breakpoint in a shlib_disabled state, and it would be nice if
	GDB didn't crash as a result.

	I've updated the printing code to check for and handle this case, and
	I've updated the docs to mention this (rare) case.

	For testing, I've extended gdb.base/nostdlib.exp to compile as
	pie and nopie, and then run 'maint info breakpoints'.  If we're
	running on a buggy glibc then this will trigger the crash.  I don't
	know how I can trigger this problem without a buggy glibc as this
	would require forcing the dynamic linker to be unloaded.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: disable internal b/p when a solib is unloaded
	Bug PR gdb/32079 highlights an issue where GDB will try to remove a
	breakpoint for a shared library that has been unloaded.  This will
	trigger an error from GDB like:

	  (gdb) next
	  61            dlclose (handle[dl]);
	  (gdb) next
	  warning: error removing breakpoint 0 at 0x7ffff78169b9
	  warning: error removing breakpoint 0 at 0x7ffff7730b57
	  warning: error removing breakpoint 0 at 0x7ffff7730ad3
	  54        for (dl = 0; dl < 4; ++dl)
	  (gdb)

	What happens is that as the inferior steps over the dlclose() call,
	GDB notices that the library has been unloaded and calls
	disable_breakpoints_in_unloaded_shlib.  However, this function only
	operates on user breakpoints and tracepoints.

	In the example above what is happening is that the test loads multiple
	copies of libc into different linker namespsaces.  When we 'next' over
	the dlclose call one of the copies of libc is unloaded.  As GDB placed
	longjmp master breakpoints within the copy of libc that was just
	unloaded, the warnings we see are GDB trying (and failing) to remove
	these breakpoints.

	I think the solution is for disable_breakpoints_in_unloaded_shlib to
	handle all breakpoints, even internal ones like the longjmp master
	breakpoints.

	If we do this then the breakpoint will be marked as shlib_disabled and
	also will be marked as not inserted.  Later when we call
	breakpoint_re_set() and the longjmp breakpoints are deleted we will no
	longer try to remove them.

	This solution is inspired by a patch suggested in the bug report:

	  https://sourceware.org/bugzilla/show_bug.cgi?id=32079#c3

	There are some differences with my approach compared to the patch
	suggested in the bug.  First I have no need to delete the breakpoint
	inside disable_breakpoints_in_unloaded_shlib as an earlier patch in
	this series arranged for breakpoint_re_set to be called when shared
	libraries are removed.  Calling breakpoint_re_set will take care of
	deleting the breakpoint for us.  For details see the earlier commit
	titled:

	  gdb: fixes for code_breakpoint::disabled_by_cond logic

	Next, rather than only handling bp_longjmp and bp_longjmp_master, I
	allow all breakpoints to be handled.  I also only give the warning
	about disabling breakpoints for user breakpoints, I don't see the
	point of warning the user about internal b/p changes.

	With this done the issues in PR gdb/32079 are resolved.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079

	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't clear inserted flag in disable_breakpoints_in_unloaded_shlib
	This commit removes the clearing of bp_location::inserted from
	disable_breakpoints_in_unloaded_shlib, my claim is that this call is
	not needed (any more), and with the next commit, this line actually
	causes some problems.

	The disable_breakpoints_in_unloaded_shlib function was added back in
	2004 with commit 84acb35a5a97c, and from this first version the
	function cleared the bp_location::inserted flag.  The motivation for
	this is that the shared library might have already been unmapped, in
	which case, a later attempt to remove the location could fail.

	In 2013 a similar function disable_breakpoints_in_freed_objfile was
	added.  This function also cleared bp_location::inserted for similar
	reasons.  This code was added in commit:

	  commit 63644780babdca3f40e1978a236b6cd78473c91b
	  Date:   Tue Mar 12 11:10:18 2013 +0100

	      New remove-symbol-file command.

	Then in 2014 the clearing of bp_location::inserted was removed from
	disable_breakpoints_in_freed_objfile in the commit:

	  commit 08351840eabb44799e3d01026610420758f4fa40
	  Date:   Tue Apr 22 23:19:19 2014 +0100

	      Stale breakpoint instructions, spurious SIGTRAPS.

	The reason that clearing the ::inserted flag was removed in this
	commit is that if the disable_breakpoints_in_freed_objfile function
	was called when the b/p were actually inserted, and the memory for the
	associated objfile wasn't actually unmapped, then we could end up
	leaving breakpoints inserted into the inferior, which leads to
	spurious SIGTRAPs.

	In the next commit I'll change disable_breakpoints_in_unloaded_shlib
	so that all breakpoints, not just user breakpoints, will be
	disabled (via shlib_disabled) when a shared library is unloaded.  This
	addresses PR gdb/32079, see the next commit for a fuller justification
	for this change.

	The problem is that when I tested the next commit I ran into some
	regressions from the gdb.base/nostdlib.exp test when run on an AArch64
	GNU/Linux system where executables are compiled as PIE by default.
	This test compiles a simple binary with the -nostdlib flag.

	What happens is this:

	  - The executable is compiled as PIE, this means that we get a
	    dynamically linked executable, the dynamic linker is used to
	    perform the PIE relocation, but the executable uses no other
	    shared libraries.

	  - When GDB starts the inferior, initially the dynamic linker is
	    discovered as a shared library being used by the application, GDB
	    loads in the library and its debug symbols, placing the internal
	    "shlib event" breakpoints so that future shared library events can
	    be tracked.

	  - For the target I tested on systemtap probes were not used, instead
	    GDB fell back to the old style even breakpoint.

	  - As the inferior progresses, after the PIE relocation has been
	    performed, the dynamic linker performs some house keeping on the
	    list of shared libraries being used by the application.  During
	    this process the dynamic linker is removed from the list of shared
	    libraries being used by the inferior, this causes GDB see a shared
	    library event, which GDB understands to mean that it should unload
	    the dynamic linker from the inferior.

	    I spoke with the glibc engineers at RH, and the feeling is that
	    this is likely a bug (it's still being investigated).  But I don't
	    think it really matters if this is a bug or not.  There are
	    versions of glibc in the wild that have this behaviour, so GDB
	    should (if the cost is not too great) be updated to handle this.

	    Obviously after removing the dynamic linker from the list of
	    shared libraries, the dynamic linker is not actually unmapped,
	    that would not be possible, it's the dynamic linker that does the
	    unmapping, so the dynamic linker is left mapped into the
	    inferior's address space.

	  - With the next patch in place all breakpoints (user and internal)
	    within the dynamic linker are disabled (shlib_disabled) and
	    currently marked as not inserted (bp_location::inserted flag is
	    cleared).

	  - Having processed the shared library event GDB then resumes the
	    inferior.  As the shared library event is not a full stop of the
	    inferior (i.e. we don't remove all breakpoints before handling the
	    event), all of the breakpoints in the dynamic linker are still
	    inserted, but are now marked as not-inserted.

	  - GDB then resumes the inferior and immediately hits the breakpoint
	    that is still inserted.  As GDB thinks this breakpoint is not
	    inserted, this is reported to the user as a SIGTRAP.

	The fix I think is just to not clear the bp_location::inserted flag in
	disable_breakpoints_in_unloaded_shlib.  This will leave the breakpoint
	as inserted in the case above.  GDB will now be able to successfully
	resume the inferior after the shared library event (knowing there is a
	breakpoint inserted GDB will step over it and continue as expected).
	The next time the inferior performs a full stop the now shlib_disabled
	breakpoint will be removed from the inferior we would want.

	For the usual case, where a shared library is being unloaded due to
	say a dlclose, the breakpoints in the library will be marked as
	disabled, but will be left inserted.  The next time remove_breakpoints
	is called GDB will try to remove those breakpoint locations.  If the
	removal fails, as the breakpoint is marked shlib_disabled, GDB will
	hide the error message from the user and just assume that the shared
	library has been unmapped.  This functionality was first added in 2008
	in commit 879d1e6b4674bc8.

	There are two aspects to testing this change.  First whether no
	clearing the ::inserted flag causes general problems.  That is tested
	by running the full testsuite (I see no regressions).

	Then there is the specific problem that caused me to make this
	change.  That issue only occurs on AArch64, with GNU/Linux using
	glibc, when the executable is compiled as PIE, and doesn't use any
	shared libraries other than the dynamic linker (which can be the
	gdb.base/nostdlib.exp test if run on the right system).  What I don't
	know is how to recreate this setup in a more general form.

	We can't use add-symbol-file/remove-symbol-file as that passes through
	disable_breakpoints_in_freed_objfile instead, which the ::installed
	flag is already not adjusted.

	Also the bug doesn't trigger on x86 targets due to code in
	handle_signal_stop which sees the inserted breakpoint, and decides
	this must be a breakpoint that actually exists in the program, and
	then because gdbarch_decr_pc_after_break returns non-zero for x86, GDB
	steps the inferior past the breakpoint.  This is the big difference
	from AArch64 where gdbarch_decr_pc_after_break returns zero, and so
	the inferior gets stuck hitting the unexpectedly inserted breakpoint.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: handle dprintf breakpoints when unloading a shared library
	While working on the previous commit I realised that GDB would not
	handle dprintf breakpoints correctly when a shared library was
	unloaded.

	Consider this example using the test binary from shlib-unload.exp.  In
	the function 'foo' we create a dprintf is in a shared library:

	  (gdb) b 59
	  Breakpoint 1 at 0x401215: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c, line 59.
	  (gdb) r
	  Starting program: /tmp/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/shlib-unload/shlib-unload

	  Breakpoint 1, main () at /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c:59
	  59	  res = dlclose (handle);	/* Break here.  */
	  (gdb) dprintf foo,"In foo"
	  Dprintf 2 at 0x7ffff7fc50fd: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload-lib.c, line 23.
	  (gdb) n
	  Error in re-setting breakpoint 2: Function "foo" not defined.
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  warning: error removing breakpoint 2 at 0x7ffff7fc50fd
	  Cannot remove breakpoints because program is no longer writable.
	  Further execution is probably impossible.
	  60	  assert (res == 0);
	  (gdb)

	What happens here is that as the inferior steps over the dlclose call
	the shared library containing 'foo' is unloaded and
	disable_breakpoints_in_unloaded_shlib is called.  However in
	disable_breakpoints_in_unloaded_shlib we have this check:

	  if (b.type != bp_breakpoint
	     && b.type != bp_jit_event
	     && b.type != bp_hardware_breakpoint
	     && !is_tracepoint (&b))
	   continue;

	As the dprintf has type bp_dprintf then this check triggers and we
	ignore the dprintf, meaning the dprintf is not disabled.  When the
	inferior stops after the 'next' GDB tries to remove all breakpoints
	but the dprintf can no longer be removed, the memory in which it was
	placed has been unmapped from the inferior.

	The fix is to start using is_breakpoint() in
	disable_breakpoints_in_unloaded_shlib instead of the bp_breakpoint and
	bp_hardware_breakpoint checks.  The is_breakpoint() function also
	checks for bp_dprintf.

	With this fix in place GDB now correctly disables the breakpoint and
	we no longer see the warning about removing the breakpoint.

	During review it was pointed out that PR gdb/23149 and PR gdb/20208
	both describe something similar, though for these bugs, the inferior
	is restarted (which unloads all currently loaded shlib) rather than
	passing over the dlclose.  But the consequences are pretty similar.
	I've included a test which covers this case.

	One additional thing that these two bugs did show though is that
	disable_breakpoints_in_shlibs also needs to start using is_breakpoint
	for the same reason.  Without this change, when an inferior is
	restarted we get a warning like this for dprintf breakpoints:

	  warning: Temporarily disabling breakpoints for unloaded shared library "..."

	but we don't get a similar warning for "normal" breakpoints.  This is
	because disable_breakpoints_in_shlibs is called from clear_solib,
	which is called when an inferior is restarted.

	It is best not to think too hard about disable_breakpoints_in_shlibs,
	as this function is pretty broken, e.g. it doesn't call
	notify_breakpoint_modified, despite modifying the breakpoints.  But
	for now I'm ignoring that, but fixing this is definitely on my list
	for my next set of breakpoint related fixes, it's just that a lot of
	these breakpoint fixes end up being depending on one another, but I
	want to avoid making this series too long.  So for now, I'm ignoring
	the existing bug (missing breakpoint modified events), and fixing
	disable_breakpoints_in_shlibs to cover dprintf.

	With these fixes in place, the two bugs mentioned above should be
	fixed.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23149
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20208

	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: restructure disable_breakpoints_in_unloaded_shlib
	This commit rewrites disable_breakpoints_in_unloaded_shlib to be more
	like disable_breakpoints_in_freed_objfile.  Instead of looping over
	all b/p locations, we instead loop over all b/p and then over all
	locations for each b/p.

	The advantage of doing this is that we can fix the small bug that was
	documented in a comment in the code:

	  /* This may cause duplicate notifications for the same breakpoint.  */
	  notify_breakpoint_modified (b);

	By calling notify_breakpoint_modified() as we modify each location we
	can potentially send multiple notifications for a single b/p.

	Is this a bug?  Maybe not.  After all, at each notification one of the
	locations will have changed, so its probably fine.  But it's not
	ideal, and we can easily do better, so lets do that.

	There's a new test which checks that we only get a single notification
	when the shared library is unloaded.  Note that the test is written as
	if there are multiple related but different tests within the same test
	file ... but there aren't currently!  The next commit will add another
	test proc to this test script at which point the comments will make
	sense.  I've done this to avoid unnecessary churn in the next commit.

	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: fixes for code_breakpoint::disabled_by_cond logic
	I spotted that the code_breakpoint::disabled_by_cond flag doesn't work
	how I'd expect it too.  The flag appears to be "sticky" in some
	situations; once a code_breakpoint::disabled_by_cond flag is marked
	true, then, in some cases the flag wont automatically become false
	again, even when you'd think it should.

	The problem is in update_breakpoint_locations.  In this function,
	which is called as a worker of code_breakpoint::re_set, GDB computes a
	new set of locations for a breakpoint, the new locations are then
	installed into the breakpoint.

	However, before installing the new locations GDB attempts to copy the
	bp_location::enabled and bp_location::disabled_by_cond flag from the
	old locations into the new locations.

	The reason for copying the ::enabled flag makes sense.  This flag is
	controlled by the user.  When we create the new locations if GDB can
	see that a new location is equivalent to one of the old locations, and
	if the old location was disabled by the user, then the new location
	should also be disabled.

	However, I think the logic behind copying the ::disabled_by_cond flag
	is wrong.  The disabled_by_cond flag is controlled by GDB and should
	toggle automatically.  If the condition string can be parsed then the
	flag should be false (b/p enabled), if the condition string can't be
	parsed then the flag should be true (b/p disabled).

	As we always parse the condition string in update_breakpoint_locations
	before we try to copy the ::enabled flag value then the
	::disabled_by_cond flag should already be correct, there's no need to
	copy over the ::disabled_by_cond value from the old location.

	As a concrete example, consider a b/p placed within the main
	executable, but with a condition that depends on a variable within a
	shared library.

	When the b/p is initially created the b/p will be disabled as the
	condition string will be invalid (the shared library variable isn't
	available yet).

	When the inferior starts the shared library is loaded and the
	condition variable becomes available to GDB.  When the shared library
	is loaded breakpoint_re_set is called which (eventually) calls
	update_breakpoint_locations.

	A new location is computed for the breakpoint and the condition string
	is parsed.  As the shared library variable is now know the expression
	parses correctly and ::disabled_by_cond is left false for the new
	location.

	But currently GDB spots that the new location is at the same address
	as the old location and copies disabled_by_cond over from the old
	location, which marks the b/p location as disabled.  This is not what
	I would expect.

	The solution is simple, don't copy over disabled_by_cond.

	While writing a test I found another problem though.  The
	disabled_by_cond flag doesn't get set true when it should!  This is
	the exact opposite of the above.

	The problem here is in solib_add which is (despite the name) called
	whenever the shared library set changes, including when a shared
	library is unloaded.

	Imagine an executable that uses dlopen/dlclose to load a shared
	library.  Given an example of a b/p in the main executable that has a
	condition that uses a variable from our shared library, a library
	which might be unloaded with dlclose.

	My expectation is that, when the library is unloaded, GDB will
	automatically mark the breakpoint as disabled_by_cond, however, this
	was not happening.

	The problem is that in solib_add we only call breakpoint_re_set when
	shared libraries are added, not when shared libraries are removed.

	The solution I think is to just call breakpoint_re_set in both cases,
	now the disabled_by_cond flag is updated as I'd expect.

	Unfortunately, making this change causes a regression when running:

	  make check-gdb \
	     TESTS="gdb.trace/change-loc.exp" \
	     RUNTESTFLAGS="--target_board=native-gdbserver"

	This test unloads a shared library and expects breakpoints within the
	shared library to enter the PENDING state (because the bp_location's
	shlib_disabled flag will be set).  However, the new call to
	breakpoint_re_set means that this is no longer the case.

	The breakpoint_re_set call means that update_breakpoint_locations is
	called, which then checks if all locations for a breakpoint are
	pending or not.  In this test not all locations are pending, and so
	GDB recalculates the locations of each breakpoint, this means that
	pending locations are discarded.

	There is a but report PR gdb/32404 which mentions the problems with
	shlib_disabled pending breakpoints, and how they are prone to being
	randomly deleted if the user can cause GDB to trigger a call to
	breakpoint_re_set.  This patch just adds another call to
	breakpoint_re_set, which triggers this bug in this one test case.

	For now I have marked this test as KFAIL.  I do plan to try and
	address the pending (shlib_disabled) breakpoint problem in the future,
	but I'm not sure when that will be right now.

	There are, of course, tests to cover all these cases.

	During review I was pointed at bug PR gdb/32079 as something that this
	commit might fix, or help in fixing.

	And this commit is part of the fix for that bug, but is not the
	complete solution.  However, the remaining parts of the fix for that
	bug are not really related to the content of this commit.

	The problem in PR gdb/32079 is that the inferior maps multiple copies
	of libc in different linker namespaces using dlmopen (actually libc is
	loaded as a consequence of loading some other library into a different
	namespace, but that's just a detail).  The user then uses a 'next'
	command to move the inferior forward.

	GDB sets up internal breakpoints on the longjmp symbols, of which
	there are multiple copies (there is a copy in every loaded libc).

	However, the 'next' command is, in the problem case, stepping over a
	dlclose call which unloads one of the loaded libc libraries.

	In current HEAD GDB in solib_add we fail to call breakpoint_re_set()
	when the library is unloaded; breakpoint_re_set() would delete and
	then recreate the longjmp breakpoints.  As breakpoint_re_set() is not
	called GDB thinks that the the longjmp breakpoint in the now unloaded
	libc still exists, and is still inserted.

	When the inferior stops after the 'next' GDB tries to delete and
	remove the longjmp breakpoint which fails as the libc in which the
	breakpoint was inserted is no longer mapped in.

	When the user tries to 'next' again GDB tries to re-insert the still
	existing longjmp breakpoint which again fails as the memory in which
	the b/p should be inserted is no longer part of the inferior memory
	space.

	This commit helps a little.  Now when the libc library is unmapped GDB
	does call breakpoint_re_set().  This deletes the longjmp breakpoints
	including the one in the unmapped library, then, when we try to
	recreate the longjmp breakpoints (at the end of breakpoint_re_set) we
	don't create a b/p in the now unmapped copy of libc.

	However GDB does still think that the deleted breakpoint is inserted.
	The breakpoint location remains in GDB's data structures until the
	next time the inferior stops, at which point GDB tries to remove the
	breakpoint .... and fails.

	However, as the b/p is now deleted, when the user tries to 'next' GDB
	no longer tries to re-insert the b/p, and so one of the problems
	reported in PR gdb/32079 is resolved.

	I'll fix the remaining issues from PR gdb/32079 in a later commit in
	this series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079

	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-23  Tom Tromey  <tom@tromey.com>

	Fix formatting in dwarf2/index-write.c
	I noticed a spot in dwarf2/index-write.c that was mis-formatted.  This
	fixes it.

2025-02-23  Milica Matic  <milica.matic@htecgroup.com>

	MIPS: Apply coding guidelines: indentation
	Format mips-tdep.c code as described on links:

	https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
	https://www.gnu.org/prep/standards/standards.html#Comments

	correcting indentation as required.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Maciej W. Rozycki <macro@orcam.me.uk>

2025-02-23  Milica Matic  <milica.matic@htecgroup.com>

	MIPS: Apply coding guidelines: tabs
	Format mips-tdep.c code as described on links:

	https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
	https://www.gnu.org/prep/standards/standards.html#Comments

	converting spaces to tabs and fixing alignment as appropriate.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Maciej W. Rozycki <macro@orcam.me.uk>

2025-02-23  Milica Matic  <milica.matic@htecgroup.com>

	MIPS: Apply coding guidelines: sentences
	Format mips-tdep.c code as described on links:

	https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
	https://www.gnu.org/prep/standards/standards.html#Comments

	capitalizing sentences and adding full stops and spaces after them.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Maciej W. Rozycki <macro@orcam.me.uk>

2025-02-23  Milica Matic  <milica.matic@htecgroup.com>

	MIPS: Apply coding guidelines: new lines
	Format mips-tdep.c code as described on links:

	https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
	https://www.gnu.org/prep/standards/standards.html#Comments

	removing and adding new lines as appropriate.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Maciej W. Rozycki <macro@orcam.me.uk>

2025-02-23  Milica Matic  <milica.matic@htecgroup.com>

	MIPS: Apply coding guidelines: trailing space
	Format mips-tdep.c code as described on links:

	https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
	https://www.gnu.org/prep/standards/standards.html#Comments

	removing trailing space.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Maciej W. Rozycki <macro@orcam.me.uk>

2025-02-23  Alan Modra  <amodra@gmail.com>

	gas: avoid dangling pointers into freed memory
	The oss-fuzz gas fuzzer is quite broken in that it doesn't
	reinitialise all gas and bfd static variables between runs.  Since gas
	naughtily modifies bfd_und_section and bfd_abs_section those bfd
	statics can hold pointers into freed memory between runs.
	This patch fixes oss-fuzz issue 398060144.

2025-02-23  Alan Modra  <amodra@gmail.com>

	PR 32731 ub sanitizer accessing filenames_reversed
	tic4x-coff and mcore-pe tickle this bug by a peculiarity of their
	default ld scripts.

		PR 32731
		* ldlang.c (lang_add_wild): Init filenames_reversed when no
		filespec.

2025-02-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-22  Maximilian Ciric  <max.ciric@gmail.com>

	MIPS objdump: Recognize o64 ABI names
	Add gpr and fpr names for the o64 ABI to objdump.

	With the recent addition of both EABIs, this completes support for the
	standard ABI options (ABI-breaking options such as -modd-spreg or
	-mabi=32 -mfp64 notwithstanding). The names have been verified against
	GCC's usage of the registers. Notably, the only(?) documentation that
	defines the o64 ABI at

	https://gcc.gnu.org/projects/mipso64-abi.html

	appears to contain a mistake w.r.t. floating-point arguments. In
	particular:

	> If the first and second arguments floating-point arguments to a
	> function are 32-bit values, they are passed in $f12 and $f14.

	As from 4.0.0 this does not happen in GCC's implementation of the ABI;
	a pair of single-float arguments are still passed in $f12 and $f13, the
	same as when one or both of the arguments are double-precision floats.
	The registers $f12, $f13 and $f14 have been named $fa0, $fa1 and $ft10
	to match the implementation.

2025-02-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-21  Shahab Vahedi  <shahab.vahedi@amd.com>

	gdb/testsuite/rocm.exp: Use system GPU(s) to detect features
	gdb/testsuite/rocm.exp: Use system GPU(s) to detect features

	Background
	----------
	This patch revisits the purpose of hcc_amdgpu_targets{} in
	order to address the separation of concerns between:

	- GPU targets passed to the compiler.  This kind of target
	  is passed as an argument to flags like "--offload-arch=...",
	  "--targets=...", etc.

	- GPU targets as in available GPU devices on the system.  This
	  is crucial for finding which capabilities are available,
	  and therefore which tests should be executed or skipped.

	Code change
	-----------
	- A new "find_amdgpu_devices{}" procedure is added.  It is
	  responsible for listing the GPU devices that are available
	  on the system.

	- "hcc_amdgpu_targets{}" is rewritten to use the newly added
	  "find_amdgpu_devices{}" when there's no environment variable
	  (HCC_AMDGPU_TARGET) set.

	- The output of "hcc_amdgpu_targets{}" is now only used in
	  places that set the target for the building toolchains.

	- The output of "find_amdgpu_devices{}" is used anywhere that
	  needs to evaluate the GPU features.

	Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
	Change-Id: Ib11021dbe674aa40192737ede78284a1bc531513

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	IQ2000: drop maintainer
	After I found his email bouncing, Stan, via private communication which
	Nick helped with, has indicated that - having retired - he won't any
	longer fulfill the maintainer role here.

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	x86: GOT is an ELF-only entity
	Make md_undefined_symbol() conditional upon dealing with ELF, much like
	other architectures (e.g. Arm32 and Arm64) have it. This avoids errors
	in gas and even assertions in libbfd when "accidentally" e.g. a COFF-
	targeting source file uses "_GLOBAL_OFFSET_TABLE_" for whatever reason.

	While there also convert the final return statement to properly use
	NULL.

	NB: In principle 64-bit Mach-O knows GOT, too. Yet only an i?86-macho
	assembler can be built right now, as per configure.tgt. Pretty clearly
	adjustments to gotrel[] would also be necessary before these targets
	could actually work reasonably cleanly.

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	ix86: drop dead part of a conditional in elf_i386_convert_load_reloc()
	A few lines up we would have already bailed when "baseless && is_pic".

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	ix86: restrict use of GOT32X relocs
	The ELF linker rejects use of this reloc type without a base register
	for PIC code. Suppress its use by gas in such cases.

	To keep things building for non-ELF, include the entire containing if()
	in an #ifdef: All consumers of ->fx_tcbit* live in such conditionals as
	well, hence there's no reason to keep the producer active.

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	x86-64: further tighten convert-load-reloc checking
	REX2.M affects what insn we're actually dealing with, so we better check
	this to avoid transforming (future) insns we must not touch.

	x86: widen @got{,pcrel} support to PUSH and APX IMUL
	With us doing the transformation to an immediate operand for MOV and
	various ALU insns, there's little reason to then not support the same
	conversion for the other two insns which have respective immediate
	operand forms. Unfortunately for IMUL (due to the 0F opcode prefix)
	there's no suitable relocation, so the pre-APX forms cannot be marked
	for relaxation in the assembler.

	x86/APX: use CS: in place of ES: in @gotpcrel and @gottpoff relaxation
	H.J. requested this adjustment; I'm unaware of any specific technical
	background.

2025-02-21  Jan Beulich  <jbeulich@suse.com>

	ix86: tighten convert-load-reloc checking
	Just like was done recently for x86-64 (commit 4998f9ea9d35): Even if
	the assembler avoids using the relaxable relocation for inapplicable
	insns, the relocation type can still appear for other reasons. Be more
	thorough in the opcode checking we do, to avoid bogusly altering other
	insns.

	Furthermore correct an opcode mask (even if with the added condition
	that's now fully benign).

2025-02-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/doc: fix sentence in save gdb-index` command doc
	The part "... this command by default creates it produces a single ..."
	sounds wrong.  Replace with "... this command by default produces a
	single ...".

	Change-Id: I39cc533fa5a2bf473ca9e361ee0e6426d7d37ac6

2025-02-20  Tom Tromey  <tom@tromey.com>

	Fix "compilation unit" matching in dwarf-font-lock-keywords
	Today I learned that, at least on my system (Fedora 40), the printf
	"%#x" format will produce "0" rather than "0x0" when given 0 as an
	argument.

	This causes dwarf-mode.el to not correctly fontify the very first
	"Compilation Unit" line it sees.

	This patch adapts dwarf-mode.el.  As always, this patch bumps the
	version number for easier installation.

	I am checking this in.

2025-02-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb/doc: fix .debug_index -> .gdb_index
	Change-Id: Ibd8d6c35c2cc02e309f83b11b5fd1172dfa05283

2025-02-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/compile: add missing entry in bfd_link_callbacks array
	clang 19 fails to build gdb with this error:

	    /home/simark/src/binutils-gdb/gdb/compile/compile-object-load.c:302:3: error: cannot initialize a member subobject of type 'void (*)(const char *, ...) __attribute__((noreturn))' with an lvalue of type 'void (const char *, ...)'
	      302 |   link_callbacks_einfo, /* einfo */
	          |   ^~~~~~~~~~~~~~~~~~~~

	This illustrates that the bfd_link_callbacks array is missing an entry
	for the "fatal" callback, add it.

	The fatal field was added very recently, in d26161914 ("PR 32603, more
	ld -w misbehaviour").  We're lucky that the new callback was marked with
	the noreturn attribute and that clang checks that, otherwise this would
	have gone unnoticed.

	Change-Id: I68b63d89f2707359e6254da23bdc0776b0e03ba2

2025-02-20  Tom Tromey  <tromey@adacore.com>

	Handle optional lines correctly in gdb.ada/complete.exp
	While working on another series, I discovered that the existing code
	in gdb.ada/complete.exp that conditionally accepts a completion does
	not work correctly.  The code assumes that wrapping a line in "(...)?"
	will make the entire line optional, but really this will only match a
	blank line.

	Meanwhile, I needed this same patch for a second series I'm working
	on, so I've pulled this out.  As it only affects Ada, I am going to
	check it in.

2025-02-20  Tom Tromey  <tromey@adacore.com>

	Small get_tib_address cleanups
	I noticed a non-bool-like use of target_get_tib_address in
	windows-tdep.c.  After fixing this I thought it would be good to
	document the target method; and this also lead to some non-bool-like
	commentary in remote.c.  This patch fixes all of these nits.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-20  Guinevere Larsen  <guinevere@redhat.com>

	GDB: add stabs deprecation warning
	Now that stabs is deprecated, we should probably warn our users of it
	before removing support, so that they have time to react and either make
	themselves heard, or fix things on their end so that they can still debug
	their applications.

	This commit adds a new function that emits a warning whenever GDB does
	stabs reading. Since there are several places where stabs is
	re-invented, this warning had to be added to many places, but I think I
	managed to warn everywhere relevant without duplicating warnings.

	Also, the test gdb.stabs/weird.exp explicitly checks for GDB warnings
	when reading stabs, so it had to be updated to account for the
	deprecation warning. It is done generically, since it will be removed in
	the next release anyway.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-20  Alan Modra  <amodra@gmail.com>

	PR 32721, internal error in tc-i386.c:parse_register
	pr30117 showed one of the assertions added by 4d1bb7955a8b was too
	strict.  oss-fuzz also found the second assertion to be too strict,
	with this testcase distilled from 7k of garbage source:

	 A=%eax%%!
	 Y=A
	 Z=A
	 or $6,Z

		PR 32721
		* config/tc-i386.c (parse_register): Move "know" into
		condition.  Simplify.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Hoist language-finding in expand_symtabs_matching
	Right now, cooked_index_functions::expand_symtabs_matching computes
	the language for each component of a split name, using the language of
	the corresponding entry.

	Instead, I think that we want to do all the comparisons using the
	final entry's language.  I don't think there's a way to trigger bad
	behavior here right now, but with another series I'm working on, we
	end up with some entries whose language can't reliably be determined;
	and in this case using the final entry's language avoids issues.

	I suspect we could also dispense with the per-segment name-matcher
	lookup as well.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Move producer checks to dwarf2_cu
	This changes the various producer-checking functions to be methods on
	dwarf2_cu.  It adds a few new caching members as well -- every one
	that could reasonably be done this way has been converted, with the
	only exception being a gdbarch hook.

	Note the new asserts in the accessors.  Without the earlier
	prepare_one_comp_unit change, these could trigger in some modes.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Make prepare_one_comp_unit a method of cutu_reader
	This changes prepare_one_comp_unit to be a private method of
	cutu_reader.  This should make it somewhat simpler to reason about.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Clean up calls to prepare_one_comp_unit
	Currently, prepare_one_comp_unit is called somewhat haphazardly: it is
	mostly called when a CU is read, but some places manage to instantiate
	a cutu_reader* without calling it, and some code (e.g.,
	read_file_scope) calls it without really needing to.

	Aside from contributing to the general confusion around CU reading,
	this doesn't really cause problems in the current tree.  However, it
	is possible for the DWARF reader to check the CU's producer before it
	is ever set -- which is certainly unintended.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Move producer_is_realview to producer.c
	This moves the producer_is_realview to producer.c.

2025-02-20  Tom Tromey  <tom@tromey.com>

	Clean up DW_TAG_namelist handling in new_symbol
	In dwarf2/read.c:new_symbol, DW_TAG_namelist is listed in the same
	part of the "switch" as other tags.  However, it effectively shares no
	code with these.  This patch splits it into its own case.

	Longer term I think new_symbol should be split up drastically.

2025-02-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-19  Georg-Johann Lay  <avr@gjlay.de>

	gas/config/tc-avr.c: Fix an indentation glitch.
	gas/
		* config/tc-avr.c (md_assemble): Fix indentation.

2025-02-19  Lancelot Six  <lancelot.six@amd.com>

	gdb/mi: Fix segfault when attaching a rocm process with MI
	When using the MI interpreter, if someone was to attach to a ROCm
	process which has active GPU waves, GDB would issue a segfault as
	follows:

	    attach 1994813
	    &"attach 1994813\n"
	    ~"Attaching to process 1994813\n"
	    =thread-group-started,id="i1",pid="1994813"
	    =thread-created,id="1",group-id="i1"
	    =thread-created,id="2",group-id="i1"
	    ~"[New LWP 1994828]\n"
	    *running,thread-id="2"
	    =thread-created,id="3",group-id="i1"
	    ~"[New LWP 1994825]\n"
	    *running,thread-id="3"
	    =thread-created,id="4",group-id="i1"
	    ~"[New LWP 1994823]\n"
	    *running,thread-id="4"
	    ^done
	    =library-loaded,...
	    [...]
	    ~"[Thread debugging using libthread_db enabled]\n"
	    ~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n"
	    =thread-created,id="5",group-id="i1"
	    &"\n\n"
	    &"Fatal signal: "
	    &"Segmentation fault"
	    &"\n"
	    &"----- Backtrace -----\n"
	    &"Backtrace unavailable\n"
	    &"---------------------\n"
	    &"A fatal error internal to GDB has been detected, further\ndebugging is not possible.  GDB will now terminate.\n\n"
	    &"This is a bug, please report it."
	    &"  For instructions, see:\n"
	    &"<https://github.com/ROCm-Developer-Tools/ROCgdb/issues>"
	    &"."
	    &"\n\n"
	    Segmentation fault

	The issue comes from using a non-initialized pointer in mi_on_resume_1:

	    if (!mi->running_result_record_printed && mi->mi_proceeded)
	      {
	        gdb_printf (mi->raw_stdout, "%s^running\n",
	                    mi->current_token ? mi->current_token : "");
	      }

	In this instance, "mi->current_token" has an uninitialized value.  This is a
	regression introduced by:

	    commit def2803789208a617c429b5dcf2026decb25ce0c
	    Date:   Wed Sep 6 11:02:00 2023 -0400

	        gdb/mi: make current_token a field of mi_interp

	Before this patch, current_token was a global implicitly 0-initialized.  Since
	it is now a class field, it is not 0-initialized by default anymore.  This
	patch changes this.

	Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: add logging for CU expansion
	I was trying to get an understanding of which CUs were expanded when,
	and how much time it was taking.  I wrote this patch to add some logging
	related to that, and I think it would be useful to have upstream, to
	better understand performance problems related to over-eager CU
	expansion, for example.

	 - add DWARF_READ_SCOPED_DEBUG_START_END
	 - use it in process_queue, to wrap the related expansion messages
	   together
	 - add a message in maybe_queue_comp_unit when enqueuing a comp unit
	 - add timing information to messages in process_queue, indicating how
	   much time it took to expand a given symtab
	 - count the number of expansions done in a single call to process_queue

	    [dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
	      [dwarf-read] process_queue: Expanding symtab of CU at offset 0xc
	      [dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2
	      [dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s
	      [dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b
	      [dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s
	      [dwarf-read] process_queue: Done expanding 2 symtabs.
	    [dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...

	Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: set is_debug_types in signatured_type constructor
	This makes it more obvious that all created signatured_type objects have
	this flag set.

	Also, remove an unnecessary assignment in create_cus_hash_table: when
	constructing the dwarf2_per_cu_data object, is_debug_types is already
	initialized to 0/false.

	Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: pass section to dwarf2_per_cu_data constructor
	Same as the previous patch, but for the containing section.

	Change-Id: I469147cce21525d61b3cf6edd9a9f4b12027c176
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor
	Similar to the previous patch, but for the offset within the containing
	section.

	Change-Id: I1d76e1f88002bca924e0b12fd78c7ea49d36c0ec
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: pass dwarf2_per_bfd to dwarf2_per_cu_data constructor
	Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set
	the per_bfd field there.  All "real" instantiations of
	dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd
	backlink, this makes it a bit more obvious.  The instantiations of
	dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones
	used to do hash map lookups and the ones used in selftests.

	Remove an unnecessary assignment of per_bfd in
	fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when
	the signatured_type object is constructor (before that, it was set in
	allocate_signatured_type).

	Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: change some functions from "per objfile" to "per bfd"
	I noticed that the following functions accept a "dwarf2_per_objfile",
	but they can actually accept a less specific "dwarf2_per_bfd".  This
	makes it more obvious that the work they do is per BFD and not per
	objfile.

	 - add_type_unit
	 - lookup_dwo_file_slot
	 - create_dwo_unit_in_dwp_v1
	 - create_dwp_v2_or_v5_section
	 - create_dwo_unit_in_dwp_v2
	 - create_dwo_unit_in_dwp_v5
	 - lookup_dwo_unit_in_dwp

	Change-Id: I200cd77850ce0ffa29fc1b9d924056fdce2559f8
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: std::unordered_{set,map} -> gdb::unordered_{set,map} throughout
	No behavior changes expected.

	Change-Id: I16ff6c67058362c65cc8edb05d1948e48be6b2e1
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Qwinci  <qwinci222@gmail.com>

	gdb/remote: don't error if qGetTIBAddr is unsupported
	This change makes it possible to debug PE executables run in e.g. Qemu
	without needing to set osabi to none, it breaks backtrace
	and commands like finish if frame pointers are not present but SEH unwind info is.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-19  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Extend the maximum number of hardware watchpoints
	The maximum number of load/store watchpoints and fetch instruction
	watchpoints is 14 each according to LoongArch Reference Manual [1],
	so extend the maximum number of hardware watchpoints from 8 to 14.

	A new struct user_watch_state_v2 was added into uapi in the related
	kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
	watchpoints") [2], but there may be no struct user_watch_state_v2 in
	the system header in time. Modify the struct loongarch_user_watch_state
	in GDB which is same with the uapi struct user_watch_state_v2.

	As far as I can tell, the only users for this struct in the userspace
	are GDB and LLDB, there are no any problems of software compatibility
	between the application and kernel according to the analysis.

	The compatibility problem has been considered while developing and
	testing. When the applications in the userspace get watchpoint state,
	the length will be specified which is no bigger than the sizeof struct
	user_watch_state or user_watch_state_v2, the actual length is assigned
	as the minimal value of the application and kernel in the generic code
	of ptrace:

	kernel/ptrace.c: ptrace_regset():

		kiov->iov_len = min(kiov->iov_len,
	                            (__kernel_size_t) (regset->n * regset->size));

		if (req == PTRACE_GETREGSET)
	                return copy_regset_to_user(task, view, regset_no, 0,
	                                           kiov->iov_len, kiov->iov_base);
		else
	                return copy_regset_from_user(task, view, regset_no, 0,
	                                             kiov->iov_len, kiov->iov_base);

	For example, there are four kind of combinations, all of them work well.

	(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
	(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
	(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
	(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

	BTW, LLDB also made this change in the related commit ff79d83caeee
	("[LLDB][LoongArch] Extend the maximum number of watchpoints") [3]

	[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
	[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e
	[3] https://github.com/llvm/llvm-project/commit/ff79d83caeee

2025-02-19  Alan Modra  <amodra@gmail.com>

	bintuils/dwarf.c indentation fixes
	plus a few other formatting fixes.

2025-02-19  Alan Modra  <amodra@gmail.com>

	binutils/dwarf.c debug_information leak
	It is possible with fuzzed files to have num_debug_info_entries zero
	after allocating space for debug_information, leading to multiple
	allocations.

		* dwarf.c (process_debug_info): Don't test num_debug_info_entries
		to determine whether debug_information has been allocated,
		test alloc_num_debug_info_entries.

2025-02-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver, remote: introduce "id_str" in the "qXfer:threads:read" XML
	GDB prints the target id of a thread in various places such as the
	output of the "info threads" command in the "Target Id" column or when
	switching to a thread.  A target can define what to print for a given
	ptid by overriding the `pid_to_str` method.

	The remote target is a gateway behind which one of many various
	targets could be running.  The remote target converts a given ptid to
	a string in a uniform way, without consulting the low target at the
	server-side.

	In this patch we introduce a new attribute in the XML that is sent in
	response to the "qXfer:threads:read" RSP packet, so that a low target
	at the server side, if it wishes, can specify what to print as the
	target id of a thread.

	Note that the existing "name" attribute or the "extra" text provided
	in the XML are not sufficient for the server-side low target to
	achieve the goal.  Those attributes, when present, are simply appended
	to the target id by GDB.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-18  Alan Modra  <amodra@gmail.com>

	PR32715, ld-elf/pr29072 fail with --disable-default-execstack
	--disable-default-stack is an alias for --enable-default-execstack=no.
	The existing check only looked for the latter config option.

		PR 32715
		* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Look
		in config.h for result of --enable-default-execstack.

2025-02-18  Alan Modra  <amodra@gmail.com>

	PR32716, objdump -i memory leak
		PR binutils/32716
		* bucomm.c (display_info): Free arg.info.

2025-02-18  Alan Modra  <amodra@gmail.com>

	PR32703, Null pointer dereference in bfd/linker.c
	NULL is a possible return from bfd_section_already_linked_table_lookup
	if out-of-memory.

		PR 32703
		* linker.c (_bfd_generic_section_already_linked): Catch
		bfd_section_already_linked_table_lookup failure.
		* coffgen.c (_bfd_coff_section_already_linked): Likewise.

2025-02-18  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	testsuite, mi: prevent buffer overflow in get_mi_thread_list
	If there is a large number of threads in the input program, the expect
	buffer in `get_mi_thread_list` would become full.  Prevent this by
	consuming the buffer in small pieces.

	Regression-tested using the gdb.mi tests.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't start gdb in gdb.base/gstack.exp
	In test-case gdb.base/gstack.exp we start a gdb implicitly using
	prepare_for_testing.

	The gdb is not really used, but its spawn_id (available in variable
	gdb_spawn_id) is used in a gdb_test_multiple, which is used to interact with
	the gstack process.

	Usually, a running gdb is cleaned up at test-case exit in gdb_finish, which
	calls gdb_exit, which by default calls gdb_default_exit, which does
	'send_gdb "quit\n"'.

	However, this sends a quit to the host process expect is currently talking to,
	defined by board_info(host,fileid), and after spawning gstack that's gstack, not
	gdb.

	Fix this by:
	- using build_executable instead of prepare_for_testing to not spawn an unused
	  gdb, and
	- changing the gdb_test_multiple into a gdb_expect, eliminating the implicit use
	  of gdb_spawn_id.

	Tested on x86_64-linux.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

	PR testsuite/32709
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709

2025-02-18  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix some typos
	Fix typos:
	...
	overriden -> overridden
	reate -> create
	...

	Tested on x86_64-linux.
	I

2025-02-18  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add tests for PR ld/32690
	Without

	commit 230a788eb28a64d628e623068c44add2a24aa5d3
	Author: Alan Modra <amodra@gmail.com>
	Date:   Tue Feb 18 08:54:06 2025 +1030

	    PR32690, assertion failure in lang_size_relro_segment

	this test triggers the linker error:

	.../ld: internal error .../ld/ldlang.c 6618
	collect2: error: ld returned 1 exit status

	with GCC 10 or above on x86-64.

		PR ld/32690
		* testsuite/ld-elf/elf.exp: Run PR ld/32690 tests.
		* testsuite/ld-elf/pr32690.h: New file.
		* testsuite/ld-elf/pr32690a.c: Likewise.
		* testsuite/ld-elf/pr32690b.c: Likewise.

2025-02-18  Alan Modra  <amodra@gmail.com>

	Re: bfd_set_section_alignment errors.
	Fix another one for aarch64.

2025-02-18  Alan Modra  <amodra@gmail.com>

	Use bfd_link_align_section in a few more places
	Some of these aren't relevant to the relro bug.  Some are.  They all
	matter if early estimation of section layout needs to be good.

		PR ld/32690
		* elf32-bfin.c (bfin_adjust_dynamic_symbol),
		* elf32-hppa.c (elf32_hppa_late_size_sections),
		* elf32-microblaze.c (microblaze_elf_adjust_dynamic_symbol),
		* elf32-nds32.c (nds32_elf_adjust_dynamic_symbol),
		* elf64-ppc.c (size_global_entry_stubs),
		* elflink.c (_bfd_elf_tls_setup),
		* elfxx-mips.c (mips_elf_add_la25_intro),
		(mips_elf_add_la25_trampoline),
		(_bfd_mips_elf_adjust_dynamic_symbol),
		* elfxx-x86.c (_bfd_x86_elf_late_size_sections): Use
		bfd_link_align_section to ensure correct output section
		alignment.

2025-02-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-17  Alan Modra  <amodra@gmail.com>

	bfd_set_section_alignment errors
	I noticed when making the change from "einfo" to "fatal" that the
	alignment error in _bfd_elf_link_create_gnu_property_sec lacked a %P,
	and then decided that a bfd_set_section_alignment that can't happen
	does not merit a separate error message.  elfxx-x86.c had copied the
	same code, so fix that too.  In fact, every bfd_set_section_alignment
	call in elfxx-x86.c will always return true absent some future
	programming error.  This patch makes those that accompany making a
	section lose their "failed to align " error and share the "failed to
	create" error.  Those that are changing alignment of a section created
	elsewhere now abort on bfd_set_section_alignment returning false.

	PR 32603, more ld -w misbehaviour
	Commit 8d97c1a53f3d claimed to replace all einfo calls using %F with
	a call to fatal.  It did so only for the ld/ directory.  This patch
	adds a "fatal" to linker callbacks, and replaces those calls in bfd/
	too.

2025-02-17  Alan Modra  <amodra@gmail.com>

	PR32690, assertion failure in lang_size_relro_segment
	This introduces a new function which should be used whenever the
	linker needs to increase section alignment after mapping input to
	output sections.

		PR ld/32690
		* linker.c (bfd_link_align_section): New function.
		* elflink.c (_bfd_elf_adjust_dynamic_copy): Use it.
		* bfd-in2.h: Regenerate.

2025-02-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: make maybe_queue_comp_unit return bool
	Change-Id: I9a6bf27b72f7efb1cc4cea5345db14969e794bdb

	gdb/dwarf: remove spurious space
	Change-Id: I420280721cb734a2e061743309bf9b25d2179f8f

2025-02-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused include in symfile-debug.c
	This is reported as unused by clangd.

	Change-Id: Ida5a93b632cd4477fb91df1ab0edf66f12a28f64

2025-02-17  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused include in objfiles.h
	clangd reports this include as unused.

	Change-Id: I6a4224d8aa581fea2336da124c89ade09f573af3

2025-02-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	testsuite, mi: fix indentation in get_mi_thread_list
	The `get_mi_thread_list` procedure's body is incorrectly indented.
	Fix it.

	There is one line that was already long.  Consider it an exception and
	don't bother breaking it.

2025-02-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-16  Andrew Oates  <andrew@andrewoates.com>

	gdb: fix color_option_def compile error (clang)
	color_option_def was added in commit 6447969d0 ("Add an option with a
	color type."), but not used.

	The color_option_def constructor passes the wrong number of arguments
	to the option_def constructor.  Since color_option_def is a template and
	never actually instantiated, GCC does not fail to compile this.  clang
	generates an error (see below).

	This passes nullptr to the extra_literals_ option_def ctor argument,
	which matches what filename_option_def above it does.

	clang's generated error:
	  ../../gdb/cli/cli-option.h:343:7: error: no matching constructor for initialization of 'option_def'
	      : option_def (long_option_, var_color,
	        ^           ~~~~~~~~~~~~~~~~~~~~~~~~
	  ../../gdb/cli/cli-option.h:50:13: note: candidate constructor not viable: requires 8 arguments, but 7 were provided
	    constexpr option_def (const char *name_,
	              ^
	  ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 7 were provided
	  struct option_def
	         ^
	  ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 7 were provided

	Approved-By: Tom de Vries <tdevries@suse.de>

2025-02-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-15  Alan Modra  <amodra@gmail.com>

	score-elf gas SEGV
	Commit 3fb6f5457e5b typoed an array subscript.

		* config/tc-score7.c (s7_gen_reloc): Correct array subscript.
		* testsuite/gas/score/pr32700.d,
		* testsuite/gas/score/pr32700.s: New test.
		* testsuite/gas/score/relax.exp: Run it.

2025-02-15  Alan Modra  <amodra@gmail.com>

	PR32698, potential null pointer dereference in tekhex.c
		PR 32698
		* tekhex.c (find_chunk): Remove unnecessary casts.
		(insert_byte): Check and return status from find_chunk.
		(move_section_contents): Likewise.
		(tekhex_get_section_contents, tekhex_set_arch_mach): Return
		status from move_section_contents.
		(first_phase): Check and return status from first_phase.

2025-02-15  Alan Modra  <amodra@gmail.com>

	riscv disassembler leak
	Commit 3f61a38b5e81 moved the disassembler subset_list from a static
	variable to disassembler private_data.  It is now malloc'd in
	riscv_init_disasm_info so should be freed when disassemble_free_target
	runs.

		* riscv-dis.c (disassemble_free_riscv): Free subset_list.

2025-02-15  Anghelo Carvajal  <angheloalf95@gmail.com>

	MIPS objdump: Add `eabi32` and `eabi64` ABI options
	Extend gpr and fpr register names with names suitable for both EABIs.

	Heavily inspired by the EABI documenation written by Eric Christopher,
	which can be read at
	https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html

	2025-02-15  Anghelo Carvajal  <angheloalf95@gmail.com>

		* mips-dis.c (mips_fpr_names_eabi32): New variable.
		(mips_fpr_names_eabi64): New variable.
		(mips_abi_choices): Add "eabi32" and "eabi64" options.

2025-02-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Reuse n64 GPR disassembly for n32
	The MIPS ABI register names are the same between n64 and n32, so remove
	duplication and use n64 GPR disassembly output for the n32 test as well.
	The tests were developed long before we gained output reuse support.

	MIPS/GAS: Fix comment about "img" vendor configurations
	Adjust a comment about "img" vendor configurations to comply with the
	GNU coding standards.

2025-02-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS: Set default CPU to MIPS64r6 for 64-bit "img" configurations
	Fix broken commit 070961b377b3 ("MIPS: Set r6 as default arch if vendor
	is img") that sets up GAS in an inconsistent way where "img" vendor has
	been used with a 64-bit configuration, such as `mips64-img-linux-gnu'.
	In that case GAS is set up to use a 64-bit ABI by default combined with
	the MIPS32r6 CPU, which is 32-bit.

	Consequently GAS always fails to assemble even trivial input, producing
	a message such as:

	Assembler messages:
	Error: -march=mips32r6 is not compatible with the selected ABI
	.../gas/testsuite/gas/all/nop.s:2: Error: `gp=32' used with a 64-bit ABI

	unless the defaults have been suitably overridden either for the ABI or
	the CPU.

	Set the default CPU to MIPS64r6 for 64-bit "img" vendor configurations
	then and adjust the GAS testsuite accordingly, removing 1048 FAIL and 3
	ERROR regression test results for the `mips64-img-linux-gnu' and
	`mips64el-img-linux-gnu' targets each.

2025-02-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Support negated targets for default architecture
	Add support for giving negated targets in the list of targets passed to
	`mips_arch_create' for the purpose of setting the default architecture.
	This is so that a subset of targets can be excluded from matching within
	a broader set of targets.

2025-02-15  Ivan Kokshaysky  <ink@unseen.parts>

	alpha, ld: remove -taso option
	The -taso switch was quite useful 25 years ago for porting 32-bit
	code with broken integer-pointer casting. Not anymore. The EF_ALPHA_32BIT
	Linux support is going to be dropped in kernel v6.14 [1], NetBSD and OpenBSD
	never had it, so there is no point in keeping the -taso option around.

	Also remove alpha special case that uses -taso from gdb.base/dump.exp
	in gdb testsuite.

	[1] https://lore.kernel.org/all/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org

	Reviewed-By: Maciej W. Rozycki <macro@orcam.me.uk>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: clean ups in gdb.python/py-source-styling.exp
	The top comment in gdb.python/py-source-styling.exp was completely
	wrong, clearly a cut&paste job from elsewhere.  Write a comment that
	actually reflects what the test does.

	I've also moved the allow_python_tests check earlier in the file.

	And I changed some 'return -1' into just 'return'.  I'm not aware that
	the '-1' adds any value.

	I also folded a 'pass $gdb_test_name' into the preceding gdb_assert,
	which I think is neater.

	There is no change in what is actually being tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: use maybe_update for source centring in an extra case
	I noticed that, with recent versions of GDB, when the TUI is enabled
	before the inferior is started, the source code display is not as
	helpful as it used to be.  Here's a simple test program being
	displayed using GDB 15.2, at this point the inferior has not started,
	all I've done is 'tui enable':

	  ┌─hello.c────────────────────────────────────────────────┐
	  │     10   return 0;                                     │
	  │     11 }                                               │
	  │     12                                                 │
	  │     13 /* The main function.  */                       │
	  │     14                                                 │
	  │     15 int                                             │
	  │     16 main ()                                         │
	  │     17 {                                               │
	  │     18   printf ("Hello World\n");                     │
	  │     19   call_me ( 0, 1, 2, 3, 4, 5, 6, 7 );           │
	  │     20   return 0;                                     │
	  │     21 }                                               │
	  │                                                        │
	  │                                                        │
	  └────────────────────────────────────────────────────────┘

	Compare this to GDB 16.2:

	  ┌─hello.c────────────────────────────────────────────────┐
	  │       17 {                                             │
	  │       18   printf ("Hello World\n");                   │
	  │       19   call_me ( 0, 1, 2, 3, 4, 5, 6, 7 );         │
	  │       20   return 0;                                   │
	  │       21 }                                             │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  │                                                        │
	  └────────────────────────────────────────────────────────┘

	I think the new layout is not as good because it is missing the
	context of the function name.  The new behaviour started with the
	commit:

	  commit 49e607f511c1fab82a0116990a72d1915c74bb4a
	  Author: Stephan Rohr <stephan.rohr@intel.com>
	  Date:   Sat Aug 3 02:07:42 2024 -0700

	      gdb: adjust the default place of 'list' to main's prologue

	I don't think the new behaviour is really a problem with that commit,
	rather, when using 'tui enable' before the inferior has started GDB
	ends up calling tui_source_window_base::rerender(), and then passes
	through the code path which calls update_source_window_with_addr().

	When using 'tui enable' after the inferior has started, GDB again
	calls tui_source_window_base::rerender(), but this time has a frame,
	and so takes the second code path, which centres the selected source
	line, and then calls update_source_window.

	The point is that the update_source_window_with_addr() path doesn't
	include the logic to centre the source line.

	Before the above commit this was fine as GDB's default location would
	be prior to main, and so we got the "good" TUI output.  After the
	above commit the default location is now main's prologue, and without
	the centring logic, the first line shown is main's prologue.

	I propose fixing this by having update_source_window_with_addr() call
	maybe_update().  This will first check if the requested line is
	already visible, and if not, show the requested line with centring
	applied.

	After this commit, the 'tui enable' state is now:

	  ┌─hello.c─────────────────────────────────────────────────────┐
	  │       11 }                                                  │
	  │       12                                                    │
	  │       13 /* The main function.  */                          │
	  │       14                                                    │
	  │       15 int                                                │
	  │       16 main ()                                            │
	  │       17 {                                                  │
	  │       18   printf ("Hello World\n");                        │
	  │       19   call_me ( 0, 1, 2, 3, 4, 5, 6, 7 );              │
	  │       20   return 0;                                        │
	  │       21 }                                                  │
	  │                                                             │
	  │                                                             │
	  │                                                             │
	  └─────────────────────────────────────────────────────────────┘

	It's not identical to the old behaviour, but that was never the
	objective, we do however, see the context around main's prologue,
	which will usually be enough to see the function name and return type,
	which I think is useful.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: update maybe_update to take gdbarch
	This is a refactor to setup for the next commit.

	The maybe_update function currently takes a frame_info_ptr&, however,
	it only uses this to get the frame's gdbarch.

	In the next commit I want to call maybe_update when I have a gdbarch,
	but no frame_info_ptr& (the inferior hasn't even started).

	So, update maybe_update to take the gdbarch, and update the callers to
	pass that through.  Most callers already have the gdbarch to hand, but
	in one place I do need to extract this from the frame_info_ptr&.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Tom Tromey  <tom@tromey.com>

	Handle DW_FORM_data4 in read-debug-names.c
	The recent .debug_names patches caused the writer to emit
	DW_FORM_data4.  Unfortunately the reader did not handle this form.

	This patch updates the reader to handle a few DW_FORM_data* forms.

	The complaint that is there went unnoticed -- I only found this when
	debugging a failure in another series.  More evidence, IMO, that
	complaints should be removed.

	I think the reason the failure itself went unnoticed is that the
	symbol table code in gdb often works by accident, and in particular in
	small programs like the ones in the test suite, it's often the case
	that a CU will be expanded for some other reason, causing the test to
	pass without really touching the index code.  The aforementioned
	series is aimed at fixing this.

	It would probably be good to unify the abbrev/form code to some
	degree, but it's mildly a pain as some forms don't make sense here and
	because we recently discovered other issues with gdb's DW_FORM_data*
	handling.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: use `gdb::unordered_map`
	Replace the few uses of `std::unordered_map` in gdbserver with
	`gdb::unordered_map`.

	The only one of these that is likely to ever see a lot of elements is
	probably `process_info::m_ptid_thread_map`.  It was added precisely to
	improve performance when there are a lot of threads, so I guess using
	`gdb::unordered_map` here won't hurt.  I changed the others too, since
	it's easy.

	Change-Id: Ibc4ede5245551fdd7717cb349a012d05726f4363
	Reviewed-By: Stephan Rohr <stephan.rohr@intel.com>

2025-02-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: unique_ptr cleanup
	Throughout gdb/dwarf2, use `*_up` typedefs.  Add a few missing typedefs,
	and move some so they are, ideally, just after the corresponding class.

	Change-Id: Iab5cd8fc2e9989d4bd8d4868586703c2312f254f
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename cooked_index_worker subclasses
	Rename them to include "worker" in the name.  Otherwise, it's easy to be
	confused and think that they are sub-classes of "cooked_index".

	Change-Id: I625ef076f9485f3873db530493f60a53d02c1991
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: use term "shard" instead of "index"
	A bit more changes as in 8e745eac7db3 ("gdb/dwarf: rename
	cooked_index::m_vector to m_shards").  I think it's clearer if the term
	"index" is reserved for the whole thing, while "shard" or "index shard"
	are used for the parts.

	Change-Id: I457bb0016a70f3f9918f4a3c3977262a7801705b
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/python/dap: prefix internal attributes with underscore
	I'm currently reading the DAP code, and I think this would help.  This
	is pretty much standard Python style, we do it as some places but not
	others.  I think it helps readability, by saying that this attribute
	isn't mean to be accessed outside the class.

	A similar pass could be done for internal methods, I haven't done that.

	Change-Id: I8e8789b39adafe62d14404d19f7fc75e2a364e01
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: only update m_last_subfile after writing a line table entry
	While working on another patch which changes how we parse the line
	DWARF line tables I noticed what I think is a minor bug in how we
	process the line tables.

	What I noticed is that my new line table parser was adding more END
	markers into the parsed table than GDB's current approach.  This
	difference was observed when processing the debug information for
	libstdc++.

	Here is the line table from the new test, this is a reasonable
	reproduction of the problem case that I observed in the actual debug
	line table:

	  Contents of the .debug_line section:

	  dw2-skipped-line-entries-1.c:
	  File name                        Line number    Starting address    View    Stmt
	  dw2-skipped-line-entries-1.c             101            0x40110a               x

	  /tmp/dw2-skipped-line-entries-2.c:
	  dw2-skipped-line-entries-2.c             201            0x401114               x

	  /tmp/dw2-skipped-line-entries-3.c:
	  dw2-skipped-line-entries-3.c             301            0x40111e               x

	  /tmp/dw2-skipped-line-entries-1.c:
	  dw2-skipped-line-entries-1.c             102            0x401128               x
	  dw2-skipped-line-entries-1.c             103            0x401128               x
	  dw2-skipped-line-entries-1.c             104            0x401128               x

	  /tmp/dw2-skipped-line-entries-2.c:
	  dw2-skipped-line-entries-2.c             211            0x401128

	  /tmp/dw2-skipped-line-entries-3.c:
	  dw2-skipped-line-entries-3.c             311            0x401132

	  /tmp/dw2-skipped-line-entries-1.c:
	  dw2-skipped-line-entries-1.c             104            0x40113c
	  dw2-skipped-line-entries-1.c             105            0x401146               x
	  dw2-skipped-line-entries-1.c               -            0x401150

	The problem is caused by the entry for line 211.  Notice that this
	entry is at the same address as the previous entries.  Further, the
	entry for 211 is a non-statement entry, while the previous entries are
	statement entries.

	As the entry for line 211 is a non-statement entry, and the previous
	entries at that address are statement entries in a different symtab,
	it is thought that it is better to prefer the earlier entries (in
	dw2-skipped-line-entries-1.c), and so the entry for line 211 will be
	discarded.

	As GDB parses the line table it switches between the 3 symtabs (based
	on source filename) adding the relevant entries to each symtab.
	Additionally, as GDB switches symtabs, it adds an END entry to the
	previous symtab.

	The problem then is that, for the line 211 entry, this is the only
	entry in dw2-skipped-line-entries-2.c before we switch symtab again.
	But the line 211 entry is discarded.  This means that GDB switches
	from dw2-skipped-line-entries-1.c to dw2-skipped-line-entries-2.c, and
	then on to dw2-skipped-line-entries-3.c without ever adding an entry
	to dw2-skipped-line-entries-2.c.

	And here then is the bug.  GDB updates its idea of the previous symtab
	not when an entry is written into a symtab, but every time we change
	symtab.

	In this case, when we switch to dw2-skipped-line-entries-3.c we add
	the END marker to dw2-skipped-line-entries-2.c, even though no entries
	were written to dw2-skipped-line-entries-2.c.  At the same time, no
	END marker is ever written into dw2-skipped-line-entries-1.c as the
	dw2-skipped-line-entries-2.c entry (for line 211) was discarded.

	Here is the 'maint info line-table' for dw2-skipped-line-entries-1.c
	before this patch:

	  INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END EPILOGUE-BEGIN
	  0      101    0x000000000040110a 0x000000000040110a Y
	  1      END    0x0000000000401114 0x0000000000401114 Y
	  2      102    0x0000000000401128 0x0000000000401128 Y
	  3      103    0x0000000000401128 0x0000000000401128 Y
	  4      104    0x0000000000401128 0x0000000000401128 Y
	  5      104    0x000000000040113c 0x000000000040113c
	  6      105    0x0000000000401146 0x0000000000401146 Y
	  7      END    0x0000000000401150 0x0000000000401150 Y

	And after this patch:

	  INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END EPILOGUE-BEGIN
	  0      101    0x000000000040110a 0x000000000040110a Y
	  1      END    0x0000000000401114 0x0000000000401114 Y
	  2      102    0x0000000000401128 0x0000000000401128 Y
	  3      103    0x0000000000401128 0x0000000000401128 Y
	  4      104    0x0000000000401128 0x0000000000401128 Y
	  5      END    0x0000000000401132 0x0000000000401132 Y
	  6      104    0x000000000040113c 0x000000000040113c
	  7      105    0x0000000000401146 0x0000000000401146 Y
	  8      END    0x0000000000401150 0x0000000000401150 Y

	Notice that we gained an extra entry, the END marker that was added at
	position #5 in the table.

	Now, does this matter?  I cannot find any bugs that trigger because of
	this behaviour.

	So why fix it?  First, the current behaviour is inconsistent, as we
	switch symtabs, we usually get an END marker in the previous symtab.
	But occasionally we don't.  I don't like things that are inconsistent
	for no good reason.  And second, as I said, I want to change the line
	table parsing.  To do this I want to check that my new parser creates
	an identical table to the current parser.  But my new parser naturally
	"fixes" this inconsistency, so I have two choices, do extra work to
	make my new parser bug-compatible with the current one, or fix the
	current one.  I'd prefer to just fix the current line table parser.

	There's a test that includes the above example and checks that the END
	markers are put in the correct place.  But as I said, I've not been
	able to trigger any negative behaviour from the current solution, so
	there's no test that exposes any broken behaviour.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-14  Jan Beulich  <jbeulich@suse.com>

	x86: drop redundant i.operands checks from output_disp()
	The opcode space, major opcode, and - where applicable - opcode
	extension checks fully qualify the insns we're after; operand matching
	has been done far earlier, so wrong operand counts cannot occur here.

	x86: drop redundant checks from ISA-used version determination
	All F16C and all FMA insns are VEX-encoded; there's no need to check
	for their Cpu* attributes.

2025-02-14  Jan Beulich  <jbeulich@suse.com>

	x86: correct ISA-used version recording
	Updating should be based solely on the current instruction. For example,
	recording of VEX-encoded insns as v3 should be independent of there
	being earlier AMX insns.

	Further for BASELINE only a very limited set of the
	GNU_PROPERTY_X86_FEATURE_2_* bits should actually be taken into account:
	Most of the bits represent advanced (later) features (XSAVE, XSAVEOPT,
	and XSAVEC for example being part of v3).

2025-02-14  Jan Beulich  <jbeulich@suse.com>

	gas: fix rs_fill_nop listing
	In commit a0094f1a70e1 ("gas: make .nops output visible in listing") I
	was wrongly assuming fr_fix would be zero for rs_fill_nop, when that's
	only a side effect of listing_newline() inserting dummy frags, but only
	when file/line did actually change from the previous invocation. This is
	in particular not going to be true when the .nops directive isn't the
	first statement on a line.

2025-02-14  Jan Beulich  <jbeulich@suse.com>

	x86/APX: make .insn extended-EVEX capable
	So far tricks had to be played to use .insn to encode extended-EVEX
	insns; the X4 bit couldn't be controlled at all. Extend the syntax just
	enough to cover all features, taking care to reject invalid feature
	combinations (albeit aiming at being as lax there as possible, to offer
	users as much flexibility as we can - we don't, after all, know what
	future will bring).

	In a pre-existing testcase replace all but one .byte; the one that needs
	to remain wants to have EVEX.U clear in a way that's neither
	controllable via AVX10/256 embedded rounding (would otherwise also set
	EVEX.ND), nor via the index register (EVEX.X4), as there's no memory
	operand. For one of the converted instances ModR/M.mod needs correcting:
	An 8-bit displacement requires that to be 1, not 2. Also adjust source
	comments to better represent what the bad insns mimic.

2025-02-14  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Add missing doc for OP_V

2025-02-14  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Add OP_VE for .insn
	OP_VE is the opcode space for crypto vector instructions.

	Ref:
	https://github.com/riscv/riscv-isa-manual/blob/main/src/vector-crypto.adoc#crypto-vector-cryptographic-instructions

2025-02-14  Hau Hsu  <hau.hsu@sifive.com>

	RISC-V: Make SSAMOSWAP.W available for rv64
	Previously we limited SSAMOSWAP.W only available on RV32, but it should
	be available on RV64 as well.

	See
	https://github.com/riscv/riscv-cfi/blob/main/src/cfi_backward.adoc
	https://github.com/riscv/riscv-isa-manual/blob/702a3e6e843235a2a13b918ae6938b04f8974ffc/src/unpriv-cfi.adoc#L789

2025-02-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-13  Alan Modra  <amodra@gmail.com>

	dlltool memory leaks
	dlltool copies strings with strdup all over the place, seeming to take
	the attitude that anything might be modified.  That leads to lots of
	memory leaks.  Fixing the leaks by removing the strdup calls of course
	means you need to take good care that strings *aren't* modified.  This
	isn't as easy as it sounds due to functions like xlate that have
	const char* params but then manage to modify the strings.  I've fixed
	xlate, but if I've missed something somewhere then this patch likely
	will break dlltool.  Testsuite coverage of dlltool isn't good.

	The leaks in defparse.y are small.  It also is a little work to verify
	that all the strings I'm freeing in defparse.y are in fact malloc'd,
	which is no doubt why the leaks are there.

	Using bfd_xalloc in make_one_lib_file and functions called from there
	results in memory being freed automatically at the bfd_close in
	make_one_lib_file, without any fuss.

	The patch also makes use of xasprintf to replace xmalloc followed by
	sprintf.

		* defparse.y (opt_name2): Free incoming ID strings after
		adding prefix/suffix.
		* dlltool.c (struct ifunct): Constify char* fields.
		(struct iheadt, struct dlist): Likewise.
		(set_dll_name_from_def,	def_heapsize, def_stacksize),
		(def_section, assemble_file): Use xasprintf.
		(def_name, def_library): Free dll_name and name.
		(def_description, new_directove): Don't strdup incoming args.
		(append_import): Likewise.
		(def_import): Free module after appending dllext.
		(run): Free temp_base.
		(scan_filtered_symbols): Don't segfault on NULL strchr return.
		Remove unnecessary strdup.
		(scan_drectve_symbols): Likewise.  Constify pointers.
		Use bfd_malloc_and_get_section.  Use xmemdup.
		(add_excludes): Use xasprintf and xstrdup.
		(gen_exp_file): Free xlate return.  Constify pointer to suit
		struct changes.  Free copy.
		(xlate): Always copy arg.  Use xasprintf and xstrdup.
		(make_imp_label): Add bfd arg.  Use bfd_xalloc.
		(gen_lib_file): Adjust to suit.
		(make_one_lib_file): Likewise.  Use bfd_xalloc for section data
		and relocs.  Simplify code calling xlate, and free xlate return.
		(dll_name_list_free_contents): Flatten recursion.
		(mangle_defs): Free d_export_vec.
		(main): Formatting.  Use xasprintf.
		* resres.c (write_res_id): Free section data.

2025-02-13  Alan Modra  <amodra@gmail.com>

	gas: replace bfd_alloc with notes_alloc
	bfd_alloc can return NULL on out-of-memory so code needs to check the
	return value and print an error.  That check was missing in write.c.
	notes_alloc won't return NULL, instead the underlying obstack_alloc
	prints an OOM message and the process exits.  This is more convenient,
	and when the bfd_alloc memory is attached to the gas output bfd it is
	released only slightly before the notes obstack.

		* config/obj-macho.c (obj_mach_o_set_indirect_symbols): Use
		notes_calloc rather than bfd_zalloc.
		* write.c (set_symtab): Use notes_alloc.

2025-02-13  Alan Modra  <amodra@gmail.com>

	gas obj-coff memory leaks
	This patch addresses memory leaks in gas that show up when running the
	testsuite on x86_64-w64-mingw32.  The seh_ctx_cur, and weak sym naming
	leaks can occur many times during assembly.  The symbol hook and
	section leaks are not so important since this memory needs to persist
	until closing the output bfd.

		* config/obj-coff-seh.c (do_seh_endproc): Free seh_ctx_cur and
		its fields.
		* config/obj-coff-seh.h (struct seh_context): Remove unused
		"next" field.
		* config/obj-coff.c (coff_obj_symbol_new_hook): Use notes_alloc
		for aux entries.
		(coff_obj_symbol_clone_hook): Likewise.
		(obj_coff_def): Don't strdup name unless we need to do so
		for tc_canonicalize_symbol_name.  Free after making symbol.
		(weak_name2altname, weak_altname2name): Return a char*.
		(weak_uniquify): Use notes_concat.
		(pecoff_obj_set_weak_hook, pecoff_obj_clear_weak_hook): Free name
		returned by weak_name2altname.
		(coff_frob_symbol): Similarly for weak_altname2name.
		(obj_coff_section): Use notes_memdup0.
		* symbols.h: Add include guard.
		(notes_memdup0): New inline function.

2025-02-13  Tom Tromey  <tom@tromey.com>

	Remove assumption from py-symbol.exp
	The current py-symbol.exp test makes an assumption about which symbol
	will be returned first.  I don't think gdb should really make promises
	about the order in which the symbols are listed, though, and a series
	I am working on changes this behavior.  This patch changes the test to
	merely ensure that both symbols are returned.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-13  Kevin Buettner  <kevinb@redhat.com>

	Update my maintenance areas in MAINTAINERS file
	I've dropped maintenance of the mep target.  Additionally, I'm removed
	myself as an authorized committer for PowerPC, ia64, AIX, and
	GNU/Linux PPC native.

2025-02-13  Christina Schimpe  <christina.schimpe@intel.com>

	gdb, testsuite: Rename set_sanitizer procedures to append_environment.
	The procedures set_sanitizer_1, set_sanitizer and set_sanitizer_default
	are used for the configuration of ASAN specific environment variables.
	However, they are actually generic.  Rename them to append_environment*
	so that their purpose is more clear.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-13  Klaus Gerlicher  <klaus.gerlicher@intel.com>

	aarch64: fix a crash during maintenance print cooked-registers
	On aarch64 with pauth enabled a crash when can be seen when
	using "maintenance print cooked-registers".

	This happens because the register dump code tries to read
	a pseudo reg that is not handled here because it is supposedly
	only used in unwinding.

	Fix this by returning a zero value typed as a built-in uint64.

	Approved-By: Luis Machado <luis.machado@arm.com>

2025-02-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-12  Tom Tromey  <tromey@adacore.com>

	Reorder gnatmake arguments in inline-section-gc.exp, again
	Tom de Vries pointed out that commit 8cfa1fc4 ("Reorder gnatmake
	arguments in inline-section-gc.exp") caused a regression with an older
	version of dejagnu.

	This patch works around that problem by further reordering the
	arguments to gnatmake and also arranging to leave gnatmake in "-margs"
	mode.

2025-02-12  Tom Tromey  <tromey@adacore.com>

	Add copyright header to gnat_debug_info_test.adb
	I noticed that gdb/testsuite/lib/gnat_debug_info_test.adb is missing a
	copyright header.  This adds one, using the date range from the
	original commit.

2025-02-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: cleanup includes in mi/
	Remove a few includes reported as unused by clangd.

	Change-Id: I7365b7cce04c9ef1a4164764191303914da42ef9

2025-02-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-11  Rohr, Stephan  <stephan.rohr@intel.com>

	gdb: remove check for minimal symbols in 'start_command'
	GDB aborts the 'start' command if the minimal symbols cannot be
	resolved.  On Windows, GDB reads the minimal symbols from the COFF
	header of the PE file.  The symbol table is deprecated and the
	number of symbols in the COFF header may be zero:

	  https://learn.microsoft.com/en-us/windows/win32/debug/pe-format

	This is reproducible with clang version 18.1.8 on Windows:

	  clang++ -g -O0 -gdwarf -fuse-ld=lld test.cpp -o test_clang

	The COFF file header shows:

	  FILE HEADER VALUES
	        8664 machine (x64)
	           E number of sections
	    66E889EC time date stamp Mon Sep 16 21:41:32 2024
	       FB400 file pointer to symbol table
	           0 number of symbols
	          F0 size of optional header
	          22 characteristics

	GDB is not able to read the minimal symbols; the `start' command fails
	with an error:

	  (gdb) start
	  No symbol table loaded.  Use the "file" command.

	Manually inserting a breakpoint in main works fine:

	  (gdb) tbreak main
	  Temporary breakpoint 1 at 0x14000100c: file test.cpp, line 6.
	  (gdb) run
	  Starting program: C:\test-clang

	  Temporary breakpoint 1, main () at test.cpp:6
	  6         std::cout << "Hello World.\n";

	Remove the check entirely; a 'NOT_FOUND_ERROR' is thrown if 'main'
	cannot be resolved.  The error is consumed in 'create_breakpoint ()'
	and an error message is displayed to the user.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-02-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename cooked_index::m_vector to m_shards
	I think that is clearer and helps readability.

	Rename a few iteration variables from "index" or "idx" to "shard".  In
	my mental model, the "index" is the whole thing, so it's confusing to
	use that word when referring to shards.

	Change-Id: I208cb839e873c514d1f8eae250d4a16f31016148
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: remove cooked_index::vec_type
	I find this typedef to be confusing.  The name is a bit too generic, so
	it's not clear what it represents.  When using the typedef for a
	cooked_index_shard unique pointer, I think that spelling out the vector
	type is not overly long.

	Change-Id: I99fdab5cd925c37c3835b466ce40ec9c1ec7209d
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-11  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Add .bfloat16 directive
	RISC-V already support bfloat16 instruciton like Zfbfmin, Zvfbfmin and
	Zvfbfwma, so I think it's reasonable to add .bfloat16 directive to
	support bfloat16 data type.

	And the code logic mostly support by common code already.

2025-02-11  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Move all global static target stuff into private data for disassembler.
	I got a request said that the JDK multi-thread compiler may be broken
	if two or more threads are trying to print/disassemble stuff, and filling
	the disassemble_info, setting callbacks, and grabbing the function pointer
	to disasm at the same time.  Since such as the target global static stuff,
	including subset of extensions and mapping symbol stuff, seems to only be
	one globally.  Ideally, for dis-assembler, all global static target stuff
	should/can be better to be defined into the target private data, since they
	are target-dependency.

	opcodes/
		* riscv-dis.c: Moved all global static target-dependency stuff into
		riscv_private_data, including architecture and mapping symbol stuff.
		(set_default_riscv_dis_options): Updated since global static target-
		dependency stuff are moved into riscv_private_data.
		(parse_riscv_dis_option_without_args): Likewise.
		(parse_riscv_dis_option): Likewise.
		(parse_riscv_dis_options): Likewise.
		(maybe_print_address): Likewise.
		(print_reg_list): Likewise.
		(riscv_get_spimm): Likewise.
		(print_insn_args): Likewise.
		(riscv_disassemble_insn): Likewise.
		(riscv_update_map_state): Likewise.
		(riscv_search_mapping_symbol): Likewise.
		(riscv_data_length): Likewise.
		(print_insn_riscv): Likewise.  Call the riscv_init_disasm_info before
		parsing any disassembler options, since the related stuff are moved
		into riscv_private_data.
		(riscv_init_disasm_info): Likewise.  Parse and set the architecture
		string and privileged spec version since riscv_get_disassembler is
		no longer needed.
		(riscv_get_disassembler): Removed.
		(disassemble_free_riscv): Only free the subset_list if
		riscv_private_data exsits.
		* disassemble.c (disassembler): Since riscv_get_disassembler is
		removed, call to print_insn_riscv.
		* disassemble.h: Removed extern riscv_get_disassembler.

2025-02-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-10  Flavio Cruz  <flaviocruz@gmail.com>

	Port GDB to Hurd x86_64.
	This port extends the existing i686 port to support x86_64 by reusing
	existing code whenever it makes sense.

	* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
	  position of amd64 registers in the different Hurd structs.
	  The signal code is very similar to i686, except the trampoline code
	  is adapted.
	* gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.h
	  and adapt it for x86_64.
	* gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn
	  and reuse it for x86_64.
	* gdb/configure.host: recognize gnu64 as a host.
	* gdb/configure.nat: recognize gnu64 host and update existing i386gnu to
	  reuse the new shared files.
	* gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use
	  amd64-gnu-tdep.c.
	* gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is
	  copied from i386-gnu-nat.c. This makes it similar to amd64.
	* gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this for
	  i386 and amd64. Updated REG_ADDR to use one of the structures. Added
	  VALID_REGISTER to make sure it's a register we can provide at this time
	  (not all of them are available in amd64). FLAGS_REGISTER is either rfl
	  or efl depending on the arch. Renamed functions and class from i386 to x86
	  whenever they can be reused.

	Tested on Hurd x86_64 and i686.

2025-02-10  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS16/GAS: Streamline forced size suffix handling code
	Clean up after commit 112cf77b1855 ("MIPS: use is_whitespace()") and
	untangle the code flow in the handling of forced size suffixes, noting
	that owing to the loop right above the only data `c' can hold at this
	point is '\0', '.', or a white-space character.  No functional change.

2025-02-10  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS16/GAS: Reject instructions that end with a dot
	Fix a regression from commit 3fb49709438e ("MIPS16/GAS: Fix forced size
	suffixes with argumentless instructions") and reject MIPS16 instructions
	that end with a dot and no forced size suffix following, e.g.:

	$ cat test.s
		.set	mips16
	foo:
		break.
		entry.
		addiu.	$2, 0x7fff
		addiu.	$3, $2, 0
		.align	8, 0
	$ as -32 -o test.o test.s
	$ objdump -d test.o

	test.o:     file format elf32-tradbigmips

	Disassembly of section .text:

	00000000 <foo>:
	   0:	e805      	break
	   2:	e809      	entry
	   4:	f7ef 4a1f 	addiu	v0,32767
	   8:	4260      	addiu	v1,v0,0
		...
	$

	Add a test accordingly, also verifying invalid forced size suffixes.

2025-02-10  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/BFD: Remove redundant "want64=true" settings
	Clean up after commit 29c108c96106 ("MIPS: Support `-gnuabi64' target
	triplet suffix for 64-bit Linux targets") and discard individual MIPS
	"want64=true" settings, the use of which has been superseded by commit
	42429eacb42f ("Require a 64-bit bfd_vma for MIPS ELF") back in 2013[1].

	References:

	[1] <https://inbox.sourceware.org/binutils/87mwqg4mfn.fsf@talisman.default/>

2025-02-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: use tui_batch_rendering more
	While working on the commit:

	  commit 4f28b020a3416ac87ac12cf7ae3625a4bc178975
	  Date:   Wed Feb 5 20:12:03 2025 +0000

	      gdb/tui: use wrefresh if output is not surpressed

	I spotted some places where tui_win_info::refresh_window() was being
	called when suppress_output was false.  This means that there is no
	tui_batch_rendering in place on the call stack, and so, after that
	commit, we might be performing more wrefresh() calls than necessary.

	Before the above commit we would have been calling wnoutrefresh() and,
	due to the missing tui_batch_rendering, there might have been a delay
	before doupdate() was called.

	To (hopefully) make screen updates smoother, this commit adds
	tui_batch_rendering in a few places where it is possible that there
	might be multiple window updates performed, this will mean the final
	write to screen is deferred until the tui_batch_rendering goes out of
	scope.

	Other than possibly smother screen updates, there should be no user
	visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: remove unnecessary wmove call from tui_status_window
	I've been looking recently at when the TUI calls wnoutrefresh vs
	wrefresh, and the ordering of other screen update actions relative to
	these calls.

	I noticed in tui_status_window::rerender() a call to wmove() that is
	placed after the refresh_window() call.  This surely means that the
	cursor is moved, but, this update is not sent to the screen.

	But we call wmove() at the start of tui_status_window::rerender()
	before anything is sent to the screen, so the final wmove() call is
	pointless as far as I can tell.

	I propose removing it.  This is trivial, but removing pointless work
	like this slowly makes the TUI code easier to understand.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Deprecate stabs debug info
	GCC has deprecated stabs generation in GCC 12 and entirely removed it in
	GCC 13, which was released in April 2023. At the time it was proposed
	that GDB deprecate stabs as well, but the decision was to support it a
	bit longer. With this patch, it'll be deprecated on GDB 17, and removed
	on GDB 18, which following the current cadence, will be released early
	2026, meaning we will have supported stabs for nearly 3 years longer
	than GCC, which I think is reasonable.

	As pointed out in the previous discussion on this topic[1], there are
	several existing issues on the code, and none of the current maintainers
	knows how to fix it.  Unless someone steps up to fix this before the
	removal on GDB 18, I don't see why we should keep this old code that
	breaks all conventions of modern debuginfo readers and doesn't even
	work, instead of being able to further advance adjacent code.

	Finally, deprecating and removing stabs will make a.out/dbx inferiors be
	essentially unsupported, as the only debuginfo GDB supports for those
	formats is stabs, meaning users would only have assembly-level debugging
	for that format. With that in mind, this commit deprecates the a.out/dbx
	format as well.

	[1] https://inbox.sourceware.org/gdb-patches/20230119174156.654402-1-tom@tromey.com/

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: create multiple cooked index shards when reading .debug_names
	New in v2:

	 - install address map in a single shard
	 - update test gdb.mi/mi-sym-info.exp to cope with the fact that
	   different symbols could be returned when using --max-results

	When playing with the .debug_names reader, I noticed it was
	significantly slower than the DWARF scanner.  Using a "performance"
	build of GDB (with optimization, no runtime sanitizer enabled, etc), I
	measure with the following command on a rather large debug info file
	(~4 GB):

	    $ time ./gdb -q -nx --data-directory=data-directory <binary> -iex 'maint set dwarf sync on' -batch

	This measures the time it takes for GDB to build the cooked index (plus
	some startup and exit overhead).  I have a version of the binary without
	.debug_names and a version with .debug_names added using gdb-add-index.
	The results are:

	 - without .debug_names: 7.5 seconds
	 - with .debug_names: 24 seconds

	This is a bit embarrassing, given that the purpose of .debug_names is to
	accelerate things :).  The reason is that the .debug_names processing is
	not parallelized at all, while the DWARF scanner is heavily
	parallelized.

	The process of creating the cooked index from .debug_names is roughly in
	two steps:

	 1. scanning of .debug_names and creation of cooked index entries (see
	    mapped_debug_names_reader::scan_all_names)
	 2. finalization of the index, name canonicalization and sorting of the
	    entries (see cooked_index::set_contents).

	This patch grabs a low hanging fruit by creating multiple cooked index
	shards instead of a single one during step one.  Just doing this allows
	the second step of the processing to be automatically parallelized, as
	each shard is sent to a separate thread to be finalized.

	With this patch, I get:

	 - without .debug_names: 7.5 seconds
	 - with .debug_names: 9.7 seconds

	Not as fast as we'd like, but it's an improvement.

	The process of scanning .debug_names could also be parallelized to shave
	off a few seconds.  My profiling shows that out of those ~10 seconds of
	excecution, about 6 are inside scan_all_names.  Assuming perfect
	parallelization with 8 threads, it means that at best we could shave
	about 5 seconds from that time, which sounds interesting.  I gave it a
	shot, but it's a much more intrusive change, I'm not sure if I will
	finish it.

	This patch caused some regressions in gdb.mi/mi-sym-info.exp with the
	cc-with-debug-names board, in the test about the `--max-results` switch.
	It appears at this test is relying on the specific symbols returned when
	using `--max-results`.  As far as I know, we don't guarantee which
	specific symbols are returned, so any of the matching symbols could be
	returned.

	The round robin method used in this patch to assign index entries to
	shards ends up somewhat randomizing which CU gets expanded first during
	the symbol search, and therefore which order they appear in the
	objfile's CU list, and therefore which one gets searched first.

	I meditated on whether keeping compunits sorted within objfiles would
	help make things more stable and predictable.  It would somewhat, but it
	wouldn't remove all sources of randomness.  It would still possible for
	a call to `expand_symtabs_matching` to stop on the first hit.  Which
	compunit gets expanded then would still be dependent on the specific
	`quick_symbol_functions` internal details / implementation.

	Commit 5b99c5718f1c ("[gdb/testsuite] Fix various issues in
	gdb.mi/mi-sym-info.exp") had already started to make the test a bit more
	flexible in terms of which symbols it accepts, but with this patch, I
	think it's possible to get wildly varying results.  I therefore modified
	the test to count the number of returned symbols, but not expect any
	specific symbol.

	Change-Id: Ifd39deb437781f72d224ec66daf6118830042941
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: allow for cooked_index_shard::m_addrmap to be nullptr
	The following patch makes the .debug_names reader create multiple cooked
	index shards, only one of them having an address map.  The others will
	have a nullptr address map.

	Change the code using cooked_index_shard::m_addrmap to account for the
	fact that it can be nullptr.

	Change-Id: Id05b974e661d901dd43bb5ecb3a8fcfc15abc7ed
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: write offset to parent entry for DW_IDX_parent
	New in v2:

	 - add doc
	 - fix computation of offset in entry pool

	Due to a mistake in the DWARF 5 spec, the way that GDB interprets
	DW_IDX_parent when generating and reading .debug_names is not correct.

	In Section 6.1.1.2, the parent index entry attribute is described as:

	  Parent debugging information entry, a reference to the index entry for
	  the parent. This is represented as the offset of the entry relative to
	  the start of the entry pool.

	But in Table 6.1, DW_IDX_parent is described as:

	  Index of name table entry for parent

	These two contradict each other.  The former is the correct one and the
	latter is an unfortunate leftover from an earlier version of the
	proposal, according to [1].  It does make sense, because pointing to a
	name table entry is ambiguous, while poiting to an index entry directly
	is not.  Unfortunately, GDB implemented pointing to a name table entry.

	Changes on the writer side:

	 - For each written pool entry, remember the offset within the pool.

	 - Change the DW_IDX_parent form to DW_FORM_data4.

	   Using DW_FORM_udata isn't an option, because we don't know the actual
	   value when doing the first pass of writing the pool (see next point),
	   so we wouldn't know how many bytes to reserve, if we used a
	   variable-size encoding.

	   Using a fixed 4 bytes encoding would be an issue if the entry pool
	   was larger than 4 GiB, but that seems unlikely.

	   Note that clang uses DW_FORM_ref4 for this, but I'm not sure it is
	   appropriate, since forms of the reference class are specified as
	   referring "to one of the debugging information entries that describe
	   the program".  Since we're not referring to a DIE, I decided to stay
	   with a form of the "constant" class.  I think that readers will be
	   able to understand either way.

	 - Write a dummy 4 byte number when writing the pool, then patch those
	   values later.  This is needed because parents can appear before their
	   children in the pool (there's no way to ensure that parents always
	   appear before their children), so we might now know at first what
	   value to put in.

	 - Add a `write_uint` method to `class data_buf` to support that use
	   case of patching a value in the middle of the data buffer.

	 - Simplify the type of `m_name_to_value_set`, we no longer need to
	   track the index at which a name will be written at.

	 - Produce a new augmentation string, "GDB3", to be able to distinguish
	   "old" and "new" indexes.  It would be possible for a reader to
	   distinguish the two semantics of DW_IDX_parent using the form.
	   However, current versions of GDB don't do that, so they would be
	   confused trying to read a new index.  I think it is preferable to use
	   a new augmentation string so that they will reject a new index
	   instead.

	Changes on the reader side:

	 - Track the GDB augmentation version, in addition to whether the
	   augmentation string indicates the index was produced by GDB.

	 - When reading index entries, maintain a "pool offset" -> "cooked index
	   entry" mapping, to be able to find parents by pool offset.

	 - When resolving parents, keep the existing behavior of finding parents
	   by name table index if the augmentation string is "GDB2.  Otherwise,
	   look up parents by pool offset.  This assumes that .debug_names from
	   other producers (if/when we add support for reading them) use pool
	   offsets for DW_IDX_parent.  This at least what clang does.

	 - Simplify augmentation string comparison a bit by using array views.

	Update the "Extensions to ‘.debug_names’" section of the documentation
	to reflect the new augmentation string version.

	Tested by:

	 - manually producing executables with "GDB2" and "GDB3" .debug_names
	   sections and reading them.
	 - running the testsuite with the cc-with-debug-names board

	[1] https://lists.dwarfstd.org/pipermail/dwarf-discuss/2025-January/002618.html

	Change-Id: I265fa38070b86ef320e0a972c300d1d755735d8d
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: add gdb::make_array_view overload to create from an array
	I think this overload will be useful for the following reasons.
	Consider a templated function like this:

	    template <typename T>
	    void func(gdb::array_view<T> view) {}

	Trying to pass an array to this function doesn't work, as template
	argument deduction fails:

	    test.c:698:8: error: no matching function for call to ‘func(int [12])’
	      698 |   func (array);
	          |   ~~~~~^~~~~~~
	    test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’
	      686 | void func(gdb::array_view<T> view) {}
	          |      ^~~~
	    test.c:686:6: note:   template argument deduction/substitution failed:
	    test.c:698:8: note:   mismatched types ‘gdb::array_view<U>’ and ‘int*’
	      698 |   func (array);
	          |   ~~~~~^~~~~~~

	Similarly, trying to compare a view with an array doesn't work.  This:

	  int array[12];
	  gdb::array_view<int> view;

	  if (view == array) {}

	... fails with:

	    test.c:698:8: error: no matching function for call to ‘func(int [12])’
	      698 |   func (array);
	          |   ~~~~~^~~~~~~
	    test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’
	      686 | void func(gdb::array_view<T> view) {}
	          |      ^~~~
	    test.c:686:6: note:   template argument deduction/substitution failed:
	    test.c:698:8: note:   mismatched types ‘gdb::array_view<U>’ and ‘int*’
	      698 |   func (array);
	          |   ~~~~~^~~~~~~

	With this new overload, we can do:

	    func (gdb::make_array_view (array));

	and

	    if (view == gdb::make_array_view (array)) {}

	This is not ideal, I wish that omitting `gdb::make_array_view` would
	just work, but at least it allows creating an array view and have the
	element type automatically deduced from the array type.

	If someone knows how to make these cases "just work", I would be happy
	to know how.

	Change-Id: I6a71919d2d5a385e6826801d53f5071b470fef5f
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-10  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Improve the handling of atomic sequence
	In the current code, when using software single-step to debug atomic
	instruction sequence, the execution of the atomic instruction sequence
	may not be completed normally.

	Here is a test with setting a software watchpoint to execute in software
	single-step mode:

	$ cat test.c
	int a = 0;
	int main()
	  {
	    a = 1;
	    return 0;
	  }
	$ gcc -g test.c -o test
	$ gdb test
	..
	(gdb) start
	..
	Temporary breakpoint 1, main () at test.c:4
	4	    a = 1;
	(gdb) set can-use-hw-watchpoints 0
	(gdb) n
	5	    return 0;
	(gdb) watch a
	Watchpoint 2: a
	(gdb) c
	Continuing.

	At this point, the program continues to execute and can not exit
	normally because it incorrectly handled the following ll/sc atomic
	sequence in __run_exit_handlers () from /lib64/libc.so.6 during
	software single-step execution.

	   0x00007ffff7df7a48 <+408>:	ld.d        	$t1, $s2, 1776
	   0x00007ffff7df7a4c <+412>:	ll.w        	$t0, $t1, 0
	=> 0x00007ffff7df7a50 <+416>:	bne         	$t0, $zero, 20	# 0x7ffff7df7a64 <__run_exit_handlers+436>
	   0x00007ffff7df7a54 <+420>:	or          	$t3, $zero, $s4
	   0x00007ffff7df7a58 <+424>:	sc.w        	$t3, $t1, 0
	   0x00007ffff7df7a5c <+428>:	beq         	$zero, $t3, -16	# 0x7ffff7df7a4c <__run_exit_handlers+412>
	   0x00007ffff7df7a60 <+432>:	b           	8	# 0x7ffff7df7a68 <__run_exit_handlers+440>
	   0x00007ffff7df7a64 <+436>:	dbar        	0x700
	   0x00007ffff7df7a68 <+440>:	slli.w      	$t0, $t0, 0x0

	The root cause of this problem is that a breakpoint was inserted in the
	middle of ll/sc atomic sequence during software single-step execution.
	The execution result of the atomic instruction sequence is disrupted,
	causing the program unable to complete the execution of the atomic
	instruction sequence normally.

	Further explanation, if the current pc is 0x00007ffff7df7a50, it is a
	conditional branch instruction, breakpoint should only be set at the
	jump destination address (0x00007ffff7df7a64, which is outside of the
	ll/sc atomic instruction sequence) and should not set at the address
	of pc + 4 (0x00007ffff7df7a54, which is in the middle of ll/sc atomic
	sequence).

	Modify a judgment condition in loongarch_deal_with_atomic_sequence()
	to ensure that breakpoints can not be inserted in the middle of ll/sc
	atomic sequence to address such issues.

2025-02-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix selecting tail-call frames by name
	I noticed that attempting to select a tail-call frame using 'frame
	function NAME' wouldn't work:

	  (gdb) bt
	  #0  func_that_never_returns () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:49
	  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
	  #2  0x00000000004011a5 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:70
	  (gdb) frame function func_that_tail_calls
	  No frame for function "func_that_tail_calls".
	  (gdb) up
	  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
	  59	  func_that_never_returns ();
	  (gdb) disassemble
	  Dump of assembler code for function func_that_tail_calls:
	     0x000000000040117a <+0>:	push   %rbp
	     0x000000000040117b <+1>:	mov    %rsp,%rbp
	     0x000000000040117e <+4>:	call   0x40116c <func_that_never_returns>
	  End of assembler dump.
	  (gdb)

	The problem is that the 'function' mechanism uses get_frame_pc() and
	then compares the address returned with the bounds of the function
	we're looking for.

	So in this case, the bounds of func_that_tail_calls are 0x40117a to
	0x401183, with 0x401183 being the first address _after_ the function.

	However, because func_that_tail_calls ends in a tail call, then the
	get_frame_pc() is 0x401183, the first address after the function.  As
	a result, GDB fails to realise that frame #1 is inside the function
	we're looking for, and the lookup fails.

	The fix is to use get_frame_address_in_block, which will return an
	adjusted address, in this case, 0x401182, which is within the function
	bounds.  Now the lookup works:

	  (gdb) frame function func_that_tail_calls
	  #1  0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
	  59	  func_that_never_returns ();
	  (gdb)

	I've extended the gdb.base/frame-selection.exp test to cover this
	case.

2025-02-10  Alan Modra  <amodra@gmail.com>

	tc-i386.c fix for oss-fuzz gas fuzzing
	oss-fuzz fuzz_as is seriously broken with respect to gas static
	variables, so much so that most fuzz_as reports should simply be
	ignored.  This patch is a fix for
	https://oss-fuzz.com/testcase-detail/6268463220654080

		* config/tc-i386.c (i386_md_end): Clear GOT_symbol.

2025-02-10  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Use x86_64_elf_howto_table for standard relocations
	For standard relocations, use x86_64_elf_howto_table, instead of calling
	elf_x86_64_rtype_to_howto.

		* elf64-x86-64.c (elf_x86_64_tls_transition): Use
		x86_64_elf_howto_table, instead of elf_x86_64_rtype_to_howto.
		(elf_x86_64_convert_load_reloc): Use x86_64_elf_howto_table,
		instead of elf_x86_64_rtype_to_howto, for R_X86_64_PC32.

2025-02-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-09  Tom Tromey  <tom@tromey.com>

	Add dwarf2_per_bfd::start_reading
	The cooked index "start_reading" method can only be called after the
	dwarf2_per_bfd "index_table" member is set.  This patch refactors this
	code a little to centralize this constraint, adding a new
	dwarf2_per_bfd::start_reading method and another (virtual) method to
	dwarf_scanner_base.

	This removes some casts, but also is also useful to support another
	series I'm working on where the .gdb_index is rewritten.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-02-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: avoid incorrect symbols in gdb.base/condbreak-multi-context.cc
	In a different series I tweak how disabled_by_cond is handled in
	update_breakpoint_locations for code_breakpoint objects, see:

	  https://inbox.sourceware.org/gdb-patches/cover.1734366277.git.aburgess@redhat.com

	But when I did this I ran into a regression in the test script
	gdb.base/condbreak-multi-context.cc which I think is actually an issue
	with this test.

	The test relies on creating a multi-location breakpoint with a
	condition and having GDB disable some of the locations as the
	condition is only valid in some of the locations.

	Here's an example of the test creating one such breakpoint:

	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
	  (gdb) break func if a == 10
	  warning: failed to validate condition at location 1, disabling:
	    No symbol "a" in current context.
	  warning: failed to validate condition at location 3, disabling:
	    No symbol "a" in current context.
	  Breakpoint 1 at 0x401142: func. (3 locations)
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  1       breakpoint     keep y   <MULTIPLE>
	  	stop only if a == 10
	  1.1                         N*  0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
	  1.2                         y   0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
	  1.3                         N*  0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
	  (*): Breakpoint condition is invalid at this location.
	  (gdb)

	Notice that only location 1.2 is actually enabled, 1.1 and 1.3 are
	disabled due to the condition 'a == 10' not being valid.

	However, notice that this b/p is created before GDB has started the
	inferior.  What I noticed is that if I first start the inferior then I
	get a different behaviour:

	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
	  (gdb) start
	  Temporary breakpoint 1 at 0x40110e: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc, line 49.
	  Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context

	  Temporary breakpoint 1, main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:49
	  49	  aobj.func ();
	  (gdb) break func if a == 10
	  Breakpoint 2 at 0x401142: func. (3 locations)
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   <MULTIPLE>
	  	stop only if a == 10
	  2.1                         y   0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
	  2.2                         y   0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
	  2.3                         y   0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
	  (gdb)

	Notice that now all three locations are valid.

	What's actually happening is that, on my machine libm.so contains a
	global symbol 'a' which for 2.1 and 2.3 is being used to satisfy the
	condition.

	I don't believe this is actually the intention of the test, this is
	just an unfortunate consequence of name collision.

	The test actually relies on the local variables 'a' and 'c', and my
	libm.so contains a global version of both.

	So I propose that we just update the test, I've gone for the super
	inventive 'aaa' and 'ccc'.  With this change, after starting the
	inferior I now see the expected behaviour where only one of the three
	locations is enabled.

	However, while I'm fixing this I figure that it would be nice if the
	test checked both cases, creating the breakpoints before starting the
	inferior, and after starting the inferior.

	So I've updated the test to check both cases.  This has meant
	converting the mostly linear test script into a set of parameterised
	functions which I then call with a flag to indicate if the inferior
	should be started before of after creating the breakpoints.

	Approved-By: Tom Tromey <tom@tromey.com>
	Tested-By: Hannes Domani <ssbssa@yahoo.de>

2025-02-09  H.J. Lu  <hjl.tools@gmail.com>

	x86: Return error for invalid relocation offset
	Return error if relocation offset + relocation size > section size.

	bfd/

		PR ld/32665
		* elf32-i386.c (elf_i386_scan_relocs): Return error for invalid
		relocation offset.
		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.

	ld/

		PR ld/32665
		* testsuite/ld-x86-64/pr32665.err: New file.
		* testsuite/ld-x86-64/pr32665.o.bz2: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run PR ld/32665 test.

2025-02-09  Alan Modra  <amodra@gmail.com>

	Fix typo in objdump info/man page

2025-02-09  Richard Allen  <rsaxvc@gmail.com>

	gprof: fix odd inst len hist scale calculation
	With even instruction sizes, this rounding never truncated.
	Xtensa CPUs mostly use 2-3 byte instructions, and this can lead
	to a histogram being captured with an odd length address range.

	This small truncation prevented gprof from parsing gmon.out files
	containing multiple histograms when at least one of them has an
	odd address range length and another has any other address range.

2025-02-09  Richard Allen  <rsaxvc@gmail.com>

	gprof: print values of mismatched histogram scales

	gprof: fix comment typos

	gprof: add missing newline to error text

2025-02-09  Alan Modra  <amodra@gmail.com>

	PR32664, compressed debug section naming confusion
	The pr326664 fuzzer testcase has two .debug_info sections, one
	SHF_ALLOC, one not.  SEC_DEBUGGING is never set for SHF_ALLOC sections
	that happen to be named .debug_info, nor are they compressed.  However
	in this case we get an output section that is both SEC_ALLOC and
	SEC_DEBUGGING which confuses code setting up the output section names
	(.zdebug_* for compressed debug sections), resulting in a -1u index
	into a string table.

		PR 32664
		* elf.c (elf_fake_sections): Do not delay naming of SEC_ALLOC
		sections.

2025-02-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/mi: include ranges in =library-unloaded event
	Having looked at the dlmopen support in GDB, it occurred to me that
	the current MI =library-unloaded event doesn't incude enough
	information to be useful.

	Consider the gdb.mi/mi-dlmopen.exp test, this test loads libraries
	into multiple linker namespaces, and then unloads these libraries.

	We should probably figure out a way to include the linker namepsace ID
	in GDB's output, e.g. in the =library-loaded and =library-unloaded MI
	events, and in the output of 'info sharedlibrary'.  But this commit is
	not about doing that.

	This commit includes the 'ranges' information in the =library-unloaded
	event output.  This is the same ranges information as is included in
	the =library-loaded output.  Even without the linker namespace ID,
	this should allow MI consumers to figure out which library instance is
	being unloaded.

	Here is the 'info sharedlibrary' output for mi-dlmopen.exp at the
	point where all the shared libraries are loaded:

	  info sharedlibrary
	  &"info sharedlibrary\n"
	  ~"From                To                  Syms Read   Shared Object Library\n"
	  ~"0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2\n"
	  ~"0x00007ffff7eda3d0  0x00007ffff7f4e898  Yes         /lib64/libm.so.6\n"
	  ~"0x00007ffff7d0e800  0x00007ffff7e6dccd  Yes         /lib64/libc.so.6\n"
	  ~"0x00007ffff7fbd040  0x00007ffff7fbd116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n"
	  ~"0x00007ffff7fb8040  0x00007ffff7fb80f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n"
	  ~"0x00007ffff7bfe3d0  0x00007ffff7c72898  Yes         /lib64/libm.so.6\n"
	  ~"0x00007ffff7a32800  0x00007ffff7b91ccd  Yes         /lib64/libc.so.6\n"
	  ~"0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2\n"
	  ~"0x00007ffff7fb3040  0x00007ffff7fb3116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n"
	  ~"0x00007ffff7fae040  0x00007ffff7fae0f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n"
	  ~"0x00007ffff7ce1040  0x00007ffff7ce1116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n"
	  ~"0x00007ffff7cdc040  0x00007ffff7cdc0f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n"
	  ~"0x00007ffff79253d0  0x00007ffff7999898  Yes         /lib64/libm.so.6\n"
	  ~"0x00007ffff7759800  0x00007ffff78b8ccd  Yes         /lib64/libc.so.6\n"
	  ~"0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2\n"
	  ~"0x00007ffff7cd7040  0x00007ffff7cd7116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so\n"
	  ^done
	  (gdb)

	Notice that dlmopen-lib.1.so is loaded multiple times.  Here is the
	=library-unloaded event when one copy of this library is unloaded
	before this patch:

	  =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
	                    target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
			    host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
			    thread-group="i1",

	It is not possible, given this information, to know which copy of
	dlmopen-lib.1.so has actually been unloaded.  An MI consumer would
	need to query the full shared library list and update from that
	information.

	After this patch the new output is:

	  =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
	                    target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
			    host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so",
			    thread-group="i1",
			    ranges=[{from="0x00007ffff7fbd040",to="0x00007ffff7fbd116"}],
			    still-in-use="false"

	The new 'ranges' field allows an MI consumer to uniquely identify
	which library instance was just unmapped.  A frontent could,
	e.g. update a library list with no need to query the full shared
	library list.

	To include the 'ranges' field I updated mi_interp::on_solib_unloaded
	to call a new helper function.  The new helper function is split out
	from the existing mi_output_solib_attribs.  I was tempted to just call
	mi_output_solib_attribs, but doing so would mean that the
	'symbols-loaded' field was also added to the =library-unloaded event,
	however, the docs for 'symbols-unloaded' on =library-loaded says:

	  The @var{symbols-loaded} field is emitted only for backward
	  compatibility and should not be relied on to convey any useful
	  information.

	And it seemed silly to add a fields to =library-unloaded, which I
	would then document as something that should be ignored.  The new
	helper function means I can avoid emitting the 'symbols-loaded'
	field.

	I have also added a 'still-in-use' field.  When true this indicates
	that the library was removed from the inferior's library list, but the
	mapping was not removed from the inferior's address space as there is
	another copy of the library that is still using the library.  In the
	above list, notice that ld-linux-x86-64.so.2 appears 3 times, but each
	instance is mapped as 0x00007ffff7fca000.  When one copy of
	ld-linux-x86-64.so.2 is unloaded, here's the event:

	  =library-unloaded,id="/lib64/ld-linux-x86-64.so.2",
	                    target-name="/lib64/ld-linux-x86-64.so.2",
			    host-name="/lib64/ld-linux-x86-64.so.2",
			    thread-group="i1",
			    ranges=[{from="0x00007ffff7fca000",to="0x00007ffff7ff03f5"}],
			    still-in-use="true"

	The 'still-in-use' field is 'true', this indicates there are at least
	one instance of this library remaining mapped at 0x00007ffff7fca000.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-02-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: include a still-mapped flag in solib unload notification
	Consider the gdb.base/dlmopen.exp test case.  The executable in this
	test uses dlmopen to load libraries into multiple linker namespaces.

	When a library is loaded into a separate namespace, its dependencies
	are also loaded into that namespace.

	This means that an inferior can have multiple copies of some
	libraries, including the dynamic linker, loaded at once.

	However, glibc optimises at least the dynamic linker case.  Though the
	library appears to be mapped multiple times (it is in the inferior's
	solib list multiple times), there is really only one copy mapped into
	the inferior's address space.  Here is the 'info sharedlibrary' output
	on an x86-64/Linux machine once all the libraries are loaded:

	  (gdb) info sharedlibrary
	  From                To                  Syms Read   Shared Object Library
	  0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7eda3d0  0x00007ffff7f4e898  Yes         /lib64/libm.so.6
	  0x00007ffff7d0e800  0x00007ffff7e6dccd  Yes         /lib64/libc.so.6
	  0x00007ffff7fbd040  0x00007ffff7fbd116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so
	  0x00007ffff7fb8040  0x00007ffff7fb80f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so
	  0x00007ffff7bfe3d0  0x00007ffff7c72898  Yes         /lib64/libm.so.6
	  0x00007ffff7a32800  0x00007ffff7b91ccd  Yes         /lib64/libc.so.6
	  0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7fb3040  0x00007ffff7fb3116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so
	  0x00007ffff7fae040  0x00007ffff7fae0f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so
	  0x00007ffff7ce1040  0x00007ffff7ce1116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so
	  0x00007ffff7cdc040  0x00007ffff7cdc0f9  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so
	  0x00007ffff79253d0  0x00007ffff7999898  Yes         /lib64/libm.so.6
	  0x00007ffff7759800  0x00007ffff78b8ccd  Yes         /lib64/libc.so.6
	  0x00007ffff7fca000  0x00007ffff7ff03f5  Yes         /lib64/ld-linux-x86-64.so.2
	  0x00007ffff7cd7040  0x00007ffff7cd7116  Yes         /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.2.so

	Notice that every copy of /lib64/ld-linux-x86-64.so.2 is mapped at the
	same address.

	As the inferior closes the libraries that it loaded, the various
	copies of the dynamic linker will also be unloaded.

	Currently, when this happens GDB calls notify_solib_unloaded, which
	triggers the gdb::observers::solib_unloaded observer.  This observer
	will call disable_breakpoints_in_unloaded_shlib (in breakpoint.c),
	which disables any breakpoints in the unloaded solib.

	The problem with this, is that, when the dynamic linker (or any solib)
	is only really mapped once as is the case here, we only want to
	disable breakpoints in the library when the last instance of the
	library is unloaded.

	The first idea that comes to mind is that GDB should not emit the
	solib_unloaded notification if a shared library is still in use,
	however, this could break MI consumers.

	Currently, every time a copy of ld-linux-x86-64.so.2 is unloaded,
	GDB's MI interpreter will emit a =library-unloaded event.  An MI
	consumer might use this to update the library list that it displays to
	the user, and fewer notify_solib_unloaded calls will mean fewer MI
	events, which will mean the MI consumer's library list could get out
	of sync with GDB.

	Instead I propose that we extend GDB's solib_unloaded event to add a
	new flag.  The new flag indicates if the library mapping is still in
	use within the inferior.  Now the MI will continue to emit the
	expected =library-unloaded events, but
	disable_breakpoints_in_unloaded_shlib can check the new flag, when it
	is true (indicating that the library is still mapped into the
	inferior), no breakpoints should be disabled.

	The other user of the solib_unloaded observer, in bsd-uthread.c,
	should, I think, do nothing if the mapping is still in use.  This
	observer is also disabling breakpoints when a library is unloaded.

	Most of the changes in this commit relate to passing the new flag
	around for the event.  The interesting changes are mostly in solib.c,
	where the flag value is determined, and in breakpoint.c and
	bsd-uthread.c, where the flag value is read.

	There's a new MI test, the source of which is mostly copied from the
	gdb.base/dlmopen.exp test.  This new test is checking we see all the
	expected =library-unloaded events.

2025-02-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: restructure gdb.base/dlmopen.exp
	In the next commit I want to add more tests to the dlmopen.exp script.
	Doing this will be easier if the dlmopen.exp script was structured so
	that the current tests were contained inside separatate procs.  So
	this commit moves all of the current tests within dlmopen into two
	procs, and then calls these.

	There should be no changes to what is actually being tested in this
	commit.

2025-02-09  Michael Weghorn  <m.weghorn@posteo.de>

	gdb: Support some escaping of args with startup-with-shell being off
	I (Andrew Burgess) have taken this patch from this series:

	  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

	I started off reviewing that series, but wanted to explore some
	alternative strategies for solving the problems this series addresses.
	However, this patch I think is super useful, so I've taken it mostly
	as it was in the original series.

	I have made a few minor cleanups, and I've also added some more tests.
	Any bugs should be considered mine (Andrew's), but I've left the
	original author (Michael Weghorn) in place as the GDB side changes are
	mostly their work.

	The function execv_argv::init_for_no_shell (gdb/nat/fork-inferior.c),
	is passed a single string ALLARGS containing all of the inferior
	arguments, and contains some custom code for splitting this argument
	string into a vector of separate arguments.  This function is used
	when startup-with-shell is off (which is not the default).

	The algorithm in this function was just splitting on whitespace
	characters, and ignoring any quoting, so for example:

	    (gdb) set startup-with-shell off
	    (gdb) set args "first arg" second_arg

	would result in three arguments ("first), (arg"), and (second_arg)
	being passed to the inferior (the parenthesis are not part of the
	parsed arguments).

	This commit replaces this custom argument splitting with a use of the
	existing gdb_argv class (which uses the libiberty buildargv function).
	This does a better job of supporting quoting and escaping, so for the
	example given above we now pass two arguments (first arg)
	and (second_arg), which is certainly what I would have expected as a
	GDB user.

	This commit changes the 'execv_argv' class accordingly and drops the
	optimization to have all the 'char *' in 'm_argv' point to a single
	string rather than allocating a separate string for each arg.  This is
	needed because we are now going to be stripping some escaping from the
	arguments, for example:

	    (gdb) set startup-with-shell off
	    (gdb) set args "literal \$"

	In this case we will pass the single argument (literal $) to the
	inferior, the escaping backslash will be removed.  This might seem
	strange as usually the backslash would be stripped by the shell, and
	now we have no shell.  However, I think the consistent behaviour is a
	good thing; whether we start with a shell or not the escaping will be
	removed.

	Using gdb_argv will mean that quote characters are also stripped.  If
	we consider the first example again:

	    (gdb) set startup-with-shell off
	    (gdb) set args "first arg" second_arg

	This is now going to pass (first arg) and (second_arg), the quotes
	have been removed.  If the user did want the original behaviour then
	they are going to have to now do this:

	    (gdb) set startup-with-shell off
	    (gdb) set args \"first arg\" second_arg

	or they could do this:

	    (gdb) set startup-with-shell off
	    (gdb) set args '"first' 'arg"' second_arg

	This commit also extends the three tests that cover inferior argument
	passing to cover the case where 'startup-with-shell' is off.  All of
	these new tests pass for native targets, but there are still problems
	when using remote targets.

	The remote target problems arise because of how escaping is handled
	while passing arguments to remote targets.  I have a larger series
	that aims to address this issue:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	This patch was originally part of that series, but getting a 14 patch
	series reviewed is not easy, so I've pulled this patch out on its own
	for now, and the new tests are (rather crudely) disabled for remote
	targets.

	My hope is to work through my 14 patch series posting all of the
	patches in smaller groups, which will hopefully make reviewing
	easier.  As more of that series gets merged, the remote argument
	handling will improve, before, eventually, no tests will need to be
	disabled.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392

	Tested-By: Guinevere Larsen <guinevere@redhat.com>
	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-02-09  Alan Modra  <amodra@gmail.com>

	PR32663, ld buffer overflow reading .debug_info
	When reading debug info to print an error message, we'll be reading
	the debug info off disk, not using edited debug info.  sec->rawsize
	if non-zero is the correct size.

		PR 32663
		* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Use
		bfd_get_section_limit_octets to properly size debug sections.

2025-02-09  Alan Modra  <amodra@gmail.com>

	PR32662, segv in _bfd_generic_link_output_symbols
	asymbol flags zero can result from certain combinations of ELF st_info
	binding and type.  asymbol section is set to bfd_abs_section for
	genuine absolute symbols and also ones with a bogus st_shndx.  A
	fuzzed ELF object with such a symbol can tickle a bug in generic
	linker code added by commit d3a65d4dea to avoid an abort, resulting
	in a segfault.  This patch fixes the segfault by removing the
	sym->section->owner->flags test.  I think it should be OK to exclude
	all symbols without any BSF flags set, not just IR symbols.

		PR 32662
		* linker.c (_bfd_generic_link_output_symbols): Exclude all
		symbols with zero flags.  Replace abort with assertion.
		Tidy logic.

2025-02-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: use wrefresh if output is not surpressed
	Recent work in the TUI has improved GDB's use of the curses
	wnoutrefresh and doupdate mechanism, which improves performance by
	batching together updates and then doing a single set of writes to the
	screen when doupdate is finally called.

	The tui_batch_rendering type is a RAII class which, in its destructor,
	calls doupdate to send the batched updates to the screen.

	However, if there is no tui_batch_rendering active on the call stack
	then any wnoutrefresh calls will remain batched but undisplayed until
	the next time doupdate happens to be called.

	This problem can be seen in PR gdb/32623.  When an inferior is started
	the 'Starting program' message is not immediately displayed to the
	user.

	The 'Starting program' message originates from run_command_1 in
	infcmd.c, the message is sent to the current_uiout, which will be the
	TUI ui_out.  After the message is sent, ui_out::flush() is called,
	here's the backtrace when that happens:

	  #0  tui_file::flush (this=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
	  #1  0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at ../../src/gdb/utils.c:1531
	  #2  0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at ../../src/gdb/utils.c:1539
	  #3  0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at ../../src/gdb/cli-out.c:250
	  #4  0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at ../../src/gdb/ui-out.h:263
	  #5  0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
	  #6  0x00000000009f599a in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:511

	And if we check out tui_file::flush (tui-file.c) we can see that this
	just calls tui_win_info::refresh_window(), which in turn, just uses
	wnoutrefresh to batch any pending output.

	The problem is that, in the above backtrace, there is no
	tui_batch_rendering active, and so there will be no doupdate call to
	flush the output to the screen.

	We could add a tui_batch_rendering into tui_file::flush.  And
	tui_file::write.  And tui_file::puts .....

	... but that all seems a bit unnecessary.  Instead, I propose that
	tui_win_info::refresh_window() should be changed.  If suppress_output
	is true (i.e. a tui_batch_rendering is active) then we should continue
	to call wnoutrefresh().  But if suppress_output is false, meaning that
	no tui_batch_rendering is in place, then we should call wrefresh(),
	which immediately writes the output to the screen.

	Testing but PR gdb/32623 was a little involved.  We need to 'run' the
	inferior and check for the 'Starting program' message.  But DejaGNUU
	can only check for the message once it knows the message should have
	appeared.  But, as the bug is that output is not displayed, we don't
	have any output hints that the inferior is started yet...

	In the end, I have the inferior create a file in the test's output
	directory.  Now DejaGNU can send the 'run' command, and wait for the
	file to appear.  Once that happens, we know that the 'Starting
	program' message should have appeared.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32623

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-08  Alexandre Oliva  <oliva@adacore.com>

	sparc: define _GLOBAL_OFFSET_TABLE_ when referenced
	GCC testsuite gcc.dg/20050321-2.c hit link errors on undefined
	_GLOBAL_OFFSET_TABLE_.  The compiler output referenced only
	_GLOBAL_OFFSET_TABLE_-offsets to set it up, and to compute the
	GOT-relative address of local symbols, none of which triggered the
	machinery that enabled the creation of the dynamic section, so
	_GLOBAL_OFFSET_TABLE_ ended up undefined.

	Enable the dynamic section if we find a relocation involving
	_GLOBAL_OFFSET_TABLE_.  While at that, optimize checks for references
	to it.


	for  bfd/ChangeLog

		* elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Check for
		_GLOBAL_OFFSET_TABLE_ references early, then compare hashed
		symbols instead of strings.
		(_bfd_sparc_elf_relocate_section): Compare hashed symbols.

	for  ld/ChangeLog

		* testsuite/ld-sparc/got-def.s: New test.
		* testsuite/ld-sparc/sparc.exp: Add it.

2025-02-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-07  Alan Modra  <amodra@gmail.com>

	Re: x86-64: Estimate output section layout before sizing dynamic sections
	Commit 73ab3b9825 results in a warning compiling eelf_x86_64_sol2.c,
	breaking --enable-targets=all builds.
	warning: ‘elf_x86_64_before_allocation’ defined but not used

	Fix this by hooking up the chain of before_allocation functions, so
	x86_64-solaris2 calls elf_x86_64_before_allocation, while
	sparc64-solaris2 calls gldelf64_sparc_sol2_before_allocation.

2025-02-07  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: fix "up to main" in gdb.base/corefile-exec-context.exp
	On ubuntu systems with libc debug info available (libc6-dbg), I see the
	following failures for the gdb.base/corefile-exec-context.exp testcase:

	    show args
	    Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
	    (gdb) PASS: gdb.base/corefile-exec-context.exp: show args
	    up
	    #1  __pthread_kill_internal (signo=6, threadid=133859295332160) at ./nptl/pthread_kill.c:78
	    78	in ./nptl/pthread_kill.c
	    (gdb) FAIL: gdb.base/corefile-exec-context.exp: move up to main

	This failures is because the pattern used to parse the output of `up`
	is not expecting what is seen when debugging information is present for
	those frames.

	This patch adjusts the pattern to allow both possible outputs.

	Tested on ubuntu-22.04 and ubuntu24.04 with libc6-dbg installed for gdb
	build with --with-separate-debug-dir=/usr/lib/debug.

	Change-Id: I217d4b20006d0ecdb4b7a71eeb8d01597ec5ac63
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-07  Tom de Vries  <tdevries@suse.de>

	[gdb/corefiles] Fix segfault in core_target_open
	On x86_64-freebsd, with test-case gdb.arch/i386-biarch-core.exp I run into a
	segfault here in corelow.c:core_target_open:
	...
	    {
	      gdb::unique_xmalloc_ptr<char> failing_command = make_unique_xstrdup
	        (bfd_core_file_failing_command (current_program_space->core_bfd ()));
	      if (failing_command != nullptr)
	        gdb_printf (_("Core was generated by `%s'.\n"),
	                    failing_command.get ());
	    }
	...
	where bfd_core_file_failing_command returns nullptr, so the segfault happens
	somewhere during "strdup (nullptr)".

	There doesn't seem to be a need to make a copy of the string, so fix this by
	dropping the make_unique_xstrdup.

	Tested on x86_64-linux.
	Tested the test-case on x86_64-freebsd.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR corefiles/32634
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32634

2025-02-07  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix x86_64-w64-mingw32 build by avoiding SCNx8
	With an x86_64-w64-mingw32 targeted cross-build on x86_64-linux, I run into:
	...
	gdb/cli/cli-decode.c: \
	  In function 'ui_file_style::color parse_cli_var_color(const char**)':
	gdb/cli/cli-decode.c:2917:41: error: expected ')' before 'SCNx8'
	  int parsed_args = sscanf (*args, "#%2" SCNx8 "%2" SCNx8 "%2" SCNx8 "%n",
	...

	Apparantly, the definition of SCNx8 is missing in inttypes.h.

	Rewrite the sscanf call to use SCNx32, which is available.

	Tested by:
	- completing aforementioned cross-build, and
	- build & test on x86_64-linux.

	Suggested-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-07  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Support x86 Zhaoxin PadLock XMODX instructions
	The CPUID EDX bit[28] indicates its enablement, and it includes REP
	XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
	the support of modular exponentiation feature, both REP XMODEXP and
	REP MONTMUL2 use it.

	gas/ChangeLog:

		* NEWS: Support Zhaoxin PadLock XMODX instructions.
		* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
		PadLockXMODX instructions.
		(output_insn): Handle PadLockXMODX instructions.
		* doc/c-i386.texi: Document PadLockXMODX.
		* testsuite/gas/i386/i386.exp: Add PadLockXMODX test.
		* testsuite/gas/i386/padlockxmodx.d: Ditto.
		* testsuite/gas/i386/padlockxmodx.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: Add PadLockXMODX.
		* i386-gen.c: Ditto
		* i386-opc.h (CpuPadLockXMODX): New.
		* i386-opc.tbl: Add Zhaoxin PadLock XMODX instructions.
		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2025-02-07  Jan Beulich  <jbeulich@suse.com>

	gas: suppress use of ISSPACE() / ISBLANK()
	We want is_whitespace() to be used uniformly, no matter what this then
	expands to.

2025-02-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-06  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Estimate output section layout before sizing dynamic sections
	When sizing dynamic sections, elf_x86_64_scan_relocs converts GOTPCREL
	relocations to R_X86_64_PC32, R_X86_64_32S or R_X86_64_32 for local
	symbols.  But at that time, since the output section layout is unknown,
	the local symbol values can't be determined.  Later linker issues an
	error if the converted relocation overflows when resolving relocations
	against these local symbols.  Update the x86-64 ELF linker to estimate
	output section layout before sizing dynamic sections and use the
	preliminary output section layout info to skip the GOTPCREL relocation
	conversion if the converted relocation overflows.

	bfd/

		PR ld/32591
		* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Add an input
		section argument.  Use the lowest-addressed section to estimate
		the __ehdr_start symbol value.  Don't convert relocation if the
		converted relocation will overflow.

	ld/

		PR ld/32591
		* emultempl/elf-x86.em (elf_x86_64_before_allocation):
		New.  Defined for x86-64.
		(LDEMUL_BEFORE_ALLOCATION): Likewise.
		* testsuite/ld-x86-64/pr19609-2a.d: Don't fail.
		* testsuite/ld-x86-64/pr19609-2b.d: Likewise.
		* testsuite/ld-x86-64/pr19609-4a.d: Likewise.
		* testsuite/ld-x86-64/pr19609-5d.d: Likewise.
		* testsuite/ld-x86-64/pr19609-7a.d: Likewise.
		* testsuite/ld-x86-64/pr19609-7c.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1.s: New file.
		* testsuite/ld-x86-64/pr32591-1a-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1a.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1a.t: Likewise.
		* testsuite/ld-x86-64/pr32591-1b-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1b.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1b.t: Likewise.
		* testsuite/ld-x86-64/pr32591-1c-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1c.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1c.t: Likewise.
		* testsuite/ld-x86-64/pr32591-1d-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1d.d: Likewise.
		* testsuite/ld-x86-64/pr32591-1d.t: Likewise.
		* testsuite/ld-x86-64/pr32591-2.s: Likewise.
		* testsuite/ld-x86-64/pr32591-2-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-2.d: Likewise.
		* testsuite/ld-x86-64/pr32591-2.t: Likewise.
		* testsuite/ld-x86-64/pr32591-3.s: Likewise.
		* testsuite/ld-x86-64/pr32591-3-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-3.d: Likewise.
		* testsuite/ld-x86-64/pr32591-3.t: Likewise.
		* testsuite/ld-x86-64/pr32591-4.s: Likewise.
		* testsuite/ld-x86-64/pr32591-4-x32.d: Likewise.
		* testsuite/ld-x86-64/pr32591-4.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run PR ld/32591 tests.

2025-02-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use -nostdlib in gdb.base/list-dot-nodebug.exp
	When running test-case gdb.base/list-dot-nodebug.exp with target board
	cc-with-gnu-debuglink, I run into:
	...
	(gdb) list .^M
	warning: 1      ../sysdeps/x86_64/crtn.S: No such file or directory^M
	(gdb) FAIL: gdb.base/list-dot-nodebug.exp: debug=none: print before start
	...

	The problem is that the call to gdb_gnu_strip_debug in
	gdb.base/list-dot-nodebug.exp has no effect, because the target board makes
	sure that compilation delivers an executable that is already stripped, with a
	.gnu_debuglink section linking to the debug info.

	Fix this by using -nostdlib instead of static, which means the call to
	gdb_gnu_strip_debug can be removed.

	This also allows us to extend the test-case to excercise "list ." before
	starting the inferior, for the debug=some scenario, which is currently
	skipped:
	...
		# We don't test "list ." before starting with some debug info
		# because GDB will choose the symtab that has debuginfo, and
		# print the copyright blurb.  This test isn't interested (yet?)
		# in checking if this default location choice is consistent.
	...

	While we're at it, make the effect of "list ." on the current source location
	explicit using "info source" before and after "list .".

	While we're at it, make sure when running with target board
	cc-with-gdb-index or cc-with-debug-names, that the failure to compile the
	debug=none variant due to:
	...
	Error while writing index ...: No debugging symbols
	...
	doesn't stop the test-case from running the debug=some variant.

	Tested on x86_64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2025-02-06  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: gdb.base/gcorebg.exp against installed binaries
	It is possible to run GDB's testsuite against installed binaries rather
	than the one from the build tree.  For example, one could do:

	   $ make check-gdb RUNTESTFLAGS=GDB=/usr/bin/gdb

	Running the testsuite this way causes error for gdb.base/gcorebg.exp:

	    Running [...]/gdb/testsuite/gdb.base/gcorebg.exp ...
	    FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished
	    FAIL: gdb.base/gcorebg.exp: detached=detached: Core file generated by gcore
	    FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished
	    FAIL: gdb.base/gcorebg.exp: detached=standard: Core file generated by gcore

	This is due to 2 problems.
	First, when running this way, the $GDB_DATA_DIRECTORY is not set (on
	purpose) as the installed GDB does not need to be specified where to
	find it.  See this section in gdb/testsuite/lib/gdb.exp:

	    if ![info exists GDB] {
	        [....]
	    } else {
	        # If the user specifies GDB on the command line, and doesn't
	        # specify GDB_DATA_DIRECTORY, then assume we're testing an
	        # installed GDB, and let it use its own configured data directory.
	        if ![info exists GDB_DATA_DIRECTORY] {
	            set GDB_DATA_DIRECTORY ""
	        }
	    }

	The testbg.exp file always assumes a non-empty GDB_DATA_DIRECTORY.  As a
	consequence, when calling the gcorebg binary with an empty argument
	(i.e. missing argument), the program fails:

	    gcorebg: [...]/gdb/testsuite/gdb.base/gcorebg.c:42: main: Assertion `argc == 5' failed.
	    FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished

	This patch does adjust the gcorebg.c and gcorebg.exp files to allow not
	specifying the data-directory.

	The other issue is that the testsuite assumes that the `gcore` to test
	is always the one from the build tree.  However, if someone is testing
	an installed binary by setting GDB, I think that person would expect to
	test the `gcore` script next to the binary that was specified (unless
	GCORE is specified to explicitly specified).  This patch does that
	adjustment as well.  To that end, it needs to move the block setting
	GCORE after the block setting GDB.

	Change-Id: I070e039903c0b5afeac357d8fac7d710ff6697b9
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-06  Alan Modra  <amodra@gmail.com>

	PR 32603, ld -w misbehaviour
	ld -w currently causes segmentation faults and other misbehaviour
	since it changes einfo with %F in the format string (fatal error) to
	not exit.  This patch fixes that by introducing a new variant of einfo
	called "fatal" that always exits, and replaces all einfo calls using
	%F with a call to fatal without the %F.  I considered modifying einfo
	to inspect the first 2 or 4 chars in the format string, looking for
	%F, but decided that was probably a bad idea given that translators
	might have moved the %F.  It's also a little nicer to inform the
	compiler of a function that doesn't return.

	The patch also fixes some formatting nits, and makes use of %pA
	to print section names in a couple of places in aix.em.

2025-02-06  Nick Clifton  <nickc@redhat.com>

	Fix illegal memory access when linking a corrupt input file.
	PR 32647

2025-02-06  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix unused var in linux-fork.c
	On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
	...
	linux-fork.c: In function ‘void detach_checkpoint_command(const char*, int)’:
	linux-fork.c:744:16: error: unused variable ‘inf’ [-Werror=unused-variable]
	   auto [fi, inf] = parse_checkpoint_id (args);
	                ^
	linux-fork.c: In function ‘void linux_fork_context(fork_info*, int, inferior*)’:
	linux-fork.c:1020:22: error: unused variable ‘oldinf’ [-Werror=unused-variable]
	   auto [oldfp, oldinf] = find_fork_ptid (inferior_ptid);
	                      ^
	...

	Fix this by dropping the unused variables, similar how that was done in commit
	bc13da1980c ("[gdb/build] Fix unused var in corelow.c").

	Tested on x86_64-linux, by completing a build.

2025-02-06  Tom Tromey  <tom@tromey.com>

	Return bool from dwarf2_read_gdb_index
	This changes dwarf2_read_gdb_index to return bool rather than int.

2025-02-06  H.J. Lu  <hjl.tools@gmail.com>

	x86: Use hehdr_start for __ehdr_start
	Use hehdr_start for __ehdr_start instead of elf_link_hash_lookup.

		* elfxx-x86.c (elf_x86_linker_defined): Use hehdr_start if name
		is NULL.
		(_bfd_x86_elf_link_check_relocs): Pass NULL as __ehdr_start to
		elf_x86_linker_defined.

2025-02-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-05  Kevin Buettner  <kevinb@redhat.com>

	Linux checkpoints: Update NEWS and gdb.texinfo regarding multiple inferiors
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-05  Kevin Buettner  <kevinb@redhat.com>

	Print only process ptids from linux-fork.c
	This commit causes a "process ptid" to be passed to all calls
	of target_pid_to_str in linux-fork.c.  A "process ptid" is one
	in which only the pid component is set to a non-zero value;
	both the lwp  and tid components are zero.

	The reason for doing this is that pids associated with checkpoints can
	never be a thread due to the fact that checkpoints (which are
	implemented by forking a process) can only (reasonably) work with
	single-threaded processes.

	Without this commit, many of the "info checkpoints" commands
	in gdb.multi/checkpoint-multi.exp will incorrectly show some
	of the checkpoints as threads.  E.g...

	  Id  Active Target Id                          Frame
	* 1.0 y      Thread 0x7ffff7cb5740 (LWP 581704) at 0x401199, file hello.c, line 51
	  1.2 n      process 581716                     at 0x401199, file hello.c, line 51
	  1.3 n      process 581717                     at 0x401199, file hello.c, line 51
	  2.1 n      process 581708                     at 0x401258, file goodbye.c, line 62
	  2.2 y      Thread 0x7ffff7cb5740 (LWP 581712) at 0x401258, file goodbye.c, line 62
	  3.0 y      Thread 0x7ffff7cb5740 (LWP 581713) at 0x40115c, file hangout.c, line 31
	  3.2 n      process 581715                     at 0x40115c, file hangout.c, line 31
	(gdb

	With this commit in place, the output looks like this instead:

	  Id  Active Target Id      Frame
	* 1.0 y      process 535276 at 0x401199, file hello.c, line 51
	  1.2 n      process 535288 at 0x401199, file hello.c, line 51
	  1.3 n      process 535289 at 0x401199, file hello.c, line 51
	  2.1 n      process 535280 at 0x401258, file goodbye.c, line 62
	  2.2 y      process 535284 at 0x401258, file goodbye.c, line 62
	  3.0 y      process 535285 at 0x40115c, file hangout.c, line 31
	  3.2 n      process 535287 at 0x40115c, file hangout.c, line 31

	(For brevity, I've removed the directory elements in each of the paths
	above.)

	The testcase, gdb.multi/checkpoint-multi.exp, has been updated to
	reflect the fact that only "process" should now appear in output
	from "info checkpoints".

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-05  Kevin Buettner  <kevinb@redhat.com>

	Capitalize output of successful checkpoint command
	This commit causes the output of a "checkpoint" command to be
	changed from:

	    checkpoint N: fork returned pid DDDD

	to:

	    Checkpoint N: fork returned pid DDDD

	This change was made to bring the output of the "checkpoint" command in
	line with that of other commands, e.g.:

	    (gdb) break main
	    Breakpoint 1 at ...

	    (gdb) catch exec
	    Catchpoint 2 (exec)

	    (gdb) add-inferior
	    [New inferior 2]
	    Added inferior 2

	The tests gdb.base/checkpoint.exp, gdb.base/kill-during-detach.exp,
	and gdb.multi/checkpoint-multi.exp have been updated to accept the new
	(capitalized) output from the "checkpoint" command.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-05  Kevin Buettner  <kevinb@redhat.com>

	Make linux checkpoints work with multiple inferiors
	The current linux checkpoint code, most of which may be found in
	linux-fork.c, is quite broken when attempting to use more than
	one inferior.  Running GDB will show internal errors when starting
	two inferiors, placing a checkpoint in one, then switching to
	the other and doing one of the following commands, "restart",
	"detach", "kill", or continue (to program exit).  Test cases
	for two of those scenarios may be found in this bug:

	    https://sourceware.org/bugzilla/show_bug.cgi?id=31065

	I've tested for each of the scenarios and many more in the new
	test case, gdb.multi/checkpoint-multi.exp.

	I started off with the goal of fixing just those problems, and was
	mostly successful with a much smaller patch, but doing "info
	checkpoints" with more than one inferior didn't work correctly due to
	some of the inferiors being in the wrong program space.  That led me
	to making the linux-fork code fully inferior-aware.

	Prior to this commit, the list of forks was being maintained in a
	global named named 'fork_list'.  I turned this into a per-inferior
	data structure.  There was also global named 'highest_fork_num' which
	is also now part of the per-inferior struct.  A registry key named
	'checkpoint_inferior_data_key' along with function
	'get_checkpoint_inferior_data' is used to access the per-inferior
	data.  This new function, get_checkpoint_inferior_data, is only
	called by the new functions 'fork_list', 'reset_highest_fork_num',
	and increment_highest_fork_num, each of which is passed a pointer to
	the inferior.  Most occurrences referring to the (previously) global
	'fork_list' have been replaced by 'fork_list (inf)'.  In some
	functions, where the 'fork_list' is referenced multiple times, a local
	named 'fork_list' is declared and initialized instead, like this:

	    auto &fork_list = ::fork_list (inf);

	The constructor for 'struct fork_info' has gained an additional
	parameter.  In addition to passing the pid of the new fork, we now
	also pass the fork identifier, fork_num, to the constructor.  This
	integer is shown to the user in the "info checkpoints" command and
	is provided by the user, perhaps in conjunction with the inferior
	number, in commands which manipulate checkpoints, e.g. 'restart' and
	'delete checkpoint'.

	When checkpoints are used in only one inferior, this commit will
	present information to the user and will accept checkpoint identifiers
	to commands in much the same way as the code did before this commit.
	Per Pedro Alves's recommendations, the "info checkpoints" command has
	been changed somewhat.  "info checkpoints" used to display "(main
	process)" for the first process in the checkpoint list.  This is no
	longer done because it does not provide useful information.  It also
	used to display "<running>", when the process is running and no useful
	frame information may be displayed.  This has been changed to
	"(running)" in order to be more consistent with the output of the
	"info threads" command.  A new column has been added to the output for
	showing the active process in the output from "info checkpoints".
	This column will display 'y' for the active process and 'n' for the
	others.  For the active inferior a '*' is also printed preceding the
	checkpoint identifier.  Here's what things look(ed) like before and
	after for just one inferior:

	Before:

	(gdb) info checkpoints
	* 0 Thread 0x7ffff7cd3740 (LWP 84201) (main process) at 0x40114a, file hello.c, line 28
	  1 process 84205 at 0x401199, file hello.c, line 51
	  2 process 84206 at 0x4011a3, file hello.c, line 53

	After:

	(gdb) info checkpoints
	  Id Active Target Id      Frame
	*  0 y      process 551311 at 0x40114a, file hello.c, line 28
	   1 n      process 551314 at 0x401199, file hello.c, line 51
	   2 n      process 551315 at 0x4011a3, file hello.c, line 53

	(The Thread versus process distinction is handled by another
	patch - the "After" example assumes that patch is applied too.)

	When there are multiple inferiors, the "info checkpoints" output looks
	like this:

	(gdb) info checkpoints
	  Id  Active Target Id      Frame
	  1.0 y      process 535276 at 0x401199, file hello.c, line 51
	  1.1 n      process 535283 at 0x401199, file hello.c, line 51
	  1.2 n      process 535288 at 0x401199, file hello.c, line 51
	  2.1 n      process 535280 at 0x401258, file goodbye.c, line 62
	  2.2 y      process 535284 at 0x401258, file goodbye.c, line 62
	* 3.0 y      process 535285 at 0x40115c, file hangout.c, line 31
	  3.2 n      process 535287 at 0x40115c, file hangout.c, line 31

	A new function named 'parse_checkpoint_id' has been added.  As its
	name suggests, it's responsible for parsing a string representing a
	checkpoint identifier.  These identifiers may be either a decimal
	number representing the checkpoint number in the current inferior or
	two decimal numbers separated by '.', in which case the first is the
	inferior number and the second is the checkpoint number in that
	inferior.  It is called by delete_checkpoint_command,
	detach_checkpoint_command, info_checkpoints_command, and
	restart_command.  Calls to 'parse_checkpoint_id' replace calls to
	'parse_and_eval_long', plus error checking and error reporting code
	near the calls to 'parse_and_eval_long'.  As such, error checking and
	reporting has been consolidated into a single function and the
	messages output are more uniform, though this has necessitated changes
	to the existing test case gdb.base/checkpoint.exp.

	The functions 'find_fork_ptid' and 'find_fork_pid' used to return a
	pointer to a fork_info struct.  They now return a pair consisting of
	the pointer to a fork_info struct in addition to a pointer to the
	inferior containing that checkpoint.

	'find_fork_id' returns a pointer to a fork_info struct just as it did
	before, but it's now gained a new parameter, 'inf', which is the
	inferior in which to look.

	info_checkpoints_command used to simply iterate over the list of
	forks (checkpoints), printing each one out.  It now needs to iterate
	over all inferiors and, for those which have checkpoints, it needs
	to iterate over the list of checkpoints in that inferior.  As noted
	earlier, the format of the output has been changed so that checkpoint
	identifiers incorporating an inferior number may be printed.

	linux_fork_context, called by restart_command, now contains code to
	switch inferiors when the fork being restarted is in an inferior which
	is different from the current one.  The scoped_switch_fork_info class
	now also contains code for switching inferiors in both the constructor
	and destructor.

	gdb/linux-nat.c has a few changes.  All but one of them are related
	to passing the inferior to one of the linux-fork functions.  But
	one of the tests in linux_nat_target::detach has also changed in
	a non-obvious way.  In attempting to determine whether to call
	linux_fork_detach(), that code used to do:

	  if (pid == inferior_ptid.pid () && forks_exist_p ())

	It's been simplified to:

	  if (forks_exist_p (inf))

	I had added the 'pid == inferior_ptid.pid ()' condition in late 2023
	while working on a detach bug.  It was kind of a hack to prevent
	calling linux_fork_detach() when in a different inferior.  That's no
	longer needed since the call to forks_exist_p does this directly -
	i.e. it is now inferior-aware.

	Finally, the header file 'linux-fork.h' has been updated to reflect
	the fact that add_fork, linux_fork_killall, linux_fork_detach, and
	forks_exist_p all now require that a pointer to an inferior be passed
	to these functions.  Additionally (as mentioned earlier),
	find_fork_pid now returns std::pair<fork_info *, inferior *> instead
	'of fork_info *'.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31065
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-05  Nick Clifton  <nickc@redhat.com>

	Fix another illegal memory access triggered by corrupt ELF input files.
	PR 32644

	Add even more checks for corrupt input when processing relocations for ELF files.
	PR 32643

	Prevent illegal memory access when checking relocs in a corrupt ELF binary.
	PR 32641

2025-02-05  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Add leading zeros to opcodes in aarch64-tbl.h
	Opcodes and bitmasks are 32-bit numbers and omitting leading
	zeros might be interpreted as if they are 28-bit.

	aarch64: Clean up whitespace in aarch64-tbl.h
	Clean up whitespace for conforming to GNU coding standards

2025-02-05  Nick Clifton  <nickc@redhat.com>

	Prevent an abort in the bfd linker when attempting to generate dynamic relocs for a corrupt input file.
	PR 32638

2025-02-05  Guinevere Larsen  <guinevere@redhat.com>

	gdb: restrict configure error with all targets and 64 bit bfd to mips
	The recent commit b601c58034ed755fb765fc13782b6876bffd25d4 causes the
	gdb configure to fail if --enable-targets=all was requested, but 64 bit
	bfd was not enabled. This was due to a build failure first reported
	against mips, and that I also encountered building on a 32 bit mips
	system, but that looked like a general failure.

	Further examination showed that this is, in fact, mips-specific (or at
	least, not completely generic) as other targets like debian-i386 and
	32-bit arm could build all targets just fine.

	This commit restricts the new error to only trigger in mips hosts.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-05  Nick Clifton  <nickc@redhat.com>

	Prevent illegal memory access when indexing into the sym_hashes array of the elf bfd cookie structure.
	PR 32636

2025-02-05  Jan Beulich  <jbeulich@suse.com>

	gas MMIX: Use more of is_... framework like is_whitespace and is_end_of_stmt
	Convert uses of ISSPACE() and testing for specific characters into
	calls to is_whitespace and is_end_of_stmt.  While doing that, also
	remove some redundant tests, like ';' together with is_end_of_line[]
	and is_whitespace and !is_end_of_line.

	Note the invalid casts being fixed as part of moving to is_... macros;
	there were (unsigned int) where there should have been (unsigned char)
	applied on char as index to is_end_of_line[].

	Beware that the input language changes slightly: some constructs with
	whitespace characters other than space and TAB are now invalid.

2025-02-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Clean up asserts in tui_source_window_base::refresh_window
	Commit 1c525b0e037 ("[gdb/tui] Fix assert in
	tui_source_window_base::refresh_window") added an early return in
	tui_source_window_base::refresh_window.

	Assert after the early return that "m_pad != nullptr", and clean up the
	following asserts that allow for m_pad == nullptr.

	Tested on x86_64-linux.

	Reported-By: Andrew Burgess <aburgess@redhat.com>
	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[pre-commit] Require pre-commit version 3.2.0
	Recent commit 0bd340d6704 ("pre-commit autoupdate") bumped the isort version
	to 6.0.0.

	Subsequently, I started running into:
	...
	$ SKIP=flake8,isort pre-commit run
	An error has occurred: InvalidManifestError:
	==> File /home/vries/.cache/pre-commit/repommstqefj/.pre-commit-hooks.yaml
	==> At Hook(id='isort')
	==> At key: stages
	==> At index 0
	=====> Expected one of commit, commit-msg, manual, merge-commit, \
	  post-checkout, post-commit, post-merge, post-rewrite, prepare-commit-msg, \
	  push but got: 'pre-commit'
	Check the log at /home/vries/.cache/pre-commit/pre-commit.log
	...

	I found a similar PR [1], that explains that using pre-commit as a stage (as
	isort 6.0.0 does) is supported starting pre-commit 3.2.0.

	Add minimum_pre_commit_version 3.2.0 in .pre-commit-config.yaml, as suggested
	in the PR.

	After adding this, I get a more helpful message:
	...
	$ SKIP=flake8,isort pre-commit run
	An error has occurred: InvalidConfigError:
	==> File .pre-commit-config.yaml
	==> At Config()
	==> At key: minimum_pre_commit_version
	=====> pre-commit version 3.2.0 is required but version 2.17.0 is installed. \
	  Perhaps run `pip install --upgrade pre-commit`.
	Check the log at /home/vries/.cache/pre-commit/pre-commit.log
	...
	and after doing so which upgrades pre-commit to version 4.1.0, as well as
	re-installing pre-commit using:
	...
	$ pre-commit uninstall
	$ pre-commit install
	...
	I have a functional setup again.

	Interestingly, since pre-commit 4.1.0 runs in a python 3.11 environment, I no
	longer need to skip flake8 and isort, as I needed to previously when the
	system python 3.6 was used.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

	[1] https://github.com/psf/black/issues/4065

2025-02-04  Simon Marchi  <simon.marchi@polymtl.ca>

	pre-commit: run flake8 on more Python files
	pre-commit currently runs flake8 only on `gdb/python/**/*.py`.  There
	are more files we can run it on, without running it on all the testsuite
	files.  Add:

	 - gdb/gdb-gdb.py.in
	 - gdb/*.py
	 - gdb/testsuite/*.py

	Fix the new errors that popped up:

	    gdb/copyright.py:29:21: W605 invalid escape sequence '\*'
	    gdb/copyright.py:29:29: W605 invalid escape sequence '\*'
	    gdb/copyright.py:29:38: W605 invalid escape sequence '\*'
	    gdb/copyright.py:29:46: W605 invalid escape sequence '\*'
	    gdb/copyright.py:34:1: F401 'datetime' imported but unused
	    gdb/testsuite/analyze-racy-logs.py:150:9: E722 do not use bare 'except'

	Change-Id: Ia864c22d4f170d4e18ce3beb06a86c49966654b2
	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-04  Tom Tromey  <tromey@adacore.com>

	Reorder gnatmake arguments in inline-section-gc.exp
	inline-section-gc.exp ends up passing "-lm" to gnatmake as an "marg"
	-- meaning gnatmake should process it itself.  However, the gnat-llvm
	gnatmake does not know what to do with this, so the test fails.

	This patch rearranges the arguments so that the (implicit) trailing
	-lm ends up being passed through to the linker.

2025-02-04  Jens Remus  <jremus@linux.ibm.com>

	doc: sframe: Clarify FDE/FRE function/range start address fields
	The function start address in a SFrame FDE (sfde_func_start_address)
	is encoded as a signed offset to the function start address from the
	SFrame section.

	The PC range start address in a SFrame FRE (sfre_start_address) is
	encoded as an unsigned offset to the range from the function start
	address.

2025-02-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Skip SFrame FDE if .cfi_val_offset specifies non-default offset
	Unwinding of the stack pointer (SP) is performed using the assumed
	default rule ".cfi_val_offset <SP-reg>, 0", so that SP unwinds as:

	  SP = CFA

	Warn if the CFI directive .cfi_val_offset is encountered for the
	SP register with a different offset.

	gas/
		* gen-sframe.c (sframe_xlate_do_val_offset): Skip SFrame FDE
		if non-default SP value offset.

2025-02-04  Jens Remus  <jremus@linux.ibm.com>

	gas: sframe: Use appropriate struct cfi_insn_data union members
	Use the appropriate struct cfi_insn_data union members to access
	fields when generating SFrame information from CFI directives.

	gas/
		* gen-sframe.c (sframe_xlate_do_def_cfa, sframe_xlate_do_offset,
		sframe_xlate_do_val_offset): Access ri fields, as .cfi_def_cfa,
		.cfi_offset, and .cfi_val_offset define a register and offset
		value.
		* (sframe_xlate_do_def_cfa_register): Access r field, as
		.cfi_def_cfa_register defines a register.

2025-02-04  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: add void_type () method to gdb.Architecture object
	This commit adds a new method to Python architecture objects that
	returns a void type for that architecture.

	This will be useful later to create types for function symbols created
	using Python extension code.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-04  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: add domain property to gdb.Symbol
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-04  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: add subblocks property to gdb.Block
	This commit adds new propery "subblocks" to gdb.Block objects. This
	allows Python to traverse block tree starting with global block.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/big_packed_array.exp on s390x-linux
	When running test-case gdb.ada/big_packed_array.exp on s390x-linux, I run
	into:
	...
	(gdb) print bad^M
	$2 = (0 => 0 <repeats 24 times>, 1)^M
	(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
	...

	This is with gcc 7.5.0, and this xfail should trigger:
	...
	           if { $have_xfail && [string is integer $last] \
	                   && [expr ($last & 0xf) == 0] } {
	                # gcc/101643
	                setup_xfail *-*-*
	            }
	...
	but it doesn't because $last is '1'.

	Fix this by using 0xf0 as mask for big endian.

	Tested on s390x-linux.

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/convvar_comp.exp on s390x-linux
	When running test-case gdb.ada/convvar_comp.exp on s390x-linux, I get:
	...
	(gdb) run ^M
	Starting program: pb16_063 ^M
	^M
	Breakpoint 1, pck.break_me (item=...) at pck.adb:17^M
	17        function Break_Me (Item : T) return Boolean is^M
	(gdb) print item.started^M
	Cannot access memory at address 0x0^M
	(gdb) FAIL: gdb.ada/convvar_comp.exp: print item.started
	...

	This happens as follows.

	The parameter item is available in (DW_OP_fbreg: -168):
	...
	 <2><912>: Abbrev Number: 18 (DW_TAG_formal_parameter)
	    <913>   DW_AT_name        : (indirect string, offset: 0x14ca): item
	    <919>   DW_AT_type        : <0x929>
	    <91d>   DW_AT_location    : 3 byte block: 91 d8 7e  (DW_OP_fbreg: -168)
	...
	and according to the rules of -O0, it's considered to be available after the
	prologue, which looks like this:
	...
	0000000001002998 <pck__break_me>:
	 1002998:       b3 c1 00 2b             ldgr    %f2,%r11
	 100299c:       b3 c1 00 0f             ldgr    %f0,%r15
	 10029a0:       e3 f0 ff 58 ff 71       lay     %r15,-168(%r15)
	 10029a6:       b9 04 00 bf             lgr     %r11,%r15
	 10029aa:       e3 20 b0 a0 00 24       stg     %r2,160(%r11)
	...

	To detect the prologue, gdb checks the line info, which looks like this:
	...
	pck.adb:
	File name                Line number    Starting address    View    Stmt
	pck.adb                           17           0x1002998               x
	pck.adb                           17           0x1002998       1       x
	pck.adb                           19           0x10029b0               x
	pck.adb                           20           0x10029b8               x
	pck.adb                            -           0x10029c6
	...
	and gdb concludes that it's an empty prologue, so we stop at 0x1002998 and
	try to print parameter item, which is not available yet.

	For more details, see this comment in skip_prologue_using_sal:
	...
	  /* For languages other than assembly, treat two consecutive line
	     entries at the same address as a zero-instruction prologue.
	...

	The same thing happens on x86_64-linux, but it causes no problem there,
	because amd64_skip_prologue decides not to trust the result:
	...
	      struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr);

	      /* LLVM backend (Clang/Flang) always emits a line note before the
		 prologue and another one after.  We trust clang and newer Intel
		 compilers to emit usable line notes.  */
	      if (post_prologue_pc
		  && (cust != NULL
		      && cust->producer () != nullptr
		      && (producer_is_llvm (cust->producer ())
		      || producer_is_icc_ge_19 (cust->producer ()))))
		return std::max (start_pc, post_prologue_pc);
	...
	because the producer is GCC.

	Work around this by setting a breakpoint on the first statement of
	pck.break_me instead.

	Tested on s390x-linux.

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use c++ flag in c++ test-cases
	In some cases, test-cases use c++, but don't add "c++" to the compilation
	flags.  This can cause problems with some compilers.

	Fix this in some test-cases.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/30380
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30380

2025-02-04  Nick Clifton  <nickc@redhat.com>

	Update with latest changes to src-release.sh

	Rename 'binutils' to 'binutils_with_gold'.  Rename 'bin_no_gold' to 'binutils'.  Add 'gold'

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/list-dot-nodebug.exp on openSUSE
	On openSUSE Leap 15.6 with test-case gdb.base/list-dot-nodebug.exp I run into:
	...
	(gdb) list .^M
	warning: 1      ../sysdeps/x86_64/crtn.S: No such file or directory^M
	(gdb) FAIL: $exp: debug=none: print before start
	...

	The intent of the debug=none case is to generate an executable with no debug
	info.  However, we have quite a few CUs with debug info:
	...
	$ readelf -wi outputs/gdb.base/list-dot-nodebug/list-dot-nodebug-none \
	    | egrep -c " @ "
	431
	...

	This is because this code:
	...
	  gdb_gnu_strip_debug $executable no-debuglink
	...
	uses $executable, and the variable is set here:
	...
		set executable ${testfile}-none
	...
	which sets it to "list-dot-nodebug-none" and consequently
	gdb_gnu_strip_debug cannot find it.

	Fix this by using "[standard_output_file $executable]" instead.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31721
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721

2025-02-04  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Remove stale title when showing "No Source Available"
	When running test-case gdb.tui/main.exp, the last command discards the
	executable file and symbol table:
	...
	(gdb) file
	No executable file now.
	Discard symbol table from `main'? (y or n) [answered Y; input not from terminal]
	No symbol file now.
	(gdb)
	...
	and we end up with this source window:
	...
	+-tui-layout.c----------------------------------------------------------------+
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                           [ No Source Available ]                           |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	|                                                                             |
	+-----------------------------------------------------------------------------+
	...

	The source window title shouldn't be showing tui-layout.c.  It's the source
	file containing function main for the executable that was just discarded.

	Fix this by clearing the title in tui_source_window::erase_source_content.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-02-04  H.J. Lu  <hjl.tools@gmail.com>

	elf: Store __ehdr_start hash in elf_link_hash_table
	Since

	commit 97da0e2677c4a38df2406576428ec27d1da26e7c
	Author: Alan Modra <amodra@gmail.com>
	Date:   Wed Jan 12 23:42:23 2022 +1030

	    tweak __ehdr_start visibility and flags for check_relocs

	creates __ehdr_start hash in lang_symbol_tweaks, store __ehdr_start hash
	in elf_link_hash_table so that we just need to lookup it up only once.

	bfd/

		* elf-bfd.h (elf_link_hash_table): Add hehdr_start.
		* elf.c (assign_file_positions_for_load_sections): Use
		hehdr_start.

	ld/

		* ldelf.c (ldelf_before_allocation): Use hehdr_start for
		__ehdr_start hash.
		* ldlang.c (lang_symbol_tweaks): Store hehdr_start hash in
		hehdr_start.

2025-02-04  H.J. Lu  <hjl.tools@gmail.com>

	elflink.c: Replace bed->dynamic_sec_flags with flags
	Since at the function entry, there is

	  flags = bed->dynamic_sec_flags;

	we can replace bed->dynamic_sec_flags with flags.

		* elflink.c (_bfd_elf_create_got_section): Replace
		bed->dynamic_sec_flags with flags.
		(_bfd_elf_link_create_dynamic_sections): Likewise.

2025-02-04  Simon Marchi  <simon.marchi@efficios.com>

	pre-commit autoupdate
	Run `pre-commit autoupdate`.

	This picks up a fresh Black version from 2025, and with it comes a small
	but welcome formatting change.

	There is a new version of isort as well, but no formatting change there.

	Change-Id: Ie654a9c14c3a4096893011082668efb57c166fa4

2025-02-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-03  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Sync with strace v6.13
	After syncing with strace v6.13 using:
	...
	$ update-linux-defaults.sh ~/upstream/strace.git
	...
	we have a few new entries in linux-defaults.xml.in:
	...
	  <syscall name="getxattrat" groups="descriptor,file"/>
	  <syscall name="listxattrat" groups="descriptor,file"/>
	  <syscall name="removexattrat" groups="descriptor,file"/>
	  <syscall name="setxattrat" groups="descriptor,file"/>
	...

	Regenerate most *-linux.xml.in files using:
	...
	$ ./update-linux-from-src.sh ~/upstream/linux-stable.git
	...
	updating the copyright years, and do so manually for the remaining two.

	Then regenerate *-linux.xml using make, propagating the groups changes and
	copyright years.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	Z8k: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). At the same time use is_end_of_stmt() instead of an
	open-coded check in adjacent code.

	Z80: use is_whitespace()
	Replace an open-coded check and convert ISSPACE() uses.

	Xtensa: use is_whitespace()
	Convert an open-coded check.

	xgate: use is_whitespace()
	Convert an open-coded check.

	x86: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	wasm32: use is_whitespace()
	Convert an open-coded check.

	Visium: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert an open-coded check.

	VAX: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	v850: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks as well as ISSPACE()
	uses. At the same time use is_end_of_stmt() instead of a kind-of-open-
	coded check in adjacent code.

	C6x: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert an ISSPACE() use. At the same time use
	is_end_of_stmt() instead of open-coded checks in adjacent code.

	C54x: use is_whitespace()
	Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead
	of open-coded checks in adjacent code. The function also needs using in
	next_line_shows_parallel().

	C4x: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). At the same time use is_end_of_stmt() instead of
	kind-of-open-coded checks in adjacent code.

	C30: use is_whitespace()
	Convert an open-coded check.

	spu: use is_whitespace()
	Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead
	of a kind-of-open-coded check in adjacent code.

	Sparc: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	SH: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks as well as an
	ISSPACE() use. At the same time use is_end_of_stmt() instead of
	(kind-of-)open-coded checks in adjacent code.

	Score: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	S/390: use is_whitespace()
	Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead
	of kind-of-open-coded checks in adjacent code.

	s12z: use is_whitespace()
	Convert open-coded checks. At the same time use is_end_of_stmt() instead
	of open-coded checks in adjacent code. This then also fixes the prior
	use of a wrong cast for an array index: Plain char may, after all, be
	signed.

	rx: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks as well as ISSPACE()
	uses. At the same time use is_end_of_stmt() instead of an open-coded
	check in adjacent code.

	rl78: use is_whitespace()
	Replace open-coded checks and convert ISSPACE() uses. At the same time
	use is_end_of_stmt() instead of an open-coded check in adjacent code.

	RISC-V: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Switch places already checking for tabs to use the
	macro, too.

	pru: use is_whitespace()
	Convert open-coded checks as well as an ISSPACE() use.

	PPC: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also switch ISSPACE() uses over. At the same time
	use is_end_of_stmt() instead of an open-coded nul char check.

	PicoJava: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert ISSPACE(). At the same time use
	is_end_of_stmt() instead of an open-coded check in adjacent code.

	PDP11: use is_whitespace()
	Convert open-coded checks.

	NS32k: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	nds32: use is_whitespace()
	Convert ISSPACE() uses.

	msp430: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert ISSPACE() uses. At the same time use
	is_end_of_stmt() instead of open-coded checking in code needing touching
	anyway.

	Moxie: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert ISSPACE() uses. At the same time use
	is_end_of_stmt() instead of an open-coded check in adjacent code. While
	at it also drop a redundant whitespace skipping loop.

	mn10300: use is_whitespace()
	Convert open-coded checks as well as ISSPACE() uses. At the same time
	use is_end_of_stmt() instead of kind-of-open-coded checks in adjacent
	code.

	mn10200: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks as well as ISSPACE()
	uses. At the same time use is_end_of_stmt() instead of kind-of-open-
	coded checks in adjacent code.

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	MIPS: use is_whitespace()
	... for consistency of recognition of what is deemed whitespace.

	At the same time use is_end_of_stmt() instead of an open-coded nul char
	check, and check for statement end in the first place in
	parse_relocation().

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	MicroBlaze: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert ISSPACE() uses. At the same time use
	is_end_of_stmt() instead of an open-coded check in adjacent code.

	metag: use is_whitespace()
	Replace the custom is_whitespace_char().

	M*Core: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert ISSPACE() uses. At the same time use
	is_end_of_stmt() instead of an open-coded check in adjacent code.

	M68k: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included. At the same time use is_end_of_stmt() instead of open-
	coded checks in adjacent code.

	M68HC1x: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included. At the same time use is_end_of_stmt() instead of an
	open-coded check in adjacent code.

	m32r: use is_whitespace()
	Convert a lonely ISSPACE().

	m32c: use is_whitespace()
	Convert open-coded checks as well as the sole ISBLANK() use throughout
	the gas/ tree.

	LoongArch: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	kvx: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included. At the same time use is_end_of_stmt() instead of open-
	coded checks in adjacent code.

	HP-PA: use is_whitespace()
	Convert open-coded checks. At the same time use is_end_of_stmt() instead
	of an open-coded check in adjacent code.

	H8/300: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). At the same time use is_end_of_stmt() instead of an
	open-coded check in adjacent code.

	ft32: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also switch ISSPACE() uses over. At the same time
	use is_end_of_stmt() instead of open-coded checks in adjacent code.

	fr30: use is_whitespace()
	Convert open-coded checks. At the same time use is_end_of_stmt() instead
	of an open-coded check in adjacent code.

	Epiphany: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	CRx: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also switch ISSPACE() uses over.

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	cris: use is_whitespace()
	Switch ISSPACE() uses over.

	Unlike many other targets, limiting whitespace checks to just blanks is
	deemed okay here: Compilers wanting to use -f / #NO_APP are apparently
	required to emit only blanks (without this being written down anywhere).

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	CR16: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also switch ISSPACE() uses over.

	C-Sky: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also switch ISSPACE() uses over. At the same time
	use is_end_of_stmt() instead of kind-of-open-coded checks.

	dlx: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included.

	d30v: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included. At the same time use is_end_of_stmt() instead of open-
	coded checks in adjacent code.

	d10v: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Also convert open-coded checks where tabs were
	already included. At the same time use is_end_of_stmt() instead of open-
	coded checks in adjacent code.

	bpf: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). Various redundant nul char checks are also dropped,
	where adjacent. At the same time use is_end_of_stmt() instead of an
	open-coded nul char check.

	bfin: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	gas/obj-*.c: use is_whitespace()
	... for consistency of recognition of what is deemed whitespace.

	In obj_elf_section_name() also generalize end-of-statement recognition
	at the same time. Conversely drop the unused SKIP_SEMI_COLON() for COFF.

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	avr: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

	aarch64: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input).

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	Arm: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). At the same time use is_end_of_stmt() instead of an
	open-coded nul char check.

	In parse_neon_type() be more aggressive and remove the special casing of
	certain characters altogether. The original default case simply having
	"break" can't have been correct.

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	arc: use is_whitespace()
	Wherever blanks are permissible in input, tabs ought to be permissible,
	too. This is particularly relevant when -f is passed to gas (alongside
	appropriate input). At the same time use is_end_of_stmt() instead of
	open-coded nul char checks.

	Alpha/EVAX: use is_whitespace() / is_end_of_stmt()
	Don't open-code checking for ' ', '\t', and statement ending chars.

2025-02-03  Jan Beulich  <jbeulich@suse.com>

	gas: consolidate whitespace recognition
	Let's extend lex_type[] to also cover whitespace, then having a simple
	macro to uniformly recognize both blanks and tabs (and \r when it's not
	EOL) as such.

	In macro.c use sb_skip_white() as appropriate, instead of open-coding
	it.

2025-02-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-02  Tom Tromey  <tom@tromey.com>

	Avoid "text file busy" in dw2-using-debug-str.exp
	When I run:

	    runtest dw2-using-debug-str.exp

	... if I examine the gdb.log, I see:

	    objcopy: unable to copy file '[...]/dw2-using-debug-str'; reason: Text file busy

	This happens because the inferior is still running, and objcopy --
	despite the invocation seemingly not needing this -- tries to open it
	for writing.

	This patch works around the objcopy oddity by having gdb exit (killing
	the inferior) before the invocation.

	Fixing this points out that the test does not work in the
	--target_board=cc-with-gdb-index case.  This patch also arranges to
	issue an "untested" here.

2025-02-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-02-01  Tom Tromey  <tom@tromey.com>

	Remove obsolete test from gdb.cp/var-tag.exp
	There is a test in gdb.cp/var-tag.exp that is kfail'd.  I happened
	across this while working on another series and found that the PR it
	referenced was closed as invalid.  On that basis I think the test
	should be deleted.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-02-01  Tom Tromey  <tom@tromey.com>

	Show type- and function-domain in maint print psymbols
	I neglected to update "maint print psymbols" when adding TYPE_DOMAIN
	and FUNCTION_DOMAIN.  This would have been mildly helpful when
	debugging a series I am working on.  This patch corrects the
	oversight.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-02-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-31  Tom Tromey  <tromey@adacore.com>

	Use "false" when setting cli_styling
	I noticed a spot that uses 0 where "false" is more appropriate.

2025-01-31  Tom Tromey  <tom@tromey.com>

	Add space in name of Rust tuple type
	The Rust compiler emits tuple type names with a space after the comma,
	like "(i32, f64)".  This changes rust-parse.c to follow.  This isn't
	ideal -- probably the DWARF reader should canonicalize these names --
	but it is a bit more robust if symbol lookup should change; and anyway
	this feature of gdb is probably rarely used.

2025-01-31  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Support +sme+nosve permissively
	There is inconsistency regarding whether or not +sme implies +sve2 and
	whether +nosve2 implies +nosme.  In particular, GCC 14 assumes the
	dependency exists, and canonicalises target strings accordingly, whereas
	LLVM treats the features as independent.

	This patch removes the positive implication while retaining the negative
	implication.  This is the more permissive choice in each case, and
	allows us to support target strings written with either interpretation
	in mind.

	This reduces our ability to detect invalid instructions, but we already
	can't rely on this detection because gas doesn't know whether functions
	might be executed in streaming mode and/or non-streaming mode.

	The aarch64_feature_enable_set change is functionally redundant within
	this patch.  It is included because the longer term intention is to
	instead remove the workaround in aarch64_parse_features, once the
	internal feature checks have been modified to support having both
	AARCH64_FEATURE_SME set and AARCH64_FEATURE_SVE unset.

	Similarly, the dependency from +sme to +fp16 is currently redundant, but
	this redundancy relies upon an incorrect dependency from +fcma to +fp16.
	This can be fixed in the future, but it might require modifying internal
	feature checks for a few FCMA instructions, so it's left unchanged for
	now.

2025-01-31  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Fix fp8 feature dependencies
	We agreed with LLVM that we shouldn't enforce the architectural
	dependencies between fp8 muliplication features, so remove them.

	Additionally, fix a typo in the gating for FEAT_SME_F8F16 instructions,
	which were mistakenly gated by +sme-f8f32 instead.  Until now this
	mistake had been masked by the dependency between the features.

2025-01-31  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Fix overly lax +frintts dependency
	We agreed with LLVM that +frintts should only enable +fp, not +simd.
	This also matches the dependency used in GCC.

2025-01-31  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Do not relax against __[start|stop]_SECNAME symbol

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	x86/APX: correct libbfd's EVEX Rn -> Bn transformations
	In the recent GOTPCREL addition I screwed up, in clearing the Rn bits
	afterwards rather than setting them. While that ought to be benign (for
	the bits being ignored in situations like this), we still want to leave
	"canonical" encodings.

	The pre-existing GOTTPOFF conversion wasn't doing quite correctly
	either: We cannot assume the incoming Bn bits to be in a particular
	state, as for the addressing form in question they're ignored as well.

	To address both, introduce a helper function. This is then also an
	overall reduction of (source) code size (and use of "magic" numbers).

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	x86/APX: GETSEC cannot be used with REX2
	It lives in a "forbidden" row, yet its disassembler table entry was
	lacking a respective marker.

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	x86: support RMPREAD insn
	Like for RMPUPDATE documentation is about to change as far as operands
	are concerned. They're merely the other way around here.

	While adjustind gas documentation, also add the missing RMPQUERY
	counterparts there.

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	x86: RMPUPDATE wants operands in different form
	AMD are about to update their doc, to help clarify that what we
	currently do isn't quite right: In particular it is not %rax but %rcx
	which is affected by address size. In fact, that's a normal memory
	operand, just not expressed via ModR/M byte, but fixed to (%rcx) (or
	(%ecx) with 32-bit addressing).

	To support this in the assembler, generalize memory operand handling so
	far specific to XLAT (which isn't really a string insn, but requires its
	memory operand to be (%bx) / (%ebx) / (%rbx)).

	In the disassembler mimic handling after XLAT's, too.

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	x86-64: omit "default" segment prefixes from string insn disassembly
	Printing implicit %ds: and %es: prefixes is pretty meaningless in 64-bit
	mode. The SDM explicitly omits them for the 64-bit forms, and it
	obviously has them for the other ones only to cover non-64-bit modes
	(oddly enough the AMD PM has them present).

2025-01-31  Jan Beulich  <jbeulich@suse.com>

	RISC-V: widen LEB128 support
	Do away with at least one of the limitations - all other targets permit
	multiple values to be specified with a single directive. Re-arrange the
	logic further to also overcome an internal error in
	riscv_insert_uleb128_fixes(), as e.g. observed by the all/sleb128-2
	testcase. This way there's also no need to parse expressions twice,
	thus also not raising the same diagnostics (if any) twice.

	Note how this addresses a pre-existing XFAIL (where the comment wasn't
	really applicable either for RISC-V).

	Also update documentation, also to mention that differences between
	symbols may be used with .uleb128 (albeit I'm uncertain whether there
	are limitations).

2025-01-31  Tom Tromey  <tom@tromey.com>

	Use "require" a two gdb.dwarf2 test files
	A couple of ".tcl" files in gdb.dwarf2 escaped notice during the
	"require" refactoring.  This patch fixes these to use "require" rather
	than if/return.

2025-01-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-30  Alexandra Hájková  <ahajkova@redhat.com>

	gdb: add first gdbreplay test, connect.exp
	When the changes on the remote protocol are made,
	we want to test all the corner cases to prevent
	regressions.  Currently it can be tricky to simulate
	some corner case conditions that would expose possible
	regressions.  When I want to add or change the remote
	protocol packet, I need to hack gdbserver to send a
	corrupted packet or an error to make sure GDB is able
	to handle such a case.

	This test makes it easy to send a corruped packet or
	an error message to GDB using the gdbreplay tool and
	check GDB deals with it as we expect it to.

	This test starts a communication with gdbsever setting
	the remotelog file.  Then, it modifies the remotelog with
	update_log proc, injects an error message instead of
	the expected replay to the vMustReplyEmpty packet in order
	to test GDB reacts to the error response properly.  After
	the remotelog modification, this test restarts GDB and starts
	communication with gdbreply instead of the gdbserver using
	the remotelog.

	Add a lib/gdbreplay-support.exp.  update_log proc matches lines
	from GDB to gdbserver in a remotelogfile.  Once a match is found then
	the custom line is used to build a replacement line to send from
	gdbserver to GDB.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-30  Tom Tromey  <tom@tromey.com>

	Re-enable background reading
	All the reported races have been fixed, so this patch re-enabled
	background DWARF reading.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
	Tested-By: Tom de Vries <tdevries@suse.de>

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes from dwarf2/index-write.c
	These includes are reported as unused by clangd.

	Change-Id: Ibf3cdc881abad5f5969edca623412ceac7212149

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove includes from dwarf2/mapped-index.h
	They are unused, according to clangd.

	Add some includes to other files, which were relying on transitive
	includes.

	Change-Id: I3bcb4be93b3a18bf44a4068f4067e567f83e1d4f

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused include from dwarf2/read.c
	It is unused, according to clangd.

	Change-Id: Ieadb84a2b1953b70d82a28775472fd347a809a62

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused include, add forward declaration in dwarf2/parent-map.h
	dwarf2_per_bfd is used but never declared in this file, forward-declare
	it.

	dwarf2/types.h is unused, according to clangd.

	Change-Id: I324b68894008af20307030c9e36c5abe06e36a78

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused include in symtab.h
	This include is unused, according to clangd.

	Change-Id: Ifbc2fe75b02c9ae9b3e2f1184bbcc4dc7095a554

2025-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: include symtab.h in quick-symbol.h
	quick-symbol.h uses domain_search_flags, defined in symtab.h.

	Change-Id: I5c4ae272da929eb6a8dd593bcd96a2aacf0ca99f

2025-01-30  Nick Clifton  <nickc@redhat.com>

	Remove a couple of entries in the binutils MAINTAINERS file

2025-01-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle unordered dict in gdb.python/py-mi-notify.exp
	With test-case gdb.python/py-mi-notify.exp and python 3.4, I occasionally run
	into:
	...
	python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
	&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
	=-test-notification,data2="2",data1="1"
	^done
	(gdb)
	FAIL: $exp: python notification, with additional data (unexpected output)
	...

	In contrast, a passing version looks like:
	...
	python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
	&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
	=-test-notification,data1="1",data2="2"
	^done
	(gdb)
	PASS: gdb.python/py-mi-notify.exp: python notification, with additional data
	...

	The python method "gdb.notify_mi(name, data)" has parameter data which is a
	dictionary, and it iterates over that dictionary.

	The problem is that dictionaries are only guaranteed to be iterating in
	insertion order starting python 3.7 (though cpython does this starting python
	3.6).

	Fix this in the same way as in commit 362a867f2ac ("[gdb/testsuite] Handle
	unordered dict in gdb.python/py-mi-cmd.exp"): by allowing the alternative
	order.

	Tested on x86_64-linux.

2025-01-30  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Remove pr19609-4c.d and pr19609-4d.d
	Remove pr19609-4c.d and pr19609-4d.d since they are identical to
	pr19609-4a.d and pr19609-4b.d, respectively.

		* testsuite/ld-x86-64/pr19609-4c.d: Removed.
		* testsuite/ld-x86-64/pr19609-4d.d: Likewise.
		* testsuite/ld-x86-64/pr19609-4e.d: Renamed to ...
		* testsuite/ld-x86-64/pr19609-4c.d: This.
		* testsuite/ld-x86-64/x86-64.exp: Updated.

2025-01-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-29  Tom Tromey  <tom@tromey.com>

	Use command style in cmd_show_list
	cmd_show_list is a bit funny because it shows partial command names --
	for a command like "show abc xyz", it will only show "abc xyz".

	Nevertheless, I think it makes some sense to highlight these with the
	command style.  That is what this patch does.

2025-01-29  Tom Tromey  <tom@tromey.com>

	Remove "enabled" output from show_index_cache_command
	show_index_cache_command prints whether the index-cache is enabled.
	This text was added back in 2018 in commit 87d6a7aa (Add DWARF index
	cache).  Then in 2021, the enabling option was changed via commit
	7bc5c369 (gdb: introduce "set index-cache enabled", deprecate "set
	index-cache on/off").

	This latter change made this output, IMO, redundant.  That is,
	currently gdb will show:

	    (gdb) show index-cache
	    ...
	    index-cache enabled:  The index cache is off.
	    ...
	    The index cache is currently disabled.

	This patch removes the redundant output.

2025-01-29  Tom Tromey  <tom@tromey.com>

	Use command style in "help" command
	This changes the help command to use the new command style when
	displaying text like:

	    List of "catch" subcommands:

	As a side effect, this mildly -- but not hugely -- cleans up some i18n
	issues in help_list.  The header comment for that function is also
	changed to the gdb style.

	Finally, this function used to print something like:

	    Type "help catch" followed by catch subcommand name for full documentation.

	The second "catch" here seems redundant to me, so this patch removes
	it.

2025-01-29  Tom Tromey  <tom@tromey.com>

	Avoid calling help_list in more places
	I think there is no need to have a prefix command that simply calls
	help_list.  Instead, add_basic_prefix_cmd can be used.  This patch
	changes the relevant instances.  In one spot, add_setshow_prefix_cmd
	is used instead.

2025-01-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: include cli/cli-style.h in darwin-nat.c
	PR 32610 says:

	  File gdb/darwin-nat.c is missing an #include statement of
	  "cli/cli-style.h". It is needed because there is a reference to class
	  object command_style in the .c file.

	I'm not able to build-test this change (I only have access to arm64
	macos machines, which GDB doesn't support yet), but I don't think I'm
	doing things worse by adding this.

	Change-Id: I2a169664ff91b92caf27cb084334f2eb4df46aa5

2025-01-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add comments to line table from DWARF assembler
	Add comments to the assembler generated by the DWARF assembler that
	builds the line table.  I found these comments useful when debugging
	issues with the line table parsing.

	This patch should make no difference to what is being tested.  The
	test binaries should be unchanged after this commit.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: fix the declared type of register_status in regcache
	The register_status field of regcache is declared as `unsigned char *`.
	This is incorrect, because `enum register_status` from
	gdbsupport/common-regcache.h is based on signed char and
	REG_UNAVAILABLE is defined as -1.  Fix the declared type.

	Now that we are modifying the declaration, also use a unique_ptr
	and make the field private.

	The get/set methods already use the correct type, but we update cast
	operations in two places.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: refactor the definition and uses of supply_regblock
	The supply_regblock function takes a pointer to a buffer as an
	argument and implements two different behavior based on the pointer
	being null.  There are two cases where we pass nullptr, all in
	tracepoint.cc, where we are essentially doing a reset on the regcache.

	In fast_tracepoint_ctx::regcache, register_status array does not
	even exist.  Hence, that use simply boils down to zeroing of register
	data.  Do this at the time of creating the buffer and remove the call
	to supply_regblock.

	In fetch_traceframe_registers, inline the use with a call to `reset`.

	Hence, there are no more cases left, where a nullptr would be passed
	to supply_regblock.  Assert that the buffer argument is non-null and
	simplify the implementation.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: define and use regcache::reset
	Define a `reset` method for a regcache and use it for code
	simplification.  This patch allows further simplification in the next
	patch.

	The reset method fills the register data with zeroes.  For the use in
	get_thread_regcache, this is added behavior, making the patch not a
	pure refactoring, and may look like extra overhead.  However, it is
	better to avoid having arbitrary values left in the data buffer.
	Hence, it is considered a behavioral improvement.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: use REG_UNKNOWN for a regcache's register statuses
	When a regcache is initialized, the values of registers are not
	fetched yet.  Thus, initialize the register statuses to REG_UNKNOWN
	instead of REG_UNAVAILABLE, because the latter rather means "we
	attempted to fetch but could not obtain the value".

	The definitions of the reg status enums (from
	gdbsupport/common-regcache.h) as a reminder:

	    /* The register value is not in the cache, and we don't know yet
	       whether it's available in the target (or traceframe).  */
	    REG_UNKNOWN = 0,

	    /* The register value is valid and cached.  */
	    REG_VALID = 1,

	    /* The register value is unavailable.  E.g., we're inspecting a
	       traceframe, and this register wasn't collected.  Note that this
	       "unavailable" is different from saying the register does not
	       exist in the target's architecture --- in that case, the target
	       should have given us a target description that does not include
	       the register in the first place.  */
	    REG_UNAVAILABLE = -1

	Similarly, when the regcache is invalidated, change all the statuses
	back to REG_UNKNOWN.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: use unique_ptr for thread_info's regcache
	Store the regcache pointer in thread_info as a unique_ptr.  This
	allows us delete the thread_info destructor.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: convert free_register_cache into a destructor of regcache
	Convert the `free_register_cache` function into a destructor of the
	regcache struct.  In one place, we completely remove the call to free
	the regcache object by stack-allocating the object.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: convert init_register_cache and new_register_cache into constructors
	This is a refactoring that converts

	  init_register_cache (struct regcache *regcache,
	                       const struct target_desc *tdesc,
	                       unsigned char *regbuf)

	into the constructor

	  regcache (const target_desc *tdesc, unsigned char *regbuf)

	and converts

	  new_register_cache (const struct target_desc *tdesc)

	into the constructor

	  regcache (const target_desc *tdesc)

	Also use DISABLE_COPY_AND_ASSIGN for additional compile-time safety.

	Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and
	with '--enable-inprocess-agent=yes'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: use inheritance more to define tracepoint contexts
	This is a continuation of the previous refactoring to use inheritance
	in the definition of tracepoints contexts.  Again, no behavioral change
	is intended.

	Different tracepoint contexts are identified by the `type` field.  The
	field is used only in `get_context_regcache`, where we essentially
	have 2 cases, each corresponding to a tracepoint context type.  Remove
	the `type` field and split the `get_context_regcache` function into 2
	virtual method implementations.

	Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and
	'--enable-inprocess-agent=yes'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: use inheritance to define tracepoint contexts
	Use inheritance in the definition of tracepoint contexts.  This is a
	refactoring that aims to improve the code.  No behavior should be
	altered.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: add back lost comments in fast_tracepoint_ctx
	Before the removal of the UST/static-tracepoint support, the
	`static_tracepoint_ctx` struct contained comments for its fields,
	whereas `fast_tracepoint_ctx` did not.  Nevertheless, those comments
	also applied to `fast_tracepoint_ctx`.  With the removal of
	`static_tracepoint_ctx`, the comments were lost, making
	`fast_tracepoint_ctx` data members completely commentless.  Add back
	those comments.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-29  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: introduce and use new gdb::argv_vec class
	In gdbserver there are a couple of places where we perform manual
	memory management using a 'std::vector<char *>' with the vector owning
	the strings within it.  We need to take care to call
	free_vector_argv() before leaving the scope to cleanup the strings
	within the vector.

	This commit introduces a new class gdb::argv_vec which wraps around a
	'std::vector<char *>' and owns the strings within the vector, taking
	care to xfree() them when the gdb::argv_vec is destroyed.

	Right now I plan to use this class in gdbserver.

	But this class will also be used to address review feedback on this
	commit:

	  https://inbox.sourceware.org/gdb-patches/72227f1c5a2e350ca70b2151d1b91306a0261bdc.1736860317.git.aburgess@redhat.com

	where I tried to introduce another 'std::vector<char *>' which owns
	the strings.  That patch will be updated to use gdb::argv_vec instead.

	The obvious question is, instead of introducing this new class, could
	we change the APIs to avoid having a std::vector<char *> that owns the
	strings?  Could we use 'std::vector<std::string>' or
	'std::vector<gdb::unique_xmalloc_ptr<char>>' instead?

	The answer is yes we could.

	I originally posted this larger patch set:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	however, getting a 14 patch series reviewed is just not possible, so
	instead, I'm posting the patches one at a time.  The earlier patch I
	mentioned is pulled from the larger series.

	The larger series already includes changes to gdbserver which removes
	the need for the 'std::vector<char *>', however, getting those changes
	in depends (I think) on the patch I mention above.  Hence we have a
	bit of a circular dependency.

	My proposal is to merge this patch (adding gdb::argv_vec) and make use
	of it in gdbserver.

	Then I'll update the patch above to also use gdb::argv_vec, which will
	allow the above patch to get reviewed and merged.

	Then I'll post, and hopefully merge additional patches from my larger
	inferior argument series, which will remove the need for gdb::argv_vec
	from gdbserver.

	At this point, the only use of gdb::argv_vec will be in the above
	patch, where I think it will remain, as I don't think that location
	can avoid using 'std::vector<char *>'.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-29  Andrew Burgess  <aburgess@redhat.com>

	gdb: move debug output inside block in dwarf_record_line_1
	The debug output that says a line has been recorded is currently
	outside the `if` block which decides if the line should be recorded or
	not.  This means the debug output will claim the line was recorded,
	when actually it wasn't!

	Fixed by moving the debug output inside the `if` block.

	Should be no user visible changes after this commit (except if debug
	output is turned on).

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-28  Michael J. Eager  <eager@eagercon.com>

	MicroBlaze: Add features/microblaze-linux.xml
	This is a preparatory patch to support native linux port
	of gdbserver for MicroBlaze
	* gdb/features/Makefile : Add microblaze-expedite
	* gdb/features/microblaze-linux.xml : New
	* gdb/features/microblaze-linux.c : New (generated)
	* gdb/regformats/microblaze-linux.dat : New (generated)

2025-01-28  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix assert in tui_source_window_base::refresh_window
	Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
	...
	$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
	    -ex "b f2"\
	    -ex run
	...
	(from a directory not containing a file called main.c to make sure that the
	missing source stays missing) and then issue finish:
	...
	(gdb) finish
	Run till exit from #0  f2 (x=4)
	    at f2.c:5
	0x0000000000400570 in main ()
	    at main.c:7
	Value returned is $1 = 13
	(gdb)
	...
	and use control-<minus> to decrease the font size (IOW increase the $LINES and
	$COLUMNS) on the terminal, we get:
	...
	gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
	  Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	...

	The tui_source_window_base class has variable m_pad which keeps track of a
	curses pad that is used to display the source code or disassembly efficiently.

	The assert in tui_source_window_base::refresh_window triggers while preparing
	to display part of the pad.

	The problem is that the window is in a state in which the pad is not used,
	because m_content.empty () == true.  Instead, it simply shows
	"[ No Source Available ]".

	Fix this by bailing out of tui_source_window_base::refresh_window before
	accessing the m_pad variable, if m_content.empty () == true.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR tui/32592
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592

2025-01-28  Tom de Vries  <tdevries@suse.de>

	[gdb/guile] Use SCM_DEBUG_TYPING_STRICTNESS 0
	I build gdb with libguile v2.0.9, and ran into:
	...
	In file included from /usr/include/guile/2.0/libguile.h:56,
	                 from ../../gdb/guile/guile-internal.h:30,
	                 from ../../gdb/guile/scm-arch.c:26:
	/usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)':
	/usr/include/guile/2.0/libguile/tags.h:97:53: error: \
	  operation on '*0' may be undefined [-Werror=sequence-point]
	 #   define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
	                                            ~~~~~~~~~^~~~~
	...

	Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0.

	We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK
	when using libguile v2.0.10.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-28  Tom Tromey  <tromey@adacore.com>

	Fix gdb.ada/import.exp when using mold
	We found that the gdb.ada/import.exp test fails when 'mold' is used as
	the linker.  This happens because mold decides to mark most of the
	symbols in the executable as being file-local.  I tend to think this
	choice, while non-traditional, is probably fine.  So, this patch fixes
	the problem by changing the relevant Ada code to look for file-local
	symbols as well.

	Furthermore, there are two overloads of lookup_minimal_symbol_linkage
	that both have a final 'bool' parameter -- but with radically
	different meanings.  This patch somewhat clears up this confusion as
	well.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31378

2025-01-28  Nick Clifton  <nickc@redhat.com>

	Add translations for various sub-directories

2025-01-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/remote: add 'binary-upload' feature to guard 'x' packet use
	This mailing list discussion:

	  https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com

	highlighted the following issue with GDB's 'x' packet implementation.

	Unfortunately, LLDB also has an 'x' packet, but their implementation
	is different to GDB's and so targets that have implemented LLDB's 'x'
	packet are incompatible with GDB.

	The above thread is specifically about the 'rr' tool, but there could
	be other remote targets out there that have this problem.

	The difference between LLDB and GDB is that GDB expects a 'b' prefix
	on the reply data, while LLDB does not.  The 'b' is important as it
	allows GDB to distinguish between an empty reply (which will be a 'b'
	prefix with no trailing data) and an unsupported packet (which will be
	a completely empty packet).  It is not clear to me how LLDB
	distinguishes these two cases.

	See for discussion of the 'x' packet:

	  https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r

	with the part specific to the 'b' marker in:

	  https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/

	I propose that we add a new feature 'binary-upload' which can be
	reported by a stub in its qSupported reply.  By default this feature
	is "off", meaning GDB will not use the 'x' packet unless a stub
	advertises this feature.

	I have updated gdbserver to send 'binary-upload+', and when I examine
	the gdbserver log I can see this feature being sent back, and then GDB
	will use the 'x' packet.

	When connecting to an older gdbserver, the feature is not sent, and
	GDB does not try to use the 'x' packet at all.

	I also built the latest version of `rr` and tested using current HEAD
	of master, where I see problems like this:

	  (rr) x/10i main
	     0x401106 <main>:   Cannot access memory at address 0x401106

	Then tested using this patched version of GDB, and now I see:

	  (rr) x/10i main
	     0x401106 <main>:   push   %rbp
	     0x401107 <main+1>: mov    %rsp,%rbp
	     0x40110a <main+4>: mov    0x2f17(%rip),%rax        # 0x404028 <global_ptr>
	     ... etc ...

	and looking in the remote log I see GDB is now using the 'm' packet
	instead of the 'x' packet.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2025-01-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/configure: fail configure if all targets requested with 32bit bfd
	As PR sim/28684 explains, it isn't possible to compile GDB with all
	targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd
	is forced, so the build works, but in 32 bit hosts, that has to be
	explicitly enabled.

	I ran into this when I tried compiling GDB on a mips64 machine running a
	32 bit OS. Along with the errors in the PR, several other architectures
	are also required, notably aarch64 and other explicitly 64bit targets.
	Additionally, some 32 bit files required for the gdb mips target aren't
	added to the makefile.

	Considering the last comment in the bug says this isn't going to be
	fixed on the binutils side, I didn't think it was worth trying to fix
	the GDB side. Instead, this commit causes the configure script to fail
	if all targets were requested and 64 bit bfd isn't enabled. If that is
	ever fixed, we can revert this commit.

	I considered adding this to the top level configure script, but couldn't
	figure out how to detect the situation in there, so this was my next
	best idea.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-01-28  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Fix "Standard Replies" xref
	When building gdb with an older makeinfo (4.13), I run into:
	...
	gdb/doc/gdb.texinfo:42613: warning: `.' or `,' must follow @xref, not `f'.
	...

	This is related to this line:
	...
	@xref{Standard Replies} for standard error responses, and how to
	respond indicating a command is not supported.
	...

	Fix this by adding a comma.

	Tested by rebuilding the docs.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Co-Authored-By: Eli Zaretskii <eliz@gnu.org>

2025-01-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-27  Michael J. Eager  <eager@eagercon.com>

	MicroBlaze: Widen mask used in opcodes/microblaze-dis,c
	Instead of using 0xFFFF0000, or with (~0xFFFF) to sign extend
	negative 16-bit value and with (~0xFFFF) to extract higher order
	address bits

	opcodes/
		* microblaze-dis.c: (print_insn_microblaze): Widen mask
		(microblaze_get_target_address): Likewis

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Error if vector index register omitted in assembly
	Vector index registers are currently only used in the VRV instruction
	format.  Unlike general purpose index registers an operand value of
	zero (e.g. %v0, 0, or omitted) does not imply a zero value:

	"For VRV format instructions, a vector element is used in the formation
	of the intermediate value.  This vector element is an unsigned binary
	integer value that is added to the base address and 12-bit displacement
	to form a 64-bit intermediate sum.  The vector element is designated by
	a vector register and an element index.  A zero V field accesses the
	element in vector register zero and does not imply a zero value." [1]

	Therefore require vector index register operands to be specified in
	assembler source.  That is do require coding of D(VX,B) instead of
	allowing to omit VX=0 as D(,B), D(B), or D.  Emit an error message if
	a mandatory vector index register is omitted:

	  Error: operand <n>: missing vector index register operand

	Note that this change is not backwards compatible.  But any code that
	omitted the specification of the vector index register is likely to be
	in error.  Therefore it is favorable to report an error than to stay
	backward compatible.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	gas/
		* config/tc-s390.c (md_gather_operands): Do not allow
		vector index register operands to be optionally omitted.

	gas/testsuite/
		* gas/s390/zarch-base-index-0.d (vgef): Remove tests with
		omitted vector index register operands.
		* gas/s390/zarch-base-index-0.s (vgef): Move tests with omitted
		vector index register operands ...
		* gas/s390/zarch-base-index-0-err.s (vgef): ... to here.
		* gas/s390/zarch-base-index-0-err.l (vgef): Expect error
		for omitted vector index register operands.
		* gas/s390/zarch-omitted-base-index.d (vgef): Remove tests with
		omitted vector index register operands.
		* gas/s390/zarch-omitted-base-index.s (vgef): Move tests with
		omitted vector index register operands ...
		* gas/s390/zarch-omitted-base-index-err.s (vgef): ... to here.
		* gas/s390/zarch-omitted-base-index-err.l (vgef): Expect error
		for omitted vector index register operands.
		* gas/s390/zarch-warn-areg-zero.l (vgef): Remove tests with
		omitted vector index register operands.
		* gas/s390/zarch-warn-areg-zero.s (vgef): Likewise.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Do not warn about vector index register 0 in assembly
	Vector index registers are currently only used in the VRV instruction
	format.  Unlike general purpose index registers an operand value of
	zero (e.g. %v0, 0, or omitted) does not imply a zero value:

	"For VRV format instructions, a vector element is used in the formation
	of the intermediate value.  This vector element is an unsigned binary
	integer value that is added to the base address and 12-bit displacement
	to form a 64-bit intermediate sum.  The vector element is designated by
	a vector register and an element index.  A zero V field accesses the
	element in vector register zero and does not imply a zero value." [1]

	Therefore when using s390-specific assembler option "-mwarn-areg-zero"
	do not warn if vector index register 0 is specified.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	gas/
		* config/tc-s390.c (md_gather_operands): Do not warn about
		vector index register 0.

	gas/testsuite/
		* gas/s390/zarch-warn-areg-zero.l (vgef): Do not expect warning
		about vector index register 0.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Do not omit vector index register 0 in disassembly
	Vector index registers are currently only used in the VRV instruction
	format.  Unlike general purpose index registers an operand value of
	zero (e.g. %v0, 0, or omitted) does not imply a zero value:

	"For VRV format instructions, a vector element is used in the formation
	of the intermediate value.  This vector element is an unsigned binary
	integer value that is added to the base address and 12-bit displacement
	to form a 64-bit intermediate sum.  The vector element is designated by
	a vector register and an element index.  A zero V field accesses the
	element in vector register zero and does not imply a zero value." [1]

	Therefore do not omit vector index register 0 in disassembly, that is
	disassemble D(VX,B) with VX=0 as D(VX,B) instead of D(B).  Also do not
	disassemble index register 0 as "0", that is disassemble D(VX,B) with
	VX=0 as D(%v0,B) instead of D(0,B).  Note that a base register 0 still
	still gets disassembled as "0", that is D(VX,B) with B=0 disassembles
	into D(VX,0).

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	opcodes/
		* s390-dis.c (s390_print_insn_with_opcode): Do not omit vector
		index register 0 in disassembly.  Disassemble it as %v0.

	gas/testsuite/
		* gas/s390/zarch-base-index-0.d (vgef): Expect vector index
		register 0 in disassembly.
		* gas/s390/zarch-omitted-base-index.d (vgef): Likewise.

	Suggested-by: Florian Krohm <flo2030@eich-krohm.de>

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Additional tests for omitted base register operands
	This complements commit aacf780bca29 ("s390: Allow to explicitly omit
	base register operand in assembly").

	gas/testsuite/
		* gas/s390/zarch-warn-areg-zero.l: Add tests for omitted base
		register operands.
		* gas/s390/zarch-warn-areg-zero.s: Likewise.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Generate .eh_frame unwind information for .plt section
	Enable unwinding using .eh_frame information through PLT entries.  Based
	on x86-64.

	This enhances stack traces if the instruction pointer is in a PLT entry.
	For instance perf call graphs, when using --call-graph=dwarf, and Glibc
	backtraces, when using backtrace() e.g. from a signal handler.
	Note that GDB could already unwind through PLT entries using its s390-
	specific prologue unwinder.

	Furthermore this lays the foundation to generate SFrame information for
	the PLT section in the future.

	bfd/
		* elf64-s390.c: Include dwarf2.h.
		(PLT_CIE_SIZE, PLT_FDE_SIZE,
		PLT_FDE_START_OFFSET, PLT_FDE_LEN_OFFSET,
		elf_s390x_eh_frame_plt): New .eh_frame template for .plt
		section.
		(elf_s390_link_hash_table): Add plt_eh_frame field.
		(elf_s390_create_dynamic_sections): New s390-specific wrapper
		around _bfd_elf_create_dynamic_sections.  Create .eh_frame
		section for .plt section.
		(elf_backend_create_dynamic_sections): Register s390-specific
		elf_s390_create_dynamic_sections.
		(elf_s390_late_size_sections): Fill in .eh_frame section for
		.plt section.  Write .plt section size into .eh_frame FDE
		covering .plt section.
		(elf_s390_finish_dynamic_sections): Write .plt section start
		into .eh_frame FDE covering .plt section.  Call
		_bfd_elf_write_section_eh_frame on on htab->plt_eh_frame
		section.

	ld/
		* NEWS: Add news entry.
		* emulparams/elf64_s390.sh: Include plt_unwind.sh.

	ld/testsuite/
		* ld-s390/plt_64-1_eh.wf: New PLT .eh_frame generation test.
		* ld-s390/s390.exp: Link some existing test cases with
		--no-ld-generated-unwind-info so that they do not fail.  Run
		new PLT .eh_frame generation test.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Add basic PLT generation tests
	ld/testsuite/
		* ld-s390/plt_31_non-pic-1.pd: New non-PIC/PIE PLT generation
		test for 31-bit.
		* ld-s390/plt_31_pic-1.pd: New PIC/PIE PLT generation test for
		31-bit.
		* ld-s390/plt_31-1.wf: New PLT generation test for 31-bit.
		* ld-s390/plt_64-1.pd: New PLT generation test for 64-bit.
		* ld-s390/plt_64-1.wf: Likewise.
		* ld-s390/plt-1.s: New PLT generation test for 31/64-bit.
		* ld-s390/pltlib.s: Likewise.
		* ld-s390/s390.exp: Run new PLT generation tests.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: Fix linker s390 emulation option parsing
	Append s390-specific emulation options to the shell variables instead of
	replacing their contents.

	ld/
		* emultempl/s390.em (PARSE_AND_LIST_LONGOPTS,
		PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Append to
		emulation options instead of replacing them.

	Fixes: b4cbbe8f7294 ("S/390: Add support for pgste marker")

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: s390_machine leak
	Simplify the .machine directive parsing logic, so that cpu_string is
	always xstrdup'd and can therefore always be xfree'd before returning
	to the caller.

	This resolves the following memory leak reported by ASAN:

	Direct leak of 13 byte(s) in 3 object(s) allocated from:
	    #0 0x3ff8aafbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x2aa338861cf in xmalloc ../../libiberty/xmalloc.c:149
	    #2 0x2aa338868ff in xstrdup ../../libiberty/xstrdup.c:34
	    #3 0x2aa320253cb in s390_machine ../../gas/config/tc-s390.c:2172
	    #4 0x2aa31fddc7b in read_a_source_file ../../gas/read.c:1293
	    #5 0x2aa31f4f7bf in perform_an_assembly_pass ../../gas/as.c:1223
	    #6 0x2aa31f4f7bf in main ../../gas/as.c:1436
	    #7 0x3ff8a02be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
	    #8 0x3ff8a02bf33 in __libc_start_main_impl ../csu/libc-start.c:360
	    #9 0x2aa31f5758f  (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...)

	While at it add tests with double quoted .machine
	"<cpu>[+<extension>...]" values.

	gas/
		* config/tc-s390.c (s390_machine): Simplify parsing and free
		cpu_string before returning.

	gas/testsuite/
		* gas/s390/machine-parsing-1.l: Add tests with double quoted
		values.
		* gas/s390/machine-parsing-1.s: Likewise.

2025-01-27  Jens Remus  <jremus@linux.ibm.com>

	s390: s390_machinemode leak
	This resolves the following memory leak reported by ASAN:

	Direct leak of 17 byte(s) in 1 object(s) allocated from:
	    #0 0x3ffb32fbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x2aa149861cf in xmalloc ../../libiberty/xmalloc.c:149
	    #2 0x2aa149868ff in xstrdup ../../libiberty/xstrdup.c:34
	    #3 0x2aa1312391f in s390_machinemode ../../gas/config/tc-s390.c:2241
	    #4 0x2aa130ddc7b in read_a_source_file ../../gas/read.c:1293
	    #5 0x2aa1304f7bf in perform_an_assembly_pass ../../gas/as.c:1223
	    #6 0x2aa1304f7bf in main ../../gas/as.c:1436
	    #7 0x3ffb282be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
	    #8 0x3ffb282bf33 in __libc_start_main_impl ../csu/libc-start.c:360
	    #9 0x2aa1305758f  (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...)

	gas/
		* config/tc-s390.c (s390_machinemode): Free mode_string before
		returning.

2025-01-27  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix build with gcc 7.5.0
	When building gdb with gcc 7.5.0, I run into:
	...
	gdb/dwarf2/cooked-index.c: In lambda function:
	gdb/dwarf2/cooked-index.c:104:5: error: \
	  the value of ‘_sch_tolower’ is not usable in a constant expression
	     };
	     ^
	In file included from gdbsupport/gdb-safe-ctype.h:47:0,
	                 from gdb/dwarf2/cooked-index.c:34:
	include/safe-ctype.h:111:29: note: ‘_sch_tolower’ was not declared ‘constexpr’
	 extern const unsigned char  _sch_tolower[256];
	                             ^~~~~~~~~~~~
	...

	This does not happen with gcc 8.2.1.

	Fix this by dropping the constexpr on lambda function munge in
	cooked_index_entry::compare for gcc 7.

	Tested by completing the build on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-27  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Use more lower-case in @sc in the documentation
	When building gdb with an older makeinfo (4.13), I run into:
	...
	gdb/doc/gdb.texinfo:49064: warning: @sc argument all uppercase, thus no effect.
	...

	Using a grep, I found one more instance:
	...
	$ grep @sc gdb/doc/*.tex* | egrep -v  '@sc{[^A-Z]*}'
	gdb/doc/gdb.texinfo:\
	Bit 1 (@sc{ZA}) shows whether the @code{ZA} register state is active (in use) or
	gdb/doc/python.texi:\
	corresponding @sc{GDB/MI} command's output.  Refer to the
	...

	Fix this by using lowercase letters in the @sc argument, similar to how that
	was done in commit c96452ad168 ("Use lower-case in @sc in the documentation").

	Tested by rebuilding the documentation.

2025-01-27  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Fix qIsAddressTagged anchor
	When building gdb with an older makeinfo (4.13), I run into:
	...
	gdb/doc/gdb.texinfo:44159: @anchor expected braces.
	gdb/doc/gdb.texinfo:44159: ` {qIsAddressTagged}
	...

	This is related to this line:
	...
	@anchor {qIsAddressTagged}
	...

	Fix this by removing the space before the left brace.

	Tested by rebuilding the documentation.

2025-01-27  Tom de Vries  <tdevries@suse.de>

	[gdb/doc] Fix gdb.unwinder docs
	When building gdb with an older makeinfo (4.13), I run into:
	...
	gdb/doc/python.texi:3015: warning: `(' follows defined name \
	  `gdb.unwinder.Unwinder.__init__' instead of whitespace.
	gdb/doc/python.texi:3041: warning: `(' follows defined name \
	  `gdb.unwinder.FrameId.__init__' instead of whitespace.
	...

	The warnings are related to these two lines:
	...
	@defun gdb.unwinder.Unwinder.__init__(name)
	  ...
	@defun gdb.unwinder.FrameId.__init__(sp, pc, special = @code{None})
	...

	Indeed, when checking the command and variable index, we can see that it
	contains an incorrect entry:
	...
	  gdb.unwinder.FrameId.__init__(sp,:          Unwinding Frames in Python
	...

	Fix this by adding a space before the left parenthesis.

	Tested by rebuilding the documentation and checking the command and variable
	index.

2025-01-27  Yury Khrustalev  <yury.khrustalev@arm.com>

	Fix some broken links in docs and comments
	Reviewed-By Richard Earnshaw <richard.earnshaw@arm.com>

2025-01-27  Christopher Wellons  <wellons@nullprogram.com>

	Exclude libpthread from automatic export generation
	Before this change, static linking libwinpthread, commonly distributed
	as part of Mingw-w64, while using automatic symbol exports would export
	the entire threading API, which is never wanted. This is always the case
	when static linking libstdc++ built against libpthread.

2025-01-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-26  H.J. Lu  <hjl.tools@gmail.com>

	ld-x86-64/pr19609-2d.d: Move "#pass" to the end
		* testsuite/ld-x86-64/pr19609-2d.d:  Move "#pass" to the end.

2025-01-26  Alan Modra  <amodra@gmail.com>

	loongson buffer overflow
	bfd_elfNN_loongarch_set_data_segment_info can be called from the target
	after_allocation function with a non-ELF hash table.  This is seen in
	the ld-elf pr21884 testcase.  Fix the problem by first checking the
	hash table type before writing to a loongarch_elf_hash_table field.

2025-01-26  Alan Modra  <amodra@gmail.com>

	PR32599, objcopy -I ihex: invalid operation
	Restores ihex get_symtab_upper_bound to what it was prior to commit
	394a3f4f8d.  This will enable objcopy of other no-sym formats too.

		PR 32599
		* libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define
		as _bfd_long_bfd_0.
		* libbfd.h: Regenerate.

2025-01-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-25  Alan Modra  <amodra@gmail.com>

	Re: ld plugin bfd_make_readable leak
	Commit 3097045a18a8 runs into an abort in objalloc_free_block when the
	memory being bfd_release'd wasn't bfd_alloc'd.  Fix that.

		* coffgen.c (_bfd_coff_free_cached_info): Don't release
		raw_syments when obj_coff_keep_raw_syms.
		* libcoff-in.h (obj_coff_keep_raw_syms): Define.
		(struct coff_tdata): Add keep_raw_syms.
		* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_keep_raw_syms.
		* libcoff.h: Regenerate.

2025-01-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-24  Tom Tromey  <tom@tromey.com>

	Fix C++ template function matching in cooked index
	In commit 64a97606 ("Support template lookups in
	strncmp_iw_with_mode"), gdb was changed so that a command like "break
	func<templ>" would match instantiations like "func<templ<int>>".

	The new indexer does not support this and so this is a regression.
	This went unnoticed because gdb.linespec.cpcompletion.exp puts all
	these functions into the main file, and this CU is expanded early.

	This patch fixes the bug by changing the cooked index entry comparison
	function.  It also updates the test to fail without this fix.

	Regression tested on x86-64 Fedora 40.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482

2025-01-24  Ciaran Woodward  <ciaranwoodward@xmos.com>

	gdb/riscv: Add command to switch between numeric & abi register names
	In RISC-V, the general registers can be shown in their abi
	form (e.g. sp, a0) or their numeric form (e.g. x2, x10).
	Depending on context/preference, someone may prefer to
	see one form over the other. The disassembler already
	supports this configuration, which can be changed using
	the 'set disassembler-options numeric' command.

	This commit adds a new set/show command to change gdb's
	preference: 'set riscv numeric-registers-names on/off'.

	If on, 'info registers' and other situations will print
	the numeric register names, rather than the abi versions.
	The alias generation has been modified so that the abi
	versions are still available for access if specifically
	requested such as 'print $ra'. This was done by changing
	the behaviour of the code which adds the aliases: all
	register names will be added as aliases, even if the name
	is the primary one.

	There is also no functional downside to adding aliases
	which are surplus-to-requirement, since they will be
	ignored if there is a 'true' register with the same
	name.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-24  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.ada/O2_float_param.exp on s390x-linux
	With test-case gdb.ada/O2_float_param.exp on s390x-linux, I get:
	...
	 (gdb) frame^M
	 #0  callee.increment (val=99.0, val@entry=<error reading variable: \
	   register has not been saved in frame>, msg=...) at callee.adb:19^M
	 19         procedure Increment (Val : in out Float; Msg: String) is^M
	 (gdb) FAIL: $exp: scenario=all: frame
	...

	The frame command calls read_frame_arg to get:
	- the current value of val, and
	- the value of val at function entry.

	The first scenario succeeds, and the second scenario fails.

	For context and contrast, let's also investigate the first scenario: getting
	the current value of val.

	Function parameter val:
	...
	 <2><b51>: Abbrev Number: 4 (DW_TAG_formal_parameter)
	    <b52>   DW_AT_name        : val
	    <b58>   DW_AT_type        : <0xb86>
	    <b5c>   DW_AT_location    : 0xab (location list)
	...
	has location list:
	...
	    000000ab 0000000001002928 0000000001002967
	      (DW_OP_reg16 (f0))
	    000000be 0000000001002967 0000000001002968
	      (DW_OP_reg24 (f8))
	    000000d1 0000000001002968 0000000001002974
	      (DW_OP_GNU_regval_type: 24 (f8) <0xb29>;
	       DW_OP_GNU_const_type: <0xb29>  4 byte block: 3f 80 0 0 ; DW_OP_plus;
	       DW_OP_stack_value)
	    000000ef 0000000001002974 0000000001002982
	      (DW_OP_GNU_entry_value: (DW_OP_GNU_regval_type: 16 (f0) <0xb29>);
	       DW_OP_GNU_const_type: <0xb29>  4 byte block: 3f 80 0 0 ; DW_OP_plus;
	       DW_OP_stack_value)
	    0000010f <End of list>
	...
	and since we're stopped at address 0x1002928:
	...
	(gdb) print $pc
	$1 = (access procedure) 0x1002928 <callee.increment>
	...
	we get the value from dwarf register 16.

	The s390x ABI [1] specifies that dwarf register 16 maps onto 8-byte register
	f0 or 16-byte register v0 (where f0 is part of v0), and in this case (because
	the v0 register is available) s390_dwarf_reg_to_regnum maps it to v0.

	Val is only 4 bytes:
	...
	(gdb) ptype val
	type = <4-byte float>
	...
	and s390_value_from_register takes care to get the value from the correct part
	of v0.

	The value of v0 is found in the prologue cache, and the value of parameter val
	is printed.

	Now the second scenario: getting the value of val at function entry.

	FWIW, since we're stopped at function entry, we could simply return the same
	value, reading the same register, but that's currently not implemented [2].

	Instead we start from the fact that val is in dwarf reg 16 at function entry,
	and then use call site information:
	...
	 <4><cf7>: Abbrev Number: 13 (DW_TAG_GNU_call_site)
	    <cf8>   DW_AT_low_pc      : 0x1002a46
	    <d00>   DW_AT_abstract_origin: <0xdda>
	 <5><d04>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
	    <d05>   DW_AT_location    : 1 byte block: 60        (DW_OP_reg16 (f0))
	    <d07>   DW_AT_GNU_call_site_value: 3 byte block: f5 18 2d   \
	              (DW_OP_GNU_regval_type: 24 (f8) <0xc42>)
	 <5><d0b>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
	...
	to conclude that the value we're looking for is in dwarf reg 24, which
	s390_dwarf_reg_to_regnum maps to v8.

	As before, s390_value_from_register takes care to get the value from the
	correct part of v8.

	However, v8 is not available in the prologue cache, and we take a different
	path and end up in s390_unwind_pseudo_register, where v8 and similar
	(regnum_is_vxr_full) is unhandled, and we get:
	...
	   return value::allocate_optimized_out (type);
	...
	which eventually causes the "error reading variable: register has not been
	saved in frame".

	Fix this by handling the regnum_is_vxr_full case in
	s390_unwind_pseudo_register, similar to how that is done in
	s390_pseudo_register_read.

	Tested on s390x-linux.

	This also fixes test-case gdb.base/savedregs.exp.

	[1] https://github.com/IBM/s390x-abi
	[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211589.html

2025-01-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Record less in gdb.reverse/time-reverse.exp
	While stepping through gdb.reverse/time-reverse.exp I realized that we're
	recording the instructions for resolving the PLT entries for functions time
	and syscall, while that's not really the focus of the test-case.

	Limit the scope of the test, by calling the functions once before starting
	to record.

	Also call "info record" after recording to make it clear how many
	instructions were recorded.

	On x86_64-linux, before this patch (but with info record added), we have:
	...
	$ grep "Log contains" gdb.log
	Log contains 750 instructions.
	Log contains 1218 instructions.
	...
	and with this patch we have:
	...
	$ grep "Log contains" gdb.log
	Log contains 24 instructions.
	Log contains 19 instructions.
	...

	Tested on x86_64-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-24  Richard Earnshaw  <rearnsha@arm.com>

	aarch64: Fix PLT fixups when BTI is used [PR32572]
	PR ld/32572

	There are two problems addressed in this PR.  Firstly, the choice of
	whether or not a PLT stub needs a BTI on entry was too strict,
	resulting in non-pie executables not having a BTI on their stub.  But
	secondly, the logic to handle each stub types did not agree across the
	various places where this information is used.

	The first issue is fixed by using bfd_link_executable rather than
	bfd_link_pde.  The second is addressed by recording a delta for PLT
	stub alongside the stub itself.  This is then used without needing
	additional logic later on since it has been pre-calculated.

	A more comprehensive fix would involve creating a data structure to
	describe each fixup, including a call-back function to apply any
	relocations.  But that's a fairly large change and not appropriate for
	backporting.

2025-01-24  Jan Beulich  <jbeulich@suse.com>

	x86-64: tighten convert-load-reloc checking
	Even if the assembler avoids using relaxable relocations for
	inapplicable insns, such relocations can still appear for other reasons.
	Be more thorough in the opcode checking we do, to avoid bogusly altering
	other insns.

	Furthermore correct an opcode mask (even if with the added condition
	that's now fully benign).

2025-01-24  Jan Beulich  <jbeulich@suse.com>

	x86/APX: widen @gotpcrel and @gottpoff support (incl to MOVRS)
	If legacy-encoded arithmetic insns are eligible for @gotpcrel
	relaxation, EVEX-encoded ones ought to be, too.

	Further anything that MOV-from-memory can be used for (and transformed
	from) should then also extend to MOVRS.

	While extending the apx-load* testcases add  -mrelax-relocations=yes to
	the two ones which were missing this: Without this option the intended
	testing would not occur on configurations defaulting the option to off.

2025-01-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-23  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bfd: fix generation of bfd.texi in out-of-tree builds
	[In the sequel TS means $(top_srcdir) and TB means $(top_builddir)]

	The Texinfo file TS/bfd/doc/bfd.texi @includes many other .texi files
	such as:

	   bfdt.texi
	   bfdio.texi
	   section.texi
	   ...

	These .texi files are generated from the bfd/*.c source files, by a
	program called `chew' that is distributed along with BFD, via some
	default rules and macro magic in TS/bfd/doc/local.mk.  Important
	point: the .texi files are generated in TB/bfd/doc/, not TS/bfd/doc.

	Now, AM_MAKEINFOFLAGS in local.mk is defined as:

	  AM_MAKEINFOFLAGS = --no-split -I "$(srcdir)/%D%" -I %D%

	Where %D% is 'doc/' in this case.  Now, it looks like the directory
	containing the .texi file is automatically inserted in the @include
	search path, so the -I %D% above places TB/bfd/doc _after_ TS/bfd/doc.

	Since currently TS/bfd/doc/bfdt.texi is outdated and is missing some
	nodes, the error above happens.

	This patch changes bfd/doc/local.mk to use -P to prepend the current
	build directory to the @include search path, rather than -I, which
	appends it.

	bfd/ChangeLog:

	2025-01-23  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* doc/local.mk (AM_MAKEINFOFLAGS): Prepend the build directory to
		the @include search path.
		* Makefile.in: Regenerate.

2025-01-23  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Fix return from frame containing inline frame
	Consider test-case gdb.base/return-3.exp:
	...
	$ gdb -q outputs/gdb.base/return-3/return-3
	Reading symbols from outputs/gdb.base/return-3/return-3...
	(gdb)
	...

	Function bar is an inlined function, and consequently we cannot return from
	it:
	...
	(gdb) b bar
	Breakpoint 1 at 0x4006ac: file return-3.c, line 25.
	(gdb) r
	Starting program: return-3
	  ...
	Breakpoint 1, bar () at return-3.c:25
	25        c++;
	(gdb) return
	Can not force return from an inlined function.
	(gdb)
	...

	However, function foo is not an inline function, and we should be able to
	return from it, but we get the same error message:
	...
	(gdb) up
	31        bar ();
	(gdb) return
	Can not force return from an inlined function.
	(gdb)
	...

	Fix this by using the selected frame rather than the current frame in
	return_command, such that we get instead:
	...
	(gdb) up
	31        bar ();
	(gdb) return
	40        printf ("%d\n", c);
	(gdb)
	...

	Tested on aarch64-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

	PR cli/32479
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479

2025-01-23  Surya Kumari Jangala  <jskumari@linux.ibm.com>

	PowerPC: Add support for RFC02657 - AES acceleration instructions
	opcodes/
		* ppc-opc.c (insert_m2, extract_m2): New functions.
		(AESM, PGF1, XX2M, XX3M, XX3GF, XX2AES_MASK, XX2AESM_MASK,
		XX3AES_MASK, XX3AESM_MASK, XX3GF_MASK): New macros.
		(UIM): Update for new macros.
		(powerpc_opcodes): Add xxaes128encp, xxaes192encp, xxaes256encp,
		xxaesencp, xxaes128decp, xxaes192decp, xxaes256decp, xxaesdecp,
		xxaes128genlkp, xxaes192genlkp, xxaes256genlkp, xxaesgenlkp,
		xxgfmul128gcm, xxgfmul128xts, xxgfmul128.

	gas/
		* testsuite/gas/ppc/future.s: New test.
		* testsuite/gas/ppc/future.d: Likewise.

2025-01-23  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>
	    Guillaume VACHERIAS  <guillaume.vacherias@st.com>

	ld: fix alignment issue for ARM thumb long branch stub using PureCode section
	When pure-code option is activated. The linker creates for M-profile architecures
	a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte
	alignment instead of 4-byte alignment. This is a problem for long branch stub
	without pure-code section as it contains a 32-bit address as data, which is expected
	to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed
	by a long branch stub will result in a misalignment for the 32-bit address.

	An easy fix is to add a nop instruction after the branch to keep the section alignment
	to 4 bytes.

2025-01-23  Alan Modra  <amodra@gmail.com>

	ld plugin bfd_make_readable leak
	bfd_make_readable leaks memory that could be freed by
	_free_cached_info except that does too much in releasing all bfd
	memory.  (The fact that we had to hack around keeping the bfd filename
	also indicates that releasing all bfd memory was too much.)  So this
	patch moves code releasing bfd_alloc'd memory to the COFF
	_free_cached_info, where the syms and suchlike are released.  This is
	the memory that archive handling wants to release in the call there to
	bfd_free_cached_info.

		* coffgen.c (_bfd_coff_free_cached_info): Release syms.
		* opncls.c (_bfd_new_bfd): Correct error return path.
		(_bfd_free_cached_info): Don't kill all abfd->memory.
		(_bfd_delete_bfd): Adjust fallback for bfd_free_cached_info.
		(bfd_make_readable): Call target bfd_free_cached_info and
		_bfd_free_cached_info plus reinstate section_htab.

2025-01-23  Alan Modra  <amodra@gmail.com>

	ld compact eh-frame leak
	u.compact.extries wasn't being freed anywhere.  Free it when
	destroying the linker hash table.  Also free u.dwarf.aray there in
	case errors result in the linker not getting to the slightly earlier
	free in write_dwarf_eh_frame_hdr.

		* elf-eh-frame.c (write_dwarf_eh_frame_hdr): Don't exit without
		freeing u.dwarf.array.
		* elflink.c (_bfd_elf_link_hash_table_free): Free u.compact.entries
		and u.dwarf.array.

2025-01-23  Alan Modra  <amodra@gmail.com>

	ld plugin.c concat leaks
		* ldlang.c: Whitespace.
		(stat_free, stat_concat): New functions.
		* ldlang.h (stat_free, stat_concat): Declare.
		* plugin.c (asymbol_from_plugin_symbol): Use stat_concat.

2025-01-23  Alan Modra  <amodra@gmail.com>

	unusual eh_frame memory leak
	This one happens with --gc-sections and a linker script that either
	discards some or all .eh_frame sections (eg. ld-elf/pr14265 test) or
	maps an input .eh_frame to some other named output section.  In that
	case the discarded/renamed .eh_frame won't have local_cies freed.

		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Correct comment.
		* elf.c (_bfd_elf_free_cached_info): Free eh_frame cies.

2025-01-23  Alan Modra  <amodra@gmail.com>

	Another ldelf_before_allocation leak
	This fixes an even more obvious leak.

		* ldelf.c (ldelf_before_allocation): Free copied elf_dt_audit.
		Simplify loop.

2025-01-23  Alan Modra  <amodra@gmail.com>

	More ld testsuite fixes
		* testsuite/ld-elf/indirect.exp: Run compiler capability checks
		using run_host_noleak.
		* testsuite/ld-ifunc/ifunc.exp: Don't exit without restoring
		ASFLAGS.  Don't run ifuncmod5 twice.

2025-01-23  Sam James  <sam@gentoo.org>

	ld: fix bashism in scripttempl/elf.sc
	ld/
		PR ld/32580

		* scripttempl/elf.sc: Fix '==' bashism.

2025-01-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-22  Tom Tromey  <tromey@adacore.com>

	Remove gnatmake_version_at_least
	This removes gnatmake_version_at_least in favor of using the more
	flexible gnat_version_compare.  I think these two version numbers
	should be the same, as gnatmake is shipped with the compiler.

	Avoid crash with 'length
	While testing gnat-llvm, I found a gdb crash when applying 'length to
	a non-array type.  This patch fixes the crash.

	Preserve local variables in another Ada test case
	I found another Ada test case where gnat-llvm optimizes away the local
	variables.  This patch applies the same fix to it as previous patches.

2025-01-22  Andrew Burgess  <aburgess@redhat.com>

	bfd/doc: use abs_srcdir when creating symlinks
	After commit:

	  commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
	  Date:   Fri Dec 3 00:23:20 2021 -0500

	      bfd: merge doc subdir up a level

	And the follow-up commit:

	  commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33
	  Date:   Wed Oct 2 22:58:08 2024 +0300

	      bfd: fix unnecessary bfd.info regen

	There is still a problem building the bfd docs from a release tar
	file.

	As the release tar file contains the pre-generated .texi files we
	expect the bfd/doc build stage to symlink to the pre-existing .texi
	files in the source tree.

	However, this is still not working as expected if $(srcdir) is
	relative.  The problem is this line in REGEN_TEXI:

	    test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \

	This is executed from the build/bfd/ directory, so if $(srcdir) is
	relative, then this will get you from the bfd/ directory in the build
	tree to the corresponding bfd/ directory in the src tree.  However,
	the symlink is created in the bfd/doc/ build directory.  The relative
	path will then fail to take you to the bfd/ directory in the src
	tree.

	Fix this by using $(abs_srcdir) when creating the symlink.

	Approved-By: Nick Clifton <nickc@redhat.com>

2025-01-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/branch-to-self.exp on arm-linux
	On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
	test-case gdb.base/branch-to-self.exp I run into:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, main () at branch-to-self.c:38^M
	38        for (;;); /* loop-line */^M
	(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
	si^M
	0x0040058c      38        for (;;); /* loop-line */^M
	(gdb) FAIL: $exp: single-step: si
	...

	In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, main () at branch-to-self.c:38^M
	38        for (;;); /* loop-line */^M
	(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
	si^M
	^M
	Breakpoint 2, main () at branch-to-self.c:38^M
	38        for (;;); /* loop-line */^M
	(gdb) PASS: $exp: single-step: stepi
	...

	The difference is in the instruction(s) generated for the loop.

	In the passing case, we have:
	...
	 588:   eafffffe        b       588 <main+0x24>
	...
	and in the failing case:
	...
	 588:   e320f000        nop     {0}
	 58c:   eafffffd        b       588 <main+0x24>
	...

	The purpose of this part of the test-case is to:
	- generate a branch instruction that jumps to itself, and
	- set a breakpoint on it, and check that stepi-ing from that breakpoint
	  triggers the breakpoint again.

	As we can see, in the failing case we failed to generate a branch instruction
	that jumps to itself, and consequently we cannot expect to hit the breakpoint
	again after issuing a single si.

	Fix this by issuing stepi until we hit the breakpoint.

	Tested on arm-linux.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2025-01-22  Jan Beulich  <jbeulich@suse.com>

	x86/Solaris: correct support for Sun form of CMOV<size>.S
	PR gas/32579

	The deprecated .s (swapped operand encoding) functionality got in the
	way of properly recognizing this specific form. Move the Solaris-
	specific code ahead of that.

2025-01-22  Jan Beulich  <jbeulich@suse.com>

	ld: replace another @progbits etc in an ELF testcase
	The canonical form (in the testsuite) is %progbits and alike.

2025-01-22  timhu2011  <hudi2011@163.com>

	x86: Add missing @tab to separate columns in c-i386.texi
	I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.

	gas/ChangeLog:

		* doc/c-i386.texi: Add the missing @tab for .gmiccs and
		  .padlockphe2

2025-01-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-21  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix gdb.base/fission-macro.exp with unix/-m32
	When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed
	(using gcc 14) with target board unix/-m32, I get:
	...
	(gdb) info macro FIRST^M
	Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M
	-DFIRST=1^M
	(gdb) FAIL: $exp: \
	  dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
	...
	instead of the expected:
	...
	(gdb) info macro FIRST^M
	Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M
	(gdb) PASS: $exp: \
	  dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
	...

	A dwarf-5 .debug_str_offsets section starts with a header consisting of:
	- an initial length (4 bytes for 32-bit and 12 bytes for 64-bit),
	- a 2 byte version string, and
	- 2 bytes padding
	so in total 8 bytes for 32-bit and 16 bytes for 64-bit.

	This offset is calculated here in dwarf_decode_macros:
	...
	      str_offsets_base = cu->header.addr_size;
	...
	which is wrong for both dwarf-5 cases (and also happens to be wrong for
	dwarf-4).

	Fix this by computing str_offsets_base correctly for dwarf-5, for both the
	32-bit and 64-bit case.

	Likewise, fix this for dwarf-4, using str_offsets_base 0.  We can only test
	this with gcc-15, because gcc 14 and earlier don't have the fix for
	PR debug/115066.

	Tested on x86_64-linux.

	Tested test-case using a current gcc trunk build, and gcc 14.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/31897
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897

2025-01-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use -g3 in gdb.base/lineinc.exp
	The stated intention of test-case gdb.base/lineinc.exp is:
	...
	 # Test macro handling of #included files.
	...

	However, the test-case does not produce any macro debug information.

	Fix this by adding macros in the compilation flags.

	Tested on x86_64-linux.

2025-01-21  Nick Clifton  <nickc@redhat.com>

	More updated translations

2025-01-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-20  Alan Modra  <amodra@gmail.com>

	Support broken gcc test for gas string merge support
	On casual reading of older gcc configure scripts it might be supposed
	that the test for gas string merge support tries with %progbits after
	a fail on ARM with @progbits.  It doesn't succeed due to a bug.  So to
	support building of older gcc's for ARM without users having to edit
	gcc sources, add a hack to gas.  The hack can disappear in a few years
	when building older gcc's likely requires other work too.

	I've changed the docs to reflect what we actually allow for .section
	syntax prior to this patch.  (No way should this hack be documented as
	allowed!)

		PR 32491
		* config/obj-elf.c (obj_elf_section): Allow missing entsize
		for ARM gcc configure bug.
		* doc/as.texi: Correct syntax of ELF .section directive.
		* testsuite/gas/elf/string.s,
		* testsuite/gas/elf/string.d: Test it.

2025-01-20  Alan Modra  <amodra@gmail.com>

	run_dump_test warning/error regexp
	This allows you to specify a run_dump_test warning that may or may not
	be present using
	warning: (warning_text_goes_here)?
	ie. the regexp matches an empty string.

2025-01-20  Alan Modra  <amodra@gmail.com>

	asan ld builds without detect_leaks=0
	I found that building binutils with -fsanitize=address,undefined
	results in much of the testsuite not being run.  The problem is that
	running gcc results in linker plugin memory leaks which of course are
	errors, so the testsuite sees this as lack of compiler support.

		* testsuite/lib/ld-lib.exp (run_host_noleak): New proc.
		(check_compiler_available, check_lto_available),
		(check_lto_fat_available, check_lto_shared_available),
		(check_ifunc_available, check_ifunc_attribute_available),
		(check_libdl_available, check_gnu2_tls_available),
		(compile_one_cc): Use run_host_noleak.
		* testsuite/config/default.exp (compiler_supports): Likewise.

2025-01-20  Maciej W. Rozycki  <macro@redhat.com>

	LD: Remove duplicate 2.44 NEWS marker
	Delete an extra 2.44 NEWS marker that has crept in by chance.

2025-01-20  Nick Clifton  <nickc@redhat.com>

	Update translations for various sub-directories

	Update release readme for gold-in-branches change

2025-01-20  Lulu Cai  <cailulu@loongson.cn>

	gas/NEWS,ld/NEWS: Announce LoongArch changes in 2.44

2025-01-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: Fix file location for gdb.base/backtrace-through-cu-nodebug
	The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a
	problem in the call to gdb_compile, that caused the .o files to be
	outputted in the GDB file tree. This commit fixes the issues in the calls.

	Reported-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-01-20  Nick Clifton  <nickc@redhat.com>

	Update how-to-make-a-release document after creating the 2.44 branch

2025-01-20  Richard Earnshaw  <rearnsha@arm.com>

	gas: elf: Relax rules for SHF_STRING sections
	Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
	declared with "S" (SHF_STRING) to specify the entity size, but then
	would warn if the entity size was omitted, as with the old syntax.

	Unfortunately, since specifying the entity size is incompatible with
	binutils 2.43 or earlier, this makes it impossible to specify a
	strings section in source code without generating an assembly warning
	(the new syntax isn't supported in older assemblers and the old syntax
	generates warnings).

	Nevertheless, the old code was wrong in that it did not set the entity
	size at all, in contravention of the ELF specification (though to date
	there are no known cases where this mattered outside of mergeable
	sections).

	Fix this by permitting the original syntax without a warning again,
	but by defaulting the entity size to 1.  This is compatible with the
	most common case of strings being byte-based.

	Added some tests for the various flavours of declaration that we
	support.

2025-01-20  Alan Modra  <amodra@gmail.com>

	ldelf_before_allocation leak
	ldelf_before_allocation is passed the audit and depaudit strings built
	from command line args, then possibly adds to the depaudit string,
	freeing the original.  The new string isn't freed.  Fix this leak by
	keeping the string attached to the static vars.

		* ldelf.c (ldelf_before_allocation): Pass char** for audit
		and depaudit.  Adjust uses.
		* ldelf.h (ldelf_before_allocation): Update prototype.
		* gld${EMULATION_NAME}_before_allocation: Update call.

2025-01-20  Alan Modra  <amodra@gmail.com>

	Re: elflink.c memory leaks
		* elflink.c (elf_link_add_object_symbols): Free old_strtab
		in another code path.  Revert one unnecessary change in last
		patch.

2025-01-20  Alan Modra  <amodra@gmail.com>

	_bfd_elf_get_dynamic_symbols
	This fixes an error path in _bfd_elf_get_dynamic_symbols, fixes the
	minimum size required when reading DT_HASH header, and tidies
	formatting in a few places.  Nit-fixes all.

	Very likely we shouldn't be trying to mmap DT_DYNAMIC as it won't be
	large enough for the mmap size threshold.

		* elf.c (_bfd_elf_get_dynamic_symbols): Use _bfd_munmap_temporary
		in error return path rather than free.  Corrent size passed to
		offset_from_vma when reading DT_HASH header.  Formatting.

2025-01-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/non-trivial-retval.exp on arm-linux with gcc 13
	On arm-linux, with target board unix/-mthumb, we get:
	...
	(gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here
	p f1 (i1, i2)^M
	$1 = {a = -136274256}^M
	(gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)>
	...

	This is not a problem with the inferior call, which works fine:
	...
	(gdb) p f1 (23, 100)
	$3 = {a = 123}
	...
	but instead it's a problem with the location information:
	...
	(gdb) p i1
	$1 = -136274356
	(gdb) p i2
	$2 = 100
	...
	which tells us to find the value of i1 in (DW_OP_fbreg: -12).

	The test-case passes if we drop -fvar-tracking, in which case the debug info
	tells us to find the value of i1 in (DW_OP_fbreg: -20).

	This is with gcc 13.3.0 on Ubuntu 24.04.  With gcc 14.2.0 on Debian testing,
	the code is the same, but -fvar-tracking does use the correct
	'(DW_OP_fbreg: -20)'.

	There seems to be some bugfix in -fvar-tracking for gcc 14.

	Workaround the bug by using constants 23 and 100 instead of i1 and i2 when
	using -fvar-tracking and gcc < 14.

	Tested on arm-linux.

	PR testsuite/32549
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549

2025-01-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-19  Alan Modra  <amodra@gmail.com>

	reloc caching
	This arranges to free section relocs cached in elf_section_data.  To
	do that, some relocs stored there need to use bfd_malloc buffers
	rather than bfd_alloc ones.

		* elf.c (_bfd_elf_free_cached_info): Free relocs.
		* elf32-ppc.c (ppc_elf_relax_section): Realloc relocs rather
		than malloc, copy, free old.
		* elf64-ppc.c (get_relocs): bfd_malloc relocs.
		* elflink.c (_bfd_elf_link_info_read_relocs): Always
		bfd_malloc relocs.

2025-01-19  Alan Modra  <amodra@gmail.com>

	sec->alloced and freeing section contents
	This modifies _bfd_elf_free_cached_info to unmap/free section
	contents.  To do that we need to *not* free sections where contents
	are bfd_alloc'd or point to constant strings or somesuch.  I've chosen
	to implement this be adding another flag to struct bfd_section,
	"alloced" to say the section contents can't be freed.  Most of the
	patch is about setting that flag in many places.

2025-01-19  Alan Modra  <amodra@gmail.com>

	_bfd_elf_munmap_section_contents
	Do unmap/free cached contents to avoid some memory leaks we'd
	otherwise see.

		* elf.c (_bfd_elf_munmap_section_contents): Clear pointers to
		contents that we unmap/free rather than not unmapping/freeing.

2025-01-19  Alan Modra  <amodra@gmail.com>

	Replace xmalloc with stat_alloc in ld parser
	A few place dealing with ld script handling made some attempt to free
	memory, but this was generally ignored and would be quite a lot of
	work to implement.  Instead, use the stat_obstack rather than
	mallocing in many more cases.

		* ldexp.c (exp_get_fill): Use stat_alloc for fill.
		* ldfile.c (ldfile_try_open_bfd): Don't free yylval fields.
		* ldgram.y: Replace xmalloc with stat_alloc throughout.
		* ldlang.c (stat_memdup, stat_strdup): New functions.
		(ldirname): Use stat_memdup.  Don't strdup ".".
		(output_section_callback_sort): Use stat_alloc.
		(output_section_callback_tree_to_list): Don't free.
		(lang_memory_region_lookup): Use stat_strdup.
		(lang_memory_region_alias): Likewise.
		(add_excluded_libs): Use stat_alloc and stat_memdup.
		(ldlang_add_undef, ldlang_add_require_defined): Use stat_strdup.
		(lang_add_nocrossref, lang_leave_overlay): Use stat_alloc.
		(realsymbol): Use stat_strdup for return value and always
		free symbol.
		(lang_new_vers_pattern, lang_new_vers_node): Use stat_alloc.
		(lang_finalize_version_expr_head): Don't free.  Delete FIXME.
		(lang_register_vers_node): Don't free.
		(lang_add_vers_depend): Use stat_alloc.
		(lang_do_version_exports_section): Likewise.
		(lang_add_unique): Use stat_alloc and stat_strdup.
		(lang_append_dynamic_list): Use stat_alloc.
		* ldlang.h (stat_memdup, stat_strdup): Declare.
		* ldlex.l: Replace xstrdup with stat_strdup throughout.
		Replace xmemdup with stat_memdup too.
		* lexsup.c (parse_args): Don't free export list or dynamic
		list.

2025-01-19  Alan Modra  <amodra@gmail.com>

	Use stat_alloc in plugin
	We never free the tv array.

		* plugin.c (plugin_load_plugins): Use stat_alloc.

2025-01-19  Nick Clifton  <nickc@redhat.com>

	Change version to 2.44.50 and regenerate files

	Add name of 2.44 branch

	Add markers for bihnutils 2.44 branch

2025-01-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-18  Alan Modra  <amodra@gmail.com>

	Re: binary outsymbols
	The "of course to free outsymbols" turned out to be wrong.  outsymbols
	belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced
	a double free.

		* srec.c (srec_write_symbols): Don't free outsymbols.
		* tekhex.c (tekhex_write_object_contents): Likewise.

2025-01-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-17  Tom Tromey  <tromey@adacore.com>

	Simplify get_frame_unwind_table
	This simplifies get_frame_unwind_table, changing it to use the
	registry 'emplace' method and to pass the initialization iterators to
	the constructor.  This fixes a build problem on x86 -- reported by the
	auto-builder -- as a side effect.

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb/reverse: Fix recording vmov[u|a]p[s|d] instructions
	Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
	failing. In my machine xmm3 was consistently set to 0x54, but apparently
	that is different depending on the system. This commit zeroes out xmm3
	at the start of the test instead.

	While debugging the test failures, I also noticed an issue where the
	recording wasn't saving all the required memory. That happened because
	vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
	share code paths, but the latter encodes memory modification size on
	VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
	and made the relevant tests more robust and complete.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-17  Tom Tromey  <tromey@adacore.com>

	Fix self-test crash
	My earlier changes introduced a self-test crash.  This patch fixes the
	bug by introducing a new method overload into mock_mapped_index.

2025-01-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: some more details in the README file
	After some recent discussions on the mailing list, I've made some
	changes to the README to (I hope) provide more clarity.

	The changes I made are:

	  1. Removed the use of a lone 'HOST' on the configure line.  I tried
	  this and 'configure' gave me a warning:

	    configure: WARNING: you should use --build, --host, --target

	  So I don't think this is approved practice any more.  We should
	  encourage users to use `--host` instead.

	  2. Added and reworded the --host, --target, and --enable-targets
	  descriptions in the 'configure options' section.  My goals here are
	  to clarify that 'cross-debugging' is really the same as 'remote
	  debugging', and also to make it clearer what the defaults are.

	  3. Added some additional text to the 'Remote debugging' section
	  mentioning that 'remote debugging' is basically the same as 'cross
	  debugging', given that we use 'cross-debugging' in the text above.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2025-01-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: quote inferior arguments, if needed,  when opening a core file
	This commit fixes an issue with the commit:

	  commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
	  Date:   Thu Apr 25 09:36:43 2024 +0100

	      gdb: add gdbarch method to get execution context from core file

	The above commit improves GDB's ability to display inferior arguments
	when opening a core file, however, if an argument includes white
	space, then this is not displayed as well as it should be.  For
	example:

	  (gdb) core-file /tmp/corefile-exec-context.2.core
	  [New LWP 4069711]
	  Reading symbols from /tmp/corefile-exec-context...
	  Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
	  Program terminated with signal SIGABRT, Aborted.
	  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
	  50	  return ret;
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
	  (gdb)

	Notice the 'Core was generated by ...' line.  In this case it is not
	clear if the "e e e e e" is a single argument containing white space,
	or 5 single arguments.

	But when we 'show args' it is immediately clear that this is a single
	argument, as the white space is now escaped.

	This problem was caused by the above commit building the argument
	string itself, and failing to consider white space escaping.

	This commit changes things around, first we place the arguments into
	the inferior, then, to print the 'Core was generated by ...' line, we
	ask the inferior for the argument string.  In this way the quoting is
	handled just as it is for 'show args'.  The initial output is now:

	  (gdb) core-file /tmp/corefile-exec-context.2.core
	  [New LWP 4069711]
	  Reading symbols from /tmp/corefile-exec-context...
	  Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
	  Program terminated with signal SIGABRT, Aborted.
	  #0  0x00007f4f007af625 in raise () from /lib64/libc.so.6
	  (gdb)

	Much better.  The existing test is extended to cover this case.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: update binutils/NEWS for 2.44
	ChangeLog
	2025-01-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* binutils/NEWS: Updated.

2025-01-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix Segmentation Fault in DbeInstr::mapPCtoLine
	The bug was filed against gprofng-gui (https://savannah.gnu.org/bugs/?66560).

	gprofng/ChangeLog
	2025-01-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Hist_data.cc (DbeInstr::mapPCtoLine): Check for null pointer.

2025-01-17  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Fix sve2p1 gating and add missing instructions
	Many FEAT_SVE2p1 instructions need to be enabled by either of two
	different features (one for streaming mode, and one for non-streaming
	mode).  This patch adds correct gating conditions for these
	instructions.

	There were also a few sve2p1 instructions missing altogether, so add
	those as well.

	The testsuite is modified to check for all alternative enablement
	conditions.  In many cases this is done by adding an alternative
	assembler commands to existing test files.  For some SME/SME2 tests,
	only some of the instructions are enabled by +sve2p1, so these are
	copied into a separate test.  For original SVE2p1 tests, the non-SME2p1
	instructions have been moved to a separate test file.

	There are also new tests for the newly added instructions.  These
	include a couple of fixme comments relating to bad error reporting,
	which should be investigated later.

2025-01-17  Tom Tromey  <tromey@adacore.com>

	Remove mapped_index_base
	The base class mapped_index_base is no longer needed.  Previously it
	was used by both the .gdb_index and .debug_names readers, but the
	latter now uses the cooked index instead.

	This patch removes mapped_index_base, merging it into
	mapped_gdb_index.  Supporting code that is specific to .gdb_index is
	also moved into read-gdb-index.c.  This shrinks dwarf2/read.c a bit,
	which is nice.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Tom Tromey  <tromey@adacore.com>

	Remove gdb_index_unpack
	gdb_index_unpack is not used and can be removed.  The include of
	extract-store-integer.h is also no longer needed by this file.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Tom Tromey  <tromey@adacore.com>

	Add missing includes of extract-store-integer.h
	I found a number of .c files that need to include
	extract-store-integer.h but that were only including it indirectly.
	This patch adds the missing includes.  This change enables the next
	patch.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: Test for a backtrace through object without debuginfo
	Fedora has been carrying this test since back in the Project Archer
	days. A change back then caused GDB to stop being able to backtrace when
	only some of the object files had debug information. Even though the
	changed code never seems to have made its way into the main GDB project,
	I think it makes sense to bring the test along to ensure something like
	this doesn't pass unnoticed.

	Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb: introduce ability to disable frame unwinders
	Sometimes, in the GDB testsuite, we want to test the ability of specific
	unwinders to handle some piece of code. Usually this is done by trying
	to outsmart GDB, or by coercing the compiler to remove information that
	GDB would rely on.  Both approaches have problems as GDB gets smarter
	with time, and that compilers might differ in version and behavior, or
	simply introduce new useful information. This was requested back in 2003
	in PR backtrace/8434.

	To improve our ability to thoroughly test GDB, this patch introduces a
	new maintenance command that allows a user to disable some unwinders,
	based on either the name of the unwinder or on its class. With this
	change, it will now be possible for GDB to not find any frame unwinders
	for a given frame, which would previously cause GDB to assert. GDB will
	now check if any frame unwinder has been disabled, and if some has, it
	will just error out instead of asserting.

	Unwinders can be disabled or re-enabled in 3 different ways:
	* Disabling/enabling all at once (using '-all').
	* By specifying an unwinder class to be disabled (option '-class').
	* By specifying the name of an unwinder (option '-name').

	If you give no options to the command, GDB assumes the input is an
	unwinder class. '-class' would make no difference if used, is just here
	for completeness.

	This command is meant to be used once the inferior is already at the
	desired location for the test. An example session would be:

	(gdb) start
	Temporary breakpoint 1, main () at omp.c:17
	17          func();
	(gdb) maint frame-unwinder disable ARCH
	(gdb) bt
	\#0  main () at omp.c:17
	(gdb) maint frame-unwinder enable ARCH
	(gdb) cont
	Continuing.

	This commit is a more generic version of commit 3c3bb0580be0,
	and so, based on the final paragraph of the commit message:
	    gdb: Add switch to disable DWARF stack unwinders
	<...>
	    If in the future we find ourselves adding more switches to disable
	    different unwinders, then we should probably move to a more generic
	    solution, and remove this patch.
	this patch also reverts 3c3bb0580be0

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434
	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

	temp adding completion

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Migrate frame unwinders to use C++ classes
	Frame unwinders have historically been a structure populated with
	callback pointers, so that architectures (or other specific unwinders)
	could install their own way to handle the inferior. However, since
	moving to C++, we could use polymorphism to get the same functionality
	in a more readable way. Polymorphism also makes it simpler to add new
	functionality to all frame unwinders, since all that's required is
	adding it to the base class.

	As part of the changes to add support to disabling frame unwinders,
	this commit makes the first baby step in  using polymorphism for the
	frame unwinders, by making frame_unwind a virtual class, and adds a
	couple of new classes. The main class added is frame_unwind_legacy,
	which works the same as the previous structs, using function pointers
	as callbacks. This class was added to allow the transition to happen
	piecemeal. New unwinders should instead follow the lead of the other
	classes implemented.

	2 of the others, frame_unwind_python and frame_unwind_trampoline, were added
	because it seemed simpler at the moment to do that instead of reworking
	the dynamic allocation to work with the legacy class, and can be used as
	an example to future implementations.

	Finally, the cygwin unwinder was converted to a class since it was most
	of the way there already.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb: add "unwinder class" to frame unwinders
	A future patch will add a way to disable certain unwinders based on
	different characteristics. This patch aims to make it more convenient
	to disable related unwinders in bulk, such as architecture specific
	ones, by identifying all unwinders by which part of the code adds it.
	The classes, and explanations, are as follows:

	* GDB: An internal unwinder, added by GDB core, such as the unwinder
	  for dummy frames;
	* EXTENSION: Unwinders added by extension languages;
	* DEBUGINFO: Unwinders installed by the debug info reader;
	* ARCH: Unwinders installed by the architecture specific code.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  Guinevere Larsen  <guinevere@redhat.com>

	gdb: make gdbarch store a vector of frame unwinders
	Before this commit, all frame unwinders would be stored in the obstack
	of a gdbarch and accessed by using the registry system. This made for
	unwieldy code, and unnecessarily complex logic in the frame_unwinder
	implementation, along with making frame_unwind structs be unable to have
	non-trivial destructors.

	Seeing as a future patch of this series wants to refactor the
	frame_unwind struct to use inheritance, and we'd like to not restrict
	the future derived classes on what destructors are allowed. In
	preparation for that change, this commit changes the registry in gdbarch
	to instead store an std::vector, which doesn't require using an obstack
	and doesn't rely on a linked list.

	There should be no user-visible changes.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-17  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Add CpuGMISM2 and CpuGMICCS
	There are separate CPUID feature bits for SM2 and CCS instructions.
	CCS is the acronym of Chinese Cipher System, it includes SM3 and SM4
	instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on
	corresponding instructions.

	gas/ChangeLog:

		* config/tc-i386.c: Add gmism2 and gmiccs to replace gmi.
		* doc/c-i386.texi: Ditto.

	opcodes/ChangeLog:

		* i386-gen.c: Add GMISM2 and GMICCS to replace GMI.
		* i386-opc.h (enum i386_cpu): Add  CpuGMISM2 and CpuGMICCS to
		  replace CpuGMI.
		* i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI
		  with GMICCS on sm3 and sm4 instructions.
		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2025-01-17  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Allocate GOT entry for TLS DESC when -mno-relax is enabled
	The type transition of TLSDESC is only done when -mrelax is enabled.
	So when -mno-relax is enabled, keep GOT_TLS_GDESC to allocate the
	GOT entry instead of just keeping GOT_TLS_IE.

2025-01-17  Nick Clifton  <nickc@redhat.com>

	Sync config.guess and config.sub with latest versions from the config project.

2025-01-17  Jan Beulich  <jbeulich@suse.com>

	x86/APX: convert runtime special case to build-time one
	cpu_flags_match() is a hot path. Move the special casing that
	b7267244a355 ("Support Intel AMX-MOVRS") added there to i386-gen, thus
	affecting only build time performance.

	x86: have .insn correctly consider AVX10.2's 256-bit embedded rounding
	Deriving operand size may no longer assume 512-bit vector size when
	embedded rounding is in use. In fact it was apparently wrong to do so
	in the first place, as that's not correct for scalar insns. Drop the
	rounding type check altogether; we fall back to EVEX.LIG when no
	suitable operand was specified anyway, later in the function (and, btw,
	similarly for VEX encodings).

2025-01-17  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR32499, Fix PR18841 segfault caused by ifunc relocation ordering
	Even though the relocation isn't IRELATIVE, it still should be come last if
	refering to ifunc symbol.  In order to get the ifunc relocs properly sorted
	the correct class needs to be returned.  The code mimics what has been done
	for x86, sparc, aarch64 and arm32.

	bfd/
		PR 18841
		PR 32499
		* elfnn-riscv.c (riscv_reloc_type_class): Handle ifunc relocation
		ordering, even though it's not IRELATIVE, it still should be come
		last if refering ifunc symbol.

2025-01-17  Alan Modra  <amodra@gmail.com>

	cmdline_add_object_only_section leak
	Free ofilename on error path.  Don't bother testing "if (foo)" before
	"free (foo)".

2025-01-17  Alan Modra  <amodra@gmail.com>

	buffer overflow in cmdline_add_object_only_section
	Seen running ld-plugin/lto-4r-c on x86_64-w64-mingw32

		* ldlang.c (cmdline_add_object_only_section): Allocate one more
		for output symbol buffer.

2025-01-17  Alan Modra  <amodra@gmail.com>

	Silence asan warnings in resolve_symbol_value
	The ".quad with division (fwdref)" gas test fails with asan warning
	negation of -9223372036854775808 cannot be represented in type 'long int'
	Fix this and another similar case.

		* symbols.c (resolve_symbol_value): Cast "left" to valueT
		before negating.

2025-01-17  H.J. Lu  <hjl.tools@gmail.com>

	ld: Load the object only section when opening the mixed object file
	Load the object only section when opening the mixed object file, instead
	of loading it after all other input files have been loaded. This fixed

	.../ld/collect-ld: /tmp/ccZAoUIW.obj-only.o: in function `main':
	.../ld/testsuite/ld-plugin/lto-10a.c:4: multiple definition of `main'; /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0x0): first defined here
	.../ld/collect-ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0xc5): undefined reference to `WinMain'
	collect2: error: ld returned 1 exit status
	...
	FAIL: LTO 10

	for x86_64-w64-mingw32 so that mixing LTO and non-LTO relocatable files
	for "ld -r" works for both ELF and non-ELF platforms.

		* ld.texi: Remove "On ELF platforms" from documentation of mixing
		LTO and non-LTO relocatable files for "ld -r".
		* ldlang.c (cmdline_load_object_only_section): New.
		(cmdline_check_object_only_section): Call it.
		* testsuite/ld-plugin/lto.exp: Enable mixed LTO and non-LTO
		relocatable output tests for all.

2025-01-17  Alan Modra  <amodra@gmail.com>

	buffer overflow in score_elf_create_dynamic_relocation
	score_elf_create_dynamic_relocation sets up three output dynamic
	relocs from rel[0], rel[1] and rel[2].  When rel[0] is the last reloc
	in a section this of course results in a buffer overflow.  It's a
	weird thing to do given that only one relocation is output.

		* elf32-score.c (score_elf_create_dynamic_relocation): Do not
		set up three dynamic relocations when only one is output.
		* elf32-score7.c: Likewise.

2025-01-17  Alan Modra  <amodra@gmail.com>

	buffer overflow in mmix_elf_relocate_section
		* elf64-mmix.c (mmix_elf_relocate_section): Correct size of
		relocs shuffled by memmove.

2025-01-17  Alan Modra  <amodra@gmail.com>

	xtensa unnecessary free
	No path to "cleanup" label has internal_relocs malloc'd.

		* emultempl/xtensaelf.em (replace_insn_sec_with_prop_sec): Don't
		free internal_relocs in cleanup.

2025-01-17  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Added lost zcmt in gas imply testcase.

	gas/NEWS: Updated risc-v assembler support in 2.44.

2025-01-17  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Use t2 for tail if Zicfilp enabled
	This change is to make tail conform with software guarded jump of Zicfilp. The
	reason to not choose t1 as the label register is that t1 is also as .got.plt
	offset of _dl_runtime_resolve in PLT.

	See more: https://github.com/riscv-non-isa/riscv-asm-manual/pull/93

2025-01-17  Monk Chiang  <monk.chiang@sifive.com>

	RISC-V: Support CFI Zicfiss and Zicfilp instructions and CSR.
	https://github.com/riscv/riscv-cfi/releases/tag/v1.0

	This patch only support the CFI instructions and CSR in assembler.

2025-01-17  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Support ssctr/smctr extensions with version 1.0.
	https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0

	The privileged spec v1.10 already removed the sfence.vm instruction, and the
	encoding of sfence.vm instruction is overlapped with the sctrclr instruction
	of ssctr/smctr.  But since the privileged spec v1.10 already removed the
	sfence.vm, and we no longer support the privileged spec v1.9.1 for now, we
	had to remove the sfence.vm.

	bfd/
		* elfxx-riscv.c (riscv_implicit_subsets): Imply zicsr for ssctr/smctr.
		(riscv_supported_std_s_ext): Added ssctr/smctr with version 1.0.
		(riscv_multi_subset_supports): Handle INSN_CLASS for ssctr/smctr.
		(riscv_multi_subset_supports_ext): Likewise.
	gas/
		* config/tc-riscv.c (enum riscv_csr_class, riscv_csr_address):
		Added and handle CSR_CLASS_SSCTR and CSR_CLASS_SMCTR.
		(riscv_is_priv_insn): Removed SFENCE_VM check.
		* testsuite/gas/riscv/attribute-14e.d: Removed since sfence.vm is no
		longer supported since privileged spec v1.10.
		* testsuite/gas/riscv/attribute-14.s: Likewise.
		* testsuite/gas/riscv/csr-version-1p10.d: Updated for ssctr/smctr CSRs.
		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
		* testsuite/gas/riscv/csr.s: Likewise.
		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
		* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
		* testsuite/gas/riscv/march-help.l: Updated for ssctr/smctr.
		* testsuite/gas/riscv/smctr-ssctr.d: New testcase for sctr instruction.
		* testsuite/gas/riscv/smctr-ssctr.s: Likewise.
	include/
		* opcode/riscv-opc.h: Added encoding macro for sctrclr, but removed
		encoding macro for sfence.vm since encoding conflict.  Added CSR
		numbers for ssctr/smctr CSRs.
		* opcode/riscv.h (enum riscv_insn_class): Added
		INSN_CLASS_SMCTR_OR_SSCTR for sctrclr.
	opcodes/
		* riscv-opc.c (riscv_opcodes): Added sctrclr, but removed sfence.vm
		since encoding conflict.

2025-01-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: don't check Elf when file is in archive
	map.xml contains a checksum for all Elf files.
	gprofng-archive archives a file only with the same checksum.
	In gprofng-display-text no additional check is required.

	gprofng/ChangeLog
	2025-01-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/parse.cc: Don't check Elf when file is in archive.

2025-01-17  Alan Modra  <amodra@gmail.com>

	Re: ld parser buffer leak
	Apparently reflex doesn't have yyalloc.

		* ldlex.l (yy_create_string_buffer): Revert last change.

2025-01-17  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Ignore rounding for vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd instead of reporting bad for disassembler
	According to SDM, vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd treat
	Rounding as Ignored when trying to using them. Thus, disassembler
	should accept bytecode with rounding instead of reporting bad.

	For assembler, it needs some more time to decide how to deal
	with that.

	gas/ChangeLog:

		* testsuite/gas/i386/evex.d: Add new testcase for vcvt[,u]dq2pd.
		Change the output for vcvt[,u]si2sd.
		* testsuite/gas/i386/evex.s: Ditto.
		* testsuite/gas/i386/x86-64-evex.d: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-w.h: Add EXxEVexR64 for vcvt[,u]dq2pd.
		* i386-dis.c (OP_Rounding): Mark EVEX_b as used to change the handle
		for ignored rounding.

2025-01-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-16  Alan Modra  <amodra@gmail.com>

	plugin_get_ir_dummy_bfd leak
		* plugin.c (plugin_get_ir_dummy_bfd): Free bfd filename.

	ld parser buffer leak
		* ldlex.l (<<EOF>>): yy_delete_buffer current.
		(yy_create_string_buffer): Use yyalloc.

2025-01-16  Alan Modra  <amodra@gmail.com>

	write_build_id and write_package_metadata leaks
	There isn't much sense in stashing contents in sec->contents
	after those contents have been written.

		* ldelf.c (write_build_id): Don't assign sec->contents.
		Free contents if malloc'd here.
		(write_package_metadata): Likewise.

2025-01-16  Alan Modra  <amodra@gmail.com>

	ldelf_search_needed leak
		* ldelf.c (ldelf_search_needed): Free filename before returning.

	free ldfile search paths
		* ldfile.c (ldfile_remap_input_free): Make static, call from..
		(ldfile_free): ..here.  New function.
		(ldfile_library_path_free, ldfile_script_free),
		( ldfile_arch_free): New functions.
		(ldfile_find_command_file): Free script_dir.  Move
		script_search to file scope.
		(ldfile_open_command_file_1): Delete FIXME comment.
		* ldfile.h (ldfile_remap_input_free): Delete.
		(ldfile_free): Declare.
		* ldlang.c (lang_finish): Update.

2025-01-16  Alan Modra  <amodra@gmail.com>

	output_section_statement leak
	This frees output_section_statement data, which is currently only used
	by elf targets but doing so for all targets is simpler and more
	future proof than adding ths to ldelf_finish.  (Doing it there
	requires moving the function to ldelfgen.c.)

		* ldemul.c (finish_default): Free os->data.

2025-01-16  H.J. Lu  <hjl.tools@gmail.com>

	NEWS: Mention mixed LTO and non-LTO output support for ld -r

2025-01-16  Nick Clifton  <nickc@redhat.com>

	Copy gcc commit e76df3586417d645dd84e8a1ab165605a8924796  to sourceware

	Have readelf sanitize the program interpreter string before displaying it.

2025-01-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/implptr.exp regression
	When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we
	get:
	...
	(gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar
	break implptr.c:34^M
	No compiled code for line 34 in file "implptr.c".^M
	Make breakpoint pending on future shared library load? (y or [n]) n^M
	(gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt)
	...

	This is a regression since commit dcaa85e58c4 ("gdb: reject inserting
	breakpoints between functions").

	The .debug_line info does not contain an entry with a line number lower than
	36, so gdb cannot map it to an address.

	Fix this by setting a breakpoint at the function containing line 34 instead.

	Tested on x86_64-linux.

	PR testsuite/32477
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477

2025-01-16  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Support x86 Zhaoxin PadLock PHE2 instructions
	The CPUID EDX bit[26] indicates its enablement, and it includes REP
	XSHA384 and REP XSHA512.

	gas/ChangeLog:

		* NEWS: Support Zhaoxin PadLock PHE2 instructions.
		* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
		PadLockPHE2 instructions.
		(output_insn): Handle PadLockPHE2 instructions.
		* doc/c-i386.texi: Document PadLockPHE2.
		* testsuite/gas/i386/i386.exp: Add PadLockPHE2 test.
		* testsuite/gas/i386/padlock_phe2.d: Ditto.
		* testsuite/gas/i386/padlock_phe2.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: Add PadLockPHE2.
		* i386-gen.c: Ditto
		* i386-opc.h (CpuPadLockPHE2): New.
		* i386-opc.tbl: Add Zhaoxin PadLock PHE2 instructions.
		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2025-01-16  Alan Modra  <amodra@gmail.com>

	disassemble_free_powerpc
	This fixes leaks in a ppc disassembler buffer.  I'm not sure now why I
	used a private buffer for section contents, but I'm not going to
	change that just now.

		* disassemble.h (disassemble_free_powerpc): Declare.
		* disassemble.c (disassemble_free_target): Call it.
		* ppc-dis.c (disassemble_free_powerpc): New function.

2025-01-16  Alan Modra  <amodra@gmail.com>

	ppc plt sym memory leak
		* elf32-ppc.c (add_stub_sym): Alloc the sym name.

	gas ppc .machine leak
		* config/tc-ppc.c (ppc_machine): Free cpu_string.

2025-01-16  Alan Modra  <amodra@gmail.com>

	elf64-ppc.c memory leaks
	I've freed htab->relr in two places, first when we're done with it
	in ppc64_elf_build_stubs, and also when freeing the hasn table to
	catch cases where the linker exits early due to errors.

		* elf64-ppc.c (ppc64_elf_link_hash_table_free): Free htab->relr.
		(ppc64_elf_build_stubs): Also free it here.
		(ppc_add_stub): Copy stub_name when creating..
		(ppc64_elf_size_stubs): ..and always free stub_name.
		(opd_entry_value): Free sym.
		(ppc_build_one_stub): bfd_alloc stub sym name.
		(build_global_entry_stubs_and_plt): Likewise.
		(ppc64_elf_setup_section_lists): bfd_zalloc htab->sec_info.

2025-01-16  Alan Modra  <amodra@gmail.com>

	gas HANDLE_ALIGN and frag_alloc
	This adds the section to HANDLE_ALIGN args, so that the frag created
	by the ppc backend can be properly allocated on the frag obstack.
	I've added an extra param to frag_alloc too, for cases where we know
	the frag requires at least some bytes in fr_literal.  This simplifies
	some existing code, for example in compress_debug and relax_segment.
	In the case of the relax_segment code, I think we may have had a bug
	there in using obstack_blank_fast, which doesn't check that the frag
	has room.

		* config/tc-ppc.c (ppc_handle_align): Add section param,
		use frag obstack to allocate frag.
		* config/tc-ppc.h (HANDLE_ALIGN, ppc_handle_align): Add extra
		param.
		* config/tc-aarch64.h (HANDLE_ALIGN): Add extra param.
		* config/tc-alpha.h: Likewise.
		* config/tc-arc.h: Likewise.
		* config/tc-arm.h: Likewise.
		* config/tc-avr.h: Likewise.
		* config/tc-epiphany.h: Likewise.
		* config/tc-frv.h: Likewise.
		* config/tc-i386.h: Likewise.
		* config/tc-ia64.h: Likewise.
		* config/tc-kvx.h: Likewise.
		* config/tc-loongarch.h: Likewise.
		* config/tc-m32c.h: Likewise.
		* config/tc-m32r.h: Likewise.
		* config/tc-metag.h: Likewise.
		* config/tc-mips.h: Likewise.
		* config/tc-mn10300.h: Likewise.
		* config/tc-nds32.h: Likewise.
		* config/tc-riscv.h: Likewise.
		* config/tc-rl78.h: Likewise.
		* config/tc-rx.h: Likewise.
		* config/tc-sh.h: Likewise.
		* config/tc-sparc.h: Likewise.
		* config/tc-spu.h: Likewise.
		* config/tc-tilegx.h: Likewise.
		* config/tc-tilepro.h: Likewise.
		* config/tc-v850.h: Likewise.
		* config/tc-visium.h: Likewise.
		* config/tc-wasm32.h: Likewise.
		* config/tc-xtensa.h: Likewise.
		* frags.h (frag_alloc): Update prototype.
		* frags.c (frag_alloc): Add extra size param, allocate extra.
		(frag_new): Update.
		* subsegs.c (subseg_set_rest): Update frag_alloc call.
		* write.c: Formatting.
		(cvt_frag_to_fill): Pass sec to HANDLE_ALIGN.
		(compress_frag): Update frag_alloc call.
		(compress_debug): Use new frag_alloc to simplify frag sizing.
		(relax_segment): Likewise.

2025-01-16  Alan Modra  <amodra@gmail.com>

	binary outsymbols
	This fixes leaks of outsymbols for various targets that use the
	generic linker.  The key fix here is to not generate output symbols
	for targets that won't ever write symbols, and of course to free
	outsymbols after they've been written in targets that do.  Target
	vector object_flags and section_flags are updated to better reflect
	target capabilities, in particular not setting HAS_SYMS or SEC_RELOC
	when the target does not support symbols or relocs.

		* binary.c (binary_vec): Update section_flags.
		* linker.c (generic_add_output_symbol): Don't add to
		outsymbols if !HAS_SYMS.
		* srec.c (srec_write_symbols): Free outsymbols on return.
		(srec_vec): Update object_flags and section_flags.
		(symbolsrec_vec): Likewise.
		* tekhex.c (tekhex_write_object_contents): Free outsymbols on
		return.
		(tekhex_vec): Update object_flags and section_flags.
		* verilog.c (verilog_vec): Likewise.

2025-01-16  Alan Modra  <amodra@gmail.com>

	tidy binary, ihex and verilog
		* binary.c (binary_sizeof_headers): Delete function.  Define
		instead.
		* ihex.c (ihex_sizeof_headers): Likewise.
		(ihex_vec): Use _bfd_nosymbols for BFD_JUMP_TABLE_SYMBOLS.  Delete
		now unused defines.
		* verilog.c: Delete unused defines.

2025-01-16  Alan Modra  <amodra@gmail.com>

	genlink tidy
	Some of the declarations in genlink.h are not used in current sources
	apart from needing them in linker.c, so delete and/or move them there.
	The patch also fixes a FIXME.  It's actually quite easy to return
	a failure from a hash traversal function.

		* genlink.h (_bfd_generic_link_hash_newfunc): Delete.
		(_bfd_generic_link_output_symbols),
		(generic_write_global_symbol_info),
		(_bfd_generic_link_write_global_symbol): Move to..
		* linker.c: ..here, making functions static.
		(generic_write_global_symbol_info): Add "failed".
		(_bfd_generic_final_link): Handle wginfo.failed.
		(_bfd_generic_link_write_global_symbol): Set wginfo->failed
		on memory failures and return false rather than aborting.

2025-01-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.exp
	Once in a while, I run into a timeout in test-case
	gdb.threads/step-over-thread-exit.exp:
	...
	(gdb) continue^M
	Continuing.^M
	[New Thread 0xfffff7cff1a0 (LWP 2874854)]^M
	^M
	Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \
	  my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M
	74      SYSCALL (my_exit, __NR_exit)^M
	(gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M
	FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \
	  schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout)
	...

	I can reproduce it more frequently by running with taskset -c <slow core id>.

	Fix this by using -no-prompt-anchor.

	This requires us to add -no-prompt-anchor to proc gdb_test_multiple.

	Tested on aarch64-linux.

	PR testsuite/32489
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489

2025-01-16  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Run black on gdb/gdbarch_components.py
	The sourceware buildbot reported "python black formatter ( failure )" at
	commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook").

	Fix this by running the precommit hooks in a container with Python 3.11 using:
	...
	$ pre-commit run --files gdb*/*
	...

2025-01-16  Sergio Durigan Junior  <sergiodj@sergiodj.net>

	gdbserver: Fix build on MIPS
	Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke
	the build on MIPS because it's passing a non-existent "pid" argument
	to "proc->for_each_thread".  This commit fixes the problem by removing
	the argument from the call.

2025-01-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-15  Alan Modra  <amodra@gmail.com>

	x86 relr memory leaks
	This fixes some x86 memory leaks.  I think it would be possible to
	free the relr data in _bfd_elf_x86_finish_relative_relocs if we
	wanted to reclaim some memory earlier, but for tidying after errors we
	likely would need to free in the hash_table_free function anyway.

	_bfd_x86_elf_link_relax_section is called via bfd_relax_section,
	ie. whenever relaxation is enabled.  This is a waste of time if
	dt_relr relocs are not enabled since the function is there only to
	handle relr.

		* elfxx-x86.c (elf_x86_link_hash_table_free): Free relr data.
		(_bfd_x86_elf_link_relax_section): Return early
		if !info->enable_dt_relr.  Do set "again" false before early
		returns.

2025-01-15  Alan Modra  <amodra@gmail.com>

	Tidy elf_mmap_section_contents
	It is simpler to clear the buffer pointer in the caller than pass
	a param that controls clearing.

		* elf.c (elf_mmap_section_contents): Remove final_link param.
		(_bfd_elf_mmap_section_contents): Instead set *buf to NULL here.
		(_bfd_elf_link_mmap_section_contents): Adjust.

2025-01-15  Alan Modra  <amodra@gmail.com>

	elf_x86_64_scan_relocs error paths
	Fix some memory leaks.

		* elf64-x86-64.c (elf_x86_64_scan_relocs): Ensure error return
		paths that should free relocs go via error_return.

2025-01-15  Martin Storsjö  <martin@martin.st>

	Add support for IMPORT_CONST in ILF (MSVC style) import libraries
	This is a very strange and obsolete kind of import type; it is
	used for imported data just like IMPORT_DATA - but with an extra
	odd caveat.

	The behaviour is explained at [1]; generating such import libraries
	with current MSVC tools produces "warning LNK4087: CONSTANT keyword is
	obsolete; use DATA".

	While obsolete, some import libraries within the Microsoft WDK (Windows
	Driver Kit) do contain such symbols, which currently are ignored by
	binutils and produce warnings about "file format not recognized".

	For IMPORT_CONST for a DLL exported symbol "foo", we should provide
	the import library symbols "__imp_foo" and "foo". For IMPORT_DATA, we
	only provide "__imp_foo", and for IMPORT_CODE, "foo" points at a thunk.
	The odd/surprising thing for IMPORT_CONST is that the "foo" symbol also
	points at the same thing as "__imp_foo", i.e. directly at the IAT
	entry.

	[1] https://learn.microsoft.com/en-us/cpp/build/importing-using-def-files

2025-01-15  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: GCS tests for linking issues with dynamic objects

2025-01-15  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: check GCS feature in GNU properties of input dynamic objects
	The Guarded Control Stack (GCS) feature requires that two things:
	- at static link time, all the input objects of a link unit have to
	  be compatible with GCS.
	- at runtime, the executable and the shared libraries which it
	  depends on have to be compatible with GCS.
	Both of those criteria are checked with the GCS feature stored in
	the GNU property note.

	The previous patch, adding support for the GCS feature check in GNU
	note properties for input objects, ignored the input dynamic objects.
	Although this support was better than no check, it was still
	delaying the detection of compatibility issues up to the runtime
	linker.

	In order to help the developer in detecting such an incompatibility
	issue as early as possible, this patch adds a check for input dynamic
	objects lacking the GCS marking. This check can be controlled via the
	linker option '-z gcs-report-dynamic[=none|warning|error]'. By default,
	if the option is omitted, it inherits the value from '-z gcs-report'.
	However, the inherited value is capped to 'warning' as a user might
	want to only report errors in the currently built module, and not the
	shared dependencies. If a user also wants to error on GCS issues in
	the shared libraries, '-z gcs-report-dynamic=error' will have to be
	specified explicitly.

2025-01-15  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: boolify the 'in_g_packet' field of remote's 'packet_reg'
	Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in
	remote.c.

2025-01-15  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove an obsolete comment in tracepoint.cc
	The comment

	  /* Functions local to this file.  */

	has somehow been positioned above struct definitions, not functions.
	Some static function declarations are given after the structs, to
	where the comment could be moved, but the comment is not really
	helpful.  Therefore remove it.

2025-01-15  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove forward declaration of struct tracepoint_hit_ctx
	Remove the unnecessary forward declaration for `struct tracepoint_hit_ctx`.

2025-01-15  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.base/store.exp on s390x
	On s390x-linux, I get:
	...
	(gdb) print l^M
	$29 = 0^M
	(gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1
	...

	So, we're in wack_doublest trying to print l, which is a copy of parameter u:
	...
	  register doublest l = u, r = v;
	...
	which does have the expected value:
	...
	(gdb) p u
	$1 = -1
	...
	which is a long double, 16 bytes and looks like this:
	...
	(gdb) p /x u
	$3 = 0xbfff0000000000000000000000000000
	...

	Parameter u is passed in two registers:
	...
	 <2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter)
	    <6a6>   DW_AT_name        : v
	    <69e>   DW_AT_location    : 6 byte block: 50 93 8 51 93 8 \
	      (DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8)
	...
	and indeed we find the msw in r0 and the lsw in r1:
	...
	(gdb) p /x $r0
	$4 = 0xbfff000000000000
	(gdb) p /x $r1
	$5 = 0x0
	(gdb)
	...

	Likewise, variable l consists of two registers:
	...
	 <2><6b5>: Abbrev Number: 13 (DW_TAG_variable)
	    <6b6>   DW_AT_name        : l
	    <6be>   DW_AT_location    : 6 byte block: 68 93 8 69 93 8 \
	      (DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8)
	...
	and we find the same values there:
	...
	(gdb) p /x $f8
	$6 = 0xbfff000000000000
	(gdb) p /x $f10
	$7 = 0x0
	...

	So, we get the expected results when fetching the value from two gprs, but not
	when fetching the value from two fprs.

	When fetching the values from the two fprs, we stumble upon a particularity of
	the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24
	maps to both floating-point register f8 (8 bytes), and vector register v8
	(16 bytes).

	In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and
	if available vector registers are preferred over floating-point registers, so
	v8 is chosen, and used to fetch the value.

	Since the size of the DW_OP_piece is 8 bytes, and the register size is 16
	bytes, this bit in rw_pieced_value is activated:
	...
			    /* If the piece is located in a register, but does not
			       occupy the entire register, the placement of the piece
			       within that register is defined by the ABI. */
			    bits_to_skip
			      += 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum,
								      p->size / 8);
	...
	but since the default implemention default_dwarf2_reg_piece_offset does not
	match the s390x ABI, we get the wrong answer.

	This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other
	DWARF Location Woes" [2].

	Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same
	logic as in s390_value_from_register.

	Tested on s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://github.com/IBM/s390x-abi
	[2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces

2025-01-15  Tom de Vries  <tdevries@suse.de>

	[gdb] Add gdbarch_dwarf2_reg_piece_offset hook
	In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and
	DW_OP_bit_piece are handled the same, but the standard tells us:
	- DW_OP_piece: if the piece is located in a register, but does not occupy the
	  entire register, the placement of the piece within that register is defined
	  by the ABI.
	- DW_OP_bit_piece: if the location is a register, the offset is from the least
	  significant bit end of the register.

	Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the
	ABI-specific behaviour for DW_OP_piece.

	The default implementation of the hook is the behaviour of DW_OP_bit_piece, so
	there should not be any functional changes.

	Tested on s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-15  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Add dwarf_expr_piece.op
	Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of
	which dwarf_location_atom caused a dwarf_expr_piece to be added.

	This is used in the following patch.

	Tested on s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-15  Tom Tromey  <tromey@adacore.com>

	Fix help formatting for string and filename options
	I happened to notice that "help add-inferior" said:

	  -execFILENAME
	    FILENAME is the file name of the executable to use as the
	    main program.

	This is missing a space after "-exec".  This patch fixes the bug.

	If ok'd on time I plan to check this in to the gdb-16 branch as well.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2025-01-15  Hui Li  <lihui@loongson.cn>

	gdbserver: LoongArch: Add hardware watchpoint/breakpoint support
	LoongArch defines hardware watchpoint functions for fetch and load/store
	operations, the related support for gdb was added in the following two

	  commit c1cdee0e2c17 ("gdb: LoongArch: Add support for hardware watchpoint")
	  commit 6ced1278fc00 ("gdb: LoongArch: Add support for hardware breakpoint")

	Now, add hardware watchpoint and breakpoint support for gdbserver on
	LoongArch.

	Here is a simple example

	$ cat test.c
	  #include <stdio.h>
	  int a = 0;
	  int b = 0;
	  int main()
	  {
	    printf("start test\n");
	    a = 1;
	    printf("a = %d\n", a);
	    a = 2;
	    printf("a = %d\n", a);
	    b = 2;
	    printf("b = %d\n", b);
	    return 0;
	  }
	$ gcc -g test.c -o test

	Execute on the target machine:

	$ gdbserver 192.168.1.100:1234 ./test

	Execute on the host machine:

	$ gdb ./test
	...
	(gdb) target remote 192.168.1.100:1234
	...
	(gdb) b main
	Breakpoint 1 at 0x1200006b8: file test.c, line 6.
	(gdb) c
	Continuing.
	...
	Breakpoint 1, main () at test.c:6
	6	    printf("start test\n");
	(gdb) watch a
	Hardware watchpoint 2: a
	(gdb) hbreak 11
	Hardware assisted breakpoint 3 at 0x120000700: file test.c, line 11.
	(gdb) c
	Continuing.

	Hardware watchpoint 2: a

	Old value = 0
	New value = 1
	main () at test.c:8
	8	    printf("a = %d\n", a);
	(gdb) c
	Continuing.

	Hardware watchpoint 2: a

	Old value = 1
	New value = 2
	main () at test.c:10
	10	    printf("a = %d\n", a);
	(gdb) c
	Continuing.

	Breakpoint 3, main () at test.c:11
	11	    b = 2;
	(gdb) c
	Continuing.
	[Inferior 1 (process 696656) exited normally]

	Output on the target machine:

	Process ./test created; pid = 696708
	Listening on port 1234
	Remote debugging from host 192.168.1.200, port 60742
	start test
	a = 1
	a = 2
	b = 2

	Child exited with status 0

2025-01-15  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Adjust loongarch_stopped_data_address()
	loongarch_stopped_data_address() is a common function and will be used by
	gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c
	to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver
	patch on LoongArch and is no effect for the current code.

	gdb: LoongArch: Adjust loongarch_{get,remove}_debug_reg_state()
	loongarch_{get,remove}_debug_reg_state() are used as helper functions
	by loongarch_linux_nat_target. We should move their definitions from
	gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c.

	gdb: LoongArch: Remove loongarch_lookup_debug_reg_state()
	loongarch_lookup_debug_reg_state() is a unused function, so we
	can remove it.

2025-01-15  H.J. Lu  <hjl.tools@gmail.com>

	ld: Update gld${EMULATION_NAME}_place_orphan for PE/PEP
	Similar to ldelf_place_orphan, initialize hold from orig_hold at run-time
	in PE and PEP gld${EMULATION_NAME}_place_orphan.

		* emultempl/pe.em (orphan_init_done): Make it file scope.
		(gld${EMULATION_NAME}_finish): Set orphan_init_done to false for
		the object-only output.
		(gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold.
		Initialize hold from orig_hold at run-time.
		* emultempl/pep.em (orphan_init_done): Make it file scope.
		(gld${EMULATION_NAME}_finish): Set orphan_init_done to false for
		the object-only output.
		(gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold.
		Initialize hold from orig_hold at run-time.

2025-01-15  H.J. Lu  <hjl.tools@gmail.com>

	ld: Correct ldelf_place_orphan
	Remove the extra for loop and if statement in ldelf_place_orphan.

		* ldelf.c (ldelf_place_orphan): Remove the extra for loop and if
		statement.

2025-01-15  Jan Vrany  <jan.vrany@labware.com>

	gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require also avx2
	The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX
	instructions but it actually also uses AVX2 instructions (like
	vpcmpeqd). This caused the test to fail on CPUs that have AVX but not
	AVX2.

	This commit adds check for AVX2.

	Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U
	(has AVX2).

2025-01-15  Alan Modra  <amodra@gmail.com>

	bfd_get_unique_section_name leak
	The name returned by this function is used in asection->name, so
	needs to persist until a bfd is closed.

		* section.c (bfd_get_unique_section_name): Return an alloc'd
		string.

2025-01-15  Alan Modra  <amodra@gmail.com>

	Free symtab_hdr.contents and a cache_size correction
	symtab_hdr.contents looks to be malloc'd memory, except in one case.
	Change that one case to also be malloc'd and free when we are done.

		* elf.c (swap_out_syms): bfd_malloc outbound_syms.
		(_bfd_elf_free_cached_info): Free symtab_hdr.contents.
		* elflink.c (init_reloc_cookie): Correct cache_size.  locsyms
		is an array of Elf_Internal_Sym.

2025-01-15  Alan Modra  <amodra@gmail.com>

	elflink.c memory leaks
	Many targets leaked parts of the elf_link_hash_table.  Fix that by
	making _bfd_elf_link_hash_table_init set up hash_table_free correctly,
	so that targets that extend elf_link_hash_table without adding
	anything that needs freeing, will use _bfd_elf_link_hash_table_free.

		* elflink.c (elf_link_add_object_symbols): Always free
		nondeflt_vers.  Don't return false without freeing.
		(_bfd_elf_link_hash_table_init): Set hash_table_free here..
		(_bfd_elf_link_hash_table_create): ..rather than here.
		(elf_link_swap_symbols_out): Don't free strtab here..
		(elf_link_add_object_symbols): ..do so here instead.  Don't
		omit freeing on some error return paths.

2025-01-15  Alan Modra  <amodra@gmail.com>

	sframe memory leak
	This is another case where an array isn't freed anywhere and needs to
	persist a while, so allocate it with bfd_alloc.

		* elf-sframe.c (sframe_decoder_init_func_bfdinfo): Add abfd
		param.  bfd_zalloc std_func_bfdinfo.
		(_bfd_elf_parse_sframe): Adjust to suit.

2025-01-15  Alan Modra  <amodra@gmail.com>

	eh-frame memory leaks
	The set_loc array attached to eh-frame sec_info isn't freed, and is
	used in _bfd_elf_eh_frame_section_offset.  Rather than finding a
	suitable late stage of linking past any b_e_e_f_s_o use, I decided
	this might as well persist until the bfd is closed.
	Some memory is freed in _bfd_elf_discard_section_eh_frame_hdr, but
	the function isn't always called, so fix that too.

		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc the
		set_loc array.
		(find_merged_cie): Use bfd_malloc rather than malloc.
		(_bfd_elf_discard_section_eh_frame_hdr): Move condition under
		which this function does anything except free memory from..
		* elflink.c (bfd_elf_discard_info): ..here.

2025-01-15  Alan Modra  <amodra@gmail.com>

	Fix known minor objdump leak
		* objdump.c (main): Free disassembler_options.

2025-01-15  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: convert program_args to a single string
	This commit changes how gdbserver stores the inferior arguments from
	being a vector of separate arguments into a single string with all of
	the arguments combined together.

	Making this change might feel a little strange; intuitively it feels
	like we would be better off storing the arguments as a vector, but
	this change is part of a larger series of work that aims to improve
	GDB's inferior argument handling.  The full series was posted here:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	But asking people to review a 14 patch series in unreasonable, so I'm
	instead posting the patches in smaller batches.  This patch can stand
	alone, and I do think this change makes sense on its own:

	First, GDB already stores the inferior arguments as a single string,
	so doing this moves gdbserver into line with GDB.  The common code
	into which gdbserver calls requires the arguments to be a single
	string, so currently each target's create_inferior implementation
	merged the arguments anyway, so all this commit really does is move
	the merging up the call stack, and store the merged result rather than
	storing the separate parts.

	However, the biggest reason for why this commit is needed, is an issue
	with passing arguments from GDB to gdbserver when starting a new
	inferior.

	Consider:

	  (gdb) set args $VAR
	  (gdb) run
	  ...

	When using a native target the inferior will see the value of $VAR
	expanded by the shell GDB uses to start the inferior.  However, if
	using an extended-remote target the inferior will see literally $VAR,
	the unexpanded name of the variable, the reason for this is that,
	although GDB sends '$VAR' to gdbserver, when gdbserver receives this,
	it converts this to '\$VAR', which prevents the variable from being
	expanded by the shell.

	The reason for this is that construct_inferior_arguments escapes all
	special shell characters within its arguments, and it is
	construct_inferior_arguments that is used to combine the separate
	arguments into a single string.

	In the future I will change construct_inferior_arguments so that
	it can apply different escaping strategies.  When this happens we will
	want to escape arguments coming from the gdbserver command line
	differently than arguments coming from GDB (via a vRun packet), which
	means we need to call construct_inferior_arguments earlier, at the
	point where we know if the arguments came from the gdbserver command
	line, or from the vRun packet.

	This argument escaping issue is discussed in PR gdb/28392.

	This commit doesn't fix any issues, nor does it change
	construct_inferior_arguments to actually do different escaping, that
	will all come later.  This is purely a restructuring.

	There should be no user visible changes after this commit.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392

	Tested-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-15  Alan Modra  <amodra@gmail.com>

	PR32560 stack-buffer-overflow at objdump disassemble_bytes
	There's always someone pushing the boundaries.

		PR 32560
		* objdump.c (MAX_INSN_WIDTH): Define.
		(insn_width): Make it an unsigned long.
		(disassemble_bytes): Use MAX_INSN_WIDTH to size buffer.
		(main <OPTION_INSN_WIDTH>): Restrict size of insn_width.

2025-01-15  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Require current language before symbol lookups
	Test-case gdb.python/py-symbol.exp fails with various target boards, including
	fission and gold-gdb-index.

	The problem here is that, in this test, the current language is still
	unset (i.e., lazy) when the symbol lookup is done.  It is eventually
	set deep in the lookup -- but this then requires a reentrant symbol
	lookup, which fails.  (DWARF symbol lookup is not reentrant.)

	Fix this by:
	- detecting symbol lookup reentrance using an assert, and
	- requiring the current language to be set when entering symbol lookup.

	Tested on x86_64-linux.

	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/32490
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490

2025-01-15  Alan Modra  <amodra@gmail.com>

	Re: elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property
	Don't run tests on targets without required support.  Supply an
	explicit -z nomemory-seal rather then relying on the harness default,
	to lessen confusion for people looking at the test.  Don't use numeric
	labels for the sake of hppa64*-hpux, and run the tests there.  Remove
	incorrect comment about source editing.  Also, xfail rather than
	notarget failing tests with a list of target triples so we check that
	the list is correct.

	Re: ld: Add --enable-memory-seal configure option
	Commit 80dc29527ff9 accidentally removed an assignment to board_flags,
	resulting in tcl errors 'can't read "board_flags": no such variable'
	on sh4-linux-gnu.  Fix that by calling [get_board_flags] in the
	condition rather than reinstating the removed line since it seems most
	configurations don't have a null STATIC_LDFLAGS.  Do the same in
	another similar test too.

2025-01-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-14  Tom Tromey  <tom@tromey.com>

	Use bool in decode_line_2_item
	This changes decode_line_2_item::selected to bool.  There was no
	benefit to keeping this as a bitfield, so I removed that.  Note that
	the constructor already uses bool here.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tom Tromey  <tom@tromey.com>

	Use bool for parameter of add_sal_to_sals
	This changes add_sal_to_sals to use 'bool' rather than 'int'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tom Tromey  <tom@tromey.com>

	Use filename style in "show" commands
	I found a few filename-related "show" commands that do not use the
	filename style when displaying the file.  This patch fixes the
	oversight.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Parse linker script only once
	Parsing linker script twice caused

	FAIL: ld-plugin/lto-3r
	FAIL: ld-plugin/lto-5r
	FAIL: PR ld/19317 (2)

	for x86_64-w64-mingw32 with the linker error:

	./ld-new:built in linker script:27 assignment to location counter invalid outside of SECTIONS

	ldscripts/i386pep.xr has

	 24   .rdata  :
	 25   {
	 26     *(.rdata)
	 27     . = ALIGN(4);
	 28     /* .ctors & .dtors */
	 29     /* .CRT */
	 30     /* ___crt_xl_end__ is defined in the TLS Directory support code */
	 31   }

	Remove ld_parse_linker_script to parse linker script only once.

		* ldlang.c (cmdline_emit_object_only_section): Don't call
		ld_parse_linker_script.
		* ldmain.c (main): Fold ld_parse_linker_script.
		(ld_parse_linker_script): Removed.

2025-01-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Call cmdline_check_object_only_section only if plugin is enabled
		* ldmain.c (add_archive_element): Call
		cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS
		is defined.

2025-01-14  Yang Liu  <liuyang22@iscas.ac.cn>

	gdb/jit: fix jit-reader linetable integrity
	The custom linetable functionality in GDB's JIT Interface has been broken
	since commit 1acc9dca423f78e44553928f0de839b618c13766.

	In that commit, linetables were made independent from the objfile, which
	requires objfile->section_offsets to be initialized. However, section_offsets
	were never initialized in objfiles generated by GDB's JIT Interface
	with custom jit-readers, leading to GDB crashes when stepping into JITed code
	blocks with the following command already executed:

	  jit-reader-load libmygdbjitreader.so

	This patch fixes the issue by initializing the minimum section_offsets required
	for linetable parsing procedures.

	A minimal test is included.  The test sets up some very simple line
	table information, which is enough to trigger the bug.  However, the
	line table information is crafted such that none of the line table
	entries will end up being displayed in GDB's output when the test is
	run, as such, none of the expected output actually changes.

	It might be nice in the future to extend some of the jit tests to
	actually test hitting line table entries added via the jit reader.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-14  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for AVX floating point arithmetic instructions
	This commit adds support for the following types of instructions
	relating to floating poitn values: add, mul, sub, min, div, max.
	These are supported with packed or single values, and single or double
	precision.

	Some of the instructions had opcode clashes, however, considering the
	mechanics of recording the registers is the same on both instructions,
	this is just marked with a comment.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-14  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for floating point vunpck instructions
	This commit adds support for the AVX instructions vunpck[l|h][ps|pd]
	instructions, which was pretty straightforward.

	This commit also fixes a mistake in the test, where "record stop" was
	used after the recording was already stopped, if it failed during
	vpunpck_test recording. It also improved the documentation at the start
	of the relevant .c function.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-14  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for floating point vmov instructions
	This commit updates GDB's record-full to be able to record vmov[ss|sd]
	and vmov [u|a] [ps|pd] AVX instructions, and tests for them.

	Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions
	of vmov?[ps|pd] have different opcodes. The mechanics of recording them
	is the same, but the aligned version has opcodes 0x28 and 0x29, while
	the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and
	0x11.

	Approved-By: Guinevere Larsen <guinevere@redhat.com>

2025-01-14  Sam James  <sam@gentoo.org>

	ld: regenerate
	80dc29527ff9b5179741c360418e77e5064f2b69 contained some changes from
	non-vanilla autoconf. Regenerate.

	ChangeLog:

		* config.in: Regenerate.
		* configure: Regenerate.

2025-01-14  Adhemerval Zanella  <adhemerval.zanella@linaro.org>

	ld: Add --enable-memory-seal configure option
	Add --enable-memory-seal linker configure option to enable memory
	sealing (GNU_PROPERTY_MEMORY_SEAL) by default.

	Change-Id: I4ce4ff33657f0f09b1ceb06210b6fcaa501f1799

2025-01-14  Adhemerval Zanella  <adhemerval.zanella@linaro.org>

	elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property
	The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries
	to be memory sealed by the loader, to avoid further changes of
	PT_LOAD segments (such as unmapping or change permission flags).
	This is done along with Linux kernel (the mseal syscall [1]), and
	C runtime supports to instruct the kernel on the correct time during
	program startup (for instance, after RELRO handling).  This support
	is added along the glibc support to handle the new gnu property [2].

	This is a opt-in security features, like other security hardening
	ones like NX-stack or RELRO.

	The new property is ignored if present on ET_REL objects, and only
	added on ET_EXEC/ET_DYN if the linker option is used.  A gnu property
	is used instead of DT_FLAGS_1 flag to allow memory sealing to work
	with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports
	still do no support static-pie).

	[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370
	[2] https://sourceware.org/pipermail/libc-alpha/2024-September/160291.html

	Change-Id: Id47fadabecd24be0e83cff45653f7ce9a900ecf4

2025-01-14  Ella MA  <xutong.ma@inria.fr>

	Fix a syntax error in sim/common/cgen-mem.h

2025-01-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Update mixed LTO and non-LTO relocatable output tests
	Since mixed LTO and non-LTO relocatable output is only supported on ELF
	platforms, limit these tests to ELF targets.  Since powerpc64 elfv1
	defines a function symbol on its procedure descriptor, which is in a
	data section, rather than on the code for that function, allow both D
	and T for nm test on mixed object.

		* testsuite/ld-plugin/lto.exp: Limits  mixed LTO and non-LTO
		relocatable output tests to ELF targets.  Allow both D and T for
		nm test on mixed object.

2025-01-14  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64 SFrame: skip with warning new CFI directive used with pauth_lr
	Today, SFrame v2 specification does not describe how to encode the
	information corresponding to the PAuth_LR PAC signing method (it only
	supports PAuth PAC signing method).
	SFrame v3 specification should hopefully specify it.

	In the meantime, if the GNU assembler finds .cfi_negate_ra_state_with_pc
	and --gsframe is specified, it will output a warning to the user and
	will fail to generate the FDE entry.

	A new SFrame test for .cfi_negate_ra_state_with_pc is also added to
	reflect this issue.

	Approved-by: Indu Bhagat <indu.bhagat@oracle.com>

2025-01-14  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64 DWARF: add new CFI directive for PAuth_LR
	This patch adds a new CFI directive (cfi_negate_ra_state_with_pc) which
	set an additional bit in the RA state to inform that RA was signed with
	SP but also PC as an additional diversifier.

	RA state | Description
	0b00     | Return address not signed (default if no cfi_negate_ra_state*)
	0b01     | Return address signed with SP (cfi_negate_ra_state)
	0b10     | Invalid state
	0b11     | Return address signed with SP+PC (cfi_negate_ra_state_with_pc)

	Approved-by: Indu Bhagat <indu.bhagat@oracle.com>
	Approved-by: Jan Beulich <jbeulich@suse.com>

2025-01-14  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64 SFrame: use preferred CFI directive for AArch64 PAC
	ARMv8.3 addded support for a new security feature named Pointer
	Authentication. Support for this feature in SFrame already exists.

	In GCC 14 and older, the Sparc DWARF extension .cfi_gnu_window_save
	is emitted instead of .cfi_negate_ra_state.
	GCC 15 fixed this issue, but this behavior is preserved for backward
	compatibility.

	The existing sframe test for AArch64 PAC was using .cfi_gnu_window_save.
	This patch replaces this CFI in the existing test by the preferred one,
	and adds a new test to check for backward compatibility when using
	.cfi_gnu_window_save.

	Approved-by: Indu Bhagat <indu.bhagat@oracle.com>

2025-01-14  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: make explicit that CFI gnu_window_save is for Sparc, not AArch64
	- add a detailed comment when parsing DW_CFA_GNU_window_save in SFrame to
	  explain why we are checking whether the targeted architecture is AArch64,
	  whereas this CFI is a Sparc extension.
	- replace .cfi_gnu_window_save by .cfi_negate_ra_state in existing AArch64
	  DWARF tests as this is the preferred directive since GCC 15.
	- add a new AArch64 test to check backward compatibility with old GCC
	  versions that emits .cfi_gnu_window_save.

	Approved-by: Indu Bhagat <indu.bhagat@oracle.com>
	Approved-by: Richard Earnshaw <richard.earnshaw@arm.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove handling of the 'L' tracepoint action
	Now that static tracepoint support is removed from gdbserver, it makes
	sense to remove handling of the 'L' tracepoint action, too.  The code
	that checks received actions already has a default case that tolerates
	unrecognized actions:

	        default:
	          trace_debug ("unknown trace action '%c', ignoring...", *act);

	In case 'L' is unexpectedly received, we would at least be able to see
	this in the logs.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove the static_tracepoint enum value
	As a continuation of the previous patches that remove UST from
	gdbserver, remove the `static_tracepoint` enum value from
	`tracepoint_type` and all the associated code.

	Now that the last use of `write_e_static_tracepoints_not_supported`
	is gone, also remove that function.

	The handling of the 'S' option, where the `static_tracepoint` enum
	value was being used, is removed completely, because recognizing that
	option makes sense only when static tracepoint support is announced.

	This patch is easier to view with "git show -w".

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: do not announce static tracepoint support
	Remove the announcement that `qXfer:statictrace:read` and
	`StaticTracepoints` are supported.  Associated to this, remove the
	handling of "qTfSTM", "qTsSTM", and "qTSTMat" packets and the
	qXfer:statictrace:read handling.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove UST (static tracepoint) support (part 2)
	With the removal of UST, the `in_process_agent_supports_ust` query
	would essentially always be false.  Remove the function and adjust
	the uses, comments, and warning/error messages.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove UST (static tracepoint) support (part 1)
	UST support in gdbserver is substantially outdated.  Simon says:

	  ...[having HAVE_UST defined] never happens nowadays because it used
	  a version of lttng-ust that has been deprecated for a loooong time
	  (the 0.x series).  So everything in HAVE_UST just bitrots.  It might
	  be possible to update all this code to use lttng-ust 2.x (1.x never
	  existed), but I don't think it's going to happen unless somebody
	  specifically asks for it.  I would suggest removing support for UST
	  from gdbserver.  ...If we ever want to resurrect the support for UST
	  and port to 2.x, we can get the code from the git history.

	This patch removes the support, mostly mechanically by deleting code
	guarded by `#ifdef HAVE_UST`.  After these removals, `struct
	static_tracepoint_ctx` becomes unused.  So, remove it, too.

	The following patches remove more code.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, doc: describe the 'L' tracepoint action
	I noticed that 'L' is a tracepoint action but it is not defined in the
	document.  Add the description.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-01-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, doc: mention the 'S' option for the QTDP packet
	I noticed that gdbserver accepts an 'S' option for the QTDP packet to
	create a static tracepoint, but this is not mentioned in the document.
	Update the document.

	I first thought about updating the argument as `[:Flen|:S]`, but then
	opted for `[:Flen][:S]`.  Although it is odd that ':F' and ':S' are
	allowed to co-exist, the implementation at the gdbserver side allows
	this and handles the packet arguments so that the right-most
	positioned ':F' or ':S' overwrites the final tracepoint type.  When
	the documentation is missing, the implementation usually determines
	the behavior.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-01-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Call cmdline_check_object_only_section only if plugin is enabled
		* ldfile.c (ldfile_try_open_bfd): Call
		cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS
		is defined.

2025-01-14  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Remove "NE" in mnemonics for convert insns related to AI data types
	NE is quite ambiguous and misleading in mnemonics since it should be
	Rounding to Nearest Even, but could be mis-interpretated to No
	Exception.

	Under its correct meaning, which means rounding, it should only be used
	in down-convert, since up-convert is always exact for normal values
	It could be difficult to judge which kind of convert it is if we have
	the convert between same bit float types.

	For all AI data types including BF16 and FP8, the default rounding is
	Rounding to Nearest Even. So removing them in mnemonics would reduce
	burden for programmers to consider whether it should be added or not
	in mnemonics and stop the ambiguous meaning on "NE" itself.

	If the convert itself is using a rounding mode other than RNE, it would
	be explicitly added in mnemonics (e.g., Long used "T" and "BIAS"
	introduced in AVX10.2).

	gas/ChangeLog:

		* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Refine testcases
		according to mnemonics change.
		* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-prefix.h: Remove ne in mnemonics for
		convert insns.
		* i386-opc.tbl: Ditto.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2025-01-14  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Rename VCOMSBF16 to VCOMISBF16
	The functionality for VCOMSBF16 is exactly the same as the VCOMISD/S/H.
	The only difference is the bf16 type. Thus, it should be VCOMISBF16.
	This patch would fix that.

	gas/ChangeLog:

		* testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase
		according to mnemonics change.
		* testsuite/gas/i386/avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-prefix.h: Rename VCOMSBF16 to VCOMISBF16.
		* i386-opc.tbl: Ditto.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2025-01-14  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Remove "P" and "NE" in mnemonics for BF16 arithmetic insns
	Since the bf16 is an AI data types, it will be implicitly packed. Thus,
	"P" (for packed) is omitted in mnemonics from its introduction. AVX10.2
	BF16 arithmetic insns are introduced with "P" in mnemonics with packed.
	This patch will remove them for consistency.

	NE is quite ambiguous and misleading in mnemonics since it should be
	Rounding to Nearest Even, but could be mis-interpretated to No
	Exception. While AI data types like BF16 and FP8 are using Rounding to
	Nearest Even as default rounding modes. There is no need to use the
	ambiguous mnemonics in AVX10.2 insns. This patch will also remove them.

	For convert insns, it will be handled in the upcoming patch.

	gas/ChangeLog:

		* testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase
		according to new mnemonics.
		* testsuite/gas/i386/avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-bf16.s: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-prefix.h: Remove p and ne in bf16 mnemonics.
		* i386-opc.tbl: Ditto.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2025-01-14  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AMX-AVX512
	This patch will support AMX-AVX512. In disassmbler, we pull out all
	GPR mode out of the vex length switch to make it more general.

	gas/ChangeLog:

		* NEWS: Mention the full support on DMR AMX ISAs.
		* config/tc-i386.c: Add amx_avx512.
		* doc/c-i386.texi: Document .amx_avx512.
		* testsuite/gas/i386/x86-64.exp: Run AMX-AVX512 tests.
		* testsuite/gas/i386/x86-64-amx-avx512-intel.d: New test.
		* testsuite/gas/i386/x86-64-amx-avx512.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-avx512.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-len.h: Add EVEX_LEN_0F384A_X86_64_W_0,
		EVEX_LEN_0F386D_X86_64_W_0, EVEX_LEN_0F3A07_X86_64_W_0,
		EVEX_LEN_0F3A77_X86_64_W_0.
		* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F384A_W_0_L_2,
		PREFIX_EVEX_0F386D_W_0_L_2, PREFIX_EVEX_0F3A07_W_0_L_2,
		PREFIX_EVEX_0F3A77_W_0_L_2.
		* i386-dis-evex-w.h: Add EVEX_W_0F384A_X86_64, EVEX_W_0F386D_X86_64,
		EVEX_W_0F3A07_X86_64, EVEX_W_0F3A77_X86_64.
		* i386-dis-evex-x86-64.h: Add X86_64_EVEX_0F384A, X86_64_EVEX_0F386D,
		X86_64_EVEX_0F3A07, X86_64_EVEX_0F3A77.
		* i386-dis-evex.h: Ditto.
		* i386-dis.c (EVEX_LEN_0F384A_X86_64_W_0): New.
		(EVEX_LEN_0F386D_X86_64_W_0): Ditto.
		(EVEX_LEN_0F3A07_X86_64_W_0): Ditto.
		(EVEX_LEN_0F3A77_X86_64_W_0): Ditto.
		(MOD_EVEX_0F384A_X86_64_W_0): Ditto.
		(MOD_EVEX_0F386D_X86_64_W_0): Ditto.
		(MOD_EVEX_0F3A07_X86_64_W_0): Ditto.
		(MOD_EVEX_0F3A77_X86_64_W_0): Ditto.
		(PREFIX_EVEX_0F384A_W_0_L_2): Ditto.
		(PREFIX_EVEX_0F386D_W_0_L_2): Ditto.
		(PREFIX_EVEX_0F3A07_W_0_L_2): Ditto.
		(PREFIX_EVEX_0F3A77_W_0_L_2): Ditto.
		(EVEX_W_0F384A_X86_64): Ditto.
		(EVEX_W_0F386D_X86_64): Ditto.
		(EVEX_W_0F3A07_X86_64): Ditto.
		(EVEX_W_0F3A77_X86_64): Ditto.
		(X86_64_EVEX_0F384A): Ditto.
		(X86_64_EVEX_0F386D): Ditto.
		(X86_64_EVEX_0F3A07): Ditto.
		(X86_64_EVEX_0F3A77): Ditto.
		(OP_VEX): Pull out all GPR mode out of the vector length switch.
		* i386-gen.c (isa_dependencies): Add AMX-AVX512.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuAMX_AVX512): New.
		(i386_cpu_flags): Add cpuamx_avx512.
		* i386-opc.tbl: Add AMX-AVX512 instructions.
		* i386-tbl.h: Regenerated.

2025-01-14  Hu, Lin1  <lin1.hu@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AMX-MOVRS
	This patch will support AMX-MOVRS feature. Unlike all the other
	AMX insns in vector space where we pass vex_len_table before
	vex_w_table, we first pass vex_w_table for tileloaddrs[,t1] to
	align with the order in EVEX space. The reason why we first pass
	vex_w_table in EVEX space is due to AMX-AVX512, where tcvtrowd2ps
	and tilemovrow with r32 shares the same opcode with tileloaddrs[,t1].
	All of them have evex.w = 0 but with different evex.length. Re-doing
	that shortly is not ideal.

	APX_F extension is also implemented in this patch. The encoding will
	be:
	  - EVEX.128.NP/66.MAP5.W0 F8/F9 !(11):rrr:100 for
	    T2RPNTLVW[Z0,Z1]RS[,T1] with NF=0.
	  - EVEX.128.F2/66.0F38.W0 4A !(11):rrr:100 FOR TILELOADDRS[,T1] with
	    NF=0.

	For APX_F extension, we could not use APX_F(AMX_TRANSPOSE&AMX_MOVRS)
	since the transformation could not be done. Instead, we will use
	AMX_TRANSPOSE & APX_F(AMX_MOVRS). Thus, we should set AMX_TRANSPOSE
	for "any" for cpu_flags in assembler. Since it will only affect the
	cpu_flags_match, handle that there.

	gas/ChangeLog:

		* config/tc-i386.c (cpu_arch): Add amx_movrs.
		(cpu_flags_match): Set any bitfield for multiple cpuid
		enabled insns.
		* doc/c-i386.texi: Document .amx_movrs.
		* testsuite/gas/i386/x86-64.exp: Run AMX-MOVRS tests.
		* testsuite/gas/i386/x86-64-amx-movrs-intel.d: New test.
		* testsuite/gas/i386/x86-64-amx-movrs-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-amx-movrs-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-movrs.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-movrs.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-len.h (EVEX_LEN_0F384A_X86_64_W_0): New.
		* i386-dis-evex-w.h (EVEX_W_0F384A_X86_64): Ditto.
		* i386-dis-evex-x86-64.h (X86_64_EVEX_0F384A): Ditto.
		* i386-dis-evex.h: New entry for AMX-MOVRS.
		* i386-dis.c:
		(PREFIX_VEX_0F384A_X86_64_L_0_W_0): New.
		(PREFIX_VEX_MAP5_F8_X86_64_L_0_W_0): Ditto.
		(PREFIX_VEX_MAP5_F9_X86_64_L_0_W_0): Ditto.
		(X86_64_VEX_0F384A): Ditto.
		(X86_64_VEX_MAP5_F8): Ditto.
		(X86_64_VEX_MAP5_F9): Ditto.
		(X86_64_EVEX_0F384A): Ditto.
		(VEX_LEN_0F384A_X86_64_W_0): Ditto.
		(VEX_LEN_MAP5_F8_X86_64): Ditto.
		(VEX_LEN_MAP5_F9_X86_64): Ditto.
		(EVEX_LEN_0F384A_X86_64_W_0): Ditto.
		(VEX_W_0F384A_X86_64): Ditto.
		(VEX_W_MAP5_F8_X86_64): Ditto.
		(VEX_W_MAP5_F9_X86_64): Ditto.
		(EVEX_W_0F384A_X86_64): Ditto.
		(prefix_table): New entry for AMX-MOVRS.
		(x86_64_table): Ditto.
		(vex_len_table): Ditto.
		(vex_w_table): Ditto.
		(map5_f8_opcode): New.
		(map5_f9_opcode): Ditto.
		(get_valid_dis386): Handle VEX_MAP5 opcode for AMX-MOVRS.
		* i386-gen.c (isa_dependencies): Add AMX_MOVRS.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuAMX_MOVRS): New.
		(i386_cpu_flags): Add cpuamx_movrs.
		* i386-opc.tbl: Add AMX-MOVRS instructions.
		* i386-tbl.h: Regenerated.

2025-01-14  Hu, Lin1  <lin1.hu@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>
	    Lili Cui  <lili.cui@intel.com>

	Support Intel MOVRS
	This patch focus on supporting MOVRS ISA. We could take this full ISA
	as four part: PREFETCHRST2, MOVRS, MOVRS APX_F extension and MOVRS AVX10.2
	extension.

	The APX_F extension for MOVRS will be:
	  - EVEX.LLZ.NP.MAP4.WIG 8A !(11):rrr:bbb for r8/m8 with NF=0 and
	    ND=0
	  - EVEX.LLZ.NP/66.MAP4.SCALABLE 8B !(11):rrr:bbb for rv/mv with NF=0
	    and ND=0

	We did not merge the table together for APX_F since there is an explicit
	x64 for movrs insn. The current APX_F() did not support the combination
	between CPUIDs. Also, the space is different for legacy and apx_f forms.

	gas/ChangeLog:

		* NEWS: Support Intel MOVRS.
		* config/tc-i386.c: Add MOVRS.
		* doc/c-i386.texi: Document .movrs.
		* testsuite/gas/i386/i386.exp: Run MOVRS tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Add MOVRS
		tests.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto.
		* testsuite/gas/i386/lfence-load.d: Add prefetchrst2.
		* testsuite/gas/i386/lfence-load.s: Ditto.
		* testsuite/gas/i386/nops-8.d: Ditto.
		* testsuite/gas/i386/prefetch-intel.d: Ditto.
		* testsuite/gas/i386/prefetch.d: Ditto.
		* testsuite/gas/i386/x86-64-lfence-load.d: Ditto.
		* testsuite/gas/i386/x86-64-lfence-load.s: Ditto.
		* testsuite/gas/i386/x86-64-prefetch-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-prefetch.d: Ditto.
		* testsuite/gas/i386/movrs-intel.d: New test.
		* testsuite/gas/i386/movrs-inval.l: Ditto.
		* testsuite/gas/i386/movrs-inval.s: Ditto.
		* testsuite/gas/i386/movrs.d: Ditto.
		* testsuite/gas/i386/movrs.s: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-256-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-256.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-256.s: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-512-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-512.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-avx10_2-512.s: Ditto.
		* testsuite/gas/i386/x86-64-movrs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs.s: Ditto.
		* testsuite/gas/i386/x86-64-movrs-intel-suffix.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-suffix.d: Ditto.
		* testsuite/gas/i386/x86-64-movrs-suffix.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_6F_X86_64.
		* i386-dis-evex-x86.h: Add X86_64_EVEX_MAP5_6F.
		* i386-dis-evex.h (evex_table): New entry for movrs.
		* i386-dis.c (MOD_0F18_REG_4): New.
		(PREFIX_EVEX_MAP5_6F_X86_64): Ditto.
		(X86_64_0F388A): Ditto.
		(X86_64_0F388B): Ditto.
		(X86_64_EVEX_MAP5_6F): Ditto.
		(three_byte_table): New entry for MOVRS.
		(reg_table): Ditto.
		(mod_table): Ditto.
		(x86_64_table): Ditto. Also include i386-dis-evex-x86.h.
		* i386-gen.c (cpu_flags): Add MOVRS.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (i386_cpu_flags): Add cpumovrs.
		* i386-opc.tbl: Add MOVRS instrctions.
		* i386-tbl.h: Regenerated.

2025-01-14  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Remove mod_table pass for MVexSIBMEM
	When using MVexSIBMEM, OP_M will help check modrm. Thus, no need
	to pass mod_table.

	Since we have OP_M do the work, from now on, mod_table[] should
	not gain any new entries, unless both slots of them are populated,
	e.g., different modrm leading to different insns could not be
	combined (Bad_Opcode is not the case since OP_M could handle that).

	opcodes/ChangeLog:

		* i386-dis.c: Remove mod_table pass for MVexSIBMEM.

2025-01-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-13  H.J. Lu  <hjl.tools@gmail.com>

	h8300: Handle .gnu_object_only section
		PR ld/12291
		PR ld/12430
		PR ld/13298
		* config/tc-h8300.c (h8300_elf_section): Handle .gnu_object_only
		section.

	ld: Document mixing LTO and non-LTO objects for -r
		* ld.texi: Document mixing LTO and non-LTO relocatable files for
		"ld -r".

2025-01-13  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add LTO and none-LTO output support for ld -r
	Link with mixed IR/non-IR objects

	* 2 kinds of object files
	  o non-IR object file has
	    * non-IR sections
	  o IR object file has
	    * IR sections
	    * non-IR sections
	    * The output of "ld -r" with mixed IR/non-IR objects should work with:
	        o Compilers/linkers with IR support.
		o Compilers/linkers without IR support.
	* Add the mixed object file which has
	  o IR sections
	  o non-IR sections:
	    * Object codes from IR sections.
	    * Object codes from non-IR object files.
	  o Object-only section:
	    * With section name ".gnu_object_only" and SHT_GNU_OBJECT_ONLY type
	    on ELF:
	    https://gitlab.com/x86-psABIs/Linux-ABI
	    #define SHT_GNU_OBJECT_ONLY 0x6ffffff8	/* Object only */
	    * Contain non-IR object file.
	    * Input is discarded after link.
	* Linker action:
	  o Classify each input object file:
	    * If there is a ".gnu_object_only" section, it is a mixed object file.
	    * If there is a IR section, it is an IR object file.
	    * Otherwise, it is a non-IR object file.
	  o Relocatable non-IR link:
	    * Prepare for an object-only output.
	    * Prepare for a regular output.
	    * For each mixed object file:
	      * Add IR and non-IR sections to the regular output.
	      * For object-only section:
		* Extract object only file.
		* Add it to the object-only output.
		* Discard object-only section.
	    * For each IR object file:
	      * Add IR and non-IR sections to the regular output.
	    * For each non-IR object file:
	      * Add non-IR sections to the regular output.
	      * Add non-IR sections to the object-only output.
	    * Final output:
	      * If there are IR objects, non-IR objects and the object-only
	      output isn't empty:
		* Put the object-only output into the object-only section.
		* Add the object-only section to the regular output.
		* Remove the object-only output.
	  o Normal link and relocatable IR link:
	    * Prepare for output.
	    * IR link:
	      * For each mixed object file:
		* Compile and add IR sections to the output.
		* Discard non-IR sections.
		* Object-only section:
		  * Extract object only file.
		  * Add it to the output.
		  * Discard object-only section.
	      * For each IR object file:
	        * Compile and add IR sections to the output.
		* Discard non-IR sections.
	      * For each non-IR object file:
		* Add non-IR sections to the output.
	    * Non-IR link:
	      * For each mixed object file:
		* Add non-IR sections to the output.
		* Discard IR sections and object-only section.
	      * For each IR object file:
		* Add non-IR sections to the output.
		* Discard IR sections.
	      * For each non-IR object file:
		* Add non-IR sections to the output.

	This is useful for Linux kernel build with LTO.

	bfd/

		PR ld/12291
		PR ld/12430
		PR ld/13298
		* bfd.c (bfd_lto_object_type): Add lto_mixed_object.
		(bfd): Add object_only_section.
		(bfd_group_signature): New.
		* elf.c (special_sections_g): Add .gnu_object_only.
		* format.c: Include "plugin-api.h" and "plugin.h" if
		BFD_SUPPORTS_PLUGINS is defined.
		(bfd_set_lto_type): Set type to lto_mixed_object for
		GNU_OBJECT_ONLY_SECTION_NAME section.
		(bfd_check_format_matches): Don't check the plugin target twice
		if the plugin target is explicitly specified.
		* opncls.c (bfd_extract_object_only_section): New.
		* plugin.c (bfd_plugin_fake_text_section): New.
		(bfd_plugin_fake_data_section): Likewise.
		(bfd_plugin_fake_bss_section): Likewise.
		(bfd_plugin_fake_common_section): Likewise.
		(bfd_plugin_get_symbols_in_object_only): Likewise.
		* plugin.c (add_symbols): Call
		bfd_plugin_get_symbols_in_object_only and count
		plugin_data->object_only_nsyms.
		(bfd_plugin_get_symtab_upper_bound): Count
		plugin_data->object_only_nsyms.
		bfd_plugin_get_symbols_in_object_only and add symbols from
		object only section.
		(bfd_plugin_canonicalize_symtab): Remove fake_section,
		fake_data_section, fake_bss_section and fake_common_section.
		Set udata.p to NULL.  Use bfd_plugin_fake_text_section,
		bfd_plugin_fake_data_section, bfd_plugin_fake_bss_section and
		bfd_plugin_fake_common_section.
		Set udata.p to NULL.
		* plugin.h (plugin_data_struct): Add object_only_nsyms and
		object_only_syms.
		* section.c (GNU_OBJECT_ONLY_SECTION_NAME): New.
		* bfd-in2.h: Regenerated.

	binutils/

		PR ld/12291
		PR ld/12430
		PR ld/13298
		* objcopy.c (group_signature): Removed.
		(is_strip_section): Replace group_signature with
		bfd_group_signature.
		(setup_section): Likewise.
		* readelf.c (get_os_specific_section_type_name): Handle
		SHT_GNU_OBJECT_ONLY.

	gas/

		PR ld/12291
		PR ld/12430
		PR ld/13298
		* testsuite/gas/elf/section9.s: Add the .gnu_object_only test.
		* testsuite/gas/elf/section9.d: Updated.

	include/

		PR ld/12291
		PR ld/12430
		PR ld/13298
		* elf/common.h (SHT_GNU_OBJECT_ONLY): New.

	ld/

		PR ld/12291
		PR ld/12430
		PR ld/13298
		* ld.h (ld_config_type): Add emit_gnu_object_only and
		emitting_gnu_object_only.
		* ldelf.c (orphan_init_done): Make it file scope.
		(ldelf_place_orphan): Rename hold to orig_hold.  Initialize hold
		from orig_hold at run-time.
		(ldelf_finish): New.
		* ldelf.h (ldelf_finish): New.
		* ldexp.c (ldexp_init): Take a bfd_boolean argument to supprt
		object-only output.
		(ldexp_finish): Likewise.
		* ldexp.h (ldexp_init): Take a bfd_boolean argument.
		(ldexp_finish): Likewise.
		* ldfile.c (ldfile_try_open_bfd): Call
		cmdline_check_object_only_section.
		* ldlang.c: Include "ldwrite.h" and elf-bfd.h.
		* ldlang.c (cmdline_object_only_file_list): New.
		(cmdline_object_only_archive_list): Likewise.
		(cmdline_temp_object_only_list): Likewise.
		(cmdline_lists_init): Likewise.
		(cmdline_list_new): Likewise.
		(cmdline_list_append): Likewise.
		(print_cmdline_list): Likewise.
		(cmdline_on_object_only_archive_list_p): Likewise.
		(cmdline_object_only_list_append): Likewise.
		(cmdline_get_object_only_input_files): Likewise.
		(cmdline_arg): Likewise.
		(setup_section): Likewise.
		(copy_section): Likewise.
		(cmdline_fopen_temp): Likewise.
		(cmdline_add_object_only_section): Likewise.
		(cmdline_emit_object_only_section): Likewise.
		(cmdline_extract_object_only_section): Likewise.
		(cmdline_check_object_only_section): Likewise.
		(cmdline_remove_object_only_files): Likewise.
		(lang_init): Take a bfd_boolean argument to supprt object-only
		output.  Call cmdline_lists_init.
		(load_symbols): Call cmdline_on_object_only_archive_list_p
		to check if an archive member should be loaded.
		(lang_process): Handle object-only link.
		* ldlang.h (lang_init): Take a bfd_boolean argument.
		(cmdline_enum_type): New.
		(cmdline_header_type): Likewise.
		(cmdline_file_type): Likewise.
		(cmdline_bfd_type): Likewise.
		(cmdline_union_type): Likewise.
		(cmdline_list_type): Likewise.
		(cmdline_emit_object_only_section): Likewise.
		(cmdline_check_object_only_section): Likewise.
		(cmdline_remove_object_only_files): Likewise.
		* ldmain.c (main): Call xatexit with
		cmdline_remove_object_only_files.  Pass FALSE to lang_init,
		ldexp_init and ldexp_finish.  Use ld_parse_linker_script.
		Set link_info.output_bfd to NULL after close.  Call
		cmdline_emit_object_only_section if needed.
		(add_archive_element): Call cmdline_check_object_only_section.
		(ld_parse_linker_script): New.
		* ldmain.h (ld_parse_linker_script): New.
		* plugin.c (plugin_maybe_claim): Call
		cmdline_check_object_only_section on claimed IR files.
		* scripttempl/elf.sc: Also discard .gnu_object_only sections.
		* scripttempl/elf64hppa.sc: Likewise.
		* scripttempl/elfxtensa.sc: Likewise.
		* scripttempl/mep.sc: Likewise.
		* scripttempl/pe.sc: Likewise.
		* scripttempl/pep.sc: Likewise.
		* emultempl/aarch64elf.em (gld${EMULATION_NAME}_finish): Replace
		finish_default with ldelf_finish.
		* emultempl/alphaelf.em (alpha_finish): Likewise.
		* emultempl/avrelf.em (avr_finish): Likewise.
		* emultempl/elf.em (ld_${EMULATION_NAME}_emulation): Likewise.
		* emultempl/ppc32elf.em (ppc_finish): Likewise.
		* emultempl/ppc64elf.em (gld${EMULATION_NAME}_finish): Likewise.
		* emultempl/spuelf.em (gld${EMULATION_NAME}_finish): Likewise.
		* testsuite/ld-plugin/lto-10.out: New file.
		* testsuite/ld-plugin/lto-10a.c: Likewise.
		* testsuite/ld-plugin/lto-10b.c: Likewise.
		* testsuite/ld-plugin/lto-10r.d: Likewise.
		* testsuite/ld-plugin/lto-4.out: Likewise.
		* testsuite/ld-plugin/lto-4a.c: Likewise.
		* testsuite/ld-plugin/lto-4b.c: Likewise.
		* testsuite/ld-plugin/lto-4c.c: Likewise.
		* testsuite/ld-plugin/lto-4r-a.d: Likewise.
		* testsuite/ld-plugin/lto-4r-b.d: Likewise.
		* testsuite/ld-plugin/lto-4r-c.d: Likewise.
		* testsuite/ld-plugin/lto-4r-d.d: Likewise.
		* testsuite/ld-plugin/lto.exp (lto_link_tests): Prepare for
		"LTO 4[acd]", "lto-4r-[abcd]" and "LTO 10" tests.
		(lto_run_tests): Add "LTO 4[acd]" and "LTO 10" tests.
		Build liblto-4.a.  Run "lto-4r-[abcd]" tests.
		Run lto-10r and create tmpdir/lto-10.o.
		Add test for nm on mixed LTO/non-LTO object.

2025-01-13  Aditya Vidyadhar Kamath  <aditya.kamath1@ibm.com>

	Fix AIX CI build break.
	In AIX a recent commit caused a build break with the error as shown below.
	In file included from python/py-color.h:23,
	                 from python/python.c:39:
	python/python-internal.h:86:10: fatal error: Python.h: No such file or directory
	   86 | #include <Python.h>

	In AIX, we run builds with and without python for our internal CI's.

	A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690
	missed to guard Python.h in HAVE_PYTHON macro.

	This commit is a fix for the same.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-13  Tom Tromey  <tromey@adacore.com>

	Handle case where DAP line can be None
	A comment in bugzilla pointed out a bug in my earlier patch to handle
	the DAP "linesStartAt1" setting.  In particular, in the backtrace
	code, "line" can be None, which would lead to an exception from
	export_line.

	This patch fixes the problem.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468

2025-01-13  Jan Beulich  <jbeulich@suse.com>

	bfd/ELF: slightly "better" file alignment for object files
	PR gas/32435

	Commit 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object
	files") caused an issue in the Linux kernels modpost utility, which was
	building upon .rodata sections to be 4-byte aligned in the file when
	they have 4-byte alignment. While we don't want to revert back to
	original behavior, apply the same alignment "capping" as done originally
	in two other places also for "ordinary" sections.

2025-01-13  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, doc: do a minor fix in the description of qTSTMat
	Fix a typo and do a format change.

2025-01-13  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/jit: use correctly-sized array view in deprecated_frame_register_read call
	Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in
	register reading and unwinding") introduces a regression in
	gdb.base/jit-reader.exp:

	    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/jit-reader/jit-reader -ex 'jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader.so' -ex r -batch

	    This GDB supports auto-downloading debuginfo from the following URLs:
	      <https://debuginfod.archlinux.org>
	    Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
	    Debuginfod has been disabled.
	    To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
	    [Thread debugging using libthread_db enabled]
	    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".

	    Program received signal SIGTRAP, Trace/breakpoint trap.
	    Recursive internal problem.

	The "Recusive internal problem" part is not good, but it's not the point
	of this patch.  It still means we hit an internal error.

	The stack trace is:

	    #0  internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53
	    #1  0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...)
	        at /home/simark/src/binutils-gdb/gdb/frame.c:1207
	    #2  0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496
	    #3  0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988
	    #4  0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100
	    #5  0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143
	    #6  0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 <jit_frame_unwind>, this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042
	    #7  0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 <jit_frame_unwind>) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138
	    #8  0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209
	    #9  0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996
	    #10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033

	The problem is that function `jit_unwind_reg_get_impl` passes field
	`gdb_reg_value::value`, a gdb_byte array of 1 element (used as a
	flexible array member), as the array view parameter of
	`deprecated_frame_register_read`.  This results in an array view of size
	1.  The assertion in `frame_register_unwind` that verifies the passed in
	buffer is larger enough to hold the unwound register value then fails.

	Fix this by explicitly creating an array view of the right size.

	Change-Id: Ie170da438ec9085863e7be8b455a067b531635dc
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2025-01-13  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Cleanup the imply code and test cases for vendor xsf extensions.

2025-01-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-12  Andrei Pikas  <gdb@mail.api.win>

	Add an option with a color type.
	Colors can be specified as "none" for terminal's default color, as a name of
	one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.,
	as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an
	integer from 0 to 255.  Integers 0 to 7 are the synonyms for the standard
	colors.  Integers 8-15 are used for the so-called bright colors from the
	aixterm extended 16-color palette.  Integers 16-255 are the indexes into xterm
	extended 256-color palette (usually 6x6x6 cube plus gray ramp).  In
	general, 256-color palette is terminal dependent and sometimes can be
	changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\".

	It is the responsibility of the user to verify that the terminal supports
	the specified colors.

	PATCH v5 changes: documentation fixed.
	PATCH v6 changes: documentation fixed.
	PATCH v7 changes: rebase onto master and fixes after review.
	PATCH v8 changes: fixes after review.

2025-01-12  Tom Tromey  <tom@tromey.com>

	Fix grammar in "Debug Names" node of the manual
	I noticed that an article was missing in the "Debug Names" node.  I'm
	checking this in to correct the error.

2025-01-12  Tom Tromey  <tom@tromey.com>

	Remove unused declaration and macros
	event-top.h declares the_prompts, but it is never defined.  It's a
	leftover from some ancient refactoring.

	Similarly, top.c defines a few prompt-related macros, but these are
	unused.

	This patch removes these.

2025-01-12  H.J. Lu  <hjl.tools@gmail.com>

	ld: Update function prototypes for compilers defaulting to -std=gnu23
	Since GCC 15 defaults to -std=gnu23, update function prototypes in linker
	tests for compilers defaulting to -std=gnu23.

		PR ld/32546
		* ld-shared/main.c (shlib_checkfunptr1): Update prototype for
		compilers defaulting to -std=gnu23.
		(shlib_checkfunptr2): Likewise.
		* ld-shared/sh1.c (shlib_checkfunptr1): Likewise.
		(shlib_checkfunptr2): Likewise.
		* ld-srec/sr1.c (fn1): Likewise.
		(fn2): Likewise.
		* ld-srec/sr2.c (fn1): Likewise.
		(fn2): Likewise.
		* ld-vsb/main.c (shlib_checkfunptr1): Likewise.
		(shlib_checkfunptr2): Likewise.
		* ld-vsb/sh1.c (hlib_checkfunptr1): Likewise.
		(shlib_checkfunptr2): Likewise.

2025-01-12  Sergio Durigan Junior  <sergiodj@sergiodj.net>

	Fix typo in gdb/csky-linux-tdep.c
	This was flagged by Debian's lintian.

2025-01-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-11  Tom Tromey  <tom@tromey.com>

	Update comment in linespec.c
	I belatedly realized I had forgotten to update a bool-related comment
	in linespec.c.  This patch fixes the oversight.

2025-01-11  Tom Tromey  <tom@tromey.com>

	Use bool in linespec
	This changes various spots in linespec to use a bool rather than an
	int.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  Tom Tromey  <tom@tromey.com>

	Hoist lambda in linespec.c:add_matching_symbols_to_info
	I noticed that two parts of linespec.c:add_matching_symbols_to_info
	use the same lambda, and hoisting this seems slightly more efficient.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  Tom Tromey  <tom@tromey.com>

	Minor cleanup in linespec.c:add_minsym
	This cleans up a 'return' in linespec.c:add_minsym.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  Tom Tromey  <tom@tromey.com>

	Use std::vector in linespec_state
	This changes linespec_state to use a std::vector, and changes
	linespec_canonical_name to use std::string.  This removes some manual
	memory management, including some odd cleanup code in in
	decode_line_full.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  Tom Tromey  <tom@tromey.com>

	Use gdb::unordered_set in linespec_state
	This patch changes linespec_state to use gdb::unordered_set.  This
	simplifies the code a little and removes some manual management.  It
	also replaces address_entry with a std::pair, which simplifies the
	code even more; and since this is a private type, IMO it doesn't
	reduce readability at all.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  Tom Tromey  <tom@tromey.com>

	Add constructor and destructor to linespec_state
	This changes linespec_state to have real constructors and a
	destructor.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-10  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: Use gdb::array_view for buffers used in register reading and unwinding
	This allows checking the size of the given buffer.  Changes
	frame_register_unwind (), frame_unwind_register (), get_frame_register ()
	and deprecated_frame_register_read ().

	As pointed out by Baris, in the case of MIPS target code this is best
	done by changing a couple of alloca-based buffers in
	mips_read_fp_register_single and mips_print_fp_register to
	gdb::byte_vector instances.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-10  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: frame: Make VALUEP argument optional in frame_register_unwind
	It already accepts a nullptr value and a couple of places were always
	calling it that way, so make it possible to omit the argument entirely.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-10  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SME_B16B16 feature.
	This patch adds support for SME ZA-targeting non-widening BFloat16 instructions,
	under tick FEAT_SME_B16B16 and command line flag "+sme-b16b16".

	FEAT_SME_B16B16 implements FEAT_SME2 and FEAT_SVE_B16B16, in accordance with that
	"+sme-b16b16" enables "+sme2" and "+sve-b16b16".

	Also the test files related to FEAT_SME_B16B16 are prefixed with sme-b16b16*.
	eg: sme-b16b16-1.s, sme-b16b16-1.d.

	The spec for this feature and instructions is availabe here [1]:
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en

2025-01-10  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SVE_B16B16 min and max instructions.
	This patch adds support for SME Z-targeting multi-vector non-widening
	BFloat16 instructions, under tick FEAT_SVE_B16B16 and command line flag
	"+sve-b16b16+sme2".

	Also the test files related to FEAT_SVE_B16B16 (+sme2) are prefixed with
	sve-b16b16-sme2*.
	eg: sve-b16b16-sme2-1.s, sve-b16b16-sme2-1.d.

	The spec for this feature and instructions is availabe here [1]:
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en

2025-01-10  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SVE_B16B16 feature.
	In the current code, SVE2 Bfloat16 instructions are implemented with tick
	FEAT_B16B16 and command line flag "+b16b16" and this feature was suspended
	due to incomplete support.

	In the new spec available here[1], FEAT_B16B16 is replaced with
	FEAT_SVE_B16B16 and command line flag "+b16b16" is replace with "sve-b16b16".

	Also the test files related to FEAT_SVE_B16B16 are prefixed with sve-b16b16*.
	eg: sve-b16b16-sve2-1.s, sve-b16b16-sve2-1.d.

	This patch supports the SVE Z-targeting non-widening BFloat16 instructions
	with command line flag "+sve-b16b16+sve2".
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SVE-Instructions?lang=en

2025-01-10  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Make VGx4 symbol mandatory for fvdotb and fvdott
	Add tests for this, and update the existing fvdotb and fvdott tests to
	include the VGx4 symbol so that they continue to test for the intended
	errors.

	aarch64: Rename AARCH64_OPND_SME_ZT0_INDEX2_12
	Rename to AARCH64_OPND_SME_ZT0_INDEX_MUL_VL.

	aarch64: Add tests for movt with missing "mul vl"
	The error message really isn't appropriate (both here and elsewhere in
	the test file), but I don't currently have time to investigate further.

	aarch64: Remove redundant sme-lutv2 qualifiers and operands

	aarch64: Fix incorrect gating of sme-lutv2 instructions
	Only the strided form of the luti4 intrinsic requires FEAT_SME2p1.

2025-01-10  Tom Tromey  <tromey@adacore.com>

	Minor test case updates for gnat-llvm
	gnat-llvm seems to be a bit more aggressive about eliminating unused
	variables.  This patch improves the test results a tiny bit by
	arranging for some variables to appear to be used.

	Note the copyright dates on the new files are done that way because I
	simply copied existing files.

2025-01-10  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SME_F16F16 fcvt and fcvtl instructions.
	This patch adds support for FEAT_SME_F16F16 instructions fcvt and fcvtl,
	which are available on passing command line flags +sme-f16f16 and the
	spec is available here[1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en

	aarch64: Add support for FEAT_SME_F16F16 fmla and fmls instructions.
	This patch adds support for FEAT_SME_F16F16 instructions fmla and fmls,
	which are available on passing command line flags +sme-f16f16 and the
	spec is available here[1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en

	aarch64: Add support for FEAT_SME_F16F16 fmops and fmopa instructions.
	This patch adds support for FEAT_SME_F16F16 instructions fmops and fmopa,
	which are available on passing command line flags +sme-f16f16 and the
	spec is available here[1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en

2025-01-10  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SME_F16F16 feature.
	This patch adds support for FEAT_SME_F16F16 feature (Non-widening
	half-precision FP16 to FP16 arithmetic for SME2), which is enabled
	using command line flags +sme-f16f16 to -march (which enables both
	FEAT_SME2 and FEAT_SME_F16F16).

	There are couple of instructions (fadd and fsub variants) which should
	be allowed by the assembler on either passing +sme-f16f16 or +sme-f8f16.
	Those instructions are already supported in the current assembler, this
	patch adds tests for those instructions as well.

2025-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.cp/non-trivial-retval.exp on riscv64-linux
	With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into:
	...
	(gdb) finish^M
	Run till exit from #0  f1 (i1=i1@entry=23, i2=i2@entry=100) \
	  at non-trivial-retval.cc:34^M
	main () at non-trivial-retval.cc:163^M
	163       B b = f2 (i1, i2);^M
	Value returned is $6 = {a = -5856}^M
	(gdb) FAIL: $exp: finish from f1
	...
	where "Value returned is $6 = {a = 123}" is expected.

	The problem is that gdb thinks that the return value is in $a0:
	...
	$ gdb -q -batch non-trivial-retval \
	  -ex "b f1" \
	  -ex run \
	  -ex "set debug riscv infcall on" \
	  -ex finish
	Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34.
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".

	Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34
	34      {
	[riscv-infcall] riscv_return_value: \
	  [R] type: 'A', length: 0x4, alignment: 0x4, register a0
	[riscv-infcall] riscv_return_value: \
	  [R] type: 'A', length: 0x4, alignment: 0x4, register a0
	[riscv-infcall] riscv_return_value: \
	  [R] type: 'A', length: 0x4, alignment: 0x4, register a0
	main () at non-trivial-retval.cc:163
	163       B b = f2 (i1, i2);
	Value returned is $1 = {a = -3568}
	...
	while $a0 actually contains a pointer to the returned value 123:
	...
	(gdb) p /x $a0
	$3 = 0x3ffffff210
	(gdb) p  *((unsigned int *)$a0)
	$5 = 123
	...

	The returned type is:
	...
	class A
	{
	public:
	  A () {}
	  A (A &obj);

	  int a;
	};
	...
	which is a C++ aggregate with a nontrivial (because it's user-defined) copy
	constructor:

	According to the ABI [1], indeed this is returned by reference:
	...
	Values are returned in the same manner as a first named argument of the same
	type would be passed.  If such an argument would have been passed by
	reference, the caller allocates memory for the return value, and passes the
	address as an implicit first parameter.
	  ...
	Aggregates larger than 2×XLEN bits are passed by reference and are replaced in
	the argument list with the address, as are C++ aggregates with nontrivial copy
	constructors, destructors, or vtables.
	...

	Fix this in riscv_call_arg_scalar_int by checking for
	language_pass_by_reference ().trivially_copy_constructible.

	The vtable case is explictly mentioned in the ABI, but AFAIU already covered
	by the nontrivial copy constructor case.

	The nontrivial destructor case is also not supported, but the testsuite
	doesn't seem to trigger this.

	Fix this by:
	- extending the test-case to cover this scenario, and
	- fixing it in riscv_call_arg_scalar_int by checking for
	  language_pass_by_reference ().trivially_destructible.

	Tested on riscv64-linux.

	PR tdep/32152
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32152

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc

2025-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.rust/completion.exp timeout on riscv64-linux
	On riscv64-linux, with test-case gdb.rust/completion.exp I run into the
	following timeout:
	...
	(gdb) complete break pars^M
	FAIL: gdb.rust/completion.exp: complete break pars (timeout)
	...

	Replaying the scenario outside the testsuite show us that the command takes
	~13 seconds:
	...
	$ gdb -q -batch -x gdb.in
	  ...
	2025-01-08 12:23:46.853 - command started
	+complete break pars
	break parse.rs
	break parse_printf_format
	break parse_running_mmaps_unix.rs
	break parser.rs
	2025-01-08 12:23:59.600 - command finished
	Command execution time: 12.677752 (cpu), 12.748565 (wall)
	...
	while the timeout is 10 seconds.

	The riscv64 processor on the server (cfarm91) is not fast (a fair amount of
	the skip_huge_test test-cases times out), but something else is going on as
	well.

	For x86_64-linux, roughly measuring the size of debug info in the exec get us:
	...
	$ readelf -wi outputs/gdb.rust/completion/completion | wc -l
	2007
	...
	while on the riscv64 server I get:
	...
	$ readelf -wi outputs/gdb.rust/completion/completion | wc -l
	1606950
	...

	So it seems reasonable that the test is somewhat slower on riscv64.

	Fix this by using timeout factor 2.

	Tested on riscv64-linux and x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-10  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Support x86 Zhaoxin PadLockRNG2 instruction
	This patch adds support for Zhaoxin PadLock RNG2 instruction, the
	CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2
	instruction.

	gas/ChangeLog:

		* NEWS: Support Zhaoxin PadLock RNG2 instruction.
		* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
		PadLock RNG2 instruction.
		(output_insn): Handle PadLock RNG2 instruction.
		* doc/c-i386.texi: Document PadLock RNG2.
		* testsuite/gas/i386/i386.exp: Add PadLock RNG2 test.
		* testsuite/gas/i386/padlock_rng2.d: Ditto.
		* testsuite/gas/i386/padlock_rng2.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: Add PadLockRNG2.
		* i386-gen.c: Ditto
		* i386-opc.h (CpuPadLockRNG2): New.
		* i386-opc.tbl: Add Zhaoxin PadLock RNG2 instruction.
		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2025-01-10  Jan Beulich  <jbeulich@suse.com>

	gas: consolidate . latching
	... by purging dot_{frag,value}. Right now these two and dot_symbol are
	updated independently, which can't be quite right. Centralize .-related
	information in dot_symbol, updating it also where previously
	dot_{frag,value} were updated. Since S_GET_VALUE() can't be used to
	retrieve what used to be dot_value, introduce a new helper to fetch both
	frag and offset.

2025-01-10  Jan Beulich  <jbeulich@suse.com>

	aarch64: re-work PR gas/27217 fix again
	Commit c1723a8118f0 ("Arm64: re-work PR gas/27217 fix") really was only
	a band-aid; Nick's original solution to the problem was technically
	preferable, yet didn't work when . came into play. Undo most of that
	change, now that expr_defer expression parsing mode latches dot as is
	desired here.

	Also add testing for the . case, which I should have done already back
	at the time.

2025-01-10  Jan Beulich  <jbeulich@suse.com>

	gas: make deferred expression evaluation generally latch dot
	Deferring expression evaluation is often necessary. However, the value
	current_location() records typically is intended to represent the
	location at the point of use of the expression, with the exception being
	.eqv (or its == equivalent). Change how expr_defer behaves in this
	regard, and introduce a special mode just for pseudo_set() to use.

	Introduce a predicate to cover both "deferred" modes, and use it
	everywhere except in current_location(), where only the new mode wants
	checking for.

2025-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix build with gcc 10
	With gcc 10 and -std=c++20, we run into the same problem as reported in commit
	6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct").

	The problem was fixed using:
	...
	-template<typename T, typename A = std::allocator<T>>
	+template<typename T,
	+         typename A
	+#if __cplusplus >= 202002L
	+         = std::pmr::polymorphic_allocator<T>
	+#else
	+         = std::allocator<T>
	+#endif
	+        >
	...
	but that doesn't work for gcc 10, because it defines __cplusplus differently:
	...
	 $ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
	 #define __cplusplus 201709L
	 $ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
	 #define __cplusplus 202002L
	...

	Fix this by using the library feature test macro
	__cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined
	for c++20:
	...
	 $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \
	   | grep __cpp_lib_polymorphic_allocator
	 $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \
	   | grep __cpp_lib_polymorphic_allocator
	 #define __cpp_lib_polymorphic_allocator 201902L
	 $
	...

	A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work
	around Werror=volatile in libguile.h").  Fix this by testing for 201709L
	instead.

	Tested on x86_64-linux, by building gdb with
	{gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}.

	PR build/32503
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator

2025-01-10  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: trad-frame: Store length of value_bytes in trad_frame_saved_reg
	The goal is to ensure that it is available in frame_unwind_got_bytes () to
	make sure that the provided buf isn't larger than the size of the register
	being provisioned.

	In the process, regcache's cached_reg_t::data also needed to be
	converted to a gdb::byte_vector, so that the register contents' size can
	be tracked.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-10  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB: remote: Print total bytes received in debug message
	This is useful information I missed while debugging issues with
	the g packet reply.

	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.base/readnever.exp on s390x
	On s390x-linux, I run into:
	...
	 (gdb) backtrace
	 #0  0x000000000100061a in fun_three ()
	 #1  0x000000000100067a in fun_two ()
	 #2  0x000003fffdfa9470 in ?? ()
	 Backtrace stopped: frame did not save the PC
	 (gdb) FAIL: gdb.base/readnever.exp: backtrace
	...

	This is really due to a problem handling the fun_three frame.  When generating
	a backtrace from fun_two, everying looks ok:
	...
	 $ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \
	     -ex "b fun_two" \
	     -ex run \
	     -ex bt
	   ...
	 #0  0x0000000001000650 in fun_two ()
	 #1  0x00000000010006b6 in fun_one ()
	 #2  0x00000000010006ee in main ()
	...

	For reference the frame info with debug info (without -readnever) looks like this:
	...
	$ gdb -q -batch outputs/gdb.base/readnever/readnever \
	    -ex "b fun_three" \
	    -ex run \
	    -ex "info frame"
	  ...
	Stack level 0, frame at 0x3fffffff140:
	 pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a
	 called by frame at 0x3fffffff1f0
	 source language c.
	 Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c
	 Locals at 0x3fffffff140, Previous frame's sp in v0
	...

	But with -readnever, like this instead:
	...
	Stack level 0, frame at 0x0:
	 pc = 0x100061a in fun_three; saved pc = 0x100067a
	 called by frame at 0x3fffffff140
	 Arglist at 0xffffffffffffffff, args:
	 Locals at 0xffffffffffffffff, Previous frame's sp in r15
	...

	An obvious difference is the "Previous frame's sp in" v0 vs. r15.

	Looking at the code:
	...
	0000000001000608 <fun_three>:
	 1000608:	b3 c1 00 2b       	ldgr	%f2,%r11
	 100060c:	b3 c1 00 0f       	ldgr	%f0,%r15
	 1000610:	e3 f0 ff 50 ff 71 	lay	%r15,-176(%r15)
	 1000616:	b9 04 00 bf       	lgr	%r11,%r15
	...
	it becomes clear what is going on.  This is an unusual prologue.

	Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack,
	instead they're saved into call-clobbered floating point registers.

	[ For reference, this is the prologue of fun_two:
	...
	0000000001000640 <fun_two>:
	 1000640:	eb bf f0 58 00 24 	stmg	%r11,%r15,88(%r15)
	 1000646:	e3 f0 ff 50 ff 71 	lay	%r15,-176(%r15)
	 100064c:	b9 04 00 bf       	lgr	%r11,%r15
	...
	where the first instruction stores registers r11 to r15 to stack. ]

	Gdb fails to properly analyze the prologue, which causes the problems getting
	the frame info.

	Fix this by:
	- adding handling of the ldgr insn [1] in s390_analyze_prologue, and
	- recognizing the insn as saving a register in
	  s390_prologue_frame_unwind_cache.

	This gets us instead:
	...
	Stack level 0, frame at 0x0:
	 pc = 0x100061a in fun_three; saved pc = 0x100067a
	 called by frame at 0x3fffffff1f0
	 Arglist at 0xffffffffffffffff, args:
	 Locals at 0xffffffffffffffff, Previous frame's sp in f0
	...
	and:
	...
	 (gdb) backtrace^M
	 #0  0x000000000100061a in fun_three ()^M
	 #1  0x000000000100067a in fun_two ()^M
	 #2  0x00000000010006b6 in fun_one ()^M
	 #3  0x00000000010006ee in main ()^M
	 (gdb) PASS: gdb.base/readnever.exp: backtrace
	...

	Tested on s390x-linux.

	PR tdep/32417
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417

	Approved-By: Andreas Arnez <arnez@linux.ibm.com>

	[1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf

2025-01-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use symbolic constants in s390_prologue_frame_unwind_cache
	In s390_prologue_frame_unwind_cache there are two loops using a hardcoded
	constant 16:
	...
	  for (i = 0; i < 16; i++)
	    if (s390_register_call_saved (gdbarch, S390_R0_REGNUM + i)
	  ...
	  for (i = 0; i < 16; i++)
	    if (s390_register_call_saved (gdbarch, S390_F0_REGNUM + i)
	...

	Fix this by using symbolic constants S390_NUM_GPRS and S390_NUM_FPRS instead.

	Tested on s390x-linux, by rebuilding.

	Approved-By: Andreas Arnez <arnez@linux.ibm.com>

2025-01-09  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: introduce and use regcache::set_register_status
	Introduce and use a setter method in regcache to set the status of a
	register.  There already exists get_register_status.  So, it made
	sense to add the setter to control access to the register_status
	field.

	In two places, we also do cosmetic improvements to for-loops.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Run one more test-case with ASAN_OPTIONS=verify_asan_link_order=0
	After building gdb with asan, and running test-case
	gdb.trace/basic-libipa.exp, I got:
	...
	(gdb) run ^M
	Starting program: basic-libipa ^M
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	==7705==ASan runtime does not come first in initial library list; you should \
	  either link runtime to your application or manually preload it with \
	  LD_PRELOAD.^M
	[Inferior 1 (process 7705) exited with code 01]^M
	(gdb) FAIL: gdb.trace/basic-libipa.exp: runto: run to main
	...

	Fix this in the same way as in commit 75948417af8 ("[gdb/testsuite] Run two
	test-cases with ASAN_OPTIONS=verify_asan_link_order=0").

	Tested on x86_64-linux.

2025-01-09  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: boolify thread_info's 'stop_requested' field
	Boolify the field.  The 'set_stop_requested' function was already
	taking a bool parameter, whose value is assigned to the field.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2025-01-09  Alan Modra  <amodra@gmail.com>

	PR32238, ld -r slowdown since 21401fc7bf
		PR 32238
		* ldlang.c (struct out_section_hash_entry): Add "tail".
		(output_section_statement_newfunc_1): New, extracted from..
		(output_section_statement_newfunc): ..here.  Init tail.
		(lang_output_section_statement_lookup): Use tail to avoid
		list traversal.

2025-01-09  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: dump 'xx...x' in collect_register_as_string for unavailable register
	Fix 'collect_register_as_string' so that unavailable registers are
	dumped as 'xx...x' instead of arbitrary values, in particular when
	reporting expedited registers in a resume reply packet.  This change
	gives the opportunity that we can reuse 'collect_register_as_string'
	in 'registers_to_string' for additional code simplification.

	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-09  Alan Modra  <amodra@gmail.com>

	xfail quad-div2 test for am33

	Excessive gas .irpt count
	There is a test in do_repeat to error on "negative" repeat counts.
	Just at what value a ssize_t is negative of course depends on the
	host.  Change the excessive repeat count to a fixed value, 0x80000000,
	ie. what would be seen as negative on a 32-bit host.

2025-01-09  Xiao Zeng  <zengxiao@eswincomputing.com>

	ld: Utilize specific digit ranges for different numeral systems
	        * ldlex.l: Utilize specific digit ranges for different
		numeral systems.

2025-01-09  Charlie Jenkins  <charlie@rivosinc.com>

	RISC-V: Add partial instruction display tests
	When objdump is specified with a stop address that ends up in the middle
	of an instruction, the partial instruction is expected to be displayed.
	These three tests check that the partial instruction is correctly
	displayed when there are 1, 2, or 3 bytes of the instruction dumped.

2025-01-09  Charlie Jenkins  <charlie@rivosinc.com>

	RISC-V: Fix display of partial instructions
	As of commit e43d8768d909 ("RISC-V: Fix disassemble fetch fail return
	value.") partial instructions are no longer displayed by objdump. While
	that commit fixed the behavior of print_insn_riscv() returning the
	arbitrary status value upon failure, it caused the behavior of dumping
	instructions to change. Allow partial instructions to be displayed once
	again and only return -1 if no part of the instruction was able to be
	displayed.

	Fixes: e43d8768d909 ("RISC-V: Fix disassemble fetch fail return
	value.")

	Acked-By: Andrew Burgess <aburgess@redhat.com>

2025-01-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-08  Tom Tromey  <tromey@adacore.com>

	Rename two Ada test suite functions
	I happened to notice that the Ada compiler emitted a warning when
	compiling a couple of DAP tests.  This wasn't intentional, and this
	patch renames the functions to match the filename.

2025-01-08  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	GDB, gdbserver: Convert regcache_register_size function to method
	The regcache_register_size function has one implementation in GDB, and
	one in gdbserver.  Both of them have a gdb::checked_static_cast to their
	corresponding regcache class.  This can be avoided by defining a
	pure virtual register_size method in the
	reg_buffer_common class, which is then implemented by the reg_buffer
	class in GDB, and by the regcache class in gdbserver.

	Calls to the register_size () function from methods of classes in the
	reg_buffer_common hierarchy need to be changed to calls to the newly
	defined method, otherwise the compiler complains that a matching method
	cannot be found.

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3

2025-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Check gnatmake version in gdb.ada/scalar_storage.exp
	On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into:
	...
	(gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
	get_compiler_info: gcc-14-2-0
	print V_BE^M
	$2 = (value => 126, another_value => 12, color => red)^M
	(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE
	...

	The test-case contains a corresponding kfail:
	...
	 # This requires a compiler fix that is in GCC 14.
	 if {[gcc_major_version] < 14} {
	     setup_kfail "DW_AT_endianity on enum types" *-*-*
	 }
	...
	which doesn't trigger because it checks the gcc version rather than the
	gnatmake version.

	Fix this by checking the gnatmake version instead.

	Tested on aarch64-linux and x86_64-linux.

2025-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require can_spawn_for_attach in gdb.base/gstack.exp
	I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope
	set to 1 and ran into:
	...
	PASS: gdb.base/gstack.exp: spawn gstack
	ptrace: Operation not permitted.^M
	GSTACK-END^M
	PASS: gdb.base/gstack.exp: gstack exits with no error
	PASS: gdb.base/gstack.exp: gstack's exit status is 0
	FAIL: gdb.base/gstack.exp: got backtrace
	...

	Fix this by requiring can_spawn_for_attach.

	Tested on x86_64-linux.

2025-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require supports_process_record in gdb.reverse/test_ioctl_TCSETSW.exp
	I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got:
	...
	(gdb) record full^M
	Process record: the current architecture doesn't support record function.^M
	(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full
	...

	Fix this by requiring supports_process_record.

	Tested on riscv64-linux and x86_64-linux.

2025-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp for !supports_catch_syscall
	I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got:
	...
	(gdb) catch syscall write^M
	The feature 'catch syscall' is not supported on this architecture yet.^M
	(gdb) FAIL: $exp: mode=syscall: catch syscall write
	...

	Fix this by checking for supports_catch_syscall.

	Tested on riscv64-linux and x86_64-linux.

2025-01-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32085 Source file not recognized for gcc 11.4.0-compiled code
	gprofng cannot read compressed section.
	In the next release we plan to use libbfd everywhere instead of our ELF reader.
	But in this release I use bfd_get_full_section_contents() only
	when bfd_is_section_compressed() returns true.

	gprofng/ChangeLog
	2025-01-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/32085
		* src/Elf.cc: Use bfd_get_full_section_contents to decompress a section.
		* src/Elf.h: Define SEC_DECOMPRESSED.

2025-01-08  Liwei Xu  <liwei.xu@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AMX-FP8
	In this patch, we will support AMX-FP8 feature. Since in the
	foreseeable future, only AMX-MOVRS will also use VEX_MAP5, we
	currently will not add a table of 256 entries and handle just
	like MAP7.

	gas/ChangeLog:

		* config/tc-i386.c: Add amx_fp8.
		* doc/c-i386.texi: Document .amx_fp8.
		* testsuite/gas/i386/x86-64.exp: Run AMX-FP8 tests.
		* testsuite/gas/i386/x86-64-amx-fp8-bad.d: New test.
		* testsuite/gas/i386/x86-64-amx-fp8-bad.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp8-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp8-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp8-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp8.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp8.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0): New.
		(X86_64_VEX_MAP5_FD): Ditto.
		(VEX_LEN_MAP5_FD_X86_64): Ditto.
		(VEX_W_MAP5_FD_X86_64_L_0):Ditto.
		(prefix_table): Add PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0.
		(x86_64_table): Add X86_64_VEX_MAP5_FD.
		(vex_len_table): Add VEX_LEN_MAP5_FD_X86_64.
		(vex_w_table): Add VEX_W_MAP5_FD_X86_64_L_0.
		* i386-gen.c: Add CPU_AMX_FP8_FLAGS and
		CPU_ANY_AMX_FP8_FLAGS.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h: Add cpuamx_fp8.
		* i386-opc.tbl: Add AMX_FP8 instructions.
		* i386-tbl.h: Regenerated.

2025-01-08  Tom Tromey  <tom@tromey.com>

	Rename two maint commands
	This renames two maint commands, removing a hyphen from
	"check-symtabs" and "check-psymtabs"; that is, moving them under the
	existing "maint check" prefix.

	Regression tested on x86-64 Fedora 40.

	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2025-01-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-07  Nick Clifton  <nickc@redhat.com>

	Updated Malay translation for the bfd sub-directory

2025-01-07  Tom Tromey  <tromey@adacore.com>

	Fix crash in DWARF indexer
	Iain pointed out a crash in the DWARF indexer when run on a certain D
	program.  The DWARF in this case has a nameless enum class; this
	causes an assertion failure.

	This patch arranges to simply ignore such types.  The fact that an
	enum class is nameless in this case appears to be a compiler bug.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518
	Approved-By: Tom de Vries <tdevries@suse.de>

2025-01-07  Christina Schimpe  <christina.schimpe@intel.com>

	testsuite: adapt to new --debug command line option
	Since commit "gdbserver: allow the --debug command line option to take a
	value", gdbserver no longer supports
	  --debug
	  --remote-debug
	  --event-loop-debug.

	Instead, --debug now takes a comma separated list of components.

	The make check parameter GDBSERVER_DEBUG doesn't support these changes
	yet.  This patch fixes this, by adding the --debug gdbserver arguments,
	as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for
	GDBSERVER_DEBUG.  Replay logging is still enabled by adding the
	"replay" GDBSERVER_DEBUG argument.  We can also configure "all" to
	enable all of the available options.

	Now, for instance, we can use it as follows:

	make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"

	or simply

	make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"

	to enable all debug options.

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-07  Tom Tromey  <tromey@adacore.com>

	Clarify documentation of signal numbers
	A user was confused by the meaning of signal numbers in the gdb CLI.
	For instance, when using "signal 3", exactly which signal is
	delivered?  Is it always 3, or is it always SIGQUIT?

	This patch attempts to clarify the documentation here.

2025-01-07  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: move board flags to ld_link
	Both CFLAGS and LDFLAGS provided by dejagnu board configuration could be
	required to perform a link.

	Up to now, those flags were pulled with run_cc_link_tests and
	run_ld_link_exec_tests and then passed to ld_link process as arguments.
	This means that calling `ld_link` outside those functions must remember
	to manually pass them.

2025-01-07  Clément Chigot  <chigot@adacore.com>

	ld/testsuite/lto: replace manual links by ld_link helper
	Some tests are calling run_host_cmd in order to retrieve the
	errors/warnings messages generated.
	ld_link is also making them available through exec_output global
	variable but as the advantages of taking the board configuration into
	account unlike run_host_cmd.

	ld/testsuite: centralize board_cflags and board_ldflags
	Those flags are retrieving the CFLAGS or LDFLAGS defined by the dejagnu
	board. The same pattern was repeated many times.

2025-01-07  Alan Modra  <amodra@gmail.com>

	Remove dead code in bfd_check_format_matches
	Commit cb001c0d283d made code added in 64bfc2584c01 dead.  Remove it.

2025-01-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-06  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Show LOC_CONST_BYTES var for info locals
	PR cli/32525 reports that a variable with this DWARF:
	..
	<2><423>: Abbrev Number: 14 (DW_TAG_variable)
	    <424>   DW_AT_name        : var1867
	    <42a>   DW_AT_type        : <0x2f8>
	    <42e>   DW_AT_const_value : 8 byte block: 0 0 0 0 0 0 0 0
	...
	is not shown by info locals.

	Fix this by handling LOC_CONST_BYTES in iterate_over_block_locals.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32525

	Approved-By: Tom Tromey <tom@tromey.com>

2025-01-06  Jan Beulich  <jbeulich@suse.com>

	x86/APX: simplify ENQCMD[,S} opcode table entries
	APX_F() makes sense to use only for dual VEX/EVEX templates; ENQCMD{,S}
	are legacy encoded though in their original forms. Make the entries
	match the MOVDIR{I,64B} sibling ones.

2025-01-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	Fix procfs.c compilation
	procfs.c compilation is currently broken on Solaris:

	/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
	/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
	 2067 |               wait_retval = gdb::wait (&wstat);
	      |                                  ^~~~
	In file included from ../gnulib/import/sys/wait.h:28,
	                 from /usr/include/stdlib.h:16,
	                 from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
	                 from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
	                 from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
	                 from <command-line>:
	/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
	   85 | extern pid_t wait(int *);
	      |              ^~~~
	/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
	 2154 |                         int temp = gdb::wait (&wstat);
	      |                                         ^~~~
	/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
	   85 | extern pid_t wait(int *);
	      |              ^~~~
	/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
	/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
	 2566 |       gdb::wait (NULL);
	      |            ^~~~
	/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
	   85 | extern pid_t wait(int *);
	      |              ^~~~

	The use of gdb::wait was introduced in

	commit 4e4dfc4728622d83c5d600949024449e21de868a
	Author: Tom de Vries <tdevries@suse.de>
	Date:   Fri Nov 22 17:44:29 2024 +0100

	    [gdb] Add gdb::wait

	but obviously never tested.

	Fixed by including gdbsupport/eintr.h to provide the declaration.

	Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.

2025-01-06  Jan Beulich  <jbeulich@suse.com>

	x86/Intel: don't accept memory operands with J*CXZ and LOOP*
	PR gas/31887

	Like for, in particular, J<cc> such should be rejected. Simplify the
	respective conditional in i386_intel_operand(), leveraging that
	JumpAbsolute will never occur in the first template of a mnemonic-
	specific group (thus making it unnecessary to exclude that one case).

	At this occasion do the same simplification later in the function as
	well: The resulting two operands will uniformly be invalid for all
	mnemonics other than CALL and JMP (and their AT&T counterparts, which
	we've been wrongly accepting in Intel syntax) anyway.

2025-01-06  Jan Beulich  <jbeulich@suse.com>

	gas: special-case division / modulo by ±1
	Dividing the largest possible negative value by -1 generally is UB, for
	the result not being representable at least in commonly used binary
	notation. This UB on x86, for example, is a Floating Point Exception on
	Linux, i.e. resulting in an internal error (albeit only when
	sizeof(valueT) == sizeof(void *); the library routine otherwise involved
	apparently deals with the inputs quite okay).

	Leave original values unaltered for division by 1; this may matter down
	the road, in case we start including X_unsigned and X_extrabit in
	arithmetic. For the same reason treat modulo by 1 the same as modulo by
	-1.

	The quad and octa tests have more relaxed expecations than intended, for
	X_unsigned and X_extrabit not being taken into account [yet]. The upper
	halves can wrongly end up as all ones (for .octa, when !BFD64, even the
	upper three quarters). Yet it makes little sense to address this just
	for div/mod by ±1. quad-div2 is yet more special, to cover for most
	32-bit targets being unable to deal with forward-ref expressions in
	.quad even when BFD64; even ones being able to (like x86) then still
	don't get the values right.

2025-01-06  Tom Tromey  <tromey@adacore.com>

	Handle linesStartAt1 in DAP
	The DAP initialize request has a "linesStartAt1" option, where the
	client can indicate that it prefers whether line numbers be 0-based or
	1-based.

	This patch implements this.  I audited all the line-related code in
	the DAP implementation.

	Note that while a similar option exists for column numbers, gdb
	doesn't handle these yet, so nothing is done here.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468

2025-01-06  Tom Tromey  <tromey@adacore.com>

	Don't lex floating-point number in Rust field expression
	Consider this Rust tuple:

	    let tuple_tuple = ((23i32, 24i32), 25i32);

	Here, the value is a tuple whose first element is also a tuple.
	You should be able to print this with:

	    (gdb) print tuple_tuple.0.1

	However, currently the Rust lexer sees "0.1" as a floating-point
	number.

	This patch fixes the problem by introducing a special case in the
	lexer: when parsing a field expression, the parser informs the lexer
	that a number should be handled as a decimal integer only.

	This change then lets us remove the decimal integer special case from
	lex_number.

	v2: I realized that the other DECIMAL_INTEGER cases aren't needed any
	more.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32472

2025-01-06  Tom Tromey  <tromey@adacore.com>

	Remove "then" from test suite
	This removes the "then" keyword from the test suite.  Andrew did this
	once before, but some new ones crept in.

	This also adds braces to the "if" conditions and normalizes the
	failures to just use "return".

2025-01-06  Tom Tromey  <tromey@adacore.com>

	Simplify traits.h using C++17
	This patch simplifies gdbsupport/traits.h by reusing some C++17 type
	traits.  I kept the local names, since they are generally better.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31423
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2025-01-06  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Use const_cast in fd_copy
	Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did:
	...
	 fd_copy (fd_set *dst, const fd_set *src, int n)
	 {
	   FD_ZERO (dst);
	   for (int i = 0; i < n; ++i)
	-    if (FD_ISSET (i, src))
	+    if (FD_ISSET (i, (fd_set *)src))
	...
	but according to [1] only const_cast may be used to cast away constness.

	Fix this by using const_cast.

	Tested by rebuilding on x86_64-linux.

	[1] https://en.cppreference.com/w/cpp/language/const_cast

2025-01-06  Alan Modra  <amodra@gmail.com>

	ar and foreign object files
	ar is supposed to make archives containing any sort of file, and it
	generally does that.  It also tries to make archives suited to target
	object files stored.  Some targets have peculiar archives.

	In one particular case we get into trouble trying to suit archives to
	object files: where the target object file is recognised but that
	target doesn't happen to support archives, and the default target has
	a special archive format.  For example, we'll get failures on
	rs6000-aix if trying to add tekhex objects to a new archive.  What
	happens in that the tekhex object is recognised and its target vector
	used to create an empty archive, ie. with _bfd_generic_mkarchive and
	_bfd_write_archive_contents.  An attempt is then made to open the
	newly created archive.  The tekhex target vector does not have a
	check_format function to recognise generic archives, nor as it happens
	do any of the xcoff or other targets built for rs6000-aix.

	It seems to me the simplest fix is to not use any target vector to
	create archives where that vector can't also recognise them.  That's
	what this patch does, and to reinforce that I've removed target vector
	support for creating empty archives from such targets.

	bfd/
		* i386msdos.c (i386_msdos_vec): Remove support for creating
		empty archives.
		* ihex.c (ihex_vec): Likewise.
		* srec.c (srec_vec, symbolsrec_vec): Likewise.
		* tekhex.c (tekhex_vec): Likewise.
		* wasm-module.c (wasm_vec): Likewise.
		* ptrace-core.c (core_ptrace_vec): Tidy.
		* targets.c (bfd_target_supports_archives): New inline function.
		* bfd-in2.h: Regenerate.
	binutils/
		* ar.c (open_inarch): Don't select a target from the first
		object file that can't read archives.  Set output_filename
		earlier.
		* testsuite/binutils-all/ar.exp (thin_archive_with_nested):
		Don't repeat --thin test using T.
		(foreign_object): New test.
		* testsuite/binutils-all/tek1.obj,
		* testsuite/binutils-all/tek2.obj: New files.

2025-01-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Eliminate redundant instruction macro
	include/ChangeLog:

		* opcode/riscv.h: Eliminate redundant instruction macro M_j.

2025-01-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-05  Tom Tromey  <tom@tromey.com>

	Some small cleanups in add_symbol_overload_list_qualified
	This applies some more cleanups to add_symbol_overload_list_qualified,
	consolidating calls to get_selected_block.

	It also moves the symtab expansion call after the code that walks up
	from the selected block, merging two loops.

2025-01-05  Tom Tromey  <tom@tromey.com>

	Fix latent bug in Ada import symbol handling
	The code in dwarf2/read.c:new_symbol that handles Ada 'import' symbols
	has a bug.  It uses the current scope, which by default this is the
	file scope -- even for a global symbol like:

	 <1><1186>: Abbrev Number: 4 (DW_TAG_variable)
	    <1187>   DW_AT_name        : (indirect string, offset: 0x1ad2): pkg__imported_var_ada
	...
	    <1196>   DW_AT_external    : 1

	This disagrees with the scope computed by the DWARF indexer.

	Now, IMO new_symbol and its various weirdness really has to go.  And,
	ideally, this information would come from the indexer rather than
	perhaps being erroneously recomputed.  But meanwhile, this patch fixes
	the issue at hand.

	This came up while working on another change that exposes the bug.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2025-01-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.python/py-commands-breakpoint.exp
	A recent discussion about what commands are allowed during
	gdb.Breakpoint.stop, made me wonder if there would be less restrictions if
	we'd do those commands as part of a breakpoint command list instead.

	Attribute gdb.Breakpoint.commands is a string with gdb commands, so I
	tried implementing a new class PyCommandsBreakpoint, derived from
	gdb.Breakpoint, that supports a py_commands method.

	My original idea was to forbid setting PyCommandsBreakpoint.commands, and do:
	...
	    def py_commands(self):
	        print("VAR: %d" % self.var)
	        self.var += 1
		gdb.execute("continue")
	...
	but as it turns out 'gdb.execute("continue")' does not behave the same way as
	continue.  I've filed PR python/32454 about this.

	So the unsatisfactory solution is to first execute
	PyCommandsBreakpoint.py_commands:
	...
	    def py_commands(self):
	        print("VAR: %d" % self.var)
	        self.var += 1
	...
	and then:
	...
	        self.commands = "continue"
	...

	I was hoping for a better outcome, but having done the work of writing this, I
	suppose it has use as a test-case, perhaps also as an example of how to work
	around PR python/32454.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32454

2025-01-04  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.base/finish-pretty.exp on s390x
	On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into:
	...
	(gdb) finish
	Run till exit from #0  foo () at finish-pretty.c:28
	main () at finish-pretty.c:40
	40	  return v.a + v.b;
	Value returned has type: struct s. Cannot determine contents
	(gdb) FAIL: $exp: finish foo prettyprinted function result
	...

	The function being finished is foo, which returns a value of type struct s.

	The ABI [1] specifies:
	- that the value is returned in a storage buffer allocated by the caller, and
	- that the address of this buffer is passed as a hidden argument in r2.

	GDB fails to print the value when finishing foo, because it doesn't know the
	address of the buffer.

	Implement the gdbarch_get_return_buf_addr hook for s390x to fix this.

	This is based on ppc_sysv_get_return_buf_addr, the only other implementation
	of gdbarch_get_return_buf_addr.  For readability I've factored out
	dwarf_reg_on_entry.

	There is one difference with ppc_sysv_get_return_buf_addr: only
	NO_ENTRY_VALUE_ERROR is caught.  If this patch is approved, I intend to submit
	a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well.

	The hook is not guaranteed to work, because it attempts to get the value r2
	had at function entry.

	The hook can be called after function entry, and the ABI doesn't guarantee
	that r2 is the same throughout the function.

	Using -fvar-tracking adds debug information, which allows the hook to succeed
	more often, and indeed after adding this to the test-case, it passes.

	Do likewise in one more test-case.

	Tested on s390x-linux.

	Fixes:
	- gdb.ada/finish-large.exp
	- gdb.base/finish-pretty.exp
	- gdb.base/retval-large-struct.exp
	- gdb.cp/non-trivial-retval.exp
	- gdb.ada/array_return.exp

	AFAICT, I've also enabled the hook for s390 and from the ABI I get the
	impression that it should work, but I haven't been able to test it.

	[1] https://github.com/IBM/s390x-abi

2025-01-04  Eli Zaretskii  <eliz@gnu.org>

	[gdb/readline] Fix link error on MinGW due to missing 'alarm'
	  The previous solution used symbols that exist only in MinGW64.
	  Add a stub implementation of 'alarm' for mingw.org's MinGW.

2025-01-04  Eli Zaretskii  <eliz@gnu.org>

	[gdb/selftest] Fix 'help_doc_invariants' self-test
	  Running selftest help_doc_invariants.
	  help doc broken invariant: command 'signal-event' help doc has over-long line
	  Self test failed: self-test failed at unittests/command-def-selftests.c:121

	  The reason is that doc string of 'signal-event' doesn't have
	  newlines at end of its line.  Fix by adding newlines.

2025-01-04  Eli Zaretskii  <eliz@gnu.org>

	[gdb] Fix compilation error in event-top.c
	       CXX    event-top.o
	     In file included from d:\usr\include\winsock2.h:69,
			      from ./../gdbsupport/gdb_select.h:30,
			      from event-top.c:43:
	     event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
	     event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
	      1279 |     if (FD_ISSET (i, src))
		   |                      ^
		   |                      |
		   |                      const fd_set*
	     d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
	       164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
		   |                                          ~~~~~~~~^~~~~

	  Use an explicit type cast to prevent this.

	      * gdb/event-top.c (fd_copy): Type-cast in call to FD_ISSET.

2025-01-04  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Warn about forced return from signal trampoline
	The Linaro CI reported a regression on arm-linux in test-case
	gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply
	workaround for PR gas/31115 a bit more") [1]:
	...
	(gdb) return^M
	Make __default_sa_restorer return now? (y or n) n^M
	Not confirmed^M
	(gdb) FAIL: $exp: return from handleri: \
	  leave signal trampoline (got interactive prompt)
	...

	After installing package glibc-debuginfo and adding --with-separate-debug-dir
	to the configure flags, I managed to reproduce the FAIL.

	The regression seems to be a progression in the sense that the function name
	for the signal trampoline is found.

	After reading up on the signal trampoline [2] and the return command [3], my
	understanding is that forced returning from the signal trampoline is
	potentially unsafe, given that for instance the process signal mask won't be
	restored.

	Fix this by:
	- rather than using the name, using "signal trampoline" in the query, and
	- adding a warning about returning from a signal trampoline,
	giving us:
	...
	(gdb) return^M
	warning: Returning from signal trampoline does not fully restore pre-signal \
	  state, such as process signal mask.^M
	Make signal trampoline return now? (y or n) y^M
	87            dummy = 0; dummy = 0; while (!done);^M
	(gdb) PASS: $exp: return from handleri: leave signal trampoline (in main)
	...

	Tested on x86_64-linux.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

	[1] https://linaro.atlassian.net/browse/GNU-1459
	[2] https://man7.org/linux/man-pages/man2/sigreturn.2.html
	[3] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Returning.html

2025-01-04  Alan Modra  <amodra@gmail.com>

	ELF sec_info memory leaks
	Use the bfd's objalloc memory so we don't need to free anything
	attached to elf_section_data sec_info.  Other uses of sec_info that
	need to allocate memory already use bfd_alloc.

		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc sec_info.
		* elf-sframe.c (_bfd_elf_parse_sframe): Likewise.

2025-01-04  Alan Modra  <amodra@gmail.com>

	_bfd_write_ar_hdr
	This has been broken since commit 8f95b6e44955 in 2010, and apparently
	nobody has noticed.  How we write archive headers depends on the
	archive, not the contents.

		* libbfd-in.h (_bfd_write_ar_hdr): Correct.
		* libbfd.h: Regenerate.

2025-01-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Skip stabs board in make-check-all.sh
	I ran make-check-all.sh with gdb.linespec/explicit.exp, and the only problems
	were found with target board stabs.

	With target board unix the test-case runs in two seconds, but with target
	board stabs it takes 12 seconds due to a timeout.

	Stabs support in gdb has been unmaintained for a while, and there's an ongoing
	discussion to deprecate and remove it (PR symtab/31210).

	It seems unnecessary to excercise this unmaintained feature in
	make-check-all.sh, so drop it.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210

2025-01-04  Fangrui Song  <maskray@sourceware.org>

	skip -gfile: call fnmatch without FNM_FILE_NAME
	fnmatch is called with the FNM_FILE_NAME flag so that `skip -gfi /usr/*`
	doesn't match /usr/include/*.  This makes the file matching feature not
	useful for STL headers that reside in multiple directories.  In
	addition, the user cannot use a single `*` to match multiple leading
	path components.

	Let's drop the FNM_FILE_NAME flag and remove the assertion from
	gdb_filename_fnmatch (originally for the auto-load feature).

2025-01-04  Alan Modra  <amodra@gmail.com>

	bfd_set_input_error
	My recent change to closing archives showed some problems with the way
	we stash errors for archive elements.  The most obvious thing found
	by oss-fuzz, is that if output archive elements are closed during
	bfd_close of an archive, then we can't access the element filename
	when printing the element.  So change bfd_set_input_error to stash the
	entire error message instead of input bfd and input error.

		* bfd.c (input_bfd, input_error): Delete.
		(bfd_error, _bfd_error_buf): Move.
		(_bfd_clear_error_data): Move.  Make static.  Clear bfd_error too.
		(bfd_set_input_error): Print the error use bfd_asprintf here..
		(bfd_errmsg): ..not here.
		(bfd_init): Update.
		* opncls.c (bfd_close_all_done): Don't call _bfd_clear_error_data.
		* libbfd.h: Regenerate.

2025-01-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-03  Alan Modra  <amodra@gmail.com>

	macro nesting testcases
	Fix a bunch of regressions.  Don't start anything besides a label in
	first column, don't name macros the same as directives, and make
	labels global.

2025-01-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-02  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove the old archiver
	The first versions of Performance Analyzer archived only function names.
	This is no longer used. We need a real elf-file.

	gprofng/ChangeLog
	2025-01-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/LoadObject.cc: Remove LoadObject::read_archive.
		* src/LoadObject.h: Likewise.
		* src/data_pckts.h: Remove unused declarations.
		* src/parse.cc (process_seg_map_cmd): Don't look for the old archive.

2025-01-02  H.J. Lu  <hjl.tools@gmail.com>

	nesting[123].d: Replace Sone with Some in comment
		* testsuite/gas/macros/nesting1.d: Replace Sone with Some in
		comment.
		* testsuite/gas/macros/nesting2.d: Likewise.
		* testsuite/gas/macros/nesting3.d: Likewise.

2025-01-02  H.J. Lu  <hjl.tools@gmail.com>

	gas: Revert PR 32391 related commits to fix 3 regressions
	9f2e3c21f65 Fix the handling or arguments and macro pseudo-variables inside nested assembler macros.

	introduced 3 regressions of PR gas/32484, PR gas/32486 and PR gas/32487.
	Revert all PR 32391 related commits and add tests for PR gas/32484,
	PR gas/32486, PR gas/32487.

		PR gas/32484
		PR gas/32486
		PR gas/32487
		* testsuite/gas/macros/macros.exp: Run nesting1, nesting2 and
		nesting3.
		* testsuite/gas/macros/nesting1.d: New file.
		* testsuite/gas/macros/nesting1.s: Likewise.
		* testsuite/gas/macros/nesting2.d: Likewise.
		* testsuite/gas/macros/nesting2.s: Likewise.
		* testsuite/gas/macros/nesting3.d: Likewise.
		* testsuite/gas/macros/nesting3.s: Likewise.

2025-01-02  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AMX-TF32
	In this patch, we will support AMX-TF32. It is a simple ISA
	comparing to the previous ones, so there is no special handling.

	gas/ChangeLog:

		* config/tc-i386.c: Add amx_tf32.
		* doc/c-i386.texi: Document .amx_tf32.
		* testsuite/gas/i386/x86-64.exp: Run AMX-TF32 tests.
		* testsuite/gas/i386/x86-64-amx-tf32-bad.d: New test.
		* testsuite/gas/i386/x86-64-amx-tf32-bad.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-tf32-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-tf32-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-amx-tf32-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-tf32.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-tf32.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (PREFIX_VEX_0F3848_X86_64_W_0_L_0): New.
		(X86_64_VEX_0F3848): Ditto.
		(VEX_LEN_0F3848_X86_64_W_0): Ditto.
		(VEX_W_0F3848_X86_64): Ditto.
		(prefix_table): Add PREFIX_VEX_0F3848_X86_64_W_0_L_0.
		(x86_64_table): Add X86_64_VEX_0F3848.
		(vex_len_table): Add VEX_LEN_0F3848_X86_64_W_0.
		(vex_w_table): Add VEX_W_0F3848_X86_64.
		* i386-gen.c (isa_dependencies): Add AMX_TF32.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuAMX_TF32): New.
		(i386_cpu_flags): Add cpuamx_tf32.
		* i386-opc.tbl: Add AMX-TF32 instructions.
		* i386-tbl.h: Regenerated.

2025-01-02  Haochen Jiang  <haochen.jiang@intel.com>
	    Hu, Lin1  <lin1.hu@intel.com>

	Support Intel AMX-TRANSPOSE
	In this patch, we will support AMX-TRANSPOSE. Since AMX-TRANSPOSE
	will be used with other CPUIDs very often, we put it into
	CPU_FLAGS_COMMON.

	To implement TMM pair, we reused ImplicitGroup and adjust the condition
	in process_operands for the instructions.

	APX_F extension is also handled in this patch, where it extends
	T2RPNTLVW[Z0,Z1][,T1] to EVEX.128.NP/66.0F38.W0 6E/6F !(11):rrr:100
	with NF=0.

	Also, TTDPFP16PS should base on AMX_FP16, not AMX_BF16 in ISE055.
	It would be fixed in ISE056.

	gas/ChangeLog:

		* config/tc-i386.c (cpu_arch): Add amx_transpose.
		(_is_cpu): Ditto.
		(process_operands): Adjust the condition for AMX-TRANSPOSE.
		* doc/c-i386.texi: Document .amx_transpose.
		* testsuite/gas/i386/x86-64.exp: Run AMX-TRANSPOSE tests.
		* testsuite/gas/i386/x86-64-amx-transpose-bad.d: New test.
		* testsuite/gas/i386/x86-64-amx-transpose-bad.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-transpose-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-transpose-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-amx-transpose-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-transpose.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-transpose.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (MOD_VEX_0F386E_X86_64_W_0): New.
		(MOD_VEX_0F386F_X86_64_W_0): Ditto.
		(PREFIX_VEX_0F385F_X86_64_W_0_L_0): Ditto.
		(PREFIX_VEX_0F386B_X86_64_W_0_L_0): Ditto.
		(PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0): Ditto.
		(PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0): Ditto.
		(X86_64_VEX_0F385F): Ditto.
		(X86_64_VEX_0F386B): Ditto.
		(X86_64_VEX_0F386E): Ditto.
		(X86_64_VEX_0F386F): Ditto.
		(VEX_LEN_0F385F_X86_64_W_0): Ditto.
		(VEX_LEN_0F386B_X86_64_W_0): Ditto.
		(VEX_LEN_0F386E_X86_64_W_0_M_0): Ditto.
		(VEX_LEN_0F386F_X86_64_W_0_M_0): Ditto.
		(VEX_W_0F385F_X86_64): Ditto.
		(VEX_W_0F386B_X86_64): Ditto.
		(VEX_W_0F386E_X86_64): Ditto.
		(VEX_W_0F386F_X86_64): Ditto.
		(mod_table): Add MOD_VEX_0F386E_X86_64_W_0,
		MOD_VEX_0F386F_X86_64_W_0.
		(prefix_table): Add PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0,
		PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0.
		Add new instructions for PREFIX_VEX_0F386C_X86_64_W_0_L_0.
		(x86_64_table): Add X86_64_VEX_0F385F, X86_64_VEX_0F386B,
		X86_64_VEX_0F386E, X86_64_VEX_0F386F.
		(vex_len_table): Add VEX_LEN_0F385F_X86_64_W_0,
		VEX_LEN_0F386B_X86_64_W_0, VEX_LEN_0F386E_X86_64_W_0_M_0,
		VEX_LEN_0F386F_X86_64_W_0_M_0.
		(vex_w_table): Add VEX_W_0F385F_X86_64, VEX_W_0F386B_X86_64,
		VEX_W_0F386E_X86_64, VEX_W_0F386F_X86_64.
		* i386-gen.c (cpu_flag_init): Add AMX_TRANSPOSE.
		(cpu_flags): Add CpuAMX_TRANSPOSE.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuAMX_TRANSPOSE): New.
		(i386_cpu): Add cpuamx_transpose.
		* i386-opc.tbl: Add AMX-TRANSPOSE instructions.
		* i386-tbl.h: Regenerated.

2025-01-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2025-01-01  Alan Modra  <amodra@gmail.com>

	readelf memory leaks
	This fixes multiple readelf memory leaks:
	- The check functions used to validate separate debug info files
	  opened and read file data but didn't release the memory nor close
	  the file.
	- A string table was being re-read into a buffer, leaking the old
	  contents.
	- Decompressed section contents leaked.

		* dwarf.c (check_gnu_debuglink): Always call close_debug_file.
		(check_gnu_debugaltlink): Likewise.
		* readelf.c (process_section_headers): Don't read string_table
		again if we already have it.
		(maybe_expand_or_relocate_section): Add decomp_buf param to
		return new uncompressed buffer.
		(dump_section_as_strings, filedata->string_table): Free any
		uncompressed buffer.
		(process_file): Call close_debug_file rather than freeing
		various filedata components.

2025-01-01  Alan Modra  <amodra@gmail.com>

	objdump sym memory leak
	The sym array should be freed even with a symcount of zero.

		* objdump.c (dump_bfd): Free syms before replacing with
		extra_syms.  Free extra_syms after adding to syms.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gnu_debuglink related memory leak
		* opncls.c (bfd_fill_in_gnu_debuglink_section): Free section
		contents on success too.

2025-01-01  Alan Modra  <amodra@gmail.com>

	Close elements of output archive
	When cleaning up an archive, close all its elements.  This fixes a
	number of ar memory leaks.

	bfd/
		* archive.c (_bfd_archive_close_and_cleanup): Close elements
		of an archive open for writing.
	binutils/
		* objcopy.c (copy_archive): Don't close output archive
		elements here.
		* dlltool.c (gen_lib_file): Likewise.
	ld/
		* pe-dll.c (pe_dll_generate_implib): Don't close output
		archive elements here.

2025-01-01  Alan Modra  <amodra@gmail.com>

	ar.c memory leak fixme
	Cure the leak by always mallocing the string in output_filename,
	and freeing the old one any time we assign output_filename.

2025-01-01  Alan Modra  <amodra@gmail.com>

	bfdtest1 loop check
	Add a check that next_archived_file doesn't return the same element.
	Seen with the following, which I think shows a bug with "ar r" and
	thin archives as you get two copies of artest.a in artest2.a.

	$ rm tmpdir/artest*
	$ ./ar rc tmpdir/artest.a tmpdir/bintest.o
	$ ./ar rcT tmpdir/artest2.a tmpdir/artest.a
	$ ./bfdtest1 tmpdir/artest.a
	$ ./bfdtest1 tmpdir/artest2.a
	$ ./ar rcT tmpdir/artest2.a tmpdir/artest.a
	$ ./bfdtest1 tmpdir/artest2.a
	oops: next_archived_file

2025-01-01  Alan Modra  <amodra@gmail.com>

	thin archive with nested archive memory leak
	The only reason to keep new_areldata around was for access to the
	filename, but we now always take a copy in alloc'd memory.

		* archive.c (_bfd_get_elt_at_filepos): Free new_areldata when
		it is not attached to bfd.

2025-01-01  Alan Modra  <amodra@gmail.com>

	memory leak in gas dwarf2dbg.c
	Found when running the pr27355 testcase.

		PR 27355
		PR 27426
		* dwarf2dbg.c (allocate_filename_to_slot): Update dirs_in_use.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas obj-elf.c memory leaks
		* config/obj-elf.c (obj_elf_section): Use notes_memdup for
		linked_to_symbol_name.
		(obj_elf_find_and_add_versioned_name): Use notes_alloc for
		versioned_name.

	PR 32391 memory leak
		* macro.c (sub_actual): Free newadd.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas reloc_list memory leaks
	Put these on the notes obstack too.

		* config/tc-wasm32.c (wasm32_leb128): Use notes_alloc for
		reloc_list vars.
		* read.c (s_reloc): Likewise.
		* write.c (create_note_reloc): Likewise.
		(write_object_file): Reset reloc_list after write_relocs.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas tc_gen_reloc memory leaks
	This makes all the tc_gen_reloc functions and the associated array in
	write.c:write_relocs use notes_alloc rather than malloc.  tc-hppa.c
	tc_gen_reloc gets a few more changes, deleting some dead code, and
	tidying code that duplicates prior initialisation.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas gen-sframe memory leaks
	More freeing required.

		* gen-sframe.c (all_sframe_fdes, last_sframe_fde): Move earlier,
		make file scope.
		(sframe_row_entry_new): Move earlier.
		(sframe_row_entry_free): New function.
		(sframe_fde_alloc, sframe_fde_free): Move earlier.
		(sframe_fde_link): Delete.  Expand into..
		(create_sframe_all): ..here.
		(output_sframe_internal): Delete silly sframe_flags init.
		Free fdes.  Reset static vars.
		(sframe_xlate_ctx_cleanup): Use sframe_row_entry_free.  Free
		remember_fre too.  Don't re-init xlate_ctx we're about to drop.
		* gen-sframe.h (all_sframe_fdes): Don't declare.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas dw2gencfi memory leaks
	Some of these could have remained as malloc'd memory, but that would
	require quite a bit of code to traverse frch_cfi_data for example, and
	would rely on matching cfi directives (ie. valid input).  Just put
	them on the notes obstack instead.

		* dw2gencfi.c (alloc_fde_entry): Use notes_calloc.
		(alloc_cfi_insn_data): Likewise.
		(cfi_end_fde): Don't free frch_cfi_data.
		(cfi_add_label): Use notes_strdup.
		(cfi_add_CFA_remember_state): Use notes_alloc.
		(cfi_add_CFA_restore_state): Don't free.
		(dot_cfi_escape): Use notes_alloc.
		(cfi_finish): Free cies after each pass, not before.  Clear
		out static vars too.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas include_dirs memory leak
	This is the first of a series of patches aimed at making it possible
	to configure with CFLAGS="-g -O2 -fsanitize=address,undefined" and run
	the binutils and gas testsuite on x86_64-linux without using
	ASAN_OPTIONS=detect_leaks=0.  ie. the patch series is aimed at fixing
	common gas, ar, objcopy, objdump, and readelf leaks.

		* config/tc-tic54x.c (md_begin): Make use of notes_strdup rather
		than xstrdup to copy entries added to include_dirs.
		* read.c (read_end): Free include_dirs array.

2025-01-01  Alan Modra  <amodra@gmail.com>

	gas totalfrags
	Avoid any possibility of signed overflow.  (Seen on oss-fuzz).

		* frags.c (totalfrags): Make unsigned.
		(get_frag_count): Return unsigned.
		* frags.h (get_frag_count): Likewise.

2025-01-01  Alan Modra  <amodra@gmail.com>

	PR 32507, PRIx64 in error messages on 32-bit mingw
	People, including me, had forgotten that the bfd_error_handler just
	handled standard printf format strings, not MSC %I64 and suchlike.
	Using PRIx64 and similar in errors does not work if the host compiler
	headers define those formats as the Microsoft %I64 variety.  (We
	handled %ll OK, editing it to %I64 on such hosts.)

		PR 32507
		* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
		in input strings if the host defines PRId64 as "I64d".
		Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
		a preprocessor define.

2025-01-01  Alan Modra  <amodra@gmail.com>

	Regen gprofng after copyright update

	Update year range in copyright notice of binutils files

2025-01-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-31  Tom Tromey  <tom@tromey.com>

	Use 'flags' when expanding symtabs in gdbpy_lookup_static_symbols
	This changes gdbpy_lookup_static_symbols to pass the 'flags' parameter
	to expand_symtabs_matching.  This should refine the search somewhat.
	Note this is "just" a performance improvement, as the loop over
	symtabs already checks 'flags'.

	v2 also removes 'SEARCH_GLOBAL_BLOCK' and updates py-symbol.exp to
	verify that this works properly.  Thanks to Tom for this insight.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

2024-12-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-29  Joel Brobecker  <brobecker@adacore.com>

	Update gdb/NEWS after GDB 16 branch creation.
	This commit a new section for the next release branch, and renames
	the section of the current branch, now that it has been cut.

2024-12-29  Joel Brobecker  <brobecker@adacore.com>

	Bump version to 17.0.50.DATE-git.
	Now that the GDB 16 branch has been created,
	this commit bumps the version number in gdb/version.in to
	17.0.50.DATE-git

	For the record, the GDB 16 branch was created
	from commit ee29a3c4ac7adc928ae6ed1fed3b59c940a519a4.

	Also, as a result of the version bump, the following changes
	have been made in gdb/testsuite:

		* gdb.base/default.exp: Change $_gdb_major to 17.

2024-12-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-27  Jan Beulich  <jbeulich@suse.com>

	bfd/ELF: refine segment index in filepos assignment diag
	Reporting an internal loop index isn't helpful for the user to determine
	which segment the problem is with. Report the PHDR index instead.

	ld/testsuite: replace aarch64 uses of load_lib
	Using $srcdir/$subdir directly doesn't work, at least not with expect
	5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
	aspect which is crucial here). Make use of load_file instead.

2024-12-27  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Reword message for unresolvable relocs
	For PDE, "recompiling with -fPIE" just makes no sense.

	For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
	relocs, but not unresolveable PC-relative relocs: if the reloc is
	already PC-relative, the problem is not the reloc is PC-relative or
	absolute, but the reloc is not applicable for external symbols.

	If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
	reloc in PIE, it means the programmer has somehow wrongly instructed the
	compiler to treat external symbols as local symbols.  A misuse of
	-mdirect-extern-access can cause the issue, so we can suggest
	-mno-direct-extern-access.  And in all cases (DSO/PIE/PDE) a mismatching
	symbol visibility can also cause the issue, so we should also suggest to
	check the visibility.

2024-12-27  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE
	In a static PIE, undefined weak symbols should be just resolved to
	runtime address 0, like those symbols with non-default visibility.  This
	was silently broken in all prior Binutils releases with "-static-pie
	-mdirect-extern-access":

	    $ cat t.c
	    int x (void) __attribute__ ((weak));

	    int
	    main (void)
	    {
	      __builtin_printf("%p\n", x);
	    }
	    $ gcc t.c -static-pie -mdirect-extern-access
	    $ ./a.out
	    0x7ffff1d64000

	Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for
	shared libraries), the situation has been improved: the linker errors
	out instead of silently producing a wrong output file.

	But logically, using -mdirect-extern-access for a static PIE perfectly
	makes sense, and we should not prevent that even if the programmer uses
	weak symbols.  Linux kernel is such an example, and Linux < 6.10 now
	fails to build with Binutils trunk.  (The silent breakage with prior
	Binutils releases was "benign" due to some blind luck.)

	While since the 6.10 release Linux has removed those potentially
	undefined weak symbols (due to performance issue), we still should
	support weak symbols in -mdirect-extern-access -static-pie and unbreak
	building old kernels.

	Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/

2024-12-27  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Fix resolution of undefined weak hidden/protected symbols
	An undefined weak hidden/protect symbol should be resolved to runtime
	address 0, but we were actually resolving it to link-time address 0.  So
	in PIE or DSO the runtime address would be incorrect.

	Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
	The latter does not always work because the immediate field of addi.w is
	narrower, report an error in the case the addend is too large.

2024-12-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-25  Alan Modra  <amodra@gmail.com>

	macro.c:871 heap-buffer-overflow
	PR 32391 commit 9f2e3c21f6 fallout again.  Also fix another 'macro'
	may be used uninitialized.

2024-12-25  Alan Modra  <amodra@gmail.com>

	buffer overflow in gas/app.c
	This testcase:
	 .irp x x x "
	 .end #
	 .endr
	manages to access lex[EOF].

	xxx: Warning: end of file in string; '"' inserted
	xxx:1: Warning: missing closing `"'
	gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
	Following that there is a buffer overflow.

	Stop this happening, and in other similar places, by checking for EOF.

2024-12-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add some xfail in gdb.base/startup-with-shell.exp
	There are two tests that fail in gdb.base/startup-with-shell.exp when
	using the native-extended-remote board.  I plan to fix these issues,
	and I've posted a series that does just that:

	  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

	But until that series is reviewed, I thought I'd merge this commit,
	which marks the FAIL as XFAIL and links them to the relevant bug
	number.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392

	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/freebsd: port core file context parsing to FreeBSD
	This commit implements the gdbarch_core_parse_exec_context method for
	FreeBSD.

	This is much simpler than for Linux.  On FreeBSD, at least the
	version (13.x) that I have installer, there are additional entries in
	the auxv vector that point directly to the argument and environment
	vectors, this makes it trivial to find this information.

	If these extra auxv entries are not available on earlier FreeBSD, then
	that's fine.  The fallback behaviour will be for GDB to act as it
	always has up to this point, you'll just not get the extra
	functionality.

	Other differences compared to Linux are that FreeBSD has
	AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is
	the full path to the executable.  On Linux AT_EXECFN is the command
	the user typed, so this can be a relative path.

	This difference is handy as on FreeBSD we don't parse the mapped files
	from the core file (are they even available?).  So having the EXECPATH
	means we can use that as the absolute path to the executable.

	However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be
	the absolute path to the symlink, not to the underlying file.  This is
	probably a good thing, but it does mean there is one case we test on
	Linux that fails on FreeBSD.

	On Linux if we create a symlink to an executable, then run the symlink
	and generate a corefile.  Now delete the symlink and load the core
	file.  On Linux GDB will still find (and open) the original
	executable.  This is because we use the mapped file information to
	find the absolute path to the executable, and the mapped file
	information only stores the real file names, not symlink names.

	This is a total edge case, I only added the deleted symlink test
	originally because I could see that this would work on Linux.  Though
	it is neat that Linux finds this, I don't feel too bad that this fails
	on FreeBSD.

	Other than this, everything seems to work on x86-64 FreeBSD (13.4)
	which is all I have setup right now.  I don't see why other
	architectures wouldn't work too, but I haven't tested them.

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve GDB's ability to auto-load the exec for a core file
	GDB already has a limited mechanism for auto-loading the executable
	corresponding to a core file, this can be found in the function
	locate_exec_from_corefile_build_id in corelow.c.

	However, this approach uses the build-id of the core file to look in
	either the debug directory (for a symlink back to the executable) or
	by asking debuginfod.  This is great, and works fine if the core file
	is a "system" binary, but often, when I'm debugging a core file, it's
	part of my development cycle, so there's no build-id symlink in the
	debug directory, and debuginfod doesn't know about the binary either,
	so GDB can't auto load the executable....

	... but the executable is right there!

	This commit builds on the earlier commits in this series to make GDB
	smarter.

	On GNU/Linux, when we parse the execution context from the core
	file (see linux-tdep.c), we already grab the command pointed to by
	AT_EXECFN.  If this is an absolute path then GDB can use this to
	locate the executable, a build-id check ensures we've found the
	correct file.  With this small change GDB suddenly becomes a lot
	better at auto-loading the executable for a core file.

	But we can do better!  Often the AT_EXECFN is not an absolute path.

	If it is a relative path then we check for this path relative to the
	core file.  This helps if a user does something like:

	  $ ./build/bin/some_prog
	  Aborted (core dumped)
	  $ gdb -c corefile

	In this case the core file in the current directory will have an
	AT_EXECFN value of './build/bin/some_prog', so if we look for that
	path relative to the location of the core file this might result in a
	hit, again, a build-id check ensures we found the right file.

	But we can do better still!  What if the user moves the core file?  Or
	the user is using some tool to manage core files (e.g. the systemd
	core file management tool), and the user downloads the core file to a
	location from which the relative path no longer works?

	Well in this case we can make use of the core file's mapped file
	information (the NT_FILE note).  The executable will be included in
	the mapped file list, and the path within the mapped file list will be
	an absolute path.  We can search for mapped file information based on
	an address within the mapped file, and the auxv vector happens to
	include an AT_ENTRY value, which is the entry address in the main
	executable.  If we look up the mapped file containing this address
	we'll have the absolute path to the main executable, a build-id check
	ensures this really is the file we're looking for.

	It might be tempting to jump straight to the third approach, however,
	there is one small downside to the third approach: if the executable
	is a symlink then the AT_EXECFN string will be the name of the
	symlink, that is, the thing the user asked to run.  The mapped file
	entry will be the name of the actual file, i.e. the symlink target.
	When we auto-load the executable based on the third approach, the file
	loaded might have a different name to that which the user expects,
	though the build-id check (almost) guarantees that we've loaded the
	correct binary.

	But there's one more thing we can check for!

	If the user has placed the core file and the executable into a
	directory together, for example, as might happen with a bug report,
	then neither the absolute path check, nor the relative patch check
	will find the executable.  So GDB will also look for a file with the
	right name in the same directory as the core file.  Again, a build-id
	check is performed to ensure we find the correct file.

	Of course, it's still possible that GDB is unable to find the
	executable using any of these approaches.  In this case, nothing
	changes, GDB will check in the debug info directory for a build-id
	based link back to the executable, and if that fails, GDB will ask
	debuginfod for the executable.  If this all fails, then, as usual, the
	user is able to load the correct executable with the 'file' command,
	but hopefully, this should be needed far less from now on.

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: make some of the core file / build-id tests harder
	We have a few tests that load core files, which depend on GDB not
	auto-loading the executable that matches the core file.  One of these
	tests (corefile-buildid.exp) exercises GDB's ability to load the
	executable via the build-id links in the debug directory, while the
	other two tests are just written assuming that GDB hasn't auto-loaded
	the executable.

	In the next commit, GDB is going to get better at finding the
	executable for a core file, and as a consequence these tests could
	start to fail if the testsuite is being run using a compiler that adds
	build-ids by default, and is on a target (currently only Linux) with
	the improved executable auto-loading.

	To avoid these test failures, this commit updates some of the tests.

	coredump-filter.exp and corefile.exp are updated to unload the
	executable should it be auto-loaded.  This means that the following
	output from GDB will match the expected patterns.  If the executable
	wasn't auto-loaded then the new step to unload is harmless.

	The corefile-buildid.exp test needed some more significant changes.
	For this test it is important that the executable be moved aside so
	that GDB can't locate it, but we do still need the executable around
	somewhere, so that the debug directory can link to it.  The point of
	the test is that the executable _should_ be auto-loaded, but using the
	debug directory, not using GDB's context parsing logic.

	While looking at this test I noticed two additional problems, first we
	were creating the core file more times than we needed.  We only need
	to create one core file for each test binary (total two), while we
	previously created one core file for each style of debug info
	directory (total four).  The extra core files should be identical, and
	were just overwriting each other, harmless, but still pointless work.

	The other problem is that after running an earlier test we modified
	the test binary in order to run a later test.  This means it's not
	possible to manually re-run the first test as the binary for that test
	is destroyed.

	As part of the rewrite in this commit I've addressed these issues.

	This test does change many of the test names, but there should be no
	real changes in what is being tested after this commit.  However, when
	the next commit is added, and GDB gets better at auto-loading the
	executable for a core file, these tests should still be testing what
	is expected.

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: parse and set the inferior environment from core files
	Extend the core file context parsing mechanism added in the previous
	commit to also store the environment parsed from the core file.

	This environment can then be injected into the inferior object.

	The benefit of this is that when examining a core file in GDB, the
	'show environment' command will now show the environment extracted
	from a core file.

	Consider this example:

	  $ env -i GDB_TEST_VAR=FOO ./gen-core
	  Segmentation fault (core dumped)
	  $ gdb -c ./core.1669829
	  ...
	  [New LWP 1669829]
	  Core was generated by `./gen-core'.
	  Program terminated with signal SIGSEGV, Segmentation fault.
	  #0  0x0000000000401111 in ?? ()
	  (gdb) show environment
	  GDB_TEST_VAR=foo
	  (gdb)

	There's a new test for this functionality.

2024-12-24  Andrew Burgess  <aburgess@redhat.com>

	gdb: add gdbarch method to get execution context from core file
	Add a new gdbarch method which can read the execution context from a
	core file.  An execution context, for this commit, means the filename
	of the executable used to generate the core file and the arguments
	passed to the executable.

	In later commits this will be extended further to include the
	environment in which the executable was run, but this commit is
	already pretty big, so I've split that part out into a later commit.

	Initially this new gdbarch method is only implemented for Linux
	targets, but a later commit will add FreeBSD support too.

	Currently when GDB opens a core file, GDB reports the command and
	arguments used to generate the core file.  For example:

	  (gdb) core-file ./core.521524
	  [New LWP 521524]
	  Core was generated by `./gen-core abc def'.

	However, this information comes from the psinfo structure in the core
	file, and this struct only allows 80 characters for the command and
	arguments combined.  If the command and arguments exceed this then
	they are truncated.

	Additionally, neither the executable nor the arguments are quoted in
	the psinfo structure, so if, for example, the executable was named
	'aaa bbb' (i.e. contains white space) and was run with the arguments
	'ccc' and 'ddd', then when this core file was opened by GDB we'd see:

	  (gdb) core-file ./core.521524
	  [New LWP 521524]
	  Core was generated by `./aaa bbb ccc ddd'.

	It is impossible to know if 'bbb' is part of the executable filename,
	or another argument.

	However, the kernel places the executable command onto the user stack,
	this is pointed to by the AT_EXECFN entry in the auxv vector.
	Additionally, the inferior arguments are all available on the user
	stack.  The new gdbarch method added in this commit extracts this
	information from the user stack and allows GDB to access it.

	The information on the stack is writable by the user, so a user
	application can start up, edit the arguments, override the AT_EXECFN
	string, and then dump core.  In this case GDB will report incorrect
	information, however, it is worth noting that the psinfo structure is
	also filled (by the kernel) by just copying information from the user
	stack, so, if the user edits the on stack arguments, the values
	reported in psinfo will change, so the new approach is no worse than
	what we currently have.

	The benefit of this approach is that GDB gets to report the full
	executable name and all the arguments without the 80 character limit,
	and GDB is aware which parts are the executable name, and which parts
	are arguments, so we can, for example, style the executable name.

	Another benefit is that, now we know all the arguments, we can poke
	these into the inferior object.  This means that after loading a core
	file a user can 'show args' to see the arguments used.  A user could
	even transition from core file debugging to live inferior debugging
	using, e.g. 'run', and GDB would restart the inferior with the correct
	arguments.

	Now the downside: finding the AT_EXECFN string is easy, the auxv entry
	points directly too it.  However, finding the arguments is a little
	trickier.  There's currently no easy way to get a direct pointer to
	the arguments.  Instead, I've got a heuristic which I believe should
	find the arguments in most cases.  The algorithm is laid out in
	linux-tdep.c, I'll not repeat it here, but it's basically a search of
	the user stack, starting from AT_EXECFN.

	If the new heuristic fails then GDB just falls back to the old
	approach, asking bfd to read the psinfo structure for us, which gives
	the old 80 character limited answer.

	For testing, I've run this series on (all GNU/Linux) x86-64. s390,
	ppc64le, and the new test passes in each case.  I've done some very
	basic testing on ARM which does things a little different than the
	other architectures mentioned, see ARM specific notes in
	linux_corefile_parse_exec_context_1 for details.

2024-12-24  Alan Modra  <amodra@gmail.com>

	arc: add_to_decodelist
	Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three
	entries to decodelist for each instruction disassembled.  That can
	waste a lot of cpu when the list grows large.  What's more,
	decodelist is static and nothing clears the list.  So the list
	persists from one file to the next if objdump is disassembling
	multiple files in one invocation.  Wrong disassembly might result.

	To fix this problem, I've moved decodelist to the arc private_data and
	made it an array.  I believe that init_disassemble_data will be
	called, clearing private_data, for each file disassembled.  That's
	certainly true for objdump, and if I can see my way around gdb
	constructors, it's also true for gdb.  I don't think there is a
	possibility of info.disassembler_options changing unless there is
	first a call to init_disassebled_data.  That means all of the option
	parsing and bfd mach and e_flags decoding need only be done when
	initialising the arc private_data.

		* arc-dis.c (addrtypenames_max, addrtypeunknown): Delete..
		(get_addrtype): ..substitute values here.  Tidy.
		(skipclass_t, linkclass, decodelist): Delete.
		(enforced_isa_mask, print_hex): Delete.
		(struct arc_disassemble_info): Add decode[], decode_count,
		isa_mask, print_hex.
		(init_arc_disasm_info): Tidy.
		(add_to_decodelist): Delete, replacing with..
		(add_to_decode): ..this.  Don't duplicate entries.
		(skip_this_opcode): Adjust to suit.
		(find_format_from_table, parse_option): Likewise.
		(parse_disassembler_options): Likewise.  Move code dealing
		with bfd mach and eflags from..
		(print_insn_arc): ..here.  Adjust for other changes.

2024-12-24  Alan Modra  <amodra@gmail.com>

	PR 32324, Stripping BOLT'ed binaries leads to unwanted behaviour
	This patch corrects layout for a PT_LOAD header that doesn't include
	the ELF file header but does contain PHDRs and sections requiring
	alignment.  The required alignment (which was missing) is placed
	before the PHDRs.

2024-12-24  Alan Modra  <amodra@gmail.com>

	PR 32391 testcase
	The new testcase results in these regressions:
	hppa64-hp-hpux11.23  +FAIL: Nested macros (PR 32391)
	hppa-hp-hpux10  +FAIL: Nested macros (PR 32391)
	i386-darwin  +FAIL: Nested macros (PR 32391)

	Fix the hppa regressions by ensuring that only symbols start on the
	first column.

2024-12-24  Alan Modra  <amodra@gmail.com>

	Fix error: macro may be used uninitialized
	PR 32391 commit 9f2e3c21f6 fallout

2024-12-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-23  Haochen Jiang  <haochen.jiang@intel.com>
	    Jun Zhang  <jun.zhang@intel.com>
	    Zewei Mo  <zewei.mo@intel.com>

	Support Intel AVX10.2 minmax, vector copy and compare instructions
	In this patch, we will support AVX10.2 minmax, vector copy and compare
	instructions. This will finish the new instruction form support for
	AVX10.2. Most of them are new instructions forms except for vmovd
	and vmovw, which are extended usage from the old ones.

	gas/ChangeLog:

		* NEWS: Mention AVX10.2.
		* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-256-5-intel.d: New test.
		* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-miscs.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-len.h: Add EVEX_LEN_0F7E_P_1_W_1,
		EVEX_LEN_0FD6_P_2_W_0, EVEX_LEN_MAP5_6E and EVEX_LEN_MAP5_7E.
		* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F2E, PREFIX_EVEX_0F2F,
		PREFIX_EVEX_0F3A52, PREFIX_EVEX_0F3A53, PREFIX_EVEX_MAP5_2E,
		PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_6E and PREFIX_EVEX_MAP5_7E.
		* i386-dis-evex-w.h: Adjust EVEX_W_0F3A42, EVEX_W_0F7E_P_1
		and EVEX_W_0FD6. Add EVEX_W_MAP5_6E_P_1 and EVEX_W_MAP5_7E_P_1.
		* i386-dis-evex.h: Add and adjust table entries for AVX10.2.
		* i386-dis.c (PREFIX_EVEX_0F2E): New.
		(PREFIX_EVEX_0F2F): Ditto.
		(PREFIX_EVEX_0F3A52): Ditto.
		(PREFIX_EVEX_0F3A53): Ditto.
		(PREFIX_EVEX_MAP5_2E): Ditto.
		(PREFIX_EVEX_MAP5_2F): Ditto.
		(PREFIX_EVEX_MAP5_6E_L_0): Ditto.
		(PREFIX_EVEX_MAP5_7E_L_0): Ditto.
		(EVEX_LEN_0F7E_P_1_W_1): Ditto.
		(EVEX_LEN_0FD6_P_2_W_0): Ditto.
		(EVEX_LEN_MAP5_6E): Ditto.
		(EVEX_LEN_MAP5_7E): Ditto.
		(EVEX_W_MAP5_6E_P_1): Ditto.
		(EVEX_W_MAP5_7E_P_1): Ditto.
		* i386-opc.tbl: Add AVX10.2 instructions.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-12-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-22  Carlos Galvez  <carlosgalvezp@gmail.com>

	Fix -Wenum-constexpr-conversion in enum-flags.h
	This fixes PR 31331:
	https://sourceware.org/bugzilla/show_bug.cgi?id=31331

	Currently, enum-flags.h is suppressing the warning
	-Wenum-constexpr-conversion coming from recent versions of Clang.
	This warning is intended to be made a compiler error
	(non-downgradeable) in future versions of Clang:

	https://github.com/llvm/llvm-project/issues/59036

	The rationale is that casting a value of an integral type into an
	enumeration is Undefined Behavior if the value does not fit in the
	range of values of the enum:
	https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766

	Undefined Behavior is not allowed in constant expressions, leading to
	an ill-formed program.

	In this case, in enum-flags.h, we are casting the value -1 to an enum
	of a positive range only, which is UB as per the Standard and thus not
	allowed in a constexpr context.

	The purpose of doing this instead of using std::underlying_type is
	because, for C-style enums, std::underlying_type typically returns
	"unsigned int". However, when operating with it arithmetically, the
	enum is promoted to *signed* int, which is what we want to avoid.

	This patch solves this issue as follows:

	* Use std::underlying_type and remove the custom enum_underlying_type.

	* Ensure that operator~ is called always on an unsigned integer. We do
	  this by casting the input enum into std::size_t, which can fit any
	  unsigned integer. We have the guarantee that the cast is safe,
	  because we have checked that the underlying type is unsigned. If the
	  enum had negative values, the underlying type would be signed.

	  This solves the issue with C-style enums, but also solves a hidden
	  issue: enums with underlying type of std::uint8_t or std::uint16_t are
	  *also* promoted to signed int. Now they are all explicitly casted
	  to the largest unsigned int type and operator~ is safe to use.

	* There is one more thing that needs fix. Currently, operator~ is
	  implemented as follows:

	  return (enum_type) ~underlying(e);

	  After applying ~underlying(e), the result is a very large value,
	  which we then cast to "enum_type". This cast is Undefined Behavior
	  if the large value does not fit in the range of the enum. For
	  C++ enums (scoped and/or with explicit underlying type), the range
	  of the enum is the entire range of the underlying type, so the cast
	  is safe. However, for C-style enums, the range is the smallest
	  bit-field that can hold all the values of the enumeration. So the
	  range is a lot smaller and casting a large value to the enum would
	  invoke Undefined Behavior.

	  To solve this problem, we create a new trait
	  EnumHasFixedUnderlyingType, to ensure operator~ may only be called
	  on C++-style enums. This behavior is roughly the same as what we
	  had on trunk, but relying on different properties of the enums.

	* Once this is implemented, the following tests fail to compile:

	  CHECK_VALID (true,  int,  true ? EF () : EF2 ())

	  This is because it expects the enums to be promoted to signed int,
	  instead of unsigned int (which is the true underlying type).

	  I propose to remove these tests altogether, because:

	  - The comment nearby say they are not very important.
	  - Comparing 2 enums of different type like that is strange, relies
	    on integer promotions and thus hurts readability. As per comments
	    in the related PR, we likely don't want this type of code in gdb
	    code anyway, so there's no point in testing it.
	  - Most importantly, this type of comparison will be ill-formed in
	    C++26 for regular enums, so enum_flags does not need to emulate
	    that.

	Since this is the only place where the warning was suppressed, remove
	also the corresponding macro in include/diagnostics.h.

	The change has been tested by running the entire gdb test suite
	(make check) and comparing the results (testsuite/gdb.sum) against
	trunk. No noticeable differences have been observed.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331
	Tested-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-22  Flavio Cruz  <flaviocruz@gmail.com>

	gdb/hurd: remove VLA usage
	Compilation will fail with -Werror=vla, which seems to be the default.

	Note that we don't need to allocate num_threads + 1 since the matching
	algorithm works only on the num_threads as returned by task_threads.

	Change-Id: I276928d0ff3c52c7c7fe4edb857e5789cdabfcf7

2024-12-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-20  Keith Seitz  <keiths@redhat.com>

	Add gstack script
	This commit adds support for a `gstack' command which Fedora has
	been carrying for many years. gstack is a natural counterpart to
	the gcore command. Whereas gcore dumps a core file, gstack prints
	stack traces of a running process.

	There are many improvements over Fedora's version of this script.
	The dependency on procfs is gone; gstack will run anywhere gdb
	runs. The only runtime dependencies are bash and awk.

	The script includes suggestions from gdb/32325 to include
	versioning and help. [If this approach to gdb/32325 is acceptable,
	I could propagate the solution to gcore/gdb-add-index.]

	I've rewritten the documentation, integrating it into the User Manual.
	The manpage is now output using this one source.

	Example run (on x86_64 Fedora 40)

	$ gstack --help
	Usage: gstack [-h|--help] [-v|--version] PID
	Print a stack trace of a running program

	  -h, --help         Print this message then exit.
	  -v, --version      Print version information then exit.
	$ gstack -v
	GNU gstack (GDB) 16.0.50.20241119-git
	$ gstack 12345678
	Process 12345678 not found.
	$ gstack $(pidof emacs)
	Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"):
	#0  0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
	#1  0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
	#2  0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
	#3  0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0
	#4  0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
	#5  0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
	#6  0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
	#7  0x0000000000000000 in ??? ()

	Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"):
	#0  0x00007fd6015be87d in poll () at /lib64/libc.so.6
	#1  0x0000000000000001 in ??? ()
	#2  0xffffffff00000001 in ??? ()
	#3  0x0000000000000001 in ??? ()
	#4  0x000000002104cfd0 in ??? ()
	#5  0x00007fd5eb9be320 in ??? ()
	#6  0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0

	Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"):
	#0  0x00007fd6015be87d in poll () at /lib64/libc.so.6
	#1  0x0000000020f9b558 in ??? ()
	#2  0xffffffff00000003 in ??? ()
	#3  0x0000000000000003 in ??? ()
	#4  0x00007fd5d8000b90 in ??? ()
	#5  0x00007fd5eb1bd320 in ??? ()
	#6  0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0

	Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"):
	#0  0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
	#1  0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
	#2  0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
	#3  0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0
	#4  0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0
	#5  0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
	#6  0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
	#7  0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
	#8  0x0000000000000000 in ??? ()

	Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"):
	#0  0x00007fd6015be87d in poll () at /lib64/libc.so.6
	#1  0x0000000000000001 in ??? ()
	#2  0xffffffff00000001 in ??? ()
	#3  0x0000000000000001 in ??? ()
	#4  0x00007fd5cc000b90 in ??? ()
	#5  0x00007fd5e9e6c320 in ??? ()
	#6  0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0

	Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"):
	#0  0x00007fd6015c9197 in pselect () at /lib64/libc.so.6
	#1  0x0000000000000000 in ??? ()

	Since this is essentially a complete rewrite of the original
	script and documentation, I've chosen to only keep a 2024 copyright date.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-20  Tom Tromey  <tromey@adacore.com>

	Minor cleanups in rust-lang.c
	This patch is a few minor cleanups to rust-lang.c: renaming a
	badly-named local variable, moving a couple of declarations into 'for'
	headers, and using 'bool' in one spot.

2024-12-20  Richard Earnshaw  <rearnsha@arm.com>

	arm: fix incorrect assembly of stm{,ia} as push [PR32363]
	PR/32363.

	Gas was incorrectly translating
		stm sp!, {regs}
	into
		push {regs}
	but this is invalid.  Conversely, it was also failing to translate
		stmfd sp!, {lowregs[, lr]}
	into a 16-bit push instruction.  Fortunately stmia SP! is unlikely to be
	a common idiom on a full-descending stack as it writes values to the stack,
	then immediately deallocates that bit of the stack.

	Fixed this and cleaned up the logic somewhat.  While there, change some of
	the ordering so that "ldm base, {base}" is transformed preferentially to
	LDR.  This is in keeping with the general preference in the Arm ARM for
	avoiding single register LDM instructions.

2024-12-20  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Don't prefill for operate-and-get-next of last command
	Consider operate-and-get-next [1] in bash:
	...
	$ <echo 1>echo 1<enter>
	1
	$ <echo 2>echo 2<enter>
	2
	$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
	1
	$ echo 2<Ctrl-o>
	2
	$ echo 1
	...

	So, typing Ctrl-o:
	- executes the recalled command, and
	- prefills the next one (which then can be executed again with Ctrl-o).

	We have the same functionality in gdb, but when recalling the last command
	from history with bash we have no prefill:
	...
	$ <echo 1>echo 1<enter>
	1
	$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
	1
	$
	...
	but with gdb do we have a prefill:
	...
	(gdb) echo 1\n
	1
	(gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o>
	1
	(gdb) echo 1\n
	...

	Following the principle of least surprise [2], I think gdb should do what bash
	does.

	Fix this by:
	- signalling this case in gdb_rl_operate_and_get_next using
	  "operate_saved_history = -1", and
	- handling operate_saved_history == -1 in
	  gdb_rl_operate_and_get_next_completion.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR cli/32485
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485

	[1] https://www.man7.org/linux/man-pages/man3/readline.3.html
	[2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment

2024-12-20  Tom Tromey  <tom@tromey.com>

	Use block::is_static_block in ada-lang.c
	This changes one spot in ada-lang.c to use block::is_static_block
	rather than a hand-rolled implementation.  Note this also fixes the
	call -- what is currently written there is wrong.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-20  Tom Tromey  <tom@tromey.com>

	Fix latent bug in gdbpy_lookup_static_symbols
	gdbpy_lookup_static_symbols is missing an error check for the case
	where symbol_to_symbol_object returns NULL.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-20  Nick Clifton  <nickc@redhat.com>

	Fix examples of the use of the linker script TYPE keyword

2024-12-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use -nostdlib in gdb.linespec/explicit.exp
	On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run
	into:
	...
	(gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr"
	Quit^M
	...

	The test-case already contains a related workaround:
	...
		# Get rid of symbols from shared libraries, otherwise
		# "b -source thr<tab>" could find some system library's
		# source.
		gdb_test_no_output "nosharedlibrary"
	...
	but that doesn't work in this case because the debug info is in the executable
	itself:
	...
	 The File Name Table (offset 0xb5):
	  Entry Dir     Time    Size    Name
	  1     0       0       0       abi-note.c
	  2     1       0       0       types.h
	  3     2       0       0       stdint-intn.h
	  4     2       0       0       stdint-uintn.h
	  5     3       0       0       elf.h
	  6     4       0       0       thread_pointer.h
	...
	due to debug info in some glibc object file.

	Fix this by:
	- using -nostdlib, ensuring only debug info from the three test-case sources
	  is present in the executable, and
	- adding a _start wrapping main.

	Tested on x86_64-linux and ppc64le-linux.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

	PR testsuite/31229
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229

2024-12-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-19  Alexandra Hájková  <ahajkova@redhat.com>

	elfcpp/dwarf.h: Add post DWARF5 constants to DW_LANG enum
	Also add the post DWARF5 language codes to gold/gdb-index.cc
	Gdb_index_info_reader::visit_top_die check as --gdb-index only
	supports C and C++ languages and emits warning otherwise.

2024-12-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, gdbserver: introduce the 'x' RSP packet for binary memory read
	Introduce an RSP packet, 'x', for reading from the remote server
	memory in binary format.  The binary write packet, 'X' already exists.
	The 'x' packet is essentially the same as 'm', except that the
	returned data is in binary format.  For transferring relatively large
	data from the memory of the remote process, the 'x' packet can reduce the
	transfer costs.

	For example, without this patch, fetching ~100MB of data from a remote
	target takes

	  (gdb) dump binary memory temp.o 0x00007f3ba4c576c0 0x00007f3bab709400
	  2024-03-13 16:17:42.626 - command started
	  2024-03-13 16:18:24.151 - command finished
	  Command execution time: 32.136785 (cpu), 41.525515 (wall)
	  (gdb)

	whereas with this patch, we obtain

	  (gdb) dump binary memory temp.o 0x00007fec39fce6c0 0x00007fec40a80400
	  2024-03-13 16:20:48.609 - command started
	  2024-03-13 16:21:16.873 - command finished
	  Command execution time: 20.447970 (cpu), 28.264202 (wall)
	  (gdb)

	We see improvements not only when reading bulk data as above, but also
	when making a large number of small memory access requests.

	For example, without this patch:

	  (gdb) pipe x/100000xw $pc | wc -l
	  2024-03-13 16:04:57.112 - command started
	  25000
	  2024-03-13 16:05:10.798 - command finished
	  Command execution time: 9.952364 (cpu), 13.686581 (wall)

	With this patch:

	  (gdb) pipe x/100000xw $pc | wc -l
	  2024-03-13 16:06:48.160 - command started
	  25000
	  2024-03-13 16:06:57.750 - command finished
	  Command execution time: 6.541425 (cpu), 9.589839 (wall)
	  (gdb)

	Another example, where we create a core file of a GDB process.

	  (gdb) gcore /tmp/core.1
	  ...
	  Command execution time: 85.496967 (cpu), 133.224373 (wall)

	vs.

	  (gdb) gcore /tmp/core.1
	  ...
	  Command execution time: 48.328885 (cpu), 115.032289 (wall)

	Regression-tested on X86-64 using the unix (default) and
	native-extended-gdbserver board files.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: allow suppressing the next putpkt remote-debug log
	When started with the --debug=remote flag, gdbserver enables the debug
	logs for the received and sent remote packets.  If the packet contents
	are too long or contain verbatim binary data, printing the contents
	may create noise in the logs or even distortion in the terminal output.

	Introduce a function, `suppress_next_putpkt_log`, that allows omitting
	the contents of a sent package in the logs.  This can be useful when a
	certain packet handler knows that it is sending binary data.

	My first attempt was to implement this mechanism by passing an extra
	parameter to putpt_binary_1 that could be controlled by the caller,
	putpkt_binary or putpkt.  However, all qxfer handlers, regardless of
	whether they send binary or ascii data, cause the data to be sent via
	putpkt_binary. Hence, the solution was going to be either too
	suppressive or too intrusive.  I opted for the approach where a package
	handler would suppress the log explicitly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	doc: fine-tune the documentation of the 'm' RSP packet
	Revise a sentence to avoid misinterpretation.  Move @cindex entries
	before the text they index.  Refer to trace frames regarding partial
	reads.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-12-19  Nick Clifton  <nickc@redhat.com>

	Updated Serbian translation for the bfd sub-directory

	Fix the handling or arguments and macro pseudo-variables inside nested assembler macros.
	PR 32391

2024-12-19  Jan Beulich  <jbeulich@suse.com>

	bfd/ELF: refine PR binutils/31872 fix
	The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case
	of targets with only RELA support, where nevertheless object files using
	REL exist. In particular objcopy will create such objects for x86-64
	when converting from an i?86 ELF object (this by itself probably isn't
	quite right, but we ought to cope with what our own tools are doing).

	Restore the fallback to the RELA lookup, just without re-introducing the
	blind NULL de-ref that was there before.

2024-12-19  Jan Beulich  <jbeulich@suse.com>

	PPC: drop redundant value conversion from md_assemble()
	Just ahead of the enclosing OBJ_ELF conditional the exact same
	conversion was already carried out, with "val" not further changed in
	between.

	x86-64: correct CODE_5 relocs
	Two of them had their numbers swapped; luckily they aren't really in use
	just yet. Correct indentation as well while at it.

2024-12-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-18  Alan Modra  <amodra@gmail.com>

	Adjust expected loongarch32 test results
	readelf and objdump differ in output for 32-bit vs 64-bit.

		* testsuite/gas/loongarch/dwarf-regnum.d: Adjust to suit both
		32-bit and 64-bit output.
		* testsuite/gas/loongarch/localpic.d: Likewise.

2024-12-18  Alan Modra  <amodra@gmail.com>

	target_id for cr16 and vax
	Both of these targets extend elf_link_hash_entry, so arguably should
	set hash_table_id to something other than GENERIC_ELF_DATA.  The patch
	also sorts enum elf_target_id.

	Remove bfd_elf_allocate_object object_id param
	This is another case where the proper object_id can be read from
	elf_backend_data.

	Remove _bfd_elf_link_hash_table_init target_id param
	hash_table_id can be set from elf_backend_data, now that all targets
	have matching ELF_TARGET_ID and hash_table_init target_id.

2024-12-18  Alan Modra  <amodra@gmail.com>

	Add a few elf_backend_data target ids
	aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
	the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID.  Fix that.
	These are all targets that use other than GENERIC_ELF_DATA in their
	object and hash table ids.

		* elf32-am33lin.c,
		* elf32-csky.c,
		* elf64-ia64-vms.c,
		* elf64-sparc.c,
		* elfnn-aarch64.c,
		* elfnn-kvx.c (ELF_TARGET_ID): Define.

2024-12-18  Keith Seitz  <keiths@redhat.com>

	[doc] Update gdb-add-index manpage
	The current gdb-add-index manual page is a bit out-of-date.  This
	commit fixes a few deficiencies:

	- gdb-add-index does not use objdump; it uses objcopy and readelf
	- missing info on environment variables (in appropriate ENVIRONMENT section).
	- missing mention of -dwarf-5 option
	- adds important notice about FILENAME being writable
	- explains exit status
	- the script adds appropriate section(s) to the file; it does not
	  output new files with the section(s)

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-12-18  Tom Tromey  <tromey@adacore.com>

	Add check-include-guards.py to pre-commit
	This changes pre-commit to run check-include-guards.py.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-12-18  Tom Tromey  <tromey@adacore.com>

	Run check-include-guards.py
	This patch is the result of running check-include-guards.py on the
	current tree.  Running it a second time causes no changes.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-12-18  Tom Tromey  <tromey@adacore.com>

	Add an include-checking script
	This adds a new Python script that checks the header guards of all gdb
	source files.  It enforces a fairly strict formatting and naming
	scheme.

	In particular, for a file "x/y-z.h" (relative to the repository root),
	the include guard will be named "X_Y_Z_H".  Only the '#ifndef' form is
	allowed, not "#if !defined(...)".  The trailing comment on the
	"#endif" is also required.

	The script also tries to update files that appear to have the required
	lines if they are in the wrong form or use the wrong name.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-12-18  Tom Tromey  <tromey@adacore.com>

	Fix some minor header file irregularities
	The script in the next patch noticed some irregularities in some
	headers: trailing or leading blank lines, or in one case a missing
	copyright header.  This patch fixes these.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-12-18  Tom Tromey  <tromey@adacore.com>

	Fix typo in Python documentation
	Oleg pointed out that when renaming from "status" to "enabled" in the
	Python TUI events patch, I neglected to update one spot in the
	documentation.  This patch fixes this.  I'm checking it in as obvious.

	You can verify that this change is correct by examining
	gdb/python/py-event-types.def.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162

2024-12-18  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel SM4 AVX10.2 extension
	In this patch, we will support SM4 AVX10.2 extension part. It is
	a promotion from VEX encoding to EVEX encoding. The EVEX encoding
	is based on AVX10.2, which is the same as the upcoming MOVRS ISA.
	Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS.

	While I have also tried to merge the table like AVX/AVX512, I
	choose to just templatize the table. I am okay to go either way,
	but slightly prefer the templatizing one since probably SM4 would
	be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS
	does not need that). Also, it is a tendancy that we will directly
	provide EVEX encodings and no VEX encodings for vector instructions
	since AVX10. This will make the adding in gas/config/tc-i386.c not
	that worthy.

	gas/ChangeLog:

		* NEWS: Support Intel SM4 EVEX instructions.
		* config/tc-i386.c (_is_cpu): Handle AVX10.2.
		* testsuite/gas/i386/i386.exp: Run SM4 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-256-sm4-intel.d: Add SM4 tests.
		* testsuite/gas/i386/avx10_2-256-sm4.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-sm4.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-sm4-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-sm4.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-sm4.s: Ditto.
		* testsuite/gas/i386/avx10_2-sm4-inval.l: Ditto.
		* testsuite/gas/i386/avx10_2-sm4-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-sm4-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-sm4.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-sm4.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-sm4-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-sm4.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-sm4.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-sm4-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-sm4-inval.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex.h: Add evex table entry for SM4.
		* i386-dis.h: Ditto.
		* i386-opc.h: (i386_cpu): Move AVX10.2 to CPU_FLAGS_COMMON.
		* i386-opc.tbl: Add SM4 EVEX instructions.
		* i386-init.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-12-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-17  Tom Tromey  <tromey@adacore.com>

	Minor C++-ification in rust-parse.c
	This patch changes a few spots in rust-parse.c to use 'bool', and also
	declares a couple of loop iteration variables in the loop headers.
	I'm checking this in.

2024-12-17  Flavio Cruz  <flaviocruz@gmail.com>

	Hurd: do not include defs.h when compiling MiG stubs since they are compiled as C files
	Otherwise, GDB will fail to compile for Hurd.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-17  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Update ARM64 xml files
	There are some new syscalls in the latest upstream Linux kernel [1],
	some archs updated the xml files in the recent commit 19f3450f7429
	("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also
	update ARM64 to reflect the reality.

	[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-17  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Update LoongArch xml files
	There are some new syscalls in the latest upstream Linux kernel [1][2][3],
	update the xml files for LoongArch to reflect the reality.

	[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7697a0fe0154
	[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff388fe5c481
	[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-17  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Remove tips for LoongArch xml files
	After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number",
	no need to do special handling when generating xml file for LoongArch,
	just remove the tips in the file comment.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-17  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Handle __NR3264_ prefixed syscall number
	In gdb commit a08dc2aa004b ("gdb: syscalls: Add loongarch-linux.xml.in"),
	we find:

	   There exist some __NR3264_ prefixed syscall numbers, replace them
	   with digital numbers according to /usr/include/asm-generic/unistd.h
	   and sort them by syscall number manually, maybe we can modify the
	   script to do it automatically in the future.

	It is time to do it now, just handle __NR3264_ prefixed syscall number
	automatically in the script update-linux.sh.

	By the way, a Linux kernel patch did the similar change [1].

	[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6e1cc6b7220

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-17  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: testsuite: remove macro expansion messages from expected error output
	gas generates an information diagnostic message for every context
	invoking a macro and generating a warning or error message.
	For the specific case of sysreg tests, this pollutes the expected
	error output for no benefit in term of test debug or testing coverage.

	This patch aims at stopping such diagnostic messages to be generated
	for the failure tests by providing --no-info flag to gas.
	It also removed from the expected outputs the information messages
	related to macro expansions.

2024-12-17  Matthieu Longo  <matthieu.longo@arm.com>

	gas: add new command line options to control diagnostic informational messages
	gas currently emits informational messages for context information along warnings.
	In the context of system register tests in AArch64 backend, these messages
	pollute the tests when checking for error message patterns in stderr output.

	This patch aims at providing two new flags while preserving the existing
	behavior if none of the options is provided.
	  * --info, similar to the existing --warn flag to enable diagnostic
	    informational messages (default behavior).
	  * --no-info, similar to the existing --no-warn flag to disable diagnostic
	    informational messages.

	It also adds the flags to the existing documentation, and command manual.

2024-12-17  Nick Clifton  <nickc@redhat.com>

	nm: Avoid potential segmentation fault when displaying symbols without version info.
	PR 32467

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: return tracked register status in regcache_raw_read_unsigned
	In regcache_raw_read_unsigned, we unconditionally return REG_VALID as
	the register status.  This does not seem right, since the register may
	in fact be in another state, such as REG_UNAVAILABLE.  Return the
	tracked status.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbsupport: fix a typo in a comment in common-regcache.h
	Fix a typo.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: rename regcache's registers_valid to registers_fetched
	The registers_valid field of the regcache struct is used for tracking
	whether we have attempted to fetch all the registers from the target.
	Its name does not reflect this well, I think.  It falsely gives the
	impression that all the registers are valid.  This may conflict an
	individual register status, which could be REG_UNAVAILABLE.  To better
	reflect the purpose, rename the field to "registers_fetched".

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: boolify regcache fields
	The registers_valid and registers_owned fields of the regcache struct
	are of type int.  Make them bool.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: check for nullptr condition in regcache::get_register_status
	A regcache can be initialized with a register value buffer, in which
	case, the register_status pointer is null.  This condition is checked
	in set_register_status, but not in get_register_status.  Do this check
	for consistence and safety.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: convert regcache_cpy into regcache::copy_from
	Convert the free `regcache_cpy` function to a method of the
	regcache struct.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache
	Boolify the 'fetch' parameter of the get_thread_regcache function.

	All of the current uses pass true for this parameter.  Therefore, define
	its default value as true and remove the argument from the uses.

	We still keep the parameter, though, to give downstream targets the
	option to obtain a regcache without having to fetch the whole
	contents.  Our (Intel) downstream target is an example.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: by-pass regcache to access tdesc only
	The `get_thread_regcache` function has a `fetch` option to skip
	fetching the registers from the target.  It seems this option is set
	to false only at uses where we just need to access the tdesc through
	the regcache of the current thread, as in

	  struct regcache *regcache = get_thread_regcache (current_thread, 0);
	  ... regcache->tdesc ...

	Since the tdesc of a regcache is set from the process of the thread
	that owns the regcache, we can simplify the code to access the tdesc
	via the process, as in

	  ... current_process ()->tdesc ...

	This is intended to be a refactoring with no behavioral change.

	Tested only for the linux-x86-low target.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-17  Alan Modra  <amodra@gmail.com>

	Re: score and mmix target_id
	elflink.c checks elf_object_id(ibfd) == elf_hash_table_id(hash_table)
	in a number of places.  Make them match.

2024-12-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-16  Tom Tromey  <tom@tromey.com>

	Use correct type for saved signal handler
	A user noticed that the sim assigns the result of a call to 'signal'
	to a variable like:

	  RETSIGTYPE (*prev_sigint) ();

	However, it's more correct to use (int) here.

	This patch fixes the error.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32466
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-16  Tom Tromey  <tom@tromey.com>

	Fix readline build on mingw
	Upstream readline 8.2 does not build on mingw.  This patch fixes the
	build, but I do not know how well it works.

	I've submitted this to readline here:

	    https://lists.gnu.org/archive/html/bug-readline/2024-11/msg00007.html

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265

2024-12-16  Tom Tromey  <tom@tromey.com>

	Import GNU Readline 8.2
	This imports readline 8.2 patch 13.

	This time around I thought I would try to document the process.

	First I have a checkout of the upstream readline repository.  I make a
	local branch there, based on the previous upstream import.  In this
	case that was readline 8.1; see gdb commit b4f26d541aa.

	Then, I apply all readline changes from the gdb repository since the
	previous readline import.  In this case that is up to commit
	3dee0baea2e in the gdb repo.

	After this, I "git merge" from the relevant upstream commit.  In the
	past I feel like I used a tag, but readline is managed very strangely
	and I didn't see a tag.  So I just used the patch 13 commit, aka
	commit 037d85f1 upstream.

	Then I fixed all the merge conflicts.  Re-running autoconf requires a
	symlink from '../../config' into the gdb tree, due to the local
	m4_include addition.  It's possible other hacks like this are
	required, I don't remember how I set things up in the past.

	After this, I did a build + test of gdb.  I also did a mingw
	cross-hosted build, because that's caused build failures in past
	imports.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265
	Reviewed-by: Sam James <sam@gentoo.org>

2024-12-16  Tom Tromey  <tromey@adacore.com>

	Greatly speed up rbreak
	While debugging another issue, I noticed that 'rbreak' on a large
	program was very slow.  In particular, with 'maint time 1':

	(gdb) with pagination off -- rbreak ^command_display
	[...]
	Command execution time: 1940.646332 (cpu), 1960.771517 (wall)

	"ps" also reported that, after this command, gdb's VSZ was 4619360.

	Looking into this, I found something strange.  When 'rbreak' found a
	function "f" in file "file.adb", it would try to set the breakpoint
	using "break 'file.adb':'f'".

	This then interacted somewhat poorly with linespec.  linespec first
	expands all the symtabs matching "file.adb", but in this program this
	results in thousands of CU expansions (probably due to inlining, but I
	did not investigate).

	There is probably a linespec bug here.  It would make more sense for
	it to combine the file- and symbol- lookups, as this is more
	efficient.  I plan to file a bug about this at least.

	I tracked this "file:function" style of linespec to the earliest days
	of gdb.  Back then, "break function" would only break on the first
	"function" that was found -- it wasn't until much later that we
	changed gdb to break on all matching functions.  So, I think that
	rbreak was written this way to try to work around this limitation, and
	it seems to me that this change obsoleted the need for rbreak to
	mention the file at all.

	That is, "break file:function" is redundant now, because plain
	"break function" will redo that same work -- just more efficiently.
	(The only exception to this is the case where a file is given
	to rbreak -- here the extra filtering is still needed.)

	This patch implements this.  On the aforementioned large program, with
	this patch, rbreak still sets all the desired breakpoints (879 of
	them) but is now much faster:

	(gdb) with pagination off -- rbreak ^command_display
	[...]
	Command execution time: 91.702648 (cpu), 92.770430 (wall)

	It also reduces the VSZ number to 2539216.

	Regression tested on x86-64 Fedora 40.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340
	Approved-By: Pedro Alves <pedro@palves.net>

2024-12-16  Tom Tromey  <tromey@adacore.com>

	Don't let exception terminate 'rbreak'
	'rbreak' searches symbols and then sets a number of breakpoints.  If
	setting one of the breakpoints fails, then 'rbreak' will terminate
	before examining the remaining symbols.

	However, it seems to me that it is better for 'rbreak' to keep going
	in this situation.  That is what this patch implements.

	This problem can be seen by writing an Ada program that uses "pragma
	import" to reference a symbol that does not have debug info.  In this
	case, the program will link but setting a breakpoint on the imported
	name will not work.

	I don't think it's possible to write a reliable test for this, as it
	depends on the order in which symtabs are examined.

	New in v2: rbreak now shows how many breakpoints it made and also how
	many errors it encountered.

	Regression tested on x86-64 Fedora 40.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-16  Tom Tromey  <tromey@adacore.com>

	Re-run isort
	I noticed that an earlier commit caused a change in the isort output.
	This patch repairs the problem.

2024-12-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: rename test source file to avoid glibc clash
	After posting this series:

	  https://inbox.sourceware.org/gdb-patches/cover.1733742925.git.aburgess@redhat.com

	I got a failure report from the Linaro CI system.  I eventually
	tracked the issue down to a filename clash with glibc.  I was able to
	reproduce the issue when I installed the glibc debug information on to
	my local machine, and ran the gdb.base/dlmopen.exp test as updated in
	the above series.

	Here's what's happening:

	There is a file called dlmopen.c within glibc, within the glibc source
	tree the file can be found at ./dlfcn/dlmopen.c.  When this file is
	compiled it appears that the glibc build system first enters the dlfcn
	directory, and then compiles the file using the relative path
	./dlmopen.c, here's a snippet of the DWARF:

	 <0><d5d27>: Abbrev Number: 12 (DW_TAG_compile_unit)
	    <d5d28>   DW_AT_producer    : (alt indirect string, offset: 0x16433) t
	    <d5d2c>   DW_AT_language    : 29    (C11)
	    <d5d2d>   DW_AT_name        : (indirect line string, offset: 0x5c8f): dlmopen.c
	    <d5d31>   DW_AT_comp_dir    : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn
	    <d5d35>   DW_AT_low_pc      : 0x8a4c0
	    <d5d3d>   DW_AT_high_pc     : 408
	    <d5d3f>   DW_AT_stmt_list   : 0x68ec1

	The important thing here is the DW_AT_name, which is just "dlmopen.c".

	The gdb.base/dlmopen.exp test also has a source file called
	"dlmopen.c".

	The dlmopen.exp test makes use of the clean_restart TCL proc, which
	calls gdb_reinitialize_dir, which resets the source directories search
	path to '$cdir:$cwd', and then prepends the test source directory to
	the front of the list, so the source directory search path will look
	something like:

	  /tmp/src/gdb/testsuite/gdb.base/gdb.base:$cdir:$cwd

	In the existing test we try to place a breakpoint on 'dlmopen.c:64'.
	This is the line tagged 'bp.main' in the source file.  This currently
	works fine.  GDB searches through the symtabs and finds two matches,
	the test dlmopen.c, and the glibc dlmopen.c.  For each GDB tries to
	convert line 64 into an address.

	For the testsuite source file this is fine, we get the address of the
	line tagged 'bp.main' from the source, and the breakpoint is created.

	For the glibc source file though, at least, for the version available
	to me, line 64 happens to be the closing '}' of a function, and there
	isn't a line table entry for this exact line.  So GDB searches forward
	looking for the next line in order to place a breakpoint there.  The
	next line GDB finds is the start of the next function, and so GDB
	rejects this location due to commit:

	  commit dcaa85e58c4ef50a92908e071ded631ce48c971c
	  Date:   Wed May 1 10:47:47 2024 +0100

	      gdb: reject inserting breakpoints between functions

	So we managed to avoid creating two breakpoint locations in this case,
	but only by pure good luck.

	In my updates to the test though I try to create a breakpoint at line
	61 in addition to the breakpoint at line 64.  So now the breakpoint
	spec is 'dlmopen.c:61'.

	Just as before, GDB identifies the 'dlmopen.c' could mean two files,
	and searches for line 61 in both.  The test source works as expected
	and the breakpoint is created in the desired location.

	But this time, line 61 in the glibc source file is an actual line,
	with actual code, and so GDB places a breakpoint at this location.

	This second breakpoint, in glibc is entirely unexpected (by the
	dlmopen.exp test script).  Unfortunately, the inferior hits this
	second glibc breakpoint before it hits the actual breakpoint within
	the main test executable, this throws the test off and causes some
	failures.

	In trying to fix this, I did wonder if I could just specify the full
	path to the source file, instead of using just 'dlmopen.c:61'.
	However, this doesn't work.

	Remember that the glibc source file is recorded as just 'dlmopen.c'.
	So, when GDB tries to figure out the absolute path to this source
	file, the source directory search path is used.  In this case, the
	first entry in the source directory search path is the gdb.base/
	directory in the GDB source tree.  GDB looks in this directory and
	finds a dlmopen.c, and so GDB assumes that this is the file in
	question.

	Thus, GDB actually thinks that both files _are_ the same source file.
	Indeed, when GDB stops at the incorrect (glibc) breakpoint, and lists
	the source code, it actually lists the source code from the correct
	file.  This confused me to begin with, GDB reported the wrong
	function (the glibc function), but listed code from the correct file
	and line.

	Now on my machine I have installed the package that provides the glibc
	source code.  If I change the source directory search path so that
	$cdir is first instead of the gdb.base/ from the GDB source tree, this
	fixes the listing the wrong file problem.  GDB does not realise that
	the files are different, and if I create the breakpoint using the
	absolute path then only a single breakpoint location is created.
	However, this relies on the developer having both the glibc debug
	information, and the glibc source package installed, this doesn't seem
	like a great requirement to have in place.

	So instead, I propose that we just take the easy way out, rename the
	test source file.  By doing this all the issues are avoided.  The test
	now creates a breakpoint at 'dlmopen-main.c:61', and there is only one
	file with this name found, so we only get a single breakpoint location
	created.

	I renamed the source file, but not the dlmopen.exp file because the
	test already makes use of multiple source files, so having a range of
	different names didn't feel that bad, but if this bothers people, I
	could rename both the .exp and main .c file, just let me know.

	If you want to explore this issue for yourself then try with
	installing the glibc debug information for your system, and ensure
	that your GDBs under test are able to find the glibc debug
	information.  You can then either apply the series I linked above, or,
	you can modify the existing test source so that the line tagged as
	'bp.main' becomes line 61, I just deleted 3 lines from the big comment
	at the head of the file.

	Of course, reproducing this does depend on how glibc is compiled,
	which could change from system to system, or overtime.  I reproduced
	this issue on Fedora 39 with glibc-2.38-19.

	With this patch applied I no longer see any regressions when I apply
	the above linked series.

	While making these changes I took the opportunity to update the test
	script to make better use of standard_testfile and build_executable.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-16  Nick Clifton  <nickc@redhat.com>

	Update translations for the opcodes directory for the French and Serbian languages.

2024-12-16  Jan Beulich  <jbeulich@suse.com>

	ld/doc: properly separate @samp from @item
	At least makeinfo 4.13 doesn't tolerate @item@samp, considering it a
	single command.

2024-12-16  Alan Modra  <amodra@gmail.com>

	mach-o segment section count assertion
	Add an assertion that verifies we have filled the mdata->sections
	array in bfd_mach_o_flatten_sections.

	score and mmix target_id
	These targets currently use GENERIC_ELF_DATA as their target_id, but
	that isn't exactly correct.  While their bfd tdata is generic elf,
	their elf_section_data is extended with extra target data.  Add
	MMIX_ELF_DATA and SCORE_ELF_DATA.

	goodbye aout_section_data
	aout_section_data->relocs isn't set by anything, so delete it.

2024-12-16  Alan Modra  <amodra@gmail.com>

	record_section_with_aarch64_elf_section_dat
	Nowhere in the aarch64 backend is the list created by this function
	examined, and in any case there are much simpler ways to determine the
	type of elf_section_data attached to a bfd ELF section.  It will
	always be according to the target_id of the section owner.

	Delete sections_with_aarch64_elf_section_data and everything
	associated with it.

2024-12-16  Alan Modra  <amodra@gmail.com>

	section tdata tidy
	Any _new_section_hook that is not itself called from another
	_new_section_hook will always see used_by_bfd NULL.  Remove those
	NULL checks in such hooks, and tidy code a little.

2024-12-16  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix bfd ld failed test case
	This test case requires host gcc, and different distributions have
	different default configurations for gcc, which can cause address value
	mismatches.
	Therefore, it is fixed by passing consistent options and using regular
	expressions.

2024-12-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-15  Alan Modra  <amodra@gmail.com>

	Move modification of bfd abs and und back to gas
	In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and
	instead put the gas modification of bfd's *ABS* and *UND* sections in
	bfd_make_section_old_way.  More recently in commit 8b5a21249537 I made
	tekhex symbol creation use bfd_make_section_old_way for symbol
	sections.  After that we saw numerous non-repeatable oss-fuzz reports
	of accesses to freed memory involving relocation symbols.  I think
	what is happening is:

	A tekhex testcase with an absolute symbol is run through the tool,
	modifying bfd_abs_section.symbol to point to a symbol on the bfd's
	objalloc memory.  On closing that bfd bfd_abs_section.symbol points to
	freed memory.

	A second testcase is run through the tool with some access to the
	*ABS* symbol.  This triggers the invalid memory access.

	The same thing could happen if a user runs objdump or nm with two
	files on the command line, the first being a tekhex file with absolute
	symbols, or if ld is given tekhex input among other files.  Clearly,
	it's a bad idea to modify the *ABS* or *UND* sections for input files.

	bfd/
		* section.c (bfd_make_section_old_way): Don't call
		_new_section_hook for standard abs, com, und and ind sections.
	gas/
		* as.c (bfd_std_section_init): New function.
		(perform_an_assembly_pass): Move section initialisation to..
		(gas_init): ..here.  Use bfd_std_section_init.

2024-12-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-14  oltolm  <oleg.tolmatcev@gmail.com>

	fix Windows build
	Fix the Windows build that was broken in "Introduce \"command\" styling".

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-14  Alexandra Hájková  <ahajkova@redhat.com>

	display_lang: Add descriptions for post DWARF5 constants
	Describe all the new post DWARF5 language codes from the latest sync
	of include/dwarf.h with gcc.

2024-12-14  Alan Modra  <amodra@gmail.com>

	Delete asection.symbol_ptr_ptr
	This field is always set to point to asection.symbol, and no code ever
	changes it from its initial value.  With one exception.  elfxx-mips.c
	creates two sections with separate pointers to their symbols, and uses
	those as asection.symbol_ptr_ptr.  Those pointers aren't modified,
	so they disappear in this patch too.

2024-12-14  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix regressions with python 3.6
	With test-case gdb.dap/ada-arrays.exp, on Leap openSUSE 15.6 with python 3.6,
	I run into:
	...
	Python Exception <class 'TypeError'>: 'type' object is not subscriptable
	Error occurred in Python: 'type' object is not subscriptable
	ERROR: tcl error sourcing ada-arrays.exp.
	...

	This is due to using a python 3.9 construct:
	...
	thread_ids: dict[int, int] = {}
	...

	Fix this by using typing.Dict instead.

	Tested on x86_64-linux.

2024-12-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-13  Alan Modra  <amodra@gmail.com>

	xcoff ldrel and tls sections
		* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Use
		.tdata and .tbss section symbols.
		(xcoff_create_ldrel): Abort on h and hsec both NULL.

2024-12-13  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix tsan warning: signal handler spoils errno
	When building gdb with -fsanitize=thread and running test-case
	gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
	...
	==================^M
	WARNING: ThreadSanitizer: signal handler spoils errno (pid=25422)^M
	    #0 handler_wrapper gdb/posix-hdep.c:66^M
	    #1 decltype ({parm#2}({parm#3}...)) gdb::handle_eintr<>() \
	         gdbsupport/eintr.h:67^M
	    #2 gdb::waitpid(int, int*, int) gdbsupport/eintr.h:78^M
	    #3 run_under_shell gdb/cli/cli-cmds.c:926^M
	...

	Likewise in:
	- tui_sigwinch_handler with test-case gdb.python/tui-window.exp, and
	- handle_sighup with test-case gdb.base/quit-live.exp.

	Fix this by saving the original errno, and restoring it before returning [1].

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html

2024-12-13  oltolm  <oleg.tolmatcev@gmail.com>

	gdb/dap: allow some requests when the process is running
	It is impossible to set a breakpoint when the process is running,
	which I find annoying. LLDB does not have this restriction. I made
	`setBreakpoints` and `breakpointLocations` work when the process is
	running. Probably more requests can be changed, but I only need these
	two at the moment.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-13  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	gdb-dap: fix gdb.error: Frame is invalid.
	When you try to use a frame on one thread and it was created on
	another you get an error. I fixed it by creating a map from a frame ID
	to a thread ID. When a frame is created it is added to the map. When
	you try to find a frame for an id it checks if it is on the correct
	thread and if not switches to that thread. I had to store the frame id
	instead of the frame itself in a "_ScopeReference".

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32133
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-13  Marek Pikuła  <m.pikula@partner.samsung.com>

	gitignore: Add .devcontainer to ignored
	Some people might use devcontainer to set up development environment.
	Ignore this directory, similar to other existing IDE-specific ignores.

2024-12-13  Nick Clifton  <nickc@redhat.com>

	Give unique names to s390 assembler opcode tests.

2024-12-13  Jan Beulich  <jbeulich@suse.com>

	msp430/gas: correct BFD_RELOC_32 handling
	It was likely a copy-and-paste oversight that bfd_putl16() was used here
	from the very beginning. And of course there's a difference only if the
	value to be stored is different from the value that's already there;
	typically both are 0.

	gas: avoid UB on signed multiplication in resolve_symbol_value()
	Commit 487b0ff02dda ("ubsan: signed integer multiply overflow") touched
	only one of the two affected places (the 3rd, resolve_expression(), is
	already using valueT type local variables).

2024-12-13  Alan Modra  <amodra@gmail.com>

	xcoff reading dynamic relocs
	This adds a sanity check to relocation symbol indices, and tidies code
	a little.

	The patch does result in a couple of testsuite failures
	rs6000-aix7.2  +FAIL: TLS relocations (32-bit)
	rs6000-aix7.2  +FAIL: TLS relocations (64-bit)

	That seems reasonable to me, because prior to this patch l_symndx was
	being set to -1 and -2 for .tdata and .tbss symbols resulting in a
	buffer overflow when accessing the syms array.

	bfd/
		* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Prevent
		symbol array overflow on invalid relocation symbol index.
		Tidy code for relocs against standard sections.
		(xcoff_create_ldrel): Remove cast.
	include/
		* coff/xcoff.h (struct internal_ldrel): Make l_symndx uint32_t.
		Make l_rtype and l_rsecnm int16_t.

2024-12-13  Alan Modra  <amodra@gmail.com>

	small coffgen.c tidy
	_bfd_coff_free_cached_info should always call
	_bfd_generic_bfd_free_cached_info, even if _bfd_coff_free_symbols
	returns an error.  (It won't return an error here, but let's not leave
	anyone wondering about _bfd_coff_free_cached_info.)

		* coffgen.c (_bfd_coff_free_cached_info): Ignore return status
		of _bfd_coff_free_symbols.

2024-12-13  Alan Modra  <amodra@gmail.com>

	objdump: Delete close optimisation
	In commit cd6581da62c3, Nick made an optimisation that was reasonable
	at the time, but then pr22032 came along and commit 7c0ed39626e3 made
	bfd_close_all_done free memory.  So Nick's optimisation is now
	ineffective, and the comment wrong.

		* objdump.c (display_file): Delete last_file param.  Update
		caller.  Call bfd_close always.

2024-12-13  Tom Tromey  <tom@tromey.com>

	Reuse "title" style for list headers
	This patch reuses the "title" style for titles -- in particular the
	header line of a list display.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-13  Tom Tromey  <tom@tromey.com>

	Replace uses of "title" style with "command"
	Currently the "title" style is only used when printing command names.
	The "title" name itself is probably a misnomer, but meanwhile this
	patch changes the existing uses to instead use the new "command" style
	for consistency.

	The "title" style is not removed; see the next patch.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-13  Tom Tromey  <tom@tromey.com>

	Introduce "command" styling
	This adds a new "command" style that is used when styling the name of
	a gdb command.

	Note that not every instance of a command name that is output by gdb
	is changed here.  There is currently no way to style error() strings,
	and there is no way to mark up command help strings.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-12  Tom Tromey  <tom@tromey.com>

	Lock bfd_stat and bfd_get_mtime
	PR gdb/31713 points out some races when using the background DWARF
	reader.

	This particular patch fixes some of these, namely the ones when using
	the sim.  In this case, the 'load' command calls reopen_exec_file,
	which calls bfd_stat, which introduces a race.

	BFD only locks globals -- concurrent use of a single BFD must be
	handled by the application.  To this end, this patch adds locked
	wrappers for bfd_stat and bfd_get_mtime.

	I couldn't reproduce these data races but the original reporter tested
	the patch and confirms that it helps.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-12  Tom Tromey  <tom@tromey.com>

	Fix races involving _bfd_section_id
	BFD's threading approach is that global variables are guarded by a
	lock.  However, while implementing this, I missed _bfd_section_id.  A
	user pointed out, via Thread Sanitizier, that this causes a data race
	when gdb's background DWARF reader is enabled.

	This patch fixes the problem by using the BFD lock in most of the
	appropriate spots.  However, in ppc64_elf_setup_section_lists I chose
	to simply assert that multiple threads are not in use instead.  (Not
	totally sure if this is good, but I don't think this can be called by
	gdb.)

	I chose locking in bfd_check_format_matches, even though it is a
	relatively big hammer, because it seemed like the most principled
	approach, and anyway if this causes severe contention we can always
	revisit the decision.  Also this approach means we don't need to add
	configury to check for _Atomic, or figure out whether bfd_section_init
	can be reworded to make "rollback" unnecessary.

	I couldn't reproduce these data races but the original reporter tested
	the patch and confirms that it helps.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713

2024-12-12  Tom Tromey  <tromey@adacore.com>

	Fix formatting in gdb.ada/lazy-string.exp
	This fixes a formatting issue and corrects a comment in the new
	gdb.ada/lazy-string.exp.  I meant to do this in an earlier patch but
	forgot to save.

2024-12-12  Tom Tromey  <tromey@adacore.com>

	Use generic_printstr from ada_language::printstr
	Currently, if you create a lazy string while in Ada language mode, the
	string will be rendered strangely, like:

	    "["d0"]["9f"]["d1"]["80"]["d0"]["b8"]...

	This happens because ada_printstr does not really handle UTF-8
	decoding.

	This patch changes ada_language::printstr to use generic_printstr when
	UTF-8 is used.

	Note that this code could probably be improved some more -- the
	current patch only addresses the narrow case of the Python API.  I've
	filed a follow-up bug (PR ada/32413) for the remaining changes.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-12  Tom Tromey  <tromey@adacore.com>

	Add text to gdbreplay --help output
	I noticed that gdbreplay --help is rather sparse -- it doesn't even
	mention the names of the options it accepts.

	This patch updates the help output to be more complete.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-12  Tom Tromey  <tromey@adacore.com>

	Fix GNAT version check in gdb.ada
	Commit 1411185a ("Introduce and use gnat_version_compare") changed the
	Ada tests to use a new proc for version checking.  Unfortunately this
	patch inadvertently reversed the sense of the test in
	packed_array_assign.exp.

	After fixing this, I went through that patch again and looked for
	other problems.  I found one spot where the wrong syntax was used, and
	some others where I believe the sense of the test was inverted.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32444
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-12  Tom Tromey  <tromey@adacore.com>

	Make rs6000-tdep.c:variants 'const'
	I noticed that rs6000-tdep.c has a global "variants" array that can be
	marked "const", moving it into rodata.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-12  Alexandra Hájková  <ahajkova@redhat.com>

	mangle_style: Add new DWARF5 constants
	Update bfd/dwarf2.c with the post DWARF5 language codes which
	were added after DWARF5 was finalized. Adding them makes it
	possible to return the mangling style for the new language
	codes for Ada 2005 Fortran, C++, C and Assembly.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Jan Beulich <jbeulich@suse.com>

2024-12-12  Alan Modra  <amodra@gmail.com>

	Revert bfd_use_reserved_id patch
	Commit fc1cfaa5f1 and bc110b6e40 were made to avoid testsuite
	regressions on a number of targets that used bfd id in symbol hashing.
	Since it no longer seems necessary to start plugin bfd id's from -1
	and count down, revert the functional changes in those patches.

2024-12-12  Alan Modra  <amodra@gmail.com>

	Use bfd id to validate dwarf2 cache
	Using a bfd pointer to validate the cache isn't very robust.  If a bfd
	is closed somehow without clearing the cache, then it's possible that
	another bfd is opened using the same memory and thus orig_bfd compares
	equal to the new bfd.

		* dwarf2.c (struct dwarf2_debug): Add orig_bfd_id.  Delete
		orig_bfd.
		(_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id.

2024-12-12  Alan Modra  <amodra@gmail.com>

	close last arfile before processing current arfile
	This also reduces peak memory a little.

		* dlltool.c (identify_search_archive): Close last_arfile earlier.
		Report an error if bfd_openr_next_archived_file returns the same
		bfd.  Localise variables.
		* nm.c (display_archive): Likewise.
		* objdump.c (display_any_bfd): Likewise.
		* size.c (display_archive): Likewise.

2024-12-12  Alan Modra  <amodra@gmail.com>

	nm.c free_lineno_cache
	free_lineno_cache frees symbol and relocation data used when displaying
	line number info for symbols (nm -l).  Currently that is done when
	closing the bfd, but that's not ideal for archives since that results
	in two bfds worth of memory in use.

		* nm.c (display_rel_file): Call free_lineno_cache here..
		(display_archive, display_file): ..not here.

2024-12-12  Alan Modra  <amodra@gmail.com>

	tdata related object_p tidy for various formats
	The aout object_p function copies any existing tdata.  Apparently this
	was done for hp300, an old target that is no longer supported.  See
	commit ebd241352942.  This isn't useful for current sources, nor is it
	necessary or useful any more to preserve tdata in object_p functions
	when a target doesn't match.  When I was fixing this, I noticed some
	object_p functions rudely didn't release memory on failures, and
	others had nits in the bfd_error returns.

		* aoutx.h (some_aout_object_p): Don't restore previous tdata
		on failure.  Don't copy any existing tdata.
		* archive.c (bfd_generic_archive_p): Don't restore previous
		tdata on failure.
		* pdp11.c (some_aout_object_p): Likewise.
		* coff-rs6000.c (_bfd_xcoff_archive_p): Allocate both artdata
		and extension in one call.  Don't restore previous tdata on
		failure.
		* coff64-rs6000.c (xcoff64_archive_p): Likewise.
		* coffgen.c (coff_real_object_p): Don't restore previous
		tdata on failure.
		* ihex.c (ihex_object_p): Likewise.  Simplify release of tdata
		on scan failure.
		* mach-o.c (bfd_mach_o_scan): Don't set tdata here.  Do set
		error on read_command failure.
		(bfd_mach_o_header_p): Set tdata here, release on failure.
		Tidy bfd_error return values.
		(bfd_mach_o_fat_archive_p): Tidy error return values.
		* mmo.c (mmo_mkobject): Do not test current tdata.
		* pef.c (bfd_pef_scan_start_address): Set bfd_error on
		failure.
		(bfd_pef_scan): Don't set tdata here.
		(bfd_pef_object_p): Set tdata here, release on failure.  Tidy
		bfd_error return values.
		(bfd_pef_xlib_object_p): Tidy bfd_error return values.
		* srec.c (srec_object_p): Don't restore previous tdata on
		failure.  Do release tdata on failure.
		(symbolsrec_object_p): Likewise.
		* tekhex.c (tekhex_object_p): Don't ignore tekhex_mkobject
		failure.  Release tdata on failure.
		* vms-alpha.c (alpha_vms_object_p): Don't restore previous
		tdata on failure.  Simplify release of tdata.
		* xsym.c (bfd_sym_scan): Don't set tdata here.
		(bfd_sym_object_p): Set tdata here.  Release on failure.

2024-12-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-11  Tom Tromey  <tromey@adacore.com>

	Fix gdbreplay checksum calculation
	I needed to use gdbreplay today.  It didn't work quite right, and
	using "set debug remote 1" showed that gdb was rejecting some
	responses like:

	  [remote] Sending packet: $vCont?#49
	  [remote] Junk: #vCont?
	  [remote] Junk: 8vCont?
	  [remote] Junk: 3vCont?
	  [remote] Received Ack

	The checksum recalculation seems to have gone wrong.  Looking at the
	code, it seems like 'where_csum' is calculated inconsistently: in the
	main loop it is after the '#' but in the "== 0" case it is before the
	'#'.

	This patch fixes the problem and also avoids a string copy.

	CC: Alexandra Hájková <ahajkova@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-11  Alexandra Hájková  <ahajkova@redhat.com>

	dwarf_lang_to_enum_language: Map new DWARF5 constants
	Add new DWARF5 language codes to gdb/dwarf2/read.c where
	they are converted to GDB language names. The codes
	were added to include/dwarf.h by syncing with gcc, Ada language
	codes were added to dwarf.h earlier.

	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-11  Jens Remus  <jremus@linux.ibm.com>

	gdb: s390: Correct record/replay of may/mayr insn
	The IBM z/Architecture Principles of Operation [1] specifies that the
	R1 operand of the may and mayr instructions designates may designate
	either the lower- or higher-numbered register of a floating-point-
	register (FPR) pair.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	gdb/
		* s390-tdep.c (s390_process_record): may/mayr operand R1 may
		designate lower- or higher numbered register of FPR pair.

2024-12-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix sorting in Hist_data::sort
	If the '-name soname' option is used, the fake '<Total>' function is expanded
	with the name loadobject.

	gprofng/ChangeLog
	2024-12-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Hist_data.cc (Hist_data::sort): Fix sorting.

2024-12-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use setVariable in gdb.dap/scopes.exp
	The test-case gdb.dap/scopes.exp contains the following outdated comment:
	...
	 # setVariable isn't implemented yet, so use the register name.
	...

	Now that setVariable is implemented, use it to set variable scalar, and remove
	the bit that sets the first register.  That part is known to fail on s390x,
	because the first register isn't writeable [1].

	Tested on x86_64-linux.

	Suggested-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html

2024-12-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dap/step-out.exp on s390x
	With test-case gdb.dap/step-out.exp on s390x-linux, I get:
	...
	>>> {"seq": 7, "type": "request", "command": "scopes", "arguments": {"frameId": 0}}
	Content-Length: 569^M
	^M
	{"request_seq": 7, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 1, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 114, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}]}, "success": true, "seq": 21}PASS: gdb.dap/step-out.exp: get scopes success
	FAIL: gdb.dap/step-out.exp: three scopes
	...

	The problem is that the test-case expects three scopes:
	...
	lassign $scopes scope reg_scope return_scope
	...
	but the return_scope is missing because this doesn't work:
	...
	$ gdb -q -batch outputs/gdb.dap/step-out/step-out \
	    -ex "b function_breakpoint_here" \
	    -ex run \
	    -ex finish
	  ...
	Value returned has type: struct result. Cannot determine contents
	...

	This is likely caused by a problem in gdb, but there's nothing wrong the DAP
	support.

	Fix this by:
	- allowing two scopes, and
	- declaring the tests of return_scope unsupported.

	Tested on s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix fails in gdb.python/py-arch-reg-groups.exp
	Since commit e69d35f45e0 ("Use ui-out table in "maint print reggroups""),
	test-case gdb.python/py-arch-reg-groups.exp fails with check-read1:
	...
	FAIL: $exp: Same number of registers groups found
	FAIL: $exp: all register groups match
	...

	Fix this by adding a gdb_test_multiple clause that matches the command.

	Tested on x86_64-linux.

2024-12-10  WANG Xuerui  <git@xen0n.name>

	LoongArch: Default to a maximum page size of 64KiB
	As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1),
	LoongArch machines are not limited in page size choices, and currently
	page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux.
	While 16KiB is the most common, the current BFD code says it is the
	maximum; this is not correct, and as an effect, almost all existing
	binaries are incompatible with a 64KiB kernel because the sections are
	not sufficiently aligned, while being totally fine otherwise.
	This is needlessly complicating integration testing [1].

	This patch fixes the inconsistency, and also brings BFD behavior in line
	with that of LLD [2].

	[1] https://github.com/loongson-community/discussions/issues/47
	[2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183

	bfd/
		* elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB.
		(ELF_MINPAGESIZE): Define as 4KiB.
		(ELF_COMMONPAGESIZE): Define as 16KiB.

	ld/
		* testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after
		changing the target max page size to 64KiB.
		* testsuite/ld-loongarch-elf/data-got.d: Likewise.
		* testsuite/ld-loongarch-elf/desc-relex.d: Likewise.
		* testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise.
		* testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work
		as intended by not checking exact instruction words.
		* testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise.

2024-12-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-09  Alan Modra  <amodra@gmail.com>

	Re: gprofng: use gprofng- prefix for gprofng binaries
	Commit d25ba4596e85 mangled ZLIBINC to ZLIgp-C.  Fix that.

2024-12-09  Peter Bergner  <bergner@linux.ibm.com>

	PowerPC: Disallow r0 as a base register for the hashst and hashchk insns
	Using r0 as a base address register in the ROP hashst and hashchk instructions
	is invalid.  Modify the assembler to catch that illegal use and emit an error.

	opcodes/
		* ppc-opc.c (insert_ras): Update error message and function comment.
		(powerpc_opcodes) <hashst, hashstp, hashchk, hashchkp>: Use RAS.

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Introduce NoOpStringPrinter
	We discovered that attempting to print a very large string-like array
	would succeed on the CLI, but in DAP would cause the "variables"
	request to fail with:

	  value requires 67038491 bytes, which is more than max-value-size

	This turns out to be a limitation in Value.format_string, which
	de-lazy-ifies the value.

	This patch fixes this problem by introducing a new NoOpStringPrinter
	class, and then using it for string-like values.  This printer returns
	a lazy string, which solves the problem.

	Note there are some special cases where we do not want to return a
	lazy string.  I've documented these in the code.  I considered making
	gdb.Value.lazy_string handle these cases -- for example it could
	return 'self' rather than a lazy string in some situations -- but this
	approach was simpler.

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Clean up 0-length handling in gdbpy_create_lazy_string_object
	gdbpy_create_lazy_string_object will throw an exception if you pass it
	a NULL pointer without also setting length=0 -- the default,
	length==-1, will fail.  This seems bizarre.  Furthermore, it doesn't
	make sense to do this check for array types, as an array can have a
	zero length.  This patch cleans up the check and makes it specific to
	TYPE_CODE_PTR.

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Reject non-string types in gdb.Value.lazy_string
	Currently, gdb.Value.lazy_string will allow the conversion of any
	object to a "lazy string".  However, this was never the intent and is
	weird besides.  This patch changes this code to correctly throw an
	exception in the non-matching cases.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20769

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Fix error check in gdb_py_test_silent_cmd
	I added a new test using gdb_py_test_silent_cmd, and then was
	surprised to find out that the new test passed -- it caused a Python
	exception and I had expected it to fail.  This patch fixes this proc
	to detect this situation and fail.

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Omit artificial symbols from DAP variables response
	While testing DAP, we found a situation where a compiler-generated
	variable caused the "variables" request to fail -- the variable in
	question being an apparent 67-megabyte string.

	It seems to me that artificial variables like this aren't interesting
	to DAP users, and the gdb CLI omits these as well.

	This patch changes DAP to omit these variables, adding a new
	gdb.Symbol.is_artificial attribute to make this possible.

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Defer DAP launch command until after configurationDone
	PR dap/32090 points out that gdb's DAP "launch" sequencing is
	incorrect.  The current approach (which is itself a 2nd
	implementation...) was based on a misreading of the spec.  The spec
	has since been clarified here:

	    https://github.com/microsoft/debug-adapter-protocol/issues/497

	The clarification here is that a client is free to send the "launch"
	(or "attach") request at any point after the "initialized" event has
	been sent by gdb.  However, the "launch" does not cause any action to
	be taken -- and does not send a response -- until after
	"configurationDone" has been seen.

	This patch implements this by arranging for the launch and attach
	commands to return a DeferredRequest object.

	All the tests needed updates.  I've also added a new test that checks
	that the deferred "launch" request can be cancelled.  (Note that the
	cancellation is lazy -- it also waits until configurationDone is seen.
	This could be fixed, but I was not sure whether it is important to do
	so.)

	Finally, the "launch" command has a somewhat funny sequencing now.
	Simply sending the command and waiting for a response yielded strange
	results if the inferior did not stop -- in this case, the repsonse was
	never sent.  So now, the command is split into two parts, with some
	setup being done synchronously (for better error propagation) and the
	actual "run" being done async.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090
	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Add DAP deferred requests
	This adds a new "deferred request" capability to DAP.  The idea here
	is that if a request returns a DeferredRequest object, then no
	response is sent immediately to the client.  Instead, the request is
	pending until the deferred request is rescheduled.

	Some minor refactorings, particularly in cancellation, were needed to
	make this work.

	There's no use of this in the tree yet -- that is the next patch.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Allow cancellation of DAP-thread requests
	This patch started as an attempt to fix the comment in
	CancellationHandler.cancel, but while working on it I found that the
	code could be improved as well.

	The current DAP cancellation code only handles the case where work is
	done on the gdb thread -- by checking for cancellation in
	interruptable_region.  This means that if a request is handled
	completely in tthe DAP thread, then cancellation will never work.

	Now, this isn't a bug per se.  DAP doesn't actually require that
	cancellation succeed.  In fact, I think it can't, because cancellation
	is inherently racy.

	However, a coming patch will add a sort of "pending" request, and it
	would be nice if that were cancellable before any commands are sent to
	the gdb thread.

	No test in this patch, but one will arrive at the end of the series.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Refactor CancellationHandler in DAP
	This refactors the DAP CancellationHandler to be a context manager,
	and reorganizes the caller to use this.  This is a bit more robust and
	also simplifies a subsequent patch in this series.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Add call_function_later to DAP
	This adds a new call_function_later API to DAP.  This arranges to run
	a function after the current request has completed.  This isn't used
	yet, but will be at the end of this series.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Reimplement DAP delayed events
	This patch changes how delayed events are implemented in DAP.  The new
	implementation makes it simpler to add a delayed function call, which
	will be needed by the final patch in this series.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom Tromey  <tromey@adacore.com>

	Reimplement DAP's stopAtBeginningOfMainSubprogram
	Right now, stopAtBeginningOfMainSubprogram is implemented "by hand",
	but then later the launch function uses "starti" to implement
	stopOnEntry.  This patch unifies this code and rewrites it to use
	"start" when appropriate.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2024-12-09  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Apply workaround for PR gas/31115 a bit more
	In commit 8a61ee551ce ("[gdb/symtab] Workaround PR gas/31115"), I applied a
	workaround for PR gas/31115 in read_func_scope, fixing test-case
	gdb.arch/pr25124.exp.

	Recently I noticed that the test-case is failing again.

	Fix this by factoring out the workaround into a new function fixup_low_high_pc
	and applying it in dwarf2_die_base_address.

	While we're at it, do the same in dwarf2_record_block_ranges.

	Tested on arm-linux with target boards unix/-marm and unix/-mthumb.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-12-09  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Generate aarch64-linux.xml.in in update-linux-from-src.sh
	Currently aarch64-linux.xml.in is skipped by update-linux-from-src.sh:
	...
	$ ./update-linux-from-src.sh ~/upstream/linux-stable.git/
	Skipping aarch64-linux.xml.in, no syscall.tbl
	  ...
	$
	...
	and instead we use update-linux.sh.

	This works fine, but requires an aarch64 system with recent system headers,
	which makes it harder to pick up the latest changes in the linux kernel.

	Fix this by updating ./update-linux-from-src.sh to:
	- build the linux kernel headers for aarch64
	- use update-linux.sh with those headers to generate
	  aarch64-linux.xml.in.

	Regenerating aarch64-linux.xml.in using current trunk of linux-stable gives me
	these changes:
	...
	+  <syscall name="setxattrat" number="463"/>
	+  <syscall name="getxattrat" number="464"/>
	+  <syscall name="listxattrat" number="465"/>
	+  <syscall name="removexattrat" number="466"/>
	...
	which are the same changes I see for the other architectures.

	Note that the first step, building the linux kernel headers is a cross build
	and should work on any architecture.

	But the second step, update-linux.sh uses plain gcc rather than a cross-gcc,
	so there is scope for problems, but we seem to get away with this on
	x86_64-linux.

	So, while we could constrain this to only generate aarch64-linux.xml.in on
	aarch64-linux, I'm leaving this unconstrained.

	For aarch64-linux.xml.in, this doesn't matter much to me because I got an
	aarch64-linux system.

	But I don't have a longaarch system, and the same approach seems to work
	there.  I'm leaving this for follow-up patch though.

	Tested on aarch64-linux and x86_64-linux.  Verified with shellcheck.

2024-12-09  Mark Wielaard  <mark@klomp.org>

	Include gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c
	Commit c8889b913175 ("gdb, gdbserver, gdbsupport: remove some unused
	gdb_vecs.h includes") removed gdbsupport/gdb_vecs.h from various
	header files. This caused an compile issue for gdb/s390-linux-nat.c

	../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_watchpoint(CORE_ADDR, int, target_hw_bp_type, expression*)’:
	../../binutils-gdb/gdb/s390-linux-nat.c:875:11: error: ‘unordered_remove’ was not declared in this scope
	  875 |           unordered_remove (state->watch_areas, ix);
	      |           ^~~~~~~~~~~~~~~~
	../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_hw_breakpoint(gdbarch*, bp_target_info*)’:
	../../binutils-gdb/gdb/s390-linux-nat.c:928:11: error: ‘unordered_remove’ was not declared in this scope
	  928 |           unordered_remove (state->break_areas, ix);
	      |           ^~~~~~~~~~~~~~~~

	Fix this by including gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c.

2024-12-09  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: remove 'struct' in 'struct thread_info' declarations
	Remove the 'struct' keyword in occurrences of 'struct thread_info'.
	This is a code clean-up.

	Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-09  Nick Clifton  <nickc@redhat.com>

	Add linker diagnostic message about missing static libraries

2024-12-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: allow core file containing special characters on the command line
	After the commit:

	  commit 03ad29c86c232484f9090582bbe6f221bc87c323
	  Date:   Wed Jun 19 11:14:08 2024 +0100

	      gdb: 'target ...' commands now expect quoted/escaped filenames

	it was no longer possible to pass GDB the name of a core file
	containing any special characters (white space or quote characters) on
	the command line.  For example:

	  $ gdb -c /tmp/core\ file.core
	  Junk after filename "/tmp/core": file.core
	  (gdb)

	The problem is that the above commit changed the 'target core' command
	to expect quoted filenames, so before the above commit a user could
	write:

	  (gdb) target core /tmp/core file.core
	  [New LWP 2345783]
	  Core was generated by `./mkcore'.
	  Program terminated with signal SIGSEGV, Segmentation fault.
	  #0  0x0000000000401111 in ?? ()
	  (gdb)

	But after the above commit the user must write:

	  (gdb) target core /tmp/core\ file.core

	or

	  (gdb) target core "/tmp/core file.core"

	This is part of a move to make GDB's filename argument handling
	consistent.

	Anyway, the problem with the '-c' command line flag is that it
	forwards the filename unmodified through to the 'core-file' command,
	which in turn forwards to the 'target core' command.

	So when the user, at a shell writes:

	  $ gdb -c "core file.core"

	this arrives in GDB as the unquoted string 'core file.core' (without
	the single quotes).  GDB then forwards this to the 'core-file'
	command as if the user had written this at a GDB prompt:

	  (gdb) core-file core file.core

	Which then fails to parse due to the unquoted white space between
	'core' and 'file.core'.

	The solution I propose is to escape any special characters in the core
	file name passed from the command line before calling 'core-file'
	command from main.c.

	I've updated the corefile.exp test to include a test for passing a
	core file containing a white space character.  While I was at it I've
	modernised the part of corefile.exp that I was touching.

2024-12-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: make core_target_open static
	The core_target_open function is only used in corelow.c, so lets make
	it static.

	There should be no user visible changes after this commit.

2024-12-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: use 'const' more in a couple of small breakpoint functions
	Make the 'struct breakpoint *' argument 'const' in user_breakpoint_p
	and pending_breakpoint_p.  And make the 'struct bp_location *'
	argument 'const' in bl_address_is_meaningful.

	There should be no user visible changes after this commit.

2024-12-09  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Assign DWARF register numbers to register aliases
	.cfi directives only support the use of register numbers and not
	register names or aliases.

	This commit adds support for 4 formats, for example:
	  .cfi_offset r1, 8
	  .cfi_offset ra, 8
	  .cfi_offset $r1,8
	  .cfi_offset $ra,8

	The above .cfi directives are equivalent and all represent dwarf
	register number 1.

	Display register aliases as specified in the psABI during disassembly.

2024-12-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: simplify win32 process removal
	In the spirit of encapsulation, I'm looking to remove the need for
	external code to access the "ptid -> thread" map of process_info, making
	it an internal implementation detail.  The only remaining use is in
	function clear_inferiors, and it led me down this rabbit hole:

	 - clear_inferiors is really only used by the Windows port and doesn't
	   really make sense in the grand scheme of things, I think (when would
	   you want to remove all threads of all processes, without removing
	   those processes?)

	 - ok, so let's remove clear_inferiors and inline the code where it's
	   called, in function win32_clear_inferiors

	 - the Windows port does not support multi-process, so it's not really
	   necessary to loop over all processes like this:

	       for_each_process ([] (process_info *process)
	         {
	           process->thread_list ().clear ();
	           process->thread_map ().clear ();
	         });

	   We could just do:

	     current_process ()->thread_list ().clear ();
	     current_process ()->thread_map ().clear ();

	   (or pass down the process from the caller, but it's not important
	   right now)

	 - so, the code that we've inlined in win32_clear_inferiors does 3
	   things:

	    - clear the process' thread list and map (which deletes the
	      thread_info objects)

	    - clear the dll list, which just basically frees some objects

	    - switch to no current process / no current thread

	 - let's now look at where this win32_clear_inferiors function is used:

	     - in win32_process_target::kill, where the process is removed just
	       after

	     - in win32_process_target::detach, where the process is removed
	       just after

	     - in win32_process_target::wait, when handling a process exit.
	       After this returns, we could be in handle_target_event (if async)
	       or resume (if sync), both in `server.cc`.  In both of these
	       cases, target_mourn_inferior gets called, we end up in
	       win32_process_target::mourn, which removes the process

	 - in all 3 cases above, we end up removing the process, which takes
	   care of the 3 actions listed above:

	     - the thread list and map get cleared when the process gets
	       destroyed

	     - same with the dll list

	     - remove_process switches to no current process / current thread
	       if the process being removed is the current one

	 - I conclude that it's probably unnecessary to do the cleanup in
	   win32_clear_inferiors, because it's going to get done right after
	   anyway.

	Therefore, this patch does:

	 - remove clear_inferiors, remove the call in win32_clear_inferiors

	 - remove clear_dlls, which is now unused

	 - remove process_info::thread_map, which is now unused

	 - rename win32_clear_inferiors to win32_clear_process, which seems more
	   accurate

	win32_clear_inferiors also does:

	    for_each_thread (delete_thread_info);

	which also makes sure to delete all threads, but it also deletes the
	Windows private data object (windows_thread_info), so I'll leave this
	one there for now.  But if we could make the thread private data
	destruction automatic, on thread destruction, it could be removed, I
	think.

	There should be no user-visible change with this patch.  Of course,
	operations don't happen in the same order as before, so there might be
	some important detail I'm missing.  I'm only able to build-test this, if
	someone could give it a test run on Windows, it would be appreciated.

	Change-Id: I4a560affe763a2c965a97754cc02f3083dbe6fbf

2024-12-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-06  Alan Modra  <amodra@gmail.com>

	fix dependencies for ld/emultemp/nto.em
	Don't use "." to source .em files, use "source_em".

2024-12-06  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make objfile::make actually use its pspace parameter
	Fix an oversight in commit 8991986e2413 ("gdb: pass program space to
	objfile::make").

	Change-Id: I263eec6e94dde0a9763f831d2d87b4d300b6a36a

2024-12-06  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb, gdbserver, gdbsupport: remove some unused gdb_vecs.h includes
	Remove some includes reported as unused by clangd.  Add some to files
	that actually need it.

	Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363

2024-12-06  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Fix use-after-free when an objfile has no symbols to load
	The recent commit <HASH> moved an initialization of an objfile_holder in
	syms_from_objfile_1 much earlier in the function, to better deal with
	when GDB is unable to read the objfile format.

	However, there is an early exit from syms_from_objfile_1 when the
	objfile can be understood, but has no symbols. That was not releasing
	the objfile_holder, so the objfile was being unlinked from the program
	space, but the process of reading the objfile was being continued,
	leading to use-after-frees flagged by the Address Sanitizer.

	This commit fixes that UAF by making the objfile_holder release the
	objfile right before the early exit.

	This commit also changes the test gdb.base/dump.exp since that was the
	original test that flagged the UAF, but at the end of the test the
	generated files were being deleted, meaning we couldn't redo the test
	manually after the fact. That final deletion was removed

	Reported-by: Simon Marchi <simark@simark.ca>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-06  Hannes Domani  <ssbssa@yahoo.de>

	Reduce WOW64 code duplication
	Currently we have duplicate code for each place where
	windows_thread_info::context is touched, since for WOW64 processes
	it has to do the equivalent with wow64_context instead.

	For example this code...:

	 #ifdef __x86_64__
	   if (windows_process.wow64_process)
	     {
	       th->wow64_context.ContextFlags = WOW64_CONTEXT_ALL;
	       CHECK (Wow64GetThreadContext (th->h, &th->wow64_context));
	       ...
	     }
	   else
	 #endif
	     {
	       th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
	       CHECK (GetThreadContext (th->h, &th->context));
	       ...
	     }

	...changes to look like this instead:

	   windows_process.with_context (th, [&] (auto *context)
	     {
	       context->ContextFlags = WindowsContext<decltype(context)>::all;
	       CHECK (get_thread_context (th->h, context));
	       ...
	     }

	The actual choice if context or wow64_context are used, is handled by
	this new function in windows_process_info:

	   template<typename Function>
	   auto with_context (windows_thread_info *th, Function function)
	   {
	 #ifdef __x86_64__
	     if (wow64_process)
	       return function (th != nullptr ? th->wow64_context : nullptr);
	     else
	 #endif
	       return function (th != nullptr ? th->context : nullptr);
	   }

	The other parts to make this work are the templated WindowsContext class
	which give the appropriate ContextFlags for both types.
	And there are also overloaded helper functions, like in the case of
	get_thread_context here, call either GetThreadContext or
	Wow64GetThreadContext.

	According git log --stat, this results in 120 lines less code.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-06  H.J. Lu  <hjl.tools@gmail.com>

	gold: Update expected outputs in  testsuite/pr26936.sh
	Update expected outputs in testsuite/pr26936.sh to match the assembler
	outputs changed by:

	a96a8b7367b2cd51ff32c69e516dfbe0204c8008 is the first bad commit
	commit a96a8b7367b2cd51ff32c69e516dfbe0204c8008 (HEAD)
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Mon Dec 2 09:38:47 2024 +0100

	    x86: always set ISA_1_BASELINE property for 64-bit objects

		PR gold/32422
		* testsuite/pr26936.sh: Updated.

2024-12-06  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR27566, consider ELF_MAXPAGESIZE/COMMONPAGESIZE for gp relaxations.
	For default linker script, if a symbol's value outsides the bounds of the
	defined section, then it may cross the data segment alignment, so we should
	reserve more size about MAXPAGESIZE and COMMONPAGESIZE when doing gp
	relaxations.  Otherwise we may meet the truncated errors since the data
	segment alignment might move the section forward.

	bfd/
		PR 27566
		* elfnn-riscv.c (_bfd_riscv_relax_lui): Consider MAXPAGESIZE and
		COMMONPAGESIZE if the symbol's value outsides the bounds of the
		defined section.
		(_bfd_riscv_relax_pc): Likewise.
	ld/
		PR 27566
		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
		* testsuite/ld-riscv-elf/relax-data-segment-align*: New testcase
		for pr27566.  Without this patch, the rv32 binutils will meet
		truncated errors for this testcase.

2024-12-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver/win32-low.cc: remove use of `all_threads`
	Fix this:

	    gdbserver/win32-low.cc: In function ‘void child_delete_thread(DWORD, DWORD)’:
	    gdbserver/win32-low.cc:192:7: error: ‘all_threads’ was not declared in this scope; did you mean ‘using_threads’?
	      192 |   if (all_threads.size () == 1)
	          |       ^~~~~~~~~~~
	          |       using_threads

	Commit 9f77b3aa0bfc ("gdbserver: change 'all_processes' and
	'all_threads' list type") changed the type of `all_thread` to an
	intrusive_list, without changing this particular use, which broke the
	build because an intrusive_list doesn't know its size, so it doesn't
	have a `size()` method.  The subsequent commit removed `all_threads`,
	leading to the error above.

	Fix it by using the number of threads of the concerned process instead.
	My rationale: as far as I know, GDBserver on Windows only supports one
	process at a time, so there's no need to iterate over all processes.  If
	we made GDBserver for Windows support multiple processes, my intuition
	is that we'd want this check to use the number of threads of the
	concerned process, not the number of threads overall.

	Add the method `process_info::thread_count`, to get the number of
	threads of the process.

	I'm not really sure what this check is for in the first place, Hannes
	Domani said that this check didn't seem to trigger on Windows 7 and 11.
	Perhaps it was necessary before.

	Change-Id: I84d6226532b887d99248cf3be90f5065fb7a074a
	Tested-By: Hannes Domani <ssbssa@yahoo.de>

2024-12-05  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: add and use `process_info::find_thread(ptid)`
	Add an overload of `process_info::find_thread` that finds a thread by
	ptid.  Use it in two spots.

	Change-Id: I2b7fb819bf4f83f7bd37f8641c38e878119b3814

2024-12-05  Nick Clifton  <nickc@redhat.com>

	Fix clang compile time warning about optarg parameter shadowing optarg global variable.

2024-12-05  Hu, Lin1  <lin1.hu@intel.com>
	    Zewei Mo  <zewei.mo@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>
	    Levy Hsu  <admin@levyhsu.com>

	Support Intel AVX10.2 satcvt instructions
	In this patch, we will support AVX10.2 satcvt instructions. All of them
	are new instruction forms. In current documentation, it is still
	VCVTTNEBF162I[,U]BS, but it will change to VCVTTBF162I[,U]BS eventually.

	In table part, we used temporary <sign> iterator to reduce redundancy.
	It definitely could be done for legacy cvt insns, but it is out of this
	patch's scope.

	gas/ChangeLog:

		* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-512-satcvt-intel.d: New test.
		* testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_68, PREFIX_EVEX_MAP5_69,
		PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B, PREFIX_EVEX_MAP5_6C,
		PREFIX_EVEX_MAP5_6D.
		* i386-dis-evex-w.h: Add EVEX_W_MAP5_6C_P_0, EVEX_W_MAP5_6C_P_2,
		EVEX_W_MAP5_6D_P_0, EVEX_W_MAP5_6D_P_2.
		* i386-dis-evex.h (prefix_table): Add PREFIX_EVEX_MAP5_68,
		* PREFIX_EVEX_MAP5_69, PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B.
		* i386-dis.c: (PREFIX_EVEX_MAP5_68): New.
		(PREFIX_EVEX_MAP5_69): Ditto.
		(PREFIX_EVEX_MAP5_6A): Ditto.
		(PREFIX_EVEX_MAP5_6B): Ditto.
		(PREFIX_EVEX_MAP5_6C): Ditto.
		(PREFIX_EVEX_MAP5_6D): Ditto.
		(EVEX_MAP5_6C_P_0): Ditto.
		(EVEX_MAP5_6C_P_2): Ditto.
		(EVEX_MAP5_6D_P_0): Ditto.
		(EVEX_MAP5_6D_P_2): Ditto.
		* i386-opc.tbl: Add AVX10.2 instructions.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-12-05  H.J. Lu  <hjl.tools@gmail.com>
	    Haochen Jiang  <haochen.jiang@intel.com>

	x86: Eliminate unnecessary {evex} prefixes
	For several instructions including vps{l,r}l{d,q,w,dq} and vpsra{d,w},
	their VEX part do not have the following version:

		vpsrlw $0x1f,(%r15,%rcx,4),%xmm0

	Thus, {evex} prefix should not be inserted when their second operand is
	memory, while we still need them for register as second operand. Add a
	new macro %ME to solve this problem.

	For vpsraq, there is no VEX version, so the {evex} prefix should always
	be eliminated.

	gas/ChangeLog:

		PR binutils/32403
		* testsuite/gas/i386/i386.exp: Run new test.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/evex-only.d: New test.
		* testsuite/gas/i386/evex-only.s: Ditto.
		* testsuite/gas/i386/x86-64-evex-only.d: Ditto.
		* testsuite/gas/i386/x86-64-evex-only.s: Ditto.

	opcodes/ChangeLog:

		PR binutils/32403
		* i386-dis-evex-reg.h: Use %ME instead of %XE for vps{l,r}l{w,dq}
		and vpsraw. Split table for vpsra{d,q}.
		* i386-dis-evex-w.h: Use %ME instead of %XE for vps{l,r}l{d,q}
		and vpsrad. Eliminate vpsraq {evex} prefix.
		* i386-dis-evex.h: Split table for vpsra{d,q}.
		* i386-dis.c: (EVEX_W_0F72_R_4): New.
		(EVEX_W_0FE2): Ditto.
		(struct dis386): Add comment for %ME.
		(putop): Handle %ME.

2024-12-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix parsing of DIEs with both low/high pc AND ranges attributes
	After the commit:

	  commit b9de07a5ff74663ff39bf03632d1b2ea417bf8d5
	  Date:   Thu Oct 10 11:37:34 2024 +0100

	      gdb: fix handling of DW_AT_entry_pc of inlined subroutines

	GDB's buildbot CI testing highlighted this assertion failure:

	  (gdb) c
	  Continuing.
	  ../../binutils-gdb/gdb/block.h:203: internal-error: set_entry_pc: Assertion `start >= this->start () && start < this->end ()' failed.
	  A problem internal to GDB has been detected,
	  further debugging may prove unreliable.
	  ----- Backtrace -----
	  FAIL: gdb.base/break-probes.exp: run til our library loads (GDB internal error)

	This assertion was in the new function set_entry_pc and is asserting
	that the default_entry_pc() value is within the blocks start/end
	range.

	The default_entry_pc() is the value GDB will use as the entry-pc if
	the DWARF doesn't specifically override the entry-pc.  This value is
	calculated as:

	  1. The start address of the first sub-range within the block, if the
	  block has more than 1 range, or

	  2. The low address (from DW_AT_low_pc) for the block.

	If the block only has a single range then this means the block was
	defined with low/high pc attributes (case #2 above).  These low/high
	pc values are what block::start() and block::end() return.  This means
	that by definition, if the block is continuous, the above assert
	cannot trigger as 'start', the default_entry_pc() would be equivalent
	to block::start().

	This means that, for the assert to trigger, the block must have
	multiple ranges, and the first address of the first range is not
	within the blocks low/high address range.  This seems wrong.

	I inspected the state at the time the assert triggered and discovered
	the block's start() address.  Then I removed the assert and restarted
	GDB.  I was now able to inspect the blocks at the offending address:

	  (gdb) maintenance info blocks 0x7ffff7dddaa4
	  Blocks at 0x7ffff7dddaa4:
	    from objfile: [(objfile *) 0x44a37f0] /lib64/ld-linux-x86-64.so.2
	 [(block *) 0x46b30c0] 0x7ffff7ddd5a0..0x7ffff7dde8a6
	    entry pc: 0x7ffff7ddd5a0
	    is global block
	    symbol count: 4
	    is contiguous
	  [(block *) 0x46b3020] 0x7ffff7ddd5a0..0x7ffff7dde8a6
	    entry pc: 0x7ffff7ddd5a0
	    is static block
	    symbol count: 9
	    is contiguous
	  [(block *) 0x46b2f70] 0x7ffff7ddda00..0x7ffff7dddac3
	    entry pc: 0x7ffff7ddda00
	    function: __GI__dl_find_dso_for_object
	    symbol count: 4
	    is contiguous
	  [(block *) 0x46b2e10] 0x7ffff7dddaa4..0x7ffff7dddac3
	    entry pc: 0x7ffff7dddaa4
	    inline function: __GI__dl_find_dso_for_object
	    symbol count: 5
	    is contiguous
	  [(block *) 0x46b2a40] 0x7ffff7dddaa4..0x7ffff7dddac3
	    entry pc: 0x7ffff7dddaa4
	    symbol count: 1
	    is contiguous
	  [(block *) 0x46b2970] 0x7ffff7dddaa4..0x7ffff7dddac3
	    entry pc: 0x7ffff7dddaa4
	    symbol count: 2
	    address ranges:
	      0x7ffff7ddda0e..0x7ffff7ddda77
	      0x7ffff7ddda90..0x7ffff7ddda96

	I've left everything in for context, but the only really interesting
	bit is the very last block, it's low/high range is:

	  0x7ffff7dddaa4..0x7ffff7dddac3

	but it has separate ranges:

	  0x7ffff7ddda0e..0x7ffff7ddda77
	  0x7ffff7ddda90..0x7ffff7ddda96

	which are all outside the low/high range.  This is what triggers the
	assert.  But why does that block exist at all?

	What I believe is happening is that we're running into a bug in older
	versions of GCC.  The buildbot failure was with an 8.5 gcc, and Tom de
	Vries also reported seeing failures when using version 7 and 8 gcc,
	but not with gcc 9 and onward.

	Looking at the DWARF I can see that the problematic block is created
	from this DIE:

	  <4><15efb>: Abbrev Number: 83 (DW_TAG_lexical_block)
	     <15efc>   DW_AT_abstract_origin: <0x15e9f>
	     <15efe>   DW_AT_low_pc      : 0x7ffff7dddaa4
	     <15f06>   DW_AT_high_pc     : 31

	which links via DW_AT_abstract_origin to:

	  <2><15e9f>: Abbrev Number: 80 (DW_TAG_lexical_block)
	     <15ea0>   DW_AT_ranges      : 0x38e0
	     <15ea4>   DW_AT_sibling     : <0x15eca>

	And so we can see that <15efb> has got both low/high pc attributes and
	a ranges attribute.

	If I widen my checking to parents of DIE <15efb> then I see that they
	also have DW_AT_abstract_origin, however, there is something
	interesting going on, the parent DIEs are linking to a different DIE
	tree than <15efb>.

	What I believe is happening is this, we have an abstract instance
	tree, this is rooted at a DW_AT_subprogram, and contains all the
	blocks, variables, parameters, etc, that you would expect.  As this is
	an abstract instance, then there are no low/high pc attributes, and no
	ranges attributes in this tree.  This makes sense.

	Now elsewhere we have a DW_TAG_subprogram (not
	DW_TAG_inlined_subroutine) which links via
	DW_AT_abstract_origin to the abstract DW_AT_subprogram.  This case is
	documented in the DWARF 5 spec in section 3.3.8.3, and describes an
	Out-of-Line Instance of an Inlined Subroutine.  Within this out of
	line instance many of the DIE correctly link back, using
	DW_AT_abstract_origin to the abstract instance tree.  This tree also
	includes the DIE <15e9f>, which is where our problem DIE references.

	Now, to really confuse things, within this out-of-line instance we
	have a DW_TAG_inlined_subroutine, which is another instance of the
	same abstract instance tree!  This would seem to indicate a recursive
	call to the inline function, and the compiler, for some reason, needed
	to instantiate an out of line instance of this function.

	And it is within this nested, inlined subroutine, that the problem DIE
	exists.  The problem DIE is referencing the corresponding DIE within
	the out of line instance tree, but I am convinced this must be a (long
	fixed) GCC bug, and that the problem DIE should be referencing the DIE
	within the abstract instance tree.

	I'm aware that the above is pretty confusing.  The actual DWARF would
	be a around 200 lines long, so I'd like to avoid dumping it in here.
	But here's my attempt at representing what's going on in a minimal
	example.  The numbers down the side represent the section offset, not
	the nesting level, and I've removed any attributes that are not
	relevant:

	  <1> DW_TAG_subprogram
	  <2>   DW_TAG_lexical_block
	  <3> DW_TAG_subprogram
	        DW_AT_abstract_origin <1>
	  <4>   DW_TAG_lexical_block
	          DW_AT_ranges ...
	  <5>   DW_TAG_inlined_subroutine
	          DW_AT_abstract_origin <1>
	  <6>     DW_TAG_lexical_block
	            DW_AT_abstract_origin <4>
	            DW_AT_low_pc ...
	            DW_AT_high_pc ...

	The lexical block at <6> is linking to <4> when it should be linking
	to <2>.

	There is one additional thing that we might wonder about, which is,
	when calculating the low/high pc range for a block, why does GDB not
	make use of the range information and expand the range beyond the
	defined low/high values?

	The answer to this is in dwarf_get_pc_bounds_ranges_or_highlow_pc in
	dwarf/read.c.  This is where the low/high bounds are calculated.  What
	we see is that GDB first checks for a low/high attribute pair, and if
	that is present, this defines the address range for the block.  Only
	if there is no DW_AT_low_pc do we check for the DW_AT_ranges, and use
	that to define the extent of the block.  And this makes sense, section
	3.5 of the DWARF-5 spec says:

	  The lexical block entry may have either a DW_AT_low_pc and DW_AT_high_pc
	  pair of attributes or a DW_AT_ranges attribute whose values encode the
	  contiguous or non-contiguous address ranges, respectively, of the machine
	  instructions generated for the lexical block...

	Section 3.5 is specifically about lexical blocks, but the same
	wording, about it being either low/high OR ranges is repeated for
	other DW_TAG_ types.

	So this explains why GDB doesn't use the ranges to expand the problem
	blocks ranges; as the first DIE has low/high addresses, these are
	used, and the ranges is not consulted.

	It is only later in dwarf2_record_block_ranges that we create a range
	based off the low/high pc, and then also process the ranges data, this
	allows the problem block to exist with ranges that are outside the
	low/high range.

	To solve this I considered a number of options:

	1. Prevent loading certain attributes from an abstract instance.

	Section 3.3.8.1 of the DWARF-5 spec talks about which attributes are
	appropriate to place in an abstract instance.  Any attribute that
	might vary between instances should not appear in an abstract
	instance.  DW_AT_ranges is included as an example in the
	non-exhaustive list of attributes that should not appear in an
	abstract instance.

	Currently in dwarf2_attr (dwarf2/read.c), when we see a
	DW_AT_abstract_origin attribute, we always follow this to try and find
	the attribute we are looking for.  But we could change this function
	so that we prevent this following for attributes that we know should
	not be looked up in an abstract instance.  This would solve the
	problem in this case by preventing us finding the DW_AT_ranges in the
	incorrect abstract instance.

	2. Filter the ranges.

	Having established a blocks low/high address range in
	dwarf_get_pc_bounds_ranges_or_highlow_pc, we could allow
	dwarf2_record_block_ranges to parse the ranges, but we could reject
	any range that extends outside the blocks defined start and end
	addresses.

	For well behaved DWARF where we have either low/high or ranges, then
	the blocks start/end are defined from the range data, and so, by
	definition, every range would be acceptable.

	But in our problem case we would reject all of the invalid ranges.

	This is my least favourite solution as it feels like rejecting the
	ranges is tackling the problem too late on.

	3. Don't try to parse ranges when we have low/high attributes.

	This option involves updating dwarf2_record_block_ranges to match the
	behaviour of dwarf_get_pc_bounds_ranges_or_highlow_pc, and, I believe,
	to match the DWARF spec: don't try to read range data from
	DW_AT_ranges if we have low/high pc attributes.

	In our case this solves the issue because the problematic DIE has the
	low/high attributes, and it then links to the wrong DIE which happens
	to have DW_AT_ranges.  With this change in place we don't even look
	for the DW_AT_ranges.

	If the problem were reversed, and the initial DIE had DW_AT_ranges,
	but the incorrectly referenced DIE had the low/high pc attributes,
	we would pick up the wrong addresses, but this wouldn't trigger any
	asserts.  The reason is that dwarf_get_pc_bounds_ranges_or_highlow_pc
	would also find the low/high addresses from the incorrectly referenced
	DIE, and so we would just end up with a block which had the wrong
	address ranges, but the block would be self consistent, which is
	different to the problem we hit here.

	In the end, in this commit I went with solution #3, having
	dwarf_get_pc_bounds_ranges_or_highlow_pc and
	dwarf2_record_block_ranges be consistent seems sensible.  However, I
	do wonder if in the future we might want to explore solution #1 as an
	additional safety feature.

	With this patch in place I'm able to run the gdb.base/break-probes.exp
	without seeing the assert that CI testing highlighted.  I see no
	regressions when testing on x86-64 GNU/Linux with gcc  9.3.1.

	Note: the diff in this commit looks big, but it's really just me
	indenting the code.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Remove includes of gdbsupport/common-defs.h
	In commit 18d2988e5da ("gdb, gdbserver, gdbsupport: remove includes of early
	headers") all includes of gdbsupport/common-defs.h where removed, but
	commit c1cdee0e2c1 ("gdb: LoongArch: Add support for hardware watchpoint")
	reintroduced some.

	Fix this by removing them.

	Tested by doing this on x86_64-linux:
	...
	$ make \
	    nat/loongarch-hw-point.o \
	    nat/loongarch-linux.o \
	    nat/loongarch-linux-hw-point.o
	  CXX    nat/loongarch-hw-point.o
	  CXX    nat/loongarch-linux.o
	  CXX    nat/loongarch-linux-hw-point.o
	...

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-04  Simon Marchi  <simark@simark.ca>

	[gdb/build] Fix build breaker on mingw-w64
	The mingw-w64 build breaks currently:
	...
	    In file included from gdb/cli/cli-cmds.c:58:
	    gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’:
	    gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \
	                                     did you mean ‘gdb::waitpid’?
	       77 |   return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options);
	          |                                   ^~~~~~~
	          |                                   gdb::waitpid
	    gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here
	       75 | waitpid (pid_t pid, int *wstatus, int options)
	          | ^~~~~~~
	...

	This is a regression since commit 658a03e9e85 ("[gdbsupport] Add
	gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from
	run_under_shell, where it was used conditionally:
	...
	 #if defined(CANT_FORK) || \
	       (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK))
	   ...
	 #else
	   ...
	       int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0);
	...
	to gdb::waitpid, where it's used unconditionally:
	...
	inline pid_t
	waitpid (pid_t pid, int *wstatus, int options)
	{
	  return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options);
	}
	...

	Likewise for ::wait.

	Guard these uses with HAVE_WAITPID and HAVE_WAIT.

	Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux.

	Reported-By: Simon Marchi <simark@simark.ca>
	Co-Authored-By: Tom de Vries <tdevries@suse.de>

2024-12-04  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: make thread_target_data a method of thread_info
	Make the field private, change the free function to be a method.

	Change-Id: I05010e7d1bd58ce3895802eb263c029528427758
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: make thread_regcache_data / set_thread_regcache_data methods of thread_info
	Make the field private, change the free functions to be methods.

	Change-Id: Ifd8ed2775dddefc73a0e00126182e1db02688af4
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: make get_thread_lwp a function
	Replace the macro with a static inline function.

	Change-Id: I1cccf5b38d6a412d251763f0316902b07cc28d16
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove macro get_lwp_thread
	I was thinking of changing this macro to a function, but I don't think
	it adds much value over just accessing the field directly.

	Change-Id: I5dc63e9db0773549c5b55a1279212e2d1213f50c
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Stephan Rohr  <stephan.rohr@intel.com>

	gdb, testsuite: fix TCL error in 'gdb.base/structs.exp'
	A failure of 'runto_main' in 'start_structs_test' results in a TCL
	error.  The return value of 'start_structs_test' function is evaluated
	inside an if conditional clause, which expects a boolean value.  Return
	'-1' on failure to avoid the error.

	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix failure in gdb.python/py-startup-opt.exp
	In commit 922ab963e1c ("[gdb/python] Handle empty PYTHONDONTWRITEBYTECODE") I
	added a test in gdb.python/py-startup-opt.exp that checks the
	"show python dont-write-bytecode" output.

	Then in commit 348290c7ef4 ("[gdb/python] Warn and ignore ineffective python
	settings") I changed the output of "show python dont-write-bytecode" after
	python initialization.

	I tested these changes individually, and found no problems but after
	committing both the test started failing, which the Linaro CI reported.

	Fix this by updating the expected output.

	While we're at it, make the test a bit more generic by testing
	"show python $setting" in all cases.

	Tested on x86_64-linux, using:
	- PYTHONDONTWRITEBYTECODE=
	- PYTHONDONTWRITEBYTECODE=1
	- unset PYTHONDONTWRITEBYTECODE

2024-12-04  Tom Tromey  <tom@tromey.com>

	Fix "maint print" error messages
	While working on an earlier patch, I noticed that all the
	register-related "maint print" commands used the wrong command name in
	an error message.  This fixes them.

	Reviewed-by: Christina Schimpe <christina.schimpe@intel.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-04  Tom Tromey  <tom@tromey.com>

	Use ui-out table in "maint print reggroups"
	This changes the "maint print reggroups" command to use a ui-out table
	rather than printf.

	It also fixes a typo I noticed in a related test case name; and lets
	us finally remove the leading \s from the regexp in completion.exp.

	Reviewed-by: Christina Schimpe <christina.schimpe@intel.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-04  Tom Tromey  <tom@tromey.com>

	Use ui-out tables in some "maint print" commands
	This changes various "maint print" register commands to use ui-out
	tables rather than the current printf approach.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix DUPLICATE in gdb.arch/pr25124.exp
	With test-case gdb.arch/pr25124.exp, I run into:
	...
	PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try)
	PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try)
	DUPLICATE: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try)
	...

	Fix this by using a comma instead of parentheses.

	Tested on arm-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Issue warning if python fails to initialize
	A common problem is that python may fail to initialize if PYTHONHOME is
	set incorrectly, or points to incompatible default libraries.

	Likewise if PYTHONPATH points to incompatible modules.

	For instance, say PYTHONHOME is foo, then we get:
	...
	$ gdb -q
	Python path configuration:
	  PYTHONHOME = 'foo'
	  PYTHONPATH = (not set)
	  program name = '/usr/bin/python'
	  isolated = 0
	  environment = 1
	  user site = 1
	  safe_path = 0
	  import site = 1
	  is in build tree = 0
	  stdlib dir = 'foo/lib64/python3.12'
	  sys._base_executable = '/usr/bin/python'
	  sys.base_prefix = 'foo'
	  sys.base_exec_prefix = 'foo'
	  sys.platlibdir = 'lib64'
	  sys.executable = '/usr/bin/python'
	  sys.prefix = 'foo'
	  sys.exec_prefix = 'foo'
	  sys.path = [
	    'foo/lib64/python312.zip',
	    'foo/lib64/python3.12',
	    'foo/lib64/python3.12/lib-dynload',
	  ]
	Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
	Python not initialized
	$
	...

	In this case, it might be easy to figure out what went wrong because of the
	obviously incorrect pathnames, but that might not be the case if PYTHONHOME
	points to an incompatible python installation.

	Fix this by adding a warning with a description of the possible cause and what
	to do about it:
	...
	Python initialization failed: \
	  failed to get the Python codec of the filesystem encoding
	gdb: warning: Python failed to initialize with PYTHONHOME set.  Maybe because \
	  it is set incorrectly? Maybe because it points to incompatible standard \
	  libraries? Consider changing or unsetting it, or ignoring it using "set \
	  python ignore-environment on" at early initialization.
	...

	Likewise for PYTHONPATH:
	...
	Python initialization failed: \
	  failed to get the Python codec of the filesystem encoding
	gdb: warning: Python failed to initialize with PYTHONPATH set.  Maybe because \
	  it points to incompatible modules? Consider changing or unsetting it, or \
	  ignoring it using "set python ignore-environment on" at early \
	  initialization.
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/32379
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Handle empty PYTHONDONTWRITEBYTECODE
	When using PYTHONDONTWRITEBYTECODE with an empty string we get:
	...
	$ PYTHONDONTWRITEBYTECODE= gdb -q -batch -ex "show python dont-write-bytecode"
	Python's dont-write-bytecode setting is auto (currently on).
	...

	This is incorrect, it should be off.

	The actual setting is correct, that was already fixed in commit 24d2cbc42cc
	("set/show python dont-write-bytecode fixes"), in function
	python_write_bytecode.

	Fix this by:
	- factoring out new function env_python_dont_write_bytecode out of
	  python_write_bytecode, and
	- using it in show_python_dont_write_bytecode.

	Tested on x86_64-linux, using test-case gdb.python/py-startup-opt.exp and:
	- PYTHONDONTWRITEBYTECODE=
	- PYTHONDONTWRITEBYTECODE=1
	- unset PYTHONDONTWRITEBYTECODE

	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/32389
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32389

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-startup-opt.exp with empty PYTHONDONTWRITEBYTECODE
	When running test-case gdb.python/py-startup-opt.exp with empty
	PYTHONDONTWRITEBYTECODE:
	...
	$ cd build/gdb/testsuite
	$ PYTHONDONTWRITEBYTECODE= make check \
	    RUNTESTFLAGS=gdb.python/py-startup-opt.exp
	...
	I get:
	...
	end^M
	dont_write_bytecode is off^M
	(gdb) FAIL: $exp: attr=dont_write_bytecode: testname: input 6: end
	...

	The problem is that the test-case expects dont_write_bytecode to be
	on, which is incorrect because PYTHONDONTWRITEBYTECODE only has effect if set
	to a non-empty string [1].

	Fix this by correctly setting expectations in the test-case.

	Tested on x86_64-linux, with:
	- PYTHONDONTWRITEBYTECODE=
	- PYTHONDONTWRITEBYTECODE=1
	- unset PYTHONDONTWRITEBYTECODE

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Warn and ignore ineffective python settings
	Configuration flags "python dont-write-bytecode" and
	"python ignore-environment" have effect only at Python initialization.

	For instance, setting "python dont-write-bytecode" here has no effect:
	...
	$ gdb -q
	(gdb) show python dont-write-bytecode
	Python's dont-write-bytecode setting is auto (currently off).
	(gdb) python import sys
	(gdb) python print (sys.dont_write_bytecode)
	False
	(gdb) set python dont-write-bytecode on
	(gdb) python print (sys.dont_write_bytecode)
	False
	...

	This is not clear in the code: we set Py_DontWriteBytecodeFlag and
	Py_IgnoreEnvironmentFlag in set_python_ignore_environment and
	set_python_dont_write_bytecode.  Fix this by moving the setting of those
	variables to py_initialization.

	Furthermore, this is not clear to the user: after Python initialization, the
	user can still modify the configuration flags, and observe the changed setting:
	...
	$ gdb -q
	(gdb) show python ignore-environment
	Python's ignore-environment setting is off.
	(gdb) set python ignore-environment on
	(gdb) show python ignore-environment
	Python's ignore-environment setting is on.
	(gdb)
	...

	Fix this by emitting a warning when trying to set these configuration flags
	after Python initialization:
	...
	$ gdb -q
	(gdb) set python ignore-environment on
	warning: Setting python ignore-environment after Python initialization has \
	  no effect, try setting this during early initialization
	(gdb) set python dont-write-bytecode on
	warning: Setting python dont-write-bytecode after Python initialization has \
	  no effect, try setting this during early initialization, or try setting \
	  sys.dont_write_bytecode
	...
	and by keeping the values constant after Python initialization.

	Since the auto setting for python dont-write-bytecode depends on the current
	value of environment variable PYTHONDONTWRITEBYTECODE, we simply avoid it
	after Python initialization:
	...
	$ gdb -q -batch \
	    -eiex "show python dont-write-bytecode" \
	    -iex "show python dont-write-bytecode"
	Python's dont-write-bytecode setting is auto (currently off).
	Python's dont-write-bytecode setting is off.
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/32388
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32388

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Drop ATTRIBUTE_UNUSED on py_initialize_catch_abort
	I added ATTRIBUTE_UNUSED to py_initialize_catch_abort as a quick fix to deal
	with it being unused for PY_VERSION_HEX >= 0x030a0000, but forgot to fix this
	before committing.

	Fix this now, by removing the attribute and using
	'#if PY_VERSION_HEX < 0x030a0000' instead.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Factor out and refactor py_initialize
	Function do_start_initialization has a large part dedicated to initializing
	the python interpreter, as opposed to the rest of the function where
	gdb-specific python support is initialized.

	Factor out this part, as new function py_initialize, and rename the existing
	py_initialize to py_initialize_catch_abort.

	Refactor the new function py_initialize by getting rid of the nested:
	...
	 #ifdef WITH_PYTHON_PATH
	 #if PY_VERSION_HEX < 0x030a0000
	 #else
	 #endif
	 #else
	 #endif
	...

	In particular, this changes behaviour for the "!defined (WITH_PYTHON_PATH)"
	case.

	For the "defined (WITH_PYTHON_PATH)" case, we've started using
	Py_InitializeFromConfig () for PY_VERSION_HEX >= 0x030a0000 to deal with the
	deprecation of Py_SetProgramName in 3.11.

	For the "!defined (WITH_PYTHON_PATH)" case, we don't use Py_SetProgramName so
	we stuck with Py_Initialize ().

	However, in 3.12 Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag got
	deprecated and also here we need Py_InitializeFromConfig () to deal with this,
	but the "!defined (WITH_PYTHON_PATH)" case didn't get updated.

	This should be taken care of, now that we have this behavior:
	- for PY_VERSION_HEX < 0x030a0000 we use Py_Initialize
	- for PY_VERSION_HEX >= 0x030a0000 we use Py_InitializeFromConfig

	I'm not sure how to test the "!defined (WITH_PYTHON_PATH)" though.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-12-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb: restore nullptr check in compunit_symtab::find_call_site
	Commit de2b4ab50de ("Convert dwarf2_cu::call_site_htab to new hash
	table") removed this nullptr check for no good reason.  This causes a
	crash if `m_call_site_htab` is not set, as shown in PR 32410.  My guess
	is that when doing this change, I tried to make `m_call_site_htab` not a
	pointer, removed this check, then realized it wasn't so obvious, and
	forgot to re-add the check.

	Change-Id: I455e00cdc0519dfb412dc7826d17a839b77aae69
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32410
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom de Vries <tdevries@suse.de>

2024-12-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require avx
	The test gdb.reverse/i386-avx-reverse.exp was assuming that if the CPU
	was like x86, it would have AVX instructions because I didn't know how
	to check for AVX instruction support explicitly.  This commit updates
	that to use the pre-existing TCL proc have_avx.

	Also update the comment at the top of the test, since it was a copy of a
	different test.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb/dbx: Remove stabsect_build_psymtab as it was unused
	The function stabsect_build_psymtabs, defined in the dbxread file, is no
	longer used in any parts of GDB, so this commit just removes it.

	Tested by rebuilding.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp with --with-expat=no
	When building gdb with --with-expat=no and running test-case
	gdb.base/reset-catchpoint-cond.exp we get:
	...
	(gdb) catch syscall write^M
	warning: Can not parse XML syscalls information; \
	  XML support was disabled at compile time.^M
	Unknown syscall name 'write'.^M
	(gdb) FAIL: $exp: mode=syscall: catch syscall write
	...

	Fix this by skipping the test for --with-expat=no.

	Tested on x86_64-linux.

2024-12-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/python.exp with --disable-tui
	When building gdb with --disable-tui, we run into:
	...
	(gdb) python print(type(gdb.TuiWindow))^M
	Python Exception <class 'AttributeError'>: \
	  module 'gdb' has no attribute 'TuiWindow'^M
	Error occurred in Python: module 'gdb' has no attribute 'TuiWindow'^M
	(gdb) FAIL: gdb.python/python.exp: gdb.TuiWindow is registered
	...

	Fix this by skipping the test for --disable-tui.

	Tested on x86_64-linux.

2024-12-03  Guinevere Larsen  <guinevere@redhat.com>

	gdb: fix crash when GDB can't read an objfile
	If a user starts an inferior composed of objfiles that GDB is unable to
	read, there is an error thrown in find_sym_fns, printing the famous "I'm
	sorry, Dave, I can't do that" and the objfile stops being read. However,
	the objfile will already have been linked to the program space, and
	future interactions with the objfile will assume that it is readable.

	Relevant to this commit, if GDB tries to find out the section that
	contains a PC, and this section happens to land in the unreadable
	objfile, GDB will try to create a section mapping, eventually calling
	update_section_map. Since that function uses bfd to calculate the
	sections, it'll think there are sections to be ordered, but when trying
	to access the objfile::section_offsets, it'll be indexing a size 0
	std::vector, which will end up segfaulting.

	Currently, it isn't easy to trigger this crash, but the upcoming
	possibility to disable support for some file formats would make the
	crash very easy to reproduce, by attempting to debug an unsupported
	inferior and using "break *<instruction>" command, or simply connecting
	to a gdbserver loaded with an unsupported inferior.

	The struct objfile_up seems to have been created to catch these kinds of
	errors and unlink the partially-read objfile from the program space, as
	the objfile isn't useful to GDB anymore, but it seems to have been added
	before find_sym_fns would throw errors for unreadable objfiles, as the
	instance in syms_from_objfile_1 (that could save GDB from this crash) is
	declared well after find_sym_fns, too late to guard us. This commit
	moves the declaration up to the top of the function, so it works as
	intended.

	Further discussion on the mailing list also agreed that the name
	"objfile_up" implies some level of ownership of the pointer, which this
	struct doesn't have. So this commit renames the struct to
	scoped_objfile_unlinker, which is more descriptive of what the struct is
	actually meant to do.

	The final change this commit does is add an assertion to
	objfile::section_offset and objfile::set_section_offset, which ensures
	that the section_offsets vector is large enough to return the desired
	offset. This ensures that we won't misteriously segfault or worse,
	continue going with garbage data.

	Reported-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-12-03  Jens Remus  <jremus@linux.ibm.com>

	gas: Re-enable .org test 1 on all targets except kvx
	It got erroneously disabled for all targets including kvx instead of
	excluding kvx only.

	gas/testsuite/
		* gas/all/org-1.d: Re-enable on all targets except kvx.

	Fixes: 6e712424f5cb ("kvx: New port.")

2024-12-03  Jens Remus  <jremus@linux.ibm.com>

	s390: Enable .bss/.struct data allocation directives tests
	This reduces the number of unsupported tests on s390 by two.

	gas/testsuite/
		* gas/elf/bss.d: Enable for s390*-*-*.
		* gas/elf/bad-bss.d: Likewise.

2024-12-03  Surya Kumari Jangala  <jskumari@linux.ibm.com>

	PowerPC: Add support for RFC02680 - PQC Acceleration Instructions
	opcodes/
		* ppc-opc.c (powerpc_opcodes): Add xvadduwm, xvadduhm, xvsubuwm,
		xvsubuhm, xvmuluwm, xvmuluhm, xvmulhsw, xvmulhsh, xvmulhuw,
		xvmulhuh.
	gas/
		* testsuite/gas/ppc/future.s: New test.
		* testsuite/gas/ppc/future.d: Likewise.

2024-12-03  Nick Clifton  <nickc@redhat.com>

	Updated Russian translation and new Malay translation for the BFD sub-directory

2024-12-03  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix the infinite loop caused by calling undefweak symbol
	The undefweak symbol value of non-default visibility is 0 and does
	not use plt entry, and will not be relocated in the relocate_secion
	function. As a result, an infinite loop is generated because
	bl %plt(sym) => bl 0.

	Fix this by converting the call into a jump address 0.

2024-12-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix comment for gdbarch_stack_grows_down
	The comment for gdbarch_stack_grows_down was wrong.  Fixed in this
	commit.

	There should be no user visible changes after this commit.

2024-12-03  Jan Beulich  <jbeulich@suse.com>

	gas: partly restore how current_location() had worked
	Commit 4a826962e760 changed its behavior without saying why, and without
	putting in place any testcase demonstrating the required behavior.
	Firmly latch the current position unless deferred-evaluation mode is in
	effect.

	MMIX: use current_location() directly
	It's no longer a static function, so it can be used without involving a
	wrapper function plus an indirect function call.

2024-12-03  Jan Beulich  <jbeulich@suse.com>

	gas: streamline expr_build_dot()
	There's no point involving symbol_clone_if_forward_ref(), just for it to
	replace dot_symbol by one obtained from symbol_temp_new_now(). For the
	abs-section case also produce a slightly more "complete" (as in: all
	potentially relevant fields filled) expression by going through
	expr_build_uconstant().

	Move the function next to current_location(), for it to be easier to see
	the (dis)similarities. Correct the function's comment while there.

2024-12-03  Kong Lingling  <lingling.kong@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AVX10.2 BF16 instructions
	In this patch, we will support AVX10.2 BF16 instructions. All of them
	are new instructions forms. In current documentation, it is still
	VSCALEFPBF16, but it will change to VSCALEFNEPBF16 eventually.

	In disassembler part, we added %XB to reduce W table pass since all
	of them get evex.w=0.

	gas/Changelog:

		* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-256-bf16-intel.d: New.
		* testsuite/gas/i386/avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-bf16.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto.

	opcodes/

		* i386-dis-evex-prefix.h: Update PREFIX_EVEX_0F3A08, PREFIX_EVEX_0F3A26,
		PREFIX_EVEX_0F3A56, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3AC2,
		PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58,
		PREFIX_EVEX_MAP5_59, PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D,
		PREFIX_EVEX_MAP5_5E, PREFIX_EVEX_MAP5_5F.
		Add PREFIX_EVEX_MAP6_2C, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E,
		PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C,
		PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA,
		PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8,
		PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE.
		* i386-dis-evex.h (evex_table): Update PREFIX_EVEX_MAP6_2C,
		PREFIX_EVEX_MAP6_42, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E,
		PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C,
		PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA,
		PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8,
		PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE.
		* i386-dis.c (PREFIX_EVEX_MAP6_2C): New enum.
		(PREFIX_EVEX_MAP6_42): Ditto.
		(PREFIX_EVEX_MAP6_4C): Ditto.
		(PREFIX_EVEX_MAP6_4E): Ditto.
		(PREFIX_EVEX_MAP6_98): Ditto.
		(PREFIX_EVEX_MAP6_9A): Ditto.
		(PREFIX_EVEX_MAP6_9C): Ditto.
		(PREFIX_EVEX_MAP6_9E): Ditto.
		(PREFIX_EVEX_MAP6_A8): Ditto.
		(PREFIX_EVEX_MAP6_AA): Ditto.
		(PREFIX_EVEX_MAP6_AC): Ditto.
		(PREFIX_EVEX_MAP6_AE): Ditto.
		(PREFIX_EVEX_MAP6_B8): Ditto.
		(PREFIX_EVEX_MAP6_BA): Ditto.
		(PREFIX_EVEX_MAP6_BC): Ditto.
		(PREFIX_EVEX_MAP6_BE): Ditto.
		(putop): Handle %XB.
		* i386-opc.tbl: Add AVX10.2 instructions.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-12-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-02  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/configure.ac: remove elf_hp.h check
	The comment says this is for HP/UX, which is no longer supported.  There
	should be no functional changes with this, since nothing checks
	HAVE_ELF_HP_H.

	Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84

2024-12-02  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb, gdbserver,  gdbsupport: flatten and sort some list in configure files
	This makes the lists easier sort read and modify.  There are no changes
	in the generated config.h files, so I'm confident this brings no
	functional changes.

	Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add tests for combinations of GCS options and marked/unmarked inputs

	aarch64: add tests to check the correct merge of the GCS feature with others.

2024-12-02  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>
	    Matthieu Longo  <matthieu.longo@arm.com>
	    Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: GCS feature check in GNU note properties for input objects
	This patch adds support for Guarded Control Stack in AArch64 linker.

	This patch implements the following:
	1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in
	GNU_PROPERTY_AARCH64_FEATURE_1_AND macro.

	2) Adds readelf support to read and print the GCS feature in GNU
	properties in AArch64.

	Displaying notes found in: .note.gnu.property
	[      ]+Owner[        ]+Data size[    ]+Description
	  GNU                  0x00000010      NT_GNU_PROPERTY_TYPE_0
	      Properties: AArch64 feature: GCS

	3) Adds support for the "-z gcs" linker option and document all the values
	allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is
	equivalent to "-z gcs=always". When '-z gcs' option is omitted from the
	command line, it defaults to "implicit" and relies on the GCS feature
	marking in GNU properties.

	4) Adds support for the "-z gcs-report" linker option and document all the
	values allowed with this option (-z gcs-report[=none|warning|error]) where
	"-z gcs-report" is equivalent to "-z gcs-report=warning". When this option
	is omitted from the command line, it defaults to "warning".

	The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU
	property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and
	can be found in [1].

	[1] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: rename BTI error/warning message
	The previous message for missing BTI feature in GNU properties was
	not very clear. The new message explains that a missing GNU property
	marking is lacking on this specific input.

	aarch64: delete duplicated BTI tests

	aarch64: improve test coverage for combination of BTI options

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: limit number of reported issues on missing GNU properties
	This patch attempts to make the linker output more friendly for the
	developers by limiting the number of emitted warning/error messages
	related to BTI issues.

	Every time an error/warning related to BTI is emitted, the logger
	also increments the BTI issues counter. A batch of errors/warnings is
	limited to a maximum of 20 explicit errors/warnings. At the end of
	the merge, a summary of the total of errors/warning is given if the
	number exceeds the limit of 20 invidual messages.

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: bugfix when finding 1st bfd input with GNU property
	The current implementation of searching the first input BFD with GNU
	properties has a bug. The search was not filtering on object inputs
	belonging to the output link unit only, but was also including dynamic
	objects, BFD plugins, and linker-created files.
	This means that the initial initialization of the output properties
	were skewed, and warnings on input files that should have been emitted
	were not.

	This patch fixes the filtering to exclude the object input files not
	belonging to the output link unit, not having the same ELF class, and
	not the same target architecture.

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: remove early exit when setting up GNU properties with partial linking
	There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties
	that is enabled when the output link unit is relocatable, i.e. ld
	generates an output file that can in turn serve as input to ld. (see
	ld manual, -r,--relocatable for more details).

	At this stage, the GNU properties have already been merged and errors
	or warnings (if any) have already been issued. However, OUTPROP has
	not been updated yet.
	Not updating OUTPROP means that implicits enablement of BTI PLTs via
	the GNU properties will be ignored for final links. Indeed, the
	enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries
	by looking up at gnu_property_aarch64_feature_1_and (OUTPROP).
	Since the final link does not happen in the case of partial linking,
	the behaviour with or without the early exit should be the same.

	Given that there is currently no comment for explain why the exit is
	there, and that there might in the future be cases were these properties
	affect relocatable links, it is preferrable to drop the early exit.

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 5)
	Use _bfd_aarch64_elf_check_bti_report to report any BTI issue on the
	first input object.

	aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 4)
	Move the code related to the creation of the gnu.note section to a
	separate function: _bfd_aarch64_elf_create_gnu_property_section

	aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 3)
	Move the code related to the search of the first bfd input with GNU
	properties to a separate function:
	_bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property

	aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 2)
	Simplify this for-loop with too many "break" instructions inside.

	aarch64: refactoring _bfd_aarch64_elf_check_bti_report
	Before this patch, warnings were reported normally, and errors
	(introduced by a previous patch adding '-z bti-report' option)
	were logged as error but were not provoking a link failure.
	The root of the issue was a misuse of _bfd_error_handler to
	report the errors.
	Replacing _bfd_error_handler by info->callbacks->einfo, with the
	addition of the formatter '%X' for errors fixed the issue.

	aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 1)
	Exposing the output GNU property as a parameter of
	_bfd_aarch64_elf_link_setup_gnu_properties seems to break the
	encapsulation. The output GNU property update should be part of the
	function that sets up the GNU properties.
	This patch removes the parameter, and perform the update of the GNU
	property on the output object inside the function.

	aarch64: rename gnu_and_prop to gnu_property_aarch64_feature_1_and

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: simplify condition in elfNN_aarch64_merge_gnu_properties
	The current condition used to check if a GNU feature property is set
	on an input object before the merge is a bit confusing.

	  (aprop && !<something about aprop>) || !aprop

	It seems easier to understand if it is changed as follows:

	  (!aprop || !<something about aprop>)

2024-12-02  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: rename parameter of _bfd_aarch64_elf_merge_gnu_properties
	The current naming of the AArch64 feature GNU property of the output bfd
	does not reflect what it is. This patch renames it from "prop" to
	"outprop".

	aarch64: update ld documentation with bti and pac options

	aarch64: use only one type for feature marking report

	aarch64: group software protection options under a same struct.
	- declare a new struc aarch_protection_opts to store all the
	  configuration options related to software protections (i.e. bti-plt,
	  pac-plt, bti-report level).
	- add a new option "-z bti-report" to configure the log level of reported
	  issues when BTI PLT is forced.
	- encapsulate the BTI report inside _bfd_aarch64_elf_check_bti_report.

	aarch64: adapt BTI tests to use selectable GNU properties

	aarch64: adapt bti-far* tests to use selectable GNU properties

	aarch64: adapt tests for PAC PLT to use selectable GNU properties

	aarch64: delete old tests for PAC & BTI PLT

	aarch64: new tests for BTI & PAC PLT to use selectable GNU properties

	aarch64: adapt bti-plt-so to use selectable GNU properties

	aarch64: delete old tests covering the merge of feature markings

	aarch64: new tests covering the merge of feature markings

	aarch64: move tests for AArch64 protections (BTI, PAC) into a subfolder
	- moved all the BTI and PAC tests into a new subfolder: "protections".
	    bti-far-*
	    bti-plt-*
	    bti-pac-plt-*
	- move several procedures used only for AArch64 linker tests to a new exp
	  library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib.
	- use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp.

2024-12-02  Andrew Burgess  <aburgess@redhat.com>

	gdb: handle DW_AT_entry_pc pointing at an empty sub-range
	The test gdb.cp/step-and-next-inline.exp creates a test binary called
	step-and-next-inline-no-header.  This test includes a function
	`tree_check` which is inlined 3 times.

	When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1)
	we see the following DWARF representing one of the inline instances of
	tree_check:

	 <2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
	    <8da>   DW_AT_abstract_origin: <0x9ee>
	    <8de>   DW_AT_entry_pc    : 0x401165
	    <8e6>   DW_AT_GNU_entry_view: 0
	    <8e7>   DW_AT_ranges      : 0x30
	    <8eb>   DW_AT_call_file   : 1
	    <8ec>   DW_AT_call_line   : 52
	    <8ed>   DW_AT_call_column : 10
	    <8ee>   DW_AT_sibling     : <0x92d>

	 ...

	 <1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram)
	    <9ef>   DW_AT_external    : 1
	    <9ef>   DW_AT_name        : (indirect string, offset: 0xe8): tree_check
	    <9f3>   DW_AT_decl_file   : 1
	    <9f4>   DW_AT_decl_line   : 38
	    <9f5>   DW_AT_decl_column : 1
	    <9f6>   DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei
	    <9fa>   DW_AT_type        : <0x9e8>
	    <9fe>   DW_AT_inline      : 3       (declared as inline and inlined)
	    <9ff>   DW_AT_sibling     : <0xa22>

	 ...

	 Contents of the .debug_ranges section:

	    Offset   Begin    End
	    ...
	    00000030 0000000000401165 0000000000401165 (start == end)
	    00000030 0000000000401169 0000000000401173
	    00000030 0000000000401040 0000000000401045
	    00000030 <End of list>
	    ...

	Notice that one of the sub-ranges of tree-check is empty, this is the
	line marked 'start == end'.  As the end address is the first address
	after the range, this range cover absolutely no code.

	But notice too that the DW_AT_entry_pc for the inline instance points
	at this empty range.

	Further, notice that despite the ordering of the sub-ranges, the empty
	range is actually in the middle of the region defined by the lowest
	address to the highest address.  The ordering is not a problem, the
	DWARF spec doesn't require that ranges be in any particular order.

	However, this empty range is causing issues with GDB newly acquire
	DW_AT_entry_pc support.

	GDB already rejects, and has done for a long time, empty sub-ranges,
	after all, the DWARF spec is clear that such a range covers no code.

	The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which
	was outside of the low/high bounds of a block.

	But in this case, the entry-pc value is within the bounds of a block,
	it's just not within any useful sub-range.  As a consequence, GDB is
	storing the entry-pc value, and making use of it, but when GDB stops,
	and tries to work out which block the inferior is in, it fails to spot
	that the inferior is within tree_check, and instead reports the
	function into which tree_check was inlined.

	I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with
	these versions gcc is still generating the empty sub-range, but now
	this empty sub-range is no longer the entry point.  Here's the
	corresponding ranges table from gcc 14.2.0:

	  Contents of the .debug_rnglists section:

	   Table at Offset: 0:
	    Length:          0x56
	    DWARF version:   5
	    Address size:    8
	    Segment size:    0
	    Offset entries:  0
	      Offset   Begin    End
	      ...
	      00000021 0000000000401165 000000000040116f
	      0000002b 0000000000401040 (base address)
	      00000034 0000000000401040 0000000000401040  (start == end)
	      00000037 0000000000401041 0000000000401046
	      0000003a <End of list>
	      ...

	The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range,
	as a result, when GDB stops at the entry-pc, GDB will correctly spot
	that the inferior is in the tree_check function.

	The fix I propose here is, instead of rejecting entry-pc values that
	are outside the block's low/high range, instead reject entry-pc values
	that are not inside any of the block's sub-ranges.

	Now, GDB will ignore the prescribed entry-pc, and will instead select
	a suitable default entry-pc based on either the block's low-pc value,
	or the first address of the first range.

	I have extended the gdb.cp/step-and-next-inline.exp test to check this
	case, but this does depend on the compiler version being used (newer
	compilers will always pass, even without the fix).

	So I have also added a DWARF assembler test to cover this case.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2024-12-02  Jan Beulich  <jbeulich@suse.com>

	x86: default to not accepting MPX insns
	Gcc9 had MPX support removed. While we don't want to remove support,
	require these deprecated insns (and registers) to be enabled explicitly.

2024-12-02  Jan Beulich  <jbeulich@suse.com>

	x86: always set ISA_1_BASELINE property for 64-bit objects
	The baseline was, afaik, specifically chosen to align with the baseline
	ISA of x86-64. It therefore makes no sense to emit that property only
	conditionally; if anything it confuses tools analyzing the difference
	between generated object files, which may result from just
	added / changed / removed (entirely ISA-independent) code, without any
	change to the enabled extensions. Compilers, after all, are free to use
	these baseline "extensions" when generating 64-bit code.

	While changing the one testcase that needs adjustment, also correct its
	misleading name (to be in sync with the filename).

2024-12-02  Jan Beulich  <jbeulich@suse.com>

	x86/COFF: support section-index relocations in insn operands
	On the grounds of the principle put down near the bottom of [1], along
	with image and section relative operations, let's also support as insn
	operands what .secidx is for on the data side (of course like elsewhere
	the reloc operator can then also be used for data generation, albeit a
	small tweak to x86_cons() is needed for this to work).

	[1] https://sourceware.org/pipermail/binutils/2024-November/137617.html

2024-12-02  Jan Beulich  <jbeulich@suse.com>

	x86/COFF: support RVA (image-relative) relocations in insn operands
	As was pointed out in [1] compilers produce code using such constructs,
	and hence we'd better support this. In analogy to the .rva directive
	permit @rva to be used for this, and in analogy with other architectures
	(plus to not diverge from e.g. Clang's integrated assembler, albeit I
	haven't been able myself to confirm it knows this form) also permit
	@imgrel.

	While there also adjust the operand type specifier for the adjacent
	@secrel32 - 64-bit fields cannot be used with a 32-bit relocation.

	Further while there also deal with *-*-pe* in x86-64.exp, even if (right
	now) perhaps only for completeness.

	[1] https://sourceware.org/pipermail/binutils/2024-November/137548.html

2024-12-02  Rohr, Stephan  <stephan.rohr@intel.com>

	testsuite, threads: add missing return statements
	Add missing return statements in

	  * gdb.threads/process-exit-status-is-leader-exit-status.c
	  * gdb.threads/next-fork-exec-other-thread.c

	to fix 'no return statement' compiler warnings, e.g.:

	  process-exit-status-is-leader-exit-status.c: In function ‘start’:
	  process-exit-status-is-leader-exit-status.c:46:1: warning: no return
	    statement in function returning non-void [-Wreturn-type]
	     46 | }
	        | ^

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-12-02  Dongyan Chen  <chendongyan@isrc.iscas.ac.cn>

	RISC-V: Add support for ssdbltrp and smdbltrp extension.
	This implements the ssdbltrp extensons, version 1.0[1] and the smdbltrp
	extensions, version1.0[2].

	[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc
	[2] https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltrp.adoc

	bfd/ChangeLog:

		* elfxx-riscv.c: Add 'ssdbltrp' and 'smdbltrp' to the list of konwn
		  standard extensions.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/imply.d: Ditto.
		* testsuite/gas/riscv/imply.s: Ditto.
		* testsuite/gas/riscv/march-help.l: Ditto.

2024-12-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-12-01  Alan Modra  <amodra@gmail.com>

	Correct hpux-core.c thread_section_p signature
	Fix fallout from commit 0a1b45a20eaa.

2024-12-01  Alan Modra  <amodra@gmail.com>

	Re: PR32399, buffer overflow printing core_file_failing_command
	Fix more potential buffer overflows, and correct trad-code.c and
	cisco-core.c where they should be using bfd_{z}alloc rather than
	bfd_{z}malloc.  To stop buffer overflows with fuzzed objects that
	don't have a terminator on the core_file_failing_command string, this
	patch allocates an extra byte at the end of the entire header buffer
	rather than poking a NUL at the end of the name array (u_comm[] or
	similar) because (a) it's better to not overwrite the file data, and
	(b) it is possible that some core files make use of fields in struct
	user beyond the end of u_comm to extend the command name.  The patch
	also changes some unnecessary uses of bfd_zalloc to bfd_alloc.
	There's not much point in clearing memeory that will shortly be
	completely overwritten.

		PR 32399
		* aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to
		ensure the core_file_failing_command string is terminated.
		* netbsd-core.c (netbsd_core_file_p): Likewise.
		* ptrace-core.c (ptrace_unix_core_file_p): Likewise.
		* rs6000-core.c (rs6000coff_core_p): Likewise.
		* trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc
		tdata rather than bfd_zmalloc.
		* cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata.

2024-12-01  oltolm  <oleg.tolmatcev@gmail.com>

	Remove more remnants of old Mach-O workaround
	Remove another adjustment for section address, this time for the
	offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by
	fetch_indexed_string.

2024-12-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-29  Jens Remus  <jremus@linux.ibm.com>

	s390: Fix linker test TLS -fpic and -fno-pic exec transitions
	Commit 36bbf8646c8b ("s390: Treat addressing operand sequence as one in
	disassembler") changed how plain "nop" gets disassembled and missed to
	update any affected linker tests accordingly.

	ld/testsuite/
		* ld-s390/tlsbin.dd: "nop" disassembles into "nop".

	Fixes: 36bbf8646c8b ("s390: Treat addressing operand sequence as one in disassembler")

2024-11-29  Jens Remus  <jremus@linux.ibm.com>

	s390: Simplify parsing of omitted index register operand
	The index register operand X in D(X,B) can optionally be omitted by
	coding D(,B) or D(B).  Simplify the parsing logic.

	gas/
		* config/tc-s390.c (md_gather_operands): Rename
		omitted_base_or_index to omitted_index and simplify logic.

2024-11-29  Jens Remus  <jremus@linux.ibm.com>

	s390: Treat addressing operand sequence as one in disassembler
	Reuse logic introduced with the preceding commit in the assembler to
	treat addressing operand sequences D(X,B), D(B), and D(L,B) as one
	with regards to optional last operands (i.e. optparm and optparm2).

	With this "nop" now disassembles into "nop" instead of "nop 0".

	opcodes/
		* s390-dis.c (operand_count): New helper to count the remaining
		operands, treating D(X,B), D(B), and D(L,B) as one.
		(skip_optargs_p): New helper to test whether remaining operands
		 are optional.
		(skip_optargs_zero_p): New helper to test whether remaining
		operands are optional and their values are zero.
		(s390_print_insn_with_opcode): Use skip_optargs_zero_p to skip
		optional last operands with a value of zero.

	gas/testsuite/
		* gas/s390/zarch-optargs.d (nop): Adjust test case accordingly.

2024-11-29  Jens Remus  <jremus@linux.ibm.com>

	s390: Treat addressing operand sequence as one in assembler
	The assembler erroneously treated any number of operands as optional,
	if the instruction was flagged to have one or two optional operands
	(i.e. optparm or optparm2).

	Only treat the exact specified number of operands as optional while
	treating addressing operand sequences D(X,B), D(B), and D(L,B) as one
	operand.

	gas/
		* config/tc-s390.c (operand_count): New helper to count the
		remaining operands, treating D(X,B), D(B), and D(L,B) as one.
		(skip_optargs_p): Use new helper operand_count to treat
		D(X,B), D(B), and D(L,B) as one operand.
		(md_gather_operands): Use skip_optargs_p to skip only the
		optional last operands.

2024-11-29  Jens Remus  <jremus@linux.ibm.com>

	s390: Fix disassembly of optional addressing operands
	"nop D1(B1)" erroneously disassembled into "nop D1(B1" (missing
	closing parenthesis).  "nop D1(X1,0)" and "nop D1(X1,)" erroneously
	disassembled into "nop D1(X1)" (missing zero base register) instead
	of "nop D1(X1,0)".

	Do not skip disassembly of optional operands if they are index (X)
	or base (B) registers or length (L) in an addressing operand sequence
	"D(X,B)",  "D(B)", or "D(L,B).  Index and base register operand values
	of zero are being handled separately, as they may not be omitted
	unconditionally.  For instance a base register value of zero must be
	printed in above mentioned case, to distinguish the index from the
	base register.  This also ensures proper formatting of addressing
	operand sequences.

	While at it add further test cases for instructions with optional
	operands.

	opcodes/
		* s390-dis.c (s390_print_insn_with_opcode): Do not
		unconditionally skip disassembly of optional operands with a
		value of zero, if within an addressing operand sequence.

	gas/testsuite/
		* gas/s390/zarch-optargs.d: Add further test cases for
		instructions with optional operands.
		* gas/s390/zarch-optargs.s: Likewise.

	Reported-by: Florian Krohm <flo2030@eich-krohm.de>

2024-11-29  Jan Beulich  <jbeulich@suse.com>

	x86: restrict gas'es recognition of -s to Solaris
	When there for Solaris compatibility only, also recognize it only there.
	This way the option becomes available for other possible uses.

	While adjusting md_shortopts[], also re-arrange things such that we have
	only a single, uniform definition of it.

2024-11-29  Jan Beulich  <jbeulich@suse.com>

	x86/Solaris: support Sun form of CMOVcc
	Sun specifies an alternative form for CMOVcc [1], which for some reason
	we never cared to support, even if - as per gcc's configure checking for
	it - it may have been the only permitted form at some point.

	While documentation doesn't indicate FCMOVcc to have similar alternative
	forms, gcc assumes so. Hence cover FCMOVcc as well.

	[1] https://docs.oracle.com/cd/E37838_01/html/E61064/ennbz.html#XALRMeoizm

2024-11-29  Jan Beulich  <jbeulich@suse.com>

	x86: purge most *avx512*ig*-intel tests
	Having just one each (AVX512F) ought to be sufficient to cover Intel
	syntax disassembly.

	In x86-64.exp also reorder tests some, so that related ones are again
	next to each other, rather than being interspersed with APX ones.

2024-11-29  Jan Beulich  <jbeulich@suse.com>

	x86: SETcc doesn't permit W suffix
	Accidentally I had removed No_wSuf when cloning the extra template.

2024-11-29  Surya Kumari Jangala  <jskumari@linux.ibm.com>

	MAINTAINERS: Update Peter Bergner's e-mail address

2024-11-29  Alan Modra  <amodra@gmail.com>

	PR32399, buffer overflow printing core_file_failing_command
	Assorted targets do not check, as the ELF targets do, that the program
	name in a core file is NUL terminated.  Fix some of them.  I haven't
	attempted to fix all targets because editing host specific code can
	easily result in build bugs, which aren't discovered until someone
	build binutils for that host.  (Of the files edited here, I can't
	easily compile hpux-core.c and osf-core.c on a linux system.)

		PR 32399
		* hppabsd-core.c (hppabsd_core_core_file_p): Ensure core_command
		string is terminated.
		* hpux-core.c (hpux_core_core_file_p): Likewise.
		* irix-core.c (irix_core_core_file_p): Likewise.
		* lynx-core.c (lynx_core_file_p): Likewise.
		* osf-core.c (osf_core_core_file_p): Likewise.
		* mach-o.c (bfd_mach_o_core_file_failing_command): Likewise.

2024-11-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-28  Alexandra Hájková  <ahajkova@redhat.com>

	Sync include/dwarf.h with gcc up to commit c4073a3d154
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-28  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat
	In commit 58776901074 ("[gdb/syscalls] Update to linux v6.11") I updated to
	linux v6.11, but a recent submission for loongarch [1] used a current trunk
	version, so it makes sense to do this as well elsewhere.

	Using linux current trunk with update-linux-from-src.sh gets us 4 more
	syscalls:
	- setxattrat
	- getxattrat
	- listxattrat
	- removexattrat

	Tested on x86_64-linux.

	[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213613.html

2024-11-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32392 [2.44 Regression] gprofng fails to build on i686-linux-gnu
	gprofng/ChangeLog
	2024-11-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/32392
		* libcollector/libcol_util.c (__collector_util_init): Fix warning.

2024-11-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: skip unrecognized input command
	gprofng crashes when the GUI sends an invalid command.
	Skip unrecognized commands and return an error status to the GUI.

	gprofng/ChangeLog
	2024-11-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/ipc.cc (ipc_doWork): Skip unrecognized commands.
		* src/ipcio.cc (writeError): New function.
		* src/ipcio.h: Add RESPONSE_STATUS_ERROR.

2024-11-27  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: skip gdb.threads/omp-par-scope.exp with clang
	Since 2020 it has been reported to clang[1] that the debug information
	around OpenMP is insufficient.  The OpenMP section is not declared
	within the correct scope, and instead clang marks as if the section was
	a function in the global scope.  This causes several failures in the
	test gdb.threads/omp-par-scope.exp when using clang to test GDB.

	Since this isn't a true failure of GDB, and there is little expectation
	that clang will be able to fix this soon, this commit disables the
	aforementioned test when clang is being used.

	[1] https://github.com/llvm/llvm-project/issues/44236

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-27  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix parent map dump
	Before the fix for PR symtab/32225, the parent map dump showed a mapping from
	section offsets to cooked index entries:
	...
	  0x0000000000000035 0x3ba9560 (0x34: sp1::A)
	...
	but now that's no longer the case:
	...
	  0x00000000406f5405 0x410a04d0 (0x34: sp1::A)
	...

	Fix this by extending the annotation somewhat, such that we get:
	...
	map start:
	  0x0000000012c52405 0x135fd550
		(section: .debug_info, offset: 0x35) -> (0x34: sp1::A)
	...

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225

2024-11-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/dw2-tu-dwarf-4-5.exp
	Add a regression test for PR symtab/32225.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225

2024-11-27  Author: Tom Tromey  <tom@tromey.com>

	[gdb/symtab] Fix parent map when handling .debug_info and .debug_types
	Consider test-case:
	...
	$ cat test.c
	namespace sp1 {
	  class A {
	    int i;
	    const int f1 = 1;
	    ...
	    const int f29 = 1;
	  };
	}
	sp1::A a;
	void _start (void) {}
	$ cat test2.c
	namespace sp2 {
	  class B {
	    float f;
	    const float f1 = 1;
	    ...
	    const float f29 = 1;
	  };
	}
	sp2::B b;
	...
	compiled like this:
	...
	$ g++ test.c -gdwarf-4 -c -g -fdebug-types-section
	$ g++ test2.c -gdwarf-5 -c -g -fdebug-types-section
	$ g++ -g test.o test2.o -nostdlib
	...

	Using:
	...
	$ gdb -q -batch -iex "maint set worker-threads 0" a.out -ex "maint print objfiles"
	...
	we get a cooked index entry with incorrect parent:
	...
	    [29] ((cooked_index_entry *) 0x3c57d1a0)
	    name:       B
	    canonical:  B
	    qualified:  sp1::A::B
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x154
	    parent:     ((cooked_index_entry *) 0x3c57d110) [A]
	...

	The problem is that the parent map assumes that all offsets are in the same
	section.

	Fix this by using dwarf2_section_info::buffer-relative addresses instead,
	which get us instead:
	...
	    [29] ((cooked_index_entry *) 0x3f0962b0)
	    name:       B
	    canonical:  B
	    qualified:  sp2::B
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x154
	    parent:     ((cooked_index_entry *) 0x3f096280) [sp2]
	...

	Tested on x86_64-linux.

	PR symtab/32225
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225

2024-11-27  Andreas Arnez  <arnez@linux.ibm.com>

	[gdb/tdep] s390: Add arch15 record/replay support
	Enable recording of the new "arch15" instructions on z/Architecture
	targets.

2024-11-27  Liu Hao  <lh_mouse@126.com>

	PE LD: Merge .CRT .ctors and .dtors into .rdata
	PR 32264

2024-11-27  Nick Clifton  <nickc@redhat.com>

	Tidy up the default ELF linker script

2024-11-27  Alan Modra  <amodra@gmail.com>

	Re: nios2: Remove binutils support for Nios II target
	Remove a now unused config file, regenerate POTFILES to remove nios2
	refs, and modify config.bfd to report the target is obsolete.

2024-11-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-26  Sandra Loosemore  <sloosemore@baylibre.com>

	nios2: Remove binutils support for Nios II target.
	The Nios II architecture has been EOL'ed by the vendor.  This patch
	removes all binutils, bfd, gas, binutils, and opcodes support for this
	target with the exception of the readelf utility.  (The ELF EM_*
	number remains valid and the relocation definitions from the Nios II
	ABI will never change in future, so retaining the readelf support
	seems consistent with its purpose as a utility that tries to parse the
	headers in any ELF file provided as an argument regardless of target.)

	nios2: Remove all GDB support for Nios II targets.
	Intel has EOL'ed the Nios II architecture, and it's time to remove support
	from all toolchain components before it gets any more bit-rotten from
	lack of maintenance or regular testing.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Update aarch64-linux.xml to linux v6.11
	Use gdb/syscalls/update-linux.sh to update aarch64-linux.xml.in to linux
	v6.11, and update aarch64-linux.xml by running make.

	Noteworthy changes are removal of entries:
	- arch_specific_syscall
	- syscalls
	which look like they were added accidentally.

	I modified update-linux.sh to keep the copyright start date.  Verified with
	shellcheck.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-11-26  Alan Modra  <amodra@gmail.com>

	PR32387 ppc64 TLS optimization bug with -fno-plt code
	The inline plt code emitted by gcc is incompatible with the
	linker/ld.so --tls-get-addr-optimize scheme.  This is the runtime
	optimisation where the first call to __tls_get_addr results in
	__tls_get_addr updating the tls_index pair, then the special linker
	stub using that to short-circuit second and subsequent calls for a
	given tls symbol.  Enabled by default when the linker sees
	__tls_get_addr_opt is preseent, and enabled in ld.so when DT_PPC64_OPT
	has PPC64_OPT_TLS set.  Note that this is distinct from link-time tls
	optimisation.

		PR 32387
		* elf64-ppc.c (ppc64_elf_check_relocs): Disable tls_get_addr_opt
		on detecting inline plt calls to __tls_get_addr.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Sync with strace v6.12
	I ran gdb/syscalls/update-linux-defaults.sh with strace sources v6.12, and got
	one difference in gdb/syscalls/linux-defaults.xml.in:
	...
	+  <syscall name="mseal" groups="memory"/>
	...

	Rerun make to propagate this change to the xml files.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Use update-linux-from-src.sh for arm-linux
	I tried to use arm-linux.py to regenerate arm-linux.xml.in, but it didn't work.

	Fix this by:
	- adding handling of arm-linux.xml.in in update-linux-from-src.sh,
	- regenerating arm-linux.xml.in using update-linux-from-src.sh and linux 6.11
	  sources,
	- regenerating arm-linux.xml using make, and
	- removing arm-linux.py.

	This changes the name "oldolduname" into "olduname".

	Tested on arm-linux.  Verified with shellcheck.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Restructure update-linux-from-src.sh
	Restructure update-linux-from-src.sh to do the generation of each line
	in the script it self rather than in awk.

	Tested on aarch64-linux.  Verified with shellcheck.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Improve update-linux-from-src.sh
	Some improvements in gdb/syscalls/update-linux-from-src.sh:
	- use bash instead of sh
	- use local to distinguish between local and global vars
	  (which brings to light that pre uses the global rather than the local
	  start_date)
	- factor out main and parse_args
	- factor out regen
	- iterate over *.xml.in instead of *.in

	Tested on aarch64-linux.  Verified with shellcheck.

2024-11-26  Tom de Vries  <tdevries@suse.de>

	[gdb/syscalls] Update to linux v6.11
	Regenerate some gdb/syscalls/*.xml.in files using
	gdb/syscalls/update-linux-from-src.sh and linux v6.11 sources.

	Regenerate the corresponding gdb/syscalls/*.xml using make.

	Tested on aarch64-linux.

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert dwarf2_per_objfile::die_type_hash to new hash table
	Convert dwarf2_per_objfile::die_type_hash, which maps debug info
	offsets to `type *`, to gdb::unordered_map.

	Change-Id: I5c174af64ee46d38a465008090e812acf03704ec
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@polymtl.ca>

	Convert dwarf2_cu::call_site_htab to new hash table
	Convert one use of htab_t, mapping (unrelocated) pc to call_site
	objects, to `gdb::unordered_map<unrelocated_addr, call_site *>`.

	Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@polymtl.ca>

	Convert dwarf_cu::die_hash to new hash table
	Convert one use of htab_t, mapping offsets to die_info object, to
	`gdb::unordered_set`.

	Change-Id: Ic80df22bda551e2d4c2511d167e057f4d6cd2b3e
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert gdb_bfd.c to new hash table
	This converts the BFD cache in gdb_bfd.c to use the new hash table.

	Change-Id: Ib6257fe9d4f7f8ef793a2c82d53935a8d2c245a3
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@polymtl.ca>

	Convert more DWARF code to new hash table
	This converts more code in the DWARF reader to use the new hash table.

	Change-Id: I86f8c0072f0a09642de3d6f033fefd0c8acbc4a3
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert all_bfds to new hash table
	This converts gdb_bfd.c to use the new hash table for all_bfds.

	This patch slightly changes the htab_t pretty-printer test, which was
	relying on all_bfds.  Note that with the new hash table, gdb-specific
	printers aren't needed; the libstdc++ printers suffice -- in fact,
	they are better, because the true types of the contents are available.

	Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert typedef hash to new hash table
	This converts the typedef hash to use the new hash table.

	This patch found a latent bug in the typedef code.  Previously, the
	hash function looked at the type name, but the hash equality function
	used types_equal -- but that strips typedefs, meaning that equality of
	types did not imply equality of hashes.  This patch fixes the problem
	and updates the relevant test.

	Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert abbrevs to new hash table
	This converts the DWARF abbrevs themselves to use the new hash table.

	Change-Id: I0320a733ecefe2cffeb25c068f17322dd3ab23e2
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert abbrev cache to new hash table
	This converts the DWARF abbrev cache to use the new hash table.

	Change-Id: I5e88cd4030715954db2c43f873b77b6b8e73f5aa
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert gnu-v3-abi.c to new hash table
	This converts gnu-v3-abi.c to use the new hash table.

	This change shows how a std::vector can easily be made directly from
	the hash table, simplifying the earlier approach of constructing a
	vector and a hash table at the same time.

	Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert static links to new hash table
	This converts the objfile static link table to the new hash map.

	Change-Id: If978e895679899ca2af4ef01c12842b4184d88e6
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert type copying to new hash table
	This converts the type copying code to use the new hash map.

	Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert compile/compile.c to new hash table
	This converts compile/compile.c to use the new hash table.

	Change-Id: I7df3b8d791ece731ae0d1d64cdc91a2e372f5d4f
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert disasm.c to new hash table
	This converts disasm.c to use the new hash table.

	Change-Id: I2efbe7ecc2964ec49e0b726ad4674e8eafc929f7
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert py-framefilter.c to new hash table
	This converts py-framefilter.c to use the new hash table.

	Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert breakpoint.c to new hash table
	This converts breakpoint.c to use the new hash table.

	Change-Id: I6d997a6242969586a7f8f9eb22cc8dd8d3ac97ff
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert dwarf2/macro.c to new hash table
	This converts dwarf2/macro.c to use the new hash table.

	Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert target-descriptions.c to new hash table
	This converts target-descriptions.c to use the new hash table.

	Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert linespec.c to new hash table
	This converts linespec.c to use the new hash table.

	Note that more simplification could perhaps be done.  Currently, the
	collectors in this code insert an element into a set and then, if the
	element has not been seen before, append it to a vector.  If we know
	the order does not matter, or if the results can be sorted later, we
	could dispense with the vector.  This would simplify the code some
	more.  (This technique is used in the vtable patch, later in this
	series.)

	Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert filename-seen-cache.h to new hash table
	This converts filename-seen-cache.h to use the new hash table.
	filename-seen-cache.c is removed.

	Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	Convert compile-c-symbols.c to new hash table
	This converts compile-c-symbols.c to use the new hash table.

	I made it use a set of string_view instead of a set of `symbol *`, to
	avoid calling `symbol::natural_name` over and over.  This appears safe
	to do, since I don't expect the storage behing the natural names to
	change during the lifetime of the map.

	Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c
	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: add unordered_dense.h 4.4.0
	Add a copy of unordered_dense.h from [1].  This file implements an
	efficient hash map and hash set with a nice C++ interface (a near
	drop-in for std::unordered_map and std::unordered_set).  This is
	expected to be used to replace uses of `htab_t`, for improved code
	readability and type safety.  Performance-wise, it is preferred to the
	std types (std::unordered_map and std::unordered_set) due to it using
	open addressing vs closed addressing for the std types.

	I chose this particular implementation because it is simple to use, it's
	a standalone header and it typically performs well in benchmarks I have
	seen (e.g. [2]).  The license being MIT, my understanding is that it's
	not a problem to use it and re-distribute it.

	Add two additional files, gdbsupport/unordered_map.h and
	gdbsupport/unordered_set.h, which make the map and set offered by
	gdbsupport/unordered_dense.h available as gdb::unordered_map and
	gdb::unordered_set.

	[1] https://github.com/martinus/unordered_dense
	[2] https://jacksonallan.github.io/c_cpp_hash_tables_benchmark/#conclusion-which-hash-table-to-choose

	Change-Id: I0c7469ccf9a14540465479e58b2a5140a2440a7d
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make `cooked_index_storage::get_abbrev_table_cache` return a reference
	It can never return nullptr, return a reference instead of a pointer.

	Change-Id: Ibc6f16eb74dc16059152982600ca9f426d7f80a4
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb: constification around abbrev_table_cache and abbrev_table
	Make `abbrev_table_cache::find` const, make it return a pointer to
	`const abbrev_table`, adjust the fallouts.

	Make `cooked_index_storage::get_abbrev_table_cache` const, make itreturn
	a pointer to const `abbrev_table_cache`.

	Change-Id: If63b4b3a4c253f3bd640b13bce4a854eb2d75ece
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename abbrev_cache to abbrev_table_cache
	This cache holds `abbrev_table` objects, so I think it's clearer and
	more consistent to name it `abbrev_table_cache`.  Rename it and
	everything that goes along with it.

	Change-Id: I43448c0aa538dd2c3ae5efd2f7b3e7b827409d8c
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: do better in breakpoint_free_objfile
	The breakpoint_free_objfile function is called from the objfile
	destructor, and has the job of removing references to the soon to be
	deleted objfile from all breakpoint locations.

	The current implementation of breakpoint_free_objfile seems to miss
	lots of possible objfile references within bp_location.  Currently we
	only check if bp_location::symtab is associated with the objfile in
	question, but there's bp_location::section and bp_location::probe,
	both of which might reference the soon to be deleted objfile.

	Additionally bp_location::symbol and bp_location::msymbol if set will
	surely be related to the objfile and should also be cleaned up.

	I'm not aware that this causes any problems, but it doesn't seem like
	a good idea to retain pointers to deleted state, so I propose that we
	improve breakpoint_free_objfile to set these pointers back to nullptr.

	In the future I plan to investigate the possibility of merging the
	functionality of breakpoint_free_objfile into
	disable_breakpoints_in_freed_objfile which is called via the
	gdb::observers::free_objfile event.  However, I already have a patch series
	in progress which touches this area of GDB, and I'd like to avoid
	conflicting with that earlier series:

	  https://inbox.sourceware.org/gdb-patches/cover.1724948606.git.aburgess@redhat.com

	Once this patch, and that earlier series have landed then I'll see if
	I can merge breakpoint_free_objfile, but I don't think that this needs
	to block this patch.

	There should be no user visible changes after this commit.

2024-11-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove an unnecessary scope block in update_breakpoint_locations
	In update_breakpoint_locations there's a scope block which I don't
	think adds any value.  There is one local defined within the scope,
	the local is currently an 'int' but should be a 'bool', either way
	there's no destructor being triggered when we exit the scope.

	This commit changes the local to a 'bool', removes the unnecessary
	scope, and re-indents the code.

	Within the (now removed) scope was a `for' loop.  Inside the loop I
	have converted this:

	  for (....)
	    {
	      if (CONDITION)
	        {
	          /* Body */
	        }
	    }

	to this:

	  for (....)
	    {
	      if (!CONDITION)
	        continue;

	      /* Body */
	    }

	which means that the body doesn't need to be indented as much, making
	things easier to read.

	There should be no functional change after this commit.

	Reviewed-By: Klaus Gerlicher <klaus.gerlicher@intel.com>

2024-11-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove bp_location::objfile
	The bp_location::objfile member variable is never used, so lets delete
	it.

	There should be no user visible changes after this commit.

2024-11-25  Alexandra Hájková  <ahajkova@redhat.com>

	gdbreplay: Calculate the checksum if missing
	Recalculate the checksum and replace whatever is at the end
	of the packet with the newly calculated checksum. Then
	replay the packet with the checksum added.

	The motivation for this change is that I'd like to add a TCL test
	which starts a communication with gdbsever setting the remotelog file.
	Then, it modifies the remotelog, injects an error message instead of
	the expected replay to some packet in order to test GDB reacts to
	the error response properly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-25  Nick Clifton  <nickc@redhat.com>

	Updated Bulgarian, Romanian and French translations for various sub-directories.  New Georgian translation for the gold sub-directory.

2024-11-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: force TERM setting for some filename completion tests
	Some of the filename completion tests perform mid-line completion.
	That is we enter a partial line, then move the cursor back to the
	middle of the line and perform completion.

	The problem is that, emitting characters into the middle of a terminal
	line relies on first emitting some control characters.  And which
	control characters are emitted will depend on the current TERM
	setting.

	When I initially added the mid-line completion tests I setup two
	regexp that covered two different terminal types, but PR gdb/32338
	identifies additional terminal types that emit different sequences of
	control characters.

	Rather than trying to handle all possible terminal types, lets just
	force the TERM variable to something simple (i.e. "dumb") and then
	just support that one case.  The thing being tested for here was that
	GDB would complete a filename in the middle of a line, the specific
	terminal type was not really important.

	I've simplified the regexp used to match the completion in two places,
	and I now force TERM to be "dumb" for the mid-line completion tests.
	I've tested this by setting my global environment TERM to 'ansi',
	'xterm', 'xterm-mono', and 'dumb', and I see no failures in any mode
	now.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32338
	Tested-By: Tom de Vries <tdevries@suse.de>

2024-11-25  Hui Li  <lihui@loongson.cn>

	gdb: Add LoongArch process record/replay support in NEWS and doc
	At present, process record/replay and reverse debugging has been
	implemented on LoongArch. Update the NEWS and doc to record this
	new change.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-25  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add system call support for process record/replay
	The process record and replay function also need record Linux
	system call instruction. This patch adds LoongArch system call
	number definitions in gdb/arch/loongarch-syscall.h, and adds
	loongarch_linux_syscall_record() in gdb/loongarch-linux-tdep.c
	to record system call execute log. With this patch, the main
	functions of process record/replay and reverse debugging are
	implemented.

	The LoongArch system call numbers definitions are obtained from Linux kernel.
	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/unistd.h
	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/unistd.h

	Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full)
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-25  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add basic process record/replay support
	GDB provides a special process record and replay target that can
	record a log of the process execution, and replay it later with
	both forward and reverse execution commands. This patch adds the
	basic support of process record and replay on LoongArch, it allows
	users to debug basic LoongArch instructions and provides reverse
	debugging support.

	Here is a simple example on LoongArch:

	$ cat test.c
	int a = 0;
	int main()
	  {
	    a = 1;
	    a = 2;
	    return 0;
	  }
	$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:4
	4	    a = 1;
	(gdb) record
	(gdb) p a
	$1 = 0
	(gdb) n
	5	    a = 2;
	(gdb) n
	6	    return 0;
	(gdb) p a
	$2 = 2
	(gdb) rn
	5	    a = 2;
	(gdb) rn

	Reached end of recorded history; stopping.
	Backward execution from here not possible.
	main () at test.c:4
	4	    a = 1;
	(gdb) p a
	$3 = 0
	(gdb) record stop
	Process record is stopped and all execution logs are deleted.
	(gdb) c
	Continuing.
	[Inferior 1 (process 129178) exited normally]

	Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full)
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-25  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add instruction definition for process record
	GDB provides a special process record function that can record a log
	of the process execution. The core of this feature is need to record
	the execution of all instructions. This patch adds opcode definitions
	and judgments in gdb/arch/loongarch-insn.h. This is preparation for
	later patch on LoongArch, there is no effect for the other archs with
	this patch.

	The LoongArch opcode and mask definitions are obtained from
	https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/loongarch-opc.c
	LoongArch instruction description refer to the LoongArch Reference Manual:
	https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-24  Tom de Vries  <tdevries@suse.de>

	opcodes: fix Werror=format build breaker in opcodes/riscv-dis.c
	I build gdb on arm-linux and ran into:
	...
	  CC       riscv-dis.lo
	opcodes/riscv-dis.c: In function ‘print_insn_args’:
	opcodes/riscv-dis.c:743:29: error: format ‘%lu’ expects argument of type \
	  ‘long unsigned int’, but argument 4 has type ‘insn_t’ \
	  {aka ‘long long unsigned int’} [-Werror=format=]
	  743 |                          "%lu", EXTRACT_ZCMT_INDEX (l));
	      |                           ~~^
	      |                             |
	      |                             long unsigned int
	      |                           %llu
	...

	Fix this by printing the insn_t value, which is a uint64_t, using PRIu64.

	Tested by finishing the build.

2024-11-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[sim] Run spellcheck.sh in sim (part 2)
	Run gdb/contrib/spellcheck.sh on directory sim.

	Fix these todos:
	...
	TODO: inbetween -> between, in between, in-between
	TODO: behavour -> behavior, behaviour
	TODO: firts -> flirts, first
	TODO: wich -> which, witch
	...

	Tested by rebuilding on x86_64-linux.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add two words to common-misspellings.txt
	While reviewing changes generated by spellcheck.sh for directory sim, I
	noticed two more misspellings:
	...
	arrithemetic->arithmetic
	electricaly->electrically
	...

	Add them to common-misspellings.txt, and fix them in directory sim.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[sim] Run spellcheck.sh in sim (part 1)
	Run gdb/contrib/spellcheck.sh on directory sim.

	Fix auto-corrected typos:
	...
	accessable -> accessible
	accidently -> accidentally
	accomodate -> accommodate
	adress -> address
	afair -> affair
	agains -> against
	agressively -> aggressively
	annuled -> annulled
	arbitary -> arbitrary
	arround -> around
	auxillary -> auxiliary
	availablity -> availability
	clasic -> classic
	comming -> coming
	controled -> controlled
	controling -> controlling
	destory -> destroy
	existance -> existence
	explictly -> explicitly
	faciliate -> facilitate
	fouth -> fourth
	fullfilled -> fulfilled
	guarentee -> guarantee
	hinderance -> hindrance
	independant -> independent
	inital -> initial
	loosing -> losing
	occurance -> occurrence
	occured -> occurred
	occuring -> occurring
	omited -> omitted
	oportunity -> opportunity
	parallely -> parallelly
	permissable -> permissible
	postive -> positive
	powerfull -> powerful
	preceed -> precede
	preceeding -> preceding
	preceeds -> precedes
	primative -> primitive
	probaly -> probably
	programable -> programmable
	propogate -> propagate
	propper -> proper
	recieve -> receive
	reconized -> recognized
	refered -> referred
	refering -> referring
	relevent -> relevant
	responisble -> responsible
	retreive -> retrieve
	safty -> safety
	specifiying -> specifying
	spontanous -> spontaneous
	sqaure -> square
	successfull -> successful
	supress -> suppress
	sytem -> system
	thru -> through
	transfered -> transferred
	trigered -> triggered
	unfortunatly -> unfortunately
	upto -> up to
	usefull -> useful
	wierd -> weird
	writen -> written
	doesnt -> doesn't
	isnt -> isn't
	...

	Manually undid the "andd -> and" transformation in sim/testsuite/cr16/andd.cgs
	and sim/cr16/simops.c.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[sim] Rename local variable in ARMul_NthReg
	Rename local variable in ARMul_NthReg from upto to up_to, to avoid being
	rewritten by gdb/contrib/spellcheck.sh.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Rerun autoreconf -f
	Rerun autoreconf -f in gdbsupport, reverting "behaviour" -> "behavior" changes
	in generated files aclocal.m4 and configure.

2024-11-23  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add two rules in common-misspellings.txt
	Eli mentioned [1] that given that we use US English spelling in our
	documentation, we should use "behavior" instead of "behaviour".

	In wikipedia-common-misspellings.txt there's a rule:
	...
	behavour->behavior, behaviour
	...
	which leaves this as a choice.

	Add an overriding rule to hardcode the choice to common-misspellings.txt:
	...
	behavour->behavior
	...
	and add a rule to rewrite behaviour into behavior:
	...
	behaviour->behavior
	...
	and re-run spellcheck.sh on gdb*.

	Tested on x86_64-linux.

	[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html

2024-11-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-22  Sam James  <sam@gentoo.org>

	Sync toplevel configure fixup
	Apparently I missed that we needed to sync config/acx.m4. I only
	noticed this because our packaging has a grep for certain messages
	post-merge.

	```
	work/binutils/configure: 5814: ACX_PROG_CARGO: not found
	```

	Fix that by syncing the macro too, which I missed in 987db70acefd0b223a8df2240d4e5ca544cc0a91.

2024-11-22  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: introduce recoding support for vpor
	This commit adds recording support for the AVX instruction vpor, and the
	AVX2 extension. Since the encoding of vpor and vpxor are the same, and
	their semantics are basically the same, modulo the mathematical
	operation, they are handled by the same switch case block.

	This also updates the vpxor function, to test vpor and vpxor, and
	updates the name to vpor_xor_test to better reflect what it does.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: Add support for recording vpmovmskb
	This commit adds support for recording the AVX instruction vpmovmskb,
	and tests to the relevant file. The test didn't really support checking
	general purpose registers, so this commit also adds a proc to
	gdb.reverse/i386-avx-reverse.exp, which can be used to test them

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: Add support for all vpcmpeq instructions
	This commit adds support to recording instructions of the form
	VPCMPEQ[B|W|D]. They are all encoded in the same way and only
	differentiated by the opcode, so they are all processed together. This
	commit also updates the test to (quite exhaustively) test the new
	instruction.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support for vpxor instruction
	This commit adds support for recording the instruction vpxor,
	introduced in the AVX extension, and extended in AVX2 to use 256 bit
	registers. The test gdb.reverse/i386-avx-reverse.exp has been extended
	to test this instruction as well.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Introduce RAII signal handler setter
	This patch is motivated by the wait function for the record-full target,
	that would install a custom signal handler for SIGINT, but could throw
	an exception and never reset the SIGINT handler.  This is clearly a bad
	idea, so this patch introduces the class scoped_signal_handler in a new
	.h file.  The file is added to gdbsupport, even though only gdb code is
	using it, because it feels like an addition that would be useful for
	more than just directly gdb.

	The implementation of the RAII class is based on the implementation
	on gdb/utils.c. That is, it uses preprocessor ifdefs to probe for
	sigaction support, and uses it if possible, defaulting to a raw call to
	signal only if sigaction isn't supported. sigaction is preferred based
	on the "portability" section of the manual page for the signal function.

	There are 3 places where this class can just be dropped in,
	gdb/record-full.c, gdb/utils.c and gdb/extension.c. This third place
	already had a specialized RAII signal handler setter, but it is
	substituted for the new general purpose one.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix build with -std=gnu23
	Fix function pointer types accordingly.
	Remove unused function pointers.

	gprofng/ChangeLog
	2024-11-21  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/32374
		PR gprofng/32373
		* common/cpuid.c: Define ATTRIBUTE_UNUSED if necessary.
		* libcollector/libcol_util.c (sysinfo): Remove unused pointer.
		* src/collector_module.h: Likewise.
		* libcollector/dispatcher.c (setitimer): Fix prototype.
		* libcollector/linetrace.c (system, grantpt, ptsname): Likewise.
		* testsuite/gprofng.display/mttest/mttest.c (dump_arrays): Likewise.
		* testsuite/gprofng.display/synprog/endcases.c (xinline_code,
		s_inline_code): Likewise.
		* testsuite/gprofng.display/synprog/inc_inline.h (ext_inline_code):
		Likewise.
		* testsuite/gprofng.display/synprog/synprog.c (doabort): Rename nullptr.

2024-11-22  Hannes Domani  <ssbssa@yahoo.de>

	Use appropriate context flags for Wow64 processes
	When I implemented debugging of Wow64 processes, I missed that there are
	extra ContextFlags defines for them.
	It's a bit surprising that the wrong ones actually worked, except that
	CONTEXT_EXTENDED_REGISTERS is not available for x86_64, and they are
	needed for i686, since that's where the xmm registers are stored.

	So this replaces the ContextFlags values with their WOW64_* equivalents.
	On gdbserver this also duplicates the fallback logic if the
	GetThreadContext call failed with CONTEXT_EXTENDED_REGISTERS.

	Fixes these fails:
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm0
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm0
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm1
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm1
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm2
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm3
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm3
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm4
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm4
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm5
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm5
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm6
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm6
	FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm7
	FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm7
	FAIL: gdb.arch/i386-sse.exp: check contents of data[0]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[1]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[3]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[4]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[5]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[6]
	FAIL: gdb.arch/i386-sse.exp: check contents of data[7]

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Sam James  <sam@gentoo.org>

	Sync toplevel configure with GCC
	This syncs us with GCC as of r15-5590-gf34422e06c38eb.

	Some changes will need to be propagated to the GCC side (so I've kept those
	and not clobbered them) which I will handle shortly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Handle failure to initialize without exiting
	I tried out making python initialization fail by passing an incorrect
	PYTHONHOME, and got:
	...
	$ PYTHONHOME=foo ./gdb.sh -q
	Python path configuration:
	  PYTHONHOME = 'foo'
	  ...
	Python initialization failed: \
	  failed to get the Python codec of the filesystem encoding
	Python not initialized
	$
	...

	The relevant part of the code is:
	...
	static void
	gdbpy_initialize (const struct extension_language_defn *extlang)
	{
	  if (!do_start_initialization () && py_isinitialized && PyErr_Occurred ())
	    gdbpy_print_stack ();

	   gdbpy_enter enter_py;
	...

	What happens is:
	- gdbpy_enter::gdbpy_enter () is called, where we run into:
	  'if (!gdb_python_initialized) error (_("Python not initialized"));'
	- the error propagates to gdb's toplevel
	- gdb print the error and exits.

	It seems unnecesssary that we exit gdb.  We could continue the
	session without python support.

	Fix this by:
	- bailing out of gdbpy_initialize if !do_start_initialization
	- bailing out of finalize_python if !gdb_python_initialized

	This gets us instead:
	...
	$ PYTHONHOME=foo gdb -q
	Python path configuration:
	  PYTHONHOME = 'foo'
	  ...
	Python initialization failed: \
	  failed to get the Python codec of the filesystem encoding
	(gdb) python print (1)
	Python not initialized
	(gdb)
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix abort on Py_Initialize
	I tried out making python initialization fail by passing an incorrect
	PYTHONHOME with python 3.6, and got:
	...
	$ PYTHONHOME=foo gdb -q
	Fatal Python error: Py_Initialize: Unable to get the locale encoding
	ModuleNotFoundError: No module named 'encodings'

	Current thread 0x0000ffff89269c80 (most recent call first):

	Fatal signal: Aborted
	  ...
	Aborted (core dumped)
	$
	...

	This is as per spec: when Py_Initialize () fails, a fatal error is raised
	using Py_FatalError.

	This can be worked around using:
	...
	$ PYTHONHOME=foo gdb -q -eiex "set python ignore-environment on"
	(gdb)
	...
	but it would be better if gdb didn't abort.

	I found an article [1] describing two solutions:
	- try out Py_Initialize in a separate process, and
	- catch the abort using a signal handler.

	This patch implements the latter solution.

	Obviously we cannot call into python anymore after the abort, so we avoid
	calling Py_IsInitialized (), and instead use a new variable py_isinitialized.

	This gets us instead:
	...
	$ PYTHONHOME=foo gdb -q
	Fatal Python error: Py_Initialize: Unable to get the locale encoding
	ModuleNotFoundError: No module named 'encodings'

	Current thread 0x0000fffecfd49c80 (most recent call first):
	Python not initialized
	$
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/32379
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379

	[1] https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Handle !Py_IsInitialized () in gdbpy_initialize
	I tried out making python initialization fail by passing an incorrect
	PYTHONHOME, and got:
	...
	$ PYTHONHOME=foo gdb -q
	Python path configuration:
	  PYTHONHOME = 'foo'
	  ...
	Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
	Python not initialized
	$
	...

	The relevant part of the code is:
	...
	static void
	gdbpy_initialize (const struct extension_language_defn *extlang)
	{
	  if (!do_start_initialization () && PyErr_Occurred ())
	    gdbpy_print_stack ();

	   gdbpy_enter enter_py;
	...

	What happens is that:
	- do_start_initialization returns false because Py_InitializeFromConfig fails,
	  leaving us in the !Py_IsInitialized () state
	- PyErr_Occurred () returns true
	- gdbpy_print_stack is called, which prints
	  "Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings"

	The problem is that in the Py_IsInitialized () == false state, very few
	functions can be called, and PyErr_Occurred is not one of them [1], and
	likewise functions in gdbpy_print_stack.

	Fix this by:
	- guarding the PyErr_Occurred / gdbpy_print_stack part with Py_IsInitialized ().
	- handling the !Py_IsInitialized () case by printing the failure PyStatus
	  in do_start_initialization

	This gets us instead:
	...
	$ PYTHONHOME=foo ./gdb.sh -q
	Python path configuration:
	  PYTHONHOME = 'foo'
	  ...
	Python initialization failed: failed to get the Python codec of the filesystem encoding
	Python not initialized
	$
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://docs.python.org/3/c-api/init.html#before-python-initialization

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Handle EINTR in event-pipe.cc
	Use gdb syscall wrappers to handle EINTR in event-pipe.cc.

	Tested on aarch64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle EINTR in ser-event.c
	Use gdb syscall wrappers to handle EINTR in ser-event.c.

	Tested on aarch64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Add gdb::wait
	Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled.

	Tested on x86_64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Use gdb::waitpid more often
	Use gdb::waitpid instead of plain waitpid, making sure that EINTR is handled.

	Tested on x86_64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Add gdb::{waitpid,read,write,close}
	We have gdb::handle_eintr, which allows us to rewrite:
	...
	  ssize_t ret;
	    do
	      {
	        errno = 0;
	        ret = ::write (pipe[1], "+", 1);
	      }
	    while (ret == -1 && errno == EINTR);
	...
	into:
	...
	  ssize_t ret = gdb::handle_eintr (-1, ::write, pipe[1], "+", 1);
	...

	However, the call to write got a bit mangled, requiring effort to decode it
	back to its original form.

	Instead, add a new function gdb::write that allows us to write:
	...
	  ssize_t ret = gdb::write (pipe[1], "+", 1);
	...

	Likewise for waitpid, read and close.

	Tested on x86_64-linux.

2024-11-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/disasm: fix demangling when disassembling the current function
	When disassembling function symbols in C++ code, if GDB is asked to
	disassemble a function by name then the function name in the header
	line can be demangled by turning on `set print asm-demangle on`, e.g.:

	  (gdb) disassemble foo_type::some_function
	  Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
	     0x0000000000401142 <+0>:	push   %rbp
	     ... etc ...
	  End of assembler dump.
	  (gdb) set print asm-demangle on
	  (gdb) disassemble foo_type::some_function
	  Dump of assembler code for function foo_type::some_function(my_type):
	     0x0000000000401142 <+0>:	push   %rbp
	     ... etc ...                                                        │
	  End of assembler dump.                                                │

	However, if GDB is disassembling the current function, then this
	demangling doesn't work, e.g.:

	  (gdb) break foo_type::some_function
	  Breakpoint 1 at 0x401152: file mangle.cc, line 16.
	  (gdb) run
	  Starting program: /tmp/mangle

	  Breakpoint 1, foo_type::some_function (this=0x7fffffffa597, obj=...) at mangle.cc:16
	  16	    obj.update ();
	  (gdb) disassemble
	  Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
	     0x0000000000401142 <+0>:	push   %rbp
	     ... etc ...
	  End of assembler dump.
	  (gdb) set print asm-demangle on
	  (gdb) disassemble
	  Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
	     0x0000000000401142 <+0>:	push   %rbp
	     ... etc ...
	  End of assembler dump.

	This commit fixes this issue, and extends gdb.cp/disasm-func-name.exp,
	which was already testing the first case (disassemble by name) to also
	cover disassembling the current function.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Ensure locale is restored in do_start_initialization
	I noticed in do_start_initialization:
	...
	  std::string oldloc = setlocale (LC_ALL, NULL);
	  setlocale (LC_ALL, "");
	  ...
	  if (count == (size_t) -1)
	    {
	      fprintf (stderr, "Could not convert python path to string\n");
	      return false;
	    }
	  setlocale (LC_ALL, oldloc.c_str ());
	...
	that the old locale is not restored if the "return false" is triggered.

	Fix this by using SCOPE_EXIT.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Sam James  <sam@gentoo.org>

	libiberty: sync with gcc again
	This imports the following single commit from GCC as of r15-5586-g77f4b1097e6aec:
		961c50410926 Add LTO support

	That change slipped in while I was preparing the previous just-pushed sync.

2024-11-22  Sam James  <sam@gentoo.org>

	libiberty: sync with gcc
	This imports the following commits from GCC as of r15-5375-gbeec291225be9b:
		94bea5dd6c9a libiberity: ANSIfy test-demangle.c
		aa84020b2edb libiberty: Fix comment typos
		c1b2100e736c libiberty: Restore build with CP_DEMANGLE_DEBUG defined
		bb8dd0980b39 libiberty: Fix up > 64K section handling in simple_object_elf_copy_lto_debug_section [PR116614]

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Simplify amd64_windows_store_arg_in_reg
	Simplify amd64_windows_store_arg_in_reg by:
	- replacing memset with value initialization,
	- making valbuf a gdb::array_view, allowing us to:
	  - replace memcpy with std::copy, and
	  - use valbuf.size () instead of arg->type->size (), and
	- dropping the std::min in std::min (type->length (), (ULONGEST) 8), since
	  we're already asserting that type->length () <= 8.

	Suggested-By: Tom Tromey <tom@tromey.com>

	Tested by rebuilding on x86_64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require local host in gdb.base/bg-exec-sigint-bp-cond.exp
	I noticed that gdb.base/bg-exec-sigint-bp-cond.exp fails for remote host
	(concretely, host board local-remote-host and target board
	remote-gdbserver-on-localhost):
	...
	(gdb) c&^M
	Continuing.^M
	(gdb) bash: line 0: kill: (23834) - Operation not permitted^M
	^M
	Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
	23        return 0;^M
	...
	due to getting gdb's pid like this:
	...
	    set gdb_pid [exp_pid -i [board_info host fileid]]
	...

	For remote host using ssh, this returns the pid of the ssh session on build.

	Fix this by requiring local host.

	Tested on x86_64-linux.

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/bg-exec-sigint-bp-cond.exp for signal merging
	The test-case gdb.base/bg-exec-sigint-bp-cond.exp sends 10 SIGINTS to gdb, and
	counts whether 10 have arrived.

	Occasionally, less than 10 arrive due to signal merging [1].

	This is more likely to happen when building gdb with -fsanitize=thread.

	Fix this by instead, sending one SIGINT at a time, and waiting for it to
	arrive.

	This still makes the test-case fail if the fix fixing the PR that the
	test-case was introduced for is reverted.

	Tested on aarch64-linux and x86_64-linux.

	PR testsuite/32329
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32329

	[1] https://www.gnu.org/software/libc/manual/html_node/Merged-Signals.html

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Workaround tsan select bug
	When building gdb with -O0 and -fsanitize-thread, I run into a large number of
	timeouts caused by gdb hanging, for instance:
	...
	(gdb) continue^M
	Continuing.^M
	[Inferior 1 (process 378) exited normally]^M
	FAIL: gdb.multi/stop-all-on-exit.exp: continue until exit (timeout)
	...

	What happens is the following:
	- two inferiors are added, stopped at main
	- inferior 1 is setup to exit after 1 second
	- inferior 2 is setup to exit after 10 seconds
	- the continue command is issued
	- because of set schedule-multiple on, both inferiors continue
	- the first inferior exits
	- gdb sends a SIGSTOP to the second inferior
	- the second inferior receives the SIGSTOP, and raises a SIGCHILD
	- gdb calls select, and blocks
	- the signal arrives, and interrupts select
	- ThreadSanitizers signal handler is called, which marks the signal pending
	  internally
	- select returns -1 with errno == EINTR
	- gdb calls select again, and blocks
	- gdb hangs, waiting for gdb's sigchild_handler to be called

	This is a bug [1] in ThreadSanitizer.  When select is called with
	timeout == nullptr, it is blocking but ThreadSanitizer doesn't consider it so,
	and consequently doesn't see the need to call sigchild_handler.

	Work around this by:
	- instead of using the blocking select variant, forcing a small timeout and
	- upon timeout calling a function that ThreadSanitizer does consider
	  blocking: usleep, forcing sigchild_handler to be called.

	Tested on x86_64-linux.

	PR build/32295
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32295

	[1] https://github.com/google/sanitizers/issues/1813

2024-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Add gdb_select variant for looping
	In interruptible_select we run gdb_select in a loop:
	...
	  do
	    {
	      res = gdb_select (n, readfds, writefds, exceptfds, timeout);
	    }
	  while (res == -1 && errno == EINTR);
	...
	but man select tells us that:
	- if using select() within a loop, the sets (readfds, writefds and
	  exceptfds) must be reinitialized before each call, and
	- timeout should be considered to be undefined after select() returns.

	Add a gdb_select variant:
	...
	static int
	gdb_select (int n,
		    const fd_set *req_readfds, fd_set *ret_readfds,
		    const fd_set *req_writefds, fd_set *ret_writefds,
		    const fd_set *req_exceptfds, fd_set *ret_exceptfds,
		    const struct timeval *req_timeout, struct timeval *ret_timeout)
	...
	that keeps requested and returned values separate, ensuring that the requested
	values stay constant.

	Tested on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-11-22  Martin Storsjö  <martin@martin.st>

	ld/PE: Handle MS style import libraries for files named *.exe too
	When handling MS style import libraries (also called short import
	libraries, or ILF), we need to detect the kind of library.

	So far, this has been done by looking at the member file names
	in the import library - in an MS style import library, all the
	member files for a specific library have the same member file
	name - the name of the runtime module to link against. Usually
	this is a DLL - thus we do a case insensitive comparison and
	check if the suffix is .dll.

	However, an .exe can also export symbols which can be linked
	against in the same way. In particular, if linking against
	WDK (Windows Driver Kit) import libraries, e.g. wdmsec.lib, the
	import libraries can provide imports for ntoskrnl.exe.

	Instead of specifically checking for *.dll (and *.exe, etc),
	invert the condition and skip archive members named *.o and *.obj.
	For any remaining archive members, that do contain .idata
	sections, apply the renaming. (The renaming is also mostly
	harmless if applied where it isn't needed; if archive members
	already have unique file names, their relative ordering should
	remain intact except for very contrieved cases.)

2024-11-22  Nelson Chu  <nelson.chu@sifive.com>
	    Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Support SiFive extensions: xsfvqmaccdod, xsfvqmaccqoq and xsfvfnrclipxfqf
	Those SiFive extensions have been published on the web for a while, and we plan
	to implement intrinsics in GCC for those instructions soon.

	NOTE: The original patch was written by Nelson when he was still working at
	SiFive, and Kito rebased it to the trunk. Therefore, I kept the author as Nelson
	with his SiFive email.

	Document links:
	xsfvqmaccdod: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification
	xsfvqmaccqoq: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification
	xsfvfnrclipxfqf: https://www.sifive.com/document-file/fp32-to-int8-ranged-clip-instructions

2024-11-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-21  Tom Tromey  <tromey@adacore.com>

	Don't put JIT_READER_DIR into help text
	The 80-column-help-string self-test can fail if gdb's install
	directory is too long, because the help for "jit-reader-load" includes
	JIT_READER_DIR.

	This help text is actually somewhat misleading, though.
	JIT_READER_DIR is not actually used directly -- instead the relocated
	variant is used.

	This patch adds a new "show jit-reader-directory" command and changes
	the help text to refer to this instead.  I considered adding a "set"
	command as well, but since absolute paths are acceptable here, and
	since this is a very niche command anyway, I figured there was no need
	to bother.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32357
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-11-21  Andrew Burgess  <aburgess@redhat.com>

	gdb/build-id: protect against weirdly short build-ids
	While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised
	that GDB would likely not do what we wanted if a build-id was ever a
	single byte.

	Right now, build-ids generated by the GNU linker are 32 bytes, but
	there's nothing that forces this to be the case, it's pretty easy to
	create a fake, single byte, build-id.  Given that the build-id is an
	external input (read from the objfile), GDB should protect itself
	against these edge cases.

	The problem with build_id_to_bfd_suffix is that this function creates
	the path used to lookup either the debug information, or an
	executable, based on its build-id.  So a 3-byte build-id 0xaabbcc will
	look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`.
	However, a single byte build-id 0xaa, will look in the file:
	`$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right.

	Worse, when looking for an objfile given a build-id GDB will look for
	a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing
	'/' character.

	I propose that, in build_id_to_bfd_suffix we just return early if the
	build-id is 1 byte (or less) with a return value that indicates no
	separate file was found.

	For testing I made use of the DWARF assembler.  I needed to update the
	build-id creation proc, the existing code assumes that the build-id is
	a multiple of 4 bytes, so I added some additional padding to ensure
	that the generated note was a multiple of 4 bytes, even if the
	build-id was not.

	I added a test with a 1 byte build-id, and also for the case where the
	build-id has zero length.  The zero length case already does what
	you'd expect (no debug is loaded) as the bfd library rejects the
	build-id when loading it from the objfile, but adding this additional
	test is pretty cheap.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

2024-11-21  Rohr, Stephan  <stephan.rohr@intel.com>

	testsuite: skip confirmation in 'gdb_reinitialize_dir'
	Some shells automatically confirm the 'dir' command:

	  (gdb) dir
	  Reinitialize source path to empty? (y or n)
	    [answered Y; input not from terminal]
	  Source directories searched: $cdir;$cwd
	  (gdb) y
	  dir <...>/gdb/testsuite/gdb.base
	  Undefined command: "y".  Try "help".

	For example, this reprdocues in a MinGW32 environment with
	'TERM=dumb'.  Skip sending 'y' if the command is already confirmed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-20  Peter Bergner  <bergner@linux.ibm.com>

	PowerPC: Add support for RFC02677 - VSX Vector Rotate Left Word
	opcodes/
		* ppc-opc.c (powerpc_opcodes): Add xvrlw.

	gas/
		* testsuite/gas/ppc/future.s: Add test for xvrlw.
		* testsuite/gas/ppc/future.d: Likewise.

2024-11-20  Tom Tromey  <tromey@adacore.com>

	Improve choice sorting in ada-lang.c
	ada-lang.c has a "sort_choices" function that claims to sort the
	symbol choices, but which does not really implement sorting.  This
	patch changes this code to really sort the result vector, sorting
	first by filename, then line number, and finally by the symbol name.

	The filename sorting is done first by comparing basenames.  It turns
	out that gnatmake and gprbuild invoke the compiler a bit differently,
	so depending on which one you use, the results of a naive sort might
	be different (due to the use of absolute or relative paths).

2024-11-20  Andre Vieira  <andre.simoesdiasvieira@arm.com>

	arm: Support pac_key_* register operand for MRS/MSR in Armv8.1-M Mainline
	Add support for pac_key_[pu]_[0-3](_ns)? register operands for the MRS and MSR
	instructions when assembling for Armv8.1-M Mainline, as well as adding the
	corresponding support for disassembling instructions that use it.

2024-11-20  Mohamed Bouhaouel  <mohamed.bouhaouel@intel.com>

	gdb: add Mohamed Bouhaouel to gdb/MAINTAINERS

2024-11-20  Nick Clifton  <nickc@redhat.com>

	Remove Debian from SECURITY.txt

2024-11-20  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: fix reference leak in gdb.BreakpointLocation.thread_groups
	While reviewing another patch which uses PyList_Append I took a look
	at our other uses of PyList_Append in GDB.  I spotted something odd
	about the use in bplocpy_get_thread_groups.

	We do:

	    gdbpy_ref<> num = gdb_py_object_from_ulongest (inf->num);

	At which point `num` will own a reference to the `int` object.  But
	when we add the object to the result list we do:

	    if (PyList_Append (list.get (), num.release ()) != 0)
	      return nullptr;

	By calling `release` we pass ownership of the reference to
	PyList_Append, however, PyList_Append acquires its own reference, it
	doesn't take ownership of an existing reference.

	The consequence of this is that we leak the reference held in `num`.

	This mostly isn't a problem though.  For small (< 257) integers Python
	keeps a single instance of each and just hands out new references.  By
	leaking the references, these small integers will not be cleaned up as
	the Python interpreter shuts down, but that is only done when GDB
	exits, so hardly a disaster.  As we're dealing with GDB's internal
	inferior number here, unless the user has 257+ inferiors, we'll not
	actually be leaking memory.

	Still, lets do things right.  Switch to using `num.get ()`.  Now when
	`num` goes out of scope it will decrement the reference count as
	needed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-20  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Zcmt instructions and csr.
	This patch supports Zcmt[1] instruction 'cm.jt' and 'cm.jalt'.
	Add new CSR jvt for tablejump using. Since 'cm.jt' and 'cm.jalt'
	have the same instructiong encoding, use 'match_cm_jt' and 'match_cm_jalt'
	check the 'zcmt_index' field to distinguish them.

	[1] https://github.com/riscvarchive/riscv-code-size-reduction/releases

	Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
	Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
	Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
	Co-Authored by: Simon Cook <simon.cook@embecosm.com>
	Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
	Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): New extension.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* config/tc-riscv.c (enum riscv_csr_class): New CSR.
		(riscv_csr_address): Ditto.
		(validate_riscv_insn): New operand.
		(riscv_ip): Ditto.
		* testsuite/gas/riscv/csr-version-1p10.d: New CSR.
		* testsuite/gas/riscv/csr-version-1p10.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.l: Ditto.
		* testsuite/gas/riscv/csr.s: Ditto.
		* testsuite/gas/riscv/march-help.l: New extension.
		* testsuite/gas/riscv/zcmt-fail.d: New test.
		* testsuite/gas/riscv/zcmt-fail.l: New test.
		* testsuite/gas/riscv/zcmt-fail.s: New test.
		* testsuite/gas/riscv/zcmt.d: New test.
		* testsuite/gas/riscv/zcmt.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_CM_JT): New opcode.
		(MASK_CM_JT): New mask.
		(MATCH_CM_JALT): New opcode.
		(MASK_CM_JALT): New mask.
		(CSR_JVT): New CSR.
		(DECLARE_INSN): New declaration.
		(DECLARE_CSR): Ditto.
		* opcode/riscv.h (EXTRACT_ZCMT_INDEX): New marco.
		(ENCODE_ZCMT_INDEX): Ditto.
		(enum riscv_insn_class): New class.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): New operand.
		* riscv-opc.c (match_cm_jt): New function.
		(match_cm_jalt): Ditto.

2024-11-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-19  Charles Baylis  <cbaylis@undo.io>  (tiny change)

	gdb: Remove inappropriate comments
	Remove some inappropriate comments in darwin_nat_target::attach,
	gnu_nat_target::attach and inf_ptrace_target::attach.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-19  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Fix shellcheck warnings in spellcheck.sh
	Fix shellcheck warnings in spellcheck.sh, found using shellcheck v0.10.0.

	Ran shellcheck v0.10.0 (on a system with shellcheck version 0.8.0) using this
	command from an RFC patch [1]:
	...
	$ ./gdb/contrib/pre-commit-shellcheck.sh ./gdb/contrib/spellcheck.sh
	...

	Tested on x86_64-linux

	[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html

2024-11-19  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Don't report warnings when linking different privileged spec objects.
	Since only the abandoned privileged spec v1.9.1 will have conflict csrs, to
	keep the compatible we still report warnings when linking privileged spec
	v1.9.1 objects with others.  But don't report warnings for other compatible
	cases because it is actually a bit noisy and useless...

	bfd/
		* elfnn-riscv.c (riscv_merge_attributes): Only report warnings when
		linking the abandoned privileged spec v1.9.1 object with others.
	ld/
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Removed.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Removed.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Removed.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Removed.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Removed.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Removed.
		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.

2024-11-19  Hu, Lin1  <lin1.hu@intel.com>

	Support x86 Intel MSR_IMM
	gas/ChangeLog:

		* NEWS: Support x86 Intel MSR_IMM.
		* config/tc-i386.c (cpu_arch): Add MSR_IMM.
		(cpu_flags_match): Add MSR_IMM to APX_F related processing.
		(i386_assemble): WRMSRNS's first operand is imm32, so add
		MN_wrmsrns like MN_uwrmsr.
		* doc/c-i386.texi: Document .msr_imm.
		* testsuite/gas/i386/i386.exp: Run MSR_IMM tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/msr_imm-inval.l: New test.
		* testsuite/gas/i386/msr_imm-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-msr_imm-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-msr_imm.d: Ditto.
		* testsuite/gas/i386/x86-64-msr_imm.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: Add REG_VEX_MAP7_F6_L_0_W_0,
		PREFIX_VEX_MAP7_F6_L_0_W_0_R_0_X86_64,
		X86_64_VEX_MAP7_F6_L_0_W_0_R_0,
		VEX_LEN_MAP7_F6,
		VEX_W_MAP7_F6_L_0.
		(reg_table): New entry for MSR_IMM.
		(prefix_table): Ditto.
		(x86_64_table): Ditto.
		(vex_len_table): Ditto.
		(vex_w_table): Ditto.
		(map7_f6_opcode): New variable for MAP7.
		(get_valid_dis386): Support MAP7.
		* i386-gen.c (cpu_flags): Add MSR_IMM.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (i386_cpu_flags): Add cpumsr_imm.
		* i386-opc.tbl: Add MSR_IMM instructions.
		* i386-tbl.h: Regenerated.

2024-11-19  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Do not relax pcalau12i+ld.d when there is overflow
	There is no overflow check for the relaxation of pcalau12i+ld.d =>
	pcalau12i+addi.d. For instruction sequences that can be relaxed,
	they are directly relaxed to pcalau12i+addi.d. However, when the
	relative distance between the symbol and the pc exceeds the 32-bit
	range, the symbol value cannot be obtained correctly.

	Adds an overflow check for the relaxation of pcalau12i+ld.d.
	If it is found that the relaxation will overflow, it will not
	be relaxed.

2024-11-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-18  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: renaming of arm to AArch64

	aarch64: remove annoying white spaces in bfd/elfnn-aarch64.c

2024-11-18  Christina Schimpe  <christina.schimpe@intel.com>

	LAM: Enable tagged pointer support for watchpoints.
	The Intel (R) linear address masking (LAM) feature modifies the checking
	applied to 64-bit linear addresses.  With this so-called "modified
	canonicality check" the processor masks the metadata bits in a pointer
	before using it as a linear address.  LAM supports two different modes that
	differ regarding which pointer bits are masked and can be used for
	metadata: LAM 48 resulting in a LAM width of 15 and LAM 57 resulting in a
	LAM width of 6.

	This patch adjusts watchpoint addresses based on the currently enabled
	LAM mode using the untag mask provided in the /proc/<pid>/status file.
	As LAM can be enabled at runtime or as the configuration may change
	when entering an enclave, GDB checks enablement state each time a watchpoint
	is updated.

	In contrast to the patch implemented for ARM's Top Byte Ignore "Clear
	non-significant bits of address on memory access", it is not necessary to
	adjust addresses before they are passed to the target layer cache, as
	for LAM tagged pointers are supported by the system call to read memory.
	Additionally, LAM applies only to addresses used for data accesses.
	Thus, it is sufficient to mask addresses used for watchpoints.

	The following examples are based on a LAM57 enabled program.
	Before this patch tagged pointers were not supported for watchpoints:
	~~~
	(gdb) print pi_tagged
	$2 = (int *) 0x10007ffffffffe004
	(gdb) watch *pi_tagged
	Hardware watchpoint 2: *pi_tagged
	(gdb) c
	Continuing.
	Couldn't write debug register: Invalid argument.
	~~~~

	Once LAM 48 or LAM 57 is enabled for the current program, GDB can now
	specify watchpoints for tagged addresses with LAM width 15 or 6,
	respectively.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-11-18  Christina Schimpe  <christina.schimpe@intel.com>

	gdb: Make tagged pointer support configurable.
	The gdbarch function gdbarch_remove_non_address_bits adjusts addresses to
	enable debugging of programs with tagged pointers on Linux, for instance for
	ARM's feature top byte ignore (TBI).
	Once the function is implemented for an architecture, it adjusts addresses for
	memory access, breakpoints and watchpoints.

	Linear address masking (LAM) is Intel's (R) implementation of tagged
	pointer support.  It requires certain adaptions to GDB's tagged pointer
	support due to the following:
	- LAM supports address tagging for data accesses only.  Thus, specifying
	  breakpoints on tagged addresses is not a valid use case.
	- In contrast to the implementation for ARM's TBI, the Linux kernel supports
	  tagged pointers for memory access.

	This patch makes GDB's tagged pointer support configurable such that it is
	possible to enable the address adjustment for a specific feature only (e.g
	memory access, breakpoints or watchpoints).  This way, one can make sure
	that addresses are only adjusted when necessary.  In case of LAM, this
	avoids unnecessary parsing of the /proc/<pid>/status file to get the
	untag mask.

	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
	(AArch64) Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	x86: rename SPACE_{,E}VEX_MAP<N>
	Map7 already has dual purpose for USER-MSR (and is to gain more for
	MSR-IMM), while Map5 is about to gain VEX uses for AMX extensions. Drop
	the not really meaningful infixes and (in the opcode table) prefixes,
	retaining merely EVexMap4 for encoding EVex128 at the same time.

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	x86: VP2INTERSECT{D,Q} have mask register destination group
	Much like AVX512-{4FMAPS,4VNNIW} have a constraint on their register
	source, there's a constraint (need to be even) on the destination
	register here.

	Adjust "good" test cases accordingly, and add a new test case to check
	the warning.

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	x86: generalize "implicit quad group" handling
	We'll want to re-use it for VP2INTERSECT{D,Q}.

	While there add a testcase for the similarly affected AVX512-4VNNIW
	insns.

2024-11-18  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Fix spellcheck.sh for bash < 5.1
	Since commit 5cb0406bb64 ("[gdb/contrib] Handle capitalized words in
	spellcheck.sh"), spellcheck.sh uses '${pat@u}' which is available starting
	bash 5.1, and consequently the script breaks with bash 4.4.

	Fix this by checking for the bash version, and using an alternative
	implementation for bash < 5.1.

	Tested on x86_64-linux.

2024-11-18  Benjamin Drung  <benjamin.drung@canonical.com>

	ld: Support percent-encoded JSON in --package-metadata
	Specifying the compiler flag `-Wl,--package-metadata=<JSON>` will not
	work in case the JSON contains a comma, because compiler drivers eat
	commas. Example:

	```
	$ echo "void main() { }" > test.c
	$ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c
	/usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory
	collect2: error: ld returned 1 exit status
	```

	The quotation marks in the JSON value do not work well with shell nor
	make. Specifying the `--package-metadata` linker flag in a `LDFLAGS`
	environment variable might loose its quotation marks when it hits the
	final compiler call.

	So support percent-encoded and %[string] encoded JSON data in the
	`--package-metadata` linker flag. Percent-encoding is used because it is
	a standard, simple to implement, and does take too many additional
	characters. %[string] encoding is supported for having a more readable
	encoding.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32003
	Bug-Ubutru: https://bugs.launchpad.net/bugs/2071468

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	gas: move had_errors() invocation in finishing of subsegs
	Invoking this repeatedly in an inner loop is not only inefficient, but
	may lead to inconsistencies in e.g. the listings that the original
	comment author cared about. (Accept potential inconsistencies across
	distinct sections though, to cover all invocations of the function.)

	ELF: SHF_STRINGS isn't really tied to SHF_MERGE
	It's not overly useful without it, but the spec doesn't name any
	dependency between the two. People may want to use it for purely
	informational purposes, for example. Adjust, in particular, entity size
	processing to be engaged if either flag is set, as mandated by the spec.

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	ELF: SHF_MERGE vs SHT_NOBITS
	bfd/merge.c puts in quite some effort to track mergable sections. That's
	all wasted for sections which don't have contents, as for them
	_bfd_write_merged_section() will never be called.

	With the combination not having any useful effect, also warn about this
	in gas.

2024-11-18  Jan Beulich  <jbeulich@suse.com>

	gas/ELF: also reject merge entity size being zero
	This won't have any useful effect, so is at best marginally less bogus
	than a negative value.

	The change actually points out a flawed (for Arm) testcase: @ is a
	comment character there.

2024-11-18  Jens Remus  <jremus@linux.ibm.com>

	s390: Add arch15 Concurrent-Functions Facility insns
	opcodes/
		* s390-opc.txt: Add arch15 Concurrent-Functions Facility
		instructions.
		* s390-opc.c (INSTR_SSF_RRDRD2, MASK_SSF_RRDRD2): New SSF
		instruction format variant.

	gas/testsuite/
		* gas/s390/zarch-arch15.d: Tests for arch15 Concurrent-Functions
		Facility instructions.
		* gas/s390/zarch-arch15.s: Likewise.

2024-11-18  Jens Remus  <jremus@linux.ibm.com>

	s390: Add arch15 instruction names
	opcodes/
		* s390-opc.txt: Add arch15 instruction names.

2024-11-18  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix some typos
	Run gdb/contrib/spellcheck.sh on directories gdb*.

	Fix typo:
	...
	unkown -> unknown
	...

	Tested on x86_64-linux.

2024-11-18  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add spellcheck.sh --print-dictionary
	Add an option --print-dictionary to spellcheck.sh that allows us to inspect
	the effective dictionary.

	Verified with shellcheck.

2024-11-18  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Allow thru in spellcheck.sh
	Eli mentioned that "thru" is a widely-accepted shorthand [1].

	Skip the "thru->through" rule by adding an overriding identity rule
	"thru->thru".

	Verified with shellcheck.

	[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213380.html

2024-11-18  Sam James  <sam@gentoo.org>

	gprofng: fix -std=gnu23 compatibility wrt unprototyped functions
	C23 removes support for unprototyped functions. Fix function pointer types
	accordingly.

	This does not fix all instances, there's a few left as I commented on in
	PR32374 (e.g. setitimer which I have a local workaround for but it involves
	a glibc implementation detail; the Linaro precommit CI tester pointed that
	out too, so dropped that).

	ChangeLog:
		PR gprofng/32374

		* libcollector/collector.c (collector_sample): Fix prototype.
		* libcollector/envmgmt.c (putenv): Ditto.
		(_putenv): Ditto.
		(__collector_putenv): Ditto.
		(setenv): Ditto.
		(_setenv): Ditto.
		(__collector_setenv): Ditto.
		(unsetenv): Ditto.
		(_unsetenv): Ditto.
		(__collector_unsetenv): Ditto.
		* libcollector/jprofile.c (open_experiment): Ditto.
		(__collector_jprofile_enable_synctrace): Ditto.
		(jprof_find_asyncgetcalltrace): Ditto.
		* libcollector/libcol_util.c (__collector_util_init): Ditto.
		(ARCH): Ditto.
		* libcollector/mmaptrace.c (collector_func_load): Ditto.
		(collector_func_unload): Ditto.
		* libcollector/unwind.c (__collector_ext_unwind_init): Ditto.
		* src/collector_module.h: Ditto.

2024-11-18  Sam James  <sam@gentoo.org>

	ld: fix -std=gnu23 compatibility wrt _Bool
	GCC trunk now defaults to -std=gnu23. We return false in a few places
	which can't work when true/false are a proper type (_Bool). Return NULL
	where appropriate instead of false. All callers handle this appropriately.

	ChangeLog:
		PR ld/32372

		* pdb.c (add_stream): Return NULL.

2024-11-18  Sam James  <sam@gentoo.org>

	binutils: fix -std=gnu23 compatibility wrt _Bool
	GCC trunk now defaults to -std=gnu23. We return false in a few places
	which can't work when true/false are a proper type (_Bool). Return NULL
	where appropriate instead of false. All callers handle this appropriately.

	ChangeLog:
		PR ld/32372

		* prdbg.c (visibility_name): Return NULL.

2024-11-18  Sam James  <sam@gentoo.org>

	opcodes: fix -std=gnu23 compatibility wrt static_assert
	static_assert is declared in C23 so we can't reuse that identifier:
	* Define our own static_assert conditionally;

	* Rename "static assert" hacks to _N as we do already in some places
	  to avoid a conflict.

	ChangeLog:
		PR ld/32372

	        * i386-gen.c (static_assert): Define conditionally.
	        * mips-formats.h (MAPPED_INT): Rename identifier.
	        (MAPPED_REG): Rename identifier.
	        (OPTIONAL_MAPPED_REG): Rename identifier.
	        * s390-opc.c (static_assert): Define conditionally.

2024-11-18  Sam James  <sam@gentoo.org>

	bfd: fix -std=gnu23 compatibility wrt _Bool
	GCC trunk now defaults to -std=gnu23. We return false in a few places
	which can't work when true/false are a proper type (_Bool). Return NULL
	where appropriate instead of false. All callers handle this appropriately.

	ChangeLog:
		PR ld/32372

		* elf32-ppc.c (ppc_elf_tls_setup): Return NULL.
	        * elf32-xtensa.c (translate_reloc_bfd_fix): Ditto.
	        (translate_reloc): Ditto.
	        * elf64-ppc.c (update_local_sym_info): Ditto.
	        * mach-o.c (bfd_mach_o_lookup_uuid_command): Ditto.
	        * xsym.c (bfd_sym_read_name_table): Ditto.

2024-11-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-17  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Always check IBT PLT before BND PLT
	Since BND PLT has been deprecated and the same IBT PLT is used for both
	x86-64 and x32, always check IBT PLT before BND PLT when synthesizing
	PLT symtab.

		* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Always check
		elf_x86_64_lazy_ibt_plt and elf_x86_64_non_lazy_ibt_plt first.

2024-11-17  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	gdb: Update linkage name lookup function to allow mst_file_data/bss types.
	From the commit 667ed4b14ddaa9af196481f1757c0e517e80b6ed onward, instead
	of normal name GDB looks for the "jit_descriptor" linkage name in the JIT
	code initialization.  Without this change, the function
	"lookup_minimal_symbol_linkage", only matches the non-static data.  So in
	case jit_debugger is static type then setting up breakpoint in the JIT code
	fails.  Issue is seen for the intel compilers, where jit_debug_descriptor has
	static type i.e. "mst_file_data".  Hence lookup_minimal_symbol_linkage returns
	nullptr for it.  So, in this case breakpoint does not hit in the JIT code.
	To resolve this, the commit introduces a new boolean argument to the
	lookup_minimal_symbol_linkage function.  This argument allows the function to
	also match mst_file_data and mst_file_bss types when set to true.  The
	function is called with this new argument set to true only from JIT code
	initialization handling, ensuring that the current behavior remains unchanged
	for other cases.  Because handling of static types of data symbols for all cases
	result in regression for "gdb.base/print-file-var.exp" test.

	Example of minsym for the JIT code emitted by the intel compilers where
	lookup_minimal_symbol_linkage fails without this change because jit_debugger
	type is "mst_file_data".

	(top-gdb) p *msymbol
	$1 = {<general_symbol_info> =
	{m_name = 0x7fffcc77dc95 "__jit_debug_descriptor",
	m_value = {ivalue = 84325936, block = 0x506b630,
	bytes = 0x506b630 <error: Cannot access memory at address 0x506b630>,
	address = 0x506b630, unrel_addr = (unknown: 0x506b630),
	common_block = 0x506b630, chain = 0x506b630},
	language_specific = {obstack = 0x0, demangled_name = 0x0},
	m_language = language_unknown, ada_mangled = 0, m_section = 29},
	m_size = 24, filename = 0x55555a751b70 "JITLoaderGDB.cpp",
	m_type = mst_file_data, created_by_gdb = 0,
	m_target_flag_1 = 0, m_target_flag_2 = 0, m_has_size = 1,
	name_set = 1, hash_next = 0x55555b86e4f0, demangled_hash_next = 0x0}

	Updated the test "jit-elf-so.exp" to test the static type of jit_descriptor
	object.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-17  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Drop x32 references in PLT entry variables
	e9c11d58b95 x86-64: Remove BND from 64-bit IBT PLT

	removed the BND prefix from 64-bit IBT PLT by using x32 IBT PLT.

	Drop x32 references in PLT entry variables.

		* elf64-x86-64.c (elf_x86_64_lazy_ibt_plt_entry): Renamed to ...
		(elf_x86_64_lazy_bnd_ibt_plt_entry): This.
		(elf_x32_lazy_ibt_plt_entry): Renamed to ...
		(elf_x86_64_lazy_ibt_plt_entry): This.
		(elf_x86_64_non_lazy_ibt_plt_entry): Renamed to ...
		(elf_x86_64_non_lazy_bnd_ibt_plt_entry): This.
		(elf_x32_non_lazy_ibt_plt_entry): Renamed to ...
		(elf_x86_64_non_lazy_ibt_plt_entry): This.
		(elf_x86_64_eh_frame_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_eh_frame_lazy_bnd_ibt_plt): This.
		(elf_x32_eh_frame_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_eh_frame_lazy_ibt_plt): This.
		(elf_x86_64_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_lazy_bnd_ibt_plt): This.  Updated.
		(elf_x32_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_lazy_ibt_plt): This.  Updated.
		(elf_x86_64_non_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_non_lazy_bnd_ibt_plt): This.  Updated.
		(elf_x32_non_lazy_ibt_plt): Renamed to ...
		(elf_x86_64_non_lazy_ibt_plt): This.  Updated.
		(elf_x86_64_get_synthetic_symtab): Updated.
		(elf_x86_64_link_setup_gnu_properties): Likewise.

2024-11-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-16  Tom Tromey  <tom@tromey.com>

	Use bool for solib::symbols_loaded
	This changes solib::symbols_loaded to be of type 'bool'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-11-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-15  Barnabás Pőcze  <pobrn@protonmail.com>

	PR 32359, --dependency-file: wrong error message if fopen fails
	Use of %E in ld error messages requires bfd_error to be set.

2024-11-15  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix segfault with dwp file
	Consider the following test-case:
	...
	$ cat test.c
	int main (void) { return 0; }
	$ clang -g -gsplit-dwarf test.c -o test
	$ llvm-dwp -e test -o test.dwp
	...

	This runs into a segmentation fault:
	...
	$ gdb -q -batch test
	Fatal signal: Segmentation fault
	...

	The segmentation fault happens because in read_dwo_str_index this line sets p
	to nullptr:
	...
	  const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer;
	...
	while the following code expects it to point to some data.

	The section we're trying to read is:
	...
	(gdb) p reader->dwo_file->sections.str_offsets
	$4 = {s = {section = 0xffffcc00a9d0, containing_section = 0xffffcc00a9d0},
	  buffer = 0x0, size = 28, virtual_offset = 0, readin = false, is_virtual = true}
	...

	At first glance, the section is not readin, but actually it is.

	This is a virtual section, meaning part of a containing section:
	...
	(gdb) p *reader->dwo_file->sections.str_offsets.s.containing_section
	$8 = {s = {section = 0xffffcc00cde8, containing_section = 0xffffcc00cde8},
	  buffer = 0xffffcc009650 "\030", size = 28, virtual_offset = 0, readin = true,
	  is_virtual = false}
	...
	which is readin.

	Fix this in create_dwp_v2_or_v5_section by initializing the buffer of the
	virtual section using the buffer of the containing section:
	...
	  result.buffer = section->buffer + offset;
	...

	Unfortunately it's difficult to write a test-case for this.  We'll have to
	teach the dwarf assembler to generate dwp files.

	Tested on aarch64-linux.

	This is a partial fix for PR symtab/31497.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497

2024-11-15  Tom Tromey  <tromey@adacore.com>

	Improvements to gdb.LazyString documentation
	I noticed the gdb.LazyString documentation did not mention how to
	create one.  Then, while adding this, I found a couple other ways that
	this documentation could be clarified.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-11-15  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: skip gdb.opt/inline-entry.exp for gcc 7 and older
	It was pointed out that the recently added gdb.opt/inline-entry.exp
	test would fail when run using gcc 7 and earlier, on an x86-64 target:

	  https://inbox.sourceware.org/gdb-patches/9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de

	Bernd Edlinger points out that, for gcc, the test relies on the
	-gstatement-frontiers work which was added in gcc 8.x:

	  https://inbox.sourceware.org/gdb-patches/DU2PR08MB10263357597688D9D66EA745CE4242@DU2PR08MB10263.eurprd08.prod.outlook.com

	For gcc 7.x and older, without the -gstatement-frontiers work, the
	compiler uses DW_AT_entry_pc differently, which leads to a poorer
	debug experience.

	Here is the interesting source line from inline-entry.c:

	  if ((global && bar (1)) || bar (2))

	And here's some of the relevant disassembly output:

	  Dump of assembler code for function main:
	     0x401020 <+0>:	mov    0x3006(%rip),%eax	(1)
	     0x401026 <+6>:	test   %eax,%eax		(2)
	     0x401028 <+8>:	mov    0x2ffe(%rip),%eax	(3)
	     0x40102e <+14>:	je     0x401038 <main+24>	(4)
	     0x401030 <+16>:	sub    $0x1,%eax		(5)
	     0x401033 <+19>:	jne    0x40103d <main+29>	(6)

	Lines (1), (2), and (4) represent the check of 'global'.  However,
	line (3) is actually the first instruction for 'bar' which has been
	inlined.  Lines (5) and (6) are also part of the first inlined 'bar'
	function.

	If the check of 'global' returns false then the first call to 'bar'
	should never happen, this is accomplished by the branch at (4) being
	taken.

	For gcc 8+, gcc generates a DW_AT_entry_pc with the value 0x401030,
	this is where GDB places a breakpoint for 'bar', and this address is
	after the branch at line (4), and so, if the call to 'bar' never
	happens, the breakpoint is never hit.

	For gcc 7 and older, gcc generates a DW_AT_entry_pc with the value
	0x401028, which is the first address associated with the inline 'bar'
	function.  Unfortunately, this address is also before the check of
	'global' has completed, this means that GDB hits the 'bar' breakpoint
	before the inferior has decided if 'bar' should actually be called or
	not.

	I don't think there's really much GDB can do in the older gcc
	versions, we are placing the breakpoint at the entry point, and this
	is within bar.  Given that this test does really depend on the newer
	gcc behaviour, I think the only sensible solution is to skip this test
	when an older version of gcc is being used.

	I've incorporated the check for -gstatement-frontiers support that
	Bernd suggested and now the test will be skipped for older versions of
	GCC.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-11-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: missing PyObject_IsTrue error check in bppy_init
	As with the previous two commits, this commit fixes a location where
	we called PyObject_IsTrue without including an error check, this time
	in bppy_init.

	The 'qualified' argument is supposed to be a bool, the docs say:

	  The optional QUALIFIED argument is a boolean that allows
	  interpreting the function passed in 'spec' as a fully-qualified
	  name.  It is equivalent to 'break''s '-qualified' flag (*note
	  Linespec Locations:: and *note Explicit Locations::).

	It's not totally clear that the only valid values are True or False,
	but I'm choosing to interpret the docs that way, and so I've added a
	PyBool_Type check during argument parsing.  Now, if a non-bool is
	passed the user will get a TypeError during argument parsing.  I've
	added a test to cover this case.

	This is a potentially breaking change to the Python API, but hopefully
	this will not impact too many people.  I've added a NEWS entry to
	highlight this change.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed
	Like the previous commit, I discovered that in micmdpy_set_installed
	we were calling PyObject_IsTrue, but not checking for a possible error
	value being returned.

	The micmdpy_set_installed function implements the
	gdb.MICommand.installed attribute, and the documentation indicates that
	this attribute should only be assigned a bool:

	  This attribute is read-write, setting this attribute to 'False'
	  will uninstall the command, removing it from the set of available
	  commands.  Setting this attribute to 'True' will install the
	  command for use.

	So I propose that instead of using PyObject_IsTrue we use
	PyBool_Check, and if the new value fails this check we raise an
	error.  We can then compare the new value to Py_True directly instead
	of calling PyObject_IsTrue.

	This is a potentially breaking change to the Python API, but hopefully
	this will not impact too many people, and the fix is pretty
	easy (switch to using a bool).  I've added a NEWS entry to draw
	attention to this change.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: missing PyObject_IsTrue error check in py-arch.c
	Building on the previous two commits, I was auditing our uses of
	PyObject_IsTrue looking for places where we were missing an error
	check.

	The gdb.Architecture.integer_type() function takes a 'signed' argument
	which should be a 'bool', and the docs do say:

	  If SIGNED is not specified, it defaults to 'True'.  If SIGNED is
	  'False', the returned type will be unsigned.

	Currently we use PyObject_IsTrue, but we are missing an error check.

	To fix this I've tightened the code to enforce the bool requirement at
	the point that the arguments are parsed.  With that done I can remove
	the call to PyObject_IsTrue and instead compare to Py_True directly,
	the object in question will always be a PyBool_Type.

	However, we were testing that passing a non-bool argument for 'signed'
	is treated as Py_False, this was added with this commit:

	  commit 90fe61ced1c9aa4afb263326e336330d15603fbf
	  Date:   Mon Nov 29 13:53:06 2021 +0000

	      gdb/python: don't use the 'p' format for parsing args

	which is when the PyObject_IsTrue call was added.  Given that the docs
	do seem pretty clear that only True or False are suitable argument
	values, my proposal is that we just remove these tests and instead
	test that any non-bool argument value for 'signed' gives a TypeError.

	This is a breaking change to the Python API, however, my hope is that
	this is such a edge case that it will not cause too many problem.
	I've added a NEWS entry to highlight this change though.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove some additional PyObject_IsTrue calls
	After the previous commit I audited all our uses of PyObject_IsTrue
	looking for places where we were missing an error check.  I did find
	some that are missing error checks in places where we really should
	have error checks, and I'll fix those in later commits.

	This commit however, focuses on those locations where PyObject_IsTrue
	is called, there is no error check, and the error check isn't really
	necessary because we already know that the object we are dealing with
	is of type PyBool_Type.

	Inline with the previous commit, in these cases I have removed the
	PyObject_IsTrue call, and replaced it with a comparison against
	Py_True.  In one location where it is not obvious that the object we
	have is PyBool_Type I've added an assert, but in the other cases the
	comparison to Py_True immediately follows a PyBool_Check call, so an
	assert would be redundant.

	I've added a test for the gdb.Value.format_string styling argument
	being passed a non-bool value as this wasn't previously being tested,
	though this new test will pass before and after this commit.

	There should be no functional change after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove PyObject_IsTrue call in gdbpy_handle_missing_debuginfo
	In this review:

	  https://inbox.sourceware.org/gdb-patches/87wmirfzih.fsf@tromey.com

	Tom pointed out that using PyObject_IsTrue as I was doing, though
	technically fine, at least appears to be missing an error check, and
	that it would be better to compare to Py_True directly.  I made that
	change in the patch Tom was commenting on, but I'd actually copied
	that code from elsewhere in python/python.c, so this commit updates
	the original code inline with Tom's review feedback.

	There should be no functional change after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Handle syscall clock_gettime64 for arm-linux
	When running test-case gdb.reverse/time-reverse.exp on arm-linux, I run into:
	...
	(gdb) continue^M
	Continuing.^M
	Process record and replay target doesn't support syscall number 403^M
	Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M
	Process record: failed to record execution log.^M
	^M
	Program stopped.^M
	0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
	(gdb) FAIL: $exp: mode=c: continue to breakpoint: marker2
	...

	Syscall number 403 stands for clock_gettime64 on arm-linux.

	Fix this by handling 403 in arm_canonicalize_syscall, and handling
	gdb_sys_clock_gettime64 elsewhere.

	Since i386_canonicalize_syscall is the identity function, enum value
	gdb_sys_clock_gettime64 gets a value to match i386, which also happens to be
	403.

	Tested on arm-linux.

	Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full)

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Handle capitalized words in spellcheck.sh
	The dictionary contains a few entries with capital letters:
	...
	$ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l
	143
	...
	but they don't look too interesting in the gdb context (for instance,
	Habsbourg->Habsburg), so filter them out.

	That leaves us with entries looking only like "foobat->foobar", so add
	handling of capitalized words, such that we also rewrite "Foobat" to "Foobar".

	Tested on aarch64-linux.  Verified with shellcheck.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add "doens't->doesn't" to common-misspellings.txt
	Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run
	gdb/contrib/spellcheck.sh to fix this in a few files.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Handle double quotes in spellcheck.sh
	Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the
	following typos:
	...
	inheritence -> inheritance
	psuedo -> pseudo
	succeded -> succeeded
	...

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Handle parentheses in spellcheck.sh
	Currently, text adjacent to parentheses is not spell-checked:
	...
	$ cat tmp.txt
	(upto)
	$ ./gdb/contrib/spellcheck.sh tmp.txt
	$
	...

	Add handling of parentheses, such that we get:
	...
	$ ./gdb/contrib/spellcheck.sh tmp.txt
	upto -> up to
	$
	...

	Rerun spellcheck.sh, resulting in a few "thru->through" replacements.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[precommit] Add some documentation in .pre-commit-config.yaml
	Add some documention to .pre-commit-config.yaml that explains:
	- what the file is,
	- how it can be used, and
	- how to skip specific hooks in case of trouble.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix recording of T1 push
	When running test-case gdb.reverse/recursion.exp on arm-linux with target
	board unix/-mthumb, I run into:
	...
	(gdb) PASS: gdb.reverse/recursion.exp: Skipping recursion from inside
	reverse-next^M
	bar (x=4195569) at /home/linux/gdb/src/gdb/testsuite/gdb.reverse/recursion.c:34^M
	34        int r = foo (x);^M
	(gdb) FAIL: gdb.reverse/recursion.exp: print frame when stepping out
	...

	The problem is the recording of the T1 push instruction [1,2], specifically:
	...
	000004d8 <foo>:
	 4d8:   b580            push    {r7, lr}
	...

	The current code fails to add a memory record for the memory written with the
	value of the lr register.

	Fix this by adding the missing memory record.

	Tested on arm-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

	[1] https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Instruction-Details/Encoding-of-lists-of-ARM-core-registers
	[2] https://developer.arm.com/documentation/ddi0597/2024-09/T32-Instructions-by-Encoding/16-bit?lang=en#pushpop16

2024-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Handle sycall statx for arm-linux
	When running test-case gdb.reverse/fstatat-reverse.exp on arm-linux, I run
	into:
	...
	(gdb) continue^M
	Continuing.^M
	Process record and replay target doesn't support syscall number 397^M
	Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M
	Process record: failed to record execution log.^M
	^M
	Program stopped.^M
	0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
	(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
	...

	Syscall number 397 stands for statx on arm-linux.

	Fix this by handling 397 in arm_canonicalize_syscall.

	Tested on arm-linux.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-11-13  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	gdb: stepping between inline functions with multiple ranges
	I (Andrew) have split this small change from a larger patch which was
	posted here:

	  https://inbox.sourceware.org/gdb-patches/AS1PR01MB9465608EBD5D62642C51C428E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com

	And I have written the stand alone test for this issue.  The original
	patch included this paragraph to explain this change (I've fixed one
	typo in this text replacing 'program' with 'function'):

	  ... it may happen that the infrun machinery steps from one inline
	  range to another inline range of the same inline function.  That can
	  look like jumping back and forth from the calling function to the
	  inline function, while really the inline function just jumps from a
	  hot to a cold section of the code, i.e. error handling.

	The important thing that happens here is that both the outer function
	and the inline function must both have multiple ranges.  When the
	inferior is within the inline function and moves from one range to
	another it is critical that the address we stop at is the start of a
	range in both the outer function and the inline function.

	The diagram below represents how the functions are split and aligned:

	                           (A)       (B)
	  bar:         |------------|         |---|
	  foo:   |------------------|         |--------|

	The inferior is stepping through 'bar' and eventually reaches
	point (A) at which point control passes to point (B).

	Currently, when the inferior stops, GDB notices that both 'foo' and
	'bar' start at address (B), and so GDB uses the inline frame mechanism
	to skip 'bar' and tells the user that the inferior is in 'foo'.

	However, as we were in 'bar' before the step then it makes sense that
	we should be in 'bar' after the step, and this is what the patch does.

	There are two tests using the DWARF assembler, the first checks the
	above situation and ensures that GDB reports 'bar' after the step.

	The second test is similar, but after the step we enter a new range
	where a different inline function starts, something like this:

	                           (A)       (B)
	  bar:         |------------|
	  baz:                                |---|
	  foo:   |------------------|         |--------|

	In this case as we step at (A) and land at (B) we leave 'bar' and
	expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as
	that is a completely different inline function.  And this is, indeed,
	what we see.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

2024-11-13  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix handling of DW_AT_entry_pc of inlined subroutines
	The entry PC for a DIE, e.g. an inline function, might not be the base
	address of the DIE.  Currently though, in block::entry_pc(), GDB
	always returns the base address (low-pc or the first address of the
	first range) as the entry PC.

	This commit extends the block class to carry the entry PC as a
	separate member variable.  Then the DWARF reader is extended to read
	and set the entry PC for the block.  Now in block::entry_pc(), if the
	entry PC has been set, this is the value returned.

	If the entry-pc has not been set to a specific value then the old
	behaviour of block::entry_pc() remains, GDB will use the block's base
	address.  Not every DIE will set the entry-pc, but GDB still needs to
	have an entry-pc for every block, so the existing logic supplies the
	entry-pc for any block where the entry-pc was not set.

	The DWARF-5 spec for reading the entry PC is a super-set of the spec
	as found in DWARF-4.  For example, if there is no DW_AT_entry_pc then
	DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
	address, which is DW_AT_low_pc or the first address in the first range
	specified by DW_AT_ranges if there is no DW_AT_low_pc.

	I have taken the approach of just implementing the DWARF-5 spec for
	everyone.  There doesn't seem to be any benefit to deliberately
	ignoring a ranges based entry PC value for DWARF-4.  If some naughty
	compiler has emitted that, then lets use it.

	Similarly, DWARF-4 says that DW_AT_entry_pc is an address.  DWARF-5
	allows an address or a constant, where the constant is an offset from
	the base address.  I allow both approaches for all DWARF versions.
	There doesn't seem to be any downsides to this approach.

	I ran into an issue when testing this patch where GCC would have the
	DW_AT_entry_pc point to an empty range.  When GDB parses the ranges
	any empty ranges are ignored.  As a consequence, the entry-pc appears
	to be outside the address range of a block.

	The empty range problem is certainly something that we can, and should
	address, but that is not the focus of this patch, so for now I'm
	ignoring that problem.  What I have done is added a check: if the
	DW_AT_entry_pc is outside the range of a block then the entry-pc is
	ignored, GDB will then fall-back to its default algorithm for
	computing the entry-pc.

	If/when in the future we address the empty range problem, these
	DW_AT_entry_pc attributes will suddenly become valid and GDB will
	start using them.  Until then, GDB continues to operate as it always
	has.

	An early version of this patch stored the entry-pc within the block
	like this:

	  std::optional<CORE_ADDR> m_entry_pc;

	However, a concern was raised that this, on a 64-bit host, effectively
	increases the size of block by 16-bytes (8-bytes for the CORE_ADDR,
	and 8-bytes for the std::optional's bool plus padding).

	If we remove the std::optional part and just use a CORE_ADDR then we
	need to have a "special" address to indicate if m_entry_pc is in use
	or not.  I don't really like using special addresses; different
	targets can access different address ranges, even zero is a valid
	address on some targets.

	However, Bernd Edlinger suggested storing the entry-pc as an offset,
	and I think that will resolve my concerns.  So, we store the entry-pc
	as a signed offset from the block's base address (the first address of
	the first range, or the start() address value if there are now
	ranges).  Remember, ranges can be out of order, in which case the
	first address of the first range might be greater than the entry-pc.

	When GDB needs to read the entry-pc we can add the offset onto the
	blocks base address to recalculate it.

	With this done, on a 64-bit host, block only needs to increase by
	8-bytes.

	The inline-entry.exp test was originally contributed by Bernd here:

	  https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com

	though I have made some edits, making more use of lib/gdb.exp
	functions, making the gdb_test output patterns a little tighter, and
	updating the test to run with Clang.  I also moved the test to
	gdb.opt/ as that seemed like a better home for it.

	Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>

2024-11-13  Mark Harmstone  <mark@harmstone.com>

	gas: add .cv_ucomp and .cv_scomp pseudo-directives
	Add .cv_ucomp and .cv_scomp pseudo-directives for object files for
	Windows targets, which encode compressed CodeView integers according to
	the algorithm in CVCompressData in
	https://github.com/Microsoft/microsoft-pdb/blob/master/include/cvinfo.h.
	This is essentially Microsoft's answer to the LEB128, though used in far
	fewer places.

	CodeView uses these to encode the "binary annotations" in the
	S_INLINESITE symbol, which express the relationship between code offsets
	and line numbers in inlined functions. This has to be done in the
	assembler as GCC doesn't know how many bytes each instruction takes up.
	There's no equivalent for this for MSVC or LLVM, as in both cases the
	assembler and compiler are integrated.

	.cv_ucomp represents an unsigned big-endian integer between 0 and 0x1fffffff,
	taking up 1, 2, or 4 bytes:

	Value between 0 and 0x7f:

		0aaaaaaa -> 0aaaaaaa (identity-mapped)

	Value between 0x80 and 0x3fff:

		00aaaaaa bbbbbbbb -> 10aaaaaa bbbbbbbb

	Value between 0x4000 and 0x1fffffff:
		000aaaaa bbbbbbbb ccccccccc dddddddd ->
		110aaaaa bbbbbbbb ccccccccc dddddddd

	.cv_scomp represents a signed big-endian integer between -0xfffffff and
	0xfffffff, encoded according to EncodeSignedInt32 in cvinfo.h. The
	absolute value of the integer is shifted left one bit, the LSB set
	for a negative value, and the result expressed as if it were a
	.cv_ucomp: cv_scomp(x) = cv_ucomp((abs(x) << 1) | (x < 0 ? 1 : 0))

2024-11-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-12  Mark Wielaard  <mark@klomp.org>

	bfd: Add WARN_CFLAGS_FOR_BUILD to doc/chew.c build, fix warnings
	doc/chew.c was compiled without any warning flags set. Adding the
	common warnings for build showed various issues with non-static
	functions missing prototypes and globals with common names (ptr and
	idx) that shadowed local arguments or variables.

	     * doc/local.mk (doc/chew.stamp): Add WARN_CFLAGS_FOR_BUILD.
	     * Makefile.in: Regenerate.
	     * doc/chew.c (idx): Rename to pos_idx.
	     (ptr): Rename to buf_ptr.
	     (xmalloc): Make static.
	     (xrealloc): Likewise.
	     (xstrdup): Likewise.
	     (nextword): Likewise.
	     (newentry): Likewise.
	     (add_to_definition): Likewise.
	     (add_intrinsic): Likewise.
	     (compile): Likewise.
	     (icopy_past_newline): Rename idx to pos_idx, ptr to buf_ptr.
	     (get_stuff_in_command): Likewise.
	     (skip_past_newline): Likewise.
	     (perform): Likewise.
	     (main): Likewise.

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: some cleanups in gdb.base/annota{1,3}.exp tests
	Fedora GDB has, for years, carried an out of tree patch for the
	gdb.base/annota{1,3}.exp tests.  The patch simply adds a call to 'set
	breakpoint pending off' near the start of each test.

	Normally GDB tests are written using gdb_test or gdb_test_multiple,
	with gdb_test being a wrapper around gdb_test_multiple.  Inside
	gdb_test_multiple we add a test pattern which detects if GDB offers
	the user an interactive yes/no prompt and immediately fails the test.

	What this means is that if something goes wrong with a test like:

	  gdb_test "break main" ".*"

	and GDB ends up offering this prompt:

	  Make breakpoint pending on future shared library load? (y or [n])

	then instead of hanging waiting for the test to timeout, DejaGNU will
	spot the interactive prompt and immediately fail the test.

	In the gdb.base/annota{1,3}.exp tests we turn on GDB's annotation
	mode, and many of the tests in these scripts are written using
	send_gdb and gdb_expect or gdb_expect_list.  This is done because in
	the past, gdb_test_multiple and friends were hard-coded to use the
	"normal" GDB prompt, and these tests instead expect the annotated
	prompt.  Specifically, gdb_test_multiple expects '$gdb_prompt $' as
	the full prompt, that is the value of $gdb_prompt followed by a single
	white space.  The annotation tests do update the value of $gdb_prompt,
	but with annotations on there is no trailing whitespace, so
	gdb_test_multiple's default behaviour doesn't work, which is why the
	test scripts originally avoided using gdb_test_multiple.

	As a result none of the tests in these files would early exit if we
	got an interactive yes/no prompt, and instead we'd be relying on each
	test to timeout, which could take a while.

	However, gdb_test_multiple now accepts a -prompt argument, so we can
	modify the prompt we are looking for, which is neat.

	So, I started off by going through these tests an changing all of the
	tests that create a breakpoint to use gdb_test, passing the -prompt
	option to change the prompt.

	While doing that I noticed some other things that I could improve in
	these tests, I've cleaned up the use of standard_testfile, switched to
	use prepare_for_testing, and removed some redundant clean_restart and
	'set height 0' calls (set height 0 is done within clean_restart, which
	is called by prepare_for_testing).

	I've updated some comments which said "we can't use gdb_test" to say
	"we can use gdb_test with -prompt option", and I've removed some
	commented out debug code (e.g. setting 'exp_internal').

	Finally, I ran these two tests through check-all-boards, and spotted
	that annota1.exp failed when using a remote host.  This is because one
	test checks for a full path to the binary in some output, and with a
	remote host the binary ends up being copied and the path is not as
	expected.

	I'm assuming that checking the full path is important, so I've
	disabled this test on remote host boards.

	After all these changes I checked using 'make check-all-boards' and
	there are no unexpected results on either of these tests.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Acked-By: Tom de Vries <tdevries@suse.de>

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix duplicate test names in gdb.trace/
	After this commit:

	  commit 35f09cd5d7fdd1a64f4d1751e73c3495bef1ed99
	  Date:   Wed Jul 31 15:04:25 2024 +0200

	      [gdb/testsuite] Detect trailing-text-in-parentheses duplicates

	we are now seeing some duplicate test names in gdb.trace/ tests when
	using native-gdbserver or native-extended-gdbserver boards.  This is
	all due to tests that use some text in trailing parenthesis to make
	the test name unique.

	I've gone through and edited the test names as best I could to make
	them all unique.  Hopefully the updated test names should all make
	sense.

	On my machine I'm no longer seeing any duplicates with either of the
	boards listed above.

	Acked-By: Tom de Vries <tdevries@suse.de>

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/readline: don't get stuck thinking an EOF arrived
	It was brought to my attention[1] that if a user makes use of Ctrl+d
	to quit from a secondary prompt (e.g. the prompt used to enter lines
	for the 'commands' command) then GDB will start displaying some
	unexpected blank lines.  Here's an example:

	  Reading symbols from /tmp/hello.x...
	  (gdb) break main
	  Breakpoint 1 at 0x401198: file hello.c, line 18.
	  (gdb) commands
	  Type commands for breakpoint(s) 1, one per line.
	  End with a line saying just "end".
	  >quit			# <----------- Use Ctrl+d to quit here.
	  (gdb) show architecture
				# <----------- This blank line is unexpected.
	  The target architecture is set to "auto" (currently "i386:x86-64").
	  (gdb)

	I've marked up where I press 'Ctrl+d', and also the unexpected blank
	line.

	This issue will only happen if bracketed-paste-mode is in use.  If
	this has been disabled (e.g. in ~/.inputrc) then this issue will not
	occur.

	The blank line is not just emitted for the 'show architecture'
	command.  The blank line is actually caused by an extra '\n' character
	emitted by readline after it has gathered a complete line of input,
	and so will occur for any command.

	The problem is caused by readline getting "stuck" in a state where it
	thinks that an EOF has just been delivered.  This state is set when
	the 'Ctrl+d' does deliver an EOF, but then this state is never fully
	reset.  As a result, every time readline completes a line, it thinks
	that the line was completed due to an EOF and so adds an extra '\n'
	character.

	Obviously the real fix for this issue is to patch readline, and I do
	have a patch for that[2], however, version 8.2 of readline has been
	released, and contains this issue.  As such, if GDB is linked against
	the system readline, and that system readline is 8.2, then we can
	expect to see this issue.

	There's a pretty simple, and cheap workaround that we can add to GDB
	that will mitigate this issue.

	I propose that we add this workaround to GDB.  If/when the readline
	patch is accepted then I'll back-port this to our local readline copy,
	but retaining the workaround will be harmless, and will make GDB play
	nicer with system readline libraries (version 8.2).

	[1] https://inbox.sourceware.org/gdb-patches/34ef5438-8644-44cd-8537-5068e0e5e434@redhat.com
	[2] https://lists.gnu.org/archive/html/bug-readline/2024-10/msg00014.html

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/readline: add readline library version to 'show configuration'
	When debugging readline issues I'd like an easy way to know (for sure)
	what version of readline GDB is using.  This could also be useful when
	writing readline tests, knowing the precise readline version will
	allow us to know if we expect a test to pass or not.

	Add the readline library version to the output of the 'show
	configuration' command.  Also include a suffix indicating if we are
	using the system readline, or the statically linked in readline.

	The information about static readline vs shared readline can be
	figured out from the configure command output, but having it repeated
	in the readline version line makes it super easy to grok within tests,
	and it's super cheap, so I don't see this as a problem.

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: pass osabi to GDB in more target descriptions
	Problem Description
	-------------------

	On a Windows machine I built gdbserver, configured for the target
	'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
	support for all target (--enable-targets=all).

	On the Windows machine I start gdbserver with a small test binary:

	  $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe

	On the GNU/Linux machine I start GDB without the test binary, and
	connect to gdbserver.

	As I have not given GDB the test binary, my expectation is that GDB
	would connect to gdbserver and then download the file over the remote
	protocol, but instead I was presented with this message:

	  (gdb) target remote 192.168.129.25:54321
	  Remote debugging using 192.168.129.25:54321
	  warning: C:\some\directory\executable.exe: No such file or directory.
	  0x00007ffa3e1e1741 in ?? ()
	  (gdb)

	What I found is that if I told GDB where to find the binary, like
	this:

	  (gdb) file target:C:/some/directory/executable.exe
	  A program is being debugged already.
	  Are you sure you want to change the file? (y or n) y
	  Reading C:/some/directory/executable.exe from remote target...
	  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
	  Reading C:/some/directory/executable.exe from remote target...
	  Reading symbols from target:C:/some/directory/executable.exe...
	  (gdb)

	then GDB would download the executable.

	The Actual Issue
	----------------

	I tracked the problem down to exec_file_find (solib.c).  The remote
	target was passing an absolute Windows filename (beginning with "C:/"
	in this case), but in exec_file_find GDB was failing the
	IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
	relative.

	The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
	the file system kind was "unix", and as the filename didn't start with
	a "/" it assumed the filename was not absolute.

	But I'm connecting to a Windows target and 'target-file-system-kind'
	was set to "auto", so GDB should be figuring out that the target
	file-system is "dos-based".

	Looking in effective_target_file_system_kind (filesystem.c), we find
	that the logic of "auto" is delegated to the current gdbarch.  However
	in windows-tdep.c we see:

	  set_gdbarch_has_dos_based_file_system (gdbarch, 1);

	So if we are using a Windows gdbarch we should have "dos-based"
	filesystems.  What this means is that after connecting to the remote
	target GDB has selected the wrong gdbarch.

	What's happening is that the target description sent back by the
	remote target only includes the x86-64 registers.  There's no
	information about which OS we're on.  As a consequence, GDB picks the
	first x86-64 gdbarch which can handle the provided register set, which
	happens to be a GNU/Linux gdbarch.

	And indeed, there doesn't appear to be anywhere in gdbserver that sets
	the osabi on the target descriptions. Some target descriptions do have
	their osabi set when the description is created, e.g. in:

	  gdb/arch/amd64.c	- Sets GNU/Linux osabi when appropriate.
	  gdb/arch/i386.c	- Likewise.
	  gdb/arch/tic6x.c	- Always set GNU/Linux osabi.

	There are also some cases in gdb/features/*.c where the tdesc is set,
	but these locations are only called from GDB, not from gdbserver.

	This means that many target descriptions are created without an osabi,
	gdbserver does nothing to fix this, and the description is returned to
	GDB without an osabi included.  This leaves GDB having to guess what
	the target osabi is, and in some cases, GDB can get this wrong.

	Proposed Solution
	-----------------

	I propose to change init_target_desc so that it requires an gdb_osabi
	to be passed in, this will then be used to set the target_desc osabi
	field.

	I believe that within gdbserver init_target_desc is called for every
	target_desc, so this should mean that every target_desc has an
	opportunity to set the osabi to something sane.

	I did consider passing the osabi into the code which creates the
	target_desc objects, but that would require updating far more code, as
	each target has its own code for creating target descriptions.
	The approach taken here requires minimal changes and forces every
	user of init_target_desc to think about what the correct osabi is.

	In some cases, e.g. amd64, where the osabi is already set when the
	target_desc is created, the init_target_desc call will override the
	current value, however, we should always be replacing it with the same
	actual value.  i.e. if the target_desc is created with the osabi set
	to GNU/Linux, then this should only happen when gdbserver is built for
	GNU/Linux, in which case the init_target_desc should also be setting
	the osabi to GNU/Linux.

	The Tricky Bits
	---------------

	Some targets, like amd64, use a features based approach for creating
	target_desc objects, there's a function in arch/amd64.c which creates
	a target_desc, adds features too it, and returns the new target_desc.
	This target_desc is then passed to an init_target_desc call within
	gdbserver.  This is the easy case to handle.

	Then there are other targets which instead have a fixed set of xml
	files, each of which is converted into a .dat file, which is then used
	to generate a .cc file, which is compiled into gdbserver.  The
	generated .cc file creates the target_desc object and calls
	init_target_desc on it.  In this case though the target description
	that is sent to GDB isn't generated from the target_desc object, but
	is instead the contents of the fixed xml file.  For this case the
	osabi which we pass to init_target_desc should match the osabi that
	exists in the fixed xml file.

	Luckily, in the previous commit I copied the osabi information from
	the fixed xml files into the .dat files.  So in this commit I have
	extended regdat.sh to read the osabi from the .dat file and use it in
	the generated init_target_desc call.

	The problem with some of these .dat base targets is that their fixed
	xml files don't currently contain any osabi information, and the file
	names don't indicate that they are Linux only (despite them currently
	only being used from gdbserver for Linux targets), so I don't
	currently feel confident adding any osabi information to these files.
	An example would be features/rs6000/powerpc-64.xml.  For now I've just
	ignored these cases.  The init_target_desc will use GDB_OSABI_UNKNOWN
	which is the default.  This means that for these targets nothing
	changes from the current behaviour.  But many other targets do now
	pass the osabi back.  Targets that do pass the osabi back are
	improved with this commit.

	Conclusion
	----------

	Now when I connect to the Windows remote the target description
	returned includes the osabi name.  With this extra information GDB
	selects the correct gdbarch object, which means that GDB understands
	the target has a "dos-based" file-system.  With that correct GDB
	understands that the filename it was given is absolute, and so fetches
	the file from the remote as we'd like.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/regformats: add osabi information to generated .dat files
	Some gdbserver targets generate their target description based on the
	gdb/regformats/*.dat files.  These .dat files are generated from a
	matching xml file in gdb/features/.

	Lets consider a concrete example:

	Take gdb/features/or1k-linux.xml, this file is processed by
	gdb/features/Makefile to create gdb/regformats/or1k-linux.dat.

	When gdbserver is built for the or1k target the file
	or1k-linux-generated.cc is generated using the
	gdb/regformats/regdat.sh script.  This .cc file is then compiled and
	linked into gdbserver.

	The or1k-linux-generated.cc file contains the function
	init_registers_or1k_linux which is called from within gdbserver, this
	function creates a target_desc object and sets its xmltarget field to
	a fixed string.  This fixed string is the xml filename that was
	originally used to generate the xml file, in this case or1k-linux.xml.

	Additionally, as part of the gdbserver build the file or1k-linux.xml
	is converted to a string and placed in the file
	xml-builtin-generated.cc which is then built into gdbserver.

	Now when GDB asks gdbserver for the target description, gdbserver
	returns the fixed xmltarget string, which is the name of an xml file.
	GDB will then ask gdbserver for that file and gdbserver will return
	the contents of that file thanks to the xml-builtin-generated.cc
	file's contents.

	This is all rather complicated, but it does work.  So what's the
	problem that I'm fixing?

	Well or1k-linux.xml does contain the osabi information, so this will
	be returned from gdbserver to GDB.  That's good.

	However, the target_desc object created in init_registers_or1k_linux
	will not have its osabi set correctly.

	Now this doesn't really matter too much except
	init_registers_or1k_linux includes a call to init_target_desc.

	In the next commit I want to extend init_target_desc to require an
	osabi to be passed in.  The motivation for this will be explained in
	the next commit, but if we accept for a moment that this is something
	that should be done, then the question is what osabi should we use in
	init_registers_or1k_linux?

	Ideally we'd use the osabi which is set in or1k-linux.xml.  If we do
	that then everything will remain consistent, which is a good thing.

	And so, to get the osabi from or1k-linux.xml into
	init_registers_or1k_linux, we first need to get the osabi information
	into or1k-linux.dat file, and this is what this commit does.

	I've added a new xsl script print-osabi.xsl and updated
	gdb/features/Makefile to make use of this script.  Then I regenerated
	all of the .dat files.  Now every .dat file contains either:

	  osabi:GNU/Linux
	  osabi:unknown

	The first is for xml files containing <osabi>GNU/Linux</osabi> and the
	second is for xml files that don't contain an osabi element.

	This commit doesn't attempt to make use of the osabi information in
	the .dat files, that will come in the next commit.  There should be no
	user visible changes after this commit.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

2024-11-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/features: set osabi in all Linux related features/*.xml files
	Some of the top level (i.e. those that contain the <target> element)
	xml files in gdb/features/ are clearly Linux only.  I conclude this
	based on the files names containing the string "linux".

	I think that all of these files should have the <osabi> element
	included with the value "GNU/Linux".

	This commits adds the <osabi> element where I believe it is
	appropriate and regenerates the associated .c files.

	The benefit of this change is that gdbserver, which makes use of these
	files, will now send the osabi back in more cases.  Sending back more
	descriptive target descriptions is a good thing as this makes it
	easier for GDB to select the correct gdbarch.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

2024-11-12  Shahab Vahedi  <shahab.vahedi@amd.com>

	gdb/MAINTAINERS: Update my email address

2024-11-12  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: fix gdb.reverse/i386-avx-reverse.exp with clang
	The test gdb.reverse/i386-avx-reverse.exp was changed by the recent
	commit:

	    commit 5bf288d5a88ab6d3fa9bd7bd070e624afd264dc6
	    Author: Guinevere Larsen <guinevere@redhat.com>
	    Date:   Fri Jul 26 17:31:14 2024 -0300

	    gdb/record: support AVX instructions VMOVDQ(U|A) when recording

	In that commit I added a few calls to the instruction vmovdqa to and
	from memory addresses. Because my local gcc testing always had aligned
	pointers, I thought this would always work, but clang (and maybe other
	compilers) might not do the same, which will cause vmovdqa to segfault,
	and the test to fail spectacularly.

	This commit fixes that by using the pre-existing precise-aligned-alloc
	to allocate the dynamic buffers, forcing them to be aligned to the
	required boundary for vmovdqa instruction to work. The code was then
	re-shuffled to keep the current clustering of instructions.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_part_zeroed for AArch64
	In gdb/aarch64-linux-tdep.c we find:
	...
	      gdb::byte_vector za_zeroed (za_bytes, 0);
	      regcache->raw_supply (tdep->sme_za_regnum, za_zeroed);
	...

	We can't use reg_buffer::raw_supply_zeroed here because only part of the
	register is written.

	Add raw_supply_part_zeroed, and use it instead.

	Likewise elsewhere in AArch64 tdep code.

	Tested on aarch64-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-11-12  Alan Modra  <amodra@gmail.com>

	Remove redundant section merge hash table field
	sec_merge_hash.size duplicates sec_merge_hash.table.count, albeit using
	bfd_size_type rather than unsigned int.  The only reason to have the
	duplicate field is to catch unsigned int overflows, and that can be
	done easily enough when and if required.  Overflow isn't possible at
	the moment.  See the needs_resize comment.

		* merge.c (sec_merge_hash): Remove "size" field.
		(NEEDS_RESIZE): Delete macro, replacing with..
		(needs_resize): ..this inline function.
		(sec_merge_resize): Rename from sec_merge_maybe_resize,
		removing redundant check.
		(sec_merge_hash_insert, sec_merge_hash_lookup): Adjust to suit.
		(sec_merge_init, merge_strings): Likewise.

2024-11-12  Alan Modra  <amodra@gmail.com>

	Re: ld: Move note sections after .rodata section
	Fix csky-linux-gnu FAIL of ld-elf/pr32341, due to that target having
	its own .bss directive.

		PR ld/32341
		* testsuite/ld-elf/pr32341.s: Don't use .bss directive.  Specify
		progbits/nobits on all .section directives.

2024-11-12  Alan Modra  <amodra@gmail.com>

	Re: tekhex object file output fixes
	Commit 8b5a212495 supported *ABS* symbols by allowing "section" to be
	bfd_abs_section, but bfd_abs_section needs to be treated specially.
	In particular, bfd_get_next_section_by_name (.., bfd_abs_section_ptr)
	is invalid.

		PR 32347
		* tekhex.c (first_phase): Guard against modification of
		_bfd_std_section[] entries.

2024-11-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-11  Shahab Vahedi  <shahab.vahedi@amd.com>

	Handle type-casting in template parameter list when hashing symbols
	Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB
	may not be able to find a symbol when asked by the user.  See the
	accompanying test for such demonstration.

	The cp_search_name_hash() cannot correctly handle a (demangled) symbol
	that comprises of type-casting for the first parameter in its template
	parameter list, e.g.:

	  foo<(enum_test)0>(int, int)

	In this example, the processing logic in cp_search_name_hash() considers
	the "foo<" string for hashing instead of "foo".  This is due to a faulty
	logic in the processing loop that tries to _keep_ hashing if a '<' char
	with the following property is encountered:

	---------------------------------------------------------------------
	for (const char *string = search_name; *string != '\0'; ++string)
	  {
	    ...

	    if (*string == '(')
	      break;

	    ...

	    /* Ignore template parameter list.  */
	    if (string[0] == '<'
	        && string[1] != '(' && string[1] != '<' && string[1] != '='
	        && string[1] != ' ' && string[1] = '\0')
	      break;

	    ...
	    hash = SYMBOL_HASH_NEXT (hash, *string);
	  }
	---------------------------------------------------------------------

	Ostensibly, this logic strives to bail out of the processing loop as
	soon as the beginning of an argument list is encountered, "(int, int)"
	in the example, or the beginning of a template parameter list, the
	"<(enum_test)0>" in the example.  However, when "string" is pointing
	at '<', the following incorrect logic takes precedence:

	---------------------------------------------------------------------
	for (const char *string = search_name; *string != '\0'; ++string)
	  {
	    if (*string == '(')
	      break;
	    ...
	    if (string[0] == '<' && string[1] != '(' ...)
	      break;

	    hash = SYMBOL_HASH_NEXT (hash, *string);
	  }
	---------------------------------------------------------------------

	In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after
	the '<' char causes the "if" condition at the end of the loop not to
	"break".  As a result, the '<' is considered for hashing and at the
	beginning of the next iteration, the loop is exited because "string"
	points to '(' char.

	It's obvious that the intention of the "if" condition at the end of the
	loop body is to handle cases where the method name is "operator<",
	"operator<<", or "operator<=".  While fixing the issue, I've re-written
	the logic as such to make that more explicit.  Still, the complexity of
	the function remains O(n).  It is worth mentioning that in the same
	file the "find_toplevel_char()" follows the same explicit logic.

	Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
	Reviewed-By: Pedro Alves <pedro@palves.net>
	Approved-by: Tom Tromey <tom@tromey.com>
	Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e

2024-11-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/progspace: make program_space::objfiles_list private
	This field is only accessed within the program_space class, make it
	private.

	Change-Id: I0b53d78d3d11adf0dfadfb3ecace33d2996dd87b

2024-11-11  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/progspace: link objfiles using owning_intrusive_list
	This simplifies things a little bit, removing some `find_if` when
	inserting or removing objfiles, and the whole
	unwrapping_objfile_iterator thing.

	Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba

2024-11-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix using Page-Up in TUI source window close to the top
	Currently, when you're already less than a page from the top in the TUI
	source window, and you press Page-Up, nothing happens, while I would
	expect that it then scrolls the source up to the first line.

	It's happening because scrolling a full page up would result in a
	negative starting line number, which is then checked if it's higher than
	the (unsigned) number of available lines, and since this will always be
	true, the original starting line number is restored.
	Afterwards it would check if the line number is too low, but since the
	negative value was already gone, it didn't do much.

	Fixed by moving the low line number check before the maximum line number
	check.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix typo 'unsupport' to 'unsupported'
	I noticed that in commit:

	  commit 5cabc8098e65ac22d4245232ad20b19fa4729802
	  Date:   Wed Jul 31 15:55:57 2024 +0100

	      gdb/python: implement Python find_exec_by_build_id hook

	I managed to typo 'unsupported' as 'unsupport'.  If you run the test
	on a target that doesn't support core file creation then you'll get a
	TCL error.

	Fixed in this commit.

2024-11-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix failure in gdb.base/info_sources.exp
	I ran into an unexpected failure in gdb.base/info_sources.exp.  The
	test in question runs this command:

	  (gdb) info sources -d -- -d

	That is, list all the source files whose directory name matches the
	regexp '-d'.  The expectation is that no source files will be listed.

	Unfortunately, when I ran the test some source files are listed; the
	directory I am running in contains the pattern '-d', and so the test
	fails.

	As we cannot control where the developer is building and testing GDB,
	I propose that instead of just testing with '-d' we should search
	through all the letters a-z and find one that isn't present in the
	source file directory name.  I'm still including the leading '-'
	character in the regexp.

	So now, unless GDB is being built in a directory that contains '-a',
	'-b', '-c', .... '-z', the test will find one letter which isn't
	present, and use that for the test.

	To avoid test names changing between runs in different directories
	I've had to tweak the test name to something more generic, but there
	should be no change in which parts of GDB are actually being tested.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Reduce quoting in gdb.base/annota1.exp
	Reduce quoting in gdb.base/annota1.exp, mostly using string_to_regexp.

	Tested on arm-linux and x86_64-linux.

2024-11-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/annota1.exp on arm-linux
	On arm-linux, gdb.base/annota1.exp fails:
	...
	PASS: gdb.base/annota1.exp: breakpoint info
	run^M
	^M
	^Z^Zpost-prompt^M
	Starting program: /home/linux/gdb/build/gdb/testsuite/outputs/gdb.base/annota1/annota1 ^M
	^M
	^Z^Zbreakpoints-invalid^M
	^M
	^Z^Zframes-invalid^M
	^M
	^Z^Zstarting^M
	^M
	^Z^Zframes-invalid^M
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".^M
	^M
	^Z^Zbreakpoints-invalid^M
	^M
	^Z^Zbreakpoint 1^M
	^M
	Breakpoint 1, ^M
	^Z^Zframe-begin 0 0x40054a^M
	^M
	^Z^Zframe-function-name^M
	main^M
	^Z^Zframe-args^M
	 ()^M
	^Z^Zframe-source-begin^M
	 at ^M
	^Z^Zframe-source-file^M
	/home/linux/gdb/src/gdb/testsuite/gdb.base/annota1.c^M
	^Z^Zframe-source-file-end^M
	:^M
	^Z^Zframe-source-line^M
	15^M
	^Z^Zframe-source-end^M
	^M
	^M
	^Z^Zsource /home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x40054a^M
	^M
	^Z^Zframe-end^M
	^M
	^Z^Zstopped^M
	^M
	^Z^Zpre-prompt^M
	(gdb) ^M
	^Z^Zprompt^M
	FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
	...
	because the regexp doesn't match the first frames-invalid annotation.

	Fix this by adding an optional frames-invalid annotation in the regexp.

	Tested on arm-linux and x86_64-linux.

2024-11-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Avoid intermittent failures on another debuginfod test
	With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran
	into:
	...
	(gdb) core-file solib-with-soname.core^M
	Downloading 197.86 K file libfoo_1.so...^M
	[New LWP 997314]^M
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	Core was generated by `solib-with-soname'.^M
	Program terminated with signal SIGABRT, Aborted.^M
	(gdb) FAIL: $exp: load core file, use debuginfod: load core file
	...

	The test-case doesn't expect the "197.86 K" part.

	The same problem was fixed for another test-case in commit a723c56efb0
	("gdb/testsuite: avoid intermittent failures on a debuginfod test").

	Fix this in the same way: by updating the regexp.

	Tested on aarch64-linux.

	PR testsuite/32354
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Use an iterator range for 'using' directives
	This patch changes block::get_using to return an iterator range.  This
	seemed cleaner to me than the current approach of returning a pointer
	to the first using directive; all the callers actually use this to
	iterate.

	Ensure that help text fits in 80 columns
	This patch adds a new unit test that ensures that all help text wraps
	at 80 columns.

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Wrap help options when building help string
	When building a help string, it's possible that the resulting options
	will go over 80 columns.  This patch changes this code to add line
	wrapping where needed.

	This can most be seen by looking "help bt" and in particular the
	"-frame-info" help text.

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Shorten internal problem help text
	The help text for various "internal problem" settings is longer than
	80 columns.  This patch tightens this up a bit.  Note that these
	commands are all "maint" commands so, IMO, it is sufficient if they
	are clear to a gdb developer.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Remove the "title" from the remote packet help
	The help for remote packet controls includes the "title".  However
	this is is just the parameter name, and not really useful to see
	repeated in the help text.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Clean up opaque-type-resolution help
	The opaque-type-resolution help says "if set before loading symbols",
	but I don't think this is accurate.  As far as I know, this resolution
	can be done at any time.

	This patch cleans up the help, also shortening it to less than 80
	characters.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Wrap help strings at 80 columns
	This patch ensures that all ordinary help strings are wrapped at 80
	columns.  For the most part this consists of changing code like this
	(note the embedded \n and the trailing backslash without a newline):

	-Manage the space-separated list of debuginfod server URLs that GDB will query \
	-when missing debuginfo, executables or source files.\nThe default value is \
	-copied from the DEBUGINFOD_URLS environment variable."),

	... to end each line with \n\, like:

	+Manage the space-separated list of debuginfod server URLs that GDB will\n\
	+query when missing debuginfo, executables or source files.\n\
	+The default value is copied from the DEBUGINFOD_URLS environment variable."),

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Call gdbpy_fix_doc_string_indentation for function help
	If you invoke "help function _caller_is", you'll see that the help
	text is indented strangely.  The fix for this is to add a call to
	gdbpy_fix_doc_string_indentation in the appropriate spot, as is
	already done for Python commands and parameters.

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Add setting to control frame language mismatch warning
	A customer noted that there is no way to prevent the "current language
	does not match this frame" warning.  This patch adds a new setting to
	allow this warning to be suppressed.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-11-11  Tom Tromey  <tromey@adacore.com>

	Re-run isort
	pre-commit pointed out that one file needed a change to satisfy isort.
	This patch is the result.

2024-11-11  Pedro Silva  <pedromsilva.git@gmail.com>

	gdb: fix missing operator % on xmethod matcher output
	Fixed missing operator % on xmethod matcher registration output and, as
	suggested on bug 32532, converted both uses of operator % to str.format.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32352
	Change-Id: Ic471516292c2f1d6d1284aaeaea3ec14421decb8

2024-11-11  H.J. Lu  <hjl.tools@gmail.com>

	ld: Move note sections after .rodata section
	Move note sections after .rodata section so that note sections are
	placed in the same PT_LOAD segment together with .rodata section,
	instead of a separate PT_LOAD segment.

		PR ld/32341
		* scripttempl/misc-sections.sc: Move note sections to ...
		* scripttempl/elf.sc: Here, after .rodata section.
		* testsuite/ld-elf/pr32341.d: New file.
		* testsuite/ld-elf/pr32341.s: Likewise.

	Co-Authored-By: Nick Clifton <nickc@redhat.com>

2024-11-11  Lancelot SIX  <lancelot.six@amd.com>

	gdb/dwarf2/read.c: Handle empty CU name
	I recently came across a case where a compiler would emit a CU with an
	empty name.  In such case, the attribute object constructed by GDB will
	return nullptr when as_string is called.  One place is not checking for
	this possibility.  As a result, loading such binary results in a GDB
	crash:

	    $ gdb -q a.out
	    Reading symbols from a.out...

	    Fatal signal: Segmentation fault
	    ----- Backtrace -----
	    [...]
	    0x742f4dd8afab __strcmp_avx2
	            ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
	    0x58593704a0bc prepare_one_comp_unit
	            ../../gdb/dwarf2/read.c:21842
	    0x585937053fd9 process_psymtab_comp_unit
	            ../../gdb/dwarf2/read.c:4633
	    0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
	            ../../gdb/dwarf2/read.c:4943
	    [...]
	    ---------------------
	    A fatal error internal to GDB has been detected, further
	    debugging is not possible.  GDB will now terminate.

	    This is a bug, please report it.  For instructions, see:
	    <https://www.gnu.org/software/gdb/bugs/>.

	    Segmentation fault (core dumped)

	This seems to be a regression introduced by the following commit:

	    commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36
	    Date:   Tue Sep 24 10:24:22 2024 +0200

	        [gdb/symtab] Don't expand non-Ada CUs for info exceptions

	This patch fixes this issue by checking if attr->as_string returns
	nullptr.

	Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c
	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-11  Xin Wang  <wangxin03@loongson.cn>

	ld, LoongArch: print error about linking without -fPIC or -fPIE flag in more detail

2024-11-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: implement Python find_exec_by_build_id hook
	Implement extension_language_ops::find_objfile_from_buildid within
	GDB's Python API.  Doing this allows users to write Python extensions
	that can help locate missing objfiles when GDB opens a core file.  A
	handler might perform some project- or site-specific actions to find a
	missing objfile.  Or might provide some project- or site-specific
	advice to the user on how they can obtain the missing objfile.

	The implementation is very similar to the approach taken in:

	  commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
	  Date:   Sun Oct 15 22:48:42 2023 +0100

	      gdb: implement missing debug handler hook for Python

	The following new commands are added as commands implemented in
	Python, this is similar to how the Python missing debug and unwinder
	commands are implemented:

	  info missing-objfile-handlers
	  enable missing-objfile-handler LOCUS HANDLER
	  disable missing-objfile-handler LOCUS HANDLER

	To make use of this extension hook a user will create missing objfile
	handler objects, and registers these handlers with GDB.  When GDB
	opens a core file and encounters a missing objfile each handler is
	called in turn until one is able to help.  Here is a minimal handler
	that does nothing useful:

	  import gdb
	  import gdb.missing_objfile

	  class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
	      def __init__(self):
	          super().__init__("my_first_handler")

	      def __call__(self, pspace, build_id, filename):
	          # This handler does nothing useful.
	          return None

	  gdb.missing_objfile.register_handler(None, MyFirstHandler())

	Returning None from the __call__ method tells GDB that this handler
	was unable to find the missing objfile, and GDB should ask any other
	registered handlers.

	Possible return values from a handler:

	  - None: This means the handler couldn't help.  GDB will call other
	          registered handlers to see if they can help instead.

	  - False: The handler has done all it can, but the objfile couldn't
	            be found.  GDB will not call any other handlers, and will
		    continue without the objfile.

	  - True: The handler has installed the objfile into a location where
	          GDB would normally expect to find it.  GDB should repeat its
		  normal lookup process and the objfile should now be found.

	  - A string: The handler can return a filename, which is the missing
	              objfile.  GDB will load this file.

	Handlers can be registered globally, or per program space.  GDB checks
	the handlers for the current program space first, and then all of the
	global handles.  The first handler that returns a value that is not
	None, has "handled" the missing objfile, at which point GDB continues.

	The implementation of this feature is mostly straight forward.  I have
	reworked some of the missing debug file related code so that it can be
	shared with this feature.  E.g. gdb/python/lib/gdb/missing_files.py is
	mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
	updated to be more generic.  Now gdb/python/lib/gdb/missing_debug.py
	and the new file gdb/python/lib/gdb/missing_objfile.py both call into
	the missing_files.py file.

	For gdb/python/lib/gdb/command/missing_files.py this is even more
	extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
	gone now and gdb/python/lib/gdb/command/missing_files.py provides all
	of the new commands in a generic way.

	I have made one change to the existing Python API, I renamed the
	attribute Progspace.missing_debug_handlers to
	Progspace.missing_file_handlers.  I don't see this as too
	problematic.  This attribute was only used to implement the missing
	debug feature and was never documented beyond the fact that it
	existed.  There was no reason for users to be touching this attribute.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-11-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: add extension hook ext_lang_find_objfile_from_buildid
	Add a new ext_lang_find_objfile_from_buildid function which is called
	from find_objfile_by_build_id and gives extension languages a chance
	to find missing objfiles.

	This commit adds the ext_lang_find_objfile_from_buildid function and
	the extension_language_ops::find_objfile_from_buildid() hook, but does
	not implement the hook for any extension languages, that will come in
	the next commit.

	This commit does rewrite find_objfile_by_build_id (build-id.c) to call
	the new hook though.  The basic steps of find_objfile_by_build_id are
	now this:

	  1. Try to find the missing objfile using the build-id by looking in
	  the debug-file-directory's .build-id/ sub-directory.  If we find the
	  file then we're done.

	  2. Ask debuginfod to download the missing file for us.  If we
	  download the file successfully then we're done.

	  3. Ask the extension language hook to find the file for us.  If the
	  extension language asks us to try again then we repeat step (1) only
	  and if we still don't have the file, we move to step (4).  If the
	  extension language told us where the file is then we use that file
	  and we're done.

	  4. We didn't find the file.  Carry on without it.

	Only step (3) is new in this logic, everything else was already done.

	There are no tests added here as we can't currently write an extension
	language callback.  The next commit will add the tests.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: rename ext_lang_missing_debuginfo_result
	In preparation for later commits in this series, rename
	ext_lang_missing_debuginfo_result to ext_lang_missing_file_result.

	A later commit will add additional Python APIs to handle different
	types of missing files beyond just debuginfo.

	This is just a rename commit, there should be no functional changes
	after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: use mapped file information to improve debuginfod text
	When opening a core-file GDB is able to use debuginfod to download the
	executable that matches the core-file if GDB can find a build-id for
	the executable in the core-file.

	In this case GDB calls debuginfod_exec_query to download the
	executable and GDB prints a message like:

	  Downloading executable for /path/to/core-file...

	which makes sense in that case.

	For a long time GDB has also had the ability to download memory-mapped
	files and shared libraries when opening a core-file.  However, recent
	commits have made these cases more likely to trigger, which is a good
	thing, but the messaging from GDB in these cases is not ideal.  When
	downloading a memory-mapped file GDB prints:

	  Downloading executable for /path/to/memory-mapped-file

	And for a shared library:

	  Downloading executable for /path/to/libfoo.so

	These last two messages could, I think, be improved.

	I propose making two changes.  First, I suggest instead of using
	/path/to/core-file in the first case, we use the name of the
	executable that GDB is fetching.  This makes the messaging consistent
	in that we print the name of the file we're fetching rather than the
	name of the file we're fetching something for.

	I further propose that we replace 'executable for' with the more
	generic word 'file'.  The messages will then become:

	  Downloading file /path/to/exec-file...
	  Downloading file /path/to/memory-mapped-file...
	  Downloading file /path/to/libfoo.so...

	I think these messages are clearer than what we used to have, and they
	are consistent in that we name the thing being downloaded in all
	cases.

	There is one tiny problem.  The first case relies on GDB knowing the
	name of the executable it wants to download.  The only place we can
	currently get that from is, I think, the memory-mapped file list.

	[ ASIDE: There is `bfd_core_file_failing_command` which reports the
	  executable and argument list from the core file, but this
	  information is not ideal for this task.  First, the executable and
	  arguments are merged into a single string, and second, the string is
	  a relatively short, fixed length string, so the executable name is
	  often truncated.  For these reasons I don't consider fetching the
	  executable name using this bfd function as a solution. ]

	We do have to consider the case that the core file does not have any
	mapped file information.  This shouldn't ever be the case for a Linux
	target, but it's worth considering.

	[ ASIDE: I mention Linux specifically because this only becomes a
	  problem if we try to do a lookup via debuginfod, which requires that
	  we have build-ids available.  Linux has special support for
	  embedding build-ids into the core file, but I'm not sure if other
	  kernels do this. ]

	For the unlikely edge case of a core-file that has build-ids, but
	doesn't have any mapped file information then I propose that we
	synthesis a filename like: 'with build-id xxxxxx'.  We would then see
	a message like:

	  Downloading file with build-id xxxxxx...

	Where 'xxxxxx' would be replaced by the actual build-id.

	This isn't ideal, but I think is good enough, and, as I said, I think
	this case is not going to be hit very often, or maybe at all.

	We already had some tests that emitted two of the above messages,
	which I've updated, these cover the mapped-file and shared library
	case.

	The message about downloading the exec for the core-file is actually
	really hard to trigger now as usually the exec will also appear in the
	memory-mapped file list and GDB will download the file at this stage.
	Then when GDB needs the executable for loading the symbols it'll ask
	debuginfod, and debuginfod will find the file in its cache, and so no
	message will be printed.

	If anyone has any ideas about how to trigger this case then I'm happy
	to add additional tests.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-08  Alexandra Hájková  <ahajkova@redhat.com>

	Add dw2-aranges.exp
	This test checks that GDB is able to load DWARF information when
	.debug_aranges has a section address size that is set to 0.

	This test was originally written by Jan Kratochvil to test commit
	927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer".

	This test was originally written using a static .S file and has
	been present in the Fedora tree for a long time.

	If dwarf2/aranges.c is modified to turn off the address_size check,
	GDB will crash with SIGFPE when loading the executable with address
	size set to zero.

	I modified the DWARF assembler to make it possible to set the address
	size to zero in a .debug_aranges section and used the DWARF assembler
	to produce the assembly file.

	Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove pidof(process)
	This function doesn't seem so useful, use `process_info::pid` directly
	instead.

	Change-Id: I55d592f38b32a197957ed4c569993cd23a818cb4
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove pid_of(thread)
	This function doesn't seem so useful, use `thread_info::id::pid`
	directly instead.

	Change-Id: I7450c4223e5b0bf66788eeb5b070ab6f5287f798
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove lwpid_of(thread)
	This function doesn't seem so useful.  Use `thread_info::id::lwp`
	directly.

	Change-Id: Ib4a86eeeee6c1342bc1c092f083589ce28009be1
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove ptid_of(thread)
	This function doesn't seem so useful.  Use `thread_info::id` directly.

	Change-Id: I158cd06a752badd30f68424e329aa42d275e43b7
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove current_thread_ptid
	This function doesn't seem so useful.  Use `thread_info::id` directly.

	Change-Id: I4ae4e7baa44e09704631a1c3a5a66e5b8b5a3594
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove current_ptid macro
	I think it just makes things more obscure.  Use `thread_info::id`
	directly instead.

	Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: remove get_thread_process
	Remove the `get_thread_process` function, use `thread_info::process`
	instead.

	In `server.cc`, use `current_process ()` instead of going through the
	current thread.

	Change-Id: Ifc61d65852e392d154b854a45d45df584ab3922e
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: make remove_thread a method of process_info
	Same idea as the previous patch, but for `remove_thread`.

	Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: make add_thread a method of process_info
	Since thread_info objects are now basically children of process_info
	objects, I think that makes sense.

	Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: add thread -> process backlink
	In a few spots, we need to get to a process from a thread.  Having a
	backlink from thread to process is cheap and makes the operation
	trivial, add it.

	Change-Id: I8a94b2919494b1dcaf954de2246386794308aa82
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove for_each_thread(pid, func)
	Remove this overload, prefer to use `process_info::for_each_thread`.  In
	many instances, the `process_info` is already available, so this saves a
	map lookup.  In other instances, add the `process_info` lookup at the
	call site.

	In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()`
	instead of `current_thread->id.pid ()`.  I presume that if
	`current_process ()` and `current_thread` don't match, it's a bug
	orthogonal to this change.

	Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51
	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

2024-11-08  Schimpe, Christina  <christina.schimpe@intel.com>

	gdb: LoongArch: Remove use of gdbarch_remove_non_address_bits hook
	LoongArch doesn't implement the hook gdbarch_remove_non_address_bits, so
	there is no need to use the hook in gdb/loongarch-linux-nat.c.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-11-08  Guinevere Larsen  <guinevere@redhat.com>

	gdb: make the error message for unreadable objfiles more informative
	When GDB is unable to read an objfile, it prints the error message "I'm
	sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a
	great reference, an end user won't have much information about the
	problem.

	So far this wasn't much of a problem, as it is very uncommon for GDB to
	be unable to read an objfile. However, a future patch will allow users
	to selectively disable support to some formats, making it somewhat
	expected that the message will be seen by end users.

	This commit makes the end message more informative and direct.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add flag OPD_F_UNSIGNED to distinguish signedness of immediate operands
	This patch introduces a new operand flag OPD_F_UNSIGNED to signal that
	the immediate value should be treated as an unsigned value. The default
	signedness of immediate operands is signed.

	aarch64: testsuite: remove hard-coded instruction addresses

	aarch64: remove redundant register type R_N
	The register type R_N is redundant with R_ZR_SP. This patch removes it,
	and replaces its usage by R_ZR_SP.

	aarch64: improve debuggability on array of enum
	The current space optmization on enum aarch64_opn_qualifier forced its
	encoding using an unsigned char. This "hard-coded" optimization has the
	bad consequence of making the array of such enums being completely
	unreadable when debugging with GDB because the enum type is lost along
	the way.
	Keeping this space optimization, and the enum type as well, is possible
	when the declaration of the enum is tagged with attribute((packed)).
	attribute((packed)) is a GNU extension, and is wrapped in the macro
	ATTRIBUTE_PACKED (defined in ansidecl.h), and should be used instead.

	aarch64: change returned type to bool to match semantic of functions

	aarch64: constify unchanged char* arguments

	aarch64: make comment clearer about the location
	The enum aarch64_opnd_qualifiers in include/opcode/aarch64.h needs to
	stay in sync with the array of struct operand_qualifier_data which
	defines various properties for the different type of operands. For
	instance, for:
	- registers: the size of the register, the number of elements.
	- immediates: lower and upper bits to determine the range of values.

2024-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix gdb.base/basic-edit-cmd.exp test
	In the recent commit:

	  commit 31ada87f91b4c5306d81c8a896df9764c32941f3
	  Date:   Wed Nov 6 22:18:55 2024 +0000

	      gdb: fixes and tests for the 'edit' command

	the new gdb.base/basic-edit-cmd.exp was added.  The Linaro CI
	highlighted an issue with the test which I failed to address before
	pushing the above commit.

	Part of the test loads a file into GDB and then uses the 'edit'
	command with no arguments to edit the default location.  This default
	location is expected to be the 'main' function.

	On my local machine the line reported is the opening '{' of main, and
	that is what the test checks for.

	The Linaro CI though appears to see the first code line of main.

	I think either result is fine as far as this test is concerned, so
	I've expanded the test regexp to check for either line number.  This
	should make the CI testing happy again.

2024-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: fixes and tests for the 'edit' command
	This commit was inspired by this mailing list post:

	  https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm

	When reviewing that patch, the first thing I wanted to do was add some
	tests for the 'edit' command because, as far as I can tell, there are
	no real tests right now.

	The approach I've taken for testing is to override the EDITOR
	environment variable, setting this to just 'echo'.  Now when the
	'edit' command is run, instead of entering an interactive editor, the
	shell instead echos back the arguments that GDB is trying to pass to
	the editor.  The output might look like this:

	  (gdb) edit
	  +22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c
	  (gdb)

	We can then test this like any other normal command.  I then wrote
	some basic tests covering a few situations like, using 'edit' before
	the inferior is started.  Using 'edit' without any arguments, and
	using 'edit' with a line number argument.

	There are plenty of cases that are still not tested, for example, the
	test program only has a single source file for example.  But we can
	always add more tests later.

	I then used these tests to validate the fix proposed in the above
	patch.

	The patch above does indeed fix some cases, specifically, when GDB
	stops at a location (e.g. a breakpoint location) and then the 'edit'
	command without any arguments is fixed.  But using the 'list' command
	to show some other location, and then 'edit' to edit the just listed
	location broken before and after the above patch.

	I am instead proposing this alternative patch which I think fixes more
	cases.  When GDB stops at a location then 'edit' with no arguments
	should correctly edit the current line.  And using 'list XX' to list a
	specific location, followed by 'edit' should also now edit the just
	listed location.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669

	Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Mark Wielaard  <mark@klomp.org>

	bfd: Remove unused static find function from doc/chew.c
	After commit 2e60790cf7c27d79f90f2dcb81e1930dc980bc1c "Remove the
	paramstuff word" there is no caller left of the static find function
	in doc/chew.c, so it should be removed.

	* doc/chew.c (find): Remove.

2024-11-08  Andre Vieira  <andre.simoesdiasvieira@arm.com>

	arm, objdump: print obsolote warning when 26-bit set in instructions
	Arm has obsoleted the 26-bit addressing mode. Diagnose this when disasembling
	these instructions by printing OBSOLETE.

2024-11-08  Andre Vieira  <andre.simoesdiasvieira@arm.com>

	arm, objdump: Make objdump use bfd's machine detection to drive disassembly
	For any arm elf target, disable an old piece of code that forced disassembly to
	disassemble for 'unknown architecture' which once upon a time meant it would
	disassemble ANY arm instruction.  This is no longer true with the addition of
	Armv8.1-M Mainline, as there are conflicting encodings for different thumb
	instructions.

	BFD however can detect what architecture the object file was assembled for
	using information in the notes section.  So if available, we use that,
	otherwise we default to the old 'unknown' behaviour.

	With the changes above code, a mode changing 'bx lr' assembled for armv4 with
	the option --fix-v4bx will result in an object file that is recognized by bfd
	as one for the armv4 architecture.  The disassembler now disassembles this
	encoding as a BX even for Armv4 architectures, but warns the user when
	disassembling for Armv4 that this instruction is only valid from Armv4T
	onwards.

	Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and
	define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by
	-march=armv8-r+crc are disassembled correctly.

	Patch up some of the tests cases, see a brief explanation for each below.

	inst.d:
	This test checks the assembly & disassembly of basic instructions in armv3m. I
	changed the expected behaviour for teqp, cmnp cmpp and testp instructions to
	properly print p when disassembling, whereas before, in the 'unknown' case it
	would disassemble these as UNPREDICTABLE as they were changed in later
	architectures.

	nops.d:
	Was missing an -march, added one to make sure we were testing the right
	behavior of NOP<c> instructions.

	unpredictable.d:
	Was missing an -march, added armv6 as that reproduced the behaviour being
	tested.

2024-11-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed in i387_supply_xsave
	Use reg_buffer::raw_supply_zeroed in i387_supply_xsave.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed for NIOS r0 reg
	Use reg_buffer::raw_supply_zeroed for NIOS register r0.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed for Alpha r31 reg
	Use reg_buffer::raw_supply_zeroed for Alpha register r31.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed for PA-RISC r0 reg
	Use reg_buffer::raw_supply_zeroed for PA-RISC register r0.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed for IA-64 gr0 and fr0 regs
	Use reg_buffer::raw_supply_zeroed for IA-64 registers gr0 and fr0.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-07  Andre Simoes Dias Vieira  <andre.simoesdiasvieira@arm.com>

	arm: Skip two failing tests for wince & pe targets
	We don't seem to support any m-profile assembly/disassembly tests for wince or
	pe, so skipping the pacbti one too.

	The pr29494 test needs to be skipped because it uses assembly syntax that is
	not supported in wince/pe like for instance eabi_attribute directives.

2024-11-07  Nick Clifton  <nickc@redhat.com>

	Deprecate the ARM simulator.
	    The ARM simulator is no longer able to simulator modern ARM cores, so it
	    is being deprecated.  Once this change has been active for a while - and
	    assuming that no problems have been found - the ARm simulator codebase
	    will be removed.

2024-11-07  Stephan Rohr  <stephan.rohr@intel.com>

	gdbserver: add process specific thread list and map
	Replace the servers global thread list with a process specific thread
	list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on
	GDB side.  Optimize the 'find_thread' and 'find_thread_ptid' functions
	to use std::unordered_map::find for faster lookup of threads without
	iterating over all processes and threads, if applicable.  This becomes
	important when debugging applications with a large thread count, e.g.,
	in the context of GPU debugging.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-11-07  Stephan Rohr  <stephan.rohr@intel.com>

	gdbserver: change 'all_processes' and 'all_threads' list type
	This patch replaces the 'std::list' type of 'all_processes' and
	'all_threads' with the more lightweight 'owning_intrusive_list'
	type.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-11-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-06  Peter Bergner  <bergner@linux.ibm.com>

	PowerPC: Merge rfc2655 and rfc2656 test cases into one future test case
	gas/
		* testsuite/gas/ppc/rfc02655.[ds]: Rename from this...
		* testsuite/gas/ppc/future.[ds]: ... to this.
		* testsuite/gas/ppc/rfc02656.[ds]: Delete.  Move tests to future.[ds].
		* testsuite/gas/ppc/ppc.exp: Update for file name changes.

2024-11-06  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use raw_supply_zeroed for SPARC g0 reg
	Use reg_buffer::raw_supply_zeroed for SPARC register g0.

	Tested by rebuilding on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-06  Klaus Gerlicher  <klaus.gerlicher@intel.com>

	gdb: remove exact_match parameter from find_line_symtab
	struct symtab *find_line_symtab (struct symtab *, int, int *, bool *);

	The last parameter is bool* that when set will receive information
	if the match was exact. This parameter is never used by any callsite
	and can therefore be removed.

	This will become:

	symtab *find_line_symtab (symtab *sym_tab, int line, int *index);

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-04  Tom Tromey  <tromey@adacore.com>

	Turn decode_line_2_compare_items into operator<
	This rewrites decode_line_2_compare_items to be an operator< on the
	relevant type.  This simplifies the code a little.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-11-04  Simon Marchi  <simon.marchi@efficios.com>

	gdb: cleanup includes in *-typeprint.[ch]
	Remove includes reported as unused by clangd.

	Include "gdb-hashtab.h" in typeprint.h for the use of "htab_up".

	Change-Id: I5b04ec14e71800e2d6ad622838e39b7033e168cf

2024-11-04  Simon Marchi  <simon.marchi@efficios.com>

	gdb: cleanup includes in gdbtypes.h
	Remove some includes reported as unused by clangd.

	Change-Id: Ifc74f782d5aaafd1d719816821860352090c6667

2024-11-04  Tom Tromey  <tromey@adacore.com>

	Remove gdb::hash_enum
	gdb::hash_enum is a workaround for a small oversight in C++11:
	std::hash was not defined for enumeration types.  This was rectified
	in C++14 and so we can remove the local workaround.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-11-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: use option framework for add-inferior and clone-inferior
	Convert the add-inferior and clone-inferior commands to make use of
	the option framework.  This improves the tab completion for these
	commands.

	Previously the add-inferior command used a trick to simulate
	completion of -exec argument.  The command use filename completion for
	everything on the command line, thus you could do:

	  (gdb) add-inferior /path/to/some/fil<TAB>

	and GDB would complete the file name, even though add-inferior doesn't
	really take a filename as an argument.  This helped a little though
	because, if the user did this:

	  (gdb) add-inferior -exec /path/to/some/fil<TAB>

	then the file name would be completed.  However, GDB didn't really
	understand the options, so couldn't offer completion of the options
	themselves.

	After this commit, the add-inferior command makes use of the recently
	added gdb::option::filename_option_def feature.  This means that the
	user now has full completion of the option names, and that file names
	will still complete for the '-exec' option, but will no longer
	complete if the '-exec' option is not used.

	I have also converted the clone-inferior command, though this command
	does not use any file name options.  This command does now have proper
	completion of the command options.

2024-11-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: add filename option support
	This commit adds support for filename options to GDB's option
	sub-system (see cli/cli-option.{c,h}).

	The new filename options support quoted and escaped filenames, and tab
	completion is fully supported.

	This commit adds the new option, and adds these options to the
	'maintenance test-options' command as '-filename', along with some
	tests that exercise this new option.

	I've split the -filename testing into two.  In gdb.base/options.exp we
	use the -filename option with some arbitrary strings.  This tests that
	GDB can correctly extract the value from a filename option, and that
	GDB can complete other options after a filename option.  However,
	these tests don't actually pass real filenames, nor do they test
	filename completion.

	In gdb.base/filename-completion.exp I have added some tests that test
	the -filename option with real filenames, and exercise filename tab
	completion.

	This commit doesn't include any real uses of the new filename options,
	that will come in the next commit.

2024-11-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: spring clean the gdb.stabs/gdb11479.exp test
	I had reason to look at the gdb.stabs/gdb11479.exp test script and
	figured it could do with a small clean up.  I've:

	  - Made use of standard_testfile and the variables it defines.

	  - Made use of with_test_prefix and removed the prefix from the end
	    of each test name.

	  - Avoid overwriting the test binary when we recompile, instead use a
	    different name for each recompilation.

	  - Add '.' at the end of each comment.

	There should be no changes in what is tested with this commit.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-11-04  Aditya Vidyadhar Kamath  <aditya.kamath1@ibm.com>

	Fix AIX core dump while main thread exits.
	Consider the test case:
	void *thread_main(void *) {
	  std::cout << getpid() << std::endl;
	  sleep(20);
	  return nullptr;
	}

	int main(void) {
	  pthread_t thread;
	  pthread_create(&thread, nullptr, thread_main, nullptr);
	  pthread_join(thread, nullptr);

	  return 0;
	}

	This program creates a thread via main that sleeps for 20 seconds.

	When we debug this with gdb we get,
	Reading symbols from ./test...
	(gdb) b main
	Breakpoint 1 at 0x10000934: file test.c, line 11.
	(gdb) r
	Starting program: /read_only_gdb/binutils-gdb/gdb/test

	Breakpoint 1, main () at test.c:11
	11   pthread_create(&thread, nullptr, thread_main, nullptr);
	(gdb) c
	Continuing.
	15335884
	[New Thread 258 (tid 31130079)]
	Thread 2 received signal SIGINT, Interrupt.
	[Switching to Thread 258 (tid 31130079)]
	0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
	(gdb) thread 1
	[Switching to thread 1 (Thread 1 (tid 25493845))]
	(gdb) c
	Continuing.
	[Thread 1 (tid 25493845) exited]
	[Thread 258 (tid 31130079) exited]
	inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	----- Backtrace -----

	There are two bugs here. One is the core dump. The other is the main thread information
	not captured.

	So, while I was debugging the first part the reason, the reason I figured out was
	the last for loop in sync_threadlists ().

	Once both my threads exit we delete them as below:

	for (struct thread_info *it : all_threads ())
	      {
	if (in_queue_threads.count (priv->pdtid) == 0
	        && in_thread_list (proc_target, it->ptid)
	        && pid == it->ptid.pid ())
	      {
	        delete_thread (it);
	        data->exited_threads.insert (priv->pdtid);

	But once these two threads are deleted, all_threads ()
	has one more thread whose tid and pid are 0.

	gdb) c
	Continuing.
	In for loop 8782296 is pid, 19857879 is tid
	[Thread 1 (tid 19857879) exited]
	In for loop 8782296 is pid, 30933401 is tid
	[Thread 258 (tid 30933401) exited]
	In for loop 0 is pid, 0 is tid
	[Inferior 1 (process 8782296) exited normally]
	(gdb) q

	I used a printf in the for loop mentioned above for explaination.

	You see the loop enters the third time with 0 as pid.

	The reason being though the threads are removed but not deleted since they are
	not deletable ().

	Hence we use all_threads_safe () iterator instead.

	The second part to the bug is the lack of information of the main thread.
	Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html)
	Thank you Andrew.

	The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread
	failed. This returned EPERM as errno.

	if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL))
	        memset (gprs32, 0, sizeof (gprs32));

	Hence all registers were set to 0 and we did not get the required infromation.
	This issue will be fixed within the AIX ptrace call.

	Approved By: Ulrich Weigand <ulrich.weigand@de.ibm.com>.

2024-11-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-11-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: use gprofng- prefix for gprofng binaries
	gprofng application names have a gp- prefix (gp-display-text, gp-archive, etc.).
	But our man pages use the gprofng- prefix (gprofng-display-text,
	gprofng-archive, etc.).
	I renamed the gprofng binaries and temporarily created the gp-* links for
	compatibility with the old gprofng-gui.
	We plan to remove these links in version 2.46.

	gprofng/ChangeLog
	2024-10-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* doc/gprofng-archive.texi: Rename gprofng application names.
		* doc/gprofng-collect-app.texi: Likewise.
		* doc/gprofng-display-html.texi: Likewise.
		* doc/gprofng-display-src.texi: Likewise.
		* doc/gprofng-display-text.texi: Likewise.
		* doc/gprofng.texi: Likewise.
		* doc/gprofng_ug.texi: Likewise.
		* gp-display-html/Makefile.am: Likewise.
		* gp-display-html/gp-display-html.in: Likewise.
		* libcollector/collector.c: Likewise.
		* src/Application.cc: Likewise.
		* src/Experiment.cc: Likewise.
		* src/Makefile.am: Likewise.
		* src/gp-archive.cc: Likewise.
		* src/gp-collect-app.cc: Likewise.
		* src/gp-display-src.cc: Likewise.
		* src/gp-display-text.cc: Likewise.
		* src/gprofng.cc: Likewise.
		* src/Makefile.in: Rebuild.
		* gp-display-html/Makefile.in: Rebuild.

2024-11-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32303 ./configure --help: replace --enable-gprofng with --disable-gprofng
	ChangeLog
	2024-10-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32303
		* configure.ac: Replace --enable-gprofng with --disable-gprofng
		* configure: Rebuild.

2024-11-01  Indu Bhagat  <indu.bhagat@oracle.com>

	ld: generate SFrame stack trace info for .plt.got
	PR/32298 sframe: no SFrame stack trace info generated for .plt.got

	Add support to generate SFrame stack trace info for .plt.got section.
	Enhance the current definition of struct elf_x86_sframe_plt to include
	initialized SFrame FDE/FREs applicable for .plt.got section.  There are
	two variants of .plt.got entries: 16 byte and 8 byte.

	8 byte:
	    ff 25 00 00 00 00     jmpq  *name@GOTPCREL(%rip)
	    66 90                 xchg  %ax,%ax

	16 byte:
	    f3 0f 1e fa           endbr64
	    ff 25 66 2f 00 00     jmpq  *name@GOTPCREL(%rip)
	    66 0f 1f 44 00 00     nopw   0x0(%rax,%rax,1)

	For the testcase, define some application symbols such that their PLT
	entry is placed in .plt.got and ensure SFrame information is generated
	with and without -z ibtplt.

	ChangeLog:
		PR/32298
		* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
		PLT GOT entry size is different for IBT vs non IBT PLTs.
		* bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for
		SFRAME_PLT_GOT.
		(_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT.
		(_bfd_x86_elf_write_sframe_plt): Likewise.
		(_bfd_x86_elf_late_size_sections): Likewise.
		(_bfd_x86_elf_finish_dynamic_sections): Likewise.
		* bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members
		to keep information about PLT GOT entries.
		(struct elf_x86_link_hash_table): Add support for creating
		SFrame section for .plt.got.
		* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests.
		* ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test.
		* ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test.
		* ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test.

2024-11-01  Josh Poimboeuf  <jpoimboe@kernel.org>

	ld: fix wrong SFrame info for lazy IBT PLT
	Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt

	The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and
	.plt.sec entries.  It was observed that SFrame information for .plt.sec
	section was incorrect.  The erroneous assumption was that SFrame stack
	trace information for .plt.sec with lazy binding is the same as SFrame
	stack trace information for .plt with lazy binding.  This is corrected
	now by initializing a new SFrame PLT helper object
	elf_x86_64_sframe_ibt_plt for lazy PLT with IBT.

	Add a testcase where linking with -z ibtplt generates .plt.sec entries and
	ensure correct SFrame information for it.

	Committed by Indu Bhagat.

	ChangeLog:
		PR/32296
		* bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New
		definition elf_x86_64_sframe_ibt_plt.  Use it in
		elf_x86_64_sframe_plt.
		(elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are
		different from lazy PLT.
	        * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for
		SFrame for IBT PLT.
	        * ld/testsuite/ld-x86-64/x86-64.exp: Add new test.
	        * ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test.

2024-11-01  Josh Poimboeuf  <jpoimboe@kernel.org>

	ld: fix PR/32297
	When _creating_ SFrame information for the linker created .plt.sec, the
	code correctly checks for presence of .plt.sec.  When _writing_ the
	SFrame section for the corresponding .plt.sec, however, the conditionals
	were wrongly checking for splt.  This was causing an assertion at link
	time.

	This issue has been known to affect glibc build with SFrame enabled.

	No testcase is added just yet.  A later commit ensures correct SFrame
	stack trace information is created for .plt.got. A test case (where only
	.plt and .plt.got are created) is added then.

	PR/32297 sframe: bfd assertion with empty main on IBT enabled system

	Committed by Indu Bhagat.

	ChangeLog:
		PR/32297
		* bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for
		  plt_second member not for splt.

2024-11-01  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Add a test for hidden undefined symbol
	Linker should report an error for hidden undefined symbol when building
	a shared library without the "recompile with -fPIC" message:

	$ cat x.c
	extern int foo __attribute__ ((visibility ("hidden")));

	int
	func (void)
	{
	  return foo;
	}
	$ gcc -c -fPIC -O2 x.c
	$ objdump -dwr x.o

	x.o:     file format elf64-x86-64

	Disassembly of section .text:

	0000000000000000 <func>:
	   0:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 6 <func+0x6>	2: R_X86_64_PC32	foo-0x4
	   6:	c3                   	ret
	$ ld -shared -o x.so x.o
	ld: x.o: in function `func':
	x.c:(.text+0x2): undefined reference to `foo'
	ld: x.o: relocation R_X86_64_PC32 against undefined hidden symbol `foo' can not be used when making a shared object
	ld: final link failed: bad value
	$

	since -fPIC has been used.

		* testsuite/ld-x86-64/hidden6.d: New file.
		* testsuite/ld-x86-64/hidden6.s: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run hidden6.

2024-11-01  Andrew Oates  <andrew@andrewoates.com>

	Fix compile error due to [[noreturn]] with clang
	Since commit d9deb60b2e9e94b532f43a7d3ddddf5ddf6dbdd3, I get the
	following compiler error when building binutils (cross-compiling) on
	macos:

	 CXX    remote-sim.o
	../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback
	*, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)')
	      gdb_callback.error = gdb_os_error;
	                           ^~~~~~~~~~~~
	1 error generated.

	This appears to be due to the mismatch between ATTRIBUTE_NORETURN and
	[[noreturn]] on gdb_os_error.  Reverting the change for gdb_os_error
	resolves the issue.  Removing ATTTRIBUTE_NORETURN on the
	declaration of host_callback::error also works, but deprives the
	compiler of data.

	Tested by compiling on macos both with the system clang, as well as with
	GCC 14.  With clang, remote-sim.c does not compile (per above) without
	this patch.  With GCC, it compiles with and without the patch (it
	doesn't link, but AFAICT that is unrelated).

	The clang bug is reported upstream at
	https://github.com/llvm/llvm-project/issues/113511

	Approved-By: Tom Tromey <tom@tromey.com>

2024-11-01  Tom Tromey  <tromey@adacore.com>

	Add gdb.events.tui_enabled
	This adds a new event source so that Python scripts can track whether
	or not the TUI is presently enabled.

	v2 of the patch renames "status" -> "enabled".

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-11-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-31  Domani Johannes  <johannes.domani@lisec.com>

	Prevent use-after-free of bfd filename in gdb_bfd_close_or_warn
	On Windows gcore is not implemented, and if you try it, you get an
	heap-use-after-free error:

	(gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test
	warning: cannot close "=================================================================
	==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140
	READ of size 111 at 0x1259ea503110 thread T0
	    #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391
	    #1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558
	    #2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514
	    #3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41
	    #4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484
	    #5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106
	    #6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227
	    #7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571
	    #8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740
	    #9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73
	    #10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881
	    #11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181
	    #12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33
	    #13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437
	    #14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646
	    #15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
	    #16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
	    #17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
	    #18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176

	0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0)
	freed by thread T0 here:
	    #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90
	    #1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187
	    #2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247
	    #3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180
	    #4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960
	    #5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925
	    #6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643
	    #7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
	    #8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
	    #9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
	    #10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176

	It happens because gdb_bfd_close_or_warn uses a bfd-internal name for
	the failing-close warning, after the close is finished, and the name
	already freed:

	static int
	gdb_bfd_close_or_warn (struct bfd *abfd)
	{
	  int ret;
	  const char *name = bfd_get_filename (abfd);

	  for (asection *sect : gdb_bfd_sections (abfd))
	    free_one_bfd_section (sect);

	  ret = bfd_close (abfd);

	  if (!ret)
	    gdb_bfd_close_warning (name,
				   bfd_errmsg (bfd_get_error ()));

	  return ret;
	}

	Fixed by making a copy of the name for the warning.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-31  Nelson Chu  <nelson@rivosinc.com>

	gas/doc/riscv: Fixed misaligned instruction table
	gas/
		* doc/c-riscv.texi: Fixed misaligned instruction table.

2024-10-31  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Dump instruction without checking architecture support as usual.
	Since QEMU have supported -Max option to to enable all normal extensions,
	the dis-assembler should also add an option, -M,max to do the same thing.
	For the instruction, which have overlapped encodings like zfinx, will not
	be considered by the -M,max option.

	opcodes/
		* riscv-dis.c (all_ext): New static boolean.  If set, disassemble
		without checking architectire string.
		(riscv_disassemble_insn): Likewise.
		(parse_riscv_dis_option_without_args): Recognized -M,max option.
	binutils/
		* NEWS: Updated.

2024-10-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-30  H.J. Lu  <hjl.tools@gmail.com>

	ld-elf/pr25207.d: Pass --no-rosegment to ld
	Pass --no-rosegment to ld to support linker configured with
	--enable-rosegment,

		PR ld/25207
		* ld-elf/pr25207.d: Pass --no-rosegment to ld.

2024-10-30  Guinevere Larsen  <blarsen@redhat.com>

	gdb: Update SECURITY.txt to mention extension scripts and internal errors
	Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
	the gdb/SECURITY.txt to be more explicit about some details. Specifically,
	we now explicitly say that internal errors aren't security
	vulnerabilities, and mention that users should review plugins before
	running them, and under which conditions a plugin can cause a security
	bug.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-30  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Use std::array in amd64-windows-tdep.c
	I noticed commit 84786372e1c ("Fix size of register buffer") fixing a
	stack-buffer-overflow found by AddressSanitizer in
	amd64_windows_store_arg_in_reg:
	...
	-  gdb_byte buf[8];
	+  gdb_byte buf[16];
	...
	and wondered if we could have found this without AddressSanitizer.

	I realized that the problem is that this:
	...
	  gdb_byte buf[N];
	  ...
	  regcache->cooked_write (regno, buf);
	...
	is using the deprecated variant of cooked_write instead of the one using
	gdb::array_view:
	...
	  /* Transfer of pseudo-registers.  */
	  void cooked_write (int regnum, gdb::array_view<const gdb_byte> src);

	  /* Deprecated overload of the above.  */
	  void cooked_write (int regnum, const gdb_byte *src);
	...
	and consequently cooked_write does not know the size of buf.

	Fix this by using std::array, and likewise in other places in
	gdb/amd64-windows-tdep.c.

	In the process I fixed another out of bounds access here:
	...
		gdb_byte imm16[2];
	  ...
		cache->prev_sp = cur_sp
		  + extract_unsigned_integer (imm16, 4, byte_order);
	...
	where we're reading 4 bytes from the 2-byte buffer imm16.

	Tested by rebuilding on x86_64-linux.

	Tested-By: Hannes Domani <ssbssa@yahoo.de>

2024-10-30  Jan Beulich  <jbeulich@suse.com>

	x86: add a helper to copy insn operand info
	We're doing such in fairly many places, and yet more are likely to
	appear; centralize the logic, much like we already have
	swap_2_operands().

	While there also correct mis-indentation in adjacent code in
	process_operands().

2024-10-30  Jan Beulich  <jbeulich@suse.com>

	x86/APX: support JMPABS also in assembler
	Without this APX support isn't really complete.

	For Intel syntax displacement form is needed, such that symbolic
	operands won't need prefixing by "offset". (The other form is actually
	not used at all in Intel syntax.)

	For the record: To restrict displacement form to Intel syntax is not
	something I actually agree with.

2024-10-30  Jan Beulich  <jbeulich@suse.com>

	x86/APX: squash REX prefix when REX2 is being emitted
	We should not (silently) emit a REX prefix ahead of a REX2-encoded insn;
	such encodings are illegal. Best we can do is fold the REX bits into the
	REX2 prefix, and then zap the REX one from i.prefix[].

2024-10-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-29  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix signal unsafe call inside a signal
	It can easily happen that the signal handler function
	`handle_fatal_signal` uses various signal unsafe functions.
	The problematic functions are `_` and `strsignal` which
	can be pre-computed after the `setlocale` call is done.

	Unfortunately when compiled with --disable-libbacktrace a
	different code path is used, that calls the glibc function
	`backtrace` which calls `malloc` and `free` and is therefore
	also signal unsafe, that is probably unfixable, so there
	is no attempt to fix anything in this code path.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9

2024-10-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add read1 and readmore to make-check-all.sh
	There are two useful ways to run a test-case, that are not represented by a
	board file in gdb/testsuite/boards: check-read1 and check-readmore.

	Consequently, they're not run either by make-check-all.sh.

	Fix this by adding check-read1 and check-readmore to make-check-all.sh.

	Tested on x86_64-linux.  Verified with shellcheck.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-29  Nick Clifton  <nickc@redhat.com>

	Add a target to src-release.sh to crate a binutils release without Gold

2024-10-29  Hakan Candar  <hakancandar@protonmail.com>

	ld/ELF: Add --image-base command line option to the ELF linker
	LLD has dropped the option -Ttext-segment for specifying image base
	addresses, instead forcing the use of the --image-base option for both
	ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible,
	having two different options for the same functionality.

	This patch enables the use of --image-base on ELF targets, advancing
	consistency and compatibility.

	See: https://reviews.llvm.org/D70468
	     https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#address-related
	     https://sourceware.org/bugzilla/show_bug.cgi?id=25207

	Moreover, a new test has been added to ensure -z separate-code behaviour
	when used with -Ttext-segment stays the same. When this combination is
	used, -Ttext-segment sets the address of the first segment (R), not the
	text segment (RX), and like with -z noseparate-code, no segments lesser
	than the specified address are created. If this behaviour was to change,
	the first (R) segment of the ELF file would begin in a lesser address
	than the specified text (RX) segment, breaking traditional use of this
	option for specifying image base address.

2024-10-29  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle multiple .debug_info sections
	When compiling dw2-multiple-debug-info.c using -gdwarf-5
	-fdebug-types-section, we end with two .debug_info sections in the object
	file:
	...
	$ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \
	    -gdwarf-5 \
	    -fdebug-types-section
	$ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info
	  [10] .debug_info  PROGBITS        0 000128 0000cd 00  GC  0   0  8
	  [12] .debug_info  PROGBITS        0 0001f8 0000ad 00   C  0   0  8
	...

	One of them contains the CU for dw2-multiple-debug-info.c, the other contains
	the TU for the type of variable a.

	When trying to print the type of variable a, we get:
	...
	$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
	'a' has unknown type; cast it to its declared type
	...
	because the TU hasn't been read.

	Fix this by adding support for reading multiple .debug_info sections, similar
	to how that is done for multiple .debug_types sections, getting us instead:
	...
	$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
	type = class sp1::A {
	  ...
	}
	...

	Tested on x86_64-linux.

	PR symtab/32223
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223

2024-10-29  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	fortran: Fix arrays of variable length strings for FORTRAN
	Before this change resolve_dynamic_array_or_string was called for
	all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end,
	this function always called create_array_type_with_stride, which
	creates a TYPE_CODE_ARRAY type.

	Suppose we have

	subroutine vla_array (arr1, arr2)
	  character (len=*):: arr1 (:)
	  character (len=5):: arr2 (:)

	  print *, arr1 ! break-here
	  print *, arr2
	end subroutine vla_array

	The "print arr1" and "print arr2" command at the "break-here" line
	gives the following output:

	(gdb) print arr1
	$1 = <incomplete type>
	(gdb) print arr2
	$2 = ('abcde', 'abcde', 'abcde')
	(gdb) ptype arr1
	type = Type
	End Type
	(gdb) ptype arr2
	type = character*5 (3)

	Dwarf info using Intel® Fortran Compiler for such case contains following:
	 <1><fd>: Abbrev Number: 12 (DW_TAG_string_type)
	    <fe>   DW_AT_name        : (indirect string, offset: 0xd2): .str.ARR1
	    <102>   DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8)

	After this change resolve_dynamic_array_or_string now calls
	create_array_type_with_stride or create_string_type, so if the
	incoming dynamic type is a TYPE_CODE_STRING then we'll get back a
	TYPE_CODE_STRING type.  Now gdb shows following:

	(gdb) p arr1
	$1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij')
	(gdb) p arr2
	$2 = ('abcde', 'abcde', 'abcde')
	(gdb) ptype arr1
	type = character*10 (5)
	(gdb) ptype arr2
	type = character*5 (3)

	In case of GFortran, compiler emits DW_TAG_structure_type for string type
	arguments of the subroutine and it has only DW_AT_declaration tag.  This
	results in <incomplete type> in gdb.  So, following issue is raised in gcc
	bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826".

	Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp,
	i.e. the test forces the language to C/C++ and print a Fortran string value.
	The string value is a dynamic type with code TYPE_CODE_STRING.

	Before this commit the dynamic type resolution would always convert this to
	a TYPE_CODE_ARRAY of characters, which the C value printing could handle.

	But now after this commit we get a TYPE_CODE_STRING, which
	neither the C value printing, or the generic value printing code can
	support.  And so, I've added support for TYPE_CODE_STRING to the generic
	value printing, all characters of strings are printed together till the
	first null character.

	Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp
	tests it expects type of character array in 'character (3)' format but now
	after this change we get 'character*3', so tests are updated accordingly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-29  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Corrected to GNU style code

2024-10-29  Jan Beulich  <jbeulich@suse.com>

	x86: use <xyz> for VFPCLASSP{S,D}
	Just like VFPCLASSPH does. While the order of generated table entries
	changes this way, the individual entries don't change.

	gas: make fix_new_exp()'s "exp" parameter const
	This really should be only an input; in particular it looks bogus that
	O_add expressions are even altered. That altering and the recursion are
	even pointless: Once expanding what the inner call would do (with
	O_symbol) it becomes clear that this is no different than the default
	case. Simplify the code accordingly, retaining the comment.

2024-10-29  Jan Beulich  <jbeulich@suse.com>

	gas: constify md_{short,long}opts and md_longopts_size
	First of all make the declarations globally visible, such that producer
	and consumer actually share them.

	For the latter two simply add const (as PPC already had it,), while for
	the former achieve the effect by converting to an array: There's no need
	for the extra level of indirection.

2024-10-29  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Update the doc to match ISA manual
	ISA manual use funct* rather than func*[1] (e.g. funct7 rather than func7),
	and I realized that may something I typo at beginning when I write the patch
	for `.insn` support...:P

	[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/rv32.adoc#integer-register-register-operations

2024-10-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-28  Hannes Domani  <ssbssa@yahoo.de>

	Fix size of register buffer
	When calling a function with double arguments, I get this asan error:

	==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40
	READ of size 16 at 0x0053131ece38 thread T0
	    #0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814
	    #1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845
	    #2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840
	    #3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874
	    #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:914
	    #5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933
	    #6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216

	Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame
	    #0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208

	  This frame has 4 object(s):
	    [32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable

	It's because the first 4 double arguments are passed via XMM registers,
	and they need a buffer of 16 bytes, even if we only use 8 bytes of them.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Hannes Domani  <ssbssa@yahoo.de>

	Don't copy memory for arguments if there are none
	If amd64_windows_push_arguments is called with no arguments, then ARGS
	can be NULL, and inside the passed-by-pointer block, memcpy is called
	with this NULL, which is undefined behavior.

	So this just disable the passed-by-pointer block if there are no
	arguments.

	Fixes the following ubsan error:
	C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: remove unused include in gdbthread.h
	clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h,
	which seems right, so remove it.  Add it to two files that need it, but
	were relying on the now-removed include.

	Change-Id: I12916a044d0b15f346c4ad0e6527ce99a6d460e4

2024-10-28  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbserver: fix formatting in gdbthread.h
	Remove newlines after return type in declarations.

	Change-Id: I00c6f35e063024cf6674d532454b67e6d0d98a19

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support to vzeroupper instruction
	This commit adds recording support for the AVX instruction vzeroupper,
	which zeroes the high bits of ymm registers 0..15.  In the programmer's
	manual, it is explicitly states that ymm registers 16..31 won't be
	affected if present, so we only need to record the first 16 registers.

	We record ymm_h registers since only the higher bits are touched, and
	that reduces the memory footprint of the instruction.

	This instruction is tested differently as we want to confirm we're only
	saving the relevant registers, and we want to ensure we're saving
	all of them, so it makes use of "maint print record-instruction" to see
	exactly what was recorded.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: support AVX instructions VMOVDQ(U|A) when recording
	This commit adds support for the instructions VMOVDQU and VMOVDQA, used
	to move values to/from 256 bit registers. Unfortunately, the
	programmer's manual is very incomplete (if not wrong) about these
	instructions, so the logic had to be reverse engineered from how gcc
	actually encodes the instruction.

	This commit also changes the memory regions from the test to store 256
	bits, so its easier to test the instructions and that we're recording
	ymm registers correctly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: Add recording support to vpbroadcast instructions
	This commit adds recording support to all AVX and AVX2 instructions
	of the form vpbroadcast. GDB is not yet concerned about AVX512 in
	recording mode, so for now we only support the AVX2 registers and
	instructions.

	This commit also updates the gdb.reverse/i386-avx-reverse.exp to test
	broadcast instructions.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support to AVX unpack instructions
	This commit adds support to recording instructions to unpack high
	or low data from XMM registers, identified by the mnemonics in the
	form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
	All these instructions are encoded the exact same way, and only affect
	the destination register, making them trivial to implement together.

	It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
	new instructions.  The test always uses ymm because the vpunpck
	instructions overwrite the high bits, so we have to be able to record
	the full ymm register, not just the output size.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb/record: add support to vmovd and vmovq instructions
	This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
	The programmers manuals for Intel and AMD describe these 2 instructions
	as being almost the same, but my local testing, using gcc 13.2 on Fedora
	39, showed several differences and inconsistencies.

	The instruction is supposed to always use the 3-byte VEX prefix, but I
	could only find 2-byte versions. The instructions aren't differentiated
	by the VEX.w bit, but by opcodes and VEX.pp.

	This patch adds a test with many different uses for both vmovd and
	vmovq. It also updates the test gdb.reverse/step-precsave.exp to
	reference the generic "missing avx support" bug open in the bug tracker
	(17346), instead of pointing to one that specifically calls out to
	vmovd instructions.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188
	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Start supporting AVX instruction
	This patch introduces the information needed to properly identify the
	VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
	a helper function to handle all AVX instruction, instead of adding to
	the 3000 line long recording function.

	This new function will temporarily set the current thread as "not
	executing" so that it can read from pseudo registers as we record, since
	most AVX/AVX2 instructions would benefit from recording ymm registers.

	The new helper also handles unsupported instructions so that the largest
	part of the i386_process_record doesn't have to be shifted by 2 spaces,
	which made an unreadably big patch file.

	The only expected difference to the end user added by this patch is a
	small change to the unsupported message. This patch also updates the
	test gdb.reverse/step-precsave.exp, by recognizing the new output.

	As a note for the future, we don't handle xmm16-31 and ymm16-31 because
	those require the EVEX prefix, meaning avx512 support.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Allow replayed threads to read and write pseudo registers
	In an effort to support AVX instructions when recording, we need to
	allow replaying threads to access pseudo registers. Currently, if
	we try to do that gdb will fail in a call to validate_registers_access,
	because the thread is executing so GDB thinks it is unsafe to read
	pseudo registers.

	When replaying, the thread is really executing for all intents and
	purposes, but the execution is just having GDB change values on
	registers, so it will always be safe to read and write pseudo registers.
	This commit changes functions that check for register access to allow
	access when we are replaying. The check to whether we are replaying must
	not happen when writing a core file, as record_full_list could be nullptr,
	so we only check it if the thread is executing.

	As of this commit, I don't know of a way to trigger this commit without
	AVX support on record, so a test isn't provided. However, as soon as
	record-full supports saving ymm registers, the AVX tests will test this
	as well.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-28  Jim Lin  <jim@andestech.com>

	RISC-V: Fix typo in gas/testsuite/gas/riscv/mapping.s
	gas/
	        * gas/riscv/mapping.s: Fix typo.
	        * gas/riscv/mapping-dis.d: Fix typo.
	        * gas/riscv/mapping-symbols.d. Fix typo.

2024-10-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: avoid intermittent failures on a debuginfod test
	I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which
	I could only produce one time.

	Normally the test output looks like this:

	  file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
	  Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
	  (gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war

	But one time I saw this:

	  file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
	  Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
	  Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
	  (gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings

	The difference is the "Downloading separate debug info for ..." line
	has gained an extra '6.77 K' component.  When I got the FAIL the
	machine was under heavy load, so I suspect everything was running
	pretty slow.  I think the size is only added when the debuginfod
	download is taking its time.

	Anyway, the test in question is not expecting to see a size, which is
	why it failed.

	Every other debuginfod test does allow for an optional size being
	printed, so lets update this test to also accept an optional size,
	this should prevent failures like this in the future.

2024-10-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp
	There are two test-cases that only run when the target board produces .dwp
	files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp.

	When running those test-cases with target board fission-dwp, I run into:
	...
	(gdb) ptype main^M
	warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \
	  referenced by CU at offset 0xa6 [in module dwp-symlink]^M
	type = <unknown return type> ()^M
	(gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink
	...
	coming from:
	...
	 # This case cannot work.
	 gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink"
	...

	I had a bit of difficulty understanding what the test-case does/tries to do,
	so to build some understanding I reproduced the behaviour outside of the
	test-case:
	...
	$ cat start.c
	void _start (void) {}
	$ gcc -gsplit-dwarf start.c -nostdlib
	$ gdb -q -batch a.out -ex "print _start"
	$1 = {void (void)} 0x400144 <_start>
	$ dwp -e a.out
	$ rm start.dwo
	$ gdb -q -batch a.out -ex "print _start"
	$1 = {void (void)} 0x400144 <_start>
	$ ln -s a.out b.out
	$ gdb -q -batch b.out -ex "print _start"
	$1 = {void (void)} 0x400144 <_start>
	$ mv a.out.dwp b.out.dwp
	$ gdb -q -batch b.out -ex "print _start"
	$1 = {void (void)} 0x400144 <_start>
	$ gdb -q -batch a.out -ex "print _start"
	During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
	  referenced by CU at offset 0x0 [in module a.out]
	warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
	  referenced by CU at offset 0x0 [in module a.out]
	$1 = {<text variable, no debug info>} 0x400144 <_start>
	...
	and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp,
	and there's no way to find b.out.dwp starting from a.out.

	The fact that a FAIL is produced is incorrect, gdb does nothing wrong.

	Fix this by checking for the warning text instead.

	While we're at it, fix this PATH as well:
	...
	(gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M
	Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M
	(gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \
	  /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
	PATH: gdb.dwarf2/dwp-symlink.exp: cd \
	  /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
	...

	While we're at it, use string_to_regexp to simplify the test-case.

	Tested on x86_64-linux, with target board fission-dwp.

2024-10-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix test pattern after switch to -lbl matching
	After commit:

	  commit a1ccc78ea7ba8cad3ff37cbde9b5d3bba0194796
	  Date:   Fri Oct 25 06:14:03 2024 +0200

	      [gdb/testsuite] Fix some test-cases for check-read1 (-lbl)

	I notice that gdb.base/sect-cmd.exp would sometimes fail.  The problem
	is that by switching to line by line matching we now need to ensure
	that the gdb_test_multiple patterns match up to the end of the line,
	but don't actually include the trailing \r\n (yeah, our line by line
	matching is weird).  We need to be especially careful anywhere '.*' is
	used as this can potentially match content on a subsequent line.

	I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up
	to the end of the line, but not the end of line itself, and I've made
	use of '(?=\r\n)' in a couple of other places to ensure we match up to
	the end of the line, but don't match the line terminator itself.

2024-10-26  Tom de Vries  <tdevries@suse.de>

	[gdb] Don't create registry keys in destructor
	Creating a registry key using emplace calls new:
	...
	      DATA *result = new DATA (std::forward<Args> (args)...);
	...
	which can throw a bad alloc, which will terminate gdb if called from a
	destructor.

	Fix this in a few places.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-26  Alan Modra  <amodra@gmail.com>

	tekhex.c tidy writesym
	Simplifies the code a little.  No functional changes.

	PR32300, --dependency-file: link dependencies are not all collected
		PR 32300
		PR 31904
	Revert patch accidentally committed with 057a2b4c4b

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexcept
	Say we simulate a bad alloc in exceptions_state_mc_init:
	...
	 jmp_buf *
	 exceptions_state_mc_init ()
	 {
	+  {
	+    static bool throw_bad_alloc = true;
	+    if (throw_bad_alloc)
	+      {
	+       throw_bad_alloc = false;
	+
	+       va_list dummy;
	+       throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
	+      }
	+  }
	   catchers.emplace_front ();
	   return &catchers.front ().buf;
	 }
	...

	After starting gdb and typing "q", gdb terminates:
	...
	$ gdb -q
	(gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc'
	  what():  std::bad_alloc
	...
	because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on
	gdb_rl_callback_read_char_wrapper_noexcept:
	...
	static struct gdb_exception
	gdb_rl_callback_read_char_wrapper_noexcept () noexcept
	{
	  struct gdb_exception gdb_expt;

	  /* C++ exceptions can't normally be thrown across readline (unless
	     it is built with -fexceptions, but it won't by default on many
	     ABIs).  So we instead wrap the readline call with a sjlj-based
	     TRY/CATCH, and rethrow the GDB exception once back in GDB.  */
	  TRY_SJLJ
	...

	Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to
	gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function
	that catches the bad alloc expection:
	...
	static struct gdb_exception
	gdb_rl_callback_read_char_wrapper_noexcept () noexcept
	{
	  try
	    {
	      return gdb_rl_callback_read_char_wrapper_sjlj ();
	    }
	  catch (gdb_exception &ex)
	    {
	      return std::move (ex);
	    }
	}
	...
	getting us instead:
	...
	$ gdb -q
	(gdb) bad alloc
	(gdb) q
	...

	Tested on aarch64-linux.

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1
	Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting
	the output of skip_libstdcxx_probe_tests_prompt by making the used command
	more precise: using "info probes stap libstdcxx" instead of "info probes".

	Tested on x86_64-linux.

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1
	Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by
	using a custom line-by-line exp_continue clause:
	...
	    -re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" {
		exp_continue
	    }
	...
	which drops a line each time it finds two lines in the buffer.

	This allows the other clauses to use two-line patterns.

	Tested on x86_64-linux.

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)
	I ran the testsuite in an environment simulating a stressed system in
	combination with check-read1.  This exposes a few more FAILs.

	Fix some by using -lbl.

	Tested on x86_64-linux.

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix some test-cases for check-read1 (pipe/grep)
	I ran the testsuite in an environment simulating a stressed system in
	combination with check-read1.  This exposes a few more FAILs.

	Fix some by using pipe / grep to filter out unnecessary output.

	Tested on x86_64-linux.

2024-10-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix some test-cases for check-read1 (gdb_test_lines)
	I ran the testsuite in an environment simulating a stressed system in
	combination with check-read1.  This exposes a few more FAILs.

	Fix some by using gdb_test_lines, as well as related gdb_get_lines.

	Tested on x86_64-linux.

2024-10-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-24  Tom Tromey  <tom@tromey.com>

	Add locking when reading BFD sections
	This adds some per-BFD locking to gdb_bfd_map_section and
	gdb_bfd_get_full_section_contents.

	It turned out that the background DWARF reader could race with the
	auto-load code, because the reader might try to mmap a section when
	the main thread was trying to read in .debug_gdb_scripts.

	The current BFD threading model is that only BFD globals will be
	locked, so any multi-threaded use of a BFD has to be handled specially
	by the application.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2024-10-24  Tom Tromey  <tom@tromey.com>

	Use gdb_bfd_get_full_section_contents in auto-load.c
	This changes auto-load.c ot use gdb_bfd_get_full_section_contents.
	This shouldn't change any behavior, but makes it easier to add locking
	in a subsequent patch.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2024-10-24  Alan Modra  <amodra@gmail.com>

	Replace uses of asprintf with xasprintf
	xasprintf has a nicer interface and behaves like xmalloc as far as
	memory is concerned, ie. no need to check a return status and the
	program exits with an error on OOM.

	binutils/
		* dwarf.c (load_debug_sup_file): Replace asprintf with xasprintf.
		* nm.c (get_elf_symbol_type, get_coff_symbol_type): Likewise.
		* objdump.c (dump_ctf_indent_lines): Likewise.
		* readelf.c (display_lto_symtab, dump_ctf_indent_lines): Likewise.
		* windres.c (main): Likewise.
		* configure.ac: Remove asprintf from AC_CHECK_DECLS.
		* config.in: Regenerate.
		* configure: Regenerate.
	gas/
		* config/tc-kvx.c (kvx_emit_single_noop): Simplify.
		* config/tc-riscv.c (md_assemblef): Replace asprintf with xasprintf.
		* read.c (s_nop, do_s_func): Likewise.
		* stabs.c (stabs_generate_asm_func): Likewise.
		(stabs_generate_asm_endfunc): Likewise.
		* configure.ac: Remove asprintf from AC_CHECK_DECLS.
		* config.in: Regenerate.
		* configure: Regenerate.
	ld/
		* ldlang.c (lang_leave_overlay_section): Replace xmalloc+sprintf
		with xasprintf.  Localise vars.
		* lexsup.c (parse_args): Replace asprintf with xasprintf.
		* pe-dll.c (make_head, make_tail, make_one): Likewise.
		(make_singleton_name_thunk, make_import_fixup_entry): Likewise.
		(make_runtime_pseudo_reloc): Likewise.
		(pe_create_runtime_relocator_reference): Likewise.
		* configure.ac: Remove asprintf from AC_CHECK_DECLS.
		* config.in: Regenerate.
		* configure: Regenerate.

2024-10-24  Alan Modra  <amodra@gmail.com>

	tekhex object file output fixes
	writevalue didn't handle 64-bit values, dropping the high 32 bits,
	and also wrote any value in the range [0,15] as 0.

		* tekhex.c (first_phase): Handle *ABS* symbols.
		(writevalue): Rewrite.

2024-10-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-23  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: introduce dwarf5 option to gdb_compile
	A few tests on the testsuite require dwarf5 to work. Up until now, the
	way to do this was to explicitly add the command line flag -gdwarf-5.
	This isn't very portable, in case a compiler requires a different flag
	to emit dwarf5.

	This commit adds a new option to gdb_compile that would be able to add
	the correct flag (if known) or error out in case we are unable to tell
	which flag to use. It also changes the existing tests to use this
	general option instead of hard coding -gdwarf-5.

	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-22  Tom Tromey  <tromey@adacore.com>

	Implement 'Object_Size
	This patch started as an attempt to allow the 'Size attribute to be
	applied to types, and not just objects.

	However, that turns out to be difficult due to the Ada semantcs of
	'Size.  In particular, Ada requires 'Size to denote the size of the
	representation of the value, so for example Boolean'Size must be 1.
	Implementing this properly requires information not readily available
	to gdb... and while we could synthesize this information in many
	cases, it also seemed to me that this wasn't strictly very useful when
	debugging.

	So instead, this patch adds support for the 'Object_Size attribute,
	which is somewhat closer to 'sizeof'.

	Note also that while 'Object_Size is defined for some dynamic types, I
	chose not to implement this here, as again this information is not
	readily available -- and I think it's preferable to error than to
	print something that might be incorrect.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-10-22  Michael Matz  <matz@suse.de>

	stringmerge: don't presize hash table
	originally the reason for pre-sizing was that that's easier
	for a multi-threaded use of the hash table.  That hasn't materialized
	yet, so there's not much sense in using the very very conservative
	estimates for pre-sizing.  Doing the resize on-demand, whenever we
	actually need to add a new entry doesn't change performance.

		bfd/
		merge.c (sec_merge_hash_insert): Resize as needed from here ...
		(record_section): ... not from here.  Don't calculate estimates,
		return bool instead of three-state, regard all errors as soft
		errors.
		(_bfd_merge_sections): Adjust.

2024-10-22  Stephan Rohr  <stephan.rohr@intel.com>

	gdbserver: use 'gdb::function_view' in 'find_*' and 'for_each_*'
	Remove the templated versions of 'find_thread', 'for_each_thread' and
	'find_thread_in_random' and replace the template function argument with
	'gdb::function_view'.  The usage of 'gdb::function_view' produces less
	cryptic messages on errors and documents well the types of the
	parameters taken by the callback and its return type.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle maint set dwarf synchronous off default
	I ran the testsuite with a patch setting dwarf_synchronous to false by
	default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
	and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
	not show up as a result of the file command.

	Fix this by forcing "maint set dwarf synchronous on".

	Add the same in gdb.base/index-cache.exp, where this is also required.

	Tested on aarch64-linux.

2024-10-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.exp
	I ran into:
	...
	(gdb) pipe maint print objfiles self-spec | grep c1^M
	    name:       c1^M
	    canonical:  c1^M
	    qualified:  c1^M
	    [3] ((addrmap *) 0xfffedfc1f010)^M
	(gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index
	...

	Fix this by renaming the class from c1 to class1.

	Tested on aarch64-linux.

2024-10-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle EINTR in run_under_shell
	When building gdb with -O2 -fsanitize=thread and running test-case
	gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
	...
	(gdb) c&^M
	Continuing.^M
	(gdb) Quit^M
	(gdb) quit_count=1
	^M
	Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
	23        return 0;^M
	FAIL: $exp: no force memory write: \
	  SIGINT does not interrupt background execution
	...

	What happens is that:
	- the breakpoint hits
	- while evaluating the condition of the breakpoint,
	  $_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
	- in run_under_shell, a vfork is issued
	- in the vfork child, execl executes the kill command
	- in the vfork parent, waitpid is called to wait for the result of the kill
	  command
	- waitpid returns -1 with errno set to EINTR
	- run_under_shell doesn't check the result of waitpid, and returns the
	  value of local variable status.  Since waitpid returned -1, status was
	  not assigned a value, so it's uninitialized, and happens to be
	  non-zero
	- the breakpoint condition evaluates to true, because
	  $_shell("kill -INT <pid-of-gdb>") != 0
	- the breakpoint triggers a stop, which the test-case doesn't expect.

	Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.

	Also handle the case that waitpid returns an error other than EINTR, using
	perror_with_name.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR gdb/30695
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695

2024-10-22  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Force relocation for every reference to the global offset table
	Local absolute symbols are resolved at assembly stage and the symbol
	value is placed in the relocation addend. But non-zero addend will
	cause an assertion failure during linking.

	Forces emission of relocations to defer resolution of local abs symbols
	until link time.

	bfd/

	        * elfnn-loongarch.c (loongarch_elf_relax_section): Determine
	          absolute symbols in advance to avoid ld crash.

	gas/

	        * config/tc-loongarch.c (loongarch_force_relocation): New
	          function to force relocation.
	        * config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros
	          to force relocation.
	        (loongarch_force_relocation): Function declaration.
	        * testsuite/gas/loongarch/localpic.d: New test.
	        * testsuite/gas/loongarch/localpic.s: New test.

2024-10-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-21  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix incorrect filenames with inter-CU refs
	With target board unix we get:
	...
	$ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \
	  -ex "info function operator\*"
	All functions matching regular expression "operator\*":

	File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc:
	72:     void foo::operator*(foo&);
	85:     void foo::operator*=(foo&);
	...
	but with target board cc-with-dwz-m:
	...
	All functions matching regular expression "operator\*":

	File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h:
	72:     void foo::operator*(foo&);
	85:     void foo::operator*=(foo&);
	...

	The first operator:
	...
	$ c++filt _ZN3foomlERS_
	foo::operator*(foo&)
	...
	matches address 0x410250 which is defined here in the CU in the exec:
	...
	 <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
	    <10f2>   DW_AT_specification: <alt 0x93>
	    <10f6>   DW_AT_decl_line   : 72
	    <10f7>   DW_AT_decl_column : 7
	    <10f7>   DW_AT_object_pointer: <0x1106>
	    <10f9>   DW_AT_low_pc      : 0x410250
	    <1101>   DW_AT_high_pc     : 32
	    <1102>   DW_AT_frame_base  : 1 byte block: 9c       (DW_OP_call_frame_cfa)
	    <1104>   DW_AT_call_all_calls: 1
	...
	and declared here in the PU in the .dwz file:
	...
	 <2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
	    <94>   DW_AT_external    : 1
	    <94>   DW_AT_name        : operator*
	    <98>   DW_AT_decl_file   : 2
	    <98>   DW_AT_decl_line   : 10
	    <99>   DW_AT_decl_column : 9
	    <9a>   DW_AT_linkage_name: _ZN3foomlERS_
	    <9e>   DW_AT_accessibility: 1       (public)
	    <9e>   DW_AT_declaration : 1
	    <9e>   DW_AT_object_pointer: <0xa2>
	...

	When creating a new symbol for the operator, the DW_AT_decl_file attribute is
	looked up, and found to be 2.

	The 2 is supposed to be mapped using the PU, which has this file name table:
	...
	 The File Name Table (offset 0x78, lines 3, columns 2):
	  Entry Dir     Name
	  0     0       <dwz>
	  1     1       stddef.h
	  2     2       cplusfuncs.cc
	...

	Instead, it's mapped using the CU, which has this file name table:
	...
	 The File Name Table (offset 0x34, lines 3, columns 2):
	  Entry Dir     Name
	  0     1       cplusfuncs.cc
	  1     1       cplusfuncs.cc
	  2     2       stddef.h
	...

	This is PR symtab/30814.  There's a similar PR for lto, PR symtab/25771, where
	the same problem happens for two CUs.

	Fix this by using the correct file name table.

	Add a dwarf assembly test-case for PR25771.

	Tested on aarch64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814

2024-10-21  Alexandra Hájková  <ahajkova@redhat.com>

	gdbreplay: Add --debug-logging option
	As gdbreplay communicates with GDB, it outputs all the remote
	protocol communication it reads from the remotelogfile to stderr.
	This patch disables this behavior by default but adds the new
	--debug-logging option which turns printing the packets
	to stderr on again.

	The motivation for this change is to make it possible to use
	gdbreplay with TCL tests. Printing the whole remotelog file out
	seems to overflow the expect cache wich causes gdbreplay to not
	to get the packet its expects and results in going out of sync
	with GDB. Other motivation is making communication between GDB
	and gdbreplay faster as printing bigger remotelogfile takes
	considerable amount of time.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-21  Alexandra Hájková  <ahajkova@redhat.com>

	gdbreplay: Use getopt_long to parse command line arguments
	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-21  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Handle dot in spellcheck.sh
	Add handling of '.' in gdb/contrib/spellcheck.sh.

	While we're at, simplify the sed invocation by using a single s command
	instead of 3 s commands.

	Also introduce sed_join and grep_join.

	Fix the following common misspellings:
	...
	bandwith -> bandwidth
	emmitted -> emitted
	immediatly -> immediately
	suprize -> surprise
	thru -> through
	transfered -> transferred
	...

	Verified with shellcheck.

2024-10-21  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Speed up spellcheck.sh --check
	Speed up gdb/contrib/shellcheck.sh by caching the grep pattern.

	Without cached grep pattern:
	...
	$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c

	real    0m2,750s
	user    0m0,013s
	sys     0m0,032s
	...
	and with cached grep pattern:
	...
	$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c

	real    0m0,192s
	user    0m0,022s
	sys     0m0,024s
	...

	Tested on aarch64-linux.

2024-10-21  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add spellcheck.sh --check
	Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell
	check and bail out ASAP with an exit code of 1 if misspelled words were
	found, or 0 otherwise.

	Verified with shellcheck.

2024-10-21  Andrew Burgess  <aburgess@redhat.com>

	gdb/guile: add get-basic-type
	A question was asked on stackoverflow.com about the guile function
	get-basic-type[1] which is mentioned in the docs along with an example
	of its use.

	The problem is, the function was apparently never actually added to
	GDB.  But it turns out that it's pretty easy to implement, so lets add
	it now.  Better late than never.

	The implementation mirrors the Python get_basic_type function.  I've
	added a test which is a copy of the documentation example.

	One issue is that the docs suggest that the type will be returned as
	just "int", however, I'm not sure what this actually means.  It makes
	more sense that the function return a gdb:type object which would be
	represented as "#<gdb:type int>", so I've updated the docs to show
	this output.

	[1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2024-10-21  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix more deprecated implicit capture of this
	When building gdb with -std=c++20 I run into:
	...
	gdb/dwarf2/cooked-index.c: In lambda function:
	gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \
	  ‘[=]’ is deprecated in C++20 [-Werror=deprecated]
	  471 |   gdb::thread_pool::g_thread_pool->post_task ([=] ()
	      |                                               ^
	gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture
	...

	Fix this and two more spots by removing the capture default, and explicitly
	listing all captures.

	Tested on x86_64-linux.

2024-10-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix 'maint info inline-frames' after 'stepi'
	There is an invalid assumption within 'maint info inline-frames' which
	triggers an assert:

	  (gdb) stepi
	  0x000000000040119d	18	  printf ("Hello World\n");
	  (gdb) maintenance info inline-frames
	  ../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed.
	  A problem internal to GDB has been detected,
	  further debugging may prove unreliable.
	  ----- Backtrace -----
	  ... etc ...

	The problem is this assert:

	  /* Stopped threads always have cached inline_state information.  */
	  gdb_assert (it != inline_states.end ());

	If you check out infrun.c and look in handle_signal_stop for the call
	to skip_inline_frames then you'll find a rather large comment that
	explains that we don't always compute the inline state information for
	performance reasons.  So the assertion is not valid.

	I've updated the code so that if there is cached information we use
	that, but if there is not then we just create our own information for
	the current $pc of the current thread.

	This means that, if there is cached information, GDB still correctly
	shows which frame the inferior is in (it might not be in the inner
	most frame).

	If there is no cached information we will always display the inferior
	as being in the inner most frame, but that's OK, because if
	skip_inline_frames has not been called then GDB will have told the
	user they are in the inner most frame, so everything lines up.

	I've extended the test to check 'maint info inline-frames' after a
	stepi which would previously have triggered the assertion.

2024-10-20  Tom Tromey  <tom@tromey.com>

	Use std::make_unique in more places
	I searched for spots using ".reset (new ...)" and replaced most of
	these with std::make_unique.  I think this is a bit cleaner and more
	idiomatic.

	Regression tested on x86-64 Fedora 40.

	Reviewed-By: Klaus Gerlicher<klaus.gerlicher@intel.com>

2024-10-20  Alan Modra  <amodra@gmail.com>

	Report bfd_merge_sections error
		PR 32260
	bfd/
		* elfxx-target.h (bfd_elfNN_bfd_merge_sections): Default to
		bfd_generic_merge_sections when using the generic linker.
		* elflink.c (_bfd_elf_merge_sections): Return error from
		_bfd_merge_sections.  Abort on wrong hash table.
	ld/
		* ldlang.c (lang_process): Report bfd_merge_sections error.

2024-10-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-19  Tom Tromey  <tom@tromey.com>

	Capture the current directory and debug directory in DWARF reader
	This changes the DWARF reader to capture the current working directory
	and the current debug directory.  This avoids races when the DWARF
	reader is working in the background.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716

2024-10-19  Tom Tromey  <tom@tromey.com>

	Add cwd paramter to openp
	This patch adds a cwd paramter to openp, so that the current directory
	can be passed in by the caller.  This is useful when background
	threads call this function -- they can then avoid using the global and
	thus avoid races with the user using "cd".

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716

2024-10-19  Tom Tromey  <tom@tromey.com>

	Pass current directory to gdb_abspath
	Currently, gdb_abspath uses the current_directory global.  However,
	background threads need to capture this global to avoid races with the
	user using "cd".

	This patch changes this function to accept a cwd parameter, in
	prepration for this.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716

2024-10-19  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Add gdb::array_view::{iterator,const_iterator}
	While trying to substitute some std::vector type A in the code with a
	gdb::array_view:
	...
	- using A = std::vector<T>
	+ using A = gdb::array_view<T>
	....
	I ran into the problem that the code was using A::iterator while
	gdb::array_view doesn't define such a type.

	Fix this by:
	- adding types gdb::array_view::iterator and gdb::array_view::const_iterator,
	- using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is
	  usual, and
	- using them explicitly in a unit test.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-19  Tom de Vries  <tdevries@suse.de>

	[gdbsupport] Use std::span-style iterators for gdb::array_view
	There's a plan to replace gdb::array_view with std::span (PR31422), and making
	gdb::array_view more like std::span helps with that.

	One difference is that std::span has:
	...
	constexpr iterator begin() const noexcept;
	constexpr const_iterator cbegin() const noexcept;
	...
	while gdb::array_view has:
	...
	constexpr T *begin () noexcept;
	constexpr const T *begin () const noexcept;
	...

	Fix this by renaming the second variant to cbegin, and making the first
	variant const.

	Likewise for gdb::array_view::end.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-19  Tom de Vries  <tdevries@suse.de>

	[gdb/guile, c++20] Work around Werror=volatile in libguile.h
	When building gdb with -std=c++20, I run into:
	...
	In file included from /usr/include/guile/2.0/libguile/__scm.h:479,
	                 from /usr/include/guile/2.0/libguile.h:31,
	                 from /data/vries/gdb/src/gdb/guile/guile-internal.h:30,
	                 from /data/vries/gdb/src/gdb/guile/guile.c:37:
	/usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \
	  scm_cell(scm_t_bits, scm_t_bits)’:
	/usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \
	  assignment with ‘volatile’-qualified left operand is deprecated \
	  [-Werror=volatile]
	   98 | #   define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
	      |                                            ~~~~~~~~~~~~~~~~~~~^~~~~
	...

	This was reported upstream [1].

	Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the
	default SCM_DEBUG_TYPING_STRICTNESS == 1.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR guile/30767
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767

	[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333

2024-10-19  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Skip local variables in cooked index
	Consider test-case gdb.dwarf2/local-var.exp.  The corresponding source
	contains a function with a local variable:
	...
	program test
	  logical :: local_var
	  local_var = .TRUE.
	end
	...

	Currently, the local variable shows up in the cooked index:
	...
	    [2] ((cooked_index_entry *) 0xfffec40063b0)
	    name:       local_var
	    canonical:  local_var
	    qualified:  local_var
	    DWARF tag:  DW_TAG_variable
	    flags:      0x2 [IS_STATIC]
	    DIE offset: 0xa3
	    parent:     ((cooked_index_entry *) 0xfffec4006380) [test]
	...
	making the cooked index larger than necessary.

	Fix this by skipping it in cooked_indexer::index_dies.

	Tested on aarch64-linux.

	PR symtab/32276
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276

2024-10-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-18  Tom Tromey  <tromey@adacore.com>

	Require a command argument in gdb.execute_mi
	Hannes pointed out that gdb.execute_mi() will crash.
	This patch fixes the bug.

	Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

2024-10-18  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Regenerate missing table files
	As soon as I committed Zhaoxin's patch, I realized that I did not
	include the regen file. Regenerate them and commit as obvious.

	opcodes/ChangeLog:

		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2024-10-18  MayShao-oc  <MayShao-oc@zhaoxin.com>

	x86: Support x86 ZHAOXIN GMI instructions
	gas/ChangeLog:

		* NEWS: Support ZHAOXIN GMI instructions.
		* config/tc-i386.c: Add gmi.
		* doc/c-i386.texi: Document gmi.
		* testsuite/gas/i386/i386.exp: Add gmi test.
		* testsuite/gas/i386/gmi.d: Ditto.
		* testsuite/gas/i386/gmi.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: New comment.
		* i386-gen.c: Add gmi.
		* i386-opc.h (CpuGMI): New.
		* i386-opc.tbl: Add Zhaoxin GMI instructions.
		* i386-tbl.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-init.h: Ditto.

2024-10-18  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	gprofng: fix a memory leak in the mxv-pthreads example
	Fix a bug where the main program does not free the rows of
	the matrix. The memory for thread_data_arguments is also
	not released. In function check_results, the memory for the
	marker vector is not released.
	The usage of the verbose veriable has been extended to
	print more messages.

	gprofng/ChangeLog
	2024-10-16  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		PR 32273
		PR 32274
		* mxv-pthreads/src/main.c: add calls to free() to
		release the memory allocated for array A and vector
		marker. Improve the usage of the verbose variable.
		* mxv-pthreads/src/manage_data.c: add a diagnostic
		printf statement.
		* mxv-pthreads/src/mydefs.h: adapt prototype to
		match the changes in main.c.

2024-10-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle bad alloc handling in gdb_bfd_open
	Say we simulate a bad alloc in gdb_bfd_init_data:
	...
	+  {
	+    static bool throw_bad_alloc = true;
	+    if (throw_bad_alloc)
	+      {
	+       throw_bad_alloc = false;
	+
	+       va_list dummy;
	+       throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
	+      }
	+  }
	   gdata = new gdb_bfd_data (abfd, st);
	...

	That works out fine for doing "file a.out" once:
	...
	$ gdb -q -batch -ex "file a.out"
	bad alloc
	$
	...
	but doing so twice get us:
	...
	$ gdb -q -batch -ex "file a.out" -ex "file a.out"
	bad alloc

	Fatal signal: Segmentation fault
	----- Backtrace -----
	0x5183f7 gdb_internal_backtrace_1
	        /home/vries/gdb/src/gdb/bt-utils.c:121
	0x5183f7 _Z22gdb_internal_backtracev
	        /home/vries/gdb/src/gdb/bt-utils.c:167
	0x62329b handle_fatal_signal
	        /home/vries/gdb/src/gdb/event-top.c:917
	0x6233ef handle_sigsegv
	        /home/vries/gdb/src/gdb/event-top.c:990
	0xfffeffba483f ???
	0x65554c eq_bfd
	        /home/vries/gdb/src/gdb/gdb_bfd.c:231
	0xeaca77 htab_find_with_hash
	        /home/vries/gdb/src/libiberty/hashtab.c:597
	0x657487 _Z12gdb_bfd_openPKcS0_ib
	        /home/vries/gdb/src/gdb/gdb_bfd.c:580
	0x6272d7 _Z16exec_file_attachPKci
	        /home/vries/gdb/src/gdb/exec.c:451
	0x627e67 exec_file_command
	        /home/vries/gdb/src/gdb/exec.c:550
	0x627f23 file_command
	        /home/vries/gdb/src/gdb/exec.c:565
	Segmentation fault (core dumped)
	$
	...

	The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache:
	...
	  if (bfd_sharing)
	    {
	      slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT);
	      gdb_assert (!*slot);
	      *slot = abfd;
	    }

	  gdb_bfd_init_data (abfd, &st);
	...
	while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is
	not properly initialized.

	Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after
	a successful call to gdb_bfd_init_data, such that we get:
	...
	$ gdb -q -batch -ex "file a.out" -ex "file a.out"
	bad alloc
	$
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Use -fno-hoist-adjacent-loads for gcc <= 13
	When building gdb with gcc 12 and -fsanitize=threads while renabling
	background dwarf reading by setting dwarf_synchronous to false, I run into:
	...
	(gdb) file amd64-watchpoint-downgrade
	Reading symbols from amd64-watchpoint-downgrade...
	(gdb) watch global_var
	==================
	WARNING: ThreadSanitizer: data race (pid=20124)
	  Read of size 8 at 0x7b80000500d8 by main thread:
	    #0 cooked_index_entry::full_name(obstack*, bool) const cooked-index.c:220
	    #1 cooked_index::get_main_name(obstack*, language*) const cooked-index.c:735
	    #2 cooked_index_worker::wait(cooked_state, bool) cooked-index.c:559
	    #3 cooked_index::wait(cooked_state, bool) cooked-index.c:631
	    #4 cooked_index_functions::wait(objfile*, bool) cooked-index.h:729
	    #5 cooked_index_functions::compute_main_name(objfile*) cooked-index.h:806
	    #6 objfile::compute_main_name() symfile-debug.c:461
	    #7 find_main_name symtab.c:6503
	    #8 main_language() symtab.c:6608
	    #9 set_initial_language_callback symfile.c:1634
	    #10 get_current_language() language.c:96
	    ...

	  Previous write of size 8 at 0x7b80000500d8 by thread T1:
	    #0 cooked_index_shard::finalize(parent_map_map const*) \
	         dwarf2/cooked-index.c:409
	    #1 operator() cooked-index.c:663
	    ...

	  ...

	SUMMARY: ThreadSanitizer: data race cooked-index.c:220 in \
	  cooked_index_entry::full_name(obstack*, bool) const
	==================
	Hardware watchpoint 1: global_var
	(gdb) PASS: gdb.arch/amd64-watchpoint-downgrade.exp: watch global_var
	...

	This was also reported in PR31715.

	This is due do gcc PR110799 [1], generating wrong code with
	-fhoist-adjacent-loads, and causing a false positive for
	-fsanitize=threads.

	Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13
	and -fsanitize=threads.

	Tested in that same configuration on x86_64-linux.  Remaining ThreadSanitizer
	problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and
	PR32247 (gdb.trace/basic-libipa.exp).

	PR gdb/31715
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31715

	Tested-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799

2024-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix qualified name for cooked index dump
	While looking at the cooked index entry for local variable l4 of function test
	in test-case gdb.fortran/logical.exp:
	...
	$ gdb -q -batch outputs/gdb.fortran/logical/logical \
	  -ex "maint print objfiles"
	  ...
	    [9] ((cooked_index_entry *) 0x7fc6e0003010)
	    name:       l4
	    canonical:  l4
	    qualified:  l4
	    DWARF tag:  DW_TAG_variable
	    flags:      0x2 [IS_STATIC]
	    DIE offset: 0x17c
	    parent:     ((cooked_index_entry *) 0x7fc6e0002f20) [test]
	...
	I noticed that while the entry does have a parent, that's not reflected in the
	qualified name.

	This makes it harder to write test-cases that check the parent of a cooked
	index entry.

	This is due to the implementation of full_name, which skips printing
	parents if the language does not specify an appropriate separator.

	Fix this by using "::" as default separator, getting us instead:
	...
	    [9] ((cooked_index_entry *) 0x7f94ec0040c0)
	    name:       l4
	    canonical:  l4
	    qualified:  test::l4
	    DWARF tag:  DW_TAG_variable
	    flags:      0x2 [IS_STATIC]
	    DIE offset: 0x17c
	    parent:     ((cooked_index_entry *) 0x7f94ec003fd0) [test]
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix regression in man page installation
	gprofng/ChangeLog
	2024-10-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* doc/Makefile.am: Use install-data-local to install gprofng examples.
		* doc/Makefile.in: Rebuild.

2024-10-17  Michael Matz  <matz@suse.de>

	Fix for -Wstringop-overflow false positive
	the way the overflow check was written wasn't understood by some
	GCC versions and produced false positives for the memset call being
	called potentially with object sizes that are larger than half
	address-space.

2024-10-17  Michael Matz  <matz@suse.de>

	PR32260: Improve error handling on string merging
	if the input sections are near the max supported size (4G)
	we might fail to enlarge the hash table.  The error handling
	for this case didn't quite work.  When this happens we can
	gracefully fall back to just not deduplicate this section
	(and continue with further mergable sections).  We were mixing
	that with the case of not being able to even allocate a small
	structure (in which case we can as well error out completely),
	this disentables both cases.

		bfd/

		PR ld/32260
		* merge.c (sec_merge_maybe_resize): Check overflow in ultimate
		target type.
		(record_section): Return three-state, use new state when unable
		to enlarge hash table.
		(_bfd_merge_sections): Remove current section from merging
		consideration when hashtable can't be enlarged.

2024-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/fixed_points.exp for gcc < 10
	When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
	into:
	...
	(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
	get_compiler_info: gcc-7-5-0
	p Float(Another_Fixed) = Float(Another_Delta * 5)^M
	No definition of "another_delta" in current context.^M
	(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
	...

	This is a regression since commit 1411185a57e ("Introduce and use
	gnat_version_compare"), which did:
	...
	     # This failed before GCC 10.
	-    if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
	+    if {$scenario == "all" && [gnat_version_compare < 10]} {
	 	gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
	 	    "value of another_fixed"
	     }
	...

	Fix this by using gnat_version_compare >= 10 instead.

	Tested on x86_64-linux, with gcc 7 - 13.

2024-10-17  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Check PC-relative relocations for shared libraries
	Building shared libraries should not be allowed for PC-relative
	relocations against external symbols.
	Currently LoongArch has no corresponding checks and silently
	generates wrong shared libraries.

	However, In the first version of the medium cmodel, pcalau12i+jirl was
	used for function calls, in which case PC-relative relocations were
	allowed.

2024-10-17  kamathforaix  <aditya.kamath1@ibm.com>

	Add myself to gdb/MAINTAINERS

2024-10-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-16  Andreas Schwab  <schwab@suse.de>

	gprofng: use xmalloc/xrealloc/xcalloc/xstrdup/xstrndup from libiberty
		PR gprofng/32241
		* src/Makefile.am (CSOURCES): Remove dbe_memmgr.c
		* src/Makefile.in: Regenerate.
		* src/dbe_memmgr.c: Remove.
		* src/gprofng.cc (main): Call xmalloc_set_program_name.
		* src/gp-archive.cc (main): Likewise.
		* src/gp-collect-app.cc (main): Likewise.
		* src/gp-display-src.cc (main): Likewise.
		* src/gp-display-text.cc (main): Likewise.
		* src/Application.cc: Use xmalloc, xrealloc, xcalloc, xstrdup,
		xstrndup instead of malloc, realloc, calloc, strdup, strndup.
		* src/BaseMetric.cc: Likewise.
		* src/CallStack.cc: Likewise.
		* src/ClassFile.cc: Likewise.
		* src/Data_window.cc: Likewise.
		* src/Dbe.cc: Likewise.
		* src/DbeJarFile.cc: Likewise.
		* src/DbeSession.cc: Likewise.
		* src/DbeView.cc: Likewise.
		* src/DerivedMetrics.cc: Likewise.
		* src/DwarfLib.cc: Likewise.
		* src/Elf.cc: Likewise.
		* src/Emsg.cc: Likewise.
		* src/Experiment.cc: Likewise.
		* src/Function.cc: Likewise.
		* src/Module.cc: Likewise.
		* src/Print.cc: Likewise.
		* src/QLParser.yy: Likewise.
		* src/SAXParserFactory.cc: Likewise.
		* src/Settings.cc: Likewise.
		* src/SourceFile.cc: Likewise.
		* src/StringBuilder.cc: Likewise.
		* src/StringMap.h: Likewise.
		* src/Table.cc: Likewise.
		* src/checks.cc: Likewise.
		* src/collctrl.cc: Likewise.
		* src/comp_com.c: Likewise.
		* src/count.cc: Likewise.
		* src/envsets.cc: Likewise.
		* src/gp-archive.cc: Likewise.
		* src/gp-display-src.cc: Likewise.
		* src/gp-display-text.cc: Likewise.
		* src/gprofng.cc: Likewise.
		* src/ipc.cc: Likewise.
		* src/ipcio.cc: Likewise.
		* src/vec.h: Likewise.
		* src/util.cc: Likewise.
		(get_prog_name): Remove.
		* src/util.h: Likewise.
		* src/dbe_hwc.h (malloc, realloc, calloc, strdup): Define.

2024-10-16  Alan Modra  <amodra@gmail.com>

	Assertion fail at peicode.h:607
	This is the assertion that vars->string_ptr < vars->end_string_ptr,
	ie. when it fails we've overflowed the string buffer area.  Caused by
	allocating space for import_name but writing symbol_name, and they can
	be different.

		* peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change.

2024-10-16  Alan Modra  <amodra@gmail.com>

	Add noxfail option to run_dump_test
	The noxfail option is useful in situations like pr23658-1e which
	fails on all microblaze ELF targets except microblaze-linux.  This was
	possible to handle by writing a small proc and use that as an xfail
	predicate, or painstakingly listing all microblaze ELF targets, but
	this is simpler.  The patch also fixes some other FAILs and XPASSes of
	the pr23658 tests.

	binutils/
		* testsuite/lib/binutils-common.exp (run_dump_test): Support
		noxfail.
	ld/
		* testsuite/ld-elf/pr23658-1a.d: Don't xfail m68hc12.
		* testsuite/ld-elf/pr23658-1e.d: Likewise.  xfail xstormy16
		and correct microblaze xfails.

2024-10-16  Alan Modra  <amodra@gmail.com>

	PR32266, segv when linking libclang_rt.asan-powerpc64.so
	Change the mmap support added with commit 9ba56acee518 to always mmap
	memory with PROT_READ | PROT_WRITE.  Prior to that commit most file
	contents were read into a buffer allocated with bfd_alloc or
	bfd_malloc and thus the memory was read/write.  Even after that commit
	any section contents with relocations must be read/write to apply the
	relocs.  Making them all read/write is not a major change, and it
	should not introduce any measurable linker slowdown for contents that
	are not modified.  More importantly, it removes a BFD behaviour
	difference that only triggers when large files are involved.

		PR 32266
		PR 32109
		* libbfd.c (bfd_mmap_local): Remove prot param.  Always mmap
		with PROT_READ | PROT_WRITE.  Adjust all calls.
		(_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary.
		(_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary.
		_bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent.
		(_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE
		regardless of relocs.
		* libbfd-in.h: Update decls to suit.  Make non-USE_MMAP variants
		static inline functions.
		* elflink.c: Update all uses of _bfd_mmap functions.
		* elf.c: Likewise.
		(bfd_elf_get_str_section): Revert commit 656f8fbaae.
		* libbfd.h: Regenerate.

2024-10-16  Liwei Xu  <liwei.xu@intel.com>
	    Kong Lingling  <lingling.kong@intel.com>
	    Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AVX10.2 convert instructions
	In this patch, we will support AVX10.2 convert instructions. All
	of them are new instruction forms.

	Among all the instructions, vcvtbiasph2[b,h]f8[,s] needs extra care.
	Since Operand 2 could indicate memory size, we do not need suffix
	under ATTmode. However, we could not fold all three templates but only
	XMM/YMM since the dst operand size are the same for them. Also, a new
	iterator <cvt8> is added to reduce redundancy.

	gas/
		* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-256-cvt-intel.d: New.
		* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-cvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto.

	opcodes/
		* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F3874,
		PREFIX_EVEX_MAP5_18, PREFIX_EVEX_MAP5_1B,
		PREFIX_EVEX_MAP5_1E and PREFIX_EVEX_MAP5_74.
		* i386-dis-evex.h: Add table pass for AVX10.2
		instructions.
		* i386-dis.c (MOD_EVEX_0F38B1): New.
		(PREFIX_EVEX_0F3874): Ditto.
		(PREFIX_EVEX_MAP5_18): Ditto.
		(PREFIX_EVEX_MAP5_1B): Ditto.
		(PREFIX_EVEX_MAP5_1E): Ditto.
		(PREFIX_EVEX_MAP5_74): Ditto.
		* i386-opc.tbl: Add AVX10.2 instructions.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-10-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-15  Tom Tromey  <tromey@adacore.com>

	Introduce and use gnat_version_compare
	While testing a modified GNAT, I found that this test in
	fun_renaming.exp was returning 0 for GCC 13:

	    if {[test_compiler_info {gcc-6*}]}

	This patch introduces a new, more robust way to check the GNAT
	compiler version, and changes the gda.ada tests to use it.  A small
	update to version_compare was also needed.

	Note that, in its current form, this new code won't really interact
	well with non-GCC compilers (specifically gnat-llvm).  This doesn't
	seem like a major issue at this point, though, because gnat-llvm
	doesn't properly emit debuginfo yet, and when it does, more changes
	will be needed in these tests anyway.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-10-15  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add more relaxation support for call36
	Add relaxation support for call36 that jump to PLT entry.

	Add relaxation support for call36 with IFUNC symbol.

	Add relaxation support for call36 that jump to undefweak symbol.
	For undefweak symbol, it can always be relaxed if it have no PLT entry.
	Because we set the address of undefweak symbol without PLT entry to PC
	like relocate_section.

2024-10-15  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Optimize the relaxation process
	The symbol value is only calculated when the relocation can be relaxed.

2024-10-15  Cui, Lili  <lili.cui@intel.com>

	x86: Refine instruction check in x86_check_tls_relocation
	gas/ChangeLog:

	        * config/tc-i386.c
		(x86_check_tls_relocation): Refine instruction check.

2024-10-15  Haochen Jiang  <haochen.jiang@intel.com>

	x86/testsuite: Rename AVX10.2 media testcases
	Change these testcase name to make them clearer.

	gas/ChangeLog:

		* testsuite/gas/i386/avx10_2-256-1-intel.d: Renamed to...
		* testsuite/gas/i386/avx10_2-256-media-intel.d: ...this.
		* testsuite/gas/i386/avx10_2-256-1.d: Renamed to...
		* testsuite/gas/i386/avx10_2-256-media.d: ...this.
		* testsuite/gas/i386/avx10_2-256-1.s: Renamed to...
		* testsuite/gas/i386/avx10_2-256-media.s: ...this.
		* testsuite/gas/i386/avx10_2-512-1-intel.d: Renamed to...
		* testsuite/gas/i386/avx10_2-512-media-intel.d: ...this.
		* testsuite/gas/i386/avx10_2-512-1.d: Renamed to...
		* testsuite/gas/i386/avx10_2-512-media.d: ...this.
		* testsuite/gas/i386/avx10_2-512-1.s: Renamed to...
		* testsuite/gas/i386/avx10_2-512-media.s: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-256-media-intel.d: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-256-1.d: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-256-media.d: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-256-1.s: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-256-media.s: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-512-media-intel.d: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-512-1.d: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-512-media.d: ...this.
		* testsuite/gas/i386/x86-64-avx10_2-512-1.s: Renamed to...
		* testsuite/gas/i386/x86-64-avx10_2-512-media.s: ...this.
		* testsuite/gas/i386/i386.exp: Change testcase name.
		* testsuite/gas/i386/x86-64.exp: Ditto.

2024-10-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-14  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: fix gdb.multi/inferior-specific-bp.exp
	A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations
	calls in update_breakpoint_locations", started checking if GDB correctly
	relocates a breakpoint from inferior 1's declaration of the function
	"bar" to inferior 2's declaration.

	Unfortunately, inferior 2 never calls bar in its regular execution, and
	because of that, clang would optimize that whole function away, making
	it so there is no location for the breakpoint to be relocated to.

	This commit changes the .c file so that the function is not optimized
	away and the test fully passes with clang. It is important to actually
	call bar instead of using __attribute__((used)) because the latter
	causes the breakpoint locations to be inverted, 3.1 belongs to inferior
	2 and 3.2 belongs to inferior 1, which will cause an unrelated failure.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-14  Jan Beulich  <jbeulich@suse.com>

	ia64/ELF: fix HPUX testsuite fallout
	... from 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object
	files"), as noticed / reported by Alan.

	x86: also template-expand trailing mnemonic part
	So far template expansion was limited to fields other than the insn
	mnemonic. In order to be able to use <fop> also for AVX10.2 we want the
	trailing mnemonic part to also be expanded. Split out the respective
	piece of code into a helper function, which is then invoked twice.

	gas: drop SKIP_WHITESPACE_AFTER_NAME()
	Exclusively all users should use restore_line_pointer() instead, at
	which point SKIP_WHITESPACE() suffices as a check afterwards.

2024-10-14  Guinevere Larsen  <guinevere@redhat.com>

	gdb: make frame_unwind_try_unwinder return bool
	Before this commit, the function frame_unwind_try_unwinder would return
	an int, where 1 meant the unwinder works, and 0 it doesn't. This is just
	a boolean with extra steps, so this commit updates the function to
	return bool instead.

2024-10-14  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fixed R_LARCH_[32/64]_PCREL generation bug
	The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead
	of the relocation in fixp. This can cause the second relocation
	of a pair to be deleted when -mthin-add-sub is enabled. Apply the
	correct macro to fix this.

	Also sets the initial value of -mthin-add-sub.

2024-10-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32110 gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary
	gprofng does not handle DW_FORM_strx1* forms correctly.

	gprofng/ChangeLog
	2024-10-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32110
		* src/DwarfLib.cc: Handle DW_FORM_strx* forms.

2024-10-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-12  Robert Guthrie  <forkbombidable@gmail.com>  (tiny change)

	Add to GDB manual information about building index with 'gold'
	* gdb/doc/gdb.texinfo (Index Files): New subsection about building
	the index using 'gold'.

2024-10-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-11  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: remove declaration of init_registers_arm_with_neon
	The last use of init_registers_arm_with_neon was removed in this
	commit:

	  commit 7cc17433020a62935e4d91053251fe900d83c7f0
	  Date:   Fri Jul 19 15:04:48 2019 +0100

	      Arm: Use read_description funcs in gdbserver

	But the declaration was left around.  Remove the declaration now.

2024-10-11  Andrew Burgess  <aburgess@redhat.com>

	Revert "gdbserver: pass osabi to GDB in target description"
	This reverts commit 98bcde5e268ea7cd54186c5f2c27c65103218fc3.  This
	commit was causing build problems on at least sparc, ppc, and s390,
	though I suspect some other targets might be impacted too.

2024-10-11  Jan Beulich  <jbeulich@suse.com>

	x86: bring 64-bit-only cmdline option handling in sync
	--64 and --x32 are already suppressed in --help output when BFD64 is not
	defined. Also avoid recognizing these options in such configurations.

	bfd/ELF: drop align_file_position()
	Switch the sole user to BFD_ALIGN() instead. (It's comment was partly
	wrong [stale?] anyway, talking of some maximum that was nowhere in
	sight.)

	bfd/ELF: restrict file alignment for object files
	While for executables properly aligning sections within the file can be
	quite relevant, the same is of pretty little importance for relocatable
	object files. Avoid passing "true" into
	_bfd_elf_assign_file_position_for_section() when dealing with object
	files, but compensate minimally by applying log_file_align in such
	cases as a cap to the alignment put in place.

2024-10-11  Haochen Jiang  <haochen.jiang@intel.com>
	    Lili Cui  <lili.cui@intel.com>

	Support Intel AVX10.2 media instructions
	In disassembler part, for vnni instructions, we extended previous
	VEX part using %XE in disassembler to promote them to EVEX by reusing
	the original VEX table. For vmpsadbw, we will also use %XE. However,
	it is hard to reuse the VEX table, so we are using new ones.

	In assmbler part, we put the vnni table entries with previous vnni
	instructions since they are just promotion from AVX-VNNI-INT{8,16}.
	Since we will prefer VEX encoding, we need to use the different table
	order in template <vnni>, which prefers EVEX due to earlier introduction
	for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. For vdpphps
	and vmpsadbw, we put them at the end of the table, with future AVX10.2
	instructions.

	Nit: I will remove the arch requirement for avx_vnni_int{8,16} in
	evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}.

	gas/Changelog:

		* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-256-1-intel.d: New.
		* testsuite/gas/i386/avx10_2-256-1.d: Ditto.
		* testsuite/gas/i386/avx10_2-256-1.s: Ditto.
		* testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-1.d: Ditto.
		* testsuite/gas/i386/avx10_2-512-1.s: Ditto.
		* testsuite/gas/i386/avx10_2-promote.d: Ditto.
		* testsuite/gas/i386/avx10_2-promote.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto.

	opcodes/Changelog:

		* i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852.
		Add PREFIX_EVEX_0F3A42_W_0.
		* i386-dis-evex-w.h: Adjust EVEX_W_0F3A42.
		* i386-dis-evex.h: Add table pass for AVX10.2
		instructions.
		* i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0,
		PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0.
		* i386-opc.tbl: Add AVX10.2 instructions.
		* i386-mnem.h: Regenerated.
		* i386-tbl.h: Ditto.

2024-10-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-10  H.J. Lu  <hjl.tools@gmail.com>

	gprofng: Use $(DESTDIR) in install-examples
	Use $(DESTDIR) in install-examples to fix

	mkdir -p -- /usr/share/doc//gprofng
	mkdir: cannot create directory ‘/usr/share/doc//gprofng’: Permission denied

	for "make install DESTDIR=...".

		* doc/Makefile.am (install-examples): Use $(DESTDIR).
		* doc/Makefile.in: Regenerated.

2024-10-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: install examples to $(docdir)/gprofng
	gprofng/ChangeLog
	2024-10-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* doc/Makefile.am: Install gprofng examples.
		* doc/Makefile.in: Rebuild.

2024-10-10  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: pass osabi to GDB in target description
	On a Windows machine I built gdbserver, configured for the target
	'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
	support for all target (--enable-targets=all).

	On the Windows machine I start gdbserver with a small test binary:

	  $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe

	On the GNU/Linux machine I start GDB without the test binary, and
	connect to gdbserver.

	As I have not given GDB the test binary, my expectation is that GDB
	would connect to gdbserver and then download the file over the remote
	protocol, but instead I was presented with this message:

	  (gdb) target remote 192.168.129.25:54321
	  Remote debugging using 192.168.129.25:54321
	  warning: C:\some\directory\executable.exe: No such file or directory.
	  0x00007ffa3e1e1741 in ?? ()
	  (gdb)

	What I found is that if I told GDB where to find the binary, like
	this:

	  (gdb) file target:C:/some/directory/executable.exe
	  A program is being debugged already.
	  Are you sure you want to change the file? (y or n) y
	  Reading C:/some/directory/executable.exe from remote target...
	  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
	  Reading C:/some/directory/executable.exe from remote target...
	  Reading symbols from target:C:/some/directory/executable.exe...
	  (gdb)

	then GDB would download the executable.

	I eventually tracked the problem down to exec_file_find (solib.c).
	The remote target was passing an absolute Windows filename (beginning
	with "C:/" in this case), but in exec_file_find GDB was failing the
	IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
	relative.

	The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
	the file system kind was "unix", and as the filename didn't start with
	a "/" it assumed the filename was not absolute.

	But I'm connecting to a Windows target, my 'target-file-system-kind'
	was set to "auto", so should be figuring out that my file-system is
	"dos-based".

	Looking in effective_target_file_system_kind (filesystem.c), we find
	that the logic of "auto" is delegated to the current gdbarch.  However
	in windows-tdep.c we see:

	  set_gdbarch_has_dos_based_file_system (gdbarch, 1);

	So if we are using a Windows gdbarch we should have "dos-based"
	filesystems.  What this means is that after connecting to the remote
	target GDB has selected the wrong gdbarch.

	What's happening is that the target description sent back by the
	remote target only includes the x86-64 registers.  There's no
	information about which OS we're on.  As a consequence, GDB picks the
	first x86-64 gdbarch which can handle the provided register set, which
	happens to be a GNU/Linux gdbarch.

	And indeed, there doesn't appear to be anywhere in gdbserver that sets
	the osabi on the target descriptions, though some target descriptions
	do have their osabi set when the description is created, e.g. in:

	  gdb/arch/amd64.c	- Sets GNU/Linux osabi when appropriate.
	  gdb/arch/i386.c	- Likewise.
	  gdb/arch/tic6x.c	- Always set GNU/Linux osabi.

	Most target descriptions are created without an osabi, gdbserver does
	nothing to fix this, and the description is returned to GDB without an
	osabi included.

	I propose that we always set the osabi name on the target descriptions
	returned from gdbserver.  We could try to do this when the description
	is first created, but that would mean passing extra flags into the
	tdesc creation code (or just passing the osabi string in), and I don't
	think that's really necessary.  If we consider the tdesc creation as
	being about figuring out which registers are on the target, then it
	makes sense that the osabi information is injected later.

	So what I've done is require the osabi name to be passed to the
	init_target_desc function.  This is called, I believe, for all
	targets, in the gdbserver code.

	Now when I connect to the Windows remote the target description
	returned includes the osabi name.  With this extra information GDB
	selects the correct gdbarch object, which means that GDB understands
	the target has a "dos-based" file-system.  With that correct GDB
	understands that the filename it was given is absolute, and so fetches
	the file from the remote as we'd like.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: change shared set_tdesc_osabi to take gdb_osabi
	There is a single declaration of set_tdesc_osabi that is shared
	between gdbserver/ and gdb/, this declaration takes a 'const char *'
	argument which is the string representing an osabi.

	Then in gdb/ we have an overload of set_tdesc_osabi which takes an
	'enum gdb_osabi'.

	In this commit I change the shared set_tdesc_osabi to be the version
	which takes an 'enum gdb_osabi', and I remove the version which takes
	a 'const char *'.  All users of set_tdesc_osabi are updated to pass an
	'enum gdb_osabi'.

	The features/ code, which is generated from the xml files, requires a
	new function to be added to osabi.{c,h} which can return a string
	representation of an 'enum gdb_osabi'.  With that new function in
	place the features/ code is regenerated.

	This change is being made to support the next commit.  In the next
	commit gdbserver will be updated to call set_tdesc_osabi in more
	cases.  The problem is that gdbserver stores the osabi as a string.
	The issue here is that a typo in the gdbserver/ code might go
	unnoticed and result in gdbserver sending back an invalid osabi
	string.

	To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
	set_tdesc_osabi function.  With that requirement in place it seems to
	make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.

	There should be no user visible changes after this commit.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: split osabi support between gdb/ and gdbsupport/ directories
	In future commits I want to call set_tdesc_osabi from gdbserver/
	code.  Currently the only version of set_tdesc_osabi available to
	gdbserver takes a string representing the osabi.

	The problem with this is that, having lots of calls to set_tdesc_osabi
	which all take a string is an invite for a typo to slip in.  This typo
	could potentially go unnoticed until someone tries to debug the wrong
	combination of GDB and gdbserver, at which point GDB will fail to find
	the correct gdbarch because it doesn't understand the osabi string.

	It would be better if the set_tdesc_osabi calls in gdbserver could
	take an 'enum gdb_osabi' value and then convert this to the "correct"
	string internally.  In this way we are guaranteed to always have a
	valid, known, osabi string.

	This commit splits the osabi related code, which currently lives
	entirely on the GDB side, between gdb/ and gdbsupport/.  I've moved
	the enum definition along with the array of osabi names into
	gdbsupport/.  Then all the functions that access the names list, and
	which convert between names and enum values are also moved.

	I've taken the opportunity of this move to add a '.def' file which
	contains all the enum names along with the name strings.  This '.def'
	file is then used to create 'enum gdb_osabi' as well as the array of
	osabi name strings.  By using a '.def' file we know that the enum
	order will always match the name string array.

	This commit is just a refactor, there are no user visible changes
	after this commit.  This commit doesn't change how gdbserver sets the
	target description osabi string, that will come in the next commit.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: make use of set_tdesc_osabi overload in features/ files
	There are two versions of the set_tdesc_osabi function in GDB:

	  void
	  set_tdesc_osabi (struct target_desc *target_desc, const char *name)
	  {
	    set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name));
	  }

	  void
	  set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi)
	  {
	    target_desc->osabi = osabi;
	  }

	In the gdb/features/ files we call the second of these functions, like
	this:

	  set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux"));

	This can be replaced with a call to the first set_tdesc_osabi
	function, so lets do that.  I think that this makes the features/ code
	slightly simpler and easier to understand.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-10  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr<char>
	Convert target_desc::arch and target_desc::osabi from 'const char*' to
	gdb::unique_xmalloc_ptr<char>.  This also allows us to remove the user
	defined ~target_desc destructor.

	I doubt it ever actually occurred, but in theory at least, there was a
	memory leak in set_tdesc_architecture and set_tdesc_osabi where the
	member variables were assigned without freeing any previous
	value... but I suspect that usually these fields are only set once.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-10-10  Tom de Vries  <tdevries@suse.de>

	[gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linux
	On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
	...
	(gdb) awatch a^M
	Can't set read/access watchpoint when hardware watchpoints are disabled.^M
	(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
	rwatch b^M
	Can't set read/access watchpoint when hardware watchpoints are disabled.^M
	(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
	continue^M
	Continuing.^M
	^M
	Program received signal SIGSEGV, Segmentation fault.^M
	0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
	(gdb) FAIL: $exp: continue until exit
	...

	Using "maint info break", we can see that the two failed attempts to set a
	watchpoint each left behind a stale "watchpoint scope" breakpoint:
	...
	-5      watchpoint scope del  y   0xf7ec569a  inf 1
	-5.1                          y   0xf7ec569a  inf 1
		stop only in stack frame at 0xfffef4f8
	-6      watchpoint scope del  y   0xf7ec569a  inf 1
	-6.1                          y   0xf7ec569a  inf 1
		stop only in stack frame at 0xfffef4f8
	...

	The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
	same happens if we:
	- have can-use-hw-watchpoints == 1,
	- set one of the watchpoints, and
	- continue to exit.
	The problem is missing symbol info on libc which is supposed to tell which
	code is thumb.  After doing "set arm fallback-mode thumb" the SIGSEGV
	disappears.

	Extend the test-case to check the "maint info break" command before and after
	the two failed attempts, to make sure that we catch the stale
	"watchpoint scope" breakpoints also on x86_64-linux.

	Fix this in watch_command_1 by moving creation of the "watchpoint scope"
	breakpoint after the call to update_watchpoint.

	Tested on x86_64-linux.

	PR breakpoints/31860
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860

2024-10-10  Andreas Krebbel  <krebbel@linux.ibm.com>

	s390: Add arch15 instructions
	opcodes/
		* s390-mkopc.c (main) Accept arch15 as CPU string.
		* s390-opc.txt: Add arch15 instructions.

	include/
		* opcode/s390.h (enum s390_opcode_cpu_val): Add
		S390_OPCODE_ARCH15.

	gas/
		* config/tc-s390.c (s390_parse_cpu): New entry for arch15.
		* doc/c-s390.texi: Document arch15 march option.
		* doc/as.texi: Likewise.
		* testsuite/gas/s390/s390.exp: Run the arch15 related tests.
		* testsuite/gas/s390/zarch-arch15.d: Tests for arch15
		instructions.
		* testsuite/gas/s390/zarch-arch15.s: Likewise.

	Reviewed-by: Jens Remus <jremus@linux.ibm.com>

2024-10-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clang
	When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
	...
	FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
	FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
	FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
	FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
	...

	The problem is that the debug info produced by clang does not contain any
	references to enumerators val1 and val2, or the corresponding enumeration
	types.

	Instead, the variables u1 and u2 are considered to be simply of type int:
	...
	 <1><fb>: Abbrev Number: 2 (DW_TAG_variable)
	    <fc>   DW_AT_name        : u1
	    <fd>   DW_AT_type        : <0x106>
	    <101>   DW_AT_external    : 1
	    <103>   DW_AT_location    : (DW_OP_addrx <0>)
	 <1><106>: Abbrev Number: 3 (DW_TAG_base_type)
	    <107>   DW_AT_name        : int
	    <108>   DW_AT_encoding    : 5       (signed)
	    <109>   DW_AT_byte_size   : 4
	 <1><10a>: Abbrev Number: 2 (DW_TAG_variable)
	    <10b>   DW_AT_name        : u2
	    <10c>   DW_AT_type        : <0x106>
	    <110>   DW_AT_external    : 1
	    <112>   DW_AT_location    : (DW_OP_addrx <0x1>)
	...

	Fix this by checking whether val1 and val2 are present in the cooked index
	before checking whether they have the correct parent.

	This cannot be expressed efficiently with gdb_test_lines, so factor out
	gdb_get_lines and use that instead.

	The test-case still calls "maint print objfiles" twice, but the first time is
	for have_index.  We should probably use a gdb_caching_proc for this.

	Tested on aarch64-linux.

	Reported-By: Guinevere Larsen <guinevere@redhat.com>
	Reviewed-By: Keith Seitz <keiths@redhat.com>
	Tested-By: Guinevere Larsen <guinevere@redhat.com>

2024-10-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1
	I ran the testsuite in an environment simulating a stressed system in
	combination with check-read1.  This exposes a few more FAILs.

	Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.

	Tested on x86_64-linux.

2024-10-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1
	On aarch64-linux, with make target check-read1, I run into:
	...
	(gdb) info reg vector^M
	  ...
	d19            {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
	 0, u = 0, s = 0}^M
	...

	The problem is that while (as documented) the corresponding gdb_test_multiple
	doesn't work for vector registers, it doesn't skip them either.  This causes
	the timeout, and it also causes the registers after a vector register not to
	be found.

	Fix this by using -lbl style matching.

	Make which reggroups and registers are found more explicit using verbose -log,
	which makes us notice that regnames with underscores are skipped, so fix that
	as well.

	While we're at it, this:
	...
	set invalid_register_re "Invalid register .*"
	...
	and this:
	...
	       -re $invalid_register_re {
	           fail "$test (unexpected invalid register response)"
	       }
	...
	means that the prompt may or may not be consumed.  Fix this by limiting the
	regexp to one line, and using exp_continue.

	While we're at it, improve readability of the complex regexp matching a single
	register by factoring out regexps.

	Tested on aarch64-linux and x86_64-linux.

2024-10-09  Alan Modra  <amodra@gmail.com>

	PR32243, NAME_MAX does not exist on mingw-w64 without _POSIX_
		PR 32243
		* dlltool.c: Move forward decls.  Delete unnecessary ones.
		(bfd_errmsg): Delete macro, define as inline function.
		(PATHMAX): Delete.
		(NAME_MAX): Define.

2024-10-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-09  Tom Tromey  <tom@tromey.com>

	Use ui-out tables in "maint print user-regs"
	This changes "maint print user-regs" to use ui-out tables rather than
	printfs.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-09  Tom Tromey  <tom@tromey.com>

	Use ui-out tables for info proc mappings
	This changes a few implementations of "info proc mappings" to use
	ui-out tables rather than printf.

	Note that NetBSD and FreeBSD also use printfs here, but since I can't
	test these, I didn't update them.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1
	When running test-case gdb.base/break-interp.exp with check-read1, I run into:
	...
	(gdb) info files^M
	  ...
		0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
	pieNO.d/libc.so.6^M
	...

	The code has two adaptations to deal with the large output:
	- nested gdb_test_multiple, and
	- an exp_continue in the inner gdb_test_multiple.

	The former seems unnecessary, and the latter doesn't trigger often enough
	because of an incomplete hex number regexp, causing the timeout.

	Get rid of both of these, and use -lbl instead.

	Tested on x86_64-linux.

2024-10-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: include --enable-targets in 'show configuration' output
	Include the value of configuration flag --enable-targets in the output
	of GDB command 'show configuration' and also in the output printed for
	'gdb --configuration'.  This will make it easier to see how GDB was
	built.

	No tests added or updated as we can't really check for a specific flag
	appearing or not appearing on the configuration output.  But we do
	print the configuration within lib/gdb.exp to check which features are
	built into GDB, so if this change broke configuration printing then
	plenty of tests should stop working (they don't).

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations
	The commit:

	  commit 6cce025114ccd0f53cc552fde12b6329596c6c65
	  Date:   Fri Mar 3 19:03:15 2023 +0000

	      gdb: only insert thread-specific breakpoints in the relevant inferior

	added a couple of calls to breakpoint::clear_locations() inside
	update_breakpoint_locations().

	The intention of these calls was to avoid leaving redundant locations
	around when a thread- or inferior-specific breakpoint was switched
	from one thread or inferior to another.

	Without the clear_locations() calls the tests gdb.multi/tids.exp and
	gdb.multi/pending-bp.exp have some failures.  A b/p is changed such
	that the program space it is associated with changes.  This triggers a
	call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
	the new program space.  As a result GDB correctly calculates the new
	locations and adds these to the breakpoint, but the old locations, in
	the old program space, are incorrectly retained.  The call to
	clear_locations() solves this by deleting the old locations.

	However, while working on another patch I realised that the approach
	taken here is not correct.  The FILTER_PSPACE argument passed to
	breakpoint_re_set_one() and then on to update_breakpoint_locations()
	might not be the program space to which the breakpoint is associated.
	Consider this example:

	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) start
	  Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
	  Starting program: /tmp/hello.x

	  Temporary breakpoint 1, main () at hello.c:18
	  18	  printf ("Hello World\n");
	  (gdb) break main thread 1
	  Breakpoint 2 at 0x401198: file hello.c, line 18.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   0x0000000000401198 in main at hello.c:18
	  	stop only in thread 1
	  (gdb) add-inferior -exec /tmp/hello.x
	  [New inferior 2]
	  Added inferior 2 on connection 1 (native)
	  Reading symbols from /tmp/hello.x...
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address    What
	  2       breakpoint     keep y   <PENDING>  main
	  	stop only in thread 1.1

	Notice that after creating the second inferior and loading a file the
	thread-specific breakpoint was incorrectly made pending.  Loading the
	exec file in the second inferior triggered a call to
	breakpoint_re_set() with the new, second, program space as the
	current_program_space.

	This program space ends up being passed to
	update_breakpoint_locations().

	In update_breakpoint_locations this condition is true:

	  if (all_locations_are_pending (b, filter_pspace) && sals.empty ())

	and so we end up discarding all of the locations for this breakpoint,
	making the breakpoint pending.

	What we really want to do in update_breakpoint_locations() is, for
	thread- or inferior- specific breakpoints, delete any locations which
	are associated with a program space that this breakpoint is NOT
	associated with.

	But then I realised the answer was easier than that.

	The ONLY time that a b/p can have locations associated with the
	"wrong" program space like this is at the moment we change the thread
	or inferior the b/p is associated with by calling
	breakpoint_set_thread() or breakpoint_set_inferior().

	And so, I think the correct solution is to hoist the call to
	clear_locations() out of update_breakpoint_locations() and place a
	call in each of the breakpoint_set_{thread,inferior} functions.

	I've done this, and added a couple of new tests.  All of which are
	now passing.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnow
	When running test-case gdb.ada/tagged-lookup.exp with target board readnow and
	make target check-read1:
	...
	$ ( cd build/gdb; \
	    make check-read1 \
	      RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" )
	...
	I run into:
	...
	(gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1
	print *the_local_var^M
	$1 = (n => 2)^M
	(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
	...

	The problem is that the corresponding gdb_test_multiple uses line-by-line
	matching (using -lbl) which doesn't work well with the multiline pattern
	matching both the prompt and the line before it:
	...
	    -re -wrap ".* = \\\(n => $decimal\\\)" {
	...

	Fix this by making it a one-line pattern:
	...
	    -re -wrap "" {
	...

	While we're at it, replace an if-then-pass-else-fail with a gdb_assert.

	Tested on aarch64-linux.

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-types
	When running test-case gdb.dwarf2/enum-type-c++.exp with target board
	cc-with-debug-types, we run into:
	...
	(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
	...
	because val1 has no parent:
	...
	    [31] ((cooked_index_entry *) 0x7efedc002e90)
	    name:       val1
	    canonical:  val1
	    qualified:  val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0xef
	    parent:     ((cooked_index_entry *) 0)

	  ...

	    [37] ((cooked_index_entry *) 0x38ffd280)
	    name:       val1
	    canonical:  val1
	    qualified:  val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0xef
	    parent:     ((cooked_index_entry *) 0)
	...

	There are two entries, which seems to be an inefficiency, but for now let's
	focus on the correctness issue.

	The debug info for val1 looks like this:
	...
	 <1><cb>: Abbrev Number: 2 (DW_TAG_namespace)
	    <cc>   DW_AT_name        : ns
	    <cf>   DW_AT_declaration : 1
	 <2><d3>: Abbrev Number: 12 (DW_TAG_class_type)
	    <d4>   DW_AT_name        : A
	    <d6>   DW_AT_declaration : 1
	 <3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type)
	    <db>   DW_AT_declaration : 1
	 <1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type)
	    <e7>   DW_AT_specification: <0xd6>
	 <2><ef>: Abbrev Number: 5 (DW_TAG_enumerator)
	    <f0>   DW_AT_name        : val1
	    <f4>   DW_AT_const_value : 1
	...

	Fix this by:
	- adding a cooked index entry for DIE 0xcb (and consequently for child DIE
	  0xd3), by marking it interesting,
	- making sure that the entry for DIE 0xcb has a name, and
	- using the entry for DIE 0xd3 as parent entry for DIE 0xdd.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix parent of enumerator
	As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of
	DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in
	test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent:
	...
	    [27] ((cooked_index_entry *) 0x7fbbb4002ef0)
	    name:       val1
	    canonical:  val1
	    qualified:  val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0x124
	    parent:     ((cooked_index_entry *) 0)
	...

	This happens here in cooked_indexer::index_dies:
	...
		      info_ptr = recurse (reader, info_ptr,
					  is_enum_class ? this_entry : parent_entry,
					  fully);
	...
	when we're passing down a nullptr parent_entry, while the parent of this_entry
	is deferred.

	Fix this in cooked_indexer::index_dies by passing down a deffered parent
	instead, such that we get:
	...
	    [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M
	    name:       val1^M
	    canonical:  val1^M
	    qualified:  ns::val1^M
	    DWARF tag:  DW_TAG_enumerator^M
	    flags:      0x0 []^M
	    DIE offset: 0x124^M
	    parent:     ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Fix "sofar->so far" misspelling
	I forgot to follow up on a review comment and fix the "sofar->so far"
	misspelling [1].

	Fix this by adding it to gdb/contrib/common-misspellings.txt.

	Tested on x86_64-linux.

	[1] https://sourceware.org/pipermail/gdb-patches/2024-September/211894.html

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add more separators in spellcheck.sh
	Add two more separators in spellcheck.sh: colon and comma.

	Doing so triggers the "inbetween->between" rule, which gives an incorrect
	result.  Override this with "inbetween->between, in between, in-between" [1],
	in a new file gdb/contrib/common-misspellings.txt.

	Fix the following common misspellings:
	...
	everytime -> every time
	sucess -> success
	thru -> through
	transfered -> transferred
	inbetween -> between, in between, in-between
	...

	Verified with spellcheck.sh.  Tested on x86_64-linux.

	[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/

2024-10-08  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Factor out grep_or and sed_or in spellcheck.sh
	While trying to add more separators here:
	...
	 # Separators: space, slash, tab.
	 grep_separator=" |/|	"
	 sed_separator=" \|/\|\t"
	...
	I mistakingly used "|" instead of "\|" in sed_separator.

	Factor out new variables grep_or and sed_or, and construct the grep_separator
	and sed_separator variables by joining the elements of a list using grep_or
	and sed_or.

	Verified with shellcheck, and tested by rerunning on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-10-08  Alan Modra  <amodra@gmail.com>

	Revised "Don't return (null) from bfd_elf_sym_name"
	Commit 68bbe1183379 results in a lot of follow up work, much of which
	likely is still to be done. (And yes, since this is all for corrupted
	or fuzzed object files, a whole lot of work doesn't much benefit
	anyone.  It was a bad idea to put NULL in asymbol->name.)  So I'm
	changing the approach to instead put a unique empty string for symbols
	with a corrupted st_name.  An empty string won't require much work to
	ensure nm, objcopy, objdump etc. won't crash, since these tools
	already must work with unnamed local symbols.

	The unique empty string is called bfd_symbol_error_name.  This patch
	uses that name string for corrupted symbols in the ELF and COFF
	backends.  Such symbols are displayed by nm and objdump as the
	translated string "<corrupt>", which is what the COFF backend used to
	put directly into corrupted symbols.

	ie. it's the way I should have written the original patch, plus a few
	tides and cleanups I retained from the reverted patches.

2024-10-08  Alan Modra  <amodra@gmail.com>

	Revert "Don't return "(null)" from bfd_elf_sym_name"
	This reverts commit 68bbe118337939aa0b52e007a7415c8a157579a1.

	Revert "bfd_elf_sym_name_raw"
	This reverts commit 265757dc6e4d011a1b33ef1b3bfcd7f100f12f64.

	Revert "get_synthetic_symtab fixes for commit 68bbe1183379"
	This reverts commit 0c13ac533e59589793ee6c8045cff98663f3ea85.

	Revert "is_target_special_symbol fixes for commit 68bbe1183379"
	This reverts commit 6e40f9bb31be2f3656df97a1fcba4d6a30081e24.

	Revert "dlltool fixes for commit 68bbe1183379"
	This reverts commit 06116013f80e474800cfb122924bc2a6f060606a.

	Revert "elf.c and elflink.c fixes for commit 68bbe1183379"
	This reverts commit 389fdfbe0d2aca0af1431ddf34704534dacc48c8.

	Revert "objcopy fixes for commit 68bbe1183379"
	This reverts commit ef166f451fbc2c7b251a251ab23cd35b36c5ee23.

2024-10-08  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Fix implicit dependency of Zabha and Zacas
	1 Zabha depends on Zaamo:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/zabha.adoc>

	2 Zacas depends on Zaamo:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/zacas.adoc>

	bfd/ChangeLog:

		* elfxx-riscv.c: Zabha and Zacas implicitly depend on Zaamo.

	gas/ChangeLog:

		* testsuite/gas/riscv/imply.d: Updated.

2024-10-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add hardware counters for Neoverse-N1 and Ampere-1 processors
	gprofng/ChangeLog
	2024-10-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		* common/hwc_cpus.h: New constant for Neoverse-N1 and Ampere-1.
		* common/hwctable.c: Add the hwc table for Neoverse-N1 and Ampere-1.
		* src/hwc_arm_ampere_1.h: New file with hwc table for Ampere-1.
		* src/hwc_arm_neoverse_n1.h: New file with hwc table for Neoverse-N1.

2024-10-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-07  Andreas Schwab  <schwab@linux-m68k.org>

	m68k: Support for jump visualization in disassembly
	opcodes/
		* m68k-dis.c (m68k_opcode_to_insn_type): Define.
		(match_insn_m68k): Call it to set insn_type.
		(print_insn_arg) [case 'B']: Set branch target address.
		(print_insn_m68k): Set insn_info_valid.

2024-10-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-inferior.exp with -fsanitize=thread
	With a gdb build with -fsanitize=thread, and test-case
	gdb.python/py-inferior.exp I run into:
	...
	(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
	ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
	  maximum supported size of 0x10000000000^M
	...

	There's already a workaround for this using ASAN_OPTIONS, and apparently the
	same is needed for TSAN_OPTIONS.

	Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.

	Likewise in gdb.dap/memory.exp.

	Tested on x86_64-linux.

2024-10-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-06  Gaius Mulley  <gaiusmod2@gmail.com>

	gdb/m2: add builtin procedure function ADR
	This patch introduces ADR to the Modula-2 language interface.
	It return the address of the parameter supplied.
	The patch also contains a dejagnu test for ADR.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-10-06  Gaius Mulley  <gaiusmod2@gmail.com>

	gdb/MAINTAINERS: update my email address
	Sync the maintainers file with my new email address.

2024-10-06  Tom de Vries  <tdevries@suse.de>

	[gdb] Rerun spellcheck.sh
	Fix the following common misspellings:
	...
	completetion -> completion
	inital -> initial
	...

2024-10-06  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix more common misspellings
	Fix the following common misspellings:
	...
	addres -> address, adders
	behavour -> behavior, behaviour
	intented -> intended, indented
	ther -> there, their, the
	throught -> thought, through, throughout
	...

	Tested on x86_64-linux.

2024-10-06  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix common misspellings
	Fix the following common misspellings:
	...
	accidently -> accidentally
	additonal -> additional
	addresing -> addressing
	adress -> address
	agaisnt -> against
	albiet -> albeit
	arbitary -> arbitrary
	artifical -> artificial
	auxillary -> auxiliary
	auxilliary -> auxiliary
	bcak -> back
	begining -> beginning
	cannonical -> canonical
	compatiblity -> compatibility
	completetion -> completion
	diferent -> different
	emited -> emitted
	emiting -> emitting
	emmitted -> emitted
	everytime -> every time
	excercise -> exercise
	existance -> existence
	fucntion -> function
	funtion -> function
	guarentee -> guarantee
	htis -> this
	immediatly -> immediately
	layed -> laid
	noone -> no one
	occurances -> occurrences
	occured -> occurred
	originaly -> originally
	preceeded -> preceded
	preceeds -> precedes
	propogate -> propagate
	publically -> publicly
	refering -> referring
	substract -> subtract
	substracting -> subtracting
	substraction -> subtraction
	taht -> that
	targetting -> targeting
	teh -> the
	thier -> their
	thru -> through
	transfered -> transferred
	transfering -> transferring
	upto -> up to
	vincinity -> vicinity
	whcih -> which
	whereever -> wherever
	wierd -> weird
	withing -> within
	writen -> written
	wtih -> with
	doesnt -> doesn't
	...

	Tested on x86_64-linux.

2024-10-06  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Add spellcheck.sh
	I came across a table containing common misspellings [1], and wrote a script to
	detect and correct these misspellings.

	The table also contains entries that have alternatives, like this:
	...
	addres->address, adders
	...
	and for those the script prints a TODO instead.

	The script downloads the webpage containing the table, extracts the table and
	caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
	over and over again.

	Example usage:
	...
	$ gdb/contrib/spellcheck.sh gdb*
	...

	ChangeLog files are silently skipped.

	Checked with shellcheck.

	Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
	test run.

	The results of running it are in the two following patches.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines

2024-10-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-05  Alan Modra  <amodra@gmail.com>

	objcopy fixes for commit 68bbe1183379
		* objcopy.c (is_specified_symbol): Handle NULL name.
		(filter_symbols): Drop syms with a NULL name.

2024-10-05  Alan Modra  <amodra@gmail.com>

	elf.c and elflink.c fixes for commit 68bbe1183379
	Plus some tidies to swap_out_syms.

		* elf.c (swap_out_syms): Handle NULL sym name.  Use correct type
		for return of _bfd_elf_strtab_add.  Simplify.
		* elflink.c (bfd_elf_match_symbols_in_sections): Handle NULL
		sym name.

2024-10-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-04  Alan Modra  <amodra@gmail.com>

	gdb segv in elfread.c:elf_rel_plt_read
	After commit 68bbe1183379, ELF symbols read via bfd_canonicalize_symtab
	and similar functions which have bad st_name fields will have NULL in
	the name rather than "(null)".  gdb.base/bfd-errors.exp deliberately
	creates a faulty shared library with st_name pointing outside of
	.dynsym for some symbols, and thus now results in NULL symbol names.
	This triggers a segv on string_buffer.assign(name).  Fix that.

2024-10-04  Alan Modra  <amodra@gmail.com>

	dlltool fixes for commit 68bbe1183379
	For some reason, dlltool supports mcore-elf input files.

		* dlltool.c (filter_symbols): Drop symbols with NULL names.
		(identify_member_contains_symname): Don't consider symbols
		with NULL names.

2024-10-04  Alan Modra  <amodra@gmail.com>

	is_target_special_symbol fixes for commit 68bbe1183379
		* elf.c (_bfd_elf_is_local_label_name): Don't segv on NULL name.
		* elf32-v850.c (v850_elf_is_local_label_name): Likewise.
		* elfnn-riscv.c (riscv_elf_is_target_special_symbol): Likewise.

2024-10-04  Alan Modra  <amodra@gmail.com>

	get_synthetic_symtab fixes for commit 68bbe1183379
	Given that relocation symbol name can now be NULL for ELF, adjust
	various get_synthetic_symtab routines so they don't segfault.

		* elf.c (_bfd_elf_get_synthetic_symtab): Cope with sym->name
		possibly being NULL.
		* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
		* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
		* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
		* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.
		* elfxx-x86.c (_bfd_x86_elf_get_synthetic_symtab): Likewise.

2024-10-04  Alan Modra  <amodra@gmail.com>

	bfd_elf_sym_name_raw
	Many uses of bfd_elf_sym_name report errors.  They ought to not return
	a NULL, as was the case prior to commit 68bbe1183379.  Introduce a new
	function for cases where we'd like to know there is a problem with a
	symbol st_name.

		* elf-bfd.h  (bfd_elf_sym_name_raw): Declare.
		* elf.c (bfd_elf_sym_name_raw): New function.
		(bfd_elf_sym_name): Revert to behaviour prior to 68bbe1183379,
		but returning "<null>" rather than "(null)" for st_name errors.
		(group_signature): Use bfd_elf_sym_name_raw.
		* elfcode.h (elf_slurp_symbol_table): Likewise.
		* elf32-i386.c (elf_i386_scan_relocs): Whitespace.

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	gas: hide emulation struct format_ops instances when not needed
	Most targets don't even support emulations, so this data (and certain
	functions) are entirely dead code for them.

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	x86: prune OBJ_MAYBE_... uses
	With the removal of emulations, OBJ_MAYBE_... can no longer be defined.
	Tidy code wherever they're used, which also includes the dropping of
	most IS_ELF and uses and checks of OUTPUT_FLAVOR.

	Where touching such constructs anyway, also drop TE_PEP checks when used
	together with TE_PE ones (the former implies the latter).

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	x86: drop largely defunct gas emulations
	Both ELF and COFF have various sub-flavors, each of which would then
	require its own emulation: Right now when configuring a COFF/PE
	secondary target (with perhaps an ELF primary one), one gets plain COFF
	emulation rather than COFF/PE one.

	As such a multitude of emulations would be unwieldy (and likely fragile)
	drop gas emulations altogether instead.

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	include: de-duplicate i386.h and x86_64.h
	Move common definitions to a new x86.h, thus allowing gas'es obj-coff.h
	to include just that, getting rid of a TE_PEP compile-time dependency.

	gas: drop generate_asm_lineno emulation hook
	It's not wired up, so can't be used.

	gas: don't use COFF-specific SF_SET_LOCAL() directly from read.c
	Make this a proper obj-format hook instead.

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	gas/dw2gencfi: correct .sframe section conditional
	While originally this was in preparation of a subsequent change making
	SUPPORT_FRAME_LINKONCE potentially dependent on a global variable, the
	construct appears unlikely to have been correct in the first place: The
	variable would have been passed reliably uninitialized when
	SUPPORT_FRAME_LINKONCE is build-time true.

	While there correct indentation of the parameters passed to
	get_cfi_seg().

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	gas: put emul decls in emul.h
	The individual struct emulation instances shouldn't be declared in a .c
	file; it and the producers of the symbols want to both see the
	declarations, so declarations and definitions don't go out of sync. Move
	these declarations to emul.h.

	While there also adjust the conditional around this_format: That symbol
	is never #define-d anywhere, and it's needed only when USE_EMULATIONS is
	defined. (Really, when obj-multi isn't in use, it also is effectively
	only ever written to.)

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	gas: drop unused fields from struct emulation
	Neither .match not .bfd_name appear to ever have been used in the last
	about 25 years. Purge them.

	MAINTAINERS: move M R Swami Reddy to Past Maintainers
	He/she cannot be reached at the given address anymore, and the name is
	apparently too common to identify the person to attempt to establish
	another contact. Sadly this orphans the CR16 and CRx ports.

2024-10-04  Jan Beulich  <jbeulich@suse.com>

	MAINTAINERS: move Matt Thomas to Past Maintainers
	Matt cannot be reached at the @netbsd.org address anymore, and I was
	unable to find another one, even with the help of the NetBSD community
	(where his resigning was announced over 4 years ago [1]).

	[1] http://mail-index.netbsd.org/netbsd-announce/2020/05/07/msg000314.html

2024-10-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-03  oltolm  <oleg.tolmatcev@gmail.com>

	gdb-dap: disable events when deleting breakpoints
	when I disable a breakpoint in VS Code the breakpoint is removed
	instead. I compared the behavior to lldb-dap and disabled events when
	removing a breakpoint. Now it is possible to disable and enable
	breakpoints in VS Code.

2024-10-03  Alexey Izbyshev  <izbyshev@ispras.ru>

	bfd: fix unnecessary bfd.info regen
	When building from an unmodified release tarball, a REGEN_TEXI
	invocation is supposed to create a symlink to the .texi file
	in the source directory and discard the newly generated .tmp file.
	However, after commit bd32be01c997 ("bfd: merge doc subdir up a level")
	it creates the symlink at the wrong level, and then a .texi with
	a fresh timestamp, which in turn forces bfd.info regeneration.
	This breaks builds in environments without makeinfo program.

	Fix this by creating the symlink at the level of the target stamp.

	Fixes: bd32be01c997 ("bfd: merge doc subdir up a level")

2024-10-03  Alan Modra  <amodra@gmail.com>

	peicode.h formatting
	Fix some overlong line, comment block style, whitespace issues.

2024-10-03  Alan Modra  <amodra@gmail.com>

	Enable dlltool --leading-underscore for targets other than x86
	This also makes the dlltool tests run more PE targets, finding that
	sh-pe dlltool reports "Machine 'sh' not supported".  I guess no one
	cares about that.

		PR19459
		* dlltool.c (asm_prefix): Remove "mach" parameter.  Return
		leading_underscore independent of machine.
		(ASM_PREFIX): Adjust.
		* testsuite/binutils-all/dlltool.exp: Run on any target
		satisfying is_pecoff_format for which dlltool is built.
		Revert commit 0398b8d6c86a.  Remove target_xfail.

2024-10-03  Alan Modra  <amodra@gmail.com>

	dlltool leading_underscore
	This patch tidies dlltool code dealing with adding a leading
	underscore to generated symbol names.  There should be no functional
	change here, but there could be if we ever have a bfd target with
	symbol_leading_char something other than '_' or 0.

		* dlltool.c (leading_underscore): Change from an int to a
	        char*.  Update all uses.  If neither --leading-underscore or
	        --no=leading-underscore is given, set leading_underscore to a
	        string with first char returned by bfd_get_target_info as the
	        target's symbol underscoring.

2024-10-03  Alan Modra  <amodra@gmail.com>

	nm: don't try to print line numbers for symbols without names
	It doesn't make much sense trying to print line numbers for what are
	usually broken symbols, and there is a possibility of a segfault if
	we pass strcmp a NULL.

2024-10-03  Alan Modra  <amodra@gmail.com>

	Don't return "(null)" from bfd_elf_sym_name
	A NULL return from bfd_elf_string_from_elf_section indicates an error.
	That shouldn't be masked by bfd_elf_sym_name but rather passed up to
	callers such as group_signature.  If we want to print "(null)" then
	that should be done at a higher level.  That's what this patch does,
	except that I chose to print "<null>" instead, like readelf.  If we
	see "(null)" we're probably passing a NULL to printf.  I haven't
	changed aoutx.h or pdp11.c print_symbol functions because they already
	handle NULL names by omitting the name.  I also haven't changed
	mach-o.c, mmo.c, som.c, srec.c, tekhex.c, vms-alpha.c and
	wasm-module.c print_symbol function because it looks like they will
	never have NULL symbol names.

	bfd/
		* elf.c (bfd_elf_sym_name): Don't turn a NULL name into a
		pointer to "(null)".
		(bfd_elf_print_symbol): Print "<null>" for NULL symbol names.
		* coffgen.c (coff_print_symbol): Likewise.
		* ecoff.c (_bfd_ecoff_print_symbol): Likewise.
		* pef.c (bfd_pef_print_symbol): Likewise.
		* syms.c (bfd_symbol_info): Return "<null>" in symbol_info.name
		if symbol name is NULL.
	ld/
		* ldlang.c (ld_is_local_symbol): Don't check for "(null)"
		symbol name.

2024-10-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-02  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	gprofng: fix a problem with hardware event counters
	Fix a bug where an experiment with hardware event counter data
	causes the source and disassembly files not to be generated.
	No longer suppress zero valued metrics and change the name
	of the man page in a warning message. Adapt line lengths to
	not exceed 79.

	gprofng/ChangeLog
	2024-09-24  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		PR 32193
		PR 32199
		PR 32201
		* gp-display-html/gp-display-html.in: Implement all
		the above changes.

2024-10-02  Andrew Burgess  <aburgess@redhat.com>

	gdb: more file name styling
	While looking at the recent line number styling commit I noticed a few
	places where we could add more file name styling.  So lets do that.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-10-02  Martin Storsjö  <martin@martin.st>

	Add support for IMPORT_NAME_EXPORTAS in ILF (MSVC style) import libraries
	This import name type is formally yet undocumented, but MSVC
	produces/supports it, primarily for ARM64EC import libraries.

	LLVM/LLD also supports this import name type. Since recently,
	llvm-dlltool also uses this type for certain kinds of renamed imports
	(that are easy to do in the long style import libraries produced by
	GNU dlltool, but require this name type in short import libraries).

	This name type contains a third string, in addition to the symbol
	name and the DLL name, indicating the actual imported name to
	reference in the import tables - which now can be distinct different
	from the symbol name on the object file level.

	https://github.com/llvm/llvm-project/commit/8f23464a5d957242c89ca6f33d4379c42519cd81
	and
	https://github.com/llvm/llvm-project/commit/7b275aa2438c22604505d618dd37ee60052f2800
	show how this import name type was added in LLVM.

2024-10-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-01  Tom Tromey  <tromey@adacore.com>

	Introduce and use operation::type_p
	There's currently code in gdb that checks if an expression evaluates
	to a type.  In some spots this is done by comparing the opcode against
	OP_TYPE, but other spots more correctly also compare with OP_TYPEOF
	and OP_DECLTYPE.

	This patch cleans up this area, replacing opcode-checking with a new
	method on 'operation'.

	Generally, checking the opcode should be considered deprecated,
	although it's unfortunately difficult to get rid of opcodes entirely.

	I also took advantage of this change to turn eval_op_type into a
	method, removing a bit of indirection.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-10-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-10-01  Alan Modra  <amodra@gmail.com>

	Re: dlltool: file name too long
	Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy
	TMP_STUB handling by overwriting a prior nnnnn.o string rather than
	copying the entire name.

		* dlltool.c (TMP_STUB): Add "nnnnn.o" to format.
		(make_one_lib_file): Localise variables.  Don't copy TMP_STUB,
		overwrite suffix instead.
		(gen_lib_file): Similarly.
		(main): Allow for max suffix when testing against NAME_MAX.

2024-10-01  Alan Modra  <amodra@gmail.com>

	segv in read_a_source_file
	On some paths through read_a_source file, "s" may not be set.

		* read.c (read_a_source_file): Correct code ignoring comment.

2024-09-30  Alan Modra  <amodra@gmail.com>

	segv in bfd_elf_get_str_section
	Attempting to write a termination NUL to PROT_READ mmap'd memory was
	a silly idea.

		PR 32109
		* elf.c (bfd_elf_get_str_section): Don't write terminating NUL
		if missing.
		* libbfd.c (_bfd_munmap_readonly_temporary): Correct comment.

2024-09-30  Tom Tromey  <tom@tromey.com>

	Add line-number styling
	This patch adds separate styling for line numbers.  That is, whenever
	gdb prints a source line number, it uses this style.

	v2 includes a change to ensure that %ps works in query.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-30  Nick Clifton  <nickc@redhat.com>

	Improve the placement of orphan note sections.
	PR 32219

2024-09-30  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix filename completion in the middle of a line
	I noticed that filename completion in the middle of a line doesn't
	work as I would expect it too.  For example, assuming '/tmp/filename'
	exists, and is the only file in '/tmp/' then when I do the following:

	  (gdb) file "/tmp/filen<TAB>

	GDB completes to:

	  (gdb) file "/tmp/filename"

	But, if I type this:

	  (gdb) file "/tmp/filen "xxx"

	Then move the cursor to the end of '/tmp/filen' and press <TAB>, GDB
	will complete the line to:

	  (gdb) file "/tmp/filename "xxx"

	But GDB will not insert the trailing double quote character.

	The reason for this is found in readline/readline/complete.c in the
	function append_to_match.  This is the function that appends the
	trailing closing quote character, however, the closing quote is only
	inserted if the cursor (rl_point) is at the end (rl_end) of the line
	being completed.

	In this patch, what I do instead is add the closing quote in the
	function gdb_completer_file_name_quote, which is called from readline
	through the rl_filename_quoting_function hook.  The docs for
	rl_filename_quoting_function say (see 'info readline'):

	  "... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one
	  completion match, or 'MULT_MATCH'.  Some functions use this to
	  decide whether or not to insert a closing quote character. ..."

	This is exactly what I'm doing in this patch, and clearly this is not
	an unusual choice.  Now after completing a filename that is not at the
	end of the line GDB will add the closing quote character if
	appropriate.

	I have managed to write some tests for this.  I send a line of text to
	GDB which includes a partial filename followed by a trailing string, I
	then send the escape sequence to move the cursor left, and finally I
	send the tab character.

	Obviously, expect doesn't actually see the complete output with the
	extra text "in place", instead expect sees the original line followed
	by some escape sequences to reflect the cursor movement, then an
	escape sequence to indicate that text is being inserted in the middle
	of a line, followed by the new characters ... it's a bit messy, but I
	think it holds together.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2024-09-30  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix for completing a second filename for a command
	After the recent filename completion changes I noticed that the
	following didn't work as expected:

	  (gdb) file "/path/to/some/file" /path/to/so<TAB>

	Now, I know that the 'file' command doesn't actually take multiple
	filenames, but currently (and this was true before the recent filename
	completion changes too) the completion function doesn't know that the
	command only expects a single filename, and should complete any number
	of filenames.  And indeed, this works:

	  (gdb) file "/path/to/some/file" "/path/to/so<TAB>

	In this case I quoted the second path, and now GDB is happy to offer
	completions.

	It turns out that the problem in the first case is an off-by-one bug
	in gdb_completer_file_name_char_is_quoted.  This function tells GDB if
	a character within the line being completed is escaped or not.  An
	escaped character cannot be a word separator.

	The algorithm in gdb_completer_file_name_char_is_quoted is to scan
	forward through the line keeping track of whether we are inside double
	or single quotes, or if a character follows a backslash.  When we find
	an opening quote we skip forward to the closing quote and then check
	to see if we skipped over the character we are looking for, if we did
	then the character is within the quoted string.

	The problem is that this "is character inside quoted string" check
	used '>=' instead if '>'.  As a consequence a character immediately
	after a quoted string would be thought of as inside the quoted string.

	In our first example this means that the single white space character
	after the quoted string was thought to be quoted, and was not
	considered a word breaking character.  As such, GDB would not try to
	complete the second path.  And indeed, if we tried this:

	  (gdb) file "/path/to/some/file"    /path/to/so<TAB>

	That is, place multiple spaces after the first path, then GDB would
	consider the first space as quoted, but the second space is NOT
	quoted, and would be a word break.  Now GDB does complete the second
	path.

	By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this
	bug is resolved, now the original example works and GDB will correctly
	complete the second path.

	For testing I've factored out the core of one testing proc, and I now
	run those tests multiple times, once with no initial path, once with
	an initial path in double quotes, once with an initial path in
	single quotes, and finally, with an unquoted initial path.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2024-09-30  Gerlicher, Klaus  <klaus.gerlicher@intel.com>

	gdb/MAINTAINERS: add myself to maintainers

2024-09-30  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb: Remove myself as x86 maintainer and update my email

2024-09-30  Gerlicher, Klaus  <klaus.gerlicher@intel.com>

	gdb, testsuite: clean duplicate header includes
	Some of the gdb and testsuite files double include some headers. While
	all headers use include guards, it helps a bit keeping the code base
	tidy.

	No functional change.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-09-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-28  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Dump m_all_parents_map for verbose debug dwarf-read
	[ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ]

	When building the cooked index, gdb builds up a parent map.

	This map is currently only visible at user level through the effect of using
	it, but it's useful to be able to inspect it as well.

	Add dumping of this parent map for "set debug dwarf-read 2".

	As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board
	debug-types.

	The parent map looks like:
	...
	$ gdb -q -batch \
	    -iex "maint set worker-threads 0" \
	    -iex "set debug dwarf-read 2" \
	    outputs/gdb.dwarf2/enum-type-c++/enum-type-c++
	  ...
	[dwarf-read] print_stats: Final m_all_parents_map:
	map start:
	  0x0000000000000000 0x0
	  0x0000000000000037 0x20f27d30 (0x36: ec)
	  0x0000000000000051 0x0
	  0x000000000000008b 0x20f27dc0 (0x8a: A)
	  0x00000000000000a6 0x0
	...

	There's no parent entry at address 0xd6, which is part of what causes this:
	...
	(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
	...

	With the series containing the proposed fix applied [2], we get instead:
	...
	[dwarf-read] print_stats: Final m_all_parents_map:
	map start:
	  0x0000000000000000 0x0
	  0x0000000000000026 0x7e0bdc0 (0x25: ns)
	  0x0000000000000036 0x0
	  0x0000000000000037 0x7e0bdf0 (0x36: ns::ec)
	  0x0000000000000051 0x0
	  0x000000000000007f 0x7e0be80 (0x7e: ns)
	  0x000000000000008a 0x0
	  0x000000000000008b 0x7e0beb0 (0x8a: ns::A)
	  0x00000000000000a6 0x0
	  0x00000000000000cc 0x7e0bf10 (0xcb: ns)
	  0x00000000000000d4 0x7e0bf40 (0xd3: ns::A)
	  0x00000000000000dc 0x7e0bf10 (0xcb: ns)
	  0x00000000000000dd 0x7e0bf40 (0xd3: ns::A)
	  0x00000000000000f6 0x0
	...
	and find at 0xd6 parent ns::A.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html
	[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html

2024-09-28  Alan Modra  <amodra@gmail.com>

	gas buffer overflow with --listing-rhs-width
	With listings enabled, gas keeps a small cache of source lines.  They
	are stored in buffers of size LISTING_RHS_WIDTH, ie. 100.  Given
	listing-rhs-width larger than 100 it is of course possible to overflow
	the buffer.  Fix that by allocating as needed.  We could allocate all
	buffers on the first call to print_source using listing_rhs_width, but
	I chose not to do that in case some future assembly directive allows
	changes to listing_rhs_width similarly to the way paper_width can
	change during assembly.

2024-09-28  Alan Modra  <amodra@gmail.com>

	Move uses_elf_em to ld-lib.exp
	and add a missing entry from uses_genelf.

	binutils/
		* testsuite/lib/binutils-common.exp (uses_elf_em): Delete.
	ld/
		* testsuite/lib/ld-lib.exp (uses_genelf): Add moxie-*-moxiebox.
		(uses_elf_em): New.

2024-09-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-27  Tom Tromey  <tromey@adacore.com>

	Re-run 'isort' on gdb tests
	Re-running 'isort' (via pre-commit) showed that the file
	py-read-memory-leak.py (from the gdb test suite) needed a small patch.

2024-09-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb/symtab: pass program space to lookup_symtab and iterate_over_symtabs
	Make the current program space references bubble up.

	In collect_symtabs_from_filename, remove the calls to
	set_current_program_space and just pass the relevant pspaces.
	This appears safe to do, because nothing in the `collector` callback
	cares about the current pspace.

	Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: fix Solaris gas testsuite run
	Commits 8015b1b0c1a1 ("x86-64: Never make R_X86_64_GOT64 section
	relative"), d774bf9b3623 ("x86: Add tls check in gas"), and
	1b714c14e40f ("x86: Turn PLT32 to PC32 only for PC-relative
	relocations") all should have adjusted the Solaris counterpart of the
	reloc64 test as well.

	RISC-V: odd data padding vs mapping symbols
	Odd data padding has a $d label inserted at its beginning. When a $x...
	label is removed instead, a replacement is inserted after the padding.
	The same, however, needs to also happen when there's no $x to replace.

2024-09-27  Jan Beulich  <jbeulich@suse.com>

	RISC-V: correct alignment directive handling for text sections
	.insn or data emitted inside text sections can lead to positions not
	being at insn granularity. In such situations using alignment
	directives should reliably enforce the requested alignment.
	Specifically requests to align back to insn granularity may not be
	ignored (where, as a subcase thereof, the ordering of ".option norvc"
	and e.g. ".p2align 2" should not matter; so far the alignment directive
	needs to come first to have any effect). Similarly ahead of emitting
	NOPs alignment first needs to be forced back to insn granularity.

	The new testcases actually point out a corner case issue in the
	disassembler as well, which is being corrected at the same time: We
	don't want to print "0x" without any subsequent digits.

2024-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: optimize {,V}INSERTPS with certain immediates
	They are equivalent to simple moves or xors, which are up to 3 bytes
	shorter to encode (and maybe/likely also cheaper to execute).

	x86: optimize {,V}EXTRACT{F,I}{128,32x{4,8},64x{2,4}} with immediate 0
	They, too, are equivalent to simple moves, which are up to 3 bytes
	shorter to encode (and maybe also cheaper to execute).

	x86: optimize {,V}EXTRACTPS with immediate 0
	They are equivalent to simple moves, which are up to 2 bytes shorter to
	encode (and maybe also cheaper to execute).

	x86: correct {,V}PEXTR{D,Q} optimization
	A possible relocation associated with a memory operand also needs
	moving.

2024-09-27  Alan Modra  <amodra@gmail.com>

	Enable -z separate-code, -z common and -z text for more targets
	Fix a mis-placed "fi".

2024-09-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-27  Tom Tromey  <tom@tromey.com>

	Add 'const' to symmisc.c
	I noticed a few spots in symmisc.c that could use a 'const'.

2024-09-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32207 [gprofng collect app] Error in parsing the -O option
	gprofng/ChangeLog
	2024-09-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32207
		* src/collctrl.cc (preprocess_names): Fix the size in strndup.

2024-09-26  Nick Clifton  <nickc@redhat.com>

	Updated Brazilian Portuguese translation for the gprof directory.

2024-09-26  Andreas Schwab  <schwab@suse.de>

	Fix -Wstringop-overflow warning in ecoff_link_hash_newfunc
		* ecoff.c (ecoff_link_hash_newfunc): Don't call memset if ret is
		NULL.

2024-09-26  H.J. Lu  <hjl.tools@gmail.com>

	ld: Ignore .note.gnu.build-id when placing orphaned notes
	The commits:

	e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments.
	bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map

	place .note.gnu.build-id before text sections when --rosegment is used.
	Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and
	-z separate-code are used together to avoid putting any note sections
	between .note.gnu.build-id and text sections in the same PT_LOAD segment.

		PR ld/32191
		* ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when
		placing orphaned notes.
		* testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld.
		* testsuite/ld-elf/pr23658-1c.d: Likewise.
		* testsuite/ld-elf/pr23658-1e.d: New file.
		* testsuite/ld-elf/pr23658-1f.d: Likewise.
		* testsuite/ld-i386/i386.exp: Run PR ld/32191 test.
		* testsuite/ld-i386/pr32191.d: New file.
		* testsuite/ld-x86-64/lam-u48.rd: Updated.
		* testsuite/ld-x86-64/lam-u57.rd: Likewise.
		* testsuite/ld-x86-64/pr32191-x32.d: New file.
		* testsuite/ld-x86-64/pr32191.d: Likewise.
		* testsuite/ld-x86-64/pr32191.s: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests.

2024-09-26  Jan Beulich  <jbeulich@suse.com>

	x86: templatize SIMD narrowing-move templates
	Once again to reduce redundancy.

	x86: templatize SIMD sign-/zero-extension templates
	Yet again to reduce redundancy.

	x86: templatize SIMD FP binary-logic templates
	Once more to reduce redundancy.

	x86: further templatize FMA templates
	Further reduce redundancy, in preparation of the addition of
	counterparts for AVX10.2.

	x86: templatize SIMD FP arithmetic templates
	Reduce redundancy, in preparation of the addition of further counterparts
	for AVX10.2. Provide the "ne" parameter needed there right away, even if
	unused for now.

2024-09-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: test for memory leaks in gdb.Inferior.read_memory()
	For a long time Fedora GDB has carried an out of tree patch which
	checks for memory leaks in gdb.Inferior.read_memory().  At one point
	in the distant past GDB did have a memory leak in this code, but this
	was first fixed in commit:

	  commit 655e820cf9a039ee55325d9e1f8423796d592b4b
	  Date:   Wed Mar 28 17:38:07 2012 +0000

	        * python/py-inferior.c (infpy_read_memory): Remove cleanups and
	          explicitly free 'buffer' on exit paths.  Decref 'membuf_object'
	          before returning.

	And the code has changed a lot since then, but the leak is still
	fixed.  Unfortunately, this commit didn't have any associated tests.

	The original Fedora test wasn't really suitable for upstream, it was
	reading /proc/PID/... to figure out if there was a leak or not.

	However, we already have gdb.python/py-inferior-leak.exp in upstream
	GDB, which makes use of the Python tracemalloc module to check for
	memory leaks in a corner of the Python API, so I figured it wouldn't
	hurt to rewrite the test in the same style.

	And so here is a test for a bug which was closed 12 years ago.  This
	detects if the gdb.Inferior.read_memory() call leaks any memory.

	I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last
	line which currently looks like this:

	  return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ());

	and instead doing:

	  return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ());

	The use of "release" here will mean we no longer decrement the
	reference count on membuf_obj before returning from the function.  As
	a consequence the membuf_obj will not be garbage collected.  With this
	hack in place the new test will fail.

	The Python script in the new test is mostly a copy&paste from
	py-inferior-leak.py with the core changed to do a memory read instead
	of inferior creation.  I did consider rewriting both tests into a
	single file, maybe, py-memory-leak.py, which would make it easier to
	add additional similar tests in the future.  For now I've held off
	doing that, but if this gets merged then I _might_ revisit this idea.

	If folk feel that this new test should only be accepted if I do this
	rewrite then let me know and I can get that done.

	On copyright date ranges: The .exp and .py scripts are new enough for
	this commit that I've dated them 2024.  The .c source script is lifted
	directly from the old Fedora patch, so I've retained the original 2014
	start date for that file only.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-26  Haochen Jiang  <haochen.jiang@intel.com>

	x86/testsuite: Refine AVX10.2 rounding testcases
	Using hard byte code is not a good idea in dump file. Add a label
	for intel syntax test check to avoid that.

	gas/ChangeLog:

		* testsuite/gas/i386/avx10_2-rounding-intel.d: Use label for
		test split.
		* testsuite/gas/i386/avx10_2-rounding.s: Add label to avoid
		hard coding in dump file.

2024-09-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-25  Alan Modra  <amodra@gmail.com>

	x86 TLS relocation checks
	Some configurations (eg. i386-bsd, i386-msdos) broke with the addition
	of the TLS relocation checking.  The "x86_elf_abi undeclared" error
	has been fixed, but "gotrel defined but not used" remains.  Fix that.
	Also invert the preprocessor test around lex_got to make it positive
	logic and remove the LEX_AT condition which is no longer necessary.
	(The only x86 config files defining LEX_AT also define TE_PE.)

2024-09-25  Sam James  <sam@gentoo.org>

	ltmain.sh: allow more flags at link-time
	libtool defaults to filtering flags passed at link-time.

	This brings the filtering in GCC's 'fork' of libtool into sync with
	upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e.

	In particular, this now allows some harmless diagnostic flags (especially
	useful for things like -Werror=odr), more optimization flags, and some
	Clang-specific options.

	GCC's -flto documentation mentions:
	> To use the link-time optimizer, -flto and optimization options should be
	> specified at compile time and during the final link. It is recommended
	> that you compile all the files participating in the same link with the
	> same options and also specify those options at link time.

	This allows compliance with that.

		* ltmain.sh (func_mode_link): Allow various flags through filter.

2024-09-25  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Make sure python sys.exit makes gdb exit
	With gdb 15.1, python sys.exit no longer makes gdb exit:
	...
	$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
	Python Exception <class 'SystemExit'>: 2
	Error occurred in Python: 2
	$1 = 123
	0
	...

	This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python"
	command exception handling"), first available in gdb 15.1.

	This patch reverts to the old behaviour by handling PyExc_SystemExit in
	gdbpy_handle_exception, such what we have instead:
	...
	$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
	2
	...

	Tested on x86_64-linux, with python 3.6 and 3.13.

	Tested-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/31946
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946

2024-09-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: format some Python files
	Format with black.

	Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2

2024-09-25  Schimpe, Christina  <christina.schimpe@intel.com>

	gdb, gdbserver, python, testsuite: Remove MPX.
	GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
	listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
	MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
	and glibc (since v2.35).  Let's now remove MPX support in GDB completely.

	This includes the removal of:
	- MPX functionality including register support
	- deprecated mpx commands
	- i386 and amd64 implementation of the hooks report_signal_info and
	  get_siginfo_type
	- tests
	- and pretty printer.

	We keep MPX register numbers to not break compatibility with old gdbservers.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-09-25  Schimpe, Christina  <christina.schimpe@intel.com>

	gdb, testsuite, python: Add missing imports.
	Removing the pretty printer (bound_registers.py) in the next commit
	leads to failures due to a missing import of 'gdb.printing':

	"AttributeError: module 'gdb' has no attribute 'printing'".

	Add this import to each file requiring it, as it's not imported by the
	pretty-printer anymore.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-09-25  Frank Ch. Eigler  <fche@redhat.com>

	binutils testsuite: canonicalize subtest names in libctf
	Previous code included the full $srcdir pathnames in the individual
	subtest PASS/FAIL names, which makes it difficult to compute
	comparisons or regressions between test runs on different machines.
	This version switches to the basename only, which are common.

	binutils testsuite: canonicalize subtest names in debuginfod.exp
	Previous code included the full $srcdir pathnames in the individual
	subtest PASS/FAIL names, which makes it difficult to compute
	comparisons or regressions between test runs on different machines.
	This version switches to the basename only, which are common.

2024-09-25  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Smrnmi extension csrs.
	This patch support Smrnmi extension[1],
	The csrs address can be find in[2].

	[1] https://github.com/riscv/riscv-isa-manual/commit/35eb3948bf0b87c83fab5a7238bd68b6211faf62
	[2] https://github.com/riscv/riscv-isa-manual/blob/smrnmi-1.0/src/priv-csrs.adoc

	bfd/ChangeLog:

		* elfxx-riscv.c: New extension.

	gas/ChangeLog:

		* NEWS: Add Smrnmi extension support.
		* config/tc-riscv.c (enum riscv_csr_class): New extension class.
		(riscv_csr_address): Ditto.
		* testsuite/gas/riscv/csr-version-1p10.d: New csrs.
		* testsuite/gas/riscv/csr-version-1p10.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.l: Ditto.
		* testsuite/gas/riscv/csr.s:  Ditto.
		* testsuite/gas/riscv/march-help.l: New extension.

	include/ChangeLog:

		* opcode/riscv-opc.h (CSR_MNSCRATCH): New csr.
		(CSR_MNEPC): Ditto.
		(CSR_MNCAUSE): Ditto.
		(CSR_MNSTATUS): Ditto.
		(DECLARE_CSR): New csr declarations.

2024-09-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-24  Tom Tromey  <tromey@adacore.com>

	Fix typo in gdb.ada/complete.exp test
	I noticed that two tests in gdb.ada/complete.exp are testing the same
	thing: the completion of "p pck.inne".  The second such test has this
	comment:

	    # A fully qualified package name

	I believe the intent here was to test "p pck.inner" (note the trailing
	"r").  This patch makes this change.

2024-09-24  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb: testsuite: Test whether PC register is expedited in gdb.server/server-run.exp
	One thing GDB always does when the inferior stops is finding out where
	it's stopped at, by way of querying the value of the program counter
	register.

	To save a packet round trip, the remote target can send the PC
	value (often alongside other frequently consulted registers such as the
	stack pointer) in the stop reply packet as an "expedited register".

	Test that this is actually done for the targets where gdbserver is
	supposed to.

	Extend the "maintenance print remote-registers" command output with an
	"Expedited" column which says "yes" if the register was seen by GDB in
	the last stop reply packet it received, and is left blank otherwise.

	Tested for regressions on aarch64-linux-gnu native-extended-remote.

	The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and
	x86_64-linux-gnu native-remote and native-extended-remote targets.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Simon Marchi  <simon.marchi@polymtl.ca>

	ld: re-generate configure
	Looks like configure has been generated with a non-upstream autoconf,
	re-generate it.

	ld/ChangeLog:

		* configure: Re-generate.

	Change-Id: I6774381ad411a190fb93ff260234dd79d8791680

2024-09-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/elfread.c: remove unused includes
	Remove some includes reported as unused by clangd.

	Change-Id: If7c4729975bd90b9cc2c22bcf84d333bd0002a52

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle SIGTERM in run_events
	While reviewing "catch (...)" uses I came across:
	...
	  for (auto &item : local)
	    {
	      try
		{
		  item ();
		}
	      catch (...)
		{
		  /* Ignore exceptions in the callback.  */
		}
	    }
	...

	This means that when an item throws a gdb_exception_forced_quit,
	the exception is ignored and following items are executed.

	Fix this by handling gdb_exception_forced_quit explicity, and immediately
	rethrowing it.

	I wondered about ^C, and couldn't decide whether current behaviour is ok, so
	I left this alone, but I made the issue explicit in the source code.

	As for the "catch (...)", I think that it should let a non-gdb_exception
	propagate, so I've narrowed it to "catch (const gdb_exception &)".

	My rationale for this is as follows.

	There seem to be a few ways that "catch (...)" is allowed in gdb:
	- clean-up and rethrow (basically the SCOPE_EXIT pattern)
	- catch and handle an exception from a call into an external c++ library

	Since we're dealing with neither of those here, we remove the "catch (...)".

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Frank Ch. Eigler  <fche@redhat.com>

	ld: support --build-id=xx mode
	The is patch adds a new ld build-id computation mode, "xx", using
	xxhash in its 128-bit mode.  The patch prereqs the xxhash-devel
	headers being installed, and uses the "all-inlined" model, so no
	run-time or link-time library dependence exists.

	The xxhash mode performs well, saving roughly 20% of total userspace
	run time from an ld job over a 800MB shared library relative to sha1.
	128 bits of good hash should be collision-resistant to a number of
	distinct binaries that numbers in the 2**32 - 2**64 range, even if not
	"crypto" level hash.  Confirmations of this are in progress.

	         ld/configury: add --with-xxhash mode, different from gdb case
	                       because only using it in inline mode

	         ld/ldbuildid.c: add "xx" mode, #if WITH_XXHASH

	         ld/NEWS, ld.texi: mention new option

	         ld/lexsup.c: add enumeration of --build-id STYLES to --help

	         ld/testsuite/ld-elf/build-id.exp: add test case for 0xHEX case
	                                           and conditional for xx case;
	                                           also, simply tcl list syntax

	https://inbox.sourceware.org/binutils/20240917201509.GB26396@redhat.com/

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle ^C in ~scoped_remote_fd
	While reviewing "catch (...)" uses I came across:
	...
		try
		  {
		    fileio_error remote_errno;
		    m_remote->remote_hostio_close (m_fd, &remote_errno);
		  }
		catch (...)
		  {
		    /* Swallow exception before it escapes the dtor.  If
		       something goes wrong, likely the connection is gone,
		       and there's nothing else that can be done.  */
		  }
	...

	This also swallows gdb_exception_quit and gdb_exception_forced_quit.  I don't
	know whether these can actually happen here, but if not it's better to
	accommodate for the possibility anyway.

	Fix this by handling gdb_exception_quit and gdb_exception_forced_quit
	explicitly.

	It could be that "catch (...)" should be replaced by
	"catch (const gdb_exception &)" but that depends on what kind of exception
	remote_hostio_close is expected to throw, and I don't know that, so I'm
	leaving it as is.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Add support for further events.
	This is similar to the previous events that we added, and adds support for
	SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET.
	Though since these are mainly mechanical and not really possible to test,
	they are bundled in one commit.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Add support for IRET events.
	This is similar to the previous events that we added.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Add support for interrupt events.
	Newer Intel CPUs support recording asynchronous events in the PT trace.
	Libipt also recently added support for decoding these.

	This patch adds support for interrupt events, based on the existing aux
	infrastructure.  GDB can now display such events during the record
	instruction-history and function-call-history commands.

	Subsequent patches will add the rest of the events currently supported.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Enable event tracing on Linux for Intel PT.
	Event tracing allows GDB to show information about interesting asynchronous
	events when tracing with Intel PT.  Subsequent patches will add support for
	displaying each type of event.

	Enabling event-tracing unconditionally would result in rather noisy output, as
	breakpoints themselves result in interrupt events.  Which is why this patch adds
	a set/show command to allow the user to enable/disable event-tracing before
	starting a recording. The event-tracing setting has no effect on an already
	active recording.  The default setting is off.   As event tracing will use the
	auxiliary infrastructure added by ptwrite, the user can still disable printing
	events, even when event-tracing was enabled, by using the /a switch for the
	record instruction-history/function-call-history commands.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Add printing support for cfe and evd packets.
	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Print "non-contiguous" for gaps.
	So far we printed "disabled" for gaps, when we saw a ptev_enabled event that
	doesn't have the resumed flag set.  This is wrong, as the actual disabling
	happens with ptev_disabled.  So far this didn't matter, but once we have event
	tracing, there can be events between a ptev_disabled and a ptev_enabled.
	This patch is in preparation for that, and removes the disabled reason in
	favour of a more accurate non-contiguous reason, and adjusts the string we
	print accordingly.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Eliminate catch(...) in pipe_command
	Remove duplicate code in pipe_command using SCOPE_EXIT.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Eliminate catch(...) in target_wait
	Remove duplicate code in target_wait using SCOPE_EXIT.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Eliminate catch(...) in execute_fn_to_string
	Remove duplicate code in execute_fn_to_string using SCOPE_EXIT.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Make scope_exit constructor throw
	While reviewing "catch (...)" uses I came across:
	...
	  scope_exit (EFP &&f)
	    try : m_exit_function ((!std::is_lvalue_reference<EFP>::value
				    && std::is_nothrow_constructible<EF, EFP>::value)
				   ? std::move (f)
				   : f)
	  {
	  }
	  catch (...)
	    {
	      /* "If the initialization of exit_function throws an exception,
		 calls f()."  */
	      f ();
	    }

	...
	and while looking up the origin of the comment here [1] I saw right after:
	...
	throws: Nothing, unless the initialization of exit_function throws
	...

	I think that means that the exception should be rethrown, so fix this by doing
	so.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle ^C in gnu_source_highlight_test
	In gnu_source_highlight_test we have:
	...
	  try
	    {
	      res = try_source_highlight (styled_prog, language_c, fullname);
	    }
	  catch (...)
	    {
	      saw_exception = true;
	    }
	...

	This also swallows gdb_exception_quit and gdb_exception_forced_quit.  I don't
	know whether these can actually happen here, but if not it's better to
	accommodate for the possibility anyway.

	Fix this by handling gdb_exception explicitly, and rethrowing
	gdb_exception_quit and gdb_exception_forced_quit.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Show readline wrapping mode for maint info screen
	With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC
	as used in commit 250f1bbaf33 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with
	wrapping disabled"), we can easily reproduce a failure in
	gdb.tui/wrap-line.exp mentioned in PR testsuite/31201:
	...
	(gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678                         ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout)
	...

	The test-case expects wrapping, but that's disabled by horizontal-scroll-mode.

	Add a new line to "maint info screen", that describes the current readline
	wrapping mode, and use it in the test-case to handle the different cases.

	The reported values for the wrapping mode are as follows.

	Unsupported because of running in batch mode:
	...
	$ gdb -q -batch -ex "maint info screen"
	Readline wrapping mode: unsupported (gdb batch mode).
	...

	Unsupported because the terminal is not capable to move the cursor up:
	...
	$ TERM=dumb gdb -q -ex "maint info screen" -ex q
	Readline wrapping mode: unsupported (terminal is not Cursor Up capable).
	...

	Disabled by horizontal-scroll-mode:
	...
	$ grep horizontal-scroll-mode ~/.inputrc
	set horizontal-scroll-mode on
	$ gdb -q -ex "maint info screen" -ex q
	Readline wrapping mode: disabled (horizontal-scroll-mode).
	...

	Wrap done by readline because terminal is not auto wrap capable:
	...
	$ TERM=ansi gdb -q -ex "maint info screen" -ex q
	Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved).
	...

	Wrap done by terminal autowrap:
	...
	$ TERM=xterm gdb -q -ex "maint info screen" -ex q
	Readline wrapping mode: terminal (terminal is auto wrap capable).
	...

	Tested on x86_64-linux.

	Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Use gdbpy_handle_gdb_exception in valpy_assign_core
	In valpy_assign_core we have:
	...
	  catch (const gdb_exception &except)
	    {
	      gdbpy_convert_exception (except);
	      return false;
	     }
	...

	Use instead:
	...
	  catch (const gdb_exception &except)
	    {
	      return gdbpy_handle_gdb_exception (false, except);
	    }
	...

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Eliminate GDB_PY_SET_HANDLE_EXCEPTION
	Result of:
	...
	$ search="GDB_PY_SET_HANDLE_EXCEPTION ("
	$ replace="return gdbpy_handle_gdb_exception (-1, "
	$ sed -i \
	    "s/$search/$replace/" \
	    gdb/python/*.c
	...

	Also remove the now unused GDB_PY_SET_HANDLE_EXCEPTION.

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Eliminate GDB_PY_HANDLE_EXCEPTION
	Result of:
	...
	$ search="GDB_PY_HANDLE_EXCEPTION ("
	$ replace="return gdbpy_handle_gdb_exception (nullptr, "
	$ sed -i \
	    "s/$search/$replace/" \
	    gdb/python/*.c
	...

	Also remove the now unused GDB_PY_HANDLE_EXCEPTION.

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Add gdbpy_handle_gdb_exception
	I've recently committed two patches:
	- commit 2f8cd40c37a ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often")
	- commit fbf8e4c35c2 ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often")
	which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
	more often, with the goal of making things more consistent.

	Having done that, I wondered if a better approach could be possible.

	Consider GDB_PY_HANDLE_EXCEPTION:
	...
	 /* Use this in a 'catch' block to convert the exception to a Python
	    exception and return nullptr.  */
	 #define GDB_PY_HANDLE_EXCEPTION(Exception)	\
	   do {						\
	     gdbpy_convert_exception (Exception);	\
	     return nullptr;				\
	   } while (0)
	...

	The macro nicely codifies how python handles exceptions:
	- setting an error condition using some PyErr_Set* variant, and
	- returning a value implying that something went wrong
	presumably with the goal that using the macro will mean not accidentally:
	- forgetting to return on error, or
	- returning the wrong value on error.

	The problems are that:
	- the macro hides control flow, specifically the return statement, and
	- the macro hides the return value.

	For example, when reading somewhere:
	...
	  catch (const gdb_exception &except)
	    {
	      GDB_PY_HANDLE_EXCEPTION (except);
	    }
	...
	in order to understand what this does, you have to know that the macro
	returns, and that it returns nullptr.

	Add a template gdbpy_handle_gdb_exception:
	...
	template<typename T>
	[[nodiscard]] T
	gdbpy_handle_gdb_exception (T val, const gdb_exception &e)
	{
	  gdbpy_convert_exception (e);
	  return val;
	}
	...
	which can be used instead:
	...
	  catch (const gdb_exception &except)
	    {
	      return gdbpy_handle_gdb_exception (nullptr, except);
	    }
	...

	[ Initially I tried this:
	...
	template<auto val>
	[[nodiscard]] auto
	gdbpy_handle_gdb_exception (const gdb_exception &e)
	{
	  gdbpy_convert_exception (e);
	  return val;
	}
	...
	with which the usage is slightly better looking:
	...
	  catch (const gdb_exception &except)
	    {
	      return gdbpy_handle_gdb_exception<nullptr> (except);
	    }
	...
	but I ran into trouble with older gcc compilers. ]

	While still a single statement, we now have it clear:
	- that the statement returns,
	- what value the statement returns.

	[ FWIW, this could also be handled by say:
	...
	-      GDB_PY_HANDLE_EXCEPTION (except);
	+      GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr);
	...
	but I still didn't find the fact that it returns easy to spot.

	Alternatively, this is the simplest form we could use:
	...
	      return gdbpy_convert_exception (e), nullptr;
	...
	but the pairing would not necessarily survive a copy/paste/edit cycle. ]

	Also note how making the value explicit makes it easier to check for
	consistency:
	...
	  catch (const gdb_exception &except)
	    {
	      return gdbpy_handle_gdb_exception (-1, except);
	    }

	  if (PyErr_Occurred ())
	    return -1;
	...
	given that we do use the explicit constants almost everywhere else.

	Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify
	the return value, but I assume that this will be generally copy-pasted and
	therefore present no problem.

	Also, there's no longer a guarantee that there's an immediate return, but I
	assume that nodiscard making sure that the return value is not silently
	ignored is sufficient mitigation.

	For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
	in terms of gdbpy_handle_gdb_exception.

	Follow-up patches will eliminate the macros.

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix segfault on invalid debug info
	While looking at PR symtab/31478 (a problem in the cooked indexer with invalid
	dwarf) it occurred to me that I could trigger a similar problem using:
	...
	  Compilation Unit @ offset 0xb2:
	   Length:        0x1f (32-bit)
	   Version:       4
	   Abbrev Offset: 0x6c
	   Pointer Size:  8
	 <0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
	    <be>   DW_AT_language    : 2	(non-ANSI C)
	 <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
	    <c0>   DW_AT_low_pc      : 0x4004a7
	    <c8>   DW_AT_high_pc     : 0x4004b2
	    <d0>   DW_AT_specification: <0xd5>
	 <1><d4>: Abbrev Number: 0
	  Compilation Unit @ offset 0xd5:
	   Length:        0x7 (32-bit)
	   Version:       4
	   Abbrev Offset: 0x7f
	   Pointer Size:  8
	...
	and indeed I get:
	...
	$ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2

	Fatal signal: Segmentation fault
	...

	The problem is that we're calling prepare_one_comp_unit with cu == nullptr and
	comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists:
	...
	      cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false,
	                              m_index_storage->get_abbrev_cache ());

	      prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die,
	                             language_minimal);
	...

	Fix this by bailing out for various types of dummy CUs:
	...
	      if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr
		  || !new_reader.comp_unit_die->has_children)
		return nullptr;
	...

	Also make sure in scan_attributes that this triggers a dwarf error:
	...
	$ gdb -q -batch dw2-inter-cu-error-2
	DWARF Error: cannot follow reference to DIE at 0xd5 \
	  [in module dw2-inter-cu-error-2]
	...

	With target board readnow, the test-case triggers an assertion failure in
	follow_die_offset, so fix this by throwing the same dwarf error.

	While we're at it, make the other check for dummy CUs in
	cooked_indexer::ensure_cu_exists more robust by adding an intermediate test
	for comp_unit_die:
	...
	-  if (result->dummy_p || !result->comp_unit_die->has_children)
	+  if (result->dummy_p || result->comp_unit_die == nullptr
	+      || !result->comp_unit_die->has_children)
	     return nullptr;
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Use expand_all_symtabs in maint expand-symtabs
	When issuing a command "maint expand-symtabs", maintenance_expand_symtabs is
	called with regexp == nullptr, and calls expand_symtabs_matching like so:
	...
	      objfile->expand_symtabs_matching
	       ([&] (const char *filename, bool basenames)
		{
		  /* KISS: Only apply the regexp to the complete file name.  */
		  return (!basenames
			  && (regexp == NULL || re_exec (filename)));
		},
	...

	To expand all symtabs gdb usually uses expand_all_symtabs (used for -readnow),
	but here we try to handle it in the filename_matcher argument.

	Make this more similar to how gdb usually works by using expand_all_symtabs.

	A previous version of the patch instead used a nullptr filename_matcher for
	the regexp == nullptr case.  That approach regressed test-cases
	gdb.dwarf2/dwz-unused-pu.exp and gdb.dwarf2/dw2-dummy.exp.

	Tested on x86_64-linux.

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.exp
	Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol
	from an unused PU is not accessible.

	Passes with the relevant target boards:
	- unix (using the cooked index),
	- readnow (using no index at all),
	- cc-with-gdb-index (using .gdb_index), and
	- cc-with-debug-names (using .debug_names).

	Tested on x86_64-linux.

2024-09-24  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Don't expand non-Ada CUs for info exceptions
	I noticed when running test-case gdb.ada/info_exc.exp with glibc debug info
	installed, that the "info exceptions" command that lists all Ada exceptions
	also expands non-Ada CUs, which includes CUs in
	/lib64/ld-linux-x86-64.so.2 and /lib64/libc.so.6.

	Fix this by:
	- adding a new lang_matcher parameter to the expand_symtabs_matching
	  function, and
	- using that new parameter in the expand_symtabs_matching call in
	  ada_add_global_exceptions.

	The new parameter is a hint, meaning implementations are free to ignore it and
	expand CUs with any language.  This is the case for partial symtabs, I'm not
	sure whether it makes sense to implement support for this there.

	Conversely, when processing a CU with language C and name "<artificial>"
	(as produced by GCC LTO), the CU may not really have a single language and we
	should ignore the lang_matcher.  See also commit d2f67711730
	("Fix 'catch exception' with -flto").

	Now that we have lang_matcher available, also use it to limit name splitting
	styles and symbol matchers to those applicable to the matched languages.

	Without this patch we have (with a gdb build with -O0):
	...
	$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
	real	0m1.866s
	user	0m2.089s
	sys	0m0.120s
	...
	and with this patch we have:
	...
	$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
	real	0m0.469s
	user	0m0.777s
	sys	0m0.051s
	...

	Or, to put it in terms of number of CUs, we have 1853 CUs:
	...
	$ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \
	    -ex start \
	    -ex "maint info symtabs" \
	    | grep -c " name "
	1853
	...

	Without this patch, we have:
	...
	$ gdb -q -batch outputs/gdb.ada/info_exc/foo \
	    -ex start \
	    -ex "info exceptions" \
	    -ex "maint info symtabs" \
	    | grep -c " name "
	1393
	...
	so ~75% of the CUs is expanded, and with this patch we have:
	...
	$ gdb <same-as-above>
	20
	...
	so ~1% of the CUs is expanded.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/32182
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182

2024-09-24  Rohr, Stephan  <stephan.rohr@intel.com>

	testsuite, threads: fix LD_LIBRARY_PATH in 'tls-sepdebug.exp'
	Some compilers (e.g. the Intel compiler) may dynamically link against
	dependencies.  The test uses the 'set env' command to set the
	LD_LIBRARY_PATH to a test specific value.  Update the 'set env' command
	to also provide the users LD_LIBARY_PATH to gdb.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-24  Mark Harmstone  <mark@harmstone.com>

	ld/pdb: Handle DEBUG_S_INLINEELINES data
	The DEBUG_S_INLINEELINES block in the .debug$S section records the line
	numbers in a source file covered by inlined functions. It's similar to
	the DEBUG_S_LINES block, but as it references LF_FUNC_ID types we also
	need to parse it to remap the type numbers.

2024-09-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-23  H.J. Lu  <hjl.tools@gmail.com>

	x86: Enable TLS relocation check only for ELF
	Since TLS relocation check is ELF specific, enable it only for ELF.

		PR gas/32022
		* config/tc-i386.c (x86_tls_error_type): Define only if
		OBJ_MAYBE_ELF or OBJ_ELF is defined.
		(x86_check_tls_relocation): Likewise.
		(x86_report_tls_error): Likewise.
		(i386_assemble): Check TLS relocations only if OBJ_MAYBE_ELF or
		OBJ_ELF is defined.
		(md_show_usage): Output -mtls-check= only if OBJ_MAYBE_ELF or
		OBJ_ELF is defined.

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Avoid large timeout in gdb.base/checkpoint.exp
	I ran the testsuite in an environment simulating a stressed system, and the
	only test-cases that timed out in gdb.base were gdb.base/checkpoint.exp and
	gdb.base/checkpoint-ns.exp (which includes gdb.base/checkpoints.exp).

	In test-case gdb.base/checkpoint.exp there's a part where the timeout is
	increased with 120 seconds (in the default case that's from 10 to 130), to
	accommodate for a single command creating 600+ checkpoints.

	Instead, rewrite the test to present a gdb prompt each time a checkpoint is
	created, for which the default timeout is sufficient.

	Also ensure that the amount of checkpoints added is exactly 600 rather than
	600+.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-23  Tom Tromey  <tromey@adacore.com>

	Automatically add types to Python modules
	PR python/32163 points out that various types provided by gdb are not
	added to the gdb module, so they aren't available for interactive
	inspection.  I think this is just an oversight.

	This patch fixes the problem by introducing a new helper function that
	both readies the type and then adds it to the appropriate module.  The
	patch also poisons PyType_Ready, the idea being to avoid this bug in
	the future.

	v2:
	* Fixed a bug in original patch in gdb.Architecture registration
	* Added regression test for the types mentioned in the bug

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.fortran/info-types.exp
	When running the testsuite in an enviroment that simulates a stressed system,
	I ran into a timeout in test-case gdb.fortran/info-types.exp:
	...
	(gdb) info types^M
	FAIL: gdb.fortran/info-types.exp: info types (timeout)
	...

	This is mainly due the presence of glibc debug info.

	With it installed, I get:
	...
	$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
	real	0m35.969s
	user	0m38.231s
	sys	0m1.007s
	...
	and without:
	...
	$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
	real	0m4.782s
	user	0m5.014s
	sys	0m0.304s
	...

	Fix this by not running to main, which gets us:
	...
	$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
	real	0m0.808s
	user	0m0.789s
	sys	0m0.137s
	...

	Likewise in gdb.mi/mi-sym-info.exp and gdb.mi/mi-complete.exp.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: update comment in code_breakpoint::re_set_default
	Spotted a comment in code_breakpoint::re_set_default that was added in
	commit:

	  commit 6cce025114ccd0f53cc552fde12b6329596c6c65
	  Date:   Fri Mar 3 19:03:15 2023 +0000

	      gdb: only insert thread-specific breakpoints in the relevant inferior

	that was incorrect.  The comment was not updated to take inferior
	specific breakpoints into account.

	This commit just updates the comment, there's no user visible changes
	after this commit.

2024-09-23  Jan Beulich  <jbeulich@suse.com>

	ld/PE: enable secrel testcases also for 64-bit Cygwin
	Plus the others that are grouped there.

2024-09-23  Jan Beulich  <jbeulich@suse.com>

	ld/PE: no base relocs for section (relative) ones
	Even more so than image relative (RVA) relocations, section relative
	ones as well as section ones should not have base relocations created in
	the final PE image. Reportedly section relative relocations will want
	using for TLS support in the (Windows) compiler.

	While there also correct the names for two of the "image base" relocs.

2024-09-23  Nick Clifton  <nickc@redhat.com>

	LD: Document use of SOURCE_DATE_EPOCH in Environment section

	Fix compile time error introduced by d774bf9b3623239a1cfa729afcf048a15da657d3 for non-ELF x86 targets

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix failure in gdb.threads/signal-sigtrap.exp
	The test-case gdb.threads/signal-sigtrap.exp:
	- installs a signal handler called sigtrap_handler for SIGTRAP,
	- sets a breakpoint on sigtrap_handler, and
	- expects the breakpoint to trigger after issuing "signal SIGTRAP".

	Usually, that happens indeed:
	...
	(gdb) signal SIGTRAP^M
	Continuing with signal SIGTRAP.^M
	^M
	Thread 1 "signal-sigtrap" hit Breakpoint 2, sigtrap_handler (sig=5)^M
	28      }^M
	(gdb) PASS: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
	...

	Occasionally, I run into this failure on openSUSE Tumbleweed:
	...
	(gdb) signal SIGTRAP^M
	Continuing with signal SIGTRAP.^M
	^M
	Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M
	__pthread_create_2_1 () at pthread_create.c:843^M
	(gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
	...

	AFAIU, the problem is in the situation that is setup before issuing that
	command, by running to a breakpoint in thread_function:
	...
	void *thread_function (void *arg) {
	  return NULL;
	}
	int main (void) {
	  pthread_t child_thread;
	  signal (SIGTRAP, sigtrap_handler);
	  pthread_create (&child_thread, NULL, thread_function, NULL);
	  pthread_join (child_thread, NULL);
	  return 0;
	}
	...

	In the passing case, thread 2 is stopped in thread_function, and thread 1 is
	stopped somewhere in pthread_join:
	...
	(gdb) info threads^M
	  Id   Target Id                                          Frame ^M
	  1    Thread ... (LWP ...) "signal-sigtrap" __futex_abstimed_wait_common64 ()
	* 2    Thread ... (LWP ...) "signal-sigtrap" thread_function ()
	...

	In the failing case, thread 2 is stopped in thread_function, but thread 1 is
	stopped somewhere in pthread_create:
	...
	(gdb) info threads^M
	  Id   Target Id                                          Frame ^M
	  1    Thread ... (LWP ...) "signal-sigtrap" __GI___clone3 ()
	* 2    Thread ... (LWP ...) "signal-sigtrap" thread_function ()
	...

	What I think happens is that pthread_create blocks SIGTRAP at some point, and
	if the "signal SIGTRAP" command is issued while that is the case, the signal
	becomes pending and consequently there's no longer a guarantee that the signal
	will be delivered to the inferior.

	Instead the signal will be handled by gdb like this:
	...
	(gdb) info signals SIGTRAP
	Signal        Stop	Print	Pass to program	Description
	SIGTRAP       Yes	Yes	No		Trace/breakpoint trap
	...

	Fix this by adding a barrier that ensures that pthread_create is done before
	we issue the "signal SIGTRAP" command.

	Likewise in test-case gdb.threads/signal-command-handle-nopass.exp.

	Using the fixed test-case, I tested my theory by explicitly blocking SIGTRAP:
	...
	+  sigset_t old_ss, new_ss;
	+  sigemptyset (&new_ss);
	+  sigaddset (&new_ss, SIGTRAP);
	+  sigprocmask (SIG_BLOCK, &new_ss, &old_ss);
	+
	   /* Make sure that pthread_create is done once the breakpoint on
	      thread_function triggers.  */
	   pthread_barrier_wait (&barrier);

	   pthread_join (child_thread, NULL);
	+  sigprocmask (SIG_SETMASK, &old_ss, NULL);
	...
	and managed to reproduce the same failure:
	...
	(gdb) signal SIGTRAP^M
	Continuing with signal SIGTRAP.^M
	[Thread 0x7ffff7c00700 (LWP 13254) exited]^M
	^M
	Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M
	0x00007ffff7c80056 in __GI___sigprocmask () sigprocmask.c:39^M
	(gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
	...

	Tested on x86_64-linux.

	PR testsuite/26867
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26867

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/return.exp on arm-linux
	After doing pre-commit testing of some patch on arm-linux, the Linaro CI
	reported:
	...
	FAIL: 1 regressions: 1 improvements

	regressions.sum:
			=== gdb tests ===

	Running gdb:gdb.base/return.exp ...
	ERROR: no fileid for ccd235fdc9bf

	improvements.sum:
			=== gdb tests ===

	Running gdb:gdb.base/return.exp ...
	ERROR: no fileid for 017e9b314c5a
	...

	The problem is the call to allow_float_test.  It calls gdb_exit (for arm-linux
	only), and consequently kills the gdb instance setup by prepare_for_testing:
	...
	if { [prepare_for_testing "failed to prepare" "return"] } {
	     return -1
	}

	set allow_float_test [allow_float_test]
	...

	Fix this by moving the call to allow_float_test to before prepare_for_testing.

	Tested on arm-linux and x86_64-linux.

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make parse_args error out on remaining args
	I noticed that introducing a typo here in gdb.mi/mi-breakpoint-changed.exp:
	...
	     set bp_re [mi_make_breakpoint \
	-		   -number $bp_nr \
	+		   -nunber $bp_nr \
	 		   -type dprintf \
	 		   -func marker \
	 		   -script [string_to_regexp {["printf \"arg\" \""]}]]
	...
	didn't make the test fail.

	Proc mi_make_breakpoint uses parse_args, but does not check the remaining args
	as parse_args suggests:
	...
	proc parse_args { argset } {
	    parse_list 2 args $argset "-" false

	    # The remaining args should be checked to see that they match the
	    # number of items expected to be passed into the procedure
	}
	...

	We could add the missing check in mi_make_breakpoint, but I think the problem
	is likely to occur again because the name parse_args does not suggest that
	further action is required.

	Fix this instead by:
	- copying proc parse_args to new proc parse_some_args,
	- adding new proc check_no_args_left, and
	- calling check_no_args_left in parse_args.

	Also be more strict in a few places where we do lassign for remaining args:
	...
	    lassign $args a b
	...

	There may be more arguments left in $args, so check that that's not the case
	using check_no_args_left:
	...
	    set args [lassign $args a b]
	    check_no_args_left
	...

	Fix a few test-cases that trigger on the stricter checking.

	Tested on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

	PR testsuite/32129
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/empty-host-env-vars.exp
	On aarch64-linux (debian testing) with test-case
	gdb.base/empty-host-env-vars.exp I ran into:
	...
	(gdb) show index-cache directory^M
	The directory of the index cache is "/home/linux/.cache/gdb".^M
	(gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory
	...

	Without changing any environment variables, the value of the index-cache dir
	is:
	...
	$ gdb -q -batch -ex "show index-cache directory"
	The directory of the index cache is "/home/linux/.cache/gdb".
	...
	and the expectation of the test-case is that setting HOME to empty will
	produce an empty dir, but what it actually produces is:
	...
	$ HOME= gdb -q -batch -ex "show index-cache directory"
	The directory of the index cache is "/home/linux/.cache/gdb".
	...

	There's nothing wrong with that behaviour, the dir is simply constructed using
	XDG_CACHE_HOME which happens to be explictly set to its default value
	$HOME/.cache [1]:
	...
	$ echo $XDG_CACHE_HOME
	/home/linux/.cache
	...
	and indeed also setting that variable to empty gets us the expected empty dir:
	...
	$ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory"
	gdb: warning: Couldn't determine a path for the index cache directory.
	The directory of the index cache is "".
	...

	Furthermore, the test-case assumption that setting variables to empty either
	produces the original dir or an empty dir is incorrect.

	Say that XDG_CACHE_HOME has a non-default value:
	...
	$ echo $XDG_CACHE_HOME
	/home/linux/my-xdg-cache-home
	$ gdb -q -batch -ex "show index-cache directory"
	The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb".
	...
	then setting that variable to empty:
	...
	$ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory"
	The directory of the index cache is "/home/linux/.cache/gdb".
	...
	does change the value of the dir.

	Fix this by making the test-case less specific.

	While we're at it, factor out regexps re_pre and re_post to make regexps more
	readable, and use string_to_regexp to reduce quoting.

	Tested on aarch64-linux.

	PR testsuite/32132
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132

	[1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/attach-deleted-exec.exp with NFS
	With test-case gdb.base/attach-deleted-exec.exp I ran into:
	...
	(gdb) attach 121552^M
	Attaching to process 121552^M
	Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^M
	Reading symbols from /lib64/libm.so.6...^M
	(No debugging symbols found in /lib64/libm.so.6)^M
	Reading symbols from /lib64/libc.so.6...^M
	(No debugging symbols found in /lib64/libc.so.6)^M
	Reading symbols from /lib64/ld64.so.2...^M
	(No debugging symbols found in /lib64/ld64.so.2)^M
	0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M
	(gdb) FAIL: $exp: attach to process with deleted executable
	....

	The .nfs file indicates:
	- that the file has been removed on the NFS server, and
	- that the file is still open on the NFS client.

	Fix this by detecting this situation, and declaring the test for filename
	/proc/PID/exe unsupported.

	Tested on:
	- x86_64-linux (setup without NFS)
	- ppc64le-linux (setup with NFS)

	PR testsuite/32130
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.trace/entry-values.exp on riscv64-linux
	On riscv64-linux, with test-case gdb.trace/entry-values.exp I run into:
	...
	(gdb) disassemble bar^M
	Dump of assembler code for function bar:^M
	   0x0000000000000646 <+0>:     addi    sp,sp,-48^M
	   0x0000000000000648 <+2>:     sd      ra,40(sp)^M
	   0x000000000000064a <+4>:     sd      s0,32(sp)^M
	   0x000000000000064c <+6>:     addi    s0,sp,48^M
	   0x000000000000064e <+8>:     mv      a5,a0^M
	   0x0000000000000650 <+10>:    sw      a5,-36(s0)^M
	   0x0000000000000654 <+14>:    li      a5,2^M
	   0x0000000000000656 <+16>:    sw      a5,-20(s0)^M
	   0x000000000000065a <+20>:    lw      a4,-20(s0)^M
	   0x000000000000065e <+24>:    lw      a5,-36(s0)^M
	   0x0000000000000662 <+28>:    mv      a1,a4^M
	   0x0000000000000664 <+30>:    mv      a0,a5^M
	   0x0000000000000666 <+32>:    jal     0x628 <foo>^M
	   0x000000000000066a <+36>:    mv      a5,a0^M
	   0x000000000000066c <+38>:    mv      a0,a5^M
	   0x000000000000066e <+40>:    ld      ra,40(sp)^M
	   0x0000000000000670 <+42>:    ld      s0,32(sp)^M
	   0x0000000000000672 <+44>:    addi    sp,sp,48^M
	   0x0000000000000674 <+46>:    ret^M
	End of assembler dump.^M
	(gdb) FAIL: gdb.trace/entry-values.exp: disassemble bar
	FAIL: gdb.trace/entry-values.exp: find the call or branch instruction offset in bar
	...

	Fix this by setting call_insn to jal for riscv64.

	Tested on riscv64-linux and x86_64-linux.

2024-09-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp
	On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while
	I run into (edited for readability):
	...
	(gdb) ^M
	<LOTS-OF-SPACES>-data-evaluate-expression $a^M
	-data-evaluate-^done,value="\"FIRST COMMAND\""^M
	expression $b(gdb) ^M
	^M
	^done,value="\"TEST COMPLETE\""^M
	(gdb) ^M
	PASS: $exp: args=: look for first command output, command length 236
	FAIL: $exp: args=: look for second command output, command length 236 (timeout)
	...

	This is more likely to trigger when running the test-case using
	taskset -c <cpu> (where in a big.little setup we pick a little cpu).

	The setup here is that the test-case issues these two commands at once:
	...
	-data-evaluate-expression $a
	-data-evaluate-expression $b
	...
	where the length of the first command is artificially increased by prefixing
	it with spaces, show as <LOTS-OF-SPACES> above.

	What happens is that gdb, after parsing the first command, executes it.
	Then the output of the first command intermixes with the echoing of the second
	command, which produces this line containing the first prompt:
	...
	expression $b(gdb) ^M
	...
	which doesn't match the \r\n prefix of the regexp supposed to consume the
	first prompt:
	...
	           -re "\r\n$mi_gdb_prompt" {
	...

	Fix this by dropping the \r\n prefix.

	Tested on aarch64-linux.

	PR testsuite/29781
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781

2024-09-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-22  H.J. Lu  <hjl.tools@gmail.com>

	x86: Turn PLT32 to PC32 only for PC-relative relocations
	commit 292676c15a615b5a95bede9ee91004d3f7ee7dfd
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Thu Feb 13 13:44:17 2020 -0800

	    x86: Resolve PLT32 reloc aganst local symbol to section

	resolved PLT32 relocation against local symbol to section and

	commit 2585b7a5ce5830e60a089aa2316a329558902f0c
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Sun Jul 19 06:51:19 2020 -0700

	    x86: Change PLT32 reloc against section to PC32

	turned PLT32 relocation against section into PC32 relocation.  But these
	transformations are valid only for PC-relative relocations.  Add fx_pcrel
	check for PC-relative relocations when performing these transformations
	to keep PLT32 relocation in `movq $foo@PLT, %rax`.

	gas/

		PR gas/32196
		* config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel
		for PLT32 relocations.
		(i386_validate_fix): Turn PLT32 relocation into PC32 relocation
		only if fixp->fx_pcrel is set.
		* testsuite/gas/i386/reloc32.d: Updated.
		* testsuite/gas/i386/reloc64.d: Likewise.
		* testsuite/gas/i386/reloc32.s: Add PR gas/32196 test.
		* testsuite/gas/i386/reloc64.s: Likewise.

	ld/

		PR gas/32196
		* testsuite/ld-x86-64/plt3.s: New file.
		* testsuite/ld-x86-64/x86-64.exp: Run plt3.

2024-09-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Limit xfail in gdb.ada/call_pn.exp
	Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only
	necessary for gcc 8 and 9.

	Fix this by limiting the xfail to those releases.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.ada/call_pn.exp
	With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into
	this timeout:
	...
	(gdb) maint expand-symtabs^M
	FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout)
	...

	The timeout was related to running the cpu at base frequency of 400Mhz instead
	of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core).

	But when investigating the test-case I realized that the maint expand-symtabs
	could be limited to the source files, so use that to speed up the test-case.

	Tested on x86_64-linux.

	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/32177
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177

2024-09-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-cases
	When running the testsuite in an enviroment simulating a stressed system, I
	ran into timeouts in three test-cases in gdb.dwarf2:
	- gdb.dwarf2/count.exp,
	- gdb.dwarf2/implptrconst.exp, and
	- gdb.dwarf2/implptrpiece.exp.

	In all three cases, -readnow is used which results in symtabs being expanded for
	the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2.

	We could address this by limiting the scope of -readnow to the executable, but
	after reviewing the test-cases there doesn't seem to be a clear reason to use
	-readnow.

	Fix this by dropping the -readnow.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-20  Cui, Lili  <lili.cui@intel.com>

	x86: Add tls check in gas
	Assembler shouldn't accept invalid TLS instructions, TLS relocations
	can only be used with specific instructions as specified in TLS psABI
	and linker issues an error when TLS relocations are used with wrong
	instructions or format. Since it is inconvenient for gcc to rely on
	linker to report errors, adding TLS check in the assembler stage so
	that gcc can know TLS errors earlier.

	gas/ChangeLog:

	        PR gas/32022
	        * config.in: Regenerate.
	        * config/tc-i386.c
	        *(enum x86_tls_error_type): New.
	        *(struct _i386_insn): Added has_gotrel to indicate whether TLS
		relocations need to be checked.
	        (x86_check_tls_relocation): Added a new function to check TLS
		relocation.
	        (x86_report_tls_error): Created a new function to report TLS error.
	        (i386_assemble): Handle x86_check_tls_relocation.
	        (lex_got): Set i.has_gotrel.
	        (OPTION_MTLS_CHECK): Added a new option to contrl TLS check.
	        (struct option): Ditto.
	        (md_parse_option): Ditto.
	        (md_show_usage): Ditto.
	        * configure.ac: Added a new option to check TLS relocation by
		default.
	        * configure: Regenerated.
	        * doc/c-i386.texi: Document -mtls-check=.
	        * testsuite/gas/i386/i386.exp: Added new tests.
	        * testsuite/gas/i386/ilp32/ilp32.exp: Ditto.
	        * testsuite/gas/i386/ilp32/reloc64.d: Disable TLS check for it.
	        * testsuite/gas/i386/ilp32/x32-tls.d: Ditto.
	        * testsuite/gas/i386/inval-tls.l: Added more test cases.
	        * testsuite/gas/i386/inval-tls.s: Ditto.
	        * testsuite/gas/i386/reloc32.d: Disable TLS check for it.
	        * testsuite/gas/i386/reloc64.d: Ditto.
	        * testsuite/gas/i386/x86-64-inval-tls.l: Added more test cases.
	        * testsuite/gas/i386/x86-64-inval-tls.s: Ditto.
	        * testsuite/gas/i386/x86-64.exp: Added new tests.
	        * testsuite/gas/i386/ilp32/x32-inval-tls.l: New test.
	        * testsuite/gas/i386/ilp32/x32-inval-tls.s: Ditto.
	        * testsuite/gas/i386/ilp32/x86-64-tls.d: Ditto.
	        * testsuite/gas/i386/tls.d: Ditto.
	        * testsuite/gas/i386/tls.s: Ditto.
	        * testsuite/gas/i386/x86-64-tls.d: Ditto.
	        * testsuite/gas/i386/x86-64-tls.s: Ditto.

	ld/ChangeLog:

	        PR gas/32022
	        * testsuite/ld-i386/tlsgdesc1.d: Disable TLS check for it.
	        * testsuite/ld-i386/tlsgdesc2.d: Ditto.
	        * testsuite/ld-i386/tlsie2.d: Ditto.
	        * testsuite/ld-i386/tlsie3.d: Ditto.
	        * testsuite/ld-i386/tlsie4.d: Ditto.
	        * testsuite/ld-i386/tlsie5.d: Ditto.
	        * testsuite/ld-i386/tlsgdesc3.d: Ditto.
	        * testsuite/ld-x86-64/tlsdesc3.d: Ditto.
	        * testsuite/ld-x86-64/tlsdesc4.d: Ditto.
	        * testsuite/ld-x86-64/tlsie2.d: Ditto.
	        * testsuite/ld-x86-64/tlsie3.d: Ditto.
	        * testsuite/ld-x86-64/tlsie5.d: Ditto.
	        * testsuite/ld-x86-64/tlsdesc5.d: Ditto.

2024-09-20  H.J. Lu  <hjl.tools@gmail.com>

	ld: Use --no-rosegment to ld for PR ld/22393 tests
	The commit

	bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map

	moves the .note.build-id section before text sections.  When --rosegment
	and -z separate-code are used together, the .note.gnu.property section
	is placed between the .note.build-id section and text sections in the
	same PT_LOAD segment by orphan placement.  Pass --no-rosegment to ld for
	PR ld/22393 tests to avoid linker test failures.

		PR ld/32190
		* testsuite/ld-elf/pr22393-2a.rd: Pass --no-rosegment to ld.
		* testsuite/ld-elf/pr22393-2b.rd: Likewise.
		* testsuite/ld-elf/shared.exp: Pass --no-rosegment to ld when
		building pr22393-2 tests.
		* testsuite/ld-x86-64/pr22393-3a.rd: Pass --no-rosegment to ld.
		* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Pass --no-rosegment to ld when
		building pr22393-3 tests.

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb: fully separate coff and elf reading from dbx
	With the previous commits, the only thing entangling elf and coff file
	reading with dbx file reading is the functions
	{elf|coff}stab_build_psymtabs, defined in dbxread.c. These functions
	depend on dbx_symfile_read.

	To solve this, I renamed read_stabs_symtab to read_stabs_symtab_1, and
	created a function with the original name that does what
	dbx_symfile_read used to do.

	This way, dbx_symfile_read can just call read_stabs_symtab, and the elf
	and coff psymtab builders can also call it directly, fully disentangling
	the readers, which would allow us to selectively not compile dbxread in
	the future.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Move read_dbx_symtab to stabsread, and rename to read_stabs_symtab
	Despite the name, read_dbx_symtab is not only used for the dbx file
	format (also called the aout format). It is used by elf and coff
	implicitly as well. So I think it makes more sense to have this function
	in the generic stabsread file, so that reading elf files or coff files
	depends less on GDB's ability to read dbx files.

	There were 11 static functions in dbxread that were onlyl helper
	functions, they were moved and kept as static in stabsread.c. Notably,
	dbx_read_symtab - which is installed as a callback on legacy_psymtab
	for aout, elf and coff at least - has been moved to stabsread.c and
	renamed as well; the function that is specific to aout is
	dbx_symfile_read, and that hasn't been moved.

	Some macros had to be moved as well, but since they are still used
	in dbxread, they were moved to the .h file that the struct symloc
	is declared, so anyone can properly use the struct.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Move dbx_end_psymtab to stabsread, and rename to stabs_end_psymtab
	This function is used by multiple stabs readers (even if not all), and
	the comment in stabsread.h even acknowledges it. I believe that the
	comment is incorrect in saying that the function should be in dbxread
	because not everyone uses it. If any one reader other than dbx uses
	it, the function should be in stabsread, in my opinion.

	This commit makes also renames the function to stabs_end_psymtab since,
	again, this is not specific to dbx/aout format.

	struct symloc had to be moved because stabs_end_psymtab dereferences
	symloc objects, so stabsread.c must be aware of the full struct.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Move process_one_symbol to stabsread.c
	The function process_one_symbol was defined in the file dbxread.c, but
	this function is used by all file formats that handle stabs debug
	information. It makes much more sense for it to be in the stabsread.c
	file instead.

	To move that function, many other static functions had to be moved from
	dbxread. A few were only used by process_one_symbol, so they're still
	static, but most were used by other functions still in dbxread, so they
	are being exported by stabsread.h

	Finally, the registry entry has been moved as well, seeing as it was
	already exported by gdb-stabs.h, and stabsread.c will need it to
	properly use the newly added function.

	With this change, reading mdebug files is totally independent of reading
	dbx.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb: Make dbxread rely less on global variables
	The file dbxread.c, which is responsible for reading stabs information
	for multiple file formats, relies heavily on setting and using global
	variables over the course of reading symbols.

	Future patches aim to make stabs reading more file format independent,
	and this patch starts that change by introducing a stabs_context struct,
	that will hold all the relevant variables. This context struct is saved
	on the registry key inside the objfile being read. Some of those global
	variables have been deemed irrelevant:
	* dbxread_objfile - Since we're saving in an objfile, this is redundant
	* symfile_bfd - It is trivial to get the bfd pointer from the objfile,
	  so also unnecessary
	* string_table_offset - was never initialized, just used to set a value.
	  That usage was substituted by a hardcoded 0
	* next_file_string_table_offset - was only used by read_dbx_symtab, so
	  it was turned into a local variable there.

	As I was moving variables, I also couldn't think of a good reason for
	the bincl_list to be a pointer, so it was changed to just be an
	std::vector.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  Guinevere Larsen  <guinevere@redhat.com>

	gdb/testsuite: rework bp-cond-failure to not depend on inlining
	The test gdb.base/bp-cond-failure is implicitly expecting that the
	function foo will be inlined twice and gdb will be able to find 2
	locations to place a breakpoint. When clang is used, gdb only finds
	one location which causes the test to fail. Since the test is not
	worried about handling breakpoints on inlined functions, but rather on
	the format of the message on a breakpoint condition fail, this seems
	like a false fail report.

	This commit reworks the test to be in c++, and uses function overloading
	to ensure that 2 locations will always be found. Empirical testing
	showed that, for clang, we will land on location 2 with the currest exp
	commands, no matter the order of the functions declared, whereas for gcc
	it depends on the order that functions were declared, so they are
	ordered to always land on the second location, this way we are able to
	hardcode it and check for it.

	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-20  H.J. Lu  <hjl.tools@gmail.com>

	ld: Change -z one-rosegment to --rosegment in comments
	There is no such linker command-line option, -z one-rosegment.  Replace
	it with --rosegment in comments.

		* genscripts.sh: Change -z one-rosegment to --rosegment in
		comments.

2024-09-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-20  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Disable PIE on PR gas/32189 test
	Disable PIE on PR gas/32189 test, which contains the non-PIE assembly
	source, to support GCC defaulted to PIE.

		PR gas/32189
		* testsuite/ld-x86-64/x86-64.exp: Pass $NOPIE_LDFLAGS to linker
		on PR gas/32189 test.

2024-09-19  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Never make R_X86_64_GOT64 section relative
	R_X86_64_GOT64 relocation should never be made section relative.  Change
	tc_i386_fix_adjustable to return 0 for BFD_RELOC_X86_64_GOT64.

	gas/

		PR gas/32189
		* config/tc-i386.c (tc_i386_fix_adjustable): Return 0 for
		BFD_RELOC_X86_64_GOT64.
		* testsuite/gas/i386/reloc64.d: Updated.
		* testsuite/gas/i386/reloc64.s: Add more tests for R_X86_64_GOT64
		and R_X86_64_GOTOFF64.

	ld/

		PR gas/32189
		* testsuite/ld-x86-64/x86-64.exp: Run PR gas/32189 test.
		* testsuite/ld-x86-64/pr32189.s: New file.

2024-09-19  Guinevere Larsen  <guinevere@redhat.com>

	gdb/MAINTAINERS: update my email address
	Sync the maintainers file with my new email address

2024-09-19  Nick Clifton  <nickc@redhat.com>

	ld: Move the .note.build-id section to near the start of the memory map.
	This helps GDB to locate the debug information associated with a core dump.
	Core dumps include the first page of an executable's image, and if this
	page include the .note.build-id section then GDB can find it and then track
	down a debug info file for that build-id.

2024-09-19  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32096 UBSAN issues in gprofng
	Fixed UBSAN runtime errors such as:
	 - member call on address which does not point to an object of type 'Vector'
	 - load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte alignment

	gprofng/ChangeLog
	2024-09-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		PR gprofng/32096
		* libcollector/unwind.c: Fix UBSAN runtime errors.
		* src/CallStack.cc (add_stack_java, add_stack_java_epilogue):
		Change argument type to Vector<Histable*>*.
		* src/Experiment.cc (update_ts_in_maps): Change variable type.
		* src/Experiment.h: Change field type to Vector<Histable*>*.

2024-09-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-18  Xin Wang  <yw987194828@gmail.com>

	LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata
	LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata.

2024-09-18  H.J. Lu  <hjl.tools@gmail.com>

	x86/APX: Don't promote AVX/AVX2 instructions out of APX spec
	V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted
	to support EGPR in APX spec.  Don't promote them out of APX spec.  This
	commit effectively reverted:

	ec3babb8c10 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
	5a635f1f59a x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}
	eea4357967b x86/APX: VROUND{P,S}{S,D} can generally be encoded

	gas/

		PR gas/32171
		* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add
		V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR.
		* testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove
		V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests
		with EGPR.
		* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated.
		* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise.

	opcodes/

		PR gas/32171
		* i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and
		VROUND{P,S}{S,D} entries with EGPR.
		* i386-tbl.h: Regenerated.

2024-09-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-17  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: skip gdb.mi/dw2-ref-missing-frame.exp with clang
	The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set
	debug information by hand, using a .S file and assembly labels to get
	addresses. Unfortunately, clang will always re-arrange the global labels
	to be side by side, making high and low PC for CUs and functions be the
	same, and thus they will all be empty ranges. This makes the test fail,
	since we never technically enter the functions that we want to check.

	This commit skips that test when using clang. If we ever port this test
	to use the dwarf assembler, we can reenable it with clang.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-17  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix gdb.mi/mi-var-cp.exp with clang
	The inline tests in gdb.mi/mi-var-cp.cc were failing when using clang to
	run the test. This happened because inline tests want to step past the C
	statements and then run the TCL tests, but in mi-var-cp.cc the statement
	to be stepped past is "return s2.i;". Since clang links the epilogue
	information to the return statement, not the closing brace,
	single-stepping past return had us exiting the function - which made the
	expressions invalid.

	This commit fixes this by making the function have 2 C statements, and
	the return one be after all inline tests, so we know GDB won't leave the
	function before running the create_varobj tests.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-17  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix gdb.mi/mi-catch-cpp-exceptions.exp with clang
	Clang adds line table information for a try/catch block differently to
	gcc. Instead of linking the instructions related to __cxa_begin_catch to
	the line containing the "catch" statement in the source code, it links
	to the closing brace of the try block.

	This was causing gdb.mi/mi-catch-cpp-exceptions.exp to fail when tested
	with clang. The test was updated to have the catch in the same line as
	the closing brace so it passes with no additional modifications with
	clang.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-16  Tom Tromey  <tromey@adacore.com>

	Fix typo in py-arch.exp
	I found a typo in a test name in py-arch.exp.

2024-09-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS: Discard redundant instruction from DDIV/DREM macros
	A sequence such as:

		li	at,-1
		bne	xx,at,0f
		 li	at,1
		dsll32	at,at,0x1f

	is produced in the expansion of the DDIV and DREM assembly macros, where
	a redundant `li at,1' instruction is used to load an intermediate value
	of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f'
	yielding 0x8000000000000000.  However this value likewise results from
	left-shifting the value of -1, already present in $at at this point.

	Remove the extraneous instruction then, shortening the sequence emitted.
	Adjust dumps in the testsuite accordingly.

2024-09-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Print instructions in hex in division tests
	Add `--show-raw-insn' to division tests so as to verify branch offsets
	without the need to know actual offsets into the text section individual
	instructions have been assembled at.  Add `-z' where applicable to make
	interlock NOP instructions appear in output so as to verify them without
	the need to know the offsets too.  Replace individual offsets to match
	against with generic patterns so that a change in the expansion of an
	assembly macro does not affect code that follows.

	MIPS/opcodes: Rework documentation for instruction args
	Rewrite the inline documentation for the characters used in the `args'
	member of `struct mips_opcode' to make it consistent in terms of style
	and formatting.  Discard references to inexistent macros.

2024-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix amd_dbgapi_target_breakpoint::re_set's signature
	Following

	        commit 6cce025114ccd0f53cc552fde12b6329596c6c65
	        Date:   Fri Mar 3 19:03:15 2023 +0000

	            gdb: only insert thread-specific breakpoints in the relevant inferior

	... when building amd-dbgapi-target.c:

	      CXX    amd-dbgapi-target.o
	    /home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override
	      486 |   void re_set () override;
	          |        ^~~~~~

	Update the signature to match the base.

	Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692

2024-09-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-14  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"
	After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
	this debug info:
	...
	 <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
	    <120>   DW_AT_specification: <0x130>
	 <2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
	    <125>   DW_AT_name        : val1
	    <12a>   DW_AT_const_value : 1
	 <2><12b>: Abbrev Number: 0
	 <1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
	    <12d>   DW_AT_name        : ns
	 <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
	    <131>   DW_AT_name        : e
	    <133>   DW_AT_type        : <0x118>
	    <137>   DW_AT_declaration : 1
	...
	I run into an assertion failure:
	...
	(gdb) file enum-type^M
	Reading symbols from enum-type...^M
	cooked-index.h:214: internal-error: get_parent: \
	  Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
	...

	This was reported in PR32160 comment 1.

	This is a regression since commit 4e417d7bb1c ("Change handling of
	DW_TAG_enumeration_type in DWARF scanner").

	Fix this by reverting the commit.

	[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
	same commit. ]

	That allows us to look at the output of "maint print objfiles", and for val1
	we get an entry without parent:
	...
	    [27] ((cooked_index_entry *) 0x7fbbb4002ef0)
	    name:       val1
	    canonical:  val1
	    qualified:  val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0x124
	    parent:     ((cooked_index_entry *) 0)
	...
	which is incorrect, as noted in that same comment, but an improvement over the
	assertion failure, and I don't think that ever worked.  This is to be
	addressed in a follow-up patch.

	Reverting the commit begs the question: what was it trying to fix in the first
	place, and do we need a different fix?  I've investigated this and filed
	PR32160 to track this.

	My guess is that the commit was based on a misunderstand of what we track
	in cooked_indexer::m_die_range_map.

	Each DIE has two types of parent DIEs:
	- a DIE that is the parent as indicated by the tree structure in which DIEs
	  occur, and
	- a DIE that represent the parent scope.

	In most cases, these two are the same, but some times they're not.

	The debug info above demonstrates such a case.  The DIE at 0x11f:
	- has a tree-parent: the DIE representing the CU, and
	- has a scope-parent: DIE 0x12c representing namespace ns.

	In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
	tried to add a tree-parent instead.

	So, I don't think we need a different fix, and propose we backport the reversal
	for gdb 15.2.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160

2024-09-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add regression test for PR32158
	Consider test-case:
	...
	namespace ns {
	  enum class ec {
	    val2 = 2
	  };
	}

	int main () {
	  return (int)ns::ec::val2;
	}
	...
	compiled with debug info:
	...
	$ g++ test.c -g
	...

	When looking at the cooked index entry for val2 using "maint print objfiles",
	we get:
	...
	    [7] ((cooked_index_entry *) 0x7f8ecc002ef0)
	    name:       val2
	    canonical:  val2
	    qualified:  ns::val2
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0xe9
	    parent:     ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
	...
	which is wrong, there is no source level entity ns::val2.

	This is PR symtab/32158.

	This is a regression since commit 4e417d7bb1c ("Change handling of
	DW_TAG_enumeration_type in DWARF scanner").

	Reverting the commit on current trunk fixes the problem, and gets us instead:
	...
	    [7] ((cooked_index_entry *) 0x7fba70002ef0)
	    name:       val2
	    canonical:  val2
	    qualified:  ns::ec::val2
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0xe9
	    parent:     ((cooked_index_entry *) 0x7fba70002ec0) [ec]
	...

	Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158

2024-09-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900.
	Consider the following test-case:
	...
	$ cat a.h
	namespace ns {

	class A {
	public:
	  enum {
	    val1 = 1
	  };
	};

	}
	$ cat main.c

	ns::A a;

	int
	main (void)
	{
	  return 0;
	}
	$ cat val1.c

	int u1 = ns::A::val1;
	...
	compiled with debug info:
	...
	$ g++ main.c val1.c -g
	...

	When trying to print ns::A::val with current trunk and gdb 15.1 we get:
	...
	$ gdb -q -batch a.out -ex "print ns::A::val1"
	There is no field named val1
	...

	This PR c++/31900.

	With gdb 14.2 we get the expected:
	...
	$ gdb -q -batch a.out -ex "print ns::A::val1"
	$1 = ns::A::val1
	...

	This is a regression since commit 4e417d7bb1c ("Change handling of
	DW_TAG_enumeration_type in DWARF scanner").

	Reverting the commit on current trunk fixes the problem.

	So how does this problem happen?

	First, let's consider the current trunk, with the commit reverted.

	Gdb looks for the entry ns::A::val1, and find this entry:
	...
	    [29] ((cooked_index_entry *) 0x7f7830002ef0)
	    name:       val1
	    canonical:  val1
	    qualified:  ns::A::val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0x15a
	    parent:     ((cooked_index_entry *) 0x7f7830002ec0) [A]
	...
	and expands the corresponding CU val1.c containing this debug info:
	...
	 <2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
	    <14b>   DW_AT_name        : A
	    <14d>   DW_AT_byte_size   : 1
	 <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
	    <151>   DW_AT_encoding    : 7       (unsigned)
	    <152>   DW_AT_byte_size   : 4
	    <153>   DW_AT_type        : <0x163>
	    <159>   DW_AT_accessibility: 1      (public)
	 <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
	    <15b>   DW_AT_name        : val1
	    <15f>   DW_AT_const_value : 1
	 <4><160>: Abbrev Number: 0
	 <3><161>: Abbrev Number: 0
	 <2><162>: Abbrev Number: 0
	...
	after which it finds ns::A::val1 in the expanded symtabs.

	Now let's consider the current trunk as is (so, with the commit present).

	Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
	entry is missing its parent:
	...
	   [29] ((cooked_index_entry *) 0x7f5240002ef0)
	    name:       val1
	    canonical:  val1
	    qualified:  val1
	    DWARF tag:  DW_TAG_enumerator
	    flags:      0x0 []
	    DIE offset: 0x15a
	    parent:     ((cooked_index_entry *) 0)
	...

	Then gdb looks for the entry ns::A, and finds this entry:
	...
	   [3] ((cooked_index_entry *) 0x7f5248002ec0)
	    name:       A
	    canonical:  A
	    qualified:  ns::A
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0xdd
	    parent:     ((cooked_index_entry *) 0x7f5248002e90) [ns]
	...
	which corresponds to this debug info, which doesn't contain val1
	due to -fno-eliminate-unused-debug-types:
	...
	 <2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
	    <de>   DW_AT_name        : A
	    <e0>   DW_AT_byte_size   : 1
	 <2><e3>: Abbrev Number: 0
	...

	Gdb expands the corresponding CU main.c, after which it doesn't find
	ns::A::val1 in the expanded symtabs.

	The root cause of the problem is the missing parent on the val1
	cooked_index_entry, but this only becomes user-visible through the
	elaborate scenario above.

	Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
	for this problem that doesn't rely on expansion state or
	-feliminate-unused-debug-types, but simply tests for the root cause by
	grepping for ns::A::val1 in the output of "maint print objfile".

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900

2024-09-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-13  oltolm  <oleg.tolmatcev@gmail.com>

	gdb dap: introduce stopOnEntry option
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-13  Tom Tromey  <tom@tromey.com>

	Update more types for section index change
	Commit f89276a2f3e ("change type of `general_symbol_info::m_section`
	to int") did what it says in the title -- changed the type of the
	section index from short to int.  However, it seems incomplete, in
	that there are uses of the section index that use the type 'short'.

	This patch fixes the ones I found, first by searching for
	"short.*sect" and then by looking at all the callers of section_index
	(and then functions called with the resulting value) just to try to be
	more sure.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-09-13  Tom Tromey  <tromey@adacore.com>

	Fix quoting in gdb-add-index.sh
	When the filename quoting change was merged into the AdaCore tree, we
	saw a regression in a test setup that uses the DWARF 5 index (that is
	running gdb-add-index), and a filename with a space in it.

	Initially I thought this was a change in the 'file' command -- but
	looking again, I found out that 'file' has worked this way for a
	while, and our immediate error was caused by the (documented) change
	to "save gdb-index".

	While I'm not sure why this test was working previously, it seems to
	me that gdb-add-index.sh requires a change to quote the arguments to
	"file" and "save gdb-index".

	While working on this, though, it seemed to me that multiple other
	spots needed quoting for the script to work correctly.  And, I was
	unable to get quoting working correctly in the objcopy calls, so I
	split it into multiple different invocations.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-09-13  Tom Tromey  <tromey@adacore.com>

	Add quoting to 'file' invocations in DAP
	Oleg Tolmatcev noticed that DAP launch and attach requests don't
	properly handle Windows filenames, because "file" doesn't handle the
	backslash characters correctly.  This patch adds quoting to the
	command in an attempt to fix this.

2024-09-13  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: use owning_intrusive_list for solib list
	Functions implementing `solib_ops::current_sos` return a list of solib
	object, transferring the ownership to their callers.  However, the
	return type, `intrusive_list<solib>`, does not reflect that.

	Also, some of these functions build these lists incrementally, reading
	this from the target for each solib.  If a target read were to throw,
	for instance, the already created solibs would just be leaked.

	Change `solib_ops::current_sos` to return an owning_intrusive_list to
	address that.  Change `program_space::so_list` to be an
	owning_intrusive_list as well.  This also saves us doing a few manual
	deletes.

	Change-Id: I6e4071d49744874491625075136c59cce8e608d4
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-13  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport/intrusive-list: add owning_intrusive_list
	It occured to me that `intrusive_list<solib>`, as returned by
	`solib_ops::current_sos`, for instance, is not very safe.  The
	current_sos method returns the ownership of the solib objects
	(heap-allocated) to its caller, but the `intrusive_list<solib>` type
	does not convey it.  If a function is building an
	`intrusive_list<solib>` and something throws, the solibs won't
	automatically be deleted.  Introduce owning_intrusive_list to fill this
	gap.

	Interface
	---------

	The interface of owning_intrusive_list is mostly equivalent to
	intrusive_list, with the following differences:

	 - When destroyed, owning_intrusive_list deletes all element objects.
	   The clear method does so as well.

	 - The erase method destroys the removed object.

	 - The push_front, push_back and insert methods accept a `unique_ptr<T>`
	   (compared to `T &` for intrusive_list), taking ownership of the
	   object.

	 - owning_intrusive_list has emplace_front, emplace_back and emplace
	   methods, allowing to allocate and construct an object directly in the
	   list.  This is really just a shorthand over std::make_unique and
	   insert (or push_back / push_front if you don't care about the return
	   value), but I think it is nicer to read:

	     list.emplace (pos, "hello", 2);

	   rather than

	     list.insert (pos, std::make_unique<Foo> ("hello", 2));

	   These methods are not `noexcept`, since the allocation or the
	   constructor could throw.

	 - owning_intrusive_list has a release method, allowing to remove an
	   element without destroying it.  The release method returns a
	   pair-like struct with an iterator to the next element in the list
	   (like the erase method) and a unique pointer transferring the
	   ownership of the released element to the caller.

	 - owning_intrusive_list does not have a clear_and_dispose method, since
	   that is typically used to manually free items.

	Implementation
	--------------

	owning_intrusive_list privately inherits from intrusive_list, in order
	to re-use the linked list machinery.  It adds ownership semantics around
	it.

	Testing
	-------

	Because of the subtle differences in the behavior in behavior and what
	we want to test for each type of intrusive list, I didn't see how to
	share the tests for the two implementations.  I chose to copy the
	intrusive_list tests and adjust them for owning_intrusive_list.

	The verify_items function was made common though, and it tries to
	dereference the items in the list, to make sure they have not been
	deleted by mistake (which would be caught by Valgrind / ASan).

	Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760
	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-13  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport/intrusive-list: make insert return an iterator
	Make the insert method return an iterator to the inserted element.  This
	mimics what boost does [1] and what the standard library insert methods
	generally do [2].

	[1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33771-bb
	[2] https://en.cppreference.com/w/cpp/container/vector/insert

	Change-Id: I59082883492c60ee95e8bb29a18c9376283dd660
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-13  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport/intrusive-list: sprinkle noexcept
	Some methods of intrusive_list are marked noexcept.  But really,
	everything in that file could be noexcept.  Add it everywhere.

	The only one I had a doubt about is clear_and_dispose: what if the
	disposer throws?  The boost equivalent [1] is noexcept and requires the
	disposer not to throw.  The rationale is probably the same as for
	destructors.  What if the disposer throws for an element in the middle
	of the list?  Do you skip the remaining elements?  Do you swallow the
	exception and keep calling the disposer for the remaining elements?
	It's simpler to say no exceptions allowed.

	[1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33710-bb

	Change-Id: I402646cb12c6b7906f4bdc2ad85203d8c8cdf2cc
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-13  Stephan Rohr  <stephan.rohr@intel.com>

	testsuite, trace: add guards if In-Process Agent library is not found
	Several tests in gdb.trace trigger TCL errors if the In-Process Agent
	library is not found, e.g.:

	  Running gdb/testsuite/gdb.trace/change-loc.exp ...
	  ERROR: tcl error sourcing gdb/testsuite/gdb.trace/change-loc.exp.
	  ERROR: error copying "gdb/gdb/testsuite/../../gdbserver/libinproctrace.so":
		 no such file or directory
	      while executing
	  "file copy -force $fromfile $tofile"
	      (procedure "gdb_remote_download" line 29)
	      invoked from within
	  "gdb_remote_download target $target_file"
	      (procedure "gdb_download_shlib" line 6)
	      invoked from within
	  "gdb_download_shlib $file"
	      (procedure "gdb_load_shlib" line 2)
	      invoked from within
	  "gdb_load_shlib $libipa"
	      (file "gdb/testsuite/gdb.trace/change-loc.exp" line 354)
	      invoked from within
	  "source gdb/testsuite/gdb.trace/change-loc.exp"
	      ("uplevel" body line 1)
	      invoked from within
	  "uplevel #0 source gdb/testsuite/gdb.trace/change-loc.exp"
	      invoked from within
	  "catch "uplevel #0 source $test_file_name""

	Protect against this error by checking if the library is available.

2024-09-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-12  Sam James  <sam@gentoo.org>

	gprofng: avoid use of non-portable which [PR32166]
	Distributions like Debian [0] and Gentoo are phasing out the use of
	the non-portable `which` utility. Use POSIX's `command -v` instead.

	[0] https://lwn.net/Articles/874049/

	gprofng/ChangeLog
		PR gprofng/32166
		* testsuite/lib/Makefile.skel (JAVABIN): Replace use of which.

2024-09-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: change type of `general_symbol_info::m_section` to int
	The binary provided with bug 32165 [1] has 36139 ELF sections.  GDB
	crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1:

	    $ ./gdb  -nx -q --data-directory=data-directory ./vmlinux
	    Reading symbols from ./vmlinux...
	    (No debugging symbols found in ./vmlinux)
	    (gdb) info func
	    /usr/include/c++/14.2.1/debug/vector:508:
	    In function:
	        std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp,
	        _Allocator>::operator[](size_type) [with _Tp = long unsigned int;
	        _Allocator = std::allocator<long unsigned int>; reference = long
	        unsigned int&; size_type = long unsigned int]

	    Error: attempt to subscript container with out-of-bounds index -29445, but
	    container only holds 36110 elements.

	    Objects involved in the operation:
	        sequence "this" @ 0x514000007340 {
	          type = std::debug::vector<unsigned long, std::allocator<unsigned long> >;
	        }

	The crash occurs here:

	    #3  0x00007ffff5e334c3 in __GI_abort () at abort.c:79
	    #4  0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320
	    #5  0x0000555561119a16 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[] (this=0x514000007340, __n=18446744073709522171)
	        at /usr/include/c++/14.2.1/debug/vector:508
	    #6  0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517
	    #7  0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value])
	        at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983
	    #8  0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189
	    #9  0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1)
	        at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361
	    #10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525

	That is, at this line of `minimal_symbol::value_address`, where
	`objfile->section_offsets` is an `std::vector`:

	    return (CORE_ADDR (this->unrelocated_address ())
		    + objfile->section_offsets[this->section_index ()]);

	A section index of -29445 is suspicious.  The minimal_symbol at play
	here is:

	    (top-gdb) p m_name
	    $1 = 0x521001de10af "_sinittext"

	So I restarted debugging, breaking on:

	   (top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name)

	And I see that weird -29445 value:

	    (top-gdb) frame
	    #0  general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611
	    611       { m_section = idx; }

	But going up one frame, the section index is 36091:

	    (top-gdb) frame
	    #1  0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false,
	        address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228
	    1228      msymbol->set_section_index (section);

	It seems like the problem is just that the type used for the section
	index (short) is not big enough.  Change from short to int.  If somebody
	insists, we could even go long long / int64_t, but I doubt it's
	necessary.

	With that fixed, I get:

	    (gdb) info func
	    All defined functions:

	    Non-debugging symbols:
	    0xffffffff81000000  _stext
	    0xffffffff82257000  _sinittext
	    0xffffffff822b4ebb  _einittext

	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165

	Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04
	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-09-12  Jens Remus  <jremus@linux.ibm.com>

	s390: Relax risbg[n]z, risb{h|l}gz, {rns|ros|rxs}bgt operand constraints
	This leverages commit ("s390: Simplify (dis)assembly of insn operands
	with const bits") to relax the operand constraints of the immediate
	operand that contains the constant Z- or T-bit of the following extended
	mnemonics:
	risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt

	Previously those instructions were the only ones where the assembler
	on s390 restricted the specification of the subject I3/I4 operand values
	exactly according to their specification to an unsigned 6- or 5-bit
	unsigned integer. For any other instructions the assembler allows to
	specify any operand value allowed by the instruction format, regardless
	of whether the instruction specification is more restrictive.

	Allow to specify the subject I3/I4 operand as unsigned 8-bit integer
	with the constant operand bits being ORed during assembly.
	Relax the instructions subject significant operand bit masks to only
	consider the Z/T-bit as significant, so that the instructions get
	disassembled as their *z or *t flavor regardless of whether any reserved
	bits are set in addition to the Z/T-bit.
	Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set
	the T-bit in operand I3, as they otherwise get disassembled as their
	rnsbgt, rosbgt, and rxsbgt counterpart.

	This aligns GNU Assembler to LLVM Assembler.

	opcodes/
		* s390-opc.c (U6_18, U5_27, U6_26): Remove.
		(INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define
		as INSTR_RIE_RRUUU while retaining insn fmt mask.
		(MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only
		Z/T-bit of I3/I4 operand as significant.

	gas/testsuite/
		* gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit.

	Reported-by: Dominik Steenken <dost@de.ibm.com>
	Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

2024-09-12  Jens Remus  <jremus@linux.ibm.com>

	s390: Simplify (dis)assembly of insn operands with const bits
	Simplify assembly and disassembly of extended mnemonics with operands
	with constant ORed bits:
	Their instruction template already contains the respective constant
	operand bits, as they are significant to distinguish the extended from
	their base mnemonic. Operands are ORed into the instruction template.
	Therefore it is not necessary to OR the constant bits into the operand
	value during assembly in s390_insert_operand.
	Additionally the constant operand bits from the instruction template
	can be used to mask them from the operand value during disassembly in
	s390_print_insn_with_opcode. For now do so for non-length unsigned
	integer operands only.

	The separate instruction formats need to be retained, as their masks
	differ, which is relevant during disassembly to distinguish the base
	and extended mnemonics from each other.

	This affects the following extended mnemonics:
	- vfaebs, vfaehs, vfaefs
	- vfaezb, vfaezh, vfaezf
	- vfaezbs, vfaezhs, vfaezfs
	- vstrcbs, vstrchs, vstrcfs
	- vstrczb, vstrczh, vstrczf
	- vstrczbs, vstrczhs, vstrczfs
	- wcefb, wcdgb
	- wcelfb, wcdlgb
	- wcfeb, wcgdb
	- wclfeb, wclgdb
	- wfisb, wfidb, wfixb
	- wledb, wflrd, wflrx

	include/
		* opcode/s390.h (S390_OPERAND_OR1, S390_OPERAND_OR2,
		S390_OPERAND_OR8): Remove.

	opcodes/
		* s390-opc.c (U4_OR1_24, U4_OR2_24, U4_OR8_28): Remove.
		(INSTR_VRR_VVV0U1, INSTR_VRR_VVV0U2, INSTR_VRR_VVV0U3): Define
		as INSTR_VRR_VVV0U0 while retaining respective insn fmt mask.
		(INSTR_VRR_VV0UU8): Define as INSTR_VRR_VV0UU while retaining
		respective insn fmt mask.
		(INSTR_VRR_VVVU0VB1, INSTR_VRR_VVVU0VB2, INSTR_VRR_VVVU0VB3):
		Define as INSTR_VRR_VVVU0VB while retaining respective insn fmt
		mask.
		* s390-dis.c (s390_print_insn_with_opcode): Mask constant
		operand bits set in insn template of non-length unsigned
		integer operands.

	gas/
		* config/tc-s390.c (s390_insert_operand): Do not OR constant
		operand value bits.

2024-09-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-11  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32096 UBSAN issues in gprofng
	Fixed UBSAN runtime errors such as:
	 - load of value 4294967295, which is not a valid value for type 'Cmsg_warn'
	 - null pointer passed as argument 2, which is declared to never be null
	 - load of value 4294967295, which is not a valid value for type 'ProfData_type'
	 - reference binding to misaligned address 0x00000357583c for type 'long unsigned int', which requires 8 byte alignment

	gprofng/ChangeLog
	2024-09-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		PR gprofng/32096
		* src/BaseMetric.cc: Fix UBSAN runtime errors.
		* src/BaseMetric.h: Likewise.
		* src/Emsg.h: Likewise.
		* src/Experiment.cc: Likewise.
		* src/Table.h: Likewise.

2024-09-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.dwarf2/forward-spec.exp
	Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple
	to parse this cooked_index_entry:
	...
	    [5] ((cooked_index_entry *) 0x7f01f0004040)^M
	    name:       v^M
	    canonical:  v^M
	    qualified:  ns::v^M
	    DWARF tag:  DW_TAG_variable^M
	    flags:      0x2 [IS_STATIC]^M
	    DIE offset: 0xcb^M
	    parent:     ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M
	...
	which allows us to verify that the entry has a parent.

	After commit 8f258a6c979 ("[gdb/symtab] Dump qualified name of
	cooked_index_entry") that's no longer necessary.

	Simplify this by checking for ns::v instead.

	While we're at it, also fix the test-case for target boards readnow,
	cc-with-gdb-index and cc-with-debug-names.

	Tested on x86_64-linux.

2024-09-11  Christophe Lyon  <christophe.lyon@linaro.org>

	arm: Handle undefweak with ST_BRANCH_UNKNOWN
	A previous patch made ld fail early on Thumb-only where branch_type is
	ST_BRANCH_UNKNOWN.

	However, this fails erroneously when the target is undefweak: in that
	case the branch should be replaced by a branch to the next instruction
	(or nop.w on thumb2).  This patch accepts this case and restores the
	previous behaviour in such cases.

	This was reported by failures in the GCC testsuite, where we fail to
	link executables because __deregister_frame_info is undefweak:

	(__deregister_frame_info): Unknown destination type (ARM/Thumb) in ...crtbegin.o
	crtbegin.o: in function `__do_global_dtors_aux':
	crtstuff.c:(.text+0x52): dangerous relocation: unsupported relocation

2024-09-11  Kyle Huey  <me@kylehuey.com>

	gdb: Support DW_OP_constx (the standardized version of DW_OP_GNU_const_index).
	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-11  Tom Tromey  <tromey@adacore.com>

	Fix typo in Python TUI window text
	I noticed a typo in the Python TUI window documentation.

2024-09-11  Jan Beulich  <jbeulich@suse.com>

	gas: avoid (scrubber) diagnostics for stuff past .end
	What's past an active .end directive (when that has its default purpose)
	is supposed to be entirely ignored. That should be true not just for
	regular processing, but also for "pre-processing" (aka scrubbing). A
	complication is that such a directive may of course occur inside a
	(false) conditional or a macro definition. To deal with that make sure
	we can continue as usual if called another time.

	Note however that .end inside a macro will still have the full macro
	body expanded; dealing with that would require further (perhaps
	intrusive) adjustments in sb_scrub_and_add_sb() and/or callers thereof.
	However, at least some of the warnings issued by do_scrub_chars() are
	unlikely to occur when expanding a macro. (If we needed to go that far,
	presumably .exitm would also want recognizing.)

2024-09-11  Jan Beulich  <jbeulich@suse.com>

	gas: restrict scrubber mri_{state,last_ch} vars
	They're needed with TC_M68K only. Group them accordingly, just like is
	the case for Arm's symver vars.

	arm: don't engage symver scrubber hack in CCS mode
	In that mode the comment char is ; while @ has no special meaning.
	Engaging the special logic in that case results in comments not being
	respected on .symver lines.

	x86/APX: correct disassembly for EVEX.B4
	EVEX.B4 is used only for GPR (or addressing of memory) operands. SIMD
	registers encoded via ModR/M.rm (when ModR/M.mod == 3) have their top
	bit in EVEX.X3. Supposedly (doc version 004) EVEX.B4 is ignored when
	unused, hence also don't flag such encodings as invalid.

2024-09-11  Jan Beulich  <jbeulich@suse.com>

	x86: error handling in set_cpu_arch()
	Error messages there would better not be followed by further "junk at
	end of line" diagnostics. Arrange for this to be the case uniformly.

	While there also replace a somewhat unhelpful open-coding of
	restore_line_pointer().

2024-09-11  Mark Harmstone  <mark@harmstone.com>

	ld/testsuite: exclude relocs from section contributions PDB test
	A bug in ld meant that we were erroneously generating image relocations
	for .secrel32 ops, which we then reflected in our PDB section
	contributions because the linker was adding a .reloc section.

	This was incidental to what we were testing for, so pass
	--disable-reloc-section to ld in order to ensure a consistent output.

2024-09-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix argument order in example code within a comment
	Small typo in some example code inside a comment; the arguments were
	in the wrong order.

	There's no functional change after this commit.

2024-09-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add return after a call to 'untested'
	In gdb.base/corefile-buildid.exp, in the function
	do_corefile_buildid_tests, if we fail to find the build-id for the
	test binary then we call 'untested', but then push on with the test,
	which inevitably fails as the rest of the test depends on having found
	the build-id.

	I think we're missing a 'return' after the call to 'untested' which
	I've now added.

	Also I noticed that we call build_id_debug_filename_get and then
	manually remove '.debug' from the end.  This is no longer necessary,
	we can just ask build_id_debug_filename_get to not add the suffix.

2024-09-10  Andrew Burgess  <aburgess@redhat.com>

	Revert "[gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp"
	This reverts commit 29c70787112e01cd52b53bf14bdcacb0a11e0725.

	After the previous commit 29c70787112e01cd52 should no longer be
	needed as the curses dependency has been removed.

2024-09-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: avoid depending on the curses library
	The commit:

	  commit 29c70787112e01cd52b53bf14bdcacb0a11e0725
	  Date:   Sun Sep 8 07:46:09 2024 +0200

	      [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp

	Highlighted that in some cases we might be running on a system with an
	older version of Python (earlier than 3.7), and on a system for which
	the curses library has not been installed.

	In these circumstances the gdb.missing_debug module will not load as
	it uses curses to provide isalnum() and isascii() functions.

	To avoid this problem I propose that we copy the isalnum() and
	isascii() from the Python curses library.  These functions are
	basically trivial and removing the curses dependency means GDB will
	work in more cases without increasing its dependencies.

	I did consider keeping the uses of curses and only having the function
	definitions be a fallback for when the curses library failed to load,
	but this felt like overkill.  The function definitions are both tiny
	and I think "obvious" given their specifications, so I figure we might
	as well just use our own definitions if they are not available as
	builtin methods on the str class.

	For testing I changed this line:

	  if sys.version_info >= (3, 7):

	to

	  if sys.version_info >= (3, 7) and False:

	then reran gdb.python/py-missing-debug.exp, there were no failures.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.xml/tdesc-regs.exp on riscv64
	When running test-case gdb.xml/tdesc-regs.exp on riscv64-linux, I get:
	...
	(gdb) set tdesc file single-reg.xml^M
	warning: Architecture rejected target-supplied description^M
	(gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml
	UNSUPPORTED: gdb.xml/tdesc-regs.exp: register tests
	...

	The FAIL and UNSUPPORTED are produced here:
	...
	 # If no core registers were specified, assume this target does not
	 # support target-defined registers.  Verify that we get a warning if
	 # we try to use them.  This not only tests the warning, but also
	 # reminds maintainers to add test support when they add the feature.

	if {[string equal ${core-regs} ""]} {
	    gdb_test "set tdesc file $single_reg_xml" \
		"warning: Target-supplied registers are not supported.*" \
		"set tdesc file single-reg.xml"
	    unsupported "register tests"
	    return 0
	}
	...

	The test-case contains target-specific setting of the core-regs variable, and
	adding this for riscv64 bypasses this code and makes the test-case pass.

	However, without that change, the test-case shouldn't produce a FAIL since
	gdb isn't doing anything wrong.

	Fix this by producing instead:
	...
	PASS: $exp: set tdesc file single-reg.xml
	UNSUPPORTED: $exp: register tests (missing architecture-specific core-regs setting)
	...

	Tested on riscv64-linux.

2024-09-10  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix unused var in corelow.c
	On x86_64-linux, with gcc 7.5.0 and CFLAGS/CXXFLAGS="-O0 -g -Wall" I ran into
	a build breaker:
	...
	gdb/corelow.c: In member function ‘void mapped_file_info::add(const char*, const char*, const char*, std::vector<mem_range>&&, const bfd_build_id*)’:
	gdb/corelow.c:1822:27: error: unused variable ‘it’ [-Werror=unused-variable]
	   const auto [it, inserted]
	                           ^
	...

	Fix this by dropping the variable it.

	Tested on x86_64-linux.

	Reviewed-By: Lancelot Six<lancelot.six@amd.com>

2024-09-10  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Pass true to ld_plugin_object_p
	Since linker calls bfd_plugin_object_p, which calls ld_plugin_object_p,
	only for command-line input objects, pass true to ld_plugin_object_p so
	that the same input IR file won't be included twice if the new LTO hook,
	LDPT_REGISTER_CLAIM_FILE_HOOK_V2 isn't used.

		PR ld/32153
		* plugin.c (bfd_plugin_object_p): Pass true to ld_plugin_object_p.

2024-09-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Move enum size check into ada_identical_enum_types_p
	Currently, the callers of ada_identical_enum_types_p must check that
	both enum types have the same number of members.  In another series
	I'm working on, it was convenient to move this check into the callee
	instead; and I broke this patch out to make that series a little
	simpler.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Minor cleanup to ada_identical_enum_types_p
	This moves the declaration of 'i' into the 'for' loops in
	ada_identical_enum_types_p.  This is just a trivial cleanup.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Boolify ada_identical_enum_types_p
	This changes ada_identical_enum_types_p to return bool rather than
	int.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Fix some comments in dwarf2/cooked-index.h
	This fixes a couple of comments in dwarf2/cooked-index.h.

	The comment by cooked_index_entry::canonical mentions C++, but this
	field can also be different from 'name' in other situations.  Rather
	than enumerate the cases here (which doesn't seem important), make the
	text a little less specific.

	Also, cooked_index_entry::write_scope doesn't document its "for_main"
	parameter -- and it is misnamed in the prototype as well.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Refactor cooked_index_shard::handle_gnat_encoded_entry
	This changes cooked_index_shard::handle_gnat_encoded_entry to modify
	the incoming entry itself, and to return void rather than a new name.
	this simplifies the caller a little, which is convenient for a
	different series I am working on.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Tom Tromey  <tromey@adacore.com>

	Ignore DW_TAG_padding in tag_is_type
	DW_TAG_padding isn't a real tag -- it doesn't appear in the DWARF
	standard, only in include/dwarf2.def as a placeholder.  So, remove it
	from dwarf2/tag.h:tag_is_type.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-09-09  Jens Remus  <jremus@linux.ibm.com>

	s390: Align opcodes to lower-case
	opcodes/
		* s390-opc.txt (rdp): Change opcode to lower-case.

2024-09-09  Jens Remus  <jremus@linux.ibm.com>

	s390: Document syntax to omit base register operand
	Document the s390-specific assembler syntax introduced by commit
	aacf780bca29 ("s390: Allow to explicitly omit base register operand in
	assembly") to omit the base register operand B in D(X,B) and D(L,B) by
	coding D(X,) and D(L,).

	While at it document the alternative syntax to omit the index register
	operand X in D(X,B) by coding D(,B) instead of D(B).

	gas/
		* doc/c-s390.texi (s390 Operands): Document syntax to omit base
		register operand.

	Fixes: aacf780bca29 ("s390: Allow to explicitly omit base register operand in assembly")

2024-09-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/NEWS: group general news items together
	I noticed that the list of general NEWS items seemed to have gotten
	mixed up a bit in the NEWS file.  This commit just moves things around
	so that the general items all appear at the start of the 'Changes
	since GDB 15' section.  I've not changed any of the actual content.

2024-09-09  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fixed precedence of expression operators in instructions
	The precedence of the operators "+" and "-" in the current loongarch
	instruction expression is higher than "<<" and ">>", which is different
	from the explanation in the user guide.

	We modified the precedence of "<<" and ">>" to be higher than "+" and "-".

2024-09-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix use of out of scope temporary variable in break-cond-parse.c
	The commit:

	  commit c6b486755e020095710c7494d029577ca967a13a
	  Date:   Thu Mar 30 19:21:22 2023 +0100

	      gdb: parse pending breakpoint thread/task immediately

	Introduce a use bug where the value of a temporary variable was being
	used after it had gone out of scope.  This was picked up by the
	address sanitizer and would result in this error:

	  (gdb) maintenance selftest create_breakpoint_parse_arg_string
	  Running selftest create_breakpoint_parse_arg_string.
	  =================================================================
	  ==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768
	  READ of size 1 at 0x7fbb08046511 thread T0
	      #0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, bool*) ../../src/gdb/break-cond-parse.c:496
	      #1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582
	      #2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649
	      #3 0x12cfebc in void std::__invoke_impl<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
	      #4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
	      #5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
	      #6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
	      #7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, bool) ../../src/gdbsupport/selftest.cc:100
	      #8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172
	      ... etc ...

	The problem was caused by three lines like this one:

	  thread_info *thr
	    = parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok);

	After parsing the thread-id TMPTOK would be left pointing into the
	temporary string which had been created on this line.  When on the
	next line we did this:

	  gdb_assert (*tmptok == '\0');

	The value of *TMPTOK is undefined.

	Fix this by creating the std::string earlier in the scope.  Now the
	contents of the string will remain valid when we check *TMPTOK.  The
	address sanitizer issue is now resolved.

2024-09-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp
	On a system with python 3.6, module gdb.missing_debug imports module curses,
	so when running test-case gdb.python/py-missing-debug.exp on a system without
	that module installed, we run into:
	...
	(gdb) source py-missing-debug.py^M
	Python Exception <class 'ImportError'>: Module 'curses' is not installed.^M
	Use:^M
	  sudo zypper install python36-curses^M
	to install it.^M
	Error occurred in Python: Module 'curses' is not installed.^M
	Use:^M
	  sudo zypper install python36-curses^M
	to install it.^M
	(gdb) FAIL: gdb.python/py-missing-debug.exp: source python script
	...

	Fix this by issuing UNSUPPORTED instead, and bailing out.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	PR testsuite/31576
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31576

2024-09-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: only insert thread-specific breakpoints in the relevant inferior
	This commit updates GDB so that thread or inferior specific
	breakpoints are only inserted into the program space in which the
	specific thread or inferior is running.

	In terms of implementation, getting this basically working is easy
	enough, now that a breakpoint's thread or inferior field is setup
	prior to GDB looking for locations, we can easily use this information
	to find a suitable program_space and pass this to as a filter when
	creating the sals.

	Or we could if breakpoint_ops::create_sals_from_location_spec allowed
	us to pass in a filter program_space.

	So, this commit extends breakpoint_ops::create_sals_from_location_spec
	to take a program_space argument, and uses this to filter the set of
	returned sals.  This accounts for about half the change in this patch.

	The second set of changes starts from breakpoint_set_thread and
	breakpoint_set_inferior, this is called when the thread or inferior
	for a breakpoint changes, e.g. from the Python API.

	Previously this call would never result in the locations of a
	breakpoint changing, after all, locations were inserted in every
	program space, and we just use the thread or inferior variable to
	decide when we should stop.  Now though, changing a breakpoint's
	thread or inferior can mean we need to figure out a new set of
	breakpoint locations.

	To support this I've added a new breakpoint_re_set_one function, which
	is like breakpoint_re_set, but takes a single breakpoint, and just
	updates the locations for that one breakpoint.  We only need to call
	this function if the program_space in which a breakpoint's thread (or
	inferior) is running actually changes.  If the program_space does
	change then we call the new breakpoint_re_set_one function passing in
	the program_space which should be used to filter the new locations (or
	nullptr to indicate we should set locations in all program spaces).
	This filter program_space needs to propagate down to all the re_set
	methods, this accounts for the remaining half of the changes in this
	patch.

	There were a couple of existing tests that created thread or inferior
	specific breakpoints and then checked the 'info breakpoints' output,
	these needed updating.  These were:

	  gdb.mi/user-selected-context-sync.exp
	  gdb.multi/bp-thread-specific.exp
	  gdb.multi/multi-target-continue.exp
	  gdb.multi/multi-target-ping-pong-next.exp
	  gdb.multi/tids.exp
	  gdb.mi/new-ui-bp-deleted.exp
	  gdb.multi/inferior-specific-bp.exp
	  gdb.multi/pending-bp-del-inferior.exp

	I've also added some additional tests to:

	  gdb.multi/pending-bp.exp

	I've updated the documentation and added a NEWS entry.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't set breakpoint::pspace in create_breakpoint
	I spotted this code within create_breakpoint:

	  if ((type_wanted != bp_breakpoint
	      && type_wanted != bp_hardware_breakpoint) || thread != -1)
	   b->pspace = current_program_space;

	this code is only executed when creating a pending breakpoint, and
	sets the breakpoint::pspace member variable.

	The above code gained the 'thread != -1' clause with this commit:

	  commit cc72b2a2da6d6372cbdb1d14639a5fce84e1a325
	  Date:   Fri Dec 23 17:06:16 2011 +0000

	              Introduce gdb.FinishBreakpoint in Python

	While the type_wanted checks were added with this commit:

	  commit f8eba3c61629b3c03ac1f33853eab4d8507adb9c
	  Date:   Tue Dec 6 18:54:43 2011 +0000

	      the "ambiguous linespec" series

	Before this breakpoint::pspace was set unconditionally.

	If we look at how breakpoint::pspace is used today, some breakpoint
	types specifically set this field, either in their constructors, or in
	a wrapper function that calls the constructor.  So, the watchpoint
	type and its sub-class set this variable, as does the catchpoint type,
	and all it's sub-classes.

	However, code_breakpoint doesn't specifically set this field within
	its constructor, though some sub-classes of
	code_breakpoint (ada_catchpoint, exception_catchpoint,
	internal_breakpoint, and momentary_breakpoint) do set this field.

	When I examine all the places that breakpoint::pspace is used, I
	believe that in every place where it is expected that this field is
	set, the breakpoint type will be one that specifically sets this
	field.

	Next, I observe two problems with the existing code.

	First, the above code is only hit for pending breakpoints, there's no
	equivalent code for non-pending breakpoints.  This opens up the
	possibility of GDB entering non-consistent states; if a breakpoint is
	first created pending and then later gets a location, the pspace field
	will be set, while if the breakpoint is immediately non-pending, then
	the pspace field will never be set.

	Second, if we look at how breakpoint::pspace is used in the function
	breakpoint_program_space_exit, we see that when a program space is
	removed, any breakpoint with breakpoint::pspace set to the removed
	program space, will be deleted.  This makes sense, but does mean we
	need to ensure breakpoint::pspace is only set for breakpoints that
	apply to a single program space.

	So, if I create a pending dprintf breakpoint (type bp_dprintf) then
	the breakpoint::pspace variable will be set even though the dprintf is
	not really tied to that one program space.  As a result, when the
	matching program space is removed the dprintf is incorrectly removed.

	Also, if I create a thread specific breakpoint, then, thanks to the
	'thread != -1' clause the wrong program space will be stored in
	breakpoint::pspace (the current program space is always used, which
	might not be the program space that corresponds to the selected
	thread), as a result, the thread specific breakpoint will be deleted
	when the matching program space is removed.

	If we look at commit cc72b2a2da6d which added the 'thread != -1'
	clause, we can see this change was entirely redundant, the
	breakpoint::pspace is also set in bpfinishpy_init after
	create_breakpoint has been called.  As such, I think we can safely
	drop the 'thread != -1' clause.

	For the other problems, I'm proposing to be pretty aggressive - I'd
	like to drop the breakpoint::pspace assignment completely from
	create_breakpoint.  Having looked at how this variable is used, I
	believe that it is already set elsewhere in all the cases that it is
	needed.  Maybe this code was needed at one time, but I can't see how
	it's needed any more.

	There's tests to expose the issues I've spotted with this code, and
	there's no regressions in testing.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: parse pending breakpoint thread/task immediately
	The initial motivation for this commit was to allow thread or inferior
	specific breakpoints to only be inserted within the appropriate
	inferior's program-space.  The benefit of this is that inferiors for
	which the breakpoint does not apply will no longer need to stop, and
	then resume, for such breakpoints.  This commit does not make this
	change, but is a refactor to allow this to happen in a later commit.

	The problem we currently have is that when a thread-specific (or
	inferior-specific) breakpoint is created, the thread (or inferior)
	number is only parsed by calling find_condition_and_thread_for_sals.
	This function is only called for non-pending breakpoints, and requires
	that we know the locations at which the breakpoint will be placed (for
	expression checking in case the breakpoint is also conditional).

	A consequence of this is that by the time we figure out the breakpoint
	is thread-specific we have already looked up locations in all program
	spaces.  This feels wasteful -- if we knew the thread-id earlier then
	we could reduce the work GDB does by only looking up locations within
	the program space for which the breakpoint applies.

	Another consequence of how find_condition_and_thread_for_sals is
	called is that pending breakpoints don't currently know they are
	thread-specific, nor even that they are conditional!  Additionally, by
	delaying parsing the thread-id, pending breakpoints can be created for
	non-existent threads, this is different to how non-pending
	breakpoints are handled, so I can do this:

	  $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
	  Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
	  (gdb) break foo thread 99
	  Function "foo" not defined.
	  Make breakpoint pending on future shared library load? (y or [n]) y
	  Breakpoint 1 (foo thread 99) pending.
	  (gdb) r
	  Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
	  [Thread debugging using libthread_db enabled]
	  Using host libthread_db library "/lib64/libthread_db.so.1".
	  Error in re-setting breakpoint 1: Unknown thread 99.
	  [Inferior 1 (process 3329749) exited normally]
	  (gdb)

	GDB only checked the validity of 'thread 99' at the point the 'foo'
	location became non-pending.  In contrast, if I try this:

	  $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
	  Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
	  (gdb) break main thread 99
	  Unknown thread 99.
	  (gdb)

	GDB immediately checks if 'thread 99' exists.  I think inconsistencies
	like this are confusing, and should be fixed if possible.

	In this commit the create_breakpoint function is updated so that the
	extra_string, which contains the thread, inferior, task, and/or
	condition information, is parsed immediately, even for pending
	breakpoints.

	Obviously, the condition still can't be validated until the breakpoint
	becomes non-pending, but the thread, inferior, and task information
	can be pulled from the extra-string, and can be validated early on,
	even for pending breakpoints.  The -force-condition flag is also
	parsed as part of this early parsing change.

	There are a couple of benefits to doing this:

	1. Printing of breakpoints is more consistent now.  Consider creating
	   a conditional breakpoint before this commit:

	    (gdb) set breakpoint pending on
	    (gdb) break pendingfunc if (0)
	    Function "pendingfunc" not defined.
	    Breakpoint 1 (pendingfunc if (0)) pending.
	    (gdb) break main if (0)
	    Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
	    (gdb) info breakpoints
	    Num     Type           Disp Enb Address            What
	    1       breakpoint     keep y   <PENDING>          pendingfunc if (0)
	    2       breakpoint     keep y   0x0000000000401198 in main at /tmp/hello.c:18
	            stop only if (0)
	    (gdb)

	   And after this commit:

	    (gdb) set breakpoint pending on
	    (gdb) break pendingfunc if (0)
	    Function "pendingfunc" not defined.
	    Breakpoint 1 (pendingfunc) pending.
	    (gdb) break main if (0)
	    Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
	    (gdb) info breakpoints
	    Num     Type           Disp Enb Address            What
	    1       breakpoint     keep y   <PENDING>          pendingfunc
	            stop only if (0)
	    2       breakpoint     keep y   0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
	            stop only if (0)
	    (gdb)

	   Notice that the display of the condition is now the same for the
	   pending and non-pending breakpoints.

	   The same is true for the thread, inferior, or task information in
	   thread, inferior, or task specific breakpoints; this information is
	   displayed on its own line rather than being part of the 'What'
	   field.

	2. We can check that the thread exists as soon as the pending
	   breakpoint is created.  Currently there is a weird difference
	   between pending and non-pending breakpoints when creating a
	   thread-specific breakpoint.

	   A pending thread-specific breakpoint only checks its thread when it
	   becomes non-pending, at which point the thread the breakpoint was
	   intended for might have exited.  Here's the behaviour before this
	   commit:

	    (gdb) set breakpoint pending on
	    (gdb) break foo thread 2
	    Function "foo" not defined.
	    Breakpoint 2 (foo thread 2) pending.
	    (gdb) c
	    Continuing.
	    [Thread 0x7ffff7c56700 (LWP 2948835) exited]
	    Error in re-setting breakpoint 2: Unknown thread 2.
	    [Inferior 1 (process 2948832) exited normally]
	    (gdb)

	   Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
	   line, this was triggered when GDB tried to make the breakpoint
	   non-pending, and GDB discovers that the thread no longer exists.

	   Compare that to the behaviour after this commit:

	    (gdb) set breakpoint pending on
	    (gdb) break foo thread 2
	    Function "foo" not defined.
	    Breakpoint 2 (foo) pending.
	    (gdb) c
	    Continuing.
	    [Thread 0x7ffff7c56700 (LWP 2949243) exited]
	    Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
	    [Inferior 1 (process 2949240) exited normally]
	    (gdb)

	   Now the behaviour for pending breakpoints is identical to
	   non-pending breakpoints, the thread specific breakpoint is removed
	   as soon as the thread the breakpoint is associated with exits.

	   There is an additional change; when the pending breakpoint is
	   created prior to this patch we see this line:

	     Breakpoint 2 (foo thread 2) pending.

	   While after this patch we get this line:

	     Breakpoint 2 (foo) pending.

	   Notice that 'thread 2' has disappeared.  This might look like a
	   regression, but I don't think it is.  That we said 'thread 2'
	   before was just a consequence of the lazy parsing of the breakpoint
	   specification, while with this patch GDB understands, and has
	   parsed away the 'thread 2' bit of the spec.  If folk think the old
	   information was useful then this would be trivial to add back in
	   code_breakpoint::say_where.

	As a result of this commit the breakpoints 'extra_string' field is now
	only used by bp_dprintf type breakpoints to hold the printf format and
	arguments.  This string should always be empty for other breakpoint
	types.  This allows some cleanup in print_breakpoint_location.

	In code_breakpoint::code_breakpoint I've changed an error case into an
	assert.  This is because the error is now handled earlier in
	create_breakpoint.  As a result we know that by this point, the
	extra_string will always be nullptr for anything other than a
	bp_dprintf style breakpoint.

	The find_condition_and_thread_for_sals function is now no longer
	needed, this was previously doing the delayed splitting of the extra
	string into thread, task, and condition, but this is now all done in
	create_breakpoint, so find_condition_and_thread_for_sals can be
	deleted, and the code that calls this in
	code_breakpoint::location_spec_to_sals can be removed.  With this
	update this code would only ever be reached for bp_dprintf style
	breakpoints, and in these cases the extra_string should not contain
	anything other than format and args.

	The most interesting changes are all in create_breakpoint and in the
	new file break-cond-parse.c.  We have a new block of code early on in
	create_breakpoint that is responsible for splitting the extra_string
	into its component parts by calling create_breakpoint_parse_arg_string
	a function in the new break-cond-parse.c file.  This means that some
	of the later code can be simplified a little.

	The new break-cond-parse.c file implements the splitting up the
	extra_string and finding all the parts, as well as some self-tests for
	the new function.

	Finally, now we know all the breakpoint details, these can be stored
	within the breakpoint object if we end up creating a deferred
	breakpoint.  Additionally, if we are creating a deferred bp_dprintf we
	can parse the extra_string to build the printf command.

	The implementation here aims to maintain backwards compatibility as
	much as possible, this means that:

	  1. We support abbreviations of 'thread', 'task', and 'inferior' in
	  some places on the breakpoint line.  The handling of abbreviations
	  has (before this patch) been a little weird, so this works:

	  (gdb) break *main th 1

	  And creates a breakpoint at '*main' for thread 1 only, while this
	  does not work:

	  (gdb) break main th 1

	  In this case GDB will try to find the symbol 'main th 1'.  This
	  weirdness exists before and after this patch.

	  2. The handling of '-force-condition' is odd, if this flag appears
	  immediately after a condition then it will be treated as part of the
	  condition, e.g.:

	  (gdb) break main if 0 -force-condition
	  No symbol "force" in current context.

	  But we are fine with these alternatives:

	  (gdb) break main if 0 thread 1 -force-condition
	  (gdb) break main -force-condition if 0

	  Again, this is just a quirk of how the breakpoint line used to be
	  parsed, but I've maintained this for backward compatibility.  During
	  review it was suggested that -force-condition should become an
	  actual breakpoint flag (i.e. only valid after the 'break' command
	  but before the function name), and I don't think that would be a
	  terrible idea, however, that's not currently a trivial change, and I
	  think should be done as a separate piece of work.  For now, this
	  patch just maintains the current behaviour.

	The implementation works by first splitting the breakpoint condition
	string (everything after the location specification) into a list of
	tokens, each token has a type and a value. (e.g. we have a THREAD
	token where the value is the thread-id string).  The list of tokens is
	validated, and in some cases, tokens are merged.  Then the values are
	extracted from the remaining token list.

	Consider this breakpoint command:

	  (gdb) break main thread 1 if argc == 2

	The condition string passed to create_breakpoint_parse_arg_string is
	going to be 'thread 1 if argc == 2', which is then split into the
	tokens:

	  { THREAD: "1" } { CONDITION: "argc == 2" }

	The thread-id (1) and the condition string 'argc == 2' are extracted
	from these tokens and returns back to create_breakpoint.

	Now consider this breakpoint command:

	  (gdb) break some_function if ( some_var == thread )

	Here the user wants a breakpoint if 'some_var' is equal to the
	variable 'thread'.  However, when this is initially parsed we will
	find these tokens:

	  { CONDITION: "( some_var == " } { THREAD: ")" }

	This is a consequence of how we have to try and figure out the
	contents of the 'if' condition without actually parsing the
	expression; parsing the expression requires that we know the location
	in order to lookup the variables by name, and this can't be done for
	pending breakpoints (their location isn't known yet), and one of the
	points of this work is that we extract things like thread-id for
	pending breakpoints.

	And so, it is in this case that token merging takes place.  We check
	if the value of a token appearing immediately after the CONDITION
	token looks valid.  In this case, does ')' look like a valid
	thread-id.  Clearly, in this case ')' does not, and so me merge the
	THREAD token into the condition token, giving:

	  { CONDITION: "( some_var == thread )" }

	Which is what we want.

	I'm sure that we might still be able to come up with some edge cases
	where the parser makes the wrong choice.  I think long term the best
	way to work around these would be to move the thread, inferior, task,
	and -force-condition flags to be "real" command options for the break
	command.  I am looking into doing this, but can't guarantee if/when
	that work would be completed, so this patch should be reviewed assume
	that the work will never arrive (though I hope it will).

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: create new is_thread_id helper function
	This is a refactoring commit that splits the existing parse_thread_id
	function into two parts, and then adds a new is_thread_id function.

	The core of parse_thread_id is split into parse_thread_id_1, which is
	responsible for actually parsing a thread-id.  Then parse_thread_id is
	responsible for taking a parsed thread-id and validating that it
	references an actually existing inferior thread.

	The new is_thread_id function also uses parse_thread_id_1, but doesn't
	actually check that the inferior thread exists, instead, this new
	function simply checks that a string looks like a thread-id.

	This commit does not add a use for is_thread_id, this will be added in
	the next commit.

	This is a refactoring commit, there should be no user visible changes
	after this commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: add another overload of startswith
	We already have one overload of the startswith function that takes a
	std::string_view for both arguments.  A later patch in this series is
	going to be improved by having an overload that takes one argument as
	a std::string_view and the other argument as a plain 'char *'.

	This commit adds the new overload, but doesn't make use of it (yet).
	There should be no user visible changes after this commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: make breakpoint_debug_printf global
	This commit makes breakpoint_debug_printf available outside of
	breakpoint.c.  In a later commit I'll want to use this macro from
	another file.

	This is just a refactor, there should be no user visible changes after
	this commit.

2024-09-07  Tom Tromey  <tom@tromey.com>

	Remove tui_refresh_cmd_win
	tui_refresh_cmd_win is no longer needed and can be replaced with a
	call to the refresh_window method.

	Remove tui_wrefresh
	This removes tui_wrefresh, moving the code into refresh_window.  We
	remove tui_norefresh_window as well, because now the command window's
	refresh_window has to do what tui_wrefresh previously did.

2024-09-07  Tom Tromey  <tom@tromey.com>

	Rename tui_suppress_output
	This patch renames tui_suppress_output to the more descriptive
	tui_batch_rendering.  This code was never really correct, and was
	based on a misunderstanding of the curses API.  The updated comments
	describe the intended use of this class.

	This also removes the erroneous tui_win_info::no_refresh.
	wnoutrefresh does not prevent any output; rather, it copies from one
	curses buffer to another but (unlike woutrefresh) without then
	flushing to the screen.

	tui_batch_rendering now works in the correct way: calling doupdate in
	the destructor of the outermost instance, thus batching all screen
	output until that point.

	The patch adds instantiations of tui_batch_rendering to various spots,
	to make sure it is active when refreshing.

2024-09-07  Tom Tromey  <tom@tromey.com>

	Clean up refreshing in TUI register window
	This patch rearranges the TUI register window code a bit, removing a
	call to tui_wrefresh and hoisting the calls to refresh_window to "more
	outer" spots.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: 'target ...' commands now expect quoted/escaped filenames
	This commit changes the 'target ...' commands that accept a filename
	to take a quoted or escaped filename rather than a literal filename.

	What this means in practice is that if you are specifying a filename
	that contains no white space or quote characters, then nothing should
	change, e.g.:

	  target exec /path/to/some/file

	works both before and after this commit.

	However, if a user wishes to specify a file containing white space
	then either the entire filename needs to be quoted, or the special
	white space needs to be escaped.  Before this patch a user could
	write:

	  target exec /path/to a file/containing spaces

	But after this commit the user would have to choose one of:

	  target exec "/path/to a file/containing spaces"

	or

	  target exec /path/to\ a\ file/containing\ spaces

	Obviously this is a potentially breaking change.  The benefit of
	making this change is consistency.  Commands that take multiple
	arguments (one of which is a filename) or in the future, commands that
	take filename options, will always need to use quoted/escaped
	filenames, so converting all unquoted filename commands to use quoting
	or escaping makes the UI more consistent.

	Additionally (though this is probably not a common problem), GDB
	strips trailing white space from commands that the user enters.  As
	such it is not possible to reference any file that ends in white space
	unless the quoting / escaping style is used.  Though I suspect very
	few users run into this problem!

	The downside obviously is that this is a UI breaking change.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: allow quoted filenames for commands that have custom completion
	This commit changes how GDB processes command arguments for the
	following commands:

	  compile file
	  maint print c-tdesc
	  save gdb-index

	After this commit these commands will now expect their single filename
	argument to be (optionally) quoted if it contains any special
	characters (e.g. whit space or quotes).

	If the filename does not contain any special characters then nothing
	changes.  As an example:

	   (gdb) save gdb-index /path/to/some/directory/

	will work before and after this patch.  However, if the directory
	name contains a white space then before this patch a user would write:

	  (gdb) save gdb-index /path/to some/directory/

	But this will now fail as GDB will consider this as two arguments,
	'/path/to' and 'some/directory/'.  To pass this single directory name
	a user must now do one of these:

	  (gdb) save gdb-index "/path/to some/directory/"
	  (gdb) save gdb-index '/path/to some/directory/'
	  (gdb) save gdb-index /path/to\ some/directory/

	This brings these commands into line with commands like 'file' and
	'symbol-file', which have supported quoted filenames for a while.

	The motivation for this change is to make handling of filename
	arguments consistent throughout GDB.  We can't move to all commands
	taking non-quoted filenames as the non-quoted style only allows for a
	single argument.  Additionally, the non-quoted style doesn't allow for
	filenames that end in white space (though this is probably pretty
	rare).  So, if we want to have consistency the only choice is to move
	towards supporting quote filenames.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: add remove-symbol-file command completion
	The 'remove-symbol-file' command doesn't currently offer command
	completion.  This commit addresses this.

	The 'remove-symbol-file' uses gdb_argv to split its command arguments,
	this means that the filename the command expects can be quoted.

	However, the 'remove-symbol-file' command is a little weird in that it
	also has a '-a' option, if this option is passed then the command
	expects not a filename, but an address.

	Currently the remove_symbol_file_command function splits the command
	args using gdb_argv, checks for a '-a' flag by looking at the first
	argument value, and then expects the filename or address to occupy a
	single entry in the gdb_argv array.

	The first thing I do is handle the '-a' flag using GDB's option
	system.  I model this option as a flag_option_def (a boolean option).

	I've dropped the use of gdb_argv and instead use the new(ish) function
	extract_single_filename_arg, which was added a couple of commits back,
	to parse the filename argument (when '-a' is not given).

	If '-a' is given the the remove-symbol-file command expects an address
	rather than a filename.  As we previously split the arguments using
	gdb_argv this meant the address needed to appear as a single
	argument.  So a user could write:

	  (gdb) remove-symbol-file 0x1234

	Or they could write:

	  (gdb) remove-symbol-file some_function

	Both of these would work fine.  But a user could not write:

	  (gdb) remove-symbol-file some_function + 0x1000

	As only the 'some_function' part would be processed.  Now the user
	could do this:

	  (gdb) remove-symbol-file "some_function + 0x1000"

	By enclosing the address expression in quotes this would be handled as
	a single argument.  However, this is a little weird, that's not how
	commands like 'print' or 'x' work.  Also this functionality was
	neither documented, or tested.

	And so, in this commit, by removing the use of gdb_argv I bring the
	'remove-symbol-file' command inline with GDB's other commands that
	take an expression, the quotes are no longer needed.

	Usually in a completer we call 'complete_options', but don't actually
	capture the option values.  But for remove-symbol-file I do.  This
	allows me to spot when the '-a' option has been given, I can then
	complete the rest of the command line as either a filename or an
	expression.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: extend completion of quoted filenames to work in brkchars phase
	Up to this point filename completion for possibly quoted filenames has
	always been handled during the second (non-brkchars) phase of
	completion.  This works fine for commands that only want to complete
	on a single filename argument.

	In a later commit though I need to perform completion of a quoted
	filename argument during the first (brkchars) phase of completion.
	This will allow me to add a custom completer that completes both
	command options and arguments for a command (remove-symbol-file) that
	takes a possibly quoted filename argument.

	This commit doesn't add the remove-symbol-file completer, this commit
	is just about putting support for that in place.

	To achieve this I've added the new function
	advance_to_filename_maybe_quoted_complete_word_point, which is unused
	in this commit.  I've then had to extend some other functions in order
	to extract the quoting state during the brkchars phase.

	As this commit doesn't use the new functionality, the important thing
	at this point is that I've not regressed the existing filename
	completion (or any of the other completion).  The next commit in this
	series will make use of the new functionality, and will include
	tests.

	There should be no user visible changes after this commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: new extract_single_filename_arg helper function
	This commit is in preparation for the next few commits, this commit
	adds a new function extract_single_filename_arg.

	This new function will be used to convert GDB commands that expect a
	single filename argument to have these commands take a possibly quoted
	or escaped string.

	There's no use of the new function in this commit, for that see the
	following commits.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: implement readline rl_directory_rewrite_hook callback
	Implement the readline rl_directory_rewrite_hook callback function,
	this is used when readline needs to offer completions from within a
	directory.  The important thing is that this function should remove
	any escaping, this allows GDB to correctly offer completions in
	situations like this:

	  (gdb) file /tmp/directory\ with\ spaces/<TAB><TAB>

	Note the escaping in 'directory\ with\ spaces'.  Without the
	rl_directory_rewrite_hook callback readline will try to open a
	directory literally called '/tmp/directory\ with\ spaces' which
	obviously doesn't exist.

	There are tests added to cover this new functionality.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve gdb_rl_find_completion_word for quoted words
	The function gdb_rl_find_completion_word is very similar to the
	readline function _rl_find_completion_word, but was either an older
	version of that function, or was trimmed when copying to remove code
	which was considered unnecessary.

	We maintain this copy because the _rl_find_completion_word function is
	not part of the public readline API, and we need to replicate the
	functionality of that function as part of the 'complete' command.

	Within gdb_rl_find_completion_word when looking for the completion
	word, if we don't find a unclosed quoted string (which would become
	the completion word) then we scan backwards looking for a word break
	character.  For example, given:

	  (gdb) complete file /tmp/foo

	There is no unclosed quoted string so we end up scanning backwards
	from the end looking for a word break character.  In this case the
	space after 'file' and before '/tmp/foo' is found, so '/tmp/foo'
	becomes the completion word.

	However, given this:

	  (gdb) complete file /tmp/foo\"

	There is still no unclosed quoted string, however, when we can
	backwards the '"' (double quotes) are treated as a word break
	character, and so we end up using the empty string as the completion
	word.

	The readline function _rl_find_completion_word avoids this mistake by
	using the rl_char_is_quoted_p hook.  This function will return true
	for the double quote character as it is preceded by a backslash.  An
	earlier commit in this series supplied a rl_char_is_quoted_p function
	for the filename completion case, however, gdb_rl_find_completion_word
	doesn't call rl_char_is_quoted_p so this doesn't help for the
	'complete' case.

	In this commit I've copied the code to call rl_char_is_quoted_p from
	_rl_find_completion_word into gdb_rl_find_completion_word.

	This half solves the problem.  In the case:

	  (gdb) complete file /tmp/foo\"

	We do now try to complete on the string '/tmp/foo\"', however, when we
	reach filename_completer we call back into readline to actually
	perform filename completion.  However, at this point the WORD variable
	points to a string that still contains the backslash.  The backslash
	isn't part of the actual filename, that's just an escape character.

	Our expectation is that readline will remove the backslash when
	looking for matching filenames.  However, readline contains an
	optimisation to avoid unnecessary work trying to remove escape
	characters.

	The readline variable rl_completion_found_quote is set in the readline
	function gen_completion_matches before the generation of completion
	matches.  This variable is set to true (non-zero) if there is (or
	might be) escape characters within the completion word.

	The function rl_filename_completion_function, which generates the
	filename matches, only removes escape characters when
	rl_completion_found_quote is true.  When GDB generates completions
	through readline (e.g. tab completion) then rl_completion_found_quote
	is set correctly.

	But when we use the 'complete' command we don't pass through readline,
	and so gen_completion_matches is never called and
	rl_completion_found_quote is not set.  In this case when we call
	rl_filename_completion_function readline doesn't remove the escapes
	from the completion word, and so in our case above, readline looks for
	completions of the exact filename '/tmp/foo\"', that is, the filename
	including the backslash.

	To work around this problem I've added a new flag to our function
	gdb_rl_find_completion_word which is set true when we find any quoting
	or escaping.  This matches what readline does.

	Then in the 'complete' function we can set rl_completion_found_quote
	prior to generating completion matches.

	With this done the 'complete' command now works correctly when trying
	to complete filenames that contain escaped word break characters.  The
	tests have been updated accordingly.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: apply escaping to filenames in 'complete' results
	Building on the mechanism added in the previous commit(s), this commit
	applies escaping to filenames in the 'complete' command output.
	Consider a file: /tmp/xxx/aa"bb -- that is a filename that contains a
	double quote, currently the 'complete' command output looks like this:

	  (gdb) complete file /tmp/xxx/a
	  file /tmp/xxx/aa"bb

	Notice that the double quote in the output is not escaped.  If we
	passed this same output back to GDB then the double quote will be
	treated as the start of a string.

	After this commit then the output looks like this:

	  (gdb) complete file /tmp/xxx/a
	  file /tmp/xxx/aa\"bb

	The double quote is now escaped.  If we feed this output back to GDB
	then GDB will treat this as a single filename that contains a double
	quote, exactly what we want.

	To achieve this I've done a little refactoring, splitting out the core
	of gdb_completer_file_name_quote, and then added a new call from the
	filename_match_formatter function.

	There are updates to the tests to cover this new functionality.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: add match formatter mechanism for 'complete' command output
	This commit solves a problem that existed prior to the previous
	commit, but the previous commit made more common.

	When completing a filename with the 'complete' command GDB will always
	add a trailing quote character, even if the completion is a directory
	name, in which case it would be better if the trailing quote was not
	added.  Consider:

	  (gdb) complete file '/tmp/xx
	  file '/tmp/xxx/'

	The completion offered here is really only a partial completion, we've
	completed up to the end of the next directory name, but, until we have
	a filename then the completion is not finished and the trailing quote
	should not be added.

	This would match the readline behaviour, e.g.:

	  (gdb) file '/tmp/xx<TAB>
	  (gdb) file '/tmp/xxx/

	In this case readline completes the directory name, but doesn't add
	the trailing quote character.

	Remember that the 'complete' command is intended for tools like
	e.g. emacs in order that they can emulate GDB's standard readline
	completion when implementing a CLI of their own.  As such, not adding
	the trailing quote in this case matches the readline behaviour, and
	seems like the right way to go.

	To achieve this, I've added a new function pointer member variable
	completion_result::m_match_formatter.  This contains a pointer to a
	callback function which is used by the 'complete' command to format
	each result.

	The default behaviour of this callback function is to just append the
	quote character (the character from before the completion string) to
	the end of the completion result.  This matches the current behaviour.

	However, for filename completion we override the default value of
	m_match_formatter, this new function checks if the completion result
	is a directory or not.  If the completion result is a directory then
	the closing quote is not added, instead we add a trailing '/'
	character.

	The code to add a trailing '/' character already exists within the
	filename_completer function.  This is no longer needed in this
	location, instead this code is moved into the formatter callback.

	Tests are updated to handle the changes in functionality, this removes
	an xfail added in the previous commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: simplify completion_result::print_matches
	Simplify completion_result::print_matches by removing one of the code
	paths.  Now, every time we call ::print_matches we always add the
	trailing quote.

	Previously, when using the 'complete' command, if there was only one
	result then trailing quote was added in ::build_completion_result, but
	when we had multiple results the trailing quote was added in
	::print_matches.  As a consequence, ::print_matches had to understand
	not to add the trailing quote for the single result case.

	After this commit we don't add the trailing quote in
	::build_completion_result, instead ::print_matches always adds the
	trailing quote, which makes ::print_matches simpler.

	However, there is a slight problem.  When completion is being driven
	by readline, and not by the 'complete' command, we still need to
	manually add the trailing quote in the single result case, and as the
	printing is done by readline we can't add the quote at the time of
	printing, and so, in ::build_completion_result, we still add the
	trailing quote, but only when completion is being done for readline.

	And this does cause a small problem.  When completing a filename, if
	the completion results in a directory name then, when using the
	'complete' command, GDB should not be adding a trailing quote.  For
	example, if we have the file /tmp/xxx/foo.c, then what we should see
	is this:

	  (gdb) complete file '/tmp/xx
	  file 'tmp/xxx/

	But what we actually see after this commit is this:

	  (gdb) complete file '/tmp/xx
	  file 'tmp/xxx/'

	Previously we didn't get the trailing quote in this case, as when
	there is only a single result, the quote was added in
	::build_completion_result, and for filename completion, GDB didn't
	know what the quote character was in ::build_completion_result, so no
	quote was added.  Now that the trailing quote is always added in
	::print_matches, and GDB does know the quote character at this point,
	so we are now getting the trailing quote, which is not correct.

	This is a regression, but really, GDB is now broken in a consistent
	way, if we create the file /tmp/xxa/bar.c, then previously if we did
	this:

	  (gdb) complete file '/tmp/xx
	  file '/tmp/xxa/'
	  file '/tmp/xxx/'

	Notice how we get the trailing quote in this case, this is the before
	patch behaviour, and is also wrong.

	A later commit will fix things so that the trailing quote is not added
	in this filename completion case, but for now I'm going to accept this
	small regression.

	This change in behaviour caused some failures in one of the completion
	tests, I've tweaked the test case to expect the trailing quote as part
	of this commit, but will revert this in a later commit in this series.

	I've also added an extra test for when the 'complete' command does
	complete to a single complete filename, in which case the trailing
	quote is expected.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: move display of completion results into completion_result class
	This commit moves the printing of the 'complete' command results out
	of the 'complete_command' function.  The printing is now done in a new
	member function 'completion_result::print_matches'.  At this point,
	this is entirely a refactor.

	The motivation for this refactor is how 'complete' should print the
	completion of filename arguments.  In some cases the filename results
	need to have escaping added to the output.  This escaping needs to be
	done immediately prior to printing the result as adding too early will
	result in multiple 'complete' results potentially being sorted
	incorrectly.  See the subsequent commits for more details.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve escaping when completing filenames
	This improves quoting and escaping when completing filenames for
	commands that allow filenames to be quoted and escaped.

	I've struggled a bit trying to split this series into chunks.  There's
	a lot of dependencies between different parts of the completion
	system, and trying to get this working correctly is pretty messy.

	This first step is really about implementing 3 readline hooks:

	  rl_char_is_quoted_p
	    - Is a particular character quoted within readline's input buffer?
	  rl_filename_dequoting_function
	    - Remove quoting characters from a filename.
	  rl_filename_quoting_function
	    - Add quoting characters to a filename.

	See 'info readline' for full details, but with these hooks connected
	up, readline (on behalf of GDB) should do a better job inserting
	backslash escapes when completing filenames.

	There's still a bunch of stuff that doesn't work after this commit,
	mostly around the 'complete' command which of course doesn't go
	through readline, so doesn't benefit from all of these new functions
	yet, I'll add some of this in a later commit.

	Tab completion is now slightly improved though, it is possible to
	tab-complete a filename that includes a double or single quote, either
	in an unquoted string or within a string surrounded by single or
	double quotes, backslash escaping is used when necessary.

	There are some additional tests to cover the new functionality.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: deprecated filename_completer and associated functions
	Following on from the previous commit, this commit marks the old
	unquoted filename completion related functions as deprecated.

	The aim of doing this is to make it more obvious to someone adding a
	new command that they should not be using the older unquoted style
	filename argument handling.

	I split this change from the previous to make for an easier review.
	This commit touches more files, but is _just_ function renaming.
	Check out gdb/completer.{c,h} for what has been renamed.  All the
	other files have just been updated to use the new names.

	There should be no user visible changes after this commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: split apart two different types of filename completion
	Unfortunately we have two different types of filename completion in
	GDB.

	The majority of commands have what I call unquoted filename
	completion, this is for commands like 'set logging file ...', 'target
	core ...', and 'add-auto-load-safe-path ...'.  For these commands
	everything after the command name (that is not a command option) is
	treated as a single filename.  If the filename contains white space
	then this does not need to be escaped, nor does the filename need to
	be quoted.  In fact, the filename argument is not de-quoted, and does
	not have any escaping removed, so if a user does try to add such
	things, they will be treated as part of the filename.  As an example:

	  (gdb) target core "/path/that contains/some white space"

	Will look for a directory calls '"' (double quotes) in the local
	directory.

	A small number of commands do de-quote and remove escapes from
	filename arguments.  These command accept what I call quoted and
	escaped filenames.  Right now these are the commands that specify the
	file for GDB to debug, so:

	  file
	  exec-file
	  symbol-file
	  add-symbol-file
	  remove-symbol-file

	As an example of this in action:

	  (gdb) file "/path/that contains/some white space"

	In this case GDB would load the file:

	  /path/that contains/some white space

	Current filename completion always assumes that filenames can be
	quoted, though escaping doesn't work in completion right now.  But the
	assumption that quoting is allowed is clearly wrong.

	This commit splits filename completion into two.  The existing
	filename_completer is retained, and is used for unquoted filenames.  A
	second filename_maybe_quoted_completer is added which can be used for
	completing quoted filenames.

	The filename completion test has been extended to cover more cases.
	As part of the extended testing I need to know the character that
	should be used to separate filenames within a path.  For this TCL 8.6+
	has $::tcl_platform(pathSeparator).  To support older versions of TCL
	I've added some code to testsuite/lib/gdb.exp.

	You might notice that after this commit the completion for unquoted
	files is all done in the brkchars phase, that is the function
	filename_completer_handle_brkchars calculates the completions and
	marks the completion_tracker as using a custom word point.  The reason
	for this is that we don't want to break on white space for this
	completion, but if we rely on readline to find the completion word,
	readline will consider the entire command line, and with no white
	space in the word break character set, readline will end up using the
	entire command line as the word to complete.

	For now at least, the completer for quoted filenames does generate its
	completions during the completion phase, though this is going to
	change in a later commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: unify build-id to objfile lookup code
	There are 3 places where we currently call debuginfod_exec_query to
	lookup an objfile for a given build-id.

	In one of these places we first call build_id_to_exec_bfd which also
	looks up an objfile given a build-id, but this function looks on disk
	for a symlink in the .build-id/ sub-directory (within the
	debug-file-directory).

	I can't think of any reason why we shouldn't call build_id_to_exec_bfd
	before every call to debuginfod_exec_query.

	So, in this commit I have added a new function in build-id.c,
	find_objfile_by_build_id, this function calls build_id_to_exec_bfd,
	and if that fails, then calls debuginfod_exec_query.

	Everywhere we call debuginfod_exec_query is updated to call the new
	function, and in locate_exec_from_corefile_build_id, the existing call
	to build_id_to_exec_bfd is removed as calling find_objfile_by_build_id
	does this for us.

	One slight weird thing is in core_target::build_file_mappings, here we
	call find_objfile_by_build_id which returns a gdb_bfd_ref_ptr for the
	opened file, however we immediately reopen the file as "binary".  The
	reason for this is that all the bfds opened in ::build_file_mappings
	need to be opened as "binary" (see the function comments for why).

	I did consider passing a target type into find_objfile_by_build_id,
	which could then be forwarded to build_id_to_exec_bfd and used to open
	the BFD as "binary", however, if you follow the call chain you'll end
	up in build_id_to_debug_bfd_1, where we actually open the bfd.  Notice
	in here that we call build_id_verify to double check the build-id of
	the file we found, this requires that the bfd not be opened as
	"binary".

	What this means is that we always have to first open the bfd using the
	gnutarget target type (for the build-id check), and then we would have
	to reopen it as "binary".  There seems little point pushing the reopen
	logic into find_objfile_by_build_id, so we just do this in the
	::build_file_mappings function.

	I've extended the tests to cover the two cases which actually changed
	in this commit.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve shared library build-id check for core-files
	When GDB opens a core file, in 'core_target::build_file_mappings ()',
	we collection information about the files that are mapped into the
	core file, specifically, the build-id and the DT_SONAME attribute for
	the file, which will be set for some shared libraries.

	We then cache the DT_SONAME to build-id information on the core file
	bfd object in the function set_cbfd_soname_build_id.

	Later, when we are loading the shared libraries for the core file, we
	can use the library's file name to look in the DT_SONAME to build-id
	map, and, if we find a matching entry, we can use the build-id to
	validate that we are loading the correct shared library.

	This works OK, but has some limitations: not every shared library will
	have a DT_SONAME attribute.  Though it is good practice to add such an
	attribute, it's not required.  A library without this attribute will
	not have its build-id checked, which can lead to GDB loading the wrong
	shared library.

	What I want to do in this commit is to improve GDB's ability to use
	the build-ids extracted in core_target::build_file_mappings to both
	validate the shared libraries being loaded, and then to use these
	build-ids to potentially find (via debuginfod) the shared library.

	To do this I propose making the following changes to GDB:

	(1) Rather than just recording the DT_SONAME to build-id mapping in
	set_cbfd_soname_build_id, we should also record, the full filename to
	build-id mapping, and also the memory ranges to build-id mapping for
	every memory range covered by every mapped file.

	(2) Add a new callback solib_ops::find_solib_addr.  This callback
	takes a solib object and returns an (optional) address within the
	inferior that is part of this library.  We can use this address to
	find a mapped file using the stored memory ranges which will increase
	the cases in which a match can be found.

	(3) Move the mapped file record keeping out of solib.c and into
	corelow.c.  Future commits will make use of this information from
	other parts of GDB.  This information was never solib specific, it
	lived in the solib.c file because that was the only user of the data,
	but really, the data is all about the core file, and should be stored
	in core_target, other parts of GDB can then query this data as needed.

	Now, when we load a shared library for a core file, we do the
	following lookups:

	  1. Is the exact filename of the shared library found in the filename
	  to build-id map?  If so then use this build-id for validation.

	  2. Find an address within the shared library using ::find_solib_addr
	  and then look for an entry in the mapped address to build-id map.
	  If an entry is found then use this build-id.

	  3. Finally, look in the soname to build-id map.  If an entry is
	  found then use this build-id.

	The addition of step #2 here means that GDB is now far more likely to
	find a suitable build-id for a shared library.  Having acquired a
	build-id the existing code for using debuginfod to lookup a shared
	library object can trigger more often.

	On top of this, we also create a build-id to filename map.  This is
	useful as often a shared library is implemented as a symbolic link to
	the actual shared library file.  The mapped file information is stored
	based on the actual, real file name, while the shared library
	information holds the original symbolic link file name.

	If when loading the shared library, we find the symbolic link has
	disappeared, we can use the build-id to file name map to check if the
	actual file is still around, if it is (and if the build-id matches)
	then we can fall back to use that file.  This is another way in which
	we can slightly increase the chances that GDB will find the required
	files when loading a core file.

	Adding all of the above required pretty much a full rewrite of the
	existing set_cbfd_soname_build_id function and the corresponding
	get_cbfd_soname_build_id function, so I have taken the opportunity to
	move the information caching out of solib.c and into corelow.c where
	it is now accessed through the function core_target_find_mapped_file.

	At this point the benefit of this move is not entirely obvious, though
	I don't think the new location is significantly worse than where it
	was originally.  The benefit though is that the cached information is
	no longer tied to the shared library loading code.

	I already have a second set of patches (not in this series) that make
	use of this caching from elsewhere in GDB.  I've not included those
	patches in this series as this series is already pretty big, but even
	if those follow up patches don't arrive, I think the new location is
	just as good as the original location.

	Rather that caching the information within the core file BFD via the
	registry mechanism, the information used for the mapped file lookup is
	now stored within the core_file target directly.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb/corefile: improve file backed mapping handling
	This commit improves how GDB handles file backed mappings within a
	core file, specifically, this is a restructuring of the function
	core_target::build_file_mapping.

	The primary motivation for this commit was to put in place the
	infrastructure to support the next commit in this series, but this
	commit does itself make some improvements.

	Currently in core_target::build_file_mapping we use
	gdbarch_read_core_file_mappings to iterate over the mapped regions
	within a core file.

	For each region a callback is invoked which is passed details of the
	mapping; the file the mapping is from, the offset into the file, and
	the address range at which the mapping exists.  We are also passed the
	build-id for the mapped file in some cases.

	We are only told the build-id for the mapped region which actually
	contains the ELF header of the mapped file.  Other regions of the same
	mapped ELF will not have the build-id passed to the callback.

	Within core_target::build_file_mapping, in the per-region callback, we
	try to find the mapped file based on its filename.  If the file can't
	be found, and if we have a build-id then we'll ask debuginfod to
	download the file.

	However we find the file, we cache the opened bfd object, which is
	good.  Subsequent mappings from the same file will not have a build-id
	set, but by that point we already have a cached open bfd object, so
	the lack of build-id is irrelevant.

	The problem with the above is that if we find a matching file based on
	the filename, then we accept that file, even if we have a build-id,
	and the build-id doesn't match.

	Currently, the mapped region processing is done in a single pass, we
	call gdbarch_read_core_file_mappings, and for each mapping, as we see
	it, we create the data structures needed to represent that mapping.

	In this commit, I will change this to a two phase process.  In the
	first phase the mappings are grouped together based on the name of the
	mapped file.  At the end of phase one we have a 'struct mapped_file',
	a new struct, for each mapped file.  This struct associates an
	optional build-id with a list of mapped regions.

	In the second phase we try to find the file using its filename.  If
	the file is found, and the 'struct mapped_file' has a build-id, then
	we'll compare the build-id with the file we found.  This allows us to
	reject on-disk files which have changed since the core file was
	created.

	If no suitable file was found (either no file found, or a build-id
	mismatch) then we can use debuginfod to potentially download a
	suitable file.

	  NOTE: In the future we could potentially add additional sanity
	  checks here, for example, if a data-file is mapped, and has no
	  build-id, we can estimate a minimum file size based on the expected
	  mappings.  If the file we find is not big enough then we can reject
	  the on-disk file.  But I don't know how useful this would actually
	  be, so I've not done that for now.

	Having found (or not) a suitable file then we can create the data
	structures for each mapped region just as we did before.

	The new functionality here is the extra build-id check, and the
	possibility of rejecting an on-disk file if the build-id doesn't
	match.

	This change could have been done within the existing single phase
	approach I think, however, in the next approach I need to have all the
	mapped regions associated with the expected build-id, and the new two
	phase structure allows me to do that, this is the reason for such an
	extensive rewrite in this commit.

	There's a new test that exercises GDB's ability to find mapped files
	via the build-id, and this downloading from debuginfod.

2024-09-07  Andrew Burgess  <aburgess@redhat.com>

	gdb/corefile: don't pretend unavailable sections are readable
	When GDB opens a core file the bfd library processes the core file and
	creates sections within the bfd object to represent each of the
	segments within the core file.

	GDB then creates two target_section lists, m_core_section_table and
	m_core_file_mappings, these, along with m_core_unavailable_mappings,
	are used by GDB to implement core_target::xfer_partial; this is the
	function used when GDB tries to read memory from a core file inferior.

	The m_core_section_table list represents sections within the core file
	itself.  The sections in this list can be split into two groups based
	on whether the section has the SEC_HAS_CONTENTS flag set or not.

	Sections (from the core file) that have the SEC_HAS_CONTENTS flag had
	their contents copied into the core file when the core file was
	created.  These correspond to writable sections within the original
	inferior (the inferior for which the core file was created).

	Sections (from the core file) that do not have the SEC_HAS_CONTENTS
	flag will not have had their contents copied into the core file when
	it was created.  These sections correspond to read-only sections
	mapped from a file (possibly the initial executable, or possibly some
	other file) in the original inferior.  The expectation is that the
	contents of these sections can still be found by looking in the file
	that was originally mapped.

	The m_core_file_mappings list is created when GDB parses the mapped
	file list in the core file.  Every mapped region will be covered by
	entries in the m_core_section_table list (see above), but for
	read-only mappings the entry in m_core_section_table will not have the
	SEC_HAS_CONTENTS flag set.  As GDB parses the mapped file list, if the
	file that was originally mapped can be found, then GDB creates an
	entry in the m_core_file_mappings list which represents the region
	of the file that was mapped into the original inferior.

	However, GDB only creates entries in m_core_file_mappings if it is
	able to find the correct on-disk file to open.  If the file can't be
	found then an entry is added to m_core_unavailable_mappings instead.

	If is the handling m_core_unavailable_mappings which I think is
	currently not completely correct.

	When a read lands within an m_core_unavailable_mappings region we
	currently forward the read to the exec file stratum.  The reason for
	this is this: when GDB read the mapped file list, if the executable
	file could not be found at the expected path then mappings within the
	executable will end up in the m_core_unavailable_mappings list.

	However, the user might provide the executable to GDB from a different
	location.  If this happens then forwarding the read to the exec file
	stratum might give a result.

	But, if the exec file stratum does not resolve the access then
	currently we continue through ::xfer_partial, the next step of which
	is to handle m_core_section_table entries that don't have the
	SEC_HAS_CONTENTS flag set.  Every m_core_unavailable_mappings entry
	will naturally have an m_core_section_table without the
	SEC_HAS_CONTENTS flag set, and so we treat the unavailable mapping as
	zero initialised memory and return all zeros.

	It is this fall through behaviour that I think is wrong.  If a read
	falls in an unavailable region, and the exec file stratum cannot help,
	then I think the access should fail.

	To achieve this goal I have removed the xfer_memory_via_mappings
	helper function and moved its content inline into ::xfer_partial.
	Now, if an access is within an m_core_unavailable_mappings region, and
	the exec file stratum doesn't help, we immediately return with an
	error.

	The reset of ::xfer_partial is unchanged, I've extended some comments
	in the area that I have changed to (I hope) explain better what's
	going on.

	There's a new test that covers the new functionality, an inferior maps
	a file and generates a core file.  We then remove the mapped file,
	load the core file and try to read from the mapped region.  The
	expectation is that GDB should give an error rather than claiming that
	the region is full of zeros.

2024-09-07  Xin Wang  <yw987194828@gmail.com>

	Not append rela for absolute symbol
	LoongArch: Not append rela for absolute symbol

	Use la.global to get absolute symbol like la.abs.
	la.global put address of a global symbol into a got
	entry and append a rela for it, which will be used
	to relocate by dynamic linker. Dynamic linker should
	not relocate for got entry of absolute symbol as it
	stores symval not symbol's address.

2024-09-07  Xin Wang  <yw987194828@gmail.com>

	Add macros to get opcode of instructions approriately
	LoongArch: Add macros to get opcode and register of instructions appropriately

	Currently, we get opcode of an instruction by manipulate the binary with
	it's mask, it's a bit of a pain. Now a macro is defined to do this and a
	macro to get the RD and RJ registers which is applicable to most instructions
	of LoongArch are added.

2024-09-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Rename gp-* man pages to gprofng-* man pages
	gprofng/ChangeLog
	2024-09-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		* doc/gp-archive.texi: Rename to doc/gprofng-archive.texi.
		* doc/gp-collect-app.texi: Rename to doc/gprofng-collect-app.texi.
		* doc/gp-display-html.texi: Rename to doc/gprofng-display-html.texi.
		* doc/gp-display-src.texi: Rename to doc/gprofng-display-src.texi.
		* doc/gp-display-text.texi: Rename to doc/gprofng-display-text.texi.
		* doc/gp-macros.texi: Add new macros.
		* doc/gprofng.texi: Rename man pages.
		* doc/gprofng_ug.texi: Likewise.
		* doc/Makefile.am: Likewise.
		* doc/Makefile.in: Rebuild.

2024-09-06  Tom Tromey  <tromey@adacore.com>

	Fix 'catch exception' with -flto
	A user noticed that when an Ada program (including the runtime) is
	compiled with -flto, then "catch exception" does not work -- even
	though setting the equivalent breakpoint by hand does work.

	Looking into this, it turns out that GCC puts the exception functions
	from the Ada runtime into a CU that uses the C language, not Ada.
	Then, when trying to look up the relevant symbol,
	lookup_name_info::search_name_hash uses the "verbatim" form of the
	symbol name (like "<__gnat_debug_raise_exception>") rather than the
	"<>"-less form, causing the symbol not to be found.

	This patch fixes the problem in two steps.

	First, lookup_name_info::search_name_hash is changed to use the same
	hack that language_defn::get_symbol_name_matcher uses.  That is, when
	the current language is Ada, verbatim-mode lookups are special-cased.
	(This is a bit unfortunate; perhaps a better long term approach would
	be to promote verbatim mode to a fundamental mode of
	lookup_name_info.)

	Second, although the above fixes the problem in the Ada language mode,
	the code still fails in other languages.  However, due to the way
	these lookups are coded in ada-lang.c, I think it makes sense to
	temporarily set the current language to Ada in
	create_ada_exception_catchpoint.

	Tested on x86-64 Fedora 38.

	A new test case that mimics the -flto scenario is included.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-09-06  Tom Tromey  <tromey@adacore.com>

	Clear Ada symbol cache
	This patch changes "maint flush symbol-cache" to also flush the
	Ada-specific symbol cache.  This can be helpful when working on the
	Ada code.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-06  Tom Tromey  <tromey@adacore.com>

	Test -fgnat-encodings=all in tagged_access.exp
	While working on a longer series, I needed to make sure this
	particular test kept working with -fgnat-encodings=all, so this patch
	adds it to the test.

	Introduce and use foreach_gnat_encoding
	gnat-llvm does not support the -fgnat-encodings flag.  This patch
	prepares gdb's Ada tests to handle this situation by introducing a new
	foreach_gnat_encoding.  A subsequent patch may change this to support
	gnat-llvm; meanwhile this is a little cleaner anyway.

2024-09-06  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix the build-id option for GCC default configuration
	It is possible that the compiler is configured to do
	so automatically, but at least for GCC the configure option
	--enable-linker-build-id is not enabled by default.
	So the option -Wl,--build-id should be used regardless
	of which compiler is used.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-09-06  Shahab Vahedi  <shahab.vahedi@amd.com>

	bfd: Fix GCC warning when CFLAGS="-Og" is used
	This patch initializes the "op" variable in skip_cfa_op() function
	of bfd/elf-eh-frame.c to "0" at its declaration point to avoid the
	"maybe-uninitialized" warning.

	Building binutils on a system with GCC version 13.2.0 and a configure
	command that sets the optimization level to "-Og" leads to a build
	failure because of a warning being treated as an error:
	---------------------------------------------------------------------
	$ ./configure CFLAGS="-Og"
	$ make
	  ...
	  CC       elf-eh-frame.lo
	  /src/gdb/bfd/elf-eh-frame.c: In function 'skip_cfa_op':
	  /src/gdb/bfd/elf-eh-frame.c:354:33: error: 'op' may be used
	    uninitialized [-Werror=maybe-uninitialized]
	  354 |   switch (op & 0xc0 ? op & 0xc0 : op)
	      |           ~~~~~~~~~~~~~~~~~~~~~~^~~~
	  /src/gdb/bfd/elf-eh-frame.c:348:12: note: 'op' was declared here
	  348 |   bfd_byte op;
	      |            ^~
	  cc1: all warnings being treated as errors
	  ...
	---------------------------------------------------------------------

	The relevant code snippet related to this warning looks like:
	---------------------------------------------------------------------
	  static inline bool
	  read_byte (bfd_byte **iter, bfd_byte *end, unsigned char *result)
	  {
	    if (*iter >= end)
	      return false;
	    *result = *((*iter)++);
	    return true;
	  }

	  static bool
	  skip_cfa_op (bfd_byte **iter, bfd_byte *end,...)
	  {
	    bfd_byte op;

	    if (!read_byte (iter, end, &op))
	      return false;

	    switch (op & 0xc0 ? op & 0xc0 : op)
	    ...
	  }
	---------------------------------------------------------------------

	This warning probably happens because "-Og" results in GCC not
	inlining the "read_byte()" function. Therefore, GCC treats its
	invocation inside "skip_cfa_op()" like a black box and that ends
	in the aforementioned warning.

	Acknowledgement:
	  Lancelot Six -- for coming with the idea behind this fix.
	  Jan Beulich  -- for reviewing.

	bfd/ChangeLog:
		* elf-eh-frame.c (skip_cfa_op): Initialize the "op" variable.

2024-09-06  Jan Beulich  <jbeulich@suse.com>

	x86/APX: use D for 2-operand CFCMOVcc
	There's no need to have 30 redundant templates when we can easily take
	care of the operand swapping like we do for various other insns.

	x86/APX: optimize certain reg-only CFCMOVcc forms
	Along the lines of 2513312930b2 ("x86/APX: apply NDD-to-legacy
	transformation to further CMOVcc forms") these can similarly be
	converted to the shorter legacy-encoded CMOVcc.

	bfd/PE: correct SizeOfImage calculation
	We don't really want to align the last section's size to object
	alignment (when that section may itself not be aligned as much), we want
	image size to be a multiple thereof.

	x86: templatize VNNI templates
	Reduce redundancy, in preparation of the addition of further counterparts
	for AVX10.2.

2024-09-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-05  Mark Harmstone  <mark@harmstone.com>

	bfd/pdb: fix -Wmaybe-uninitialized warning
	Initialize stream0_start to fix spurious -Wmaybe-uninitialized warning
	on some versions of gcc.

2024-09-05  Alan Modra  <amodra@gmail.com>

	PR32136, Use-of-uninitialized-memory in evax_bfd_print_image
		 PR 32136
		 * vms-alpha.c (evax_bfd_print_image): Sanity check various string
		 lengths.

2024-09-05  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdbserver: aarch64: Fix expedited registers list
	Since this commit:

	  commit a8651ef51822f91ec86d0d5caffbf2e50b174c23
	  CommitDate: Fri Jun 14 14:47:38 2024 +0100

	      gdb/aarch64: prevent crash from in process agent

	gdbserver isn't sending expedited registers with its stop reply packets
	anymore.  The problem is with how the constructor of the
	expedited_registers std::vector is called:

	The intent of the expedited_registers initialization in
	aarch64_linux_read_description is to create a vector with capacity for 6
	elements, but that's not how the std::vector constructor works.

	Instead it creates a vector pre-populated with 6 elements initialized
	with the default value for the type of the elements, and thus the first
	6 elements are null pointers.  The actual expedited registers are added
	starting at the 7th element.

	This causes init_target_desc to consider that the expedite_regs list is
	empty, since it stops checking at the first nullptr element.  The end
	result is that gdbserver doesn't send any expedited registers to GDB in
	its stop replies.

	Fix by not specifying an element count when declaring the vector.

	Tested for regressions on aarch64-linux-gnu native-extended-remote.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-09-05  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fixed ABI v1.00 TLS dynamic relocation generation bug
	Commit "b67a17aa7c0c478a" modified the logic of allocating dynamic
	relocation space for TLS GD/IE, but only modified the logic of
	generation dynamic relocations for TLS GD/IE in ABI v2.00. When
	linking an object file of ABI v1.00 with bfd ld of ABI v2.00, it
	will cause an assertion failure.

	Modified the dynamic relocation generation logic of TLS GD/IE
	in ABI v1.00 to be consistent with ABI v2.00.

2024-09-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-04  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 32097 Warnings when building gprofng with Clang
	gprofng/ChangeLog
	2024-09-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		PR gprofng/32097
		* common/hwcdrv.c: Fix -Wempty-body warnings.
		* common/hwcentry.h: Fix -Wdeprecated-non-prototype warnings.
		* common/hwctable.c: Fix -Wdeprecated-non-prototype warnings.
		* libcollector/collector.c: Likewise.
		* libcollector/collector.h: Likewise.
		* libcollector/collectorAPI.c: Likewise.
		* libcollector/dispatcher.c: Likewise.
		* libcollector/iotrace.c: Likewise.
		* libcollector/libcol_util.c: Fix -Wunused-but-set-variable warnings.
		* libcollector/libcol_util.h: Remove unused declarations.
		* libcollector/linetrace.c: Fix -Wdeprecated-non-prototype warnings.
		* src/BaseMetricTreeNode.h: Fix -Wunused-private-field warnings.
		* src/Dbe.cc: Fix -Wself-assign warnings.
		* src/DbeSession.cc: Fix -Wunused-but-set-variable warnings.
		* src/Disasm.cc: Fix -Wunused-const-variable warnings.
		* src/Experiment.cc: Fix -Wunused-private-field warnings.
		* src/HashMap.h: Fix -Wself-assign warnings.
		* src/IOActivity.h: Fix -Wunused-private-field warnings.
		* src/collctrl.cc: Fix -Wself-assign, -Wparentheses-equality warnings.
		* src/collctrl.h: Fix -Wunused-private-field warnings.
		* src/collector_module.h: Fix -Wdeprecated-non-prototype warnings.
		* src/gp-display-src.cc: Fix -Wunused-private-field warnings.
		* src/gp-print.h: Fix -Wheader-guard warnings.
		* src/hwc_intel_icelake.h: Fix -Winitializer-overrides warnings.
		* src/util.cc: Fix -Wunused-but-set-variable warnings.

2024-09-04  Tom Tromey  <tromey@adacore.com>

	Improve comments in dwarf2/parent-map.h
	I noticed that the comments for class parent_map aren't very clear.
	This patch attempts to fix this, and also clarifies a point on
	parent_map_map::add_map.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-09-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: reformat Python file with black
	Fix formatting of a Python file added in commit:

	  commit a92e943014f5e8d6a2eaccaf8a725941ac47a121
	  Date:   Wed Aug 14 15:16:46 2024 +0100

	      gdb: implement ::re_set method for catchpoint class

	No functional change after this commit.

2024-09-04  Andrew Burgess  <aburgess@redhat.com>

	libiberty: sync with gcc
	This syncs binutils-gdb/libiberty with gcc/libiberty up to GCC commit
	64028d626a50410dbf29.  This picks up the follow 3 GCC commits:

	  ea238096883 (gcc-delete-unused-func) libiberty/argv.c: remove only_whitespace
	  5e1d530da87 (gcc-buildargv) libiberty/buildargv: handle input consisting of only white space
	  a87954610f5 libiberty/buildargv: POSIX behaviour for backslash handling

2024-09-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: implement ::re_set method for catchpoint class
	It is possible to attach a condition to a catchpoint.  This can't be
	done when the catchpoint is created, but can be done with the
	'condition' command, this is documented in the GDB manual:

	     You can also use the 'if' keyword with the 'watch' command.  The
	  'catch' command does not recognize the 'if' keyword; 'condition' is the
	  only way to impose a further condition on a catchpoint.

	A GDB crash was reported against Fedora GDB where a user had attached
	a condition to a catchpoint and then restarted the inferior.  When the
	catchpoint was hit GDB would immediately segfault.  I was able to
	reproduce the failure on upstream GDB:

	  (gdb) file ./some/binary
	  (gdb) catch syscall write
	  (gdb) run
	  ...
	  Catchpoint 1 (returned from syscall write), 0x00007ffff7b594a7 in write () from /lib64/libc.so.6
	  (gdb) condition 1 $_streq((char *) $rsi, "foobar") == 0
	  (gdb) run
	  ...
	  Fatal signal: Segmentation fault
	  ...

	What happened here is that on the system in question we had debug
	information available for both the main application and also for
	libc.

	When the condition was attached GDB was stopped inside libc and as the
	debug information was available GDB found a reference to the 'char'
	type (for the cast) inside libc's debug information.

	When the inferior is restarted GDB discards all of the objfiles
	associated with shared libraries, and this includes libc.  As such the
	'char' type, which is objfile owned, is discarded and the reference to
	it from the catchpoint's condition expression becomes invalid.

	Now, if it were a breakpoint instead of a catchpoint, what would
	happen is that after the shared library objfiles had been discarded
	we'd call the virtual breakpoint::re_set method on the breakpoint, and
	this would update the breakpoint's condition expression.  This is
	because user breakpoints are actually instances of the code_breakpoint
	class and the code_breakpoint::re_set method contains the code to
	recompute the breakpoint's condition expression.

	However, catchpoints are instances of the catchpoint class which
	inherits from the base breakpoint class.  The catchpoint class does
	not override breakpoint::re_set, and breakpoint::re_set is empty!

	The consequence of this is that catchpoint condition expressions are
	never recomputed, and the dangling pointer to the now deleted, objfile
	owned type 'char' is left around, and, when the catchpoint is hit, the
	invalid pointer is used when GDB tries to evaluate the condition
	expression.

	In this commit I have implemented catchpoint::re_set.  This is pretty
	simple and just recomputes the condition expression as you'd expect.
	If the condition doesn't evaluate then the catchpoint is marked as
	disabled_by_cond.

	I have also made breakpoint::re_set pure virtual.  With the addition
	of catchpoint::re_set every sub-class of breakpoint now implements the
	::re_set method, and if new sub-classes are added in the future I
	think that they _must_ implement ::re_set in order to avoid this
	problem.  As such falling back to an empty breakpoint::re_set doesn't
	seem helpful.

	For testing I have not relied on stopping in libc and having libc
	debug information available, this doesn't seem like a good idea for
	the GDB testsuite.  Instead I create a (rather pointless) condition
	check that uses a type defined only within a shared library.  When the
	inferior is restarted the catchpoint will temporarily be marked as
	disabled_by_cond (due to the type not being available), but once the
	shared library is loaded again the catchpoint will be re-enabled.
	Without the fixes above then the same crashing behaviour can be
	observed.

	One point of note: the dangling pointer of course exposes undefined
	behaviour, with no guarantee of a crash.  Though a crash is what I
	usually see I have see GDB throw random errors from the expression
	evaluation code, and once, I saw no problem at all!  If you recompile
	GDB with the address sanitizer, or run under valgrind, then the bug
	will be exposed every time.

	After fixing this bug I checked bugzilla and found PR gdb/29960 which
	is the same bug.  I was able to reproduce the bug before this commit,
	and after this commit GDB is no longer crashing.

	Before:

	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) run
	  Starting program: /tmp/hello.x
	  Hello World
	  [Inferior 1 (process 1101855) exited normally]
	  (gdb) catch syscall 1
	  Catchpoint 1 (syscall 'write' [1])
	  (gdb) condition 1 write.fd == 1
	  (gdb) run
	  Starting program: /tmp/hello.x

	  Fatal signal: Segmentation fault
	  ...

	And after:

	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) run
	  Starting program: /tmp/hello.x
	  Hello World
	  Args: ( 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 )
	  [Inferior 1 (process 1102373) exited normally]
	  (gdb) catch syscall 1
	  Catchpoint 1 (syscall 'write' [1])
	  (gdb) condition 1 write.fd == 1
	  (gdb) r
	  Starting program: /tmp/hello.x
	  Error in testing condition for breakpoint 1:
	  Attempt to extract a component of a value that is not a structure.

	  Catchpoint 1 (call to syscall write), 0x00007ffff7eb94a7 in write ()
	     from /lib64/libc.so.6
	  (gdb) ptype write
	  type = <unknown return type> ()
	  (gdb)

	Notice we get the error now when the condition fails to evaluate.
	This seems reasonable given that 'write' will be a function, and
	indeed the final 'ptype' shows that it's a function, not a struct.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29960

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-09-04  Christophe Lyon  <christophe.lyon@linaro.org>

	Revert "contrib: Add autoregen.py"
	This reverts commit e1ad04ad6cd43fb5a876d787da5ac29f72a9c7e5.

2024-09-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/riscv-tdesc-regs.exp
	On riscv64-linux, with test-case gdb.arch/riscv-tdesc-regs.exp I get:
	...
	(gdb) info registers fflags^M
	fflags         0x0      NV:0 DZ:0 OF:0 UF:0 NX:0^M
	(gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers fflags
	info registers frm^M
	frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]^M
	(gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers frm
	...

	The FAILs are produced by:
	...
	foreach reg {fflags frm} {
	    gdb_test_multiple "info registers $reg" "" {
	        -re "^info registers $reg\r\n" {
	            exp_continue
	        }

	        -wrap -re "^Invalid register `$reg`" {
	            fail $gdb_test_name
	        }

	        -wrap -re "^$reg\\s+\[^\r\n\]+" {
	            pass $gdb_test_name
		}
	    }
	}
	...

	The first clause is meant to consume the command.

	The '^' char was updated to mean "consume command", so that clause no longer
	works since it now attempts to consume the command twice.

	Also, it's unnecessary because the following clauses start with ^.

	Then, the second clause is unnecessary because there's a default clause
	producing the FAIL.

	Fix this by simplifying to:
	...
	foreach reg {fflags frm} {
	    gdb_test "info registers $reg" "^$reg\\s+\[^\r\n\]+"
	}
	...

	Tested on riscv64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-09-04  Christophe Lyon  <christophe.lyon@linaro.org>

	arm: Do not insert stubs needing Arm code on Thumb-only cores.
	We recently fixed a bug in libgcc
	(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360)
	where a symbol was missing a %function .type decoration.

	This meant the linker would silently pick the wrong type of 'farcall
	stub', involving Arm-mode instructions on Thumb-only CPUs.

	This patch emits an error instead, and warns in some other cases, to
	encourage users to add the missing '.type foo,%function' directive.

	In practice: in arm_type_of_stub() we no longer try to infer which
	stub to use if the destination is of unknown type and the CPU is
	Thumb-only; so we won't lie to elf32_arm_size_stubs() which does not
	check branch_type.

	If branch_type is ST_BRANCH_TO_ARM but the CPU is Thumb-only, we now
	convert it to ST_BRANCH_TO_THUMB only if the destination is of
	absolute type.  This is to support the case where the destination of
	the branch is defined by the linker script (see thumb-b-lks-sym.s and
	thumb-bl-lks-sym.s testcases for instance).

	The motivating case is covered by the new farcall-missing-type
	testcase, where we now emit an error message.  We do not emit an error
	when branch_type is ST_BRANCH_UNKNOWN and the CPU supports Arm-mode: a
	lot of legacy code (e.g. newlib's crt0.S) lacks the corresponding
	'.type foo, %function' directives and even a (too verbose) warning
	could be perceived as a nuisance.

	Existing testcases where such a warning would trigger:
	arm-static-app.s (app_func, app_func2)
	arm-rel32.s (foo)
	arm-app.s (app_func)
	rel32-reject.s () main)
	fix-arm1176.s (func_to_branch_to)
	but this list is not exhaustive.

	For the sake of clarity, the patch replaces occurrences of
	sym.st_target_internal = 0; with
	sym.st_target_internal = ST_BRANCH_TO_ARM;

	enum arm_st_branch_type is defined in include/elf/arm.h, and relies on
	ST_BRANCH_TO_ARM==0, as sym.st_target_internal is also initialized to
	0 in other target-independent parts of BFD code.  (For instance,
	swapping the ST_BRANCH_TO_ARM and ST_BRANCH_TO_THUMB entries in the
	enum definition leads to 'interesting' results...)

	Regarding the testsuite:
	* new expected warning for thumb-b-lks-sym and thumb-bl-lks-sym
	* new testcase farcall-missing-type to check the new error case
	* attr-merge-arch-2b.s, branch-futures (and bfs-1.s) updated to avoid
	  a diagnostic

	Tested on arm-eabi and arm-pe with no regression.

2024-09-04  Christophe Lyon  <christophe.lyon@linaro.org>

	contrib: Add autoregen.py
	This script is a copy of the current script used by Sourceware's
	autoregen buildbots.

	It is intended as a helper to regenerate files managed by autotools
	(autoconf, automake, aclocal, ....), as well as the toplevel
	Makefile.in which is created by autogen.

	Other files can be updated when using maintainer-mode, but this is not
	covered by this script.

	2024-04-19  Christophe Lyon  <christophe.lyon@linaro.org>

		contrib/
		* autoregen.py: New script.

2024-09-04  Shahab Vahedi  <list@vahedi.org>

	MAINTAINERS: Update my email address

2024-09-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linux
	With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into:
	...
	(gdb) break bar_label^M
	Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, bar () at dw2-lines.c:29^M
	29        foo (2);^M
	(gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\)
	...

	The pass is incorrect because the continue lands at line 29 with "foo (2)"
	instead of line line 27 with "foo (1)".

	A minimal version is:
	...
	$ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label"
	Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29.
	...
	where:
	...
	000004ec <bar>:
	 4ec:	b580      	push	{r7, lr}
	 4ee:	af00      	add	r7, sp, #0

	000004f0 <bar_label>:
	 4f0:	2001      	movs	r0, #1
	 4f2:	f7ff fff1 	bl	4d8 <foo>

	000004f6 <bar_label_2>:
	 4f6:	2002      	movs	r0, #2
	 4f8:	f7ff ffee 	bl	4d8 <foo>
	...

	So, how does this happen?  In short:
	- skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec,
	- thumb_analyze_prologue returns 0x4f2
	  (overshooting by 1 insn, PR tdep/31981), and
	- skip_prologue_sal decides that we're mid-line, and updates to 0x4f6.

	However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue
	use the line info to skip the prologue?

	The answer is that the line info starts at bar_label, not at bar.

	Fixing that allows us to work around PR tdep/31981.

	Likewise in gdb.dwarf2/dw2-line-number-zero.exp.

	Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to
	checking quality of architecture-specific prologue analysis, without being
	written in an architecture-specific way.

	If fails on arm-linux for both marm and mthumb:
	...
	FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much)
	FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much)
	...
	and passes for:
	- x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie}
	- aarch64-linux.

	Tested on arm-linux.

2024-09-04  Mark Harmstone  <mark@harmstone.com>

	bfd/pdb: fix bitmap generation in pdb_write_bitmap
	MSVC 2022 is more pedantic than MSVC 2019 when it comes to loading PDB
	files in readonly mode, and was rejecting PDB files generated by binutils
	because of their invalid free-space bitmaps. It's unknown what would
	have happened if you tried to use MS tools to modify a PDB created by
	binutils, but it probably would have led to a corrupted file.

	This patch fixes pdb_write_bitmap so we generate files that MSVC will accept.

	Specifically there were three things we were doing wrong:

	- We weren't including the superblock (block 0)

	- We were setting bits in bytes backwards (MSB to LSB, rather than LSB to MSB)

	- We should have been marking the contents of stream 0 as free. This is
	  because, as the comment says, it's intended to be used for the
	  directory for the previous write, to allow atomic updates.

2024-09-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-03  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix typos
	Fix a few typos.

	unconditionaly -> unconditionally
	gratuitiously -> gratuitously
	configureable -> configurable
	represention -> representation
	distiguished -> distinguished
	breakpointer -> breakpoint
	asssignments -> assignments
	architectual -> architectural
	compatibity -> compatibility
	adjustement -> adjustment
	unexcepted -> unexpected
	propogated -> propagated
	consistant -> consistent
	succeding -> succeeding
	higlight -> highlight
	detachs -> detach

	Tested by rebuilding on x86_64-linux.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-09-03  Mary Bennett  <mary.bennett682@gmail.com>

	RISC-V: Add support for XCVsimd extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett682@gmail.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvsimd`
		instruction class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:
		* NEWS: Updated.
		* config/tc-riscv.c (validate_riscv_insn): Add custom operands.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Note XCVsimd as an additional ISA extension
		for CORE-V.
		* testsuite/gas/riscv/march-help.l: Add xcvsimd.
		* testsuite/gas/riscv/x-cv-simd.d: New test.
		* testsuite/gas/riscv/x-cv-simd.s: New test.
		* testsuite/gas/riscv/x-cv-simd-fail.d: New test.
		* testsuite/gas/riscv/x-cv-simd-fail.l: New test.
		* testsuite/gas/riscv/x-cv-simd-fail.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h: Add corresponding MATCH and MASK macros
		for XCVsimd.
		* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
		for XCVsimd.
		(enum riscv_insn_class): Add the XCVsimd instruction class.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Add custom operands.
		* riscv-opc.c: Add XCVsimd instructions.

2024-09-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-02  Haochen Jiang  <haochen.jiang@intel.com>

	Support ymm rounding control for Intel AVX10.2
	In the patch, in order to support ymm rounding for AVX10.2, we derive
	evex attribute for all cases instead of only for rc_none to encode U bit.
	Also changed some bad_opcode return due to the share of U bit with APX_F.

	gas/ChangeLog:

		* config/tc-i386.c
		(cpu_flags_match): Handle AVX10_2.
		(build_evex_prefix): Handle U bit. Derive evex attribute
		for all cases.
		(check_VecOperands): Handle AVX10.2 and ymm roundings.
		* doc/c-i386.texi: Document .avx10.2.
		* testsuite/gas/i386/i386.exp: Run AVX10.2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx10_2-rounding-intel.d: New test.
		* testsuite/gas/i386/avx10_2-rounding-inval.l: Ditto.
		* testsuite/gas/i386/avx10_2-rounding-inval.s: Ditto.
		* testsuite/gas/i386/avx10_2-rounding.d: Ditto.
		* testsuite/gas/i386/avx10_2-rounding.s: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Ditto.
		* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (struct instr_info): Add U bit.
		(get_valid_dis386): Handle U bit.
		* i386-gen.c (isa_dependencies): Add AVX10.2.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-opc.h (CpuAVX10_2): New.
		(i386_cpu_flags): Add cpuavx10_2.
		* i386-opc.tbl: Add rounding to old entries which do not
		permit rounding previously. Also eliminate the redundant
		RegXMM for vcvtps2uqq.
		* i386-tbl.h: Regenerated.

2024-09-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-09-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-31  H.J. Lu  <hjl.tools@gmail.com>

	x86: Fix comment typos in TLS relocation check
	R_386_TLS_IE is used only in

		movl foo@indntpoff, %eax
		movl foo@indntpoff, %reg
		addl foo@indntpoff, %reg

	R_386_TLS_DESC_CALL and R_X86_64_TLSDESC_CALL are used only in

		call *x@tlscall(%[er]ax)

		* elf32-i386.c (elf_i386_check_tls_transition): Use foo@indntpoff
		in comments for R_386_TLS_IE check.
		(elf_i386_tls_transition): Use @tlscall in comments for
		R_386_TLS_DESC_CALL check.
		* elf64-x86-64.c (elf_x86_64_tls_transition): Use @tlscall in
		comments for R_X86_64_TLSDESC_CALL check.

2024-08-31  H.J. Lu  <hjl.tools@gmail.com>

	gold: Always resolve non-default weak undefined to 0
	Non-default weak undefined symbols in executable and shared library are
	always resolved to 0 at runtime and don't need dynamic relocation.

	Tested on i686, x86-64, powerpc64le and aarch64.

		PR gold/32071
		* symtab.cc (Symbol::final_value_is_known): Always resolve
		non-default weak undefined symbol in executable and shared library
		to 0 at runtime.
		* symtab.h (Symbol::needs_dynamic_reloc): Return false for
		non-default weak undefined symbol in executable and shared library.
		* testsuite/Makefile.am: Add weak_undef_test_3 and
		weak_undef_test_4 tests.
		* testsuite/Makefile.in: Regenerated.
		* testsuite/weak_undef_lib_4.c: New file.
		* testsuite/weak_undef_test_3.c: Likewise.
		* testsuite/weak_undef_test_4.c: Likewise.

2024-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle unsupported catch syscall
	On riscv64-linux, I run into:
	...
	Expecting: ^(catch syscall[^M
	]+)?((&.*)*.*~"Catchpoint 5 .*\\n".*=breakpoint-created,bkpt=\{number="5",type="catchpoint".*\}.*\n\^done[^M
	]+[(]gdb[)] ^M
	[ ]*)
	catch syscall^M
	&"catch syscall\n"^M
	&"The feature 'catch syscall' is not supported on this architecture yet.\n"^M
	^error,msg="The feature 'catch syscall' is not supported on this architecture yet."^M
	(gdb) ^M
	FAIL: gdb.mi/mi-breakpoint-changed.exp: test_insert_delete_modify: catch syscall (unexpected output)
	...

	Fix this by:
	- factoring out proc supports_catch_syscall out of gdb.base/catch-syscall.exp,
	  and
	- using it in gdb.mi/mi-breakpoint-changed.exp.

	Tested on x86_64-linux and riscv64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-30  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove duplicate check in disable_breakpoints_in_freed_objfile
	I spotted that we have a duplicate condition check in the function
	disable_breakpoints_in_freed_objfile.

	Lets remove it.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf2: cleanup includes
	Cleanup includes in dwarf2/*.

	 1. Add the necessary includes so that clangd reports no errors when
	    opening header files.  This ensures that header files include what
	    they use.

	 2. Remove all includes reported as unused by clangd (except
	    gdb-safe-ctype.h, which I think does some magic that affects what
	    follows).

	Built-tested --enable-threading at "yes" and "no", since there are some
	portions of code gated by `#ifdef CXX_STD_THREAD`.

	Change-Id: I21debffcd7c2caf90f08e1e0fbba3ce30422d042
	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-30  Tom Tromey  <tromey@adacore.com>

	Minor formatting fix in breakpoint.c
	I noticed a spot in breakpoint.c that doesn't follow gdb's formatting
	rules: the return type is on the same line as the method name.

2024-08-30  Tom Tromey  <tromey@adacore.com>

	Fix regexp quoting in gdb.ada test cases
	I noticed that some gdb.ada tests used regular expressions like:

	         "Continuing\..*$inferior_exited_re.*" \

	Here, the "\." should either be "." or "\\." -- "\." is not really
	meaningful.

	This patch fixes all the cases of this I could find in gdb.ada.  In
	one test (fun_renaming.exp), using "\\." would result in failures, and
	here I rewrote the tests to use -wrap.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-30  H.J. Lu  <hjl.tools@gmail.com>

	x86: Check invalid TLS descriptor call
	TLS descriptor call,

	call *x@tlsdesc(%rax)

	or

	call *x@tlsdesc(%eax)

	calls _dl_tlsdesc_return which expects that RAX/EAX points to the TLS
	descriptor.  Update x86 linker to issue an error with or without TLS
	transition.

	bfd/

		PR ld/32123
		* elf32-i386.c (elf_i386_check_tls_transition): Move
		R_386_TLS_DESC_CALL to ...
		(elf_i386_tls_transition): Here.
		* elf64-x86-64.c (elf_x86_64_check_tls_transition): Move.
		R_X86_64_TLSDESC_CALL check to ...
		(elf_x86_64_tls_transition): Here.

	ld/

		PR ld/32123
		* testsuite/ld-i386/i386.exp: Run tlsgdesc3.
		* testsuite/ld-i386/tlsgdesc3.d: New file.
		* testsuite/ld-x86-64/tlsdesc5.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run tlsdesc5.

2024-08-30  Jan Beulich  <jbeulich@suse.com>

	x86: replace conditional operators used to calculate booleans
	The boolean expressions themselves are fine to use there.

	x86/APX: drop %SW disassembler macro again
	Not the least due to its extremely rare use I didn't really like that
	macro's introduction. Adjust swap_operand() accordingly instead.

2024-08-30  Jan Beulich  <jbeulich@suse.com>

	x86: limit RegRex64 use
	The special property really only applies to the "extended" byte regs
	having legacy word/dword counterparts.

	While touching involved code also drop redundant byte checks from a
	conditional in establish_rex(): The other remaining RegRex64 uses only
	exist on registers which can't be used as register operands anyway.
	Hence RegRex64 as an attribute of a (valid) register operand implies
	that it's a byte reg.

2024-08-30  Jan Beulich  <jbeulich@suse.com>

	gas: properly check for ELF in LISTING_NODEBUG handling
	While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h
	including obj-elf.h for obscure reasons), there still need to be IS_ELF
	checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code
	checking for ->debugging being true doesn't need such extra checks, as
	the field can only ever be true when IS_ELF.

	On the same basis reduce #ifdef-ary in debugging_pseudo().

	Also move the field (into what on 64-bit architectures is a 32-bit gap)
	and put it inside an OBJ_ELF conditional, too.

	While there further switch int to bool in related code.

2024-08-30  Jan Beulich  <jbeulich@suse.com>

	gas: generated code/data listing output vs .endr and alike
	These ending directives are swallowed by buffer_and_nest() and hence
	aren't seen by read_a_source_file(). Thus they also weren't announced to
	the listing subsystem. That was, when macro expansions are included,
	thus misguided to associate possible output resulting from the first
	line of the construct being expanded with both the .endr and that first
	line (i.e. showing it twice).

2024-08-30  Nicolás Ortega Froysa  <nicolas@ortegas.org>

	gdb/doc: fix typo in 'watch' command
	* gdb/breakpoint.c (watch_option_defs): Fix typo.

2024-08-30  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: LoongArch64 allows relocations to use 64-bit addends
	Relocations using 64-bit addends allow larger constant offset address
	calculations to be fused.

2024-08-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-29  Andrew Burgess  <aburgess@redhat.com>

	gdb: reject inserting breakpoints between functions
	When debugging ROCm code, you might have something like this:

	  __global__ void kernel ()
	  {
	    ...
	    // break here
	    ...
	  }

	  int main ()
	  {
	    // Code to call `kernel`
	  }

	... where kernel is a function compiled to execute on the GPU.  It does
	not exist in the host x86-64 program that runs the main function, and
	GDB doesn't know about that function until it is called, at which point
	the runtime loads the corresponding code object and GDB learns about the
	code of the "kernel" function.  Before the GPU code object is loaded,
	from the point of view of GDB, you might as well have blank lines
	instead of the "kernel" function.  The DWARF in the host program doesn't
	describe anything at these lines.

	So, a common problem that users face is:

	 - Start GDB with the host binary
	 - Place a breakpoint by line number at the "break here" line
	 - At this point, GDB only knows about the host code, the lines of the
	   `kernel` function are a big void.
	 - GDB finds no code mapped to the "break here" line and searches for
	   the first following line that has code mapped to it.
	 - GDB finds that the line with the opening bracket of the `main`
	   function (or around there) has code mapped to it, places breakpoint
	   there.
	 - User runs the program.
	 - The programs hits the breakpoint at the start of main.
	 - User is confused, because they didn't ask for a breakpoint in main.

	If they continue, the code object eventually gets loaded, GDB reads the
	debug info from it, re-evaluates the breakpoint locations, and at this
	point the breakpoint is placed at the expected location.

	The goal of this patch is to get rid of this annoyance.

	A case similar to the one shown above can actually be simulated without
	GPU-specific code: using a single source file to generate a library and
	an executable loading that library (see the new test
	gdb.linespec/line-breakpoint-outside-function.c for an example).  Before
	the library is loaded, trying to place a breakpoint in the library code
	results in the breakpoint "drifting" down to the main function.

	To address this problem, make it so that when a user requests a
	breakpoint outside a function, GDB makes a pending breakpoint, rather
	than placing a breakpoint at the next line with code, which happens to
	be in the next function.  When the GPU kernel or shared library gets
	loaded, the breakpoint resolves to a location in the kernel or library.

	Note that we still want breakpoints placed inside a function to
	"drift" down to the next line with code.  For example, here:

	   9
	  10 void foo()
	  11 {
	  12   int x;
	  13
	  14   x++;

	There is probably no code associated to lines 10, 12 and 13, but the
	user can still reasonably expect to be able to put a breakpoint there.
	In my experience, GCC maps the function prologue to the line with the
	opening curly bracket, so the user will be able to place a breakpoint
	there anyway (line 11 in the example).  But I don't really see a use
	case to put a breakpoint above line 10 and expect to get a breakpoint in
	foo.  So I think that is a reasonable behavior change for GDB.

	This is implemented using the following heuristic:

	 - If a breakpoint is requested at line L but there is no code mapped to
	   L, search for a following line with associated code (this already
	   exists today).
	 - However, if:

	     1. the found location falls in a function symbol's block
	     2. the found location's address is equal the entry PC of that
	        function
	     3. the found location's line is greater that the requested line

	   ... then we don't place a breakpoint at the found location, we will
	   end up with a pending breakpoint.

	Change the message "No line X in file..." to "No compiled code for line
	X in file...".  There is clearly a line 9 in the example above, so it
	would be weird to say "No line 9 in file...".  What we mean is that
	there is no code associated to line 9.

	All the regressions that I found this patch to cause were:

	 1. tests specifically this behavior where placing a breakpoint before
	    a function results in a breakpoint on that function, in which case I
	    removed the tests or changed them to expect a pending breakpoint
	 2. linespec tests expecting things like "break -line N garbage" to
	    error out because of the following garbage, but we now got a
	    different error because line N now doesn't resolve to something
	    anymore.  For example, before:

	      (gdb) break -line 3 if foofoofoo == 1
	      No symbol "foofoofoo" in current context.

	    became

	      (gdb) break -line 3 if foofoofoo == 1
	      No line 3 in the current file.

	    These tests were modified to refer to a valid line with code, so
	    that we can still test what we intended to test.

	Notes:

	 - The CUDA compiler "solves" this problem by adding dummy function
	   symbols between functions, that are never called.  So when you try to
	   insert a breakpoint in the not-yet-loaded kernel, the breakpoint
	   still drifts, but is placed on some dummy symbol.  For reasons that
	   would be too long to explain here, the ROCm compiler does not do
	   that, and it is not a desirable option.

	 - You can have constructs like this:

	   void host_function()
	   {
	     struct foo
	     {
	       static void __global__ kernel ()
	       {
	         // Place breakpoint here
	       }
	     };

	     // Host code that calls `kernel`
	   }

	   The heuristic won't work then, as the breakpoint will drift somewhere
	   inside the enclosing function, but won't be at the start of that
	   function.  So a bogus breakpoint location will be created on the host
	   side.  I don't think that people are going to use this kind of
	   construct often though, so we can probably ignore it (or at least it
	   shouldn't prevent making the more common case better).

	   ROCm doesn't support passing a lambda kernel function to
	   hipLaunchKernelGGL (the function used to launch kernels on the
	   device), but if it eventually does, there will be the same
	   problem.

	   I think that to properly support this, we will need some DWARF
	   improvements to be able to say "there is really nothing at these
	   lines" in the line table.

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6

2024-08-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: move NEWS entry to the correct place
	In commit:

	  commit 3055e3d2f13bb84db90b9c19d427c362053775d2
	  Date:   Tue May 21 15:58:02 2024 +0100

	      gdb: add GDB side target_ops::fileio_stat implementation

	I managed to place a NEWS entry in the wrong place.  I put the entry
	in 'Changes in GDB 15' rather than 'Changes since GDB 15'.  This
	commit moves the entry to the correct place.

2024-08-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: include gdbsupport/gdb_obstack.h in addrmap.h
	This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h.
	This fixes an error shown when editing addrmap.h with clangd, and makes
	it so addrmap.h includes what it uses.

	Change-Id: I0b0c8d26638e2150fcb65c601098ed9df5a8945a

2024-08-29  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused includes in linespec.c
	Remove some includes reported as unused by clangd.

	Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df

2024-08-29  Alan Modra  <amodra@gmail.com>

	get_type_abbrev_from_form tidy
		* dwarf.c (get_type_abbrev_from_form): Make uvalue param a
		uint64_t.  Localise variables.  Don't bother clearing *data_return
		and *addrev_num_return for a NULL return value.

2024-08-29  Alan Modra  <amodra@gmail.com>

	ld testsuite output files
	In many cases the output of one run_cc_link_tests test is used as
	input for another test.  I hit a case where some system change caused
	errors when compiling object files, but the old .so output from a
	previous test run was still there, and then was used in following
	tests.

		* testsuite/lib/ld-lib.exp (run_ld_link_tests): Delete output
		file before building.
		(run_ld_link_exec_tests, run_cc_link_tests): Likewise.

2024-08-29  Alan Modra  <amodra@gmail.com>

	PR32093, -Walloc-size warning in ctf-hash.c
		PR 32093
		* ctf-hash.c (ctf_dynhash_create_sized, ctf_hashtab_insert): Avoid
		-Walloc-size warning.

2024-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix another regexp in gdb.threads/stepi-over-clone.exp
	On openSUSE Tumbleweed, I run into:
	...
	(gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
	continue^M
	Continuing.^M
	^M
	Catchpoint 2 (call to syscall clone3), __clone3 () at clone3.S:62^M
	(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
	...

	Fix this by updating another (see commit 8fbf220321d) regexp to also recognize
	__clone3.

	Tested on x86_64-linux.

2024-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in gdb.arch/i386-disp-step-self-call.exp
	Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get:
	...
	(gdb) x/1wx 0xffffc4f8^M
	0xffffc4f8:     0x08048472^M
	(gdb) PASS: $exp: check return address was updated correctly
	...
	but sometimes I run into:
	...
	(gdb) x/1wx 0xffffc5c8^M
	0xffffc5c8:     0x0804917e^M
	(gdb) FAIL: $exp: check return address was updated correctly
	...

	The problem is that here:
	...
	set next_insn_addr 0x[format %08X $next_insn_addr]
	gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \
	    "check return address was updated correctly"
	...
	we're trying to match string 0x0804917e against regexp 0x0804917E due to using
	"%08X" as format string.

	We only run into this problem if the address contains letters, which apparently
	usually isn't the case.

	Fix this by using "%08x" instead as format string.

	Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp.

	Tested on x86_64-linux.

	PR testsuite/32121
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32121

2024-08-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-28  Tom Tromey  <tromey@adacore.com>

	Don't check dwarf2_name in process_enumeration_scope
	I noticed that process_enumeration_scope checks the result of
	dwarf2_name.  However, this isn't needed, because new_symbol does the
	same check.  This patch removes the unnecessary code.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-28  Jiaying Song  <jiaying.song.cn@windriver.com>

	dlltool: file name too long
	During the execution of the command: i686-w64-mingw32-dlltool
	--input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe
	An error occurred:
	i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s

	Due to the path length exceeding the Linux system's file name length
	limit (NAME_MAX=255), the temporary file name generated by the
	i686-w64-mingw32-dlltool command becomes too long to open. To address
	this, a new temporary file name prefix is generated using tmp_prefix =
	prefix_encode ("d", getpid()), ensuring that the file name does not
	exceed the system's length limit.

	Reviewed-by: Alan Modra <amodra@gmail.com>

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	x86: Report expected register for elf_x86_tls_error_indirect_call
	Since R_386_TLS_DESC_CALL can only be used with

		call	*variable@TLSCALL(%eax)

	and R_X86_64_TLSDESC_CALL can only be used with

		call	*variable@TLSCALL(%rax)

	update TLS transition error report to display the expected register in
	indirect CALL.

	bfd/

		PR ld/32017
		* elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize
		the ax_register field.
		(_bfd_x86_elf_link_report_tls_transition_error): Report the
		expected register in elf_x86_tls_error_indirect_call error.
		* elfxx-x86.h (elf_x86_link_hash_table): Add ax_register.

	ld/

		PR ld/32017
		* testsuite/ld-i386/tlsgdesc2.d: Updated.
		* testsuite/ld-i386/tlsgdesc2.s: Change jmp to call via ECX.
		* testsuite/ld-x86-64/tlsdesc4.d: Updated.
		* testsuite/ld-x86-64/tlsdesc4.s: Change jmp to call via RCX.

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	gold: Force a PC-relative reference to .LC0
	Force a PC-relative reference to .LC0 with:

	__asm__ (".dc.a .LC0 - .");

	for all targets.

	Tested on x86, powerpc64le and aarch64.

		* testsuite/discard_locals_relocatable_test.c: Force a PC-relative
		reference to .LC0.

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	gold: Disable &no_such_symbol_ != NULL check when GOT in use
	Since this test:

	  if (&no_such_symbol_ != NULL)
	    {
	      fprintf(stderr, "FAILED weak undef test 4: %s\n",
	              "&no_such_symbol_ is not NULL");
	      status = 1;
	    }

	always fails when GOT is used and aarch64 always uses GOT, disable it
	for aarch64 and PIC.

		PR gold/32112
		* testsuite/weak_undef_test.cc (main): Disable the
		&no_such_symbol_ != NULL check for aarch64 and PIC.

2024-08-28  Alan Modra  <amodra@gmail.com>

	dlltool.c formatting
	Mostly whitespace fixes, some removal of excess parens.

	Re: x86: Allow R_386_TLS_LE_32 with KMOVD
	Adjust the new test to pass on i686-pc-elf where it failed due to not
	matching the _start address.

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	gold: Use asm for GCC 9 and older in PR gold/31830 tests
	Since GCC 9 and older fail to compile PR gold/31830 tests:

	$ gcc -S testsuite/ver_test_pr31830_b.c -o /tmp/x.s
	testsuite/ver_test_pr31830_b.c:3:1: warning: ‘__symver__’ attribute directive ignored [-Wattributes]
	 void __collector_foo_2_2(void) {}
	 ^~~~

	use asm statement, instead of symver attribute, for GCC 9 and older.

		PR gold/31830
		* testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm
		statement, instead of symver attribute, for GCC 9 and older.
		symver attribute with __asm__.
		* testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise.

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	gold: Remove duplicated rules for ifuncmain[12457]picstatic
	When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports:

	Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic'
	Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic'
	Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic'
	Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic'
	Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic'
	Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic'
	Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic'
	Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic'
	Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic'
	Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic'

	due to duplicated rules for ifuncmain[12457]picstatic:

	@GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@GCC_TRUE@@HAVE_STATIC_TRUE@@IFUNC_STATIC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld

	Make rules for ifuncmain[12457]picstatic independent of HAVE_STATIC and
	IFUNC_STATIC:

	@GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
	@GCC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld

		PR gold/32116
		* testsuite/Makefile.am (ifuncmain1picstatic): Make it independent
		of HAVE_STATIC and IFUNC_STATIC.
		(ifuncmain2picstatic): Likewise.
		(ifuncmain4picstatic): Likewise.
		(ifuncmain5picstatic): Likewise.
		(ifuncmain7picstatic): Likewise.
		* testsuite/Makefile.in: Regenerated.

2024-08-28  H.J. Lu  <hjl.tools@gmail.com>

	x86: Report invalid TLS operator
	Report invalid TLS operator, instead of relocation.

		PR gas/28595
		* config/tc-i386.c (gotrel): Replace int with unsigned int.
		(i386_assemble): Report invalid TLS operator.
		* testsuite/gas/i386/inval-tls.l: updated.
		* testsuite/gas/i386/x86-64-inval-tls.l: Likewise.

2024-08-28  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix gdb.btrace/non-stop.exp end of history check
	The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the
	warnings when GDB reaches the end of the recorded history, and updated
	tests to expect the new messages. The pattern used for
	gdb.btrace/non-stop.exp, however, was too broad and could cause the
	following test result:

	    ...
	    (gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt
	    ^M
	    Reached end of recorded history; stopping.^M
	    Following forward execution will be added to history.^M
	    test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
	    30        return arg; /* bp.2 */^M
	    ^M
	    Reached end of recorded history; stopping.^M
	    Following forward execution will be added to history.^M
	    test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
	    30        return arg; /* bp.2 */^M
	    PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0
	    FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout)
	    ...

	This happens because the pattern looks like one of these 2:
	    "Reached end of recorded.*Backwards execution.*"
	    "Reached end of recorded.*Following forward.*"

	What seems to have happened is that all the output came at once, and
	most of it was consumed by the first '.*' pattern when checking for
	thread 0, so there was no output left for checking thread 1. This commit
	fixes that by making the expected outputs more exact.

	I also fixed the whitespace errors in gdb_cont_to_no_history_backwards
	that pre-dated the commit above, since I was already touching that proc.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-08-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add no-delete-breakpoints option to 'runto' proc
	New 'no-delete-breakpoints' option for the 'runto' proc.  This option
	disables the delete_breakpoints call early on in this proc.

	There are a couple of places in the testsuite where I have used:

	  proc no_delete_breakpoints {} {}

	  with_override delete_breakpoints no_delete_breakpoints {
	    if {![runto_main]} {
	      return
	    }
	 }

	In order to avoid the deleting all breakpoints when I call
	runto_main.  I was about to add yet another instance of this pattern
	and I figured that it's time to do this properly.

	This commit adds the new option to 'runto' which causes the
	delete_breakpoints call to be skipped.

	And, we now forward any arguments from 'runto_main' through to
	'runto', this means I can now just do:

	  if {![runto_main no-delete-breakpoints]} {
	    return
	  }

	which I think is cleaner and easier to understand.

	I've updated the two tests I found that use the old with_override
	approach.

	There should be no change in what is tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: add 'maint info blocks' command
	While reviewing a patch I wanted to understand which blocks existed at
	a given address.

	The 'maint print symbols' command does provide some of this
	information, but that command displays all blocks within a given
	symtab.  If I want to know which blocks are at a given address I have
	to figure that out for myself based on the output of 'maint print
	symbols' ... and I'm too lazy for that!

	So this command lists just those blocks at a given address, along with
	information about the blocks type.  This new command doesn't list the
	symbols within each block, for that my expectation is that you'd cross
	reference the output with that of 'maint print symbols'.

	The new command format is:

	  maintenance info blocks
	  maintenance info blocks ADDRESS

	This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is
	not given.  Blocks are listed starting at the global block, then the
	static block, and then the progressively narrower scoped blocks.

	For each block we list the internal block pointer (which allows easy
	cross referencing with 'maint print symbols'), the inferior address
	range, along with other useful information.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: Add 'maint info inline-frames' command
	While reviewing a patch I wanted to view GDB's inline frame state.  I
	don't believe there's currently a maintenance command to view this
	information, so in this commit I've added one.

	The new command is:

	  maintenance info inline-frames
	  maintenance info inline-frames ADDRESS

	The command lists the inline frames that start at ADDRESS, or at the
	current $pc if no ADDRESS is given.  The command also displays the
	"outer" function in which the inline functions are present.

	An example of the command output:

	  (gdb) maintenance info inline-frames
	  Cached inline state information for thread 1.
	  program counter = 0x401137
	  skipped frames = 1
	    bar
	  > foo
	    main
	  (gdb)

	This tells us that function 'main' called 'foo' which called 'bar'.
	The functions 'foo' and 'bar' are both inline and both start at the
	address 0x401137.  Currently GDB considers the inferior to be stopped
	in frame 'foo' (note the '>' marker), this means that there is 1
	skipped frame (function 'bar').

	The function 'main' is the outer function.  The outer function might
	not start at 0x401137, it is simply the function that contains the
	inline functions.

	If the user does a 'step' then GDB will not actually move the inferior
	forward, but will instead simply tell the user that the inferior
	entered 'bar'.  The output of 'maint info inline-frames' will change
	like this:

	  (gdb) step
	  bar () at inline.c:6
	  6	  ++global_counter;
	  (gdb) maintenance info inline-frames
	  Cached inline state information for thread 1.
	  program counter = 0x401137
	  skipped frames = 0
	  > bar
	    foo
	    main
	  (gdb)

	Now GDB is in function 'bar' and there are no skipped frames.

	I have renamed skipped_symbols to function symbols within the
	inline_state class.  We are now going to carry the "outer"
	function (the function that contains all the inlined functions) within
	this list (as the last entry), so the old name didn't really make
	sense.  As a consequence of this rename I've updated some comments.

	I've changed stopped_by_user_bp_inline_frame to take a symbol rather
	than a block.  Previously we just used the block to access the
	associated function symbol.  After this commit we can just pass in the
	function symbol directly, so lets do that.

	New function gather_inline_frames contains some of the logic pulled
	from skip_inline_frames.  This new function builds the list of all
	symbols of inlined functions that start at a given $pc value and also
	the "outer" function that contains all of the inlined functions.

	In skip_inline_frames I've split the loop logic into two.  The loop to
	build the function symbol list has moved to gather_inline_frames.  The
	loop to figure out how many of the inlined functions we are skipping
	remains in skip_inline_frames and uses the result of calling
	gather_inline_frames.

	In inline_skipped_symbol there are some minor updates to the comment,
	and I've tweaked one of the asserts now that the function symbols list
	also contains the "outer" function (a <= becomes <).

	The maintenance_info_inline_frames function is now and implements the
	new maintenance command.

	And _initialize_inline_frame is updated to register the new command.

	I've added a basic test for the new command.  Please excuse the file
	name for the new test, in the next commit I'll be adding additional
	tests and at that point the file name will make sense.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: make symbols const in struct inline_state
	Make the inline_state::skipped_symbols a vector of 'const symbol *',
	adding the const qualifier.

	There's only a couple of places this leaks into the rest of GDB and in
	both places its fine for the symbol to become const.

	There should be no functional change after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-28  Andrew Burgess  <aburgess@redhat.com>

	Revert "gdb: remove inline_frame::skipped_frames"
	This reverts commit 713e89012e43c83a6c1bb957c43ff58e5433336c.

	Having inline_state::skipped_frames back will make a later patch in
	this series easier.

2024-08-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-27  H.J. Lu  <hjl.tools@gmail.com>

	x86: Report invalid TLS relocation name
	Get TLS relocation name from its lex_got entry when reporting invalid
	instructions with TLS relocations.

		PR gas/28595
		* config/tc-i386.c (gotrel): Moved from ...
		(lex_got): There.
		(i386_assemble): Get invalid TLS relocation name from its lex_got
		entry when reporting TLS relocation error.

2024-08-27  H.J. Lu  <hjl.tools@gmail.com>

	x86: Allow R_386_TLS_LE_32 with KMOVD
	Since there is no TLS IE transition, allow R_386_TLS_LE_32 with KMOVD.

	gas/

		PR gas/28595
		* config/tc-i386.c (i386_assemble): Remove BFD_RELOC_386_TLS_LE_32
		from TLS code check.
		* testsuite/gas/i386/inval-tls.s: Remove foo@tpoff(%eax).
		* testsuite/gas/i386/inval-tls.l: Updated.

	ld/

		PR gas/28595
		* testsuite/ld-i386/i386.exp: Run tlsle1.
		* testsuite/ld-i386/tlsle1.d: New file.
		* testsuite/ld-i386/tlsle1.s: Likewise.

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.exp
	In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to
	DWARF Error") I changed the dwarf error prefix, but failed to update test-case
	gdb.dwarf2/dw2-inter-cu-error.exp.

	Fix this by updating the corresponding regexp in the test-case.

	Tested on x86_64-linux.

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often
	I found a few more places where we can use GDB_PY_SET_HANDLE_EXCEPTION.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often
	I found a few more places where we can use GDB_PY_HANDLE_EXCEPTION.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error
	It was suggested here [1] that the canonical prefix for dwarf errors
	should not be "Dwarf Error: ", given that the canonical spelling is DWARF
	instead of Dwarf.

	Fix this by using "DWARF Error: " instead.

	Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single
	location.

	Tested on x86_64-linux.

	Suggested-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Use DWARF_ERROR_PREFIX
	Result of:
	...
	$ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/*
	...
	and manually fixing indentation.

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Add gdb/dwarf2/error.h
	Add a new header file gdb/dwarf2/error.h, containing macros:
	- DWARF_ERROR, and
	- DWARF_ERROR_PREFIX.

	The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch.

	No functional changes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-27  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Use [in module %s] notation more consistently in dwarf errors
	In gdb/dwarf2/read.c, I found a few strings "in module %s":
	...
	$ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '['
			     "DIE at %s in module %s"),
	      error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
	    error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
		error (_("Dwarf Error: DIE at %s referenced in module %s "
	      error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
	    error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
	...
	that are not using the commonly used "[in module %s]" notation.  Fix these.

	In one case, the string was also used in the middle rather than at the end of
	the message, so fix that as well.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-27  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions.
	This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'.
	All disassemble instructions use the sreg format.

	Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
	Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
	Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
	Co-Authored by: Simon Cook <simon.cook@embecosm.com>
	Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
	Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>

	gas/ChangeLog:
		PR 32036
		* NEWS: Updated.
	        * config/tc-riscv.c (validate_riscv_insn): New operators.
	        (riscv_ip): Ditto.
	        * testsuite/gas/riscv/zcmp-mv.d: New test.
	        * testsuite/gas/riscv/zcmp-mv.s: New test.

	include/ChangeLog:
		PR 32036
	        * opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode.
	        (MASK_CM_MVA01S): New mask.
	        (MATCH_CM_MVSA01): New opcode.
	        (MASK_CM_MVSA01): New mask.
	        (DECLARE_INSN): New declarations.
	        * opcode/riscv.h (OP_MASK_SREG1): New mask.
	        (OP_SH_SREG1): New operand code.
	        (OP_MASK_SREG2): New mask.
	        (OP_SH_SREG2): New operand code.
	        (X_A0): New reg number.
	        (X_A1): Ditto.
	        (X_S7): Ditto.
	        (RISCV_SREG_0_7): New macro function.

	opcodes/ChangeLog:
		PR 32036
	        * riscv-dis.c (riscv_zcmp_get_sregno): New function.
	        (print_insn_args): New operators.
	        * riscv-opc.c (match_sreg1_not_eq_sreg2): New match function.

2024-08-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Disable gprofng build for *musl*
	I disable gprofng until gprofng is ported to musl.

	gprofng/ChangeLog
	2024-08-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		PR gprofng/30779
		PR gprofng/29593
		PR gprofng/29477
		* configure.ac: Disable gprofng build for *musl*.
		* configure: Rebuild.

2024-08-26  Tom Tromey  <tromey@adacore.com>

	Simplify ada_identical_enum_types_p
	This patch changes ada_identical_enum_types_p to reuse the field names
	that are computed earlier in the loop.  This is a simple cleanup, but
	also is useful for a larger change that I'm working on.

	Tested on x86-64 Fedora 38.

2024-08-26  Mark Harmstone  <mark@harmstone.com>

	ld/PDB: handle pointers to members
	If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an
	LF_POINTER entry's attributes, there's a few extra bytes on the end that
	we weren't accounting for.

	Change handle_type so that we remap the containing_class field if it's
	present, and add a test for this.

2024-08-26  William Ferreira  <wqferr@gmail.com>

	gdb: imply --once if connecting via stdio
	Currently, gdbserver hangs after stdin is closed while it tries to
	write: "Remote side has terminated connection.  GDBserver will reopen
	the connection." This hang disappears if --once is also given. Since
	the stdin connection won't ever reopen if it's closed, it's safe to
	assume --once is desired.

	The gdb.server/server-pipe.exp test was also updated to reflect this
	change. There is now a second disconnect at the end of the proc,
	with a tighter-than-normal timeout to catch if the command hangs as
	it used to.

	Co-Authored-By: Guinevere Larsen <blarsen@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-26  Guinevere Larsen  <blarsen@redhat.com>

	Change message when reaching end of reverse history.
	In a record session, when we move backward, GDB switches from normal
	execution to simulation. Moving forward again, the emulation continues
	until the end of the reverse history. When the end is reached, the
	execution stops, and a warning message is shown. This message has been
	modified to indicate that the forward emulation has reached the end, but
	the execution can continue as normal, and the recording will also continue.

	Before this patch, the warning message shown in that case was the same as
	in the reverse case. This meant that when the end of history was reached in
	either backward or forward emulation, the same message was displayed:

	"No more reverse-execution history."

	This message has changed for these two cases. Backward emulation:

	"Reached end of recorded history; stopping.
	Backward execution from here not possible."

	Forward emulation:

	"Reached end of recorded history; stopping.
	Following forward execution will be added to history."

	The reason for this change is that the initial message was deceiving, for
	the forward case, making the user believe that forward debugging could not
	continue.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224
	Reviewed-By: Markus T. Metzger <markus.t.metzger@intel.com> (btrace)
	Approved-By: Guinevere Larsen <blarsen@redhat.com>

2024-08-26  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE
	If the symbol defined by PROVIDE in the link script is not in SECTION,
	the symbol is placed in the ABS section. The linker considers that
	symbols in the ABS section do not need to calculate PC relative offsets.

	Symbols in ABS sections should calculate PC relative offsets normally
	based on relocations.

2024-08-26  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb, btrace: Fix clang build
	Simon pointed out to me that there are some failures when building with clang,
	that were caused by my commit

	commit d894edfcc40e63be9b6efa0950c1752f249f16e5
	Author: Felix Willgerodt <felix.willgerodt@intel.com>
	Date:   Mon Feb 18 13:49:25 2019 +0100

	    btrace: Introduce auxiliary instructions.

	The errors are:

	  CXX    btrace.o
	gdb/btrace.c:1203:11: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
	 1203 |   return {(CORE_ADDR) insn.ip, (gdb_byte) insn.size,
	      |           ^~~~~~~~~~~~~~~~~~~
	      |           {                  }
	gdb/btrace.c:1218:21: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
	 1218 |   btrace_insn insn {btinfo->aux_data.size () - 1, 0,
	      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
	      |                     {                           }
	gdb/btrace.c:1323:34: error: variable 'bfun' is uninitialized when used here [-Werror,-Wuninitialized]
	 1323 |             handle_pt_aux_insn (btinfo, bfun, *ptw_string, pc);
	      |                                         ^~~~
	gdb/btrace.c:1236:35: note: initialize the variable 'bfun' to silence this warning
	 1236 |       struct btrace_function *bfun;
	      |                                   ^
	      |                                    = nullptr
	3 errors generated.
	make[1]: *** [Makefile:1961: btrace.o] Error 1

	This fixes those errors and switches two casts to C++ casts while we
	are at it.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-26  Alan Modra  <amodra@gmail.com>

	PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt
	Since bfd_section for .strtab isn't set, print the section index
	instead.  Also, don't return NULL on this error as that results in
	multiple mmap/read of the string table.  (We could return NULL if we
	arranged to set sh_size zero first, but just what we do with fuzzed
	object files is of no concern, and terminating the table might make a
	faulty object file usable.)

		PR 32109
		* elf.c (bfd_elf_get_str_section): Remove outdated comment, and
		tweak shstrtabsize test to suit.  Don't use string tab bfd_section
		in error message, use index instead.  Don't return NULL on
		unterminated string section, terminate it.
		(_bfd_elf_get_dynamic_symbols): Similarly terminate string table
		section.

2024-08-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-25  Dmitry Neverov  <dmitry.neverov@jetbrains.com>

	Recognize -2 as a tombstone value in .debug_line
	Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone
	value -1 used by lld (https://reviews.llvm.org/D81784).  The
	referenced lld commit also uses the tombstone value -2 for
	pre-DWARF-v5
	(https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7).

	If not handled, -2 breaks the pc step range calculation and triggers
	the assertion:

	  gdb/infrun.c:2794: internal-error: resume_1: Assertion
	  `pc_in_thread_step_range (pc, tp)' failed.

	This commit adds -2 tombstone value and handles it in the same way as -1.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727
	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-23  Aaron Merey  <amerey@redhat.com>
	    Tom de Vries  <tdevries@suse.de>

	gdb/dwarf2: Check for null abbrev_info ptr
	A corrupt debuginfo file can result in a null abbrev_info pointer
	being passed to cooked_indexer::scan_attributes.  This pointer
	is set to nullptr by peek_die_abbrev when an abbrev of 0 is found.

	There is no check for whether the abbrev pointer is null and
	SIGSEGV occurs when attempting to dereference the pointer.

	An abbrev of 0 normally indicates that the corresponding DIE is a
	null entry, but scan_attributes expects a non-null DIE.

	Fix this by throwing an error in cooked_indexer::scan_attributes
	when peek_die_abbrev returns a nullptr in order to avoid
	scan_attributes calling itself with a null abbrev.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478
	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-23  Jan Beulich  <jbeulich@suse.com>

	x86: simplify SAE checking
	To determine whether SAE (with or without StaticRounding) is permitted
	there's no need to iterate over all operands. Even less so starting at
	the front (thus needlessly inspecting immediate operands as well).
	Leverage the pattern across all relevant templates and check only the
	last two operands, and also only for non-512 ones (besides the non-LIG
	case that was already checked for).

	gas: update lex_type[] also for .mri directives
	Doing this just from read_begin(), i.e. merely based on command line
	options, can't be sufficient (assuming it's really relevant).

2024-08-23  Jan Beulich  <jbeulich@suse.com>

	RISC-V: process rs_align_code also when relaxing
	riscv_handle_align() runs after all input was processed. Whether
	relaxation is enabled for any particular piece of code is not recorded
	anywhere. (This issue was even "worked around" in a gas testcase, which
	is adjusted accordingly.) Furthermore, as demonstrated by an ld
	testcase, tail padding in an object file's executable sections depended
	on whether relaxation was enabled at the end of assembly: NOPs were
	emitted only when relaxation was off; zeroes were emitted with
	relaxation enabled. (It could probably be either way, but it should be
	independent of relaxation state at the end of assembly. Except of course
	write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(),
	explicitly says "proper nop-filling".)

	While re-indenting, drop the "odd_padding" variable. It's used exactly
	once, and having the actual expression right in the if() is imo helping
	readers to understand what the intentions are.

	While touching the ld testcase, also tighten the expectations for the
	addresses of the two symbols: The last two digits have to have fixed
	values.

2024-08-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-22  H.J. Lu  <hjl.tools@gmail.com>

	lto: Add a test for PR ld/32083
	Add a test for PR ld/32083 and xfail the test for GCC without the fix:

	commit a98dd536b1017c2b814a3465206c6c01b2890998
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Wed Aug 21 07:25:25 2024 -0700

	    Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

		PR ld/32083
		* testsuite/ld-plugin/common-2a.c: New file.
		* testsuite/ld-plugin/common-2b.c: Likewise.
		* testsuite/ld-plugin/lto.exp: Run PR ld/32083 test.

2024-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists
	With the test-case included in this patch, we run into:
	...
	$ gdb -q -batch $exec
	Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
	  [in module $exec]
	...

	The debug info consists of two CUs:
	...
	  Compilation Unit @ offset 0xb2:
	   Length:        0x25 (32-bit)
	   Version:       4
	   Abbrev Offset: 0x6c
	   Pointer Size:  8
	 <0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
	    <be>   DW_AT_language    : 2	(non-ANSI C)
	 <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
	    <c0>   DW_AT_low_pc      : 0x4004a7
	    <c8>   DW_AT_high_pc     : 0x4004b2
	    <d0>   DW_AT_specification: <0xe8>
	 <1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
	    <d5>   DW_AT_name        : main
	 <1><da>: Abbrev Number: 0
	  Compilation Unit @ offset 0xdb:
	   Length:        0xf (32-bit)
	   Version:       4
	   Abbrev Offset: 0x86
	   Pointer Size:  8
	 <0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
	    <e7>   DW_AT_language    : 2	(non-ANSI C)
	 <1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
	    <e9>   DW_AT_specification: <0xd4>
	 <1><ed>: Abbrev Number: 0
	...
	where:
	- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
	- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
	- DIE 0xd4 back in CU@0xb2.

	The dwarf error is caused by this bit of code in
	cooked_indexer::ensure_cu_exists:
	...
	  if (per_cu == m_per_cu)
	    return reader;
	...

	The dwarf error happens as follows:
	- a cutu_reader A is created for CU@0xb2
	- using cutu_reader A, the cooked index reader starts indexing dies, with
	  m_per_cu set to CU@0xb2
	- while indexing it scans the attributes of DIE 0xbf and encounters the
	  inter-CU reference to DIE 0xe8
	- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
	  CU@0xdb and returns it
	- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
	  encounters the inter-CU reference to DIE 0xd4
	- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
	  and cutu_reader B is returned
	- using cutu_reader B, it continues scanning attributes of DIE 0xd4
	- this goes wrong because:
	  - the attributes of the DIE are encoded using the abbreviation table at
	    offset 0x6c, while
	  - the decoding is done using cutu_reader B which uses the abbreviation table
	    at offset 0x86.

	Fix this by removing the problematic if clause.

	Since cutu_reader A is not preserved in m_index_storage,
	cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
	cutu_reader C for CU@0xb2.  Fix this in process_psymtab_comp_unit by preserving
	the cutu_reader A as well in m_index_storage.

	Tested on x86_64-linux and aarch64-linux.

	PR symtab/32081
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081

	Approved-By: Tom Tromey <tom@tromey.com>
	Reported-By: Andreas Schwab <schwab@linux-m68k.org>

2024-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Add const to catch gdb_exception
	I did a review of lines containing "catch (gdb_exception" and found a few
	where we can add const.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Eliminate catch(...) in type_to_type_object
	In type_to_type_object we have:
	...
	  try
	    {
	      if (type->is_stub ())
		type = check_typedef (type);
	    }
	  catch (...)
	    {
	      /* Just ignore failures in check_typedef.  */
	    }
	...

	The catch is supposed to ignore gdb_exception_error, but it ignores any
	exception.

	Fix that by only ignoring gdb_exception_error, and handling
	gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Add & in catch in svr4_handle_solib_event
	In svr4_handle_solib_event I noticed:
	...
		catch (const gdb_exception_error)
	...

	This seems to be the only place were we do this, elsewhere we have:
	...
		catch (const gdb_exception_error &)
	...

	I suppose the intent of adding '&' is to avoid a copy.  I'm not sure if it's
	necessary given that it's an unnamed const parameter, but I suppose it can't
	hurt either.

	Add the '&' here as well.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb] Eliminate catch(...) in get_test_insn
	In get_test_insn in gdb/disasm-selftests.c, we find this code:
	...
	            try
	              {
	                kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
	                insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
	              }
	            catch (...)
	              {
	                continue;
	              }
	...

	The catch is there to catch memory errors, but it swallows all exceptions, including
	gdb_exception_quit and gdb_exception_forced_quit.

	Fix this by limiting the catch to gdb_exception_error.

	Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-22  Sam James  <sam@gentoo.org>

	gprofng: testsuite: fix 'wrapper' typo
	gprofng/ChangeLog
	            * testsuite/config/default.exp: Fix 'wrapper' typo.

2024-08-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: some global_block improvements
	Some refactors around struct global_block, all in one patch because they
	all tie in together and are relatively trivial.

	 - Make block::global_block() and blockvector::global_block() return
	   `global_block *`, instead of `block *`.  There is no cost in doing
	   so, and it's a bit more precise.  Callers of these methods that need
	   a `global_block *` won't need to cast themselves.

	 - Add some block::as_global_block methods, as a way to get a
	   `global_block *` from a `block *` when you know it's a global block.
	   This is basically a static cast with an assert.

	 - Move set_compunit_symtab to global_block, since it requires the
	   block to be a global block anyway.  Rename to just `set_compunit` (I
	   think that compunit_symtab should just be renamed compunit...).

	 - Move the get_block_compunit_symtab free function to be a method of
	   global_block.

	 - Make global_block::compunit_symtab private and rename.

	 - Simplify initialize_block_iterator.

	Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d
	Approved-By: Tom Tromey <tom@tromey.com>

2024-08-21  Tom Tromey  <tromey@adacore.com>

	Do not assume ELF in dwarf2/read.c
	dwarf2/read.c has this code:

	  else if (elf_section_data (sectp)->this_hdr.sh_size
		   > bfd_get_file_size (abfd))

	This assumes that the BFD is an ELF, which is an invalid assumption.
	A user noticed that this can sometimes cause a crash.

	This patch fixes the problem by changing this code to use
	bfd_section_size_insane.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104
	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-20  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: track nested caching proc calls
	It was pointed out in this email:

	  https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com

	that this commit:

	  commit 0726729d344fecf98f8d138e688e77201cc3cece
	  Date:   Mon Jun 3 13:56:54 2024 +0100

	      gdb/testsuite: track if a caching proc calls gdb_exit or not

	had broken some AArch64 tests.

	What is going on is that there are two caching procs:

	  allow_aarch64_sme_tests
	  aarch64_initialize_sme_information

	the allow_aarch64_sme_tests proc makes a call to
	aarch64_initialize_sme_information, but
	aarch64_initialize_sme_information is also called from other
	non-caching procs, like aarch64_supports_sme_svl.

	Both of the caching procs mentioned above compile and run a helper
	program, and both of them call gdb_exit.

	After the above commit, the first call to any caching proc, the body
	of which calls gdb_exit, will result in a gdb_exit call even if the
	body is not executed and the result is fetched from the cache.

	What was observed is that in the first test script
	allow_aarch64_sme_tests is called, the body of this caching proc is
	run which calls gdb_exit.  Then allow_aarch64_sme_tests calls
	aarch64_initialize_sme_information, the body of which is run and
	gdb_exit is called again.  The results from both procs are added to
	the cache.

	In the next test script allow_aarch64_sme_tests is called.  This
	results in a cache hit, but gdb_exit is also called as this is the
	first call in this second test script.

	Later in the test script aarch64_supports_sme_svl is called which
	calls aarch64_initialize_sme_information.  As this is the first call
	to aarch64_initialize_sme_information in this second test
	script (remember the body of allow_aarch64_sme_tests was never run)
	then gdb_exit is called.  This call to gdb_exit is new after the above
	commit and is unexpected.

	I think the idea behind the above commit is still sound.  If the call
	to allow_aarch64_sme_tests was removed from the second test script
	then we would want the extra gdb_exit call as this would expose a real
	bug in the test.  The problem is that after the above commit the
	nested nature of the caching proc calls becomes important: a call to
	allow_aarch64_sme_tests should mean that we've also called
	aarch64_initialize_sme_information, and that relationship isn't
	currently captured.

	So in this commit I'm adding another field to the global
	gdb_data_cache (in lib/cache.exp).  This new field is 'also_called'.
	For every caching proc we populate this field with a list of names,
	these are the names of any nested caching procs that are called when
	the body of a caching proc is executed.

	Now when we get a cache hit in gdb_data_cache we mark every proc in
	the 'also_called' list as having been called.  This means that further
	calls to these procs will no longer trigger a gdb_exit call.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-08-20  Tom Tromey  <tromey@adacore.com>

	Fix Windows regression
	commit cb9f919f ("gdb: add program_space parameter to
	lookup_minimal_symbol_text") caused a crash on Windows.  In this
	function, section can be nullptr, but it is unconditionally
	dereferenced by the change introduced by the patch.

	I tested this using the AdaCore internal test suite.

	v2: always use current_program_space, reverting to be behavior before
	cb9f919f.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-20  Tom Tromey  <tromey@adacore.com>

	Use SEARCH_FUNCTION_DOMAIN when looking for Ada exception symbols
	While working on another bug, I noticed that the Ada code to find
	exception symbols uses SEARCH_VFT.  This will find variables and types
	-- but only functions are needed here.  This patch changes the code to
	use SEARCH_FUNCTION_DOMAIN.

	Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo
	installed, to ensure the exception-related tests work.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13
	When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into:
	...
	Expecting: ^(-pycmd exp[^M
	]+)?(.*&"Traceback \(most recent call last\):.."^M
	&"[^^M
	]+py-mi-cmd.py[^^M
	]+"^M
	&"[^^M
	]+raise gdb.GdbError\(\).."^M
	&"gdb.GdbError.."^M
	\^error,msg="Error occurred in Python\."[^M
	]+[(]gdb[)] ^M
	[ ]*)
	-pycmd exp^M
	&"Traceback (most recent call last):\n"^M
	&"  File \"py-mi-cmd.py\", line 76, in invoke\n    raise gdb.GdbError()\n"^M
	&"gdb.GdbError\n"^M
	^error,msg="Error occurred in Python."^M
	(gdb) ^M
	FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output)
	...

	In contrast, with python 3.12 I have:
	...
	Expecting: ^(-pycmd exp[^M
	]+)?(.*&"Traceback \(most recent call last\):.."^M
	&"[^^M
	]+py-mi-cmd.py[^^M
	]+"^M
	&"[^^M
	]+raise gdb.GdbError\(\).."^M
	&"gdb.GdbError.."^M
	\^error,msg="Error occurred in Python\."[^M
	]+[(]gdb[)] ^M
	[ ]*)
	-pycmd exp^M
	&"Traceback (most recent call last):\n"^M
	&"  File \"py-mi-cmd.py\", line 76, in invoke\n"^M
	&"    raise gdb.GdbError()\n"^M
	&"gdb.GdbError\n"^M
	^error,msg="Error occurred in Python."^M
	(gdb) ^M
	PASS: gdb.python/py-mi-cmd.exp: -pycmd exp
	...

	To make it easier to understand what we're looking at, let's take this out of
	the mi interpreter context and use the cli interpreter:
	...
	$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
	+set python print-stack full
	+source py-mi-cmd.py
	+python pycmd1('-pycmd')
	+python pycmd1.invoke (pycmd1, ["exp"])
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	  File "py-mi-cmd.py", line 76, in invoke
	    raise gdb.GdbError()
	gdb.GdbError
	gdb.in:4: Error in sourced command file:
	Error occurred in Python.
	...

	Interestingly, this is what we're seeing with both python 3.12 and 3.13.

	The difference between the python versions is that:
	- with python 3.12 each line is printed by itself, and
	- with python 3.13 two particular lines are printed toghether.

	With the cli interpreter, that makes no difference, because the '\n' is
	interpreted.

	But with the mi interpreter, that causes a difference in output because the
	'\n' is not interpreted, but rather printed literally.

	Fix this by accepting the new output in addition to the old one.

	Tested on aarch64-linux.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

	PR testsuite/31913
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913

2024-08-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add hardware counters for Appliedmicro processor
	gprofng/ChangeLog
	2024-08-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		* common/hwc_cpus.h: New constant for Appliedmicro processor.
		* common/hwctable.c: Add the hwc table for Appliedmicro processor.
		* src/hhwc_arm64_amcc.h: New file.
		* src/collctrl.cc (read_int): Use strtol instead of atoi.

2024-08-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: ginsn: x86: pacify Wmaybe-uininitialized compiler warning
	Fix PR binutils/32091

	After commit d56083b5047b8e7cc9eda2f867bd2b75724920a1, some gcc versions
	may warn about unintialized usage of ginsn_func.  Albeit false positive,
	adapt the code to escape the warning.

	gas/config/
		* tc-i386-ginsn.c (x86_ginsn_indirect_branch): Early exit if
		unexpected args.

2024-08-19  Andreas Schwab  <schwab@linux-m68k.org>

	Fix m68k OS ABI sniffer
	Do not override the generic OS ABI sniffer.

	Fixes: 3eba3a011a8 ("Various m68k fixes for gdb")

2024-08-19  Tom Tromey  <tromey@adacore.com>

	Ensure gdb.ada/multiarray.exp runs in both modes
	gdb.ada/multiarray.exp has a loop that looks like it should run the
	test in both 'all' and 'minimal' encodings mode.  However, the body of
	the loop doesn't actually use the 'flags' variable.  This was an
	oversight in the original commit.

2024-08-19  Nick Clifton  <nickc@redhat.com>

	Remove Walter Lee as maintainer for Tile Gx and Tile Pro

2024-08-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix a target: prefix issue in find_separate_debug_file
	Following on from the previous commit, this commit fixes the two KFAIL
	in gdb.base/sysroot-debug-lookup.exp when not using the
	native-extended-gdbserver board.

	The failures in this test, when using the 'unix' board, are logged as
	bug PR gdb/31804.  The problem appears to be caused by the use of the
	child_path function in find_separate_debug_file.

	What happens on the 'unix' board is that the file is specified to GDB
	with a target: prefix, however GDB spots that the target filesystem is
	local to GDB and so opens the file without a target: prefix.  When we
	call into find_separate_debug_file the DIR and CANON_DIR arguments,
	which are computed from the objfile_name() no longer have a target:
	prefix.

	However, in this test if the file was opened with a target: prefix,
	then the sysroot also has a target: prefix.  When child_path is called
	it looks for a common prefix between CANON_DIR (from the objfile_name)
	and the sysroot.  However, the sysroot still has the target: prefix,
	which means the child_path() call fails and returns nullptr.

	What I think we need to do is this: if the sysroot has a target:
	prefix, and the target filesystem is local to GDB, then we should
	strip the target: prefix from the sysroot, just as we do when opening
	a file (see gdb_bfd_open in gdb_bfd.c).

	Now, when we make the child_path() call neither the sysroot nor
	CANON_DIR will have a target: prefix, the child_path() call will
	succeed, and GDB will correctly find the debug information.

	There is just one remaining issue, the last path we look in when
	searching for debug information is built by starting with the sysroot,
	then adding the debug directory, see this line:

	  debugfile = path_join (target_prefix_str, root.c_str (),
	                         debugdir.get (), base_path, debuglink);

	The target_prefix_str is set to target: if DIR has a target: prefix,
	and DIR should have a target: prefix if the file we're looking for was
	opened with a target: prefix.  However, in our case the file was in a
	local filesystem so GDB stripped the prefix off.

	The sysroot however, does have the target: prefix, and the test is
	expecting to see GDB look within a file with the target: prefix.

	Given that the above line is about looking within a sub-directory of
	the sysroot, I think we should not be stripping the target: prefix off
	the sysroot path (as we do when building ROOT), instead, we should, in
	this case, not use TARGET_PREFIX_STR, and instead just use GDB's
	sysroot as it is (in this case with the target: prefix).

	With these fixes in place I now see no failures when using the 'unix',
	'native-gdbserver', or 'native-extended-gdbserver' boards with this
	test, and the KFAILs can be removed.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804

2024-08-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: avoid '//' in filenames when searching for debuginfo
	I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added
	recently actually had a KPASS when run with the
	native-extended-gdbserver board.  This was an oversight when adding
	the test.

	The failures in this test, when using the 'unix' board, are logged as
	bug PR gdb/31804.  The problem appears to be caused by the use of the
	child_path function in find_separate_debug_file.

	What happens on the 'unix' board is that the file is specified to GDB
	with a target: prefix, however GDB spots that the target filesystem is
	local to GDB and so opens the file without a target: prefix.  When we
	call into find_separate_debug_file the DIR and CANON_DIR arguments,
	which are computed from the objfile_name() no longer have a target:
	prefix.

	However, in this test if the file was opened with a target: prefix,
	then the sysroot also has a target: prefix.  When child_path is called
	it looks for a common prefix between CANON_DIR (from the objfile_name)
	and the sysroot.  However, the sysroot still has the target: prefix,
	which means the child_path() call fails and returns nullptr.

	What happens in the native-extended-gdbserver case is that GDB doesn't
	see the target filesystem as local.  Now the filename retains the
	target: prefix, which means that in the child_path() call both the
	sysroot and the CANON_DIR have a target: prefix, and so the
	child_path() call succeeds.  This allows GDB to progress, try some
	additional paths, and then find the debug information.

	So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect
	the test to succeed when using the native-extended-gdbserver protocol.

	This leaves one KFAIL when using the native-extended-gdbserver board,
	we find the debug information but (apparently) find it in the wrong
	file.  What's happening is that when GDB builds the filename for the
	debug information we end up with a '//' string as a directory
	separator, the test regexp only expects a single separator.

	Instead of just fixing the test regexp, I've updated the path_join
	function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to
	appear in the argument list after the first argument.  This means it's
	now possible to do this:

	  auto result = path_join ("/a/b/c", "/d/e/f");
	  gdb_assert (result == "/a/b/c/d/e/f");

	Additionally I've changed path_join so that it avoids adding
	unnecessary directory separators.  In the above case when the two
	paths were joined GDB only added a single separator between 'c' and
	'd'.  But additionally, if we did this:

	  auto result = path_join ("/a/b/c/", "/d/e/f");
	  gdb_assert (result == "/a/b/c/d/e/f");

	We'd still only get a single separator.

	With these changes to path_join I can now make use of this function in
	find_separate_debug_file.  With this done I now have no KFAIL when
	using the native-extended-gdbserver board.

	After this commit we still have 2 KFAIL when not using the
	native-gdbserver and unix boards, these will be addressed in the next
	commit.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-08-19  Guinevere Larsen  <blarsen@redhat.com>

	gdb: Fix printing frame when reversing out of a recursive call with clang
	Commit bf2813aff8f2988ad3d53e819a0415abf295c91f introduced some logic to
	not refresh the step frame id if it detects that the inferior is reverse
	stepping out of a recursive call, so that we would still print frame
	information once the inferior stops.

	However, that logic was overly specific, and wouldn't be hit for
	inferiors compiled with clang because clang adds line table entries that
	aren't statements, making process_event_stop_test go through a different
	branch on the relevant if statement.

	Fix this by not making the code that detects "reversing out of a
	recursion" an else clause to the previous if, but a standalone if block.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-08-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-18  Tom de Vries  <tdevries@suse.de>

	[gdb] Prune inferior after switching inferior
	Usually with test-case gdb.python/py-progspace-events.exp I get:
	...
	(gdb) inferior 1^M
	[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
	[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
	28      { /* Nothing.  */ }^M
	(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
	step^M
	FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
	do_parent_stuff () at py-progspace-events.c:41^M
	41        ++global_var;^M
	(gdb) PASS: gdb.python/py-progspace-events.exp: step
	...

	But occasionally I run into the following FAIL:
	...
	(gdb) inferior 1^M
	[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
	[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
	28      { /* Nothing.  */ }^M
	(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
	FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
	...

	This is caused by a race between the handling of an event, and the
	"inferior 1" command.

	In the passing case, the event is handled first.  During which prune_inferiors
	is called, but it can't remove inferior 2, because it's still the current one.

	In the failing case, the "inferior 1" command is handled first.  Then during
	handling of the event, prune_inferiors is called, and it can remove inferior 2
	because it's no longer the current one.

	This looks like a test-case issue to me, but ISTM that we can do better: by
	calling prune_inferiors asap, at the end of the "inferior 1" command, we
	stabilize the moment when the inferior is removed:
	...
	(gdb) inferior 1^M
	[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
	[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
	28      { /* Nothing.  */ }^M
	FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
	(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
	...

	This also allows us to simplify the test-case by removing the step command,
	which is no longer required to trigger the pruning of the inferior.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	PR gdb/31440
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440

2024-08-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-17  Nick Clifton  <nickc@redhat.com>

	Update release readme after making 2.43.1 release

2024-08-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-16  Tom Tromey  <tromey@adacore.com>

	Fix DAP failure when fetching global variables
	The relatively new "globals" scope code in DAP has a fairly obvious
	bug -- the fetch_one_child method should return a tuple with two
	elements, but instead just returns the variable's value.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-08-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linux
	With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
	...
	(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
	print pck.fp1_var^M
	$1 = 0.3125^M
	(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
	...

	The problem is that the thumb prologue analyzer overshoot, setting the
	breakpoint for main after line 49:
	...
	    46  int
	    47  main (void)
	    48  {
	    49    pck__fp1_var++;
	...
	and consequently we see the value of pck.fp1_var after line 49 instead of
	before line 49.  This is PR tdep/31981.

	Work around this by removing line 49 and all similar subsequent lines, which
	turn out to be dead code.

	Approved-By: Luis Machado <luis.machado@arm.com>

	Tested on arm-linux.

2024-08-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/arm-single-step-kernel-helper.exp
	On arm-linux I run into:
	...
	(gdb) p *kernel_user_helper_version^M
	Cannot access memory at address 0xffff0ffc^M
	(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
	...

	What the test-case is trying to do, is to access a special address in the arm
	linux kernel [1] using ptrace, which doesn't seem to work.

	This is with kernel version 6.1.55.  Perhaps this used to work, but the kernel
	was modified to be more strict with respect to access to this special address.

	Fix this by making the inferior access that special address instead.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

	PR testsuite/32070
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070

	[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt

2024-08-16  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb: Fix gdb.python/py-record-btrace.exp test
	My previous patch

	commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
	Author: Felix Willgerodt <felix.willgerodt@intel.com>
	Date:   Mon Feb 25 15:30:29 2019 +0100

	    python: Add clear() to gdb.Record.

	exposed a clear function for btrace data in python and added some tests
	for it.  That caused a regression (PR 32086) when recording with bts.

	This is reproducible even without my patch, when adding
	"maintenance btrace clear" to the test.

	When comparing the instructions that get recorded in both cases, the traces
	are almost identical, just that the first 3 instructions are missing.

	Before clear:

	(gdb) record instruction-history 1,100
	1	   0x0000555555555163 <main+12>:	movl   $0x0,-0x4(%rbp)
	2	   0x000055555555516a <main+19>:	movl   $0x0,-0x8(%rbp)
	3	   0x0000555555555171 <main+26>:	jmp    0x555555555184 <main+45>
	4	   0x0000555555555184 <main+45>:	cmpl   $0x63,-0x4(%rbp)
	5	   0x0000555555555188 <main+49>:	jle    0x555555555173 <main+28>
	6	   0x0000555555555173 <main+28>:	mov    -0x8(%rbp),%eax
	7	   0x0000555555555176 <main+31>:	mov    %eax,%edi
	...

	After clear:

	(gdb) record instruction-history 1,100
	1	   0x0000555555555184 <main+45>:	cmpl   $0x63,-0x4(%rbp)
	2	   0x0000555555555188 <main+49>:	jle    0x555555555173 <main+28>
	3	   0x0000555555555173 <main+28>:	mov    -0x8(%rbp),%eax
	4	   0x0000555555555176 <main+31>:	mov    %eax,%edi
	...

	The GDB manual describes this behaviour already:

		maint btrace clear
		Discard the branch trace data. The data will be fetched anew and
		the branch trace will be recomputed when needed.

		This implicitly truncates the branch trace to a single branch trace
		buffer. When updating branch trace incrementally, the branch trace
		available to GDB may be bigger than a single branch trace buffer.

	The test with BTS is updating the recorded trace incrementally.  After the
	clear, the buffer of raw trace data available is not enough to recompute the
	whole trace as it was before the clear(), and the first 3 instructions are
	missing.

	As increasing the buffer size for BTS didn't help, I propose to fix the test
	by moving the testing of clear to the end of the test.

	Approved-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086

2024-08-16  Jan Beulich  <jbeulich@suse.com>

	gas: don't open-code LEX_*NAME
	... except in read.c's definition of lex_type[], where readbility would
	otherwise suffer.

	opcodes/cgen: drop trailing whitespace also for cris
	While 919b75f7e289 ("Trailing space in opcodes/ generated files") took
	care of permanently zapping trailing whitespace, 547112801156
	("opcodes: cris: move desc & opc files from sim/") then didn't enhance
	the newly added code accordingly.

2024-08-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-15  H.J. Lu  <hjl.tools@gmail.com>

	Revert "Arm: correct macro use in gas testsuite"
	This reverts commit cfa18744d435b55bbbbc5ef1ae1df67e84aa1777.

	commit 6ae8a30d44f016cafb46a75843b5109316eb1996
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Fri Aug 9 11:59:31 2024 +0200

	    gas: have scrubber retain more whitespace

	has been reverted to fix PR gas/32073.

2024-08-15  H.J. Lu  <hjl.tools@gmail.com>

	Revert "bfin: correct macro use in gas testsuite"
	This reverts commit a1b7023447d19d70bc36d71b7627f457dbfae5ce.

	commit 6ae8a30d44f016cafb46a75843b5109316eb1996
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Fri Aug 9 11:59:31 2024 +0200

	    gas: have scrubber retain more whitespace

	has been reverted to fix PR gas/32073.

2024-08-15  H.J. Lu  <hjl.tools@gmail.com>

	Revert "ia64: correct macro use in gas testsuite"
	This reverts commit 2231ac9b9e88191178001d0ae5845e292acb2a56.

	commit 6ae8a30d44f016cafb46a75843b5109316eb1996
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Fri Aug 9 11:59:31 2024 +0200

	    gas: have scrubber retain more whitespace

	has been reverted to fix PR gas/32073.

2024-08-15  H.J. Lu  <hjl.tools@gmail.com>

	Revert "MIPS: correct macro use in gas and ld testsuites"
	This reverts commit c0e9aca554e33e900efbd6425c1830f0a20012f5.

	commit 6ae8a30d44f016cafb46a75843b5109316eb1996
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Fri Aug 9 11:59:31 2024 +0200

	    gas: have scrubber retain more whitespace

	has been reverted to fix PR gas/32073.

2024-08-15  Tom Tromey  <tromey@adacore.com>

	Add another constructor to scoped_restore_current_language
	While working on something else, I noticed that this is relatively
	common:

	  scoped_restore_current_language save;
	  set_language (something);

	This patch adds a second constructor to
	scoped_restore_current_language to simplify this idiom.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-08-15  Dimitar Dimitrov  <dimitar@dinux.eu>

	gas: pru: Fix trailing whitespace handling
	With commit 6ae8a30d44f016cafb46a75843b5109316eb1996, arguments followed
	by a C-style comment ended up with a trailing space.  That extra space
	character confused the PRU register name matching, leading to spurious
	errors about unrecognized registers.  This affected existing code like
	newlib's setjmp.s for pru.

	Fix by stripping the trailing whitespace for any argument.

	Even with 6ae8a30d44f016cafb46a75843b5109316eb1996 reverted, this patch
	is safe to be applied.

	Successfully regression-tested with GCC and newlib testsuites for pru-unknown-elf.

2024-08-15  H.J. Lu  <hjl.tools@gmail.com>

	lto: Don't include unused LTO archive members in output
	When plugin_object_p is called by elf_link_is_defined_archive_symbol to
	check if a symbol in archive is a real definition, set archive member
	plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO
	archive members in linker output.  When plugin_object_p is called as
	known used, call plugin claim_file if plugin_format is bfd_plugin_unknown
	or bfd_plugin_yes_unused.

	To get the proper support for archives with LTO common symbols with GCC,
	the GCC fix for

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361

	is needed.

	bfd/

		PR ld/32083
		* archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused
		the same as bfd_plugin_yes.
		* elflink.c (elf_link_is_defined_archive_symbol): Likewise.
		* bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused.
		* plugin.c (try_claim): Try claim_file_v2 first.
		* bfd-in2.h: Regenerated.

	ld/

		PR ld/32083
		* plugin.c (plugin_call_claim_file): Add an argument to return
		if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used.
		(plugin_object_p): When KNOWN_USED is false, we call plugin
		claim_file if plugin_format is bfd_plugin_unknown and set
		plugin_format to bfd_plugin_yes_unused on LTO object.  When
		KNOWN_USED is true, we call plugin claim_file if plugin_format
		is bfd_plugin_unknown or bfd_plugin_yes_unused.

2024-08-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix typo in src/collctrl.cc
	gprofng/ChangeLog
	2024-08-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/collctrl.cc (read_cpuinfo): Fix typo.

2024-08-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Log gdb version and configuration in DAP
	I think it would be useful for gdb's DAP logs to come with the version
	and configuration information.  This might make debugging some bug
	reports a little simpler.

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Notify Python when breakpoint symbol changes
	A DAP user noticed that breakpoints set by address were never updated
	to show their location after the DAP launch request.  It turns out
	that gdb does not emit the breakpoint-modified event when this sort of
	breakpoint is updated.

	This patch changes gdb to notify the breakpoint-modified observer when
	a breakpoint location's symbol changes.  This in turn causes the DAP
	event to be emitted.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Fix failure with C++ exceptions in DAP
	While working on earlier patches, I noticed that the DAP C++ exception
	test had some strange results in the log.  Digging into this, I found
	that while the Ada catchpoints emit a "bkptno" field in the MI result,
	the C++ ones do not -- but the DAP code was relying on this.

	This patch fixes the problem by changing which field is examined, and
	then updates the tests to verify this.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Make DAP instruction breakpoints unverified
	Currently, when a DAP client uses setInstructionBreakpoints, the
	resulting breakpoints are created as "verified", even though there is
	no symbol file and thus the breakpoint can't possibly have a source
	location.

	This patch changes the DAP code to assume that all breakpoints are
	unverified before launch.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Introduce exec_mi_and_log for DAP
	This adds a new exec_mi_and_log function that wraps gdb.execute_mi and
	logs the command.  This can be handy when debugging DAP.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add an LTO test for common symbol override
	Linker checks if a symbol in an archive member is a real definition, not
	common, before including the archive member in the link output so that
	only a real definition in archive will override the common symbol in
	object file.  Add an LTO test to verify that a real definition in archive
	overrides the common symbol in object file.

		* testsuite/ld-plugin/common-1.c: New file.
		* testsuite/ld-plugin/definition-1.c: Likewise.
		* testsuite/ld-plugin/lto.exp: Run common tests.

2024-08-14  Tom Tromey  <tromey@adacore.com>

	Remove unnecessary default argument from initialize_block_iterator
	I noticed that initialize_block_iterator has a default value for one
	of its arguments, but this is not needed as this function has a single
	caller that always passes all arguments.  This patch removes the
	default.  Tested by rebuilding.

2024-08-14  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Fix DT_RELR and relaxation interaction
	Due to the way BFD implements DT_RELR as a part of relaxation, if in a
	relax trip size_relative_relocs has changed the layout, when
	relax_section runs only the vma of the section being relaxed is
	guaranteed to be updated.  Then bad thing can happen.  For example, when
	linking an auxilary program _freeze_module in the Python 3.12.4 building
	system (with PGO + LTO), before sizing the .relr.dyn section, the vma of
	.text is 30560 and the vma of .rodata is 2350944; in the final
	executable the vma of .text is 36704 and the vma of .rodata is 2357024.
	The vma increase is expected because .relr.dyn is squashed somewhere
	before .text.  But size_relative_relocs may see the state in which .text
	is at 36704 but .rodata "is" still at 2350944.  Thus the distance
	between .text and .rodata can be under-estimated and overflowing
	R_LARCH_PCREL20_S2 reloc can be created.

	To avoid this issue, if size_relative_relocs is updating the size of
	.relr.dyn, just supress the normal relaxation in this relax trip.  In
	this situation size_relative_relocs should have been demending the next
	relax trip, so the normal relaxation can happen in the next trip.

	I tried to make a reduced test case but failed.

2024-08-14  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Fix assertion failure with DT_RELR
	In the DT_RELR implementation I missed a code path emiting relative
	reloc entries.  Then the already packed relative reloc entries will be
	(unnecessarily) pushed into .rela.dyn but we've not allocated the space
	for them, triggering an assertion failure.

	Unfortunately I failed to notice the issue until profiled bootstrapping
	GCC with LTO and -Wl,-z,pack-relative-relocs.  The failure can be easily
	triggered by linking a "hello world" program with -fprofile-generate and
	LTO:

	    $ PATH=$HOME/ld-test:$PATH gcc hw.c -fprofile-generate -Wl,-z,pack-relative-relocs -flto
	    /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628
	    /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628
	    collect2: error: ld returned 1 exit status

	And the reduced test case is just incredibly simple (included in the
	patch) so it seems I'm just stupid enough to fail to detect it before.
	Let's fix it now anyway.

2024-08-14  Jan Beulich  <jbeulich@suse.com>

	gas: correct .irpc handling with empty string
	Following 69cab370cf66 ("gas: adjust handling of quotes for .irpc") the
	closing quote was mistakenly treated as the first quoted character.

2024-08-14  Jan Beulich  <jbeulich@suse.com>

	x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding
	When VexVVVV handling was re-worked, .insn broke: When an opcode
	extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is
	already occupied, matching what c8866e3ec5e2 ("x86: Drop using
	extension_opcode to encode vvvv register") did.

	While adding (bad) POP2 forms, also slightly adjust existing ones:
	No need to use XMM registers, and no need to specify %r8 when really
	%rax is meant twice (EVEX.vvvv not really being the culprit there, or
	else EVEX.V' would also have needed mentioning).

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Extend ptwrite event decoding.
	Call the ptwrite filter function whenever a ptwrite event is decoded.
	The returned string is written to the aux_data string table and a
	corresponding auxiliary instruction is appended to the function segment.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace, python: Enable ptwrite filter registration.
	By default GDB will be printing the hex payload of the ptwrite package as
	auxiliary information.  To customize this, the user can register a ptwrite
	filter function in python, that takes the payload and the PC as arguments and
	returns a string which will be printed instead.  Registering the filter
	function is done using a factory pattern to make per-thread filtering easier.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace, linux: Enable ptwrite packets.
	Enable ptwrite in the PT config, if it is supported by the kernel.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace, gdbserver: Add ptwrite to btrace_config_pt.
	This enables gdb and gdbserver to communicate about ptwrite support.  If
	ptwrite support would be enabled unconditionally, GDBs with older libipt
	versions would break.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	python: Add clear() to gdb.Record.
	This function allows to clear the trace data from python, forcing to
	re-decode the trace for successive commands.
	This will be used in future ptwrite patches, to trigger re-decoding when
	the ptwrite filter changes.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	python: Introduce gdb.RecordAuxiliary class.
	Auxiliary instructions are no real instructions and get their own object
	class, similar to gaps. gdb.Record.instruction_history is now possibly a
	list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary
	objects.

	This patch is in preparation for the new ptwrite feature, which is based on
	auxiliary instructions.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Handle stepping and goto for auxiliary instructions.
	Print the auxiliary data when stepping. Don't allow to goto an auxiliary
	instruction.

	This patch is in preparation for the new ptwrite feature, which is based on
	auxiliary instructions.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Enable auxiliary instructions in record function-call-history.
	Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
	is encountered in the function-call-history.  Printing is
	active by default, it can be silenced with the /a modifier.

	This patch is in preparation for the new ptwrite feature, which is based on
	auxiliary instructions.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Enable auxiliary instructions in record instruction-history.
	Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
	is encountered in the instruction-history.  Printing is active by default,
	it can be silenced with the /a modifier.

	This patch is in preparation for the new ptwrite feature, which is based on
	auxiliary instructions.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Felix Willgerodt  <felix.willgerodt@intel.com>

	btrace: Introduce auxiliary instructions.
	Auxiliary instructions are pseudo instructions pointing to auxiliary data.
	This auxiliary data can be printed in all commands displaying (record
	function-call-history, record instruction-history) or stepping through
	(stepi etc.) the execution history, which will be introduced in the next
	commits.

	This patch is in preparation for the new ptwrite feature, which is based on
	auxiliary instructions.

	Approved-By: Markus Metzger <markus.t.metzger@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove unnecessary code relating to limited-length arrays
	While reviewing this commit:

	  commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528
	  Date:   Tue Aug 6 19:34:18 2024 +0200

	      Mark unavailable bytes of limited-length arrays when allocating contents

	I spotted that there was some code in value::record_latest relating to
	limited-length arrays which appeared redundant.  The code was added
	with the first introduction on limited-length arrays in commit:

	  commit a0c07915778486a950952139d27c01d4285b02b4
	  Date:   Fri Feb 10 23:49:19 2023 +0000

	      GDB: Introduce limited array lengths while printing values

	The code in question is in value::record_latest.  When the value being
	recorded is lazy we need to fetch its value before adding it to the
	history list.  The code I spotted checks to see if the value is lazy,
	if we currently have array limiting in effect, and if we do sets
	m_limited_length to max_value_size before finally calling fetch_lazy.

	The first thing fetch_lazy does is call allocate_contents to setup the
	value's buffer, and in allocate_contents we perform the same set of
	checks: if the value is an array, and array length limiting is in
	effect then only allocate max_value_size buffer for the contents.

	In ::allocate_contents the `if` condition check is spread out between
	::allocate_contents and ::set_limited_array_length, but I'm certain
	it's checking the same condition.

	As such the checks and m_limited_length adjustment in ::record_latest
	is redundant and can be removed.

	Out of curiosity I went back to the original a0c07915778486a commit
	and removed the same block of code from record_latest_value (as
	value::record_latest was called back then) and non of the tests added
	by commit a0c07915778486a failed.  I think this block of code was
	never needed.

	Anyway, I removed the unnecessary code and retested and there are no
	regressions.

	There should be no user visible changes after this commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-08-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-13  H.J. Lu  <hjl.tools@gmail.com>

	elf: Never set non_ir_ref_regular for debug reference
	Never set non_ir_ref_regular for debug reference since references in
	debug sections shouldn't impact LTO output.

		* elflink.c (elf_link_add_object_symbols): Don't check strip for
		references in debug sections when setting non_ir_ref_regular.

2024-08-13  Gerlicher, Klaus  <klaus.gerlicher@intel.com>

	gdb/gdbarch: fix a dot-space-space in generated files
	This is a very small patch to straighten out dot-space-space in these
	comments in the gdbarch generated files:

	-  /* Skip verify of short_bit, invalid_p == 0 */
	+  /* Skip verify of short_bit, invalid_p == 0.  */

	There is no functional change after this commit.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-13  Alan Modra  <amodra@gmail.com>

	gas macro arg1 test
	A number of targets pad out the data section, and there are targets
	that have 2 or 4 octets per byte.  And some even that don't have '#'
	as a line comment char.  tic6x-elf fails the test with "Error: too
	many positional arguments".

		* testsuite/gas/macros/arg1.s: Pad out data section.  Use C style
		comments.
		* testsuite/gas/macros/arg1.d: Adjust to suit.  Don't run on
		multi-octet per byte targes.  xfail tic6x.

2024-08-13  Alan Modra  <amodra@gmail.com>

	PR32072 dlltool.c initializer-string is too long
		PR 32072
		* dlltool.c: Delete unneeded forward function declaraions.
		Make buffers used by dlltmp static.
		(prefix_encode): Avoid warning.  Use stpcpy.

2024-08-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: specify the heap data collection range
	Extend the -H option:
	 -H {off|on|N1[-N2]}  disable , or enable heap tracing, or
	                      specify the heap data collection range.
	                      The default is "-H off".

	gprofng/ChangeLog
	2024-08-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* libcollector/heaptrace.c: Read the range in the -H option.
		Do not collect data if the allocated memory is out of range.
		* src/collctrl.h (heaptrace_mode): Define as char * value.
		* src/envsets.cc: Updated since heaptrace_mode is changed.
		* src/collctrl.cc: Accept the extended -H option.
		* src/gp-collect-app.cc: Accept the extended -H option.
		Remove unused code.

2024-08-12  Dimitar Dimitrov  <dimitar@dinux.eu>

	sim: pru: Fix test case assembly with latest GAS
	After the recent change in GAS [1], macro arguments must be quoted or
	grouped with parenthesis.  Add the necessary parenthesis in order to fix
	assembly errors like:
	    mul.s:31: Error: too many positional arguments

	[1] https://sourceware.org/pipermail/binutils/2024-July/136053.html

2024-08-12  Tom Tromey  <tromey@adacore.com>

	Simplify typename_concat
	This patch simplifies typename_concat, changing the return type and
	removing the obstack allocation code.  The latter is possible because
	the only caller using this mode uses the name when creating a new
	type, and 'new_type' copies the string to the appropriate obstack
	anyway.  It also changes typename_concat to use 'concat'.  This change
	lets us remove a mildly fragile macro as well.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-08-12  H.J. Lu  <hjl.tools@gmail.com>

	gas: Add macro tests for PR gas/32073
	1. Add a macro test for expression argument with inner white spaces and
	a white space before argument added by C preprocessor.
	2. Add a x86-64 specific macro test.

		PR gas/32073
		* testsuite/gas/i386/x86-64-macro-1.d: New file.
		* testsuite/gas/i386/x86-64-macro-1.s: Likewise.
		* testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1.
		* testsuite/gas/macros/arg1.d: New file.
		* testsuite/gas/macros/arg1.s: Likewise.
		* testsuite/gas/macros/macros.exp: Run arg1.

2024-08-12  H.J. Lu  <hjl.tools@gmail.com>

	Revert "gas: have scrubber retain more whitespace"
	This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996.

	This fixes PR gas/32073.

2024-08-12  H.J. Lu  <hjl.tools@gmail.com>

	Revert "gas: drop scrubber states 14 and 15"
	This reverts commit 7dd0dfbde7ee31167a3b2e192a575493d26b7b0a.

	This is a prerequisite for the PR gas/32073 fix.

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	pre-commit: autoupdate
	Run `pre-commit autoupdate`.

	Change-Id: I6623a61b7d1e827360854e825d84c5608a68e07b

2024-08-12  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	[gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled
	There are a couple of ways that readline wrapping can be disabled:
	- using "set horizontal-scroll-mode on" in INPUTRC,
	- using a TERM setting like TERM=dumb, and
	- building gdb with stub-termcap.

	Using a trigger patch in default_gdb_init that adds
	"set horizontal-scroll-mode on" to INPUTRC:
	...
	-    setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"]
	+    setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"]
	...
	we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in
	PR testsuite/31201 (which was reported for the stub-termcap case):
	...
	WARNING: timeout in accept_gdb_output
	Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1):
	    0 Quit
	    1 <89012345678901234567890123456789W
	    2
	    ...
	    23
	FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap
	...

	Fix this by accepting the horizontal-scroll-mode style output.  We do
	this only when in CLI mode though, when in TUI wrapping works as before
	because it doesn't rely on readline.

	Tested on x86_64-linux.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0
	amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards
	incompatible changes.  Adjust the amd-dbgapi target code accordingly.
	Given that the AMD GPU port in upstream GDB today is of limited use
	(it's still missing important  pieces), we don't really care about
	supporting amd-dbgapi versions other than the latest stable one, so no
	effort is made to keep compatibility with versions 6.1.2 and older.

	The changes are:

	 - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to
	   AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists
	   but is deprecated), use the latter.

	 - In the callbacks structure, the get_os_pid callback was replaced with
	   client_process_get_info, which is more general and extensible.
	   Convert our get_os_pid to a new, equivalent, client_process_get_info
	   callback.  Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE
	   query, but just return "not available".

	 - The xfer_global_memory callback was added to the callbacks structure,
	   add that new callback.

	 - Update configure.ac to check for amd-dbgapi >= 0.75.0.

	Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981
	Approved-By: Lancelot Six <lancelot.six@amd.com>
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass inferior to gdbarch_update_p
	Make the current inferior reference bubble up one level.  I think this
	makes it clearer what gdbarch_update_p, which is update the passed
	inferior's architecture (although the function name could probably be
	better).

	When gdbarch_find_by_info, it is possible for the new architecture's
	init callback to be called.  I have not audited all of them (there are
	just too many), it's possible that some of them do care about the
	current inferior, for some reason (for instance, if one of them makes a
	target call).  If so, they should be changed too.

	Change-Id: I89f012188d7fdca395a830f4b013743565f26847

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass inferior to target_current_description
	Make the current inferior reference bubble up one level.

	Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: change names of enumerations in enum flags selftest
	When reading this test (in the context of PR 31331), I had trouble
	understanding the tests, because of the abbreviated names.  I would
	prefer if the names were a bit more explicit, like this.

	Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbsupport: use `using` in enum flags code
	I think that `using` is easier to read than `typedef`, and it's the
	modern C++ thing anyway.

	Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: remove C enum flags fallback
	This might have been useful during the C -> C++ conversion (not sure),
	but it doesn't appear useful today.  I don't see when enum-flags.h would
	be used in a C context.

	Change-Id: I6c7ed655757248a62a1bf6615995f42e8aa2b4bd

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb/NEWS: announce removal of QNX Neutrino support
	QNX Neutrino support was removed here [1], but I forgot to mention in in
	NEWS.

	[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=36fb20fa93484b104d91e42e38930ee8629192ab

	Change-Id: I8db7957acdd0be3c1e0b751c7c245870c4cd7101
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add program_space parameter to lookup_minimal_symbol_text
	Make the current program space reference bubble up one level.  Use a
	program space from the context whenever that makes sense.

	Change-Id: Id3b0bf4490178d71a9aecdbf404b9287c22b30f5
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add program_space parameter to lookup_minimal_symbol_linkage
	Make the current_program_space reference bubble up one level.

	Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to get_symbol_leading_char
	Make the current_program_space references bubble up one level.  In this
	case, I think it makes sense to use m_objfile's program space.

	Change-Id: Ibecb89b5e8a0363328240f1675d0fb95ff99c99a
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add program_space parameter to lookup_minimal_symbol
	>From what I can see, lookup_minimal_symbol doesn't have any dependencies
	on the global current state other than the single reference to
	current_program_space.  Add a program_space parameter and make that
	current_program_space reference bubble up one level.

	Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove lookup_bound_minimal_symbol
	Now that lookup_minimal_symbol has default values for sfile and objf,
	calling lookup_bound_minimal_symbol is identical to calling
	lookup_minimal_symbol without sfile and objf.  Remove
	lookup_bound_minimal_symbol, replace call sites with
	lookup_minimal_symbol.

	Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make lookup_minimal_symbol objf and sfile parameters optional
	Most calls to lookup_minimal_symbol don't pass a value for sfile and
	objf.  Make these parameters optional (have a default value of
	nullptr).  And since passing a value to `objf` is much more common than
	passing a value to `sfile`, swap the order so `objf` comes first, to
	avoid having to pass a nullptr value to `sfile` when wanting to pass a
	value to `objf`.

	Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: drop struct keyword when using bound_minimal_symbol
	This is a simple find / replace from "struct bound_minimal_symbol" to
	"bound_minimal_symbol", to make things shorter and more consisten
	througout.  In some cases, move variable declarations where first used.

	Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove find_and_open_solib so_list method
	Now that the nto port is removed, this is unused.

	Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: remove #ifndef REALTIME_LO in signals.cc
	REALTIME_LO was only possibly previously defined in config/nm-nto.h,
	which is now removed.  So we can remove the #ifndef protecting against a
	redefinition of REALTIME_LO in gdbsupport/signals.cc.

	Change-Id: I021b9518ceaa6223bd480ff1e07e9a978b0b241e
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove QNX Neutrino support
	Remove the support for the QNX Neutrino OS (tdep and native bits).  This
	has been unmaintained for years, and we don't have a way to see if it
	works (or even builds, for the native parts).  Without somebody actively
	maintaining it, this is just a burden for developers, especially that
	this port does a few weird unique things that require reasoning about
	when doing big change.

	Support for GDBserver was removed in 2020, commit 613f149a90d6
	("gdbserver: remove support for Neutrino").

	Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-08-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename target-delegates.c to target-delegates-gen.c
	Following this suggestion:

	https://inbox.sourceware.org/gdb-patches/2a0520ec-ccfe-4fc3-b051-7b8c60294de5@efficios.com/T/#md537792a1871addf153f3e406224f9baf025414a

	Change-Id: I30988c46505f130ca16155891958f92621cada97
	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-10  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add PR ld/32067 tests
	Add PR ld/32067 tests with the compiler driver since the -plugin option
	is needed to trigger this --oformat binary bug.

		PR ld/32067
		* testsuite/ld-i386/i386.exp: Run PR ld/32067 test.
		* testsuite/ld-x86-64/x86-64.exp: Likewise.
		* testsuite/ld-i386/start.s: Add .note.GNU-stack section.
		* testsuite/ld-x86-64/pr32067.s: New file.

2024-08-10  Alan Modra  <amodra@gmail.com>

	PR32067, ld -Wl,--oformat,binary crash in _bfd_elf_link_keep_memory
	The direct fix for this segfault is to test for a non-NULL bed in
	_bfd_elf_link_keep_memory, but also there isn't much point in running
	code for LTO if the output is binary.

		PR 32067
		* elflink.c (_bfd_elf_link_keep_memory): Test for non-NULL bed.
		(elf_link_add_object_symbols): Don't run the loop setting
		non_ir_ref_regular if the output hash table is not ELF.

2024-08-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-09  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix test failure when TUI is not enabled
	This adds a missing allow_tui_tests guard.

	When tui is not enabled this test case does
	typically fail:

	FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-08-09  Stephan Rohr  <stephan.rohr@intel.com>

	gdb: adjust the default place of 'list' to main's prologue
	The 'list' command prints around the 'main' function if the current
	source location is not set.  The prologue of 'main' is skipped and the
	first real line of 'main' is offset by 'lines_to_print - 1'.  This is
	incorrect, the location should be defaulted to main's prologue without
	applying offsets (similar to 'list main').  Printing around the selected
	line is then done in 'list_around_line'.

	The patch also fixes an issue if the list command is used before the
	program is started.  For example, with the following code:

	26 static void attribute ((used)) ambiguous_fun (void) {}
	27
	28 static int attribute ((used)) ambiguous_var;
	29
	30
	31
	32
	33
	34
	35
	36
	37
	38 int
	39 main (void)
	40 {
	41   return 0;
	42 }

	GDB offsets the relevant line by 'lines_to_print - 1' and then by another
	'lines_to_print / 2' and prints:

	(gdb) list
	27
	28 static int attribute ((used)) ambiguous_var;
	29
	30
	31
	32
	33
	34
	35
	36

	With this patch, GDB correctly prints:

	37
	38      int
	39      main (void)
	40      {
	41        return 0;
	42      }

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-09  Jan Beulich  <jbeulich@suse.com>

	gas: drop scrubber states 14 and 15
	While sadly 5262831592fb doesn't say anything on why these would have
	been needed, the latest with the removal of most of the opcode vs
	operands distinction in the scrubber these shouldn't be needed anymore.
	The implementation was a little questionable anyway, in moving back to
	states expecting labels, when clearly labels shouldn't really be
	following predicates (in practice, due to another bug, at least ia64
	permits such).

2024-08-09  Jan Beulich  <jbeulich@suse.com>

	gas: have scrubber retain more whitespace
	According to the description of the state machine, the expectation
	appears to be that (leaving aside labels) any insn mnemonic or
	directive would be followed by a comma separated list of operands. That
	may have been true very long ago, but the latest with the advent of more
	elaborate macros this isn't rhe case anymore. Neither macro parameters
	in macro definitions nor macro arguments in macro invocations are
	required to be separated by commas. Hence whitespace serves a crucial
	role there. Plus even without "real" macros issues exist, in e.g.

		.irp n, ...
		insn\n\(suffix)	operand1, operand2
		.endr

	Whitespace following the closing parenthesis would have been removed
	(ahead of even processing the .irp), as the "opcode" was deemed to have
	ended earlier already.

	Therefore, squash the distinction between "opcode" and operands, i.e.
	fold state 10 back into state 3. Also drop most of the distinction
	between "symbol chars" and "relatively normal" ones. Not entirely
	unexpectedly this results in the need to skip whitespace in a few more
	places in arch-specific code (and quite likely more changes are needed
	for insn forms not covered by the testsuite).

	As a result the D10V special case is no longer necessary.

	In config/tc-sparc.c also move a comment to be next to the code being
	commented.

	In opcodes/cgen-asm.in some further cleanup is done, following the local
	var adjustments.

2024-08-09  Jan Beulich  <jbeulich@suse.com>

	MIPS: relax gas testsuite whitespace expectations
	In a subsequent change the scrubber is going to be changed to retain
	further whitespace.  Test case expectations generally would better not
	depend on the specific whitespace treatment by the scrubber, unless of
	course a test is specifically about it.  Adjust relevant test cases to
	permit blanks where those will subsequently appear.

	aarch64: relax gas testsuite whitespace expectations
	In a subsequent change the scrubber is going to be changed to retain
	further whitespace. Test case expectations generally would better not
	depend on the specific whitespace treatment by the scrubber, unless of
	course a test is specifically about it. Adjust relevant test cases to
	permit blanks where those will subsequently appear.

	Arm: relax gas testsuite whitespace expectations
	In a subsequent change the scrubber is going to be changed to retain
	further whitespace. Test case expectations generally would better not
	depend on the specific whitespace treatment by the scrubber, unless of
	course a test is specifically about it. Adjust relevant test cases to
	permit blanks where those will subsequently appear.

	m32r: move scrubber override to target header
	Other than LEX_IS_* settings, such #define-s don't belong into the
	common source file.

	Arm: respect line separators for .symver scrubber special case
	Directives end at "line" (really: statement) separators, not just at
	new-line chars.

	gas: respect CR_EOL also for scrubbing
	While apparently intended to be only externally controlled (e.g. via
	specifying CFLAGS at make invocation), we should still keep scrubber and
	lexer in sync in this regard. There's one place which imo was previously
	wrong already, but would go further wrong and hence is being adjusted
	right here: An .mri directive can be terminated by any kind of "line"
	(really: statement) separators.

	gas: have scrubber also respect quoted labels
	For the handling of ':' elsewhere in the scrubber to be correct with
	regard to labels, the state after parsing a string found at the start of
	a line must match that after finding a symbol character at the start of
	a line. (Things are largely okay when there's whitespace ahead of the
	label: Whitespace after the colon then is retained rather than dropped
	for typical targets like x86, but read.c will know to deal with that.)

2024-08-09  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR32014, .option directives shuoldn't affect elf attribute.
	The .option arch/rvc/norvc/push/pop directives can only take effect for a
	small/large specific code region, so they are not file-level architecture
	setting.  They should only affect the mapping symbols only rather than the
	file-level elf architecture attribute.  Otherwise, the elf architecture
	attribute will appear to missing some extensions when -flto merges files
	with different .option architecture settings.

	gas/
		PR 32014
		* config/tc-riscv.c (file_arch_str): New const char *, rather than the
		arch_str in the riscv_rps_as.subset_list, it's file-level so only be
		affected by .attribute arch directive.
		(riscv_reset_subsets_list_arch_str): Renamed to riscv_set_arch_str, and
		also can handle both file_arch_str and arch_str in subset_list, just
		give the pointer address as the input.
		(riscv_set_arch): Called by -march and .attribute arch, so set both
		file_arch_str and arch_str in subset_list.
		(s_riscv_option): Updated .option arch/rvc/norvc/push/pop that only
		set the arch_str in subset_list.
		(riscv_write_out_attrs): Output elf architecture attribute according to
		file_arch_str.  Freed file_arch_str.
		* doc/c-riscv.texi: Added destrbution that .option directives shouldn't
		affect the elf attribute settings.
		* testsuite/gas/riscv/option-arch.s: From option-arch-01/02/03 merged.
		* testsuite/gas/riscv/option-arch-dis.d: Likewise, for dis-assembler.
		* testsuite/gas/riscv/option-arch-attr.d: Likewise, to check readelf -A.

2024-08-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-08  Richard Henderson  <richard.henderson@linaro.org>

	gas: sparc: Fix faligndatai assembly and disassembly
	The first operand is a general register, not an fp register;
	the third operand is encoded into RS2, not RS3;
	the second operand must match the destination operand.

2024-08-08  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix handling of ^C during disassembly
	Inspired by the trigger patch I used here [1], I tried this in
	gdbpy_print_insn:
	...
	   /* Call into the registered disassembler to (possibly) perform the
	      disassembly.  */
	+  set_quit_flag ();
	   PyObject *insn_disas_obj = (PyObject *) disasm_info;
	   gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (),
	                                                    insn_disas_obj,
	...
	and with test-case gdb.python/py-disasm-exec.exp ran into:
	...
	(gdb) disassemble test^M
	Dump of assembler code for function test:^M
	   0x00000000004101ac <+0>:     Python Exception <class 'KeyboardInterrupt'>: ^M
	^M
	unknown disassembler error (error = -1)^M
	(gdb)
	...

	This is incorrect, the KeyboardInterrupt should propagate and interrupt the
	command.

	Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in
	gdbpy_print_insn, giving us instead:
	...
	(gdb) disassemble test^M
	Dump of assembler code for function test:^M
	   0x00000000004101ac <+0>:     ^M
	Quit^M
	(gdb)
	...

	Tested on aarch64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html

2024-08-08  Tom de Vries  <tdevries@suse.de>

	[gdb] Handle ^C during disassembly
	In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while
	disassembling.

	I managed to reproduce this on aarch64-linux in a Leap 15.5 container using
	this trigger patch:
	...
	 gdb_disassembler_memory_reader::dis_asm_read_memory
	   (bfd_vma memaddr, gdb_byte *myaddr, unsigned int len,
	    struct disassemble_info *info) noexcept
	 {
	+  set_quit_flag ();
	   return target_read_code (memaddr, myaddr, len);
	 }
	...
	and a simple gdb command line calling the disassemble command:
	...
	$ gdb -q -batch a.out -ex "disassemble main"
	...

	The following scenario leads to the fatal error:
	- the disassemble command is executed,
	- set_quit_flag is called in
	  gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a
	  user pressed ^C,
	- target_read_code calls QUIT, which throws a
	  gdb_exception_quit,
	- the exception propagation mechanism reaches c code in libopcodes and a fatal
	  error triggers because the c code is not compiled with -fexception.

	Fix this by:
	- wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in
	  catch_exceptions (which consequently needs moving to a header file), and
	- reraising the caught exception in default_print_insn using QUIT.

	Tested on aarch64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025

2024-08-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-07  Jan Beulich  <jbeulich@suse.com>

	score: drop TC_ALPHA code
	I can't see how that could ever have come into play.

2024-08-07  Jan Beulich  <jbeulich@suse.com>

	gas: drop dead VMS code from command line handling
	The only time 'v' was overridden, allowing for an optional value, was
	when OBJ_VMS support still existed (until a little less than 20 years
	ago). Drop the respective leftovers.

	With that OPTION_VERBOSE also becomes redundant and hence is being
	dropped.

2024-08-07  Jan Beulich  <jbeulich@suse.com>

	VAX: drop OBJ_VMS leftovers
	OBJ_VMS support was dropped almost 20 years ago (e330299ed5ee). Drop
	respective code from tc-vax.c as well.

	While there, make adjustments for OBJ_ELF as well: -K was dropped over
	20 years ago (530556a951f5), yet left in md_shortopts. OPTION_PIC isn't
	really necessary either; 'k' can be used instead. And then the ELF
	options available weren't displayed by md_show_usage().

2024-08-07  Jan Beulich  <jbeulich@suse.com>

	gas: improve unrecognized command line option diagnostic
	Printing optc with %c makes sense only when optc is actually a
	character. Add logic to also deal with unrecognized long options,
	rejected by md_parse_option() rather than get_opt_long_only(). Also
	quote the reproduced strings, such that possible included whitespace
	can be recognized.

2024-08-07  Nelson Chu  <nelson@rivosinc.com>

	gas/NEWS: Moved RISC-V Zimop/Zcmop changes into 2.43 section due to backport.

2024-08-07  Alan Modra  <amodra@gmail.com>

	loongarch ld testsuite xpasses
	Some tests started passing with commit 3a83f0342e54.  However,
	supporting a changed ld output format is not so simple, and the change
	to the loongarch_elf_hash_table macro needs further changes to the
	rest of the code.  It is true that some uses of
	loongarch_elf_hash_table do not need to check the type of the hash
	table, but others like loongarch_elf_relax_section do need to check.
	bfd_relax_section is called in lang_size_sections using the input bfd,
	not the output bfd.  If the input bfd may be of different type to the
	output, then the hash table type must be checked before accessing
	elements of the hash table.  This patch corrects
	loongarch_elf_relax_section.  I haven't checked all the uses of the
	hash table throughout the loongarch backend.

	bfd/
		* elfnn-loongarch.c (loongarch_elf_relax_section): Don't relax
		unless the hash table is loongarch_elf_link_hash_table.
		Move variable declarations.  Formatting.
	ld/
		* testsuite/ld-elf/pr21884.d: Don't xfail loongarach.
		* testsuite/ld-unique/pr21529.d: Likewise.

2024-08-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-06  Hannes Domani  <ssbssa@yahoo.de>

	Mark unavailable bytes of limited-length arrays when allocating contents
	Using 'output' to print arrays larger than max-value-size, with only
	repeating elements, can cause gdb to crash:
	```
	$ cat a.c:
	char a[1000000];

	int main()
	{
	  return a[0];
	}
	$ gdb -q a
	(gdb) print a
	$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
	(gdb) output a

	This application has requested the Runtime to terminate it in an unusual way.
	Please contact the application's support team for more information.
	```

	Using 'print' works, because value::record_latest sets the unavailable
	bytes of the value when it's added to the value history.
	But 'outout' doesn't do that, so the printing tries to access more bytes
	than are available.

	The original problem in PR32015 was about using 'print' of a dynamic
	array in a D program.
	Here the crash happens because for 'print' the value was a struct with
	length/ptr fields, which is converted in d-valprint.c into an array.
	So value::record_latest didn't have a chance to mark the unavailable
	bytes in this case.

	To make sure the unavailable bytes always match the contents, this fixes
	it by marking the unavailable bytes immediately after the contents are
	allocated.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-06  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: replace verbose expressions with local vars
	Replace the scattered and repeated uses of verbose expressions with
	variables.  E.g.,
	  ginsn_get_src_reg (src1)  -> src1_reg
	  ginsn_get_src_type (src1) -> src1_type
	etc.

	This hopefully makes the logic bit more maintainable.  While at it,
	include minor adjustments to make few checks in gen_scfi_ops () more
	precise:
	  - When getting imm value from src operand, ensure the src type is
	    GINSN_SRC_IMM,
	  - When getting reg from src operand, ensure the src type is checked
	    too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate).

	On the other hand, the changes in verify_heuristic_traceable_reg_fp ()
	and verify_heuristic_traceable_stack_manipulation () are purely
	mechanical.

	gas/
	        * scfi.c (verify_heuristic_traceable_reg_fp): Add new local
		vars and reuse them.
	        (verify_heuristic_traceable_stack_manipulation): Likewise.
	        (gen_scfi_ops): Likewise.  Additionally, make some conditionals
		more precise.

2024-08-06  Hau Hsu  <hau.hsu@sifive.com>

	RISC-V: map zext.h to pack/packw if Zbkb is enabled
	The `zext.h` is zero-extend halfword instruction that belongs to Zbb.
	Currently `zext.h` falls back to 2 shifts if Zbb is not enabled.  However, the
	encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which
	belongs to Zbkb.  The instructions pack the low halves of rs1 and rs2 into rd.
	When rs2 is zero (x0), they behave like zero-extend instruction, and the
	encoding are exactly the same as zext.h.

	Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled,
	instead of 2 shifts. This reduces one instruction.

	This patch does this by making `zext.h` also available for Zbkb.

	opcodes/
		* riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use
		`ZBB_OR_ZBKB` instruction class.

	gas/
		* testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to
		pack/packw encoding.
		* testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise.
		* testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise.

2024-08-06  Mary Bennett  <mary.bennett682@gmail.com>

	RISC-V: Add support for XCvBitmanip extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett682@gmail.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:
		* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvbitmanip`
		instruction class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:
		* config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension
		for CORE-V.
		* testsuite/gas/riscv/march-help.l: Add xcvbitmanip.
		* testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test.
		* testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test.
		* testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test.
		* testsuite/gas/riscv/x-cv-bitmanip.d: New Test.
		* testsuite/gas/riscv/x-cv-bitmanip.s: New Test.

	include/opcode/ChangeLog:
		* riscv-opc.h: Add corresponding MATCH and MASK macros for
		XCVbitmanip.
		* riscv.h: Add corresponding EXTRACT and ENCODE macros for
		XCVbitmanip.
		(enum riscv_insn_class): Add the XCVbitmanip instruction class.

	opcodes/ChangeLog:
		* riscv-dis.c (print_insn_args): Add custom operands `Xc6` and `Xc7`.
		* riscv-opc.c: Add XCvBitmanip instructions.

2024-08-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Add support for Zcmop extension
	This implements the Zcmop (Compressed Zimop) extension, as of version 1.0.

	View detailed information in:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>

	The Zcmop extension requires the Zca extension.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zcmop.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.
		* testsuite/gas/riscv/zcmop.d: New test.
		* testsuite/gas/riscv/zcmop.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zcmop.
		(MATCH_C_MOP_1, MATCH_C_MOP_3, MATCH_C_MOP_5, MATCH_C_MOP_7,
		MATCH_C_MOP_9, MATCH_C_MOP_11, MATCH_C_MOP_13, MATCH_C_MOP_15): Define.
		(MASK_C_MOP_1, MASK_C_MOP_3, MASK_C_MOP_5, MASK_C_MOP_7,
		MASK_C_MOP_9, MASK_C_MOP_11, MASK_C_MOP_13, MASK_C_MOP_15): Ditto.
		* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZCMOP.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zcmop instructions.

2024-08-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Add support for Zimop extension
	This implements the Zimop (May-Be-Operations) extension, as of version 1.0.

	View detailed information in:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zimop
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.
		* testsuite/gas/riscv/zimop.d: New test.
		* testsuite/gas/riscv/zimop.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zimop.
		(MATCH_MOP_R_0, MATCH_MOP_R_1, MATCH_MOP_R_2, MATCH_MOP_R_3,
		MATCH_MOP_R_4, MATCH_MOP_R_5, MATCH_MOP_R_6, MATCH_MOP_R_7,
		MATCH_MOP_R_8, MATCH_MOP_R_9, MATCH_MOP_R_10, MATCH_MOP_R_11,
		MATCH_MOP_R_12, MATCH_MOP_R_13, MATCH_MOP_R_14, MATCH_MOP_R_15,
		MATCH_MOP_R_16, MATCH_MOP_R_17, MATCH_MOP_R_18, MATCH_MOP_R_19,
		MATCH_MOP_R_20, MATCH_MOP_R_21, MATCH_MOP_R_22, MATCH_MOP_R_23,
		MATCH_MOP_R_24, MATCH_MOP_R_25, MATCH_MOP_R_26, MATCH_MOP_R_27,
		MATCH_MOP_R_28, MATCH_MOP_R_29, MATCH_MOP_R_30, MATCH_MOP_R_31,
		MATCH_MOP_RR_0, MATCH_MOP_RR_1, MATCH_MOP_RR_2, MATCH_MOP_RR_3,
		MATCH_MOP_RR_4, MATCH_MOP_RR_5, MATCH_MOP_RR_6, MATCH_MOP_RR_7): Define.
		(MASK_MOP_R_0, MASK_MOP_R_1, MASK_MOP_R_2, MASK_MOP_R_3, MASK_MOP_R_4,
		MASK_MOP_R_5, MASK_MOP_R_6, MASK_MOP_R_7, MASK_MOP_R_8, MASK_MOP_R_9,
		MASK_MOP_R_10, MASK_MOP_R_11, MASK_MOP_R_12, MASK_MOP_R_13,
		MASK_MOP_R_14, MASK_MOP_R_15, MASK_MOP_R_16, MASK_MOP_R_17,
		MASK_MOP_R_18, MASK_MOP_R_19, MASK_MOP_R_20, MASK_MOP_R_21,
		MASK_MOP_R_22, MASK_MOP_R_23, MASK_MOP_R_24, MASK_MOP_R_25,
		MASK_MOP_R_26, MASK_MOP_R_27, MASK_MOP_R_28, MASK_MOP_R_29,
		MASK_MOP_R_30, MASK_MOP_R_31, MASK_MOP_RR_0, MASK_MOP_RR_1,
		MASK_MOP_RR_2, MASK_MOP_RR_3, MASK_MOP_RR_4, MASK_MOP_RR_5,
		MASK_MOP_RR_6, MASK_MOP_RR_7): Ditto.
		* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZIMOP.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zimop instructions.

2024-08-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename gdbarch.c to gdbarch-gen.c
	For clarity and symmetry with `gdbarch-gen.h`.  I wouldn't mind
	if all generated files had the `-gen` suffix.

	Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-08-05  Jan Beulich  <jbeulich@suse.com>

	gas: maintain line numbers correctly after #APP / #NO_APP
	Maintaining line numbers correctly both inside the region and past it
	requires special care. The SB produced there is somewhat different from
	that produced for e.g. macro expansions, and hence also needs treating
	differently: In particular we aren't doing anything resembling macro
	expansion here.

	The new testcase may be a little misplaced in macros/, but that's where
	all the other #APP / #NO_APP ones are.

2024-08-05  Jan Beulich  <jbeulich@suse.com>

	gas: generalize / tighten #APP / #NO_APP recognition
	For one '#' may not be in line_comment_chars[] in the first place. Look
	for just it when it is (these "directives" are akin to C preprocessor
	directives after all), but accept any other line comment character
	otherwise (in read.c further requiring a match on the counterpart
	"directive").

	Then, when in the middle of a file, the constructs should be all on
	their own on a line.  There needs to be a newline ahead of them and
	after them.

	Finally '\n' may not be the only end-of-line character. Accept any (but
	not end-of-statement ones) in read.c, while making sure in input-file.c
	there is one in the first place - merely any kind of whitespace isn't
	good enough.

2024-08-05  Jan Beulich  <jbeulich@suse.com>

	gas: recognize #APP at start-of-physical-line only
	It's not valid to recognize it after mere line separators (often
	semicolon) or after labels, let alone after tc_unrecognized_line()
	perhaps having parsed off parts of a line. It shouldn't even be
	preceded by whitespace, aiui.

	However, keep ignoring line comments as before, for backwards
	compatibility.

2024-08-05  Tom de Vries  <tdevries@suse.de>

	[gdb] Notice when stepping into different file
	Consider the following test-case:
	...
	$ cat -n test.c
	     1	int var;
	     2
	     3	int
	     4	foo (void)
	     5	{
	     6	  var = 1;
	     7	#include "test.h"
	     8	}
	     9
	    10	int
	    11	main ()
	    12	{
	    13	  return foo ();
	    14	}
	$ cat -n test.h
	     1	  return 1;
	$ gcc test.c -g
	...

	When stepping through the test-case, gdb doesn't make it explicit that line 1
	is not in test.c:
	...
	Temporary breakpoint 1, main () at test.c:13
	13	  return foo ();
	(gdb) step
	foo () at test.c:6
	6	  var = 1;
	(gdb) n
	1	  return 1;
	(gdb)
	8	}
	(gdb)
	...
	which makes it easy to misinterpret the output.

	This is with the default "print frame-info" == auto, with documented
	behaviour [1]:
	...
	stepi will switch between source-line and source-and-location depending on the
	program counter.
	...

	What is actually implemented is that source-line is used unless stepping into
	or out of a function.

	The problem can be worked around by using
	"set print frame-info source-and-location", but that's a bit verbose.

	Instead, change the behaviour of "print frame-info" == auto to also use
	source-and-location when stepping into another file, which gets us:
	...
	(gdb) n
	foo () at test.h:1
	1	  return 1;
	...

	Tested on x86_64-linux.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

	PR gdb/32011
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011

	[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo

2024-08-05  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add support for OUTPUT_FORMAT("binary")
	In binary output format, loongarch_elf_hash_table return NULL and result
	in segment fault.

	When ld output binary file, it seems that elf related functions should
	not be called. But loongarch_elf_relax_section be called and
	loongarch_elf_hash_table cause segment fault.

	Just redefined loongarch_elf_hash_table and always return
	link_info->hash.

	The tests of binutils, glibc and gcc is ok.

	0  loongarch_elf_relax_section ()
	1  0x000055555557ab28 in lang_size_sections_1 ()
	2  0x000055555557a16c in lang_size_sections_1 ()
	3  0x000055555557b0a8 in one_lang_size_sections_pass ()
	4  0x000055555557b478 in lang_size_sections ()
	5  0x000055555557e65c in lang_relax_sections ()
	6  0x000055555559f9c8 in ldelf_map_segments ()
	7  0x000055555559783c in gldelf64loongarch_after_allocation ()
	8  0x000055555558dac0 in ldemul_after_allocation ()
	9  0x000055555557f6c0 in lang_process ()
	10 0x0000555555585314 in main ()

2024-08-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-04  Nick Clifton  <nickc@redhat.com>

	Update release-README after completing the 2.43 release.

2024-08-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-03  H.J. Lu  <hjl.tools@gmail.com>

	LTO: Restore the wrapper symbol check for standard function
	Call unwrap_hash_lookup to restore the wrapper symbol check for standard
	function since reference to standard function may not show up in LTO
	symbol table:

	[hjl@gnu-tgl-3 pr31956-3]$ nm foo.o
	00000000 T main
	         U __real_malloc
	00000000 T __wrap_malloc
	[hjl@gnu-tgl-3 pr31956-3]$  lto-dump -list foo.o
	Type   Visibility  Size  Name
	function  default     0  malloc
	function  default     0  __real_malloc
	function  default     3  main
	function  default     5  __wrap_malloc
	[hjl@gnu-tgl-3 pr31956-3]$ make
	gcc -O2 -flto -Wall   -c -o foo.o foo.c
	gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o
	/usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main':
	<artificial>:(.text.startup+0xa): undefined reference to `__wrap_malloc'
	collect2: error: ld returned 1 exit status
	make: *** [Makefile:22: x] Error 1
	[hjl@gnu-tgl-3 pr31956-3]$

	Also add a test to verify that the unused wrapper is removed.

		PR ld/31956
		* plugin.c (get_symbols): Restore the wrapper symbol check for
		standard function.
		* testsuite/ld-plugin/lto.exp: Run the malloc test and the
		unused test.
		* testsuite/ld-plugin/pr31956c.c: New file.
		* testsuite/ld-plugin/pr31956d.c: New file.
		* testsuite/ld-plugin/pr31956d.d: New file.

2024-08-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extension
	Now that all known uses of VLAs within GDB are removed, remove the
	`-Wno-vla-cxx-extension` (which was used to silence clang warnings) and
	add `-Wvla`, such that any use of a VLA will trigger a warning.

	Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025
	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-08-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove uses of VLA
	Remove uses of VLAs, replace with gdb::byte_vector.  There might be more
	in files that I can't compile, but it's difficult to tell without
	actually compiling on all platforms.

	Many thanks to the Linaro pre-commit CI for helping find some problems
	with an earlier iteration of this patch.

	Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-08-02  Guinevere Larsen  <blarsen@redhat.com>

	gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robust
	Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not
	actually compiling the test with some debuginfo in the relevant part,
	and while fixing I noticed that the base assumption of the "some" case
	was wrong, GDB would select some symtab as a default location and the
	test would always fail. This fix makes printing the default location
	only be tested when there is no debuginfo.

	When testing with no debuginfo, if a system had static libc debuginfo,
	the test would also fail. To add an extra layer of robustness to the
	test, this rewrite also strips any stray debuginfo from the executable.
	The test would only fail now if it runs in a system that can't handle
	stripped debuginfo and has static debuginfo pre-installed.

	Reported-By: Tom de Vries <tdevries@suse.de>
	Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove inline_frame::skipped_frames
	While reviewing [1], it occurred to me that having both the
	skipped_frames counter and the skipped_syms vector is redundant.  When
	stepping into an inline frame, we can just pop the last element.

	[1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a

	Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-02  Nick Clifton  <nickc@redhat.com>

	Updated Bulgarian translation for the binutils/ directory

2024-08-02  Aapo Rantalainen  <aapo.rantalainen@gmail.com>

	Fix typo in --help output of the strings program.
	  PR 31940

2024-08-02  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix gdb.python/py-framefilter-invalidarg.exp with clang
	The final test of gdb.python/py-framefilter-invalidarg.exp expected that
	the the backtrace only printed the source file name. However, when using
	clang, gdb will always print the full path to the file, which would
	cause the test to fail. This commit introduces a regexp that optionally
	matches paths, preprended to the file name, which fixes the clang
	failure without introducing gcc failures.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-02  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: extend XFAIL to gdb.fortran/entry-point.exp to clang too
	The test gdb.fortran/entry-point.exp already has an XFAIL when trying to
	set a breakpoint in mod::mod_foo because gcc puts that subprogram in the
	wrong scope in the debug information. Clang's debug information looks
	the same as gcc's, so the test to setup the xfail has been extended to
	also include clang.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-02  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: add build-id compile flag to tests that expect it
	Clang doesn't add build-id information by default, unlike gcc. This
	means that tests that rely on build-id being available and don't
	explicitly add it to the compilation options will fail with clang.
	This commit fixes the fails in gdb.python/py-missing-debug.exp,
	gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp
	and gdb.server/solib-list.exp

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-08-02  Jan Beulich  <jbeulich@suse.com>

	gas: drop unnecessary use of tc_comment_chars
	The override is necessary only when a target needs other than an array
	of const char.

	For cris drop redundant sibling declarations at the same time.

2024-08-02  Jan Beulich  <jbeulich@suse.com>

	gas: correctly deal with line comments when not preprocessing
	Internal naming of functions / data as well as commentary mixes lines
	and statements. It is presumably this confusion which has led to the
	wrong use of ignore_rest_of_line() when dealing with line comments in
	read_a_source_file(). We shall not (silently) produce different output
	depending on whether -f is passed (for suitable input).

	Introduce two new helper macros, intended to be used in favor of open-
	coded accesses to is_end_of_line[]. To emphasize the difference, convert
	ignore_rest_of_line() right away, including adjustments to its comments.

	Since most targets have # in line_comment_chars[], add a target-
	independent test for that, plus an x86-only one also checking for non-#
	to work as intended.

2024-08-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-08-01  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: ginsn: minor improvements in ginsn_dst_print and ginsn_src_print
	Keep the two symmetrical looking.  Makes sense to perform the sanity
	checks similarly too.

	gas/
	        * ginsn.c (ginsn_src_print): Buffer up result of snprintf and
		add sanity checks on the value.
	        (ginsn_dst_print): Use switch case instead.

2024-08-01  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: ginsn: do not emit an unnecessary trailing comma in textual dump
	For ginsns with less than 2 source operands or no destination operands,
	the current textual dump contains a superfluous comma, like the relevant
	testcases show.

	Adjust the code a bit to not emit the lone trailing comma.  Also, adjust
	the aarch64 and x86_64 testcases.

	gas/
	        * ginsn.c (ginsn_src_print): Do not use a trailing comma when
		printing the src of ginsn.
	        (ginsn_print): Check the strlen and prefix a comma before the
		src string.

	gas/testsuite/
		* gas/scfi/aarch64/ginsn-cofi-1.l: Adjust the expected textual
		dump of the ginsn.
		* gas/scfi/x86_64/ginsn-cofi-1.l: Likewise.

2024-08-01  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: x86: ginsn: handle previously missed indirect call and jmp ops
	Some flavors of indirect call and jmp instructions were not being
	handled earlier, leading to a GAS error (#1):
	  (#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI"

	Not handling jmp/call (direct or indirect) ops is an error (as shown
	above) because SCFI needs an accurate CFG to synthesize CFI correctly.
	Recall that the presence of indirect jmp/call, however, does make the
	CFG ineligible for SCFI. In other words, generating the ginsns for them
	now, will eventually cause SCFI to bail out later with an error (#2)
	anyway:
	  (#2) "Error: untraceable control flow for func 'XXX'"

	The first error (#1) gives the impression of missing functionality in
	GAS.  So, it seems cleaner to synthesize a GINSN_TYPE_JUMP /
	GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with
	the error as expected.

	The handling for these indirect jmp/call instructions is similar, so
	reuse the code by carving out a function for the same.

	Adjust the testcase to include the now handled jmp/call instructions as
	well.

	gas/
		* config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New
		function.
		(x86_ginsn_new): Refactor out functionality to above.

	gas/testsuite/
		* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output.
		* gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of
		jmp/call opcodes.

2024-08-01  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add show-debug-regs maintenance command
	This patch register the command "maint set show-debug-regs on/off"
	and make it settable by the user. If show-debug-regs is enabled,
	the debug register values are shown when GDB inserts or removes a
	hardware breakpoint or watchpoint. This is helpful for the use and
	development of hardware watchpoints.

	With this patch, the effect of this maintenance command as follows:

	lihui@bogon:~$ cat test.c
	int a = 0;
	int main()
	{
		a = 1;
		return 0;
	}
	lihui@bogon:~$ gcc -g test.c -o test
	lihui@bogon:~$ gdb test
	...
	(gdb) watch a
	Hardware watchpoint 1: a
	(gdb) maint set show-debug-regs on
	(gdb) r
	Starting program: /home/lihui/test
	...
	...

	prepare_to_resume thread 41525
	...
	insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint):
		BREAKPOINTs:
		BP0: addr=0x0, ctrl=0x00000000, ref.count=0
		BP1: addr=0x0, ctrl=0x00000000, ref.count=0
		BP2: addr=0x0, ctrl=0x00000000, ref.count=0
		BP3: addr=0x0, ctrl=0x00000000, ref.count=0
		BP4: addr=0x0, ctrl=0x00000000, ref.count=0
		BP5: addr=0x0, ctrl=0x00000000, ref.count=0
		BP6: addr=0x0, ctrl=0x00000000, ref.count=0
		BP7: addr=0x0, ctrl=0x00000000, ref.count=0
		WATCHPOINTs:
		WP0: addr=0x0, ctrl=0x00000000, ref.count=0
		WP1: addr=0x0, ctrl=0x00000000, ref.count=0
		WP2: addr=0x0, ctrl=0x00000000, ref.count=0
		WP3: addr=0x0, ctrl=0x00000000, ref.count=0
		WP4: addr=0x0, ctrl=0x00000000, ref.count=0
		WP5: addr=0x0, ctrl=0x00000000, ref.count=0
		WP6: addr=0x0, ctrl=0x00000000, ref.count=0
		WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1
	...
	remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint):
		BREAKPOINTs:
		BP0: addr=0x0, ctrl=0x00000000, ref.count=0
		BP1: addr=0x0, ctrl=0x00000000, ref.count=0
		BP2: addr=0x0, ctrl=0x00000000, ref.count=0
		BP3: addr=0x0, ctrl=0x00000000, ref.count=0
		BP4: addr=0x0, ctrl=0x00000000, ref.count=0
		BP5: addr=0x0, ctrl=0x00000000, ref.count=0
		BP6: addr=0x0, ctrl=0x00000000, ref.count=0
		BP7: addr=0x0, ctrl=0x00000000, ref.count=0
		WATCHPOINTs:
		WP0: addr=0x0, ctrl=0x00000000, ref.count=0
		WP1: addr=0x0, ctrl=0x00000000, ref.count=0
		WP2: addr=0x0, ctrl=0x00000000, ref.count=0
		WP3: addr=0x0, ctrl=0x00000000, ref.count=0
		WP4: addr=0x0, ctrl=0x00000000, ref.count=0
		WP5: addr=0x0, ctrl=0x00000000, ref.count=0
		WP6: addr=0x0, ctrl=0x00000000, ref.count=0
		WP7: addr=0x0, ctrl=0x00000000, ref.count=0

	Hardware watchpoint 1: a

	Old value = 0
	New value = 1
	main () at test.c:5
	5		return 0;
	(gdb)

2024-08-01  Alan Modra  <amodra@gmail.com>

	skip_attr_bytes assertion (data) <= (end) fail
	get_type_abbrev_from_form is lax in not limiting data for a uleb to
	the current CU, because DW_FORM_ref_addr allows access to other CU's
	data.  This can lead to an assertion fail when skipping or reading
	attributes in get_type_signedness.

		* dwarf.c (get_type_abbrev_from_form): Limit uleb data to map end
		for ref_addr, cu_end otherwise.

2024-08-01  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: AArch64: Support MTE on baremetal
	This commit moves aarch64_linux_memtag_matches_p,
	aarch64_linux_set_memtags, aarch64_linux_get_memtag, and
	aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag
	function used by them), along with the setting of the memtag granule
	size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available
	on baremetal targets. Since the aarch64-linux-tdep.c layer inherits
	these hooks from aarch64-tdep.c, there is no effective change for
	aarch64-linux targets.

	Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were
	moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h}
	files.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-08-01  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13
	On fedora rawhide, with python 3.13, I run into:
	...
	(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
	Python Exception <class 'TypeError'>: \
	  this function got an unexpected keyword argument 'invalid'^M
	Error occurred in Python: \
	  this function got an unexpected keyword argument 'invalid'^M
	(gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
	  a_point_t with option invalid=True
	...

	A passing version with an older python version looks like:
	...
	(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
	Python Exception <class 'TypeError'>: \
	  'invalid' is an invalid keyword argument for this function^M
	Error occurred in Python: \
	  'invalid' is an invalid keyword argument for this function^M
	(gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
	  a_point_t with option invalid=True
	...

	Fix this by accepting the updated error message.

	Tested on aarch64-linux.

	PR testsuite/31912
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912

2024-08-01  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix ld FAIL test cases
	To avoid differences in C library paths on different systems
	use gcc instead of ld to perform the test.

	Problems caused by adding options to different distributions
	will not be fixed.

2024-08-01  Mark Harmstone  <mark@harmstone.com>

	ld/PDB: handle empty LF_FIELDLIST types
	Empty structs in C++ lead to empty LF_FIELDLIST types in the .debug$T
	section, but we were mistakenly rejecting these as invalid. Allow
	CodeView types of two bytes, and add a test for this.

2024-08-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix ctf_archive_count return value on big-endian
	This failed to properly byteswap its return value.

	The ctf_archive format predates the idea of "just write natively and
	flip on open", and byteswaps all over the place.  It's too easy to
	forget one.  The next revision of the archive format (not versioned,
	so we just tweak the magic number instead) should be native-endianned
	like the dicts inside it are.

	libctf/
		* ctf-archive.c (ctf_archive_count): Byteswap return value.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: dump: fix small leak
	If you asprintf something and then use it only as input to another asprintf,
	it helps to free it afterwards.

	libctf/
		* ctf-dump.c (ctf_dump_header): Free the flagstr after use.
		(ctf_dump): Make a NULL return slightly clearer.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix ref leak of names of newly-inserted non-root-visible types
	A bug in ctf_dtd_delete led to refs in the string table to the
	names of non-root-visible types not being removed when the DTD
	was.  This seems harmless, but actually it would lead to a write
	down a pointer into freed memory if such a type was ctf_rollback()ed
	over and then the dict was serialized (updating all the refs as the
	strtab was serialized in turn).

	Bug introduced in commit fe4c2d55634c700ba527ac4183e05c66e9f93c62
	("libctf: create: non-root-visible types should not appear in name tables")
	which is included in binutils 2.35.

	libctf/
		* ctf-create.c (ctf_dtd_delete): Remove refs for all types
		with names, not just root-visible ones.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: clean up hashtab error handling mess
	The dict and archive opening code in libctf is somewhat unusual, because
	unlike everything else, it cannot report errors by setting an error on the
	dict, because in case of error there isn't one.  They get passed an error
	integer pointer that is set on error instead.

	Inside ctf_bufopen this is implemented by calling ctf_set_open_errno and
	passing it a positive error value.  In turn this means that most things it
	calls (including init_static_types) return zero on success and a *positive*
	ECTF_* or errno value on error.

	This trickles down to ctf_dynhash_insert_type, which is used by
	init_static_types to add newly-detected types to the name tables.  This was
	returning the error value it received from a variety of functions without
	alteration.  ctf_dynhash_insert conformed to this contract by returning a
	positive value on error (usually OOM), which is unfortunate for multiple
	reasons:

	- ctf_dynset_insert returns a *negative* value
	- ctf_dynhash_insert and ctf_dynset_insert don't take an fp, so the value
	  they return is turned into the errno, so it had better be right, callers
	  don't just check for != 0 here
	- more or less every single caller of ctf_dyn*_insert in libctf other than
	  ctf_dynhash_insert_type (and there are a *lot*, mostly in the
	  deduplicator) assumes that ctf_dynhash_insert returns a negative value
	  on error, even though it doesn't.  In practice the only possible error is
	  OOM, but if OOM does happen we end up with a nonsense error value.

	The simplest fix for this seems to be to make ctf_dynhash_insert and
	ctf_dynset_insert conform to the usual interface contract: negative
	values are errors.  This in turn means that ctf_dynhash_insert_type
	needs to change: let's make it consistent too, returning a negative
	value on error, putting the error on the fp in non-negated form.

	init_static_types_internal adapts to this by negating the error return from
	ctf_dynhash_insert_type, so the value handed back to ctf_bufopen is still
	positive: the new call site in ctf_track_enumerator does not need to change.

	(The existing tests for this reliably detect when I get it wrong.
	I know, because they did.)

	libctf/
		* ctf-hash.c (ctf_dynhash_insert): Negate return value.
		(ctf_dynhash_insert_type): Set de-negated error on the dict:
	        return negated error.
		* ctf-open.c (init_static_types_internal): Adapt to this change.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, include: add ctf_dict_set_flag: less enum dup checking by default
	The recent change to detect duplicate enum values and return ECTF_DUPLICATE
	when found turns out to perturb a great many callers.  In particular, the
	pahole-created kernel BTF has the same problem we historically did, and
	gleefully emits duplicated enum constants in profusion.  Handling the
	resulting duplicate errors from BTF -> CTF converters reasonably is
	unreasonably difficult (it amounts to forcing them to skip some types or
	reimplement the deduplicator).

	So let's step back a bit.  What we care about mostly is that the
	deduplicator treat enums with conflicting enumeration constants as
	conflicting types: programs that want to look up enumeration constant ->
	value mappings using the new APIs to do so might well want the same checks
	to apply to any ctf_add_* operations they carry out (and since they're
	*using* the new APIs, added at the same time as this restriction was
	imposed, there is likely to be no negative consequence of this).

	So we want some way to allow processes that know about duplicate detection
	to opt into it, while allowing everyone else to stay clear of it: but we
	want ctf_link to get this behaviour even if its caller has opted out.

	So add a new concept to the API: dict-wide CTF flags, set via
	ctf_dict_set_flag, obtained via ctf_dict_get_flag.  They are not bitflags
	but simple arbitrary integers and an on/off value, stored in an unspecified
	manner (the one current flag, we translate into an LCTF_* flag value in the
	internal ctf_dict ctf_flags word). If you pass in an invalid flag or value
	you get a new ECTF_BADFLAG error, so the caller can easily tell whether
	flags added in future are valid with a particular libctf or not.

	We check this flag in ctf_add_enumerator, and set it around the link
	(including on child per-CU dicts).  The newish enumerator-iteration test is
	souped up to check the semantics of the flag as well.

	The fact that the flag can be set and unset at any time has curious
	consequences. You can unset the flag, insert a pile of duplicates, then set
	it and expect the new duplicates to be detected, not only by
	ctf_add_enumerator but also by ctf_lookup_enumerator.  This means we now
	have to maintain the ctf_names and conflicting_enums enum-duplication
	tracking as new enums are added, not purely as the dict is opened.
	Move that code out of init_static_types_internal and into a new
	ctf_track_enumerator function that addition can also call.

	(None of this affects the file format or serialization machinery, which has
	to be able to handle duplicate enumeration constants no matter what.)

	include/
		* ctf-api.h (CTF_ERRORS) [ECTF_BADFLAG]: New.
		(ECTF_NERR): Update.
		(CTF_STRICT_NO_DUP_ENUMERATORS): New flag.
		(ctf_dict_set_flag): New function.
		(ctf_dict_get_flag): Likewise.

	libctf/
		* ctf-impl.h (LCTF_STRICT_NO_DUP_ENUMERATORS): New flag.
		(ctf_track_enumerator): Declare.
		* ctf-dedup.c (ctf_dedup_emit_type): Set it.
		* ctf-link.c (ctf_create_per_cu): Likewise.
		(ctf_link_deduplicating_per_cu): Likewise.
		(ctf_link): Likewise.
		(ctf_link_write): Likewise.
		* ctf-subr.c (ctf_dict_set_flag): New function.
		(ctf_dict_get_flag): New function.
		* ctf-open.c (init_static_types_internal): Move enum tracking to...
		* ctf-create.c (ctf_track_enumerator): ... this new function.
		(ctf_add_enumerator): Call it.
		* libctf.ver: Add the new functions.
		* testsuite/libctf-lookup/enumerator-iteration.c: Test them.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	include, libctf: improve ECTF_DUPLICATE error message
	It applies to enums now, so it should mention them.

	include/
		* ctf-api.h (_CTF_ERRORS) ECTF_DUPLICATE]: Mention enums.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: link: remember to turn off the LCTF_LINKING flag after ctf_link_write
	We set this flag at the top of ctf_link_write (to tell ctf_serialize, way
	down under the archive file writing functions, to do the various link- time
	serialization things like symbol filtering and the like), but we never
	remember to clear it except on error.  This is probably bad if you want to
	serialize the dict yourself directly in the future after linking it (which
	is...  definitely a *possible* use of the API, if rather strange).

	libctf/
		* ctf-link.c (ctf_link_write): Clear LCTF_LINKING before exit.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: link: fix error handling
	We were calling the wrong error function if opening failed, causing leaks.

	libctf/
		* ctf-link.c (ctf_link_deduplicating_per_cu): Fix error handling.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, open: Fix enum error handling path
	This new error-handling path was not properly initializing the
	fp's errno.

	libctf/
		* ctf-open.c (init_static_types_internal): Set errno properly.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, subr: don't mix up errors and warnings
	ctf_err_warn() was debug-logging warnings as if they were errors and vice
	versa.

	libctf/
		* ctf-subr.c (ctf_err_warn): Fix debugging thinko.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix dynset insertion
	libctf's dynsets are a straight wrapper around libiberty hashtab, storing
	the key directly in the hashtab slot.  However, we'd often like to be able
	to store 0 and 1 (HTAB_EMPTY_ENTRY and HTAB_DELETED_ENTRY) in there, so we
	move them out of the way and replace them with huge unlikely values
	instead.  Unfortunately we failed to do this replacement in one place, so
	insertion of 0 or 1 ended up misinforming the hashtab machinery that an
	entry was empty or deleted when it wasn't.

	libctf/
		* ctf-hash.c (ctf_dynset_insert): Call key_to_internal properly.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: dedup: tiny tweaks
	Drop an unnecessary variable, and fix a buggy comment.

	No effect on generated code.

	libctf/
		* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Drop unnecessary
	        variable.
		(ctf_dedup_rwalk_output_mapping): Fix comment.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: improve ECTF_NOPARENT error message
	This erorr doesn't just indicate that there is no parent dictionary
	(that's routine, and true of all dicts that are parents themselves)
	but that a parent is *needed* but wasn't found.

	include/
		* ctf-api.h (_CTF_ERRORS) [ECTF_NOPARENT]: Improve error message.

	ld/
		* testsuite/ld-ctf/diag-parname.d: Adjust.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix CTF dict compression
	Commit 483546ce4f3 ("libctf: make ctf_serialize() actually serialize")
	accidentally broke dict compression.  There were two bugs:

	 - ctf_arc_write_one_ctf was still making its own decision about
	   whether to compress the dict via direct ctf_size comparison, which is
	   unfortunate because now that it no longer calls ctf_serialize itself,
	   ctf_size is always zero when it does this: it should let the writing
	   functions decide on the threshold, which they contain code to do which is
	   simply not used for lack of one trivial wrapper to write to an fd and
	   also provide a compression threshold

	 - ctf_write_mem, the function underlying all writing as of the commit
	   above, was calling zlib's compressBound and avoiding compression if this
	   returned a value larger than the input.  Unfortunately compressBound does
	   not do a trial compression and determine whether the result is
	   compressible: it just adds zlib header sizes to the value passed in, so
	   our test would *always* have concluded that the value was incompressible!
	   Avoid by simply always compressing if the raw size is larger than the
	   threshold: zlib is quite clever enough to avoid actually compressing
	   if the data is incompressible.

	Add a testcase for this.

	libctf/
		* ctf-impl.h (ctf_write_thresholded): New...
		* ctf-serialize.c (ctf_write_thresholded): ... defined here,
	        a wrapper around...
	        (ctf_write_mem): ... this.  Don't check compressibility.
		(ctf_compress_write): Reimplement as a ctf_write_thresholded
	        wrapper.
		(ctf_write): Likewise.
		* ctf-archive.c (arc_write_one_ctf): Just call
	        ctf_write_thresholded rather than trying to work out whether
	        to compress.
		* testsuite/libctf-writable/ctf-compressed.*: New test.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix linking of non-root-visible types
	If you deduplicate non-root-visible types, the resulting type should still
	be non-root-visible! We were promoting all such types to root-visible, and
	re-demoting them only if their names collided (which might happen on
	cu-mapped links if multiple compilation units with conflicting types are
	fused into one child dict).

	This "worked" before now, in that linking at least didn't fail (if you don't
	mind having your non-root flag value destroyed if you're adding
	non-root-visible types), but now that conflicting enumerators cause their
	containing enums to become conflicted (enums which might have *different
	names*), this caused the linker to crash when it hit two enumerators with
	conflicting values.

	Not testable in ld because cu-mapped links are not exposed to ld, but can be
	tested via direct creation of libraries and calls to ctf_link directly.
	(This also tests the ctf_dump non-root type printout, which before now
	was untested.)

	libctf/
		* ctf-dedup.c (ctf_dedup_emit_type): Non-root-visible input types
		should be emitted as non-root-visible output types.
		* testsuite/libctf-writable/ctf-nonroot-linking.c: New test.
		* testsuite/libctf-writable/ctf-nonroot-linking.lk: New test.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, dump: correctly dump non-root-visible types
	The flag test when dumping non-root-visible tyeps was doubly wrong: the
	flags word is a *bitfield* containing CTF_ADD_ROOT as one possible
	value, so needs | and & testing, not just ==, and CTF_ADD_NONROOT is 0,
	so cannot be tested for this way: one must check for the non-presence of
	CTF_ADD_ROOT.

	libctf/
		* ctf-dump.c (ctf_dump_format_type): Fix non-root flag test.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, string: split the movable refs out of the ref list
	In commit 149ce5c263616e65 we introduced the concept of "movable" refs,
	which are refs that can be moved in batches, to let us maintain valid ref
	lists even when adding refs to blocks of memory that can be realloced (which
	is any type containing a vlen which can expand, like names contained within
	enum or struct members).  Movable refs need a backpointer to the movable
	refs dynhash for this dict; since non-movable refs are very common, we tried
	to save memory by having a slightly bigger struct for moveable refs with a
	backpointer in it, and casting appropriately, indicating which sort of ref
	we were dealing with via a flag on the atom.

	Unfortunately this doesn't work reliably, because you can perfectly well
	have a string ("foo", say) which has both non-movable refs (say, an external
	symbol and a variable name) and movable refs (say, a structure member name)
	to the same atom.  Indicate which struct we're dealing with with an atom
	flag and suddenly you're casting a ctf_str_atom_ref to a
	ctf_str_atom_ref_movable (which is bigger) and dereferencing random memory
	off the end of it and interpreting it as a backpointer to the movable refs
	dynhash.  This is unlikely to work well.

	So bite the bullet and split refs into two separate lists, one for movable
	refs, one for immovable refs. It means some annoying code duplication, but
	there's not very much of it, and it means we can keep the movable refs
	hashtab (which in turn means we don't have to do linear searches to find all
	relevant refs when moving refs, which in turn means that
	structure/union/enum member additions remain amortized O(n) time, not
	O(n^2).

	Callers can now purge movable and non-movable refs independently of each
	other.  We don't use this yet, but a use is coming.

	libctf/
		* ctf-impl.h (CTF_STR_ATOM_MOVABLE): Delete.
	        (struct ctf_str_atom) [csa_movable_refs]: New.
		(struct ctf_dict): Adjust comment.
		(ctf_str_purge_refs): Add MOVABLE arg.
		* ctf-string.c (ctf_str_purge_movable_atom_refs): Split out of...
	        (ctf_str_purge_atom_refs): ... this.
		(ctf_str_free_atom): Call it.
		(ctf_str_purge_one_atom_refs): Likewise.
		(aref_create): Adjust accordingly.
		(ctf_str_move_refs): Likewise.
		(ctf_str_remove_ref): Remove movable refs too, including
		deleting the ref from ctf_str_movable_refs.
		(ctf_str_purge_refs): Add MOVABLE arg.
		(ctf_str_update_refs): Update movable refs.
		(ctf_str_write_strtab): Check, and purge, movable refs.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf, dedup: drop unnecessary arg from ctf_dedup()
	The PARENTS arg is carefully passed down through all the layers of hash
	functions and then never used for anything.  (In the distant past it was
	used for cycle detection, but the algorithm eventually committed doesn't
	need to do cycle detection...)

	The PARENTS arg is still used by ctf_dedup_emit(), but even there we can
	loosen the requirements and state that you can just leave entries
	corresponding to dicts with no parents at zero (which will be useful
	in an upcoming commit).

	libctf/
		* ctf-dedup.c (ctf_dedup_hash_type): Drop PARENTS arg.
		(ctf_dedup_rhash_type): Likewise.
		(ctf_dedup): Likewise.
		(ctf_dedup_emit_struct_members): Mention what you can do to
	        PARENTS entries for parent dicts.
		* ctf-impl.h (ctf_dedup): Adjust accordingly.
		* ctf-link.c (ctf_link_deduplicating_per_cu): Likewise.
		(ctf_link_deduplicating): Likewise.

2024-07-31  Nick Alcock  <nick.alcock@oracle.com>

	libctf: we do in fact support foreign-endian old versions
	The worry that caused this to not be supported was because we don't
	bother endian-flipping version-related fields before checking them.
	But they're all unsigned chars anyway, and don't need any flipping at
	all.

	This should be supported and should already work.  Enable it.

	libctf/
		* ctf-open.c (ctf_bufopen): Don't prohibit foreign-endian
	        upgrades.

2024-07-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix trailing-text-in-parentheses duplicates
	Fix all trailing-text-in-parentheses duplicates exposed by previous patch.

	Tested on x86_64-linux and aarch64-linux.

2024-07-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Detect trailing-text-in-parentheses duplicates
	When using a duplicate test name:
	...
	fail foo
	fail foo
	...
	we get:
	...
	FAIL: $exp: foo
	FAIL: $exp: foo
	DUPLICATE: $exp: foo
	...

	But when we do:
	...
	fail foo
	fail "foo (timeout)"
	...
	we get only:
	...
	FAIL: $exp: foo
	FAIL: $exp: foo (timeout)
	...

	Trailing text between parentheses prefixed with a space is interpreted as
	extra information, and not as part of the test name [1].

	Consequently, "foo" and "foo (timeout)" do count as duplicate test names,
	which should have been detected.  This is PR testsuite/29772.

	Fix this in CheckTestNames::_check_duplicates, such that we get:
	...
	FAIL: $exp: foo
	FAIL: $exp: foo (timeout)
	DUPLICATE: $exp: foo (timeout)
	...

	[ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't
	know whether that covers all required cases, due to the fact that those are
	not unambiguousely specified.  It might be possible to reverse-engineer that
	information by reading or running the "regression analysis tools" mentioned on
	the wiki page [1], but I haven't been able to.  Regardless, the current regexp
	covers a large amount of cases, which IMO should be sufficient to be
	acceptable. ]

	Doing so shows many new duplicates in the testsuite.

	A significant number of those is due to using a message which is a copy of the
	command:
	...
	gdb_test "print (1)"
	...

	Fix this by handling those cases using test names "gdb-command<print (1)>" and
	"gdb-command<print (2)>.

	Fix the remaining duplicates manually (split off as follow-up patch for
	readability of this patch).

	Tested on x86_64-linux and aarch64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772

	[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages

2024-07-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.python/py-disasm-{exec,obj}.exp
	I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a
	s390x machine, but when running with target board unix/-m31 I saw that the
	required libraries were missing, so I couldn't generate an executable.

	However, I realized that I did have an object file, and the test-case should
	mostly also work with an object file.

	I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and
	included it from two new minimal test-case wrappers:
	- gdb.python/py-disasm-exec.exp, and
	- gdb.python/py-disasm-obj.exp
	where the former uses an executable as before, and the latter uses an object
	file.

	Using an object file required changing the info.read_memory calls in
	gdb.python/py-disasm.py:
	...
	-            info.read_memory(1, -info.address + 2)
	+            info.read_memory(1, -info.address - 1)
	...
	because reading from address 2 succeeds.  Using address -1 instead does
	generate the expected gdb.MemoryError.

	Tested on x86_64-linux.

2024-07-31  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Fix gdb.fortran/intrinsics.exp fail on arm
	When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get:
	...
	(gdb) p cmplx (4,4,16)^M
	/home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \
	  Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M
	A problem internal to GDB has been detected,^M
	further debugging may prove unreliable.^M
	----- Backtrace -----^M
	FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error)
	...

	The problem is that 16-byte floats are unsupported:
	...
	$ gfortran test.f90
	test.f90:2:17:

	    2 |     REAL(kind=16) :: foo = 1
	      |                 1
	Error: Kind 16 not supported for type REAL at (1)
	...
	and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with
	code TYPE_CODE_ERROR.

	Fix this by bailing out asap when encountering such a type.

	Without this patch we're able to do the rather useless:
	...
	(gdb) ptype real*16
	type = real*16
	(gdb) ptype real_16
	type = real*16
	...
	but with this patch we get:
	...
	(gdb) ptype real*16
	unsupported kind 16 for type real*4
	(gdb) ptype real_16
	unsupported type real*16
	...

	Tested on arm-linux.

	PR fortran/30537
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537

2024-07-31  Jan Beulich  <jbeulich@suse.com>

	x86: move ginsn stuff
	This had been badly inserted between md_assemble() and its helpers
	anyway. Follow what was done for Arm64 and move the code to its own
	file, #include-d as appropriate.

	gas/doc: adjust an @xref
	Old doc tools warn about there not being a . or , following; satisfy
	those tools by shortening the line and adding a full stop.

2024-07-31  Alan Modra  <amodra@gmail.com>

	fix the framework error
	Running the testsuite for an x86_64-w64-mingw32 target using the
	Ubuntu package gcc-mingw-w64-x86-64 version 13.2.0-6ubuntu1+26.1
	results in a number of messages:
	ERROR: can't decipher gcc version number, fix the framework!

	Someone in their wisdom decided this compiler should advertise itself
	with a version of 13-win32, breaking the ld testsuite version checks.
	(It is also configured using --with-as=/usr/bin/x86_64-w64-mingw32-as
	--with-ld=/usr/bin/x86_64-w64-mingw32-ld which renders the -B flag
	inoperative for testing the newly built gas and ld.  You'd need to
	install binutils over the top of the Ubuntu versions before testing, a
	rather unsatisfactory process.)

		* testsuite/lib/ld-lib.exp (at_least_gcc_version): Use
		preprocessor test of __GNUC__ and __GNUC_MINOR__ rather than
		output of gcc --version.  Correct removal of -Wl options.

2024-07-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some more
	When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie),
	I run into:
	...
	Expecting: ^(-var-create A_String_Access \* A_String_Access[
	]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[
	]+[(]gdb[)]
	[ ]*)
	-var-create A_String_Access * A_String_Access
	^error,msg="Cannot access memory at address 0x4"
	(gdb)
	FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
	...

	This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite]
	Fix regexp in gdb.ada/mi_var_access.exp").

	The problem in both cases is that we're printing an uninitialized variable,
	and consequently we can run into various error messages during printing.

	Fix this as in the other commit, by accepting the error message.

	Tested on arm-linux.

2024-07-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't call macro_bcache with nullptr
	Since commit b1da98a74656 ("gdb: remove use of alloca in
	new_macro_definition"), if cached_argv is empty, we call macro_bcache
	with a nullptr data.  This ends up caught by UBSan deep down in the
	bcache code:

	    $ ./gdb -nx -q --data-directory=data-directory  /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow
	    Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
	    Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
	    /home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null

	The backtrace:

	    #1  0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750
	    #2  0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195
	    #3  0x0000555564b49222 in gdb::bcache::insert<char const*, void> (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158
	    #4  0x0000555564b481fa in macro_bcache<char const*> (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117
	    #5  0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573
	    #6  0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777
	    #7  0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816
	    #8  0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203

	This can be reproduced by running gdb.base/macscp.exp.  Avoid calling
	macro_bcache if the macro doesn't have any arguments.

	Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d

2024-07-30  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 32018 Compilation of binutils 2.43 failed on CentOS 6
	strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7.
	In this case, we may not use our CALL_UTIL macro for strchr.
	Use __collector_strchr instead of "CALL_UTIL (strchr)".

	gprofng/ChangeLog
	2024-07-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 32018
		* libcollector/hwprofile.c (open_experiment): Use __collector_strchr.

2024-07-30  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Emit malformed macro definition complaint once
	Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
	.debug_macro section.

	For one malformed macro definition, I get two identical complaints:
	...
	During symbol reading: macro debug info contains a malformed macro definition:^M
	`M1_11_MALFORMED(ARG'^M
	During symbol reading: macro debug info contains a malformed macro definition:^M
	`M1_11_MALFORMED(ARG'^M
	...

	Fix this by bailing out after the first one.

	Tested on aarch64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-07-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove use of alloca in new_macro_definition
	Replace alloca with std::vector.

	Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c
	Approved-By: Tom de Vries <tdevries@suse.de>

2024-07-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use std::string vector for macro definition
	Use std::vector<std::string> when defining macros, to avoid the manual
	memory management.

	With the use of std::vector, the separate `int argc` parameter is no
	longer needed, we can use the size of the vector instead.  However, for
	some functions, this parameter had a dual function.  For object-like
	macros, it was interpreted as a `macro_special_kind` enum.  For these
	functions, remove `argc`, but add a new `special_kind` parameter.

	Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5
	Approved-By: Tom de Vries <tdevries@suse.de>

2024-07-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: move @anchor off @item line
	When building the GDB info manual I see this warning:

	  gdb.texinfo:41447: warning: @anchor should not appear on @item line

	And indeed line 41447 looks like this:

	  @item @anchor{maint info breakpoints}maint info breakpoints

	I propose moving the @anchor{...} part to the previous line which
	silences the warning.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-07-30  Lulu Cai  <cailulu@loongson.cn>

	gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.43

2024-07-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-29  Alexandra Hájková  <ahajkova@redhat.com>

	Add a test for the gcore script
	It also tests the gcore script being run without its accessible
	terminal.

	This test was written by Jan Kratochvil a long time ago. I modernized
	the test making it use various procs from lib/gdb.exp, reorganizing it
	and added some comments.

	Modify the gcore script to make it possible to pass the --data-directory to
	it. This prevents a lot of these warnings:

	Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
	'_handle_missing_debuginfo'

	Tested by using make check-all-boards.

	Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-07-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0
	When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we
	run into:
	...
	(gdb) save gdb-index index_1^M
	Error while writing index for `xgdb': No debugging symbols^M
	(gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file
	...

	Fix this by instead emitting an unsupported, and bailing out.

	Tested on aarch64-linux.

2024-07-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.exp
	When running test-case gdb.threads/leader-exit-attach.exp with target board
	native-extended-gdbserver I run into:
	...
	(gdb) KFAIL: $exp: attach (PRMS: gdb/31555)
	print $_inferior_thread_count^M
	$1 = 0^M
	(gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554)
	...

	The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc
	("Fix "attach" failure handling with GDBserver"), and consequently the PR is
	closed.

	Fix this by removing the corresponding kfail.

	Tested on x86_64-linux.

2024-07-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1
	With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into:
	...
	(gdb) attach 18591^M
	Attaching to program: leader-exit-attach, process 18591^M
	warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555)
	^M
	ptrace: Operation not permitted.^M
	(gdb) FAIL: $exp: get valueof "$_inferior_thread_count"
	...

	The problem is that the gdb_test_multiple in the test-case doesn't consume the
	prompt in all clauses:
	...
	gdb_test_multiple "attach $testpid" "attach" {
	    -re "Attaching to process $testpid failed.*" {
		# GNU/Linux gdbserver.  Linux ptrace does not let you attach
		# to zombie threads.
		setup_kfail "gdb/31555" *-*-linux*
		fail $gdb_test_name
	    }
	    -re "warning: process $testpid is a zombie - the process has already terminated.*" {
		# Native GNU/Linux.  Linux ptrace does not let you attach to
		# zombie threads.
		setup_kfail "gdb/31555" *-*-linux*
		fail $gdb_test_name
	    }
	    -re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
		pass $gdb_test_name
		set attached 1
	    }
	}
	...

	Fix this by using -wrap in the first two clauses.

	While we're at it, also use -wrap in the third clause.

	Tested on x86_64-linux.

2024-07-29  Nick Clifton  <nickc@redhat.com>

	Updated translations for the bfd, binutils, gas, ld and opcodes directories

2024-07-29  Alan Modra  <amodra@gmail.com>

	Fixes to "PR 31728 testcases"
	This brings us down to just these fails for the set of targets I
	usually test when making testsuite changes.
	aarch64-pe  +FAIL: ld-pe/symbols-ordinals-hints-imports-ld
	arm-pe  +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool
	arm-pe  +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool

	The aarch64 one is likely due to the target missing support somewhere.
	It is fairly new, I haven't investigated.  The arm-pe fails are due to
	arm-pe being a target that adds underscores to symbol names (see
	config.bfd) whereas dlltool thinks it does not (see
	dlltool.c:asm_prefix).  arm-wince-pe on the other hand doesn't add
	underscores.  I would guess the right fix for dlltool is to get this
	symbol info from bfd using bfd_get_target_info.

	Note I'm not very happy about the creative use of ld_after_inputfile
	in symbols-ordinals-hints-imports-ld.d, which is likely to break with
	some future run_dump_test change.

2024-07-29  Pali Rohár  <pali@kernel.org>

	PR 31728 testcases

2024-07-29  Alan Modra  <amodra@gmail.com>

	PR32032 dwp segfaults on hello world binary
	Fixing the segfault is easy with this bandaid, but further work is
	needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header.
	At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id.

		PR 32032
		* dwp.cc (Dwp_output_file::finalize): Return immediately on
		no output file.

2024-07-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: track if a caching proc calls gdb_exit or not
	After a recent patch review I asked myself why can_spawn_for_attach
	exists.  This proc currently does some checks, and then calls
	can_spawn_for_attach_1 which is an actual caching proc.

	The answer is that can_spawn_for_attach exists in order to call
	gdb_exit the first time can_spawn_for_attach is called within any test
	script.

	The reason this is useful is that can_spawn_for_attach_1 calls
	gdb_exit.  If the user calls can_spawn_for_attach_1 directly then a
	problem might exist.  Imagine a test written like this:

	  gdb_start

	  if { [can_spawn_for_attach_1] } {
	    ... do stuff that assumes GDB is running ...
	  }

	If this test is NOT the first test run, and if an earlier test calls
	can_spawn_for_attach_1, then when the above test is run the
	can_spawn_for_attach_1 call will return the cached value and gdb_exit
	will not be called.

	But, if the above test IS the first test run then
	can_spawn_for_attach_1 will not return the cached value, but will
	instead compute the cached value, a process that ends up calling
	gdb_exit.  When can_spawn_for_attach_1 returns GDB will have exited
	and the test might fail if it is written assuming that GDB is
	running.

	So can_spawn_for_attach was added which ensures that we _always_ call
	gdb_exit the first time can_spawn_for_attach is called within a single
	test script, this ensures that in the above case, even if the above is
	not the first test script run, gdb_exit will still be called.  This
	ensures consistent behaviour and avoids some hidden bugs in the
	testsuite.

	The split between can_spawn_for_attach and can_spawn_for_attach_1 was
	introduced in this commit:

	  commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f
	  Date:   Mon May 6 14:27:09 2024 +0200

	      [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach

	However, I observe that can_spawn_for_attach is not the only caching
	proc that calls gdb_exit.  Why does can_spawn_for_attach get special
	treatment when surely the same issue exists for any other caching proc
	that calls gdb_exit?

	I think a better solution is to move the logic from
	can_spawn_for_attach into cache.exp and generalise it so that it
	applies to all caching procs.

	This commit does this by:

	 1. When the underlying caching proc is executed we track calls to
	    gdb_exit.  If a caching proc calls gdb_exit then this information
	    is stored in gdb_data_cache (using a ',exit' suffix), and also
	    written to the cache file if appropriate.

	 2. When a cached value is returned from gdb_do_cache, if the
	    underlying proc would have called gdb_exit, and if this is the
	    first use of the caching proc in this test script, then we call
	    gdb_exit.

	When storing the ',exit' value into the on-disk cache file, the flag
	value is stored on a second line.  Currently every cached value only
	occupies a single line, and a check is added to ensure this remains
	true in the future.

	To track calls to gdb_exit I eventually settled on using TCL's trace
	mechanism.  We already make use of this in lib/gdb.exp so I figure
	this is OK to use.  This should be fine, so long as non of the caching
	procs use 'with_override' to replace gdb_exit, or do any other proc
	replacement to change gdb_exit, however, I think that is pretty
	unlikely.

	One issue did come up in testing, a FAIL in gdb.base/break-interp.exp,
	prior to this commit can_spawn_for_attach would call gdb_exit before
	calling the underlying caching proc.  After this call we call gdb_exit
	after calling the caching proc.

	The underlying caching proc relies on gdb_exit having been called.  To
	resolve this issue I just added a call to gdb_exit into
	can_spawn_for_attach.

	With this done can_spawn_for_attach_1 can be renamed to
	can_spawn_for_attach, and the existing can_spawn_for_attach can be
	deleted.

2024-07-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: restructure gdb_data_cache (lib/cache.exp)
	In the next commit I want to add more information to
	gdb_data_cache (see lib/cache.exp).  Specifically I want to track if
	the underlying function of a caching proc calls gdb_exit or not.

	Currently gdb_data_cache is an associative array, the keys of which
	are the name of the caching proc.

	In this commit I add a ',value' suffix to the gdb_data_cache keys.  In
	the next commit I'll add additional entries with a different suffix.

	There should be no noticable changes after this commit, this is just a
	restructuring.

2024-07-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-27  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix arm thumb2 hw breakpoint
	On an aarch64-linux system with 32-bit userland running in a chroot, and using
	target board unix/mthumb I get:
	...
	(gdb) hbreak hbreak.c:27^M
	Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
	(gdb) PASS: gdb.base/hbreak.exp: hbreak
	continue^M
	Continuing.^M
	Unexpected error setting breakpoint: Invalid argument.^M
	(gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
	...
	due to this call in arm_linux_nat_target::low_prepare_to_resume:
	...
	          if (ptrace (PTRACE_SETHBPREGS, pid,
	              (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
	            perror_with_name (_("Unexpected error setting breakpoint"));
	...

	This problem does not happen if instead we use a 4-byte aligned address.

	This may or may not be a kernel bug.

	Work around this by first using an inoffensive address bpts[i].address & ~0x7.

	Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on
	target board native-gdbserver/mthumb.

	While we're at it:
	- use arm_hwbp_control_is_initialized in
	  arm_linux_nat_target::low_prepare_to_resume,
	- handle the !arm_hwbp_control_is_initialized case explicitly,
	- add missing '_()' in arm_target::low_prepare_to_resume,
	- make error messages identical between arm_target::low_prepare_to_resume and
	  arm_linux_nat_target::low_prepare_to_resume,
	- factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to
	  make the implementation more readable.

	Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in
	gdb.base/hbreak.exp") by simply reverting the commit.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-07-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-26  YunQiang Su  <yunqiang.su@cipunited.com>

	microMIPS: Add MT ASE instruction set support
	Add the MT ASE instruction operand types and encodings to the microMIPS
	opcode table and enable the assembly of these instructions in GAS from
	MIPSr2 onwards.  Update the binutils and GAS testsuites accordingly.

	References:

	"MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for
	the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number:
	MD00768, Revision 1.12, July 16, 2013

	Co-Authored-By: Maciej W. Rozycki <macro@redhat.com>

2024-07-26  Nick Clifton  <nickc@redhat.com>

	Fix "Untranslated plural in readelf.c"
	  PR 32002

2024-07-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix build-id compile option when used with clang
	It was pointed out in this message:

	  https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com

	That the test gdb.base/build-id-seqno.exp I added recently was FAILing
	when using Clang as the compiler.

	The problem was that I had failed to add 'build-id' as a compile
	option in the call to build_executable within the test script.  For
	GCC this is fine as build-ids are included by default.  For Clang
	though this meant the build-id was not included and the test would
	fail.

	So I added build-id to the compiler options.... and the test still
	didn't pass!  Now the test fails to compile and I see this error from
	the compiler:

	  gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \
	        input unused [-Wunused-command-line-argument]

	It turns out that the build-id compile option causes our gdb.exp to
	add the '-Wl,--build-id' option into the compiler flags, which means
	its used when building the object file AND during the final link.
	However this option is unnecessary when creating the object file and
	Clang warns about this, which causes the build to fail.

	The solution is to change gdb.exp, instead of adding the build-id
	flags like this:

	  lappend new_options "additional_flags=-Wl,--build-id"

	we should instead add them like:

	  lappend new_options "ldflags=-Wl,--build-id"

	Now the flag is only appended during the link phase and Clang is
	happy.  The gdb.base/build-id-seqno.exp test now passes with Clang.

	The same problem (adding to additional_flags instead of ldflags)
	exists for the no-build-id compile option, so I've fixed that too.

	While investigating this I also spotted two test scripts,
	gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were
	setting ldflag directly rather than using the build-id compile option
	so I've updated these two tests to use the compile option which I
	think is neater.

	I've checked that all these tests still pass with both GCC and Clang.

	There should be no changes in what is actually tested after this
	commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-07-26  Jan Beulich  <jbeulich@suse.com>

	gas: correct sb_add_char() 2nd parameter type
	It's entirely unclear why size_t was used there; my only guess is copy-
	and-paste from another of the functions.

2024-07-26  Jan Beulich  <jbeulich@suse.com>

	gas: drop scrubber state -2
	Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring
	that we wouldn't get bogus state transitions: For example, when we're in
	states 0 or 1, a comment should be no different from whitespace
	encountered in those states. Plus for e.g. x86 this results in such
	comments now truly being converted to a blank, as mandated by
	documentation. Both aspects apparently were a result of blindly (and
	wrongly) moving to state 3 _before_ consuming the "ungot" blank.

	Also amend a related comment elsewhere.

	In the new testcase the .irp is to make visible in the listing all the
	whitespace that the scrubber inserts / leaves in place.

2024-07-26  Jan Beulich  <jbeulich@suse.com>

	x86: accept whitespace around prefix separator
	... and prediction suffix comma. Other than documented /**/ comments
	currently aren't really converted to a single space, at least not for
	x86 in its most common configurations. That'll be fixed subsequently, at
	which point blanks may appear where so far none were expected.
	Furthermore not permitting blanks around these separators wasn't quite
	logical anyway - such constructs are composite ones, and hence
	components ought to have been permitted to be separated by whitespace
	from the very beginning. Furthermore note how, due to the scrubber being
	overly aggressive in removing whitespace, some similar construct with a
	prefix were already accepted.

	Note how certain other checks in parse_insn() can be simplified as a
	result.

	While there for the prediction suffix also make checks case-insensitive
	and check for a proper trailing separator.

2024-07-26  Jan Beulich  <jbeulich@suse.com>

	x86/APX: optimize certain {nf}-form insns to BMI2 ones
	..., as those leave EFLAGS untouched anyway. That's a shorter encoding,
	available as long as no eGPR is in use anywhere.

2024-07-26  Alan Modra  <amodra@gmail.com>

	Remove srcdir from x86 testcase "source:" lines
	It's wrong to have ${srcdir} in run_dump_test "source:" lines, as
	run_dump_test adds $srcdir/$subdir/ to the line passed to the shell
	except when the source path starts with "./".  The tests work
	currently because the shell expands ${srcdir} to an empty string.

		PR 31728
		* testsuite/ld-i386/code16.d: Correct "source:".
		* testsuite/ld-x86-64/code16.d: Likewise.
		* testsuite/ld-x86-64/rela.d: Likewise.

2024-07-26  Alan Modra  <amodra@gmail.com>

	ARM print_insn_mve assertion
	This corrects objdump -d -m armv8.1-m.main output for a testcase found
	by oss-fuzz, .inst 0xee2fee79, which hits an assertion.

	Obviously the switch case constants should be binary, not hex.
	Correcting that is enough to cure this assertion, but I don't see any
	point in singling out the invalid case 0b10.  In fact, it is just plain
	wrong to print "undefined instruction: size equals zero    undefined
	instruction: size equals two".

	I also don't see the need for defensive programming here as is done
	elsewhere in checking that "value" is in range before indexing
	mve_vec_sizename.  There is exactly one MVE_VSHLL_T2 entry in
	mve_opcodes.  It is easy to verify that "value" is only two bits.

2024-07-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amdgpu: remove unused includes
	Remove two includes reported as unused by clangd.

	Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e

2024-07-25  H.J. Lu  <hjl.tools@gmail.com>

	x86: Add missing newlines in TLS transition error messages
	Change TLS transition error messages from

	a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV onlyld: final link failed: bad value

	to

	a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV only
	ld: final link failed: bad value

		PR ld/32017
		* elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error):
		Add missing newlines.

2024-07-25  H.J. Lu  <hjl.tools@gmail.com>

	x86: Improve TLS transition error check
	Provide detailed TLS transition errors when unsupported instructions are
	used.  Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as
	R_X86_64_GOTTPOFF when performing TLS transition.

	bfd/

		PR ld/32017
		* elf32-i386.c (elf_i386_check_tls_transition): Return different
		enums for different errors.
		(elf_i386_tls_transition): Change argument from r_symndx to sym.
		Call _bfd_x86_elf_link_report_tls_transition_error to report TLS
		transition errors.
		(elf_i386_scan_relocs): Pass isym instead of r_symndx to
		elf_i386_tls_transition.
		(elf_i386_relocate_section): Pass sym instead of r_symndx to
		elf_i386_tls_transition.
		* elf64-x86-64.c (elf_x86_64_check_tls_transition): Return
		different enums for different errors.
		(elf_x86_64_tls_transition): Change argument from r_symndx to sym.
		Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as
		R_X86_64_GOTTPOFF.  Call
		_bfd_x86_elf_link_report_tls_transition_error to report TLS
		transition errors.
		(elf_x86_64_scan_relocs): Pass isym instead of r_symndx to
		elf_x86_64_tls_transition.
		(elf_x86_64_relocate_section): Pass sym instead of r_symndx to
		elf_x86_64_tls_transition.
		* elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): New.
		* elfxx-x86.h (elf_x86_tls_error_type): Likewise.
		(_bfd_x86_elf_link_report_tls_transition_error): Likewise.

	ld/

		PR ld/32017
		* testsuite/ld-i386/i386.exp: Run tlsgdesc1 and tlsgdesc2.
		* testsuite/ld-i386/tlsie2.d: Updated.
		* testsuite/ld-i386/tlsie3.d: Likewise.
		* testsuite/ld-i386/tlsie4.d: Likewise.
		* testsuite/ld-i386/tlsie5.d: Likewise.
		* testsuite/ld-x86-64/tlsie2.d: Likewise.
		* testsuite/ld-x86-64/tlsie3.d: Likewise.
		* testsuite/ld-i386/tlsgdesc1.d: New file.
		* testsuite/ld-i386/tlsgdesc1.s: Likewise.
		* testsuite/ld-i386/tlsgdesc2.d: Likewise.
		* testsuite/ld-i386/tlsgdesc2.s: Likewise.
		* testsuite/ld-x86-64/tlsdesc3.d: Likewise.
		* testsuite/ld-x86-64/tlsdesc3.s: Likewise.
		* testsuite/ld-x86-64/tlsdesc4.d: Likewise.
		* testsuite/ld-x86-64/tlsdesc4.s: Likewise.
		* testsuite/ld-x86-64/tlsie5.d: Likewise.
		* testsuite/ld-x86-64/tlsie5.s: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run tlsie5, tlsdesc3 and
		tlsdesc4.

2024-07-25  Nick Clifton  <nickc@redhat.com>

	Add /usr/lib32 to the native search paths for FreeBSD systems.
	  PR 31395

2024-07-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-24  Tom Tromey  <tromey@adacore.com>

	Remove redundant macro definitions from remote.c
	I happened to notice that a few macros are defined twice in remote.c.
	This patch removes one copy.  Tested by rebuilding.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-07-24  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Fix ptype $_creal/$_cimag
	Consider test.c, compiled with -g:
	...
	__complex__ float cf = 1 + 2i;
	int main (void) { return 0; }
	...

	The values of cf and its components are:
	...
	$ gdb -q a.out
	Reading symbols from a.out...
	(gdb) p cf
	$1 = 1 + 2i
	(gdb) p $_creal(cf)
	$2 = 1
	(gdb) p $_cimag(cf)
	$3 = 2
	...
	and their respective types are:
	...
	(gdb) ptype $1
	type = complex float
	(gdb) ptype $2
	type = float
	(gdb) ptype $3
	type = float
	...

	Now let's try that again, using ptype directly:
	...
	(gdb) ptype cf
	type = complex float
	(gdb) ptype $_creal(cf)
	type = int
	(gdb) ptype $_cimag(cf)
	type = int
	...

	The last two types should have been float, not int.

	Fix this by extending the internal function handlers creal_internal_fn and
	cimag_internal_fn with the noside parameter, such that we get instead:
	...
	(gdb) ptype $_creal(cf)
	type = float
	(gdb) ptype $_cimag(cf)
	type = float
	...

	Tested on x86_64-linux.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

	PR exp/31816
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816

2024-07-24  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Allow internal function to indicate return type
	Currently an internal function handler has this prototype:
	...
	struct value *handler (struct gdbarch *gdbarch,
	                       const struct language_defn *language,
	                       void *cookie, int argc, struct value **argv);
	...

	Also allow an internal function with a handler with an additional
	"enum noside noside" parameter:
	...
	struct value *handler (struct gdbarch *gdbarch,
	                       const struct language_defn *language, void *cookie,
	                       int argc, struct value **argv, enum noside noside);
	...

	In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's
	expected to return some value with the correct return type.

	At least, provided it can do so without side effects, otherwise it should
	throw an error.

	No functional changes.

	Tested on x86_64-linux and aarch64-linux.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-07-24  Nick Clifton  <nickc@redhat.com>

	BFD: Add .relro_padding to list of special sections

2024-07-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: ensure gdb_get_worker_threads succeeds
	Sometimes, if I'm testing on a loaded machine, the
	gdb.gdb/index-file.exp test will timeout during some early steps,
	which then cases a TCL error to be thrown later in the test script.

	Dejagnu then reports this error once the test run has completed, which
	can be pretty noisy, and isn't really very helpful.

	The underlying problem is that if GDB takes too long to load the
	executable (which is GDB itself in this test) then GDB will still be
	busy loading the executable when dejagnu moves on and call
	gdb_get_worker_threads.  The gdb_get_worker_threads call itself times
	out as GDB is _still_ busy loading the executable, and so
	gdb_get_worker_threads returns the string "UNKNOWN".

	Later we try to perform arithmetic on the worker thread count, which
	results in errors when we try to do 'UNKNOWN / 2'.

	I propose that after calling gdb_get_worker_threads, we check if the
	result was UNKNOWN.  If it was then we should report an UNRESOLVED and
	abandon the test, this avoids the later TCL errors.

2024-07-24  Andrew Burgess  <aburgess@redhat.com>

	opcodes/x86: fix minor missed styling case
	I noticed that the x86 instruction:

	  sar    $1,%rsi

	would fail to style the '$0x1' as an immediate.  This commit fixes
	that case.

2024-07-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle address class annotation for s390x in some test-cases
	On s390x-linux, I ran into:
	...
	(gdb) ptype crash^M
	type = class crash {^M
	^M
	  public:^M
	    crash(int (class {...}::*)(class {...} * const @mode32));^M
	}^M
	(gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash
	...

	The problem is that the test-case doesn't expect the address class annotation
	@mode32.

	The test-case uses a .S file, with the address size hard-coded to 4 bytes, and
	that's something that is annotated with @mode32 on s390x (which uses 8 byte
	addresses).

	Fix this by allowing the annotation in the regexp.

	Likewise in two other test-cases.

	Tested on s390-linux and x86_64-linux.

2024-07-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/m-static.exp on arm
	With test-case gdb.cp/m-static.exp on arm-linux, I get:
	...
	(gdb) ptype test5.single_constructor^M
	type = class single_constructor {^M
	^M
	  public:^M
	    single_constructor(void);^M
	    ~single_constructor(void);^M
	} *(single_constructor * const)^M
	(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor
	...

	The test-case expects:
	- no empty line before "public:", and
	- no "~single_constructor(void)", but "~single_constructor()"

	The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same
	for gcc and clang").

	The failing test is in a part only enabled for is_aarch32_target == 1, so it
	looks like it was left behind.

	I'm assuming the same happened for the other difference.

	Fix this by updating the regexps to match the observed output.

	Tested on arm-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-07-24  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR32001, Untranslated "internal:" prefix for error message.
	bfd/
		PR 32001
		* elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated
		"internal:" prefix for error message.

2024-07-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-23  Tom Tromey  <tromey@adacore.com>

	Add returnValue scope to DAP
	The DAP spec recently changed to add a new scope for the return value
	from a "stepOut" request.  This new scope uses the "returnValue"
	presentation hint.  See:

	    https://github.com/microsoft/debug-adapter-protocol/issues/458

	This patch implements this for gdb.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-07-23  Tom Tromey  <tromey@adacore.com>

	Refine the 'define' documentation
	A while ago, an AdaCore user reported some difficulties with the
	'define' command.  While some of these difficulties are intrinsic, or
	at least difficult to change, it seemed sensible to document a couple
	of the typical problems -- and to make the text describing argument
	substitution a bit more prominent.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-07-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-frv: move lm_info object to solib
	I noticed that the lm_info_frv objects created in frv_current_sos are
	never moved to the solib object.  This bug was introduced in 8971d2788e
	("gdb: link so_list using intrusive_list"), which mistakenly removed the
	line

	    sop->lm_info = std::move (li);

	... probably due so a bad merge conflict resolution.

	Re-add this line.

	If merged in master, I would cherry-pick this to gdb-15-branch.

	Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-07-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add xfail in gdb.base/hbreak.exp
	On an aarch64-linux system with 32-bit userland running in a chroot, and using
	target board unix/mthumb I get:
	...
	(gdb) hbreak hbreak.c:27^M
	Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
	(gdb) PASS: gdb.base/hbreak.exp: hbreak
	continue^M
	Continuing.^M
	Unexpected error setting breakpoint: Invalid argument.^M
	(gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
	...
	due to this call in arm_linux_nat_target::low_prepare_to_resume:
	...
	          if (ptrace (PTRACE_SETHBPREGS, pid,
	              (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
	            perror_with_name (_("Unexpected error setting breakpoint"));
	...

	This problem does not happen if instead we use a 4-byte aligned address.

	I'm not sure if this is simply unsupported or if there's a kernel bug of some
	sort, but I don't see what gdb can do about this.

	Tentatively mark this as xfail.

	Tested on aarch64-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-07-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linux
	On arm-linux, I run into:
	...
	PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me
	Expecting: ^(-stack-list-arguments 1[^M
	]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M
	]+[(]gdb[)] ^M
	[ ]*)
	-stack-list-arguments 1^M
	^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M
	(gdb) ^M
	FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
	...

	The problem is that the test-case expects a level 3 frame, but there is none.

	This can be reproduced using cli bt:
	...
	 $ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \
	   -ex "b task_switch.break_me" \
	   -ex run \
	   -ex bt
	 Breakpoint 1 at 0x34b4: file task_switch.adb, line 57.

	 Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \
	   at task_switch.adb:57
	 57	      null;
	 #0  task_switch.break_me () at task_switch.adb:57
	 #1  0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51
	 #2  0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so
	 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
	...

	The purpose of the test-case is printing the frame at level 1, so I don't
	think we should bother about the presence of the frame at level 3.

	Fix this by allowing the backtrace to stop at level 2.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-07-23  Pali Roh?r  <pali@kernel.org>

	Improve objdump's display of PE header information.
	  PR 31953

2024-07-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-22  Simon Marchi  <simon.marchi@efficios.com>

	gdb/unittests/intrusive-list: remove unnecessary local objects
	These objects are not used.

	Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f

2024-07-22  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib: pass program space to solib_used
	Make the current program space reference bubble up one level.

	Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123

2024-07-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/remote: remove an out of date comment
	A comment above an `if` check was accidentally left in place after
	this commit:

	  commit ddb3f3d89cf62df6be3cb9e110504def19625160
	  Date:   Tue Mar 19 12:34:34 2024 +0100

	      Add "error_message+" feature to qSupported

	The comment relates to how 'E.msg' style remote replies are not
	supported by every packet, but after the above commit they are
	supported in all cases (that call packet_check_result), and the
	comment should have been removed.

2024-07-22  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix minor typo in a comment
	Fix 'text' to 'test' in a test comment.

2024-07-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-21  Alan Modra  <amodra@gmail.com>

	Don't trim trailing newline in run_host_cmd
	Testcases like ld-elf/pr19719a.c that
	    printf ("PASS\n");
	on success ought to see the whole output for "string match".
	Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last
	newline to match.  For most of the testsuite it doesn't matter whether
	the trailing newline is present or not, and there are only a few cases
	where we need to remove it.

		* testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away
		output trailing newline.  Do string trim for gcc/ld version checks.
		* testsuite/config/default.exp (plug_so): Do string trim output of
		run_host_cmd.
		* testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust
		string match to include trailing newline.
		* testsuite/ld-i386/i386.exp (undefined_weak): Likewise.
		* testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise.
		* testsuite/ld-plugin/libdep.exp (run_test): Likewise.
		* testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise.
		* testsuite/ld-pe/pdb-strings.d,
		* testsuite/ld-pe/pdb-syms1-globals.d,
		* testsuite/ld-pe/pdb-syms1-records.d,
		* testsuite/ld-pe/pdb-syms1-symbols1.d,
		* testsuite/ld-pe/pdb-syms1-symbols2.d,
		* testsuite/ld-pe/pdb-syms2-symbols1.d,
		* testsuite/ld-pe/pdb-types1-hashlist.d,
		* testsuite/ld-pe/pdb-types1-skiplist.d,
		* testsuite/ld-pe/pdb-types1-typelist.d,
		* testsuite/ld-pe/pdb-types2-hashlist.d,
		* testsuite/ld-pe/pdb-types2-skiplist.d,
		* testsuite/ld-pe/pdb-types2-typelist.d,
		* testsuite/ld-pe/pdb-types3-hashlist.d,
		* testsuite/ld-pe/pdb-types3-skiplist.d,
		* testsuite/ld-pe/pdb-types3-typelist.d,
		* testsuite/ld-pe/pdb1-publics.d,
		* testsuite/ld-pe/pdb1-sym-record.d,
		* testsuite/ld-pe/pdb2-section-contrib.d,
		* testsuite/ld-pe/pdb3-c13-info1.d,
		* testsuite/ld-pe/pdb3-c13-info2.d,
		* testsuite/ld-pe/pdb3-source-info.d: Add trailing newline.

2024-07-21  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: Add missing 'require allow_gdbserver_tests'
	The commit:

	  commit 22836ca88591ac7efacf06d5b6db191763fd8aba
	  Date:   Tue May 21 09:57:49 2024 +0100

	      gdb: check for multiple matching build-id files

	Was missing a 'require allow_gdbserver_tests' in a gdbserver test.
	Add it now.

2024-07-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.exp
	When running test-case gdb.dap/rust-slices.exp on aarch64-linux
	(debian 12/bookworm), I run into:
	...
	{"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success
	FAIL: gdb.dap/rust-slices.exp: three scopes
	PASS: gdb.dap/rust-slices.exp: scope is locals
	PASS: gdb.dap/rust-slices.exp: locals presentation hint
	PASS: gdb.dap/rust-slices.exp: three vars in scope
	...

	The test-case expects three scopes due to a rust compiler issue:
	...
	 # There are three scopes because an artificial symbol ends up in the
	 # DWARF.  See https://github.com/rust-lang/rust/issues/125126.
	 gdb_assert {[llength $scopes] == 3} "three scopes"
	...
	but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't
	have this issue.

	Fix this by allowing two or three scopes, and changing the test name to
	"two scopes".

	Tested on aarch64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	PR testsuite/31983
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983

2024-07-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-20  Mark Harmstone  <mark@harmstone.com>

	ld/testsuite: add missing definition to PDB test
	The file pdb-syms1a.s was missing a definition for T_VOID, which was
	causing some types not to be deduplicated. It also meant that the test
	couldn't be run against LLVM's lld, which throws an error for this.

	This particular test only tests the symbols stream, not the types
	stream, which is why the deduplication doesn't result in a change in the
	file size.

2024-07-20  Mark Harmstone  <mark@harmstone.com>

	ld/PDB: use correct hashing algorithm in add_globals_ref
	add_globals_ref was hashing using CRC32 rather than the hashing
	algorithm used for symbols, which meant that windbg was unable to put
	breakpoints against unmangled names.

2024-07-20  H.J. Lu  <hjl.tools@gmail.com>

	Correct version for binutils 2.43 NEWS entries.
	Change 2.42 to 2.43 for binutils 2.43 NEWS entries.

	binutils/

		* NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries.

	ld/

		* NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries.

2024-07-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove tracepoint_probe_create_sals_from_location_spec
	The tracepoint_probe_create_sals_from_location_spec function just
	forwards all its arguments to
	bkpt_probe_create_sals_from_location_spec, and is only used in one
	place.

	Lets delete tracepoint_probe_create_sals_from_location_spec and
	replace it with bkpt_probe_create_sals_from_location_spec.

	There should be no user visible changes after this commit.

2024-07-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove breakpoint_re_set_one
	During a later patch I wanted to reset a single breakpoint, so I
	called breakpoint_re_set_one.  However, this is not the right thing to
	do.  If we look at breakpoint_re_set then we see that there's a whole
	bunch of state that needs to be preserved prior to calling
	breakpoint_re_set_one, and after calling breakpoint_re_set_one we
	still need to call update_global_location_list.

	I could just update the comment on breakpoint_re_set_one to make it
	clearer how the function should be used -- or more likely to warn that
	the function should only be used as a helper from breakpoint_re_set.

	However, breakpoint_re_set_one is only 3 lines long.  So I figure it
	might actually be easier to just fold breakpoint_re_set_one into
	breakpoint_re_set, then there's no risk of accidentally calling
	breakpoint_re_set_one when we shouldn't.

	There should be no user visible changes after this commit.

2024-07-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't display inferior list for pending breakpoints
	I noticed that in the 'info breakpoints' output, GDB sometimes prints
	the inferior list for pending breakpoints, this doesn't seem right to
	me.  A pending breakpoint has no locations (at least, as far as we
	display things in the 'info breakpoints' output), so including an
	inferior list seems odd.

	Here's what I see right now:

	  (gdb) info breakpoint 5
	  Num     Type           Disp Enb Address            What
	  5       breakpoint     keep y   <PENDING>          foo inf 1
	  (gdb)

	It's the 'inf 1' at the end of the line that I'm objecting too.

	To trigger this behaviour we need to be in a multi-inferior debug
	session.  The breakpoint must have been non-pending at some point in
	the past, and so have a location assigned to it.

	The breakpoint becomes pending again as a result of a shared library
	being unloaded.  When this happens the location itself is marked
	pending (via bp_location::shlib_disabled).

	In print_one_breakpoint_location, in order to print the inferior list
	we check that the breakpoint has a location, and that we have multiple
	inferiors, but we don't check if the location itself is pending.

	This commit adds that check, which means the output is now:

	  (gdb) info breakpoint 5
	  Num     Type           Disp Enb Address            What
	  5       breakpoint     keep y   <PENDING>          foo
	  (gdb)

	Which I think makes more sense -- indeed, the format without the
	inferior list is what we display for a pending breakpoint that has
	never had any locations assigned, so I think this change in behaviour
	makes GDB more consistent.

2024-07-20  Nick Clifton  <nickc@redhat.com>

	Update after creating 2.43 branch

	Change version to 2.43.50

	Add markers for 2.43 branch/release

2024-07-20  Alan Modra  <amodra@gmail.com>

	Re: binutils: Add a test for strip with build notes
	The new test wasn't being run, and failed due to relocations against
	.gnu.build.attributes being stripped by default strip behaviour.
	We probably should be keeping these relocations, but I haven't made
	that change here.
	BTW, the new test fails on ia64-hpux but that's just a repeat of the
	existing note-5 fail.

		PR 31999
		* testsuite/binutils-all/strip-16.d: strip with --strip-unneeded
		and --merge-notes.
		* testsuite/binutils-all/objcopy.exp: Run the new test.  Sort
		other strip tests.

2024-07-20  H.J. Lu  <hjl.tools@gmail.com>

	binutils: Add a test for strip with build notes
	Add a test for strip with build notes.

		PR binutils/31999
		* testsuite/binutils-all/strip-16.d: New.

2024-07-20  Alan Modra  <amodra@gmail.com>

	PR31999 strip [.gnu.build.attributes]: failed
		PR 31999
		* objcopy.c (merge_gnu_build_notes): Always set *new_size.

2024-07-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb-gdb.py: strip typedefs in intrusive_list printer assertion
	When debugging gdb itself and trying to print a intrusive_list that has
	more than one element, I get:

	    File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator
	      node_ptr = self._as_node_ptr(elem_ptr)
	                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
	    File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr
	      assert elem_ptr.type.code == gdb.TYPE_CODE_PTR
	             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	    AssertionError

	This is because node_ptr is a typedef
	(intrusive_list_base_iterator::pointer).  Add a call to strip_typedefs
	to get to the real type.

	Enhance gdb.gdb/python-helper.exp with a test that would have caught
	this bug.

	Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Replace "y" microMIPS operand code with "x"
	Replace the "y" microMIPS operand code, used with ALNV.PS only, with "x"
	so as to make "y" available for microMIPS MT use.

	MIPS/opcodes: Mark MT thread context move assembly idioms as aliases
	A number of instructions in the regular MIPS opcode table are assembly
	idioms for the MT thread context move MFTR and MTTR instructions, so
	mark them as aliases accordingly.  Add suitable test cases, which also
	cover the PAUSE assembly idiom.

	MIPS/opcodes: Mark PAUSE as an alias
	PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in
	the regular MIPS opcode table, matching the microMIPS opcode table.  A
	test case will be supplied separately.

	MIPS/GAS/testsuite: Run the MT ASE test across architectures
	Verify that MT ASE instructions assemble and disassemble correctly
	across the compatible architectures.

	MIPS/opcodes: Reorder coprocessor moves alphabetically
	A number of coprocessor move encodings have been randomly sprinkled over
	the regular MIPS and microMIPS opcode tables rather than where they'd be
	expected following the alphabetic order.  Fix the ordering, taking into
	account precedence where it has to be observed for correct disassembly.
	No functional change.

	MIPS/opcodes: Make AL a shorthand for INSN2_ALIAS
	Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS
	opcode tables, just as with the MIPS16 opcode table, and use it
	throughout.  No functional change.

	MIPS/opcodes: Rename the AL membership shorthand to ALX
	Make room for AL as a shorthand for INSN2_ALIAS with the regular MIPS
	opcode table, just as with the MIPS16 opcode table.  No functional
	change.

2024-07-19  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/opcodes: Remove the regular MIPS "+t" operand code
	The semantics of the regular MIPS "+t" operand code is exactly the same
	as that of the "E" operand code, so replace the former with the latter
	in the single MFTC0 instruction with implicit 'sel' == 0 encoding where
	it's used, matching the encoding with explicit 'sel' as well as other
	instructions.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Output thread context registers numerically with MFTR/MTTR
	We print MFTR and MTTR instructions' thread context register operand in
	disassembly using the ABI name the register number would correspond to
	should the targeted register be a general-purpose register.

	However in most cases it is wrong, because general-purpose registers are
	only referred when the 'u' and 'sel' operands are 1 and 0 respectively.
	And even in these cases the MFGPR and MTGPR aliases take precedence over
	the corresponding generic instruction encodings, so you won't see the
	valid case to normally trigger.

	Conversely decoding the thread context register operand numerically is
	always valid, so switch to using it.  Adjust test coverage accordingly.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros
	As from commit ab90248154ba ("Add structures to describe MIPS
	operands"), <https://sourceware.org/ml/binutils/2013-07/msg00135.html>,
	the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros
	has been removed.

	Similarly as from commit c3c0747817f4 ("Use operand structures for
	MIPS16"), <https://sourceware.org/ml/binutils/2013-07/msg00136.html>,
	the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed.

	And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"),
	<https://sourceware.org/ml/binutils/2013-07/msg00139.html>, none of the
	OP_OP macros are used anymore.

	Discard all the unused macros then and only keep the small subset that
	is still referred.  This simplifies maintenance and removes the need to
	keep the artificial arrangement where some regular MIPS and microMIPS
	macros expand to 0 and are kept for compatibility with the opposite ISA
	mode only, as it used to be required before the commit referred.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Correct documentation for R6 operand types
	The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which
	is the target register rather than the source register.  Additionally
	the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand
	of the BOVC/BNVC and the BEQC/BNEC instructions respectively.  Also the
	"-x" operand type does not permit 'rs' to be the same as 'rt'.

	Correct inline documentation in opcode/mips.h accordingly.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Exclude $0 from "-x" R6 operand type
	The "-x" operand type is used for the reverse encoding of the BOVC and
	BNVC instructions, where 'rs' and 'rt' have been supplied as the second
	and the first operand respectively rather than the order the instruction
	expects.

	In this case we require the register associated with the "-x" operand to
	have a higher number than the register associated with the preceding "t"
	operand, which precludes the use of $0.  The case where 'rs' and 'rt'
	both refer to the same register is handled by the straight encoding of
	the BOVC and BNVC instructions, which come in the opcode table ahead of
	the corresponding reverse encoding.

	Therefore clear the ZERO_OK flag for the "-x" operand.  No need for an
	extra test case as the encodings involved are already covered by "r6"
	and its associated GAS tests.

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	Sparc: relax gas testsuite whitespace expectations
	In a subsequent change the scrubber is going to be changed to retain
	further whitespace. Test case expectations generally would better not
	depend on the specific whitespace treatment by the scrubber, unless of
	course a test is specifically about it. Adjust relevant test cases to
	permit blanks where those will subsequently appear.

	TilePro: correct macro use in gas testsuite
	Whitespace in macro arguments either needs quoting / parenthesizing to
	reliably not be mistaken for an argument separator, or respective macro
	parameters need to be marked as covering all remaining arguments. The
	latter appears more appropriate (and far less intrusive) here.

	MIPS: correct macro use in gas and ld testsuites
	Whitespace in macro arguments either needs quoting / parenthesizing to
	reliably not be mistaken for an argument separator, or respective macro
	parameters need to be marked as covering all remaining arguments. The
	former appears more appropriate here, as the macro parameters already
	have ":req".

	ia64: correct macro use in gas testsuite
	Whitespace in macro arguments either needs quoting / parenthesizing to
	reliably not be mistaken for an argument separator, or respective macro
	parameters need to be marked as covering all remaining arguments. The
	latter appears more appropriate here.

	bfin: drop _ASSIGN_BANG
	A few testcases demonstrate that "=!" isn't supposed to be an
	individual token, since "= !" is used in a number of places. So far
	lexing that to a single token worked because of the scrubber being
	overly aggressive in removing whitespace. As that's going to change,
	replace uses by separate ASSIGN and BANG.

	bfin: correct macro use in gas testsuite
	Whitespace in macro arguments either needs quoting / parenthesizing to
	reliably not be mistaken for an argument separator, or respective macro
	parameters need to be marked as covering all remaining arguments. The
	latter really isn't an option here.

	Arm: correct macro use in gas testsuite
	The way the inner macro invocations are written doesn't quite work as
	expected (and would actually break subsequently): Due to overly
	aggressive removal of whitespace by the scrubber, the incoming \sym and
	\offset arguments actually get concatenated; an empty 3rd argument is
	being passed to ldrtest2. That just so happened to work as intended; any
	use of \offset alone would have exposed the problem. Quote the 3rd
	argument, thus retaining enough whitespace to be independent of scrubber
	internals.

	gas: adjust impossible/bogus M68K/MRI special case when scrubbing
	State 1 is uniformly handled further up. And it is highly questionable
	that in state 10 (i.e. after having seen not only a possible label, but
	also an opcode), which is about to go away anyway, a line comment char
	could still be meant to take effect. With the state checking dropped,
	the immediately preceding logic can then also be simplified.

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	gas: consistently drop trailing whitespace when scrubbing
	From especially the checks for the two separator forms it appears to
	follow that the construct being touched is about trailing whitespace. In
	such a case, considering that for many targets ordinary and line comment
	chars overlap, take into account that line comment chars override
	ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually
	depends on that ordering, and also accounts for this overriding).

	Plus of course IS_NEWLINE() would better also be consulted. Note also
	that the DOUBLESLASH_LINE_COMMENTS change should generally have no
	effect just yet; it's a prereq for a later change but better fits here.

	Leave respective comments as well, and update documentation to correct
	which comment form is actually replaced by a single blank (i.e. neither
	the ones starting with what {,tc_}comment_chars[] has nor the ones
	starting with what line_comment_chars[] has).

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	gas: drop tic6x scrubber special case
	Two successive PUT() without a state change in between can't be right:
	The first PUT() may take the "goto tofull" path, leading to the
	subsequent character being processed later in the previously set state
	(1 in this case), rather than the state we were in upon entry to the
	switch() (13 in this case).

	However, the original purpose of that logic appears to be to not mistake
	"|| ^" for "||^". This effect, sadly, looks to not have been achieved.
	Therefore drop the special case altogether; something that actually
	achieves the (presumably) intended effect may then be introduced down
	the road.

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	gas: pre-init the scrubber's lex[]
	While we can't - unlike an old comment suggests - do this fully, we can
	certainly do part of this at compile time.

	Since it's adjacent, also drop the unnecessary forward declaration of
	process_escape().

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	x86: accept whitespace inside curly braces
	Other than documented /**/ comments currently aren't really converted to
	a single space, at least not for x86 in its most common configurations.
	That'll be fixed subsequently, at which point blanks may appear where so
	far none were expected. Furthermore not permitting blanks immediately
	inside curly braces wasn't quite logical anyway - such constructs are
	composite ones, and hence components ought to have been permitted to be
	separated by whitespace from the very beginning.

	With this we also don't care anymore whether the scrubber would remove
	whitespace around curly braces, so move them from extra_symbol_chars[]
	to operand_special_chars[].

	Note: The new testcase doesn't actually exercise much (if any) of the
	added code. It is being put in place to ensure that subsequently, when
	that code actually comes into play, behavior remains the same.

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	x86: undo '{' being a symbol-start character
	Having it that way has undue side effects, in permitting not only
	pseudo-prefixes to be parsed correctly, but also permitting odd symbol
	names which ought to be possible only when quoted.  Borrow what other
	architectures do: Put in place an "unrecognized line" hook to parse off
	any pseudo prefixes, while using the "start of line" hook to reject ones
	not actually followed by an insn. For that parsing re-use parse_insn()
	in yet a slightly different mode (dealing with only pseudo-prefixes).

	With that, pp may no longer be cleared from init_globals(), but instead
	needs clearing after a line was fully processed. Since md_assemble() has
	pretty many return paths, convert that into a local helper, with a
	trivial wrapper around it.

	Similarly pp may no longer be updated (by check_register()) when
	processing anything other than insn operands. To be able to (easily)
	recognize the case, clear current_templates.start when done with an insn
	(or with .insn).

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	x86: split pseudo-prefix state from i386_insn
	Subsequently we will want to update that ahead of md_assemble(), with
	that function needing to take into account such earlier updating.
	Therefore it'll want resetting separately from i.

2024-07-19  Jan Beulich  <jbeulich@suse.com>

	x86/APX: add CMPcc/CTESTcc cases to noreg64 tests
	This was missed when support for the insns was added. Just like for
	DATA16, in

		rex64 neg (%rax)
		rex64 neg (%r16)
		rex64 {nf} neg (%rax)

	it is not logical why the last one shouldn't be permitted. Bypassing
	that check requires other adjustments, though, to actually properly
	consume (and then squash) the prefix.

2024-07-19  zhangxianting  <zhangxianting@uniontech.com>

	bfin: free the allocated memory

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS/testsuite: Also verify trap expansions of multiplication macros
	Provide 'mul' test variants for trap expansions as requested by the
	'-trap' command-line option, and run them across all the compatible
	architectures.

	MIPS/GAS/testsuite: Split mul test into 32-bit and 64-bit parts
	Enable full 32-bit and 64-bit multiplication macro verification, by
	splitting the 'mul' test into two parts respectively, and run them
	across all the compatible architectures.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS/testsuite: Run the mul macro test across architectures
	The multiplication macros expand differently based on the ISA chosen, so
	run the 'mul' macro test across compatible architectures, adopting the
	'mul-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test
	failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
	and providing coverage for the expansion variants.

	Only run from MIPS III up for now and remove the ISA override from the
	source, so that the 64-bit instructions are covered for individual
	64-bit architectures.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS/testsuite: Also verify trap expansions of division macros
	Provide 'div' test variants for trap expansions as requested by the
	'-trap' command-line option, and run them across all the compatible
	architectures.

	MIPS/GAS/testsuite: Split div test into 32-bit and 64-bit parts
	Enable full 32-bit and 64-bit division macro verification, by splitting
	the 'div' test into two parts respectively, and run them across all the
	compatible architectures.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS/testsuite: Run the div macro test across architectures
	The division macros expand differently depending on the ISA selected, so
	run the 'div' macro test across compatible architectures, adopting the
	'div-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test
	failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
	and providing coverage for the expansion variants.

	Only run from MIPS III up for now and remove the ISA override from the
	source, so that the 64-bit instructions are covered for individual
	64-bit architectures.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS: Handle --trap command-line option dynamically
	We have an ISA check for the '--trap' command-line option that reports
	its incompatibility with the MIPS I architecture.  It doesn't prevent
	trap instructions from being enabled though, so when attempt is made to
	emit one in an expansion of one of the division or multiplication macros
	an assertion failure triggers:

	.../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages:
	.../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1
	.../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero
	.../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064.
	Please report this bug.

	The same assertion failure triggers without an earlier error message
	when the initial ISA is compatible with the '--trap', however at the
	time an attempt is made to emit a trap instruction from a division or
	multiplication macro the ISA has been changed by a '.set' pseudo-op to
	an incompatible one.

	With the way the situations are mishandled it seems unlikely that anyone
	relies on the current semantics and a sane approach is to decide on the
	fly according to the currently selected ISA as to whether to emit trap
	or breakpoint instructions in the case where '--trap' has been used.

	Change our code to do so then and clarify that in the manual, which is
	not explicit about how '--trap' is handled with a changing ISA.  Mention
	the change in NEWS too since it's a applies to a user option.

2024-07-19  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/GAS/testsuite: Add R10000 CPU architecture
	Add a fully interlocked MIPS IV CPU so that we can have coverage for
	MIPS IV instruction sequences with and without instruction separation
	required for a HI/LO data anti-dependency.

	MIPS/GAS/testsuite: Reorder R5900 CPU architecture definition
	The R5900 CPU architecture is based on MIPS III, so move it ahead of
	MIPS IV CPU architecture definitions.  No functional change.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: aarch64: testsuite: add new tests for SCFI
	Similar to the x86_64 testcases, some .s files contain the corresponding
	CFI directives.  This helps in validating the synthesized CFI by running
	those tests with and without the --scfi=experimental command line
	option.

	GAS issues some diagnostics, enabled by default, with
	--scfi=experimental.  The diagnostics have been added with an intent to
	help user correct inadvertent errors in their hand-written asm.  An
	error is issued when GAS finds that input asm is not amenable to
	accurate CFI synthesis.  The existing scfi-diag-*.s tests in the
	gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics
	already:

	      - (#1) "Warning: SCFI: Asymetrical register restore"
	      - (#2) "Error: SCFI: usage of REG_FP as scratch not supported"
	      - (#3) "Error: SCFI: unsupported stack manipulation pattern"
	      - (#4) "Error: untraceable control flow for func 'XXX'"

	In the newly added aarch64 testsuite, further tests for additional
	diagnostics have been added:
	 - scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic:
	   (#5) "Warning: SCFI: ignored probable save/restore op with reg offset"

	Additionally, some testcases are added to showcase the (currently)
	unsupported patterns, e.g., scfi-unsupported-1.s
	        mov     x16, 4384
	        sub     sp, sp, x16

	gas/testsuite/:
		* gas/scfi/README: Update comment to include aarch64.
		* gas/scfi/aarch64/scfi-aarch64.exp: New file.
		* gas/scfi/aarch64/ginsn-arith-1.l: New test.
		* gas/scfi/aarch64/ginsn-arith-1.s: New test.
		* gas/scfi/aarch64/ginsn-cofi-1.l: New test.
		* gas/scfi/aarch64/ginsn-cofi-1.s: New test.
		* gas/scfi/aarch64/ginsn-ldst-1.l: New test.
		* gas/scfi/aarch64/ginsn-ldst-1.s: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test.
		* gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test.
		* gas/scfi/aarch64/scfi-cb-1.d: New test.
		* gas/scfi/aarch64/scfi-cb-1.l: New test.
		* gas/scfi/aarch64/scfi-cb-1.s: New test.
		* gas/scfi/aarch64/scfi-cfg-1.d: New test.
		* gas/scfi/aarch64/scfi-cfg-1.l: New test.
		* gas/scfi/aarch64/scfi-cfg-1.s: New test.
		* gas/scfi/aarch64/scfi-cfg-2.d: New test.
		* gas/scfi/aarch64/scfi-cfg-2.l: New test.
		* gas/scfi/aarch64/scfi-cfg-2.s: New test.
		* gas/scfi/aarch64/scfi-cfg-3.d: New test.
		* gas/scfi/aarch64/scfi-cfg-3.l: New test.
		* gas/scfi/aarch64/scfi-cfg-3.s: New test.
		* gas/scfi/aarch64/scfi-cfg-4.l: New test.
		* gas/scfi/aarch64/scfi-cfg-4.s: New test.
		* gas/scfi/aarch64/scfi-cond-br-1.d: New test.
		* gas/scfi/aarch64/scfi-cond-br-1.l: New test.
		* gas/scfi/aarch64/scfi-cond-br-1.s: New test.
		* gas/scfi/aarch64/scfi-diag-1.l: New test.
		* gas/scfi/aarch64/scfi-diag-1.s: New test.
		* gas/scfi/aarch64/scfi-diag-2.l: New test.
		* gas/scfi/aarch64/scfi-diag-2.s: New test.
		* gas/scfi/aarch64/scfi-diag-3.l: New test.
		* gas/scfi/aarch64/scfi-diag-3.s: New test.
		* gas/scfi/aarch64/scfi-ldrp-1.d: New test.
		* gas/scfi/aarch64/scfi-ldrp-1.l: New test.
		* gas/scfi/aarch64/scfi-ldrp-1.s: New test.
		* gas/scfi/aarch64/scfi-ldrp-2.d: New test.
		* gas/scfi/aarch64/scfi-ldrp-2.l: New test.
		* gas/scfi/aarch64/scfi-ldrp-2.s: New test.
		* gas/scfi/aarch64/scfi-ldstnap-1.d: New test.
		* gas/scfi/aarch64/scfi-ldstnap-1.l: New test.
		* gas/scfi/aarch64/scfi-ldstnap-1.s: New test.
		* gas/scfi/aarch64/scfi-strp-1.d: New test.
		* gas/scfi/aarch64/scfi-strp-1.l: New test.
		* gas/scfi/aarch64/scfi-strp-1.s: New test.
		* gas/scfi/aarch64/scfi-strp-2.d: New test.
		* gas/scfi/aarch64/scfi-strp-2.l: New test.
		* gas/scfi/aarch64/scfi-strp-2.s: New test.
		* gas/scfi/aarch64/scfi-unsupported-1.l: New test.
		* gas/scfi/aarch64/scfi-unsupported-1.s: New test.
		* gas/scfi/aarch64/scfi-unsupported-2.l: New test.
		* gas/scfi/aarch64/scfi-unsupported-2.s: New test.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: aarch64: add experimental support for SCFI
	For synthesizing CFI (SCFI) for hand-written asm, the SCFI machinery in
	GAS works on the generic GAS insns (ginsns).  This patch adds support in
	the aarch64 backend to create ginsns for a subset of the supported
	machine instructions.  The subset includes the minimal necessary
	instructions to ensure SCFI correctness:

	- Any potential register saves and unsaves.  Hence, process instructions
	  belonging to a variety of iclasses involving str, ldr, stp, ldp.
	- Any change of flow instructions.  This includes all conditional and
	  unconditional branches, call (bl, blr, etc.) and return.
	- Most importantly, any instruction that could affect the two registers
	  of interest: REG_SP, REG_FP.  This set includes all pre-indexed and
	  post-indexed memory operations, with writeback, on the stack.  This
	  set must also include other instructions (e.g., arithmetic insns)
	  where the destination register is one of the afore-mentioned registers.

	With respect to callee-saved registers in Aarch64, FP/Advanced SIMD
	registers D8-D15 are included along with the relevant GPRs.  Calculating
	offsets for loads and stores especially for Q registers needs special
	attention here.

	As an example,
	   str q8, [sp, #16]
	On big-endian:
	   STR Qn stores as a 128-bit integer (MSB first), hence, should record
	   D8 as being saved at sp+24 rather than sp+16.
	On little-endian:
	   should record D8 as being saved at sp+16

	D8-D15 are the low 64 bits of Q8-Q15, and of Z8-Z15 if SVE is used;
	hence, they remain "interesting" for SCFI purposes in such cases.  A CFI
	save slot always represents the low 64 bits, regardless of whether a
	save occurs on D, Q or Z registers.  Currently, the ginsn creation
	machinery can handle D and Q registers on little-endian and big-endian.

	Apart from creating ginsn, another key responsibility of the backend is
	to make sure there are safeguards in place to detect and alert if an
	instruction of interest may have been skipped.  This is done via
	aarch64_ginsn_unhandled () (similar to the x86 backend).  This function
	, hence, is also intended to alert when future ISA changes may otherwise
	render SCFI results incorrect, because of missing ginsns for the newly
	added machine instructions.

	At this time, becuase of the complexities wrt endianness in handling Z
	register usage, skip sve_misc opclass altogether for now.  The SCFI
	machinery will error out (using the aarch64_ginsn_unhandled () code
	path) though if Z register usage affects correctness.

	The current SCFI machinery does not currently synthesize the
	PAC-related, aarch64-specific CFI directives: .cfi_b_key_frame.  The
	support for this is planned for near future.

	SCFI is enabled for ELF targets only.

	gas/
		* config/tc-aarch64-ginsn.c: New file.
		* config/tc-aarch64.c (md_assemble): Include tc-aarch64-ginsn.c
		file.  Invoke aarch64_ginsn_new.
		* config/tc-aarch64.h (TARGET_USE_GINSN): Define for SCFI
		enablement.
		(TARGET_USE_SCFI): Likewise.
		(SCFI_MAX_REG_ID): New definition.
		(REG_FP): Likewise.
		(REG_LR): Likewise.
		(REG_SP): Likewise.
		(SCFI_INIT_CFA_OFFSET): Likewise.
		(SCFI_CALLEE_SAVED_REG_P): Likewise.
		(aarch64_scfi_callee_saved_p): New declaration.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: aarch64: enforce checks on subclass flags in aarch64-gen.c
	Enforce some checks on the newly added subclass flags:
	  - If a subclass is set of one insn of an iclass, every insn of that
	    iclass must have non-zero subclass field.
	  - For all other iclasses, the subclass bits are zero for all insns.

	include/
	        * opcode/aarch64.h (enum aarch64_insn_class): Identify the
		maximum iclass enum value.

	opcodes/
	        * aarch64-gen.c (iclass_has_subclasses_p): New array of bool.
	        (read_table): Enforce checks on subclass flags.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: aarch64: denote subclasses for insns of iclass dp_2src
	For detecting irg, add a subclass to identify it in the set of
	instructions of iclass dp_2src.

	opcodes/
		* aarch64-tbl.h: Add subclass flag F_DP_TAG_ONLY for irg insn.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: aarch64: add flags to denote subclasses of uncond branches
	Use the two new subclass flags: F_BRANCH_CALL, F_BRANCH_RET, to indicate
	call to and return from subroutine respectively.

	opcodes/
		* aarch64-tbl.h: Use the new F_BRANCH_* flags.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: aarch64: add flags to denote subclasses of arithmetic insns
	Use the three new subclass flags: F_ARITH_ADD, F_ARITH_SUB,
	F_ARITH_MOV, to indicate add, sub and mov ops respectively.

	These flags for subclasses will later be used for SCFI purposes to
	create appropriate ginsns.  At this time, only those iclasses relevant
	to SCFI have the new subclass flags specified.

	For addg and subg insns, F_SUBCLASS_OTHER is more suitable because these
	operations do more than just simple add or sub.

	opcodes/
	    * aarch64-tbl.h: Use the new F_ARITH_* flags.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: aarch64: add flags to denote subclasses of ldst insns
	The existing iclass information tells us the general shape and purpose
	of the instructions.  In some cases, however, we need to further disect
	the iclass on the basis of other finer-grain information.  E.g., for the
	purpose of SCFI, we need to know whether a given insn with iclass
	of ldst_* is a load or a store.

	At the moment, specify subclasses for only those iclasses relevant to
	SCFI: ldst_imm9, ldst_pos, ldstpair_indexed, ldstpair_off and
	ldstnapair_offs.

	Some insns are best tagged with F_SUBCLASS_OTHER rather than F_LDST_LOAD
	or F_LDST_STORE:
	  - stg* ops (as they store tag only),
	  - prfm,
	  - ldpsw, ldrsw (32-bit loads with signed extended value.  Not useful
	    for restore operations in context of SCFI.)
	  - Use F_SUBCLASS_OTHER for all QL_LDST_R8 and QL_LDST_R16 operands.
	    Also use F_SUBLASS_OTHER for strb/ldrb, strh/ldrh opcodes.
	    These are not full loads and stores and cannot be allowed for
	    register save / restore for the purpose of SCFI.

	opcodes/
	    * aarch64-tbl.h: Use the new F_LDST_* flags.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	include: opcodes: aarch64: define new subclasses
	The existing iclass information tells us the general shape and purpose
	of the instructions.  In some cases, however, we need to further disect
	the iclass on the basis of other finer-grain information.  E.g., for the
	purpose of SCFI, we need to know whether a given insn with iclass of
	ldst_* is a load or a store.  Similarly, whether a particular arithmetic
	insn is an add or sub or mov, etc.

	This patch defines new flags to demarcate the insns.  Also provide an
	access function for subclass lookup.

	Later, we will enforce (in aarch64-gen.c) that if an iclass has at least
	one instruction with a non-zero subclass, all instructions of the iclass
	must have a non-zero subclass information.  If none of the defined
	subclasses are applicable (or not required for SCFI purposes),
	F_SUBCLASS_OTHER can be used for such instructions.

	include/
	        * opcode/aarch64.h (F_SUBCLASS): New flag.
	        (F_SUBCLASS_OTHER): Likewise.
	        (F_LDST_LOAD): Likewise.
	        (F_LDST_STORE): Likewise.
	        (F_ARITH_ADD): Likewise.
	        (F_ARITH_SUB): Likewise.
	        (F_ARITH_MOV): Likewise.
	        (F_BRANCH_CALL): Likewise.
	        (F_BRANCH_RET): Likewise.
		(F_DP_TAG_ONLY): Likewise.
	        (aarch64_opcode_subclass_p): New definition.

2024-07-19  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: make scfi_state_restore_reg function more precise
	When the SCFI machinery detects that a register has been restored from
	stack, it makes some state changes in the SCFI state object.

	Prior to the patch, scfi_state_restore_reg () was setting a value of
	(reg, CFI_IN_REG) for (base, state) respectively.  This was causing
	issues in the cmp_scfi_state () function:
	  - The default state of all (callee-saved) regs at the beginning of
	    function is set to (0, CFI_UNDEFINED).
	  - If a register is saved and restored on some control path, the state
	    of reg is (reg, CFI_IN_REG) on that path.
	  - On another control path where the register was perhaps not
	    used (or saved/restored on stack) remains (0, CFI_UNDEFINED).
	  - The two states should be treated equal, however, at the point in
	    program after the register has been restored.

	Fix this by resetting the state to (0, CFI_UNDEFINED) in
	scfi_state_restore_reg ().

	A testcase (scfi-cfg-4.s) for this is added in a subsequent commit.

	gas/
	        * scfi.c (scfi_state_restore_reg): Reset to 0, CFI_UNDEFINED
		for base, state.

2024-07-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-18  Matthieu Longo  <matthieu.longo@arm.com>

	gas: minor reformatting in command line help and doc
	- help message: add a comma between the short and long option
	- as doc:
	  - brief summary of how to invoke gas: separate [-w] [-x] on a new line as those
	  two options have nothing to do with the warning options.
	  - reordering of the warning options to have the same order as the listing.
	  - no-warn option description: change an "and" to a "or", as it is either the short
	  or long option to use, but not both at the same time.
	- remove trailing whitespaces.

2024-07-18  Andrew Burgess  <aburgess@redhat.com>

	gdb: check for multiple matching build-id files
	Within the debug-file-directory GDB looks for the existence of a
	.build-id directory.

	Within the .build-id directory GDB looks for files with the form:

	  .build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug

	which contain the debug information for the objfile with the build-id
	ff4b4142d62b399499844924d53e33d4028380db.

	There appear to be two strategies for populating the .build-id
	directory.  Ubuntu takes the approach of placing the actual debug
	information in this directory, so
	4b4142d62b399499844924d53e33d4028380db.debug is an actual file
	containing the debug information.

	Fedora, RHEL, and SUSE take a slightly different approach, placing the
	debug information elsewhere, and then creating symlinks in the
	.build-id directory back to the original debug information file.  The
	actual debug information is arranged in a mirror of the filesystem
	within the debug directory, as an example, if the debug-file-directory
	is /usr/lib/debug, then the debug information for /bin/foo can be
	found in /usr/lib/debug/bin/foo.debug.

	Where this gets interesting is that in some cases a package will
	install a single binary with multiple names, in this case a single
	binary will be install with either hard-links, or symlinks providing
	the alternative names.

	The debug information for these multiple binaries will then be placed
	into the /usr/lib/debug/ tree, and again, links are created so a
	single file can provide debug information for each of the names that
	binary presents as.  An example file system might look like this (the
	[link] could be symlinks, but are more likely hard-links):

	  /bin/
	    foo
	    bar -> foo	[ HARD LINK ]
	    baz -> foo	[ HARD LINK ]
	  /usr/
	    lib/
	      debug/
	        bin/
		  foo.debug
		  bar.debug -> foo.debug	[ HARD LINK ]
		  baz.debug -> foo.debug	[ HARD LINK ]

	In the .build-id tree though we have a problem.  Do we have a single
	entry that links to one of the .debug files?  This would work; a user
	debugging any of the binaries will find the debug information based on
	the build-id, and will get the correct information, after all the
	.debug files are identical (same file linked together).  But there is
	one problem with this approach.

	Sometimes, for *reasons* it's possible that one or more the linked
	binaries might get removed, along with its associated debug
	information.  I'm honestly not 100% certain under what circumstances
	this can happen, but what I observe is that sometime a single name for
	a binary, and its corresponding .debug entry, can be missing.  If this
	happens to be the entry that the .build-id link is pointing at, then
	we have a problem.  The user can no longer find the debug information
	based on the .build-id link.

	The solution that Fedora, RHEL, & SUSE have adopted is to add multiple
	entries in the .build-id tree, with each entry pointing to a different
	name within the debug/ tree, a sequence number is added to the
	build-id to distinguish the multiple entries.  Thus, we might end up
	with a layout like this:

	  /bin/
	    foo
	    bar -> foo	[ HARD LINK ]
	    baz -> foo	[ HARD LINK ]
	  /usr/
	    lib/
	      debug/
	        bin/
		  foo.debug
		  bar.debug -> foo.debug	[ HARD LINK ]
		  baz.debug -> foo.debug	[ HARD LINK ]
	      .build-id/
	        a3/
	          4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug	[ SYMLINK ]
	          4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug	[ SYMLINK ]
	          4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug	[ SYMLINK ]

	With current master GDB, debug information will only ever be looked up
	via the 4b4142d62b399499844924d53e33d4028380db.debug link.  But if
	'foo' and its corresponding 'foo.debug' are ever removed, then master
	GDB will fail to find the debug information.

	Ubuntu seems to have a much better approach for debug information
	handling; they place the debug information directly into the .build-id
	tree, so there only ever needs to be a single entry for any one
	build-id.  I wonder if/how they handle the case where multiple names
	might share a single .debug file, if one of those names is then
	uninstalled, how do they know the .debug file should be retained or
	not ... but I assume that problem either doesn't exist or has been
	solved.

	Anyway, for a while Fedora has carried a patch that handles the
	build-id sequence number logic.  What's presented here is inspired by
	the Fedora patch, but has some changes to fix some issues.

	I'm aware that this is a patch that applies to only some (probably a
	minority) of distros.  However, the logic is contained to only a
	single function in build-id.c, and isn't too complex, so I'm hoping
	that there wont be too many objections.

	For distros that don't have build-id sequence numbers there should be
	no impact.  The sequence number approach still leaves the first file
	without a sequence number, and this is the first file that GDB (after
	this patch) checks for.  The new logic only kicks in if the
	non-sequence numbered first file exists, but is a symlink to a non
	existent file; in this case GDB checks for the sequence numbered files
	instead.

	Tests are included.

	There is a small fix needed for gdb.base/sysroot-debug-lookup.exp,
	after this commit GDB now treats a target: sysroot where the target
	file system is local to GDB the same as if the sysroot had no target:
	prefix.  The consequence of this is that GDB now resolves a symlink
	back to the real filename in the sysroot-debug-lookup.exp test where
	it didn't previously.  As this behaviour is inline with the case where
	there is no target: prefix I think this is fine.

2024-07-18  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: add gdbserver support for vFile::stat packet
	After the previous two commits, this commit adds support for the
	vFile::stat packet to gdbserver.  This is pretty similar to the
	handling for vFile::fstat, but instead calls 'lstat'.

	There's still no users of target_fileio_stat in GDB, that will come in
	a later commit.

2024-07-18  Andrew Burgess  <aburgess@redhat.com>

	gdb: add GDB side target_ops::fileio_stat implementation
	This commit adds the GDB side of target_ops::fileio_stat.  There's an
	implementation for inf_child_target, which just calls 'lstat', and
	there's an implementation for remote_target, which sends a new
	vFile:stat packet.

	The new packet is documented.

	There's still no users of target_fileio_stat as I have not yet added
	support for vFile::stat to gdbserver.  If these packets are currently
	sent to gdbserver then they will be reported as not supported and the
	ENOSYS error code will be returned.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-07-18  Andrew Burgess  <aburgess@redhat.com>

	gdb: add target_fileio_stat, but no implementations yet
	In a later commit I want target_fileio_stat, that is a call that
	operates on a filename rather than an open file descriptor as
	target_fileio_fstat does.

	This commit adds the initial framework for target_fileio_stat, I've
	added the top level target function and the virtual target_ops methods
	in the target_ops base class.

	At this point no actual targets override target_ops::fileio_stat, so
	any attempts to call this function will return ENOSYS error code.

2024-07-18  Cui, Lili  <lili.cui@intel.com>

	X86: Update gas/NEWS for Intel APX.
	gas/ChangeLog:

	        * NEWS: Added "APX_F is fully supportted" to gas/NEWS.

2024-07-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/arm-pseudo-unwind.exp with unix/mthumb
	When running test-case gdb.arch/arm-pseudo-unwind.exp with target board
	unix/mthumb, we run into:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Program received signal SIGILL, Illegal instruction.^M
	0x00400f38 in ?? ()^M
	(gdb) FAIL: $exp: continue to breakpoint: continue to callee
	...

	The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode
	using additional_flags=-marm, but that's overridden by using target board
	unix/mthumb.

	This causes function main to be in thumb mode, and consequently function
	caller (which is called from main) is is executed as if it's in thumb mode,
	while it's actually in arm mode.

	Fix this by adding an intermediate function caller_trampoline in
	arm-pseudo-unwind.c, and hardcoding it to arm mode using
	__attribute__((target("arm"))).

	Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-07-17  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: testsuite: refresh the README
	Update some stale text in the README.  Add few more notes to guide
	future maintenance of the testsuite.

	gas/testsuite/
		* gas/scfi/README: Update text.

2024-07-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb, gdbserver, gdbsupport: use [[noreturn]] instead of ATTRIBUTE_NORETURN
	C++ 11 has a built-in attribute for this, no need to use a compat macro.

	Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875
	Reviewed-by: Lancelot Six <lancelot.six@amd.com>

2024-07-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix indentation in remote.c
	Change-Id: If344acdf703fdd3892f73f75fc891d5473808b79

2024-07-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add ATTRIBUTE_NORETURN to remote_unpush_target
	My IDE (well, clangd) suggested this.  It doesn't hurt to have it.

	Change-Id: If6001983c17dbed3dceebac3078c8deb12c04d6b

2024-07-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.base/complex-parts.exp
	I noticed a lot of escaping in test-case gdb.base/complex-parts.exp.

	Make the test-case more readable by using:
	- string_to_regexp, and
	- {} instead of "".

	Tested on x86_64-linux and aarch64-linux.

2024-07-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass program space to overlay_invalidate_all
	Make the current program space bubble up one level.

	Change-Id: I5ac1e3290ad266730465cd60aa3672d45ffa6475

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to objfile::make
	Make the current program space reference bubble up one level.

	Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to objfile::objfile
	Make the current program space reference bubble up one level.

	Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to entry_point_address
	Make the current program space reference bubble up one level.

	Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to entry_point_address_query
	Make the current program space bubble up one level.

	Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to objfiles_changed
	Make the current program space reference bubble up one level.

	Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to get_current_source_symtab_and_line
	Make the current program space reference bubble up one level.

	Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to have_{full,partial}_symbols
	Make the current program space reference bubble up one level.

	Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: bool-ify a few functions in objfiles.{c,h}
	Change return types to bool, and make a few stylistic adjustments.

	Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to clear_current_source_symtab_and_line
	Make the current program space reference bubble up one level.

	Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make `program_space::free_all_objfiles` use `this`
	Use `this` instead of `current_program_space`.  Presumably, the method
	wants to check the solibs of "this" program space, not the current
	global program space (although they are likely always the same at the
	moment).

	Change-Id: Iaf0534f36bfd47c04c53ed0657da332bdb8fb906
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to no_shared_libraries
	Make the current program space reference bubble up one level.  Pass
	`current_program_space` everywhere, except in some cases where we can
	get the pspace another way, and it's relatively obvious that it's the
	same as the current program space.

	Change-Id: Id86b79f1e44f92a398f49d137d57457174dfa96d
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: split no_shared_libraries, command vs implementation
	The `no_shared_libraries` function is currently used to implement the
	`nosharedlibrary` command, but it also used internally by other
	functions.  This does not make a very good internal API.

	Add the `no_shared_libraries_command` function to implement the CLI
	command.  Remove the unused parameters from `no_shared_libraries`.

	Remove the `from_tty` parameter of `target_pre_inferior`, since it's now
	unused.

	Change-Id: I4fcba5ee1e0f7d250aab1a7b62b9ea16265fe962
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pass program space to objfile_purge_solibs
	Make the current program space reference bubble up one level.

	Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: use objfile::pspace in objfile::unlink
	I think it would make sense to use objfile::pspace instead of the
	current program space here.  It reduces the risks of calling this
	method with the wrong current program space set.

	Change-Id: Id4f3644719f232640c83a1c7f4aa92eaa6af6c5c
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-07-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove some trivial uses of current_program_space
	It is obvious that pspace is the same as current_program_space in these
	cases, due to the set_current_program_space call just above.  The rest
	of the functions probably care about the current program space though,
	so leave the set_cset_current_program_space calls there.

	Change-Id: I3c300decbf2c2fe5f25aa7f697ebcb524432394f

2024-07-15  Hannes Domani  <ssbssa@yahoo.de>

	Fix loading a saved recording
	Currently you get this assertion failure if you try to execute the
	inferior after loading a saved recording, when no recording was done
	earlier in the same gdb session:
	```
	$ gdb -q c -ex "record restore test.rec"
	Reading symbols from c...
	[New LWP 26428]
	Core was generated by `/tmp/c'.
	Restored records from core file /tmp/test.rec.
	(gdb) c
	Continuing.
	../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	```

	The change in step-precsave.exp triggers this bug, since now the
	recording is loaded in a new gdb session, where
	record_full_resume_ptid was never set.

	The fix is to simply set record_full_resume_ptid when resuming a loaded
	recording.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971
	Approved-By: Guinevere Larsen <blarsen@redhat.com>

2024-07-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make objfile::pspace private
	Rename to m_pspace, add getter.  An objfile's pspace never changes, so
	no setter is necessary.

	Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626

2024-07-15  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Fix --no-apply-dynamic-relocs for RELR
	The option only makes sense for RELA relative relocs where the
	addend is present, not for RELR relative relocs.

	Fixes bug 31924.

2024-07-15  Nick Clifton  <nickc@redhat.com>

	Synchronize config.[sub|guess] with the latest versions from the config project.

2024-07-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-14  John David Anglin  <danglin@gcc.gnu.org>

	hppa: Fix handling of relocations that apply to data
	Commit d125f9675372b1ae01ceb1893c06ccb27bc7bf22 introduced a bug
	in handling relocations for data.  The R_PARISC_DIR32 relocation
	operates on 32-bit data and not instructions.  The HOWTO table
	needs to be used to determine the format of relocations that apply
	to data.  The R_PARISC_SEGBASE relocation is another special case
	as it only changes segment base.

	This was noticed in Debian cmor package build.

	2024-07-14  John David Anglin  <danglin@gcc.gnu.org>

	bfd/ChangeLog:

		* elf32-hppa.c (final_link_relocate): Use HOWTO table to
		determine reload format for relocations that apply to data.

2024-07-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-13  Maciej W. Rozycki  <macro@orcam.me.uk>

	Revert "MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64"
	This reverts commit d49f2dd78b08efa4e1ee51f5df5058846c2eb4fa.  It was
	applied unapproved.

	Revert "MIPS/GAS: Omit LI 0 for condition trap"
	This reverts commit bfa257b407270d1c808b31fbd97da779e0fd20d2.  It was
	applied unapproved.

2024-07-13  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix dwarf3 test cases from XPASS to PASS
	In the past, the .align directive generated a label that did not match
	the regular expression, and we set it to XFAIL.
	But now it matches fine so it becomes XPASS. We fix it with PASS.

2024-07-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-12  Sam James  <sam@gentoo.org>

	libiberty: sync with gcc
	This imports the following commits from GCC as of r15-1722-g7682d115402743:
		ca2f7c84927f libiberty: Invoke D demangler when --format=auto
		94792057ad4a Fix up duplicated words mostly in comments, part 1
		20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957].
		52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen
		53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size
		65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal

2024-07-12  Jens Remus  <jremus@linux.ibm.com>

	s390: Avoid reloc overflows on undefined weak symbols (cont)
	This complements and reuses logic from Andreas Krebbel's commit
	896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols").

	Replace relative long addressing instructions of weak symbols, which
	will definitely resolve to zero, with either a load address of 0 or a
	a trapping insn.

	This prevents the PLT32DBL relocation from overflowing in case the
	binary will be loaded at 4GB or more.

	bfd/
		* elf64-s390.c (elf_s390_relocate_section): Replace
		instructions using undefined weak symbols with relative
		addressing to avoid relocation overflows.

	ld/
		* testsuite/ld-s390/s390.exp: Add new test.
		* testsuite/ld-s390/weakundef-2.s: New test.
		* testsuite/ld-s390/weakundef-2.dd: Likewise.

	Reported-by: Alexander Gordeev <agordeev@linux.ibm.com>
	Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>
	Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-07-12  Jens Remus  <jremus@linux.ibm.com>

	s390: Do not replace brcth referencing undefined weak symbol
	Branch Relative on Count High (brcth) is a conditional branch relative
	instruction. It is not guaranteed that it only appears within loops
	that sooner or later will take the branch. It may very well be used to
	check a condition that will prevent the branch from ever being taken.

	bfd/
		* elf64-s390.c (elf_s390_relocate_section): Do not replace brcth
		referencing undefined weak symbol with a trap.

	ld/
		* testsuite/ld-s390/weakundef-1.s: Update test case accordingly.
		* testsuite/ld-s390/weakundef-1.dd: Likewise.

	Fixes: 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols")

2024-07-12  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for sme2.1 zero instructions.
	This patch adds support for following sme2.1 zero instructions and
	the spec is available here [1].

	1. ZERO (single-vector).
	2. ZERO (double-vector).
	3. ZERO (quad-vector).

	The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler
	for most of the sme and sve instructions. But for few of the sme2.1
	zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory.
	To address this a bit "F_VG_REQ" is introduced in this patch, on setting
	F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept
	instruction operand only having VECTOR GROUP symbols.

	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en

2024-07-12  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for sme2.1 movaz instructions.
	This patch adds support for following sme2.1 movaz instructions and
	the spec is available here [1].

	1. MOVAZ (array to vector, two registers).
	2. MOVAZ (array to vector, four registers).
	3. MOVAZ (tile to vector, single).

	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en

2024-07-12  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for sme2.1 luti2 and luti4 instructions.
	This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is
	available here [1]

	1. LUTI2 (two registers) strided.
	2. LUTI2 (four registers) strided.
	3. LUTI4 (two registers) strided.
	4. LUTI4 (four registers) strided.

	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en

2024-07-12  Jan Beulich  <jbeulich@suse.com>

	x86: drop unnecessary \() from bundle tests
	':' isn't permitted in macro parameter names, hence this separator
	construct isn't necessary at the end of labels. Drop its use in such
	cases, for being potentially confusing (and hampering readability, even
	if only a little).

2024-07-12  Jan Beulich  <jbeulich@suse.com>

	x86/APX: remove two inconsistencies
	As indicated in earlier discussion, permitting GOTTPOFF uniformly for
	all legacy non-SIMD insns while at the same time restricting to just
	certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns
	"equal" to their legacy original ones. Doing that adjustment prevents
	another inconsistency, too: In

		data16 neg (%rax)
		data16 neg (%r16)
		data16 {nf} neg (%rax)

	it is not logical why the last one shouldn't be permitted. Bypassing
	that check requires other adjustments, though, to actually properly
	consume (and then squash) the data size prefix.

	While there also add the missing CMP and TEST cases to the test case
	being modified.

2024-07-12  Jan Beulich  <jbeulich@suse.com>

	x86/APX: correct TEST/CTESTcc with 1st operand being a memory one
	While they properly inherited D and C, code processing the reversal of
	operands wasn't updated accordingly (and "reversed" operands also
	weren't tested anywhere).

2024-07-12  YunQiang Su  <syq@gcc.gnu.org>

	MIPS/GAS: Omit LI 0 for condition trap
	MIPSr6 removes condition trap instructions with imm, so we expand
	the instruction like "tne $2,IMM" to
		li	$at,IMM
		tne	$2,$at
	While if IMM is 0, we can use
		tne	$2,$zero
	only.

2024-07-12  YunQiang Su  <syq@gcc.gnu.org>

	MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64
	the ABI section of the triple explicitly asks for N64,
	and in fact GCC also does so.

	It can fix the test failure:
	  FAIL: libdep test: did not get expected output from the linker
	with Debian's mipsisa64r6el-linux-gnuabi64 toolchain.

2024-07-12  Matthieu Longo  <Matthieu.Longo@arm.com>

	aarch64: disable feature b16b16
	Feature b16b16 is currently incomplete and requires re-work.

	Disable the command line option for b16b16, and mark the associated
	tests as XFAIL.

2024-07-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add release notes for 2.43
	ChangeLog
	2024-07-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		* binutils/NEWS (gprofng): Add release notes for 2.43

2024-07-12  Alan Modra  <amodra@gmail.com>

	Re: base64: Add support for targets with byte size > octet size.
	Three extra octets are now expected with the latest change to base64.s.
	They happened to be covered by patterns allowing for zero padding at
	the end of the section, but we don't want to allow fewer octets than
	expected.

		PR 31964
		* testsuite/gas/all/base64.d: Adjust.

2024-07-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-11  Nick Clifton  <nickc@redhat.com>

	base64: Add support for targets with byte size > octet size.
	PR 31964

2024-07-11  Jan Beulich  <jbeulich@suse.com>

	gas: don't open-code IS_WHITESPACE() / IS_NEWLINE()
	Better be consistent in use of the wrapper macros, which imo also helps
	readability.

2024-07-11  Jan Beulich  <jbeulich@suse.com>

	gas: multi-byte warning adjustments
	First input_scrub_next_buffer()'s invocation was wrong, leading to input
	only being checked from the last newline till the end of the current
	buffer. Correcting the invocation, however, leads to duplicate checking
	unless -f (or the #NO_APP equivalent thereof) is in effect. Move the
	invocation to input_file_give_next_buffer(), to restrict it accordingly.

	Then, when macros contain multi-byte characters, warning about them
	again in every expansion isn't useful. Suppress such warnings from
	sb_scrub_and_add_sb().

2024-07-11  Jan Beulich  <jbeulich@suse.com>

	gas: there's no scrubber state 12
	Apparently (beyond what's [easily] visible in git history) when this was
	added there was confusion about scrubber states vs lex[] contents. For
	the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve
	to 12) alone is sufficient. "state" is never set to 12, and it being 12
	also isn't handled anywhere.

2024-07-11  Kévin Le Gouguec  <legouguec@adacore.com>

	gdb: add testcase for invalid record display
	More of a DWARF-generation non-regression test; fixed on the GCC side
	with 2024-06-03 "Implement wrap-around arithmetics in DWARF
	expressions" (f3d6d60d2ae).

	Approved-By: Tom Tromey <tom@tromey.com>

2024-07-11  Cui, Lili  <lili.cui@intel.com>

	X86: Update gas/NEWS for Intel APX.
	gas/ChangeLog:

	        * NEWS: Update gas/NEWS for Intel APX.

2024-07-11  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add platform property/capability extensions
	RISC-V Profiles document defines number of "extensions" that indicate
	certain platform properties/capabilities just like 'Zkt' extension from the
	RISC-V cryptography extensions.

	This commit defines 20 platform property/capability extensions as defined
	in the RISC-V Profiles documentation.

	The only exception: 'Ssstateen' extension is defined separately because it
	defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension.

	This is based on the ratified version of RISC-V Profiles:
	<https://github.com/riscv/riscv-profiles/releases/tag/v1.0>

	[Definition]

	"Main memory regions":
	    Main memory regions (in contrast to I/O or vacant memory regions) with
	    both the cacheability and coherence PMAs.

	[New Unprivileged Extensions]

	1.  'Ziccif'
	    "Main memory regions" support instruction fetch and any instruction
	    fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN)
	    are atomic.
	2.  'Ziccrse'
	    "Main memory regions" provide the eventual success guarantee for
	    LR/SC sequence (RsrvEventual).
	3.  'Ziccamoa'
	    "Main memory regions" support all currently-defined AMO operations
	    including swap, logical and arithmetic operations (AMOArithmetic).
	4.  'Za64rs'
	    For LR/SC instructions, reservation sets are contiguous, naturally
	    aligned and at most 64-bytes in size.
	5.  'Za128rs'
	    Likewise, but reservation sets are at most 128-bytes in size.
	6.  'Zicclsm'
	    Misaligned loads / stores to "main memory regions" are supported.
	    Those include both regular scalar and vector accesses but does not
	    include AMOs and other specialized forms of memory accesses.
	7.  'Zic64b'
	    Cache blocks are (exactly) 64-bytes in size and naturally aligned.

	[New Privileged Extensions]

	1.  'Svbare'
	    "satp" mode Bare is supported.
	2.  'Svade'
	    Page-fault exceptions are raised when a page is accessed when A bit is
	    clear, or written when D bit is clear.
	3.  'Ssccptr'
	    "Main memory regions" support hardware page-table reads.
	4.  'Sstvecd'
	    "stvec" mode Direct is supported.  When "stvec" mode is Direct,
	    "stvec.BASE" is capable of holding any valid 4-byte aligned address.
	5.  'Sstvala'
	    "stval" is always written with a nonzero value whenever possible as
	    specified in the Privileged Architecture documentation
	    (version 20211203: see section 4.1.9).
	6.  'Sscounterenw'
	    For any "hpmcounter" that is not read-only zero, the corresponding bit
	    in "scounteren" is writable.
	7.  'Ssu64xl'
	    "sstatus.UXL" is capable of holding the value 0b10
	    (UXLEN==64 is supported).
	8.  'Shcounterenw'
	    Similar to 'Sscounterenw' but the same rule applies to "hcounteren".
	9.  'Shvstvala'
	    Similar to 'Sstvala' but the same rule applies to "vstval".
	10. 'Shtvala'
	    "htval" is written with the faulting guest physical address as long as
	    permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala').
	11. 'Shvstvecd'
	    Similar to 'Sstvecd' but the same rule applies to "vstvec".
	12. 'Shvsatpa'
	    All translation modes supported in "satp" are also supported in "vsatp".
	13. 'Shgatpa'
	    For each supported virtual memory scheme SvNN supported in "satp", the
	    corresponding "hgatp" SvNNx4 mode is supported.  The "hgatp" mode Bare
	    is also supported.

	[Implications]

	(Due to reservation set size constraints)
	-   'Za64rs' -> 'Za128rs'

	(Due to the fact that a privileged "extension" directly refers a CSR)
	-   'Svbare'       -> 'Zicsr'
	-   'Sstvecd'      -> 'Zicsr'
	-   'Sstvala'      -> 'Zicsr'
	-   'Sscounterenw' -> 'Zicsr'
	-   'Ssu64xl'      -> 'Zicsr'

	(Due to the fact that a privileged "extension" indirectly depends on CSRs)
	-   'Svade' -> 'Zicsr'

	(Due to the fact that a privileged "extension" is a hypervisor property)
	-   'Shcounterenw' -> 'H'
	-   'Shvstvala'    -> 'H'
	-   'Shtvala'      -> 'H'
	-   'Shvstvecd'    -> 'H'
	-   'Shvsatpa'     -> 'H'
	-   'Shgatpa'      -> 'H'

	bfd/
		* elfxx-riscv.c (riscv_implicit_subsets): Updated for property
		and capability extensions.
		(riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm,
		ziccrse, za64rs and za128rs extensions.
		(riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala,
		shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala,
		sstvecd, ssu64xlm svade and svbare extensions.
	gas/
		* testsuite/gas/riscv/imply.d: Updated for property and capability
		extensions.
		* testsuite/gas/riscv/imply.s: Likewise.
		* testsuite/gas/riscv/march-help.l: Likewse.

2024-07-11  Alan Modra  <amodra@gmail.com>

	Re: Add support for a .base64 pseudo-op to gas
	Fixes a failure on rx-elf where the standard data section isn't .data.
	run_dump_test has machinery to translate .data in both options and
	expected results for objdump, but not for readelf -x.

		PR 31964
		* testsuite/gas/all/base64.d: Dump .data with objdump.  Run on
		all targets.

2024-07-11  Jinyang He  <hejinyang@loongson.cn>

	LoongArch: Not alloc dynamic relocs if symbol is absolute
	The absolute symbol should be resolved to const when link to dso or exe.
	Alloc dynamic relocs will cause extra space and R_LARCH_NONE finally.

2024-07-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-11  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Skip -z mark-plt tests on MUSL
	Skip -z mark-plt tests, which are specific to glibc, on MUSL.

		PR ld/31970
		* ld/testsuite/ld-x86-64/x86-64.exp: Skip -z mark-plt tests on
		MUSL.

2024-07-10  Yixuan Chen  <chenyixuan@iscas.ac.cn>

	RISC-V:[gprofng] Minimal support gprofng for riscv.
	ChangeLog: Add target riscv to --enable-gprofng.

	2024-07-04  Yixuan Chen  <chenyixuan@iscas.ac.cn>

	        * configure: Add riscv.
	        * configure.ac: Add riscv.

	gprofng/ChangeLog: Minimal support gprofng for riscv.

	2024-07-04  Yixuan Chen  <chenyixuan@iscas.ac.cn>

	        * gprofng/common/core_pcbe.c (core_pcbe_init): Add RISC-V vendor conditon.
	        (defined): Add riscv.
	        * gprofng/common/cpuid.c (defined): Add risc-v hwprobe.
	        * gprofng/common/gp-defs.h (TOK_A_RISCV): Add riscv.
	        (defined): Add riscv.
	        (ARCH_RISCV): Add riscv.
	        * gprofng/common/hwc_cpus.h: Add RISC-V vendor.
	        * gprofng/common/hwcfuncs.h (HW_INTERVAL_TYPE): Remove useless defination.
	        * gprofng/configure: Add riscv.
	        * gprofng/configure.ac: Add riscv.
	        * gprofng/libcollector/hwprofile.h (ARCH): Add RISC-V register.
	        (CONTEXT_PC): Add RISC-V register.
	        (CONTEXT_FP): Add RISC-V register.
	        (CONTEXT_SP): Add RISC-V register.
	        (SETFUNCTIONCONTEXT):
	        * gprofng/libcollector/libcol_util.c (__collector_util_init): Fix libc open condition.
	        * gprofng/libcollector/libcol_util.h (ARCH): Add RISC-V.
	        * gprofng/libcollector/unwind.c (ARCH): Add RISC-V register.
	        (GET_PC): Add RISC-V register.
	        (GET_SP): Add RISC-V register.
	        (GET_FP): Add RISC-V register.
	        (FILL_CONTEXT):
	        * gprofng/src/DbeSession.cc (ARCH): Add RISC-V.
	        * gprofng/src/Disasm.cc (Disasm::disasm_open): Add RISC-V.
	        * gprofng/src/Experiment.cc (Experiment::ExperimentHandler::startElement): Add RISC-V.
	        * gprofng/src/checks.cc (ARCH): Add RISC-V.
	        * gprofng/src/collctrl.cc (defined): Set risc-v cpu frequency to 1000MHz as default for now, will fix when I find a better method to get cpu frequency.
	        (read_cpuinfo): Add "mvendorid" condition according to risc-v /proc/cpuinfo file content.
	        * gprofng/src/dbe_types.h (enum Platform_t): Add RISC-V.

2024-07-10  Nick Clifton  <nickc@redhat.com>

	Add support for a .base64 pseudo-op to gas
	  PR 31964

2024-07-10  Clément Chigot  <chigot@adacore.com>

	libsframe: remove runstatedir in Makefile.in
	The regeneration was made with Ubuntu automake which has this runstatedir
	additional variable, compared to the usual automake.

	libsframe: accept --target configure option
	Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was
	ignored. This could prevent libsframe.a to be installed in some cases,
	the host fetching its canonical value while the target isn't. Both
	having a different value, INSTALL_LIBBFD would be false.

2024-07-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-09  H.J. Lu  <hjl.tools@gmail.com>

	elf: Add glibc version dependency only if needed
	There is no need to add a needed glibc version if the glibc base version
	includes the needed glibc version.

		PR ld/31966
		* elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base.
		Skip if the glibc base version includes the needed glibc version.
		(_bfd_elf_link_add_glibc_version_dependency): Initialize
		glibc_minor_base to INT_MAX and pass it to
		elf_link_add_glibc_verneed.

2024-07-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add hardware counters for Intel Ice Lake processor
	gprofng/ChangeLog
	2024-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

		* common/hwc_cpus.h: New constant for Intel Ice Lake processor.
		* common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel.
		Set config1 in perf_event_attr. Remove the use of memset.
		* common/core_pcbe.c (core_pcbe_get_eventnum): Return 0.
		* common/hwcentry.h: Add config1.
		* src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1.
		* common/hwcfuncs.c (process_data_descriptor): Set config1.
		* common/hwctable.c: Add the hwc table for Intel Ice Lake processor.
		* src/hwc_intel_icelake.h: New file.

2024-07-09  Indu Bhagat  <indu.bhagat@oracle.com>

	doc: sframe: add appendix for generating stack traces
	Add an appendix to provide a rough outline to show how to generate stack
	traces using the SFrame format.  Such content should hopefully aid the
	reader assimmilate the information in the specification.

	libsframe/
		* doc/sframe-spec.texi: Add new appendix.

2024-07-09  Indu Bhagat  <indu.bhagat@oracle.com>

	include: sframe: update code comments around SFrame FRE stack offsets
	This also amends the incorrect comment:
	    offset3 (intrepreted as FP = CFA + offset2)

	If RA tracking is enabled,  the offset to recover FP is at the third
	index.  The SFrame format (V2) has assumption that if FP is saved on
	stack, RA must have been saved as well.  This is true for the currently
	supported arch Aarch64.  For AMD64, RA tracking per SFrame FRE is not
	necessary.

	In future, when extending support for more architectures, this will
	likely need to be revisited.

	include/
		* sframe.h: Make the comments clearer by enumerating what
		happens per-ABI.

2024-07-09  Indu Bhagat  <indu.bhagat@oracle.com>

	doc: sframe: segregate the ABI/arch-specific components
	The recipe to interpret the SFrame FRE stack offsets is
	ABI/arch-specific.

	Although, there is other information in the specification that is
	ABI-specific (like pauth_key usage in AArch64), those pieces of
	information are now assimmilated in the SFrame specification in a way
	that it is fairly difficult to carve then out into a ABI/arch-specific
	section without confusing the readers.

	For future though, the specification must strive to keep the generic
	parts and ABI/arch-specific parts clearly laid out in separate sections.

	libsframe/
		* doc/sframe-spec.texi: Reorder and adapt the contents.

2024-07-09  H.J. Lu  <hjl.tools@gmail.com>

	LTO: Properly check wrapper symbol
	Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper
	symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO.

	Note: Calling unwrap_hash_lookup to check for the wrapper symbol works
	only when there is a definition for the wrapped symbol since references
	to the wrapped symbol have been redirected to the wrapper symbol.

	bfd/

		PR ld/31956
		* linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol
		for wrapper symbol.

	include/

		PR ld/31956
		* bfdlink.h (bfd_link_hash_entry): Add wrapper_symbol.

	ld/

		PR ld/31956
		* plugin.c (get_symbols): Set wrap_status to wrapper if
		wrapper_symbol is set.
		* testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests.
		* testsuite/ld-plugin/pr31956a.c: New file.
		* testsuite/ld-plugin/pr31956b.c: Likewise.

2024-07-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-08  srinath  <srinath.parvathaneni@arm.com>

	aarch64: Add support for sve2p1 pmov instruction.
	This patch adds support for followign SVE2p1 instruction, spec is available here [1].

	1. PMOV (to vector)
	2. PMOV (to predicate)

	Both pmov (to vector) and pmov (to predicate) have destination scalable vector
	register and source scalable vector register respectively as an operand with no
	suffix and optional index. To handle this case we have added 8 new operands in
	this patch.

	AARCH64_OPND_SVE_Zn0_INDEX,      /* Zn[index], bits [9:5].  */
	AARCH64_OPND_SVE_Zn1_17_INDEX,    /* Zn[index], bits [9:5,17].  */
	AARCH64_OPND_SVE_Zn2_18_INDEX,    /* Zn[index], bits [9:5,18:17].  */
	AARCH64_OPND_SVE_Zn3_22_INDEX,    /* Zn[index], bits [9:5,18:17,22].  */
	AARCH64_OPND_SVE_Zd0_INDEX,      /* Zn[index], bits [4:0].  */
	AARCH64_OPND_SVE_Zd1_17_INDEX,    /* Zn[index], bits [4:0,17].  */
	AARCH64_OPND_SVE_Zd2_18_INDEX,    /* Zn[index], bits [4:0,18:17].  */
	AARCH64_OPND_SVE_Zd3_22_INDEX,    /* Zn[index], bits [4:0,18:17,22].  */

	Since the index of the <Zd> operand is optional, the index part is
	dropped in disassembly in both the cases of "no index" or "zero index".

	As per spec: PMOV <Zd>{[<imm>]}, <Pn>.D
	             PMOV <Pn>.D, <Zd>{[<imm>]}

	Example1:
		Assembly: pmov z5[0], p6.d
		Disassembly: pmov z5, p6.d

	        Assembly: pmov z5, p6.d
	        Disassembly: pmov z5, p6.d

	Example2:
		Assembly: pmov p4.b, z5[0]
		Disassembly: pmov p4.b, z5

	        Assembly: pmov p4.b, z5
	        Disassembly: pmov p4.b, z5
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

2024-07-08  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for sve2p1 tbxq instruction.
	This patch adds support for SVE2p1 "tbxq" instruction, spec is available here [1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

	aarch64: Add support for sve2p1 zipq[1-2] instructions.
	This patch adds support for SVE2p1 "zipq1" and "zipq2" instructions, spec is
	available here [1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

	aarch64: Add support for sve2p1 uzpq[1-2] instructions.
	This patch adds support for SVE2p1 "uzpq1" and "uzpq2" instructions, spec is
	available here [1]
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

	aarch64: Add support for sve2p1 tblq instruction.
	This patch adds support for SVE2p1 "tblq" instruction, spec is available here [1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

	aarch64: Add support for sve2p1 orqv instruction.
	This patch adds support for SVE2p1 "orqv" instruction, spec available here [1].
	[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en

2024-07-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-06  Alan Modra  <amodra@gmail.com>

	Re: LoongArch: Add DT_RELR support
	Fix commit d89ecf33ab testsuite breakage.

		* testsuite/lib/binutils-common.exp (supports_dt_relr): Correct.

2024-07-06  Alan Modra  <amodra@gmail.com>

	objcopy bfd_map_over_sections and global status
	This patch started life as a relatively simple change to fix some
	unimportant objcopy memory leaks, but expanded into a larger patch
	when I was annoyed by the awkwardness of passing data when using
	bfd_map_over_sections.  A simple loop over sections is much more
	convenient, and we really don't need the abstraction layer.  Sections
	in a list isn't going to disappear any time soon.

	The patch also removes use of the global "status" variable by all but
	the top-level functions called from main.

		* objcopy.c (filter_symbols): Return success as a bool.  Pass
		symcount as a pointer, updated on return.
		(merge_gnu_build_notes): Similarly return a bool and add newsize
		param with updated smaller section size.
		(setup_bfd_headers): Return bool success rather than setting
		"status" on failure.
		(setup_section): Likewise.
		(copy_relocations_in_section, copy_section): Likewise, and adjust
		params.
		(mark_symbols_used_in_relocations): Likewise, and free memory
		on failure path.  Don't call bfd_fatal.
		(get_sections): Delete function.
		(copy_object): Don't use bfd_map_over_sections, instead use a
		loop allowing easy detection of failure status.  Free memory on
		error paths.
		(copy_archive): Return bool success rather than setting "status"
		on failure.
		(copy_file): Set "status" here.
		* testsuite/binutils-all/strip-13.d: Adjust to suit.

2024-07-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-05  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add Debug Feature Register 2 (ID_AA64DFR2_EL1)
	This patch also adds relevant tests. Regression tested on aarch64-none-elf,
	and no regression found.

2024-07-05  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add STEP2 feature and its associated registers
	AArch64 defines new registers for the feature step2 (Enhanced Software Step
	Extension). step2 is an Armv9.5-A feature.

	This patch also adds relevant tests. Regression tested on aarch64-none-elf,
	and no regression found.

2024-07-05  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add SPMU2 feature and its associated registers
	AArch64 defines new registers for the feature spmu2 (System Performance
	Monitors Extension version 2). spmu2 is an Armv9.5-A feature.

	This patch also adds relevant tests. Regression tested on aarch64-none-elf,
	and no regression found.

2024-07-05  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add E3DSE feature and its associated registers
	AArch64 defines new registers for the feature e3dse (Delegated SError
	exceptions for EL3): vdisr_el3 and vdisr_el3. e3dse is an Armv9.5-A
	feature.

	This patch also adds relevant tests. Regression tested on aarch64-none-elf,
	and no regression found.

2024-07-05  Lingling Kong  <lingling.kong@intel.com>

	x86-64: Fix support for APX NF TLS IE with 2 operands
	Added the restriction in assemble for APX TLS IE that the destination
	can only be a register.

	gas/

	      * config/tc-i386.c (md_assemble): Added stricter restrictions
	      for APX TLS IE.

2024-07-05  Jan Beulich  <jbeulich@suse.com>

	RISC-V: avoid use of match_opcode() in riscv_insn_types[]
	As of 27b33966b18e ("RISC-V: disallow x0 with certain macro-insns") the
	.match_func field may be NULL for entries used for assembly only, which
	is the case for the entire table. With .match and .mask both zero the
	function would only ever succeed anyway. Save almost a hundred base
	relocations in the final executable by using NULL instead.

	aarch64: fix build with old glibc
	As was pointed out several times before, old glibc declares index(),
	resulting in warnings from -Wshadow, in turn failing the build due to
	-Werror.

2024-07-05  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Add DT_RELR tests
	Most tests are ported from AArch64.

	The relr-addend test is added to make sure the addend (link-time address)
	is correctly written into the relocated section.  Doing so is not
	strictly needed for RELA, but strictly needed for RELR).

2024-07-05  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Add DT_RELR support
	The logic is same as a71d87680110 ("aarch64: Add DT_RELR support").

	As LoongArch does not have -z dynamic-undefined-weak, we don't need to
	consider UNDEFWEAK_NO_DYNAMIC_RELOC.

	The linker relaxation adds another layer of complexity.  When we delete
	bytes in a section during relaxation, we need to fix up the offset in
	the to-be-packed relative relocations against this section.

2024-07-05  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Make protected function symbols local for -shared
	On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols
	as preemptible.  See the comment above LARCH_REF_LOCAL for detailed
	explanation.

2024-07-05  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Fix bad reloc with mixed visibility ifunc symbols in shared libraries
	With a simple test case:

	    .globl  ifunc
	    .globl  ifunc_hidden
	    .hidden ifunc_hidden
	    .type   ifunc, %gnu_indirect_function
	    .type   ifunc_hidden, %gnu_indirect_function

	    .text
	    .align  2
	    ifunc:  ret
	    ifunc_hidden: ret

	    test:
	      bl ifunc
	      bl ifunc_hidden

	"ld -shared" produces a shared object with one R_LARCH_NONE (instead of
	R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc".
	It's because the indices in .plt and .rela.plt mismatches for
	STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a
	STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of
	loongarch_elf_finish_dynamic_symbol.  Fix the issue by reordering .plt
	so the indices no longer mismatch.

2024-07-05  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64
	We were converting R_LARCH_32 to R_LARCH_RELATIVE for ELFCLASS64:

	    $ cat t.s
	    .data
	    x:
	        .4byte x
		.4byte 0xdeadbeef
	    $ as/as-new t.s -o t.o
	    $ ld/ld-new -shared t.o
	    $ objdump -R
	    a.out:     file format elf64-loongarch

	    DYNAMIC RELOCATION RECORDS
	    OFFSET           TYPE              VALUE
	    00000000000001a8 R_LARCH_RELATIVE  *ABS*+0x00000000000001a8

	But this is just wrong: at runtime the dynamic linker will run
	*(uintptr *)&x += load_address, clobbering the next 4 bytes of data
	("0xdeadbeef" in the example).

	If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected
	by the Glibc dynamic linker anyway.  And it does not make too much sense
	to modify Glibc to support it.  So we can just reject it like x86_64:

	    relocation R_X86_64_32 against `.data' can not be used when making a
	    shared object; recompile with -fPIC

	or RISC-V:

	    relocation R_RISCV_32 against non-absolute symbol `a local symbol'
	    can not be used in RV64 when making a shared object

2024-07-05  Cui, Lili  <lili.cui@intel.com>

	x86: Correct position of ".s" for CCMPcc in disassembler
	Added new macro %SW to CCMPcc to print ".s" after the mnemonic.

	Before:
	ccmpbl {dfv=}.s %edx,%eax

	After:
	ccmpbl.s {dfv=} %edx,%eax

	gas/ChangeLog:

	        * testsuite/gas/i386/x86-64-pseudos-apx.d: Add tests for CCMPcc.
	        * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex.h: Added %SW for CCMPcc swap operands.
	        * i386-dis.c (struct dis386): Added %SW.
	        (putop): Handle %SW.

2024-07-05  Cui, Lili  <lili.cui@intel.com>

	x86: Add {load}/{store} tests for apx instructions.
	gas/ChangeLog:

	        * testsuite/gas/i386/x86-64.exp: Add {load}/{store} tests for apx
		instructions.
	        * testsuite/gas/i386/x86-64-pseudos-apx.d: New test.
	        * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto.

2024-07-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-04  Sun Sunny  <sunny.sun@corelabtech.com>

	RISC-V: Fix BFD_RELOC_RISCV_PCREL_LO12_S patch issue
	In commit dff565fcca8137954d6ad571ef39f6aec5c0429c, the fixups
	for PCREL_LO12_I and PCREL_LO12_S were mixed, so the "IMM"
	field were applied to incorrect position, this caused incorrect
	src registers to be encoded.

	gas/
		* config/tc-riscv.c (md_apply_fix): Fix PCREL_LO12_S issue.
		* testsuite/gas/riscv/ixup-local.s: Updated for PCREL_LO12_S cases.
		* testsuite/gas/riscv/fixup-local-relax.d: Likewise.
		* testsuite/gas/riscv/fixup-local-norelax.d: Likewise.

2024-07-04  Lifang Xia  <lifang_xia@linux.alibaba.com>

	RISC-V: hash with segment id and pcrel_hi address while recording pcrel_hi
	When the same address across different segments (sections) needs to be
	recorded, it will overwrite the slot, leading to a memory leak. To ensure
	uniqueness, the segment (section) ID needs to be included in the hash key
	calculation.

	gas/
		* config/tc-riscv.c (riscv_pcrel_hi_fixup): New "const asection *sec".
		(riscv_pcrel_fixup_hash): make sec->id and e->adrsess as the
		hash key.
		(riscv_pcrel_fixup_eq): Check sec->id at first.
		(riscv_record_pcrel_fixup): New member "sec".
		(md_apply_fix) <case BFD_RELOC_RISCV_PCREL_HI20>: Likewise.
		(md_apply_fix) <case BFD_RELOC_RISCV_PCREL_LO12_I>: Likewise.

2024-07-04  Andre Vieira  <andre.simoesdiasvieira@arm.com>

	mve: Fix encoding for vcvt[bt] single-half float conversion instructions
	The encoding was previously not taking into account that the Quad vector
	registers were being encoded using their Q-register numbers rather than their
	D-register equivalent (multiply by 2).

	gas/

		* config/tc-arm.c (do_neon_cvttb_1): Use Q-register vector number
		rather than their D-register equivalent.

	gas/testsuite/

		* gas/arm/mve-vcvt-3.d: Correct expected values in test.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Validate SFrame RA tracking and fixed RA offset
	Verify all architectures participating in SFrame generation do define
	the mandatory SFrame return address (RA) tracking predicate function
	sframe_ra_tracking_p. Do so by explicitly not testing for the macro
	SFRAME_FRE_RA_TRACKING as otherwise required.

	Verify that architectures not using SFrame RA tracking specify a valid
	fixed RA offset.

	gas/
		* gen-sframe.c (output_sframe_internal): Validate SFrame
		RA tracking and fixed RA offset.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Test predicate whether SFrame RA tracking is used
	The existence of the macro SFRAME_FRE_RA_TRACKING only ensures the
	existence of the macro SFRAME_CFA_RA_REG and the predicate function
	sframe_ra_tracking_p. It does not indicate whether SFrame RA tracking
	is actually used.

	Test the return value of the SFrame RA tracking predicate function
	sframe_ra_tracking_p to determine whether RA tracking is used.

	This aligns the logic in functions get_fre_num_offsets and
	output_sframe_row_entry to the one used in all other places.

	gas/
		* gen-sframe.c (get_fre_num_offsets, output_sframe_row_entry):
		Test predicate to determine whether SFrame RA tracking is used.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Don't skip SFrame FDE if .cfi_register specifies SP register
	Neither ".cfi_offset SP, <offset>", ".cfi_register SP, <regno>", nor
	".cfi_val_offset SP, <offset>" alter the tracking information to recover
	the stack pointer (SP). Doing so would need an explicit .cfi_def_cfa,
	which SFrame tracks.

	The stack pointer (SP) register contents on entry can be reconstructed
	from the SFrame CFA tracking information using information from the
	current and initial SFrame FREs of the SFrame FDE:

	1. Compute CFA from the current CFA base register (SP or FP) and CFA
	   offset from the SFrame CFA tracking information from the SFrame FRE
	   for the current instruction address:

	     CFA = <current_base_reg> + <current_cfa_offset>

	2. Compute SP from the current CFA and the CFA offset from the SFrame
	   CFA tracking information from the initial SFrame FRE of the FDE:

	     SP = CFA - <initial_cfa_offset>

	While at it add comments to the processing of .cfi_offset and
	.cfi_val_offset that the SP can be reconstructed from the CFA tracking
	information.

	gas/
		* gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame
		FDE if .cfi_register specifies SP register.
		(sframe_xlate_do_offset,sframe_xlate_do_val_offset): Add comment
		that this is likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking
	Do not skip SFrame FDE if .cfi_register specifies RA register without
	RA tracking being actually used. Without RA tracking the register
	contents can always be restored from the stack using the fixed
	RA offset from CFA.

	gas/
		* gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame
		FDE if .cfi_register specifies RA register without RA tracking
		being used.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Skip SFrame FDE if .cfi_window_save
	CFI opcode DW_CFA_AARCH64_negate_ra_state is multiplexed with
	DW_CFA_GNU_window_save. Process DW_CFA_AARCH64_negate_ra_state on
	AArch64. Skip generation of SFrame FDE otherwise with the following
	warning message:

	  skipping SFrame FDE; .cfi_window_save

	gas/
		* gen-sframe.c: Skip SFrame FDE if .cfi_window_save.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Skip SFrame FDE if FP without RA on stack
	The SFrame format cannot represent the frame pointer (FP) being saved
	on the stack without the return address (RA) also being saved on the
	stack, if RA tracking is used.

	A SFrame FDE is followed by 1-3 offsets with the following information:

	Without RA tracking:
	1. Offset from base pointer (SP or FP) to locate the CFA
	2. Optional: Offset to CFA to restore the frame pointer (FP)

	With RA tracking:
	1. Offset from base pointer (SP or FP) to locate the CFA
	2. Optional: Offset to CFA to restore the return address (RA)
	3. Optional: Offset to CFA to restore the frame pointer (FP)

	When RA tracking is used and a FDE is followed by two offsets the
	SFrame format does not provide any information to distinguish whether
	the second offset is the RA or FP offset. SFrame assumes the offset to
	be the RA offset, which may be wrong.

	Therefore skip generation of SFrame FDE information and print the
	following warning, if RA tracking is used and the FP is saved on the
	stack without the RA being saved as well:

	  skipping SFrame FDE; FP without RA on stack

	gas/
		* gen-sframe.c (sframe_do_fde): Skip SFrame FDE if FP without RA
		on stack, as the SFrame format cannot represent this case.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: User readable warnings if SFrame FDE is not generated
	The following generic warning message, which is printed whenever the
	assembler skips generation of SFrame FDE, is not very helpful for the
	user:

	  skipping SFrame FDE; CFI insn <name> (0x<hexval>)

	Whenever possible print meaningful warning messages, when the assembler
	skips generation of SFrame FDE:

	- skipping SFrame FDE; non-SP/FP register <regno> in .cfi_def_cfa
	- skipping SFrame FDE; non-SP/FP register <regno> in
	  .cfi_def_cfa_register
	- skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register
	  in effect
	- skipping SFrame FDE; {FP|RA} register <regno> in .cfi_val_offset
	- skipping SFrame FDE; {SP|FP|RA} register <regno> in in .cfi_register
	- skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE
	  state
	- skipping SFrame FDE; non-default RA register <regno>

	gas/
		* gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): New macro for
		invalid SFrame FRE CFA base register value of -1.
		* gen-sframe.c: User readable warnings if SFrame FDE is not
		generated.

	gas/testsuite/
		* gas/cfi-sframe/common-empty-1.d: Update generic SFrame test
		case to updated warning message texts.
		* gas/cfi-sframe/common-empty-2.d: Likewise.
		* gas/cfi-sframe/common-empty-3.d: Likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Refactor SFrame CFI opcode DW_CFA_register processing
	Refactor SFrame processing of CFI opcode DW_CFA_register into a separate
	function. This harmonizes the CFI opcode processing.

	While at it reword the comment on CFI opcodes that are not processed.

	This is a purely mechanical change.

	gas/
		* gen-sframe.c (sframe_do_cfi_insn, sframe_xlate_do_register):
		Refactor SFrame CFI opcode DW_CFA_register processing.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Warn if SFrame FDE is skipped due to non-default return column
	Print a warning message if SFrame FDE is skipped due to a non-default
	DWARF return column (i.e. return address (RA) register number). This
	may be caused by the use of CFI directive .cfi_return_column with a
	non-default return address (RA) register number in the processed
	assembler source code.

	  Warning: skipping SFrame FDE due to non-default DWARF return column

	gas/
		* gen-sframe.c: Warn if SFrame FDE is skipped due to non-default
		DWARF return column.

	gas/testsuite/
		* gas/cfi-sframe/common-empty-3.d: Update test case to expect
		for new warning message when SFrame FDE is skipped due to
		a non-default DWARF return column.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Skip SFrame FDE if CFI specifies non-FP/SP base register
	Do not generate SFrame FDE if DWARF CFI directives .cfi_def_cfa or
	.cfi_def_cfa_register specify a CFA base register number other than
	the architecture-specific stack-pointer (SP) or frame-pointer (FP)
	register numbers.

	This also causes the assembler to print a warning message, so that
	skipping of the SFrame FDE does not occur silently.

	Update the generic ld SFrame test case to be architecture independent.
	Do not use CFI directive .cfi_def_cfa, as the specified CFA base
	register number is not a valid SP/FP register number on all
	architectures. An invalid SP/FP register number will now cause the
	assembler to print a warning message and skip SFrame FDE generation.
	Remove the offending CFI directive, that cannot be coded architecture-
	independent, as the test case requires SFrame information to be
	generated. This was reported by the Linaro-TCWG-CI for AArch64.

	gas/
		* gen-sframe.c: Skip SFrame generation if CFI specifies
		non-FP/SP base register.

	ld/testsuite/
		* ld-sframe/discard.s: Update generic SFrame test case to be
		architecture independent.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Print DWARF call frame insn name in SFrame warning message
	SFrame generation prints the DWARF call frame instruction opcode in
	hexadecimal. Leverage get_DW_CFA_name to additionally print the
	DWARF call frame instruction name in human readable form, while also
	respecting fake CFI types. Use "(unknown)", if the DWARF call frame
	instruction name is not known.

	While at it use the terminology "instruction" for these DW_CFA_*, as
	suggested by Indu.

	This changes the following assembler SFrame generation warning message
	as follows:

	Old:
	Warning: skipping SFrame FDE due to DWARF CFI op 0x<hexval>

	New:
	Warning: skipping SFrame FDE; CFI insn <name> (0x<hexval>)

	gas/
		* gen-sframe.c (sframe_get_cfi_name): New function to get the
		DWARF call frame instruction name for a DWARF call frame
		instruction opcode.
		(sframe_do_cfi_insn): Use sframe_get_cfi_name to print the
		DWARF call frame instruction name for the DWARF call frame
		instruction opcode in the warning message.

	gas/testsuite/
		* gas/cfi-sframe/common-empty-1.d: Update expected SFrame
		warning message text for DWARF call frame insn name.
		* gas/cfi-sframe/common-empty-2.d: Likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	readelf/objdump: Display SFrame fixed RA offset as 'f' in dump
	For the SFrame FRE frame-pointer (FP) offset from CFA a 'u' is displayed
	if it is unavailable.

	For the SFrame FRE return-address (RA) offset from CFA a 'u' was
	displayed if the ABI uses a fixed RA offset from CFA. By chance a
	'u' was also displayed if the RA offset is unavailable, as the string
	buffer was not initialized after formatting the FP offset. Note that it
	could not occur that the FP offset was erroneously displayed as RA
	offset, as the SFrame format cannot have a FRE with FP offset without
	RA offset.

	For the FRE RA offset display 'f' if the ABI uses a fixed RA offset
	from CFA. Display a 'u' if it is unavailable.

	libsframe/
		* sframe-dump.c: Display SFrame fixed RA offset as 'f' in dump.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe-common-4.d: Test for RA displayed
		either as 'u' (if RA tracking) or as 'f' (fixed RA offset if no
		RA tracking).
		* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for RA displayed
		as 'f' (fixed RA offset), as x86-64 does not use RA tracking.
		* gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise.
		* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.

	ld/testsuite/
		* ld-x86-64/sframe-plt-1.d: Test for RA displayed as 'f' (fixed
		RA offset), as x86-64 does not use RA tracking.
		* ld-x86-64/sframe-simple-1.d: Likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	readelf/objdump: Dump SFrame CFA fixed FP and RA offsets
	The SFrame format allows architectures to specify fixed offsets from the
	CFA, if any, from which the frame pointer (FP) and/or return address
	(RA) may be recovered. These offsets are stored in the SFrame header.

	For instance the SFrame generation in the assembler for x86 AMD64
	specifies a fixed offset from the CFA, from which the return address
	(RA) may be recovered.

	When dumping the SFrame header, for instance in readelf/objdump with
	option --sframe, do also dump the specified fixed offsets from the CFA,
	if any, from which the frame pointer (FP) and return address (RA) may
	be recovered.

	Update the common SFrame test case verification patterns to allow for
	the optional dumping of the CFA fixed FP/RA offsets. Update the x86-
	specific SFrame and SCFI test case verification patterns to require a
	CFA fixed RA offset of -8.

	libsframe/
		* sframe-dump.c: Dump CFA fixed FP and RA offsets.

	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe-common-1.d: Test for optional fixed
		FP and RA offsets.
		* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for fixed
		RA offset.
		* gas/cfi-sframe/common-empty-1.d: Test for optional fixed
		FP and RA offsets.
		* gas/cfi-sframe/common-empty-2.d: Likewise.
		* gas/cfi-sframe/common-empty-3.d: Likewise.
		* gas/scfi/x86_64/scfi-cfi-sections-1.d: Test for SFrame fixed
		RA offset.
		* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.

	ld/testsuite/
		* ld-x86-64/sframe-plt-1.d: Test for SFrame fixed RA offset.
		* ld-x86-64/sframe-simple-1.d: Likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	gas: Enhance arch-specific SFrame configuration descriptions
	Explicitly mention "SFrame" in the descriptions for the architecture-
	specific SFrame configuration macros, variables, and functions.

	Use the term "frame pointer" (FP) instead of "base pointer". This aligns
	with the terminology used in the SFrame specification. Additionally it
	helps not to confuse "base-pointer register" with the term "BASE_REG"
	used in the specification to denote either the SP or FP register.

	Specify what the SFRAME_CFA_*_REG register numbers are used for:
	- SP (stack pointer): CFA tracking
	- FP (frame pointer): CFA and FP tracking
	- RA (return address): RA tracking

	Align the descriptions for definitions in the source files to the
	declarations in the header files.

	gas/
		* config/tc-aarch64.h: Enhance architecture-specific SFrame
		configuration descriptions.
		* config/tc-aarch64.c: Likewise.
		* config/tc-i386.h: Likewise.
		* config/tc-i386.c: Likewise.

2024-07-04  Jens Remus  <jremus@linux.ibm.com>

	x86: Remove unused SFrame CFI RA register variable
	gas/
		* config/tc-i386.c (x86_sframe_cfa_ra_reg): Remove.

2024-07-04  Cui, Lili  <lili.cui@intel.com>

	Support APX CFCMOV
	The CMOVcc instruction proposed by EVEX has four different forms,
	corresponding to the four possible combinations of EVEX.ND and EVEX.NF
	values.

	In the encoder part, when the CFCMOV template supports EVEX_NF, it means that
	it requires EVEX.NF to be 1.

	In the decoder part, CFCMOV_Fixup is used to reverse source and destination
	operands in the 2-operand case.

	gas/ChangeLog:

	        * config/tc-i386.c (build_apx_evex_prefix): Set NF bit for cfcmov
	        when the insn template supports EVEX_NF.
	        * testsuite/gas/i386/x86-64-apx-inval.l: Add invalid tests for cfcmov.
	        * testsuite/gas/i386/x86-64-apx-inval.s: Ditto.
	        * testsuite/gas/i386/x86-64.exp: Add tests for cfcmov and cmov.
	        * testsuite/gas/i386/x86-64-apx-cfcmov-intel.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-cfcmov.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-cfcmov.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex-prefix.h: Add cfcmov instructions.
	        * i386-dis.c (CFCMOV_Fixup): Special handling of cfcmov.
	        (putop): Print 'cf' for cfcmov instructions.
	        * i386-opc.h (EVEX_NF): New.
	        * i386-opc.tbl: Add cfcmov instructions.
	        * i386-mnem.h: Regerated.
	        * i386-tbl.h: Regerated.

2024-07-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-03  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Tidy and complete testing of all architecture imply rules.
	gas/
		* testsuite/gas/riscv/imply.s: New testcase for all imply cases.
		* testsuite/gas/riscv/imply.d: Likewise.
		* testsuite/gas/riscv/march-imply-i.s: Renamed to
		imply-zicsr-zifencei.s.
		* testsuite/gas/riscv/march-imply-i2p0-02.d: Renamed to
		imply-zicsr-zifencei-i2p0-misa-spec-2p2.d.
		* testsuite/gas/riscv/march-imply-i2p1-01.d/l: Renamed to
		imply-zicsr-zifencei-i2p1-misa-spec-20191213.d.
		* testsuite/gas/riscv/march-imply-i2p0-01.d: Removed.
		Combined into new imply testcase.
		* testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise.
		* testsuite/gas/riscv/march-imply-a.d: Likewise.
		* testsuite/gas/riscv/march-imply-b.d: Likewise.
		* testsuite/gas/riscv/march-imply-f.d: Likewise.
		* testsuite/gas/riscv/march-imply-g.d: Likewise.
		* testsuite/gas/riscv/march-imply-h.d: Likewise.
		* testsuite/gas/riscv/march-imply-q.d: Likewise.
		* testsuite/gas/riscv/march-imply-smcsrind.d: Likewise.
		* testsuite/gas/riscv/march-imply-smstateen.d: Likewise.
		* testsuite/gas/riscv/march-imply-unsupported.d: Likewise.
		* testsuite/gas/riscv/march-imply-v.d: Likewise.
		* testsuite/gas/riscv/march-imply-zcd.d: Likewise.
		* testsuite/gas/riscv/march-imply-zcf.d: Likewise.

2024-07-03  Alan Modra  <amodra@gmail.com>

	Avoid possible signed overflow in decode_local_label_name
	Matches what both fb_label_name and dollar_label_name use.

		* symbols.c (decode_local_label_name): Use unsigned variables.

2024-07-03  Nelson Chu  <nelson@rivosinc.com>

	gas/doc/riscv: Fixed typo of `.insn cj' format
	gas/
		* doc/c-riscv.texi: Fixed typo of `.insn cj' format.

2024-07-03  Lingling Kong  <lingling.kong@intel.com>

	x86-64: Support APX NF TLS IE with 2 operands
	Support APX NF TLS IE with 2 operands.Verify it with ld and gold.

	gas/

		* config/tc-i386.c (md_assemble): Allow APX NF TLS IE with
		2 operands.
		* testsuite/gas/i386/x86-64-gottpoff.d: Updated.
		* testsuite/gas/i386/x86-64-gottpoff.s: Add APX NF TLS IE
		tests with 2 operands.

	gold/

		* testsuite/x86_64_ie_to_le.s: Add APX NF TLS IE tests with
		2 operands.
		* testsuite/x86_64_ie_to_le.sh: Updated.

	ld/

		* testsuite/ld-x86-64/tlsbindesc.s: Add APX NF TLS IE tests
		with 2 operands.
		* testsuite/ld-x86-64/tlsbindesc.d: Updated.
		* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.

2024-07-03  Nelson Chu  <nelson@rivosinc.com>

	gas/doc/riscv: Fixed syntax of `.option arch' when reseting whole architecture
	gas/
		* doc/c-riscv.texi: Fixed syntax of `.option arc'h when reseting whole
		architecture.  Don't need the `=' before ISA.

2024-07-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-02  Tom Tromey  <tromey@adacore.com>

	Accept unnamed array in gdb.ada/limited-length.exp
	Some compiler changes I'm working on cause a regression in
	gdb.ada/limited-length.exp -- with the changes, the array type is
	nameless and so is not mentioned in the max-value-size error message.

	Because the array type is nameless in the source code, this seems like
	an improvement to me, and so this patch changes the test to accept
	either form.

2024-07-02  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Use lwp field in ptid for AIX.
	Currently in AIX, the private data is used to maintain the kernel thread ID.

	This is a patch to trim the need to have another field in the private data of a thread in AIX.

	We want to use the lwp field to represent the kernel thread ID to match or
	make things similar to the Linux targets.

2024-07-02  konglin1  <lingling.kong@intel.com>

	x86-64: Verify that TLS IE works with APX NF
	Verify that

	{nf} add %reg1, foo@gottpoff(%rip), %reg2
	{nf} add foo@gottpoff(%rip), %reg, %reg2

	work correctly with ld and gold.

	gas/

		* testsuite/gas/i386/x86-64-gottpoff.d: Updated.
		* testsuite/gas/i386/x86-64-gottpoff.s: Add tests for
		"{nf} add %reg1, foo@gottpoff(%rip), %reg2" and
		"{nf} add foo@gottpoff(%rip), %reg, %reg2".

	gold/

		* testsuite/x86_64_ie_to_le.s: Add tests for
		"{nf} add %reg1, foo@gottpoff(%rip), %reg2" and
		"{nf} add foo@gottpoff(%rip), %reg, %reg2".
		* testsuite/x86_64_ie_to_le.sh: Updated.

	ld/

		* testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF
		for APX NF tests.
		* testsuite/ld-x86-64/tlsbindesc.d: Updated.
		* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.

	Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>

2024-07-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-07-01  H.J. Lu  <hjl.tools@gmail.com>

	ld: Move foo before delete in dl5.cc
		* testsuite/ld-elf/dl5.cc (main): Move foo before delete.

2024-07-01  Claudiu Zissulescu  <claziss@gmail.com>

	MAINTAINERS: Update my e-mail address

2024-07-01  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Remove unused code in ld test suite
	These seems some left over from MIPS code and they do not make any
	sense for LoongArch.

2024-07-01  Alan Modra  <amodra@gmail.com>

	PR31941 objcopy --globalize-symbol
	I think FILE symbols are special, and I can't see why anyone would
	want them to be made global.  The fact that no one has reported this
	bug since commit 7b4a0685e80a in 2005 supports that claim.

		PR 31941
		* objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to
		be made global.

2024-07-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-30  H.J. Lu  <hjl.tools@gmail.com>

	ld: Avoid folding new and delete pairs
	GCC 15 may fold new and delete pairs, like

	  A *bb = new A[10];
	  delete [] bb;
	  bb = new (std::nothrow) A [10];
	  delete [] bb;

	as shown in

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712

	Avoid folding new and delete pairs by adding a function call between new
	and delete.

		* testsuite/ld-elf/dl5.cc: Include "dl5.h".
		(A): Removed.
		Call foo between new and delete.
		* testsuite/ld-elf/dl5.h: New file.
		* testsuite/ld-elf/new.cc: Include "dl5.h".
		(foo): New function.

2024-06-30  Marcus Nilsson  <brainbomb@gmail.com>

	objcopy: Allow making symbol global and weak on same invocation
	Previously objcopy had to be run twice in order to make a local symbol
	weak, first once to globalize it, and once again to mark it as weak.

		* objcopy.c (filter_symbols): Weaken symbols after making
		local/global changes.
		* testsuite/binutils-all/symbols-5.d,
		* testsuite/binutils-all/symbols-5.s: New test.

2024-06-30  Alan Modra  <amodra@gmail.com>

	tweak latest vms-alpha.c change
	It's that tiny bit nicer to have the "len" expression in order of
	the components in the buffer.

	Assertion `(data) <= (end)' failed in read_bases
		* dwarf.c (skip_attribute): Don't increment data past end.
		Use SKIP_{S,U}LEB rather than READ_{S,U}LEB.

2024-06-30  Alan Modra  <amodra@gmail.com>

	Re: Rewrite SHT_GROUP handling
	Some more error tweaks.  Report a zero entry as "invalid entry.."
	rather than "unknown type..", and allow a section to be mentioned
	twice in a group.

		* elf.c (process_sht_group_entries): Tweak error messages, and
		allow a duplicate index in a group without reporting an error.

2024-06-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-29  Sam James  <sam@gentoo.org>

	ld: pass -g for ld-elf tests
	The "DWARF parse during linker error" and "Build warn libbar.so" tests
	require debug information.

	configure defaults to "-O2 -g" but if overriding *FLAGS when building
	tests, this might be lost. Explicitly pass -g given these tests require
	it.

	Originally reported downstream in Gentoo at https://bugs.gentoo.org/934149.

	ld/
		* testsuite/ld-elf/dwarf.exp: Pass -g for "DWARF parse during linker error".
		* testsuite/ld-elf/shared.exp: Ditto for "Build warn libbar.so".

2024-06-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-28  Claudio Bantaloukas  <claudio.bantaloukas@arm.com>

	aarch64: Add support for Armv9.5-A architecture
	The new -march=armv9.5-a flag enables access to the
	mandatory cpa, lut and faminmax extensions.
	Existing test cases for features are extended to verify they
	work without additional flags.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	ld/doc: drop stray blank
	Old enough tools demand no blank between @option and the opening figure
	brace. Re-wrap the paragraph as well while at it.

2024-06-28  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files
	R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38.
	We do not check this relocation to prevent broken links with old object
	files.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	x86/APX: apply NDD-to-legacy transformation to further CMOVcc forms
	With both sources being registers, these insns are almost commutative;
	the only extra adjustment needed is inversion of the encoded condition.

	x86/APX: extend TEST-by-imm7 optimization to CTESTcc
	The same properties apply there.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL
	..., for differing only in the resulting EFLAGS, which are left
	untouched anyway. That's a shorter encoding, available as long as
	certain constraints on operands are met; see code comments. (SHL-by-1
	forms may then be subject to further optimization that was introduced
	earlier.)

	Note that kind of as a side effect this also converts multiplication by
	1 to shift by 0, which is a plain move or even no-op anyway. That could
	be further shrunk (as could be presence of shifts/rotates by 0 in the
	original code as  well as a fair set of other {nf}-form insns), yet the
	expectation (for now) is that people won't write such code in the first
	place.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	x86-64: restrict by-imm31 optimization
	Avoid changing the encoding when there's no size gain: If there's a REX
	or REX2 prefix anyway and the base opcode wouldn't be changed, dropping
	just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case
	in the same big conditional.)

	While there also pull out the .qword check: For the 2-register-operands
	case whether that's done on the 1st or 2nd operand doesn't matter. Due
	to reduction in necessary parentheses this improves readability a tiny
	bit.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	x86/APX: optimize certain {nf}-form insns to LEA
	..., as that leaves EFLAGS untouched anyway. That's a shorter encoding,
	available as long as certain constraints on operand size and registers
	are met; see code comments.

	Note that this requires deferring to derive encoding_evex from {nf}
	presence, as in optimize_encoding() we want to avoid touching the insns
	when {evex} was also used.

	Note further that this requires want_disp32() to now also consider the
	opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still
	report the original mnemonic (or else things can get confusing). While
	there, correct adjacent mis-indentation.

2024-06-28  Jan Beulich  <jbeulich@suse.com>

	x86/APX: optimize {nf}-form rotate-by-width-less-1
	Unlike for the legacy forms, where there's a difference in the resulting
	EFLAGS.CF, for the NF variants the immediate can be got rid of in that
	case by switching to a 1-bit rotate in the opposite direction.

	x86/APX: optimize {nf} forms of ADD/SUB with specific immediates
	Unlike for the legacy forms, where there's a difference in the resulting
	EFLAGS, for the NF variants we can safely replace ones using 0x80 by the
	respectively other insn while negating the immediate, saving 3 immediate
	bytes (just 1 though for 16-bit operand size). Similarly we can replace
	ones using 1 / -1 by INC/DEC (eliminating the immediate).

	gas: .irp/.irpc are macro-like
	... for the purposes of get_line_sb() and _find_end_of_line(): They
	support \@ just like macros do, and hence the special casing there also
	needs applying.

2024-06-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Shrink the riscv_implicit_subsets table.
	Allow to add implicit extensions by using the syntax of `.option arch, +-', so
	that the table is shrinked and more readable.

	bfd/
		* elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT
		parameter.
		(check_implicit_for_i): Likewise.
		(riscv_implicit_subsets): Shrink the table by allowing the syntax of
		`.option arch, +-' for implicit extensions.
		(riscv_update_subset1): New function, called from riscv_update_subset
		or riscv_parse_add_implicit_subsets.  It basically does the same thing
		as riscv_update_subset function before.
		(riscv_parse_add_implicit_subsets): Updated.
		(riscv_update_subset): Updated.

2024-06-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc.
	When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel
	relocation to absolutly access if possible at the relocate stage.  We used to
	encode the target address into r_sym of R_RISCV_HI20 if it is converted from
	R_RISCV_PCREL_HI20.  But that may cause segfault if --emit-relocs is set,
	since r_sym becomes an address rather than a symbol index.  Although the
	relocate result is correct, it does not meet the definition, so may cause
	unexpected behaviors.

	This patch encodes the target address into r_addend, rather than r_sym, if
	riscv_zero_pcrel_hi_reloc converts the relocation.  Besdies, since the
	corresponding pcrel_lo relocation are also changed to absolutly access,
	we should also update them to R_RISCV_LO12_I/S.

	bfd/
		PR 27180
		* elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to
		inform corresponding pcrel_lo that the pcrel_hi relocation was already
		converted to hi20 relocation.
		(riscv_record_pcrel_hi_reloc): Likewise, record `absolute'.
		(riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc,
		since we may need to convert it from pcrel_lo to lo relocation.
		(riscv_record_pcrel_lo_reloc): Likewise.  Convert pcrel_lo to lo
		relocation if corresponding pcrel_hi was converted to hi relocation.
		(riscv_zero_pcrel_hi_reloc): Encode target absolute address into
		r_addend rather than r_sym.  Clear the `addr' to avoid duplicate
		relocate in the perform_relocation.
		(riscv_elf_relocate_section): Updated.
	ld/
		PR 27180
		* testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase.
		Segfault without applying this patch.
		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.

2024-06-28  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Add Zabha extension CAS instructions.
	This patch update the cas instruction in Zabha extension [1],
	when both Zabha and Zacas extension enabled.

	[1] https://github.com/riscv/riscv-zabha/tags

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): New extension case.

	gas/ChangeLog:

		* testsuite/gas/riscv/zabha-32.d: New instructions.
		* testsuite/gas/riscv/zabha.d: Ditto.
		* testsuite/gas/riscv/zabha.s: Ditto.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_AMOCAS_B): New opcodes.
		(MASK_AMOCAS_B): Ditto.
		(MATCH_AMOCAS_H): Ditto.
		(MASK_AMOCAS_H): Ditto.
		(DECLARE_INSN): New instructions.
		* opcode/riscv.h (enum riscv_insn_class): New class case.

	opcodes/ChangeLog:

		* riscv-opc.c: New instructions.

2024-06-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-27  H.J. Lu  <hjl.tools@gmail.com>

	Set BFD_DECOMPRESS when reading build-id debuglink
	We should set BFD_DECOMPRESS to decompress sections unless dumping the
	section contents when reading build-id debuglink.

		PR binutils/31925
		* objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress
		sections unless dumping the section contents.
		* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
		Add a compress option.
		Run test_build_id_debuglink with none and zlib.

2024-06-27  Andrew Burgess  <aburgess@redhat.com>

	gdb: add overloads of gdb_tilde_expand
	Like the previous commit, add two overloads of gdb_tilde_expand, one
	takes std::string and other takes gdb::unique_xmalloc_ptr<char>.  Make
	use of these overloads throughout GDB and gdbserver.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-27  Andrew Burgess  <aburgess@redhat.com>

	gdb: add overloads of gdb_abspath
	Add two overloads of gdb_abspath, one which takes std::string and one
	which takes gdb::unique_xmalloc_ptr<char>, then make use of these
	overloads throughout GDB and gdbserver.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-27  Pali Roh?r  <pali@kernel.org>

	Improve comments describing the Import Directory Table
	  PR 31728

2024-06-27  Nick Clifton  <nickc@redhat.com>

	Fix new libdep test so that if the plugin cannot be located the test fails gracefully.

2024-06-27  Alan Modra  <amodra@gmail.com>

	Re: Rewrite SHT_GROUP handling
	There is no need to loop over the headers twice.  Remove that leftover
	from the previous scheme.  Also, the previous scheme silently ignored
	a section being mentioned in two or more SHT_GROUP sections.

		* elf.c (process_sht_group_entries): Prevent sections from
		belonging to two groups.
		(_bfd_elf_setup_sections): Process groups in a single loop
		over headers.

2024-06-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-27  Alan Modra  <amodra@gmail.com>

	Rewrite SHT_GROUP handling
	This patch delays setting up elf_next_in_group, elf_sec_group and
	elf_group_name when reading ELF object files until after all ELF
	sections have been processed by bfd_section_from_shdr.  This is simpler
	and more robust than the current scheme of driving the whole process
	on detecting a section with SHF_GROUP set.

		* elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr,
		num_group and group_search_offset.
		* elf.c (Elf_Internal_Group): Delete.
		(setup_group): Delete function.
		(IS_VALID_GROUP_SECTION_HEADER): Delete macro.
		(is_valid_group_section_header),
		(process_sht_group_entries): New functions.
		(_bfd_elf_setup_sections): Handle group sections here..
		(_bfd_elf_make_section_from_shdr): ..rather than here.
		(bfd_section_from_shdr): Don't check SHT_GROUP validity here.

2024-06-26  Nick Clifton  <nickc@redhat.com>

	Revert: 35fd2ddeb1d90f1750401cfb6d01fe055656b88d
	  PR 20814

2024-06-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Minor cleanup in gdb.base/bg-execution-repeat.exp
	Simplify a gdb_test_multiple in test-case gdb.base/bg-execution-repeat.exp
	using "gdb_test -no-prompt-anchor".

	Suggested-By: Guinevere Larsen <blarsen@redhat.com>

	Tested on x86_64-linux.

2024-06-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp
	I ran into the following test failure with test-case
	gdb.base/bg-execution-repeat.exp:
	...
	(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command
	^M
	Breakpoint 2, foo () at bg-execution-repeat.c:23^M
	23        return 0; /* set break here */^M
	print 1^M
	$1 = 1^M
	(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted
	FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout)
	...

	The failure can be easily reproduced by adding a sleep 5 here:
	...
	+    sleep 5
	     gdb_test "print 1" " = 1" "input still accepted"
	...

	There's a race in the test-case, between:
	- the command handled in the foreground: the "print 1" command, and
	- the command handled in the background: the continue command.

	The current way of dealing with this is by putting the inferior to sleep for 5
	seconds:
	...
	  foo ();
	  sleep (5);
	  foo ();
	...
	with the aim that the "print 1" command will win the race.

	This method is both slow and unreliable.

	Fix this by making the inferior wait till the "print 1" command is done.

	This reduces running time from ~11s to ~1s.

	I also verified that the test-case still triggers on the original problem by
	applying this gdb/infcmd.c patch:
	...
	-strip_bg_char (const char *args, int *bg_char_p)
	+strip_bg_char (const char *_args, int *bg_char_p)
	 {
	-  const char *p;
	+  char *args = const_cast<char *>(_args);
	+  char *p;

	   if (args == nullptr || *args == '\0')
	     {
	@@ -210,6 +211,7 @@ strip_bg_char (const char *args, int *bg_char_p)
	       p--;
	       while (p > args && isspace (p[-1]))
	 	p--;
	+      *p = '\0';
	...

	Tested on x86_64-linux, with make-check-all.sh.

	PR testsuite/31794
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31794

	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

2024-06-26  Indu Bhagat  <indu.bhagat@oracle.com>

	doc: sframe: small improvements for readability
	Update some of the content to make the specification document hopefully
	clearer:
	  - Fix some typos.
	  - Use Title case consistently for headings.
	  - Update text around detection of foreign endianness.
	  - Split the structure field "Name" in each table to two separate
	    colunms for additional attention: "Type" and "Name".
	  - Rename "SFrame endianness" section to "SFrame magic number and
	    endianness"
	  - Update text around provisions for extending SFrame for future
	    ABIs/architectures.  Make it clear by tagging all provisions with an
	    explicit index item "Provisions for future ABIs".
	  - Add a paragraph on sort order of SFrame FDEs.
	  - Add a statement for SFRAME_F_FRAME_POINTER flag.
	  - Add a statement to assert that SFrame version 1 is now obsolete and
	    should not be used.

	libsframe/
		* doc/sframe-spec.texi: Small improvements for readability.

2024-06-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-26  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: FP8 scale and convert - Implement minor improvements
	Following feedback received shortly after the initial commit of the
	aarch64 instructions for scaling and converting fp8 instructions, this
	patch addresses the issues raised in the relevant feedback.

	This includes the following changes:

	* Standardize all FP8 qualifier-set names.  This has resulted in the
	  renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B
	  to QL_V2_HB_FULL.

	* Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new
	  standardized qualifier-set names mentioned above and, in the case of
	  the "fcvtn" entries, also add a leading 0 to their opcode values so
	  they are given as 8 hexadecimal digits in length to ensure
	  consistency in formatting relative to other entries in the table.

	* Revise the added test-cases so that when checking operand fields in
	  the disassembled binaries, all bits for these fields get tested to
	  ensure they can be toggled on/off by the relevant operand arguments.

2024-06-25  Flavio Cruz  <flaviocruz@gmail.com>

	Hurd port: update interface to match upstream and fix warnings.
	We have recently updated the interface for raising exceptions to use
	long [1] and updated mach_port_t to be "unsigned int". This patches fixes
	those problems and will help us port GDB to Hurd x86_64.

	Tested on Hurd i686 and x86_64.

	[1] https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/mach/exc.defs

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-06-25  Jens Remus  <jremus@linux.ibm.com>

	aarch64: Treat operand ADDR_SIMPLE as address with base register
	The AArch64 instruction table (aarch64-tbl.h) defines the operand
	ADDR_SIMPLE as "address with base register (no offset)". During assembly
	it is correctly encoded as address with base register (addr.base_regno)
	in parse_operands. In warn_unpredictable_ldst it is erroneously treated
	as register number (reg.regno).

	This resolves the assembler test case "Diagnostics Quality" to
	erroneously fail when changing the union in struct aarch64_opnd_info
	from union to struct for debugging purposes.

	gas/
		* config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with
		base register.

2024-06-25  Jens Remus  <jremus@linux.ibm.com>

	aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919)
	The AArch64 instruction table (aarch64-tbl.h) defines the operand
	Rt_IN_SYS_ALIASES as register number. During assembly it is correctly
	encoded as register number (reg.regno) in parse_operands. During
	disassembly it is first correctly decoded as register number (reg.regno)
	in aarch64_ext_regno called by aarch64_extract_operand, but then
	erroneously treated as immediate value (imm.value) in
	aarch64_print_operand.

	This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to
	erroneously fail on s390. On AArch64 - being little-endian - the struct
	aarch64_opnd_info union fields reg.regno and imm.value share their
	least-significant bits. On s390 - being big-endian - they do not.

	opcodes/
		PR binutils/31919
		* aarch64-opc.c: Treat operand Rt_IN_SYS_ALIASES as register
		number.

	Bug: https://sourceware.org/PR31919
	Fixes: 72476aca8f58 ("aarch64: add Branch Record Buffer extension instructions")

2024-06-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: the all-doc build target should build .... all docs
	I noticed that the 'all-doc' build target doesn't build all the doc
	formats, 'man' and 'html' are missing.

	This commit updates 'all-doc' so that all formats are built.

	This doesn't change the default 'all' target, which is the default
	target used when building GDB itself, the 'all' target continues to
	just build the 'info' docs.

	There should be no difference in the actual generated output after
	this commit, I'm just changing what gets built.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: fix cannot create directory error when building dvi/pdf
	After this commit:

	  commit 0700386f142f0b0d3d0021995970a1b41c36cc92 (gdb-tmp-c)
	  Date:   Wed May 8 19:12:57 2024 +0100

	      gdb/doc: fix parallel build of pdf and dvi files

	When building the dvi or pdf targets you'd get errors like this:

	  mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory
	  mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory

	fixed by ensuring the directory is created before calling texi2dvi.

2024-06-25  Nick Clifton  <nickc@redhat.com>

	Updated Russian translation for the bfd/ sub-directory

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix FEAT_B16B16 sve2 instruction constraints.
	This patch adds missing contraints to FEAT_B16B16 sve2 instructions
	bfclamp, bfmla and bfmls and add negative tests for all the bfloat
	instructions.

	The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.*
	to maintain consistency in the testsuite.

	The bfloat16-1-invalid.* tests are  modified so that "selected
	processor does not support" is generated by the assembler, since
	+b16b16 is not passed in the command line.

	The bfloat16-2-invalid.* testcase includes the wrong operands
	bfloat16 tests.

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add extra tests for sve2p1 min max instructions.
	This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv,
	sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and
	fminqv" instructions.

	The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase
	without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands
	for sve2p1 instructions.

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	arch64: Fix the wrong constraint used for sve2p1 instructions.
	The current implementation for the following SVE2p1 instructions add a
	constraint in aarch64_opcode_table[] array, so that these instruction
	might be immediately preceded in program order by a MOVPRFX instruction.

	As per the spec these instruction does not immediately preceded in
	program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC
	macro is replaced with SVE2p1_INSN macro for the entries of these
	instructions in aarch64_opcode_table[] array.

	List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv,
	eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv.

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix sve2p1 ld[1-4]/st[1-4]q instruction operands.
	This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q
	as mentioned below, for the issues reported here.
	https://sourceware.org/pipermail/binutils/2024-February/132408.html

	1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as
	predicated instructions and this issue is fixed in this patch by replacing
	"SVE2p1_INSNC" with "SVE2p1_INSN" macro.
	2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed
	by replacing "SVE_Zt" with "SVE_ZtxN".
	3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in
	this patch.
	4) In ld1q/st1q the index in the second argument is optional and if index
	   is xzr and is skipped in the assembly, the index field is ignored by the
	   disassembler.

	Fixing above mentioned issues helps with following:
	1) ld1q and st1q first register operand accepts enclosed figure braces.
	2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping
	   sequence of vector registers.

	For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector
	registers are added along with short-form of operands for non-wrapping sequence.

	I have added test using following logic:
	ld2q {Z0.Q, Z1.Q}, p0/Z, [x0,  #0, MUL VL]  //raw insn encoding (all zeroes)
	ld2q {Z31.Q, Z0.Q}, p0/Z, [x0,  #0, MUL VL] // encoding of <Zt1>
	ld2q {Z0.Q, Z1.Q}, p7/Z, [x0,  #0, MUL VL] // encoding of <Pg>
	ld2q {Z0.Q, Z1.Q}, p0/Z, [x30,  #0, MUL VL] // encoding of <Xm>
	ld2q {Z0.Q, Z1.Q}, p0/Z, [x0,  #-16, MUL VL] // encoding of <imm> (low value)
	ld2q {Z0.Q, Z1.Q}, p0/Z, [x0,  #14, MUL VL] // encoding of <imm> (high value)
	ld2q {Z31.Q, Z0.Q}, p7/Z, [x30,  #-16, MUL VL] // encoding of all fields (all ones)
	ld2q {Z30.Q, Z31.Q}, p1/Z, [x3,  #-2, MUL VL] // random encoding.

	For all the above form of instructions the hyphenated form is preferred for
	disassembly if there are more than two registers in the list, and the register
	numbers are monotonically increasing in increments of one.

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix sve2p1 extq instruction operands.
	This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands
	count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th
	argument an 4-bit unsigned immediate of extq instruction. The instruction encoding
	is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately
	precede in program order by a MOVPRFX instruction. Also removed the unused operand
	AARCH64_OPND_SVE_Zm_imm4.

	This issues was reported here:
	 https://sourceware.org/pipermail/binutils/2024-February/132408.html

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix sve2p1 dupq instruction operands.
	This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way
	2nd operand does the encoding and decoding using the [<imm>] value.

	dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index
	inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter)
	and aarch64_ext_sve_index_imm (extractor) is removed in this patch.

	This issues was reported here:
	 https://sourceware.org/pipermail/binutils/2024-February/132408.html

2024-06-25  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Enable mandatory feature bits for v9.4-A.
	This patch fixes the mandatory feature bits in v9.4-a architectures,
	by enabling FEAT_SVE2p1 for Armv9.4-A architecture by default.

2024-06-25  Nick Clifton  <nickc@redhat.com>

	Revert 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c
	  PR 20880

	Fix calculation of space remaining in buffer when printing the contents of a DST__K_RECBEG type debug symbol for the VMS Alpha port.
	  PR 31873

2024-06-25  Schimpe, Christina  <christina.schimpe@intel.com>

	gdb: use alternative for demangled name for non-demangeable linkage names
	In case a DIE contains a linkage name which cannot be demangled and
	a source language name (DW_AT_NAME) exists then we want to display this name
	instead of the non-demangeable linkage name.

	dwarf2_physname returns the linkage name in case the linkage name
	cannot be demangled.  Before this patch we always set the returned physname
	as demangled name.  This patch changes this by comparing the value
	of physname with the linkage name.  Now after this change in case it is equals
	to the linkage name and if DW_AT_NAME exists then this is set as the demangled
	name otherwise like before still linkage name is used.

	For the reproducer, using the test source file added in this change:
	"gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c"

	Here is an example of the DWARF where wrong linkage name is emitted by the
	compiler for the "func_demangled_test" function:

	subprogram {
	    {MACRO_AT_range {func_demangled_test}}
	    {linkage_name "_FUNC_WRONG_MANGLED__"}
	    {name "func_demangled_test"}
	    {external 1 flag}
	}
	subprogram {
	    {MACRO_AT_range {main}}
	    {external 1 flag}
	    {name main}
	    {main_subprogram 1 flag}
	}

	Before this change for a function having both DIEs DW_AT_name and
	DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace
	command shows following:

	(gdb) b func_demangled_test
	(gdb) r
	Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
	(gdb) backtrace
	\#0  0x0000555555555131 in  _FUNC_WRONG_MANGLED__ ()
	\#1  0x000055555555514a in main ()

	After the change now GDB shows the name emitted by DW_AT_NAME:

	(gdb) b func_demangled_test
	(gdb) r
	Breakpoint 1, 0x0000555555555131 in func_demangled_test ()
	(gdb) backtrace
	\#0  0x0000555555555131 in func_demangled_test ()
	\#1  0x000055555555514a in main ()

	A new test is added to verify this change.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-25  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Add DT_RELR tests for ILP32 ABI

	aarch64: Add DT_RELR support for ILP32 ABI
	Extend the 64bit DT_RELR support to work on 32bit ELF too. For this
	only a few changes were needed in the sizing and creation of the
	relr relocations.

2024-06-25  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Remove dead code in parse_macro_definition
	In parse_macro_definition, there's a loop:
	...
	  for (p = body; *p; p++)
	    if (*p == ' ' || *p == '(')
	      break;
	...
	whose post-condition is:
	...
	  gdb_assert (*p == ' ' || *p == '(' || *p == '\0');
	...

	Consequently, in the following:
	...
	  if (*p == ' ' || *p == '\0')
	    <BODY1>
	  else if (*p == '(')
	    <BODY2>
	  else
	    <BODY3>
	...
	BODY3 is dead code.

	Remove it, and get rid of unnecessary indentation by using an early-exit:
	....
	  if (*p == ' ' || *p == '\0')
	    {
	      <BODY1>
	      return;
	    }

	  gdb_assert (*p == '(');
	  <BODY2>
	...

	Tested on aarch64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-24  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add support for hardware breakpoint
	LoongArch defines hardware watchpoint functions for fetch operations.
	After the software configures the watchpoints for fetch, the processor
	hardware will monitor the access addresses of the fetch operations and
	trigger a watchpoint exception when the watchpoint setting conditions
	are met.

	Hardware watchpoints for fetch operations is used to implement hardware
	breakpoint function on LoongArch. Refer to the following document for
	hardware breakpoint.
	https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints

	A simple test is as follows:

	lihui@bogon:~$ cat test.c
	  #include <stdio.h>
	  int a = 0;
	  int main()
	  {
	        printf("start test\n");
	        a = 1;
	        printf("a = %d\n", a);
	        printf("end test\n");
	        return 0;
	  }
	lihui@bogon:~$ gcc -g test.c -o test

	without this patch:

	lihui@bogon:~$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:5
	5               printf("start test\n");
	(gdb) hbreak 8
	No hardware breakpoint support in the target.

	with this patch:

	lihui@bogon:~$ gdb test
	...
	(gdb) start
	...

	Temporary breakpoint 1, main () at test.c:5
	5               printf("start test\n");
	(gdb) hbreak 8
	Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8.
	(gdb) c
	Continuing.
	start test
	a = 1

	Breakpoint 2, main () at test.c:8
	8               printf("end test\n");
	(gdb) c
	Continuing.
	end test
	[Inferior 1 (process 25378) exited normally]

2024-06-24  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add support for hardware watchpoint
	LoongArch defines hardware watchpoint functions for load/store
	operations. After the software configures the watchpoints for
	load/store, the processor hardware will monitor the access
	addresses of the load/store operations and trigger watchpoint
	exception when the watchpoint setting conditions are met.

	After this patch, watch/rwatch/awatch command are supported. Refer to the
	following document for hardware watchpoint.
	https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints

	A simple test is as follows:

	lihui@bogon:~$ cat test.c
	  #include <stdio.h>
	  int a = 0;
	  int main()
	  {
	        printf("start test\n");
	        a = 1;
	        printf("a = %d\n", a);
	        printf("end test\n");
	        return 0;
	  }

	lihui@bogon:~$ gcc -g test.c -o test

	without this patch:

	lihui@bogon:~$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:5
	5               printf("start test\n");
	(gdb) awatch a
	Target does not support this type of hardware watchpoint.
	...

	with this patch:

	lihui@bogon:~$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:5
	5               printf("start test\n");
	(gdb) awatch a
	Hardware access (read/write) watchpoint 2: a
	(gdb) c
	Continuing.
	start test

	Hardware access (read/write) watchpoint 2: a

	Old value = 0
	New value = 1
	main () at test.c:7
	7               printf("a = %d\n", a);
	(gdb) c
	Continuing.

	Hardware access (read/write) watchpoint 2: a

	Value = 1
	0x00000001200006e0 in main () at test.c:7
	7               printf("a = %d\n", a);
	(gdb) c
	Continuing.
	a = 1
	end test
	[Inferior 1 (process 22250) exited normally]

2024-06-24  Hannes Domani  <ssbssa@yahoo.de>

	Fix gdb.lookup_type for function-local types
	Looking for a type defined locally in a function doesn't work
	any more since the introduction of TYPE_DOMAIN:
	```
	(gdb) python print (gdb.lookup_type ('main()::Local'))
	Python Exception <class 'gdb.error'>: No type named main()::Local.
	Error occurred in Python: No type named main()::Local.
	```

	cp_search_static_and_baseclasses was simply missing a check for
	SEARCH_TYPE_DOMAIN, now it works again:
	```
	(gdb) python print (gdb.lookup_type ('main()::Local'))
	Local
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Add SME FP8 multiplication instructions
	This includes:
	- FEAT_SME_F8F32 (+sme-f8f32)
	- FEAT_SME_F8F16 (+sme-f8f16)

	The FP16 addition/subtraction instructions originally added by
	FEAT_SME_F16F16 haven't been added to Binutils yet.  They are also
	required to be enabled if FEAT_SME_F8F16 is present, so they are
	included in this patch.

2024-06-24  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Add FP8 Neon and SVE multiplication instructions
	This includes all the instructions under the following features:
	- FEAT_FP8FMA (+fp8fma)
	- FEAT_FP8DOT4 (+fp8dot4)
	- FEAT_FP8DOT2 (+fp8dot2)
	- FEAT_SSVE_FP8FMA (+ssve-fp8fma)
	- FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4)
	- FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2)

2024-06-24  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Add support for virtual features
	These features will be used to gate instructions that can be enabled by
	either of two (or more) different sets of command line feature flags.

	This patch add a postprocessing step to the feature parsing code to
	set the value of the virtual bits.

2024-06-24  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Move struct definition towards its usage

2024-06-24  Tom Tromey  <tromey@adacore.com>

	Prefer htab_traverse_noresize
	A few spots in gdb were using htab_traverse.  IMO this is almost never
	useful and htab_traverse_noresize should be preferred.

2024-06-24  Tom Tromey  <tromey@adacore.com>

	Remove hashtab_obstack_allocate
	I think that hashtabs should never be obstack-allocated.  In the past
	this was convenient sometimes, because any new data structure needed a
	corresponding cleanup.  However, with the switch to C++, resource
	management has become much simpler; for example, a local variable can
	simply be of type htab_up rather than hashtab_t, and the problem is
	solved.

	This patch removes hashtab_obstack_allocate to try to prevent this
	anti-pattern from being used again.

2024-06-24  Tom Tromey  <tromey@adacore.com>

	Don't obstack-allocate the call site hash table
	The call site hash table is the last hash table using obstack
	allocation.  In one large (non-public) test case, these hash tables
	take a substiantial amount of memory.  Some of this memory is wasted
	-- whenever the hash table is resized, the old table is not freed.

	This patch fixes the problem by changing this hash table to be
	heap-allocated.  This means that resizing will no longer "leak"
	memory.

2024-06-24  Tom Tromey  <tromey@adacore.com>

	Add compunit_symtab::forget_cached_source_info
	It seemed cleaner to me for compunit_symtab to have a
	forget_cached_source_info method, then for the objfile to know how to
	do this.

	Make symtab members private
	This rearranges symtab so that the private members appear at the end,
	and then adds the "private" keyword.

	Rename symtab::fullname
	This renames symtab::fullname to m_fullname and adds new accessor
	methods.

	Don't obstack-allocate the CU dependency hash table
	The CU dependency hash table is obstack-allocated, but there's no need
	to do this.

2024-06-24  Tom Tromey  <tromey@adacore.com>

	Don't obstack-allocate the DIE hash
	The DIE hash table is currently allocated on an obstack.  There's no
	need to do this, and I think it's better to simply heap-allocate the
	hash table.

	This patch implements this.  I also removed store_in_ref_table as
	well, inlining it into its sole caller, as I think this is clearer.

2024-06-24  Harmen Stoppels  <me@harmenstoppels.nl>

	libdep plugin: fix bugs in parser and drop escaping
	  PR ld/31906
	  * libdep_plugin.c (str2vec): Fix bug where null byte was not copied on memmove during quote handling and escaping, causing repeat of the last character in the last argument.
	  Fix buffer overflow in **res when arguments were separated by `\t` instead of ` `.
	  Remove handling of the escape character `\`, as it made it impossible to specify paths containing `\`
	  -- the implementation merely dropped `\`, and was affected by the memmove bug, so this should not be breaking; just single and double quotes are sufficient to deal with white space and quote characters, there is no need for escaping.
	  Handle syntax errors   on unterminated quotes.
	  Make the parser linear time instead of   quadratic.

2024-06-24  Nick Clifton  <nickc@redhat.com>

	Updated Spanish translations for the bfd and binutils sub-directories

	ld: Improve the documentation describing the -o option.
	  PR 31761

2024-06-24  saurabh.jha@arm.com  <saurabh.jha@arm.com>

	gas, aarch64: Add SME2 lutv2 extension
	Introduces instructions for the SME2 lutv2 extension for AArch64. They
	are documented in the following document:

	  * ARM DDI0602

	For both luti4 instructions, we introduced an operand called
	SME_Znx2_BIT_INDEX. We use the existing function parse_vector_reg_list
	for parsing but modified that function so that it can accept operands
	without qualifiers and rejects instructions that have operands with
	qualifiers but are not supposed to have operands with qualifiers.
	For disassembly, we modified print_register_list so that it could
	accept register lists without qualifiers.

	For one luti4 instruction, we introduced a SME_Zdnx4_STRIDED. It is
	similar to SME_Ztx4_STRIDED and we could use existing code for parsing,
	encoding, and disassembly.

	For movt instruction, we introduced an operand called SME_ZT0_INDEX2_12.
	This is a ZT0 register with a bit index encoded in [13:12]. It is
	similar to SME_ZT0_INDEX.

	We also introduced an iclass named sme_size_12_b so that we can encode
	size bits [13:12] correctly when only 'b' is allowed as qualifier.

2024-06-24  Martin Simmons  <martin@lispworks.com>

	Include needed unordered_map header
	Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level
	configure options --with-python=/usr/local/bin/python3.9 gives this error:

	  CXX    ada-exp.o
	./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std'
	  std::unordered_map<std::string, std::vector<ada_index_var_operation *>>
	  ~~~~~^
	1 error generated.

	This change fixes it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: fix parallel build of pdf and dvi files
	When building with 'make -j20 -C gdb/doc all-doc' I often see problems
	caused from trying to build some dvi files in parallel with some pdf
	files.  The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and
	stabs.pdf; and annotate.dvi and annotate.pdf.

	The problem is that building these files create temporary files in the
	local directory.  There's already a race here that two make threads
	might try to create these files at the same time.

	But it gets worse, to avoid issues where a failed build could leave
	these temporary files in a corrupted state, and so prevent the next
	build from succeeding, the recipe for each of these files deletes all
	the temporary files first, this obviously causes problems if some
	other thread has already started the build and is relying on these
	temporary files.

	To work around this problem I propose we start using the --build and
	--build-dir options for texi2dvi (which is the same tool used to
	create the pdf files).  These options were added in texinfo 4.9 which
	was released in June 2007.  We already require using a version of
	texinfo after 4.9 (I tried to build with 4.13 and the doc build failed
	as some of the texinfo constructs were not understood), so this patch
	has not changed the minimum required version at all.

	The --build flag allows the temporary files to be placed into a
	sub-directory, and the --build-dir option allows us to control the
	name of that sub-directory.

	What we do is create a unique sub-directory for each target that
	invokes texi2dvi, all of the unique sub-directories are created within
	a single directory texi2dvi_tmpdir, and so after a complete doc build,
	we are left with a build tree like this:

	  build/gdb/doc/
	  '-- texi2dvi_tmpdir/
	      |-- annotate_dvi/
	      |-- annotate_pdf/
	      |-- gdb_dvi/
	      |-- gdb_pdf/
	      |-- stabs_dvi/
	      '-- stabs_pdf/

	I've left out all the individual files that live within these
	directories for simplicity.

	To avoid corrupted temporary files preventing a future build to
	complete, each recipe deletes its associated sub-directory from within
	texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh
	start each time.

	And the mostlyclean target deletes texi2dvi_tmpdir/ and all its
	sub-directories, ensuring that everything is cleaned up.

	For me, with this fix in place, I can now run 'make -j20 -C gdb/doc
	all-doc' without seeing any build problems.

	Approved-By: Pedro Alves <pedro@palves.net>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: fix parallel build of refcard related targets
	There are two problems we encounter when trying to build the refcard
	related target in parallel, i.e.:

	  $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf

	These problems are:

	(1) The refcard.dvi and refcard.pdf targets both try and generate the
	    tmp.sed and sedref.tex files.  If two make threads end up trying
	    to create these files at the same time then the result is these
	    files become corrupted.

	    I've fixed this by creating a new rule that creates sedref.tex,
	    both refcard.dvi and refcard.pdf now depend on this, and make will
	    build sedref.tex just once.  The tmp.sed file is now generated as
	    refcard.sed, this is generated and deleted as a temporary file
	    within the sedref.tex recipe.

	(2) Having created sedref.tex the recipes for refcard.dvi and
	    refcard.pdf both run various LaTeX based tools with sedref.tex as
	    the input file.  The problem with this is that these tools all
	    rely on creating temporary files calls sedref.*.

	    If the refcard.dvi and refcard.pdf rules run at the same time then
	    these temporary files clash and overwrite each other causing the
	    build to fail.

	    We already copy the result file in order to rename it, our input
	    file is sedref.tex which results in an output file named
	    sedref.dvi or sedref.pdf, but we actually want refcard.dvi or
	    refcard.pdf.  So within the recipe for refcard.dvi I copy the
	    input file from sedref.tex to sedref_dvi.tex.  Now all the temp
	    files are named sedref_dvi.* and the output is sedref_dvi.dvi, I
	    then rename this new output file to refcard.dvi.

	    I've done the same thing for refcard.pdf, but I copy the input
	    to sedref_pdf.tex.

	    In this way the temp files no longer clash, and both recipes can
	    safely run in parallel.

	After this commit I was able to reliably build all of the refcard
	targets in parallel.  There should be no change in the final file.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: also look in srcdir when running TEXI2POD
	In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke
	texi2pod.pl, which process the .texinfo files.  This also handles the
	'include' directives within the .texinfo files.

	Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag
	to add search directories for resolving 'include' directives within
	.texinfo files.

	When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes
	GDBvn.texi.

	When building from a git checkout the gdb-cfg.texi files and
	GDBvn.texi files will be created in the build directory, which is
	where texi2pod.pl is invoked, so the files will be found just fine.

	However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the
	source tree, along with the generated manual (.1 and .5) files.

	So when building a release, what normally happens is that we spot that
	the .1 and .5 man files are up to date, and don't run the recipe to
	regenerate these files.

	However, if we deliberately touch the *.texinfo files in a release
	source tree, and then try to rebuild the man files, we'll get an error
	like this:

	  make: Entering directory '/tmp/release-build/build/gdb/doc'
	    TEXI2POD gdb.1
	  cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
	  make: *** [Makefile:664: gdb.1] Error 2
	  make: Leaving directory '/tmp/release-build/build/gdb/doc'

	The problem is that texi2pod.pl doesn't know to look in the source
	tree for the GDBvn.texi file.

	If we compare this to the recipe for creating (for example) gdb.dvi,
	which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi
	command line, which allows texi2dvi to find GDBvn.texi in the source
	tree.

	In this commit I add a similar -I option to the texi2pod.pl command
	line.  After this, given a GDB release, it is possible to edit (or
	just touch) the gdb.texinfo file and rebuild the man pages, the
	GDBvn.texi will be picked up from the source tree.

	If however a dependency for GDBvn.texi is changed in a release tree
	then GDBvn.texi will be regenerated into the build directory and this
	will be picked up in preference to the GDBvn.texi in the source tree,
	just as you would want.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: allow for version.subst in the source tree
	In a git checkout of the source code we don't have a version.subst
	file in the gdb/doc directory.  When building the GDB docs the
	version.subst file is generated on demand (we have a recipe for that).

	However, in a release tar file we do include a copy of the
	version.subst file in the source tree, as a result the version.subst
	recipe will not be run.

	If, in a release build, we force the running of any recipe that
	depends on version.subst then we run into a problem.  For example,
	slightly confusingly, if we 'touch gdb/doc/version.subst' within the
	unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi'
	in the build tree, we'll see:

	  make: Entering directory '/tmp/build/build/gdb/doc'
	    GEN    GDBvn.texi
	  sed: can't read version.subst: No such file or directory
	  make: Leaving directory '/tmp/build/build/gdb/doc'

	The problem is that every reference to version.subst in GDB's Makefile
	assumes that the version.subst file will always be in the build
	directory.

	Handily version.subst is always the first dependency in every recipe
	that uses that file.  As such we can replace references to
	version.subst with $<, make will expand this to the location where the
	dependency was found.

	In the case of the man page generation, the reference to version.subst
	is hidden inside POD2MAN.  It seemed a little confusing adding a use
	of  $< within POD2MAN, so I've moved the use into the recipe, which I
	think is clearer.

	I've also added comments for the two rules that I've modified to
	explain our use of $<.

	After this change it is possible to rebuild the man pages even when
	version.subst is located in the source tree.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: merge rules for building .1 and .5 man pages
	We have two rules, one each for building the .1 and .5 man pages.  The
	only actual difference is that one rule passes --section=1 and the
	other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5
	respectively.

	I figure by using the suffix from the target of the rule we can
	combine these two rules into one.

	I use:

	  $(subst .,,$(suffix $@))

	This gets the suffix from the target, either '.1' or '.5', and the
	'subst' removes the '.' leaving '1' or '5'.

	Now that I'm not using a static pattern rule for building the man
	pages, the advice in the 'make' documentation is to not use $*, so
	I've moved away from that to instead use $(basename $@), e.g. for
	'gdbinit.5' this gives 'gdbinit', which is what we want.

	There should be no difference in what is created after this change.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: don't try to copy GDBvn.texi from the source tree
	The build recipe for gdb.dvi and gdb.pdf contains instructions for
	copying the GDBvn.texi file from the source tree into the build
	directory if the GDBvn.texi file doesn't already exist in the build
	directory.

	The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi,
	and we have a recipe for building GDBvn.texi.

	What's happening here is this:

	  - In a git checkout of the source tree there is no GDBvn.texi in the
	    source tree, the GDBvn.texi dependency will trigger a rebuild of
	    GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf.

	  - In a release tar file we do include a copy of GDBvn.texi.  This
	    file will appear to be up to date, and so no copy of GDBvn.texi is
	    created within the build directory.  Now when building gdb.dvi
	    and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from
	    the source tree into the build directory.

	However, copying GDBvn.texi from the source directory is completely
	unnecessary.  The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and
	pass '-I $(srcdir)' as an argument, this means that texi2dvi will look
	in the $(srcdir) to find included files, including GDBvn.texi.

	As such I believe we can remove the code that copies GDBvn.texi from
	the source tree into the build tree.

	I've tested with a release build; creating a release with:

	  ./src-release gdb

	Then in an empty directory, unpacking the resulting .tar file,
	creating a parallel build directory and doing the usual configure,
	make, and 'make install'.

	Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked
	source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf
	and dvi files, this works fine without having to either build or copy
	GDBvn.texi into the build directory.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/i386: fix tdesc rejection issue for targets without PTRACE_GETREGSET
	After the x86 target description changes that I committed recently,
	the first commit in the series being:

	  commit 8a29222b85f28a2201db50a34ac4144f961311db
	  Date:   Sat Jan 27 10:40:35 2024 +0000

	      gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition

	and the last commit in the series being:

	  commit 646d754d14c2fe70a492a893506a74b0463b6ae8
	  Author: Andrew Burgess <aburgess@redhat.com>
	  Date:   Tue Jan 30 15:37:23 2024 +0000

	      gdb/gdbserver: share x86/linux tdesc caching

	The sourceware buildbot highlighted a regression on i386.  On the GDB
	side we'd see this:

	  Remote debugging using :54321
	  warning: Architecture rejected target-supplied description
	  Remote connection closed
	  (gdb)

	while on the gdbserver side we'd see this:

	  $ ./gdbserver/gdbserver --once :54321 ~/empty
	  Process /srv/aburgess/empty created; pid = 31406
	  Listening on port 54321
	  Remote debugging from host ::1, port 39488
	  ../../src/gdbserver/regcache.cc:272: A problem internal to GDBserver has been detected.
	  Unknown register st0 requested
	  Aborted (core dumped)

	When I tried to reproduce this regression on my local i386 VM the
	issue would not reproduce.

	I eventually tracked the problem down to x86_linux_tdesc_for_tid in
	gdb/nat/x86-linux-tdesc.c.  In this function we have this line:

	  /* Check if PTRACE_GETREGSET works.  */
	  if (ptrace (PTRACE_GETREGSET, tid,
	              (unsigned int) NT_X86_XSTATE, &iov) < 0)
	    {
	      ... handle failure ...
	    }
	  else
	    {
	      ... handle success ...
	    }

	The problem is that on my VM the PTRACE_GETREGSET feature is
	supported, while on sourceware's buildbot machine this feature is not
	supported.

	I did a quick search and it seems like the 'xsave' feature in
	/proc/cpuinfo might be the indicator for whether PTRACE_GETREGSET is
	supported or not, and indeed my machine has the 'xsave' feature while
	the sourceware machine does not.

	The point of divergence then is this ptrace call, on my machine the
	call succeeds and we extract the xcr0 value from the iov vector, while
	on the sourceware machine the ptrace call fails and we use a default
	xcr0 value of 0.

	This xcr0 value is then passed to i386_linux_read_description at the
	end of x86_linux_tdesc_for_tid.

	In gdb/arch/i386-linux-tdesc.c we find i386_linux_read_description
	which does some caching but calls i386_create_target_description to
	actually create the target descriptions when needed.  The xcr0 value
	is masked to only the bits that are interesting, but given a value of
	0 we'll just pass 0 through to i386_create_target_description.

	In gdb/arch/i386.c we find i386_create_target_description which checks
	the xcr0 bits and builds the target description.  What we can see is
	that if no bits are set in the xcr0 value then no features will be
	added to the created target description.  This featureless target
	description is then transmitted back to GDB, which is then rejected
	due to lack of essential core registers.

	So, how did things work prior to the above commit series?  There are
	three places of interest, on the GDB side there is
	x86_linux_nat_target::read_description and
	i386_linux_core_read_description.  Then on the gdbserver side there is
	x86_linux_read_description.

	All of these locations have a call to i386_linux_read_description
	followed by a check if the return value was nullptr.  If we do get
	back nullptr then we perform another call to
	i386_linux_read_description with a default xcr0 value.

	Looking in i386_linux_read_description we see a specific check for
	xcr0 being 0 in which case we return nullptr.

	And so, prior to the above series, if xcr0 was 0 due to
	PTRACE_GETREGSET being unavailable we'd use a default xcr0 value.

	After the above series this is no longer the case, the 'xcr0 == 0'
	check has been removed from i386_linux_read_description and the
	calling code is streamlined to remove the use of default xcr0 values.

	The fix I propose here is to setup the default xcr0 value at the point
	where we find that PTRACE_GETREGSET is unavailable.  The default value
	used is X86_XSTATE_SSE_MASK.  This is the default used in
	x86_linux_nat_target::read_description (for GDB) and in
	x86_linux_read_description (for gdbserver).  The above commit series
	already fixed i386_linux_core_read_description to ensure that the
	correct default xcr0 value was used, this case is a little special in
	that it uses different defaults depending on which sections are
	present in the core file, so that case always needed to be handled
	differently.

	The choice of X86_XSTATE_SSE_MASK corresponds to the default used for
	i386 before the above series was committed.  This mask includes the
	X87 and SSE bits only, neither of these bits are checked for on amd64
	or x32, so this default doesn't change the behaviour on these targets.

	By setting the default xcr0 value at this early stage we ensure that
	the cached xcr0 value on the gdbserver side is correct.  This is
	critical as this cached xcr0 value is passed through to the in process
	agent (IPA).  If we leave the cached xcr0 value as 0 and apply the
	defaults later in the series we also have to encode the knowledge of
	the default into the IPA, this just means we have the default encoded
	in multiple locations, which seems like a bad idea.  The approach used
	in this patch means the default is present in just one location.

	This commit should fix the i386 regressions seen on the sourceware
	buildbot.

	In addition to the fix in nat/x86-linux-tdesc.c I've also fixed the
	layout of the declaration of x86_linux_tdesc_for_tid in the header
	file.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-23  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Enable +cssc for armv8.9-a
	FEAT_CSSC is mandatory in the architecture from Armv8.9.

2024-06-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-22  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: analyze-racy-logs.py cleanup
	 - Add type annotations
	 - Use a raw string in one spot (where we call re.sub), to avoid an
	   "invalid escape sequence" warning.
	 - Remove unused "os" import.

	Change-Id: I0149cbb73ad2b05431f032fa9d9530282cb01e90
	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

2024-06-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in gdb.threads/stepi-over-clone.exp
	On fedora rawhide, I ran into:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Catchpoint 2 (call to syscall clone3), 0x000000000042097d in __clone3 ()^M
	(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
	...

	Fix this by updating a regexp to also recognize __clone3.

	Tested on x86_64-linux.

	Tested-By: Guinevere Larsen <blarsen@redhat.com>

2024-06-21  Pedro Alves  <pedro@palves.net>

	[gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux
	When running test-case gdb.base/watchpoint-running on ppc64le-linux (and
	similar on arm-linux), we get:
	...
	(gdb) watch global_var^M
	warning: Error when detecting the debug register interface. \
	  Debug registers will be unavailable.^M
	Watchpoint 2: global_var^M
	(gdb) FAIL: $exp: all-stop: hardware: watch global_var
	FAIL: $exp: all-stop: hardware: watchpoint hit (timeout)
	...

	The problem is that ppc_linux_dreg_interface::detect fails to detect the
	hardware watchpoint interface, because the calls to ptrace return with errno
	set to ESRCH.

	This is a feature of ptrace: if a call is done while the tracee is not
	ptrace-stopped, it returns ESRCH.

	Indeed, in the test-case "watch global_var" is executed while the inferior is
	running, and that triggers the first call to ppc_linux_dreg_interface::detect.

	And because the detection failure is cached, subsequent attempts at setting
	hardware watchpoints will also fail, even if the tracee is ptrace-stopped.

	The way to fix this is to make sure that ppc_linux_dreg_interface::detect is
	called when we know that the thread is ptrace-stopped, which in the current
	setup is best addressed by using target-specific post_attach and
	post_startup_inferior overrides.  However, as we can see in
	aarch64_linux_nat_target, that causes code duplication.

	Fix this by:
	- defining a new target hook low_init_process, called from
	  linux_init_ptrace_procfs, which is called from both
	  linux_nat_target::post_attach and linux_nat_target::post_startup_inferior,
	- adding implementations for ppc_linux_nat_target and arm_linux_nat_target
	  that detect the hardware watchpoint interface,
	- replacing the aarch64_linux_nat_target implementations of post_attach and
	  post_startup_inferior with a low_init_process implementation.

	Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/31834
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834
	PR tdep/31705
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705

2024-06-21  Jan Beulich  <jbeulich@suse.com>

	x86: optimize {,V}PEXTR{D,Q} with immediate of 0
	Such are equivalent to simple moves, which are up to 3 bytes shorter to
	encode (and perhaps also cheaper to execute).

2024-06-21  Jan Beulich  <jbeulich@suse.com>

	x86: optimize left-shift-by-1
	These can be replaced by adds when acting on a register operand.

	While for the scalar forms there's no gain in encoding size, ADD
	generally has higher throughput than SHL. EFLAGS set by ADD are a
	superset of those set by SHL (AF in particular is undefined there).

	For the SIMD cases the transformation also reduced code size, by
	eliminating the 1-byte immediate from the resulting encoding. Note
	that this transformation is not applied by gcc13 (according to my
	observations), so would - as of now - even improve compiler generated
	code.

2024-06-21  Jan Beulich  <jbeulich@suse.com>

	x86/APX: fix disassembly of byte register operands
	Like for REX/REX2, EVEX-prefixed insns access the low bytes of all
	registers; %ah...%bh are inaccessible. Reflect this correctly in output,
	by leveraging REX machinery we already have to this effect.

	x86: %riz, %rip, and %eip don't require REX
	While these can't be used as register operands, they can be used for
	memory operand addressing. Such uses do not prevent conversion: The
	RegRex64 checks in check_Rex_required() for base and index registers
	were simply wrong. They specifically also aren't needed for byte
	registers, as those won't pass i386_index_check() anyway.

	x86: don't suppress errors when optimizing
	Blindly ignoring any mnemonic suffix can't be quite right: Bad suffix /
	operand combinations still want flagging. Simply avoid optimizing in
	such situations.

2024-06-21  Jan Beulich  <jbeulich@suse.com>

	gas: terminate buffer SB in do_repeat()
	PR gas/31903

	While elsewhere having realized that "one" doesn't point to a nul-
	terminated string, it somehow didn't occur to me that the pre-existing
	strstr() could have been wrong, and hence I blindly added a new use of
	the function. Add the (already prior to 1e3c814459d8 ["gas: extend \+
	support to .rept"]) missing call to sb_terminate(), leveraging that to
	simplify the other two places where the lack of nul termination was
	previously worked around.

2024-06-21  Feng Wang  <wangfeng@eswincomputing.com>

	RISC-V: Remove implicit enablement of Zvknha from Zvkn.
	Accroding to the Crypto spec, the Zvkned,Zvknhb,Zvkb and Zvkt are
	included in the Zvkn.  So the Zvknha should be removed from Zvkn.

	bfd/ChangeLog:

		* elfxx-riscv.c: Remove zvknha from zvkn.

2024-06-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-20  Tom Tromey  <tom@tromey.com>

	Handle "info symbol" in Rust language mode
	When I changed the Rust parser to handle 128-bit ints, this
	inadvertently broke some other gdb commands.  For example, "info
	symbol 0xffffffffffffffff" now fails, because the resulting value is
	128 bits, but this is rejected by extract_integer.

	This patch fixes the problem by changing extract_integer to allow
	over-long integers as long as the high bytes are either 0, or (for
	signed types) 0xff.

	Regression tested on x86-64 Fedora 38.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-format-address.exp on arm
	When running test-case gdb.python/py-format-address.exp on arm-linux, I get:
	...
	(gdb) python print("Got: " + gdb.format_address(0x103dd))^M
	Got: 0x103dd <main at py-format-address.c:30>^M
	(gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \
	result should have an offset
	...

	What is expected here is:
	...
	Got: 0x103dd <main+1 at py-format-address.c:30>^M
	...

	Main starts at main_addr:
	...
	(gdb) print /x &main^M
	$1 = 0x103dc^M
	...
	and we obtained next_addr 0x103dd by adding 1 to it:
	...
	set next_addr [format 0x%x [expr $main_addr + 1]]
	...

	Adding 1 to $main_addr results in an address for a thumb function starting at
	address 0x103dc, which is incorrect because main is an arm function (because
	I'm running with target board unix/-marm).

	At some point during the call to format_addr, arm_addr_bits_remove removes
	the thumb bit, which causes the +1 offset to be dropped, causing the FAIL.

	Fix this by using the address of the breakpoint on main, provided it's not at
	the very start of main.

	Tested on arm-linux.

	PR testsuite/31452
	Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31452

2024-06-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix duplicates in gdb.base/watchpoint-unaligned.exp
	When running test-case gdb.base/watchpoint-unaligned.exp on ppc64le-linux, we
	get:
	...
	XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
	XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
	  ...
	UNTESTED: $exp: wpcount(4)
	XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
	DUPLICATE: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
	XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
	DUPLICATE: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
	  ...
	UNTESTED: $exp: wpcount(7)
	...

	Fix this by using foreach_with_prefix.

	Tested on ppc64le-linux.

2024-06-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix duplicates in gdb.opt/inline-cmds.exp
	With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into:
	...
	PASS: gdb.opt/inline-cmds.exp: finish from marker
	 ...
	PASS: gdb.opt/inline-cmds.exp: finish from marker
	DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker
	...

	Fix this by issuing less passes.

	Tested on ppc64le-linux.

2024-06-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix duplicates in gdb.fortran/huge.exp
	With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I
	ran into a number of duplicates:
	...
	Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ...
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/huge.exp: huge.exp
	  ...
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/huge.exp: huge.exp
	DUPLICATE: gdb.fortran/huge.exp: huge.exp
	UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
	...

	Fix this by wrapping the compile in a with_test_prefix, getting us instead:
	...
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp
	  ...
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp
	UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
	...

	Tested on x86_64-linux.

2024-06-20  Alan Modra  <amodra@gmail.com>

	Revert "Remove LIBINTL_DEP"
	This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6.
	The patch was wrong.  LIBINTL_DEP is needed with an in-tree gettext.

2024-06-20  Alan Modra  <amodra@gmail.com>

	Remove LIBINTL_DEP
	The intl directory in the source no longer exists.  LIBINTL_DEP is
	thus always empty.  Remove references to it.

	config/
		* gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP.
	bfd/
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	binutils/
		* Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP.
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	gas/
		* Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP.
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	gdb/
		* Makefile.in (INTL_DEPS): Don't set or reference.
		* configure: Regenerate.
	gdbserver/
		* Makefile.in (INTL_DEPS): Don't set or reference.
	gdbsupport/
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	gold/
		* Makefile.am (deps_var): Remove LIBINTL_DEP.
		(incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise.
		* Makefile.in: Regenerate.
		* configure: Regenerate.
		* testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP.
		* testsuite/Makefile.in: Regenerate.
	gprof/
		* Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP.
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	ld/
		* Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP.
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	libctf/
		* Makefile.in: Regenerate.
		* configure: Regenerate.
	opcodes/
		* configure.ac (BUILD_LIBS): Remove LIBINTL.
		(BUILD_LIB_DEPS): Remove LIBINTL_DEP.
		* Makefile.in: Regenerate.
		* configure: Regenerate.

2024-06-20  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: TLS IE needs only one dynamic reloc
	As the comment in the code says, TLS_IE needs only one dynamic reloc.
	But commit b67a17aa7c0c ("LoongArch: Fix the issue of excessive
	relocation generated by GD and IE") has incorrectly allocated the space
	for two dynamic relocs, causing libc.so to contain 8 R_LARCH_NONE.

	Adjust tlsdesc-dso.d for the offset changes and add two tests to ensure
	there are no R_LARCH_NONE with TLS.

2024-06-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-20  H.J. Lu  <hjl.tools@gmail.com>

	ld: Remove JANSSON_LIBS from ld_new_DEPENDENCIES
	Remove JANSSON_LIBS from ld_new_DEPENDENCIES since ld_new_DEPENDENCIES
	should only contain binutils dependencies.

		PR ld/31909
		* Makefile.am (ld_new_DEPENDENCIES): Remove JANSSON_LIBS.
		* Makefile.in: Regenerated.

2024-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Redo poisoning of PyObject_CallMethod
	In commit 764af878259 ("[gdb/python] Add typesafe wrapper around
	PyObject_CallMethod") I added poisoning of PyObject_CallMethod:
	...
	/* Poison PyObject_CallMethod.  The typesafe wrapper gdbpy_call_method should be
	   used instead.  */
	template<typename... Args>
	PyObject *
	PyObject_CallMethod (Args...);
	...

	The idea was that subsequent code would be forced to use gdbpy_call_method
	instead of PyObject_CallMethod.

	However, that caused build issues with gcc 14 and python 3.13:
	...
	/usr/bin/ld: python/py-disasm.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<unsigned int, long long>(_object*, char const*, unsigned int, long long)':
	/data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x384f): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, unsigned int, long long>(_object*, char*, char*, unsigned int, long long)'
	/usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<int>(_object*, char const*, int)':
	/data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x1235): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int>(_object*, char*, char*, int)'
	/usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<int, int, int>(_object*, char const*, int, int, int)':
	/data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x12b0): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int, int, int>(_object*, char*, char*, int, int, int)'
	collect2: error: ld returned 1 exit status
	...

	Fix this by poisoning without using templates.

	Tested on x86_64-linux.

2024-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix target type of complex long double on arm
	When running test-case gdb.base/complex-parts.exp on arm-linux, I get:
	...
	(gdb) p $_cimag (z3)^M
	$6 = 6.5^M
	(gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3)
	ptype $^M
	type = double^M
	(gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $
	...

	Given that z3 is a complex long double, the test-case expects the type of the
	imaginary part of z3 to be long double, but it's double instead.

	This is due to the fact that the dwarf info doesn't specify an explicit target
	type:
	...
	    <5b>   DW_AT_name        : z3
	    <60>   DW_AT_type        : <0xa4>
	  ...
	 <1><a4>: Abbrev Number: 2 (DW_TAG_base_type)
	    <a5>   DW_AT_byte_size   : 16
	    <a6>   DW_AT_encoding    : 3        (complex float)
	    <a7>   DW_AT_name        : complex long double
	...
	and consequently we're guessing in dwarf2_init_complex_target_type based on
	the size:
	...
		case 64:
		  tt = builtin_type (gdbarch)->builtin_double;
		  break;
		case 96: /* The x86-32 ABI specifies 96-bit long double.  */
		case 128:
		  tt = builtin_type (gdbarch)->builtin_long_double;
		  break;
	...

	For arm-linux, complex long double is 16 bytes, so the target type is assumed
	to be 8 bytes, which is handled by the "case 64", which gets us double
	instead of long double.

	Fix this by searching for "long" in the name_hint parameter, and using long
	double instead.

	Note that base types in dwarf are not allowed to contain references to other
	types, and the complex types are base types, so the missing explicit target
	type is standard-conformant.

	A gcc PR was filed to add this as a dwarf extension (
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ).

	Tested on arm-linux.

2024-06-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix testsuite bugs revealed by -Wall
	Most of these are harmless, but some of the type confusions and especially
	a missing ctf_strerror() on an error path were actual bugs that could
	have resulted in test failures crashing rather than printing an error
	message.

	libctf/
		* testsuite/libctf-lookup/enumerator-iteration.c: Fix type
	        confusion, signedness confusion and a missing ctf_errmsg().
		* testsuite/libctf-regression/libctf-repeat-cu-main.c: Return 0 from
	        the test function.
		* testsuite/libctf-regression/open-error-free.c: Fix signedness
	        confusion.
		* testsuite/libctf-regression/zrewrite.c: Remove unused label.

2024-06-19  Lancelot SIX  <lancelot.six@amd.com>

	gdb/python/python-internal.h: avoid uninitialized constexpr
	The following recent change introduced a regression when building using
	clang++:

	    commit 764af878259768bb70c65bdf3f3285c2d6409bbd
	    Date:   Wed Jun 12 18:58:49 2024 +0200

	        [gdb/python] Add typesafe wrapper around PyObject_CallMethod

	The error message is:

	    ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char'
	    constexpr char gdbpy_method_format;
	                   ^
	                                       = '\0'
	      CXX    python/py-block.o
	    1 error generated.
	    make[2]: *** [Makefile:1959: python/py-arch.o] Error 1
	    make[2]: *** Waiting for unfinished jobs....
	    In file included from ../../gdb/python/py-auto-load.c:25:
	    ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char'
	    constexpr char gdbpy_method_format;
	                   ^
	                                       = '\0'
	    1 error generated.
	    make[2]: *** [Makefile:1959: python/py-auto-load.o] Error 1
	    In file included from ../../gdb/python/py-block.c:23:
	    ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char'
	    constexpr char gdbpy_method_format;
	                   ^
	                                       = '\0'
	    1 error generated.

	This patch fixes this by changing gdbpy_method_format to be a templated
	struct, and only have its specializations define the static constexpr
	member "format".  This way, we avoid having an uninitialized constexpr
	expression, regardless of it being instantiated or not.

	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Change-Id: I5bec241144f13500ef78daea30f00d01e373692d

2024-06-19  Cui, Lili  <lili.cui@intel.com>

	x86: Remove the secondary encoding for ctest.
	There are two encodings for each opcode F6/F7 in ctest, but the second one
	is never used, so remove it to reduce the size of opcode_tbl.h.

	opcodes/ChangeLog:

	        * i386-opc.tbl: Removed the secondary insn template for ctest.
	        * i386-tbl.h: Regenerated.

2024-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x
	On s390x-linux, I run into:
	...
	(gdb) p (short []) s1^M
	$3 = {0, 1, 0, <optimized out>}^M
	(gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1
	...
	while this is expected:
	...
	(gdb) p (short []) s1^M
	$3 = {1, 0, 0, <optimized out>}^M
	(gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1
	...

	The type of s1 is:
	...
	(gdb) ptype s1
	type = struct S {
	    myint a;
	    myushort b;
	}
	...
	so the difference is due the fact that viewing an int as two shorts gives
	different results depending on the endianness.

	Fix this by allowing both results.

	Tested on x86_64-linux and s390x-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add string cat for tcl version < 8.6.2
	I noticed that we started using "string cat", which has been available since
	tcl version 8.6.2.

	Add a local implementation for use with older tcl versions.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Simplify ARM_LINUX_JB_PC_EABI
	In commit 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI"), in absense of
	osabi settings for newlib and uclibc for arm, I chose a best-effort approach
	using ifdefs.

	Post-commit review [1] pointed out that this may be causing more problems than
	it's worth.

	Fix this by removing the ifdefs and simply defining ARM_LINUX_JB_PC_EABI to 1.

	Rebuild on x86_64-linux with --enable-targets=all.

	Fixes: 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI")

	[1] https://sourceware.org/pipermail/gdb-patches/2024-June/209779.html

2024-06-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-18  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Add GPL header comment to gdb/features/feature_to_c.awk
	Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh")
	factored out new file gdb/features/feature_to_c.awk out of
	gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add
	this now.

	Tested on x86_64-linux.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf, include: new functions for looking up enumerators
	Three new functions for looking up the enum type containing a given
	enumeration constant, and optionally that constant's value.

	The simplest, ctf_lookup_enumerator, looks up a root-visible enumerator by
	name in one dict: if the dict contains multiple such constants (which is
	possible for dicts created by older versions of the libctf deduplicator),
	ECTF_DUPLICATE is returned.

	The next simplest, ctf_lookup_enumerator_next, is an iterator which returns
	all enumerators with a given name in a given dict, whether root-visible or
	not.

	The most elaborate, ctf_arc_lookup_enumerator_next, finds all
	enumerators with a given name across all dicts in an entire CTF archive,
	whether root-visible or not, starting looking in the shared parent dict;
	opened dicts are cached (as with all other ctf_arc_*lookup functions) so
	that repeated use does not incur repeated opening costs.

	All three of these return enumerator values as int64_t: unfortunately, API
	compatibility concerns prevent us from doing the same with the other older
	enum-related functions, which all return enumerator constant values as ints.
	We may be forced to add symbol-versioning compatibility aliases that fix the
	other functions in due course, bumping the soname for platforms that do not
	support such things.

	ctf_arc_lookup_enumerator_next is implemented as a nested ctf_archive_next
	iterator, and inside that, a nested ctf_lookup_enumerator_next iterator
	within each dict.  To aid in this, add support to ctf_next_t iterators for
	iterators that are implemented in terms of two simultaneous nested iterators
	at once.  (It has always been possible for callers to use as many nested or
	semi-overlapping ctf_next_t iterators as they need, which is one of the
	advantages of this style over the _iter style that calls a function for each
	thing iterated over: the iterator change here permits *ctf_next_t iterators
	themselves* to be implemented by iterating using multiple other iterators as
	part of their internal operation, transparently to the caller.)

	Also add a testcase that tests all these functions (which is fairly easy
	because ctf_arc_lookup_enumerator_next is implemented in terms of
	ctf_lookup_enumerator_next) in addition to enumeration addition in
	ctf_open()ed dicts, ctf_add_enumerator duplicate enumerator addition, and
	conflicting enumerator constant deduplication.

	include/
		* ctf-api.h (ctf_lookup_enumerator): New.
		(ctf_lookup_enumerator_next): Likewise.
		(ctf_arc_lookup_enumerator_next): Likewise.

	libctf/
		* libctf.ver: Add them.
		* ctf-impl.h (ctf_next_t) <ctn_next_inner>: New.
		* ctf-util.c (ctf_next_copy): Copy it.
	        (ctf_next_destroy): Destroy it.
		* ctf-lookup.c (ctf_lookup_enumerator): New.
		(ctf_lookup_enumerator_next): New.
		* ctf-archive.c (ctf_arc_lookup_enumerator_next): New.
		* testsuite/libctf-lookup/enumerator-iteration.*: New test.
		* testsuite/libctf-lookup/enum-ctf-2.c: New test CTF, used by the
		  above.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	include: libctf: comment improvements
	Describe a bit more clearly what effects a type being non-root-
	visible has.  More consistently use the term non-root-visible
	rather than hidden.  Document ctf_enum_iter.

	include/
		* ctf-api.h (ctf_enum_iter): Document.
	        (ctf_type_iter): Hidden, not non-root.  Mention that
	        parent dictionaries are not traversed.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: make the ctf_next ctn_fp non-const
	This was always an error, because the ctn_fp routinely has errors set on it,
	which is not something you can (or should) do to a const object.

	libctf/
		* ctf-impl.h (ctf_next_) <cu.ctn_fp>: Make non-const.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: prohibit addition of enums with overlapping enumerator constants
	libctf has long prohibited addition of enums with overlapping constants in a
	single enum, but now that we are properly considering enums with overlapping
	constants to be conflciting types, we can go further and prohibit addition
	of enumeration constants to a dict if they already exist in any enum in that
	dict: the same rules as C itself.

	We do this in a fashion vaguely similar to what we just did in the
	deduplicator, by considering enumeration constants as identifiers and adding
	them to the core type/identifier namespace, ctf_dict_t.ctf_names.  This is a
	little fiddly, because we do not want to prohibit opening of existing dicts
	into which the deduplicator has stuffed enums with overlapping constants!
	We just want to prohibit the addition of *new* enumerators that violate that
	rule.  Even then, it's fine to add overlapping enumerator constants as long
	as at least one of them is in a non-root type.  (This is essential for
	proper deduplicator operation in cu-mapped mode, where multiple compilation
	units can be smashed into one dict, with conflicting types marked as
	hidden: these types may well contain overlapping enumerators.)

	So, at open time, keep track of all enums observed, then do a third pass
	through the enums alone, adding each enumerator either to the ctf_names
	table as a mapping from the enumerator name to the enum it is part of (if
	not already present), or to a new ctf_conflicting_enums hashtable that
	tracks observed duplicates. (The latter is not used yet, but will be soon.)

	(We need to do a third pass because it's quite possible to have an enum
	containing an enumerator FOO followed by a type FOO: since they're processed
	in order, the enumerator would be processed before the type, and at that
	stage it seems nonconflicting.  The easiest fix is to run through the
	enumerators after all type names are interned.)

	At ctf_add_enumerator time, if the enumerator to which we are adding a type
	is root-visible, check for an already-present name and error out if found,
	then intern the new name in the ctf_names table as is done at open time.

	(We retain the existing code which scans the enum itself for duplicates
	because it is still an error to add an enumerator twice to a
	non-root-visible enum type; but we only need to do this if the enum is
	non-root-visible, so the cost of enum addition is reduced.)

	Tested in an upcoming commit.

	libctf/
		* ctf-impl.h (ctf_dict_t) <ctf_names>: Augment comment.
	        <ctf_conflicting_enums>: New.
		(ctf_dynset_elements): New.
		* ctf-hash.c (ctf_dynset_elements): Implement it.
		* ctf-open.c (init_static_types): Split body into...
	        (init_static_types_internal): ... here.  Count enumerators;
	        keep track of observed enums in pass 2; populate ctf_names and
	        ctf_conflicting_enums with enumerators in a third pass.
		(ctf_dict_close): Free ctf_conflicting_enums.
		* ctf-create.c (ctf_add_enumerator): Prohibit addition of duplicate
	        enumerators in root-visible enum types.

	include/
		* ctf-api.h (CTF_ADD_NONROOT): Describe what non-rootness
	        means for enumeration constants.
		(ctf_add_enumerator):  The name is not a misnomer.
	        We now require that enumerators have unique names.
	        Document the non-rootness of enumerators.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: suppress spurious failure of malloc-counting tests under valgrind
	The libctf-regression/open-error-free.c test works by interposing malloc
	and counting mallocs and frees across libctf operations.  This only
	works under suitably-interposable mallocs on systems supporting
	dlsym (RTLD_NEXT, ...), so its operation is restricted to glibc
	systems for now, but also it interacts badly with valgrind, which
	interposes malloc itself.  Detect a running valgrind and skip the test.

	Add new facilities allowing libctf lookup tests to declare themselves
	unsupported, by printing "UNSUPPORTED: " and then some meaningful
	message instead of their normal output.

	libctf/
		* configure.ac: Check for <valgrind/valgrind.h>.
		* config.h.in: Regenerate.
		* configure: Likewise.
		* testsuite/lib/ctf-lib.exp (run_lookup_test): Add support for
		UNSUPPORTED tests.
		* testsuite/libctf-regression/open-error-free.c: When running
		under valgrind, this test is unsupported.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix dict leak on archive-wide symbol lookup error path
	If a lookup fails for a reason unrelated to a lack of type data for this
	symbol, we return with an error; but we fail to close the dict we opened
	most recently, which is leaked.

	libctf/
		* ctf-archive.c (ctf_arc_lookup_sym_or_name): Close dict.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: don't leak enums if ctf_add_type fails
	If ctf_add_type failed in the middle of enumerator addition, the
	destination would end up containing the source enum type and some
	but not all of its enumerator constants.

	Use snapshots to roll back the enum addition as a whole if this happens.
	Before now, it's been pretty unlikely, but in an upcoming commit we will ban
	addition of enumerators that already exist in a given dict, making failure
	of ctf_add_enumerator and thus of this part of ctf_add_type much more
	likely.

	libctf/
		* ctf-create.c (ctf_add_type_internal): Roll back if enum or
	          enumerator addition fails.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: dedup: enums with overlapping enumerators are conflicting
	The CTF deduplicator was not considering enumerators inside enum types to be
	things that caused type conflicts, so if the following two TUs were linked
	together, you would end up with the following in the resulting dict:

	1.c:
	enum foo { A, B };

	2.c:
	enum bar { A, B };

	linked:

	enum foo { A, B };
	enum bar { A, B };

	This does work -- but it's not something that's valid C, and the general
	point of the shared dict is that it is something that you could potentially
	get from any valid C TU.

	So consider such types to be conflicting, but obviously don't consider
	actually identical enums to be conflicting, even though they too have (all)
	their identifiers in common.  This involves surprisingly little code. The
	deduplicator detects conflicting types by counting types in a hash table of
	hash tables:

	decorated identifier -> (type hash -> count)

	where the COUNT is the number of times a given hash has been observed: any
	name with more than one hash associated with it is considered conflicting
	(the count is used to identify the most common such name for promotion to
	the shared dict).

	Before now, those identifiers were all the identifiers of types (possibly
	decorated with their namespace on the front for enumerator identifiers), but
	we can equally well put *enumeration constant names* in there, undecorated
	like the identifiers of types in the global namespace, with the type hash
	being the hash of each enum containing that enumerator.  The existing
	conflicting-type-detection code will then accurately identify distinct enums
	with enumeration constants in common.  The enum that contains the most
	commonly-appearing enumerators will be promoted to the shared dict.

	libctf/
		* ctf-impl.h (ctf_dedup_t) <cd_name_counts>: Extend comment.
		* ctf-dedup.c (ctf_dedup_count_name): New, split out of...
		(ctf_dedup_populate_mappings): ... here.  Call it for all
		* enumeration constants in an enum as well as types.

	ld/
		* testsuite/ld-ctf/enum-3.c: New test CTF.
		* testsuite/ld-ctf/enum-4.c: Likewise.
		* testsuite/ld-ctf/overlapping-enums.d: New test.
		* testsuite/ld-ctf/overlapping-enums-2.d: Likewise.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: doc: fix ctf_stype_t typedef string in spec

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	include: fix libctf ECTF_NOENUMNAM error message
	ECTF_NOENUMNAM is emitted when enumerator constant names don't exist.
	Call them that, not 'enum elements'.

	include/
		* ctf-api.h (ECTF_NOENUMNAM): fix error message.

2024-06-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: strtab corruption when strings are added to ctf_open()ed dicts
	ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed
	to return a strtab offset.  These offsets are "provisional": the ref
	mechanism records the address of the location in which the ref is stored and
	modifies it when the strtab is finally written out.  Provisional refs in new
	dicts start at 0 and go up via strlen() as new refs are added: this is fine,
	because the strtab is empty and none of these values will overlap any
	existing string offsets (since there are none).  Unfortunately, when a dict
	is ctf_open()ed, we fail to set the initial provisional strtab offset to a
	higher value than any existing string offset: it starts at zero again!
	It's a shame that we already *have* strings at those offsets...

	This is all fixed up once the string is reserialized, but if you look up
	newly-added strings before serialization, you get corrupted partial string
	results from the existing ctf_open()ed dict.

	Observed (and thus regtested) by an upcoming test (in this patch series).

	Exposed by the recently-introduced series that permits modification of
	ctf_open()ed dicts, which has not been released anywhere.  Before that,
	any attempt to do such things would fail with ECTF_RDONLY.

	libctf/
		* ctf-string.c (ctf_str_create_atoms): Initialize
	        ctf_str_prov_offset.

2024-06-18  Jan Beulich  <jbeulich@suse.com>

	readelf: rename recently added testsuite files
	Files named *.0 are somewhat odd for testsuite expectations. Rename the
	one such file to *.r with a suitable base name suffix, and have its
	sibling follow suit in this latter regard.

2024-06-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Fixed typo from smscrind to smcsrind in riscv_implicit_subsets.
	bfd/
		* elfxx-riscv.c (riscv_implicit_subsets): Fixed type from smscrind to
		smcsrind.
	gas/
		* testsuite/gas/riscv/march-imply-smcsrind.d: New testcase.  It fails
		without applying this patch.

2024-06-18  Nick Clifton  <nickc@redhat.com>

	Ensure that the text segment is aligned on disk when using --rosegment.

2024-06-18  Felix Willgerodt  <felix.willgerodt@intel.com>
	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb: rename offset to high bits in ymm registers
	The xsave_ymm_avx512_offset data structure contains the xsave
	offset to the upper 128 bits of a ymm register.  Similarly, for zmm this
	offset is described by xsave_avx512_zmm_h_offset, h indicating the
	high bits.  This commit renames the xsave_ymm_avx512_offset to
	xsave_ymm_h_avx512_offset - as well as the associated define from
	XSAVE_YMM_AVX512_ADDR to XSAVE_YMM_H_AVX512_ADDR - to make this
	more consistent.

	Note, that the regnum defines already included the 'h' for ymm, like
	I387_YMM16H_REGNUM and I387_YMMH_AVX512_END_REGNUM.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Updated gas/NEWS and gas/doc/c-riscv.texi for vendor extensions.
	gas/
		* NEWS: Updated for XCvMem, XCvBi, XCvElw, XSfCease.
		* doc/c-riscv.texi: Minor typo for XCv* extensions.

2024-06-18  Hau Hsu  <hau.hsu@sifive.com>

	RISC-V: Add SiFive cease extension v1.0
	Add SiFive cease extension,
	https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf

	This aligns LLVM:
	* https://llvm.org/docs/RISCVUsage.html
	* https://github.com/llvm/llvm-project/pull/83896

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_supported_vendor_x_ext): Add support for
		'xsfcease'.
		(riscv_multi_subset_supports): Handle INSN_CLASS_XSFCEASE.
		(riscv_multi_subset_supports_ext): Handle INSN_CLASS_XSFCEASE.

	gas/ChangeLog:

		* doc/c-riscv.texi: Updated.
		* testsuite/gas/riscv/march-help.l: Updated.
		* testsuite/gas/riscv/sifive-insns.d: Add test case for 'sf.cease'.
		* testsuite/gas/riscv/sifive-insns.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_SF_CEASE, MASK_SF_CEASE): Define match and
		mask encoding for 'sf.cease'.
		* opcode/riscv.h (INSN_CLASS_XSFCEASE): Add new instruction class for
		'xsfcease'.

	opcodes/ChangeLog:

	    * riscv-opc.c (riscv_opcodes): Add opcode entry for 'sf.cease'.

2024-06-18  Gianluca Guida  <gianluca@rivosinc.com>

	RISC-V: Support Zacas extension.
	https://github.com/riscvarchive/riscv-zacas/releases/tag/v1.0

	The Zacas extension introduce compare-and-swap instructions to operate
	on 32-bit, 64-bit and 128-bit (RV64 only) data values.

	It introduces three new instructions:
	  - amocas.w (32-bit CAS)
	  - amocas.d (64-bit CAS)
	  - amocas.q (128-bit CAS, RV64 only)

	Like other AMOs in the A extension, Zacas instructions have '.aq',
	'.rl' and '.aqrl' variations.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): 'A' implied by 'Zacas'.
		(riscv_supported_std_z_ext): Add 'Zacas' extension.
		(riscv_multi_subset_supports, riscv_multi_subset_supports_ext):
		Handle INSN_CLASS_ZACAS case.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Updated.
		* testsuite/gas/riscv/zacas-32.d: New test (RV32).
	        * testsuite/gas/riscv/zacas-fail-32.d: Likewise.
		* testsuite/gas/riscv/zacas-64.d: New test (RV64).
	        * testsuite/gas/riscv/zacas-fail-64.d: Likewise.
		* testsuite/gas/riscv/zacas.s: New test source.
		* testsuite/gas/riscv/zacas-fail.s: Likewise.
		* testsuite/gas/riscv/zacas-fail-32.l: New file.
		* testsuite/gas/riscv/zacas-fail-64.l: Likewise.

	include/ChangeLog:

		* include/opcode/riscv.h (INSN_CLASS_ZACAS): New definition.
		* include/opcode/riscv-opc.h (MATCH_AMOCAS_W, MASK_AMOCAS_W)
		(MATCH_AMOCAS_D, MASK_AMOCAS_D, MATCH_AMOCAS_Q, MASK_AMOCAS_Q):
		Likewise.
		(amocas_w, amocas_d, amocas_q): Declare instructions.

	opcodes/ChangeLog:

		* riscv-opc.c (match_rs2_rd_even): New function.
		(amocas_w, amocas_d, amocas_q, amocas_w.aq)
		(amocas_d.aq, amocas_q.aq, amocas_w.rl, amocas_d.rl, amocas_q.rl)
		(amocas_w.aqrl, amocas_d.aqrl, amocas_q.aqrl): Add instructions.

2024-06-18  Cui, Lili  <lili.cui@intel.com>

	x86: Fix typo in i386-dis-evex-mod.h
	opcodes/ChangeLog:

	        * i386-dis-evex-mod.h: Used MOD_EVEX_MAP4_F8_P_1/MOD_EVEX_MAP4_F8_P_3
	        instead of MOD_EVEX_MAP4_F8_P1/MOD_EVEX_MAP4_F8_P3.

2024-06-18  Cui, Lili  <lili.cui@intel.com>

	Remove %ME and used %NE for movbe.
	%ME is added specifically for movbe. Now with %NE, we can use
	MOD table + %NE to indicate whether a {evex} prefix is needed.

	opcodes/ChangeLog:

	        * i386-dis-evex-mod.h: Added movbe.
	        * i386-dis-evex.h: Let movbe go through the mod table.
	        * i386-dis.c (struct dis386): Removed %ME.
	        (putop): Removed case ME.

2024-06-18  Cui, Lili  <lili.cui@intel.com>

	Support APX CCMP and CTEST
	CCMP and CTEST are two new sets of instructions for conditional CMP
	and TEST, SCC and OSZC flags are given as suffixes of CCMP or CTEST
	in the instruction mnemonic, e.g.:

	ccmp<cc> { dfv=sf , cf , of } %eax, %ecx

	also add

	{evex} cmp/test %eax, %ecx

	as an alias for ccmpt.

	For the encoder part, add function check_Scc_OszcOperation to parse
	'{ dfv=of , sf, sf, cf}', store scc in the lower 4 bits of base_opcode,
	and adjust base_opcode to its normal meaning in install_template.

	For the decoder part, add 'SC' and 'DF' macros to add scc and oszc flags
	suffixes.

	gas/ChangeLog:

	        * config/tc-i386.c (OSZC_CF): New.
	        (OSZC_ZF): Ditto.
	        (OSZC_SF): Ditto.
	        (OSZC_OF): Ditto.
	        (set_oszc_flags): Set oszc flags and report error for using the same oszc flags twice.
	        (check_Scc_OszcOperations): Handle SCC OSZC flags.
	        (install_template): Add scc and oszc_flags.
	        (build_apx_evex_prefix): Encode SCC and oszc flags bits.
	        (parse_insn): Handle check_Scc_OszcOperations.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add ivalid test case.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.
	        * testsuite/gas/i386/x86-64.exp: Add test for ccmp and ctest.
	        * testsuite/gas/i386/x86-64-apx-ccmp-ctest-intel.d: New test.
	        * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.l: Ditto.
	        * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.s: Ditto.
	        * testsuite/gas/i386/x86-64-apx-ccmp-ctest.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-ccmp-ctest.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex-reg.h: Add ccmp and ctest.
	        * i386-dis-evex.h: Ditto.
	        * i386-dis.c (struct instr_info): add scc.
	        (struct dis386): Add new micro 'NE','SC' and'DF'.
	        (get_valid_dis386): Get scc value and move MAP4 invalid check to print_insn.
	        (putop): Handle %NE, %SC and %DF.
	        * i386-opc.h (SCC): New.
	        * i386-opc.tbl: Add ccmp/ctest and evex format for cmp/test.
	        * i386-mnem.h: Regenerated.
	        * i386-tbl.h: Ditto.

2024-06-18  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: add .option directive
	In some cases we may want to use different options only for certain
	assembly, so the .option directive is added to control the assembler
	options.

	.option can accept 4 parameters:

	push
	pop
	  Pushes or pops the current option stack. They limit the scope of
	  option changes so that they do not affect other parts of the assembly
	  file.

	relax
	norelax
	  Enables or disables relaxation.

2024-06-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-17  Maciej W. Rozycki  <macro@redhat.com>

	GAS/testsuite: Make a copy of none.s before operating on it as output
	The "Output file must be distinct from input" test in gas/all/gas.exp
	operates on none.s as output.  Should the test fail it may happen that
	GAS will delete the output file requested in which case none.s will be
	removed.  Since the test operates directly on the source tree it will be
	clobbered as a result.  It has actually been observed in the field in
	the form of intermittent:

	FAIL: gas/all/none

	regressions in a parallel run of many configurations.

	Prevent this from happening by copying none.s first to the test object
	directory and operating on it instead.  It does not prevent the file
	from being removed should the test fail, but the source tree won't be
	clobbered in that case.

	A nice side effect is that syntactically different paths will now be
	used in this test for the input and the output file each, so coverage
	will extend to verifying that a file is checked against itself even if
	referred to via different paths.  Previously "$srcdir/$subdir/none.s"
	was used for both paths and now "tmpdir/none.s" is referred to directly
	and via a relative path from "$srcdir/$subdir" respectively.

	I note that we have no previous use of the UNRESOLVED test result in the
	GAS testsuite, but it seems the correct one should copying none.s fail,
	as this is an unexpected situation that requires a human intervention
	and the test proper has not been evaluated.

2024-06-17  Maciej W. Rozycki  <macro@redhat.com>

	GAS/testsuite: Add a helper for paths outside the source dir
	Implement a helper to construct a relative path from $srcdir/$subdir,
	where `gas_run' operates, to an arbitrary place in the filesystem, for
	example a file in the test object directory.

2024-06-17  Maciej W. Rozycki  <macro@redhat.com>

	binutils/testsuite: Add a helper for relative path construction
	Implement a helper to construct a relative path between two locations in
	the filesystem, for example to make a path from the source to the object
	directory for the case where a tool has been set up to look at a given
	path and there is a need to point it elsewhere, but an absolute path
	will not work.  The helper works on normalized paths internally, so the
	result is correct even in the presence of symlinks as intermediate path
	components.

	So given "/path/to/src/gas/testsuite/gas/all" as the FROM argument and
	then "/path/to/obj/gas/testsuite/tmpdir/none.s" as the TO argument the
	helper will return "../../../../../obj/gas/testsuite/tmpdir/none.s" in
	the absence of symlinks.

2024-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix duplicates in gdb.fortran/array-{indices,repeat}.exp
	When running test-case gdb.fortran/array-indices.exp on a system without
	fortran compiler, I run into a duplicate:
	...
	Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ...
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
	gdb compile failed, default_target_compile: Can't find gfortran.
	UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
	DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp
	...

	Fix this by adding a with_test_prefix at the toplevel.

	Likewise in gdb.fortran/array-repeat.exp.

	Tested on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-06-17  Alan Modra  <amodra@gmail.com>

	PR31898 bug in processing DW_RLE_startx_endx
		PR 31898
		* dwarf.c (display_debug_rnglists_list): Correct fetch of "end"
		indexed address.  Remove excess parens.

2024-06-17  Alan Modra  <amodra@gmail.com>

	Error messages emitted during bfd_check_format_matches
	Error/warning messages are only printed for the target that
	successfully matched, which makes sense for warnings, but not so much
	for errors where the errors cause no target to match.  I noticed this
	when looking at the pr20520 testcase again with objdump, which just
	reports "file format not recognized" omitting the five "SHT_GROUP
	section [index n] has no SHF_GROUP sections" messages.  They are
	omitted because multiple ELF targets match the object file.  This is
	going to be true for all ELF objects due to at least the proper ELF
	target and the generic ELF target matching.

		* format.c (print_and_clear_messages): Print messages if all
		targets with messages have exactly the same set of messages.

2024-06-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-16  Tom Tromey  <tom@tromey.com>

	Make tui_register_info::highlight private
	This changes tui_register_info::highlight to be private, renaming it
	to m_highlight.

2024-06-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-15  Tom Tromey  <tom@tromey.com>

	Remove a call to fflush
	This TUI code calls fflush on stdout, but I don't believe this is
	useful in gdb.

2024-06-15  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Cleanup gdb/features/feature_to_c.sh
	Clean up script gdb/features/feature_to_c.sh by:
	- fixing shellcheck warnings,
	- moving an embedded awk script out of the file, reducing the amount of
	  escaping in the awk script, making it more readable and maintainable, and
	- adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh).

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-06-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean up lib/dg-add-core-file-count.sh
	Fix shellcheck warnings in script lib/dg-add-core-file-count.sh.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-06-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean up formatting in gdb/contrib/cc-with-tweaks.sh
	In emacs, on gdb/contrib/cc-with-tweaks.sh, do:
	- M-x whitespace-cleanup,
	- M-x mark-whole-buffer and M-x indent-region, and
	- and undo the unwanted changes in the header comment.

	Only whitespace changes.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-06-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean up gdb/contrib/cc-with-tweaks.sh
	Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-06-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean up gdb/contrib/expect-read1.sh
	Clean up script gdb/contrib/expect-read1.sh by:
	- fixing shellcheck warnings,
	- using mktemp (which takes TMPDIR into account) instead of a hardcoded
	  "/tmp/expect-read1.$$.so",
	- adding comments, and
	- adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh).

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-06-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-14  H.J. Lu  <hjl.tools@gmail.com>

	x86: Add -z isa-level-report=[none|all|needed|used]
	Add -z isa-level-report=[none|all|needed|used] to the x86 ELF linker to
	report needed and used x86-64 ISA levels.

	bfd/

		PR ld/31868
		* elf-linker-x86.h (elf_x86_isa_level_report): New.
		(elf_linker_x86_params): Add isa_level_report.
		* elfxx-x86.c (report_isa_level): New.
		(_bfd_x86_elf_link_setup_gnu_properties): Check
		-z isa-level-report=[none|all|needed|used] to report needed and
		used x86-64 ISA level.

	ld/

		PR ld/31868
		* NEWS: Mention -z isa-level-report=[none|all|needed|used].
		* ld.texi: Document -z isa-level-report=[none|all|needed|used].
		* emulparams/elf32_x86_64.sh: Source x86-64-level-report.sh.
		* emulparams/elf_i386.sh: Likewise.
		* emulparams/elf_x86_64.sh: Likewise.
		* emulparams/x86-64-level-report.sh: New file.
		* testsuite/ld-i386/pr31868a.d: Likewise.
		* testsuite/ld-i386/pr31868b.d: Likewise.
		* testsuite/ld-i386/pr31868c.d: Likewise.
		* testsuite/ld-x86-64/pr31868a-x32.d: Likewise.
		* testsuite/ld-x86-64/pr31868a.d: Likewise.
		* testsuite/ld-x86-64/pr31868a.l: Likewise.
		* testsuite/ld-x86-64/pr31868a.s: Likewise.
		* testsuite/ld-x86-64/pr31868b-x32.d: Likewise.
		* testsuite/ld-x86-64/pr31868b.d: Likewise.
		* testsuite/ld-x86-64/pr31868b.l: Likewise.
		* testsuite/ld-x86-64/pr31868b.s: Likewise.
		* testsuite/ld-x86-64/pr31868c-x32.d: Likewise.
		* testsuite/ld-x86-64/pr31868c.d: Likewise.
		* testsuite/ld-x86-64/pr31868c.l: Likewise.
		* testsuite/ld-i386/i386.exp: Run PR ld/31868 tests.
		* testsuite/ld-x86-64/x86-64.exp: Likewise.

2024-06-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Align --no-error-execstack help output
		* lexsup.c (elf_static_list_options): Align --no-error-execstack
		help output.

2024-06-14  Tom Tromey  <tromey@adacore.com>

	Simplify ada_lookup_encoded_symbol
	This patch simplifies ada_lookup_encoded_symbol by having it return
	its result, rather than returning void and having an out parameter.

	Introduce language_defn::lookup_symbol_local
	This introduces the new method language_defn::lookup_symbol_local, and
	then changes lookup_symbol_local to use it.  This removes an explicit
	language check from this function, and makes it easier for other
	languages to hook into this code.

	Remove an unnecessary null check from lookup_local_symbol
	lookup_local_symbol checks whether 'function' is null before calling
	block::inlined_p, but this is not necessary.

	Simplify lookup_local_symbol
	This simplifies lookup_local_symbol a little, by having it check
	whether the current block is the static or global block, instead of
	first searching for the static block.

2024-06-14  Tom Tromey  <tromey@adacore.com>

	Examine template symbols in lookup_local_symbol
	This changes lookup_local_symbol to directly examine any attached
	template symbols, rather than gating this lookup on the use of C++ or
	Fortran.  As mentioned in an earlier patch, these objects are not
	necessarily C++-specific, and doing the search generically seems
	better.

	This also renames cp_lookup_symbol_imports_or_template now that the
	"template" part has been removed.

2024-06-14  Tom Tromey  <tromey@adacore.com>

	Move search_symbol_list to symtab.c
	This moves search_symbol_list to symtab.c and exports it.  It will be
	useful in a later patch.

	Rename is_cplus_template_function
	This patch renames is_cplus_template_function to is_template_function.
	There is nothing C++-specific about this code, and the code in the
	DWARF reader that creates these objects is not C++-specific.  In fact
	this may already be used by Rust (though I didn't check).

2024-06-14  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add SPMU system registers missed in f01ae0392ed

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/aarch64: prevent crash from in process agent
	Since this commit:

	  commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d
	  Date:   Wed May 18 13:32:04 2022 -0700

	      Use aarch64_features to describe register features in target descriptions.

	There has been an issue with how aarch64 target descriptions are
	cached within gdbserver, and specifically, how this caching impacts
	the in process agent (IPA).

	The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is
	part of the IPA, this function is a constructor function, i.e. is
	called as part of the global initialisation process.  We can't
	guarantee the ordering of when this function is called vs when other
	global state is initialised.

	Now initialize_tracepoint_ftlib calls initialize_tracepoint, which
	calls initialize_low_tracepoint, which for aarch64 calls
	aarch64_linux_read_description.

	The aarch64_linux_read_description function lives in
	linux-aarch64-tdesc.cc and after the above commit, depends on a
	std::unordered_map having been initialized.

	Prior to the above commit aarch64_linux_read_description used a global
	C style array, which obviously requires no runtime initialization.

	The consequence of the above is that any inferior linked with the IPA
	(for aarch64) will experience undefined behaviour (access to an
	uninitialized std::unordered_map) during startup, which for me
	manifests as a segfault.

	I propose fixing this by moving the std::unordered_map into the
	function body, but leaving it static.  The map will now be initialized
	the first time the function is called, which removes the undefiend
	behaviour.

	The same problem exists for the expedited_registers global, however
	this global can just be made into a function local instead.  The
	expedited_registers variable is used to build a pointer list which is
	then passed to init_target_desc, however init_target_desc copies the
	values it is given so expedited_registers does not need to live longer
	than its containing function.

	On most of the AArch64 machines I have access too tracing is not
	supported, and so the gdb.trace/*.exp tests that use the IPA just exit
	early reporting unsupported.  I've added a test which links an
	inferior with the IPA and just starts the inferior.  No tracing is
	performed.  This exposes the current issue even on hosts that don't
	support tracing.  After this patch the test passes.

2024-06-14  Nick Clifton  <nickc@redhat.com>

	Regenerate configure files in ld sub-directory

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share x86/linux tdesc caching
	This commit builds on the previous series of commits to share the
	target description caching code between GDB and gdbserver for
	x86/Linux targets.

	The objective of this commit is to move the four functions (2 each of)
	i386_linux_read_description and amd64_linux_read_description into the
	gdb/arch/ directory and combine them so we have just a single copy of
	each.  Then GDB, gdbserver, and the in-process-agent (IPA) will link
	against these shared functions.

	One curiosity with this patch is the function
	x86_linux_post_init_tdesc.  On the gdbserver side the two functions
	amd64_linux_read_description and i386_linux_read_description have some
	functionality that is not present on the GDB side, there is some
	additional configuration that is performed as each target description
	is created, to setup the expedited registers.

	To support this I've added the function x86_linux_post_init_tdesc.
	This function is called from the two *_linux_read_description
	functions, but is implemented separately for GDB and gdbserver.

	An alternative approach that avoids adding x86_linux_post_init_tdesc
	would be to have x86_linux_tdesc_for_tid return a non-const target
	description, then in x86_target::low_arch_setup we could inspect the
	target description to figure out if it is 64-bit or not, and modify
	the target description as needed.  In the end I think that adding the
	x86_linux_post_init_tdesc function is the simpler solution.

	The contents of gdbserver/linux-x86-low.cc have moved to
	gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h
	has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to
	some updates in the #includes in the gdbserver/ directory.

	This commit also changes how target descriptions are cached.
	Previously both GDB and gdbserver used static C-style arrays to act as
	the tdesc cache.  This was fine, except for two problems.  Either the
	C-style arrays would need to be placed in x86-linux-tdesc-features.c,
	which would allow us to use the x86_linux_*_tdesc_count_1() functions
	to size the arrays for us, or we'd need to hard code the array sizes
	using separate #defines, which we'd then have to keep in sync with the
	rest of the code in x86-linux-tdesc-features.c.

	Given both of these problems I decided a better solution would be to
	just switch to using a std::unordered_map to act as the cache.  This
	will resize automatically, and we can use the xcr0 value as the key.

	At first inspection, using xcr0 might seem to be a problem; after all
	the {i386,amd64}_create_target_description functions take more than
	just the xcr0 value.  However, this patch is only for x86/Linux
	targets, and for x86/Linux all of the other flags passed to the tdesc
	creation functions have constant values and so are irrelevant when we
	consider tdesc caching.

	For testing I've done the following:

	  - Built on x86-64 GNU/Linux for all targets, and just for the native
	    target,

	  - Build on i386 GNU/Linux for all targets, and just for the native
	    target,

	  - Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the
	    native target, and for targets x86_64-*-linux and i386-*-linux.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: update target description creation for x86/linux
	This commit is part of a series which aims to share more of the target
	description creation between GDB and gdbserver for x86/Linux.

	After some refactoring earlier in this series the shared
	x86_linux_tdesc_for_tid function was added into nat/x86-linux-tdesc.c.
	However, this function still relies on amd64_linux_read_description
	and i386_linux_read_description which are implemented separately for
	both gdbserver and GDB.  Given that at their core, all these functions
	do is:

	  1. take an xcr0 value as input,
	  2. mask out some feature bits,
	  3. look for a cached pre-generated target description and return it
	     if found,
	  4. if no cached target description is found then call either
	     amd64_create_target_description or
	     i386_create_target_description to create a new target
	     description, which is then added to the cache.  Return the newly
	     created target description.

	The inner functions amd64_create_target_description and
	i386_create_target_description are already shared between GDB and
	gdbserver (in the gdb/arch/ directory), so the only thing that
	the *_read_description functions really do is add the caching layer,
	and it feels like this really could be shared.

	However, we have a small problem.

	Despite using the same {amd64,i386}_create_target_description
	functions in both GDB and gdbserver to create the target descriptions,
	on the gdbserver side we cache target descriptions based on a reduced
	set of xcr0 feature bits.

	What this means is that, in theory, different xcr0 values can map to
	the same cache entry, which could result in the wrong target
	description being used.

	However, I'm not sure if this can actually happen in reality.  Within
	gdbserver we already split the target description cache based on i386,
	amd64, and x32.  I suspect within a given gdbserver session we'll only
	see at most one target description for each of these.

	The cache conflicting problem is caused by xcr0_to_tdesc_idx, which
	maps an xcr0 value to a enum x86_linux_tdesc value, and there are only
	7 usable values in enum x86_linux_tdesc.

	In contrast, on the GDB side there are 64, 32, and 16 cache slots for
	i386, amd64, and x32 respectively.

	On the GDB side it is much more important to cache things correctly as
	a single GDB session might connect to multiple different remote
	targets, each of which might have slightly different x86
	architectures.

	And so, if we want to merge the target description caching between GDB
	and gdbserver, then we need to first update gdbserver so that it
	caches in the same way as GDB, that is, it needs to adopt a mechanism
	that allows for the same number of cache slots of each of i386, amd64,
	and x32.  In this way, when the caching is shared, GDB's behaviour
	will not change.

	Unfortunately it's a little more complex than that due to the in
	process agent (IPA).

	When the IPA is in use, gdbserver sends a target description index to
	the IPA, and the IPA uses this to find the correct target description
	to use, the IPA having first generated every possible target
	description.

	Interestingly, there is certainly a bug here which results from only
	having 7 values in enum x86_linux_tdesc.  As multiple possible target
	descriptions in gdbserver map to the same enum x86_linux_tdesc value,
	then, when the enum x86_linux_tdesc value is sent to the IPA there is
	no way for gdbserver to know that the IPA will select the correct
	target description.  This bug will get fixed by this commit.

	** START OF AN ASIDE **

	Back in the day I suspect this approach of sending a target
	description index made perfect sense.  However since this commit:

	  commit a8806230241d201f808d856eaae4d44088117b0c
	  Date:   Thu Dec 7 17:07:01 2017 +0000

	      Initialize target description early in IPA

	I think that passing an index was probably a bad idea.

	We used to pass the index, and then use that index to lookup which
	target description to instantiate and use, the target description was
	not generated until the index arrived.

	However, the above commit fixed an issue where we can't call malloc()
	within (certain parts of) the IPA (apparently), so instead we now
	pre-compute _every_ possible target description within the IPA.  The
	index is only used to lookup which of the (many) pre-computed target
	descriptions to use.

	It would (I think) have been easier all around if the IPA just
	self-inspected, figured out its own xcr0 value, and used that to
	create the one target description that is required.  So long as the
	xcr0 to target description code is shared (at compile time) with
	gdbserver, then we can be sure that the IPA will derive the same
	target description as gdbserver, and we would avoid all this index
	passing business, which has made this commit so very, very painful.

	I did look at how a process might derive its own xcr0 value, but I
	don't believe this is actually that simple, so for now I've just
	doubled down on the index passing approach.

	While reviewing earlier iterations of this patch there has been
	discussion about the possibility of removing the IPA from GDB.  That
	would certainly make all of the code touched in this patch much
	simpler, but I don't really want to do that as part of this series.

	** END OF AN ASIDE **

	Currently then for x86/linux, gdbserver sends a number between 0 and 7
	to the IPA, and the IPA uses this to create a target description.

	However, I am proposing that gdbserver should now create one of (up
	to) 64 different target descriptions for i386, so this 0 to 7 index
	isn't going to be good enough any more (amd64 and x32 have slightly
	fewer possible target descriptions, but still more than 8, so the
	problem is the same).

	For a while I wondered if I was going to have to try and find some
	backward compatible solution for this mess.  But after seeing how
	lightly the IPA is actually documented, I wonder if it is not the case
	that there is a tight coupling between a version of gdbserver and a
	version of the IPA?  At least I'm hoping so, and that's what I've
	assumed in this commit.

	In this commit I have thrown out the old IPA target description index
	numbering scheme, and switched to a completely new numbering scheme.
	Instead of the index that is passed being arbitrary, the index is
	instead calculated from the set of xcr0 features that are present on
	the target.  Within the IPA we can then reverse this logic to recreate
	the xcr0 value based on the index, and from the xcr0 value we can
	choose the correct target description.

	With the gdbserver to IPA numbering scheme issue resolved I have then
	update the gdbserver versions of amd64_linux_read_description and
	i386_linux_read_description so that they cache target descriptions
	using the same set of xcr0 features as GDB itself.

	After this gdbserver should now always come up with the same target
	description as GDB does on any x86/Linux target.

	This commit does not introduce any new code sharing between GDB and
	gdbserver as previous commits in this series have done.  Instead this
	commit is all about bringing GDB and gdbserver into alignment
	functionally so that the next commit(s) can merge the GDB and
	gdbserver versions of these functions.

	Notes On The Implementation
	---------------------------

	Previously, within gdbserver, target descriptions were cached within
	arrays.  These arrays were sized based on enum x86_linux_tdesc and
	xcr0_to_tdesc_idx returned the array (cache) index.

	Now we need different array lengths for each of i386, amd64, and x32.
	And the index to use within each array is calculated based on which
	xcr0 bits are set and valid for a particular target type.

	I really wanted to avoid having fixed array sizes, or having the set
	of relevant xcr0 bits encoded in multiple places.

	The solution I came up with was to create a single data structure
	which would contain a list of xcr0 bits along with flags to indicate
	which of the i386, amd64, and x32 targets the bit is relevant for.  By
	making the table constexpr, and adding some constexpr helper
	functions, it is possible to calculate the sizes for the cache arrays
	at compile time, as well as the bit masks needed to each target type.

	During review it was pointed out[1] that possibly the failure to check
	the SSE and X87 bits for amd64/x32 targets might be an error, however,
	if this is the case then this is an issue that existed long before
	this patch.  I'd really like to keep this patch focused on reworking
	the existing code and try to avoid changing how target descriptions
	are actually created, mostly out of fear that I'll break something.

	[1] https://inbox.sourceware.org/gdb-patches/MN2PR11MB4566070607318EE7E669A5E28E1B2@MN2PR11MB4566.namprd11.prod.outlook.com

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share some code relating to target description creation
	This commit is part of a series to share more of the x86 target
	description creation code between GDB and gdbserver.

	Unlike previous commits which were mostly refactoring, this commit is
	the first that makes a real change, though that change should mostly
	be for gdbserver; I've largely adopted the "GDB" way of doing things
	for gdbserver, and this fixes a real gdbserver bug.

	On a x86-64 Linux target, running the test:

	  gdb.server/connect-with-no-symbol-file.exp

	results in two core files being created.  Both of these core files are
	from the inferior process, created after gdbserver has detached.

	In this test a gdbserver process is started and then, after gdbserver
	has started, but before GDB attaches, we either delete the inferior
	executable, or change its permissions so it can't be read.  Only after
	doing this do we attempt to connect with GDB.

	As GDB connects to gdbserver, gdbserver attempts to figure out the
	target description so that it can send the description to GDB, this
	involves a call to x86_linux_read_description.

	In x86_linux_read_description one of the first things we do is try to
	figure out if the process is 32-bit or 64-bit.  To do this we look up
	the executable via the thread-id, and then attempt to read the
	architecture size from the executable.  This isn't going to work if
	the executable has been deleted, or is no longer readable.

	And so, as we can't read the executable, we default to an i386 target
	and use an i386 target description.

	A consequence of using an i386 target description is that addresses
	are assumed to be 32-bits.  Here's an example session that shows the
	problems this causes.  This is run on an x86-64 machine, and the test
	binary (xx.x) is a standard 64-bit x86-64 binary:

	  shell_1$ gdbserver --once localhost :54321 /tmp/xx.x

	  shell_2$ gdb -q
	  (gdb) set sysroot
	  (gdb) shell chmod 000 /tmp/xx.x
	  (gdb) target remote :54321
	  Remote debugging using :54321
	  warning: /tmp/xx.x: Permission denied.
	  0xf7fd3110 in ?? ()
	  (gdb) show architecture
	  The target architecture is set to "auto" (currently "i386").
	  (gdb) p/x $pc
	  $1 = 0xf7fd3110
	  (gdb) info proc mappings
	  process 2412639
	  Mapped address spaces:

	  	Start Addr   End Addr       Size     Offset  Perms   objfile
	  	  0x400000   0x401000     0x1000        0x0  r--p   /tmp/xx.x
	  	  0x401000   0x402000     0x1000     0x1000  r-xp   /tmp/xx.x
	  	  0x402000   0x403000     0x1000     0x2000  r--p   /tmp/xx.x
	  	  0x403000   0x405000     0x2000     0x2000  rw-p   /tmp/xx.x
	  	0xf7fcb000 0xf7fcf000     0x4000        0x0  r--p   [vvar]
	  	0xf7fcf000 0xf7fd1000     0x2000        0x0  r-xp   [vdso]
	  	0xf7fd1000 0xf7fd3000     0x2000        0x0  r--p   /usr/lib64/ld-2.30.so
	  	0xf7fd3000 0xf7ff3000    0x20000     0x2000  r-xp   /usr/lib64/ld-2.30.so
	  	0xf7ff3000 0xf7ffb000     0x8000    0x22000  r--p   /usr/lib64/ld-2.30.so
	  	0xf7ffc000 0xf7ffe000     0x2000    0x2a000  rw-p   /usr/lib64/ld-2.30.so
	  	0xf7ffe000 0xf7fff000     0x1000        0x0  rw-p
	  	0xfffda000 0xfffff000    0x25000        0x0  rw-p   [stack]
	  	0xff600000 0xff601000     0x1000        0x0  r-xp   [vsyscall]
	  (gdb) info inferiors
	    Num  Description       Connection           Executable
	  * 1    process 2412639   1 (remote :54321)
	  (gdb) shell cat /proc/2412639/maps
	  00400000-00401000 r--p 00000000 fd:03 45907133           /tmp/xx.x
	  00401000-00402000 r-xp 00001000 fd:03 45907133           /tmp/xx.x
	  00402000-00403000 r--p 00002000 fd:03 45907133           /tmp/xx.x
	  00403000-00405000 rw-p 00002000 fd:03 45907133           /tmp/xx.x
	  7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0          [vvar]
	  7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0          [vdso]
	  7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
	  7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0          [stack]
	  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
	  (gdb)

	Notice the difference between the mappings reported via GDB and those
	reported directly from the kernel via /proc/PID/maps, the addresses of
	every mapping is clamped to 32-bits for GDB, while the kernel reports
	real 64-bit addresses.

	Notice also that the $pc value is a 32-bit value.  It appears to be
	within one of the mappings reported by GDB, but is outside any of the
	mappings reported from the kernel.

	And this is where the problem arises.  When gdbserver detaches from
	the inferior we pass the inferior the address from which it should
	resume.  Due to the 32/64 bit confusion we tell the inferior to resume
	from the 32-bit $pc value, which is not within any valid mapping, and
	so, as soon as the inferior resumes, it segfaults.

	If we look at how GDB (not gdbserver) figures out its target
	description then we see an interesting difference.  GDB doesn't try to
	read the executable.  Instead GDB uses ptrace to query the thread's
	state, and uses this to figure out the if the thread is 32 or 64 bit.

	If we update gdbserver to do it the "GDB" way then the above problem
	is resolved, gdbserver now sees the process as 64-bit, and when we
	detach from the inferior we give it the correct 64-bit address, and
	the inferior no longer segfaults.

	Now, I could just update the gdbserver code, but better, I think, to
	share one copy of the code between GDB and gdbserver in gdb/nat/.
	That is what this commit does.

	The cores of x86_linux_read_description from gdbserver and
	x86_linux_nat_target::read_description from GDB are moved into a new
	file gdb/nat/x86-linux-tdesc.c and combined into a single function
	x86_linux_tdesc_for_tid which is called from each location.

	This new function does things mostly the GDB way, some changes are
	needed to allow for the sharing; we now take some pointers for where
	the shared code can cache the xcr0 and xsave layout values.

	Another thing to note about this commit is how the functions
	i386_linux_read_description and amd64_linux_read_description are
	handled.  For now I've left these function as implemented separately
	in GDB and gdbserver.  I've moved the declarations of these functions
	into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are
	left where they are.

	A later commit in this series will make these functions shared too,
	but doing this is not trivial, so I've left that for a separate
	commit.  Merging the declarations as I've done here ensures that
	everyone implements the function to the same API, and once these
	functions are shared (in a later commit) we'll want a shared
	declaration anyway.

	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
	Acked-By: John Baldwin <jhb@FreeBSD.org>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: move xcr0 == 0 check into i386_linux_core_read_description
	Currently, in i386_linux_core_read_description, if GDB fails to
	extract an xcr0 value from the core file, then we will have a default
	zero value for the xcr0 variable, we still call the
	i386_linux_read_description function, which checks for this zero value
	and returns nullptr.

	Back in i386_linux_core_read_description we spot the nullptr return
	value from i386_linux_read_description and call
	i386_linux_read_description again, but this time passing a default
	value for xcr0.

	In the next commit I plan to rework i386_linux_read_description, and
	in so doing I will remove the check for xcr0 == 0, this is inline with
	how the amd64 code is written.

	However, this means that the 'xcr0 == 0' check needs to move up the
	stack to i386_linux_core_read_description, again, this brings the i386
	code into line with the amd64 code.

	This is just a refactor in preparation for the next commit, there
	should be no user visible changes after this commit.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/x86: move reading of cs and ds state into gdb/nat directory
	This patch is part of a series that has the aim sharing the x86 Linux
	target description creation code between GDB and gdbserver.

	Within GDB part of this process involves reading the cs and ds state
	from the 'struct user_regs_struct' using a ptrace call.

	This isn't done by gdbserver, which is part of the motivation for this
	whole series; the approach gdbserver takes is inferior to the approach
	GDB takes (gdbserver relies on reading the file being debugged, and
	extracting similar information from the file headers).

	This commit moves the reading of cs and ds, which is used to figure
	out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat
	directory so that the code can be shared with gdbserver, but at this
	point I'm not actually using the code in gdbserver, that will come
	later.

	As such there should be no user visible changes after this commit, GDB
	continues to do things as it did before (reading cs/ds), while
	gdbserver continues to use its own approach (which doesn't require
	reading cs/ds).

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: move have_ptrace_getregset declaration into gdb/nat directory
	In a later commit I want to access have_ptrace_getregset from a .c
	file in the nat/ directory.  To achieve this I need access to the
	declaration of have_ptrace_getregset.

	Currently have_ptrace_getregset is declared (and defined) twice, once
	in GDB and once in gdbserver.

	This commit moves the declaration into nat/linux-nat.h, but leaves the
	two definitions where they are.  Now, in my later commit, I can pull
	in the declaration from nat/linux-nat.h.

	There should be no user visible changes after this commit.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory
	The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is
	running on a kernel that supports the GETFPXREGS ptrace request.

	Currently this global is declared twice (once in GDB and once in
	gdbserver), I think it makes sense to move this global into the nat/
	directory, and have a single declaration and definition.

	While moving this variable I have converted it to a tribool, as that
	was what it really was, if even used the same numbering as the tribool
	enum (-1, 0, 1).  Where have_ptrace_getfpxregs was used I have updated
	in the obvious way.

	However, while making this change I noticed what I think is a bug in
	x86_linux_nat_target::read_description and x86_linux_read_description,
	both of these functions can be called multiple times, but in both
	cases we only end up calling i386_linux_read_description the first
	time through in the event that PTRACE_GETFPXREGS is not supported.
	This is because initially have_ptrace_getfpxregs will be
	TRIBOOL_UNKNOWN, but after the ptrace call fails we set
	have_ptrace_getfpxregs to TRIBOOL_FALSE.  The next time we attempt to
	read the target description we'll skip the ptrace call, and so skip
	the call to i386_linux_read_description.

	I've not tried to address this preexisting bug in this commit, this is
	purely a refactor, there should be no user visible changes after this
	commit.  In later commits I'll merge the gdbserver and GDB code
	together into the nat/ directory, and after that I'll try to address
	this bug.

	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdbserver/x86: move no-xml code earlier in x86_linux_read_description
	This commit is part of a series that aims to share more of the x86
	target description reading/generation code between GDB and gdbserver.

	There are a huge number of similarities between the code in
	gdbserver's x86_linux_read_description function and GDB's
	x86_linux_nat_target::read_description function, and it is this
	similarity that I plan, in a later commit, to share between GDB and
	gdbserver.

	However, one thing that is different in x86_linux_read_description is
	the code inside the '!use_xml' block.  This is the code that handles
	the case where gdbserver is not allowed to send an XML target
	description back to GDB.  In this case gdbserver uses some predefined,
	fixed, target descriptions.

	First, it's worth noting that I suspect this code is not tested any
	more.  I couldn't find anything in the testsuite that tries to disable
	XML target description support.  And the idea of having a single
	"fixed" target description really doesn't work well when we think
	about all the various x86 extensions that exist.  Part of me would
	like to rip out the no-xml support in gdbserver (at least for x86),
	and if a GDB connects that doesn't support XML target descriptions,
	gdbserver can just give an error and drop the connection.  GDB has
	supported XML target descriptions for 16 years now, I think it would
	be reasonable for our shipped gdbserver to drop support for the old
	way of doing things.

	Anyway.... this commit doesn't do that.

	What I did notice was that, over time, the '!use_xml' block appears to
	have "drifted" within the x86_linux_read_description function; it's
	now not the first check we do.  Instead we make some ptrace calls and
	return a target description generated based on the result of these
	ptrace calls.  Surely it only makes sense to generate variable target
	descriptions if we can send these back to GDB?

	So in this commit I propose to move the '!use_xml' block earlier in
	the x86_linux_read_description function.

	The benefit of this is that this leaves the later half of
	x86_linux_read_description much more similar to the GDB function
	x86_linux_nat_target::read_description and sets us up for potentially
	sharing code between GDB and gdbserver in a later commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition
	Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
	gdbserver.

	This commit moves the definition into gdbsupport/x86-xstate.h, which
	allows the #define to be shared.

	There should be no user visible changes after this commit.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-06-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-13  Tom Tromey  <tromey@adacore.com>

	Add gdbpy_call_method overloads for gdbpy_ref<>
	This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>.
	This is just a small convenience.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-06-13  Tom Tromey  <tromey@adacore.com>

	Return gdbpy_ref<> from gdbpy_call_method
	This changes gdbpy_call_method to return a gdbpy_ref<>.  This is
	slightly safer because it makes it simpler to correctly handle
	reference counts.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-06-13  Nick Clifton  <nickc@redhat.com>

	Adjust linker tests that are sensitive to --rosegment

2024-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.base/fission-macro.exp
	Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT
	macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc
	produces a usable dwarf-5 32-bit .debug_macro.dwo section.

	Add a test-case excercising this.

	Tested on x86_64-linux.

	Tested test-case using a current gcc trunk build, and gcc 14.

2024-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix kfail number in gdb.base/watchpoint-running.exp
	Test-case gdb.base/watchpoint-running.exp reports the following kfail:
	...
	KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111)
	...
	but the referenced gdb PR doesn't exist.

	Fix this by using an actual PR.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833

2024-06-13  Nick Clifton  <nickc@redhat.com>

	Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments.
	  PR 30907

2024-06-13  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Rework INSN_* flags into a consistent block
	For historic reasons we have ended up with a random set of discontiguous
	bit assignments for INSN_* flags within `membership' and `exclusions'
	members of `mips_opcode'.  Some of the bits were previously used for ASE
	assignments and have been reused in a disorganised fashion since `ase'
	has been split off as a member on its own.  It makes them hard to track
	and maintain, and to see how many we still have available for future
	assignments.

	Therefore reorder the flags using consecutive bits and matching the
	order used with the switch statement in `cpu_is_member'.

2024-06-13  Maciej W. Rozycki  <macro@redhat.com>

	MIPS/opcodes: Update INSN_CHIP_MASK for INSN_ALLEGREX
	An update has been missed with commit df18f71b565c ("Add MIPS Allegrex
	CPU as a MIPS2-based CPU") for INSN_CHIP_MASK to include INSN_ALLEGREX.
	Fix it.

2024-06-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove LS_TOKEN_STOKEN macro
	This removes the LS_TOKEN_STOKEN macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove LS_TOKEN_KEYWORD macro
	This removes the LS_TOKEN_KEYWORD macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove PARSER_STREAM macro
	This removes the PARSER_STREAM macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove PARSER_EXPLICIT macro
	This removes the PARSER_EXPLICIT macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove PARSER_RESULT macro
	This removes the PARSER_RESULT macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom Tromey  <tromey@adacore.com>

	Remove PARSER_STATE macro
	This removes the PARSER_STATE macro from linespec.c.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-06-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix error in gdb.server/server-kill-python.exp
	With test-case gdb.server/server-kill-python.exp, I sometimes run into:
	...
	builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \
	  -data-directory data-directory^M
	kill^M
	(gdb) kill^M
	file server-kill-python^M
	The program is not being run.^M
	(gdb) ERROR: Couldn't load server-kill-python into GDB.
	...

	The problem is that the spawn produces a prompt, but it's not explicitly
	consumed.

	This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify
	gdb.server/server-kill-python.exp").

	Fix this by consuming the initial prompt.

	PR testsuite/31819
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819
	Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp"

2024-06-12  Tom Tromey  <tom@tromey.com>

	[gdb/python] Add typesafe wrapper around PyObject_CallMethod
	In gdb/python/py-tui.c we have code like this:
	...
	      gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll",
	                                              "i", num_to_scroll, nullptr));
	...

	The nullptr is superfluous, the format string already indicates that there's
	only one method argument.

	OTOH, passing no method args does use a nullptr:
	...
	      gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render",
	                                               nullptr));
	...

	Furthermore, choosing the right format string chars can be tricky.

	Add a typesafe wrapper around PyObject_CallMethod that hides these
	details, such that we can use the more intuitive:
	...
	      gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll",
	                                             num_to_scroll));
	...
	and:
	...
	      gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render"));
	...

	Tested on x86_64-linux.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-12  Claudio Bantaloukas  <claudio.bantaloukas@arm.com>

	aarch64: add Branch Record Buffer extension instructions
	The FEAT_BRBE extension provides two aliases of sys:
	- brb iall (Invalidates all Branch records in the Branch Record Buffer)
	- brb inj (Injects the Branch Record held in BRBINFINJ_EL1,
	  BRBSRCINJ_EL1, and BRBTGTINJ_EL1 into the Branch Record Buffer)

	This patch adds:
	- the feature option "brbe" that must be added for the aliases to be available
	- a new operand flag AARCH64_OPND_Rt_IN_SYS_ALIASES that warns in a comment
	  when Rt is set to the non default value 0b11111 (it is constrained
	  unpredictable whether the instruction is undefined or behaves as if the Rt
	  field is set to 0b11111).
	- a new operand flag AARCH64_OPND_BRBOP that encodes and decodes Op2 values
	  from bit 5
	- support for the two brb aliases above

	See:
	- https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/BRB--Branch-Record-Buffer--an-alias-of-SYS-?lang=en
	- https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-INJ--Branch-Record-Injection-into-the-Branch-Record-Buffer?lang=en
	- https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-IALL--Invalidate-the-Branch-Record-Buffer?lang=en

2024-06-12  Hannes Domani  <ssbssa@yahoo.de>

	Allow calling of user-defined function call operators
	Currently it's not possible to call user-defined function call
	operators, at least not without specifying operator() directly:
	```
	(gdb) l 1
	1       struct S {
	2         int operator() (int x) { return x + 5; }
	3       };
	4
	5       int main () {
	6         S s;
	7
	8         return s(23);
	9       }
	(gdb) p s(10)
	Invalid data type for function to be called.
	(gdb) p s.operator()(10)
	$1 = 15
	```

	This now looks if an user-defined call operator is available when
	trying to 'call' a struct value, and calls it instead, making this
	possible:
	```
	(gdb) p s(10)
	$1 = 15
	```

	The change in operation::evaluate_funcall is to make sure the type
	fields are only used for function types, only they use them as the
	argument types.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-12  Alexandra Hájková  <ahajkova@redhat.com>

	Add "error_message+" feature to qSupported
	Add a new 'error_message' feature to the qSupported packet. When GDB
	supports this feature then gdbserver is able to send
	errors in the E.errtext format for the qRcmd and m packets.

	Update qRcmd packet and m packets documentation as qRcmd newly
	accepts errors in a E.errtext format.
	Previously these two packets didn't support E.errtext style errors.

	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-12  A. Wilcox  <awilfox@adelielinux.org>

	PR 31882 libctf: test suite incorrect format specifiers

2024-06-12  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Support S[sm]csrind extension csrs.
	This patch supports RISC-V Smcsrind/Sscsrind privilege extension csrs.
	Reuse csr 'smselect/siselect', 'mireg/sireg' and 'vsiselect,vsireg' csrs
	in Smaia/Ssaia extension.

	bfd/ChangeLog:

		* elfxx-riscv.c: New extensions.

	gas/ChangeLog:

		* NEWS: Updated.
		* config/tc-riscv.c (enum riscv_csr_class): New extensions.
		(riscv_csr_address): Ditto.
		* testsuite/gas/riscv/csr-version-1p10.d: New csrs.
		* testsuite/gas/riscv/csr-version-1p10.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p11.l: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.d: Ditto.
		* testsuite/gas/riscv/csr-version-1p12.l: Ditto.
		* testsuite/gas/riscv/csr.s: Ditto.
		* testsuite/gas/riscv/march-help.l: New extensions.

	include/ChangeLog:

		* opcode/riscv-opc.h (CSR_MIREG2): New csr.
		(CSR_MIREG3): Ditto.
		(CSR_MIREG4): Ditto.
		(CSR_MIREG5): Ditto.
		(CSR_MIREG6): Ditto.
		(CSR_SIREG2): Ditto.
		(CSR_SIREG3): Ditto.
		(CSR_SIREG4): Ditto.
		(CSR_SIREG5): Ditto.
		(CSR_SIREG6): Ditto.
		(CSR_VSIREG2): Ditto.
		(CSR_VSIREG3): Ditto.
		(CSR_VSIREG4): Ditto.
		(CSR_VSIREG5): Ditto.
		(CSR_VSIREG6): Ditto.
		(DECLARE_CSR): Ditto.

2024-06-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: convert separate-debug-file to new(ish) debug scheme
	Convert 'set/show debug separate-debug-file' to the new debug scheme.
	Though I'm not sure if we can really call it "new" any more!

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: warn of slow remote file reading only after a successful open
	While working on a later patch in this series, I noticed that GDB
	would print the message:

	  Reading /path/to/file from remote target...

	Even when /path/to/file doesn't exist on the remote target.

	GDB does indeed try to open /path/to/file, but I'm not sure we really
	need to tell the user unless we actually manage to open the file, and
	plan to read content from it.

	If we consider how GDB probes for separate debug files, we can attempt
	to open multiple possible files, most of them will not exist.  When we
	are native debugging we don't bother telling the user about each file
	we're checking for, we just announce any file we finally use.

	I think it makes sense to do a similar thing for remote files.

	So, in remote_target::remote_hostio_open(), I'd like to move the block
	of code that prints the above message to after the open call has been
	made, and we should only print the message if the open succeeds.

	Now GDB only tells the user about files that we actually open and read
	from the remote.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: avoid duplicate search in build_id_to_bfd_suffix
	In build_id_to_bfd_suffix we look in each debug-file-directory for a
	file matching the required build-id.

	If we don't find one then we add the sysroot and perform the search
	again.

	However, the default sysroot is 'target:', and for a native target
	this just means to search on the local machine.  So by default, if the
	debug information is not present, then we end up searching each
	location twice.

	I think we only need to perform the "with sysroot" check if either:

	 1. The sysroot is something other than 'target:'.  If the user has
	 set it to '/some/directory' then we should check this sysroot.  Or if
	 the user has set it to 'target:/some/other_directory', this is also
	 worth checking.

	 2. If the sysroot is 'target:', but the target's filesystem is not
	 local (i.e. the user is connected to a remote target), then we should
	 check using the sysroot as this will be looking on the remote
	 machine.

	There's no tests for this as the whole point here is that I'm removing
	duplicate work.  No test regressions were seen though.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/fileio: fix errno for packets where an attachment is expected
	In remote.c lives remote_target::remote_hostio_send_command(), which
	is used to handle sending a fileio packet to the remote, and for
	parsing the reply packet.

	Some commands, e.g. open, pwrite, close, send some arguments to the
	remote, and then get back a single integer return value.

	Other commands though, e.g. pread, readlink, fstat, send some
	arguments and get back an integer return value and some additional
	data.  This additional data is called the attachment.

	Except, we only get the attachment if the command completes
	successfully.  For example, calling readlink with a non existent path
	will result in a return packet: 'F-1,2' with no attachment.  This is
	as expected.

	Within remote_hostio_send_command we call remote_hostio_parse_result,
	this parses the status code (-1 in our example above) and
	then parses the errno value (2 in our example above).

	Back in remote_hostio_parse_result we then hit this block:

	  /* Make sure we saw an attachment if and only if we expected one.  */
	  if ((attachment_tmp == NULL && attachment != NULL)
	      || (attachment_tmp != NULL && attachment == NULL))
	    {
	      *remote_errno = FILEIO_EINVAL;
	      return -1;
	    }

	Which ensures that commands that expect an attachment, got an
	attachment.

	The problem is, we'll only get an attachment if the command
	succeeded.  If it didn't, then there is no attachment, and that is as
	expected.

	As remote_hostio_parse_result always sets the returned error number to
	FILEIO_SUCCESS unless the packet contained an actual error
	number (e.g. 2 in our example above), I suggest we should return early
	if remote_hostio_parse_result indicates an error packet.

	I ran into this issue while working on another patch.  In that patch I
	was checking the error code returned by a remote readlink call and
	spotted that when I passed an invalid path I got EINVAL instead of
	ENOENT.  This patch fixes this issue.

	Unfortunately the patch I was working on evolved, and my need to check
	the error code went away, and so, right now, I have no way to reveal
	this bug.  But I think this is an obviously correct fix, and worth
	merging even without a test.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix cast types for opencl
	The bitshift tests for opencl have these failures:

	print /x (signed char) 0x0f << 8
	No type named signed char.
	(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
	print (signed char) 0x0f << 8
	No type named signed char.
	(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8

	Apparently opencl doesn't have the 'signed' modifier for types, only
	the 'unsigned' modifier.
	Even 'char' is guaranteed to be signed if no modifier is used, so
	this changes the casts to match this logic.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix 64-bit shifts where long only has 32-bit size
	On systems where long has 32-bit size you get these failures:

	print 1 << (unsigned long long) 0xffffffffffffffff
	Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
	print 1 >> (unsigned long long) 0xffffffffffffffff
	Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
	print -1 << (unsigned long long) 0xffffffffffffffff
	Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
	print -1 >> (unsigned long long) 0xffffffffffffffff
	Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff

	Fixed by changing the number-of-bits variable to ULONGEST.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix too-large or negative right shift of negative numbers
	As seen in these test failures:

	print -1 >> -1
	warning: right shift count is negative
	$N = 0
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
	print -4 >> -2
	warning: right shift count is negative
	$N = 0
	(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2

	Fixed by restoring the logic from before the switch to gmp.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix right shift of negative numbers
	PR31590 shows that right shift of negative numbers doesn't work
	correctly since GDB 14:

	(gdb) p (-3) >> 1
	$1 = -1

	GDB 13 and earlier returned the correct value -2.
	And there actually is one test that shows the failure:

	print -1 >> 1
	$84 = 0
	(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1

	The problem was introduced with the change to gmp functions in
	commit 303a881f87.
	It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
	always rounds toward zero, and the gmp docu says this:

	For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
	bitwise right shifts.
	For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
	treating n as two's complement the same as the bitwise logical functions
	do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.

	So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
	does right shifts for both positive and negative numbers.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Hannes Domani  <ssbssa@yahoo.de>

	Restore bitshift.exp tests
	Commit cdd4206647 unintentionally disabled all tests of bitshift.exp,
	so it actually just does this:

	Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ...
	PASS: gdb.base/bitshift.exp: complete set language

			=== gdb Summary ===

	 # of expected passes		1

	It changed the 'continue' of unsupported languages to 'return', and
	since ada is the first language and is unsupported, no tests were run.

	This changes it back to 'continue', and the following patches fix
	the regressions that were introduced since then unnoticed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-11  Kilian Kilger  <kkilger@gmail.com>

	fix division by zero in target_read_string()
	Under certain circumstances, a floating point exception in
	target_read_string() can happen when the type has been obtained
	by a call to stpy_lazy_string_elt_type(). In the latter function,
	a call to check_typedef() has been forgotten. This makes
	type->length = 0 in this case.

2024-06-11  Tom Tromey  <tom@tromey.com>

	Remove useless call to wnoutrefresh
	This call to wnoutrefresh is not useful.  It's based on the
	misunderstanding that wnoutrefresh somehow prevents display, whereas
	actually what it does is copy from one curses buffer to another.

	I'm working on a larger patch to clean up this area, but this
	particular call can be removed immediately without consequence.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-11  Tom Tromey  <tom@tromey.com>

	Remove extract_long_unsigned_integer
	The function extract_long_unsigned_integer is unused, so remove it.
	Tested by rebuilding.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-11  Alan Modra  <amodra@gmail.com>

	support_dt_relr aarch64
	Tweak commit db335d7e0a so that support_dt_relr returns false for
	aarch64*-*-*ilp32.

2024-06-11  Ciaran Woodward  <ciaranwoodward@xmos.com>

	Fix printing strings on macOS Sonoma
	On macOS sonoma, printing a string would only print the first
	character. For instance, if there was a 'const char *s = "foobar"',
	then the 'print s' command would print '$1 = "f"' rather than the
	expected '$1 = "foobar"'.

	It seems that this is due to Apple silently replacing the version
	of libiconv they ship with the OS to one which silently fails to
	handle the 'outbytesleft' parameter correctly when using 'wchar_t'
	as a target encoding.

	This specifically causes issues when using iterating through a
	string as wchar_iterator does.

	This bug is visible even if you build for an old version of macOS,
	but then run on Sonoma. Therefore this fix in the code applies
	generally to macOS, and not specific to building on Sonoma. Building
	for an older version and expecting forwards compatibility is a
	common situation on macOS.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853

2024-06-11  David Guillen Fandos  <david@davidgf.net>

	MIPS/opcodes: Add MIPS Allegrex DBREAK instruction
	This complements the debug instruction set and uses the same encoding as
	the VR5400/VR5500 devices.

	MIPS/opcodes: Exclude trap instructions for MIPS Allegrex
	These instructions are not supported by the target even though they are
	part of the MIPS II specification.

2024-06-11  Alan Modra  <amodra@gmail.com>

	PR31872, Segfault in objdump (elf_slurp_reloc_table_from_section)
	This one was triggered by trying to dump an AMDGPU object.
	elf64-amdgcn.c lacks support for objdump relocation handling.

		PR 31872
		* elfcode.h (elf_slurp_reloc_table_from_section): Don't segfault
		on NULL elf_info_to_howto_rel.

2024-06-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-10  Ilya Leoshkevich  <iii@linux.ibm.com>

	IBM zSystems: Rewrite l(g)rl @GOTENT to larl for --no-pie
	Regtested on s390x-redhat-linux.

	Rewriting l(g)rl @GOTENT to larl is unnecessarily guarded by
	bfd_link_pic().  There were no use cases for this in the past, but
	since recently the Linux Kernel on s390x is compiled with -fPIE
	and linked with --no-pie.  Remove the unnecessary bfd_link_pic()
	check.

	bfd/ChangeLog:

	        * elf32-s390.c (elf_s390_relocate_section): Don't check for
		bfd_link_pic() when rewriting lrl@GOTENT to larl.
		(elf_s390_finish_dynamic_symbol): Emit a relative reloc for
		the above case.
	        * elf64-s390.c (elf_s390_relocate_section): Don't check for
		bfd_link_pic() when rewriting lgrl@GOTENT to larl.
		(elf_s390_finish_dynamic_symbol): Emit a relative reloc for
		the above case.

	ld/ChangeLog:

	* testsuite/ld-s390/s390.exp: Hook up the new tests.
	        * testsuite/ld-s390/gotreloc_31-no-pie-1.dd: New test.
	        * testsuite/ld-s390/gotreloc_64-no-pie-1.dd: New test.

2024-06-10  Tom Tromey  <tromey@adacore.com>

	Make global_symbol_searcher::filenames private
	This patch renames global_symbol_searcher::filenames and makes it
	private, adding a new method to append a filename to the vector.  This
	also cleans up memory management here, removing an alloca from rbreak,
	and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor
	of having global_symbol_searcher manage the memory itself.

	Regression tested on x86-64 Fedora 38.

2024-06-10  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long long
	If in gdb/python/python-internal.h, we pretend to have a platform that doesn't
	support long long:
	...
	-#ifdef HAVE_LONG_LONG
	+#if 0
	...
	I get on arm-linux:
	...
	(gdb) placement_candidate()
	disassemble test^M
	Dump of assembler code for function test:^M
	   0x004004d8 <+0>:     push    {r11}           @ (str r11, [sp, #-4]!)^M
	   0x004004dc <+4>:     Python Exception <class 'ValueError'>: \
	     Buffer returned from read_memory is sized 0 instead of the expected 4^M
	^M
	unknown disassembler error (error = -1)^M
	(gdb) FAIL: $exp: memory source api: second disassembler pass
	...

	The problem is that gdb_py_longest is typedef-ed to long, but the
	corresponding format character GDB_PY_LL_ARG is defined to "L", meaning
	"long long" [1].

	Fix this by using "l", meaning long instead.  Likewise for GDB_PY_LLU_ARG.

	Tested on arm-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/31845
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845

	[1] https://docs.python.org/3/c-api/arg.html

2024-06-10  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix gdb.python/py-disasm.exp on arm-linux
	After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
	...
		nop	{0}
	...
	we run into:
	...
	disassemble test^M
	Dump of assembler code for function test:^M
	   0x004004d8 <+0>:     push    {r11}           @ (str r11, [sp, #-4]!)^M
	   0x004004dc <+4>:     add     r11, sp, #0^M
	   0x004004e0 <+8>:     nop     {0}^M
	=> 0x004004e4 <+12>:    Python Exception <class 'ValueError'>: Buffer \
	  returned from read_memory is sized 0 instead of the expected 4^M
	^M
	unknown disassembler error (error = -1)^M
	(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
	...

	This is caused by this code in gdbpy_disassembler::read_memory_func:
	...
	  gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
	                                              "read_memory",
	                                              "KL", len, offset));
	...
	where len has type "unsigned int", while "K" means "unsigned long long" [1].

	Fix this by using "I" instead, meaning "unsigned int".

	Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
	"long long".

	Fix this by using type gdb_py_longest for offset, in combination with format
	character "GDB_PY_LL_ARG".  Likewise in disasmpy_info_read_memory.

	Tested on arm-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR python/31845
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845

	[1] https://docs.python.org/3/c-api/arg.html

2024-06-10  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: warn on unpredictable results for new rcpc3 instructions
	The previous patch for the feature rcpc3 introduced 4 new operations
	(ldiapp, stilp, ldapr, stlr).
	The specification mentions some cases of inputs causing unpredictable
	results. gas currently fails to diagnose them, and does not emit
	warnings. Even if the instruction encoding is valid, the developer
	probably wants to know for those cases that the instruction won't have
	the expected effect.
	- ldiapp & stilp:
	  * unpredictable load pair transfer with register overlap
	  * unpredictable transfer with writeback
	- ldapr & stlr:
	  * unpredictable transfer with writeback

	This patch also completes the existing relevant tests.

2024-06-10  Maciej W. Rozycki  <macro@orcam.me.uk>

	Revert "MIPS/Allegrex: Exclude trap instructions"
	This reverts commit a2e71b281a9365872451a157767e03a2e89ddaad.

	Revert "MIPS/Allegrex: Enable dbreak instruction"
	This reverts commit c41020942b94ea7c5a58de4fed644826e8f0b509.

2024-06-10  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Note that python 3.6 assumes long long support
	Starting with python 3.6, support for platforms without long long support
	has been removed [1].

	HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility,
	so stop relying on them.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://github.com/python/cpython/issues/72148

2024-06-10  Alan Modra  <amodra@gmail.com>

	PR31873, buffer overflow in evax_bfd_print_dst
		PR 31873
		* vms-alpha.c (evax_bfd_print_dst): Sanity check len against
		dst_size.

2024-06-10  Rostislav Krasny  <rostiprodev@gmail.com>

	src-release.sh: don't take untracked files into account in  the uncommitted changes check

2024-06-10  David Guillen Fandos  <david@davidgf.net>

	MIPS/Allegrex: Enable dbreak instruction

	MIPS/Allegrex: Exclude trap instructions
	These instructions are not supported by the target even though they are
	part of the MIPS II specification.

2024-06-10  Jan Beulich  <jbeulich@suse.com>

	x86/APX: convert ZU to operand constraint
	Extremely rarely used attributes are inefficient when represented by a
	separate attribute. Convert it to an operand constraint, as already
	suggested during review. The collision with RegKludge is pretty simple
	to resolve.

2024-06-10  Jan Beulich  <jbeulich@suse.com>

	x86: disassembler macro for condition code
	Both CMPccXADD and APX'es {,CF}CMOVcc have almost identical entries
	replicated 16 times each. Fold those to just one each by introducing a
	%CC macro. (Note that the recording of ->condition_code in print_insn()
	is merely for completeness for now; it's not used as long as only
	VEX/EVEX encodings would consume it.)

	This then also renders condition codes printed consistent across all
	respective insns; CMPxxXADD had a number of outliers so far.

2024-06-10  Jan Beulich  <jbeulich@suse.com>

	x86/APX: support extended SETcc form
	As indicated during review, spelling/readability-wise

		setz	%eax

	is easier than

		setzuz	%al

	_and_ properly specifies the full register that's being modified. Permit
	that form to be used, even if the spec writers are unwilling to formally
	mention it.

	While there also correct the non-ZU EVEX form: That ought to also permit
	memory operands.

2024-06-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: re-add necessary includes in tui/tui-win.c
	Commit 9102a6c15c75 ("gdb/tui: cleanup includes") broke
	gdb.python/tui-window.exp on Linux:

	    Running /data/vries/gdb/src/gdb/testsuite/gdb.python/tui-window.exp ...
	    WARNING: timeout in accept_gdb_output
	    WARNING: timeout in accept_gdb_output
	    FAIL: gdb.python/tui-window.exp: Window was updated

	and caused a build failure on AIX:

	    CXX    tui/tui-win.o
	    tui/tui-win.c: In function 'void tui_sigwinch_handler(int)':
	    tui/tui-win.c:532:3: error: 'mark_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'?
	      532 |   mark_async_signal_handler (tui_sigwinch_token);
	          |   ^~~~~~~~~~~~~~~~~~~~~~~~~
	          |   async_signal_handler
	    tui/tui-win.c: At global scope:
	    tui/tui-win.c:538:1: error: variable or field 'tui_async_resize_screen' declared void
	      538 | tui_async_resize_screen (gdb_client_data arg)
	          | ^~~~~~~~~~~~~~~~~~~~~~~
	    tui/tui-win.c:538:26: error: 'gdb_client_data' was not declared in this scope
	      538 | tui_async_resize_screen (gdb_client_data arg)
	          |                          ^~~~~~~~~~~~~~~
	    tui/tui-win.c: In function 'void tui_initialize_win()':
	    tui/tui-win.c:579:36: error: 'tui_async_resize_screen' was not declared in this scope
	      579 |     = create_async_signal_handler (tui_async_resize_screen, NULL,
	          |                                    ^~~~~~~~~~~~~~~~~~~~~~~
	    tui/tui-win.c:579:7: error: 'create_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'?
	      579 |     = create_async_signal_handler (tui_async_resize_screen, NULL,
	          |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
	          |       async_signal_handler
	    gmake: *** [Makefile:1947: tui/tui-win.o] Error 1

	On Linux, the removal of the signal.h include causes the `#ifdef
	SIGWINCH` sections to become inactive.  The code builds, but then the
	TUI fails to react to terminal size changes.  When we add back the
	inclusion of signal.h, then we see the same build error as on AIX.

	On AIX, I suppose that the SIGWINCH define is still seen by some other
	transitive include.

	When I go back to before 9102a6c15c75, I don't see async-event.h and
	signal.h being marked as unneeded by clangd, so I'm not sure why I
	removed them in the first place... I'll be more careful in the future
	(files with #ifdef/#ifndef can be tricky w.r.t. determining necessary
	includes).

	So, re-add the inclusion of signal.h and async-event.h

	Change-Id: I3ed385c2dc1726ade2118a5186ea7cccffd12635
	Reported-By: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
	Reported-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865

2024-06-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't use set auto-solib-add off
	In test-case gdb.mi/mi-var-child-f.exp, we have:
	...
	mi_gdb_test "-gdb-set auto-solib-add off" "\\^done"
	mi_runto prog_array
	mi_gdb_test "nosharedlibrary" ".*\\^done"
	...

	This was added to avoid a name clash between the array variable as defined in
	gdb.mi/array.f90 and debug info in shared libraries, and used in other places
	in the testsuite.

	The same workaround is also used to ignore symbols from shared libraries when
	excercising for instance a command that prints all symbols.

	However, this approach can cause problems for targets like arm that require
	symbol info for some libraries like ld.so and libc to fully function.

	While absense of debug info for shared libraries should be handled gracefully
	(which does need fixing, see PR31817), failure to do so should not result
	in failures in unrelated test-cases.

	Fix this by removing "set auto-solib-add off".

	This ensures that we don't run into PR31817, while the presence of
	nosharedlibrary still ensures that in the rest of the test-case we're not
	bothered by shared library symbols.

	Likewise in other test-cases.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	Tested on arm-linux.

2024-06-10  Jan Beulich  <jbeulich@suse.com>

	gas: extend \+ support to .rept
	PR gas/31752

	While not quite as macro-like as .irp / .irpc, this perhaps benefits from
	supporting \+ even more than those: It allows, where desired, to get away
	without maintaining an explicit count variable in source code.

	Keep .rep (and custom per-arch uses of s_rept() / do_repeat()) behavior
	unaltered.

2024-06-10  Jan Beulich  <jbeulich@suse.com>

	x86/APX: add missing CPU requirement to imm+rm forms of <alu2> insns
	This was overlooked when the form was added by dd74a603376e ("Support
	APX NF").

2024-06-10  Clément Chigot  <chigot@adacore.com>

	ld-aarch64: check support before launching dt_relr tests
	Not all aarch64 targets supports dt_relr as this requires some
	mechanisms on the OS side.

	Adjust support_dt_relr helper and use it in aarch64-elf.exp.

2024-06-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-09  Alan Modra  <amodra@gmail.com>

	regen sim/frv files for copyright update

2024-06-09  Matthieu Longo  <matthieu.longo@arm.com>

	autoupdate: regen after replacing obsolete macros

2024-06-09  Matthieu Longo  <matthieu.longo@arm.com>

	autoconf: delete obsolete unused m4 file
	config/uintmax_t.m4 contains only one function: jm_AC_TYPE_UINTMAX_T.
	After a grep, I could not find any usage of it.

	jm_AC_TYPE_UINTMAX_T seems to be an old implementation of the officially
	suppported AC_TYPE_UINTMAX_T.
	Doc: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/
	     autoconf-2.72/autoconf.html#index-AC_005fTYPE_005fUINTMAX_005fT-1

	config/stdint.m4 seems to have taken over. The usage of
	AC_REQUIRE([AC_TYPE_UINTMAX_T]) is not garded or inside a function, so it
	will also automatically be run for the configure.ac files using
	AC_CONFIG_MACRO_DIRS([../config]) instead of m4_include([../config/stdint.m4]).

	It seems that people replaced jm_AC_TYPE_UINTMAX_T occurences by
	AC_TYPE_UINTMAX_T, and forgot to delete uintmax_t.m4.
	Deleting the file and regenerating the build scripts results in no diff,
	so it looks safe to delete it from the repository.

2024-06-09  Matthieu Longo  <matthieu.longo@arm.com>

	autoupdate: add square brackets around arguments of AC_INIT
	https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2

	autoupdate: add square brackets around argument of AC_PREREQ
	https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fPREREQ-1

	autoupdate: replace old version of AC_INIT by the new one
	- old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3

	autoupdate: replace obsolete macros AC_CONFIG_HEADER
	- AC_CONFIG_HEADER by AC_CONFIG_HEADERS
	  https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER

	autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM
	- AC_CANONICAL_SYSTEM by:
	    * AC_CANONICAL_HOST where host, and host_alias are needed
	    * AC_CANONICAL_TARGET where target_alias is needed
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1

	autoupdate: replace obsolete macros AC_PROG_LIBTOOL
	- AC_PROG_LIBTOOL by LT_INIT
	  https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#index-LT_005fINIT

	autoupdate: replace obsolete macros AC_AIX, AC_MINIX, and AC_GNU_SOURCE
	- AC_AIX, AC_MINIX, and AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fAIX
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fMINIX-1
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fGNU_005fSOURCE-1

	autoupdate: replace obsolete macros AC_HELP_STRING
	- AC_HELP_STRING by AS_HELP_STRING
	  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fHELP_005fSTRING-1
	Except for the ifdef in lib-prefix.m4, make the defun of AC_LIB_ARG_WITH
	unconditional.

2024-06-09  H.J. Lu  <hjl.tools@gmail.com>

	gold: Properly remove the versioned symbol
	When the versioned symbol foo is removed from the shared library,  the
	".symver foo,foo@VER" directive provides binary compatibility for foo@VER.
	In this case, the unversioned symbol foo should be hidden and shouldn't
	generate a multiple definition error.

		PR gold/31830
		* resolve.cc (Symbol_table::resolve): Move symbol version handling
		to ...
		* symtab.cc (Symbol_table::add_from_object): Here. If the hidden
		version from .symver is the same as the default version from the
		unversioned symbol, don't make the unversioned symbol the default
		versioned
		symbol.
		* testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr31830.sh.
		(check_DATA): ver_test_pr31830_a.syms and ver_test_pr31830_b.syms.
		(ver_test_pr31830_a.syms): New.
		(ver_test_pr31830_b.syms): Likewise.
		(ver_test_pr31830_a.so): Likewise.
		(ver_test_pr31830_b.so): Likewise.
		* testsuite/Makefile.in: Regenerated.
		* testsuite/ver_test_pr31830.script: New file.
		* testsuite/ver_test_pr31830.sh: Likewise.
		* testsuite/ver_test_pr31830_a.c: Likewise.
		* testsuite/ver_test_pr31830_b.c: Likewise.
		* testsuite/ver_test_pr31830_lto.c: Likewise.
		* testsuite/ver_test_pr31830_lto.sh: Likewise.

2024-06-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-08  Tom Tromey  <tom@tromey.com>

	Fix typo in warning in gdb/configure
	Eli pointed out that "babeltrace" is misspelled in a warning in
	gdb/configure.  This patch fixes the typo.

2024-06-08  Eli Zaretskii  <eliz@gnu.org>

	gdb: Avoid compilation warning in gcore.c.
	See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html
	for the details.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove get_exec_file
	I believe that the get_exec_file function is unnecessary, and the code
	can be simplified if we remove it.

	Consider for instance when you "run" a program on Linux with native
	debugging.

	 1. run_command_1 obtains the executable file from
	    `current_program_space->exec_filename ()`
	 2. it passes it to `run_target->create_inferior()`, which is
	    `inf_ptrace_target::create_inferior()` in this case, which then
	    passes it to `fork_inferior()`
	 3. `fork_inferior()` then has a fallback, where if the passed exec file
	    is nullptr, it gets its from `get_exec_file()`.
	 4. `get_exec_file()` returns `current_program_space->exec_filename ()`
	    - just like the things we started with - or errors out if the
	    current program space doesn't have a specified executable.

	If there's no exec filename passed in step 1, there's not going to be
	any in step 4, so it seems pointless to call `get_exec_file()`, we could
	just error out when `exec_file` is nullptr.  But we can't error out
	directly in `fork_inferior()`, since the error is GDB-specific, and that
	function is shared with GDBserver.

	Speaking of GDBserver, all code paths that lead to `fork_inferior()`
	provide a non-nullptr exec file.

	Therefore, to simplify things:

	 - Make `fork_inferior()` assume that the passed exec file is not
	   nullptr, don't call `get_exec_file()`
	 - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace,
	   nto-procfs, procfs) to error out when the exec file passed to their
	   create_inferior method is nullptr.  Some targets are fine with a
	   nullptr exec file, so we can't check that in `run_command_1()`.
	 - Add the `no_executable_specified_error()` function, which re-uses the
	   error message that `get_exec_file()` had.
	 - Change some targets (go32-nat, nto-procfs) to not call
	   `get_exec_file()`, since it's pointless for the same reason as in the
	   example above, if it returns, it's going the be the same value as the
	   `exec_file` parameter.  Just rely on `exec_file`.
	 - Remove the final use of `get_exec_file()`, in `load_command()`.
	 - Remove the `get_exec_file()` implementations in GDB and GDBserver and
	   remove the shared declaration.

	Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove dead code in nto-procfs.c
	`get_exec_file()` never returns nullptr, so remove some dead code that
	check for a nullptr return.

	Change-Id: I9eff2a013d602588aaf4477a22cf45f2bc417c6a
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: replace `get_exec_file (0)` calls with `current_program_space->exec_filename ()`
	Calls of `get_exec_file (0)` are equivalent to just getting the exec
	filename from the current program space.  I'm looking to remove
	`get_exec_file`, so replace these uses with
	`current_program_space->exec_filename ()`.

	Remove the `err` parameter of `get_exec_wrapper` since all the calls
	that remain pass 1, meaning to error out if no executable is specified.

	Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make progspace::exec_filename private, add getter / setter
	Just like the title says... I think this makes things a bit clearer, for
	instance where the exec filename is set.  It also makes the read call
	sites a bit nicer, avoiding the `.get ()`.

	Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/tui: cleanup includes
	Remove includes reported as unused by clangd.  Then, add any includes
	necessary to get rid of errors (includes possibly relying on previous
	includes)..

	I didn't remove the includes of gdb-safe-ctypes.h, because it appears to
	do some some preprocessor magic, redefining standard macros.  I'm afraid
	that removing these includes could change the behavior unintentionally.

	Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add IWYU export pragams to gdb_curses.h
	It seems like gdb_curses.h is included whenever we want to access
	ncurses functionality, instead of including directly ncurses.h.  As a
	result, clangd often erroneously shows that gdb_curses.h inclusions are
	unused.

	By adding those pragmas, clangd (and the include-what-you-use tool)
	understands that gdb_curses.h is a valid provider for whatever these
	ncurses.h files provide.

	Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb/tui: change some macros to functions
	Change the `TUI_*` macros to access known windows to functions.  Define
	them in their respective files, because trying to define them in
	tui-data.h would end up causing include cycles.

	This makes static analysis (detection of unused include files in this
	case) more accurate, and I think in general we should avoid hiding
	code behind macros if not necessary.

	Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-07  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp
	Test behaviour of watchpoints triggered by MOPS instructions.  This test
	is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
	instructions rather than whatever instructions are used in the libc's
	implementation of memset/memcpy/memmove.

	There's a separate watched variable for each set of instructions so that
	the testcase can test whether GDB correctly identified the watchpoint
	that triggered in each case.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-06-07  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/aarch64: Add record support for MOPS instructions.
	There are two kinds of MOPS instructions: set instructions and copy
	instructions.  Within each group there are variants with minor
	differences in how they read or write to memory — e.g., non-temporal
	read and/or write, unprivileged read and/or write and permutations of
	those — but they work in the same way in terms of the registers and
	regions of memory that they modify.

	The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
	instructions are recorded and correctly reversed.  Not all variants of the
	copy and set instructions are tested, since there are many and the record
	and replay target processes them in the same way.

	PR tdep/31666
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-06-07  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/aarch64: Disable displaced single-step for MOPS instructions
	The AArch64 MOPS (Memory Operation) instructions provide a standardised
	instruction sequence to perform a memset, memcpy or memmove.  A sequence is
	always composed of three instructions: a prologue instruction, a main
	instruction and an epilogue instruction.  As an illustration, here are the
	implementations of these memory operations in glibc 2.39:

	  (gdb) disassemble/r
	  Dump of assembler code for function __memset_mops:
	  => 0x0000fffff7e8d780 <+0>:     d503201f        nop
	     0x0000fffff7e8d784 <+4>:     aa0003e3        mov     x3, x0
	     0x0000fffff7e8d788 <+8>:     19c10443        setp    [x3]!, x2!, x1
	     0x0000fffff7e8d78c <+12>:    19c14443        setm    [x3]!, x2!, x1
	     0x0000fffff7e8d790 <+16>:    19c18443        sete    [x3]!, x2!, x1
	     0x0000fffff7e8d794 <+20>:    d65f03c0        ret
	  End of assembler dump.

	  (gdb) disassemble/r
	  Dump of assembler code for function __memcpy_mops:
	  => 0x0000fffff7e8c580 <+0>:     d503201f        nop
	     0x0000fffff7e8c584 <+4>:     aa0003e3        mov     x3, x0
	     0x0000fffff7e8c588 <+8>:     19010443        cpyfp   [x3]!, [x1]!, x2!
	     0x0000fffff7e8c58c <+12>:    19410443        cpyfm   [x3]!, [x1]!, x2!
	     0x0000fffff7e8c590 <+16>:    19810443        cpyfe   [x3]!, [x1]!, x2!
	     0x0000fffff7e8c594 <+20>:    d65f03c0        ret
	  End of assembler dump.

	  (gdb) disassemble/r
	  Dump of assembler code for function __memmove_mops:
	  => 0x0000fffff7e8d180 <+0>:     d503201f        nop
	     0x0000fffff7e8d184 <+4>:     aa0003e3        mov     x3, x0
	     0x0000fffff7e8d188 <+8>:     1d010443        cpyp    [x3]!, [x1]!, x2!
	     0x0000fffff7e8d18c <+12>:    1d410443        cpym    [x3]!, [x1]!, x2!
	     0x0000fffff7e8d190 <+16>:    1d810443        cpye    [x3]!, [x1]!, x2!
	     0x0000fffff7e8d194 <+20>:    d65f03c0        ret
	  End of assembler dump.

	The Arm Architecture Reference Manual says that "the prologue, main, and
	epilogue instructions are expected to be run in succession and to appear
	consecutively in memory".  Therefore this patch disables displaced stepping
	on them.

	The testcase verifies that MOPS sequences are correctly single-stepped.

	PR tdep/31666
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI
	In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1
	since glibc 2.20.

	See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and
	setjmp.").

	Update it, allowing us to run into the gdb/26967 kfail.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

	PR arm/tdep
	Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089

2024-06-07  Alan Modra  <amodra@gmail.com>

	Re: Yet another ecoff fuzzed object fix
	In commit 6fc018e9e593 I replaced the fdr_ptr csym check against the
	header isymMax count with a check against bfd symcount.  In fact, both
	checks are needed.  The isymMax check sanity checks accesses against
	the external sym array, the symcount one against the internal array.

		* ecoff.c (_bfd_ecoff_slurp_symbol_table): Reinstate fdr_ptr
		csym check against isymMax.

2024-06-07  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Test DT_RELR with discarded sections

2024-06-07  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Fix DT_RELR support with discarded sections
	In case of discarded sections, via /DISCARD/ or .gnu.linkonce,
	relr relocation accounting was wrong.  This broke building linux.

	The issue was that the *_relocate_section logic was copied to
	record_relr_non_got_relocs to find the relative relocs that can
	be packed, however *_relocate_section is not called on sections
	that are discarded, while record_relr_non_got_relocs is called
	for all input sections. The fix is to filter out the discarded
	sections with the same logic that is used to count non-GOT
	relocs in *_late_size_sections for local symbols earlier.
	Use the discarded_section helper in both cases to clarify the
	intent and handle all corner-cases consistently.

	GOT relocations are affected too if all sections are discarded
	that reference the GOT entry of a particular symbol, however
	this can cause unused GOT entries independently of DT_RELR, and
	the only difference with DT_RELR is that a relative reloc may be
	emitted instead of a R_AARCH64_NONE for the unused GOT entry
	which is acceptable. A proper fix would require redoing the GOT
	refcounting after we know the discarded sections, see bug 31850.

2024-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.fortran/array-bounds.exp on arm
	When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into:
	...
	(gdb) print &foo^M
	$1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M
	(gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo
	print &bar^M
	$2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M
	(gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar
	...

	This is due to gcc PR debug/54934.

	The test-case contains a kfail for this, which is only activated for
	x86_64/i386.

	Fix this by enabling the kfail for all ilp32 targets.

	Also:
	- change the kfail into an xfail, because gdb is not at fault here, and
	- limit the xfail to the gfortran compiler.

	Tested on arm-linux.

2024-06-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: use POD2MAN5 when appropriate
	In commit:

	  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
	  Date:   Fri Apr 12 17:47:20 2024 +0100

	      gdb/doc: use silent-rules.mk in the Makefile

	I rewrote the rules for building the man pages.  While doing this I
	accidentally switched from using MAN2POD5 to MAN2POD1 for generating
	the file gdbinit.5.

	Restore use of MAN2POD5 where appropriate.

2024-06-06  Johan Sternerup  <johan.sternerup@gmail.com>

	DAP: Handle "stepOut" request in outermost frame
	Previously a "stepOut" request when in the outermost frame would result
	in a sucessful response even though gdb internally would reject the
	associated "finish" request, which means no stoppedEvent would ever be
	sent back to the client. Thus the client would believe the inferior was
	still running and as a consequence reject subsequent "next" and "stepIn"
	requests from the user.

	The solution is to execute the underlying finish command as a background
	command, i.e. `finish &`. If we're in the outermost frame an exception
	will be raised immediately, which we can now capture and report back to
	the client as success=False so then the absence of a `stopped` event is
	no longer a problem.

	We also make use of the `defer_stop_event` option to prevent a stop
	event from reaching the client until the response has been sent.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-06  Johan Sternerup  <johan.sternerup@gmail.com>

	DAP: Allow gdb exception in exec_and_log to propagate
	This allows a request to specify that any gdb exception raised in
	exec_and_log within the gdb thread to be propagated back to the DAP
	thread (using the Canceller object as the orchestrator).

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-06  Johan Sternerup  <johan.sternerup@gmail.com>

	DAP: Allow for deferring stop events from gdb thread
	The existing `send_event_later()` method allows commands processed on
	the DAP thread to queue an event for execution until after the response
	has been sent to the client.

	We now introduce a corresponding method for use by the gdb thread. This
	method `send_event_maybe_later()` will queue the event just like
	`send_event_later()`, but only if it has been configured to do so by a
	new @request option `defer_stop_events`. As the name implies the
	functionality is currently only used for handling stop events.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-06  Richard Earnshaw  <rearnsha@arm.com>

	arm: fix testsuite fallout on arm-elf and arm-nto from FPA removal
	Removing FPA means that in some cases we default to 'no-fpu' in the
	assembler when previously we would have picked FPA-format floating
	numbers.  This patch fixes the testsuite fallout on a couple of
	targets that are affected by this change.  Where possible we do this
	by adding an option to set the floating-point format, but for bad-bss
	we just skip the test.

2024-06-06  Nick Clifton  <nickc@redhat.com>

	Updated Spanish translation for the bfd/ directory

2024-06-06  Andrew Burgess  <aburgess@redhat.com>

	opcodes/riscv: prevent future use of disassemble_info::fprintf_func
	The previous commit removed a use of disassemble_info::fprintf_func
	which had been added to the RISC-V disassembler after the disassembler
	had been switched to use ::fprintf_styled_func, for styled output.

	To prevent future mistakes, I propose adding a #define to rename
	fprintf_func to something which does not exist.  If this had been in
	place then the before the previous commit libopcodes would have failed
	to compile, like this:

	  ../../src/opcodes/riscv-dis.c: In function ‘print_reg_list’:
	  ../../src/opcodes/riscv-dis.c:229:7: error: ‘disassemble_info’ {aka ‘struct disassemble_info’} has no member named ‘please_use_fprintf_styled_func_instead’
	    229 |   info->fprintf_func (info->stream, "%s", riscv_gpr_names[X_RA]);
	        |       ^~

	If this commit is accepted then I'll follow up with another commit
	that adds the same #define to every disassembler that has been
	converted to use styled output.

	As the RISC-V disassembler is now fully styled, this commit should
	make no difference at all.

2024-06-06  Andrew Burgess  <aburgess@redhat.com>

	opcodes/riscv: add styling support to print_reg_list
	I noticed that some unstyled output had crept into the risc-v
	disassembler in this commit:

	  commit 9132c8152b899a1683bc886f8ba76bedadb48aa1
	  Date:   Tue Feb 27 11:48:11 2024 +0800

	      RISC-V: Support Zcmp push/pop instructions.

	this commit adds styling support.  The risc-v disassembler is now once
	again, fully styled.

2024-06-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Add support for Zvfbfwma extension
	This implements the Zvfbfwma extension, as of version 1.0.
	View detailed information in:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zvfbfwma---vector-bf16-widening-mul-add>

	1 In spec: "Zvfbfwma requires the Zvfbfmin extension and the Zfbfmin extension."
	  1.1 In Embedded    Processor: Zvfbfwma -> Zvfbfmin -> Zve32f
	  1.2 In Application Processor: Zvfbfwma -> Zvfbfmin -> V
	  1.3 In both scenarios, there are: Zvfbfwma -> Zfbfmin

	2 Depending on different usage scenarios, the Zvfbfwma extension may
	depend on 'V' or 'Zve32f'. This patch only implements dependencies in
	scenario of Embedded Processor. This is consistent with the processing
	strategy in Zvfbfmin. In scenario of Application Processor, it is
	necessary to explicitly indicate the dependent 'V' extension.

	For relevant information in gcc, please refer to:
	<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=38dd4e26e07c6be7cf4d169141ee4f3a03f3a09d>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfwma.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.
		* testsuite/gas/riscv/zvfbfwma.d: New test.
		* testsuite/gas/riscv/zvfbfwma.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VFWMACCBF16_VF): Define.
		(MASK_VFWMACCBF16_VF): Ditto.
		(MATCH_VFWMACCBF16_VV): Ditto.
		(MASK_VFWMACCBF16_VV): Ditto.
		(DECLARE_INSN): New declarations for Zvfbfwma.
		* opcode/riscv.h (enum riscv_insn_class): Add
		INSN_CLASS_ZVFBFWMA

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvfbfwma instructions.

2024-06-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Add support for Zvfbfmin extension
	This implements the Zvfbfmin extension, as of version 1.0.
	View detailed information in:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zvfbfmin---vector-bf16-converts>

	Depending on different usage scenarios, the Zvfbfmin extension may
	depend on 'V' or 'Zve32f'. This patch only implements dependencies
	in scenario of Embedded Processor. In scenario of Application
	Processor, it is necessary to explicitly indicate the dependent
	'V' extension.

	For relevant information in gcc, please refer to:
	<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ddf65c5fc6ba7cf5826e1c02c569c923a541c09>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfmin.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.
		* testsuite/gas/riscv/zvfbfmin.d: New test.
		* testsuite/gas/riscv/zvfbfmin.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VFNCVTBF16_F_F_W): Define.
		(MASK_VFNCVTBF16_F_F_W): Ditto.
		(MATCH_VFWCVTBF16_F_F_V): Ditto.
		(MASK_VFWCVTBF16_F_F_V): Ditto.
		(DECLARE_INSN): New declarations for Zvfbfmin.
		* opcode/riscv.h (enum riscv_insn_class): Add
		INSN_CLASS_ZVFBFMIN

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvfbfmin instructions.

2024-06-06  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Add support for Zfbfmin extension
	This implements the Zfbfmin extension, as of version 1.0.

	View detailed information in:
	<https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zfbfmin---scalar-bf16-converts>

	1 The Zfbfmin extension depend on 'F', and the FLH, FSH, FMV.X.H, and
	  FMV.H.X instructions as defined in the Zfh extension.

	2 The Zfhmin extension includes the following instructions from the Zfh
	  extension: FLH, FSH, FMV.X.H, FMV.H.X... View detailed information in:
	  <https://github.com/riscv/riscv-isa-manual/blob/main/src/zfh.adoc>

	3 Zfhmin extension depend on 'F'.

	4 Simply put, just make Zfbfmin dependent on Zfhmin.

	Perhaps in the future, we could propose making the FLH, FSH, FMV.X.H, and
	FMV.H.X instructions an independent extension to achieve precise dependency
	relationships for the Zfbfmin.

	5 For relevant information in gcc, please refer to:
	  <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=35224ead63732a3550ba4b1332c06e9dc7999c31>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zfbfmin.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
		* testsuite/gas/riscv/march-help.l: Ditto.
		* testsuite/gas/riscv/zfbfmin.d: New test.
		* testsuite/gas/riscv/zfbfmin.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_FCVT_BF16_S): Define.
		(MASK_FCVT_BF16_S): Ditto.
		(MATCH_FCVT_S_BF16): Ditto.
		(MASK_FCVT_S_BF16): Ditto.
		(DECLARE_INSN): New declarations for Zfbfmin.
		* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZFBFMIN.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zfbfmin instructions.

2024-06-06  Alan Modra  <amodra@gmail.com>

	Re: aarch64: Add some DT_RELR ld tests
	aarch64-elf fails these tests due to .rela.dyn being at a different
	address to that expected, and due to the symbol table being different.
	Unexpected symbol numbering results in a mismatch of reloc r_info
	field, but these are shown decoded so the raw field doesn't really add
	anything to the test.

		* testsuite/ld-aarch64/relr-align.d: Accept any address for
		.relr.dyn section.  Don't match raw r_info field.
		* testsuite/ld-aarch64/relr-data-shared.d: Likewise.
		* testsuite/ld-aarch64/relr-got-shared.d: Likewise.
		* testsuite/ld-aarch64/relr-text-shared.d: Likewise.

2024-06-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-05  Richard Earnshaw  <rearnsha@arm.com>

	NEWS: arm: note that FPA support has been removed

	arm: minor documentation cleanup given removal of FPA
	The use in the documentation of .save for an FPA instruction is no-longer
	relevant, so remove it.

	arm: remove disassembly support for the FPA co-processor
	Remove the FPA support from the disassembler.  This entails a couple
	of testsuite fixes where we were (probably incorrectly) disassembling
	a generic co-processor instruction using the legacy FPA opcodes.

	arm: remove FPA instructions from assembler
	These can no-longer be generated as the options to reach them have now
	gone.  So remove the parsing support for FPA instructions.

	arm: remove options to select the FPA
	Remove the command-line options to choose the FPA (or FPE - an
	emulated FPA).  From this point on it should be impossible to assemble
	the old FPA instructions.

	arm: change default FPUs from FPA to none
	Change the cases where the default FPU was FPA to none.  This should
	ensure that any code that used settings to pick the floating-point
	order will not silently produce a different output.  The options that
	explicitly set the FPA remain for the moment.

2024-06-05  Richard Earnshaw  <rearnsha@arm.com>

	arm: redirect fp constant data directives through a wrapper
	Assembler directives such as .float, or .double are handled by generic
	code, but on Arm, their output can vary depeding on the type of FPU
	begin targetted.  When we remove FPA support we don't want to silently
	generate different code for processors that previously defaulted to
	the FPA, so redirect these directives through a wrapper function that
	checks the FPU is enabled; we use the legacy -mno-fpu in the test to
	catch this.

	Also fix a few tests so that they won't start to fail on targets (eg
	arm-wince-pe) where there is no default format for the FPU and we pick
	this from the default processor type.

2024-06-05  Richard Earnshaw  <rearnsha@arm.com>

	arm: adjust FPU selection logic
	The logic here seems to be overly complex, so simplify it a bit.  One
	particular problem was that using the legacy -mno-fpu option was not
	working properly, as this has all the feature bits set to zero causing
	the code to then pick a different FPU as the default.  Fix this by
	only selecting an FPU as a fallback if the code has not otherwise
	selected one: there was only one route by which this could happen.

	This patch is really a pre-cursor to the following one where we want
	to make no-fpu internally a fall-back position for some legacy
	processors where previously we would have dropped back to the FPA.

2024-06-05  Richard Earnshaw  <rearnsha@arm.com>

	arm: default to softvfp on armv6 or later cores
	From armv6 onwards a lot of cores started to come with a physical VFP
	implementation; but many still did not and in some cases there are
	both variants.  For the cores that lacked a physical VFP we would fall
	back to FPU_NONE if the platform/ABI did not mandate something else.
	To make matters worse, FPU_NONE is internal state used to imply
	soft-fpa (ie a mixed-endian double format), so any use of .double in
	hand-written assembly is almost certainly generating incorrect output.

	That's undesirable, all these cores should really default to a softvfp
	model.

2024-06-05  Richard Earnshaw  <rearnsha@arm.com>

	arm: rename FPU_ARCH_VFP to FPU_ARCH_SOFTVFP
	FPU_ARCH_VFP has always meant VFP floating-point format (natural FP
	word order) but without any VFP instructions.  But the name
	FPU_ARCH_VFP is potentially confusing.  This patch just changes the
	name to make the meaning clearer.

	arm: remove FPA related tests
	Remove various tests of the FPA instruction set and relocation support.

2024-06-05  Nick Clifton  <nickc@redhat.com>

	Fix illegal memory access when bfd_get_section_contents is called with a NULL section pointer.
	  PR 31843

2024-06-05  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Tidy vendor core-v extension gas testcases
	1. Combined testcases into one if they use same extention name.
	2. Likewise for the fail testcases.
	3. Renamed with x-cv prefix, just like what other vendors did.

	gas/
		* testsuite/gas/riscv/cv-alu-*: Combined and renamed to
		x-cv-alu.  Likewise for fail testcases, to x-cv-alu-fail*.
		* testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to
		x-cv-bi and x-cv-bi-fail.
		* testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to
		x-cv-elw and x-cv-elw-fail.
		* testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to
		x-cv-mac and x-cv-mac-fail.
		* testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to
		x-cv-mem and x-cv-mem-fail.

2024-06-05  Mary Bennett  <mary.bennett682@gmail.com>

	RISC-V: Add support for XCVmem extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett682@gmail.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem`
		instruction class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:
		* doc/c-riscv.texi: Note XCVmem as an additional ISA extension
		for CORE-V.
		* testsuite/gas/riscv/cv-mem-fail-march.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-march.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-march.s: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test.
		* testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test.
		* testsuite/gas/riscv/cv-mem-lbpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lbpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lbrr.d: New test.
		* testsuite/gas/riscv/cv-mem-lbrr.s: New test.
		* testsuite/gas/riscv/cv-mem-lbrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lbrrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lbupost.d: New test.
		* testsuite/gas/riscv/cv-mem-lbupost.s: New test.
		* testsuite/gas/riscv/cv-mem-lburr.d: New test.
		* testsuite/gas/riscv/cv-mem-lburr.s: New test.
		* testsuite/gas/riscv/cv-mem-lburrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lburrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lhpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lhpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lhrr.d: New test.
		* testsuite/gas/riscv/cv-mem-lhrr.s: New test.
		* testsuite/gas/riscv/cv-mem-lhrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lhrrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lhupost.d: New test.
		* testsuite/gas/riscv/cv-mem-lhupost.s: New test.
		* testsuite/gas/riscv/cv-mem-lhurr.d: New test.
		* testsuite/gas/riscv/cv-mem-lhurr.s: New test.
		* testsuite/gas/riscv/cv-mem-lhurrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lhurrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lwpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lwpost.s: New test.
		* testsuite/gas/riscv/cv-mem-lwrr.d: New test.
		* testsuite/gas/riscv/cv-mem-lwrr.s: New test.
		* testsuite/gas/riscv/cv-mem-lwrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-lwrrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-sbpost.d: New test.
		* testsuite/gas/riscv/cv-mem-sbpost.s: New test.
		* testsuite/gas/riscv/cv-mem-sbrr.d: New test.
		* testsuite/gas/riscv/cv-mem-sbrr.s: New test.
		* testsuite/gas/riscv/cv-mem-sbrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-sbrrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-shpost.d: New test.
		* testsuite/gas/riscv/cv-mem-shpost.s: New test.
		* testsuite/gas/riscv/cv-mem-shrr.d: New test.
		* testsuite/gas/riscv/cv-mem-shrr.s: New test.
		* testsuite/gas/riscv/cv-mem-shrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-shrrpost.s: New test.
		* testsuite/gas/riscv/cv-mem-swpost.d: New test.
		* testsuite/gas/riscv/cv-mem-swpost.s: New test.
		* testsuite/gas/riscv/cv-mem-swrr.d: New test.
		* testsuite/gas/riscv/cv-mem-swrr.s: New test.
		* testsuite/gas/riscv/cv-mem-swrrpost.d: New test.
		* testsuite/gas/riscv/cv-mem-swrrpost.s: New test.
		* testsuite/gas/riscv/march-help.l: Add xcvmem string.

	include/ChangeLog:

		* opcode/riscv-opc.h: Add corresponding MATCH and MASK macros
		for XCVmem.
		* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
		for XCVmem.
		(enum riscv_insn_class): Add the XCVmem instruction class.

	opcodes/ChangeLog:

		* riscv-opc.c: Add XCVmem instructions.

2024-06-05  Mary Bennett  <mary.bennett682@gmail.com>

	RISC-V: Add support for XCVbi extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett682@gmail.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>
	  Nazareno Bruschi <nazareno.bruschi@embecosm.com>
	  Lin Sinan

	include/ChangeLog:

		* opcode/riscv-opc.h: Add corresponding MATCH and MASK
		macros for XCVbi.
		* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
		for XCVbi.
		(enum riscv_insn_class): Add the XCVbi instruction class.

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn): Add the necessary
		operands for the extension.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Note XCVbi as an additional ISA extension
		for CORE-V.
		* testsuite/gas/riscv/cv-bi-beqimm.d: New test.
		* testsuite/gas/riscv/cv-bi-beqimm.s: New test.
		* testsuite/gas/riscv/cv-bi-bneimm.d: New test.
		* testsuite/gas/riscv/cv-bi-bneimm.s: New test.
		* testsuite/gas/riscv/cv-bi-fail-march.d: New test.
		* testsuite/gas/riscv/cv-bi-fail-march.l: New test.
		* testsuite/gas/riscv/cv-bi-fail-march.s: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test.
		* testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test.
		* testsuite/gas/riscv/march-help.l: Add xcvbi string.

	include/ChangeLog:

		* opcode/riscv-opc.h: Add corresponding MATCH and MASK
		macros for XCVbi.
		* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
		for XCVbi.
		(enum riscv_insn_class): Add the XCVbi instruction class.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Add disassembly for new operand.
		* riscv-opc.c: Add XCVbi instructions.

2024-06-05  Mary Bennett  <mary.bennett682@gmail.com>

	RISC-V: Add support for XCVelw extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett682@gmail.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvelw` instruction
		class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* doc/c-riscv.texi: Note XCVelw as an additional ISA extension
		for CORE-V.
		* testsuite/gas/riscv/cv-elw-fail.d: New test.
		* testsuite/gas/riscv/cv-elw-fail.l: New test.
		* testsuite/gas/riscv/cv-elw-fail.s: New test.
		* testsuite/gas/riscv/cv-elw-fail-march.d: New test.
		* testsuite/gas/riscv/cv-elw-fail-march.l: New test.
		* testsuite/gas/riscv/cv-elw-fail-march.s: New test.
		* testsuite/gas/riscv/cv-elw-pass.d: New test.
		* testsuite/gas/riscv/cv-elw-pass.s: New test.
		* testsuite/gas/riscv/march-help.l: Add xcvelw string.

	opcodes/ChangeLog:

		* riscv-opc.c: (riscv_opcode) Add event load instructions.

	include/ChangeLog:

		* opcode/riscv-opc.h: Add corresponding MATCH and MASK
		instruction opcode macros.
		* opcode/riscv.h (riscv_insn_class): Add INSN_CLASS_XCVELW.

2024-06-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: remove trailing \r from rust_llvm_version result
	I noticed that the value returned by rust_llvm_version had a trailing
	carriage return.  I don't think this is causing any problems right
	now, but looking at the code I don't think this was the desired
	behaviour.

	The current code runs 'rustc --version --verbose', splits the output
	at each '\n' and then loops over every line looking for the line that
	contains the LLVM version.

	There are two problems here.  First, at the end of each captured line
	we have '\r\n', so when we split the lines on '\n', each of the lines
	will still end with a '\r' character.

	Second, though we loop over the lines, when we try to compare the line
	contents we actually compare the unsplit full output.  Luckily this
	still finds the match, but this renders the loop over lines redundant.

	This commit makes two fixes:

	 1. I use regsub to convert all '\r\n' sequences to '\n'; now when we
	    split on '\n' the lines will not end in '\r'.

	 2. Within the loop over lines block I now check the line contents
	    rather than the unsplit full output; now we capture a value
	    without a trailing '\r'.

	There's only one test (gdb.rust/simple.exp) that uses
	rust_llvm_version, and it doesn't care if there's a trailing '\r' or
	not, so this change should make no difference there.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: more filename styling in remote.c and target.c
	I spotted a few more places where we could apply filename styling in
	remote.c and target.c.  Other than the styling, there should be no
	user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Return global scope from DAP scopes request
	A co-worker requested that the DAP code emit a scope for global
	variables.  It's not really practical to do this for all globals, but
	it seemed reasonable to do this for globals coming from the frame's
	compilation unit.  For Ada in particular, this is convenient as it
	exposes package-scoped variables.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Convert DAP disassemble code to use Block hashing
	This changes the DAP disassemble code to use the new Block hashing,
	storing the already-visited blocks in a set rather than a list.

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Memoize gdb.Block and make them hashable
	In subsequent patches, it's handy if gdb.Block is hashable, so it can
	be stored in a set or a dictionary.  However, doing this in a
	straightforward way is not really possible, because a block isn't
	truly immutable -- it can be invalidated.  And, while this isn't a
	real problem for my use case (in DAP the maps are only used during a
	single stop), it seemed error-prone.

	This patch instead takes the approach of using the gdb.Block's own
	object identity to allow hashing.  This seems fine because the
	contents don't affect the hashing.  In order for this to work, though,
	the blocks have to be memoized -- two requests for the same block must
	return the same object.

	This also allows (actually, requires) the simplification of the
	rich-compare method for blocks.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Put "source" into DAP scope
	I noticed a FIXME comment in the DAP code about adding a "source"
	field to a scope.  This is easy to implement; I don't know why I
	didn't do this originally.

	Remove a couple unnecessary casts
	After the previous bcache change, a couple of casts in objfiles.h are
	now redundant.

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Make bcache more type-safe
	The bcache uses memcpy to make copies of the data passed to it.  In
	C++, this is only safe for trivially-copyable types.

	This patch changes bcache to require this property, and slightly
	changes the API to make it easier to use when copying a single object.
	It also makes the new 'insert' template methods return the correct
	type.

2024-06-04  Tom Tromey  <tromey@adacore.com>

	Some constification in psymtab
	This patch changes some spots in psymtab.[ch] to use 'const'.  This is
	just preparation for a subsequent patch.  Note that psymbols are
	conceptually const, and since they were changed to be
	objfile-indepdendent, they are truly never modified -- which is what
	makes this patch reasonably short.

	Rely on std::uncaught_exceptions
	std::uncaught_exceptions is a C++17 feature, so I think we can remove
	this conditional code from inferior.h.

2024-06-04  Dmitry Neverov  <dmitry.neverov@jetbrains.com>

	Add myself to gdb/MAINTAINERS

2024-06-04  Rostislav Krasny  <rostiprodev@gmail.com>

	src-release.sh: fix adjusting files permissions and cleaning
	  PR 31800

2024-06-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: tests for debug lookup within the sysroot
	Add tests for looking up debug information within the sysroot via both
	build-id and gnu_debuglink.

	I wanted to ensure that the gnu_debuglink test couldn't make use of
	build-ids, so I added the 'no-build-id' flag to gdb_compile.

	As these tests rely on setting the sysroot, if I'm running a
	dynamically linked executable, GDB will try to find all shared
	libraries within the sysroot.  This would mean I'd have to figure out
	and copy all shared libraries the executable uses, certainly possible,
	but a bit of a pain.

	So instead, I've just compiled the test executable as a static binary.
	Now there are no shared library dependencies.

	I can now split the debug information out from the test binary, and
	place it within the sysroot.  When GDB is started and the executable
	loaded, we can check that GDB is finding the debug information within
	the sysroot.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-06-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: make gdb_gnu_strip_debug consistent
	While writing a test I realised that the default behaviour of
	gdb_gnu_strip_debug doesn't match its comment.

	The comment says that the function takes a FILENAME, and splits the
	file into FILENAME.stripped and FILENAME.debug, leaving FILENAME
	unchanged.  The comment says that a .gnu_debuglink will be added to
	FILENAME.stripped.

	However, this is not true, FILENAME.stripped is created, with no debug
	information.  FILENAME.debug is created containing the debug
	information.

	But, when adding the .gnu_debuglink we take FILENAME.stripped as the
	input, and then overwrite FILENAME with the output.  As a result,
	FILENAME.stripped does not include a .gnu_debuglink, while FILENAME
	contains the .gnu_debuglink and no debug information!

	The users of gdb_gnu_strip_debug can be split into two groups, those
	who are using the .gnu_debuglink, these tests are all written assuming
	that FILENAME is updated.

	Then there are some tests that only rely on gdb_gnu_strip_debug's
	ability to split out the debug information, these tests are then going
	to do a lookup based on the build-id, these tests don't require the
	.gnu_debuglink.  These tests use the FILENAME.stripped output file.

	This all seems too confused to me.

	As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I
	propose that we just make that the actual, advertised behaviour of
	this proc.

	So now, gdb_gnu_strip_debug will take FILENAME, and will split the
	debug information out into FILENAME.debug.  The debug information will
	then be stripped from FILENAME, and by default a .gnu_debuglink will
	be added to FILENAME pointing to FILENAME.debug.

	I've updated the two tests that actually relied on FILENAME.stripped
	to instead just use FILENAME.

	One of the tests was doing a build-id based lookup, but was still
	allowing the .gnu_debuglink to be added to FILENAME, I've updated this
	test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops
	the .gnu_debuglink from being added.

	All of the tests that call gdb_gnu_strip_debug still pass for me.

	Acked-By: Tom de Vries <tdevries@suse.de>

2024-06-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/Makefile.in: silence recipe for creating .deps/ directories
	When building in a fresh directory we'll see some output like this:

	  /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps
	  mkdir -p -- arch/.deps
	  /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps
	  mkdir -p -- cli/.deps
	  /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps
	  mkdir -p -- dwarf2/.deps
	  ... etc ...

	this commit uses silent-rules.mk to silence this output, now we'll
	see:

	  GEN    arch/.deps
	  GEN    cli/.deps
	  GEN    dwarf2/.deps
	  ... etc ...

	The recipe that currently generates these directories uses
	mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs
	is deprecated and 'install-sh -d' should be used instead.  This
	silences the 'mkdir -p -- ...' part of the output.

	There should be no change in what is actually built after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-04  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Disable linker relaxation if set the address of section or segment
	If set the address of section or segment, the offset from pc to symbol
	may become bigger and cause overflow.

2024-06-04  mengqinggang  <mengqinggang@loongson.cn>
	    Jinyang He  <hejinyang@loongson.cn>

	LoongArch: Make align symbol be in same section with alignment directive
	R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only
	created at the first time to handle alignment directive. This means that
	all other sections may use this symbol. If the section of this symbol is
	discarded, there may be problems. Search it in its own section.

	Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c.

	Reported-by: WANG Xuerui <git@xen0n.name>
	Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t

2024-06-04  Richard Earnshaw  <rearnsha@arm.com>

	arm: testsuite: fix msdos line endings in tests
	A couple of the tests in the testsuite were at some point in the past
	committed with DOS-style CRLF line endings.  This potentially causes
	email problems if the tests are touched in the middle of a large patch
	series so convert them to standard Un*x line endings.

2024-06-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add hardware counters for AMD Zen4
	ChangeLog
	2024-06-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* common/hwctable.c: Add the hwc table for AMD Zen4.
		* src/hwc_amd_zen4.h: New file.
		* src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H.

2024-06-03  Tom Tromey  <tom@tromey.com>

	Remove one call to can_box from TUI
	This removes a call to can_box from
	tui_source_window_base::show_source_content.  can_box will always
	return true here.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-06-03  Tom Tromey  <tromey@adacore.com>

	Fix deprecation text
	I noticed one spot where deprecate_cmd is called with a second
	argument that is not a command name.  This patch fixes the problem.

	Regression tested on x86-64 Fedora 38.

2024-06-03  Hannes Domani  <ssbssa@yahoo.de>

	Enable call of overloaded subscript operator from python
	If you try to use the overloaded subscript operator of a class
	in python, it fails like this:

	(gdb) py print(gdb.parse_and_eval('b')[5])
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	gdb.error: Cannot subscript requested type.
	Error while executing Python code.

	This simply checks if such an operator exists, and calls it
	instead, making this possible:

	(gdb) py print(gdb.parse_and_eval('b')[5])
	102 'f'

	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-03  Hannes Domani  <ssbssa@yahoo.de>

	Allow calling of convenience functions with python
	As mentioned in PR13326, currently when you try to call a
	convenience function with python, you get this error:

	(gdb) py print(gdb.convenience_variable("_isvoid")(3))
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD).
	Error while executing Python code.

	So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as
	well, making this possible:

	(gdb) py print(gdb.convenience_variable("_isvoid")(3))
	0

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326
	Approved-By: Tom Tromey <tom@tromey.com>

2024-06-03  Mark Wielaard  <mark@klomp.org>

	src-release.sh: Use -T0 for xz compression
	Use parallel compression to create the xz archive.

	On my machine (using 4 cores) this reduces the time to create
	binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds.

	xz has supported -T0 since version 5.2.0 (released 2014-12-21).

2024-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/resize-2.exp
	When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run
	into:
	...
	tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable
	^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout)
	...

	The test-case does "Term::resize 24 80 0" while having the settings of an
	earlier "Term::resize 40 90", so both dimensions change.

	When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc:
	- calls stty to change one dimension,
	- waits for the message (enabled by "maint set tui-resize-message on")
	  confirming the resize has happened,
	- calls stty to change the other dimension, and again
	- waits for the message confirming the resize has happened.

	Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the
	message is not printed, so stty is called twice, and afterwards we check for
	the results of the two resizes, which is the test that is failing.

	The problem is that not waiting for a response after each stty call opens up
	the possibility of the responses being merged.

	Fix this by calling Term::resize twice, changing one dimension at a time, and
	waiting for a single prompt redisplay after each one.

	Tested on x86_64-linux.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

	PR testsuite/31822
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822

2024-06-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-02  Tom Tromey  <tom@tromey.com>

	Fix typo in tui-data.h
	I noticed a typo in a comment in tui-data.h.

2024-06-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-06-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-31  Kevin Buettner  <kevinb@redhat.com>

	[gdb/testsuite] New test: gdb.base/errno.exp
	Printing the value of 'errno' from GDB is sometimes problematic.  The
	situation has improved in recent years, though there are still
	scenarios for which "print errno" doesn't work.

	The test, gdb.base/errno.exp, introduced by this commit, tests whether
	or not GDB can print errno using a binary compiled in the following
	different ways:

	- default: no switches aside from -g (and whatever else is added by the
	  testing framework)
	- macros: macro info is included in the debuginfo; this is enabled by
	  using -g3 when using gcc or clang
	- static: statically linked binary
	- static-macros: statically linked binary w/ macro definitions included
	  in debuginfo
	- pthreads: libpthread linked binary
	- pthreads-macros: libpthread linked binary w/ macro definitions included
	  in debuginfo
	- pthreads-static: Statically linked against libpthread
	- pthreads-static-macros: Statically linked against libpthread w/ macro
	  definitions

	For each of these, the test also creates a corefile, then loads the
	corefile and attempts to print errno again.

	Additionally, the test checks that a "masking" errno declared as a
	local variable will print correctly.

	On Linux, if the machine is missing glibc debuginfo (or you have
	debuginfod disabled), it's likely you'll see:

	    (gdb) print errno
	    'errno' has unknown type; cast it to its declared type

	But if you add a cast, the value of errno is often available:

	    (gdb) print (int) errno
	    $1 = 42

	The test detects this situation along with several others and does
	'setup_xfail' for tests that will almost certainly fail.  It could be
	argued that some of these ought to be KFAILs due to deficiencies in
	GDB, but I'm not entirely certain which, if any, are fixable yet.

	On Fedora 39, without glibc debuginfo, there are no failures, but
	I do see the following XFAILS:

	XFAIL: gdb.base/errno.exp: default: print errno
	XFAIL: gdb.base/errno.exp: default: check errno value from corefile
	XFAIL: gdb.base/errno.exp: macros: print errno
	XFAIL: gdb.base/errno.exp: macros: print (int) errno
	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static: print errno
	XFAIL: gdb.base/errno.exp: static: print (int) errno
	XFAIL: gdb.base/errno.exp: static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: print errno
	XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads: print errno
	XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	On Fedora 39, with glibc debug info, but without libc.a (for static
	linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED
	tests.

	So, even when testing in less than ideal conditions, either due to lack
	of glibc debuginfo or lack of a libc to link against to make a static
	binary, there are no failures.

	With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40,
	Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs:

	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static: print errno
	XFAIL: gdb.base/errno.exp: static: print (int) errno
	XFAIL: gdb.base/errno.exp: static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: print errno
	XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	On FreeBSD 13.1, the total number of XFAILs are fewer, and could be
	even better still if it had debug info for glibc:

	XFAIL: gdb.base/errno.exp: default: print errno
	XFAIL: gdb.base/errno.exp: default: check errno value from corefile
	XFAIL: gdb.base/errno.exp: macros: print errno
	XFAIL: gdb.base/errno.exp: macros: print (int) errno
	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads: print errno
	XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	Starting with glibc-2.34, most of the pthreads library has been
	incorporated into libc, so finding thread-local variables using
	libthread_db is possible for several scenarios in which it previously
	wasn't.  But, prior to this, accessing errno for the default scenario
	was a problem.  This is borne out by running this new test on Fedora
	34, which uses glibc-2.33:

	XFAIL: gdb.base/errno.exp: default: print errno
	XFAIL: gdb.base/errno.exp: default: print (int) errno
	XFAIL: gdb.base/errno.exp: default: check errno value from corefile
	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static: print errno
	XFAIL: gdb.base/errno.exp: static: print (int) errno
	XFAIL: gdb.base/errno.exp: static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: print errno
	XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	In the v3 version of this test, Tom de Vries tested on openSUSE Leap
	15.5 and found a number of cases which showed a FAIL instead of an
	XFAIL.  The v4 version of this test fixed those problems.  On Leap
	15.5, which uses glibc-2.31, with glibc debug info, I now see:

	XFAIL: gdb.base/errno.exp: default: print errno
	XFAIL: gdb.base/errno.exp: default: print (int) errno
	XFAIL: gdb.base/errno.exp: default: check errno value from corefile
	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static: print errno
	XFAIL: gdb.base/errno.exp: static: print (int) errno
	XFAIL: gdb.base/errno.exp: static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	On Leap 15.5, with glibc debuginfo missing, the results are a little
	worse:

	XFAIL: gdb.base/errno.exp: default: print errno
	XFAIL: gdb.base/errno.exp: default: print (int) errno
	XFAIL: gdb.base/errno.exp: default: check errno value from corefile
	XFAIL: gdb.base/errno.exp: macros: print errno
	XFAIL: gdb.base/errno.exp: macros: print (int) errno
	XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static: print errno
	XFAIL: gdb.base/errno.exp: static: print (int) errno
	XFAIL: gdb.base/errno.exp: static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads: print errno
	XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static: print errno
	XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
	XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
	XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

	The v5 version of this test fixed failures when testing with
	check-read1.  (Thanks to Linaro CI for finding these.)  I revised the
	regular expressions being used so that the failures were eliminated,
	but the results mentioned above have not changed.

	The v6 version of this test fixes some nits pointed out by both Tom
	de Vries and Pedro Alves.  One of Pedro's suggestions was to rename the
	test from check-errno.exp to errno.exp, so in v5, the name has
	changed.  Tom also noticed that there were failures when using
	--target_board=native-extended-gdbserver.  For v6, I've tested on 10
	different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o
	static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o
	glibc debuginfo, and Fedora 34) using "make check" and "make check-read1"
	using target boards "unix", "native-extended-gdbserver", and
	"native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for
	a total of 12 distinct test runs on each machine.  I've also tested the
	native-only cases on FreeBSD.  (Attempting to test against gdbserver
	on FreeBSD resulted in hangs while running the test suite.)

	The v7 version of this test simplifies the REs used in the uses of
	gdb_test_multiple by adding -wrap and removing parts of the REs which
	match the GDB prompt.  In cases where there was a leading '.*', those
	were removed too.  Thanks to Pedro for explaining how to use -wrap.

	So, bottom line, this test does not introduce any new failures on the
	platforms on which I've tested, but the XFAILs are certainly unfortunate.
	Some aren't fixable - e.g. when attempting to make a function call while
	debugging a core file - but I think that some of them are.  I'm using
	this new test case as a starting point for investigating problems with
	printing errno.

	Co-Authored-By: Jan Kratochvil
	Approved-By: Tom de Vries <tdevries@suse.de>

2024-05-31  Claudio Bantaloukas  <claudio.bantaloukas@arm.com>

	aarch64, testsuite: avoid regexes in opcode field
	Some dejagnu files use regexes rather than specific encodings. This
	change replaces them with the explicit encodings we expect.

	Tested against aarch64-unknown-linux-gnu and aarch64-none-elf.

2024-05-31  saurabh.jha@arm.com  <saurabh.jha@arm.com>

	gas, aarch64: Fixes in texi and tests following faminmax and lut changes
	Making two cleanups that came out of the comments from my previous
	patches:
	1. Fixing `c-aarch64.texi` file so that the AArch64 architecture
	   extensions are ordered alphabetically.
	2. Fixing faminmax test cases so that they follow the existing test
	   conventions.

2024-05-31  Tom Tromey  <tromey@adacore.com>

	Move dwarf2_per_bfd::index_addrmap to mapped_gdb_index
	dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader,
	so this field can be moved to mapped_gdb_index instead.  Then,
	cooked_index_functions::find_per_cu can be removed in favor of a
	method on the index object.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-05-31  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Add some DT_RELR ld tests

2024-05-31  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	aarch64: Add DT_RELR support
	The logic to decide if an input relocation for a symbol becomes a
	particular kind of output relocation is one of the hard to maintain
	parts of the bfd ld backend, since it is partially repeated across

	 elfNN_aarch64_check_relocs (where dynamic relocations are counted per
	 symbol and input section),

	 elfNN_aarch64_late_size_sections (where relocation sections are sized
	 and GOT offsets assigned),

	 elfNN_aarch64_relocate_section (where most relocations are applied and
	 output to a relocation section),

	 elfNN_aarch64_finish_dynamic_symbol (where some of the GOT
	 relocations are applied and output).

	The DT_RELR support adds another layer to this complexity: after the
	output relocation sections are sized, so all dynamic relocations are
	accounted (in elfNN_aarch64_late_size_sections), we scan the symbols
	and input relocations again to decide which ones become relative
	relocations that can be packed. The sizes of the relocation sections
	are updated accordingly. This logic must be consistent with the code
	that applies the relocs later so each relative relocation is emitted
	exactly once: either in .rela.* or packed in .relr.dyn.

	Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that
	may be called repeatedly whenever the layout changes since an address
	change can affect the size of the packed format. Then the final content
	is emitted in elfNN_aarch64_finish_relative_relocs, that is called
	after the layout is final and before relocations are applied and
	emitted. These hooks are only called if DT_RELR is enabled.

	We only pack relative relocs that are known to be aligned in the output
	during .relr.dyn sizing, the potentially unaligned relative relocs are
	emitted normally (in .rela.*, not packed), because the format requires
	aligned addresses.

2024-05-31  Jan Beulich  <jbeulich@suse.com>

	x86: reduce check_{byte,word,long,qword}_reg() overhead
	These run after template matching. Therefore it is quite pointless for
	them to check all operands, when operand sizes matching across operands
	is already known. Exit the loops early in such cases.

	In check_byte_reg() also drop a long-stale part of a comment.

2024-05-31  Felix Willgerodt  <felix.willgerodt@intel.com>
	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, amd64: remove unused forward declarations
	These structs are not referenced anywhere anymore and seemed to have been
	missed at some point when their usage was removed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-31  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb, doc: Fix AVX-512 documentation.
	org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the
	docs yet.  Fix that.

	In addition the documentation describes xmm registers with an `h`
	(e.g. xmm16h).  I am assuming that we follow the register xml files here,
	which don't have the h suffix.  So this removes that as well.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-05-31  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes in utils.h
	Remove some includes reported as unused by clangd.  Add some includes in
	other files that were previously relying on the transitive include.

	Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e

2024-05-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused includes in symfile.c
	Remove some includes reported as unused by clangd.

	Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6

2024-05-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused includes in breakpoint.{c,h}
	Remove some includes reported as unused by clangd.

	Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d

2024-05-30  Nick Clifton  <nickc@redhat.com>

	Update binutils release documentation to include using the -z option when invoking src-release.sh

2024-05-30  Mark Wielaard  <mark@klomp.org>

	src-release.sh: Support zstd compression

2024-05-30  Simon Marchi  <simon.marchi@efficios.com>

	.gitignore: ignore .vscode

2024-05-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: don't have .pod targets separate to man page targets
	While preparing the new release it was discovered that commit:

	  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
	  Date:   Fri Apr 12 17:47:20 2024 +0100

	      gdb/doc: use silent-rules.mk in the Makefile

	was causing problems.  Given a release tar file, an attempt to build
	and install GDB would give an error like this:

	  [...]
	    TEXI2POD gdb.pod
	  cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
	  make[5]: *** [Makefile:663: gdb.pod] Error 2

	The problem here is how the man pages are built, and how they are
	distributed within a release.

	Within the development (git) tree, the man page files are not part of
	the source tree, these files are built as needed.  Within a release
	tar file though, the man pages are included.  The idea being that a
	user can build and install GDB, including getting the man pages,
	without having to install the tools needed to generate the man pages.

	The man pages are generated in a two step process.  First the .texi
	file is processed with texi2pod to create a .pod file, then this .pod
	file is processed to create the .1 or .5 man file.

	Prior to the above commit these two steps were combined into a single
	recipe, this meant that when a user performed a build/install from a
	release tree all of the dependencies, as well as the final result,
	were all present in the source tree, and so nothing needed to be
	rebuilt.

	However, the above commit split the two steps apart.  Now we had a
	separate rule for building the .pod files, and the .1/.5 man page
	files depended on the relevant .pod file.

	As the .pod files are not shipped in a GDB release, this meant that
	one of the dependencies of the man page files was now missing.  As a
	result if a user tried to install from a release tree a rebuild of the
	.pod files would be attempted, and if that succeeded then building the
	man pages would follow that.

	Unfortunately, building the .pod files would fail as the GDBvn.texi
	file, though present in the source tree, was not present in the build
	tree, which is where it is needed for the .pod file generation to
	work.

	To fix this, I propose merging the .pod creation and the .1/.5 man
	page creation back into a single recipe.  Having these two steps split
	is probably the "cleaner" solution, but makes it harder for us to
	achieve our goal of shipping the prebuilt man page files.  I've added
	a comment explaining what's going on (such a comment would have
	prevented this mistake having been made in the first place).

	One possibly weird thing here is that I have left both an
	ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
	recipes.  This is 100% not going to break anything, these just print
	two different progress messages while executing the recipes, but I'm
	not sure if this is considered poor style or not.  Maybe we're only
	supposed to have a single ECHO_* per recipe?

	Anyway, even if this is poor style, I figure it really is just a style
	thing.  We can tweak this later as needed.  Otherwise, this commit
	should fix the current issue blocking the next GDB release.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-29  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	readelf: Use section names for displaying RELR relocs
	In some cases using section names instead of symbol names for
	displaying an address is more useful.

	If the symbol falls outside the section where the address is
	then likely it is not useful to display the address relative to.

	And if symbols are stripped from a binary then printing the
	section that contains the address is more useful than printing
	<no sym>.

2024-05-29  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	readelf: Fix symbol display for RELR relocs
	Filter symbols before binary searching for the right symbol to display
	for a given address, such that only displayable symbols are present and
	at most one per address.

	The current logic does not handle multiple symbols for the same address
	well if some of them are empty, the selected symbol is not stable with
	respect to an unrelated symbol table change and on aarch64 often mapping
	symbols are displayed which is not useful.

	Filtering solves these problems at the cost of a linear scan of the
	sorted symbol table.

	The heuristic to select the best symbol likely could be improved, this
	patch aims to improve symbol display for RELR without complex logic
	such that the output is useful and stable for ld tests.

2024-05-29  Jan Beulich  <jbeulich@suse.com>

	x86/Intel: warn about undue mnemonic suffixes
	Except for very few insns mnemonic suffixes aren't permitted in Intel
	syntax. Warn about such for now, indicating that they will be outright
	refused down the road.

	While fiddling with testcases to address fallout, drop a few things
	which should never have been tested as valid Intel syntax.

	Also add a previously missing line to simd-suffix.d.

2024-05-29  Jan Beulich  <jbeulich@suse.com>

	x86/Intel: SHLD/SHRD have dual meaning
	Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode
	an L suffix may be used, we need to be consistent with this.

	Take the easy route, despite that still leading to an anomaly which is
	also visible from the new testcase:

		shld	eax, ecx, 1
		shld	eax, ecx, cl

	can mean two things with APX: SHL with a D suffix in NDD EVEX encoding,
	or the traditional SHLD in legacy encoding.

2024-05-29  Alan Modra  <amodra@gmail.com>

	PR31796, Internal error in write_function_pdata at obj-coff-seh
	PR31796 is the result of lack of aarch64 support in obj-coff-seh.c.
	Nick fixed this with commit 73c8603c3f.  Make the seh support
	consistently warn in future if some archictecture is missing, rather
	than giving internal errors.

		PR 31796
		* config/obj-coff-seh.c (verify_target): New function.
		(obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc),
		(obj_coff_seh_endprologue): Use it.

2024-05-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-28  Dimitar Dimitrov  <dimitar@dinux.eu>

	ld: pru: Increase the default memory region sizes
	The default memory region sizes for PRU were set somewhat arbitrarily to
	the sizes of the most popular BeagleBone board with AM33x SoC.  But the
	PRU toolchain documentation has always instructed to use SoC-specific
	spec files to override the defaults and set the correct memory sizes [1].

	The small default memory sizes can cause IMEM memory region overflow
	even for simple printf("Hello world") programs, as usually done by
	Autotools checks.  The stdio is simply too big to fit in 8K
	instruction memory.  This can confuse the check and lead to wrong
	feature selection during configure [2].

	Fix by bumping the default DMEM and IMEM memory sizes.

	There is no need to backport this patch.  Issue was caught with a
	feature-rich newlib build used for daily CI.  The release builds of the
	PRU toolchain use stripped newlib configuration, which does not overflow
	the IMEM region, even for 8K.

	[1] https://github.com/dinuxbg/gnuprumcu
	[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158

2024-05-28  Tom Tromey  <tom@tromey.com>

	Make tui_win_info::make_window non-virtual
	Nothing overrides tui_win_info::make_window, so remove the "virtual".
	Tested by rebuilding.

2024-05-28  saurabh.jha@arm.com  <saurabh.jha@arm.com>

	gas, aarch64: Add SVE2 lut extension
	Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links:
	* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
	* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en

	These instructions use new SVE2 vector operands. They are called
	SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have
	1 bit, 2 bit, and 3 bit indices respectively.

	The lsb and width of these new operands are the same as many existing
	operands but the convention is to give different names to fields that
	serve different purpose so we introduced new fields in aarch64-opc.c
	and aarch64-opc.h.

	We made a design choice for the second operand of the halfword variant of
	luti4 with two register tables. We could have either defined a new operand,
	like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With
	the new operand, we would need to implement constraints on register
	lists based on either operand or opcode flag. With existing operand, we
	could just existing constraint checks using opcode flag. We chose
	the second approach and went with SVE_ZnxN and added opcode flag to
	enforce lengths of vector register list operands. This way, we can reuse
	the existing constraint check logic.

2024-05-28  saurabh.jha@arm.com  <saurabh.jha@arm.com>

	gas, aarch64: Add AdvSIMD lut extension
	Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links:
	* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
	* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en

	These instructions needed definition of some new operands. We will first
	discuss operands for the third operand of the instructions and then
	discuss a vector register list operand needed for the second operand.

	The third operands are vectors with bit indices and without type
	qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12
	and they have 1 bit, 2 bit, and 3 bit indices respectively. For these
	new operands, we defined new parsing case branch. The lsb and width of
	these operands are the same as many existing but the convention is to
	give different names to fields that serve different purpose so we
	introduced new fields in aarch64-opc.c and aarch64-opc.h for these new
	operands.

	For the second operand of these instructions, we introduced a new
	operand called LVn_LUT. This represents a vector register list with
	stride 1. We defined new inserter and extractor for this new operand and
	it is encoded in FLD_Rn. We are enforcing the number of registers in the
	reglist using opcode flag rather than operand flag as this is what other
	SIMD vector register list operands are doing. The disassembly also uses
	opcode flag to print the correct number of registers.

2024-05-28  Tom Tromey  <tom@tromey.com>

	Use bool in thread_events
	This changes target_ops::thread_events and target_thread_events to use
	'bool'.  The callers were already doing this.

	Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-05-28  Nick Clifton  <nickc@redhat.com>

	Fix typo in assembler documentation

	Fix: internal error in write_function_pdata at obj-coff-seh
	  PR 31796

	Updated Spanish translation for the BFD sub-directory.

2024-05-28  Richard Earnshaw  <rearnsha@arm.com>

	opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions
	The autogenerated files in opcodes use spaces for indentation.
	Changing that would be a lot of work to little benefit, so add a local
	override to the white-space rules, so patches apply cleanly.

2024-05-28  Nick Clifton  <nickc@redhat.com>

	Add new ELF section and segment types to readelf.

2024-05-28  Javier Mora  <cousteaulecommandant@gmail.com>

	RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi
	The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the
	bit arrangement of the simm20 immediate that belongs to the J type;
	It should be just `simm20[19:0]`.  The current behavior of `gas` matches
	the proposed documentation change.

	Additionally, the opcode is called `opcode6` despite of having 7 bits.
	Rename it to `opcode7`.

	gas/
		* doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7.

2024-05-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-27  Tom Tromey  <tom@tromey.com>

	Re-run make-target-delegates.py
	I re-ran make-target-delegates.py and discovered that the tree was out
	of sync.  This patch corrects the problem.

2024-05-27  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc.
	This was originally reported by Hau Hsu <hau.hsu@sifive.com>.

	Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d

	We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt
	in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64.
	This just like what did in the riscv_elf_finish_dynamic_symbol.

	bfd/
		* elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use
		riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the
		riscv_elf_relocate_section when handling ifunc data reloc.
	ld/
		* testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed.
		* testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise.
		* testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise.
		* testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise.
		* testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed.

2024-05-27  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Segment fault for kernel purgatory when linking.
	This was originally reported by Ard Biesheuvel <ardb@kernel.org>.

	The followings are reproduce steps,
	https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u

	The segment fault happens in the riscv_elf_finish_dynamic_sections when the
	output got section is an ABS.  Refer to MIPS code, they added an extra
	bfd_is_abs_section check to avoid ABS got, so this seems the right and easier
	way to go in the short-term.

	bfd/
		* elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize
		and fill the got entries only when the got isn't an ABS section, and
		the size of got is larger than zero.  The similar goes for gotplt,
		except we already reported error when the gotplt is an ABS.

2024-05-27  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix relaxation overflow caused by ld -z separate-code
	ld -z separate-code let .text and .rodata in two different but read only
	segment. If the symbol and pc in two segment, the offset from pc to
	symbol need to consider segment alignment.

	Add a function 'loongarch_two_sections_in_same_segment' to determine
	whether two sections are in the same segment.

2024-05-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-26  Joel Brobecker  <brobecker@adacore.com>

	Update gdb/NEWS after GDB 15 branch creation.
	This commit a new section for the next release branch, and renames
	the section of the current branch, now that it has been cut.

2024-05-26  Joel Brobecker  <brobecker@adacore.com>

	Bump version to 16.0.50.DATE-git.
	Now that the GDB 15 branch has been created,
	this commit bumps the version number in gdb/version.in to
	16.0.50.DATE-git

	For the record, the GDB 15 branch was created
	from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd.

	Also, as a result of the version bump, the following changes
	have been made in gdb/testsuite:

		* gdb.base/default.exp: Change $_gdb_major to 16.

2024-05-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-25  H.J. Lu  <hjl.tools@gmail.com>

	ld: Document -pie -Ttext-segment=ORG generates ET_EXEC
	This is the v2 patch I am checking in.

	H.J.

2024-05-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-24  Alan Modra  <amodra@gmail.com>

	Re: LoongArch: gas: Adjust DWARF CIE alignment factors
	Adjust the gas testsuite to suit commit de203ed568f6.

		* testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d:
		Expect data alignment of -8.  Tidy.

2024-05-24  Jan Beulich  <jbeulich@suse.com>

	gas: extend \+ support to .irp / .irpc
	PR gas/31752

	These are effectively macro-like, without any separate macro definition.
	They already support \@, so they would better also support \+. This
	allows, where desired, to get away without maintaining an explicit count
	variable in source code.

	With this the recently introduced testcase doesn't need any xfails
	anymore.

2024-05-24  Jan Beulich  <jbeulich@suse.com>

	gas: adjust handling of quotes for .irpc
	The present handling of inner double quotes can lead to very strange
	diagnostics. Follow one of the two possible interpretations of the doc:
	@dots{} referring to possibly multiple white space separated
	@var{values}, each of which may be quoted. The original implementation,
	prior to 465e5617233f ("PR gas/3856"), hints at the other possible
	interpretation: When quoted there's only a single @var{values}, with
	inner quotes taken as ordinary characters. That, however, seems overall
	less useful to me.

	While touching the documentation, mirror the (inverse) spelling
	correction (@section line inconsistent with actual description) to .irp
	as well.

2024-05-24  Jan Beulich  <jbeulich@suse.com>

	x86: simplify VexVVVV_SRC2 handling for the XOP case
	As already suggested during review, rather than having an extra
	conditional in build_modrm_byte() (a code path used for quite a few
	more insns, including even certain GPR ones), adjust the attribute in
	the installed template to properly describe things with operands
	swapped.

2024-05-24  Jan Beulich  <jbeulich@suse.com>

	x86: simplify / consolidate check_{word,long,qword}_reg()
	These run after template matching. Therefore operands are already known
	to match the template in use. With the loop bodies skipping anything not
	a GPR in the actual operands, there's therefore no need to check the
	template's operand type for permitting Reg or Accum.

	At the same time bring the three functions in sync for the "byte" part
	of the logic, as far as checking the template for other sizes (qword
	specifically) goes. Plus drop a stale comment from check_qword_reg(),
	when all three are now behaving the same in this regard.

2024-05-24  Jan Beulich  <jbeulich@suse.com>

	x86: correct VCVT{,U}SI2SD
	Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
	omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]),
	to avoid emitting bad or arbitrarily guessed instructions. Interestingly
	check_{long,qword}_suffix() don't help here, which perhaps is another
	indication that the way they work right now isn't quite appropriate.

	Sadly correcting just the templates breaks operand ambiguity detection,
	since so far that worked from a single template permitting more than one
	suffix. Here we have ambiguity though which can now be noticed only when
	taking all (matching) templates together. Therefore we need to determine
	further matching templates (see code comments for constraints), to then
	accumulate permitted suffixes across all of them.

2024-05-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp
	When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
	regularly into PR26286:
	...
	(gdb) continue^M
	Continuing.^M
	[LWP ... exited]^M
	  ...
	[LWP ... exited]^M
	^M
	Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
	The program no longer exists.^M
	(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
	  break at break_fn: 1
	...

	Add a kfail for this, such that we have:
	...
	(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
	  break at break_fn: 1 (PRMS: threads/26286)
	...

	Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

	Tested on x86_64-linux.

2024-05-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-23  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb, testsuite: Fix return value in gdb.base/foll-fork.exp
	In a remote testing setup, I saw this error:

	~~~
	(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
	ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
	ERROR: expected boolean value but got ""
	    while executing
	"if { ![check_fork_catchpoints] } {
	    untested "follow-fork not supported"
	    return
	}"
	    (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
	    invoked from within
	"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
	    ("uplevel" body line 1)
	    invoked from within
	"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
	    invoked from within
	"catch "uplevel #0 source $test_file_name""
	Remote debugging from host 172.0.1.3, port 37766
	Killing process(es): 1171
	Quit
	~~~

	The actual reason for this were some connection problems. Though the
	function check_fork_catchpoints shouldn't return an empty string, especially
	as it promises to always return 0 or 1. Fix that.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-23  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Restore libc_has_debug_info's less strict behaviour
	The code that was factored out from gdb.base/relativedebug.exp assumed that
	libc has debug info and only determined that it doesn't if it saw a specific
	message from GDB to that effect.  In the process of factoring it into a
	require predicate, I made it stricter by trying to make a specific
	determination of whether or not debug info is available.

	Pedro noticed that "It'll disable the testcase on systems that link with
	their libc statically (even if has debug info), or systems that name their
	libc something else."  Which is something I hadn't considered.

	This patch returns libc_has_debug_info to the original behaviour.

	Also, remove a verbose message that is redundant with the $message
	variable.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-22  Alan Modra  <amodra@gmail.com>

	libctf testsuite compilation failure
		* testsuite/libctf-regression/open-error-free.c (main): Correct
		format length modifier.

2024-05-22  Tom Tromey  <tromey@adacore.com>

	Default dwarf_synchronous to true
	Unfortunately the background DWARF reading series introduced a number
	of races, as repored by thread sanitizer.  This patch changes gdb to
	disable this feature for the time being -- in particular for the gdb
	15 release.

	I've filed a bug and linked all the known races to it.  Once those are
	fixed we can re-enable this feature by default.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751

2024-05-22  Indu Bhagat  <indu.bhagat@oracle.com>

	restore build with --enable-maintainer-mode
	A build with --enable-maintainer-mode is currently failing with:

	make[4]: *** No rule to make target '<SRC>/gas/config/te-ia64aix.h',
		 needed by '<SRC>/gas/po/gas.pot'.  Stop.
	make[4]: Leaving directory '<$OBJ>/gas/po'
	make[3]: *** [Makefile:1695: all-recursive] Error 1
	...

	As config/te-ia64aix.h is now removed, remove the corresponding fragment
	from the makefile.

	gas/
	        * Makefile.am: Remove config/te-ia64aix.h.
	        * Makefile.in: Regenerate.
	        * po/POTFILES.in: Regenerate.

2024-05-22  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: fix incorrect encoding for system register pmsdsfr_el1
	This patch fixes a mistake in the encoding of the system register
	pmsdsfr_el1.

	Reference:
	https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en

2024-05-22  Cui, Lili  <lili.cui@intel.com>

	Support APX zero-upper
	This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc.
	Since the spec only recommends one form of setzu, I won't be adding
	set<cc>reg32/reg64 support in this patch.

	gas/ChangeLog:

	        * config/tc-i386.c (build_apx_evex_prefix): Handle ZU.
	        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
	        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
	        * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test.
	        * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto.
	        * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto.
	        * testsuite/gas/i386/x86-64-apx-zu.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-zu.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~
	        PREFIX_EVEX_MAP4_4F.
	        * i386-dis-evex.h: Ditto.
	        * i386-dis.c (struct dis386): Add new micro 'ZU'.
	        (putop): Handle %ZU.
	        * i386-gen.c: Added ZU.
	        * i386-opc.h: Ditto.
	        * i386-opc.tbl: Added new templates to support ZU.

2024-05-22  Cui, Lili  <lili.cui@intel.com>

	X86: Remove "i.rex" to eliminate extra conditional branch
	Resulting code will do better without the extra conditional branch.
	Remove "i.rex" to eliminate extra conditional branch.

	gas/ChangeLog:

	        * config/tc-i386.c (establish_rex): Remove i.rex.

2024-05-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: use StringBuilder to create long messages
	ChangeLog
	2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/collctrl.cc: Use StringBuilder to create messages.
		Remove unused variables and arrays.
		* src/collctrl.h: Remove unused variables.

2024-05-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Remove hardware counter tables for unsupported hardware (Sparc)
	ChangeLog
	2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31123
		* common/hwctable.c: Remove hardware counter tables for Sparc machines.

2024-05-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove memset() in libcollector
	ChangeLog
	2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* libcollector/collector.c: Use static initialization instead of memset.
		* libcollector/dispatcher.c: Likewise.
		* libcollector/hwprofile.c: Likewise.
		* libcollector/jprofile.c: Likewise.
		* libcollector/profile.c: Likewise.
		* libcollector/synctrace.c: Likewise.

2024-05-22  Cui, Lili  <lili.cui@intel.com>

	Add check for 8-bit old registers in EVEX format
	Since APX supports EVEX from legacy instructions, we need to check
	the 8-bit old registers in EVEX format. And add test cases for it.

	gas/ChangeLog:

	        * config/tc-i386.c (md_assemble): Add invalid check for old byte
	        registers in EVEX format.
	        * testsuite/gas/i386/x86-64-apx-inval.l: Add new test.
	        * testsuite/gas/i386/x86-64-apx-inval.s: Ditto.

2024-05-22  Cui, Lili  <lili.cui@intel.com>

	x86: Split REX/REX2 old registers judgment.
	Split "REX/REX2 old register checking" and "add empty rex prefix"
	into two separate branches.

	gas/ChangeLog:

	        * config/tc-i386.c (establish_rex): Split the judgments.

2024-05-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-21  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: ginsn: remove unnecessary buffer allocation and free
	A previous commit 80ec235 fixed the memory leaks, but brought to light
	that the code should ideally make consistent use of snprintf and not
	allocate/free more buffers than necessary.

	gas/
		* ginsn.c (ginsn_dst_print): Use snprintf consistently.

2024-05-21  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix the hyphenated disassembly comment.
	This patch fixes the following comment.

	-  /* The hyphenated form is preferred for disassembly if there are
	-     more than two registers in the list, and the register numbers
	      are monotonically increasing in increments of one.  */

	+  /* The hyphenated form is preferred for disassembly if there is
	+     more than one register in the list, and the register numbers
	      are monotonically increasing in increments of one.  */

2024-05-21  Tom Tromey  <tromey@adacore.com>

	Clarify documentation for pretty_printer.child
	An Ada pretty-printer had a bug where its 'child' method returned a
	gdb.Value rather than a tuple.  Kévin suggested that the documentation
	for this method could be improved to clarify this.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-05-21  Jan Beulich  <jbeulich@suse.com>

	gas: drop remnants of ia64-*-aix*
	With BFD not supporting that target anymore, GAS can't possibly support
	it either.

	ld: silence makeinfo warnings
	Older tool versions (4.12 in my case) demand . or , after @xref{};
	arrange for this to be the case.

2024-05-21  Nick Alcock  <nick.alcock@oracle.com>

	include, libctf: improve documentation
	Some review comments came in after I pushed the last lot of ctf-api.h
	comment improvements.  They were good, so I've incorporated them.
	Mostly: better _next iterator usage info, better info on ctf_*open
	functions, and better info on ctf_type_aname and ctf_type_name_raw.

	include/
		* ctf-api.h: improve documentation.

2024-05-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-20  Kévin Le Gouguec  <legouguec@adacore.com>

	gdb: Fix Windows build after #include shuffle
	Without this patch, the build chokes on:

	    ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic<bool>'
	      384 |   std::atomic<bool> m_debug_event_pending { false };
	          |                     ^~~~~~~~~~~~~~~~~~~~~
	    In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
	                     from […gcc tree…]/include/c++/13.2.1/memory:81,
	                     from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23,
	                     from ../../src/gdb/../gdbsupport/common-utils.h:26,
	                     from ../../src/gdb/../gdbsupport/common-defs.h:199,
	                     from ./../../src/gdb/defs.h:26,
	                     from <command-line>:
	    […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>'
	      174 |     struct atomic;
	          |            ^~~~~~
	    make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1

	Presumably windows-nat.c relied on objfiles.h including <atomic>,
	which was undone in 2024-05-16 "gdb: remove unused includes in
	objfiles.{c,h}" (f617661c110).

2024-05-20  Luca Boccassi  <luca.boccassi@gmail.com>

	readelf: add pretty printing for FDO Dlopen Metadata note

2024-05-20  Nick Clifton  <nickc@redhat.com>

	Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh
	  PR 31726

2024-05-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix can_spawn_for_attach_1 consistency check
	When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
	target board native-gdbserver, we run into:
	...
	(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
	ERROR: gdbserver does not support attach 4827 without extended-remote
	    while executing
	"error "gdbserver does not support $command without extended-remote""
	    (procedure "gdb_test_multiple" line 51)
	    invoked from within
	"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
	        -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
	            # Not permitte..."
	    (procedure "gdb_real__can_spawn_for_attach_1" line 27)
	    invoked from within
	"gdb_real__can_spawn_for_attach_1"
	...

	The problem is that:
	- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
	  designed to be called only from that function, and
	- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
	  test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
	  can_spawn_for_attach_1 directly.

	Fix this by copying the early-outs from can_spawn_for_attach to
	can_spawn_for_attach_1.

	Tested on x86_64-linux.

	Reported-By: Simon Marchi <simark@simark.ca>
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2024-05-20  Claudio Bantaloukas  <claudio.bantaloukas@arm.com>

	aarch64: Add support for the fpmr system register

2024-05-20  Georg-Johann Lay  <avr@gjlay.de>

	Include .rodata size in avr-objdump -P mem-usage.
	  PR 31687

	Let avr-objdump show .note.gnu.avr.deviceinfo
	  PR 31704

2024-05-20  Sung-hun Kim  <sfoon.kim@samsung.com>

	RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa
	The DWARF specification (especially, DWARF4 and 5 [1,2]) states that
	DW_CFA_def_cfa_register cannot be used as the first CFI operation.
	It said DW_CFA_def_cfa_register as follows:

	  ... This operation is valid only if the current CFA rule is defined
	  to use a register and offset.

	So, DW_CFA_def_cfa_register can be used after that other definition
	operation such as DW_CFA_def_cfa is called. However, the current gas
	code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV.

	In the libgcc, the unwinding function does not care about it, so it can
	unwind the call stack. However, on the third party library such as
	libunwindstack in Android, it causes a fatal error.

	This patch changes the initial CFI operation to DW_CFA_def_cfa with
	offset 0. It works as same as the previous one, but it does not have
	any limitation so it satisfies the DWARF spec. This change resolves
	the compatibility issue while preserving the original behaviour.

	[1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf
	[2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Nelson Chu <nelson@rivosinc.com>

	gas/
		PR 31733
		config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use
		DW_CFA_def_cfa rather than DW_CFA_def_cfa_register.

2024-05-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-18  Tom Tromey  <tom@tromey.com>

	Remove unnecessary block from execute_fn_to_ui_file
	I noticed that execute_fn_to_ui_file has an extra, unnecessary block.
	This patch removes it.

2024-05-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add hardware counters for AMD Zen3
	Historically, we have used several APIs (perfctr, libcpc, perf_event_open) for profiling.
	For each hardware we have several tables of hardware counters.
	Some information is duplicated in these tables.
	Some of the information is no longer used.
	I did not touch the existing hwc tables.
	I added a new hwc table for an AMD Zen3 machine.

	ChangeLog
	2024-05-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31123
		* common/core_pcbe.c (core_pcbe_get_events): Add new argument.
		* common/hwc_cpus.h: New constants for AMD hardware.
		* common/hwcdrv.c: Add new argument to hwcdrv_get_descriptions.
		Clean up the code.
		* common/hwcdrv.h: Likewise.
		* common/hwcfuncs.c (hwcdrv_get_descriptions): Add new argument.
		* common/hwctable.c: Add the hwc table for AMD Zen3.
		* src/hwc_amd_zen3.h: New file.
		* common/opteron_pcbe.c: Add new argument to opt_pcbe_get_events.
		* src/collctrl.cc: Remove unused variable.
		* src/collctrl.h: Likewise.

2024-05-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove old interface with libcpc
	interface with libcpc was used on Solaris.
	gprofng doesn't support profiling on Solaris.
	I removed this old code and other unused macros and variables.

	gprofng/ChangeLog
	2024-04-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31123
		* common/hwcdrv.c: remove old interface with libcpc.
		* common/hwcdrv.h: Likewise.
		* common/hwcentry.h: Likewise.
		* common/hwcfuncs.c: Likewise.
		* common/hwcfuncs.h: Likewise.
		* common/hwctable.c: Likewise.
		* src/Dbe.cc: Likewise.
		* src/collctrl.cc: Likewise.

2024-05-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-17  Indu Bhagat  <indu.bhagat@oracle.com>

	bfd: sframe: minor code adjustments and fix typos
	bfd/
		* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use local
		variable.
		(_bfd_x86_elf_size_dynamic_sections): Fix typos.

2024-05-17  Tom Tromey  <tromey@adacore.com>

	Remove gdb_stdtargerr
	This patch removes gdb_stdtargerr.  There doesn't seem to be a need
	for this -- it is always the same as stdtarg, and (I believe) has been
	for many years.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-17  Tom Tromey  <tromey@adacore.com>

	Don't allow new-ui to start the TUI
	The TUI can't really work properly with new-ui, at least not as
	currently written.  This patch changes new-ui to reject an attempt.
	Attempting to make a DAP ui this way is also now rejected.

	Regression tested on x86-64 Fedora 38.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-17  Tom Tromey  <tromey@adacore.com>

	Inline some ui_out methods
	I noticed a few ui_out methods that are just trivial wrappers.  This
	patch moves these to ui-out.h, as it seems like they should be
	inlineable.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-17  Dmitry Neverov  <dmitry.neverov@jetbrains.com>

	gdb/symtab: use symbol name matcher for all segments in a qualified name

2024-05-17  Dmitry Neverov  <dmitry.neverov@jetbrains.com>

	gdb/symtab: compute match_type outside the loop
	It will be used for all segments in a qualified name,
	not only the last one.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-17  Dmitry Neverov  <dmitry.neverov@jetbrains.com>

	gdb/symtab: reuse last segment lookup name info by creating it outside the loop

2024-05-17  Dmitry.Neverov  <dmitry.neverov@jetbrains.com>

	gdb/symtab: check name matches before expanding a CU
	The added check fixes the case when an unqualified lookup
	name without template arguments causes expansion of many CUs
	which contain the name with template arguments.

	This is similar to what dw2_expand_symtabs_matching_symbol does
	before expanding the CU.

	In the referenced issue the lookup name was wxObjectDataPtr and many
	CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused
	their expansion and the lookup took around a minute. The added check
	helps to avoid the expansion and makes the symbol lookup to return in
	a second or so.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	include, libctf: add a bunch of documentation to ctf-api.h
	Hopefully this library is no longer quite so much a "you have to look
	in the source to understand anything" library.

	No semantic changes, though some functions have been moved around for
	clarity.

	include/
		ctf-api.h: Add comments.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix leak of entire dict when dict opening fails
	Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount
	loops") ctf_dict_close has only freed anything if the refcount on entry
	to the function is precisely 1.  >1 obviously just decrements the
	refcount, but the linker machinery can sometimes cause freeing to recurse
	from a dict to another dict and then back to the first dict again, so
	we interpret a refcount of 0 as an indication that this is a recursive call
	and we should just return, because a caller is already freeing this dict.

	Unfortunately there is one situation in which this is not true: the bad:
	codepath in ctf_bufopen entered when opening fails.  Because the refcount is
	bumped only at the very end of ctf_bufopen, any failure causes
	ctf_dict_close to be entered with a refcount of zero, and it frees nothing
	and we leak the entire dict.

	The solution is to bump the refcount to 1 right before freeing... but this
	codepath is clearly delicate enough that we need to properly validate it,
	so we add a test that uses malloc interposition to count allocations and
	frees, creates a dict, writes it out, intentionally corrupts it (by setting
	a bunch of bytes after the header to a value high enough that it is
	definitely not a valid CTF type kind), then tries to open it again and
	counts the malloc/free pairs to make sure they're matched.  (Test run only
	on *-linux-gnu, because malloc interposition is not a thing you can rely
	upon working everywhere, and this test is not arch-dependent so if it
	passes on one arch it can be assumed to pass on all of them.)

	libctf/
		* ctf-open.c (ctf_bufopen): Bump the refcount on failure.
		* testsuite/libctf-regression/open-error-free.*: New test.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: test: add wrapper
	This .lk option lets you run the lookup program via a wrapper executable.
	For example, to run under valgrind and check for leaks (albeit noisily
	because of the libtool shell script wrapper):

	libctf/
		* testsuite/lib/ctf-lib.exp (run_lookup_test): Add wrapper.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: test: add host
	This .lk option lets you execute particular tests only on specific host
	architectures.

	libctf/
		* testsuite/lib/ctf-lib.exp (run_lookup_test): Add host.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: test: add lookup_link
	This .lk option lets you link the lookup program with extra libraries
	in addition to -lctf.

	libctf/
		* testsuite/lib/ctf-lib.exp (run_lookup_test): Add lookup_link.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: ctf_archive_iter: fix tiny leak
	If iteration fails because opening a dict has failed, ctf_archive_next does
	not destroy the iterator, so the caller can keep going and try to open other
	dicts further into the archive.  ctf_archive_iter just returns, though, so
	it should free the iterator rather than leaking it.

	libctf/
		* ctf-archive.c (ctf_archive_iter): Don't leak the iterator on
		failure.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: failure to open parent dicts that exist should be an error
	CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et
	al) attempts to be helpful and auto-open and import any needed parent dict
	in the same archive.  But if this fails, the error is not reported but
	simply discarded, and you silently get back a dict with no parent, that
	*you* suddenly have to remember to import.

	This is not helpful behaviour: if the parent is corrupted or we run out of
	memory or something, the caller is going to want to know!  Split it in two:
	if the dict cites a parent that doesn't exist at all (a lot of historic
	dicts name "PARENT" as their parent, even when they're not even children, or
	perhaps the parent dict is stored separately and you plan to manually
	associate it), we skip it as now, but if the import fails with an actual
	error other than ECTF_ARNNAME, return the error and fail the open.

	libctf/
		* ctf-archive.c (ctf_arc_import_parent):  Return failure if
	        parent opening fails for reasons other thnn nonexistence.
		(ctf_dict_open_sections): Adjust.

2024-05-17  Nick Alcock  <nick.alcock@oracle.com>

	libctf: typos
	Some functions were renamed without the comments catching up.

	libctf/
		* ctf-open.c (upgrade_types_v1): Fix comment typos.

2024-05-17  Jan Beulich  <jbeulich@suse.com>

	aarch64: correct SVE2.1 ld2q (scalar plus scalar)
	It's opcode was wrong, as was e.g. easily visible from the inappropriate
	testcase expectation.

	aarch64: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate)
	Like their byte, half, word, and doubleword counterparts their
	immediates are multiples of 3 / 4 respectively.

2024-05-17  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Adjust DWARF CIE alignment factors
	Set DWARF2_CIE_DATA_ALIGNMENT (data alignment factors) to -8.
	It helps to save space.

	Data Alignment Factor
	A signed LEB128 encoded value that is factored out of all offset
	instructions that are associated with this CIE or its FDEs. This value
	shall be multiplied by the register offset argument of an offset
	instruction to obtain the new offset value.

2024-05-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-16  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: fix typo to use FP instead of BP
	gas/
		* gen-sframe.c (output_sframe_internal): Use BP instead of FP.

2024-05-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing terminator in Dwarf::_macro_unit
	When printing complaints with one of the execs from test-case
	gdb.dwarf2/macro-source-path.exp, we run into:
	...
	$ gdb -q -batch \
	    -iex "set complaints 100" \
	    macro-source-path-clang14-dw4-absolute-cwd-32 \
	    -ex "p main"
	During symbol reading: debug info runs off end of .debug_macro section \
	  [in module macro-source-path-clang14-dw4-absolute-cwd-32]
	$1 = {int ()} 0x4004b7 <main>
	...
	and readelf complains more specifically:
	...
	Contents of the .debug_macro section:

	  Offset:                      0
	  Version:                     5
	  Offset size:                 4
	  Offset into .debug_line:     0xe3

	 DW_MACRO_define - lineno : 0 macro : ONE 1
	 DW_MACRO_define_strp - lineno : 0 macro : THREE 3
	 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c
	 DW_MACRO_define - lineno : 1 macro : TWO 2
	 DW_MACRO_end_file
	readelf: Error: .debug_macro section not zero terminated
	...

	Fix this by adding the missing terminator in Dwarf::_macro_unit.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused includes in objfiles.{c,h}
	Remove some includes reported as unused by clangd.

	Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a

2024-05-16  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	gdb, testsuite: Handle unused compiler option fdiagnostics-color=never.
	The 'univeral_compile_options' in gdb.exp file only verifies the support
	of '-fdiagnostics-color=never' for the "C" source file.  So while running
	tests with assembly source file (.s), many of them are not able to run
	on icx/clang compilers because '-fdiagnostics-color=never' option is not
	supported.  This problem is not seen for the ".S" assembly source files so
	these files are not handled separately.  After this change, this function
	is split into multiple functions to check the support for different type
	of sources individually.

	Before this change, in the case of clang and ICX compiler, this error is
	shown for assembly source files (.s):

	'''
	icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o
	amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300)

	icx: warning: argument unused during compilation: '-fdiagnostics-color=never'
	[-Wunused-command-line-argument]

	gdb compile failed, icx: warning: argument unused during compilation:
	'-fdiagnostics-color=never' [-Wunused-command-line-argument]

	UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare
	'''

	Similarly this error is shown for the clang compiler:

	'''
	clang  -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0
	-o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s

	clang: warning: argument unused during compilation:
	 '-fdiagnostics-color=never' [-Wunused-command-line-argument]
	'''

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: define type aliases for `fork_inferior()` callbacks
	The `fork_inferior()` function accepts multiple callbacks, making its
	signature a bit hard to read.  Define some type aliases to make it a bit
	clearer.  Use function view for all, while at it.

	Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb: initialize packet_result::m_textual_err_msg
	When building GDB with -O2 and --enable-ubsan, I get some random errors
	in the packet_result self test:

	  /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool'

	This happens because packet_result::m_textual_err_msg is uninitialized
	when using the second constructor.  When such a packet_result object
	gets copied, an invalid value for m_textual_err_msg (a bool field) is
	loaded, which triggers ubsan.

	Avoid this by initializing m_textual_err_msg.

	Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused include in infcmd.c
	clangd reports this header as unused.

	Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b

2024-05-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused includes from progspace.{c,h}
	Remove some include files reported as unused by clangd.

	Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a

2024-05-16  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: bump black version to 24.4.2
	Run `pre-commit autoupdate`, this is the outcome.  There is no change in
	formatting of Python files.

	Change-Id: I79c221af1b2192f866a344ab17d6199b137371cb

2024-05-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move lm_info to solib in dsbt_current_sos
	Commit 8971d2788e79 ("gdb: link so_list using intrusive_list")
	mistakenly removed the line that moves the lm_info unique pointer to
	sop->lm_info, probably due to a bad conflict resolution.  Restore that
	line.

	Unfortunately, this code is only used for TI C66, which is not widely
	tested (if used at all).

	Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Victor Do Nascimento  <vicdon01@e133397.arm.com>

	aarch64: fp8 convert and scale - add sme2 insn variants
	Add the SME2 variant of the FP8 convert and scale
	instructions, enabled at assembly-time using the `+sme2+fp8'
	architectural extension flag.  More specifically, support is
	added for the following instructions:

	Multi-vector floating-point convert from FP8 to
	BFloat16 (in-order):
	-----------------------------------------------

	  - bf1cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
	  - bf2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B

	Multi-vector floating-point convert from FP8 to
	deinterleaved BFloat16:
	-----------------------------------------------

	  - bf1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
	  - bf2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B

	Multi-vector floating-point convert from BFloat16
	to packed FP8 format:
	-------------------------------------------------

	  - bfcvt <Zd>.B, { <Zn1>.H-<Zn2>.H }

	Multi-vector floating-point convert from FP8 to
	half-precision (in-order):
	-----------------------------------------------

	  - f1cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
	  - f2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B

	Multi-vector floating-point convert from FP8 to
	deinterleaved half-precision:
	-----------------------------------------------

	  - f1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
	  - f2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B

	Multi-vector floating-point convert from half-precision
	to packed FP8 format:
	-------------------------------------------------------

	fcvt_2h

	Multi-vector floating-point convert from single-precision
	to packed FP8 format:
	---------------------------------------------------------
	fcvt_4s

	Multi-vector floating-point convert from single-precision
	to interleaved FP8 format:
	---------------------------------------------------------

	  - fcvtn <Zd>.B, { <Zn1>.S-<Zn4>.S }

	Multi-vector floating-point adjust exponent by vector:
	------------------------------------------------------

	  - fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
		   <Zm>.H
	  - fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
		   <Zm>.S
	  - fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
		   <Zm>.D

	Multi-vector floating-point adjust exponent:
	--------------------------------------------

	  - fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
		   { <Zm1>.H - <Zm2>.H }
	  - fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
		   { <Zm1>.S - <Zm2>.S }
	  - fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
		   { <Zm1>.D - <Zm2>.D }

2024-05-16  Victor Do Nascimento  <vicdon01@e133397.arm.com>

	aarch64: fp8 convert and scale - add sve2 insn variants
	Add the SVE2 variant of the FP8 convert and scale instructions,
	enabled at assembly-time using the `+sve2+fp8' architectural
	extension flag.  More specifically, support is added for the
	following instructions:

	FP8 convert to BFloat16 (bottom/top):
	-------------------------------------

	  - bf1cvt Z<d>.H, Z<n>.B
	  - bf2cvt Z<d>.H, Z<n>.B
	  - bf1cvtlt Z<d>.H, Z<n>.B
	  - bf2cvtlt Z<d>.H, Z<n>.B

	FP8 convert to half-precision (bottom/top):
	-------------------------------------------

	  - f1cvt Z<d>.H, Z<n>.B
	  - f2cvt Z<d>.H, Z<n>.B
	  - f1cvtlt Z<d>.H, Z<n>.B
	  - f2cvtlt Z<d>.H, Z<n>.B

	BFloat16/half-precision convert, narrow and
	interleave to FP8:
	-------------------------------------------

	  - bfcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }
	  - fcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }

	Single-precision convert, narrow and interleave
	to FP8 (bottom/top):
	-----------------------------------------------

	  - fcvtnb Z<d>.B, { Z<n>1.S - Z<n>2.S }
	  - fcvtnt Z<d>.B, { Z<n>1.S - Z<n>2.S }

2024-05-16  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: fp8 convert and scale - Add advsimd insn variants
	Add the advanced SIMD variant of the FP8 convert and scale
	instructions, enabled at assembly-time using the `+fp8'
	architectural extension flag.  More specifically, support is
	added for the following instructions:

	FP8 convert to BFloat16 (vector):
	---------------------------------

	  - bf1cvtl V<d>.8H, V<n>.8B
	  - bf2cvtl V<d>.8H, V<n>.8B
	  - bf1cvtl2 V<d>.8H, V<n>.16B
	  - bf2cvtl2 V<d>.8H, V<n>.16B

	FP8 convert to half-precision (vector):
	---------------------------------------

	  - f1cvtl V<d>.8H, V<n>.8B
	  - f2cvtl V<d>.8H, V<n>.8B
	  - f1cvtl2 V<d>.8H, V<n>.16B
	  - f2cvtl2 V<d>.8H, V<n>.16B

	Single-precision to FP8 convert and narrow (vector):
	----------------------------------------------------

	  - fcvtn V<d>.8B, V<n>.4S, V<m>.4S
	  - fcvtn2 V<d>.16B, V<n>.4S, V<m>.4S

	Half-precision to FP8 convert and narrow (vector):
	--------------------------------------------------

	  - fcvtn V<d>.8B, V<n>.4H, V<m>.4H
	  - fcvtn V<d>.16B, V<n>.8H, V<m>.8H

	Floating-point adjust exponent by vector:
	-----------------------------------------

	  - fscale V<d>.4H, V<n>.4H, V<m>.4H
	  - fscale V<d>.8H, V<n>.8H, V<m>.8H
	  - fscale V<d>.2S, V<n>.2S, V<m>.2S
	  - fscale V<d>.4S, V<n>.4S, V<m>.4S
	  - fscale V<d>.2d, V<n>.2d, V<m>.2d

2024-05-16  Victor Do Nascimento  <vicdon01@e133397.arm.com>

	aarch64: fp8 convert and scale - add feature flags and related structures

2024-05-16  Pedro Alves  <pedro@palves.net>

	Stop 'configure --enable-threading' if std::thread doesn't work
	Currently, if you configure gdb with explicit --enable-threading, but
	then configure detects std::thread does not work, configure silently
	disables threading support and continues configuring.

	This patch makes that scenario cause a configuration error, like so:

	 $ /home/pedro/gdb/src/configure --enable-threading && make
	 ...
	 configure: error: std::thread does not work; disable threading
	 make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1
	 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads'
	 make: *** [Makefile:1041: all] Error 2
	 $

	Additionally, if you don't explicitly pass --enable-threading, and
	std::thread does not work, we will now get a warning (and the build
	continues):

	 $ /home/pedro/gdb/src/configure && make
	 ...
	 configure: WARNING: std::thread does not work; disabling threading
	 ...

	This is similar to how we handle --enable-tui and missing curses.  The
	code and error/warning messages were borrowed from there.

	Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: add SPMU feature and its associated registers

2024-05-16  Nick Clifton  <nickc@redhat.com>

	Move assembler "IRP \+" test into a separate file.  Add XFAILs for targets that do not support it.

2024-05-16  Richard Earnshaw  <rearnsha@arm.com>

	arm: remove incorrect handling of FP bignums in move_or_literal_pool
	This hunk of code in move_or_literal_pool just looks wrong, but I
	can't find a testcase that will tickle it to prove it.  It looks a bit
	like it was intended to catch cases where a bignum contained a
	floating-point value, but there were a number of problems with it.

	- It tested X_add_number == -1, but an FP bignum is indicated by any
	  value <= 0.
	- It converted the floating-point value to extended precision, but
	  that's not used on Arm beyond the legacy FPA code.  No attempt was
	  made to match the FP value to the intended memory/mov operation.

	Since I can't construct a viable testcase, I've just removed the existing
	code and made the function error out in this case: this seems more sensible
	than generating wrong code or trying to write something more complex that
	can't be tested anyway.

2024-05-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assembly
	Add support for DW_MACRO_define_strp in dwarf assembly, and use it in
	test-case gdb.dwarf2/macro-source-path.exp.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-16  Alan Modra  <amodra@gmail.com>

	Fix FAIL: macros altmacro
	spu-elf and z80-coff fail this test due to "def" being a pseudo-op.
	tic30-unknown-coff fails it due to '#' not starting comments.

		* testsuite/gas/macros/altmacro.s: Use /* */ comments.  Rename
		DEF to EDF.

2024-05-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-15  Fangrui Song  <maskray@gcc.gnu.org>

	gas: Fix \+ expansion for .irp and .irpc
	.irp and .irpc receive a null macro_entry.  \+ causes a crash after the
	recent \+ support.  Restore the previous behavior.

2024-05-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Add sysreg features to +d128 dependencies
	We should revisit sysreg feature enablement and dependencies in future, but
	this change should help until then.

	OK for master?

2024-05-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Add simd dependency to +sha2
	This matches the existing behaviour in GCC and LLVM, and also the current
	documentation.

	OK for master?

2024-05-15  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: testsuite: share test utils macros and use them
	This patch rewrites assembly tests to use utils macros declared in
	sysreg-test-utils.inc. Some tests were adapted to use the new macro
	rw_sys_reg.

	aarch64: testsuite: reorder write and read to match macro order
	This patch aims at grouping write and read for a same system register
	one after another so that the diff for the macro replacement does not
	generate too much noise.

	aarch64: testsuite: use same regs for read and write tests
	This patch aims at making easier to replacement of read and write
	instructions to system registers by a macro that will use the same
	registers for read and write.

	aarch64: testsuite: replace instruction addresses by regex
	This patch removes the instruction addresses from the objdump's expected
	output (.d files). The intended benefit from this clean-up is to allow to
	swap lines around more easilly, and removes the noise of patches that add,
	remove or reorder instructions.

2024-05-15  Tom de Vries  <tdevries@suse.de>

	[binutils/readelf] Fix handling of DW_MACRO_define_strx in dwo file
	When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we
	run into:
	...
	 DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets section>
	...

	Fix this in display_debug_macro by passing the correct dwo argument to a
	fetch_indexed_string call.

	That works fine for readelf -w, with with readelf -wm we have:
	...
	 DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets.dwo section>
	...

	Fix this in display_debug_macro by doing load_debug_section_with_follow for
	str_dwo / str_index_dwo sections instead of str / str_index sections when
	handling .debug_macro.dwo.

	PR 31735

2024-05-15  Tom de Vries  <tdevries@suse.de>

	[binutils/readelf] Fix printing of dwarf4 .debug_str_offsets.dwo
	When compiling a hello world with dwarf4 split dwarf:
	...
	$ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA
	...
	we have in a-hello.s these three initial entries in .debug_str_offsets:
	...
		.section        .debug_str_offsets.dwo,"e",@progbits
		.4byte  0       // indexed string 0x0: short int
		.4byte  0xa     // indexed string 0x1: /home/vries/binutils
		.4byte  0x1f    // indexed string 0x2: main
	...
	but "readelf -ws a.out" starts at the third entry:
	...
	Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo):

	    Length: 0x30
	       Index   Offset [String]
	           0 00000000  main
	...

	This is a regression since commit 407115429b3 ("Modified changes for
	split-dwarf and dwarf-5."), which introduced a variable
	debug_str_offsets_hdr_len in display_debug_str_offsets.

	Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case.

	PR 31734

2024-05-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-15  Joseph Faulls  <Joseph.Faulls@imgtec.com>

	RISC-V: Search for mapping symbols from the last one found
	With previous behaviour, multiple mapping symbols within the same
	function would result in all the mapping symbols being searched.
	This could slow down disassembly dramatically.

	Multiple mapping symbols within a function can be a result of encoding
	instructions as data, like sometimes seen in random instruction
	generators.

	opcodes/ChangeLog:

		* riscv-dis.c (riscv_search_mapping_symbol): Use last mapping
		symbol if it exists.

2024-05-14  Tom Tromey  <tom@tromey.com>

	Add spaceship operator to cp-name-parser.y
	While debugging gdb, I saw this:

	During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >'

	This happens because cp-name-parser.y does not handle the spaceship
	operator.  This patch implements this.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Allow function types as template parameters in name canonicalizer
	This adds function types as template parameters in the C++ name
	canonicalizer.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Implement C++14 numeric separators
	C++14 allows the use of the apostrophe as a numeric separator; that
	is, "23000" and "23'000" represent the same number.  This patch
	implements this for gdb's C++ parser and the C++ name canonicalizer.

	I did this unconditionally for all C variants because I think it's
	unambiguous.

	For the name canonicalizer, there's at least one compiler that can
	emit constants with this form, see bug 30845.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Fix C++ canonicalization of hex literals
	Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to
	different things.  I think it's nicer for them to be the same.
	Differences between types can be done using suffixes like "ll" and "u"
	-- it's not really possible to implement C++ rules in the
	canoncalizer, because no gdbarch is available.  Possibly gdb should
	even drop the type here and just represent all integers the same way
	in names.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Remove some unnecessary allocations from cpname_state::parse_number
	cpname_state::parse_number allocates nodes for various types and then
	only uses one of them.  This patch reduces the number of allocations
	by not performing the unnecessary ones.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Fix C++ name canonicalizations of character literals
	The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should
	canonicalize to the same string, but currently they do not -- the
	former remains unchanged and the latter is transformed to
	"void C<(char)'\001'>::m()".

	This patch fixes the bug and also adds some unit tests.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Change storage of demangle_component
	This changes demangle_component objects to be stored on the obstack
	that is part of demangle_info.  It also arranges for a demangle_info
	object to be kept alive by cp_merge_demangle_parse_infos.  This way,
	other data on the obstack can be kept while an "outer" demangle_info
	needs it.

	Acked-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Clean up demangle_parse_info
	This changes demangle_parse_info to use inline initializers and to
	remove some manual memory management.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tom@tromey.com>

	Allow initialization functions in .y files
	If you add an initialization function to a .y file, it will not show
	up in init.c, because if the yacc output is in the build tree, it
	won't be found.

	This patch changes the Makefile to be more robust in this situation.

2024-05-14  Tom Tromey  <tom@tromey.com>

	Remove test code from cp-name-parser.y
	This removes the current test 'main' from cp-name-parser.y.  There
	aren't any tests using this, and nowadays it would be better as a unit
	test.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-05-14  Tom Tromey  <tromey@adacore.com>

	Disallow trailing whitespace in docstrings
	This patch changes the docstring self-test to verify that there is no
	trailing whitespace at the end of lines.  A few existing docstrings
	had to be updated.

2024-05-14  Tom Tromey  <tom@tromey.com>

	Remove fflush call from tui_refresh_cmd_win
	tui_refresh_cmd_win calls fflush, but there's a comment explaining
	that the reason for the call is unknown.  This patch removes the call.
	I don't think it can be useful, since gdb doesn't generally use stdout
	in this way -- only through ui_file.

2024-05-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: don't delete *.pod files too early
	When doing 'make -C gdb/doc man' to build the man pages, I noticed
	that the outputs were being rebuilt each time the make command was
	rerun, even when the input files hadn't changed.

	This was caused by this commit:

	  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
	  Date:   Fri Apr 12 17:47:20 2024 +0100

	      gdb/doc: use silent-rules.mk in the Makefile

	Which split the generation of the .pod file from the actual creation
	of the man page file.  Prior to this split it was OK to delete the
	.pod file at the end of the recipe, the rule depending on the .texi
	input file, and output was the .1 or .5 man page file.

	Now however, with the split, the man page creation depends on the .pod
	file, if we delete this after creating the .1 or .5 man page file then
	the next time we run 'make' the .pod file is missing and is
	regenerated, which in turn triggers the regeneration of the man page
	file.

	Fix this by leaving the .pod file around, and only cleaning up these
	files in the 'mostlyclean' target.

	Which leads to a second problem, the POD_FILE_TMPS is not created
	correctly, so we don't actually clean up the .pod files!  This too is
	fixed in this commit.

	After this commit running 'make -C gdb/doc man' will build the manual
	pages the first time, and each subsequent run will do nothing.

	Running 'make -C gdb/doc mostlyclean' will now delete the .pod files.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flags
	While working on another patch I needed to pass -Wl,-soname,NAME as a
	compiler flag.  I initially looked for other tests that did this, and
	found a few examples, so I copied what they did.

	But when I checked the gdb.log file I noticed that we were actually
	getting -Wl,-soname passed twice.

	I tracked the repeated option to 'proc gdb_compile_shlib_1' in
	lib/gdb.exp.  It turns out that we always add -Wl,-soname when
	compiling a shared library.

	Here's an example of a build command from gdb.base/prelink.exp:

	  builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
	    /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \
	    -fdiagnostics-color=never -shared -g \
	    -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \
	    -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so

	Notice that '-Wl,-soname,prelink.so' is repeated.

	I believe that all of the places where tests add '-Wl,-soname,NAME' as
	a build option, are unnecessary.

	In this commit I propose we remove them all.

	As part of this change I've switched from calling gdb_compile_shlib
	directly, to instead call build_executable and adding the 'shlib'
	flag.

	I've tested with gcc and clang and see no changes in the test results
	after this commit.  All the compile commands still have -Wl,-soname
	added, but now it's only added once, from within lib/gdb.exp.

	There should be no change in what is tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-14  Pali Roh?r  <pali@kernel.org>

	Improve objdump -p output of PE Import and Export Tables
	  PR 31738

2024-05-14  Jason Merrill  <jason@redhat.com>

	Adjust C++ destructor type tests
	In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
	parameter from destructors of classes with no virtual bases; Linaro's CI
	informed me that the gdb testsuite needs to be adjusted to match.

	Teested against GCC 13.2 and GCC 15 trunk.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-05-14  Nick Clifton  <nickc@redhat.com>

	Fix gas's 'macro count' test for various targets

2024-05-14  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix Segmentation Fault in AIX during multi process debugging.
	Due to the recent commit in aix-thread.c, we see a segmentation fault
	in AIX while debugging multiple process involving multiple threads.

	One example is a thread that can fork. The GDB output in AIX for the same is

	Reading symbols from //gdb_tests/multi-thread-fork...
	(gdb) set detach-on-fork off
	(gdb) r
	Starting program: /gdb_tests/multi-thread-fork
	[New Thread 258 (tid 67110997)]
	[New Thread 515 (tid 127404289)]
	[New inferior 2 (process 16580940)]
	Hello from Parent!
	[process 16580940 exited]
	[New inferior 3 (process 14549318)]
	Hello from Parent!
	[process 14549318 exited]
	Fatal signal: Segmentation fault
	----- Backtrace -----

	This is because in sync_threadlists () in aix-thread.c there when we
	delete threads in unknown state we iterate through all the threads.

	When we have one or more threads with the same user thread ID but of different
	process then we delete a wrong thread. Since we just check only the pdtid
	in in_queue_threads.count (priv->pdtid) == 0 this happened.

	This patch is a fix for the same.

	The output after we apply this patch is:
	Reading symbols from //gdb_tests/multi-thread-fork...
	(gdb) set detach-on-fork off
	(gdb) r
	Starting program: /gdb_tests/multi-thread-fork
	[New Thread 258 (tid 75565441)]
	[New Thread 515 (tid 63244397)]
	[New inferior 2 (process 10813892)]
	Hello from Parent!
	[New inferior 3 (process 19005888)]
	Hello from Parent!

	Thread 1.1 received signal SIGINT, Interrupt.
	0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
	(gdb) info threads
	  Id   Target Id                             Frame
	* 1.1  Thread 1 (tid 66062355) ([running])   0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
	  1.2  Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
	  1.3  Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
	2.1  Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
	  3.1  Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
	(gdb) q
	A debugging session is active.

2024-05-14  Richard Earnshaw  <rearnsha@arm.com>

	arm: update documentation for removal of the Maverick extension
	Finally, update the documentation and add a NEWS item.

	arm: remove Maverick support from BFD.
	Remove the handling of Maverick from BFD.  Where appropriate we handle
	legacy code by mapping ep9312 onto Armv4t.

2024-05-14  Richard Earnshaw  <rearnsha@arm.com>

	arm: opcodes: remove Maverick disassembly.
	Remove the patterns to match Maverick co-processor instructions from
	the disassembly tables.

	This required fixing a couple of tests in the assembler testsuite
	where we, probably incorrectly, disassembled generic co-processor
	instructions as a Maverick instruction (it particularly made no sense
	to do this for Armv6t2 in Thumb state).

2024-05-14  Richard Earnshaw  <rearnsha@arm.com>

	arm: binutils: drop Maverick support.
	Remove the decoding of the Maverick flag from readelf.

	arm: remove Maverick support from the assembler.
	Delete all the Maverick instructions and register handling from the
	assembler.  We continue to recognize -mcpu=ep9312, but treat it as an
	alias for arm920t.  We no-longer recognize -mfpu=maverick.

	arm: remove tests for Maverick FPU extensions
	Before removing the code itself, remove the tests that will no-longer
	apply.

2024-05-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-13  Nick Clifton  <nickc@redhat.com>

	Add new assembler macro pseudo-variable \+ which counts the number of times a macro has been invoked.

2024-05-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp
	When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide
	container, I run into:
	...
	temp/$pid/static-libc.c: In function 'main':
	temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function
	 returning void [-Wreturn-mismatch]
	    2 |                void main (void) { return 0; }
	      |                                          ^
	  ...
	UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link
	...

	Fix this by changing the return type to int.

	Tested on x86_64-linux.

2024-05-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-10  Tom Tromey  <tromey@adacore.com>

	Change gdbarch_inner_than to return bool
	A recent patch from Andrew pointed out that gdbarch_inner_than returns
	'int', while it should really return 'bool'.

	Approved-By: Pedro Alves <pedro@palves.net>

2024-05-10  Tom Tromey  <tom@tromey.com>

	Remove tui_refresh_all
	This removes tui_refresh_all.  There is only a single caller,
	tui_refresh_all_win, so inlining the code there simplifies gdb at no
	cost.

	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-10  Tom Tromey  <tromey@adacore.com>

	Add symbol, line, and location to DAP disassemble result
	The DAP spec allows a number of attributes on the resulting
	instructions that gdb currently does not emit.  A user requested some
	of these, so this patch adds the 'symbol', 'line', and 'location'
	attributes.  While the spec lets the implementation omit 'location' in
	some cases, it was simpler in the code to just always emit it, as then
	no extra tracking was needed.

	Implement tp_richcompare for gdb.Block
	I noticed that two gdb.Block objects will never compare as equal with
	'=='.  This patch fixes the problem by implementing tp_richcompare, as
	was done for gdb.Frame.

	Simplify DAP make_source callers
	A couple callers of make_source call basename by hand.  Rather than
	add another caller like this, I thought it would be better to put this
	ability into make_source itself.

	Remove FIXME from DAP
	This patch removes one of the few DAP "FIXME" comments.  This
	particular comment is already covered by PR dap/31036.

2024-05-10  Tom Tromey  <tromey@adacore.com>

	Pass stream to remote_console_output
	I noticed that remote_target::rcmd did not pass its ui_file argument
	down to remote_console_output.  This patch fixes this oversight.

	Tested-By: Ciaran Woodward <ciaranwoodward@xmos.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-10  Nick Clifton  <nickc@redhat.com>

	Add --section-ordering command line option to the bfd linker.

2024-05-10  Alan Modra  <amodra@gmail.com>

	Re: PR31692, objdump fails .debug_info size check
	The fuzzers found a hole.  bfd_section_size_insane doesn't check
	!SEC_HAS_CONTENTS sections against file size for obvious reasons,
	which allows fuzzed debug sections to be stupidly large.  Real debug
	sections of course always have contents.

		PR 31692
		* objdump.c (load_specific_debug_section): Don't allow sections
		without contents.

2024-05-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: add gdbarch_stack_grows_down function
	In another patch I'm working on I needed to ask: does the stack grow
	down, or grow up?

	Looking around I found in infcall.c some code where we needed to ask
	the same question, what we do there is ask:

	  gdbarch_inner_than (gdbarch, 1, 2)

	which should do the job.  However, I don't particularly like copying
	this, it feels like we're asking something slightly different that
	just happens to align with the question we're actually asking.

	I propose adding a new function `gdbarch_stack_grows_down`.  This is
	not going to be a gdbarch method that can be overridden, instead, this
	will just call the gdbarch_inner_than function.  We already have some
	gdbarch methods like this, checkout arch-utils.c for examples.

	I think it's now clearer what we're actually doing.

	A new self-test ensures that all architectures have a stack that
	either grows down, or grows up.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-10  Nick Clifton  <nickc@redhat.com>

	Add missing \n to the end of warning messages in dwarf.c.
	  PR 31722

2024-05-10  Pedro Alves  <pedro@palves.net>

	gdb sim testing, set gdb_protocol to "sim"
	Bernd reported that when testing with riscv-unknown-elf target using
	the simulator, before commit c7a2ee649115 ("gdb_is_target_native ->
	gdb_protocol_is_native"), he had:

	 PASS: gdb.base/load-command.exp: probe for target native
	 PASS: gdb.base/load-command.exp: check initial value of the_variable
	 PASS: gdb.base/load-command.exp: manually change the_variable
	 PASS: gdb.base/load-command.exp: check manually changed value of the_variable
	 PASS: gdb.base/load-command.exp: reload: re-load binary
	 PASS: gdb.base/load-command.exp: reload: check initial value of the_variable

	and now:

	 UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command

	The problem is that the sim board/config isn't setting gdb_protocol
	anywhere, so gdb_protocol_is_native returns true.

	This commit fixes it by making gdb/testsuite/config/sim.exp set
	gdb_protocol to "sim".

	Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
	Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
	Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a

2024-05-10  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)
	In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register
	more robust") I added this code in unwind_infopy_add_saved_register:
	...
	  if (value->optimized_out () || !value->entirely_available ())
	...
	which may throw c++ exceptions.

	This needs to be caught and transformed into a python exception.

	Fix this by using GDB_PY_HANDLE_EXCEPTION.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")

2024-05-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-09  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	sim: riscv: Fix build issue due to recent binutils commit
	The commit c144f6383379 removed INSN_CLASS_A and
	added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead,
	which broke the build of the sim for riscv targets.

	Fix that by using the new INSN_CLASS types.

	Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.")

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-09  Eli Zaretskii  <eliz@gnu.org>

	Fix typo in gdb/README.
	Patch from Tiezhu Yang <yangtiezhu@loongson.cn>.

2024-05-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: convert address_in_mem_range to mem_range::contains
	Replace the global function address_in_mem_range with the member
	function mem_range::contains.  The implementation of the function
	doesn't change.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: add a new build_id_equal function
	Add two versions of a new function build_id_equal which can be used to
	compare build-ids, then make use of these functions in GDB.  It seems
	better to have a specific function for the task of comparing build-ids
	rather than having a length check followed by a memcmp call.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix hard-coded bash path in gprofng
	When running 'make check', the default gprofng test suite creates a
	shell script for which it used a hardcoded shebang of '/usr/bin/bash'
	this script would not run if bash is in a different location, like
	/bin/bash

	This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the
	installation path of bash is detected at configuration time. The
	configuration is propagated to the runtest command line where it is
	needed.

2024-05-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: use silent-rules.mk in the Makefile
	Make use of silent-rules.mk when building the GDB docs.

	During review it was requested that there be more specific rules than
	just reusing the general 'GEN' rule everywhere in the doc/ directory,
	so I've added:

	  ECHO_DVIPS =    @echo "  DVIPS    $@";
	  ECHO_TEX =      @echo "  TEX      $@";
	  ECHO_PDFTEX =   @echo "  PDFTEX   $@";
	  ECHO_TEXI2DVI = @echo "  TEXI2DVI $@";
	  ECHO_MAKEHTML = @echo "  MAKEHTML $@";
	  ECHO_TEXI2POD = @echo "  TEXI2POD $@";
	  ECHO_TEXI2MAN = @echo "  TEXI2MAN $@";
	  ECHO_MAKEINFO = @echo "  MAKEINFO $@";

	Then I've made use of these new silent rules and added lots of uses of
	SILENT to reduce additional clutter.

	As the man page generation is done in two phases, first the creation
	of a .pod file, then the creation of the final man page file, I've
	restructured the man page rules.  Previously we had one rule for each
	of the 5 man pages.  I now have one general rule that will generate
	all of the 5 .pod files, then I have two rules that convert the .pod
	files into the final man pages.

	I needed two rules for the man page generation as some man pages match
	%.1 and some match %.5.  I could combine these by using the GNU Make
	.SECONDARYEXPANSION extension, but I think having two rules like this
	is probably clearer, and the duplication is minimal.

	Cleaning up the temporary .pod files is now moved into the
	'mostlyclean' target rather than being done as soon as the man page is
	created.

	I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like
	SILENT_FLAG, but is set to '-q' when in silent mode, this can be used
	with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to
	mean: only report errors.

	As with the rest of the GDB makefiles, I've only converted the
	"generation" rules to use silent-rules.mk, the install / uninstall
	rules are left unchanged.

	When looking at the 'diststuff' target, which generates the info and
	man pages, I noticed the recipe for this rule just deleted a temporary
	file.  As that temporary file is already cleaned up as part of the
	'clean' rule I've removed the deletion from the 'diststuff' target.

	There are still a few "generation" targets that produce output, there
	seems to be no flag to silence the 'tex' and 'pdftex' commands which
	some recipes use, I've not worried about these for now, e.g. the
	refcard.dvi and refcard.pdf targets still produce some output.

	Luckily, when doing a 'make all' in the gdb/ directory, we only build
	the info docs by default, and those rules are now nice and silent, so
	a complete GDB build is now looking nice and quiet by default.

	While working on this patch I noticed that 'make -j all-doc' doesn't
	work (reliably), this is a preexisting bug in the way that dvi/pdf
	targets are generated.  For example gdb.dvi and gdb.pdf both use the
	texi2dvi tool, which relies on temporary files to hold state.  If both
	these rules run in parallel then one (or both) of the recipes will
	fail.

	Luckily, the default docs target (all), which is what gets run when we
	do 'make all' in the gdb/ directory, doesn't build the dvi and pdf
	targets, so we're OK in that case.

	I've not tried to fix this problem in this commit as it already
	existed, and I don't want to do too much in one commit.  I mention it
	only because I ran into this issue while testing this commit.

2024-05-08  Guinevere Larsen  <blarsen@redhat.com>

	gdb: Change "list ." command's error when no debuginfo is available
	Currently, when a user tries to list the current location, there are 2
	different error messages that can happen, either:

	    (gdb) list .
	    No symbol table is loaded.  Use the "file" command.
	or
	    (gdb) list .
	    No debug information available to print source lines.

	The difference here is if gdb can find any symtabs at all or not, which
	is not something too important for end-users - and isn't informative at
	all. This commit changes it so that the error always says that there
	isn't debug information available, with these two variants:

	    (gdb) list .
	    Insufficient debug info for showing source lines at current PC (0x55555555511d).
	or
	    (gdb) list .
	    Insufficient debug info for showing source lines at default location.

	The difference now is if the inferior has started already, which is
	controlled by the user and may be useful.

	Unfortunately, it isn't as easy to differentiate if the symtab found for
	other list parameters is correct, so other invocations, such as "list +"
	still retain their original error message.

	Co-Authored-By: Simon Marchi <simark@simark.ca>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: more filename styling
	I spotted a few places in solib.c and build-id.c where we could apply
	file name styling.

	Other than the extra styling, there should be no user visible changes
	after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.tui/reread.exp
	Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because
	all_objfiles_removed triggers tui_display_main").

	When building with address sanitizer, and reverting the commit it triggers the
	heap-use-after-free.

	Tested on aarch64-linux.

	PR symtab/31697
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697

2024-05-08  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix AIX thread exit events not being reported and UI to show kernel thread ID.
	In AIX when a thread exits we were not showing that a thread exit event happened
	and GDB continued to keep the terminated threads.

	If we have terminated threads then the UI on info threads command will look like
	(gdb) info threads
	  Id   Target Id                                          Frame
	* 1    Thread 1 (tid 26607979, running)    0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
	  2    Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)

	If we see the frame is not getting displayed correctly.

	The reason for the same is that in AIX we were not managing thread states. In particular we do not know
	when a thread terminates.

	The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit.

	This patch is a fix to the same.

	Also certain UI is changed.

	On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information.

	[New Thread 258 (tid 32178533)]
	[New Thread 515 (tid 30343651)]
	[New Thread 772 (tid 33554909)]
	[New Thread 1029 (tid 24969489)]
	[New Thread 1286 (tid 18153945)]
	[New Thread 1543 (tid 30736739)]
	[Thread 258 (tid 32178533) exited]
	[Thread 515 (tid 30343651) exited]
	[Thread 772 (tid 33554909) exited]
	[Thread 1029 (tid 24969489) exited]
	[Thread 1286 (tid 18153945) exited]
	[Thread 1543 (tid 30736739) exited]

	and info threads will look like
	(gdb) info threads
	  Id   Target Id                           Frame
	* 1    Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)

	Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.

2024-05-08  Tom Tromey  <tom@tromey.com>

	Fix typo in binutils manual
	I happened to notice that the binutils manual has a typo in the name
	of a command-line option.

2024-05-08  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add PR ld/31710 tests
		PR ld/31710
		* testsuite/ld-elf/wrap.exp: Run ld/31710 tests.
		* testsuite/ld-elf/wrap2.h: New file.
		* testsuite/ld-elf/wrap2a.c: Likewise.
		* testsuite/ld-elf/wrap2b.c: Likewise.

2024-05-08  H.J. Lu  <hjl.tools@gmail.com>

	ld: Run --wrap tests only if supported
	Run --wrap tests with shared library only if -shared is supported.

		* testsuite/ld-elf/wrap.exp: Run --wrap tests with shared library
		only if -shared is supported.

2024-05-08  Nick Clifton  <nickc@redhat.com>

	Fix RELOC_FOR_GLOBAL_SYMBOLS macro so that it can cope with user defined symbols that start with __wrap_.
	  PR 31710

2024-05-08  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust
	On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register
	from non-FreeBSD target descriptions") I ran into:
	...
	FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \
	  backtrace when the unwind is broken at frame 5
	...

	What happens is the following:
	- the TestUnwinder from inline-frame-cycle-unwind.py calls
	  gdb.UnwindInfo.add_saved_register with reg == tpidruro and value
	  "<unavailable>",
	- pyuw_sniffer calls value->contents ().data () to access the value of the
	  register, which throws an UNAVAILABLE_ERROR,
	- this causes the TestUnwinder unwinder to fail, after which another unwinder
	  succeeds and returns the correct frame, and
	- the test-case fails because it's counting on the TestUnwinder to succeed and
	  return an incorrect frame.

	Fix this by checking for !value::entirely_available as well as
	valued::optimized_out in unwind_infopy_add_saved_register.

	Tested on x86_64-linux and arm-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	PR python/31437
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437

2024-05-08  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Support B, Zaamo and Zalrsc extensions.
	* https://github.com/riscv/riscv-b/tags
	Added standard B extension back, which implies Zba, Zbb and Zbs extensions.

	* https://github.com/riscv/riscv-zaamo-zalrsc/tags
	Splited standard A extension into two new extensions, Zaamo and Zalrsc.
	The A extension implies Zaamo and Zalrsc extensions.

	Not sure if we need to do the similar check as i and zicsr/zifencei.

	Passed riscv[32|64]-[elf/linux] binutils testcases.

	bfd/
		* elfxx-riscv.c (riscv_implicit_subsets): Added imply rules
		for A and B extensions.  The A implies Zaamo and Zalrsc, the
		B implies Zba, Zbb and Zbs.
		(riscv_supported_std_ext): Supported B extension with v1.0.
		(riscv_supported_std_z_ext): Supported Zaamo and Zalrsc with v1.0.
		(riscv_multi_subset_supports, riscv_multi_subset_supports_ext): Updated.
	include/
		* opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_A, Added
		INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC.
	opcodes/
		* riscv-opc.c (riscv_opcodes): Splited standard A extension into two
		new extensions, Zaamo and Zalrsc.
	gas/
		* testsuite/gas/riscv/march-imply-a.d: New testcase.
		* testsuite/gas/riscv/march-imply-b.d: New testcase.
		* testsuite/gas/riscv/attribute-01.d: Updated.
		* testsuite/gas/riscv/attribute-02.d: Updated.
		* testsuite/gas/riscv/attribute-03.d: Updated.
		* testsuite/gas/riscv/attribute-04.d: Updated.
		* testsuite/gas/riscv/attribute-05.d: Updated.
		* testsuite/gas/riscv/attribute-10.d: Updated.
		* testsuite/gas/riscv/mapping-symbols.d: Updated.
		* testsuite/gas/riscv/march-imply-g.d: Updated.
		* testsuite/gas/riscv/march-imply-unsupported.d: Updated.
		* testsuite/gas/riscv/march-ok-reorder.d: Updated.
	ld/
		* testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated.
		* testsuite/ld-riscv-elf/attr-merge-arch-02.d: Updated.
		* testsuite/ld-riscv-elf/attr-merge-arch-03.d: Updated.
		* testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Updated.

2024-05-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-07  Hannes Domani  <ssbssa@yahoo.de>

	Fix heap-use-after-free because all_objfiles_removed triggers tui_display_main
	Since gdb-10 there is a heap-use-after free happening if starting the
	target in TUI triggers a re-reading of symbols.

	It can be reproduced with:

	$ gdb -q -batch a.out -ex "tui enable" -ex "shell touch a.out" -ex start

	==28392== Invalid read of size 1
	==28392==    at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503)
	==28392==    by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641)
	==28392==    by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473)
	==28392==    by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150)
	==28392==    by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958)
	==28392==    by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970)
	==28392==    by 0x77120F: select_source_symtab() (source.c:319)
	==28392==    by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401)
	==28392==    by 0x807558: tui_display_main() (tui-winsource.c:55)
	==28392==    by 0x7937B5: clear_symtab_users(enum_flags<symfile_add_flag>) (functional:2464)
	==28392==    by 0x794F40: reread_symbols(int) (symfile.c:2690)
	==28392==    by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
	==28392==  Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd
	==28392==    at 0x4A0A430: free (vg_replace_malloc.c:446)
	==28392==    by 0x936B63: _obstack_free (obstack.c:280)
	==28392==    by 0x79541E: reread_symbols(int) (symfile.c:2579)
	==28392==    by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
	==28392==    by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735)
	==28392==    by 0x7DAB50: execute_command(char const*, int) (top.c:575)
	==28392==    by 0x5D2B43: command_handler(char const*) (event-top.c:552)
	==28392==    by 0x5D3A50: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:788)
	==28392==    by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259)
	==28392==    by 0x857B3F: rl_callback_read_char (callback.c:290)
	==28392==    by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195)
	==28392==    by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234)

	The problem is that tui_display_main is called by the all_objfiles_removed
	hook, which tries to access the symbol cache.
	This symbol cache is actually stale at this point, and would have been
	flushed immediately afterwards by that same all_objfiles_removed hook.

	It's not possible to tell the hook to call the observers in a specific
	order, but in this case the tui_all_objfiles_removed observer is actually
	not needed, since it only calls tui_display_main, and a 'main' can only
	be found if objfiles are added, not removed.

	So the fix is to simply remove the tui_all_objfiles_removed observer.

	The clearing of the source window (if symbols were removed by e.g. 'file'
	without arguments) still works, since this is done by the
	tui_before_prompt observer.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-07  Andrew Burgess  <aburgess@redhat.com>

	gdb/arch: assert that X86_XSTATE_MPX is not set for x32
	While rebasing this series[1] past this commit:

	  commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a
	  Date:   Wed Mar 20 04:13:18 2024 -0700

	      gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32

	I worried that there could be other paths that might result in an xcr0
	value which has X86_XSTATE_MPX set in x32 mode.  As everyone
	eventually calls amd64_create_target_description to build their target
	description, I figured we could assert in here that if X86_XSTATE_MPX
	is set then we should not be an x32 target, this will uncover any
	other bugs in this area.

	I'm not currently able to build/run any x32 binaries, so I have no way
	to test this, but the author of commit 4bb20a6244b7091 did test this
	series with that assert in place and didn't see any problems.

	[1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-05-07  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: convert have_ptrace_getregset to a tribool
	Convert the have_ptrace_getregset global within gdbserver to a
	tribool.  This brings the flag into alignment with the corresponding
	flag in GDB.

	The gdbserver have_ptrace_getregset variable is already used as a
	tribool, it just doesn't have the tribool type.

	In a future commit I plan to share more code between GDB and
	gdbserver, and having this variable be the same type in both code
	bases will make the sharing much easier.

	There should be no user visible changes after this commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-05-07  Andrew Burgess  <aburgess@redhat.com>

	gdbserver/ipa/x86: remove unneeded declarations
	Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no
	longer needed.  These are:

	  1. 'init_registers_amd64_linux' - the comment claims this function
	  is auto generated, but I don't believe that this is still the case.
	  Also the function is not used in this file,

	  2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any
	  more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but
	  neither are used in this file, so lets remove the declaration.

	The amd64 in-process-agent still builds fine after this commit.

	There should be no user visible changes after this commit.

	Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>

2024-05-07  Pedro Alves  <pedro@palves.net>

	gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch
	The code in gdb.base/watchpoint-running.exp that is trying to skip
	testing with hardware watchpoints also skips testing with software
	watchpoints if hardware watchpoints aren't supported by the target.
	This fixes it.

	Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba

2024-05-07  Pedro Alves  <pedro@palves.net>

	Remove gdb.base/watchpoint-running.exp leftover
	Remove accidentally leftover commented-out line from
	gdb.base/watchpoint-running.exp.

	Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697

2024-05-07  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lock
	A recent commit refactored with_rocm_gpu_lock:

	    commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e
	    Date:   Sat May 4 10:41:09 2024 +0200

	        [gdb/testsuite] Factor out proc with_lock

	        Factor out proc with_lock from with_rocm_gpu_lock, and move required procs
	        lock_file_acquire and lock_file_release to lib/gdb-utils.exp.

	This causes regressions in gdb.rocm/*.exp (as well as in downstream
	rocgdb).  The issue can be reproduced in the following minimal test:

	    load_lib rocm.exp
	    set foo hello
	    with_rocm_gpu_lock {
	        verbose -logs $foo
	    }

	The issue is that the body to execute under the lock is executed in the
	context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of
	in the context of the "original" caller.

	This patch adjusted with_rocm_gpu_lock to account for the new extra
	frame in the call stack between the caller of with_rocm_gpu_lock and
	where the code execution is triggered.

	Approved-By: Tom de Vries <tdevries@suse.de>

	Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe

2024-05-07  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix ld test failures caused by using instruction aliases
	Different versions of objdump may take different forms of output
	for instructions. Use -M no-aliases to avoid the failure of ld
	test cases caused by objdump using aliases.

2024-05-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-06  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix build issues with mingw toolchain
	With a x86_64-pc-mingw32 toolchain there is a build issue
	whether or not the --disable-threading option is used.
	The problem happens because _WIN32_WINNT is defined to 0x501
	before #include <mutex> which makes the compilation abort
	due to missing support for __gthread_cond_t in std_mutex.h,
	which is conditional on _WIN32_WINNT >= 0x600.

	Fix the case when --disable-threading is used, by only
	including <mutex> in gdb/complaints.c when STD_CXX_THREAD
	is defined.

	Additionally make the configure script try to #include <mutex>
	to automatically select --disable-threading when the header file
	is not able to compile.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach
	When running the testsuite on a system with kernel.yama.ptrace_scope set to 1,
	we run into attach failures.

	Fix this by recognizing "ptrace: Operation not permitted" in
	can_spawn_for_attach.

	Tested on aarch64-linux and x86_64-linux.

	Approved-By: Pedro Alves <pedro@palves.net>

2024-05-06  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Redo cast handling for indirection
	In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I
	introduced the behaviour that even though we have:
	...
	(gdb) p *a_loc ()
	'a_loc' has unknown return type; cast the call to its declared return type
	...
	we get:
	...
	(gdb) p (char)*a_loc ()
	$1 = 97 'a'
	...

	In other words, the unknown return type of a_loc is inferred from the cast,
	effectually evaluating:
	...
	(gdb) p (char)*(char *)a_loc ()
	...

	This is convient for the case that errno is defined as:
	...
	 #define errno (*__errno_location ())
	...
	and the return type of __errno_location is unknown but the macro definition is
	known, such that we can use:
	...
	(gdb) p (int)errno
	...
	instead of
	...
	(gdb) p *(int *)__errno_location ()
	...

	However, as Pedro has pointed out in post-commit review [1], this makes it
	harder to reason about the semantics of an expression.

	For instance, this:
	...
	(gdb) p (long long)*a_loc ()"
	...
	would be evaluated without debug info as:
	...
	(gdb) p (long long)*(long long *)a_loc ()"
	...
	but with debug info as:
	...
	(gdb) p (long long)*(char *)a_loc ()"
	...

	Fix this by instead simply erroring out for this case:
	...
	(gdb) p (char)*a_loc ()
	'a_loc' has unknown return type; cast the call to its declared return type
	...

	Tested on x86_64-linux.

	Approved-By: Pedro Alves <pedro@palves.net>

	[1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html

2024-05-06  Cui, Lili  <lili.cui@intel.com>

	x86: Drop using extension_opcode to encode vvvv register
	gas/ChangeLog:

	        * config/tc-i386.c (build_modrm_byte): Dropped the use of
	        extension_opcode to encode the vvvv register.
	        * testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases.
	        * testsuite/gas/i386/x86-64-sse2avx.s: Diito.

	opcodes/ChangeLog:

	        * i386-opc.tbl: Added DstVVVV to some extension_opcode instructions.
		* i386-tbl.h: Regenerated.

2024-05-06  Cui, Lili  <lili.cui@intel.com>

	x86: Drop SwapSources
	gas/ChangeLog:

	        * config/tc-i386.c (build_modrm_byte): Dropped the use of
		SWAP_SOURCES to encode the vvvv register.

	opcodes/ChangeLog:

	        * i386-opc.h (SWAP_SOURCES): Dropped.
	        (NO_DEFAULT_MASK): Adjusted the value.
	        (ADDR_PREFIX_OP_REG): Ditto.
	        (DISTINCT_DEST): Ditto.
	        (IMPLICIT_STACK_OP): Ditto.
	        (VexVVVV_SRC2): New.
	        * i386-opc.tbl: Dropped SwapSources and replaced its VexVVVV
		with Src1VVVV.
		* i386-tbl.h: Regenerated.

2024-05-06  Cui, Lili  <lili.cui@intel.com>

	x86: Use vexvvvv as the switch state to encode the vvvv register
	Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV.
	Src1VVVV means using VEX.vvvv encodes the first source register
	operand. The old logic did not check vexvvvv first, which made the
	logic here very complicated.

	gas/ChangeLog:

	        * config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV.
	        (build_modrm_byte): Used vexvvvv to encode the vvvv register.
	        (s_insn): Replaced 1 with Src1VVVV.

	opcodes/ChangeLog:

	        * i386-opc.h (VexVVVV_DST): Adjusted the value.
	        (Src1VVVV): New.
	        * i386-opc.tbl: Replaced part VexVVVV with Src1VVVV.
		* i386-tbl.h: Regenerated.

2024-05-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-04  Hannes Domani  <ssbssa@yahoo.de>

	Fix heap-use-after-free in index-cached with --disable-threading
	If threads are disabled, either by --disable-threading explicitely, or by
	missing std::thread support, you get the following ASAN error when
	loading symbols:

	==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68
	READ of size 1 at 0x614000002128 thread T0
	    #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163
	    #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601
	    #2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690
	    #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38

	0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8)
	freed by thread T0 here:
	    #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177
	    #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689
	    #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657
	    #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300

	It's happening because cooked_index_worker::wait always returns true in
	this case, which tells cooked_index::wait it can delete the m_state
	cooked_index_worker member, but cooked_index_worker::write_to_cache tries
	to access it immediately afterwards.

	Fixed by making cooked_index_worker::wait only return true if desired_state
	is CACHE_DONE, same as if threading was enabled, so m_state will not be
	prematurely deleted.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694
	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom Tromey  <tom@tromey.com>

	Remove dwarf2_per_objfile::adjust
	All the calls to dwarf2_per_objfile::adjust have been removed, so we
	can remove this function entirely.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261

2024-05-04  Tom Tromey  <tom@tromey.com>

	Remove call to dwarf2_per_objfile::adjust from read_attribute_value
	Currently, read_attribute_value calls dwarf2_per_objfile::adjust on
	any address.  This seems wrong, because the address may not even be in
	the text section.

	Luckily, this call is also not needed, because read_func_scope calls
	'relocate', which does the same work.

2024-05-04  Tom Tromey  <tom@tromey.com>

	Remove call to dwarf2_per_objfile::adjust from read_call_site_scope
	read_call_site_scope does not need to call 'adjust', because in
	general the call site is not a symbol address, but rather just the
	address of some particular call.

2024-05-04  Tom Tromey  <tom@tromey.com>

	Remove more calls to dwarf2_per_objfile::adjust
	As with the previous patch, this patch removes some calls to
	dwarf2_per_objfile::adjust.  These calls are not needed by the cooked
	indexer, as it does not create symbols or look up symbols by address.

	The call in dwarf2_ranges_read is similarly not needed, as it is only
	used to update an addrmap; and in any case I believe this particular
	call is only reached by the indexer.

2024-05-04  Tom Tromey  <tom@tromey.com>

	Remove call to dwarf2_per_objfile::adjust from ranges readers
	dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an
	address, leaving the result unrelocated.  However, this adjustment is
	only needed for text-section symbols -- it isn't needed for any sort
	of address mapping.  Therefore, these calls can be removed from
	read_addrmap_from_aranges and create_addrmap_from_gdb_index.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-04  Alan Modra  <amodra@gmail.com>

	bus error with fuzzed archive element
		* libbfd.c (bfd_mmap_local): Sanity check rsize against actual
		file offset and size, not an archive element offset and size.

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use unique portnum in parallel testing (check//% case)
	Make target check//% is the gdb variant of a similar gcc make target [1].

	When running tests using check//%:
	...
	$ cd build/gdb
	$ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp
	...
	we get:
	...
	$ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum
	2427
	$ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum
	2423
	...

	The problem is that there are two portnum files used in parallel.

	Fix this by:
	- creating a common lockdir build/gdb/testsuite.lockdir for make target
	  check//%,
	- passing this down to the runtests invocations using variable GDB_LOCK_DIR,
	  and
	- using GDB_LOCK_DIR in lock_dir.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31632
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632

	[1] https://gcc.gnu.org/install/test.html

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use unique portnum in parallel testing
	When instrumenting get_portnum using:
	...
	puts "PORTNUM: $res"
	...
	and running:
	...
	$ cd build/gdb
	$ make check-parallel -j2 TESTS=gdb.server/*.exp
	...
	we run into:
	...
	Running gdb.server/abspath.exp ...
	PORTNUM: 2345
	...
	and:
	...
	Running gdb.server/bkpt-other-inferior.exp ...
	PORTNUM: 2345
	...

	This is because the test-cases are run in independent runtest invocations.

	Fix this by handling the parallel case in get_portnum using:
	- a file $objdir/cache/portnum to keep the portnum variable, and
	- a file $objdir/cache/portnum.lock to serialize access to it.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Move gpu-parallel.lock to cache dir
	The lock directory returned by lock_dir is currently $objdir.

	It seems possible to leave a stale lock file that blocks progress in a
	following run.

	Fix this by using a directory that is guaranteed to be initially empty when
	using GDB_PARALLEL, like temp or cache.

	In gdb/testsuite/README I found:
	...
	cache in particular is used to share data across invocations of runtest
	...
	which seems appropriate, so let's use cache for this.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Factor out proc lock_dir
	In lib/rocm.exp we have:
	...
	set gpu_lock_filename $objdir/gpu-parallel.lock
	...

	This decides both the lock file name and directory.

	Factor out a new proc lock_dir that decides on the directory, leaving just:
	...
	set gpu_lock_filename gpu-parallel.lock
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Factor out proc with_lock
	Factor out proc with_lock from with_rocm_gpu_lock, and move required procs
	lock_file_acquire and lock_file_release to lib/gdb-utils.exp.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make portnum a persistent global
	When instrumenting get_portnum using:
	...
	    puts "PORTNUM: $res"
	...
	and running:
	...
	$ cd build/gdb
	$ make check TESTS=gdb.server/*.exp
	...
	we get:
	...
	Running gdb.server/target-exec-file.exp ...
	PORTNUM: 2345
	Running gdb.server/stop-reply-no-thread-multi.exp ...
	PORTNUM: 2345
	PORTNUM: 2346
	PORTNUM: 2347
	PORTNUM: 2348
	PORTNUM: 2349
	PORTNUM: 2350
	...

	So, while get_portnum does return increasing numbers in a single test-case, it
	restarts at each test-case.

	This is a regression since the introduction of persistent globals.

	Fix this by using "gdb_persistent_global portnum", such that we get:
	...
	Running gdb.server/target-exec-file.exp ...
	PORTNUM: 2345
	Running gdb.server/stop-reply-no-thread-multi.exp ...
	PORTNUM: 2346
	PORTNUM: 2347
	PORTNUM: 2348
	PORTNUM: 2349
	PORTNUM: 2350
	PORTNUM: 2351
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Factor out proc get_portnum
	In gdbserver_start, we have some code that determines what port number to use:
	...
	    # Port id -- either specified in baseboard file, or managed here.
	    if [target_info exists gdb,socketport] {
	       set portnum [target_info gdb,socketport]
	    } else {
	       # Bump the port number to avoid conflicts with hung ports.
	       incr portnum
	    }
	...

	Factor this out into a new proc get_portnum.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-05-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-03  Pedro Alves  <pedro@palves.net>

	Adjust gdb_continue_to_end for Windows
	On Cygwin, supposely single-threaded programs are always
	multi-threaded, due to the extra threads spawned by the Cygwin
	runtime.  Because of that, any gdb_continue_to_end call that doesn't
	specify "allow_extra" fails, like so:

	 (gdb) PASS: gdb.base/langs.exp: show language at main
	 continue
	 Continuing.
	 [Thread 16140.0x1fbc exited with code 0]
	 [Thread 16140.0x2458 exited with code 0]
	 [Thread 16140.0x3494 exited with code 0]
	 [Inferior 1 (process 16140) exited normally]
	 (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited)

	Similarly, with this simple program compiled with MinGW:

	 $ cat ~/sleeper.c
	 #include <windows.h>

	 int main ()
	 {
	   Sleep (2000);
	   return 0;
	 }

	and with a MinGW GDB, I see:

	 (gdb) start
	 ...
	 (gdb) info threads
	   Id   Target Id           Frame
	 * 1    Thread 15292.0x3850 main () at /home/alves/sleeper.c:5
	   2    Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
	 (gdb) c
	 Continuing.
	 [Thread 15292.0x3850 exited with code 0]
	 [Inferior 1 (process 15292) exited normally]
	 (gdb)

	This commit adjusts gdb_continue_to_end to expect the thread exited
	messages, on Cygwin and MinGW.

	Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-05-03  Mark Wielaard  <mark@klomp.org>

	[gdb/build] Fix gdbserver/linux-aarch64-low.cc build
	Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver")
	removed the last use of i in gdbserver/linux-aarch64-low.cc
	(aarch64_target::low_stopped_data_address). Breaking the build on
	aarch64 with:

	gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?:
	gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable]
	  557 |   int pid, i;
	      |            ^
	cc1plus: all warnings being treated as errors

	Fix this by removing the variable i completely.

	Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver")

2024-05-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use save_vars to restore GDBFLAGS
	There's a pattern of using:
	...
	set saved_gdbflags $GDBFLAGS
	set GDBFLAGS "$GDBFLAGS ..."
	<do something with GDBFLAGS>
	set GDBFLAGS $saved_gdbflags
	...

	Simplify this by using save_vars:
	...
	save_vars { GDBFLAGS } {
	    set GDBFLAGS "$GDBFLAGS ..."
	    <do something with GDBFLAGS>
	}
	...

	Tested on x86_64-linux.

2024-05-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0
	INTERNAL_GDBFLAGS contains:
	- -quiet
	- -iex "set width 0"
	- -iex "set height 0"

	There are test-cases that add these once more.

	Clean this up.

	Tested on x86_64-linux.

	PR testsuite/31649
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649

2024-05-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Update INTERNAL_GDBFLAGS example
	In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added
	-q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS
	example in gdb/testsuite/README.

	Fix this by adding the -q there as well.

2024-05-03  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Fix cast handling for indirection
	Consider a test-case compiled without debug info, containing:
	...
	char a = 'a';

	char *
	a_loc (void)
	{
	  return &a;
	}
	...

	We get:
	...
	(gdb) p (char)*a_loc ()
	Cannot access memory at address 0x10
	...

	There's a bug in unop_ind_base_operation::evaluate that evaluates
	"(char)*a_loc ()" the same as:
	...
	(gdb) p (char)*(char)a_loc ()
	Cannot access memory at address 0x10
	...

	Fix this by instead evaluating it the same as:
	...
	(gdb) p (char)*(char *)a_loc ()
	$1 = 97 'a'
	...

	Tested on x86_64-linux.

	PR exp/31693
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693

2024-05-03  Jan Beulich  <jbeulich@suse.com>

	x86: tidy <sse*> templates
	Some of them no longer need a separate vvvv attribute, thus allowing
	them to be simplified. For <aes> the situation is slightly different:
	None of the remaining uses make use of vvvv anymore.

	x86/APX: further extend SSE2AVX coverage
	Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is
	in use, {evex} should be respected, too. So far this is the case only
	for insns where eGPR-s can come into play. Extend coverage to insns with
	only %xmm register and possibly immediate operands.

2024-05-03  Jan Beulich  <jbeulich@suse.com>

	x86/APX: extend SSE2AVX coverage
	Legacy encoded SIMD insns are converted to AVX ones in that mode. When
	eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where
	available; there are quite a few which can't be converted).

	Note that LDDQU is represented as VMOVDQU32 (and the prior use of the
	sse3 template there needs dropping, to get the order right).

	Note further that in a few cases, due to the use of templates, AVX512VL
	is used when AVX512F would suffice. Since AVX10 is the main reference,
	this shouldn't be too much of a problem.

2024-05-03  Jan Beulich  <jbeulich@suse.com>

	x86: zap value-less Disp8MemShift from non-EVEX templates
	In order to allow to continue to use templatized SSE2AVX templates when
	enhancing those to also cover eGPR usage, Disp8MemShift wants using to
	deviate from what general template attributes supply. That requires
	using Disp8MemShift in a way also affecting non-EVEX templates, yet
	having this attribute set would so far implicitly mean EVEX encoding.
	Recognize the case and instead zap the attribute if no other attribute
	indicates EVEX encoding.

	No change in generated tables.

2024-05-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-02  Tom Tromey  <tromey@adacore.com>

	Fix regression on aarch64-linux gdbserver
	Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64")
	fixed a watchpoint bug in gdb -- but did not touch the corresponding
	code in gdbserver.

	This patch moves the gdb code into gdb/nat, so that it can be shared
	with gdbserver, and then changes gdbserver to use it, fixing the bug.

	This is yet another case where having a single back end would prevent
	bugs.

	I tested this using the AdaCore internal gdb testsuite.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-05-02  Alan Modra  <amodra@gmail.com>

	PR31692, objdump fails .debug_info size check
		PR 31692
		* objdump.c (load_specific_debug_section): Replace bfd_get_size
		check with bfd_section_size_insane.  Call free_debug_section
		after printing error messages.  Set section->start NULL when
		freeing.

2024-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Work around PR gas/29517, dwarf2 case
	In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a
	workaround for PR gas/29517.

	The problem is present in gas version 2.39, and fixed in 2.40, so the
	workaround is only active for gas version == 2.39.

	However, the problem in gas is only fixed for dwarf version >= 3, which
	supports DW_TAG_unspecified_type.

	Fix this by also activating the workaround for dwarf version == 2.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

	PR symtab/31689
	https://sourceware.org/bugzilla/show_bug.cgi?id=31689

2024-05-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-05-01  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix stray file in get_compiler_info
	When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board
	local-remote-host and target board remote-gdbserver-on-localhost, I get:
	...
	$ ls build/gdb/testsuite
	cache    compiler.i  config.log  config.status  gdb.log  gdb.sum  lib  Makefile
	outputs  site.bak    site.exp    temp
	...

	The file compiler.i is there because get_compiler_info uses:
	...
		set ppout "$outdir/compiler.i"
	...

	The file is a temporary, and as such belongs in a temp dir.  Fix this by using
	standard_temp_file, moving the file to build/gdb/testsuite/temp/<pid>/compiler.i.

	Tested on x86_64-linux.

2024-05-01  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.exp
	After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have:
	...
	$ ls build/gdb/testsuite
	cache       config.status                gdb.log  lib       outputs   site.exp
	config.log  gdb-index-nodebug.gdb-index  gdb.sum  Makefile  site.bak  temp
	...

	The file gdb-index-nodebug.gdb-index doesn't belong there.

	It happens to be there because we do:
	...
	set index_file ${testfile}.gdb-index
	set cmd "save gdb-index [file dirname ${index_file}]"
	...
	which results in:
	...
	(gdb) save gdb-index .
	...

	The intention was possibly to use $binfile instead of $testfile, but using
	that wouldn't work for remote host.

	Fix this by using host_standard_output_file.

	Tested on x86_64-linux.

2024-05-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-30  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown.
	bfd/
		PR 29823
		* elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function.
		(elf_backend_obj_attrs_handle_unknown): Defined to
		riscv_elf_obj_attrs_handle_unknown.

2024-04-30  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Add gdb.base/memops-watchpoint.exp
	Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove.
	These functions are frequently optimized with specialized instructions
	that favor larger memory access operations, so make sure GDB behaves
	correctly in their presence.

	There's a separate watched variable for each function so that the testcase
	can test whether GDB correctly identified the watchpoint that triggered.

	Also, the watchpoint is 28 bytes away from the beginning of the buffer
	being modified, so that large memory accesses (if present) are exercised.

	PR testsuite/31484
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-04-30  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/nat/linux: Fix attaching to process when it has zombie threads
	When GDB attaches to a multi-threaded process, it calls
	linux_proc_attach_tgid_threads () to go through all threads found in
	/proc/PID/task/ and call attach_proc_task_lwp_callback () on each of
	them.  If it does that twice without the callback reporting that a new
	thread was found, then it considers that all inferior threads have been
	found and returns.

	The problem is that the callback considers any thread that it hasn't
	attached to yet as new.  This causes problems if the process has one or
	more zombie threads, because GDB can't attach to it and the loop will
	always "find" a new thread (the zombie one), and get stuck in an
	infinite loop.

	This is easy to trigger (at least on aarch64-linux and powerpc64le-linux)
	with the gdb.threads/attach-many-short-lived-threads.exp testcase, because
	its test program constantly creates and finishes joinable threads so the
	chance of having zombie threads is high.

	This problem causes the following failures:

	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted on (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the inferior (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted off (timeout)
	FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout)
	ERROR: breakpoints not deleted

	The iteration number is random, and all tests in the subsequent iterations
	fail too, because GDB is stuck in the attach command at the beginning of
	the iteration.

	The solution is to make linux_proc_attach_tgid_threads () remember when it
	has already processed a given LWP and skip it in the subsequent iterations.

	PR testsuite/31312
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312

	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2024-04-30  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/nat: Factor linux_proc_get_stat_field out of linux_common_core_of_thread
	The new function will be used in a subsequent patch to read a different
	stat field.

	The new code is believed to be equivalent to the old code, so there
	should be no change in GDB behaviour.  The only material change was to
	use std::string and string_printf rather than a fixed char array to
	build the path to the stat file.

	Also, take the opportunity to move the function's documentation comment to
	the header file, to conform with GDB practice.

	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2024-04-30  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread
	The code and comment reference stat fields by made-up indexes.  The
	procfs(5) man page, which describes the /proc/PID/stat file, has a numbered
	list of these fields so it's more convenient to use those numbers instead.

	This is currently an implementation detail inside the function so it's
	not really relevant with the code as-is, but a future patch will do some
	refactoring which will make the index more prominent.

	Therefore, make this change in a separate patch so that it's simpler to
	review.

	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2024-04-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-29  Pedro Alves  <pedro@palves.net>

	gdb/Cygwin: Fix attach pid error message
	On Cygwin, with "attach PID":

	 - GDB first tries to interpret PID as a Windows native PID, and tries
	   to attach to that.

	 - if the attach fails, GDB then tries to interpret the PID as a
	   Cygwin PID, and attach to that.

	If converting the user-provided PID from a Cygwin PID to a Windows PID
	fails, you get this:

	 (gdb) attach 12345
	 Can't attach to process 0 (error 2: The system cannot find the file specified.)

	Note "process 0".

	With the fix in this commit, we'll now get:

	 (gdb) attach 12345
	 Can't attach to process 12345 (error 2: The system cannot find the file specified.)

	I noticed this while looking at gdb.log after running
	gdb.base/attach.exp on Cygwin.

	Change-Id: I05b9dc1f3a634a822ea49bb5c61719f5e62c8514
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-04-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: document how filename arguments are formatted
	In the following commits I intend to improve GDB's filename
	completion.  However, how filenames should be completed is a little
	complex because GDB is not consistent with how it expects filename
	arguments to be formatted.

	This commit documents the current state of GDB when it comes to
	formatting filename arguments.

	Currently GDB will not correctly complete filenames inline with this
	documentation; GDB will either fail to complete, or complete
	incorrectly (i.e. the result of completion will not then be accepted
	by GDB).  However, later commits in this series will fix completion.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-04-29  Nick Clifton  <nickc@redhat.com>

	Fix initiali state of DWARF v5 line number table in BFD library
	  PR 30783

2024-04-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/remote: fix qRcmd error handling
	This commit:

	  commit 3623271997a5c0d79609aa6a1f35ef61b4469054
	  Date:   Tue Jan 30 15:55:47 2024 +0100

	      remote.c: Use packet_check_result

	Introduced a bug in the error handling of the qRcmd packet.  Prior to
	this commit if a packet had status PACKET_OK then, if the packet
	contained the text "OK" we considered the packet handled.  But, if the
	packet contained any other content (that was not an error message)
	then the content was printed to the user.

	After the above commit this was no longer the case, any non-error
	packet that didn't contain "OK" would be treated as an error.

	Currently, gdbserver doesn't exercise this path so it's not possible
	to write a simple test for this case.  When gdbserver wishes to print
	output it sends back an 'O' string output packet, these packets are
	handled earlier in the process.  Then once gdbserver has finished
	sending output an 'OK' packet is sent.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-29  Nick Clifton  <nickc@redhat.com>

	Fix building Loongarch BFD with a 32-bit compiler

2024-04-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-27  Tom Tromey  <tom@tromey.com>

	Fix typo in TUI comment
	tui_win_info::make_visible has a mildly misleading comment -- it says
	"visible" where "invisible" is meant.  This patch fixes it.

	Remove two unneeded forward declarations
	I noticed a couple of forward declarations in the TUI that aren't
	needed -- the declarations aren't used in the header files in which
	they appear.  This patch removes these.

2024-04-27  Tom de Vries  <tdevries@suse.de>

	[gdb/remote] Fix abort on REMOTE_CLOSE_ERROR
	When running test-case gdb.server/connect-with-no-symbol-file.exp on
	aarch64-linux (specifically, an opensuse leap 15.5 container on a
	fedora asahi 39 system), I run into:
	...
	(gdb) detach^M
	Detaching from program: target:connect-with-no-symbol-file, process 185104^M
	Ending remote debugging.^M
	terminate called after throwing an instance of 'gdb_exception_error'^M
	...

	The detailed backtrace of the corefile is:
	...
	 (gdb) bt
	 #0  0x0000ffff75504f54 in raise () from /lib64/libpthread.so.0
	 #1  0x00000000007a86b4 in handle_fatal_signal (sig=6)
	     at gdb/event-top.c:926
	 #2  <signal handler called>
	 #3  0x0000ffff74b977b4 in raise () from /lib64/libc.so.6
	 #4  0x0000ffff74b98c18 in abort () from /lib64/libc.so.6
	 #5  0x0000ffff74ea26f4 in __gnu_cxx::__verbose_terminate_handler() ()
	    from /usr/lib64/libstdc++.so.6
	 #6  0x0000ffff74ea011c in ?? () from /usr/lib64/libstdc++.so.6
	 #7  0x0000ffff74ea0180 in std::terminate() () from /usr/lib64/libstdc++.so.6
	 #8  0x0000ffff74ea0464 in __cxa_throw () from /usr/lib64/libstdc++.so.6
	 #9  0x0000000001548870 in throw_it (reason=RETURN_ERROR,
	     error=TARGET_CLOSE_ERROR, fmt=0x16c7810 "Remote connection closed", ap=...)
	     at gdbsupport/common-exceptions.cc:203
	 #10 0x0000000001548920 in throw_verror (error=TARGET_CLOSE_ERROR,
	     fmt=0x16c7810 "Remote connection closed", ap=...)
	     at gdbsupport/common-exceptions.cc:211
	 #11 0x0000000001548a00 in throw_error (error=TARGET_CLOSE_ERROR,
	     fmt=0x16c7810 "Remote connection closed")
	     at gdbsupport/common-exceptions.cc:226
	 #12 0x0000000000ac8f2c in remote_target::readchar (this=0x233d3d90, timeout=2)
	     at gdb/remote.c:9856
	 #13 0x0000000000ac9f04 in remote_target::getpkt (this=0x233d3d90,
	     buf=0x233d40a8, forever=false, is_notif=0x0) at gdb/remote.c:10326
	 #14 0x0000000000acf3d0 in remote_target::remote_hostio_send_command
	     (this=0x233d3d90, command_bytes=13, which_packet=17,
	     remote_errno=0xfffff1a3cf38, attachment=0xfffff1a3ce88,
	     attachment_len=0xfffff1a3ce90) at gdb/remote.c:12567
	 #15 0x0000000000ad03bc in remote_target::fileio_fstat (this=0x233d3d90, fd=3,
	     st=0xfffff1a3d020, remote_errno=0xfffff1a3cf38)
	     at gdb/remote.c:12979
	 #16 0x0000000000c39878 in target_fileio_fstat (fd=0, sb=0xfffff1a3d020,
	     target_errno=0xfffff1a3cf38) at gdb/target.c:3315
	 #17 0x00000000007eee5c in target_fileio_stream::stat (this=0x233d4400,
	     abfd=0x2323fc40, sb=0xfffff1a3d020) at gdb/gdb_bfd.c:467
	 #18 0x00000000007f012c in <lambda(bfd*, void*, stat*)>::operator()(bfd *,
	     void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400,
	     sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955
	 #19 0x00000000007f015c in <lambda(bfd*, void*, stat*)>::_FUN(bfd *, void *,
	     stat *) () at gdb/gdb_bfd.c:956
	 #20 0x0000000000f9b838 in opncls_bstat (abfd=0x2323fc40, sb=0xfffff1a3d020)
	     at bfd/opncls.c:665
	 #21 0x0000000000f90adc in bfd_stat (abfd=0x2323fc40, statbuf=0xfffff1a3d020)
	     at bfd/bfdio.c:431
	 #22 0x000000000065fe20 in reopen_exec_file () at gdb/corefile.c:52
	 #23 0x0000000000c3a3e8 in generic_mourn_inferior ()
	     at gdb/target.c:3642
	 #24 0x0000000000abf3f0 in remote_unpush_target (target=0x233d3d90)
	     at gdb/remote.c:6067
	 #25 0x0000000000aca8b0 in remote_target::mourn_inferior (this=0x233d3d90)
	     at gdb/remote.c:10587
	 #26 0x0000000000c387cc in target_mourn_inferior (
	     ptid=<error reading variable: Cannot access memory at address 0x2d310>)
	     at gdb/target.c:2738
	 #27 0x0000000000abfff0 in remote_target::remote_detach_1 (this=0x233d3d90,
	     inf=0x22fce540, from_tty=1) at gdb/remote.c:6421
	 #28 0x0000000000ac0094 in remote_target::detach (this=0x233d3d90,
	     inf=0x22fce540, from_tty=1) at gdb/remote.c:6436
	 #29 0x0000000000c37c3c in target_detach (inf=0x22fce540, from_tty=1)
	     at gdb/target.c:2526
	 #30 0x0000000000860424 in detach_command (args=0x0, from_tty=1)
	    at gdb/infcmd.c:2817
	 #31 0x000000000060b594 in do_simple_func (args=0x0, from_tty=1, c=0x231431a0)
	     at gdb/cli/cli-decode.c:94
	 #32 0x00000000006108c8 in cmd_func (cmd=0x231431a0, args=0x0, from_tty=1)
	     at gdb/cli/cli-decode.c:2741
	 #33 0x0000000000c65a94 in execute_command (p=0x232e52f6 "", from_tty=1)
	     at gdb/top.c:570
	 #34 0x00000000007a7d2c in command_handler (command=0x232e52f0 "")
	     at gdb/event-top.c:566
	 #35 0x00000000007a8290 in command_line_handler (rl=...)
	     at gdb/event-top.c:802
	 #36 0x0000000000c9092c in tui_command_line_handler (rl=...)
	     at gdb/tui/tui-interp.c:103
	 #37 0x00000000007a750c in gdb_rl_callback_handler (rl=0x23385330 "detach")
	     at gdb/event-top.c:258
	 #38 0x0000000000d910f4 in rl_callback_read_char ()
	     at readline/readline/callback.c:290
	 #39 0x00000000007a7338 in gdb_rl_callback_read_char_wrapper_noexcept ()
	     at gdb/event-top.c:194
	 #40 0x00000000007a73f0 in gdb_rl_callback_read_char_wrapper
	     (client_data=0x22fbf640) at gdb/event-top.c:233
	 #41 0x0000000000cbee1c in stdin_event_handler (error=0, client_data=0x22fbf640)
	     at gdb/ui.c:154
	 #42 0x000000000154ed60 in handle_file_event (file_ptr=0x232be730, ready_mask=1)
	     at gdbsupport/event-loop.cc:572
	 #43 0x000000000154f21c in gdb_wait_for_event (block=1)
	     at gdbsupport/event-loop.cc:693
	 #44 0x000000000154dec4 in gdb_do_one_event (mstimeout=-1)
	    at gdbsupport/event-loop.cc:263
	 #45 0x0000000000910f98 in start_event_loop () at gdb/main.c:400
	 #46 0x0000000000911130 in captured_command_loop () at gdb/main.c:464
	 #47 0x0000000000912b5c in captured_main (data=0xfffff1a3db58)
	     at gdb/main.c:1338
	 #48 0x0000000000912bf4 in gdb_main (args=0xfffff1a3db58)
	     at gdb/main.c:1357
	 #49 0x00000000004170f4 in main (argc=10, argv=0xfffff1a3dcc8)
	     at gdb/gdb.c:38
	 (gdb)
	...

	The abort happens because a c++ exception escapes to c code, specifically
	opncls_bstat in bfd/opncls.c.  Compiling with -fexceptions works around this.

	Fix this by catching the exception just before it escapes, in stat_trampoline
	and likewise in few similar spot.

	Add a new template catch_exceptions to do so in a consistent way.

	Tested on aarch64-linux.

	Approved-by: Pedro Alves <pedro@palves.net>

	PR remote/31577
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577

2024-04-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-26  Pedro Alves  <pedro@palves.net>

	Improve target.h & target_ops & xfer_partial descriptions
	Working backwards in terms of motivation for the patch:

	- When accessing memory via the xfer_partial interface, the process
	  that we're accessing is indicated by inferior_ptid.  This can be
	  either the same process as current inferior, or a fork child which
	  does not exist in the inferior list.  This is not documented
	  currently.  This commit fixes that.

	- For target delegation to work, we must always make the inferior we
	  want to call the target method on, the current inferior.  This
	  wasn't documented, AFAICT, so this commit fixes that too.  I put
	  that in the intro comment to target_ops.

	- I actually started writing a larger intro comment to target_ops, as
	  there was seemingly none, which I did find odd.  However, I then
	  noticed the description closer to the top of the file.  I missed it
	  the first time, because for some reason, that intro comment is no
	  longer at the top of the file, as #includes etc. have been added
	  above it over the years.  This commit fixes that too, by moving that
	  intro comment to the top.

	Change-Id: Id21f5462947f2a0f6f3ac0c42532df62ba355914
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579)
	Old RHEL systems have a kernel that does not support writing memory
	via /proc/pid/mem.  On such systems, we fallback to accessing memory
	via ptrace.  That has a few downsides described in the "Accessing
	inferior memory" section at the top of linux-nat.c.

	The target_xfer interface for memory access uses inferior_ptid as
	sideband argument to indicate which process to access.  Memory access
	is process-wide, it is not thread-specific, so inferior_ptid is
	sometimes pointed at a process-wide ptid_t for the memory access
	(i.e., a ptid that looks like {pid, 0, 0}).  That is the case for any
	code that uses scoped_restore_current_inferior_for_memory, for
	example.

	That is what causes the issue described in PR 31579, where thread_db
	calls into the debugger to read memory, which reaches our
	ps_xfer_memory function, which does:

	  static ps_err_e
	  ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr,
			  gdb_byte *buf, size_t len, int write)
	  {
	    scoped_restore_current_inferior_for_memory save_inferior (ph->thread->inf);

	    ...
	      ret = target_read_memory (core_addr, buf, len);
	    ...
	  }

	If linux_nat_target::xfer_partial falls back to inf_ptrace_target with
	a pid-ptid, then the ptrace code will do the ptrace call targeting
	pid, the leader LWP.  That may fail with ESRCH if the leader is
	currently running, or zombie.  That is the case in the scenario in
	question, because thread_db is consulted for an event of a non-leader
	thread, before we've stopped the whole process.

	Fix this by having the ptrace fallback code try to find a stopped LWP
	to use with ptrace.

	I chose to handle this in the linux-nat target instead of in common
	code because (global) memory is a process-wide property, and this
	avoids having to teach all the code paths that use
	scoped_restore_current_inferior_for_memory to find some stopped thread
	to access memory through, which is a ptrace quirk.  That is
	effectively what we used to do before we started relying on writable
	/proc/pid/mem.  I'd rather not go back there.

	To trigger this on modern kernels you have to hack linux-nat.c to
	force the ptrace fallback code, like so:

	 --- a/gdb/linux-nat.c
	 +++ b/gdb/linux-nat.c
	 @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object,
		  poke would incorrectly write memory to the post-exec address
		  space, while the core was trying to write to the pre-exec
		  address space.  */
	 -      if (proc_mem_file_is_writable ())
	 +      if (0 && proc_mem_file_is_writable ())

	With that hack, I was able to confirm that the fix fixes hundreds of
	testsuite failures.  Compared to a test run with pristine master, the
	hack above + this commit's fix shows that some non-stop-related tests
	fail, but that is expected, because those are tests that need to
	access memory while the program is running.  (I made no effort to
	temporarily pause an lwp if no ptrace-stopped lwp is found.)

	Change-Id: I24a4f558e248aff7bc7c514a88c698f379f23180
	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Fix gdb.base/attach.exp --pid test skipping on native-extended-gdbserver
	When testing with the native-extended-gdbserver board,
	gdb.base/attach.exp shows a couple failures, like so:

	 Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ...
	 FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid
	 FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread)

	From gdb.log:

	 builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build
	 /gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260
	 Don't know how to attach.  Try "help target".
	 (gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid

	There is a check for [isnative] to skip the test on anything but
	target native, but that is the wrong check.  native-extended-gdbserver
	is "isnative".  Fix it by using a gdb_protocol check instead.

	Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Eliminate gdb_is_target_remote / gdb_is_target_native & friends
	After the previous patches, gdb_is_target_remote,
	gdb_is_target_native, and mi_is_target_remote aren't used anywhere.
	This commit eliminates them, along with now unnecessary helpers.

	Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	gdb_is_target_remote -> gdb_protocol_is_remote
	This is similar to the previous patch, but for gdb_protocol_is_remote.

	gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
	print target-stack", which is unnecessary when checking whether
	gdb_protocol is "remote" or "extended-remote" would do.  Checking
	gdb_protocol is more efficient, and can be done before starting GDB
	and running to main, unlike gdb_is_target_remote/mi_is_target_remote.

	This adds a new gdb_protocol_is_remote procedure, and uses it in place
	of gdb_is_target_remote/mi_is_target_remote throughout.

	There are no uses of gdb_is_target_remote/mi_is_target_remote left
	after this.  Those will be eliminated in a following patch.

	In some spots, we no longer need to defer the check until after
	starting GDB, so the patch adjusts accordingly.

	Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	gdb_is_target_native -> gdb_protocol_is_native
	gdb_is_target_native uses "maint print target-stack", which is
	unnecessary when checking whether gdb_protocol is empty would do.
	Checking gdb_protocol is more efficient, and can be done before
	starting GDB and running to main, unlike gdb_is_target_native.

	This adds a new gdb_protocol_is_native procedure, and uses it in place
	of gdb_is_target_native.

	At first, I thought that we'd end up with a few testcases needing to
	use gdb_is_target_native still, especially multi-target tests that
	connect to targets different from the default board target, but no,
	actually all uses of gdb_is_target_native could be converted.
	gdb_is_target_native will be eliminated in a following patch.

	In some spots, we no longer need to defer the check until after
	starting GDB, so the patch adjusts accordingly.

	Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	gdbserver: Fix vAttach response when attaching is not supported
	handle_v_attach calls attach_inferior, which says:

	  "return -1 if attaching is unsupported, 0 if it succeeded, and call
	  error() otherwise."

	So if attach_inferior return != 0, we have the unsupported case,
	meaning we should return the empty packet instead of an error.

	In practice, this shouldn't trigger, as vAttach support is supposed to
	be reported via qSupported.  But it doesn't hurt to be pedantic here.

	Change-Id: I99cce6fa678f2370571e6bca0657451300956127
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Fix "attach" failure handling with GDBserver
	This fixes the same issue as the previous patch, but for "attach"
	instead of "run".

	If attaching to a process with "attach" (vAttach packet) fails,
	GDBserver throws an error that escapes all the way to the top level.
	When an error escapes all the way like that, GDBserver interprets it
	as a disconnection, and either goes back to waiting for a new GDB
	connection, or exits, if --once was specified.

	Here's an example:

	On the GDB side:

	 ...
	 (gdb) tar extended-remote :9999
	 ...
	 Remote debugging using :9999
	 (gdb) attach 1
	 Attaching to process 1
	 Attaching to process 1 failed
	 (gdb)

	On the GDBserver side:

	 $ gdbserver --once --multi :9999
	 Listening on port 9999
	 Remote debugging from host 127.0.0.1, port 37464
	 gdbserver: Cannot attach to process 1: Operation not permitted (1)
	 $   # gdbserver exited

	This is wrong, as we've connected with extended-remote/--multi.
	GDBserver should just report an error to vAttach, and continue
	connected to GDB, waiting for other commands.

	This commit fixes GDBserver by catching the error locally in
	handle_v_attach.

	Note we now let pid == 0 pass down to attach_inferior.  That is so we
	get a useful textual error message to report to GDB.

	This fixes a couple KFAILs in gdb.base/attach.exp.  Still, I thought
	it would be useful to add a new testcase specifically for this
	scenario, in case gdb.base/attach.exp is ever split and stops trying
	to attach again after a failed attach, with the same GDB session.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554

	Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Improve vRun error reporting
	After the previous commit, if starting the inferior process with "run"
	(vRun packet) fails, GDBserver reports an error using the "E." textual
	error packet.  On the GDB side, however, GDB doesn't yet do anything
	with the textual error string.  This commit improves that.

	This makes remote debugging output the same as native output, when
	possible, another small step in the "local/remote parity" project.

	E.g., before, against GNU/Linux GDBserver:

	  (gdb) run
	  Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
	  Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed

	After, against GNU/Linux GDBserver (same as native):

	  (gdb) run
	  Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
	  During startup program exited with code 126.

	To know whether we have a textual error message, extend packet_result
	to carry that information.  While at it, convert packet_result to use
	factory methods, and change its std::string parameter to a plain const
	char *, as that it always what we have handy to pass to it.

	Change-Id: Ib386f267522603f554b52a885b15229c9639e870
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Fix "run" failure handling with GDBserver
	If starting the inferior process with "run" (vRun packet) fails,
	GDBserver throws an error that escapes all the way to the top level.
	When an error escapes all the way like that, GDBserver interprets it
	as a disconnection, and either goes back to waiting for a new GDB
	connection, or exits, if --once was specified.

	E.g., with the testcase program added by this commit, we see:

	On GDB side:

	 ...
	 (gdb) tar extended-remote :999
	 ...
	 Remote debugging using :9999
	 (gdb) r
	 Starting program:
	 Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed
	 (gdb)

	On GDBserver side:

	 $ gdbserver --once --multi :9999
	 Remote debugging from host 127.0.0.1, port 34344
	 bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied
	 bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied
	 gdbserver: During startup program exited with code 126.
	 $   # gdbserver exited

	This is wrong, as we've connected with extended-remote/--multi.
	GDBserver should just report an error to vCont, and continue connected
	to GDB, waiting for other commands.

	This commit fixes GDBserver by catching the error locally in
	handle_v_run.

	Change-Id: Ib386f267522603f554b52a885b15229c9639e870
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Windows: Fix run/attach hang after bad run/attach
	On Cygwin, gdb.base/attach.exp exposes that an "attach" after a
	previously failed "attach" hangs:

	 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited
	 attach 0
	 Can't attach to process 0 (error 2: The system cannot find the file specified.)
	 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited
	 attach 10644
	 FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout)

	The problem is that windows_nat_target::attach always returns success
	even if the attach fails.  When we return success, the helper thread
	begins waiting for events (which will never come), and thus the next
	attach deadlocks on the do_synchronously call within
	windows_nat_target::attach.

	"run" has the same problem, which is exposed by the new
	gdb.base/run-fail-twice.exp testcase added in a following patch:

	 (gdb) run
	 Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
	 Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.)
	 (gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1
	 run
	 Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox
	 FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout)

	The problem here is the same, except that this time it is
	windows_nat_target::create_inferior that returns the incorrect result.

	This commit fixes both the "attach" and "run" paths, and the latter
	both the Cygwin and MinGW paths.  The tests mentioned above now pass
	on Cygwin.  Confirmed the fixes manually for MinGW GDB.

	Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Document "E.MESSAGE" RSP errors
	For many years, GDB has accepted a "E.MESSAGE" error reponse, in
	addition to "E NN".  For many packets, GDB strips the "E." before
	giving the error message to the user.  For others, GDB does not strip
	the "E.", but still understands that it is an error, as it starts with
	"E", and either prints the whole string, or ignores it and just
	mentions an error occured (same as for "E NN").

	This has been the case for as long as I remember.  Now that I check, I
	see that it's been there since 2006 (commit a76d924dffcb, also here:
	https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html).
	All along, I actually thought it was documented.  Turns out it wasn't.

	This commit documents it, in the new "Standard Replies" section, near
	where we document "E NN".

	The original version of this 3-patch documentation series was a single
	CodeSourcery patch that documented the textual error as
	"E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded.  But I
	think the ship has sailed for that.  GDBserver has been sending error
	messages with more than one "." for a long while, and with no binary
	encoding.  Still, I've preserved the "Co-Authored-By" list of the
	original larger patch.

	The 'qRcmd' and 'm' commands are exceptions and do not accept this
	reply format.  The top of the "Standard Replies" section already says:

	  "All commands support these, except as noted in the individual
	  command descriptions."

	So this adds a note to the description of 'qRcmd' and 'm', explicitly
	stating that they do not support this error reply format.

	Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8
	Co-Authored-By: Jim Blandy <jimb@codesourcery.com>
	Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
	Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
	Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Centralize documentation of error and empty RSP responses
	Currently, for each packet, we document the "E NN" response (error),
	and the empty response (unsupported).  This patch centralizes that in
	a new "Standard Replies" section.

	In the "Packets", "General Query Packets", "Tracepoint Packets"
	sections, Remove explicit mention of empty and error replies, except
	when they provide detail not covered in Standard Replies.

	Note this hunk:

	 -@item E @var{NN}
	 -@var{NN} is errno

	and this one:

	 -@item E00
	 -The request was malformed, or @var{annex} was invalid.
	 -
	 -@item E @var{nn}
	 -The offset was invalid, or there was an error encountered reading the data.
	 -The @var{nn} part is a hex-encoded @code{errno} value.

	were really documenting things that don't really work that way.

	The first is the documentation of the "m" packet.  GDB does _not_
	interpret the NN as an errno.  It can't, in fact, because the
	remote/target errno numbers have nothing to do with GDB/host errno
	numbers in a cross debugging scenario.

	The second hunk above is from the documentation of qXfer.  Again, GDB
	does not give any interpretation to the NN error code at all.  Nor
	does GDBserver.  And again, an errno number can't be interpreted in a
	cross debugging scenario.

	Change-Id: I973695c80809cdb5a5e8d5be8b78ba4d1ecdb513
	Co-Authored-By: Jim Blandy <jimb@codesourcery.com>
	Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
	Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
	Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-04-26  Pedro Alves  <pedro@palves.net>

	Document conventions for describing packet syntax
	This comment documents conventions for describing packet syntax in the
	Overview section.

	Change-Id: I96198592601b24c983da563d143666137e4d0a4e
	Co-Authored-By: Jim Blandy <jimb@codesourcery.com>
	Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
	Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
	Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-04-26  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Remove unnecessary get_current_frame calls from infrun.c
	Since the frame variable is now a frame_info_ptr, the issue
	with the dangling frame pointer is apparently no longer there.

	So remove the re-fetch code and the corresponding meanwhile
	misleading comments.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Andrew Burgess  <aburgess@redhat.com>

	gdb: Add a SECURITY.txt document for GDB
	This commit adds a SECURITY document to GDB.  The idea behind this
	document is to define what security expectations a user can reasonably
	have when using GDB.  In addition the document specifies which bugs
	GDB developers consider a security bug, and which are just "normal"
	bugs.

	Discussion for the creation of this initial version can be found here:

	  https://inbox.sourceware.org/gdb-patches/877cmvui64.fsf@redhat.com/

	Like any part of GDB, this is not intended as the absolute final
	version, instead this is a living document, and this is just a
	reasonable starting point from which we can iterate.

	For now I've added this document as a text file but I am considering
	merging this document into the manual at a later date, and having the
	SECURITY.txt file just say "Read the manual"

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-26  Sébastien Michelland  <sebastien.michelland@lcis.grenoble-inp.fr>

	gdb: specify sh pointer register types
	This patch fixes a pretty funny issue on sh targets that occurred
	because $pc (and similar registers) were typed as int. When $pc is in
	the upper half of the address space (i.e. kernel code on sh), `x/i $pc'
	would resolve to a negative value. At least in the case of a remote
	target with an Xfer memory map, this leads to a spurious "cannot access
	memory" error as negative addresses are out of bounds.

	(gdb) x/i $pc
	    0x8c202c04:    Cannot access memory at address 0x8c202c04
	(gdb) x/i 0x8c202c04
	=> 0x8c202c04 <gintctl_gint_gdb+304>:    mov.l    @r1,r10

	The issue is fixed by specifying pointer types for pc and other pointer
	registers. Code pointer registers on sh include pc, pr (return address
	of a call), vbr (interrupt handler) and spc (return address after
	interrupt). Data pointers include r15 (stack pointer) and gbr (base
	register for a few specific addressing modes).

	Change-Id: I043a058f7cbc6494f380dc0461616a9f3e0d87e0
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-26  Jan Beulich  <jbeulich@suse.com>

	objcopy: check input flavor before setting PE/COFF section alignment
	coff_section_data() and elf_section_data() use the same underlying
	field. The pointer being non-NULL therefore isn't sufficient to know
	that pei_section_data() can validly be used on the incoming object.
	Apparently in 64-bit-host builds the resulting memory corruption is
	benign, whereas in 32-bit-host builds a segmentation fault occurs upon
	de-referencing pei_section_data()'s return value.

2024-04-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-25  Carl Love  <cel@linux.ibm.com>

	Fix end_sequence addresses for dw2-lines.exp
	The patch:

	  From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001
	  From: Tom de Vries <tdevries@suse.de>
	  Date: Wed, 17 Apr 2024 12:55:00 +0200
	  Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses

	  I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
	  ...
	  00000000004102c4 <end_of_sequence>:
	    4102c4:       52800000        mov     w0, #0x0                        // #0
	   4102c8:       9100c3ff        add     sp, sp, #0x30
	    4102cc:       d65f03c0        ret
	  ...
	  is not described by the line table:
	  ...

	  <snip>

	The regression failure on PowerPC is due to the change in file
	dw2-lines.exp,

	-               DW_LNE_set_address bar_label_5
	+               DW_LNE_set_address "$main_start + $main_len"

	The label bar_label_5 is in function bar, not function main.  The new
	set address should have been $bar_start + $bar_len.

2024-04-25  David Faust  <david.faust@oracle.com>

	bpf: fix calculation when deciding to relax branch
	In certain cases we were calculating the jump displacement incorrectly
	when deciding whether to relax a branch.  This meant for some branches,
	such as a very long backwards conditional branch, relaxation was not
	done when it should have been.  The result was to error later, because
	the actual jump displacement was too large to fit in the original
	instruction.

	This patch fixes up the displacement calculation so that those branches
	are correctly relaxed and no longer result in an error.  In addition, it
	changes md_convert_frag to install fixups for the JAL instructions in
	the resulting relaxations rather than encoding the displacement value
	directly.

	gas/
		* config/tc-bpf.c (relaxed_branch_length): Correct displacement
		calculation when relaxing.
		(md_convert_frag): Likewise.  Install fixups for JAL
		instructions resulting from relaxation.
		* testsuite/gas/bpf/jump-relax-ja-be.d: Correct and expand test.
		* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
		* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
		* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
		* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
		* testsuite/gas/bpf/jump-relax-jump.s: Likewise.

2024-04-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add type annotations to ada-unicode.py
	Add type annotations to ada-unicode.py, just enough to make pyright
	happy:

	    $ pyright --version
	    pyright 1.1.359
	    $ pyright ada-unicode.py
	    0 errors, 0 warnings, 0 informations

	Introduce a `Range` class instead of using separate variables and
	tuples, to make the code and type annotations a bit cleaner.

	When running ada-unicode.py, I get a diff for ada-casefold.h, but I get
	the same diff before and after this patch, so that is a separate issue.

	Change-Id: I0d8975a57f9fb115703178ae197dc6b6b8b4eb7a
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove gdbcmd.h
	Most files including gdbcmd.h currently rely on it to access things
	actually declared in cli/cli-cmds.h (setlist, showlist, etc).  To make
	things easy, replace all includes of gdbcmd.h with includes of
	cli/cli-cmds.h.  This might lead to some unused includes of
	cli/cli-cmds.h, but it's harmless, and much faster than going through
	the 170 or so files by hand.

	Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move style_set_list/style_show_list declarations to cli/cli-style.h
	They are defined in cli/cli-style.c.

	Change-Id: Ic478a3985ff0fd773bd7ba85bb144c6e914d0be6
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused print_command_line and print_command_lines declarations
	There is no corresponding definition for print_command_line.

	There is already a declaration for print_command_lines in
	cli/cli-script.h (the implementation is in cli/cli-script.c).

	Change-Id: Ic9e67ed04703306d614383ead14e2b2b059b2a8e
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-25  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move execute function declarations from gdbcmd.h to top.h
	These functions are implemented in top.c, move their declarations to
	top.h.

	Change-Id: I8893ef91d955156a6530734fefe8002d78c3e5fc
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-25  Jinyang He  <hejinyang@loongson.cn>

	LoongArch: gas: Simplify relocations in sections without code flag
	Gas should not emit ADD/SUB relocation pairs for label differences
	if they are in the same section without code flag even relax enabled.
	Because the real value is not be affected by relaxation and it can be
	compute out in assembly stage. Thus, correct the `TC_FORCE_RELOCATION
	_SUB_SAME` and the label differences in same section without code
	flag can be resolved in fixup_segment().

2024-04-25  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Add bad static relocation check and output more information to user
	Absolute address symbols cannot be used with -shared.
	We output more information to the user than just BFD_ASSETR.

	LoongArch: The symbol got type can only be obtained after initialization
	When scanning relocations and determining whether TLS type transition is
	possible, it will try to obtain the symbol got type. If the symbol got
	type record has not yet been allocated space and initialized, it will
	cause ld to crash. So when uninitialized, the symbol is set to GOT_UNKNOWN.

2024-04-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-24  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Add libc_has_debug_info require helper
	Factor the test for libc debug info out of gdb.base/relativedebug.exp to
	a new procedure.

	Also, change the "info sharedlibrary" test to explicitly detect when
	libc has debug info.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-04-24  Ciaran Woodward  <ciaranwoodward@xmos.com>

	gdb/doc: Fix incorrect information in RSP doc
	The 'PacketSize' attribute of the qSupported packet was
	documented to be the maximum size of the packet including
	the frame and checksum bytes, however this is not how it
	was treated in the code. In reality, PacketSize is the
	maximum size of the data in the RSP packets, not including
	the framing or checksum bytes.

	For instance, GDB's remote.c treats it as the maximum
	number of data bytes.  See remote_read_bytes_1, where the
	size of the request is capped at PacketSize/2 (for
	hex-encoding).

	Also see gdbserver's server.cc, where the internal buffer
	is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize.
	In gdbserver's case, the buffer is not used for any of the
	framing or checksum characters. (I am not certain where the -1
	comes from. I think it comes from back when there were no
	binary packets, so packets were treated as strings with
	null terminators).

	It also seems like gdbservers in the wild treat it in
	this way:

	Embocosm doc:
	https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#id3078000

	A quick glance over openocd's gdb_server.c gdb_put_packet_inner()
	function shows that the internal buffer also excludes the framing
	and checksum.

	Likewise, qEmu's gdbstub.c allocates PacketSize bytes for
	the internal packet contents, and PacketSize+4 for the
	full frame.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Pedro Alves <pedro@palves.net>

2024-04-24  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Handle two-linetable function in find_epilogue_using_linetable
	Consider the following test-case:
	...
	$ cat hello.c
	int main()
	{
	  printf("hello ");
	  #include "world.inc"
	$ cat world.inc
	  printf("world\n");
	  return 0;
	}
	$ gcc -g hello.c
	...

	The line table for the compilation unit, consisting just of
	function main, is translated into these two gdb line tables, one for hello.c
	and one for world.inc:
	...
	compunit_symtab: hello.c
	symtab: hello.c
	INDEX  LINE   REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
	0      3      0x400557    0x400557      Y
	1      4      0x40055b    0x40055b      Y
	2      END    0x40056a    0x40056a      Y

	compunit_symtab: hello.c
	symtab: world.inc
	INDEX  LINE   REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
	0      1      0x40056a    0x40056a      Y
	1      2      0x400574    0x400574      Y
	2      3      0x400579    0x400579      Y
	3      END    0x40057b    0x40057b      Y
	...

	The epilogue of main starts at 0x400579:
	...
	  400579:	5d                   	pop    %rbp
	  40057a:	c3                   	ret
	...

	Now, say we have an epilogue_begin marker in the line table at 0x400579.

	We won't find it using find_epilogue_using_linetable, because it does:
	...
	  const struct symtab_and_line sal = find_pc_line (start_pc, 0);
	...
	which gets us the line table for hello.c.

	Fix this by using "find_pc_line (end_pc - 1, 0)" instead.

	Tested on x86_64-linux.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

	PR symtab/31622
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622

2024-04-24  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix an out of bounds array access in find_epilogue_using_linetable
	An out of bounds array access in find_epilogue_using_linetable causes random
	test failures like these:

	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $fn_fba
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: check frame-id matches
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: bt 2
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: up
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $sp_value == $::main_sp
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $::main_fba
	FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: [string equal $fid $::main_fid]

	Here the read happens below the first element of the line
	table, and the test failure depends on the value that is
	read from there.

	It also happens that std::lower_bound returns a pointer exactly at the upper
	bound of the line table, also here the read value is undefined, that happens
	in this test:

	FAIL: gdb.dwarf2/dw2-epilogue-begin.exp: confirm watchpoint doesn't trigger

	Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table")

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

	PR symtab/31268
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268

2024-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/threadcrash.exp for remote host
	With test-case gdb.threads/threadcrash.exp using host board local-remote-host
	and target board remote-gdbserver-on-localhost I run into:
	...
	(gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash
	gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M
	Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M
	(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore
	UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file
	...

	The problem is that the gcore command tries to save a file on a remote host,
	but the filename is a location on build.

	Fix this by using host_standard_output_file.

	Tested on x86_64-linux.

2024-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/threadcrash.exp with glibc debuginfo
	After installing glibc debuginfo, I ran into:
	...
	FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \
	  $thread_count == [llength $test_list]
	...

	This happens because the clause:
	...
		-re "^\r\n${hs}main$hs$eol" {
	...
	which is intended to match only:
	...
	 #1  <hex> in main () at threadcrash.c:423^M
	...
	also matches "remaining" in:
	...
	 #1  <hex> in __GI___nanosleep (requested_time=<hex>, remaining=<hex>) at \
	   nanosleep.c:27^M
	...

	Fix this by checking for "in main" instead.

	Tested on x86_64-linux.

2024-04-24  Nick Clifton  <nickc@redhat.com>

	Update readelf's display of RELR sections to include the number of locations relocated

2024-04-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: include extract-store-integer.h in charset.c when PHONY_ICONV
	When building on a system where "phony iconv" is used (NetBSD in this
	case, not sure why), I get:

	      CXX    charset.o
	    /home/smarchi/src/binutils-gdb/gdb/charset.c: In function 'size_t phony_iconv(int, const char**, size_t*, char**, size_t*)':
	    /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: error: 'extract_unsigned_integer' was not declared in this scope
	          = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian);
	            ^~~~~~~~~~~~~~~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: note: suggested alternative: 'btrace_insn_number'
	          = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian);
	            ^~~~~~~~~~~~~~~~~~~~~~~~
	            btrace_insn_number

	Add the necessary include.

	Change-Id: I10b967584645961c86167a8395d88929a42bef03

2024-04-24  Alan Modra  <amodra@gmail.com>

	PPC maintainers
	I'm retiring from IBM, and Geoff hasn't been active for a very long
	time.

		* MAINTAINERS (ppc): Remove myself and Geoff Keating.  Add
		Geoff to past maintainers.

2024-04-24  Alan Modra  <amodra@gmail.com>

	buffer overflow in libctf tests
	       * testsuite/libctf-regression/gzrewrite.c (main): Don't overflow
	       "a" buffer in "after adding types" check.
	       * testsuite/libctf-regression/zrewrite.c (main): Likewise.

2024-04-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: adjust copyright years of extract-store-integer.{c,h}
	The contents of these files was copied from defs.h and findvar.  Copy
	over the copyright years (1986-2024).

	Change-Id: Idfb0f255fbcfda7e107e9a82804cece3d81ed5fc

2024-04-23  Claudio Bantaloukas  <claudio.bantaloukas@arm.com>

	arm: Fix MVE vmla encoding

2024-04-23  Olivier Hainque  <hainque@adacore.com>

	bfd: Remove duplicate word in elf-vxworks.c
		PR ld/31652
		* elf-vxworks.c  (elf_vxworks_emit_relocs): Drop duplicate word.

2024-04-23  H.J. Lu  <hjl.tools@gmail.com>

	objcopy.c: Fix bfd_copy_private_symbol_data on 32-bit hosts
	Use long with bfd_copy_private_symbol_data to fix

	.../binutils/objcopy.c: In
	function ‘copy_object’:
	.../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare]
	 3383 |   for (i = 0; i < symcount; i++)
	      |                 ^

	on 32-bit hosts.

		PR binutils/14493
		* objcopy.c (copy_object): Use long with
		bfd_copy_private_symbol_data.

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move symbol_file_command declaration to symfile.h
	Move it out of defs.h, the corresponding definition is in symfile.c.

	Change-Id: I984666c3bcd213f8574e9ec91462e1d61f77f16b
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove enum precision_type
	It is unused.

	Change-Id: Ic49a3ef03c21b209594cd567ae80b5441606bef6
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move annotation_level declaration/definition to annotate.{h,c}
	The declaration of annotation_level is currently in defs.h, while the
	definition is in stack.c.  I don't really understand why that variable
	would live in stack.c, it seems completely unrelated.  Move it to
	annotate.c, and move the declaration to annotate.h.

	Change-Id: I6cf8e9bd20e83959bdf5ad58dd008b6e1187d7d8
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move a bunch of quit-related things to event-top.{c,h}
	Move some declarations related to the "quit" machinery from defs.h to
	event-top.h.  Most of the definitions associated to these declarations
	are in event-top.c.  The exceptions are `quit()` and `maybe_quit()`,
	that are defined in utils.c.  For consistency, move these two
	definitions to event-top.c.

	Include "event-top.h" in many files that use these things.

	Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: change type of quit_flag to bool
	Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: change return type of check_quit_flag to bool
	Change the return type of the check_quit_flag function to bool.  Update
	a few related spots.

	Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move declarations of check_quit_flag and set_quit_flag to extension.h
	Move them out of defs.h, to extension.h, since the implementations are
	in extension.c.

	Change-Id: Ie7321468bd7fecc684d70b09f72c3ee8ac75d8f4
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused include in infrun.c
	Remove the gdbcmd.h, which is reported as unused by clangd.  Add
	cli/cli-cmds.h instead, to get access to `cmdlist` and friends.

	Change-Id: Ic0c60d2f6d3618f1bd9fd80b95ffd7c33c692a04

2024-04-23  Waqar Hameed  <whame91@gmail.com>

	objdump: Round ASCII art lines in jump visualization

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2/read.c: remove pessimizing std::move
	When building with this clang:

	    $ c++ --version
	    FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)

	I see:

	    $ gmake
	      CXX    dwarf2/read.o
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
	                                            std::move (thread_storage.release_parent_map ()));
	                                            ^
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: note: remove std::move call here
	                                            std::move (thread_storage.release_parent_map ()));
	                                            ^~~~~~~~~~~                                    ~

	The compiler seems right, there is not need to std::move the result of
	`release_parent_map ()`, it's already going to be an rvalue.  Remove the
	std::move.

	The issue isn't FreeBSD-specific, I see it on Linux as well when
	building hwith clang, I just noticed it on a FreeBSD build first.

	Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: bump black version to 24.4.0
	Run `pre-commit autoupdate`, this is the outcome.  There is no change in
	formatting of Python files.

	Change-Id: I977781fa6cc924c398cc3b9d9954dc0fbb95d082

2024-04-23  Alan Modra  <amodra@gmail.com>

	PR31667, objcopy/strip corrupts solaris binaries
	Using want_p_paddr_set_to_zero in commit 45d92439aebd was wrong.  Even
	solaris targets don't have want_p_paddr_set_to_zero, but we should
	handle them at least somewhat reasonably.

		PR 31667
		* elf.c (IS_SECTION_IN_INPUT_SEGMENT): Remove bed arg, add
		paddr_valid.  Don't use bed->want_p_paddr_set_to_zero.
		(INCLUDE_SECTION_IN_SEGMENT): Likewise.
		(rewrite_elf_program_header): Adjust to suit.

2024-04-23  Alan Modra  <amodra@gmail.com>

	ignore some symbols in elf.c:swap_out_syms
	The reason behind this patch was noticing that generic ELF targets
	fail to remove "bar" in the recently committed ld-elf/undefweak-1
	test.  (Despite that, those targets pass the test due to it being too
	strict when matching symbols.  "bar" gets turned into a local weak
	defined absolute symbol.)

	swap_out_syms currently drops local section syms that are defined in
	discarded sections.  Extend that to also drop other symbols in
	discarded sections too, even global symbols.  The linker goes to quite
	a lot of effort to ensure globals in discarded section take a
	definition from the kept linkonce or comdat group section.  So the
	global sym change should only affect cases where something is quite
	wrong about the set of linkonce or comdat group sections.  However
	that change to elf_map_symbols meant we dropped _DYNAMIC_LINK /
	_DYNAMIC_LINKING for mips, a global absolute symbol given STT_SECTION
	type for some reason.  That problem is fixed by reverting the pr14493
	change which is no longer needed due to a) BSF_SECTION_SYM_USED on
	x86, and b) fixing objcopy to use copy_private_symbol_data.

	bfd/
		PR 14493
		* elf.c (ignore_sym): Rename from ignore_section_sym.  Return
		true for any symbol without a section or in a discarded section.
		Revert pr14493 change.
		(elf_map_symbols): Tidy.  Use ignore_sym on all symbols.
		(swap_out_syms): Tidy.
	ld/
		* testsuite/ld-elf/undefweak-1.rd: Match any "bar".

2024-04-23  Alan Modra  <amodra@gmail.com>

	xfail undefweak-1 test for alpha
	".set" has a different meaning on alpha.  Changing it to ".equ" runs
	into ".equ" having a different meaning on hppa, and changing it to "="
	runs into trouble on bfin.

		* testsuite/ld-elf/elf.exp (undefweak-1): xfail on alpha,
		don't xfail for genelf.

2024-04-23  Alan Modra  <amodra@gmail.com>

	use copy_private_symbol_data in objcopy
	osympp appearing twice here is not a bug.

		PR 14493
		* objcopy.c (copy_object): Run the symbols through
		bfd_copy_private_symbol_data.

2024-04-23  Alan Modra  <amodra@gmail.com>

	copy_private_symbol_data
	bfd_copy_private_symbol_data is a bfd function that appeared in
	commit 89665c8562da a long time ago, but seemingly wasn't used
	anywhere until Jan added it to gas/symbols.c in commit 6a2b6326c21e.

	The function is used to modify ELF symbol st_shndx for symbols defined
	in odd sections like .symtab, so that they get the corresponding
	section st_shndx in an output file.  This patch fixes some bitrot in
	the function.  After commit c03551323c04 which introduced
	output_elf_obj_tdata, elf_strtab_sec and elf_shstrtab_sec will
	segfault if used on an input bfd.

		PR 14493
		* elf.c (_bfd_elf_copy_private_symbol_data): Don't use
		elf_strtab_sec and elf_shstrtab_sec.

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't include gdbsupport/array-view.h in defs.h
	Nothing in defs.h actually uses this.  Everything that I (and the
	buildbot) can compile still compiles, so I guess that all users of
	array_view already include it one way or another.  Worst case, if this
	causes some build failure, the fix will be one #include away.

	Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't include hashtab.h in defs.h
	Nothing in defs.h actually uses this.

	Add some includes for some spots using things from hashtab.h.  Note that
	if the GDB build doesn't use libxxhash, hashtab.h is included by
	gdbsupport/common-utils.h, so all files still see hashtab.h.  It puzzled
	me for some time why I didn't see build failures in my build (which
	didn't use libxxhash) but the buildbot gave build failures (it uses
	libxxhash).

	Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move RequireLongest to gdbsupport/traits.h
	Move it out of defs.h.

	Change-Id: Ie1743d41a57f81667650048563e66073c72230cf
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move store/extract integer functions to extract-store-integer.{c,h}
	Move the declarations out of defs.h, and the implementations out of
	findvar.c.

	I opted for a new file, because this functionality of converting
	integers to bytes and vice-versa seems a bit to generic to live in
	findvar.c.

	Change-Id: I524858fca33901ee2150c582bac16042148d2251
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove extract_long_unsigned_integer
	It is unused.

	Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move `enum compile_i_scope_types` to compile/compile.h
	Move it out of defs.h, adjust the includes here and there.

	Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move two declarations out of defs.h
	Move declarations of initialize_progspace and initialize_inferiors to
	progspace.h and inferior.h, respectively.

	Change-Id: I62292ffda429861b9f27d8c836a56d161dfa548d
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-22  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Use default gdb_expect timeout in runto
	runto uses a hard-coded timeout of 30s in its invocation of gdb_expect.
	This is normally fine, but for very a slow system (e.g., an emulator) it
	may not be enough time for GDB to reach the intended breakpoint.

	gdb_expect can obtain a timeout value from user-configurable variables
	when it's not given one explicitly, so use that mechanism instead since
	the user will have already adjusted the timeout variable to account for
	the slow system.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-22  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix unknown variable typo in c-exp.y
	Fix 'val' -> 'value' typo in c-exp.y which was breaking the build.
	Introduced in commit:

	  commit e6375bc8ebbbc177c79f08e9616eb0b131229f65
	  Date:   Wed Apr 17 16:17:33 2024 -0600

	      Remove some alloca uses

2024-04-22  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Fix coding style issue in `aarch64-dis.c'
	Fix integer value being returned from boolean function, as introduced
	in `aarch64: Remove asserts from operand qualifier decoders [PR31595]'.

2024-04-22  Tom Tromey  <tom@tromey.com>

	Use std::vector in event-loop.cc
	In my occasional and continuing campaign against realloc, this patch
	changes event-loop.cc to use std::vector to keep track of pollfd
	objects.  Regression tested on x86-64 Fedora 38.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-22  Cui, Lili  <lili.cui@intel.com>

	x86/APX: Add invalid check for APX EVEX.X4.
	gas/ChangeLog:

	        * config/tc-i386.c (build_apx_evex_prefix): Added invalid check for APX
	        X4.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added invalid
	        testcase.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis.c (get_valid_dis386): Added invalid check for APX X4.

2024-04-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-21  Tom Tromey  <tom@tromey.com>

	Remove a couple of VLAs
	I found a couple of spots where VLAs are in use but where they can
	easily be removed.

	In one spot, adding 'const' is enough -- and is already done in
	similar code elsewhere in the file.

	In another spot, one of two arrays will be used, so making the buffer
	large enough for both works.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-21  Tom Tromey  <tom@tromey.com>

	Remove some alloca uses
	A few spots (mostly in the parsers) use alloca to ensure that a string
	is terminated before passing it to a printf-like function (mostly
	'error').  However, this isn't needed as the "%.*s" format can be used
	instead.

	This patch makes this change.

	In one spot the alloca is dead code and is simply removed.

	Regression tested on x86-64 Fedora 38.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-20  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add -mignore-start-align option
	Ignore .align at the start of a section may result in misalignment when
	partial linking. Manually add -mignore-start-align option without partial
	linking.

	Gcc -falign-functions add .align 5 to the start of a section, it causes some
	error message mismatch. Set these testcases to xfail on LoongArch target.

2024-04-20  Alan Modra  <amodra@gmail.com>

	Error compiling libctf-regression test
	Seen on 64-bit targets.
	ERROR: compilation of lookup program .../libctf-regression/gzrewrite.c failed

		* testsuite/libctf-regression/gzrewrite.c (main): Use %zu to
		print size_t values.
		* testsuite/libctf-regression/zrewrite.c (main): Likewise.

2024-04-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add target_debug_printf and target_debug_printf_nofunc
	Add the `target_debug_printf` and `target_debug_printf_nofunc` macros
	and use them when outputting debug messages depending on `targetdebug`.
	I opted for `target_debug_printf_nofunc` to follow the current style
	where the function name is already printed, along with the arguments.

	Modify the debug printfs in the `debug_target` methods (generated by
	`make-target-delegates.py`) to use `target_debug_printf_nofunc` as well.

	This makes the "target" debug prints integrate nicely with the other
	debug prints that use the "new" debug print system:

	    [infrun] proceed: enter
	      [infrun] follow_fork: enter
	        [target] -> multi-thread->record_will_replay (...)
	        [target] <- multi-thread->record_will_replay (-1, 0) = false
	        [target] -> multi-thread->supports_multi_process (...)
	        [target] <- multi-thread->supports_multi_process () = true
	      [infrun] follow_fork: exit
	      ...

	Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make regcache::debug_print_register return a string
	Rename the method to `register_debug_string`.

	This makes it easier to introduce `target_debug_printf` in a subsequent
	patch.

	Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make debug_target use one-liners
	Turn the debug prints in debug_target's method to be one liners.  For
	instance, change this:

	    gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ());
	    gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog);
	    gdb_puts (", ", gdb_stdlog);
	    gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog);
	    gdb_puts (", ", gdb_stdlog);
	    gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog);
	    gdb_puts (") = ", gdb_stdlog);
	    target_debug_print_ptid_t (result);
	    gdb_puts ("\n", gdb_stdlog);

	into this:

	    gdb_printf (gdb_stdlog,
	               "<- %s->wait (%s, %s, %s) = %s\n",
	               this->beneath ()->shortname (),
	               target_debug_print_ptid_t (arg0).c_str (),
	               target_debug_print_target_waitstatus_p (arg1).c_str (),
	               target_debug_print_target_wait_flags (arg2).c_str (),
	               target_debug_print_ptid_t (result).c_str ());

	This makes it possible for a subsequent patch to turn this gdb_printf
	call into a `target_debug_printf` call.

	Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make target debug functions return std::string
	Change the functions in target-debug.h to return string representations
	in an std::string, such that they don't need to know how the printing
	part is done.  This also helps the following patch that makes the debug
	prints in debug_target one-liners.

	Update target-delegates.c (through make-target-delegates.py) to do the
	printing.

	Add an overload of gdb_puts to avoid using `.c_str ()`.

	Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix include for gdb_signal in target/waitstatus.h
	clangd tells me that the gdb_signals.h include in target/waitstatus.h is
	unused.  This include was probably to give access to `enum gdb_signal`,
	but this is in fact defined in gdb/signals.h.  Change the include to
	gdb/signals.h.  Include gdbsupport/gdb_signals.h in some files that were
	relying on the transitive include.

	Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: convert target debug macros to functions
	Convert all the macros to static functions.  Some macros were unused,
	and now that they are functions, got flagged by the compiler, so I
	omitted them.

	No behavior change expected.

	Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add includes in target-debug.h
	Editing target-debug.h with clangd shows a bunch of errors.  Add some
	includes to fix that (make target-debug.h include what it uses).

	Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: do not include undefined functions in libctf.ver
	libctf's version script is applied to two libraries: libctf.so,
	and libctf-nobfd.so.  The latter library is a subset of the former
	which does not link to libbfd and does not include a few public
	entry points that use it (found in libctf-open-bfd.c).  This means
	that some of the symbols in this version script only exist in one
	of the libraries it's applied to.

	A number of linkers dislike this: before now, only Solaris's linker
	caused serious problems, introducing NOTYPE-typed symbols when such
	things were found, but now LLD has started to complain as well:

	ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined
	ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined
	ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined
	ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined
	ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined

	Rather than adding more and more whack-a-mole fixes for every
	linker we encounter that does this, simply exclude such symbols
	unconditionally, using the same trick we used to use for Solaris.
	(Well, unconditionally if we can use version scripts with this
	linker at all, which is not always the case.)

	Thanks to Nicholas Vinson for the original report and a fix very
	similar to this one (but not quite identical).

	libctf/

		* configure.ac: Always exclude libctf symbols from
		libctf-nobfd's version script.
		* configure: Regenerated.

2024-04-19  Nicholas Vinson  <nvinson234@gmail.com>

	libctf: Remove undefined functions from ver. map
	Starting with ld.lld-17, ld.lld is invoked with the option
	--no-undefined-version enabled by default. Furthermore, The functions
	ctf_label_set() and ctf_label_get() are not defined. Their inclusion in
	libctf/libctf.ver causes ld.lld-17 to fail emitting the following error
	messages:

	ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined
	ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined

	This patch fixes the issue by removing the symbol names from
	libctf/libctf.ver.

	[nca: fused in later commit that marked ctf_arc_open as libctf
	      only as well.  Added ChangeLog entry.]


	libctf/
		* libctf.ver: drop nonexistent label functions: mark
		ctf_arc_open as libctf-only.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: don't pass errno into ctf_err_warn so often
	The libctf-internal warning function ctf_err_warn() can be passed a libctf
	errno as a parameter, and will add its textual errmsg form to the passed-in
	error message. But if there is an error on the fp already, and this is
	specifically an error and not a warning, ctf_err_warn() will print the error
	out regardless: there's no need to pass in anything but 0.

	There are still a lot of places where we do

	ctf_err_warn (fp, 0, EFOO, ...);
	return ctf_set_errno (fp, 0, EFOO);

	I've left all of those alone, because fixing it makes the code a bit longer:
	but fixing the cases where no return is involved and the error has just been
	set on the fp itself costs nothing and reduces redundancy a bit.

	libctf/

		* ctf-dedup.c (ctf_dedup_walk_output_mapping): Drop the errno arg.
		(ctf_dedup_emit): Likewise.
		(ctf_dedup_type_mapping): Likewise.
		* ctf-link.c (ctf_create_per_cu): Likewise.
		(ctf_link_deduplicating_close_inputs): Likewise.
		(ctf_link_deduplicating_one_symtypetab): Likewise.
		(ctf_link_deduplicating_per_cu): Likewise.
		* ctf-lookup.c (ctf_lookup_symbol_idx): Likewise.
		* ctf-subr.c (ctf_assert_fail_internal): Likewise.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix leak in test
	This purely serves to make it easier to interpret valgrind output.
	No functional effect.

	libctf/
		* testsuite/libctf-lookup/conflicting-type-syms.c: Free everything.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: add rewriting tests
	Now there's a chance of it actually working, we can add more tests for
	the long-broken dict read-and-rewrite cases.  This is the first ever
	test for the (rarely-used, unpleasant, and until recently completely
	broken) ctf_gzwrite function.

	libctf/

		* testsuite/libctf-regression/gzrewrite*: New test.
		* testsuite/libctf-regression/zrewrite*: Likewise.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix a debugging typo
	libctf/

		* ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: make ctf_lookup of symbols by name work in more cases
	In particular, we don't need a symbol table if we're looking up a
	symbol by name and that type of symbol has an indexed symtypetab,
	since in that case we get the name from the symtypetab index, not
	from the symbol table.

	This lets you do symbol lookups in unlinked object files and unlinked
	dicts written out via libctf's writeout functions.

	libctf/

		* ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups
		by index even when there is no symtab.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: improve handling of type dumping errors
	When dumping a type fails with an error, we want to emit a warning noting
	this: a warning because it's not fatal and we can continue.  But warnings
	don't automatically print out the ctf_errno (because not all cases causing
	warnings set the errno at all), so we must do it at warning-emission time or
	lose track of what's gone wrong.

	libctf/

		* ctf-dump.c (ctf_dump_format_type): Dump the underlying error on
		type dump failure.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix tiny dumping error
	Without this, you might get things like this in the output:

	    Flags: 0xa (CTF_F_NEWFUNCINFO, , CTF_F_DYNSTR)

	Note the spurious comma.

	libctf/
		* ctf-dump.c (ctf_dump_header): Fix comma emission.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: make ctf_serialize() actually serialize
	ctf_serialize() evolved from the old ctf_update(), which mutated the
	in-memory CTF dict to make all the dynamic in-memory types into static,
	unchanging written-to-the-dict types (by deserializing and reserializing
	it): back in the days when you could only do type lookups on static types,
	this meant you could see all the types you added recently, at the small,
	small cost of making it impossible to change those older types ever again
	and inducing an amortized O(n^2) cost if you actually wanted to add
	references to types you added at arbitrary times to later types.

	It also reset things so that ctf_discard() would throw away only types you
	added after the most recent ctf_update() call.

	Some time ago this was all changed so that you could look up dynamic types
	just as easily as static types: ctf_update() changed so that only its
	visible side-effect of affecting ctf_discard() remained: the old
	ctf_update() was renamed to ctf_serialize(), made internal to libctf, and
	called from the various functions that wrote files out.

	... but it was still working by serializing and deserializing the entire
	dict, swapping out its guts with the newly-serialized copy in an invasive
	and horrible fashion that coupled ctf_serialize() to almost every field in
	the ctf_dict_t.  This is totally useless, and fixing it is easy: just rip
	all that code out and have ctf_serialize return a serialized representation,
	and let everything use that directly.  This simplifies most of its callers
	significantly.

	(It also points up another bug: ctf_gzwrite() failed to call ctf_serialize()
	at all, so it would only ever work for a dict you just ctf_write_mem()ed
	yourself, just for its invisible side-effect of serializing the dict!)

	This lets us simplify away a bunch of internal-only open-side functionality
	for overriding the syn_ext_strtab and some just-added functionality for
	forcing in an existing atoms table, without loss of functionality, and lets
	us lift the restriction on reserializing a dict that was ctf_open()ed rather
	than being ctf_create()d: it's now perfectly OK to open a dict, modify it
	(except for adding members to existing structs, unions, or enums, which
	fails with -ECTF_RDONLY), and write it out again, just as one would expect.

	libctf/

		* ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos.
		(ctf_type_sect_size): Add static type sizes too.
		(ctf_serialize): Return the new dict rather than updating the
		existing dict.  No longer fail for dicts with static types;
		copy them onto the start of the new types table.
		(ctf_gzwrite): Actually serialize before gzwriting.
		(ctf_write_mem): Improve forced (test-mode) endian-flipping:
		flip dicts even if they are too small to be compressed.
		Improve confusing variable naming.
		* ctf-archive.c (arc_write_one_ctf): Don't bother to call
		ctf_serialize: both the functions we call do so.
		* ctf-string.c (ctf_str_create_atoms): Drop serializing case
		(atoms arg).
		* ctf-open.c (ctf_simple_open): Call ctf_bufopen directly.
		(ctf_simple_open_internal): Delete.
		(ctf_bufopen_internal): Delete/rename to ctf_bufopen: no
		longer bother with syn_ext_strtab or forced atoms table,
		serialization no longer needs them.
		* ctf-create.c (ctf_create): Call ctf_bufopen directly.
		* ctf-impl.h (ctf_str_create_atoms): Drop atoms arg.
		(ctf_simple_open_internal): Delete.
		(ctf_bufopen_internal): Likewise.
		(ctf_serialize): Adjust.
		* testsuite/libctf-lookup/add-to-opened.c: Adjust now that
		this is supposed to work.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: rethink strtab writeout
	This commit finally adjusts strtab writeout so that repeated writeouts, or
	writeouts of a dict that was read in earlier, only sorts the portion of the
	strtab that was newly added.

	There are three intertwined changes here:

	 - pull the contents of strtabs from newly ctf_bufopened dicts into the
	   atoms table, so that future additions will reuse the existing offset etc
	   rather than adding new identical strings
	 - allow the internal ctf_bufopen done by serialization to contribute its
	   existing atoms table, so that existing atoms can be used for the
	   remainder of the open process (like name table construction): this atoms
	   table currente gets thrown away in the mass reassignment done later in
	   ctf_serialize in any case, but it needs to be there during the open.
	 - rewrite ctf_str_write_strtab so that a) it uses iterators rather than
	   ctf_*_iter, reducing pointless structures which serve no other purpose
	   than to implement ordinary variable scope, but more clunkily, and b)
	   retains the existing strtab on the front of the new one, with its sort
	   retained, rather than resorting, so all existing already-written strtab
	   offsets remain valid across the call.

	This latter change finally permits repeated serializations, and
	reserializations of ctf_open()ed dicts, to work, but for now we keep the
	code that prevents that because serialization is about to change again in a
	way that will make it more obvious that doing such things is safe, and we
	can take it out then.

	(There are also some smaller changes like moving the purge of the refs table
	into ctf_str_write_strtab(), since that's where the changes happen that
	invalidate it, rather than doing it in ctf_serialize().  We also prohibit
	something that has never worked, opening a dict and then reporting symbols
	to it via ctf_link_add_strtab() et al: you must do that to newly-created
	dicts which have had stuff ctf_link()ed into them.  This is very unlikely
	ever to be a problem in practice: linkers just don't do that sort of thing.)

	libctf/

		* ctf-create.c (ctf_create): Add (temporary) atoms arg.
		* ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New.
		(ctf_str_create_atoms): Adjust.
		(ctf_str_write_strtab): Likewise.
		(ctf_simple_open_internal): Likewise.
		* ctf-open.c (ctf_simple_open_internal): Add atoms arg.
		(ctf_bufopen): Likewise.
		(ctf_bufopen_internal): Initialize just enough of an
		atoms table: pre-init from the atoms arg if supplied.
		(ctf_simple_open): Adjust.
		* ctf-serialize.c (ctf_serialize): Constify the strtab.
		Move ref list purging into ctf_str_write_strtab.
		Initialize the new dict with the old dict's atoms table.
		Accept the new strtab from ctf_str_write_strtab.
		Adjust for addition of ctf_dynstrtab.
		* ctf-string.c (ctf_strraw_explicit): Improve comments.
		(ctf_str_create_atoms): Prepopulate from an existing atoms table,
		or alternatively pull in all strings from the strtab and turn
		them into atoms.
		(ctf_str_free_atoms): Free the dynstrtab and its strtab.
		(struct ctf_strtab_write_state): Remove.
		(ctf_str_count_strtab): Fold this...
		(ctf_str_populate_sorttab): ... and this...
		(ctf_str_write_strtab): ... into this.  Prepend existing strings
		to the strtab rather than resorting them (and wrecking their
		offsets).  Keep the dynstrtab updated.  Update refs for all
		atoms with refs, whether or not they are strings newly added
		to the strtab.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: replace 'pending refs' abstraction
	A few years ago we introduced a 'pending refs' abstraction to fix one
	problem: serializing a dict, then changing it would tend to corrupt the dict
	because the strtab sort we do on strtab writeout (to improve compression
	efficiency) would modify the offset of any strings that sorted
	lexicographically earlier in the strtab: so we added a new restriction that
	all strings are added only at serialization time, and maintained a set of
	'pending' refs that were added earlier, whose offsets we could update (like
	other refs) at writeout time.

	This was in hindsight seriously problematic for maintenance (because
	serialization has to traverse all strings in all datatypes in the entire
	dict), and has become impossible to sustain now that we can read in existing
	dicts, modify them, and reserialize them again.  We really don't want to
	have to dig through the entire dict we jut read in just in order to dig out
	all its strtab offsets, then *change* it, just for the sake of a sort that
	adds a frankly trivial amount of compression efficiency.

	Sorting *is* still worthwhile -- but it sacrifices very little to only sort
	newly-added portions of the strtab, reusing older portions as necessary.
	As a first stage in this, discard the whole "pending refs" abstraction and
	replace it with "movable" refs, which are exactly like all other refs
	(addresses containing the strtab offset of some string, which are updated
	wiht the final strtab offset on serialization) except that we track them in
	a reverse dict so that we can move the refs around (which we do whenever we
	realloc() a buffer containing a bunch of structure members or something when
	we add members to the structure).

	libctf/

		* ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add
	        a movable ref.
		(ctf_add_member_offset): Likewise.
		* ctf-util.c (ctf_realloc): Delete.
		* ctf-serialize.c (ctf_serialize): No longer use it.  Adjust to
		new fields.
		* ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs.
		(ctf_str_free_atom): Free freeable atoms' strings.
		(ctf_str_create_atoms): Create the movable refs dynhash if needed.
		(ctf_str_free_atoms): Destroy it.
		(CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous
		reversion).  Add new flag.
		(aref_create):  New, populate movable refs if need be.
		(ctf_str_add_ref_internal): Switch back to flags, update refs
		directly for nonprovisional strings (with already-known fixed offsets);
		create refs via aref_create.  Allocate strings only if not within an
		mmapped strtab.
		(ctf_str_add_movable_ref): New.
		(ctf_str_add): Adjust to CTF_STR_* reintroduction.
		(ctf_str_add_external): LIkewise.
		(ctf_str_move_refs): New, move refs via ctf_str_movable_refs
		backpointer.
		(ctf_str_purge_refs): Drop ctf_str_num_refs.
		(ctf_str_update_refs): Fix indentation.
		* ctf-impl.h (struct ctf_str_atom_movable): New.
		(struct ctf_dict.ctf_str_num_refs): Drop.
		(struct ctf_dict.ctf_str_movable_refs): New.
		(ctf_str_add_movable_ref): Declare.
		(ctf_str_move_refs): Likewise.
		(ctf_realloc): Drop.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	Revert "libctf: do not corrupt strings across ctf_serialize"
	This reverts commit 986e9e3aa03f854bedacef7fac38fe8f009a416c.

	(We do not revert the testcase -- it remains valid -- but we are
	taking a different, less complex and more robust approach.)

	This also deletes the pending refs abstraction without (yet)
	replacing it, so some tests will fail for a commit or two.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: rename ctf_dict.ctf_{symtab,strtab}
	These two fields are constantly confusing because CTF dicts contain both
	a symtypetab and strtab, but these fields are not that: they are the
	symtab and strtab from the ELF file.  We have enough string tables now
	(internal, external, synthetic external, dynamic) that we need to at
	least name them better than this to avoid getting totally confused.
	Rename them to ctf_ext_symtab and ctf_ext_strtab.

	libctf/

		* ctf-dump.c (ctf_dump_objts): Rename ctf_symtab -> ctf_ext_symtab.
		* ctf-impl.h (struct ctf_dict.ctf_symtab): Rename to...
		(struct ctf_dict.ctf_ext_strtab): ... this.
		(struct ctf_dict.ctf_strtab): Rename to...
		(struct ctf_dict.ctf_ext_strtab): ... this.
		* ctf-lookup.c (ctf_lookup_symbol_name): Adapt.
		(ctf_lookup_symbol_idx): Adapt.
		(ctf_lookup_by_sym_or_name): Adapt.
		* ctf-open.c (ctf_bufopen_internal): Adapt.
		(ctf_dict_close): Adapt.
		(ctf_getsymsect): Adapt.
		(ctf_getstrsect): Adapt.
		(ctf_symsect_endianness): Adapt.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix a comment typo
	ctf_update has been called ctf_serialize for years now.

	libctf/

		* ctf-impl.h: Fix comment typo.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: delete LCTF_DIRTY
	This flag was meant as an optimization to avoid reserializing dicts
	unnecessarily.  It was critically necessary back when serialization was
	done by ctf_update() and you had to call that every time you wanted any
	new modifications to the type table to be usable by other types, but
	that has been unnecessary for years now, and serialization is only done
	once when writing out, which one would naturally assume would always
	serialize the dict.  Worse, it never really worked: it only tracked
	newly-added types, not things like added symbols which might equally
	well require reserialization, and it gets in the way of an upcoming
	change.  Delete entirely.

	libctf/

		* ctf-create.c (ctf_create): Drop LCTF_DIRTY.
		(ctf_discard): Likewise.
		(ctf_rollback): Likewise.
		(ctf_add_generic): Likewise.
		(ctf_set_array): Likewise.
		(ctf_add_enumerator): Likewise.
		(ctf_add_member_offset): Likewise.
		(ctf_add_variable_forced): Likewise.
		* ctf-link.c (ctf_link_intern_extern_string): Likewise.
		(ctf_link_add_strtab): Likewise.
		* ctf-serialize.c (ctf_serialize): Likewise.
		* ctf-impl.h (LCTF_DIRTY): Likewise.
		(LCTF_LINKING): Renumber.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix a comment
	A mistaken "not" in ctf_err_warn made it seem like we only extracted
	error messages if this was not an error.

	libctf/

		* ctf-subr.c (ctf_err_warn): Fix comment.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: support addition of types to dicts read via ctf_open()
	libctf has long declared deserialized dictionaries (out of files or ELF
	sections or memory buffers or whatever) to be read-only: back in the
	furthest prehistory this was not the case, in that you could add a
	few sorts of type to such dicts, but attempting to do so often caused
	horrible memory corruption, so I banned the lot.

	But it turns out real consumers want it (notably DTrace, which
	synthesises pointers to types that don't have them and adds them to the
	ctf_open()ed dicts if it needs them). Let's bring it back again, but
	without the memory corruption and without the massive code duplication
	required in days of yore to distinguish between static and dynamic
	types: the representation of both types has been identical for a few
	years, with the only difference being that types as a whole are stored in
	a big buffer for types read in via ctf_open and per-type hashtables for
	newly-added types.

	So we discard the internally-visible concept of "readonly dictionaries"
	in favour of declaring the *range of types* that were already present
	when the dict was read in to be read-only: you can't modify them (say,
	by adding members to them if they're structs, or calling ctf_set_array
	on them), but you can add more types and point to them.  (The API
	remains the same, with calls sometimes returning ECTF_RDONLY, but now
	they do so less often.)

	This is a fairly invasive change, mostly because code written since the
	ban was introduced didn't take the possibility of a static/dynamic split
	into account.  Some of these irregularities were hard to define as
	anything but bugs.

	Notably:

	 - The symbol handling was assuming that symbols only needed to be
	   looked for in dynamic hashtabs or static linker-laid-out indexed/
	   nonindexed layouts, but now we want to check both in case people
	   added more symbols to a dict they opened.

	 - The code that handles type additions wasn't checking to see if types
	   with the same name existed *at all* (so you could do
	   ctf_add_typedef (fp, "foo", bar) repeatedly without error).  This
	   seems reasonable for types you just added, but we probably *do* want
	   to ban addition of types with names that override names we already
	   used in the ctf_open()ed portion, since that would probably corrupt
	   existing type relationships.  (Doing things this way also avoids
	   causing new errors for any existing code that was doing this sort of
	   thing.)

	 - ctf_lookup_variable entirely failed to work for variables just added
	   by ctf_add_variable: you had to write the dict out and read it back
	   in again before they appeared.

	 - The symbol handling remembered what symbols you looked up but didn't
	   remember their types, so you could look up an object symbol and then
	   find it popping up when you asked for function symbols, which seems
	   less than ideal.  Since we had to rejig things enough to be able to
	   distinguish function and object symbols internally anyway (in order
	   to give suitable errors if you try to add a symbol with a name that
	   already existed in the ctf_open()ed dict), this bug suddenly became
	   more visible and was easily fixed.

	We do not (yet) support writing out dicts that have been previously read
	in via ctf_open() or other deserializer (you can look things up in them,
	but not write them out a second time).  This never worked, so there is
	no incompatibility; if it is needed at a later date, the serializer is a
	little bit closer to having it work now (the only table we don't deal
	with is the types table, and that's because the upcoming CTFv4 changes
	are likely to make major changes to the way that table is represented
	internally, so adding more code that depends on its current form seems
	like a bad idea).

	There is a new testcase that tests much of this, in particular that
	modification of existing types is still banned and that you can add new
	ones and chase them without error.

	libctf/

		* ctf-impl.h (struct ctf_dict.ctf_symhash): Split into...
		(ctf_dict.ctf_symhash_func): ... this and...
		(ctf_dict.ctf_symhash_objt): ... this.
		(ctf_dict.ctf_stypes): New, counts static types.
		(LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR.
		(LCTF_RDWR): Deleted.
		(LCTF_DIRTY): Renumbered.
		(LCTF_LINKING): Likewise.
		(ctf_lookup_variable_here): New.
		(ctf_lookup_by_sym_or_name): Likewise.
		(ctf_symbol_next_static): Likewise.
		(ctf_add_variable_forced): Likewise.
		(ctf_add_funcobjt_sym_forced): Likewise.
		(ctf_simple_open_internal): Adjust.
		(ctf_bufopen_internal): Likewise.
		* ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with.
		(ctf_create): Migrate a bunch of initializations into bufopen.
		Force recreation of name tables.  Do not forcibly override the
		model, let ctf_bufopen do it.
		(ctf_static_type): New.
		(ctf_update): Drop LCTF_RDWR check.
		(ctf_dynamic_type): Likewise.
		(ctf_add_function): Likewise.
		(ctf_add_type_internal): Likewise.
		(ctf_rollback): Check ctf_stypes, not LCTF_RDWR.
		(ctf_set_array): Likewise.
		(ctf_add_struct_sized): Likewise.
		(ctf_add_union_sized): Likewise.
		(ctf_add_enum): Likewise.
		(ctf_add_enumerator): Likewise (only on the target dict).
		(ctf_add_member_offset): Likewise.
		(ctf_add_generic): Drop LCTF_RDWR check.  Ban addition of types
		with colliding names.
		(ctf_add_forward): Note safety under the new rules.
		(ctf_add_variable): Split all but the existence check into...
		(ctf_add_variable_forced): ... this new function.
		(ctf_add_funcobjt_sym): Likewise...
		(ctf_add_funcobjt_sym_forced): ... for this new function.
		* ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts
		with any stypes.
		(ctf_link_add_strtab): Likewise.
		(ctf_link_shuffle_syms): Likewise.
		(ctf_link_intern_extern_string): Note pre-existing prohibition.
		* ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check.
		(ctf_lookup_variable): Split out looking in a dict but not
		its parent into...
		(ctf_lookup_variable_here): ... this new function.
		(ctf_lookup_symbol_idx): Track whether looking up a function or
		object: cache them separately.
		(ctf_symbol_next): Split out looking in non-dynamic symtypetab
		entries to...
		(ctf_symbol_next_static): ... this new function.  Don't get confused
		by the simultaneous presence of static and dynamic symtypetab entries.
		(ctf_try_lookup_indexed):  Don't waste time looking up symbols by
		index before there can be any idea how symbols are numbered.
		(ctf_lookup_by_sym_or_name): Distinguish between function and
		data object lookups.  Drop LCTF_RDWR.
		(ctf_lookup_by_symbol): Adjust.
		(ctf_lookup_by_symbol_name): Likewise.
		* ctf-open.c (init_types): Rename to...
		(init_static_types): ... this.  Drop LCTF_RDWR.  Populate ctf_stypes.
		(ctf_simple_open): Drop writable arg.
		(ctf_simple_open_internal): Likewise.
		(ctf_bufopen): Likewise.
		(ctf_bufopen_internal): Populate fields only used for writable dicts.
		Drop LCTF_RDWR.
		(ctf_dict_close): Cater for symhash cache split.
		* ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR.
		* ctf-types.c (ctf_variable_next): Drop LCTF_RDWR.
		* testsuite/libctf-lookup/add-to-opened*: New test.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix name lookup in dicts containing base-type bitfields
	The intent of the name lookup code was for lookups to yield non-bitfield
	basic types except if none existed with a given name, and only then
	return bitfield types with that name.  Unfortunately, the code as
	written only does this if the base type has a type ID higher than all
	bitfield types, which is most unlikely (the opposite is almost always
	the case).

	Adjust it so that what ends up in the name table is the highest-width
	zero-offset type with a given name, if any such exist, and failing that
	the first type with that name we see, no matter its offset.  (We don't
	define *which* bitfield type you get, after all, so we might as well
	just stuff in the first we find.)

	Reported by Stephen Brennan <stephen.brennan@oracle.com>.

	libctf/

		* ctf-open.c (init_types): Modify to allow some lookups during open;
		detect bitfield name reuse and prefer less bitfieldy types.
		* testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: remove static/dynamic name lookup distinction
	libctf internally maintains a set of hash tables for type name lookups,
	one for each valid C type namespace (struct, union, enum, and everything
	else).

	Or, rather, it maintains *two* sets of hash tables: one, a ctf_hash *,
	is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the
	other, a ctf_dynhash *, is meant for lookups in ctf_create()d dicts.

	This distinction was somewhat valuable in the far pre-binutils past when
	two different hashtable implementations were used (one expanding, the
	other fixed-size), but those days are long gone: the hash table
	implementations are almost identical, both wrappers around the libiberty
	hashtab. The ctf_dynhash has many more capabilities than the ctf_hash
	(iteration, deletion, etc etc) and has no downsides other than starting
	at a fixed, arbitrary small size.

	That limitation is easy to lift (via a new ctf_dynhash_create_sized()),
	following which we can throw away nearly all the ctf_hash
	implementation, and all the code to choose between readable and writable
	hashtabs; the few convenience functions that are still useful (for
	insertion of name -> type mappings) can also be generalized a bit so
	that the extra string verification they do is potentially available to
	other string lookups as well.

	(libctf still has two hashtable implementations, ctf_dynhash, above,
	and ctf_dynset, which is a key-only hashtab that can avoid a great many
	malloc()s, used for high-volume applications in the deduplicator.)

	libctf/

		* ctf-create.c (ctf_create): Eliminate ctn_writable.
		(ctf_dtd_insert): Likewise.
		(ctf_dtd_delete): Likewise.
		(ctf_rollback): Likewise.
		(ctf_name_table): Eliminate ctf_names_t.
		* ctf-hash.c (ctf_dynhash_create): Comment update.
	        Reimplement in terms of...
		(ctf_dynhash_create_sized): ... this new function.
		(ctf_hash_create): Remove.
		(ctf_hash_size): Remove.
		(ctf_hash_define_type): Remove.
		(ctf_hash_destroy): Remove.
		(ctf_hash_lookup_type): Rename to...
		(ctf_dynhash_lookup_type): ... this.
		(ctf_hash_insert_type): Rename to...
		(ctf_dynhash_insert_type): ... this, moving validation to...
		* ctf-string.c (ctf_strptr_validate): ... this new function.
		* ctf-impl.h (struct ctf_names): Extirpate.
		(struct ctf_lookup.ctl_hash): Now a ctf_dynhash_t.
		(struct ctf_dict): All ctf_names_t fields are now ctf_dynhash_t.
		(ctf_name_table): Now returns a ctf_dynhash_t.
		(ctf_lookup_by_rawhash): Remove.
		(ctf_hash_create): Likewise.
		(ctf_hash_insert_type): Likewise.
		(ctf_hash_define_type): Likewise.
		(ctf_hash_lookup_type): Likewise.
		(ctf_hash_size): Likewise.
		(ctf_hash_destroy): Likewise.
		(ctf_dynhash_create_sized): New.
		(ctf_dynhash_insert_type): New.
		(ctf_dynhash_lookup_type): New.
		(ctf_strptr_validate): New.
		* ctf-lookup.c (ctf_lookup_by_name_internal): Adapt.
		* ctf-open.c (init_types): Adapt.
		(ctf_set_ctl_hashes): Adapt.
		(ctf_dict_close): Adapt.
		* ctf-serialize.c (ctf_serialize): Adapt.
		* ctf-types.c (ctf_lookup_by_rawhash): Remove.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	libctf: don't leak the symbol name in the name->type cache
	This cache replaced a cache of symbol index->ctf_id_t. That cache was
	just an array, so it could get away with just being free()d, but the
	ctfi_symnamedicts cache that replaced it is a full dynhash with a
	dynamically-allocated string as the key.  As such, it needs freeing with
	ctf_dynhash_destroy(), not just free(), or we leak parts of the
	underlying hashtab, and all the keys.

	libctf/ChangeLog:

		* ctf-archive.c (ctf_arc_flush_caches): Fix leak.

2024-04-19  Nick Alcock  <nick.alcock@oracle.com>

	binutils, objdump: Add --ctf-parent-section
	This lets you examine CTF where the parent and child dicts are in entirely
	different sections, rather than in a CTF archive with members with different
	names.  The linker doesn't emit ELF objects structured like this, but some
	third-party linkers may; it's also useful for objcopy-constructed files
	in some cases.

	(This is what the objdump --ctf-parent option used to do before commit
	80b56fad5c99a8c9 in 2021.  The new semantics of that option are much more
	useful, but that doesn't mean the old ones are never useful at all, so let's
	bring them back.)

	(I was specifically driven to add this by DTrace's obscure "ctypes" and
	"dtypes" options, which dump its internal, dynamically-generated dicts out
	to files for debugging purposes: there are two, one the parent of the other.
	Since they're in two separate files rather than a CTF archive and we have no
	tools that paste files together into archives, objdump wouldn't show them --
	and even pasting them together into an ELF executable with objcopy didn't
	help, since objdump had no options that could be used to look in specific
	sections for the parent dict.  With --ctf-parent-section, this sort of
	obscure use case becomes possible again.  You'll never need it for the
	output of the normal linker.)

	binutils/

		* doc/ctf.options.texi: Add --ctf-parent-section=.
		* objdump.c (dump_ctf): Implement it.
		(dump_bfd): Likewise.
		(main): Likewise.

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: Document qIsAddressTagged packet
	This commit documents the qIsAddressTagged packet.

	Reviewed-by: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb/testsuite: Add unit tests for qIsAddressTagged packet
	Add unit tests for testing qIsAddressTagged packet request creation and
	reply checks.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: Add qIsAddressTagged packet
	This commit adds a new packet, qIsAddressTagged, allowing GDB remote
	targets to use it to query the stub if a given address is tagged.

	Currently, the memory tagging address check is done via a read query,
	where the contents of /proc/<PID>/smaps is read and the flags are
	inspected for memory tagging-related flags that indicate the address is
	in a memory tagged region.

	This is not ideal, for example, for QEMU stub and other cases, such as
	on bare-metal, where there is no notion of an OS file like 'smaps.'
	Hence, the introduction of qIsAddressTagged packet allows checking
	if an address is tagged in an agnostic way.

	The is_address_tagged target hook in remote.c attempts to use the
	qIsAddressTagged packet first for checking if an address is tagged and
	if the stub does not support such a packet (reply is empty) it falls
	back to using the current mechanism that reads the contents of
	/proc/<PID>/smaps via vFile requests.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: Introduce is_address_tagged target hook
	This commit introduces a new target hook, target_is_address_tagged,
	which is used instead of the gdbarch_tagged_address_p gdbarch hook in
	the upper layer (printcmd.c).

	This change enables easy specialization of memory tagging address
	check per target in the future. As target_is_address_tagged continues
	to utilize the gdbarch_tagged_address_p hook, there is no change in
	behavior for all the targets that use the new target hook (i.e., the
	remote.c, aarch64-linux-nat.c, and corelow.c targets).

	Just the gdbarch_tagged_address_p signature is changed for convenience,
	since target_is_address_tagged takes the address to be checked as a
	CORE_ADDR type.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: Use passed gdbarch instead of calling current_inferior
	In do_examine function, use passed gdbarch when checking if an address
	is tagged instead of calling current_inferior()->arch() to make the code
	more localized and help modularity by not calling a current_* function,
	which disguises the use of a global state/variable. There is no change
	in the code behavior.

	Suggested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: aarch64: Remove MTE address checking from memtag_matches_p
	This commit removes aarch64_linux_tagged_address_p from
	aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if
	an address is tagged (MTE) or not.

	The check is redundant because aarch64_linux_memtag_matches_p is always
	called from the upper layers (i.e. from printcmd.c via gdbarch hook
	gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that
	already points to aarch64_linux_tagged_address_p) has been called or
	after should_validate_memtags (that calls gdbarch_tagged_address_p at
	the end) has been called, so the address is already checked. Hence:

	a) in print_command_1, gdbarch_memtag_matches_p is called only after
	should_validate_memtags is called, which checks the address at its end;

	b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only
	after gdbarch_tagged_address_p is called directly.

	Also, because after this change the address checking only happens at the
	upper layer it now allows the address checking to be specialized easily
	per target, via a target hook.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: aarch64: Move MTE address check out of set_memtag
	Remove check in parse_set_allocation_tag_input as it is redundant:
	currently the check happens at the end of parse_set_allocation_tag_input
	and also in set_memtag (called after parse_set_allocation_tag_input).

	After it, move MTE address check out of set_memtag and add this check to
	the upper layer, before set_memtag is called.

	This is a preparation for using a target hook instead of a gdbarch hook
	on MTE address checks.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Gustavo Romero  <gustavo.romero@linaro.org>

	gdb: aarch64: Remove MTE address checking from get_memtag
	This commit removes aarch64_linux_tagged_address_p from
	aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an
	address is tagged (MTE) or not.

	The check is redundant because aarch64_linux_get_memtag is always called
	from the upper layers (i.e. from printcmd.c via gdbarch hook
	gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already
	points to aarch64_linux_tagged_address_p) has been called or
	after should_validate_memtags (that calls gdbarch_tagged_address_p at
	the end) has been called, so the address is already checked. Hence:

	a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag
	hook) is called but only after should_validate_memtags, which calls
	gdbarch_tagged_address_p;

	b) in do_examine, aarch64_linux_get_memtag is also called only after
	gdbarch_tagged_address_p is directly called;

	c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags
	matching or not -- after the initial check via direct call to
	gdbarch_tagged_address_p;

	d) in memory_tag_print_tag_command, address is checked directly via
	gdbarch_tagged_address_p before gdbarch_get_memtag is called.

	Also, because after this change the address checking only happens at the
	upper layer it now allows the address checking to be specialized easily
	per target, via a target hook.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-19  Alan Modra  <amodra@gmail.com>

	Re: elf: Strip unreferenced weak undefined symbols
		PR ld/31652
		* elflink.c (_bfd_elf_link_output_relocs): Don't segfault
		on NULL rel_hash.

2024-04-19  H.J. Lu  <hjl.tools@gmail.com>

	elf: Strip unreferenced weak undefined symbols
	Linker will resolve an undefined symbol only if it is referenced by
	relocation.  Unreferenced weak undefined symbols serve no purpose.
	Weak undefined symbols appear in the dynamic symbol table only when they
	are referenced by dynamic relocation.  Mark symbols with relocation and
	strip undefined weak symbols if they don't have relocation and aren't
	in the dynamic symbol table.

	bfd/

		PR ld/31652
		* elf-bfd.h (elf_link_hash_entry): Add has_reloc.
		* elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc.
		* elflink.c (_bfd_elf_link_output_relocs): Likewise.
		(elf_link_output_extsym): Strip undefined weak symbols if they
		don't have relocation and aren't in the dynamic symbol table.

	ld/

		PR ld/31652
		* testsuite/ld-elf/elf.exp: Run undefweak tests.
		* testsuite/ld-elf/undefweak-1.rd: New file.
		* testsuite/ld-elf/undefweak-1a.s: Likewise.
		* testsuite/ld-elf/undefweak-1b.s: Likewise.
		* testsuite/ld-x86-64/weakundef-1.nd: Likewise.
		* testsuite/ld-x86-64/weakundef-1a.s: Likewise.
		* testsuite/ld-x86-64/weakundef-1b.s: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run undefweak tests.

2024-04-19  Alan Modra  <amodra@gmail.com>

	memory leak in bfd/dwarf2.c
		* dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free
		dwarf_addr_buffer and dwarf_str_offsets_buffer.

2024-04-19  Alan Modra  <amodra@gmail.com>

	mmix disassemble memory leak
	It's a once-off and of no consequence, but fix it anyway.  The mmix
	caonoicalize_syms array is an array of pointers.  Freeing it won't
	lose symbol names.

		* mmix-dis.c (initialize_mmix_dis_info): Free syms.

2024-04-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake
	On SLE-11, with an older dejagnu version, I ran into:
	...
	Running gdb.ada/mi_prot.exp ...
	UNRESOLVED: gdb.ada/mi_prot.exp: \
	  testcase aborted due to invalid command name: gdb_find_gnatmake
	ERROR: tcl error sourcing gdb.ada/mi_prot.exp.
	ERROR: invalid command name "gdb_find_gnatmake"
	    while executing
	"::gdb_tcl_unknown gdb_find_gnatmake"
	    ("uplevel" body line 1)
	    invoked from within
	"uplevel 1 ::gdb_tcl_unknown $args"
	    (procedure "::unknown" line 5)
	    invoked from within
	"gdb_find_gnatmake"
	    (procedure "gnatmake_version_at_least" line 2)
	    invoked from within
	...

	Proc gdb_find_gnatmake is actually a backup for find_gnatmake:
	...
	if {[info procs find_gnatmake] == ""} {
	    rename gdb_find_gnatmake find_gnatmake
	...
	so gnatmake_version_at_least should use find_gnatmake instead.

	For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we
	don't run into this error.

	For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to
	find_gnatmake, and we do run into the error.

	It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it
	seems something legitimate to use.  Maybe we should use future_ or gdb_future_
	prefix instead to make this more clear, but I've left that alone for now.

	Fix this by:
	- triggering the same error with a recent dejagnu by removing
	  gdb_find_gnatmake unless used (and likewise for other procs in future.exp),
	  and
	- using find_gnatmake in gnatmake_version_at_least.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31647
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647

2024-04-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use allocator_may_return_null=1 in two test-cases
	Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw
	MemoryError in inferior.read_memory if malloc fails") introduced
	AddressSanitizer allocation-size-too-big errors in the two test-cases
	affected by this commit.

	Fix this by suppressing the error in the two test-cases using
	allocator_may_return_null=1.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html

2024-04-18  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: constify some return values in print-utils.{h,cc}
	There is no reason the callers of these functions need to change the
	returned string, so change the `char *` return types to `const char *`.

	Update a few callers to also use `const char *`.

	Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-18  Nick Clifton  <nickc@redhat.com>

	HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets.
	  PR 30743

2024-04-18  Will Hawkins  <hawkinsw@obs.cr>

	Add DW_TAG_compile_unit DIE to Dummy CUs
	Dummy CUs help detect errors and are very helpful. However, the DWARF
	spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to
	the header. This patch adds that.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650

	Approved-By: Tom de Vries <tdevries@suse.de>
	Tested-By: Tom de Vries <tdevries@suse.de>

2024-04-18  Alan Modra  <amodra@gmail.com>

	Re: Fix address violations when reading corrupt VMS records
	Fixes error reports about the length of EEOM records produced by gas.

		PR 21618
		* vms-alpha.c (evax_bfd_print_emh): Don't read subtyp if short
		record.  Consolidate error messages.
		(evax_bfd_print_eeom): Allow length 10 record.

2024-04-18  Alan Modra  <amodra@gmail.com>

	alpha_vms_get_section_contents vs. fuzzed files
	This patch is in response to an oss-fuzz report regarding
	use-of-uninitialized-value in bfd_is_section_compressed_info from
	section contents provided by alpha_vms_get_section_contents.  That
	hole is covered by using bfd_zalloc rather than bfd_alloc.

	The rest of the patch is mostly a tidy.  In a function returning
	section contents, I tend to prefer a test on the section properties
	over a test on file properties.  That's why I've changed the file
	flags test to one on section filepos and flags before calling
	_bfd_generic_get_section_contents.  Also, fuzzed objects can easily
	have sections with file backing in relocatable objects, or sections
	without file backing in images.  Possible confusion is avoided by
	testing each section.

	Note that we are always going to run into out-of-memory with fuzzed
	alpha-vms object files due to sections with contents via ETIR records.
	eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a
	32-bit repeat count.  So section contents can be very large from a
	relatively small file.  I'm inclined to think that an out-of-memory
	error is fine for such files.

		* vms-alpha.c (alpha_vms_get_section_contents): Handle sections
		with non-zero filepos or without SEC_HAS_CONTENTS via
		_bfd_generic_get_section_contents.  Zero memory allocated for
		sections filled by ETIR records.

2024-04-18  Alan Modra  <amodra@gmail.com>

	Tidy objdump opb expressions
	I don't think any of these can overflow, but since all of the
	expressions I'm editing here are inside a while loop with condition
	addr_offset < stop_offset, this change makes it more obvious that they
	can't overflow.

		* objdump.c (disassemble_bytes): Calculate octet expressions
		involving both addr_offset and stop_offset by first
		subtracting addr_offset from stop_offset.

2024-04-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-17  Tom Tromey  <tom@tromey.com>

	Remove a copy from c-exp.y:parse_number
	parse_number copies its input string, but there is no need to do this.
	This patch removes the copy.

	Regression tested on x86-64 Fedora 38.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2024-04-17  Pedro Alves  <pedro@palves.net>

	gdb/Windows: Fix detach while running
	While testing a WIP Cygwin GDB that supports non-stop, I noticed that
	gdb.threads/attach-non-stop.exp exposes that this:

	 (gdb) attach PID&
	 ...
	 (gdb) detach

	... hangs.

	And it turns out that it hangs in all-stop as well.  This commits
	fixes that.

	After "attach &", the target is set running, we've called
	ContinueDebugEvent and the process_thread thread is waiting for
	WaitForDebugEvent events.  It is the equivalent of "attach; c&".

	In windows_nat_target::detach, the first thing we do is
	unconditionally call windows_continue (for ContinueDebugEvent), which
	blocks in do_synchronously, until the process_thread sees an event out
	of WaitForDebugEvent.  Unless the inferior happens to run into a
	breakpoint, etc., then this hangs indefinitely.

	If we've already called ContinueDebugEvent earlier, then we shouldn't
	be calling it again in ::detach.

	Still in windows_nat_target::detach, we have an interesting issue that
	ends up being the bulk of the patch -- only the process_thread thread
	can call DebugActiveProcessStop, but if it is blocked in
	WaitForDebugEvent, we need to somehow force it to break out of it.
	The only way to do that, is to force the inferior to do something that
	causes WaitForDebugEvent to return some event.

	This patch uses CreateRemoteThread to do it, which results in
	WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT.  We then
	terminate the injected thread before it has a chance to run any
	userspace code.

	Note that Win32 functions like DebugBreakProcess and
	GenerateConsoleCtrlEvent would also inject a new thread in the
	inferior.  I first used DebugBreakProcess, but that is actually more
	complicated to use, because we'd have to be sure to consume the
	breakpoint event before detaching, otherwise the inferior would likely
	die due a breakpoint exception being raised with no debugger around to
	intercept it.

	See the new break_out_process_thread method.

	So the fix has two parts:

	 - Keep track of whether we've called ContinueDebugEvent and the
	   process_thread thread is waiting for events, or whether
	   WaitForDebugEvent already returned an event.

	 - In windows_nat_target::detach, if the process_thread thread is
	   waiting for events, unblock out of its WaitForDebugEvent, before
	   proceeding with the actual detach.

	New test included.  Passes cleanly on GNU/Linux native and gdbserver,
	and also passes cleanly on Cygwin and MinGW, with the fix.  Before the
	fix, it would hang and fail with a timeout.

	Tested-By: Hannes Domani <ssbssa@yahoo.de>
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905

2024-04-17  Pedro Alves  <pedro@palves.net>

	gdb+gdbserver/Linux: Remove USE_SIGTRAP_SIGINFO fallback
	It's been over 9 years (since commit faf09f0119da) since Linux GDB and
	GDBserver started relying on SIGTRAP si_code to tell whether a
	breakpoint triggered, which is important for non-stop mode.  When that
	then-new code was added, I had left the then-old code as fallback, in
	case some architectured still needed it.  Given AFAIK there haven't
	been complaints since, this commit finally removes the fallback code,
	along with USE_SIGTRAP_SIGINFO.

	Change-Id: I140a5333a9fe70e90dbd186aca1f081549b2e63d

2024-04-17  Tom Tromey  <tromey@adacore.com>

	Use section name in DWARF error message
	A bug points out that a certain error message in read_str_index uses a
	hard-coded section name.  This patch changes it to use
	dwarf2_section_info::get_name instead, like the other errors in the
	function.

	No test because it didn't seem worthwhile.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31639
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extension
	When building with clang 18, I see:

	      CXX    aarch64-linux-tdep.o
	    /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
	     1299 |       gdb_byte za_zeroed[za_bytes];
	          |                          ^~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression
	    /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here
	     1282 |   size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2);
	          |          ^

	Since we are using VLAs right now, that warning doesn't make sense for
	us.  add `-Wno-vla-cxx-extension` to the list of warning flags we try to
	enable.  If we ever choose to disallow VLAs, we can remove that flag.

	Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c

2024-04-17  Matt Wozniski  <godlygeek@gmail.com>

	Fix include guard typo
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/record: minor clean, remove some unneeded arguments
	I spotted that the two functions:

	  record_full_open_1
	  record_full_core_open_1

	both took two arguments, neither of which are used.

	I stumbled onto this while reviewing how filename_completer is used.
	The 'record full restore' command uses filename_completer and invokes
	the cmd_record_full_restore function.

	The cmd_record_full_restore function calls core_file_command and then
	record_full_open, which then calls one of the above functions.

	As 'record full restore' takes a filename, this is passed to
	cmd_record_full_restore, which forwards the filename to both
	core_file_command and record_full_open.  However, record_full_open
	never actually uses the filename that is passed in.

	The record_full_open function is also used for 'target record-full'.

	I propose that record_full_open should no longer expect to see any
	user supplied arguments passed in (it doesn't use any).  In fact, I've
	added a check that if we do get any user supplied arguments we'll
	throw an error.

	Now that we know record_full_open isn't being passed any user
	arguments we can stop passing the arguments to record_full_open_1 and
	record_full_core_open_1, this will make no user visible difference as
	these arguments were not used.

	It is possible that a user was previously doing:

	  (gdb) target record-full blah blah blah

	And this previously would work fine, the 'blah blah blah' was
	ignored.  Now this will give an error.  Other than this case there
	should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/record: add an assert in cmd_record_start
	The 'record' command is both a prefix command AND an alias for 'target
	record-full'.  As it is a prefix command, if a user types:

	  (gdb) record blah

	Then GDB will look for, and try to invoke the 'blah' sub-command.
	This will either succeed (if blah is found) or throw an error (if blah
	is not found).

	As such, the only way to invoke the 'record' command is like:

	  (gdb) record

	It is impossible to pass arguments to the 'record' command.  As we
	know this is true then we can assert this in cmd_record_start.

	I added this assert because initially I was going to try forwarding
	ARGS from cmd_record_start to the 'target record-full' command, but
	then I realised passing arguments to 'record' was impossible.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/record: remove unnecessary use of filename_completer
	Spotted that the 'record' command has its completer set to
	filename_completer.  The problem is that 'record' is a prefix command,
	as such, its completer is hard-coded to complete on sub-commands.  The
	attempt to use filename_completer is irrelevant.

	The 'record' command is itself a command though, that is, a user can
	do this:

	  (gdb) record

	which is really just an alias for:

	  (gdb) target record-full

	Nowhere does cmd_record_start (which is called when 'record' is used)
	expect a filename, and 'target record-full' doesn't expect a filename
	either.

	So lets just drop the line which sets filename_completer as the
	completer for 'record'.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require DW_LNE_end_sequence
	The dwarf standard requires that every line number program sequence ends
	with a DW_LNE_end_sequence instruction.

	Enforce this in the dwarf assembler for the last sequence in a line number
	program (we have no means to enforce this for earlier sequences), and fix a
	few test-case that don't have it.

	Tested on aarch64-linux.

	PR testsuite/31618
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix end_sequence addresses
	I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
	...
	00000000004102c4 <end_of_sequence>:
	  4102c4:       52800000        mov     w0, #0x0                        // #0
	  4102c8:       9100c3ff        add     sp, sp, #0x30
	  4102cc:       d65f03c0        ret
	...
	is not described by the line table:
	...
	File name                    Line number    Starting address    View    Stmt
	  ...
	map-to-same-line.c                    54            0x4102ac               x
	map-to-same-line.c                     -            0x4102c4
	...

	Fix this by ending the line table at $main_end.

	Likewise in a few other test-cases, found using:
	...
	$ find gdb/testsuite/ -type f \
	  | xargs grep -B1 DW_LNE_end_sequence \
	  | grep set_address \
	  | egrep -v "_end|_len"
	...

	Tested on aarch64-linux.

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require address update for DW_LNS_copy
	No address update before a DW_LNS_copy might mean an incorrect dwarf
	assembly test-case.

	Try to catch such incorrect dwarf assembly test-cases by:
	- requiring an explicit address update for each DW_LNS_copy, and
	- handling the cases where an update is indeed not needed, by adding
	  "DW_LNS_advance_pc 0".

	Tested on aarch64-linux.

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require address update for DW_LNE_end_sequence
	With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence
	entry with the same address as the line entry before it:
	...
	File name                    Line number    Starting address    View    Stmt

	dw2-epilogue-begin.c                  44            0x4101e8               x
	dw2-epilogue-begin.c                  47            0x4101ec               x
	dw2-epilogue-begin.c                   -            0x4101ec
	...
	and consequently the line entry is removed by gdb:
	...
	INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PRO EPI
	0      20     0x00000000004101a8 0x00000000004101a8 Y       Y   Y
	1      27     0x00000000004101b0 0x00000000004101b0 Y
	2      32     0x00000000004101b8 0x00000000004101b8 Y       Y
	3      34     0x00000000004101c0 0x00000000004101c0 Y           Y
	4      35     0x00000000004101c8 0x00000000004101c8 Y
	5      40     0x00000000004101d4 0x00000000004101d4 Y       Y
	6      44     0x00000000004101e8 0x00000000004101e8 Y
	7      END    0x00000000004101ec 0x00000000004101ec Y
	...

	This is a common mistake in dwarf assembly test-cases.

	Fix this by:
	- requiring an address update for each DW_LNE_end_sequence, and
	- fixing the test-cases where that triggers an error.

	I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in
	this case I worked around it using "DW_LNS_advance_pc 0".

	Tested on aarch64-linux.

	PR testsuite/31592
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592

2024-04-17  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix max-depth test case for AIX.
	In AIX, if in the main program the global variables are unused then the linker optimises
	these variables and the dwarf will not have proper address to the same. Hence we cannot access these
	variables.

	This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well.

2024-04-17  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Remove asserts from operand qualifier decoders [PR31595]
	Given that the disassembler should never abort when decoding
	(potentially random) data, assertion statements in the
	`get_*reg_qualifier_from_value' function family prove problematic.

	Consider the random 32-bit word W, encoded in a data segment and
	encountered on execution of `objdump -D <obj_name>'.

	If:

	  (W & ~opcode_mask) == valid instruction

	Then before `print_insn_aarch64_word' has a chance to report the
	instruction as potentially undefined, an attempt will be made to have
	the qualifiers for the instruction's register operands (if any)
	decoded.  If the relevant bits do not map onto a valid qualifier for
	the matched instruction-like word, an abort will be triggered and the
	execution of objdump aborted.

	As this scenario is perfectly feasible and, in light of the fact that
	objdump must successfully decode all sections of a given object file,
	it is not appropriate to assert in this family of functions.

	Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for
	handling invalid qualifier-associated values and re-purpose the
	assertion conditions in qualifier-retrieving functions to be the
	predicate guarding the returning of the calculated qualifier type.
	If the predicate fails, we return this new qualifier and allow the
	caller to handle the error as appropriate.

	As these functions are called either from within
	`aarch64_extract_operand' or `do_special_decoding', both of which are
	expected to return non-zero values, it suffices that callers return
	zero upon encountering `AARCH64_OPND_QLF_ERR'.

	Ar present the error presented in the hypothetical scenario has been
	encountered in `get_sreg_qualifier_from_value', but the change is made
	to the whole family to keep the interface consistent.

	Bug: https://sourceware.org/PR31595

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdbserver pid in gdb.server/server-kill-python.exp
	The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for
	remote target") intended to addresss the problem that this command:
	...
	set gdbserver_pid [exp_pid -i $server_spawn_id]
	...
	does not return the pid of the gdbserver for remote target, but rather the one
	of the ssh client session.

	To fix this, it added another way of getting the gdbserver_pid.

	For the trivial case of non-remote target, the PID found by either method
	should be identical, but if we compare those by adding
	"puts [exec ps -p $gdbserver_pid]" we get:
	...
	  PID TTY          TIME CMD
	31711 pts/8    00:00:00 gdbserver
	  PID TTY          TIME CMD
	31718 pts/8    00:00:00 server-kill-pyt
	...

	The problem is that while the gdbserver PID is supposed to be read from the
	result of "gdb.execute ('p server_pid')" in the python script, instead it's
	taken from:
	...
	Process server-kill-python created; pid = 31718^M
	...

	Fix this by moving the printing of the gdbserver PID out of the python script.

	Also double-check the two methods against each other, in the cases that they
	should match.

	Tested on x86_64-linux.

	PR testsuite/31633
	https://sourceware.org/bugzilla/show_bug.cgi?id=31633

2024-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.server/server-kill-python.exp
	In test-case gdb.server/server-kill-python.exp we have:
	...
	if {[gdb_spawn_with_cmdline_opts \
	         "-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} {
	    fail "spawn"
	    return
	}
	...

	I reproduced the problem by reverting the fix at the commit adding both the
	fix and the test-case, and the reproduced the same problem using:
	...
	(gdb) source $host_file1
	...
	so there doesn't seem to be a specific need to source the python file using
	"-ex".

	Simplify the test-case by sourcing the python file using send_gdb.

	This also allow us to simplify the python script.

	Tested on x86_64-linux.

2024-04-17  Hu, Lin1  <lin1.hu@intel.com>

	Add W table for USER_MSR under MAP4.
	opcodes/ChangeLog:

		* i386-dis-evex-mod.h: Modify MOD_EVEX_MAP4_F8_P1,
		MOD_EVEX_MAP4_F8_P3.
		* i386-dis-evex-w.h (EVEX_W_MAP4_F8_P1_M_1): New.
		(EVEX_W_MAP4_F8_P3_M_1): Ditto.
		* i386-dis.c (vex_w_table): Add EVEX_W_MAP4_F8_P1_M_1,
		EVEX_W_MAP4_F8_P3_M_1.
		* i386-opc.tbl: Remove redundant '|'.

2024-04-17  H.J. Lu  <hjl.tools@gmail.com>

	elf: Skip the archive if the symbol isn't referenced
	Also skip the archive if the symbol isn't referenced by a regular object.

	bfd/

		PR ld/31644
		* elflink.c (elf_link_add_archive_symbols): Also skip the archive
		if the symbol isn't referenced by a regular object.

	ld/

		PR ld/31644
		* testsuite/ld-plugin/lto.exp: Run PR ld/31644 tests.
		* testsuite/ld-plugin/pr31644a.c: New test.
		* testsuite/ld-plugin/pr31644b.c: Likewise.
		* testsuite/ld-plugin/pr31644c.c: Likewise.

2024-04-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-17  Alan Modra  <amodra@gmail.com>

	ARC e_flags vs. objcopy
	While the patch that Nick reverted in commit 3f6a060c7543 was in the
	source, "FAIL: objcopy executable (pr25662)" was seen on ARC.  The
	failure was triggered by the .ARC.attributes section being removed by
	the linker script.  When a file lacking this section is copied by
	objcopy, e_flags from the input is copied to the output (in this case
	the value 0x406), but arc_elf_final_write_processing then logical-ors
	in 0x300 when Tag_ARC_ABI_osver is not found.

		* elf32-arc.c (arc_elf_final_write_processing): Don't ignore
		existing e_flags for objcopy.

2024-04-17  Alan Modra  <amodra@gmail.com>

	libctf warnings
	Seen with every compiler I have if using -fno-inline:
	home/alan/src/binutils-gdb/libctf/ctf-create.c: In function ‘ctf_add_encoded’:
	/home/alan/src/binutils-gdb/libctf/ctf-create.c:555:3: warning: ‘encoding’ may be used uninitialized [-Wmaybe-uninitialized]
	  555 |   memcpy (dtd->dtd_vlen, &encoding, sizeof (encoding));

	Seen with gcc-4.9 and probably others at lower optimisation levels:
	home/alan/src/binutils-gdb/libctf/ctf-serialize.c: In function 'symtypetab_density':
	/home/alan/src/binutils-gdb/libctf/ctf-serialize.c:211:18: warning: 'sym' may be used uninitialized in this function [-Wmaybe-uninitialized]
	    if (*max < sym->st_symidx)

	Seen with gcc-4.5 and probably others at lower optimisation levels:
	/home/alan/src/binutils-gdb/libctf/ctf-types.c:1649:21: warning: 'tp' may be used uninitialized in this function
	/home/alan/src/binutils-gdb/libctf/ctf-link.c:765:16: warning: 'parent_i' may be used uninitialized in this function

	Also with gcc-4.5:
	In file included from /home/alan/src/binutils-gdb/libctf/ctf-endian.h:25:0,
	                 from /home/alan/src/binutils-gdb/libctf/ctf-archive.c:24:
	/home/alan/src/binutils-gdb/libctf/swap.h:70:0: warning: "_Static_assert" redefined
	/usr/include/sys/cdefs.h:568:0: note: this is the location of the previous definition

		* swap.h (_Static_assert): Don't define if already defined.
		* ctf-serialize.c (symtypetab_density): Merge two
		CTF_SYMTYPETAB_FORCE_INDEXED blocks.
		* ctf-create.c (ctf_add_encoded): Avoid "encoding" may be used
		uninitialized warning.
		* ctf-link.c (ctf_link_deduplicating_open_inputs): Avoid
		"parent_i" may be used uninitialized warning.
		* ctf-types.c (ctf_type_rvisit): Avoid "tp" may be used
		uninitialized warning.

2024-04-16  Tom Tromey  <tom@tromey.com>

	Avoid cache race in bfd_check_format_matches
	Running the gdb test suite with the thread sanitizer enabled shows a
	race when bfd_check_format_matches and bfd_cache_close_all are called
	simultaneously on different threads.

	This patch fixes this race by having bfd_check_format_matches
	temporarily remove the BFD from the file descriptor cache -- leaving
	it open while format-checking proceeds.

	In this setup, the BFD client is responsible for closing the BFD again
	on the "checking" thread, should that be desired.  gdb does this by
	calling bfd_cache_close in the relevant worker thread.

	An earlier version of this patch omitted the "possibly_cached" helper
	function.  However, this ran into crashes in the binutils test suite
	involving the archive-checking abort in bfd_cache_lookup_worker.  I do
	not understand the purpose of this check, so I've simply had the new
	function work around it.  I couldn't find any comments explaining this
	situation, either.  I suspect that there may still be races related to
	this case, but I don't think I have access to the platforms where gdb
	deals with archives.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264

2024-04-16  Tom Tromey  <tom@tromey.com>

	Thread-safety improvements for bfd_check_format_matches
	A gdb bug found that bfd_check_format_matches has some data races when
	called from multiple threads.

	In particular, it changes the BFD error handler, which is a global.
	It also has a local static variable ("in_check_format") that is used
	for recursion detection.  And, finally, it may emit warnings to the
	per-xvec warning array, which is a global.

	This patch removes all the races here.

	The first part of patch is to change _bfd_error_handler to directly
	handle the needs of bfd_check_format_matches.  This way, the error
	handler does not need to be changed.

	This change lets us use the new per-thread global
	(error_handler_messages, replacing error_handler_bfd) to also remove
	the need for in_check_format -- a single variable suffices.

	Finally, the global per-xvec array is replaced with a new type that
	holds the error messages.  The outermost such type is stack-allocated
	in bfd_check_format_matches.

	I tested this using the binutils test suite.  I also built gdb with
	thread sanitizer and ran the test case that was noted as failing.
	Finally, Alan sent me the test file that caused the addition of the
	xvec warning code in the first place, and I confirmed that "nm-new"
	has the same behavior on this file both before and after this patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264
	Co-Authored-By: Alan Modra <amodra@gmail.com>

2024-04-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/backward-spec-inter-cu.exp
	Add another regression test for PR symtab/30846.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846

2024-04-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.dwarf2/forward-spec-inter-cu.exp
	Add a regression test for PR symtab/30846.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846

2024-04-16  Tom Tromey  <tom@tromey.com>

	Correctly handle DIE parent computations
	Tom de Vries pointed out that the combination of sharding,
	multi-threading, and per-CU "racing" means that sometimes a cross-CU
	DIE reference might not be correctly resolved.  However, it's
	important to handle this correctly, due to some unfortunate aspects of
	DWARF.

	This patch implements this by arranging to preserve each worker's DIE
	map through the end of index finalization.  The extra data is
	discarded when finalization is done.  This approach also allows the
	parent name resolution to be sharded, by integrating it into the
	existing entry finalization loop.

	In an earlier review, I remarked that addrmap couldn't be used here.
	However, I was mistaken.  A *mutable* addrmap cannot be used, as those
	are based on splay trees and restructure the tree even during lookups
	(and thus aren't thread-safe).  A fixed addrmap, on the other hand, is
	just a vector and is thread-safe.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846

2024-04-16  Tom Tromey  <tom@tromey.com>

	Introduce class parent_map for DIE range map
	This changes the DIE range map from a raw addrmap to a custom class.
	A new type is used to represent the ranges, in an attempt to gain a
	little type safety as well.

	Note that the new code includes a map-of-maps type.  This is not used
	yet, but will be used in the next patch.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

2024-04-16  Tom Tromey  <tom@tromey.com>

	Add move operators for addrmap
	A subsequent patch needs to move an addrmap.  This patch adds the
	necessary support.  It also changes addrmap_fixed to take a 'const'
	addrmap_mutable.  This is fine according to the contract of
	addrmap_mutable; but it did require a compensating const_cast in the
	implementation.

2024-04-16  Tom Tromey  <tom@tromey.com>

	Change handling of DW_TAG_enumeration_type in DWARF scanner
	Currently the DWARF scanner will enter enumeration constants into the
	same namespace as the DW_TAG_enumeration_type itself.  This is the
	right thing to do, but the implementation may result in strange
	entries being added to the addrmap that maps DIE ranges to entries.

	This came up when debugging an earlier version of this series; and
	while I don't think this should impact the current series, it seems
	better to clean this up anyway.

	In the new code, rather than pass the "wrong" scope down through
	recursive calls to the scanner, the correct scope is always passed,
	and then the parent handling is done when creating the enumerator
	entry.

2024-04-16  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Refactor condition in scan_attributes
	In scan_attributes there's code:
	...
		  if (new_reader->cu == reader->cu
		      && new_info_ptr > watermark_ptr
		      && *parent_entry == nullptr)
		    ...
		  else if (*parent_entry == nullptr)
		    ...
	...
	that uses the "*parent_entry == nullptr" condition twice.

	Make this somewhat more readable by factoring out the condition:
	...
		  if (*parent_entry == nullptr)
		    {
		      if (new_reader->cu == reader->cu
			  && new_info_ptr > watermark_ptr)
			...
		      else
			...
		    }
	...

	This also allows us to factor out "form_addr (origin_offset, origin_is_dwz)".

	Tested on x86_64-linux.

2024-04-16  Nick Clifton  <nickc@redhat.com>

	Fix test for sections with different VMA<->LMA relationships so that it only applies to allocated sections, and only sections in the same segment are checked.
	  PR 31450

2024-04-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb/make-target-delegates.py: don't handle "void" in parse_argtypes
	I suppose this was needed when we had `void` in declarations of methods
	with no parameters.  If so, we no longer need it.  There are no changes
	in the generated file.

	Change-Id: I0a2b398408aa129634e2d73097a038f7f80db4b4
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-16  Eli Zaretskii  <eliz@gnu.org>

	Remove excess whitespace from doc strings of some commands
	I've noticed that doc strings of some commands, like "set cwd"
	and  "set inferior-tty", have some excess whitespace, which
	makes them display with unexpected indentation, at least in a
	Windows command prompt window.  This patch fixes that.

	* gdb/linux-nat.c (_initialize_linux_nat):
	* gdb/riscv-tdep.c (riscv_insn):
	* gdb/top.c (quit_force):
	* gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace.

2024-04-16  Nick Clifton  <nickc@redhat.com>

	Remove accidental commit of an experimental change

2024-04-16  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Throw MemoryError in inferior.read_memory if malloc fails
	PR python/31631 reports a gdb internal error when doing:
	...
	(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
	utils.c:709: internal-error: virtual memory exhausted.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	...

	Fix this by throwing a python MemoryError, such that we have instead:
	...
	(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
	Python Exception <class 'MemoryError'>:
	Error occurred in Python.
	(gdb)
	...

	Likewise for DAP.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631

2024-04-16  H.J. Lu  <hjl.tools@gmail.com>

	x86: Fix a memory leak in md_assemble
	Fix a memory leak in md_assemble where copy may be cleared and may be
	the same as copy:

	      if (copy && !mnem_suffix)
	        {
	          line = copy;
	          copy = NULL;
	  no_match:

		* config/tc-i386.c (md_assemble): Properly free the xstrdup
		memory.

2024-04-16  H.J. Lu  <hjl.tools@gmail.com>

	gas: Free unused memory in scfi_ops_cleanup
	* scfi.c (scfi_ops_cleanup): Free op->op_data and head.

2024-04-16  Fangrui Song  <i@maskray.me>

	Simplify readelf's RELR relocation display.

2024-04-16  Nick Clifton  <nickc@redhat.com>

	Gas Doc: Update example of how .altmacro affects the interpretation of macro arguments.
	  PR 31255

2024-04-16  Simon Cook  <simon.cook@embecosm.com>

	Remove debug printout from 9dd918142787246ea7ed53494d9cbc6b51486133

2024-04-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-15  Tom Tromey  <tromey@adacore.com>

	Fix crash in gdb_rl_callback_handler
	commit bdcd50f9 ("Strip trailing newlines from input string")
	introduced a crash in eof-exit.exp.  This patch fixes the problem by
	adding a NULL check in the appropriate spot.

	Regression tested on x86-64 Fedora 38.  I'm checking this in.

2024-04-15  Tom Tromey  <tromey@adacore.com>

	Remove 'copy_names' parameter from add_using_directive
	I noticed that add_using_directive's 'copy_names' parameter is only
	used by a single caller.  This patch removes the parameter and changes
	that caller to copy the names itself.  I chose to use intern here
	since I suspect the names may well be repeated in a given objfile.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-04-15  John Baldwin  <jhb@FreeBSD.org>

	gdb: Add Felix Willgerodt as the x86 architecture maintainer
	This includes both the i386 and x86-64 architectures.

2024-04-15  Nick Clifton  <nickc@redhat.com>

	Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments.
	  PR 31527

2024-04-15  Tom Tromey  <tromey@adacore.com>

	Change printf attribute to fix clang build
	commit e8cd90f0 ("Rewrite gdb_bfd_error_handler") broke the clang
	build.

	The problem here is that print_error_callback isn't marked as being
	printf-like, but it calls string_file::vprintf, triggering:

	../../binutils-gdb/gdb/gdb_bfd.c:1202:18: error: format string is not a string literal [-Werror,-Wformat-nonliteral]

	This patch applies the attribute to this function.

	It also removes the attribute from gdb_bfd_error_handler, because that
	function is no longer really printf-like.

2024-04-15  Vijay Shankar  <shank.vijay@yandex.com>

	When mapping sections to segments ensure that we do not add sections whose VMA->LMA relationship does not match the relationship of earlier sections in the segment.
	  PR 31540

2024-04-15  Tom Tromey  <tromey@adacore.com>

	Avoid complaint warning on mingw
	The mingw build currently issues a warning:

	./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes]

	This patch fixes the problem as suggested by Simon:

	    https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html

	...that is, by changing the warning interceptor to a class with a
	single 'warn' method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-15  Tom Tromey  <tromey@adacore.com>

	Strip trailing newlines from input string
	A co-worker noticed a strange situation where "target remote" would
	fail due to a trailing newline in the address part of the command.
	Eventually he tracked this down to the fact that he was pasting the
	command into the terminal, and due to bracketed paste mode, the
	newline was being preserved by readline.

	It seems to me that we basically never want a trailing newline on a
	gdb command, so this patch removes it when handling the readline
	result.

	Co-Authored-By: Kévin Le Gouguec <legouguec@adacore.com>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-15  Christophe Lyon  <christophe.lyon@linaro.org>

	gprofng: Fix dvi documentation build rule
	This  patch fixes 'install-dvi'.

2024-04-15  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	sim: riscv: Fix confusion with c.jal vs. c.addiw
	There was apparently a confusion which cpu model uses
	compressed JAL and which ADDIW.  Fixed that in execute_c,
	case MATCH_C_JAL | MATCH_C_ADDIW.

	Fixes 3224e32fb84f ("sim: riscv: Add support for compressed integer instructions")

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-15  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	sim: riscv: Make stack 16-byte aligned
	Various gcc test cases fail due to the stack
	alignment of 16 bytes is expected by gcc,
	causing issues mostly with vararg functions,
	e.g.

	FAIL: gcc.c-torture/execute/nest-align-1.c   -O0  execution test
	FAIL: gcc.c-torture/execute/nest-stdar-1.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-12.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-15.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-16.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-17.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-20.c   -O0  execution test
	FAIL: gcc.c-torture/execute/va-arg-26.c   -O0  execution test
	...

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-15  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	sim: riscv: Fix PC at gdb breakpoints
	The uncompressed EBREAK instruction does not work
	correctly this way, and the comment saying that
	GDB expects us to step over EBREAK is just wrong.
	The PC was always 4 bytes too high, which skips one
	instruction at break and step over commands, and
	causes complete chaos.  The compressed EBREAK was
	already implemented correctly.

	Tested by using gdb's "target sim" and single-stepping.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-15  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: ld:Report an error when seeing an unrecognized relocation
	If we generate an object file using an assembler with the new
	relocations added, and then linking those files with an older
	linker, the link will still complete and the linked file will
	be generated.
	In this case we should report an error instead of continuing
	the linking process.

2024-04-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-12  Pedro Alves  <pedro@palves.net>

	Fix setting watchpoints when current thread is running
	Currently, when the current thread is running, you can print global
	variables.  However, if you try to set a watchpoint on the same
	globals, GDB errors out, complaining that the selected thread is
	running.  Like so:

	 (gdb) c&
	 Continuing.
	 (gdb) p global
	 $1 = 1098377287
	 (gdb) watch global
	 Selected thread is running.

	This patch makes setting the watchpoint work.  You'll now get:

	 (gdb) c&
	 Continuing.
	 (gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)]
	 [New Thread 0x7ffff756d640 (LWP 434994)]
	 p global
	 $1 = 88168
	 (gdb) watch global
	 Hardware watchpoint 2: global
	 (gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)]

	 Thread 2 "function0" hit Hardware watchpoint 2: global

	 Old value = 185420
	 New value = 185423
	 int_return () at threads.c:39
	 39      }

	The problem is that update_watchpoint calls get_selected_frame
	unconditionally.  We can skip it if the watchpoint expression is only
	watching globals.

	This adds a testcase that exercises both all-stop and non-stop, and
	also software and hardware watchpoints.  It is kfailed for software
	watchpoints, as those require another fix not handled by this patch
	(the sw watchpoint doesn't fire because GDB doesn't force the
	running-free thread to switch to single-stepping).

	Change-Id: I68ca948541aea3edd4f70741f272f543187abe40

2024-04-12  Pedro Alves  <pedro@palves.net>

	New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153)
	Add a new testcase for exercising attaching to a process after its
	main thread has exited.

	This is not possible on Linux, the kernel does not allow attaching to
	a zombie task, so the test is kfailed there.  It is possible however
	on Windows at least, and was the scenario addressed by the Windows
	backend fix in
	https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html,
	nowadays PR threads/8153, back in 2003.

	Passes cleanly on Cygwin.
	KFAILed on GNU/Linux native and gdbserver.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555
	Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b

2024-04-12  Pedro Alves  <pedro@palves.net>

	Cygwin/testsuite: Avoid infinite hang
	On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp
	testcase hits a sequence of cascading FAILs:

	 (gdb) run
	 Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
	 [New Thread 12672.0x318c]
	 [New Thread 12672.0x2844]
	 [New Thread 12672.0x714]
	 FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout)
	 frame
	 FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout)
	 list
	 FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout)

	And the test program never makes progress.

	... and at this point, Cygwin is completely stuck.  I can't run any
	other Cygwin program.

	However, if we run the test program outside DejaGnu, we see something
	different:

	  (gdb) b add
	  Function "add" not defined.
	  Make breakpoint pending on future shared library load? (y or [n]) y
	  Breakpoint 1 (add) pending.
	  (gdb) r
	  Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
	  [New Thread 10968.0x834]
	  [New Thread 10968.0x29a4]
	  [New Thread 10968.0x16b8]
	  [New Thread 10968.0xf9c]
	  [Switching to Thread 10968.0x16b8]

	  Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 <sigq>) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304
	  1304      se = sigs + pack.si.si_signo;
	  (gdb)

	Ah, the test wanted to run to a global "add" function, but managed to
	stop at an internal Cygwin method called "add".  And stopping there
	deadlocks everything Cygwin in the system.  (I believe some
	cygwin1.dll mechanisms use cross-process synchronization or
	communication, we're probably blocking something like that.)

	Fix this by using "break -q".  The tests FAIL because we don't support
	follow-fork for Cygwin, but at least we no longer deadlock the
	machine.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9

2024-04-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/data-directory: silence output from mkinstalldirs script
	After my recent changes the data-directory build now uses
	silent-rules.mk to reduce the output.

	One problem that remains was the use of mkinstalldirs by stamp-python
	and stamp-guile for creating some directories, the mkinstalldirs
	prints some messages, so we're left with output like this:

	    GEN    stamp-python
	  mkdir -p -- ./python/gdb
	  mkdir -p -- ./python/gdb/command
	  mkdir -p -- ./python/gdb/dap
	  mkdir -p -- ./python/gdb/function
	  mkdir -p -- ./python/gdb/printer

	I was looking at adding a --silent option to the mkinstalldirs script,
	however, when I took a look at the automake package (which is where
	mkinstalldirs comes from) it turns out that mkinstalldirs is
	deprecated, at the advice is to use 'install-sh -d' instead.

	Just like we carry mkinstalldirs in the top-level directory, we also
	carry install-sh, and a version of install-sh which supports the -d
	flag.

	And best of all, 'install-sh -d' doesn't appear to print any of the
	information messages to stdout that mkinstalldirs does, so if we
	switch to use that, we get a quieter build.

	There should be no changes in what is built after this commit

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-12  Nick Clifton  <nickc@redhat.com>

	Update description of macro keyword argument assignment in assembler documentation.
	  PR 31255

2024-04-12  H.J. Lu  <hjl.tools@gmail.com>

	gas: Fix memory leaks in gen-sframe.c
	* gen-sframe.c (sframe_xlate_ctx_cleanup): Call XDELETE on
		xlate_ctx->cur_fre.
		(create_sframe_all): Call XDELETE on xlate_ctx after use.

2024-04-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-12  Alan Modra  <amodra@gmail.com>

	Re: Fix null pointer dereference in process_debug_info()
	read_bases has a potential null-pointer deref too, and without a
	debug_info_p there isn't any point in calling read_bases.

		* dwarf.c (process_debug_info): Don't call read_bases when
		debug_info_p is NULL.

2024-04-11  Nick Clifton  <nickc@redhat.com>

	Improve readelf's display of RELR relocs.

	Add -j/--display-section option to readelf.

2024-04-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang
	When running test-case gdb.threads/access-mem-running-thread-exit.exp with
	clang, we run into:
	...
	(gdb) print global_var = 555^M
	No symbol "global_var" in current context.^M
	(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \
	  access mem (write to global_var, inf=2, iter=1)
	...

	The problem is that clang removes the unused variable.

	Fix this in the same way as done in commit b4f767131f7
	("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the
	variable.

	Tested on x86_64-linux with gcc and clang.

2024-04-11  H.J. Lu  <hjl.tools@gmail.com>

	gas: Fix a CFI label name memory leak in scfi.c
	CFI label name can be freed only after use.

		* scfi.c (handle_scfi_dot_cfi): Free CFI label name after use.
		* scfidw2gen.c (scfi_process_cfi_label): Add a comment.  Remove
		TODO on freeing CFI label name.

2024-04-11  H.J. Lu  <hjl.tools@gmail.com>

	gas: Fix memory leaks in ginsn.c
	Free buffer memory after use in ginsn.c.

		* ginsn.c (ginsn_dst_print): Free buffer after use.
		(ginsn_print): Likewise.

2024-04-11  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: fix format in remote.c
	Fix space-before-parenthesis format at three spots in remote.c.

2024-04-11  Alan Modra  <amodra@gmail.com>

	Remove bfdwin.c
	In commit b86d3af60ffc and 0ab0435fe672 I fixed SIGBUS errors found by
	oss-fuzz now that --with-mmap defaults to enabled.  It turns out there
	are further problems with the aout mmap code: aout_read_minisymbols
	returns the external symbol array, which is later freed by nm.c.  If
	the array is mmaped you can't free it.  Now this could be fixed by
	making aout minisymbols an array of pointers, but I figure there's not
	much point in expending effort on that.  So delete the aout mmap
	support along with bfdwin.c and get_section_contents_in_window.

2024-04-11  Alan Modra  <amodra@gmail.com>

	asan: heap buffer overflow elf_link_add_to_first_hash
	Seen on mmix.
	mmix  +FAIL: ld-misc/defsym1
	mmix  +FAIL: sysroot-prefix common plain -Lpath, quoted
	mmix  +FAIL: sysroot-prefix common plain -Lpath, unquoted
	mmix  +FAIL: sysroot-prefix common full-path, quoted
	mmix  +FAIL: sysroot-prefix common full-path, unquoted
	mmix  +FAIL: sysroot-prefix common plain =-prefixed with empty, quoted
	mmix  +FAIL: sysroot-prefix common plain =-prefixed with empty, unquoted
	mmix  +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, quoted
	mmix  +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, unquoted
	mmix  +FAIL: sysroot-prefix common plain =-prefixed -Lpath, quoted
	mmix  +FAIL: sysroot-prefix common plain =-prefixed -Lpath, unquoted
	mmix  +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, quoted
	mmix  +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, unquoted
	mmix  +FAIL: sysroot-prefix common full-path =-prefixed without, quoted
	mmix  +FAIL: sysroot-prefix common full-path =-prefixed without, unquoted
	mmix  +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, quoted
	mmix  +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, unquoted

	==3746597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070000007a0 at pc 0x56d87b0d1a40 bp 0x7fffb1629bf0 sp 0x7fffb1629be0
	READ of size 8 at 0x6070000007a0 thread T0
	    #0 0x56d87b0d1a3f in elf_link_add_to_first_hash /home/alan/src/binutils-gdb/bfd/elflink.c:4312

	mmix uses bfd_link_generic_hash_table.

		* elflink.c (_bfd_elf_archive_symbol_lookup): Dont use first_hash
		unless the hash table is bfd_link_elf_hash_table.
		(elf_link_add_archive_symbols): Likewise.

2024-04-11  Alan Modra  <amodra@gmail.com>

	Re: Update objcopy's --section-alignment option
	ubsan: shift exponent 255 is too large for 64-bit type

	I should have known oss-fuzz wouldn't be satisfied so easily.  The pef
	format allows quite silly section alignments in object files.

		* objcopy.c (setup_section): Limit shift exponent when checking
		vma and lma for alignment.

2024-04-11  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Use long NOPs for Intel Core processors
	Use long NOPs for Intel Core processors since they are faster than
	multiple NOPs.  Don't use them for 64-bit processors by default since
	Intel Atom processors can only decode 4 prefixes in 1 cycle.

		* config/tc-i386.c (alt64_9): New.
		(alt64_10): Likewise.
		(alt64_11): Likewise.
		(alt64_12): Likewise.
		(alt64_13): Likewise.
		(alt64_14): Likewise.
		(alt64_15): Likewise.
		(alt64_patt): Likewise.
		(i386_generate_nops): Use alt64_patt for Intel Core processors
		in 64-bit mode.
		* testsuite/gas/i386/x86-64-nops-1-core2.d: Expect long NOPs.
		* testsuite/gas/i386/x86-64-nops-4-core2.d: Likewise.
		* testsuite/gas/i386/ilp32/x86-64-nops-1-core2.d: Replace
		../x86-64-nops-1.d with ../x86-64-nops-1-core2.d.
		* testsuite/gas/i386/ilp32/x86-64-nops-4-core2.d: Replace
		../x86-64-nops-4.d with ../x86-64-nops-4-core2.d.

2024-04-11  H.J. Lu  <hjl.tools@gmail.com>

	mmap: Fix a memory leak in _bfd_mmap_read_temporary
	Return malloced memory in *mmap_base so that _bfd_munmap_readonly_temporary
	will free it.

		* libbfd.c (_bfd_mmap_read_temporary): Return malloced memory
		in *mmap_base.

2024-04-11  H.J. Lu  <hjl.tools@gmail.com>

	elf: Fix a memory leak in _bfd_elf_add_dynamic_entry
	Normally, the section contents is allocated by bfd_alloc which is freed
	when the object is closed.  But the .dynamic section contents is allocated
	by bfd_realloc, which should be freed by calling free.  Add a dynamic
	field to elf_link_hash_table for the .dynamic section and free its
	contents in _bfd_elf_link_hash_table_free.

		* elf-bfd.h (elf_link_hash_table): Add dynamic.
		* elflink.c (_bfd_elf_link_create_dynamic_sections): Set the
		dynamic field in elf_link_hash_table.
		(_bfd_elf_add_dynamic_entry): Use hash_table->dynamic.
		(_bfd_elf_strip_zero_sized_dynamic_sections): Likewise.
		(bfd_elf_add_dt_needed_tag): Likewise.
		(elf_finalize_dynstr): Likewise.
		(_bfd_elf_link_hash_table_free): Free htab->dynamic->contents.
		(bfd_elf_final_link): Use htab->dynamic.
		* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use
		htab->elf.dynamic.

2024-04-11  Alan Modra  <amodra@gmail.com>

	Segfault in _bfd_delete_bfd with USE_MMAP
	Any of the calls to _bfd_delete_bfd in bfd_fopen will hit this.

		* opncls.c (_bfd_delete_bfd): Check for non-NULL xvec before
		accessing flavour.

2024-04-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-10  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: bugfixes for SCFI state propagation
	There are two state propagation functions in SCFI machinery - forward
	and backward flow.  The patch addresses two issues:
	  - In forward_flow_scfi_state (), the state being compared in forward flow
	    must be that at the exit of a prev bb and that at the entry of the
	    next bb.  The variable holding the state to be compared was
	    previously (erroneously) stale.
	  - In cmp_scfi_state (), the assumption that two different control
	    flows, leading to the same basic block, cannot have a mismatched
	    notion of CFA base register, is not true.  Remove the assertion and
	    instead return err if mismatch.

	Fixing these issues helps correctly synthesize CFI, when previously
	SCFI was erroring out for an otherwise valid input asm.

	gas/
		* scfi.c (cmp_scfi_state): Remove assertion and return mismatch
		in return value as applicable.
		(forward_flow_scfi_state): Update state object to be the same as
		the exit state of the prev bb before comparing.

	gas/testsuite/
		* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
		* gas/scfi/x86_64/scfi-cfg-5.d: New test.
		* gas/scfi/x86_64/scfi-cfg-5.l: New test.
		* gas/scfi/x86_64/scfi-cfg-5.s: New test.

2024-04-10  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: gcfg: add_bb_at_ginsn must return root_bb
	A GCFG (ginsn control flow graph) is created for SCFI purposes in GAS.
	The existing GCFG creation process was ignoring some paths.

	add_bb_at_ginsn () is a recursive function which should return the root
	of the added basic blocks.  This property was being violated in some
	traversals, e.g., where a taken path involving a sequence of a few basic
	blocks eventually culminated in a GINSN_TYPE_RETURN instruction.  This
	patch fixes the issue by keeping an explicit variable root_bb to
	memorize the bb to be returned.

	Next, find_or_make_bb () must either create or find the bb with the
	first ginsn as the provided ginsn.  Add a few assertions to ensure
	health of the cfg creation process.

	Note that the testcase, in its current shape, is not fit for catching
	regressions for the issue at hand.  Although the testcase does exercise
	the updated code path, the testcase passes even without the current fix,
	because the added edge in this specific testcase does not alter the
	synthesized CFI.  (The missing edge is the fallthrough edge of the
	conditional branch "jne .L13" in the testcase.)

	Using a manual gcfg_print (), one can see the missing edge without the
	fix.  Lets keep the testcase for now, until there is a better way to
	test the GCFG for this issue (e.g., either by dumping the GCFG in
	textual format, or a case when the missing edge does cause wrong
	synthesized CFI).

	gas/
		* ginsn.c (bb_add_edge): Fix a code comment.
		(find_bb): Likewise.
		(find_or_make_bb): Add new assertions to ensure health of cfg
		creation process.
		(add_bb_at_ginsn): Keep reference to the root_bb and return it.

	gas/testsuite/
		* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
		* gas/scfi/x86_64/scfi-cfg-4.d: New test.
		* gas/scfi/x86_64/scfi-cfg-4.l: New test.
		* gas/scfi/x86_64/scfi-cfg-4.s: New test.

2024-04-10  Christophe Lyon  <christophe.lyon@linaro.org>

	gdb, gdbserver: Add missing install-dvi Makefile target
	For some reason install-dvi is missing although other targets of the
	same family are present. This looks like an oversight.

	This enables calling 'make install-dvi' from the top-level build
	directory.

	Fix what looks like another oversight: include 'pdf' in 'all-doc' in
	gdb/doc/Makefile.in.

	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2024-04-10  Nick Clifton  <nickc@redhat.com>

	readelf: Add -j/--display-section command line option.

2024-04-10  H.J. Lu  <hjl.tools@gmail.com>

	mmap: Avoid the sanitizer configure check failure
	When -fsanitize=address,undefined is used to build, the mmap configure
	check failed with

	=================================================================
	==231796==ERROR: LeakSanitizer: detected memory leaks

	Direct leak of 4096 byte(s) in 1 object(s) allocated from:
	    #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239

	Direct leak of 4096 byte(s) in 1 object(s) allocated from:
	    #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190

	SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s).

	Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP to avoid the sanitizer
	configure check failure.

	bfd/

		* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
		* Makefile.in: Regenerated.
		* aclocal.m4: Likewise.
		* configure: Likewise.

	binutils/

		* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
		* Makefile.in: Regenerated.
		* aclocal.m4: Likewise.
		* configure: Likewise.

	ld/

		* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
		* Makefile.in: Regenerated.
		* aclocal.m4: Likewise.
		* configure: Likewise.

	libctf/

		* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
		* Makefile.in: Regenerated.
		* aclocal.m4: Likewise.
		* configure: Likewise.

	libsframe/

		* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
		* Makefile.in: Regenerated.
		* aclocal.m4: Likewise.
		* configure: Likewise.

2024-04-10  H.J. Lu  <hjl.tools@gmail.com>

	mmap: Avoid the sanitizer configure check failure
	When -fsanitize=address,undefined is used to build, the mmap configure
	check failed with

	=================================================================
	==231796==ERROR: LeakSanitizer: detected memory leaks

	Direct leak of 4096 byte(s) in 1 object(s) allocated from:
	    #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239

	Direct leak of 4096 byte(s) in 1 object(s) allocated from:
	    #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
	    #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190

	SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s).

	Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid
	the sanitizer configure check failure.

	config/

		* mmap.m4 (GCC_AC_FUNC_MMAP): New.
		* no-executables.m4 (AC_FUNC_MMAP): Renamed to GCC_AC_FUNC_MMAP.
		Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP.

	libiberty/

		* Makefile.in (aclocal_deps): Add $(srcdir)/../config/mmap.m4.
		* acinclude.m4: Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP.
		* aclocal.m4: Regenerated.
		* configure: Likewise.

	zlib/

		* acinclude.m4: Include ../config/mmap.m4.
		* Makefile.in: Regenerated.
		* configure: Likewise.

2024-04-10  Alan Modra  <amodra@gmail.com>

	Re: ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET
	Don't use CC_FOR_TARGET in the bootstrap test, a silly idea aiming at
	consistency that made things worse.  The objects being linked were
	built using $CC, so $CC should be used to link.

		* testsuite/ld-bootstrap/bootstrap.exp: Revert last change.

2024-04-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-09  Tom Tromey  <tom@tromey.com>

	Rewrite gdb_bfd_error_handler
	This patch rewrites gdb_bfd_error_handler to use 'bfd_print_error' to
	generate the text of the warning, and then emits it using 'warning'.
	The current code in the tree is a bit wrong because it may do the
	wrong thing when BFD uses ones of its printf extensions.

	This also adds locking to increment_bfd_error_count.  This is
	important now that some BFD operations can be done on worker threads.

	This approach makes it simpler for worker threads to intercept any
	messages.

	Regression tested on x86-64 Fedora 38.

2024-04-09  Jens Remus  <jremus@linux.ibm.com>

	aarch64: Treat operand "SME list of ZA tiles" as immediate (PR 31561)
	The AArch64 instruction table (aarch64-tbl.h) defines the operand
	"SME list of ZA tiles" (SME_list_of_64bit_tiles) as immediate. During
	assembly it is correctly encoded as immediate value (imm.value) in
	parse_operands. During disassembly it is first correctly decoded as
	immediate value (imm.value) in aarch64_ext_imm called by
	aarch64_extract_operand, but then erroneously treated as register
	number (reg.regno) in aarch64_print_operand.

	This resolves the assembler test case "SME extension (ZERO)" to
	erroneously fail on s390. On AArch64 - being little-endian - the struct
	aarch64_opnd_info union fields reg.regno and imm.value share their
	least-significant bits. On s390 - being big-endian - they do not.

	opcodes/
		PR binutils/31561
		* aarch64-opc.c: Treat operand "SME list of ZA tiles" as
		immediate.

	Bug: https://sourceware.org/PR31561
	Acked-by: Nick Clifton <nickc@redhat.com>

2024-04-09  Jens Remus  <jremus@linux.ibm.com>

	s390: Flag conditional branch relative insns as condjump
	Flag conditional branch relative (extended) mnemonics clij* and clgij*
	as "condjump" for jump visualization in disassembly. They were missed
	to be flagged as such in commit c5306fed7d40 ("s390: Support for jump
	visualization in disassembly").

	opcodes/
		* s390-opc.txt: Flag conditional branch relative instructions
		clij* and clgij* as condjump for jump visualization in
		disassembly.

	Acked-by: Nick Clifton <nickc@redhat.com>

2024-04-09  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Define pagesize variables only for mmap
	Define _bfd_pagesize, _bfd_pagesize_m1 and _bfd_minimum_mmap_size only
	if HAVE_MMAP is defined.

		* libbfd-in.h (_bfd_pagesize): Declare only if HAVE_MMAP is
		defined.
		(_bfd_pagesize_m1): Likewise.
		(_bfd_minimum_mmap_size): Likewise.
		* libbfd.c (_bfd_pagesize): Define only if HAVE_MMAP is defined.
		(_bfd_pagesize_m1): Likewise.
		(_bfd_minimum_mmap_size): Likewise.
		(bfd_init_pagesize): Likewise.
		* lynx-core.c (lynx_core_file_p): Replace _bfd_pagesize with
		getpagesize.

2024-04-09  Alex Coplan  <alex.coplan@arm.com>

	arm: Fix disassembly of MVE vq[r]shr[u]n
	This patch fixes the disassembly of vq[r]shr[u]n insns so that the
	shift immediate is properly decoded.  See the description of the
	previous patch for an example of the incorrect disassembly.

	As part of this patch we also fix the mve-vqrshrn.d test which was
	testing for the incorrect disassembly of the immediates.  The
	disassembly now matches the assembled instructions in that test.

	Finally we add an mve-vqshrn test which tests the non-rounding variants
	of those insns, whose encoding we fixed with the previous patch in this
	series.

2024-04-09  Alex Coplan  <alex.coplan@arm.com>

	arm: Fix encoding of MVE vqshr[u]n
	As it stands, these insns are incorrectly encoded as vqrshr[u]n.
	Concretely, the problem can be seen as follows:

	$ cat t.s
	vqrshrnb.s16 q0,q0,#8
	vqshrnb.s16 q0,q0,#8
	$ gas/as-new t.s -march=armv8.1-m.main+mve -o t.o
	$ binutils/objdump -d t.o -m armv8.1-m.main

	t.o:     file format elf32-littlearm

	Disassembly of section .text:

	00000000 <.text>:
	   0:   ee88 0f41       vqrshrnb.s16    q0, q0, #0
	   4:   ee88 0f41       vqrshrnb.s16    q0, q0, #0

	Here we assemble these two instructions to the same opcode.  The
	encoding of the first is the correct, while the encoding of the second
	is incorrect, and the bottom bit should be clear, see the Armv8-M ARM:
	https://developer.arm.com/documentation/ddi0553/latest/

	There is an additional problem here in that the disassembly of the
	immediate is incorrect.  llvm-objdump shows the correct disassembly
	here:

	t.o:    file format elf32-littlearm

	Disassembly of section .text:

	00000000 <$t>:
	       0: ee88 0f41     vqrshrnb.s16    q0, q0, #8
	       4: ee88 0f41     vqrshrnb.s16    q0, q0, #8

	Note that we defer adding a test for the correct encoding of these insns
	until the next patch which fixes the disassembly issue.

2024-04-09  Alex Coplan  <alex.coplan@arm.com>

	arm: Refactor condition for print_mve_shift_n
	This is intended to have no functional change, but refactors the
	condition guarding the call to print_mve_shift_n in arm-dis.c ahead of a
	later patch which adds additional insns to the set of those whose
	shift immediate is disassembled using print_mve_shift_n.

2024-04-09  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Support Zcmp push/pop instructions.
	Support zcmp extension push/pop/popret and popret zero instructions.
	The `reg_list' is a list containing 1 to 13 registers, we can use:
	"{ra}, {ra, s0}, {ra, s0-s1}, {ra, s0-s2} ... {ra, s0-sN}"
	to present this feature.

	Passed gcc/binutils regressions of riscv-gnu-toolchain.

	Most of work was finished by Sinan Lin.
	Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
	Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
	Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
	Co-Authored by: Simon Cook <simon.cook@embecosm.com>
	Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
	Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>

	bfd/ChangeLog:

	        * elfxx-riscv.c (riscv_implicit_subset): Imply zca for zcmp.
		(riscv_supported_std_z_ext): Added zcmp with version 1.0.
		(riscv_parse_check_conflicts): Zcmp conflicts with d/zcd.
	        (riscv_multi_subset_supports): Handle zcmp.
	        (riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* NEWS: Updated.
	        * config/tc-riscv.c (regno_to_reg_list): New function, used to map
		register to reg_list number.
	        (reglist_lookup): Called reglist_lookup_internal.  Return false if
		reg_list number is zero, which is an invalid value.
		(reglist_lookup_internal): Parse register list, and return the last
		register by regno_to_reg_list.
	        (validate_riscv_insn):  New operators.
	        (riscv_ip): Ditto.
		* testsuite/gas/riscv/march-help.l: Updated.
	        * testsuite/gas/riscv/zcmp-push-pop-fail.d: New test.
	        * testsuite/gas/riscv/zcmp-push-pop-fail.l: New test.
	        * testsuite/gas/riscv/zcmp-push-pop-fail.s: New test.
	        * testsuite/gas/riscv/zcmp-push-pop.d: New test.
	        * testsuite/gas/riscv/zcmp-push-pop.s: New test.

	include/ChangeLog:

	        * opcode/riscv-opc.h (MATCH/MASK_CM_PUSH): New macros for zcmp.
	        (MATCH/MASK_CM_POP): Ditto.
	        (MATCH/MASK_CM_POPRET): Ditto.
	        (MATCH/MASK_CM_POPRETZ): Ditto.
	        (DECLARE_INSN): New declarations for zcmp.
	        * opcode/riscv.h (EXTRACT/ENCODE/VALID_ZCMP_SPIMM): Handle spimm
		operand for zcmp.
	        (OP_MASK_REG_LIST): Handle operand for zcmp register list.
	        (OP_SH_REG_LIST): Ditto.
	        (ZCMP_SP_ALIGNMENT): New argument, used in riscv_get_sp_base.
	        (X_S0, X_S1, X_S2, X_S10, X_S11): New register numbers.
	        (enum riscv_insn_class): Added INSN_CLASS_ZCMP.
	        (extern riscv_get_sp_base): Added.

	opcodes/ChangeLog:

	        * riscv-dis.c (print_reg_list): New function, used to get zcmp
		reg_list field.
	        (riscv_get_spimm): New function, used to get zcmp sp adjustment
		immediate.
	        (print_insn_args): Handle new operands for zcmp.
	        * riscv-opc.c (riscv_get_sp_base): New function, used by gas and
		objdump.  Get sp base adjustment.
		(riscv_opcodes): Added zcmp instructions.

2024-04-09  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: ld: Move .got .got.plt before .data and protect .got with relro
	Move .got .got.plt before .data so .got can be protected with -zrelro.
	And the first two entries of .got.plt (_dl_runtime_resolve and link map)
	are placed within the relro region.

2024-04-09  Hu, Lin1  <lin1.hu@intel.com>

	Support {evex} pseudo prefix for decode evex promoted insns without egpr32.
	This patch is based on APX NF patch and also adds test cases for Checking 64-bit insns not sizeable through
	register operands with evex.

	gas/ChangeLog:

	        * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Added no-egpr testcases for movbe.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto.
	        * testsuite/gas/i386/x86-64.exp: Added tests.
	        * testsuite/gas/i386/noreg64-evex.d: New test.
	        * testsuite/gas/i386/noreg64-evex.e: Ditto.
	        * testsuite/gas/i386/noreg64-evex.s: Ditto.
	        * testsuite/gas/i386/x86-64-apx_f-evex.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx_f-evex.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex.h: Added %ME to movbe.
	        * i386-dis.c : Added %XE to evex_from_vex instructions to output {evex}.
	        (struct dis386): New %ME.
	        (putop): Handle %ME and output {evex} for evex_from_legacy instructions.
	        * Return early when the instruction name is (bad).

2024-04-09  Alan Modra  <amodra@gmail.com>

	Remove dead code in bfdwin.c
	All of bfdwin.c is wrapped in USE_MMAP.  There isn't any point in
	HAVE_MMAP tests inside USE_MMAP.

		* bfdwin.c (bfd_free_window, bfd_get_file_window): Delete
		HAVE_MMAP conditionals.

2024-04-09  Alan Modra  <amodra@gmail.com>

	ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET
	The idea here is build tests without sanitizer flags, so they don't
	fail due to many not using the compiler to link and thus result in
	undefined symbols, since libasan is not supplied.  We definitely do not
	want a compiler to perform linking in most cases, and it's complicated
	to supply libasan (and would possibly disturb testcase output).

		* testsuite/config/default.exp (CFLAGS_FOR_TARGET),
		(CXXFLAGS_FOR_TARGET): Append NOSANITIZE_CFLAGS.
		* testsuite/ld-bootstrap/bootstrap.exp: Use CC_FOR_TARGET and
		CFLAGS_FOR_TARGET throughout.

2024-04-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-08  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add PR ld/31615 tests
	PR ld/31615
		* testsuite/ld-plugin/lto.exp: Run ld/31615 tests.
		* testsuite/ld-plugin/pr31615.ver: New file.
		* testsuite/ld-plugin/pr31615a.c: Likewise.
		* testsuite/ld-plugin/pr31615b.c: Likewise.
		* testsuite/ld-plugin/pr31615c.c: Likewise.
		* testsuite/ld-plugin/pr31615d.c: Likewise.

2024-04-08  Alexandra Hájková  <ahajkova@redhat.com>

	remote.c: Make packet_ok return struct packet_result
	This allows the error message stored in a packet_result to be easily
	printed in the calling function.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-08  Alexandra Hájková  <ahajkova@redhat.com>

	remote.c: Use packet_check_result
	when processing the GDBserver reply to qRcmd packet.
	Print error message or the error code.
	Currently, when qRcmd request returns an error,
	GDB just prints:

	Protocol error with Rcmd

	After this change, GDB will also print the error code:

	Protocol error with Rcmd: 01.

	Add an accept_msg argument to packet_check result. qRcmd
	request (such as many other packets) does not recognise
	"E.msg" form as an error right now. We want to recognise
	"E.msg" as an error response only for the packets where
	it's documented.

	Also use packet_check result in remote_read_bytes_1.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/configure: realign the AC_ARG_ENABLE(sim, ....) block
	Following the suggestion in this review comment:

	  https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca

	this commit realigns the AC_ARG_ENABLE(sim, ....) block.  I've added
	additional [...] quoting in a couple of places, which is inline with
	how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac
	file.

	There should be no change in how GDB configures or builds after this
	commit.

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/build: apply silent-rules.mk to the data-directory Makefile.in
	This commit makes use of gdb/silent-rules.mk in the data-directory
	Makefile.in.  I've only updated the rules that actually generate
	things, I've not touched the install or uninstall rules, this matches
	gdb/Makefile.in.

	I've not managed to completely silence all of the recipe output, the
	mkinstalldirs command outputs some diagnostic text which looks like
	this:

	    GEN    stamp-python
	  mkdir -p -- ./python/gdb
	  mkdir -p -- ./python/gdb/command
	  mkdir -p -- ./python/gdb/dap
	  mkdir -p -- ./python/gdb/function
	  mkdir -p -- ./python/gdb/printer

	I have a patch for mkinstalldirs that fixes this (by adding a new
	--silent command line flag), but that patch needs to be submitted to
	automake, then an updated mkinstalldirs sync'd to the gcc repository,
	and then copied into the binutils-gdb repository... so I'm leaving
	that for a future project.

	Then the guild compiler also emits some diagnostic output, which looks
	like this:

	    GEN    stamp-guile
	  mkdir -p -- ./guile/.
	  mkdir -p -- ./guile/gdb
	  wrote `./gdb.go'
	  wrote `gdb/experimental.go'
	  wrote `gdb/iterator.go'
	  wrote `gdb/printing.go'
	  wrote `gdb/support.go'
	  wrote `gdb/types.go'

	The 'wrote' lines are from the guild compiler.  The only way to
	silence these would be to redirect stdout to /dev/null I think.  I did
	prototype this, but wasn't 100% convinced about that part of the
	patch, so I've decided to leave that for another day.

	I did need to add a new SILENT_ECHO variable to silent-rules.mk, this
	is set to a suitable 'echo' command to use within recipes.  When we
	are in silent mode then I use the 'true' command, while in verbose
	mode we actually use 'echo'.

	So, other than the issues outlined above, the output when building the
	data-directory is now greatly reduced, and more inline with the output
	when building in the gdb/ directory.

	There should be no change in what is actually built after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/configure: use AC_MSG_NOTICE not a direct echo call
	After the recent commits, I noticed that GDB's configure script would
	still emit two lines even when run in silent mode.  If you touch
	gdb/Makefile.in and then run 'make all' in the gdb/ build directory
	you'll see this:

	    GEN    config.status
	  enable_sim = no
	  enableval = no

	Obviously the 'no' might be 'yes' depending on how you actually
	configured GDB.

	This is caused by two direct invocations of 'echo' in GDB's
	configure.ac script.

	In this commit I replace these calls with use of AC_MSG_NOTICE
	instead.  Now when configure is run with the --silent command line
	option these lines will not be printed.

	There should be no changes in the built GDB after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/Makefile: Print 'GEN' message, and pass SILENT_FLAG more
	The targets that use config.status to regenerate themselves don't
	currently follow the silent rules that the rest of GDB's Makefile
	does.  For example, touch the gdb/gcore.in file and then 'make all' in
	the gdb/ directory prints:

	  /bin/sh config.status gcore
	  config.status: creating gcore

	In this commit I make use of the silent-rules.mk mechanism for these
	targets, now we get:

	  GEN    gcore

	Which matches the rest of our Makefile.  Obviously, if you pass 'V=1'
	to the build then you'll get the old output back.

	There's no change in what is generated after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/Makefile: add some missing config.status dependencies
	I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py,
	and gdb-gdb.gdb the rules all use the config.status script, but don't
	have a dependency on the config.status target.  This means we might
	fail to regenerate these targets in a case where config.status, or one
	of its dependencies changes.

	Two other targets that use config.status do correctly have a
	dependency on config.status.

	Fixed in this commit by adding the missing dependencies.

	There should be no changes in _what_ is generated after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/Makefile: rewrite dependencies for config.status target
	I noticed something weird, the rule for the config.status target looks
	like this:

	  config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh
	          $(SHELL) config.status --recheck

	What bothered me is that 'configure' is specified as being in
	$(srcdir), while all of the other files are not, even though those
	files are in the same $(srcdir) as the configure script.

	However, I tried touching one of those files, and the config.status
	rule does trigger!

	This is thanks to the VPATH variable, which is set to $(srcdir), so
	make looks in $(srcdir) for any dependencies.

	However, this inconsistency bothers me.  Better, I think, to add the
	$(srcdir) prefix to each of these files.

	I also spotted that the configure script also includes the files
	../bfd/config.bfd, yet that is missing from the include list, so in
	this commit I plan to add this as a dependency.

	The configure script also pulls in two TCL and TK related files:

		. ${TCL_BIN_DIR}/tclConfig.sh
		. ${TK_BIN_DIR}/tkConfig.sh

	However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently
	visible in GDB's Makefile, so I'm not planning to add these
	dependencies at this time.

	In this commit I add a new variable config_status_deps which holds the
	list of all the dependencies for config.status, with the $(srcdir)
	prefix included, and then I use this in the config.status rule.

	After this commit config.status will regenerate if config.bfd changes,
	which it wouldn't before, but nothing else changes.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/Makefile: add gcore to the 'all' target dependency list
	The gcore script is initially generated by the configure process, just
	like gdb-gdb.gdb and gdb-gdb.py.  However if the gdb/gcore.in input
	source is modified then 'make all' in the gdb/ directory does not
	regenerate the gcore script.

	This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their
	input is updated then 'make all' will regenerate these files.

	The difference is that for gdb-gdb.* there is an explicit dependency
	between the 'all' target and the generated file, this dependency is
	missing for gcore.

	This commit adds the dependency.  Now, if gcore.in is changed, running
	'make all' will regenerate the gcore script.

	There is no change in _what_ is generated after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: ignore -Wregister instead of -Wdeprecated-register
	When building GDB on Centos 7 (which has flex 2.5.37) and Clang, I get:

	    $ make ada-exp.o
	      YACC   ada-exp.c
	      LEX    ada-lex.c
	      CXX    ada-exp.o
	    In file included from /home/smarchi/src/binutils-gdb/gdb/ada-exp.y:1179:
	    <stdout>:1106:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
	     1106 |         register yy_state_type yy_current_state;
	          |         ^~~~~~~~

	In ada-lex.l, we already use `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER`,
	which for Clang translates to ignoring `-Wdeprecated-register` [1].  I think
	that was produced when compiling as C++11, but now that we always compile as
	C++17, Clang produces a `-Wregister` error [2].

	For GCC, `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` already translates to
	ignoring `-Wregister`.  So, rename
	`DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` to `DIAGNOSTIC_IGNORE_REGISTER`
	and ignore `-Wregister` for Clang too.

	[1] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wdeprecated-register
	[2] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wregister

	include/ChangeLog:

		* diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Rename
		to...
		(DIAGNOSTIC_IGNORE_REGISTER): ... this.  Ignore `-Wregister`
		instead of `-Wdeprecated-register`.

	Change-Id: I8a4a51c7222c68577fa22ecacdddfcba32d9dbc5

2024-04-08  Alan Modra  <amodra@gmail.com>

	Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1
	Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be
	created, resulting in _bfd_generic_link_add_one_symbol never
	returning.  Fix that.  Note that the MIND case handles two types of
	redefinition.  For a new indirect symbol we'll have string non-NULL.
	For a new def, string will be NULL.  So moving the string comparison
	earlier would work.  However, we've already looked up inh in the first
	case so can dispense with name comparisons.  Either way, for a new def
	we'll get to the defweak test and possibly cycle.  Which is what we
	want here.

		PR 31615
		PR 26978
		* linker.c (_bfd_generic_link_add_one_symbol <MIND>): Test for
		exactly matching indirect symbols before cycling on a defweak.

2024-04-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-07  Cui, Lili  <lili.cui@intel.com>

	Support APX NF
	For the case when NDD and NF are both 0 in evex-promoted format,
	we will fully support and test it in another patch.

	gas/ChangeLog:

	       * NEWS: Support Intel APX NF.
	       * config/tc-i386.c (enum i386_error): Add unsupported_nf.
	       (struct _i386_insn): Add has_nf.
	       (is_apx_evex_encoding): Ditto.
	       (build_apx_evex_prefix): Encode the NF bit.
	       (md_assemble): Handle unsupported_nf.
	       (parse_insn): Handle Prefix_NF and report bad for illegal combination.
	       (can_convert_NDD_to_legacy): Replace i.tm.opcode_modifier.nf with i.has_nf.
	       (match_template): Support D for APX_F insns and check NF support.
	       * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add bad test for NF bit.
	       * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.
	       * testsuite/gas/i386/x86-64-apx-inval.l: Ditto.
	       * testsuite/gas/i386/x86-64-apx-inval.s: Ditto.
	       * testsuite/gas/i386/x86-64.exp: Add apx nf tests.
	       * testsuite/gas/i386/x86-64-apx-nf-intel.d: New test.
	       * testsuite/gas/i386/x86-64-apx-nf.d: Ditto.
	       * testsuite/gas/i386/x86-64-apx-nf.s: Ditto.

	opcodes/ChangeLog:

	       * i386-dis-evex.h: Add %NF to the instructions that support APX NF and
	       add new instruction imul, popcnt, tzcnt and lzcnt to EVEX table.
	       * i386-dis-evex-reg.h: Ditto.
	       * i386-dis.c (struct instr_info): Add nf.
	       (struct dis386): Add "NF" for EVEX.NF.
	       (get_valid_dis386): Set ins->vex.nf and report bad-nf for illegal case.
	       (print_insn): Handle ins.vex.nf.
	       (putop): Handle "%NF".
	       * i386-opc.h (Prefix_NF): New.
	       * i386-opc.tbl: Added new entries to support full APX NF instructions.
	       * i386-mnem.h: Regenerated.
	       * i386-tbl.h: Regenerated.

2024-04-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-06  H.J. Lu  <hjl.tools@gmail.com>

	elf: Call bfd_malloc instead xmalloc
	* elflink.c (elf_link_add_object_symbols): Call bfd_malloc
		instead of xmalloc.

2024-04-06  H.J. Lu  <hjl.tools@gmail.com>

	Revert "x86: Restore APX shift-double instructions with omitted shift count"
	This reverts commit c2d698fe03a6092d58a07de96068b87836daced0.

	GCC 14 has been changed to use explicit shift count in shift-double
	instructions by the commit:

	06a7e7514af x86: Use explicit shift count in double-precision shifts

	gas/

		PR gas/31606
		* testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated.
		* testsuite/gas/i386/x86-64-apx-ndd.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-ndd.s: Remove tests for APX
		shift-double instructions with omitted shift count.

	opcodes/

		PR gas/31606
		* i386-opc.tbl: Remove APX shift-double instructions with
		omitted shift count.
		* i386-tbl.h: Regenerated.

2024-04-06  Alan Modra  <amodra@gmail.com>

	Don't have first_hash entries of strings that can be freed.
	Seen running "LTO 1" under valgrind.
	==1443263== Invalid read of size 1
	==1443263==    at 0x484CFE4: strcmp (vg_replace_strmem.c:939)
	==1443263==    by 0x56E16C: bfd_hash_lookup (hash.c:564)
	==1443263==    by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316)
	==1443263==    by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663)
	==1443263==    by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333)
	==1443263==    by 0x41448F: load_symbols (ldlang.c:3129)
	==1443263==    by 0x4149D8: open_input_bfds (ldlang.c:3621)
	==1443263==    by 0x414968: open_input_bfds (ldlang.c:3569)
	==1443263==    by 0x4166A2: lang_process (ldlang.c:8162)
	==1443263==    by 0x4194D5: main (ldmain.c:504)
	==1443263==  Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd
	==1443263==    at 0x484810F: free (vg_replace_malloc.c:974)
	==1443263==    by 0x8D4D87: objalloc_free_block (objalloc.c:248)
	==1443263==    by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790)
	==1443263==    by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333)
	==1443263==    by 0x41448F: load_symbols (ldlang.c:3129)
	==1443263==    by 0x4149D8: open_input_bfds (ldlang.c:3621)
	==1443263==    by 0x414968: open_input_bfds (ldlang.c:3569)
	==1443263==    by 0x4166A2: lang_process (ldlang.c:8162)
	==1443263==    by 0x4194D5: main (ldmain.c:504)

		PR ld/31482
		PR ld/31489
		* elflink.c (elf_link_add_to_first_hash): Add "copy" param.
		(elf_link_add_object_symbols): Flag that name must be copied
		when appending version string to symbol name.

2024-04-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-06  H.J. Lu  <hjl.tools@gmail.com>

	elf: Use elf_link_first_hash_entry for first_hash
	Add elf_link_first_hash_entry and use it for first_hash.  Free first_hash
	before freeing the main hash table.

		PR ld/31482
		PR ld/31489
		* elf-bfd.h (elf_link_hash_table): Change first_hash to
		bfd_hash_table.
		* elflink.c (elf_link_first_hash_entry): New.
		(elf_link_first_hash_newfunc): Likewise.
		(elf_link_add_to_first_hash): Updated.
		(elf_link_add_object_symbols): Initialize first_hash with
		elf_link_first_hash_newfunc.
		(elf_link_add_object_symbols): Updated.
		(elf_link_add_archive_symbols): Likewise.
		(_bfd_elf_link_hash_table_free): Free first_hash before freeing
		the main hash table.

2024-04-05  H.J. Lu  <hjl.tools@gmail.com>

	elf: Always honor the first definition in shared object and archive
	GCC doesn't put builtin function symbol references, which are defined in
	the shared C library, in the IR symbol table.  When linker rescans shared
	objects and archives for newly added symbol references generated from the
	IR inputs, it skips definitions of the builtin functions in shared
	objects and archives.

	Add first_hash to elf_link_hash_table to track unreferenced definitions
	defined first in shared objects and archives.  Always use them to resolve
	any references.

	bfd/

		PR ld/31482
		PR ld/31489
		* elf-bfd.h (elf_link_hash_table): Add first_hash.
		* elflink.c (elf_link_add_to_first_hash): New function.
		(elf_link_add_object_symbols): Initialize first_hash for an IR
		input.  Always use the first definition in shared object.  Add
		the first unreferenced dynamic definition to first_hash.
		(_bfd_elf_archive_symbol_lookup): Add the first unreferenced
		definition to first_hash..
		(elf_link_add_archive_symbols): Use the symbol definition in
		archive if symbol is defined first in this archive.
		(_bfd_elf_link_hash_table_free): Also free first_hash.

	ld/

		PR ld/31482
		PR ld/31489
		* testsuite/ld-plugin/lto.exp: Add PR ld/31482 and PR ld/31489
		tests.
		* testsuite/ld-elf/pr31482a-no-lto.c: New file.
		* testsuite/ld-elf/pr31482b-no-lto.c: Likewise.
		* testsuite/ld-elf/pr31482c-no-lto.c: Likewise.
		* testsuite/ld-elf/pr31482d-no-lto.c: Likewise.
		* testsuite/ld-plugin/pass1.out: Likewise.
		* testsuite/ld-plugin/pr31482a.c: Likewise.
		* testsuite/ld-plugin/pr31482b.c: Likewise.
		* testsuite/ld-plugin/pr31482c.c: Likewise.

2024-04-05  Zhiqing Xiong  <zhiqxion@qti.qualcomm.com>

	Add support for Windows network paths to the UNC support in _bfd_real_open().
	PR 31527

2024-04-05  Christophe Lyon  <christophe.lyon@linaro.org>

	Add missing install-dvi and install-ps Makefie targets.
	For some reason, these targets are missing although others from the
	same family are present. This looks like an oversight.

	This enables calling 'make install-dvi' from the top-level build
	directory.

2024-04-05  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Munmap readonly memory after bfd_free_cached_info
	Munmap readonly memory after bfd_free_cached_info which may use munmapped
	readonly memory.

		PR ld/31608
		* opncls.c (_bfd_delete_bfd): Munmap readonly memory after
		bfd_free_cached_info.

2024-04-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-04  H.J. Lu  <hjl.tools@gmail.com>

	bfd_mmap_local: Check offset and size
	Update bfd_mmap_local to return NULL if filesize < offset or filesize -
	offset < rsize.

		* libbfd.c (bfd_mmap_local): Validate offset and size against
		the file size.

2024-04-04  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Handle bmmap failure in _bfd_mmap_read_temporary
	iovec->bmmap may return MAP_FAILED, which happens in GDB on objects with
	iovec == opncls_iovec.  Update _bfd_mmap_read_temporary to handle
	iovec->bmmap failure.

		* libbfd.c (_bfd_mmap_read_temporary): Handle iovec->bmmap
		failure.

2024-04-04  H.J. Lu  <hjl.tools@gmail.com>

	x86: Restore APX shift-double instructions with omitted shift count
	Restore APX shift-double instructions with omitted shift count since
	they are generated by GCC as shown in:

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590

	gas/

		PR gas/31606
		* testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated.
		* testsuite/gas/i386/x86-64-apx-ndd.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-ndd.s: Add tests for APX
		shift-double instructions with omitted shift count.

	opcodes/

		PR gas/31606
		* i386-opc.tbl: Restore APX shift-double instructions with
		omitted shift count.
		* i386-tbl.h: Regenerated.

2024-04-04  Tom Tromey  <tromey@adacore.com>

	Add flake8 and isort to .pre-commit-config.yaml
	This adds flake8 and isort to .pre-commit-config.yaml.  This way, they
	will automatically be run on commit.

	I chose the most recent available versions after verifying that they
	don't cause any reports or changes in the current tree.

	Internally at AdaCore, we also use a few flake8 plugins as well, so
	perhaps that's another avenue for investigation.

	v2: Also update the various file-selection clauses to pick up
	gdb-gdb.py.in; include the isort change made to this file; and finally
	add a comment about the exclusions from flake8.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-04  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	Fix a test failure in gdb.threads/stepi-over-clone.exp
	When the XML support was disabled at compile time,
	the test case gdb.threads/stepi-over-clone.exp fails
	with lots of time-outs, which can be annoying.
	This makes the test case unsupported instead.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-04  Alan Modra  <amodra@gmail.com>

	MIPS HI16 and LO16 reloc howtos
	All the HI16 reloc howtos should have a rightshift of 16, and all the
	LO16 relocs shouldn't complain on overflow.  This was correct for
	R_MIPS_LO16 and R_MIPS_LO16 (at least on the howto_table_rel entries),
	and corresponding MIPS16, MICROMIPS and MIPS64 relocs, but not on many
	other HI16 and LO16 relocs.

	While we're at it, fix the HIGHER and HIGHEST rightshift too.

	These changes are necessary to support addends outside the range
	[0,32767] when those addends are stored in section contents.  Note
	that some of the reloc howtos changed here will always have zero
	addends (GOT_HI16, CALL_HI16).  Those don't really need changing, but
	use what is clearly correct for hi16 relocs anyway.

		PR 19977
		* elf32-mips.c: Correct rightshift for HI16, HIGHER and HIGHEST
		reloc howtos.  Correct complain_on_overflow for LO16 relocs.
		* elf64-mips.c: Likewise.
		* elfn32-mips.c: Likewise.

2024-04-04  Alan Modra  <amodra@gmail.com>

	Re: Update objcopy's --section-alignment option
	ubsan: left shift of 1 by 31 places cannot be represented in type 'int'

		* objcopy.c (setup_section): Avoid undefined behaviour when
		checking vma and lma for alignment.

2024-04-04  Nandakumar Edamana  <nandakumar@nandakumar.co.in>

	dlltool: replace unchecked malloc with xmalloc

2024-04-04  Alan Modra  <amodra@gmail.com>

	Memory corruption with USE_MMAP
	mips64-linux-gnuabi64  +FAIL: GOT page 4 (two files)
	mipsel-linux-gnu  +FAIL: GOT page 4 (two files)
	mipsisa32el-linux-gnu  +FAIL: GOT page 4 (two files)
	mips-linux-gnu  +FAIL: GOT page 4 (two files)
	powerpc64-freebsd  +FAIL: relocatable relaxing large
	powerpc64le-linux-gnu  +FAIL: relocatable relaxing large
	powerpc64-linux-gnu  +FAIL: relocatable relaxing large
	powerpc-eabisim  +FAIL: relocatable relaxing large
	powerpc-eabivle  +FAIL: relocatable relaxing large
	powerpc-freebsd  +FAIL: relocatable relaxing large
	powerpcle-elf  +FAIL: relocatable relaxing large
	powerpc-linux-gnu  +FAIL: relocatable relaxing large

		* elflink.c (bfd_elf_final_link): Heed bed->use_mmap when
		sizing buffers, not just USE_MMAP.

2024-04-04  Alan Modra  <amodra@gmail.com>

	Re: USE_MMAP fuzzed object file attacks
	I committed a broken patch.

		* aoutx.h (aout_get_external_symbols): Remove wrong #else and
		unneeded casts.
		* pdp11.c (aout_get_external_symbols): Likewise.

2024-04-04  Alan Modra  <amodra@gmail.com>

	Fix uninitialised variable errors
	Commit c6291d749aec introduced a number of errors, found by clang.

	elf.c:456:7: error: variable 'alloc_ext_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
	  if (_bfd_mul_overflow (symcount, extsym_size, &amt))
	      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	elf.c:464:7: error: variable 'alloc_extshndx_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
	  if (bfd_seek (ibfd, pos, SEEK_SET) != 0
	      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	elflink.c:2837:11: error: variable 'alloc1_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
	      if (internal_relocs == NULL)
	          ^~~~~~~~~~~~~~~~~~~~~~~
	elflink.c:12595:16: error: variable 'ext_size' set but not used [-Werror,-Wunused-but-set-variable]
	                      size_t ext_size = 0;

		* elf.c (bfd_elf_get_elf_syms): Fix use of uninitialised variables.
		* elflink.c (_bfd_elf_link_info_read_relocs): Likewise.
		(bfd_elf_final_link): Fix set but not used warning.

2024-04-04  Alan Modra  <amodra@gmail.com>

	USE_MMAP fuzzed object file attacks
	If mmap is used without sanity checking, then we'll get a SIGBUS if
	an access is done to the mmap'd memory corresponding to a page past
	end of file.

		* aoutx.h (aout_get_external_symbols): Check that mmap regions
		are within file contents.  Catch stringsize overflow.
		(some_aout_object_p): Don't clear already zeroed fields.  Tidy.
		* pdp11.c: As for aoutx.h.  Copy some fixes too.

2024-04-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Add _bfd_elf_link_m[un]map_section_contents
	To copy input section contents, add _bfd_elf_link_mmap_section_contents
	and _bfd_elf_link_munmap_section_contents to mmap in the input sections.

		* elf-bfd.h (_bfd_elf_link_mmap_section_contents): New.
		(_bfd_elf_link_munmap_section_contents): Likewise.
		* elf.c (elf_mmap_section_contents): New.
		(_bfd_elf_mmap_section_contents): Use it.
		(_bfd_elf_link_mmap_section_contents): New.
		(_bfd_elf_link_munmap_section_contents): Likewise.
		* elflink.c (elf_link_input_bfd): Call
		_bfd_elf_link_mmap_section_contents instead of
		bfd_get_full_section_contents.  Call
		_bfd_elf_link_munmap_section_contents to munmap the section
		contents.
		(bfd_elf_final_link): When mmap is used, initialize
		max_contents_size to _bfd_minimum_mmap_size and increase it
		for compressed or linker created sections or sections whose
		rawsize != size.

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Always keep symbol table and relocation info for eh_frame
	When --no-keep-memory is used, the symbol table and relocation info for
	eh_frame are freed after they are retrieved for each text section in the
	input object.  If an input object has many text sections, the same data
	is retrieved and freed many times which can take a very long time.
	Update _bfd_elf_gc_mark to keep the symbol table and relocation info for
	eh_frame to avoid it.  Data to link the 3.5GB clang executable in LLVM
	17 debug build on Linux/x86-64 with 32GB RAM is:

			before		after		improvement
	user		86.31		86.44		-0.2%
	system		8.77		8.63		1.6%
	total		95.58		96.81		-1.3%
	maximum set(GB)	13.1		13.1		0%
	page faults	3024752		3028699		-1.3%

	and data to link the 275M cc1plus executable in GCC 14 stage 1 build is:

	user		5.49		5.46		-0.5%
	system		0.73		0.73		0%
	total		6.26		6.25		0.3%
	maximum set(MB)	964		964		0%
	page faults	235173		235796		-0.3%

	The memory usage impact is minimum and the link time of the Rust binary
	in

	https://sourceware.org/bugzilla/show_bug.cgi?id=31466

	is reduced from 500+ seconds to 1.44 seconds, a 300x speedup.

		PR ld/31466
		* elflink.c (init_reloc_cookie): Add a bool argument, keep_memory,
		for keeping memory.  Always keep memory if keep_memory is true.
		(init_reloc_cookie_rels): Likewise
		(init_reloc_cookie_for_section): Add a bool argument for keeping
		memory and pass it to init_reloc_cookie and
		init_reloc_cookie_rels.
		(_bfd_elf_gc_mark_reloc): Pass false to _bfd_elf_gc_mark.
		(_bfd_elf_gc_mark): Pass true to init_reloc_cookie_for_section
		for the eh_frame section.  Pass false to
		init_reloc_cookie_for_section for other sections.
		(_bfd_elf_gc_mark_extra_sections): Add Add a bool argument for
		keeping memory and pass it to _bfd_elf_gc_mark.
		(bfd_elf_parse_eh_frame_entries): Pass false to init_reloc_cookie
		and init_reloc_cookie_rels.
		(bfd_elf_gc_sections): Pass false to init_reloc_cookie_for_section
		and _bfd_elf_gc_mark.
		(bfd_elf_discard_info): Pass false to
		init_reloc_cookie_for_section and init_reloc_cookie.

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Don't cache symbol nor relocation tables with mmap
	During a "-j 8" LLVM 17 debug build on a machine with 32GB RAM and 16GB
	swap, ld was killed by kernel because of out of memory:

	[79437.949336] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-9.scope,task=ld,pid=797431,uid=1000
	[79437.949349] Out of memory: Killed process 797431 (ld) total-vm:9219600kB, anon-rss:6558156kB, file-rss:1792kB, shmem-rss:0kB, UID:1000 pgtables:17552kB oom_score_adj:0

	Don't cache symbol nor relocation tables if they are mapped in.  Data to
	link the 3.5GB clang executable in LLVM 17 debug build on Linux/x86-64
	with 32GB RAM is:

			stdio		mmap		improvement
	user		86.73		87.02		-0.3%
	system		9.55		9.21		3.6%
	total		100.40		97.66		0.7%
	maximum set(GB)	17.34		13.14		24%
	page faults	4047667		3042877		25%

	and data to link the 275M cc1plus executable in GCC 14 stage 1 build is:

	user		5.41		5.44		-0.5%
	system		0.80		0.76		5%
	total		6.25		6.26		-0.2%
	maximum set(MB)	1323		968		27%
	page faults	323451		236371		27%

	These improve the overall system performance for parallel build by
	reducing memory usage and page faults.

	Also rename _bfd_link_keep_memory to _bfd_elf_link_keep_memory.  Since
	the --no-keep-memory linker option causes:

	https://sourceware.org/bugzilla/show_bug.cgi?id=31458

	this is opt-in by each backend.

	bfd/

		* elf32-i386.c (elf_i386_scan_relocs): Remove
		_bfd_link_keep_memory.
		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
		* elflink.c (_bfd_elf_link_keep_memory): New.
		(_bfd_elf_link_iterate_on_relocs): Replace _bfd_link_keep_memory
		with _bfd_elf_link_keep_memory.
		(elf_link_add_object_symbols): Likewise.
		(init_reloc_cookie): Likewise.
		(init_reloc_cookie_rels): Likewise.
		* libbfd-in.h (_bfd_link_keep_memory): Removed.
		* linker.c (_bfd_link_keep_memory): Likewise.
		* libbfd.h: Regenerated.

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Use mmap to map in symbol and relocation tables
	Add _bfd_mmap_read_temporary to mmap in symbol tables and relocations
	whose sizes >= 4 * page size.  For the final link, allocate an external
	relocation buffer of 4 * page size to avoid using mmap and munmap on
	smaller relocation sections.  Since _bfd_mmap_read_temporary allocates
	buffer as needed, its callers don't need to.

	When mmap is used to map in all ELF sections, data to link the 3.5GB
	clang executable in LLVM 17 debug build on Linux/x86-64 with 32GB RAM
	is:

			stdio		mmap		improvement
	user		84.79		85.27		-0.5%
	system		10.95		9.09		17%
	total		97.91		94.90		3%
	page faults	4837944		4033778		17%

	and data to link the 275M cc1plus executable in GCC 14 stage 1 build
	is:

	user		5.31		5.33		-0.4%
	system		0.86		0.76		12%
	total		6.19		6.13		1%
	page faults	361273		322491		11%

		* elf.c (bfd_elf_get_elf_syms): Don't allocate buffer for external
		symbol table.  Replace bfd_read with _bfd_mmap_read_temporary.
		* elflink.c (elf_link_read_relocs_from_section): Add 2 arguments
		to return mmap memory address and size.
		(_bfd_elf_link_info_read_relocs): Don't allocate buffer for
		external relocation information.  Replace bfd_read with
		_bfd_mmap_read_temporary.
		(bfd_elf_final_link): Cache external relocations up to
		_bfd_minimum_mmap_size bytes when mmap is used.
		* libbfd.c (_bfd_mmap_read_temporary): New.
		* libbfd-in.h (_bfd_mmap_read_temporary): Likewise.
		* libbfd.h: Regenerated.

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Add _bfd_elf_m[un]map_section_contents
	Add _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents.
	A backend must opt-in to use mmap.  It should replace

	bfd_malloc_and_get_section -> _bfd_elf_mmap_section_contents
	free			   -> _bfd_elf_munmap_section_contents

	on section contents.

		* compress.c (bfd_get_full_section_contents): Don't allocate
		buffer if mmapped_p is true.
		* elf-bfd.h (elf_backend_data): Add use_mmap.
		(bfd_elf_section_data): Add contents_addr and contents_size.
		(_bfd_elf_mmap_section_contents): New.
		(_bfd_elf_munmap_section_contents): Likewise.
		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Replace
		bfd_malloc_and_get_section and free with
		_bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents
		on section contents.
		* elf-sframe.c (_bfd_elf_parse_sframe): Likewise.
		* elf.c (_bfd_elf_make_section_from_shdr): Replace
		bfd_malloc_and_get_section and free with
		_bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents
		on section contents.
		(_bfd_elf_print_private_bfd_data): Likewise.
		(_bfd_elf_mmap_section_contents): New.
		(_bfd_elf_munmap_section_contents): Likewise.
		* elf32-i386.c (elf_i386_scan_relocs): Replace
		bfd_malloc_and_get_section and free with
		_bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents
		on section contents.
		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
		(elf_x86_64_get_synthetic_symtab): Likewise.
		* elfcode.h (elf_checksum_contents): Likewise.
		* elflink.c (elf_link_add_object_symbols): Likewise.
		(bfd_elf_get_bfd_needed_list): Likewise.
		* elfxx-target.h (elf_backend_use_mmap): New.
		(elfNN_bed): Add elf_backend_use_mmap.
		* elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Replace
		bfd_malloc_and_get_section and free with
		_bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents
		on section contents.
		(_bfd_x86_elf_get_synthetic_symtab): Replace free with
		_bfd_elf_munmap_section_contents.
		* elfxx-x86.h (elf_backend_use_mmap): New.
		* libbfd.c: Include "elf-bfd.h".
		(_bfd_generic_get_section_contents): Call bfd_mmap_local for
		mmapped_p.
		* opncls.c (_bfd_delete_bfd): Also munmap ELF section contents.
		* section.c (asection): Add mmapped_p.
		(BFD_FAKE_SECTION): Updated.
		(bfd_malloc_and_get_section): Add a sanity check for not
		mmapped_p.
		* bfd-in2.h: Regenerated.

2024-04-03  H.J. Lu  <hjl.tools@gmail.com>

	elf: Use mmap to map in read-only sections
	There are many linker input files in LLVM debug build with huge string
	sections.  All these string sections can be treated as read-only.  But
	linker copies all of them into memory which consumes huge amount of
	memory and slows down linker significantly.

	Add _bfd_mmap_readonly_persistent and _bfd_mmap_readonly_temporary to
	mmap in reado-only sections with size >= 4 * page size.

	NB: All string sections in valid ELF inputs must be null terminated.
	There is no need to terminate it again and string sections are mmapped
	as read-only.

		* bfd.c (bfd_mmapped_entry): New.
		(bfd_mmapped): Likewise.
		(bfd): Add mmapped.
		* bfdwin.c (bfd_get_file_window): Use _bfd_pagesize.
		* cache.c (cache_bmmap): Remove pagesize_m1 and use pagesize_m1
		instead.
		* elf.c (bfd_elf_get_str_section): Call
		_bfd_mmap_readonly_persistent instead of _bfd_alloc_and_read.
		Don't terminate the string section again.
		(get_hash_table_data): Call _bfd_mmap_readonly_temporary and
		_bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read
		and free.
		(_bfd_elf_get_dynamic_symbols): Call _bfd_mmap_readonly_persistent
		instead of _bfd_alloc_and_read.  Don't terminate the string
		section again.  Call _bfd_mmap_readonly_temporary and
		_bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read
		and free.
		(_bfd_elf_slurp_version_tables): Call _bfd_mmap_readonly_temporary
		and _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read
		and free.
		* elflink.c (bfd_elf_link_record_dynamic_symbol): Use bfd_malloc
		to get the unversioned symbol.
		* libbfd-in.h (_bfd_pagesize): New.
		(_bfd_pagesize_m1): Likewise.
		(_bfd_minimum_mmap_size): Likewise.
		(_bfd_mmap_readonly_persistent): Likewise.
		(_bfd_mmap_readonly_temporary): Likewise.
		(_bfd_munmap_readonly_temporary): Likewise.
		* libbfd.c
		(bfd_allocate_mmapped_page): New.
		(_bfd_mmap_readonly_temporary): Likewise.
		(_bfd_munmap_readonly_temporary): Likewise.
		(_bfd_mmap_readonly_persistent): Likewise.
		(_bfd_pagesize): Likewise.
		(_bfd_pagesize_m1): Likewise.
		(_bfd_minimum_mmap_size): Likewise.
		(bfd_init_pagesize): Likewise.
		* lynx-core.c (lynx_core_file_p): Use _bfd_pagesize.
		* opncls.c (_bfd_delete_bfd): Munmap tracked mmapped memories.
		* sysdep.h (MAP_ANONYMOUS): New. Define if undefined.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Likewise.

2024-04-03  Lancelot SIX  <lancelot.six@amd.com>

	Revert "gdb/compile: Use std::filesystem::remove_all in cleanup"
	This reverts commit 7bba0ad08576309763e3f41193eaa93025e10b8b.

	Tom de Vries reported that 7bba0ad0857 (gdb/compile: Use
	std::filesystem::remove_all in cleanup) broke builds with gcc-7.5.0
	which mostly supports c++17, but not std::filesystem[1].  As this change
	is not critical, revert it to maintain compatibility.

	[1] https://inbox.sourceware.org/gdb-patches/a06e6483-aa2e-4b8a-854f-e369a1e961ea@suse.de/

	Change-Id: I58150bd27600c95052bdf1bbbd6b44718a5a0bbf
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-03  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	doc: add the missing 'handle' attribute in xml
	The XML response to the "qXfer:threads:read" packet may include
	a "handle" attribute.  The attribute is mentioned in the document
	but not shown in the sample XML structure.  Add it.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-04-03  Lancelot SIX  <lancelot.six@amd.com>

	gdb/compile: Use std::filesystem::remove_all in cleanup
	In a previous review, I noticed that some code in gdb/compile/compile.c
	could use c++17's `std::filesystem::remove_all` instead of using some
	`system ("rm -rf ...");`.

	This patch implements this.

	Note that I use the noexcept overload of std::filesystem::remove_all and
	explicitly check for an error code.  This means that this code called
	during the cleanup procedure cannot throw, and does not risk preventing
	other cleanup functions to be called.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420
	Change-Id: If5668bf3e15e66c020e5c3b4fa999f861690e4cf
	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-03  Lancelot SIX  <lancelot.six@amd.com>

	gdb: ensure has dwarf info before reading DWZ file
	I recent change (e9b738dfbdc "Avoid race when reading dwz file") moved
	the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to
	dwarf2_has_info.

	Before that patch, dwarf2_initialize_objfile was only called when
	dwarf2_has_info returned true, and since that patch it is always called.

	When reading a file that has no debug info (.debug_info/.debug_abbrev
	sections), but has a .gnu_debugaltlink section, GDB’s behavior is
	different.  I can observe this when loading
	/lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging
	any program dynamically loading this library).

	Before e9b738dfbdc, we had:

	    $ ./gdb/gdb -data-directory ./gdb/data-directory -q  /lib/x86_64-linux-gnu/libtinfo.so
	    Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so...
	    (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so)
	    (gdb)

	while after we have:

	    $ ./gdb/gdb -data-directory ./gdb/data-directory -q  /lib/x86_64-linux-gnu/libtinfo.so
	    Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so...

	    warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3
	    (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so)
	    (gdb)

	This patch restores the previous behavior of only trying to load the
	DWZ file for objfiles when the main part of the debuginfo is present
	(i.e. when dwarf2_has_info returns true).  We still make sure that
	dwarf2_read_dwz_file is called at most once per objfile.

	A consequence of this change is that the per_bfd->dwz_file optional
	object can now remain empty (instead of containing a nullptr), so also
	this patch also adjusts dwarf2_get_dwz_file to account for this
	possibility.  This effectively reverts the changes to
	dwarf2_get_dwz_file done by e9b738dfbdc.

	Regression tested on x86_64-linux-gnu Ubuntu 22.04.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-04-03  Nick Clifton  <nickc@redhat.com>

	Fix null pointer dereference in process_debug_info()

	Extend objdump's --show-all-symbols option so that it also shows the extra symbols referenced by an instruction.

2024-04-03  Jan Beulich  <jbeulich@suse.com>

	Arm64: check tied operand specifier in aarch64-gen
	Make sure that field actually matches the specified operands. Don't
	follow existing F_PSEUDO checking in using assertions, though. Print
	meaningful error messages, thus - while not having a line number
	available - at least providing some indication of where things are
	wrong.

	Fix SVE2.1's extq accordingly, but don't extend the testsuite there:
	There are further issues with its operands (SVE_Zm_imm4 doesn't look to
	be correct to use there, as that describes an indexed vector register,
	while here a separate vector register and immediate operand are to be
	specified).

2024-04-03  Jan Beulich  <jbeulich@suse.com>

	x86: add missing No_qSuf to non-64-bit PTWRITE
	While largely benign, it still should have been put there when the
	original single template was split (commit a04973848dc5).

	x86: drop stray Size64 from WRSSQ
	Like for WRUSSQ it's not needed here. The legacy insn had gained it in
	the course of zapping Rex64, but that attribute wasn't needed here
	either. The APX insn then simply gained it by copy-and-paste, I suppose.

2024-04-03  Cui, Lili  <lili.cui@intel.com>

	x86/APX: Remove KEYLOCKER and SHA promotions from EVEX MAP4
	APX spec removed KEYLOCKER and SHA promotions from EVEX MAP4.
	https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

	gas/ChangeLog:

	        * NEWS: Mention that remove KEYLOCKER and SHA promotions from EVEX
		* MAP4.
	        * config/tc-i386.c (process_operands): Removed special handling of
		* KEYLOCKER and SHA.
	        * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Removed KEYLOCKER
	        * and SHA instructions.
	        * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto.
	        * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis-evex-prefix.h: Removed KEYLOCKER and SHA instructions.
	        * i386-dis-evex.h: Ditto.
	        * i386-opc.tbl: Ditto.
	        * i386-dis.c (print_vector_reg): Removed special handling of KEYLOCKER
		*  and SHA.

2024-04-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-02  Tom Tromey  <tom@tromey.com>

	libiberty: Invoke D demangler when --format=auto
	Investigating GDB PR d/31580 showed that the libiberty demangler
	doesn't automatically demangle D mangled names.  However, I think it
	should -- like C++ and Rust (new-style), D mangled names are readily
	distinguished by the leading "_D", and so the likelihood of confusion
	is low.  The other non-"auto" cases in this code are Ada (where the
	encoded form could more easily be confused by ordinary programs) and
	Java (which is long gone, but which also shared the C++ mangling and
	thus was just an output style preference).

	This patch also fixed another GDB bug, though of course that part
	won't apply to the GCC repository.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276

	libiberty
		* cplus-dem.c (cplus_demangle): Try the D demangler with
		"auto" format.
		* testsuite/d-demangle-expected: Add --format=auto test.

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Print type name when printing Rust slice
	The recent change to how unsized Rust values are printed included a
	small regression from past behavior.  Previously, a slice's type would
	be printed, like:

	    (gdb) print slice
	    $80 = &[i32] [3]

	The patch changed this to just

	    (gdb) print slice
	    $80 = [3]

	This patch restores the previous behavior.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Constify ada-lex.l:attributes
	While examining the Ada parser globals with 'nm', I noticed that the
	lexer's "attributes" array should be const.  This change moves it into
	read-only storage.

	Remove "numbuf" global
	The lexer has a "numbuf" global that is only used for temporary
	storage.  This patch removes the global and redeclares it at the
	points of use.

	Move "returned_complete" into ada_parse_state
	This moves the "returned_complete" global into ada_parse_state.

	Move "paren_depth" into ada_parse_state
	This moves the "paren_depth" global into ada_parse_state.

	Move "temp_parse_space" into ada_parse_state
	This patch moves the "temp_parse_space" global into ada_parse_state.
	It is also renamed to remove the redundant "parse".  Finally, it is
	changed to an auto_obstack to avoid the need for any manual
	management.

	Move "iterated_associations" into ada_parse_state
	This patch moves the "iterated_associations" global into
	ada_parse_state.

	Move "assignments" global into ada_parse_state
	This patch moves the "assignments" global into ada_parse_state.

	Move "components" and "associations" into ada_parse_state
	This patch moves the "components" and "associations" globals into
	ada_parse_state.

	Move "int_storage" global into ada_parse_state
	This patch moves the "int_storage" global into ada_parse_state.

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Introduce ada_parse_state
	This patch introduces the ada_parse_state class and the ada_parser
	global.  It also changes find_completion_bounds to be a method of this
	new type.

	Note that find_completion_bounds never used its parameter; and because
	it is generally fine to use the 'pstate' global throughout the parser,
	this patch removes the parameter entirely.

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Implement Ada 2022 iterated assignment
	Ada 2022 includes iterated assignment for array initialization.  This
	patch implements a subset of this for gdb.  In particular, only arrays
	with integer index types really work -- currently there's no decent
	way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during
	parsing.  Fixing this probably requires the Ada parser to take a
	somewhat more sophisticated approach to type resolution; and while
	this would help fix another bug in this area, this patch is already
	useful without it.

	Introduce and use aggregate_assigner type
	This patch is a refactoring to add a new aggregate_assigner type.
	This type is passed to Ada aggregate assignment operations in place of
	passing a number of separate arguments.  This new approach makes it
	simpler to change some aspects of aggregate assignment behavior.

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Run isort
	This patch is the result of running 'isort .' in the gdb directory.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Prepare gdb for isort
	This patch prepares gdb for isort: it adds a couple of isort marker
	comments where needed, and it adds an isort clause to setup.cfg.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Do not use bare "except"
	flake8 warns about a bare "except".  The docs point out that this will
	also catch KeyboardInterrupt and SystemExit exceptions, which is
	normally undesirable.  Using "except Exception" catches everything
	reasonable, so this patch makes this change.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Suppress some "undefined" warnings from flake8
	flake8 warns about some identifiers in __init__.py, because it does
	not realize these come from the star-imported _gdb module.  This patch
	suppresses these warnings.

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Specify ImportError in styling.py
	styling.py has a long try/except surrounding most of the body.  flake8
	warns about the final bare "except".  However, this except is really
	only there to catch the situation where the host doesn't have Pygments
	installed.  This patch changes this to only catch ImportError.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Suppress star import errors
	flake8 warns about the "from _gdb.disassembler import *" line in
	disassembler.py, and a similar line from __init__.py.  These line are
	needed to re-export names from the corresponding C++ module, so this
	patch applies the appropriate "noqa" flags.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Remove bare "except" from disassembler.py
	flake8 complains about a bare "except" in disassembler.py.  In this
	case, the code purports to guard against some kind of user error
	involving data structure corruption.  I think it's better here to just
	let the error occur -- py-disasm.c will show a stack trace in this
	case.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Remove unused import from gdb/__init__.py
	flake8 points out that the import of _gdb in gdb/__init__.py is
	unused.  Remove it.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Ignore unsed import in dap/__init__.py
	flake8 warns about dap/__init__.py because it has a number of unused
	imports.  Most of these are intentional: the import is done to ensure
	that the a DAP request is registered with the server object.

	This patch applies a "noqa" comment to these imports, and also removes
	one import that is truly unnecessary.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Fix flake8 errors in dap/server.py
	Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel")
	introduced some errors into dap/server.py.  A function is called but
	not imported, and the wrong variable name is used.  This patch
	corrects both errors.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom Tromey  <tromey@adacore.com>

	Remove .flake8
	I re-ran flake8 today and was puzzled to see W503 warnings.
	Eventually I found out that the setup.cfg config overrides .flake8.
	This patch merges the two and removes .flake8, to avoid future
	confusion.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-04-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing include in gdb.base/ctf-ptype.c
	On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get:
	...
	gdb compile failed, ctf-ptype.c: In function 'main':
	ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \
	  [-Wimplicit-function-declaration]
	  242 |   v_char_pointer = (char *) malloc (1);
	      |                             ^~~~~~
	ctf-ptype.c:1:1: note: include '<stdlib.h>' or provide a declaration of 'malloc'
	  +++ |+#include <stdlib.h>
	    1 | /* This test program is part of GDB, the GNU debugger.
	...

	Fix this by adding the missing include.

	Tested on aarch64-linux.

2024-04-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit target
	In an aarch32-linux chroot on an aarch64-linux system, I run into:
	...
	(gdb) print x^M
	$1 = 9223372036854775807^M
	(gdb) FAIL: gdb.ada/verylong.exp: print x
	...

	A passing version on aarch64-linux looks like:
	...
	(gdb) print x^M
	$1 = 170141183460469231731687303715884105727^M
	(gdb) PASS: gdb.ada/verylong.exp: print x
	...

	The difference is caused by the size of the type Long_Long_Long_Integer, which
	is:
	- a 128-bit signed on 64-bit targets, and
	- a 64-bit signed on 32-bit target.

	Fix this by detecting the size of the Long_Long_Long_Integer type, and
	handling it.

	Tested on aarch64-linux and aarch32-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31574
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574

	[1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html

2024-04-02  Nick Clifton  <nickc@redhat.com>

	Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections.   Add a check for aligned sections not matching their VMAs.

2024-04-02  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix centering and highlighting of current line
	After starting TUI like this with a hello world a.out:
	...
	$ gdb -q a.out -ex start -ex "tui enable"
	...
	we get:
	...
	┌─hello.c──────────────────────────────┐
	│        5 {                           │
	│        6   printf ("hello\n");       │
	│        7                             │
	│        8   return 0;                 │
	│        9 }                           │
	│                                      │
	└──────────────────────────────────────┘
	...

	This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main
	after resizing"), before which we had instead:
	...
	┌─hello.c──────────────────────────────┐
	│        4 main (void)                 │
	│        5 {                           │
	│  >     6   printf ("hello\n");       │
	│        7                             │
	│        8   return 0;                 │
	│        9 }                           │
	└──────────────────────────────────────┘
	...

	In other words, the problems are:
	- the active line (source line 6) is no longer highlighted, and
	- the active line is not vertically centered (screen line 2 out 6 instead of
	  screen line 3 out of 6).

	Fix these problems respectively by:
	- in tui_enable, instead of "tui_show_frame_info (0)" using
	  'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and
	- in tui_source_window_base::rerender, adding centering functionality.

	Tested on aarch64-linux.

	Co-Authored-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR tui/31522
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522

2024-04-02  H.J. Lu  <hjl.tools@gmail.com>

	PR31458, FAIL: MIPS eh-frame 3 with --no-keep-memory
		PR 31458
	bfd/
		* elf-bfd.h (_bfd_elf_link_read_relocs),
		(_bfd_elf_link_info_read_relocs): Constify section.
		* elflink.c: Likewise.
		* elfxx-mips.c (_bfd_mips_elf_eh_frame_address_size): Read
		relocs again in case --no-keep-memory.
	ld/
		* testsuite/ld-mips-elf/mips-elf.exp: Run --no-keep-memory
		version of eh-frame3 test.

2024-04-02  Alan Modra  <amodra@gmail.com>

	PR 30569, delete _bfd_mips_elf_early_size_sections
	PR30569 was triggered by a patch of mine 6540edd52cc0 moving the call
	to always_size_sections in bfd_elf_size_dynamic_sections earlier, made
	to support the x86 DT_RELR implementation.  This broke mips16 code
	handling stubs when --export-dynamic is passed to the linker, because
	numerous symbols then became dynamic after always_size_sections.  The
	mips backend fiddles with symbols in its always_size_sections.  Maciej
	in 902e9fc76a0e had moved the call to always_size_sections to after
	the export-dynamic code.  Prior to that, Nathan in 04c3a75556c0 moved
	it before the exec stack code, back to the start of
	bfd_elf_size_dynamic_sections which was where Ian put it originally
	in ff12f303355b.  So the call has moved around a little.  I'm leaving
	it where it is, and instead calling mips_elf_check_symbols from
	late_size_sections (the old size_dynamic_sections) which is now always
	called.  In fact, the whole of _bfd_mips_elf_early_size_sections can
	be merged into _bfd_mips_elf_late_size_sections.

2024-04-02  Alan Modra  <amodra@gmail.com>

	PR 30569, always call elf_backend_size_dynamic_sections
	This largely mechanical patch is preparation for a followup patch.

	For quite some time I've thought that it would be useful to call
	elf_backend_size_dynamic_sections even when no dynamic objects are
	seen by the linker.  That's what this patch does, with some renaming.
	There are no functional changes to the linker, just a move of the
	dynobj test in bfd_elf_size_dynamic_sections to target backend
	functions, replacing the asserts/aborts already there.  No doubt some
	of the current always_size_sections functions could be moved to
	size_dynamic_sections but I haven't made that change.

	Because both hooks are now always called, I have renamed
	always_size_sections to early_size_sections and size_dynamic_sections
	to late_size_sections.  I condisdered calling late_size_sections plain
	size_sections, since this is the usual target dynamic section sizing
	hook, but decided that searching the sources for "size_sections" would
	then hit early_size_sections and other functions.

2024-04-02  Alan Modra  <amodra@gmail.com>

	objdump --disassemble=sym peculiarities
	Given this testcase:
	 .text
	 mov $x1,%eax
	f1:
	 mov $f1,%eax
	 .type f1,@function
	 .size f1,.-f1

	 mov $x2,%eax
	f2:
	 mov $f2,%eax
	 .type f2,@function
	 .size f2,.-f2+0x1000 #bad size

	objdump --reloc --disassemble=f1 prints
	00000000 <f1-0x5>:
	   0:	b8 00 00 00 00       	mov    $0x0,%eax

	and objdump --reloc --disassemble=f2 prints
	0000000f <f2>:
	   f:	b8 0f 00 00 00       	mov    $0xf,%eax
				10: R_386_32	.text

	It seems for f1 we get the insn before f1 and no reloc whereas, post
	159daa36fa, f2 is disassembled correctly.  Some analysis says that
	find_symbol_for_address may return a symbol past the current address,
	and reloc skipping is broken.  Fix both of these problems.

		* objdump.c (disassemble_jumps, disassemble_bytes): Replace
	        relppp with relpp, ie. don't update caller's rel_pp.  Adjust
	        calls.
		(disassemble_section): Skip over relocs inside loop rather
	        than before loop.  Revert 7e538762c2c1.  If given a symbol,
		don't start disassembling until its address is reached.
		Correct end of function calculation.

2024-04-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-04-02  John David Anglin  <danglin@gcc.gnu.org>

	hppa: Implement PA 2.0 symbolic relocations for long displacements
	The PA 2.0 architecture introduced several new load and store
	instructions with long displacements.  These include floating
	point loads and stores for word mode, and integer and floating
	point loads and stores for double words.  Currently, ld does
	not correctly support symbolic relocations for these instructions.

	If these are used, ld applies the standard R_PARISC_DPREL14R
	relocation and corrupts the instruction.  This change uses
	bfd_hppa_insn2fmt to determine the correct relocation format.

	We need to check the computed displacement as the immediate
	value used in these instruction must be a multiple of 4 or 8
	depending on whether the access is for a word or double word.

	A misaligned offset can potentially occur if the symbol is not
	properly aligned or if $global$ (the global pointer) is not
	double word aligned.  $global$ is provided as a .data section
	start symbol.  The patch adjusts elf.sc and hppalinux.sh to
	align .data to a 8-byte boundary in non-shared and non-pie
	links.

	2024-04-01  John David Anglin  <danglin@gcc.gnu.org>

		PR ld/31503

	bfd/ChangeLog:

		* elf32-hppa.c (final_link_relocate): Output

	ld/ChangeLog:

		* emulparams/hppalinux.sh (DATA_SECTION_ALIGNMENT): Define.
		* scripttempl/elf.sc: Align .data section to DATA_SECTION_ALIGNMENT
		when relocating.

2024-04-01  Alan Modra  <amodra@gmail.com>

	asan: heap-buffer-overflow objdump.c:3299 in disassemble_bytes
	Fix yet another crash, this one with a fuzzed function symbol size.
	The patch also corrects objdump behaviour when both --disassemble=sym
	and --stop-address=value are given.  Previously --disassemble=sym
	overrode --stop-address, now we take the lower of the stop-address
	value and the end of function.

		* objdump.c (disassemble_section): Sanity check ELF st_size.

2024-04-01  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix the issue of excessive relocation generated by GD and IE
	Currently, whether GD and IE generate dynamic relocation is
	determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable.
	This results in dynamic relocations still being generated in some
	situations where dynamic relocations are not necessary (such as
	the undefined weak symbol in static links).

	We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether
	GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation,
	set need_reloc to true and indx to be a dynamic index.

	At the same time, some test cases were modified to use regular
	expression matching instead of complete disassembly matching.

2024-04-01  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Ignore .align if it is at the start of a section
	Ignore .align if it is at the start of a section and the alignment
	can be divided by the section alignment, the section alignment
	can ensure this .align has a correct alignment.

2024-04-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-31  Andrew Burgess  <aburgess@redhat.com>

	gdb: build dprintf commands just once in code_breakpoint constructor
	I noticed in code_breakpoint::code_breakpoint that we are calling
	update_dprintf_command_list once for each breakpoint location, when we
	really only need to call this once per breakpoint -- the data updated
	by this function, the breakpoint command list -- is per breakpoint,
	not per breakpoint location.  Calling update_dprintf_command_list
	multiple times is just wasted effort, there's no per location error
	checking, we don't even pass the current location to the function.

	This commit moves the update_dprintf_command_list call outside of the
	per-location loop.

	There should be no user visible changes after this commit.

2024-03-31  Andrew Burgess  <aburgess@redhat.com>

	gdb: the extra_string in a dprintf breakpoint is never nullptr
	Given the changes in the previous couple of commits, this commit
	cleans up some of the asserts and 'if' checks related to the
	extra_string within a dprintf breakpoint.

	This commit:

	  1. Adds some asserts to update_dprintf_command_list about the
	  breakpoint type, and that the extra_string is not nullptr,

	  2. Given that we know extra_string is not nullptr (this is enforced
	  when the breakpoint is created), we can simplify
	  code_breakpoint::code_breakpoint -- it no longer needs to check for
	  the extra_string is nullptr case,

	  3. In dprintf_breakpoint::re_set we can remove the assert (this will
	  be checked within update_dprintf_command_list, we can also remove
	  the redundant 'if' check.

	There should be no user visible changes after this commit.

2024-03-31  Andrew Burgess  <aburgess@redhat.com>

	gdb: change 'if' to gdb_assert in update_dprintf_command_list
	I noticed in update_dprintf_command_list that we handle the case where
	the bp_dprintf style breakpoint doesn't have a format and args string.

	However, I don't believe such a situation is possible.  The obvious
	approach certainly already catches this case:

	  (gdb) dprintf main
	  Format string required

	If it is possible to create a dprintf breakpoint without a format and
	args string then I think we should be catching this case and handling
	it at creation time, rather than having GDB just ignore the situation
	later on.

	And so, I propose that we change the 'if' that ignores the case where
	the format/args string is empty, and instead assert that we do always
	have a format/args string.  The original code, that handled an empty
	format/args string has existed since commit e7e0cddfb0d4, which is
	when dprintf support was added to GDB.

	If I'm correct and this situation can't ever happen then there should
	be no user visible changes after this commit.

2024-03-31  Andrew Burgess  <aburgess@redhat.com>

	gdb: create_breakpoint: asserts relating to extra_string/parse_extra
	The goal of this commit is to better define the API for
	create_breakpoint especially around the use of extra_string and
	parse_extra.  This will be useful in the next commit when I plan to
	make some changes to create_breakpoint.

	This commit makes one possibly breaking change: until this commit it
	was possible to create thread-specific dprintf breakpoint like this:

	  (gdb) dprintf call_me, thread 1 "%s", "hello"
	  Dprintf 2 at 0x401152: file /tmp/hello.c, line 8.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       dprintf        keep y   0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1
	          stop only in thread 1
	          printf "%s", "hello"
	  (gdb)

	This feature of dprintf was not documented, was not tested, and is
	slightly different in syntax to how we create thread specific
	breakpoints and/or watchpoints -- the thread condition appears after
	the first ','.

	I believe that this worked at all was simply by luck.  We happen to
	pass the parse_extra flag as true from dprintf_command to
	create_breakpoint.

	So in this commit I made the choice to change this.  We now pass
	parse_extra as false from dprintf_command to create_breakpoint.  With
	this done it is assumed that the only thing in the extra_string is the
	dprintf format and arguments.

	Beyond this change I've updated the comment on create_breakpoint in
	breakpoint.h, and I've then added some asserts into
	create_breakpoint as well as moving around some of the error
	handling.

	 - We now assert on the incoming argument values,

	 - I've moved an error check to sit after the call to
	   find_condition_and_thread_for_sals, this ensures the extra_string
	   was parsed correctly,

	In dprintf_command:

	 - We now throw an error if there is no format string after the
	   dprintf location.  This error was already being thrown, but was
	   being caught later in the process.  With this change we catch the
	   missing string earlier,

	 - And, as mentioned earlier, we pass parse_extra as false when
	   calling create_breakpoint,

	In create_tracepoint_from_upload:

	 - We now throw an error if the parsed location doesn't completely
	   consume the addr_str variable.  This error has now effectively
	   moved out of create_breakpoint.

2024-03-31  Andrew Burgess  <aburgess@redhat.com>

	gdb: create_breakpoint: add asserts and additional comments
	This commit extends the asserts on create_breakpoint (in the header
	file), and adds some additional assertions into the definition.

	The new assert confirms that when the thread and inferior information
	is going to be parsed from the extra_string, then the thread and
	inferior arguments should be -1.  That is, the caller of
	create_breakpoint should not try to create a thread/inferior specific
	breakpoint by *both* specifying thread/inferior *and* asking to parse
	the extra_string, it's one or the other.

	There should be no user visible changes after this commit.

2024-03-31  mengqinggang  <mengqinggang@loongson.cn>

	BFD: Fix the bug of R_LARCH_AGLIN caused by discard section
	To represent the first and third expression of .align, R_LARCH_ALIGN need to
	associate with a symbol. We define a local symbol for R_LARCH_AGLIN.
	But if the section of the local symbol is discarded, it may result in
	a undefined symbol error.

	Instead, we use the section name symbols, and this does not need to
	add extra symbols.

	During partial linking (ld -r), if the symbol associated with a relocation is
	STT_SECTION type, the addend of relocation needs to add the section output
	offset. We prevent it for R_LARCH_ALIGN.

	The elf_backend_data.rela_normal only can set all relocations of a target to
	rela_normal. Add a new function is_rela_normal to elf_backend_data, it can
	set part of relocations to rela_normal.

2024-03-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-30  Tom Tromey  <tom@tromey.com>

	Lower variable definitions in tui_redisplay_readline
	I noticed a redundant assignment to 'prev_col' in
	tui_redisplay_readline, and then went ahead and lowered most of the
	variable definitions in that function to their initialization point.

2024-03-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: don't include port numbers in test names
	The gdb.python/py-cmd-prompt.exp script includes a test that has a
	gdbserver port number within a test name.  As port numbers can change
	from one test run to the next (depending on what else is running on
	the machine at the time), this can make it hard to compare test
	results between runs.

	Give the test a specific name to avoid including the port number.

	There is no change in what is tested after this commit.

2024-03-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: avoid $pc/$sp values in test names
	Provide an explicit name for a test in gdb.base/pc-not-saved.exp to
	avoid printing $pc and $sp values in the test name -- these values
	might change between different test runs, which makes it harder to
	compare test results.

	There is no change in what is actually being tested with this commit.

2024-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing includes in gdb.trace/collection.c
	On fedora rawhide, with test-case gdb.trace/collection.exp, I get:
	...
	gdb compile failed, collection.c: In function 'strings_test_func':
	collection.c:227:13: error: implicit declaration of function 'malloc' \
	  [-Wimplicit-function-declaration]
	  227 |   longloc = malloc(500);
	      |             ^~~~~~
	collection.c:1:1: note: \
	  include '<stdlib.h>' or provide a declaration of 'malloc'
	  +++ |+#include <stdlib.h>
	    1 | /* This testcase is part of GDB, the GNU debugger.

	collection.c:228:3: error: implicit declaration of function 'strcpy' \
	  [-Wimplicit-function-declaration]
	  228 |   strcpy(longloc, ... );
	      |   ^~~~~~
	collection.c:1:1: note: include '<string.h>' or provide a declaration of \
	  'strcpy'
	  +++ |+#include <string.h>
	    1 | /* This testcase is part of GDB, the GNU debugger.
	collection.c:230:8: error: implicit declaration of function 'strlen' \
	  [-Wimplicit-function-declaration]
	  230 |   i += strlen (locstr);
	      |        ^~~~~~
	collection.c:230:8: note: include '<string.h>' or provide a declaration of \
	  'strlen'
	...

	Fix this by adding the missing includes.

	Tested on aarch64-linux.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.c
	On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I
	get:
	...
	gdb compile failed, break-asm-file.c:21:8: error: \
	  return type defaults to 'int' [-Wimplicit-int]
	   21 | static func()
	      |        ^~~~
	...

	Fix this by adding the missing return type.

	Tested on aarch64-linux.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-28  Tom Tromey  <tom@tromey.com>

	Make pascal_language::print_type handle varstring==nullptr
	PR gdb/31524 points out a crash when pascal_language::print_type is
	called with varstring==nullptr.  This crash is a regression arising
	from the printf/pager rewrite -- that indirectly removed a NULL check
	from gdb's "puts".

	This patch instead fixes the problem by adding a check to print_type.
	Passing nullptr here seems to be expected in other places (e.g., there
	is a call to type_print like this in expprint.c), and other
	implementations of this method (or related helpers) explicitly check
	for NULL.

	I didn't write a test case for this because it seemed like overkill
	for a Pascal bug that only occurs with -i=mi.  However, if you want
	one, let me know and I will do it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-28  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: gcfg: fix handling of non-local direct jmps in gcfg
	The ginsn infrastructure in GAS includes the ability to create a GCFG
	(ginsn CFG).  A GCFG is currently used for SCFI passes.

	This patch fixes the following invalid assumptions / code blocks:
	 - The function ginsn_direct_local_jump_p () was erroneously _not_
	   checking whether the symbol is locally defined (i.e., within the
	   scope of the code block for which GCFG is desired).  Fix the code
	   to do so.
	 - Similarly, the GCFG creation code, in gcfg_build () itself had an
	   assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be
	   seen.  The latter can indeed be seen, and in fact, needs to be treated
	   the same way as an exit from the function in terms of control-flow.

	gas/
	        * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol
		is local to the code block or function being assembled.
	        (add_bb_at_ginsn): Remove buggy assumption.
	        (frch_ginsn_data_append): Direct jmps do not disqualify a stream
		of ginsns from GCFG creation.

	gas/testsuite/
		* gas/scfi/x86_64/scfi-cfg-3.d: New test.
		* gas/scfi/x86_64/scfi-cfg-3.l: New test.
		* gas/scfi/x86_64/scfi-cfg-3.s: New test.
		* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86/SSE2AVX: move checking
	It has always been looking a little odd to me that this was done deep
	in cpu_flags_match(). Move it to match_template() itself - there's no
	need to do anything complex when encountering such a template while it
	cannot possibly be used.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86/SSE2AVX: respect prefixes
	1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to
	   also do so with -msse2avx, converting to VEX.W.

	2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2}
	   shouldn't either.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	gas: drop integer_constant()'s maxdig
	Once properly set, it's only ever holding the same value as "radix".
	Even if there was some plan with it, that plan hasn't made it anywhere
	in over 20 years.

	gas: drop dead check for double quote
	FB and dollar label definitions can't be enclosed in double quotes. In
	fact at that point nul_char is the same as next_char, which we know is a
	digit.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	gas: sanitize FB- and dollar-label uses
	I don't view it as sensible to be more lax when it comes to references
	to (uses of) such labels compared to their definition: The latter has
	been limited to decimal numerics, while the former permitted any radix.
	Beyond that leading zeroes on such labels aren't helpful either. Imo
	labels and their use sites would better match literally, to avoid
	confusion.

	As it turns out, one z80 testcase actually had such an odd use of labels
	where definition and use don't match in spelling. That testcase is being
	adjusted accordingly.

	While there also adjust a comment on a local variable in
	integer_constant().

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize RAO-INT insns
	It's only four of them, but still better to reduce redundancy.

	x86: templatize ADX insns
	It's only two of them, but still better to reduce redundancy.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize shift-double insns
	With the multitude of new APX templates, it finally becomes desirable to
	further remove redundancy by also templatizing basic arithmetic insns.
	Continue with the shift-double ones.

	While there also drop the APX form with ShiftCount omitted. Other shift
	and rotate insns were deliberately left without this form as well. Note
	that there's also no testsuite adjustment needed for this, indicating
	that the form wasn't tested either.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize shift/rotate insns
	With the multitude of new APX templates, it finally becomes desirable to
	further remove redundancy by also templatizing basic arithmetic insns.
	Continue with the "ordinary" shift and rotate ones.

	While there also drop the APX form of RCL/RCR with Imm1 omitted. Other
	shift insns as well as ROR/ROL were deliberately left without this form
	as well. Note that there's also no testsuite adjustment needed for this,
	indicating that the form wasn't tested either.

	Furthermore since RCL/RCR already had non-NDD APX forms, those end up
	being added for the other 6 mnemonics, too.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize binary ALU insns
	With the multitude of new APX templates, it finally becomes desirable to
	further remove redundancy by also templatizing basic arithmetic insns.
	Continue with a the more complex binary (two source) cases.

	Note how this adds a missing CheckOperandSize to one of the APX sub
	forms.

	Furthermore since SBB already had a non-NDD APX form, one ends up
	being added for the other 6 mnemonics, too.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize unary ALU insns
	With the multitude of new APX templates, it finally becomes desirable to
	further remove redundancy by also templatizing basic arithmetic insns.
	Continue with a few simple unary (single source) cases.

2024-03-28  Jan Beulich  <jbeulich@suse.com>

	x86: templatize INC/DEC
	With the multitude of new APX templates, it finally becomes desirable to
	further remove redundancy by also templatizing basic arithmetic insns.
	Start with the simplest case, accompanied by a necessary adjustment to
	i386-gen (such that template uses can also be at the start of a line).

	While there also drop a bogus (meaningless / unreachable) "break" as
	well as a unused variable (which I'm surprised compilers didn't warn
	about).

2024-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux
	On aarch64-linux, using the manjaro linux distro, I run into:
	...
	(gdb) next^M
	32      }^M
	(gdb) next^M
	0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M
	(gdb) FAIL: gdb.base/ending-run.exp: step out of main
	...

	What happens here is described in detail in this clause:
	...
	    -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" {
		# This case occurs on Powerpc when gdb steps out of main and the
		# needed debug info files are not loaded on the system, preventing
		# GDB to determine which function it reached (__libc_start_call_main).
		# Ideally, the target system would have the necessary debugging
		# information, but in its absence, GDB's behavior is as expected.
		...
	    }
	...
	but the clause only matches for powerpc.

	Fix this by:
	- making the regexp generic enough to also match /usr/lib/libc.so.6, and
	- updating the comment to not mention powerpc.

	Tested on aarch64-linux.

	PR testsuite/31450
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450

2024-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux
	When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using
	the manjaro linux distro, I get:
	...
	 (gdb) thread apply all bt^M
	 ^M
	 Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M
	 #0  0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M
	 #1  0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M
	 #2  0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M
	 #3  0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M
	 #4  0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M
	 #5  0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M
	 ^M
	 Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M
	 #0  0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M
	 #1  0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M
	 #2  0x0000aaaade37086c in main () at attach-stopped.c:45^M
	 (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt
	...

	The problem is that the test-case expects to see start_thread:
	...
		gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \
		    "$threadtype: attach2 to stopped bt"
	...
	but lack of symbols makes that impossible.

	Fix this by allowing " in ?? () from " as well.

	Tested on aarch64-linux.

	PR testsuite/31451
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451

2024-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing include in gdb.base/rtld-step.exp
	On fedora rawhide, with test-case gdb.base/rtld-step.exp I get:
	...
	static-pie-static-libc.c: In function '_start':^M
	static-pie-static-libc.c:1:22: error: \
	  implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M
	    1 | void _start (void) { _exit (0); }^M
	      |                      ^~~~~^M
	compiler exited with status 1
	  ...
	UNTESTED: gdb.base/rtld-step.exp: failed to compile \
	  (-static-pie not supported or static libc missing)
	...

	Fix this by adding the missing include.

	Tested on aarch64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-03-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Removed privileged spec 1.9.1 support in assembler.
	Removed since it's may have lots of conflicts with the newer extensions, but
	still keep linker recognizes it in case of linking old objects.

	gas/
		* NEWS: Updated.
		* config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as
		an unknown version.
		(md_show_usage): Removed privileged spec 1.9.1 information.
		* testsuite/gas/riscv/attribute-05.s: Updated since privileged spec
		1.9.1 is unsupported.
		* testsuite/gas/riscv/attribute-05.d: Likewise.
		* testsuite/gas/riscv/attribute-12.d: Likewise.
		* testsuite/gas/riscv/attribute-13.d: Likewise.
		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
		* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
		* testsuite/gas/riscv/csr.s: Likewise.
		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p9p1.d: Removed.
		* testsuite/gas/riscv/csr-version-1p9p1.l: Removed.
	include/
		* opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is
		unsupported.
	ld/
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since
		privileged spec 1.9.1 is unsupported.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise.
		* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise.

2024-03-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-27  Tom Tromey  <tromey@adacore.com>

	Fix clang build
	Simon pointed out that commit 818ef5f4 ("Capture warnings when writing
	to the index cache") broke the build with clang.  This patch fixes the
	breakage.

2024-03-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: remove includes of early headers
	Now that defs.h, server.h and common-defs.h are included via the
	`-include` option, it is no longer necessary for source files to include
	them.  Remove all the inclusions of these files I could find.  Update
	the generation scripts where relevant.

	Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
	Approved-By: Pedro Alves <pedro@palves.net>

2024-03-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: include early header files with `-include`
	The motivation for this change is for analysis tools and IDEs to be
	better at analyzing header files on their own.

	There are some definitions and includes we want to occur at the very
	beginning of all translation units.  The way we currently do that is by
	requiring all source files (.c and .cc files) to include one of defs.h
	(for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
	shared source files).  These special header files define and include
	everything that needs to be included at the very beginning.  Other
	header files are written in a way that assume that these special
	"prologue" header files have already been included.

	My problem with that is that my editor (clangd-based) provides a very
	bad experience when editing header files.  Since clangd doesn't know
	that one of defs.h/server.h/common-defs.h was included already, a lot of
	things are flagged as errors.  For instance, CORE_ADDR is not known.
	It's possible to edit the files in this state, but a lot of the power of
	the editor is unavailable.

	My proposal to help with this is to include those things we always want
	to be there using the compilers' `-include` option.  Tom Tromey said
	that the current approach might exist because not all compilers used to
	have an option like this.  But I believe that it's safe to assume they
	do today.

	With this change, clangd picks up the -include option from the compile
	command, and is able to analyze the header file correctly, as it sees
	all that stuff included or defined by that -include option.  That works
	because when editing a header file, clangd tries to get the compilation
	flags from a source file that includes said header file.

	This change is a bit self-serving, because it addresses one of my
	frustrations when editing header files, but it might help others too.
	I'd be curious to know if others encounter the same kinds of problems
	when editing header files.  Also, even if the change is not necessary by
	any means, I think the solution of using -include for stuff we always
	want to be there is more elegant than the current solution.

	Even with this -include flag, many header files currently don't include
	what they use, but rather depend on files included before them.  This
	will still cause errors when editing them, but it should be easily
	fixable by adding the appropriate include.  There's no rush to do so, as
	long as the code still compiles, it's just a convenience thing.

	The changes are:

	 - Add the appropriate `-include` option to the various Makefiles.

	 - There is one particularity for gdbserver's Makefile: we do not want
	   to include server.h when building `gdbreplay.o`, as `gdbreplay.cc`
	   doesn't include it.  So we can't simply put the `-include` in
	   `INTERNAL_CFLAGS`.  Add the `-include server.h` option to the
	   `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule
	   to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`.

	 - Remove the `-include` option from the `check-headers` rule in
	   gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`.

	Change-Id: If3e345d00a9fc42336322f1d8286687d22134340
	Approved-By: Pedro Alves <pedro@palves.net>

2024-03-27  Simon Marchi  <simon.marchi@efficios.com>

	{gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables
	Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their
	contents in `INTERNAL_CFLAGS`.  Not functional changes expected.

	Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f
	Approved-By: Pedro Alves <pedro@palves.net>

2024-03-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line
	Reformat some variables definitions.  I think it makes them easier to
	read, and it also makes diffs clearer.

	Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02
	Approved-By: Pedro Alves <pedro@palves.net>

2024-03-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make gdbarch_types.py non-executable
	I noticed that gdbarch_types.py is executable.  It's not needed, since
	it's only imported from gdbarch.py.

	Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e

2024-03-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-26  Andrew Burgess  <aburgess@redhat.com>

	Revert "gdbserver: convert have_ptrace_getregset to a tribool"
	This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c.

	Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory"
	This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354.

	Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description"
	This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e.

	Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition"
	This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54.

	Revert "gdb/gdbserver: share some code relating to target description creation"
	This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd.

	Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32"
	This reverts commit efba976d9713a92b4507ccfef2257e4589da2798.

	Revert "gdbserver: update target description creation for x86/linux"
	This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a.

	Revert "gdb/gdbserver: share x86/linux tdesc caching"
	This reverts commit 198ff6ff819c240545f9fc68b39636fd376d4ba9.

	Revert "gdbserver/Makefile.in: add missing `-x c++`"
	This reverts commit c7c9820071f8b81a64221f5cfafb3cbfeafe7916.

	Revert "gdb: fix possible uninitialised variable use"
	This reverts commit 24df37a10f8773ad5db07dc000f694d6405e3a36.

	Revert "gdb/gdbserver: fix some defined but unused function warnings"
	This reverts commit f4c19f89ef43dbce8065532c808e1aeb05d08994.

2024-03-26  Tom Tromey  <tromey@adacore.com>

	Remove redundant check from parse_number.exp
	A user on irc pointed out that parse_number.exp has a redundant check.
	This patch removes the duplicate.

2024-03-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix valgrind tests on debian
	On debian 12, I run into:
	...
	(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
	Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
	relaying data between gdb and process 618591^M
	warning: remote target does not support file transfer, \
	  attempting to access files from local filesystem.^M
	Reading symbols from /lib/ld-linux-aarch64.so.1...^M
	(No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M
	0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M
	(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
	...

	The problem is that we're expecting to match either of these regexps:
	...
		set start_re1 " in \\.?_start "
	        set start_re2 "\\.?_start \\(\\) at "
	...
	but there are no dwarf or elf symbols present.

	Fix this by also allowing:
	...
	       set start_re3 "$::hex in \\?\\? \\(\\) from "
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-26  Tom Tromey  <tromey@adacore.com>

	Capture warnings when writing to the index cache
	PR symtab/30837 points out a race that can occur when writing to the
	index cache: a call to ada_encode can cause a warning, which is
	forbidden on a worker thread.

	This patch fixes the problem by arranging to capture any such
	warnings.

	This is v2 of the patch.  It is rebased on top of some other changes
	in the same area.  v1 was here:

	    https://sourceware.org/pipermail/gdb-patches/2024-February/206595.html

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30837

2024-03-26  H.J. Lu  <hjl.tools@gmail.com>

	Don't claim a fat IR object if no IR object should be claimed
	When the linker sees an input object containing nothing but IR during
	rescan, it should ignore it (LTO phase is over).  But if the input object
	is a fat IR object, which has non-IR code as well, it should be used to
	resolve references as if it did not contain any IR at all.  This patch
	adds lto_type to bfd and linker avoids claiming a fat IR object if no IR
	object should be claimed.

	bfd/

		PR ld/23935
		* archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type
		instead of lto_slim_object.
		* elflink.c (elf_link_add_object_symbols): Likewise.
		* bfd.c (bfd_lto_object_type): New.
		(bfd): Remove lto_slim_object and add lto_type.
		(bfd_get_lto_type): New function.
		* elf.c (lto_section): Removed.
		(_bfd_elf_make_section_from_shdr): Don't set lto_slim_object.
		* format.c: (lto_section): New.
		(bfd_set_lto_type): New function.
		(bfd_check_format_matches): Call bfd_set_lto_type.
		* bfd-in2.h: Regenerated.

	binutils/

		PR ld/23935
		* nm.c (display_rel_file): Check bfd_get_lto_type instead of
		lto_slim_object.

	ld/

		PR ld/23935
		* ldmain.c (add_archive_element): Don't claim a fat IR object if
		no IR object should be claimed.
		* testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test.
		Add PR ld/23935 test.
		* testsuite/ld-plugin/pr23935a.c: New file.
		* testsuite/ld-plugin/pr23935b.c: Likewise.

2024-03-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: fix some defined but unused function warnings
	This commit:

	  commit 198ff6ff819c240545f9fc68b39636fd376d4ba9
	  Date:   Tue Jan 30 15:37:23 2024 +0000

	      gdb/gdbserver: share x86/linux tdesc caching

	added some functions which are always defined, but their use is
	guarded within various #ifdef blocks.  As a result we were seeing
	errors about defined, but unused, functions.

	I've fixed this problem in this commit by wrapping the function
	definitions within #ifdef blocks.

	I'm a little worried that there might be too many #ifdef blocks within
	this file, however, I'm going to commit this fix for now as this will
	fix the build, then I'll think about if there's a better way to split
	this file so we might avoid some of these #ifdef blocks.

2024-03-26  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix possible uninitialised variable use
	After this commit:

	  commit 198ff6ff819c240545f9fc68b39636fd376d4ba9
	  Date:   Tue Jan 30 15:37:23 2024 +0000

	      gdb/gdbserver: share x86/linux tdesc caching

	a possible use of an uninitialised variable was introduced, the
	'tdesc' variable in i386_linux_core_read_description might be read
	without being written too if 'xcr0' was 0.

	This is fixed in this commit.  I've updated the function to follow the
	same pattern as amd64_linux_core_read_description, if xcr0 is 0 then
	we select a default xcr0 value and use that to select a tdesc.

2024-03-26  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver/Makefile.in: add missing `-x c++`
	When building with Clang, I get:

	      CXX    nat/x86-linux-tdesc-ipa.o
	    clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]

	Fix that by adding the missing `-x c++` in the rule building
	`gdb/nat/*.c` files for the in-process agent.

	Change-Id: Ie53e4b9a8b57bef9669397fdfaf21617107c7180
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb: mark addrmap classes `final`
	When building GDB with clang, I see:

	    /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non
	    -abstract-non-virtual-dtor]
	       95 |         delete __ptr;
	          |         ^
	    /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete<addrmap_mutable>::operator()' requested here
	      396 |           get_deleter()(std::move(__ptr));
	          |           ^
	    /home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr<addrmap_mutable>::~unique_ptr' requested here
	      422 |   auto map = std::make_unique<struct addrmap_mutable> ();
	          |              ^

	Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too
	while at it.

	Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix infinite recursion on calloc with multi-threaded applications
	libcollector uses pthread_getspecific() and pthread_setspecific() to access
	thread local memory. libcollector uses this memory to check that
	interposed functions (like malloc, calloc or free) don't have recursion.
	The first time we call calloc(), we call pthread_setspecific() to create
	a thread-specific value.
	On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept
	such recursion.
	gcc supports thread-local storage. For example,
	  static __thread int reentrance = 0;
	I rewrote code using this instead of pthread_setspecific().

	gprofng/ChangeLog
	2024-03-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31460
		* libcollector/heaptrace.c: Use the __thread variable to check for
		* reentry. Clean up code.

2024-03-25  Pedro Alves  <pedro@palves.net>

	gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode
	Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all
	test programs.  When running the testsuite in parallel mode, on
	Cygwin, I noticed errors like:

	  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory
	...
	  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory
	...
	  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied

	(Absolute paths elided above.)

	The problem is that gdb_compile's unbuffered_mode_obj cache isn't
	parallel safe.  This is fixed in this commit.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>
	Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2

2024-03-25  Pedro Alves  <pedro@palves.net>

	Fix windows_nat_target::fake_create_process ptid
	While working on Windows non-stop mode, I managed to introduce a bug
	that led to fake_create_process being called.  That then resulted in
	GDB crashes later on, because fake_create_process added a thread with
	an incorrect ptid for this target.  It is putting dwThreadId in the
	tid field of the ptid instead of on the lwp field.  This is fixed by
	this patch.

	Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	bfd: make _bfd_section_size_insane part of the public API
	If a BFD user is making use of a function like
	bfd_get_section_contents to read a section into a pre-allocated
	buffer, then that BFD user might also want to make use of
	_bfd_section_size_insane prior to allocating the buffer they intend to
	use in order to validate that the buffer size that plan to allocate is
	sane.

	This commit makes _bfd_section_size_insane public, by renaming it to
	bfd_section_size_insane.

	I've updated the existing uses within bfd/, I don't believe this
	function is used outside of bfd/ currently.

	One place that I plan to make use of this function is in
	gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
	This change isn't included in this commit, but will come later if/when
	this has been merged into bfd.

	There should be no change in behaviour after this commit.

	bfd/

		* bfd-in2.h (bfd_section_size_insane): Add declaration.
		* compress.c (bfd_get_full_section_contents): Update for new name
		of _bfd_section_size_insane.
		(bfd_init_section_compress_status): Likewise.
		* dwarf2.c (read_section): Likewise.
		(_bfd_dwarf2_slurp_debug_info): Likewise.
		* libbfd.h (_bfd_section_size_insane): Remove declaration.
		* section.c (_bfd_section_size_insane): Rename to ...
		(bfd_section_size_insane): ... this.

	binutils/

		* readelf.c (uncompress_section_contents): Update comment to
		account for new name of _bfd_section_size_insane.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: move more completion setup into completer.c
	Move more setup of the readline global state relating to tab
	completion into completer.c out of top.c.

	Lots of the readline setup is done in init_main (top.c).  This commit
	moves those bits of initialisation that relate to completion, and
	which are only set the one time, into completer.c.  This does mean
	that readline initialisation is now done in multiple locations, some
	in init_main (top.c) and some in completer.c, but I think this is OK.
	The work done in init_main is the general readline setup.

	I think making static what can be made static, and having it all in
	one file, makes things easier to reason about.  So I'm OK with having
	this split initialisation.

	The only completion related thing which is still setup in top.c is
	rl_completion_display_matches_hook.  I've left this where it is for
	now as rl_completion_display_matches_hook is also updated in the tui
	code, and the display hook functions are not in completer.c anyway, so
	moving this initialisation to completer.c would not allow anything
	else to be made static.

	There should be no user visible changes after this commit.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/completion: make completion_find_completion_word static
	I noticed that completion_find_completion_word is only used within
	completer.c, so lets make it static.

	There should be no user visible changes after this commit.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove special case completion word handling for filenames
	This commit removes some code which is special casing the filename
	completion logic.  The code in question relates to finding the
	beginning of the completion word and was first introduced, or modified
	into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001).

	The code being removed moved the start of the completion word backward
	until a character in gdb_completer_file_name_break_characters was
	found, or until we reached the end of the actual command.

	However, I doubt that this is needed any more.  The filename completer
	has a corresponding filename_completer_handle_brkchars function which
	provides gdb_completer_file_name_break_characters as the word break
	characters to readline, and also sets rl_completer_quote_characters.
	As such, I would expect readline to be able to correctly find the
	start of the completion word.

	There is one change which I've needed to make as a consequence of
	removing the above code, and I think this is a bug fix.

	In complete_line_internal_normal_command we initialised temporary
	variable P to the CMD_ARGS; this is the complete text after the
	command name.  Meanwhile, complete_line_internal_normal_command also
	accepts an argument WORD, which is the completion word that readline
	found for us.

	In the code I removed P was updated, it was first set to WORD, and
	then moved backwards to the "new" start of the completion word.

	But notice, the default for P is the complete command argument text,
	and only if we are performing filename completion do we modify P to be
	the completion word.

	We then passed P through to the actual commands completion function.

	If we are doing anything other than filename completion then the value
	of P passed is the complete argument text.

	If we are doing filename completion then the value of P passed is the
	completion word.

	In filename_completer we get two arguments TEXT and WORD, the TEXT
	argument is the value of P which is the "new" completion word, while
	WORD is the completion word that readline calculated.

	After simplifying complete_line_internal_normal_command, and the
	temporary P is removed, we always pass the complete argument text into
	TEXT, while WORD remains the completion word that readline found.

	Previously in filename_completer we actually tried to generate
	completions based on TEXT, which worked fine as TEXT actually
	contained the completion word that we found in
	complete_line_internal_normal_command.  But I believe that we should
	be fine to use the completion word that readline found, so I have
	updated filename_completer to generate completions based on WORD.

	If I'm correct, then I don't expect to see any user visible changes
	after this commit.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove some dead code from completer.c
	In completer.c there is some code that is surrounded with '#if 0',
	this code:

	  #if 0
	    /* There is no way to do this just long enough to affect quote
	       inserting without also affecting the next completion.  This
	       should be fixed in readline.  FIXME.  */
	    /* Ensure that readline does the right thing
	       with respect to inserting quotes.  */
	    rl_completer_word_break_characters = "";
	  #endif

	This code, in some form, and always defined out, has been around since
	the original import of GDB.  Though the comment hints at what the
	problem might be, it's not really clear what the issue is.  And
	completion within GDB has moved on a long way since this code was
	written ... but not used.

	I'm proposing that we just remove this code.

	If/when a problem comes up then we can look at how to solve it.  Maybe
	this code would be the answer ... but also, I suspect, given all the
	changes ... maybe not.  I'm not sure carrying around this code for
	another 20+ years adds much value.

	There should be no user visible changes after this commit.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: allow double quotes for quoting filenames
	Currently GDB only supports using single quotes for quoting things,
	the reason for this, as explained in completer.c (next to the variable
	gdb_completer_expression_quote_characters) is that double quoted
	strings need to be treated differently by the C expression parser.

	But for filenames I don't believe this restriction holds.  The file
	names as passed to things like the 'file' command are not passing
	through the C expression parser, so it seems like we should be fine to
	allow double quotes for quoting in this case.

	And so, this commit extends GDB to allow double quotes for quoting
	filenames.  Maybe in future we might be able to allow double quote
	quoting in additional places, but this seems enough for now.

	The testing has been extended to cover double quotes in addition to
	the existing single quote testing.

	This change does a number of things:

	 1. Set rl_completer_quote_characters in filename_completer and
	 filename_completer_handle_brkchars, this overrides the default which
	 is set in complete_line_internal_1,

	 2. In advance_to_completion_word we now take a set of quote
	 characters as a parameter, the two callers
	 advance_to_expression_complete_word_point and
	 advance_to_filename_complete_word_point now pass in the required set
	 of quote characters,

	 3. In completion_find_completion_word we now use the currently active
	 set of quote characters, this means we'll use
	 gdb_completer_expression_quote_characters or
	 gdb_completer_file_name_quote_characters depending on what type of
	 things we are completing.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix bug where quote characters would become nullptr
	In gdb_completion_word_break_characters_throw, after calling
	complete_line_internal, if the completion function chose to use a
	custom word point then we set rl_completer_quote_characters to NULL.

	However, nowhere do we set rl_completer_quote_characters back to its
	default value, which is setup in init_main (top.c).

	An example of something that uses a custom word point for its
	completion is 'thread apply all ...'.

	An example of something that relies on rl_completer_quote_characters
	would be completion of a quoted filename that contains white space.

	Consider this shell and GDB session.  The <TAB> markers indicate where
	I've used tab to trigger completion:

	  $ mkdir /tmp/aaa\ bbb
	  $ touch /tmp/aaa\ bbb/xx\ 11
	  $ touch /tmp/aaa\ bbb/xx\ 22
	  $ gdb -q
	  (gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
	  xx 11  xx 22
	  (gdb) thread apply all hel<TAB>
	  (gdb) thread apply all help
	  (gdb) file '/tmp/aaa bbb/xx<TAB><TAB>

	First I create a directory structure which uses white space within
	file and directory names.  Then within GDB I use the 'file' command
	and use a single quote to quote the filename.  When I tab complete GDB
	correctly offers the two files within the directory '/tmp/aaa bbb/'.

	This works because rl_completer_quote_characters contains the single
	quote, and so readline knows that it is trying to complete the string
	that starts after the single quote: /tmp/aaa bbb/xx

	Next I invoke the completer for the 'thread apply all' command, to do
	this I type 'thread apply all hel' and hit tab, this expands to the
	one completion 'thread apply all help'.  We can run this command or
	not, it doesn't matter (there are no threads, so we'll get no output).

	Now I repeat the original 'file' completion.  This time though I don't
	get offered any completions.

	The reason is that the 'thread apply all' completer set
	rl_completer_quote_characters to nullptr.  Now, when readline tries to
	figure out the word to complete it doesn't see the single quote as the
	start of a quoted word, so instead readline falls back to the word
	break characters, and in this case spots the white space.  As a result
	readline tries to complete the string 'bbb/xx' which obviously doesn't
	have any completions.

	By setting rl_completer_quote_characters each time completion is
	invoked this problem is resolved and the second 'file' command
	completes as expected.

	I've extended gdb.base/filename-completion.exp to also test with
	quoted filenames, and added a 'thread apply all' completion at the
	start to expose this bug.

	As setting of rl_completer_quote_characters is now all done in the
	completer.c file the function get_gdb_completer_quote_characters()
	could be made static.  However, as this function is only used one time
	to initialise rl_completer_quote_characters, I've instead just deleted
	get_gdb_completer_quote_characters() and used
	gdb_completer_quote_characters directly.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove skip_quoted and skip_quoted_chars
	The function skip_quoted_chars (completer.c) is only used by
	skip_quoted (also completer.c), so could be made static.  The function
	skip_quoted just calls directly to skip_quoted_chars but fills in some
	default arguments.

	The function skip_quoted is only used by the Pascal expression parser,
	and is only used in one place.

	The skip_quoted_chars function skips a single string; it either looks
	for a string between matching quotes, or for a string up to a word
	break character.

	However, given how the Pascal expression parser calls this function,
	we know that the first character will always be a single quote, in
	which case skip_quoted_chars will looks for a string between matching
	single quotes.

	The skip_quoted_chars doesn't do any escaped character handling, it
	will just stop at the next single quote character.

	In this commit I propose to remove skip_quoted and skip_quoted_chars,
	and replace these with a smaller function pascal_skip_string  which
	I've placed in p-exp.y.  This new function only skips a string between
	matching single quotes, which is exactly the use case that we need.

	The benefit of this change is to remove (some) code duplication.  It
	feels like skip_quoted is similar in some ways to
	extract_string_maybe_quoted, however, there are some differences;
	skip_quoted uses the quotes and word break characters from the
	completion engine which extract_string_maybe_quoted does not.

	However, I'm currently working on improving filename completion, one
	part of this is that I'm looking at allowing filenames to be quoted
	with single or double quotes, while the default string quoting in
	GDB (for expressions) can only use single quotes.  If I do end up
	allowing single and double quotes in some cases, but we retain the
	single quotes only for expressions then skip_quoted starts to become a
	problem, should it accept both quote types, or only one?

	But given how skip_quoted is used, I can avoid worrying about this by
	simply removing skip_quoted.

	The Pascal tests do still pass.  The code that called skip_quoted is
	called at least once in the Pascal tests (adding an abort() call
	causes gdb.pascal/types.exp to fail), but I doubt the testing is
	extensive.  Not sure how widely used GDB for Pascal actually is
	though.

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: rename unwindonsignal to unwind-on-signal
	We now have unwind-on-timeout and unwind-on-terminating-exception, and
	then the odd one out unwindonsignal.

	I'm not a great fan of these squashed together command names, so in
	this commit I propose renaming this to unwind-on-signal.

	Obviously I've added the hidden alias unwindonsignal so any existing
	GDB scripts will keep working.

	There's one test that I've extended to test the alias works, but in
	most of the other test scripts I've changed over to use the new name.

	The docs are updated to reference the new name.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Keith Seitz <keiths@redhat.com>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: introduce unwind-on-timeout setting
	Now that inferior function calls can timeout (see the recent
	introduction of direct-call-timeout and indirect-call-timeout), this
	commit adds a new setting unwind-on-timeout.

	This new setting is just like the existing unwindonsignal and
	unwind-on-terminating-exception, but the new setting will cause GDB to
	unwind the stack if an inferior function call times out.

	The existing inferior function call timeout tests have been updated to
	cover the new setting.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Keith Seitz <keiths@redhat.com>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb: add timeouts for inferior function calls
	In the previous commits I have been working on improving inferior
	function call support.  One thing that worries me about using inferior
	function calls from a conditional breakpoint is: what happens if the
	inferior function call fails?

	If the failure is obvious, e.g. the thread performing the call
	crashes, or hits a breakpoint, then this case is already well handled,
	and the error is reported to the user.

	But what if the thread performing the inferior call just deadlocks?
	If the user made the call from a 'print' or 'call' command, then the
	user might have some expectation of when the function call should
	complete, and, when this time limit is exceeded, the user
	will (hopefully) interrupt GDB and regain control of the debug
	session.

	But, when the inferior function call is from a breakpoint condition it
	is much harder to understand that GDB is deadlocked within an inferior
	call.  Maybe the breakpoint hasn't been hit yet?  Or maybe the
	condition was always false?  Or maybe GDB is deadlocked in an inferior
	call?  The only way to know for sure is for the user to periodically
	interrupt the inferior, check on the state of all the threads, and
	then continue.

	Additionally, the focus of the previous commit was inferior function
	calls, from a conditional breakpoint, in a multi-threaded inferior.
	This opens up a whole new set of potential failure conditions.  For
	example, what if the function called relies on interaction with some
	other thread, and the other thread crashes?  Or hits a breakpoint?
	Given how inferior function calls work (in a synchronous manner), a
	stop event in some other thread is going to be ignored while the
	inferior function call is being executed as part of a breakpoint
	condition, and this means that GDB could get stuck waiting for the
	original condition thread, which will now never complete.

	In this commit I propose a solution to this problem.  A timeout.  For
	targets that support async-mode we can install an event-loop timer
	before starting the inferior function call.  When the timer expires we
	will stop the thread performing the inferior function call.  With this
	mechanism in place a user can be sure that any inferior call they make
	will either complete, or timeout eventually.

	Adding a timer like this is obviously a change in behaviour for the
	more common 'call' and 'print' uses of inferior function calls, so, in
	this patch, I propose having two different timers.  One I call the
	'direct-call-timeout', which is used for 'call' and 'print' commands.
	This timeout is by default set to unlimited, which, not surprisingly,
	means there is no timeout in place.

	A second timer, which I've called 'indirect-call-timeout', is used for
	inferior function calls from breakpoint conditions.  This timeout has
	a default value of 30 seconds.  This is a reasonably long time to
	wait, and hopefully should be enough in most cases to allow the
	inferior call to complete.  An inferior call that takes more than 30
	seconds, which is installed on a breakpoint condition is really going
	to slow down the debug session, so hopefully this is not a common use
	case.

	The user is, of course, free to reduce, or increase the timeout value,
	and can always use Ctrl-c to interrupt an inferior function call, but
	this timeout will ensure that GDB will stop at some point.

	The new commands added by this commit are:

	  set direct-call-timeout SECONDS
	  show direct-call-timeout
	  set indirect-call-timeout SECONDS
	  show indirect-call-timeout

	These new timeouts do depend on async-mode, so, if async-mode is
	disabled (maint set target-async off), or not supported (e.g. target
	sim), then the timeout is treated as unlimited (that is, no timeout is
	set).

	For targets that "fake" non-async mode, e.g. Linux native, where
	non-async mode is really just async mode, but then we park the target
	in a sissuspend, we could easily fix things so that the timeouts still
	work, however, for targets that really are not async aware, like the
	simulator, fixing things so that timeouts work correctly would be a
	much bigger task - that effort would be better spent just making the
	target async-aware.  And so, I'm happy for now that this feature will
	only work on async targets.

	The two new show commands will display slightly different text if the
	current target is a non-async target, which should allow users to
	understand what's going on.

	There's a somewhat random test adjustment needed in gdb.base/help.exp,
	the test uses a regexp with the apropos command, and expects to find a
	single result.  Turns out the new settings I added also matched the
	regexp, which broke the test.  I've updated the regexp a little to
	exclude my new settings.

	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Keith Seitz <keiths@redhat.com>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>
	    Natalia Saiapova  <natalia.saiapova@intel.com>
	    Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: fix b/p conditions with infcalls in multi-threaded inferiors
	This commit fixes bug PR 28942, that is, creating a conditional
	breakpoint in a multi-threaded inferior, where the breakpoint
	condition includes an inferior function call.

	Currently, when a user tries to create such a breakpoint, then GDB
	will fail with:

	  (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ())
	  Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61.
	  (gdb) continue
	  Continuing.
	  [New Thread 0x7ffff7c5d700 (LWP 2460150)]
	  [New Thread 0x7ffff745c700 (LWP 2460151)]
	  [New Thread 0x7ffff6c5b700 (LWP 2460152)]
	  [New Thread 0x7ffff645a700 (LWP 2460153)]
	  [New Thread 0x7ffff5c59700 (LWP 2460154)]
	  Error in testing breakpoint condition:
	  Couldn't get registers: No such process.
	  An error occurred while in a function called from GDB.
	  Evaluation of the expression containing the function
	  (return_true) will be abandoned.
	  When the function is done executing, GDB will silently stop.
	  Selected thread is running.
	  (gdb)

	Or, in some cases, like this:

	  (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1))
	  Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56.
	  (gdb) continue
	  Continuing.
	  [New Thread 0x7ffff7c5d700 (LWP 2461106)]
	  [New Thread 0x7ffff745c700 (LWP 2461107)]
	  ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
	  A problem internal to GDB has been detected,
	  further debugging may prove unreliable.

	The precise error depends on the exact thread state; so there's race
	conditions depending on which threads have fully started, and which
	have not.  But the underlying problem is always the same; when GDB
	tries to execute the inferior function call from within the breakpoint
	condition, GDB will, incorrectly, try to resume threads that are
	already running - GDB doesn't realise that some threads might already
	be running.

	The solution proposed in this patch requires an additional member
	variable thread_info::in_cond_eval.  This flag is set to true (in
	breakpoint.c) when GDB is evaluating a breakpoint condition.

	In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is
	true, then GDB will only try to resume the current thread, that is,
	the thread for which the breakpoint condition is being evaluated.
	This solves the problem of GDB trying to resume threads that are
	already running.

	The next problem is that inferior function calls are assumed to be
	synchronous, that is, GDB doesn't expect to start an inferior function
	call in thread #1, then receive a stop from thread #2 for some other,
	unrelated reason.  To prevent GDB responding to an event from another
	thread, we update fetch_inferior_event and do_target_wait in infrun.c,
	so that, when an inferior function call (on behalf of a breakpoint
	condition) is in progress, we only wait for events from the current
	thread (the one evaluating the condition).

	In do_target_wait I had to change the inferior_matches lambda
	function, which is used to select which inferior to wait on.
	Previously the logic was this:

	   auto inferior_matches = [&wait_ptid] (inferior *inf)
	     {
	       return (inf->process_target () != nullptr
	               && ptid_t (inf->pid).matches (wait_ptid));
	     };

	This compares the pid of the inferior against the complete ptid we
	want to wait on.  Before this commit wait_ptid was only ever
	minus_one_ptid (which is special, and means any process), and so every
	inferior would match.

	After this commit though wait_ptid might represent a specific thread
	in a specific inferior.  If we compare the pid of the inferior to a
	specific ptid then these will not match.  The fix is to compare
	against the pid extracted from the wait_ptid, not against the complete
	wait_ptid itself.

	In fetch_inferior_event, after receiving the event, we only want to
	stop all the other threads, and call inferior_event_handler with
	INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint.
	If we are, then all the other threads should be left doing whatever
	they were before.  The inferior_event_handler call will be performed
	once the breakpoint condition has finished being evaluated, and GDB
	decides to stop or not.

	The final problem that needs solving relates to GDB's commit-resume
	mechanism, which allows GDB to collect resume requests into a single
	packet in order to reduce traffic to a remote target.

	The problem is that the commit-resume mechanism will not send any
	resume requests for an inferior if there are already events pending on
	the GDB side.

	Imagine an inferior with two threads.  Both threads hit a breakpoint,
	maybe the same conditional breakpoint.  At this point there are two
	pending events, one for each thread.

	GDB selects one of the events and spots that this is a conditional
	breakpoint, GDB evaluates the condition.

	The condition includes an inferior function call, so GDB sets up for
	the call and resumes the one thread, the resume request is added to
	the commit-resume queue.

	When the commit-resume queue is committed GDB sees that there is a
	pending event from another thread, and so doesn't send any resume
	requests to the actual target, GDB is assuming that when we wait we
	will select the event from the other thread.

	However, as this is an inferior function call for a condition
	evaluation, we will not select the event from the other thread, we
	only care about events from the thread that is evaluating the
	condition - and the resume for this thread was never sent to the
	target.

	And so, GDB hangs, waiting for an event from a thread that was never
	fully resumed.

	To fix this issue I have added the concept of "forcing" the
	commit-resume queue.  When enabling commit resume, if the force flag
	is true, then any resumes will be committed to the target, even if
	there are other threads with pending events.

	A note on authorship: this patch was based on some work done by
	Natalia Saiapova and Tankut Baris Aktemur from Intel[1].  I have made
	some changes to their work in this version.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942

	[1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html

	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Keith Seitz <keiths@redhat.com>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	Revert "gdb: remove unnecessary parameter wait_ptid from do_target_wait"
	This reverts commit ac0d67ed1dcf470bad6a3bc4800c2ddc9bedecca.

	There was nothing wrong with the commit which I'm reverting here, but
	it removed some functionality that will be needed for a later commit;
	that is, the ability for GDB to ask for events from a specific ptid_t
	via the do_target_wait function.

	In a follow up commit, this functionality will be used to implement
	inferior function calls in multi-threaded inferiors.

	This is not a straight revert of the above commit.  Reverting the
	above commit replaces a 'nullptr' with 'NULL', I've gone in and
	changed that, preserving the 'nullptr'.

	Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Keith Seitz <keiths@redhat.com>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share x86/linux tdesc caching
	This commit builds on the previous series of commits to share the
	target description caching code between GDB and gdbserver for
	x86/Linux targets.

	The objective of this commit is to move the four functions (2 each of)
	i386_linux_read_description and amd64_linux_read_description into
	gdb/nat/x86-linux-tdesc.c and combine them so we have just a single
	copy of each.  Then both GDB and gdbserver will link against these
	shared functions.

	It is worth reading the description of the previous commit to see why
	this merging is not as simple as it seems: on the gdbserver side we
	actually have two users of these functions, gdbserver itself, and the
	in process agent (IPA).

	However, the previous commit streamlined the gdbserver code, and so
	now it is simple to move the two functions along with all their
	support functions from the gdbserver directory into the gdb/nat/
	directory, and then GDB is fine to call these functions.

	One small curiosity with this patch is the function
	x86_linux_post_init_tdesc.  On the gdbserver side the two functions
	amd64_linux_read_description and i386_linux_read_description have some
	functionality that is not present on the GDB side, that is some
	additional configuration that is performed as each target description
	is created to setup the expedited registers.

	To support this I've added the function x86_linux_post_init_tdesc.
	This function is called from the two *_linux_read_description
	functions, but is implemented separately for GDB and gdbserver.

	This does mean adding back some non-shared code when this whole series
	has been about sharing code, but now the only non-shared bit is the
	single line that is actually different between GDB and gdbserver, all
	the rest, which is identical, is now shared.

	I did need to add a new rule to the gdbserver Makefile, this is to
	allow the nat/x86-linux-tdesc.c file to be compiled for the IPA.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: update target description creation for x86/linux
	This commit is part of a series which aims to share more of the target
	description creation between GDB and gdbserver for x86/Linux.

	After some refactoring, the previous commit actually started to share
	some code, we added the shared x86_linux_tdesc_for_tid function into
	nat/x86-linux-tdesc.c.  However, this function still relies on
	amd64_linux_read_description and i386_linux_read_description which are
	implemented separately for both gdbserver and GDB.  Given that at
	their core, all these functions to is:

	  1. take an xcr0 value as input,
	  2. mask out some feature bits,
	  3. look for a cached pre-generated target description and return it
	     if found,
	  4. if no cached target description is found then call either
	     amd64_create_target_description or
	     i386_create_target_description to create a new target
	     description, which is then added to the cache.  Return the newly
	     created target description.

	The inner functions amd64_create_target_description and
	i386_create_target_description are already shared between GDB and
	gdbserver (in the gdb/arch/ directory), so the only thing that
	the *_read_description functions really do is add the caching layer,
	and it feels like this really could be shared.

	However, we have a small problem.

	On the GDB side we create target descriptions using a different set of
	cpu features than on the gdbserver side!  This means that for the
	exact same target, we might get a different target description when
	using native GDB vs using gdbserver.  This surely feels like a
	mistake, I would expect to get the same target description on each.

	The table below shows the number of possible different target
	descriptions that we can create on the GDB side vs on the gdbserver
	side for each target type:

	        | GDB | gdbserver
	  ------|-----|----------
	  i386  | 64  | 7
	  amd64 | 32  | 7
	  x32   | 16  | 7

	So in theory, all I want to do is move the GDB version
	of *_read_description into the nat/ directory and have gdbserver use
	that, then both GDB and gdbserver would be able to create any of the
	possible target descriptions.

	Unfortunately it's a little more complex than that due to the in
	process agent (IPA).

	When the IPA is in use, gdbserver sends a target description index to
	the IPA, and the IPA uses this to find the correct target description
	to use.

	** START OF AN ASIDE **

	Back in the day I suspect this approach made perfect sense.  However
	since this commit:

	  commit a8806230241d201f808d856eaae4d44088117b0c
	  Date:   Thu Dec 7 17:07:01 2017 +0000

	      Initialize target description early in IPA

	I think passing the index is now more trouble than its worth.

	We used to pass the index, and then use that index to lookup which
	target description to instantiate and use.  However, the above commit
	fixed an issue where we can't call malloc() within (certain parts of)
	the IPA (apparently), so instead we now pre-compute _every_ possible
	target description within the IPA.  The index is now only used to
	lookup which of the (many) pre-computed target descriptions to use.

	It would (I think) have been easier all around if the IPA just
	self-inspected, figured out its own xcr0 value, and used that to
	create the one target description that is required.  So long as the
	xcr0 to target description code is shared (at compile time) with
	gdbserver, then we can be sure that the IPA will derive the same
	target description as gdbserver, and we would avoid all this index
	passing business, which has made this commit so very, very painful.

	** END OF AN ASIDE **

	Currently then for x86/linux, gdbserver sends a number between 0 and 7
	to the IPA, and the IPA uses this to create a target description.

	However, I am proposing that gdbserver should now create one of (up
	to) 64 different target descriptions for i386, so this 0 to 7 index
	isn't going to be good enough any more (amd64 and x32 have slightly
	fewer possible target descriptions, but still more than 8, so the
	problem is the same).

	For a while I wondered if I was going to have to try and find some
	backward compatible solution for this mess.  But after seeing how
	lightly the IPA is actually documented, I wonder if it is not the case
	that there is a tight coupling between a version of gdbserver and a
	version of the IPA?  At least I'm hoping so.

	In this commit I have thrown out the old IPA target description index
	numbering scheme, and switched to a completely new numbering scheme.
	Instead of the index that is passed being arbitrary, the index is
	instead calculated from the set of cpu features that are present on
	the target.  Within the IPA we can then reverse this logic to recreate
	the xcr0 value based on the index, and from the xcr0 value we can
	create the correct target description.

	With the gdbserver to IPA numbering scheme issue resolved I have then
	update the gdbserver versions of amd64_linux_read_description and
	i386_linux_read_description so that they create target descriptions
	using the same set of cpu features as GDB itself.

	After this gdbserver should now always come up with the same target
	description as GDB does on any x86/Linux target.

	This commit does not introduce any new code sharing between GDB and
	gdbserver as previous commits in this series does.  Instead this
	commit is all about bringing GDB and gdbserver into alignment
	functionally so that the next commit can merge the GDB and gdbserver
	versions of these functions.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/arch: assert that X86_XSTATE_MPX is not set for x32
	While trying to merge this commit:

	  commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a
	  Date:   Wed Mar 20 04:13:18 2024 -0700

	      gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32

	With this patch series of mine:

	  https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com

	I worried that there could be other paths that could result in an xcr0
	value that has X86_XSTATE_MPX set in x32 mode.  As everyone eventually
	calls amd64_create_target_description to build their target
	description, I figured we could assert in here that if X86_XSTATE_MPX
	is set then we should not be an x32 target, this should uncover any
	other bugs in this area.

	I'm not currently able to build/run any x32 binaries, so I have no way
	to test this.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share some code relating to target description creation
	This commit is part of a series to share more of the x86 target
	description creation code between GDB and gdbserver.

	Unlike previous commits which were mostly refactoring, this commit is
	the first that makes a real change, though that change should mostly
	be for gdbserver; I've largely adopted the "GDB" way of doing things
	for gdbserver, and this fixes a real gdbserver bug.

	On a x86-64 Linux target, running the test:

	  gdb.server/connect-with-no-symbol-file.exp

	results in two core files being created.  Both of these core files are
	from the inferior process, created after gdbserver has detached.

	In this test a gdbserver process is started and then, after gdbserver
	has started, but before GDB attaches, we either delete the inferior
	executable, or change its permissions so it can't be read.  Only after
	doing this do we attempt to connect with GDB.

	As GDB connects to gdbserver, gdbserver attempts to figure out the
	target description so that it can send the description to GDB, this
	involves a call to x86_linux_read_description.

	In x86_linux_read_description one of the first things we do is try to
	figure out if the process is 32-bit or 64-bit.  To do this we look up
	the executable via the thread-id, and then attempt to read the
	architecture size from the executable.  This isn't going to work if
	the executable has been deleted, or is no longer readable.

	And so, as we can't read the executable, we default to an i386 target
	and use an i386 target description.

	A consequence of using an i386 target description is that addresses
	are assumed to be 32-bits.  Here's an example session that shows the
	problems this causes.  This is run on an x86-64 machine, and the test
	binary (xx.x) is a standard 64-bit x86-64 binary:

	  shell_1$ gdbserver --once localhost :54321 /tmp/xx.x

	  shell_2$ gdb -q
	  (gdb) set sysroot
	  (gdb) shell chmod 000 /tmp/xx.x
	  (gdb) target remote :54321
	  Remote debugging using :54321
	  warning: /tmp/xx.x: Permission denied.
	  0xf7fd3110 in ?? ()
	  (gdb) show architecture
	  The target architecture is set to "auto" (currently "i386").
	  (gdb) p/x $pc
	  $1 = 0xf7fd3110
	  (gdb) info proc mappings
	  process 2412639
	  Mapped address spaces:

	  	Start Addr   End Addr       Size     Offset  Perms   objfile
	  	  0x400000   0x401000     0x1000        0x0  r--p   /tmp/xx.x
	  	  0x401000   0x402000     0x1000     0x1000  r-xp   /tmp/xx.x
	  	  0x402000   0x403000     0x1000     0x2000  r--p   /tmp/xx.x
	  	  0x403000   0x405000     0x2000     0x2000  rw-p   /tmp/xx.x
	  	0xf7fcb000 0xf7fcf000     0x4000        0x0  r--p   [vvar]
	  	0xf7fcf000 0xf7fd1000     0x2000        0x0  r-xp   [vdso]
	  	0xf7fd1000 0xf7fd3000     0x2000        0x0  r--p   /usr/lib64/ld-2.30.so
	  	0xf7fd3000 0xf7ff3000    0x20000     0x2000  r-xp   /usr/lib64/ld-2.30.so
	  	0xf7ff3000 0xf7ffb000     0x8000    0x22000  r--p   /usr/lib64/ld-2.30.so
	  	0xf7ffc000 0xf7ffe000     0x2000    0x2a000  rw-p   /usr/lib64/ld-2.30.so
	  	0xf7ffe000 0xf7fff000     0x1000        0x0  rw-p
	  	0xfffda000 0xfffff000    0x25000        0x0  rw-p   [stack]
	  	0xff600000 0xff601000     0x1000        0x0  r-xp   [vsyscall]
	  (gdb) info inferiors
	    Num  Description       Connection           Executable
	  * 1    process 2412639   1 (remote :54321)
	  (gdb) shell cat /proc/2412639/maps
	  00400000-00401000 r--p 00000000 fd:03 45907133           /tmp/xx.x
	  00401000-00402000 r-xp 00001000 fd:03 45907133           /tmp/xx.x
	  00402000-00403000 r--p 00002000 fd:03 45907133           /tmp/xx.x
	  00403000-00405000 rw-p 00002000 fd:03 45907133           /tmp/xx.x
	  7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0          [vvar]
	  7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0          [vdso]
	  7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904     /usr/lib64/ld-2.30.so
	  7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
	  7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0          [stack]
	  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
	  (gdb)

	Notice the difference between the mappings reported via GDB and those
	reported directly from the kernel via /proc/PID/maps, the addresses of
	every mapping is clamped to 32-bits for GDB, while the kernel reports
	real 64-bit addresses.

	Notice also that the $pc value is a 32-bit value.  It appears to be
	within one of the mappings reported by GDB, but is outside any of the
	mappings reported from the kernel.

	And this is where the problem arises.  When gdbserver detaches from
	the inferior we pass the inferior the address from which it should
	resume.  Due to the 32/64 bit confusion we tell the inferior to resume
	from the 32-bit $pc value, which is not within any valid mapping, and
	so, as soon as the inferior resumes, it segfaults.

	If we look at how GDB (not gdbserver) figures out its target
	description then we see an interesting difference.  GDB doesn't try to
	read the executable.  Instead GDB uses ptrace to query the thread's
	state, and uses this to figure out the if the thread is 32 or 64 bit.

	If we update gdbserver to do it the "GDB" way then the above problem
	is resolved, gdbserver now sees the process as 64-bit, and when we
	detach from the inferior we give it the correct 64-bit address, and
	the inferior no longer segfaults.

	Now, I could just update the gdbserver code, but better, I think, to
	share one copy of the code between GDB and gdbserver in gdb/nat/.
	That is what this commit does.

	The cores of x86_linux_read_description from gdbserver and
	x86_linux_nat_target::read_description from GDB are moved into a new
	file gdb/nat/x86-linux-tdesc.c and combined into a single function
	x86_linux_tdesc_for_tid which is called from each location.

	This new function does things the GDB way, the only changes are to
	allow for the sharing; we now have a callback function to call the
	first time that the xcr0 state is read, this allows for GDB and
	gdbserver to perform their own initialisation as needed, and
	additionally, the new function takes a pointer for where to cache the
	xcr0 value, this isn't needed for this commit, but will be useful in a
	later commit where gdbserver will want to read this cached xcr0
	value.

	Another thing to note about this commit is how the functions
	i386_linux_read_description and amd64_linux_read_description are
	handled.  For now I've left these function as implemented separately
	in GDB and gdbserver.  I've moved the declarations of these functions
	into gdb/nat/x86-linux-tdesc.h, but the implementations are left as
	separate.

	A later commit in this series will make these functions shared too,
	but doing this is not trivial, so I've left that for a separate
	commit.  Merging the declarations as I've done here ensures that
	everyone implements the function to the same API, and once these
	functions are shared (in a later commit) we'll want a shared
	declaration anyway.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition
	Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
	gdbserver.

	This commit is part of a series that aims to share more of the x86
	target description creation code between GDB and gdbserver.  The
	I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target
	description creation, and I noticed that this constant is defined
	separately for GDB and gdbserver.

	This commit moves the definition into gdb/nat/x86-linux.h, which
	allows the #define to be shared.

	There should be no user visible changes after this commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdbserver/x86: move no-xml code earlier in x86_linux_read_description
	This commit is part of a series that aims to share more of the x86
	target description reading/generation code between GDB and gdbserver.

	There are a huge number of similarities between the code in
	gdbserver's x86_linux_read_description function and GDB's
	x86_linux_nat_target::read_description function, and it is this
	similarity that I plan, in a later commit, to share between GDB and
	gdbserver.

	However, one thing that is different in x86_linux_read_description is
	the code inside the '!use_xml' block.  This is the code that handles
	the case where gdbserver is not allowed to send an XML target
	description back to GDB.  In this case gdbserver uses some predefined,
	fixed, target descriptions.

	First, it's worth noting that I suspect this code is not tested any
	more.  I couldn't find anything in the testsuite that tries to disable
	XML target description support.  And the idea of having a single
	"fixed" target description really doesn't work well when we think
	about all the various x86 extensions that exist.  Part of me would
	like to rip out the no-xml support in gdbserver (at least for x86),
	and if a GDB connects that doesn't support XML target descriptions,
	gdbserver can just give an error and drop the connection.  GDB has
	supported XML target descriptions for 16 years now, I think it would
	be reasonable for our shipped gdbserver to drop support for the old
	way of doing things.

	Anyway.... this commit doesn't do that.

	What I did notice was that, over time, the '!use_xml' block appears to
	have "drifted" within the x86_linux_read_description function; it's
	now not the first check we do.  Instead we make some ptrace calls and
	return a target description generated based on the result of these
	ptrace calls.  Surely it only makes sense to generate variable target
	descriptions if we can send these back to GDB?

	So in this commit I propose to move the '!use_xml' block earlier in
	the x86_linux_read_description function.

	The benefit of this is that this leaves the later half of
	x86_linux_read_description much more similar to the GDB function
	x86_linux_nat_target::read_description and sets us up for potentially
	sharing code between GDB and gdbserver in a later commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/x86: move reading of cs and ds state into gdb/nat directory
	This patch is part of a series that has the aim of making the code
	that, for x86, reads the target description for a native process
	shared between GDB and gdbserver.

	Within GDB part of this process involves reading the cs and ds state
	from the 'struct user_regs_struct' using a ptrace call.

	This isn't done by gdbserver, which is part of the motivation for this
	whole series; the approach gdbserver takes is inferior to the approach
	GDB takes.

	This commit moves the reading of cs and ds, which is used to figure
	out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat
	directory so that the code could be shared with gdbserver, but at this
	point I'm not actually using the code in gdbserver, that will come
	later.

	As such there should be no user visible changes after this commit, GDB
	continues to do things as it did before (reading cs/ds), while
	gdbserver continues to use its own approach (which doesn't require
	reading cs/ds).

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: convert have_ptrace_getregset to a tribool
	Convert the have_ptrace_getregset global within gdbserver to a
	tribool.  This brings the flag into alignment with the corresponding
	flag in GDB.

	The gdbserver have_ptrace_getregset variable is already used as a
	tribool, it just doesn't have the tribool type.

	In a future commit I plan to share more code between GDB and
	gdbserver, and having this variable be the same type in both code
	bases will make the sharing much easier.

	There should be no user visible changes after this commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12
	With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc
	12, I get:
	...
	(gdb) set debug symtab-create 1^M
	(gdb) print *the_local_var^M
	  ...
	$1 = (n => 2)^M
	(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
	...

	The problem is that this fails:
	...
	    -re -wrap ".* = \\\(n => $decimal\\\)" {
		if {$found_pck + $found_pck2 == 1} {
		    pass $gdb_test_name
		} else {
		    fail $gdb_test_name
		}
	...
	because $found_pck == 0 and $found_pck2 == 0.

	Indeed, with gcc 13 we have:
	...
	$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
	b~foo.adb
	b~foo.adb
	b~foo.adb
	b~foo.ads
	pck2.adb
	pck2.adb
	pck2.ads
	pck2.adb
	pck2.ads
	...
	and with gcc 12:
	...
	$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
	b~foo.adb
	b~foo.adb
	b~foo.adb
	b~foo.ads
	...

	Fix this by checking for "$found_pck + $found_pck2 <= 1" instead.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31514
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514

2024-03-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix tdlabel_re references
	Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs
	from info threads") introduces a new global variable tdlabel_re, but fails to
	indicate it's global when used in procs in four test-cases.

	Fix this by adding "global tdlabel_re".

	Tested on aarch64-linux.

2024-03-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-23  John Baldwin  <jhb@FreeBSD.org>

	gdb tests: Allow for "LWP" or "process" in thread IDs from info threads
	Several tests assume that the first word after a thread ID in 'info
	threads' output is "Thread".  However, several targets use "LWP"
	instead such as the FreeBSD and NetBSD native targets.  The Linux
	native target also uses "LWP" if libthread_db is not being used.
	Targets that do not support threads use "process" as the first word
	via normal_pid_to_str.

	Add a tdlabel_re global variable as a regular-expression for a thread
	label in `info threads' that matches either "process", "Thread", or
	"LWP".

	Some other tests in the tree don't require a specific word, and
	some targets may use other first words (e.g. OpenBSD uses "thread"
	and Ravenscar threads use "Ravenscar Thread").

2024-03-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-22  Pedro Alves  <pedro@palves.net>

	windows-nat: Use gdb_realpath
	Use gdb_realpath instead of realpath in windows-nat.c:windows_make_so,
	so that we don't have to manually call free.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff

2024-03-22  Pedro Alves  <pedro@palves.net>

	windows-nat: Remove SO_NAME_MAX_PATH_SIZE limit
	There is no need to limit shared library path sizes to
	SO_NAME_MAX_PATH_SIZE nowadays.  windows_solib::name and
	windows_solib::original_name are std::strings nowadays, and so are
	solib::so_name and solib::so_original_name in the core solib code.

	This commit reworks the code to remove that limit.  This also fixes a
	leak where we were not releasing 'rname' in the realpath branch if the
	'rname' string was larger than SO_NAME_MAX_PATH_SIZE.

	Note: I tested the cygwin_conv_path with a manual hack to force that
	path, and then stepping through the code.  You only get to that path
	if Windows doesn't report an absolute path for ntdll.dll, and on my
	machine (running Windows 10), it always does.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5

2024-03-22  Pedro Alves  <pedro@palves.net>

	Simplify windows-nat.c:windows_make_so #ifdefery
	There are two separate #ifndef __CYGWIN__/#else/#endif sections in the
	windows_make_so function with 3 lines of shared code separating them.
	I find this makes the code harder to understand than necessary.
	AFAICS, there is no reason those three shared lines need to be after
	the first #ifdef block.  There is no early return, nor are 'load_addr'
	nor 'name' modified.

	This commit moves that shared code to the top of the function, and
	then combines the two #ifndef sections.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc

2024-03-22  Pedro Alves  <pedro@palves.net>

	Remove SO_NAME_MAX_PATH_SIZE limit from core solib code
	solib_map_sections errors out if the library file name is longer than
	SO_NAME_MAX_PATH_SIZE.

	solib::so_name and solib::so_original_name used to be arrays of
	SO_NAME_MAX_PATH_SIZE size, so that check made sense then.

	However, since commit 98107b0b17ac ("gdb: make
	so_list::{so_original_name,so_name} std::strings") those fields are of
	std::string type, so there's really no need for the limit.

	This commit simply removes the length limit check.

	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6

2024-03-22  Tom Tromey  <tromey@adacore.com>

	Use std::string for disassembler options
	I noticed that the disassembler_options code uses manual memory
	management.  It seemed simpler to replace this with std::string.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-22  Tom Tromey  <tromey@adacore.com>

	Remove some unnecessary casts
	I found a few unnecessary casts when calling
	set_gdbarch_disassembler_options_implicit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-22  Tom Tromey  <tromey@adacore.com>

	Constify get_disassembler_options
	This changes get_disassembler_options to return a const char *.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-22  Tom Tromey  <tom@tromey.com>

	Revert "Pass GUILE down to subdirectories"
	This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.

	This patch caused problems for some users when building gdb, because
	it would cause 'guild' to be invoked with the wrong versin of guile.
	On the whole it seems simpler to just back this out.

	I'm checking this in to the binutils-gdb repository in the interest of
	fixing the build for Andrew.  No one has responded to the identical
	patch sent to gcc-patches, but I will ping it there.

		* Makefile.in: Rebuild.
		* Makefile.tpl (BASE_EXPORTS): Remove GUILE.
		(GUILE): Remove.
		* Makefile.def (flags_to_pass): Remove GUILE.

2024-03-22  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: LoongArch: Clean up loongarch_iterate_over_regset_sections()
	Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET
	to replace the related code in the first cb(), and also make use of
	tabs and spaces in indentation to force the proper alignment of code,
	then remove the empty line at the end of the function.

2024-03-22  Pedro Alves  <pedro@palves.net>

	Teach GDB to generate sparse core files (PR corefiles/31494)
	This commit teaches GDB's gcore command to generate sparse core files
	(if supported by the filesystem).

	To create a sparse file, all you have to do is skip writing zeros to
	the file, instead lseek'ing-ahead over them.

	The sparse logic is applied when writing the memory sections, as
	that's where the bulk of the data and the zeros are.

	The commit also tweaks gdb.base/bigcore.exp to make it exercise
	gdb-generated cores in addition to kernel-generated cores.  We
	couldn't do that before, because GDB's gcore on that test's program
	would generate a multi-GB non-sparse core (16GB on my system).

	After this commit, gdb.base/bigcore.exp generates, when testing with
	GDB's gcore, a much smaller core file, roughly in line with what the
	kernel produces:

	 real sizes:

	 $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
	 2.2M    testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
	 2.0M    testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel

	 apparent sizes:

	 $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
	 16G     testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
	 16G     testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel

	Time to generate the core also goes down significantly.  On my machine, I get:

	  when writing to an SSD, from 21.0s, down to 8.0s
	  when writing to an HDD, from 31.0s, down to 8.5s

	The changes to gdb.base/bigcore.exp are smaller than they look at
	first sight.  It's basically mostly refactoring -- moving most of the
	code to a new procedure which takes as argument who should dump the
	core, and then calling the procedure twice.  I purposely did not
	modernize any of the refactored code in this patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494
	Reviewed-By: Lancelot Six <lancelot.six@amd.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1

2024-03-22  Jan Beulich  <jbeulich@suse.com>

	x86: fix Solaris testsuite failures
	For one 0afc614c9938 ("x86: Warn .insn instruction with length > 15
	bytes") introduced a .insn use involving a slash; such tests need to
	have --divide passed to gas.

	And then 5bc71c2a6b8e ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke
	BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by
	adding respective code in a section guarded by
	generate_relax_relocations (the case of that not being required there
	was limited to 32-bit object files). Re-arrange that block of code to
	check generate_relax_relocations later.

2024-03-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-21  H.J. Lu  <hjl.tools@gmail.com>

	gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32
	Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits
	on x32.

		PR server/31511
		* linux-x86-low.cc (x86_linux_read_description): Clear
		X86_XSTATE_MPX bits in xcr0 on x32.
	Reviewed-by: Felix Willgerodt <felix.willgerodt@intel.com>

2024-03-21  Tom Tromey  <tromey@adacore.com>

	Implement Ada 2022 delta aggregates
	Ada 2022 includes a "delta aggregates" feature that can sometimes
	simplify aggregate creation.  This patch implements this feature for
	GDB.

2024-03-21  Tom Tromey  <tromey@adacore.com>

	Require trivial destructor in allocate_on_obstack
	This patch makes allocate_on_obstack a little bit safer, by enforcing
	the rule that objects allocated on an obstack must have a trivial
	destructor.

	The static assert is done in a method -- doing it inside the class
	itself won't work because the class is incomplete at that point.

2024-03-21  Tom Tromey  <tromey@adacore.com>

	Don't use virtual destructor in addrmap
	The addrmap polymorphism is sort of "phony" in that there isn't really
	code in the tree that can be presented with either type.  I haven't
	tried to fix this (though perhaps I may); but meanwhile it's handy for
	the next patch if addrmap_fixed has a trivial destructor.  This patch
	achieves this by making the addrmap destructor non-virtual, and also
	making it protected so that objects of any of these types cannot be
	destroyed when only the base class is known.

	Use addrmap_fixed in a few spots
	There are a few spots in the tree that use 'addrmap' where only an
	addrmap_fixed will ever really be seen.  This patch changes this code
	to use the more specific type.

2024-03-21  Orgad Shaneh  <orgads@gmail.com>

	sim/erc32: Rename EVENT_MAX -> MAX_EVENTS
	EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when
	building on Windows, the value is overridden and compilation fails
	because the array size of evbuf is too large.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-21  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Add some tips for LoongArch xml files
	In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in),
	it needs special handling when generating xml file. This should at
	least be mentioned in the file comment rather than git log to help
	the next person who regenerates this file understand what needs to
	be done, suggested by Pedro Alves, thank you.

	At the beginning, I only added the tips in loongarch-linux.xml.in,
	after executing the command "make" to generate loongarch-linux.xml
	from loongarch-linux.xml.in, it generates the same tips in the file
	loongarch-linux.xml automatically, so update loongarch-linux.xml.in
	and loongarch-linux.xml together.

	Approved-by: Pedro Alves <pedro@palves.net>

2024-03-21  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Silence warning about core file of lsx and lasx
	In loongarch_iterate_over_regset_sections(), the second and third arguments
	of the iterate_over_regset_sections_cb callback function should be the regset
	size which is regsize * regnum. Otherwise when execute:

	make check-gdb TESTS="gdb.base/corefile.exp"

	there exists the following failed log:

	  (gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
	  [New LWP 531099]
	  warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
	  warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
	  Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
	  Program terminated with signal SIGABRT, Aborted.
	  warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
	  warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
	  #0  0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6
	  (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free

2024-03-21  Nick Clifton  <nickc@redhat.com>

	New Romanian translation for gas sub-directory

2024-03-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-20  Simon Marchi  <simon.marchi@efficios.com>

	.pre-commit-config.yaml: bump black hook to 24.3.0
	Running `pre-commit autoupdate` showed that there is a new version of
	the black hook for v24.3.0.  Update it.

	ChangeLog:

		* .pre-commit-config.yaml: Bump black hook to 24.3.0

	Change-Id: I5ec7d2edf99cd15f6525281a43aed9ff481ee9ee

2024-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/server-connect.exp for missing ipv6
	On a system without ipv6 support enabled, when running test-case
	gdb.server/server-connect.exp, it takes about 4 minutes, and I get:
	...
	builtin_spawn gdbserver --once ::1:2347 server-connect^M
	Can't open socket: Address family not supported by protocol.^M
	Exiting^M
	PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
	target remote tcp6:::1:2347^M
	A program is being debugged already.  Kill it? (y or n) y^M
	could not connect: Address family not supported by protocol.^M
	(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
	...

	Fix this by:
	- recognizing the error message in gdbserver_start, and returning an empty list
	  to signal unsupported, and
	- handling the unsupported response in the test-case.

	This brings testing time down to 2 seconds, and gets me:
	...
	UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver
	UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver
	UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver
	UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31502
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502

2024-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle core without build-id in gdb.base/corefile-buildid.exp
	On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get:
	...
	expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163"
	info files^M
	Local core dump file:^M
	        `build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M
	        0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M
		...
	        0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M
	(gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files
	...

	The problem is that the test-case expect the build-id to be available in the
	core file, while it isn't.

	Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in
	gdb.base/coredump-filter-build-id.exp.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases
	On aarch64-linux (debian 12), when running test-case
	gdb.base/longjmp-until-in-main.exp, I run into:
	...
	(gdb) until 33^M
	warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M
	Warning:^M
	Cannot insert breakpoint 0.^M
	Cannot access memory at address 0xfff727c678928489^M
	^M
	0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
	(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
	...

	This is PR gdb/26967: no longjmp probe is available:
	...
	(gdb) info probes stap libc ^longjmp$^M
	No probes matched.^M
	...
	and glibc applies pointer mangling which makes it fairly difficult for gdb to
	get the longjmp target.

	There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit
	b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").

	Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in
	this and one more test-case.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-20  Hannes Domani  <ssbssa@yahoo.de>

	Fix casting in-memory values of primitive types to const reference
	It's currently not possible to cast an in-memory value of a primitive
	type to const reference:
	```
	(gdb) p Q.id
	$1 = 42
	(gdb) p (int&)Q.id
	$2 = (int &) @0x22fd0c: 42
	(gdb) p (const int&)Q.id
	Attempt to take address of value not located in memory.
	```

	And if in a function call an argument needs the same kind of casting,
	it also doesn't work:
	```
	(gdb) l f3
	39      int f3(const int &i)
	40      {
	41        return i;
	42      }
	(gdb) p f3(Q.id)
	Attempt to take address of value not located in memory.
	```

	It's because when the constness of the type changes in a call to
	value_cast, a new not_lval value is allocated, which doesn't exist
	in the target memory.

	Fixed by ignoring const/volatile/restrict qualifications in
	value_cast when comparing cast type to original type, so the new
	value will point to the same location as the original value:
	```
	(gdb) p (int&)i
	$2 = (int &) @0x39f72c: 1
	(gdb) p (const int&)i
	$3 = (const int &) @0x39f72c: 1
	(gdb) p f3(Q.id)
	$4 = 42
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-20  Hannes Domani  <ssbssa@yahoo.de>

	Fix reinterpret_cast for classes with multiple inheritance
	Currently a reinterpret_cast may change the pointer value if
	multiple inheritance is involved:
	```
	(gdb) p r
	$1 = (Right *) 0x22f75c
	(gdb) p reinterpret_cast<LeftRight*>(r)
	$2 = (LeftRight *) 0x22f758
	```

	It's because value_cast is called in this case, which automatically
	does up- and downcasting.

	Fixed by simply using the target pointer type in a copy of the
	original value:
	```
	(gdb) p r
	$1 = (Right *) 0x3bf87c
	(gdb) p reinterpret_cast<LeftRight*>(r)
	$2 = (LeftRight *) 0x3bf87c
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-20  Simon Marchi  <simon.marchi@efficios.com>

	Add .pre-commit-config.yaml
	Add a pre-commit [1] config file, with a single hook to run black on the
	gdb directory whenever a Python file is modified.  We can always add
	more hooks if we find some that are useful.

	Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
	for development, but it can be useful to run some checks that are easy
	to forget (like running black).  The hooks run locally on the
	developer's machine when doing `git commit` (although they can also be
	configured to run at other stages of the git workflow).

	Follow these instructions to install the hooks in your local development
	git repository:

	 - Install pre-commit the way you prefer.  It can be using your OS
	   package manager if it has a recent enough version, or using `pip
	   install pre-commit`.
	 - Go to the binutils-gdb repository and run `pre-commit install`.

	This installs a git hook at `.git/hooks/pre-commit`.

	Now, whenever you modify and try to commit a Python file, pre-commit
	will run black on it.  For instance, if I try to insert something
	misformatted, I get this when doing `git commit`:

	    $ git commit
	    black....................................................................Failed
	    - hook id: black
	    - files were modified by this hook

	    reformatted gdb/python/lib/gdb/dap/breakpoint.py

	    All done! ✨ 🍰 ✨
	    1 file reformatted.

	At this point, black has already reformatted the files in place, so the
	changes that fix the formatting are ready to add and commit.  black is
	only ran on files modified in the commit.

	The hook defines a black version, which is downloaded at `pre-commit
	install` time.  pre-commit manages its own env at
	`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
	black you have installed already.  This may help ensure that
	contributors use the right black version.

	The procedure when there is a new version of black (or a new version of
	any hook we might be using in the future) is:

	 - Modify .pre-commit-config.yaml to change the version number, push to
	   the upstream repo.
	 - Have contributors run `pre-commit autoupdate` to make their local
	   pre-commit installation update the hooks.

	It is possible to have pre-commit skip some hooks if needed [2].

	I will add these instructions to the wiki if this patch gets merged, so
	they are easy to find.  We could perhaps think of having a
	gdb/CONTRIBUTING document of some sort checked in the repo with that
	kind of information.

	I have not used pre-commit in a real project before, but have heard good
	things from it.  If we want to give it a try before pushing it to the
	repo, some volunteers can copy the .pre-commit-config.yaml file locally
	and try it for some time.  However, pushing the file upstream is not
	going to impact anybody who doesn't care about it, so I'd say it's
	relatively low-risk to push it right now.

	[1] https://pre-commit.com
	[2] https://pre-commit.com/#temporarily-disabling-hooks

	Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099
	Acked-By: Tom Tromey <tromey@adacore.com>
	Acked-By: Guinevere Larsen <blarsen@redhat.com>
	Acked-By: Andrew Burgess <aburgess@redhat.com>

2024-03-20  Hannes Domani  <ssbssa@yahoo.de>

	Fix comparison of array types
	Currently it's not possible to call functions if an argument is a
	pointer to an array:
	```
	(gdb) l f
	1       int f (int (*x)[2])
	2       {
	3         return x[0][1];
	4       }
	5
	6       int main()
	7       {
	8         int a[2][2] = {{0, 1}, {2, 3}};
	9         return f (a);
	10      }
	(gdb) p f(a)
	Cannot resolve function f to any overloaded instance
	```

	This happens because types_equal doesn't handle array types, so the
	function is never even considered as a possibility.

	With array type handling added, by comparing element types and array
	bounds, the same works:
	```
	(gdb) p f(a)
	$1 = 1
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398
	Co-Authored-By: Keith Seitz <keiths@redhat.com>
	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: LoongArch: Set the correct XML syscall filename
	Now, there exists syscalls/loongarch-linux.xml, let us set the correct
	XML syscall filename for LoongArch, otherwise GDB won't be able to find
	the correct XML file to open and get the syscalls definitions.

	It should install the package expat-devel (a library for XML parsing)
	and configure --with-expat (done by default if libexpat is installed
	and found at configure time) for compiling gdb in this case.

	Without this patch:

	(gdb) catch syscall
	warning: There is no XML file to open.
	warning: GDB will not be able to display syscall names nor to verify if
	any provided syscall numbers are valid.
	Catchpoint 1 (any syscall)

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Add loongarch case in update-linux-from-src.sh
	It shows that "Don't know how to generate loongarch-linux.xml.in"
	when using the script update-linux-from-src.sh to regenerate the
	syscall group info against Linux kernel, just add loongarch case.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Generate loongarch-linux.xml
	Make use of the command "make" to generate loongarch-linux.xml
	from loongarch-linux.xml.in.

	Like this:

	  $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
	  $ cd gdb.git/gdb/syscalls/
	  $ make

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Add loongarch-linux.xml.in
	There is no syscall.tbl for LoongArch because it uses generic syscalls,
	so it can not generate loongarch-linux.xml.in automatically through the
	script update-linux-from-src.sh, make use of the script update-linux.sh
	to generate loongarch-linux.xml.in.

	Like this:

	  $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
	  $ cd gdb.git/gdb/syscalls/
	  $ touch loongarch-linux.xml.in
	  $ ./update-linux.sh loongarch-linux.xml.in

	Note that the system header file /usr/include/asm-generic/unistd.h
	may be different with the latest upstream Linux kernel uapi header
	file include/uapi/asm-generic/unistd.h, it is better to copy the
	upstream header file into the system header file when generating
	loongarch-linux.xml.in.

	There exist some __NR3264_ prefixed syscall numbers, replace them
	with digital numbers according to /usr/include/asm-generic/unistd.h
	and sort them by syscall number manually, maybe we can modify the
	script to do it automatically in the future.

	  <syscall name="fcntl" number="__NR3264_fcntl"/>
	  <syscall name="statfs" number="__NR3264_statfs"/>
	  <syscall name="fstatfs" number="__NR3264_fstatfs"/>
	  <syscall name="truncate" number="__NR3264_truncate"/>
	  <syscall name="ftruncate" number="__NR3264_ftruncate"/>
	  <syscall name="lseek" number="__NR3264_lseek"/>
	  <syscall name="sendfile" number="__NR3264_sendfile"/>
	  <syscall name="mmap" number="__NR3264_mmap"/>
	  <syscall name="fadvise64" number="__NR3264_fadvise64"/>

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Update .xml files for some archs
	Make use of the command "make" to regenerate .xml files from .xml.in files.

	Like this:

	  $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
	  $ cd gdb.git/gdb/syscalls/
	  $ make

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Update .xml.in files for some archs
	Make use of the script update-linux-from-src.sh to regenerate the Linux
	syscall group info against Linux git commit d206a76d7d27 which will be
	released in v6.8.

	Like this:

	  $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git
	  $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
	  $ cd gdb.git/gdb/syscalls/
	  $ ./update-linux-from-src.sh ~/linux.git/

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: syscalls: Update linux-defaults.xml.in
	Make use of the script update-linux-defaults.sh to regenerate the Linux
	syscall group info against strace git commit 8c480270653d which will be
	released in v6.8.

	Like this:

	  $ git clone https://github.com/strace/strace.git strace.git
	  $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
	  $ cd gdb.git/gdb/syscalls/
	  $ ./update-linux-defaults.sh ~/strace.git/

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Workaround PR gas/31115
	On arm-linux, with gas 2.40, I run into:
	...
	(gdb) x /i main+8^M
	   0x4e1 <main+7>:      vrhadd.u16      d14, d14, d31^M
	(gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try)
	...

	This is a regression due to PR gas/31115, which makes gas produce a low_pc
	with the thumb bit set (0x4d8 & 0x1):
	...
	 <1><24>: Abbrev Number: 2 (DW_TAG_subprogram)
	    <25>   DW_AT_name        : main
	    <29>   DW_AT_external    : 1
	    <29>   DW_AT_type        : <0x2f>
	    <2a>   DW_AT_low_pc      : 0x4d9
	    <2e>   DW_AT_high_pc     : 12
	...

	The regression was introduced in 2.39, and is also present in 2.40 and 2.41,
	and hasn't been fixed yet.

	Work around this in read_func_scope, by using gdbarch_addr_bits_remove on
	low_pc and high_pc.

	Tested on arm-linux and x86_64-linux.

	PR tdep/31453
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453

2024-03-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-19  Tom Tromey  <tromey@adacore.com>

	Speed up lookup of "type_specific_data"
	I noticed that "info locals" on a certain large Ada program was very
	slow.  I tracked this down to ada_get_tsd_type expanding nearly every
	CU in the program.

	This patch fixes the problem by changing this code to use the more
	efficient lookup_transparent_type which, unlike the Ada-specific
	lookup functions, does not try to find all matching instances.

	Note that I first tried fixing this by changing ada_find_any_type, but
	this did not work -- I may revisit this approach at some later date.

	Also note that the copyright dates on the test files are set that way
	because I copied them from another test.

	New in v2: the new test failed on the Linaro regression tester.
	Looking at the logs, it seems that gdb was picking up a 'value' from
	libgnat:

	    $1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>

	This version renames the local variable in an attempt to work around
	this.

	v3: In v2, while trying to reproduce the problem locally, I
	accidentally forgot to commit one of the changes.

2024-03-19  Tom Tromey  <tromey@adacore.com>

	Fix two serious flake8 reports
	flake8 points out that some code in frame_filters.py is referring to
	undefined variables.

	In the first hunk, I've changed the code to match what other
	'complete' methods do in this file.

	In the second hunk, I've simply removed the try/except -- if
	get_filter_priority fails, it will raise GdbError, which is already
	handled properly by gdb.

2024-03-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: test exception case for gdb.solib_name
	The gdb.solib_name() and Progspace.solib_name() functions can throw an
	exception if the address argument is not a valid address, but this is
	not currently tested.

	This commit adds a couple of tests to check that exceptions are thrown
	correctly.

	An early version of this commit updated the documentation, but it was
	pointed out that lots of functions throw an exception if passed an
	argument of the wrong type, and we don't document all of these, it's
	kind-of assumed that passing an object of the incorrect type might
	result in an exception, so this updated version leaves the docs alone,
	but I do think adding the extra tests has value.

	There's no changes to GDB itself in this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-19  Saurabh Jha  <saurabh.jha@arm.com>

	gas, aarch64: Add faminmax extension

2024-03-19  Nick Clifton  <nickc@redhat.com>

	Remove redunant test of ELF size in core note decoder.
	  PR 31469

2024-03-19  Andrew Burgess  <aburgess@redhat.com>

	gdbsupport: rename include guard in gdb-checked-static-cast.h
	I noticed in passing that the include guard in the file
	gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word
	DYNAMIC when STATIC would be better, fixed in this commit.

	There should be no user visible changes after this commit.

2024-03-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: use static_cast in gdb::checked_static_cast
	This commit:

	  commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf
	  Date:   Sat Feb 24 11:00:20 2024 +0100

	      [gdb/build] Fix static cast of virtual base

	addressed an issue where GDB would not compile in production mode due
	to a use of gdb::checked_static_cast.  The problem was that we were
	asking GDB to cast from a virtual base class to a sub-class, this
	works fine when using dynamic_cast, but does not work with
	static_cast.

	The gdb::checked_static_cast actually uses dynamic_cast under the hood
	in development mode in order to ensure that the cast is valid, while
	in a production build we use static_cast as this is more efficient.

	What this meant however, was that when gdb::checked_static_cast was
	used to cast from a virtual base class, the dynamic_cast of a
	non-production build worked fine, while the production build's
	static_cast caused a build failure.

	However, the gdb::checked_static_cast function already contains some
	static_assert calls that are intended to catch any issues with invalid
	type casting, the goal of these asserts was to prevent issues like
	this: the build only failing in production mode.  Clearly the current
	asserts are not enough.

	I don't think there is a std::is_virtual_base type trait check, so
	what I propose instead is that in non-production mode we also make use
	of static_cast.  This will ensure that any errors that crop up in
	production mode should also be revealed in non-production mode, and
	should catch issues like this in the future.

	There should be no user visible changes after this commit.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399

	Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

2024-03-19  Nick Clifton  <nickc@redhat.com>

	Fix seg-fault in the DWARF reader code when accessing an abbreviatuin table with a corrupt entry offset.
	  PR 31456

2024-03-19  H.J. Lu  <hjl.tools@gmail.com>

	ld: Support LD_UNDER_TEST environment variable
	Support LD_UNDER_TEST environment variable to test a different linker.
	Issue an error if LD_UNDER_TEST isn't an absolute full path.

		* testsuite/config/default.exp: If LD_UNDER_TEST environment
		variable exists, set ld and LD to it and set up tmpdir/ld/ld.
		Issue an error if LD_UNDER_TEST isn't an absolute full path.

2024-03-19  Nick Clifton  <nickc@redhat.com>

	Fix free of unallocated memory in the BFD library's compression code.
	  PR 31455

	Fix typo in previous patch to ld.texi

2024-03-19  Toby Lloyd Davies  <tlloyddavies@undo.io>

	gdb/python: Fix segfault when iterating over empty linetable
	symtab-> linetable () is set to null in
	buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab
	has no linetable. Attempting to iterate over this linetable using the
	Python API caused GDB to segfault.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-19  Toby Lloyd Davies  <tlloyddavies@undo.io>

	Add myself to gdb/MAINTAINERS

2024-03-19  Tom de Vries  <tdevries@suse.de>

	[gdb] Further fix "value is not available" with debug frame
	In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame")
	I fixed a case in frame_unwind_register_value where using "set debug frame on"
	caused an "info frame" command to abort, reporting a "value is not available"
	error, due to the tpidruro register being unavailable.

	Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from
	non-FreeBSD target descriptions") removed the unavailable register, which
	caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp.

	While investigating the progression (see PR python/31437), I found that the
	"debug frame" output of the test-case (when reverting commit bbb12eb9c84)
	showed a smilar problem:
	...
	Python Exception <class 'gdb.error'>: value is not available^M
	...
	that was absent without "debug frame".

	Fix this likewise in fetch_lazy_register, and update the test-case to check
	for the exception.

	Furthermore, I realized that there's both value::entirely_available and
	value::entirely_unavailable, and that commit 2aaba744467 handled the case
	of !entirely_available by printing unavailable.

	Instead, print:
	- "unavailable" for entirely_unavailable, and
	- "partly unavailable" for !entirely_unavailable && !entirely_available.

	Tested on x86_64-linux and arm-linux.

2024-03-19  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add relaxation for R_LARCH_CALL36
	This relaxation is effective for both macro instructions (call36, tail36)
	and explicit relocation instructions (pcaddu18i + jirl).

	call36 f	  ->	bl f
	  R_LARCH_CALL36  ->	  R_LARCH_B26

	tail36 $t0, f	  ->	b f
	  R_LARCH_CALL36  ->	  R_LARCH_B26

2024-03-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-18  Nick Clifton  <nickc@redhat.com>

	Regenerate AArch64 opcodes files

2024-03-18  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Add support for SVE ADDPT, SUBPT, MADPT, MLAPT instructions
	The following instructions are added in this patch:

	- ADDPT (predicated): Add checked pointer vectors (predicated).
	- ADDPT (unpredicated): Add checked pointer vectors (unpredicated).
	- SUBPT (predicated): Subtract checked pointer vectors (predicated).
	- SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated).
	- MADPT: Multiply-add checked pointer vectors, writing multiplicand
	- MLAPT: Multiply-add checked pointer vectors, writing addend

	These instructions are part of Checked Pointer Arithmetic extension
	and are enabled when both CPA and SVE are enabled. To achieve this,
	both flag "+sve" and "+cpa" should be active.

	This patch adds assembler and disassembler support for these instructions
	with relevant checks. Tests are included as well.

	Regression tested on the aarch64-none-linux-gnu target and no regressions
	have been found.

2024-03-18  Yury Khrustalev  <yury.khrustalev@arm.com>

	aarch64: Add support for (M)ADDPT and (M)SUBPT instructions
	The following instructions are added in this patch:

	 - ADDPT and SUBPT - Add/Subtract checked pointer
	 - MADDPT and MSUBPT - Multiply Add/Subtract checked pointer

	These instructions are part of Checked Pointer Arithmetic extension.
	This patch adds assembler and disassembler support for these instructions
	with relevant checks. Tests are included as well.

	A new flag "+cpa" added to documentation. This flag enables CPA extension.

	Regression tested on the aarch64-none-linux-gnu target and no regressions
	have been found.

2024-03-18  Nick Clifton  <nickc@redhat.com>

	[PATCH] ld: Improve documentation of -rpath-link search paths

2024-03-18  Tom Tromey  <tromey@adacore.com>

	Remove some unnecessary Ada expression code
	ada_bitwise_operation differs from the "usual" bitwise operations only
	in that it calls value_cast at the end.  However, because gdb is
	generally fairly lax about integer types, and because (perhaps oddly)
	C-style binary promotion is done here anyway, it seems to me that this
	code isn't needed.

2024-03-18  Tom Tromey  <tromey@adacore.com>

	Fix Ada 'ptype' of access to array
	ptype is a bit funny, in that it accepts both expressions and type
	names.  It also evaluates the resulting expression using
	EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would
	you expect ptype to possibly cause inferior execution?), but is also a
	historical artifact of how expressions are implemented (there's no
	EVAL_FOR_TYPE).

	In Ada, calling a function with an array will sometimes result in a
	"thick pointer" array descriptor being made.  This is essentially a
	structure holding a pointer and bounds information.

	Currently, in such a callee, printing the type of the array will yield
	funny results:

	    (gdb) print str.all
	    $1 = "Hello World"
	    (gdb) ptype str
	    type = array (<>) of character
	    (gdb) ptype str.all
	    type = array (1 .. 0) of character

	That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch
	trying to do "something" with an array descriptor, without doing too
	much.

	I tried briefly to make this code really dereference the array
	descriptor and get the correct runtime type.  However, that proved to
	be tricky; it certainly can't be done for all access types, because
	that will cause dynamic type resolution and end up printing just the
	runtime type -- which with variants may be pretty far from what the
	user may expect.

	Instead, this patch arranges to just leave such types alone in this
	situation.  I don't think this should have an extra effects, because
	things like array subscripting still work on thick pointers.

	This patch also touches arrayptr.exp, because in that case the access
	type is a "thin pointer", and this ensures that the output does not
	change in that scenario.

2024-03-18  Tom Tromey  <tromey@adacore.com>

	Use string_view in quirk_rust_enum
	quirk_rust_enum makes string copies to store in an unordered_map.
	However, the original strings have an appropriate lifetime, and so no
	copying is needed.  With C++17, we can rely on string_view having a
	std::hash specialization, so this patch changes this code to use
	string_view rather than string.

2024-03-18  Tom Tromey  <tromey@adacore.com>

	Set __file__ when source'ing a Python script
	This patch arranges to set __file__ when source'ing a Python script.
	This fixes a problem that was introduced by the "source" rewrite, and
	then pointed out by Lancelot Six.

	Reviewed-by: Lancelot Six <lancelot.six@amd.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-03-18  Tom Tromey  <tromey@adacore.com>

	Clear board_info entry after waiting for process
	When certain DAP tests are run in a certain order, dejagnu will throw
	an exception during shutdown.  After adding many logging statements, I
	tracked this down to kill_wait_spawned_process not clearing the
	'fileid' board_info entry, causing dejagnu to try to wait for the
	process a second time -- and fail.

	Tom de Vries then pointed out a second instance of this, which I
	tracked down to the same problem occurring when spawning gdbserver.

	This version of the patch fixes this by adding a new proc that can be
	used to clean up board_info after waiting for a process to exit.  I'm
	not sure why this problem hasn't affected the test suite in the past.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-03-18  Clément Chigot  <chigot@adacore.com>

	bfd: add missing include <time.h>
	bdfio.c is defining bfd_get_current_time which is returning a time_t.
	This type is defined in time.h and thus, must be included in bfd main
	header to avoid undefined type when include bfd.h.

	Note that most of the time, <time.h> is pulled by <sys/stat.h> already
	included in bfd.h. That's why it went unnoticed.

2024-03-18  Nick Clifton  <nickc@redhat.com>

	Fix compiling bfd/vms-lib.c for a 32-bit host.

2024-03-18  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: attach to i386 process stopped in vDSO
	Fedora GDB has carried around a patch for a while which tested
	attaching to an i386 process which is stopped within the vDSO library
	region.  Apparently, at some point in the distant past there was an
	issue finding symbol information for this region in this situation.

	I'm struggling to track down the precise details of what the original
	bug was, however, acquiring symbol information for the vDSO region is
	different than for "normal" shared libraries -- the vDSO information
	is synthesised within GDB during the attach / inferior creation
	process -- so it's not unreasonable to imagine that there could be a
	bug specifically in this area of GDB which wouldn't impact "normal"
	shared libraries.

	I looked for references to vDSO in our testsuite and couldn't find
	any tests that looked like they did the same sort of thing, so I'd
	like to propose adding this test to our testsuite.

	It's a pretty simple test, and doesn't take long to run, so the cost
	of adding this is not huge.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-18  Jan Beulich  <jbeulich@suse.com>

	Arm64: check matching operands for predicated B16B16 insns
	Except for bfml{a,s} their 1st and 3rd operands need to match - pass
	the TIED macro argument accordingly. While doing that also slightly
	re-arrange table entries, such that all predicated insns are close
	together.

	At the same time change the existing test source to actually use non-
	matching operands for the respective bfml{a,s} forms.

2024-03-18  Jan Beulich  <jbeulich@suse.com>

	Arm64: correct B16B16 indexed bf{mla,mls,mul}
	Their index is in bits 19, 20, and 22. Bit 11 in particular is already
	set in the base opcode. Note also how disassembler output didn't match
	assembler input in the respective testcase.

2024-03-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Tidy smstateen and ssstateen testcases.
	gas/
		* testsuite/gas/riscv/march-imply-smstateen.d: Added.
		* testsuite/gas/riscv/smstateen-csr-s.d: Removed.
		* testsuite/gas/riscv/ssstateen-csr.d: Likewise.
		* testsuite/gas/riscv/ssstateen-csr.s: Likewise.

2024-03-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/list-no-debug.exp on debian
	On debian 12, aarch64-linux I run into:
	...
	(gdb) list .^M
	No symbol table is loaded.  Use the "file" command.^M
	(gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .'
	...

	The test-case expects some debug info, but none for main.  Instead, there's no
	debug info at all.

	Fix this by adding another source file to the test-case, and compiling it with
	debug info.

	Tested on aarch64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	PR testsuite/31290
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290

2024-03-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-15  Tom Tromey  <tromey@adacore.com>

	Use size_t in gdb_bfd_section_data
	BFD recently changed bfd_mmap to use size_t, not bfd_size_type.  This
	patch updates gdb_bfd_section_data to follow.  Without this patch, if
	the two types ever differ, gdb would fail to build.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-03-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	gas/NEWS: Remove mention of AArch64 B16B16 extension
	This aligns the 2.42 NEWS with the update backported to the 2.42 release
	branch.

2024-03-15  Jan Beulich  <jbeulich@suse.com>

	x86/APX: legacy promoted insns can't access %xmm16-%xmm31
	Irrespective of the encoding being EVEX, the usable SIMD register range
	continues to be limited to %xmm0-%xmm15. Enforce this in gas (but
	continue to generate code, as in principle we know how to encode
	things) and recognize/flag the case in the disassembler.

	Oddly enough wrong forms were actually used in the testsuite (register-
	only forms are then really meaningless to test here, and are hence
	dropped instead of adjusted).

	Convert the POP2 test that needs touching anyway (due to a bad ModR/M
	byte having been chosen) to .insn.

2024-03-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix build on postmarketos
	I tried building gdbserver on postmarketos (which is based on alpine linux,
	which uses musl libc), and ran into:
	...
	gdbserver/linux-low.cc: In lambda function:
	gdbserver/linux-low.cc:1907:41: error: \
	  'W_EXITCODE' was not declared in this scope
	 1907 |               mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true);
	      |                                         ^~~~~~~~~~
	...

	The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h.

	OTOH, WSETEXIT is defined there, but unused:
	...
	 /* These are not defined in POSIX, but are used by our programs.  */

	 #ifndef WSETEXIT
	 # ifdef W_EXITCODE
	 #define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0))
	 # else
	 #define WSETEXIT(w,status) ((w) = (0 | ((status) << 8)))
	 # endif
	 #endif
	...

	Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE.

	Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make
	sure the definition is exercised.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/31483
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483

2024-03-14  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver/linux: probe for libiconv in configure
	Make gdbserver's build system locate libiconv when building for Linux.

	Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names")
	make libiconv madantory for building gdbserver on Linux.

	While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
	toolchain generated with crosstool-ng), I got:

	    /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
	       48 | #include <iconv.h>
	          |          ^~~~~~~~~

	I downloaded GNU libiconv, built it for that host, and installed it in
	an arbitrary directory.  I had to modify the gdbserver build system to
	locate libiconv and use it, the result is this patch.

	I eventually found that crosstool-ng has a config option to make uclibc
	provide an implementation of iconv, which is of course much easier.  But
	given that this patch is now written, I think it would be worth merging
	it, it could help some people who do not have iconv built-in their libc
	in the future (and may not have the luxury of rebuilding their libc like
	I do).

	Using AM_ICONV in configure.ac adds these options for configure (the
	same we have for gdb):

	    --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
	    --without-libiconv-prefix     don't search for libiconv in includedir and libdir
	    --with-libiconv-type=TYPE     type of library to search for (auto/static/shared)

	It sets the `LIBICONV` variable with whatever is needed to link with
	libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.

	To avoid unnecessarily linking against libiconv on hosts that don't need
	it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
	host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.

	Since libiconv is a hard requirement for Linux hosts, error out if it is
	not found.

	The bits in acinclude.m4 are similar to what we have in
	gdb/acinclude.m4.

	Update the top-level build system to support building against an in-tree
	libiconv (I did not test this part though).  Something tells me that the
	all-gdbserver dependency on all-libiconv is unnecessary, since there is
	already a dependency of configure-gdbserver on all-libiconv (and
	all-gdbserver surely depends on configure-gdbserver).  I just copied
	what's done for GDB though.

	ChangeLog:

		* Makefile.def: Add configure-gdbserver and all-gdbserver
		dependencies on all-libiconv.
		* Makefile.in: Re-generate.

	Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-14  Tom Tromey  <tom@tromey.com>

	Pass alignment when using GCC_C_FE_VERSION_2
	When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can
	use the new 'finish_record_with_alignment' method.  This lets gdb pass
	alignment information to the compiler, which in turn fixes the test
	case included in this patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397

2024-03-14  Tom Tromey  <tom@tromey.com>

	Remove 'if' from GDB_PY_HANDLE_EXCEPTION
	This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and
	GDB_PY_SET_HANDLE_EXCEPTION.  I believe this 'if' was necessary with
	the old gdb try/catch macros, but it no longer is: these should only
	ever be called from a 'catch' block, where it's already known that an
	exception was thrown.

	Simon pointed out, though, that in a few spots, these were in facts
	called outside of 'catch' blocks.  This patch cleans up these spots.
	I also found one spot where a redundant 'return nullptr' could be
	removed.

2024-03-14  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64
	On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into:
	...
	(gdb) watch data.u.size8twice[1]^M
	Hardware watchpoint 241: data.u.size8twice[1]^M
	(gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1]
	continue^M
	Continuing.^M
	FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
	FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
	...

	This happens as follows.

	We start the exec and set an 8-byte hardware watchpoint on
	data.u.size8twice[1] at address 0x440048:
	...
	(gdb) p sizeof (data.u.size8twice[1])
	$1 = 8
	(gdb) p &data.u.size8twice[1]
	$2 = (uint64_t *) 0x440048 <data+16>
	...

	We continue execution, and a 16-byte write at address 0x440040 triggers the
	hardware watchpoint:
	...
	  4101c8:       a9000801        stp     x1, x2, [x0]
	...

	When checking whether a watchpoint has triggered in
	aarch64_stopped_data_address, we check against address 0x440040 (passed in
	parameter addr_trap).  This behaviour is documented:
	...
		  /* ADDR_TRAP reports the first address of the memory range
		     accessed by the CPU, regardless of what was the memory
		     range watched.  ...  */
	...
	and consequently the matching logic compares against an addr_watch_aligned:
	...
		  && addr_trap >= addr_watch_aligned
		  && addr_trap < addr_watch + len)
	...

	However, the comparison fails:
	...
	(gdb) p /x addr_watch_aligned
	$3 = 0x440048
	(gdb) p addr_trap >= addr_watch_aligned
	$4 = false
	...

	Consequently, aarch64_stopped_data_address returns false, and
	stopped_by_watchpoint returns false, and watchpoints_triggered returns 0,
	which make infrun think it's looking at a delayed hardware
	breakpoint/watchpoint trap:
	...
	  [infrun] handle_signal_stop: stop_pc=0x4101c8
	  [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring
	...
	Infrun then ignores the trap and continues, but runs into the same situation
	again and again, causing a hang which then causes the test timeout.

	Fix this by allowing a match 8 bytes below addr_watch_aligned.  This
	introduces the possibility for false positives, so we only do this for regular
	"value changed" watchpoints.

	An earlier version of this patch worked by aligning addr_watch_aligned to 16
	instead of 8:
	...
	-  const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8);
	+  const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16);
	...
	but while that fixed the test-case, it didn't fix the problem completely, so
	extend the test-case to check more scenarios.

	Tested on aarch64-linux.

	Tested-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/29423
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423

2024-03-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-13  Tom Tromey  <tromey@adacore.com>

	Remove extraneous word from manual
	I noticed that the manual has an extra "either", which makes a
	sentence ungrammatical.  This patch removes it.

2024-03-13  Christophe Lyon  <christophe.lyon@linaro.org>

	opcodes: Fix build verbosity
	Add $(AM_V_xxx) in a few places where they were missing.

2024-03-13  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Use size_t in the BFD mmap interface
	Change the size type in the BFD mmap interface from bfd_size_type to
	size_t to be consistent with the size type of the host mmap interface.

		* bfdio.c (bfd_iovec): Change the bmmap size type to size_t.
		(bfd_mmap): Likewise.
		(memory_bmmap): Likewise.
		* cache.c (cache_bmmap): Change the bmmap size type to size_t.
		* opncls.c (opncls_bmmap): Change the bmmap size type to size_t.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Likewise.

2024-03-13  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Use MAP_FAILED for mmap failure
	Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use
	((void *) -1) only if MAP_FAILED is undefined.

		* bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for
		mmap failure.
		* bfdwin.c: Don't include <sys/mman.h>.
		(MAP_FILE): Removed.
		(bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for
		mmap failure.
		* cache.c: Don't include <sys/mman.h>.
		(cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap
		failure.
		* opncls.c (opncls_bmmap): Likewise.
		* sysdep.h: Include <sys/mman.h> if HAVE_MMAP is define.
		(MAP_FILE): New.  Defined as 0 if undefined.
		(MAP_FAILED): New.  Defined as ((void *) -1) if undefined.

2024-03-13  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Don't call bfd_write with 0 size
	There is no need to call bfd_write with 0 size.

		* elf-strtab.c (_bfd_elf_strtab_emit): Don't call bfd_write with
		0 size.

2024-03-13  Hau Hsu  <hau.hsu@sifive.com>

	RISC-V: Add -march=help for gas
	Use -march=help for gas to print all supported extensions and versions.

	Here is part of the output of `as -march=help`:
	All available -march extensions for RISC-V:
	        e                                       1.9
	        i                                       2.1, 2.0
	        m                                       2.0
	        a                                       2.1, 2.0
	        f                                       2.2, 2.0
	        d                                       2.2, 2.0
	        q                                       2.2, 2.0
	        c                                       2.0
	        v                                       1.0
	        h                                       1.0
	        zicbom                                  1.0
	        zicbop                                  1.0
	        ...

	This patch assumes that the supported extensions with the same versions
	are listed together. For example:
	static struct riscv_supported_ext riscv_supported_std_ext[] =
	{
	  ...
	  {"i",         ISA_SPEC_CLASS_20191213,        2, 1, 0 },
	  {"i",         ISA_SPEC_CLASS_20190608,        2, 1, 0 },
	  {"i",         ISA_SPEC_CLASS_2P2,             2, 0, 0 },
	  ...
	};

	For the "i" extension, 2.1.0 with different spec class are listed together.
	This patch records the previous printed extension and version.  If the
	current extension and version are the same as the previous one, skip
	printing.

	bfd/
		* elfxx-riscv.c (riscv_print_extensions): New function.  Print
		available extensions and versions.
		* elfxx-riscv.h (riscv_print_extensions): New declaration.
	gas/
		* gas/config/tc-riscv.c (md_parse_option): Parse 'help' keyword in
		-march option to print available extensions and versions.
		* testsuite/gas/riscv/march-help.l: New testcase for -march=help.
		* testsuite/gas/riscv/riscv.exp: Updated.

2024-03-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64
	On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Hardware watchpoint 2: -location q.a^M
	^M
	Old value = 1^M
	New value = 0^M
	main () at watch-bitfields.c:42^M
	42        q.h--;^M
	(gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue
	...

	In a minimal form, if we step past line 37 which sets q.e, and we have a
	watchpoint set on q.e, it triggers:
	...
	$ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step
	Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37.

	Breakpoint 1, main () at watch-bitfields.c:37
	37        q.e = 5;
	Hardware watchpoint 2: q.e

	Hardware watchpoint 2: q.e

	Old value = 0
	New value = 5
	main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38
	38        q.f = 6;
	...

	However, if we set in addition a watchpoint on q.a, the watchpoint on q.e
	doesn't trigger.

	How does this happen?

	Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1
	and bit 1 of byte 2.  So, watch q.a should watch byte 0, and watch q.e should
	watch bytes 1 and 2.

	Using "maint set show-debug-regs on" (and some more detailed debug prints) we
	get:
	...
	WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1
	  ctrl: enabled=1, offset=1, len=2
	WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1
	  ctrl: enabled=1, offset=0, len=1
	...
	which matches that.

	When executing line 37, a hardware watchpoint trap triggers and we hit
	aarch64_stopped_data_address with addr_trap == 0x440028:
	...
	(gdb) p /x addr_trap
	$1 = 0x440028
	....
	and since the loop in aarch64_stopped_data_address walks backward, we check
	WP3 first, which matches, and consequently target_stopped_by_watchpoint
	returns true in watchpoints_triggered.

	Likewise for target_stopped_data_address, which also returns addr == 0x440028.
	Watchpoints_triggered matches watchpoint q.a to that address, and sets
	watch_triggered_yes.

	However, subsequently the value of q.a is checked, and it's the same value as
	before (becase the insn in line 37 didn't change q.a), so the watchpoint
	hardware trap is not reported to the user.

	The problem originates from that fact that aarch64_stopped_data_address picked
	WP3 instead of WP2.

	There's something we can do about this.  In the example above, both
	target_stopped_by_watchpoint and target_stopped_data_address returned true.
	Instead we can return true in target_stopped_by_watchpoint but false in
	target_stopped_data_address.  This lets watchpoints_triggered known that a
	watchpoint was triggered, but we don't know where, and both watchpoints
	get set to watch_triggered_unknown.

	Subsequently, the values of both q.a and q.e are checked, and since q.e is not
	the same value as before, the watchpoint hardware trap is reported to the user.

	Note that this works well for regular (write) watchpoints (watch command), but
	not for read watchpoints (rwatch command), because for those no value is
	checked.  Likewise for access watchpoints (awatch command).

	So, fix this by:
	- passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and
	  aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not
	  interested in the stop address,
	- introducing a two-phase approach in aarch64_stopped_data_address, where:
	  - phase one handles access and read watchpoints, as before, and
	  - phase two handles write watchpoints, where multiple matches cause:
	    - return true if addr_p == null, and
	    - return false if addr_p != null.

	Tested on aarch64-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/31214
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214

2024-03-12  Sam James  <sam@gentoo.org>

	contrib: sync dg-extract-results.sh with GCC
	This syncs dg-extract-results.sh with GCC.

	It contains two commits: r14-4333-g346f5991569fae and r14-9393-g64273a7e6bd8ba.

	contrib/ChangeLog:
		* dg-extract-results.sh: Sync with GCC.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-12  Sam James  <sam@gentoo.org>

	contrib: sync dg-extract-results.py with GCC
	This syncs dg-extract-results.py with GCC.

	It contains only one commit: r14-7145-g8f67953d0198fe.

	contrib/ChangeLog:
	        * dg-extract-results.py: Sync with GCC.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-12  Schimpe, Christina  <christina.schimpe@intel.com>

	gdb: Deprecate MPX commands.
	This patch deprecates the MPX commands "show/set mpx bound".
	Intel listed Intel(R) Memory Protection Extensions (MPX) as removed
	in 2019.  Following gcc v9.1, the linux kernel v5.6 and glibc v2.35,
	deprecate MPX in GDB.

2024-03-12  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Scan all illegal operand instructions without interruption
	Currently, gas will exit immediately and report an error when
	it sees illegal operands, and will not process the remaining
	instructions. Replace as_fatal with as_bad to check for all
	illegal operands.

	Add test cases for illegal operands of some instructions.

2024-03-12  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix gas and ld test cases
	* After adding the old LE relax, all old LE relocations will have
	  an R_LARCH_RELAX relocation. Fix the gas test case failure caused
	  by the implementation of the old LE relax.

	* loongarch64-elf does not support pie and -z norelro options,
	  removed in test files.

2024-03-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gnulib: re-generate build files
	I see some changes in the generated files when running update-gnulib.sh.
	The changes appeared with commit 35b38b0182d0 ("Finalized intl-update
	patches (trois)").  This is most likely due to how the autotools were
	ran in that commit, possibly with some different -I arguments.

	Change-Id: Idaad8084b0e91e22d066f573775e21d0c7a039cb

2024-03-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-11  Sam James  <sam@gentoo.org>

	Sync libbacktrace from gcc [PR31327]
	Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which
	landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC.

	This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk.

	Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b
	which would've required an autoreconf, as it should be handled separately.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-11  Tom Tromey  <tom@tromey.com>

	Remove tui-out.[ch]
	The other day on irc, we were discussing the "m_line" hack in
	tui-out.c, and I mentioned that it would be nice to replace this with
	a new ui_out_flag.

	Later, I looked at ui_out_flag and found:

	      ui_source_list = (1 << 0),

	... and sure enough, this is tested already.

	This patch removes tui-out.[ch] and changes the TUI to use an ordinary
	cli-out object without this flag set.

	As far as I can tell, this doesn't affect behavior at all -- the TUI
	tests all pass, and interactively I tried switching stack frames,
	"list", etc, and it all seems to work.

	New in v2: fixed the problem pointed out by Keith, and added a test
	case for that scenario.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2024-03-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/Makefile.in: remove ACLOCAL_AMFLAGS
	aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in
	configure.ac, so there's no need to pass `-I ../config` here.

	Passing `-I ../config` is actually annoying, because it makes the output
	different between when the update is triggered by the maintainer mode
	and when aclocal or autoreconf is ran with no special flags.  The
	difference in the output is due to the order of include paths being
	different.

	Change-Id: I2c963876516570842f20b4a6a470867e7a941006
	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-11  Tom Tromey  <tromey@adacore.com>

	Special case NULL pointers in dynamic type resolution
	commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically")
	caused a regression on a test case in the AdaCore internal test suite.

	The issue here is that gdb would try to resolve the type of a dynamic
	pointer that happened to be NULL.  In this case, the "Location address
	is not set." error would end up being thrown from the DWARF expression
	evaluator.

	I think it makes more sense to special-case NULL pointers and not try
	to resolve their target type, as that type can't really be accessed
	anyway.

	This patch implements this idea, and also adds the missing Ada test
	case.

2024-03-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: reformat file with a more recent version of black
	A Python file in my previous commit (5eb2254a1d1) was formatted with
	an older version of black, which gives slightly different results.

	Reformat with a newer version of black.  This should make our
	post-commit testing happy again.

	No functional changes in this commit.

2024-03-11  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix uninitialized variables in testsuite
	Just because a path is an error path doesn't mean the program terminates
	there if you don't ask it to.  And we don't want to -- but that means
	we need to initialize the variables that are missed if an error happens to
	*something*.  Type ID 0 (unimplemented) will do: it'll induce further
	ECTF_BADID errors, but that's no bad thing.

	libctf/ChangeLog:

		* testsuite/libctf-writable/libctf-errors.c: Initialize variables.

2024-03-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb:  re-generate aclocal.m4
	I get some changes when running `autoreconf -vf` in the gdb directory,
	fix that.

	I did a bisect, it appears to have been introduced in this commit, not
	sure why we haven't spotted that before.

	    commit 862776f26a59516467c98091994c3dac90383159
	    Author:     Arsen Arsenovi? <arsen@aarsen.me>
	    AuthorDate: Wed Nov 15 12:53:04 2023 +0000
	    Commit:     Nick Clifton <nickc@redhat.com>
	    CommitDate: Wed Nov 15 12:53:04 2023 +0000

	Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9

2024-03-11  Markus Metzger  <markus.t.metzger@intel.com>

	gdb, btrace: fix error diagnostics
	When we improved error messages in

	    cd393cec3ab gdb, btrace: improve error messages

	we cleared the original errno.  When the error reason can not be explained
	in a more detailed error message, and we fall back to the default error
	message, it now gives Success as error.

	Restore the original errno to fix that.

2024-03-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/unwinders: better support for $pc not saved
	This started with a Red Hat bug report which can be seen here:

	  https://bugzilla.redhat.com/show_bug.cgi?id=1850710

	The problem reported here was using GDB on GNU/Linux for S390, the
	user stepped into JIT generated code.  As they enter the JIT code GDB
	would report 'PC not saved', and this same message would be reported
	after each step/stepi.

	Additionally, the user had 'set disassemble-next-line on', and once
	they entered the JIT code this output was not displayed, nor were any
	'display' directives displayed.

	The user is not making use of the JIT plugin API to provide debug
	information.  But that's OK, they aren't expecting any source level
	debug here, they are happy to use 'stepi', but the missing 'display'
	directives are a problem, as is the constant 'PC not saved' (error)
	message.

	What is happening here is that as GDB is failing to find any debug
	information for the JIT generated code, it is falling back on to the
	S390 prologue unwinder to try and unwind frame #0.  Unfortunately,
	without being able to identify the function boundaries, the S390
	prologue scanner can't help much, in fact, it doesn't even suggest an
	arbitrary previous $pc value (some targets that use a link-register
	will, by default, assume the link-register contains the previous $pc),
	instead the S390 will just say, "sorry, I have no previous $pc value".

	The result of this is that when GDB tries to find frame #1 we end
	throwing an error from frame_unwind_pc (the 'PC not saved' error).
	This error is not caught anywhere except at the top-level interpreter
	loop, and so we end up skipping all the 'display' directive handling.

	While thinking about this, I wondered, could I trigger the same error
	using the Python Unwinder API?  What happens if a Python unwinder
	claims a frame, but then fails to provide a previous $pc value?

	Turns out that exactly the same thing happens, which is great, as that
	means we now have a way to reproduce this bug on any target.  And so
	the test included with this patch does just this.  I have a Python
	unwinder that claims a frame, but doesn't provide any previous
	register values.

	I then do two tests, first I stop in the claimed frame (i.e. frame #0
	is the frame that can't be unwound), I perform a few steps, and check
	the backtrace.  And second, I stop in a child of the problem
	frame (i.e. frame #1 is the frame that can't be unwound), and from
	here I check the backtrace.

	While all this is going on I have a 'display' directive in place, and
	each time GDB stops I check that the display directive triggers.

	Additionally, when checking the backtrace, I am checking that the
	backtrace finishes with the message 'Backtrace stopped: frame did not
	save the PC'.

	As for the fix I chose to add a call to frame_unwind_pc directly to
	get_prev_frame_always_1.  Calling frame_unwind_pc will cache the
	unwound $pc value, so this doesn't add much additional work as
	immediately after the new frame_unwind_pc call, we call
	get_prev_frame_maybe_check_cycle, which actually generates the
	previous frame, which will always (I think) require a call to
	frame_unwind_pc anyway.

	The reason for adding the frame_unwind_pc call into
	get_prev_frame_always_1, is that if the frame_unwind_pc call fails we
	want to set the frames 'stop_reason', and get_prev_frame_always_1
	seems to be the place where this is done, so I wanted to keep the new
	stop_reason setting code next to all the existing stop_reason setting
	code.

	Additionally, once we enter get_prev_frame_maybe_check_cycle we
	actually create the previous frame, then, if it turns out that the
	previous frame can't be created we need to remove the frame .. this
	seemed more complex than just making the check in
	get_prev_frame_always_1.

	With this fix in place the original S390 bug is fixed, and also the
	test added in this commit, that uses the Python API, is also fixed.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2024-03-11  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: Reduce gdb.threads/threadcrash.exp reliance on libc symbols
	The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and
	print the names of all functions. However, some of the functions are
	from the libc library, and so the test implicitly demanded libc symbols
	to be available, and would fail otherwise, as was raised in PR
	gdb/31293.

	This commit changes it so we only explicitly check for functions that
	are not provided by threadcrash.c if they are indeed available.

	Tested on arm-linux and x86_64-linux.

	Approved-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293

2024-03-11  Tom de Vries  <tdevries@suse.de>

	gdb/testsuite: Simplify gdb.threads/threadcrash.exp
	I noticed in gdb.threads/threadcrash.exp that the usage of test_list is
	somewhat convoluted.

	Simplify the test-case by storing a classification instead of a pattern in
	test_list.

	Tested on arm-linux and x86_64-linux.

2024-03-11  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: Use _inferior_thread_count in gdb.threads/threadcrash.exp
	A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails
	to cout the number of threads in the inferior:
	...
	FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
	FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list]
	...

	Fix this by getting the convenience variable _inferior_thread_count as opposed
	to calculating it based on the output of "info threads".

	Tested on arm-linux and x86_64-linux.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>
	Approved-By: Tom de Vries <tdevries@suse.de>

	[1] https://linaro.atlassian.net/browse/GNU-1120

2024-03-11  Tom de Vries  <tdevries@suse.de>

	gdb/testsuite: Fix gdb.threads/threadcrash.exp with check-readmore
	With check-readmore, I run into:
	...
	FAIL: gdb.threads/threadcrash.exp: test_corefile: \
	  $thread_count == [llength $test_list]
	...

	The problem is that the clauses in the gdb_test_multiple for
	"thread apply all backtrace" intent to match one line, but actually can
	match more than one line, and consequently a match for one type of thread can
	consume a line that was supposed to match another thread.

	For instance, there's this regexp:
	...
		    -re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" {
	...

	It's limited at the end by \[^\n\]*, meaning the match stops at the end of the
	line.

	But it doesn't start with a ^, and consequently can match more than one line.
	The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at
	the start of each pattern, unless it's anchored using a ^.

	Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where:
	- hs is: \[^\n\]* (horizontal space), and
	- eol is (?=\r\n) (look-ahead end-of-line).

	It also turned out to be necessary to drop the -lbl switch, and introduce a
	corresponding explicit clause.  The -lbl clause is placed ALAP, and
	consequently allowed the default fail clause to trigger.

	Tested on arm-linux and x86_64-linux.

2024-03-11  Tom de Vries  <tdevries@suse.de>

	gdb/testsuite: Reduce indentation in gdb.threads/threadcrash.exp
	In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented
	gdb_test_multiple:
	...
	    gdb_test_multiple "thread apply all backtrace" \
		"Get thread information" -lbl {
		    -re "#\[0-9\]+\\\?\\\?\[^\n\]*" {
	...

	Fix this by moving the command into a variable, allowing the
	"gdb_test_multiple ... {" to fit on a single 80 chars line.

	Tested on arm-linux and x86_64-linux.

2024-03-11  Jan Beulich  <jbeulich@suse.com>

	x86: KeyLocker insn interaction with -msse-check / .sse_check
	Some of these have no explicit %xmm operand(s), yet they still act SSE-
	like (in leaveing bits 128 and up untouched). Hence they want similarly
	diagnosing, if that was asked for.

	x86/APX: permit wider than 4-bit immediates with V{EXTRACT,INSERT}{F,I}128
	These aren't useful, but can be encoded for their AVX forms and hence
	should also be permitted for the APX surrogates. Extend the respective
	conditional by a base opcode check, to restrict it to VROUND{P,S}{S,D}.

	x86: don't open-code REG_{SP,FP}
	Since we have the #define-s, we should also use them.

2024-03-11  Stephen Kitt  <steve@sk2.org>

	tests: force non-deterministic mode in non-deterministic tests
	Since ar can be built defaulting to deterministic mode, tests which
	expect non-deterministic behaviour need to explicitly set the U flag.

	The non-deterministic member test expects SOURCE_DATE_EPOCH to not be
	set; this documents that. Unconditionally unsetting the variable
	causes issues in test infrastructure (which expects unsetenv to only
	be called on variables which are already set).

2024-03-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Handle deprecation of PyErr_{Fetch,Restore} in 3.12
	Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated.

	Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for
	python >= 3.12.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Normalize exceptions in gdbpy_err_fetch
	With python 3.12, I run into:
	...
	(gdb) PASS: gdb.python/py-block.exp: check variable access
	python print (block['nonexistent'])^M
	Python Exception <class 'KeyError'>: 'nonexistent'^M
	Error occurred in Python: 'nonexistent'^M
	(gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable
	...

	The problem is that that PyErr_Fetch returns a normalized exception, while the
	test-case matches the output for an unnormalized exception.

	With python 3.6, PyErr_Fetch returns an unnormalized exception, and the
	test passes.

	Fix this by:
	- updating the test-case to match the output for a normalized exception, and
	- lazily forcing normalized exceptions using PyErr_NormalizeException.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Use gdbpy_err_fetch::{type,value} as getters
	Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use
	both consistently to get gdbpy_err_fetch members m_error_value and
	m_error_type.

	Tested on aarch64-linux.

2024-03-09  Alan Modra  <amodra@gmail.com>

	Reinstate bfd_print_error as an extern function
		* bfd.c (_bfd_print): Renamed from bfd_print_error.
		(bfd_print_error): Reinstate previous code but using the above.
		(error_handler_fprintf, error_handler_sprintf): Adjust.
		* bfd-in2.h: Regenerate.

2024-03-09  Alan Modra  <amodra@gmail.com>

	Re: Move bfd_init to bfd.c
	Commit b1c95bc4dd73 cleared some bfd static variables, with bad
	results since bfd_set_error_program_name is often called before
	bfd_init.

		* bfd.c (bfd_init): Don't clear _bfd_error_program_name.

2024-03-09  Alan Modra  <amodra@gmail.com>

	print cached error messages using _bfd_error_handler
		* bfd.c (bfd_print_error): Make static.  Don't print program name.
		(error_handler_fprintf): Print program name here.
		* format.c (print_warnmsg): Use _bfd_error_handler to print
		cached messages.
		* bfd-in2.h: Regenerate.

2024-03-09  Tom Tromey  <tom@tromey.com>

	Avoid race when writing to index cache
	The background DWARF reader changes introduced a race when writing to
	the index cache.  The problem here is that constructing the
	index_cache_store_context object should only happen on the main
	thread, to ensure that the various value captures do not race.

	This patch adds an assert to the construct to that effect, and then
	arranges for this object to be constructed by the cooked_index_worker
	constructor -- which is only invoked on the main thread.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262

2024-03-09  Tom Tromey  <tom@tromey.com>

	Move the 'store' method to index_cache_store_context
	I think it is cleaner for 'store' to be a method on
	index_cache_store_context rather than on the global index cache
	itself.  This patch makes this change.

	Capture the per-BFD object in index_cache_store_context
	This changes index_cache_store_context to also capture the per-BFD
	object when it is constructed.  This is used when storing to the
	cache, and this approach makes the code a little simpler.

	Capture directory in index_cache_store_context
	I noticed that index_cache_store_context captures the 'enabled'
	setting, but not the index cache directory.  This patch makes this
	change, which avoids a possible race -- with background reading, the
	user could possibly change this directory at the exact moment the
	writer examines the variable.

	Rename members of index_cache_store_context
	This renames the private members of index_cache_store_context to start
	with "m_".

2024-03-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-08  Tom Tromey  <tromey@adacore.com>

	Add return value to DAP scope
	A bug report in the DAP specification repository pointed out that it
	is typical for DAP implementations to put a function's return value
	into the outermost scope.

	This patch changes gdb to follow this convention.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2024-03-08  Tom Tromey  <tromey@adacore.com>

	Export "finish" return value to Python
	This patch changes the Python "stop" event emission code to also add
	the function return value, if it is known.  This happens when the stop
	comes from a "finish" command and when the value can be fetched.

	The test is in the next patch.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-03-08  H.J. Lu  <hjl.tools@gmail.com>

	gas: Fix x86 build with GCC 6.4
	Add "()" to silence GCC 6.4:

	.../gas/config/tc-i386.c: In function ‘x86_ginsn_lea’:
	.../gas/config/tc-i386.c:5738:19: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
	   if (!i.base_reg != (!i.index_reg || i.index_reg->reg_num == RegIZ))
	                   ^~
	cc1: all warnings being treated as errors

		PR gas/31464
		* config/tc-i386.c (x86_ginsn_lea): Add "()" to silence GCC 6.4.

2024-03-08  Tom Tromey  <tom@tromey.com>

	Avoid race when reading dwz file
	PR gdb/31260 points out a race introduced by the background reading
	changes.  If a given objfile is re-opened when it is already being
	read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again,
	causing the 'dwz_file' to be reset.

	This patch fixes the problem by arranging to open the dwz just once:
	when the dwarf2_per_bfd object is created.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31260

2024-03-08  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Change the --with-mmap default to true
	Change the configure default to using mmap.

		* configure.ac: Change the --with-mmap default to true.
		* configure: Regenerated.

2024-03-08  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Don't hard-code BFD_JUMP_TABLE_COPY
	In BFD_JUMP_TABLE_COPY, replace _bfd_generic_init_private_section_data
	with NAME##_init_private_section_data so that ELF targets can properly
	replace it with _bfd_elf_init_private_section_data.

		* aout-target.h (MY_init_private_section_data): New.
		* coff-rs6000.c (_bfd_xcoff_init_private_section_data): New.
		* coffcode.h (coff_init_private_section_data): New.
		* elfxx-target.h (bfd_elfNN_init_private_section_data): New.
		* libecoff.h (_bfd_ecoff_init_private_section_data): New.
		* mach-o-target.c (bfd_mach_o_init_private_section_data): New.
		* mmo.c (mmo_init_private_section_data): New.
		* plugin.c (bfd_plugin_init_private_section_data): New.
		* ppcboot.c (ppcboot_init_private_section_data): New.
		* som.c (som_init_private_section_data): New.
		* targets.c (BFD_JUMP_TABLE_COPY): Replace
		_bfd_generic_init_private_section_data with
		NAME##_init_private_section_data.
		* vms-alpha.c (vms_init_private_section_data): New.
		* elf-bfd.h (_bfd_generic_init_private_section_data): Removed.
		* bfd-in2.h: Regenerated.

2024-03-08  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Support Zabha extension.
	The Zabha extension[1] supports for byte and halfword
	atomic memory operations. This patch add all instructions
	include in Zabha. Further work is waiting Zacas[2] merge.

	[1] https://github.com/riscv/riscv-zabha/tags
	[2] https://sourceware.org/pipermail/binutils/2023-May/127700.html

	Version log:
	Add new imply relation that Zabha extension implies A extension.

	bfd/ChangeLog:

	        * elfxx-riscv.c (riscv_implicit_subsets): New imply.
	        (riscv_multi_subset_supports): New extension.
	        (riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

	        * testsuite/gas/riscv/zabha-32.d: New test.
	        * testsuite/gas/riscv/zabha.d: New test.
	        * testsuite/gas/riscv/zabha.s: New test.

	include/ChangeLog:

	        * opcode/riscv-opc.h (MATCH_AMOADD_B): New opcodes.
	        (MASK_AMOADD_B): Ditto.
	        (MATCH_AMOXOR_B): Ditto.
	        (MASK_AMOXOR_B): Ditto.
	        (MATCH_AMOOR_B): Ditto.
	        (MASK_AMOOR_B): Ditto.
	        (MATCH_AMOAND_B): Ditto.
	        (MASK_AMOAND_B): Ditto.
	        (MATCH_AMOMIN_B): Ditto.
	        (MASK_AMOMIN_B): Ditto.
	        (MATCH_AMOMAX_B): Ditto.
	        (MASK_AMOMAX_B): Ditto.
	        (MATCH_AMOMINU_B): Ditto.
	        (MASK_AMOMINU_B): Ditto.
	        (MATCH_AMOMAXU_B): Ditto.
	        (MASK_AMOMAXU_B): Ditto.
	        (MATCH_AMOSWAP_B): Ditto.
	        (MASK_AMOSWAP_B): Ditto.
	        (MATCH_AMOADD_H): Ditto.
	        (MASK_AMOADD_H): Ditto.
	        (MATCH_AMOXOR_H): Ditto.
	        (MASK_AMOXOR_H): Ditto.
	        (MATCH_AMOOR_H): Ditto.
	        (MASK_AMOOR_H): Ditto.
	        (MATCH_AMOAND_H): Ditto.
	        (MASK_AMOAND_H): Ditto.
	        (MATCH_AMOMIN_H): Ditto.
	        (MASK_AMOMIN_H): Ditto.
	        (MATCH_AMOMAX_H): Ditto.
	        (MASK_AMOMAX_H): Ditto.
	        (MATCH_AMOMINU_H): Ditto.
	        (MASK_AMOMINU_H): Ditto.
	        (MATCH_AMOMAXU_H): Ditto.
	        (MASK_AMOMAXU_H): Ditto.
	        (MATCH_AMOSWAP_H): Ditto.
	        (MASK_AMOSWAP_H): Ditto.
	        (DECLARE_INSN): New declare.
	        * opcode/riscv.h (enum riscv_insn_class): New class.

	opcodes/ChangeLog:

	        * riscv-opc.c: New instructions.

2024-03-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-06  Nick Clifton  <nickc@redhat.com>

	Add "-j1" to make command lines in the create-a-release README.

2024-03-06  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix some test cases for TLS transition and relax

	LoongArch: Add dtpoff calculation function
	When tls_sec is NULL, we should not access the virtual address
	of tls_sec.

2024-03-06  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Delete extra instructions when TLS type transition
	This modification mainly changes the timing of type transition,
	adds relaxation to the old LE instruction sequence, and fixes
	bugs in extreme code models.

	We strictly distinguish between type transition and relaxation.
	Type transition is from one type to another, while relaxation
	is the removal of instructions under the same TLS type. Detailed
	instructions are as follows:

	1. For type transition, only the normal code model of DESC/IE
	does type transition, and each relocation is accompanied by a
	RELAX relocation. Neither abs nor extreme will do type transition,
	and no RELAX relocation will be generated.
	The extra instructions when DESC transitions to other TLS types
	will be deleted during the type transition.

	2. Implemented relaxation for the old LE instruction sequence.
	The first two instructions of LE's 32-bit and 64-bit models
	use the same relocations and cannot be distinguished based on
	relocations. Therefore, for LE's instruction sequence, any code
	model will try to relax.

	3. Some function names have been adjusted to facilitate understanding,
	parameters have been adjusted, and unused macros have been deleted.

2024-03-06  Alan Modra  <amodra@gmail.com>

	Don't use bfd_error_handler in bfd_abort
	We don't want to lose an abort message when bfd_set_error_handler has
	been called to ignore or cache errors.

		PR ld/31444
		* bfd.c (_bfd_abort): Don't use _bfd_error_handler.

2024-03-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix duplicate test names in gdb.trace/circ.exp
	This fixes some duplicate test names in gdb.trace/circ.exp when using
	native-gdbserver and native-extended-gdbserver boards.

	In this test we set the trace buffer size twice.  The same test name
	was used each time the size was adjusted.

	I've fixed this issue by:

	  1. Creating a new proc, set_trace_buffer_size, which factors out the
	  code to change the buffer size, and uses test names based on the
	  size we're setting the buffer too,

	  2. Calling the new proc each time we want to adjust the buffer size.

	After this the duplicate test names are resolved.  There should be no
	change in what is tested after this commit.

2024-03-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix some more duplicate test names in gdb.trace/
	This commit fixes some duplicate test names in the gdb.trace/
	directory when run with the native-gdbserver and
	native-extended-gdbserver boards.  In this case the duplicates relate
	to the calls to gdb_compile_pthreads which emits a fixed PASS message,
	as there are two calls to gdb_compile_pthreads we get a duplicate PASS
	message.

	In both cases the problem is fixed by adding a with_test_prefix around
	one of the compilations, however, I've made additional changes to
	clean up the tests a little while I was working on them:

	  1. Switch to use prepare_for_testing instead of
	  gdb_compile_pthreads.  By passing the 'pthreads' option this does
	  call gdb_compile_pthreads under the hood, but using the standard
	  compile function is cleaner,

	  2. Using prepare_for_testing removes the need to call clean_restart
	  immediately afterwards, so those calls are removed,

	  3. I removed the unneeded $executable and $expfile globals, where
	  the $executable global was used I've replaced this with $binfile,

	  4. When we compile two executables I've now given these different
	  names so that both exist at the end of the test run,

	  5. Removed a gdb_reinitialize_dir call, this is covered by
	  clean_restart,

	  6. Use gdb_test_no_output where it makes sense.

	I now see no duplicate test names when running these test scripts.
	There should be no change in what is being tested after this commit.

2024-03-05  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Add gas testsuit for LA32 relocations
	Test the relocation of the LA32 instruction set.

	LoongArch: Add gas testsuit for LA64 relocations
	Test the relocation of the LA64 instruction set.

	LoongArch: Add gas testsuit for LA32 int/float instructions
	Test the int/float instructions of LA32.

	LoongArch: Add gas testsuit for LA64 int/float instructions
	Test the int/float instructions of LA64.

	LoongArch: Add gas testsuit for lsx/lasx instructions
	Test the LSX/LASX instructions. Only LA64 supports
	these instructions.

	LoongArch: Add gas testsuit for lbt/lvz instructions
	Test the LBT/LVZ instructions. Only LA64 supports
	these instructions.

	LoongArch: Add gas testsuit for alias instructions
	Test the alias instructions.

2024-03-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-02  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35
	There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())"
	in find_register_by_number() when gdb connects to gdbserver, this
	is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains
	10 reserved regs) is different with the number of regs (35, which not
	contains 10 reserved regs) in file gdb/features/loongarch/base64.xml.
	Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to
	keep consistent with the gdb/features/loongarch/base64.xml, and then
	define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that
	all the reg numbers in regcache are consistent with tdesc reg numbers.

	without this patch:

	Execute on the target machine:

	  $ gdbserver 192.168.1.123:5678 ./test

	Execute on the host machine:

	  $ gdb ./test
	  (gdb) target remote 192.168.1.123:5678

	Output on the target machine:

	  Process ./test created; pid = 67683
	  Listening on port 5678
	  Remote debugging from host 192.168.1.136, port 6789
	  gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected.
	  find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed.

	Output on the host machine:

	  Remote debugging using 192.168.1.123:5678
	  Remote connection closed

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-03-02  Tom Tromey  <tom@tromey.com>

	Fix TUI text centering
	In a couple of spots, the TUI tries to center some text in the window.
	Andrew noticed that the calculation is done strangely and the text
	ends up somewhat to the left of center.

	This patch fixes the problem.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31355

2024-03-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-03-01  Will Hawkins  <hawkinsw@obs.cr>

	gdb/jit: Fix missing word in comment
	ChangeLog:

		* gdb/jit.c: Fix missing word in code comment.

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Be more verbose about missing operand type
	Provide expected operand type in s390-specific assembler operand parsing
	error message:

	"error: operand <operand-number>: missing <operand-type> operand"

	With <operand-type> being one of:
	- base register
	- displacement
	- [vector] index register
	- length
	- access register
	- control register
	- floating-point register
	- general-purpose register
	- vector register
	- [un]signed number

	gas/
		* config/tc-s390.c: Provide missing operand type in error
		message.
		* testsuite/gas/s390/zarch-base-index-0-err.l: Update test case
		result validation patterns to operand number in operand syntax
		error messages.
		* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Provide operand number in assembler warning and error messages
	Prepend the operand number "operand %d:" to the s390-specific assembler
	operand parsing warning and error messages.

	While at it reword the custom operand out of range error message text to
	be closer to the one used by as_bad_value_out_of_range(). Additionally
	reword the invalid FPR pair warning message to make it nicer.

	gas/
		* config/tc-s390.c: Print operand number in error messages.
		* testsuite/gas/s390/zarch-base-index-0-err.l: Update test case
		verification patterns to accept syntax error messages now
		containing the operand number.
		* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
		* testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise.
		* testsuite/gas/s390/zarch-z9-109-err.l: Likewise.
		* testsuite/gas/s390/zarch-z900-err.l: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Allow to explicitly omit base register operand in assembly
	The base register operand B may be omitted in D(B) by coding D and in
	D(L,B) by coding D(L). The index register operand X may be omitted in
	D(X,B) by coding D(B) or explicitly omitted by coding D(,B). In both
	cases the omitted base register operand value defaults to zero.

	Allow to explicitly omit the base register operand B in D(X,B) and
	D(L,B) by coding D(X,) and D(L,). Default the omitted base register
	operand value to zero.

	gas/
		* config/tc-s390.c: Allow to explicitly omit the base register
		operand in assembly.
		* NEWS: Mention that the base register now may be omitted on
		s390.
		* gas/testsuite/gas/s390/zarch-base-index-0.s: Update test cases
		for change to allow to explicitly omit the base register
		operand in assembly.
		* gas/testsuite/gas/s390/zarch-base-index-0.d: Likewise.
		* gas/testsuite/gas/s390/zarch-base-index-0-err.s: Likewise.
		* gas/testsuite/gas/s390/zarch-base-index-0-err.l: Likewise.
		* gas/testsuite/gas/s390/zarch-omitted-base-index.s: Likewise.
		* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
		* gas/testsuite/gas/s390/zarch-omitted-base-index-err.s:
		Likewise.
		* gas/testsuite/gas/s390/zarch-omitted-base-index-err.l:
		Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Print base register 0 as "0" in disassembly
	Base and index register 0 have no effect in address computation:

	"A value of zero in the B [base] or X [index] field specifies that no
	base or index is to be applied, and, thus, general register 0 cannot be
	designated as containing a base address or index."
	IBM z/Architecture Principles of Operation [1], chapter "Organization",
	section "General Registers".

	Index register 0 is omitted in the s390 disassembly. Base register 0 is
	omitted in D(B), D(L,B) and D(X,B) - the latter only if the index
	register is zero.

	To make it more apparent print base register 0 as "0" instead of "%r0",
	whenever it would still be printed in the disassembly.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	opcodes/
		* s390-dis.c: Print base register 0 as "0" in disassembly.

	binutils/
		* NEWS: Mention base register 0 now being printed as "0" in s390
		disassembly.

	gas/
		* testsuite/gas/s390/zarch-base-index-0.d: Update test case
		output verification patterns to accept "0" as base base
		register due to disassembler output format change.
		* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Warn when register name type does not match operand
	Print a warning message when the register type of a specified register
	name does not match with the operand's register type:

	operand {#}: expected {access|control|floating-point|general|vector}
	  register name [as {base|index} register]

	Introduce a s390-specific assembler option "warn-regtype-mismatch"
	with the values "strict", "relaxed", and "no" as well as an option
	"no-warn-regtype-mismatch" which control whether the assembler
	performs register name type checks and generates above warning messages.

	warn-regtype-mismatch=strict:
	  Perform strict register name type checks.

	warn-regtype-mismatch=relaxed:
	  Perform relaxed register name type checks, which allow floating-point
	  register (FPR) names %f0 to %f15 to be specified as argument to vector
	  register (VR) operands and vector register (VR) names %v0 to %v15 to
	  be specified as argument to floating-point register (FPR) operands.
	  This is acceptable as the FPRs are embedded into the lower halves of
	  the VRs. Make "relaxed" the default, as GCC generates assembler code
	  using FPR and VR interchangeably, which would cause assembler warnings
	  to be generated with "strict".

	warn-regtype-mismatch=no:
	no-warn-regtype-mismatch:
	  Disable any register name type checks.

	Tag .insn pseudo mnemonics as such, to skip register name type checks
	on those. They need to be skipped, as there do not exist .insn pseudo
	mnemonics for every possible operand register type combination. Keep
	track of the currently parsed operand number to provide it as reference
	in warning messages.

	To verify that the introduction of this change does not unnecessarily
	affect the compilation of existing code the GNU Binutils, GNU C Library,
	and Linux Kernel have been build with the new assembler, verifying that
	the assembler did not generate any of the new warning messages.

	gas/
		* config/tc-s390.c: Handle new assembler options
		"[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate
		parsed register expressions with register type. Keep track of
		operand number being parsed. Print warning message in case of
		register type mismatch between instruction operand and parsed
		register expression.
		* doc/as.texi: Document new s390-specific assembler options
		"[no-]warn-regtype-mismatch[=strict|relaxed|no]".
		* NEWS: Mention new s390-specific register name type checks and
		related assembler option "warn-regtype-mismatch=strict|
		relaxed|no".
		* testsuite/gas/s390/s390.exp: Add test cases for new assembler
		option "warn-regtype-mismatch={strict|relaxed}".
		* testsuite/gas/s390/esa-g5.s: Fix register types in tests for
		didbr, diebr, tbdr, and tbedr.
		* testsuite/gas/s390/zarch-z13.s: Fix register types in tests
		for vgef, vgeg, vscef, and vsceg.
		* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s:
		Tests for assembler option "warn-regtype-mismatch=strict".
		* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l:
		Likewise.
		* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s:
		Tests for assembler option "warn-regtype-mismatch=relaxed".
		* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l:
		Likewise.
		* gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update
		test cases for assembler option "warn-regtype-mismatch"
		defaulting to "relaxed".
		* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.

	include/
		* opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add
		instruction flag to tag .insn pseudo-mnemonics.

	opcodes/
		* s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as
		such.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Revise s390-specific assembler option descriptions
	Reorder, reword, and complete the s390-specific option descriptions.
	Align the formatting of s390-specific assembler options to that of the
	general assembler options in "as --help".

	While at it change a warning message to use the term "z/Architecture"
	instead of the deprecated "esame" (ESA Modal Extensions or ESAME) one.

	gas/
		* config/tc-s390.c: Revise s390-specific assembler option
		descriptions.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Add test case for disassembler option warn-areg-zero
	gas/
		* testsuite/gas/s390/s390.exp: Add test cases for s390-specific
		assembler option "warn-areg-zero".
		* testsuite/gas/s390/zarch-warn-areg-zero.s: Likewise.
		* testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Add test cases for base/index register 0
	While at it add comments to logic to omit base and/or index register 0
	in s390 disassembly.

	opcodes/
		* s390-dis.c: Add comments related to omitting base and/or index
		register 0 in disassembly.
	gas/
		* testsuite/gas/s390/s390.exp: Add test cases for base and/or
		index register 0.
		* testsuite/gas/s390/zarch-base-index-0.s: Add test cases for
		base and/or index register 0.
		* testsuite/gas/s390/zarch-base-index-0.d: Likewise.
		* testsuite/gas/s390/zarch-base-index-0-err.s: Add error test
		cases for base and/or index register 0.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Add comments to assembler operand parsing logic
	gas/
		* config/tc-s390.c: Add comments to assembler operand parsing
		logic.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Assemble processor specific test cases for their processor
	Assemble the esa-g5 test case with -march=g5.
	Assemble the zarch-z900 test case with -march=z900.

	gas/
		* testsuite/gas/s390/s390.exp: Assemble processor specific test
		cases for their respective processor (-march=<processor>).

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Correct setting of highgprs flag in ELF output
	The combination of an architecture size of 32 bits and z/Architecture
	mode requires the highgprs flag to be set in the ELF output. It causes
	the high-halves of the general purpose registers (GPRs) to be preserved
	at run-time, so that the code can use 64-bit GPRs.

	The architecture size of 32 bits can either be the default in case of
	a default architecture name of "s390" or due to specification of the
	option -m31 (to generate the 31-bit file format).
	The z/Architecture mode can either be the default or due to
	specification of the option -mzarch (to assemble for z/Architecture
	mode). It can also be selected using the pseudo commands
	".machinemode zarch" and ".machinemode zarch_nohighgprs". The latter
	not causing the highgprs flag to be set.

	The highgprs flag was only set when the following s390-specific
	assembler options were given in the following specific order:
	"-m31 -mzarch".

	The highgprs flag was erroneously not set when:
	- the order of above options was inverse (i.e. "-mzarch -m31"),
	- the architecture mode defaulted to z/Architecture mode and
	  option "-m31" was specified,
	- the architecture size defaulted to 32 bits due to a default
	  architecture name of "s390" and option -mzarch was specified,
	- the architecture size defaulted to 32 bits and the architecture
	  mode defaulted to z/Architecture due to the specified processor
	  (e.g. "-march=z900" or follow-on processor).

	Determine whether to set the highgprs flag in init_default_arch() after
	having processed all assembler options in md_parse_option(). This
	ensures the flag is set in all of the above cases it was erroneously not
	set. Add test cases for highgprs flag, including ones that use
	.machinemode to switch the architecture mode.

	gas/
		* config/tc-s390.c: Correct setting of highgprs flag in ELF
		output.
		* testsuite/gas/s390/s390.exp: Add test cases for highgprs
		flag.
		* testsuite/gas/s390/blank.s: Empty assembler source used in
		test cases for "highgprs" flag.
		* testsuite/gas/s390/esa-highgprs-0.d: Add test case for
		highgprs flag.
		* testsuite/gas/s390/zarch-highgprs-0.d: Likewise.
		* testsuite/gas/s390/zarch-highgprs-1.d: Likewise.
		* testsuite/gas/s390/esa-highgprs-machinemode-0.s: Add test case
		for highgprs flag when using .machinemode to switch
		architecture mode.
		* testsuite/gas/s390/esa-highgprs-machinemode-0.d: Likewise.
		* testsuite/gas/s390/esa-highgprs-machinemode-1.s: Likewise.
		* testsuite/gas/s390/esa-highgprs-machinemode-1.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Do not erroneously use base operand value for length operand
	The base register operand B may optionally be omitted in D(B) by coding
	D and in D(L,B) by coding D(L). The index register operand X may
	optionally be omitted in D(X,B) by coding D(,B) or D(B). Both base and
	index register operands may optionally be omitted in D(X,B) by coding D.
	In any case the omitted base and/or index register operand value
	defaults to zero.

	When parsing an erroneously omitted length L operand in D(L,B) by coding
	D(,B) the base register operand B was erroneously consumed as length
	operand. When using a register name for the base register operand this
	was detected and reported as error. But when not using a register name
	the base register operand value was erroneously used as length operand
	value.

	Correct the parsing of an omitted optional base or index register to not
	erroneously use the base register operand value as length, when
	erroneously omitting the length operand.

	While at it rename the variable used to remember whether the base or
	index register operand was omitted to enhance code readability.
	Additionally add test cases for the optional omission of base and/or
	index register operands.

	Example assembler source:
		mvc	16(1,%r1),32(%r2)
		mvc	16(1),32(%r2)
		mvc	16(,1),32(%r2)		# undetected syntax error

	Disassembly of bad assembly without commit shows the base register
	operand value was erroneously used as length operand value:
	   0:   d2 00 10 10 20 20       mvc     16(1,%r1),32(%r2)
	   6:   d2 00 00 10 20 20       mvc     16(1,%r0),32(%r2)
	   c:   d2 00 00 10 20 20       mvc     16(1,%r0),32(%r2)

	Assembler messages with commit:
	3: Error: operand 1: missing operand

	gas/
		* config/tc-s390.c: Correct parsing of omitted base register.
		* testsuite/gas/s390/s390.exp: Add test cases for omitted base
		and/or index register.
		* testsuite/gas/s390/zarch-omitted-base-index.s: Test cases for
		omitted optional base or index register.
		* testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
		* testsuite/gas/s390/zarch-omitted-base-index-err.s: Test cases
		for omitted base and/or index register.
		* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Enhance handling of syntax errors in assembler
	Do not consume any unexpected character including newline ('\n') when
	detecting a syntax error when parsing an operand block with parenthesis.
	This resolves the unfavorable assembler messages from the example below,
	including consuming the newline at the end of the current statement and
	reporting the next statement as junk.

	While at it change the only pre-increment of the current instruction
	string pointer into a post-increment to align with the other instances.

	Example assembler source:
		mvi	16(),32		# syntax error
		a	%r1,16(%r2	# syntax error
		a	%r1,16(%r2)
		mvc	16(1,),32(%r2)	# syntax error
		mvc	16(1,%r1,32(%r2	# syntax error

	Assembler messages without commit:
	1: Error: bad expression
	1: Error: syntax error; missing ')' after base register
	1: Error: syntax error; expected ','
	1: Error: junk at end of line: `32'
	2: Error: syntax error; missing ')' after base register
	2: Error: junk at end of line: `a %r1,16(%r2)'
	4: Error: bad expression
	4: Error: syntax error; missing ')' after base register
	4: Error: syntax error; expected ','
	4: Error: operand out of range (32 is not between 0 and 15)
	4: Error: syntax error; missing ')' after base register
	4: Error: junk at end of line: `%r2)'
	5: Error: syntax error; missing ')' after base register
	5: Error: syntax error; expected ','
	5: Error: operand out of range (32 is not between 0 and 15)
	5: Error: syntax error; missing ')' after base register
	5: Error: junk at end of line: `%r2'

	Assembler messages with commit:
	1: Error: bad expression
	1: Error: syntax error; missing ')' after base register
	2: Error: syntax error; missing ')' after base register
	4: Error: bad expression
	4: Error: syntax error; missing ')' after base register
	5: Error: syntax error; missing ')' after base register
	5: Error: syntax error; missing ')' after base register

	gas/
		* config/tc-s390.c: Do not erroneously consume newline when
		parsing an addressing operand with parentheses.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Lower severity of assembler syntax errors from fatal to error
	Report s390 assembler syntax errors as error instead of fatal error.
	This allows the assembler to continue and potentially report further
	syntax errors in the source. This should not cause syntax errors to
	be erroneously accepted, as both error and fatal error cause the
	assembler to return with a non-zero return code.

	The following syntax errors are changed from fatal to error:
	- invalid length field specified
	- odd numbered general purpose register specified as register pair
	- invalid floating point register pair.  Valid fp register pair operands
	  are 0, 1, 4, 5, 8, 9, 12 or 13.

	gas/
		* config/tc-s390.c: Lower severity of assembler syntax errors
		from fatal to error.
		* testsuite/gas/s390/zarch-z9-109-err.l: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Use proper string lengths when parsing opcode table flags
	opcodes/
		* s390-mkopc.c: Use proper string lengths when parsing opcode
		table flags.

	Fixes: c5306fed7d4 ("s390: Support for jump visualization in disassembly")
	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jens Remus  <jremus@linux.ibm.com>

	s390: Whitespace fixes in conditional branch flavor descriptions
	opcodes/
		* s390-mkopc.c: Whitespace fixes in conditional branch flavor
		descriptions.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2024-03-01  Jan Beulich  <jbeulich@suse.com>

	x86: adjust which Dwarf2 register numbers to use
	Consumers can't know which execution mode is in effect for a certain
	piece of code; they can only go from object file properties. Hence which
	register numbers to encode ought to depend solely on object file type.

	In tc_x86_frame_initial_instructions() do away with parsing a register
	name: We have a symbolic constant already for the 64-bit case, and the
	32-bit number isn't going to change either. Said constant's definition
	needs moving, though, to be available also for non-ELF. While moving
	also adjust the comment to clarify that it's applicable to 64-bit mode
	only.

2024-03-01  Jan Beulich  <jbeulich@suse.com>

	gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1
	... plus the SME part of B16B16. As per

	https://sourceware.org/pipermail/binutils/2024-February/132408.html

	SVE2.1 support is both incomplete and buggy. SME2.1 "support" goes as
	far as a single instruction (a subset of movaz forms) only. The SME part
	of B16B16 is entirely missing.

2024-03-01  Jan Beulich  <jbeulich@suse.com>

	x86/APX: honor -mevexwig= for byte-size insns
	These uniformly ignore EVEX.W, and hence what we emit ought to be
	controllable by the command line option.

	x86/APX: optimize certain XOR and SUB forms
	While most logic in optimize_encoding() is already covering APX by way
	of the earlier NDD->REX2 conversion, there's a remaining set of cases
	which wants handling separately.

	x86/APX: correct .insn opcode space determination when REX2 is needed
	In this case spaces 0f38 and 0f3a may not be put in place. To achieve
	the intended effect, operand parsing (but not operand processing) needs
	pulling ahead, so we know whether eGRP-s are in use.

2024-03-01  Jan Beulich  <jbeulich@suse.com>

	x86/APX: respect {vex}/{vex3}
	Even when an EVEX encoding is available, use of such a prefix ought to
	be respected (resulting in an error) rather than ignored. As requested
	during review already, introduce a new encoding enumerator to record use
	of eGPR-s, and update state transitions accordingly.

	The optimize_encoding() change also addresses an internal assembler
	error that was previously raised when respective memory operands used
	eGPR-s for addressing.

	While this results in a change of diagnostic issued for VEX-encoded
	insns, the new one is at least no worse than the prior one.

2024-03-01  Tom Tromey  <tom@tromey.com>

	Use DW_FORM_ref_addr for DIE offset in .debug_names
	Today I realized that while the .debug_names writer uses DW_FORM_udata
	for the DIE offset, DW_FORM_ref_addr would be more appropriate here.
	This patch makes this change.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31361

2024-03-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-29  Alan Modra  <amodra@gmail.com>

	PR19871, description of --pie
	Say why we even mention shared libraries here (ET_DYN), and clarify
	symbol resolution.  There are of course many other ways that PIEs
	resemble PDEs more closely than shared libraries.

		PR 19871
		* ld.texi (-pie): Clarify.

2024-02-29  Tom Tromey  <tom@tromey.com>

	Synchronize GCC compile plugin headers
	This patch copies some changes to the compile headers from GCC's
	include/ directory.  It is the gdb equivalent of the GCC commit
	bc0e18a9 -- however, while that commit also necessarily touched
	libcc1, this one of course does not.

	Tested by rebuilding and also running the gdb.compile tests.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397

2024-02-29  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Fix the 2nd operand in gcsstr and gcssttr instructions.
	The assembler wrongly expects plain register name instead of
	memory-form 2nd operand for gcsstr and gcssttr instructions.
	This patch fixes the issue.

2024-02-29  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix stray KeyboardInterrupt after cancel
	When running test-case gdb.dap/pause.exp 100 times in a loop, it passes
	100/100.

	But if we remove the two "sleep 0.2" from the test-case, we run into
	(copied from dap.log and edited for readability):
	...
	Traceback (most recent call last):
	  File "startup.py", line 251, in message
	    def message():

	KeyboardInterrupt
	Quit
	...

	This happens as follows.

	CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight.

	The idea is that this interrupt triggers while in fn here in message (a nested
	function of send_gdb_with_response):
	...
	    def message():
	        try:
	            val = fn()
	            result_q.put(val)
	        except (Exception, KeyboardInterrupt) as e:
	            result_q.put(e)
	...
	but instead it triggers outside the try/except.

	Fix this by:
	- in CancellationHandler, renaming variable in_flight to in_flight_dap_thread,
	  and adding a variable in_flight_gdb_thread to be able to distinguish when
	  a request is in flight in the dap thread or the gdb thread.
	- adding a wrapper Cancellable to to deal with cancelling the wrapped
	  event
	- using Cancellable in send_gdb and send_gdb_with_response to wrap the posted
	  event
	- in CancellationHandler.cancel, only call gdb.interrupt if
	  req == self.in_flight_gdb_thread.

	This makes the test-case pass 100/100, also when adding the extra stressor of
	"taskset -c 0", which makes the fail more likely without the patch.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR dap/31275
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275

2024-02-29  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Move send_gdb and send_gdb_with_response to server module
	Move functions send_gdb and send_gdb_with_response, as well as class Invoker
	to server module.

	Separated out to make the following patch easier to read.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-29  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions
	Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro
	register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which
	adds the tpidruro register, and unconditionally enabled it in
	aarch32_create_target_description.

	In Linux, the tpidruro register isn't available via ptrace in the 32-bit
	kernel but it is available for an aarch32 program running under an arm64
	kernel via the ptrace compat interface.  This isn't currently implemented
	however, which causes GDB on arm-linux with 64-bit kernel to list the
	register but show it as unavailable, as reported by Tom de Vries:

	  $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
	  Temporary breakpoint 1 at 0x512

	  Temporary breakpoint 1, 0xaaaaa512 in main ()
	  $1 = <unavailable>

	Simon Marchi then clarified:

	> The only time we should be seeing some "unavailable" registers or memory
	> is in the context of tracepoints, for things that are not collected.
	> Seeing an unavailable register here is a sign that something is not
	> right.

	Therefore, disable the TLS feature in aarch32 target descriptions for Linux
	and NetBSD targets (the latter also doesn't seem to support accessing
	tpidruro either, based on a quick look at arm-netbsd-nat.c).

	This patch fixes the following tests:

	Running gdb.base/inline-frame-cycle-unwind.exp ...
	FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3
	FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5
	FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1

	Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native,
	native-gdbserver and native-extended-gdbserver targets with no regressions.

	PR tdep/31418
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-02-29  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Add ATTRIBUTE_HIDDEN to x86 internal functions
		* elfxx-x86.h: Add ATTRIBUTE_HIDDEN to internal functions.
		* libbfd-in.h (_bfd_get_link_info): Add ATTRIBUTE_HIDDEN.
		* libbfd.h: Regenerated.

2024-02-29  Alan Modra  <amodra@gmail.com>

	PR21739, Inconsistent diagnostics
		PR 21739
	cpu/
		* mep.opc (parse_lo16, parse_unsigned7): Mark %function
		message as no-c-format.
	opcodes/
		* mep-asm.c: Regenerate.

2024-02-29  Tatsuyuki Ishi  <ishitatsuyuki@gmail.com>

	RISC-V: Initial ld.bfd support for TLSDESC.
	Only relocation handling for now; relaxation is not implemented yet.

	bfd/
	    * elfnn-riscv.c (riscv_elf_check_relocs): Record GOT reference and
	    paired relocation for TLSDESC_HI20.
	    (riscv_elf_adjust_dynamic_symbol): Allocate GOT and reloc slots for
	    TLSDESC symbols.
	    (riscv_elf_size_dynamic_sections): Likewise but for local symbols.
	    (tlsdescoff): New helper to determine static addend for R_TLSDESC.
	    (riscv_elf_relocate_section): Ignore TLSDESC_CALL reloc for now (it is
	    relaxation only).
	    Handle TLSDESC_{LOAD,ADD}_LO12 as paired pcrel relocs.
	    For TLS GOT slot generation, generalize the logic to handle any
	    combination of (GD, IE, TLSDESC).
	    Add TLSDESC Rela generation.
	    * ld/testsuite/ld-riscv-elf/tls*: Add TLSDESC instruction sequences
	    next to the existing GD and IE sequences. Update expectations.

2024-02-29  Tatsuyuki Ishi  <ishitatsuyuki@gmail.com>

	RISC-V: Define and use GOT entry size constants for TLS.
	As the size calculation is split by global and local symbols, using a
	shared constant definition for its size improves clarity.

	bfd/
	    * elfnn-riscv.c: Add macros for sizes of a normal GOT entry, TLS GD and
	    TLS IE entry.
	    (allocate_dynrelocs): Replace GOT size expressions with the new
	    constants.
	    (riscv_elf_size_dynamic_sections): Likewise.
	    (riscv_elf_relocate_section): Likewise.

2024-02-29  Tatsuyuki Ishi  <ishitatsuyuki@gmail.com>

	RISC-V: Add assembly support for TLSDESC.
	gas/
	    * tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi,
	    %tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype
	    renamed to percent_op_relax_only as this matcher is extended to handle
	    jalr as well which is not R-type.
	    (riscv_ip): Apply the percent_op_relax_only rename and update comment.
	    (md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to
	    TLS relocation check list.
	    * testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation
	    generation.
	opcodes/
	    * riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with
	    %tlsdesc_call annotations.

	RISC-V: Add TLSDESC reloc definitions.
	bfd/
	    * elfxx-riscv.c: Add 5 TLSDESC reloc descriptions.
	    * reloc.c: Likewise.
	    * libbfd.h: Regenerate.
	    * bfd-in2.h: Regenerate.
	include/
	    * elf/riscv.h: Add 5 TLSDESC reloc descriptions.

2024-02-29  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	gprofng: change use of bignum to use of bigint
	Change the statement "use bignum" to "use bigint".  This is sufficient
	for gp-display-html to work and removes the dependency on bignum.

	gprofng/ChangeLog
	2024-02-27  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		PR 31390
		* gprofng/gp-display-html: One line change to "use bigint".

2024-02-29  John Baldwin  <jhb@FreeBSD.org>

	aarch64: Use aarch64_debug_printf in a few more places
	No functional change

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-02-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-28  Alan Modra  <amodra@gmail.com>

	PR23877, bad value (n32r5900) for default CPU
	Catching this at configure time would be nicer, but we'd need to exactly
	match mips_parse_cpu in configure.ac and keep it all in sync.

		PR 23877
		* config/tc-mips.c (mips_after_parse_args): Don't assert that
		mips_parse_cpu returns non-NULL, call as_fatal with an informative
		message instead.

2024-02-28  Vladislav Belov  <vladislav.belov@syntacore.com>

	Fix implementation of SUBALIGN.

2024-02-28  Tom Tromey  <tromey@adacore.com>

	Fix gdb.interrupt race
	gdb.interrupt was introduced to implement DAP request cancellation.
	However, because it can be run from another thread, and because I
	didn't look deeply enough at the implementation, it turns out to be
	racy.

	The fix here is to lock accesses to certain globals in extension.c.

	Note that this won't work in the case where configure detects that the
	C++ compiler doesn't provide thread support.  This version of the
	patch disables DAP entirely in this situation.

	Regression tested on x86-64 Fedora 38.  I also ran gdb.dap/pause.exp
	in a thread-sanitizer build tree to make sure the reported race is
	gone.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31263

2024-02-28  Alan Modra  <amodra@gmail.com>

	PR23881, pdp11 binutils fails if too much debug data
	The PR testcase overflows one of the exec header fields, e_syms (the
	size of the symbol table), leading to the string table offset being
	wrong.  Things go downhill from there.  Fixed by checking for
	overflow.  This happens to trigger in the ld testsuite, so xfail that
	test.

		PR 23881
	bfd/
		* libaout.h (swap_exec_header_out): Return a bool.
		* aoutx.h (swap_exec_header_out): Check for overflow in exec
		header.
		* pdp11.c (swap_exec_header_out): Likewise.
		* i386lynx.c (WRITE_HEADERS): Adjust.
	ld/
		* testsuite/ld-scripts/map-address.exp: xfail pdp11.

2024-02-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Two minor addrmap cleanups
	While working on a different patch, I found a couple of simple addrmap
	cleanups.

	In one case, a forward declaration is no longer needed, as the header
	now includes addrmap.h.

	In the other, an include of addrmap.h is no longer needed.

	Tested by rebuilding.

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Explicitly quit gdb from DAP server thread
	This changes the DAP code to explicitly request that gdb exit.
	Previously this could cause crashes, but with the previous cleanups,
	this should no longer happen.

	This also adds a tests that ensures that gdb exits with status 0.

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Add final cleanup for runnables
	This changes run-on-main-thread.c to clear 'runnables' in a final
	cleanup.  This avoids an issue where a pending runnable could require
	Python, but be run after the Python interpreter was finalized.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31172

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Change finalize_values into a final cleanup
	This removes finalize_values in favor of adding a new final cleanup.
	This is safe now that extension languages are explicitly shut down.

	Add extension_language_ops::shutdown
	Right now, Python is shut down via a final cleanup.  However, it seems
	to me that it is better for extension languages to be shut down
	explicitly, after all the ordinary final cleanups are run.  The main
	reason for this is that a subsequent patch adds another case like
	finalize_values; and rather than add a series of workarounds for
	Python shutdown, it seemed better to let these be done via final
	cleanups, and then have Python shutdown itself be the special case.

	Rewrite final cleanups
	This patch rewrites final cleanups to use std::function and otherwise
	be more C++-ish.

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Use the .py file in gdb.dap/pause.exp
	Tom de Vries pointed out that the gdb.dap/pause.exp test writes a
	Python file but then does not use it.  This patch corrects the
	oversight.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354
	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Rewrite "python" command exception handling
	The "python" command (and the Python implementation of the gdb
	"source" command) does not handle Python exceptions in the same way as
	other gdb-facing Python code.  In particular, exceptions are turned
	into a generic error rather than being routed through
	gdbpy_handle_exception, which takes care of converting to 'quit' as
	appropriate.

	I think this was done this way because PyRun_SimpleFile and friends do
	not propagate the Python exception -- they simply indicate that one
	occurred.

	This patch reimplements these functions to respect the general gdb
	convention here.  As a bonus, some Windows-specific code can be
	removed, as can the _execute_file function.

	The bulk of this change is tweaking the test suite to match the new
	way that exceptions are displayed.  These changes are largely
	uninteresting.  However, it's worth pointing out the py-error.exp
	change.  Here, the failure changes because the test changes the host
	charset to something that isn't supported by Python.  This then
	results in a weird error in the new setup.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354
	Acked-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Fix formatting buglet in python.c
	python.c has a split string that is missing a space.  There's also a
	stray backslash in this code.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-02-27  Tom Tromey  <tromey@adacore.com>

	Introduce read_remainder_of_file
	This patch adds a new function, read_remainder_of_file.  This is like
	read_text_file_to_string, but reads from an existing 'FILE *'.  This
	will be used in a subsequent patch.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-02-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Reset errcnt and warncnt in default_gdb_init
	Say we do:
	...
	$ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp"
	...
	and add a perror at the end of pause.exp:
	...
	 dap_shutdown
	+
	+perror "foo"
	...

	We run into:
	...
	UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb
	...

	This happens because the perror increases the errcnt, which is not reset at
	the end of the test-case, and consequently the first pass in the following
	test-case is changed into an unresolved.

	Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the
	end of the test-case, which does reset the errcnt, but this is with version
	1.6.1.

	Furthermore, we reset the errcnt in clean_restart, but the pass is produced
	before, so that doesn't help either.

	Fix this by resetting errcnt and warncnt in default_gdb_init.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31351
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351

2024-02-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove KFAIL for PR ada/30908
	PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by
	commit d56fdf1b976 ("Refine Ada overload matching").

	Remove the KFAILs for PR ada/30908.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908

2024-02-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp
	With test-case gdb.python/py-finish-breakpoint.exp, we run into:
	...
	(gdb) python print (finishbp_default.hit_count)
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	RuntimeError: Breakpoint 3 is invalid.
	Error while executing Python code.
	(gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \
	  check finishBP on default frame has been hit
	...

	The test producing the pass is:
	...
	    gdb_test "python print (finishbp_default.hit_count)" "1.*" \
	      "check finishBP on default frame has been hit"
	...
	so the pass is produced because the 1 in "line 1" matches "1.*".

	Temporary breakpoints are removed when hit, and consequently accessing the
	hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is
	not possible, and as per spec we get a RuntimeError.

	So the RuntimeError is correct, and not specific to finish breakpoints.

	The test presumably attempts to match:
	...
	(gdb) python print (finishbp_default.hit_count)
	1
	...
	but most likely this output was never produced by any gdb version.

	Fix this by checking whether the finishbp_default breakpoint has hit by
	checking that finishbp_default.is_valid() is False.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31391
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391

2024-02-27  Pedro Alves  <pedro@palves.net>

	Cygwin: Fix putting inferior in foreground (fix input)
	gdb.base/interrupt.exp reveals that inferior input is
	broken on Cygwin:

	  (gdb) continue
	  Continuing.
	  talk to me baby
	  Input/output error                                   <<< BAD
	  PASS: gdb.base/interrupt.exp: process is alive
	  a
	  [Thread 10688.0x2590 exited with code 1]
	  [Thread 10688.0x248c exited with code 1]
	  [Thread 10688.0x930 exited with code 1]
	  [Thread 10688.0x2c98 exited with code 1]

	  Program terminated with signal SIGHUP, Hangup.
	  The program no longer exists.
	  (gdb) FAIL: gdb.base/interrupt.exp: child process ate our char
	  a
	  Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior...
	  (gdb) ERROR: "" is not a unique command name.

	The problem is that inflow.c:child_terminal_inferior is failing to put
	the inferior in the foreground, because we're passing down the
	inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp.

	That is fixed by this commit.  Afterwards we will get:

	  (gdb) continue
	  Continuing.
	  talk to me baby
	  PASS: gdb.base/interrupt.exp: process is alive
	  a
	  a                                                              <<< GOOD
	  PASS: gdb.base/interrupt.exp: child process ate our char
	  [New Thread 7236.0x1c58]

	  Thread 6 received signal SIGINT, Interrupt.                    <<< new thread spawned for SIGINT
	  [Switching to Thread 7236.0x1c58]
	  0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
	  (gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C

	We still have the FAIL seen above because this change has another
	consequence.  By failing to put the inferior in the foreground
	correctly, Ctrl-C was always reaching GDB first.  Now that the
	inferior is put in the foreground properly, Ctrl-C reaches the
	inferior first, which results in a Windows Ctrl-C event, which results
	in Windows injecting a new thread in the inferior to report the Ctrl-C
	exception => SIGINT.  That is, running the test manually:

	Before patch:

	  (gdb) c
	  Continuing.
	  [New Thread 2352.0x1f5c]
	  [New Thread 2352.0x1988]
	  [New Thread 2352.0x18cc]
	                                                           <<< Ctrl-C pressed.
	  Thread 7 received signal SIGTRAP, Trace/breakpoint trap.
	  [Switching to Thread 2352.0x18cc]
	  0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
	  (gdb)

	Above, GDB got the SIGINT, and it manually passes it down the
	inferior, which reaches windows_nat_target::interrupt(), which
	interrupts the inferior with DebugBreakProcess (which injects a new
	thread in the inferior that executes an int3 instruction).

	After this patch, we have (with "set debugexceptions on" so
	DBG_CONTROL_C is visible):

	  (gdb) c
	  Continuing.
	  [New Thread 9940.0x1168]
	  [New Thread 9940.0x5f8]
	  gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
	  gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
	  [New Thread 9940.0x3d8]
	  gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b   <<< Ctrl-C

	  Thread 7 received signal SIGINT, Interrupt.             <<< new injected thread
	  [Switching to Thread 9940.0x3d8]
	  0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
	  (gdb)

	This new behavior is exactly the same as what you see with a MinGW GDB
	build.  Also, SIGINT reaching inferior first is what you get on Linux
	as well currently.

	I wrote an initial fix for this before I discovered that Cygwin
	downstream had a similar change, so I then combined the patches.  I am
	adding a Co-Authored-By for that reason.

	Co-Authored-By: Takashi Yano <takashi.yano@nifty.ne.jp>
	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f

2024-02-27  Andreas Krebbel  <krebbel@linux.ibm.com>

	s390: Add r_offset check to the weak undef change
	Since we are accessing up to 2 bytes before the relocation target we
	should better make sure there are actually 2 bytes before it.

	ChangeLog:

		* bfd/elf64-s390.c (elf_s390_relocate_section): Make sure
		rel->r_offset is large enough.

2024-02-27  Yuriy Kolerov  <kolerov93@gmail.com>

	arc: Don't build arc-analyze-prologue.S with -g
	arc-analyze-prologue.S test does not contain debug information thus
	it must be compiled without -g option. Otherwise GDB will try to
	unwind frames using debug information (which does not exist for .S
	code!) instead of analyzing frames manually.

	Approved-By: Shahab Vahedi <shahab@synopsys.com>

2024-02-27  Andreas Krebbel  <krebbel@linux.ibm.com>

	s390: Avoid reloc overflows on undefined weak symbols
	Replace relative long addressing instructions of weak symbols, which
	will definitely resolve to zero, with either a load address of 0, a
	NOP, or a trapping insn.

	This prevents the PC32DBL relocation from overflowing in case the
	binary will be loaded at 4GB or more.

	bfd/ChangeLog:

		* bfd/elf64-s390.c (elf_s390_relocate_section): Replace
		instructions using undefined weak symbols with relative addressing
		to avoid relocation overflows.

	ld/ChangeLog:
		* ld/testsuite/ld-s390/s390.exp:
		* ld/testsuite/ld-s390/8GB.ld: New test.
		* ld/testsuite/ld-s390/weakundef-1.dd: New test.
		* ld/testsuite/ld-s390/weakundef-1.s: New test.

2024-02-27  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: rename internals related to PAuth feature to use pauth in their naming for coherency
	Hi,

	Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion.

	Regression tested on aarch64-none-elf, and no regression found.

	Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.

	Regards,
	Matthieu.
	From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001
	From: Matthieu Longo <matthieu.longo@arm.com>
	Date: Fri, 23 Feb 2024 11:30:40 +0000
	Subject: [PATCH] aarch64: rename internals related to PAuth feature to use
	 pauth in their naming for coherency

	Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature
	with internal names that don't match the actual feature name pauth. The new
	feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature
	of Armv8.3-A. Using a different naming for it not based on the formerly "PAC"
	would create confusion.

2024-02-27  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Run overflow testcases only on LoongArch target

2024-02-27  ticat_fp  <fanpeng@loongson.cn>

	LoongArch: Modify inconsistent behavior of ld with --unresolved-symbols=ignore-all
	Remove duplicated check when producing executable files that reference external symbols
	defined in other files. RELOC_FOR_GLOBAL_SYMBOL will check it.

	Testcase is:
	resolv.c:
	int main(int argc, char *argv[]) {
	    return argc;
	}

	t.c:

	extern const struct my_struct ms1;
	static const struct my_struct *ms = &ms1;

	t.h:
	typedef struct my_struct {
	    char *str;
	    int i;
	} my_struct;

	Compiling and linking command with:
	gcc t.c -c ; gcc resolv.c -c
	gcc resolv.o t.o -o resolv -Wl,--unresolved-symbols=ignore-all

	Got error as:
	~/install/usr/bin/ld: t.o:(.data.rel+0x0): undefined reference to `ms1'
	collect2: error: ld returned 1 exit status

2024-02-27  Jinyang He  <hejinyang@loongson.cn>

	Avoid unused space in .rela.dyn if sec was discarded
	The relsec size is still increased although sec is discarded, which
	cause a lot of unused space allocated. Avoid size increased if sec
	was discarded.

	bfd/ChangeLog:

		* bfd/elfnn-loongarch.c: (allocate_dynrelocs): Do not increase
		sreloc size when discarded_section.

	ld/ChangeLog:

		* ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test.
		* ld/testsuite/ld-loongarch-elf/pie_discard.d: New test.
		* ld/testsuite/ld-loongarch-elf/pie_discard.s: New test.
		* ld/testsuite/ld-loongarch-elf/pie_discard.t: New test.

2024-02-27  Jinyang He  <hejinyang@loongson.cn>

	LoongArch: ld: Fix other pop relocs overflow check and add tests
	Add reloc_unsign_bits() to fix others sop_pop relocs overflow check.
	Then add over/underflow tests for relocs B*, SOP_POP* and PCREL20_S2.

	bfd/ChangeLog:

		* bfd/elfxx-loongarch.c: Add reloc_unsign_bits().

	ld/ChangeLog:

		* ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add tests.
		* ld/testsuite/ld-loongarch-elf/abi1_max_imm.dd: New test.
		* ld/testsuite/ld-loongarch-elf/abi1_max_imm.s: New test.
		* ld/testsuite/ld-loongarch-elf/abi1_sops.s: New test.
		* ld/testsuite/ld-loongarch-elf/abi2_max_imm.s: New test.
		* ld/testsuite/ld-loongarch-elf/abi2_overflows.s: New test.
		* ld/testsuite/ld-loongarch-elf/max_imm_b16.d: New test.
		* ld/testsuite/ld-loongarch-elf/max_imm_b21.d: New test.
		* ld/testsuite/ld-loongarch-elf/max_imm_b26.d: New test.
		* ld/testsuite/ld-loongarch-elf/max_imm_pcrel20.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_b16.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_b21.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_b26.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_pcrel20.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_0_10_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_0_5_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_10_12.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_10_16.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_10_5.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_s_5_20.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_u.d: New test.
		* ld/testsuite/ld-loongarch-elf/overflow_u_10_12.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_b16.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_b21.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_b26.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_pcrel20.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_0_10_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_0_5_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_10_12.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_10_16.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_10_16_s2.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_10_5.d: New test.
		* ld/testsuite/ld-loongarch-elf/underflow_s_5_20.d: New test.

2024-02-27  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: bfd: Fix some bugs of howto table
	R_LARCH_IRELATIVE: For dynamic relocation that does not distinguish between
	32/64 bits, size and bitsize set to 8 and 64.
	R_LARCH_TLS_DESC64: Change size to 8.
	R_LARCH_SOP_POP_32_S_0_5_10_16_S2: Change src_mask to 0, dst_mask to
	0x03fffc1f.

2024-02-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amd-dbgapi: fix indentation
	Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0

2024-02-26  Tom Tromey  <tromey@adacore.com>

	Remove two unnecessary casts
	I noticed a spot in ada-lang.c where the return value of
	value_as_address was cast to CORE_ADDR -- a no-op cast.  I searched
	and found another.  This patch fixes both.

2024-02-26  Pedro Alves  <pedro@palves.net>

	[gdb] Fix heap-use-after-free in select_event_lwp
	PR gdb/31259 reveals one scenario where we run into a
	heap-use-after-free reported by thread sanitizer, while running
	gdb.base/vfork-follow-parent.exp.

	The heap-use-after-free happens during the following scenario:

	 - linux_nat_wait_1 is about to return an event for T2.  It stops all
	   other threads, and while doing so, stop_wait_callback -> wait_lwp
	   sees T1 exit, and decides to leave the exit event pending.  It
	   should have set the lp->stopped flag too, but does not -- this is
	   the bug.

	 - The event for T2 is reported, is processed by infrun, and we're
	   back at linux_nat_wait_1.

	 - linux_nat_wait_1 selects LWP T1 with the pending exit status to
	   report.

	 - it sets variable lp to point to the corresponding lwp_info.

	 - it calls stop_callback and stop_wait_callback for all threads
	   (because !target_is_non_stop_p ()).

	 - it calls select_event_lwp to maybe pick another thread than T1, to
	   prevent starvation.

	The problem is the following:

	 - while calling stop_wait_callback for all threads, it also does this
	   for T1.  While doing so, the corresponding lwp_info is deleted
	   (callstack stop_wait_callback -> wait_lwp -> exit_lwp ->
	   delete_lwp), leaving variable lp as a dangling pointer.

	 - variable lp is passed to select_event_lwp, which derefences it,
	   which causes the heap-use-after-free.

	Note that the comment here mentions "all other LWP's":
	...
	      /* Now stop all other LWP's ...  */
	      iterate_over_lwps (minus_one_ptid, stop_callback);
	      /* ... and wait until all of them have reported back that
	        they're no longer running.  */
	      iterate_over_lwps (minus_one_ptid, stop_wait_callback);
	...

	The reason the comments say "all other LWP's", and doesn't bother
	filtering out LP is that lp->stopped should be true at this point, and
	the callbacks (both stop_callback and stop_wait_callback) check that
	flag, and do nothing if set.  I.e., they skip already-stopped threads,
	so they should skip LP.

	In this particular scenario, though, we missed setting the stopped
	flag right in the first step described above, so LP was iterated over
	incorrectly.

	The fix is to make wait_lwp set the lp->stopped flag when it decides
	to leave the exit event pending.  However, going a bit further,
	gdbserver has a mark_lwp_dead function to centralize setting up
	various lwp flags such that the rest of the code doesn't mishandle
	them, and it seems like a good idea to do a similar thing in gdb as
	well.  That is what this patch does.

	PR gdb/31259
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31259
	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9

2024-02-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Dump dap.log.$n to gdb.log when exceptions found
	For a patch I submitted, the Linaro CI reported a failure:
	...
	FAIL: gdb.dap/attach.exp: exceptions in log file
	...

	I ran the test-case locally, and observed the same FAIL in the gdb.sum file.

	I then wanted to confirm that I reproduced the exact same problem, but
	realized that I couldn't because there's no way for me to know what exception
	occurred, and where, because that information is logged in the dap.log.$n
	file, and the Linaro CI only saves the gdb.sum and gdb.log files.

	This issue is even worse if only the CI can reproduce a FAIL.

	Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when
	exceptions are found.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Further handle long filenames in gdb.base/startup-with-shell.exp
	In commit 52498004a34 ("gdb/testsuite: handle long filenames in
	gdb.base/startup-with-shell.exp") we fixed a FAIL reported by the Linaro CI:
	...
	(gdb) print argv[1]
	$1 = 0xfffed978 "<snip>/startup-with-shell/unique-file.unique-e"...
	(gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; \
	  run_args = *.unique-extension: first argument expanded
	...

	PR testsuite/31410 reports a similar failure:
	...
	(gdb) print argv[1]
	$1 = 0xfffeda96 "<snip>/startup-with-shell/*.unique-extens"...
	(gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = off; \
	  run_args = *.unique-extension: first argument not expanded
	...

	Fix this in the same way, using "set print characters unlimited".

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410

2024-02-26  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix "value is not available" with debug frame
	On arm-linux, with a started hello world, running "info frame" works fine, but
	when I set debug frame to on, I run into:
	...
	(gdb) info frame
	  ...
	[frame] frame_unwind_register_value: exit
	value is not available
	(gdb)
	...

	The problem is here in frame_unwind_register_value:
	...
	          if (value->lazy ())
	            gdb_printf (&debug_file, " lazy");
	          else
	            {
	              int i;
	              gdb::array_view<const gdb_byte> buf = value->contents ();
	...
	where we call value->contents () while !value->entirely_available ().

	Fix this by checking value->entirely_available () and printing:
	...
	    [frame] frame_unwind_register_value:   -> register=91 unavailable
	...

	Tested on arm-linux.

	PR gdb/31369
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31369

2024-02-26  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: Modify the output of "info breakpoints" and "delete breakpoints"
	The output of "info breakpoints" includes breakpoint, watchpoint,
	tracepoint, and catchpoint if they are created, so it should show
	all the four types are deleted in the output of "info breakpoints"
	to report empty list after "delete breakpoints".

	It should also change the output of "delete breakpoints" to make it
	clear that watchpoints, tracepoints, and catchpoints are also being
	deleted. This is suggested by Guinevere Larsen, thank you.

	$ make check-gdb TESTS="gdb.base/access-mem-running.exp"
	$ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running
	[...]
	(gdb) break main
	Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32.
	(gdb) watch global_counter
	Hardware watchpoint 2: global_counter
	(gdb) trace maybe_stop_here
	Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27.
	(gdb) catch fork
	Catchpoint 4 (fork)
	(gdb) info breakpoints
	Num     Type           Disp Enb Address            What
	1       breakpoint     keep y   0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32
	2       hw watchpoint  keep y                      global_counter
	3       tracepoint     keep y   0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27
		not installed on target
	4       catchpoint     keep y                      fork

	Without this patch:

	(gdb) delete breakpoints
	Delete all breakpoints? (y or n) y
	(gdb) info breakpoints
	No breakpoints or watchpoints.
	(gdb) info breakpoints 3
	No breakpoint or watchpoint matching '3'.

	With this patch:

	(gdb) delete breakpoints
	Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y
	(gdb) info breakpoints
	No breakpoints, watchpoints, tracepoints, or catchpoints.
	(gdb) info breakpoints 3
	No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'.

	Approved-by: Kevin Buettner <kevinb@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-02-26  Andreas Arnez  <arnez@linux.ibm.com>

	gdb: s390: Add arch14 record/replay support
	Enable recording of the new "arch14" instructions on z/Architecture
	targets, except for the specialized-function-assist instruction NNPA.

2024-02-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Add hardware counter profiling for the Ampere system
	gprofng should recognize Ampere and other ARM systems.

	gprofng/ChangeLog
	2024-02-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* common/hwc_cpus.h: Declare the enum values ARM_CPU_IMP_*.
		* common/core_pcbe.c (core_pcbe_init): Accept new systems ARM_CPU_IMP_*.

2024-02-26  Jinyang He  <hejinyang@loongson.cn>

	LoongArch: bfd: Correct the name of R_LARCH_SOP_POP_32_U in howto_table

2024-02-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-24  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix static cast of virtual base
	With this change in bfd/development.sh:
	...
	-development=true
	+development=false
	...
	we run into:
	...
	In file included from tui-data.h:28:0,
	                 from tui-command.c:24:
	gdb-checked-static-cast.h: In instantiation of \
	  ‘T gdb::checked_static_cast(V*) [with T = tui_cmd_window*; V = tui_win_info]’:
	tui-command.c:65:15:   required from here
	gdb-checked-static-cast.h:63:14: error: cannot convert from pointer to base \
	  class ‘tui_win_info’ to pointer to derived class ‘tui_cmd_window’ because \
	  the base is virtual
	   T result = static_cast<T> (v);
	              ^~~~~~~~~~~~~~~~~~
	...

	Fix this by using dynamic_cast instead of gdb::checked_static_cast in
	TUI_CMD_WIN and TUI_STATUS_WIN.

	Tested on x86_64-linux, with development set to false.

	Reported-By: Robert Xiao <spam_hole@shaw.ca>
	Reported-By: Simon Marchi <simark@simark.ca>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/31399
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399

2024-02-24  Alan Modra  <amodra@gmail.com>

	PR25333, GAS is slow processing -fdebug-types-sections
	gas needs to build lists of sections for each group.  This arranges to
	build the lists earlier, so they can be used when looking for sections
	that belong to a group.  Using the section hash table to find sections
	by name, then by group isn't efficient when there are numerous groups
	with the same section names.  Using a hash table to quickly find a
	group, then searching by section name on a list for the group results
	in a 100-fold speed improvement assembling the testcase in this PR.

	To reduce the number of times we traverse the section list, the patch
	also moves some processing done in elf_adjust_symtab for linked-to
	section, to elf_frob_file.  This requires a testsuite change because
	processing will stop before elf_frob_file if there is a parse error in
	section21.s, ie. you'll only get the "junk at end of line" error, not
	the "undefined linked-to symbol" errors.

		PR 25333
		* config/obj-elf.c (struct group_list, groups): Move earlier.
		(match_section): New function, extracted from..
		(get_section_by_match): ..here.
		(free_section_idx): Move earlier.
		(group_section_find, group_section_insert): New functions.
		(change_section): Use the above.
		(elf_set_group_name): New function.
		(obj_elf_attach_to_group): Use elf_set_group_name.
		(set_additional_section_info): Handle linked_to_symbol_name and
		stabs code, extracted from..
		(adjust_stab_sections): ..here,..
		(build_additional_section_info): ..and here.
		(elf_adjust_symtab): Don't call build_additional_section_info.
		(elf_frob_file): Adjust.
		* config/obj-elf.h (elf_set_group_name): Declare.
		* config/tc-xtensa.c (cache_literal_section): Use elf_set_group_name.
		(xtensa_make_property_section): Likewise.
		* testsuite/gas/elf/attach-1.d: Stricter group section matching,
		and changed group section ordering.
		* testsuite/gas/elf/attach-2.d: Stricter group section matching.
		* testsuite/gas/elf/attach-2.s: Provide section bar type.
		* testsuite/gas/elf/elf.exp: Run attach-2.
		* testsuite/gas/elf/section21.l: Update.
		* testsuite/gas/elf/section21.s: Don't check for a parse error.

2024-02-24  Alan Modra  <amodra@gmail.com>

	xtensa: move xtensa_make_property_section from bfd to gas
	This function is only used by gas, so move it there.  Necessary for
	gas to keep track of group sections as they are created.

		PR 25333
	bfd/
		* elf32-xtensa.c (xtensa_make_property_section): Delete.
		(xtensa_property_section_name): Make public.
	include/
		* elf/xtensa.h (xtensa_make_property_section): Delete.
		(xtensa_property_section_name): Declare
	gas/
		* config/tc-xtensa.c (xtensa_make_property_section): New,
		moved from elf32-xtensa.c.

2024-02-24  Alan Modra  <amodra@gmail.com>

	Make is_relocatable_executable only affect dynamic section syms
	I believe the only elflink.c specialties for is_relocatable_executable
	needed by tic6x are those directly related to dynamic section symbols.
	I might be wrong, the code in record_dynamic_symbol and
	record_link_assignment predated the tic6x port, but I think these were
	symbian specific hacks.

	The shlib-app-1* testsuite changes aren't needed for this patch.  I
	started making them when trying to remove is_relocatable_executable
	completely, but figure it is worth keeping the more permissive address
	matching for some future generic linker change.  The static-app-1*
	changes also adjust to the fact that an unneeded "c" no longer appears
	in the dynamic symbol table.

	bfd/
		* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't do anything
		special for is_relocatable_executable.
		(bfd_elf_record_link_assignment): Likewise.
	ld/
		* testsuite/ld-tic6x/shlib-app-1.rd: Make some address matching
		more permissive.
		* testsuite/ld-tic6x/shlib-app-1b.rd: Likewise.
		* testsuite/ld-tic6x/shlib-app-1r.rd: Likewise.
		* testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise.
		* testsuite/ld-tic6x/static-app-1.rd: Likewise, and adjust expected
		dynamic symbol table.
		* testsuite/ld-tic6x/static-app-1b.rd: Likewise.
		* testsuite/ld-tic6x/static-app-1r.rd: Likewise.
		* testsuite/ld-tic6x/static-app-1rb.rd: Likewise.

2024-02-24  Alan Modra  <amodra@gmail.com>

	sim: no rule to make sim/ppc/Makefile.in
	Seen with --enable-maintainer-mode.
	make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed
	by 'ppc/stamp-pk'.  Stop.

		* sim/ppc/local.mk (stamp-pk): Depend on local.mk not
		Makefile.in.
		* Makefile.in: Regenerate.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-23  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: disable formatting-related flake8 warnings
	Tom Tromey pointed out that flake8 gives some warnings related to
	formatting, such as:

	    python/lib/gdb/prompt.py:149:43: E203 whitespace before ':'

	We don't care about those, since all our formatting is handled
	automatically by black, so ignore these warnings.

	The list of warnings I put comes from:

	  https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8

	Note that since the setup.cfg file is under the gdb directory, it will
	be picked up if you run flake8 from the gdb directory like this:

	    binutils-gdb/gdb $ flake8 python

	but not if you do:

	    binutils-gdb $ flake8 gdb/python

	Change-Id: I1e42aefd388b9c3b6c9d52b4f635ac881db4bbc1
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-23  Tom Tromey  <tromey@adacore.com>

	Remove unused import
	flake8 points out that dap/io.py does not use send_gdb.  This patch
	removes the unused import.

2024-02-23  Pedro Alves  <pedro@palves.net>

	Fix throw_winerror_with_name build error on x86-64 Cygwin
	The GDB build currently fails on x86-64 Cygwin, with:

	 src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’:
	 src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=]
	   152 |   error (_("%s (error %d): %s"), string, err, strwinerror (err));
	       |            ^

	Fix this by adding a cast.  While at it, the error codes are really a
	DWORD that results from a GetLastError() call, so I think unsigned is
	more appropriate.  That is also what strwinerror already does:

	    sprintf (buf, "unknown win32 error (%u)", (unsigned) error);

	The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned
	long long, but for some reason, I don't get a warning there.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17

2024-02-23  Pedro Alves  <pedro@palves.net>

	gdb/linux-nat.c: Add "Accessing inferior memory" section
	This commit adds a new "Accessing inferior memory" comment section to
	gdb/linux-nat.c that explains why we prefer /proc/pid/mem over
	alternatives.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30453

	Change-Id: I575b21ed697a85f3ff4c0ec58c04812db5005b76

2024-02-23  Jon Turney  <jon.turney@dronecode.org.uk>

	Drop special way of getting inferior context after a Cygwin signal
	Simplify Cygwin signal handling by dropping the special way of getting
	inferior context after a Cygwin signal.

	I think the reason this existed was because previously we were not
	able to unwind through the alternate stack used by _sigfe frames, so
	without the hint of the "user" code IP, the backtrace from a signal
	was unusable.

	Now we can unwind through _sigfe frames, drop all this complexity.

	(Restoring this specially obtained context to the inferior (as the
	code currently does) skips over the actual signal delivery and
	handling.  Cygwin has carried for a long time a patch which clears the
	ContextFlags in the signal context, so we never attempt to restore it
	to the inferior, but that interfers with gdb's ability to modify that
	context e.g. if it decides it wants to turn on FLAG_TRACE_BIT.)

	Change-Id: I214edd5a99fd17c1a31ad18138d4a6cc420225e3

2024-02-23  Jon Turney  <jon.turney@dronecode.org.uk>

	Teach gdb how to unwind cygwin _sigbe and sigdelayed frames
	The majority of functions in the cygwin DLL are wrapped by routines
	which use an an alternate stack to return via a signal handler if a
	signal occured while inside the function. (See [1],[2])

	At present, these frames cannot be correctly unwound by gdb.  There
	doesn't seem to currently be a way to correctly describe these frames
	using DWARF CFI.

	So instead, write a custom unwinder for _sigbe and sigdelayed frames,
	which gets the return address from the alternate stack.

	The offset of tls::stackptr from TIB.stacktop is determined by analyzing
	the code in _sigbe or sigdelayed.

	This can backtrace from _sigbe and from a sighandler through sigdelayed.

	Implemented for amd64 and i386

	Issues:

	1. We should detect if we are in the wrapper after the return address
	has been popped off the alternate stack, and if so, fetch the return
	address from the register it's been popped into.

	2. If there are multiple _sigbe or sigdelayed stack frames to be
	unwound, this only unwinds the first one correctly, because we don't
	unwind the value of the alternate stack pointer itself.

	This is no worse than currently, when we can't even unwind one of
	these frame correctly, but isn't quite correct.

	I guess this could be handled by defining a pseudo-register to track
	its value as we unwind the stack.

	[1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/gendef
	[2] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/how-signals-work.txt

	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc

2024-02-23  Jan Beulich  <jbeulich@suse.com>

	x86: rename vec_encoding and vex_encoding_*
	Even with just VEX these weren't limited to vector insns. With APX the
	set of non-vector ones covered has greatly increased. Drop the vec_
	prefix. Also drop the vex_ ones off of the enumerators, as they weren't
	appropriate anyway: Should have been vec_ then, too.

	x86: document -moperand-check=
	PR gas/31388
	Like other command line options this should be mentioned in
	documentation as well, not just in "as --help" output.

2024-02-23  Jan Beulich  <jbeulich@suse.com>

	x86: also permit YMM/ZMM use in CFI directives
	Next to code using %ymm<N> or %zmm<N> it is more natural to have .cfi_*
	directives also reference those, not the corresponding %xmm<N>. Accept
	their names as kind of aliases, i.e. resolving to the same numbers.

	While extending the respective 64-bit testcase, also add %bnd<N> there
	(should have happened right with 633789901c83 ["x86-64: Dwarf2 register
	numbers for %bnd<N>"], sorry), requiring binutils/dwarf.c to be adjusted
	accordingly as well.

2024-02-23  Jan Beulich  <jbeulich@suse.com>

	x86/APX: INV{EPT,PCID,VPID} are WIG
	While various other entries in version 003 of the spec aren't quite as
	explicit (due to simply leaving the respective field blank), all three
	have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0
	by default (and respect -mevexwig=).

2024-02-23  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Try to avoid R_LARCH_ALIGN associate with a symbol
	The R_LARCH_ALIGN need to associated with a symbol if .align has the first
	and third expressions. If R_LARCH_ALIGN associate with a symbol, the addend can
	represent the first and third expression of .align.

	For '.align 3', the addend of R_LARCH_ALIGN only need to represent the alignment
	and R_LARCH_ALIGN not need to associate with a symbol.

	For '.align x, , y', R_LARCH_ALIGN need to associate with a symbol if 0 < y <
	2^x - 4.

2024-02-23  H.J. Lu  <hjl.tools@gmail.com>

	gdb: Add XMM16-XMM31 and K0-K1 DWARF register number mapping
	Add XMM16-XMM31 and K0-K1 DWARF register number mapping to
	amd64_dwarf_regmap.

	Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-02-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-22  Tom Tromey  <tromey@adacore.com>

	Use bool in dynamic type code
	This changes some of the dynamic-type-related code to use bool rather
	than int.

	Regression tested on x86-64 Fedora 38.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-02-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix license text in gdb.reverse/map-to-same-line.{c,exp}
	I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are
	using some kind of indirection via urldefense.proofpoint.com.

	Fix this by removing this indirection.

	Tested on x86_64-linux.

	PR testsuite/31358
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358

2024-02-22  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix race between dap exit and gdb exit
	When DAP shuts down due to an EOF event, there's a race between:
	- gdb's main thread handling a SIGHUP, and
	- the DAP main thread exiting.

	Fix this by waiting for DAP's main thread exit during the gdb_exiting event.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR dap/31380
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380

2024-02-22  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix race between dap startup and dap log file
	In dap_gdb_start we do:
	...
	        append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap"
	...

	While the dap log file setting comes before the dap interpreter setting,
	the order is the other way around:
	- first, the dap interpreter is started
	- second, the -iex commands are executed and the log file is initialized.

	Consequently, there's a race between dap interpreter startup and dap log file
	initialization.

	This cannot be fixed by using -eiex instead.  Before the interpreter is
	started, the "set debug dap-log-file" command is not yet registered.

	Fix this by postponing the start of the DAP server until GDB has processed all
	command files.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR dap/31386
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386

2024-02-22  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Factor out thread_log
	In thread_wrapper I used a style where a message is prefixed with the thread
	name.

	Factor this out into a new function thread_log.

	Also treat the GDB main thread special, because it's usual name is MainThread:
	...
	MainThread: <msg>
	...
	which is the default name assigned by python, so instead use the more
	explicit:
	...
	GDB main: <msg>
	...

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-21  Tom Tromey  <tromey@adacore.com>

	Don't allow multiple request registrations in DAP
	This changes the DAP code to check that a given request or capability
	is only registered a single time.  This is just a precaution against
	accidentally introducing a second definition of a request somewhere.

2024-02-21  Alan Modra  <amodra@gmail.com>

	Leak in i386_elf_section_change_hook
	notes_alloc is perfect for assorted memory you can't free easily
	and/or would rather leave freeing until just before exit.

		* config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc.

2024-02-21  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable}
	This code was there to support g++ 4, which didn't support
	std::is_trivially_constructible and std::is_trivially_copyable.  Since
	we now require g++ >= 9, I think it's fair to assume that GDB will
	always be compiled with a compiler that supports those.

	Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1

2024-02-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove some GCC version checks
	Since we now require C++17, and therefore gcc >= 9, it's no longer
	useful to have gcc version checks for older gcc version.

	Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2024-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix error handling in _dap_read_json
	In _dap_read_json we have a gdb_expect with clauses that generate errors:
	...
	        timeout {
	            error "timeout reading json header"
	        }
	        eof {
	            error "eof reading json header"
	        }
	...

	Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar
	semantics related to errors:
	...
	 # remote_expect works basically the same as standard expect, but it
	 # also takes care of getting the file descriptor from the specified
	 # host and also calling the timeout/eof/default section if there is an
	 # error on the expect call.
	.....

	When a timeout triggers, it generates a timeout error, which is reported by
	gdb_expect, after which it runs the timeout/eof/default clauses, which
	generates an eof error, which is reported by runtest.

	I think the intention here is to generate just a one error, a timeout error.

	Fix this by postponing generating the error until after gdb_expect.

	Tested on x86_64-linux, by:
	- running all the DAP test-cases and observing no regressions, and
	- modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and
	  observing only a timeout error.

	PR testsuite/31382
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382

2024-02-21  Yuriy Kolerov  <kolerov93@gmail.com>

	arc: Determine a branch target of DBNZ correctly
	DBNZ instruction was moved from BRANCH class to a separate one - DBNZ.
	Thus, it must be processed separately in arc_insn_get_branch_target
	to correctly determine an offset for a possible branch.

	The testsuite for DBNZ instruction verifies these cases:

	     1. Check that dbnz does not branch and falls through if its source
	        register is 0 after decrementing. GDB must successfully break
	        on the following instruction after stepping over.
	     2. Check that dbnz branches to the target correctly if its source register
	        is not 0 after decrementing - GDB must successfully break on the target
	        instruction if a forward branch is performed after stepping over.
	     3. The same as point 2 but for a backward branching case.

2024-02-21  Alan Modra  <amodra@gmail.com>

	Re: PR29785, memory bloat after b43771b045fb
	Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift
	exponent 64 is too large".  This is on the bucket_high_pc calculation
	which was moved to the top of insert_arange_in_trie where previously
	it was later, at a point where the overflow could not occur.  Move it
	back and arrange for a duplicate calculation of bucket_high_pc which
	is also protected from overflow.

		PR 29785
		* dwarf2.c (insert_arange_in_trie): Split bucket_high_pc.
		Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help.

2024-02-21  Alan Modra  <amodra@gmail.com>

	Remove is_relocatable_executable from backend code
	With the removal of symbian support, most targets no longer or never
	did set is_relocatable_executable.  Remove the backend support that is
	no longer relevant.

		* elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub),
		(elf32_arm_final_link_relocate, elf32_arm_check_relocs),
		(elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol),
		(elf32_arm_output_arch_local_syms): Remove is_relocatable_executable
		code and comments.
		* elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise.
		* elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise.
		* elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise.
		* elfxx-mips.c (count_section_dynsyms): Likewise.

2024-02-21  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: testsuite: move sysreg tests into sysreg sub-directory
	This patch moves the existing sysreg tests for AArch64 into a subdirectory
	(sysreg). The number of test files related to system registers grew
	relatively big with time and makes the browsing of those files difficult.
	Moreover, the difference of naming for the failure, working, and
	feature-specific scenarios causes the tests not to appear next to one
	another in the exploration tree when it is ordered alphabetically.

2024-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Join JSON writer thread with DAP thread
	The DAP interpreter runs in its own thread, and starts a few threads:
	- the JSON reader thread,
	- the JSON writer thread, and
	- the inferior output reader thread.

	As part of the DAP shutdown, both the JSON reader thread and the JSON writer
	thread, as well as the DAP main thread run to exit, but these exits are not
	ordered in any way.

	Wait in the main DAP thread for the exit of the JSON writer thread.

	This makes sure that the responses are flushed to the DAP client before DAP
	shutdown.

	An earlier version of this patch used Queue.task_done() to accomplish the
	same, but that didn't guarantee writing the "<thread name>: terminating"
	log entry from thread_wrapper before DAP shutdown.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR dap/31380
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380

2024-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Make dap log printing thread-safe
	I read that printing from different python threads is thread-unsafe, and I
	noticed that the dap log printing is used from different threads, but doesn't
	take care to make the printing thread-safe.

	Fix this by using a lock to access LoggingParam.log_file.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Flush after printing in log_stack
	I noticed that function log flushes the dap log file after printing, but
	that function log_stack doesn't.

	Fix this by also flushing the dap log file in log_stack.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp
	While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP
	patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap
	log file.

	This is normally set up by dap_gdb_start, but the test-case doesn't use it.

	Fix this by doing "set debug dap-log-file $logfile" in the test-case.

	To make it easy to do so, I've factored out a new proc new_dap_log_file, and
	while at likewise a new proc current_dap_log_file.

	Note that the log file is currently empty.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-21  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb: Document C++17 build requirement.
	We require C++17 to build for a while now:
	https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2024-02-21  Tatsuyuki Ishi  <ishitatsuyuki@gmail.com>

	RISC-V: Fix local GOT and reloc size calculation for TLS.
	The previous code did not account correctly for two cases:
	* A TLS symbol can be referenced with multiple TLS types (although rare),
	  in which case it only allocated the maximum slot size among the types,
	  instead of the sum.
	* TLS relocations are only needed for DLLs, unlike normal symbols which
	  requires relocations for all PIE code.

	Modify the logic to account for the two cases, so this fixes the redundant
	dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE.

	Passed the gcc/binutils regressions of riscv-gnu-toolchain.

	bfd/
	    * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation
	    sizing for TLS and non-TLS symbols differently, with the former
	    requiring relocs on DLL while the latter requiring on PIE.
	    Allocate GOT slots and relocation slots for each TLS type separately,
	    accounting for the possibility of a TLS variable getting referenced by
	    multiple symbols.
	ld/
	    * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
	    * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with
	    symbols referred by both types and global and local symbols.

2024-02-21  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax.
	Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c.  Theoretically,
	assembler don't need to generate the pc-relative relocation and the refered
	local .L symbol when relaxation is disabled.  The above commit improved the
	pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump
	relocations.

	Passed the gcc/binutils regressions of riscv-gnu-toolchain.

	gas/
		* config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all
		branch and jump relocations when -mno-relax.

2024-02-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-20  Tom Tromey  <tromey@adacore.com>

	Rewrite Rust slice type handling
	This patch rewrites the handling of slice types in Rust.

	More recent versions of the Rust compiler changed how unsized types
	were emitted, letting gdb inspect them more nicely.  However, gdb did
	not do this, and in fact treated all such types as if they were slices
	of arrays, which is incorrect.

	This patch rewrites this handling and removes the restriction that
	unsized types must be array slices.  I've added a comment explaining
	how unsized types are represented to rust-lang.c as well.

	I looked into a different approach, namely changing the DWARF reader
	to fix up slice types to have a dynamic type.  However, the approach
	taken here turned out to be simpler.

	Tested on x86-64 Fedora 38 with a variety of Rust compiler versions.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330

2024-02-20  Tom Tromey  <tom@tromey.com>

	Add obj_section::contains method
	I noticed a number of spots checking whether an address is in an
	obj_section.  This patch introduces a new method for this and changes
	some code to use it.

	Regression tested on x86-64 Fedora 38.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass frames as `const frame_info_ptr &`
	We currently pass frames to function by value, as `frame_info_ptr`.
	This is somewhat expensive:

	 - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
	   by value
	 - the constructors and destructor link/unlink the object in the global
	   `frame_info_ptr::frame_list` list.  This is an `intrusive_list`, so
	   it's not so bad: it's just assigning a few points, there's no memory
	   allocation as if it was `std::list`, but still it's useless to do
	   that over and over.

	As suggested by Tom Tromey, change many function signatures to accept
	`const frame_info_ptr &` instead of `frame_info_ptr`.

	Some functions reassign their `frame_info_ptr` parameter, like:

	  void
	  the_func (frame_info_ptr frame)
	  {
	    for (; frame != nullptr; frame = get_prev_frame (frame))
	      {
	        ...
	      }
	  }

	I wondered what to do about them, do I leave them as-is or change them
	(and need to introduce a separate local variable that can be
	re-assigned).  I opted for the later for consistency.  It might not be
	clear why some functions take `const frame_info_ptr &` while others take
	`frame_info_ptr`.  Also, if a function took a `frame_info_ptr` because
	it did re-assign its parameter, I doubt that we would think to change it
	to `const frame_info_ptr &` should the implementation change such that
	it doesn't need to take `frame_info_ptr` anymore.  It seems better to
	have a simple rule and apply it everywhere.

	Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb] Don't init history in batch mode
	I noticed in captured_main_1 that init_history is called just before bailing
	out if batch_flag is true.

	The history is used only in an interactive session, so there's no need to
	initialize it in batch mode.

	Fix this by moving init_history to after the batch mode check.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: gas: missing aliases for $r14r15 in assembler.
	Most registers from a register-pair suffixed by .lo and .hi suffixes.
	This was not the case of $r14 and $r15 since they are defined by the
	ABI: $r14 is the frame pointer, and $r15 is used to return aggregates
	from functions.  We do not add aliases for $r12 (the stack pointer) and
	$r13 (the tls register).

	opcodes/ChangeLog:

		* kvx-opc.c: Regenerate.

	gas/ChangeLog:

		* config/kvx-parse.h: Regenerate.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: enable magic immediates for integer multiply-accumulate and CMOVE*
	Affected instructions:
	 - alu unit:
	    cmovewp cmovehq
	 - mau unit:
	     maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp
	     msbfsuwdp mms mulwdp muluwdp mulsuwdp mm

	opcodes/ChangeLog:

		* kvx-opc.c (struct kvxopc): Regenerate.

	gas/ChangeLog:

		* config/kvx-parse.h: Regenerate.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: gas: rename: or -> ior, xor -> eor
	TCA instructions start with an X, this introduces ambiguities when it
	comes to XOR (Is it the OR on the TCA or the XOR of the core?).  For this
	reason, we rename OR to IOR and XOR to EOR.

	OR and XOR variants are still valid on KV3-1 and KV3-2.  However, they
	have been completely removed from KV4-1.

	opcodes/ChangeLog:

		* kvx-opc.c: Regenerate.

	include/ChangeLog:

		* opcode/kvx.h: Regenerate.

	gas/ChangeLog:

		* config/kvx-parse.h: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: gas: move the splat modifier to the immediate
	The position of the splat modifier is now after the operand it
	modifies and not attached directly to the opcode.

	opcodes/ChangeLog:

		* kvx-opc.c: Regenerate.

	include/ChangeLog:

		* opcode/kvx.h: Regenerate.

	gas/ChangeLog:

		* config/kvx-parse.h: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate.
		* testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: gas: fix leak
	gas/ChangeLog:

		* config/tc-kvx.c (md_apply_fix): Free memory at this end.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: Improve lexing & parsing
	Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates,
	however this candidate can be directly extracted from the array (in
	kvx-parse.h) registering all the immediates.

	During lexing, we ignored trailing characters after a number, this is
	not good enough since now number can be followed by a modifier.  The
	function READ_TOKEN and GET_TOKEN_CLASS have been update to take this
	into account.

	gas/ChangeLog:

		* config/kvx-parse.c (promote_token): Do not rely on
		  env.promote_immediate anymore.
		(get_token_class): Do not ignore trailing characters after a
		number.
		(read_token): Likewise.
		(print_token_list): THIS SHOULD NOT BE HERE.

2024-02-20  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: gas: fix the detection of negative powers of 2
	The detection of negative powers of 2 was wrong and could lead to
	well-formed bundles ending up taking more syllables than necessary.

	gas/ChangeLog:

		* config/kvx-parse.c (get_token_class): Use the signed value.
		* testsuite/gas/kvx/np2-detection.d: New test.
		* testsuite/gas/kvx/np2-detection.s: New test.

2024-02-20  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: add missing indcall-badoperand.* test files
	This adds teh following files that were missing in the previous
	commit ecd16ae4e47118f66447641d93a6aa1334e550d4

	  testsuite/gas/bpf/indcall-badoperand.d
	  testsuite/gas/bpf/indcall-badoperand.l
	  testsuite/gas/bpf/indcall-badoperand.s

2024-02-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-19  Will Hawkins  <hawkinsw@obs.cr>

	bpf: fix bpf expression parsing regression in GAS
	As a result of a switch instead of an if, as would issue non-specific
	error messages when it encountered an operand it could not parse in bpf.
	This patch fixes that regression and adds a test to prevent it from
	reoccurring.

	Tested for bpf-unknown-none on x86_64-redhat-linux.

	gas/ChangeLog:

		* config/tc-bpf.c (parse_expression): Change switch to if so that error
		* condition is handled.
		* testsuite/gas/bpf/bpf.exp: Invoke new test.
		* testsuite/gas/bpf/indcall-badoperand.d: New test.
		* testsuite/gas/bpf/indcall-badoperand.l: New test.
		* testsuite/gas/bpf/indcall-badoperand.s: New test.

2024-02-19  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: avoid UB in pointer subtraction
	The PARSE_ERROR macro in md_assemble performs pointer subtraction.  If
	parse_expression returns NULL then the later will be part of the
	subtraction and therefore UB will be incurred.

	This patch changes md_assemble to:
	1. Accommodate all invocations to parse_expression to the fact it will
	   return NULL when a parse error occurs.
	2. Avoid UB in PARSE_ERROR.

	Tested in bpf-unknown-none target / x86_64-linux-gnu host.

	gas/ChangeLog:

		* config/tc-bpf.c (md_assemble): Fix to take into account that
		parse_expression can return NULL.
		(PARSE_ERROR): Avoid passing invalid length to parse_error.

2024-02-19  Claudio Bantaloukas  <Claudio.Bantaloukas@arm.com>

	arm: Add support for Armv9.5-A

2024-02-19  Yury Khrustalev  <Yury.Khrustalev@arm.com>

	aarch64: Add support for the id_aa64isar3_el1 system register
	Hi,

	[PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register

	AArch64 defines a read-only system register called id_aa64isar3_el1.
	This patch also adds relevant tests.

	Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
	and no regressions was found.

	Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf?

	Thanks,
	Yury Khrustalev

	From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001
	From: Yury Khrustalev <yury.khrustalev@arm.com>
	Date: Tue, 6 Feb 2024 11:05:39 +0000
	Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the
	 id_aa64isar3_el1 system register

	AArch64 defines a read-only system register called id_aa64isar3_el1.
	This patch also adds relevant tests.

	Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
	and no regressions was found.

2024-02-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	testsuite, python: reformat python files using black
	In the recent patch titled "gdb, python: selectively omit enabling
	stdin in gdb.execute", the black tool found formatting issues.  Fix
	them.

2024-02-19  Zac Walker  <zacwalker@microsoft.com>

	aarch64: Add new relocations and limit COFF AArch64 relocation offsets
	The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation
	type. This is needed for 32-bit relative address.

	It also adds a check for relocation offsets over 21 bits. Offsets
	inside coff files are stored in instruction code. In the case of ADRP
	the actual value is stored, not a downshifted page offset. This means
	values over 21 bits would otherwise be truncated.

	Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and
	BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped.

	ChangeLog:

		* bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add
		BFD_RELOC_AARCH64_ADR_GOT_PAGE,
		BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32
		relocations.
		(coff_pe_aarch64_relocate_section): Likewise.
		* gas/write.c (adjust_reloc_syms): COFF AArch64 relocation
		offsets need to be limited to 21bits
		(defined): Likewise.

2024-02-19  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, python: selectively omit enabling stdin in gdb.execute
	From the Python API, we can execute GDB commands via gdb.execute.  If
	the command gives an exception, however, we need to recover the GDB
	prompt and enable stdin, because the exception does not reach
	top-level GDB or normal_stop.  This was done in commit

	  commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a
	  Author: Andrew Burgess <andrew.burgess@embecosm.com>
	  Date:   Tue Nov 19 11:17:20 2019 +0000

	    gdb: Enable stdin on exception in execute_gdb_command

	with the following code:

	  catch (const gdb_exception &except)
	    {
	      /* If an exception occurred then we won't hit normal_stop (), or have
	         an exception reach the top level of the event loop, which are the
	         two usual places in which stdin would be re-enabled. So, before we
	         convert the exception and continue back in Python, we should
	         re-enable stdin here.  */
	      async_enable_stdin ();
	      GDB_PY_HANDLE_EXCEPTION (except);
	    }

	In this patch, we explain what happens when we run a GDB command in
	the context of a synchronous command, e.g.  via Python observer
	notifications.

	As an example, suppose we have the following objfile event listener,
	specified in a file named file.py:

	~~~
	import gdb

	class MyListener:
	    def __init__(self):
	        gdb.events.new_objfile.connect(self.handle_new_objfile_event)
	        self.processed_objfile = False

	    def handle_new_objfile_event(self, event):
	        if self.processed_objfile:
	            return

	        print("loading " + event.new_objfile.filename)
	        self.processed_objfile = True
	        gdb.execute('add-inferior -no-connection')
	        gdb.execute('inferior 2')
	        gdb.execute('target remote | gdbserver - /tmp/a.out')
	        gdb.execute('inferior 1')

	the_listener = MyListener()
	~~~

	Using this Python file, we see the behavior below:

	  $ gdb -q -ex "source file.py" -ex "run" --args a.out
	  Reading symbols from a.out...
	  Starting program: /tmp/a.out
	  loading /lib64/ld-linux-x86-64.so.2
	  [New inferior 2]
	  Added inferior 2
	  [Switching to inferior 2 [<null>] (<noexec>)]
	  stdin/stdout redirected
	  Process /tmp/a.out created; pid = 3075406
	  Remote debugging using stdio
	  Reading /tmp/a.out from remote target...
	  ...
	  [Switching to inferior 1 [process 3075400] (/tmp/a.out)]
	  [Switching to thread 1.1 (process 3075400)]
	  #0  0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
	  (gdb) [Thread debugging using libthread_db enabled]
	  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
	  [Inferior 1 (process 3075400) exited normally]

	Note how the GDB prompt comes in-between the debugger output.  We have this
	obscure behavior, because the executed command, "target remote", triggers
	an invocation of `normal_stop` that enables stdin.  After that, however,
	the Python notification context completes and GDB continues with its normal
	flow of executing the 'run' command.  This can be seen in the call stack
	below:

	  (top-gdb) bt
	  #0  async_enable_stdin () at src/gdb/event-top.c:523
	  #1  0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
	  #2  0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801
	  #3  0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225
	  #4  0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316
	  #5  0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175
	  #6  0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338
	  #7  0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280)  at src/gdb/target.c:824
	  #8  0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735
	  #9  0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575
	  #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529
	  #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701
	  #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411
	  #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700
	  #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
	  #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52
	  #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195
	  #24 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
	  #25 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
	  #26 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290
	  #27 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590
	  #28 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166
	  #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
	  #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
	  #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
	  #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
	  #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416
	  #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
	  #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
	  #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
	  #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
	  #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
	  #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
	  #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
	  #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
	  #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
	  #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
	  #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
	  #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
	  #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
	  #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
	  (top-gdb)

	The use of the "target remote" command here is just an example.  In
	principle, we would reproduce the problem with any command that
	triggers an invocation of `normal_stop`.

	To omit enabling the stdin in `normal_stop`, we would have to check the
	context we are in.  Since we cannot do that, we add a new field to
	`struct ui` to track whether the prompt was already blocked, and set
	the tracker flag in the Python context before executing a GDB command.

	After applying this patch, the output becomes

	  ...
	  Reading symbols from a.out...
	  Starting program: /tmp/a.out
	  loading /lib64/ld-linux-x86-64.so.2
	  [New inferior 2]
	  Added inferior 2
	  [Switching to inferior 2 [<null>] (<noexec>)]
	  stdin/stdout redirected
	  Process /tmp/a.out created; pid = 3032261
	  Remote debugging using stdio
	  Reading /tmp/a.out from remote target...
	  ...
	  [Switching to inferior 1 [process 3032255] (/tmp/a.out)]
	  [Switching to thread 1.1 (process 3032255)]
	  #0  0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
	  [Thread debugging using libthread_db enabled]
	  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
	  [Inferior 1 (process 3032255) exited normally]
	  (gdb)

	Let's now consider a secondary scenario, where the command executed from
	the Python raises an error.  As an example, suppose we have the Python
	file below:

	    def handle_new_objfile_event(self, event):
	        ...
	        print("loading " + event.new_objfile.filename)
	        self.processed_objfile = True
	        gdb.execute('print a')

	The executed command, "print a", gives an error because "a" is not
	defined.  Without this patch, we see the behavior below, where the
	prompt is again placed incorrectly:

	  ...
	  Reading symbols from /tmp/a.out...
	  Starting program: /tmp/a.out
	  loading /lib64/ld-linux-x86-64.so.2
	  Python Exception <class 'gdb.error'>: No symbol "a" in current context.
	  (gdb) [Inferior 1 (process 3980401) exited normally]

	This time, `async_enable_stdin` is called from the 'catch' block in
	`execute_gdb_command`:

	  (top-gdb) bt
	  #0  async_enable_stdin () at src/gdb/event-top.c:523
	  #1  0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713
	  #2  0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #3  0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #4  0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #5  0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #6  0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #7  0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #8  0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
	  #9  0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
	  #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52
	  #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195
	  #12 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
	  #13 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
	  #14 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290
	  #15 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590
	  #16 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166
	  #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
	  #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
	  #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
	  #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
	  #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416
	  #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
	  #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
	  #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
	  #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
	  #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
	  #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
	  #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
	  #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
	  #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
	  #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
	  #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
	  #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
	  #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
	  #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
	  (top-gdb)

	Again, after we enable stdin, GDB continues with its normal flow
	of the 'run' command and receives the inferior's exit event, where
	it would have enabled stdin, if we had not done it prematurely.

	  (top-gdb) bt
	  #0  async_enable_stdin () at src/gdb/event-top.c:523
	  #1  0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
	  #2  0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700
	  #3  0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42
	  #4  0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316
	  #5  0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573
	  #6  0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694
	  #7  0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217
	  #8  0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407
	  #9  0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471
	  #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324
	  #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
	  #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
	  (top-gdb)

	The solution implemented by this patch addresses the problem.  After
	applying the patch, the output becomes

	  $ gdb -q -ex "source file.py" -ex "run" --args a.out
	  Reading symbols from /tmp/a.out...
	  Starting program: /tmp/a.out
	  loading /lib64/ld-linux-x86-64.so.2
	  Python Exception <class 'gdb.error'>: No symbol "a" in current context.
	  [Inferior 1 (process 3984511) exited normally]
	  (gdb)

	Regression-tested on X86_64 Linux using the default board file (i.e.  unix).

	Co-Authored-By: Oguzhan Karakaya <oguzhan.karakaya@intel.com>
	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-19  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Fix printing of out of bounds struct members
	When building gdb with -O0 -fsanitize=address, and running test-case
	gdb.ada/uninitialized_vars.exp, I run into:
	...
	(gdb) info locals
	a = 0
	z = (a => 1, b => false, c => 2.0)
	=================================================================
	==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80
	READ of size 4 at 0x602000097f58 thread T0
	    #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18)
	    #1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748
	    #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769
	    #3 0xbc898c in unsigned char* std::__copy_move_backward_a1<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778
	    #4 0xbc715c in unsigned char* std::__copy_move_backward_a<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807
	    #5 0xbc4e6c in unsigned char* std::copy_backward<unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867
	    #6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223
	    #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239
	    #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078
	    #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095
	    #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658
	    #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857
	    #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042
	    #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04)
	    #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092
	    #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184
	    #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
	    #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
	    #18 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
	    #19 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
	    #20 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
	    #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
	    #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
	    #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
	    #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
	    #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
	    #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
	    #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
	    #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566
	    #29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
	    #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
	    #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
	    #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
	    #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
	    #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
	    #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
	    #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
	    #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694
	    #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264
	    #39 0x1768080 in start_event_loop gdb/main.c:408
	    #40 0x17684c4 in captured_command_loop gdb/main.c:472
	    #41 0x176cfc8 in captured_main gdb/main.c:1342
	    #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361
	    #43 0xb73edc in main gdb/gdb.c:39
	    #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8)
	    #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac)
	    #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c)

	0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58)
	allocated by thread T0 here:
	    #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218)
	    #1 0xcbc278 in xcalloc gdb/alloc.c:97
	    #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29
	    #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937
	    #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033
	    #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229
	    #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560
	    #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133
	    #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182
	    #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
	    #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
	    #11 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
	    #12 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
	    #13 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
	    #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
	    #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
	    #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
	    #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
	    #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
	    #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
	    #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
	    #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566
	    #22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
	    #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
	    #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
	    #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
	    #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
	    #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
	    #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
	    #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573

	SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove
	...

	The error happens when trying to print either variable y or y2:
	...
	   type Variable_Record (A : Boolean := True) is record
	      case A is
	         when True =>
	            B : Integer;
	         when False =>
	            C : Float;
	            D : Integer;
	      end case;
	   end record;
	   Y  : Variable_Record := (A => True, B => 1);
	   Y2 : Variable_Record := (A => False, C => 1.0, D => 2);
	...
	when the variables are uninitialized.

	The error happens only when printing the entire variable:
	...
	(gdb) p y.a
	$2 = 216
	(gdb) p y.b
	There is no member named b.
	(gdb) p y.c
	$3 = 9.18340949e-41
	(gdb) p y.d
	$4 = 1
	(gdb) p y
	<AddressSanitizer: heap-buffer-overflow>
	...

	The error happens as follows:
	- field a functions as discriminant, choosing either the b, or c+d variant.
	- when y.a happens to be set to 216, as above, gdb interprets this as the
	  variable having the c+d variant (which is why trying to print y.b fails).
	- when printing y, gdb allocates a value, copies the bytes into it from the
	  target, and then prints the value.
	- gdb allocates the value using the type size, which is 8.  It's 8 because
	  that's what the DW_AT_byte_size indicates.  Note that for valid values of a,
	  it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1
	  (b variant), size is 8.
	- gdb tries to print field d, which is at an 8 byte offset, and that results
	  in a out-of-bounds access for the allocated 8-byte value.

	Fix this by handling this case in value::contents_copy_raw, such that we have:
	...
	(gdb) p y
	$1 = (a => 24, c => 9.18340949e-41,
	      d => <error reading variable: access outside bounds of object>)
	...

	An alternative (additional) fix could be this: in compute_variant_fields_inner
	gdb reads the discriminant y.a to decide which variant is active.  It would be
	nice to detect that the value (y.a == 24) is not a valid Boolean, and give up
	on choosing a variant altoghether.  However, the situation regarding the
	internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not
	possible to reliably decide what valid values are.

	The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is
	a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the
	copyright years.

	Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc
	versions. [ So, it would be nice to rewrite it into a dwarf assembly
	test-case. ]

	The test-case loops over all languages.  This is inherited from an earlier
	attempt to fix this, which had language-specific fixes (in print_field_values,
	cp_print_value_fields, pascal_object_print_value_fields and
	f_language::value_print_inner).  I've left this in, but I suppose it's not
	strictly necessary anymore.

	Tested on x86_64-linux.

	PR exp/31258
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258

2024-02-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-16  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add -plugin-save-temps
	Add -plugin-save-temps to store plugin intermediate files permanently.
	It can be used to exam the final input object files generated from IR
	inputs.

		* NEWS: Mention -plugin-save-temps.
		* ld.h (ld_config_type): Add plugin_save_temps.
		* ld.texi: Document -plugin-save-temps.
		* ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS.
		* lexsup.c (ld_options): Add -plugin-save-temps.
		(parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS.
		* plugin.c (plugin_call_cleanup): Don't call plugin
		cleanup_handler for -plugin-save-temps.

2024-02-16  Alan Modra  <amodra@gmail.com>

	PR27597, nios: assertion fail in nios2_elf32_install_imm16
	The assertion in nios2_elf32_install_imm16 triggers when the PLT is
	twice the maximum allowable size for a branch from PLTn to reach
	.PLTresolve, and on no other call to nios2_elf32_install_imm16.  That
	makes the assertion completely useless.  We can handle a PIC PLT
	exceeding 0x8000 in size by bouncing branches that won't reach through
	previous branches.

		PR 27597
		* elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT.
		(nios2_build_one_stub): Don't bother masking value passed to
		nios2_elf32_install_imm16.
		(nios2_elf32_finish_dynamic_symbol): Likewise.  Handle overflow
		of PLTn branch to .PLTresolve by bouncing through prior branches.

2024-02-16  Nick Clifton  <nickc@redhat.com>

	Update how-to-make-a-release document to reference new git repository for the documentation

2024-02-16  Jan Beulich  <jbeulich@suse.com>

	x86/APX: drop stray IgnoreSize
	While necessary on the legacy encodings, the EVEX ones don't need it.
	Even more so when they're available for 64-bit mode only, when the
	legacy encodings have the attribute only for correctly handling things
	in 16-bit mode.

	x86: don't use VexWIG in SSE2AVX templates
	Several years ago it was decided that SSE2AVX templates should not be
	sensitive to -mvexwig= (upon my suggestion to consistently make all
	sensitive as long as they don't require a specific setting of VEX.W).
	Adjust the four that still are, switching to use of Vex128 at the same
	time.

	x86: drop redundant Xmmword
	While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from
	insn templates") did so for Byte/Word/Dword/Qword, the same kind of
	redundancy was left in place for a few 128-bit SIMD operands.

	SCFI: correct test names
	Having multiple tests with the same name is confusing.

2024-02-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-15  H.J. Lu  <hjl.tools@gmail.com>

	x86: Display -msse-check= default as none
	Display -msse-check= default as none for "as --help" since its default
	is none, not warning.

		PR gas/31389
		* config/tc-i386.c (md_show_usage): Change -msse-check= default
		to none.

2024-02-15  Alan Modra  <amodra@gmail.com>

	S/390: 32-bit PIE undef weak failures
	Like 10e7c0457cb7 but for elf32-s390.c

		* elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use
		UNDEFWEAK_NO_DYNAMIC_RELOC.
		(allocate_dynrelocs): Likewise.
		(elf_s390_relocate_section): Check resolved_to_zero.
		(elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if
		UNDEFWEAK_NO_DYNAMIC_RELOC.

2024-02-15  Tom Tromey  <tromey@adacore.com>

	Move lookup_name_info creation into basic_lookup_transparent_type
	I noticed that basic_lookup_transparent_type calls two different
	functions that both proceed to create a lookup_name_info.  It's more
	efficient to create this object in the outermost layer possible.
	Making this change required a few related changes, resulting in this
	patch.

	There are still more changes of this sort that could be made.

	Regression tested on x86-64 Fedora 38.

2024-02-15  Will Hawkins  <hawkinsw@obs.cr>

	objdump, as: add callx support for BPF CPU v1
	Albeit not being a currently valid BPF instruction, callx is generated
	by both clang and GCC when BPF programs are compiled unoptimized.
	Until now, GCC would emit it only whe using the experimental
	compiler-testing cpu version xbpf, whereas clang would emit it from
	v1.  This patch makes GAS to accept callx also starting with cpu v1.

	opcodes/ChangeLog

		* bpf-opc.c: Move callx into the v1 BPF CPU variant.

	gas/ChangeLog

		* testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu
		version.
		* testsuite/gas/bpf/indcall-1.d: Likewise.

2024-02-15  Alan Modra  <amodra@gmail.com>

	Make various gas symbol predicates and accessors take const args
		* symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK),
		(S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED),
		(S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD),
		(symbol_previous, symbol_next, symbol_X_add_number),
		(symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p),
		(symbol_mri_common_p, symbol_written_p, symbol_removed_p),
		(symbol_resolved_p, symbol_resolving_p, symbol_section_p),
		(symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p),
		(symbol_shadow_p, symbol_same_p): Constify sym args.
		* symbols.h: Update prototypes.

	Re: elf_backend_finish_dynamic_symbol returning false
	Making a bfd_final_link failure noisy requires testsuite changes.

	PR28448, Memory leak in function add_symbols(plugin.c)
		PR 28448
		* plugin.c (add_symbols): bfd_alloc memory for symptrs.  Check
		bfd_make_empty_symbol return.

	Re: elf_backend_finish_dynamic_symbol returning false
	I didn't examine ld testsuite logs properly after cf95b909e2c2.
	Replacing one of the "return false" with BFD_ASSERT in
	finish_dynamic_symbol was wrong as it causes segmentation faults on
	testcases expected to fail.  Revert those changes and instead make
	a bfd_final_link failure noisy.

2024-02-15  Samuel Tardieu  <sam@rfc1149.net>  (tiny change)

	gdb/doc: Fix several typos in GDB documentation
	Approved-by: Eli Zaretskii <eliz@gnu.org>

2024-02-15  Steinar H. Gunderson  <steinar+sourceware@gunderson.no>

	PR29785, memory bloat after b43771b045fb
	Pathological cases of dwarf info with overlapping duplicate memory
	ranges can cause splitting of trie leaf nodes, which in the worst case
	will cause memory to increase without bounds.

		PR 29785
		* dwarf2.c (insert_arange_in_trie): Don't split leaf nodes
		unless that reduces number of elements in at least one node.

2024-02-15  Alan Modra  <amodra@gmail.com>

	PR30308, infinite recursion in i386_intel_simplify
	This patch exposes the symbol "resolving" flag for use in
	i386_intel_simplify, not only preventing infinite recursion on the
	testcase in the PR but also more complicated cases like:

	 .intel_syntax
	 b = a
	 a = b
	 mov eax, [a]

		PR 30308
		* symbols.c (symbol_mark_resolving, symbol_clear_resolving),
		(symbol_resolving_p): New functions.
		* symbols.h: Declare them.
		* config/tc-i386-intel.c (i386_intel_simplify): Delete forward
		declaration.  Formatting.
		(i386_intel_simplify_symbol): Use resolving flag to prevent
		infinite recursion.

2024-02-15  Alan Modra  <amodra@gmail.com>

	elf_backend_finish_dynamic_symbol returning false
	Returning false from elf_backend_finish_dynamic_symbol will not result
	in an error being printed unless bfd_error is set but will result in
	the linker exiting with a non-zero status.  If just bfd_error is set
	then a generic "final link failed" will result, which doesn't help a
	user much.  So elf_backend_finish_dynamic_symbol should print its own
	error message whenever returning false, or use BFD_ASSERT or abort to
	print assertion failures for conditions that shouldn't occur.

	This patch does that, and removes unnecessary "htab != NULL" tests in
	elf_backend_finish_dynamic_symbol.  Such tests aren't needed in a
	function only called via elf_backend_data.

2024-02-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-14  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix exit race
	When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to
	a segfault in new_threadstate.

	At the point of the core dump, the gdb main thread looks like:
	...
	 (gdb) bt
	 #0  0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6
	 #1  0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6
	 #2  0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
	     at gdb/event-top.c:926
	 #3  0x00000000007b0470 in handle_sigsegv (sig=11)
	     at gdb/event-top.c:976
	 #4  <signal handler called>
	 #5  0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0
	 #6  0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0
	 #7  0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738)
	     at gdb/python/python-internal.h:787
	 #8  0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0,
	     __in_chrg=<optimized out>) at gdb/python/python.c:1051
	 #9  0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy
	     (__victim=...) at /usr/include/c++/13/bits/std_function.h:175
	 #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager
	     (__dest=..., __source=..., __op=std::__destroy_functor)
	     at /usr/include/c++/13/bits/std_function.h:203
	 #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...)
	     at /usr/include/c++/13/bits/std_function.h:282
	 #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10,
	     __in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:244
	 #13 0x000000000042e654 in std::function<void ()>::~function() (this=0xfffea8001c10,
	     __in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:334
	 #14 0x0000000000b68e60 in std::_Destroy<std::function<void ()> >(...) (...)
	     at /usr/include/c++/13/bits/stl_construct.h:151
	 #15 0x0000000000b68cd0 in std::_Destroy_aux<false>::__destroy<...>(...) (...)
	     at /usr/include/c++/13/bits/stl_construct.h:163
	 #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...)
	     at /usr/include/c++/13/bits/stl_construct.h:196
	 #17 0x0000000000b68414 in std::_Destroy<...>(...) (...)
	     at /usr/include/c++/13/bits/alloc_traits.h:948
	 #18 std::vector<...>::~vector() (this=0x2a183c8 <runnables>)
	     at /usr/include/c++/13/bits/stl_vector.h:732
	 #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6
	 #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6
	 #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0)
	     at gdb/top.c:1822
	 #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0)
	     at gdb/cli/cli-cmds.c:508
	 #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300
	 #24 0x00000000007b09d4 in async_disconnect (arg=0x0)
	     at gdb/event-top.c:1230
	 #25 0x0000000000548acc in invoke_async_signal_handlers ()
	     at gdb/async-event.c:234
	 #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1)
	     at gdbsupport/event-loop.cc:199
	 #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
	 #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
	 #29 0x000000000094567c in captured_main (data=0xffffcb279d08)
	     at gdb/main.c:1335
	 #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08)
	     at gdb/main.c:1354
	 #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98)
	     at gdb/gdb.c:39
	...

	The direct cause of the segfault is calling PyGILState_Ensure after
	calling Py_Finalize.

	AFAICT the problem is a race between the gdb main thread and DAP's JSON writer
	thread.

	On one side, we have the following events:
	- DAP's JSON reader thread reads an EOF, and lets DAP's main thread known
	  by writing None into read_queue
	- DAP's main thread lets DAP's JSON writer thread known by writing None into
	  write_queue
	- DAP's JSON writer thread sees the None in its queue, and calls
	  send_gdb("quit")
	- a corresponding gdbpy_event is deposited in the runnables vector, to be
	  run by the gdb main thread

	On the other side, we have the following events:
	- the gdb main thread receives a SIGHUP
	- the corresponding handler calls quit_force, which calls do_final_cleanups
	- one of the final cleanups is finalize_python, which calls Py_Finalize
	- quit_force calls exit, which triggers the exit handlers
	- one of the exit handlers is the destructor of the runnables vector
	- destruction of the vector triggers destruction of the remaining element
	- the remaining element is a gdbpy_event, and the destructor (indirectly)
	  calls PyGILState_Ensure

	It's good to note that both events (EOF and SIGHUP) are caused by this line in
	the test-case:
	...
	catch "close -i $gdb_spawn_id"
	...
	where "expect close" closes the stdin and stdout file descriptors, which
	causes the SIGHUP to be send.

	So, for the system I'm running this on, the send_gdb("quit") is actually not
	needed.

	I'm not sure if we support any systems where it's actually needed.

	Fix this by removing the send_gdb("quit").

	Tested on aarch64-linux.

	PR dap/31306
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306

2024-02-14  H.J. Lu  <hjl.tools@gmail.com>

	gdb: Reformat amd64_dwarf_reg_to_regnum
	Reformat amd64_dwarf_reg_to_regnum:

	@@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg)
	   if (reg >= 0 && reg < amd64_dwarf_regmap_len)
	     regnum = amd64_dwarf_regmap[reg];

	-  if (ymm0_regnum >= 0
	-	   && i386_xmm_regnum_p (gdbarch, regnum))
	+  if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum))
	     regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep);

	to remove the misaligned line.

2024-02-14  Tom Tromey  <tromey@adacore.com>

	Use typedef in definition of warning_hook
	This changes the global 'warning_hook' to use the warning_hook_handler
	typedef in its definition.  This makes it a little easier to change
	the type, should that be needed.

2024-02-14  Yuriy Kolerov  <Yuriy.Kolerov@synopsys.com>

	arc: Put DBNZ instruction to a separate class
	DBNZ instruction decrements its source register operand, and if
	the result is non-zero it branches to the location defined by a signed
	half-word displacement operand.

	DBNZ instruction is in BRANCH class as other branch instrucitons
	like B, Bcc, etc. However, DBNZ is the only branch instruction
	that stores a branch offset in the second operand. Thus it must
	be placed in a distinct class and treated differently.

	For example, current logic of arc_insn_get_branch_target in GDB
	assumes that a branch offset is always stored in the first operand
	for BRANCH class and it's wrong for DBNZ.

	include/ChangeLog:

	2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

		* opcode/arc.h (enum insn_class_t): Add DBNZ class.

	opcodes/ChangeLog:

	2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

		* arc-tbl.h (dbnz): Use "DBNZ" class.
		* arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class.

	gas/ChangeLog:

	2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

		* config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ".

2024-02-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix another fail and tcl error in gdb.dap/sources.exp
	With gdb.dap/sources.exp on aarch64-linux, I'm running into:
	...
	{"request_seq": 3, "type": "response", "command": "loadedSources", \
	  "success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M
	^M
	{"type": "event", "event": "thread", \
	  "body": {"reason": "started", "threadId": 1}, \
	  "seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success
	ERROR: tcl error sourcing gdb.dap/sources.exp.
	ERROR: tcl error code TCL LOOKUP DICT body
	ERROR: key "body" not known in dictionary
	    while executing
	"dict get [lindex $obj 0] body sources"
	...

	These are the same type of tcl error and FAIL I just fixed for a later
	request in the same test-case.

	Fix this by:
	- moving the wait-for-stop to before the loadedSources request to fix the
	  FAIL, and
	- checking for $obj == "" to fix the tcl error.

	Also make the code a bit less indented and more readable by wrapping the tests
	in a proc, allowing the use of return to bail out, while still running
	dap_shutdown afterwards.

	Approved-By: Tom Tromey <tom@tromey.com>

	Tested on aarch64-linux.

2024-02-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-13  Yuriy Kolerov  <kolerov93@gmail.com>

	arc: Don't use multiline in arc-disassembler-options.exp test
	Breaking a TCL string to several lines leads to adding of extra
	symbols to the resulting expect string. In turn, this leads to
	failing of all test cases in gdb.arch/arc-disassembler-options.exp
	testsuite. It's necessary to use multi_line function in such
	cases.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix fail in gdb.dap/sources.exp
	With test-case gdb.dap/sources.exp, I run into:
	...
	{"request_seq": 4, "type": "response", "command": "source", \
	  "success": false, "message": "notStopped", \
	  "seq": 11}FAIL: gdb.dap/sources.exp: get source success
	...

	The fail happens because the request races with the stopping at main as
	requested by:
	...
	if {[dap_launch $testfile stop_at_main 1] == ""} {
	...

	Fix this by waiting for the stop, in the same way that is done in other
	test-cases that use stop_at_main.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31374
	https://sourceware.org/bugzilla/show_bug.cgi?id=31374

2024-02-13  Jaydeep Patil  <jaydeep.patil@imgtec.com>

	sim: riscv: Add support for compressed integer instructions
	Added support for simulation of compressed integer instruction set ("c").
	Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions.
	The compressed instructions are available for models implementing C extension.
	Such as RV32IC, RV64IC, RV32GC, RV64GC etc.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix tcl error in gdb.dap/sources.exp
	With test-case gdb.dap/sources.exp, I run into:
	...
	{"request_seq": 4, "type": "response", "command": "source", \
	  "success": false, "message": "notStopped", \
	  "seq": 11}FAIL: gdb.dap/sources.exp: get source success
	ERROR: tcl error sourcing gdb.dap/sources.exp.
	ERROR: key "body" not known in dictionary
	...

	The FAIL has been filed as PR dap/31374.

	The ERROR happens because after the FAIL, dap_check_request_and_response
	returns "", and the test-case doesn't check for that.

	Fix this by checking for $obj != "" in the test-case.

	Tested on x86_64-linux.

2024-02-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix reverse execution of LDR(immediate) T4
	When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with
	target board unix/-mthumb, we run into:
	...
	(gdb) reverse-step
	func2 () at func-map-to-same-line.c:26
	26	{
	(gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
	  column_info_flag=column-info: step-test: reverse-step into func2
	...

	The FAIL is caused by incorrect recording of this insn:
	...
	4f6:   f85d 7b04       ldr.w   r7, [sp], #4
	...

	The insn updates the sp, but we don't record this:
	...
	$ gdb -q -batch func-map-to-same-line \
	  -ex "b *func2+8" \
	  -ex run \
	  -ex record \
	  -ex "set debug record 2" \
	  -ex stepi
	Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.

	Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
	27	} /* END FUNC2 */
	Process record: arm_process_record addr = 0xaaaaa4f6
	Process record: add register num = 15 to record list.
	Process record: record_full_arch_list_add 0xabc6c460.
	Process record: add register num = 7 to record list.
	Process record: record_full_arch_list_add 0xabc3b868.
	Process record: add register num = 25 to record list.
	...
	[ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]

	The problem is that the specific insn, an LDR(immediate) T4, is not handled in
	thumb2_record_ld_word.

	Fix this by detecting the insn in thumb2_record_ld_word, and recording the
	updated base register.

	Tested on arm-linux.

	Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/31278
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278

2024-02-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-12  Tom Tromey  <tom@tromey.com>

	Introduce bfd_print_error function
	gdb likes to control its own output; for example, this is important
	for gdb's pager, and for logging.  While BFD provides a way to
	intercept error output, via bfd_set_error_handler, it turns out to be
	difficult for this function to truly generate the desired output in a
	gdb-friendly way -- the error handler is expected to implement some
	BFD printf format extensions.

	This patch introduces a new function that an error handler can use to
	format the text.  This way, gdb can set the error handler and arrange
	for the output to be displayed as it likes.

		* bfd.c (bfd_print_callback): Rename from print_func.  Move into
		comment.
		(_bfd_doprnt): Update.
		(bfd_print_error): New function.
		(error_handler_fprintf, error_handler_sprintf): Use
		bfd_print_error.
		* bfd-in2.h: Rebuild.

2024-02-12  Tom Tromey  <tom@tromey.com>

	Do not call fputc from _bfd_doprnt
	I noticed that _bfd_doprnt can unconditionally call fputc.  However,
	when called from error_handler_sprintf, this will likely result in a
	crash, as the stream argument does not actually point to a FILE.

		* bfd.c (_bfd_doprnt): Do not call fputc.

2024-02-12  Tom de Vries  <tdevries@suse.de>

	[gdb] Re-format dap/startup.py with black
	Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made
	some changes to gdb/python/lib/gdb/dap/startup.py.

	Re-format it with black.

2024-02-12  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Catch and log exceptions in dap threads
	When running test-case gdb.dap/eof.exp, it occasionally coredumps.

	The thread triggering the coredump is:
	...
	 #0  0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6
	 #1  0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6
	 #2  0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
	     at gdb/event-top.c:926
	 #3  0x00000000007b0470 in handle_sigsegv (sig=11)
	     at gdb/event-top.c:976
	 #4  <signal handler called>
	 #5  0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=...,
	     format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232
	 #6  0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=...,
	     format=0xffff0c002af1 "%s") at gdb/ui-out.c:584
	 #7  0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=...,
	     format=0x16f93ea "", args=...) at gdb/ui-out.c:621
	 #8  0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...)
	     at gdb/ui-file.c:74
	 #9  0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s",
	     args=...) at gdb/utils.c:1898
	 #10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s")
	     at gdb/utils.c:1913
	 #11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0)
	     at gdb/python/python.c:1464
	 #12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
	 #13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
	     from /lib64/libpython3.12.so.1.0
	 #14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
	    from /lib64/libpython3.12.so.1.0
	 #15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
	 #16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0
	 #17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0
	 #18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0
	 #19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0
	 #20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O ()
	    from /lib64/libpython3.12.so.1.0
	 #21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0
	 #22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
	    from /lib64/libpython3.12.so.1.0
	 #23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
	 #24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0
	 #25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0
	 #26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6
	 #27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6
	...

	The direct cause for the coredump seems to be that cli_ui_out::do_message
	is trying to write to a stream variable which does not look sound:
	...
	(gdb) p *stream
	$8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, {
	        m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}},
	    m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377',
	          m_green = 255 '\377', m_blue = 0 '\000'}}},
	    m_intensity = (unknown: 0x438fe710), m_reverse = 255}}
	...

	The string that is being printed is:
	...
	(gdb) p str
	$9 = "Exception in thread "
	...
	so AFAICT this is a DAP thread running into an exception and trying to print
	it.

	If we look at the state of gdb's main thread, we have:
	...
	 #0  0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6
	 #1  0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 ()
	    from /lib64/libc.so.6
	 #2  0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0
	 #3  0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread ()
	     from /lib64/libpython3.12.so.1.0
	 #4  0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads (
	     this=0xfffffbea1cf8, __in_chrg=<optimized out>)
	     at gdb/python/python-internal.h:769
	 #5  0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60,
	     kw=0x34553d20) at gdb/python/python.c:681
	 #6  0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
	 #7  0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
	     from /lib64/libpython3.12.so.1.0
	 #8  0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
	    from /lib64/libpython3.12.so.1.0
	 #9  0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 ()
	    from /lib64/libpython3.12.so.1.0
	 #10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900)
	     at gdb/python/python.c:1061
	 #11 0x0000000000ab93e8 in std::__invoke_impl<void, gdbpy_event&> (__f=...)
	     at /usr/include/c++/13/bits/invoke.h:61
	 #12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__fn=...)
	     at /usr/include/c++/13/bits/invoke.h:111
	 #13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...)
	     at /usr/include/c++/13/bits/std_function.h:290
	 #14 0x000000000062e0d0 in std::function<void ()>::operator()() const (
	     this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591
	 #15 0x0000000000b67f14 in run_events (error=0, client_data=0x0)
	     at gdb/run-on-main-thread.c:76
	 #16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1)
	     at gdbsupport/event-loop.cc:573
	 #17 0x000000000157e760 in gdb_wait_for_event (block=1)
	     at gdbsupport/event-loop.cc:694
	 #18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1)
	     at gdbsupport/event-loop.cc:264
	 #19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
	 #20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
	 #21 0x000000000094567c in captured_main (data=0xfffffbea23e8)
	     at gdb/main.c:1335
	 #22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8)
	     at gdb/main.c:1354
	 #23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578)
	     at gdb/gdb.c:39
	...

	AFAIU, there's a race between the two threads on gdb_stderr:
	- the DAP thread samples the gdb_stderr value, and uses it a bit later to
	  print to
	- the gdb main thread changes the gdb_stderr value forth and back,
	  using a temporary value for string capture purposes

	The non-sound stream value is caused by gdb_stderr being sampled while
	pointing to a str_file object, and used once the str_file object is already
	destroyed.

	The error here is that the DAP thread attempts to print to gdb_stderr.

	Fix this by adding a thread_wrapper that:
	- catches all exceptions and logs them to dap.log, and
	- while we're at it, logs when exiting
	and using the thread_wrapper for each DAP thread.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-12  Tom Tromey  <tromey@adacore.com>

	Fix DAP launch and configurationDone requests
	Co-workers at AdaCore pointed out that gdb incorrectly implements the
	DAP launch and configurationDone requests.  It's somewhat strange to
	me, but the spec does in fact say that configuration requests should
	occur before the executable is known to gdb.  This was clarified in
	this bug report against the spec:

	    https://github.com/microsoft/debug-adapter-protocol/issues/452

	Fixing 'launch' to start the inferior was straightforward, but this
	then required some changes to how breakpoints are handled.  In
	particular, now gdb will emit the "pending" reason on a breakpoint,
	and will suppress breakpoint events during breakpoint setting.

2024-02-12  Tom Tromey  <tromey@adacore.com>

	Clean up suppress_new_breakpoint_event
	Kévin pointed out that suppress_new_breakpoint_event would do the
	wrong thing if it happened to be used reentrantly.  While I don't
	think this can happen, it's also easy and clearly better to make it
	robust.

	Export dap_initialize
	This changes the test suite to export dap_initialize.

2024-02-12  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: re-format Python files with black 24.1.1
	New year, new black version.

	Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d

2024-02-12  Frederic Cambus  <fred@statdns.com>

	Add support to readelf for the PT_OPENBSD_SYSCALLS segment type.
	binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type.
	include  * elf/common.h (PT_OPENBSD_SYSCALLS): Define.

2024-02-12  Carl Love  <cel@linux.ibm.com>

	rs6000, unwind-on-each-instruction fix.
	The function rs6000_epilogue_frame_cache assumes the LR and gprs have been
	restored.  In fact register r31 and the link register, lr, may not have
	been restored yet.  This patch adds support to store the lr and gpr
	register unrolling rules in the cache.  The LR and GPR values can now be
	unrolled correctly.

	Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp.

2024-02-12  Alexandra Hájková  <ahajkova@redhat.com>

	remote.c: Make packet_check_result return a structure
	packet_check_result currently returns an packet_result enum.
	If GDB will recieve an error in a format E.errtext, which
	is possible for some q packets, such errtext is lost if
	treated by packet_check_result.
	Introduce a new structure which bundles enum packet_result
	with possible error message or error code returned by
	the GDBserver.
	I plan to make more GDBserver response checking functions to use
	packet_check_result to make remote.c code more consistent.
	This will also allow to use E.errtext more in the future.

	Beside adding the unit test, I tested this by modifying
	store_registers_using_G function to get an error message:

	[remote] Sending packet: $GG00000000 ...

	gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793)
	gdbserver: Invalid hex digit 71
	Killing process(es): 1104002
	[remote] Packet received: E01
	Could not write registers; remote failure reply '01'

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2024-02-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix crash when calling Frame.static_link
	If you try to call Frame.static_link for a frame without debug info,
	gdb crashes:
	```
	Temporary breakpoint 1, 0x000000013f821650 in main ()
	(gdb) py print(gdb.selected_frame().static_link())

	This application has requested the Runtime to terminate it in an unusual way.
	Please contact the application's support team for more information.
	```

	The problem was a missing check if get_frame_block returns nullptr
	inside frame_follow_static_link.

	With this, it works:
	```
	Temporary breakpoint 1, 0x000000013f941650 in main ()
	(gdb) py print(gdb.selected_frame().static_link())
	None
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: fix 'set python ignore-environment' white space
	I noticed that the help text for set/show python ignore-environment
	was messed up, some lines had unwanted leading white space, like this:

	  (gdb) help set python ignore-environment
	  Set whether the Python interpreter should ignore environment variables.
	   When enabled GDB's Python interpreter will ignore any Python related
	          flags in the environment.  This is equivalent to passing `-E' to a
	          python executable.
	  (gdb)

	This has been present since the ignore-environment setting was added
	in commit:

	  commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9
	  Date:   Thu Aug 27 16:53:13 2020 +0100

	      gdb: startup commands to control Python extension language

	Fixed in this commit.

2024-02-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-09  Hannes Domani  <ssbssa@yahoo.de>

	Allow value repeat operator on references
	Currently it's not possible to use the value repeat operator on references:
	```
	print ((int &) v_int_array_init[0])@2
	Only values in memory can be extended with '@'.
	```

	This seems like an unnecessary restriction, since it also prevents
	its use on iterators (which was the original reported problem):
	```
	(gdb) p *it@2
	Only values in memory can be extended with '@'.
	```

	So this converts any references to the referenced value in value_repeat,
	making this possible:
	```
	print ((int &) v_int_array_init[0])@2
	$1 = {10, 20}
	(gdb) p *it@2
	$2 = {1, 2}
	```

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-02-09  Peter Bergner  <bergner@linux.ibm.com>

	PowerPC: Add support for Power11 options
	binutils/
		* doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11.

	gas/
		* config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11.
		* doc/c-ppc.texi: Likewise.

	opcodes/
		* ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries.
		(powerpc_init_dialect): Default to "power11".

2024-02-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary nullptr check in remove_user_added_objfile
	Since commit 74daa597e74 ("gdb: add all_objfiles_removed observer"), the
	objfile passed to the free_objfile observable can't be nullptr.

	Change-Id: If215aa051ab43c068b11746938022c7efca09caa
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to clear_solib
	Make the current_program_space reference bubble up one level.

	Remove one unnecessary declaration of clear_solib.

	Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to disable_breakpoints_in_shlibs
	Make the current_program_space reference bubble up one level.

	Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior parameter to breakpoint_init_inferior
	By inspection, I believe that breakpoint_init_inferior doesn't call
	anything that relies on the current program space or inferior.  So,
	add an inferior parameter, to make the current inferior / program space
	references bubble up one level.

	Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to mark_breakpoints_out
	Make the current_program_space reference bubble up one level.

	Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-09  Pedro Alves  <pedro@palves.net>

	Fix crash in aarch64-linux gdbserver
	Since commit 393a6b5947d0 ("Thread options & clone events (Linux
	GDBserver)"), aarch64-linux gdbserver crashes when the inferior
	vforks.  This happens in aarch64_get_debug_reg_state:

	  struct process_info *proc = find_process_pid (pid);

	  return &proc->priv->arch_private->debug_reg_state;

	Here, find_process_pid returns nullptr -- the new inferior hasn't yet
	been created in linux_process_target::handle_extended_wait.

	This patch fixes the problem by having
	linux_process_target::handle_extended_wait create the child process
	earlier, before the child LWP is created.  This is what the function
	did before it was reorganized by the commit referred above.

	Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50
	Co-Authored-By: Tom Tromey <tromey@adacore.com>

2024-02-09  Jan Beulich  <jbeulich@suse.com>

	x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3
	Don't wander into three_byte_table[] when REX2 is present.

	While there also eliminate related confusion when accessing
	dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping
	the odd variable gets things better in sync with 1-byte handling as
	well.

2024-02-09  Jan Beulich  <jbeulich@suse.com>

	x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
	Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't
	even present in the x86-64-apx-egpr-inval testcase, hence why I
	overlooked that these can actually be encoded, (again) using suitable
	AVX512 counterparts.

	While there also "modernize" the adjacent AVX/AVX2 entries.

2024-02-09  Jan Beulich  <jbeulich@suse.com>

	x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}
	In eea4357967b6 ("x86/APX: VROUND{P,S}{S,D} can generally be encoded") I
	failed to add the AVX512* ISA dependency of the two new entries.

	x86: change type of Dwarf2 register numbers in register table
	Already the %bnd<N> registers used numbers beyond 127, and eGPR ones are
	all out of reach for "signed char", at least when CHAR_BITS=8. Switch to
	"unsigned char", covering appropriately in places where the value
	returned for "none" actually matters (in tc_x86_parse_to_dw2regnum()
	this is actually achieved by altering how X_op is set).

2024-02-09  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: fix failing test on Solaris2
	It has been observed that the run of scfi-unsupported-1 test with --x32
	arg on a Solaris2 x86_64 system fails:

	Executing on host: sh -c {../as-new  --x32 --scfi=experimental \
	          <...>/scfi-unsupported-1.s 2>&1}  /dev/null dump.out (timeout = 300)
	Assembler messages:
	Fatal error: no compiled in support for 32bit x86_64
	regexp_diff match failure
	regexp "^Fatal error: SCFI is not supported for this ABI$"
	line   "Fatal error: no compiled in support for 32bit x86_64"
	FAIL: x86_64 scfi-unsupported-1

	Fix the above by adding a check for --x32 support before running the
	test.  While at it, also include a similar check for --32 support.

	gas/testsuite/
		* gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and
		gas_32_check.  Conditionalize the execution of affected
		testcases.

2024-02-09  Alan Modra  <amodra@gmail.com>

	PR 14962 testcase xcoff failure
	Like https://sourceware.org/pipermail/binutils/2002-August/021279.html
	but for symbols defined in an xcoff object but then made absolute by a
	linker script.

		* xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly
		for symbols made absolute by a linker script.

2024-02-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-08  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Fix testing of "info copying"
	gdb.base/default.exp has an incomplete test for the "info copying" command,
	as poetically pointed out by the FIXME removed by this patch.

	The test omits the pattern argument to gdb_test, which causes it to just
	check for a GDB prompt at the end of the command output.

	The problem is that the command output is the whole GPLv3 license, which
	due to its size causes the test to fail sometimes, making the testcase to
	be out of sync with GDB's output and failing the tests that follow
	it. E.g.,

	  FAIL: gdb.base/default.exp: info copying (timeout)
	  FAIL: gdb.base/default.exp: info display
	  FAIL: gdb.base/default.exp: info frame "f" abbreviation
	  PASS: gdb.base/default.exp: info frame
	  FAIL: gdb.base/default.exp: info files
	  FAIL: gdb.base/default.exp: info float
	  FAIL: gdb.base/default.exp: info functions
	  FAIL: gdb.base/default.exp: info locals
	  FAIL: gdb.base/default.exp: info program
	  FAIL: gdb.base/default.exp: info registers
	  FAIL: gdb.base/default.exp: info stack "s" abbreviation

	Fix by by checking for a few excerpts at the beginning, middle and end of
	the license text.  This makes the test consume the command's output in
	smallish chunks.

	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-08  Alan Modra  <amodra@gmail.com>

	PR31208, strip can break ELF alignment requirements
	In https://sourceware.org/pipermail/binutils/2007-August/053261.html
	(git commit 3dea8fca8b86) I disabled a then new linker feature that
	removed empty PT_LOAD headers in cases where a user specified program
	headers, and for objcopy.  This can be a problem for objcopy/strip and
	since objcopy operates on sections, any part of a PT_LOAD loading file
	contents not covered by a section will be omitted anyway.

		PR 31208
		* elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load
		as true to elf_modify_segment_map for objcopy/strip.

2024-02-08  Tom Tromey  <tom@tromey.com>

	Update TUI register window when the inferior exits
	When the inferior exits, the TUI register window should clear.

	Fixing this was mostly a matter of sticking an assignment into
	tui_inferior_exit.  However, some changes to the register window
	itself were also needed.

	While working on this, I realized that the TUI register window would
	not work correctly when moving between frames of different
	architectures.  This patch attempts to fix this as well, though I have
	no way to test it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600
	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Rename show_registers -> set_register_group
	This renames a method on the TUI register window to reflect its real
	purpose.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Return void from tui_show_frame_info
	Nothing uses the tui_show_frame_info result any more, so change it to
	return void.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Remove redundant check from tui_refresh_frame_and_register_information
	tui_refresh_frame_and_register_information checks 'from_stack' in a
	block that's already guarded by a 'from_stack' check.  This patch
	removes the redundant check.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Remove tui_refreshing_registers
	The comment by tui_refreshing_registers mentions a hook that no longer
	exists.  However, maybe the comment is wrong.

	The code paths touching tui_refreshing_registers can only be called in two places:

	1. From the before_prompt observer.  This is only called when a prompt
	   is about to be displayed.

	2. From the register_changed observer.  This is only called when
	   value_assign changes a register value.

	From this it seems clear that the recursion case here cannot in fact
	occur.  This patch removes the variable.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Simplify tui_data_win::erase_data_content
	There's only a single call to tui_data_win::erase_data_content now, so
	remove the parameter and make it just render the "empty window" text.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Remove the TUI register window rerender overload
	After these restructurings, it should be clear that the rerender
	overload can be removed from the TUI register window.  This is done by
	moving a bit more logic from show_registers into update_register_data.
	After this, update_register_data simply updates the internal state,
	and rerender will write to the screen.  All the actual rendering work
	is done, ultimately, by display_registers_from.  This split between
	updating the model and rendering makes it clear that the recursive
	case can't happen any longer.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Simplify update_register_data
	This changes update_register_data to always update the register data.
	The idea here is that this is really only called when either the
	desired register group changes, or when gdb transitions from not
	having a frame to having a frame.

	show_registers is also simplified slightly to account for this.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Move scrollok call in register window
	The register window calls scrollok each time a register is written to
	the window.  However, we only need to call this once, at the start of
	display.  (We could actually call it just once when the window is
	made, but that would involve making another method virtual or adding a
	new member -- both which I think are worse than this approach.)

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Change tui_register_info::visible to a method
	tui_register_info::visible is redundant with the fact that y==0 means
	that the register is not visible.  This patch changes this member in
	favor of having a single indication of the register's visibility -- a
	method with the same name.  This change makes it clear that
	delete_data_content_windows is not needed, so this is removed as well.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Rename tui_data_item_window -> tui_register_info
	tui_data_item_window used to hold a curses window, but we removed that
	ages ago.  Now it just holds information about a single register.
	This patch renames the class to make it more clearly reflect its
	meaning.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Simplify tui_data_window::show_register_group
	This simplifies tui_data_window::show_register_group, renaming it as
	well.  The old method had two loops to iterate over all the registers
	for the arch, but in the new scheme, the vector is set up when
	switching groups, and then updates simply iterate over the vector.

	tui_data_item_window is made self-updating, which also clarifies the
	code somewhat.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Minor C++ cleanups in tui-regs.c
	This changes a couple of spots to use nullptr rather than 0, and
	changes an int to a bool.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Tom Tromey  <tom@tromey.com>

	Use pop_back in tui_register_format
	tui_register_format can use string::pop_back now.

	Tested-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-02-08  Hannes Domani  <ssbssa@yahoo.de>

	Allow calling of C++ methods from python
	Currently it's not possible to call C++ methods from python.
	Using this example:
	```
	class B
	{
	  static int static_func ();
	  int arg0_func ();
	  int arg1_func (int arg1);
	  int arg2_func (int arg1, int arg2);
	};

	B *b_obj = new B;
	```

	Trying to call B::static_func gives this error:
	```
	(gdb) py b_obj = gdb.parse_and_eval('b_obj')
	(gdb) py print(b_obj['static_func']())
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	RuntimeError: Value is not callable (not TYPE_CODE_FUNC).
	Error while executing Python code.
	```

	TYPE_CODE_METHOD was simply missing as a possible type in
	valpy_call, now the same is possible:
	```
	(gdb) py b_obj = gdb.parse_and_eval('b_obj')
	(gdb) py print(b_obj['static_func']())
	1111
	```

	Note that it's necessary to explicitely add the this pointer
	as the first argument in a call of non-static methods:
	```
	(gdb) py print(b_obj['arg0_func']())
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	gdb.error: Too few arguments in function call.
	Error while executing Python code.
	(gdb) py print(b_obj['arg0_func'](b_obj))
	198
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-08  Jens Remus  <jremus@linux.ibm.com>

	gdb: Fix building with clang
	This resolves the following clang++ error message:

	../../gdb/symtab.c:4892:33: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses]
	              if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
	                                       ^
	../../gdb/symtab.c:4892:33: note: add parentheses after the '!' to evaluate the comparison first
	              if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
	                                       ^
	                                        (
	../../gdb/symtab.c:4892:33: note: add parentheses around left hand side expression to silence this warning
	              if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
	                                       ^
	                                       (

	Bug: https://sourceware.org/PR31328

2024-02-08  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Add R_X86_64_CODE_6_GOTTPOFF
	For

		add	%reg1, name@gottpoff(%rip), %reg2

	and

		add	name@gottpoff(%rip), %reg1, %reg2

	add

	 #define R_X86_64_CODE_6_GOTTPOFF		50

	if the instruction starts at 6 bytes before the relocation offset.
	They are similar to R_X86_64_GOTTPOFF.  Linker can covert GOTTPOFF to

		add	$name@tpoff, %reg1, %reg2

	Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate
	R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX,
	R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and
	R_X86_64_CODE_6_GOTTPOFF.

	NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in
	md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this
	stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF
	or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix.

	5 relocations:

	 #define R_X86_64_CODE_5_GOTPCRELX		46
	 #define R_X86_64_CODE_5_GOTTPOFF		47
	 #define R_X86_64_CODE_5_GOTPC32_TLSDESC	48
	 #define R_X86_64_CODE_6_GOTPCRELX		49
	 #define R_X86_64_CODE_6_GOTPC32_TLSDESC	51

	are added for completeness and they are unused.

	bfd/

		* elf64-x86-64.c (x86_64_elf_howto_table): Add
		R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF,
		R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX,
		R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC.
		(R_X86_64_standard): Updated.
		(x86_64_reloc_map): Add R_X86_64_CODE_5_GOTPCRELX,
		R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC,
		R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and
		R_X86_64_CODE_6_GOTPC32_TLSDESC.
		(elf_x86_64_check_tls_transition): Handle
		R_X86_64_CODE_6_GOTTPOFF.
		(elf_x86_64_tls_transition): Likewise.
		(elf_x86_64_scan_relocs): Handle R_X86_64_CODE_6_GOTTPOFF.
		Issue an error for R_X86_64_CODE_5_GOTPCRELX,
		R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC,
		R_X86_64_CODE_6_GOTPCRELX and R_X86_64_CODE_6_GOTPC32_TLSDESC.
		(elf_x86_64_relocate_section): Handle R_X86_64_CODE_6_GOTTPOFF.
		* reloc.c (bfd_reloc_code_real): Add
		BFD_RELOC_X86_64_CODE_5_GOTPCRELX,
		BFD_RELOC_X86_64_CODE_5_GOTTPOFF,
		BFD_RELOC_X86_64_CODE_5_GOTPC32_TLSDESC,
		BFD_RELOC_X86_64_CODE_6_GOTPCRELX,
		BFD_RELOC_X86_64_CODE_6_GOTTPOFF and
		BFD_RELOC_X86_64_CODE_6_GOTPC32_TLSDESC.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Likewise.

	elfcpp/

		* x86_64.h (R_X86_64_CODE_5_GOTPCRELX): New.
		(R_X86_64_CODE_5_GOTTPOFF): Likewise.
		(R_X86_64_CODE_5_GOTPC32_TLSDESC): Likewise.
		(R_X86_64_CODE_6_GOTPCRELX): Likewise.
		(R_X86_64_CODE_6_GOTTPOFF): Likewise.
		(R_X86_64_CODE_6_GOTPC32_TLSDESC): Likewise.

	gas/

		* config/tc-i386.c (tc_i386_fix_adjustable): Handle
		BFD_RELOC_X86_64_CODE_6_GOTTPOFF.
		(md_assemble): Don't check BFD_RELOC_X86_64_CODE_4_GOTTPOFF.
		Allow "add %reg1, foo@gottpoff(%rip), %reg2".
		(output_disp): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF.  Rewrite
		setting fx_tcbitX bits for BFD_RELOC_X86_64_GOTTPOFF,
		BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL.
		(md_apply_fix): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF.
		(i386_validate_fix): Rewrite fx_tcbitX bit checking for
		BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and
		BFD_RELOC_32_PCREL.
		(tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF.
		* testsuite/gas/i386/x86-64-gottpoff.d: Updated.
		* testsuite/gas/i386/x86-64-gottpoff.s: Add tests for
		"add %reg1, foo@gottpoff(%rip), %reg2" and
		"add foo@gottpoff(%rip), %reg, %reg2".

	gold/

		* x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle
		R_X86_64_CODE_6_GOTTPOFF.
		(Target_x86_64::Scan::get_reference_flags): Likewise.
		(Target_x86_64::Scan::local): Likewise.
		(Target_x86_64::Scan::global): Likewise.
		(Target_x86_64::Relocate::relocate): Likewise.
		(Target_x86_64::Relocate::relocate_tls): Likewise.
		(Target_x86_64::Relocate::tls_ie_to_le): Handle.
		R_X86_64_CODE_6_GOTTPOFF.
		* testsuite/x86_64_ie_to_le.s: Add tests for
		"add %reg1, foo@gottpoff(%rip), %reg2" and
		"add foo@gottpoff(%rip), %reg, %reg2".
		* testsuite/x86_64_ie_to_le.sh: Updated.

	include/

		* elf/x86-64.h (elf_x86_64_reloc_type): Add
		R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF,
		R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX,
		R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC.

	ld/

		* testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF
		tests.
		* testsuite/ld-x86-64/tlsbindesc.d: Updated.
		* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.

2024-02-08  Richard W.M. Jones  <rjones@redhat.com>

	PR 31283 windmc: Parse input correctly on big endian hosts
	On big endian hosts (eg. s390x) the windmc tool fails to parse even
	trivial files:

	  $ cat test.mc
	  ;
	  $ ./binutils/windmc ./test.mc
	  In test.mc at line 1: parser: syntax error.
	  In test.mc at line 1: fatal: syntax error.

	The tool starts by reading the input as Windows CP1252 and then
	converting it internally into an array of UTF-16LE, which it then
	processes as an array of unsigned short (typedef unichar).

	There are lots of ways this is wrong, but in the specific case of big
	endian machines the little endian pairs of bytes are byte-swapped.

	For example, the ';' character in the input above is first converted
	to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to
	unsigned short.  On a big endian machine the first unichar appears to
	be 0x3b00.  The lexer is unable to recognize this as the comment
	character ((unichar)';') and so parsing fails.

	The simple fix is to convert the input to UTF-16BE on big endian
	machines (and do the reverse conversion when writing the output).

	Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283

2024-02-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-07  Hannes Domani  <ssbssa@yahoo.de>

	Raise exception if ambiguous name is used in gdb.parameter
	Currently gdb.parameter doesn't raise an exception if an
	ambiguous name is used, it instead returns the value of the
	last partly matching parameter:
	```
	(gdb) show print sym
	Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading.
	(gdb) show print symbol-loading
	Printing of symbol loading messages is "full".
	(gdb) py print(gdb.parameter("print sym"))
	full
	```

	It's because lookup_cmd_composition_1 tries to detect
	ambigous names by checking the return value of find_cmd
	for CMD_LIST_AMBIGUOUS, which never happens, since only
	lookup_cmd_1 returns CMD_LIST_AMBIGUOUS.
	Instead the nfound argument contains the number of found
	matches.

	By using it instead, and by setting *CMD to the special value
	CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show
	the appropriate error message:
	```
	(gdb) py print(gdb.parameter("print sym"))
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	RuntimeError: Parameter `print sym' is ambiguous.
	Error while executing Python code.
	(gdb) py print(gdb.parameter("print symbol"))
	True
	(gdb) py print(gdb.parameter("print symbol-"))
	Traceback (most recent call last):
	  File "<string>", line 1, in <module>
	RuntimeError: Parameter `print symbol-' is ambiguous.
	Error while executing Python code.
	(gdb) py print(gdb.parameter("print symbol-load"))
	full
	```

	Since the document command also uses lookup_cmd_composition, it needed
	to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an
	"Ambiguous command" error message in this case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-07  Hannes Domani  <ssbssa@yahoo.de>

	Fix raw-frame-arguments in combination with frame-filters
	Currently, if frame-filters are active, raw-values is used instead of
	raw-frame-arguments to decide if a pretty-printer should be invoked for
	frame arguments in a backtrace.

	In this example, "super struct" is the output of the pretty-printer:

	    (gdb) disable frame-filter global BasicFrameFilter
	    (gdb) bt
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57

	If no frame-filter is active, then the raw-values print option does not
	affect the backtrace output:

	    (gdb) set print raw-values on
	    (gdb) bt
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
	    (gdb) set print raw-values off

	Instead, the raw-frame-arguments option disables the pretty-printer in the
	backtrace:

	    (gdb) bt -raw-frame-arguments on
	    #0  foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57

	But if a frame-filter is active, the same rules don't apply.
	The option raw-frame-arguments is ignored, but raw-values decides if the
	pretty-printer is used:

	    (gdb) enable frame-filter global BasicFrameFilter
	    (gdb) bt
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
	    (gdb) set print raw-values on
	    (gdb) bt
	    #0  foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
	    (gdb) set print raw-values off
	    (gdb) bt -raw-frame-arguments on
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57

	So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which
	is then used in the frame-filter to override the raw flag in enumerate_args.

	Then the output is the same if a frame-filter is active, the pretty-printer
	for backtraces is only disabled with the raw-frame-arguments option:

	    (gdb) enable frame-filter global BasicFrameFilter
	    (gdb) bt
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
	    (gdb) set print raw-values on
	    (gdb) bt
	    #0  foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
	    (gdb) set print raw-values off
	    (gdb) bt -raw-frame-arguments on
	    #0  foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
	    #1  0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-07  Ciaran Woodward  <ciaranwoodward@xmos.com>

	Remove use of scoped_restore_tmpl from scoped_restore_warning_hook
	The warning_hook_handler function pointer takes va_list as
	an argument, which on some platforms (mingw64) includes some
	attributes. Attributes get ignored in template arguments.
	This led to the compiler warning:

	error: ignoring attributes on template argument 'warning_hook_handler' {aka 'void (*)(const char*, char*)'} [-Werror=ignored-attributes]
	  387 |   scoped_restore_tmpl<warning_hook_handler> m_save;
	      |                                           ^

	By manually implementing the save/restore behaviour, rather
	than using the helper template, this warning is fixed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-07  Alan Modra  <amodra@gmail.com>

	asan: NULL dereference in _bfd_mips_final_write_processing
	Fuzzed object files can easily have unexpected section names.  We
	don't want to segfault on objcopy of any file accepted by the mips
	object_p functions.  For objcopy, an assertion that "sec" is non-NULL
	followed by deferencing "sec" is wrong.  So too is asserting that the
	section name string starts with a particular prefix, and then blithely
	accessing past the assumed prefix.

		* elfxx-mips.c (_bfd_mips_final_write_processing): Replace
		assertions with conditionals.  Don't bother testing for name
		non-NULL.

2024-02-07  Alan Modra  <amodra@gmail.com>

	memory leak in objdump disassemble_section
		* objdump.c (disassemble_section): Free rel_ppstart on error path.

2024-02-07  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly
	PR gas/31326
	SCFI must handle non QWORD ALU with imm and MOV ops correctly

	As per the x86 ISA manual:
	  - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit
	    result in the destination general-purpose register.
	  - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The
	    upper 56 bits or 48 bits (respectively) of the destination
	    general-purpose register are not modified by the operation.

	Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have
	implications on SCFI.  SCFI/ginsn machinery does not track operation size
	in the ginsn representation.  But given that these sub-QWORD ops update
	only a portion of a 64-bit destination register, for SCFI purposes, this
	needs to be deemed as an untraceable update (when the destination is
	REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected
	for stack management, but the SCFI machinery must behave correctly, when
	such ops are indeed present.

	As mentioned earlier, ginsn representation does not carry operation size
	information.  To resolve the issue raised in PR gas/31326, an option is
	to force the generation of GINSN_TYPE_OTHER for all cases when there is
	a 8/16/32 bit op.  But this may dilute the utility of ginsn for other
	use-cases, when they pop up in future.

	The current approach is less disruptive than above in that it generates
	GINSN_TYPE_OTHER for all cases only when:
	  - there is a 8/16/32 bit op, and
	  - the 64-bit op is otherwise traceable.

	In other words this means:
	 - For add/sub ops where dest is reg and src is reg/mem: these always
	   make dest reg untraceable; So, the current handling is unchanged.  We
	   simply skip detecting 8/16/32-bit ops.
	 - An x86 pop instruction is translated to a load ginsn followed by a stack
	   increment add op.  A load op always makes dest reg untraceable.
	   Hence, if the pop instruction is sub-QWORD, we continue to (skip
	   detecting 8/16/32-bit op, and) generate the load instruction as usual.
	   This means that if input asm does have save and restore of unequal sized
	   registers, gas/SCFI will not detect nor warn.
	 - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated
	   when a 8/16/32-bit op is seen.

	gas/
		PR gas/31326
		* config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code
		comment.
		(x86_ginsn_addsub_mem_reg): Likewise.
		(x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early.
		(x86_ginsn_move): Likewise.
		(x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in
	        opcode_space SPACE_BASE) about skipped handling.

	gas/testsuite/:
		PR gas/31326
		* gas/scfi/x86_64/ginsn-add-1.l: Update.
		* gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops.
		* gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update.
		* gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of
		add to invoke and test the ginsn_dw2_regnum code path.

2024-02-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-06  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove core_bfd macro
	The core_bfd macro hides a use of current_program_space.  Remove it, so
	that we have the opportunity to get the program space from the context,
	if possible.  I guess that the macro was introduced at some point to
	replace a global variable of the same name without changing all the
	uses.

	Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-06  H.J. Lu  <hjl.tools@gmail.com>

	x86: Warn .insn instruction with length > 15 bytes
	Change .insn instruction with length > 15 bytes from error to warning.

		PR gas/31323
		* config/tc-i386.c (output_insn): Issue a warning when .insn
		instruction length exceeds the limit of 15 bytes.
		* testsuite/gas/i386/oversized64.s: Add a test for .insn
		* testsuite/gas/i386/oversized64.l: Updated.

2024-02-06  Tiezhu Yang  <yangtiezhu@loongson.cn>

	gdb: LoongArch: Implement the get_syscall_number gdbarch method
	In the current code, the feature 'catch syscall' is not supported
	on LoongArch, implement the "get_syscall_number" gdbarch method to
	get the system call number from the register a7.

	Without this patch:

	(gdb) catch syscall
	The feature 'catch syscall' is not supported on this architecture yet.

2024-02-06  Feiyang Chen  <chenfeiyang@loongson.cn>

	gdb: LoongArch: Add LBT extension support
	Loongson Binary Translation (LBT) is used to accelerate binary
	translation, which contains 4 scratch registers (scr0 to scr3),
	x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This
	patch support gdb to fetch/store these registers.

	Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> #  Framework
	Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>   #  Detail Optimizes
	Signed-off-by: Hui Li <lihui@loongson.cn>             #  Error Fixes

2024-02-06  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add vector extensions support
	Add LoongArch's vector extensions support, which including
	128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX
	(i.e., Loongson Advanced SIMD eXtension). This patch support
	gdb to fetch/store vector registers.

2024-02-06  Alan Modra  <amodra@gmail.com>

	Link x86-64 mark-plt-1.so with --no-as-needed
	Fixes
	FAIL: Build mark-plt-1.so
	where gcc is built with default --as-needed.

		* testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass
		--no-as-needed.

2024-02-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename target_so_ops to solib_ops
	I don't like the name `target_so_ops`, because:

	 - The name `target` is so overloaded, and in this case it's not even
	   related to target_ops or anything else called "target".
	 - We do have an implementation that actually fetches solibs from the
	   target (solib_target_so_op in solib-target.c), so it's confusing for
	   the "base class" to be called target_something as well.

	Rename to solib_ops.

	Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename struct shobj -> struct solib
	`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f
	("gdb: rename struct so_list to shobj")).  In hindsight, `solib` would
	have been a better name.  We have solib.c, the implementations in
	solib-*.c, many functions with solib in their name, the solib_loaded /
	solib_unloaded observables, etc.

	Rename shobj to solib.

	Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-05  Tom Tromey  <tom@tromey.com>

	Remove remnants of partial DIEs from DWARF reader
	When rewriting the DWARF scanner, I forgot to remove
	dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies.  This patch
	corrects the oversight and fixes up a couple other spots that mention
	partial DIEs, which no longer exist.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-02-05  Tom Tromey  <tom@tromey.com>

	Avoid an allocation in attr_to_dynamic_prop
	I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no
	allocation is required.  This patch stack-allocates the object
	instead.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-02-05  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	Fix disabling of year 2038 support on 32-bit hosts by default
	Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
	default") fixed a mismatch between 64-bit time_t in GDB and system headers
	and 32-bit time_t in BFD.

	However, since commit 862776f26a59 ("Finalized intl-update patches")
	gnulib's year 2038 support has been accidentally re-enabled — causing
	problems for 32-bit hosts again.  The commit split baseargs into
	{h,b}baseargs, but this hasn't been done for the code that handles
	--disable-year2038.

	This patch restores the intended behaviour.  With this change, the number
	of unexpected core files goes from 18 to 4.

	Tested on armv8l-linux-gnueabihf.

	Approved-By: Luis Machado <luis.machado@arm.com>

2024-02-05  Tom Tromey  <tromey@adacore.com>

	Handling of arrays with optimized-out bounds
	In Ada, sometimes the compiler must emit array bounds by referencing
	an artificial variable that's created for this purpose.  However, with
	optimization enabled, these variables can be optimized away.

	Currently this can result in displays like:

	    (gdb) print mumble
	    $1 = (warning: unable to get bounds of array, assuming null array
	    )

	This patch changes this to report that the array is optimized-out,
	instead, which is closer to the truth, and more generally useful.  For
	example, Python pretty-printers can now recognize this situation.

	In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT
	enumerator and changed one place to use it.  Reusing the "unknown"
	state wouldn't work properly, because in C it is normal for array
	bounds to be unknown.

2024-02-05  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix use-after-free in arm_exidx_fill_cache
	On arm-linux the linaro CI occasionally reports:
	...
	 (gdb) up 10
	 #4  0x0001b864 in pthread_join ()
	 (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
	...
	while this is expected:
	...
	 (gdb) up 10
	 #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
	 76          pthread_join (thread, NULL);
	 (gdb) PASS: gdb.threads/staticthreads.exp: up 10
	...

	Thiago investigated the problem, and using valgrind found an invalid read in
	arm_exidx_fill_cache.

	The problem happens as follows:
	- an objfile and corresponding per_bfd are allocated
	- some memory is allocated in arm_exidx_new_objfile using
	  objfile->objfile_obstack, for the "exception table entry cache".
	- a symbol reread is triggered, and the objfile, including the
	  objfile_obstack, is destroyed
	- a new objfile is allocated, using the same per_bfd
	- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
	  it doesn't allocate any new memory for the "exception table entry cache".
	- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
	  and we have a use-after-free.

	This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
	information per-bfd instead of per-objfile"), which changed the "exception
	table entry cache" from per-objfile to per-bfd, but failed to update the
	obstack_alloc.

	Fix this by using objfile->per_bfd->storage_obstack instead of
	objfile->objfile_obstack.

	I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
	fixes it.

	Tested on arm-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

	PR tdep/31254
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

2024-02-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-04  Tom Tromey  <tom@tromey.com>

	Use reference result of emplace_back
	Starting with C++17, emplace_back returns a reference to the new
	object.  This patch changes code that uses emplace_back followed by a
	call to back() to simply use this reference instead.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-02-04  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab
	When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a
	TLS symbol and we should set its type to TLS in the symtab.  Otherwise
	when building Perl with gcc-14 -flto, we get:

	/usr/bin/ld: PL_current_context: TLS definition in
	./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference
	in ./miniperl.ltrans1.ltrans.o

	A minimal reproducer:

	    $ cat t1.s
	    .section .tbss
	    .globl x
	    x: .word 0
	    $ cat t2.s
	    f:
	      lu12i.w $a0, %le_hi20_r(x)
	      add.d   $a0, $a0, $tp, %le_add_r(x)
	      li.w    $a1, 1
	      st.w    $a1, $a0, %le_lo12_r(x)
	    $ gas/as-new t1.s -o t1.o
	    $ gas/as-new t2.s -o t2.o
	    $ ld/ld-new t1.o t2.o
	    ld/ld-new: x: TLS definition in t1.o section .tbss mismatches
	    non-TLS reference in t2.o

	Unfortunately this was undetected before Binutils-2.42 release because
	GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a
	TLS LE definition and its reference in two different translation units.
	So this fix should be backported to Binutils-2.42 branch too.

2024-02-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-02  Andrew Burgess  <aburgess@redhat.com>

	gdb: attach to a process when the executable has been deleted
	Bug PR gdb/28313 describes attaching to a process when the executable
	has been deleted.  The bug is for S390 and describes how a user sees a
	message 'PC not saved'.

	On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but
	instead I see this:

	  (gdb) attach 901877
	  Attaching to process 901877
	  No executable file now.
	  warning: Could not load vsyscall page because no executable was specified
	  0x00007fa9d9c121e7 in ?? ()
	  (gdb) bt
	  #0  0x00007fa9d9c121e7 in ?? ()
	  #1  0x00007fa9d9c1211e in ?? ()
	  #2  0x0000000000000007 in ?? ()
	  #3  0x000000002dc8b18d in ?? ()
	  #4  0x0000000000000000 in ?? ()
	  (gdb)

	Notice that the addresses in the backtrace don't seem right, quickly
	heading to 0x7 and finally ending at 0x0.

	What's going on, in both the s390 case and the x86-64 case is that the
	architecture's prologue scanner is going wrong and causing the stack
	unwinding to fail.

	The prologue scanner goes wrong because GDB has no unwind information.

	And GDB has no unwind information because, of course, the executable
	has been deleted.

	Notice in the example session above we get this line in the output:

	  No executable file now.

	which indicates that GDB failed to find an executable to debug.

	For GNU/Linux when GDB tries to find an executable for a given pid we
	end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c.
	Within this function we call `readlink` on /proc/PID/exe to find the
	path of the actual executable.

	If the `readlink` call fails then we already fallback on using
	/proc/PID/exe as the path to the executable to debug.

	However, when the executable has been deleted the `readlink` call
	doesn't fail, but the path that is returned points to a non-existent
	file.

	I propose that we add an `access` call to linux_proc_pid_to_exec_file
	to check that the target file exists and can be read.  If the target
	can't be read then we should fall back to /proc/PID/exe (assuming that
	/proc/PID/exe can be read).

	Now on x86-64 the output looks like this:

	  (gdb) attach 901877
	  Attaching to process 901877
	  Reading symbols from /proc/901877/exe...
	  Reading symbols from /lib64/libc.so.6...
	  (No debugging symbols found in /lib64/libc.so.6)
	  Reading symbols from /lib64/ld-linux-x86-64.so.2...
	  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	  0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
	  (gdb) bt
	  #0  0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
	  #1  0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6
	  #2  0x000000000040117e in spin_forever () at attach-test.c:17
	  #3  0x0000000000401198 in main () at attach-test.c:24
	  (gdb)

	which is much better.

	I've also tagged the bug PR gdb/29782 which concerns the test
	gdb.server/connect-with-no-symbol-file.exp.  After making this change,
	when running gdb.server/connect-with-no-symbol-file.exp GDB would now
	pick up the /proc/PID/exe file as the executable in some cases.

	As GDB is not restarted for the multiple iterations of this test
	GDB (or rather BFD) would given a warning/error like:

	  (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect
	  set sysroot target:
	  BFD: reopening /proc/3283001/exe: No such file or directory
	  (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot

	What's happening is that an executable found for an earlier iteration
	of the test is still registered for the inferior when we are setting
	up for a second iteration of the test.  When the sysroot changes, if
	there's an executable registered GDB tries to reopen it, but in this
	case the file has disappeared (the previous inferior has exited by
	this point).

	I did think about maybe, when the executable is /proc/PID/exe, we
	should auto-delete the file from the inferior.  But in the end I
	thought this was a bad idea.  Not only would this require a lot of
	special code in GDB just to support this edge case: we'd need to track
	if the exe file name came from /proc and should be auto-deleted, or
	we'd need target specific code to check if a path should be
	auto-deleted.....

	... in addition, we'd still want to warn the user when we auto-deleted
	the file from the inferior, otherwise they might be surprised to find
	their inferior suddenly has no executable attached, so we wouldn't
	actually reduce the number of warnings the user sees.

	So in the end I figured that the best solution is to just update the
	test to avoid the warning.  This is easily done by manually removing
	the executable from the inferior once each iteration of the test has
	completed.

	Now, in bug PR gdb/29782 GDB is clearly managing to pick up an
	executable from the NFS cache somehow.  I guess what's happening is
	that when the original file is deleted /proc/PID/exe is actually
	pointing to a file in the NFS cache which is only deleted at some
	later point, and so when GDB starts up we do manage to associate a
	file with the inferior, this results in the same message being emitted
	from BFD as I was seeing.  The fix included in this commit should also
	fix that bug.

	One final note:  On x86-64 GNU/Linux, the
	gdb.server/connect-with-no-symbol-file.exp test will produce 2 core
	files.  This is due to a bug in gdbserver that is nothing to do with
	this test.  These core files are created before and after this
	commit.  I am working on a fix for the gdbserver issue, but will post
	that separately.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-02  H.J. Lu  <hjl.tools@gmail.com>

	x86: Disallow instructions with length > 15 bytes
	It is a hard error when an instruction length exceeds the limit of 15
	bytes:

	[hjl@gnu-cfl-3 tmp]$ cat x.s
		.text
		xacquire lock addq $0x11223344, %fs:(,%eax)
	[hjl@gnu-cfl-3 tmp]$ gcc -c x.s
	x.s: Assembler messages:
	x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15
	[hjl@gnu-cfl-3 tmp]$ objdump -dw x.o

	x.o:     file format elf64-x86-64

	Disassembly of section .text:

	0000000000000000 <.text>:
	   0:	64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 	xacquire lock (bad)
	   f:	11                   	.byte 0x11
	[hjl@gnu-cfl-3 tmp]$

	and

	[hjl@gnu-cfl-3 tmp]$ cat z.s
		addq $0xe0, %fs:0, %rdx
	[hjl@gnu-cfl-3 tmp]$ as -o z.o z.s
	z.s: Assembler messages:
	z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15
	[hjl@gnu-cfl-3 tmp]$ objdump -dw z.o

	z.o:     file format elf64-x86-64

	Disassembly of section .text:

	0000000000000000 <.text>:
	   0:	64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 	(bad)
		...
	[hjl@gnu-cfl-3 pr31323]$

	Instructions with length > 15 bytes are always invalid.  It is quite easy
	to generate invalid instructions with AVX now.  We should issue an error
	when instruction length exceeds the limit of 15 bytes.

		PR gas/31323
		* config/tc-i386.c (output_insn): Issue an error when instruction
		length exceeds the limit of 15 bytes.
		* testsuite/gas/i386/oversized16.l: Updated.
		* testsuite/gas/i386/oversized64.l: Likewise.
		* testsuite/gas/i386/x86-64-apx-inval.l: New file.
		* testsuite/gas/i386/x86-64-apx-inval.s: Likewise.

2024-02-02  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers
	For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like

	<2><17d>: Abbrev Number: 22 (DW_TAG_variable)
	   <180>   DW_AT_name        : (indirect string, offset: 0x1f1): fptr
	   <184>   DW_AT_type        : <0x214>
	...
	<1><219>: Abbrev Number: 27 (DW_TAG_array_type)
	   <21a>   DW_AT_type        : <0x10e>
	   <216>   DW_AT_associated  : ...

	The 'pointer property' in Fortran is implicitly modeled by adding a
	DW_AT_associated to the type of the variable (see also the
	DW_AT_associated description in DWARF 5).  A Fortran pointer is more
	than an address and thus different from a C pointer.  It is a
	self contained type having additional fields such as, e.g., the rank of
	its underlying array.  This motivates the intended DWARF modeling of
	Fortran pointers via the DW_AT_associated attribute.

	This patch adds support for the sizeof intrinsic by simply dereferencing
	pointer types when encountered during a sizeof evaluation.

	The patch also adds a test for the sizeof intrinsic which was not tested
	before.

	Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-02  Bernhard Heckel  <bernhard.heckel@intel.com>

	gdb, types: Resolve pointer types dynamically
	This commit allows pointers to be dynamic types (on the outmost
	level).  Similar to references, a pointer is considered a dynamic type
	if its target type is a dynamic type and it is on the outmost level.
	Also this commit removes the redundant code inside function
	"value_check_printable" for handling of DW_AT_associated type.

	The pointer resolution follows the one of references.

	This change generally makes the GDB output more verbose.  We are able to
	print more details about a pointer's target like the dimension of an array.

	In Fortran, if we have a pointer to a dynamic type

	  type buffer
	    real, dimension(:), pointer :: ptr
	  end type buffer
	  type(buffer), pointer :: buffer_ptr
	  allocate (buffer_ptr)
	  allocate (buffer_ptr%ptr (5))

	which then gets allocated, we now resolve the dynamic type before
	printing the pointer's type:

	Before:

	  (gdb) ptype buffer_ptr
	  type = PTR TO -> ( Type buffer
	    real(kind=4) :: alpha(:)
	  End Type buffer )

	After:

	  (gdb) ptype buffer_ptr
	  type = PTR TO -> ( Type buffer
	    real(kind=4) :: alpha(5)
	  End Type buffer )

	Similarly in C++ we can dynamically resolve e.g. pointers to arrays:

	  int len = 3;
	  int arr[len];
	  int (*ptr)[len];
	  int ptr = &arr;

	Once the pointer is assigned one gets:

	Before:

	  (gdb) p ptr
	  $1 = (int (*)[variable length]) 0x123456
	  (gdb) ptype ptr
	  type = int (*)[variable length]

	After:

	  (gdb) p ptr
	  $1 = (int (*)[3]) 0x123456
	  (gdb) ptype ptr
	  type = int (*)[3]

	For more examples see the modified/added test cases.

	Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-02  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp
	Improve indentation in the test file by replacing 10 spaces at second level
	with 4 spaces.  This helps to update the test using the right indentation
	in future.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-02-02  Jan Beulich  <jbeulich@suse.com>

	x86: move Q-suffix-to-REX.W translation logic
	By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a
	part of another conditional there. While moving, also drop a pointless
	check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily
	have both been 64-bit ones.

2024-02-02  Jan Beulich  <jbeulich@suse.com>

	x86: actually implement .noopt
	For quite some time we've had support for -O command line options. With
	that ignoring at least .noopt isn't really a good idea.

	Re-purpose the optimize-3 test for testing this directive's effect as
	well.

	As to the doc addition - this uses the same text as is there for the
	{nooptimize} pseudo-prefix, despite me not being convinced of the "size"
	part being fully accurate there (and hence also here).

2024-02-02  Sandra Loosemore  <sloosemore@baylibre.com>

	MAINTAINERS: Update my e-mail address.

2024-02-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-02-01  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: x86: ginsn: adjust ginsns for certain lea ops
	A review comment on the SCFI V4 series was to handle ginsn creation for
	certain lea opcodes more precisely.

	Specifically, we should preferably handle the following two cases of lea
	opcodes similarly:
	  - #1 lea with "index register and scale factor of 1, but no base
	    register",
	  - #2 lea with "no index register, but base register present".

	Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the
	case of #1 above.  For #2, however, the lea insn is translated to either
	a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate
	for displacement is non-zero or not respectively.

	Change the handling in x86_ginsn_lea so that both of the above lea
	manifestations are handled similarly.

	While at it, remove the code paths creating GINSN_TYPE_OTHER altogether
	from the function.  It makes sense to piggy back on the
	x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the
	destination register is interesting.  This was also suggested in one of
	the previous review rounds;  the other functions already follow that
	model, so this keeps functions symmetrical looking.

	gas/
		* gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with
		no base register similar to the case of no index register.  Remove
		creation of GINSN_TYPE_OTHER from the function.

	gas/testsuite/
		* gas/scfi/x86_64/ginsn-lea-1.l: New test.
		* gas/scfi/x86_64/ginsn-lea-1.s: Likewise.
		* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.

2024-02-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Remove unused macros
	gprofng/ChangeLog
	2024-02-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION.
		* common/hwctable.c: Remove DBG_LT* macros.
		* libcollector/envmgmt.c: Likewise.
		* libcollector/hwprofile.c: Likewise.
		* libcollector/iolib.c: Likewise.
		* libcollector/jprofile.c: Likewise.
		* libcollector/memmgr.c: Likewise.
		* libcollector/profile.c: Likewise.
		* libcollector/tsd.c: Likewise.
		* libcollector/unwind.c: Likewise.

2024-02-01  Tom Tromey  <tromey@adacore.com>

	Fix "objstack" typo
	I noticed some comments that mentions "objstack".  The type is
	actually "obstack".  This patch fixes the typos.

2024-02-01  Tom Tromey  <tromey@adacore.com>

	Rename SEARCH_ALL
	The constant SEARCH_ALL conflicts with a define in a Windows header.
	This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the
	conflict.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307

2024-02-01  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix some duplicate test names in gdb.trace/
	This commit fixes some of the easier duplicate test names in the
	gdb.trace/ directory.

	All of these duplicates are resolved by either given tests a name, or
	by extended the existing name to make it more descriptive.

	There should be no change in what is tested after this commit.

2024-02-01  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp
	Fix some duplicate test names in gdb.base/cond-eval-mode.exp when
	running with native-gdbserver or native-extended-gdbserver board
	files.

	I've just added some 'with_test_prefix' blocks to make the test names
	unique, there should be no change in what is tested after this commit.

2024-02-01  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix AIX build break.
	A recent commit broke AIX build. The thread_local type defined functions
	were being considered a weak symbol and hence while creating the binary these
	symbols were not visible.

	This patch is a fix for the same.

2024-02-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-31  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove some unnecessary frame_info_ptr resets
	This code was probably needed before we had reinflatable
	frame_info_ptrs, it's not necessary anymore.

	Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-31  Nick Clifton  <nickc@redhat.com>

	Mention support for AMD/znver5 in GAS

2024-01-31  Georg-Johann Lay  <avr@gjlay.de>

	PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap.
	Supply these symbols as computed by the linker scripts, even when there are weak definitions.
	PR 31124
	  * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.

2024-01-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-30  Tom Tromey  <tromey@adacore.com>

	Really fix Windows gdbserver segment registers
	My earlier attempt to mask the segment registers in gdbserver for
	Windows introduced some bugs.  That patch is here:

	https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html

	The problem turned out to be that these fields in the Windows
	'CONTEXT' type are just 16 bits, so while masking the values on read
	is fine, writing the truncated values back then causes zeros to be
	written to some subsequent field.

	This patch cleans this up by arranging never to write too much data to
	a field.

	I also noticed that two register numbers here were never updated for
	the 64-bit port.  This patch fixes this as well, and renames the "FCS"
	register to follow gdb.

	Finally, this patch applies the same treatment to windows-nat.c.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2024-01-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-29  Alan Modra  <amodra@gmail.com>

	PR31314, chew crashing on use of uninitialized value
	The "drop" call in wrap_comment already increments pc.  Defining DOCDD
	in proto.str is a warning fix.

		PR 31314
		* chew.c (wrap_comment): Don't increment pc.
		* proto.str (DOCDD): Define.

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

	sim: bpf: remove support for ldinddw and ldabsdw instructions
	This patch removes support for the two instructions above from the GNU
	simulator, including the corresponding tests.  These instructions do
	not really exist in BPF and are not recognized as such by the kernel
	verifier.  This has now been pointed out during the standardization of
	the BPF ISA.

2024-01-29  Lancelot SIX  <lancelot.six@amd.com>

	gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.def
	Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the
	sym-domains.def file has been introduced, and requires the user to
	define the DOMAIN(x) macro.

	On older systems (centos-7 with glibc-2.17 for example), this DOMAIN
	macro conflicts with another macro defined in /usr/include/math.h.

	Fix this conflict by changing sym-domains.def to use a macro named
	SYM_DOMAIN instead of DOMAIN.

	Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bfd: restore Threading menu entry in bfd.texi
	I mistakenly vandalized bfd.texi in the commit
	0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the
	manual menu.  This commit reverts that thunk.

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: there is no ldinddw nor ldabsdw instructions
	There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW.
	For some reason we were (incorrectly) supporting these.  This patch
	updates the opcodes so the instructions get removed and modifies the
	GAS manual and testsuite accordingly.

	See discussion at
	https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev

	Tested in bpf-uknonwn-none target, x86-64-linux-gnu host.

	include/ChangeLog:

	2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and
		BPF_INSN_LDABSDW instructions.

	opcodes/ChangeLog:

	2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and
		BPF_INSN_LDABSDW instructions.

	gas/ChangeLog:

	2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit
		load instruction.
		(BPF Instructions): There is no absolute 64-bit load instruction.
		* testsuite/gas/bpf/mem.s: Update test accordingly.
		* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-be.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
		* testsuite/gas/bpf/mem.d: Likewise.
		* testsuite/gas/bpf/mem.s: Likewise.

2024-01-29  Nick Clifton  <nickc@redhat.com>

	Update release making documentation after 2.42 release

	Remove support for the beos file format

2024-01-29  Hannes Domani  <ssbssa@yahoo.de>

	Fix backtrace limit stopping on inline frame
	If you have set up a backtrace limit, and the backtrace stops
	because of this in an inline frame with arguments, you get an
	assertion failure:
	```
	(gdb) bt
	(gdb) set backtrace limit 2
	(gdb) bt
	C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed.
	```

	And if this one is fixed, there is another one as well:
	```
	(gdb) bt
	C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed.
	```

	The reason for both of them is this kind of loop:
	```
	  while (get_frame_type (frame) == INLINE_FRAME)
	    frame = get_prev_frame (frame);
	```
	Since get_prev_frame respects the backtrace limit, it will return
	NULL, and from there on you can't continue.
	This changes these loops to use get_prev_frame_always instead, so
	you always get a non-inline frame in the end.

	With this backtrace works:
	```
	(gdb) bt
	(gdb)
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-01-29  Nick Clifton  <nickc@redhat.com>

	Updated French translations for GOLD and LD

2024-01-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-28  Tom Tromey  <tom@tromey.com>

	Document new Python and Guile constants
	This documents the new Python and Guile constants introduced earlier
	in this series.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2024-01-28  Tom Tromey  <tom@tromey.com>

	Refine search in cp_search_static_and_baseclasses
	This changes cp_search_static_and_baseclasses to only search for
	types, functions, and modules.  The latter two cases were discovered
	by regression testing.  I found it somewhat surprising the Fortran
	name lookup ends up in this code, but did not attempt to change this.

	Only search for functions in rust_structop::evaluate_funcall
	This changes rust_structop::evaluate_funcall to only search for
	functions.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Only search types in lookup_typename
	This changes lookup_typename to only look for types.  The check for
	LOC_TYPEDEF can now also be removed, because only types will appear in
	TYPE_DOMAIN.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24870

2024-01-28  Tom Tromey  <tom@tromey.com>

	Only search types in cp_lookup_rtti_type
	This changes cp_lookup_rtti_type to only search for types -- not
	functions or variables.  Due to the symbol-matching hack, this could
	just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also
	I hold on to some hope that perhaps the hack can someday be removed.

	Use a function-domain search in inside_main_func
	This changes inside_main_func to search only for functions.

	Only look for functions in expand_symtabs_for_function
	This changes expand_symtabs_for_function to only look in the function
	domain.

	Only search for "main" as a function
	This changes find_main_name to restrict its search to the function
	domain.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Simplify some symbol searches in linespec.c
	This simplifies some symbol searches in linespec.c.  In particular,
	two separate searches here can now be combined into one, due to the
	new use of flags.

	Arguably the STRUCT_DOMAIN searches should perhaps not even be done.
	Only C really has these, and C doesn't have member functions.
	However, it seems relatively harmless -- and clearly compatible -- to
	leave this in.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Simplify some symbol searches in Ada code
	This changes some of the Ada code to simplify symbol searches.  For
	example, if a function is being looked for, the search is narrowed to
	use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT.  In one spot, a
	search of the "struct" domain is removed, because Ada does not have a
	tag domain.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Use the new symbol domains
	This patch changes the DWARF reader to use the new symbol domains.  It
	also adjusts many bits of associated code to adapt to this change.

	The non-DWARF readers are updated on a best-effort basis.  This is
	somewhat simpler since most of them only support C and C++.  I have no
	way to test a few of these.

	I went back and forth a few times on how to handle the "tag"
	situation.  The basic problem is that C has a special namespace for
	tags, which is separate from the type namespace.  Other languages
	don't do this.  So, the question is, should a DW_TAG_structure_type
	end up in the tag domain, or the type domain, or should it be
	language-dependent?

	I settled on making it language-dependent using a thought experiment.
	Suppose there was a Rust compiler that only emitted nameless
	DW_TAG_structure_type objects, and specified all structure type names
	using DW_TAG_typedef.  This DWARF would be correct, in that it
	faithfully represents the source language -- but would not work with a
	purely struct-domain implementation in gdb.  Therefore gdb would be
	wrong.

	Now, this approach is a little tricky for C++, which uses tags but
	also enters a typedef for them.  I notice that some other readers --
	like stabsread -- actually emit a typedef symbol as well.  And, I
	think this is a reasonable approach.  It uses more memory, but it
	makes the internals simpler.  However, DWARF never did this for
	whatever reason, and so in the interest of keeping the series slightly
	shorter, I've left some C++-specific hacks in place here.

	Note that this patch includes language_minimal as a language that uses
	tags.  I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
	which doesn't specify the language for a type unit.  Arguably this
	test case is wrong.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164

2024-01-28  Tom Tromey  <tom@tromey.com>

	Remove old symbol_matches_domain
	Nothing calls the variant of symbol_matches_domain that accepts a
	domain_enum for searching, so this patch removes it and the
	corresponding symbol::matches.

	Remove some obsolete Python constants
	The Python code has exported some constants, but they are no longer
	documented, and were never useful.  This patch removes them.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Use domain_search_flags in lookup_symbol et al
	This changes lookup_symbol and associated APIs to accept
	domain_search_flags rather than a domain_enum.

	Note that this introduces some new constants to Python and Guile.  I
	chose to break out the documentation patch for this, because the
	internals here do not change until a later patch, and it seemed
	simpler to patch the docs just once, rather than twice.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Use domain_search_flags in lookup_global_symbol_language
	This changes quick_symbol_functions::lookup_global_symbol_language to
	accept domain_search_flags rather than just a domain_enum, and fixes
	up the fallout.

	To avoid introducing any regressions, any code passing VAR_DOMAIN now
	uses SEARCH_VFT.

	That is, no visible changes should result from this patch.  However,
	it sets the stage to refine some searches later on.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Introduce "scripting" domains
	The Python and Guile code exposed the internal domain constants both
	as attributes of symbols and as values to pass to lookup functions.

	Now, perfect backward compatibility here can't be achieved: some
	symbols are going to have domain changes by the end of this series.
	However, it seemed to me that we can preserve lookups using the basic
	domain values.

	This patch implements this by exporting the "or"-able search constants
	with an extra bit set.  Then it introduces some functions to convert
	such constants to domain_search_flags.  This will be used by the
	Python and Guile code, so that both old- and new-style lookups will
	work properly; and while preserving the idea that the domain constants
	can be compared to a symbol's domain.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Remove a check of VAR_DOMAIN
	completion_list_add_symbol checks that the returned symbol has
	VAR_DOMAIN, but also checks that its address class is LOC_BLOCK.  The
	domain check is redundant -- only functions can possibly be LOC_BLOCK
	-- and leaving this in place will cause a regression when combined
	with a later patch in this series.  This patch preemptively removes
	the redundant check.

	Replace search_domain with domain_search_flags
	This patch changes gdb to replace search_domain with
	domain_search_flags everywhere.  search_domain is removed.

	Add domain_search_flags
	This adds a new flag enum type, domain_search_flags, which is the flag
	version of domain_enum.  Nothing uses this yet, but the goal here is
	to have all symbol searches and lookups use these flags.  The new
	names are chosen to exactly parallel domain_enum.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Add two new symbol domains
	This adds two new symbol domain constants, TYPE_DOMAIN and
	FUNCTION_DOMAIN.

	Historically, gdb was a C debugger, and the symbol tables continue to
	reflect this.  In particular, symbol domains match the C language,
	with VAR_DOMAIN including variables, functions, and types.

	However, other languages have other approaches to namespacing.  And,
	in any case, it is often useful for other parts of gdb to be able to
	distinguish between some domains at lookup time, without resorting to
	examining a symbol's location -- in some situations, this sort of
	filtering happens too late.

	Nothing uses these new domains yet, but the idea behind the patch is
	to separate symbols into more domains and then let the
	language-specific parts of gdb implement their semantics in terms of
	these categories.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Use a .def file for domain_enum
	Future patches will change and reuse the names from domain_enum.  This
	patch makes this less error-prone by having a single point to define
	these names, using the typical gdb ".def" file.

	Split up a big 'if' in symtab.c
	global_symbol_searcher::add_matching_symbols in symtab.c has a
	gigantic 'if' statement -- 33 lines of conditional expression.  This
	patch splits it up into a series of separate 'if's.

	Simplify symbol_to_info_string
	Thi simplifies symbol_to_info_string, removing the 'kind' parameter
	and instead having it use the symbol's domain.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Remove NR_DOMAINS
	NR_DOMAINS is only used for a static assert, but we no longer need it
	now.  If we add too many constants to this enum, GCC will warn about
	the bitfield overflow:

	    error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’

2024-01-28  Tom Tromey  <tom@tromey.com>

	Give names to unspecified types
	A patch later in this series will change check_typedef to also look in
	the type domain.  This change by itself caused a regression, but one
	that revealed some peculiar behavior.

	The regression is in nullptr_t.exp, where examining a std::nullptr_t
	will change from the correct:

	    typedef decltype(nullptr) std::nullptr_t;

	to

	    typedef void std::nullptr_t;

	Right now, the DWARF reader marks all unspecified types as stub types.
	However, this interacts weirdly with check_typedef, which currently
	does not try to resolve types -- only struct-domain objects.

	My first attempt here was to fix this by changing void types not to be
	stub types, as I didn't see what value that provided.  However, this
	caused another regression, because call_function_by_hand_dummy checks
	for stub-ness:

	  if (values_type == NULL || values_type->is_stub ())
	    values_type = default_return_type;

	I'm not really sure why it does this rather than check for
	TYPE_CODE_VOID.

	While looking into this, I found another oddity: the DWARF reader
	correctly creates a type named 'decltype(nullptr)' when it seems a
	DW_TAG_unspecified_type -- but it creates a symbol named "void"
	instead.

	This patch changes the DWARF reader to give the symbol the correct
	name.  This avoids the regression.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Fix latent bug in mdebugread.c
	mdebugread.c makes a label symbol but puts it into VAR_DOMAIN.  I
	think LABEL_DOMAIN is more appropriate.

	I don't have a way to test this.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Make nsalias.exp more reliable
	nsalias.exp tries to detect a complaint that is issued when expanding
	a CU.  However, the test is a bit funny in that, while gdb does
	currently expand the CU and issue the complaint, it also emits this
	error:

	    No symbol "N100" in current context.

	This series will change gdb such that this CU is not expanded -- which
	makes sense, the symbol in question doesn't actually match the lookups
	that are done.

	So, to make the test more robust, a direct request to expand symtabs
	is done instead.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Fix latent bug in DW_TAG_entry_point handling
	A DW_TAG_entry_point symbol inherits its extern/static property from
	the enclosing subroutine.  This is encoded in new_symbol -- but the
	cooked indexer does not agree.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Small cleanup in DWARF reader
	I noticed a couple of spots in dwarf/read.c:new_symbol that call
	add_symbol_to_list.  However, this function is generally written to
	set list_to_add, and then have a single call to add_symbol_to_list at
	the end.  This patch cleans up this discrepancy.

	Note that new_symbol is overlong and should probably be split up.

2024-01-28  Tom Tromey  <tom@tromey.com>

	Fix bug in cooked index scanner
	Testing this entire series pointed out that the cooked index scanner
	disagrees with new_symbol about certain symbols.  In particular,
	new_symbol has this comment:

	    Ada and Fortran subprograms, whether marked external or
	    not, are always stored as a global symbol, because we want

	This patch updates the scanner to match.

	I don't know why the current code does not cause failures.

	It's maybe worth noting that incremental CU expansion -- creating
	symtabs directly from the index -- would eliminate this sort of bug.

2024-01-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-26  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfi: untraceable control flow should be a hard error
	PR gas/31284

	Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be
	created, and the SCFI machinery bails out with a warning:
	  "Warning: Untraceable control flow for func 'foo'; Skipping SCFI"

	It is, however, better suited if this is a hard error.  Change it to a
	hard error.  Also change the message to skip mentioning "SCFI", because
	the error itself may also useful when ginsns are used for other passes
	(distinct from SCFI) involving GCFG, like a pass to detect if there is
	unreachable code.  Hence, simply say:
	  "Error: untraceable control flow for func 'foo'"

	gas/
	PR gas/31284
		* ginsn.c (ginsn_data_end): Use as_bad instead of as_warn.

	gas/testsuite/
	PR gas/31284
		* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output
		in case of errors.
		* gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning.

2024-01-26  Indu Bhagat  <indu.bhagat@oracle.com>

	x86: testsuite: scfi: adjust COFI testcase
	The testcase for change of flow instructions in its current shape is not
	doing much: it checks that SCFI issues an appropriate warning.  The same
	warning is covered by another testcase (scfi-unsupported-cfg-1); It is
	better to test the ginsn translation instead, for these 'change of flow
	instructions'.

	gas/testsuite/
		* gas/scfi/x86_64/scfi-cofi-1.s: Moved to...
		* gas/scfi/x86_64/ginsn-cofi-1.s: ...here.
		* gas/scfi/x86_64/scfi-x86-64.exp: Adjust tests.
		* gas/scfi/x86_64/scfi-cofi-1.d: Removed.
		* gas/scfi/x86_64/scfi-cofi-1.l: Removed.
		* gas/scfi/x86_64/ginsn-cofi-1.l: New test.

2024-01-26  H.J. Lu  <hjl.tools@gmail.com>

	elf: Rename is_standard_elf to uses_elf_em
	Rename is_standard_elf to uses_elf_em for targets which use elf.em.

	binutils/

		PR ld/31289
		* testsuite/lib/binutils-common.exp (is_standard_elf): Renamed
		to ...
		(uses_elf_em): This.

	ld/

		PR ld/31289
		* testsuite/ld-elf/fatal-warnings-2a.d: Replace is_standard_elf
		with uses_elf_em.
		* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.

2024-01-26  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: move SHA512 instructions to +sha3
	SHA512 instructions were added to the architecture at the same time as SHA3
	instructions, but later than the SHA1 and SHA256 instructions.  Furthermore,
	implementations must support either both or neither of the SHA512 and SHA3
	instruction sets.  However, SHA512 instructions were originally (and
	incorrectly) added to Binutils under the +sha2 flag.

	This patch moves SHA512 instructions under the +sha3 flag, which matches the
	architecture constraints and existing GCC and LLVM behaviour.

2024-01-26  Nick Clifton  <nickc@redhat.com>

	Fix: Stripping Rust static libraries fails because of overly zealous illegal path check
	  PR 31250
	  * objcopy.c (copy_archive): Improve the handling of archives that contain elements with invalid pathnames.

	Remove -pie from command line of fatal-warnings 1a and 1b tests.

2024-01-26  Jan Beulich  <jbeulich@suse.com>

	x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings
	Re-using the entire VEX decode hierarchy for the respective major opcode
	has led to those two also being decoded as-if valid. Follow the earlier
	USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.

	x86/APX: no need to have decode go through x86_64_table[]
	As suggested during review already, all such entries have their first
	slot as Bad_Opcode, so by adding two more enumerators we can avoid doing
	that decode step altogether.

	x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix"
	Adjustments made for the directive (by set_intel_syntax()) need also
	making for the command line option. Break out respective code into a new
	helper function, to also be invoked during command line processing.
	Further also set register_prefix when processing -mnaked-reg.

	x86/APX: optimize MOVBE
	With identical source and destination it can be covered by the NDD-to-
	legacy conversion logic as well, even if in this case the original insn
	doesn't use an NDD encoding. The size savings are even better here, for
	the replacement (BSWAP) not having a ModR/M byte.

2024-01-26  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix a bug of getting relocation type
	The old code works because R_LARCH_RELAX has no symbol index. It causes
	'(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1.

2024-01-26  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Add support for s9 register
	In LoongArch ABI, r22 register can be used as frame pointer or
	static register(s9).

	Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers

2024-01-26  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: ld: Add support for TLS LE symbol with addend
	Add support for TLS LE symbol with addend, such as:
	  lu12i.w $t0, %le_hi20(a + 0x8)
	  ori	  $t0, $t0, %le_lo12(a + 0x8)

2024-01-26  Alan Modra  <amodra@gmail.com>

	Assertion failure dumping .eh_frame_hdr
	dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated
	sections, due to get_encoded_eh_value wrongly returning a full count
	for truncated words.

		* dwarf.c (get_encoded_eh_value): Return zero for truncated words.

2024-01-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove get_gdb_program_name
	Nothing uses it.

	Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7

2024-01-25  H.J. Lu  <hjl.tools@gmail.com>

	elf: Add is_standard_elf
	PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf,
	mn10200-elf, ms1-elf and msp430-elf targets:

	FAIL: ld-elf/fatal-warnings-2a
	FAIL: ld-elf/fatal-warnings-2b
	FAIL: ld-elf/fatal-warnings-3a
	FAIL: ld-elf/fatal-warnings-3b
	FAIL: ld-elf/fatal-warnings-4a
	FAIL: ld-elf/fatal-warnings-4b

	even though PR ld/31289 targets xfail for [is_generic] targets.  These
	targets not only don't use the generic_link_hash_table linker, but also
	don't use the standard ELF emulation.  Add is_standard_elf for ELF
	targets which use the standard ELF emulation and replace [is_generic]
	with ![is_standard_elf] in PR ld/31289 tests.

	binutils/

		PR ld/31289
		* testsuite/lib/binutils-common.exp (is_standard_elf): New.

	ld/

		PR ld/31289
		* testsuite/lib/binutils-common.exp (is_generic): Return 1 for
		fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*,
		moxie-*-moxiebox*, msp430-*-* and mt-*-*.
		* testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic]
		with ![is_standard_elf].
		* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.

2024-01-25  H.J. Lu  <hjl.tools@gmail.com>

	ld: Always call output_unknown_cmdline_warning
	Call output_unknown_cmdline_warning if there are no input files so that

	$ ld -z bad-option

	reports

	ld: warning: -z bad-option ignored
	ld: no input files

	instead of

	ld: no input files

		PR ld/31289
		* ldmain.c (main): Call output_unknown_cmdline_warning if there
		are no input files.

2024-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in vgdb_start
	On Fedora 39 aarch64 I run into:
	...
	(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
	Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
	relaying data between gdb and process 2114437^M
	warning: remote target does not support file transfer, \
	  attempting to access files from local filesystem.^M
	Reading symbols from /lib/ld-linux-aarch64.so.1...^M
	_start () at ../sysdeps/aarch64/dl-start.S:22^M
	warning: 22     ../sysdeps/aarch64/dl-start.S: No such file or directory^M
	(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
	...

	For contrast, on openSUSE Leap 15.4 x86_64 I have:
	...
	(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
	Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
	relaying data between gdb and process 18797^M
	warning: remote target does not support file transfer, \
	  attempting to access files from local filesystem.^M
	Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
	(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
	0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M
	(gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb
	...

	The fail happens in vgdb_start because the regexp only matches the
	"in _start ()" variant, not the "_start () at":
	...
	       gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
	...
	Which variant you get is determined by presence of debug info.

	Fix this by also matching the "_start () at" variant.

	Tested aarch64-linux and x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-25  Andrew Carlotti  <andrew.carlotti@arm.com>

	gas: Update NEWS
	Groups entries by architecture, and update AArch64 content.

2024-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Workaround gcc PR113599
	Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
	[PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
	reported in PR build/31281.

	Work around this by flipping inherit order:
	...
	-class thread_info : public refcounted_object,
	-		    public intrusive_list_node<thread_info>
	+class thread_info : public intrusive_list_node<thread_info>,
	+		    public refcounted_object
	...

	An argument could be made that this isn't necessary, because this occurred in
	an unreleased gcc version.

	However, I think it could be useful when bisecting gcc for other problems in
	building gdb.  Having this workaround means the bisect won't reintroduce the
	problem.  Furthermore, the workaround is harmless.

	Tested on Fedora rawhide x86_64.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281

	[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599

2024-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/eh_return.exp
	On Fedora rawhide aarch64, I run into:
	...
	(gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address
	run ^M
	Starting program: eh_return ^M
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib64/libthread_db.so.1".^M
	[Inferior 1 (process 1113051) exited normally]^M
	(gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited)
	...

	This happens as follows: the test-case sets a breakpoint on the last
	instruction of function eh2:
	...
	(gdb) break *0x00000000004103ec^M
	...
	and expects to hit the breakpoint, but instead the "br x6" is taken:
	...
	   0x00000000004103e0 <+176>:   cbz     x4, 0x4103ec <eh2+188>^M
	   0x00000000004103e4 <+180>:   add     sp, sp, x5^M
	   0x00000000004103e8 <+184>:   br      x6^M
	   0x00000000004103ec <+188>:   ret^M
	...

	In contrast, with fedora f39 we have:
	...
	   0x00000000004103bc <+156>:   ldp     x2, x3, [sp, #48]^M
	   0x00000000004103c0 <+160>:   ldp     x29, x30, [sp, #16]^M
	   0x00000000004103c4 <+164>:   add     sp, sp, #0x50^M
	   0x00000000004103c8 <+168>:   add     sp, sp, x4^M
	   0x00000000004103cc <+172>:   ret^M

	...
	and the breakpoint is reached.

	Fix this by detecting that the breakpoint is not hit, and declaring the test
	unsupported.

	Tested on aarch64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR testsuite/31291
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291

2024-01-25  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix attach-twice.c testcase for AIX.
	Currently, in AIX attach-twice.exp testcase is untested due to the below error.
	gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace'

	This is because in AIX ptrace has five arguments. This patch is a fix for the same such that
	this test case runs in AIX and other targets as well.

2024-01-25  H.J. Lu  <hjl.tools@gmail.com>

	ld: Improve --fatal-warnings for unknown command-line options
	There are 2 problems with --fatal-warnings for unknown command-line
	options:

	1. --fatal-warnings doesn't trigger an error for an unknown command-line
	option when --fatal-warnings is the last command-line option.
	2. When --fatal-warnings triggers an error for an unknown command-line
	option, the message says that the unknown command-line option is ignored.

	This patch queues unknown command-line option warnings and outputs queued
	command-line option warnings after all command-line options have been
	processed so that --fatal-warnings can work for unknown command-line
	options regardless of the order of --fatal-warnings.

	When --fatal-warnings is used, the linker message is changed from

	ld: warning: -z bad-option ignored

	to

	ld: error: unsupported option: -z bad-option

	The above also applies to "-z dynamic-undefined-weak" when the known
	"-z dynamic-undefined-weak" option is ignored.

		PR ld/31289
		* ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning
		to warn the ignored -z dynamic-undefined-weak option.
		* ldmain.c (main): Call output_unknown_cmdline_warnings after
		calling ldemul_after_parse.
		* ldmisc.c (CMDLINE_WARNING_SIZE): New.
		(cmdline_warning_list): Likewise.
		(cmdline_warning_head): Likewise.
		(cmdline_warning_tail): Likewise.
		(queue_unknown_cmdline_warning): Likewise.
		(output_unknown_cmdline_warnings): Likewise.
		* ldmisc.h (queue_unknown_cmdline_warning): Likewise.
		(output_unknown_cmdline_warnings): Likewise.
		* emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use
		queue_unknown_cmdline_warning to warn unknown -z option.
		* testsuite/ld-elf/fatal-warnings-1a.d: New file.
		* testsuite/ld-elf/fatal-warnings-1b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-2a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
		* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.

2024-01-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-24  Alan Modra  <amodra@gmail.com>

	riscv64-pei uninitialised data writing relocs
	Without this patch the r_offset field of struct external_reloc is
	uninitialised when using objcopy.

		* coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define.
		(SWAP_OUT_RELOC_OFFSET): Define.

2024-01-24  Tom Tromey  <tromey@adacore.com>

	Emit stopped event for DAP attach request
	In an earlier patch, I wrote:

	    ...  It also adds some machinery so that attach stops can be
	    suppressed, which I think is the right thing to do.

	However, after some discussions here at AdaCore, I now believe this to
	be incorrect -- while DAP says that expected "continue" events should
	be suppressed, there is no corresponding language for expected "stop"
	events, and indeed "stop" events explicitly mention cases like "step".

	This patch arranges for the stop event to be emitted again.

2024-01-24  Tom Tromey  <tromey@adacore.com>

	Handle DW_AT_endianity on enumeration types
	A user found that gdb would not correctly print a field from an Ada
	record using the scalar storage order feature.  We tracked this down
	to a combination of problems.

	First, GCC did not emit DW_AT_endianity on the enumeration type.
	DWARF does not specify this, but it is an obvious and harmless
	extension.  This was fixed in GCC recently:

	    https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html
	    https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd

	Second, GDB did not handle this attribute on enumeration types.  This
	patch makes this change and adds a test case that will pass with the
	patched GCC.

	So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes
	in, the test case in this patch can be updated to reflect that.

	Reviewed-By: Keith Seitz <keiths@redhat.com>

2024-01-24  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/arm: Fix epilogue frame id
	arm_epilogue_frame_this_id has a comment saying that it fall backs to using
	the current PC if the function start address can't be identified, but it
	actually uses only the PC to make the frame id.

	This patch makes the code match the comment.  Another hint that it's what
	is intended is that arm_prologue_this_id, a function almost identical to
	it, does that.

	The problem was found by code inspection.  It fixes the following testsuite
	failures:

	FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches
	FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1
	FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1
	FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1
	FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic
	FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
	FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
	FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
	FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two

	Tested on arm-linux-gnueabi-hf.

2024-01-24  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: add test for backtracing for threaded inferiors from a corefile
	This patch is based on an out-of-tree patch that fedora has been
	carrying for a while. It tests if GDB is able to properly unwind a
	threaded program in the following situations:
	* regular threads
	* in a signal handler
	* in a signal handler executing on an alternate stack

	And the final frame can either be in a syscall or in an infinite loop.

	The test works by running the inferior until a crash to generate a
	corefile, or until right before the crash. Then applies a backtrace to
	all threads to see if any frame can't be identified, and the order of
	the threads in GDB. Finally, it goes thread by thread and tries to
	collect a large part of the backtrace, to confirm that everything is
	being unwound correctly.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-By:  Luis Machado  <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com>

2024-01-24  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Eliminate unused variable warnings with -DNDEBUG

2024-01-24  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Start a new frag after instructions that can be relaxed
	For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20}
	relocations, start a new frag to get correct eh_frame Call Frame Information
	FDE DW_CFA_advance_loc info.

2024-01-24  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Don't define LoongArch .align
	Gcc may generate "\t.align\t%d,54525952,4\n" before commit
	b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object
	file, we call s_align_ptwo (-4). It result in alignment padding must be a
	multiple of 4 if .align has second parameter.

	Use default s_align_ptwo for .align.

2024-01-24  Paul Iannetta  <piannetta@kalrayinc.com>

	Add myself as the KVX port maintainer
	binutils/ChangeLog:

		* MAINTAINERS: Add myself as the KVX port maintainer.

2024-01-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-23  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Update Architecture Extensions documentation
	Restructure the architecture extensions table, add a new table for architecture
	version dependencies, add missing architecture extensions, and improve some
	extension descriptions.

	aarch64: Include +predres2 in -march=armv8.9-a
	This matches the dependencies in the architecture, in LLVM, and even in the
	original Binutils commit message that mistakenly included it only in armv9.4-a.

2024-01-23  Xi Ruoyao  <xry111@xry111.site>

	[PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42

2024-01-23  Guinevere Larsen  <blarsen@redhat.com>

	gdb: fix "list ." related crash
	When a user attempts to use the "list ." command with an inferior that
	doesn't have debug symbols, GDB would crash. This was reported as PR
	gdb/31256.

	The crash would happen when attempting to get the current symtab_and_line
	for the stop location, because the symtab would return a null pointer
	and we'd attempt to dereference it to print the line.

	This commit fixes that by checking for an empty symtab and erroring out
	of the function if it happens.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-23  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: fix nested braces in struct init
	The op struct includes an array of strings, but doesn't use braces
	around that array when initializing.  This causes a ton of warnings
	when using -Wmissing-braces.  Add them to fix.

	The code this tool generates is the same before & after.

2024-01-23  Jaydeep Patil  <jaydeep.patil@imgtec.com>

	sim: riscv: Fix crash during instruction decoding
	The match_never() function has been removed and thus step_once() crashes
	during instruction decoding. Fixed it by checking for null pointer before
	invoking function attached to match_func member of riscv_opcode structure

2024-01-23  Mike Frysinger  <vapier@gentoo.org>

	sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752]
	Some compilers warn in the frv code:
	sem.c:24343:41: error: incompatible function pointer types passing
	  'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
	  to parameter of type
	  'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]

	This is due to frvbf_h_acc40U_set using UDI for setting the new value,
	but using the common sim_queue_fn_di_write API which uses DI.  The same
	size, but different sign.  We could change frvbf_h_acc40U_set to take a
	DI without changing behavior in practice: the UDI is already passed via
	the queue function which accepts a DI, and frvbf_h_acc40U_set already
	casts the input to UDI before running any operations on it.  However,
	these files are all generated, so manual changes here would be reverted.

	Seems like we can only change the register type for all APIs in the cpu
	definition.  This builds cleanly, and passes sim unittests.  Not sure if
	it's 100% the answer, but seems to be the best we have currently.

	Bug: https://sourceware.org/PR29752

2024-01-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-22  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp (and more)
	Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test
	name.  This happens because have_index calls get_index_type with the
	default test name.  Refactor the test to avoid this, while cleaning a
	few other things, the most important being:

	 - factor out the relocated and unrelocated parts in their own procs
	 - give different names to generated binaries in different variations,
	   such that all binaries are left in the test output directory (this
	   makes it easier to debug a specific variation)

	Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94

2024-01-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 31252 gprofng causes testsuite parallel jobs fail
	Before running our tests, we made a fake installation into ./tmpdir.
	This installation changes libopcodes.la in the build area.
	Gas testing may fail if gas and gprofng tests are run in parallel.

	I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH,
	GPROFNG_SYSCONFDIR are set.
	putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create
	directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used
	to set up LD_PRELOAD).

	gprofng/ChangeLog
	2024-01-19  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31252
		PR gprofng/30808
		* src/envsets.cc (putenv_libcollector_ld_misc): Use
		$GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH.
		* testsuite/config/default.exp: Create a script to run gprofng.
		* testsuite/lib/display-lib.exp: Fix typo.

2024-01-22  Nick Clifton  <nickc@redhat.com>

	Updated Serbian translations for th bfd, gold and opcodes directories

2024-01-22  Mark Wielaard  <mark@klomp.org>

	binutils: Fix calloc argument order in srconv.c
	GCC 14 will warn about calling calloc with swapped size and count
	arguments.

	binutils/srconv.c: In function ‘nints’:
	binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
	  598 |   return (int *) (xcalloc (sizeof (int), x));
	      |                                    ^~~
	binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element

	binutils/

		* srconv.c (nints): Swap xcalloc arguments.
		(wr_du): Likewise.
		(wr_dus): Likewise.

2024-01-22  Mark Wielaard  <mark@klomp.org>

	binutils: Fix calloc argument order in coffgrok.c
	GCC 14 will warn about calling calloc with swapped size and count
	arguments.

	binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’:
	binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
	  116 |   struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section),
	      |                                                                        ^~~~~~
	binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element

	binutils/

		* coffgrok.c (empty_scope): Swap xcalloc arguments.
		(empty_symbol): Likewise.
		(do_lines): Likewise.
		(doit): Likewise.
		(coff_grok): Likewise.

2024-01-22  Mark Wielaard  <mark@klomp.org>

	libsframe: Fix calloc argument order in dump_sframe_header
	GCC14 warns about the order of the arguments to calloc

	libsframe/sframe-dump.c: In function ‘dump_sframe_header’:
	libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
	   70 |   flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN);
	      |                                       ^~~~
	libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element

	Fix this by swapping the size and count arguments.

	libsframe/

		* sframe-dump.c (dump_sframe_header): Swap arguments to calloc

2024-01-22  Mark Wielaard  <mark@klomp.org>

	opcodes: tic4x_disassemble swap xcalloc arguments
	GCC 14 will detect when the size and count arguments of calloc are
	swapped.

	binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’:
	binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
	  710 |       optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE));
	      |                                ^~~~~~~~~~~~
	binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element
	binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
	  712 |       optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE);
	      |                                        ^~~~~~~~~~~~
	binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element

	opcodes/ChangeLog:

		* /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc
		arguments.

2024-01-22  Tom Tromey  <tromey@adacore.com>

	Handle EOF more gracefully in DAP
	A user pointed out that gdb will print a Python exception when it gets
	an EOF in DAP mode.  And, it turns out that an EOF like this also
	causes gdb not to exit.  This is due to the refactoring that moved the
	JSON reader to its own thread -- previously this caused an exception
	to propagate and cause an exit, but now it just leaves the reader
	hung.

	This patch fixes these problems by arranging to handle EOF more
	gracefully.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217

2024-01-22  Tom Tromey  <tromey@adacore.com>

	Fix handling of DW_OP_GNU_push_tls_address
	In one spot, DW_OP_GNU_push_tls_address is handled differently from
	DW_OP_form_tls_address.  However, I think they should always be
	treated identically.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-01-22  Mark Wielaard  <mark@klomp.org>

	sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write}
	m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit

	sim/m32c/gdb-if.c: In function ‘sim_read’:
	sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local]
	  162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length)
	      |                        ~~~~~~~~~^~~
	In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38:
	sim/m32c/cpu.h:83:3: note: shadowed declaration is here
	   83 |   mem,
	      |   ^~~

	Fix this by renaming mem to addr in all sim_read and sim_write functions.
	Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this
	also meant renaming the local addr variable to vma.

2024-01-22  Mark Wielaard  <mark@klomp.org>

	sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.c
	With GCC 14 -Werror=shadow=compatible-local flags the reuse of single
	capital letters used in aarch64/cpustate.h enums

	   88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N)
	      |                                                   ~~~~~~~~~^
	In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27,
	                 from ../../binutils-gdb/sim/aarch64/simulator.c:33:
	  217 |   N = 1 << N_IDX
	      |   ^

	sim/aarch64/simulator.c: In function ‘expand_logical_immediate’:
	sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local]
	sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here

2024-01-22  Mark Wielaard  <mark@klomp.org>

	sim: Fix cc -Werror=shadow=local in cr16/simops.c
	include/opcode/cr16.h defines cc as an enum value, which causes GCC 14
	to warn

	sim/cr16/simops.c: In function ‘cond_stat’:
	sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local]
	  138 | static int cond_stat(int cc)
	      |                      ~~~~^~
	In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26,
	                 from ../../binutils-gdb/sim/cr16/simops.c:39:
	sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here
	  149 |   cc,
	      |   ^~

	Fix this by renaming cc in cr16/simops.c to cond.

2024-01-22  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: relax filename restriction in some gdb.btrace tests
	The test gdb.btrace/tailcall.exp has multiple tests that include the
	filename in the output. When testing with gcc, only a relative path is
	printed, but when using clang, the full file path is printed instead.
	This makes most of those tests fail, with the exception of "record goto
	4" which allows for more characters before the file name. The test
	gdb.btrace/recod_goto.exp suffers with the same issue

	This commit allows for text before the filename. However, instead of how
	the aforementioned "record goto 4", it uses a regexp that doesn't allow
	for newlines, just in case some off output happens.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-22  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: modernize gdb.dwarf2/dw2-noloc.exp
	The test gdb.dwarf2/dw2-noloc.exp predates the dwarf assembler, and uses
	some unreliable assumptions about where global labels get put.
	Specifically, when using clang to compile the test, both labels it uses
	to gauge the adresses of the main function get reshuffled to be side-by-side,
	and the debug information ends up making it look like main's high pc is equal
	to low pc, meaning we never enter the main function's scope, and that leads to
	22 failures because the "main_*" variables are technically never in scope.

	This patch modernizes the aforementioned test to use the dwarf
	assembler, which removes all failures when using clang.  It also renames
	the .c file to be more inline with current standard.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-22  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Fix some test failures about TLS desc and TLS relaxation
	There are two issues causing 11 test failures:

	1. The TLS desc tests are matching the entire disassemble of a linked
	   executable.  But if ld is configured --enable-default-hash-style=gnu
	   (note that most modern distros use this option), the layout of the
	   linked executables will be different and the immediate operands in
	   the linked executables will also be different.  So we add
	   "--hash-style=both" for these tests to cancel the effect of
	   --enable-default-hash-style=gnu, like [x86_64 mark-plt tests].
	2. By default objdump disassemble uses [pseudo-instructions] so "addi.w"
	   is outputed as "li.w", causing mismatches in TLS relaxation tests.
	   We can turn off the pseudo-instruction usage in objdump using "-M
	   no-aliases" to fix them.

	[x86_64 mark-plt tests]: 16666ccc91295d1568c5c2cb0e7600694840dfd9
	[pseudo-instructions]: 17f9439038257b1de0c130a416a9a7645c653cb0

2024-01-22  Tatsuyuki Ishi  <ishitatsuyuki@gmail.com>

	LoongArch: Do not add DF_STATIC_TLS for TLS LE
	TLS LE is exclusively for executables, while DF_STATIC_TLS is for DLLs.
	DF_STATIC_TLS should only be set for TLS IE (and when it's DLL), not LE.

	LoongArch: Use tab to indent assembly in TLSDESC test suite
	The usual convention is to use tabs. Not all test are following this,
	but at least when using tabs, let's use it consistently throughout the
	file.

2024-01-22  Jan Beulich  <jbeulich@suse.com>

	x86/APX: also amend the PUSH2/POP2 testcase
	Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be
	encoded") took care of only half of the remaining issue. Add #pass here
	as well.

2024-01-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-21  Lancelot SIX  <lancelot.six@amd.com>

	gdb/infrun: lazily load curr_frame_id in process_event_stop_test
	A recent(ish) change in gdb/infrun.c made process_event_stop_test load
	debug information where it would not have done so previously.  The
	change is:

	    commit bf2813aff8f2988ad3d53e819a0415abf295c91f
	    AuthorDate: Fri Sep 1 13:47:32 2023 +0200
	    CommitDate: Mon Nov 20 10:54:03 2023 +0100

	        gdb/record: print frame information when exiting a recursive call

	        Currently,  when GDB is reverse stepping out of a function into the same
	        function due to a recursive call, it doesn't print frame information, as
	        reported by PR record/29178. This happens because when the inferior
	        leaves the current frame, GDB decides to refresh the step information,
	        clobbering the original step_frame_id, making it impossible to figure
	        out later on that the frame has been changed.

	        This commit changes GDB so that, if we notice we're in this exact
	        situation, we won't refresh the step information.

	        Because of implementation details, this change can cause some debug
	        information to be read when it normally wouldn't before, which showed up
	        as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
	        isn't a problem, the test was changed to allow for the new output.

	        Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178

	Although there is nothing wrong with this change in principle, it
	happens to break most of the tests in gdb/testsuite/gdb.rocm/*.exp.
	This is because those tests do rely on GDB not loading debug
	information.  This is necessary because the debug information produced
	for AMDGPU code is using DWARF extensions which are not supported by GDB
	at this point.

	In this patch, I propose to use a lazy loading mechanism so the frame_id
	for the current frame is only computed when required instead of when
	entering process_event_stop_test.  The lazy_loader class is currently
	defined locally in infrun.c, but if it turns out to be useful elsewhere,
	it could go somewhere under gdbsupport.

	This patch should restore the behavior GDB had before
	bf2813aff8f2988ad3d53e819a0415abf295c91f when it comes to load debug
	info.

	Another approach could have been to revert
	fb84fbf8a51f5be2e78765508ebd9753af96b492 (gdb/infrun: simplify
	process_event_stop_test) and adjust the implementation of
	bf2813aff8f2988ad3d53e819a0415abf295c91f (gdb/record: print frame
	information when exiting a recursive call).  However, I think that the
	lazy loading works well with the simplification done recently, so I went
	down that route.

	Regression tested on x86_64-linux (Ubuntu 22.04) with AMDGPU support.

	Change-Id: Ib63a162128130d1786a77c98623e9e3dcbc363b7
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2024-01-21  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Do not emit R_LARCH_RELAX for two register macros
	For two register macros (e.g. la.local $t0, $t1, symbol) used in extreme code
	model, do not emit R_LARCH_RELAX relocations.

2024-01-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove SYMBOL_*_OPS macros
	Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in
	favor of methods on struct symbol.  More changes could be done here to
	improve the design and make things safer, but I just wanted to do a
	straightforward change to remove the macros for now.

	Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2024-01-20  Tom Tromey  <tom@tromey.com>

	Simplify DWARF symtab inclusion handling
	In the past, dwarf2_per_cu_data was allocated using malloc, so special
	handling was needed for the vector used for symtab handling.  We
	changed this to use 'new' a while back, so this code can now be
	greatly simplified.

	Regression tested on x86-64 Fedora 38.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-01-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove deprecated_exec_file_display_hook and associated code
	This commit removes deprecated_exec_file_display_hook and the
	associated specify_exec_file_hook.

	The specify_exec_file_hook is used to add a new hook function to
	deprecated_exec_file_display_hook, but is only used from the insight
	debugger.

	I posted a patch to remove the use of specify_exec_file_hook from
	insight, and instead use gdb::observers::executable_changed, this
	patch can be found here (it has now been merged):

	  https://inbox.sourceware.org/insight/6abeb45e97d9004ec331e94cf2089af00553de76.1702379379.git.aburgess@redhat.com/T/#u

	With this merged we can now cleanup the GDB side as this code is now
	unused.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-19  Сергей Чернов  <klen_s@mail.ru>

	Fix remote serial read
	After closing "Bug 30770 - serial.c does not preserve errno correctly"
	https://sourceware.org/bugzilla/show_bug.cgi?id=30770
	remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The
	documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is
	permissible to use recv in the case of a non-socket.

	condition:
	os: Distributor ID:    Ubuntu
	Description:    Ubuntu 23.10
	Release:    23.10
	Codename:    mantic

	libc:
	ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38
	kernel:
	Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
	gdb: build from trank at 15.0.50.20231226-git

	GDB output:
	$ arm-kgp-eabi-gdb
	GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi<rmprofile/lto>_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>)
	15.0.50.20231226-git
	....
	(gdb) tar ext /dev/ttyACM1
	Remote debugging using /dev/ttyACM1
	Remote communication error.  Target disconnected: error while reading: Socket operation on non-socket.
	(gdb)

	after fix gdb work fine

	$ arm-kgp-eabi-gdb -q
	(gdb) tar ext /dev/ttyACM0
	Remote debugging using /dev/ttyACM0
	(gdb) mon swd
	Target voltage: 0.0V
	Available Targets:
	No. Att Driver
	       STM32F40x M4
	(gdb) att 1
	Attaching to Remote target
	warning: No executable has been specified and target does not support
	determining executable automatically.  Try using the "file" command.
	0x08020c80 in ?? ()
	(gdb)

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2024-01-19  Aaron Merey  <amerey@redhat.com>

	gdb/ui-out.h: Fix exception handling in do_with_buffered_output
	Replace throw with throw_exeception in do_with_buffered_output.

	This patch fixes regressions in gdb.dwarf2/dw2-dir-file-name.exp
	caused by commit 519d63439.

	do_with_buffered_output needs to use throw_exception instead of
	throw to ensure that exceptions of the correct type are thrown.
	If using throw, gdb_exception_error may be wrongly converted into
	gdb_exception during print_frame_info.  This prevents the exception
	from being caught in print_stack_frame.

2024-01-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp
	With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into:
	...
	(gdb) attach 7773^M
	Attaching to program: attach-many-short-lived-threads, process 7773^M
	Cannot attach to lwp 7776: Operation not permitted (1)^M
	(gdb) PASS: $exp: iter 1: attach
	info threads^M
	No threads.^M
	(gdb) PASS: $exp: iter 1: no new threads
	set breakpoint always-inserted on^M
	(gdb) PASS: $exp: iter 1: set breakpoint always-inserted on
	break break_fn^M
	Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M
	(gdb) PASS: $exp: iter 1: break break_fn
	continue^M
	The program is not being run.^M
	(gdb) FAIL: $exp: iter 1: break at break_fn: 1 \
	  (the program is no longer running)
	...

	There's some code in the test-case dealing with a similar warning:
	...
	  -re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
	...

	But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be
	traced"), the warning has been changed into an error.

	Fix the FAIL by updating the test-case to expect an error instead of a
	warning.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary NULL checks for return value of value_from_register
	value_from_register can't return nullptr, remove some NULL checks.

	Change-Id: Ia6b32b8f86e593c535e3678a89dffe5544eb7ab0
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-19  H.J. Lu  <hjl.tools@gmail.com>

	ld: Remove scripttempl/elf_chaos.sc
	scripttempl/elf_chaos.sc is unused.  Remove it.

		* scripttempl/elf_chaos.sc: Removed.

2024-01-19  H.J. Lu  <hjl.tools@gmail.com>

	Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc
	Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc which are unused
	after

	commit 3596d8ceb2cdc35b4fd702ee9daace5a2d880174
	Author: Alan Modra <amodra@gmail.com>
	Date:   Wed Apr 18 15:39:34 2018 +0930

	    Remove mips aout, coff, and pe support

	bfd/

		* hosts/mipsbsd.h: Removed.

	ld/

		* scripttempl/mipsbsd.sc: Removed.

2024-01-19  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	ld: fix 32-bit mingw DLL symbol export bug
	I think there's a bug in ld on 32-bit Windows.  Here is a tiny project for reproducing the problem:
	https://github.com/oltolm/ld-mingw32-bug

	A 32-bit DLL exports two stdcall functions "myfunc" and "myfunc64". The functions would normally get
	exported as "myfunc@0" and "myfunc64@0". The "DEF" file exports them as "myfunc" and "myfunc64"
	without the decorations. When you run the executable it shows an error message saying that it cannot
	find "myfunc64".

	I think it happens because the sorting in ld is wrong. I think it should use the exported names
	"myfunc" and "myfunc64", but instead it uses the decorated names "myfunc@0" or "myfunc65@0". The
	ordering of functions in the DLL is different depending on which names you use.

	My patch changes ld to use undecorated exported names for sorting and it seems to fix the problem.
	When I execute ctest in my project, it runs successfully.

2024-01-19  H.J. Lu  <hjl.tools@gmail.com>

	Update x86/APX: VROUND{P,S}{S,D} can generally be encoded
	Append "#pass" to APX tests for targets which pad text sections with NOPs.

		* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Append
		"#pass".
		* testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise.

2024-01-19  Nick Clifton  <nickc@redhat.com>

	Update readelf's and objdump's debug frame displaying feature to include the contents of the .eh_frame_hdr section, if present.

2024-01-19  H.J. Lu  <hjl.tools@gmail.com>

	ld: Put all emulation options in ldlex.h
	For each command line option, parse_args() calls ldemul_parse_args()
	to check if the command line option is an emulation option.  But when
	there is a conflict between the emulation option value and the default
	option value, the default command line option will be processed as if
	the emulation option is used.  Remove PARSE_AND_LIST_PROLOGUE and move
	all emulation options to ldlex.h to avoid conflicts.

		PR ld/31247
		* ldlex.h (option_values): Add all emulation options.
		* emulparams/elf32mcore.sh (PARSE_AND_LIST_PROLOGUE): Removed.
		* emulparams/plt_unwind.sh (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/aarch64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/alphaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/armelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/avrelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/bfin.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/cskyelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/hppaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/ia64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/m68hc1xelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/m68kelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/metagelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/mipself.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/nds32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/nto.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/ppc32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/ppc64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/riscvelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/rxelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/s390.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/scoreelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/spuelf.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/tic6xdsbt.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/vxworks.em (PARSE_AND_LIST_PROLOGUE): Likewise.
		* emultempl/aix.em: Include "ldlex.h".
		(OPTION_XXX): Removed.
		(gld${EMULATION_NAME}_read_file): Replace lineno with linenumber.
		* emultempl/beos.em (OPTION_XXX): Removed.
		* emultempl/elf.em: Include "ldlex.h".
		Don't check PARSE_AND_LIST_PROLOGUE.
		(OPTION_XXX): Removed.
		* emultempl/msp430.em: Include "ldlex.h".
		(OPTION_XXX): Removed.
		* emultempl/pe.em (OPTION_XXX): Removed.
		* emultempl/pep.em (OPTION_XXX): Likewise.
		* emultempl/ticoff.em: Include "ldlex.h".
		(OPTION_XXX): Removed.
		* emultempl/vms.em: Include "ldlex.h".
		(OPTION_XXX): Removed.
		* emultempl/xtensaelf.em (elf32xtensa_size_opt,
		elf32xtensa_no_literal_movement, elf32xtensa_abi): Moved out of
		PARSE_AND_LIST_PROLOGUE.
		(PARSE_AND_LIST_PROLOGUE): Removed.

2024-01-19  Nick Clifton  <nickc@redhat.com>

	Add multilib.am to the list of top level files included in any release created by the src-release.sh script

2024-01-19  Jan Beulich  <jbeulich@suse.com>

	x86-64: Dwarf2 register numbers for %bnd<N>
	I don't see why we shouldn't record them when they have been allocated,
	even if they're (bogusly) named as reserved in the ABI right now.

	x86/APX: VROUND{P,S}{S,D} can generally be encoded
	VRNDSCALE{P,S}{S,D} is the AVX512 generalization of these AVX insns. As
	long as the immediate has the top 4 bits clear, they are equivalent to
	the earlier VEX-encoded insns, and hence can be used to permit use of
	eGPR-s in the memory operand. Since this is the normal way of using
	these insns, also alter the resulting diagnostic to complain about the
	immediate, not the eGPR use.

	x86/APX: be consistent with insn suffixes
	When there's a suitably disambiguating register operand, suffixes are
	generally omitted (unless in suffix-always mode). All NDD insns have a
	suitable register operand, so they shouldn't have suffixes by default.

	x86: drop redundant EVex128 from PUSH2/POP2
	EVexMap4 already covers that.

	x86: support APX forms of U{RD,WR}MSR
	This was missed in 6177c84d5edc ("Support APX GPR32 with extend evex
	prefix").

2024-01-19  Aaron Merey  <amerey@redhat.com>

	gdb: Buffer output streams during events that might download debuginfo
	Introduce new ui_file buffering_file to temporarily collect output
	written to gdb_std* output streams during print_thread, print_frame_info
	and print_stop_event.

	This ensures that output during these functions is not interrupted
	by debuginfod progress messages.

	With the addition of deferred debuginfo downloading it is possible
	for download progress messages to print during these events.
	Without any intervention we can end up with poorly formatted output:

	    (gdb) backtrace
	    [...]
	    #8  0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0
	    function_cache=0x561221b224d0, state=<optimized out>...

	To fix this we buffer writes to gdb_std* output streams while allowing
	debuginfod progress messages to skip the buffers and print to the
	underlying output streams immediately.  Buffered output is then written
	to the output streams.  This ensures that progress messages print first,
	followed by uninterrupted frame/thread/stop info:

	    (gdb) backtrace
	    [...]
	    Downloading separate debug info for /lib64/libpython3.11.so.1.0
	    #8  0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=<optimized out>...

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2024-01-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-18  Tom Tromey  <tom@tromey.com>

	Rewrite .debug_names writer
	This rewrites GDB's .debug_names writer.  It is now closer to the form
	imagined in the DWARF spec.  In particular, names are emitted exactly
	as they appear in the original DWARF.

	In order to make the reader work nicely, some extensions were needed.
	These were all documented in an earlier patch.  Note that in
	particular this writer solves the "main name" problem by putting a
	flag into the table.

	GDB does not use the .debug_names hash table, so it also does not
	write one.  I consider this hash table to be essentially useless in
	general, due to the name canonicalization problem -- while DWARF says
	that writers should use the system demangling style, (1) this style
	varies across systems, so it can't truly be relied on; and (2) at
	least GCC and one other compiler don't actually follow this part of
	the spec anyway.

	It's important to note, though, that even if the hash was somehow
	useful, GDB probably still would not use it -- a sorted list of names
	is needed for completion and performs reasonably well for other
	lookups, so a hash table is just overhead, IMO.

	String emission is also simplified.  There's no need in this writer to
	ingest the contents of .debug_str.

	A couple of tests are updated to reflect the fact that they now "fail"
	because the tests don't include .debug_aranges in the .S file.
	Arguably the .debug_names writer should also create this section; but
	I did not implement that in this series, and there is a separate bug
	about it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549

2024-01-18  Tom Tromey  <tom@tromey.com>

	Export dwarf5_augmentation
	I don't know why gdb had the .debug_names augmentation string in two
	separate places; this patch exports it in one spot, to be used in
	another.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Rewrite .debug_names reader
	This rewrites the .debug_names reader to follow the spec.

	Since it was first written, gdb's .debug_names writer has been
	incorrect -- while the form of the section has been ok, the contents
	have been very gdb-specific.

	This patch fixes the reader side of this equation, rewriting the
	reader to create a cooked index internally -- an important detail
	because it allows for the deletion of a lot of code, and it means the
	various readers will agree more often.

	This reader checks for a new augmentation string.  For the time being,
	all other producers are ignored -- the old GDB ones because they are
	wrong, and clang because it does not emit DW_IDX_parent.  (If there
	are any other producers, I'm unaware of them.)

	While the new reader mostly runs in a worker thread, it does not try
	to distribute its work.  This could be done by partitioning the name
	table.  The parent computations could also be done in parallel after
	all names have been read.  I haven't attempted this.

	Note that this patch temporarily regresses gdb.base/gdb-index-err.exp.
	This test writes an index using gdb -- but at this particular stage,
	gdb cannot read the indexes it creates.  Rather than merge the patches
	into a mega-patch, I've chosen to just accept this temporary
	regression.

	In v1 of this patch, I made the new reader more strict about requiring
	.debug_aranges.  In v2, I've backed this out and kept the previous
	logic.  This solved a few test failures, though it's arguably not the
	right approach.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950

2024-01-18  Tom Tromey  <tom@tromey.com>

	Allow other results in DW_TAG_entry_point test
	DW_TAG_entry_point is implemented by adding a new LOC_BLOCK symbol --
	that is, another function symbol.  However, the test case assumes that
	"bt" will never pick this symbol.

	This assumption seems unwarranted to me, and in fact this test will
	regress with the debug-names target board after the .debug_names
	rewrite.

	This patch changes the test to allow either answer in the backtrace.
	If only the main entry point is desired, then it seems that more work
	must be done to handle DW_TAG_entry_point properly, as nothing
	currently guarantees this property.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Remove some .debug_names tests
	These .debug_names tests were hand-written to mimic clang.  However,
	they are difficult to update, and in any case the new reader won't
	accept clang-generated indices.  Therefore this patch removes these
	tests.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Explicitly expand CUs in dw2-inline-with-lexical-scope.exp
	dw2-inline-with-lexical-scope.exp relies on the main CU being
	expanded.  However, it doesn't guarantee that this actually happens,
	and with the new .debug_names reader, it won't, because the "main"
	program will be found in the index without requiring CU expansion.

	This patch fixes the problem by explicitly expanding the CU in
	question.

	Note that this is an artificial bug -- it occurs because the generated
	.debug_aranges isn't correct.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Fix dw2-zero-range.exp when an index is in use
	dw2-zero-range.exp looks for a certain complaint, but this won't be
	issued when an index is in use.  This patch changes the test to not
	fail in this case.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Empty hash table fix in .debug_names reader
	The handling of an empty hash table in the .debug_names reader is
	slightly wrong.

	Currently the code assumes there is always an array of hashes.
	However, section 6.1.1.4.5 Hash Lookup Table says:

	    The optional hash lookup table immediately follows the list of
	    type signatures.

	and then:

	    The hash lookup table is actually two separate arrays: an array of
	    buckets, followed immediately by an array of hashes.

	My reading of this is that the hash table as a whole is optional, and
	so the hashes will not exist in this case.  (This also makes sense
	because the hashes are not useful without the buckets anyway.)

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950

2024-01-18  Tom Tromey  <tom@tromey.com>

	Remove cooked_index_worker::start_reading
	I noticed that cooked_index_worker::start_reading isn't really needed.
	This patch removes it, and also removes the SCOPED_EXIT, in favor of a
	direct call.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Change cooked_index_worker to abstract base class
	This changes cooked_index_worker to be an abstract base class.  The
	base class implementation is moved to cooked-index.c, and a concrete
	subclass is added to read.c.

	This change is preparation for the new .debug_names reader, which will
	supply its own concrete implementation of the worker.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Do not write the index cache from an index
	The new .debug_names reader will work by creating a cooked index from
	.debug_names.  This patch updates cooked_index::maybe_write_index to
	avoid writing the index in this case.

	However, in order to do this in a clean way, the readers are changed
	so that a nullptr result from index_for_writing means "cannot be
	done", and then the error message is moved into write_dwarf_index
	(where it historically lived).

2024-01-18  Tom Tromey  <tom@tromey.com>

	Move cooked_index_functions to cooked-index.h
	This moves the declaration of cooked_index_functions to
	cooked-index.h.  This makes it visible for use by the rewritten
	.debug_names reader, and it also lets us move the implementation of
	make_quick_functions into cooked-index.c, where it really belongs.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Add language to cooked_index_entry
	This adds a new 'lang' member to cooked_index_entry.  This holds the
	language of the symbol.  This is primarily useful for the new
	.debug_names reader, which will not scan the CUs for languages up
	front.

	This also changes cooked_index_shard::add to return a non-const
	pointer.  This doesn't impact the current code, but is needed for the
	new reader.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Document GDB extensions to DWARF .debug_names
	GDB's new .debug_names implementation uses some extensions.  This
	patch adds some documentation on this to the manual.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-01-18  Tom Tromey  <tom@tromey.com>

	Remove IS_ENUM_CLASS from cooked_index_flag
	I noticed that cooked_index_flag::IS_ENUM_CLASS is not needed.  This
	patch removes it.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Refactor quick-function installation in DWARF reader
	While working on the previous patch, I saw that the handling of
	quick-function installation could be unified
	dwarf2_initialize_objfile.  In particular, at the end of the function,
	if there is an index table, then it can be used to create the quick
	function object.

	This cleanup will be useful when rewriting the .debug_names reader.

2024-01-18  Tom Tromey  <tom@tromey.com>

	Refactor 'maint set dwarf synchronous' handling
	The new .debug_names reader will reuse the background reading
	infrastructure of the cooked index code.  In order to share the
	handling of 'maint set dwarf synchronous' -- and to avoid having to
	export this global -- this patch refactors this to be handled directly
	in dwarf2_initialize_objfile.

2024-01-18  Nick Clifton  <nickc@redhat.com>

	Add note to translators not to translate z/Architecture

	Updated translations for various sub-directories

2024-01-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Call ldd --version in gdb.testsuite/dump-system-info.exp
	Once in a while I'm looking at the gdb.log of an entire testsuite run, and I'm
	trying to establish what glibc version is used.  Sometimes this is possible,
	sometimes not.

	Make this easy by calling ldd --version in test-case
	gdb.testsuite/dump-system-info.exp, which for instance on openSUSE Leap 15.4
	gives:
	...
	$ ldd --version
	ldd (GNU libc) 2.31
	  ...
	$
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-18  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: implement 128-bit register read/writes with sim-endian APIs
	We have APIs in sim-endian for working with 128-bit values like this code
	is already doing for 8/16/32/64-bit values.  Switch over to that to make
	it a bit simpler, and drop the WITH_ALTIVEC check.  The code probably is
	only used when altivec is enabled, but it doesn't add much to always
	compile it in, and avoids #ifdef rot by not actually compiling it.

2024-01-18  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: switch register read/writes to union to avoid aliasing issues
	This code creates a small buffer on the stack w/alloca, then proceeds to
	write to it with a cast to a pointer type based on the register type, then
	reads from it with a cast to a pointer type based on the register size.
	gcc will flags only one of these lines as "maybe used uninitialized", but
	it seems to track back to this memory abuse.

	Create a large union with all the possible types that this code will read
	or write as, and then use those.  It's a bit ugly, but is probably better
	than using raw memcpy's everywhere.

2024-01-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-17  Alan Modra  <amodra@gmail.com>

	PR30824 internal error with -z pack-relative-relocs
	This corrects a counting problem, where prior to relocate_section relr
	encoded relative relocs were allowed when it was known they were on
	even boundaries, but relocate_section can only put relative relocs
	(non-relr) on eight byte boundaries.

		PR 30824
		* elf64-ppc.c (RELR_ALIGN): Define, use throughout.
		(maybe_relr): New function, use throughout.

2024-01-17  H.J. Lu  <hjl.tools@gmail.com>

	Update x86-64: Add -z mark-plt and -z nomark-plt
	Pass --hash-style=both to ld for -z mark-plt tests to support linker
	configured with --enable-default-hash-style=gnu.

		* testsuite/ld-x86-64/mark-plt-1b-x32.d: Pass --hash-style=both
		to ld.
		* testsuite/ld-x86-64/mark-plt-1b.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1d.d: Likewise.

2024-01-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: handle long filenames in gdb.base/startup-with-shell.exp
	I got a report of a failure from Linaro's CI testing for the test
	gdb.base/startup-with-shell.exp.

	Looking at the log I see this:

	  (gdb) PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: inferior started
	  print argv[1]
	  $1 = 0xfffed978 "/home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gdb-gdb.git~master/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-e"...
	  (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: first argument expanded

	Notice that the value of $1 was truncated (indicated by the trailing
	ellipses), and as a result it isn't going to match the expected output
	pattern.

	Avoid this by adding a call to 'set print characters unlimited' which
	allows GDB to print strings of any length.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-01-17  Tom Tromey  <tom@tromey.com>

	Fix crash in struct-with-sig-2.exp with debug-names target board
	When I run the struct-with-sig-2.exp test with the .debug_names-using
	target board, I see a gdb crash.  This happens because the reader
	throws an exception without calling finalize_all_units.  This causes
	an assertion failure later because the number of CUs and TUs doesn't
	match.

	The fix is to clear 'all_units' on failure.

	Approved-By: Tom de Vries <tdevries@suse.de>

2024-01-17  Nick Clifton  <nickc@redhat.com>

	Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling.

2024-01-17  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Adapt R_LARCH_{PCALA,GOT,TLS_IE,TLS_DESC}64_* handling per psABI v2.30
	In LoongArch psABI v2.30, an offset (-8 for LO20 and -12 for HI12)
	should be applied on PC for these reloc types to avoid wrong relocation
	when the instruction sequence crosses a page boundary.

	The lld linker has already adapted the change.  Make it for the bfd
	linker too.

	Link: https://github.com/loongson/la-abi-specs/releases/v2.30
	Link: https://github.com/loongson-community/discussions/issues/17
	Link: https://github.com/llvm/llvm-project/pull/73387

2024-01-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: remove spurious $ in save_vars
	I noticed that running the whole testsuite in serial mode (which means
	all the .exp files are ran in the same TCL environment, one after the
	other) with the native-extended-gdbserver board caused some weird
	failures, for instance a lot of internal errors in the reverse tests,
	like:

	    continue^M
	    Continuing.^M
	    /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/native-extended-gdbserver/src/binutils-gdb/gdb/remot        e.c:6922: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.^M
	    A problem internal to GDB has been detected,^M
	    further debugging may prove unreliable.^M
	    ----- Backtrace -----^M
	    FAIL: gdb.reverse/break-precsave.exp: run to end of main (GDB internal error)

	This only happens after running gdb.multi/attach-while-running.exp.
	That test does not restore GDBFLAGS properly when it's done, it leaves
	`-ex \"maint set target-non-stop on\""` in there, which breaks some
	subsequent tests.  The problem is that this line:

	    save_vars { $::GDBFLAGS } {

	should not use a `$` before the variable name.  Passes the content of
	`::GDBFLAGS` to save_vars, which is not what we want.  We want to pass
	the `::GDBFLAGS` string.  Fix that.

	Change-Id: I5ad32c527795fd10d0d94020e4fd15cebaca3a77

2024-01-15  Tom Tromey  <tom@tromey.com>

	Remove addrmap_fixed::set_entry
	It occurred to me that there is no reason for addrmap_fixed::set_entry
	to exist.  This patch removes it and removes the abstract virtual
	function from the base class.  This then required a few minor changes
	in the DWARF reader.  I consider this a type-safety improvement.

	Tested by rebuilding.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2024-01-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary braces
	Change-Id: I5e96c0f38aa788462ab19a9becfe22030e913c2a

2024-01-15  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Skip SCFI tests for x32 targets
	Since SCFI isn't supported on x32:

	Fatal error: SCFI is not supported for this ABI

	skip SCFI tests for x32 targets.

		PR gas/31245
		* testsuite/gas/scfi/x86_64/scfi-x86-64.exp: Skip for x32
		targets.

2024-01-15  Nick Clifton  <nickc@redhat.com>

	Update HOWTO document after creating the 2.42 branch

	Change version to 2.42.50 and regenerate files

2024-01-15  Mark Wielaard  <mark@klomp.org>

	Regenerate two Makefile.in files to update Copyright headers
	commit 1d506c26d9772bcd84e1a7b3a8c8c5bc602dbf61
	Update copyright year range in header of all files managed by GDB
	updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in
	also sim/Makefile.in was updated, but the Copyright hunks/years
	were off. The first hunk comes from automake 1.15.1 header-vars.am
	and so should have 2017 as last year, the second hunk does come from
	sim/Makefile.am and so should have 2024 as last year.

		* gnulib/Makefile.in: Regenerate.
		* sim/Makefile.in: Likewise.

2024-01-15  Nick Clifton  <nickc@redhat.com>

	Add markers for 2.42 branch

	Update branch/release creation documentation

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Regenerate aarch64-*-2.c files

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>
	    Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: rcpc3: Add FP load/store insns
	Along with the relevant unit-tests, this adds the following rcpc3
	instructions:

	  STL1  { <Vt>.D }[<index>], [<Xn|SP>]
	  LDAP1 { <Vt>.D }[<index>], [<Xn|SP>]

	  LDAPUR <Bt>, [<Xn|SP>{, #<simm>}]
	  LDAPUR <Ht>, [<Xn|SP>{, #<simm>}]
	  LDAPUR <St>, [<Xn|SP>{, #<simm>}]
	  LDAPUR <Dt>, [<Xn|SP>{, #<simm>}]
	  LDAPUR <Qt>, [<Xn|SP>{, #<simm>}]

	  STLUR <Bt>, [<Xn|SP>{, #<simm>}]
	  STLUR <Ht>, [<Xn|SP>{, #<simm>}]
	  STLUR <St>, [<Xn|SP>{, #<simm>}]
	  STLUR <Dt>, [<Xn|SP>{, #<simm>}]
	  STLUR <Qt>, [<Xn|SP>{, #<simm>}]

	with `#<simm>' taking on a signed 8-bit integer value in the range
	[-256,255] and `index' the values 0 or 1.

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Add integer load/store insns
	Along with the relevant unit tests and updates to the existing
	regression tests, this adds support for the following novel rcpc3
	insns:

	  LDIAPP <Wt1>, <Wt2>, [<Xn|SP>]
	  LDIAPP <Wt1>, <Wt2>, [<Xn|SP>], #8
	  LDIAPP <Xt1>, <Xt2>, [<Xn|SP>]
	  LDIAPP <Xt1>, <Xt2>, [<Xn|SP>], #16

	  STILP <Wt1>, <Wt2>, [<Xn|SP>]
	  STILP <Wt1>, <Wt2>, [<Xn|SP>, #-8]!
	  STILP <Xt1>, <Xt2>, [<Xn|SP>]
	  STILP <Xt1>, <Xt2>, [<Xn|SP>, #-16]!

	  LDAPR <Wt>, [<Xn|SP>], #4
	  LDAPR <Xt>, [<Xn|SP>], #8

	  STLR <Wt>, [<Xn|SP>, #-4]!
	  STLR <Xt>, [<Xn|SP>, #-8]!

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Define RCPC3_INSN macro
	This patch adds the necessary macro for encoding FEAT_RCPC3-dependent
	instructions in Binutils.

	aarch64: rcpc3: add support in general_constraint_met_p
	Given the introduction of the new address operand types for rcpc3
	instructions, this patch adds the necessary logic to teach
	`general_constraint_met_p` how to proper handle these.

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: New RCPC3_ADDR operand types
	The particular choices of address indexing, along with their encoding
	for RCPC3 instructions lead to the requirement of a new set of operand
	descriptions, along with the relevant inserter/extractor set.

	That is, for the integer load/stores, there is only a single valid
	indexing offset quantity and offset mode is allowed - The value is
	always equivalent to the amount of data read/stored by the
	operation and the offset is post-indexed for Load-Acquire RCpc, and
	pre-indexed with writeback for Store-Release insns.

	This indexing quantity/mode pair is selected by the setting of a
	single bit in the instruction. To represent these insns, we add the
	following operand types:

	  - AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND
	  - AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB

	In the case of loads and stores involving SIMD/FP registers, the
	optional offset is encoded as an 8-bit signed immediate, but neither
	post-indexing or pre-indexing with writeback is available.  This
	created the need for an operand type similar to
	AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should
	not be checked.

	We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a
	variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield.

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Define address operand fields and inserter/extractors
	Beyond the need to encode any registers involved in data transfer and
	the address base register for load/stores, it is necessary to specify
	the data register addressing mode and whether the address register is
	to be pre/post-indexed, whereby loads may be post-indexed and stores
	pre-indexed with write-back.

	The use of a single bit to specify both the indexing mode and indexing
	value requires a novel function be written to accommodate this for
	address operand insertion in assembly and another for extraction in
	disassembly, along with the definition of two insn fields for use with
	these instructions.

	This therefore defines the following functions:

	  - aarch64_ins_rcpc3_addr_opt_offset
	  - aarch64_ins_rcpc3_addr_offset
	  - aarch64_ext_rcpc3_addr_opt_offset
	  - aarch64_ext_rcpc3_addr_offset

	It extends the `do_special_{encoding|decoding}' functions and defines
	two rcpc3 instruction fields:

	  - FLD_opc2
	  - FLD_rcpc3_size

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Create implicit load/store size calc function
	The allowed immediate offsets in integer rcpc3 load store instructions
	are not encoded explicitly in the instruction itself, being rather
	implicitly equivalent to the amount of data loaded/stored by the
	instruction.

	This leads to the requirement that this quantity be calculated based on
	the number of registers involved in the transfer, either as data
	source or destination registers and their respective qualifiers.

	This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)'
	implemented here, using a cumulative sum of qualifier sizes preceding
	the address operand in the OPNDS operand list argument.

2024-01-15  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: rcpc3: Add +rcpc3 architectural feature support flag
	Indicating the presence of the Armv8.2-a feature adding further
	support for the Release Consistency Model, the `+rcpc3' architectural
	extension flag is added to the list of possible `-march' options in
	Binutils, together with the necessary macro for encoding rcpc3
	instructions.

2024-01-15  Mark Wielaard  <mark@klomp.org>

	bfd: riscv_maybe_function_sym check _bfd_elf_is_local_label_name
	This fixes the ld "Handle no DWARF information" testcase. Which
	currently fails on riscv because a local label name is assumed
	to be the current function name.

	bfd/ChangeLog:

	* elfnn-riscv.c (riscv_maybe_function_sym): Also check
		_bfd_elf_is_local_label_name.

2024-01-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Fix tlbi and tlbip instructions
	There are some tlbi operations that don't have a corresponding tlbip operation,
	but we were incorrectly using the same list for both.  Add the missing tlbi
	*nxs operations, and use the F_REG_128 flag to filter tlbi operations that
	don't have a tlbip analogue.  For increased clarity, I have also used a macro
	to reduce duplication between the 'nxs' and non-'nxs' variants, and added a
	test to verify that no invalid combinations are accepted.

	Additionally, fix two missing checks for AARCH64_OPND_SYSREG_TLBIP that were
	preventing disassembly of tlbip instructions.

2024-01-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Refactor aarch64_sys_ins_reg_supported_p
	Add an aarch64_feature_set field to aarch64_sys_ins_reg, and use this for
	feature checks instead of testing against a list of operand codes.

2024-01-15  Nick Clifton  <nickc@redhat.com>

	nm: Replace --with-symbol-versions with --without-symbol-versions in --help output
	  PR 31243
	  nm: Fix --help output

2024-01-15  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Remove unused BTI feature bit
	OK for master?

2024-01-15  Nick Clifton  <nickc@redhat.com>

	Add generated source files and fix thinko in aarch64-asm.c

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add SVE2.1 Contiguous load/store instructions.
	Hi,

	This patch add support for SVE2.1 instructions ld1q,
	ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	PATCH 5/6][Binutils] aarch64: Add SVE2.1 fmin and fmax instructions.
	Hi,

	This patch add support for SVE2.1 instruction faddqv,
	fmaxnmqv, fmaxqv, fminnmqv and fminqv.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add SVE2.1 dupq, eorqv and extq instructions.
	Hi,

	This patch add support for SVE2.1 instruction dupq, eorqv and extq.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SVE2p1.
	Hi,

	This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature
	along with +sve2p1 optional flag to enabe this feature.

	Also support for following SVE2p1 instructions is added
	addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_SME2p1 instructions.
	Hi,

	This patch add support for FEAT_SME2p1 and "movaz" instructions
	along with the optional flag +sme2p1.

	Following "movaz" instructions are add:
	Move and zero two ZA tile slices to vector registers.
	Move and zero four ZA tile slices to vector registers.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for FEAT_B16B16 instructions.
	Hi,

	This patch add support for SVE2.1 and SME2.1 non-widening BFloat16
	(FEAT_B16B16) instructions.

	Following instructions predicated, unpredicated and indexed
	variants are added in this patch.

	bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm,
	bfmla,bfmls,bfmul and bfsub.

	Regression testing for aarch64-none-elf target and found no regressions.

	Ok for binutils-master?

	Regards,
	Srinath.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas/NEWS: announce the new SCFI command line option

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: testsuite: add an x86 testsuite for SCFI
	The testsuite for SCFI contains target-specific tests.

	When a test is executed with --scfi=experimental command line option,
	the CFI annotations in the test .s files are skipped altogether by the
	GAS for processing.  The CFI directives in the input assembly files are,
	however, validated by running the assembler one more time without
	--scfi=experimental.

	Some testcases are used to highlight those asm constructs that the SCFI
	machinery in GAS currently does not support:

	  - Only System V AMD64 ABI is supported for now. Using either --32 or
	    --x32 with SCFI results in hard error.
	    See scfi-unsupported-1.s.

	  - Untraceable stack-pointer manipulation in function epilougue and prologue.
	    See scfi-unsupported-2.s.

	  - Using Dynamically Realigned Arguement Pointer (DRAP) register to
	    realign the stack.  For SCFI, the CFA must be only REG_SP or REG_FP
	    based.  See scfi-unsupported-drap-1.s

	Some testcases are used to highlight some diagnostics that the SCFI
	machinery in GAS currently issues, with an intent to help user correct
	inadvertent errors in their hand-written asm.  An error is issued when
	GAS finds that input asm is not amenable to correct CFI synthesis.

	  - (#1) "Warning: SCFI: Asymetrical register restore"
	  - (#2) "Error: SCFI: usage of REG_FP as scratch not supported"
	  - (#3) "Error: SCFI: unsupported stack manipulation pattern"

	In case of (#2) and (#3), SCFI generation is skipped for the respective
	function.  Above is a subset of the warnings/errors implemented in the
	code.

	gas/testsuite/:
		* gas/scfi/README: New test.
		* gas/scfi/x86_64/ginsn-add-1.l: New test.
		* gas/scfi/x86_64/ginsn-add-1.s: New test.
		* gas/scfi/x86_64/ginsn-dw2-regnum-1.l: New test.
		* gas/scfi/x86_64/ginsn-dw2-regnum-1.s: New test.
		* gas/scfi/x86_64/ginsn-pop-1.l: New test.
		* gas/scfi/x86_64/ginsn-pop-1.s: New test.
		* gas/scfi/x86_64/ginsn-push-1.l: New test.
		* gas/scfi/x86_64/ginsn-push-1.s: New test.
		* gas/scfi/x86_64/scfi-add-1.d: New test.
		* gas/scfi/x86_64/scfi-add-1.l: New test.
		* gas/scfi/x86_64/scfi-add-1.s: New test.
		* gas/scfi/x86_64/scfi-add-2.d: New test.
		* gas/scfi/x86_64/scfi-add-2.l: New test.
		* gas/scfi/x86_64/scfi-add-2.s: New test.
		* gas/scfi/x86_64/scfi-asm-marker-1.d: New test.
		* gas/scfi/x86_64/scfi-asm-marker-1.l: New test.
		* gas/scfi/x86_64/scfi-asm-marker-1.s: New test.
		* gas/scfi/x86_64/scfi-asm-marker-2.d: New test.
		* gas/scfi/x86_64/scfi-asm-marker-2.l: New test.
		* gas/scfi/x86_64/scfi-asm-marker-2.s: New test.
		* gas/scfi/x86_64/scfi-asm-marker-3.d: New test.
		* gas/scfi/x86_64/scfi-asm-marker-3.l: New test.
		* gas/scfi/x86_64/scfi-asm-marker-3.s: New test.
		* gas/scfi/x86_64/scfi-bp-sp-1.d: New test.
		* gas/scfi/x86_64/scfi-bp-sp-1.l: New test.
		* gas/scfi/x86_64/scfi-bp-sp-1.s: New test.
		* gas/scfi/x86_64/scfi-bp-sp-2.d: New test.
		* gas/scfi/x86_64/scfi-bp-sp-2.l: New test.
		* gas/scfi/x86_64/scfi-bp-sp-2.s: New test.
		* gas/scfi/x86_64/scfi-callee-saved-1.d: New test.
		* gas/scfi/x86_64/scfi-callee-saved-1.l: New test.
		* gas/scfi/x86_64/scfi-callee-saved-1.s: New test.
		* gas/scfi/x86_64/scfi-callee-saved-2.d: New test.
		* gas/scfi/x86_64/scfi-callee-saved-2.l: New test.
		* gas/scfi/x86_64/scfi-callee-saved-2.s: New test.
		* gas/scfi/x86_64/scfi-callee-saved-3.d: New test.
		* gas/scfi/x86_64/scfi-callee-saved-3.l: New test.
		* gas/scfi/x86_64/scfi-callee-saved-3.s: New test.
		* gas/scfi/x86_64/scfi-callee-saved-4.d: New test.
		* gas/scfi/x86_64/scfi-callee-saved-4.l: New test.
		* gas/scfi/x86_64/scfi-callee-saved-4.s: New test.
		* gas/scfi/x86_64/scfi-cfg-1.d: New test.
		* gas/scfi/x86_64/scfi-cfg-1.l: New test.
		* gas/scfi/x86_64/scfi-cfg-1.s: New test.
		* gas/scfi/x86_64/scfi-cfg-2.d: New test.
		* gas/scfi/x86_64/scfi-cfg-2.l: New test.
		* gas/scfi/x86_64/scfi-cfg-2.s: New test.
		* gas/scfi/x86_64/scfi-cfi-label-1.d: New test.
		* gas/scfi/x86_64/scfi-cfi-label-1.l: New test.
		* gas/scfi/x86_64/scfi-cfi-label-1.s: New test.
		* gas/scfi/x86_64/scfi-cfi-sections-1.d: New test.
		* gas/scfi/x86_64/scfi-cfi-sections-1.l: New test.
		* gas/scfi/x86_64/scfi-cfi-sections-1.s: New test.
		* gas/scfi/x86_64/scfi-cofi-1.d: New test.
		* gas/scfi/x86_64/scfi-cofi-1.l: New test.
		* gas/scfi/x86_64/scfi-cofi-1.s: New test.
		* gas/scfi/x86_64/scfi-diag-1.l: New test.
		* gas/scfi/x86_64/scfi-diag-1.s: New test.
		* gas/scfi/x86_64/scfi-diag-2.l: New test.
		* gas/scfi/x86_64/scfi-diag-2.s: New test.
		* gas/scfi/x86_64/scfi-dyn-stack-1.d: New test.
		* gas/scfi/x86_64/scfi-dyn-stack-1.l: New test.
		* gas/scfi/x86_64/scfi-dyn-stack-1.s: New test.
		* gas/scfi/x86_64/scfi-enter-1.d: New test.
		* gas/scfi/x86_64/scfi-enter-1.l: New test.
		* gas/scfi/x86_64/scfi-enter-1.s: New test.
		* gas/scfi/x86_64/scfi-fp-diag-2.l: New test.
		* gas/scfi/x86_64/scfi-fp-diag-2.s: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-1.d: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-1.l: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-1.s: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-2.d: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-2.l: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-2.s: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-3.d: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-3.l: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-3.s: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-4.d: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-4.l: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-4.s: New test.
		* gas/scfi/x86_64/scfi-indirect-mov-5.s: New test.
		* gas/scfi/x86_64/scfi-lea-1.d: New test.
		* gas/scfi/x86_64/scfi-lea-1.l: New test.
		* gas/scfi/x86_64/scfi-lea-1.s: New test.
		* gas/scfi/x86_64/scfi-leave-1.d: New test.
		* gas/scfi/x86_64/scfi-leave-1.l: New test.
		* gas/scfi/x86_64/scfi-leave-1.s: New test.
		* gas/scfi/x86_64/scfi-pushq-1.d: New test.
		* gas/scfi/x86_64/scfi-pushq-1.l: New test.
		* gas/scfi/x86_64/scfi-pushq-1.s: New test.
		* gas/scfi/x86_64/scfi-pushsection-1.d: New test.
		* gas/scfi/x86_64/scfi-pushsection-1.l: New test.
		* gas/scfi/x86_64/scfi-pushsection-1.s: New test.
		* gas/scfi/x86_64/scfi-pushsection-2.d: New test.
		* gas/scfi/x86_64/scfi-pushsection-2.l: New test.
		* gas/scfi/x86_64/scfi-pushsection-2.s: New test.
		* gas/scfi/x86_64/scfi-selfalign-func-1.d: New test.
		* gas/scfi/x86_64/scfi-selfalign-func-1.l: New test.
		* gas/scfi/x86_64/scfi-selfalign-func-1.s: New test.
		* gas/scfi/x86_64/scfi-simple-1.d: New test.
		* gas/scfi/x86_64/scfi-simple-1.l: New test.
		* gas/scfi/x86_64/scfi-simple-1.s: New test.
		* gas/scfi/x86_64/scfi-simple-2.d: New test.
		* gas/scfi/x86_64/scfi-simple-2.l: New test.
		* gas/scfi/x86_64/scfi-simple-2.s: New test.
		* gas/scfi/x86_64/scfi-sub-1.d: New test.
		* gas/scfi/x86_64/scfi-sub-1.l: New test.
		* gas/scfi/x86_64/scfi-sub-1.s: New test.
		* gas/scfi/x86_64/scfi-sub-2.d: New test.
		* gas/scfi/x86_64/scfi-sub-2.l: New test.
		* gas/scfi/x86_64/scfi-sub-2.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-1.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-1.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-2.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-2.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-3.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-3.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-4.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-4.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-cfg-1.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-cfg-1.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-cfg-2.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-cfg-2.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-drap-1.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-drap-1.s: New test.
		* gas/scfi/x86_64/scfi-unsupported-insn-1.l: New test.
		* gas/scfi/x86_64/scfi-unsupported-insn-1.s: New test.
		* gas/scfi/x86_64/scfi-x86-64.exp: New file.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: i386-reg.tbl: Add a comment to reflect dependency on ordering
	The ginsn representation keeps the DWARF register number of the
	operands.  The API ginsn_dw2_regnum relies on the the relative ordering
	of these register entries in the table.  Add a comment to make it clear.

	opcodes/
		* i386-reg.tbl: Add a comment.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: doc: update documentation for the new listing option
	Add a new listing option, -i, to emit ginsn in the listing output.  We
	may also emit other SCFI information if necessary in the future.

	ginsn are most useful when seen alongside the assembly instructions.
	Hence, they are emitted when the user includes the assembly instructions
	in the listing output, i.e., "-ali=FILE".

	gas/doc/:
		* as.texi: Add documentation for the new listing option, -i.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: x86: synthesize CFI for hand-written asm
	This patch adds support in GAS to create generic GAS instructions
	(a.k.a., the ginsn) for the x86 backend (AMD64 ABI only at this time).
	Using this ginsn infrastructure, GAS can then synthesize CFI for
	hand-written asm for x86_64.

	A ginsn is a target-independent representation of the machine
	instructions.  One machine instruction may need one or more ginsn.

	This patch also adds skeleton support for printing ginsn in the listing
	output for debugging purposes.

	Since the current use-case of ginsn is to synthesize CFI, the x86 target
	needs to generate ginsns necessary for the following machine
	instructions only:

	 - All change of flow instructions, including all conditional and
	   unconditional branches, call and return from functions.
	 - All register saves and unsaves to the stack.
	 - All instructions affecting the two registers that could potentially
	   be used as the base register for CFA tracking.  For SCFI, the base
	   register for CFA tracking is limited to REG_SP and REG_FP only for
	   now.

	The representation of ginsn is kept simple:

	- GAS instruction has GINSN_NUM_SRC_OPNDS (defined to be 2 at this time)
	  number of source operands and one destination operand at this time.
	- GAS instruction uses DWARF register numbers in its representation and
	  does not track register size.
	- GAS instructions carry location information (file name and line
	  number).
	- GAS instructions are ID's with a natural number in order of their
	  addtion to the list.  This can be used as a proxy for the static
	  program order of the corresponding machine instructions.

	Note that, GAS instruction (ginsn) format does not support
	GINSN_TYPE_PUSH and GINSN_TYPE_POP.  Some architectures, like aarch64,
	do not have push and pop instructions, but rather STP/LDP/STR/LDR etc.
	instructions.  Further these instructions have a variety of addressing
	modes, like offset, pre-indexing and post-indexing etc.  Among other
	things, one of differences in these addressing modes is _when_ the addr
	register is updated with the result of the address calculation: before
	or after the memory operation.  To best support such needs, the generic
	instructions like GINSN_TYPE_LOAD, GINSN_TYPE_STORE together with
	GINSN_TYPE_ADD, and GINSN_TYPE_SUB may be used.

	The functionality provided in ginsn.c and scfi.c is compiled in when a
	target defines TARGET_USE_SCFI and TARGET_USE_GINSN.  This can be
	revisited later when there are other use-cases of creating ginsn's in
	GAS, apart from the current use-case of synthesizing CFI for
	hand-written asm.

	Support is added only for System V AMD64 ABI for ELF at this time.  If
	the user enables SCFI with --32, GAS issues an error:

	  "Fatal error: SCFI is not supported for this ABI"

	For synthesizing (DWARF) CFI, the SCFI machinery requires the programmer
	to adhere to some pre-requisites for their asm:
	   - Hand-written asm block must begin with a .type   foo, @function
	It is highly recommended to, additionally, also ensure that:
	   - Hand-written asm block ends with a .size foo, .-foo

	The SCFI machinery encodes some rules which align with the standard
	calling convention specified by the ABI.  Apart from the rules, the SCFI
	machinery employs some heuristics.  For example:
	   - The base register for CFA tracking may be either REG_SP or REG_FP.
	   - If the base register for CFA tracking is REG_SP, the precise amount of
	     stack usage (and hence, the value of REG_SP) must be known at all times.
	   - If using dynamic stack allocation, the function must switch to
	     FP-based CFA.  This means using instructions like the following (in
	     AMD64) in prologue:
	        pushq   %rbp
	        movq    %rsp, %rbp
	     and analogous instructions in epilogue.
	   - Save and Restore of callee-saved registers must be symmetrical.
	     However, the SCFI machinery at this time only warns if any such
	     asymmetry is seen.

	These heuristics/rules are architecture-independent and are meant to
	employed for all architectures/ABIs using SCFI in the future.

	gas/
		* Makefile.am: Add new files.
		* Makefile.in: Regenerated.
		* as.c (defined): Handle documentation and listing option for
		ginsns and SCFI.
		* config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end.
		(obj_elf_type): Invoke ginsn_data_begin.
		* config/tc-i386.c (x86_scfi_callee_saved_p): New function.
		(ginsn_prefix_66H_p): Likewise.
		(ginsn_dw2_regnum): Likewise.
		(x86_ginsn_addsub_reg_mem): Likewise.
		(x86_ginsn_addsub_mem_reg): Likewise.
		(x86_ginsn_alu_imm): Likewise.
		(x86_ginsn_move): Likewise.
		(x86_ginsn_lea): Likewise.
		(x86_ginsn_jump): Likewise.
		(x86_ginsn_jump_cond): Likewise.
		(x86_ginsn_enter): Likewise.
		(x86_ginsn_safe_to_skip): Likewise.
		(x86_ginsn_unhandled): Likewise.
		(x86_ginsn_new): New functionality to generate ginsns.
		(md_assemble): Invoke x86_ginsn_new.
		(s_insn): Likewise.
		(i386_target_format): Add hard error for usage of SCFI with non AMD64 ABIs.
		* config/tc-i386.h (TARGET_USE_GINSN): New definition.
		(TARGET_USE_SCFI): Likewise.
		(SCFI_MAX_REG_ID): Likewise.
		(REG_FP): Likewise.
		(REG_SP): Likewise.
		(SCFI_INIT_CFA_OFFSET): Likewise.
		(SCFI_CALLEE_SAVED_REG_P): Likewise.
		(x86_scfi_callee_saved_p): Likewise.
		* gas/listing.h (LISTING_GINSN_SCFI): New define for ginsn and
		SCFI.
		* gas/read.c (read_a_source_file): Close SCFI processing at end
		of file read.
		* gas/scfidw2gen.c (scfi_process_cfi_label): Add implementation.
		(scfi_process_cfi_signal_frame): Likewise.
		* subsegs.h (struct frch_ginsn_data): New forward declaration.
		(struct frchain): New member for ginsn data.
		* gas/subsegs.c (subseg_set_rest): Initialize the new member.
		* symbols.c (colon): Invoke ginsn_frob_label to convey
		user-defined labels to ginsn infrastructure.
		* ginsn.c: New file.
		* ginsn.h: New file.
		* scfi.c: New file.
		* scfi.h: New file.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: x86: new marker for insns that implicitly update stack pointer
	Some x86 instructions affect the stack pointer implicitly.  Add a new
	operand constraint to reflect this.  This will be useful for SCFI
	implmentation to ensure its correctness.

	Mark all push, pop, call, ret, enter, leave, INT, iret instructions.

	opcodes/
		* i386-gen.c: Update opcode_modifiers.
		* i386-opc.h: Add a new constraint.
		* i386-opc.tbl: Update the affected instructions.
		* i386-tbl.h: Regenerated.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	opcodes: gas: x86: define and use Rex2 as attribute not constraint
	Rex2 is currently an operand constraint.  For the upcoming SCFI
	implementation in GAS, we need to identify operations which implicitly
	update the stack pointer.  An operand constraint enumerator for implicit
	stack op seems more appropriate than an attribute.  However, two opcodes
	currently necessitate both Rex2 and an implicit stack op marker; this
	prompts revisiting the current representations a bit.

	Make Rex2 a standalone attribute, so that later a new operand constraint
	may be added for IMPLICIT_STACK_OP.

	ChangeLog:
		* gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check.
		* opcodes/i386-gen.c: Add a new BITFIELD for Rex2.
		* opcodes/i386-opc.h (REX2_REQUIRED): Remove.
		* opcodes/i386-opc.tbl: Remove Rex2 operand constraint.
		* opcodes/i386-tbl.h: Regenerated.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: scfidw2gen: new functionality to prepare for SCFI
	Define a new set of handlers for CFI directives for the purpose of SCFI.
	The SCFI machinery ignores many of the user-specified CFI direcives when
	SCFI is in effect.  A warning ("Warning: SCFI ignores most
	user-specified CFI directives") is issued once per file.  The following
	CFI directives, however, are not ignored:
	      - .cfi_sections
	      - .cfi_label
	      - .cfi_signal_frame

	gas/
		* Makefile.am: Add new files to GAS_CFILES and HFILES.
		* Makefile.in: Likewise.
		* gas/read.c (scfi_pop_insert): New define.
		(pobegin): Use the SCFI handlers.
		* scfidw2gen.c: New file.
		* scfidw2gen.h: New file.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: add new command line option --scfi=experimental
	When the command line option --scfi=experimenta is passed to the GNU
	assembler, it will synthesize DWARF call frame information (CFI) for the
	input assembly.

	The option --scfi=experimental will also ignore most of the existing
	.cfi_* directives, if already contained in the provided input file.
	Only the following CFI directives will not be ignored:
	  - .cfi_sections,
	  - .cfi_label,
	  - .cfi_signal_frame

	To use SCFI, a target will need to:
	    - define TARGET_USE_SCFI and TARGET_USE_GINSN, and other necessary
	    definitions,
	    - provide means to help GAS understand the target specific instruction
	    semantics by creating ginsns.

	The upcoming support for SCFI is inteded to be experimental, hence the
	option --scfi=experimental.  The --scfi= may see more options like
	--scfi=[all,none] added in future, once the SCFI support in GAS is
	mature and robust.  The offering may also see for example, an
	--scfi=inline option for dealing with inline asm may be added in the
	future.  In --scfi=inline option, the GNU assembler may consume (and not
	ignore) the compiler generated CFI for the code surrounding the inline
	asm.

	Also document the option.

	gas/
	        * as.c (show_usage): Add support for --scfi=experimental.
	        (parse_args): Likewise.
	        * as.h (enum synth_cfi_type): Define new type.
	        * doc/as.texi: Document the new option.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: externalize the all_cfi_sections
	gas/
	        * dw2gencfi.h: Declare all_cfi_sections as extern.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen
	scfidw2gen will use this for processing the .cfi_sections directive.

	gas/
	        * dw2gencfi.c (dot_cfi_sections): Not static anymore.
	        * dw2gencfi.h (dot_cfi_sections): Mark as extern.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: move some tc_* defines to the header file
	Move the following three defines to the header file, so the SCFI
	machinery can use them:
	 - tc_cfi_frame_initial_instructions
	 - tc_cfi_startproc
	 - tc_cfi_endproc

	gas/
	        * dw2gencfi.c: Move from ...
		* dw2gencfi.h: ... to here.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: expose a new cfi_set_last_fde API
	gas/
		* dw2gencfi.c (cfi_set_last_fde): New definition.
		(dot_cfi_endproc): Use it.
		(dot_cfi_fde_data): Likewise.
		(dot_cfi_inline_lsda): Likewise.
		* dw2gencfi.h (struct fde_entry): New declaration.
		(cfi_set_last_fde): Likewise.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: use all_cfi_sections instead of cfi_sections
	The code in dw2gencfi.c was checking variable cfi_sections and
	all_cfi_sections seemingly randomly.  Accessing all_cfi_sections seems
	to the correct variable to access.

	The data in cfi_sections has already been propagated to all_cfi_sections
	once cfi_dot_startproc () has been called.

	gas/
	        * dw2gencfi.c (dot_cfi_startproc): Use all_cfi_sections
		instead.
	        (dot_cfi_endproc): Likewise.
	        (dot_cfi_fde_data): Likewise.

2024-01-15  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections
	cfi_sections_set is best set to true in cfi_dot_startproc ().  Setting
	it to true again in other APIs (dot_cfi_endproc, dot_cfi_fde_data, and
	cfi_finish) is unnecessary.  Also, move setting the global var
	all_cfi_sections into cfi_set_sections ().

	gas/
	        * dw2gencfi.c (cfi_set_sections): Set cfi_sections_set and
		cfi_sections here.
	        (dot_cfi_startproc): Remove unnecessarily setting
		cfi_set_sections to true.
	        (dot_cfi_endproc): Likewise.
	        (dot_cfi_fde_data): Likewise.
	        (cfi_finish): Likewise.

2024-01-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.mi/mi-dprintf.exp with read1
	When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into:
	...
	(gdb) ^M
	PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop
	-data-evaluate-expression stderr^M
	^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M
	(gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check
	...

	The problem is in proc mi_gdb_is_stderr_available:
	...
	proc mi_gdb_is_stderr_available {} {
	    set has_stderr_symbol false
	    gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" {
		-re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" {
		}
		-re "$::mi_gdb_prompt$" {
		    set has_stderr_symbol true
		}
	     }
	...
	which uses a gdb_test_multiple that is supposed to use the mi prompt, but
	doesn't use -prompt to indicate this.  Consequently, the default patterns use
	the regular gdb prompt, which trigger earlier than the two custom patterns
	which use "$::mi_gdb_prompt$".

	Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments.

	While we're at it, make the gdb_test_multiple call a bit more readable by
	using variables, and by using -wrap.

	Tested on x86_64-linux, with:
	- gcc and clang (to trigger both the has_stderr_symbol true and false cases)
	- make check and make check-read1.

2024-01-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/namespace.exp with read1
	With check-read1 we run into:
	...
	(gdb) break DNE>::DNE^M
	Function "DNE>::DNE" not defined.^M
	Make breakpoint pending on future shared library load? (y or [n]) y^M
	Breakpoint 9 (DNE>::DNE) pending.^M
	n^M
	(gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt)
	n^M
	...

	The question is supposed to be handled by the question and response arguments
	to this gdb_test call:
	...
	gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \
	    "Make breakpoint pending on future shared library load?.*" "y"
	...
	but both this and the builtin handling in gdb_test_multiple triggers.

	The cause of this is that the question argument regexp is incomplete.

	Fix this by making sure that the entire question is matched in the regexp:
	...
	set yn_re [string_to_regexp {(y or [n])}]
	  ...
	    "Make breakpoint pending on future shared library load\\? $yn_re " "Y"
	...

	Tested on x86_64-linux.

2024-01-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-13  Yang Liu  <liuyang22@iscas.ac.cn>

	gdb: RISC-V: Refine lr/sc sequence support
	Per RISC-V spec, the lr/sc sequence can consist of up to 16 instructions, and we
	cannot insert breakpoints in the middle of this sequence. Before this, we only
	detected a specific pattern (the most common one). This patch improves this part
	and now supports more complex pattern detection.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

2024-01-13  Yang Liu  <liuyang22@iscas.ac.cn>

	Add myself to gdb/MAINTAINERS

2024-01-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30889 can't compile without large file support
	gprofng/ChangeLog
	2024-01-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR 30889
		* src/util.h (O_LARGEFILE): Define to 0, if not defined.

2024-01-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix 3 bugzillas against gp-display-html
	Fix two cases where gp-display-html terminates prematurely because the
	input format is not recognized.  This problem occurs in the function
	overview and caller-callee parts of the code.
	The fix consists of new regular expressions and a different approach
	in handling the input from gp-display-text.
	Also fix a performance problem in the caller-callee part that has a
	noticeable impact on the performance for large applications.

	gprofng/ChangeLog
	2024-01-10  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		PR gprofng/30438
		PR gprofng/30439
		PR gprofng/30942
		* gp-display-html/gp-display-html.in: fixes the issues.

2024-01-12  Dimitar Dimitrov  <dimitar@dinux.eu>

	sim: Fix compile errors
	The following change broke simulator testsuite with host GCC 13:
	  commit 435ad222b3de93fa647fba7221eece36b1b395eb
	  sim: warnings: compile build tools with -Werror too

	Host GCC13 complains about missing function prototypes:

	binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes]
	   26 | gen_struct (void)
	      | ^~~~~~~~~~

	Fix by making the functions static, which instructs the compiler that
	there is no need for a prototype.

2024-01-12  David Faust  <david.faust@oracle.com>

	bpf: fix relocation addend incorrect symbol value
	Relocations installed by the BPF ELF backend were sometimes incorrectly
	adding the symbol value to the relocation entry addend, when the correct
	relocation value was already stored in the addend. This could lead to a
	relocation effectively adding the symbol value twice.

	Fix that by making bpf_elf_generic_reloc () more similar to the flow of
	bfd_install_relocation in the case where howto->install_addend is set,
	which is how it ought to behave.

	bfd/
		* bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64)
		(R_BPF_64_NODYLD32): Set partial_inplace to true.
		* elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value
		of the symbol when installing relocation. Copy some additional
		logic from bfd_elf_generic_reloc.

	gas/
		* testsuite/gas/bpf/bpf.exp: Run new test.
		* testsuite/gas/bpf/elf-relo-1.d: New.
		* testsuite/gas/bpf/elf-relo-1.s: New.

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix failure in gdb.python/py-inferior.exp
	After this commit:

	  commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72
	  Date:   Thu Jan 4 10:01:24 2024 +0000

	      gdb/python: add gdb.InferiorThread.__repr__() method

	failures were reported for gdb.python/py-inferior.exp.

	The test grabs a gdb.InferiorThread object representing an inferior
	thread, and then, later in the test, expects this Python object to
	become invalid when the inferior thread has exited.

	The gdb.InferiorThread object was obtained from the list returned by
	calling gdb.Inferior.threads().

	The mistake I made in the original commit was to assume that the order
	of the threads returned from gdb.Inferior.threads() somehow reflected
	the thread creation order.  Specifically, I was expecting the main
	thread to be first in the list, and "other" threads to appear ... not
	first.

	However, the gdb.Inferior.threads() function creates a list and
	populates it from a map.  The order of the threads in the returned
	list has no obvious relationship to the thread creation order, and can
	vary from host to host.

	On my machine the ordering was as I expected, so the test passed for
	me.  For others the ordering was not as expected, and it just happened
	that we ended up recording the gdb.InferiorThread for the main thread.

	As the main thread doesn't exit (until the test is over), the
	gdb.InferiorThread object never became invalid, and the test failed.

	Fixed in this commit by taking more care to correctly find a non-main
	thread.  I do this by recording the main thread early on (when there
	is only one inferior thread), and then finding any thread that is not
	this main thread.

	Then, once all of the secondary threads have exited, I know that the
	second InferiorThread object I found should now be invalid.

	The test still passes for me, and I believe this should fix the issue
	for everyone else too.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	Update copyright year range in header of all files managed by GDB
	This commit is the result of the following actions:

	  - Running gdb/copyright.py to update all of the copyright headers to
	    include 2024,

	  - Manually updating a few files the copyright.py script told me to
	    update, these files had copyright headers embedded within the
	    file,

	  - Regenerating gdbsupport/Makefile.in to refresh it's copyright
	    date,

	  - Using grep to find other files that still mentioned 2023.  If
	    these files were updated last year from 2022 to 2023 then I've
	    updated them this year to 2024.

	I'm sure I've probably missed some dates.  Feel free to fix them up as
	you spot them.

2024-01-12  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Remove unused code
	Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was
	already dead when it was first added.

	aarch64: Make FEAT_ASMv8p2 instruction aliases always available
	There's no reason to disallow the aliases when the aliased instructions are
	always available.  The new behaviour matches existing LLVM behaviour.

	aarch64: Add +xs flag for existing instructions
	Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of
	"+d128".  This is an incremental improvement; there are still some FEAT_XS tlbi
	variants that are gated incorrectly or missing entirely.

	aarch64: Add +wfxt flag for existing instructions

	aarch64: Add +rcpc2 flag for existing instructions

	aarch64: Add +flagm2 flag for existing instructions

	aarch64: Add +frintts flag for existing instructions

	aarch64: Add +jscvt flag for existing fjcvtzs instruction

	aarch64: Fix option parsing to disallow prefixes of valid options
	Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility
	with Clang.

	aarch64: Add +fcma alias for +compnum

	aarch64: Fix +lse feature flag dependency

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs
	This commit updates the Python example code in the gdb.Progspace and
	gdb.Objfile sections of the docs.  Changes made:

	  1. Use @value{GDBP} for the GDB prompt rather than
	  hard-coding (gdB),

	  2. Use @group...@end group to split the example code into
	  unbreakable chunks, and

	  3. Add parenthesis to the Python print() calls in the examples.  In
	  Python 2 it was OK to drop the parenthesis, but now GDB is Python 3
	  only, example code should include the parenthesis.

	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: add some notes on selecting suitable attribute names
	In previous commits I've added Object.__dict__ support to gdb.Inferior
	and gdb.InferiorThread, this is similar to the existing support for
	gdb.Objfile and gdb.Progspace.

	This commit extends the documentation to offer the user some guidance
	on selecting good names for their custom attributes so they
	can (hopefully) avoid conflicting with any future attributes that GDB
	might add.

	The rules I've proposed are:

	  1. Don't start user attributes with a lower case letter, all the
	  current GDB attributes start with a lower case letter, and I suspect
	  all future attributes would also start with a lower case letter, and

	  2. Don't start user attributes with a double underscore, this risks
	  conflicting with Python built in attributes (e.g. __dict__) - though
	  clearly the user would need to start and end with a double
	  underscore, but it seemed easier just to say no double underscores.

	I'm doing this as a separate commit as I've updated the docs for the
	existing gdb.Objfile and gdb.Progspace so they all reference a single
	paragraph on selecting attribute names.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: Add gdb.InferiorThread.__dict__ attribute
	The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python
	types already have a __dict__ attribute, which allows users to create
	user defined attributes within the objects.  This is useful if the
	user wants to cache information within an object.

	This commit adds the same functionality to the gdb.InferiorThread
	type.

	After this commit there is a new gdb.InferiorThread.__dict__
	attribute, which is a dictionary.  A user can, for example, do this:

	  (gdb) pi
	  >>> t = gdb.selected_thread()
	  >>> t._user_attribute = 123
	  >>> t._user_attribute
	  123
	  >>>

	There's a new test included.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: Add gdb.Inferior.__dict__ attribute
	The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have
	a __dict__ attribute, which allows users to create user defined
	attributes within the objects.  This is useful if the user wants to
	cache information within an object.

	This commit adds the same functionality to the gdb.Inferior type.

	After this commit there is a new gdb.Inferior.__dict__ attribute,
	which is a dictionary.  A user can, for example, do this:

	  (gdb) pi
	  >>> i = gdb.selected_inferior()
	  >>> i._user_attribute = 123
	  >>> i._user_attribute
	  123
	  >>>

	There's a new test included.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove users ability to create gdb.Progspace objects
	I noticed that it is possible for the user to create a new
	gdb.Progspace object, like this:

	  (gdb) pi
	  >>> p = gdb.Progspace()
	  >>> p
	  <gdb.Progspace object at 0x7ffad4219c10>
	  >>> p.is_valid()
	  False

	As the new gdb.Progspace object is not associated with an actual C++
	program_space object within GDB core, then the new gdb.Progspace is
	created invalid, and there is no way in which the new object can ever
	become valid.

	Nor do I believe there's anywhere in the Python API where it makes
	sense to consume an invalid gdb.Progspace created in this way, for
	example, the gdb.Progspace could be passed as the locus to
	register_type_printer, but all that would happen is that the
	registered printer would never be used.

	In this commit I propose to remove the ability to create new
	gdb.Progspace objects.  Attempting to do so now gives an error, like
	this:

	  (gdb) pi
	  >>> gdb.Progspace()
	  Traceback (most recent call last):
	    File "<stdin>", line 1, in <module>
	  TypeError: cannot create 'gdb.Progspace' instances

	Of course, there is a small risk here that some existing user code
	might break ... but if that happens I don't believe the user code can
	have been doing anything useful, so I see this as a small risk.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add gdb.Frame.__repr__() method
	Add a gdb.Frame.__repr__() method.  Before this patch we would see
	output like this:

	  (gdb) pi
	  >>> gdb.selected_frame()
	  <gdb.Frame object at 0x7fa8cc2df270>

	After this patch, we now see:

	  (gdb) pi
	  >>> gdb.selected_frame()
	  <gdb.Frame level=0 frame-id={stack=0x7ffff7da0ed0,code=0x000000000040115d,!special}>

	More verbose, but, I hope, more useful.

	If the gdb.Frame becomes invalid, then we will see:

	  (gdb) pi
	  >>> invalid_frame_variable
	  <gdb.Frame (invalid)>

	which is inline with how other invalid objects are displayed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add gdb.InferiorThread.__repr__() method
	Add a gdb.InferiorThread.__repr__() method.  Before this patch we
	would see output like this:

	  (gdb) pi
	  >>> gdb.selected_thread()
	  <gdb.InferiorThread object at 0x7f4dcc49b970>

	After this patch, we now see:

	  (gdb) pi
	  >>> gdb.selected_thread()
	  <gdb.InferiorThread id=1.2 target-id="Thread 0x7ffff7da1700 (LWP 458134)">

	More verbose, but, I hope, more useful.

	If the gdb.InferiorThread becomes invalid, then we will see:

	  (gdb) pi
	  >>> invalid_thread_variable
	  <gdb.InferiorThread (invalid)>

	Which is inline with how other invalid objects are displayed.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: hoist common invalid object repr code into py-utils.c
	Many object types now have a __repr__() function implementation.  A
	common pattern is that, if an object is invalid, we print its
	representation as: <TYPENAME (invalid)>.

	I thought it might be a good idea to move the formatting of this
	specific representation into a utility function, and then update all
	of our existing code to call the new function.

	The only place where I haven't made use of the new function is in
	unwind_infopy_repr, where we currently return a different string.
	This case is a little different as the UnwindInfo is invalid because
	it references a frame, and it is the frame itself which is invalid.
	That said, I think it would be fine to switch to using the standard
	format; if the UnwindInfo references an invalid frame, then the
	UnwindInfo is itself invalid.  But changing this would be an actual
	change in behaviour, while all the other changes in this commit are
	just refactoring.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: add trailing '/' when using 'complete' with directory names
	This patch contains work pulled from this previously proposed patch:

	  https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/

	But has been modified by me.  Credit for the original idea and
	implementation goes to Lancelot, any bugs in this new iteration belong
	to me.

	Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is
	empty other than the `foo' sub-directory, then currently within GDB,
	if I type:

	  (gdb) file /tmp/f

	and then hit TAB, GDB completes this to:

	  (gdb) file /tmp/foo/

	notice that not only did GDB fill in the whole of `foo', but GDB also
	added a trailing '/' character.  This is done within readline when the
	path that was just completed is a directory.  However, if I instead
	do:

	  (gdb) complete file /tmp/f
	  file /tmp/foo

	I now see the completed directory name, but the trailing '/' is
	missing.  The reason is that, in this case, the completions are not
	offered via readline, but are handled entirely within GDB, and so
	readline never gets the chance to add the trailing '/' character.

	The above patch added filename option support to GDB, which included
	completion of the filename options.  This initially suffered from the
	same problem that I've outlined above, but the above patch proposed a
	solution to this problem, but this solution only applied to filename
	options (which have still not been added to GDB), and was mixed in
	with the complete filename options support.

	This patch pulls out just the fix for the trailing "/" problem, and
	applies it to GDB's general filename completion.  This patch does not
	add filename options to GDB, that can always be done later, but I
	think this small part is itself a useful fix.

	One of the biggest changes I made in this version is that I got rid of
	the set_from_readline member function, instead, I now pass the value
	of m_from_readline into the completion_tracker constructor.

	I then moved the addition of the trailing '/' into filename_completer
	so that it is applied in the general filename completion case.  I also
	added a call to gdb_tilde_expand which was missing from the original
	patch, I haven't tested, but I suspect that this meant that the
	original patch would not add the trailing '/' if the user entered a
	path starting with a tilde character.

	When writing the test for this patch I ran into two problems.

	The first was that the procedures in lib/completion-support.exp relied
	on the command being completed for the test name.  This is fine for
	many commands, but not when completing a filename, if we use the
	command in this case the test name will (potentially) include the name
	of the directory in which the test is being run, which means we can't
	compare results between two runs of GDB from different directories.

	So in this commit I've gone through completion-support.exp and added a
	new (optional) testname argument to many of the procedures, this
	allows me to give a unique test name, that doesn't include the path
	for my new tests.

	The second issue was in the procedure make_tab_completion_list_re,
	this builds the completion list which is displayed after a double tab
	when there are multiple possible completions.

	The procedure added the regexp ' +' after each completion, and then
	added another ' +' at the very end of the expected output.  So, if we
	expected to match the name of two functions 'f1' and 'f2' the
	generated regexp would be: 'f1 +f2 + +'.  This would match just fine,
	the actual output would be: 'f1  f2  ', notice that we get two spaces
	after each function name.

	However, if we complete two directory names 'd1' and 'd2' then the
	output will be 'd1/ d2/ '.  Notice that now we only have a single
	space between each match, however, we do get the '/' added instead.

	What happens is that when presenting the matches, readline always adds
	the appropriate trailing character; if we performed tab completion of
	'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with
	a trailing space added.  However, if we complete 'file d1' then we get
	'file d1/'.  Then readline is adding a single space after each
	possible match, including the last one, which accounts for the
	trailing space character.

	To resolve this I've simply remove the addition o the second ' +'
	within make_tab_completion_list_re, for the function completion
	example I gave above the expected pattern is now 'f1 +f2 +', which for
	the directory case we expect 'd1/ +d2/ +', both of which work just
	fine.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265
	Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2024-01-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: New InferiorThread.ptid_string attribute
	This commit adds a new InferiorThread.ptid_string attribute.  This
	read-only attribute contains the string returned by target_pid_to_str,
	which actually converts a ptid (not pid) to a string.

	This is the string that appears (at least in part) in the output of
	'info threads' in the 'Target Id' column, but also in the thread
	exited message that GDB prints.

	Having access to this string from Python is useful for allowing
	extensions identify threads in a similar way to how GDB core would
	identify the thread.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp
	In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is
	missing here after the unsupported:
	...
	if { ![is_x86_64_m64_target] } {
	    unsupported "unsupported architecture"
	}
	...
	and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3
	FAILs.

	Fix this by simply using require:
	...
	require is_x86_64_m64_target
	...

	Tested on x86_64-linux and aarch64-linux.

2024-01-12  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: warn when skipping SFrame FDE generation
	Fix PR gas/31213.

	gas/
		PR gas/31213
	        * gen-sframe.c (sframe_do_cfi_insn): Add new warning.

	gas/testsuite/
		* gas/cfi-sframe/common-empty-1.d: Test the new warning as well.
		* gas/cfi-sframe/common-empty-2.d: Likewise.

2024-01-12  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix relaxation overflow caused by section alignment
	When deleting NOP instructions addend by .align at second pass, this may cause
	the PC decrease but the symbol address to remain unchanged due to section
	alignment.

	To solve this question, we subtract a maximux alignment of all sections like
	RISC-V.

2024-01-12  Cui, Lili  <lili.cui@intel.com>

	x86: Fix indentation and use true/false instead of 1/0
	gas/ChangeLog:

	        * config/tc-i386.c (establish_rex): Fix indentation.
	        (check_EgprOperands): Use true/false instead of 1/0.

2024-01-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix frame passed to gdbarch_value_to_register in value_assign
	Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum")
	introduced an unexpected change in value_assign.  It replaced
	`get_prev_frame_always (next_frame)` with `next_frame`in the call to
	gdbarch_value_to_register.

	This is the result of a merge error, since I previously had a patch to
	change gdbarch_value_to_register to take the next frame, and later
	decided to drop it.  Revert that change.

	Add a test based on the DWARF assembler to expose the problem and test
	the fix.  I also tested on ppc64le to make sure the problem reported in
	PR 31231 was fixed.

	Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231

2024-01-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le
	On ppc64le-linux, I run into:
	...
	(gdb) bt^M
	 #0  0x00000000100006dc in foobar (J=2)^M
	 #1  0x000000001000070c in prog ()^M
	(gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo
	...

	The test-case attemps to emulate additional entry points of a function, with
	function bar having entry points foo and foobar:
	...
	(gdb) p bar
	$1 = {void (int, int)} 0x1000064c <bar>
	(gdb) p foo
	$2 = {void (int, int)} 0x10000698 <foo>
	(gdb) p foobar
	$3 = {void (int)} 0x100006d0 <foobar>
	...

	However, when setting a breakpoint on the entry point foo:
	...
	(gdb) b foo
	Breakpoint 1 at 0x100006dc
	...
	it ends up in foobar instead of in foo, due to prologue skipping, and
	consequently the backtrace show foobar instead foo.

	The problem is that the test-case does not emulate an actual prologue at each
	entry point.

	Fix this by disabling the prologue skipping when setting a breakpoint, using
	"break *foo".

	Tested on ppc64le-linux and x86_64-linux.

	Tested-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>

	PR testsuite/31232
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232

2024-01-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Extend gdb.base/kill-during-detach.exp
	I ran into the following FAIL:
	...
	(gdb) python kill_and_detach()^M
	Traceback (most recent call last):^M
	  File "<string>", line 1, in <module>^M
	  File "<string>", line 7, in kill_and_detach^M
	gdb.error: Selected thread is running.^M
	Error while executing Python code.^M
	(gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \
	  python kill_and_detach()
	...

	The FAIL happens as follows:
	- gdb is debugging a process A
	- a checkpoint is created, in other words, fork is called in the inferior,
	  after which we have:
	  - checkpoint 0 (the fork parent, process A), and
	  - checkpoint 1 (the fork child, process B).
	- during checkpoint creation, lseek is called in the inferior (process A) for
	  all file descriptors, and it returns != -1 for at least one file descriptor.
	- the process A continues in the background
	- gdb detaches, from process A
	- gdb switches to process B, in other words, it restarts checkpoint 1
	- while restarting checkpoint 1, gdb tries to call lseek in the inferior
	  (process B), but this fails because gdb incorrectly thinks that inferior B
	  is running.

	This happens because linux_nat_switch_fork patches the pid of process B into
	the current inferior and current thread which where originally representing
	process A.  So, because process A was running in the background, the
	thread_info fields executing and resumed are set accordingly, but they are not
	correct for process B.

	There's a line in fork_load_infrun_state that fixes up the thread_info field
	stop_pc, so fix this by adding similar fixups for the executing and resumed
	fields alongside.

	The FAIL did not always reproduce, so extend the test-case to reliably
	trigger this scenario.

	Tested on x86_64-linux.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

	PR gdb/31203
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203

2024-01-11  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: ld: Adjusted some code order in relax.exp.
		ld/testsuite/ChangeLog:

		* ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.

2024-01-11  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Discard extra spaces in objdump output
	Due to the formatted output of objdump, some instructions
	that do not require output operands (such as nop/ret) will
	have extra spaces added after them.

	Determine whether to output operands through the format
	of opcodes. When opc->format is an empty string, no extra
	spaces are output.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: return register error when unhandled
	We don't want to fallthru and use cooked_buf when we haven't initialized
	it to anything.  Returning 0 indicates the register wasn't recognized.

	sim: m32r: enable warnings in traps.c
	File should be clean now!

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: fixup some of the int<->pointer casts
	The m32r trap code was written for a 32-bit Linux host (and really, one
	whose Linux ABI matched pretty exactly).  This has lead to conversions
	between integers and pointers which breaks down hard on 64-bit hosts.

	Clean up some of the functions where possible to avoid unnecessary
	conversions, use uintptr_t to cast 32-bit target pointers to host
	pointers in some places, and just stub out a few functions that can't
	easily be salvaged currently when sizeof(void*) is not 32-bits.  This
	is a bit ugly, but lets us enable warnings for the whole file.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: fix missing break statement
	The ftime syscall should not fallthrough to the sync syscall.
	Clearly the code was missing a break statement.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: migrate ftime() to clock_gettime()
	The ftime() function has been deprecated since POSIX-1-2004, and
	removed in POSIX.1-2008.  It's also been deprecated/removed in glibc
	since 2.33.  POSIX has always said the function is not portable, and
	its return value, timezone, and dstflag fields are unspecified.  Even
	if Linux/glibc & m32r had defined behavior, those aren't the host for
	the sim runtime.

	So let's stop using the function and switch to clock_gettime.  gnulib
	already has detection support for it, and it's been around since at
	least POSIX-1-2004.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: cleanup unused variables
	We've been building this file with -Wno-error, so clean up unused
	variable warnings.

	sim: igen: add printf attributes to the prototypes too
	While gcc propagates the printf attribute via the typedef, clang
	doesn't seem to, so add it to the prototypes themselves too.  We
	still keep it on the prototype for cases where it's used as a
	variable.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	gdbsupport: tighten up libiberty code a bit with dnl
	No functional change here, just touch up generated output slightly.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	sim: build: switch to gdbsupport/libiberty.m4
	Leverage this common logic to find all the libiberty settings rather
	than duplicate it ourselves.

	sim: ppc: rework defines.h to handle HAVE symbols defined to 0
	The HAVE_DECL_xxx defines are always defined to 0 or 1.  The current
	defines.h logic assumes every HAVE_xxx symbol is only defined iff it's
	defined to 1 which causes this to break.  Tweak the sed logic to only
	match defines of 1.

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	gdb: libiberty: switch to AC_CHECK_DECLS_ONCE
	Only check these decls once in case other m4 macros also look for them.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-11  Mike Frysinger  <vapier@gentoo.org>

	gdb: move libiberty.m4 to gdbsupport
	This is used by gdb, gdbsupport, and gdbserver.  We want to use it
	in the sim tree too.  Move it to gdbsupport which is meant as the
	common sharing space for these projects.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: add an examples directory
	This directory contains example programs for the user to experiment with.
	Initially there is one application written in C.  The plan is to include
	more examples, also in other langauges, over time.
	In addition to the sources and a make file, a sample script how to make
	a profile is included.  There is also a README.md file.

	gprofng/ChangeLog
	2024-01-08  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		* examples: Top level directory.
		* examples/mxv-pthreads: Example program written in C.

2024-01-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 31123 improvements to hardware event implementation
	Our hardware counter profiling is based on perf_event_open().
	Our HWC tables are absent for new machines.
	I have added HWC tables for the following events: PERF_TYPE_HARDWARE,
	PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes.

	Did a little cleaning: marked the symbols as static, used Stringbuilder,
	created a function to read /proc/cpuinfo.

	gprofng/ChangeLog
	2024-01-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31123
		* common/core_pcbe.c: Mark the symbols as static. Add events_generic[].
		* common/hwc_cpus.h: Declare a new function read_cpuinfo.
		* common/hwcdrv.c: Add a new parameter in init_perf_event().
		* common/hwcentry.h: Add use_perf_event_type in Hwcentry.
		* common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type,
		type, config.
		* common/hwctable.c: Add a new HWC table generic_list[].
		* common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines.
		* src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc().
		Add a new function read_cpuinfo.

2024-01-10  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix AIX catchpoint warning during fork () event
	In AIX we were missing some hooks needed to catch a fork () event
	in rs6000-aix-nat.c. Due to their absence we were returning 1 while we
	insert the breakpoint/catchpoint location. This patch is a fix to the same.

2024-01-10  Nick Clifton  <nickc@redhat.com>

	Sync top level configure and makefiles
	This update brings in the following commits from the gcc mainline:

	commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f
	Author: Tom Tromey <tom@tromey.com>
	Date:   Tue Jan 9 06:25:26 2024 -0700

	    Pass GUILE down to subdirectories

	    When I enable cgen rebuilding in the binutils-gdb tree, the default is
	    to run cgen using 'guile'.  However, on my host, guile is guile 2.2,
	    which doesn't work for me -- I have to use guile3.0.

	    This patch arranges to pass "GUILE" down to subdirectories, so I can
	    use 'make GUILE=guile3.0'.

	commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb
	Author: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
	Date:   Wed Oct 25 13:06:48 2023 +0200

	    build: Add libgrust as compilation modules

	    Define the libgrust directory as a host compilation module as well as
	    for targets. Disable target libgrust if we're not building target
	    libstdc++.

	commit 56ca59a03150cf44cea340f58967c990ed6bf43c
	Author: Lewis Hyatt <lhyatt@gmail.com>
	Date:   Thu Nov 16 11:18:37 2023 -0500

	    Makefile.tpl: Avoid race condition in generating site.exp from the top level

	    A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of
	    a fresh build directory does not work reliably. That will spawn two
	    independent make processes inside the "gcc" directory, and each of those
	    will attempt to create site.exp if it doesn't exist and will interfere with
	    each other, producing often a corrupted or empty site.exp. Resolve that by
	    making these targets depend on a new phony target which makes sure site.exp
	    is created first before starting the recursive makes.

	commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1
	Author: Iain Sandoe <iain@sandoe.co.uk>
	Date:   Sun Mar 28 14:48:17 2021 +0100

	    Config,Darwin: Allow for configuring Darwin to use embedded runpath.

	    Recent Darwin versions place contraints on the use of run paths
	    specified in environment variables.  This breaks some assumptions
	    in the GCC build.

	    This change allows the user to configure a Darwin build to use
	    '@rpath/libraryname.dylib' in library names and then to add an
	    embedded runpath to executables (and libraries with dependents).

	    The embedded runpath is added by default unless the user adds
	    '-nodefaultrpaths' to the link line.

	    For an installed compiler, it means that any executable built with
	    that compiler will reference the runtimes installed with the
	    compiler (equivalent to hard-coding the library path into the name
	    of the library).

	    During build-time configurations  any "-B" entries will be added to
	    the runpath thus the newly-built libraries will be found by exes.

	    Since the install name is set in libtool, that decision needs to be
	    available here (but might also cause dependent ones in Makefiles,
	    so we need to export a conditional).

	    This facility is not available for Darwin 8 or earlier, however the
	    existing environment variable runpath does work there.

	    We default this on for systems where the external DYLD_LIBRARY_PATH
	    does not work and off for Darwin 8 or earlier.  For systems that can
	    use either method, if the value is unset, we use the default (which
	    is currently DYLD_LIBRARY_PATH).

	commit 2551e10038a70901f30b2168e6e3af4536748f3c
	Author: Sergei Trofimovich <siarheit@google.com>
	Date:   Mon Oct 2 12:08:17 2023 +0100

	    Makefile.tpl: disable -Werror for feedback stage [PR111663]

	    Without the change profiled bootstrap fails for various warnings on
	    master branch as:

	        $ ../gcc/configure
	        $ make profiledbootstrap
	        ...
	        gcc/genmodes.cc: In function ‘int main(int, char**)’:
	        gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
	        ...
	        gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’:
	        gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=]

	    The change removes -Werror just like autofeedback does today.

	commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a
	Author: Thomas Schwinge <thomas@codesourcery.com>
	Date:   Thu Jun 1 23:07:37 2023 +0200

	    Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951]

	    ..., where we need to use it (separate commits) for build-tree testing, similar
	    to 'gcc/Makefile.in:site.exp':

	        # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation.
	        # They are passed first to allow individual tests to override them.
	            @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp

	            PR testsuite/109951
	            * Makefile.tpl (BASE_TARGET_EXPORTS): Add
	            'SYSROOT_CFLAGS_FOR_TARGET'.
	            * Makefile.in: Regenerate.

2024-01-10  Saurabh Jha  <saurabh.jha@arm.com>

	gas: aarch64: Add system registers for Debug and PMU extensions
	This patch adds support for the new AArch64 system registers that are part of the following extensions:
	 * FEAT_DEBUGv8p9
	 * FEAT_PMUv3p9
	 * FEAT_PMUv3_SS
	 * FEAT_PMUv3_ICNTR
	 * FEAT_SEBEP

2024-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix assertion failure for checkpoint delete 0
	When doing "checkpoint delete 0" we run into an assertion failure:
	...
	+delete checkpoint 0
	inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
	...

	Fix this by handling the "pptid == null_ptid" case in
	delete_checkpoint_command.

	Tested on x86_64-linux.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

	PR gdb/31209
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209

2024-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix info checkpoints
	Consider test-case gdb.base/checkpoint.exp.  At some point, it issues an info
	checkpoints command:
	...
	(gdb) info checkpoints^M
	* 0 process 30570 (main process) at 0x0^M
	  1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M
	  2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M
	  3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M
	  4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M
	  5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M
	  6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M
	  7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M
	  8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M
	  9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M
	  10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M
	...

	According to the docs, each of these (0-10) is a checkpoint.

	But the pc address (as well as the file name and line number) is missing for
	checkpoint 0.

	Fix this by sampling the pc value for the current process in
	info_checkpoints_command, such that we have instead:
	...
	* 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M
	...

	Tested on x86_64-linux.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

	PR gdb/31211
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211

2024-01-10  Tom de Vries  <tdevries@suse.de>

	[gdb] Make variable printed bool in info_checkpoints_command
	While reading info_checkpoints_command, I noticed variable printed:
	...
	  const fork_info *printed = NULL;
	  ...
	  for (const fork_info &fi : fork_list)
	    {
	      if (requested > 0 && fi.num != requested)
		continue;

	      printed = &fi;
	      ...
	    }
	  if (printed == NULL)
	...
	has pointer type, but is just used as bool.

	Make this explicit by changing the variable type to bool.

	Tested on x86_64-linux.

	Approved-By: Kevin Buettner <kevinb@redhat.com>

2024-01-10  Tom de Vries  <tdevries@suse.de>

	gdb/symtab: Eliminate deferred_entry
	Currently cooked_index entry creation is either:
	- done immediately if the parent_entry is known, or
	- deferred if the parent_entry is not yet known, and done later while
	  resolving the deferred entries.

	Instead, create all cooked_index entries immediately, and keep track of which
	entries have a parent_entry that needs resolving later using the new
	IS_PARENT_DEFERRED flag.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-10  Tom de Vries  <tdevries@suse.de>

	gdb/symtab: Make cooked_index_entry::parent_entry private
	Make cooked_index_entry::parent_entry private, and add member functions to
	access it.

	Tested on x86_64-linux and ppc64le-linux.
	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-10  Tom de Vries  <tdevries@suse.de>

	gdb/symtab: Allow changing of added cooked_index entries
	Make cooked_index_storage::add and cooked_index_entry::add return a
	"cooked_index_entry *" instead of a "const cooked_index_entry *".

	Tested on x86_64-linux and ppc64le-linux.
	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-10  Tom Tromey  <tom@tromey.com>

	Fix ASAN failure in DWO code
	Simon pointed out that my recent change to the DWO code caused a
	failure in ASAN testing.

	The bug here was I updated the code to use a different search type in
	the hash table; but then did not change the search code to use
	htab_find_slot_with_hash.

	Note that this bug would not be possible with my type-safe hash table
	series, hint, hint.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2024-01-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-09  Tom Tromey  <tom@tromey.com>

	Fix thread-less build
	A user pointed out that the recent background DWARF reader series
	broke the build when --disable-threading is in use.  This patch fixes
	the problem.  I am checking it in.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223

2024-01-09  Tom Tromey  <tom@tromey.com>

	Pass GUILE down to subdirectories
	When I enable cgen rebuilding in the binutils-gdb tree, the default is
	to run cgen using 'guile'.  However, on my host, guile is guile 2.2,
	which doesn't work for me -- I have to use guile3.0.

	This patch arranges to pass "GUILE" down to subdirectories, so I can
	use 'make GUILE=guile3.0'.

		* Makefile.in: Rebuild.
		* Makefile.tpl (BASE_EXPORTS): Add GUILE.
		(GUILE): New variable.
		* Makefile.def (flags_to_pass): Add GUILE.

2024-01-09  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add --enable-mark-plt configure option
	Add --enable-mark-plt linker configure option to mark PLT entries with
	DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by
	default.

		* NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt.
		* config.in: Regenerated.
		* configure: Likewise.
		* configure.ac: Add --enable-mark-plt.
		(DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED.
		* emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT):
		Support DEFAULT_LD_Z_MARK_PLT.
		* emultempl/elf-x86.em (elf_x86_64_before_parse): New function.
		(LDEMUL_BEFORE_PARSE): New.  Set to elf_x86_64_before_parse for
		x86-64 targets.

2024-01-09  H.J. Lu  <hjl.tools@gmail.com>

	elf: Add elf_backend_add_glibc_version_dependency
	When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and
	DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation
	stores the offset of the indirect branch instruction.  However, glibc
	versions which don't have this commit in glibc 2.36:

	commit f8587a61892cbafd98ce599131bf4f103466f084
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Fri May 20 19:21:48 2022 -0700

	    x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT

	    According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT
	    and R_X86_64_JUMP_SLOT.  Since linkers always set their r_addends to 0, we
	    can ignore their r_addends.

	    Reviewed-by: Fangrui Song <maskray@google.com>

	won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation.
	Although this commit has been backported to glibc 2.33/2.34/2.35 release
	branches, it is safer to require glibc 2.36 for such binaries.

	Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to
	also add GLIBC_2.36 version dependency for -z mark-plt on the shared C
	library if it provides a GLIBC_2.XX symbol version.

		* elflink.c (elf_find_verdep_info): Moved to ...
		* elf-bfd.h (elf_find_verdep_info): Here.
		(elf_backend_data): Add elf_backend_add_glibc_version_dependency.
		(_bfd_elf_link_add_glibc_version_dependency): New function.
		(_bfd_elf_link_add_dt_relr_dependency): Likewise.
		* elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency):
		Likewise.
		(elf_backend_add_glibc_version_dependency): New.
		* elflink.c (elf_link_add_dt_relr_dependency): Renamed to ...
		(elf_link_add_glibc_verneed): This.  Modified to support other
		glibc dependencies.
		(_bfd_elf_link_add_glibc_version_dependency): Likewise.
		(_bfd_elf_link_add_dt_relr_dependency): Likewise.
		(bfd_elf_size_dynamic_sections): Call
		elf_backend_add_glibc_version_dependency instead of
		elf_link_add_dt_relr_dependency.
		* elfxx-target.h (elf_backend_add_glibc_version_dependency): New.
		(elfNN_bed): Add elf_backend_add_glibc_version_dependency.

	ld/

		* testsuite/ld-x86-64/mark-plt-1a.rd: New file.
		* testsuite/ld-x86-64/mark-plt-1b.rd: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for
		GLIBC_2.36 dependency.

2024-01-09  H.J. Lu  <hjl.tools@gmail.com>

	x86: Don't check R_386_NONE nor R_X86_64_NONE
	Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning
	relocations.

	bfd/

		* PR ld/31047
		* elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE.
		* elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check
		R_X86_64_NONE.

	ld/

		* PR ld/31047
		* testsuite/ld-i386/i386.exp: Run PR ld/31047 test.
		* testsuite/ld-x86-64/x86-64.exp: Likewise.
		* testsuite/ld-i386/pr31047.d: New file.
		* testsuite/ld-x86-64/pr31047-x32.d: Likewise.
		* testsuite/ld-x86-64/pr31047.d: Likewise.
		* testsuite/ld-x86-64/pr31047a.s: Likewise.
		* testsuite/ld-x86-64/pr31047b.s: Likewise.

2024-01-09  Tom Tromey  <tromey@adacore.com>

	Fix two bugs in gdbserver thread name handling
	Simon pointed out that my earlier patch to gdbserver's thread name
	code:

	    commit 07b3255c3bae7126a0d679f957788560351eb236
	    Author: Tom Tromey <tom@tromey.com>
	    Date:   Thu Jul 13 17:28:48 2023 -0600

		Filter invalid encodings from Linux thread names

	... introduced a regression.  This bug was that the iconv output was
	not \0-terminated.

	Looking at it, I found another bug as well -- replace_non_ascii would
	not \0-terminate, and also would return the wrong pointer

	This patch fixes both of them.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153

2024-01-09  Tom Tromey  <tromey@adacore.com>

	Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu
	dwarf2_base_index_functions::find_per_cu is documented as using an
	unrelocated address.  This patch changes the interface to use the
	unrelocated_addr type, just to be a bit more type-safe.

	Regression tested on x86-64 Fedora 38.

2024-01-09  Jan Beulich  <jbeulich@suse.com>

	x86: add missing APX logic to cpu_flags_match()
	As already indicated during review, we can't get away without certain
	adjustments here: Without these, respective {evex}-prefixed insns are
	assembled to APX encodings even when APX_F is turned off.

	While there also extend the respective comment in the opcode table, to
	explain why this construct is used.

2024-01-09  Jan Beulich  <jbeulich@suse.com>

	x86: FMA insns aren't eligible to VEX2 encoding
	PR gas/31178

	In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked
	that C aliases StaticRounding, and hence build_vex_prefix() now needs to
	be aware of that aliasing. Disambiguation is easy, as StaticRounding is
	only ever used together with SAE (hence why the overlaying works in the
	first place).

2024-01-09  Jan Beulich  <jbeulich@suse.com>

	PPC64/ELF: adjust comment wrt ABI versions
	While having been moved a couple of times since its introduction in
	f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"),
	the wording has always remained the same. In particular ELFv1 and ELFv2
	have always been the wrong way round.

2024-01-09  Nick Clifton  <nickc@redhat.com>

	Synchronize sourceware version of the libiberty sources with the master gcc versions.
	This brings in the following commits:

	commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a
	Author: Jakub Jelinek <jakub@redhat.com>
	Date:   Tue Dec 5 23:32:19 2023 +0100

	    libiberty: Fix build with GCC < 7

	    Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
	    In configure I've tried to use everything actually used in the sha1.c
	    x86 hw implementation, but unfortunately I forgot about implicit function
	    declarations.  GCC before 7 did have <cpuid.h> header and bit_SHA define
	    and __get_cpuid function defined inline, but it didn't define
	    __get_cpuid_count, which compiled fine (and the configure test is
	    intentionally compile time only) due to implicit function declaration,
	    but then failed to link when linking the linker, because
	    __get_cpuid_count wasn't defined anywhere.

	    The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
	    to make sure the functions are declared.

	commit 691858d279335eeeeed3afafdf872b1c5f8f4201
	Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
	Date:   Tue Dec 5 11:04:06 2023 +0100

	    libiberty: Fix pex_unix_wait return type

	    The recent warning patches broke Solaris bootstrap:

	    /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t,  int *, struct pex_time *, int,  const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int,  int *, struct pex_time *, int,  const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t,  int *, struct pex_time *, int,  const char **, int *)' {aka 'int (*)(struct pex_obj *, long int,  int *, struct pex_time *, int,  const char **, int *)'} [-Wincompatible-pointer-types]
	      326 |   pex_unix_wait,
	          |   ^~~~~~~~~~~~~
	    /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait')

	    While pex_funcs.wait expects a function returning pid_t, pex_unix_wait
	    currently returns int.  However, on Solaris pid_t is long for 32-bit,
	    but int for 64-bit.

	    This patches fixes this by having pex_unix_wait return pid_t as
	    expected, and like every other variant already does.

	    Bootstrapped without regressions on i386-pc-solaris2.11,
	    sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and
	    x86_64-apple-darwin23.1.0.

	commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6
	Author: Jason Merrill <jason@redhat.com>
	Date:   Mon Sep 25 10:15:02 2023 +0100

	    c++: mangle function template constraints

	    Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
	    https://github.com/itanium-cxx-abi/cxx-abi/pull/166

	    We need to mangle constraints to be able to distinguish between function
	    templates that only differ in constraints.  From the latter link, we want to
	    use the template parameter mangling previously specified for lambdas to also
	    make explicit the form of a template parameter where the argument is not a
	    "natural" fit for it, such as when the parameter is constrained or deduced.

	    I'm concerned about how the latter link changes the mangling for some C++98
	    and C++11 patterns, so I've limited template_parm_natural_p to avoid two
	    cases found by running the testsuite with -Wabi forced on:

	    template <class T, T V> T f() { return V; }
	    int main() { return f<int,42>(); }

	    template <int i> int max() { return i; }
	    template <int i, int j, int... rest> int max()
	    {
	      int sub = max<j, rest...>();
	      return i > sub ? i : sub;
	    }
	    int main() {  return max<1,2,3>(); }

	    A third C++11 pattern is changed by this patch:

	    template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
	    template <typename> struct A { };
	    int main() { f<A,int>(); }

	    I aim to resolve these with the ABI committee before GCC 14.1.

	    We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
	    (mangling references to dependent template-ids where the name is fully
	    resolved) as references to concepts in std:: will consistently run into this
	    area.  This is why mangle-concepts1.C only refers to concepts in the global
	    namespace so far.

	    The library changes are to avoid trying to mangle builtins, which fails.

	    Demangler support and test coverage is not complete yet.

	commit f2c52c0dfde581461959b0e2b423ad106aadf179
	Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
	Date:   Thu Nov 30 10:06:23 2023 +0100

	    libiberty: Disable hwcaps for sha1.o

	    This patch

	    commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
	    Author: Jakub Jelinek <jakub@redhat.com>
	    Date:   Tue Nov 28 13:14:05 2023 +0100

	        libiberty: Use x86 HW optimized sha1

	    broke Solaris/x86 bootstrap with the native as:

	    libtool: compile:  /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
	    ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000  [ SHA1 ]
	    gccgo: fatal error: Killed signal terminated program go1

	    As is already done in a couple of other similar cases, this patches
	    disables hwcaps support for libiberty.

	    Initially, this didn't work because config/hwcaps.m4 uses target_os, but
	    didn't ensure it is defined.

	    Tested on i386-pc-solaris2.11 with as and gas.

	commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
	Author: Jakub Jelinek <jakub@redhat.com>
	Date:   Tue Nov 28 13:14:05 2023 +0100

	    libiberty: Use x86 HW optimized sha1

	    Nick has approved this patch (+ small ld change to use it for --build-id=),
	    so I'm commiting it to GCC as master as well.

	    If anyone from ARM would be willing to implement it similarly with
	    vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
	    speedup on those hosts as well, the intent in sha1.c was that
	    sha1_hw_process_bytes, sha1_hw_process_block functions
	    would be defined whenever
	    defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
	    but the body of sha1_hw_process_block and sha1_choose_process_bytes
	    would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
	    the other arch support, similarly for any target attributes on
	    sha1_hw_process_block if needed.

	commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942
	Author: Mark Wielaard <mjw@redhat.com>
	Date:   Wed Nov 15 20:27:08 2023 +0100

	    Regenerate libiberty/aclocal.m4 with aclocal 1.15.1

	    There is a new buildbot check that all autotool files are generated
	    with the correct versions (automake 1.15.1 and autoconf 2.69).
	    https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen

	    Correct one file that was generated with the wrong version.

	commit 879cf9ff45d94065d89e24b71c6b27c7076ac518
	Author: Brendan Shanks <bshanks@codeweavers.com>
	Date:   Thu Nov 9 21:01:07 2023 -0700

	    [PATCH v3] libiberty: Use posix_spawn in pex-unix when available.

	    Hi,

	    This patch implements pex_unix_exec_child using posix_spawn when
	    available.

	    This should especially benefit recent macOS (where vfork just calls
	    fork), but should have equivalent or faster performance on all
	    platforms.
	    In addition, the implementation is substantially simpler than the
	    vfork+exec code path.

	    Tested on x86_64-linux.

	    v2: Fix error handling (previously the function would be run twice in
	    case of error), and don't use a macro that changes control flow.

	    v3: Match file style for error-handling blocks, don't close
	    in/out/errdes on error, and check close() for errors.

	commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450
	Author: Jason Merrill <jason@redhat.com>
	Date:   Thu Aug 17 11:36:23 2023 -0400

	    c++: constrained hidden friends [PR109751]

	    r13-4035 avoided a problem with overloading of constrained hidden friends by
	    checking satisfaction, but checking satisfaction early is inconsistent with
	    the usual late checking and can lead to hard errors, so let's not do that
	    after all.

	    We were wrongly treating the different instantiations of the same friend
	    template as the same function because maybe_substitute_reqs_for was failing
	    to actually substitute in the case of a non-template friend.  But we don't
	    actually need to do the substitution anyway, because [temp.friend] says that
	    such a friend can't be the same as any other declaration.

	    After fixing that, instead of a redefinition error we got an ambiguous
	    overload error, fixed by allowing constrained hidden friends to coexist
	    until overload resolution, at which point they probably won't be in the same
	    ADL overload set anyway.

	    And we avoid mangling collisions by following the proposed mangling for
	    these friends as a member function with an extra 'F' before the name.  I
	    demangle this by just adding [friend] to the name of the function because
	    it's not feasible to reconstruct the actual scope of the function since the
	    mangling ABI doesn't distinguish between class and namespace scopes.

	            PR c++/109751

2024-01-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: ADD FEAT_THE RCWCAS instructions.
	This patch adds support for FEAT_THE doubleword and quadword instructions.
	doubleword insturctions are enabled by "+the" flag whereas quadword
	instructions are enabled on passing both "+the and +d128" flags.

	Support for following sets of instructions is added in this patch.
	Read check write compare and swap doubleword:
	(rcwcas, rcwcasa, rcwcasal, rcwcasl)
	Read check write compare and swap quadword:
	(rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl)
	Read check write software compare and swap doubleword:
	(rcwscas, rcwscasa, rcwscasal, rcwscasl)
	Read check write software compare and swap quadword:
	(rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl)
	Read check write atomic bit clear on doubleword:
	(rcwclr, rcwclra, rcwclral, rcwclrl)
	Read check write atomic bit clear on quadword:
	(rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl)
	Read check write software atomic bit clear on doubleword:
	(rcwsclr, rcwsclra, rcwsclral, rcwsclrl)
	Read check write software atomic bit clear on quadword:
	(rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl)
	Read check write atomic bit set on doubleword:
	(rcwset,rcwseta, rcwsetal,rcwsetl)
	Read check write atomic bit set on quadword:
	(rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl)
	Read check write software atomic bit set on doubleword:
	(rcwsset,rcwsseta,rcwssetal,rcwssetl)
	Read check write software atomic bit set on quadword:
	(rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl)
	Read check write swap doubleword:
	(rcwswp,rcwswpa,rcwswpal,rcwswpl)
	Read check write swap quadword:
	(rcwswpp,rcwswppa, rcwswppal,rcwswppl)
	Read check write software swap doubleword:
	(rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl)
	Read check write software swap quadword:
	(rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl)

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Regenerate aarch64-*-2.c files

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	arch64: Add optional operand register pair support tests
	Add tests to cover the full range of behaviors observed around
	optional register operands for the `tlbip' and `sysp' instructions,
	namely:

	  * Not all `tlbip' operations take GPR operands.  When this is the
	  case, we should check that neither optional operand was supplied.
	  * When a `tlbip' operation is labeled with the `F_HASXT' flag, xzr
	  is not a valid optional operand.  In such case, at least the fist
	  optional register needs to be specified with a non-xzr value.
	  * The first operand for both insns should be either xzr or an
	  even-numbered register (n % 2 == 0).  In the former scenario, the
	  second operand should default to xzr too, while in the latter, it
	  should default to n + 1.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add support for 128-bit system register mrrs and msrr insns
	With the addition of 128-bit system registers to the Arm architecture
	starting with Armv9.4-a, a mechanism for manipulating their contents
	is introduced with the `msrr' and `mrrs' instruction pair.

	These move values from one such 128-bit system register into a pair of
	contiguous general-purpose registers and vice-versa, as for example:

		   msrr ttlb0_el1, x0, x1
		   mrrs x0, x1, ttlb0_el1

	This patch adds the necessary support for these instructions, adding
	checks for system-register width by defining a new operand type in the
	form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p'
	predicate, responsible for checking whether the requested system
	register table entry is marked as implemented in the 128-bit mode via
	the F_REG_128 flag.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add TLBIP tests

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add xs variants of tlbip operands
	The 2020 Architecture Extensions to the Arm A-profile architecture
	added FEAT_XS, the XS attribute feature, giving cores the ability to
	identify devices which can be subject to long response delays. TLB
	invalidate (TLBI) operations and barriers can also be annotated with
	this attribute[1].

	With the introduction of the 128-bit translation tables with the
	Armv8.9-a/Armv9.4-a Translation Hardening Extension, a series of new
	TLB invalidate operations are introduced which make use of this
	extension.  These are added to aarch64_sys_regs_tlbi[] for use
	with the `tlbip' insn.

	[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Implement TLBIP 128-bit instruction
	The addition of 128-bit page table descriptors and, with it, the
	addition of 128-bit system registers for these means that special
	"invalidate translation table entry" instructions are needed to cope
	with the new 128-bit model.  This is introduced with the `tlbpi'
	instruction, implemented here.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Create QL_SRC_X2 and QL_DEST_X2 qualifier macros
	Some 128-bit system operations (mrrs, msrr, tlbip, and sysp) take two
	qualified operands and one of unqualified type (e.g. system register
	name, tlbip operation).  This creates the need for adequate qualifiers
	to handle this.

	This patch therefore introduces the `QL_SRC_X2' and `QL_DST_X2' qualifier
	specifiers, which expand to `QLF3(NIL,X,X)' and `QLF3(X,X,NIL)',
	respectively.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Apply narrowing of allowed immediate values for SYSP
	While CRn and CRm fields in the SYSP instruction are 4-bit wide and
	are thus able to accommodate values in the range 0-15, the
	specifications for the SYSP instructions limit their ranges to 8-9 for
	CRm and 0-7 in the case of CRn.

	This led to the need to signal in some way to the operand parser that
	a given operand is under special restrictions regarding its use.  This
	is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the
	range of operand values for fields in the instruction tagged with the
	flag.

	The flag is then used in `parse_operands' when the instruction is
	assembled, but needs not be taken into consideration during
	disassembly.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add support for the SYSP 128-bit system instruction
	Mirroring the use of the `sys' - System Instruction assembly
	instruction, this implements its 128-bit counterpart, `sysp'.

	This optionally takes two contiguous general-purpose registers
	starting at an even number or, when these are omitted, by default
	sets both of these to xzr.

	Syntax:

		sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add support for optional operand pairs
	Two of the instructions added by the `+d128' architectural extension
	add the flexibility to have two optional operands.  Prior to the
	addition of the `tlbip' and `sysp' instructions, no mnemonic allowed
	more than one such optional operand.

	With `tlbip' as an example, some TLBIP instruction names do not allow
	for any optional operands, while others allow for both to be optional.
	In the latter case, it is possible that either the second operand
	alone is omitted or both operands are omitted.
	Therefore, a considerable degree of flexibility needed to be added to
	the way operands were parsed.  It was, however, possible to achieve
	this with relatively few changes to existing code.

	it is noteworthy that opcode flags specifying the optional operand
	number are non-orthogonal. For example, we have:

	       #define F_OPD1_OPT (2 << 12) : 0b10 << 12
	       #define F_OPD2_OPT (3 << 12) : 0b11 << 12

	such that by virtue of the observation that

	       (F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT

	it is impossible to mark both operands 1 and 2 as optional for an
	instruction and it is assumed that a maximum of 1 operand can ever be
	optional.  This is not overly-problematic given that, for optional
	pairs, the second optional operand is always found immediately after
	the first.  Thus, it suffices for us to flag that there is a second
	optional operand.  With this fact, we can infer its position in the
	mnemonic from the position of the first (e.g. if the second operand in
	the mnemonic is optional, we know the third is too).  We therefore
	define the `F_OPD_PAIR_OPT' flag and calculate its position in the
	mnemonic from the value encoded by the `F_OPD<n>_OPT' flag.

	Another observation is that there is a tight coupling between default
	values assigned to the two registers when one (or both) are omitted
	from the mnemonic.  Namely, if Xt1 has a value of 0x1f (the zero
	register is specified), Xt2 defaults to the same value, otherwise Xt2
	will be assigned Xt + 1.  This meant that where you have default value
	validation, in checking the second optional operand's value, it is
	also necessary to look at the value assigned to the
	previously-processed operand value before deciding its validity. Thus
	`process_omitted_operand' needs not only access to its `operand'
	argument, but also to the global `inst' struct.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add support for xzr register in register pair operands
	Analysis of the allowed operand values for `sysp' and `tlbip' reveals
	a significant departure from the allowed behavior for operand register
	pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other
	insns in this category.

	For instructions `casp', `mrrs' and `msrr' the register pair must
	always start at an even index and the second register in the pair is
	the index + 1.  This precludes the use of xzr as the first register,
	given it corresponds to register number 31.

	This is different in the case of `sysp' and `tlbip', however.  These
	allow the use of xzr and, where the first operand in the pair is
	omitted, this is the default value assigned to it.  When this
	operand is assigned xzr, it is expected that the second operand will
	likewise take on a value of xzr.

	These two instructions therefore "break" two rules of register pairs:

	  * The first of the two registers is odd-numbered.
	  * The index of the second register is equal to that of the first,
	  and not n+1.

	To allow for this departure from hitherto standard behavior, we
	extend the functionality of the assembler by defining an extension of
	the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR.

	It is used in defining `sysp' and `tlbip' and allows
	`operand_general_constraint_met_p' to allow the pair to both take on
	the value of xzr.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Expand maximum number of operands from 5 to 6
	Given the introduction of the new Armv9.4-a `sysp' insn using the
	following syntax:

		sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}

	and by extension the need to encode 6 assembly operands, extend
	Binutils to handle instructions taking 6 operands, up from a previous
	maximum of 5.

2024-01-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add +d128 architectural feature support
	Indicating the presence of the Armv9.4-a features concerning 128-bit
	Page Table Descriptors, 128-bit System Registers and Instructions,
	the "+d128" architectural extension flag is added to the list of
	possible -march options in Binutils, together with the necessary macro
	for encoding d128 instructions.

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: compile build tools with -Werror too
	Add support for compiling build tools with various -Werror settings.
	Since the tools don't compile cleanly with the same set of flags as
	the rest of the sim code, we need to maintain & test a separate list.

	Only bother when not cross-compiling so we don't have to test all the
	flags against the build compiler.  This should be good enough for our
	actual development flows.

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: igen: fix format-zero-length warnings
	Fix warnings from calling printf functions with "" which normally
	is useless.

	sim: m68hc11: gencode: add printf markings

	sim: m32c: fix declaration-after-statement warnings

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: fix unused variable warnings
	Leave the igen code in place as it's meant to be used with newer
	(to-be-written) code ported from the ppc version.

	The sh code isn't really necessary as the opcodes enums have been
	maintained independently from here, and the lists are out-of-sync
	already.

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: mark local funcs/vars as static
	These are only used in the respective files, so mark them as static.
	This fixes missing prototype warnings at build time.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Back out some parallel_for_each features
	Now that the DWARF reader does not use parallel_for_each, we can
	remove some of the features that were added just for it: return values
	and task sizing.

	The thread_pool typed tasks feature could also be removed, but I
	haven't done so here.  This one seemed less intrusive and perhaps more
	likely to be needed at some point.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Avoid language-based lookups in startup path
	The previous patches are nearly enough to enable background DWARF
	reading.  However, this hack in language_defn::get_symbol_name_matcher
	causes an early computation of current_language:

	  /* If currently in Ada mode, and the lookup name is wrapped in
	     '<...>', hijack all symbol name comparisons using the Ada
	     matcher, which handles the verbatim matching.  */
	  if (current_language->la_language == language_ada
	      && lookup_name.ada ().verbatim_p ())
	    return current_language->get_symbol_name_matcher_inner (lookup_name);

	I considered various options here -- reversing the order of the
	checks, or promoting the verbatim mode to not be a purely Ada feature
	-- but in the end found that the few calls to this during startup
	could be handled more directly.

	In the JIT code, and in create_exception_master_breakpoint_hook, gdb
	is really looking for a certain kind of symbol (text or data) using a
	linkage name.  Changing the lookup here is clearer and probably more
	efficient as well.

	In create_std_terminate_master_breakpoint, the lookup can't really be
	done by linkage name (it would require relying on a certain mangling
	scheme, and also may trip over versioned symbols) -- but we know that
	this spot is C++-specific, and so the language ought to be temporarily
	set to C++ here.

	After this patch, the "file" case is much faster:

	    (gdb) file /tmp/gdb
	    2023-10-23 13:16:54.456 - command started
	    Reading symbols from /tmp/gdb...
	    2023-10-23 13:16:54.520 - command finished
	    Command execution time: 0.225906 (cpu), 0.064313 (wall)

2024-01-09  Tom Tromey  <tom@tromey.com>

	Optimize lookup_minimal_symbol_text
	lookup_minimal_symbol_text always loops over all objfiles, even when
	an objfile is passed in as an argument.  This patch changes the
	function to loop over the minimal number of objfiles in the latter
	situation.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Lazy language setting
	When gdb starts up with a symbol file, it uses the program's "main" to
	decide the "static context" and the initial language.  With background
	DWARF reading, this means that gdb has to wait for a significant
	amount of DWARF to be read synchronously.

	This patch introduces lazy language setting.  The idea here is that in
	many cases, the prompt can show up early, making gdb feel more
	responsive.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Change current_language to be a macro
	This changes the 'current_language' global to be a macro that wraps a
	function call.  This change will let a subsequent patch introduce lazy
	language setting.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Remove two quick_symbol_functions methods
	quick_symbol_functions::read_partial_symbols is no longer implemented,
	so both it and quick_symbol_functions::can_lazily_read_symbols can be
	removed.  This allows for other functions to be removed as well.

	Note that SYMFILE_NO_READ is now pretty much dead.  I haven't removed
	it here -- but could if that's desirable.  I tend to think that this
	functionality would be better implemented in the core; but whenever I
	dive into the non-DWARF readers it is pretty depressing.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Simplify the public DWARF API
	dwarf2_has_info and dwarf2_initialize_objfile are only separate
	because the DWARF reader implemented lazy psymtab reading.  However,
	now that this is gone, we can simplify the public DWARF API again.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Do more DWARF reading in the background
	This patch rearranges the DWARF reader so that more work is done in
	the background.  This is PR symtab/29942.

	The idea here is that there is only a small amount of work that must
	be done on the main thread when scanning DWARF -- before the main
	scan, the only part is mapping the section data.

	Currently, the DWARF reader uses the quick_symbol_functions "lazy"
	functionality to defer even starting to read.  This patch instead
	changes the reader to start reading immediately, but doing more in
	worker tasks.

	Before this patch, "file" on my machine:

	    (gdb) file /tmp/gdb
	    2023-10-23 12:29:56.885 - command started
	    Reading symbols from /tmp/gdb...
	    2023-10-23 12:29:58.047 - command finished
	    Command execution time: 5.867228 (cpu), 1.162444 (wall)

	After the patch, more work is done in the background and so this takes
	a bit less time:

	    (gdb) file /tmp/gdb
	    2023-10-23 13:25:51.391 - command started
	    Reading symbols from /tmp/gdb...
	    2023-10-23 13:25:51.712 - command finished
	    Command execution time: 1.894500 (cpu), 0.320306 (wall)

	I think this could be further sped up by using the shared library load
	map to avoid objfile loops like the one in expand_symtab_containing_pc
	-- it seems like the correct objfile could be chosen more directly.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174

2024-01-09  Tom Tromey  <tom@tromey.com>

	Change how cooked index waits for threads
	This changes the cooked index code to wait for threads in its
	public-facing API.  That is, the waits are done in cooked_index now,
	and never in the cooked_index_shard.  Centralizing this decision makes
	it easier to wait for other events here as well.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Add "maint set dwarf synchronous"
	For testing, it's sometimes convenient to be able to request that
	DWARF reading be done synchronously.  This patch adds a new "maint"
	setting for this purpose.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2024-01-09  Tom Tromey  <tom@tromey.com>

	Move cooked_index_storage to cooked-index.h
	This moves cooked_index_storage to cooked-index.h.  This is needed by
	a subsequent patch.

	Add gdb::task_group
	This adds gdb::task_group, a convenient way to group background tasks
	and then call a function when all the tasks have completed.

	Add quick_symbol_functions::compute_main_name
	This adds a new compute_main_name method to quick_symbol_functions.
	Currently there are no implementations of this, but a subsequent patch
	will add one.

	Add deferred_warnings parameter to read_addrmap_from_aranges
	When DWARF reading is done in the background,
	read_addrmap_from_aranges will be called from a worker thread.
	Because warnings can't be emitted from these threads, this patch adds
	a new deferred_warnings parameter to the function, letting the caller
	control exactly how the warnings are emitted.

	Refactor complaint thread-safety approach
	This patch changes the way complaint works in a background thread.
	The new approach requires installing a complaint interceptor in each
	worker, and then the resulting complaints are treated as one of the
	results of the computation.  This change is needed for a subsequent
	patch, where installing a complaint interceptor around a parallel-for
	is no longer a viable approach.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Add thread-safety to gdb's BFD wrappers
	This changes gdb to ensure that gdb's BFD cache is guarded by a lock.
	This avoids any races when multiple threads might open a BFD (and thus
	use the BFD cache) at the same time.

	Currently, this change is not needed because the the main thread waits
	for some DWARF scanning to be completed before returning.  The only
	locking that's required is when opening DWO files, and there's a local
	lock to this end in dwarf2/read.c.

	However, in the coming patches, the DWARF reader will begin its work
	earlier, in the background.  This means there is the potential for the
	DWARF reader and other code on the main thread to both attempt to open
	BFDs at the same time.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Add a couple of bfd_cache_close calls
	This adds a couple of calls to bfd_cache_close at points where a BFD
	isn't actively needed by gdb.  Normally at these points, all the
	needed section data is already mapped, so we can simply close the file
	descriptor.  This is harmless at worst, because if this is needed
	after all, the BFD file descriptor cache will reopen it.

	Pre-read DWZ section data
	This changes the DWZ code to pre-read the section data and somewhat
	simplify the DWZ API.  This makes it easier to add the bfd_cache_close
	call to the new dwarf2_read_dwz_file function -- after this is done,
	there shouldn't be a reason to keep the BFD's file descriptor open.

2024-01-09  Tom Tromey  <tom@tromey.com>

	Don't use objfile::intern in DWO code
	The DWO code in the DWARF reader currently uses objfile::intern.  This
	accesses a shared data structure and so would be racy when used from
	multiple threads.  I don't believe this can happen right now, but
	background reading could provoke this, and in any case it's better to
	avoid this, just to be sure.

	This patch changes this code to just use a std::string.  A new type is
	introduced to do hash table lookups, to avoid unnecessary copies.

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: build: clean more generated outputs

	sim: mips: drop old clean workaround
	This logic dates back to the original import, and seems to be for
	handling systems where `rm -f` (i.e. no files) would error out.
	None of that is relevant for us with current automake, so drop it.

	sim: ppc: workaround uninitialized variable compiler warnings
	Some compilers don't understand the semctl API and think it's an input
	argument even when it's used as an output, and then complains that it
	is being used uninitialized.  Zero it out explicitly to workaround it.
	This adds some runtime overhead, but should be fairly minor as it's a
	small stack buffer, and shouldn't be that relevant relative to all the
	other logic in these functions.

	sim: warnings: enable -Wshift-negative-value
	Now that all the relevant sources are fixed, enable the warning.

	sim: sh: avoid left shifting negative values
	We just want to create a bitmask here, so cast the mask to unsigned
	to avoid left shifting a negative value which is undefined behavior.

	sim: bfin: avoid left shifting negative values
	We just want to create a bitmask here, so cast the mask to unsigned
	to avoid left shifting a negative value which is undefined behavior.

2024-01-09  Mike Frysinger  <vapier@gentoo.org>

	sim: cgen: rework DI macros to avoid signed left shifts
	The cgen code uses DI as int64_t and UDI as uint64_t.  The DI macros
	are used to construct 64-bit values from 32-bit values (for the low
	and high parts).  The MAKEDI macro casts the high 32-bit value to a
	signed 32-bit value before shifting.  If this created a negative
	value, this would be undefined behavior according to the C standard.
	All we care about is shifting the 32-bits as they are to the high
	32-bits, not caring about sign extension (since there's nothing left
	to shift into), and the low 32-bits being empty.  This is what we
	get from shifting an unsigned value, so cast it to unsigned 32-bit
	to avoid undefined behavior.

	While we're here, change the SETLODI macro to truncate the lower
	value to 32-bits before we set it.  If it was passing in a 64-bit
	value, those high bits would get included too, and that's not what
	we want.

	Similarly, tweak the SETHIDI macro to cast the value to an unsigned
	64-bit instead of a signed 64-bit.  If the value was only 32-bits,
	the behavior would be the same.  If it happened to be signed 64-bit,
	it would trigger the undefined behavior too.

2024-01-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-08  Cupertino Miranda  <cupertino.miranda@oracle.com>

	bpf: Added linker support for R_BPF_64_NODYLD32.
	This patch adds linker support to patch R_BPF_64_NODYLD32 relocations.
	The implementation was based on comments and code in LLVM, as the GNU
	toolchain does not uses this relocation type.

2024-01-08  Joseph Myers  <josmyers@redhat.com>

	MAINTAINERS: Update my email address

2024-01-08  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/GAS: mips.exp, mark all mipsisa32*-linux as addr32
	Currently, only mipsisa32-linux and mipsisa32el-linux is marked
	as addr32, which make mipsisa32rN(el) not marked.

	This change can fix 2 test failures on mipsisa32rN(el)-linux:
		FAIL: MIPS MIPS64 MIPS-3D ASE instructions (-mips3d flag)
		FAIL: MIPS MIPS64 MDMX ASE instructions (-mdmx flag)

	These failures don't happen for mipsisa32rN-mti-elf etc,
	due to that, the output is set as NO_ABI instead of O32, then
	gas won't warn:
		`fp=64' used with a 32-bit ABI
	Maybe, we should change this behaivour in future.

2024-01-08  srinath  <srinath.parvathaneni@arm.com>

	arm: Add support for Armv8.9-A and Armv9.4-A
	This patch adds AArch32 support for -march=armv8.9-a and
	-march=armv9.4-a. The behaviour of the new options can be
	expressed using a combination of existing feature flags
	and tables.

	The cpu_arch_ver entries for ARM_ARCH_V9_4A and ARM_ARCH_V8_9A
	are technically redundant but it including them for macro code
	consistency across architectures.

2024-01-08  srinath  <srinath.parvathaneni@arm.com>

	aarch64: Add ite feature system registers.
	This patch adds ite feature (FEAT_ITE) system registers,
	trcitecr_el1, trcitecr_el12, trcitecr_el2 and trciteedcr.

2024-01-08  Samuel Tardieu  <sam@rfc1149.net>

	gas/doc: fix several typos

2024-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing -no-prompt-anchor in gdb.base/vfork-follow-parent.exp
	When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but
	when running it with "taskset -c 0" I run into:
	...
	(gdb) inferior 1^M
	[Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M
	[Switching to thread 1.1 (process 26606)]^M
	(gdb) Reading symbols from vfork-follow-parent-exit...^M
	FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \
	  non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout)
	...

	Fix this by using -no-prompt-anchor.

	Tested on x86_64-linux.

	PR testsuite/31166
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31166

2024-01-08  Sergey Bugaev  <bugaevc@gmail.com>

	Add support for the aarch64-gnu target (GNU/Hurd on AArch64)
	Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or
	aarch64-unknown-gnu.

	The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh,
	or to aarch64linux.sh with Linux-specific logic removed; and mainly different
	from the generic aarch64elf.sh in that it does not set EMBEDDED=yes.

	Coupled with a corresponding GCC patch, this produces a toolchain that can
	sucessfully build working binaries targeting aarch64-gnu.

2024-01-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.base/solib-search.exp more robust
	On aarch64-linux, with gcc 13.2.1, I run into:
	...
	 (gdb) backtrace^M
	 #0  break_here () at solib-search.c:30^M
	 #1  0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M
	 #2  0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M
	 #3  0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
	 #4  0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
	 #5  0x00000000004101b4 in main () at solib-search.c:23^M
	 (gdb) PASS: gdb.base/solib-search.exp: \
	   backtrace (with wrong libs) (data collection)
	 FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs)
	...

	The FAIL is generated by this code in the test-case:
	...
	    if { $expect_fail } {
		# If the backtrace output is correct the test isn't sufficiently
		# testing what it should.
		if { $count == $total_expected } {
		    set fail 1
		}
	...

	The test-case:
	- builds two versions of two shared libs, a "right" and "wrong" version, the
	  difference being an additional dummy function (called spacer function),
	- uses the "right" version to generate a core file,
	- uses the "wrong" version to interpret the core file, and
	- generates a backtrace.

	The intent is that the backtrace is incorrect due to using the "wrong"
	version, but actually it's correct.  This is because the spacer functions
	aren't large enough.

	Fix this by increasing the size of the spacer functions by adding a dummy
	loop, after which we have, as expected, an incorrect backtrace:
	...
	 (gdb) backtrace^M
	 #0  break_here () at solib-search.c:30^M
	 #1  0x0000fffff7f201c0 in ?? ()^M
	 #2  0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
	 #3  0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
	 #4  0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
	 #5  0x00000000004101b4 in main () at solib-search.c:23^M
	 (gdb) PASS: gdb.base/solib-search.exp: \
	   backtrace (with wrong libs) (data collection)
	 PASS: gdb.base/solib-search.exp: backtrace (with wrong libs)
	...

	Tested on aarch64-linux.

2024-01-08  Hu, Lin1  <lin1.hu@intel.com>

	i386: Use .insn describe jmpabs's testcases.
	gas/ChangeLog:

		* testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Use .insn instead
		of .byte to describe test cases.

2024-01-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-07  H.J. Lu  <hjl.tools@gmail.com>

	i386: Correct adcx suffix in disassembler
	Since 0x66 is the opcode prefix for adcx, it is wrong to use the 'S'
	prefix:

	  'S' => print 'w', 'l' or 'q' if suffix_always is true

	on adcx.  Add

	  'L' => print 'l' or 'q' if suffix_always is true

	replace S with L on adcx and adox.

	gas/

		PR binutils/31219
		* testsuite/gas/i386/suffix.d: Updated.
		* testsuite/gas/i386/x86-64-suffix.d: Likewise.
		* testsuite/gas/i386/suffix.s: Add tests for adcx and adox.
		* testsuite/gas/i386/x86-64-suffix.s: Likewise.

	opcodes/

		PR binutils/31219
		* i386-dis.c: Add the 'L' suffix.
		(prefix_table): Replace S with L on adcx and adox.
		(putop): Handle the 'L' suffix.

2024-01-07  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: enable -Wshadow=local
	This brings us in sync with current set of gdb warnings (for C).

2024-01-07  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: change temp var name slightly to avoid shadowing
	Rename the temp var to avoid shadowing another one:

	.../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local]
	11032 |   tmp_tmpb = ({   SI tmp_tmpb;
	      |                      ^~~~~~~~
	.../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here
	11031 |   tmp_tmpres = ({   SI tmp_tmpb;
	      |                        ^~~~~~~~

2024-01-07  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: add error fallbacks when decoding condition & swap codes
	The condition & swap code decoder only checks known bits and sets
	based on that.  If the variable is out of range, it ends up returning
	uninitialized data.  Turn that case into a hard error.

	This fixes build warnings like:
	sim/cris/semcrisv10f-switch.c:13115:11: error:
		variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]

2024-01-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-06  H.J. Lu  <hjl.tools@gmail.com>

	ld: Adjust x86 and x86-64 tests for -z mark-plt
	To support -z mark-plt enabled by default, adjust x86 tests to accept
	non-zero r_addend for JUMP_SLOT relocation and pass -z nomark-plt to
	x86-64 tests if -z mark-plt changes the expected outputs.

		* testsuite/ld-elf/indirect-extern-access-2.rd: Allow non-zero
		r_addend for JUMP_SLOT relocation.
		* testsuite/ld-elf/pr23161d.rd: Likewise.
		* testsuite/ld-ifunc/ifunc-25c-x86.d: Likewise.
		* testsuite/ld-ifunc/ifunc-16-x86-64-now.d: Pass -z nomark-plt
		to linker.
		* testsuite/ld-ifunc/ifunc-16-x86-64.d: Likewise.
		* testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
		* testsuite/ld-ifunc/ifunc-2-local-x86-64.d: Likewise.
		* testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
		* testsuite/ld-ifunc/ifunc-2-x86-64.d: Likewise.
		* testsuite/ld-ifunc/ifunc-20-x86-64.d: Likewise.
		* testsuite/ld-ifunc/ifunc-5b-x86-64.d: Likewise.
		* testsuite/ld-ifunc/pr17154-x86-64-now.d: Likewise.
		* testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
		* testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise.
		* testsuite/ld-x86-64/dt-relr-1a.d: Likewise.
		* testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise.
		* testsuite/ld-x86-64/dt-relr-1b.d: Likewise.
		* testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise.
		* testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
		* testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise.
		* testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
		* testsuite/ld-x86-64/pr19636-2d.d: Likewise.
		* testsuite/ld-x86-64/pr19636-2e.d: Likewise.
		* testsuite/ld-x86-64/pr19636-2f.d: Likewise.
		* testsuite/ld-x86-64/pr19636-2l.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Pass -z nomark-plt to linker
		in 6 tests.

2024-01-06  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: sframe: fix some typos in code comments

2024-01-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	x86: relax AMD Zen5 testcase expectations
	One item was too strict for PE/COFF, and there's really no need to check
	for specific comment contents here.

2024-01-05  Tejas Joshi  <TejasSanjay.Joshi@amd.com>

	Add AMD znver5 processor support
	gas/

		* config/tc-i386.c (cpu_arch): Add znver5 ARCH.
		* doc/c-i386.texi: Add znver5.
		* testsuite/gas/i386/arch-15.d: New.
		* testsuite/gas/i386/arch-15.s: Likewise.
		* testsuite/gas/i386/arch-15-znver5.d: Likewise.
		* testsuite/gas/i386/i386.exp: Add new znver5 test cases.
		* testsuite/gas/i386/x86-64.exp: Likewise.
		* testsuite/gas/i386/x86-64-arch-5.d: Likewise.
		* testsuite/gas/i386/x86-64-arch-5.s: Likewise.
		* testsuite/gas/i386/x86-64-arch-5-znver5.d: Likewise.

	opcodes/

		* i386-gen.c (isa_dependencies): Add ZNVER5 dependencies.
		* i386-init.h: Re-generated.

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	Arm/doc: separate @code from @item for older makeinfo
	At least 4.12 doesn't like the constructs without a separator.

	x86: corrections to CPU attribute/flags splitting
	There are a number of issues with 734dfd1cc966 ("x86: pack CPU flags in
	opcode table"):
	- the condition when two array slots need writing wasn't correct (with
	  enough new Cpu* added an out of bounds array access would validly have
	  been complained about by the compiler),
	- table generation didn't take into account CpuAttrUnused and CpuUnused
	  being independent, and hence there not always (not) being an "unused"
	  bitfield member in both structures,
	- cpu_flags_from_attr() wasn't ready for use on big-endian hosts,
	- there were two style violations.

	ELF: test certain .text/.data usages
	Various targets have / had overrides for .text and/or .data. Make sure
	that in such cases sub-section specifiers are accepted, as mandated by
	the doc.

	ELF: test certain .bss usages
	Various targets have / had overrides for .bss. Make sure that in such
	cases
	- .previous still works correctly (requiring such targets to invoke
	  obj_elf_section_change_hook() from their overriding handlers),
	- sub-section specifiers are accepted as far as feasible (mandated by
	  the doc).

	gas: correct .bss documentation for non-ELF
	Only ELF permits the specification of a subsection, and even there not
	consistently: csky, mcore, and spu handle .bss similar to .lcomm.

	z80: drop .bss override
	It doesn't look to be a good idea to override the custom handlers that
	ELF and COFF have; afaict doing so broke .previous on ELF, and a sub-
	section specifier wasn't accepted either.

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	visium: drop .bss and .skip overrides
	The comment in s_bss() looks bogus (perhaps simply stale, or wrongly
	copied from another target). It also doesn't look to be a good idea to
	override the custom handler that ELF has (afaict doing so broke
	.previous as well as sub-section specification).

	The override for .skip is simply pointless, for read.c having exactly
	the same.

	While there also drop two adjacent redundant (with read.h) declarations
	(which would be outright dangerous if read.h wasn't included anyway).

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	v850: drop .bss override
	While there doesn't look to be anything wrong with this override,
	there's also no apparent reason why this override would be needed. Drop
	it, reducing overall size a tiny bit.

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	score: drop .bss override
	The comment looks bogus (perhaps simply stale, or wrongly copied from
	another target). It also doesn't look to be a good idea to override the
	custom handler that ELF has (afaict doing so broke .previous as well as
	sub-section specification).

	While there also fold the identical handlers for .text (there likely is
	more room for such folding).

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	s390: drop .bss override
	The comment looks bogus (perhaps simply stale), and there are also no
	other precautions against subsections being used on ELF with .bss. It
	also doesn't look to be a good idea to override the custom handler that
	ELF has (afaict doing so further broke .previous).

	rx: drop .bss override
	It doesn't look to be a good idea to override the custom handler that
	ELF has; afaict doing so broke .previous.

	rl78: drop .bss override
	It doesn't look to be a good idea to override the custom handler that
	ELF has; afaict doing so broke .previous.

	pru: fix .text/.data interaction with .previous
	Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
	need calling for .text/.data.

	microblaze: drop/restrict override of .text, .data, and .bss
	While only ELF is supported right now, (stub) code generally is in place
	for the non-ELF case as well. Don't override .bss for ELF - that's
	unlikely to be a good idea anyway and prevented the sub-section
	specifier from being usable. Don't override .text and .data at all - for
	.data and ELF for the same reason, while for .text and ELF obj-elf.c's is
	all we need, and for (hypothetical) non-ELF read.c's identical handling
	would have been invoked anyway.

	m68k: drop .bss override
	The comment looks bogus (perhaps simply stale), and there are also no
	other precautions against subsections being used on ELF with .bss. It
	also doesn't look to be a good idea to override the custom handler that
	ELF has (afaict doing so further broke .previous).

	m32c: drop .bss override
	It doesn't look to be a good idea to override the custom handler that
	ELF has; afaict doing so broke .previous.

	IA64: drop .bss override
	It doesn't look to be a good idea to override the custom handlers that
	ELF and COFF have. While in this case interaction with ELF's .previous
	wasn't screwed, the sub-section specifier wasn't permitted.

	d30v: fix .text/.data interaction with .previous
	Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
	need calling for .text/.data.

	bfin: drop .bss override
	It doesn't look to be a good idea to override the custom handler that
	ELF has; afaict doing so broke .previous.

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	Arm64: drop .bss override
	The comment looks bogus (perhaps simply stale, perhaps wrongly copied
	from Arm in the first place), and there are also no other precautions
	against subsections being used on ELF with .bss. It also doesn't look
	to be a good idea to override the custom handlers that ELF and COFF
	have (afaict doing so further broke .previous on ELF).

	As to the mapping state update - such also doesn't appear to be done
	for other section switching, so its original purpose was at best
	questionable as well.

2024-01-05  Jan Beulich  <jbeulich@suse.com>

	Arm: drop .bss override
	The comment looks bogus (perhaps simply stale), and there are also no
	other precautions against subsections being used on ELF with .bss. It
	also doesn't look to be a good idea to override the custom handlers that
	ELF and COFF have (afaict doing so further broke .previous on ELF).

2024-01-05  Tamar Christina  <tamar.christina@arm.com>

	Enforce C++11 as a minimum for building gold [PR30867]
	The attempt in 5e9091dab885 to correct gold for modern LLVM has broken
	gold for older compilers.  This commit introduced C++11 types without
	changing the build system to require a C++ compiler.  More importantly
	it depends on the compiler having at least C++11 as the default
	language.  Older compilers which support C++11 but not as the default
	language needlessly break.  Fix that.

		PR gold/30867
		* configure.ac (AX_CXX_COMPILE_STDCXX): Require C++11.
		* Makefile.in: Regenerate.
		* aclocal.m4: Regenerate.
		* config.in: Regenerate.
		* configure: Regenerate.
		* testsuite/Makefile.in: Regenerate.

2024-01-05  Alan Modra  <amodra@gmail.com>

	loongarch: 'index' shadows global
	Avoid an error when compiling with older versions of gcc.

		* elfnn-loongarch.c (loongarch_relax_align): Rename "index" to
		"sym_index".

2024-01-05  Alan Modra  <amodra@gmail.com>

	Tidy bfd_scan_vma
	In commit 83c79df86bf4 I removed configure tests for strtoull among
	other library functions part of C99, but didn't remove what is now
	dead code.

		* bfd.c (bfd_scan_vma): Delete fall-back for strtoull.

2024-01-05  Alan Modra  <amodra@gmail.com>

	PR31120, ld-scripts/fill2 fails when bfd_vma is 32 bits
	The ld lexer converts strings to integers without overflow checking,
	so I don't think there is any problem in truncating an integer that
	exceeds the size of a bfd_vma rather than using (bfd_vma) -1.

		PR 31120
		* ldlex.l: Don't use bfd_scan_vma for integer conversion, use
		strtoull.

2024-01-05  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: T-HEAD: Fix wrong instruction encoding for th.vsetvli
	Since the particularity of "th.vsetvli" was not taken into account in the
	initial support patches for XTheadVector, the program operation failed
	due to instruction coding errors. According to T-Head SPEC ([1]), the
	"vsetvl" in the XTheadVector extension consists of SEW, LMUL and EDIV,
	which is quite different from the "V" extension. Therefore, we cannot
	simply reuse the processing of vsetvl in V extension.

	We have set up tens of thousands of test cases to ensure that no
	further encoding issues are there, and and execute all compiled test
	files on real HW and make sure they don't trigger SIGILL.

	Ref:
	[1] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn): Add handling for
		th.vsetvli.
		(my_getThVsetvliExpression): New function.
		(riscv_ip): Likewise.
		* testsuite/gas/riscv/x-thead-vector.d: Likewise.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv.h (OP_MASK_XTHEADVLMUL): New macro.
		(OP_SH_XTHEADVLMUL): Likewise.
		(OP_MASK_XTHEADVSEW): Likewise.
		(OP_SH_XTHEADVSEW): Likewise.
		(OP_MASK_XTHEADVEDIV): Likewise.
		(OP_SH_XTHEADVEDIV): Likewise.
		(OP_MASK_XTHEADVTYPE_RES): Likewise.
		(OP_SH_XTHEADVTYPE_RES): Likewise.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Likewise.
		* riscv-opc.c: Likewise.

2024-01-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle PAC marker
	On aarch64-linux, I run into:
	...
	FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
	...
	due to the PAC marker showing up:
	...
	^Z^Zframe-address^M
	0x000000000041025c [PAC]^M
	^Z^Zframe-address-end^M
	...

	In the docs the marker is documented as follows:
	...
	When GDB is debugging the AArch64 architecture, and the program is using the
	v8.3-A feature Pointer Authentication (PAC), then whenever the link register
	$lr is pointing to an PAC function its value will be masked.  When GDB prints
	a backtrace, any addresses that required unmasking will be postfixed with the
	marker [PAC].  When using the MI, this is printed as part of the addr_flags
	field.
	...

	Update the test-case to allow the PAC marker.

	Likewise in a few other test-cases.

	While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
	a more readable form.  Likewise for the corresponding pat_end.

	Tested on aarch64-linux.

	Approved-By: Luis Machado <luis.machado@arm.com>

	PR testsuite/31202
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202

2024-01-04  Alan Modra  <amodra@gmail.com>

	Update year range in copyright notice of binutils files
	Adds two new external authors to etc/update-copyright.py to cover
	bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
	updates copyright messages as follows:

	1) Update cgen/utils.scm emitted copyrights.
	2) Run "etc/update-copyright.py --this-year" with an extra external
	   author I haven't committed, 'Kalray SA.', to cover gas testsuite
	   files (which should have their copyright message removed).
	3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
	4) Check out */po/*.pot which we don't update frequently.

2024-01-04  Nick Clifton  <nickc@redhat.com>

	Synchronize config.sub and config.guess with their upstream master versions.
	Brings in:
	commit 28ea239c53a2d5d8800c472bc2452eaa16e37af2    config.sub: Remove windows-gnu
	commit a6976af01b0c6206561782183a0db42124b19f7b    config.sub: recognise ARM64EC machine type
	commit 4e60c54be77f743ff8018ab58fb36fd8bc055e2a    config.sub: allow aarch64c-unknown-freebsd
	commit e4786449e1c26716e3f9ea182caf472e4dbc96e0    config.guess: invoke "uname -p" from PATH for non-arm FreeBSD
	commit 021155df7fad97a5ae1baa354e15a03ea14500b4    config.guess: Detect Android (as opposed to GNU/Linux)
	commit 6c78704d542cebfb56d17474fe9f8395e9defb94    config.sub: add javascript-*-ghcjs
	commit 2a7c4b64d4aec5c3a8a975625f0f8c369d365667    testsuite: add coverage for vendor-clobbering
	commit 39c49ea712cba8ae6613ef85ab22fe7c552b48b0    config.sub: Systematize parsing of machine code formats
	commit d4e37b5868ef910e3e52744c34408084bb13051c    config.sub: Handle arbitrary MIPS CPU names
	commit af8d803a82436779d35ea389888788c78677804e    config.guess (aarch64:Linux:*:*): Detect 32-bit ABI
	commit 602766470c886df7ae07bcfd7dcf532f0783d3e0    Add KVX MPPA detection
	commit be68d790b6bc7dd84982fa6760f1448e92849e63    config.sub: Add Apple tvOS and watchOS
	commit 998ba1414387b4ce1a519be234e1609bc7912e0c    config.sub: Accept $cpu-$vendor-none-{coff,elf}

2024-01-04  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix linker generate PLT entry for data symbol
	With old "medium" code model, we call a function with a pair of PCALAU12I
	and JIRL instructions. The assembler produces something like:

	   8:	1a00000c 	pcalau12i   	$t0, 0
				8: R_LARCH_PCALA_HI20	g
	   c:	4c000181 	jirl        	$ra, $t0, 0
				c: R_LARCH_PCALA_LO12	g

	The linker generates a "PLT entry" for data without any diagnostic.
	If "g" is a data symbol and ld with -shared option, it may load two
	instructions in the PLT.

	Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT
	entry.

	For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC
	and STT_GNU_IFUNC symbols.

2024-01-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve error reporting from expression parser
	This commits changes how errors are reported from the expression
	parser.  Previously, parser errors were reported like this:

	  (gdb) p a1 +}= 432
	  A syntax error in expression, near `}= 432'.
	  (gdb) p a1 +
	  A syntax error in expression, near `'.

	The first case is fine, a user can figure out what's going wrong, but
	the second case is a little confusing; as the error occurred at the
	end of the expression GDB just reports the empty string to the user.

	After this commit the first case is unchanged, but the second case now
	reports like this:

	  (gdb) p a1 +
	  A syntax error in expression, near the end of `a1 +'.

	Which I think is clearer.  There is a possible issue if the expression
	being parsed is very long, GDB will repeat the whole expression.  But
	this issue already exists in the standard case; if the error occurs
	early in a long expression GDB will repeat everything after the syntax
	error.  So I've not worried about this case in my new code either,
	which keeps things simpler.

	I did consider trying to have multi-line errors here, in the style
	that gcc produces, with some kind of '~~~~~^' marker on the second
	line to indicate where the error occurred; but I rejected this due to
	the places in GDB where we catch an error and repackage the message
	within some longer string, I don't think multi-line error messages
	would work well in that case.  At a minimum it would require some
	significant work in order to make all our error handling multi-line
	aware.

	I've added a couple of extra tests in gdb.base/exprs.exp.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-01-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: merge error handling from different expression parsers
	Many (all?) of the expression parsers implement yyerror to handle
	parser errors, and all of these functions are basically identical.

	This commit adds a new parser_state::parse_error() function, which
	implements the common error handling code, this function can then be
	called from all the different yyerror functions.

	The benefit of this is that (in a future commit) I can improve the
	error output, and all the expression parsers will benefit.

	This commit is pure refactoring though, and so, there should be no
	user visible changes after this commit.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-01-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't try to style content in error calls
	While working on a later commit in this series I realised that the
	error() function doesn't support output styling.  Due to the way that
	output from error() calls is passed around within the exception
	object and often combined with other output, it's not immediately
	obvious to me if we should be trying to support styling in this
	context or not.

	On inspection, I found one place in GDB where we apparently try to
	apply styling within the error() output (in procfs.c).  I suspect this
	error() call might not be tested.

	Rather than try to implement styling in the error() output, right now
	I'm proposing to just remove the attempt to style error() output.

	This doesn't mean that someone shouldn't add error() styling in the
	future, but right now, I'm not planning to do that, I just wanted to
	fix this in passing.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2024-01-04  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix loongarch*-elf target ld testsuite failure
	The loongarch*-elf target does not support SHARED and PIE, so this
	target is skipped for some tests that require these options.

2024-01-04  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Fix some macro that cannot be expanded properly
	Suppose we want to use la.got to generate 32 pcrel and
	32 abs instruction sequences respectively. According to
	the existing conditions, to generate 32 pcrel sequences
	use -mabi=ilp32*, and to generate 32 abs use -mabi=ilp32*
	and -mla-global-with-abs.

	Due to the fact that the conditions for generating 32 abs
	also satisfy 32 pcrel, using -mabi=ilp32* and -mla-global-with-abs
	will result in only generating instruction sequences of 32 pcrel.

	By modifying the conditions for macro expansion and adjusting
	the matching order of macro instructions, it is ensured that
	the correct sequence of instructions can be generated.

2024-01-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: unify igen filter modules
	The common igen code was forked from the ppc long ago.  The filter
	module is still pretty similar in API, so we can unfork them with
	a little bit of effort.

	The filter.c module is still here because of the unique it_is API.
	The common igen code doesn't seem to have an equiv API as this only
	operates on two strings and not an actual filter object, and it's
	easy enough to leave behind to unfork the rest.

2024-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: unify igen line number output modules
	The common igen code was forked from the ppc long ago.  The lf module
	is still pretty similar in API, so we can unfork them with a little
	bit of effort.

	Some of the generated ppc code is now slightly different, but that's
	because of fixes the common igen code has gained, but not the ppc igen
	code (e.g. fixing of #line numbers).

	The ppc code retains lf_print__c_code because the common igen code
	rewrote the logic to a new table.c API.  Let's delay that in the ppc
	code to at least unfork all this code.

2024-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: igen: clean up headers a bit
	Add standard multiple inclusion protection, and add a few missing
	local includes when one header uses another.  This isn't complete,
	but fixes some short comings seen when merging the ppc igen.

	sim: ppc: switch to common endian code
	The common sim-endian is a forked & updated version of the ppc code.
	Fortunately, they didn't diverge from the basic APIs, so they are
	still compatible, which means we can just delete the ppc version now
	that the build env is merged at the top-level.

	sim: common: include sim-types.h in the endian header directly
	This is a bit redundant for most ports as they go through sim-basics.h
	which always includes sim-types.h before including sim-endian.h, but in
	order to unify ppc's sim-endian code, we need this include here.  Plus,
	it's the directly we generally want to go to get away from one header
	that defines all APIs and causes hard to untangle dependencies.

	sim: ppc: rename local ALU SIGNED64 macros
	The common/ code has macros with the same name but different behavior:
	it's for declaring integer constants as 64-bit, not for casting them.
	Rename ppc's local variant since it's only used in this file in order
	to avoid conflicts.

	sim: ppc: sync WITH_TARGET_{ADDRESS,CELL}_BITSIZE with common/
	This will make it easier to share common/ code that rely on these
	additional defines.

	sim: cr16: cleanup unused variable compiler warnings

	sim: configure: switch to m4_map
	Minor reduction in boilerplate here.  No real functional changes.

	sim: drop support for recursive makes entirely
	Now that all ports have been merged to the top-level, we no longer need
	this framework to pass settings down to sub-makefiles.  Delete it all.

	sim: ppc: hoist compilation up to top-level
	This removes all recursive makes from the ppc port.

	sim: drop support for automatic subdir recursion
	No port relies on this anymore, so we can scrub it all.

2024-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  It adds some overhead, so it's not great, but it shouldn't
	be a big deal.  This will go away once compilation is hoisted up.

2024-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: move main.o compilation to top-level

2024-01-03  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: delete bfd/.elfnn-loongarch.c.swp

2024-01-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-02  Carl Love  <cel@linux.ibm.com>

	Fix GDB reverse-step and reverse-next command behavior
	Currently GDB when executing in reverse over multiple statements in a single
	line of source code, GDB stops in the middle of the line.  Thus requiring
	multiple commands to reach the previous line.  GDB should stop at the first
	instruction of the line, not in the middle of the line.

	The following description of the incorrect behavior was taken from an
	earlier message by Pedro Alves <pedro@palves.net>:

	https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html

	---------------------------------

	The source line looks like:

	   func1 ();  func2 ();

	in the test case:

	(gdb) list 1
	1       void func1 ()
	2       {
	3       }
	4
	5       void func2 ()
	6       {
	7       }
	8
	9       int main ()
	10      {
	11        func1 (); func2 ();
	12      }

	compiled with:

	 $ gcc reverse.c -o reverse -g3 -O0
	 $ gcc -v
	 ...
	 gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)

	Now let's debug it with target record, using current gdb git master
	(f3d8ae90b236),

	 $ gdb ~/reverse
	 GNU gdb (GDB) 14.0.50.20230124-git
	 ...
	 Reading symbols from /home/pedro/reverse...
	 (gdb) start
	 Temporary breakpoint 1 at 0x1147: file reverse.c, line 11.
	 Starting program: /home/pedro/reverse
	 [Thread debugging using libthread_db enabled]
	 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

	 Temporary breakpoint 1, main () at reverse.c:11
	 11        func1 (); func2 ();
	 (gdb) record

	 (gdb) disassemble /s
	 Dump of assembler code for function main:
	 reverse.c:
	 10      {
	    0x000055555555513f <+0>:     endbr64
	    0x0000555555555143 <+4>:     push   %rbp
	    0x0000555555555144 <+5>:     mov    %rsp,%rbp

	 11        func1 (); func2 ();
	 => 0x0000555555555147 <+8>:     mov    $0x0,%eax
	    0x000055555555514c <+13>:    call   0x555555555129 <func1>
	    0x0000555555555151 <+18>:    mov    $0x0,%eax
	    0x0000555555555156 <+23>:    call   0x555555555134 <func2>
	    0x000055555555515b <+28>:    mov    $0x0,%eax

	 12      }
	    0x0000555555555160 <+33>:    pop    %rbp
	    0x0000555555555161 <+34>:    ret
	 End of assembler dump.

	 (gdb) n
	 12      }

	So far so good, a "next" stepped over the whole of line 11 and stopped at
	line 12.

	Let's confirm where we are now:

	 (gdb) disassemble /s
	 Dump of assembler code for function main:
	 reverse.c:
	 10      {
	    0x000055555555513f <+0>:     endbr64
	    0x0000555555555143 <+4>:     push   %rbp
	    0x0000555555555144 <+5>:     mov    %rsp,%rbp

	 11        func1 (); func2 ();
	    0x0000555555555147 <+8>:     mov    $0x0,%eax
	    0x000055555555514c <+13>:    call   0x555555555129 <func1>
	    0x0000555555555151 <+18>:    mov    $0x0,%eax
	    0x0000555555555156 <+23>:    call   0x555555555134 <func2>
	    0x000055555555515b <+28>:    mov    $0x0,%eax

	 12      }
	 => 0x0000555555555160 <+33>:    pop    %rbp
	    0x0000555555555161 <+34>:    ret
	 End of assembler dump.

	Good, we're at the first instruction of line 12.

	Now let's undo the "next", with "reverse-next":

	 (gdb) reverse-next
	 11        func1 (); func2 ();

	Seemingly stopped at line 11.  Let's see exactly where:

	 (gdb) disassemble /s
	 Dump of assembler code for function main:
	 reverse.c:
	 10      {
	    0x000055555555513f <+0>:     endbr64
	    0x0000555555555143 <+4>:     push   %rbp
	    0x0000555555555144 <+5>:     mov    %rsp,%rbp

	 11        func1 (); func2 ();
	    0x0000555555555147 <+8>:     mov    $0x0,%eax
	    0x000055555555514c <+13>:    call   0x555555555129 <func1>
	 => 0x0000555555555151 <+18>:    mov    $0x0,%eax
	    0x0000555555555156 <+23>:    call   0x555555555134 <func2>
	    0x000055555555515b <+28>:    mov    $0x0,%eax

	 12      }
	    0x0000555555555160 <+33>:    pop    %rbp
	    0x0000555555555161 <+34>:    ret
	 End of assembler dump.
	 (gdb)

	And lo, we stopped in the middle of line 11!  That is a bug, we should have
	stepped back all the way to the beginning of the line.  The "reverse-next"
	should have fully undone the prior "next" command.

	--------------------

	This patch fixes the incorrect GDB behavior by ensuring that GDB  stops at
	the first instruction in the line.

	The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite
	to verify this fix when the line table information is and is not available.

2024-01-02  Carl Love  <cel@linux.ibm.com>

	PowerPC and aarch64: Fix reverse stepping failure
	When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
	the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
	gdb.reverse/solib-reverse.exp.

	The failure happens around the following code:

	38  b[1] = shr2(17);          /* middle part two */
	40  b[0] = 6;   b[1] = 9;     /* generic statement, end part two */
	42  shr1 ("message 1\n");     /* shr1 one */

	Normal execution:

	- step from line 38 will land on line 40.
	- step from line 40 will land on line 42.

	Reverse execution:
	- step from line 42 will land on line 40.
	- step from line 40 will land on line 40.
	- step from line 40 will land on line 38.

	The problem here is that line 40 contains two contiguous but distinct
	PC ranges in the line table, like so:

	Line 40 - [0x7ec ~ 0x7f4]
	Line 40 - [0x7f4 ~ 0x7fc]

	The two distinct ranges are generated because GCC started outputting source
	column information, which GDB doesn't take into account at the moment.

	When stepping forward from line 40, we skip both of these ranges and land on
	line 42. When stepping backward from line 42, we stop at the start PC of the
	second (or first, going backwards) range of line 40.

	Since we've reached ecs->event_thread->control.step_range_start, we stop
	stepping backwards.

	The above issues were fixed by introducing a new function that looks for
	adjacent PC ranges for the same line, until we notice a line change. Then
	we take that as the start PC of the range.  The new start PC for the range
	is used for the control.step_range_start when setting up a step range.

	The test case gdb.reverse/map-to-same-line.exp is added to test the fix
	for the above reverse step issues.

	Patch has been tested on PowerPC, X86 and AArch64 with no regressions.

2024-01-02  Carl Love  <cel@us.ibm.com>

	Add gdb_compile options column-info and no-column-info
	This patch adds two new options to gdb_compile to specify if the compile
	should or should not generate the line table information.  The
	options are supported on clang and gcc version 7 and newer.

	Patch has been tested on PowerPC with both gcc and clang.

2024-01-02  Guinevere Larsen  <blarsen@redhat.com>

	gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table
	This commit adds a mechanism for GDB to detect the linetable opcode
	DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
	that a certain instruction marks the point where the frame is destroyed.

	While the standard allows for multiple points marked with epilogue_begin
	in the same function, for performance reasons, the function that
	searches for the epilogue address will only find the last address that
	sets this flag for a given block.

	This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
	use the epilogue begin directly, and only if an epilogue can't be found
	will it attempt heuristics based on the current instruction.

	Finally, this commit also changes the dwarf assembler to be able to emit
	epilogue-begin instructions, to make it easier to test this patch

	Approved-By: Tom Tromey <tom@tromey.com>

2024-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: hoist pk.h creation to top-level

	sim: ppc: hoist hw.[ch] creation to top-level

	sim: ppc: hoist igen execution to top-level
	Invoke ppc's igen from the top-level like we do for all other ports.

	sim: ppc: merge configure logic into top-level
	Now that the ppc configure script is just namespaced options, we can
	move it to ppc/acinclude.m4 and include it directly in the top-level
	configure script and kill off the last subdir configure script.

	sim: ppc: scope configure options to --enable-sim-ppc-xxx
	To prepare for moving these into the top-level configure, namespace
	then with the port name like we do with all other ports.

	sim: ppc: standardize configure option processing
	Switch from ad-hoc $silent checks & echo calls to standard
	AC_MSG_CHECKING & AC_MSG_RESULT calls.  Also delete pointless
	variable setting after calling AC_MSG_ERROR.

	sim: ppc: switch to AS_HELP_STRING for automatic formatting

	sim: ppc: drop now unused config.in

	sim: ppc: move defines.h generation to the top-level
	Since we rely on the top-level config.h now, the defines.h generation
	step should live here too.

	sim: ppc: drop configure compiler checks
	Now that the ppc script only checks configure options and sets up
	variables in the Makefile from those, delete all the compile related
	logic to greatly simplify the configure script.

	sim: ppc: drop custom config.h header
	Now that everything has moved to the top-level, we can drop the
	custom ppc config.h and reuse the common one.

	sim: ppc: stop including headers from gdb/
	The common sim code doesn't snoop in gdb/, and the ppc code doesn't
	need to either.  Any common code we pull from gnulib/ now only.

	sim: ppc: move termios probes to top-level
	This is the last compile-time logic in the ppc subdir.

	sim: ppc: switch to AC_CACHE_CHECK
	This macro replaces the AC_MSG_CHECKING+AC_CACHE_VAL+AC_MSG_RESULT
	which reduces the boilerplate in here a little bit.

	sim: ppc: switch struct member checks to AC_CHECK_MEMBER
	This covers a lot of the AC_MSG_CHECKING+AC_TRY_COMPILE+AC_MSG_RESULT
	boilerplate and matches what we do in the top-level platform checks.

	sim: ppc: move termio defines to config.h
	Move the defines from explicit -D options to config.h defines to simplify
	the build and make it easier to move to the top-level configure.

	sim: ppc: move struct statfs to top-level

	sim: ppc: move long long test to top-level
	While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
	(like libiberty) seem to, so check for it in the top-level for all
	ports to leverage.

	sim: ppc: hoist sysv tests to top-level
	Now that the sysv tests turn into config.h defines and everything
	checks that, we can move the tests to the top-level and out of the
	ppc subdir.

2024-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: always compile in the sysv sem & shm device files
	Move the stub logic to the device files themselves.  This makes the
	configure & build logic more static which will make it easier to move
	to the top-level build, and matches what we did with the common/ hw
	tree already.

	This also decouples the logic from the two -- in the past, you needed
	both sem & shm in order to enable the device models, but now each one
	is tied to its own independent knob.  Practically speaking, this will
	probably not make a difference, but it simplifies the build a bit.

2024-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: change SysV sem & shm tests to compile-time
	Instead of executing code to see if SysV semaphores & shared memory
	are available, switch to just a compile-time test.  The system used
	to compile might not match the system used to run the code wrt the
	current kernel & OS settings, but the library APIs should.  So move
	the failures from compile-time to runtime so the program is more
	portable, and works correctly even when cross-compiling.

2024-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: merge System V semaphores checks
	Compile tests can use earlier defines, so hoist the HAVE_UNION_SEMUN
	define to before the semaphore check, and use it in the test so that
	we can merge the 2 versions into one.

	This also defines HAVE_UNION_SEMUN even when ac_cv_sysv_sem is not
	set, but that's OK as this define is only about a type existing, not
	about whether the overall code is usable.

2024-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: fix bad AC_CACHE_CHECK call with semun
	The first arg is the cache var name, and this one was typoed relative
	to what the call actually set.  We also don't need the manual call to
	AC_MSG_RESULT as the AC_CACHE_CHECK takes care of it for us.

	sim: ppc: delete unused build compile & link settings
	These should have been removed as part of the ppc/igen merging into the
	top-level, but they were missed.  Clean up now.

2024-01-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2024-01-01  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: merge misc igen APIs
	The common igen code provides the same misc APIs as the ppc version,
	so delete the ppc code and pull in the common one.  There is one
	minor difference: the ppc code has a unique dumpf function.  The
	common code switched to lf_printf for the same functionality, but
	since that requires changes throughout the igen codebase, delay that
	cleanup for now so we can merge the rest.

	sim: ppc: rework igen error to match common
	Switch to an ERROR macro and tweak the error signature to match the
	common igen version in preparation for merging the two implementations.

	sim: igen: extend error to take arguments
	The ppc igen error helper allows arbitrary printf calls, so extend
	the common one to do the same.

	sim: ppc: rename igen max_insn_bit_size
	We want to avoid conflicts with the common igen enums.  This should
	get migrated over to the common parsing logic, but for now, switch
	the name to avoid redefinition.

	sim: igen: minor constify logic
	Copy some improvements from the ppc igen code.

	sim: ppc: unify igen filter_filename implementations
	Now that both igen implementations are in the top-level, we can unify
	the filter_filename implementation between them since they're the same
	(literally the same code).

	sim: ppc: replace filter_filename with lbasename
	The lbasename function from libiberty provides the same API as this
	custom function.  The common/ code already made the switch, so make
	the same change to the ppc code to avoid target duplication.

	sim: ppc: hoist igen compilation into top-level
	This simplifies the build a bit (especially for deps in port subdirs),
	and avoids recursive make.  This in turn speeds up the build, and lets
	us reuse existing build-time vs host-time logic from Makefile.am.

	sim: ppc: drop build-config.h usage
	This header is only used by the igen tool, and none of the igen code
	depends on the configure-time checks.  Delete the logic to simplify
	to prepare for moving it to the local.mk code.

	sim: ppc: simplify filter_host.c logic
	Switch this from a build-time generation to a static include.  This
	makes the build rules a bit simpler, especially as we move them to
	Automake from hand-written makefiles.

	sim: igen: remove libigen.a when cleaning

	sim: ppc: drop unused host bitsize settings
	This is never set anywhere, so it's always empty.  Scrub it.

	sim: frv: fix cmpb uninitialized variable usage
	This code sets up the cc variable based on the comparison of other
	registers, but it does so incrementally with bit operations, and it
	never initializes the cc variable.  Initialize it to 0 which the
	cmpba insn is already doing.

	sim: arm: mark local read-only arrays as static const
	Move it into read-only data sections to avoid constructing them on the
	stack at runtime.

	sim: warnings: enable -Wunused-variable

	cpu: or1k: drop unused l.swa flag
	The "flag" argument isn't set/used in this insn, so drop it.
	This fixes an unused variable warning in the generated sim.

2024-01-01  Tom Tromey  <tom@tromey.com>

	sim: fix pervasive typo
	I noticed a typo in a sim constant.  This patch fixes it.
		permenant -> permanent

2024-01-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-31  Tom Tromey  <tom@tromey.com>

	Run 'black' on tui-window.py
	Mark pointed out that a recent patch of mine caused the buildbot to
	complain about the formatting of some Python test code.  This patch
	re-runs 'black' to fix the problem.

2023-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix typo in gdb.base/catch-syscall.exp
	On aarch64-linux with a gdb build without libexpat, I run into:
	...
	(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
	  catch syscall 59
	continue
	Continuing.

	Catchpoint 5 (call to syscall 59), 0x0000fffff7e04578 in pipe () from \
	  /lib64/libc.so.6
	(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
	...

	In the test-case, this pattern handles either the syscall name or number for
	the pipe syscall:
	...
	  -re -wrap "Catchpoint $decimal \\(call to syscall (pipe|$SYS_pipe)\\).*" {
	...
	but the pattern for the pipe2 syscall mistakenly uses SYS_pipe instead of
	SYS_pipe2:
	...
	  -re -wrap "Catchpoint $decimal \\(call to syscall (pipe2|$SYS_pipe)\\).*" {
	...
	and consequently doesn't handle the pipe2 syscall number.

	Fix the typo by using SYS_pipe2 instead.

	Tested on aarch64-linux.

2023-12-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-30  Tom Tromey  <tom@tromey.com>

	Add keywords to TuiWindow.write
	The gdb docs promise that methods with more than two or more arguments
	will accept keywords.  However, I found that TuiWindow.write didn't
	allow them.  This patch adds the missing support.

2023-12-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/gdb-index-err.exp for root user
	When running test-case gdb.base/gdb-index-err.exp in a container as root user,
	I run into:
	...
	FAIL: gdb.base/gdb-index-err.exp: flag=: \
	  try to write index to a non-writable directory
	FAIL: gdb.base/gdb-index-err.exp: flag=-dwarf-5: \
	  try to write index to a non-writable directory
	...

	The test-case creates a directory without write permissions:
	...
	$ ls -ald private
	dr-xr-xr-x 2 root root 4096 Dec 29 06:26 private/
	...
	but apparently the root user is still able to write in it.

	Fix this by making the test unsupported for the root user.

	Tested on x86_64-linux.

	Reviewed-By: Lancelot SIX <lancelot.six@amd.com>

	PR testsuite/31197
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31197

2023-12-30  Alan Modra  <amodra@gmail.com>

	LoongArch: Commas inside double quotes
	This adds an extra feature: Commas inside double quotes are not an
	arg delimiter, and thus can be part of the arg.

		* loongarch-coder.c (loongarch_split_args_by_comma): Commas
		inside quotes are not arg delimiters.

2023-12-30  Alan Modra  <amodra@gmail.com>

	Regen bfd-in2.h
	Please DON'T edit this file.  READ THE COMMENT!

2023-12-30  Joseph Myers  <jsm@polyomino.org.uk>

	MAINTAINERS: Update my email address
	There will be another update in January.

2023-12-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-29  H.J. Lu  <hjl.tools@gmail.com>

	x86: Append "#pass" to APX tests
	Append "#pass" to APX tests for targets which pad text sections with NOPs.

		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Append
		"#pass".
		* testsuite/gas/i386/x86-64-apx-ndd-optimize.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-ndd.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: Likewise.
		* testsuite/gas/i386/x86-64-apx-pushp-popp.d: Likewise.

2023-12-29  H.J. Lu  <hjl.tools@gmail.com>

	x86: Don't use .insn with '/'
	'/' starts a comment for some targets.  Use .byte instead of .insn with
	'/'.

		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Use .byte
		instead of .insn with '/'.

2023-12-29  H.J. Lu  <hjl.tools@gmail.com>

	Fix x86-64: Add R_X86_64_CODE_4_GOTPCRELX
	commit 3d5a60de52556f6a53d71d7e607c6696450ae3e4
	Author: H.J. Lu <hjl.tools@gmail.com>
	Date:   Thu Jun 8 10:01:03 2023 -0700

	    x86-64: Add R_X86_64_CODE_4_GOTPCRELX

	added a new field, fx_tcbit3, to fix.  But it didn't initialize it.
	Fix it by clearing it in fix_new_internal.

		* wrtite.c (fix_new_internal): Clear fx_tcbit3.

2023-12-29  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
	    Bernhard Heckel  <bernhard.heckel@intel.com>
	    Tim Wiederhake  <tim.wiederhake@intel.com>

	dwarf, fortran: add support for DW_TAG_entry_point
	Fortran provides additional entry points for subroutines and functions.
	These entry points may use only a subset (or a different set) of the
	parameters of the original subroutine.  The entry points may be described
	via the DWARF tag DW_TAG_entry_point.

	This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
	Currently, between ifx/ifort/gfortran, only ifort is actually emitting
	this tag.  Both, ifx and gfortran use the DW_TAG_subprogram tag as
	workaround/alternative.  Thus, this patch really only adds more ifort
	support.  Even so, some of the attached tests still fail for ifort, due
	to some wrong line info generated for the entry points in ifort.

	After this patch it is possible to set a breakpoint in gdb with the
	ifort compiled example at the entry points 'foo' and 'foobar', which was not
	possible before.

	As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
	which uses some underlying c compiled code and adds some Fortran style DWARF
	to it emitting the DW_TAG_entry_point.  Before this patch it was not
	possible to actually define breakpoint at the entry point tags.

	For gfortran there actually exists a bug on bugzilla, asking for the use
	of DW_TAG_entry_point over DW_TAG_subprogram:

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134

	This patch was originally posted here

	https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html

	but its review/pinging got lost after a while.  I reworked it to fit the
	current GDB.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-12-29  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, dwarf: add assert to dwarf2_get_pc_bounds
	In dwarf2_get_pc_bounds we were writing unchecked to *lowpc.  This
	commit adds a gdb_assert to first check that lowpc != nullptr.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-12-29  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, dwarf: move part of dwarf2_get_pc_bounds into separate function
	This commit is in preparation of the next commit.  There, we will add
	a second variation to retrieve the pc bounds for DIEs tagged with
	DW_TAG_entry_point.  Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc
	we will call a separate method for entry points.  As the validity checks
	at the endo f dwarf2_get_pc_bounds are the same for both variants,
	we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method,
	outsourcing part of dwarf2_get_pc_bounds.

	This commit should have no functional impact on GDB.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-12-29  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: ld: Add support for tls le relax.
	Add tls le relax related testsuites in ld.

	The new test cases are mainly tested in three aspects:

	1. tls le relax function correctness test.
	2. tls le relax boundary check test.
	3. tls le relax function compatibility test.

	ld/testsuite/ChangeLog:

		* ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.
		* ld/testsuite/ld-loongarch-elf/old-tls-le.s: New test.
		* ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s: Likewise.
		* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s: Likewise.
		* ld/testsuite/ld-loongarch-elf/relax-tls-le.s: Likewise.
		* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s: Likewise.

2023-12-29  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: gas: Add support for tls le relax.
	Add tls le relax related relocs support and testsuites in gas.

	The main test is three new relocation items,
	R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_HI20_R,
	R_LARCH_TLS_LE_LO12_R can be generated properly
	and tls le insn format check.

	gas/ChangeLog:

		* config/tc-loongarch.c:
		(loongarch_args_parser_can_match_arg_helper): Add support for relax.
		* gas/testsuite/gas/loongarch/reloc.d: Likewise.
		* gas/testsuite/gas/loongarch/reloc.s: Likewise.
		* gas/testsuite/gas/loongarch/loongarch.exp: Likewise.
		* gas/testsuite/gas/loongarch/tls_le_insn_format_check.s: New test.

2023-12-29  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: opcodes: Add support for tls le relax.
	Add new opcode for tls le relax.

		opcode/ChangeLog:

		* loongarch-opc.c: Add new loongarch opcode.

2023-12-29  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: include: Add support for tls le relax.
	Add new relocs number for tls le relax.

	include/ChangeLog:

		* elf/loongarch.h:
		(RELOC_NUMBER (R_LARCH_TLS_LE_HI20_R, 121)): New relocs number.
		(RELOC_NUMBER (R_LARCH_TLS_LE_ADD_R, 122)): Likewise.
		(RELOC_NUMBER (R_LARCH_TLS_LE_LO12_R, 123)): Likewise.

2023-12-29  changjiachen  <changjiachen@stu.xupt.edu.cn>

	LoongArch: bfd: Add support for tls le relax.
	Add tls le relax support and related relocs in bfd.

	New relocation related explanation can refer to the following url:
	https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc

	This support does two main things:

	1. Implement support for three new relocation items in bfd.

	The three new relocation items are shown below:

	R_LARCH_TLS_LE_ADD_R
	R_LARCH_TLS_LE_HI20_R
	R_LARCH_TLS_LE_LO12_R

	2. ADD a new macro RELOCATE_TLS_TP32_HI20

	Handle problems caused by symbol extensions in TLS LE, The processing
	is similar to the macro RELOCATE_CALC_PC32_HI20 method.

	3. Implement the tls le relax function.

	bfd/ChangeLog:

		* bfd-in2.h: Add relocs related to tls le relax.
		* elfnn-loongarch.c:
		(loongarch_relax_tls_le): New function.
		(RELOCATE_TLS_TP32_HI20): New macro.
		(loongarch_elf_check_relocs): Add new reloc support.
		(perform_relocation): Likewise.
		(loongarch_elf_relocate_section): Handle new relocs related to relax.
		(loongarch_elf_relax_section): Likewise.
		* elfxx-loongarch.c:
		(LOONGARCH_HOWTO (R_LARCH_TLS_LE_ADD_R)): New reloc how to type.
		(LOONGARCH_HOWTO (R_LARCH_TLS_LE_HI20_R)): Likewise.
		(LOONGARCH_HOWTO (R_LARCH_TLS_LE_LO12_R)): Likewise.
		* libbfd.h: Add relocs related to tls le relax.
		* reloc.c: Likewise.

2023-12-29  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: THEAD: Add 5 assembly pseudoinstructions for XTheadVector extension
	In order to make it easier to complete the compiler's support for
	the XTheadVector extension and to be as compatible as possible
	with the programming model of the 'V' extension ([1]), we consider
	adding a few pseudo instructions ([2]).

	th.vmmv.m vd,vs		=> th.vmand.mm vd,vs,vs
	th.vneg.v vd,vs		=> th.vrsub.vx vd,vs,x0
	th.vncvt.x.x.v vd,vs,vm	=> th.vnsrl.vx vd,vs,x0,vm
	th.vfneg.v vd,vs	=> th.vfsgnjn.vv vd,vs,vs
	th.vfabs.v vd,vs	=> th.vfsgnjx.vv vd,vs,vs

	Ref:
	[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641302.html
	[2] https://github.com/T-head-Semi/thead-extension-spec/pull/40

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for new
		pseudoinstructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	opcodes/ChangeLog:

		* riscv-opc.c: Add new pseudoinstructions.

2023-12-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	ld: Mention support for Intel APX relocations in NEWS

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	Gold: Handle R_X86_64_CODE_4_GOTPC32_TLSDESC/R_X86_64_CODE_4_GOTTPOFF
	Handle R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
	Convert

		add	name@gottpoff(%rip), %reg
		mov	name@gottpoff(%rip), %reg

	to

		add	$name@tpoff, %reg
		mov	$name@tpoff, %reg

	and

		lea	name@tlsdesc(%rip), %reg

	to

		mov     $name@tpoff, %reg
		mov	name@gottpoff(%rip), %reg

	if the instruction is encoded with the REX2 prefix when possible.

	elfcpp/

		* x86_64.h (R_X86_64_CODE_4_GOTTPOFF): New.
		(R_X86_64_CODE_4_GOTPC32_TLSDESC): Likewise.

	gold/

		* x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle
		R_X86_64_CODE_4_GOTPC32_TLSDESC and R_X86_64_CODE_4_GOTTPOFF.
		(Target_x86_64::Scan::get_reference_flags): Likewise.
		(Target_x86_64::Scan::local): Likewise.
		(Target_x86_64::Scan::global): Likewise.
		(Target_x86_64::Relocate::relocate): Likewise.
		(Target_x86_64::Relocate::relocate_tls): Likewise.
		(Target_x86_64::Relocate::tls_desc_gd_to_ie): Handle
		R_X86_64_CODE_4_GOTPC32_TLSDESC.
		(Target_x86_64::Relocate::tls_desc_gd_to_le): Likewise.
		(Target_x86_64::Relocate::tls_ie_to_le): Handle.
		R_X86_64_CODE_4_GOTTPOFF.
		* testsuite/Makefile.am: Add x86_64_ie_to_le test.
		* testsuite/Makefile.in: Regenerated.
		* testsuite/x86_64_gd_to_le.s: Add R_X86_64_CODE_4_GOTPC32_TLSDESC
		test.
		* testsuite/x86_64_gd_to_le.sh: Check GDesc to LE conversion.
		* testsuite/x86_64_ie_to_le.s: New file.
		* testsuite/x86_64_ie_to_le.sh: Likewise.

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Add R_X86_64_CODE_4_GOTTPOFF/R_X86_64_CODE_4_GOTPC32_TLSDESC
	For

		add	name@gottpoff(%rip), %reg
		mov	name@gottpoff(%rip), %reg

	add

	 # define R_X86_64_CODE_4_GOTTPOFF	44

	and for

		lea	name@tlsdesc(%rip), %reg

	add

	 # define R_X86_64_CODE_4_GOTPC32_TLSDESC	45

	if the instruction starts at 4 bytes before the relocation offset.
	They are similar to R_X86_64_GOTTPOFF and R_X86_64_GOTPC32_TLSDESC,
	respectively.  Linker can covert GOTTPOFF to

		add	$name@tpoff, %reg
		mov	$name@tpoff, %reg

	and GOTPC32_TLSDESC to

		mov	$name@tpoff, %reg
		mov	name@gottpoff(%rip), %reg

	if the instruction is encoded with the REX2 prefix when possible.

	bfd/

		* elf64-x86-64.c (x86_64_elf_howto_table): Add
		R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
		(R_X86_64_standard): Updated.
		(x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTTPOFF
		and BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
		(elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_4_GOTTPOFF
		and R_X86_64_CODE_4_GOTPC32_TLSDESC.
		(elf_x86_64_tls_transition): Likewise.
		(elf_x86_64_scan_relocs): Likewise.
		(elf_x86_64_relocate_section): Likewise.
		* reloc.c (bfd_reloc_code_real): Add
		BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
		BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Likewise.

	gas/

		* config/tc-i386.c (tc_i386_fix_adjustable): Handle
		BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
		BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
		(md_assemble): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF.
		(output_insn): Don't add empty REX prefix with REX2 prefix.
		(output_disp): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
		BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
		(md_apply_fix): Likewise.
		(i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTTPOFF or
		BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC if ixp->fx_tcbit3 is set.
		(tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
		BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
		* testsuite/gas/i386/x86-64-gottpoff.d: New file.
		* testsuite/gas/i386/x86-64-gottpoff.s: Likewise.
		* testsuite/gas/i386/x86-64-tlsdesc.d: Likewise.
		* testsuite/gas/i386/x86-64-tlsdesc.s: Likewise.

	include/

		* elf/x86-64.h (elf_x86_64_reloc_type): Add
		R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC

	ld/

		* testsuite/ld-x86-64/tlsbindesc.d: Updated.
		* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.
		* testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_4_GOTTPOFF
		and R_X86_64_CODE_4_GOTPC32_TLSDESC tests.

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	gold: Handle R_X86_64_CODE_4_GOTPCRELX
	Handle R_X86_64_CODE_4_GOTPCRELX and convert

		mov	name@GOTPCREL(%rip), %r31

	to

		lea	name@GOTPCREL(%rip), %r31

	if the instruction is encoded with the REX2 prefix when possible.

	elfcpp/

		* x86_64.h (R_X86_64_CODE_4_GOTPCRELX): New.

	gold/

		* x86_64.cc (Target_x86_64::can_convert_mov_to_lea): Handle
		R_X86_64_CODE_4_GOTPCRELX.
		(Target_x86_64::Scan::get_reference_flags): Likewise.
		(Target_x86_64::Scan::local): Likewise.
		(Target_x86_64::Scan::possible_function_pointer_reloc): Likewise.
		(Target_x86_64::Scan::global): Likewise.
		(Target_x86_64::Relocate::relocate): Likewise.
		* testsuite/x86_64_mov_to_lea1.s: Add a test for
		R_X86_64_CODE_4_GOTPCRELX.
		* testsuite/x86_64_mov_to_lea2.s: Likewise.
		* testsuite/x86_64_mov_to_lea3.s: Likewise.
		* testsuite/x86_64_mov_to_lea4.s: Likewise.
		* testsuite/x86_64_mov_to_lea5.s: Likewise.
		* testsuite/x86_64_mov_to_lea.sh: Updated.

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Add R_X86_64_CODE_4_GOTPCRELX
	For

		mov        name@GOTPCREL(%rip), %reg
		test       %reg, name@GOTPCREL(%rip)
		binop      name@GOTPCREL(%rip), %reg

	where binop is one of adc, add, add, cmp, or, sbb, sub, xor instructions,
	add

	 # define R_X86_64_CODE_4_GOTPCRELX  43

	if the instruction starts at 4 bytes before the relocation offset.  It
	similar to R_X86_64_GOTPCRELX.  Linker can treat R_X86_64_CODE_4_GOTPCRELX
	as R_X86_64_GOTPCREL or convert the above instructions to

		lea	name(%rip), %reg
		mov	$name, %reg
		test	$name, %reg
		binop	$name, %reg

	if the instruction is encoded with the REX2 prefix when possible.

	bfd/

		* elf64-x86-64.c (x86_64_elf_howto_table): Add
		R_X86_64_CODE_4_GOTPCRELX.
		(R_X86_64_standard): Updated.
		(x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
		(elf_x86_64_convert_load_reloc): Handle R_X86_64_CODE_4_GOTPCRELX.
		(elf_x86_64_scan_relocs): Likewise.
		(elf_x86_64_relocate_section): Likewise.
		* reloc.c (bfd_reloc_code_real): Add
		BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Likewise.

	gas/

		* write.h (fix): Add fx_tcbit3.  Change fx_unused to 1 bit.
		* config/tc-i386.c (tc_i386_fix_adjustable): Handle
		BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
		(tc_gen_reloc): Likewise.
		(output_disp): Set fixP->fx_tcbit3 for REX2 prefix.
		(i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTPCRELX
		if fixp->fx_tcbit3 is set.
		* config/tc-i386.h (TC_FORCE_RELOCATION_LOCAL): Add
		BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
		(TC_FORCE_RELOCATION_ABS): Likewise.
		* testsuite/gas/i386/x86-64-gotpcrel.s: Add tests for
		R_X86_64_CODE_4_GOTPCRELX.
		* testsuite/gas/i386/x86-64-localpic.s: Likewise.
		* testsuite/gas/i386/x86-64-gotpcrel.d: Updated.
		* testsuite/gas/i386/x86-64-localpic.d: Likewise.
		* testsuite/gas/i386/ilp32/x86-64-localpic.d: Likewise.

	include/

		* elf/x86-64.h (elf_x86_64_reloc_type): Add
		R_X86_64_CODE_4_GOTPCRELX.

	ld/

		* testsuite/ld-x86-64/apx-load1.s: New file.
		* testsuite/ld-x86-64/apx-load1a.d: Likewise.
		* testsuite/ld-x86-64/apx-load1b.d: Likewise.
		* testsuite/ld-x86-64/apx-load1c.d: Likewise.
		* testsuite/ld-x86-64/apx-load1d.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run apx-load1a, apx-load1b,
		apx-load1c and apx-load1d.

2023-12-28  H.J. Lu  <hjl.tools@gmail.com>

	gas: Mention initial support for Intel APX in NEWS

2023-12-28  Schimpe, Christina  <christina.schimpe@intel.com>

	x86: Add NT_X86_SHSTK note
	Define NT_X86_SHSTK which is the note for x86 Shadow Stack (SHSTK) to
	support Intel SHSTK in Linux kernel.
	For now only userspace shadow stack and kernel IBT are supported by the
	linux kernel.  This note should be used instead of NT_X86_CET introduced
	in the commit "x86: Add NT_X86_CET note", as it is outdated and only
	used by old binutils versions.

2023-12-28  Hu, Lin1  <lin1.hu@intel.com>

	Support APX JMPABS for disassembler
	gas/ChangeLog:

		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/x86-64-apx-jmpabs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-jmpabs-inval.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-apx-jmpabs.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-jmpabs.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (JMPABS_Fixup): New Fixup function to disassemble jmpabs.
		(print_insn): Add #UD exception for jmpabs.
		(dis386): Modify a1 unit for support jmpabs.
		* i386-mnem.h: Regenerated.
		* i386-opc.tbl: New insns.
		* i386-tbl.h: Regenerated.

2023-12-28  Hu, Lin1  <lin1.hu@intel.com>

	Support APX NDD optimized encoding.
	This patch aims to optimize:

	add %r16, %r15, %r15 -> add %r16, %r15

	gas/ChangeLog:

		* config/tc-i386.c (check_Rex_required): New function.
		(can_convert_NDD_to_legacy): Ditto.
		(match_template): If we can optimzie APX NDD insns, so rematch
		template.
		* testsuite/gas/i386/x86-64.exp: Add test.
		* testsuite/gas/i386/x86-64-apx-ndd-optimize.d: New test.
		* testsuite/gas/i386/x86-64-apx-ndd-optimize.s: Ditto.

2023-12-28  Cui, Lili  <lili.cui@intel.com>

	Support APX pushp/popp
	gas/ChangeLog:

		* config/tc-i386.c (process_operands): Handle "PUSHP/POPP requires
		rex2.w == 1."
		* testsuite/gas/i386/x86-64.exp: Add new test for PUSHP/POPP.
		* testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: New test.
		* testsuite/gas/i386/x86-64-apx-pushp-popp-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-apx-pushp-popp-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-apx-pushp-popp.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-pushp-popp.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (putop): print pushp and popp.
		* i386-opc.tbl: Added new insns.
		* i386-init.h : Regenerated.
		* i386-mnem.h : Regenerated.
		* i386-tbl.h: Regenerated.

2023-12-28  Mo, Zewei  <zewei.mo@intel.com>

	Support APX Push2/Pop2
	PPX functionality for PUSH/POP is not implemented in this patch
	and will be implemented separately.

	gas/ChangeLog:

	2023-12-28  Zewei Mo <zewei.mo@intel.com>
	            H.J. Lu  <hongjiu.lu@intel.com>
	            Lili Cui <lili.cui@intel.com>

		* config/tc-i386.c: (enum i386_error):
		New unsupported_rsp_register and invalid_src_register_set.
		(md_assemble): Add handler for unsupported_rsp_register and
		invalid_src_register_set.
		(check_APX_operands): Add invalid check for push2/pop2.
		(match_template): Handle check_APX_operands.
		* testsuite/gas/i386/i386.exp: Add apx-push2pop2 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/x86-64-apx-push2pop2.d: New test.
		* testsuite/gas/i386/x86-64-apx-push2pop2.s: Ditto.
		* testsuite/gas/i386/x86-64-apx-push2pop2-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-push2pop2-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-apx-push2pop2-inval.s: Ditto.
		* testsuite/gas/i386/apx-push2pop2-inval.s: Ditto.
		* testsuite/gas/i386/apx-push2pop2-inval.d: Ditto.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added bad
		testcases for POP2.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis-evex-reg.h: Add REG_EVEX_MAP4_8F.
		* i386-dis-evex-w.h: Add EVEX_W_MAP4_8F_R_0 and EVEX_W_MAP4_FF_R_6
		* i386-dis-evex.h: Add REG_EVEX_MAP4_8F.
		* i386-dis.c (PUSH2_POP2_Fixup): Add special handling for PUSH2/POP2.
		(get_valid_dis386): Add handler for vector length and address_mode for
		APX-Push2/Pop2 insn.
		(nd): define nd as b for EVEX-promoted instrutions.
		(OP_VEX): Add handler of 64-bit vvvv register for APX-Push2/Pop2 insn.
		* i386-gen.c: Add Push2Pop2 bitfield.
		* i386-opc.h: Regenerated.
		* i386-opc.tbl: Regenerated.

2023-12-28  konglin1  <lingling.kong@intel.com>

	Support APX NDD
	opcodes/ChangeLog:

		* opcodes/i386-dis-evex-reg.h: Handle for REG_EVEX_MAP4_80,
		REG_EVEX_MAP4_81, REG_EVEX_MAP4_83,  REG_EVEX_MAP4_F6,
		REG_EVEX_MAP4_F7, REG_EVEX_MAP4_FE, REG_EVEX_MAP4_FF.
		* opcodes/i386-dis-evex.h: Add NDD insn.
		* opcodes/i386-dis.c (nd): New define.
		(VexGb): Ditto.
		(VexGv): Ditto.
		(get_valid_dis386): Change for NDD decode.
		(print_insn): Ditto.
		(putop): Ditto.
		(intel_operand_size): Ditto.
		(OP_E_memory): Ditto.
		(OP_VEX): Ditto.
		* opcodes/i386-opc.h (VexVVVV_DST): New.
		* opcodes/i386-opc.tbl: Add APX NDD instructions and adjust VexVVVV.
		* opcodes/i386-tbl.h: Regenerated.

	gas/ChangeLog:

		* gas/config/tc-i386.c (operand_size_match):
		Support APX NDD that the number of operands is 3.
		(build_apx_evex_prefix): Change for ndd encode.
		(process_operands): Ditto.
		(build_modrm_byte): Ditto.
		(match_template): Support swap the first two operands for
		APX NDD.
		* testsuite/gas/i386/x86-64.exp: Add x86-64-apx-ndd.
		* testsuite/gas/i386/x86-64-apx-ndd.d: New test.
		* testsuite/gas/i386/x86-64-apx-ndd.s: Ditto.
		* testsuite/gas/i386/x86-64-pseudos.d: Add test.
		* testsuite/gas/i386/x86-64-pseudos.s: Ditto.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d : Ditto.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s : Ditto.

2023-12-28  Cui, Lili  <lili.cui@intel.com>

	Add tests for APX GPR32 with extend evex prefix
	gas/ChangeLog:

	2023-12-28 Lingling Kong <lingling.kong@intel.com>
		    H.J. Lu  <hongjiu.lu@intel.com>
		    Lili Cui <lili.cui@intel.com>
		    Lin Hu   <lin1.hu@intel.com>

		* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Add some insn don't
		support gpr32.
		* testsuite/gas/i386/x86-64-apx-egpr-inval.s: Ditto.
		* testsuite/gas/i386/x86-64.exp: Add new test.
		* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: New test.
		* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: New test.
		* testsuite/gas/i386/x86-64-apx-evex-egpr.d: New test.
		* testsuite/gas/i386/x86-64-apx-evex-egpr.s: New test.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: New test.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: New test.
		* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: New test.
		* testsuite/gas/i386/x86-64-apx-evex-promoted.d: New test.
		* testsuite/gas/i386/x86-64-apx-evex-promoted.s: New test.

2023-12-28  Cui, Lili  <lili.cui@intel.com>

	Support APX GPR32 with extend evex prefix
	This patch adds non-ND, non-NF forms of EVEX promotion insn.

	EVEX extension of legacy instructions:
	  All promoted legacy instructions are placed in EVEX map 4, which is
	  currently reserved.
	EVEX extension of EVEX instructions:
	  All existing EVEX instructions are extended by APX using the extended
	  EVEX prefix, so that they can access all 32 GPRs.
	EVEX extension of VEX instructions:
	  Promoting a VEX instruction into the EVEX space does not change the map
	  id, the opcode, or the operand encoding of the VEX instruction.

	Note: The promoted versions of MOVBE will be extended to include the “MOVBE
	  reg1, reg2”.

	  gas/ChangeLog:

	  2023-12-28  Lingling Kong <lingling.kong@intel.com>
		      H.J. Lu  <hongjiu.lu@intel.com>
		      Lili Cui <lili.cui@intel.com>
		      Lin Hu   <lin1.hu@intel.com>

		* config/tc-i386.c (struct _i386_insn): Add has_egpr.
		(need_evex_encoding): Adjusted for apx.
		(cpu_flags_match): Ditto.
		(install_template): Handled APX combines.
		(is_apx_evex_encoding): Test apx evex encoding.
		(build_apx_evex_prefix): Enabe APX evex prefix.
		(md_assemble): Handle apx with evex encoding.
		(process_suffix): Handle apx map4 prefix.
		(check_register): Assign i.vec_encoding for APX evex instructions.
		* testsuite/gas/i386/x86-64-evex.d: Adjust test cases.
		* testsuite/gas/i386/x86-64.exp: Adjust x86-64-inval-movbe.

	opcodes/ChangeLog:

		* i386-dis-evex-len.h: Handle EVEX_LEN_0F38F2, EVEX_LEN_0F38F3.
		* i386-dis-evex-prefix.h: Handle PREFIX_EVEX_0F38F2_L_0,
		PREFIX_EVEX_0F38F3_L_0, PREFIX_EVEX_MAP4_D8,
		PREFIX_EVEX_MAP4_DA, PREFIX_EVEX_MAP4_DB,
		PREFIX_EVEX_MAP4_DC, PREFIX_EVEX_MAP4_DD,
		PREFIX_EVEX_MAP4_DE, PREFIX_EVEX_MAP4_DF,
		PREFIX_EVEX_MAP4_F0, PREFIX_EVEX_MAP4_F1,
		PREFIX_EVEX_MAP4_F2, PREFIX_EVEX_MAP4_F8.
		* i386-dis-evex-reg.h: Handle REG_EVEX_0F38F3_L_0_P_0.
		* i386-dis-evex.h: Add EVEX_MAP4_ for legacy insn
		promote to apx to use gpr32
		* opcodes/i386-dis-evex-x86-64.h: Handle Add X86_64_EVEX_0F90,
		X86_64_EVEX_0F92, X86_64_EVEX_0F93, X86_64_EVEX_0F38F2,
		X86_64_EVEX_0F38F3, X86_64_EVEX_0F38F5, X86_64_EVEX_0F38F6,
		X86_64_EVEX_0F38F7, X86_64_EVEX_0F3AF0, X86_64_EVEX_0F91.
		* i386-dis.c
		(struct instr_info): Deleted bool r.
		(PREFIX_NP_OR_DATA): New.
		(NO_PREFIX): New.
		(putop): Ditto.
		(X86_64_EVEX_FROM_VEX_TABLE): Diito.
		(get_valid_dis386): Decode insn erex in extend evex prefix.
		Handle EVEX_MAP4
		(print_insn): Handle PREFIX_DATA_AND_NP_ONLY.
		(print_register): Handle apx instructions decode.
		(OP_E_memory): Diito.
		(OP_G): Diito.
		(OP_XMM): Diito.
		(DistinctDest_Fixup): Diito.
		* i386-gen.c (process_i386_opcode_modifier): Add EVEXMAP4.
		* i386-opc.h (SPACE_EVEXMAP4): Add legacy insn
		promote to evex.
		* i386-opc.tbl: Handle some legacy and vex insns don't
		support gpr32. And add some legacy insn (map2 / 3) promote
		to evex.

2023-12-28  Cui, Lili  <lili.cui@intel.com>

	Created an empty EVEX_MAP4_ sub-table for EVEX instructions.
	opcode/ChangeLog:

		* i386-dis-evex.hi: Added an empty EVEX_MAP4_ sub-table for
		legacy insn promote to EVEX insn.
		* opcodes/i386-dis-evex.h: Add EVEX_MAP4.

2023-12-28  Cui, Lili  <lili.cui@intel.com>

	Support APX GPR32 with rex2 prefix
	APX uses the REX2 prefix to support EGPR for map0 and map1 of legacy
	instructions. We added the NoEgpr flag in i386-gen.c for instructions
	that do not support EGPR.

	gas/ChangeLog:

	2023-12-28  Lingling Kong <lingling.kong@intel.com>
		    H.J. Lu  <hongjiu.lu@intel.com>
		    Lili Cui <lili.cui@intel.com>
		    Lin Hu   <lin1.hu@intel.com>

		* config/tc-i386.c
		(enum i386_error): Add unsupported_EGPR_for_addressing
		and invalid_pseudo_prefix.
		(struct _i386_insn): Add rex2 and rex2_encoding for
		gpr32.
		(cpu_arch): Add apx_f.
		(is_cpu): Ditto.
		(register_number): Handle RegRex2 for gpr32.
		(is_apx_rex2_encoding): New func. Test rex2 prefix encoding.
		(build_rex2_prefix): New func. Build legacy insn in
		opcode 0/1 use gpr32 with rex2 prefix.
		(establish_rex): Handle rex2 and rex2_encoding.
		(optimize_encoding): Handel add r16-r31 for registers.
		(md_assemble): Handle apx encoding.
		(parse_insn): Handle Prefix_REX2.
		(check_EgprOperands): New func. Check if Egprs operands
		are valid for the instruction
		(match_template):  Handle Egpr operands check.
		(set_rex_rex2):  New func. set i.rex and i.rex2.
		(build_modrm_byte): Ditto.
		(output_insn): Handle rex2 2-byte prefix output.
		(check_register): Handle check egpr illegal without
		target apx, 64-bit mode and with rex_prefix.
		* doc/c-i386.texi: Document .apx.
		* testsuite/gas/i386/ilp32/x86-64-opcode-inval-intel.d: D5 valid
		in 64-bit mode.
		* testsuite/gas/i386/ilp32/x86-64-opcode-inval.d: Ditto.
		* testsuite/gas/i386/rex-bad: Adjust rex testcase.
		* testsuite/gas/i386/x86-64-opcode-inval-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-opcode-inval.d: Ditto.
		* testsuite/gas/i386/x86-64-opcode-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-pseudos-bad.l: Add illegal rex2 test.
		* testsuite/gas/i386/x86-64-pseudos-bad.s: Ditto.
		* testsuite/gas/i386/x86-64-pseudos.d: Add rex2 test.
		* testsuite/gas/i386/x86-64-pseudos.s: Ditto.
		* testsuite/gas/i386/x86-64.exp: Run APX tests.
		* testsuite/gas/i386/x86-64-apx-egpr-inval.l: New test.
		* testsuite/gas/i386/x86-64-apx-egpr-inval.s: New test.
		* testsuite/gas/i386/x86-64-apx-rex2.d: New test.
		* testsuite/gas/i386/x86-64-apx-rex2.s: New test.

	include/ChangeLog:

		* opcode/i386.h (REX2_OPCODE): New.
		(REX2_M): Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (struct instr_info): Add erex for gpr32.
		Add last_erex_prefix for rex2 prefix.
		(REX2_M): Extend for gpr32.
		(PREFIX_REX2): Ditto.
		(PREFIX_REX2_ILLEGAL): Ditto.
		(ckprefix): Ditto.
		(prefix_name): Ditto.
		(print_insn): Ditto.
		(print_register): Ditto.
		(OP_E_memory): Ditto.
		(OP_REG): Ditto.
		(OP_EX): Ditto.
		* i386-gen.c (rex2_disallowed): Some instructions are not allowed rex2 prefix.
		(process_i386_opcode_modifier): Set NoEgpr for VEX and some special instructions.
		(output_i386_opcode): Handle if_entry_needs_special_handle.
		* i386-init.h : Regenerated.
		* i386-mnem.h : Regenerated.
		* i386-opc.h (enum i386_cpu): Add CpuAPX_F.
		(NoEgpr): New.
		(Prefix_NoOptimize): Ditto.
		(Prefix_REX2): Ditto.
		(RegRex2): Ditto.
		* i386-opc.tbl: Add rex2 prefix.
		* i386-reg.tbl: Add egprs (r16-r31).
		* i386-tbl.h: Regenerated.

2023-12-28  Dimitar Dimitrov  <dimitar@dinux.eu>

	sim: pru: Fix emulation of carry bit
	The PRU architecture documentation [1] was used for the initial GNU
	simulator implementation.  But recently [2] TI confirmed the carry
	behaviour was wrongly documented.  In reality, the PRU carry behaves
	like the carry in ARM processors.

	This patch fixes simulator to align with latest recommendations from TI.

	The new carry.s test was also validated to pass on real hardware -
	a BeaglePlay board [3].  That test is a bit long because TI still
	has not released official updates for the PRU documents.  And I wanted
	to ensure simulator handles all edge cases exactly as the real hardware
	does.

	[1] https://www.ti.com/lit/pdf/spruij2
	[2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1244359/sk-am64b-am64x-pru-assembler-how-works-this-bloody-carry
	[3] https://www.beagleboard.org/boards/beagleplay

2023-12-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: PR31179, The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
	* Problematic fix commit,
	2029e13917d53d2289d3ebb390c4f40bd2112d21
	RISC-V: Clarify the behaviors of SET/ADD/SUB relocations

	* Bugzilla,
	https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5

	The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it
	non-zero by accident in assembler before.  This causes troubles by applying
	the above commit, since the calculation is changed to support .reloc *SUB*
	relocations with non-zero addend.

	We encourage people to rebuild their stuff to get the non-zero addend of
	SUB_ULEB128, but that might need some times, so report warnings to inform
	people need to rebuild their stuff if --check-uleb128 is enabled.

	Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use,
	it may acceptable that stop supproting them until people rebuld their stuff,
	maybe half-year or a year later.  Or maybe we should teach people that don't
	write the .reloc R_RISCV_SUB* with non-zero constant, and then report
	warnings/errors in assembler.

	bfd/
		* elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of
		R_RISCV_SUB_ULEB128.
		(riscv_elf_relocate_section): Report warnings to inform people need
		to rebuild their stuff if --check-uleb128 is enabled.  So that can
		get the right non-zero addend of R_RISCV_SUB_ULEB128.
		* elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128.
	ld/
		* NEWS: Updated.
		* emultempl/riscvelf.em: Added linker risc-v target options,
		--[no-]check-uleb128, to enable/disable checking if the addend of
		uleb128 is non-zero or not.  So that people will know they need to
		rebuild the objects with binutils 2.42 and up, to get the right zero
		addend of SUB_ULEB128 relocation, or they may get troubles if using
		.reloc.
		* ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
		* ld/testsuite/ld-riscv-elf/pr31179*: New test cases.

2023-12-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-27  Alan Modra  <amodra@gmail.com>

	asan: buffer overflow in loongarch_elf_rtype_to_howto
	Seen when running ld-loongarch-elf/tlsdesc-dso test.
	elfxx-loongarch.c:1844:32: runtime error: index 125 out of bounds for
	type 'loongarch_reloc_howto_type [124]'

	So either the loongarch_howto_table needs three more
	LOONGARCH_EMPTY_HOWTO entries, or loongarch_elf_rtype_to_howto should
	be testing for r_type < ARRAY_SIZE (loongarch_howto_table).  I figure
	it's worth wasting a little more space to get faster lookup.

		* elfxx-loongarch.c (loongarch_howto_table): Add
		LOONGARCH_EMPTY_HOWTO entries for 121..123.
		(loongarch_elf_rtype_to_howto): Don't support slow lookup.
		Assert exact table size and r_type indexing.  Omit return cast.
		(loongarch_reloc_name_lookup): Omit assertion and return cast.
		(loongarch_reloc_type_lookup): Likewise.

2023-12-27  Alan Modra  <amodra@gmail.com>

	PR31191, objcopy leaves temporary files
	Fix the ENOTDIR rmdir too.

		PR 31191
		* objcopy.c (copy_archive): Localise uses of "l".  Remove
		const from name_list.name.  Unlink output element on bfd_close
		error, and NULL list->name to indicate file is removed.  Adjust
		cleanup to prevent rmdir on non-existent file.

2023-12-27  Mike Frysinger  <vapier@gentoo.org>

	sim: common: pull in newlib extensions for Linux compatibility
	Since newlib allows people to opt-in to extra errno names, pull them
	into our table too.  The values don't conflict with each other -- the
	newlib names & values are distinct from newlib's Linux compatibility.

2023-12-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-25  Mike Frysinger  <vapier@gentoo.org>

	binutils: SECURITY: use https URI

2023-12-25  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Add testsuit for DESC and tls transition and tls relaxation.

2023-12-25  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add support for TLS LD/GD/DESC relaxation
	The pcalau12i + addi.d of TLS LD/GD/DESC relax to pcaddi.
	Relaxation is only performed when the TLS model transition is not possible.

2023-12-25  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: Add tls transition support.
	Transitions between DESC->IE/LE and IE->LE are supported now.
	1. For DESC -> LE:
	   pcalau12i  $a0,%desc_pc_hi20(var)     =>  lu12i.w $a0,%le_hi20(var)
	   addi.d     $a0,$a0,%desc_pc_lo12(var) =>  ori $a0,$a0,%le_lo12(var)
	   ld.d       $a1,$a0,%desc_ld(var)      =>  NOP
	   jirl       $ra,$a1,%desc_call(var)	 =>  NOP
	   add.d      $a0,$a0,$tp
	2. For DESC -> IE:
	   pcalau12i  $a0,%desc_pc_hi20(var)     =>  pcalau12i $a0,%ie_pc_hi20(var)
	   addi.d     $a0,$a0,%desc_pc_lo12(var) =>  ld.d $a0,$a0,%ie_pc_lo12(var)
	   ld.d       $a1,$a0,%desc_ld(var)      =>  NOP
	   jirl       $ra,$a1,%desc_call(var)	 =>  NOP
	   add.d      $a0,$a0,$tp
	3. For IE -> LE:
	   pcalau12i  $a0,%ie_pc_hi20(var)       =>  lu12i.w $a0,%le_hi20(var)
	   ld.d       $a0,$a0,%ie_pc_lo12(var)   =>  ori $a0,$a0,%le_lo12(var)
	   add.d      $a0,$a0,$tp
	4. When a tls variable is accessed using both DESC and IE, DESC transitions
	   to IE and uses the same GOT entry as IE.

	LoongArch: Add support for TLSDESC in ld.
	1.The linker for each DESC generates a R_LARCH_TLS_DESC64 dynamic
	  relocation, which relocation is placed at .rela.dyn.
	  TLSDESC always allocates two GOT slots and one dynamic relocation
	  space to TLSDESC.
	2. When using multiple ways to access the same TLS variable, a
	   maximum of 5 GOT slots are used. For example, using GD, TLSDESC,
	   and IE to access the same TLS variable, GD always uses the first
	   two of the five GOT, TLSDESC uses the third and fourth, and IE
	   uses the last.

	LoongArch: Add new relocs and macro for TLSDESC.
	The normal DESC instruction sequence is:
	  pcalau12i  $a0,%desc_pc_hi20(var)     #R_LARCH_TLS_DESC_PC_HI20
	  addi.d     $a0,$a0,%desc_pc_lo12(var) #R_LARCH_TLS_DESC_PC_LO12
	  ld.d       $ra,$a0,%desc_ld(var)	#R_LARCH_TLS_DESC_LD
	  jirl       $ra,$ra,%desc_call(var)	#R_LARCH_TLS_DESC_CALL
	  add.d	     $a0,$a0,$tp

2023-12-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-24  Alan Modra  <amodra@gmail.com>

	Re: LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1">
	This fixes the buffer overflow added in commit 22b78fad28, and a few
	other problems.

		* loongarch-coder.c (loongarch_split_args_by_comma): Don't
		overflow buffer when args == "".  Don't remove unbalanced
		quotes.  Don't trim last arg if max number of args exceeded.

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make value::allocate_register_lazy store id of next non-inline frame
	Some spots loop on the frame chain to find the first next non-inline
	frame, and pass that as the "next frame" to
	value::allocate_register_lazy / value::allocate_register.  This is
	necessary if the value is used in the process of computing the id of
	"this frame".  If the frame next to "this frame" is inlined into "this
	frame", then you that next frame won't have a computed id yet.  You have
	to go past that to find the next non-inline frame, which will have a
	computed id.

	In other cases, it's fine to store the id of an inline frame as the
	"next frame id" in a register struct value.  When trying to unwind a
	register from it, it will just call inline_frame_prev_register, which
	will forward the request to the next next frame, until we hit the next
	physical frame.

	I think it would make things simpler to just never store the id of an
	inline frame as the next frame id of register struct values, and go with
	the first next non-inline frame directly.  This way, we don't have to
	wonder which code paths have to skip inline frames when creating
	register values and which don't.

	So, change value::allocate_register_lazy to do that work, and remove the
	loops for the callers that did it.

	Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310

2023-12-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove VALUE_REGNUM, add value::regnum
	Remove VALUE_REGNUM, replace it with a method on struct value.  Set
	`m_location.reg.regnum` directly from value::allocate_register_lazy,
	which is fine because allocate_register_lazy is a static creation
	function for struct value.

	Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove VALUE_NEXT_FRAME_ID, add value::next_frame_id
	Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value.  Set
	`m_location.reg.next_frame_id` directly from value::allocate_register_lazy,
	which is fine because allocate_register_lazy is a static creation
	function for struct value.

	Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: implement address_from_register using value_from_register
	As explained in the comment removed by the previous commit "gdb: pass
	non-nullptr frame to gdbarch_value_from_register in
	address_from_register", address_from_register copies some implementation
	bits from value_from_register:

	   /* This routine may be called during early unwinding, at a time
	      where the ID of FRAME is not yet known.  Calling value_from_register
	      would therefore abort in get_frame_id.  However, since we only need
	      a temporary value that is never used as lvalue, we actually do not
	      really need to set its VALUE_NEXT_FRAME_ID.  Therefore, we re-implement
	      the core of value_from_register, but use the null_frame_id.  */

	This is no longer relevant, since we now create a value with a valid next
	frame id, so change address_from_register to use value_from_register.

	Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove read_frame_register_value's frame parameter
	By now, all register struct values should have a valid next frame id
	(assuming they are created using value::allocate_register or
	value::allocate_register_lazy), so there should be no need to pass a
	frame alongside the value to read_frame_register_value.  Remove the
	frame parameter and adjust read_frame_register_value accordingly.

	While at it, make read_frame_register_value static, it's only used in
	findvar.c.

	Change-Id: I118959ef8c628499297c67810916e8ba9934bfac

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add type parameter to value::allocate_register and add value::allocate_register_lazy
	Some places that create register struct values don't use register_type
	to obtain the value type.  This prevents them from using the current
	version of value::allocate_register.  One spot (value_of_register_lazy)
	also creates a lazy register value.

	Add a value::allocate_register_lazy method.  Add some type parameters
	to value::allocate_register and value::allocate_register_lazy, to let
	the caller specify the type to use for the value.  The parameters
	default to nullptr, in which case we use register_type to obtain the
	type.

	Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register
	address_from_register used to pass null_frame_id to
	gdbarch_value_from_register as "this frame"'s id, because it's possible
	for it to be called during unwind, when "this frame"'s id is not yet
	known.  This create an oddity where those register struct values are
	created without a valid next frame id.  I would much prefer for things
	to be consistent and have all register struct values to have a valid
	next frame id.

	Since gdbarch_value_from_register takes a frame_info_ptr now, rather
	than a frame_id, we can pass down "this frame", even if it doesn't have
	a valid id.  gdbarch_value_from_register implementations can obtain the
	next frame from it.

	However, it's possible for the "this frame"'s next frame to be an
	inline frame, inlined in "this frame", in which case that next frame's
	id is also not known.  So, loop until we get to the next non-inline
	frame (which is actually the frame where registers for "this frame" are
	unwound from).  This is the same thing that we do in
	value_of_register_lazy, for the same reason.  A later patch will factor
	out this "while next frame is inline" loop to apply it to all register
	struct values, so this is somewhat temporary.

	Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass frame_info_ptr to gdbarch_value_from_register
	Pass a frame_info_ptr rather than a frame_id.  This avoids having to do
	a frame lookup on the callee side, when we can just pass the frame down
	directly.

	I think this fixes a bug in rs6000-tdep.c where the id of the wrong
	frame was set to `VALUE_NEXT_FRAME_ID (v)`.

	Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565

2023-12-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't set frame id after calling cooked_read_value
	I don't think that setting the next frame id is needed there, all code
	paths in cooked_read_value do set it properly, AFAIK.

	Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d

2023-12-24  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: rvdummy: delete unused variable

2023-12-24  Mike Frysinger  <vapier@gentoo.org>

	sim: cgen: mark cgen_rtx_error noreturn
	Since this function never returns, mark it as such to fix some unused
	variable warnings in error code paths.

	For example, cris triggers:
	sim/cris/semcrisv10f-switch.c:3558:11: error:
		variable 'tmp_newval' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]

	Even though it has an "else" path that calls this error function.

2023-12-24  Mike Frysinger  <vapier@gentoo.org>

	sim: cgen: regenerate decode tables
	Integrate some changes from upstream cgen that tightened up the
	generated output.  Shouldn't be any functional changes here.

	sim: sh: refine pwsb & pwad nops
	Since these insns don't do anything and are effectively ignored,
	return early to avoid doing any common processing at the end as
	that requires initializing variables like "res" with something.

	sim: sh: fix plds Dz,MACL implementation
	The plds Dz,MACL insn stores the Dz bit into MACL.  The current code
	was storing the "res" variable into Dz and then into MACL, but not
	setting "res" to anything.  Delete that logic and make it match the
	existing plds Dz,MACH insn.

2023-12-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-23  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: rework individual flag disable into dedicated vars
	The -Wshadow=local is too new for some compilers, so move it to a var
	that we test at configure time.

2023-12-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix build problems on linux-musl
	ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl.
	Fixed by declaring these types for linux-musl.

	2023-12-21  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30779
		PR gprofng/29593
		* common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl.
		* libcollector/unwind.c: Define __u64 for linux-musl.
		* src/util.h: Define dbe_stat_t.
		* src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64".
		* src/Dbe.cc: Likewise.
		* src/DbeFile.cc: Likewise.
		* src/DbeFile.h: Likewise.
		* src/DbeSession.cc: Likewise.
		* src/Experiment.cc: Likewise.
		* src/checks.cc: Likewise.
		* src/util.cc: Likewise.

2023-12-23  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: fix -Wshadow=local warnings
	Rename the var to avoid shadowing & clobbering the higher context.

	sim: riscv: fix -Wshadow=local warnings
	Inline the one usage of sd in these macros to avoid possible shadowing.

	sim: ppc: fix -Wshadow=local warnings
	Use a local name in the macro to avoid shadowing wherever it's used.

	sim: mips: fix -Wshadow=local warnings
	Delete redundant decls when the existing scope has the same var and
	type available for use.

	sim: m68hc11: fix -Wshadow=local warnings
	Delete redundant decls when the existing scope has the same var and
	type available for use.

	sim: m32c: fix -Wshadow=local warnings
	These decoders declare a lot of common variables for use by substeps,
	and then shadows a few because of how the opc generator is implemented.
	Easiest way around it is to rename the per-substep vars as needed as
	anything more would require substantial changes to the opc logic.

	sim: iq2000: fix -Wshadow=local warnings
	Delete redundant decls.

	sim: h8300: fix -Wshadow=local warnings
	Delete conflicting decls when the existing scope has vars of the same
	name & type for this exact use.

	sim: frv: fix -Wshadow=local warnings
	Delete redundant decls, and rename conflicting vars.

	sim: erc32: fix -Wshadow=local warnings
	Rename shadowed vars with different types to avoid confusion.

2023-12-23  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: disable -Wshadow=local in generated mloop files
	The mloop files include CGEN generated switch files which have some
	nested assignments that expand into repeated shadowed variables.
	Fixing this looks fairly non-trivial as it appears to be interplay
	between the common CGEN code and how this particular set of cris
	insns are defined.  Disable the warning instead.

	In file included from sim/cris/mloop.in:286:
	sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’:
	sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local]
	12383 |     SI opval = tmp_addr;
	      |        ^~~~~
	sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here
	12371 |     USI opval = ({   SI tmp_addr;
	      |         ^~~~~

	And the code looks like:
		USI opval = ({
			...
				{
					SI opval = tmp_addr;
					...
				}
			...
		});

	Since the CGEN code treats "opval" as an internal variable that the cpu
	definitions don't have direct access to, the likelihood of this being a
	real bug is low, so leave it be.  The warning is suppressed for more code
	that is hand written (e.g. the mloop logic), but disabling for the entire
	file is the easiest way to suppress while keeping it on everywhere else in
	the sim.

2023-12-23  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: fix -Wshadow=local warnings
	Delete redundant local decls.

	sim: common: fix -Wshadow=local warnings
	Rename shadowed vars with different types, and delete redundant decls.

	sim: bfin: fix -Wshadow=local warnings
	Rename the shadowed var to avoid confusion with the function argument
	as to which address this code is using.

	sim: arm: fix -Wshadow=local warnings
	Remove duplicate nested variable declarations, rename some to avoid
	confusion when the type is different or the original value should be
	retained, and fix some weirdness with nested enums in structs.

	sim: aarch64: fix -Wshadow=local warnings
	These functions have local vars named "val" of type float, and
	then create nested vars named "val" of type double.  This is a
	bit confusing and causes build time warnings.

2023-12-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Check for rogue DAP exceptions in test suite
	This changes the test suite to look for rogue DAP exceptions in the
	log file, and issue a "fail" if one is found.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Avoid exception from attach in DAP
	I noticed that the DAP attach test case (and similarly
	remoted-dap.exp) had a rogue exception stack trace in the log.  It
	turns out that an attach will generate a stop that does not have a
	reason.

	This patch fixes the problem in the _on_stop event listener by making
	it a bit more careful when examining the event reason.  It also adds
	some machinery so that attach stops can be suppressed, which I think
	is the right thing to do.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Add DAP log level parameter
	This adds a new parameter to control the DAP logging level.  By
	default, "expected" exceptions are not logged, but the parameter lets
	the user change this when more logging is desired.

	This also changes a couple of spots to avoid logging the stack trace
	for a DAPException.

	This patch also documents the existing DAP logging parameter.  I
	forgot to document this before.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Introduce and use DAPException
	This introduces a new DAPException class, and then changes various
	spots in the DAP implementation to wrap "expected" exceptions in this.
	This class will help detect rogue exceptions caused by bugs in the
	implementation.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Fix build with clang 16
	clang 16 reports a missing declaration in new-op.cc.  We believed
	these operators to be declared starting with C++14, but apparently
	that is not the case.

	This patch reverts the earlier change and then updates the comment to
	reflect the current state.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31141

2023-12-22  Kévin Le Gouguec  <legouguec@adacore.com>

	gdb: fix refactoring hiccup in rs6000_register_to_value
	In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame"
	(9fc79b42369), *_register_to_value functions were made to (a) call
	get_next_frame_sentinel_okay (frame) (b) pass that next frame to
	get_frame_register_bytes.

	Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on
	PPC platforms for e.g. O2_float_param: instead of seeing…

	  Temporary breakpoint 1, callee.increment (val=val@entry=99.0, msg=...) at callee.adb:19

	… we get "optimized_out" for val.  Passing next_frame to
	get_frame_register_bytes fixes the issue.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-12-22  Tom Tromey  <tromey@adacore.com>

	Add 'program' to DAP 'attach' request
	In many cases, it's not possible for gdb to discover the executable
	when a DAP 'attach' request is used.  This patch lets the IDE supply
	this information.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-12-22  Mike Frysinger  <vapier@gentoo.org>

	sim: cgen: regenerate decode tables to avoid shadow warnings
	Use latest cgen to regenerate the decode tables which has some shadow
	warning fixes with "val" variables.

	sim: cris: regen cgen decoders to fix build warnings [PR sim/31181]
	Bug: https://sourceware.org/PR31181

2023-12-22  Guinevere Larsen  <blarsen@redhat.com>

	gdb: add git trailer information on gdb/MAINTAINERS
	The project has been using Tested-By (tb), Reviewed-By (rb) and
	Approved-By (ab) for some time, but there has been no information to be
	found in the actual repository. This commit changes that by adding
	information about all git trailers to the MAINTAINERS file, so that it
	can be easily double-checked. Simply put, the trailers in use work as
	follows:

	* Tested-by: The person tested the patch and it fixes the problem, or
	  introduces no regressions (or both).
	* Acked-by: The general outline looks good, but the maintainer hasn't
	  looked at the code
	* Reviewed-by: The code looks good, but the reviewer has not approved
	  the patch to go upstream
	* Approved-by: The patch is ready to be pushed to master

	These last 3 trailers can also be restricted to one or more areas of GDB
	by adding the areas in a comma separated list in parenthesis after the
	trailers.

	Finally, for completeness sake, the trailers Co-Authored-By and Bug
	were added, even though they have been in use for a long time already

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>
	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: John Baldwin <jhb@FreeBSD.org>

2023-12-22  Jan Beulich  <jbeulich@suse.com>

	nios2: fix .text/.data interaction with .previous
	Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
	need calling for .text/.data.

2023-12-22  Jan Beulich  <jbeulich@suse.com>

	hppa/ELF: fix .text/.data interaction with .previous
	For some ELF targets .text/.data are overridden. In that case
	obj_elf_{text,data}() need calling, just like .code vectors to that
	function for the remaining ELF targets.

	While there also hand on the function arguments, even if right now
	they're meaningless. This matches what other targets' code does.

2023-12-22  Jan Beulich  <jbeulich@suse.com>

	RISC-V: drop .bss override
	It doesn't look to be a good idea to override the custom handler that
	ELF has; afaict doing so broke .previous, and a sub-section specifier
	wasn't accepted either.

2023-12-22  Jan Beulich  <jbeulich@suse.com>

	x86-64: refuse "high" 8-bit regs with .insn and VEX/XOP/EVEX encodings
	Much like REX, those encodings - if permitting 8-bit regs at all, i.e.
	only starting with APX - permit use of "new" 8-bit registers only. %ah,
	%ch, %dh, and %bh cannot be encoded and hence should be rejected.

	Permit their use outside of 64-bit code though, as "new" registers
	simply don't exist there.

2023-12-22  Jan Beulich  <jbeulich@suse.com>

	x86: properly respect rex/{rex}
	This addresses two issues: For one, a user specified "rex" did not cause
	the diagnostic to trigger when there was no other need for a REX prefix;
	instead, another than the specified insn+operands was encoded. And then
	(which is what this started from) .insn didn't respect {rex} (and was
	otherwise similarly flawed as ordinary insns).

	The latter requires splitting out code from md_assemble(), for it to
	become re-usable. Besides the addition to address the first issue, that
	code then also needs generalizing to account for immediate operands, as
	with .insn we can't make assumptions anymore on all respective templates
	having at most two operands (we still can build upon there being at most
	two non-immediate operands, though). While moving the code also simplify
	the first if(), by folding redundant checks.

	In the new testcase also test a few more things which afaics weren't
	tested till now.

2023-12-22  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add support for the third expression of .align for R_LARCH_ALIGN
	If the symbol index is not zero, the addend is used to represent
	the first and the third expressions of the .align.

	The lowest 8 bits are used to represent the first expression.
	Other bits are used to represent the third expression.

	The addend of R_LARCH_ALIGN for ".align 5, ,4" is 0x405.
	The addend of R_LARCH_ALIGN for ".balign 32, ,4" is 0x405.

2023-12-22  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: igen: fix -G handling
	We weren't using the enable_p flag to see whether the option should
	be enabled or disabled, and we weren't breaking out when done parsing.

	sim: warnings: enable -Wreturn-type
	Older versions of gcc support this warning flag.  We're already clean.

	sim: warnings: fix -Wreturn-mismatch typo

	sim: m32c: fix initial #line number in generated code
	This emits #line 2 for the first line in the output when it should be 1.

	sim: mloop: add #line pragmas everywhere
	This will make compiler diagnostics much better with generated code
	so people can understand the original source file.

2023-12-22  Mike Frysinger  <vapier@gentoo.org>

	sim: common: add $LINENO rewriting support to genmloop scripts
	The generated mloop files can trigger compile time warnings.  It can
	be difficult to see/understand where the original code is coming from
	as all the diagnostics point to the generated output.  Using #line
	pragmas, we can point people to the original source files.

	Unfortunately, this code is written in POSIX shell, and that lacks
	support for line number tracking.  The $LINENO variable, even when
	available, can just be plain wrong.  For example, when using dash
	and subshells, $LINENO can end up having negative values.  Add a
	wrapper script that will uses awk to rewrite the $LINENO variable
	to the right value to avoid all that.

	Basically lineno.sh takes an input script, rewrites all uses of
	$LINENO into the actual line number (and $0 into the original file
	name), and then executes the temporary script.

	This commit doesn't actually add #line pragmas to any files.  That
	comes next.

2023-12-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-21  Tom Tromey  <tom@tromey.com>

	Rename TUI locator window -> status
	The TUI status window is called the "locator" in the source, but
	"status" in the documentation.  Whenever I've needed to find the code,
	I've had to search to "locate" it (ha, ha).  This patch renames the
	window to match the public name of the window.

	Rename tui-stack -> tui-status
	The TUI status line is called the "status" window in the
	documentation, but not in the source.  There, the relevant files are
	named "tui-stack", which to me makes it sound like they have something
	to do with backtraces.  This patch renames them to "tui-status".

2023-12-21  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64
	GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when
	the linked libraries have dependencies on shared objects themselves:

	$ gcc -m32 -o ei ei.c -lexecinfo
	/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
	warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found
	(try using -rpath or -rpath-link)
	/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
	/usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0'
	[...]

	Fixed by handling FreeBSD/amd64 like Linux/x86.

	Tested on amd64-pc-freebsd14.0.

2023-12-21  Pedro Alves  <pedro@palves.net>

	Fix Clang build issue with flexible array member and non-trivial dtor
	Commit d5cebea18e7a ("Make cached_reg_t own its data") added a
	destructor to cached_reg_t.

	That caused a build problem with Clang, which errors out like so:

	 > CXX    python/py-unwind.o
	 > gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction
	 >   126 |   cached_reg_t reg[];
	 >       |                ^

	This is is not really a problem for our code, which allocates the
	whole structure with xmalloc, and then initializes the array elements
	with in-place new, and then takes care to call the destructor
	manually.  Like, commit d5cebea18e7a did:

	 @@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache)
	    cached_frame_info *cached_frame = (cached_frame_info *) cache;

	    for (int i = 0; i < cached_frame->reg_count; i++)
	 -    xfree (cached_frame->reg[i].data);
	 +    cached_frame->reg[i].~cached_reg_t ();

	Maybe we should get rid of the flexible array member and use a bog
	standard std::vector.  I doubt this would cause any visible
	performance issue.

	Meanwhile, to unbreak the build, this commit switches from C99-style
	flexible array member to 0-length array.  It behaves the same, and
	Clang doesn't complain.  I got the idea from here:

	  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11

	GCC 9, our oldest support version, already supported this:

	  https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html

	but the extension is actually much older than that.  Note that
	C99-style flexible array members are not standard C++ either.

	Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce

2023-12-21  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: enable -Wimplicit-fallthrough=5
	It caught some legitimate bugs, so clearly it's helpful.

	sim: sh: fix -Wimplicit-fallthrough warnings
	These generate conditional insns where it tests, then fallsthru.

	sim: rx: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: rl78: fix -Wimplicit-fallthrough warnings
	Seems like this code was meant to fallthru.

	sim: riscv: fix -Wimplicit-fallthrough warnings

	sim: ppc: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: or1k: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: mips: fix -Wimplicit-fallthrough warnings
	Seems like these cases were meant to fallthru.

	sim: mcore: fix Wimplicit-fallthrough warnings
	Seems like these decodes were intended to fallthru.

	sim: m68hc11: fix -Wimplicit-fallthrough warnings
	Seems like these register operations intended on falling thru.

	sim: frv: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: erc32: fix -Wimplicit-fallthrough warnings
	Add the attribute where it seems to make sense.

	sim: cris: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: bfin: fix -Wimplicit-fallthrough warnings
	Add the attribute to places where we want to fall thru.

	sim: avr: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: arm: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: aarch64: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute, and add some
	default abort calls when the compiler can't figure out that the set
	of values were already fully enumerated in the switch statement.

	sim: common: fix -Wimplicit-fallthrough warnings
	Replace some fall through comments with the attribute.

	sim: add ATTRIBUTE_FALLTHROUGH for local code
	We'll replace various /* fall through */ comments so compilers can
	actually understand what the code is doing.

	sim: signal: mark signal callback funcs as noreturn since they don't return
	All funcs already call other funcs that don't return.  The mips port is
	the only exception because its generic exception handler can return in
	the case of normal exceptions.  So while the exceptions its signal handler
	triggers doesn't return, we can't express that conditional logic.  So add
	some useless abort calls to make the compiler happy.

	sim: sh: add missing breaks to bit processing
	Doesn't seem like we want to cascade in this section when bit processing.

	sim: rx: mark abort func as noreturn since it doesn't

	sim: rx: add missing break to memory write
	It doesn't seem like we want to keep executing the next block of code
	after processing the request.

	sim: iq2000: add fallback for exit syscall
	Make sure this syscall always exits regardless of the exit code.

	sim: cr16: add missing break statement
	Doesn't seem to make sense for this to fall through
	(although I'm not an expert in this ISA).

	sim: arm: add missing breaks to SWI processing
	Seems unlikely we want the remove syscall to fallthrough into the
	rename syscall since we can't rename files that have been removed.

	sim: common: mark engine restart as noreturn
	This helps the compiler with optimization and fixes fallthru warnings.

	sim: ppc: phb: add missing break to address decoder
	I don't know what this emulation does exactly, but it missing a break
	statement seems kind of obvious based on the 32-bit case above it.

	sim: ppc: mark halt & restart funcs as noreturn
	This helps the compiler with optimization and fixes fallthru warnings.

	sim: warnings: enable -Wduplicated-cond

	sim: mn10300: fix LAST_TIMER_REG typo
	The compiler pointed out that we're testing LAST_TIMER_REG and
	LAST_COUNTER which are the same value ... and that's because we
	set LAST_TIMER_REG to the wrong register.  Fix the typo.

2023-12-21  Mike Frysinger  <vapier@gentoo.org>

	sim: bfin: clean up astat reg name decode a little
	The compiler pointed out we checked AZ twice.  Sort by name to avoid
	that in the future, and to make it clearer that we have coverage of
	all the bits.  And add the bits we were missing.

	The order here doesn't matter as it's just turning a pointer into a
	human readable string when store tracing is enabled.

2023-12-21  Mike Frysinger  <vapier@gentoo.org>

	sim: common: delete unused scache in some mloop paths
	The scache vars aren't used by ports in the pbb & fast codepaths,
	nor are they documented as inputs to the callbacks, so delete them
	to avoid unused variable compiler warnings.

	sim: cgen: unify the genmloop logic a bit
	Pull out the common parts of the genmloop invocation into the common
	code.  This will make it easier to add more, and make the per-port
	differences a little more obvious.

2023-12-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 31169 Source code locations can not be found in a C++ application
	gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF
	Version 3 or later.
	From DWARF specification:
	  References that use the attribute form DW_FORM_ref_addr are specified to
	  be four bytes in the DWARF 32-bit format and eight bytes in the DWARF
	  64-bit format, while DWARF Version 2 specifies that such references have
	  the same size as an address on the target system.

	2023-12-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/31169
		* src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr.

2023-12-20  Pedro Alves  <pedro@palves.net>

	Fix handling of vanishing threads that were stepping/stopping
	Downstream, AMD is carrying a testcase
	(gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues
	with the amd-dbgapi target's handling of exited threads.  The test
	can't be added upstream yet, unfortunately, due to dependency on DWARF
	extensions that can't be upstreamed yet.  However, it can be found on
	the mailing list on the same series as this patch.

	The test spawns a kernel with a number of waves.  The waves do nothing
	but exit.  There is a breakpoint on the s_endpgm instruction.  Once
	that breakpoint is hit, the test issues a "continue" command.  We
	should see one breakpoint hit per wave, and then the whole program
	exiting.  We do see that, however we also see this:

	 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
	 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
	 *repeat for other waves*
	 ...
	 [Thread 0x7ffff626f640 (LWP 3048491) exited]
	 [Thread 0x7fffeb7ff640 (LWP 3048488) exited]
	 [Inferior 1 (process 3048475) exited normally]

	That "New AMDGPU Wave" output comes from infrun.c itself adding the
	thread to the GDB thread list, because it got an event for a thread
	not on the thread list yet.  The output shows "?"s instead of proper
	coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED,
	i.e., the wave was already gone when infrun.c added the thread to the
	thread list.

	That shouldn't ever happen for the amd-dbgapi target, threads should
	only ever be added by the backend.

	Note "New AMDGPU Wave ?:?:?:1" is for wave 1.  What happened was that
	wave 1 terminated previously, and a previous call to
	amd_dbgapi_target::update_thread_list() noticed the wave had vanished
	and removed it from the GDB thread list.  However, because the wave
	was stepping when it terminated (due to the displaced step over the
	s_endpgm) instruction, it is guaranteed that the amd-dbgapi library
	queues a WAVE_COMMAND_TERMINATED event for the exit.

	When we process that WAVE_COMMAND_TERMINATED event, in
	amd-dbgapi-target.c:process_one_event, we return it to the core as a
	TARGET_WAITKIND_THREAD_EXITED event:

	 static void
	 process_one_event (amd_dbgapi_event_id_t event_id,
			    amd_dbgapi_event_kind_t event_kind)
	 {
	 ...
		 if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID
		     && event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED)
		   ws.set_thread_exited (0);
	 ...
	 }

	Recall the wave is already gone from the GDB thread list.  So when GDB
	sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't
	know about, it adds the thread to the thread list, resulting in that:

	 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]

	and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB
	marks the thread exited right afterwards:

	 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]

	The fix is to make amd_dbgapi_target::update_thread_list() _not_
	delete vanishing waves iff they were stepping or in progress of being
	stopped.  These two cases are the ones dbgapi guarantees will result
	in a WAVE_COMMAND_TERMINATED event if the wave terminates:

	  /**
	   * A command for a wave was not able to complete because the wave has
	   * terminated.
	   *
	   * Commands that can result in this event are ::amd_dbgapi_wave_stop and
	   * ::amd_dbgapi_wave_resume in single step mode.  Since the wave terminated
	   * before stopping, this event will be reported instead of
	   * ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP.
	   *
	   * The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE
	   * query.  However, the wave will be invalid since it has already terminated.
	   * It is the client's responsibility to know what command was being performed
	   * and was unable to complete due to the wave terminating.
	   */
	  AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2,

	As the comment says, it's GDB's responsability to know whether the
	wave was stepping or being stopped.  Since we now have a wave_info map
	with one entry for each wave, that seems like the place to store that
	information.  However, I still decided to put all the coordinate
	information in its own structure.  I.e., basically renamed the
	existing wave_info to wave_coordinates, and then added a new wave_info
	structure that holds the new state, plus a wave_coordinates object.
	This seemed cleaner as there are places where we only need to
	instantiate a wave_coordinates object.

	There's an extra twist.  The testcase also exercises stopping at a new
	kernel right after the first kernel fully exits.  In that scenario, we
	were hitting this assertion after the first kernel fully exits and the
	hit of the breakpoint at the second kernel is handled:

	 [amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP
	 [amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list)
	 ../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed.
	 A problem internal to GDB has been detected,
	 further debugging may prove unreliable.

	This is the exact same problem as above, just a different
	manifestation.  In this scenario, we end up in update_thread_list
	successfully deleting the exited thread (because it was no longer the
	current thread) that was incorrectly added by infrun.c.  Because it
	was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread,
	it doesn't have an entry in the wave_info map, so
	amd_dbgapi_thread_deleted trips on this assertion:

	      gdb_assert (it != info->wave_info_map.end ());

	here:

	  ...
	  -> stop_all_threads
	   -> update_thread_list
	    -> target_update_thread_list
	     -> amd_dbgapi_target::update_thread_list
	      -> thread_db_target::update_thread_list
	       -> linux_nat_target::update_thread_list
		-> delete_exited_threads
		 -> delete_thread
		  -> delete_thread_1
		   -> gdb::observers::observable<thread_info*>::notify
		    -> amd_dbgapi_thread_deleted
		     -> internal_error_loc

	The testcase thus tries both running to exit after the first kernel
	exits, and running to a breakpoint in a second kernel after the first
	kernel exits.

	Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
	Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028

2023-12-20  Pedro Alves  <pedro@palves.net>

	Fix thread target ID of exited waves
	Currently, if you step over kernel exit, you see:

	 stepi
	 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
	 Command aborted, thread exited.
	 (gdb)

	Those '?' are because the thread/wave is already gone by the time GDB
	prints the "exited" notification, we can't ask dbgapi for any info
	about the wave anymore.

	This commit fixes it by caching the wave's coordinates as soon as GDB
	sees the wave for the first time, and making
	amd_dbgapi_target::pid_to_str use the cached info.

	At first I thought of clearing the wave_info object from a
	thread_exited observer.  However, that is too soon, resulting in this:

	 (gdb) si
	 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
	 Command aborted, thread exited.
	 (gdb) thread
	 [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)]

	We need instead to clear the wave info when the thread is ultimately
	deleted, so we get:

	 (gdb) si
	 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
	 Command aborted, thread exited.
	 (gdb) thread
	 [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)]

	And for that, we need a new thread_deleted observable.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
	Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580

2023-12-20  Pedro Alves  <pedro@palves.net>

	Step over thread exit, always delete the thread non-silently
	With AMD GPU debugging, I noticed that when stepping over a breakpoint
	placed on top of the s_endpgm instruction inline (displaced=off), GDB
	would behave differently -- it wouldn't print the wave exit.  E.g:

	With displaced stepping, or no breakpoint at all:

	 stepi
	 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
	 Command aborted, thread exited.
	 (gdb)

	With inline stepping:

	 stepi
	 Command aborted, thread exited.
	 (gdb)

	In the cases we see the "exited" notification, handle_thread_exit is
	what first called delete_thread on the exiting thread, which is
	non-silent.

	With inline stepping, however, handle_thread_exit ends up in
	update_thread_list (via restart_threads) before any delete_thread
	call.  Thus, amd_dbgapi_target::update_thread_list notices that the
	wave is gone and deletes it with delete_thread_silent.

	This commit fixes it, by making handle_thread_exited call
	set_thread_exited (with the default silent=false) early, which emits
	the user-visible notification.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f

2023-12-20  Pedro Alves  <pedro@palves.net>

	displaced_step_finish: Don't fetch the regcache of exited threads
	displaced_step_finish can be called with event_status.kind ==
	TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to
	get at the already-exited thread's registers.

	This patch moves the get_thread_regcache calls to branches that
	actually need it, where we know the thread is still alive.

	It also adds an assertion to get_thread_regcache, to help catching
	these broken cases sooner.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3

2023-12-20  Pedro Alves  <pedro@palves.net>

	Ensure selected thread after thread exit stop
	While making step over thread exit work properly on AMDGPU, I noticed
	that if there's a breakpoint on top of the exit syscall, and,
	displaced stepping is off, then when GDB reports "Command aborted,
	thread exited.", GDB also switches focus to a random thread, instead
	of leaving the exited thread as selected:

	 (gdb) thread
	 [Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])]
	 (gdb) si
	 Command aborted, thread exited.
	 (gdb) thread
	 [Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))]
	 (gdb)

	The previous patch extended gdb.threads/step-over-thread-exit.exp to
	exercise this on GNU/Linux (on the CPU side), and there, after that
	"si", we always end up with the exiting thread as selected even
	without this fix, but that's just a concidence, there's a code path
	that happens to select the exiting thread for an unrelated reason.

	This commit add the explict switch, fixing the latent problem for
	GNU/Linux, and the actual problem on AMDGPU.  I wrote a gdb.rocm/
	testcase for this, but it can't be upstreamed yet, until more pieces
	of the DWARF machinery are upstream as well.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51

2023-12-20  Pedro Alves  <pedro@palves.net>

	gdb.threads/step-over-thread-exit.exp improvements
	This commit makes the following improvements to
	gdb.threads/step-over-thread-exit.exp:

	- Add a third axis to stepping over the breakpoint with displaced vs
	  inline stepping -- also test with no breakpoint at all.

	- Check that when GDB reports "Command aborted, thread exited.", the
	  selected thread is the thread that exited.  This is always true
	  currently on GNU/Linux by coincidence, but a similar testcase on AMD
	  GPU exposed a problem here.  Better make the testcase catch any
	  potential regression.

	- Fixes a race that Simon ran into with GDBserver testing.

	    (gdb) next
	    [New Thread 2143071.2143438]

	    Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
	    74      SYSCALL (my_exit, __NR_exit)
	    (gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits

	  I was not able to reproduce it, but I believe that what happens is
	  the following:

	  Once we continue, the thread 2 exits, and the main thread thus
	  unblocks from its pthread_join, and spawns a new thread.  That new
	  thread may hit the breakpoint at my_exit_syscall very quickly.  GDB
	  could then see/process that breakpoint event before the thread exit
	  event for the thread we care about, which would result in the
	  failure seen above.

	  The fix here is to not loop and start a new thread at all in the
	  scenario where the race can happen.  We only need to loop and spawn
	  new threads when testing with "cmd=continue" and schedlock off, in
	  which case GDB doesn't abort the command when the thread exits.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6

2023-12-20  Pedro Alves  <pedro@palves.net>

	Fix bug in previous remote unique_ptr change
	By inspection, I noticed that the previous patch went too far, here:

	 @@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior *inf)
	    if (rs->remote_desc == NULL)
	      return;

	 -  reply = (struct stop_reply *) rns->pending_event[notif_client_stop.id];
	 +  stop_reply_up reply
	 +    = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id]));

	    /* Discard the in-flight notification.  */
	    if (reply != NULL && reply->ptid.pid () == inf->pid)

	That is always moving the stop reply from pending_event, when we only
	really want to peek into it.  The code further below that even says:

	  /* Discard the in-flight notification.  */
	  if (reply != NULL && reply->ptid.pid () == inf->pid)
	    {
	      /* Leave the notification pending, since the server expects that
		 we acknowledge it with vStopped.  But clear its contents, so
		 that later on when we acknowledge it, we also discard it.  */

	This commit reverts that hunk back, adjusted to use unique_ptr::get().

	Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24

2023-12-20  Pedro Alves  <pedro@palves.net>

	Complete use of unique_ptr with notif_event and stop_reply
	We already use unique_ptr with notif_event and stop_reply in some
	places around the remote target, but not fully.  There are several
	code paths that still use raw pointers.  This commit makes all of the
	ownership of these objects tracked by unique pointers, making the
	lifetime flow much more obvious, IMHO.

	I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't
	destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE
	kind.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c

2023-12-20  Pedro Alves  <pedro@palves.net>

	Make cached_reg_t own its data
	struct cached_reg_t owns its data buffer, but currently that is
	managed manually.  Convert it to use a unique_xmalloc_ptr.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b

2023-12-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove stale comment and ctor in gdbarch_info
	tdesc_data is not part of a union, since commit 4f3681cc3361 ("Fix thread's
	gdbarch when SVE vector length changes").  Remove the stale comment and
	constructor.

	Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Add suffix to conditional branch instruction descriptions
	Suffix the instruction description of conditional branch extended
	mnemonics with their condition (e.g. "on A high"). This complements
	the optional printing of instruction descriptions as comments in the
	disassembly.

	Due to the added text the maximum description length is increased from
	80 to 128 characters (including the trailing '\0' character).

	opcodes/
		* s390-mkopc.c: Add suffix to conditional branch extended
		  mnemonic instruction descriptions.

	gas/
		* testsuite/gas/s390/zarch-insndesc.s: Add test cases for
		  printing of suffixed instruction description of conditional
		  branch extended mnemonics.
		* testsuite/gas/s390/zarch-insndesc.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Optionally print instruction description in disassembly
	Print instruction description as comment in disassembly with s390
	architecture specific option "insndesc":

	- For objdump it can be enabled with option "-M insndesc"
	- In gdb it can be enabled with "set disassembler-options insndesc"

	Since comments are not column aligned the output can enhanced for
	readability by postprocessing using a filter such as "expand":

	... | expand -t 8,16,24,32,40,80

	Or when using in combination with objdump option --visualize-jumps:

	... | expand | sed -e 's/ *#/\t#/' | expand -t 1,80

	Note that the instruction descriptions add about 128 KB to s390-opc.o:

	s390-opc.o without instruction descriptions: 216368 bytes
	s390-opc.o with instruction descriptions   : 348432 bytes

	binutils/
		* NEWS: Mention new s390-specific disassembler option
		  "insndesc".

	include/
		* opcode/s390.h (struct s390_opcode): Add field to hold
		  instruction description.

	opcodes/
		* s390-mkopc.c: Copy instruction description from s390-opc.txt
		  into generated operation code table s390-opc.tab.
		* s390-opc.c (s390_opformats): Provide NULL as description in
		  .insn pseudo-mnemonics opcode table.
		* s390-dis.c: Add s390-specific disassembler option "insndesc"
		  and optionally print the instruction description as comment in
		  the disassembly when it is specified.

	gas/
		* testsuite/gas/s390/s390.exp: Add new test disassembly test
		  case "zarch-insndesc".
		* testsuite/gas/s390/zarch-insndesc.s: New test case for s390-
		  specific disassembler option "insndesc".
		* testsuite/gas/s390/zarch-insndesc.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Use safe string functions and length macros in s390-mkopc
	Use strncpy() and snprintf() instead of strcpy() and strcat(). Define
	and use macros for string lengths, such as mnemonic, instruction
	format, and instruction description.

	This is a mechanical change, although some buffers have increased in
	length by one character. This has been confirmed by verifying that the
	generated opcode/s390-opc.tab is unchanged.

	opcodes/
		* s390-mkopc.c: Use strncpy() and strncat().

	Suggested-by: Nick Clifton <nickc@redhat.com>
	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Enhance error handling in s390-mkopc
	When the s390-mkopc utility detects an error it prints an error message
	to strerr and either continues processing or exists with a non-zero
	return code. If it continues without detecting any further error the
	final return code was zero, potentially hiding the detected error.

	Introduce a global variable to hold the final return code and initialize
	it to EXIT_SUCCESS. Introduce a helper function print_error() that
	prints an error message to stderr and sets the final return code to
	EXIT_FAILURE. Use it to print all error messages. Return the final
	return code at the end of the processing.

	While at it enhance error messages to state more clearly which mnemonic
	an error was detected for. Also continue processing for cases where
	subsequent mnemonics can be processed.

	opcodes/
		* s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE
		  in case of an error, otherwise EXIT_SUCCESS.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Provide IBM z16 (arch14) instruction descriptions
	Provide descriptions for instructions introduced with commit ba2b480f103
	("IBM Z: Implement instruction set extensions"). This complements commit
	69341966def ("IBM zSystems: Add support for z16 as CPU name."). Use
	instruction names from IBM z/Architecture Principles of Operation [1] as
	instruction description.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	opcodes/
		* s390-opc.txt: Add descriptions for IBM z16 (arch14)
		  instructions.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Align letter case of instruction descriptions
	Change the bitwise operations names "and" and "or" to lower case. Change
	the register name abbreviations "FPR", "GR", and "VR" to upper case.

	opcodes/
		* s390-opc.txt: Align letter case of instruction descriptions.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Jens Remus  <jremus@linux.ibm.com>

	s390: Fix build when using EXEEXT_FOR_BUILD
	Suffix the s390-mkopc build utility executable file name with
	EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with
	EXEEXT_FOR_BUILD. Use pattern used for other architecture build
	utilities and compile and link s390-mkopc in two steps.

	While at it also specify the dependencies of s390-mkopc.c.

	opcodes/
		* Makefile.am: Add target to build s390-mkopc.o. Correct
		  target to build s390-mkopc$(EXEEXT_FOR_BUILD).
		* Makefile.in: Regenerate.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-20  Mike Frysinger  <vapier@gentoo.org>

	sim: frv: enable warnings in memory.c
	Fix one minor pointer-sign warning to enable warnings in general
	for this file.  Reading the data as signed and then returning it
	as unsigned should be functionally the same in this case.

2023-12-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-19  Alan Modra  <amodra@gmail.com>

	Re: PR31145, potential memory leak in binutils/ld
	Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY
	iostream in io_reinit.

		PR 31145
		* format.c (io_reinit): Revert last change.  Comment.
		* opncls.c (_bfd_delete_bfd): Likewise.

2023-12-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw
	Here, we write single complete registers, we don't need the
	functionality of put_frame_register_bytes, use put_frame_register
	instead.

	Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove stale comment in value_assign
	This comment is no longer relevant, put_frame_register_bytes now accepts
	the "next frame".

	Change-Id: I077933a03f8bdb886f8ba10a98d1202a38bce0a9
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-19  Andrea Corallo  <andrea.corallo@arm.com>

	aarch64: Add FEAT_ITE support
	This patch add support for FEAT_ITE "Instrumentation Extension" adding
	the "trcit" instruction.

	This is enabled by the +ite march flag.

2023-12-19  Andrea Corallo  <andrea.corallo@arm.com>

	aarch64: Add FEAT_ECBHB support
	This patch add support for FEAT_ECBHB "Exploitative control using
	branch history information" adding the "clrbhb" instruction.  AFAIU
	the same alias was originally added as "clearbhb" before the
	architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional
	v8.0-a+/v9.0-a+).

2023-12-19  Andrea Corallo  <andrea.corallo@arm.com>

	aarch64: Add FEAT_SPECRES2 support
	This patch add supports for FEAT_SPECRES2 "Enhanced speculation
	restriction instructions" adding the "cosp" instruction.

	This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+.  It is
	enabled by the +predres2 march flag.

2023-12-19  Guinevere Larsen  <blarsen@redhat.com>

	gdb: register frame_destroyed function for amd64 gdbarch
	gdbarches usually register functions to check when a frame is destroyed
	which is used with software watchpoints, since the expression of the
	watchpoint is no longer vlaid at this point.  On amd64, this wasn't done
	anymore because GCC started using CFA for variable locations instead.

	However, clang doesn't use the CFA and instead relies on specifying when
	an epilogue has started, meaning software watchpoints get a spurious hit
	when a frame is destroyed. This patch re-adds the code to register the
	function that detects when a frame is destroyed, but only uses this when
	the producer is LLVM, so gcc code isn't affected. The logic that
	identifies the epilogue has been factored out into the new function
	amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
	directly, and its behavior isn't changed.

	This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
	that handled this exact flaw in clang.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-19  Mike Frysinger  <vapier@gentoo.org>

	sim: common: delete unused argbuf in generated mloop code
	This function only uses prev_abuf, not abuf, and doesn't inline code
	from the various ports on the fly, so abuf will never be used.

	sim: v850: fix -Wunused-variable warnings

	sim: sh: fix -Wunused-variable warnings

	sim: moxie: fix -Wunused-variable warnings

	sim: msp430: fix -Wunused-variable warnings

	sim: mn10300: fix -Wunused-variable warnings

	sim: mips: fix -Wunused-variable warnings

	sim: microblaze: fix -Wunused-variable warnings

	sim: mcore: fix -Wunused-variable warnings

	sim: m32r: fix -Wunused-variable warnings

	sim: lm32: fix -Wunused-variable warnings

	sim: iq2000: fix -Wunused-variable warnings

	sim: h8300: fix -Wunused-variable warnings

	sim: ft32: fix -Wunused-variable warnings

	sim: frv: fix -Wunused-variable warnings

	sim: erc32: fix -Wunused-variable warnings

	sim: cris: fix -Wunused-variable warnings

	sim: cr16: fix -Wunused-variable warnings

	sim: bpf: fix -Wunused-variable warnings

	sim: bfin: fix -Wunused-variable warnings

	sim: aarch64: fix -Wunused-variable warnings

	sim: common: fix -Wunused-variable warnings

	cpu: cris: drop some unused vars
	These fix unused variable warnings in the generated sim.

2023-12-19  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Remove the restriction for size of the mask register in AVX10
	Since AVX10.1/256 will also allow 64 bit mask register, we will
	remove the restriction for size of the mask register in AVX10.

	gas/ChangeLog:

		* config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
		(VEX_check_encoding): Remove opcode_modifier check for vsz.
		* testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
		registers since they are not needed.
		* testsuite/gas/i386/avx10-vsz.s: Ditto.

	opcodes/ChangeLog:

		* i386-gen.c: Remove Vsz.
		* i386-opc.h: Ditto.
		* i386-opc.tbl: Remove kvsz.
		* i386-tbl.h: Regenerated.

2023-12-19  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: Allow la.got -> la.pcrel relaxation for shared object
	Even in shared objects, la.got -> la.pcrel relaxation can still be
	performed for symbols with hidden visibility. For example, if a.c is:

	    extern int x;
	    int f() { return x++; }

	and b.c is:

	    int x = 114514;

	If compiling and linking with:

	    gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c

	Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
	should be like:

	    pcaddi  $t0, x
	    ldptr.w $a0, $t0, 0
	    addi.w  $t1, $a0, 1
	    stptr.w $t1, $t0, 0
	    ret

	Remove bfd_link_executable from the condition of la.got -> la.pcrel
	relaxation so this will really happen.  The SYMBOL_REFERENCES_LOCAL
	check is enough not to wrongly relax preemptable symbols (for e.g.
	when -fvisibility=hidden is not used).

	Note that on x86_64 this is also relaxed and the produced code is like:

	    lea x(%rip), %rdx
	    mov (%rdx), %rax
	    lea 1(%rax), %ecx
	    mov %ecx, (%rdx)
	    ret

	Tested by running ld test suite, bootstrapping and regtesting GCC with
	the patched ld, and building and testing Glibc with the patched ld.  No
	regression is observed.

2023-12-19  Jeff Law  <jeffreyalaw@gmail.com>

	Yet another fix for mcore-sim (rotli)
	This came up testing the CRC optimization work from Mariam@RAU.
	Basically to optimize some CRC loops into table lookups or carryless
	multiplies, we may need to do a bit reflection, which on the mcore
	processor is done using a rotate instruction.

	Unfortunately the simulator implementation of rotates has the exact same
	problem as we saw with right shifts.  The input value may have been sign
	extended from 32 to 64 bits.  When we rotate the extended value, we get
	those sign extension bits and thus the wrong result.

	The fix is the same.  Rather than using a "long", use a uint32_t for the
	type of the temporary.  This fixes a handful of tests in the GCC testsuite:

2023-12-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-18  Arsen Arsenović  <arsen@aarsen.me>

	gettext: disable install, docs targets, libasprintf, threads
	This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by
	Eric Gallager <egallager@gcc.gnu.org>.

	ChangeLog:

		* Makefile.def (gettext): Disable (via missing)
		{install-,}{pdf,html,info,dvi} and TAGS targets.  Set no_install
		to true.  Add --disable-threads --disable-libasprintf.
		* Makefile.in: Regenerate.

2023-12-18  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	ld: Print 0 size in B and not in GB
	When using --print-memory-usage, the printed size can be zero and in
	that case, the unit should be B and not GB.

	ld/
		* ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
		* testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
		* testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.

2023-12-18  Alan Modra  <amodra@gmail.com>

	PR31162, Memory Leak in ldwrite.c
	This isn't a particularly worrying memory leak, but fix it anyway.

		PR 31162
		* ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
		Add %E to error messages.

2023-12-18  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp
	The gdb.threads/thread-specific-bp.exp test has been a little
	problematic, see commits:

	  commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
	  Date:   Thu Mar 9 12:31:26 2023 +0100

	      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver

	and

	  commit 2e5843d87c4050bf1109921481fb29e1c470827f
	  Date:   Fri Nov 19 14:33:39 2021 +0100

	      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp

	But I recently saw a test failure for that test, which looked like
	this:

	  ...
	  (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
	  continue -a
	  Continuing.

	  Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
	  29      }
	  (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
	  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
	  FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
	  ...

	This only crops up (for me) when running on a loaded machine, and
	still only occurs sometimes.  I've had to leave the test running in a
	loop for 10+ minutes sometimes in order to see the failure.

	The problem is that we use gdb_test_multiple to try and match two
	patterns:

	  (1) The 'Thread-specific breakpoint 3 deleted ....' message, and
	  (2) The GDB prompt.

	As written in the test, we understand that these patterns can occur in
	any order, and we have a flag for each pattern.  Once both patterns
	have been seen then we PASS the test.

	The problem is that once expect has matched a pattern, everything up
	to, and including the matched text is discarded from the input
	buffer.  Thus, if the input buffer contains:

	  <PATTERN 2><PATTERN 1>

	Then expect will first try to match <PATTERN 1>, which succeeds, and
	then expect discards the entire input buffer up to the end of the
	<PATTERN 1>.  As a result, we will never spot <PATTERN 2>.

	Obviously we can't just reorder the patterns within the
	gdb_test_multiple, as the output can legitimately (and most often
	does) occur in the other order, in which case the test would mostly
	fail, and only occasionally pass!

	I think the easiest solution here is just to have the
	gdb_test_multiple contain two patterns, each pattern consists of the
	two parts, but in the alternative orders, thus, for a particular
	output configuration, only one regexp will match.  With this change in
	place, I no longer see the intermittent failure.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-18  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add call36 and tail36 pseudo instructions for medium code model
	  For tail36, it is necessary to explicitly indicate the temporary register.
	  Therefore, the compiler and users will know that the tail will use a register.

	  call36 func
	    pcalau18i $ra, %call36(func)
	    jirl      $ra, $ra, 0;

	  tail36 $t0, func
	    pcalau18i $t0, %call36(func)
	    jirl      $zero, $t0, 0;

2023-12-18  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add new relocation R_LARCH_CALL36
	R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
	these two instructions must adjacent.

	The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.

2023-12-18  Georg-Johann Lay  <avr@gjlay.de>

	PR31177: Let region text start at __TEXT_REGION_ORIGIN___
	The start of MEMORY region text currently starts hard-coded at 0.

	The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.

	For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.

	If ok, please apply to master.
	This one is also fine to back-port.

	Johann

	--

	AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.

	ld/
		PR 31177
		* scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
		(MEMORY): Use as start address for the text region.

2023-12-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-17  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: add more flags
	We already build cleanly with these.

2023-12-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-16  Hannes Domani  <ssbssa@yahoo.de>

	Use function entry point record only for entry values
	PR28987 notes that optimized code sometimes shows the wrong
	value of variables at the entry point of a function, if some
	code was optimized away and the variable has multiple values
	stored in the debug info for this location.

	In this example:
	```
	void foo()
	{
	   int l_3 = 5, i = 0;
	   for (; i < 8; i++)
	       ;
	   test(l_3, i);
	}
	```
	When compiled with optimization, the entry point of foo is at
	the test() function call, since everything else is optimized
	away.
	The debug info of i looks like this:
	```
	(gdb) info address i
	Symbol "i" is multi-location:
	  Base address 0x140001600  Range 0x13fd41600-0x13fd41600: the constant 0
	  Range 0x13fd41600-0x13fd41600: the constant 1
	  Range 0x13fd41600-0x13fd41600: the constant 2
	  Range 0x13fd41600-0x13fd41600: the constant 3
	  Range 0x13fd41600-0x13fd41600: the constant 4
	  Range 0x13fd41600-0x13fd41600: the constant 5
	  Range 0x13fd41600-0x13fd41600: the constant 6
	  Range 0x13fd41600-0x13fd41600: the constant 7
	  Range 0x13fd41600-0x13fd4160f: the constant 8
	(gdb) p i
	$1 = 0
	```

	Currently, when at the entry point of a function, it will
	always show the initial value (here 0), while the user would
	expect the last value (here 8).
	This logic was introduced for showing the entry-values of
	function arguments if they are available, but for some
	reason this was added for non-entry-values as well.

	One of the tests of amd64-entry-value.exp shows the same
	problem for function arguments, if you "break stacktest"
	in the following example, you stop at this line:
	```
	124     static void __attribute__((noinline, noclone))
	125     stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
	126                double d1, double d2, double d3, double d4, double d5, double d6,
	127                double d7, double d8, double d9, double da)
	128     {
	129       s1 = 3;
	130       s2 = 4;
	131       d9 = 3.5;
	132       da = 4.5;
	133 ->    e (v, v);
	134     asm ("breakhere_stacktest:");
	135       e (v, v);
	136     }
	```
	But `bt` still shows the entry values:
	```
	s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
	```

	I've fixed this by only using the initial values when
	explicitely looking for entry values.

	Now the local variable of the first example is as expected:
	```
	(gdb) p i
	$1 = 8
	```

	And the test of amd64-entry-value.exp shows the expected
	current and entry values of the function arguments:
	```
	s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
	Tested-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-16  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Remove dependency on _rl_term_autowrap
	Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a
	dependency on readline private variable _rl_term_autowrap.

	There is precedent for this, but it's something we want to get rid of
	(PR build/10723).

	Remove the dependency on _rl_term_autowrap, and instead calculate
	readline_hidden_cols by comparing the environment variable COLS with cols as
	returned by rl_get_screen_size.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10723

2023-12-16  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Show regs when switching to regs layout
	When starting gdb in CLI mode, running to main and switching into the TUI regs
	layout:
	...
	$ gdb -q a.out -ex start -ex "layout regs"
	...
	we get:
	...
	+---------------------------------+
	|                                 |
	| [ Register Values Unavailable ] |
	|                                 |
	+---------------------------------+
	...

	Fix this by handling this case in tui_data_window::rerender.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR tui/28600
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600

2023-12-16  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Use more box_width in tui-regs.c
	While experimenting with can_box () == false by default, I noticed two places
	in tui-regs.c where we can replace a hardcoded 1 with box_width ().

	It also turned out to be necessary to set scrollok to false, otherwise writing
	the last char of the last line with register info will cause a scroll.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-16  Mike Frysinger  <vapier@gentoo.org>

	sim: cr16: clean up unused insn operands
	The push/pop insns only have 2 operands, so delete unused "c".

	The pushret/popret insns use 2 operands, but they don't implement the
	logic directly, they call the push/pop implementations.  So delete the
	unused "a" & "b".

2023-12-16  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: adjust some dsp insn masks
	The pmuls encoding is incorrect -- it looks like a copy & paste error
	from the padd pmuls variant.  The SuperH software manual covers this.

	On the flip side, the manual lists pwsb & pwad as insns that exist,
	but no description of what they do, what the insn name means, or the
	actual encoding.  Our sim implementation stubs them both out as nops.
	Let's mark the fields to avoid unused variable warnings.

2023-12-16  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: tidy up gencode slightly
	Mark a few things static/const, and clean up trailing whitespace.

	sim: bfin: fix typo in bf52x ports
	These should be using the BF52x set of ports, not BF51x.

	sim: warnings: enable -Wunused-but-set-variable

	sim: mn10300: fix incorrect implementation of a few insns
	Fix a few problems caught by compiler warnings:
	* Some of the asr & lsr insns were setting up the c state flag,
	  but then forgetting to set it in the PSW.  Add it like the other
	  asr & lsr variants.
	* Some of the dmulh insns were multiplying one of the source regs
	  against itself instead of against the other source reg.
	* The sat16_cmp parallel insn was using the wrong register in the
	  compare -- the reg1 src/dst pair are used in the sat16 op, and
	  the reg2 src/dst pair are used in the add op.

2023-12-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-15  Tom Tromey  <tromey@adacore.com>

	Refine Ada overload matching
	Currently, the overload handling in Ada assumes that any two array
	types are compatible.  However, this is obviously untrue, and a user
	reported an oddity where comparing two Ada strings resulted in a call
	to the "=" function for packed boolean arrays.

	This patch improves the situation somewhat, by requiring that the two
	arrays have the same arity and compatible base element types.  This is
	still over-broad, but it seems safe and is better than the status quo.

2023-12-15  Tom Tromey  <tromey@adacore.com>

	Boolify ada_type_match
	This changes ada_type_match to return bool.

2023-12-15  John David Anglin  <danglin@gcc.gnu.org>

	Fix segmentation fault in bfd/elf32-hppa.c
	2023-12-15  John David Anglin  <danglin@gcc.gnu.org>

		PR ld/31148

	bfd/ChangeLog:

		* elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output
		relative reloc only when eh->root.type is bfd_link_hash_defined
		or bfd_link_hash_defweak.

2023-12-15  Matthieu Longo  <matthieu.longo@arm.com>

	arm: reformat -march option section in gas documentation
	Hi,

	This patch contains a reformatting of -march option section in gas documentation.

	For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options),
	before all the options were on one line:
	   For armv8-a:
	   +crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables
	   Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier
	   Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction
	   Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions.
	   +nocrypto: Disables Cryptography Extensions.

	Now, the readability is improved thanks to the itemization of the options:
	   For armv8-a:
	    +crc: Enables CRC32 Extension.
	    +simd: Enables VFP and NEON for Armv8-A.
	    +crypto: Enables Cryptography Extensions for Armv8-A, implies +simd.
	    +sb: Enables Speculation Barrier Instruction for Armv8-A.
	    +predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A.
	    +nofp: Disables all FPU, NEON and Cryptography Extensions.
	    +nocrypto: Disables Cryptography Extensions.

	Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.

	Regards,
	Matthieu.

2023-12-15  Matthieu Longo  <matthieu.longo@arm.com>

	aarch64: Enable Cortex-X3 CPU
	Hi,

	This patch adds support for the Cortex-X3 CPU to binutils.

	Gas regression testing for aarch64-none-linux-gnu target and found no regressions.

	Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.

	Regards,

	Matthieu.

2023-12-15  Matthieu Longo  <matthieu.longo@arm.com>

	arm: document -march=armv9.[123]-a binutils options

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	x86: last-insn recording should be per-subsection
	Otherwise intermediate subsection switches result in inconsistent
	behavior. Leverage ELF's section change hook to switch state as
	necessary, limiting overhead to the bare minimum when subsections aren't
	used.

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	ELF: reliably invoke md_elf_section_change_hook()
	... after any (sub)section change. While certain existing target hooks
	only look at now_seg, for a few others it looks as if failing to do so
	could have caused anomalies if sub-sections were used. In any event a
	subsequent x86 change is going to require the sub-section to be properly
	in place at the time the hook is invoked.

	This primarily means for obj_elf_section() to pass the new subsection
	into change_section(), for it to be set right away (ahead of invoking
	the hook).

	Also adjust obj_elf_ident() to invoke the hook after all section
	changes. (Note that obj_elf_version(), which also changes sections and
	then changes them back, has no hook invocation at all so far, so none
	are added. Presumably there is a reason for this difference in
	behavior.)

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	ELF: drop "push" parameter from obj_elf_change_section()
	No caller outside of obj-elf.c cares about the parameter - drop it by
	introducing an obj-elf.c-internal wrapper.

	While adding the new function parameter, take the opportunity and change
	the adjacent boolean one to "bool".

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	x86: don't needlessly override .bss
	ELF, COFF, and Mach-O all have custom handlers for .bss. Don't override
	those; install a handler only for a.out.

	revert "x86: allow 32-bit reg to be used with U{RD,WR}MSR"
	This reverts commit 1f865bae65db9588f6994c02a92355bfb4e3d955. The
	specification is going to by updated in a way rendering this change
	wrong.

	x86: fold assembly dialect attributes
	Now that ATTSyntax and ATTMnemonic aren't use in combination anymore,
	fold them and IntelSyntax into a single, enum-like attribute. Note that
	this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's
	not for long, seeing in-flight additions for APX).

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	x86: Intel syntax implies Intel mnemonics
	As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly
	of fsub*/fdiv*") there's no such thing as Intel syntax without Intel
	mnemonics. Enforce this on the assembler side, and disentangle command
	line option handling on the disassembler side accordingly.

	As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes
	redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and
	remove the then no longer accessible templates.

2023-12-15  Jan Beulich  <jbeulich@suse.com>

	Arm64: fix build for certain gcc versions
	Some complain (by default) about isalpha shadowing ctype.h's isalpha().
	Some also complain about signed/unsigned comparison a few lines later.

2023-12-15  Georg-Johann Lay  <avr@gjlay.de>

	Addendum to PR31124
	This is a small addendum to PR31124 "rodata in flash for
	more AVR devices".

	It adds some symbols so the startup code can set a lock
	on the FLMAP bit field as specified by the user.

	New symbols are introduced because otherwise, all the
	computations / decisions would have to be performed at
	run-time.

	It approved, please apply to master.

	Johann

	--

	ld/
		PR 31124
		* scripttempl/avr.sc: Adjust comments.
		[MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock.
		Remove __flmap_lsl4.

2023-12-15  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: fix mloop.in variant stamp deps
	The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053
	accidentally listed the deps for all mloop steps as mloop.in instead of the
	various variants that m32r uses.

	Reported-by: Simon Marchi <simon.marchi@polymtl.ca>

2023-12-15  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: use @cpu@_fill_argbuf_tp to set trace & profile state
	The mloop.in code does this, but these variants do not.  Use it to
	avoid unused function warnings.  The fast_p logic in these files
	also looks off, but that'll require a bit more work to fixup.

	  CC       m32r/mloopx.o
	m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
	   37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
	      | ^~~~~~~~~~~~~~~~~~~~~

	  CC       m32r/mloop2.o
	m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
	   37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
	      | ^~~~~~~~~~~~~~~~~~~~~

	Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
	Tested-By: Simon Marchi <simon.marchi@polymtl.ca>

2023-12-15  Mike Frysinger  <vapier@gentoo.org>

	sim: igen: do not reindent literal semantics output
	When generating semantics.c from .igen source files, indenting the code
	makes it more readable, but confuses compiler diagnostics.  The latter
	is a bit more important than the former, so bias towards that.

	For example, with an introduced error, we can see w/gcc-13:

	(before this change)
	  CC       mn10300/semantics.o
	../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
	../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function)
	   11 |   srcreg = translate_rreg (SD_, RN2);
	      |     ^~~~~~

	(with this change)
	  CC       mn10300/semantics.o
	../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
	../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function)
	   11 |   srcreg = translate_rreg (SD_, RN2);
	      |   ^~~~~~

2023-12-15  Alan Modra  <amodra@gmail.com>

	regen ld POTFILES

	PR31145, potential memory leak in binutils/ld
		PR 31145
		* bfd.c (BFD_IN_MEMORY): Mention that bim is malloc'd.
		* format.c (io_reinit): Free BFD_IN_MEMORY iostream.
		* opncls.c (_bfd_delete_bfd): Likewise.
		(bfd_make_readable): Delete unnecessary code.
		* bfd-in2.h: Regenerate.

	Re: readelf..debug-dump=loc displays bogus base addresses
	Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to
	prevent segfaults when debug_info_p is NULL, which can be the case
	with fuzzed objects.  Restore those checks.  Also, for dwo look at
	rnglists_dwo rather than rnglists.

2023-12-15  Xiao Zeng  <zengxiao@eswincomputing.com>

	RISC-V: Imply 'Zicntr' and 'Zihpm' implicitly depended on 'Zicsr'
	This commit adds support for ratified extensions:
	'Zicntr' and 'Zihpm', Which are all implicitly depend on 'Zicsr'.

	This is based on:
	<https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf>

	bfd/ChangeLog:

		* elfxx-riscv.c:  Add 'Zicntr' and 'Zihpm' -> 'Zicsr'.
	        (riscv_supported_std_z_ext) Add 'Zicntr' and 'Zihpm' to the list.

2023-12-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix -Wuse-after-free warning
	Removed incorrect unnecessary code.

	gprofng/ChangeLog
	2023-12-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/collctrl.cc (set_synctrace): Fix -Wuse-after-free warning.

2023-12-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/options: fix copy&paste error in string_option_def
	Spotted what appears to be a copy&paste error in string_option_def,
	the code for string handling writes the address fetching callback
	function into the option_def::var_address::enumeration location,
	rather than option_def::var_address::string.

	Of course, this works just fine as option_def::var_address is a union,
	and all of its members are function pointers, so they're going to be
	the same size on every target GDB cares about.

	But it doesn't hurt to be correct, so fixed in this commit.

	There should be no user visible changes after this commit.

2023-12-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: add tests for unwinding of pseudo registers
	This patch adds tests to exercise the previous patches' changes.

	All three tests:

	 - aarch64-pseudo-unwind
	 - amd64-pseudo-unwind
	 - arm-pseudo-unwind

	follow the same pattern, just with different registers.

	The other test, arm-pseudo-unwind-legacy, tests the special case where
	the unwind information contains an entry for a register considered a
	pseudo-register by GDB.

	Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Reviewed-by: Luis Machado <luis.machado@arm.com>
	Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
	Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: migrate arm to new gdbarch_pseudo_register_write
	Make arm use the new gdbarch_pseudo_register_write.  This fixes writing
	pseudo registers to non-current frames for that architecture.

	Change-Id: Icb2a649ab6394817844230e9e94c3d0564d2f765
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-by: Luis Machado <luis.machado@arm.com>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: migrate arm to gdbarch_pseudo_register_read_value
	Make arm use the "newer" gdbarch_pseudo_register_read_value.  This fixes
	reading pseudo registers in non-current frames on that architecture.

	Change-Id: Ic4d3d5d96957a4addfa3443c7b567dc4a31794a9
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-by: Luis Machado <luis.machado@arm.com>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: migrate aarch64 to new gdbarch_pseudo_register_write
	Make aarch64 use the new gdbarch_pseudo_register_write.  This fixes
	writing pseudo registers to non-current frames on this architecture.

	Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add missing raw register read in aarch64_sme_pseudo_register_write
	It seems like the intention here is to read the contents of the ZA
	register and only write part of it.  However, there's no actual read of
	the ZA register, so it looks like we'll write uninitialized bytes to the
	target, for the portion of the raw register where we don't write the
	pseudo register.  Add a call to raw_read to fix this.

	I don't know how to test this though.

	Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-by: Luis Machado <luis.machado@arm.com>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make aarch64_za_offsets_from_regnum return za_offsets
	This is not necessary, but it seems more natural to me to make
	aarch64_za_offsets_from_regnum return a za_offsets object, rather than
	fill an instance passed by parameter.

	Change-Id: I40a185f055727da887ce7774be193eef1f4b9147
	Approved-by: Luis Machado <luis.machado@arm.com>
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_write
	Make i386 and amd64 use the new gdbarch_pseudo_register_write.  This
	fixes writing to pseudo registers in non-current frames for those
	architectures.

	Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add gdbarch_pseudo_register_write that takes a frame
	Add a new variant of gdbarch_pseudo_register_write that takes a
	frame_info in order to write raw registers.  Use this new method when
	available:

	 - in put_frame_register, when trying to write a pseudo register to a given frame
	 - in regcache::cooked_write

	No implementation is migrated to use this new method (that will come in
	subsequent patches), so no behavior change is expected here.

	The objective is to fix writing pseudo registers to non-current
	frames.  See previous commit "gdb: read pseudo register through
	frame" for a more detailed explanation.

	Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write
	The next patch introduces a new variant of gdbarch_pseudo_register_write
	that takes a frame instead of a regcache for implementations to write
	raw registers.  Rename to old one to make it clear it's deprecated.

	Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: change parameter name in frame_unwind_register_unsigned declaration
	For consistency with the declarations around.

	Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: read pseudo register through frame
	Change gdbarch_pseudo_register_read_value to take a frame instead of a
	regcache.  The frame (and formerly the regcache) is used to read raw
	registers needed to make up the pseudo register value.  The problem with
	using the regcache is that it always provides raw register values for
	the current frame (frame 0).

	Let's say the user wants to read the ebx register on amd64.  ebx is a pseudo
	register, obtained by reading the bottom half (bottom 4 bytes) of the
	rbx register, which is a raw register.  If the currently selected frame
	is frame 0, it works fine:

	    (gdb) frame 0
	    #0  break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36
	    36      in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
	    (gdb) p/x $ebx
	    $1 = 0x24252627
	    (gdb) p/x $rbx
	    $2 = 0x2021222324252627

	But if the user is looking at another frame, and the raw register behind
	the pseudo register has been saved at some point in the call stack, then
	we get a wrong answer:

	    (gdb) frame 1
	    #1  0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
	    56      in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
	    (gdb) p/x $ebx
	    $3 = 0x24252627
	    (gdb) p/x $rbx
	    $4 = 0x1011121314151617

	Here, the value of ebx was computed using the value of rbx in frame 0
	(through the regcache), it should have been computed using the value of
	rbx in frame 1.

	In other to make this work properly, make the following changes:

	 - Make dwarf2_frame_prev_register return nullptr if it doesn't know how
	   to unwind a register and that register is a pseudo register.
	   Previously, it returned `frame_unwind_got_register`, meaning, in our
	   example, "the value of ebx in frame 1 is the same as the value of ebx
	   in frame 0", which is obviously false.  Return nullptr as a way to
	   say "I don't know".

	 - In frame_unwind_register_value, when prev_register (for instance
	   dwarf2_frame_prev_register) returns nullptr, and we are trying to
	   read a pseudo register, try to get the register value through
	   gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
	   If using gdbarch_pseudo_register_read, the behavior is known to be
	   broken.  Implementations should be migrated to use
	   gdbarch_pseudo_register_read_value to fix that.

	 - Change gdbarch_pseudo_register_read_value to take a frame_info
	   instead of a regcache, update implementations (aarch64, amd64, i386).
	   In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
	   uses a frame instead of a regcache.  The version using the regcache
	   is still used by i386_pseudo_register_write.  It will get removed in
	   a subsequent patch.

	 - Add some helpers in value.{c,h} to implement the common cases of
	   pseudo registers: taking part of a raw register and concatenating
	   multiple raw registers.

	 - Update readable_regcache::{cooked_read,cooked_read_value} to pass the
	   current frame to gdbarch_pseudo_register_read_value.  Passing the
	   current frame will give the same behavior as before: for frame 0, raw
	   registers will be read from the current thread's regcache.

	Notes:

	 - I do not plan on changing gdbarch_pseudo_register_read to receive a
	   frame instead of a regcache. That method is considered deprecated.
	   Instead, we should be working on migrating implementations to use
	   gdbarch_pseudo_register_read_value instead.

	 - In frame_unwind_register_value, we still ask the unwinder to try to
	   unwind pseudo register values.  It's apparently possible for the
	   debug info to provide information about [1] pseudo registers, so we
	   want to try that first, before falling back to computing them
	   ourselves.

	[1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/

	Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add value::allocate_register
	Add value::allocate_register, to facilitate allocating a value
	representing a register in a given frame (or rather, in the given
	frame's previous frame).  It will be used in a subsequent patch.  I
	changed one relatively obvious spot that could use it, to at least
	exercise the code path.

	Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make get_frame_register_bytes take the next frame
	Similar to the previous patches, change get_frame_register_bytes to take
	the "next frame" instead of "this frame".

	Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make put_frame_register_bytes take the next frame
	Similar to the previous patches, change put_frame_register_bytes to take
	the "next frame" instead of "this frame".

	Change-Id: I27bcb26573686d99b231230823cff8db6405a788
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make put_frame_register take the next frame
	Similar to the previous patches, change put_frame_register to take the
	"next frame" instead of "this frame".

	Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove frame_register
	I was going to change frame_register to take the "next frame", but I
	realized that doing so would make it a useless wrapper around
	frame_register_unwind.  So, just remove frame_register and replace uses
	with frame_register_unwind.

	Change-Id: I185868bc69f8e098124775d0550d069220a4678a
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: change value_of_register and value_of_register_lazy to take the next frame
	Some functions related to the handling of registers in frames accept
	"this frame", for which we want to read or write the register values,
	while other functions accept "the next frame", which is the frame next
	to that.  The later is needed because we sometimes need to read register
	values for a frame that does not exist yet (usually when trying to
	unwind that frame-to-be).

	value_of_register and value_of_register_lazy both take "this frame",
	even if what they ultimately want internally is "the next frame".  This
	is annoying if you are in a spot that currently has "the next frame" and
	need to call one of these functions (which happens later in this
	series).  You need to get the previous frame only for those functions to
	get the next frame again.  This is more manipulations, more chances of
	mistake.

	I propose to change these functions (and a few more functions in the
	subsequent patches) to operate on "the next frame".  Things become a bit
	less awkward when all these functions agree on which frame they take.

	So, in this patch, change value_of_register_lazy and value_of_register
	to take "the next frame" instead of "this frame".  This adds a lot of
	get_next_frame_sentinel_okay, but if we convert the user registers API
	to also use "the next frame" instead of "this frame", it will get simple
	again.

	Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make put_frame_register take an array_view
	Change put_frame_register to take an array_view instead of a raw
	pointer.

	Add an assertion to verify that the number of bytes we try to write
	matches the length of the register.

	Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix bugs in {get,put}_frame_register_bytes
	I found this only by inspection: the myaddr pointer in
	{get,put}_frame_register_bytes is reset to `buffer.data ()` at each
	iteration.  This means that we will always use the bytes at the
	beginning of `buffer` to read or write to the registers, instead of
	progressing in `buffer`.

	Fix this by re-writing the functions to chip away the beginning of the
	buffer array_view as we progress in reading or writing the data.

	These bugs was introduced almost 3 years ago [1], and yet nobody
	complained.  I'm wondering which architecture relies on that register
	"overflow" behavior (reading or writing multiple consecutive registers
	with one {get,put}_frame_register_bytes calls), and in which situation.
	I find these functions a bit dangerous, if a caller mis-calculates
	things, it could end up silently reading or writing to the next
	register, even if it's not the intent.

	If I could change it, I would prefer to have functions specifically made
	for that ({get,put}_frame_register_bytes_consecutive or something like
	that) and make {get,put}_frame_register_bytes only able to write within
	a single register (which I presume represents most of the use cases of
	the current {get,put}_frame_register_bytes).  If a caller mis-calculates
	things and an overflow occurs while calling
	{get,put}_frame_register_bytes, it would hit an assert.  The problem is
	knowing which callers rely on the overflow behavior and which don't.

	[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43

	Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: change regcache interface to use array_view
	Change most of regcache (and base classes) to use array_view when
	possible, instead of raw pointers.  By propagating the use of array_view
	further, it enables having some runtime checks to make sure the what we
	read from or write to regcaches has the expected length (such as the one
	in the `copy(array_view, array_view)` function.  It also integrates well
	when connecting with other APIs already using gdb::array_view.

	Add some overloads of the methods using raw pointers to avoid having to
	change all call sites at once (which is both a lot of work and risky).

	I tried to do this change in small increments, but since many of these
	functions use each other, it ended up simpler to do it in one shot than
	having a lot of intermediary / transient changes.

	This change extends into gdbserver as well, because there is some part
	of the regcache interface that is shared.

	Changing the reg_buffer_common interface to use array_view caused some
	build failures in nat/aarch64-scalable-linux-ptrace.c.  That file
	currently "takes advantage" of the fact that
	reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which
	IMO is dangerous.  It uses raw_supply/raw_collect directly on
	uint64_t's, which I guess is fine because it is expected that native
	code will have the same endianness as the debugged process.  To
	accomodate that, add some overloads of raw_collect and raw_supply that
	work on uint64_t.

	This file also uses raw_collect and raw_supply on `char` pointers.
	Change it to use `gdb_byte` pointers instead.  Add overloads of
	raw_collect and raw_supply that work on `gdb_byte *` and make an
	array_view on the fly using the register's size.  Those call sites could
	be converted to use array_view with not much work, in which case these
	overloads could be removed, but I didn't want to do it in this patch, to
	avoid starting to dig in arch-specific code.

	During development, I inadvertently changed reg_buffer::raw_compare's
	behavior to not accept an offset equal to the register size.  This
	behavior (effectively comparing 0 bytes, returning true) change was
	caught by the AArch64 SME core tests.  Add a selftest to make sure that
	this raw_compare behavior is preserved in the future.

	Change-Id: I9005f04114543ddff738949e12d85a31855304c2
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part
	Make a few simplifications in these functions.

	1. When checking if we need to do nothing, if the length is 0, we don't
	   need to do anything, regardless of the value of offset.  Remove the
	   offset check.

	2. When check if transferring the whole register, if the length is equal
	   to the register size, then we transfer the whole register, no need to
	   check the offset.  Remove the offset check.

	3. In the gdb_asserts, it is unnecessary to check for:

	     offset <= reg_size

	   given that right after we check for:

	     len >= 0 && offset + len <= reg_size

	   If `offset + len` is <= reg_size and len is >= 0, then necessarily
	   offset is <= reg_size.  Remove the `offset <= reg_size` check.

	Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make store_integer take an array_view
	Change store_integer, store_signed_integer and store_unsigned_integer to
	accept an array_view.  Add some backwards compatibility overloads to
	avoid changing all callers at once.

	Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h
	Right now, gdbsupport/common-regcache.h contains two abstractons for a
	regcache.  An opaque type `regcache` (gdb and gdbserver both have their
	own regcache that is the concrete version of this) and an abstract base
	class `reg_buffer_common`, that is the base of regcaches on both sides.
	These abstractions allow code to be written for both gdb and gdbserver,
	for instance in the gdb/arch sub-directory.

	However, having two
	different abstractions is impractical.  If some common code has a regcache,
	and wants to use an operation defined on reg_buffer_common, it can't.
	It would be better to have just one.  Change all instances of `regcache
	*` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix
	fallouts.

	Implementations in gdb and gdbserver now need to down-cast (using
	gdb::checked_static_cast) from reg_buffer_common to their concrete
	regcache type.  Some of them could be avoided by changing free functions
	(like regcache_register_size) to be virtual methods on
	reg_buffer_common.  I tried it, it seems to work, but I did not include
	it in this series to avoid adding unnecessary changes.

	Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't handle i386 k registers as pseudo registers
	I think that i386 k registers are raw registers, and therefore shouldn't
	be handled in the various functions handling pseudo registers.

	What tipped me off is the code in i386_pseudo_register_read_into_value:

	      else if (i386_k_regnum_p (gdbarch, regnum))
		{
		  regnum -= tdep->k0_regnum;

		  /* Extract (always little endian).  */
		  status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf);

	We take regnum (the pseudo register number we want to read), subtract
	k0_regnum, add k0_regnum, and pass the result to raw_read.  So we would
	end up calling raw_read with the same regnum as the function received
	which is supposedly a pseudo register number.

	Other hints are:

	 - The command `maint print raw-registers` shows the k registers.
	 - Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be
	   called.
	 - There's code in i387-tdep.c to save/restore the k registers.

	Remove handling of the k registers from:

	 - i386_pseudo_register_read_into_value
	 - i386_pseudo_register_write
	 - i386_ax_pseudo_register_collect

	Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-12-14  Hannes Domani  <ssbssa@yahoo.de>

	Allow calling of variadic C++ functions
	Currently, it's not possible to call a variadic C++ function:
	```
	(gdb) print sum_vararg_int(1, 10)
	Cannot resolve function sum_vararg_int to any overloaded instance
	(gdb) print sum_vararg_int(2, 20, 30)
	Cannot resolve function sum_vararg_int to any overloaded instance
	```

	It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
	rank by rank_function, which disqualifies the function.

	To fix this, I've created the new VARARG_BADNESS rank, which is
	used only for additional arguments of variadic functions, allowing
	them to be called:
	```
	(gdb) print sum_vararg_int(1, 10)
	$1 = 10
	(gdb) print sum_vararg_int(2, 20, 30)
	$2 = 50
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-14  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Fix the wrong encoding and operand of the XTheadFmv extension.
	The description of instructions 'th.fmv.hw.x' and 'th.fmv.x.hw' of the
	XTheadFmv extension in T-Head specific is incorrect, and it also has
	some impact on the implementation of the binutils, so this patch
	corrects this.

	For details see:
	https://github.com/T-head-Semi/thead-extension-spec/pull/34

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-fmv.d: Correct test.
		* testsuite/gas/riscv/x-thead-fmv.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_FMV_HW_X): Correct coding.
		(MASK_TH_FMV_HW_X): Likewise.
		(MATCH_TH_FMV_X_HW): Likewise.
		(MASK_TH_FMV_X_HW): Likewise.

	opcodes/ChangeLog:

		* riscv-opc.c: Correct operands.

2023-12-14  Cui, Lili  <lili.cui@intel.com>

	Remove redundant Byte, Word, Dword and Qword from insn templates.
	opcodes/ChangeLog:

		* i386-opc.tbl: Remove redundant Byte, Word, Dword and Qword.

2023-12-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-13  Tom Tromey  <tom@tromey.com>

	Use unique_xmalloc_ptr in explicit_location_spec
	This changes explicit_location_spec to use unique_xmalloc_ptr,
	removing some manual memory management.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-13  Tom Tromey  <tom@tromey.com>

	Use unique_xmalloc_ptr in linespec_location_spec
	This changes linespec_location_spec to use unique_xmalloc_ptr,
	removing some manual memory management.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-13  H.J. Lu  <hjl.tools@gmail.com>

	Update Make const_1_mode print $1 in AT&T syntax
	commit b70a487d5945b13e5ab503be4fc37b964819ec0e
	Author: Cui, Lili <lili.cui@intel.com>
	Date:   Wed Dec 13 06:07:36 2023 +0000

	    Make const_1_mode print $1 in AT&T syntax

	changes disassembler output from

	d1 f8                   sar    %eax

	to

	d1 f8                   sar    $1,%eax

	Adjust pe-x86-64-6.od accordingly.

		* testsuite/ld-x86-64/pe-x86-64-6.od: Adjusted.

2023-12-13  Magne Hov  <mhov@undo.io>

	[gdb/tui] add SingleKey bindings for reverse execution commands
	The bindings for the reverse execution commands are the same letters
	as the forward execution command, but with the opposite case. This way
	one can simply hold down the Shift modifier key or tap the Caps Lock key
	to change the direction of execution.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: avoid use of _PyOS_ReadlineTState
	In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState,
	however, this variable is no longer public in Python 3.13, and so GDB
	no longer builds.

	We are making use of _PyOS_ReadlineTState in order to re-acquire the
	Python Global Interpreter Lock (GIL).  The _PyOS_ReadlineTState
	variable is set in Python's outer readline code prior to calling the
	user (GDB) supplied readline callback function, which for us is
	gdbpy_readline_wrapper.  The gdbpy_readline_wrapper function is called
	without the GIL held.

	Instead of using _PyOS_ReadlineTState, I propose that we switch to
	calling PyGILState_Ensure() and PyGILState_Release().  These functions
	will acquire the GIL based on the current thread.  I think this should
	be sufficient; I can't imagine why we'd be running
	gdbpy_readline_wrapper on one thread on behalf of a different Python
	thread.... that would be unexpected I think.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-13  Alexandra Hájková  <ahajkova@redhat.com>

	gdb: move gdbpy_gil into python-internal.h
	Move gdbpy_gil class into python-internal.h, the next
	commit wants to make use of this class from a file other
	than python.c.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-13  Andrew Burgess  <aburgess@redhat.com>

	gdb: improve error reporting for 'save gdb-index'
	While making recent changes to 'save gdb-index' command I triggered
	some errors -- of the kind a user might be expected to trigger if they
	do something wrong -- and I didn't find GDB's output as helpful as it
	might be.

	For example:

	  $ gdb -q /tmp/hello.x
	  ...
	  (gdb) save gdb-index /non_existing_dir
	  Error while writing index for `/tmp/hello': mkstemp: No such file or directory.

	That the error message mentions '/tmp/hello', which does exist, but
	doesn't mention '/non_existing_dir', which doesn't is, I think,
	confusing.

	Also, I find the 'mkstemp' in the error message confusing for a user
	facing error.  A user might not know what mkstemp means, and even if
	they do, that it appears in the error message is an internal GDB
	detail.  The user doesn't care what function failed, but wants to know
	what was wrong with their input, and what they should do to fix
	things.

	Similarly, for a directory that does exist, but can't be written to:

	  (gdb) save gdb-index /no_access_dir
	  Error while writing index for `/tmp/hello': mkstemp: Permission denied.

	In this case, the 'Permission denied' might make the user thing there
	is a permissions issue with '/tmp/hello', which is not the case.

	After this patch, the new errors are:

	  (gdb) save gdb-index /non_existing_dir
	  Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.

	and:

	  (gdb) save gdb-index /no_access_dir
	  Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.

	we also have:

	  (gdb) save gdb-index /tmp/not_a_directory
	  Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.

	I think these do a better job of guiding the user towards fixing the
	problem.

	I've added a new test that exercises all of these cases, and also
	checks the case where a user tries to use an executable that already
	contains an index in order to generate an index.  As part of the new
	test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
	into a new proc (get_index_type), which I've then used in the new
	test.  I've confirmed that all the tests that use ensure_gdb_index
	still pass.

	During review it was pointed out that the testsuite proc
	have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
	I've rewritten have_index to also use get_index_type, I've confirmed
	that all the tests that use have_index still pass.

	Nothing that worked correctly before this patch should give an error
	after this patch; I've only changed the output when the user was going
	to get an error anyway.

	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-13  Cui, Lili  <lili.cui@intel.com>

	Make const_1_mode print $1 in AT&T syntax
	Make const_1_mode print $1 in AT&T syntax, otherwise
	there will be correctness issues when it is extended
	to support APX NDD,

	gas/ChangeLog:

	        * testsuite/gas/i386/intel.d: Adjust testcase.
	        * testsuite/gas/i386/lfence-load.d: Ditto.
	        * testsuite/gas/i386/noreg16-data32.d: Ditto.
	        * testsuite/gas/i386/noreg16.d: Ditto.
	        * testsuite/gas/i386/noreg32-data16.d: Ditto.
	        * testsuite/gas/i386/noreg32.d: Ditto.
	        * testsuite/gas/i386/noreg64-data16.d: Ditto.
	        * testsuite/gas/i386/noreg64-rex64.d: Ditto.
	        * testsuite/gas/i386/noreg64.d: Ditto.
	        * testsuite/gas/i386/opcode-suffix.d: Ditto.
	        * testsuite/gas/i386/opcode.d: Ditto.
	        * testsuite/gas/i386/x86-64-lfence-load.d: Ditto.
	        * testsuite/gas/i386/x86-64-opcode.d: Ditto.

	opcodes/ChangeLog:

	        * i386-dis.c (OP_I): Make const_1_mode print $1 in AT&T syntax.

2023-12-13  Cui, Lili  <lili.cui@intel.com>

	Clean base_reg and assign correct values to regs for input_output_operand (%dx).
	For special processing of input and output operands (%dx),
	the state of some variables needs to be cleaned.

	gas/ChangeLog:

		* config/tc-i386.c (i386_att_operand): Assign values to regs and
		clean i.base_reg for input output operand (%dx).

2023-12-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-12  Stefano Moioli  <smxdev4@gmail.com>

	gdbserver/win32: fix crash on detach
	this patch fixes a crash in gdbserver whenever a process is detached.
	the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors`

	error message:

	Detaching from process 184
	../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec
	ted.
	remove_process: Assertion `find_thread_process (process) == NULL' failed.

	This application has requested the Runtime to terminate it in an unusual way.
	Please contact the application's support team for more information.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-12  Hannes Domani  <ssbssa@yahoo.de>

	Fix gdb.FinishBreakpoint when returning to an inlined function
	Currently, when creating a gdb.FinishBreakpoint in a function
	called from an inline frame, it will never be hit:
	```
	(gdb) py fb=gdb.FinishBreakpoint()
	Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
	(gdb) c
	Continuing.
	Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list.
	[Inferior 1 (process 1208) exited normally]
	```

	The reason is that the frame_id of a breakpoint has to be the
	ID of a real frame, ignoring any inline frames.

	With this fixed, it's working correctly:
	```
	(gdb) py fb=gdb.FinishBreakpoint()
	Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
	(gdb) c
	Continuing.

	Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47
	(gdb) py print(fb.return_value)
	-8
	```

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-12  Hannes Domani  <ssbssa@yahoo.de>

	Support dynamically computed convenience variables in get_internalvar_integer
	When using $_thread in info threads to showonly the current thread,
	you get this error:
	```
	(gdb) info thread $_thread
	Convenience variable must have integer value.
	Args must be numbers or '$' variables.
	```

	It's because $_thread is a dynamically computed convenience
	variable, which isn't supported yet by get_internalvar_integer.

	Now the output looks like this:
	```
	(gdb) info threads $_thread
	  Id   Target Id           Frame
	* 1    Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-12  Georg-Johann Lay  <avr@gjlay.de>

	Support rodata in flash for more AVR devices
	  PR 31124
	  * Makefile.am (ALL_EMULATION_SOURCES): Add eavrxmega2_flmap.c and eavrxmega4_flmap.c.
	  * Makefile.in: Regenerate.
	  * configure.tgt: Add eavrxmega2_flmap and eavrxmega4_flmap to avr's targ_extra_emuls list.
	  * emulparams/avrxmega2.sh (MAYBE_FLMAP): Define.
	  * emulparams/avrxmega2_flmap.sh: New file.
	  * emulparams/avrxmega4.sh (MAYBE_FLMAP): Define.
	  * emulparams/avrxmega4_flmap.sh: New file.
	  * scripttempl/avr.sc: Add support for HAVE_FLMAP.

2023-12-12  Nick Clifton  <nickc@redhat.com>

	Fix whitespace snafu in tc-riscv.c

2023-12-12  Rui Ueyama  <rui314@gmail.com>

	RISC-V: Emit R_RISCV_RELAX for the la/lga pseudo instruction
	Some psABIs define a relaxation to turn a GOT load into a PC-relative
	address materialization.  For example, the AArch64's psABI allows
	adrp+ldr to be rewritten to nop+adr to eliminate the memory load.
	This patch is part of the effort to make such optimization possible
	for RISC-V.

	For RISC-V, we use the la assembly pseudo instruction to load a symbol
	address from the GOT. The pseudo instruction is expanded to auipc+ld.
	If the address loaded by the instruction pair is actually a PC-relative
	link-time constant, we want the linker to rewrite the instruction pair
	with auipc+addi.

	We can't rewrite all existing auipc+ld pairs with auipc+addi in the
	linker because there might be code that jumps to the middle of the
	instruction pair.  That should be extremely rare, if ever exists, but
	you can at least in theory write a program in assembly that jumps to
	the ld instruction of the instruction pair.  We need a marker to
	identify that an auipc+ld can be safely relaxed (i.e. they are emitted
	for la).

	This patch is to annotate R_RISCV_GOT_HI20 with R_RISCV_RELAX only
	when the relocation is emitted for the la pseudo instruction.  The
	linker will use it as a signal that the instruction pair can be safely
	relaxed.

	Proposal to the RISC-V psABI:
	https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/397

	gas/
		* config/tc-riscv.c (source_macro): New static int variable.
		The identifier of the assembler macro we are expanding, if any.
		(append_insn): Updated source_macro to tc_fix_data, to record
		which macro expands, if any.
		(macro): Record which macro expands into source_macro.  Reset
		source_macro to -1 at the end.
		(md_apply_fix): Apply R_RISCV_RELAX if pcrel_got_hi is expanded
		from macro LA/LGA.
		* config/tc-riscv.h (struct riscv_fix, TC_FIX_TYPE, TC_INIT_FIX_DATA):
		Defined to record source_macro into fixups for riscv target.
		* testsuite/gas/riscv/la-variants.d: Updated.

2023-12-12  Lifang Xia  <lifang_xia@linux.alibaba.com>

	RISC-V: Resolve PCREL_HI20/LO12_I/S fixups with local symbols while `-mno-relax'
	In the scenario of generating .ko files, the kernel does not relax the .ko
	files.  However, due to the large amount of relax and local relocation
	information, this increases the size of the .ko files.  In this patch, it
	will finish the fixup of the local relocations while with `-mno-relax' option.
	This can reduce the size of the relocation table.

	The implemntation is based on the code from bfd/elfnn-riscv.c.  We probably
	can move the code to bfd/elfxx-riscv.c, so that can reduce duplicate code,
	just like what we did for the architecture parser.

	Besides, maybe not only pcrel_hi/lo12 relocation with local symbols can be
	resolved at assembler time.  Other pc-relative relocation, like branch,
	may also be able to perform related optimizations.

	Passed the gcc/binutils regressions of riscv-gnu-toolchain.

	gas/
		* config/tc-riscv.c (riscv_pcrel_hi_reloc): New structure.  Record all
		PC-relative high-part relocation that we have encountered to help us
		resolve the corresponding low-part relocation later.
		(riscv_pcrel_hi_fixup_hash): The hash table to record pcrel_hi fixups.
		(riscv_pcrel_fixup_hash): New function.  Likewise.
		(riscv_pcrel_fixup_eq): Likewise.
		(riscv_record_pcrel_fixup): Likewise.
		(md_begin): Init pcrel_hi hash table.
		(md_apply_fix):  For PCREL_HI20 relocation, do fixup and record
		the pcrel_hi relocs, mark as done while with `-mno-relax'.  For
		PCREL_LO12_I/S relocation, do fixup and mark as done while with
		`-mno-relax'.
		(riscv_md_end): New function.  Free pcrel_hi hash table.
		* config/tc-riscv.h (md_end): Define md_end with riscv_md_end.
	gas/
		* testsuite/gas/riscv/fixup-local*: New tests.

2023-12-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Implement DAP cancellation
	This implements DAP cancellation.  A new object is introduced that
	handles the details of cancellation.  While cancellation is inherently
	racy, this code attempts to make it so that gdb doesn't inadvertently
	cancel the wrong request.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Catch KeyboardInterrupt in send_gdb_with_response
	Cancellation will generally be seen by the DAP code as a
	KeyboardInterrupt.  However, this derives from BaseException and not
	Exception, so a small change is needed to send_gdb_with_response, to
	forward the exception to the DAP server thread.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Rename a couple of DAP procs in the testsuite
	This renames a couple of DAP procs in the testsuite, to clarify that
	they are now exported.  The cancellation test will need these.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Introduce gdb.interrupt
	DAP cancellation needs a way to interrupt whatever is happening on
	gdb's main thread -- whether that is the inferior, a gdb CLI command,
	or Python code.

	This patch adds a new gdb.interrupt() function for this purpose.  It
	simply sets the quit flag and lets gdb do the rest.

	No tests in this patch -- instead this is tested via the DAP
	cancellation tests.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Move DAP JSON reader to its own thread
	This changes the DAP server to move the JSON reader to a new thread.
	This is key to implementing request cancellation, as now requests can
	be read while an earlier one is being serviced.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Clean up handling of DAP not-stopped response
	This patch introduces a new NotStoppedException type and changes the
	DAP implementation of "not stopped" to use it.  I was already touching
	some code in this area and I thought this looked a little cleaner.
	This also has the advantage that we can now choose not to log the
	exception -- previously I was sometimes a bit alarmed when seeing this
	in the logs, even though it is harmless.

	Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Simplify DAP stop-reason code
	Now that gdb adds stop-reason details to stop events, we can simplify
	the DAP code to emit correct stop reasons in its own events.  For the
	most part a simple renaming of gdb reasons is sufficient; however,
	"pause" must still be handled specially.

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Emit stop reason details in Python stop events
	This changes Python stop events to carry a "details" dictionary, that
	holds any relevant information about the stop.  The details are
	constructed using more or less the same procedure as is done for MI.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Move py_ui_out to a new header
	This moves the declaration of py_ui_out to a new header, so that it
	can more readily be used by other code.

2023-12-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix $eol regexp usage in some test-cases
	Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced:
	...
	set eol "\[\r\n\]+"
	...
	with the more strict:
	...
	set eol "\r\n"
	...
	in a few test-cases, but didn't update all uses of eol accordingly.

	Fix this in three gdb.ada test-cases.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-11  Tom Tromey  <tom@tromey.com>

	Use TARGET_SYSROOT_PREFIX in more places
	I found some spots using "target:"; I think it's better to use the
	define everywhere, so this changes these to use TARGET_SYSROOT_PREFIX.
	In some spots, is_target_filename is used rather than an explicit
	check.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-11  Tom Tromey  <tromey@adacore.com>

	Add DAP items to NEWS
	Now that DAP is in GDB 14, significant changes to it should be noted
	in NEWS.  This patch adds a note for a fix that's already gone in.  I
	started a new section in NEWS because more changes are coming.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-12-11  Hannes Domani  <ssbssa@yahoo.de>

	Fix dynamic_cast
	PR29011 notes that dynamic_cast does not work correctly if
	classes with virtual methods are involved, some of the results
	wrongly point into the vtable of the derived class:
	```
	(gdb) p vlr
	$1 = (VirtualLeftRight *) 0x162240
	(gdb) p vl
	$2 = (VirtualLeft *) 0x162240
	(gdb) p vr
	$3 = (VirtualRight *) 0x162250
	(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
	$4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
	(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
	$5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
	(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
	$6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
	(gdb) p dynamic_cast<VirtualLeft*>(vlr)
	$7 = (VirtualLeft *) 0x162240
	(gdb) p dynamic_cast<VirtualLeft*>(vl)
	$8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
	(gdb) p dynamic_cast<VirtualLeft*>(vr)
	$9 = (VirtualLeft *) 0x162240
	(gdb) p dynamic_cast<VirtualRight*>(vlr)
	$10 = (VirtualRight *) 0x162250
	(gdb) p dynamic_cast<VirtualRight*>(vl)
	$11 = (VirtualRight *) 0x162250
	(gdb) p dynamic_cast<VirtualRight*>(vr)
	$12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
	```

	For the cases where the dynamic_cast type is the same as the
	original type, it used the ARG value for the result, which in
	case of pointer types was already the dereferenced value.

	And the TEM value at the value address was created with the
	pointer/reference type, not the actual class type.

	With these fixed, the dynamic_cast results make more sense:
	```
	(gdb) p vlr
	$1 = (VirtualLeftRight *) 0x692240
	(gdb) p vl
	$2 = (VirtualLeft *) 0x692240
	(gdb) p vr
	$3 = (VirtualRight *) 0x692250
	(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
	$4 = (VirtualLeftRight *) 0x692240
	(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
	$5 = (VirtualLeftRight *) 0x692240
	(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
	$6 = (VirtualLeftRight *) 0x692240
	(gdb) p dynamic_cast<VirtualLeft*>(vlr)
	$7 = (VirtualLeft *) 0x692240
	(gdb) p dynamic_cast<VirtualLeft*>(vl)
	$8 = (VirtualLeft *) 0x692240
	(gdb) p dynamic_cast<VirtualLeft*>(vr)
	$9 = (VirtualLeft *) 0x692240
	(gdb) p dynamic_cast<VirtualRight*>(vlr)
	$10 = (VirtualRight *) 0x692250
	(gdb) p dynamic_cast<VirtualRight*>(vl)
	$11 = (VirtualRight *) 0x692250
	(gdb) p dynamic_cast<VirtualRight*>(vr)
	$12 = (VirtualRight *) 0x692250
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-11  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1">
	Support symbol names enclosed in double quotation marks.

2023-12-11  Konstantin Isakov  <ikm@zbackup.org>

	bfd_find_nearest_line leaks dwarf_rnglists_buffer
		* dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free dwarf_rnglists_buffer.

2023-12-11  Alan Modra  <amodra@gmail.com>

	regen bfd POTFILES

2023-12-11  Nelson Chu  <nelson@rivosinc.com>

	RISC-V/gas: Clarify the definition of `relaxable' in md_apply_fix
	The `relaxable' in md_apply_fix means if the relocation can be relaxed or not
	in link-time generally.  We can use `.option relax/norelax' to enable/disable
	relaxations for some specific areas, so the value of `riscv_opts.relax'
	will be changed dynamically.  The `fixP->fx_tcbit' records the correct value
	of `riscv_opts.relax' for every relocation.  Therefore, set `relaxable' to
	`riscv_opts.relax' will cause unexpected behavior for the following case,

	.option norelax
	lla a1, foo1
	.option relax
	lla a2, foo2
	.option norelax
	lla a3, foo3

	For the current assembler, the final value of `riscv_opts.relax' is false, so
	the second `lla a2, foo2' won't have R_RISCV_RELAX relocation, but should have.

	gas/
		* config/tc-riscv.c (md_apply_fix): Set the value of `relaxable' to
		`riscv_opts.relax' is wrong.  It should be `true' generally.

2023-12-11  Alan Modra  <amodra@gmail.com>

	R_MICROMIPS_GPREL7_S2
	This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
	match/mask encoding in `micromips_opcodes'.  It is correctly specified
	to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
	and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
	code like _bfd_mips_elf32_gprel16_reloc.

	Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
	is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
	when little-endian.  Big-endian behaviour is unchanged after this
	patch and little-endian correctly applies the reloc to byte 0x11.

	The patch also corrects REL addend extraction from section contents,
	and overflow checking.  gold had all of the bfd problems with this
	reloc and additionally did not apply the rightshift by two.

	bfd/
		* elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
		R_MICROMIPS_GPREL7_S2.
		(mips_elf_calculate_relocation): Correct sign extension and
		overflow calculation for R_MICROMIPS_GPREL7_S2.
		(_bfd_mips_elf_relocate_section): Update small-data overflow
		message.
	gold/
		* mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
		Return false for R_MICROMIPS_GPREL7_S2.
		(Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
		(Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
		handling.
		(Mips_relocate_functions::relgprel7): New function.
		(Target_mips::Relocate::relocate): Adjust to suit.
	ld/
		* testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
		* testsuite/ld-mips-elf/reloc-5.d: Likewise.

2023-12-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-10  Tom Tromey  <tom@tromey.com>

	Fix "not not" in Python documentation
	I noticed a "not not" in the Python documentation where just "not" was
	meant.  This patch fixes the error.

2023-12-10  Tom Tromey  <tom@tromey.com>

	Add some new DW_IDX_* constants
	I've reimplemented the .debug_names code in GDB -- it was quite far
	from being correct, and the new implementation is much closer to what
	is specified by DWARF.

	However, the new writer in GDB needs to emit some symbol properties,
	so that the reader can be fully functional.  This patch adds a few new
	DW_IDX_* constants, and tries to document the existing extensions as
	well.  (My patch series add more documentation of these to the GDB
	manual as well.)

	2023-12-10  Tom Tromey  <tom@tromey.com>

		* dwarf2.def (DW_IDX_GNU_internal, DW_IDX_GNU_external): Comment.
		(DW_IDX_GNU_main, DW_IDX_GNU_language, DW_IDX_GNU_linkage_name):
		New constants.

2023-12-10  Jeff Law  <jeffreyalaw@gmail.com>

	Improve performance of the H8 simulator
	Running the H8 port through the GCC testsuite currently takes 4h 30m on my
	fastest server -- that's roughly 1.5hrs per multilib tested and many tests are
	disabled for various reasons.

	To put that 1.5hr/multilib in perspective, that's roughly 3X the time for other
	embedded targets.  Clearly something isn't working as well as it should.

	A bit of digging with perf shows that we're spending a crazy amount of time
	decoding instructions in the H8 simulator.  It's not hard to see why --
	basically we take a blob of instruction data, then try to match it to every
	instruction in the H8 opcode table starting at the beginning.  That table has
	~8000 entries (each different addressing mode is considered a different
	instruction in the table).

	Naturally my first thought was to sort the table and use a binary search to
	find the right entry.  That's made excessively complex due to the encoding on
	the H8.  Just getting the sort right would be much more complex than I'd
	consider advisable.

	Another thought was to build a mapping to the right entry for all the
	instructions that can be disambiguated based on the first nibble (4 bits) of
	instruction data and a mapping for those which can be disambiguated based on
	the first byte of instruction data.

	That seemed feasible until I realized that the H8/SX did some truly horrid
	things with encoding branches in the 0x4XYY opcode space.  It uses an "always
	zero" bit in the offset to encode new semantic information.  So we can't select
	on just 0x4X.  Ugh!

	We could always to a custom decoder.  I've done several through the years, they
	can be very fast.  But no way I can justify the time to do that.

	So what I settled on was to first sort the opcode table by the first nibble,
	then find the index of the first instruction for each nibble. Decoding uses
	that index to start its search.  This cuts the overall build/test by more than
	half.

	Next I adjusted the sort so that instructions that are not available on the
	current sub architecture are put at the end of the table.   This shaves another
	~15% off the total cycle time.

	The net of the two changes is on my fastest server we've gone from 4:30 to 1:40
	running the GCC testsuite.  Same test results before/after, of course.  It's
	still not fast, but it's a hell of a lot better.

2023-12-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Handle shared border in fixed-sized layout
	In tui_layout_split::apply I noticed that for variable-size layouts we take
	share_box into account by decreasing used_size:
	...
	          used_size += info[i].size;
	          if (info[i].share_box)
		    --used_size;
	...
	but not for fixed-size layouts:
	...
	      if (info[i].min_size == info[i].max_size)
		available_size -= info[i].min_size;
	...

	Fix this by increasing available_size for fixed-size layouts with shared box.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Show focus window in status line
	The focused window is highlighted by using active-border-kind instead of
	border-kind.

	But if the focused window is the cmd window (which is an unboxed window), then
	no highlighting is done, and it's not obvious from looking at the screen which
	window has the focus.  Instead, you have to notice the absence of highlighting
	on boxed windows, and then infer that the focus is on the unboxed window.

	That approach stops working if there are multiple unboxed windows.

	Likewise if highlighting is switched off by setting active-border-kind to the
	same value as border-kind.

	Make it more explicit which window has the focus by mentioning it in the status
	window, like so:
	...
	native process 8282 (src) In: main                      L7    PC: 0x400525
	...

	Tested on x86_64-linux and ppc64le-linux.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Hannes Domani  <ssbssa@yahoo.de>

	Fix printing of global variable stubs if no inferior is running
	Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
	to print a global variable stub without a running inferior, because of
	a missing nullptr-check (the block_scope function took care of that
	check before it was converted to a method).

	With this check it works again:
	```
	(gdb) print s
	$1 = <incomplete type>
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: tighten up some end-of-line patterns
	Following on from the previous commit, I searched the testsuite for
	places where we did:

	  set eol "<some pattern>"

	in most cases the <some pattern> could be replaced with "\r\n" though
	in the stabs test I've switched to using the multi_line proc as that
	seemed like a better choice.

	In gdb.ada/info_types.exp I did need to add an extra use of $eol as
	the previous pattern would match multiple newlines, and in this one
	place we were actually expecting to match multiple newlines.  The
	tighter pattern only matches a single newline, so we now need to be
	explicit when multiple newlines are expected -- I think this is a good
	thing.

	All the tests are still passing for me after these changes.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix gdb.ada/complete.exp timeout in READ1 mode
	While reviewing another patch I spotted a timeout in
	gdb.ada/complete.exp when testing in READ1 mode, e.g.:

	  $ make check-read1 TESTS="gdb.ada/complete.exp"
	  ...
	  FAIL: gdb.ada/complete.exp: complete break ada (timeout)
	  ...

	The problem is an attempt to match the entire output from GDB within a
	single gdb_test_multiple pattern, for a completion command that
	returns a large number of completions.

	This commit changes the gdb_test_multiple to process the output line
	by line.  I don't use the gdb_test_multiple -lbl option, as I've
	always found that option backward -- it checks for the \r\n at the
	start of each line rather than the end, I think it's much clearer to
	use '^' at the start of each pattern, and '\r\n' at the end, so that's
	what I've done here.

	.... Or I would, if this test didn't already define $eol as the end of
	line regexp ... except that $eol was set to '[\r\n]*', which isn't
	that helpful, so I've updated $eol to be just '\r\n' the actual end of
	line regexp.

	And now, the test passes without a timeout when using READ1.

	There should be no change in what is tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use
	Building on the last commit, which added a general --debug=COMPONENT
	option to the gdbserver command line, this commit updates the monitor
	command to allow for general:

	  (gdb) monitor set debug COMPONENT off|on

	style commands.  Just like with the previous commit, the COMPONENT can
	be any one of all, threads, remote, event-loop, and correspond to the
	same set of global debug flags.

	While on the command line it is possible to do:

	  --debug=remote,event-loop,threads

	the components have to be entered one at a time with the monitor
	command.  I guess there's no reason why we couldn't allow component
	grouping within the monitor command, but (to me) what I have here
	seemed more in the spirit of GDB's existing 'set debug ...' commands.
	If people want it then we can always add component grouping later.

	Notice in the above that I use 'off' and 'on' instead of '0' and '1',
	which is what the 'monitor set debug' command used to use.  The 0/1
	can still be used, but I now advertise off/on in all the docs and help
	text, again, this feels more inline with GDB's existing boolean
	settings.

	I have removed the two existing monitor commands:

	  monitor set remote-debug 0|1
	  monitor set event-loop-debug 0|1

	These are replaced by:

	  monitor set debug remote off|on
	  monitor set debug event-loop off|on

	respectively.

	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-12-08  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: allow the --debug command line option to take a value
	Currently, gdbserver has the following command line options related to
	debugging output:

	  --debug
	  --remote-debug
	  --event-loop-debug

	This doesn't scale well.  If I want an extra debug component I need to
	add another command line flag.

	This commit changes --debug to take a list of components.

	The currently supported components are: all, threads, remote, and
	event-loop.  The 'threads' component represents the debug we currently
	get from the --debug option.  And if --debug is used without a
	component list then the threads component is assumed as the default.

	Currently the threads component actually includes a lot of output that
	is not really threads related.  In the future I'd like to split this
	up into some new, separate components.  But that is not part of this
	commit, or even this series.

	The special component 'all' does what you'd expect: enables debug
	output from all supported components.

	The component list is parsed left to write, and you can prefix a
	component with '-' to disable that component, so I can write:

	  target> gdbserver --debug=all,-event-loop

	to get debug for all components except the event-loop component.

	I've removed the existing --remote-debug and --event-loop-debug
	command line options, these are equivalent to --debug=remote and
	--debug=event-loop respectively, or --debug=remote,event-loop to
	enable both components.

	In this commit I've only update the command line options, in the next
	commit I'll update the monitor commands to support a similar
	interface.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables
	The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
	flags, which can be passed to make in order to enable debugging within
	GDB or gdbserver respectively.

	However, when I do:

	  make check-gdb GDB_DEBUG=infrun

	I don't see the corresponding debug feature within GDB being enabled.
	Nor does:

	  make check-gdb GDBSERVER_DEBUG=debug  \
	       RUNTESTFLAGS="--target_board=native-extended-gdbserver"

	Appear to enable gdbserver debugging.

	I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
	missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile.  This
	variable already contains lots of testing related flags, like
	RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
	GDBSERVER_DEBUG here too.

	With this done, this debug feature is now working as expected.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Hannes Domani  <ssbssa@yahoo.de>

	Use pretty printers for struct member stubs
	PR29079 shows that pretty printers can be used for an incomplete
	type (stub), but only when printing it directly, not if it's
	part of another struct:
	```
	(gdb) p s
	$1 = {pp m_i = 5}
	(gdb) p s2
	$2 = {m_s = <incomplete type>, m_l = 20}
	```

	The reason is simply that in common_val_print the check for stubs
	is before any pretty printer is tried.
	It works if the pretty printer is tried before the stub check:
	```
	(gdb) p s
	$1 = {pp m_i = 5}
	(gdb) p s2
	$2 = {m_s = {pp m_i = 10}, m_l = 20}
	```

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix displaying main after resizing
	A TUI src window is displaying either:
	- the source for the current frame,
	- the source for main, or
	- the string "[ No Source Available ]".

	Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
	we're able to resize the TUI to 1 line without crashing.

	I noticed that if TUI is displaying main, and we resize to 1 line (destroying
	the src window) and then back to a larger terminal (reconstructing the src
	window), the TUI displays "[ No Source Available ]" instead of main.

	Fix this by moving the responsibility for showing main from tui_enable to
	tui_source_window_base::rerender.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Tom Tromey  <tom@tromey.com>

	Allow cast of 128-bit integer to pointer
	PR rust/31082 points out that casting a 128-bit integer to a pointer
	will fail.  This happens because a case in value_cast was not
	converted to use GMP.

	This patch fixes the problem.  I am not really sure that testing
	against the negative value here makes sense, but I opted to just
	preserve the existing behavior rather than change it.

	Regression tested on x86-64 Fedora 38.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082

2023-12-08  Tom Tromey  <tom@tromey.com>

	Fix dynamic type resolution for LOC_CONST and LOC_CONST_BYTES symbols
	PR rust/31005 points out that dynamic type resolution of a LOC_CONST
	or LOC_CONST_BYTES symbol will fail, leading to output like:

	    from_index=<error reading variable: Cannot access memory at address 0x0>

	This patch fixes the problem by using the constant value or bytes when
	performing type resolution.

	Thanks to tpzker@thepuzzlemaker.info for a first version of this
	patch.

	I also tested this on a big-endian PPC system (cfarm203).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005

2023-12-08  Guinevere Larsen  <blarsen@redhat.com>

	gdb: Guarantee that an SAL's end is right before the next statement
	When examining a failure that happens when testing
	gdb.python/py-symtab.c with clang, I noticed that it was going wrong
	because the test assumed that whenever we get an SAL, its end would
	always be right before statement in the line table. This is true for GCC
	compiled binaries, since gcc only adds statements to the line table, but
	not true for clang compiled binaries.

	This is the second time I run into a problem where GDB doesn't handle
	non-statement line table entries correctly. The other was eventually
	committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
	behavior with trailing !is_stmt lines", but that commit only changes the
	behavior for the 'until' command. In this patch I propose a more general
	solution, making it so every time we generate the SAL for a given pc, we
	set the end of the SAL to before the next statement or the first
	instruciton in the next line, instead of naively assuming that to be the
	case.

	With this new change, the edge case is removed from the processing of
	the 'until' command without regressing the accompanying test case, and
	no other regressions were observed in the testsuite.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-08  Mike Frysinger  <vapier@gentoo.org>

	sim: aarch64: fix -Wunused-but-set-variable warnings

	sim: common: fix -Wunused-but-set-variable warnings

	sim: ppc: fix -Wunused-but-set-variable warnings

	sim: v850: fix -Wunused-but-set-variable warnings

	sim: sh: fix -Wunused-but-set-variable warnings

	sim: msp430: fix -Wunused-but-set-variable warnings

	sim: mips: fix -Wunused-but-set-variable warnings

	sim: mcore: fix -Wunused-but-set-variable warnings

	sim: m68hc11: fix -Wunused-but-set-variable warnings

	sim: h8300: fix -Wunused-but-set-variable warnings

	sim: ft32: fix -Wunused-but-set-variable warnings

	sim: frv: fix -Wunused-but-set-variable warnings

	sim: erc32: fix -Wunused-but-set-variable warnings

	sim: d10v: fix -Wunused-but-set-variable warnings

	sim: cris: fix -Wunused-but-set-variable warnings
	We suppress the warning in the generated switch file because the cris
	cpu file has a hack to workaround a cgen bug, but that generates a set
	but unused variable which makes the compiler upset.

	sim: bfin: fix -Wunused-but-set-variable warnings

	sim: bfin: gui: fix -Wunused-but-set-variable warnings
	Rework the code to use static inline functions when it's disabled
	rather than macros so the compiler knows the various function args
	are always used.  The ifdef macros are a bit ugly, but get the job
	done without duplicating the function prototypes.

	sim: arm: fix -Wunused-but-set-variable warnings

	sim: m32r: fix syslog call
	The function returns void, not int.  We only pass one argument to
	syslog (the format), so use %s as the static format instead since
	the emulation layer doesn't handle passing additional arguments.

2023-12-08  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: include more glibc headers for the funcs we use [PR sim/29752]
	Not exactly portable, but doesn't make the situation worse here, and
	fixes a lot of implicit function warnings.

	Bug: https://sourceware.org/PR29752

2023-12-08  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: add more cgen prototypes for traps
	The traps file uses a bunch of functions directly without prototypes,
	and we can't safely include the relevant cpu*.h files for them.

2023-12-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-07  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: add more cgen prototypes to enable -Werror in most files

2023-12-07  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: disable -Wenum-conversion fow now [PR sim/29752]
	The cgen code mixes virtual insn enums with insn enums, and there isn't
	an obvious (to me) way to unravel this atm, so disable the warning.

	sim/lm32/decode.c:45:5: error:
		implicit conversion from enumeration type 'CGEN_INSN_VIRTUAL_TYPE'
		to different enumeration type 'CGEN_INSN_TYPE' (aka 'enum cgen_insn_type')
		[-Werror,-Wenum-conversion]
	   45 |   { VIRTUAL_INSN_X_INVALID, LM32BF_INSN_X_INVALID, LM32BF_SFMT_EMPTY },
	      |   ~ ^~~~~~~~~~~~~~~~~~~~~~

	Bug: https://sourceware.org/PR29752

2023-12-07  Cupertino Miranda  <cupertino.miranda@oracle.com>

	gdb/record: Support for rdtscp in i386_process_record.
	This patch adds support for process recording of the instruction rdtscp in
	x86 architecture.
	Debugging applications with "record full" fail to record with the error
	message "Process record does not support instruction 0xf01f9".

	Approved-by: Guinevere Larsen <blarsen@redhat.com>

2023-12-07  Mike Frysinger  <vapier@gentoo.org>

	sim: support dlopen in -lc
	Stop assuming that dlopen is only available via -ldl.  Newer versions
	of glibc have merged it into -lc which broke this configure test.

	sim: cris: move generated file to right place
	Not sure why this ended up in the topdir, but it belongs under cris/.

	sim: warnings: add more flags
	Sync with the list of flags from gdbsupport, and add a few more of
	our own to catch recent issues.  Comment out the C++-specific flags
	as we don't build with C++.

2023-12-07  Kevin Buettner  <kevinb@redhat.com>

	Add more 'step' tests to gdb.base/watchpoint.exp
	The test gdb.base/watchpoint.exp has a proc named 'test_stepping'
	which claims to "Test stepping and other mundane operations with
	watchpoints enabled".  It sets a watchpoint on ival2, performs an
	inferior function call (which is not at all mundane), and uses 'next',
	'until', and, finally, does a 'step'.

	However, that final 'step' command steps to (but not over/through) the
	line at which the assignment to ival2 takes place.  At no time while
	performing these operations is a watchpoint hit.

	This commit adds a test to see what happens when stepping over/through
	the assignment to ival2.  The watchpoint on ival2 should be triggered
	during this step.  I've added another 'step' to make sure that the
	correct statement is reached after performing the watchpoint-hitting
	step.

	After running the 'test_stepping' proc, gdb.base/watchpoint.exp does
	a clean_restart before doing further tests, so nothing depends upon
	'test_stepping' to stop at the particular statement at which it had
	been stopping.

	I've examined all tests which set watchpoints and step.  I haven't
	been able to identify a(nother) test case which tests what happens
	when stepping over/through a statement which triggers a watchpoint.
	Therefore, adding these new 'step' tests is testing something which
	hasn't being tested elsewhere.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-12-07  Palmer Dabbelt  <palmer@rivosinc.com>

	RISC-V: Fix "withand" in LEB128 error messages
	This was split over multiple lines and ended up missing a space.

	Reported-by: David Abdurachmanov <davidlt@rivosinc.com>

2023-12-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-06  Hannes Domani  <ssbssa@yahoo.de>

	Fix DLL export forwarding
	I noticed it when I was trying to set a breakpoint at ExitProcess:
	```
	(gdb) b ExitProcess
	Breakpoint 1 at 0x14001fdd0
	(gdb) r
	Starting program: C:\qiewer\heob\heob64.exe
	Warning:
	Cannot insert breakpoint 1.
	Cannot access memory at address 0x3dbf4120
	Cannot insert breakpoint 1.
	Cannot access memory at address 0x77644120
	```

	The problem doesn't exist in gdb 13.2, and the difference can easily be
	seen when printing ExitProcess.
	gdb 14.1:
	```
	(gdb) p ExitProcess
	$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
	```
	gdb 13.2:
	```
	(gdb) p ExitProcess
	$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
	```

	The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
	where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
	relative to DLL_NAME before.

	Fixed by calculating VMA relative to DLL_NAME again.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-06  Tom Tromey  <tromey@adacore.com>

	Fix minor grammar error in gdb.texinfo
	This fixes a small grammar issue in gdb.texinfo -- "additional" was
	written where "additionally" is correct.

	Remove quick_symbol_functions::expand_matching_symbols
	The only caller of quick_symbol_functions::expand_matching_symbols was
	removed, so now this method and all implementations of it can be
	removed.

	Remove split_style::UNDERSCORE
	The recent changes to the way Ada names are matched means that
	split_style::UNDERSCORE is no longer used.  This patch removes it.

2023-12-06  Tom Tromey  <tromey@adacore.com>

	Always use expand_symtabs_matching in ada-lang.c
	The previous patch fixed the immediate performance problem with Ada
	name matching, by having a subset of matches call
	expand_symtabs_matching rather than expand_matching_symbols.  However,
	it seemed to me that expand_matching_symbols should not be needed at
	all.

	To achieve this, this patch changes ada_lookup_name_info::split_name
	to use the decoded name, rather than the encoded name.  In order to
	make this work correctly, a new decoded form is used: one that does
	not decode operators (this is already done) and also does not decode
	wide characters.  The latter change is done so that changes to the Ada
	source charset don't affect the DWARF index.

	With this in place, we can change ada-lang.c to always use
	expand_symtabs_matching rather than expand_matching_symbols.

2023-12-06  Tom Tromey  <tromey@adacore.com>

	Improve performance of Ada name searches
	A user reported that certain operations -- like printing a large
	structure -- could be slow.  I tracked this down to
	ada-lang.c:map_matching_symbols taking an inordinate amount of time.
	Specifically, calls like the one to look for a parallel "__XVZ"
	variable, in ada_to_fixed_type_1, could result in gdb walking over all
	the entries in the cooked index over and over.

	Looking into this reveals that
	cooked_index_functions::expand_matching_symbols is not written
	efficiently -- it ignores its "ordered_compare" parameter.  While
	fixing this would be good, it turns out that this entire method isn't
	needed; so this series removes it.

	However, the deletion is not done in this patch.  This one, instead,
	fixes the immediate cause of the slowdown, by using
	objfile::expand_symtabs_matching when possible.  This approach is
	faster because it is more selective about which index entries to
	examine.

2023-12-06  Tom Tromey  <tom@tromey.com>

	Start abbrevs at 1 in DWARF assembler
	I noticed that the DWARF assembler starts abbrevs at 2.
	I think 1 should be preferred.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>

2023-12-06  Hannes Domani  <ssbssa@yahoo.de>

	Fix hardware watchpoints in replay mode
	Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
	caused a regression that meant hardware watchpoint stops would not
	trigger in reverse execution or replay mode.  This was documented in
	PR breakpoints/21969.
	The problem is that record_check_stopped_by_breakpoint always overwrites
	record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
	value which would be checked afterwards.

	This commit fixes that by not overwriting the stop-reason in
	record_full_stop_reason if we're not stopped at a breakpoint.

	And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
	tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
	doesn't convert enabled watchpoints to use hardware.
	This is fixed by disabling said watchpoint while enabling hw watchpoints.
	The same is not done for gdb.reverse/watch-precsave.exp, since it's not
	possible to use hw watchpoints in restored recordings anyways.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969
	Approved-by: Guinevere Larsen <blarsen@redhat.com>

2023-12-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix libstdc++ assert caused by invalid use of std::clamp
	After this commit:

	  commit 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2
	  Date:   Mon Dec 4 14:23:17 2023 +0000

	      gdb: Enable early init of thread pool size

	I am now seeing this assert from libstdc++:

	  /usr/include/c++/9/bits/stl_algo.h:3715: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed.

	This may only be visible because I compile with:

	  -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1

	but I haven't checked.  The issue the assert is highlighting is real,
	and is caused by this block of code:

	  if (n_threads < 0)
	    {
	      const int hardware_threads = std::thread::hardware_concurrency ();
	      /* Testing in #29959 indicates that parallel efficiency drops between
	         n_threads=5 to 8.  Therefore, clamp the default value to 8 to avoid an
	         excessive number of threads in the pool on many-core systems.  */
	      const int throttle = 8;
	      n_threads = std::clamp (hardware_threads, hardware_threads, throttle);
	    }

	The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if
	we have more than 8 hardware threads available the LOW will be greater
	than the HIGH, which is triggering the assert I see above.

	I believe std::clamp is the wrong tool to use here.  Instead std::min
	would be a better choice; we want the smaller value of
	HARDWARE_THREADS or THROTTLE.  If h/w threads is 2, then we want 2,
	but if h/w threads is 16 we want 8, this is what std::min gives us.

	After this commit, I no longer see the assert.

2023-12-06  Tom de Vries via Gdb-patches  <gdb-patches@sourceware.org>

	[gdb/symtab] Redo "Fix assert in set_length"
	This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
	to a regression reported in PR29572, and implements a different fix for PR29453.

	The fix is to not use the CU table in a .debug_names section to construct
	all_units, but instead use create_all_units, and then verify the CU
	table from .debug_names.  This also fixes PR25969, so remove the KFAIL.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969

2023-12-06  Mike Frysinger  <vapier@gentoo.org>

	sim: warnings: sync some build logic from gdbsupport
	This fixes testing of -Wno flags, and adds some more portable ones.

2023-12-06  Alan Modra  <amodra@gmail.com>

	PR31096, nm shows 32bit addresses as 64bit addresses
	Prior to commit 0e3c1eebb2 nm output depended on the host unsigned
	long when printing "negative" symbol values for 32-bit targets.
	Commit 0e3c1eebb22 made the output match that seen with a 64-bit host
	unsigned long.  The fact that nm output changed depending on host is
	of course a bug, but it is reasonable to expect 32-bit target output
	is only 32 bits.  So this patch makes 32-bit target output the same as
	it was on 32-bit hosts prior to 0e3c1eebb2.

		PR 31096
		* nm.c (print_format_string): Make it a static buffer.
		(get_print_format): Merge into..
		(set_print_format): ..this, renamed from set_print_width.  When
		print_width is 32, set up print_format_string for an int32_t
		value.  Don't malloc print_format_string.  Adjust calls.
		(print_value): Correct printing of 32-bit values.

2023-12-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-05  Jakub Jelinek  <jakub@redhat.com>

	libiberty: Fix build with GCC < 7
	Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
	In configure I've tried to use everything actually used in the sha1.c
	x86 hw implementation, but unfortunately I forgot about implicit function
	declarations.  GCC before 7 did have <cpuid.h> header and bit_SHA define
	and __get_cpuid function defined inline, but it didn't define
	__get_cpuid_count, which compiled fine (and the configure test is
	intentionally compile time only) due to implicit function declaration,
	but then failed to link when linking the linker, because
	__get_cpuid_count wasn't defined anywhere.

	The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
	to make sure the functions are declared.

	2023-12-05  Jakub Jelinek  <jakub@redhat.com>

		* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and
		__get_cpuid_count are not implicitly declared.
		* configure: Regenerated.

2023-12-05  Hannes Domani  <ssbssa@yahoo.de>

	Fix breakpoints on symbols with multiple trampoline symbols
	On mingw targets it's possible that there are multiple trampoline
	symbols for __cxa_throw, in each module where a throw is done, but
	without a corresponding global symbol.
	Since commit 77f2120b200be6cabbf6f610942fc1173a8df6d3 they cancel each
	other out in search_minsyms_for_name, which makes it impossible to set
	a breakpoint there:

	(gdb) b __cxa_throw
	Function "__cxa_throw" not defined.
	Make breakpoint pending on future shared library load? (y or [n]) y
	Breakpoint 2 (__cxa_throw) pending.
	(gdb) c
	Continuing.
	[Inferior 1 (process 10004) exited with code 03]

	With catch throw it also doesn't work, and you don't even get an error
	message:

	(gdb) catch throw
	Catchpoint 2 (throw)
	(gdb) c
	Continuing.
	[Inferior 1 (process 5532) exited with code 03]
	(gdb)

	The fix is to simply ignore other trampoline symbols when looking for
	corresponding global symbols, and it's working as expected:

	(gdb) b __cxa_throw
	Breakpoint 2 at 0x13f091590 (2 locations)
	(gdb) c
	Continuing.

	Breakpoint 2.1, 0x000000013f091590 in __cxa_throw ()
	(gdb)

	And catch throw also works again:

	(gdb) catch throw
	Catchpoint 2 (throw)
	(gdb) c
	Continuing.

	Catchpoint 2.1 (exception thrown), 0x000000013f181590 in __cxa_throw ()
	(gdb)

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29548
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-05  Richard Bunt  <richard.bunt@linaro.org>

	gdb/testsuite: Update worker thread show assertion
	Commit 33ae45434d0 updated the text reported by GDB when showing the
	number of worker threads. However, it neglected to update the assertions
	using this text, which caused index-file.exp to fail. This commit
	corrects this omission.

	Tested index-file.exp is fixed on my local machine.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-05  Tom Tromey  <tromey@adacore.com>

	Remove some DAP helper functions
	Now that DAP requests are normally run on the gdb thread, some DAP
	helper functions are no longer needed.  Removing these simplifies the
	code.

2023-12-05  Nick Clifton  <nickc@redhat.com>

	Fix: strip --strip-debug breaks relocations
	  PR 31106
	  * elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation.

2023-12-05  Tom Tromey  <tom@tromey.com>

	Fix off-by-one error in compute_delayed_physnames
	compute_delayed_physnames does this:

		  size_t len = strlen (physname);
	...
		      if (physname[len] == ')') /* shortcut */
			break;

	However, physname[len] will always be \0.

	This patch changes it to the correct len-1.

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: mips: fix sim_fpu usage
	Fix some of the sim_fpu calls to use the right types.  While I'm
	not familiar with the MIPS ISA in these cases, these look like
	simple oversights due to the name/type mismatches.  This at least
	fixes compiling with -Wenum-conversion.

	sim: sh: trim trailing whitespace in generated code
	No functional change here, but makes it a little easier to read the
	generated code when editors aren't highlighting all the spurious
	trailing whitespace on lines.

	sim: mn10300: fix sim_engine_halt call
	The sim_stop argument is an enum and should only be one of those
	values, not a signal constant.  Fix the logic to pass the right
	sim_xxx & SIM_xxx values in the right arguments.

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: m32c: use UTF-8 encoding
	We only support UTF-8 nowadays, so stop using ISO-8859-1.

	Maybe we should delete this logic entirely, but for now,
	do the bare min conversion to keep it compiling.

2023-12-05  Andreas Schwab  <schwab@suse.de>

	Add basic support for RISC-V 64-bit EFI objects
	This adds a new PEI target pei-riscv64-little.  Only objdump and objcopy
	are supported.

	bfd:
		* .gitignore: Add pe-riscv64igen.c.
		* Makefile.am (BFD64_BACKENDS): Add pei-riscv64.lo,
		pe-riscv64igen.lo.
		(BFD64_BACKENDS_CFILES): Add pei-riscv64.c.
		(BUILD_CFILES): Add pe-riscv64igen.c.
		(pe-riscv64igen.c): New rule.
		* Makefile.in: Regenerate.
		* bfd.c (bfd_get_sign_extend_vma): Add pei-riscv64-little.
		* coff-riscv64.c: New file.
		* coffcode.h (coff_set_arch_mach_hook, coff_set_flags)
		(coff_write_object_contents): Add riscv64 (riscv64_pei_vec)
		support.
		* config.bfd (targ_selvecs): Add riscv64_pei_vec to all riscv*
		targets.
		* configure.ac: Handle riscv64_pei_vec.
		* configure: Regenerate.
		* libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE)
		(GET_OPTHDR_SIZE_OF_STACK_RESERVE)
		(PUT_OPTHDR_SIZE_OF_STACK_RESERVE)
		(GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT)
		(GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE)
		(GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT)
		(GET_PDATA_ENTRY, _bfd_XX_bfd_copy_private_bfd_data_common)
		(_bfd_XX_bfd_copy_private_section_data)
		(_bfd_XX_get_symbol_info, _bfd_XX_only_swap_filehdr_out)
		(_bfd_XX_print_private_bfd_data_common)
		(_bfd_XXi_final_link_postscript, _bfd_XXi_only_swap_filehdr_out)
		(_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out)
		(_bfd_XXi_swap_aux_in, _bfd_XXi_swap_aux_out)
		(_bfd_XXi_swap_lineno_in, _bfd_XXi_swap_lineno_out)
		(_bfd_XXi_swap_scnhdr_out, _bfd_XXi_swap_sym_in)
		(_bfd_XXi_swap_sym_out, _bfd_XXi_swap_debugdir_in)
		(_bfd_XXi_swap_debugdir_out, _bfd_XXi_write_codeview_record)
		(_bfd_XXi_slurp_codeview_record) [COFF_WITH_peRiscV64]: Define.
		(_bfd_peRiscV64_print_ce_compressed_pdata): Declare.
		* peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out)
		(_bfd_XXi_swap_scnhdr_out, pe_print_pdata)
		(_bfd_XX_print_private_bfd_data_common)
		(_bfd_XX_bfd_copy_private_section_data)
		(_bfd_XXi_final_link_postscript): Support COFF_WITH_peRiscV64.
		* pei-riscv64.c: New file.
		* peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd)
		(pe_ILF_object_p): Support COFF_WITH_peRiscV64.
		(jtab): Add dummy entry that traps.
		* targets.c (_bfd_target_vector): Add riscv64_pei_vec.

	binutils:
		* testsuite/binutils-all/riscv/pei-riscv64.d: New.
		* testsuite/binutils-all/riscv/pei-riscv64.s: New.

	include:
		* coff/riscv64.h: New file.
		* coff/pe.h (IMAGE_FILE_MACHINE_RISCV32)
		(IMAGE_FILE_MACHINE_RISCV64): Define.

2023-12-05  Alan Modra  <amodra@gmail.com>

	alpha_ecoff_get_relocated_section_contents buffer overflow
	This is aimed at fixing holes in two alpha-ecoff relocation functions
	that access section contents without first bounds checking offsets.
	I've also rewritten ALPHA_R_OP_STORE handling to support writing to
	the bytes near the end of the section.

		* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't
		bother checking ALPHA_R_LITERAL insn.  Range check before reading
		contents for ALPHA_R_GPDISP, and simplify handling.  Rewrite
		ALPHA_R_OP_STORE handling.  Correct error callback args.
		(alpha_relocate_section): Similarly.  Don't abort, report errors.

2023-12-05  Alan Modra  <amodra@gmail.com>

	memory leak in display_debug_addr
		* dwarf.c (display_debug_addr): Free dummy debug_addr_info entry.
		Don't return without freeing debug_addr_info on error paths.

2023-12-05  Alan Modra  <amodra@gmail.com>

	Don't use free_contents in _bfd_elf_slurp_version_tables
	In commit 7ac6d0c38c36 I made more use of free_contents in
	_bfd_elf_slurp_version_tables, a variable added to tag the case where
	raw verneed and verdefs have been read locally by the function, and
	thus should be freed before returning.  In retrospect it may have been
	better to do without the extra variable entirely.  It's easy to infer
	when "contents" should be freed, costing a little extra on an error
	path but costing less elsewhere.

		* elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents.

2023-12-05  Peter Jones  <pjones@redhat.com>

	Handle "efi-app-riscv64" and similar targets in objcopy.
	This adds the efi target name handling for riscv64 to objcopy.

	binutils:
		* binutils/objcopy.c: add riscv64 handling to
		  convert_efi_target()

	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: rx: mark unused static var as unused
	This seems like a useful utility func that mirrors the int2float
	helper, so mark it as unused rather than delete.

	sim: rx: constify some read-only global vars

	sim: warnings: enable only for development builds
	Reuse the bfd/development.sh script like most other project to
	determine whether the current source tree is a dev build (e.g.
	git) or a release build, and disable the warnings for releases.

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: fix implicit enum conversion
	This code tries to use attach_type enums as hw_phb_decode, and while
	they're setup to have compatible values, the compiler doesn't like it
	when the cast is missing.  So cast it explicitly and then use that.

	sim/ppc/hw_phb.c:322:28: error:
		implicit conversion from enumeration type 'attach_type'
		(aka 'enum _attach_type') to different enumeration type
		'hw_phb_decode' [-Werror,-Wenum-conversion]

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: fix -Wmisleading-indentation warnings
	Fix building with -Wmisleading-indentation.

2023-12-05  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: cleanup getrusage decls
	Don't conflate HAVE_GETRUSAGE & HAVE_SYS_RESOURCE_H.  Use the latter
	to include the header and nothing else.  Use the former to determine
	whether to use the function and nothing else.  If we find a system
	that doesn't follow POSIX and provides only one of these, we can
	figure out how to support it then.  The manual local definition is
	clashing with the system ones and leading to build failures with
	newer C standards.

	sim/ppc/emul_netbsd.c:51:5: error: a function declaration without a
		prototype is deprecated in all versions of C and is treated as a
		zero-parameter prototype in C2x, conflicting with a previous
		declaration [-Werror,-Wdeprecated-non-prototype]

2023-12-05  Alan Modra  <amodra@gmail.com>

	aarch64-elf: FAIL: indirect call stub to BTI stub relaxation
	aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs
	being emitted in a different order to that of aarch64-linux.  They are
	emitted in a different order due to stub names for local symbols
	having the section id in the stub name.  aarch64-linux-ld generates
	one more section than aarch64-elf-ld.  That section is .gnu.hash.  So
	the stub names differ and are hashed to different slots in
	stub_hash_table.

	Fix this by running the test with --hash-style=sysv, and adjust
	expected output.  I've also changed the branch over stubs emitted at
	the start of a group of stubs to not care about the symbol, for all
	groups not just the one that needed changing.

		* ld-aarch64/bti-far-3.d: Add --hash-style=sysv.  Adjust
		expected output.

2023-12-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix directory name in test name
	In the commit:

	  commit 4793f551a5aa68522fd5fbbb7e8f621148f410cd
	  Date:   Mon Nov 27 13:33:17 2023 +0000

	      gdb: allow use of ~ in 'save gdb-index' command

	I added a test which has a directory name within the GDB command,
	which then appears in the test name as I failed to give the test a
	better name.

	Fixed in this commit.

2023-12-04  Ciaran Woodward  <ciaranwoodward@xmos.com>

	[gdb/doc] Escape the '@' symbols in generated texinfo files.
	'@' is a special symbol meaning 'command' in GNU texinfo.

	If the GDBINIT or GDBINIT_DIR path during configuration
	included an '@' character, the makeinfo command would fail,
	as it interpreted the '@' in the path as a start of a command
	when expanding the path in the docs.

	This patch simply escapes any '@' characters in the path,
	by replacing them with '@@'. This was already done for the
	bugurl variable.

	This was detected because the 'Jenkins' tool sometimes puts
	an '@' in the workspace path.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-04  Tom Tromey  <tom@tromey.com>

	Fix two buglets in .debug_names dumping
	While working on gdb's .debug_names writer, I found a couple of small
	bugs in binutils .debug_names dumping.

	First, the DWARF spec (section 6.1.1.4.6 Name Table) says:

	    These two arrays are indexed starting at 1, [...]

	I think it is clearer for binutils to follow this, particularly
	because DW_IDX_parent refers to this number.

	Second, I think the handling of an empty hash table is slightly wrong.
	Currently the dumping code assumes there is always an array of hashes.
	However, section 6.1.1.4.5 Hash Lookup Table says:

	    The optional hash lookup table immediately follows the list of
	    type signatures.

	and then:

	    The hash lookup table is actually two separate arrays: an array of
	    buckets, followed immediately by an array of hashes.

	My reading of this is that the hash table as a whole is optional, and
	so the hashes will not exist in this case.  (This also makes sense
	because the hashes are not useful without the buckets anyway.)

	This patch fixes both of these problems.  FWIW I have some gdb patches
	in progress that change gdb both to omit the hash table and to use
	DW_IDX_parent.

	2023-12-04  Tom Tromey  <tom@tromey.com>

		* dwarf.c (display_debug_names): Handle empty .debug_names hash
		table.  Name entries start at 1.

2023-12-04  Ciaran Woodward  <ciaranwoodward@xmos.com>

	gdb: add Ciaran Woodward to gdb/MAINTAINERS

2023-12-04  Jens Remus  <jremus@linux.ibm.com>

	s390: Support for jump visualization in disassembly
	Add support for jump visualization for the s390 architecture in
	disassembly:

	objdump -d --visualize-jumps ...

	Annotate the (conditional) jump and branch relative instructions with
	information required for jump visualization:
	- jump: Unconditional jump / branch relative.
	- condjump: Conditional jump / branch relative.
	- jumpsr: Jump / branch relative to subroutine.

	Unconditional jump and branch relative instructions are annotated as
	jump.
	Conditional jump and branch relative instructions, jump / branch
	relative on count/index, and compare and jump / branch relative
	instructions are annotated as condjump.
	Jump and save (jas, jasl) and branch relative and save (bras, brasl)
	instructions are annotated as jumpsr (jump to subroutine).

	Provide instruction information required for jump visualization during
	disassembly.
	The instruction type is provided after determining the opcode.
	For non-code it is set to dis_noninsn. Otherwise it defaults to
	dis_nonbranch. No annotation is done for data reference instructions
	(i.e. instruction types dis_dref and dis_dref2). Note that the
	instruction type needs to be provided before printing of the
	instruction, as it is used in print_address_func() to translate the
	argument value into an address if it is assumed to be a PC-relative
	offset. Note that this is never the case on s390, as
	print_address_func() is only called with addresses and never with
	offsets.
	The target of the (conditional) jump and branch relative instructions
	is provided during print, when the PC relative operand is decoded.

	include/
		* opcode/s390.h: Define opcode flags to annotate instruction
		  class information for jump visualization:
		  S390_INSTR_FLAG_CLASS_BRANCH, S390_INSTR_FLAG_CLASS_RELATIVE,
		  S390_INSTR_FLAG_CLASS_CONDITIONAL, and
		  S390_INSTR_FLAG_CLASS_SUBROUTINE.
		  Define opcode flags mask S390_INSTR_FLAG_CLASS_MASK for above
		  instruction class information.
		  Define helpers for common instruction class flag combinations:
		  S390_INSTR_FLAGS_CLASS_JUMP, S390_INSTR_FLAGS_CLASS_CONDJUMP,
		  and S390_INSTR_FLAGS_CLASS_JUMPSR.

	opcodes/
		* s390-mkopc.c: Add opcode flags to annotate information
		  for jump visualization: jump, condjump, and jumpsr.
		* s390-opc.txt: Annotate (conditional) jump and branch relative
		  instructions with information for jump visualization.
		* s390-dis.c (print_insn_s390, s390_print_insn_with_opcode):
		  Provide instruction information for jump visualization.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-12-04  Tom Tromey  <tromey@adacore.com>

	Remove incorrect "fall-through" comment
	I found a "fall-through" comment in gdb/remote.c that was incorrect --
	the code here cannot in fact fall through.

2023-12-04  Tom Tromey  <tromey@adacore.com>

	Update fall-through comment in gdbserver
	I noticed that gdbserver/win32-low.cc has a fall-through comment that
	should have been converted to use the annotation instead.

	This patch makes the change.

2023-12-04  Richard Bunt  <richard.bunt@linaro.org>

	gdb: Enable early init of thread pool size
	This commit enables the early initialization commands (92e4e97a9f5) to
	modify the number of threads used by gdb's thread pool.

	The motivation here is to prevent gdb from spawning a detrimental number
	of threads on many-core systems under environments with restrictive
	ulimits.

	With gdb before this commit, the thread pool takes the following sizes:

	1. Thread pool size is initialized to 0.

	2. After the maintenance commands are defined, the thread pool size is
	set to the number of system cores (if it has not already been set).

	3. Using early initialization commands, the thread pool size can be
	changed using "maint set worker-threads".

	4. After the first prompt, the thread pool size can be changed as in the
	previous step.

	Therefore after step 2. gdb has potentially launched hundreds of threads
	on a many-core system.

	After this change, step 2 and 3 are reversed so there is an opportunity
	to set the required number of threads without needing to default to the
	number of system cores first.

	There does exist a configure option (added in 261b07488b9) to disable
	multithreading, but this does not allow for an already deployed gdb to
	be configured.

	Additionally, the default number of worker threads is clamped at eight
	to control the number of worker threads spawned on many-core systems.
	This value was chosen as testing recorded on bugzilla issue 29959
	indicates that parallel efficiency drops past this point.

	GDB built with GCC 13.

	No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
	LLVM, NVHPC; Platforms: x86_64, aarch64.

	The scenario that interests me the most involves preventing GDB from
	spawning any worker threads at all. This was tested by counting the
	number of clones observed by strace:

	    strace -e clone,clone3 gdb/gdb -q \
	    --early-init-eval-command="maint set worker-threads 0" \
	    -ex q ./gdb/gdb |& grep --count clone

	The new test relies on "gdb: install CLI uiout while processing early
	init files" developed by Andrew Burgess. This patch will need pushing
	prior to this change.

	The clamping was tested on machines with both 16 cores and a single
	core.  "maint show worker-threads" correctly reported eight and one
	respectively.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: install CLI uiout while processing early init files
	The next commit wants to use a 'show' command within an early
	initialisation file, despite these commands not being in the list of
	acceptable commands for use within an early initialisation file.

	The problem we run into is that the early initialisation files are
	processed before GDB has installed the top level interpreter.  The
	interpreter is responsible to installing the default uiout (accessed
	through current_uiout), and as a result code that depends on
	uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and
	crashing GDB.

	I did consider moving the interpreter installation before the early
	initialisation, and this would work fine except for the new DAP
	interpreter, which relies on having Python available during its
	initialisation.  Which means we can't install the interpreter until
	after Python has been initialised, and the early initialisation
	handling has to occur before Python is setup -- that's the whole point
	of this feature (to allow customisation of how Python is setup).

	So, what I propose is that early within captured_main_1, we install a
	temporary cli_ui_out as the current_uiout.  This will remain in place
	until the top-level interpreter is installed, at which point the
	temporary will be replaced.

	What this means is that current_uiout will no longer be nullptr,
	instead, any commands within an early initialisation file that trigger
	output, will perform that output in a CLI style.

	I propose that we don't update the documentation for early
	initialisation files, we leave the user advice as being only 'set' and
	'source' commands are acceptable.  But now, if a user does try a
	'show' command, then instead of crashing, GDB will do something
	predictable.

	I've not added a test in this commit.  The next commit relies on this
	patch and will serve as a test.

	Tested-By: Richard Bunt <richard.bunt@linaro.org>

2023-12-04  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix wrapping strings
	I noticed that after resizing to a narrow window, I got:
	...
	┌────────────────┐
	│                │
	│[ No Source Avail
	able ]           │
	│                │
	└────────────────┘
	...

	Fix this by adding two new functions:
	- tui_win_info::display_string (int y, int x, const char *str)
	- tui_win_info::display_string (const char *str)
	that make sure that borders are not overwritten, which get us instead:
	...
	┌────────────────┐
	│                │
	│[ No Source Avai│
	│                │
	│                │
	└────────────────┘
	...

	Tested on x86_64-linux.

2023-12-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-03  Kevin Buettner  <kevinb@redhat.com>

	Fix detach bug when lwp has exited/terminated
	When using GDB on native linux, it can happen that, while attempting
	to detach an inferior, the inferior may have been exited or have been
	killed, yet still be in the list of lwps.  Should that happen, the
	assert in x86_linux_update_debug_registers in
	gdb/nat/x86-linux-dregs.c will trigger.  The line in question looks
	like this:

	  gdb_assert (lwp_is_stopped (lwp));

	For this case, the lwp isn't stopped - it's dead.

	The bug which brought this problem to my attention is one in which the
	pwntools library uses GDB to to debug a process; as the script is
	shutting things down, it kills the process that GDB is debugging and
	also sends GDB a SIGTERM signal, which causes GDB to detach all
	inferiors prior to exiting.  Here's a link to the bug:

	https://bugzilla.redhat.com/show_bug.cgi?id=2192169

	The following shell command mimics part of what the pwntools
	reproducer script does (with regard to shutting things down), but
	reproduces the bug much less reliably.  I have found it necessary to
	run the command a bunch of times before seeing the bug.  (I usually
	see it within 5-10 repetitions.)  If you choose to try this command,
	make sure that you have no running "cat" or "gdb" processes first!

	  cat </dev/zero >/dev/null & \
	  (sleep 5; (kill -KILL `pgrep cat` & kill -TERM `pgrep gdb`)) & \
	  sleep 1 ; \
	  gdb -q -iex 'set debuginfod enabled off' -ex 'set height 0' \
	      -ex c /usr/bin/cat `pgrep cat`

	So, basically, the idea here is to kill both gdb and cat at roughly
	the same time.  If we happen to attempt the detach before the process
	lwp has been deleted from GDB's (linux native) LWP data structures,
	then the assert will trigger.  The relevant part of the backtrace
	looks like this:

	  #8  0x00000000008a83ae in x86_linux_update_debug_registers (lwp=0x1873280)
	      at gdb/nat/x86-linux-dregs.c:146
	  #9  0x00000000008a862f in x86_linux_prepare_to_resume (lwp=0x1873280)
	      at gdb/nat/x86-linux.c:81
	  #10 0x000000000048ea42 in x86_linux_nat_target::low_prepare_to_resume (
	      this=0x121eee0 <the_amd64_linux_nat_target>, lwp=0x1873280)
	      at gdb/x86-linux-nat.h:70
	  #11 0x000000000081a452 in detach_one_lwp (lp=0x1873280, signo_p=0x7fff8ca3441c)
	      at gdb/linux-nat.c:1374
	  #12 0x000000000081a85f in linux_nat_target::detach (
	      this=0x121eee0 <the_amd64_linux_nat_target>, inf=0x16e8f70, from_tty=0)
	      at gdb/linux-nat.c:1450
	  #13 0x000000000083a23b in thread_db_target::detach (
	      this=0x1206ae0 <the_thread_db_target>, inf=0x16e8f70, from_tty=0)
	      at gdb/linux-thread-db.c:1385
	  #14 0x0000000000a66722 in target_detach (inf=0x16e8f70, from_tty=0)
	      at gdb/target.c:2526
	  #15 0x0000000000a8f0ad in kill_or_detach (inf=0x16e8f70, from_tty=0)
	      at gdb/top.c:1659
	  #16 0x0000000000a8f4fa in quit_force (exit_arg=0x0, from_tty=0)
	      at gdb/top.c:1762
	  #17 0x000000000070829c in async_sigterm_handler (arg=0x0)
	      at gdb/event-top.c:1141

	My colleague, Andrew Burgess, has done some recent work on other
	problems with detach.  Upon hearing of this problem, he came up a test
	case which reliably reproduces the problem and tests for a few other
	problems as well.  In addition to testing detach when the inferior has
	terminated due to a signal, it also tests detach when the inferior has
	exited normally.  Andrew observed that the linux-native-only
	"checkpoint" command would be affected too, so the test also tests
	those cases when there's an active checkpoint.

	For the LWP exit / termination case with no checkpoint, that's handled
	via newly added checks of the waitstatus in detach_one_lwp in
	linux-nat.c.

	For the checkpoint detach problem, I chose to pass the lwp_info
	to linux_fork_detach in linux-fork.c.  With that in place, suitable
	tests were added before attempting a PTRACE_DETACH operation.

	I added a few asserts at the beginning of linux_fork_detach and
	modified the caller code so that the newly added asserts shouldn't
	trigger.  (That's what the 'pid == inferior_ptid.pid' check is about
	in gdb/linux-nat.c.)

	Lastly, I'll note that the checkpoint code needs some work with regard
	to background execution.  This patch doesn't attempt to fix that
	problem, but it doesn't make it any worse.  It does slightly improve
	the situation with detach because, due to the check noted above,
	linux_fork_detach() won't be called for the wrong inferior when there
	are multiple inferiors.  (There are at least two other problems with
	the checkpoint code when there are multiple inferiors.  See:
	https://sourceware.org/bugzilla/show_bug.cgi?id=31065)

	This commit also adds a new test,
	gdb.base/process-dies-while-detaching.exp.  Andrew Burgess is the
	primary author of this test case.  Its design is similar to that of
	gdb.threads/main-thread-exit-during-detach.exp, which was also written
	by Andrew.

	This test checks that GDB correctly handles several cases that can
	occur when GDB attempts to detach an inferior process.  The process
	can exit or be terminated (e.g.  via SIGKILL) prior to GDB's event
	loop getting a chance to remove it from GDB's internal data
	structures.  To complicate things even more, detach works differently
	when a checkpoint (created via GDB's "checkpoint" command) exists for
	the inferior.  This test checks all four possibilities: process exit
	with no checkpoint, process termination with no checkpoint, process
	exit with a checkpoint, and process termination with a checkpoint.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-02  Petr Tesarik  <petr@tesarici.cz>

	binutils: Fix documentation typo in the --set-sect-name option
	Fix a --set-sect-name typo in the description of objcopy
	--rename-section.

	gdb: Update Petr Tesarik's email address in gdb/MAINTAINERS

2023-12-02  H.J. Lu  <hjl.tools@gmail.com>

	Fix ld/x86: reduce testsuite dependency on system object files
	commit eab996435fe65a421541f59557c5f1fd427573a3
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Tue Nov 7 13:58:32 2023 +0100

	    ld/x86: reduce testsuite dependency on system object files

	changed some C compiler tests to assembler/linker tests which introduced
	2 problems:

	1. It broke x32 binutils tests since --64 was passed to assembler, but
	-m elf_x86_64 wasn't passed to linker.
	2. -nostdlib was passed to C compiler driver to exclude standard run-time
	files which should be avoided with -r option for linker tests.

	Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for
	linker tests with -r.

		PR ld/30722
		* testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker
		for tests with --64.  Remove -nostdlib for tests with -r.

2023-12-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-12-01  Tom Tromey  <tromey@adacore.com>

	Bail out of "attach" if a thread cannot be traced
	On Linux, threads are treated much like separate processes by the
	kernel.  In particular, it's possible to ptrace just a single thread.
	If gdb tries to attach to a multi-threaded inferior, where a non-main
	thread is already being traced (e.g., by strace), then gdb will get
	into an infinite loop attempting to attach.

	This patch fixes this problem by having the attach fail if ptrace
	fails to attach to any thread of the inferior.

2023-12-01  Tom Tromey  <tromey@adacore.com>

	Use gdb_dir_up in linux_proc_attach_tgid_threads
	This changes linux_proc_attach_tgid_threads to use gdb_dir_up.  This
	makes it robust against exceptions.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-12-01  Tom Tromey  <tromey@adacore.com>

	Minor cleanup in linux_proc_attach_tgid_threads
	linux_proc_attach_tgid_threads computes a file name, and then
	re-computes it for a warning.  It is better to reuse the
	already-computed name here.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-12-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add missing regcache_map_entry array null terminators in aarch64-linux-tdep.c
	Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry
	arrays without a null terminator.  The null terminators are needed for
	regcache::transfer_regset and regcache_map_entry_size to work properly.

	Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Luis Machado <luis.machado@arm.com>

2023-12-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: return when exceeding buffer size in regcache::transfer_regset
	regcache::transfer_regset iterates over an array of regcache_map_entry,
	transferring the registers (between regcache and buffer) described by
	those entries.  It stops either when it reaches the end of the
	regcache_map_entry array (marked by a null entry) or (it seems like the
	intent is) when it reaches the end of the buffer (in which case not all
	described registers are transferred).

	I said "seems like the intent is", because there appears to be a small
	bug.  transfer_regset is made of two loops:

	    foreach regcache_map_entry:
	      foreach register described by the regcache_map_entry:
	        if the register doesn't fit in the remainder of the buffer:
		  break

	        transfer register

	When stopping because we have reached the end of the buffer, the break
	only breaks out of the inner loop.

	This problem causes some failures when I run tests such as
	gdb.arch/aarch64-sme-core-3.exp (on AArch64 Linux, in qemu).  This is
	partly due to aarch64_linux_iterate_over_regset_sections failing to add
	a null terminator in its regcache_map_entry array, but I think there is
	still a problem in transfer_regset.

	The sequence to the crash is:

	 - The `regcache_map_entry za_regmap` object built in
	   aarch64_linux_iterate_over_regset_sections does not have a null
	   terminator.
	 - When the target does not have a ZA register,
	   aarch64_linux_collect_za_regset calls `regcache->collect_regset` with
	   a size of 0 (it's actually pointless, but still it should work).
	 - transfer_regset gets called with a buffer size of 0.
	 - transfer_regset detects that the register to transfer wouldn't fit in
	   0 bytes, so it breaks out of the inner loop.
	 - The outer loop tries to go read the next regcache_map_entry, but
	   there isn't one, and we start reading garbage.

	Obviously, this would get fixed by making
	aarch64_linux_iterate_over_regset_sections use a null terminator (which
	is what the following patch does).  But I think that when detecting that
	there is not enough buffer left for the current register,
	transfer_regset should return, not only break out of the inner loop.

	This is a kind of contrived scenario, but imagine we have these two
	regcache_map_entry objects:

	  - 2 registers of 8 bytes
	  - 2 registers of 4 bytes

	For some reason, the caller passes a buffer of 12 bytes.
	transfer_regset will detect that the second 8 byte register does not
	fit, and break out of the inner loop.  However, it will then go try the
	next regcache_map_entry.  It will see that it can fit one 4 byte
	register in the remaining buffer space, and transfer it from/to there.
	This is very likely not an expected behavior, we wouldn't expect to
	read/write this sequence of registers from/to the buffer.

	In this example, whether passing a 12 bytes buffer makes sense or
	whether it is a size computation bug in the caller, we don't know, but I
	think that exiting as soon as a register doesn't fit is the sane thing
	to do.

	Change-Id: Ia349627d2e5d281822ade92a8e7a4dea4f839e07
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Reviewed-By: Luis Machado <luis.machado@arm.com>

2023-12-01  Tom Tromey  <tromey@adacore.com>

	Add link to Debugger Adapter Protocol node in documentation
	I noticed that the interpreters node in the docs links to the DAP
	protocol docs, but I thought the DAP node ought to as well.  This
	patch adds a bit of introductory text there.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-12-01  Jeff Law  <jeffreyalaw@gmail.com>

	Fix right shifts in mcore simulator on 64 bit hosts.
	If the value to be shifted has the sign bit set, the sign
	bit would get copied into bits 32..63 of the temporary.  Those
	would then be right shifted into the final value giving an
	incorrect final result.

	This was observed with upcoming GCC improvements which eliminate
	unnecessary extensions.

2023-12-01  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix completion tests when using READ1
	The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced
	regressions when testing using the READ1 mechanism. The reason for that
	is the new failure path in proc test_gdb_complete_tab_unique, which
	looks for GDB suggesting more than what the test inputted, but not the
	correct answer, followed by a white space. Consider the following case:

	int foo(int bar, int baz);

	Sending the command "break foo<tab>" to GDB will return

	break foo(int, int)

	which easily fits the buffer in normal testing, so everything works, but
	when reading one character at a time, the test will find the partial
	"break foo(int, " and assume that there was a mistake, so we get a
	spurious FAIL.

	That change was added because we wanted to avoid forcing a completion
	failure to fail through timeout, which it had to do because there is no
	way to verify that the output is done, mostly because when I was trying
	to solve a different problem I kept getting reading errors and testing
	completion was frustrating.

	This commit implements a better way to avoid that frustration, by first
	testing gdb's complete command and only if that passes we will test tab
	completion. The difference is that when testing with the complete
	command, we can tell when the output is over when we receive the GDB
	prompt again, so we don't need to rely on timeouts. With this, the
	change to test_gdb_complete_tab_unique has been removed as that test
	will only be run and fail in the very unlikely scenario that tab
	completion is different than command completion.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-12-01  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Remove unnecessary returns and unused variables in AIX.
	This is a patch to simplify the pd_activate () in aix-thread.c incase of a failure to start a thread session
	, since pd_activate () now has return type void.

	Also this patch fixes the shadow declarartion warning in sync-threadlists.

2023-12-01  Nick Clifton  <nickc@redhat.com>

	Fix: nm -U short flag erroneously consumes argument
	  PR 31105
	  * nm.c (main): Remove spurious colon after U in the call to getopt_long

2023-12-01  Jan Beulich  <jbeulich@suse.com>

	ld: fix build with old makeinfo
	Makeinfo 4.12 is unhappy about the new "Special Sections" without that
	also having a @chapter line.

	binutils/Dwarf: avoid "shadowing" of glibc function name
	Yet once again: Old enough glibc has an (unguarded) declaration of
	index() in string.h, which triggers a "shadows a global declaration"
	warning with at least some gcc versions.

	gas: drop unused fields from struct segment_info_struct
	user_stuff, dot, and lineno_list_{head,tail} have no users (left), while
	bfd_section was only ever written.

	x86: adjust NOP generation after potential non-insn
	Just like avoiding to do certain transformations potentially affected by
	stand-alone prefixes or direct data emission, also avoid emitting
	optimized NOPs right afterwards; insert a plain old NOP first in such
	cases.

	x86: i386_cons_align() badly affects diagnostics
	Warning without knowing what's going to follow isn't useful, the more
	that appropriate warnings are emitted elsewhere in all cases. Not
	updating state (file/line in particular) also isn't helpful, as it's
	always the last directive ahead of a construct potentially needing
	fiddling with that's "guilty" in that fiddling being suppressed.

	gas: no md_cons_align() for .nop{,s}
	.nop and .nops generate code, not data. Hence them invoking
	md_cons_align() is at best inappropriate. In fact it actually gets in
	the of x86'es state maintenance involving i386_cons_align().

	x86: suppress optimization after potential non-insn
	Just like avoiding to do other transformations potentially affected by
	stand-alone prefixes or direct data emission, also avoid optimization
	on the following insn.

2023-12-01  Jan Beulich  <jbeulich@suse.com>

	x86: last-insn recording should be per-section
	Otherwise intermediate section switches result in inconsistent behavior.
	Note, however, that intermediate sub-section switches will continue to
	result in inconsistent or even inappropriate behavior.

	While there also add recording of state to s_insn().

2023-12-01  Jan Beulich  <jbeulich@suse.com>

	x86: allow 32-bit reg to be used with U{RD,WR}MSR
	... as MSR index specifier: It is unreasonable to demand that people
	write less readable / understandable code, just because the present
	documentation mentions only Reg64. Whether to also adjust the
	disassembler is a separate question, perhaps indeed more tightly tied
	to what the spec says.

2023-12-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix warnings about invalid [[fallthrough]] usage
	Fix these two warnings, when building on macos:

	      CXX    cp-name-parser.o
	    /Users/smarchi/src/binutils-gdb/gdb/cp-name-parser.y:1644:7: error: fallthrough annotation does not directly precede switch label
	          [[fallthrough]];
	          ^

	      CXX    dbxread.o
	    /Users/smarchi/src/binutils-gdb/gdb/dbxread.c:2809:7: error: fallthrough annotation does not directly precede switch label
	          [[fallthrough]];
	          ^

	In these two cases, we [[fallthrough]], followed by a regular label,
	followed by a case label.  Move the [[fallthrough]] below the regular
	label.

	Change-Id: If4a3145139e050bdb6950c7f239badd5778e6f64
	Approved-By: Tom Tromey <tom@tromey.com>

2023-12-01  Patrick O'Neill  <patrick@rivosinc.com>

	RISC-V: Make riscv_is_mapping_symbol stricter
	riscv_is_mapping_symbol currently accepts any symbol that starts with $x
	or $d. This patch makes the check more strict, requiring exactly $x, $d,
	or $xrv. It also makes use of this stricter mapping in
	riscv_is_valid_mapping_symbol.

	ChangeLog:

		* bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only
		strings that are exactly $x, $d, or $xrv.
		* opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use
		riscv_elf_is_mapping_symbols.

2023-12-01  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Update gas/NEWS for RISC-V vendor extension news.
	gas/
		* NEWS: Update RISC-V vendor extension news.

2023-12-01  Nelson Chu  <nelson.chu@sifive.com>
	    Hau Hsu  <hau.hsu@sifive.com>
	    Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Add SiFive custom vector coprocessor interface instructions v1.0
	SiFive has define as set of flexible instruction for extending vector
	coprocessor, it able to encoding opcode like .insn but with predefined
	format.

	List of instructions:
	  sf.vc.x
	  sf.vc.i
	  sf.vc.vv
	  sf.vc.xv
	  sf.vc.iv
	  sf.vc.fv
	  sf.vc.vvv
	  sf.vc.xvv
	  sf.vc.ivv
	  sf.vc.fvv
	  sf.vc.vvw
	  sf.vc.xvw
	  sf.vc.ivw
	  sf.vc.fvw
	  sf.vc.v.x
	  sf.vc.v.i
	  sf.vc.v.vv
	  sf.vc.v.xv
	  sf.vc.v.iv
	  sf.vc.v.fv
	  sf.vc.v.vvv
	  sf.vc.v.xvv
	  sf.vc.v.ivv
	  sf.vc.v.fvv
	  sf.vc.v.vvw
	  sf.vc.v.xvw
	  sf.vc.v.ivw
	  sf.vc.v.fvw

	Spec of Xsfvcp
	https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software

2023-12-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Zv*: Add support for Zvkb ISA extension
	Back then when the support for the RISC-V vector crypto extensions
	was merged, the specification was frozen, but not ratified.
	A frozen specification is allowed to change within tight bounds
	before ratification and this has happend with the vector crypto
	extensions.

	The following changes were applied:
	* A new extension Zvkb was defined, which is a strict subset of Zvbb.
	* Zvkn and Zvks include now Zvkb instead of Zvbb.

	This patch implements these changes between the frozen and the
	ratified specification.

	Note, that this technically an incompatible change of Zvkn and Zvks,
	but I am not aware of any project that depends on the currently
	implemented behaviour of Zvkn and Zvks. So this patch should be fine.

	Reported-By: Jerry Shih <jerry.shih@sifive.com>
	Reported-By: Eric Biggers <ebiggers@kernel.org>

2023-12-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-30  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix adding -DNDEBUG to python flags of release build
	In gdb/configure the line:
	...
	    $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
	...
	intends to ensure that -DNDEBUG is added to the python flags of a release
	build.

	However, when building gdb-14-branch we have:
	...
	configure:22024: checking compiler flags for python code
	  ...
	configure:22047: result:  -fno-strict-aliasing -fwrapv
	...

	This is a regression since commit db6878ac553 ("Move sourcing of development.sh
	to GDB_AC_COMMON"), which introduced a reference before assignment:
	...
	    $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
	  ...
	. $srcdir/../bfd/development.sh
	...
	and consequently -DNDEBUG is never added.

	[ This was not obvious to me, but apparently evaluating an empty or undefined
	variable in this context is similar to using ':' or 'true', so the line is
	evaluated as:
	...
	    true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
	... ]

	Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that
	was done for gdbserver/configure.ac in commit db6878ac553.

	[ Unfortunately, the move might introduce issues similar to the one we're
	fixing, and I'm not sure how to check for this.  Shellcheck doesn't detect
	this type of problem.  FWIW, I did run shellcheck (using arguments -xa, in the
	src/gdb directory to make sure ../bfd/development.sh is taken into account)
	before and after and observed that the number of lines/words/chars in the
	shellcheck output is identical. ]

	Build & tested on top of trunk.

	Also build on top of gdb-14-branch, and observed this in gdb/config.log:
	...
	configure:25214: checking compiler flags for python code
	  ...
	configure:25237: result:  -fno-strict-aliasing -fwrapv -DNDEBUG
	...

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/31099
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099

2023-11-30  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/GAS: Add -march=loongson2f to loongson-2f-3 test
	On MIPSr6, the encoding of JR instruction has been chaned.
	This patch can fix these failures for r6 default triples:
		ST Microelectronics Loongson-2F workarounds of Jump Instruction issue

2023-11-30  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Set r6 as default arch if vendor is img
	This behavior is used by downstream toolchain since 2014,
	and has been in GCC since the same year.

	We don't support mips64*-img* due to GCC doesn't support it,
	and we believe that the multilib should be used for this case.

2023-11-30  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	Fix procfs.c compilation
	procfs.c doesn't currently compile on Solaris:

	/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’:
	/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’?
	 3017 |   type *ptr_type
	      |         ^~~~~~~~
	      |         var_types

	This was caused by this patch:

	commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee
	Author: Simon Marchi <simon.marchi@efficios.com>
	Date:   Fri Sep 29 14:24:38 2023 -0400

	    gdb: remove target_gdbarch

	Partially undoing it restores the build.

	Tested on amd64-pc-solaris2.11.

2023-11-30  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libiberty: Disable hwcaps for sha1.o
	This patch

	commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
	Author: Jakub Jelinek <jakub@redhat.com>
	Date:   Tue Nov 28 13:14:05 2023 +0100

	    libiberty: Use x86 HW optimized sha1

	broke Solaris/x86 bootstrap with the native as:

	libtool: compile:  /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
	ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000  [ SHA1 ]
	gccgo: fatal error: Killed signal terminated program go1

	As is already done in a couple of other similar cases, this patches
	disables hwcaps support for libiberty.

	Initially, this didn't work because config/hwcaps.m4 uses target_os, but
	didn't ensure it is defined.

	Tested on i386-pc-solaris2.11 with as and gas.

	2023-11-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

		config:
		* hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require
		AC_CANONICAL_TARGET.

		libiberty:
		* configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke.
		* configure, aclocal.m4: Regenerate.
		* Makefile.in (COMPILE.c): Add HWCAP_CFLAGS.

2023-11-30  Patrick O'Neill  <patrick@rivosinc.com>

	RISC-V: Avoid updating state until symbol is found
	Currently objdump gets and updates the map state once per symbol. Updating the
	state (partiularly riscv_parse_subset) is expensive and grows quadratically
	since we iterate over all symbols. By deferring this until once we've found the
	symbol of interest, we can reduce the time to dump a 4k insn file of .norvc and
	.rvc insns from ~47 seconds to ~0.13 seconds.

	opcodes/ChangeLog:

		* riscv-dis.c (riscv_get_map_state): Remove state updating logic
		and rename to riscv_is_valid_mapping_symbol.
		(riscv_update_map_state): Add state updating logic to seperate function.
		(riscv_search_mapping_symbol): Use new riscv_update_map_state.
		(riscv_data_length): Ditto.

2023-11-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: support double-slash line comments in BPF assembly
	This patch makes the BPF assembler to support double-slash line
	comments, like the llvm BPF assembler does.  At this point both
	assemblers support the same commenting styles:

	- Line comments preceded by # or //.
	- Non-nestable block comments delimited by /* and */.

	This patch also adds a couple of tests to make sure all the comment
	styles work in both normal and pseudoc syntax.  The manual is also
	updated to mention double-slash line comments.

2023-11-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-29  Tom Tromey  <tom@tromey.com>

	Remove gdb_static_assert
	C++17 makes the second parameter to static_assert optional, so we can
	remove gdb_static_assert now.

2023-11-29  Tom Tromey  <tom@tromey.com>

	Use C++17 void_t
	C++17 has void_t and make_void, so gdbsupport/traits.h can be
	simplified.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Rely on copy elision in scope-exit.h
	gdbsupport/scope-exit.h has a couple of comments about being able to
	rely on copy elision in C++17.  This patch makes the change.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Rely on C++17 <new> in new-op.cc
	gdbsupport/new-op.cc has a comment about relying on the C++-17 <new>
	header.  This patch implements the suggestion.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Use try_emplace in index-write.c
	index-write.c has a comment indicating that C++17's try_emplace could
	be used.  This patch makes the change.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Enable some C++14 code in array-view.h
	This changes gdbsupport/array-view.h to enable some code that is
	C++14-specific.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Switch to -Wimplicit-fallthrough=5
	This changes the various gdb-related directories to use
	-Wimplicit-fallthrough=5, meaning that only the fallthrough attribute
	can be used in switches -- special 'fallthrough' comments will no
	longer be usable.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Tom Tromey  <tom@tromey.com>

	Use C++17 [[fallthrough]] attribute
	This changes gdb to use the C++17 [[fallthrough]] attribute rather
	than special comments.

	This was mostly done by script, but I neglected a few spellings and so
	also fixed it up by hand.

	I suspect this fixes the bug mentioned below, by switching to a
	standard approach that, presumably, clang supports.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159
	Approved-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: support GNU option syntax in gp-display-html, plus various fixes
	This is a major update of gp-display-html.  The option handling has been
	modified to support the GNU style long option syntax.  Compatibility with
	the previous syntax has been preserved. If still used, a warning is issued.
	Through the --nowarnings option, this can be suppressed.
	In addition to this, various lay-out changes have been implemented.  In
	particular to reduce the number of lines that extend beyond column 79.
	Several bugs have been fixed, for example in the handling of directory names.

	gprofng/ChangeLog
	2023-11-28  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		* gp-display-html/gp-display-html.in: Change option syntax plus fixes.

2023-11-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: updated man pages and user guide
	This is a major update of all the man pages.  Bugs 30679 and 30895 are
	addressed.  In addition to fixes for typos, the texts have been expanded
	and clarified, and line lengths no longer extend beyond column 79.  In
	case of gp-display-html, the new option syntax is documented. The user
	guide has a new section on the gprofng GUI.

	gprofng/ChangeLog
	2023-11-28  Ruud van der Pas  <ruud.vanderpas@oracle.com>

		PR 30679
		PR 30895
		* doc/gp-archive.texi: Expand the description of the options.
		* doc/gp-collect-app.texi: Fix various typos and textual improvements.
		* doc/gp-display-html.texi: Cover the new GNU long option syntax.
		* doc/gp-display-src.texi: Fix various typos and textual improvements.
		* doc/gp-display-text.texi: Fix typos fixed and textual improvements.
		* doc/gp-macros.texi: Fix a bug in the vspace macro and add new macro.
		* doc/gprofng.texi: Cover the GPROFNG_SYSCONFDIR environment variable.
		* doc/gprofng_ug.texi: Fix various typos and textual improvements.
		* doc/version.texi: Adapt the date and version number.

2023-11-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: display errors from command completion
	This commit makes the gdb.Command.complete methods more verbose when
	it comes to error handling.

	Previous to this commit if any commands implemented in Python
	implemented the complete method, and if there were any errors
	encountered when calling that complete method, then GDB would silently
	hide the error and continue as if there were no completions.

	This makes is difficult to debug any errors encountered when writing
	completion methods, and encourages the idea that Python extensions can
	be broken, and GDB will just silently work around them.

	I don't think this is a good idea.  GDB should encourage extensions to
	be written correctly, and robustly, and one way in which GDB can (I
	think) support this, is by pointing out when an extension goes wrong.

	In this commit I've gone through the Python command completion code,
	and added calls to gdbpy_print_stack() or gdbpy_print_stack_or_quit()
	in places where we were either clearing the Python error, or, in some
	cases, just not handling the error at all.

	One thing I have not changed is in cmdpy_completer (py-cmd.c) where we
	process the list of completions returned from the Command.complete
	method; this routine includes a call to gdbpy_is_string to check a
	possible completion is a string, if not the completion is ignored.

	I was tempted to remove this check, attempt to complete each result to
	a string, and display an error if the conversion fails.  After all,
	returning anything but a string is surely a mistake by the extension
	author.

	However, the docs clearly say that only strings within the returned
	list will be considered as completions.  Anything else is ignored.  As
	such, and to avoid (what I think is pretty unlikely) breakage of
	existing code, I've retained the gdbpy_is_string check.

	After the gdbpy_is_string check we call python_string_to_host_string,
	if this call fails then I do now print the error, where before we
	ignored the error.  I think this is OK; if GDB thinks something is a
	string, but still can't convert it to a string, then I think it's OK
	to display the error in that case.

	Another case which I was a little unsure about was in
	cmdpy_completer_helper, and the call to PyObject_CallMethodObjArgs,
	which is when we actually call Command.complete.  Previously, if this
	call resulted in an exception then we would ignore this and just
	pretend there were no completions.

	Of all the changes, this is possibly the one with the biggest
	potential for breaking existing scripts, but also, is, I think, the
	most useful change.  If the user code is wrong in some way, such that
	an exception is raised, then previously the user would have no obvious
	feedback about this breakage.  Now GDB will print the exception for
	them, making it, I think, much easier to debug their extension.  But,
	if there is user code in the wild that relies on raising an exception
	as a means to indicate there are no completions .... well, that code
	is going to break after this commit.  I think we can live with this
	though, the exceptions means no completions thing was never documented
	behaviour.

	I also added a new error() call if the PyObject_CallMethodObjArgs call
	raises an exception.  This causes the completion mechanism within GDB
	to stop.  Within GDB the completion code is called twice, the first
	time to compute the work break characters, and then a second time to
	compute the actual completions.

	If PyObject_CallMethodObjArgs raises an exception when computing the
	word break character, and we print it by calling
	gdbpy_print_stack_or_quit(), but then carry on as if
	PyObject_CallMethodObjArgs had returns no completions, GDB will
	call the Python completion code again, which results in another call
	to PyObject_CallMethodObjArgs, which might raise the same exception
	again.  This results in the Python exception being printed twice.

	By throwing a C++ exception after the failed
	PyObject_CallMethodObjArgs call, the completion mechanism is aborted,
	and no completions are offered.  But importantly, the Python exception
	is only printed once.  I think this gives a much better user
	experience.

	I've added some tests to cover this case, as I think this is the most
	likely case that a user will run into.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: improve test regexp in gdb_get_worker_threads
	I spotted I made a small mistake in this commit:

	  commit aff250145af6c7a8ea9332bc1306c1219f4a63db
	  Date:   Fri Nov 24 12:04:36 2023 +0000

	      gdb: generate gdb-index identically regardless of work thread count

	In this commit I added a new proc in testsuite/lib/gdb.exp called
	gdb_get_worker_threads.  This proc uses gdb_test_multiple with two
	possible patterns.  One pattern is anchored with '^', while the other
	is missing the '^' which it could use.

	This commit adds the missing '^'.

2023-11-28  Mike Frysinger  <vapier@gentoo.org>

	gnulib: mark configure +x

2023-11-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix call to breakpoint_inserted_here_p in darwin-nat.c
	Fixes this issue, introduced by f9582a22dba7 ("[gdb] Fix segfault in
	for_each_block, part 1"):

	       CXX    darwin-nat.o
	     /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1169:7: error: no matching function for call to 'breakpoint_inserted_here_p'
	       if (breakpoint_inserted_here_p (inf->aspace, pc))
	           ^~~~~~~~~~~~~~~~~~~~~~~~~~

	Change-Id: I3bb6be75b650319f0fa1dbdceb379b18531da96c

2023-11-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: add NEWS entry for change of comment syntax in BPF assembler
	2023-11-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* NEWS: Add entry about change of comment syntax in the BPF
		assembler.

2023-11-28  Tom Tromey  <tromey@adacore.com>

	Emit DAP "process" event
	DAP specifies a "process" event that is sent when a process is started
	or attached to.  gdb was not emitting this (several DAP clients appear
	to ignore it entirely), but it looked easy and harmless to implement.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473

2023-11-28  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Use const std::string for string literals in tui-stack.c
	I noticed in gdb/tui/tui-stack.c a source-level micro-optimization where
	strlen with a string literal argument:
	...
	strlen ("bla")
	...
	is replaced with sizeof:
	...
	sizeof ("bla") - 1
	...

	The benefit of this is that the optimization is also done at O0, but the
	drawback is that it makes the expression harder to read.

	Use const std::string to encapsulate the string literals, and use
	std::string::size () instead.

	I tried making the string names (PROC_PREFIX, LINE_PREFIX, PC_PREFIX and
	SINGLE_KEY) lower-case, but that clashed with a pre-existing pc_prefix, so
	I've left them upper-case.

	Tested on x86_64-linux.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2023-11-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	sim: bpf: do not use semicolon to begin comments
	The BPF assembler has been updated to follow the clang convention in
	the interpretation of semicolons: they separate statements and
	directives, and do not start line comments.

2023-11-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: change meaning of ; in the BPF assembler
	The BPF assembler in clang uses semi-colon (;) to separate statements,
	not to be begin line comments.  This patch adapts the GNU assembler
	accordingly.

	Testsuite and documentation updated accordingly.

	2023-11-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* config/tc-bpf.c: Semicolon does not start a comment, but
		separates multiple commands on a single line.
		* testsuite/gas/bpf/alu-pseudoc.s: Adapt test accordingly.
		* testsuite/gas/bpf/spacing-pseudoc.s: Likewise.
		* testsuite/gas/bpf/offset16-overflow.s: Likewise.
		* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
		* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
		* testsuite/gas/bpf/imm32-overflow.s: Likewise.
		* testsuite/gas/bpf/disp32-overflow.s: Likewise.
		* testsuite/gas/bpf/disp16-overflow-relax.s: Likewise.
		* testsuite/gas/bpf/disp16-overflow.s: Likewise.
		* doc/c-bpf.texi (BPF Special Characters): Update.

2023-11-28  Jakub Jelinek  <jakub@redhat.com>

	libiberty, ld: Use x86 HW optimized sha1
	The following patch attempts to use x86 SHA ISA if available to speed
	up in my testing about 2.5x sha1 build-id processing (in my case on
	AMD Ryzen 5 3600) while producing the same result.
	I believe AArch64 has similar HW acceleration for SHA1, perhaps it
	could be added similarly.

	Note, seems lld uses BLAKE3 rather than md5/sha1.  I think it would be
	a bad idea to lie to users, if they choose --buildid=sha1, we should
	be using SHA1, not some other checksum, but perhaps we could add some other
	--buildid= styles and perhaps make one of the new the default.

	Tested on x86_64-linux, both on Intel i9-7960X (which doesn't have
	sha_ni ISA support) without/with the patch and on AMD Ryzen 5 3600
	(which does have it) without/with the patch.

	2023-11-28  Jakub Jelinek  <jakub@redhat.com>

	include/
		* sha1.h (sha1_process_bytes_fn): New typedef.
		(sha1_choose_process_bytes): Declare.
	libiberty/
		* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
		* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
		and cpuid.h.
		(sha1_hw_process_bytes, sha1_hw_process_block,
		sha1_choose_process_bytes): New functions.
		* config.in: Regenerated.
		* configure: Regenerated.
	ld/
		* ldbuildid.c (generate_build_id): Use sha1_choose_process_bytes ()
		instead of &sha1_process_bytes.

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add a new check-all-boards target
	The make-check-all.sh script (gdb/testsuite/make-check-all.sh) is
	great, it makes it super easy to run some test(s) using all the
	available board files.

	This commit aims to make this script even easier to access by adding a
	check-all-boards target to the GDB Makefile.  This new target checks
	for (and requires) a number of environment variables, so the target
	should be used like this:

	  make check-all-boards GDB_TARGET_USERNAME=remote-target \
	                        GDB_HOST_USERNAME=remote-host \
				TESTS="gdb.base/break.exp"

	Where GDB_TARGET_USERNAME and GDB_HOST_USERNAME are the user names
	that should be passed to the make-check-all.sh --target-user and
	--host-user command line options respectively.

	My personal intention is to set these variables in my environment, so
	all I'll need to do is:

	  make check-all-boards TESTS="gdb.base/break.exp"

	The make rule always passes --keep-results to the make-check-all.sh
	script, as I find that the most useful.  It's super frustrating to run
	the tests and realise you forgot that option and the results have been
	discarded.

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: log 'make check' command in make-check-all.sh
	I have been making more use of the make-check-all.sh script to run
	tests against all boards.

	But one thing is pretty annoying.  When a test fails on some random
	board, I have to run make-check-all.sh with --verbose and --dry-run in
	order to see what RUNTESTFLAGS I should be using.

	I always run with --keep-results on, so, in this commit, I propose
	that, when --keep-results is on the 'make check' command will be
	written out to a file within the stored results directory, like:

	  check-all/BOARD_NAME/make-check.sh

	then, if I want to rerun a test, I can just:

	  sh check-all/BOARD_NAME/make-check.sh

	and the test will be re-run for me.

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: generate dwarf-5 index identically as worker-thread count changes
	Similar to the previous commit, this commit ensures that the dwarf-5
	index files are generated identically as the number of worker-threads
	changes.

	Building the dwarf-5 index makes use of a closed hash table, the
	bucket_hash local within debug_names::build().  Entries are added to
	bucket_hash from m_name_to_value_set, which, in turn, is populated
	by calls to debug_names::insert() in write_debug_names.  The insert
	calls are ordered based on the entries within the cooked_index, and
	the ordering within cooked_index depends on the number of worker
	threads that GDB is using.

	My proposal is to sort each chain within the bucket_hash closed hash
	table prior to using this to build the dwarf-5 index.

	The buckets within bucket_hash will always have the same ordering (for
	a given GDB build with a given executable), and by sorting the chains
	within each bucket, we can be sure that GDB will see each entry in a
	deterministic order.

	I've extended the index creation test to cover this case.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: generate gdb-index identically regardless of work thread count
	It was observed that changing the number of worker threads that GDB
	uses (maintenance set worker-threads NUM) would have an impact on the
	layout of the generated gdb-index.

	The cause seems to be how the CU are distributed between threads, and
	then symbols that appear in multiple CU can be encountered earlier or
	later depending on whether a particular CU moves between threads.

	I certainly found this behaviour was reproducible when generating an
	index for GDB itself, like:

	  gdb -q -nx -nh -batch \
	      -eiex 'maint set worker-threads NUM' \
	      -ex 'save gdb-index /tmp/'

	And then setting different values for NUM will change the generated
	index.

	Now, the question is: does this matter?

	I would like to suggest that yes, this does matter.  At Red Hat we
	generate a gdb-index as part of the build process, and we would
	ideally like to have reproducible builds: for the same source,
	compiled with the same tool-chain, we should get the exact same output
	binary.  And we do .... except for the index.

	Now we could simply force GDB to only use a single worker thread when
	we build the index, but, I don't think the idea of reproducible builds
	is that strange, so I think we should ensure that our generated
	indexes are always reproducible.

	To achieve this, I propose that we add an extra step when building the
	gdb-index file.  After constructing the initial symbol hash table
	contents, we will pull all the symbols out of the hash, sort them,
	then re-insert them in sorted order.  This will ensure that the
	structure of the generated hash will remain consistent (given the same
	set of symbols).

	I've extended the existing index-file test to check that the generated
	index doesn't change if we adjust the number of worker threads used.
	Given that this test is already rather slow, I've only made one change
	to the worker-thread count.  Maybe this test should be changed to use
	a smaller binary, which is quicker to load, and for which we could
	then try many different worker thread counts.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: C++-ify mapped_symtab from dwarf2/index-write.c
	Make static the functions add_index_entry, find_slot, and hash_expand,
	member functions of the mapped_symtab class.

	Fold an additional snippet of code from write_gdbindex into
	mapped_symtab::minimize, this code relates to minimisation, so this
	seems like a good home for it.

	Make the n_elements, data, and m_string_obstack member variables of
	mapped_symtab private.  Provide a new obstack() member function to
	provide access to the obstack when needed, and also add member
	functions begin(), end(), cbegin(), and cend() so that the
	mapped_symtab class can be treated like a contained and iterated
	over.

	I've also taken this opportunity to split out the logic for whether
	the hash table (m_data) needs expanding, this is the new function
	hash_needs_expanding.  This will be useful in a later commit.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: reduce size of generated gdb-index file
	I noticed in passing that out algorithm for generating the gdb-index
	file is incorrect.  When building the hash table in add_index_entry we
	count every incoming entry rehash when the number of entries gets too
	large.  However, some of the incoming entries will be duplicates,
	which don't actually result in new items being added to the hash
	table.

	As a result, we grow the gdb-index hash table far too often.

	With an unmodified GDB, generating a gdb-index for GDB, I see a file
	size of 90M, with a hash usage (in the generated index file) of just
	2.6%.

	With a patched GDB, generating a gdb-index for the _same_ GDB binary,
	I now see a gdb-index file size of 30M, with a hash usage of 41.9%.

	This is a 67% reduction in gdb-index file size.

	Obviously, not every gdb-index file is going to see such big savings,
	however, the larger a program, and the more symbols that are
	duplicated between compilation units, the more GDB would over count,
	and so, over-grow the index.

	The gdb-index hash table we create has a minimum size of 1024, and
	then we grow the hash when it is 75% full, doubling the hash table at
	that time.  Given this, then we expect that either:

	  a. The hash table is size 1024, and less than 75% full, or
	  b. The hash table is between 37.5% and 75% full.

	I've include a test that checks some of these constraints -- I've not
	bothered to check the upper limit, and over full hash table isn't
	really a problem here, but if the fill percentage is less than 37.5%
	then this indicates that we've done something wrong (obviously, I also
	check for the 1024 minimum size).

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: small refactor in selftest-support.exp
	Split out the code that makes a copy of the GDB executable ready for
	self testing into a new proc.  A later commit in this series wants to
	load the GDB executable into GDB (for creating an on-disk debug
	index), but doesn't need to make use of the full do_self_tests proc.

	There should be no changes in what is tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: option completion for 'save gdb-index' command
	Add proper support for option completion to the 'save gdb-index'
	command.  Update save_gdb_index_command function to make use of the
	new option_def data structures for parsing the '-dwarf-5' option.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: allow use of ~ in 'save gdb-index' command
	Add a call to gdb_tilde_expand in the save_gdb_index_command function,
	this means that we can now do:

	  (gdb) save gdb-index ~/blah/

	Previous this wouldn't work.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-28  Nick Clifton  <nickc@redhat.com>

	New Romanian translation for ld

2023-11-28  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix segfault in for_each_block, part 2
	The previous commit describes PR gdb/30547, a segfault when running test-case
	gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x).

	The root cause for the segmentation fault is that linux_is_uclinux gives an
	incorrect result: it returns true instead of false.

	So, why does linux_is_uclinux:
	...
	int
	linux_is_uclinux (void)
	{
	  CORE_ADDR dummy;

	  return (target_auxv_search (AT_NULL, &dummy) > 0
		  && target_auxv_search (AT_PAGESZ, &dummy) == 0);
	...
	return true?

	This is because ppc_linux_target_wordsize returns 4 instead of 8, causing
	ppc_linux_nat_target::auxv_parse to misinterpret the auxv vector.

	So, why does ppc_linux_target_wordsize:
	...
	int
	ppc_linux_target_wordsize (int tid)
	{
	  int wordsize = 4;

	  /* Check for 64-bit inferior process.	 This is the case when the host is
	     64-bit, and in addition the top bit of the MSR register is set.  */
	  long msr;

	  errno = 0;
	  msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0);
	  if (errno == 0 && ppc64_64bit_inferior_p (msr))
	    wordsize = 8;

	  return wordsize;
	}
	...
	return 4?

	Specifically, we get this result because because tid == 0, so we get
	errno == ESRCH.

	The tid == 0 is caused by the switch_to_no_thread in
	handle_vfork_child_exec_or_exit:
	...
		  /* Switch to no-thread while running clone_program_space, so
		     that clone_program_space doesn't want to read the
		     selected frame of a dead process.  */
		  scoped_restore_current_thread restore_thread;
		  switch_to_no_thread ();

		  inf->pspace = new program_space (maybe_new_address_space ());
	...
	but moving the maybe_new_address_space call to before that gives us the
	same result.  The tid is no longer 0, but we still get ESRCH because the
	thread has exited.

	Fix this in handle_vfork_child_exec_or_exit by doing the
	maybe_new_address_space call in the context of the vfork parent.

	Tested on top of trunk on x86_64-linux and ppc64le-linux.
	Tested on top of gdb-14-branch on ppc64-linux.

	Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

	PR gdb/30547
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547

2023-11-28  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix segfault in for_each_block, part 1
	When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise
	on s390x), I run into:
	...
	(gdb) PASS: gdb.base/vfork-follow-parent.exp: \
	  exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \
	  resolution_method=schedule-multiple: print unblock_parent = 1
	continue^M
	Continuing.^M
	Reading symbols from vfork-follow-parent-exit...^M
	^M
	^M
	Fatal signal: Segmentation fault^M
	----- Backtrace -----^M
	0x1027d3e7 gdb_internal_backtrace_1^M
	        src/gdb/bt-utils.c:122^M
	0x1027d54f _Z22gdb_internal_backtracev^M
	        src/gdb/bt-utils.c:168^M
	0x1057643f handle_fatal_signal^M
	        src/gdb/event-top.c:889^M
	0x10576677 handle_sigsegv^M
	        src/gdb/event-top.c:962^M
	0x3fffa7610477 ???^M
	0x103f2144 for_each_block^M
	        src/gdb/dcache.c:199^M
	0x103f235b _Z17dcache_invalidateP13dcache_struct^M
	        src/gdb/dcache.c:251^M
	0x10bde8c7 _Z24target_dcache_invalidatev^M
	        src/gdb/target-dcache.c:50^M
	...
	or similar.

	The root cause for the segmentation fault is that linux_is_uclinux gives an
	incorrect result: it should always return false, given that we're running on a
	regular linux system, but instead it returns first true, then false.

	In more detail, the segmentation fault happens as follows:
	- a program space with an address space is created
	- a second program space is about to be created. maybe_new_address_space
	  is called, and because linux_is_uclinux returns true, maybe_new_address_space
	  returns false, and no new address space is created
	- a second program space with the same address space is created
	- a program space is deleted. Because linux_is_uclinux now returns false,
	  gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns
	  false, and the address space is deleted
	- when gdb uses the address space of the remaining program space, we run into
	  the segfault, because the address space is deleted.

	Hardcoding linux_is_uclinux to false makes the test-case pass.

	We leave addressing the root cause for the following commit in this series.

	For now, prevent the segmentation fault by making the address space a refcounted
	object.

	This was already suggested here [1]:
	...
	A better solution might be to have the address spaces be reference counted
	...

	Tested on top of trunk on x86_64-linux and ppc64le-linux.
	Tested on top of gdb-14-branch on ppc64-linux.

	Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

	PR gdb/30547
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547

	[1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html

2023-11-28  Haochen Jiang  <haochen.jiang@intel.com>

	testsuite: Clean up .allow_index_reg in i386 tests
	gas/ChangeLog:

		* testsuite/gas/i386/adx.s: Remove .allow_index_reg.
		* testsuite/gas/i386/amx-complex-inval.l: Ditto.
		* testsuite/gas/i386/amx-complex-inval.s: Ditto.
		* testsuite/gas/i386/avx-ifma.s: Ditto.
		* testsuite/gas/i386/avx-ne-convert.s: Ditto.
		* testsuite/gas/i386/avx-scalar-2.s: Ditto.
		* testsuite/gas/i386/avx-vnni-int8.s: Ditto.
		* testsuite/gas/i386/avx-vnni.s: Ditto.
		* testsuite/gas/i386/avx-wig.s: Ditto.
		* testsuite/gas/i386/avx2-wig.s: Ditto.
		* testsuite/gas/i386/avx2.s: Ditto.
		* testsuite/gas/i386/avx256int.s: Ditto.
		* testsuite/gas/i386/avx512_4fmaps.s: Ditto.
		* testsuite/gas/i386/avx512_4vnniw.s: Ditto.
		* testsuite/gas/i386/avx512_bf16.s: Ditto.
		* testsuite/gas/i386/avx512_bf16_vl-inval.l: Ditto.
		* testsuite/gas/i386/avx512_bf16_vl-inval.s: Ditto.
		* testsuite/gas/i386/avx512_bf16_vl.s: Ditto.
		* testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto.
		* testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto.
		* testsuite/gas/i386/avx512_fp16.s: Ditto.
		* testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto.
		* testsuite/gas/i386/avx512_fp16_vl.s: Ditto.
		* testsuite/gas/i386/avx512_vpopcntdq.s: Ditto.
		* testsuite/gas/i386/avx512bitalg.s: Ditto.
		* testsuite/gas/i386/avx512bitalg_vl.s: Ditto.
		* testsuite/gas/i386/avx512bw-opts.s: Ditto.
		* testsuite/gas/i386/avx512bw-wig.s: Ditto.
		* testsuite/gas/i386/avx512bw.s: Ditto.
		* testsuite/gas/i386/avx512bw_vl-opts.s: Ditto.
		* testsuite/gas/i386/avx512bw_vl-wig.s: Ditto.
		* testsuite/gas/i386/avx512bw_vl.s: Ditto.
		* testsuite/gas/i386/avx512cd.s: Ditto.
		* testsuite/gas/i386/avx512cd_vl.s: Ditto.
		* testsuite/gas/i386/avx512dq-rcig.s: Ditto.
		* testsuite/gas/i386/avx512dq.s: Ditto.
		* testsuite/gas/i386/avx512dq_vl.s: Ditto.
		* testsuite/gas/i386/avx512er-rcig.s: Ditto.
		* testsuite/gas/i386/avx512er.s: Ditto.
		* testsuite/gas/i386/avx512f-opts.s: Ditto.
		* testsuite/gas/i386/avx512f-rcig.s: Ditto.
		* testsuite/gas/i386/avx512f.s: Ditto.
		* testsuite/gas/i386/avx512f_gfni.s: Ditto.
		* testsuite/gas/i386/avx512f_vaes.s: Ditto.
		* testsuite/gas/i386/avx512f_vl-opts.s: Ditto.
		* testsuite/gas/i386/avx512f_vl-wig.s: Ditto.
		* testsuite/gas/i386/avx512f_vl.s: Ditto.
		* testsuite/gas/i386/avx512f_vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/avx512ifma.s: Ditto.
		* testsuite/gas/i386/avx512ifma_vl.s: Ditto.
		* testsuite/gas/i386/avx512pf.s: Ditto.
		* testsuite/gas/i386/avx512vbmi.s: Ditto.
		* testsuite/gas/i386/avx512vbmi2.s: Ditto.
		* testsuite/gas/i386/avx512vbmi2_vl.s: Ditto.
		* testsuite/gas/i386/avx512vbmi_vl.s: Ditto.
		* testsuite/gas/i386/avx512vl_gfni.s: Ditto.
		* testsuite/gas/i386/avx512vl_vaes.s: Ditto.
		* testsuite/gas/i386/avx512vl_vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/avx512vnni.s: Ditto.
		* testsuite/gas/i386/avx512vnni_vl.s: Ditto.
		* testsuite/gas/i386/bmi.s: Ditto.
		* testsuite/gas/i386/bmi2.s: Ditto.
		* testsuite/gas/i386/cldemote.s: Ditto.
		* testsuite/gas/i386/clflushopt.s: Ditto.
		* testsuite/gas/i386/clwb.s: Ditto.
		* testsuite/gas/i386/cmpccxadd-inval.l: Ditto.
		* testsuite/gas/i386/cmpccxadd-inval.s: Ditto.
		* testsuite/gas/i386/enqcmd-inval.l: Ditto.
		* testsuite/gas/i386/enqcmd-inval.s: Ditto.
		* testsuite/gas/i386/enqcmd.s: Ditto.
		* testsuite/gas/i386/evex-lig-2.s: Ditto.
		* testsuite/gas/i386/evex-lig.s: Ditto.
		* testsuite/gas/i386/evex-wig.s: Ditto.
		* testsuite/gas/i386/evex.s: Ditto.
		* testsuite/gas/i386/fma-scalar.s: Ditto.
		* testsuite/gas/i386/fma.s: Ditto.
		* testsuite/gas/i386/fma4.s: Ditto.
		* testsuite/gas/i386/gfni.s: Ditto.
		* testsuite/gas/i386/hle.s: Ditto.
		* testsuite/gas/i386/ilp32/enqcmd.s: Ditto.
		* testsuite/gas/i386/ilp32/movdir.s: Ditto.
		* testsuite/gas/i386/lwp.s: Ditto.
		* testsuite/gas/i386/movdir.s: Ditto.
		* testsuite/gas/i386/movdir64b-reg.l: Ditto.
		* testsuite/gas/i386/movdir64b-reg.s: Ditto.
		* testsuite/gas/i386/mpx-inval-1.l: Ditto.
		* testsuite/gas/i386/mpx-inval-1.s: Ditto.
		* testsuite/gas/i386/mpx.s: Ditto.
		* testsuite/gas/i386/msrlist-inval.l: Ditto.
		* testsuite/gas/i386/msrlist-inval.s: Ditto.
		* testsuite/gas/i386/notrack.s: Ditto.
		* testsuite/gas/i386/notrackbad.l: Ditto.
		* testsuite/gas/i386/notrackbad.s: Ditto.
		* testsuite/gas/i386/optimize-1.s: Ditto.
		* testsuite/gas/i386/optimize-2.s: Ditto.
		* testsuite/gas/i386/optimize-3.s: Ditto.
		* testsuite/gas/i386/optimize-6.s: Ditto.
		* testsuite/gas/i386/optimize-6a.l: Ditto.
		* testsuite/gas/i386/optimize-7.l: Ditto.
		* testsuite/gas/i386/optimize-7.s: Ditto.
		* testsuite/gas/i386/opts.s: Ditto.
		* testsuite/gas/i386/prefetchwt1.s: Ditto.
		* testsuite/gas/i386/raoint.s: Ditto.
		* testsuite/gas/i386/sha.s: Ditto.
		* testsuite/gas/i386/sse2avx.s: Ditto.
		* testsuite/gas/i386/tbm.s: Ditto.
		* testsuite/gas/i386/vaes.s: Ditto.
		* testsuite/gas/i386/vex-lig-2.s: Ditto.
		* testsuite/gas/i386/vp2intersect-inval-bcast.l: Ditto.
		* testsuite/gas/i386/vp2intersect-inval-bcast.s: Ditto.
		* testsuite/gas/i386/vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/x86-64-adx.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-ifma.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-scalar-2.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-swap.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-vnni-int8.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-vnni.s: Ditto.
		* testsuite/gas/i386/x86-64-avx-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx2-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx2.s: Ditto.
		* testsuite/gas/i386/x86-64-avx256int.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_4fmaps.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_4vnniw.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512_vpopcntdq.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw-opts.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl-opts.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq-rcig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512er-rcig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512er.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-opts.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-rcig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_gfni.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vaes.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl-opts.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512pf.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_gfni.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vaes.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni.s: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni_vl.s: Ditto.
		* testsuite/gas/i386/x86-64-avx_gfni.s: Ditto.
		* testsuite/gas/i386/x86-64-bmi.s: Ditto.
		* testsuite/gas/i386/x86-64-bmi2.s: Ditto.
		* testsuite/gas/i386/x86-64-cldemote.s: Ditto.
		* testsuite/gas/i386/x86-64-clflushopt.s: Ditto.
		* testsuite/gas/i386/x86-64-clwb.s: Ditto.
		* testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto.
		* testsuite/gas/i386/x86-64-enqcmd-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-enqcmd-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-enqcmd.s: Ditto.
		* testsuite/gas/i386/x86-64-evex-lig-2.s: Ditto.
		* testsuite/gas/i386/x86-64-evex-lig.s: Ditto.
		* testsuite/gas/i386/x86-64-evex-wig.s: Ditto.
		* testsuite/gas/i386/x86-64-evex-wig2.s: Ditto.
		* testsuite/gas/i386/x86-64-fma-scalar.s: Ditto.
		* testsuite/gas/i386/x86-64-fma.s: Ditto.
		* testsuite/gas/i386/x86-64-fma4.s: Ditto.
		* testsuite/gas/i386/x86-64-fred.s: Ditto.
		* testsuite/gas/i386/x86-64-gfni.s: Ditto.
		* testsuite/gas/i386/x86-64-hle.s: Ditto.
		* testsuite/gas/i386/x86-64-lkgs.s: Ditto.
		* testsuite/gas/i386/x86-64-lwp.s: Ditto.
		* testsuite/gas/i386/x86-64-movdir.s: Ditto.
		* testsuite/gas/i386/x86-64-movdir64b-reg.l: Ditto.
		* testsuite/gas/i386/x86-64-movdir64b-reg.s: Ditto.
		* testsuite/gas/i386/x86-64-mpx-inval-1.l: Ditto.
		* testsuite/gas/i386/x86-64-mpx-inval-1.s: Ditto.
		* testsuite/gas/i386/x86-64-mpx-inval-2.l: Ditto.
		* testsuite/gas/i386/x86-64-mpx-inval-2.s: Ditto.
		* testsuite/gas/i386/x86-64-mpx.s: Ditto.
		* testsuite/gas/i386/x86-64-notrack.s: Ditto.
		* testsuite/gas/i386/x86-64-notrackbad.l: Ditto.
		* testsuite/gas/i386/x86-64-notrackbad.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-1.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-2.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-3.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-4.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-7.s: Ditto.
		* testsuite/gas/i386/x86-64-optimize-7a.l: Ditto.
		* testsuite/gas/i386/x86-64-optimize-8.l: Ditto.
		* testsuite/gas/i386/x86-64-optimize-8.s: Ditto.
		* testsuite/gas/i386/x86-64-opts.s: Ditto.
		* testsuite/gas/i386/x86-64-prefetchi-warn.s: Ditto.
		* testsuite/gas/i386/x86-64-prefetchi.s: Ditto.
		* testsuite/gas/i386/x86-64-prefetchwt1.s: Ditto.
		* testsuite/gas/i386/x86-64-raoint.s: Ditto.
		* testsuite/gas/i386/x86-64-sha.s: Ditto.
		* testsuite/gas/i386/x86-64-sse2avx.s: Ditto.
		* testsuite/gas/i386/x86-64-tbm.s: Ditto.
		* testsuite/gas/i386/x86-64-vaes.s: Ditto.
		* testsuite/gas/i386/x86-64-vex-lig-2.s: Ditto.
		* testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.l: Ditto.
		* testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.s: Ditto.
		* testsuite/gas/i386/x86-64-vpclmulqdq.s: Ditto.
		* testsuite/gas/i386/x86-64-xop.s: Ditto.
		* testsuite/gas/i386/x86-64-xsavec.s: Ditto.
		* testsuite/gas/i386/x86-64-xsaves.s: Ditto.
		* testsuite/gas/i386/xop.s: Ditto.
		* testsuite/gas/i386/xsavec.s: Ditto.
		* testsuite/gas/i386/xsaves.s: Ditto.

2023-11-28  Haochen Jiang  <haochen.jiang@intel.com>

	testsuite: Clean up #as in dump file for i386 tests
	gas/ChangeLog:

		* testsuite/gas/i386/avx-gather-intel.d: Remove unused #as.
		* testsuite/gas/i386/avx-gather.d: Ditto.
		* testsuite/gas/i386/avx-ifma-intel.d: Ditto.
		* testsuite/gas/i386/avx-ifma.d: Ditto.
		* testsuite/gas/i386/avx-ne-convert-intel.d: Ditto.
		* testsuite/gas/i386/avx-ne-convert.d: Ditto.
		* testsuite/gas/i386/avx-vnni-int8-intel.d: Ditto.
		* testsuite/gas/i386/avx-vnni-int8.d: Ditto.
		* testsuite/gas/i386/avx512_bf16.d: Ditto.
		* testsuite/gas/i386/avx512_bf16_vl.d: Ditto.
		* testsuite/gas/i386/avx512_fp16-intel.d: Ditto.
		* testsuite/gas/i386/avx512_fp16.d: Ditto.
		* testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto.
		* testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512_fp16_vl.d: Ditto.
		* testsuite/gas/i386/avx512_vpopcntdq-intel.d: Ditto.
		* testsuite/gas/i386/avx512_vpopcntdq.d: Ditto.
		* testsuite/gas/i386/avx512bitalg-intel.d: Ditto.
		* testsuite/gas/i386/avx512bitalg.d: Ditto.
		* testsuite/gas/i386/avx512bitalg_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512bitalg_vl.d: Ditto.
		* testsuite/gas/i386/avx512bw-opts-intel.d: Ditto.
		* testsuite/gas/i386/avx512bw-opts.d: Ditto.
		* testsuite/gas/i386/avx512bw_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512bw_vl-opts-intel.d: Ditto.
		* testsuite/gas/i386/avx512bw_vl-opts.d: Ditto.
		* testsuite/gas/i386/avx512bw_vl.d: Ditto.
		* testsuite/gas/i386/avx512cd-intel.d: Ditto.
		* testsuite/gas/i386/avx512cd.d: Ditto.
		* testsuite/gas/i386/avx512cd_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512cd_vl.d: Ditto.
		* testsuite/gas/i386/avx512dq-intel.d: Ditto.
		* testsuite/gas/i386/avx512dq.d: Ditto.
		* testsuite/gas/i386/avx512dq_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512dq_vl.d: Ditto.
		* testsuite/gas/i386/avx512er-intel.d: Ditto.
		* testsuite/gas/i386/avx512er.d: Ditto.
		* testsuite/gas/i386/avx512f-nondef.d: Ditto.
		* testsuite/gas/i386/avx512f-opts-intel.d: Ditto.
		* testsuite/gas/i386/avx512f-opts.d: Ditto.
		* testsuite/gas/i386/avx512f_gfni-intel.d: Ditto.
		* testsuite/gas/i386/avx512f_gfni.d: Ditto.
		* testsuite/gas/i386/avx512f_vaes-intel.d: Ditto.
		* testsuite/gas/i386/avx512f_vaes.d: Ditto.
		* testsuite/gas/i386/avx512f_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512f_vl-opts-intel.d: Ditto.
		* testsuite/gas/i386/avx512f_vl-opts.d: Ditto.
		* testsuite/gas/i386/avx512f_vl.d: Ditto.
		* testsuite/gas/i386/avx512f_vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/avx512f_vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/avx512ifma-intel.d: Ditto.
		* testsuite/gas/i386/avx512ifma.d: Ditto.
		* testsuite/gas/i386/avx512ifma_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512ifma_vl.d: Ditto.
		* testsuite/gas/i386/avx512pf-intel.d: Ditto.
		* testsuite/gas/i386/avx512pf.d: Ditto.
		* testsuite/gas/i386/avx512vbmi-intel.d: Ditto.
		* testsuite/gas/i386/avx512vbmi.d: Ditto.
		* testsuite/gas/i386/avx512vbmi2-intel.d: Ditto.
		* testsuite/gas/i386/avx512vbmi2.d: Ditto.
		* testsuite/gas/i386/avx512vbmi2_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512vbmi2_vl.d: Ditto.
		* testsuite/gas/i386/avx512vbmi_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512vbmi_vl.d: Ditto.
		* testsuite/gas/i386/avx512vl_gfni-intel.d: Ditto.
		* testsuite/gas/i386/avx512vl_gfni.d: Ditto.
		* testsuite/gas/i386/avx512vl_vaes-intel.d: Ditto.
		* testsuite/gas/i386/avx512vl_vaes.d: Ditto.
		* testsuite/gas/i386/avx512vl_vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/avx512vl_vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/avx512vnni-intel.d: Ditto.
		* testsuite/gas/i386/avx512vnni.d: Ditto.
		* testsuite/gas/i386/avx512vnni_vl-intel.d: Ditto.
		* testsuite/gas/i386/avx512vnni_vl.d: Ditto.
		* testsuite/gas/i386/bmi-intel.d: Ditto.
		* testsuite/gas/i386/bmi.d: Ditto.
		* testsuite/gas/i386/bmi2-intel.d: Ditto.
		* testsuite/gas/i386/bmi2.d: Ditto.
		* testsuite/gas/i386/cldemote-intel.d: Ditto.
		* testsuite/gas/i386/cldemote.d: Ditto.
		* testsuite/gas/i386/clflushopt-intel.d: Ditto.
		* testsuite/gas/i386/clflushopt.d: Ditto.
		* testsuite/gas/i386/clwb-intel.d: Ditto.
		* testsuite/gas/i386/clwb.d: Ditto.
		* testsuite/gas/i386/enqcmd-intel.d: Ditto.
		* testsuite/gas/i386/enqcmd.d: Ditto.
		* testsuite/gas/i386/gfni-intel.d: Ditto.
		* testsuite/gas/i386/gfni.d: Ditto.
		* testsuite/gas/i386/hreset.d: Ditto.
		* testsuite/gas/i386/invpcid-intel.d: Ditto.
		* testsuite/gas/i386/invpcid.d: Ditto.
		* testsuite/gas/i386/keylocker-intel.d: Ditto.
		* testsuite/gas/i386/keylocker.d: Ditto.
		* testsuite/gas/i386/movdir-intel.d: Ditto.
		* testsuite/gas/i386/movdir.d: Ditto.
		* testsuite/gas/i386/pr27198.d: Ditto.
		* testsuite/gas/i386/pr30248.d: Ditto.
		* testsuite/gas/i386/prefetchwt1-intel.d: Ditto.
		* testsuite/gas/i386/prefetchwt1.d: Ditto.
		* testsuite/gas/i386/ptwrite-intel.d: Ditto.
		* testsuite/gas/i386/ptwrite.d: Ditto.
		* testsuite/gas/i386/raoint-intel.d: Ditto.
		* testsuite/gas/i386/raoint.d: Ditto.
		* testsuite/gas/i386/serialize.d: Ditto.
		* testsuite/gas/i386/tbm-intel.d: Ditto.
		* testsuite/gas/i386/tdx.d: Ditto.
		* testsuite/gas/i386/tsxldtrk.d: Ditto.
		* testsuite/gas/i386/vp2intersect-intel.d: Ditto.
		* testsuite/gas/i386/vp2intersect.d: Ditto.
		* testsuite/gas/i386/vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/waitpkg-intel.d: Ditto.
		* testsuite/gas/i386/waitpkg.d: Ditto.
		* testsuite/gas/i386/wrmsrns-intel.d: Ditto.
		* testsuite/gas/i386/wrmsrns.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-bad.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16-bad.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-gather-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-gather.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-ifma-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-ifma.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx-vnni-int8.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_bf16_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_vpopcntdq-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512_vpopcntdq.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bitalg_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw-opts-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw-opts.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl-opts-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl-opts.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512bw_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512cd_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512dq_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512er-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512er.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-nondef.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-opts-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f-opts.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_gfni-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_gfni.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vaes-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vaes.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl-opts-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl-opts.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512ifma_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512pf-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512pf.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi2_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vbmi_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_gfni-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_gfni.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vaes-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vaes.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni_vl-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx512vnni_vl.d: Ditto.
		* testsuite/gas/i386/x86-64-avx_gfni-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-avx_gfni.d: Ditto.
		* testsuite/gas/i386/x86-64-bmi-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-bmi.d: Ditto.
		* testsuite/gas/i386/x86-64-bmi2-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-bmi2.d: Ditto.
		* testsuite/gas/i386/x86-64-cldemote-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-cldemote.d: Ditto.
		* testsuite/gas/i386/x86-64-clflushopt-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-clflushopt.d: Ditto.
		* testsuite/gas/i386/x86-64-clwb-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-clwb.d: Ditto.
		* testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto.
		* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-fred.d: Ditto.
		* testsuite/gas/i386/x86-64-gfni-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-gfni.d: Ditto.
		* testsuite/gas/i386/x86-64-hreset.d: Ditto.
		* testsuite/gas/i386/x86-64-invpcid-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-invpcid.d: Ditto.
		* testsuite/gas/i386/x86-64-keylocker-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-keylocker.d: Ditto.
		* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
		* testsuite/gas/i386/x86-64-movsxd-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-movsxd.d: Ditto.
		* testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-msrlist.d: Ditto.
		* testsuite/gas/i386/x86-64-prefetchi-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-prefetchi.d: Ditto.
		* testsuite/gas/i386/x86-64-prefetchwt1-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-prefetchwt1.d: Ditto.
		* testsuite/gas/i386/x86-64-ptwrite-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-ptwrite.d: Ditto.
		* testsuite/gas/i386/x86-64-raoint-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-raoint.d: Ditto.
		* testsuite/gas/i386/x86-64-serialize.d: Ditto.
		* testsuite/gas/i386/x86-64-sysenter.d: Ditto.
		* testsuite/gas/i386/x86-64-tbm-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-tdx.d: Ditto.
		* testsuite/gas/i386/x86-64-tsxldtrk.d: Ditto.
		* testsuite/gas/i386/x86-64-uintr.d: Ditto.
		* testsuite/gas/i386/x86-64-vp2intersect-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-vp2intersect.d: Ditto.
		* testsuite/gas/i386/x86-64-vpclmulqdq-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-vpclmulqdq.d: Ditto.
		* testsuite/gas/i386/x86-64-waitpkg-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-waitpkg.d: Ditto.
		* testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-wrmsrns.d: Ditto.
		* testsuite/gas/i386/x86-64-xsavec-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-xsavec.d: Ditto.
		* testsuite/gas/i386/x86-64-xsaves-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-xsaves.d: Ditto.
		* testsuite/gas/i386/xsavec-intel.d: Ditto.
		* testsuite/gas/i386/xsavec.d: Ditto.
		* testsuite/gas/i386/xsaves-intel.d: Ditto.
		* testsuite/gas/i386/xsaves.d: Ditto.

2023-11-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-27  John Baldwin  <jhb@FreeBSD.org>

	i386: Use a fallback XSAVE layout for remote targets
	If a target provides a target description including registers from the
	XSAVE extended region, but does not provide an XSAVE layout, use a
	fallback XSAVE layout based on the included registers.  This fallback
	layout matches GDB's behavior in earlier releases which assumes the
	layout from Intel CPUs.

	This fallback layout is currently only used for remote targets since
	native targets which support XSAVE provide an explicit layout derived
	from CPUID.

	PR gdb/30912
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-11-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add boards/cc-with-index-cache.exp
	We have a target board cc-with-gdb-index that uses the gdb-add-index script to
	add a .gdb_index index to an exec.

	There is however an alternative way of adding a .gdb_index: the index-cache.

	Add a new target board cc-with-index-cache.

	This is not superfluous for two reasons:
	- there is functionality that gdb-add-index doesn't support, but the
	  index-cache does: the index-cache can add an index to an exec with a
	  .gnu_debugaltlink (note that when using the cc-with-gdb-index board this
	  case is quietly ignored), and
	- using the index-cache is excercised in only a few test-cases, and having
	  this target board extends the test coverage to the entire test suite.  This
	  is for instance relevant because the index-cache is written by a worker
	  thread in the background, so we can check more thoroughly for data races
	  (see PR symtab/30837).

	Tested on x86_64-linux.

	Shell script changes checked with shellcheck.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Change serial_readchar to throw
	This changes serial_readchar to throw an exception rather than trying
	to set and preserve errno.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Change serial_send_break and serial_write to throw
	This changes serial_send_break and serial_write to throw exceptions
	rather than attempt to set errno and return an error indicator.  This
	lets us correctly report failures on Windows.

	Both functions had to be converted in a single patch because one
	implementation of send_break works via write.

	This also introduces remote_serial_send_break to handle error checking
	when attempting to send a break.  This was previously ignored.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Change serial "open" functions to throw exception
	remote.c assumes that a failure to open the serial connection will set
	errno.  This is somewhat true, because the Windows code tries to set
	errno appropriately -- but only somewhat, because it isn't clear that
	the "pex" code sets it, and the tcp code seems to do the wrong thing.
	It seems better to simply have the serial open functions throw on
	error.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Change serial_setbaudrate to throw exception
	remote.c has this code:

	      if (serial_setbaudrate (rs->remote_desc, baud_rate))
		{
		  /* The requested speed could not be set.  Error out to
		     top level after closing remote_desc.  Take care to
		     set remote_desc to NULL to avoid closing remote_desc
		     more than once.  */
		  serial_close (rs->remote_desc);
		  rs->remote_desc = NULL;
		  perror_with_name (name);

	The perror here cannot be correct, because if serial_setbaudrate did
	set errno, it may be obscured by serial_close.

	This patch changes serial_setbaudrate to throw an exception instead.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Introduce throw_winerror_with_name
	This introduces throw_winerror_with_name, a Windows analog of
	perror_with_name, and changes various places in gdb to call it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Fix latent bug in ser_windows_send_break
	The ClearCommBreak documentation says:

	    If the function fails, the return value is zero.

	ser_windows_send_break inverts this check.  This has never been
	noticed because the caller doesn't check the result.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770

2023-11-27  Tom Tromey  <tromey@adacore.com>

	Fix bug in DAP handling of 'pause' requests
	While working on cancellation, I noticed that a DAP 'pause' request
	would set the "do not emit the continue" flag.  This meant that a
	subsequent request that should provoke a 'continue' event would
	instead suppress the event.

	I then tried writing a more obvious test case for this, involving an
	inferior call -- and discovered that gdb.events.cont does not fire for
	an inferior call.

	This patch installs a new event listener for gdb.events.inferior_call
	and arranges for this to emit continue and stop events when
	appropriate.  It also fixes the original bug, by adding a check to
	exec_and_expect_stop.

2023-11-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make catch_syscall_enabled return bool
	Make it return a bool and adjust a few comparisons where it's used.

	Change-Id: Ic77d23b0dcfcfc9195dfe65e4c7ff9cf3229f6fb

2023-11-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: handle completion returning a non-sequence
	GDB's Python API documentation for gdb.Command.complete() says:

	  The 'complete' method can return several values:
	     * If the return value is a sequence, the contents of the
	       sequence are used as the completions.  It is up to 'complete'
	       to ensure that the contents actually do complete the word.  A
	       zero-length sequence is allowed, it means that there were no
	       completions available.  Only string elements of the sequence
	       are used; other elements in the sequence are ignored.

	     * If the return value is one of the 'COMPLETE_' constants
	       defined below, then the corresponding GDB-internal completion
	       function is invoked, and its result is used.

	     * All other results are treated as though there were no
	       available completions.

	So, returning a non-sequence, and non-integer from a complete method
	should be fine; it should just be treated as though there are no
	completions.

	However, if I write a complete method that returns None, I see this
	behaviour:

	  (gdb) complete completefilenone x
	  Python Exception <class 'TypeError'>: 'NoneType' object is not iterable
	  warning: internal error: Unhandled Python exception
	  (gdb)

	Which is caused because we currently assume that anything that is not
	an integer must be iterable, and we call PyObject_GetIter on it.  When
	this call fails a Python exception is set, but instead of
	clearing (and therefore ignoring) this exception as we do everywhere
	else in the Python completion code, we instead just return with the
	exception set.

	In this commit I add a PySequence_Check call.  If this call returns
	false (and we've already checked the integer case) then we can assume
	there are no completion results.

	I've added a test which checks returning a non-sequence.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-27  Jiajie Chen  <c@jia.je>

	as: Add new estimated reciprocal instructions in LoongArch v1.1
	New estimated reciprocal instructions in LoongArch v1.1:

	- frecipe.s/d
	- frsqrte.s/d
	- vfrecipe.s/d
	- vfrsqrte.s/d
	- xvfrecipe.s/d
	- xvfrsqrte.s/d

2023-11-27  Jiajie Chen  <c@jia.je>

	as: Add new atomic instructions in LoongArch v1.1
	LoongArch V1.1 release is out at
	https://github.com/loongson/LoongArch-Documentation.

	New atomic instructions in LoongArch v1.1:

	- sc.q
	- llacq.w/d
	- screl.w/d
	- amcas{_db}.b/h/w/d
	- amswap{_db}.b/h
	- amadd{_db}.b/h

2023-11-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use more %progbits for arm
	On pinebook I ran into:
	...
	Running gdb.tui/tui-layout-asm-short-prog.exp ...
	gdb compile failed, gdb.tui/tui-layout-asm-short-prog.S: Assembler messages:
	gdb.tui/tui-layout-asm-short-prog.S:23: Error: \
	  junk at end of line, first unrecognized character is `,'
	...

	Fix this by using %progbits instead of @progbits for arm.

	Approved-by: Luis Machado <luis.machado@arm.com>

	Tested on x86_64-linux and pinebook.

2023-11-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Two fixes in gdb.python/tui-window-disabled.exp
	I ran test-case gdb.python/tui-window-disabled.exp on a configuration without
	python support, and ran into:
	...
	PASS: $exp: cleanup_properly=True: initial restart: set pagination off
	UNSUPPORTED: $exp: cleanup_properly=True: couldn't restart GDB
	PASS: $exp: cleanup_properly=False: initial restart: set pagination off
	UNSUPPORTED: $exp: cleanup_properly=False: couldn't restart GDB
	...

	After looking into the test-case, I realized that this is a consequence of
	!allow_python_tests.

	Handle this instead by requiring allow_python_tests, such that we get the usual
	and more clear:
	...
	UNSUPPORTED: $exp: require failed: allow_python_tests
	...

	Also fix a return without value in clean_restart_and_setup, which if triggered
	would cause:
	...
	ERROR: expected boolean value but got ""
	...

	Tested on x86_64-linux.

2023-11-24  Ilya Leoshkevich  <iii@linux.ibm.com>

	gdb: Fix "target file /proc/.../cmdline contained unexpected null characters"
	When using the gcore command, GDB prints the following warning:

	    (gdb) gcore
	    warning: target file /proc/.../cmdline contained unexpected null characters

	The reason is that cmdline is read with target_fileio_read_stralloc(),
	which warns on seeing null characters. However, it's perfectly valid
	for cmdline to contain \0s, so switch to target_fileio_read_alloc().

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-24  Jan Beulich  <jbeulich@suse.com>

	RISC-V: drop leftover match_never() references
	Commit 27b33966b18e "RISC-V: disallow x0 with certain macro-insns"
	wasn't properly re-based over recent opcode table additions.

	x86: shrink opcode sets table
	Have i386-gen produce merely the offsets into i386_optab[]. Besides
	allowing to shrink the table even on 32-bit builds, this results in
	removing a level of indirection from the frequently accessed
	current_templates, in return for adding a level of indirection when
	looking up mnemonics (commonly happening just once per insn). Plus for
	PIE builds of gas it also reduces the number of relocations by about two
	thousand. Finally a somewhat ugly static variable can also be eliminated
	from i386_displacement().

	x86: also prefer VEX encoding over EVEX one for VCVTNEPS2BF16 when possible
	Deal with what 58bceb182740 ("x86: prefer VEX encodings over EVEX ones
	when possible") left out, for being slightly less straightforward.

2023-11-24  Jan Beulich  <jbeulich@suse.com>

	RISC-V: reduce redundancy in sign/zero extension macro insn handling
	Fold M_{S,Z}EXTH, deriving signed-ness from the incoming mnemonic. Fold
	riscv_ext()'s calls md_assemblef(), the first of which were entirely
	identical, while the other pair differed in just a single character.

	Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-11-24  Jan Beulich  <jbeulich@suse.com>

	RISC-V: disallow x0 with certain macro-insns
	While for some of the macro insns using x0 is kind of okay, as they
	would merely resolve to a sequence of hint insns (and hence not cause
	misbehavior at runtime), several of them have the degenerate AUIPC
	followed by a load, store, or branch using other than the designated
	symbol as address and hence causing runtime issues. Refuse to assemble
	those, leveraging that the matching function so far wasn't really used
	for macro insns: NULL is now allowed, indicating a match (which imo is
	preferable over converting match_never() to match_always()), while
	other matching functions now (also) used for macro insns need to avoid
	calling match_opcode().

	Note that for LA the restriction is slightly too strict: In non-PIC mode
	using x0 would be okay-ish as per above (as it's just LLA there). Yet
	libopcodes doesn't know what mode gas is presently assembling for, so we
	want to err on the safe side.

	Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-11-24  Nick Clifton  <nickc@redhat.com>

	Fix building for the s390 target with clang

2023-11-24  zengxiao  <zengxiao@eswincomputing.com>

	RISC-V: Update 'Zfa' extension version
	Because the 'Zfa' extension has a version number of 1.0
	(not 0.1). This commit updates the number.

	bfd/ChangeLog:

	            * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
	            number of the 'Zfa' extension since it's ratified.

2023-11-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Correct prno instruction name
	IBM z13 (arch11) introduced ppno (Perform Pseudorandom Number Operation).
	IBM z14 (arch12) introduced prno (Perform Random Number Operation) and
	deprecated ppno.

	opcodes/
		* s390-opc.txt: Correct prno instruction name.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Add missing extended mnemonics
	Add extended mnemonics specified in the z/Architecture Principles of
	Operation [1] and z/Architecture Reference Summary [2], that were
	previously missing from the opcode table.

	The following added extended mnemonics are synonyms to a base mnemonic
	and therefore disassemble into their base mnemonic:
	jc, jcth, lfi, llgfi, llghi

	The following added extended mnemonics are more specific than their base
	mnemonic and therefore disassemble into the added extended mnemonic:
	risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt

	The following added extended mnemonics are more specific than their base
	mnemonic, but disassemble into their base mnemonic due to design
	constraints:
	notr, notgr

	The missing extended mnemonic jl* conditional jump long flavors cannot
	be added, as they would clash with the existing non-standard extended
	mnemonic j* conditional jump flavors jle and jlh. The missing extended
	mnemonic jlc jump long conditional is not added, as the related jl*
	flavors cannot be added.
	Note that these missing jl* conditional jump long flavors are already
	defined as non-standard jg* flavors instead. While the related missing
	extended mnemonic jlc could be added as non-standard jgc instead it is
	forgone in favor of not adding further non-standard mnemonics.

	The missing extended mnemonics sllhh, sllhl, slllh, srlhh, srlhl, and
	srllh cannot be implemented using the current design, as they require
	computed operands. For that reason the following missing extended
	mnemonics are not added as well, as they fall into the same category of
	instructions that operate on high and low words of registers. They
	should better be added together, not to confuse the user, which of those
	instructions are currently implemented or not.
	lhhr, lhlr, llhfr, llchhr, llchlr, llclhr, llhhhr, llhhlr, llhlhr,
	nhhr, nhlr, nlhr, ohhr, ohlr, olhr, xhhr, xhlr, xlhr

	[1] IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	    https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
	[2] IBM z/Architecture Reference Summary, SA22-7871-11,
	    https://www.ibm.com/support/pages/sites/default/files/2022-09/SA22-7871-11.pdf

	opcodes/
		* s390-opc.c: Define operand formats R_CP16_28, U6_18, and
		  U5_27. Define instruction formats RIE_RRUUU3, RIE_RRUUU4,
		  and RRF_R0RR4.
		* s390-opc.txt: Add extended mnemonics jc, jcth, lfi, llgfi,
		  llghi, notgr, notr, risbhgz, risblgz, rnsbgt, rosbgt, and
		  rxsbgt.

	gas/
		* config/tc-s390.c: Add support to insert operand for format
		  R_CP16_28, reusing existing logic for format V_CP16_12.
		* testsuite/gas/s390/esa-g5.s: Add test for extended mnemonic
		  jc.
		* testsuite/gas/s390/esa-g5.d: Likewise.
		* testsuite/gas/s390/zarch-z900.s: Add test for extended
		  mnemonic llghi.
		* testsuite/gas/s390/zarch-z900.d: Likewise.
		* testsuite/gas/s390/zarch-z9-109.s: Add tests for extended
		  mnemonics lfi and llgfi.
		* testsuite/gas/s390/zarch-z9-109.d: Likewise.
		* testsuite/gas/s390/zarch-z10.s: Add tests for extended
		  mnemonics rnsbgt, rosbgt, and rxsbgt.
		* testsuite/gas/s390/zarch-z10.d: Likewise.
		* testsuite/gas/s390/zarch-z196.s: Add tests for extended
		  mnemonics jcth, risbhgz, and risblgz.
		* testsuite/gas/s390/zarch-z196.d: Likewise.
		* testsuite/gas/s390/zarch-arch13.s: Add tests for extended
		  mnemonics notr and notgr.
		* testsuite/gas/s390/zarch-arch13.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Align optional operand definition to specs
	The IBM z/Architecture Principle of Operation [1] specifies the last
	operand(s) of some (extended) mnemonics to be optional. Align the
	mnemonic definitions in the opcode table according to specification.

	This changes the last operand of the following (extended) mnemonics to
	be optional:
	risbg, risbgz, risbgn, risbgnz, risbhg, risblg, rnsbg, rosbg, rxsbg

	Note that efpc and sfpc actually have only one operand, but had
	erroneously been defined to have two. For backwards compatibility the
	wrong RR register format must be retained. Since the superfluous second
	operand is defined as optional the instruction can still be coded as
	specified.

	[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
	     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

	opcodes/
		* s390-opc.txt: Align optional operand definition to
		specification.

	testsuite/
		* zarch-z10.s: Add test cases for risbg, risbgz, rnsbg, rosbg,
		  and rxsbg.
		* zarch-z10.d: Likewise.
		* zarch-z196.s: Add test cases for risbhg and risblg.
		* zarch-z196.d: Likewise.
		* zarch-zEC12.s: Add test cases for risbgn and risbgnz.
		* zarch-zEC12.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Make operand table indices relative to each other
	This is a purely mechanical change. It allows subsequent insertions into
	the operands table without having to renumber all operand indices.

	The only differences in the resulting ELF object are in the .debug_info
	section. This has been confirmed by diffing the following xxd and readelf
	output:

	xxd s390-opc.o
	readelf -aW -x .text -x .data -x .bss -x .rodata -x .debug_info \
	  -x .symtab -x .strtab -x .shstrtab --debug-dump s390-opc.o

	opcodes/
		* s390-opc.c: Make operand table indices relative to each other.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Add brasl edge test cases from ESA to z/Architecture
	The ESA opcode test cases for IBM z900 contain a few edge cases. They
	exercise the brasl mnemonic with its largest allowed negative and
	positive offsets. Linux on zSeries in ESA mode executes in 31-bit
	addressing mode. Therefore the ESA test cases are assembled with -m31.
	In 31-bit addressing mode the address computation using those large
	offsets wraps, which is correctly reflected in the disassembly.

	Linux on Z in z/Architecture mode executes in 64-bit addressing mode.
	Therefore the z/Architecture (zarch) test cases are assembled with -m64.
	In 64-bit addressing mode the address computation using those large
	offsets does not necessarily wrap.

	gas/
		* testsuite/gas/s390/zarch-z900.s: Add brasl tests from ESA that
		  exercise edge cases.
		* testsuite/gas/s390/zarch-z900.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  Jens Remus  <jremus@linux.ibm.com>

	s390: Position independent verification of relative addressing
	Opcode test cases for z/Architecture instructions that use relative
	addressing contained hardcoded offsets in the test verification
	patterns. Inserting or reordering of instructions into those test cases
	therefore required updating of those hardcoded offsets.

	Use regular expressions with backreferences to verify results of test
	cases containing instructions with relative addressing. This makes the
	verification position independent.

	gas/
		* testsuite/gas/s390/esa-g5.d: Make opcode test verification
		  pattern position independent where possible.
		* testsuite/gas/s390/esa-z900.d: Likewise.
		* testsuite/gas/s390/zarch-z900.d: Likewise.
		* testsuite/gas/s390/zarch-z10.d: Likewise.
		* testsuite/gas/s390/zarch-z196.d: Likewise.
		* testsuite/gas/s390/zarch-zEC12.d: Likewise.

	Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

2023-11-23  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/GAS: Use addiu instead of addi in test elf-rel.

	MIPS/GAS: Fix test failures due to jr encoding changes on r6

2023-11-23  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Reformat missing_debug.py using black
	Reformat gdb/python/lib/gdb/missing_debug.py with black after commit
	e8c3dafa5f5 ("[gdb/python] Don't import curses.ascii module unless necessary").

2023-11-23  Tom Tromey  <tromey@adacore.com>

	Fix build with GCC 7.5
	A recent change to 'struct field' caused a build failure with GCC
	7.5.0, as reported by Tom de Vries:

	/data/vries/gdb/src/gdb/gdbtypes.h:721:51: error:
	‘field::m_accessibility’ is too small to hold all values of ‘enum
	class accessibility’ [-Werror]
	   ENUM_BITFIELD (accessibility) m_accessibility : 2;
	                                                   ^

	Mark Wielaard pointed out that this was a GCC bug:
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242

	This patch works around the bug by changing several members not to be
	bitfields.  It reduces the size of the enum's underlying type,
	instead.

	I also changed m_bitsize to no longer be a bitfield -- that was done
	for packing reasons in ancient times, but with m_accessibility not
	being a bitfield, this no longer matters.

	I removed fn_field::dummy.  In earlier times it was somewhat normal in
	gdb to have these dummy fields to keep track of any available padding.
	However, since the advent of "ptype/o", there doesn't seem to be any
	need for this.

	This patch does not change the size of struct field, fn_field, or
	decl_field on 64-bit hosts.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add vector permutation instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds permutation instructions for the "XTheadVector"
	extension. The 'th' prefix and the "XTheadVector" extension
	are documented in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		permutation instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VMVXS): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add vector mask instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds mask instructions for the "XTheadVector"
	extension. The 'th' prefix and the "XTheadVector" extension
	are documented in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		mask instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VMPOPCM): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add reductions instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds reductions instructions for the "XTheadVector"
	extension. The 'th' prefix and the "XTheadVector" extension
	are documented in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		reductions instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add floating-point arithmetic instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds floating-point arithmetic instructions for the
	"XTheadVector" extension. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		floating-point arithmetic instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VFSQRTV): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add fixed-point arithmetic instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds fixed-point arithmetic instructions for the
	"XTheadVector" extension. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		fixed-point arithmetic instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VAADDVV): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add integer arithmetic instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds integer arithmetic instructions for the
	"XTheadVector" extension. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		integer arithmetic instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VADCVVM): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add sub-extension XTheadZvamo for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds the sub-extension "XTheadZvamo" for the
	"XTheadVector" extension, and it provides AMO instructions
	for T-Head VECTOR vendor extension. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add support
		for "XTheadZvamo" extension.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* doc/c-riscv.texi:
		* testsuite/gas/riscv/x-thead-vector-zvamo.d: New test.
		* testsuite/gas/riscv/x-thead-vector-zvamo.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VAMOADDWV): New.
		* opcode/riscv.h (enum riscv_insn_class): Add insn class.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add load/store segment instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore it
	makes sense to group them into smaller chunks in form of vendor
	extensions.

	This patch adds provides load/store segment instructions for T-Head VECTOR
	vendor extension, which same as the "Zvlsseg" extension in RVI 0.71 vector
	extension, but belongs to the "XTheadVector" extension. The 'th' prefix
	and the "XTheadVector" extension are documented in a PR for the
	RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add test.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VLSEG2BV): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add load/store instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions. Therefore
	it makes sense to group them into smaller chunks in form of
	vendor extensions.

	This patch adds load/store instructions for the "XTheadVector"
	extension. The 'th' prefix and the "XTheadVector" extension are
	documented in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: Add tests for
		load/store instructions.
		* testsuite/gas/riscv/x-thead-vector.s: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_TH_VLBV): New.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add configuration-setting instructions for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions.
	Therefore it makes sense to group them into smaller chunks
	in form of vendor extensions.

	This patch adds configuration-setting instructions for the "XTheadVector"
	extension. The 'th' prefix and the "XTheadVector" extension are documented
	in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-vector.d: New test.
		* testsuite/gas/riscv/x-thead-vector.s: New test.

	opcodes/ChangeLog:

		* riscv-opc.c: Likewise..

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add CSRs for T-Head VECTOR vendor extension
	T-Head has a range of vendor-specific instructions.
	Therefore it makes sense to group them into smaller chunks
	in form of vendor extensions.

	This patch adds the CSRs for XTheadVector. Because of the
	conflict between encoding and teh 'V' extension, it is implemented
	by alias. The 'th' prefix and the "XTheadVector" extension are
	documented in a PR for the RISC-V toolchain conventions ([1]).

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	gas/ChangeLog:

		* config/tc-riscv.c (enum riscv_csr_class): Add the class for
		the CSRs of the "XTheadVector" extension.
		(riscv_csr_address): Likewise.
		* testsuite/gas/riscv/x-thead-vector-csr-warn.d: New test.
		* testsuite/gas/riscv/x-thead-vector-csr-warn.l: New test.
		* testsuite/gas/riscv/x-thead-vector-csr.d: New test.
		* testsuite/gas/riscv/x-thead-vector-csr.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (DECLARE_CSR_ALIAS): Likewise.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Prefix the CSRs disassembly with 'th'.

2023-11-23  Jin Ma  <jinma@linux.alibaba.com>

	RISC-V: Add T-Head VECTOR vendor extension.
	T-Head has a range of vendor-specific instructions ([2]).
	Therefore it makes sense to group them into smaller chunks
	in form of vendor extensions.

	This patch adds the "XTheadVector" extension, a collection of
	T-Head-specific vector instructions. The 'th' prefix and the
	"XTheadVector" extension are documented in a PR for the RISC-V
	toolchain conventions ([1]).

	Here are some things that need to be explained:
	The "XTheadVector" extension is not a custom-extension, but
	a non-standard non-conforming extension. The encoding space
	of the "TheadVector" instructions overlaps with those of
	the 'V' extension. This encoding space conflict is not on
	purpose, but the result of issues in the past that have
	been resolved since. Therefore, the "XTheadVector" extension
	and the 'V' extension are in conflict.

	[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
	[2] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf

	Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
	Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_check_conflicts): The
		"XTheadVector" extension and the 'V' extension are in conflict.
		(riscv_multi_subset_supports): Likewise..
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* doc/c-riscv.texi:
		* testsuite/gas/riscv/x-thead-vector-fail.d: New test.
		* testsuite/gas/riscv/x-thead-vector-fail.l: New test.
		* testsuite/gas/riscv/x-thead-vector.s: New test.

	include/ChangeLog:

		* opcode/riscv.h (enum riscv_insn_class):

2023-11-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-22  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix AIX thr!= NULL assertion failure during fork.
	In AIX, while we followed the child process and detach on fork was on we hit thr!= NULL assertion failure.

	The reason for the same was GDB core trying to switch to a child thread with tid not set that does not
	exist, since child's ptid was changed to ptid_t (pid, 0, tid) in sync_threadlists() as it was threaded.

	The way this happened was when a new child process is born, its object file will be loaded, calling the new_objfile ()
	in aix-thread.c file from clone_program_space, which is
	called from within follow_fork_inferior. Therefore it end ups syncing threadlists via pd_update ().

	This patch is a fix for the same where pd_update () is called in the wait () or in update_thread_list() hook only.

2023-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix resizing of terminal to 1 or 2 lines
	When starting TUI in a terminal with 3 lines:
	...
	$ echo $LINES
	3
	$ gdb -q -tui
	...
	and resizing the terminal to 2 lines we run into a segfault.

	The problem is that for the source window:
	- the minimum height is 3 (the default), but
	- the maximum height is only 2 because there are only 2 lines.

	This discrepancy eventually leads to a call to newwin in make_window with:
	...
	(gdb) p height
	$1 = 3
	(gdb) p width
	$2 = 56
	(gdb) p y
	$3 = -1
	(gdb) p x
	$4 = 0
	...
	which results in a nullptr.

	This violates the assumption here in tui_apply_current_layout:
	....
	  /* Get the new list of currently visible windows.  */
	  std::vector<tui_win_info *> new_tui_windows;
	  applied_layout->get_windows (&new_tui_windows);
	...
	that get_windows only returns visible windows, which leads to tui_windows
	holding a dangling pointer, which results in the segfault.

	Fix this by:
	- making sure get_windows only returns visible windows, and
	- detecting the situation and dropping windows from the layout if
	  there's no room for them.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR tui/31044
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044

2023-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Allow command window of 1 or 2 lines
	When starting TUI in a terminal with 2 lines (likewise with 1 line):
	...
	$ echo $LINES
	2
	$ gdb -q -tui
	...
	we run into this assert in tui_apply_current_layout:
	...
	  /* This should always be made visible by a layout.  */
	  gdb_assert (TUI_CMD_WIN != nullptr);
	...

	The problem is that for the command window:
	- the minimum height is 3 (the default), but
	- the maximum height is only 2 because there are only 2 lines.

	This discrepancy eventually leads to a call to newwin in make_window with:
	...
	(gdb) p height
	$1 = 3
	(gdb) p width
	$2 = 66
	(gdb) p y
	$3 = -1
	(gdb) p x
	$4 = 0
	(gdb)
	...
	which results in a nullptr, which eventually triggers the assert.

	The easiest way to fix this is to change the minimum height of the command
	window to 1.  However, that would also change behaviour for the case that the
	screen size is 3 lines or more.  For instance, in gdb.tui/winheight.exp the
	number of lines in the terminal is 24, and the test-case checks that the user
	cannot increase the source window height to the point that the command window
	height would be less than 3.

	Fix this by calculating the minimum height of the command window as follows:
	- the default (3) if max_height () allows it, and
	- max_height () otherwise.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR tui/31044
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044

2023-11-22  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Don't import curses.ascii module unless necessary
	I ran into a failure in test-case gdb.python/py-missing-debug.exp with python
	3.6, which was fixed by commit 7db795bc67a ("gdb/python: remove use of
	str.isascii()").

	However, I subsequently ran into a failure with python 3.11:
	...
	(gdb) PASS: $exp: initial checks: debug info no longer found
	source py-missing-debug.py^M
	Traceback (most recent call last):^M
	  File "py-missing-debug.py", line 17, in <module>^M
	    from gdb.missing_debug import MissingDebugHandler^M
	  File "missing_debug.py", line 21, in <module>^M
	    from curses.ascii import isascii, isalnum^M
	  File "/usr/lib64/python3.11/_import_failed/curses.py", line 16, in <module>^M
	    raise ImportError(f"""Module '{failed_name}' is not installed.^M
	ImportError: Module 'curses' is not installed.^M
	Use:^M
	  sudo zypper install python311-curses^M
	to install it.^M
	(gdb) FAIL: $exp: source python script
	...

	Apparently I have the curses module installed for 3.6, but not 3.11.

	I could just install it, but the test-case worked fine with 3.11 before commit
	7db795bc67a.

	Fix this by only using the curses module when necessary, for python <= 3.7.

	Tested on x86_64-linux, with both python 3.6 and 3.11.

2023-11-22  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: cleanup monitor_show_help
	After this commit:

	  commit 0b04e52316079981b2b77124198a405d826a05cd
	  Date:   Sun Jan 19 14:33:37 2014 -0700

	      link gdbserver against libiberty

	we can cleanup how the help text is generated in monitor_show_help.
	This doesn't change the output that the user will see -- it just folds
	multiple monitor_output calls into one.

	There should be no user visible change after this commit.

2023-11-22  Lulu Cai  <cailulu@loongson.cn>

	LoongArch: fix internal error when as handling unsupported modifier.

2023-11-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Simplify C++ type-printing
	The C++ type-printing code had its own variant of the accessibility
	enum.  This patch removes this and changes the code to use the new one
	from gdbtypes.h.

	This patch also changes the C++ code to recognize the default
	accessibility of a class.  This makes ptype a bit more C++-like, and
	lets us remove a chunk of questionable code.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Use enum accessibility in types and member functions
	This changes nested types and member functions to use the new
	'accessibility' enum, rather than separate private/protected flags.
	This is done for consistency, but it also lets us simplify some other
	code in the next patch.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Remove char-based bitfield macros
	This removes the char-based bitfield macros from gdbtypes.h, as they
	are no longer used.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Remove some type field accessor macros
	This removes TYPE_FIELD_PRIVATE, TYPE_FIELD_PROTECTED,
	TYPE_FIELD_IGNORE, and TYPE_FIELD_VIRTUAL.

	In c-varobj.c, match_accessibility can be removed entirely now.  Note
	that the comment before this function was incorrect.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Remove some QUIT calls from need_access_label_p
	I think these invocations of QUIT in need_access_label_p are overkill.
	QUIT is already called from its caller.  This just removes them.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Add field::is_public
	This adds a field::is_public convenience method, and updates one spot
	to use it.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Remove byte vectors from cplus_struct_type
	This removes some byte vectors from cplus_struct_type, moving the
	information into bitfields in holes in struct field.

	A new 'enum accessibility' is added to hold some of this information.
	A similar enum is removed from c-varobj.c.

	Note that the stabs reader treats "ignored" as an accessibility.
	However, the stabs texinfo documents this as a public field that is
	optimized out -- unfortunately nobody has updated the stabs reader to
	use the better value-based optimized-out machinery.  I looked and
	apparently gcc never emitted this visibility value, so whatever
	compiler generated this stab is unknown.  I left a comment in
	gdbtypes.h to this effect.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Print field accessibility inline
	This changes recursive_dump_type to print field accessibility
	information "inline".  This is clearer and preserves the information
	when the byte vectors are removed.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Use .def file to stringify type codes
	This changes recursive_dump_type to reuse the type-codes.def file when
	stringifying type codes.

	This version of the patch changes the "unknown" case to an assert.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-21  Cupertino Miranda  <cupertino.miranda@oracle.com>

	bpf: Fixed register parsing disambiguating with possible symbol.
	This changes parse_bpf_register to detect possible symbols that start with valid
	register name, however due some following characters are not.
	Also changed the regs-for-symbols-pseudo.s, adding some entries that
	should not error if parser is properly detecting the symbol.

2023-11-21  Jan-Benedict Glaw  <jbglaw@lug-owl.de>

	[opcodes] ARC + PPC: Fix -Walloc-size warnings
	Recently, -Walloc-size warnings started to kick in. Fix these two
	calloc() calls to match the intended usage pattern.

	opcodes/ChangeLog:

		* arc-dis.c (init_arc_disasm_info): Fix calloc() call.
		* ppc-dis.c (powerpc_init_dialect): Ditto.

2023-11-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix build of darwin-nat.c
	Patch 743877128 ("gdb: remove regcache's address space") changed the
	signature of darwin_nat_target::cancel_breakpoint, but missing updating
	the class declaration, resulting in:

	      CXX    darwin-nat.o
	    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1154:20: error: out-of-line definition of 'cancel_breakpoint' does not match any declaration in 'darwin_nat_target'
	    darwin_nat_target::cancel_breakpoint (inferior *inf, ptid_t ptid)
	                       ^~~~~~~~~~~~~~~~~
	    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1290:9: error: too many arguments to function call, expected single argument 'ptid', have 2 arguments
	                                        ptid_t (inf->pid, 0, thread->gdb_port)))
	                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.h:129:7: note: 'cancel_breakpoint' declared here
	      int cancel_breakpoint (ptid_t ptid);
	          ^

	Fix that.

	Change-Id: Iedd58b36777eb77bca9e23f94882b217c9c87059

2023-11-21  Tom Tromey  <tromey@adacore.com>

	Refactor DAP queue handling
	A couple of spots in the DAP code use the same workaround for the
	absence of queue.SimpleQueue before Python 3.6.  This patch
	consolidates these into a single spot.

2023-11-21  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Handle memory error in s390_linux_get_syscall_number
	In s390_linux_get_syscall_number, we use read_memory_unsigned_integer, which
	can throw a memory error.

	According to the function comment though, it should return -1 on error:
	...
	/* Retrieve the syscall number at a ptrace syscall-stop.  Return -1
	   upon error. */
	...

	Catch the memory error by using safe_read_memory_unsigned_integer instead,
	similar to how that was fixed for arm in commit eb42bb14895 ("[gdb/tdep] Fix
	catching syscall execve exit for arm").

	Approved-By: Ulrich Weigand <uweigand@de.ibm.com>

2023-11-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix spurious FAILs with examine-backward.exp, again
	Commit 59a561480d5 ("Fix spurious FAILs with examine-backward.exp") describes
	the problem that:
	...
	The test case examine-backward.exp issues the command "x/-s" after the end
	of the first string in TestStrings, but without making sure that this
	string is preceded by a string terminator.  Thus GDB may spuriously print
	some random characters from before that string, and then the test fails.
	...

	The commit fixes the problem by adding a Barrier variable before the TestStrings
	variable:
	...
	+const char Barrier[] = { 0x0 };
	 const char TestStrings[] = {
	...

	There is however no guarantee that Barrier is placed immediately before
	TestStrings.

	Before recent commit 169fe7ab54b ("Change gdb.base/examine-backwards.exp for
	AIX.") on x86_64-linux, I see:
	...
	0000000000400660 R Barrier
	0000000000400680 R TestStrings
	...

	So while the Barrier variable is the first before the TestStrings variable,
	it's not immediately preceding TestStrings.

	After commit 169fe7ab54b:
	...
	0000000000402259 B Barrier
	0000000000402020 D TestStrings
	...
	they're not even in the same section anymore.

	Fix this reliably by adding the zero in the array itself:
	...
	char TestStringsBase[] = {
	  0x0,
	  ...
	};
	char *TestStrings = &TestStringsBase[1];
	...
	and do likewise for TestStringsH and TestStringsW.

	Tested on x86_64-linux.

	PR testsuite/31064
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31064

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb: Use initializers in lambda captures unconditionally
	Initializers in lambda captures were introduced in C++14, and
	conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c.

	Since C++17 is now required by GDB, use this feature unconditionally.

	Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb/disasm.h: Mark callbacks noexcept unconditionally
	Given that C++17 is now a requirement for GDB, update gdb/disasm.h to
	define callback function types noexcept unconditionally.  The pre-C++17
	configuration is not supported anymore.

	Change-Id: I0a38e22b7912c70a11425363a991f0b01614343e
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdbsupport: Replace gdb::invoke_result with std::invoke_result
	Given that GDB now requires C++17, we can replace gdb::invoke_result
	with std::invoke_result which is provided by <type_traits>.

	This patch also removes gdbsupport/invoke-result.h as it is not used
	anymore.

	Change-Id: I7e567356d38d6b3d85d8797d61cfc83f6f933f22
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdbsupport: Remove gdb::string_view
	Now that all places using gdb::string_view have been updated to use
	std::string_view, this patch drops the gdb::string_view implementation
	and the tests which came with it.

	As this drops the unittests/string_view-selftests.c, this also
	implicitly solves PR build/23676, as pointed-out by Tom Tromey.

	Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb: Remove uses of gdb::to_string (const std::string_view &)
	This patch removes all uses of to_string(const std::string_view&) and
	use the std::string ctor or implicit conversion from std::string_view to
	std::string instead.

	A later patch will remove this gdb::to_string while removing
	gdbsupport/gdb_string_view.h.

	Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb: Use std::string_view instead of gdb::string_view
	Given that GDB now requires a C++17, replace all uses of
	gdb::string_view with std::string_view.

	This change has mostly been done automatically:
	- gdb::string_view -> std::string_view
	- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>

	One things which got brought up during review is that gdb::stging_view
	does support being built from "nullptr" while std::sting_view does not.
	Two places are manually adjusted to account for this difference:
	gdb/tui/tui-io.c:tui_getc_1 and
	gdbsupport/format.h:format_piece::format_piece.

	The above automatic change transformed
	"gdb::to_string (const gdb::string_view &)" into
	"gdb::to_string (const std::string_view &)".  The various direct users
	of this function are now explicitly including
	"gdbsupport/gdb_string_view.h".  A later patch will remove the users of
	gdb::to_string.

	The implementation and tests of gdb::string_view are unchanged, they will
	be removed in a following patch.

	Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdbsupport: remove gdb::optional
	The previous patch migrated all the uses of gdb::optional to use
	std::optional instead,  so gdb::optional can be removed entirely
	as well as the self-tests which came with it.

	Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb: Replace gdb::optional with std::optional
	Since GDB now requires C++17, we don't need the internally maintained
	gdb::optional implementation.  This patch does the following replacing:
	  - gdb::optional -> std::optional
	  - gdb::in_place -> std::in_place
	  - #include "gdbsupport/gdb_optional.h" -> #include <optional>

	This change has mostly been done automatically.  One exception is
	gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
	already lives in the gdb namespace.

	Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-21  Lancelot Six  <lancelot.six@amd.com>

	gdb: Use C++17's std::make_unique instead of gdb::make_unique
	gdb::make_unique is a wrapper around std::make_unique when compiled with
	C++17.  Now that C++17 is required, use std::make_unique directly in the
	codebase, and remove gdb::make_unique.

	Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net

2023-11-21  Nick Clifton  <nickc@redhat.com>

	Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
	  PR 31067
	  Fix typo in previous delta: defined -> referenced.

2023-11-21  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix catching syscall execve exit for arm
	When running test-case gdb.base/catch-syscall.exp on a pinebook (64-bit
	aarch64 kernel, 32-bit userland) I run into:
	...
	(gdb) PASS: $exp: execve: syscall(s) execve appears in 'info breakpoints'
	continue^M
	Continuing.^M
	^M
	Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from \
	  /lib/arm-linux-gnueabihf/libc.so.6^M
	(gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve
	continue^M
	Continuing.^M
	process 32392 is executing new program: catch-syscall^M
	Cannot access memory at address 0xf77c6a7c^M
	(gdb) FAIL: $exp: execve: syscall execve has returned
	...

	The memory error is thrown by arm_linux_get_syscall_number, when doing:
	...
	     /* PC gets incremented before the syscall-stop, so read the
	         previous instruction.  */
	      unsigned long this_instr =
	        read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
	...

	The reason for the error is that we're stopped at the syscall exit of syscall
	execve, and the pc is at the first insn of the new exec, which also happens to
	be the first insn in the code segment, so consequently we cannot read the
	previous insn.

	Fix this by detecting the situation by looking at the register state, similar
	to what is done in aarch64_linux_get_syscall_number.

	Furthermore, catch the memory error by using safe_read_memory_unsigned_integer
	and return -1 instead, matching the documented behaviour of
	arm_linux_get_syscall_number.

	Finally, rather than using a hardcoded constant 11, introduce an ad-hoc
	arm_sys_execve.

	Tested on pinebook.

	PR tdep/31071
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31071

2023-11-21  Nick Clifton  <nickc@redhat.com>

	Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
	  PR 31067
	  * linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton.
	  * ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave.

2023-11-21  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix gdb.bas/sigall.exp testcase in AIX.
	In AIX, we are not able to see the message of a signal recieved if a debugee recieves a signal.
	This is a patch to fix the signal handling done incorrectly in AIX.

	We remove the status that represent program recieving a signal and allow host_status_to_waitstatus to
	handle it for us.

2023-11-21  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb: Fix segfault with a big .dynamic section size
	Consider a binary with an erroneous size of the .dynamic section:

	$ readelf -S a.out
	...
	  [24] .dynamic          DYNAMIC          0000000000004c20  00003c20
	       000000fffffffa40  0000000000000010  WA       7     0     8
	...

	This binary causes a segfault in GDB.  GDB is trying to write the .dynamic
	section into memory allocated on the stack with alloca().  However, the
	allocation silently fails and the subsequent access to the memory is
	causing the segfault. (On my node at least.)

	Stack allocation is a bad idea for something of variable size that GDB has
	no control over.  So I changed the code to heap allocation.

	In addition, I changed the type of sect_size to the type that bfd actually
	returns.

	There should be no user visible change after this.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-20  Tom Tromey  <tom@tromey.com>

	Restore .gdb_index v9 display in readelf
	An earlier patch (commit b05efa39 "readelf..debug-dump=loc displays
	bogus base addresses") inadvertently removed support for displaying
	.gdb_index v9 sections.

	This patch corrects the oversight.  I tested this by using readelf on
	an appropriate file.

		* dwarf.c (display_gdb_index): Restore v9 display code.

2023-11-20  Carl Love  <cel@linux.ibm.com>

	PowerPC: Fix test gdb.ada/finish-large.exp
	Function Create_large returns a large data structure.  On PowerPC, register
	r3 contains the address of where the data structure to be returned is to
	be stored.  However, on exit the ABI does not guarantee that r3 has not
	been changed.  The GDB finish command prints the return value of the
	function at the end of the function.  GDB needs to use the
	DW_TAG_call_site information to determine the value of r3 on entry to
	the function to correctly print the return value at the end of the
	function.  The test must be compiled with -fvar-tracking for the
	DW_TAG_call_site information to be included in the executable file.

	This patch adds the -fvar-tracking option to the compile line if the
	option is supported.

	The patch fixes the one regression error for the test on PowerPC.

	The patch has been tested on Power 10 and X86-64 with no regressions.

2023-11-20  Nick Alcock  <nick.alcock@oracle.com>

	libctf: adding CU mappings should be idempotent
	When CTF finds conflicting types, it usually shoves each definition
	into a CTF dictionary named after the compilation unit.

	The intent of the obscure "cu-mapped link" feature is to allow you to
	implement custom linkers that shove the definitions into other, more
	coarse-grained units (say, one per kernel module, even if a module consists
	of more than one compilation unit): conflicting types within one of these
	larger components are hidden from name lookup so you can only look up (an
	arbitrary one of) them by name, but can still be found by chasing type graph
	links and are still fully deduplicated.

	You do this by calling
	ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly,
	with different "CU name"s: the ctf_link() following that will put all
	conflicting types found in "CU name"s sharing a "bigger lump name" into a
	child dict in an archive member named "bigger lump name".

	So it's clear enough what happens if you call it repeatedly with the same
	"bigger lump name" more than once, because that's the whole point of it: but
	what if you call it with the same "CU name" repeatedly?

	ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name");
	ctf_link_add_cu_mapping (fp, "CU name", "other name");

	This is meant to be the same as just doing the second of these, as if the
	first was never called.  Alas, this isn't what happens, and what you get is
	instead a bit of an inconsistent mess: more or less, the first takes
	precedence, which is the exact opposite of what we wanted.

	Fix this to work the right way round.

	(I plan to add support for CU-mapped links to GNU ld, mainly so that we can
	properly *test* this machinery.)

	libctf/ChangeLog:

		* ctf-link.c (ctf_create_per_cu): Note the behaviour of
		repeatedly adding FROMs.
		(ctf_link_add_cu_mapping): Implement that behavour.

2023-11-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix reopen_exec_file for files with target: prefix
	Following on from this commit:

	  commit f2c4f78c813a9cef38b7e9c9ad18822fb9e19345
	  Date:   Thu Sep 21 16:35:30 2023 +0100

	      gdb: fix reread_symbols when an objfile has target: prefix

	In this commit I update reopen_exec_file to correctly handle
	executables with a target: prefix.  Before this commit we used the
	system 'stat' call, which obviously isn't going to work for files with
	a target: prefix (files located on a possibly remote target machine).

	By switching to bfd_stat we will use remote fileio to stat the remote
	files, which means we should now correctly detect changes in a remote
	executable.

	The program_space::ebfd_mtime variable, with which we compare the
	result of bfd_stat is set with a call to bfd_get_mtime, which in turn
	calls bfd_stat, so comparing to the result of calling bfd_stat makes
	sense (I think).

	As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
	BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
	will always return the time at which the BFD was created.  As a result
	comparing the results will always show the file having changed.

	I don't believe that GDB can set the main executable to an in-memory
	BFD object, so, in this commit, I simply assert that the executable is
	not in-memory.  If this ever changes then we would need to decide how
	to handle this case -- always reload, or never reload.  The assert
	doesn't appear to trigger for our current test suite.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: move all bfd_cache_close_all calls in gdb_bfd.c
	In the following commit I ran into a problem.  The next commit aims to
	improve GDB's handling of the main executable being a file on a remote
	target (i.e. one with a 'target:' prefix).

	To do this I have replaced a system 'stat' call with a bfd_stat call.

	However, doing this caused a regression in gdb.base/attach.exp.

	The problem is that the bfd library caches open FILE* handles for bfd
	objects that it has accessed, which is great for short-lived, non
	interactive programs (e.g. the assembler, or objcopy, etc), however,
	for GDB this caching causes us a problem.

	If we open the main executable as a bfd then the bfd library will
	cache the open FILE*.  If some time passes, maybe just sat at the GDB
	prompt, or with the inferior running, and then later we use bfd_stat
	to check if the underlying, on-disk file has changed, then the bfd
	library will actually use fstat on the underlying file descriptor.
	This is of course slightly different than using system stat on with
	the on-disk file name.

	If the on-disk file has changed then system stat will give results for
	the current on-disk file.  But, if the bfd cache is still holding open
	the file descriptor for the original on-disk file (from before the
	change) then fstat will return a result based on the original file,
	and so show no change as having happened.

	This is a known problem in GDB, and so far this has been solved by
	scattering bfd_cache_close_all() calls throughout GDB.  But, as I
	said, in the next commit I've made a change and run into a
	problem (gdb.base/attach.exp) where we are apparently missing a
	bfd_cache_close_all() call.

	Now I could solve this problem by adding a bfd_cache_close_all() call
	before the bfd_stat call that I plan to add in the next commit, that
	would for sure solve the problem, but feels a little crude.

	Better I think would be to track down where the bfd is being opened
	and add a corresponding bfd_cache_close_all() call elsewhere in GDB
	once we've finished doing whatever it is that caused us to open the
	bfd in the first place.

	This second solution felt like the better choice, so I tracked the
	problem down to elf_locate_base and fixed that.  But that just exposed
	another problem in gdb_bfd_map_section which was also re-opening the
	bfd, so I fixed this (with another bfd_cache_close_all() call), and
	that exposed another issue in gdbarch_lookup_osabi... and at this
	point I wondered if I was approaching this problem the wrong way...

	.... And so, I wonder, is there a _better_ way to handle these
	bfd_cache_close_all() calls?

	I see two problems with the current approach:

	  1. It's fragile.  Folk aren't always aware that they need to clear
	  the bfd cache, and this feels like something that is easy to
	  overlook in review.  So adding new code to GDB can innocently touch
	  a bfd, which populates the cache, which will then be a bug that can
	  lie hidden until an on-disk file just happens to change at the wrong
	  time ... and GDB fails to spot the change.  Additionally,

	  2. It's in efficient.  The caching is intended to stop the bfd
	  library from continually having to re-open the on-disk file.  If we
	  have a function that touches a bfd then often that function is the
	  obvious place to call bfd_cache_close_all.  But if a single GDB
	  command calls multiple functions, each of which touch the bfd, then
	  we will end up opening and closing the same on-disk file multiple
	  times.  It feels like we would be better postponing the
	  bfd_cache_close_all call until some later point, then we can benefit
	  from the bfd cache.

	So, in this commit I propose a new approach.  We now clear the bfd
	cache in two places:

	  (a) Just before we display a GDB prompt.  We display a prompt after
	  completing a command, and GDB is about to enter an idle state
	  waiting for further input from the user (or in async mode, for an
	  inferior event).  If while we are in this idle state the user
	  changes the on-disk file(s) then we would like GDB to notice this
	  the next time it leaves its idle state, e.g. the next time the user
	  executes a command, or when an inferior event arrives,

	  (b) When we resume the inferior.  In synchronous mode, resuming the
	  inferior is another time when GDB is blocked and sitting idle, but
	  in this case we don't display a prompt.  As with (a) above, when an
	  inferior event arrives we want GDB to notice any changes to on-disk
	  files.

	It turns out that there are existing observers for both of these
	cases (before_prompt and target_resumed respectively), so my initial
	thought was that I should attach to these observers in gdb_bfd.c, and
	in both cases call bfd_cache_close_all().

	And this does indeed solve the gdb.base/attach.exp problem that I see
	with the following commit.

	However, I see a problem with this solution.

	Both of the observers I'm using are exposed through the Python API as
	events that a user can hook into.  The user can potentially run any
	GDB command (using gdb.execute), so Python code might end up causing
	some bfds to be reopened, and inserted into the cache.

	To solve this one solution would be to add a bfd_cache_close_all()
	call into gdbpy_enter::~gdbpy_enter().  Unfortunately, there's no
	similar enter/exit object for Guile, though right now Guile doesn't
	offer the same event API, so maybe we could just ignore that
	problem... but this doesn't feel great.

	So instead, I think a better solution might be to not use observers
	for the bfd_cache_close_all() calls.  Instead, I'll call
	bfd_cache_close_all() directly from core GDB after we've notified the
	before_prompt and target_resumed observers, this was we can be sure
	that the cache is cleared after the observers have run, and before GDB
	enters an idle state.

	This commit also removes all of the other bfd_cache_close_all() calls
	from GDB.  My claim is that these are no longer needed.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-20  Guinevere Larsen  <blarsen@redhat.com>

	gdb/infrun: simplify process_event_stop_test
	The previous commit introduced some local variables to make some if
	statements simpler. This commit uses them more liberally throughout the
	process_event_stop_test in order to simplify the function a little more.
	No functional changes are expected.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-20  Guinevere Larsen  <blarsen@redhat.com>

	gdb/record: print frame information when exiting a recursive call
	Currently,  when GDB is reverse stepping out of a function into the same
	function due to a recursive call, it doesn't print frame information, as
	reported by PR record/29178. This happens because when the inferior
	leaves the current frame, GDB decides to refresh the step information,
	clobbering the original step_frame_id, making it impossible to figure
	out later on that the frame has been changed.

	This commit changes GDB so that, if we notice we're in this exact
	situation, we won't refresh the step information.

	Because of implementation details, this change can cause some debug
	information to be read when it normally wouldn't before, which showed up
	as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
	isn't a problem, the test was changed to allow for the new output.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178
	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-18  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: bpf: do not allow referring to register names as symbols in operands
	2023-11-18  Jose E. Marchesi  <jemarch@gnu.org>

		* config/tc-bpf.c (parse_bpf_register): Move before
		bpf_parse_name.
		(bpf_parse_name): Do not allow using symbols that are also
		register names as operands in pseudo-c syntax.
		* testsuite/gas/bpf/regs-for-symbols-pseudoc.d: New file.
		* testsuite/gas/bpf/regs-for-symbols-pseudoc.s: Likewise.
		* testsuite/gas/bpf/regs-for-symbols-pseudoc.l: Likewise.
		* doc/c-bpf.texi (BPF Registers): Document that it is not possible
		to refer to register names as symbols in instruction operands.

2023-11-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-17  David Faust  <david.faust@oracle.com>

	bpf: avoid creating wrong symbols while parsing
	To support the "pseudo-C" asm dialect in BPF, the BPF parser must often
	attempt multiple different templates for a single instruction. In some
	cases this can cause the parser to incorrectly parse part of the
	instruction opcode as an expression, which leads to the creation of a
	new undefined symbol.

	Once the parser recognizes the error, the expression is discarded and it
	tries again with a new instruction template. However, symbols created
	during the process are added to the symbol table and are not removed
	even if the expression is discarded.

	This is a problem for BPF: generally the assembled object will be loaded
	directly to the Linux kernel, without being linked. These erroneous
	parser-created symbols are rejected by the kernel BPF loader, and the
	entire object is refused.

	This patch remedies the issue by tentatively creating symbols while
	parsing instruction operands, and storing them in a temporary list
	rather than immediately inserting them into the symbol table. Later,
	after the parser is sure that it has correctly parsed the instruction,
	those symbols are committed to the real symbol table.

	This approach is modeled directly after Jan Beulich's patch for RISC-V:

	  commit 7a29ee290307087e1749ce610207e93a15d0b78d
	  RISC-V: adjust logic to avoid register name symbols

	Many thanks to Jan for recognizing the problem as similar, and pointing
	me to that patch.

	gas/

		* config/tc-bpf.c (parsing_insn_operands): New.
		(parse_expression): Set it here.
		(deferred_sym_rootP, deferred_sym_lastP): New.
		(orphan_sym_rootP, orphan_sym_lastP): New.
		(bpf_parse_name): New.
		(parse_error): Clear deferred symbol list on error.
		(md_assemble): Clear parsing_insn_operands. Commit deferred
		symbols to symbol table on successful parse.
		* config/tc-bpf.h (md_parse_name): Define to...
		(bpf_parse_name): ...this. New prototype.
		* testsuite/gas/bpf/asm-extra-sym-1.s: New test source.
		* testsuite/gas/bpf/asm-extra-sym-1.d: New test.
		* testsuite/gas/bpf/bpf.exp: Run new test.

2023-11-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass address_space to target dcache functions
	A simple refactor to make the reference to current_program_space bubble
	up one level.  No behavior changes expected.

	Change-Id: I237cf2f45ae73c35bcb433ce40e3c03cef6b87e2

2023-11-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove get_current_regcache
	Remove get_current_regcache, inlining the call to get_thread_regcache in
	callers.  When possible, pass the right thread_info object known from
	the local context.  Otherwise, fall back to passing `inferior_thread ()`.

	This makes the reference to global context bubble up one level, a small
	step towards the long term goal of reducing the number of references to
	global context (or rather, moving those references as close as possible
	to the top of the call tree).

	No behavior change expected.

	Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6

2023-11-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove regcache's address space
	While looking at the regcache code, I noticed that the address space
	(passed to regcache when constructing it, and available through
	regcache::aspace) wasn't relevant for the regcache itself.  Callers of
	regcache::aspace use that method because it appears to be a convenient
	way of getting the address space for a thread, if you already have the
	regcache.  But there is always another way to get the address space, as
	the callers pretty much always know which thread they are dealing with.
	The regcache code itself doesn't use the address space.

	This patch removes anything related to address_space from the regcache
	code, and updates callers to get it from the thread in context.  This
	removes a bit of unnecessary complexity from the regcache code.

	The current get_thread_arch_regcache function gets an address_space for
	the given thread using the target_thread_address_space function (which
	calls the target_ops::thread_address_space method).  This suggest that
	there might have been the intention of supporting per-thread address
	spaces.  But digging through the history, I did not find any such case.
	Maybe this method was just added because we needed a way to get an
	address space from a ptid (because constructing a regcache required an
	address space), and this seemed like the right way to do it, I don't
	know.

	The only implementations of thread_address_space and
	process_stratum_target::thread_address_space and
	linux_nat_target::thread_address_space, which essentially just return
	the inferior's address space.  And thread_address_space is only used in
	the current get_thread_arch_regcache, which gets removed.  So, I think
	that the thread_address_space target method can be removed, and we can
	assume that it's fine to use the inferior's address space everywhere.
	Callers of regcache::aspace are updated to get the address space from
	the relevant inferior, either using some context they already know
	about, or in last resort using the current global context.

	So, to summarize:

	 - remove everything in regcache related to address spaces
	 - in particular, remove get_thread_arch_regcache, and rename
	   get_thread_arch_aspace_regcache to get_thread_arch_regcache
	 - remove target_ops::thread_address_space, and
	   target_thread_address_space
	 - adjust all users of regcache::aspace to get the address space another
	   way

	Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7

2023-11-17  Tom Tromey  <tom@tromey.com>

	Remove extraneous blocks from dwarf2/read.c:new_symbol
	dwarf2/read.c:new_symbol has some extra braces in a couple of 'case's.
	These read weirdly to me, and since they aren't necessary, this patch
	removes the braces and reindents the bodies.  Tested by rebuilding.

2023-11-17  Joseph Myers  <joseph@codesourcery.com>

	Fix read_ranges for 32-bit long
	bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which
	doesn't work correctly when long is 32-bit and bfd_vma is 64-bit
	(observed as "nm -l" being very slow for mingw64 host; probably causes
	issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64).
	Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere.

2023-11-17  Tom Tromey  <tromey@adacore.com>

	Ignore static members in NoOpStructPrinter
	Hannes' patch to show local variables in the TUI pointed out that
	NoOpStructPrinter should ignore static members.  This patch implements
	this.

2023-11-17  Tom Tromey  <tromey@adacore.com>

	Implement the notStopped DAP response
	DAP specifies that a request can fail with the "notStopped" message if
	the inferior is running but the request requires that it first be
	stopped.

	This patch implements this for gdb.  Most requests are assumed to
	require a stopped inferior, and the exceptions are noted by a new
	'request' parameter.

	You may notice that the implementation is a bit racy.  I think this is
	inherent -- unless the client waits for a stop event before sending a
	request, the request may be processed at any time relative to a stop.

	https://sourceware.org/bugzilla/show_bug.cgi?id=31037

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2023-11-17  Tom Tromey  <tromey@adacore.com>

	Remove ExecutionInvoker
	ExecutionInvoker is no longer really needed, due to the previous DAP
	refactoring.  This patch removes it in favor of an ordinary function.
	One spot (the 'continue' request) could still have used it, but is
	more succinctly expressed as a lambda.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2023-11-17  Tom Tromey  <tromey@adacore.com>

	Automatically run (most) DAP requests in gdb thread
	Nearly every DAP request implementation forwards its work to the gdb
	thread, using send_gdb_with_response.  This patch refactors the
	'request' decorator to make this automatic, and to provide some
	parameters so that the unusual requests can express their needs as
	well.

	In a few spots this simplifies the code by removing an unnecessary
	helper function.  This could be done in more places as well if we
	wanted.

	The main motivation for this patch is that I thought it would be
	helpful for cancellation.  I am still working on that, but meanwhile
	the parameterization of 'request' makes it easy to handle the
	'notStopped' response as well.

	Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>

2023-11-17  YunQiang Su  <yunqiang.su@cipunited.com>

	Gold/MIPS: Add targ_extra_size=64 for mips32 triples

2023-11-17  Tom Tromey  <tromey@adacore.com>

	Handle StackFrameFormat in DAP
	DAP specifies a StackFrameFormat object that can be used to change how
	the "name" part of a stack frame is constructed.  While this output
	can already be done in a nicer way (and also letting the client choose
	the formatting), nevertheless it is in the spec, so I figured I'd
	implement it.

	While implementing this, I discovered that the current code does not
	correctly preserve frame IDs across requests.  I rewrote frame
	iteration to preserve this, and it turned out to be simpler to combine
	these patches.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475

2023-11-17  Pedro Alves  <pedro@palves.net>

	Fix AMD_DBGAPI_SCOPED_DEBUG_START_END wrong setting
	The AMD_DBGAPI_SCOPED_DEBUG_START_END macro in gdb/amd-dbgapi-target.c
	is incorrectly controlled by "set debug infrun", while it should be
	controlled by "set debug amd-dbgapi" instead.  This commit fixes it.

	Change-Id: I8ec2b1a4b9980c2d565a8aafd060ed070eeb3b29

2023-11-17  Jan Beulich  <jbeulich@suse.com>

	x86: improve a few diagnostics
	PR gas/31043
	"unsupported instruction ..." can mean about anything, and can also be
	mistaken to mean something that isn't meant. Replace most of its uses by
	more specific diagnostics,

	While there also take the opportunity and purge the no longer used
	invalid_register_operand enumerator.

2023-11-17  Jan Beulich  <jbeulich@suse.com>

	x86: don't allow pseudo-prefixes to be overridden by legacy suffixes
	Deprecated functionality would better not win over its modern
	counterparts.

	x86: CPU-qualify {disp16} / {disp32}
	{disp16} is invalid to use in 64-bit mode, while {disp32} is invalid to
	use on pre-386 CPUs. The latter, also affecting other (real) prefixes,
	further requires that like for insns we fully check the CPU flags; till
	now only Cpu64/CpuNo64 were taken into consideration.

	x86: use IS_ELF
	... instead of (inefficiently) open-coding it.

2023-11-17  Jan Beulich  <jbeulich@suse.com>

	x86: conditionally hide object-format-specific functions
	ELF-only functions don't need to be built when dealing with a non-ELF
	target. md_section_align() also doesn't need to be a function when
	dealing with non-AOUT targets. Similarly tc_fix_adjustable() can be a
	simple macro when building non-ELF targets.

	Furthermore x86_elf_abi is already used in ELF-only code sections, with
	one exception. By adjusting that, the otherwise bogusly named variable
	can also be confined to just ELF builds.

2023-11-17  Jan Beulich  <jbeulich@suse.com>

	x86: fold conditionals in check_long_reg()
	Simplify the code follow ing what check_{,q}word_reg() already do. This
	the also eliminates a stale comment talking about a warning when an
	error is raised. While there, correct a similarly stale comment in
	check_qword_reg() while there.

2023-11-17  Jan Beulich  <jbeulich@suse.com>

	x86-64: extend expected-size check in check_qword_reg()
	Due to a missing check "crc32q %al, %rax" was wrongly translated to the
	encoding of "crc32q %rax, %rax", rather than being rejected as invalid.
	(The mnemonic suffix describes the source operand, not the destination
	one.)

	Note that check_{word,long}_reg() do not (currently) appear to require
	similar amending, as there are no insn templates permitting an L or W
	suffix and having an operand which allows for Reg8 and Reg64, but
	neither Reg16 nor Reg32.

2023-11-17  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add more relaxation testcases
	1. .so relaxation testcase
	2. ld --no-relax testcase
	3. segment alignment testcase

	LoongArch: Modify link_info.relax_pass from 3 to 2
	The first pass handles R_LARCH_RELAX relocations, the second pass
	handles R_LARCH_ALIGN relocations.

	LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition
	Previously the condition prevented shared objects from being relaxed.
	To remove the limitation, we need to update program header size and
	.eh_frame_hdr size before relaxation.

	LoongArch: Multiple relax_trip in one relax_pass
	If deleting instructions in one relax_trip, set again to true to start the
	next relax_trip.

	LoongArch: Directly delete relaxed instuctions in first relaxation pass
	Directly delete relaxed instuctions in first relaxation pass, not use
	R_LARCH_DELETE relocation. If not, the PC-relative offset may increase.

	LoongArch: Fix ld --no-relax bug
	When calling ld with --no-relax, pcalau12i + ld.d still can be relaxed.
	This patch fix this bug and pcalau12i + ld.d can be relaxed with --relax.

2023-11-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove two uses of obstack
	Remove uses of obstack in the code generating the libraries XML for
	Windows and AIX.  Use std::string instead.  I'm not able to test this
	change, unfortunately.

	Change-Id: I28480913337e3fe8d6c31e551626931e6b1367ef
	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-16  Tom Tromey  <tom@tromey.com>

	Fix small bug in compile.exp
	compile.exp generally does not work for me on Fedora 38.  However, I
	sent a GCC patch to fix the plugin crash.  With that patch, I get this
	error from one test in compile.exp:

	gdb command line:1:22: warning: initialization of 'int (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]

	This patch adds a cast to compile.exp.  This makes the test pass.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-11-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove use of str.isascii()
	This commit:

	  commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
	  Date:   Sun Oct 15 22:48:42 2023 +0100

	      gdb: implement missing debug handler hook for Python

	introduced a use of str.isascii(), which was only added in Python 3.7.

	This commit switches to use curses.ascii.isascii(), as this was
	available in 3.6.

	The same is true for str.isalnum(), which is replaced with
	curses.ascii.isalnum().

	There should be no user visible changes after this commit.

2023-11-16  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for VMSA feature enhancements.
	This patch adds the permission model enhancement and memory
	attribute index enhancement features and their corresponding
	system registers in AArch64 assembler.
	Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE)
	Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE)
	Memory Attribute Index Enhancement (FEAT_AIE)
	Extension to Translation Control Registers (FEAT_TCR2)

	These features are available by default from Armv9.4-A architecture.

2023-11-16  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add new AT system instructions.
	This patch adds 3 new AT system instructions through FEAT_ATS1A
	feature, which are available by default from Armv9.4-A architecture.

2023-11-16  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support to new features in RAS extension.
	This patch also adds support for:
	1. FEAT_RASv2 feature and "ERXGSR_EL1" system register.
	RASv2 feature is enabled by passing +rasv2 to -march
	(eg: -march=armv8-a+rasv2).

	2. FEAT_SCTLR2 and following system registers.
	SCTLR2_EL1, SCTLR2_EL12, SCTLR2_EL2 and SCTLR2_EL3.

	3. FEAT_FGT2 and following system registers.
	HDFGRTR2_EL2, HDFGWTR2_EL2, HFGRTR2_EL2, HFGWTR2_EL2

	4. FEAT_PFAR and following system registers.
	PFAR_EL1, PFAR_EL2 and PFAR_EL12.

	FEAT_RASv2, FEAT_SCTLR2, FEAT_FGT2 and FEAT_PFAR features are by default
	enabled from Armv9.4-A architecture.

	This patch also adds support for two read only system registers
	id_aa64mmfr3_el1 and id_aa64mmfr4_el1, which are available from
	Armv8-A Architecture.

2023-11-16  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add features to the Statistical Profiling Extension.
	This patch adds features to the Statistical Profiling Extension,
	identified as FEAT_SPEv1p4, FEAT_SPE_FDS, and FEAT_SPE_CRR, which
	are enabled by default from Armv9.4-A.

	Also adds support for system register "pmsdsfr_el1".

2023-11-16  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add SLC target for PRFM instruction.
	This patch adds support for FEAT_PRFMSLC feature which enables
	SLC target for PRFM instructions.

2023-11-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/NEWS: merge two 'New commands' sections
	Spotted that we'd gained two 'New commands' sections in our 'Changes
	since GDB 14' NEWS file block.  I've merged them together.

	Also, one of these two sections was actually called 'New Commands',
	however, all the other places in the NEWS file use 'New commands', so
	I've changed to use that.

2023-11-16  Vladislav Khmelevsky  <och95@yandex.ru>

	Fix emit-relocs for aarch64 gold
	Fix relocation offsets values for the relaxed input sections the same
	way it was fixed for the sections in PR21430.

2023-11-16  Ying Huang  <ying.huang@oss.cipunited.com>

	sim: mips: Change E_MIPS_* to EF_MIPS_*
	According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
	and glibc, we also need to change it here to keep same style.
	We can refer to this commit record:
	https://sourceware.org/pipermail/binutils/2023-October/129904.html

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-16  Ying Huang  <ying.huang@oss.cipunited.com>

	gdb: mips: Change E_MIPS_* to EF_MIPS_*
	According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
	and glibc, we also need to change it here to keep same style.
	We can refer to this commit record:
	https://sourceware.org/pipermail/binutils/2023-October/129904.html

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-15  Pedro Alves  <pedro@palves.net>

	Fix gdb.threads/threads-after-exec.exp race
	Simon noticed that gdb.threads/threads-after-exec.exp was racy.  You
	can consistenly reproduce it (at git hash
	319b460545dc79280e2904dcc280057cf71fb753), with:

	  $ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp"

	gdb.log shows:

	  (...)
	  Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290
	   in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec
	  info threads
	    Id   Target Id                         Frame
	  * 3    process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads
	  (...)
	  maint info linux-lwps
	  LWP Ptid          Thread ID
	  1443269.1443269.0 1.3
	  (gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps

	The FAILs happen because the .exp file expects that after the exec,
	the only thread has GDB thread number 1, but it has instead 3.

	This is yet another case of zombie leader detection making things a
	bit fuzzy.

	In the passing case, we have:

	 continue
	 Continuing.
	 [New Thread 0x7ffff7bff640 (LWP 603183)]
	 [Thread 0x7ffff7bff640 (LWP 603183) exited]
	 process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec

	While in the failing case, we have (note remarks on the rhs):

	 continue
	 Continuing.
	 [New Thread 0x7ffff7bff640 (LWP 600205)]
	 [Thread 0x7ffff7f95740 (LWP 600202) exited]   <<< gdb deletes leader thread, thread 1.
	 [New LWP 600202]                              <<< gdb adds it back -- this is now thread 3.
	 [Thread 0x7ffff7bff640 (LWP 600205) exited]
	 process 600202 is executing new program: .../threads-after-exec/threads-after-exec

	The testcase only has two threads, yet GDB presented the exec for
	thread 3.  This is GDB deleting the leader (the backend detected it
	was zombie, due to the exec), and then adding the leader back when it
	saw the exec event.

	I've recorded some thoughts about this in PR gdb/31069.

	For now, this commit just makes the testcase cope with the non-one
	thread number, as the number is not important for what this test is
	exercising.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069
	Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae

2023-11-15  Tom Tromey  <tromey@adacore.com>

	Check gdb_python_module in gdbpy_handle_missing_debuginfo
	If you run gdb in the build tree without --data-directory, on a
	program that does not have debug info, it will crash, because
	gdbpy_handle_missing_debuginfo unconditionally uses gdb_python_module.

	Other code in gdb using gdb_python_module checks it first and it
	seemes harmless to do the same thing here.  (gdb_python_initialized
	does not cover this case so that python can be partially initialized
	and still somewhat work.)

2023-11-15  Tom Tromey  <tromey@adacore.com>

	Minor cleanups in ada-nested.exp
	This changes ada-nested.exp to fix a test name (the test expects three
	variables but is named "two"), and to iterate over all the variables
	that are found.  It also adds a workaround to a problem Tom de Vries
	found with an older version of GNAT -- it emits a duplicate "x".

2023-11-15  Sam James  <sam@gentoo.org>

	Finalized intl-update patches (trois)
	Doing this on behalf of Arsen as obvious. Hopefully the last fixup.

	* gdb: Regenerate.
	* gnulib: Regenerate.

2023-11-15  Sam James  <sam@gentoo.org>

	Finalized intl-update patches (deux)
	Doing this on behalf of Arsen as obvious.

	* gdb: Regenerate.
	* gdbserver: Regenerate.
	* gprofng: Regenerate.

2023-11-15  YunQiang Su  <yunqiang.su@cipunited.com>

	GAS/MIPS: add "--defsym r6=" for default when it's r6
	  * testsuite/gas/mips/mips.exp (mips_arch_create): Add "--defsym r6=" to as_flags for r6 targets.

2023-11-15  Arsen Arsenovi?  <arsen@aarsen.me>

	Finalized intl-update patches
	  * intl: Remove directory.  Replaced with out-of-tree GNU gettext.
	  * .gitignore: Add '/gettext*'.
	  * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag.  Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing.
	  * configure: Regenerate.
	  * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext.
	  * Makefile.in: Regenerate.
	  * src-release.sh: Remove references to the intl/ directory.

2023-11-15  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Fix Irix gas testcases about pdr section
	  * testsuite/gas/elf/elf.exp (section2): Add -mpdr option to assembler command line for mips-irix targets.
	  * testsuite/gas/mips/elf-rel26.d: Add -mpdr command line option.
	  * testsuite/gas/mips/mips16-e.d: Likewise.
	  * testsuite/gas/mips/mips16-f.d: Likewise.
	  * testsuite/gas/mips/mips16-hilo-match.d: Likewise.
	  * testsuite/gas/mips/mips16-e-irix.d: Likewise.
	  * testsuite/gas/mips/call-nonpic-1.d: Adjust regexp to allow for mips-irix targets.
	  * testsuite/gas/mips/irix-no-pdr.d: New test file.
	  * testsuite/gas/mips/mips.exp: Run new test for mips-irix targets.

2023-11-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Remove path name from test case
	'runtest' complains about a path in a test name, from the new test
	case py-missing-debug.exp.

	This patch fixes the problem by providing an explicit test name to
	gdb_test.  I chose something very basic because the block in question
	is already wrapped in with_test_prefix.

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Remove some redundant "break"s
	I found some "break" statements that follow "return" or a call to a
	noreturn function.  These aren't needed, and the compiler would warn
	if they were.  So, this patch removes them.

	Tested by rebuilding.

2023-11-14  Tom Tromey  <tom@tromey.com>

	Filter invalid encodings from Linux thread names
	On Linux, a thread can only be 16 bytes (including the trailing \0).
	A user sent in a test case where this causes a truncated UTF-8
	sequence, causing gdbserver to create invalid XML.

	I went back and forth about different ways to solve this, and in the
	end decided to fix it in gdbserver, with the reason being that it
	seems important to generate correct XML for the <thread> response.

	I am not totally sure whether the call to setlocale could have
	unplanned consequences.  This is needed, though, for nl_langinfo to
	return the correct result.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Update gdb.Symbol.is_variable documentation
	Kévin found a bug in an earlier version of this series that was based
	on a misconception I had about Symbol.is_variable.  This patch fixes
	the documentation to explain the method a bit better.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Handle the static link in FrameDecorator
	A co-worker requested that the DAP scope for a nested function's frame
	also show the variables from outer frames.  DAP doesn't directly
	support this notion, so this patch arranges to put these variables
	into the inner frames "Locals" scope.

	I chose to do this only for DAP.  For CLI and MI, gdb currently does
	not do this, so this preserves the behavior.

	Note that an earlier patch (see commit 4a1311ba) removed some code
	that seemed to do something similar.  However, that code did not
	actually work.

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Fix a bug in DAP scopes code
	While working on static links, I noticed that the DAP scopes code does
	not handle the scenario where a frame decorator returns None.  This
	situation should be handled identically to a frame decorator returning
	an empty iterator.

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Add gdb.Frame.static_link method
	This adds a new gdb.Frame.static_link method to the gdb Python layer.
	This can be used to find the static link frame for a given frame.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-11-14  Tom Tromey  <tromey@adacore.com>

	Move follow_static_link to frame.c
	This moves the follow_static_link function to frame.c and exports it
	for use elsewhere.  The API is changed slightly to make it more
	generically useful.

	Add block::function_block
	This adds the method block::function_block, to easily access a block's
	enclosing function block.

	Add two convenience methods to block
	This adds a couple of convenience methods, block::is_static_block and
	block::is_global_block.

2023-11-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb/MAINTAINERS: add Guinevere Larsen as record-full maintainer
	Change-Id: I67d8361560ce0fa553b2983184c9d18df8dbeb4a

	gdb/MAINTAINERS: add Luis Machado as global maintainer
	Change-Id: I211d64393f5c0da3c9ce1fcf5486504d34ed38f4

	gdb/MAINTAINERS: add John Baldwin as global maintainer
	Change-Id: Ic9164fd19c3da1381302a17176e8f0f814e9ac6c

2023-11-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: normalize whitespaces in MAINTAINERS
	Replace some spaces with tabs.

	Change-Id: I89bbabd6610219649e7e99cd0dd7b0ed66d69b09

2023-11-14  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Factor out tui_noscroll_window et al
	I noticed that tui_locator_window has an empty do_scroll_vertical and
	do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't
	have:
	...
	  bool can_scroll () const override
	  {
	    return false;
	  }
	...

	I suspect that it probably doesn't matter, but regardless it's good to have
	the same implementations of basic properties in all windows.

	Ensure this by adding a class tui_noscroll_window, that has:
	- an empty do_scroll_vertical and do_scroll_horizontal, and
	- a can_scroll returning false
	which both tui_locator_window and tui_cmd_window inherit.

	Make all methods final to ensure no accidental overrides are left in the
	inheriting classes.

	Likewise add new classes representing basic window properties:
	- tui_nofocus_window,
	- tui_oneline_window,
	- tui_nobox_window,
	- tui_norefresh_window, and
	- tui_always_visible_window.

	The changes are only a refactoring, apart from adding the "final", which does
	limit the range of behaviours for subclasses.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: refactor make-target-delegates.py's ARGTYPES
	Refactor the ARGTYPES regular expression in make-target-delegates.py
	to eliminate '.*' for better control on what is matched.  Also,
	simplify the "E" match group, for which the optional SYMBOL becomes
	redundant because that case can be matched by the "T" group.

	After applying this patch, running './make-target-delegates.py' does not
	change anything in 'target-delegates.c'.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: regenerate target-delegates.c
	I ran './make-target-delegates.py' and there is one minor difference,
	where an older style declaration is converted to a newer
	initialization style.  Add this change.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-11-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/stepi-over-clone.exp regexp
	I ran into the following FAIL:
	...
	(gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
	continue^M
	Continuing.^M
	^M
	Catchpoint 2 (call to syscall clone), clone () at \
	  ../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M
	warning: 78     ../sysdeps/unix/sysv/linux/x86_64/clone.S: \
	  No such file or directory^M
	(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
	...

	All but one regexps in the .exp file use "clone\[23\]?" with "?" to
	also accept "clone", except the failing case.  This commit fixes that
	case to also use "?".

	Furthermore, there are FAILs like this:
	...
	(gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \
	   non-stop=on: displaced=off: i=0: continue
	stepi^M
	[New Thread 0x7ffff7ff8700 (LWP 15301)]^M
	Hello from the first thread.^M
	78      in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M
	(gdb) XXX: Consume the initial command
	XXX: Consume new thread line
	XXX: Consume first worker thread message
	FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \
	  displaced=off: i=0: stepi
	...
	because this output is expected instead:
	...
	Hello from the first thread.^M
	0x00000000004212cd in clone3 ()^M
	...

	The root cause for the difference is the presence of .debug_line info for
	clone.

	Fix this by updating the relevant regexps.

	Tested on x86_64-linux, specifically:
	- openSUSE Leap 15.4 (where the FAILs where observed), and
	- openSUSE Tumbleweed (where the FAILs where not observed).

	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Approved-By: Pedro Alves <pedro@palves.net>

	Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c

2023-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: implement missing debug handler hook for Python
	This commit builds on the previous commit, and implements the
	extension_language_ops::handle_missing_debuginfo function for Python.
	This hook will give user supplied Python code a chance to help find
	missing debug information.

	The implementation of the new hook is pretty minimal within GDB's C++
	code; most of the work is out-sourced to a Python implementation which
	is modelled heavily on how GDB's Python frame unwinders are
	implemented.

	The following new commands are added as commands implemented in
	Python, this is similar to how the Python unwinder commands are
	implemented:

	  info missing-debug-handlers
	  enable missing-debug-handler LOCUS HANDLER
	  disable missing-debug-handler LOCUS HANDLER

	To make use of this extension hook a user will create missing debug
	information handler objects, and registers these handlers with GDB.
	When GDB encounters an objfile that is missing debug information, each
	handler is called in turn until one is able to help.  Here is a
	minimal handler that does nothing useful:

	  import gdb
	  import gdb.missing_debug

	  class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
	      def __init__(self):
	          super().__init__("my_first_handler")

	      def __call__(self, objfile):
	          # This handler does nothing useful.
	          return None

	  gdb.missing_debug.register_handler(None, MyFirstHandler())

	Returning None from the __call__ method tells GDB that this handler
	was unable to find the missing debug information, and GDB should ask
	any other registered handlers.

	By extending the __call__ method it is possible for the Python
	extension to locate the debug information for objfile and return a
	value that tells GDB how to use the information that has been located.

	Possible return values from a handler:

	  - None: This means the handler couldn't help.  GDB will call other
	          registered handlers to see if they can help instead.

	  - False: The handler has done all it can, but the debug information
	           for the objfile still couldn't be found.  GDB will not call
		   any other handlers, and will continue without the debug
		   information for objfile.

	  - True: The handler has installed the debug information into a
	          location where GDB would normally expect to find it.  GDB
		  should look again for the debug information.

	  - A string: The handler can return a filename, which is the file
	              containing the missing debug information.  GDB will load
		      this file.

	When a handler returns True, GDB will look again for the debug
	information, but only using the standard built-in build-id and
	.gnu_debuglink based lookup strategies.  It is not possible for an
	extension to trigger another debuginfod lookup; the assumption is that
	the debuginfod server is remote, and out of the control of extensions
	running within GDB.

	Handlers can be registered globally, or per program space.  GDB checks
	the handlers for the current program space first, and then all of the
	global handles.  The first handler that returns a value that is not
	None, has "handled" the objfile, at which point GDB continues.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: add an extension language hook for missing debug info
	This commit adds a new extension_language_ops hook which allows an
	extension to handle the case where GDB can't find a separate debug
	information file for a particular objfile.

	This commit doesn't actually implement the hook for any of GDB's
	extension languages, the next commit will do that.  This commit just
	adds support for the hook to extension-priv.h and extension.[ch], and
	then reworks symfile-debug.c to call the hook.

	Right now the hook will always return its default value, which means
	GDB should do nothing different.  As such, there should be no user
	visible changes after this commit.

	I'll give a brief description of what the hook does here so that we
	can understand the changes in symfile-debug.c.  The next commit adds a
	Python implementation for this new hook, and gives a fuller
	description of the new functionality.

	Currently, when looking for separate debug information GDB tries three
	things, in this order:

	  1. Use the build-id to find the required debug information,

	  2. Check for .gnu_debuglink section and use that to look up the
	  required debug information,

	  3. Check with debuginfod to see if it can supply the required
	  information.

	The new extension_language_ops::handle_missing_debuginfo hook is
	called if all three steps fail to find any debug information.  The
	hook has three possible return values:

	  a. Nothing, no debug information is found, GDB continues without the
	  debug information for this objfile.  This matches the current
	  behaviour of GDB, and is the default if nothing is implementing this
	  new hook,

	  b. Install debug information into a location that step #1 or #2
	  above would normally check, and then request that GDB repeats steps
	  #1 and #2 in the hope that GDB will now find the debug information.
	  If the debug information is still not found then GDB carries on
	  without the debug information.  If the debug information is found
	  the GDB loads it and carries on,

	  c. Return a filename for a file containing the required debug
	  information.  GDB loads the contents of this file and carries on.

	The changes in this commit mostly involve placing the core of
	objfile::find_and_add_separate_symbol_file into a loop which allows
	for steps #1 and #2 to be repeated.

	We take care to ensure that debuginfod is only queried once, the first
	time through.  The assumption is that no extension is going to be able
	to control the replies from debuginfod, so there's no point making a
	second request -- and as these requests go over the network, they
	could potentially be slow.

	The warnings that find_and_add_separate_symbol_file collects are
	displayed only once assuming that no debug information is found.  If
	debug information is found, even after the extension has operated,
	then the warnings are not shown; remember, these are warnings from GDB
	about failure to find any suitable debug information, so it makes
	sense to hide these if debug information is found.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: refactor objfile::find_and_add_separate_symbol_file
	This is purely a refactoring commit.

	This commit splits objfile::find_and_add_separate_symbol_file into
	some separate helper functions.  My hope is that the steps for looking
	up separate debug information are now clearer.

	In a later commit I'm going to extend
	objfile::find_and_add_separate_symbol_file, with some additional
	logic, so starting with a simpler function will make the following
	changes easier.

	When reading objfile::find_and_add_separate_symbol_file after this
	commit, you might be tempted to think that removing the `has_dwarf`
	local variable would be a good additional cleanup.  After the next
	commit though it makes more sense to retain this local, so I've left
	this in place for now.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: merge debug symbol file lookup code from coffread & elfread paths
	This commit merges the code that looks for and loads the separate
	debug symbol files from coffread.c and elfread.c.  The factored out
	code is moved into a new objfile::find_and_add_separate_symbol_file()
	method.

	For the elfread.c path there should be no user visible changes after
	this commit.

	For the coffread.c path GDB will now attempt to perform a debuginfod
	lookup for the missing debug information, assuming that GDB can find a
	build-id in the COFF file.

	I don't know if COFF files can include a build-id, but I the existing
	coffread.c code already includes a call to
	find_separate_debug_file_by_build-id, so I know that it is at least OK
	for GDB to ask a COFF file for a build-id.  If the COFF file doesn't
	include a build-id then the debuginfod lookup code will not trigger
	and the new code is harmless.

	If the COFF file does include a build-id, then we're going to end up
	asking debuginfod for the debug file.  As build-ids should be unique,
	this should be harmless, even if debuginfod doesn't contain any
	suitable debug data, it just costs us one debuginfod lookup, so I'm
	not too worried about this for now.

	As with the previous commit, I've done some minimal testing using the
	mingw toolchain on a Linux machine, GDB seems to still access the
	split debug information just fine.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/coffread: bring separate debug file logic into line with elfread.c
	In this commit:

	  commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07
	  Date:   Fri Feb 1 19:39:04 2013 +0000

	the logic for when we try to load a separate debug file in elfread.c
	was extended.  The new code checks that the objfile doesn't already
	have a separate debug objfile linked to it, and that the objfile isn't
	itself a separate debug objfile for some other objfile.

	The coffread code wasn't extended at the same time.

	I don't know if it's possible for the coffread code to get into the
	same state where these checks are needed, but I don't see why having
	these checks would be a problem.  In a later commit I plan to merge
	this part of the elfread and coffread code, so bringing these two
	pieces of code into line first makes that job easier.

	I've tested this with a simple test binary compiled with the mingw
	toolchain on a Linux host.  After compiling the binary and splitting
	out the debug info GDB still finds and loads the separate debug info.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-14  Nick Clifton  <nickc@redhat.com>

	Fix another linker command line option that was not being recognised in its long form.
	  PR 28910
	  * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised.

	Improve objdump's handling of compressed sections.
	  PR 31062
	  * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option.
	  * NEWS: Mention the new feature.
	  * doc/binutils.texi: Document the new feature.
	  * testsuite/binutils-all/objdump.s: Update expected output.
	  * testsuite/binutils-all/objdump.exp: Add test of -Z -s.
	  * testsuite/binutils-all/objdump.Zs: New file.
	  * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions.  Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise.

2023-11-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Don't include border_width in left_margin
	Currently left_margin does not match its documentation:
	...
	  /* Return the size of the left margin space, this is the space used to
	     display things like breakpoint markers.  */
	  int left_margin () const
	  { return box_width () + TUI_EXECINFO_SIZE + extra_margin (); }
	...

	It is stated that the left margin is reserved to display things, but
	the box_width is not used for that.

	Fix this by dropping box_width () from the left_margin calculation.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Add tui_win_info::{box_width,box_size}
	In tui_source_window::set_contents we have:
	...
	  /* Take hilite (window border) into account, when
	     calculating the number of lines.  */
	  int nlines = height - 2;
	...

	The '2' represents the total size of the window border (or box, in can_box
	terms), in this case one line at the top and one line at the bottom.

	Likewise, '1' is used to represent the width of the window border.

	Introduce new functions:
	- tui_win_info::box_width () and
	- tui_win_info::box_size ()
	that can be used instead instead of these hardcoded constants.

	Implement these such that they return 0 when can_box () == false.

	Tested patch completeness by making all windows unboxed:
	...
	@@ -85,7 +85,7 @@ struct tui_win_info
	   /* Return true if this window can be boxed.  */
	   virtual bool can_box () const
	   {
	-    return true;
	+    return false;
	   }

	   int box_width () const
	...
	and test-driving TUI.

	This required eliminating an assert in
	tui_source_window_base::show_source_content, I've included that part as well.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_window
	Currently the call to prefresh in tui_source_window_base::refresh_window looks
	like:
	...
	  prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin,
		    y + m_content.size (), x + left_margin + view_width - 1);
	...

	This is hard to parse.  It's not obvious what the arguments mean, and there's
	repetition in the argument calculation.

	Fix this by rewriting the call as follows:
	- use sminrow, smincol, smaxrow and smaxcol variables for the last
	  4 arguments, and
	- calculate the smaxrow and smaxcol variables based on the sminrow and
	  smincol variables.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-13  Carl Love  <cel@linux.ibm.com>

	Fix the gdb.ada/inline-section-gc.exp test
	The original intention of the test appears to be checking to make sure
	setting a breakpoint in an inlined function didn't set multiple
	breakpoints where one of them was at address 0.

	The gdb.ada/inline-section-gc.exp test may pass or fail depending on the
	version of gnat.  Per the discussion on IRC, the ada inlining appears to
	have some target dependencies.  In this test there are two functions,
	callee and caller. Function calee is inlined into caller.  The test sets
	a breakpoint in function callee.  The reported location where the
	breakpoint is set may be at the requested location in callee or the
	location in caller after callee has been inlined.  The test needs to
	accept either location as correct provided the breakpoint address is not
	zero.

	This patch checks to see if the reported breakpoint is in function callee
	or function caller and fails if the breakpoint address is 0x0.  The line
	number where the breakpoint is set will match the requested line if the
	breakpoint location is reported is callee.adb.  If the breakpoint is
	reported in caller.adb, the line number in caller is the breakpoint
	location in callee where it is inlined into caller.

	This patch fixes the single regression failure for the test on PowerPC.
	It does not introduce any failures on X86-64.

2023-11-13  Nick Clifton  <nickc@redhat.com>

	GNU-ld: ARM: Issues when trying to set target output architecture
	  PR 28910
	  * lexsup.c (ld_options): Ensure that the --format option is correctly recognised.

2023-11-13  Mark Wielaard  <mark@klomp.org>

	Regenerate gas/config.in and ld/configure
	commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*"
	changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32
	this new name sorts differently when regenerating gas/config.in

	commit e922d1eaa "Add ability to change linker warning messages into
	errors when reporting executable stacks and/or executable segments."
	Introduced two new help strings for --enable-error-execstack and
	--enable-error-rwx-segments in configure.ac which weren't included
	in ld/configure when regenerated.

		* gas/config.in: Regenerate.
		* ld/configure: Likewise.

2023-11-13  Nick Clifton  <nickc@redhat.com>

	Add documentation for the MIPS assembler's -march=from-abi command line option

2023-11-13  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Fix binutils-all tests for r6 triples

2023-11-13  Chung-Ju Wu  <jasonwucj@gmail.com>

	Fix redundant space typo in linker documentation.

2023-11-13  Pedro Alves  <pedro@palves.net>

	Cancel execution command on thread exit, when stepping, nexting, etc.
	If your target has no support for TARGET_WAITKIND_NO_RESUMED events
	(and no way to support them, such as the yet-unsubmitted AMDGPU
	target), and you step over thread exit with scheduler-locking on, this
	is what you get:

	 (gdb) n
	 [Thread ... exited]
	 *hang*

	Getting back the prompt by typing Ctrl-C may not even work, since no
	inferior thread is running to receive the SIGINT.  Even if it works,
	it seems unnecessarily harsh.  If you started an execution command for
	which there's a clear thread of interest (step, next, until, etc.),
	and that thread disappears, then I think it's more user friendly if
	GDB just detects the situation and aborts the command, giving back the
	prompt.

	That is what this commit implements.  It does this by explicitly
	requesting the target to report thread exit events whenever the main
	resumed thread has a thread_fsm.  Note that unlike stepping over a
	breakpoint, we don't need to enable clone events in this case.

	With this patch, we get:

	 (gdb) n
	 [Thread 0x7ffff7d89700 (LWP 3961883) exited]
	 Command aborted, thread exited.
	 (gdb)

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95

2023-11-13  Pedro Alves  <pedro@palves.net>

	Document remote clone events, and QThreadOptions packet
	This commit documents in both manual and NEWS:

	 - the new remote clone event stop reply,
	 - the new QThreadOptions packet and its current defined options,
	 - the associated "set/show remote thread-events-packet" command,
	 - and the associated QThreadOptions qSupported feature.

	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Change-Id: Ic1c8de1fefba95729bbd242969284265de42427e

2023-11-13  Simon Marchi  <simon.marchi@efficios.com>
	    Pedro Alves  <pedro@palves.net>

	Testcases for stepping over thread exit syscall (PR gdb/27338)
	Add new gdb.threads/step-over-thread-exit.exp and
	gdb.threads/step-over-thread-exit-while-stop-all-threads.exp
	testcases, exercising stepping over thread exit syscall.  These make
	use of lib/my-syscalls.S to define the exit syscall.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
	Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9

2023-11-13  Pedro Alves  <pedro@palves.net>

	gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro
	Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S
	behind a SYSCALL macro so that it's easy to add new syscalls without
	duplicating code.

	Note that the way the macro is implemented, it only works correctly
	for syscalls with up to 3 arguments, and, if the syscall doesn't
	return (the macro doesn't bother to save/restore callee-saved
	registers).

	The following patch will want to use the macro to define a wrapper for
	the "exit" syscall, so the limitations continue to be sufficient.

	Change-Id: I8acf1463b11a084d6b4579aaffb49b5d0dea3bba
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-11-13  Pedro Alves  <pedro@palves.net>

	Report thread exit event for leader if reporting thread exit events
	If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the
	thread disappears from the thread list, GDB expects to shortly see a
	thread exit event for it.  See e.g., here, in
	remote_target::update_thread_list():

	    /* Do not remove the thread if we've requested to be
	       notified of its exit.  For example, the thread may be
	       displaced stepping, infrun will need to handle the
	       exit event, and displaced stepping info is recorded
	       in the thread object.  If we deleted the thread now,
	       we'd lose that info.  */
	    if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0)
	      continue;

	There's one scenario that is deleting a thread from the
	remote/gdbserver thread list without ever reporting a corresponding
	thread exit event though -- check_zombie_leaders.  This can lead to
	GDB getting confused.  For example, with a following patch that
	enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see
	this regression:

	 $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp"
	 ...
	 Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ...
	 FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)
	 ... some more cascading FAILs ...

	gdb.log shows:

	 (gdb) continue
	 Continuing.
	 FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)

	A passing run would have resulted in:

	 (gdb) continue
	 Continuing.
	 No unwaited-for children left.
	 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits

	note how the leader thread is not listed in the remote-reported XML
	thread list below:

	 (gdb) set debug remote 1
	 (gdb) set debug infrun 1
	 (gdb) info threads
	   Id   Target Id                                Frame
	 * 1    Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65
	   3    Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39
	 (gdb) c
	 Continuing.
	 [infrun] clear_proceed_status_thread: 1163850.1163850.0
	 ...
	     [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f
	     [remote] Sending packet: $QPassSignals:#f3
	     [remote] Packet received: OK
	     [remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3
	     [remote] Packet received: OK
	 ...
	     [infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3]
	 ...
	   [infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0
	   [remote] Sending packet: $vCont;c:p11c24a.11c24a#98
	   [infrun] prepare_to_wait: prepare_to_wait
	   [infrun] reset: reason=handling event
	   [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
	   [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
	 [infrun] fetch_inferior_event: exit
	 [infrun] fetch_inferior_event: enter
	   [infrun] scoped_disable_commit_resumed: reason=handling event
	   [infrun] random_pending_event_thread: None found.
	   [remote] wait: enter
	     [remote] Packet received: N
	   [remote] wait: exit
	   [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
	   [infrun] print_target_wait_results:   -1.0.0 [process -1],
	   [infrun] print_target_wait_results:   status->kind = NO_RESUMED
	   [infrun] handle_inferior_event: status->kind = NO_RESUMED
	   [remote] Sending packet: $Hgp0.0#ad
	   [remote] Packet received: OK
	   [remote] Sending packet: $qXfer:threads:read::0,1000#92
	   [remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n
	   [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
	 ...

	... however, infrun decided there was a resumed thread still, so
	ignored the TARGET_WAITKIND_NO_RESUMED event.  Debugging GDB, we see
	that the "found resumed" thread that GDB finds, is the leader thread.
	Even though that thread is not on the remote-reported thread list, it
	is still on the GDB thread list, due to the special case in remote.c
	mentioned above.

	This commit addresses the issue by fixing GDBserver to report a thread
	exit event for the zombie leader too, i.e., making GDBserver respect
	the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit"
	invariant.  To do that, it takes a bit more code than one would
	imagine off hand, due to the fact that we currently always report LWP
	exit pending events as TARGET_WAITKIND_EXITED, and then decide whether
	to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting
	the event to GDBserver core.  For the zombie leader scenario
	described, we need to record early on that we want to report a
	THREAD_EXITED event, and then make sure that decision isn't lost along
	the way to reporting the event to GDBserver core.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I1e68fccdbc9534434dee07163d3fd19744c8403b

2023-11-13  Pedro Alves  <pedro@palves.net>

	Don't resume new threads if scheduler-locking is in effect
	If scheduler-locking is in effect, e.g., with "set scheduler-locking
	on", and you step over a function that spawns a new thread, the new
	thread is allowed to run free, at least until some event is hit, at
	which point, whether the new thread is re-resumed depends on a number
	of seemingly random factors.  E.g., if the target is all-stop, and the
	parent thread hits a breakpoint, and GDB decides the breakpoint isn't
	interesting to report to the user, then the parent thread is resumed,
	but the new thread is left stopped.

	I think that letting the new threads run with scheduler-locking
	enabled is a defect.  This commit fixes that, making use of the new
	clone events on Linux, and of target_thread_events() on targets where
	new threads have no connection to the thread that spawned them.

	Testcase and documentation changes included.

	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce

2023-11-13  Pedro Alves  <pedro@palves.net>

	gdbserver: Queue no-resumed event after thread exit
	Normally, if the last resumed thread on the target exits, the server
	sends a no-resumed event to GDB.  If however, GDB enables the
	GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the
	server sends a thread exit event for that thread instead.

	In all-stop RSP mode, since events can only be forwarded to GDB one at
	a time, and the whole target stops whenever an event is reported, GDB
	resumes the target again after getting a THREAD_EXITED event, and then
	the server finally reports back a no-resumed event if/when
	appropriate.

	For non-stop RSP though, events are asynchronous, and if the server
	sends a thread-exit event for the last resumed thread, the no-resumed
	event is never sent.  This patch makes sure that in non-stop mode, the
	server queues a no-resumed event after the thread-exit event if it was
	the last resumed thread that exited.

	Without this, we'd see failures in step-over-thread-exit testcases
	added later in the series, like so:

	   continue
	   Continuing.
	 - No unwaited-for children left.
	 - (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits
	 + FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout)

	(and other similar ones)

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I927d78b30f88236dbd5634b051a716f72420e7c7

2023-11-13  Pedro Alves  <pedro@palves.net>

	stop_all_threads: (re-)enable async before waiting for stops
	Running the
	gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcase
	added later in the series against gdbserver, after the
	TARGET_WAITKIND_NO_RESUMED fix from the following patch, would run
	into an infinite loop in stop_all_threads, leading to a timeout:

	  FAIL: gdb.threads/step-over-thread-exit-while-stop-all-threads.exp: displaced-stepping=off: target-non-stop=on: iter 0: continue (timeout)

	The is really a latent bug, and it is about the fact that
	stop_all_threads stops listening to events from a target as soon as it
	sees a TARGET_WAITKIND_NO_RESUMED, ignoring that
	TARGET_WAITKIND_NO_RESUMED may be delayed.  handle_no_resumed knows
	how to handle delayed no-resumed events, but stop_all_threads was
	never taught to.

	In more detail, here's what happens with that testcase:

	#1 - Multiple threads report breakpoint hits to gdb.

	#2 - gdb picks one events, and it's for thread 1.  All other stops are
	     left pending.  thread 1 needs to move past a breakpoint, so gdb
	     stops all threads to start an inline step over for thread 1.
	     While stopping threads, some of the threads that were still
	     running report events that are also left pending.

	#2 - gdb steps thread 1

	#3 - Thread 1 exits while stepping (it steps over an exit syscall),
	     gdbserver reports thread exit for thread 1

	#4 - Thread 1 was the last resumed thread, so gdbserver also reports
	     no-resumed:

	    [remote]   Notification received: Stop:w0;p3445d0.3445d3
	    [remote] Sending packet: $vStopped#55
	    [remote] Packet received: N
	    [remote] Sending packet: $vStopped#55
	    [remote] Packet received: OK

	#5 - gdb processes the thread exit for thread 1, finishes the step
	     over and restarts threads.

	#6 - gdb picks the next event to process out of one of the resumed
	     threads with pending events:

	    [infrun] random_resumed_with_pending_wait_status: Found 32 events, selecting #11

	#7 - This is again a breakpoint hit and the breakpoint needs to be
	     stepped over too, so gdb starts a step-over dance again.

	#8 - We reach stop_all_threads, which finds that some threads need to
	     be stopped.

	#9 - wait_one finally consumes the no-resumed event queue by #4.
	     Seeing this, wait_one disable target async, to stop listening for
	     events out of the remote target.

	#10 - We still haven't seen all the stops expected, so
	      stop_all_threads tries another iteration.

	#11 - Because the remote target is no longer async, and there are no
	      other targets, wait_one return no-resumed immediately without
	      polling the remote target.

	#12 - We still haven't seen all the stops expected, so
	      stop_all_threads tries another iteration.  goto #11, looping
	      forever.

	Fix this by explicitly enabling/re-enabling target async on targets
	that can async, before waiting for stops.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: Ie3ffb0df89635585a6631aa842689cecc989e33f

2023-11-13  Pedro Alves  <pedro@palves.net>
	    Simon Marchi  <simon.marchi@efficios.com>

	gdb: clear step over information on thread exit (PR gdb/27338)
	GDB doesn't handle correctly the case where a thread steps over a
	breakpoint (using either in-line or displaced stepping), and the
	executed instruction causes the thread to exit.

	Using the test program included later in the series, this is what it
	looks like with displaced-stepping, on x86-64 Linux, where we have two
	displaced-step buffers:

	  $ ./gdb -q -nx --data-directory=data-directory build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit -ex "b my_exit_syscall" -ex r
	  Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
	  Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
	  Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
	  [Thread debugging using libthread_db enabled]
	  Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
	  [New Thread 0x7ffff7c5f640 (LWP 2915510)]
	  [Switching to Thread 0x7ffff7c5f640 (LWP 2915510)]

	  Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
	  68              syscall
	  (gdb) c
	  Continuing.
	  [New Thread 0x7ffff7c5f640 (LWP 2915524)]
	  [Thread 0x7ffff7c5f640 (LWP 2915510) exited]
	  [Switching to Thread 0x7ffff7c5f640 (LWP 2915524)]

	  Thread 3 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
	  68              syscall
	  (gdb) c
	  Continuing.
	  [New Thread 0x7ffff7c5f640 (LWP 2915616)]
	  [Thread 0x7ffff7c5f640 (LWP 2915524) exited]
	  [Switching to Thread 0x7ffff7c5f640 (LWP 2915616)]

	  Thread 4 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
	  68              syscall
	  (gdb) c
	  Continuing.
	  ... hangs ...

	The first two times we do "continue", we displaced-step the syscall
	instruction that causes the thread to exit.  When the thread exits,
	the main thread, waiting on pthread_join, is unblocked.  It spawns a
	new thread, which hits the breakpoint on the syscall again.  However,
	infrun was never notified that the displaced-stepping threads are done
	using the displaced-step buffer, so now both buffers are marked as
	used.  So when we do the third continue, there are no buffers
	available to displaced-step the syscall, so the thread waits forever
	for its turn.

	When trying the same but with in-line step over (displaced-stepping
	disabled):

	  $ ./gdb -q -nx --data-directory=data-directory \
	  build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit \
	    -ex "b my_exit_syscall" -ex "set displaced-stepping off" -ex r
	  Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
	  Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
	  Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
	  [Thread debugging using libthread_db enabled]
	  Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
	  [New Thread 0x7ffff7c5f640 (LWP 2928290)]
	  [Switching to Thread 0x7ffff7c5f640 (LWP 2928290)]

	  Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
	  68              syscall
	  (gdb) c
	  Continuing.
	  [Thread 0x7ffff7c5f640 (LWP 2928290) exited]
	  No unwaited-for children left.
	  (gdb) i th
	    Id   Target Id                                             Frame
	    1    Thread 0x7ffff7c60740 (LWP 2928285) "step-over-threa" 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0

	  The current thread <Thread ID 2> has terminated.  See `help thread'.
	  (gdb) thread 1
	  [Switching to thread 1 (Thread 0x7ffff7c60740 (LWP 2928285))]
	  #0  0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0
	  (gdb) c
	  Continuing.
	  ^C^C
	  ... hangs ...

	The "continue" causes an in-line step to occur, meaning the main
	thread is stopped while we step the syscall.  The stepped thread exits
	when executing the syscall, the linux-nat target notices there are no
	more resumed threads to be waited for, so returns
	TARGET_WAITKIND_NO_RESUMED, which causes the prompt to return.  But
	infrun never clears the in-line step over info.  So if we try
	continuing the main thread, GDB doesn't resume it, because it thinks
	there's an in-line step in progress that we need to wait for to
	finish, and we are stuck there.

	To fix this, infrun needs to be informed when a thread doing a
	displaced or in-line step over exits.  We can do that with the new
	target_set_thread_options mechanism which is optimal for only enabling
	exit events of the thread that needs it; or, if that is not supported,
	by using target_thread_events, which enables thread exit events for
	all threads.  This is done by this commit.

	This patch then modifies handle_inferior_event in infrun.c to clean up
	any step-over the exiting thread might have been doing at the time of
	the exit.  The cases to consider are:

	 - the exiting thread was doing an in-line step-over with an all-stop
	   target
	 - the exiting thread was doing an in-line step-over with a non-stop
	   target
	 - the exiting thread was doing a displaced step-over with a non-stop
	   target

	The displaced-stepping buffer implementation in displaced-stepping.c
	is modified to account for the fact that it's possible that we
	"finish" a displaced step after a thread exit event.  The buffer that
	the exiting thread was using is marked as available again and the
	original instructions under the scratch pad are restored.  However, it
	skips applying the fixup, which wouldn't make sense since the thread
	does not exist anymore.

	Another case that needs handling is if a displaced-stepping thread
	exits, and the event is reported while we are in stop_all_threads.  We
	should call displaced_step_finish in the handle_one function, in that
	case.  It was already called in other code paths, just not the "thread
	exited" path.

	This commit doesn't make infrun ask the target to report the
	TARGET_WAITKIND_THREAD_EXITED events yet, that'll be done later in the
	series.

	Note that "stop_print_frame = false;" line is moved to normal_stop,
	because TARGET_WAITKIND_THREAD_EXITED can also end up with the event
	transmorphed into TARGET_WAITKIND_NO_RESUMED.  Moving it to
	normal_stop keeps it centralized.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I745c6955d7ef90beb83bcf0ff1d1ac8b9b6285a5

2023-11-13  Pedro Alves  <pedro@palves.net>

	Implement GDB_THREAD_OPTION_EXIT support for native Linux
	This implements support for the new GDB_THREAD_OPTION_EXIT thread
	option for native Linux.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: Ia69fc0b9b96f9af7de7cefc1ddb1fba9bbb0bb90
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338

2023-11-13  Pedro Alves  <pedro@palves.net>

	Implement GDB_THREAD_OPTION_EXIT support for Linux GDBserver
	This implements support for the new GDB_THREAD_OPTION_EXIT thread
	option for Linux GDBserver.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338

2023-11-13  Pedro Alves  <pedro@palves.net>

	Introduce GDB_THREAD_OPTION_EXIT thread option, fix step-over-thread-exit
	When stepping over a breakpoint with displaced stepping, GDB needs to
	be informed if the stepped thread exits, otherwise the displaced
	stepping buffer that was allocated to that thread leaks, and this can
	result in deadlock, with other threads waiting for their turn to
	displaced step, but their turn never comes.

	Similarly, when stepping over a breakpoint in line, GDB also needs to
	be informed if the stepped thread exits, so that is can clear the step
	over state and re-resume threads.

	This commit makes it possible for GDB to ask the target to report
	thread exit events for a given thread, using the new "thread options"
	mechanism introduced by a previous patch.

	This only adds the core bits.  Following patches in the series will
	teach the Linux backends (native & gdbserver) to handle the
	GDB_THREAD_OPTION_EXIT option, and then a later patch will make use of
	these thread exit events to clean up displaced stepping and inline
	stepping state properly.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338

2023-11-13  Pedro Alves  <pedro@palves.net>

	Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to core
	Currently, infrun assumes that when TARGET_WAITKIND_THREAD_EXITED is
	reported, the corresponding GDB thread has already been removed from
	the GDB thread list.

	Later in the series, that will no longer work, as infrun will need to
	refer to the thread's thread_info when it processes
	TARGET_WAITKIND_THREAD_EXITED.

	As preparation, this patch makes deleting the GDB thread
	responsibility of infrun, instead of the target.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I013d87f61ffc9aaca49f0d6ce2a43e3ea69274de

2023-11-13  Pedro Alves  <pedro@palves.net>

	gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE
	gdbserver's linux_process_target::wait loops if:

	 - called in sync mode, and,
	 - wait_1 returns TARGET_WAITKIND_IGNORE, _and_,
	 - wait_1 also returns null_ptid.

	The null_ptid check fails however when this path is taken:

	   ptid_t
	   linux_process_target::filter_exit_event (lwp_info *event_child,
						    target_waitstatus *ourstatus)
	   {
	   ...
	     if (!is_leader (thread))
	       {
		 if (report_exit_events_for (thread))
		   ourstatus->set_thread_exited (0);
		 else
		   ourstatus->set_ignore ();            <<<<<<<

		 delete_lwp (event_child);
	       }
	     return ptid;
	   }

	This makes linux_process_target::wait return TARGET_WAITKIND_IGNORE in
	sync mode, which is unexpected by the core and fails an assertion.

	This commit fixes it by just making linux_process_target::wait loop if
	it got a TARGET_WAITKIND_IGNORE, irrespective of event_ptid.

	Change-Id: I39776908a6c75cbd68aa04139ffcf7be334868cf

2023-11-13  Pedro Alves  <pedro@palves.net>

	all-stop/synchronous RSP support thread-exit events
	Currently, GDB does not understand the THREAD_EXITED stop reply in
	remote all-stop mode.  There's no good reason for this, it just
	happened that THREAD_EXITED was only ever reported in non-stop mode so
	far.  This patch teaches GDB to parse that event in all-stop RSP too.
	There is no need to add a qSupported feature for this, because the
	server won't send a THREAD_EXITED event unless GDB explicitly asks for
	it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT
	QThreadOptions option added in the next patch.

	Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966

2023-11-13  Pedro Alves  <pedro@palves.net>

	Remove gdb/19675 kfails (displaced stepping + clone)
	Now that gdb/19675 is fixed for both native and gdbserver GNU/Linux,
	remove the gdb/19675 kfails.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I95c1c38ca370100675d303cd3c8995860bef465d

2023-11-13  Pedro Alves  <pedro@palves.net>

	gdbserver: Hide and don't detach pending clone children
	This commit extends the logic added by these two commits from a while
	ago:

	 #1  7b961964f866  (gdbserver: hide fork child threads from GDB),
	 #2  df5ad102009c  (gdb, gdbserver: detach fork child when detaching from fork parent)

	... to handle thread clone events, which are very similar to (v)fork
	events.

	For #1, we want to hide clone children as well, so just update the
	comments.

	For #2, unlike (v)fork children, pending clone children aren't full
	processes, they're just threads, so don't detach them in
	handle_detach.  linux-low.cc will take care of detaching them along
	with all other threads of the process, there's nothing special that
	needs to be done.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I7f5901d07efda576a2522d03e183994e071b8ffc

2023-11-13  Pedro Alves  <pedro@palves.net>

	Thread options & clone events (Linux GDBserver)
	This patch teaches the Linux GDBserver backend to report clone events
	to GDB, when GDB has requested them with the GDB_THREAD_OPTION_CLONE
	thread option, via the new QThreadOptions packet.

	This shuffles code in linux_process_target::handle_extended_wait
	around to a more logical order when we now have to handle and
	potentially report all of fork/vfork/clone.

	Raname lwp_info::fork_relative -> lwp_info::relative as the field is
	no longer only about (v)fork.

	With this, gdb.threads/stepi-over-clone.exp now cleanly passes against
	GDBserver, so remove the native-target-only requirement from that
	testcase.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I3a19bc98801ec31e5c6fdbe1ebe17df855142bb2

2023-11-13  Pedro Alves  <pedro@palves.net>

	Thread options & clone events (native Linux)
	This commit teaches the native Linux target about the
	GDB_THREAD_OPTION_CLONE thread option.  It's actually simpler to just
	continue reporting all clone events unconditionally to the core.
	There's never any harm in reporting a clone event when the option is
	disabled.  All we need to do is to report support for the option,
	otherwise GDB falls back to use target_thread_events().

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: If90316e2dcd0c61d0fefa0d463c046011698acf9

2023-11-13  Pedro Alves  <pedro@palves.net>

	Thread options & clone events (core + remote)
	A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
	event kind, and made the Linux target report clone events.

	A following patch will teach Linux GDBserver to do the same thing.

	However, for remote debugging, it wouldn't be ideal for GDBserver to
	report every clone event to GDB, when GDB only cares about such events
	in some specific situations.  Reporting clone events all the time
	would be potentially chatty.  We don't enable thread create/exit
	events all the time for the same reason.  Instead we have the
	QThreadEvents packet.  QThreadEvents is target-wide, though.

	This patch makes GDB instead explicitly request that the target
	reports clone events or not, on a per-thread basis.

	In order to be able to do that with GDBserver, we need a new remote
	protocol feature.  Since a following patch will want to enable thread
	exit events on per-thread basis too, the packet introduced here is
	more generic than just for clone events.  It lets you enable/disable a
	set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.

	IOW, this commit introduces a new QThreadOptions packet, that lets you
	specify a set of per-thread event options you want to enable.  The
	packet accepts a list of options/thread-id pairs, similarly to vCont,
	processed left to right, with the options field being a number
	interpreted as a bit mask of options.  The only option defined in this
	commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
	to report clone events.  Another patch later in the series will
	introduce another option.

	For example, this packet sets option "1" (clone events) on thread
	p1000.2345:

	  QThreadOptions;1:p1000.2345

	and this clears options for all threads of process 1000, and then sets
	option "1" (clone events) on thread p1000.2345:

	  QThreadOptions;0:p1000.-1;1:p1000.2345

	This clears options of all threads of all processes:

	  QThreadOptions;0

	The target reports the set of supported options by including
	"QThreadOptions=<supported options>" in its qSupported response.

	infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
	over a breakpoint.

	Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
	their parent's thread options.  This is so that GDB can send e.g.,
	"QThreadOptions;0;1:TID" without worrying about threads it doesn't
	know about yet.

	Documentation for this new remote protocol feature is included in a
	documentation patch later in the series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e

2023-11-13  Pedro Alves  <pedro@palves.net>

	Avoid duplicate QThreadEvents packets
	Similarly to QProgramSignals and QPassSignals, avoid sending duplicate
	QThreadEvents packets.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: Iaf5babb0b64e1527ba4db31aac8674d82b17e8b4

2023-11-13  Pedro Alves  <pedro@palves.net>

	Support clone events in the remote protocol
	The previous patch taught GDB about a new
	TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target
	report clone events.

	A following patch will teach Linux GDBserver to do the same thing.

	But before we get there, we need to teach the remote protocol about
	TARGET_WAITKIND_THREAD_CLONED.  That's what this patch does.  Clone is
	very similar to vfork and fork, and the new stop reply is likewise
	handled similarly.  The stub reports "T05clone:...".

	GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and
	forward it to GDB in this patch, but no backend actually emits it yet.
	That will be done in a following patch.

	Documentation for this new remote protocol feature is included in a
	documentation patch later in the series.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: If271f20320d864f074d8ac0d531cc1a323da847f
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830

2023-11-13  Pedro Alves  <pedro@palves.net>
	    Andrew Burgess  <aburgess@redhat.com>

	Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED
	(A good chunk of the problem statement in the commit log below is
	Andrew's, adjusted for a different solution, and for covering
	displaced stepping too.  The testcase is mostly Andrew's too.)

	This commit addresses bugs gdb/19675 and gdb/27830, which are about
	stepping over a breakpoint set at a clone syscall instruction, one is
	about displaced stepping, and the other about in-line stepping.

	Currently, when a new thread is created through a clone syscall, GDB
	sets the new thread running.  With 'continue' this makes sense
	(assuming no schedlock):

	 - all-stop mode, user issues 'continue', all threads are set running,
	   a newly created thread should also be set running.

	 - non-stop mode, user issues 'continue', other pre-existing threads
	   are not affected, but as the new thread is (sort-of) a child of the
	   thread the user asked to run, it makes sense that the new threads
	   should be created in the running state.

	Similarly, if we are stopped at the clone syscall, and there's no
	software breakpoint at this address, then the current behaviour is
	fine:

	 - all-stop mode, user issues 'stepi', stepping will be done in place
	   (as there's no breakpoint to step over).  While stepping the thread
	   of interest all the other threads will be allowed to continue.  A
	   newly created thread will be set running, and then stopped once the
	   thread of interest has completed its step.

	 - non-stop mode, user issues 'stepi', stepping will be done in place
	   (as there's no breakpoint to step over).  Other threads might be
	   running or stopped, but as with the continue case above, the new
	   thread will be created running.  The only possible issue here is
	   that the new thread will be left running after the initial thread
	   has completed its stepi.  The user would need to manually select
	   the thread and interrupt it, this might not be what the user
	   expects.  However, this is not something this commit tries to
	   change.

	The problem then is what happens when we try to step over a clone
	syscall if there is a breakpoint at the syscall address.

	- For both all-stop and non-stop modes, with in-line stepping:

	   + user issues 'stepi',
	   + [non-stop mode only] GDB stops all threads.  In all-stop mode all
	     threads are already stopped.
	   + GDB removes s/w breakpoint at syscall address,
	   + GDB single steps just the thread of interest, all other threads
	     are left stopped,
	   + New thread is created running,
	   + Initial thread completes its step,
	   + [non-stop mode only] GDB resumes all threads that it previously
	     stopped.

	There are two problems in the in-line stepping scenario above:

	  1. The new thread might pass through the same code that the initial
	     thread is in (i.e. the clone syscall code), in which case it will
	     fail to hit the breakpoint in clone as this was removed so the
	     first thread can single step,

	  2. The new thread might trigger some other stop event before the
	     initial thread reports its step completion.  If this happens we
	     end up triggering an assertion as GDB assumes that only the
	     thread being stepped should stop.  The assert looks like this:

	     infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.

	- For both all-stop and non-stop modes, with displaced stepping:

	   + user issues 'stepi',
	   + GDB starts the displaced step, moves thread's PC to the
	     out-of-line scratch pad, maybe adjusts registers,
	   + GDB single steps the thread of interest, [non-stop mode only] all
	     other threads are left as they were, either running or stopped.
	     In all-stop, all other threads are left stopped.
	   + New thread is created running,
	   + Initial thread completes its step, GDB re-adjusts its PC,
	     restores/releases scratchpad,
	   + [non-stop mode only] GDB resumes the thread, now past its
	     breakpoint.
	   + [all-stop mode only] GDB resumes all threads.

	There is one problem with the displaced stepping scenario above:

	  3. When the parent thread completed its step, GDB adjusted its PC,
	     but did not adjust the child's PC, thus that new child thread
	     will continue execution in the scratch pad, invoking undefined
	     behavior.  If you're lucky, you see a crash.  If unlucky, the
	     inferior gets silently corrupted.

	What is needed is for GDB to have more control over whether the new
	thread is created running or not.  Issue #1 above requires that the
	new thread not be allowed to run until the breakpoint has been
	reinserted.  The only way to guarantee this is if the new thread is
	held in a stopped state until the single step has completed.  Issue #3
	above requires that GDB is informed of when a thread clones itself,
	and of what is the child's ptid, so that GDB can fixup both the parent
	and the child.

	When looking for solutions to this problem I considered how GDB
	handles fork/vfork as these have some of the same issues.  The main
	difference between fork/vfork and clone is that the clone events are
	not reported back to core GDB.  Instead, the clone event is handled
	automatically in the target code and the child thread is immediately
	set running.

	Note we have support for requesting thread creation events out of the
	target (TARGET_WAITKIND_THREAD_CREATED).  However, those are reported
	for the new/child thread.  That would be sufficient to address in-line
	stepping (issue #1), but not for displaced-stepping (issue #3).  To
	handle displaced-stepping, we need an event that is reported to the
	_parent_ of the clone, as the information about the displaced step is
	associated with the clone parent.  TARGET_WAITKIND_THREAD_CREATED
	includes no indication of which thread is the parent that spawned the
	new child.  In fact, for some targets, like e.g., Windows, it would be
	impossible to know which thread that was, as thread creation there
	doesn't work by "cloning".

	The solution implemented here is to model clone on fork/vfork, and
	introduce a new TARGET_WAITKIND_THREAD_CLONED event.  This event is
	similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except
	that we end up with a new thread in the same process, instead of a new
	thread of a new process.  Like FORKED and VFORKED, THREAD_CLONED
	waitstatuses have a child_ptid property, and the child is held stopped
	until GDB explicitly resumes it.  This addresses the in-line stepping
	case (issues #1 and #2).

	The infrun code that handles displaced stepping fixup for the child
	after a fork/vfork event is thus reused for THREAD_CLONE, with some
	minimal conditions added, addressing the displaced stepping case
	(issue #3).

	The native Linux backend is adjusted to unconditionally report
	TARGET_WAITKIND_THREAD_CLONED events to the core.

	Following the follow_fork model in core GDB, we introduce a
	target_follow_clone target method, which is responsible for making the
	new clone child visible to the rest of GDB.

	Subsequent patches will add clone events support to the remote
	protocol and gdbserver.

	displaced_step_in_progress_thread becomes unused with this patch, but
	a new use will reappear later in the series.  To avoid deleting it and
	readding it back, this patch marks it with attribute unused, and the
	latter patch removes the attribute again.  We need to do this because
	the function is static, and with no callers, the compiler would warn,
	(error with -Werror), breaking the build.

	This adds a new gdb.threads/stepi-over-clone.exp testcase, which
	exercises stepping over a clone syscall, with displaced stepping vs
	inline stepping, and all-stop vs non-stop.  We already test stepping
	over clone syscalls with gdb.base/step-over-syscall.exp, but this test
	uses pthreads, while the other test uses raw clone, and this one is
	more thorough.  The testcase passes on native GNU/Linux, but fails
	against GDBserver.  GDBserver will be fixed by a later patch in the
	series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
	Change-Id: I95c06024736384ae8542a67ed9fdf6534c325c8e
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-11-13  Pedro Alves  <pedro@palves.net>

	gdb/linux: Delete all other LWPs immediately on ptrace exec event
	I noticed that on an Ubuntu 20.04 system, after a following patch
	("Step over clone syscall w/ breakpoint,
	TARGET_WAITKIND_THREAD_CLONED"), the gdb.threads/step-over-exec.exp
	was passing cleanly, but still, we'd end up with four new unexpected
	GDB core dumps:

			 === gdb Summary ===

	 # of unexpected core files      4
	 # of expected passes            48

	That said patch is making the pre-existing
	gdb.threads/step-over-exec.exp testcase (almost silently) expose a
	latent problem in gdb/linux-nat.c, resulting in a GDB crash when:

	 #1 - a non-leader thread execs
	 #2 - the post-exec program stops somewhere
	 #3 - you kill the inferior

	Instead of #3 directly, the testcase just returns, which ends up in
	gdb_exit, tearing down GDB, which kills the inferior, and is thus
	equivalent to #3 above.

	Vis (after said patch is applied):

	 $ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true
	 ...
	 (top-gdb) r
	 ...
	 (gdb) b main
	 ...
	 (gdb) r
	 ...
	 Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69
	 69        argv0 = argv[0];
	 (gdb) c
	 Continuing.
	 [New Thread 0x7ffff7d89700 (LWP 2506975)]
	 Other going in exec.
	 Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
	 process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd

	 Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28
	 28        foo ();
	 (gdb) k
	 ...
	 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
	 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
	 393         return m_suspend.waitstatus_pending_p;
	 (top-gdb) bt
	 #0  0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
	 #1  0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345
	 #2  0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564
	 #3  0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284
	 #4  0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278
	 #5  0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247
	 #6  0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864
	 #7  0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590
	 #8  0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911
	 ...

	The root of the problem is that when a non-leader LWP execs, it just
	changes its tid to the tgid, replacing the pre-exec leader thread,
	becoming the new leader.  There's no thread exit event for the execing
	thread.  It's as if the old pre-exec LWP vanishes without trace.  The
	ptrace man page says:

	 "PTRACE_O_TRACEEXEC (since Linux 2.5.46)
		Stop the tracee at the next execve(2).  A waitpid(2) by the
		tracer will return a status value such that

		  status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))

		If the execing thread is not a thread group leader, the thread
		ID is reset to thread group leader's ID before this stop.
		Since Linux 3.0, the former thread ID can be retrieved with
		PTRACE_GETEVENTMSG."

	When the core of GDB processes an exec events, it deletes all the
	threads of the inferior.  But, that is too late -- deleting the thread
	does not delete the corresponding LWP, so we end leaving the pre-exec
	non-leader LWP stale in the LWP list.  That's what leads to the crash
	above -- linux_nat_target::kill iterates over all LWPs, and after the
	patch in question, that code will look for the corresponding
	thread_info for each LWP.  For the pre-exec non-leader LWP still
	listed, won't find one.

	This patch fixes it, by deleting the pre-exec non-leader LWP (and
	thread) from the LWP/thread lists as soon as we get an exec event out
	of ptrace.

	GDBserver does not need an equivalent fix, because it is already doing
	this, as side effect of mourning the pre-exec process, in
	gdbserver/linux-low.cc:

	  else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events)
	    {
	...
	      /* Delete the execing process and all its threads.  */
	      mourn (proc);
	      switch_to_thread (nullptr);


	The crash with gdb.threads/step-over-exec.exp is not observable on
	newer systems, which postdate the glibc change to move "libpthread.so"
	internals to "libc.so.6", because right after the exec, GDB traps a
	load event for "libc.so.6", which leads to GDB trying to open
	libthread_db for the post-exec inferior, and, on such systems that
	succeeds.  When we load libthread_db, we call
	linux_stop_and_wait_all_lwps, which, as the name suggests, stops all
	lwps, and then waits to see their stops.  While doing this, GDB
	detects that the pre-exec stale LWP is gone, and deletes it.

	If we use "catch exec" to stop right at the exec before the
	"libc.so.6" load event ever happens, and issue "kill" right there,
	then GDB crashes on newer systems as well.  So instead of tweaking
	gdb.threads/step-over-exec.exp to cover the fix, add a new
	gdb.threads/threads-after-exec.exp testcase that uses "catch exec".
	The test also uses the new "maint info linux-lwps" command if testing
	on Linux native, which also exposes the stale LWP problem with an
	unfixed GDB.

	Also tweak a comment in infrun.c:follow_exec referring to how
	linux-nat.c used to behave, as it would become stale otherwise.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I21ec18072c7750f3a972160ae6b9e46590376643

2023-11-13  Andrew Burgess  <aburgess@redhat.com>

	Add "maint info linux-lwps" command
	This adds a maintenance command that lets you list all the LWPs under
	control of the linux-nat target.

	For example:

	 (gdb) maint info linux-lwps
	 LWP Ptid        Thread ID
	 560948.561047.0 None
	 560948.560948.0 1.1

	This shows that "560948.561047.0" LWP doesn't map to any thread_info
	object, which is bogus.  We'll be using this in a testcase in a
	following patch.

	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Change-Id: Ic4e9e123385976e5cd054391990124b7a20fb3f5

2023-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix Wmaybe-uninitialized in tui_find_disassembly_address
	When building gdb with -O2, we run into:
	...
	gdb/tui/tui-disasm.c: In function ‘CORE_ADDR tui_find_disassembly_address \
	  (gdbarch*, CORE_ADDR, int)’:
	gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used uninitialized \
	  in this function [-Wmaybe-uninitialized]
	       if (last_addr < pc)
	       ^~
	...

	The warning triggers since commit 72535eb14bd ("[gdb/tui] Fix segfault in
	tui_find_disassembly_address").

	Fix the warning by ensuring that last_addr is initialized at the point of
	use:
	...
	+      last_addr = asm_lines.back ().addr;
	       if (last_addr < pc)
	...

	Tested on x86_64-linux.

2023-11-13  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Make assert in tui_find_disassembly_address more strict
	In tui_find_disassembly_address we find an assert:
	...
	      if (asm_lines.size () < max_lines)
		{
		  if (!possible_new_low.has_value ())
		    return new_low;

		  /* Take the best possible match we have.  */
		  new_low = *possible_new_low;
		  next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
		  last_addr = asm_lines.back ().addr;
		  gdb_assert (asm_lines.size () >= max_lines);
		}
	...

	The comment right above:
	...
	      /* If we failed to disassemble the required number of lines then the
		 following walk forward is not going to work, it assumes that
		 ASM_LINES contains exactly MAX_LINES entries.  Instead we should
		 consider falling back to a previous possible start address in
		 POSSIBLE_NEW_LOW.  */
	...
	claims that the more strict asm_lines.size () == max_line is required.

	Update the assert to reflect this, and move it to after the if because it's
	supposed to hold in general, not just when entering the if.

	Tested on x86_64-linux.

2023-11-13  Tom Tromey  <tom@tromey.com>

	Remove declaration of re_comp
	defs.h declares re_comp, but it shouldn't.  If this is needed, it
	should be picked up from xregex.h via gdb_regex.h.

	Tested by rebuilding.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-11-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-10  Simon Marchi  <simon.marchi@efficios.com>

	bfd, binutils: add gfx11 amdgpu architectures
	Teach bfd and readelf about some recent gfx11 architectures.  This code
	is taken from the rocgdb 5.7.x branch [1].

	[1] https://github.com/rocm-Developer-Tools/rocgdb/tree/rocm-5.7.x

	bfd/ChangeLog:

		* archures.c (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
		bfd_mach_amdgcn_gfx1102): New.
		* bfd-in2.h (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
		bfd_mach_amdgcn_gfx1102): New.
		* cpu-amdgcn.c (arch_info_struct): Add entries for
		bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
		bfd_mach_amdgcn_gfx1102.

	binutils/ChangeLog:

		* readelf.c (decode_AMDGPU_machine_flags): Handle gfx1100,
		gfx1101, gfx1102.

	include/ChangeLog:

		* elf/amdgpu.h (EF_AMDGPU_MACH_AMDGCN_GFX1100,
		EF_AMDGPU_MACH_AMDGCN_GFX1101,
		EF_AMDGPU_MACH_AMDGCN_GFX1102): New.

	Change-Id: I95a8a62942e359781a1c9fa2079950fbcf2a78b8
	Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
	Cc: Lancelot Six <lancelot.six@amd.com>

2023-11-10  Michael J. Eager  <eager@eagercon.com>

	Correct formatting errors in elf32-microblaze.c

2023-11-10  YunQiang Su  <yunqiang.su@cipunited.com>

	Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian

	GAS/MIPS: Fix testcase module-defer-warn2 for r2+ triples

2023-11-10  Vsevolod Alekseyev  <sevaa@sprynet.com>

	readelf..debug-dump=loc displays bogus base addresses
	  PR 30880
	  * dwarf.c (read_and_display_attr_value): Fix loclist handling. (display_loclists_list): Likewise.

2023-11-10  YunQiang Su  <yunqiang.su@cipunited.com>

	GAS/MIPS: Add mips16-e-irix.d testcase

2023-11-10  Ying Huang  <ying.huang@oss.cipunited.com>

	MIPS: Change all E_MIPS_* to EF_MIPS_*

2023-11-10  Nick Clifton  <nickc@redhat.com>

	Add ability to change linker warning messages into errors when reporting executable stacks and/or executable segments.
	  include
	  * bfdlink.h (struct bfd_link_info): Update descriptions of the 'execstack', 'noexecstack' and 'warn_execstack' fields. Add 'error_exectack' and 'warn_is_error_for_rwx_segments' fields.

	  bfd
	  * elf.c (assign_file_positions_except_relocs): Turn warnings about executable segments into errors if so requested.
	  * elflink.c (bfd_elf_size_dynamic_sections): Turn warnings about executable stacks into errors if so requested.

	  ld
	  * ldlex.h (enum option_values): Add OPTION_ERROR_EXECSTACK, OPTION_NO_ERROR_EXECSTACK, OPTION_WARN_EXECSTACK_OBJECTS, OPTION_ERROR_RWX_SEGMENTS and OPTION_NO_ERROR_RWX_SEGMENTS. (struct ld_option): Add new long options. (parse_args): Parse new long options. (elf_static_list_options): Display the new options.
	  * ld.texi: Document the new command line options.
	  * configure.ac (error-execstack): New configuration option. (error-rwx-segments): New configuration option.
	  * emultempl/elf.em (_before_parse): Initialse the new linkinfo fields.
	  * NEWS: Mention the new features.
	  * config.in: Regenerate.
	  * configure: Regenerate.
	  * testsuite/ld-elf/commonpage2.d: Disable errors for RWX segments and/or executable stacks.
	  * testsuite/ld-elf/elf.exp: Likewise.
	  * testsuite/ld-elf/header.d: Likewise.
	  * testsuite/ld-elf/loadaddr1.d: Likewise.
	  * testsuite/ld-elf/loadaddr2.d: Likewise.
	  * testsuite/ld-elf/maxpage4.d: Likewise.
	  * testsuite/ld-elf/nobits-1.d: Likewise.
	  * testsuite/ld-elf/note-1.d: Likewise.
	  * testsuite/ld-elf/orphan-10.d: Likewise.
	  * testsuite/ld-elf/orphan-11.d: Likewise.
	  * testsuite/ld-elf/orphan-12.d: Likewise.
	  * testsuite/ld-elf/orphan-5.d: Likewise.
	  * testsuite/ld-elf/orphan-7.d: Likewise.
	  * testsuite/ld-elf/orphan-8.d: Likewise.
	  * testsuite/ld-elf/orphan-9.d: Likewise.
	  * testsuite/ld-elf/orphan-region.d: Likewise.
	  * testsuite/ld-elf/orphan.d: Likewise.
	  * testsuite/ld-elf/pr19539.d: Likewise.
	  * testsuite/ld-elf/pr26256-1a.d: Likewise.
	  * testsuite/ld-elf/pr26907.d: Likewise.
	  * testsuite/ld-elf/pr28597.d: Likewise.
	  * testsuite/ld-elf/retain2.d: Likewise.
	  * testsuite/ld-elf/shared.exp: Likewise.
	  * testsuite/ld-elf/size-1.d: Likewise.
	  * testsuite/ld-elf/textaddr7.d: Likewise.
	  * testsuite/ld-elf/warn1.d: Likewise.
	  * testsuite/ld-elf/warn2.d: Likewise.
	  * testsuite/ld-i386/discarded1.d: Likewise.
	  * testsuite/ld-i386/pr19175.d: Likewise.
	  * testsuite/ld-i386/pr19539.d: Likewise.
	  * testsuite/ld-i386/pr23189.d: Likewise.
	  * testsuite/ld-plugin/lto-3r.d: Likewise.
	  * testsuite/ld-plugin/lto-5r.d: Likewise.
	  * testsuite/ld-plugin/lto.exp: Likewise.
	  * testsuite/ld-powerpc/ppc476-shared.d: Likewise.
	  * testsuite/ld-powerpc/ppc476-shared2.d: Likewise.
	  * testsuite/ld-powerpc/pr28827-2.d: Likewise.
	  * testsuite/ld-s390/s390.exp: Likewise.
	  * testsuite/ld-scripts/align2a.d: Likewise.
	  * testsuite/ld-scripts/align2b.d: Likewise.
	  * testsuite/ld-scripts/align5.d: Likewise.
	  * testsuite/ld-scripts/alignof.exp: Likewise.
	  * testsuite/ld-scripts/crossref.exp: Likewise.
	  * testsuite/ld-scripts/defined2.d: Likewise.
	  * testsuite/ld-scripts/defined3.d: Likewise.
	  * testsuite/ld-scripts/defined5.d: Likewise.
	  * testsuite/ld-scripts/pr14962.d: Likewise.
	  * testsuite/ld-scripts/pr18963.d: Likewise.
	  * testsuite/ld-scripts/pr20302.d: Likewise.
	  * testsuite/ld-scripts/print-memory-usage.exp: Likewise.
	  * testsuite/ld-scripts/rgn-at1.d: Likewise.
	  * testsuite/ld-scripts/rgn-at10.d: Likewise.
	  * testsuite/ld-scripts/rgn-at4.d: Likewise.
	  * testsuite/ld-scripts/rgn-at6.d: Likewise.
	  * testsuite/ld-scripts/rgn-at8.d: Likewise.
	  * testsuite/ld-scripts/rgn-at9.d: Likewise.
	  * testsuite/ld-scripts/rgn-over1.d: Likewise.
	  * testsuite/ld-scripts/rgn-over2.d: Likewise.
	  * testsuite/ld-scripts/rgn-over4.d: Likewise.
	  * testsuite/ld-scripts/rgn-over5.d: Likewise.
	  * testsuite/ld-scripts/rgn-over6.d: Likewise.
	  * testsuite/ld-scripts/script.exp: Likewise.
	  * testsuite/ld-scripts/sizeof.exp: Likewise.
	  * testsuite/ld-scripts/sort-file.d: Likewise.
	  * testsuite/ld-x86-64/discarded1.d: Likewise.
	  * testsuite/ld-x86-64/pr19175.d: Likewise.
	  * testsuite/ld-x86-64/pr19539a.d: Likewise.
	  * testsuite/ld-x86-64/pr19539b.d: Likewise.
	  * testsuite/ld-x86-64/pr23189.d: Likewise.

2023-11-10  Nick Clifton  <nickc@redhat.com>

	Move new features above the 'Changes in 2.41' comment

2023-11-10  Lulu Cai  <cailulu@loongson.cn>

	Add support for ilp32 register alias.

2023-11-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-09  Michael Matz  <matz@suse.de>

	bfd: use less memory in string merging
	the offset-to-entry mappings are allocated in blocks, which may
	become a bit wasteful in case there are extremely many small
	input files or sections.  This made it so that a large project
	(Qt5WebEngine) didn't build anymore on x86 32bit due to address
	space limits.  It barely fit into address space before the new
	string merging, and then got pushed over the limit by this.

	So instead of leaving the waste reallocate the maps to their final
	size once known.  Now the link barely fits again.

	bfd/
	    * merge.c (record_section): Reallocate offset maps to their
	    final size.

2023-11-09  Michael Matz  <matz@suse.de>

	ld: Avoid overflows in string merging
	as the bug report shows we had an overflow in the test if
	hash table resizing is needed.  Reorder the expression to avoid
	that.  There's still a bug somewhere in gracefully handling
	failure in resizing (e.g. out of memory), but this pushes the
	boundary for that occurring somewhen into the future and
	immediately helps the reporter.

	    bfd/

	    PR ld/31009
	    * merge.c (NEEDS_RESIZE): New macro avoiding overflow.
	    (sec_merge_maybe_resize): Use it.
	    (sec_merge_hash_insert): Ditto.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	ld: aarch64: Use lp64 abi in recent BTI stub tests
	The tests are not compatible with ilp32 abi: the GNU property
	note is ABI dependent (size changes) and the disasm is ABI
	dependent too.  Making the test portable between the ABIs is
	not trivial.

	For now force lp64 abi.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	ld: aarch64: Add BTI stub insertion test PR30930
	The test creates a large shared library and covers a number of
	BTI stub insertion cases.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Avoid BTI stub for a PLT that has BTI
	We decide to emit BTI stubs based on the instruction at the target
	location. But PLT code is generated later than the stubs so we always
	read 0 which is not a valid BTI.

	Fix the logic to special case the PLT section: this is code the linker
	generates so we know when it will have BTI.

	This avoids BTI stubs in large executables where the PLTs have them
	already. An alternative is to never emit BTI stubs for PLTs, instead
	use BTI in the PLT if a library gets too big, however that may be
	more tricky given the ordering of PLT sizing and stub insertion.

	Related to bug 30957.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Fix leaks in case of BTI stub reuse
	BTI stub parameters were recomputed even if those were already set up.
	This is unnecessary work and leaks the symbol name that is allocated
	for the stub.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Fix broken BTI stub PR30930
	Input sections are grouped together that can use the same stub area
	(within reach) and these groups have a stable id.

	Stubs have a name generated from the stub group id and target symbol.
	When a relocation requires a stub with a name that already exists, the
	stub is reused instead of adding a new one.

	For an indirect branch stub another BTI stub may be inserted near the
	target to provide a BTI landing pad.

	The BTI stub can end up with the same stub group id and thus the same
	name as the indirect stub. This happens if the target symbol is within
	reach of the indirect branch stub. Then, due to the name collision,
	only a single stub was emmitted which branched to itself causing an
	infinite loop at runtime.

	A possible solution is to just name the BTI stubs differently, but
	since in the problematic case the indirect and BTI stub are in the
	same stub area, a better solution is to emit a single stub with a
	direct branch. The stub is still needed since the caller cannot reach
	the target directly and we also want a BTI landing pad in the stub in
	case other indirect stubs target the same symbol and thus need a BTI
	stub.

	In short we convert an indirect branch stub into a BTI stub when the
	target is within reach and has no BTI. It is a hassle to change the
	symbol of the stub so a BTI stub may end up with *_veneer instead of
	*_bti_veneer after the conversion, but this should not matter much.
	(Refactoring some of _bfd_aarch64_add_call_stub_entries would be
	useful but too much for this bug fix patch.)

	The same conversion to direct branch could be done even if the target
	did not need a BTI. The stub groups are fixed in the current logic so
	linking can fail if too many stubs are inserted and the section layout
	is changed too much, but this only happens in extreme cases that can
	be reasonably ignored. Because of this the target cannot go out of
	reach during stub insertion so the optimization is valid, but not
	implemented by this patch for the non-BTI case.

	Fixes bug 30930.

2023-11-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Fix BTI stub optimization PR30957
	The instruction was looked up in the wrong input file (file of branch
	source instead of branch target) when optimizing away BTI stubs in

	  commit 5834f36d93cabf1a8bcc7dd7654141aed3d296bc
	  bfd: aarch64: Optimize BTI stubs PR30076

	This can cause adding BTI stubs when they are not necessary or removing
	them when they are (the latter is a correctness issue but it is very
	unlikely in practice).

	Fixes bug 30957.

2023-11-09  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Fix error in THE system register checking
	The erroneous omission of a "reg_value == " in the THE system register
	encoding check added in [1] led to an error which was not picked up in
	GCC but which was flagged in Clang due to its use of
	[-Werror,-Wconstant-logical-operand] check.  Together with this fix we
	add a new test for the THE registers to pick up their illegal use,
	adding an extra and important layer of validation.

	Furthermore, in separating system register from instruction
	implementation (with which only the former was of concern in the cited
	patch), additions made to `aarch64-tbl.h' are rolled back so
	that these can be added later when adding THE instructions to the
	codebase, a more natural place for these changes.

	[1] https://sourceware.org/pipermail/binutils/2023-November/130314.html

	opcodes/ChangeLog:

		* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo.
		* aarch64-tbl.h (THE): Remove.
		 (aarch64_feature_set aarch64_feature_the): Likewise.

	gas/ChangeLog:

		* testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE
		system registers.
		* testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise.

2023-11-09  Jan Beulich  <jbeulich@suse.com>

	x86: rework UWRMSR operand swapping
	As indicated during review already, doing the swapping early is overall
	cheaper than doing it only after operand matching.

2023-11-09  Jan Beulich  <jbeulich@suse.com>

	x86: do away with is_evex_encoding()
	As we have grown more uses of it, it becomes increasingly more desirable
	to replace it by a simpler check. Have i386-gen do at build time what so
	far was done at runtime: Deal with templates indicating EVEX-encoding by
	other than the EVex attribute, and set that to "dynamic" in such cases.

	This then allows simplifying a number of other conditionals as well.

2023-11-09  Jan Beulich  <jbeulich@suse.com>

	x86: split insn templates' CPU field
	Right now the opcode table has entries with ISA restrictions of the form
	FEAT1|FEAT2, the meaning of which depends on context and requires
	special treatment in tc-i386.c: Sometimes this means "both features
	requires", whereas originally it was intended to solely mean "all of
	these features required". Split the field, with the original one
	regaining its original meaning. The new field now truly means "any of
	these". The combination of both fields is still and &&-type check, i.e.
	(all of these) && (any of these). In the opcode table more involved
	combinations of features then also need expressing this way: "all"
	entities first, follow by "any" entities enclosed in parentheses, e.g.
	x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be
	added around the "any" part (unless parsing logic was further relaxed).

	Note that this way AVX512VL no longer needs as much special treatment,
	and hence templates previously using AVX512F|AVX512VL are switched to
	just AVX512VL.

	Note further that this requires FMA handling as resulting from
	da0784f961d8 ("x86: fold FMA VEX and EVEX templates") to be slightly
	re-done: FMA now becomes more similar to AVX and AVX2.

2023-11-09  Jan Beulich  <jbeulich@suse.com>

	x86: Cpu64 handling improvements
	First of all we want to also accumulate its reverse dependencies, such
	that we can use them in cpu_flags_match(). This is in particular in
	preparation of APX additions, such that e.g. BMI VEX-encoding templates
	can become combined VEX/EVEX ones.

	Once we have the reverse dependencies, we can further leverage them to
	omit explicit "&x64" from any insn templates dealing with 64-bit-mode-
	only ISA extensions. Besides helping readability for several insn
	templates we already have, this will also help with what is going to be
	added for APX (as all of the new templates would otherwise need to have
	"&x64").

	Note that rather than leaving a meaningless CPU_64_FLAGS (which is
	unused anyway), its emitting is now also suppressed.

2023-11-09  Jan Beulich  <jbeulich@suse.com>

	x86: Intel Core processors do not support CMPXCHG16B
	This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot
	possibly be supported by CPUs not supporting 64-bit mode.

2023-11-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-08  Carl Love  <cel@linux.ibm.com>

	rs6000, Fix test gdb.base/store.exp
	The test currently fails for IEEE 128-bit floating point types.  PowerPC
	supports the IBM double 128-bit floating point format and IEEE 128-bit
	format.  The IBM double 128-bit floating point format uses two 64-bit
	floating point registers to store the 128-bit value.  The IEEE 128-bit
	floating point format stores the value in a single 128-bit vector-scalar
	register (vsr).

	The various floating point values, 32-bit float, 64-bit double, IBM double
	128-bit float and IEEE 128-bit floating point numbers are all mapped to the
	DWARF fpr numbers.  The issue is the IEEE 128-bit floating point values are
	actually stored in a vsr not the fprs.  This patch changes the register
	mapping for the vsrs from the fpr to the vsr registers so the value is
	properly accessed by GDB.  The functions rs6000_linux_register_to_value,
	rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
	the value is an IEEE 128-bit floating point value and adjust the register
	number as needed.  The test in function rs6000_convert_register_p is fixed
	so it is only true for floating point values.

	This patch fixes three regression tests in gdb.base/store.exp.

	The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
	with no regressions.

2023-11-08  Carl Love  <cel@us.ibm.com>

	rs6000, Fix Linux DWARF register mapping
	Overview of issues fixed by the patch.

	The primary issue this patch fixes is the DWARF register mapping for
	Linux.  The changes in ppc-linux-tdep.c fix the DWARF register mapping
	issues.  The register mapping issue is responsible for two of the
	five regression bugs seen in gdb.base/store.exp.

	Once the register mapping was fixed, an underlying issue with the unwinding
	of the signal trampoline in common-code in ifrun.c was found.  This
	underlying bug is best described by Ulrich in the following description.

	  The unwinder bug shows up on platforms where the kernel uses a trampoline
	  to dispatch "calls to" the signal handler (not just *returns from* the
	  signal handler).  Many platforms use a trampoline for signal return, and
	  that is working fine, but the only platform I'm (Ulrich) aware of that
	  uses a trampoline for signal handler calls is (recent kernels for)
	  PowerPC.  I believe the rationale for using a trampoline here
	  is to improve performance by avoiding unbalancing of the
	  branch predictor's call/return stack.

	  However, on PowerPC the bug is dormant as well as it is hidden
	  by *another* bug that prevents correct unwinding out of the
	  signal trampoline.  This is because the custom CFI for the
	  trampoline uses a register number (VSCR) that is not ever used
	  by compiler-generated CFI, and that particular register is
	  mapped to an invalid number by the current PowerPC DWARF mapper.

	The underlying unwinder bug is exposed by the "new" regression failures
	in gdb.base/sigstep.exp.  These failures were previously masked by
	the fact that GDB was not seeing a valid frame when it tried to unwind
	the frames.  The sigstep.exp test is specifically testing stepping into
	a signal handler.  With the correct DWARF register mapping in place,
	specifically the VSCR mapping, the signal trampoline code now unwinds to a
	valid frame exposing the pre-existing bug in how the signal handler on
	PowerPC works.  The one line change infrun.c fixes the exiting bug in
	the common-code for platforms that use a trampoline to dispatch calls
	to the signal handler by not stopping in the SIGTRAMP_FRAME.

	Detailed description of the DWARF register mapping fix.

	The PowerPC DWARF register mapping is the same for the .eh_frame and
	.debug_frame on Linux.  PowerPC uses different mapping for .eh_frame and
	.debug_frame on other operating systems.  The current GDB support for
	mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
	rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
	The files have some legacy mappings for spe_acc, spefscr, EV which was
	removed from GCC in 2017.

	This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
	and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
	the DWARF register mappings on Linux.  Function
	rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
	and gdbarch_stab_reg_to_regnum since the mappings are the same.

	The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
	call set_gdbarch_dwarf2_reg_to_regnum map the new function
	rs6000_linux_dwarf2_reg_to_regnum for the architecture.  Similarly,
	dwarf2_frame_set_adjust_regnum is called to map
	rs6000_linux_adjust_frame_regnum into the architecture.

	Additional detail on the signal handling fix.

	The specific sequence of events for handling a signal on most
	architectures is as follows:

	  1) Some code is running when a signal arrives.
	  2) The kernel handles the signal and dispatches to the handler.
	    ...

	However on PowerPC the sequence of events is:

	  1) Some code is running when a signal arrives.
	  2) The kernel handles the signal and dispatches to the trampoline.
	  3) The trampoline performs a normal function call to the handler.
	      ...

	We want the "nexti" to step into, not over, signal handlers invoked by
	the kernel.  This is the case for most platforms as the kernel puts a
	signal trampoline frame onto the stack to handle proper return after the
	handler.  However, on some platforms such as PowerPC, the kernel actually
	uses a trampoline to handle *invocation* of the handler.  We do not
	want GDB to stop in the SIGTRAMP_FRAME.  The issue is fixed in function
	process_event_stop_test by adding a check that the frame is not a
	SIGTRAMP_FRAME to the if statement to stop in a subroutine call.  This
	prevents GDB from erroneously detecting the trampoline invocation as a
	subroutine call.

	This patch fixes two regression test failures in gdb.base/store.exp.

	The patch then fixes an exposed, dormant, signal handling issue that
	is exposed in the signal handling test gdb.base/sigstep.exp.

	The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
	no new regressions.  Note, only two of the five failures in store.exp
	are fixed.  The remaining three failures are fixed in a following
	patch.

2023-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: call update_thread_list after completing an inferior call
	I noticed that if GDB is using a remote or extended-remote target,
	then, if an inferior call caused a new thread to appear, or for an
	existing thread to exit, then these events are not reported to the
	user.

	The problem is that for these targets GDB relies on a call to
	update_thread_list to learn about changes to the inferior's thread
	list.

	If GDB doesn't pass through the normal stop code then GDB will not
	call update_thread_list, and so will not report changes in the thread
	list.

	This commit adds an additional update_thread_list call, after which
	thread events are correctly reported.

2023-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: call update_thread_list for $_inferior_thread_count function
	I noticed that sometimes the value returned by $_inferior_thread_count
	can become out of sync with the actual thread count of the inferior,
	and will disagree with the number of threads reported by 'info
	threads'.  This commit fixes this issue.

	The cause of the problem is that 'info threads' includes a call to
	update_thread_list, this can be seen in print_thread_info_1 in
	thread.c, while $_inferior_thread_count doesn't include a similar
	call, see the function inferior_thread_count_make_value also in
	thread.c.

	Of course, this is only a problem when GDB is running on a target that
	relies on update_thread_list calls to learn about new threads,
	e.g. remote or extended-remote targets.  Native targets generally
	learn about new threads as soon as they appear and will not have this
	problem.

	I ran into this issue when writing a test for the next commit which
	uses inferior function calls to add an remove threads from an
	inferior.  But for testing I've made use of non-stop mode and
	asynchronous inferior execution; by reading the inferior state I can
	know when a new thread has been created, at which point I can print
	$_inferior_thread_count while the inferior is still running.  This is
	important, if I stop the inferior then GDB will pass through an
	update_thread_list call in the normal stop code, which will
	synchronise the thread list, after which $_inferior_thread_count will
	report the correct value.

	With this change in place $_inferior_thread_count is now correct.

2023-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: add a custom command completer for disassemble command
	Add a new command completer function for the disassemble command.
	There are two things that this completion function changes.  First,
	after the previous commit, the new function calls skip_over_slash_fmt,
	which means that hitting tab after entering a /OPT flag now inserts a
	space ready to start typing the address to disassemble at:

	  (gdb) disassemble /r<TAB>
	  (gdb) disassemble /r <CURSOR>

	But also, we now get symbol completion after a /OPT option set,
	previously this would do nothing:

	  (gdb) disassemble /r mai<TAB>

	But now:

	  (gdb) disassemble /r mai<TAB>
	  (gdb) disassemble /r main <CURSOR>

	Which was my main motivation for working on this commit.

	However, I have made a second change in the completion function.
	Currently, the disassemble command calls the generic
	location_completer function, however, the disassemble docs say:

	     Note that the 'disassemble' command's address arguments are specified
	  using expressions in your programming language (*note Expressions:
	  Expressions.), not location specs (*note Location Specifications::).
	  So, for example, if you want to disassemble function 'bar' in file
	  'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble
	  foo.c:bar'.

	And indeed, if I try:

	  (gdb) disassemble hello.c:main
	  No symbol "hello" in current context.
	  (gdb) disassemble hello.c::main
	  No symbol "hello" in current context.
	  (gdb) disassemble 'hello.c'::main
	  Dump of assembler code for function main:
	  ... snip ...

	But, if I do this:

	  (gdb) disassemble hell<TAB>
	  (gdb) disassemble hello.c:<CURSOR>

	which is a consequence of using the location_completer function.  So
	in this commit, after calling skip_over_slash_fmt, I forward the bulk
	of the disassemble command completion to expression_completer.  Now
	when I try this:

	  (gdb) disassemble hell<TAB>

	gives nothing, which I think is an improvement.  There is one slight
	disappointment, if I do:

	  (gdb) disassemble 'hell<TAB>

	I still get nothing.  I had hoped that this would expand to:
	'hello.c':: but I guess this is a limitation of the current
	expression_completer implementation, however, I don't think this is a
	regression, the previous expansion was just wrong.  Fixing
	expression_completer is out of scope for this commit.

	I've added some disassembler command completion tests, and also a test
	that disassembling using 'FILE'::FUNC syntax works, as I don't think
	that is tested anywhere.

2023-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: make skip_over_slash_fmt available outside printcmd.c
	Move the function skip_over_slash_fmt into completer.c, and make it
	extern, with a declaration in completer.h.

	This is a refactor in order to support the next commit.  I've not
	changed any of the code in skip_over_slash_fmt.

	There should be no user visible changes after this commit.

2023-11-08  Andrew Burgess  <aburgess@redhat.com>

	gdb: error if /r and /b are used with disassemble command
	The disassembler gained a new /b flag in this commit:

	  commit d4ce49b7ac077a9882d6a5e689e260300045ca88
	  Date:   Tue Jun 21 20:23:35 2022 +0100

	      gdb: disassembler opcode display formatting

	The /b and /r flags result in the instruction opcodes displayed in
	different formats, so it's not possible to have both at the same
	time.  Currently the /b flag overrides the /r flag.

	We have a similar situation with the /m and /s flags, but here, if the
	user tries to use both flags then they will get an error.

	I think the error is clearer, so in this commit I propose that we add
	an error if /r and /b are both used.

	Obviously this change breaks backwards compatibility.  I don't have a
	compelling argument for why we should make the change beyond my
	feeling that it was a mistake not to add this error from the start,
	and that the new behaviour is better.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-11-08  Jan Beulich  <jbeulich@suse.com>

	gas: S_GET_{NAME,SEGMENT}() don't alter their input symbol
	Make their parameters pointer-to-const, thus allowing callers to also be
	const-correct where possible.

2023-11-08  Clément Chigot  <chigot@adacore.com>

	ld: print branch fixups into the map file for ppc elf targets
	In a safety context, it could interesting to track the trampolines being
	generated, ensuring there are expected or not.

	bfd/ChangeLog:

		* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.

	ld/ChangeLog:

		* ld.texi (--print-map): Add new item about fixups.

2023-11-08  Tom Tromey  <tom@tromey.com>

	Add minimal thread-safety to BFD
	This patch provides some minimal thread-safety to BFD.

	The BFD client can request thread-safety by providing a lock and
	unlock function.  The globals used during BFD creation (e.g.,
	bfd_id_counter) are then locked, and the file descriptor cache is also
	locked.  A function to clean up any thread-local data is now provided
	for BFD clients.

		* bfd-in2.h: Regenerate.
		* bfd.c (lock_fn, unlock_fn): New globals.
		(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
		functions.
		* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
		(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
		and unlock.
		(cache_bclose): Add comment.
		(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
		(_bfd_cache_init_unlocked): New function.
		(bfd_cache_init): Use it.  Lock and unlock.
		(_bfd_cache_close_unlocked): New function.
		(bfd_cache_close, bfd_cache_close_all): Use it.  Lock and unlock.
		(_bfd_open_file_unlocked): New function.
		(bfd_open_file): Use it.  Lock and unlock.
		* doc/bfd.texi (BFD front end): Add Threading menu item.
		* libbfd.h: Regenerate.
		* opncls.c (_bfd_new_bfd): Lock and unlock.
		* po/bfd.pot: Regenerate.

2023-11-08  Tom Tromey  <tom@tromey.com>

	Make various error-related globals thread-local
	This changes bfd_error et al to be thread-local.

		* Makefile.in: Regenerate.
		* aclocal.m4: Include ax_tls.m4.
		* ax_tls.m4: New file.
		* bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf):
		Now thread-local.
		(bfd_asprintf): Update docs.
		* config.in, configure: Regenerate.
		* configure.ac: Call AX_TLS.
		* po/bfd.pot: Regenerate.

2023-11-08  Tom Tromey  <tom@tromey.com>

	Make _bfd_error_buf static
	This makes _bfd_error_buf static and adds a way to clear it.  I felt
	that this made the subsequent patches a little cleaner.

		* bfd.c (_bfd_error_buf): Now static.
		(bfd_set_input_error): Use _bfd_clear_error_data.
		(_bfd_clear_error_data): New function.
		(bfd_init): Use _bfd_clear_error_data.
		* libbfd.h: Regenerate.
		* opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
		* po/bfd.pot: Regenerate.

2023-11-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-07  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add LSE128 instructions
	Implement, together with the necessary tests, the following new LSE128
	atomic instructions:

	  * Atomic bit clear on quadword in memory (ldclrp{a|l|al});
	  * Atomic bit set on quadword in memory (ldsetp{a|l|al});
	  * Swap quadword in memory (swpp{a|l|al});

	gas/ChangeLog:

		* testsuite/gas/aarch64/lse128-atomic.d: New.
		* testsuite/gas/aarch64/lse128-atomic.s: Likewise.

	opcodes/ChangeLog:

		* aarch64-tbl.h (ldclrp): new _LSE128_INSN entry.
		(ldclrpa):  Likewise.
		(ldclrpal): Likewise.
		(ldclrpl): Likewise.
		(ldsetp): Likewise.
		(ldsetpa): Likewise.
		(ldsetpal): Likewise.
		(ldsetpl): Likewise.
		(swpp): Likewise.
		(swppa): Likewise.
		(swppal): Likewise.
		(swppl): Likewise.
		* aarch64-asm-2.c: Regenerate.
		* aarch64-dis-2.c: Likewise.
		* aarch64-opc-2.c: Likewise.

2023-11-07  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add arch support for LSE128 extension
	Enable the `+lse128' feature modifier which, together with new
	internal feature flags, enables LSE128 instructions, which are
	represented via the new `_LSE128_INSN' macro.

	gas/ChangeLog:

		* config/tc-aarch64.c (aarch64_features): Add new "lse128"
		entry.

	include/ChangeLog:

		* include/opcode/aarch64.h (enum aarch64_feature_bit): New
		AARCH64_FEATURE_LSE128 feature bit.
		(enum aarch64_insn_class): New lse128_atomic instruction class.

	opcodes/ChangeLog:

		* opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
		(LSE128): Likewise.
		(_LSE128_INSN): Likewise.

2023-11-07  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add LSE128 instruction operand support
	Given the particular encoding of the LSE128 instructions, create the
	necessary shared input+output operand register description and
	handling in the code to allow for the encoding of the LSE128 128-bit
	atomic operations.

	gas/ChangeLog:

		* config/tc-aarch64.c (parse_operands):

	include/ChangeLog:

		* opcode/aarch64.h (enum aarch64_opnd):

	opcodes/ChangeLog:

		* aarch64-opc.c (fields):
		(aarch64_print_operand):
		* aarch64-opc.h (enum aarch64_field_kind):
		* aarch64-tbl.h (AARCH64_OPERANDS):

2023-11-07  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add 128-bit system register flags
	In preparation for the implementation of 128-bit system register
	support across the toolchain, this patch adds the feature flag
	F_REG_128 and adds it to relevant system registers in
	`aarch64-sys-regs.def'.

	Given the shared nature of this file, this change is made necessary
	initially to implement argument validation in the `__arm_rsr128' and
	`__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in
	the binutils implementation of the corresponding `mrrs' and `msrr'
	instructions.

	Regression tested on aarch64-linux-gnu, no regressions.

	opcodes/ChangeLog:

		* aarch64-opc.h (F_REG_128):  New flag.
		* aarch64-sys-regs.def (par_el1): Add F_REG_128 flag.
		(rcwmask_el1): Likewise.
		(rcwsmask_el1): Likewise.
		(ttbr0_el1): Likewise.
		(ttbr0_el12): Likewise.
		(ttbr0_el2): Likewise.
		(ttbr1_el1): Likewise.
		(ttbr1_el12): Likewise.
		(ttbr1_el2): Likewise.
		(vttbr_el2): Likewise.

2023-11-07  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Add THE system register support
	Add Binutils support for system registers associated with the
	Translation Hardening Extension (THE).

	In doing so, we also add core feature support for THE, enabling its
	associated feature flag and implementing the necessary
	feature-checking machinery.

	Regression tested on aarch64-linux-gnu, no regressions.

	gas/ChangeLog:

		* config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
		* doc/c-aarch64.texi (AArch64 Extensions): Update
		documentation for `the' option.
		* testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
		associated system registers.
		* testsuite/gas/aarch64/sysreg-8.d: Likewise.

	include/ChangeLog:

		* opcode/aarch64.h (enum aarch64_feature_bit): Add
		AARCH64_FEATURE_THE.

	opcode/ChangeLog:

		* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
		system register check support.
		* aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
		* aarch64-tbl.h: Define `THE' preprocessor macro.

2023-11-07  Simon Marchi  <simon.marchi@efficios.com>

	gdb/arm: remove thumb bit in arm_adjust_breakpoint_address
	When compiling gdb with -fsanitize=address on ARM, I get a crash in test
	gdb.arch/arm-disp-step.exp, reproduced easily with:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
	    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
	    =================================================================
	    ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494

	Since it doesn't require running the program, it can be reproduced locally on a
	dev machine other than ARM, after acquiring the test binary.

	The length of the allocate buffer `buf` is 1, and we try to extract an
	integer of size 2 from it.  The length of 1 comes from the subtraction
	`bpaddr - boundary`.  Normally, on ARM, all instructions are aligned on
	a multiple of 2, so it's weird for this subtraction to result in 1.  In
	this case, boundary comes from the result of find_pc_partial_function
	returning 0x549:

	    (gdb) p/x bpaddr
	    $2 = 0x54a
	    (gdb) p/x boundary
	    $3 = 0x549
	    (gdb) p/x bpaddr - boundary
	    $4 = 0x1

	0x549 is the address of the test_call_subr label, 0x548, with the thumb
	bit enabled.  Before doing some math with the address, I think we need
	to strip the thumb bit, like is done elsewhere (for instance for bpaddr
	earlier in the same function).

	I wonder if find_pc_partial_function should do that itself, in order to
	return an address that is suitable for arithmetic.  In any case, that
	would be a change with a broad impact, so for now just fix the issue
	locally.

	After the patch:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
	    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
	    Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103.

	Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288
	Approved-By: Luis Machado <luis.machado@arm.com>

2023-11-07  Jan Beulich  <jbeulich@suse.com>

	ld/x86: reduce testsuite dependency on system object files
	PR ld/30722
	Tests looking for certain .note-section recorded properties may not
	involve object files from the underlying platform (e.g. via using the C
	compiler for linking): Such object files may themselves have similar
	note sections, and hence they may influence the overall outcome.

	For now convert just the tests known to be affected by crt*.o coming
	with "ISA v3 needed" notes. Eventually other tests ought to be
	converted, too.

2023-11-07  Jan Beulich  <jbeulich@suse.com>

	Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA"
	This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1.
	It wrongly altered testcase expectations; the issue will need
	taking care of differently.

2023-11-07  Mary Bennett  <mary.bennett@embecosm.com>

	RISC-V: Add support for XCValu extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett@embecosm.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
	          instruction class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn): Added the necessary
	          operands for the extension.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Noted XCValu as an additional ISA extension
	          for CORE-V.
		* testsuite/gas/riscv/cv-alu-boundaries.d: New test.
		* testsuite/gas/riscv/cv-alu-boundaries.l: New test.
		* testsuite/gas/riscv/cv-alu-boundaries.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-march.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-march.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-march.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
		* testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
		* testsuite/gas/riscv/cv-alu-insns.d: New test.
		* testsuite/gas/riscv/cv-alu-insns.s: New test.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Disassemble xcb operand.
		* riscv-opc.c: Defined the MASK and added XCValu instructions.

	include/ChangeLog:

		* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
	          for XCValu.
		* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
	          for XCValu.
		(enum riscv_insn_class): Added the XCValu instruction class.

2023-11-07  Mary Bennett  <mary.bennett@embecosm.com>

	RISC-V: Add support for XCVmac extension in CV32E40P
	Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

	Contributors:
	  Mary Bennett <mary.bennett@embecosm.com>
	  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	  Pietra Ferreira <pietra.ferreira@embecosm.com>
	  Charlie Keaney
	  Jessica Mills
	  Craig Blackmore <craig.blackmore@embecosm.com>
	  Simon Cook <simon.cook@embecosm.com>
	  Jeremy Bennett <jeremy.bennett@embecosm.com>
	  Helene Chelin <helene.chelin@embecosm.com>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
	          instruction class.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn): Added the necessary
	          operands for the extension.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
	          for CORE-V.
		* testsuite/gas/riscv/cv-mac-fail-march.d: New test.
		* testsuite/gas/riscv/cv-mac-fail-march.l: New test.
		* testsuite/gas/riscv/cv-mac-fail-march.s: New test.
		* testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
		* testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
		* testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
		* testsuite/gas/riscv/cv-mac-insns.d: New test.
		* testsuite/gas/riscv/cv-mac-insns.s: New test.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Disassemble information with
	          the EXTRACT macro implemented.
		* riscv-opc.c: Defined the MASK and added
	          XCVmac instructions.

	include/ChangeLog:

		* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
	          for XCVmac.
		* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
	          for uimm.
		(enum riscv_insn_class): Added the XCVmac instruction class.

2023-11-07  Tom Tromey  <tom@tromey.com>

	Remove EXTERN_C and related defines
	common-defs.h has a few defines that I suspect were used during the
	transition to C++.  These aren't needed any more, so remove them.

	Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-11-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-06  Carl Love  <cel@linux.ibm.com>

	gdb: Update email address for Carl Love in gdb/MAINTAINERS

2023-11-06  Hannes Domani  <ssbssa@yahoo.de>

	Fix resizing of TUI python windows
	When resizing from a big to small terminal size, and you have a
	TUI python window that would then be outside of the new size,
	valgrind shows this error:

	==3389== Invalid read of size 1
	==3389==    at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
	==3389==    by 0xC3E3C9: wrefresh (lib_refresh.c:63)
	==3389==    by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
	==3389==    by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
	==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
	==3389==    by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
	==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
	==3389==    by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
	==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
	==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
	==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
	==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
	==3389==  Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
	==3389==    at 0x4A0A430: free (vg_replace_malloc.c:446)
	==3389==    by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
	==3389==    by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
	==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
	==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
	==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
	==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
	==3389==    by 0x8E40E9: captured_command_loop() (main.c:407)
	==3389==    by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
	==3389==    by 0x62AC04: main (gdb.c:39)

	It's because tui_py_window::m_inner_window still has the outside
	coordinates, and wnoutrefresh then does an out-of-bounds access.

	Fix this by resetting m_inner_window on every resize, it will anyways
	be recreated in the next rerender call.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-11-06  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Change gdb.base/examine-backwards.exp for AIX.
	In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump
	an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating
	it cannot access memory.

	This patch is a small change to get it working in AIX as well.

2023-11-06  Nick Clifton  <nickc@redhat.com>

	ld: =fillexp different behaviors for hexidecimal literal
	  PR 30865
	  * ld.texi: Update description of the FILL command.
	  * testsuite/ld-scripts/fill2.d: New test.
	  * testsuite/ld-scripts/fill2.t: New test source.
	  * testsuite/ld-scripts/data.exp: Run the new test.

2023-11-06  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase.
	Same as commit 4352c0ac04a.

	gas/
		* testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2.

2023-11-06  Nelson Chu  <nelson@rivosinc.com>
	    Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Moved out linker internal relocations after R_RISCV_max.
	Just the lightest modifications about this, without any further checks and
	considering --emit-relocs.  We will need to improve it in the future, but
	first do this to avoid conflicts between linker internal relocations and the
	new definition of psabi.  For example, TLSDESC relocs.

	Passed riscv-gnu-toolchain regressions, so should be safe enough to commit.


	bfd/
		* reloc.c: Removed linker internal relocations.
		* bfd-in2.h: Regenerated.
		* libbfd.h: Regenerated.
		* elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h.
		* elfxx-riscv.c (howto_table, howto_table_internal): Moved linker
		internal relocations from howto_table into howto_table_internal.
		(riscv_reloc_map): Removed linker internal relocations mapping.
		(riscv_elf_rtype_to_howto): Return howto of linker internal
		relocations from howto_table_internal.
	include/
		* elf/riscv.h: Defined linker internal relocations after R_RISCV_max.

2023-11-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.exp
	Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
	- passes when gdb is configured using $(cd ../src; pwd)/configure, but
	- fails when using ../src/configure.

	Fix this by making the matching more precise:
	...
	-    -re -wrap "$objdir.*" {
	+    -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
	...
	such that we only fail on the line:
	...
	[symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
	  /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
	...

	Reported-By: Carl Love <cel@us.ibm.com>

2023-11-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-05  Tom Tromey  <tom@tromey.com>

	Pre-read DWZ file in DWARF reader
	While working on background reading of DWARF, I came across the
	DWZ-reading code.  This code can query the user (via the debuginfod
	support) -- something that cannot be done off the main thread.

	Looking into it, I realized that this code can be run much earlier,
	avoiding this problem.  Digging a bit deeper, I also found a
	discrepancy here between how the DWARF reader works in "readnow" mode
	as compared to the normal modes.

	This patch cleans this up by trying to read the DWZ file earlier, and
	also by having the DWARF reader convert any exception here into a
	warning.  This unifies the various cases, but also makes it so that
	errors do not prevent gdb from continuing on to the extent possible.

	Regression tested on x86-64 Fedora 38.

2023-11-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-03  Tom Tromey  <tromey@adacore.com>

	Remove unused declaration
	I found a declaration in py-stopevent.h for which there is no
	definition.  This patch removes it.

2023-11-03  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: mark array_view::slice with [[nodiscard]]
	I (almost) had a bug where I did:

	    buffer.slice (...)

	but I meant:

	    buffer = buffer.slice (...)

	The first one does nothing, it creates a new array_view but without
	using it, it's useless.  Mark the slice methods with [[nodiscard]]
	(which is standard C++17) so that error would generate a warning.

	I guess that many functions could be marked as nodiscard, essentially
	function that is pure (doesn't have side-effects).  But this one seems
	particularly easy to mis-use.

	Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb
	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-03  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: record and print failed selftest names
	Since "maint selftest" now runs quite a lot of tests (especially in an
	all-targets build), I thought it would be useful to print a summary at
	the end of what failed.  So, implement that.

	Print the summary before the "Ran %d unit tests, %zu failed\n" line, so
	that that one remains the last line, and the gdb.gdb/unittest.exp
	doesn't need to be changed.

	The output looks like (if I force a failure in a test):

	    (gdb) maint selftest
	    ...
	    Running selftest value_copy.
	    Running selftest xml_escape_text.
	    Running selftest xml_escape_text_append.

	    Failures:
	      aarch64-analyze-prologue

	    Ran 4134 unit tests, 1 failed
	    (gdb)

	Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e
	Approved-By: Tom Tromey <tom@tromey.com>

2023-11-03  Jan Beulich  <jbeulich@suse.com>

	gas: correct ignoring of C-style number suffixes
	First of all the respective original changes didn't deal with just 0
	having such a suffix - this needs additional logic outside of
	integer_constant(). Further bogus suffixes having more than two L-s
	were accepted, while valid suffixes with U following the L(s) weren't.
	Finally respective tests were introduced for Sparc only.

	Reviewed-by: Neal Frager <neal.frager@amd.com>

2023-11-03  Jan Beulich  <jbeulich@suse.com>

	RISC-V: reduce redundancy in load/store macro insn handling
	Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and
	FS{H,W,D,Q} the sole difference between the handling is the insn
	mnemonic passed to the common handling functions. The intended mnemonic,
	however, can easily be retrieved. Furthermore leverags that Sx and FSx
	are then handled identically, too, and hence their cases can also be
	folded.

	RISC-V: Lx/Sx macro insn tests
	Make sure these (continue to) work as intended.

	RISC-V: add F- and D-extension testcases
	Make sure future changes won't regress any of this. Also cover the FLH
	and FSH macro insns of the Zfh extension.

	RISC-V: make FLQ/FSQ macro-insns work
	When support for the Q extension was added, the libopcodes side of these
	macro-insns was properly covered, but no backing support in gas was
	added. In new testcases cover not just these, but all Q-extension insns.

2023-11-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-02  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix nr array elements in ppc64_aggregate_candidate
	On AlmaLinux 9.2 powerpc64le I run into:
	...
	(gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector
	finish^M
	Run till exit from #0  pck.create_small_float_vector () at pck.adb:30^M
	0x00000000100022d4 in p () at p.adb:25^M
	25         Vector := Create_Small_Float_Vector;^M
	Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M
	(gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector
	...
	while this is expected:
	...
	Value returned is $3 = (4.25, 4.25)^M
	...

	The problem is here in ppc64_aggregate_candidate:
	...
			  if (!get_array_bounds (type, &low_bound, &high_bound))
			    return -1;
			  count *= high_bound - low_bound
	...

	The array type (containing 2 elements) is:
	...
	   type Small_Float_Vector is array (1 .. 2) of Float;
	...
	so we have:
	...
	(gdb) p	low_bound
	$1 = 1
	(gdb) p	high_bound
	$2 = 2
	...
	but we calculate the number of elements in the array using
	"high_bound - low_bound", which is 1.

	Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous
	aggregate.

	Fix this by calculating the number of elements in the array by using
	"high_bound - low_bound + 1" instead.

	Furthermore, high_bound can (in general, though perhaps not here) also be
	smaller than low_bound, so to be safe take that into account as well:
	...
		  LONGEST nr_array_elements = (low_bound > high_bound
					       ? 0
					       : (high_bound - low_bound + 1));
		  count *= nr_array_elements;
	...

	Tested on powerpc64le-linux.

	Approved-By: Ulrich Weigand <uweigand@de.ibm.com>

	PR tdep/31015
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015

2023-11-02  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add GCS system registers.
	This patch adds support for 10 new AArch64 system registers
	(gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3,
	gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3),
	which are enabled on using Guarded Control Stack (+gcs flag)
	feature.

	aarch64: Add support for GCSB DSYNC instruction.
	This patch adds support for Guarded control stack data synchronization
	instruction (GCSB DSYNC). This instruction is allocated to existing
	HINT space and uses the HINT number 19 and to match this an entry is
	added to the aarch64_hint_options array.

2023-11-02  srinath  <srinath.parvathaneni@arm.com>

	aarch64: Add support for GCS extension.
	This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
	optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
	(eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.

	Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
	gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.

2023-11-02  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

	aarch64: Add support for Check Feature Status Extension.
	This patch adds support for Check Feature Status Extension (CHK) which
	is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
	(hint #40).

2023-11-02  srinath  <srinath.parvathaneni@arm.com>

	aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures.
	This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a)
	and Armv9.4-A architecture (-march=armv9.4-a).

2023-11-02  Nick Clifton  <nickc@redhat.com>

	ld x86_64 tests: Accept x86-64-v3 as a needed ISA
	  * testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3.
	  * testsuite/ld-x86-64/property-4.r: Likewise.
	  * testsuite/ld-x86-64/property-5.r: Likewise.

2023-11-02  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: remove dependency on help2man
	help2man is no longer used to create the gprofng man pages.

	gprofng/ChangeLog
	2023-10-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* configure.ac: Remove HELP2MAN.
		* Makefile.in: Rebuild.
		* configure: Rebuild.
		* doc/Makefile.in: Rebuild.
		* gp-display-html/Makefile.in: Rebuild.
		* src/Makefile.in: Rebuild.

2023-11-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-11-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte>
	Use the gdb::byte_vector typedef when possible.

	Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a

2023-11-01  Nick Clifton  <nickc@redhat.com>

	Fix typo in recent update to the ld/NEWS file

	ld: Support input section description keyword: REVERSE
	  PR 27565
	  * ldlex.l: Add REVERSE.
	  * ldgram.y: Allow REVERSE to be used wherever a sorting command can be used.
	  * ld.h (struct wildcard_spec): Add 'reversed' field.
	  * ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field.
	  * ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field.
	  * ld.texi: Document the new feature.
	  * NEWS: Mention the new feature.
	  * testsuite/ld-scripts/sort-file-reversed-1.d: New test driver.
	  * testsuite/ld-scripts/sort-file-reversed-1.t: New test source.
	  * testsuite/ld-scripts/sort-file-reversed-2.t: New test source.
	  * testsuite/ld-scripts/sort-file-reversed-2.d: New test driver.
	  * testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver.
	  * testsuite/ld-scripts/sort-sections-reversed-1.t: New test source.
	  * testsuite/ld-scripts/sort-sections-reversed-2.t: New test source.
	  * testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver.
	  * testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver.
	  * testsuite/ld-scripts/sort-sections-reversed-3.t: New test source.

2023-11-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Work around gas PR28629
	When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2
	ppc64le, I run into:
	...
	FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
	...

	The problem is that we get:
	...
	    7              [ No Assembly Available ]
	...
	because tui_get_begin_asm_address doesn't succeed.

	In more detail, tui_get_begin_asm_address calls:
	...
			    find_line_pc (sal.symtab, sal.line, &addr);
	...
	with:
	...
	(gdb) p *sal.symtab
	$5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0,
	  filename = "tui-layout-asm-short-prog.S",
	  filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S",
	  m_language = language_asm, fullname = 0x0}
	(gdb) p sal.line
	$6 = 1
	...

	The problem is the filename_for_id which is the source file prefixed with the
	compilation dir rather than the source dir.

	This is due to faulty debug info generated by gas, PR28629:
	...
	    <1a>   DW_AT_name        : tui-layout-asm-short-prog.S
	    <1e>   DW_AT_comp_dir    : $gdb/build/gdb/testsuite
	    <22>   DW_AT_producer    : GNU AS 2.35.2
	...

	The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry,
	making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S.

	The bug is fixed starting version 2.38, where we get instead:
	...
	    <1a>   DW_AT_name        :
	             $gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S
	    <1e>   DW_AT_comp_dir    : $gdb/build/gdb/testsuite
	    <22>   DW_AT_producer    : GNU AS 2.38
	...

	Work around the faulty debug info by constructing the filename_for_id using
	the second directory from the directory table in the .debug_line header:
	...
	 The Directory Table (offset 0x22, lines 2, columns 1):
	  Entry	Name
	  0	$gdb/build/gdb/testsuite
	  1	$gdb/src/gdb/testsuite/gdb.tui
	...

	Note that the used gas contains a backport of commit 3417bfca676 ("GAS:
	DWARF-5: Ensure that the 0'th entry in the directory table contains the
	current working directory."), because directory 0 is correct.  With the
	unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of
	entry 1.

	Add a dwarf assembly test-case that reflects the debug info as generated by
	unpatched gas 2.35.2.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Add producer_is_gas
	Add producer_is_gas, a generic way to get the gas version from the
	producer string.

	Tested on x86_64-linux.

2023-10-31  Tom Tromey  <tromey@adacore.com>

	Implement DAP setVariable request
	This patch implements the DAP setVariable request.

	setVariable is a bit odd in that it specifies the variable to modify
	by passing in the variable's container and the name of the variable.
	This approach can't handle variable shadowing (there are a couple of
	open DAP bugs on this topic), so this patch renames duplicates to
	avoid the problem.

2023-10-31  Hu, Lin1  <lin1.hu@intel.com>

	Support Intel USER_MSR
	This patches aims to support Intel USER_MSR. In addition to the usual
	support, this patch includes encoding and decoding support for MAP7 and
	immediate numbers as the last operand (ATT style).

	gas/ChangeLog:

		* NEWS: Support Intel USER_MSR.
		* config/tc-i386.c (smallest_imm_type): Reject imm32 in 64bit
		mode.
		(build_vex_prefix): Add VEXMAP7.
		(md_assemble): Handling the imm32 of USER_MSR.
		(match_template): Handling the unusual immediate.
		* doc/c-i386.texi: Document .user_msr.
		* testsuite/gas/i386/i386.exp: Run USER_MSR tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/user_msr-inval.l: New test.
		* testsuite/gas/i386/user_msr-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-user_msr-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-user_msr-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-user_msr-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-user_msr.d: Ditto.
		* testsuite/gas/i386/x86-64-user_msr.s: Ditto.

	opcodes/ChangeLog:
		* i386-dis.c (struct instr_info): Add a new attribute
		has_skipped_modrm.
		(Gq): New.
		(Rq): Ditto.
		(q_mm_mode): Ditto.
		(Nq): Change mode from q_mode to q_mm_mode.
		(VEX_LEN_TABLE):
		(get_valid_dis386): Add VEX_MAP7 in VEX prefix.
		and handle the map7_f8 for save space.
		(OP_Skip_MODRM): Set has_skipped_modrm.
		(OP_E): Skip codep++ when has skipped modrm byte.
		(OP_R): Support q_mode and q_mm_mode.
		(REG_VEX_MAP7_F8_L_0_W_0): New.
		(PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64): Ditto.
		(X86_64_VEX_MAP7_F8_L_0_W_0_R_0): Ditto.
		(VEX_LEN_MAP7_F8): Ditto.
		(VEX_W_MAP7_F8_L_0): Ditto.
		(MOD_0F38F8): Ditto.
		(PREFIX_0F38F8_M_0): Ditto.
		(PREFIX_0F38F8_M_1_X86_64): Ditto.
		(X86_64_0F38F8_M_1): Ditto.
		(PREFIX_0F38F8): Remove.
		(prefix_table): Add PREFIX_0F38F8_M_1_X86_64.
		Remove PREFIX_0F38F8.
		(reg_table): Add REG_VEX_MAP7_F8_L_0_W_0,
		PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64.
		(x86_64_table): Add X86_64_0F38F8_PREFIX_3_M_1,
		X86_64_VEX_MAP7_F8_L_0_W_0_R_0 and X86_64_0F38F8_M_1.
		(vex_table): Add VEX_MAP7.
		(vex_len_table): Add VEX_LEN_MAP7_F8,
		VEX_W_MAP7_F8_L_0.
		(mod_table): New entry for USER_MSR and
		add MOD_0F38F8.
		* i386-gen.c (cpu_flag_init): Add CPU_USER_MSR_FLAGS and
		CPU_ANY_USER_MSR_FLAGS. Add add VEXMAP7.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (SPACE_VEXMAP7): New.
		(CPU_USER_MSR_FLAGS): Ditoo.
		(CPU_ANY_USER_MSR_FLAGS): Ditto.
		(i386_cpu_flags): Add cpuuser_msr.
		* i386-opc.tbl: Add USER_MSR instructions.
		* i386-tbl.h: Regenerated.

2023-10-31  Tom Tromey  <tom@tromey.com>

	Remove some frame invalidation code
	I stumbled across a few spots that mention that a function
	"invalidates frame" and also assignments of NULL to a frame_info_ptr.
	This code isn't harmful, but is also unnecessary since the
	introduction of frame_info_ptr -- nowadays frame invalidations are
	handled automatically.

	Regression tested on x86-64 Fedora 38.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-30  Nick Clifton  <nickc@redhat.com>

	New Georgian translation for the ld sub-directory

2023-10-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: bpf: new test for MOV with C-like numbers ll suffix
	The BPF pseudo-c syntax supports both MOV and LDDW instructions:

	    mov:  r1 = EXPR
	    lddw: r1 = EXPR ll

	Note that the white space between EXPR and `ll' is necessary in order
	to avoid ambiguity with the assembler's support for C-like numerical
	suffixes.  This patch adds a new test to the GAS BPF testsuite to make
	sure that instructions like:

	    r1 = 666ll

	are interpreted as `mov %r1,666', not as `lddw %r1,666'.

	This matches clang's assembler behavior.

	2023-10-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like
		suffix `ll' is not interpreted as lddw syntax.
		* testsuite/gas/bpf/alu-pseudoc.d: Update expected results.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.

2023-10-30  Tom Tromey  <tromey@adacore.com>

	Fix fixed-point "return" on ARM
	On a big-endian ARM machine, the "return" command resulted in the
	wrong value being returned when the function had a fixed-point return
	type.  This patch fixes the problem by unpacking and repacking the
	fixed-point type appropriately.

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-10-30  Tom Tromey  <tromey@adacore.com>

	Fix range-type "return" command on ARM
	On big-endian ARM, "return"ing from a function that returned a range
	type did not work.  This patch strips the range type to treat the
	function as though it were returning the underlying type instead.

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-10-30  Tom Tromey  <tromey@adacore.com>

	Fix "finish" for vector types on ARM
	On a big-endian ARM system, "finish" printed the wrong value when
	finishing from a function that returned a vector type.  Similarly,
	calls to a function also resulted in the wrong value being passed.  I
	think both the read- and write-functions here should ignore the
	endian-ness.

	I tested this using the AdaCore internal test suite; the test case
	that caught this is identical to gdb.base/gnu_vector.exp.

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-10-30  Tom Tromey  <tromey@adacore.com>

	Fix "finish" with range types on ARM
	On ARM (I tested big-endian but it may not matter), "finish" can
	sometimes print the wrong result when the return type is a range type.
	Range types should really be treated as their underlying type
	(normally integer, but sometimes fixed-point).  This patch implements
	this.

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-10-30  Tom Tromey  <tromey@adacore.com>

	Fix calls with small integers on ARM
	On big-endian ARM, an inferior call with a small integer will pass the
	wrong value.  This patch fixes the problem.  Because the code here
	works using scalar values, and not just bytes, left-shifting is
	unnecessary.

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-10-30  Nick Clifton  <nickc@redhat.com>

	Accept and ignore the R_BPF_64_NODLYD32 relocation.

2023-10-30  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Update aarch64-sys-regs.def header
	Given the shared use of the aarch64-sys-regs.def file across Binutils
	and GCC, add instructions for keeping the file synchronized across the
	two codebases.

	Namely, it should be made clear that all changes are first to be made
	in Binutils and the updated file copied across to GCC.

	opcodes/ChangeLog

		* opcodes/aarch64-sys-regs.def: Update file-description header
		comment.

2023-10-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-29  Tom Tromey  <tom@tromey.com>

	Move read_addrmap_from_aranges to new file
	In the interest of shrinking dwarf2/read.c a little more, this patch
	moves the code that deciphers .debug_aranges into a new file.

	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

2023-10-29  Tom Tromey  <tom@tromey.com>

	Pre-read .debug_aranges section
	While working on background DWARF reading, I found a race case that I
	tracked down to the handling of the .debug_aranges section.  Currently
	the section data is only read in after the CUs have all been created.
	However, there's no real reason to do this -- it seems fine to read it
	a little earlier, when all the other necessary sections are read in.

	This patch makes this change, and updates the
	read_addrmap_from_aranges API to assert that the section is read in.

	This patch slightly changes the read_addrmap_from_aranges API as well,
	to reject an empty section.  This seems better to me than what the
	current code does, which is try to read an empty section but then do
	no work.

	Regression tested on x86-64 Fedora 38.

	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

2023-10-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-28  Lancelot Six  <lancelot.six@amd.com>

	gdb/gdbsupport/gdbserver: Require c++17
	This patch proposes to require a C++17 compiler to build gdb /
	gdbsupport / gdbserver.  Before this patch, GDB required a C++11
	compiler.

	The general policy regarding bumping C++ language requirement in GDB (as
	stated in [1]) is:

	    Our general policy is to wait until the oldest compiler that
	    supports C++NN is at least 3 years old.

	    Rationale: We want to ensure reasonably widespread compiler
	    availability, to lower barrier of entry to GDB contributions, and to
	    make it easy for users to easily build new GDB on currently
	    supported stable distributions themselves. 3 years should be
	    sufficient for latest stable releases of distributions to include a
	    compiler for the standard, and/or for new compilers to appear as
	    easily installable optional packages. Requiring everyone to build a
	    compiler first before building GDB, which would happen if we
	    required a too-new compiler, would cause too much inconvenience.

	    See the policy proposal and discussion
	    [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).

	The first GCC release which with full C++17 support is GCC-9[2],
	released in 2019[3], which is over 4 years ago.  Clang has had C++17
	support since Clang-5[4] released in 2018[5].

	A discussions with many distros showed that a C++17-able compiler is
	always available, meaning that this no hard requirement preventing us to
	require it going forward.

	[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
	[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
	[3] https://gcc.gnu.org/gcc-9/
	[4] https://clang.llvm.org/cxx_status.html
	[5] https://releases.llvm.org/

	Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-10-28  Lancelot Six  <lancelot.six@amd.com>

	gdb/ax_cxx_compile_stdcxx.m4: upgrade
	This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes
	available in [1] and regenerates the configure script.

	[1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

	Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-10-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: tc-bpf.c: fix formatting of comment

	opcodes: bpf-dis.c: fix typo in comment

2023-10-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb: trim trailing spaces in i386-tdep.{c,h}
	Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df

2023-10-27  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Clarify the behaviors of SET/ADD/SUB relocations.
	We are used to generate these kinds of relocations by data directives.
	Considering the following example,
	.word (A + 3) - (B + 2)
	The GAS will generate a pair of ADD/SUB for this,
	R_RISCV_ADD, A + 1
	R_RISCV_SUB, 0

	The addend of R_RISCV_SUB will always be zero, and the summary of the
	constants will be stored in the addend of R_RISCV_ADD/SET.  Therefore,
	we can always add the addend of these data relocations when doing relocations.

	But unfortunately, I had heard that if we are using .reloc to generate
	the data relocations will make the relocations failed.  Refer to this,
	.reloc offset, R_RISCV_ADD32, A + 3
	.reloc offset, R_RISCV_SUB32, B + 2
	.word 0
	Then we can get the relocations as follows,
	R_RISCV_ADD, A + 3
	R_RISCV_SUB, B + 2
	Then...  Current LD does the relocation, B - A + 3 + 2, which is wrong
	obviously...

	So first of all, this patch fixes the wrong relocation behavior of
	R_RISCV_SUB* relocations.

	Afterwards, considering the uleb128 direcitve, we will get a pair of
	SET_ULEB128/SUB_ULEB128 relocations for it for now,
	.uleb128 (A + 3) - (B + 2)
	R_RISCV_SET_ULEB128, A + 1
	R_RISCV_SUB_ULEB128, B + 1

	Which looks also wrong obviously, the summary of the constants should only
	be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should
	be zero like other SUB relocations.  But the current LD will still get the right
	relocation values since we only add the addend of SUB_ULEB128 by accident...
	Anyway, this patch also fixes the behaviors above, to make sure that no matter
	using .uleb128 or .reloc directives, we should always get the right values.

	bfd/
		* elfnn-riscv.c (perform_relocation):  Clarify that SUB relocations
		should substract the addend, rather than add.
		(riscv_elf_relocate_section): Since SET_ULEB128 won't go into
		perform_relocation, we should add it's addend here in advance.
	gas/
		* config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of
		SUB_ULEB128 to zero since it should already be added into the addend
		of SET_ULEB128.

2023-10-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-26  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: Add new gdb.Value.bytes attribute
	Add a gdb.Value.bytes attribute.  This attribute contains the bytes of
	the value (assuming the complete bytes of the value are available).

	If the bytes of the gdb.Value are not available then accessing this
	attribute raises an exception.

	The bytes object returned from gdb.Value.bytes is cached within GDB so
	that the same bytes object is returned each time.  The bytes object is
	created on-demand though to reduce unnecessary work.

	For some values we can of course obtain the same information by
	reading inferior memory based on gdb.Value.address and
	gdb.Value.type.sizeof, however, not every value is in memory, so we
	don't always have an address.

	The gdb.Value.bytes attribute will convert any value to a bytes
	object, so long as the contents are available.  The value can be one
	created purely in Python code, the value could be in a register,
	or (of course) the value could be in memory.

	The Value.bytes attribute can also be assigned too.  Assigning to this
	attribute is similar to calling Value.assign, the value of the
	underlying value is updated within the inferior.  The value assigned
	to Value.bytes must be a buffer which contains exactly the correct
	number of bytes (i.e. unlike value creation, we don't allow oversized
	buffers).

	To support this assignment like behaviour I've factored out the core
	of valpy_assign.  I've also updated convert_buffer_and_type_to_value
	so that it can (for my use case) check the exact buffer length.

	The restrictions for when the Value.bytes can or cannot be written too
	are exactly the same as for Value.assign.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13267

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-26  Andrew Burgess  <aburgess@redhat.com>

	gdb: handle main thread exiting during detach
	Overview
	========

	Consider the following situation, GDB is in non-stop mode, the main
	thread is running while a second thread is stopped.  The user has the
	second thread selected as the current thread and asks GDB to detach.
	At the exact moment of detach the main thread exits.

	This situation currently causes crashes, assertion failures, and
	unexpected errors to be reported from GDB for both native and remote
	targets.

	This commit addresses this situation for native and remote targets.
	There are a number of different fixes, but all are required in order
	to get this functionality working correct for native and remote
	targets.

	Native Linux Target
	===================

	For the native Linux target, detaching is handled in the function
	linux_nat_target::detach.  In here we call stop_wait_callback for each
	thread, and it is this callback that will spot that the main thread
	has exited.

	GDB then detaches from everything except the main thread by calling
	detach_callback.

	After this the first problem is this assert:

	  /* Only the initial process should be left right now.  */
	  gdb_assert (num_lwps (pid) == 1);

	The num_lwps call will return 0 as the main thread has exited and all
	of the other threads have now been detached.  I fix this by changing
	the assert to allow for 0 or 1 lwps at this point.  As the 0 case can
	only happen in non-stop mode, the assert becomes:

	  gdb_assert (num_lwps (pid) == 1
		      || (target_is_non_stop_p () && num_lwps (pid) == 0));

	The next problem is that we do:

	  main_lwp = find_lwp_pid (ptid_t (pid));

	and then proceed assuming that main_lwp is not nullptr.  In the case
	that the main thread has exited though, main_lwp will be nullptr.

	However, we only need main_lwp so that GDB can detach from the
	thread.  If the main thread has exited, and GDB has already detached
	from every other thread, then GDB has finished detaching, GDB can skip
	the calls that try to detach from the main thread, and then tell the
	user that the detach was a success.

	For Remote Targets
	==================

	On remote targets there are two problems.

	First is that when the exit occurs during the early phase of the
	detach, we see the stop notification arrive while GDB is removing the
	breakpoints ahead of the detach.  The 'set debug remote on' trace
	looks like this:

	  [remote] Sending packet: $z0,7f1648fe0241,1#35
	  [remote]   Notification received: Stop:W0;process:2a0ac8
	  # At this point an unpatched gdbserver segfaults, and the connection
	  # is broken.  A patched gdbserver continues as below...
	  [remote] Packet received: E01
	  [remote] Sending packet: $z0,7f1648ff00a8,1#68
	  [remote] Packet received: E01
	  [remote] Sending packet: $z0,7f1648ff132f,1#6b
	  [remote] Packet received: E01
	  [remote] Sending packet: $D;2a0ac8#3e
	  [remote] Packet received: E01

	I was originally running into Segmentation Faults, from within
	gdbserver/mem-break.cc, in the function find_gdb_breakpoint.  This
	function calls current_process() and then dereferences the result to
	find the breakpoint list.

	However, in our case, the current process has already exited, and so
	the current_process() call returns nullptr.  At the point of failure,
	the gdbserver backtrace looks like this:

	  #0  0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982
	  #1  0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093
	  #2  0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372
	  #3  0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498
	  ...

	The problem is that, as a result non-stop being on, the process
	exiting is only reported back to GDB after the request to remove a
	breakpoint has been sent.  Clearly gdbserver can't actually remove
	this breakpoint -- the process has already exited -- so I think the
	best solution is for gdbserver just to report an error, which is what
	I've done.

	The second problem I ran into was on the gdb side, as the process has
	already exited, but GDB has not yet acknowledged the exit event, the
	detach -- the 'D' packet in the above trace -- fails.  This was being
	reported to the user with a 'Can't detach process' error.  As the test
	actually calls detach from Python code, this error was then becoming a
	Python exception.

	Though clearly the detach has returned an error, and so, maybe, having
	GDB throw an error would be fine, I think in this case, there's a good
	argument that the remote error can be ignored -- if GDB tries to
	detach and gets back an error, and if there's a pending exit event for
	the pid we tried to detach, then just ignore the error and pretend the
	detach worked fine.

	We could possibly check for a pending exit event before sending the
	detach packet, however, I believe that it might be possible (in
	non-stop mode) for the stop notification to arrive after the detach is
	sent, but before gdbserver has started processing the detach.  In this
	case we would still need to check for pending stop events after seeing
	the detach fail, so I figure there's no point having two checks -- we
	just send the detach request, and if it fails, check to see if the
	process has already exited.

	Testing
	=======

	In order to test this issue I needed to ensure that the exit event
	arrives at the same time as the detach call.  The window of
	opportunity for getting the exit to arrive is so small I've never
	managed to trigger this in real use -- I originally spotted this issue
	while working on another patch, which did manage to trigger this
	issue.

	However, if we trigger both the exit and the detach from a single
	Python function then we never return to GDB's event loop, as such GDB
	never processes the exit event, and so the first time GDB gets a
	chance to see the exit is during the detach call.  And so that is the
	approach I've taken for testing this patch.

	Tested-By: Kevin Buettner <kevinb@redhat.com>
	Approved-By: Kevin Buettner <kevinb@redhat.com>

2023-10-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.exp
	If we make writing an index-cache entry very slow by doing this in
	index_cache::store:
	...
	   try
	     {
	+      sleep (15);
	       index_cache_debug ("writing index cache for objfile %s",
	 			 bfd_get_filename (per_bfd->obfd));
	...
	we run into:
	...
	FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
	  couldn't remove files in temporary cache dir
	...

	The FAIL happens because there is no index-cache entry in the cache dir.

	The problem is that gdb is killed (by gdb_exit) before the index-cache entry
	is written.

	Fix this by using "maint wait-for-index-cache".

	Tested on x86_64-linux.

	PR testsuite/30528
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528

2023-10-26  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itself
	GCC doesn't complain, but it's still wrong.

2023-10-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-25  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.exp
	Clang doesn't use CFA information for variable locations. This makes it
	so software breakpoints get a false hit when rbp gets popped, causing
	a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with
	GDB itself, add an xfail to reduce noise.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-25  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix running gdb.python/py-explore-cc with clang
	The test gdb.python/py-explore-cc.exp was showing one unexpected
	failure. This was due to how clang mapped instructions to lines,
	resulting in the inferior seemingly stopping at a different location.

	This patch adds a nop line in the relevant location so we don't need to
	add XFAILs for existing clang releases, if this gets solved in future
	versions.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-25  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: don't leak program name in handle_v_run
	I noticed that in handle_v_run (gdbserver/server.cc) we leak
	new_program_name (a string) each time GDB starts an inferior, in the
	case where GDB passes a program name to gdbserver.

	This bug was introduced with this commit:

	  commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c
	  Date:   Wed Apr 13 17:31:02 2022 -0400

	      gdbsupport: make gdb_abspath return an std::string

	When gdbserver receives a program name from GDB, this is first placed
	into a malloc'd buffer within handle_v_run, and this buffer is then
	used in this call:

	  program_path.set (new_program_name);

	Prior to the above commit this call took ownership of the buffer
	passed to it, but now this call uses the buffer to initialise a
	std::string, which copies the buffer contents, leaving ownership with
	the caller.  So now, after this call (in handle_v_run)
	new_program_name still owns a buffer.

	At no point in handle_v_run do we free new_program_name, as a result
	we are leaking the program name each time GDB starts a remote
	inferior.

	I could solve this by adding a 'free' call into handle_v_run, but I'd
	rather automate the memory management.

	So, to this end, I have added a new function in gdbserver/server.cc,
	decode_v_run_arg.  This function takes care of allocating the memory
	buffer and decoding the vRun packet into the buffer, but returns a
	gdb::unique_xmalloc_ptr<char> (or nullptr on error).

	Back in handle_v_run I have converted new_program_name to also be a
	gdb::unique_xmalloc_ptr<char>.

	Now, after we call program_path.set(), the allocated buffer will be
	automatically released when it is no longer needed.

	It is worth highlighting that within the new decode_v_run_arg
	function, I have wrapped the call to hex2bin in a try/catch block.
	The hex2bin function can throw an exception if it encounters an
	invalid (non-hex) character.  Back in handle_v_run, we have a local
	argument new_argv, which is of type std::vector<char *>.  Each
	'char *' in this vector is a malloc'd buffer.  If we allow
	hex2bin to throw an exception and don't catch it in either
	decode_v_run_arg or handle_v_run then we are going to leak memory from
	new_argv.

	I chose to catch the exception in decode_v_run_arg, this seemed
	cleanest, but I'm not sure it really matters, so long as the exception
	is caught before we leave handle_v_run.  I am working on a patch that
	changes new_argv to automatically manage its memory, but that isn't
	ready for posting yet.  I think what I have here would be fine if my
	follow on patch never arrives.

	Additionally, within the handle_v_run loop I have changed an
	assignment of nullptr to new_program_name into an assert.  Previously,
	the assignment could only trigger on the first iteration of the loop,
	if we had no new program name to assign.  However, new_program_name
	always starts as nullptr, so, on the first loop iteration, if we have
	nothing to assign to new_program_name, its value must already be
	nullptr.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make get_symbol_address a private method of symbol
	get_symbol_address is only used symbol::value_address, make it a private
	helper method.

	Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make get_msymbol_address a private method of minimal_symbol
	get_msymbol_address is only used in minimal_symbol::value_address.  Make
	it a private helper method.

	Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Fix -Wformat= warnings
	Added format attribute to several gprofng functions.
	Fixed -Wformat= warnings.

	gprofng/ChangeLog
	2023-10-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* libcollector/heaptrace.c: Fixed -Wformat= warnings.
		* libcollector/hwprofile.c: Likewise.
		* libcollector/iolib.c: Likewise.
		* libcollector/iotrace.c: Likewise.
		* libcollector/jprofile.c: Likewise.
		* libcollector/profile.c: Likewise.
		* libcollector/synctrace.c: Likewise.
		* src/ClassFile.cc: Likewise.
		* src/SourceFile.cc: Likewise.
		* libcollector/libcol_util.h: Added format attribute.
		* src/Emsg.h: Likewise.
		* src/collector_module.h: Likewise.
		* src/data_pckts.h: Define fld_sizeof.

2023-10-25  Alan Modra  <amodra@gmail.com>

	asan: _bfd_elf_slurp_version_tables memory leak
	Extends commit 6136093c0d00 to handle verdefs as well as verrefs.

		PR 30886
		* elf.c (_bfd_elf_slurp_version_tables): See free_contents for
		verdefs too.  Use free_contents rather than elf_tdata fields.

2023-10-25  Alan Modra  <amodra@gmail.com>

	asan: out of memory in som_set_reloc_info
	Sections without SEC_HAS_CONTENTS avoid the file size checks, and of
	course it doesn't make sense to read such as the contents are all
	zero.

		* som.c (som_set_reloc_info): Don't read sections without contents.

2023-10-25  Alan Modra  <amodra@gmail.com>

	asan: NULL deref in alpha_ecoff_get_relocated_section_contents
	This fixes some holes found by fuzzers, and removes aborts that can be
	triggered by user input to objdump.  Abort should only be used within
	bfd to show programming errors in bfd.

		* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle
		NULL howto.  Don't abort on stack errors or on unexpected relocs.
		Show more bfd reloc status messages.

2023-10-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-24  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Add gnu-source-highlight selftest
	Add a selftest gnu-source-highlight:
	...
	$ gdb -q -batch -ex "maint selftest gnu-source-highlight"
	Running selftest gnu-source-highlight.
	Ran 1 unit tests, 0 failed
	...

	Tested on x86_64-linux.

2023-10-24  Tom de Vries  <tdevries@suse.de>

	[readelf] Handle unknown name of main in .gdb_index section
	When compiling hello world and adding a v9 .gdb-index section:
	...
	$ gcc -g hello.c
	$ gdb-add-index a.out
	...
	readelf shows it as:
	...
	Shortcut table:
	Language of main: unknown: 0
	Name of main: ^A
	...

	The documentation of gdb says about the "Name of main" that:
	...
	This value must be ignored if the value for the language of main is zero.
	...

	Implement this approach in display_gdb_index, such that we have instead:
	...
	Shortcut table:
	Language of main: unknown: 0
	Name of main: <unknown>
	...

	Tested on x86_64-linux.

	Approved-By: Jan Beulich <jbeulich@suse.com>

2023-10-24  Lulu Cai  <cailulu@loongson.cn>

	as: fixed internal error when immediate value of relocation overflow.
	The as and ld use _bfd_error_handler to output error messages when
	checking relocation alignment and relocation overflow. However, the
	abfd value passed by as to the function is NULL, resulting in an
	internal error. The ld passes a non-null value to the function,
	so it can output an error message normally.

2023-10-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-23  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Only include gdbsupport/selftest.h if GDB_SELF_TEST
	I noticed that gdb/python/python.c unconditionally includes
	gdbsupport/selftest.h.

	Make this conditional on GDB_SELF_TEST.

	Tested on x86_64-linux.

2023-10-23  Jan Beulich  <jbeulich@suse.com>

	gas: make .nops output visible in listing
	Due to using a different frag type (in turn due to storing data
	differently), making the resulting code appear in listings requires
	special handling.

	x86: fold NOP testcase expectations where possible
	Like done earlier for files needing adjustment anyway, also do this for
	the remaining set.

	x86: fold a few of the "alternative" NOP patterns
	Since named objects may not overlap, the compiler is not permitted to do
	this for us, to avoid wasting space and cache bandwidth/capacity.

2023-10-23  Jan Beulich  <jbeulich@suse.com>

	x86: add a few more NOP patterns
	First of all add f32_5[], allowing to eliminate the extra slot-is-NULL
	code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[]
	following the same concept of adding a %cs segment override prefix.

	Also re-use patterns when possible and correct comments as applicable.
	Similarly re-use testcase expectations as much as possible, where they
	need touching anyway.

2023-10-23  Jan Beulich  <jbeulich@suse.com>

	x86: don't record full i386_cpu_flags in struct i386_tc_frag_data
	We only use a single bit of this ever growing structure.

2023-10-23  Jan Beulich  <jbeulich@suse.com>

	x86: i686 != PentiumPro
	The two are distinct in opcodes/, distinguished precisely by CpuNOP
	that's relevant in i386_generate_nops(), yet the function has the PPro
	case label in the other group. Simply removing it revealed that
	cpu_arch[] had a wrong entry for i686.

	While there also add PROCESSOR_IAMCU to the respective comment.

2023-10-23  Jan Beulich  <jbeulich@suse.com>

	x86: respect ".arch nonop" when selecting which NOPs to emit
	Making GENERIC64 a special case was never correct; prior to the
	generalization of ".arch .no*" to cover all ISA extensions other
	processor families supporting long NOPs should have been covered as
	well. When introducing ".arch .nonops" (among others) it wasn't
	apparent that a hidden implication of .cpunop not being possible to
	separately turn off existed here. Seeing that the two large case label
	blocks in the 2nd switch() already had identical behavior, simply
	collapse all of the (useful) case labels into a single "default" one.

	x86: don't use operand size override with NOP in 16-bit code
	Since we don't key the NOP selection to user-controlled properties, we
	may not use i386 features; otherwise we would violate a possible .arch
	directive restricting ISA to pre-386.

	x86: don't use 32-bit LEA as NOP surrogate in 64-bit code
	Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi
	(by zero-extending %esi to %rsi). Introduce separate 64-bit patterns
	which keep %rsi intact.

	x86: i386_generate_nops() may not derive decisions from global variables
	What matters is what was in effect at the time the original directive
	was issued. Later changes to global state (bitness or ISA) must not
	affect what code is generated.

	x86: record flag_code in tc_frag_data
	The recorded value, and not the global variable, will want using in
	TC_FRAG_INIT(). The so far file scope variable therefore needs to become
	external, to be accessible there.

2023-10-23  Clément Chigot  <chigot@adacore.com>

	objcopy: fix typo in --heap and --stack parser
	The help says that <reserve> and <commit> should be separated by a ","
	but the implementation is checking for ".". Having two numbers being
	separated by a "." could be confusing, thus adjust the implementation to
	match the help syntax.

	binutils/ChangeLog:

		* objcopy.c (copy_main): Set separator to "," between <reserve>
		and <commit> for --heap and --stack.
		* doc/binutils.texi: Add <commit> for --heap and --stack.

2023-10-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-23  Alan Modra  <amodra@gmail.com>

	bfd-in2.h BFD_RELOC_* comments
	I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't
	match that committed to bfd-in2.h, and was just going to regen
	bfd-in2.h but then decided to do something about the silly formatting
	of these comments in bfd-in2.h.  eg. the BFD_RELOC_MICROBLAZE_32_NONE
	comment:

	-/* This is a 32 bit reloc that stores the 32 bit pc relative
	-value in two words (with an imm instruction).No relocation is
	-done here - only used for relaxing  */
	+  /* This is a 32 bit reloc that stores the 32 bit pc relative value in
	+     two words (with an imm instruction).  No relocation is done here -
	+     only used for relaxing.  */
	   BFD_RELOC_MICROBLAZE_32_NONE,

	You'll notice how the second and third line of the original comment
	aren't indented properly relative to the first line, and the whole
	comment needs to be indented to match the code.

	I've also edited reloc.c ENUMDOC paragraphs.  Some of these had excess
	indentation, presumably in an attempt to properly indent bfd-in2.h
	comments but that fails due to chew.c removing leading whitespace
	early by skip_white_and_stars.  COMMENT was used in reloc.c to add
	extra blank lines in bfd-in2.h.  I've removed them too as I don't
	think they add anything to readability of that file.  (Perhaps more
	usefully, they also add blank lines to libbfd.h separating relocs for
	one target from others, but this isn't done consistently.)

		* doc/chew.c (drop, idrop): Move earlier.
		(strip_trailing_newlines): Check index before accessing array,
		not after.
		(wrap_comment): New function.
		(main): Add "wrap_comment" intrinsic.
		* doc/proto.str (ENUMDOC): Use wrap_comment.
		(make_enum_header, ENDSENUM): Put start and end braces on
		separate lines.
		* reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs.
		* libbfd.h: Regenerate.
		* bfd-in2.h: Regenerate.

2023-10-22  Tom Tromey  <tom@tromey.com>

	Style history variable output
	When printing a value, I think the history reference -- the "$1" in
	the output -- should be styled using the "variable" style.  This patch
	implements this.

2023-10-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix owner passed to remove_target_sections in clear_solib
	Commit 8971d2788e7 ("gdb: link so_list using intrusive_list") introduced
	a bug in clear_solib.  Instead of passing an `so_list *` to
	remove_target_sections, it passed an `so_list **`.  This was not caught
	by the compiler, because remove_target_sections takes a `void *` as the
	"owner", so you can pass it any pointer and it won't complain.

	This happened because I previously had a patch to change the type of the
	disposer parameter to be a reference rather than a pointer, so had to
	change `so` to `&so`.  When dropping that patch, I forgot to revert this
	bit and / or it got re-introduced when handling subsequent merge
	conflicts.  And I didn't properly retest.

	Fix that, but try to make things less error prone.  Add a union to
	represent the possible owner kinds for a target_section.  Trying to pass
	a pointer to another type than those will not compile.

	Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c

2023-10-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-20  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Allow source-highlight to autodetect language
	Currently when gdb asks the source-highlight library to highlight a file, it
	tells it what language file to use.

	For instance, if gdb learns from the debug info that the file is language_c,
	the language file "c.lang" is used.  This mapping is hardcoded in
	get_language_name.

	However, if gdb doesn't know what language file to use, it falls back to using
	python pygments, and in absence of that, unhighlighted source text.

	In the case of python pygments, it autodetects which language to use based on
	the file name.

	Add the same capability when using the source-highlight library.

	Tested on x86_64-linux.

	Verified that it works by:
	- making get_language_name return nullptr for language_c, and
	- checking that source-highlight still manages to highlight a hello world.

	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

	PR cli/30966
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966

2023-10-20  Tom Tromey  <tom@tromey.com>

	Don't include cooked-index.h from dwarf2/read.h
	dwarf2/read.h includes cooked-index.h, but it doesn't need to.  This
	patch removes the inclusion from this header, and adds one to
	index-write.c to make up for the absence.

2023-10-20  Neal Frager  <neal.frager@amd.com>

	gas: testsuite: microblaze: cosmetic fix
	This patch makes a cosmetic change to the reloc_weaksym.s
	by making the bneid instruction all lower case like all of
	the other instructions in the example.

2023-10-20  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix creation-time parent/child dict confusions
	The fixes applied a few years ago to resolve confusions between parent and
	child dicts at lookup time also apply in various forms to creation.  In
	general, if you have a type in a parent dict ctf_imported into a child and
	you do something to it, and the parent dict is writable (created via
	ctf_create, not opened via ctf_open*) it should work just the same to make
	changes to that type via a child dict as it does to make the change
	to the parent dict directly -- and nothing you're prohibited from doing
	to the parent dict when done directly should be allowed just because
	you're doing it via a child.

	Specifically, the following don't work when doing things from the child, but
	should:

	 - adding a member of a type in the parent to a struct or union in the
	   parent via ctf_add_member or ctf_add_member_offset: this yields
	   ECTF_BADID

	 - adding a member of a type in the parent to a struct or union in the
	   parent via ctf_add_member_encoded: this dumps core (!).

	 - adding an enumerand to an enumerator in the parent: this yields
	   ECTF_BADID

	 - setting the properties of an array in the parent via ctf_set_array;
	   this yields ECTF_BADID

	Relatedly, some things work when doing things via a child that should fail,
	yielding a CTF dictionary with invalid content (readable, but meaningless):
	in particular, you can add a child type to a struct in the parent via
	any of the ctf_add_member* family and nothing complains at all, even though
	you should never be able to add references to children to parents (since any
	given parent can be associated with many different children).

	A family of tests is added to check each of these cases independently, since
	some can result in coredumps and it would be nice to test the other cases
	even if some dump core.  They use a common library to do all the actual
	work.  The set of affected API calls was determined by code inspection
	(auditing all calls to ctf_dtd_lookup): it's possible that I missed a few,
	but I doubt it, since other cases use ctf_lookup* functions, which already
	climb to the parent where appropriate.

	libctf/ChangeLog:

		PR libctf/30985
		* ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary.
		(ctf_set_array): Likewise.  Report errors on the child; require
		both parent and child to be writable.
		(ctf_add_enumerator): Likewise.
		(ctf_add_member_offset): Likewise.  Prohibit addition of child types
		to structs in the parent.
		(ctf_add_member_encoded): Do not dereference a NULL dtd: report
		ECTF_BADID instead.
		* ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the
		dict if addition of a string ref fails.
		* testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library.
		* testsuite/libctf-writable/parent-child-dtd-enum.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-set-array.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-struct.*: New test.
		* testsuite/libctf-writable/parent-child-dtd-union.*: New test.

2023-10-20  Neal Frager  <neal.frager@amd.com>

	bfd: microblaze: Add 32_NONE reloc type
	This patch adds the R_MICROBLAZE_32_NONE relocation type.
	This is a 32-bit reloc that stores the 32-bit pc relative
	value in two words (with an imm instruction).

	Add test case to gas test suite.

2023-10-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix more style issues in v9 .gdb_index section support
	I noticed a few more style issues in commit 8b9c08eddac ("[gdb/symtab] Add
	name_of_main and language_of_main to the DWARF index"), after checking it
	with gcc's check_GNU_style.{sh,py}.

	Fix these.

	Build on x86_64-linux.

2023-10-20  Neal Frager  <neal.frager@amd.com>

	opcodes: microblaze: Fix bit masking bug
	There is currently a bug in the bit masking for the barrel shift
	instructions because the bit mask is not including all of the
	register bits which must be zero.  With this patch, the disassembler
	can be sure that the 32-bit value is indeed a barrel shift instruction
	and not a data value in memory.

	This fix can be verified by assembling and disassembling the following:

		.text
		.long 0x65005f5f

	With this patch, the bug is fixed, and the objdump will know that
	0x65005f5f is not a barrel shift instruction.

2023-10-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-19  Tom Tromey  <tom@tromey.com>

	Fix race in DWARF reader
	The recent change to record the DWARF language in the per-CU data
	yielded a race warning in my testing:

	ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit

	This patch fixes the bug by applying the same style of fix that was
	done for the ordinary (gdb) language.

	I wonder if this code could be improved.  Requiring an atomic for the
	language in particular seems unfortunate, as it is often consulted
	during index finalization.  However, I haven't investigated this.

	Regression tested on x86-64 Fedora 38.

	Reviewed-by: Tom de Vries <tdevries@suse.de>

2023-10-19  Alan Modra  <amodra@gmail.com>

	PR30984, assertion fail elf.c:8485
		PR 30984
		* ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as
		a potential output section.

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix no-expat build of solib-target.c
	Fixes:

	      CXX    solib-target.o
	    /home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type
	       57 | static lm_info_vector
	          |        ^~~~~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’:
	    /home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope
	      244 |     = solib_target_parse_libraries (library_document->data ());
	          |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

	Change-Id: Ib477d3343b401017d79729118242143bc95f24b2

2023-10-19  Jose E. Marchesi  <jose.marchesi@oracle.com>

	ld: fix typo in ld.texi metdata->metadata

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename struct so_list to shobj
	Now that so_list lists are implemented using intrusive_list, it doesn't
	really make sense for the element type to be named "_list".  Rename to
	just `struct shobj` (`struct so` was deemed to be not greppable enough).

	Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove free_so function
	Remove this function, replace it with deleting the so_list in callers.

	Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: don't call so_list::clear in free_so
	I think this `so.clear ()` call is not useful.

	 - so_list::clear deletes some things that now get automatically deleted
	   when the so_list gets deleted right after in free_so.
	 - so_list::clear resets some scalar fields of so_list, which we don't
	   really care about since the so_list gets deleted right after.
	 - so_list::clear calls target_so_ops::clear_so, of which there is a
	   single implementation, svr4_clear_so.  That implementation just
	   resets a field in lm_info_svr4, which we don't care about, as it will
	   get deleted when the so_list gets deleted right after.

	Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: link so_list using intrusive_list
	Replace the hand-made linked list implementation with intrusive_list,
	simplying management of list items.

	Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make so_list::{so_original_name,so_name} std::strings
	Change these two fields, simplifying memory management and copying.

	Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make so_list::abfd a gdb_bfd_ref_ptr
	Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically
	manage the reference.

	Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make so_list::sections not a pointer
	Make the field a vector directly, instead of a pointer to a vector.
	This was needed when so_list had to be a trivial type, which is not the
	case anymore.

	Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove target_section_table typedef
	Remove this typedef.  I think that hiding the real type (std::vector)
	behind a typedef just hinders readability.

	Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make clear_so a method of struct so_list
	... just because it seems to make sense to do so.

	Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make so_list::lm_info a unique_ptr
	Make it a unique_ptr, so it gets automatically deleted when the so_list
	is deleted.

	Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove lm_info_vector typedef
	I think this typedef hinders readability.  First, it's not well named
	(it's not clear it contains lm_info_target objects).  And hiding the
	fact that it contains unique pointers is not very useful either.  I was
	looking at the code in solib_target_current_sos where the unique
	pointers get moved from the vector, and it wasn't obvious at all what
	the source of the move was.

	Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make solib-rocm not use so_list internally
	Same rationale as the previous patch, but for solib-rocm.

	 - Introduce rocm_so, which is a name a unique_name (see comment in
	   rocm_update_solib_list for that) and a unique_ptr to the
	   lm_info_svr4.
	 - Change the internal lists from so_list lists to vectors of rocm_so.
	 - Remove rocm_free_solib_list, as everything is automatic now.
	 - Replace rocm_solib_copy_list with so_list_from_rocm_sos.

	Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make solib-svr4 not use so_list internally
	A subsequent patch makes use of non-trivial types in struct so_list.
	This trips on the fact that svr4_copy_library_list uses memcpy to copy
	so_list objects:

	      so_list *newobj = new so_list;
	      memcpy (newobj, src, sizeof (struct so_list));

	solib-svr4 maintains lists of so_list objects in its own internal data
	structures.  When requested to return a list of so_list objects (through
	target_so_ops::current_sos), it duplicates the internal so_list lists,
	using memcpy.  When changing so_list to make it non-trivial, we would
	need to replace this use of memcpy somehow.  That would mean making
	so_list copyable, with all the complexity that entails, just to satisfy
	this internal usage of solib-svr4 (and solib-rocm, which does the same).

	Change solib-svr4 to use its own data type for its internal lists.  The
	use of so_list is a bit overkill anyway, as most fields of so_list are
	irrelevant for this internal use.

	 - Introduce svr4_so, which contains just an std::string for the name
	   and a unique_ptr for the lm_info.
	 - Change the internal so_list lists to be std::vector<svr4_so>.  Vector
	   seems like a good choice for this, we don't need to insert/remove
	   elements in the middle of these internal lists.
	 - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
	   everything is managed automatically now.
	 - Replace svr4_copy_library_list (which duplicated internal lists in
	   order to return them to the core) with so_list_from_svr4_sos, which
	   creates an so_list list from a vector of svr4_so.
	 - Generalize svr4_same a bit, because find_debug_base_for_solib now
	   needs to compare an so_list and an svr4_so to see if they are the
	   same.

	Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use gdb::checked_static_cast when casting lm_info
	Now that the lm_info class hierarchy has a virtual destructor and
	therefore a vtable, use checked_static_cast instead of C-style cases to
	ensure (when building in dev mode) that we're casting to the right kind
	of lm_info.

	Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove target_so_ops::free_so
	target_so_ops::free_so is responsible for freeing the specific lm_info
	object.  All implementations basically just call delete.  Remove that
	method, make the destructor of lm_info virtual, and call delete directly
	from the free_so function.  Make the sub-classes final, just because
	it's good practice.

	Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: rename lm_info_base to lm_info
	The base class doesn't need to have "_base" in its name, all the
	sub-classes have a specific suffix.

	Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: allocate so_list with new, deallocate with delete
	Initialize all fields in the class declaration, change allocations to
	use "new", change deallocations to use "delete".  This is needed by a
	subsequent patches that use C++ stuff in so_list.

	Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make get_cbfd_soname_build_id static
	It is only used in solib.c.

	Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: use "reference" and "pointer" type aliases in intrusive_list
	It seems to me like the code should used the defined type aliases, for
	consistency.

	Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: replace some so_list parameters to use references
	A subsequent patch changes so_list to be linked using
	intrusive_list.  Iterating an intrusive_list yields some references to
	the list elements.  Convert some functions accepting so_list objects to
	take references, to make things easier and more natural.  Add const
	where possible and convenient.

	Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make interps_notify work with references
	A subsequent patch changes the interp::on_solib_loaded and
	interp::on_solib_unloaded methods to take references.  This highlighted
	that interps_notify did not work with reference parameters.

	Fix that by changing interps_notify's `args` arg to be a universal
	reference (&&).  Change the type of the method to be auto-deduced as an
	additional template parameter, otherwise the signature of the callback
	function would never match:

	      CXX    interps.o
	    /home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’:
	    /home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’
	      378 |   interps_notify (&interp::on_signal_received, sig);
	          |   ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	    /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’
	      363 | interps_notify (void (interp::*method) (Args...), Args&&... args)
	          | ^~~~~~~~~~~~~~
	    /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note:   template argument deduction/substitution failed:
	    /home/simark/src/binutils-gdb/gdb/interps.c:378:18: note:   inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’
	      378 |   interps_notify (&interp::on_signal_received, sig);
	          |   ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to target_so_ops::clear_solib
	The clear_solib is implicitly meant to clear the resources associated to
	the current program space (that's what the solib implementations that
	actually support multi-program-space / multi-inferior do).  Make that
	explicit by adding a program_space parameter and pass down
	current_program_space in call sites.  The implementation of the
	clear_solib callbacks is fairly simple, I don't think any of them rely
	on global state other than accessing current_program_space.

	Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove empty clear_solib functions
	Make the target_so_ops::clear_solib method optional, remove two empty
	implementations.

	Change-Id: Ifda297d50c74327d337091c58cdb5b3b60382591
	Approved-By: Pedro Alves <pedro@palves.net>
	Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-19  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Don't do undefweak relaxations for the linker_def symbols.
	I get the following truncated errors recently when running riscv-gnu-toolchain
	regressions,

	/scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/libc.a(libc-start.o): in function `elf_irela':
	/scratch/riscv-gnu-toolchain/glibc/csu/../sysdeps/riscv/dl-irel.h:47:(.text+0x88): relocation truncated to fit: R_RISCV_GPREL_I against symbol `__ehdr_start' defined in .note.ABI-tag section in /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/elf/sln

	The linker_def symbols like __ehdr_start that may be undefweak in early stages
	of linking, including relax stage, but are guaranteed to be defined later.
	Therefore, it seems like we shouldn't do the undefweak relaxations for these
	kinds of symbols since they may be defined after relaxations.

	bfd/
		* elfnn-riscv.c (_bfd_riscv_relax_section): Don't do undefweak
		relaxations for the linker_def symbols.

2023-10-19  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Remove semicolons from DECLARE_INSN
	This is for consistency and to prevent possible unnecessary errors due
	to this inconsistency.

	include/ChangeLog:

		* opcode/riscv-opc.h (DECLARE_INSN): Remove semicolons from the
		end of each entry.

2023-10-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-18  Lancelot Six  <lancelot.six@amd.com>

	gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp
	The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
	command, but this is incorrect.  If "continue" is given an argument, it
	sets the ignore count of the breakpoint the thread stopped at.

	For this testcase it does not really matter since the breakpoint is not
	meant to be hit anymore, so whatever the ignore count is won't influence
	the outcome of the test.  It is worth fixing nevertheless.

	Change-Id: I0eb674d5529cdeb9e808b74870a29b6077265737
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-18  Jaydeep Patil  <Jaydeep.Patil@imgtec.com>

	sim/riscv: fix JALR instruction simulation
	Fix 32bit 'jalr rd,ra,imm' integer instruction, where RD was written
	before using it to calculate destination address.

	This commit also improves testutils.inc for riscv; make use of
	pushsection and popsection when adding things to .data, and setup the
	%gp global pointer register within the 'start' macro.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-18  Nick Alcock  <nick.alcock@oracle.com>

	libctf: check for problems with error returns
	We do this as a writable test because the only known-affected platforms
	(with ssize_t longer than unsigned long) use PE, and we do not have support
	for CTF linkage in the PE linker yet.

		PR libctf/30836
		* libctf/testsuite/libctf-writable/libctf-errors.*: New test.

2023-10-18  Lancelot Six  <lancelot.six@amd.com>

	gdb/testsuite/gdb.rocm: Check value returned by hipDeviceSynchronize
	Functions of the hip runtime returning a hipError_t can be marked
	nodiscard depending on the configuration[1] (when compiled with C++17).

	This patch makes sure that we always check the value returned by
	hipDeviceSynchronize and friends, and print an error message when
	appropriate.  This avoid a wall of warnings when running the testsuite
	if the compiler defaults to using C++17.

	It is always a good practice to check the return values anyway.

	[1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218

	Change-Id: I2a819a8ac45f4bcf814efe9a2ff12c6a7ad22f97
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-18  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	libctf: Return CTF_ERR in ctf_type_resolve_unsliced PR 30836
	In commit 998a4f589d68503f79695f180fdf1742eeb0a39d, all but one return
	statement was updated to return the error proper value. This commit
	rectifies that missed return statement.

	libctf/
		ctf-types.c (ctf_type_resolve_unsliced): Return CTF_ERR on error.

2023-10-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/jit-bfd-name.exp
	When running test-case gdb.base/jit-bfd-name.exp, I run into:
	...
	ERROR: tcl error sourcing gdb/testsuite/gdb.base/jit-bfd-name.exp.
	ERROR: can't read "start": no such variable
	...

	The problem is that commit c96ceed9dce ("gdb: include the end address in
	in-memory bfd filenames") introduced a use of variable start, but not a
	definition.

	Fix this by adding the missing definition.

	Tested on x86_64-linux.

2023-10-18  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix two style issues in gdb/dwarf2/index-write.c
	While reviewing gdb/dwarf2/index-write.c I noticed two style issues.

	Fix these.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-18  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix style issues in v9 .gdb_index section support
	Post-commit review pointed out a few style issues in commit 8b9c08eddac
	("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index").

	Fix these.

	Tested on x86_64-linux.

	Reported-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Make sure rv32q conflict won't affect the zfa gas testcases.
	According to the commit 51498ab9abc6, the q extension was no longer allowed
	for rv32 since version 2.2.  Therefore, make sure the version of q is larger
	than 2.2, in case the new extension conflict breaks the toolchain regressions,
	which built with the old -misa-spec.

	gas/
		* testsuite/gas/riscv/zfa-zvfh.d: Set q to v2.2.
		* testsuite/gas/riscv/zfa.d: Likewise.

2023-10-18  caiyinyu  <caiyinyu@loongson.cn>

	LoongArch: Correct comments.

2023-10-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-17  Neal Frager  <neal.frager@amd.com>

	gas: testsuite: microblaze: Add new bit-field tests
	This patch adds new gas tests for the
	microblaze bsefi and bsifi instructions.

2023-10-17  Markus Metzger  <markus.t.metzger@intel.com>

	gdb: include the end address in in-memory bfd filenames
	Commit

	    66984afd29e gdb: include the base address in in-memory bfd filenames

	added the base address to in-memory bfd filenames.  Also add the end
	address to allow dumping the in-memory bfd using the 'dump memory'
	command.

2023-10-17  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	libctf: Sanitize error types for PR 30836
	Made sure there is no implicit conversion between signed and unsigned
	return value for functions setting the ctf_errno value.
	An example of the problem is that in ctf_member_next, the "offset" value
	is either 0L or (ctf_id_t)-1L, but it should have been 0L or -1L.
	The issue was discovered while building a 64 bit ld binary to be
	executed on the Windows platform.
	Example object file that demonstrates the issue is attached in the PR.

	libctf/
		Affected functions adjusted.

	Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>

2023-10-17  Nick Clifton  <nickc@redhat.com>

	Update the documentation of the LINKER_VERSIOn script command to actually mention the name of the command.

2023-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Keep track of styling failures in source_cache
	In source_cache::ensure, keep track of which files failed to be styled, and
	don't attempt to style them again in case the file dropped out of the cache.

	Tested on x86_64-linux.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Factor out try_source_highlight
	Function source_cache::ensure contains some code using the GNU
	source-highlight library.

	The code is a sizable part of the function, and contains conditional
	compilation in a slightly convoluted way:
	...
	       if (!already_styled)
	 #endif /* HAVE_SOURCE_HIGHLIGHT */
	       {
	...

	Fix this by factoring out the code into new function try_source_highlight,
	such that:
	- source_cache::ensure is easier to read, and
	- the conditional compilation is at the level of the function body.

	Tested on x86_64-linux.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-17  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Skip string copy in source_cache::ensure
	In function source_cache::ensure we have:
	...
	 	      std::ostringstream output;
		      ...
		      contents = output.str ();
	...
	The last line causes an unnecessary string copy.

	C++20 allows us to skip it, like this:
	...
		      contents = std::move (output).str ();
	...

	Use the more efficient solution.

	Tested on x86_64-linux.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-10-17  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: readelf -d RELASZ excludes .rela.plt size
	Before, readelf -d RELASZ is the sum of .rela.dyn size and .rela.plt size.
	To consistent with LoongArch lld, RELASZ chang to only the size of .rela.dyn.

2023-10-17  Alan Modra  <amodra@gmail.com>

	asan: Invalid free in alpha_ecoff_get_relocated_section_contents
	This fixes an ancient bug in commit a3a33af390 (which makes me think
	this code has never been used).

		* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Iterate
		through reloc_vector using a temp.

2023-10-17  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Fix typo
	include/ChangeLog:

		* opcode/riscv-opc.h: Fix typo.

2023-10-17  John Baldwin  <jhb@FreeBSD.org>

	nat/x86-cpuid.h: Remove non-x86 fallbacks
	This header is only suitable for use on x86 hosts and is only included
	there, so these fallbacks should not be needed.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-16  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary declarations in target.c
	I found that these local declarations were not needed, remove them.
	Tested by rebuilding.

	Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22

2023-10-16  Tom Tromey  <tromey@adacore.com>

	Have DAP handle non-Value results from 'children'
	A pretty-printer's 'children' method may return values other than a
	gdb.Value -- it may return any value that can be converted to a
	gdb.Value.

	I noticed that this case did not work for DAP.  This patch fixes the
	problem.

2023-10-16  Tom Tromey  <tromey@adacore.com>

	Handle gdb.LazyString in DAP
	Andry pointed out that the DAP code did not properly handle
	gdb.LazyString results from a pretty-printer, yielding:

	    TypeError: Object of type LazyString is not JSON serializable

	This patch fixes the problem, partly with a small patch in varref.py,
	but mainly by implementing tp_str for LazyString.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-10-16  Tom Tromey  <tromey@adacore.com>

	Fix register-setting response from DAP
	Andry noticed that given a DAP setExpression request, where the
	expression to set is a register, DAP will return the wrong value -- it
	will return the old value, not the updated one.

	This happens because gdb.Value.assign (which was recently added for
	DAP) does not update the value.

	In this patch, I chose to have the assign method update the Value
	in-place.  It's also possible to have it return a new value, but this
	didn't seem very useful to me.

2023-10-16  Nick Clifton  <nickc@redhat.com>

	Fix: GNU-ld: ARM: Issues when trying to set target output architecture
	  PR 28910
	  * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set.

	Fix: GNU-ld: ARM: Issues when trying to set target output architecture
	  PR 28910
	  * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option.

2023-10-16  Tom Tromey  <tromey@adacore.com>

	Add DAP scope cache
	Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
	with the same frame would yield different variableReference values in
	the response.

	This patch adds a regression test for this, and adds a scope cache in
	scopes.py, ensuring that multiple identical requests will get the same
	response.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2023-10-16  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Work around PR gas/29517
	When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
	...
	$ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
	Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.

	Temporary breakpoint 1, main () at hello.c:6
	6	  printf ("hello\n");
	Invalid cast.
	...
	while without glibc debuginfo installed we get the expected result:
	...
	$n = 0x7ffff7daa1b1 "aha"
	...
	and likewise with glibc debuginfo generated with gas 2.40.

	The strstr ifunc resolves to __strstr_sse2_unaligned.  The problem is that gas
	generates dwarf that states that the return type is void:
	...
	<1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
	    <3e1e59>   DW_AT_name        : __strstr_sse2_unaligned
	    <3e1e5d>   DW_AT_external    : 1
	    <3e1e5e>   DW_AT_low_pc      : 0xbbd2e
	    <3e1e66>   DW_AT_high_pc     : 0xbc1c3
	...
	while the return type should be a DW_TAG_unspecified_type, as is the case
	with gas 2.40.

	We can still use the workaround of casting to another function type for both
	__strstr_sse2_unaligned:
	...
	(gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
	  ("haha", "ah")
	$n = 0x7ffff7daa211 "aha"
	...
	and strstr (which requires using *strstr to dereference the ifunc before we
	cast):
	...
	gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
	$n = 0x7ffff7daa251 "aha"
	...
	but that's a bit cumbersome to use.

	Work around this in the dwarf reader, such that we have instead:
	...
	(gdb) p (char *)strstr ("haha", "ah")
	$n = 0x7ffff7daa1b1 "aha"
	...

	This also requires fixing producer_is_gcc to stop returning true for
	producer "GNU AS 2.39.0".

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

	PR symtab/30911
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911

2023-10-16  Luis Machado  <luis.machado@arm.com>

	Only allow closure lookup by address if there are threads displaced-stepping
	Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
	displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
	is available whenever we have a match between the provided address argument and
	the buffer address.

	That is fine, but the report in PR30872 shows this assertion triggering when
	it really shouldn't. After some investigation, here's what I found out.

	The 32-bit Arm architecture is the only one that calls
	gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
	32-bit Arm needs to figure out the thumb state of the original instruction
	that we displaced-stepped through the displaced-step buffer.

	Before the assertion was put in place by commit
	1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
	getting nullptr back, which meant we were not doing a displaced-stepping
	operation.

	Now, with the assertion in place, this is running into issues.

	It looks like displaced_step_buffers::copy_insn_closure_by_addr is
	being used to return a couple different answers depending on the
	state we're in:

	1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
	is supposed to return a valid closure for us, so we can determine the
	thumb mode.

	2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
	should return nullptr to signal that there isn't any displaced-step buffers
	in use, because we don't have a valid closure (but we should always have
	this).

	Since the displaced-step buffers are always allocated, but not always used,
	that means the buffers will always contain data. In particular, the buffer
	addr field cannot be used to determine if the buffer is active or not.

	For instance, we cannot set the buffer addr field to 0x0, as that can be a
	valid PC in some cases.

	My understanding is that the current_thread field should be a good candidate
	to signal that a particular displaced-step buffer is active or not. If it is
	nullptr, we have no threads using that buffer to displaced-step.  Otherwise,
	it is an active buffer in use by a particular thread.

	The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
	function so we only attempt to return a closure if the buffer has an assigned
	current_thread and if the buffer address matches the address argument.

	Alternatively, I think we could use a function to answer the question of
	whether we're actively displaced-stepping (so we have an active buffer) or
	not.

	I've also added a testcase that exercises the problem. It should reproduce
	reliably on Arm, as that is the only architecture that faces this problem
	at the moment.

	Regression-tested on Ubuntu 20.04. OK?

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-16  Andrew Burgess  <aburgess@redhat.com>

	gdb: replace architecture_changed with new_architecture observer
	This commit replaces the architecture_changed observer with a
	new_architecture observer.

	Currently the only user of the architecture_changed observer is the
	Python code, which uses this observer to register the Python unwinder
	with the architecture.

	The problem is that the architecture_changed observer is triggered
	from inferior::set_arch(), which only sees the inferior-wide gdbarch
	value.  For targets that use thread-specific architectures, these
	never trigger the architecture_changed observer, and so never have the
	Python unwinder registered with them.

	When it comes to unwinding GDB makes use of the frame's gdbarch, which
	is based on the thread's regcache gdbarch, which is set in
	get_thread_regcache to the value returned from
	target_thread_architecture, which is not always the inferiors gdbarch
	value, it might be a thread-specific gdbarch which has not passed
	through inferior::set_arch().

	The new_architecture observer will be triggered from
	gdbarch_find_by_info, whenever a new gdbarch is created and
	initialised.  As GDB caches and reuses gdbarch values, we should
	expect to see each new architecture trigger the new_architecture
	observer just once.

	After this commit, targets that make use of thread-specific
	architectures should be able to make use of Python unwinders.

	As I don't have access to a machine that makes use of thread-specific
	architectures right now, I asked Luis to confirm that an AArch64
	target that uses SVE/SME can't use the Python unwinders in threads
	that are using a thread-specific architectures, and he confirmed that
	this is indeed the case, see this discussion:

	  https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com

	Tested-By: Lancelot Six <lancelot.six@amd.com>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-16  Clément Chigot  <chigot@adacore.com>

	objcopy: Fix name of the field modified by pe_stack_reserve.

2023-10-16  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add "lp64e" ABI support
	Since RV32E and RV64E are now ratified, this commit prepares the ABI
	support for LP64E (LP64 with reduced GPRs).

	gas/ChangeLog:

		* config/tc-riscv.c (riscv_set_abi_by_arch): Update the error
		message.  (md_parse_option): Accept "lp64e".
		* doc/c-riscv.texi: Update the documentation to allow "lp64e".
		* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l:
		Change error message.
		* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
		* testsuite/gas/riscv/mabi-fail-rv32e-lp64q.l: Likewise.

2023-10-16  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Remove RV64E conflict
	Since RV32E *and* RV64E are ratified, RV64E is no longer invalid.

	This commit removes a restriction that prevents making base ISA with
	reduced GPRs with XLEN > 32.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_check_conflicts): Remove RV64E
		conflict since the ratified 'E' base ISAs include RV64E.

	gas/ChangeLog:

		* testsuite/gas/riscv/march-fail-base-02.d: Removed.
		* testsuite/gas/riscv/march-fail-base-02.l: Removed.

2023-10-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-15  Mike Frysinger  <vapier@gentoo.org>

	sim: add distclean dep for gnulib

2023-10-15  Neal Frager  <neal.frager@amd.com>

	opcodes: microblaze: Add new bit-field instructions
	This patches adds new bsefi and bsifi instructions.
	BSEFI- The instruction shall extract a bit field from a
	register and place it right-adjusted in the destination register.
	The other bits in the destination register shall be set to zero.
	BSIFI- The instruction shall insert a right-adjusted bit field
	from a register at another position in the destination register.
	The rest of the bits in the destination register shall be unchanged.

	Further documentation of these instructions can be found here:
	https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref

	With version 6 of the patch, no new relocation types are added as
	this was unnecessary for adding the bsefi and bsifi instructions.

	FIXED: Segfault caused by incorrect termination of microblaze_opcodes.

2023-10-15  Mike Frysinger  <vapier@gentoo.org>

	sim: mips: fix printf string

2023-10-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-13  Luis Machado  <luis.machado@arm.com>

	[aarch64] Use SVE_VQ_BYTES instead of __SVE_VQ_BYTES
	__SVE_VQ_BYTES is only available if SVE definitions are available in
	the system's headers, and this is not true for all systems.

	For this purpose, we define SVE_VQ_BYTES.  This patch fixes the
	name of the constant being used.

2023-10-13  Clément Chigot  <chigot@adacore.com>

	ld: replace wrong bfd_malloc in nto.em
	xmalloc should be called in ld instead of bfd_malloc.

	ld/ChangeLog:

		* emultempl/nto.em (nto_lookup_QNX_note_section): Replace
		bfd_malloc by xmalloc.

2023-10-13  Clément Chigot  <chigot@adacore.com>

	ld: warn when duplicated QNX stack note are detected
	This warning is triggered only when a stack parameter is given to
	the linker.

	ld/ChangeLog:

	        * emultempl/nto.em: Add warning when several QNX .note are
	        detected.

2023-10-13  Clément Chigot  <chigot@adacore.com>

	ld: correctly handle QNX --lazy-stack without -zstack-size
	The warning was skipped if -zstack-size is not provided.

	ld/ChangeLog:

	        * emultempl/nto.em: Move --lazy-stack warning before missing
	        -zstack-size skip.

2023-10-13  Clément Chigot  <chigot@adacore.com>

	ld: allow update of existing QNX stack note
	Up to now, the linker would always create a QNX stack note from scratch.
	However, object files could already have such note, ending up into
	duplicates. QNX loader doesn't handle that.

	Update the mechanism to first search through the input files for a .note
	section holding a QNX stack note. If none are found, then a new section
	is created into the stub file as before. This requires this search to be
	done once the file have been opened, moving the whole logic a bit later
	in the emulation process.

	As part for this update, also allow to request an executable stack
	without necessarily having to provide its size as well.  In this case, s
	etup a default lazy stack of 0x1000.

	ld/ChangeLog:

	        * emultempl/nto.em (nto_create_QNX_note_section): New Function.
	        (nto_lookup_QNX_note_section): New Function.
	        (nto_add_note_section): Move the creation of the note section
	        in the above new functions.
	        (nto_create_output_section_statements): rename nto_after_open
	        * testsuite/ld-aarch64/aarch64-nto.exp: add new test.
	        * testsuite/ld-aarch64/nto-stack-note-3.d: New test.
	        * testsuite/ld-aarch64/nto-stack-note.s: New test.

2023-10-13  Joseph Faulls  <Joseph.Faulls@imgtec.com>

	RISC-V: Add support for numbered ISA mapping strings
	The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>

	opcodes/
		* riscv-dis.c (riscv_get_map_state): allow mapping symbol to
		be suffixed by a unique identifier .<any>

2023-10-13  Tom Tromey  <tom@tromey.com>

	Move -lsocket check to common.m4
	A user pointed out that the -lsocket check in gdb should also apply to
	gdbserver -- otherwise it can't find the Solaris socketpair.  This
	patch makes the change.  It also removes a couple of redundant
	function checks from gdb's configure.ac.

	This was tested by the person who reported the bug.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
	Approved-By: Pedro Alves <pedro@palves.net>

2023-10-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-12  Tom Tromey  <tromey@adacore.com>

	Fix test suite failure in file-then-restart.exp
	Simon pointed out that the new file-then-restart.exp test fails with
	the extended-remote target board.

	The problem is that the test suite doesn't use gdb_file_cmd -- which
	handles things like "set remote exec-file".  This patch changes
	gdb_file_cmd to make the "kill" command optional, and then switches
	the test case to use it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-12  Andrew Burgess  <aburgess@redhat.com>

	bfd: add new bfd_cache_size() function
	In GDB we have a problem with the BFD cache.

	As GDB runs for a potentially extended period of time, if the BFD
	cache holds a file descriptor for an open on-disk file, this can, on
	some targets (e.g. Win32) prevent the OS writing to the file.

	This might, for example, prevent a user from recompiling their
	executable as GDB is (via the BFD cache) holding an open reference to
	that file.

	Another problem, relates to bfd_stat, for BFDs that are using the BFD
	cache (i.e. they call cache_bstat to implement bfd_stat).  The
	cache_bstat function finds the BFD in the cache, opening the file if
	needed, and then uses fstat on the open file descriptor.

	What this means is that, if the on-disk file changes, but the cache
	was holding an open reference to the file, the bfd_stat will return
	the 'struct stat' for the old file, not the new file.

	Now, for this second problem, we might be tempted to make use of an
	actual stat call, instead of calling bfd_stat, however, this isn't
	ideal as we have some BFDs that use a custom iovec, and implement the
	various functions over GDB's remote protocol.  By using bfd_stat we
	can have a single call that should work for both local files, and for
	remote files.

	To solve both of these problems GDB has calls to bfd_cache_close_all
	sprinkled around its code base.  And in theory this should work fine.

	However, I recently ran into a case where we had missed a
	bfd_cache_close_all call, and as a result some BFDs were held open.
	This caused a bfd_stat call to return an unexpected result (old file
	vs new file).

	What I'd like is some way within GDB that I can do:

	  gdb_assert ( /* Nothing is held open in the cache.  */ );

	As this would allow GDB to quickly identify when we've missed some
	bfd_cache_close_all calls.

	And so, to support this, I would like to add a new bfd_cache_size
	function.  This function returns an integer, which is the number of
	open files in the cache.  I can then start adding:

	  gdb_assert (bfd_cache_size() == 0);

	to GDB in some strategic spots, and start fixing all of the missing
	bfd_cache_close_all calls that crop up as a result.

2023-10-12  Andrew Burgess  <aburgess@redhat.com>

	bfd/cache: change type used to track cached BFDs from int to unsigned
	Within bfd/cache.c change the type for max_open_files and open_files
	variables from int to unsigned.  As a consequence of this, the return
	type for bfd_cache_max_open() is also changed from int to unsigned.

	Within bfd_cache_max_open I've left the local 'max' variable as an
	int, this should ensure that if the sysconf call fails, and returns
	-1, then the computed max value will be less than 10, which means
	max_open_files will be set to 10.  If 'max' was changed to unsigned
	then, should the sysconf call fail, we'd end up with max becoming a
	very large positive number ... which is clearly not what we want.

	And, while I was auditing how open_files is used, I added an assert
	within bfd_cache_delete to ensure that we don't try to reduce
	open_files below zero.

	There should be no user visible change with this commit.

2023-10-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-11  Jeff Law  <jlaw@ventanamicro.com>

	[RFA] Fix for mcore simulator
	I was looking for cases where a GCC patch under evaluation would cause test
	results to change.  Quite surprisingly the mcore-elf port showed test
	differences.   After a fair amount of digging my conclusion was the sequences
	before/after the patch should have been semantically the same.

	Of course if the code is supposed to behave the same, then that points to
	problems elsewhere (assembler, linker, simulator).  Sure enough the mcore
	simulator was mis-handling the sign extension instructions.  The simulator
	implementation of sextb is via paired shift-by-24 operations. Similarly the
	simulator implements sexth via paired shift-by-16 operations.

	The temporary holding the value was declared as a "long" thus this approach
	worked fine for hosts with a 32 bit wide long and failed miserably for hosts
	with a 64 bit wide long.

	This patch makes the shift count automatically adjust based on the size of the
	temporary.  It includes a simple test for sextb and sexth.  I have _not_ done a
	full audit of the mcore simulator for more 32->64 bit issues.

	This also fixes 443 execution tests in the GCC testsuite

2023-10-11  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Use the correct application name in error messages
	The old application name (er_archive) is used in many places.

	gprofng/ChangeLog
	2023-10-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Experiment.cc: Replace er_archive with gp-archive.
		* src/Experiment.cc: Likewise.

2023-10-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-10  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Handle special struct in dummy call
	When execute the following command on LoongArch:

	  make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"

	there exist some failed testcases:

	  === gdb Summary ===

	  # of expected passes		5533
	  # of unexpected failures	367

	The root cause is related with a struct containing floating-point
	members as function argument or return value for a dummy call.

	(1) Structure consists of one floating-point member within FRLEN bits
	    wide, it is passed in an FAR if available.
	(2) Structure consists of two floating-point members both within FRLEN
	    bits wide, it is passed in two FARs if available.
	(3) Structure consists of one integer member within GRLEN bits wide and
	    one floating-point member within FRLEN bits wide, it is passed in a
	    GAR and an FAR if available.

	Note that in the above cases, empty structure or union members are also
	ignored even in C++.

	Here is a simple test on LoongArch:

	  loongson@bogon:~$ cat test.c

	  #include<stdio.h>

	  struct test {
		  long   a;
		  double b __attribute__((aligned(16)));
	  };
	  struct test val = { 88, 99.99 };
	  int check_arg_struct (struct test arg)
	    {
	      printf("arg.a = %ld\n", arg.a);
	      printf("arg.b = %f\n", arg.b);
	      printf("sizeof(val) = %d\n", sizeof(val));
	      return 1;
	    }
	  int main()
	  {
	     check_arg_struct (val);
	     return 0;
	  }
	  loongson@bogon:~$ gcc -g test.c -o test
	  loongson@bogon:~$ ./test
	  arg.a = 88
	  arg.b = 99.990000
	  sizeof(val) = 32

	Before:

	loongson@bogon:~$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:19
	19	   check_arg_struct (val);
	(gdb) p check_arg_struct (val)
	arg.a = 140737488286128
	arg.b = -nan
	sizeof(val) = 32
	$1 = 1
	...

	After:

	loongson@bogon:~$ gdb test
	...
	(gdb) start
	...
	Temporary breakpoint 1, main () at test.c:19
	19	   check_arg_struct (val);
	(gdb) p check_arg_struct (val)
	arg.a = 88
	arg.b = 99.990000
	sizeof(val) = 32
	$1 = 1
	...

	With this patch, there are no failed testcases:

	  make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"

	   === gdb Summary ===

	   # of expected passes		5900

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add assertion when marking the remote async flag
	As reported in bug 30630 [1], we hit a case where the remote target's
	async flag is marked while the target is not configured (yet) to work
	async.  This should not happen.  It is caught thanks to this assert in
	remote_target::wait:

	    /* Start by clearing the flag that asks for our wait method to be called,
	       we'll mark it again at the end if needed.  If the target is not in
	       async mode then the async token should not be marked.  */
	    if (target_is_async_p ())
	      rs->clear_async_event_handler ();
	    else
	      gdb_assert (!rs->async_event_handler_marked ());

	This is helpful, but I think that we could have caught the problem earlier than
	that, at the moment we marked the handler.  Catching problems earlier
	makes them easier to debug.

	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630

	Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add remote_state::{is_async_p,can_async_p}
	A subsequent patch will want to know if the remote is async within a
	remote_state method.  Add a helper method for that, and for "can async"
	as well, for symmetry.

	Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make remote_state's async token private
	Make remote_async_inferior_event_token private (rename to
	m_async_event_handler_token) and add methods for the various operations
	we do on it.  This will help by:

	 - allowing to break on those methods when debugging
	 - allowing to add assertions in the methods

	Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove trailing whitespaces in remote.c
	Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: scope down registers_changed call in inferior::set_arch
	inferior::set_arch calls registers_changed, which invalidates all
	regcaches.  It would be enough to invalidate only regcaches of threads
	belonging to this inferior.  Call registers_changed_ptid instead, with
	the proper process target / ptid.  If the inferior does not have a
	process target, there should be no regcaches for that inferior, so no
	need to invalidate anything.

	Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove target_gdbarch
	This function is just a wrapper around the current inferior's gdbarch.
	I find that having that wrapper just obscures where the arch is coming
	from, and that it's often used as "I don't know which arch to use so
	I'll use this magical target_gdbarch function that gets me an arch" when
	the arch should in fact come from something in the context (a thread,
	objfile, symbol, etc).  I think that removing it and inlining
	`current_inferior ()->arch ()` everywhere will make it a bit clearer
	where that arch comes from and will trigger people into reflecting
	whether this is the right place to get the arch or not.

	Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move set_target_gdbarch to inferior::set_arch
	set_target_gdbarch is basically a setter for the current inferior's
	arch, that notifies other parts of GDB of the architecture change.  Move
	the code of set_target_gdbarch to the inferior::set_arch method.

	Add gdbarch_initialized_p, so we can keep the assertion.

	Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior parameter to architecture_changed observable
	This is to make it explicit which inferior's architecture just changed,
	and that the callbacks should not assume it is the current inferior.

	Update the only caller, pyuw_on_new_gdbarch, to add the parameter,
	although it doesn't use it currently.

	Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior::{arch, set_arch}
	Make the inferior's gdbarch field private, and add getters and setters.
	This helped me by allowing putting breakpoints on set_arch to know when
	the inferior's arch was set.  A subsequent patch in this series also
	adds more things in set_arch.

	Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Alan Modra  <amodra@gmail.com>

	asan: buffer overflow in elf32_arm_get_synthetic_symtab
	Guard against fuzzed files where .plt size isn't commensurate with
	plt relocations.

		* elf32-arm.c (elf32_arm_plt0_size): Add data_size param.
		Return -1 if data_size is too small.
		(elf32_arm_plt_size): Likewise.  Delete temp var.  Formatting.
		(elf32_arm_get_synthetic_symtab): Adjust to suit.

2023-10-10  Alan Modra  <amodra@gmail.com>

	asan: null dereference in read_and_display_attr_value
	This fixes multiple places in read_and_display_attr_value dealing with
	range and location lists that can segfault when debug_info_p is NULL.
	Fuzzed object files can contain arbitrary DW_FORMs.

		* dwarf.c (read_and_display_attr_value): Don't dereference NULL
		debug_info_p.

2023-10-10  Alan Modra  <amodra@gmail.com>

	asan: invalid free in bfd_init_section_compress_status
	With specially crafted compressed sections, it's possible to tickle a
	problem when decompressing:  If the compression headers says the
	uncompressed size is zero, this will be seen as an error return from
	bfd_compress_section_contents.  On errors the caller should free any
	malloc'd input buffers, but this isn't really an error and the section
	contents have been updated to a bfd_alloc'd buffer which can't be
	freed.

		* compress.c (bfd_compress_section_contents): Return -1 as error
		rather than 0.
		(bfd_init_section_compress_status, bfd_compress_section): Adjust.

2023-10-10  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: implement support for sending custom MI async notifications
	This commit adds a new Python function, gdb.notify_mi, that can be used
	to emit custom async notification to MI channel.  This can be used, among
	other things, to implement notifications about events MI does not support,
	such as remote connection closed or register change.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  Jan Vrany  <jan.vrany@labware.com>

	gdb/python: generalize serialize_mi_result()
	This commit generalizes serialize_mi_result() to make usable in
	different contexts than printing result of custom MI command.

	To do so, the check whether passed Python object is a dictionary has been
	moved to the caller - at the very least, different uses require different
	error messages.  Also it has been renamed to serialize_mi_results() to better
	match GDB/MI output syntax (see corresponding section in documentation,
	in particular rules 'result-record' and 'async-output'.

	Since it is now more generic function, it has been moved to py-mi.c.

	This is a preparation for implementing Python support for sending custom
	MI async events.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-10  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch/GAS: Add support for branch relaxation
	For the instructions of R_LARCH_B16/B21, if the immediate overflow,
	add a B instruction and R_LARCH_B26 relocation.

	For example:

	.L1
	  ...
	  blt $t0, $t1, .L1
	    R_LARCH_B16

	change to:

	.L1
	  ...
	  bge $t0, $t1, .L2
	  b .L1
	    R_LARCH_B26
	.L2

2023-10-10  Tom de Vries  <tdevries@suse.de>

	[readelf] Handle .gdb_index section version 9
	Add the abilitity to print a v9 .gdb_index section.

	The v9 section contains an extra table, which is printed as follows:
	...
	Shortcut table:
	Language of main: Fortran 95
	Name of main: contains_keyword
	...

	[ For the example, I used the exec of gdb test-case
	gdb.fortran/nested-funcs-2-exp when running the test-case with target board
	cc-with-gdb-index. ]

	Tested on x86_64-linux.

	Approved-By: Nick Clifton <nickc@redhat.com>

2023-10-10  Matheus Branco Borella  <dark.ryu.550@gmail.com>

	[gdb/symtab] Add name_of_main and language_of_main to the DWARF index
	This patch adds a new section to the DWARF index containing the name
	and the language of the main function symbol, gathered from
	`cooked_index::get_main`, if available. Currently, for lack of a better name,
	this section is called the "shortcut table". The way this name is both saved and
	applied upon an index being loaded in mirrors how it is done in
	`cooked_index_functions`, more specifically, the full name of the main function
	symbol is saved and `set_objfile_main_name` is used to apply it after it is
	loaded.

	The main use case for this patch is in improving startup times when dealing with
	large binaries. Currently, when an index is used, GDB has to expand symtabs
	until it finds out what the language of the main function symbol is. For some
	large executables, this may take a considerable amount of time to complete,
	slowing down startup. This patch bypasses that operation by having both the name
	and language of the main function symbol be provided ahead of time by the index.

	In my testing (a binary with about 1.8GB worth of DWARF data) this change brings
	startup time down from about 34 seconds to about 1.5 seconds.

	When testing the patch with target board cc-with-gdb-index, test-case
	gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a
	pre-existing issue, filed as PR symtab/30946.

	Tested on x86_64-linux, with target board unix and cc-with-gdb-index.

	PR symtab/24549
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549

	Approved-By: Tom de Vries <tdevries@suse.de>

2023-10-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-09  John Baldwin  <jhb@FreeBSD.org>

	gdb_unique_ptr.h: Fix a typo in a comment

2023-10-09  Nick Clifton  <nickc@redhat.com>

	Fix: Null pointer dereference in ldlex.l
	  PR 30951
	  * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL.

	Fix: A potential null_pointer_deference bug
	  PR 30954
	  * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it.

	Fix: Null pointer dereference in elf32-i386.c
	  PR 30950
	  * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer.

	Fix: A potential bug of null pointer dereference
	  PR 30949
	  * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer.

2023-10-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: match complete lines in gdb.base/maint.exp
	This thread:

	  https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/

	pointed out that within gdb.base/maint.exp, some regexps within a
	gdb_test_multiple were failing to match a complete line, while later
	regexps within the gdb_test_multiple made use of the '^' anchor, and
	so assumed that earlier lines had been completely matched and removed
	from expect's buffer.

	When testing with READ1 set this assumption was failing.

	Fix this by extending the offending patterns with a trailing '\r\n'.

	Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-08  Joel Brobecker  <brobecker@adacore.com>

	Update gdb/NEWS after GDB 14 branch creation.
	This commit a new section for the next release branch, and renames
	the section of the current branch, now that it has been cut.

2023-10-08  Joel Brobecker  <brobecker@adacore.com>

	Bump version to 15.0.50.DATE-git.
	Now that the GDB 14 branch has been created,
	this commit bumps the version number in gdb/version.in to
	15.0.50.DATE-git

	For the record, the GDB 14 branch was created
	from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588.

	Also, as a result of the version bump, the following changes
	have been made in gdb/testsuite:

		* gdb.base/default.exp: Change $_gdb_major to 15.

2023-10-08  cailulu  <cailulu@loongson.cn>

	Add testsuits for new assembler option of mthin-add-sub.

2023-10-08  cailulu  <cailulu@loongson.cn>

	as: add option for generate R_LARCH_32/64_PCREL.
	Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL,
	so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default,
	and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL
	as much as possible.

	The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL
	relocation in .eh_frame.

2023-10-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-07  Michael J. Eager  <eager@eagercon.com>

	Revert "opcodes: microblaze: Add new bit-field instructions"
	This reverts commit 6bbf249557ba17cfebe01c67370df4da9e6a56f9.

	Maciej W. Rozycki <macro@orcam.me.uk>:
	 Yet it has caused numerous regressions:

	microblaze-elf  +FAIL: unordered .debug_info references to .debug_ranges
	microblaze-elf  +FAIL: binutils-all/pr26548
	microblaze-elf  +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
	microblaze-elf  +FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output) Yet it has caused numerous regressions:
	microblaze-elf  +FAIL: unordered .debug_info references to .debug_ranges
	microblaze-elf  +FAIL: binutils-all/pr26548
	microblaze-elf  +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
	...

2023-10-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/i386-signal.exp on x86_64
	On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into:
	...
	builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \
	  -fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M
	/tmp/cc2xydTG.s: Assembler messages:^M
	/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
	compiler exited with status 1
	output is:
	/tmp/cc2xydTG.s: Assembler messages:^M
	/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M

	gdb compile failed, /tmp/cc2xydTG.s: Assembler messages:
	/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'
	UNTESTED: gdb.arch/i386-signal.exp: failed to compile
	...

	This is with gas 2.41, it compiles without problems with gas 2.40.  Some more
	strict checking was added in commit 5cc007751cd ("x86: further adjust
	extend-to-32bit-address conditions").  This may or may not be a gas regression
	( https://sourceware.org/pipermail/binutils/2023-October/129818.html ).

	The offending bit is:
	...
	    "    push $sigframe\n"
	...
	which refers to a function:
	...
	    "    .globl sigframe\n"
	    "sigframe:\n"
	...

	The test-case passes with target board unix/-m32.

	Make the test-case work by using pushq instead of push for the
	is_amd64_regs_target case.

	Tested on x86_64-linux, with target boards:
	- unix/-m64 (is_amd64_regs_target == 1), and
	- unix/-m32 (is_amd64_regs_target == 0),

	PR testsuite/30928
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928

2023-10-07  Ilya Leoshkevich  <iii@linux.ibm.com>

	gdb: support rseq auxvs
	Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size
	and alignment ELF auxiliary vector entries") introduced two new auxvs:
	AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN.  Support them in GDB.  This
	fixes auxv.exp on kernels >= v6.3.

	Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30910 cross test fail: can't read "CHECK_TARGET": no such variable
	When TCL_TRY is FALSE, the wrong check-DEJAGNU is generated.
	Place "if TCL_TRY / endif" in the right place.

	gprofng/ChangeLog
	2023-10-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30910
		* Makefile.am: Correct "if TCL_TRY / endif".
		* Makefile.in: Rebuild.

2023-10-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-06  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	process-dies-while-detaching.exp: Exit early if GDB misses sync breakpoint
	I'm seeing a lot of variability in the failures of
	gdb.threads/process-dies-while-detaching.exp on aarch64-linux.  On this
	platform, a problem yet to be investigated causes GDB to miss the _exit
	breakpoint.  What happens next is random because after missing that
	breakpoint, GDB is out of sync with the inferior.  This causes the tests
	following that point in the testcase to fail in a random way.

	In this scenario it's better to exit the testcase early to avoid random
	results in the testsuite.

	We are relying on gdb_continue_to_breakpoint to return the result of
	gdb_test_multiple.  This is already the case because in Tcl the return
	value of a function is the return value of the last command it runs.  But
	change gdb_continue_to_breakpoint to explicitly return this value, to make
	it clear this is the intended behaviour.

	Tested on aarch64-linux.

	Tested-By: Guinevere Larsen <blarsen@redhat.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-06  Neal Frager  <neal.frager@amd.com>

	opcodes: microblaze: Add new bit-field instructions
	This patches adds new bsefi and bsifi instructions.
	BSEFI- The instruction shall extract a bit field from a
	register and place it right-adjusted in the destination register.
	The other bits in the destination register shall be set to zero.
	BSIFI- The instruction shall insert a right-adjusted bit field
	from a register at another position in the destination register.
	The rest of the bits in the destination register shall be unchanged.

	Further documentation of these instructions can be found here:
	https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref

	This patch has been tested for years of AMD Xilinx Yocto
	releases as part of the following patch set:

	https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/NEWS: reorder some entries in the NEWS file
	I spotted two entries in the NEWS file that I believe are in the wrong
	place, these are:

	  - An entry about MI v1 being deprecated, this feels like it should
	    be the first entry under the 'MI changes' heading, and

	  - An entry for the $_shell convenience function which is currently
	    under the 'New commands' heading (sort of), when I think this
	    should be listed in the general news section.

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: fix gdbserver builds after expedite_regs changes
	After this commit:

	  commit 6a65998a8a94abaaae7ca4ff0ab9c3f25dc2e766
	  Date:   Mon Sep 11 12:42:00 2023 +0100

	      Convert tdesc's expedite_regs to a string vector

	The risc-v, loongarch, and csky gdbserver builds were broken.  A use
	of target_desc::expedite_regs (for each architecture)  was not updated
	to take account of the type change.

	I've tested that this fixes the risc-v build.  I haven't tested the
	other architectures, but they should be fine.

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: cleanup in gdb.base/args.exp
	The last few commits resolved the KFAILs in gdb.base/args.exp.  With
	those out of the way we can clean up this test script a little.

	In this commit I have:

	  - Stopped passing 'nowarnings' flag when building the source file.
	    I see no reason why this source should issue a warning,

	  - Moved setup of GDBFLAGS into args_test proc, callers that passed a
	    newline needed a small tweak, and also the matching code needs
	    updating for newline handling, but I think this is nicer, the
	    argument lists are now given just once,

	  - Updated comment on args_test,

	  - Updated other comments.

	There should be no change in what is tested after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: cleanup in handle_v_run
	After the previous commit there is now a redundant string copy in
	handle_v_run, this commit cleans that up.

	There should be no functional change after this commit.

	During review I was pointed to this older series:

	  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

	which also includes this fix as part of a larger set of changes.  I'm
	giving a Co-Authored-By credit to the author of that original series.
	I believe this smaller fix brings some benefits on its own, though the
	original series does offer additional improvements.  Once this is
	merged I'll take a look at rebasing and resubmitting the original series.

	Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: handle newlines in inferior arguments
	Similarly to how single quotes were mishandled, which was fixed two
	commits ago, this commit fixes handling of newlines in arguments
	passed to gdbserver.

	We already had a test that covered this, gdb.base/args.exp, which,
	when run with the native-extended-gdbserver board contained several
	KFAIL covering this situation.

	In this commit I remove the unnecessary, attempt to quote incoming
	newlines within arguments, and do some minimal cleanup of the related
	code.  There is additional cleanup that can be done, but I'm leaving
	that for the next commit.

	Then I've removed the KFAIL from the test case, and performed some
	minimal cleanup there too.

	After this commit the gdb.base/args.exp is 100% passing with the
	native-extended-gdbserver board file.

	During review I was pointed to this older series:

	  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

	which also includes this fix as part of a larger set of changes.  I'm
	giving a Co-Authored-By credit to the author of that original series.
	I believe this smaller fix brings some benefits on its own, though the
	original series does offer additional improvements.  Once this is
	merged I'll take a look at rebasing and resubmitting the original series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989

	Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: fix handling of trailing empty argument
	When I posted the previous patch for review Andreas Schwab pointed out
	that passing a trailing empty argument also doesn't work.

	The fix for this is in the same area of code as the previous patch,
	but is sufficiently different that I felt it deserved a patch of its
	own.

	I noticed that passing arguments containing single quotes to gdbserver
	didn't work correctly:

	  gdb -ex 'set sysroot' --args /tmp/show-args
	  Reading symbols from /tmp/show-args...
	  (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
	  Remote debugging using | gdbserver --once --multi - /tmp/show-args
	  stdin/stdout redirected
	  Process /tmp/show-args created; pid = 176054
	  Remote debugging using stdio
	  Reading symbols from /lib64/ld-linux-x86-64.so.2...
	  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) set args abc ""
	  (gdb) run
	  The program being debugged has been started already.
	  Start it from the beginning? (y or n) y
	  Starting program: /tmp/show-args \'
	  stdin/stdout redirected
	  Process /tmp/show-args created; pid = 176088
	  2 args are:
	    /tmp/show-args
	    abc
	  Done.
	  [Inferior 1 (process 176088) exited normally]
	  (gdb) target native
	  Done.  Use the "run" command to start a process.
	  (gdb) run
	  Starting program: /tmp/show-args \'
	  2 args are:
	    /tmp/show-args
	    abc

	  Done.
	  [Inferior 1 (process 176095) exited normally]
	  (gdb) q

	The 'shows-args' program used here just prints the arguments passed to
	the inferior.

	Notice that when starting the inferior using the extended-remote
	target there is only a single argument 'abc', while when using the
	native target there is a second argument, the blank line, representing
	the empty argument.

	The problem here is that the vRun packet coming from GDB looks like
	this (I've removing the trailing checksum):

	  $vRun;PROGRAM_NAME;616263;

	If we compare this to a packet with only a single argument and no
	trailing empty argument:

	  $vRun;PROGRAM_NAME;616263

	Notice the lack of the trailing ';' character here.

	The problem is that gdbserver processes this string in a loop.  At
	each point we maintain a pointer to the character just after a ';',
	and then we process everything up to either the next ';' character, or
	to the end of the string.

	We break out of this loop when the character we start with (in that
	loop iteration) is the null-character.  This means in the trailing
	empty argument case, we abort the loop before doing anything with the
	empty argument.

	In this commit I've updated the loop, we now break out using a 'break'
	statement at the end of the loop if the (sub-)string we just processed
	was empty, with this change we now notice the trailing empty
	argument.

	I've updated the test case to cover this issue.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: fix handling of single quote arguments
	I noticed that passing arguments containing single quotes to gdbserver
	didn't work correctly:

	  gdb -ex 'set sysroot' --args /tmp/show-args
	  Reading symbols from /tmp/show-args...
	  (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
	  Remote debugging using | gdbserver --once --multi - /tmp/show-args
	  stdin/stdout redirected
	  Process /tmp/show-args created; pid = 176054
	  Remote debugging using stdio
	  Reading symbols from /lib64/ld-linux-x86-64.so.2...
	  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) set args \'
	  (gdb) r
	  The program being debugged has been started already.
	  Start it from the beginning? (y or n) y
	  Starting program: /tmp/show-args \'
	  stdin/stdout redirected
	  Process /tmp/show-args created; pid = 176088
	  2 args are:
	    /tmp/show-args
	    \'
	  Done.
	  [Inferior 1 (process 176088) exited normally]
	  (gdb) target native
	  Done.  Use the "run" command to start a process.
	  (gdb) run
	  Starting program: /tmp/show-args \'
	  2 args are:
	    /tmp/show-args
	    '
	  Done.
	  [Inferior 1 (process 176095) exited normally]
	  (gdb) q

	The 'shows-args' program used here just prints the arguments passed to
	the inferior.

	Notice that when starting the inferior using the extended-remote
	target the second argument is "\'", while when running using native
	target the argument is "'".  The second of these is correct, the \'
	used with the "set args" command is just to show GDB that the single
	quote is not opening an argument string.

	It turns out that the extra backslash is injected on the gdbserver
	side when gdbserver processes the arguments that GDB passes it, the
	code that does this was added as part of this much larger commit:

	  commit 2090129c36c7e582943b7d300968d19b46160d84
	  Date:   Thu Dec 22 21:11:11 2016 -0500

	      Share fork_inferior et al with gdbserver

	In this commit I propose removing the specific code that adds what I
	believe is a stray backslash.  I've extended an existing test to cover
	this case, and I now see identical behaviour when using an
	extended-remote target as with the native target.

	This partially fixes PR gdb/27989, though there are still some issues
	with newline handling which I'll address in a later commit.

	During review I was pointed to this older series:

	  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

	which also includes this fix as part of a larger set of changes.  I'm
	giving a Co-Authored-By credit to the author of that original series.
	I believe this smaller fix brings some benefits on its own, though the
	original series does offer additional improvements.  Once this is
	merged I'll take a look at rebasing and resubmitting the original series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989

	Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  Nick Clifton  <nickc@redhat.com>

	Fix: alpha: ld segfaults in
	  PR 30940
	  * elf64-alpha.c (elf64_alpha_check_relocs): Correct error message.

2023-10-06  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/configure.ac: Add option --with-additional-debug-dirs
	If you want to install GDB in a custom prefix, have it look for debug info
	in that prefix but also in the distro's default location (typically,
	/usr/lib/debug) and run the GDB testsuite before doing "make install", you
	have a bit of a problem:

	Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory'
	parameter to $PREFIX/lib/debug.  Unfortunately this precludes GDB from
	looking for distro-installed debug info in /usr/lib/debug.  For regular GDB
	use you could set debug-file-directory to $PREFIX:/usr/lib/debug in
	$PREFIX/etc/gdbinit so that GDB will look in both places, but if you want
	to run the testsuite then that doesn't help because in that case GDB runs
	with the '-nx' option.

	There's the configure option '--with-separate-debug-dir' to set the default
	value for 'debug-file-directory', but it accepts only one directory and not
	a list.  I considered modifying it to accept a list, but it's not obvious
	how to do that because its value is also used by BFD, as well as processed
	for "relocatability".

	I thought it was simpler to add a new option to specify a list of
	additional directories that will be appended to the debug-file-directory
	setting.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-05  Tom de Vries  <tdevries@suse.de>

	[gdb/go] Handle v3 go_0 mangled prefix
	With gcc-10 we have:
	...
	(gdb) break package2.Foo^M
	Breakpoint 2 at 0x402563: file package2.go, line 5.^M
	(gdb) PASS: gdb.go/package.exp: setting breakpoint 1
	...
	but with gcc-11:
	...
	gdb) break package2.Foo^M
	Function "package2.Foo" not defined.^M
	Make breakpoint pending on future shared library load? (y or [n]) n^M
	(gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo
	...

	In the gcc-10 case, though the exec contains dwarf, it's not used to set the
	breakpoint (which is an independent problem, filed as PR go/30941), instead
	the minimal symbol information is used.

	The minimal symbol information changed between gcc-10 and gcc-11:
	...
	$ nm a.out.10 | grep Foo
	000000000040370d T go.package2.Foo
	0000000000404e50 R go.package2.Foo..f
	$ nm a.out.11 | grep Foo
	0000000000403857 T go_0package2.Foo
	0000000000405030 R go_0package2.Foo..f
	...

	A new v3 mangling scheme was used.  The mangling schemes define a separator
	character and mangling character:
	- for v2, dot is used both as separator character and mangling character, and
	- for v3, dot is used as separator character and underscore as mangling
	  character.

	For more details, see [1] and [2].

	In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo:
	change mangling scheme"), function Special_char_code::Special_char_code. ]

	Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the
	test-case.

	Note that this doesn't fix this regression:
	...
	$ gccgo-10 package2.go -c -g0
	$ gccgo-10 package1.go package2.o -g0
	$ gdb -q -batch a.out -ex "break go.package2.Foo"
	Breakpoint 1 at 0x40370d
	$ gccgo-11 package2.go -c -g0
	$ gccgo-11 package1.go package2.o -g0
	$ gdb -q -batch a.out -ex "break go.package2.Foo"
	Function "go.package2.Foo" not defined.
	...

	With gcc-10, we set a breakpoint on the mangled minimal symbol.  That
	one has simply changed for gcc-11, so it's equivalent to using:
	...
	$ gdb -q -batch a.out -ex "break go_0package2.Foo"
	Breakpoint 1 at 0x403857
	...
	which does work.

	Tested on x86_64-linux:
	- openSUSE Leap 15.4, using gccgo-7,
	- openSUSE Tumbleweed, using gccgo-13.

	PR go/27238
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238

	[1] https://go-review.googlesource.com/c/gofrontend/+/271726
	[2] https://github.com/golang/go/issues/41862#issuecomment-707244103

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use objfile->pspace in free_objfile observers
	Use objfile->pspace instead of current_program_space.

	Change-Id: I127a1788e155b321563114452ed5b530f1d1f618
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary nullptr check in free_objfile observers
	The free_objfile observable is never called with a nullptr objfile.

	Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add all_objfiles_removed observer
	The new_objfile observer is currently used to indicate both when a new
	objfile is added to program space (when passed non-nullptr) and when all
	objfiles of a program space were just removed (when passed nullptr).
	I think this is confusing (and Andrew apparently thinks so too [1]).
	Add a new "all_objfiles_removed" observer to remove the second role from
	"new_objfile".

	Some existing users of new_objfile do nothing if the passed objfile is
	nullptr.  For them, we can simply drop the nullptr check.  For others,
	add a new all_objfiles_removed callback, and refactor things a bit to
	keep the existing behavior as much as possible.

	Some callbacks relied on current_program_space, and following
	the refactoring now use either objfile->pspace or the pspace passed to
	all_objfiles_removed.  I think this should be relatively safe, and in
	general a step in the right direction.

	On the notify side, I found only one call site to change from
	new_objfile to all_objfiles_removed, in clear_symtab_users.  It is not
	entirely clear to me that this is entirely correct.  clear_symtab_users
	appears to be called in spots that don't remove all objfiles
	(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
	do_module_cleanups).  But I think that this patch at least makes the
	current code clearer.

	[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252

	Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameters to some auto-load functions
	Make the current_program_space references bubble up a bit.

	Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use objfile->pspace in auto-load.c
	Use objfile->pspace instead of current_program_space in two spots.

	Change-Id: Idf94fad486252d1250380f295e71b0fe76dce76c
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to emit_clear_objfiles_event
	Add program_space space parameters to emit_clear_objfiles_event and
	create_clear_objfiles_event_object, making the reference to
	current_program_space bubble up a bit.

	Change-Id: I5fde2071712781e5d45971fa0ab34d85d3a49a71
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameters to some functions in symtab.c
	Add some program_space parameters to functions related to getting and
	setting the main name, making the references to current_program_space
	bubble up a bit.  find_main_name calls ada_main_name, which implicitly
	relies on the current program space, so I didn't add a parameter to that
	function.

	Change-Id: I9996955e8ae56832bbd461964d978e700e6feaf4
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add program_space parameter to ada_clear_symbol_cache
	Make the references to current_program_space bubble up one level.

	Change-Id: I82acab5628c30f6535d52aa32ce2c1d0375cbeed
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix auxv cache clearing from new_objfile observer
	It was pointed out on the mailing list that a recently added
	test (gdb.python/py-progspace-events.exp) was failing when run with
	the native-extended-gdbserver board.  This test was added with this
	commit:

	  commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
	  Date:   Tue Sep 19 11:45:36 2023 +0100

	      gdb: add Python events for program space addition and removal

	It turns out though that the test is failing due to a existing bug
	in GDB, the new test just exposes the problem.  Additionally, the
	failure really doesn't even rely on the new functionality added in the
	above commit.  I reduced the test to a simple set of steps that
	reproduced the failure and tested against GDB 13, and the test passes;
	so the bug was introduced since then.  In fact, the bug was introduced
	with this commit:

	  commit a2827364e2bf19910fa5a54364a594a5ba3033b8
	  Date:   Fri Sep 8 15:48:16 2023 +0100

	      gdb: remove final user of the executable_changed observer

	This commit changed how the per-inferior auxv data cache is managed,
	specifically, when the cache is cleared, and it is this that leads to
	the failure.

	This bug is interesting because it exposes a number of issues with
	GDB, I'll explain all of the problems I see, though ultimately, I only
	propose fixing one problem in this commit, which is enough to resolve
	the crash we are currently seeing.

	The crash that we are seeing manifests like this:

	  ...
	  [Inferior 2 (process 3970384) exited normally]
	  +inferior 1
	  [Switching to inferior 1 [process 3970383] (/tmp/build/gdb/testsuite/outputs/gdb.python/py-progspace-events/py-progspace-events)]
	  [Switching to thread 1.1 (Thread 3970383.3970383)]
	  #0  breakpt () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.python/py-progspace-events.c:28
	  28	{ /* Nothing.  */ }
	  (gdb) step
	  +step
	  terminate called after throwing an instance of 'gdb_exception_error'

	  Fatal signal: Aborted
	  ... etc ...

	What's happening is that GDB attempts to refill the auxv cache as a
	result of the gdbarch_has_shared_address_space call in
	program_space::~program_space, the backtrace looks like this:

	  #0  0x00007fb4f419a9a5 in raise () from /lib64/libpthread.so.0
	  #1  0x00000000008b635d in handle_fatal_signal (sig=6) at ../../src/gdb/event-top.c:912
	  #2  <signal handler called>
	  #3  0x00007fb4f38e3625 in raise () from /lib64/libc.so.6
	  #4  0x00007fb4f38cc8d9 in abort () from /lib64/libc.so.6
	  #5  0x00007fb4f3c70756 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
	  #6  0x00007fb4f3c7c6dc in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
	  #7  0x00007fb4f3c7b6e9 in __cxa_call_terminate () from /lib64/libstdc++.so.6
	  #8  0x00007fb4f3c7c094 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
	  #9  0x00007fb4f3a80c63 in _Unwind_RaiseException_Phase2 () from /lib64/libgcc_s.so.1
	  #10 0x00007fb4f3a8154e in _Unwind_Resume () from /lib64/libgcc_s.so.1
	  #11 0x0000000000e8832d in target_read_alloc_1<unsigned char> (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2266
	  #12 0x0000000000e73dea in target_read_alloc (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2315
	  #13 0x000000000058248c in target_read_auxv_raw (ops=0x408a3a0) at ../../src/gdb/auxv.c:379
	  #14 0x000000000058243d in target_read_auxv () at ../../src/gdb/auxv.c:368
	  #15 0x000000000058255c in target_auxv_search (match=0x0, valp=0x7ffdee17c598) at ../../src/gdb/auxv.c:415
	  #16 0x0000000000a464bb in linux_is_uclinux () at ../../src/gdb/linux-tdep.c:433
	  #17 0x0000000000a464f6 in linux_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/linux-tdep.c:440
	  #18 0x0000000000510eae in gdbarch_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/gdbarch.c:4889
	  #19 0x0000000000bc7558 in program_space::~program_space (this=0x4544aa0, __in_chrg=<optimized out>) at ../../src/gdb/progspace.c:124
	  #20 0x00000000009b245d in delete_inferior (inf=0x47b3de0) at ../../src/gdb/inferior.c:290
	  #21 0x00000000009b2c10 in prune_inferiors () at ../../src/gdb/inferior.c:480
	  #22 0x00000000009c5e3e in fetch_inferior_event () at ../../src/gdb/infrun.c:4558
	  #23 0x000000000099b4dc in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
	  #24 0x0000000000cbc64f in remote_async_serial_handler (scb=0x4090a30, context=0x408a6b0) at ../../src/gdb/remote.c:14859
	  #25 0x0000000000d83d3a in run_async_handler_and_reschedule (scb=0x4090a30) at ../../src/gdb/ser-base.c:138
	  #26 0x0000000000d83e1f in fd_event (error=0, context=0x4090a30) at ../../src/gdb/ser-base.c:189

	So this is problem #1, if we throw an exception while deleting a
	program_space then this is not caught, and is going to crash GDB.

	Problem #2 becomes evident when we ask why GDB is throwing an error in
	this case; the error is thrown because the remote target, operating in
	non-async mode, can't read the auxv data while an inferior is running
	and GDB is waiting for a stop reply.  The problem here then, is why
	does GDB get into a position where it tries to interact with the
	remote target in this way, at this time?  The problem is caused by the
	prune_inferiors call which can be seen in the above backtrace.

	In prune_inferiors we check if the inferior is deletable, and if it
	is, we delete it.  The problem is, I think, we should also check if
	the target is currently in a state that would allow us to delete the
	inferior.  We don't currently have such a check available, we'd need
	to add one, but for the remote target, this would return false if the
	remote is in async mode and the remote is currently waiting for a stop
	reply.  With this change in place GDB would defer deleting the
	inferior until the remote target has stopped, at which point GDB would
	be able to refill the auxv cache successfully.

	And then, problem #3 becomes evident when we ask why GDB is needing to
	refill the auxv cache now when it didn't need to for GDB 13.  This is
	where the second commit mentioned above (a2827364e2bf) comes in.
	Prior to this commit, the auxv cache was cleared by the
	executable_changed observer, while after that commit the auxv cache
	was cleared by the new_objfile observer -- but only when the
	new_objfile observer is used in the special mode that actually means
	that all objfiles have been unloaded (I know, the overloading of the
	new_objfile observer is horrible, and unnecessary, but it's not really
	important for this bug).

	The difference arises because the new_objfile observer is triggered
	from clear_symtab_users, which in turn is called from
	program_space::~program_space.  The new_objfile observer for auxv does
	this:

	  static void
	  auxv_new_objfile_observer (struct objfile *objfile)
	  {
	    if (objfile == nullptr)
	      invalidate_auxv_cache_inf (current_inferior ());
	  }

	That is, when all the objfiles are unloaded, we clear the auxv cache
	for the current inferior.

	The problem is, then when we look at the prune_inferiors ->
	delete_inferior -> ~program_space path, we see that the current
	inferior is not going to be an inferior that exists within the
	program_space being deleted; delete_inferior removes the deleted
	inferior from the global inferior list, and then only deletes the
	program_space if program_space::empty() returns true, which is only
	the case if the current inferior isn't within the program_space to
	delete, and no other inferior exists within that program_space
	either.

	What this means is that when the new_objfile observer is called we
	can't rely on the current inferior having any relationship with the
	program space in which the objfiles were removed.  This was an error
	in the commit a2827364e2bf, the only thing we can rely on is the
	current program space.  As a result of this mistake, after commit
	a2827364e2bf, GDB was sometimes clearing the auxv cache for a random
	inferior.  In the native target case this was harmless as we can
	always refill the cache when needed, but in the remote target case, if
	we need to refill the cache when the remote target is executing, then
	we get the crash we observed.

	And additionally, if we think about this a little more, we see that
	commit a2827364e2bf made another mistake.  When all the objfiles are
	removed, they are removed from a program_space, a program_space might
	contain multiple inferiors, so surely, we should clear the auxv cache
	for all of the matching inferiors?

	Given these two insights, that the current_inferior is not relevant,
	only the current_program_space, and that we should be clearing the
	cache for all inferiors in the current_program_space, we can update
	auxv_new_objfile_observer to:

	  if (objfile == nullptr)
	    {
	      for (inferior *inf : all_inferiors ())
		{
		  if (inf->pspace == current_program_space)
		    invalidate_auxv_cache_inf (inf);
		}
	    }

	With this change we now correctly clear the auxv cache for the correct
	inferiors, and GDB no longer needs to refill the cache at an
	inconvenient time, this avoids the crash we were seeing.

	And finally, we reach problem #4.  Inspired by the observation that
	using the current_inferior from within the ~program_space function was
	not correct, I added some debug to see if current_inferior() was
	called anywhere else (below ~program_space), and the answer is yes,
	it's called a often.  Mostly the culprit is GDB doing:

	  current_inferior ()->top_target ()-> ....

	But I think all of these calls are most likely doing the wrong thing,
	and only work because the top target in all these cases is shared
	between all inferiors, e.g. it's the native target, or the remote
	target for all inferiors.  But if we had a truly multi-connection
	setup, then we might start to see odd behaviour.

	Problem #1 I'm just ignoring for now, I guess at some point we might
	run into this again, and then we'd need to solve this.  But in this
	case I wasn't sure what a "good" solution would look like.  We need
	the auxv data in order to implement the linux_is_uclinux() function.
	If we can't get the auxv data then what should we do, assume yes, or
	assume no?  The right answer would probably be to propagate the error
	back up the stack, but then we reach ~program_space, and throwing
	exceptions from a destructor is problematic, so we'd need to catch and
	deal at this point.  The linux_is_uclinux() call is made from within
	gdbarch_has_shared_address_space(), which is used like:

	  if (!gdbarch_has_shared_address_space (target_gdbarch ()))
	    delete this->aspace;

	So, we would have to choose; delete the address space or not.  If we
	delete it on error, then we might delete an address space that is
	shared within another program space.  If we don't delete the address
	space, then we might leak it.  Neither choice is great.

	A better solution might be to have the address spaces be reference
	counted, then we could remove the gdbarch_has_shared_address_space
	call completely, and just rely on the reference count to auto-delete
	the address space when appropriate.

	The solution for problem #2 I already hinted at above, we should have
	a new target_can_delete_inferiors() call, which should be called from
	prune_inferiors, this would prevent GDB from trying to delete
	inferiors when a (remote) target is in a state where we know it can't
	delete the inferior.  Deleting an inferior often (always?) requires
	sending packets to the remote, and if the remote is waiting for a stop
	reply then this will never work, so the pruning should be deferred in
	this case.

	The solution for problem #3 is included in this commit.

	And, for problem #4, I'm not sure what the right solution is.  Maybe
	delete_inferior should ensure the inferior to be deleted is in place
	when ~program_space is called?  But that seems a little weird, as the
	current inferior would, in theory, still be using the current
	program_space...

	Anyway, after this commit, the gdb.python/py-progspace-events.exp test
	now passes when run with the native-extended-remote board.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30935
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I41f0e6e2d7ecc1e5e55ec170f37acd4052f46eaf

2023-10-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30894 bison should be no hard dependency
	When running from a distribution tarball, bison should not be necessary.
	The generated files (QLParser.tab.cc, QLParser.tab.hh) should be distributed.
	configure.ac should not abort if bison is missing.
	configure.ac should remove temporary files (dummy.c, Simple.class).
	bison must be run once to create QLParser.tab.cc and QLParser.tab.hh.

	gprofng/ChangeLog
	2023-10-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30894
		* configure.ac: Don't abort if bison is missing. Remove temporary files.
		* src/Makefile.am: Distribute QLParser.tab.cc and QLParser.tab.hh.
		* Run bison once to create QLParser.tab.cc and QLParser.tab.hh.
		* configure: Rebuild.
		* src/Makefile.in: Rebuild.

2023-10-05  Nick Clifton  <nickc@redhat.com>

	Fix: nm: SEGV at bfd/elf.c:2267 in _bfd_elf_get_dynamic_symbols
	  PR 30904
	  * elf.c (_bfd_elf_get_dynamic_symbols): Fix typo when checking to see if the gnuchains array has been successfully created.

2023-10-05  A. Wilcox  <awilfox@adelielinux.org>

	Fix: ld: Test case pr28158 fails on x86_64-linux-musl when index is > 19
	  PR 30905
	  * testsuite/ld-elf/pr28158.rd: Adjust regexp to allow for section indicies larger than 9.

	Fix: addr2line testsuite fails when targeting PowerPC 64 big-endian with ELFv2 ABI
	  PR 30916
	  * testsuite/binutils-all/addr2line.exp: Do not use PowerPC specific options when working with a MUSL target.

	Fix: ld testsuite: glibc-specific DT_RELR tests should not be run on musl systems
	  PR 30917
	  * testsuite/ld-elf/dt-relr.exp: Skip for MUSL targets.

	Fix: ld testsuite: non-PIC shared tests fail on powerpc-linux-musl
	  PR 30918
	  * testsuite/ld-shared/shared.exp: Add XFAILs for tests that fail with the MUSL library.

	Fix: ld testsuite: Thumb PLT and GOT tests should be skipped on musl armhf targets
	  PR 30923
	  * testsuite/ld-arm/thumb-plt-got.d: Skip test for configurations using the MUSL library.
	  * testsuite/ld-arm/thumb-plt.d: Likewise.

	Fix: ld testsuite: pr22001-1 test segfaults on musl/x86
	  PR 30925
	  PR 22001
	  * testsuite/ld-i386/i386.exp: Skip the pr22001 test with TEXTREL relocations enabled on configurations using the MUSL library.

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix reread_symbols when an objfile has target: prefix
	When using a remote target, it is possible to tell GDB that the
	executable to be debugged is located on the remote machine, like this:

	  (gdb) target extended-remote :54321
	  ... snip ...
	  (gdb) file target:/tmp/hello.x
	  Reading /tmp/hello.x from remote target...
	  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
	  Reading /tmp/hello.x from remote target...
	  Reading symbols from target:/tmp/hello.x...
	  (gdb)

	So far so good.  However, when we try to start the inferior we run
	into a small problem:

	  (gdb) set remote exec-file /tmp/hello.x
	  (gdb) start
	  `target:/tmp/hello.x' has disappeared; keeping its symbols.
	  Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
	  Starting program: target:/tmp/hello.x
	  ... snip ...

	  Temporary breakpoint 1, main () at /tmp/hello.c:18
	  18	  printf ("Hello World\n");
	  (gdb)

	Notice this line:

	  `target:/tmp/hello.x' has disappeared; keeping its symbols.

	That's wrong, the executable hasn't been removed, GDB just doesn't
	know how to check if the remote file has changed, and so falls back to
	assuming that the file has been removed.

	In this commit I update reread_symbols to use bfd_stat instead of
	a direct stat call, this adds support for target: files, and fixes the
	problem.

	This change was proposed before in this commit:

	  https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/

	However, that patch never got merged, and seemed to get stuck
	discussing issues around gnulib stat vs system stat as used by BFD.

	I didn't 100% understand the issues discussed in that thread, however,
	I think the problem with the previous thread related to the changes in
	gdb_bfd.c, rather than to the change in symfile.c.  As such, I think
	this change might be acceptable, my reasoning is:

	  - the objfile::mtime field is set by a call to bfd_get_mtime (see
	    objfiles.c), which calls bfd_stat under the hood.  This will end
	    up using the system stat,

	  - In symfile.c we currently call stat directly, which will call the
	    gnulib stat, which, if I understand the above thread correctly,
	    might give a different result to the system stat in some cases,

	  - By switching to using bfd_stat in symfile.c we should now be
	    consistently calling the system stat.

	There is another issue that came up during testing that this commit
	fixes.  Consider this GDB session:

	  $ gdb -q
	  (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
	  Remote debugging using | ./gdbserver/gdbserver --multi --once -
	  Remote debugging using stdio
	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) set remote exec-file /tmp/hello.x
	  (gdb) start
	  ... snip ...
	  (gdb) load
	  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
	  Loading section .interp, size 0x1c lma 0x4002a8
	  ... snip ...
	  Start address 0x0000000000401050, load size 2004
	  Transfer rate: 326 KB/sec, 87 bytes/write.

	Notice this line:

	  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

	We actually see the same output, for the same reasons, when using a
	native target, like this:

	  $ gdb -q
	  (gdb) file /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) start
	  ... snip ...
	  (gdb) load
	  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
	  You can't do that when your target is `native'
	  (gdb)

	In both cases this line appears because load_command (symfile.c) calls
	reread_symbols, and reread_symbols loops over every currently loaded
	objfile and tries to check if the file has changed on disk by calling
	stat.

	However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory
	BFD, the filename for this BFD is literally the string
	'system-supplied DSO at 0x7ffff7fcf000'.

	Before this commit GDB would try to use the system 'stat' call to stat
	the file `system-supplied DSO at 0x7ffff7fcf000', which obviously
	fails; there's no file with that name (usually).  As a consequence of
	the stat failing GDB prints the ' .... has disappeared ...' line.

	Initially, all this commit did was switch from using 'stat' to using
	'bfd_stat'.  Calling bfd_stat on an in-memory BFD works just fine,
	however, BFD just fills the 'struct stat' buffer with zeros (except
	for the file size), see memory_bstat in bfd/bfdio.c.

	However, there is a bit of a weirdness about in-memory BFDs.  When
	they are initially created the libbfd caches an mtime within the bfd
	object, this is done in bfd_from_remote_memory (elfcode.h), the cached
	mtime is the time at which the in-memory BFD is created.

	What this means is that when GDB creates the in-memory BFD, and we
	call bfd_get_mtime(), the value returned, which GDB caches within
	objfile::mtime is the creation time of the in-memory BFD.  But, when
	this patch changes to use bfd_stat() we now get back 0, and so we
	believe that the in-memory BFD has changed.  This is a change in
	behaviour.

	To avoid this change in behaviour, in this commit, I propose that we
	always skip in-memory BFDs in reread_symbols.  This preserves the
	behaviour from before this commit -- mostly.

	As I'm not specifically checking for, and then skipping, in-memory
	BFDs, we no longer see this line:

	  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

	Which I think is an improvement.

	Co-Authored-By: Tom Tromey <tromey@adacore.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove print_sys_errmsg
	This started with me running into this comment in symfile.c:

	  /* FIXME, should use print_sys_errmsg but it's not filtered.  */
	  gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"),
	              styled_string (file_name_style.style (), filename));

	In this particular case I think I disagree with the comment; I think
	the output should be a warning rather than just a message printed to
	gdb_stdout, I think when the executable, or some other objfile that is
	currently being debugged, disappears from disk, this is likely an
	unexpected situation, and worth warning the user about.

	So, in theory, I could just call print_sys_errmsg and remove the
	comment, but that would mean loosing the filename styling in the
	output... so in the end I remove the comment and updated the code to
	call warning.

	But that got me looking at print_sys_errmsg and how it's used.

	Currently the function takes a string and an errno, and prints, to
	stderr, the string followed by the result of calling strerror on the
	errno.

	In some places the string passed to print_sys_errmsg is just a
	filename, and this is used when something goes wrong.  In these cases,
	I think calling warning rather than gdb_printf to gdb_stderr, would be
	better, and in fact, in a couple of places we manually print a
	"warning" prefix, and then call print_sys_errmsg.  And so, for these
	users I have added a new function warning_filename_and_errno, which
	takes a filename, which is printed with styling, and an errno, which
	is passed through strerror and the resulting string printed.  This new
	function calls warning to print its output.  I then updated some of
	the print_sys_errmsg users to use this new function.

	Some other users of print_sys_errmsg are also emitting what is clearly
	a warning, however, the string being passed in is more than just a
	filename, so the new warning_filename_and_errno function can't be
	used, it would style the whole string.  For these users I have
	switched to calling warning directly, this allows me to style the
	warning message correctly.

	Finally, in inflow.c there is one last call to print_sys_errmsg, in
	this case I just inlined the definition of print_sys_errmsg.  This is
	a really weird case, as after printing this message GDB just does a
	hard exit.  This is pretty old code, dating back to the initial GDB
	import, I guess it should be updated to call error() maybe, but I'm
	reluctant to make this change as part of this commit, just in case
	there's some reason why we can't throw an error at this point.

	With that done there are now no users of print_sys_errmsg, and so the
	old function can be removed.

	While I was doing all of the above I added some additional filename
	styling in soure.c, this is in an else block where the if contained
	the print_sys_errmsg call, so these felt related.

	And finally, while I was updating the uses of print_sys_errmsg in
	procfs.c, I noticed that we used a static errmsg buffer to format some
	error strings.  As the above changes got rid of one of the users of
	errmsg I also removed the other two users, and the static buffer.

	There were a couple of tests that depended on the existing output
	message format that needed updating.  In one case we gained an extra
	'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ',
	I think in both cases the new output is an improvement.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove use of a static buffer for building error strings
	I noticed in procfs.c that we use a static buffer for building error
	strings when we could easily use std::string and string_printf to
	achieve the same result, this commit does that.

	I ran into this while performing a further refactor/cleanup that will
	be presented in a later patch in this series, and thought this was
	worth splitting out into its own patch.

	As far as I can tell, only Solaris uses procfs.c, so I did a test
	build on a Solaris machine, and I don't believe that I've broken
	anything.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: use archive name in warning when appropriate
	While working on some other patch I noticed that in reread_symbols
	there is a diagnostic message that can be printed, and in some cases
	we might use the wrong filename in the message.

	The code in question is checking to see if an objfile has changed on
	disk, we do this by stat-ing the on disk file and checking the mtime.
	If this file has been removed from disk then we print a message that
	the file has been removed, however, if the objfile is within an
	archive then we stat the archive itself, but then warn that the
	component within the archive has disappeared.  I think it makes more
	sense to say that the archive has disappeared.

	The last related commit is this one:

	  commit 02aeec7bde8ec8a04d14a5637e75f1c6ab899e23
	  Date:   Tue Apr 27 21:01:30 2010 +0000

	      Check library name rather than member name when rereading symbols.

	Though this just makes the code to stat the archive unconditional, the
	code in question existed before this commit.

	However, the above commit doesn't include any tests, and seems to
	indicate that the problem being addressed was seen on Darwin.  I'm not
	sure how to setup a test where GDB is using an objfile from within an
	archive, and so there's no tests for this commit...

	... but if someone can let me know how I can setup a suitable test,
	please let me know and I'll try to get something working.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: some additional filename styling
	Fix up another couple of places where we can apply filename styling.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-05  A. Wilcox  <awilfox@adelielinux.org>

	Fix: ld testsuite: 'Version' pattern grabs 'Version5 EABI', breaking test on arm-linux-musleabihf
	  PR 30924
	  * testsuite/ld-elfvers/vers.exp (objdump_emptyverstuff): Handle EABI version information in objdump's output.

2023-10-05  Saurabh Jha  <saurabh.jha@arm.com>

	aarch64: Enable Cortex-X4 CPU

2023-10-05  Neal frager  <neal.frager@amd.com>

	microblaze: Add address extension instructions
	  * microblaze-opcm.h (struct op_code_struct): Tidy and remove redundant entries.
	  * microblaze-opc.h (MAX_OPCODES): Increase to 300. (op_code_struct): Add address extension instructions.

2023-10-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-04  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: XFAIL some gdb.base/fileio.exp
	Some gdb.base/fileio.exp tests expect the inferior to not have write
	access to some files. If the test is being run as root, this is never
	possible. This commit adds a way to identify if the user is root and
	xfails the tests that expect no write access.

	Approved-By: Tom de Vries <tdevries@suse.de>

2023-10-04  Neal Frager  <neal.frager@amd.com>

	ld: microblaze: ignore rwx segments
	The linker will generate warnings if it is creating an executable
	stack or a segment with all three read, write and execute permissions.
	These settings are not appropriate for all targets including
	MicroBlaze.

2023-10-04  Neal frager  <neal.frager@amd.com>

	opcodes: microblaze: Add hibernate and suspend instructions

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: Document SME2 registers and features
	Document changes introduced by gdb's SME2 support.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: Extend SME tests to include SME2
	Reusing the SME tests, this patch introduces additional tests to exercise
	reading/writing ZT0, availability of the register set, signal context reading
	for ZT0 and also core file generation.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: Core file support for ZT register set
	This patch adds support for ZT register dumps/reads for core files.  The
	ZT register is available when the SME2 feature is advertised as available
	by the Linux Kernel.

	Unlike the enablement for SME1 and the ZA register, support for SME2 is rather
	simple given the fixed size of the ZT0 register.

	Validated on the Fast Models.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: signal frame support
	Teach gdb about the ZT state on signal frames and how to restore
	the contents of the registers.

	There is a new ZT_MAGIC context that the Linux Kernel uses to communicate
	the ZT register state to gdb.

	As mentioned before, the ZT state should only be available when the ZA state
	is available.

	Validated under Fast Models.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: Enable SME2 support in gdbserver
	This patch teaches gdbserver about the SME2 and the ZT0 register.

	Since most of the code used by gdbserver for SME2 is shared with gdb, this
	is a rather small patch that reuses most of the code put in place for native
	AArch64 Linux.

	Validated under Fast Models.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme2: Enable SME2 for AArch64 gdb on Linux
	SME2 defines a new 512-bit register named ZT0, and it is only available
	if SME is also supported.  The ZT0 state is valid only if the SVCR ZA bit
	is enabled.  Otherwise its contents are empty (0).

	The target description is dynamic and gets generated at runtime based on the
	availability of the feature.

	Validated under Fast Models.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Document SME registers and features
	Provide documentation for the SME feature and other information that
	should be useful for users that need to debug a SME-capable target.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Add SVE/SME testcases
	Add 5 SVE/SME tests to exercise all the new features like reading/writing
	registers, pseudo-registers, signal frames and core files.

	- Sanity check for SME: Gives a brief smoke test to make sure the most basic
	of features are working correctly.

	- ZA unavailability tests: Validates the behavior/content of the ZA register
	is correct when no payload is available.  It also exercises changing the
	vector lengths.

	- ZA availability tests: These tests exercise reading/writing to all the
	possible ZA pseudo-registers, and validates the state is correct.

	- Core file tests: Validates that core file reading and writing works
	correctly and that all state dumped/loaded is sane.  This is exercised for
	both Linux Kernel core files and gcore core files.

	- Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD
	values across signal frames.

	Since some of these tests are very lengthy and take a little while to run
	(under QEMU at the moment), I decided to parallelize them into smaller
	chunks so we can throw some more CPU power at them so they run faster.

	I'd still like to add a few more tests to give the testsuite more coverage
	in the areas of SME/SVE.  Hopefully in the near future that will happen.

	Just a reminder that these SME tests are currently unsupported when gdb is
	connected to a remote target.  That's because the RSP doesn't support
	communicating changes in vector lenghts mid-execution, so gdb will always
	get wrong state from the remote target.

	Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Core file support for Linux
	This patch enables dumping SME state via gdb's gcore command and also
	enables gdb to read SME state from a core file generated by the Linux
	Kernel.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	corefile/bug: Add hook to control the use of target description notes from corefiles
	Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread
	can potentially have distinct target descriptions/gdbarches.

	When loading a gcore-generated core file, at the moment GDB gives priority
	to the target description dumped to NT_GDB_TDESC.  Though technically correct
	for most targets, it doesn't work correctly for AArch64 with SVE or SME
	support.

	The correct approach for AArch64/Linux is to either have per-thread target
	description notes in the corefiles or to rely on the
	gdbarch_core_read_description hook, so it can figure out the proper target
	description for a given thread based on the various available register notes.

	The former, although more correct, doesn't address the case of existing gdb's
	that only output a single target description note.

	This patch goes for the latter, and adds a new gdbarch hook to conditionalize
	the use of the corefile target description note. The hook is called
	use_target_description_from_corefile_notes.

	The hook defaults to returning true, meaning targets will use the corefile
	target description note.  AArch64 Linux overrides the hook to return false
	when it detects any of the SVE or SME register notes in the corefile.

	Otherwise it should be fine for AArch64 Linux to use the corefile target
	description note.

	When we support per-thread target description notes, then we can augment
	the AArch64 Linux hook to rely on those notes.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	corefile/bug: Use thread-specific gdbarch when dumping register state to core files
	When we have a core file generated by gdb (via the gcore command), gdb dumps
	the target description to a note.  During loading of that core file, gdb will
	first try to load that saved target description.

	This works fine for almost all architectures. But AArch64 has a few
	dynamically-generated target descriptions/gdbarch depending on the vector
	length that was in use at the time the core file was generated.

	The target description gdb dumps to the core file note is the one generated
	at the time of attachment/startup.  If, for example, the SVE vector length
	changed during execution, this would not reflect on the core file, as gdb
	would still dump the initial target description.

	Another issue is that the gdbarch potentially doesn't match the thread's
	real gdbarch, and so things like the register cache may have different formats
	and sizes.

	To address this, fetch the thread's architecture before dumping its register
	state.  That way we will always use the correct target description/gdbarch.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	Get rid of linux-core-thread-data
	This struct type seems to have been used in the past as a callback
	parameter.  Now it seems that case is no longer true, so we can simplify
	things by passing the individual parameters linux_core_thread_data
	encapsulates directly to the functions.

	This is just a cleanup before the next change.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Support TPIDR2 signal frame context
	The Linux Kernel defines a separate context for the TPIDR2 register in a
	signal frame.  Handle this additional context in gdb so this register
	gets restored properly when unwinding through signal frames.

	The TPIDR2 register is closely related to SME, and is available when SME
	support is reported.

	This is tested by testcases that are available in a later patch in the series.

	Regressions-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Fixup sigframe gdbarch when vg/svg changes
	With SME, where you have two different vector lengths (vl and svl), it may be
	the case that the current frame has a set of vector lengths (A) but the signal
	context has a distinct set of vector lengths (B).

	In this case, we may run into a situation where GDB attempts to use a gdbarch
	created for set A, but it is really dealing with a frame that was using set
	B.

	This is problematic, specially with SME, because now we have a different
	number of pseudo-registers and types that gets cached on creation of each
	gdbarch variation.

	For AArch64 we really need to be able to use the correct gdbarch for each
	frame, and I noticed the signal frame (tramp-frame) doesn't have a settable
	prev_arch field.  So it ends up using the default frame_unwind_arch function
	and eventually calling get_frame_arch (next_frame).  That means the previous
	frame will always have the same gdbarch as the current frame.

	This patch first refactors the AArch64/Linux signal context code, simplifying
	it and making it reusable for our purposes of calculating the previous frame's
	gdbarch.

	I introduced a struct that holds information that we have found in the signal
	context, and with which we can make various decisions.

	Finally, a small change to tramp-frame.c and tramp-frame.h to expose a
	prev_arch hook that the architecture can set.

	With this new field, AArch64/Linux can implement a hook that looks at the
	signal context and infers the gdbarch for the previous frame.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Signal frame support
	Teach gdb about the ZA/SSVE state on signal frames and how to restore
	the contents of the registers.

	There is a new ZA_MAGIC context that the Linux Kernel uses to communicate
	the ZA register state to gdb.

	The SVE_MAGIC context has also been adjusted to contain a flag indicating
	whether it is a SVE or SSVE state.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sve: Fix signal frame z/v register restore
	While doing some SME work, I ran into the situation where the Z register
	contents restored from a signal frame are incorrect if the signal frame
	only contains fpsimd state and no sve state.

	This happens because we only restore the v register values in that case,
	and don't do anything for the z registers.

	Fix this by initializing the z registers to 0 and then copying over the
	overlapping part of the v registers to the z registers.

	While at it, refactor the code a bit to simplify it and make it smaller.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Add support for SME
	Enable SME support in gdbserver by adjusting the usual fields.  There is
	not much to this patch because the code is either in gdb or it is shared
	between gdbserver and gdb.  One exception is the bump to gdbserver's
	PBUFSIZ from 18432 to 131104.

	Since the ZA register can be quite big (256 * 256 bytes), the g/G remote
	packet will also become quite big

	From gdbserver/tdesc.cc:init_target_desc, I estimated the new size should
	be at least (2 * 256 * 256 + 32), which yields 131104.

	It is also unlikely we will find a process starting up with SVL set to 256.

	Ideally we'd adjust the packet size dynamically based on what we need, but
	for now this should do.

	Please note we have the same limitation for SME that we have for SVE, and
	that is the fact gdbserver cannot communicate vector length changes to gdb
	via the remote protocol.

	Thiago is working on this improvement, which hopefully will be able to be
	adapted to SME in an easy way.

	Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	refactor: Adjust expedited registers dynamically
	Instead of using static arrays, build the list of expedited registers
	dynamically using a std::vector.

	This refactor shouldn't cause any user-visible changes.

	Regression-tested for aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	Convert tdesc's expedite_regs to a string vector
	Right now the list of expedited registers is stored as an array of char *,
	with a nullptr element at the end to signal its last element.

	Convert expedite_regs to a std::vector of std::string so it is easier to
	manage the elements and the storage is handled automatically.

	Eventually we might want to convert all the target functions so they pass a
	std::vector of std::string as well. Or maybe expose an interface that target can
	use to add expedited registers on-by-one depending on the target description
	discovery needs, as opposed to just a static list of char *.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sme: Enable SME registers and pseudo-registers
	The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with
	variable sizes.  It also exposes a new mode called streaming mode.

	Similarly to SVE, the ZA register size is dictated by a vector length, but the
	SME vector length is called streaming vetor length. The total size for
	ZA in a given moment is svl x svl.

	In streaming mode, the SVE registers have their sizes based on svl rather than
	the regular vector length (vl).

	The feature detection is controlled by the HWCAP2_SME bit, but actual support
	should be validated by attempting a ptrace call for one of the new register
	sets: NT_ARM_ZA and NT_ARM_SSVE.

	Due to its large size, the ZA register is exposed as a vector of bytes, but we
	introduce a number of pseudo-registers that gives various different views
	into the ZA contents. These can be arranged in a couple categories: tiles and
	tile slices.

	Tiles are matrices the same size or smaller than ZA.  Tile slices are vectors
	which map to ZA's rows/columns in different ways.

	A new dynamic target description is provided containing the ZA register, the SVG
	register and the SVCR register.  The size of ZA, like the SVE vector registers,
	is based on the vector length register SVG (VG for SVE).

	This patch enables SME register support for gdb.

	[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture

	Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	sve: Fix return command when using V registers in a SVE-enabled target
	In a target without SVE support, the V registers have a size of 16 bytes,
	otherwise they may have a size bigger than 16 bytes (depending on the current
	vector length for the Z registers, as they overlap the V registers).

	In aarch64-tdep.c:aarch64_store_return_value, the code is laid
	out in a way that allocates the buffer with the size of the register, but
	only updates the amount of bytes for the particular type we're returning.

	This may cause a situation where we have a register size of 32 bytes but
	are returning a floating point value of 8 bytes.  The temporary buffer
	will therefore have 32 bytes, but we'll only update 8 bytes of it.

	When we write the entire register back, it will have potentially 24 bytes
	of garbage in it.

	Fix this by first reading the original contents of the register and then
	overriding only the bytes that we need for the return value.

	Tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	refactor: Simplify SVE interface to read/write registers
	This is a patch in preparation to upcoming patches enabling SME support.  It
	attempts to simplify the gdb/gdbserver shared interface used to read/write
	SVE registers.

	Where the current code makes use of unique_ptr, allocating a new buffer by
	hand and passing a buffer around, this patch makes that code use
	gdb::byte_vector and passes a reference to this byte vector to the functions,
	allowing the functions to have ready access to the size of the buffer.

	It also shares a bit more code between gdb and gdbserver, in particular around
	handling of ptrace get/set requests for SVE.

	I think gdbserver could be refactored to handle register reads/writes more
	like gdb's native layer as opposed to letting the generic linux-low layer do
	the ptrace calls.  This is not very flexible and assumes one size for the
	responses.  If you have something like NT_ARM_SVE, where you can have either
	FPSIMD or SVE contents, it doesn't work that well.

	I didn't want to change that interface right now as it is a bit too much work
	and touches all the targets, some of which I can't easily test.

	Hence the reason why the buffer the generic linux-now passes down to
	linux-aarch64-low is unused or ignored.

	No user-visible changes should happen as part of this refactor other than a
	slightly reworded warning message.

	While doing the refactor, I also noticed what seems to be a mistake in checking
	if the register cache contains active (non-zero) SVE data.

	For instance, the original code did something like this in
	aarch64_sve_regs_copy_from_reg_buf:

	has_sve_state |= reg_buf->raw_compare (AARCH64_SVE_Z0_REGNUM + i
					       reg, sizeof (__int128_t));

	"reg" is a zeroed-out buffer that we compare the Z register contents
	past the first 128 bits.  The problem here is that raw_compare returns
	1 if the contents compare the same, which means has_sve_state will be
	true.  But if we compared the Z register contents to 0, it means we
	*do not* have SVE state, and therefore has_sve_state should be false.

	The consequence of this mistake is that we convert the initial
	FPSIMD-formatted data we get from ptrace for the NT_ARM_SVE register
	set to a SVE-formatted one.

	In the end, this doesn't cause user-visible differences because the
	values of both the Z and V registers will still be the same.  But the
	logic is not correct.

	I used the opportunity to fix this, and it gets tested later on by
	the additional SME tests.

	I do plan on submitting some SVE-specific tests to make sure we have
	a bit more coverage in GDB's testsuite.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	refactor: Rename SVE-specific files
	In preparation to the SME support patches, rename the SVE-specific files to
	something a bit more meaningful that can be shared with the SME code.

	In this case, I've renamed the "sve" in the names to "scalable".

	No functional changes.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Luis Machado  <luis.machado@arm.com>

	Fix register fetch/store order for native AArch64 Linux
	I noticed we don't handle register reads/writes in the best way for native
	AArch64 Linux.  Some other registers are fetched/stored even if upper level
	code told us to fetch a particular register number.

	Fix this by being more strict about which registers we touch when
	reading/writing them in the native AArch64 Linux layer.

	There should be no user-visible changes due to this patch.

	Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

	Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

2023-10-04  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: Refactor system register data
	This patch  moves instances of system register definitions, represented
	by the SYSREG macro, out of their original place in `aarch64-opc.c'
	and into a dedicated .def file, `aarch64-sys-regs.def'.

	System register entries in this new file are ordered alphabetically by
	name.  This choice is made to enable the use of fast search algorithms
	such as binary search when validating register names.

	The SYSREG macro, defined as SYSREG (name, encoding, flags, features)
	is kept as is and used in the def file, but all other SR_* macros
	which previously served as indirections to SYSREG are removed.

	opcodes/ChangeLog:
		* aarch64-opc.c (SR_CORE): Macro definition and uses deleted.
		(SR_FEAT): Likewise.
		(SR_FEAT2): Likewise.
		(SR_V8_1_A): Likewise.
		(SR_V8_4_A): Likewise.
		(SR_V8A): Likewise.
		(SR_V8R): Likewise.
		(SR_V8_1A): Likewise.
		(SR_V8_2A): Likewise.
		(SR_V8_3A): Likewise.
		(SR_V8_4A): Likewise.
		(SR_V8_6A): Likewise.
		(SR_V8_7A): Likewise.
		(SR_V8_8A): Likewise.
		(SR_GIC): Likewise.
		(SR_AMU): Likewise.
		(SR_LOR): Likewise.
		(SR_PAN): Likewise.
		(SR_RAS): Likewise.
		(SR_RNG): Likewise.
		(SR_SME): Likewise.
		(SR_SSBS): Likewise.
		(SR_SVE): Likewise.
		(SR_ID_PFR2): Likewise.
		(SR_PROFILE): Likewise.
		(SR_MEMTAG): Likewise.
		(SR_SCXTNUM): Likewise.
		(SR_EXPAND_ELx): Likewise.
		(SR_EXPAND_EL12): Likewise.
		* opcodes/aarch64-sys-regs.def: New.

2023-10-04  Victor Do Nascimento  <victor.donascimento@arm.com>

	aarch64: system register aliasing detection
	This patch adds a mechanism for system register name alias detection
	to register-matching mechanisms.

	A new `F_REG_ALIAS' flag is added to the set of register flags and
	used to label which entries in aarch64_sys_regs[] correspond to
	aliases (and thus which CPENC values are non-unique in this array).

	Where this is used is, for example, in `aarch64_print_operand' where,
	in the case of system register decoding, the aarch64_sys_regs[] array
	is iterated through until a match in CPENC value is made and the first
	match accepted.  If insufficient care is given in the ordering of
	system registers in this array, the alias is encountered before the
	"real" register and used incorrectly as the register name in the
	disassembled output.

	With this flag and the new `aarch64_sys_reg_alias_p' test, search
	candidates corresponding to aliases can be conveniently skipped over.

	One concrete example of where this is useful is with the
	`trcextinselr0' system register.  It was initially placed in the
	system register list before `trcextinselr', in contrast to a more
	natural alphabetical order.

	include/ChangeLog:
		* opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype.

	opcodes/ChangeLog:
		* aarch64-opc.c (aarch64_sys_reg_alias_p): New.
		(aarch64_print_operand): add aarch64_sys_reg_alias_p check.
		(aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr"
		entry.
		* aarch64-opc.h (F_REG_ALIAS): New.

2023-10-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/corefile: write NT_GDB_TDESC based on signalled thread
	When creating a core file from within GDB we include a NT_GDB_TDESC
	that includes the target description of the architecture in use.

	For architectures with dynamic architectures (e.g. AArch64 with
	sve/sme) the original architecture, calculated from the original
	target description, might not match the per-thread architecture.

	In the general case, where each thread has a different architecture,
	then we really need a separate NT_GDB_TDESC for each thread, however,
	there's currently no way to read in multiple NT_GDB_TDESC.

	This commit is a step towards per-thread NT_GDB_TDESC.  In this commit
	I have updated the function that writes the NT_GDB_TDESC to accept a
	gdbarch (rather than calling target_gdbarch() to find a gdbarch), and
	I now pass in the gdbarch of the signalled thread.

	In many cases (though NOT all) targets with dynamic architectures
	really only use a single architecture, even when there are multiple
	threads, so in the common case, this should ensure that GDB emits an
	architecture that is more likely to be correct.

	Additional work will be needed in order to support corefiles with
	truly per-thread architectures, but that will need to be done in the
	future.

2023-10-03  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Fix `readelf -S bintest' test for n64 targets
	Add a 64-bit traditional MIPS dump variant for the `readelf -S bintest'
	test from binutils-all/readelf.exp, using a filename suffix according to
	the rules set there, removing:

	FAIL: readelf -S bintest

	regressions with `mips64-linux-gnuabi64', `mips64el-linux-gnuabi64',
	`mips64-openbsd', and `mips64el-openbsd' targets, which default to the
	n64 ABI and consequently produce a section layout that is different from
	what the generic dump pattern covers.

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		binutils/
		* testsuite/binutils-all/readelf.s-64-tmips: New test variant.

2023-10-03  Vsevolod Alekseyev  <sevaa@sprynet.com>

	Fix: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
	  PR 29267
	  * dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation. (read_and_display_attr_value): Replace uses of fetch_indexed_value with fetch_indexed_offset.

2023-10-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-02  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: reformat file with black
	Reformat a Python file with black after this commit:

	  commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
	  Date:   Tue Sep 19 11:45:36 2023 +0100

	      gdb: add Python events for program space addition and removal

	There should be no functional change with this commit.

2023-10-02  Tom Tromey  <tromey@adacore.com>

	Add regression test for instructionReference change
	Yesterday I pushed a patch to fix a small oversight in the DAP code
	that caused an instructionReference to be an array instead of a
	string.

	This patch adds a test case for that regression.  This required
	exposing the TON form of the response -- something I mentioned might
	be necessary when this code was changed to return just the Tcl form.

	I tested this by backing out yesterday's bug fix and verifying that a
	failure is seen.

2023-10-02  Tom Tromey  <tromey@adacore.com>

	Clean up intermediate values in val_print_packed_array_elements
	Following on Tom de Vries' work in the other array-printers, this
	patch changes val_print_packed_array_elements to also avoid allocating
	too many values when printing an Ada packed array.

2023-10-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: accept variable number of spaces in gdb.base/jit-reader-simple.exp regex
	I see this failure:

	    FAIL: gdb.base/jit-reader-simple.exp: standalone: change addr: initial run: maint info breakpoints shows jit breakpoint

	The jit breakpoint expected by the test is there, it's just that the
	number of spaces doesn't match what the test expects, after "jit
	events":

	    -2      jit events       keep y   0x0000555555555119 <__jit_debug_register_code> inf 1

	Fix that by relaxing the regex a bit.

	Change-Id: Ia3b04e6d5978399d940fd1a590f95f15275ca7ac

2023-10-02  Aaron Merey  <amerey@redhat.com>

	gdb: Add command 'maint set/show debuginfod download-sections'
	This setting controls whether GDB may attempt to download ELF/DWARF
	sections from debuginfod servers.

	This setting is enabled by default if gdb is built with debuginfod
	section download support (requires libdebuginfod 0.188).

	Also update debuginfod command help text and gdb.texinfo with
	information on section downloading and the new command.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-02  Aaron Merey  <amerey@redhat.com>

	gdb/debuginfod: Add debuginfod_section_query
	Add new function debuginfod_section_query.  This function queries
	debuginfod servers for an individual ELF/DWARF section associated with
	a given build-id.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-10-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle older gcc in gdb.ada/import.exp
	When running test-case gdb.ada/import.exp with gcc 7, most test fail:
	...
	FAIL: gdb.ada/import.exp: print imported_var_ada
	FAIL: gdb.ada/import.exp: print local_imported_var
	FAIL: gdb.ada/import.exp: print pkg.imported_var_ada
	FAIL: gdb.ada/import.exp: print pkg.exported_var_ada
	FAIL: gdb.ada/import.exp: print exported_var_ada
	FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
	FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
	FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func
	...

	When running with gcc 8 or 9, only 2 tests fail:
	...
	FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
	FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
	...

	The test-case passes fully with gcc 10, 11, 12 and 13.

	Debug info for pragma import seems to not have been supported before gcc 8, so
	require that version.

	The two FAILs with gcc 8 and 9 seem to be due to problems in debug info.  Add
	an xfail for these.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add KFAIL for PR ada/30908
	With gcc 13.2.1, I run into a cluster of fails:
	...
	FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD"
	FAIL: gdb.ada/widewide.exp: print my_wws = " helo"
	FAIL: gdb.ada/widewide.exp: print my_ws = "wide"
	...

	The problem is that the debug info contains information about function
	ada.strings.maps."=", and gdb uses it to implement the comparison.
	The function is supposed to compare two char sets, not strings, so gdb
	shouldn't use it.  This is PR ada/30908.

	I don't see the same problem with gcc 7.5.0, because the exec doesn't contain
	the debug info for the function, because the corresponding object is not
	linked in.  Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to
	gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0.

	Add KFAILs for the PR.

	Tested on x86_64-linux:
	- openSUSE Leap 15.4 (using gcc 7.5.0), and
	- openSUSE Tumbleweed (using gcc 13.2.1).

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908

2023-10-02  Andrew Burgess  <aburgess@redhat.com>

	gdb: add Python events for program space addition and removal
	Initially I just wanted a Python event for when GDB removes a program
	space, I'm writing a Python extension that caches information for each
	program space, and need to know when I should discard entries for a
	particular program space.

	But, it seemed easy enough to also add an event for when GDB adds a
	new program space, so I went ahead and added both new events.

	Of course, we don't currently have an observable for program space
	addition or removal, so I first needed to add these.  After that it's
	pretty simple to add two new Python events and have these trigger.

	The two new event registries are:

	  events.new_progspace
	  events.free_progspace

	These emit NewProgspaceEvent and FreeProgspaceEvent objects
	respectively, each of these new event types has a 'progspace'
	attribute that contains the relevant gdb.Progspace object.

	There's a couple of things to be mindful of.

	First, it is not possible to catch the NewProgspaceEvent for the very
	first program space, the one that is created when GDB first starts, as
	this program space is created before any Python scripts are sourced.

	In order to allow this event to be caught we would need to defer
	creating the first program space, and as a consequence the first
	inferior, until some later time.  But, existing scripts could easily
	depend on there being an initial inferior, so I really don't think we
	should change that -- and so, we end up with the consequence that we
	can't catch the event for the first program space.

	The second, I think minor, issue, is that GDB doesn't clean up its
	program spaces upon exit -- or at least, they are not cleaned up
	before Python is shut down.  As a result, any program spaces in use at
	the time GDB exits don't generate a FreeProgspaceEvent.  I'm not
	particularly worried about this for my use case, I'm using the event
	to ensure that a cache doesn't hold stale entries within a single GDB
	session.  It's also easy enough to add a Python at-exit callback which
	can do any final cleanup if needed.

	Finally, when testing, I did hit a slightly weird issue with some of
	the remote boards (e.g. remote-stdio-gdbserver).  As a consequence of
	this issue I see some output like this in the gdb.log:

	  (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
	  step
	  FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10>
	  warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
	  Use the "interrupt" command to stop the target
	  and then try again.
	  warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running.
	  Use the "interrupt" command to stop the target
	  and then try again.
	  warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running.
	  Use the "interrupt" command to stop the target
	  and then try again.
	  do_parent_stuff () at py-progspace-events.c:41
	  41        ++global_var;
	  (gdb) PASS: gdb.python/py-progspace-events.exp: step

	The 'FreeProgspaceEvent ...' line is expected, that's my test Python
	extension logging the event.  What isn't expected are all the blocks
	like:

	  warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
	  Use the "interrupt" command to stop the target
	  and then try again.

	It turns out that this has nothing to do with my changes, this is just
	a consequence of reading files over the remote protocol.  The test
	forks a child process which GDB stays attached too.  When the child
	exits, GDB cleans up by calling prune_inferiors, which in turn can
	result in GDB trying to close some files that are open because of the
	inferior being deleted.

	If the prune_inferiors call occurs when the remote target is
	running (and in non-async mode) then GDB will try to send a fileio
	packet while the remote target is waiting for a stop reply, and the
	remote target will throw an error, see remote_target::putpkt_binary in
	remote.c for details.

	I'm going to look at fixing this, but, as I said, this is nothing to
	do with this change, I just mention it because I ended up needing to
	account for these warning messages in one of my tests, and it all
	looks a bit weird.

	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-10-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove solib::pspace field
	This backlink is not necessary, we always know the program space from
	the context.  Pass it down the solib_unloaded observer.

	Change-Id: I45a503472dc791f517558b8141901472634e0556
	Approved-By: Tom Tromey <tom@tromey.com>

2023-10-02  Nick Clifton  <nickc@redhat.com>

	Fix memory leak in RiscV assembler.
	  PR 30861
	  * config/tc-riscv.c (riscv_insert_uleb128_fixes): Release duplicated memory.

	Use bfd_get_current_time in places where it is suitable

2023-10-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-10-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-29  Tom Tromey  <tom@tromey.com>

	Support the NO_COLOR environment variable
	I ran across this site:

	    https://no-color.org/

	... which lobbies for tools to recognize the NO_COLOR environment
	variable and disable any terminal styling when it is seen.

	This patch implements this for gdb.

	Regression tested on x86-64 Fedora 38.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-09-29  Neal Frager  <neal.frager@amd.com>

	tc-microblaze.c - int compare for X_add_number.
	The range check should be checking for the range
	ffffffff80000000..7fffffff, not ffffffff70000000.

	This patch has been tested for years of AMD Xilinx Yocto
	releases as part of the following patch set:

	https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

2023-09-29  Neal Frager  <neal.frager@amd.com>

	bfd: microblaze: Fix bug in TLSTPREL Relocation
	Fixed the problem related to the fixup/relocations TLSTPREL.
	When the fixup is applied the addend is not added at the correct offset
	of the instruction. The offset is hard coded considering its big endian
	and it fails for Little endian. This patch allows support for both
	big & little-endian compilers.

	This patch has been tested for years of AMD Xilinx Yocto
	releases as part of the following patch set:

	https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

2023-09-29  H.J. Lu  <hjl.tools@gmail.com>

	x86-64: Add -z mark-plt and -z nomark-plt
	The PLT entry in executables and shared libraries contains an indirect
	branch, like

	 	jmp *foo@GOTPCREL(%rip)
		push $index_foo
		jmp .PLT0

	or

		endbr64
	 	jmp *foo@GOTPCREL(%rip)
	 	NOP padding

	which is used to branch to the function, foo, defined in another object.
	Each R_X86_64_JUMP_SLOT relocation has a corresponding PLT entry.

	The dynamic tags have been added to the x86-64 psABI to mark such PLT
	entries:

	https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6d824a52a42d173eb838b879616c1be5870b593e

	Add an x86-64 linker option, -z mark-plt, to mark PLT entries with

	 #define DT_X86_64_PLT     (DT_LOPROC + 0)
	 #define DT_X86_64_PLTSZ   (DT_LOPROC + 1)
	 #define DT_X86_64_PLTENT  (DT_LOPROC + 3)

	1. DT_X86_64_PLT: The address of the procedure linkage table.
	2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage
	table.
	3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table
	entry.

	and set the r_addend field of the R_X86_64_JUMP_SLOT relocation to the
	memory offset of the indirect branch instruction.  The dynamic linker
	can use these tags to update the PLT section to direct branch.

	bfd/

		* elf-linker-x86.h (elf_linker_x86_params): Add mark_plt.
		* elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Set the
		r_addend of R_X86_64_JUMP_SLOT to the indirect branch offset
		in PLT entry for -z mark-plt.
		* elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Add
		DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT for
		-z mark-plt.
		(_bfd_x86_elf_finish_dynamic_sections): Set DT_X86_64_PLT,
		DT_X86_64_PLTSZ and DT_X86_64_PLTENT.
		(_bfd_x86_elf_get_synthetic_symtab): Ignore addend for
		JUMP_SLOT relocation.
		(_bfd_x86_elf_link_setup_gnu_properties): Set
		plt_indirect_branch_offset.
		* elfxx-x86.h (elf_x86_plt_layout): Add plt_indirect_branch_offset.

	binutils/

		* readelf.c (get_x86_64_dynamic_type): New function.
		(get_dynamic_type): Call get_x86_64_dynamic_type.

	include/

		* elf/x86-64.h (DT_X86_64_PLT): New.
		(DT_X86_64_PLTSZ): Likewise.
		(DT_X86_64_PLTENT): Likewise.

	ld/

		* ld.texi: Document -z mark-plt and -z nomark-plt.
		* emulparams/elf32_x86_64.sh: Source x86-64-plt.sh.
		* emulparams/elf_x86_64.sh: Likewise.
		* emulparams/x86-64-plt.sh: New file.
		* testsuite/ld-x86-64/mark-plt-1.s: Likewise.
		* testsuite/ld-x86-64/mark-plt-1a-x32.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1a.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1b-x32.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1b.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1c-x32.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1c.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise.
		* testsuite/ld-x86-64/mark-plt-1d.d: Likewise.
		* testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt tests.

2023-09-29  Nick Clifton  <nickc@redhat.com>

	Fix: Segmentation fault caused by npd in objdump
	  PR 30906
	  * elf.c (_bfd_elf_slurp_version_tables): Test that the verref section header has been initialised before using it.

	Update README file's installation instructions

2023-09-29  Sam James  <sam@gentoo.org>

	gdb: add Sam James to MAINTAINERS
	Acked-by: Tom de Vries <tdevries@suse.de>

2023-09-29  Kevin Buettner  <kevinb@redhat.com>

	gdb/testsuite: Add relative versus absolute LD_LIBRARY_PATH test
	At one time, circa 2006, there was a bug, which was presumably fixed
	without adding a test case:

	    If you provided some relative path to the shared library, such as
	    with

		export LD_LIBRARY_PATH=.

	    then gdb would fail to match the shared library name during the
	    TLS lookup.

	I think there may have been a bit more to it than is provided by that
	explanation, since the test also takes care to split the debug info
	into a separate file.

	In any case, this commit is based on one of Red Hat's really old
	local patches.  I've attempted to update it and remove a fair amount
	of cruft, hopefully without losing any critical elements from the
	test.

	Testing on Fedora 38 (correctly) shows 1 unsupported test for
	native-gdbserver and 5 PASSes for the native target as well as
	native-extended-gdbserver.

	In his review of v1 of this patch, Lancelot SIX observed that
	'thread_local' could be used in place of '__thread' in the C source
	files.  But it only became available via the standard in C11, so I
	used additional_flags=-std=c11 for compiling both the shared object
	and the main program.

	Also, while testing with CC_FOR_TARGET=clang, I found that
	'additional_flags=-Wl,-soname=${binsharedbase}' caused clang
	to complain that this linker flag was unused when compiling
	the source file, so I moved this linker option to 'ldflags='.

	My testing for this v2 patch shows the same results as with v1,
	but I've done additional testing with CC_FOR_TARGET=clang as
	well.  The results are the same as when gcc is used.

	Co-Authored-by: Jan Kratochvil <jan@jankratochvil.net>
	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove nbsd_{ilp32,lp64}_solib_svr4_fetch_link_map_offsets
	They are unused.

	Change-Id: I9b78837d41126ce1957aa1e8b08c82a422f06cbf
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-09-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unused imports in solib*.[ch]
	I'm starting to work on these files, I thought it would be a good time
	to remove unused imports.  These were identified by
	include-what-you-use.  Tested by rebuilding.

	Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-09-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-28  Michael J. Eager  <eager@eagercon.com>

	Added support in gas for mlittle-endian and mbig-endian flags as options.
	Updated show usage for MicroBlaze specific assembler options
	to include new entries.

	This patch has been tested for years of AMD Xilinx Yocto
	releases as part of the following patch set:

	https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils


	---
	V1->V2:
	 - removed new options which were unnecessary
	 - added documentation for MicroBlaze specific options

2023-09-28  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix segfault in tui_find_disassembly_address
	PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
	and target board unix/-m32.

	The FAIL happens due to the test executable running into an assert, which is
	caused by a forked child segfaulting, like so:
	...
	 Program terminated with signal SIGSEGV, Segmentation fault.
	 #0  0x00000000 in ?? ()
	...

	I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
	TUI layout asm.

	I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
	following session I ran into a gdb segfault here in
	tui_find_disassembly_address:
	...
		  /* Disassemble forward.  */
		  next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
		  last_addr = asm_lines.back ().addr;
	...
	due to asm_lines being empty after the call to tui_disassemble, while
	asm_lines.back () assumes that it's not empty.

	I have not been able to reproduce that segfault in that original setting, I'm
	not sure of the exact scenario (though looking back it probably involved
	"set detach-on-fork off").

	What likely happened is that I managed to reproduce PR29040, and TUI (attempted
	to) display the disassembly for address 0, which led to the gdb segfault.

	When gdb_print_insn encounters an insn it cannot print because it can't read
	the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.

	The specific bit that causes the gdb segfault is that if gdb_print_insn throws
	a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
	asm_lines.

	FWIW, I did manage to reproduce the gdb segfault as follows:
	...
	$ gdb -q \
	    -iex "set pagination off" \
	    /usr/bin/rustc \
	    -ex "set breakpoint pending on" \
	    -ex "b dl_main" \
	    -ex run \
	    -ex "up 4" \
	    -ex "layout asm" \
	    -ex "print \$pc"
	  ...
	<TUI>
	  ...
	$1 = (void (*)()) 0x1
	(gdb)
	...
	Now press <up>, and the segfault triggers.

	Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
	tui_find_disassembly_address.

	I've written a unit test that exercises this scenario.

	Tested on x86_64-linux.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

	PR tui/30823
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Remove old gdb_bfd_openr_iovec
	This removes the old gdb_bfd_openr_iovec entirely.  I think any new
	code should use the type-safe approach.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Convert solib-rocm to new type-safe gdb_bfd_openr_iovec
	This converts the solib-rocm BFD iovec implementations to the new
	type-safe gdb_bfd_openr_iovec.  They were already essentially using
	this approach, just without the type-safe wrapper.

	Thanks to Lancelot Six for testing and fixing this patch.

	Co-Authored-By: Lancelot Six <lancelot.six@amd.com>
	Acked-by: Lancelot Six <lancelot.six@amd.com>
	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Convert minidebug to new type-safe gdb_bfd_openr_iovec
	This converts the minidebug BFD iovec implementation to the new
	type-safe gdb_bfd_openr_iovec.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Convert target fileio to new type-safe gdb_bfd_openr_iovec
	This converts the target fileio BFD iovec implementation to use the
	new type-safe gdb_bfd_openr_iovec.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Convert mem_bfd_iovec to new type-safe gdb_bfd_openr_iovec
	This converts the mem_bfd_iovec / target_buffer code to use the new
	type-safe gdb_bfd_openr_iovec.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Small constructor change to target_buffer
	This changes the target_buffer constructor to initialize m_filename
	rather than assign to it.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Tom Tromey  <tromey@adacore.com>

	Introduce type-safe variant of gdb_bfd_openr_iovec
	This patch adds a new, type-safe variant of gdb_bfd_openr_iovec.  In
	this approach, the underlying user data is simply an object, the
	callbacks are methods, and the "open" function is a function view.
	Nothing uses this new code yet.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: use reopen_exec_file from reread_symbols
	This commit fixes an issue that was discovered while writing the tests
	for the previous commit.

	I noticed that, when GDB restarts an inferior, the executable_changed
	event would trigger twice.  The first notification would originate
	from:

	  #0  exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
	  #1  0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122
	  #2  0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682
	  #3  0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192
	  #4  0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125
	  #5  0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609
	  #6  0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761
	  #7  0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593
	  #8  0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924
	  #9  0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328
	  #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381
	  #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
	  #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

	While the second originates from:

	  #0  exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
	  #1  0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517
	  #2  0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398
	  #3  0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
	  #4  0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

	In the first case the call to exec_file_attach first passes through
	reopen_exec_file.  The reopen_exec_file performs a modification time
	check on the executable file, and only calls exec_file_attach if the
	executable has changed on disk since it was last loaded.

	However, in the second case things work a little differently.  In this
	case GDB is really trying to reread the debug symbol.  As such, we
	iterate over the objfiles list, and for each of those we check the
	modification time, if the file on disk has changed then we reload the
	debug symbols from that file.

	However, there is an additional check, if the objfile has the same
	name as the executable then we will call exec_file_attach, but we do
	so without checking the cached modification time that indicates when
	the executable was last reloaded, as a result, we reload the
	executable twice.

	In this commit I propose that reread_symbols be changed to
	unconditionally call reopen_exec_file before performing the objfile
	iteration.  This will ensure that, if the executable has changed, then
	the executable will be reloaded, however, if the executable has
	already been recently reloaded, we will not reload it for a second
	time.

	After handling the executable, GDB can then iterate over the objfiles
	list and reload them in the normal way.

	With this done I now see the executable reloaded only once when GDB
	restarts an inferior, which means I can remove the kfail that I added
	to the gdb.python/py-exec-file.exp test in the previous commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: make the executable_changed event available from Python
	This commit makes the executable_changed observable available through
	the Python API as an event.  There's nothing particularly interesting
	going on here, it just follows the same pattern as many of the other
	Python events we support.

	The new event registry is called events.executable_changed, and this
	emits an ExecutableChangedEvent object which has two attributes, a
	gdb.Progspace called 'progspace', this is the program space in which
	the executable changed, and a Boolean called 'reload', which is True
	if the same executable changed on disk and has been reloaded, or is
	False when a new executable has been loaded.

	One interesting thing did come up during testing though, you'll notice
	the test contains a setup_kfail call.  During testing I observed that
	the executable_changed event would trigger twice when GDB restarted an
	inferior.  However, the ExecutableChangedEvent object is identical for
	both calls, so the wrong information is never sent out, we just see
	one too many events.

	I tracked this down to how the reload_symbols function (symfile.c)
	takes care to also reload the executable, however, I've split fixing
	this into a separate commit, so see the next commit for details.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: pass more arguments to the executable_changed observer
	This commit continues the work of the previous few commits.

	My goal is to expose the executable_changed observer through the
	Python API as an event.

	At this point adding executable_changed as an event to the Python API
	is trivial, but before I do that I would like to add some additional
	arguments to the observable, which currently has no arguments at all.

	The new arguments I wish to add are:

	 1. The program_space in which the executable was changed, and

	 2. A boolean flag that will indicate if the executable changed to a
	 whole new path, or if GDB just spotted that the executable changed on
	 disk (e.g. the user recompiled the executable).

	In this commit I change the signature of the observable and then pass
	the arguments through at the one place where this observable is
	notified.

	As there are (currently) no users of this observable nothing else
	needs updating.  In the next commit I'll add a listener for this
	observable in the Python code, and expose this as an event in the
	Python API.

	Additionally, with this change, it should be possible to update the
	insight debugger to make use of this observable rather than using the
	deprecated_exec_file_display_hook (as it currently does), which will
	then allow this hook to be removed from GDB.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove unnecessary notification of executable_changed observer
	This commit continues the work of the previous two commits.

	My goal, in the next couple of commits, is to expose the
	executable_changed observable in the Python API as an event.  However,
	before I do that I want to remove the use of the executable_changed
	observable from the reread_symbols function in symfile.c as this use
	isn't directly associated with a change of the executable file, and so
	seems wrong.

	In the previous two commits I have removed all users of the
	executable_changed observer as I believe those users can, and should,
	actually be listening for the new_objfile observable instead, so now
	there are no users of the executable_changed observable.

	As such, I think removing the use of executable_changed from the
	function reread_symbols is perfectly safe, and correct.  At this point
	the executable has not been changed, so we shouldn't be sending an
	executable_changed notification, and, as there is nobody listening to
	this observable, we can't break anything by removing this call.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove final user of the executable_changed observer
	This commit continues with the task started in the previous commit,
	and is similar in many ways.

	The goal of the next couple of commits is to expose the
	executable_changed observable in the Python API as an event.  Before I
	do this I would like to remove the additional call to the
	executable_changed observable which can be found in the reread_symbols
	function in the symfile.c file, as I don't believe that this use
	actually corresponds to a change in the current executable.

	The previous commit removed one user of the executable_changed
	observable and replaced it with a new_obfile observer instead, and
	this commit does the same thing.

	In auxv.c we use the executable_changed observable to call
	invalidate_auxv_cache, which then calls:

	  invalidate_auxv_cache_inf (current_inferior ());

	The auxv cache is already (additionally) cleared when an inferior
	exits and when an inferior appears.

	As with the previous commit, I think we can safely replace the use of
	the executable_changed observable with a use of the new_obfile
	observable.  All the tests still pass, and with some locally placed
	printf calls, I think that the cache is still being cleared in all the
	cases that should matter.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove one user of the executable changed observer
	My goal for the next few commits is to expose the executable_changed
	observable from the Python API.

	However, there is call to the executable_changed observable in the
	reread_symbols function (in symfile.c), and this doesn't actually
	correspond to the executable changing.  My idea then, is to remove
	this use of the executable_changed observable, but, before I can do
	that, I need to check that nothing is going to break, and that
	requires my to think about the current users of this observable.

	One current user of executable_changed is in symtab.c.  We add an
	executable_changed observer that calls:

	  set_main_name (nullptr, language_unknown);

	to discard all information about the main function when the executable
	changes.

	However, changing the executable doesn't actually change the debug
	information.  The debug information changes when the symbol-file
	changes, so I think this observer is in slightly the wrong place.

	The new_objfile observable is (unfortunately) overloaded, it is called
	when a new objfile is loaded, and also (when its argument is nullptr),
	when all debug information should be discarded.

	It turns out that there is already a new_objfile observer in
	symtab.c.  I propose that, when the argument is nullptr (indicating
	all debug info should be discarded), that we should call set_main_name
	to discard the information about the main function.  We can then
	remove the executable_changed observer from symtab.c.

	All tests still pass, and, in my local world, I added some debug
	printf calls, and I think we are still discarded the main information
	everywhere we need to.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: new Progspace.executable_filename attribute
	Add a new Progspace.executable_filename attribute that contains the
	path to the executable for this program space, or None if no
	executable is set.

	The path within this attribute will be set by the "exec-file" and/or
	"file" commands.

	Accessing this attribute for an invalid program space will raise an
	exception.

	This new attribute is similar too, but not the same as the existing
	gdb.Progspace.filename attribute.  If I could change the past, I'd
	change the 'filename' attribute to 'symbol_filename', which is what it
	actually represents.  The old attribute will be set by the
	'symbol-file' command, while the new attribute is set by the
	'exec-file' command.  Obviously the 'file' command sets both of these
	attributes.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: new Progspace.symbol_file attribute
	Add a new Progspace.symbol_file attribute.  This attribute holds the
	gdb.Objfile object that corresponds to Progspace.filename, or None if
	there is no main symbol file currently set.

	Currently, to get this gdb.Objfile, a user would need to use
	Progspace.objfiles, and then search for the objfile with a name that
	matches Progspace.filename -- which should work just fine, but having
	direct access seems a little nicer.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: extend the description for Progspace.filename
	Extend the description for Progspace.filename in the documentation to
	mention what the returned string is actually the filename
	for (e.g. that it is the filename passed to the 'symbol-file' or
	'file' command).

	Also document that this attribute will be None if no symbol file is
	currently loaded.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-28  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/x86: use size of XSAVE area of enabled features
	Since commit b42405a1594 ("gdb: Update x86 Linux architectures to
	support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD
	Ryzen 3700X machine:

	    FAIL: gdb.base/gcore.exp: corefile restored all registers

	The test gets the register state (saves the output of "info
	all-registers"), saves a core with the "gcore" command, loads the core,
	and checks the register state against the one previously saved.  The
	problem is that when reading registers from the core file, the last half
	of ymm registers is unavailable:

	    (gdb) print $ymm0.v32_int8
	    $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, <unavailable> <repeats 16 times>}

	One strange thing with this machine is that the bitset of state
	components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU",
	but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX".  So, PKRU appears
	to be supported by the processor, but disabled by the kernel.  I didn't
	find why yet.

	From CPUID leaf EAX=0Dh, ECX=00h, GDB can get:

	 - from EBX: max size of the XSAVE area required by features currently
	   enabled in XCR0.  On my machine, it's 0x340 (832).
	 - from ECX: max size of the XSAVE area required by all features
	   supported by XCR0.  On my machine, it's 0x380 (896).

	At runtime, GDB uses ECX (max size required by all supported features)
	to fill the x86_xsave_layout::sizeof_xsave.  So, when writing the core
	file note for the XSAVE state, it writes a note of size 896, even though
	it doesn't write the PKRU state.  When loading back the core, GDB tries
	to figure out the layout of the XSAVE area based on what features are
	enabled in XCR0 and the size of the note (the size of the XSAVE area).
	Since my combination of XCR0 and size of XSAVE area doesn't match any
	combination known by GDB, GDB falls back to a gdbarch supporting only
	x87 and SSE.

	This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave
	field (and consequently the size of the XSAVE state note in core files)
	using EBX, the size of the XSAVE area required by currently enabled
	features in XCR0.  This makes i387_guess_xsave_layout recognize my case
	with this condition:

	  else if (HAS_AVX (xcr0) && xsave_size == 832)
	    {
	      /* Intel and AMD CPUs supporting AVX.  */
	      layout.avx_offset = 576;
	    }

	In other words, just as if my machine didn't support PKRU at all.

	Another reason why I think this change makes sense is that XSAVE state
	notes in kernel-generated cores on this machine have size 832.  So this
	change makes GDB-generated cores more similar to kernel-generated ones,
	reducing the diversity of XSAVE state notes that GDB needs to be able to
	figure out.

	Note that if PKRU was enabled on my machine, then the effective XSAVE
	area size would be 896 bytes.  We would need to add a case in
	i387_guess_xsave_layout for that combination, since there is no
	currently.  But I don't have a way to test that right now, since I don't
	know why PKRU is disabled.

	Relevant review note from John Baldwin:

	  One further note is that the Linux x86 arches use x86_xsave_length()
	  to infer ("guess") the size of the XSAVE register set that the Linux
	  kernel writes out in core dumps.  On FreeBSD x86 arches, GDB is able
	  to query this size directly from the kernel via ptrace.  My use of ECX
	  for this guess earlier was just not the best guess.  In the case that
	  the kernel enables all of the available features, then ECX and EBX
	  have the same values, so this only matters for a system where the
	  kernel has enabled a subset of available XSAVE extensions.

	Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85
	Reviewed-By: John Baldwin <jhb@FreeBSD.org>

2023-09-28  Frederic Cambus  <fred@statdns.com>

	Add support to readelf for the PT_OPENBSD_NOBTCFI segment type.

2023-09-28  Nick Clifton  <nickc@redhat.com>

	Fix: nm: SEGV on unknow address at nm.c:718 in print_symname
	  PR 30886 * elf-bfd.h (struct elf_obj_tdata): Add dt_strsz field.
	  * elf.c (_bfd_elf_get_dynamic_symbols): Add a NUL byte at the end of the string table. Initialise the dt_strsz field. (_bfd_elf_slurp_version_tables): Only free the contents if they were malloc'ed. Add checks before setting string pointers in the dt_strtab buffer.

2023-09-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add nopie to gdb.base/unwind-on-each-insn-amd64-2.exp
	When running test-case gdb.base/unwind-on-each-insn-amd64-2.exp with target
	board unix/-fPIE/-pie, I run into:
	...
	gdb compile failed, ld: unwind-on-each-insn-amd64-21.o: relocation \
	  R_X86_64_32S against `.text' can not be used when making a PIE object; \
	  recompile with -fPIE
	ld: failed to set dynamic section sizes: bad value
	...

	Fix this by hardcoding nopie in the test-case, and for good measure in the
	other test-cases that source unwind-on-each-insn.exp.tcl and use a .s file.

	Tested on x86_64-linux.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-09-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-27  Aaron Merey  <amerey@redhat.com>

	config/debuginfod.m4: Add check for libdebuginfod 0.188
	Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found
	define macro HAVE_LIBDEBUGINFOD_FIND_SECTION.

	This macro indicates support for downloading ELF sections from
	debuginfod servers.

2023-09-27  Nick Clifton  <nickc@redhat.com>

	nm: heap-buffer-overflow at elfcode.h:1507 in bfd_elf64_slurp_symbol_table
	  PR 30885
	  * elfcode.h (elf_slurp_symbol_table): Compute the symcount for non dynamic symbols in the same way as _bfd_elf_get_symtab_upper_bound.

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: prefer VEX encodings over EVEX ones when possible
	AVX-* features / insns paralleling earlier introduced AVX512* ones can
	be encoded more compactly when the respective feature was explicitly
	enabled by the user.

	x86: drop cpu_arch_tune_flags
	Apparently from its introduction the variable was only ever written (the
	only read is merely to determine whether to write it with another value).
	(Since, due to the need to re-indent, the adjacent lines setting
	cpu_arch_tune need touching anyway, switch to using PREOCESSOR_*
	constants where applicable, to make more obvious what the resulting
	state is going to be.)

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: correct cpu_arch_isa_flags maintenance
	These may not be set from a value derived from cpu_arch_flags: That
	starts with (almost) all functionality enabled, while cpu_arch_isa_flags
	is supposed to track features that were explicitly enabled (and perhaps
	later disabled) by the user.

	To avoid needing to do any such adjustment in two places (each),
	introduce helper functions used by both command line handling and
	directive processing.

2023-09-27  Pedro Alves  <pedro@palves.net>

	Adjust gdb.thread/pthreads.exp for Cygwin
	The Cygwin runtime spawns a few extra threads, so using hardcoded
	thread numbers in tests rarely works correctly.  Thankfully, this
	testcase already records the ids of the important threads in globals.
	It just so happens that they are not used in a few tests.  This commit
	fixes that.

	With this, the test passes cleanly on Cygwin [1].  Still passes cleanly on
	x86-64 GNU/Linux.

	[1] - with system GDB.  Upstream GDB is missing a couple patches
	Cygwin carries downstream.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I01bf71fcb44ceddea8bd16b933b10b964749a6af

2023-09-27  Pedro Alves  <pedro@palves.net>

	In gdb.threads/pthreads.c, handle pthread_attr_setscope ENOTSUP
	On Cygwin, I see:

	 (gdb) PASS: gdb.threads/pthreads.exp: break thread1
	 continue
	 Continuing.
	 pthread_attr_setscope 1: Not supported (134)
	 [Thread 3732.0x265c exited with code 1]
	 [Thread 3732.0x2834 exited with code 1]
	 [Thread 3732.0x2690 exited with code 1]

	 Program terminated with signal SIGHUP, Hangup.
	 The program no longer exists.
	 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread

	 ... and then a set of cascading failures.

	Fix this by treating ENOTSUP the same way as if PTHREAD_SCOPE_SYSTEM
	were not defined.  I.e., ignore ENOTSUP errors, and proceed with
	testing.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Iea68ff8b9937570726154f36610c48ef96101871

2023-09-27  Pedro Alves  <pedro@palves.net>

	Fix gdb.threads/pthreads.exp error handling/printing
	On Cygwin, I noticed:

	 (gdb) PASS: gdb.threads/pthreads.exp: break thread1
	 continue
	 Continuing.
	 pthread_attr_setscope 1: No error
	 [Thread 8732.0x28f8 exited with code 1]
	 [Thread 8732.0xb50 exited with code 1]
	 [Thread 8732.0x17f8 exited with code 1]

	 Program terminated with signal SIGHUP, Hangup.
	 The program no longer exists.
	 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread

	Note "No error" in "pthread_attr_setscope 1: No error".  That is a bug
	in the test.  It is using perror, but that prints errno, while the
	pthread functions return the error directly.  Fix all cases of the
	same problem, by adding a new print_error function and using it.

	We now get:

	  ...
	  pthread_attr_setscope 1: Not supported (134)
	  ...

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I972ebc931b157bc0f9084e6ecd8916a5e39238f5

2023-09-27  Pedro Alves  <pedro@palves.net>

	Fix gdb.threads/pthreads.c formatting
	Just some GNU formatting fixes throughout.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Ie851e3815b839e57898263896db0ba8ddfefe09e

2023-09-27  Pedro Alves  <pedro@palves.net>

	gdb.threads/pthreads.c, K&R -> ANSI function style
	gdb.threads/pthreads.c is declaring functions with old K&R style.
	This commit converts them to ANSI style.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I1ce007c67bb4ab1e49248c014c7881e46634f8f8

2023-09-27  Neal Frager  <neal.frager@amd.com>

	opcodes: microblaze: Add wdc.ext.clear and wdc.ext.flush insns

2023-09-27  Hsinyuan Xavier  <TheLastLin@hotmail.com>

	Fix: Output section type does not been applied to section forced output by `. = .` assignment
	  PR 30875
	  * ldlang.c (get_os_init_flag): New function. (exp_init_os, map_input_to_output_sections): Use it.

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: fold FMA VEX and EVEX templates
	Following the folding of some generic AVX/AVX2 templates with their
	AVX512F counterpart ones, do this for FMA ones as well, requiring one
	further adjustment to cpu_flags_match().

	x86: fold VAES/VPCLMULQDQ VEX and EVEX templates
	Following the folding of some generic AVX/AVX2 templates with their
	AVX512F counterpart ones, do this for VAES and VPCLMULQDQ ones as well.

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: fold certain VEX and EVEX templates
	In anticipation of APX introduce logic to reduce the number of templates
	we have now, allowing to limit some the number of ones we then need to
	gain.

	The fundamental requirements are that
	- attributes be compatible, which specifically means VexW needs to be
	  the same in the templates (which often isn't the case, for VEX
	  encodings having far more WIG tha, EVEX ones),
	- the EVEX form being AVX512F (with or without AVX512VL), not any of its
	  extensions (the same will then be required for APX - it'll need to be
	  APX_F).

	Note that in check_register() there's now a redundant zmm check. Since
	this logic will need revisiting for APX anyway, I'd like to keep it that
	way for now. (Similarly a couple of if()-s which could be folded are
	kept separate, to reduce code churn when adding APX support.)

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86: tighten .insn SAE and broadcast checking
	SAE / embedded rounding are invalid when there's the memory operand, as
	the bit encoding this specifies broadcast in that case.

	Broadcast needs to be specified on the memory operand.

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86-64: REX.W overrides DATA_PREFIX
	REX.W needs to be respected when immediate size and relocation type are
	determined.

2023-09-27  Jan Beulich  <jbeulich@suse.com>

	x86-64: fix suffix-less PUSH of symbol address
	PR gas/30856

	In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
	conditions") I neglected the case of PUSH, which is the only insn
	allowing (proper) symbol addresses to be used as immediates (not
	displacements, like CALL/JMP) in the absence of any register operands.
	Since it defaults to 64-bit operand size, guessing an L suffix is wrong
	there.

2023-09-27  Sam James  <sam@gentoo.org>  (tiny change)

	gdb: Fix an ODR warning with byacc with GDB_YY_REMAP
	With byacc, we get an ODR warning with YYSTACKDATA between ada-exp.c.tmp
	and c-exp.c.tmp. Just include it in the list of symbols we rename.

	PR gdb/30839

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30839
	Approved-By: Tom de Vries <tdevries@suse.de>

2023-09-27  mengqinggang  <mengqinggang@loongson.cn>

	Add support for "pcaddi rd, symbol"
	Add a macro pcaddi instruction to support "pcaddi rd, symbol".

	pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative
	address, and the address should be 4-byte aligned.

2023-09-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: add xfail for gdb/29965 in gdb.threads/process-exit-status-is-leader-exit-status.exp
	Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently
	with:

	    FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=0: continue (the program exited)
	    ...
	    FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=9: continue (the program exited)

	This is due to a change in Linux kernel behavior [1] that affects
	exactly what this test tests.  That is, if multiple threads (including
	the leader) call SYS_exit, the exit status of the process should be the
	exit status of the leader.  After that change in the kernel, it is no
	longer the case.

	Add an xfail in the test, based on the Linux kernel version.  The goal
	is that if a regression is introduced in GDB regarding this feature, it
	should be caught if running on an older kernel where the behavior was
	consistent.

	[1] https://bugzilla.suse.com/show_bug.cgi?id=1206926

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965
	Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb
	Approved-By: Tom de Vries <tdevries@suse.de>

2023-09-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp with newer gcc
	When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using
	gcc 13.2.1, I run into (layout adapted for readability):
	...
	-stack-list-arguments 1^M
	^done,stack-args=[
	  frame={level="0",args=[]},
	  frame={level="1",args=[{name="<_task>",value="0x464820"},
	                         {name="<_taskL>",value="129"}]},
	  frame={level="2",args=[{name="self_id",value="0x464840"}]},
	  frame={level="3",args=[]},
	  frame={level="4",args=[]}
	]^M
	(gdb) ^M
	FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
	...

	On openSUSE Leap 15.4 with gcc 7.5.0 I get instead:
	...
	-stack-list-arguments 1^M
	^done,stack-args=[
	  frame={level="0",args=[]},
	  frame={level="1",args=[{name="<_task>",value="0x444830"}]},
	  frame={level="2",args=[{name="self_id",value="0x444850"}]},
	  frame={level="3",args=[]},
	  frame={level="4",args=[]}]^M
	(gdb) ^M
	PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1
	...

	The difference in gdb output is due to difference in the dwarf generated by
	the compiler, so I don't see a problem with gdb here.

	Fix this by updating the test-case to accept this output.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-26  Tom Tromey  <tromey@adacore.com>

	Remove some unnecessary qualification from printing.py
	printing.py references "gdb.printing" in a few spots, but there's no
	need for this.  I think this is leftover from when this code was
	(briefly) in some other module.  This patch removes the unnecessary
	qualifications.  Tested on x86-64 Fedora 36.

2023-09-26  Tom Tromey  <tromey@adacore.com>

	Add two new pretty-printer methods
	This adds two new pretty-printer methods, to support random access to
	children.  The methods are implemented for the no-op array printer,
	and DAP is updated to use this.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-09-26  Tom Tromey  <tromey@adacore.com>

	Introduce gdb.ValuePrinter
	There was an earlier thread about adding new methods to
	pretty-printers:

	https://sourceware.org/pipermail/gdb-patches/2023-June/200503.html

	We've known about the need for printer extensibility for a while, but
	have been hampered by backward-compatibilty concerns: gdb never
	documented that printers might acquire new methods, and so existing
	printers may have attribute name clashes.

	To solve this problem, this patch adds a new pretty-printer tag class
	that signals to gdb that the printer follows new extensibility rules.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30816
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-09-26  Nick Clifton  <nickc@redhat.com>

	Fix a snafu in the new tests for reproducible archives that assumed a umask of 22.

2023-09-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/ext-run.exp in container
	When running the gdb testsuite inside a container, I run into:
	...
	(gdb) gdb_expect_list pattern: /1 +root +[/a-z]*(init|systemd)/
	FAIL: gdb.server/ext-run.exp: get process list (pattern 2)
	...
	because there's no process with pid 1 and cmd init or systemd.

	In the host system (where the test passes), I have:
	...
	$ ps -f 1
	UID        PID  PPID  C STIME TTY      STAT   TIME CMD
	root         1     0  0 Sep25 ?        Ss     0:03 /usr/lib/systemd/systemd ...
	...
	but in the container instead:
	...
	UID        PID  PPID  C STIME TTY      STAT   TIME CMD
	root         1     0  0 11:45 pts/0    Ss     0:00 /bin/bash
	...

	Fix this by also accepting bash as a valid cmd.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-26  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Allow feature flags to occupy >64 bits
	Following on from the previous patch to make the feature macros take
	a word number, this one increases the number of flag words from 1 to 2.

	The patch uses some dummy features to push the number of features
	over 64.  The intention is that these should be reused by real
	features rather than kept as-is.

2023-09-26  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Restructure feature flag handling
	The AArch64 feature-flag code is currently limited to a maximum
	of 64 features.  This patch reworks it so that the limit can be
	increased more easily.  The basic idea is:

	(1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum
	    counting bit positions.

	(2) Make the feature-list macros take an array index argument
	    (currently always 0).  The macros then return the
	    aarch64_feature_set contents for that array index.

	    An N-element array would then be initialised as:

	      { MACRO (0), ..., MACRO (N - 1) }

	(3) Provide convenience macros for initialising an
	    aarch64_feature_set for:

	    - a single feature
	    - a list of individual features
	    - an architecture version
	    - an architecture version + a list of additional features

	(2) and (3) use the preprocessor to generate static initialisers.
	The main restriction was that uses of the same preprocessor macro
	cannot be nested.  So if a macro wants to do something for N individual
	arguments, it needs to use a chain of N macros to do it.  There then
	needs to be a way of deriving N, as a preprocessor token suitable for
	pasting.

	The easiest way of doing that was to precede each list of features
	by the number of features in the list.  So an aarch64_feature_set
	initialiser for three features A, B and C would be written:

	  AARCH64_FEATURES (3, A, B, C)

	This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a
	synonym for SHA2+AES, so the patch expands the former to the latter.

2023-09-26  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Fix dap for python < 3.8
	With any gdb.dap test and python 3.6 I run into:
	...
	Error occurred in Python: 'code' object has no attribute 'co_posonlyargcount'
	ERROR: eof reading json header
	...

	The attribute is not supported before python 3.8, which introduced the
	"Positional−only Parameters" concept.

	Fix this by using try/except AttributeError.

	Tested on x86_64-linux:
	- openSUSE Leap 15.4 with python 3.6, and
	- openSUSE Tumbleweed with python 3.11.5.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-26  Enze Li  <enze.li@hotmail.com>

	fbsd-nat: Fix build failure with GCC 12
	A user pointed out that the build failed on FreeBSD/amd64 with my last
	commit.  The problem is that I'm not using the proper way to tell the
	compiler that the variable has been "used".  This patch fixes this issue
	as suggested by John.  Pushed as obvious.

	Tested both on FreeBSD/amd64 and FreeBSD/aarch64 by rebuilding.

	Suggested-By: John Baldwin <jhb@FreeBSD.org>

2023-09-26  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix to step instruction due to P10 prefix instruction.
	In AIX, power 10 instructions like paddi occupy 8 bytes, while the other instructions
	4 bytes of space. Due to this when we do a stepi on paddi instruction we get a SIGILL interrupt. Hence, we
	need to check during stepi if we are able to step 8 bytes during this instruction execution and is the
	breakpoint to this instruction set correctly in both 32- and 64-bit mode.

	This patch is a fix to the same.

2023-09-26  Nick Clifton  <nickc@redhat.com>

	Allow the use of SOURCE_DATE_EPOCH in the timestamps for members of static archives.
	(For some reason this commit was not applied at the time that the patch was approved).

2023-09-26  Tom Tromey  <tromey@adacore.com>

	Use string_file::release in some places
	I found a few spots like:

	    string_file f;
	    std::string x = f.string ();

	However, string_file::string returns a 'const std::string &'...  so it
	seems to me that this must be copying the string (? I find it hard to
	reason about this in C++).

	This patch changes these spots to use release() instead, which moves
	the string.

	Reviewed-by: Keith Seitz <keiths@redhat.com>
	Reviewed-by: Lancelot Six <lancelot.six@amd.com>

2023-09-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-25  Vsevolod Alekseyev  <sevaa@sprynet.com>

	Fix readelf's display of dwarf v5 range lists
	  PR 30792
	  * dwarf.h (struct debug_info): Remove range_versions field.
	  * dwarf.c (fetch_indexed_offset): New function. (read_and_display_attr_value): Use it for DW_FORM_rnglistx. Remove code to initialise range_versions. (skip_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (process_debug_info): Call read_bases. (display_debug_rnglists): Rename to display_debug_rnglists_unit_header and only display the range list header information. (display_debug_ranges): Adjust.

2023-09-25  Claudiu Zissulescu  <claziss@gmail.com>

	Revert "arc: Add new GAS tests for ARCv3."
	This reverts commit 462693a455f04fc52c1c91ffc52ea2446a086444.

	Revert "arc: Add new LD tests for ARCv3."
	This reverts commit 6e467e9a94c1135bd11d985e9263d43204a9258b.

	Revert "arc: Add new ARCv3 ISA to BFD."
	This reverts commit 06e8d9861d16c5b7e6920ad0e89889ccf45c575a.

	Revert "arc: Add new linker emulation and scripts for ARCv3 ISA."
	This reverts commit 4deb1ee57fdb711cac6f36fed75b3c8cb5112d99.

	Revert "arc: Update opcode related include files for ARCv3."
	This reverts commit 04414221df53bb5129e34bec354dae3121db436a.

	Revert "arc: Update ARC's Gnu Assembler backend with ARCv3 ISA."
	This reverts commit f3d38d7d0b7346515ba603454feeddc58a3fc451.

	Revert "arc: Add new opcode functions for ARCv3 ISA."
	This reverts commit c99dc76089a2de97ea0ee755aa8e87037a17b6d6.

	Revert "arc: New ARCv3 ISA instruction table"
	This reverts commit 67036dfacf87e79317984f51892bfc0eda0e597f.

	Revert "arc: Update arc's gas tests"
	This reverts commit ef90c0991e78c28bebdd3ed31a77c05be0444191.

	Revert "arc: Update NEWS files"
	This reverts commit a47d304b1229ecf8912fac17ee9c48d1bf3c729a.

	Revert "arc: Update bfd arc pattern file to allow enable-targets=all"
	This reverts commit 5e5116071b09e187ee3c6b7e86e86114f6a65ef3.

2023-09-25  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Update bfd arc pattern file to allow enable-targets=all
	The ARC backend uses a BFD pattern file to generate three ARC targets:
	- an BFD ARC target for ARCv1 and ARCv2 CPU families. It also works
	for big-endian variants.
	- an BFD ARC64 target for ARCv3 64bit machines. It also allows working
	with ARCv3 32bit machines.
	- an BFD ARC32 target for ARCv4 32bit machines. It also allows working
	with ARCv3 64bit machines.

	When configuring with `--enable-targets=all` some patterns are defined
	multiple times. Fix this issue.

2023-09-25  Andreas Schwab  <schwab@suse.de>

	RISC-V: Protect .got with relro
	Move .got before .data so that it can be protected with -zrelro.  Also
	separate .got.plt from .got if -znow is not in effect; the first two words
	of .got.plt are placed within the relro region.

	ld:
		PR ld/30877
		* emulparams/elf32lriscv-defs.sh (DATA_GOT, SEPARATE_GOTPLT):
		Define.
		* emulparams/elf64lriscv-defs.sh (SEPARATE_GOTPLT): Define.
		* testsuite/ld-elf/binutils.exp (binutils_test): Remove riscv*-*-*
		from relro_got expression.

2023-09-25  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Update NEWS files
	Add ARCv3 support in NEWS files.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update arc's gas tests
	The disassembler can recognize the alternative register names ILINK1
	and ILINK2.  Update tests.

	gas/testsuite/gas/arc
	xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

		* gas/testsuite/gas/arc/adc.d: Update ILINK1/INLINK2 reg names.
		* gas/testsuite/gas/arc/add.d: Likewise.
		* gas/testsuite/gas/arc/and.d: Likewise.
		* gas/testsuite/gas/arc/asl.d: Likewise.
		* gas/testsuite/gas/arc/asr.d: Likewise.
		* gas/testsuite/gas/arc/bic.d: Likewise.
		* gas/testsuite/gas/arc/lsr.d: Likewise.
		* gas/testsuite/gas/arc/nps400-1.d: Likewise.
		* gas/testsuite/gas/arc/or.d: Likewise.
		* gas/testsuite/gas/arc/ror.d: Likewise.
		* gas/testsuite/gas/arc/sbc.d: Likewise.
		* gas/testsuite/gas/arc/sub.d: Likewise.
		* gas/testsuite/gas/arc/textinsn3op.d: Likewise.
		* gas/testsuite/gas/arc/warn.exp: Update predicate.
		* gas/testsuite/gas/arc/arc.exp: Likewise.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: New ARCv3 ISA instruction table
	opcodes/
	xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

		* opcodes/arc64-tbl.h: New file.

2023-09-25  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Add new opcode functions for ARCv3 ISA.
	opcodes/
	xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>
	            Cupertino Miranda <cmiranda@synopsys.com>

	        * opcodes/Makefile.am: Add ARC64 opcode file.
	        * opcodes/Makefile.in: Regenerate.
	        * opcodes/arc-opc.c: Move the common functionality to
	        arcxx-opc.inc. Keep only ARCv2 ARCv1 specifics.
	        * opcodes/arc-ext-tbl.h: Deleted file.
	        * opcodes/arcxx-opc.inc: New file.
	        * opcodes/arc64-opc.c: Likewise.
	        * opcodes/arc-fxi.h (insert_uimm9_a32_11_s): New function.
	        (extract_uimm9_a32_11_s): Likewise.
	        (insert_uimm10_13_s): Likewise.
	        (extract_uimm10_13_s): Likewise.
	        * opcodes/configure: Regenerate.
	        * opcodes/configure.ac: Add ARC64 target.
	        * opcodes/disassemble.c: Likewise.
	        * opcodes/arc-dis.c (regmod_t): New type.
	        (regmods): New structure.
	        (fpnames): New strings with fp-regs name.
	        (REG_PCL, REG_LIMM, REG_LIMM_S, REG_U32, REG_S32): New defines.
	        (getregname): New function.
	        (find_format_from_table): Discriminate between signed and unsigned
	        32bit immediates.
	        (find_format): Handle extract function for flags.
	        (arc_insn_length): Update insn lengths to various architectures.
	        (print_insn_arc): Update printing for various ARC architectures.
		* opcodes/arc-flag-classes.def: New file.
		* opcodes/arc-flag.def: New file.
		* opcodes/arc-operands.def: New file.
		* opcodes/arc-regs.h: Changed.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update ARC's Gnu Assembler backend with ARCv3 ISA.
	The new Synopsys ARCv3 ISA has a similar instruction format like
	the old ARCv1 and ARCv2 ISA.  Thus, the ARCv3 addition is using
	whatever we have for old ARC processors plus some ARCv3 spcific mods.

	To distinguish between various ARC variants, we introduced two new
	configure defines named TARGET_ARCv3_32 and TARGET_ARCv3_64 which are
	set when we choose either an ARC32 (ARCv3/32) ISA toolchain or an
	ARC64 (ARCv3/64) ISA toolchain.

	gas/
	xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

		* gas/config/tc-arc.h: Selectively define default target macros.
		* gas/configure.ac: Add ARC64 target.
		* gas/configure.tgt: Likewise.
		* gas/configure: Regenerate
		* gas/config.in: Regenerate.
		* gas/config/tc-arc.c (DEFAULT_ARCH): New macro.
		(default_arch): New variable.
		(md_pseudo_table): Add xword.
		(md_shortopts): Only a few options are recognized by the new ARC64
		assembler.
		(md_longopts): Likewise.
		(ARC_CPU_TYPE_A64x): New define.
		(ARC_CPU_TYPE_A32x): Likewise.
		(cpu_type): New arch field.
		(selected_cpu): Update fields.
		(arc_opcode_hash_entry_iterator_init): Formating.
		(arc_opcode_hash_entry_iterator_next): Likewise.
		(arc_select_cpu): Likewise.
		(arc_option): Likewise.
		(check_cpu_feature): Likewise.
		(debug_exp): Recognize new expression operands.
		(parse_reloc_symbol): Parse new signed/unsigend cases.
		(parse_opcode_flags): Update for the case when the flags needs
		insert/extract functions.
		(find_opcode_match): Match new signed/unsigned 32-bit immediates.
		(autodetect_attributes): PLT34 only available for ARC64.
		(md_assemble): Extend match characters.
		(declare_fp_set): New function.
		(init_default_arch): Likewise.
		(md_begin): Detect and initialize the correct CPU and coresponding
		registers.
		(md_pcrel_from_section): Add new relocs.
		(arc_target_format): New function.
		(md_apply_fix): Add new relocs.
		(md_parse_option): Update options.
		(arc_show_cpu_list): Update with ARC64 cpus.
		(md_show_usage): Update messages.
		(may_relax_expr): Add PLT34 case.
		(assemble_insn): Update for ARC64.
		(arc_make_nops): New function.
		(arc_handle_align): Refurbish this function, use arc_make_nops.
		(tc_arc_fix_adjustable): Update messages.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update opcode related include files for ARCv3.
	Add new ARCv3 CPUs and required bits to decode/encode ARCv3 ISA
	opcodes. Fix 32 bit relocations which were set as signed but should be
	bitfield: ARC_32_ME, ARC_GLOB_DAT, ARC_JMP_SLOT, ARC_RELATIVE. Remove
	non-ABI relocation ARC_32_ME_S.

	include/
	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>
		    Cupertino Miranda  <cupertinomiranda@gmail.com>
		    Bruno Mauricio <brunoasmauricio@gmail.com>

		* include/elf/arc-cpu.def: Add new HS5x and HS6x CPUs.
		* include/elf/arc-reloc.def: Add new ARC64 relocations.
		* include/elf/arc.h (EF_ARC_CPU_ARC64): New define.
		* include/opcode/arc-attrs.h (FEATURE_LIST_NAME): Update predicate.
		* include/opcode/arc-func.h: Update formating.
		(replace_disp8ls): New function.
		(replace_disp9s): Likewise.
		(replace_disp6s): Likewise.
		(replace_disp7s): Likewise.
		(replace_disp12s): Likewise.
		* include/opcode/arc.h (ARC_OPCODE_ARC64): New define.
		(ARC_OPCODE_ARC32): Likewise.
		(ARC_OPERAND_FP): Likewise.
		(HARD_FIELDF): Likewise.
		(ARC_OPCODE_ARCVx): New macro.
		(arc_flag_class): Update structure to hold new extract/insert
		functions for flags.
		(INSN3OP): Update macro.
		(FP_SIZE, TPOF, DPOF, SOPF, COPF, CONVOPS): New enums.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Add new linker emulation and scripts for ARCv3 ISA.
	Add ARCv3's linker bits. Remove obsolete tests.

	ld/
	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

		* ld/Makefile.am: Add ARC64 targets.
		* ld/configure.tgt: Likewise.
		* ld/Makefile.in: Regenerate.
		* ld/emulparams/arc64elf32.sh: New file.
		* ld/emulparams/arc64elf64.sh: Likewise.
		* ld/emulparams/arc64linux32.sh: Likewise.
		* ld/emulparams/arc64linux64.sh: Likewise.
		* ld/scripttempl/elfarc.sc: Update stack and heap definitions.
		* ld/testsuite/ld-arc/got-weak.d: Deleted file.
		* ld/testsuite/ld-arc/got-weak.s: Likewise.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Add new ARCv3 ISA to BFD.
	The new Synopsys's ARCv3 ISA is capable to run either 64-bit or
	32-bit ISA.  The new 32-bit ISA is not compatible with the old
	Synopsys ARCv1/ARCv2 ISA, however, it retains a lot of common
	concepts.  Thus, this patch is reusing the old ARC BFD backend and
	adds the necessary bits for the new architecture in a similar way as
	it is done for RISCV backend.

	bfd/
	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>
		    Cupertino Miranda  <cupertinomiranda@gmail.com>

		* bfd/Makefile.am: Add ARC64 files.
		* bfd/Makefile.in: Regerate.
		* bfd/arc-got.h (TCB_SIZE): Depends on the target architecture.
		(GOT_ENTRY_SIZE): New define.
		(write_in_got): Likewise.
		(read_from_got): Likewise.
		(align_power): Likewise.
		(arc_got_entry_type_for_reloc): Use RELA_SIZE and GOT_ENTRY_SIZE.
		(arc_fill_got_info_for_reloc): Update formating.
		(relocate_fix_got_relocs_for_got_info): Likewise.
		(arc_static_sym_data): Deleted structure.
		(get_static_sym_data): Deleted function.
		(relocate_fix_got_relocs_for_got_info): Use symbol static data.
		(create_got_dynrelocs_for_single_entry): Update formating.
		(create_got_dynrelocs_for_got_info): Likewise.
		* bfd/arc-plt.c: New file.
		* bfd/arc-plt.def: Add ARC64 PLT entry.
		* bfd/arc-plt.h: Clean it up, move functionality to arc-plt.c file.
		* bfd/archures.c: Add ARC64 target.
		* bfd/config.bfd: Likewise.
		* bfd/configure.ac: Likewise.
		* bfd/bfd-in2.h: Regenerate.
		* bfd/configure: Likewise.
		* bfd/libbfd.h: Likewise.
		* bfd/cpu-arc.c: Clean it up.
		* bfd/cpu-arc64.c: New file.
		* bfd/elf32-arc.c: Renamed to elfnn-arc.c.
		* bfd/elfnn-arc.c: New file.
		* bfd/reloc.c: Add new ARC64 relocs.
		* bfd/targets.c: Add ARC64 target.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Add new LD tests for ARCv3.
	Add new linker tests for ARCv3 ISA. All the new tests are added in a
	distinct new folder named arc64.

	ld/
	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

		* ld/testsuite/ld-arc64/arcv3_64-reloc-near-exe.dd: New file.
		* ld/testsuite/ld-arc64/arcv3_64-reloc-near-so.dd: Likewise.
		* ld/testsuite/ld-arc64/arcv3_64-reloc-near.s: Likewise.
		* ld/testsuite/ld-arc64/arcv3_64.exp: Likewise.
		* ld/testsuite/ld-arc64/bl34.dd: Likewise.
		* ld/testsuite/ld-arc64/bl34.s: Likewise.
		* ld/testsuite/ld-arc64/linkscript.ld: Likewise.
		* ld/testsuite/ld-arc64/plt34-got.dd: Likewise.
		* ld/testsuite/ld-arc64/plt34-got.s: Likewise.
		* ld/testsuite/ld-arc64/plt34-reloc.dd: Likewise.
		* ld/testsuite/ld-arc64/plt34-reloc.s: Likewise.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Add new GAS tests for ARCv3.
	Add new assembler tests for ARCv3 ISA. All the new tests are added in
	a distinct folder named arc64.

	gas/
	xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

		* gas/testsuite/gas/arc64/arc64.exp: New file.
		* gas/testsuite/gas/arc64/float01.d: Likewise.
		* gas/testsuite/gas/arc64/float01.s: Likewise.
		* gas/testsuite/gas/arc64/ldd.d: Likewise.
		* gas/testsuite/gas/arc64/ldd.s: Likewise.
		* gas/testsuite/gas/arc64/lddl.d: Likewise.
		* gas/testsuite/gas/arc64/lddl.s: Likewise.
		* gas/testsuite/gas/arc64/load.d: Likewise.
		* gas/testsuite/gas/arc64/load.s: Likewise.
		* gas/testsuite/gas/arc64/st.d: Likewise.
		* gas/testsuite/gas/arc64/st.s: Likewise.
		* gas/testsuite/gas/arc64/std.d: Likewise.
		* gas/testsuite/gas/arc64/std.s: Likewise.
		* gas/testsuite/gas/arc64/stdl.d: Likewise.
		* gas/testsuite/gas/arc64/stdl.s: Likewise.
		* gas/testsuite/gas/arc64/stl.d: Likewise.
		* gas/testsuite/gas/arc64/stl.s: Likewise.

2023-09-25  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update binutils arc predicate for tests.
	binutils/testsuite/binutils-all
	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

		* binutils/testsuite/binutils-all/arc/objdump.exp: Update predicate.

2023-09-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-22  Frederic Cambus  <fred@statdns.com>

	Update the NetBSD system call table to add memfd_create(2) and epoll(2).
	Generated from sys/sys/syscall.h revision 1.324.

2023-09-22  Enze Li  <enze.li@hotmail.com>

	fbsd-nat: Pacify gcc with no functional changes
	I see these errors on FreeBSD/aarch64 when using gcc 12 without passing
	--disable-werror.

	=====================================================================
	  CXX    fbsd-nat.o
	fbsd-nat.c: In member function 'void fbsd_nat_target::resume_one_process(ptid_t, int, gdb_signal)':
	fbsd-nat.c:1208:11: error: unused variable 'request' [-Werror=unused-variable]
	 1208 |       int request;
	      |           ^~~~~~~
	fbsd-nat.c: In member function 'virtual ptid_t fbsd_nat_target::wait(ptid_t, target_waitstatus*, target_wait_flags)':
	fbsd-nat.c:1726:22: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
	 1726 |       for (inferior *inf : all_non_exited_inferiors (this))
	      |                      ^~~
	fbsd-nat.c:1697:17: note: shadowed declaration is here
	 1697 |       inferior *inf = find_inferior_ptid (this, wptid);
	      |                 ^~~
	fbsd-nat.c: In member function 'virtual void fbsd_nat_target::detach(inferior*, int)':
	fbsd-nat.c:2044:18: error: variable 'wptid' set but not used [-Werror=unused-but-set-variable]
	 2044 |           ptid_t wptid = wait_1 (ptid, &ws, 0);
	      |                  ^~~~~
	cc1plus: all warnings being treated as errors
	=====================================================================

	This patch includes the following non-functional changes,

	1. Remove unused variable "request".
	2. Rename inf to inf_p to avoid shadowed declaration warnings.
	3. Mark wptid as used when USE_SIGTRAP_SIGINFO is defined.

	Tested on FreeBSD/aarch64 by rebuilding.

	Approved-By: John Baldwin <jhb@FreeBSD.org>

2023-09-22  Tom Tromey  <tromey@adacore.com>

	Remove keywords from target debug printer names
	I recently checked in a patch that removed the use of the "struct"
	keyword in some spots.  Doing this pointed out that the target
	delegate code preserves this keyword -- but, with C++, it does not
	really need to.  This patch changes make-target-delegates.py to remove
	these keywords, and updates target-debug.h to follow.  This pointed
	out that there was already one redudancy: both
	target_debug_print_struct_inferior_p and target_debug_print_inferior_p
	existed.

	Tested by rebuilding.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-09-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30834 improve disassembly output for call and branch instructions
	This patch makes the gprofng disassembler to emit, e.g.
	    call   fprintf@plt [ 0x401060, .-0x49c]
	instead of
	    call   0xfffffffffffffb64

	I use bfd_get_synthetic_symtab() to get function names in the .plt section.
	I have not yet modified Elf-reader in gprofng to remove parsing of .symtab or
	.dynsym sections. But we plan to do it.

	gprofng/ChangeLog
	2023-09-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30834
		* src/Disasm.cc: Show the function name in the call instruction
		and the relative address in the branch instruction. Remove unused code.
		* src/Disasm.h (map_PC_to_func, get_funcname_in_plt): New functions.
		* src/Elf.cc: Get function names for the .plt section.
		* src/Elf.h (get_funcname_in_plt, get_bfd_symbols): New functions.
		* src/Stabs.cc: Add pltSym to SymLst. Remove the conversion to uint32_t.

2023-09-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-21  Thomas Weißschuh  <thomas@t-8ch.de>

	ld: write resolved path to included file to dependency-file
	In ldfile_open_command_file_1() name written to the dependency files is
	the name as specified passed to the "INCLUDE" directive.
	This is before include-path processing so the tracked dependency
	location is most likely wrong.

	Instead track the opened file at the point where the resolved path is
	actually available, in try_open().

2023-09-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-21  Tom Tromey  <tromey@adacore.com>

	Remove stray trailing "," from DAP breakpoint.py
	The buildbot pointed out that the last DAP series I checked in had an
	issue.  Looking into it, it seems there is a stray trailing "," in
	breakpoint.py.  This patch removes it.

	This seems to point out a test suite deficiency.  I will look into
	fixing that.

2023-09-20  Tom Tromey  <tom@tromey.com>

	Remove explanatory comments from includes
	I noticed a comment by an include and remembered that I think these
	don't really provide much value -- sometimes they are just editorial,
	and sometimes they are obsolete.  I think it's better to just remove
	them.  Tested by rebuilding.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-09-20  Gregory Anders  <greg@gpanders.com>

	gdb/dap: only include sourceReference if file path does not exist
	According to the DAP specification if the "sourceReference" field is
	included in a Source object, then the DAP client _must_ make a "source"
	request to the debugger to retrieve file contents, even if the Source
	object also includes path information.

	If the Source's path field is a valid path that the DAP client is able
	to read from the filesystem, having to make another request to the
	debugger to get the file contents is wasteful and leads to incorrect
	results (DAP clients will try to get the contents from the server and
	display those contents as a file with the name in "source.path", but
	this will conflict with the _acutal_ existing file at "source.path").

	Instead, only set "sourceReference" if the source file path does not
	exist.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-20  Gregory Anders  <greg@gpanders.com>

	gdb/dap: use breakpoint fullname to resolve source
	If the breakpoint has a fullname, use that as the source path when
	resolving the breakpoint source information. This is consistent with
	other callers of make_source which also use "fullname" if it exists (see
	e.g. DAPFrameDecorator which returns the symtab's fullname).

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-20  Gregory Anders  <greg@gpanders.com>

	gdb/dap: ignore unused keyword args in step_out
	Some DAP clients may send additional parameters in the stepOut command
	(e.g. "granularity") which are not used by GDB, but should nonetheless
	be accepted without error.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-20  Gregory Anders  <greg@gpanders.com>

	gdb/dap: check for breakpoint source before unpacking
	Not all breakpoints have a source location. For example, a breakpoint
	set on a raw address will have only the "address" field populated, but
	"source" will be None, which leads to a RuntimeError when attempting to
	unpack the filename and line number.

	Before attempting to unpack the filename and line number from the
	breakpoint, ensure that the source information is not None. Also
	populate the source and line information separately from the
	"instructionReference" field, so that breakpoints that include only an
	address are still included.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-20  Tom Tromey  <tromey@adacore.com>

	Run 'black' on printing.py
	The buildbot pointed out that I neglected to re-run 'black' after
	making some changes.  This patch fixes the oversight.

2023-09-20  Matthew "strager" Glazar  <strager.nds@gmail.com>

	gdb/tui: add 'set tui mouse-events off' to restore mouse selection
	Rationale:
	I use the mouse with my terminal to select and copy text. In gdb, I use
	the mouse to select a function name to set a breakpoint, or a variable
	name to print, for example.

	When gdb is compiled with ncurses mouse support, gdb's TUI mode
	intercepts mouse events. Left-clicking and dragging, which would
	normally select text, seems to do nothing. This means I cannot select
	text using my mouse anymore. This makes it harder to set breakpoints,
	print variables, etc.

	Solution:
	I tried to fix this issue by editing the 'mousemask' call to only enable
	buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
	to not allow text to be selected. The only way I could make it work is
	by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
	entirely, which other people might want.

	I therefore decided to make a setting in gdb called 'tui mouse-events'.
	If enabled (the default), the behavior is as it is now: terminal mouse
	events are given to gdb, disabling the terminal's default behavior.
	If disabled (opt-in), the behavior is as it was before the year 2020:
	terminal mouse events are not given to gdb, therefore the mouse can be
	used to select and copy text.

	Notes:
	I am not attached to the setting name or its description. Feel free to
	suggest better wording.

	Testing:
	I tested this change in gnome-terminal by performing the following steps
	manually:

	1. Run: gdb --args ./myprogram
	2. Enable TUI: press ctrl-x ctrl-a
	3. Click and drag text with the mouse. Observe no selection.
	4. Input: set tui mouse-events off
	5. Click and drag text with the mouse. Observe that selection works now.
	6. Input: set tui mouse-events on.
	7. Click and drag text with the mouse. Observe no selection.

2023-09-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Error out for .debug_types section in dwz file
	There are two methods to factor out type information in a dwarf4 executable:
	- use -fdebug-info-types to generate type units in a .debug_types section, and
	- use dwz to create partial units.

	The dwz method has an extra benefit: it also allows to factor out information
	between executables into a newly created .dwz file, pointed to by a
	.gnu_debugaltlink section.

	There is nothing prohibiting a .gnu_debugaltlink file to contain a
	.debug_types section.

	It's just not generated by dwz or any other tool atm, and consequently gdb has
	no support for it.  Enhancement PR symtab/30838 is open about the lack of
	support.

	Make the current situation explicit by emitting a dwarf error:
	...
	(gdb) file struct-with-sig-2^M
	Reading symbols from struct-with-sig-2...^M
	Dwarf Error: .debug_types section not supported in dwz file^M
	...
	and add an assert in write_gdbindex:
	...
	+      /* See enhancement PR symtab/30838.  */
	+      gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types));
	...
	to clarify why we can use:
	...
	      data_buf &cu_list = (per_cu->is_debug_types
	                           ? types_cu_list
	                           : per_cu->is_dwz ? dwz_cu_list : objfile_cu_list);
	...

	The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it
	keeps the copyright years range.

	Tested on x86_64-linux.

	Tested-By: Guinevere Larsen <blarsen@redhat.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838

2023-09-20  Song Mengzhi  <song.mengzhi@zte.com.cn>

	PR30870, VMS_DEBUG compilation error
	Introduced by 8169954446.

		PR 30870
		* vms-alpha.c (image_write): Remove extraneous parenthesis.

2023-09-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-19  Alan Modra  <amodra@gmail.com>

	readelf.c 'ext' may be used uninitialized
		* readelf.c (display_lto_symtab): Init ext.

2023-09-19  Alan Modra  <amodra@gmail.com>

	elf-attrs.c memory allocation fail
	Report errors rather than segfaulting.

	bfd/
		* elf-attrs.c (elf_new_obj_attr): Return NULL on bfd_alloc fail.
		(bfd_elf_add_obj_attr_int): Handle NULL return from the above,
		and propagate return to callers.
		(elf_add_obj_attr_string, elf_add_obj_attr_int_string): Likewise.
		(bfd_elf_add_obj_attr_string): Similarly.
		(_bfd_elf_copy_obj_attributes): Report error on alloc fails.
		(_bfd_elf_parse_attributes): Likewise.
		* elf-bfd.h (bfd_elf_add_obj_attr_int): Update prototype.
		(bfd_elf_add_obj_attr_string): Likewise.
		(bfd_elf_add_obj_attr_int_string): Likewise.
	gas/
		* config/obj-elf.c (obj_elf_vendor_attribute): Report fatal
		error on out of memory from bfd attribute functions.
		* config/tc-arc.c (arc_set_attribute_int): Likewise.
		(arc_set_attribute_string, arc_set_public_attributes): Likewise.
		* config/tc-arm.c (aeabi_set_attribute_int): Likewise.
		(aeabi_set_attribute_string): Likewise.
		* config/tc-mips.c (mips_md_finish): Likewise.
		* config/tc-msp430.c (msp430_md_finish): Likewise.
		* config/tc-riscv.c (riscv_write_out_attrs): Likewise.
		* config/tc-sparc.c (sparc_md_finish): Likewise.
		* config/tc-tic6x.c (tic6x_set_attribute_int): Likewise.
		* config/tc-csky.c (md_begin): Likewise.
		(set_csky_attribute): Return ok status.

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Handle pointers and references correctly in DAP
	A user pointed out that the current DAP variable code does not let the
	client deference a pointer.  Oops!

	Fixing this oversight is simple enough -- adding a new no-op
	pretty-printer for pointers and references is quite simple.

	However, doing this naive caused a regession in scopes.exp, which
	expected there to be no children of a 'const char *' variable.  This
	problem was fixed by the preceding patches in the series, which ensure
	that a C type of this kind is recognized as a string.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30821

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Give a language to a type
	This changes main_type to hold a language, and updates the debug
	readers to set this field.  This is done by adding the language to the
	type-allocator object.

	Note that the non-DWARF readers are changed on a "best effort" basis.

	This patch also reimplements type::is_array_like to use the type's
	language, and it adds a new type::is_string_like as well.  This in
	turn lets us change the Python implementation of these methods to
	simply defer to the type.

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Add is_array_like and to_array to language_defn
	This adds new is_array_like and to_array methods to language_defn.
	This will be used in a subsequent patch that generalizes the new
	Python array- and string-handling code.

	Regularize some DWARF type initialization
	In one spot, it will be convenient for a subsequent patch if the CU is
	passed to a type-creation helper function.  In another spot, remove
	the redundant 'objfile' parameter to another such function.

	Pass a type allocator to init_fixed_point_type
	init_fixed_point_type currently takes an objfile and creates its own
	type allocator.  However, for a later patch it is more convenient if
	this function accepts a type allocator.  This patch makes this change.

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Use gdb::checked_static_cast for catchpoints
	This replaces some casts to various kinds of catchpoint with
	checked_static_cast.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Use gdb::checked_static_cast for code_breakpoint
	This replaces some casts to 'code_breakpoint *' with
	checked_static_cast.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Use gdb::checked_static_cast for tracepoints
	This replaces some casts to 'tracepoint *' with checked_static_cast.
	Some functions are changed to accept a 'tracepoint *' now, for better
	type safety.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-19  Tom Tromey  <tromey@adacore.com>

	Use gdb::checked_static_cast for watchpoints
	This replaces some casts to 'watchpoint *' with checked_static_cast.
	In one spot, an unnecessary block is also removed.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-19  Mohamed Bouhaouel  <mohamed.bouhaouel@intel.com>

	gdb, breakpoint: add a destructor to the watchpoint struct
	Make sure to unlink the related breakpoint when the watchpoint instance
	is deleted.  This prevents having a wp-related breakpoint that is
	linked to a NULL watchpoint (e.g.  the watchpoint instance is being
	deleted when the 'watch' command fails).  With the below scenario,
	having such a left out breakpoint will lead to a GDB hang, and this
	is due to an infinite loop when deleting all inferior breakpoints.

	Scenario:
		(gdb) set can-use-hw-watchpoints 0
		(gdb) awatch <SCOPE VAR>
		Can't set read/access watchpoint when hardware watchpoints are disabled.
		(gdb) rwatch <SCOPE VAR>
		Can't set read/access watchpoint when hardware watchpoints are disabled.
		(gdb) <continue the program until the end>
		>> HANG <<

	Reviewed-by: Bruno Larsen <blarsen@redhat.com>

2023-09-19  Guinevere Larsen  <blarsen@redhat.com>

	gdb/cli: fixes to newly added "list ." command
	After the series that added this command was pushed, Pedro mentioned
	that the news description could easily be misinterpreted, as well as
	some code and test improvements that should be made.

	While fixing the test, I realized that code repetition wasn't
	happening as it should, so I took care of that too.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-09-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-18  Tom Tromey  <tom@tromey.com>

	More type safety for symbol_search
	This patch changes class symbol_search to store a block_enum rather
	than an int.

	Regression tested on x86-64 Fedora 38.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-18  Tom Tromey  <tromey@adacore.com>

	Move val_prettyformat to valprint.h
	I stumbled across an ancient FIXME comment that was easy to fix --
	val_prettyformat does not need to be in defs.h, and is easily moved to
	valprint.h, where (despite what the comment says) it belongs.

	Tested by rebuilding.

2023-09-18  Jacob Navia  <jacob@jacob.remcomp.fr>

	Fix: Use of uninitialized memory
	  * config/tc-riscv.c (riscv_ip_hardcode): Fully initialise the allocated riscv_opcode structure.

2023-09-18  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused free_actions declaration
	This appears to be a leftover from a past change.

	Change-Id: I8e747edbf291400e4f417f5c6875049479a1669a

2023-09-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-16  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix overly large gdb-index file check for 32-bit
	Add a unit test which checks that write_gdb_index_1 will throw
	an error when the size of the file would exceed the maximum value
	capable of being represented by 'offset_type'.

	The unit test fails on 32-bit systems due to wrapping overflow.  Fix this by
	changing the type of total_len in write_gdbindex_1 from size_t to uint64_t.

	Tested on x86_64-linux.

	Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-09-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove -Werror annotations from MAINTAINERS file
	I don't think these are useful nowadays, since we now expect all code to
	be -Werror clean (it's the default in development branches).

	Change-Id: I8c3b86c70d683bd41344d27add0ac2627a474d20
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amdgpu: add precise-memory support
	The amd-dbgapi library exposes a setting called "memory precision" for
	AMD GPUs [1].  Here's a copy of the description of the setting:

	    The AMD GPU can overlap the execution of memory instructions with other
	    instructions.  This can result in a wave stopping due to a memory violation
	    or hardware data watchpoint hit with a program counter beyond the
	    instruction that caused the wave to stop.

	    Some architectures allow the hardware to be configured to always wait for
	    memory operations to complete before continuing.  This will result in the
	    wave stopping at the instruction immediately after the one that caused the
	    stop event.  Enabling this mode can make execution of waves significantly
	    slower.

	Expose this option through a new "amdgpu precise-memory" setting.

	The precise memory setting is per inferior.  The setting is transferred
	from one inferior to another when using the clone-inferior command, or
	when a new inferior is created following an exec or a fork.

	It can be set before starting the inferior, in which case GDB will
	attempt to apply what the user wants when attaching amd-dbgapi.  If the
	user has requested to enable precise memory, but it can't be enabled
	(not all hardware supports it), GDB prints a warning.

	If precise memory is disabled, GDB prints a warning when hitting a
	memory exception (translated into GDB_SIGNAL_SEGV or GDB_SIGNAL_BUS),
	saying that the stop location may not be precise.

	Note that the precise memory setting also affects memory watchpoint
	reporting, but the watchpoint support for AMD GPUs hasn't been
	upstreamed to GDB yet.  When we do upstream watchpoint support, GDB will
	produce a similar warning message when stopping due to a watchpoint if
	precise memory is disabled.

	Add a handful of tests.  Add a util proc
	"hip_devices_support_precise_memory", which indicates if all devices
	used for testing support that feature.

	[1] https://github.com/ROCm-Developer-Tools/ROCdbgapi/blob/687374258a27b5aab1309a7e8ded719e2f1ed3b1/include/amd-dbgapi.h.in#L6300-L6317

	Change-Id: Ife1a99c0e960513da375ced8f8afaf8e47a61b3f
	Approved-By: Lancelot Six <lancelot.six@amd.com>

2023-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: add linux target check in allow_hipcc_tests
	ROCm / HIP tests should only run on Linux for now, existing gdb.rocm
	tests miss such a check.  Add an "istarget linux" check in
	allow_hipcc_tests.

	Change-Id: I71f69e510a754f2fdadc32de53b923ebb9835ab5
	Approved-By: Lancelot Six <lancelot.six@amd.com>

2023-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior_cloned observable
	The following patch makes the amdgpu port transfer a property from the
	original inferior to the new inferior when using the clone-inferior
	command.  Add the inferior_cloned observable to help with this.

	Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-15  Tom Tromey  <tromey@adacore.com>

	Fix build failure with GCC 4.8
	A user pointed out that the build failed with GCC 4.8.  The problem
	was that the form used by the std::hash specialization of ptid_t was
	not accepted.  This patch rewrites this code into a form that is
	acceptable to the older compiler.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-15  Laurent Morichetti  <laurent.morichetti@amd.com>

	gdb/amdgpu: Silence wave termination messages
	After commit 9d7d58e7262, the amdgpu target started printing
	"thread exited" messages when pruning waves that had terminated.

	  ...
	  [AMDGPU Wave ?:?:?:2045 (?,?,?)/? exited]
	  [AMDGPU Wave ?:?:?:2046 (?,?,?)/? exited]
	  [AMDGPU Wave ?:?:?:2047 (?,?,?)/? exited]
	  [AMDGPU Wave ?:?:?:2048 (?,?,?)/? exited]
	  ...

	The issue was that before commit 9d7d58e7262, delete_thread was silent
	by default due to a bug that the commit fixed.

	Replaced the amdgpu target call to delete_thread with a call to
	delete_thread_silent.

	Change-Id: Ie5d5a4c5be851f092d2315b2afa6a36a30a05245
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add Lancelot Six as maintainer of the AMD GPU port
	Lancelot has accepted to take the role of maintainer for the AMD GPU
	port.  The AMD GPU port (amdgpu as I've written in the MAINTAINERS file)
	is an umbrella term for everything needed to make this work: the amdgcn
	arch, the amd-dbgapi target, solib-rocm, etc.

	Thanks for accepting the role, and congratulations!

	Change-Id: I4c898042fda49b45dcb0d54ca94731bb57287f71

2023-09-15  Tom Tromey  <tromey@adacore.com>

	Rename split_style::DOT
	This renames split_style::DOT, to avoid name clashes when building gdb
	with an old version of Bison (2.3, the version available on macOS).

	In particular the error looks like:

	./split-name.h:34:3: error: expected identifier
	  DOT,
	  ^
	m2-exp.c:163:13: note: expanded from macro 'DOT'

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286

2023-09-15  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Fix alignment of the TLS Translation Control Block
	The R_ARC_TLS_LE_32 is defined as S + A + TLS_TBSS - TLS_REL, where

	  -  S is the base address of the symbol in the memory
	  -  A is the symbol addendum
	  -  TLS_TBSS is the TLS Translation Control Block size (aligned)
	  -  TLS_REL is the base of the TLS section

	Given the next code snip:

	__thread int data_var = 12;
	__attribute__((__aligned__(128))) __thread int data_var_128 = 128;
	__thread int bss_var;
	__attribute__((__aligned__(256))) __thread int bss_var_256;

	int __start(void)
	{
		return data_var + data_var_128 + bss_var + bss_var_256;
	}

	The current code returns different TLS_TBSS values for .tdata and
	.tbss. This patch fixes this by using the linker provided tls_sec.

	bfd/

		* elf32-arc.c (TLS_REL): Clean up.
		(TLS_TBSS): Use tls_sec alignment.
		(arc_do_relocation): Check if we have valid tls_sec.

2023-09-15  Andrew Burgess  <aburgess@redhat.com>

	gdb: small cleanup in symbol_file_add_with_addrs
	While looking at how gdb::observers::new_objfile was used, I found
	some code in symbol_file_add_with_addrs that I thought could be
	improved.

	Instead of:

	  if (condition)
	   {
	     ...
	     return;
	   }

	  ...
	  return;

	Where some parts of '...' identical between the two branches.  I think
	it would be nicer if the duplication is removed, and we just use:

	  if (!condition)
	    ...

	to guard the one statement that should only happen when the condition
	is not true.

	There is one change in this commit though that is (possibly)
	significant, there is a call to bfd_cache_close_all() that was only
	present in the second block.  After this commit we now call that
	function for both paths.

	The call to bfd_cache_close_all was added in commit:

	  commit ce7d45220e4ed342d4a77fcd2f312e85e1100971
	  Date:   Fri Jul 30 12:05:45 2004 +0000

	with the purpose of ensuring that GDB doesn't hold the BFDs open
	unnecessarily, thus preventing the files from being updated on some
	hosts (e.g. Win32).

	In the early exit case we previously didn't call bfd_cache_close_all,
	with the result that GDB would continue to hold open some BFD objects
	longer than needed.

	After this commit, but calling bfd_cache_close_all for both paths this
	problem is solved.

	I'm not sure how this change could be tested, I don't believe there's
	any GDB (maintenance) command that displays the BFD cache contents, so
	we can't check the cache contents easily.  Ideas are welcome though.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-15  Andrew Burgess  <aburgess@redhat.com>

	gdb: add some missing filename styling
	Spotted a few places where we can add filename styling.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-15  Jinyang He  <hejinyang@loongson.cn>

	LoongArch: Enable gas sort relocs
	The md_pre_output_hook creating fixup is asynchronous, causing relocs
	may be out of order in .eh_frame. Define GAS_SORT_RELOCS so that reorder
	relocs when write_relocs.

	Reported-by: Rui Ueyama <rui314@gmail.com>

2023-09-15  Jan Beulich  <jbeulich@suse.com>

	x86: fold CpuLM and Cpu64
	Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while
	Cpu64 is solely used in insn templates, they no longer need to be
	treated different from other "ordinary" flags; the only "unusual" one
	left if CpuNo64. Fold both, leaving just Cpu64.

2023-09-15  Jan Beulich  <jbeulich@suse.com>

	x86: don't play with cpu_arch_flags.cpu{,no}64
	A total four places exists where we set the two bits from flag_code, but
	these values are never used. The two bits are evaluated only when coming
	from insn templates.

	Drop these assignments. Also make obvious that cpu_flags_check_cpu64()
	is only ever used against insn templates.

2023-09-15  Jan Beulich  <jbeulich@suse.com>

	x86: make code size vs CPU arch checking consistent
	While update_code_flag() checks for LM / i386, set_cpu_arch() so far
	didn't, allowing e.g. 64-bit code to be emitted after ".arch generic32".

	Oddly enough a few of our testcases actually exhibit bad behavior (and
	hence need minor adjustments).

2023-09-15  Jan Beulich  <jbeulich@suse.com>

	x86: re-order update_code_flag()
	Do checks before updating state, and bail upon failure of either of the
	checks. While moving the code, eliminate some redundancy.

2023-09-15  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: explicitly test for stderr in gdb.mi/mi-dprintf.exp
	As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some
	compilers such as clang don't add debug information about stderr by
	default, leaving it to external debug packages.

	This commit adds a way to check if GDB has access to stderr information
	when in MI mode, and uses this new mechanism to skip the related section
	of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a
	test in that file.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Kevin Buettner <kevinb@redhat.com>

2023-09-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-15  Kevin Buettner  <kevinb@redhat.com>

	Throw error when creating an overly large gdb-index file
	The header in a .gdb_index section uses 32-bit unsigned offsets to
	refer to other areas of the section.  Thus, there is a size limit of
	2^32-1 which is currently unaccounted for by GDB's code for outputting
	these sections.

	At the moment, when GDB creates an overly large section, it will exit
	abnormally due to an internal error, which is caused by a failed
	assert in assert_file_size, which in turn is called from
	write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c.

	This is what happens when that assert fails:

	$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
	Reading symbols from ./libgraph_tool_inference.so...
	No executable file now.
	Discard symbol table from `libgraph_tool_inference.so'? (y or n) n
	Not confirmed.
	../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	----- Backtrace -----
	0x55fddb4d78b0 gdb_internal_backtrace_1
		../../gdb/bt-utils.c:122
	0x55fddb4d78b0 _Z22gdb_internal_backtracev
		../../gdb/bt-utils.c:168
	0x55fddb98b5d4 internal_vproblem
		../../gdb/utils.c:396
	0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag
		../../gdb/utils.c:476
	0x55fddbb71654 _Z18internal_error_locPKciS0_z
		../../gdbsupport/errors.cc:58
	0x55fddb5a0f23 assert_file_size
		../../gdb/dwarf2/index-write.c:1069
	0x55fddb5a1ee0 assert_file_size
		/usr/include/c++/13/bits/stl_iterator.h:1158
	0x55fddb5a1ee0 write_gdbindex_1
		../../gdb/dwarf2/index-write.c:1119
	0x55fddb5a51be write_gdbindex
		../../gdb/dwarf2/index-write.c:1273
	[...]
	---------------------
	../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.

	This problem was encountered while building the python-graph-tool
	package on Fedora.  The Fedora bugzilla bug can be found here:

	https://bugzilla.redhat.com/show_bug.cgi?id=1773651

	This commit prevents the internal error from occurring by calling error()
	when the file size exceeds 2^32-1.

	Using a gdb built with this commit, I now see this behavior instead:

	$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
	Reading symbols from ./libgraph_tool_inference.so...
	No executable file now.
	Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n
	Not confirmed.
	Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded
	(gdb)

	I wish I could provide a test case, but due to the sizes of both the
	input and output files, I think that testing resources would be
	strained or exceeded in many environments.

	My testing on Fedora 38 shows no regressions.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-09-14  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix buffer overflow in DWARF reader
	In this commit:

	  commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e
	  Date:   Fri Nov 19 10:12:44 2021 -0700

	      Handle multiple addresses in call_site_target

	a buffer overflow bug was introduced when the following code was
	added:

	  CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
	                                addresses.size ());
	  std::copy (addresses.begin (), addresses.end (), saved);

	The definition of XOBNEWVAR is (from libiberty.h):

	  #define XOBNEWVAR(O, T, S)	((T *) obstack_alloc ((O), (S)))

	So 'saved' is going to point to addresses.size () bytes of memory,
	however, the std::copy will write addresses.size () number of
	CORE_ADDR sized entries to the address pointed to by 'saved', this is
	going to result in memory corruption.

	The mistake is that we should have used XOBNEWVEC, which allocates a
	vector of entries, the definition of XOBNEWVEC is:

	  #define XOBNEWVEC(O, T, N) \
	    ((T *) obstack_alloc ((O), sizeof (T) * (N)))

	Which means we will have set aside enough space to create a copy of
	the contents of the addresses vector.

	I'm not sure how to create a test for this problem, this issue cropped
	up when debugging a particular i686 built binary, which just happened
	to trigger a glibc assertion (likely due to random memory corruption),
	debugging the same binary built for x86-64 appeared to work just fine.

	Using valgrind on the failing GDB binary pointed straight to the cause
	of the problem, and with this patch in place there are no longer
	valgrind errors in this area.

	If anyone has ideas for a test I'm happy to work on something.

	Co-Authored-By: Keith Seitz <keiths@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-14  Tom de Vries  <tdevries@suse.de>

	[gdb/exp] Clean up asap in value_print_array_elements
	I've been running the test-suite on an i686-linux laptop with 1GB of memory,
	and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
	not being able to spawn for a large number of test-cases afterwards.

	So I investigated the memory usage, on my usual x86_64-linux development
	platform.

	The test-case is compiled with -DCRASH_GDB=2097152, so this:
	...
	static int a[CRASH_GDB], b[CRASH_GDB];
	...
	with sizeof (int) == 4 represents two arrays of 8MB each.

	Say we add a loop around the "print a" command and print space usage
	statistics:
	...
	gdb_test "maint set per-command space on"
	for {set i 0} {$i < 100} {incr i} {
	    gdb_test "print a"
	}
	...

	This gets us:
	...
	(gdb) print a^M
	$1 = {0 <repeats 2097152 times>}^M
	Space used: 478248960 (+469356544 for this command)^M
	(gdb) print a^M
	$2 = {0 <repeats 2097152 times>}^M
	Space used: 486629376 (+8380416 for this command)^M
	(gdb) print a^M
	$3 = {0 <repeats 2097152 times>}^M
	Space used: 495009792 (+8380416 for this command)^M
	  ...
	(gdb) print a^M
	$100 = {0 <repeats 2097152 times>}^M
	Space used: 1308721152 (+8380416 for this command)^M
	...

	In other words, we start out at 8MB, and the first print costs us about 469MB,
	and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
	i686-linux laptop, the first print costs us 335MB. ]

	The subsequent 8MBs are consistent with the values being saved into the value
	history, but the usage for the initial print seems somewhat excessive.

	There is a PR open about needing sparse representation of large arrays
	(PR8819), but this memory usage points to an independent problem.

	The function value_print_array_elements contains a scoped_value_mark to free
	allocated values in the outer loop, but it doesn't prevent the inner loop from
	allocating a lot of values.

	Fix this by adding a scoped_value_mark in the inner loop, after which we have:
	...
	(gdb) print a^M
	$1 = {0 <repeats 2097152 times>}^M
	Space used: 8892416 (+0 for this command)^M
	(gdb) print a^M
	$2 = {0 <repeats 2097152 times>}^M
	Space used: 8892416 (+0 for this command)^M
	(gdb) print a^M
	$3 = {0 <repeats 2097152 times>}^M
	Space used: 8892416 (+0 for this command)^M
	  ...
	(gdb) print a^M
	$100 = {0 <repeats 2097152 times>}^M
	Space used: 8892416 (+0 for this command)^M
	...

	Note that the +0 here just means that the mallocs did not trigger an sbrk.
	This is dependent on malloc (which can use either mmap or sbrk or some
	pre-allocated memory) and will likely vary between different tunings, versions
	and implementations, so this does not give us a reliable way detect the
	problem in a minimal way.

	A more reliable way of detecting the problem is:
	...
	 void
	 value_free_to_mark (const struct value *mark)
	 {
	+  size_t before = all_values.size ();
	   auto iter = std::find (all_values.begin (), all_values.end (), mark);
	   if (iter == all_values.end ())
	     all_values.clear ();
	   else
	     all_values.erase (iter + 1, all_values.end ());
	+  size_t after = all_values.size ();
	+  if (before - after >= 1024)
	+    fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
	...
	which without the fix tells us:
	...
	+print a
	value_free_to_mark freed 2097152 items
	$1 = {0 <repeats 2097152 times>}
	...

	Fix a similar problem for Fortran:
	...
	+print array1
	value_free_to_mark freed 4194303 items
	$1 = (0, <repeats 2097152 times>)
	...
	in fortran_array_printer_impl::process_element.

	The problem also exists for Ada:
	...
	+print Arr
	value_free_to_mark freed 2097152 items
	$1 = (0 <repeats 2097152 times>)
	...
	but is fixed by the fix for C.

	Add Fortran and Ada variants of the test-case.  The *.exp files are similar
	enough to the original to keep the copyright years range.

	While writing the Fortran test-case, I ran into needing an additional print
	setting to print the entire array in repeat form, filed as PR exp/30817.

	I managed to apply the compilation loop for the Ada variant as well, but with
	a cumbersome repetition style.  I noticed no other test-case uses gnateD, so
	perhaps there's a better way of implementing this.

	The regression test included in the patch is formulated in its weakest
	form, to avoid false positive FAILs, which also means that smaller regressions
	may not get detected.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Modernize gdb.base/huge.exp
	Rewrite test-case gdb.base/huge.exp:
	- use build_executable rather than gdb_compile,
	- use save_vars,
	- factor out hardcoded loop limits min and max,
	- handle compilation failure using require, and
	- avoid using . in regexp to match $, {} and <>.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-14  Jan Beulich  <jbeulich@suse.com>

	x86: Vxy naming correction
	Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
	operand purpose isn't properly reflected in Vxy's definition. Rename
	"dst" to "src", thus bringing things in line with Exy.

2023-09-14  Jan Beulich  <jbeulich@suse.com>

	x86: support AVX10.1 vector size restrictions
	Recognize "/<number>" suffixes on both -march=+avx10.1 and the
	corresponding .arch directive, setting an upper bound on the vector size
	that insns may use. Such a restriction can be reset by setting a new base
	architecture, by using a suffix-less form, by disabling AVX10, or by
	enabling any other VEX/EVEX-based vector extension.

	While for most insns we can suppress their use with too wide operands
	via registers becoming unavailable (or in Intel syntax memory operand
	size specifiers not being recognized), mask register insns have to have
	their minimum required vector size specified in a new attribute. (Of
	course this new attribute could also be used on other insns.)

	Note that .insn continues to be permitted to emit EVEX{512,256} (and
	VEX256 ones) encodings regardless of vector size restrictions in place.
	Of course these can't be expressed using zmm (or ymm) operands then,
	but need using the EVEX.512.* forms (broadcast forms may be usable right
	now, but this may go away so shouldn't be relied upon). This is why no
	assertions should be added to build_{e,}vex_prefix().

2023-09-14  Jan Beulich  <jbeulich@suse.com>

	x86: support AVX10.1/512
	Since this is merely a re-branding of certain AVX512* features, there's
	little code to be added.

	The main aspect here are new testcases. In order to be able to re-use
	some of the existing testcases, several of them need their start symbols
	adjusted. Note that 256- and 128-bit tests want adding here, as these
	need to work right away. Subsequently they'll gain vector length
	constraints.

	Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
	test.

2023-09-14  Jan Beulich  <jbeulich@suse.com>

	x86: make AES/PCMULQDQ respectively prereqs of VAES/VPCMULQDQ
	These probably should have been put in place already anyway, but they're
	very much wanted in order to then put AVX10.1 support on top. Note that
	to avoid reverse dependencies towards SSE (just like we already do for
	AVX and XOP), add_isa_dependencies() needs some further tweaking.

	While there also address a related anomaly: Disabling AES but neither
	AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
	VEX-encoded forms available. Note that for this the VAES insns are moved
	past the AVX+AES ones, to avoid the property-11 test suddenly failing.
	The test really is wrong, but let's not also make things inconsistent:
	Without the movement, YMM use would be correctly recorded for the
	128-bit forms simply because the first template already matches, as long
	as VAES wasn't disabled.  Yet it still wouldn't be if only AVX+AES were
	enabled. Nor would behavior here then be the same as for VPCLMUL* insns.

2023-09-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-13  Jacob Navia  <jacob@jacob.remcomp.fr>

	Fix: "Missing NULL check"
	  * elf.c (_bfd_elf_init_reloc_shdr): Don't segfault on alloc fail.

2023-09-13  Alan Modra  <amodra@gmail.com>

	Fix: "Possible Memory leak in bed hash.c"
	  * elf-strtab.c (_bfd_elf_strtab_init): In the event of memory allocation failure, make sure that the hash table is freed.

2023-09-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb/mi: remove warning about mi1
	Remove a warning about mi1.  mi1 was removed in 975249ff4e26 ("Remove MI
	version 1").  It is no longer possible to reach this warning, since
	trying to use interpreter mi1 bails out before:

	    $ ./gdb -nx -q --data-directory=data-directory -i mi1
	    Interpreter `mi1' unrecognized

	Change-Id: Ie43b21e01bca1407995150c729531a70ee662003
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-12  Tom Tromey  <tromey@adacore.com>

	Avoid spurious breakpoint-setting failure in DAP
	A user pointed out that if a DAP setBreakpoints request has a 'source'
	field in a SourceBreakpoint object, then the gdb DAP implementation
	will throw an exception.

	While SourceBreakpoint does not allow 'source' in the spec, it seems
	better to me to accept it.  I don't think we should fully go down the
	"Postel's Law" path -- after all, we have the type-checker -- but at
	the same time, if we do send errors, they should be intentional and
	not artifacts of the implementation.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30820

2023-09-12  Enze Li  <enze.li@hotmail.com>

	gdb: Fix -Wuninitialized issue
	I see the following warning when building GDB on FreeBSD/amd64 with
	Clang 14,

	======================================================================
	  CXX    mdebugread.o
	mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized]
	                f->set_loc_enumval (tsym.value);
	                ^
	mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning
	        struct field *f;
	                       ^
	                        = nullptr
	======================================================================

	after digging a little, I realized that we can not simply do what
	Clang 14 says.

	The root cause of this issue is that we lost the initialization of
	the variable 'f' in this commit,

	  commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e
	  Date:   Thu Aug 31 09:37:44 2023 +0200

	      [gdb/symtab] Factor out type::{alloc_fields,copy_fields}

	we have made these modifications,

	 ---------------------------------------------------------------------
	 --- a/gdb/mdebugread.c
	 +++ b/gdb/mdebugread.c
	 @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,

	         t->set_code (type_code);
	         t->set_length (sh->value);
	 -       t->set_num_fields (nfields);
	 -       f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field)));
	 -       t->set_fields (f);
	 +       t->alloc_fields (nfields, false);
	 ---------------------------------------------------------------------

	The problem is that the variable 'f' is used in the second half of
	parse_symbol, that's why Clang complained.

	To fix this issue we need to ensure that the varibale 'f' is
	initialized.  Calling the fields method is an obvious way to fix this
	issue.

	Tested on FreeBSD/amd64 by rebuilding.

	Approved-By: Tom de Vries <tdevries@suse.de>

2023-09-12  Lancelot Six  <lancelot.six@amd.com>

	gdb/testsuite/rocm: fix rocm-multi-inferior-gpu.cpp
	The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a
	call to execl which does not have NULL as a last argument.  This is
	an invalid use of execl.  This patch fixes this oversight.

	Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-11  Tom Tromey  <tromey@adacore.com>

	Specialize std::hash for ptid_t
	This changes hash_ptid to instead be a specialization of std::hash.
	This makes it a little easier to use with standard containers.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-09-11  Tom Tromey  <tromey@adacore.com>

	Update Python signal-handling documentation
	I noticed a typo in the "Basic Python" node, and when fixing it
	realized that the paragraph could use a link to the block_signals
	function.  This patch is the result.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-09-11  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: use foreach_with_prefix in gdb.guile/scm-ports.exp
	Simplify things a bit using foreach_with_prefix.  The only expected
	change is in the naming of tests.

	Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-09-11  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	testsuite, fortran: Fix regression due to fix for ifort's 'start' behavior
	Got a regression email due to merge of commit in CI config
	tcwg_gdb_check/master-aarch64 :
	https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec

	Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above
	commit to start the test from running to line with tag "First Breakpoint"
	instead of "fortran_runto_main".  Reason of the regression is shared
	libraries are still loaded after hitting the breakpoint as "nosharedlibrary"
	is already called before hitting the breakpoint.

	So now after this change test is updated accordingly to disable and unload
	shared libraries symbols after hitting the first breakpoint.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-09-11  Markus Metzger  <markus.t.metzger@intel.com>

	gdb: c++ify btrace_target_info
	Following the example of private_thread_info and private_inferior, turn
	struct btrace_target_info into a small class hierarchy.

	Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into
	linux_btrace_target_info.

	Fixes PR gdb/30751.

2023-09-11  Markus Metzger  <markus.t.metzger@intel.com>

	gdb, btrace: move xml parsing into remote.c
	The code is only used in remote.c and all functions can be declared static.

2023-09-11  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs
	I see the following failure when running this test on an AMD machine:

	    p/x $fioff^M
	    $24 = 0x0^M
	    (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff

	The register that GDB calls fioff normally contains the address of the
	last instruction executed by the x87 unit.  It is available through the
	FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
	area.  You can read about it in the Intel manual [1] at section "10.5.1
	FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
	manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
	State".

	The test therefore expects that after executing the FLD1 instruction,
	the fioff register contains the address of the FLD1 instruction.

	However, the FXSAVE and XSAVE instructions (which the kernel uses to
	dump x87 register state which it provides GDB through ptrace) behave
	differently on AMD CPUs.  In section "11.4.4.3 FXSAVE and FXRSTOR
	Instructions" of the AMD manual, we read:

	    The FXSAVE and FXRSTOR instructions save and restore the entire
	    128-bit media, 64-bit media, and x87 state. These instructions
	    usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
	    not normally save and restore the x87 exception pointers
	    (last-instruction pointer, last data-operand pointer, and last
	    opcode). The only case in which they do save the exception pointers
	    is the relatively rare case in which the exception-summary bit in
	    the x87 status word (FSW.ES) is set to 1, indicating that an
	    unmasked exception has occurred.

	So, unless a floating point exception happened and that exception is
	unmasked in the x87 FPU control register (which isn't by default on
	Linux, from what I saw), the "last instruction address" register (or
	fioff as GDB calls it) will always be 0 on an AMD CPU.

	For this reason, I think it's fine to change the test to accept the
	value 0 - that's just how the processor works.

	I toyed with the idea of changing the test program to make it so the CPU
	would generate a non-zero fioff.  That is by unmasking an FPU exception
	and executing an instruction to raise that kind exception.  It worked,
	but then I would have to change the test more extensively, and it didn't
	seem to be worth it.

	[1] https://cdrdv2.intel.com/v1/dl/getContent/671200
	[2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf

	Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-09-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-09  Jinyang He  <hejinyang@loongson.cn>

	Make sure DW_CFA_advance_loc4 is in the same frag
	Do the same as commit b9d8f5601bcf in another place generating
	DW_CFA_advance_loc4.  The idea behind commit b9d8f5601bcf was that
	when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
	eh_frame_convert_frag we want to remove the opcode entirely, not just
	convert to a nop.  If the opcode was split over two frags then a size
	adjustment would need to be done to the first frag, not just the
	second as is correct for other cases with split frags.  This would
	complicate the eh relaxation.  It's easier to ensure the frag is not
	split.

		* ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4
		to be placed in a different frag to the rs_cfa.

2023-09-08  Tom Tromey  <tromey@adacore.com>

	Run 'black' on recent test case
	The auto-builders pointed out that I neglected to run 'black' after a
	rest testcase change.  This patch fixes the oversight.

2023-09-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Set insn_type for branch instructions on aarch64
	gprofng uses insn_type in print_address_func().
	But insn_type is always zero on aarch64.

	opcodes/ChangeLog:
	2023-09-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
		branch instructions.

2023-09-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb/doc: describe x87 registers
	While investigating this [1], I initially had no idea what register
	"fioff" stood for, making it difficult to map it to something in the
	Intel or AMD manuals.  Similarly, I can imaging someone familiar with
	x87 to want to print the "x87 last instruction address", and have no
	clue that GDB makes it available as register "fioff".  The names of the
	x87 state fields don't seem to be standardized, they even change between
	sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
	descriptions).

	Add some details to the doc to help one map GDB register names to x87
	state fields.

	[1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u

	Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762
	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-09-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb/doc: rename "x86 Architecture-specific Issues" section to "x86"
	I'm looking to add some x86-specific information to the doc, but I find
	the naming of this section odd.  It doesn't really talk about issues, it
	just gives generally useful information.  Also, the sections about other
	architectures don't mention "issues", just the architecture name.

	Also, at least in the HTML version of the doc, the name is inconsistent
	between the main table of content, where it appears as "x86
	Architecture-specific Issues", and the sub-table of contents of the
	"Architectures" section, where it appears as "i386".

	Rename the section to just "x86".

	Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca
	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-09-08  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Remove unused function
	set_expected_error is no longer used.  It has been replaced by
	more specific error messages.

2023-09-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make gdb.dwarf2/dwzbuildid.exp more robust
	I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
	and noticed that compilation failure for one exec prohibited testing of all
	execs.

	Fix this by restructuring the test-case, such that we have:
	...
	PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
	PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
	UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
	UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
	...

	Tested on x86_64-linux.

2023-09-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add kfail in gdb.dwarf2/dwzbuildid.exp
	When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
	get:
	...
	(gdb) file dwzbuildid-mismatch^M
	Reading symbols from dwzbuildid-mismatch...^M
	warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
	could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
	(gdb) delete breakpoints^M
	(gdb) info breakpoints^M
	No breakpoints or watchpoints.^M
	(gdb) break -qualified main^M
	No symbol table is loaded.  Use the "file" command.^M
	Make breakpoint pending on future shared library load? (y or [n]) n^M
	(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
	...

	This is PR symtab/26797: when using readnow, a failure in reading the dwarf
	results in the minimal symbols not being available.

	Add a corresponding KFAIL.

	Tested on x86_64-linux.

2023-09-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add aranges in gdb.dwarf2/dwzbuildid.exp
	While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
	into a warning:
	...
	$ readelf -w dwzbuildid-ok > READELF
	readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
	point to a CU header.
	...

	AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.

	While looking at the .debug_aranges section, I noticed that the entries for
	the CUs generated by the dwarf assembler are missing.

	Fix this by adding the missing .debug_aranges entries.

	Tested on x86_64-linux.

2023-09-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix build-ids in gdb.dwarf2/dwzbuildid.exp
	When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
	readelf, I run into:
	...
	$ readelf -w dwzbuildid-ok > READELF
	readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
	readelf: Warning: Build-ID is too short (0x6 bytes)
	...

	Fix this by ensuring the Build-IDs are the required 20 bytes.

	Tested on x86_64-linux.

2023-09-08  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix gdb.mi/mi-condbreak-throw.exp failure
	In commit:

	  commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae
	  Date:   Tue Aug 8 10:45:20 2023 +0100

	      gdb: MI stopped events when unwindonsignal is on

	a new test, gdb.mi/mi-condbreak-throw.exp, was added.  Unfortunately,
	this test would fail when using the native-gdbserver board (and other
	similar boards).

	The problem was that one of the expected output patterns included some
	output from the inferior.  When using the native-gdbserver board, this
	output is not printed to GDB's tty, but is instead printed to
	gdbserver's tty, the result is that the expected output no longer
	matches, and the test fails.

	Additionally, as the output is actually from the C++ runtime, rather
	than the test's source file, changes to the C++ runtime could cause
	the output to change.

	To solve both of these issues, in this commit, I'm removing the
	reference to the inferior's output, and replacing it with '.*', which
	will skip the output if it is present, but is equally happy if the
	output is not present.

	After this commit gdb.mi/mi-condbreak-throw.exp now passes on all
	boards, including native-gdbserver.

2023-09-08  Jan Beulich  <jbeulich@suse.com>

	x86: restrict prefix use with .insn VEX/XOP/EVEX
	Avoid triggering the respective abort() in output_insn().

2023-09-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove interp_supports_command_editing
	It is a trivial wrapper around the supports_command_editing method,
	remove it.

	Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove interp_pre_command_loop
	It is a trivial wrapper around the pre_command_loop method, remove it.

	Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-07  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	testsuite, fortran: make kfail gfortran specific
	The modified test in function-calls.exp actually passes with ifort and
	ifx.  The particular fail seems to be specific to gfortran.  When the
	test was introduced it was only tested with gfortran (actually the
	whole patch was written with gfortran and the GNU Fortran argument
	passing convention in mind).

	Approved-by: Tom Tromey <tom@tromey.com>

2023-09-07  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	testsuite, fortran: adapt tests for ifort's 'start' behavior
	The modified tests array-slices-bad.exp and vla-type.exp both set a
	breakpoint at the first real statement in the respective executables.

	Normally, the expected behavior of fortran_runto_main for these would be
	the stopping of the debugger at exactly the first statment in the code.

	Strangely, neither gfortran nor ifx seem to do this for these tests.
	Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB
	stop at the 'program ...' line and gfortran stops at a variable
	declaration line.  E.g. for vla-type it stops at

	  41        type(five)               :: fivearr (2)

	So, actually, ifort's behavior can be considered to be a bit more
	'correct' here.  This patch remove the fortran_runto_main in the
	two tests and instead uses runto to directly run to the first breakpoint
	set at the first program statement.  This works with both compiler
	behaviors and makes the tests more robust.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-09-07  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	testsuite, fortran: Remove self assignment non-statements
	There were a couple of places in the testsuite where instructions like

	  var = var

	were written in the source code of tests.  These were usually dummy
	statements meant to generate a line table entry at that line on which
	to break later on.

	This worked fine for gfortran and ifx, but it seems that, when compiled
	with ifort (2021.6.0) these statements do not actually create any
	assmbler instructions and especially no line table entries.  Consider
	the program

	  program test
	    Integer var :: var = 1
	    var = var
	  end program

	compiled with gfortran (13.0.0, -O0 -g).  The linetable as emitted by
	'objdump --dwarf=decodedline ./a.out' looks like

	  test.f90:
	  File name   Line number    Starting address    View    Stmt
	  test.f90              1            0x401172               x
	  test.f90              3            0x401176               x
	  test.f90              4            0x401182               x
	  test.f90              4            0x401185               x
	  test.f90              4            0x401194               x
	  test.f90              -            0x4011c0

	actually containing line table info for line 3.  Running gdb, breaking
	at 3 and checking the assembly we see

	   0x0000000000401172 <+0>:     push   %rbp
	   0x0000000000401173 <+1>:     mov    %rsp,%rbp
	=> 0x0000000000401176 <+4>:     mov    0x2ebc(%rip),%eax   # 0x404038 <var.1>
	   0x000000000040117c <+10>:    mov    %eax,0x2eb6(%rip)   # 0x404038 <var.1>
	   0x0000000000401182 <+16>:    nop
	   0x0000000000401183 <+17>:    pop    %rbp
	   0x0000000000401184 <+18>:    ret

	so two mov instructions are being issued for this assignment one copying
	the value into a register and one writing it back to the same memory.
	Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here
	and also has no line table entry:

	  test.f90:
	  File name   Line number    Starting address    View    Stmt
	  test.f90              1            0x4040f8               x
	  test.f90              4            0x404109               x
	  test.f90              4            0x40410e               x
	  test.f90              -            0x404110

	As I do not think that this is really a bug (on either side, gfortran/ifx or
	ifort), and as I don't think this behavior is covered in the Fortran
	standard, I changed these lines to become actual value assignments.

	This removes a few FAILs in the testsuite when ran with ifort.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-09-07  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	testsuite, fortran: make mixed-lang-stack less compiler dependent
	In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
	bunch of nested function calls we issue and test a 'info args' command
	for the mixed_func_1b function (when in that function's frame).

	The signature of the function looks like

	  subroutine mixed_func_1b(a, b, c, d, e, g)
	    use type_module
	    implicit none

	    integer :: a
	    real(kind=4) :: b
	    real(kind=8) :: c
	    complex(kind=4) :: d
	    character(len=*) :: e
	    character(len=:), allocatable :: f
	    TYPE(MyType) :: g

	and usually one would expect arguments a, b, c, d, e, and g to be
	emitted here.  However, due to some compiler dependent treatment of the
	e array the actual output in the test (with gfortran/ifx) is

	  (gdb) info args
	  a = 1
	  b = 2
	  c = 3
	  d = (4,5)
	  e = 'abcdef'
	  g = ( a = 1.5, b = 2.5 )
	  _e = 6

	where the compiler generated '_e' is emitted as the length of e.  While
	ifort also generates an additional length argument, the naming (which is
	up to the compilers here I think, I could not find anything in the
	Fortran standard about this) is different and we see

	  (gdb) info args
	  a = 1
	  b = 2
	  c = 3
	  d = (4,5)
	  e = 'abcdef'
	  g = ( a = 1.5, b = 2.5 )
	  .tmp.E.len_V$4a = 6

	To make both outputs pass the test, I kept the additional argument for now and
	made the regex for the emitted name of the last variable match any
	arbitrary name.

	Approved-by: Tom Tromey <tom@tromey.com>

2023-09-07  Ijaz, Abdul B  <abdul.b.ijaz@intel.com>

	gdb: add Abdul Basit Ijaz to gdb/MAINTAINERS

2023-09-07  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: Add a testcase for bundles with KVXMAXBUNDLEWORDS syllables
		* testsuite/gas/kvx/fat-bundles.s: New test.
		* testsuite/gas/kvx/kv3-1-fat-bundles.d: New test.
		* testsuite/gas/kvx/kv3-2-fat-bundles.d: New test.

2023-09-07  Alan Modra  <amodra@gmail.com>

	PR30793, kvx_reassemble_bundle index 8 out of bounds
	While the patch already committed for pr30793 prevents the asan error,
	there is a problem: Now the last element of bundle_words never gets
	written.  That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
	So this patch rearranges things a little to support writing of all of
	bundle_words and does the parallel bit checking only when filling
	bundle_words.  In the normal case, kvx_reassemble_bundle will see
	bundle_words[word_count-1] with the parallel bit clear and all other
	words having it set.  In the error case where all words in
	bundle_words have the parallel bit set, kvx_reassemble_bundle will be
	passed a wordcount of KVXMAXBUNDLEWORDS + 1.  I've also made
	kvx_reassemble_bundle return true for success rather than zero, and
	removed the unnecessary check for zero wordcount.

		PR 30793
		* kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
		Fail if wordcount is too large.  Don't check for wordcount zero.
		Don't check kvx_has_parallel_bit.
		(print_insn_kvx): Rewrite code reading bundle_words as a for loop.
		Don't stop reading at KVXMAXBUNDLEWORDS - 1.
		(decode_prologue_epilogue_bundle): Similarly.

2023-09-07  Tom Tromey  <tromey@adacore.com>

	Fix bug in -var-evaluate-expression
	This bug points out that if one uses -var-set-visualizer with "None"
	-- to disable a pretty-printer for a varobj -- then
	-var-evaluate-expression will still use pretty-printing.

	This is a combination of bugs.  First, setting the visualizer does not
	update the display text; and second, computing the display text should
	use "raw" when Python is available but no visualizer is desired.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-09-07  Tom Tromey  <tromey@adacore.com>

	Remove variable_default_display
	variable_default_display has a single caller now, so remove it.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-09-07  Tom Tromey  <tromey@adacore.com>

	Remove dead code from varobj_set_display_format
	varobj_set_display_format takes an enum and exhaustively switches on
	the values -- but also has a default.  This default case is dead code.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-09-07  Tom Tromey  <tromey@adacore.com>

	Allow pretty-printer 'children' method to return strings
	A user noticed that, while a pretty-printer can return Python strings
	from its "children" method, this does not really work for MI.  I
	tracked this down to my_value_of_variable calling into
	c_value_of_variable, which specially handles arrays and structures --
	not using the actual contents of the string.

	Now, this part of MI seems bad to me, but rather than change that,
	this applies the fix to only dynamic varobjs, which is the only
	scenario where a string like this can really be returned.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-09-07  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix gdb-index writing for .debug_types
	With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run
	into:
	...
	(gdb) print red^M
	No definition of "red" in current context.^M
	(gdb) FAIL: gdb.ada/same_enum.exp: print red
	...

	[ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"),
	so this is broken in gdb 12 and 13. ]

	The easiest way to see what's going wrong is with readelf.  We have in section
	.gdb_index:
	...
	[7194] pck__red:
	        2 [static, variable]
	        3 [static, variable]
	...
	which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but
	should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and
	"T3").

	Fix this by removing the counter / types_counter distinction in
	write_gdbindex, such that we get the expected:
	...
	[7194] pck__red:
	        T2 [static, variable]
	        T3 [static, variable]
	...

	[ While reading write_gdbindex I noticed a few oddities related to dwz
	handling, I've filed PR30829 about this. ]

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30827
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827

2023-09-07  Tom de Vries  <tdevries@suse.de>

	[gdb/ada] Extend type equivalence test in ada_resolve_enum
	When running test-case gdb.ada/local-enum.exp with target board debug-types, I
	run into:
	...
	(gdb) print v1(three)^M
	No name 'three' in enumeration type 'local__e1'^M
	(gdb) FAIL: gdb.ada/local-enum.exp: print v1 element
	...

	The array V1 is of type A1 which is an array with index type E1, containing
	"three" as enumerator:
	...
	  type E1 is (one, two, three);
	  type A1 is array (E1) of Integer;
	  V1 : A1 := (0, 1, 2);
	...

	There's also a type E2 that contains three as enumerator:
	...
	  type E2 is (three, four, five);
	...

	When doing "print v1(three)", it's the job of ada_resolve_enum to resolve
	"three" to type E1 rather than type E2.

	When using target board debug-types, the enums E1 and E2 are replicated in the
	.debug_types section, and consequently in ada_resolve_enum the type
	equivalence check using a pointer comparison fails:
	...
	  for (int i = 0; i < syms.size (); ++i)
	    {
	      /* We already know the name matches, so we're just looking for
		 an element of the correct enum type.  */
	      if (ada_check_typedef (syms[i].symbol->type ()) == context_type)
	 	return i;
	    }
	...

	Fix this by also trying a structural comparison using
	ada_identical_enum_types_p.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR ada/29335
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335

2023-09-07  Tom de Vries  <tdevries@suse.de>

	[gdb/ada] Move identical enums handling later
	When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
	cc-with-dwz, I run into:
	...
	(gdb) print enum_with_gaps'enum_rep(lit3)^M
	'Enum_Rep requires argument to have same type as enum^M
	(gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
	...

	With target_board unix, we have instead:
	...
	(gdb) print enum_with_gaps'enum_rep(lit3)^M
	$16 = 13^M
	(gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
	...

	Conversely, when I add this test to the test-case:
	...
	     gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
	 	"enum_rep"
	+    gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
	+	"other enum_rep"
	...
	the extra test passes with target board cc-with-dwz, but fails with target
	board unix.

	The problem is here in remove_extra_symbols:
	...
	  if (symbols_are_identical_enums (syms))
	    syms.resize (1);
	...
	where one of the two identical enums is picked before the enum_rep handling
	can resolve lit3 to one of the two.

	Fix this by moving the code to ada_resolve_variable.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR ada/30726
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726

2023-09-07  Tom Tromey  <tom@tromey.com>

	Simplify block_find_symbol
	block_find_symbol takes a callback function, but only two callbacks
	are ever passed to it -- and they are similar enough that it seems
	cleaner to just have block_find_symbol do the work itself.  Also,
	block_find_symbol can take a lookup_name_info as an argument,
	following the general idea of pushing the construction of these
	objects as high in the call chain as feasible.

	Regression tested on x86-64 Fedora 38.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2023-09-07  Simon Marchi  <simon.marchi@efficios.com>

	gdb/mi: make current_token a field of mi_interp
	Following the commit f818c32ba459 ("gdb/mi: fix ^running record with
	multiple MI interpreters"), I thought it would make sense to make
	current_token a field of mi_interp.  This variable contains the token of
	the currently handled MI command, like the 222 in:

	    222-exec-continue

	I didn't find any bug related to that, it's just a "that seems nicer"
	cleanup, since the current token is a fundamentally per-interp thing.

	mi_execute_command needs a check similar to what we already have in
	mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current
	interpreter is not an mi_interp.  When using the Python gdb.execute_mi
	function, there is no such concept of token, so we can just skip that.

	There should be no user-visible change.

	Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-07  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix indentation in mi/mi-parse.h
	Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8

2023-09-07  cailulu  <cailulu@loongson.cn>

	Add testcase for generation of 32/64_PCREL.

2023-09-07  cailulu  <cailulu@loongson.cn>

	Use 32/64_PCREL to replace a pair of ADD32/64 and SUB32/64.
	Subtraction for labels that require static relocation
	usually generates ADD32/64 and SUB32/64.

	If subsy of BFD_RELOC_32/64 and PC in same segment,
	and disable relax or PC at start of subsy or enable
	relax but not in SEC_CODE, we generate 32/64_PCREL
	to replace a pair of ADD32/64 and SUB32/64.

2023-09-07  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Clarify the naming rules of vendor operands.
	The vendor operands should be named starting with `X', and preferably the
	second letter (or multiple following letters) is enough to differentiate
	them from other vendors.

	Therefore, added letter `t' after `X' for t-head operands, to differentiate
	from future different vendor's operands.

	bfd/
		* elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
		document link since it should already be recorded in the
		gas/doc/c-riscv.texi.
	gas/
		* config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
		t-head operands.  Minor updates for indents and comments.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Minor updates.
	opcodes/
		* riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
		operands.  Minor updates for indents and comments.
		* riscv-opc.c (riscv_opcode): Likewise.

2023-09-07  Roland McGrath  <mcgrathr@google.com>

	gold: Use char16_t, char32_t instead of uint16_t, uint32_t as character types
	The std::basic_string template type is only specified for
	instantiations using character types.  Newer (LLVM) libc++
	implementations no longer allow non-character integer types
	to be used.

	gold/
		* output.cc: Include <uchar.h>.
		(Output_section::add_merge_input_section): Use char16_t and
		char32_t for 2- and 4-byte entry size, respectively.
		* stringpool.cc: Include <uchar.h>.
		(Stringpool_template): Explicitly instantiate for char16_t,
		char32_t instead of uint16_t, uint32_t.
		* merge.cc (Output_merge_string): Likewise.

2023-09-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-07  Alan Modra  <amodra@gmail.com>

	PR30828, notes obstack memory corruption
	Commit 3bab069c29b3 carelessly allowed "string" to be released from
	the notes obstack twice, with the second call to obstack_free
	releasing memory for a fixup that just happened to be the same size as
	the original string.  The fixup then of course was overwritten.
	This patch fixes that problem, and another that could occur on an
	error path.

		PR 30828
		* stabs.c (s_stab_generic): Don't free string twice.  Don't
		blow away entire notes obstack on a missing string.

2023-09-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/same_enum.exp
	Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
	bit of code in remove_extra_symbols:
	...
	  if (symbols_are_identical_enums (syms))
	    syms.resize (1);
	...

	The test-case does "print red" and expects one of these two choices to be
	picked by remove_extra_symbols:
	...
	  type Color is (Black, Red, Green, Blue, White);
	  type RGB_Color is new Color range Red .. Blue;
	...
	but because only the type Color is used:
	...
	  FC : Color := Red;
	  SC : Color := Green;
	...
	the RGB_Color type is eliminated from the debug info, and consequently
	remove_extra_symbols has no effect for the test-case.

	In other words, we have:
	...
	(gdb) ptype Color ^M
	type = (black, red, green, blue, white)^M
	(gdb) ptype RGB_Color^M
	No definition of "rgb_color" in current context.^M
	...

	Fix this by changing the type of SC to RGB_Color, and add prints of the two
	types to check that they're both available.

	With the test-case fixed, if we disable the bit of code in
	remove_extra_symbols we get:
	...
	(gdb) print red^M
	Multiple matches for red^M
	[0] cancel^M
	[1] pck.color'(pck.red) (enumeral)^M
	[2] pck.rgb_colorB'(pck.red) (enumeral)^M
	> FAIL: gdb.ada/same_enum.exp: print red (timeout)
	...
	in other words, the test-case now properly functions as a regression test.

	Tested on x86_64-linux.

2023-09-06  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix too many symbols in gdbpy_lookup_static_symbols
	When running test-case gdb.python/py-symbol.exp with target board
	cc-with-dwz-m, we run into:
	...
	(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
	4^M
	(gdb) FAIL: gdb.python/py-symbol.exp: \
	  print (len (gdb.lookup_static_symbols ('rr')))
	...
	while with target board unix we have instead:
	...
	(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
	2^M
	(gdb) PASS: gdb.python/py-symbol.exp: \
	  print (len (gdb.lookup_static_symbols ('rr')))
	...

	The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits
	representing both CUs and PUs:
	...
	 	  for (compunit_symtab *cust : objfile->compunits ())
	...

	When doing a lookup on a PU, the user link is followed until we end up at a CU,
	and the lookup is done in that CU.

	In other words, when doing a lookup in the loop for a PU we duplicate the
	lookup for a CU that is already handled by the loop.

	Fix this by skipping PUs in the loop in gdb.lookup_static_symbols.

	Tested on x86_64-linux.

	PR symtab/25261
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261

2023-09-06  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle PU in iterate_over_some_symtabs
	When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
	run into:
	...
	(gdb) info line 1^M
	Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
	Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
	(gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
	...
	while the expected output is:
	...
	Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
	��setshow.c:1:0:beg:0x400527
	...

	The second line of the expected output is missing due to the first line of the
	expected output being repeated, so the problem is that the "Line 1" line is
	printed twice.

	This happens because the PU imported by the CU reuses the filetab of the CU,
	and both the CU and PU are visited by iterate_over_some_symtabs.

	Fix this by skipping PUs in iterate_over_some_symtabs.

	Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30797
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797

2023-09-06  Hans-Peter Nilsson  <hp@axis.com>

	src-release.sh (SIM_SUPPORT_DIRS): Add libsframe, libctf/swap.h and gnulib
	Without this, a simulator build breaks when building from a tarball
	made by "./src-release.sh -b sim", when building e.g. bfd and
	libsframe.  See also previous similar commits for GDB_SUPPORT_DIRS.

	The libctf library does not needed to be built, but building
	libsframe requires libctf/swap.h, with no dependencies on built or
	configured contents.  Do as for the single gdb files and include
	explicitly only that file.

2023-09-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Fix 30808 gprofng tests failed
	In gprofng testing, we need a tempory gprofng installation to resolve run-time
	dependencies on libraries (libgprofng, libopcodes, libbfd, etc).
	We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and
	configuration file. These variables must be set for all gprofng tests.

	Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>.

	gprofng/ChangeLog
	2023-08-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30808
		* testsuite/config/default.exp: Make a temporary install dir.
		Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR.
		* testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and
		GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp.

2023-09-05  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite: Make hook-stop.exp ignore termination message from GDB stub
	When a GDB stub is run via "target remote |", it sometimes produces
	extra output that ends up mixed with GDB's own output.  For example,
	QEMU's built-in GDB stub responds to the vKill packet by printing

	nios2-elf-qemu-system: QEMU: Terminated via GDBstub

	before exiting.

	This patch fixes the regexp in gdb.base/hook-stop.exp to allow such
	messages between GDB's "continuing" and "Inferior killed" messages.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-05  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite: Disable some tests that are broken on remote Windows host
	These testcases assume host==build or that the remote host has a Posix
	shell to run commands in.  Don't try to run them if that's not the case.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-05  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite: Adjust some testcases to allow Windows pathnames
	This patch fixes some testcases that formerly had patterns with
	hardwired "/" pathname separators in them, which broke when testing on
	(remote) Windows host.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-05  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite: Fix style.exp failures on targets without argc/argv support
	Some embedded targets don't have full support for argc/argv.  argv
	may print as "0x0" or as an address with a symbol name following.
	This causes problems for the regexps in the style.exp line-wrapping
	tests that assume it always prints as an ordinary address in backtrace
	output.

	This patch generalizes the regexps to handle these additional forms
	and reworks some of the line-wrapping tests to account for the argv
	address string being shorter or longer than a regular address.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Handle array- and string-like values in no-op pretty printers
	This changes the no-op pretty printers -- used by DAP -- to handle
	array- and string-like objects known by the gdb core.  Two new tests
	are added, one for Ada and one for Rust.

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Add new Python APIs to support DAP value display
	gdb's language code may know how to display values specially.  For
	example, the Rust code understands that &str is a string-like type, or
	Ada knows how to handle unconstrained arrays.  This knowledge is
	exposed via val-print, and via varobj -- but currently not via DAP.

	This patch adds some support code to let DAP also handle these cases,
	though in a somewhat more generic way.

	Type.is_array_like and Value.to_array are added to make Python aware
	of the cases where gdb knows that a structure type is really
	"array-like".

	Type.is_string_like is added to make Python aware of cases where gdb's
	language code knows that a type is string-like.

	Unlike Value.string, these cases are handled by the type's language,
	rather than the current language.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Select frame when fetching a frame variable in DAP
	Right now, if a program uses multiple languages, DAP value formatting
	will always use the language of the innermost frame.  However, it is
	better to use the variable's defining frame instead.  This patch does
	this by selecting the frame first.

	This also fixes a possibly latent bug in the "stepOut" command --
	"finish" is sensitive to the selected frame, but the DAP code may
	already select other frames when convenient.  The DAP stepOut request
	only works on the newest frame, so be sure to select it before
	invoking "finish".

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Introduce type::is_array_like and value_to_array
	This adds the type::is_array_like method and the value_to_array
	function.

	The former can be used to see whether a given type is known to be
	"array-like".  This is the currently the case for certain
	compiler-generated structure types; in particular both the Ada and
	Rust compilers do this.

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Use ada_value_subscript in valpy_getitem
	Ada has a few complexities when it comes to array handling.  Currently
	these are all handled in Ada-specific code -- but unfortunately that
	means they aren't really accessible to Python.

	This patch changes the Python code to defer to Ada when given an Ada
	array.  In order to make this work, one spot in ada-lang.c had to be
	updated to set the "GNAT-specific" flag on an array type.

	The test case for this will come in a later patch.

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Introduce TYPE_SPECIFIC_RUST_STUFF
	This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes
	the DWARF reader to set this on Rust types.  This will be used as a
	flag in a later patch.

	Note that the size of the type_specific_field bitfield had to be
	increased.  I checked that this did not impact the size of main_type.

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Refactor Rust code for slice-to-array operation
	This patch exposes rust_slice_type_p and introduces
	rust_slice_to_array, in preparation for subsequent patches that will
	need these.

	Move rust_language::lookup_symbol_nonlocal
	This moves rust_language::lookup_symbol_nonlocal to rust-lang.c.
	There's no need to have it in rust-lang.h and moving it lets us avoid
	adding new includes in a later patch.

2023-09-05  Ciaran Woodward  <ciaranwoodward@xmos.com>

	gdb/riscv: Fix oob memory access when printing info registers
	If the length of a register name was greater than 15,
	print_spaces was called with a negative number, which
	prints random data from the heap instead of the requested
	number of spaces.

	This could happen if a target-description file was used
	to specify additional long-named registers.

	Fix is simple - don't ask for fewer than 1 space (since
	we still want column separation).

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Read Ada main name from executable, not inferior
	An upstream bug report points out this bug: if the user switches from
	one Ada executable to another without "kill"ing the inferior, then the
	"start" command will fail.

	What happens here is that the Ada "main" name is found in a constant
	string in the executable.  But, if the inferior is running, then the
	process_stratum target reads from the inferior memory.

	This patch fixes the problem by changing the main name code to set
	trust-readonly-sections, causing the target stack to read from the
	executable instead.

	I looked briefly at changing GNAT to emit DW_AT_main_subprogram
	instead, but this looks to be pretty involved.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811

2023-09-05  Tom Tromey  <tromey@adacore.com>

	Avoid crash with Ada and -fdata-sections
	A user noticed that gdb would crash when showing a backtrace.
	Investigation showed this to be a crash in the DWARF reader when
	handling a "pragma export" symbol.  The bug here is that earlier code
	decides to eliminate the symbol, but the export code tries to add it
	anyway -- but to a NULL list.

2023-09-05  Nick Clifton  <nickc@redhat.com>

	readelf: Add option to display the names of sections referenced by symbols.
	  PR 30684
	  * readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function.  Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function.
	  * doc/binutils.texi: Document the new option.
	  * NEWS: Mention the new feature.

2023-09-05  Jan Beulich  <jbeulich@suse.com>

	RISC-V: fold duplicate code in vector_macro()
	There's no need to have almost identical code twice. Do away with
	M_VMSGEU and instead simply use an unused (for these macros) field to
	tell apart both variants.

2023-09-05  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add stub support for the 'Svadu' extension
	This commit implements support for 'Svadu' extension.  Because it does not
	add any instructions or CSRs (but adds bits to existing CSRs), this commit
	only adds extension name support and implication to the 'Zicsr' extension.

	This is based on the "Hardware Updating of PTE A/D Bits (Svadu)"
	specification, version 1.0-rc1 (Frozen):
	<https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add implication from
		'Svadu' to 'Zicsr'.  (riscv_supported_std_s_ext) Add 'Svadu'.

2023-09-05  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Fix typo in the testsuite
	gas/ChangeLog:

		* testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded
		by minstretcfg, not mcyclecfg.

2023-09-05  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add 'Smcntrpmf' extension and its CSRs
	This commit adds now stable and approved 'Smcntrpmf' extension defined by
	the RISC-V Cycle and Instret Privilege Mode Filtering specification.

	Note that, because mcyclecfg and minstretcfg CSRs conflict with the
	privileged specification version 1.9.1, CSRs for this extension are only
	enabled on the privileged specification version 1.10 or later.

	By checking the base privileged specification, we no longer need to change
	the design of base CSR handling.

	This is based on the specification version v1.0_rc1 (Frozen):
	<https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from
		the new 'Smcntrpmf' extension.  (riscv_supported_std_s_ext): Add
		'Smcntrpmf' to the supported S extension list.

	gas/ChangeLog:

		* config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes
		CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32.
		(riscv_csr_address): Add handling for new CSR classes.
		* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.  Move
		"mscounteren" and "mhcounteren" CSRs and note that they are now
		aliases.
		* testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change.
		* testsuite/gas/riscv/csr.s: Add new CSRs.  Move "mscounteren"
		and "mhcounteren" CSRs and note that they are now reused for
		the 'Smcntrpmf' extension.
		* testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of
		csr.s.
		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

	include/ChangeLog:

		* opcode/riscv-opc.h: Add new CSRs noting that this extension is
		incompatible with the privileged specification version 1.9.1.
		Move "mscounteren" and "mhcounteren" CSRs, make them aliases and
		reuse the CSR numbers from the 'Smcntrpmf' extension.
		(CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and
		"mhcounteren" are now aliases and new CSR macros are used instead.
		(CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH):
		New CSR macros.

2023-09-05  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Prohibit combination of 'E' and 'H'
	According to the ratified privileged specification (version 20211203),
	it says:

	> The hypervisor extension depends on an "I" base integer ISA with 32 x
	> registers (RV32I or RV64I), not RV32E, which has only 16 x registers.

	Also in the latest draft, it also prohibits RV64E with the 'H' extension.
	This commit prohibits the combination of 'E' and 'H' extensions.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and
		'H' combinations.

	gas/ChangeLog:

		* testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to
		make sure that RV32E + 'H' is prohibited.
		* testsuite/gas/riscv/march-fail-rv32eh.l: Likewise.

2023-09-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-04  Christophe Lyon  <christophe.lyon@linaro.org>

	arm: Make 'conflicting CPU architectures' error message more user-friendly
	Error messages such as "conflicting CPU architectures 10/16" are not
	very to understand, so this patch replaces the numbers with the
	description they actually mean:
	"conflicting CPU architectures ARM v7E-M vs Pre v4"

	2023-09-01  Christophe Lyon  <christophe.lyon@linaro.org>

		bfd/
		* elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and
		use it.
		(elf32_arm_merge_eabi_attributes): Update call to
		tag_cpu_arch_combine.

		ld/
		* testsuite/ld-arm/attr-merge-9.out: Update expected error
		message.
		* testsuite/ld-arm/attr-merge-arch-2.d: Likewise.

2023-09-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix race in gdb.base/add-symbol-file-attach.exp
	When running test-case gdb.base/add-symbol-file-attach.exp with target board
	unix/-m32, we run into:
	...
	(gdb) attach 3955^M
	Attaching to process 3955^M
	Load new symbol table from "add-symbol-file-attach"? (y or n) y^M
	Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M
	Reading symbols from /lib/libm.so.6...^M
	Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M
	Reading symbols from /lib/libc.so.6...^M
	Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M
	Reading symbols from /lib/ld-linux.so.2...^M
	Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M
	0xf7f53549 in __kernel_vsyscall ()^M
	(gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach
	...

	The test fails because this regexp is used:
	...
	    -re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" {
	...

	The regexp attempts to detect that the exec is somewhere in pause ():
	...
	int
	main (int argc, char **argv)
	{
	  pause ();
	  return 0;
	}
	...
	but when the exec is blocked in pause, the backtrace is:
	...
	 (gdb) bt
	 #0  0xf7fd2549 in __kernel_vsyscall ()
	 #1  0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
	 #2  0x0804844c in main (argc=1, argv=0xffffce84)
	     at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26
	...

	We could simply extend the regexp to also match __kernel_vsyscall, but the
	more fundamental problem is that the test is racy.

	The attach can happen before the exec is blocked in pause (), somewhere in the
	dynamic linker resolving the call to pause, in main or even earlier.

	Note that for the test-case to be effective, the exec is not required to be in
	pause ().  I added a "while (1);" loop at the start of main, reverted the
	patch fixing the corresponding PR and reproduced the problem it's supposed to
	detect.

	Fix this by simply matching the "Reading symbols from" line, similar to what
	an earlier test is doing.

	While we're at it, rewrite the earlier test to also use the -wrap idiom.

	Tested on x86_64-linux.

2023-09-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-02  Simon Marchi  <simon.marchi@efficios.com>

	gdbserver: i387_cache_to_xsave: fix copy dest of zmm registers
	On a machine with AVX512 support (AMD EPYC 9634), I see these failures:

	    $ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
	    ...
	    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs
	    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs
	    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs
	    ...

	The problem can be reduced to:

	    (gdb) print $zmm16.v8_int64
	    $1 = {0, 0, 0, 0, 0, 0, 0, 0}
	    (gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88}
	    $2 = {11, 22, 33, 44, 55, 66, 77, 88}
	    (gdb) print $zmm16.v8_int64
	    $3 = {11, 22, 33, 44, 55, 66, 77, 88}
	    (gdb) step
	    5               ++x;
	    (gdb) print $zmm16.v8_int64
	    $4 = {11, 22, 77, 88, 0, 0, 0, 0}

	Writing to the local regcache in GDB works fine, but the writeback to
	gdbserver (which happens when resuming / stepping) doesn't work (the
	code being stepped doesn't touch AVX registers, so we don't expect the
	value of zmm16 to change when stepping).

	The problem is on the gdbserver side, the zmmh and ymmh portions of the
	zmm register are not memcpied at the right place in the xsave buffer.  Fix
	that.  Note now how the two modified memcpy calls match the memcmp calls
	just above them.

	With this patch, gdb.arch/i386-avx512.exp passes completely for me.

	Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818

2023-09-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-01  Joseph Myers  <joseph@codesourcery.com>

	config: Fix host -rdynamic detection for build != host != target
	[Merge from GCC commit 4d9bc81a5d8d884dee7a7781fa4c1577a6c9681a.]

	The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic
	is necessary and supported uses an appropriate objdump for $host
	binaries (running on $build) in cases where $host is $build or
	$target.

	However, it is missing such logic in the case where $host is neither
	$build nor $target, resulting in the compilers not being linked with
	-rdynamic and plugins not being usable with such a compiler.  In fact
	$ac_cv_prog_OBJDUMP, as used when $build = $host, is always an objdump
	for $host binaries that runs on $build; that is, it's appropriate to
	use in this case as well.

	Tested in such a configuration that it does result in cc1 being linked
	with -rdynamic as expected.  Also bootstrapped with no regressions for
	x86_64-pc-linux-gnu.

	config/
		* gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Use
		export_sym_check="$ac_cv_prog_OBJDUMP -T" also when host is not
		build or target.

2023-09-01  Tom Tromey  <tromey@adacore.com>

	Fix "usage" errors for some MI varobj commands
	I noticed that the "usage" error for -var-set-frozen mentioned the
	wrong command name.  Then I looked through the whole file and found a
	couple other spots that didn't mention the command name at all.  This
	patch fixes all of these.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-09-01  Jan Beulich  <jbeulich@suse.com>

	x86: unindent most of set_cpu_arch()
	Inverting the initial if()'s condition allows to move out the bulk of
	the function by a level, improving readability at least a bit. While
	doing that also pull the push/pop handling up first, such that "else if"
	after "return" isn't needed anymore; the order in which special cases
	are checked doesn't really matter.

	x86: rename CpuPCLMUL
	The name we use internally isn't in line with the SDM, and also isn't in
	line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave
	alone user facing names.

	x86: correct source used for two non-AVX512 VEXWIG tests
	These shouldn't wrongly include the AVX512VL sources. Obviously the
	expectations therefore also need to change.

	x86: drop Size64 from VMOVQ
	Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was
	right in adding the attribute to MOVQ, but there was no need to add it
	to VMOVQ. (See also the AVX512F form, which doesn't have the attribute
	either.)

2023-09-01  Jan Beulich  <jbeulich@suse.com>

	RISC-V: move various alias entries
	For disassembly to only use spec-mandated aliases, respective non-alias
	entries need to come ahead of their alias ones. Since identical
	mnemonics need to stay together, whole groups are moved up where
	necessary.

	This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for
	consistent alias handling"), but then also goes beyond a plain revert.

	Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-09-01  Jerry Zhang Jian  <jerry.zhangjian@sifive.com>

	Fix ld Makefile variable naming: ELF_CLFAGS -> ELF_CFLAGS

2023-09-01  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Fixed the wrong expansion for pseudo vmsge[u].vx instructions.
	The original report was from Kiva Oyama <libkernelpanic@gmail.com>,
	https://sourceware.org/pipermail/binutils/2023-August/129255.html

	The vmsge[u].vx pseudo should be expanded to masked vmslt[u].vx only when
	vd != v0.  Otherwise, it should be expanded to unmasked one.

	gas/
		* config/tc-riscv.c (vector_macro): Fixed the wrong expansion for
		pseudo vmsge[u].vx instructions.
		* testsuite/gas/riscv/vector-insns-vmsgtvx.d: Updated.

2023-09-01  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove uses of alloca in gdbtypes.c
	Replace two uses of alloca with std::string.

	Change-Id: I970ae3f450da407494d95668a57bba8796d6292b
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-09-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-09-01  Nicolas Boulenguez  <nicolas@debian.org>

	PR30806, CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfo
		PR 30806
	bfd/
		* doc/local.mk (doc/chew.stamp): Add CPPFLAGS_FOR_BUILD.
		* Makefile.in: Regenerate.
	binutils/
		* Makefile.am (syslex_wrap.@OBJEXT@): Add CPPFLAGS_FOR_BUILD.
		(sysinfo.@OBJEXT@): Likewise.
		* Makefile.in: Regenerate.

2023-09-01  H.J. Lu  <hjl.tools@gmail.com>

	elf: Adjust PR ld/30791 tests
	Adjust PR ld/30791 tests:

	1. Generic linker targets don't comply with all orhpan section merging
	rules.
	2. z80 fails since a, b, c, d are registers for z80.
	3. hppa fails since .text sections aren't merged for relocatable link.

		PR ld/30791
		* testsuite/ld-elf/pr30791a.d: Xfail for generic and z80
		targets.
		* testsuite/ld-elf/pr30791b.d: Xfail for hppa and z80 targets.

2023-08-31  Tom Tromey  <tom@tromey.com>

	Add symbol::matches method
	This adds symbol::matches, a wrapper for symbol_matches_domain.  Most
	places calling symbol_matches_domain can call this method instead,
	which is a bit less wordy and also (IMO) clearer.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove TYPE_FIELD_PACKED
	Replace with a new equivalent "is_packed" method on struct field.

	Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove TYPE_FIELD_BITSIZE
	Replace with type::field + field::bitsize.

	Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove FIELD_BITSIZE
	Replace with field::bitsize.

	Change-Id: I400be235d6a1f446d0a4aafac01df5e850185d3a
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: introduce field::bitsize / field::set_bitsize
	Add these two methods, rename the field to m_bitsize to make it pseudo
	private.

	Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove TYPE_FIELD_ARTIFICIAL
	Replace with type::field + field::is_artificial.

	Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove FIELD_ARTIFICIAL
	Replace uses with field::is_artificial.

	Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: introduce field::is_artificial / field::set_is_artificial
	Add these two methods, rename the field to m_artificial to make it
	pseudo private.

	Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Tom Tromey  <tromey@adacore.com>

	Remove eval_op_ternop
	eval_op_ternop is only used by the implementation of
	ternop_slice_operation.  While working on another series, it was
	convenient for me to merge this function into its only caller.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-08-31  Kevin Buettner  <kevinb@redhat.com>

	[symtab/27831] New test case: gdb.base/add-symbol-file-attach.exp
	This commit adds a new test case for bug 27831.  See the contents
	of the .exp file for a description of what it's about.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Kevin Buettner  <kevinb@redhat.com>

	[symtab/27831] Fix OBJF_MAINLINE assert
	This commit fixes a bug mentioned by Florian Weimer during the
	libpthread/ld.so load order discussion from 2021.  Florian provided
	instructions for reproducing the bug here:

	https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html

	That particular test does some interesting things involving forks,
	threads, and thread local storage.  Fortunately, none of that is
	needed to reproduce the problem.

	I've made a new test case (which is now found in a separate commit)
	contained in the files gdb.base/add-symbol-file-attach.{c,exp}.  The
	.c file is fairly simple as is the recipe for reproducing the problem.

	After separately starting the test case and noting the process id,
	start gdb (w/ no arguments), and do the following to reproduce the
	assertion failure - for this run, the process id of the separately
	started add-symbol-file-attach process is 4103218:

	(gdb) add-symbol-file add-symbol-file-attach
	add symbol table from file "add-symbol-file-attach"
	(y or n) y
	Reading symbols from add-symbol-file-attach...
	(gdb) attach 4103218
	Attaching to process 4103218
	Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
	Reading symbols from /tmp/add-symbol-file-attach...
	Reading symbols from /lib64/libc.so.6...
	(No debugging symbols found in /lib64/libc.so.6)
	Reading symbols from /lib64/ld-linux-x86-64.so.2...
	(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	0x00007f502130bf27 in pause () from /lib64/libc.so.6
	(gdb) p foo
	symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
	  const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
	  failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.

	The add-symbol-file command causes the symbols to be loaded without
	the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
	set.  This, in turn, causes the "maybe_copied" flag to be set for
	the global symbol (named "foo" in the provided test case).

	The attach command will cause another objfile to be created, but
	it will reuse the symtabs from the objfile created by add-symbol-file,
	leading to a situation in which the OBJFILE_MAINLINE flag will be set
	for the new (attach-created) objfile, however the "maybe_copied"
	flag will still be set for the global symbol.  Had it been loaded
	anew, this flag would not be set due to OBJFILE_MAINLINE being set
	for the objfile.

	At present, minimal_symbol::value_address looks like this:

	CORE_ADDR
	minimal_symbol::value_address (objfile *objfile) const
	{
	  if (this->maybe_copied (objfile))
	    return get_msymbol_address (objfile, this);
	  else
	    return (CORE_ADDR (this->unrelocated_address ())
		    + objfile->section_offsets[this->section_index ()]);
	}

	So, we can now see the problem: When the "maybe_copied" flag is set,
	get_msymbol_address() will be called.  However, get_msymbol_address()
	assumes that it won't be called with the OBF_MAINLINE flag set for
	the objfile in question.  It, in fact, contains an assert() which
	makes sure that this is the case:

	  gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);

	(If this assert is removed, then get_msymbol_address() recurses
	infinitely for the case under consideration.)

	So, the problem here is that the maybe_copied flag is set for the
	symbol AND the OBJF_MAINLINE flag is set for the objfile.  As noted
	earlier, this happens due to add-symbol-file being used; this causes
	the maybe_copied flag to be set.  Later, when the attach is performed,
	OBJF_MAINLINE will be set for that objfile, leading to this
	unfortunate situation.

	My first cut at a solution involved adjusting the
	MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
	method noted above) to include a test of the OBJFILE_MAINLINE flag.
	However, Simon Marchi, in his review of my patch, suggested a better
	solution.  Simon observed that the 'maybe_copied' flag is (was, after
	this commit) being set/initialized in record_minimal_symbol() using
	using the objfile in the context in which the symbol was created.

	Simon further observed:

	  Today, a single copy is created, as symtabs are shared between
	  objfiles.  This means that everything that we store into a symbol
	  must be independent of any objfile.  However, the value of the
	  maybe_copied field is dependent on the objfile in the context of
	  which the symbol was created.  Meaning that when the symbol is
	  re-used in the context of another objfile, the maybe_copied value is
	  not right in the context of that objfile.

	  So I think it means there isn't a single "is this symbol maybe
	  copied" value, but instead "is this symbol maybe copied, in the
	  context of this given objfile".  And the answer is yes or no,
	  depending on whether the objfile is mainline.  So maybe_copied
	  should become a method that takes an objfile and returns an answer
	  based on that.

	Simon's full review can be found here:

	  https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html

	Simon also provided a patch which implements this suggestion.  The
	current patch is mostly his work, though I did make some adjustments
	during a rebase in addition to making some changes to account for a
	concern from Tom Tromey.

	During his review of the v3 series, Tom noted, "The old approach was
	specific to ELF, while the new approach will be used by any object
	format." Tom further observed, "...it seems like it could result in an
	incorrect evaluation in some scenario."  This seemed plausible to me,
	so I introduced the flag 'object_format_has_copy_relocs' to struct
	objfile.  It is set at the end of elf_symfile_read() in elfread.c.
	The minimal_symbol::maybe_copied method tests this new flag, forcing
	this method to return false when the flag is not set.  If we find that
	other object file formats use the same copy reloc mechanism as ELF,
	then 'object_format_has_copy_relocs' should be set for objfiles using
	those formats.

	Lastly, I'll note that this is a strange use case.  It's far more
	common to either let gdb figure out which file to load by itself when
	attaching, i.e.

	(gdb) attach 4104360
	Attaching to process 4104360
	Reading symbols from /tmp/add-symbol-file-attach...
	Reading symbols from /lib64/libc.so.6...
	(No debugging symbols found in /lib64/libc.so.6)
	Reading symbols from /lib64/ld-linux-x86-64.so.2...
	(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
	(gdb) p foo
	$1 = 42

	...or to use the "file" command prior to the attach, like this:

	(gdb) file add-symbol-file-attach
	Reading symbols from add-symbol-file-attach...
	(gdb) attach 4104360
	Attaching to program: /tmp/add-symbol-file-attach, process 4104360
	Reading symbols from /lib64/libc.so.6...
	(No debugging symbols found in /lib64/libc.so.6)
	Reading symbols from /lib64/ld-linux-x86-64.so.2...
	(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6

	Both of these more common scenarios work perfectly fine; using
	"add-symbol-file" to load the program to which you will attach
	isn't recommended as a normal use case.  That said, it's bad for
	gdb to assert, hence this fix.

	Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
	Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
	Approved-by: Tom Tromey <tom@tromey.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831

2023-08-31  Tom Tromey  <tom@tromey.com>

	Unify DW_TAG_typedef case in new_symbol
	This patch merges the DW_TAG_typedef case in new_symbol with some
	other type-related cases.  These all have identical code.

	Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

2023-08-31  Tom Tromey  <tom@tromey.com>

	Revert "Simplify @node use in BFD documentation"
	This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8.

	My earlier patch to simplifify the @node uses in the BFD manual didn't
	take into account (1) that BFD doesn't use the ordinary texinfo
	sectioning commands, and (2) that some users are stuck on very ancient
	versions of makeinfo.

	This patch reverts the change.

	I went through the entire manual using the spacebar, trying to find
	the original problem I reported in the change, but couldn't.  I don't
	know why.  Anyway, all this means is that, with this reversion,
	editing the node structure will be slightly less convenient.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30703

	2023-08-30  Tom Tromey  <tom@tromey.com>

		PR binutils/30703
		* doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding
		parameters back to @node.

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/contrib] Require minimal dwz version in cc-with-tweaks.sh
	I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build
	from current trunk, but the pathname to the build dir changed and I forgot to
	update my test scripts, so the test scripts reverted to using system dwz,
	version 0.12.

	Consequently, I ran into:
	...
	(gdb) p ZERO^M
	No symbol "ZERO" in current context.^M
	(gdb) FAIL: gdb.base/enumval.exp: p ZERO
	...
	which is due to PR dwz/24468, which was fixed in version 0.13.

	Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such
	that this situation is detected and we get instead:
	...
	gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \
	  0.13 or higher required
	...

	Tested on x86_64-linux, verified with shellcheck.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Alan Modra  <amodra@gmail.com>

	vms-alpha: Free memory on failure path
		* vms-alpha.c (evax_bfd_print_eobj): Free rec on failure.

2023-08-31  Alan Modra  <amodra@gmail.com>

	gas init_stab_section and get_stab_string_offset
	get_stab_string_offset currently creates the stabstr section if not
	already present, in the process keeping a reference to the malloc'd
	section name string.  Really, the name belongs in bfd_alloc'd memory
	or some obstack so that it doesn't show as a memory leak on exit.
	s_stab_generic at least does allocate the name for the stab section on
	an obstack, but doesn't tidy that as well as it could.  Return paths
	after issuing a warning don't release the memory, nor the memory for
	the "string" copy.

	This patch fixes these problems.  s_stab_generic is rearranged so that
	creation of the sections occurs earlier, before any potential uses of
	the note obstack during expression parsing.  That makes it possible to
	always free the section name strings unless used to create new
	sections.  I've also avoided get_absolute_expression_and_terminator
	as I see that function might skip over end-of-line, and lack of a
	--input_line_pointer might have caused the following source line to be
	ignored.  (Other uses of this function in gas are OK.)

		* config/obj-coff.c (obj_coff_init_stab_section): Add stabstr
		param.  Pass to get_stab_string_offset rather than name of
		section.
		* config/obj-som.c (obj_som_init_stab_section): Likewise.
		* config/obj-elf.c (obj_elf_init_stab_section): Likewise.
		(elf_init_stab_section): Adjust.
		* config/obj-coff.h (INIT_STAB_SECTION): Update.
		(obj_coff_init_stab_section): Update prototype.
		* config/obj-som.h: Similarly.
		* config/obj-elf.h: Similarly.
		* config/obj-multi.h (INIT_STAB_SECTION): Update.
		* obj.h (struct format_ops <init_stab_section>): Update.
		* read.h (get_stab_string_offset): Update prototype.
		* stabs.c (cached_sec): Delete.
		(stabs_begin): Adjust to suit.
		(get_stab_string_offset): Add stabstr param, delete stabstr_name
		and free_stabstr_secname params.  Don't make stabstr section
		here.
		(eat_comma): New function.
		(s_stab_generic): Replace stab_secname_obstack_end param with
		bool freenames.  Move creation of stab and stabstr sections
		earlier, so the names can be freed earlier before possible use
		of notes obstack during expression parsing.  Tidy error paths
		ensuring "string" is freed.  Use get_absolute_expression in
		place of get_absolute_expression_and_terminator.
		(s_stab): Adjust.
		(s_xstab): Use notes_concat to make stabstr section name.

2023-08-31  Alan Modra  <amodra@gmail.com>

	gas OBJ_PROCESS_STAB
	This macro and the supporting functions have an unused "seg" first
	argument.  Tidy that.

		* config/obj-aout.c (obj_aout_process_stab): Delete first param.
		* config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise.
		* config/obj-elf.c (elf_process_stab): Likewise.
		* config/obj-elf.h (OBJ_PROCESS_STAB): Likewise.
		* config/obj-macho.h (OBJ_PROCESS_STAB): Likewise.
		* config/obj-multi.h (OBJ_PROCESS_STAB): Likewise.
		* ecoff.c (ecoff_stab): Likewise.
		* ecoff.h (ecoff_stab): Likewise.
		* obj.h (struct format_ops <process_stab>): Likewise.
		* stabs.c (OBJ_PROCESS_STAB): Likewise.

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Replace TYPE_ALLOC with TYPE_ZALLOC where required
	Handle the remaining uses of TYPE_ALLOC, either by:
	- replacing with TYPE_ZALLOC, or
	- adding a comment explaining why zero-initialization is not necessary.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Replace TYPE_ALLOC + B_CLRALL with TYPE_ZALLOC
	I noticed some cases of TYPE_ALLOC followed by B_CLRALL.

	Replace these with TYPE_ZALLOC.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Replace TYPE_ALLOC + memset with TYPE_ZALLOC
	I noticed a case of TYPE_ALLOC followed by memset.

	Replace this with TYPE_ZALLOC.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Do more zero-initialization of type::fields
	Now that we've introduced type::{alloc_fields,copy_fields}, the places where
	no zero-initialization of allocated fields is done are easy to spot:
	...
	$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
	gdb/coffread.c:  type->alloc_fields (nfields, false);
	gdb/coffread.c:  type->alloc_fields (nsyms, false);
	gdb/stabsread.c:	  ftype->alloc_fields (nsemi, false);
	gdb/gdbtypes.c:  resolved_type->alloc_fields (nfields, false);
	gdb/gdbtypes.c:  alloc_fields (nfields, false);
	gdb/gdbtypes.c:  alloc_fields (nfields, false);
	gdb/mdebugread.c:	t->alloc_fields (nfields, false);
	gdb/mdebugread.c:		  ftype->alloc_fields (nparams, false);
	...

	All hits in gdbtypes.c are ok.  There are two hits in the two variants of
	copy_fields, and there's already a comment for the third.

	AFAICT, the other ones are not ok, so fix those by dropping the "false"
	argument.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Factor out type::{alloc_fields,copy_fields}
	After finding this code in buildsym_compunit::finish_block_internal:
	...
	              ftype->set_fields
	                ((struct field *)
	                 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
	...
	and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
	locations that needed fixing.

	I decided to make things easier to spot by factoring out a new function
	alloc_fields:
	...
	 /* Allocate the fields array of this type, with NFIELDS elements.  If INIT,
	     zero-initialize the allocated memory.  */
	  void
	  type::alloc_fields (unsigned int nfields, bool init = true);
	...
	where:
	- a regular use would be "alloc_fields (nfields)", and
	- an exceptional use that needed no initialization would be
	  "alloc_fields (nfields, false)".

	Pretty soon I discovered that most of the latter cases are due to
	initialization by memcpy, so I added two variants of copy_fields as well.

	After this rewrite there are 8 uses of set_fields left:
	...
	gdb/coffread.c:	  type->set_fields (nullptr);
	gdb/coffread.c:	  type->set_fields (nullptr);
	gdb/coffread.c:	  type->set_fields (nullptr);
	gdb/eval.c:  type->set_fields
	gdb/gdbtypes.c:  type->set_fields (args);
	gdb/gdbtypes.c:  t->set_fields (XRESIZEVEC (struct field, t->fields (),
	gdb/dwarf2/read.c:      type->set_fields (new_fields);
	gdb/dwarf2/read.c:	      sub_type->set_fields (sub_type->fields () + 1);
	...

	These fall into the following categories:
	- set to nullptr (coffread.c),
	- type not owned by objfile or gdbarch (eval.c), and
	- modifying an existing fields array, like adding an element at the end or
	  dropping an element at the start (the rest).

	Tested on x86_64-linux.

2023-08-31  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix uninitialized memory in buildsym_compunit::finish_block_internal
	When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs,
	gdb either segfaults or asserts due to reading uninitialized memory, allocated
	here in buildsym_compunit::finish_block_internal:
	...
		      ftype->set_fields
			((struct field *)
			 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
	...

	Fix this by using TYPE_ZALLOC instead.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30810
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810

2023-08-31  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Update elfarcv2 script template
	Update ARC's elfarcv2 script template with:

	- The .ivt section (Interrupt Vector Table) is mapped at the begining
	  of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it
	  was pointing to 0x00.

	- MEMORY_FILE is a new emulation paramter and sets the name for the
	  linker script file which holds the MEMORY commands required by
	  arcv2elfx emulation.

	- Four new linker variables are introduced available when arcv2elf emulation is used:
	  * __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero.
	  * __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M.
	  * __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000.
	  * __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M.

	ld/ChangeLog:

		* scripttempl/elfarcv2.sc: Update script template.

2023-08-31  H.J. Lu  <hjl.tools@gmail.com>

	elf: Don't merge sections with different SHF_LINK_ORDER
	For relocatable link, don't merge 2 SHF_LINK_ORDER sections if output
	sections of their linked to sections are different.

		* ldelf.c (elf_orphan_compatible): Don't merge sections with
		different SHF_LINK_ORDER.
		* testsuite/ld-elf/pr30791a.d: New file.
		* testsuite/ld-elf/pr30791a.s: Likewise.
		* testsuite/ld-elf/pr30791b.d: Likewise.
		* testsuite/ld-elf/pr30791b.s: Likewise.
		* testsuite/ld-elf/pr30791c.s: Likewise.
		* testsuite/ld-elf/pr30791d.s: Likewise.

2023-08-31  H.J. Lu  <hjl.tools@gmail.com>

	elf: Check DT_SYMTAB only on non-IR object
	Check DT_SYMTAB only on non-IR object of archive member to avoid crash
	on LLVM IR object with NULL elf_tdata.

		PR ld/30811
		* elflink.c (elf_link_is_defined_archive_symbol): Check
		DT_SYMTAB only on non-IR object.

2023-08-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-31  Alan Modra  <amodra@gmail.com>

	libbfd.texi zero size
	Pattern rules in doc/local.mk exist that specify how to make
	libbfd.texi from libfd.h or libbfd.c.  Since both files exist and the
	libbfd.h rule is first, libbfd.h is used.  libbfd.h doesn't contain
	the documentation..

		* doc/local.mk (doc/%stamp): Put rule making this from %.c
		before %.h rule.
		* Makefile.in: Regenerate.
		* libbfd.c (Byte swapping routines): Don't omit description.

2023-08-30  Alan Modra  <amodra@gmail.com>

	DEFAULT_BUFFERSIZE
	There isn't any reason to think that a particular buffer size is
	ideal in bfd, so let's just not define it.

		* libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define.
		* libbfd.h: Regenerate.
		* archive.c (AR_WRITE_BUFFERSIZE): Substitute value.
		* vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise.
		* coff-rs6000.c (do_copy): Likewise, and use sizeof.

2023-08-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/nullptr_t.exp with cc-with-dwz-m
	When running test-case gdb.dwarf2/nullptr_t.exp with target board
	cc-with-dwz-m, I run into:
	...
	FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
	...

	The problem is that were looking for "typedef void decltype\\(nullptr\\)"
	using "maint print symbols -source $srcfile", but dwz has moved the typedef to
	a PU, so it's shown by "maint print symbols -source <unknown>" instead.

	Fix this by dropping the "-source $srcfile" bit.

	Tested on x86_64-linux, with make-check-all.sh.

2023-08-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: simplify vector construction in eval_op_rust_array
	Replace the manual fill of the vector with the appropriate std::vector
	constructor that makes N copies of the provided value.

	Change-Id: I579570748c48f53d35024105269d83c716294746
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-30  Maciej W. Rozycki  <macro@orcam.me.uk>

	Revert "Gold: Add targ_extra_little_endian to configure.ac"
	This reverts commit cf8565fb2ea42579c50722cbaeafdf71c3d58c66.  It was
	applied unapproved.

	Revert "Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian"
	This reverts commit 39834263784567c306fbccb8230ddd1badca53fe.  It was
	applied unapproved.

	Revert "Gold/MIPS: Drop mips*le/mips*el* triple pattern"
	This reverts commit adb3ae2eba78b4b84d7b94342f6774b250190a98.  It was
	applied unapproved.

	Revert "Gold/MIPS: Add targ_extra_size=64 for mips32 triples"
	This reverts commit d6cdc0af2b880bb48dd16055f4cb3509c7a2da70.  It was
	applied unapproved.

	Revert "Gold/MIPS: Add mips64*/mips64*el triple support"
	This reverts commit 5c4cdba100b66e2924a25dad9b12d8e5b84d527f.  It was
	applied unapproved.

	Revert "MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets"
	This reverts commit 025e84f93566c8ced594ef48ddee1dec7e5b4cdd.  It was
	applied unapproved.

2023-08-30  Willgerodt, Felix  <felix.willgerodt@intel.com>

	gdbserver, linux-low: add a couple of nullptr assertions.
	This safeguards a couple of places that may theoretically return NULL but
	must not in this specific context.  These were found by a static analysis tool.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-30  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Make XVentanaCondOps RV64 only
	Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual
	only defines them only for RV64 (because all Ventana's processors implement
	RV64).

	This commit limits XVentanaCondOps instructions RV64-only to match the
	behavior of the manual and LLVM.

	Note that this commit alone will not make XVentanaCondOps extension with
	RV32 invalid (it just makes XVentanaCondOps on RV32 empty).

	opcodes/ChangeLog:

		* riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn"
		to XLEN=64.

	gas/ChangeLog:

		* testsuite/gas/riscv/x-ventana-condops-32.d: New failure test.
		* testsuite/gas/riscv/x-ventana-condops-32.l: Likewise.

2023-08-30  Alan Modra  <amodra@gmail.com>

	objdump: Free sorted_syms on error path
		* objdump.c (disassemble_data): Free sorted_syms before returning.

	binutils/dwarf.c abbrev list leak
		* dwarf.c (process_debug_info): Call free_abrev_list on
		return paths.

	Re: readelf/objdump: Handle DWARF info with mixed types of range section
		PR 30791
		* dwarf.c (free_debug_information): Free range_versions.

2023-08-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix C inclusion of nat/x86-cpuid.h
	When running test-case gdb.arch/i386-avx512.exp, I run into:
	...
	 gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0:
	 src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count':
	 src/gdb/nat/x86-cpuid.h:63:16: error: \
	   'nullptr' undeclared (first use in this function)
	    if (__eax == nullptr)
	                 ^~~~~~~
	 src/gdb/nat/x86-cpuid.h:63:16: note: each \
	   undeclared identifier is reported only once for each function it appears in

	                  === gdb Summary ===

	 # of untested testcases         1
	...

	This is due to commit e85aad4ae76 ("nat/x86-cpuid.h: Add x86_cpuid_count
	wrapper around __get_cpuid_count"), which introduced the nullptr check.

	The header file gdb/nat/x86-cpuid.h is a file that is included in the build
	and compiled as a C++ file, but also in the testsuite and compiled as a C
	file.

	Fix this by replacing nullptr with (void *)0.

	Tested on x86_64-linux.

	Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	More renames in array_operation::evaluate
	array_operation::evaluate has variables named "tem2" and "tem3".  This
	patch replaces one with a better name, and entirely removes the other.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Remove "highbound" parameter from value_array
	value_array requires the passed-in bounds to match the length of the
	array_view it is given.  This patch removes the redundant "highbound"
	parameter.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Remove another redundant variable from array_operation::evaluate
	This removes yet another redundant variable from
	array_operation::evaluate -- only one index is needed.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Remove redundant variable from array_operation::evaluate
	In array_operation::evaluate, 'idx' and 'tem' are redundant in one
	branch.  This patch merges them, using the clearer name.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Hoist array bounds check in array_operation::evaluate
	This hoists the array bounds check in array_operation::evaluate to
	before the loop.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Declare 'tem' in loop header in array_operation::evaluate
	This changes array_operation::evaluate to declare the 'tem' variable
	in the loop header, rather than at the top of the function.  This is
	cleaner and easier to reason about.  I also changed 'nargs' to be
	'const'.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Use gdb::array_view for value_array
	This changes value_array to accept an array view.  I also replaced an
	alloca with a std::vector in array_operation::evaluate.  This function
	can work on any size of array, so it seems bad to use alloca.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: recognize one more unsupported instruction in gdb.reverse/step-precsave.exp
	When running this test on a processor that supports AVX512 (AMD EPYC
	9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:

	    continue^M
	    Continuing.^M
	    Process record does not support instruction bound.^M
	    Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
	    Process record: failed to record execution log.^M
	    ^M
	    Program stopped.^M
	    0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
	    (gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main

	The instruction at this address is:

	   0x00007ffff7f49b40:	62 e2 7d 48 7a c6   vpbroadcastb %esi,%zmm16

	This seems like an AVX512 instruction (given the use of zmm16).  Match
	this byte value in order to produce a KFAIL.

	Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require have_compile_flag -mavx512f in gdb.arch/i386-avx512.exp
	When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
	...
	Running gdb.arch/i386-avx512.exp ...
	gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
	...

	Fix this by requiring have_compile_flag -mavx512f.

	Tested on x86_64-linux.

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require gcc >= 5 in gdb.linespec/cpls-abi-tag.exp
	When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
	into:
	...
	cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
	 ABI3 test_abi_tag_struct s;
	                          ^
	...

	The test-case is supported starting gcc 5.

	Fix this by requiring gcc >= 5, if a gcc compiler is used.

	Tested on x86_64-linux.

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle some test-cases with older compiler
	When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
	into a compilation failure due to the test-case requiring c++11 and the
	compiler defaulting to less than that.

	Fix this by compiling with -std=c++11.

	Likewise in a few other test-cases.

	Tested on x86_64-linux.

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix false negative in have_host_locale
	In test-case gdb.tui/pr30056.exp we check for:
	...
	require {have_host_locale C.UTF-8}
	...

	The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
	find it in the list returned by host_locales.

	On my development platform, "locale -a" lists C.utf8, which is normalized to
	"c.utf8" by host_locales, so there's a match and have_host_locale returns true.

	On another platform however, "locale -a" lists C.UTF-8, which is normalized to
	"c.utf-8" by host_locales, so there's no match and have_host_locale returns false.

	Fix this by also dropping the dash in host_locales.

	Tested on x86_64-linux.

2023-08-29  Nicolas Boulenguez  <nicolas.boulenguez@free.fr>

	readelf: typos in user messages

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Default getpkt 'forever' parameter to 'false'
	This patch changes remote.c so that the getpkt 'forever' parameter now
	defaults to 'false' and fixes up all the callers.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Unify getpkt and getpkt_or_notif_sane
	getpkt and getpkt_or_notif_sane are just wrappers for
	getpkt_or_notif_sane_1.  This patch adds the is_notif parameter to
	getpkt, with a suitable default, and removes the wrappers.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Use bool in getpkt
	This changes getpkt and related functions to use bool rather than int.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Remove expecting_notif parameter from getpkt_or_notif_sane_1
	For getpkt_or_notif_sane_1, expecting_notif is redundant, because it
	always reflects whether the is_notif parameter is non-NULL.  This
	patch removes the redundant parameter.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-29  Tom Tromey  <tromey@adacore.com>

	Remove getpkt_sane
	I noticed that getpkt is just a wrapper around getpk_sane, so this
	patch unifies the two of them.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Check for sys/random.h in gdb.reverse/getrandom.exp
	When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
	we run into:
	...
	 gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
	   sys/random.h: No such file or directory
	  #include <sys/random.h>
	                         ^
	 compilation terminated.

	                 === gdb Summary ===

	 # of untested testcases        1
	...
	and:
	...
	UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
	...

	Fix this by testing for the presence of the header, such that we have instead:
	...
	UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
	  have_system_header sys/random.h
	...

	Tested on x86_64-linux and i686-linux.

2023-08-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve xfail in gdb.cp/nsusing.exp
	In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
	mentioned:
	...
	XFAIL: gdb.cp/nsusing.exp: print x, before using statement
	XFAIL: gdb.cp/nsusing.exp: print x, only using M
	...

	Add the missing PRMS, such that we have:
	...
	XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
	XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
	...
	and limit the xfail to unfixed versions.

	The PR is fixed starting gcc 13, but it has been backported to release
	branches stretching back to gcc 10.  For simplicity we just stick to testing
	for the major version and ignore the backported fixes.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Fix style of struct declarations in i387-fp.cc

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Simplify handling of ZMM registers.
	- Reuse num_xmm_registers directly for the count of ZMM0-15 registers
	  as is already done for the YMM registers for AVX rather than using
	  a new variable that is always the same.

	- Replace 3 identical variables for the count of upper ZMM16-31
	  registers with a single variable.  Make use of this to merge
	  various loops working on the ZMM XSAVE region so that all of the
	  handling for the various sub-registers in this region are always
	  handled in a single loop.

	- While here, fix some bugs in i387_cache_to_xsave where if
	  X86_XSTATE_ZMM was set on i386 (e.g. a 32-bit process on a 64-bit
	  kernel), the -1 register nums would wrap around and store the value
	  of GPRs in the XSAVE area.  This should be harmless, but is
	  definitely odd.  Instead, check num_zmm_high_registers directly when
	  checking X86_XSTATE_ZMM and skip the ZMM region handling entirely if
	  the register count is 0.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	x86: Remove X86_XSTATE_SIZE and related constants.
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  Aleksandar Paunovic  <aleksandar.paunovic@intel.com>
	    John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Use x86_xstate_layout to parse the XSAVE extended state area.
	Replace the extended state area fields of i387_xsave with methods which
	return an offset into the XSAVE buffer.

	The two changed functions are called within all tests which runs
	gdbserver.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  Aleksandar Paunovic  <aleksandar.paunovic@intel.com>
	    John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Refactor the legacy region within the xsave struct
	Legacy fields of the XSAVE area are already defined within fx_save
	struct.  Use class inheritance to remove code duplication.

	The two changed functions are called within all tests which run
	gdbserver.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Add a function to set the XSAVE mask and size.
	Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
	the value instead.  Add a static global instance of x86_xsave_layout
	and initialize it in the new function as well to be used in a future
	commit to parse XSAVE extended state regions.

	Update the Linux port to use this function rather than setting
	x86_xcr0 directly.  In the case that XML is not supported, don't
	bother setting x86_xcr0 to the default value but just omit the call to
	i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
	non-XML.

	In addition, use x86_xsave_length to determine the size of the XSAVE
	register set via CPUID.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Use x86_xstate_layout to parse the XSAVE extended state area.
	All of the tables describing the offsets of individual registers for
	XSAVE state components now hold relative offsets rather than absolute
	offsets.  Some tables (those for MPX registers and ZMMH registers) had
	to be split into separate tables as they held entries that spanned
	multiple state components.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Support XSAVE layouts for the current host in the Linux x86 targets.
	Note that this uses the CPUID instruction to determine the total size
	of the XSAVE register set.  If there is a way to fetch the register set
	size using ptrace that would probably be better.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Update x86 Linux architectures to support XSAVE layouts.
	Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding
	x86_xsave_layout as well as xcr0 using the size of an existing
	NT_X86_XSTATE core dump to determine the offsets via
	i387_guess_xsave_layout.  Use this to add an implementation of
	gdbarch_core_xfer_x86_xsave_layout.

	Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
	set.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets.
	Use the CPUID instruction to fetch the offsets of supported state
	components.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Update x86 FreeBSD architectures to support XSAVE layouts.
	Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding
	x86_xsave_layout as well as xcr0 using the size of an existing
	NT_X86_XSTATE core dump to determine the offsets via
	i387_guess_xsave_layout.  Use this to add an implementation of
	gdbarch_core_xfer_x86_xsave_layout.

	Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
	set and only fetch/store the register set if this size is non-zero.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	x86 nat: Add helper functions to save the XSAVE layout for the host.
	x86_xsave_length returns the total length of the XSAVE state area
	standard format as queried from CPUID.

	x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE
	extended regions from the running host.  The total length of the XSAVE
	state area can either be supplied by the caller if known (e.g. from
	FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host
	using x86_xsave_length.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count.
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	core: Support fetching x86 XSAVE layout from architectures.
	Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
	structure from a core file.

	Current OS's do not export the offsets of XSAVE state components in
	core dumps, so provide an i387_guess_xsave_layout helper function to
	set offsets based on known combinations of XCR0 masks and total state
	sizes.  Eventually when core dumps do contain this information this
	function should only be used as a fall back for older core dumps.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>

	gdb: Store an x86_xsave_layout in i386_gdbarch_tdep.
	This structure is fetched from the current target in i386_gdbarch_init
	via a new "fetch_x86_xsave_layout" target method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  John Baldwin  <jhb@FreeBSD.org>
	    Aleksandar Paunovic  <aleksandar.paunovic@intel.com>

	x86: Add an x86_xsave_layout structure to handle variable XSAVE layouts.
	The standard layout of the XSAVE extended state area consists of three
	regions.  The first 512 bytes (legacy region) match the layout of the
	FXSAVE instruction including floating point registers, MMX registers,
	and SSE registers.  The next 64 bytes (XSAVE header) contains a header
	with a fixed layout.  The final region (extended region) contains zero
	or more optional state components.  Examples of these include the
	upper 128 bits of YMM registers for AVX.

	These optional state components generally have an
	architecturally-fixed size, but they are not assigned architectural
	offsets in the extended region.  Instead, processors provide
	additional CPUID leafs describing the size and offset of each
	component in the "standard" layout for a given CPU.  (There is also a
	"compact" format which uses an alternate layout, but existing OS's
	currently export the "standard" layout when exporting XSAVE data via
	ptrace() and core dumps.)

	To date, GDB has assumed the layout used on current Intel processors
	for state components in the extended region and hardcoded those
	offsets in the tables in i387-tdep.c and i387-fp.cc.  However, this
	fails on recent AMD processors which use a different layout.
	Specifically, AMD Zen3 and later processors do not leave space for the
	MPX register set in between the AVX and AVX512 register sets.

	To rectify this, add an x86_xsave_layout structure which contains the
	total size of the XSAVE extended state area as well as the offset of
	each known optional state component.

	Subsequent commits will modify XSAVE parsing in both gdb and gdbserver
	to use x86_xsave_layout.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-08-28  Tom Tromey  <tromey@adacore.com>

	Use sect_offset_str in cooked_index::dump
	Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
	Andreas Schwab pointed out that gdb already has sect_offset_str.  This
	patch applies both these observations.

2023-08-28  Mark Wielaard  <mark@klomp.org>

	Use hex_string in gdb/coffread.c instead of PRIxPTR
	The getsymname function uses PRIxPTR to print and uintptr_t value in
	an error message. Use hex_string instead.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-28  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle self-reference in inherit_abstract_dies
	Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
	self-referencing DIE:
	...
	 <2><91dace>: Abbrev Number: 405 (DW_TAG_label)
	    <91dad0>   DW_AT_abstract_origin: <0x91dace>
	...

	When encountering the self-reference DIE in inherit_abstract_dies we loop
	following the abstract origin, effectively hanging gdb.

	Fix this by handling self-referencing DIEs in the loop in
	inherit_abstract_dies.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30799
	https://sourceware.org/bugzilla/show_bug.cgi?id=30799

2023-08-28  Alan Modra  <amodra@gmail.com>

	COFF swap_aux_in
	A low level function like coff_swap_aux_in really has no business
	concatenating multiple auxents for the old PE multi-aux scheme of
	handling long file names.  In doing so, it assumes multiple internal
	auxent buffers are available, which they are not in most calls to
	bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB.  Buffer
	overflow fun.  Concatenating multiple auxents belongs at a higher
	level.

	This required some changes to coff_get_normalized_symtab, which now
	uses the external auxents to access the concatenated file name.
	(Internal auxents are larger than the x_fname array, so the pieces of
	the file name are not adjacent as they are in the external auxents.)

		* coffswap.h (coff_swap_aux_in): Do not write more than one
		internal auxent.
		* coffcode.h (coff_bigobj_swap_aux_in): Likewise.
		* coffgen.c (coff_get_normalized_symtab): Normalize strings
		after swapping in each symbol so that external auxents are
		available.  Use external auxents for multi-aux long file
		names.  Formatting.  Wrap long lines.  Remove excess parens
		and unnecessary casts.  Don't zalloc when only the string
		terminator needs zeroing, and memcpy rather than strncpy.
		Delete unnecessary sanity check with unsigned _n_offset.
		Return with failure if debug section can't be read, to avoid
		trying to read it multiple times.  Correct sanity check
		against debug section size.

2023-08-28  Alan Modra  <amodra@gmail.com>

	Re: comdat_hash memory leaks
	I missed another field that needs freeing.  Also, oss-fuzz found a
	case with a C_FILE sym using multiple auxents for a long file name
	which overflowed the single auxent buffer.  I'm going to fix that
	problem in swap_aux_in too, but we may as well avoid it here too,
	saving unnecessary work.

		* coffcode.h (comdat_delf): Free comdat_name.
		(fill_comdat_hash): Only look at symbols with one auxent.

2023-08-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add xfail in gdb.cp/subtypes.exp
	When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into:
	...
	FAIL: gdb.cp/subtypes.exp: ptype main::Foo
	FAIL: gdb.cp/subtypes.exp: ptype main::Bar
	FAIL: gdb.cp/subtypes.exp: ptype main::Baz
	FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo
	FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar
	FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz
	FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo
	FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar
	FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz
	...

	The problem is gcc PR debug/55541, which generates a superfluous
	DW_TAG_lexical_block.

	Add a corresponding xfail.

	Tested on x86_64-linux.

2023-08-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Refactor gdb.cp/subtypes.exp
	Make test-case gdb.cp/subtypes.exp less repetitive by using foreach.

	Tested on x86_64-linux.

2023-08-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle gdb.cp/*.exp with older compiler
	When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
	failures due to the test-cases requiring c++11 and the compiler defaulting
	to less than that.

	Fix this by compiling with -std=c++11.

	This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
	gcc PR debug/16063, so xfail those.

	Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
	prevent compilation failure.

	Tested on x86_64-linux.

2023-08-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets
	Following the arrangement in GCC select a 64-bit ABI by default, either
	n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as
	with the corresponding `mips64*-*-linux*' targets.

	Gold/MIPS: Add mips64*/mips64*el triple support
	Use targ_size=64 and targ_extra_size=32

	Gold/MIPS: Add targ_extra_size=64 for mips32 triples
	So we can enable 64bit ELF support for MIPS32 toolchain.

	Gold/MIPS: Drop mips*le/mips*el* triple pattern
	Only mips*el triples are supported by binutils.  The mips*le
	or mips*el* may cause some problem with other components of
	binutils, since they will consider them as big endian.

2023-08-28  YunQiang Su  <yunqiang.su@cipunited.com>

	Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian
	EM_MIPS_RS3_LE has been deprecated quite long ago, and in fact
	most of current LE ELF files are using EM_MIPS.

	This problem didn't make some trouble for us, is due to that
	gold is a linker, and all of the inputs to it has right EM values.

2023-08-28  YunQiang Su  <yunqiang.su@cipunited.com>

	Gold: Add targ_extra_little_endian to configure.ac
	This option will be used by architectures which is big endian
	by default, while little-endian support is also needed.

	Mips(eb) ports are the examples.

2023-08-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-27  Alan Modra  <amodra@gmail.com>

	PE dos_message
	I was looking at dos_message and wondering why we have H_PUT_32
	in _bfd_XXi_only_swap_filehdr_out but no H_GET_32 in pe_bfd_object_p.
	On a big-endian machine this would result in scrambling the code and
	strings constained in dos_message.  Rather than fix the lack of
	H_GET_32 in pe_bfd_object_p, I decided it doesn't make sense to store
	dos_message internally as an array of ints.

	include/
		* coff/internal.h (struct internal_extra_pe_filehdr): Make
		dos_message a char array.
		* coff/msdos.h (struct external_DOS_hdr): Flatten dos_message.
		* coff/pe.h (struct external_PEI_filehdr): Likewise.
	bfd/
		* libcoff-in.h (struct pe_tdata): Make dos_message a char array.
		* libcoff.h: Regenerate.
		* peXXigen.c (_bfd_XXi_only_swap_filehdr_out): memcpy dos_message
		to output.
		* peicode.h (pe_mkobject): Don't memset already zeroed pe_opthdr.
		Tidy allocation of tdata.pe_obj_data.  Set up dos_message from..
		(default_dos_message): ..this.  New static array.

2023-08-27  Alan Modra  <amodra@gmail.com>

	comdat_hash memory leaks
	Entries added to the hash table with bfd_malloc ought to be freed when
	the hash table is deleted.  This patch adds the necessary del_f to the
	htab_create call, and delays creating the table until an
	IMAGE_SCN_LNK_COMDAT symbol is read.

		* peicode.h (pe_mkobject): Move comdat_hash creation..
		(htab_hash_flags, htab_eq_flags): ..and these support functions..
		* coffcode.h (handle_COMDAT): ..to here, renaming support to
		(comdat_hashf, comdat_eqf): ..this and adding..
		(comdat_delf): ..this new function.

2023-08-27  Alan Modra  <amodra@gmail.com>

	Confusion in coff_object_cleanup
	A bfd_cleanup function needs to run when only tdata is correct for the
	bfd.  The xvec may have changed during bfd_check_format and thus the
	flavour may be incorrect.  The format won't have changed but checking
	is superfluous.  (In contrast to _bfd_free_cached_info or
	_close_and_cleanup where we do need to check things.)

	Not getting this correct leaked comdat_hash.

	Also, pe_ILF_cleanup ought to call coff_object_cleanup as do all PE
	files.

		* coffgen.c (coff_object_cleanup): Don't check bfd flavour or
		format.
		* peicode.h (pe_ILF_cleanup): Call coff_object_cleanup.

2023-08-27  Alan Modra  <amodra@gmail.com>

	sanity check n_numaux
	Sanity check aux entries used by PE to extend a C_FILE name.  See
	coffswap.h:coff_swap_aux_in.  The existing check only catered for
	n_numaux == 1.

		* coffcode.h (fill_comdat_hash): Properly sanity check n_numaux.
		Formatting.
		(handle_COMDAT): Formatting.

2023-08-27  Alan Modra  <amodra@gmail.com>

	Re: ld STRINGIFY
	Oops there was a reference to the old name.

		* emultempl/aix.em: Use stringify.sed.

2023-08-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-26  Tom Tromey  <tom@tromey.com>

	Simplify definition of GUILE
	This patch sets GUILE to just plain 'guile'.

	In the distant ("devo") past, the top-level build did support building
	Guile in-tree.  However, I don't think this really works any more.
	For one thing, there are no build dependencies on it, so there's no
	guarantee it would actually be built before the uses.

	This patch also removes the use of "-s" as an option to cgen scheme
	scripts.  With my latest patch upstream, this is no longer needed.

	After the upstream changes, either Guile 2 or Guile 3 will work, with
	or without the compiler enabled.

	2023-08-24  Tom Tromey  <tom@tromey.com>

		* cgen.sh: Don't pass "-s" to cgen.
		* Makefile.in: Rebuild.
		* Makefile.am (GUILE): Simplify.

2023-08-26  Tom Tromey  <tom@tromey.com>

	Use get_frame_address_in_block in print_frame
	The author of 'mold' pointed out that with a certain shared library,
	gdb would fail to find the shared library's name in 'bt'.

	The function in question appeared at the end of the .so's .text
	segment and ended with a call to 'abort'.

	This turned out to be a classic case of calling get_frame_pc when
	get_frame_address_in_block is needed -- the former will be off-by-one
	for purposes of finding the enclosing function or shared library.

	The included test fails without the patch on my system.  However, I
	imagine it can't be assumed to reliably fail.  Nevertheless it seemed
	worth doing.

	Regression tested on x86-64 Fedora 38.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-08-26  Alan Modra  <amodra@gmail.com>

	opcodes i386 and ia64 gen file warnings
	i386: warning: format ‘%u’ expects argument of type ‘unsigned int’,
	but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
	ia64: warning: ignoring return value of ‘fgets’

		* i386-gen.c (process_i386_opcodes): Correct format string.
		* ia64-gen.c (load_insn_classes, load_depfile): Don't ignore
		fgets return value.

2023-08-26  Alan Modra  <amodra@gmail.com>

	ld STRINGIFY
	Delete support for old compilers that don't support string
	concatentation.

		* Makefile.am (stringify.sed): Delete rule.
		(GEN_DEPENDS, DISTCLEANFILES): Adjust.
		* configure.ac (STRINGIFY): Delete.
		* emultempl/beos.em: Use stringify.sed from srcdir.
		* emultempl/elf.em: Likewise.
		* emultempl/generic.em: Likewise.
		* emultempl/msp430.em: Likewise.
		* emultempl/pdp11.em: Likewise.
		* emultempl/pe.em: Likewise.
		* emultempl/pep.em: Likewise.
		* emultempl/stringify.sed: Renamed from..
		* emultempl/astring.sed: ..this.
		* emultempl/ostring.sed: Delete.
		* Makefile.in: Regenerate.
		* configure: Regenerate.

2023-08-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-26  Alan Modra  <amodra@gmail.com>

	ld .deps/*.Pc files
	This patch gets rid of the individual rules including the .Pc
	dependency files made while generating e*.c files, replacing them with
	a fancy GNU make pattern include.  I've also moved creation of
	ldscripts to the makefile since it is possible to run more than one
	genscripts at once, resulting in "ldscripts: File exists" messages.

		* Makefile.am: Replace individual include of *.Pc dependency
		files with one pattern rule.
		(.Pc): New dummy rule.
		(ldscripts/stamp): New rule.
		(GEN_DEPENDS): Add ldscripts/stamp.
		(install-data-local): Exclude ldscripts/stamp from install.
		* genscripts.sh: Don't make ldscripts dir.
		* Makefile.in: Regenerate.

2023-08-25  Mark Wielaard  <mark@klomp.org>

	Fix gdb/coffread.c build on 32bit architectures
	The getsymname function tries to emit an error using %ld for an
	uintptr_t argument. Use PRIxPTR instead. Which works on any architecture
	for uintptr_t.

2023-08-25  Keith Seitz  <keiths@redhat.com>

	Verify COFF symbol stringtab offset
	This patch addresses an issue with malformed/fuzzed debug information that
	was recently reported in gdb/30639. That bug specifically deals with
	an ASAN issue, but the reproducer provided by the reporter causes a
	another failure outside of ASAN:

	$ ./gdb --data-directory data-directory -nx -q UAF_2
	Reading symbols from /home/keiths/UAF_2...


	Fatal signal: Segmentation fault
	----- Backtrace -----
	0x59a53a gdb_internal_backtrace_1
		../../src/gdb/bt-utils.c:122
	0x59a5dd _Z22gdb_internal_backtracev
		../../src/gdb/bt-utils.c:168
	0x786380 handle_fatal_signal
		../../src/gdb/event-top.c:889
	0x7864ec handle_sigsegv
		../../src/gdb/event-top.c:962
	0x7ff354c5fb6f ???
	0x611f9a process_coff_symbol
		../../src/gdb/coffread.c:1556
	0x611025 coff_symtab_read
		../../src/gdb/coffread.c:1172
	0x60f8ff coff_read_minsyms
		../../src/gdb/coffread.c:549
	0x60fe4b coff_symfile_read
		../../src/gdb/coffread.c:698
	0xbde0f6 read_symbols
		../../src/gdb/symfile.c:772
	0xbde7a3 syms_from_objfile_1
		../../src/gdb/symfile.c:966
	0xbde867 syms_from_objfile
		../../src/gdb/symfile.c:983
	0xbded42 symbol_file_add_with_addrs
		../../src/gdb/symfile.c:1086
	0xbdf083 _Z24symbol_file_add_from_bfdRKN3gdb7ref_ptrI3bfd18gdb_bfd_ref_policyEEPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaISC_EES8_I12objfile_flagEP7objfile
		../../src/gdb/symfile.c:1166
	0xbdf0d2 _Z15symbol_file_addPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaIS5_EES1_I12objfile_flagE
		../../src/gdb/symfile.c:1179
	0xbdf197 symbol_file_add_main_1
		../../src/gdb/symfile.c:1203
	0xbdf13e _Z20symbol_file_add_mainPKc10enum_flagsI16symfile_add_flagE
		../../src/gdb/symfile.c:1194
	0x90f97f symbol_file_add_main_adapter
		../../src/gdb/main.c:549
	0x90f895 catch_command_errors
		../../src/gdb/main.c:518
	0x9109b6 captured_main_1
		../../src/gdb/main.c:1203
	0x910fc8 captured_main
		../../src/gdb/main.c:1310
	0x911067 _Z8gdb_mainP18captured_main_args
		../../src/gdb/main.c:1339
	0x418c71 main
		../../src/gdb/gdb.c:39
	---------------------
	A fatal error internal to GDB has been detected, further
	debugging is not possible.  GDB will now terminate.

	This is a bug, please report it.  For instructions, see:
	<https://www.gnu.org/software/gdb/bugs/>.

	Segmentation fault (core dumped)

	The issue here is that the COFF offset for the fuzzed symbol's
	name is outside the string table. That is, the offset is greater
	than the actual string table size.

	coffread.c:getsymname actually contains a FIXME about this, and that's
	what I've chosen to address to fix this issue, following what is done
	in the DWARF reader:

	$ ./gdb --data-directory data-directory -nx -q UAF_2
	Reading symbols from /home/keiths/UAF_2...
	COFF Error: string table offset (256) outside string table (length 0)
	(gdb)

	Unfortunately, I haven't any idea how else to test this patch since
	COFF is not very common anymore. GCC removed support for it five
	years ago with GCC 8.

2023-08-25  John Baldwin  <jhb@FreeBSD.org>

	Update FreeBSD system calls for the upcoming 14.0-RELEASE
	This matches the current set of system calls at the start of the
	stable/14 branch (commit 29a16ce065dbc28bc9e87c9bfadb08bb58b137e4).

2023-08-25  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix for call feature having 9th function parameter and beyond corrupt values.
	In AIX the first eight function parameters are stored from R3 to R10.
	If there are more than eight parameters in a function then we store the 9th parameter onwards in the stack.
	While doing so, in 64 bit mode the words were not zero extended and was coming like 32 bit mode.
	This patch is a fix to the same.

	Fix 64 bit red zone frame size in AIX

2023-08-25  Jan Beulich  <jbeulich@suse.com>

	bfd: correct relocation handling for objcopy COFF -> ELF
	While documented to not be reliable, it is still odd for objcopy to
	silently produce bad output when converting COFF/PE object files to ELF
	ones. The issue there is that relocation addends all are screwed up by
	subtracting the symbol's section offset. In the COFF/PE world, to my
	knowledge, section contents stores the addends alone, not the result of
	symbol value plus addend. Hence the compensation talked about in a
	comment ahead of the sole use site of CALC_ADDEND() may need to account
	for the VMA (which is always zero for object files anyway), but not for
	the symbol value.

	The coff-sh.c adjustment is based upon guessing that behavior there is
	the same. Note also how coff-aarch64.c short-circuits CALC_ADDEND()
	altogether, which may suggest that a much simpler macro might do for the
	COFF_WITH_PE case in the three arch-specific files touched here.

	For (at least) Arm/WinCE this actually results in more appropriate
	objdump output as well, as can be seen in the one testcase which has its
	expectations adjusted (the generated binary doesn't change).

2023-08-25  Jan Beulich  <jbeulich@suse.com>

	gas/ELF: widen use of $dump_opts in testsuite
	Rather than special-casing rx-*-* for section30, force use of
	conventional section names uniformly. By further passing $dump_opts to
	a few more tests, a number of xfail-s (and one notarget) can be
	eliminated (some of which had wrong justifications in associated
	comments anyway). Note that section7 and section15 need to be left
	alone: The harness fiddling with section names there didn't help before
	and is getting in the way now. For section12b, section16b, and most of
	the Dwarf tests nothing changes. Interestingly by passing $dump_opts
	the need to xfail section11 for LoongArch and RISC-V also goes away.

2023-08-25  Jan Beulich  <jbeulich@suse.com>

	gas/ELF: allow "inheriting" section attributes and type
	While --sectname-subst is nice, it isn't enough to e.g. mimic
	-f{function,data}-sections in assembly code, when such use is to be
	optional (e.g. dependent upon some configuration setting).

	Assign meaning to '+' and '-' as section attribute letters, allowing
	to inherit the prior section's attributes (and possibly type) along
	with adding or removing some. Note that documenting the interaction
	with '?' as undefined is a precautionary measure.

	While touching the function invocation, stop using |= on the result of
	obj_elf_parse_section_letters(): "attr" is firmly zero ahead of the
	call.

2023-08-25  Alan Modra  <amodra@gmail.com>

	Use GNU make pattern rule in ld Makefile
	Use the pattern rule in a comment from commit 77ac17b8453f.

		* Makefile.am (run-genscripts): Delete.  Use pattern rule
		e%.c instead.
		* Makefile.in: Regenerate.

2023-08-25  Alan Modra  <amodra@gmail.com>

	som: buffer overflow writing strings
	Code in som_write_symbol_strings neglected to allow for padding, which
	can result in a buffer overflow.  It also used xrealloc, which we're
	not supposed to use in libbfd because libbfd isn't supposed to call
	exit.  Also a realloc is perhaps not a good idea when none of the
	buffer contents are needed, so replace with free, bfd_malloc.  There
	were three copies of the string handling code, so rather than fix them
	all I've extracted them to a function.  This necessitated making one
	of the fields in struct som_symbol unsigned.

		* som.c (add_string): New function.
		(som_write_space_strings, som_write_symbol_strings): Use it.
		* som.h (som_symbol_type <stringtab_offset>): Make unsigned.

2023-08-25  Alan Modra  <amodra@gmail.com>

	PR30794, PowerPC gold: internal error in add_output_section_to_load
	Caused by commit 5a97377e5513, specifically this code added to
	Target_powerpc::do_relax
	+      if (parameters->options().output_is_position_independent())
	+       this->rela_dyn_size_
	+         = this->rela_dyn_section(layout)->current_data_size();

	The problem here is that if .rela.dyn isn't already created then the
	call to rela_dyn_section creates it, and as this comment in
	Target_powerpc::do_finalize_sections says:
		  // Annoyingly, we need to make these sections now whether or
		  // not we need them.  If we delay until do_relax then we
		  // need to mess with the relaxation machinery checkpointing.
	We can't be creating sections in do_relax.

		PR 30794
		* powerpc.cc (Target_powerpc::do_relax): Only set rela_dyn_size_
		for size == 64, and assert that rela_dyn_ already exists.
		Tidy code setting plt_thread_safe, which also only needs to be
		set when size == 64 for ELFv1.

2023-08-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-24  Lancelot SIX  <lancelot.six@amd.com>

	gdb/solib-rocm: Detect SO for unsupported AMDGPU device
	It is possible to debug a process which uses unsupported AMDGPU devices.
	In such scenario, we can still use librocm-dbgapi.so to attach to the
	process and complete the runtime activation sequence.

	However, when listing shared objects loaded on the AMDGPU devices, we
	might list SOs loaded on the unsupported devices.  If such SO is
	seen, one of two things can happen.

	First, if the arch of this device is unknown to BFD,
	'gdbarch_find_by_info (gdbarch_info info)' will return the gdbarch
	matching default_bfd_arch.  As a result,
	rocm_solib_relocate_section_addresses will delegate the relocation
	operation to svr4_so_ops.relocate_section_addresses, but this makes no
	sense: this code object was not loaded by the system loader.

	The second case is if BFD knows the micro-architecture of the device,
	but dbgapi does not support it.  In such case, gdbarch_info_fill will
	successfully identify an amdgcn architecture (bfd_arch_amdgcn).  From
	there, gdbarch_find_by_info calls amdgpu_gdbarch_init which will fail to
	query arch specific details from dbgapi and subsequently fail to
	initialize the gdbarch object.  As a result, gdbarch_find_by_info
	returns nullptr, which will down the line cause some "gdb_assert
	(gdbarch != nullptr)" assertion failures.

	This patch proposes to add a check in rocm_solib_bfd_open to ensure that
	the architecture associated with the code object to open is fully
	supported by both BFD and amd-dbgapi, and error-out otherwise.

	Change-Id: Ica97ab7cba45e4944b77d3080c54c1038aaeda54
	Approved-By: Pedro Alves <pedro@palves.net>

2023-08-24  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Return gdb::array_view in thread_info_to_thread_handle
	In remote_target::thread_info_to_thread_handle we return a copy:
	...
	gdb::byte_vector
	remote_target::thread_info_to_thread_handle (struct thread_info *tp)
	{
	  remote_thread_info *priv = get_remote_thread_info (tp);
	  return priv->thread_handle;
	}
	...

	Fix this by returning a gdb::array_view instead:
	...
	gdb::array_view<const gdb_byte>
	remote_target::thread_info_to_thread_handle (struct thread_info *tp)
	...

	Tested on x86_64-linux.

	This fixes the build when building with -std=c++20.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-08-24  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: fix kvx_reassemble_bundle index 8 out of bounds
	opcodes/
		* kvx-dis.c (print_insn_kvx): Change the loop condition so that
		wordcount is always less than KVXMAXBUNDLEWORDS.
		(decode_prologue_epilogue_bundle): Likewise.

2023-08-24  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: Multiple improvements for gdb.reverse/insn-reverse.exp
	This commits tackles 2 problems in the test
	gdb.reverse/insn-reverse.exp. They are, broadly: flawed logic when an
	unexpected error occurs, and badly formed asm expressions.

	For the first, what happens is that if the inferior stops progressing
	for some reason, the test will emit an UNSUPPORTED and continue testing
	by reversing from the current location and checking all registers for
	every instruction.  However, due to how the outputs are indexed in the
	test, this early exit will cause most of the subsequent tests to be
	de-synced and will emit many unrelated failures.

	This commit changes the UNSUPPORTED for a FAIL, since the test has in
	fact failed to record the execution of the whole function, and
	decrements the recorded instruction count by one so that the indexes are
	in sync once more.

	At the time of committing, this reduces the amount of failures when
	testing with clang-15 from around 150 to 2, and correctly identifies
	where the issue lies.

	The second problem is in how the asm statements in the *-x86.c file
	are written. As an example, let's examine the following line:

	__asm__ volatile ("rdrand %%ebp;" : "=r" (number));

	This statement says that number is being used as the output variable,
	but is not indicating which registers were clobbered so that the
	compiler is able to properly output. GCC decides to just not save
	anything, whereas clang assumes that the output is in %rax, and writes
	it to the variable. This hid the problem that any compiler is not good
	at dealing with asm statements that change the rbp register. It can be
	seen more explicitly by informing gcc that rbp has been clobbered like
	so:

	__asm__ volatile ("rdrand %%ebp;" : "=r" (number) : : "%ebp");

	This statement gets compiled into the following assembly:
	        rdrandl %ebp
	        movl    %eax, -4(%rbp)

	Which is clearly using the incorrect rbp to find the memory location of
	the variable. Since the test only exercises GDB's ability to record the
	register changes, this commit removes the output to memory.

	Finally, correctly informing the compiler of clobbered registers
	makes gcc throw an error that the rsp is no longer usable at the end of
	the function. To avoid that, this commit compresses the 3 asm statements
	that would save, change and reset registers into a single asm statement.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-24  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix testing gdb.reverse/step-reverse.exp with clang
	When testing using reverse-stepi to fully step through a function, the
	code checks for an infinite loop by seeing if we land on the line that
	contains the return statement multiple times. This assumption only works
	if there is only one instruction associated with that line, which is how
	GCC handles line information, but other compilers may handle it differently.
	Clang-15, for instance, associates 6. Because of this, the inferior used
	to get seriously out of sync with the test expectations, and result in 13
	spurious failures. The same issue occurs with gdb.reverse/step-precsave.exp.

	This commit changes the test so that we check for PC instead of line
	number. The test still only happens when the same line is detected, to
	simplify the resulting log. With this change, no new failures are
	emitted when using clang.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-24  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: fix gdb.reverse/solib-*.exp tests when using clang
	The tests gdb.reverse/solib-precsave.exp and solib-reverse.exp have the
	assumption that line tables will have an entry for the closing } in a
	function. Not all compiles do this, one example being clang. To fix
	this, this commit changes the function in shr2.c to have multiple lines,
	and the test to accept either line as a correct step location.

	To properly re-sync the inferiors, the function repeat_cmd_until had to
	be slightly changed to work with empty "current locations", so that we
	are able to step through multiple lines.

	This also changes the annotations used to determine the breakpoint
	locations in solib-reverse.c, adding a simple variable assignment right
	before the return statement. This way GDB will not set a breakpoint in
	the closing } line.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-24  Guinevere Larsen  <blarsen@redhat.com>

	gdb/testsuite: Fix many errors in gdb.reverse with clang
	Clang does not add line information for lines that only contain a
	closing } in functions. Many tests in the gdb.reverse folder set a
	breakpoint in that line, but don't seem to use information available
	after the return statement is executed, so this commit moves the
	breakpoint to the previous line, where the return statement is.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-24  Alan Modra  <amodra@gmail.com>

	kvx: workaround gcc-4.5 bug
	kvx-dis.c:1078:10: error: missing initializer
	kvx-dis.c:1078:10: error: (near initialization for 'dec.nb_ops')

		* kvx-dis.c (print_insn_kvx): Init dec with memset.
		(decode_prologue_epilogue_bundle): Likewise.

2023-08-24  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	optimize handle_COMDAT

2023-08-24  Alan Modra  <amodra@gmail.com>

	nds32, sh, kvx: DT_JMPREL/DT_PLTRELSZ
	As commit fa4f2d46f9 did for x86, there a few other targets that
	wrongly use the output section rather than the dynamic section for
	DT_JMPREL and others.

		* elfnn-kvx.c (elfNN_kvx_finish_dynamic_sections): Use input
		section for DT_JMPREL.
		* elf32-sh.c (sh_elf_finish_dynamic_sections): Use input
		section for DT_JMPREL and DT_PLTRELSZ.
		* elf32-nds32.c (nds32_elf_finish_dynamic_sections): Likewise,
		and for DT_PLTGOT and when adjusting DT_RELA.

2023-08-24  Stafford Horne  <shorne@gmail.com>

	sim: or1k: Eliminate dangerous RWX load segments
	This fixes test failures caused by the new linker warning which report:

	  ./ld/ld-new: warning: load.S.x has a LOAD segment with RWX permissions

	Fix this by splitting the linker MEMORY into ram and rom to avoid
	generating RWX sections.  This required tests to be adjusted to fix
	issues with the move.  Namely:

	  - fpu tests: were incorrectly using l.ori with ha(anchor) which now
	    that we pushed the anchor up in memory it exposes the bug.  Update
	    to used the correct l.movhi instruction instead.
	  - adrp test: the test reports ram offset addresses, now that we have
	    moved memory layout around a bit I adjusted the test output.  Some
	    padding is added before pi to show that the actual address of pi and
	    the adrp page offset are not the same.

	Bug: https://sourceware.org/PR29957

2023-08-24  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: bfd/config.bfd & ld/configure.tgt
	bfd/
		* config.bfd: Remove kvx_elf64_vec from targ_selvecs as it is
		already in targ_defvec.
	ld/
		* configure.tgt: Split long line.

2023-08-24  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: use {u,}int32_t and {u,}int64_t
	gas/
		* config/kvx-parse.c (promote_token): Use {u,}int32_t and
		{u,}int64_t.
		(get_token_class): Likewise.
		* config/tc-kvx.c (insert_operand): Likewise.
		* config/tc-kvx.h (struct token_s): Likewise.
		(struct token_list): Likewise.

	opcodes/
		* kvx-dis.c (struct decoded_insn): Use {u,}int32_t and
		{u,}int64_t.
		(decode_insn): Likewise.
		(print_insn_kvx): Likewise.
		(decode_prologue_epilogue_bundle): Likewise.
		* kvx-dis.h (struct kvx_prologue_epilogue_insn): Likewise.

2023-08-24  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: fix handling of STB_GNU_UNIQUE symbols
	When processing a STB_GNU_UNIQUE symbol we did not update has_gnu_osabi
	correctly.

		* config/tc-kvx.c (kvx_end): Do not write to e_ident.
		(kvx_type): Properly handle STB_GNU_UNIQUE symbols.

2023-08-24  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: remove kvx_elf64_linux_vec
		* configure.ac: Remove kvx_elf64_linux_vec.
		* configure: Regenerate.

2023-08-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-23  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Run black on make-target-delegates.py
	Run black on make-target-delegates.py to fix buildbot build breaker.

	Tested on x86_64-linux.

2023-08-23  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Support reference return type in make-target-delegates.py
	When doing this in target.h:
	...
	-    virtual gdb::byte_vector thread_info_to_thread_handle (struct thread_info *)
	+    virtual gdb::byte_vector &thread_info_to_thread_handle (struct thread_info *)
	...
	make-target-delegates.py drops the function.

	By handling '&' in POINTER_PART we can prevent that the function is dropped,
	but when recompiling target.o we get:
	...
	gdb/target-delegates.c: In member function ‘virtual gdb::byte_vector& \
	  debug_target::thread_info_to_thread_handle(thread_info*)’:
	gdb/target-delegates.c:1889:22: error: ‘result’ declared as reference but not \
	  initialized
	   gdb::byte_vector & result;
	                      ^~~~~~
	make: *** [Makefile:1923: target.o] Error 1
	...

	Fix this by making sure result is initialized.

	Regenerate target-delegates.c using this new style.

	Tested on x86_64-linux.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-08-23  Peter Edwards  <peadar@arista.com>

	x86: Fix DT_JMPREL/DT_PLTRELSZ when relocs share a section
	If a linker script does not place the PLT relocations and "normal"
	relocations in separate ELF sections, `ld` will currently output incorrect
	values for DT_JMPREL and DT_PLTRELSZ - they cover the entire ELF section,
	rather than just the PLT relocations

	Don't ignore the extent of the BFD section - use the size of the srelplt
	BFD section and its offset from the output_secttion

	bfd/

		PR ld/30787
		* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use input
		section for DT_JMPREL and DT_PLTRELSZ.

	ld/

		PR ld/30787
		* testsuite/ld-i386/i386.exp: Run pr30787.
		* testsuite/ld-x86-64/x86-64.exp: Likewise.
		* testsuite/ld-i386/pr30787.d: New file.
		* testsuite/ld-i386/pr30787.s: Likewise.
		* testsuite/ld-i386/pr30787.t: Likewise.
		* testsuite/ld-x86-64/pr30787.d: Likewise.
		* testsuite/ld-x86-64/pr30787.s: Likewise.
		* testsuite/ld-x86-64/pr30787.t: Likewise.

2023-08-23  Lancelot Six  <lancelot.six@amd.com>

	gdb: fix build failure in amd-dbgapi-target.c
	Since b080fe54fb3 "gdb: add inferior-specific breakpoints", the
	breakpoint class has an "inferior" member used to handle
	inferior-specific breakpoints.  This creates a compilation error
	in amd_dbgapi_target_breakpoint::check_status which declares a local
	variable "inferior *inf".

	Fix this by using "struct inferior *inf" instead.

	Change-Id: Icc4dc1ba96c7d3ff9d33f9cb384ffcf64eba26fb
	Approved-By: Pedro Alves <pedro@palves.net>

2023-08-23  Pedro Alves  <pedro@palves.net>

	Fix Windows sharing_input_terminal hang
	After running a number of programs under Windows gdb and detaching
	them, I typed run in gdb, and got a hang, here:

	 (top-gdb) bt
	 #0  sharing_input_terminal (pid=4672) at /home/pedro/gdb/src/gdb/mingw-hdep.c:388
	 #1  0x00007ff71a2d8678 in sharing_input_terminal (inf=0x23bf23dafb0) at /home/pedro/gdb/src/gdb/inflow.c:269
	 #2  0x00007ff71a2d887b in child_terminal_save_inferior (self=0x23bf23de060) at /home/pedro/gdb/src/gdb/inflow.c:423
	 #3  0x00007ff71a2c80c0 in inf_child_target::terminal_save_inferior (this=0x23bf23de060) at /home/pedro/gdb/src/gdb/inf-child.c:111
	 #4  0x00007ff71a429c0f in target_terminal_is_ours_kind (desired_state=target_terminal_state::is_ours_for_output) at /home/pedro/gdb/src/gdb/target.c:1037
	 #5  0x00007ff71a429e02 in target_terminal::ours_for_output () at /home/pedro/gdb/src/gdb/target.c:1094
	 #6  0x00007ff71a2ccc8e in post_create_inferior (from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:245
	 #7  0x00007ff71a2cd431 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at /home/pedro/gdb/src/gdb/infcmd.c:502
	 #8  0x00007ff71a2cd58b in run_command (args=0x0, from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:527

	The problem is that the loop around GetConsoleProcessList looped
	forever, because there were exactly 10 processes to return.
	GetConsoleProcessList's documentation says:

	  If the buffer is too small to hold all the valid process identifiers,
	  the return value is the required number of array elements. The
	  function will have stored no identifiers in the buffer. In this
	  situation, use the return value to allocate a buffer that is large
	  enough to store the entire list and call the function again.

	In this case, the buffer wasn't too small, it was exactly the right
	size, so we should have broken out of the loop.  We didn't due to a
	"<" check that should have been "<=".  That is fixed by this patch.

	Approved-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Change-Id: I14e4909f2ac2fa83d0d9b6e64418b5831ac4e4e3

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix up a few places where a char was treated as a bool
	Spotted a few places where a char is being treated as a bool.  The GDB
	style is to use explicit comparisons, so fix things up.

	There should be no user visible changes after this commit.

2023-08-23  Nick Clifton  <nickc@redhat.com>

	Correct PR number in previous delta

	readelf/objdump: Handle DWARF info with mixed types of range section.
	  PR 30791
	  * dwarf.h (debug_info): Add range_versions field.
	  * dwarf.c (read_and_display_attr_value): When recording a range arribute also ecord the dwarf version number.
	  (is_range_list_for_this_section): New function.
	  (display_debug_ranges): Only show debug ranges whose version is suitable for the secction being displayed.

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: MI stopped events when unwindonsignal is on
	This recent commit:

	  commit b1c0ab20809a502b2d2224fecb0dca3ada2e9b22
	  Date:   Wed Jul 12 21:56:50 2023 +0100

	      gdb: avoid double stop after failed breakpoint condition check

	Addressed a problem where two MI stopped events would be reported if a
	breakpoint condition failed due to a signal, this commit was a
	replacement for this commit:

	  commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
	  Date:   Fri Oct 14 14:53:15 2022 +0100

	      gdb: don't always print breakpoint location after failed condition check

	which solved the two stop problem, but only for the CLI.  Before both
	of these commits, if a b/p condition failed due to a signal then the
	user would see two stops reported, the first at the location where the
	signal occurred, and the second at the location of the breakpoint.

	By default GDB remains at the location where the signal occurred, so
	the second reported stop can be confusing, this is the problem that
	commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a
	extended also address the issue for MI too.

	However, while working on another patch I realised that there was a
	problem with GDB after the above commits.  Neither of the above
	commits considered 'set unwindonsignal on'.  With this setting on,
	when an inferior function call fails with a signal GDB will unwind the
	stack back to the location where the inferior function call started.
	In the b/p case we're looking at, the stop should be reported at the
	location of the breakpoint, not at the location where the signal
	occurred, and this isn't what happens.

	This commit fixes this by ensuring that when unwindonsignal is 'on',
	GDB reports a single stop event at the location of the breakpoint,
	this fixes things for both CLI and MI.

	The function call_thread_fsm::should_notify_stop is called when the
	inferior function call completes and GDB is figuring out if the user
	should be notified about this stop event by calling normal_stop from
	fetch_inferior_event in infrun.c.  If normal_stop is called, then this
	notification will be for the location where the inferior call stopped,
	which will be the location at which the signal occurred.

	Prior to this commit, the only time that normal_stop was not called,
	was if the inferior function call completed successfully, this was
	controlled by ::should_notify_stop, which only turns false when the
	inferior function call has completed successfully.

	In this commit I have extended the logic in ::should_notify_stop.  Now
	there are three cases in which ::should_notify_stop will return false,
	and we will not announce the first stop (by calling normal_stop).
	These three reasons are:

	  1. If the inferior function call completes successfully, this is
	  unchanged behaviour,

	  2. If the inferior function call stopped due to a signal and 'set
	  unwindonsignal on' is in effect, and

	  3. If the inferior function call stopped due to an uncaught C++
	  exception, and 'set unwind-on-terminating-exception on' is in
	  effect.

	However, if we don't call normal_stop then we need to call
	async_enable_stdin in call_thread_fsm::should_stop.  Prior to this
	commit this was only done for the case where the inferior function
	call completed successfully.

	In this commit I now call ::should_notify_stop and use this to
	determine if we need to call async_enable_stdin.  With this done we
	now call async_enable_stdin for each of the three cases listed above,
	which means that GDB will exit wait_sync_command_done correctly (see
	run_inferior_call in infcall.c).

	With these two changes the problem is mostly resolved.  However, the
	solution isn't ideal, we've still lost some information.

	Here is how GDB 13.1 behaves, this is before commits b1c0ab20809a and
	2e411b8c68eb:

	  $ gdb -q /tmp/mi-condbreak-fail \
	        -ex 'set unwindonsignal on' \
	        -ex 'break 30 if (cond_fail())' \
	        -ex 'run'
	  Reading symbols from /tmp/mi-condbreak-fail...
	  Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
	  Starting program: /tmp/mi-condbreak-fail

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
	  24	  return *p;			/* Crash here.  */
	  Error in testing breakpoint condition:
	  The program being debugged was signaled while in a function called from GDB.
	  GDB has restored the context to what it was before the call.
	  To change this behavior use "set unwindonsignal off".
	  Evaluation of the expression containing the function
	  (cond_fail) will be abandoned.

	  Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
	  30	  global_counter += 1;		/* Set breakpoint here.  */
	  (gdb)

	In this state we see two stop notifications, the first is where the
	signal occurred, while the second is where the breakpoint is located.
	As GDB has unwound the stack (thanks to unwindonsignal) the second
	stop notification reflects where the inferior is actually located.

	Then after commits b1c0ab20809a and 2e411b8c68eb the behaviour changed
	to this:

	  $ gdb -q /tmp/mi-condbreak-fail \
	        -ex 'set unwindonsignal on' \
		-ex 'break 30 if (cond_fail())' \
		-ex 'run'
	  Reading symbols from /tmp/mi-condbreak-fail...
	  Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
	  Starting program: /tmp/mi-condbreak-fail

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
	  24	  return *p;			/* Crash here.  */
	  Error in testing condition for breakpoint 1:
	  The program being debugged was signaled while in a function called from GDB.
	  GDB has restored the context to what it was before the call.
	  To change this behavior use "set unwindonsignal off".
	  Evaluation of the expression containing the function
	  (cond_fail) will be abandoned.
	  (gdb) bt 1
	  #0  foo () at /tmp/mi-condbreak-fail.c:30
	  (More stack frames follow...)
	  (gdb)

	This is the broken state.  GDB is reports the SIGSEGV location, but
	not the unwound breakpoint location.  The final 'bt 1' shows that the
	inferior is not located in cond_fail, which is the only location GDB
	reported, so this is clearly wrong.

	After implementing the fixes described above we now get this
	behaviour:

	  $ gdb -q /tmp/mi-condbreak-fail \
	        -ex 'set unwindonsignal on' \
	        -ex 'break 30 if (cond_fail())' \
	        -ex 'run'
	  Reading symbols from /tmp/mi-condbreak-fail...
	  Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
	  Starting program: /tmp/mi-condbreak-fail
	  Error in testing breakpoint condition for breakpoint 1:
	  The program being debugged was signaled while in a function called from GDB.
	  GDB has restored the context to what it was before the call.
	  To change this behavior use "set unwindonsignal off".
	  Evaluation of the expression containing the function
	  (cond_fail) will be abandoned.

	  Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
	  30	  global_counter += 1;		/* Set breakpoint here.  */
	  (gdb)

	This is better.  GDB now reports a single stop at the location of the
	breakpoint, which is where the inferior is actually located.  However,
	by removing the first stop notification we have lost some potentially
	useful information about which signal caused the inferior to stop.

	To address this I've reworked the message that is printed to include
	the signal information.  GDB now reports this:

	  $ gdb -q /tmp/mi-condbreak-fail \
	        -ex 'set unwindonsignal on' \
	        -ex 'break 30 if (cond_fail())' \
	        -ex 'run'
	  Reading symbols from /tmp/mi-condbreak-fail...
	  Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
	  Starting program: /tmp/mi-condbreak-fail
	  Error in testing condition for breakpoint 1:
	  The program being debugged received signal SIGSEGV, Segmentation fault
	  while in a function called from GDB.  GDB has restored the context
	  to what it was before the call.  To change this behavior use
	  "set unwindonsignal off".  Evaluation of the expression containing
	  the function (cond_fail) will be abandoned.

	  Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
	  30	  global_counter += 1;		/* Set breakpoint here.  */
	  (gdb)

	This is better, the user now sees a single stop notification at the
	correct location, and the error message describes which signal caused
	the inferior function call to stop.

	However, we have lost the information about where the signal
	occurred.  I did consider trying to include this information in the
	error message, but, in the end, I opted not too.  I wasn't sure it was
	worth the effort.  If the user has selected to unwind on signal, then
	surely this implies they maybe aren't interested in debugging failed
	inferior calls, so, hopefully, just knowing the signal name will be
	enough.  I figure we can always add this information in later if
	there's a demand for it.

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add mi_info_frame helper proc (and use it)
	New helper proc mi_info_frame which takes care of running the MI
	-stack-info-frame command and matching its output.

	Like the breakpoint helper procs, this new proc takes a name/value
	argument list and uses this to build the expected result regexp.  This
	means that we can now write something like:

	  mi_info_frame "test name here" \
	    -level 0 -func name -line 123

	Instead of the current equivalent:

	  mi_gdb_test "235-stack-info-frame" \
	    "235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"name\",file=\".*\",fullname=\".*\",line=\"123\",arch=\".*\"\}" \
	    "test name here"

	There's also a helper proc mi_make_info_frame_regexp which is
	responsible for building the 'frame={...}' part of the pattern.

	I've update the two existing tests that use -stack-info-frame and
	expect the command to succeed.  There is another test that runs
	-stack-info-frame and expects the command to fail -- the helper proc
	doesn't help with this case, so that test is not changed.

2023-08-23  Pedro Alves  <pedro@palves.net>

	gdb: centralize "[Thread ...exited]" notifications
	Currently, each target backend is responsible for printing "[Thread
	...exited]" before deleting a thread.  This leads to unnecessary
	differences between targets, like e.g. with the remote target, we
	never print such messages, even though we do print "[New Thread ...]".

	E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
	with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
	currently see:

	 (gdb) c
	 Continuing.
	 ^C[New Thread 3850398.3887449]
	 [New Thread 3850398.3887500]
	 [New Thread 3850398.3887551]
	 [New Thread 3850398.3887602]
	 [New Thread 3850398.3887653]
	 ...

	 Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
	 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
	     at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
	 78      in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
	 (gdb)

	Above, we only see "New Thread" notifications, even though threads
	were deleted.

	After this patch, we'll see:

	 (gdb) c
	 Continuing.
	 ^C[Thread 3558643.3577053 exited]
	 [Thread 3558643.3577104 exited]
	 [Thread 3558643.3577155 exited]
	 [Thread 3558643.3579603 exited]
	 ...
	 [New Thread 3558643.3597415]
	 [New Thread 3558643.3600015]
	 [New Thread 3558643.3599965]
	 ...

	 Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
	 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
	     at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
	 78      in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
	 (gdb) q

	This commit fixes this by moving the thread exit printing to common
	code instead, triggered from within delete_thread (or rather,
	set_thread_exited).

	There's one wrinkle, though.  While most targest want to print:

	 [Thread ... exited]

	the Windows target wants to print:

	 [Thread ... exited with code <exit_code>]

	... and sometimes wants to suppress the notification for the main
	thread.  To address that, this commits adds a delete_thread_with_code
	function, only used by that target (so far).

	This fix was originally posted as part of a larger series:

	  https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/

	But didn't really need to be part of that series.  In order to get
	this fix merged sooner, I (Andrew Burgess) have rebased this commit
	outside of the original series.  Any bugs introduced while splitting
	this patch out and rebasing, are entirely my own.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129
	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove the silent parameter from exit_inferior_1 and cleanup
	After the previous commit, exit_inferior_1 no longer makes use of the
	silent parameter.  This commit removes this parameter and cleans up
	the callers.

	After doing this exit_inferior_1, exit_inferior, and
	exit_inferior_silent are all equivalent, so rename exit_inferior_1 to
	exit_inferior and delete exit_inferior_silent, update all the callers.

	Also I spotted the declaration exit_inferior_num_silent in inferior.h,
	but this function is not defined anywhere, so I deleted the
	declaration.

	There should be no user visible changes after this commit.

2023-08-23  Pedro Alves  <pedro@palves.net>

	gdb: make inferior::clear_thread_list always silent
	After this commit:

	  commit a78ef8757418105c35685c5d82b9fdf79459321b
	  Date:   Wed Jun 22 18:10:00 2022 +0100

	      Always emit =thread-exited notifications, even if silent

	The function mi_interp::on_thread_exited (or mi_thread_exit as the
	function was called back then) no longer makes use of the "silent"
	parameter.

	As a result there is no difference between inferior::clear_thread_list
	with silent true or false, because:

	  - None of the interpreter ::on_thread_exited functions rely on the
	    silent parameter, and

	  - None of GDB's thread_exit observers rely on the silent parameter
	  either.

	This commit removes the silent parameter from
	inferior::clear_thread_list, and makes the function always silent.

	This commit was originally part of a larger series:

	  https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/

	But didn't really need to be part of that series.  I had an interest
	in seeing this patch merged:

	  https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-31-pedro@palves.net/

	Which also didn't really need to be part of the larger series, but
	does depend, at least a little, on this commit.  In order to get the
	fix I'm interested in merged quicker, I (Andrew Burgess) have rebased
	this commit outside of the original series.  Any bugs introduced while
	splitting this patch out and rebasing, are entirely my own.

	There should be no user visible changes after this commit.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove mi_parse::make functions
	Remove the static mi_parse::make functions, and instead use the
	mi_parse constructor.

	This is a partial revert of the commit:

	  commit fde3f93adb50c9937cd2e1c93561aea2fd167156
	  Date:   Mon Mar 20 10:56:55 2023 -0600

	      Introduce "static constructor" for mi_parse

	which introduced the mi_parse::make functions, though after discussion
	on the list the reasons for seem to have been lost[1].  Given there
	are no test regressions when moving back to using the constructors, I
	propose we should do that for now.

	There should be no user visible changes after this commit.

	[1] https://inbox.sourceware.org/gdb-patches/20230404-dap-loaded-sources-v2-5-93f229095e03@adacore.com/

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: have mi_out_new return std::unique_ptr
	Have the mi_out_new function return a std::unique_ptr instead of a raw
	pointer.  Update the two uses of mi_out_new.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: add gdb::make_unique function
	While GDB is still C++11, lets add a gdb::make_unique template
	function that can be used to create std::unique_ptr objects, just like
	the C++14 std::make_unique.

	If GDB is being compiled with a C++14 compiler then the new
	gdb::make_unique function will delegate to the std::make_unique.  I
	checked with gcc, and at -O1 and above gdb::make_unique will be
	optimised away completely in this case.

	If C++14 (or later) becomes our minimum, then it will be easy enough
	to go through the code and replace gdb::make_unique with
	std::make_unique later on.

	I've make use of this function in all the places I think this can
	easily be used, though I'm sure I've probably missed some.

	Should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: improve MI support for inferior specific breakpoints
	In this commit:

	  commit b080fe54fb3414b488b8ef323c6c50def061f918
	  Date:   Tue Nov 8 12:32:51 2022 +0000

	      gdb: add inferior-specific breakpoints

	limited support was added in lib/mi-support.exp to help with testing
	of inferior specific breakpoints.

	Though the changes that were added were not wrong, while working on a
	later patch, I realised that I had added the support in the wrong
	place -- I only added support to mi_make_breakpoint_multi, when really
	I should have added the support to mi_make_breakpoint_1, which is used
	by all of the MI procs that create breakpoints.

	This commit moves the support to mi_make_breakpoint_1, and updates all
	the procs that use mi_make_breakpoint_1 to accept, and then pass
	through, and (optional) inferior argument.  This will make it much
	easier to write MI tests for inferior specific breakpoints.

	There's no change in what is tested after this commit.

2023-08-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: add missing notify_breakpoint_modified call
	The commit:

	  commit b080fe54fb3414b488b8ef323c6c50def061f918
	  Date:   Tue Nov 8 12:32:51 2022 +0000

	      gdb: add inferior-specific breakpoints

	introduced a bug in the function breakpoint_set_inferior. The above
	commit includes this line:

	  gdb::observers::breakpoint_modified.notify (b);

	when it should have instead used this line:

	  notify_breakpoint_modified (b);

	The change to use notify_breakpoint_modified was introduced to GDB
	after commit b080fe54fb34 was written, but before it was merged, and I
	failed to update this part of the code during the rebase.

	The consequence of this error is that the MI interpreter will not emit
	breakpoint-modified notifications when breakpoint_set_inferior is
	called.

	In this commit I update the code to call notify_breakpoint_modified,
	and add a test that checks the MI events are being emitted correctly
	in this case.

2023-08-23  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: fix 32-bit build
	bfd/
		* Makefile.am: Move elf32-kvx.lo from BFD32_BACKENDS to
		BFD64_BACKENDS.  Remove elfxx-kvx.lo from BFD32_BACKENDS.
		Remove elfxx-kvx.c from BFD32_BACKENDS_CFILES.
		* Makefile.in: Regenerate.
		* config.bfd: Adjust targ_defvec and targ_selvecs and gate them
		behind BFD64.
		* configure.ac: Add target_size=64 to kvx_elf64_*vec.
		* configure: Regenerate.
		* elfnn-kvx.c (elfNN_kvx_stub_name): Cast rel->r_addend to
		uint64_t to match format string.
		(elfNN_kvx_relocate_section): Similarly for r_offset, and
		use PRIx64 in format string.
		* targets.c (_bfd_target_vector <kvx_elf32_vec>): Move inside
		#ifdef BFD64.
	ld/
		* Makefile.am: Move eelf32kvx.c from ALL_EMULATION_SOURCES to
		ALL_64_EMULATION_SOURCES.
		* Makefile.in: Regenerate.

2023-08-23  Alan Modra  <amodra@gmail.com>

	kvx: O_pseudo_fixup
	O_pseudo_fixup was defined as O_max+1, missing the fact that O_md1
	through O_md32 enums are for use by target code.  Worse, kvx-parse.c
	used 64 rather than O_pseudo_fixup.  Fix this, and wrap some overlong
	lines.

		* config/tc-kvx.h (O_pseudo_fixup): Define.
		* config/tc-kvx.c (O_pseudo_fixup): Don't define here.
		(insert_operand): Delete bogus comment and cast.
		* config/kvx-parse.c (promote_token): Use O_pseudo_fixup
		rather than hardcoded value.  Wrap overlong lines.
		(get_token_class): Likewise.
		(parse_with_restarts): Wrap overlong line.

2023-08-23  Alan Modra  <amodra@gmail.com>

	kvx: ubsan: integer overflow
	This fixes a few places where ubsan complains about signed integer
	overflow when running the testsuite, and that clz(0) is undefined.
	When fixing the clz problem, I also noticed that we'd get complaints
	if pval is ever LLONG_MIN.  Fix that by using unsigned arithmetic.

		* config/kvx-parse.c (get_token_class): Avoid signed overflow.
		Don't clz(0).
		* config/tc-kvx.c (PARALLEL_BIT): Avoid signed overflow.

2023-08-23  Alan Modra  <amodra@gmail.com>

	kvx: asan: out-of-bounds read
	kvx-parse.c:parse_with_restarts does
	  if (!tok.insn[tok.begin])
	    tok.class_id = -3;
	then a little later
	  printf_debug (1, "\nEntering rule: %d (Trying to match: (%s)[%d])\n", jump_target,
			TOKEN_NAME (CLASS_ID (tok)), CLASS_ID (tok));

	This results in a buffer overrun in TOKEN_NAME.  Fix that.

		* config/tc-kvx.h (TOKEN_NAME): Check for tok <= 0, not just -1.

2023-08-23  Alan Modra  <amodra@gmail.com>

	kvx bfd signed calculations and _bfd_kvx_elf_resolve_relocation
	It is generally a good idea to avoid signed arithmetic on values
	extracted from object files, to avoid ubsan warnings on overflow.
	This patch replaces some uses of bfd_signed_vma in the kvx backend
	with bfd_vma, and removes _bfd_kvx_elf_resolve_relocation, a
	do-nothing function.  In the process of making this patch I noticed
	some dead code in the GOT entry handling, setting value to
	got_entry_addr but using "off" in the _bfd_final_link_relocate call.
	Since kvx_calculate_got_entry_vma also returns the GOT offset, I
	presume the code is correct, but I've left the dead code and comment
	there.

		* elfxx-kvx.h (_bfd_kvx_elf_resolve_relocation): Delete.
		* elfxx-kvx.c (kvx_signed_overflow): Rewrite using unsigned
		arithmetic.
		(_bfd_kvx_elf_resolve_relocation): Delete.
		* elfnn-kvx.c (kvx_relocate): Update for
		_bfd_kvx_elf_resolve_relocation removal.
		(elfNN_kvx_final_link_relocate): Likewise.  Don't use a signed
		addend.

2023-08-23  Alan Modra  <amodra@gmail.com>

	bfd kvx formatting fixes
	Indentation, whitespace and comment fixes.

		* elfnn-kvx.c: Formatting.
		* elfxx-kvx.c: Formatting.
		(elfNN_kvx_final_link_relocate): Correct GOT entry comment.

2023-08-23  Alan Modra  <amodra@gmail.com>

	gdb: bfd_get_symbol_leading_char vs. ""
	Some places matching the first char of a string against
	bfd_get_symbol_leading_char, which may be zero, didn't check for "".
	This could lead to accesses past the end of the string and potential
	buffer overruns.  Fix that, and also get rid of a stupid optimisation
	in dbxread when looking for "__DYNAMIC" that also might access past
	the end of a string.

2023-08-23  Alan Modra  <amodra@gmail.com>

	bfd_get_symbol_leading_char vs. ""
	Some places matching the first char of a string against
	bfd_get_symbol_leading_char, which may be zero, didn't check for the
	string being "".  This patch adds the check to stop accesses past the
	end of the string and potential buffer overruns.
	The dlltool one was found by oss-fuzz quite a while ago.

	bfd/
		* cofflink.c (_bfd_coff_link_input_bfd): Ensure a zero
		bfd_get_symbol_leading_char doesn't lead to accessing past the
		zero string terminator.
		* linker.c (bfd_wrapped_link_hash_lookup): Likewise.
		(unwrap_hash_lookup): Likewise.
	binutils/
		* dlltool.c (scan_filtered_symbols): Ensure a zero
		bfd_get_symbol_leading_char doesn't lead to accessing past the
		zero string terminator.

2023-08-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-22  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Work around cgen odr violations
	When building gdb with -flto -O2, I run into:
	...
	opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
	  C++ One Definition Rule [-Wodr]
	 typedef enum cgen_operand_type {
	              ^
	opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
	  defined in another translation unit
	 typedef enum cgen_operand_type {
	              ^
	opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
	  Definition Rule [-Wodr]
	 typedef enum cgen_hw_type {
	              ^
	opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
	  defined in another translation unit
	 typedef enum cgen_hw_type {
	              ^
	...

	Fix this by making the conflicting type names unique, adding a target-specific
	prefix using a define before the include:
	...
	 #define cgen_operand_type <target-name>_cgen_operand_type
	 #define cgen_hw_type  <target-name>_cgen_hw_type
	 #include "opcodes/<target-name>-desc.h"
	...
	and move those defines into a new file cgen-remap.h, similar to how that's
	done for yacc in yy-remap.h.

	Likewise for targets frv and lm32, the two other targets that include
	opcodes/<target-name>-desc.h.

	Likewise for more cgen symbols that I got the same warning for when using
	-flto-partition=one.

	A PR has been filed to take care of this in the opcodes dir instead (PR30758).

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/30757
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757

2023-08-22  Tom Tromey  <tromey@adacore.com>

	Remove value::copy call from gdbpy_get_varobj_pretty_printer
	I noticed a call to value::copy in gdbpy_get_varobj_pretty_printer,
	and I couldn't figure out why it was there.  I think maybe it came
	from the time when value_to_value_object would release values from the
	value chain -- but that was removed in commit f3d3bbbc.

	This patch removes this call.  Regression tested on x86-64 Fedora 36.

2023-08-22  Victor Do Nascimento  <Victor.DoNascimento@arm.com>

	aarch64: Improve naming conventions for A and R-profile architecture
	Historically, flags and variables relating to architectural revisions
	for the A-profile architecture omitted the trailing `A' such that, for
	example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
	flag in the assembler.

	This leads to some ambiguity, since Binutils also targets the
	R-profile Arm architecture.  Therefore, it seems prudent to have
	everything associated with the A-profile cores end in `A' and likewise
	`R' for the R-profile.  Referring back to the example above, the flag
	set for `-march=armv8.4-a' is better characterized if labeled
	`AARCH64_ARCH_V8_4A'.

	The only exception to the rule of appending `A' to variables is found
	in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
	baseline from which ALL processors derive and should therefore be left
	unchanged.

	In reflecting the `ARM' architectural nomenclature choices, where we
	have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
	an underscore separating the numerical revision number and the
	A/R-profile indicator suffix.  This has meant that renaming of
	R-profile related flags and variables was warranted, thus going from
	`.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.

	Finally, this is more in line with conventions within GCC and adds consistency
	across the toolchain.

	gas/ChangeLog:
		* gas/config/tc-aarch64.c:
		(aarch64_cpus): Reference to arch feature macros updated.
		(aarch64_archs): Likewise.

	include/ChangeLog:
		* include/opcode/aarch64.h:
		(AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A.
		(AARCH64_FEATURE_V8_1A): A-suffix added.
		(AARCH64_FEATURE_V8_2A): Likewise.
		(AARCH64_FEATURE_V8_3A): Likewise.
		(AARCH64_FEATURE_V8_4A): Likewise.
		(AARCH64_FEATURE_V8_5A): Likewise.
		(AARCH64_FEATURE_V8_6A): Likewise.
		(AARCH64_FEATURE_V8_7A): Likewise.
		(AARCH64_FEATURE_V8_8A):Likewise.
		(AARCH64_FEATURE_V9A): Likewise.
		(AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R.
		(AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A.
		(AARCH64_ARCH_V8_1A_FEATURES): A-suffix added.
		(AARCH64_ARCH_V8_2A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_3A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_4A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_5A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_6A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_7A_FEATURES): Likewise.
		(AARCH64_ARCH_V8_8A_FEATURES): Likewise.
		(AARCH64_ARCH_V9A_FEATURES): Likewise.
		(AARCH64_ARCH_V9_1A_FEATURES): Likewise.
		(AARCH64_ARCH_V9_2A_FEATURES): Likewise.
		(AARCH64_ARCH_V9_3A_FEATURES): Likewise.
		(AARCH64_ARCH_V8A): Updated name: V8_A -> V8A.
		(AARCH64_ARCH_V8_1A): A-suffix added.
		(AARCH64_ARCH_V8_2A): Likewise.
		(AARCH64_ARCH_V8_3A): Likewise.
		(AARCH64_ARCH_V8_4A): Likewise.
		(AARCH64_ARCH_V8_5A): Likewise.
		(AARCH64_ARCH_V8_6A): Likewise.
		(AARCH64_ARCH_V8_7A): Likewise.
		(AARCH64_ARCH_V8_8A): Likewise.
		(AARCH64_ARCH_V9A): Likewise.
		(AARCH64_ARCH_V9_1A): Likewise.
		(AARCH64_ARCH_V9_2A): Likewise.
		(AARCH64_ARCH_V9_3A): Likewise.
		(AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R.

	opcodes/ChangeLog:
		* opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A.
		(SR_V8_1A): A-suffix added.
		(SR_V8_2A): Likewise.
		(SR_V8_3A): Likewise.
		(SR_V8_4A): Likewise.
		(SR_V8_6A): Likewise.
		(SR_V8_7A): Likewise.
		(SR_V8_8A): Likewise.
		(aarch64_sys_regs): Reference to arch feature macros updated.
		(aarch64_pstatefields): Reference to arch feature macros updated.
		(aarch64_sys_ins_reg_supported_p): Reference to arch feature macros
		updated.
		* opcodes/aarch64-tbl.h:
		(aarch64_feature_v8_2a): a-suffix added.
		(aarch64_feature_v8_3a): Likewise.
		(aarch64_feature_fp_v8_3a): Likewise.
		(aarch64_feature_v8_4a): Likewise.
		(aarch64_feature_fp_16_v8_2a): Likewise.
		(aarch64_feature_v8_5a): Likewise.
		(aarch64_feature_v8_6a): Likewise.
		(aarch64_feature_v8_7a): Likewise.
		(aarch64_feature_v8r): Updated name: v8_r-> v8r.
		(ARMV8R): Updated name: V8_R-> V8R.
		(ARMV8_2A): A-suffix added.
		(ARMV8_3A): Likewise.
		(FP_V8_3A): Likewise.
		(ARMV8_4A): Likewise.
		(FP_F16_V8_2A): Likewise.
		(ARMV8_5): Likewise.
		(ARMV8_6A): Likewise.
		(ARMV8_6A_SVE): Likewise.
		(ARMV8_7A): Likewise.
		(V8_2A_INSN): `A' added to macro symbol.
		(V8_3A_INSN): Likewise.
		(V8_4A_INSN): Likewise.
		(FP16_V8_2A_INSN): Likewise.
		(V8_5A_INSN): Likewise.
		(V8_6A_INSN): Likewise.
		(V8_7A_INSN): Likewise.
		(V8R_INSN): Updated name: V8_R-> V8R.

2023-08-22  Alan Modra  <amodra@gmail.com>

	objdump: file name table entry count check
	Fuzzers have found that objdump -W takes a really long time if
	the entry count uleb is ridiculously large, and format attributes
	don't consume data (which doesn't make sense for a table of names).

		* dwarf.c (display_formatted_table): Sanity check count of
		table entries.

2023-08-22  Alan Modra  <amodra@gmail.com>

	kvx_dis_init
	kvx_dis_init currently always returns true, but error conditions do so
	by "return -1" which converts to true.  The return status is ignored
	anyway, and it doesn't make much sense to error on unexpected arch or
	mach:  If print_insn_kvx is called then the atch is known to be kvx,
	and it's better to choose some default for a user passing an unknown
	mach value rather than segfaulting in decode_insn when env.opc_table
	is NULL.

	I've chosen the default mach to be bfd_mach_kv3_1, the default in
	bfd/cpu-kvx.c, not that it matters very much.  In normal objdump/gdb
	usage, info->mach won't be an unexpected value.

		* kvx-dis.c (kvx_dis_init): Return void.  Don't error on
		unexpected arch or mach.  Default to bfd_mach_kv3_1 for
		unknown mach.  Don't clear info->disassembler_options.

2023-08-22  Alan Modra  <amodra@gmail.com>

	kvx-linux config
	A misplaced line, resulting in testsuite errors when attempting to use
	as -m32.

		* config.bfd (kvx-*-linux*): Add targ_selvecs.
		(kvx-*-*): Remove targ_selvecs.

2023-08-22  Alan Modra  <amodra@gmail.com>

	Re: kvx: New port.
	Add files submitted on the mailing list but somehow not committed.

2023-08-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-21  David Faust  <david.faust@oracle.com>

	sim: bpf: remove negi, neg32i insns
	The BPF virtual machine does not support neg instructions operating on
	immediates, and these erroneous instructions were recently removed from
	gas.  Remove them from the simulator as well.

2023-08-21  David Faust  <david.faust@oracle.com>

	bpf: correct neg and neg32 instruction encoding
	The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
	source bit, despite operating on registers.  If BPF_SRC_X (=1) is set,
	the instructions are rejected by the kernel.

	Because of this there are also no neg/neg32 instructions which operate
	on immediates, so remove them.

	bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old
	CGEN-based port, but was not carried forward in the new port.

	include/
		* opcode/bpf.h (enum bpf_insn_id): Remove spurious entries
		BPF_INSN_NEGI and BPF_INSN_NEG32I.

	opcodes/
		* bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I
		instructions.

	gas/
		* doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and
		neg32 instructions operating on immediates.
		* testsuite/gas/bpf/alu.s: Adapt accordingly.
		* testsuite/gas/bpf/alu.d: Likewise.
		* testsuite/gas/bpf/alu-be.d: Likewise
		* testsuite/gas/bpf/alu32.s: Likewise.
		* testsuite/gas/bpf/alu32.d: Likewise.
		* testsuite/gas/bpf/alu32-be.d: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.

2023-08-21  Luis Machado  <luis.machado@arm.com>

	aarch64/sme2: Teach binutils/BFD about the NT_ARM_ZT register set
	The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that
	the Linux Kernel handles through a new NT_ARM_ZT register set.

	Teach binutils/BFD about it so that gdb can make use of it for reading
	and writing core files.  This also enables readelf/objdump to show the
	correct identification for the NT_ARM_ZT register set.

	Validated under Fast Models.

2023-08-21  Ezra Sitorus  <ezra.sitorus@arm.com>

	aarch64/sme: Core file support
	Add required code to support core file dumps with NT_ARM_ZA and NT_ARM_SSVE
	register sets in them.

	These new register sets are dumped when SME is supported.

2023-08-21  Alan Modra  <amodra@gmail.com>

	bfd_close_all_done bug and bfd_last_cache
	bfd_close ought to always call iovec->bclose so that cache_bclose is
	called.  If not, bfd_last_cache will be left pointing at freed memory.
	This bug was found by oss-fuzz with the trigger being an old bug in
	the ia64-vms support.  Given a file of the "wrong" size,
	elf64_vms_close_and_cleanup attempted to extend it, leading to an
	error since the file was opened read-only by nm.  nm bad_file bad_file
	then hit the use-after-free when opening the second file.

	commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and
	bfd_close_all_done, but didn't go quite far enough.

		* elf64-ia64-vms.c (elf64_vms_close_and_cleanup): Don't
		attempt to extend read-only files.
		* opncls.c (bfd_close_all_done): Always call _close_and_cleanup.

	An old bug in the ia64-vms support can be used to tickle another bug
	in bfd_close_all_done.  If _close_and_cleanup returns an error,

2023-08-21  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Fix make check-gas crash

2023-08-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-19  Tom Tromey  <tom@tromey.com>

	Placate -Wmissing-declarations in sim/cris
	I get a couple of -Wmissing-declarations errors when building the sim.
	This happens because an earlier patch added the declarations to a
	cgen-generated header, but the recent re-generation then removed them.

	This patch fixes the build by adding declarations just before the
	definition.  This is normally not best practice, but in this
	particular situation it at leat un-breaks the build.

2023-08-19  Tom Tromey  <tom@tromey.com>

	Remove extraneous '%' from sim/cris/local.mk
	I saw this warning from make:

	Makefile:5043: *** mixed implicit and normal rules: deprecated syntax

	I believe this snuck in by error with the recent cgen-related changes.

	This patch removes the stray '%' and rebuilds the Makefile.in.  I'm
	checking this in.

2023-08-19  Alan Modra  <amodra@gmail.com>

	sim regen
	This regenerates sim files.

	Tested with the following tools from a recent binutils build in
	sim-site-config.exp, plus a few cross compilers.

	set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc"
	set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new"
	set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new"
	set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc"
	set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new"
	set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new"
	set CC_FOR_TARGET_AVR ""
	set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new"
	set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new"
	set CC_FOR_TARGET_BFIN ""
	set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new"
	set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new"
	set CC_FOR_TARGET_BPF ""
	set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new"
	set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new"
	set CC_FOR_TARGET_CR16 ""
	set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new"
	set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new"
	set CC_FOR_TARGET_CRIS ""
	set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new"
	set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new"
	set CC_FOR_TARGET_D10V ""
	set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new"
	set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new"
	set CC_FOR_TARGET_FRV ""
	set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new"
	set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new"
	set CC_FOR_TARGET_FT32 ""
	set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new"
	set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new"
	set CC_FOR_TARGET_H8300 ""
	set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new"
	set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new"
	set CC_FOR_TARGET_IQ2000 ""
	set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_LM32 ""
	set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new"
	set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new"
	set CC_FOR_TARGET_M32C ""
	set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new"
	set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new"
	set CC_FOR_TARGET_M32R ""
	set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new"
	set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new"
	set CC_FOR_TARGET_M68HC11 ""
	set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new"
	set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new"
	set CC_FOR_TARGET_MCORE ""
	set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc"
	set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc"
	set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new"
	set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new"
	set CC_FOR_TARGET_MN10300 ""
	set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new"
	set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new"
	set CC_FOR_TARGET_MOXIE ""
	set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new"
	set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new"
	set CC_FOR_TARGET_MSP430 ""
	set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_OR1K ""
	set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new"
	set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new"
	set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc"
	set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new"
	set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new"
	set CC_FOR_TARGET_PRU ""
	set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new"
	set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new"
	set CC_FOR_TARGET_RISCV ""
	set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new"
	set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new"
	set CC_FOR_TARGET_RL78 ""
	set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new"
	set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new"
	set CC_FOR_TARGET_RX ""
	set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new"
	set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new"
	set CC_FOR_TARGET_SH ""
	set AS_FOR_TARGET_ERC32 ""
	set LD_FOR_TARGET_ERC32 ""
	set CC_FOR_TARGET_ERC32 ""
	set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new"
	set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new"
	set CC_FOR_TARGET_V850 ""

	Results both before and after were:
	FAIL: crisv10 mem1.ms (execution)
	FAIL: crisv10 mem2.ms (execution)
	FAIL: crisv32 mem1.ms (execution)
	FAIL: crisv32 mem2.ms (execution)
	FAIL: microblaze fail.s (execution)
	FAIL: microblaze pass.s (execution)
	expected passes            5288
	unexpected failures        6
	expected failures          3
	untested testcases         373
	unsupported tests          14

2023-08-19  Alan Modra  <amodra@gmail.com>

	sim regen preparation
	Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
	generated file, so this patch move those declarations to
	sim/lm32/sim-main.h.

2023-08-19  Alan Modra  <amodra@gmail.com>

	sim --enable-cgen-maint
	I had reason yesterday to want to regenerate configury files which I
	do with --enable-maintainer-mode, and added --enable-cgen-maint
	accidentally.  The first problem I hit is that sim looks for cgen in a
	different directory by default than opcodes, and I had my source
	layout set up for opcodes rather than sim.  Fix that by making both
	use ../cgen first, then ../../cgen relative to sim/ and opcodes/.  The
	next problem was that various sim local.mk files expected generated
	sources in the build dir rather than the source dir.  Fix that by
	adding $(srcdir) to paths.  Finally, the generated iq2000 files had a
	compile error, fixed by the cpu/iq2000.cpu patch.

	cpu/
		* iq2000.cpu (syscall): Add pc arg.
	opcodes/
		* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
		if found there.
		* configure: Regenerate.
	sim/m4/
		* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
	sim/
		* cris/local.mk: Add $(srcdir) to paths for regenerated source.
		* frv/local.mk: Likewise.
		* iq2000/local.mk: Likewise.
		* lm32/local.mk: Likewise.
		* m32r/local.mk: Likewise.
		* or1k/local.mk: Likewise.
		* Makefile.in: Regenerate.
		* configure: Regenerate.

2023-08-19  Alan Modra  <amodra@gmail.com>

	sim prune_warnings
	Remove some of the warnings generated by newer versions of ld.

		* testsuite/lib/sim-defs.exp (prune_warnings_extra): New.
		Arrange to run it from prune_warnings.

2023-08-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-18  Tom Tromey  <tromey@adacore.com>

	Fix off-by-one in call to vector::reserve
	While looking at a bug, I noticed what I think is an off-by-one
	mistake in a call to vector::reserve.  This code:

	      new_args.reserve (args.size ());
	      new_args.push_back
		(value_from_pointer (lookup_pointer_type (values_type), struct_addr));
	      new_args.insert (new_args.end (), args.begin (), args.end ());

	... reserves 'size()' entries, but then proceeds to push one extra
	one.

	This shouldn't have any really bad effects, as insert will grow the
	vector.  Still, it seems better to use the correct size if we're going
	to bother calling reserve.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-18  Tom Tromey  <tromey@adacore.com>

	Merge psympriv.h into psymtab.h
	psympriv.h was intended for use by code that created partial symbols.
	Now that no generic code needs psymtab.h any more, psympriv.h can be
	merged into psymtab.h.

	Remove most includes of psymtab.h
	I found that most spots including psymtab.h do not need it.  This
	patch removes these includes, and also one unnecessary include of
	psympriv.h.

2023-08-18  Jan Beulich  <jbeulich@suse.com>

	x86: remove indirection from bx[] and di_si[]
	The longest register name is 3 characters (plus a nul one), so using a
	4- or 8-byte pointer to get at it is neither space nor time efficient.
	Embed the names right into the array. For PIE this also slightly reduces
	the number of base relocations in the final image.

	gas: make S_IS_LOCAL() and S_IS_EXTERNAL() exclusive of one another
	While they aren't opposites of each other, there also shouldn't be any
	symbol for which both return true; both may return false. Therefore
	use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check
	which so far both did alike.

2023-08-18  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Report "c or zca" for INSN_CLASS_C when error reporting.
	bfd/
		* elfxx-riscv.c (riscv_multi_subset_supports_ext): Return "c or zca"
		rather than "c".

2023-08-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-18  Tom Tromey  <tom@tromey.com>

	C++-ify minidebug.c
	I noticed minidebug.c was still using explicit malloc and free, where
	a vector would be more automatic.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Use execvp instead of execv
	gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui)
	can be installed in a different directory.
	In this case, $PATH is used to look up gp-display-text.
	execv() does not use $PATH to find the executable.

	gprofng/ChangeLog
	2023-08-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/gp-display-text.cc (reexec): Use execvp instead of execv.

2023-08-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: add inferior-specific breakpoints
	This commit extends the breakpoint mechanism to allow for inferior
	specific breakpoints (but not watchpoints in this commit).

	As GDB gains better support for multiple connections, and so for
	running multiple (possibly unrelated) inferiors, then it is not hard
	to imagine that a user might wish to create breakpoints that apply to
	any thread in a single inferior.  To achieve this currently, the user
	would need to create a condition possibly making use of the $_inferior
	convenience variable, which, though functional, isn't the most user
	friendly.

	This commit adds a new 'inferior' keyword that allows for the creation
	of inferior specific breakpoints.

	Inferior specific breakpoints are automatically deleted when the
	associated inferior is removed from GDB, this is similar to how
	thread-specific breakpoints are deleted when the associated thread is
	deleted.

	Watchpoints are already per-program-space, which in most cases mean
	watchpoints are already inferior specific.  There is a small window
	where inferior-specific watchpoints might make sense, which is after a
	vfork, when two processes are sharing the same address space.
	However, I'm leaving that as an exercise for another day.  For now,
	attempting to use the inferior keyword with a watchpoint will give an
	error, like this:

	  (gdb) watch a8 inferior 1
	  Cannot use 'inferior' keyword with watchpoints

	A final note on the implementation: currently, inferior specific
	breakpoints, like thread-specific breakpoints, are inserted into every
	inferior, GDB then checks once the inferior stops if we are in the
	correct thread or inferior, and resumes automatically if we stopped in
	the wrong thread/inferior.

	An obvious optimisation here is to only insert breakpoint locations
	into the specific program space (which mostly means inferior) that
	contains either the inferior or thread we are interested in.  This
	would reduce the number times GDB has to stop and then resume again in
	a multi-inferior setup.

	I have a series on the mailing list[1] that implements this
	optimisation for thread-specific breakpoints.  Once this series has
	landed I'll update that series to also handle inferior specific
	breakpoints in the same way.  For now, inferior specific breakpoints
	are just slightly less optimal, but this is no different to
	thread-specific breakpoints in a multi-inferior debug session, so I
	don't see this as a huge problem.

	[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix yysymbol_kind_t odr violation
	When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
	run into:
	...
	ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
	  Definition Rule [-Wodr]
	c-exp.c.tmp:398: note: an enum with different value name is defined in \
	  another translation unit
	ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
	  'YYSYMBOL_COMPLEX_INT' defined in another translation unit
	c-exp.c.tmp:405: note: mismatching definition
	...

	Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
	files.

	Tested on x86_64-linux.

	PR build/22395
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

2023-08-17  Alan Modra  <amodra@gmail.com>

	generated bfd files, and kvx regen
	The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are
	different to the other similar generated files, and that reminded me
	that we need to have $srcdir in the generated #line reference back to
	the source for debugging, but don't want it for comments in bfd.pot
	(because then bfd.pot will likely reference Nick's source tree).
	This patch fixes that by making all the #line use $srcdir by virtue of
	using $<, and edits bfd.pot.

	I also uniq list of files to remove duplicated elfxx-x86.c, sort lists
	of files and regen with our standard automake/autoconf.

		* configure: Regenerate.
	bfd/
		* Makefile.am: Sort various lists of files.  Use $< in #line
		directive of generated C files.
		(po/SRC-POTFILES.in): uniq SRC_POTFILES.
		(po/BLD-POTFILES.in): uniq BFD_POTFILES.
		* Makefile.in: Regenerate.
		* po/Make-in (bfd.pot): Edit out source dir from comments.
		* po/SRC-POTFILES.in: Regenerate.
	gas/
		* Makefile.in: Regenerate.
		* configure: Regenerate.
		* po/POTFILES.in: Regenerate.
	ld/
		* Makefile.am (ALL_64_EMULATION_SOURCES): Sort.
		* Makefile.in: Regenerate.

2023-08-17  Alan Modra  <amodra@gmail.com>

	Re: sim frv: Add a missing return value for frvbf_check_acc_range.
	Commit f00b50d057 went the wrong way.  As the comment says this
	function is only applicable to fr550.  If not fr550 return 1,
	meaning we don't have acc restrictions.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Handle deprecated std::allocator::construct
	When building gdb with -std=c++20, I run into:
	...
	gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \
	  declared in ‘class std::allocator<unsigned char>’
	   52 |   using A::construct;
	      |            ^~~~~~~~~
	...

	Indeed, std::allocator::construct has been deprecated in c++17 and removed in
	c++20.

	Fix this by using instead std::pmr::polymorphic_allocator for c++20.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Return const reference in target_read_auxv
	In target_read_auxv we return a copy of an object:
	...
	gdb::optional<gdb::byte_vector>
	target_read_auxv ()
	{
	  ...
	  return info->data;
	}
	...

	Return a const reference instead, saving a copy.

	This is exposed by using std::pmr::polymorphic_allocator instead of
	std::allocator in default_init_allocator.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix invalid conversion in test_symbols
	When building gdb with -std=c++20, I run into:
	...
	gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \
	  ‘const char*’ [-fpermissive]
	 2709 |   u8"u8função",
	      |   ^~~~~~~~~~~~
	      |   |
	      |   const char8_t*
	...

	Fix this by making the conversion explicit.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix deprecated implicit capture of this
	When building gdb with -std=c++20 I run into:
	...
	gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \
	  deprecated in C++20 [-Werror=deprecated]
	10713 |   auto do_op = [=] (LONGEST x, LONGEST y)
	      |                ^
	gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture
	...

	Fix this by using "[this]".

	Likewise in two more spots.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix DISABLE_COPY_AND_ASSIGN use in ui_out_emit_type
	When building gdb with -std=c++20, I run into:
	...
	include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’
	  342 |   TYPE (const TYPE&) = delete;                  \
	      |         ^~~~~
	gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
	  412 |   DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>);
	      |   ^~~~~~~~~~~~~~~~~~~~~~~
	...

	Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)".

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Stop using deprecated is_pod
	When building gdb with clang 15 and -std=c++20, I run into:
	...
	gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \
	  is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations]
	            std::is_pod<T>>
	                 ^
	...

	Fix this by following the suggestion.

	Likewise in gdb/unittests/ptid-selftests.c.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/build, c++20] Fix Wdeprecated-enum-enum-conversion
	When building gdb with clang 15 and -std=c++20, I run into:
	...
	gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \
	  enumeration types ('const enum return_reason' and 'const enum errors') is \
	  deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
	    size_t result = exc.reason + exc.error;
	                    ~~~~~~~~~~ ^ ~~~~~~~~~
	...

	Fix this by using to_underlying.

	Likewise in a few other places.

	Tested on x86_64-linux.

2023-08-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix copy-to-remote in gdb.base/vfork-follow-parent.exp
	When running test-case gdb.base/vfork-follow-parent.exp, I run into:
	...
	ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
	ERROR: error copying "vforked-prog": no such file or directory
	    while executing
	"file copy -force $fromfile $tofile"
	    (procedure "gdb_remote_download" line 29)
	    invoked from within
	"gdb_remote_download target $binfile3"
	...

	Fix this by:
	- making the copy-to-remote conditional on is_remote target, and
	- allowing gdb_remote_download to find $binfile3 by using
	  standard_output_file.

	Also remove unused variable remote_exec_prog.

	Tested on x86_64-linux.

2023-08-17  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: tc-sparc.c: undo spurious change in 5be1b787276d2adbe85ae7febc709ca517b62f08

2023-08-17  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: consolidate handling of immediate overflows
	This commit changes the BPF GAS port in order to handle immediate
	overflows the same way than the clang BPF assembler:

	- For an immediate field of N bits, any written number (positive or
	  negative) whose two's complement encoding fit in N its is accepted.
	  This means that -2 is the same than 0xffffffe.  It is up to the
	  instructions to decide how to interpret the encoded value.

	- Immediate fields in jump instructions are no longer relaxed.
	  Relaxing to jump instructions with wider range is only performed
	  when expressions are involved.

	- The manual is updated to document this, and testsuite adapted
	  accordingly.

	Tested in x86_64-linux-gnu host, bpf-unknown-none target.

	gas/ChangeLog:

	2023-08-17  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* config/tc-bpf.c (check_immediate_overflow): New function.
		(encode_insn): Use check_immediate_overflow.
		(md_assemble): Do not relax instructions with
		constant disp16 fields.
		* doc/c-bpf.texi (BPF Instructions): Add note about how numerical
		literal values are interpreted for instruction immediate operands.
		* testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly.
		* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
		* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
		* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
		* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
		* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
		* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
		* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
		* testsuite/gas/bpf/imm32-overflow.s: Likewise.
		* testsuite/gas/bpf/disp32-overflow.s: Likewise.
		* testsuite/gas/bpf/disp16-overflow.l: Likewise.
		* testsuite/gas/bpf/disp32-overflow.l: Likewise.
		* testsuite/gas/bpf/imm32-overflow.l: Likewise.
		* testsuite/gas/bpf/offset16-overflow.l: Likewise.

2023-08-17  Sam James  <sam@gentoo.org>

	ld: ld-lib.exp: log failed dump.out contents for debugging
	If we're using dump_prog in a test which fails, log the dump.out contents
	to ld.log to aid debugging.

	This avoids needing to ask reporters to manually run e.g. `objdump` commands
	when making bug reports.

	PR30722
		* ld/testsuite/lib/ld-lib.exp: Log failed dump.out contents to aid
		debugging.

	Approved-by: Nick Clifton <nickc@redhat.com>

2023-08-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-16  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle self-reference DIE
	While working on a dwarf assembly test-case I accidentally created the
	following pathological dwarf:
	...
	 <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
	    <bf>   DW_AT_name        : c1
	    <c2>   DW_AT_specification: <0xbe>
	...
	and noticed gdb segfaulting during cooked index creating due to running out of
	stack.  This is a regression from gdb-12, where gdb just hung.

	Fix this by inhibiting the scan_attributes self-recursion for self-references.

	The same test-case with -readnow makes gdb hang, so also fix this in
	dwarf2_attr and follow_die_ref.

	Note that this doesn't fix the same problems for the more complicated case of:
	...
	 <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
	    <bf>   DW_AT_name        : c1
	    <c2>   DW_AT_specification: <0xc6>
	 <1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
	    <c7>   DW_AT_name        : c2
	    <ca>   DW_AT_specification: <0xbe>
	...
	but the approach for deciding whether to fix pathological dwarf cases is as
	per PR27981 comment 3:
	...
	yes if it is cheap/obvious, and no if it is something complicated or expensive.
	...
	and at this point I'm not sure whether fixing this will fall in the first
	category.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-16  Tom Tromey  <tromey@adacore.com>

	Avoid buffer overflow in ada_decode
	A bug report pointed out a buffer overflow in ada_decode, which Keith
	helpfully analyzed.  ada_decode had a logic error when the input was
	all digits.  While this isn't valid -- and would probably only appear
	in fuzzer tests -- it still should be handled properly.

	This patch adds a missing bounds check.  Tested with the self-tests in
	an asan build.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639
	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-08-16  Tom Tromey  <tromey@adacore.com>

	Fix obvious bug in aggregate expression
	I found an obvious bug in Ada aggregate expression handling:

		  if (vvo != nullptr)
	 	    error (_("Invalid record component association."));
	 	  name = vvo->get_symbol ()->natural_name ();

	Here the code errors when vvo is not null -- and then proceeds to use
	vvo.

	This hasn't caused a crash because, I believe, there's currently no
	way to reach this code in the null case.  However, I'm not really
	willing to assert this...

	Fixing this shows another bug, which is that due to the way the parser
	works, a field name in an aggregate expression might erroneously be
	fully qualified if some global variable with the same base name
	exists.

	The included test case triggers both bugs.  Note that the test
	includes a confounding case for array aggregates as well, but as these
	are harder to fix, I've left it as kfail.

	As this is Ada-specific, and has already been tested internally at
	AdaCore, I am checking it in.

2023-08-16  Tom Tromey  <tromey@adacore.com>

	Implement DAP module-removed event
	DAP specifies an event that should be sent when a module is removed.
	This patch implements this.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2023-08-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp
	I ran into a test failure on gdb.python/py-thread-exited.c.  The test
	creates two threads and then catches the thread exits in Python.  The
	test expects the threads to exit in a specific order.

	As the test is currently written, it is _likely_, but not guaranteed,
	that the threads will exit in the same order they are created, which
	is what the test expects.

	When running on a loaded system I ran into a case where the threads
	exited in the reverse creation order, which caused the test to fail.

	I could fix this by having the .exp file not care about the thread
	order, or by changing the C file to force the order. I chose the
	later, and added a pthread_barrier_t to ensure the threads exit in the
	correct order.

	There should be no change in what is tested after this commit.

2023-08-16  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix vfork regressions when target-non-stop is off
	It was pointed out on the mailing list[1] that after this commit:

	  commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
	  Date:   Wed Jun 21 14:18:54 2023 +0100

	      gdb: don't resume vfork parent while child is still running

	the test gdb.base/vfork-follow-parent.exp now has some failures when
	run with the native-gdbserver or native-extended-gdbserver boards:

	  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
	  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
	  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
	  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)

	The reason that these failures don't show up when run on the standard
	unix board is that the test is only run in the default operating mode,
	so for Linux this will be all-stop on top of non-stop.

	If we adjust the test script so that it runs in the default mode and
	with target-non-stop turned off, then we see the same failures on the
	unix board.  This commit includes this change.

	The way that the test is written means that it is not (currently)
	possible to turn on non-stop mode and have the test still work, so
	this commit does not do that.

	I have also updated the test script so that the vfork child performs
	an exec as well as the current exit.  Exec and exit are the two ways
	in which a vfork child can release the vfork parent, so testing both
	of these cases is useful I think.

	In this test the inferior performs a vfork and the vfork-child
	immediately exits.  The vfork-parent will wait for the vfork-child and
	then blocks waiting for gdb.  Once gdb has released the vfork-parent,
	the vfork-parent also exits.

	In the test that fails, GDB sets 'detach-on-fork off' and then runs to
	the vfork.  At this point the test tries to just "continue", but this
	fails as the vfork-parent is still selected, and the parent can't
	continue until the vfork-child completes.  As the vfork-child is
	stopped by GDB the parent will never stop once resumed, so GDB refuses
	to resume it.

	The test script then sets 'schedule-multiple on' and once again
	continues.  This time GDB, in theory, resumes both the parent and the
	child, the parent will be held blocked by the kernel, but the child
	will run until it exits, and which point GDB stops again, this time
	with inferior 2, the newly exited vfork-child, selected.

	What happens after this in the test script is irrelevant as far as
	this failure is concerned.

	To understand why the test started failing we should consider the
	behaviour of four different cases:

	  1. All-stop-on-non-stop before commit b1e0126ec56e,

	  2. All-stop-on-non-stop after commit b1e0126ec56e,

	  3. All-stop-on-all-stop before commit b1e0126ec56e, and

	  4. All-stop-on-all-stop after commit b1e0126ec56e.

	Only case #4 is failing after commit b1e0126ec56e, but I think the
	other cases are interesting because, (a) they inform how we might fix
	the regression, and (b) it turns out the behaviour of #2 changed too
	with the commit, but the change was harmless.

	For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
	is:

	  1. GDB calls proceed with the vfork-parent selected, as schedule
	     multiple is on user_visible_resume_ptid returns -1 (everything)
	     as the resume_ptid (see proceed function),

	  2. As this is all-stop-on-non-stop, every thread is resumed
	    individually, so GDB tries to resume both the vfork-parent and the
	    vfork-child, both of which succeed,

	  3. The vfork-parent is held stopped by the kernel,

	  4. The vfork-child completes (exits) at which point the GDB sees the
	     EXITED event for the vfork-child and the VFORK_DONE event for the
	     vfork-parent,

	  5. At this point we might take two paths depending on which event
	     GDB handles first, if GDB handles the VFORK_DONE first then:

	     (a) As GDB is controlling both parent and child the VFORK_DONE is
	         ignored (see handle_vfork_done), the vfork-parent will be
		 resumed,

	     (b) GDB processes the EXITED event, selects the (now defunct)
	         vfork-child, and stops, returning control to the user.

	     Alternatively, if GDB selects the EXITED event first then:

	     (c) GDB processes the EXITED event, selects the (now defunct)
	         vfork-child, and stops, returning control to the user.

	     (d) At some future time the user resumes the vfork-parent, at
	         which point the VFORK_DONE is reported to GDB, however, GDB
		 is ignoring the VFORK_DONE (see handle_vfork_done), so the
		 parent is resumed.

	For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
	important difference is in step (2) above, now, instead of resuming
	both the vfork-parent and the vfork-child, only the vfork-child is
	resumed.  As such, when we get to step (5), only a single event, the
	EXITED event is reported.

	GDB handles the EXITED just as in (5)(c), then, later, when the user
	resumes the vfork-parent, the VFORKED_DONE is immediately delivered
	from the kernel, but this is ignored just as in (5)(d), and so,
	though the pattern of when the vfork-parent is resumed changes, the
	overall pattern of which events are reported and when, doesn't
	actually change.  In fact, by not resuming the vfork-parent, the order
	of events (in this test) is now deterministic, which (maybe?) is a
	good thing.

	If we now consider case #3, all-stop-on-all-stop before commit
	b1e0126ec56e, then what happens is:

	  1. GDB calls proceed with the vfork-parent selected, as schedule
	     multiple is on user_visible_resume_ptid returns -1 (everything)
	     as the resume_ptid (see proceed function),

	  2. As this is all-stop-on-all-stop, the resume is passed down to the
	     linux-nat target, the vfork-parent is the event thread, while the
	     vfork-child is a sibling of the event thread,

	  3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
	     for all threads, this causes the vfork-child to be resumed.  Then
	     in linux_nat_target::resume, the event thread, the vfork-parent,
	     is also resumed.

	  4. The vfork-parent is held stopped by the kernel,

	  5. The vfork-child completes (exits) at which point the GDB sees the
	     EXITED event for the vfork-child and the VFORK_DONE event for the
	     vfork-parent,

	  6. We are now in a situation identical to step (5) as for
	     all-stop-on-non-stop above, GDB selects one of the events to
	     handle, and whichever we select the user sees the correct
	     behaviour.

	And so, finally, we can consider #4, all-stop-on-all-stop after commit
	b1e0126ec56e, this is the case that started failing.

	We start out just like above, in proceed, the resume_ptid is
	-1 (resume everything), due to schedule multiple being on.  And just
	like above, due to the target being all-stop, we call
	proceed_resume_thread_checked just once, for the current thread,
	which, remember, is the vfork-parent thread.

	The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
	thread, read the commit message for the justification for this change.

	However, this means that GDB now rejects resuming the vfork-parent in
	this case, which means that nothing gets resumed!  Obviously, if
	nothing resumes, then nothing will ever stop, and so GDB appears to
	hang.

	I considered a couple of solutions which, in the end, I didn't go
	with, these were:

	  1. Move the vfork-parent check out of proceed_resume_thread_checked,
	     and place it in proceed, but only on the all-stop-on-non-stop
	     path, this should still address the issue seen in b1e0126ec56e,
	     but would avoid the issue seen here.  I rejected this just
	     because it didn't feel great to split the checks that exist in
	     proceed_resume_thread_checked like this,

	  2. Extend the condition in proceed_resume_thread_checked by adding a
	     target_is_non_stop_p check.  This would have the same effect as
	     idea 1, but leaves all the checks in the same place, which I
	     think would be better, but this still just didn't feel right to
	     me, and so,

	What I noticed was that for the all-stop-on-non-stop, after commit
	b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
	The vfork-parent isn't going to run anyway (the kernel will hold it
	back), so if feels like we there's no harm in just waiting for the
	child to complete, and then resuming the parent.

	So then I started looking at follow_fork, which is called from the top
	of proceed.  This function already has the task of switching between
	the parent and child based on which the user wishes to follow.  So, I
	wondered, could we use this to switch to the vfork-child in the case
	that we are attached to both?

	Turns out this is pretty simple to do.

	Having done that, now the process is for all-stop-on-all-stop after
	commit b1e0126ec56e, and with this new fix is:

	  1. GDB calls proceed with the vfork-parent selected, but,

	  2. In follow_fork, and follow_fork_inferior, GDB switches the
	     selected thread to be that of the vfork-child,

	  3. Back in proceed user_visible_resume_ptid returns -1 (everything)
	     as the resume_ptid still, but now,

	  4. When GDB calls proceed_resume_thread_checked, the vfork-child is
	     the current selected thread, this is not a vfork-parent, and so
	     GDB allows the proceed to continue to the linux-nat target,

	  5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
	     for all threads, this does not resume the vfork-parent (because
	     it is a vfork-parent), and then the vfork-child is resumed as
	     this is the event thread,

	At this point we are back in the same situation as for
	all-stop-on-non-stop after commit b1e0126ec56e, that is, the
	vfork-child is resumed, while the vfork-parent is held stopped by
	GDB.

	Eventually the vfork-child will exit or exec, at which point the
	vfork-parent will be resumed.

	[1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/

2023-08-16  Paul Iannetta  <piannetta@kalrayinc.com>

	kvx: New port.

2023-08-16  Richard Ball  <richard.ball@arm.com>

	aarch64: Enable Cortex-A720 CPU
	This patch adds support for the Cortex-A720 CPU to binutils.

	bfd/ChangeLog:

		* cpu-aarch64.c: Add Cortex-A720.

	gas/ChangeLog:

		* NEWS: Update docs.
		* config/tc-aarch64.c: Add Cortex-A720.
		* doc/c-aarch64.texi: Update docs.
		* testsuite/gas/aarch64/cpu-cortex-a720.d: New test.

2023-08-16  Puputti, Matti  <matti.puputti@intel.com>

	gdb, infcmd: support jump command in multi-inferior case
	Fixes the issue where jump failed if multiple inferiors run the same
	source.

	See the below example

	    $ gdb -q ./simple
	    Reading symbols from ./simple...
	    (gdb) break 2
	    Breakpoint 1 at 0x114e: file simple.c, line 2.
	    (gdb) run
	    Starting program: /temp/simple

	    Breakpoint 1, main () at simple.c:2
	    2         int a = 42;
	    (gdb) add-inferior
	    [New inferior 2]
	    Added inferior 2 on connection 1 (native)
	    (gdb) inferior 2
	    [Switching to inferior 2 [<null>] (<noexec>)]
	    (gdb) info inferiors
	      Num  Description       Connection           Executable
	      1    process 6250      1 (native)           /temp/simple
	    * 2    <null>            1 (native)
	    (gdb) file ./simple
	    Reading symbols from ./simple...
	    (gdb) run
	    Starting program: /temp/simple

	    Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
	    2         int a = 42;
	    (gdb) info inferiors
	      Num  Description       Connection           Executable
	      1    process 6250      1 (native)           /temp/simple
	    * 2    process 6705      1 (native)           /temp/simple
	    (gdb) jump 3
	    Unreasonable jump request
	    (gdb)

	In this example, jump fails because the debugger finds two different
	locations, one for each inferior.

	Solution is to limit the search to the current program space.

	This is done by having the jump_command function use
	decode_line_with_current_source rather than
	decode_line_with_last_displayed, which makes sense,
	the *_current_source function always looks up a location based on the
	current thread's location -- if a user is asking the current thread to
	jump, then surely their destination should be relative to where the
	current thread is located.

	Then, inside decode_line_with_current_source, the call to
	decode_line_1 is updated to pass through the current program_space,
	which will limit the returned locations to those in the current
	program space.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-08-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-15  Tom Tromey  <tromey@adacore.com>

	Mention process_stratum in inferior::priv comment
	From what I can tell, inferior::priv is reserved for the
	process_stratum target.  It seems to me that it has to be, because
	currenlty only such targets use it, and if a target at another stratum
	started using this field, then conflicts could occur.  This patch
	documents this.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-15  Nick Clifton  <nickc@redhat.com>

	Updated Russian translation for the bfd directory

2023-08-15  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Make T-Head testing pattern more generic
	On some T-Head vendor extensions, we test against the constant
	18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
	However, it heavily depends on the fact that the value used to print
	immediate value is a 64-bit unsigned type and this constant is not (and
	should not be) important (we just want to know that -1 is not valid).

	This commit replaces all such occurrences of 18446744073709551615 with
	a more generic regular expression.

	gas/ChangeLog:

		* testsuite/gas/riscv/x-thead-ba-fail.l: Replace
		18446744073709551615 with generic regular expression.
		* testsuite/gas/riscv/x-thead-bb-fail.l: Likewise.
		* testsuite/gas/riscv/x-thead-bs-fail.l: Likewise.
		* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise.
		* testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise.
		* testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise.

2023-08-15  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa'
	The documentation of the 'Zfa' extension states that "fli.h" is available
	"if the Zfh or Zvfh extension is implemented" (both the latest and the
	oldest editions are checked).

	This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
	'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
	This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
	extensions are implemented.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add new
		instruction class handling.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zfa-zvfh.s: New test.
		* testsuite/gas/riscv/zfa-zvfh.d: Ditto.

	include/ChangeLog:

		* opcode/riscv.h (enum riscv_insn_class): Add new instruction
		class.

	opcodes/ChangeLog:

		* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
		from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.

2023-08-15  Tsukasa OI  <research_trasio@irq.a4lg.com>
	    Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Add support for the 'Zihintntl' extension
	This commit adds 'Zihintntl' extension and its hint instructions.

	This is based on:
	<https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
	the first ISA Manual noting that the 'Zihintntl' extension is ratified.

	Note that compressed 'Zihintntl' hints require either 'C' or
	'Zca' extension.


	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
		standard hint 'Z' extension.
		(riscv_multi_subset_supports): Support new instruction classes.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
		including auto-compression without C prefix and explicit C prefix.
		* testsuite/gas/riscv/zihintntl.d: Likewise.
		* testsuite/gas/riscv/zihintntl-na.d: Likewise.
		* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
		between 'Zihintntl' and base 'I' or 'C' instructions.
		* testsuite/gas/riscv/zihintntl-base.d: Likewise.

	include/ChangeLog:

		* opcode/riscv.h (enum riscv_insn_class): Add new instruction
		classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
		(MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
		MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
		MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
		MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
		MATCH_C_NTL_ALL): New.

	opcodes/ChangeLog:

		* riscv-opc.c (riscv_opcodes): Add instructions from the
		'Zihintntl' extension.

2023-08-15  Jan Beulich  <jbeulich@suse.com>

	RISC-V: remove indirection from register tables
	The longest register name is 4 characters (plus a nul one), so using a
	4- or 8-byte pointer to get at it is neither space nor time efficient.
	Embed the names right into the array. For PIE this also reduces the
	number of base relocations in the final image.

	To avoid old gcc, when generating 32-bit code, bogusly warning about
	bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
	an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
	a 64-bit value, and it also doesn't need to - all operand fields to
	date are far more narrow than 32 bits. This in turn allows dropping a
	number of casts elsewhere.

2023-08-15  Jan Beulich  <jbeulich@suse.com>

	PPC: remove indirection from struct pd_reg
	The longest register name is 5 characters (plus a nul one), so using a
	4- or 8-byte pointer to get at it is neither space nor time efficient.
	Embed the names right into the array. For PIE this also reduces the
	number of base relocations in the final image.

2023-08-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix YYSTYPE and yyalloc odr violation
	When building gdb with -O2 -flto I run into:
	...
	ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
	  Definition Rule [-Werror=odr]
	...

	Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.

	Likewise for yyalloc.

	Tested on x86_64-linux.  Also tested with byacc rather than bison on
	suggestion of Tom Tromey.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/22395
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Stop a process if it is running before killing it.
	In addition, detach from any child processes implicitly attached to by
	the kernel due to fork following that have not yet been processed by
	GDB's core.

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Fix thread_alive against a running thread.
	FreeBSD's ptrace fails requests with EBUSY against a running process.
	Report that the thread is alive instead of dead if ptrace fails with
	EBUSY.

	This fixes an internal error in the gdb.threads/detach-step-over.exp
	test where one process was detached while a thread in a second process
	was being stepped.  The core incorrectly assumed the stepping thread
	had vanished and discarded the pending stepping state.  When the
	thread later reported a SIGTRAP from completing the step, this
	triggered an assertion.

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Fix several issues with detaching.
	- Detach from any child processes implicitly attached to by the kernel
	  due to fork following that have not yet been processed by GDB's
	  core.

	- Delete breakpoints before detaching.

	  inf-ptrace::detach does not do this (somewhat surprisingly), so add
	  an override to remove breakpoints from a process before detaching
	  from it.

	  This also requires explicitly draining any pending SIGTRAP events
	  for software breakpoints before detaching.  In particular, threads
	  may need their PC adjusted due to the software breakpoint before
	  being resumed after detach.  On more modern systems using the si_code
	  from SIGTRAP to identify software breakpoint traps, the PC is adjusted
	  in ::wait_1 as a side effect of parsing the event.  To support older
	  kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential
	  new PC matches an existing software breakpoint.

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Fix resuming and waiting with multiple processes.
	I did not fully understand the requirements of multiple process
	support when I enabled it previously and several parts were broken.
	In particular, the resume method was only resuming a single process,
	and wait was not stopping other processes when reporting an event.

	To support multiple running inferiors, add a new per-inferior
	structure which trackes the number of existing and running LWPs for
	each process.  The structure also stores a ptid_t describing the
	set of LWPs currently resumed for each process.

	For the resume method, iterate over all non-exited inferiors resuming
	each process matching the passed in ptid rather than only resuming the
	current inferior's process for a wildcard ptid.  If a resumed process
	has a pending event, don't actually resume the process, but other
	matching processes without a pending event are still resumed in case
	the later call to the wait method requests an event from one of the
	processes without a pending event.

	For the wait method, stop other running processes before returning an
	event to the core.  When stopping a process, first check to see if an
	event is already pending.  If it is, queue the event to be reported
	later.  If not, send a SIGSTOP to the process and wait for it to stop.
	If the event reported by the wait is not for the SIGSTOP, queue the
	event and remember to ignore a future SIGSTOP event for the process.

	Note that, unlike the Linux native target, entire processes are
	stopped rather than individual LWPs.  In FreeBSD one can only wait on
	processes (via pid), not for an event from a specific thread.

	Other changes in this commit handle bookkeeping for the per-inferior
	data such as migrating the data to the new inferior in the follow_exec
	method.  The per-inferior data is created in the attach,
	create_inferior, and follow_fork methods.

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Defer any ineligible events reported by wait.
	If wait_1 finds an event for a thread or process that does not match
	the set of threads and processes previously resumed, defer the event.
	If the event is for a specific thread, suspend the thread and continue
	the associated process before waiting for another event.

	One specific example of such an event is if a thread is created while
	another thread in the same process hits a breakpoint.  If the second
	thread's event is reported first, the target resume method does not
	yet "know" about the new thread and will not suspend it via
	PT_SUSPEND.  When wait is called, it will probably return the event
	from the first thread before the result of the step from second
	thread.  This is the case reported in PR 21497.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21497

2023-08-14  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Add a list of pending events.
	The m_pending_events list stores a queue of deferred events that might
	be reported by the next call to the target's wait method.  The set of
	events that are eligible is filtered by the ptid passed to resume.

	For now this just replaces the list of vfork_done events.  A
	subsequent commit will reuse this to store other events.

2023-08-14  Tom Tromey  <tom@tromey.com>

	Remove alloca from osabi.c
	I noticed that the call to alloca in osabi.c can be replaced with a
	statically-sized buffer, because some code just before the declaration
	ensures that the length is bounded.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix struct token odr violation
	When building gdb with -O2 -flto I run into:
	...
	/data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
	  violates the C++ One Definition Rule [-Wodr]
	 struct token
	        ^
	/data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
	  another translation unit
	 struct token
	        ^
	...

	Fix this by renaming to c_token and d_token.

	Likewise in:
	- fortran-exp.y, renaming to f_token,
	- go-exp.y, renaming to go_token, and
	- p-exp.y, renaming to p_token.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/22395
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix struct token_and_value odr violation
	When build gdb with -O2 -flto I run into:
	...
	gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
	  One Definition Rule [-Wodr]
	 struct token_and_value
	        ^
	gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
	  unit
	 struct token_and_value
	        ^
	...

	Fix this by renaming to c_token_and_value and d_token_and_value.

	Likewise in gdb/go-exp.y, renaming to go_token_and_value.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/22395
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix enum param_types odr violation
	When building gdb with -O2 -flto, I run into:
	...
	gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
	  One Definition Rule [-Wodr]
	 enum param_types
	      ^
	gdb/python/py-param.c:33:6: note: an enum with different value name is \
	  defined in another translation unit
	 enum param_types
	      ^
	...

	Fix this by renaming to enum scm_param_types and py_param_types.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/22395
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c
	In gdb/python/py-param.c we have:
	...
	enum param_types
	{
	  ...
	}
	param_types;
	...
	which declares both an enum param_types, and an unused variable param_types.

	Fix this by removing the variable.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-14  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix maint print symbols/psymbols help text
	Consider the help text of "maint print symbols":
	...
	(gdb) help maint print symbols
	Print dump of current symbol definitions.
	Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
	       mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
	Entries in the full symbol table are dumped to file OUTFILE,
	or the terminal if OUTFILE is unspecified.
	If ADDRESS is provided, dump only the file for that address.
	If SOURCE is provided, dump only that file's symbols.
	If OBJFILE is provided, dump only that file's minimal symbols.
	...
	and "maint print psymbols":
	...
	(gdb) help maint print psymbols
	Print dump of current partial symbol definitions.
	Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
	       mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
	Entries in the partial symbol table are dumped to file OUTFILE,
	or the terminal if OUTFILE is unspecified.
	If ADDRESS is provided, dump only the file for that address.
	If SOURCE is provided, dump only that file's symbols.
	If OBJFILE is provided, dump only that file's minimal symbols.
	...

	The OBJFILE lines mistakingly mention minimal symbols.

	Fix this by reformulating as "dump only that object file's symbols".

	Also make the ADDRESS lines more clear by using the formulation: "dump only
	the symbols for the file with code at that address".

	Tested on x86_64-linux.

	Co-Authored-By: Eli Zaretskii <eliz@gnu.org>

	PR gdb/30742
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742

2023-08-14  H.J. Lu  <hjl.tools@gmail.com>

	ld: Build libpr23169a.so with -z lazy
	pr23169b test only works with lazy binding.  To work with linker which
	disables lazy binding by default, build pr23169b binaries with -z lazy.

		PR ld/30698
		* ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy.

2023-08-14  Alan Modra  <amodra@gmail.com>

	Remove fall-back prune_warnings
	No one should be using versions of dejagnu without prune_warnings,
	which was available in 1996 (dejagnu-1.3).

	binutils/
		* testsuite/lib/binutils-common.exp: Remove fallback prune_warnings.
	gas/
		* testsuite/lib/gas-defs.exp: Remove fallback prune_warnings.

2023-08-14  Alan Modra  <amodra@gmail.com>

	Re: PR30715, VAX: md_create_long_jump
	Tidy comment formatting.

2023-08-14  Sam James  <sam@gentoo.org>

	ld: fix relocatable, retain7a target pattens for HPPA
	Fix issue reported by Dave and Alan.

	Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
	Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
	before.

	ld/
		PR 30733
		PR 30734
		* ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
	          but include hppa1.1, hppa2.0.
		* ld/testsuite/ld-elf/retain7a.d: Ditto.

	Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49
	Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5

2023-08-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-13  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Don't deduplicate variables in gdb-index
	When running test-case gdb.python/py-symbol.exp with target board
	cc-with-gdb-index, we run into:
	...
	(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
	1^M
	(gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
	...

	[ Note that the test-case contains rr in both py-symtab.c:
	...
	static int __attribute__ ((used)) rr = 42;	/* line of rr */
	...
	and py-symtab-2.c:
	...
	static int __attribute__ ((used)) rr = 99;	/* line of other rr */
	... ]

	This passes with gdb-12-branch, and fails with gdb-13-branch.

	AFAIU the current code in symtab_index_entry::minimize makes the assumption
	that it's fine to store only one copy of rr in the gdb-index, because
	"print rr" will only ever print one, and always the same.

	But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
	returns a list of variables rather than the first one.

	In other words, the current approach breaks feature parity between cooked
	index and gdb-index.

	Note btw that also debug-names has both instances:
	...
	[  5] #00597969 rr:
	        <4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
	        <4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
	...

	Fix this in symtab_index_entry::minimize, by not deduplicating variables.

	Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

	PR symtab/30720
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720

2023-08-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: pass gprofng location to gp-display-gui
	gprofng GUI can be installed to the other directory.
	In this case, $PATH is used to find gp-display-gui from gprofng
	and option --gprofngdir is passed to gp-display-gui.

	gprofng/ChangeLog
	2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir.

2023-08-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix typos in get_realpath() and check_executable()
	gprofng/ChangeLog
	2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Application.cc (Application::get_realpath): Fix typo.
		* src/checks.cc (collect::check_executable): Likewise.

2023-08-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-13  Alan Modra  <amodra@gmail.com>

	Re: gdb: warn unused result for bfd IO functions
	Add a missing return statement.

2023-08-12  Kalvis Duckmanton  <kalvisd@gmail.com>

	PR30715, VAX: md_create_long_jump
		PR 30715
		* config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
		* testsuite/gas/vax/broken_word.d,
		* testsuite/gas/vax/broken_word.s: New test.
		* testsuite/gas/vax/vax.exp: Run it.

2023-08-12  Kevin Buettner  <kevinb@redhat.com>

	gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps
	At the moment, while performing a software single-step, gdbserver fails
	to reinsert software single-step breakpoints for a LWP when
	interrupted by a signal in another thread.  This commit fixes this
	problem by reinstalling software single-step breakpoints in
	linux_process_target::resume_stopped_resumed_lwps in
	gdbserver/linux-low.cc.

	This bug was discovered due to a failing assert in maybe_hw_step()
	in gdbserver/linux-low.cc.  Looking at the backtrace revealed
	that the caller was linux_process_target::resume_stopped_resumed_lwps.
	I was uncertain whether the assert should still be valid when called
	from that method, so I tried hoisting the assert from maybe_hw_step
	to all callers except resume_stopped_resumed_lwps.  But running the
	new test case, described below, showed that merely eliminating the
	assert for this case was NOT a good fix - a study of the log file for
	the test showed that the single-step operation failed to occur.
	Instead GDB (via gdbserver) stopped at the next breakpoint that was
	hit.

	Zhiyong Yan had proposed a fix which resinserted software single-step
	breakpoints, albeit at a different location in linux-low.cc.  Testing
	revealed that, while running gdb.threads/pending-fork-event-detach,
	the executable associated with that test would die due to a SIGTRAP
	after the test program was detached.  Examination of the core file(s)
	showed that a breakpoint instruction had been left in program memory.
	Test results were otherwise very good, so Zhiyong was definitely on
	the right track!

	This commit causes software single-step breakpoint(s) to be inserted
	before the call to maybe_hw_step in resume_stopped_resumed_lwps.  This
	will cause 'has_single_step_breakpoints (thread)' to be true, so that
	the assert in maybe_hw_step...

	      /* GDBserver must insert single-step breakpoint for software
		 single step.  */
	      gdb_assert (has_single_step_breakpoints (thread));

	...will no longer fail.  And better still, the single-step breakpoints
	are reinstalled, so that stepping will actually work, even when
	interrupted.

	The C code for the test case was loosely adapted from the reproducer
	provided in Zhiyong's bug report for this problem.  The .exp file was
	copied from next-fork-other-thread.exp and then tweaked slightly.  As
	noted in a comment in next-fork-exec-other-thread.exp, I had to remove
	"on" from the loop for non-stop as it was failing on all architectures
	(including x86-64) that I tested.  I have a feeling that it ought to
	work, but this can be investigated separately and (re)enabled once it
	works.  I also increased the number of iterations for the loop running
	the "next" commands.  I've had some test runs which don't show the bug
	until the loop counter exceeded 100 iterations.  The C file for the
	new test uses shorter delays than next-fork-other-thread.c though, so
	it doesn't take overly long (IMO) to run this new test.

	Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
	userland using a gdbserver build without the fix in this commit shows
	the following results:

	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here

			=== gdb Summary ===

	 # of unexpected core files	12
	 # of expected passes		3011
	 # of unexpected failures	14

	Each of the 12 core files were caused by the failed assertion in
	maybe_hw_step in linux-low.c.  These correspond to 12 of the
	unexpected failures.

	When the tests are run using a gdbserver build which includes the fix
	in this commit, the results are significantly better, but not perfect:

	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
	FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line

			=== gdb Summary ===

	 # of expected passes		10178
	 # of unexpected failures	2

	I think that the two remaining failures are due to some different
	problem.  They are also racy - I've seen runs with no failures or only
	one failure, but never more than two.  Also, those runs were conducted
	with the loop count in next-fork-exec-other-thread.exp set to 200.
	During his testing of this fix and the new test case, Luis Machado
	found that this test was taking a long time and asked about ways to
	speed it up.  I then conducted additional tests in which I gradually
	reduced the loop count, timing each one, also noting the number of
	failures.  With the loop count set to 30, I found that I could still
	reliably reproduce the failures that Zhiyong reported (in which, with
	the proper settings, core files are created).  But, with the loop
	count set to 30, the other failures noted above were much less likely
	to show up.  Anyone wishing to investigate those other failures should
	set the loop count back up to 200.

	Running the new test on x86-64 and aarch64, both native and
	native-gdbserver shows no failures.

	Also, I see no regressions when running the entire test suite for
	armv7l-unknown-linux-gnueabihf (i.e.  the Raspberry Pi w/ 32-bit
	kernel+userland) with --target_board=native-gdbserver.  Additionally,
	using --target_board=native-gdbserver, I also see no regressions for
	the entire test suite for x86-64 and aarch64 running Fedora 38.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
	Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
	Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2023-08-12  Alan Modra  <amodra@gmail.com>

	regen config
	This regenerates config files changed by the previous 44 commits.
	Note that subject lines in these commits mostly match the gcc git
	originating commit.

2023-08-12  Arsen Arsenović  <arsen@aarsen.me>

	toplevel: Substitute GDCFLAGS instead of using CFLAGS
	r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
	implemented this change, but only on the generated file rather than in
	the template it is generated from.

		* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
		$(CFLAGS).

2023-08-12  Andreas Schwab  <schwab@suse.de>

	Use substituted GDCFLAGS
	Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
	that the subdir configure scripts use the configured value.

		* configure.ac (GDCFLAGS): Set default from ${CFLAGS}.

2023-08-12  Philip Herron  <philip.herron@embecosm.com>

	gccrs: Add gcc-check-target check-rust
	This allows us to invoke the rust testsuite.

		* Makefile.def: Add Rust language.

2023-08-12  Roger Sayle  <roger@nextmovesoftware.com>

	PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def
	This patch fixes PR bootstrap/106472 by adding a missing dependency
	to Makefile.def to allow make bootstrap when configured using
	"--enable-languages=go" (and not using make with multiple threads).

	2022-07-31  Roger Sayle  <roger@nextmovesoftware.com>

		PR bootstrap/106472
		* Makefile.def (dependencies): Make configure-target-libgo depend
		upon all-target-libbacktrace.

2023-08-12  Thomas Schwinge  <thomas@codesourcery.com>

	Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]

2023-08-12  Eugene Rozenfeld  <erozen@microsoft.com>

	Disable warnings as errors for STAGEautofeedback.
	Compilation during STAGEautofeedback produces additional warnings
	since inlining decisions with -fauto-profile are different from
	other builds.

	This patches disables warnings as errors for STAGEautofeedback.

	Tested on x86_64-pc-linux-gnu.

		* Makefile.tpl: Disable warnings as errors for STAGEautofeedback

2023-08-12  Eugene Rozenfeld  <erozen@microsoft.com>

	Fix autoprofiledbootstrap build
		* Makefile.tpl: Define PROFILE_MERGER

2023-08-12  Eugene Rozenfeld  <erozen@microsoft.com>

	Fix collection and processing of autoprofile data for target libs
	cc1, cc1plus, and lto  built during STAGEautoprofile need to be built with
	debug info since they are used to build target libs. -gtoggle was
	turning off debug info for this stage.

	create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto
	instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when
	processing profile data collected while building target libraries.

	Tested on x86_64-pc-linux-gnu.

		* Makefile.tpl: Remove -gtoggle for STAGEautoprofile

2023-08-12  Eugene Rozenfeld  <erozen@microsoft.com>

	Collect both user and kernel events for autofdo tests and autoprofiledbootstrap
	When we collect just user events for autofdo with lbr we get some events where branch
	sources are kernel addresses and branch targets are user addresses. Without kernel MMAP
	events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if
	it can't map at least 95% of events. We sometimes get below this threshold with just
	user events. The change is to collect both user events and kernel events.

	Tested on x86_64-pc-linux-gnu.

		* Makefile.tpl: Collect both kernel and user events for autofdo

2023-08-12  Iain Buclaw  <ibuclaw@gdcproject.org>

	d: Import dmd b8384668f, druntime e6caaab9, phobos 5ab9ad256 (v2.098.0-beta.1)
	The D front-end is now itself written in D, in order to build GDC, you
	will need a working GDC compiler (GCC version 9.1 or later).

	GCC changes:

	    - Add support for bootstrapping the D front-end.

	These add the required components in order to have a D front-end written
	in D itself.  Because the compiler front-end only depends on the core
	runtime modules, only libdruntime is built for the bootstrap stages.

	D front-end changes:

	    - Import dmd v2.098.0-beta.1.

	Druntime changes:

	    - Import druntime v2.098.0-beta.1.

	Phobos changes:

	    - Import phobos v2.098.0-beta.1.

	The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of
	development on the D programming language and run-time libraries.

		* Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
		libatomic.
		* Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
		(STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
		target-libphobos-bootstrap.
		(STAGE2_CONFIGURE_FLAGS): Likewise.

2023-08-12  Sergei Trofimovich  <siarheit@google.com>

	Makefile.def: drop remnants of unused libelf
	Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR
	lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0.

	This change removes unused references to libelf from top-level configure
	and Makefile.

		* Makefile.def: Drop libelf module and gcc-configure dependency
		on it.
		* Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and
		LIBELFINC.

2023-08-12  Martin Liska  <mliska@suse.cz>

	Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin.
		PR gcov-profile/94570
		* ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
		for CYGWIN.

	Co-Authored-By: Jonathan Yong <10walls@gmail.com>

2023-08-12  Christophe Lyon  <christophe.lyon@st.com>

	FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
	In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
	libraries support is required, as uclinux does not guarantee that.

		* libtool.m4: Handle uclinuxfdpiceabi.

2023-08-12  Bernhard M. Wiedemann  <bwiedemann@suse.de>

	libtool.m4: Sort output of 'find' to enable deterministic builds.
	        * libtool.m4: Sort output of 'find' to enable deterministic builds.
		* ltmain.sh: Likewise.

2023-08-12  John David Anglin  <danglin@gcc.gnu.org>

	Fix hppa64-hpux11 build to remove source paths from embedded path.
	This change adds the +nodefaultrpath ld option to remove all library
	paths that were specified with the -L option from the embedded path.

		* libtool.m4 (archive_cmds): Add +nodefaultrpath ld option on
		hppa64-*-hpux11*.

2023-08-12  Olivier Hainque  <hainque@adacore.com>

	Generic configury support for shared libs on VxWorks
	This change adds the configury bits to activate the build of
	shared libs on VxWorks ports configured with --enable-shared,
	for libraries variants where this is generally supported (rtp,
	code model !large - currently not compatible with -fPIC).

	Set lt_cv_deplibs_check_method in libtool.m4, so the build of
	libraries know how to establish dependencies.  This is useful in
	configurations such as aarch64 where proper support of LSE relies
	on accurate dependency information between libstdc++ and libgcc_s
	to begin with.

		* libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker
		and friends for rtp !large. Assume the linker has the required
		abilities and set lt_cv_deplibs_check_method.

2023-08-12  Arsen Arsenović  <arsen@aarsen.me>

	toplevel: reconcile few divergences with GCC
		* configure.ac: Reorder include.
		<is_elf calculation>: Re-add haiku to ELF target list.

2023-08-12  Max Filippov  <jcmvbkbc@gmail.com>

	gcc: xtensa: add data alignment properties to dynconfig
	include/
		* xtensa-dynconfig.h (xtensa_config_v4): New struct.
		(XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION)
		(XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW)
		(XCHAL_UNALIGNED_STORE_HW, XTENSA_CONFIG_V4_ENTRY_LIST): New
		definitions.
		(XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v4 instance.
		(XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V4_ENTRY_LIST.

	gcc: xtensa: add XCHAL_HAVE_{CLAMPS, DEPBITS, EXCLUSIVE, XEA3} to dynconfig
	include/
		* xtensa-dynconfig.h (xtensa_config_v3): New struct.
		(xtensa_get_config_v3): New declaration.
		(XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS, XCHAL_HAVE_EXCLUSIVE)
		(XCHAL_HAVE_XEA3, XTENSA_CONFIG_V3_ENTRY_LIST): New definitions.
		(XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v3 instance.
		(XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V3_ENTRY_LIST.

2023-08-12  Jozef Lawrynowicz  <jozefl@gcc.gnu.org>

	MSP430: Add -fno-exceptions multilib
		* config-ml.in (msp430-*-*): Support --disable-no-exceptions configure
		flag.

2023-08-12  Iain Buclaw  <ibuclaw@gcc.gnu.org>

	Add D front-end, libphobos library, and D2 testsuite.
		* config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag
		environment variables.

	Cherry picked from GCC commit b4c522fabd0df7be08882d2207df8b2765026110

2023-08-12  Jonathan Wakely  <jwakely@redhat.com>

	config-ml.in: Suppress output from multi-do recipes
	The FIXME comments saying "Leave out until this is tested a bit more"
	are from 1997. I think they've been sufficiently tested.

		* config-ml.in (multi-do, multi-clean): Add @ to silence recipes.
		Remove FIXME comments.

2023-08-12  Sergei Trofimovich  <siarheit@google.com>

	mh-mingw: drop unused BOOT_CXXFLAGS variable
	gcc's build system has BOOT_CFLAGS and various STAGE<N>_C{,XX}FLAGS
	variables. BOOT_CXXFLAGS is not handled anywhere.

	config/
		* mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable.

2023-08-12  Martin Storsjö  <martin@martin.st>

	mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables
	This is similar to what was done in
	eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
	STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
	BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
	BOOT_CFLAGS).

	2021-04-09  Martin Storsjö  <martin@martin.st>

	config/
		* mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
		variables

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	configure: Allow host fragments to react to --enable-host-shared.
	This makes the host_shared value available to host makefile
	fragments.

	It uses this to adjust Darwin's mdynamic-no-pic in the case that
	shared host resources are required.


	config/
		* mh-darwin: Require a non-shared host configuration to
		enable  mdynamic-no-pic where that is supported.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	Darwin, config: Revise host config fragment.
	There were two uses for the Darwin host config fragment:

	The first is to arrange for targets that support mdynamic-no-pic
	to be built with that enabled (since it makes a significant
	difference to the compiler performance).  We can be more specific
	in the application of this, since it only applies to 32b hosts
	plus powerpc64-darwin9.

	The second was to work around a tool bug where -fno-PIE was not
	propagated to the link stage.  This second use is redundant,
	since the buggy toolchain cannot bootstrap current GCC sources
	anyway.

	This makes the host fragment more specific and reduces the number
	of toolchains for which it is included which reduces clutter in
	configure lines.


	config/
		* mh-darwin: Make this specific to handling the
		mdynamic-no-pic case.

2023-08-12  LIU Hao  <lh_mouse@126.com>

	gcc: Add 'mcf' thread model support from mcfgthread
	This patch adds the new thread model `mcf`, which implements mutexes
	and condition variables with the mcfgthread library.

	Source code for mcfgthread is available at <https://github.com/lhmouse/mcfgthread>.

	config/
		* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
		model

2023-08-12  Andrew Pinski  <apinski@marvell.com>

	Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken
	So the problem here is that now the lto-plugin requires NM that works
	with LTO to work so we need to pass down NM just like we do for ranlib
	and ar.

	config/
		* bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR.
		* bootstrap-lto.mk: Likewise.

2023-08-12  Martin Liska  <mliska@suse.cz>

	32-bit PA-RISC with HP-UX: remove deprecated ports
		* configure.ac: Drop GCC configury for hpux10
		* configure: Likewise.
	config/
		* mh-pa-hpux10: Drop.

2023-08-12  Gaius Mulley  <gaiusmod2@gmail.com>

	Merge modula-2 front end onto gcc.
	This commit merges the devel/modula2 into master.
	The libraries reside in libgm2, the compiler in gcc/m2
	and the testsuite in gcc/testsuite/gm2.

		* configure.ac (target_libraries): Add target-libgm2.
		Add NCN_STRICT_CHECK_TARGET_TOOLS entry for gm2.
		Add GCC_TARGET_TOOL entry for gm2.  (compare_exclusions)
		add gcc/m2/gm2-compiler/M2Version,
		gcc/m2/gm2-compiler-boot/SYSTEM and gcc/m2/gm2version.
		* Makefile.def (target_modules): Add libgm2.  (flags_to_pass)
		Add GM2_FOR_TARGET, GM2FLAGS_FOR_TARGET.  (dependencies) Add
		all-target-libgm2 and on=all-target-libatomic.  (languages)
		Add entry for language=m2 with gcc-check-target=check-m2
		and lib-check-target=check-target-libgm2.
		* Makefile.tpl (BUILD_EXPORTS): Add definition for GM2
		and GM2FLAGS.  (HOST_EXPORTS) Add definition for GM2.
		(BASE_TARGET_EXPORTS) Add definition for GM2.
		(GM2_FOR_BUILD) Defined.  (GM2FLAGS) Defined.
		(GM2_FOR_TARGET) Defined.  (GM2FLAGS_FOR_TARGET) Defined.
		(EXTRA_HOST_FLAGS) Defined.  (POSTSTAGE1_FLAGS_TO_PASS)
		Add GM2 and GM2_FOR_BUILD.  (EXTRA_TARGET_FLAGS) Add
		GM2 and GM2FLAGS.  (EXTRA_GCC_FLAGS) Add GM2_FOR_TARGET.

2023-08-12  Alexandre Oliva  <oliva@adacore.com>

	Add TFLAGS to gcc's GCC_FOR_TARGET
	When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for
	dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios.  This
	patch arranges for TFLAGS to be passed from the top level down to gcc
	in GCC_FOR_TARGET in this case.

		* Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET.
		(EXTRA_GCC_FLAGS): Likewise.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	configure: Account CXXFLAGS in gcc-plugin.m4.
	We now use a C++ compiler so that we need to process
	CXXFLAGS as well as CFLAGS in the gcc-plugin config
	fragment.


	config/
		* gcc-plugin.m4: Save and process CXXFLAGS.

2023-08-12  David Seifert  <soap@gentoo.org>

	configure: use OBJDUMP determined by libtool [PR95648]
	$ac_cv_prog_OBJDUMP contains the --host OBJDUMP that
	libtool has inferred. Current config/gcc-plugin.m4 does
	not respect the user's choice for OBJDUMP.

	config/
		* gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP.

2023-08-12  Thomas Schwinge  <thomas@codesourcery.com>

	Remove support for Intel MIC offloading
	... after its deprecation in GCC 12.

		* Makefile.def: Remove module 'liboffloadmic'.
		* configure.ac: Remove 'liboffloadmic' handling.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	configure, Darwin: Ensure overrides to host-pie are passed to gcc configure.
	The latest versions of Darwin on the Aarch64 platform mandate PIE executables.
	On x86_64 it remains optional, but produces tool warnings after Darwin20, so
	we default to PIE executables there too.

	All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force
	host_shared on (we issue a diagnostic if the user tries to configure them
	non-shared).

	However, this also means we cannot test the host_shared setting independently
	of the host_pie setting so that the logic for setting PICFLAG must be amended
	for Darwin.

	For Darwin versions required to have PIE executables, in the event that the
	user tries to configure these as --disable-host-pie, we issue a warning and
	override the setting.  These versions must also switch host_pie on even if it
	is not given in the configure line.  To cater for this we pass the current
	value of host_pie, as determined by top-level configure, to the GCC configure.


		* Makefile.def: Pass the enable-host-pie value to GCC configure.
		* configure.ac: Adjust the logic for shared and PIE host flags to
		ensure that PIE is passed for hosts that require it.

2023-08-12  Peter Foley  <pefoley2@pefoley.com>

	configure: Only create serdep.tmp if needed
	There's no reason to create this file if none of the serial configure
	options are passed.

		* configure.ac: Only create serdep.tmp if needed

2023-08-12  Marek Polacek  <polacek@redhat.com>

	configure: Implement --enable-host-pie
	This patch implements the --enable-host-pie configure option which
	makes the compiler executables PIE.  This can be used to enhance
	protection against ROP attacks, and can be viewed as part of a wider
	trend to harden binaries.

	Co-Authored by: Iain Sandoe  <iain@sandoe.co.uk>

		* configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
		check.

	intl/
		* configure.ac (--enable-host-shared): Don't set PICFLAG here.
		(--enable-host-pie): New check.  Set PICFLAG after this check.

	libdecnumber/
		* configure.ac (--enable-host-shared): Don't set PICFLAG here.
		(--enable-host-pie): New check.  Set PICFLAG after this check.

	zlib/
		* configure.ac (--enable-host-shared): Don't set PICFLAG here.
		(--enable-host-pie): New check.  Set PICFLAG after this check.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	configure: When host-shared, pass --with-pic to in-tree lib configs.
	If we are building PIC/PIE host executables, and we are building dependent
	libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code.


		* Makefile.def: Pass host_libs_picflag to host dependent library
		configures.
		* configure.ac (host_libs_picflag): New configure variable set to
		'--with-pic' when building 'host_shared'.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	configure: Do not build the ununsed libffi shared library.
	We do not use the shared libffi libraray, nor do we install it.
	However, on at least Darwin, the shared version will be picked
	up for testing, so it is preferrable not to build it.


		* Makefile.def: Do not build shared libffi.

2023-08-12  Iain Sandoe  <iain@sandoe.co.uk>

	Darwin : Update libtool and dependencies for Darwin20 [PR97865]
	The change in major version (and the increment from Darwin19 to 20)
	caused libtool tests to fail which resulted in incorrect build settings
	for shared libraries.

		PR target/97865
		* libtool.m4: Update handling of Darwin platform link flags
		for Darwin20.

2023-08-12  Xi Ruoyao  <xry111@xry111.site>

	LoongArch: implement count_{leading,trailing}_zeros
	LoongArch always support clz and ctz instructions, so we can always use
	__builtin_{clz,ctz} for count_{leading,trailing}_zeros.  This improves
	the code of libgcc, and also benefits Glibc once we merge longlong.h
	there.

	Bootstrapped and regtested on loongarch64-linux-gnu.

	include/
		* longlong.h [__loongarch__] (count_leading_zeros): Define.
		[__loongarch__] (count_trailing_zeros): Likewise.
		[__loongarch__] (COUNT_LEADING_ZEROS_0): Likewise.

2023-08-12  Meghan Denny  <hello@nektro.net>

	Updated constants from <https://dwarfstd.org/Languages.php>
	include/
		* dwarf2.h: Update with additional languages from dwarf
		standard.

2023-08-12  Jason Merrill  <jason@redhat.com>

	c++: source position of lambda captures [PR84471]
	include/
		* ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __.

2023-08-12  Lulu Cheng  <chenglulu@loongson.cn>

	Libvtv: Add loongarch support.
	The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB,
	but only 16KiB pages are supported for now.

	Co-Authored-By: qijingwen <qijingwen@loongson.cn>

	include/
		* vtv-change-permission.h (defined): Determines whether the macro
		__loongarch_lp64 is defined
		(VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.

2023-08-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-11  Carl Love  <cel@us.ibm.com>

	gdb.ada/mi_var_access.exp
	The NUMCHILD value for the "A_String_Access" test differs for X86 and
	PowerPC.  The patch substitutes $decimal instead of "1" to match the value
	of NUMCHILD.

	The test "-var-update A_String_Access" generates different output depending
	on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED.  If the value is true,
	the strings "new_type" and "new_num_children" are printed along with their
	values.

	The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
	produces the output:

	  Expecting: ^(-var-update A_String_Access[
	  ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
	  ]+[(]gdb[)]
	  [ ]*)
	  -var-update A_String_Access
	  ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
	  (gdb)
	  FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)

	The patch adds a second possible result string for the test
	$re_varobj_update_result_type to match the case when type_changed is true.

	Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
	is true on PowerPC and false on X86-64.

	Fixes 2 failures on PowerPC.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-11  Tom Tromey  <tromey@adacore.com>

	Fix Python documentation for range type fields
	GDB's Python documentation claims that range types have two fields,
	but this is not true, and attempts to access them hit this error:

	      "Type is not a structure, union, enum, or function type."

	This patch fixes the documentation.

2023-08-11  Tom Tromey  <tromey@adacore.com>

	Test GNAT encodings in arr_acc_idx_w_gap.exp
	While working on a GNAT bug, I wanted to also test
	arr_acc_idx_w_gap.exp using GNAT encodings.  When the GNAT change is
	ready, I plan to add a new case here.

	Tested on x86-64 Fedora 36.  I am checking this in.

2023-08-11  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Reflect actual range of vlen for hashing
	Before actual vlen handling, fix the riscv_gdbarch_features hashing
	function based on the actual valid range of vlen.  In bytes, vlen is 0,
	or 4 <= xlen <= 8192.

	RISC-V: Add reference to Zve32*
	Before actual vlen handling, this commit fixes its description to allow vlen
	less than 16 (but 4 or greater), to support vector subset extensions for
	embedded environment ('Zve32*').

2023-08-11  Alan Modra  <amodra@gmail.com>

	gdb: warn unused result for bfd IO functions
	This fixes the compilation warnings introduced by my bfdio.c patch.

	The removed bfd_seeks in coff_symfile_read date back to 1994, commit
	7f4c859520, prior to which the file used stdio rather than bfd to read
	symbols.  Since it now uses bfd to read the file there should be no
	need to synchronise to bfd's idea of the file position.  I also fixed
	a potential uninitialised memory access.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-08-11  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix AIX build break.
	In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same.

	This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result.

2023-08-11  Jan Beulich  <jbeulich@suse.com>

	gas: purge md_elf_section_word()
	It's not documented anyway, and having it makes no sense anymore with
	obj_elf_section_word() now being TC_SPARC-only. In any event the x86
	backing function was dead code.

2023-08-11  Jan Beulich  <jbeulich@suse.com>

	x86: pack CPU flags in opcode table
	The table constantly growing in two dimensions (number of table entries
	times number of ISA extension flags) doesn't scale very well. Use a more
	compact representation: Only identifiers which need to combine with
	other identifiers retain individual flag bits. All others are combined
	into an enum, with a new helper added to transform the table entries
	into the original i386_cpu_flags layout. This way the table in the final
	binary shrinks by almost a third (the generated source code shrinks by
	about half), and isn't likely to grow again in that dimension any time
	soon.

	While moving the 3DNow! fields, drop the stray inner 'a' from their
	names.

2023-08-11  Alan Modra  <amodra@gmail.com>

	warn unused result for bfd IO functions
	This patch fixes all the warnings I found in bfd, binutils and ld,
	plus some bitrotted COFF_GO32 code that tried to allocate -168ul
	bytes.  When the malloc fail was reported these testsuite fails
	resulted:

	i386-go32  +FAIL: go32 stub
	i386-go32  +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp.
	i386-go32  +ERROR: couldn't open "tmpdir/go32stub": no such file or directory
	i386-go32  +FAIL: ld-scripts/sane1
	i386-go32  +FAIL: ld-scripts/assign-loc
	i386-go32  +FAIL: ld-scripts/pr18963

	This does result in some warnings in gdb which are fixed in a followup
	patch.

	bfd/
		* bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT.
		(bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise.
		* bfd-in2.h: Regenerate.
		* coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write
		return value.
		(xcoff_generate_rtinit): Likewise.  Also free data_buffer and
		string_table before returning.
		* coff64-rs6000.c (xcoff64_generate_rtinit): Likewise.
		* coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek
		return value.
		* coffcode.h (coff_apply_checksum): Don't ignore bfd_write return.
		(coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc.
		Fix bitrotted code to look for first section with non-zero filepos.
		* elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore
		bfd_seek or bfd_write return values.
		* pef.c (bfd_pef_scan_section): Likewise.
		(bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise.
		* vms-misc.c (_bfd_vms_output_end): Likewise.  Return status.
		* vms.h (_bfd_vms_output_end): Update prototype.
		* vms-alpha.c: Pass _bfd_vms_output_end status up call chains.
		* wasm-module.c (wasm_compute_custom_section_file_position): Don't
		ignore bfd_seek or bfd_write return values.
		(wasm_compute_section_file_positions): Likewise.
		* xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value.
		(bfd_sym_read_name_table): Likewise.
	binutils/
		* ar.c (print_contents, extract_file): Don't ignore bfd_seek
		return value.
	ld/
		* pdb.c (create_section_contrib_substream): Don't ignore bfd_seek
		return value.
		(create_section_header_stream): Likewise.
		* pe-dll.c (pe_get16, pe_get32): Add fail param to return results
		from bfd_seek and bfd_read.
		(pe_implied_import_dll): Handle these fails, and other bfd_seek
		and bfd_read return values.

2023-08-11  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Fix opcode entries of "vmsge{,u}.vx"
	Their check_func should be "match_never", not "match_opcode".  The reasons
	this error did not cause any disassembler errors are:

	1.  The problem will not reproduce if "no-aliases" is specified
	    (because macro instructions are handled as aliases).
	2.  If not, all affected compressed instructions or their aliases
	    precede before "vmsge{,u}.vx" macro instructions.

	However, it'll easily break if we reorder opcode entries.  This commit
	fixes this issue before the *accident* occurs.

	opcodes/ChangeLog:

		* riscv-opc.c (riscv_opcodes): Make sure that we never match to
		vmsge{,u}.vx instructions unless specified in the assembler.

2023-08-11  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Remove support for non-existing 'Zve32d'
	Since this "extension" does not exist (on the other hand, 'Zve64d' exists)
	and it's not useful if we keep it (as other code portions just ignore
	"zve32d"), this commit just removes it.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d'
		extension from the list.

2023-08-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-10  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix off-by-one error in cooked_indexer::recurse
	Test-case gdb.dwarf2/pr13961.exp contains:
	...
	 <1><25>: Abbrev Number: 8 (DW_TAG_class_type)
	    <26>   DW_AT_specification: <0x2a>
	 <1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
	    <2b>   DW_AT_name        : foo
	    <2f>   DW_AT_byte_size   : 4
	    <30>   DW_AT_decl_file   : 1
	    <31>   DW_AT_decl_line   : 1
	    <32>   DW_AT_sibling     : <0x44>
	...

	The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
	DIE indexing in the cooked_index, by adding it to m_deferred_entries.

	The resulting cooked index entries are:
	...
	        [25] ((cooked_index_entry *) 0x333b5d0)
	        name:       foo
	        canonical:  foo
	        qualified:  foo
	        DWARF tag:  DW_TAG_class_type
	        flags:      0x0 []
	        DIE offset: 0x2a
	        parent:     ((cooked_index_entry *) 0)

	        [26] ((cooked_index_entry *) 0x333b630)
	        name:       foo
	        canonical:  foo
	        qualified:  foo::foo
	        DWARF tag:  DW_TAG_class_type
	        flags:      0x0 []
	        DIE offset: 0x25
	        parent:     ((cooked_index_entry *) 0x333b5d0) [foo]
	...

	Notice that 0x2a is the parent of 0x25, and that this is why the qualified
	name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".

	The parent is set here in cooked_indexer::make_index:
	...
	  for (const auto &entry : m_deferred_entries)
	    {
	      void *obj = m_die_range_map.find (entry.spec_offset);
	      cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
	      m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
				    entry.name, parent, m_per_cu);
	    }
	...
	and AFAICT, we store in m_die_range_map the parent of the respective
	spec_offset DIE (though that's not clear from the comment describing it).

	So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
	m_die_range_map.find (0x2a) == 0x2a.

	This is an off-by-one error, fixed in cooked_indexer::recurse by:
	...
	-      CORE_ADDR start = form_addr (parent_entry->die_offset,
	+      CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
	...
	which gives us:
	...
	    [12] ((cooked_index_entry *) 0x41e21f0)
	    name:       foo
	    canonical:  foo
	    qualified:  foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x25
	    parent:     ((cooked_index_entry *) 0)

	    [13] ((cooked_index_entry *) 0x41e2190)
	    name:       foo
	    canonical:  foo
	    qualified:  foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x2a
	    parent:     ((cooked_index_entry *) 0)
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30739
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739

2023-08-10  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Dump qualified name of cooked_index_entry
	When doing "maint print objfiles" for the exec of test-case
	gdb.dwarf2/pr13961.exp, we get:
	...
	    [25] ((cooked_index_entry *) 0x37b25d0)
	    name:       foo
	    canonical:  foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x2a
	    parent:     ((cooked_index_entry *) 0)

	    [26] ((cooked_index_entry *) 0x37b2630)
	    name:       foo
	    canonical:  foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x25
	    parent:     ((cooked_index_entry *) 0x37b25d0) [foo]
	...

	By following the parent links in the text, we can conclude that the qualified
	name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).

	But it's not evident, and also hard to verify in a test-case.

	Add dumping of the qualified name, such that we have:
	...
	    [25] ((cooked_index_entry *) 0x333b5d0)
	    name:       foo
	    canonical:  foo
	    qualified:  foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x2a
	    parent:     ((cooked_index_entry *) 0)

	    [26] ((cooked_index_entry *) 0x333b630)
	    name:       foo
	    canonical:  foo
	    qualified:  foo::foo
	    DWARF tag:  DW_TAG_class_type
	    flags:      0x0 []
	    DIE offset: 0x25
	    parent:     ((cooked_index_entry *) 0x333b5d0) [foo]
	...

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-10  Carl Love  <cel@us.ibm.com>

	Fix gdb.ada/O2_float_param.exp for PowerPC
	The frame command on Power pc prints the address in hex between the
	#0 and in calle.increment.  For example

	(gdb) frame
	#0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
	    at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
	19	   procedure Increment (Val : in out Float; Msg: String) is

	The printing of the address for the frame is done by function
	print_frame in gdb/stack.c.  If SAL.IS_stmt is false for the frame,
	function frame_show_address returns true and print_frame prints the
	address.  Currently, SAL.IS is false on PowerPC and true on X86-64.

	Update the set re string to accept the hex address if it exits.

	Fixes two failures on PowerPC.

	Patch tested on Power10 with no new regressions.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-10  Tom Tromey  <tromey@adacore.com>

	Change py-thread-exited.exp to work with gdbserver
	gdbserver does not notify gdb of new threads when they are created.
	I'm not sure if this is documented anywhere, but it is mentioned on
	this page:

	https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity

	Search for "Finding new threads in the inferior".

	This behavior is a bit unfortunate -- I would think that it would be
	better to arrange for such notification if something on the gdb side
	is interested.

	Meanwhile, this patch fixes py-thread-exited.exp to work around this
	problem.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677

2023-08-10  Tom Tromey  <tom@tromey.com>

	Pass unique_ptr to add_thread_with_info
	This changes add_thread_with_info to accept a unique_ptr, making it
	clear that it takes ownership of the passed-in pointer.

	I can't test the AIX or Darwin changes, but I think they are
	relatively obvious.

2023-08-10  Richard Ball  <richard.ball@arm.com>

	aarch64: Enable Cortex-A520 CPU
	This patch adds support for the Cortex-A520 CPU to gas.

	No regressions on aarch64-none-elf.

	gas/ChangeLog:

		* NEWS: Update docs.
		* config/tc-aarch64.c: Add Cortex-A520.
		* doc/c-aarch64.texi: Update docs.

2023-08-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with cc-with-gnu-debuglink
	When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
	cc-with-gnu-debuglink, I run into:
	...
	(gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
	maint print symbols -objfile enqueued-cu-base-addr^M
	(gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
	...

	The problem is that the CU we're trying to print is in objfile
	enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.

	Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".

	Tested on x86_64-linux.

2023-08-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp
	I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
	cc-with-debug-names, and ran into:
	...
	FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
	FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
	...

	The first FAIL is a known issue, PR symtab/29572.

	The following FAIL is a consequence of the first FAIL, so require for the
	second test that the first test passes.

	Tested on x86_64-linux, with target boards unix and cc-with-debug-names.

2023-08-10  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix assertion in write_debug_names
	When running test-case gdb.dwarf2/pr13961.exp with target-board
	cc-with-debug-names, I run into:
	...
	Running gdb.dwarf2/pr13961.exp ...
	gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \
	  write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed.
	...

	This is a regression since commit 542a33e348a ("Only use the per-BFD object to
	 write a DWARF index"), which did:
	...
	-  gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ());
	+  gdb_assert (counter == per_bfd->all_units.size ());
	...

	Fix this by reverting to using all_comp_units:
	...
	  gdb_assert (counter == per_bfd->all_comp_units.size ());
	...

	Tested on x86_64-linux, using target boards unix and cc-with-debug-names.

	PR symtab/30741
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30741

2023-08-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-09  David Faust  <david.faust@oracle.com>

	bpf: use w regs in 32-bit non-fetch atomic pseudo-c
	The 32-bit non-fetching atomic instructions treat the source register as
	32-bits, which means in the pseudo-c syntax the "w" registers should be
	used rather than the "r" registers.

	opcodes/

		* bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32
		and AXOR32 pseudo-c dialect asm templates.

	gas/

		* testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg
		in non-fetching 32-bit atomic instructions.
		* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.

2023-08-09  Mihails Strasuns  <mihails.strasuns@intel.com>

	gdb, breakpoint: add breakpoint location debugging logs
	Add new commands:

	  set debug breakpoint on|off
	  show debug breakpoint

	This patch introduces new debugging information that prints
	breakpoint location insertion and removal flow.

	The debug output looks like:
	~~~
	(gdb) set debug breakpoint on
	(gdb) disassemble main
	Dump of assembler code for function main:
	   0x0000555555555129 <+0>:	endbr64
	   0x000055555555512d <+4>:	push   %rbp
	   0x000055555555512e <+5>:	mov    %rsp,%rbp
	=> 0x0000555555555131 <+8>:	mov    $0x0,%eax
	   0x0000555555555136 <+13>:	pop    %rbp
	   0x0000555555555137 <+14>:	ret
	End of assembler dump.
	(gdb) break *0x0000555555555137
	Breakpoint 2 at 0x555555555137: file main.c, line 4.
	[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
	(gdb) c
	Continuing.
	[breakpoint] update_global_location_list: insert_mode = UGLL_INSERT
	[breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4
	[breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5
	[breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e
	[breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4
	[breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove
	[breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove
	[breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove
	[breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove

	Breakpoint 2, 0x0000555555555137 in main () at main.c:4
	4	}
	~~~

	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-08-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-09  Alan Modra  <amodra@gmail.com>

	Rename bfd_bread and bfd_bwrite
	These were renamed from bfd_read and bfd_write back in 2001 when they
	lost an unnecessary parameter.  Rename them back, and get rid of a few
	casts that are only needed without prototyped functions (K&R C).

	Add ld makefile dependencies
		* Makefile.am (EXTRA_ld_new_SOURCES): Add pep-dll-aarch64.c
		and pep-dll-x86_64.c.
		* Makefile.in: Regenerate.

2023-08-09  Alan Modra  <amodra@gmail.com>

	PR30724, cygwin ld performance regression since 014a602b86
	According to the reporter of this bug the newlib fseek implementation
	is likely slowed down by locking and fflush, only attempting to
	optimise seeks when the file is opened read-only.  Thus when writing
	the output we get a dramatic slowdown due to commit 014a602b86.

		PR 30724
		* bfd.c (enum bfd_last_io): New.
		(struct bfd): Add last_io field.
		* bfd-in2.h: Regenerate.
		* bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is
		opposite direction.
		(bfd_seek): Reinstate optimisation for seek to same position.

2023-08-08  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Use move capture in gdb_demangle
	Use move capture in gdb_demangle when compiling for c++14 or higher, to save a
	std::string copy.

	Tested on x86_64-linux.

	Reported-By: Tom Tromey <tom@tromey.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-08  Sam James  <sam@gentoo.org>

	ld: Fix retain7a.d XFAIL/notarget entry for hppa
	PR 30733
	* ld/testsuite/ld-elf/retain7a.d: Fix XFAIL entry for hppa to match
	  hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.

	ld: Fix relocatable.d XFAIL/notarget entry for hppa
	PR 30734
	* ld/testsuite/ld-elf/relocatable.d: Fix notarget entry for hppa to match
	  hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.

2023-08-08  Guinevere Larsen  <blarsen@redhat.com>

	Update my name in maintainers file

2023-08-08  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	Guard against killing unrelated processes in amd64-disp-step.exp
	When testing current gdb trunk on Solaris/amd64, the whole session was
	reliably terminated by make check.  I could trace this to the following
	entry in gdb.arch/amd64-disp-step/gdb.log:

	FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get
	inferior pid
	Executing on target: kill -ALRM -1    (timeout = 300)
	builtin_spawn -ignore SIGHUP kill -ALRM -1

	If $inferior_pid doesn't refer to a single process for some reason, this
	kill would terminate either a process group or the whole session.

	This patch avoids this by ensuring that the pid arg is positive.

	Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-08  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix build breaker with -std=c++11
	When building with -std=c++11 I run into:
	...
	gdb/dwarf2/cooked-index.c: In member function \
	  ‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’:
	gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \
	  available with -std=c++14 or -std=gnu++14 [-Werror]
	          ctx = std::move (ctx)] ()
	          ^~~
	...

	Fix this by capturing a copy instead when using -std=c++11:
	...
	    = gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] ()
	...

	Tested by building with and without -stdc=++11 on x86_64-linux.

	Reported-By: Tom Tromey <tom@tromey.com>
	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-08  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Update ratified 'Ztso' extension version
	Because the 'Ztso' extension is now ratified, it has a version number of 1.0
	(not 0.1).  This commit updates the number.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
		number of the 'Ztso' extension since it's ratified.

2023-08-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30700 tmpdir/gp-collect-app_F test fails
	gprofng/ChangeLog
	2023-08-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30700
		* testsuite/gprofng.display/gp-collect-app_F.exp: Fix -name argument
		for sub-experiment filtering.

2023-08-07  Jan Beulich  <jbeulich@suse.com>

	RISC-V: move comment describing rules for riscv_opcodes[]
	It makes little sense to have this comment meanwhile over a hundred
	lines ahead of the array. In fact until spotting the comment, I was
	wondering why those pretty important aspects aren't spelled out
	anywhere.

2023-08-07  Richard Bunt  <richard.bunt@linaro.org>

	gdb/fortran: Align intrinsic/variable precedence
	Fortran allows variables and function to be named after language defined
	intrinsics as they are not reserved keywords. For example, the abs maths
	intrinsic can be hidden by a user declaring a variable called abs.

	The behavior before this patch was to favour the intrinsic, which meant
	that any variables named, for example "allocated", could not be
	inspected by GDB.

	This patch inverts this priority to bring GDB's behaviour closer to the
	Fortran language, where the user defined symbol can hide the intrinsic.

	Special care was need to prevent any C symbols from overriding either
	Fortran intrinsics or user defined variables. This was observed to be
	the case when GDB has access to symbols for abs from libm. This was
	solved by only allowing symbols not marked with language_fortran to be
	overridden.

	In total this brings the order of precedence to the following (highest
	first):

	    1. User defined Fortran variable or function.
	    2. Fortran intrinsic.
	    3. Symbols from languages other than Fortran.

	The sizeof intrinsic is now case insensitive. This is closer to the
	Fortran language.  I believe this change is safe enough as it increases
	the acceptance of the grammar, rather than restricts it. I.e. it should
	not break any existing scripts which rely on it. Unless of course they
	rely on SIZEOF being rejected.

	GDB built with GCC 13.

	No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
	LLVM, NVHPC; Platforms: x86_64, aarch64.

	Existing tests in gdb.fortran cover the invocation of intrinsics
	including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-05  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Find main language without symtab expansion
	When loading an executable using "file a.out", the language is set according
	to a.out, which can involve looking up the language of symbol "main", which
	will cause the symtab expansion for the containing CU.

	Expansion of lto debug info can be slow, so in commit d3214198119 ("[gdb] Use
	partial symbol table to find language for main") a feature was added to avoid
	the symtab expansion.

	This feature stopped working after commit 7f4307436fd ("Fix "start" for D,
	Rust, etc").

	[ The commit addresses problems related to command start, which requires finding
	the main function:
	- for language D, "main" was found instead of "D main", and
	- for Rust, the correct function was found, but attributed the wrong name
	  (not fully qualified). ]

	Reimplement the feature by adding
	cooked_index_functions::lookup_global_symbol_language.

	Tested on x86_64-linux.

	PR symtab/30661
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661

2023-08-05  David Carew  <david@dcarew.com>

	as: Fix typo in manual
	The -D flag should enable "debugging"

2023-08-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-04  Tom Tromey  <tromey@adacore.com>

	Reindent recursive_dump_type
	I noticed that a 'switch' in recursive_dump_type was incorrect
	indented.  This patch fixes the problem.  Tested by rebuilding.

2023-08-04  Tom Tromey  <tom@tromey.com>

	Consolidate calls to bfd_set_cacheable
	I noticed that some spots in gdb call bfd_set_cacheable after opening
	a BFD.

	The BFD file cache is a bit odd.  BFDs that are opened locally are
	unconditionally registered with the cache, and their underlying file
	descriptor will always be closed when bfd_cache_close_all is called.
	However, only "cacheable" BFDs will be eligible for reopening when
	needed -- and by default BFD decides that if a file descriptor is
	passed in, then it should not be cacheable.  If a non-cacheable BFD's
	file descriptor is closed, there is no offical way to reopen it.

	gdb needs to call bfd_cache_close_all, because some systems cannot
	start an executable when it has an open file descriptor referencing
	it.

	However, gdb also will sometimes passes an open file descriptor to the
	various BFD open functions.  And, due to lazy DWARF reading, gdb may
	also need to reopen these BFDs.

	Rather than having all the callers figure out when exactly to set the
	cacheable flag, I think it makes sense to consolidate this logic into
	the gdb_bfd.c wrapper functions.  It is ok to do this because gdb
	always passes a filename to these open functions, so reopening should
	work ok.

	Regression tested on x86-64 Fedora 38.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-04  Tom Tromey  <tromey@adacore.com>

	Remove extra '.' from error message
	A local gdb test failed with this error message:

	 Remote communication error.  Target disconnected.: Arg list too long.

	The ".:" seemed weird to me.  This patch removes the ".".

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-08-04  Tom Tromey  <tromey@adacore.com>

	Fix incorrect class name in free_objfile documentation
	The documentation for the Python free_objfile event registry uses the
	wrong class name.  This patch fixes it.  I'm checking this in as
	obvious.

2023-08-04  Nick Clifton  <nickc@redhat.com>

	Fix potential infinite loop in bfd_cache_close_all.
	  PR 15545 * cache.c (bfd_cache_close_all): Extend description to note that all files will be closed, even those that are not cacheable. Add code to prevent a possible infinite loop.

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Extend gdb.base/index-cache.exp further
	Add lookup of a non-existing symbol to test-case gdb.base/index-cache.exp.

	This serves as regression test for PR symtab/30718.

	PR symtab/30718
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Move "maint wait-for-index-cache" ALAP in gdb.base/index-cache.exp
	In test-case gdb.base/index-cache.exp proc run_test_with_flags contains:
	...
		clean_restart ${testfile}

		# The tests generally want to check the cache, so make sure it
		# has completed its work.
		gdb_test_no_output "maintenance wait-for-index-cache"
	...

	This however hides data races between:
	- index-cache writing (due to file $exec), and
	- symbol lookups (due to subsequent ptype commands).

	Fix this by:
	- moving the "maintenance wait-for-index-cache" to proc check_cache_stats, and
	- moving all calls to proc check_cache_stats ALAP.

	Tested on x86_64-linux.

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix data race on dwarf2_per_cu_data::{files_read,is_debug_types}
	With gdb build with -fsanitize=thread, and the exec from test-case
	gdb.base/index-cache.exp, I run into:
	...
	$ rm -f ~/.cache/gdb/*; \
	  gdb -q -batch -iex "set index-cache enabled on" index-cache \
	    -ex "print foobar"
	  ...
	WARNING: ThreadSanitizer: data race (pid=25018)
	  Write of size 1 at 0x7b200000410d by main thread:
	    #0 dw2_get_file_names_reader gdb/dwarf2/read.c:2033 (gdb+0x7ab023)
	    #1 dw2_get_file_names gdb/dwarf2/read.c:2130 (gdb+0x7ab023)
	    #2 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3105 (gdb+0x7ac6e9)
	    #3 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d040f)
	    #4 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5b6e)
	    #5 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc441d)
	    #6 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc4522)
	    #7 classify_name gdb/c-exp.y:3083 (gdb+0x61afec)
	    #8 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13)
	    #9 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e)
	    #10 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864)
	    #11 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x977245)
	    #12 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10b1b)
	    #13 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb1112e)
	    #14 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf8c)
	    #15 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4caaa)
	    #16 print_command gdb/printcmd.c:1468 (gdb+0xb4cdda)
	    #17 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078)
	    #18 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53)
	    #19 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a7ea)
	    #20 catch_command_errors gdb/main.c:518 (gdb+0xa183fd)
	    #21 execute_cmdargs gdb/main.c:617 (gdb+0xa185bf)
	    #22 captured_main_1 gdb/main.c:1289 (gdb+0xa1aad8)
	    #23 captured_main gdb/main.c:1310 (gdb+0xa1b9da)
	    #24 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b9da)
	    #25 main gdb/gdb.c:39 (gdb+0x42506a)

	  Previous read of size 1 at 0x7b200000410d by thread T2:
	    #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30)
	    #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803)
	    #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36)
	    #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d)
	    #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d)
	    #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d)
	    #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c)
	    #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db)
	    #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db)
	    #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db)
	    #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db)
	    #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db)
	    #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954)
	    #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954)
	    #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a)
	    #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a)
	    #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a)
	    #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a)
	    #19 pthread_once <null> (libtsan.so.0+0x4457c)
	    #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b)
	    #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b)
	    #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174570d)
	    #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174570d)
	    #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174570d)
	    #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174570d)
	    #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x17480c0)
	    #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x17480c0)
	    #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x17480c0)
	    #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x17480c0)
	    #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x17480c0)
	    #31 <null> <null> (libstdc++.so.6+0xdcac2)
	  ...
	SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:2033 in dw2_get_file_names_reader
	...

	The race happens when issuing the "file $exec" command.

	The race is between:
	- a worker thread writing the index cache, and in the process reading
	  dwarf2_per_cu_data::is_debug_type, and
	- the main thread writing to dwarf2_per_cu_data::files_read.

	The two bitfields dwarf2_per_cu_data::files_read and
	dwarf2_per_cu_data::is_debug_type share the same bitfield container.

	Fix this by making dwarf2_per_cu_data::files_read a packed<bool, 1>.

	Tested on x86_64-linux.

	PR symtab/30718
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix data race on dwarf2_per_cu_data::{mark,is_debug_types}
	With gdb build with -fsanitize=thread, and the exec from test-case
	gdb.base/index-cache.exp, I run into:
	...
	$ rm -f ~/.cache/gdb/*; \
	  gdb -q -batch -iex "set index-cache enabled on" index-cache \
	    -ex "print foobar"
	  ...
	WARNING: ThreadSanitizer: data race (pid=23970)
	  Write of size 1 at 0x7b200000410d by main thread:
	    #0 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3077 (gdb+0x7ac54e)
	    #1 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d039f)
	    #2 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5aee)
	    #3 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc439d)
	    #4 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc44a2)
	    #5 classify_name gdb/c-exp.y:3083 (gdb+0x61afec)
	    #6 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13)
	    #7 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e)
	    #8 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864)
	    #9 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x9771c5)
	    #10 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10a9b)
	    #11 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb110ae)
	    #12 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf0c)
	    #13 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4ca2a)
	    #14 print_command gdb/printcmd.c:1468 (gdb+0xb4cd5a)
	    #15 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078)
	    #16 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53)
	    #17 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a76a)
	    #18 catch_command_errors gdb/main.c:518 (gdb+0xa1837d)
	    #19 execute_cmdargs gdb/main.c:617 (gdb+0xa1853f)
	    #20 captured_main_1 gdb/main.c:1289 (gdb+0xa1aa58)
	    #21 captured_main gdb/main.c:1310 (gdb+0xa1b95a)
	    #22 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b95a)
	    #23 main gdb/gdb.c:39 (gdb+0x42506a)

	  Previous read of size 1 at 0x7b200000410d by thread T1:
	    #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30)
	    #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803)
	    #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36)
	    #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d)
	    #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d)
	    #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d)
	    #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c)
	    #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db)
	    #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db)
	    #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db)
	    #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db)
	    #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db)
	    #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954)
	    #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954)
	    #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a)
	    #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a)
	    #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a)
	    #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a)
	    #19 pthread_once <null> (libtsan.so.0+0x4457c)
	    #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b)
	    #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b)
	    #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174568d)
	    #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174568d)
	    #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174568d)
	    #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174568d)
	    #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1748040)
	    #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1748040)
	    #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1748040)
	    #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1748040)
	    #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1748040)
	    #31 <null> <null> (libstdc++.so.6+0xdcac2)
	  ...
	SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:3077 in dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>)
	...

	The race happens when issuing the "file $exec" command.

	The race is between:
	- a worker thread writing the index cache, and in the process reading
	  dwarf2_per_cu_data::is_debug_type, and
	- the main thread writing to dwarf2_per_cu_data::mark.

	The two bitfields dwarf2_per_cu_data::mark and
	dwarf2_per_cu_data::is_debug_type share the same bitfield container.

	Fix this by making dwarf2_per_cu_data::mark a packed<unsigned int, 1>.

	Tested on x86_64-linux.

	PR symtab/30718
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Extend gdb.base/index-cache.exp
	The test-case gdb.base/index-cache.exp uses only one source file, which
	contains main.

	While doing "file $exec", in set_initial_language a symbol lookup of "main" is
	done, causing the symtab containing main to be expanded.

	Handling of main is special, and a future optimization may skip the lookup and
	expansion.

	Reliably exercise:
	- the lookup of main, expanding the symtab containing main, by doing
	  "ptype main", and
	- the lookup of another symbol, expanding a symtab not containing main, by:
	  - adding another source file containing function foo, and
	  - doing "ptype foo".

	This triggered a segfault with target board native-extended-gdbserver, filed
	as PR symtab/30712, but that seems to be fixed by a previous commit in this
	series.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30712

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in,is_debug_type}
	With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp
	and target board debug-types, I run into:
	...
	(gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
	Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
	==================
	WARNING: ThreadSanitizer: data race (pid=9654)
	  Write of size 1 at 0x7b200000420d by main thread:
	    #0 dwarf2_per_cu_data::get_header() const gdb/dwarf2/read.c:21513 (gdb+0x8d1eee)
	    #1 dwarf2_per_cu_data::addr_size() const gdb/dwarf2/read.c:21524 (gdb+0x8d1f4e)
	    #2 dwarf2_cu::addr_type() const gdb/dwarf2/cu.c:112 (gdb+0x806327)
	    #3 set_die_type gdb/dwarf2/read.c:21932 (gdb+0x8d3870)
	    #4 read_base_type gdb/dwarf2/read.c:15448 (gdb+0x8bcacb)
	    #5 read_type_die_1 gdb/dwarf2/read.c:19832 (gdb+0x8cc0a5)
	    #6 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d)
	    #7 lookup_die_type gdb/dwarf2/read.c:19739 (gdb+0x8cbdc7)
	    #8 die_type gdb/dwarf2/read.c:19593 (gdb+0x8cb68a)
	    #9 read_subroutine_type gdb/dwarf2/read.c:14648 (gdb+0x8b998e)
	    #10 read_type_die_1 gdb/dwarf2/read.c:19792 (gdb+0x8cbf2f)
	    #11 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d)
	    #12 read_func_scope gdb/dwarf2/read.c:10154 (gdb+0x8a4f36)
	    #13 process_die gdb/dwarf2/read.c:6667 (gdb+0x898daa)
	    #14 read_file_scope gdb/dwarf2/read.c:7682 (gdb+0x89bad8)
	    #15 process_die gdb/dwarf2/read.c:6654 (gdb+0x898ced)
	    #16 process_full_comp_unit gdb/dwarf2/read.c:6418 (gdb+0x8981de)
	    #17 process_queue gdb/dwarf2/read.c:5690 (gdb+0x894433)
	    #18 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1770 (gdb+0x88623a)
	    #19 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x886300)
	    #20 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88b1f1)
	    #21 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16917 (gdb+0x8c228e)
	    #22 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf39055)
	    #23 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66ab7)
	    #24 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf6711b)
	    #25 operator() gdb/symtab.c:2562 (gdb+0xf67272)
	    #26 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf776b1)
	    #27 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77708)
	    #28 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3fc97)
	    #29 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xecae47)
	    #30 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
	    #31 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf674fb)
	    #32 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf67780)
	    #33 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf66d6e)
	    #34 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf65cb3)
	    #35 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf64dab)
	    #36 set_initial_language() gdb/symfile.c:1708 (gdb+0xf43074)
	    #37 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf41608)
	    #38 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf42faf)
	    #39 file_command gdb/exec.c:554 (gdb+0x94ff29)
	    #40 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
	    #41 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
	    #42 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff379c)
	    #43 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94b5bc)
	    #44 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94bc79)
	    #45 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x1034efc)
	    #46 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94ab61)
	    #47 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11be4ef)
	    #48 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a960)
	    #49 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94aa21)
	    #50 stdin_event_handler gdb/ui.c:155 (gdb+0x10751a0)
	    #51 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d95bac)
	    #52 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d962e4)
	    #53 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d946d0)
	    #54 start_event_loop gdb/main.c:412 (gdb+0xb5ab52)
	    #55 captured_command_loop gdb/main.c:476 (gdb+0xb5ad41)
	    #56 captured_main gdb/main.c:1320 (gdb+0xb5cec1)
	    #57 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5cf70)
	    #58 main gdb/gdb.c:32 (gdb+0x416776)

	  Previous read of size 1 at 0x7b200000420d by thread T11:
	    #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x831630)
	    #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x832897)
	    #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x82db8d)
	    #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:645 (gdb+0x7f1d49)
	    #4 operator() gdb/dwarf2/cooked-index.c:474 (gdb+0x7f0f31)
	    #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2a13)
	    #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
	    #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
	    #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
	    #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
	    #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
	    #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
	    #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
	    #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
	    #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
	    #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
	    #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
	    #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
	    #19 pthread_once <null> (libtsan.so.0+0x4457c)
	    #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
	    #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
	    #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
	    #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
	    #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dad25a)
	    #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dacb7c)
	    #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dadc2b)
	    #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dad05c)
	    #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1db038e)
	    #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1db0319)
	    #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1db02ce)
	    #31 <null> <null> (libstdc++.so.6+0xdcac2)
	  ...
	SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:21513 in dwarf2_per_cu_data::get_header() const
	...

	The race happens when issuing the "file $exec" command.

	The race is between:
	- a worker thread writing the index cache, and in the process reading
	   dwarf2_per_cu_data::is_debug_type, and
	- the main thread writing to dwarf2_per_cu_data::m_header_read_in.

	The two bitfields dwarf2_per_cu_data::m_header_read_in and
	dwarf2_per_cu_data::is_debug_type share the same bitfield container.

	Fix this by making dwarf2_per_cu_data::m_header_read_in a packed<bool, 1>.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30392
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix race on dwarf2_per_cu_data::{queued,is_debug_type}
	With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
	run into:
	...
	(gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
	Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
	==================
	WARNING: ThreadSanitizer: data race (pid=24296)
	  Write of size 1 at 0x7b200000420d by main thread:
	    #0 queue_comp_unit gdb/dwarf2/read.c:5564 (gdb+0x8939ce)
	    #1 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1754 (gdb+0x885b96)
	    #2 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x885d86)
	    #3 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88ac77)
	    #4 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16915 (gdb+0x8c1c8a)
	    #5 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf389a1)
	    #6 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66403)
	    #7 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf66a67)
	    #8 operator() gdb/symtab.c:2562 (gdb+0xf66bbe)
	    #9 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf76ffd)
	    #10 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77054)
	    #11 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3f5e3)
	    #12 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xeca793)
	    #13 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
	    #14 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf66e47)
	    #15 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf670cc)
	    #16 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf666ba)
	    #17 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf655ff)
	    #18 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf646f7)
	    #19 set_initial_language() gdb/symfile.c:1708 (gdb+0xf429c0)
	    #20 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40f54)
	    #21 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf428fb)
	    #22 file_command gdb/exec.c:554 (gdb+0x94f875)
	    #23 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
	    #24 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
	    #25 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff3166)
	    #26 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94af08)
	    #27 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b5c5)
	    #28 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x10348c6)
	    #29 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a4ad)
	    #30 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdf87)
	    #31 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a2ac)
	    #32 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a36d)
	    #33 stdin_event_handler gdb/ui.c:155 (gdb+0x1074b6a)
	    #34 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d9502c)
	    #35 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d95764)
	    #36 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93b50)
	    #37 start_event_loop gdb/main.c:412 (gdb+0xb5a49e)
	    #38 captured_command_loop gdb/main.c:476 (gdb+0xb5a68d)
	    #39 captured_main gdb/main.c:1320 (gdb+0xb5c80d)
	    #40 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c8bc)
	    #41 main gdb/gdb.c:32 (gdb+0x416776)

	  Previous read of size 1 at 0x7b200000420d by thread T12:
	    #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x8310c8)
	    #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x83232f)
	    #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:177 (gdb+0x82d62b)
	    #3 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf7)
	    #4 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40)
	    #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2909)
	    #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
	    #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
	    #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
	    #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
	    #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
	    #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
	    #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
	    #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
	    #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
	    #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
	    #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
	    #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
	    #19 pthread_once <null> (libtsan.so.0+0x4457c)
	    #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
	    #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
	    #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
	    #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
	    #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac6da)
	    #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabffc)
	    #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dad0ab)
	    #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac4dc)
	    #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf80e)
	    #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf799)
	    #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf74e)
	    #31 <null> <null> (libstdc++.so.6+0xdcac2)
	 ...
	SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:5564 in queue_comp_unit
	...

	The race happens when issuing the "file $exec" command.

	The race is between:
	- a worker thread writing the index cache, and in the process reading
	  dwarf2_per_cu_data::is_debug_type, and
	- the main thread expanding the CU containing main, and in the process setting
	  dwarf2_per_cu_data::queued.

	The two bitfields dwarf2_per_cu_data::queue and
	dwarf2_per_cu_data::is_debug_type share the same bitfield container.

	Fix this by making dwarf2_per_cu_data::queued a packed<bool, 1>.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30392
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix data race on bfd::{cacheable,format}
	With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
	run into:
	...
	(gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
	Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
	==================
	WARNING: ThreadSanitizer: data race (pid=12261)
	  Write of size 4 at 0x7b4400097d08 by main thread:
	    #0 bfd_open_file bfd/cache.c:584 (gdb+0x148bb92)
	    #1 bfd_cache_lookup_worker bfd/cache.c:261 (gdb+0x148b12a)
	    #2 cache_bseek bfd/cache.c:289 (gdb+0x148b324)
	    #3 bfd_seek bfd/bfdio.c:459 (gdb+0x1489c31)
	    #4 _bfd_generic_get_section_contents bfd/libbfd.c:1069 (gdb+0x14977a4)
	    #5 bfd_get_section_contents bfd/section.c:1606 (gdb+0x149cc7c)
	    #6 gdb_bfd_scan_elf_dyntag(int, bfd*, unsigned long*, unsigned long*) gdb/solib.c:1601 (gdb+0xed8eca)
	    #7 elf_locate_base gdb/solib-svr4.c:705 (gdb+0xec28ac)
	    #8 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3430 (gdb+0xeca55d)
	    #9 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
	    #10 find_main_name gdb/symtab.c:6270 (gdb+0xf743a5)
	    #11 main_language() gdb/symtab.c:6313 (gdb+0xf74499)
	    #12 set_initial_language() gdb/symfile.c:1700 (gdb+0xf4285c)
	    #13 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40e2a)
	    #14 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf427d1)
	    #15 file_command gdb/exec.c:554 (gdb+0x94f74b)
	    #16 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
	    #17 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
	    #18 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff303c)
	    #19 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94adde)
	    #20 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b49b)
	    #21 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103479c)
	    #22 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a383)
	    #23 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bde5d)
	    #24 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a182)
	    #25 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a243)
	    #26 stdin_event_handler gdb/ui.c:155 (gdb+0x1074a40)
	    #27 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94f02)
	    #28 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9563a)
	    #29 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93a26)
	    #30 start_event_loop gdb/main.c:412 (gdb+0xb5a374)
	    #31 captured_command_loop gdb/main.c:476 (gdb+0xb5a563)
	    #32 captured_main gdb/main.c:1320 (gdb+0xb5c6e3)
	    #33 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c792)
	    #34 main gdb/gdb.c:32 (gdb+0x416776)

	  Previous read of size 1 at 0x7b4400097d08 by thread T12:
	    #0 bfd_check_format_matches bfd/format.c:323 (gdb+0x1492db4)
	    #1 bfd_check_format bfd/format.c:94 (gdb+0x1492104)
	    #2 build_id_bfd_get(bfd*) gdb/build-id.c:42 (gdb+0x6648f7)
	    #3 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:110 (gdb+0x82d205)
	    #4 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf1)
	    #5 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40)
	    #6 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f28f7)
	    #7 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
	    #8 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
	    #9 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
	    #10 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
	    #11 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
	    #12 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
	    #13 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
	    #14 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
	    #15 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
	    #16 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
	    #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
	    #19 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
	    #20 pthread_once <null> (libtsan.so.0+0x4457c)
	    #21 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
	    #22 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
	    #23 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
	    #24 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
	    #25 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac5b0)
	    #26 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabed2)
	    #27 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dacf81)
	    #28 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac3b2)
	    #29 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf6e4)
	    #30 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf66f)
	    #31 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf624)
	    #32 <null> <null> (libstdc++.so.6+0xdcac2)
	  ...
	SUMMARY: ThreadSanitizer: data race bfd/cache.c:584 in bfd_open_file
	...

	The race happens when issuing the "file $exec" command.

	The race is between:
	- a worker thread getting the build id while writing the index cache, and in
	  the process reading bfd::format, and
	- the main thread calling find_main_name, and in the process setting
	  bfd::cacheable.

	The two bitfields bfd::cacheable and bfd::format share the same bitfield
	container.

	Fix this by capturing the build id in the main thread, and using the captured
	value in the worker thread.

	Likewise for the dwz build id, which likely suffers from the same issue.

	While we're at it, also move the creation of the cache directory to
	the index_cache_store_context constructor, to:
	- make sure there's no race between subsequent file commands, and
	- issue any related warning or error messages during the file command.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR symtab/30392
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392

2023-08-04  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix data race on index_cache::m_enabled
	With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
	run into:
	...
	(gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
	Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
	(gdb) show index-cache enabled
	The index cache is off.
	(gdb) PASS: gdb.base/index-cache.exp: test_basic_stuff: index-cache is disabled by default
	set index-cache enabled on
	==================
	WARNING: ThreadSanitizer: data race (pid=32248)
	  Write of size 1 at 0x00000321f540 by main thread:
	    #0 index_cache::enable() gdb/dwarf2/index-cache.c:76 (gdb+0x82cfdd)
	    #1 set_index_cache_enabled_command gdb/dwarf2/index-cache.c:270 (gdb+0x82d9af)
	    #2 bool setting::set<bool>(bool const&) gdb/command.h:353 (gdb+0x6fe5f2)
	    #3 do_set_command(char const*, int, cmd_list_element*) gdb/cli/cli-setshow.c:414 (gdb+0x6fcd21)
	    #4 execute_command(char const*, int) gdb/top.c:567 (gdb+0xff2e64)
	    #5 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94acc0)
	    #6 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b37d)
	    #7 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103467e)
	    #8 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a265)
	    #9 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdd3f)
	    #10 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a064)
	    #11 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a125)
	    #12 stdin_event_handler gdb/ui.c:155 (gdb+0x1074922)
	    #13 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94de4)
	    #14 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9551c)
	    #15 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93908)
	    #16 start_event_loop gdb/main.c:412 (gdb+0xb5a256)
	    #17 captured_command_loop gdb/main.c:476 (gdb+0xb5a445)
	    #18 captured_main gdb/main.c:1320 (gdb+0xb5c5c5)
	    #19 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c674)
	    #20 main gdb/gdb.c:32 (gdb+0x416776)

	  Previous read of size 1 at 0x00000321f540 by thread T12:
	    #0 index_cache::enabled() const gdb/dwarf2/index-cache.h:48 (gdb+0x82e1a6)
	    #1 index_cache::store(dwarf2_per_bfd*) gdb/dwarf2/index-cache.c:94 (gdb+0x82d0bc)
	    #2 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:638 (gdb+0x7f1b97)
	    #3 operator() gdb/dwarf2/cooked-index.c:468 (gdb+0x7f0f24)
	    #4 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f285b)
	    #5 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
	    #6 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
	    #7 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
	    #8 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
	    #9 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
	    #10 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
	    #11 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
	    #12 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
	    #13 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
	    #14 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
	    #15 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
	    #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
	    #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
	    #18 pthread_once <null> (libtsan.so.0+0x4457c)
	    #19 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
	    #20 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
	    #21 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
	    #22 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
	    #23 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac492)
	    #24 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabdb4)
	    #25 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dace63)
	    #26 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac294)
	    #27 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf5c6)
	    #28 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf551)
	    #29 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf506)
	    #30 <null> <null> (libstdc++.so.6+0xdcac2)

	  Location is global 'global_index_cache' of size 48 at 0x00000321f520 (gdb+0x00000321f540)
	  ...
	SUMMARY: ThreadSanitizer: data race gdb/dwarf2/index-cache.c:76 in index_cache::enable()
	...

	The race happens when issuing a "file $exec" command followed by a
	"set index-cache enabled on" command.

	The race is between:
	- a worker thread reading index_cache::m_enabled to determine whether an
	  index-cache entry for $exec needs to be written
	  (due to command "file $exec"), and
	- the main thread setting index_cache::m_enabled
	  (due to command "set index-cache enabled on").

	Fix this by capturing the value of index_cache::m_enabled in the main thread,
	and using the captured value in the worker thread.

	Tested on x86_64-linux.

	PR symtab/30392
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392

2023-08-04  Alan Modra  <amodra@gmail.com>

	ppc: sanity check writing relocs
	Check for output buffer overruns.

		* elf32-ppc.c (swap_reloc_out, count_and_swap_reloc_out): New
		functions.  Use throughout file.
		* elf64-ppc.c (swap_reloc_out, count_and_swap_reloc_out): Likewise.

2023-08-04  Alan Modra  <amodra@gmail.com>

	PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
	This fixes miscounting of dynamic relocations on GOT entries when
	a) there are both local-dynamic and global-dynamic tls accesss for a
	   given symbol, and
	b) the symbol is global with non-default visibility, and
	c) the __tls_get_addr calls aren't optimised away.

		PR 30697
	bfd/
		* elf32-ppc.c (allocate_dynrelocs): Correct local-dynamic
		reloc count.
	ld/
		* testsuite/ld-powerpc/tls32ldgd.d,
		* testsuite/ld-powerpc/tls32ldgd.s: New test.
		* testsuite/ld-powerpc/powerpc.exp: Run it.

2023-08-04  Bruno Larsen  <blarsen@redhat.com>

	gdb/testsuite: Disable gdb.compile when testing with clang
	Attempting to test the gdb.compile with clang as the compiler results in
	over 300 unexpected errors, due to a segmentation fault and several
	handshake failures. Since the whole feature is designed around a gcc
	plugin, and even the gcc testing is shaky at best, this commit restricts
	those tests to only running under gcc. If that gets fixed, this commit
	can be reverted.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-03  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Remove superfluous handling of Ada main in write_cooked_index
	I filed PR29179 about the following FAIL in test-case
	gdb.ada/O2_float_param.exp with target board cc-with-gdb-index:
	...
	(gdb) break increment^M
	Function "increment" not defined.^M
	Make breakpoint pending on future shared library load? (y or [n]) n^M
	(gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: gdb_breakpoint: \
	  set breakpoint at increment
	...

	The FAIL was a regression since commit 2cf349be0e3 ("Do not put linkage names
	into .gdb_index").

	Before that commit we had:
	...
	$ readelf -w foo > READELF
	$ grep callee.*increment READELF
	[1568] callee__increment: 5 [global, function]
	[3115] callee.increment: 5 [global, function]
	...
	but after only:
	...
	$ grep callee.*increment READELF
	[3115] callee.increment: 5 [global, function]
	...

	The regression was fixed by commit 67e83a0deef ("Fix regression in
	c-linkage-name.exp with gdb index"), which got us again:
	...
	$ grep callee.*increment READELF
	[1568] callee__increment: 5 [global, function]
	[3115] callee.increment: 5 [global, function]
	...

	The commit however did not claim that particular PR.  A subsequent commit,
	commit 5fea9794325 ("Improve Ada support in .gdb_index") did claim to fix it,
	together with commit dd05fc7071a ("Change .gdb_index de-duplication
	implementation").

	The commit 5fea9794325 contained the following addition in write_cooked_index:
	...
	+      if (entry->per_cu->lang () == language_ada)
	+	{
	+	  /* We want to ensure that the Ada main function's name
	+	     appears verbatim in the index.  However, this name will
	+	     be of the form "_ada_mumble", and will be rewritten by
	+	     ada_decode.  So, recognize it specially here and add it
	+	     to the index by hand.  */
	+	  if (entry->tag == DW_TAG_subprogram
	+	      && strcmp (main_for_ada, name) == 0)
	+	    {
	+	      /* Leave it alone.  */
	+	    }
	+	  else
	+	    {
	+	      /* In order for the index to work when read back into
	+		 gdb, it has to use the encoded name, with any
	+		 suffixes stripped.  */
	+	      std::string encoded = ada_encode (name, false);
	+	      name = obstack_strdup (&symtab->m_string_obstack,
	+				     encoded.c_str ());
	+	    }
	+	}
	...

	The code contains some special handling related to the Ada main function, so
	let's look at that one: foo.  Before commit 67e83a0deef we have:
	...
	$ grep foo.*function READELF
	[3733] foo: 7 [global, function]
	...
	and after:
	...
	$ grep foo.*function READELF
	[2738] _ada_foo: 7 [global, function]
	[3733] foo: 7 [global, function]
	...
	so that looks identical to the callee.increment case.

	At commit 5fea9794325, we have slightly different index numbers:
	...
	$ grep foo.*function READELF
	[1658] foo: 7 [global, function]
	[2738] _ada_foo: 7 [global, function]
	...
	but otherwise the same result.

	If we disable the special handling of the Ada main function like so:
	...
	-	  if (entry->tag == DW_TAG_subprogram
	+	  if (false && entry->tag == DW_TAG_subprogram
	...
	we still have the exact same result because:
	...
	(gdb) p main_for_ada
	$1 = 0x352e6a0 "_ada_foo"
	...
	and ada_encode ("_ada_foo", false) == "_ada_foo".

	The comment seems to be copied from debug_names::insert, which does indeed use
	ada_decode, while the code in write_cooked_index uses ada_encode instead.

	Remove the superfluous special handling of Ada main in write_cooked_index.

	Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-03  Tom Tromey  <tromey@adacore.com>

	Remove f-string from DAP
	One more f-string snuck into the DAP code, in breakpoint.py.  Most of
	them were removed here:

	    https://sourceware.org/pipermail/gdb-patches/2023-June/200023.html

	but I think this one landed after that patch.

	While DAP only supports Python 3.5 and later, f-strings were added in
	3.6, so remove this.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708

2023-08-03  Tom Tromey  <tromey@adacore.com>

	Use frame.name() in FrameDecorator
	A co-worker pointed out that gdb's DAP implementation might return an
	integer for the name of a stack frame, like:

	    {"id": 1, "name": 93824992310799, ...}

	This can be seen currently in the logs of the bt-nodebug.exp test
	case.

	What is happening is that FrameDecorator falls back on returning the
	PC when the frame's function symbol cannot be found, relying on the
	gdb core to look up the minsym and print its name.

	This can actually yield the wrong answer sometimes, because it falls
	into the get_frame_pc / get_frame_address_in_block problem -- if the
	frame is at a call to a noreturn function, the PC in this case might
	appear to be in the next function in memory.  For more on this, see:

	    https://sourceware.org/bugzilla/show_bug.cgi?id=8416

	and related bugs.

	However, there's a different approach we can take: the code here can
	simply use Frame.name.  This handles the PC problem correctly, and
	gets us the information we need.

2023-08-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: avoid double stop after failed breakpoint condition check
	This commit replaces this earlier commit:

	  commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
	  Date:   Fri Oct 14 14:53:15 2022 +0100

	      gdb: don't always print breakpoint location after failed condition check

	and is a result of feedback received here[1].

	The original commit addressed a problem where, if a breakpoint
	condition included an inferior function call, and if the inferior
	function call failed, then GDB would announce the stop twice.  Here's
	an example of GDB's output before the above commit that shows the
	problem being addressed:

	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5       return *p;
	  Error in testing condition for breakpoint 1:
	  The program being debugged stopped while in a function called from GDB.
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.

	  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
	  5       return *p;
	  (gdb)

	The original commit addressed this issue in breakpoint.c, by spotting
	that the $pc had changed while evaluating the breakpoint condition,
	and inferring from this that GDB must have stopped elsewhere.

	However, the way in which the original commit suppressed the second
	stop announcement was to set bpstat::print to true -- this tells GDB
	not to print the frame during the stop announcement, and for the CLI
	this is fine, however, it was pointed out that for the MI this still
	isn't really enough.  Below is an example from an MI session after the
	above commit was applied, this shows the problem with the above
	commit:

	  -break-insert -c "cond_fail()" foo
	  ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"}
	  (gdb)
	  -exec-run
	  =thread-group-started,id="i1",pid="2636270"
	  =thread-created,id="1",group-id="i1"
	  =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}]
	  ^running
	  *running,thread-id="all"
	  (gdb)
	  =library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}]
	  =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}]
	  ~"\nProgram"
	  ~" received signal SIGSEGV, Segmentation fault.\n"
	  ~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n"
	  ~"24\t  return *p;\t\t\t/* Crash here.  */\n"
	  *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9"
	  &"Error in testing condition for breakpoint 1:\n"
	  &"The program being debugged was signaled while in a function called from GDB.\n"
	  &"GDB remains in the frame where the signal was received.\n"
	  &"To change this behavior use \"set unwindonsignal on\".\n"
	  &"Evaluation of the expression containing the function\n"
	  &"(cond_fail) will be abandoned.\n"
	  &"When the function is done executing, GDB will silently stop.\n"
	  =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"}
	  *stopped
	  (gdb)

	Notice that we still see two '*stopped' lines, the first includes the
	full frame information, while the second has no frame information,
	this is a result of bpstat::print having been set.  Ideally, the
	second '*stopped' line should not be present.

	By setting bpstat::print I was addressing the problem too late, this
	flag really only changes how interp::on_normal_stop prints the stop
	event, and interp::on_normal_stop is called (indirectly) from the
	normal_stop function in infrun.c.  A better solution is to avoid
	calling normal_stop at all for the stops which should not be reported
	to the user, and this is what I do in this commit.

	This commit has 3 parts:

	  1. In breakpoint.c, revert the above commit,

	  2. In fetch_inferior_event (infrun.c), capture the stop-id before
	  calling handle_inferior_event.  If, after calling
	  handle_inferior_event, the stop-id has changed, then this indicates
	  that somewhere within handle_inferior_event, a stop was announced to
	  the user.  If this is the case then GDB should not call normal_stop,
	  and we should rely on whoever announced the stop to ensure that we
	  are in a PROMPT_NEEDED state, which means the prompt will be
	  displayed once fetch_inferior_event returns.  And,

	  3. In infcall.c, do two things:

	     (a) In run_inferior_call, after making the inferior call, ensure
	     that either async_disable_stdin or async_enable_stdin is called
	     to put the prompt state, and stdin handling into the correct
	     state based on whether the inferior call completed successfully
	     or not, and

	     (b) In call_thread_fsm::should_stop, call async_enable_stdin
	     rather than changing the prompt state directly.  This isn't
	     strictly necessary, but helped me understand this code more.
	     This async_enable_stdin call is only reached if normal_stop is
	     not going to be called, and replaces the async_enable_stdin call
	     that exists in normal_stop.  Though we could just adjust the
	     prompt state if felt (to me) much easier to understand when I
	     could see this call and the corresponding call in normal_stop.

	With these changes in place now, when the inferior call (from the
	breakpoint condition) fails, infcall.c leaves the prompt state as
	PROMPT_NEEDED, and leaves stdin registered with the event loop.

	Back in fetch_inferior_event GDB notices that the stop-id has changed
	and so avoids calling normal_stop.

	And on return from fetch_inferior_event GDB will display the prompt
	and handle input from stdin.

	As normal_stop is not called the MI problem is solved, and the test
	added in the earlier mentioned commit still passes just fine, so the
	CLI has not regressed.

	[1] https://inbox.sourceware.org/gdb-patches/6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net/

2023-08-03  Tom Tromey  <tom@tromey.com>

	Remove PEI_HEADERS define
	I noticed a few files double-included libcoff.h, and digging deeper I
	found that the PEI_HEADERS define is a sort of external include guard.

	This patch adds include guards to the few files in include/coff that
	were missing one, and then removes the PEI_HEADERS workaround and the
	redundant includes.

	I didn't see anything in these files that indicated that
	double-inclusion would be useful, so it seems to me that this approach
	is ok.

	Tested by rebuilding with --enable-targets=all.

	2023-08-02  Tom Tromey  <tromey@adacore.com>

		* pei-x86_64.c (PEI_HEADERS): Do not define.
		* pei-loongarch64.c (PEI_HEADERS): Do not define.
		* pei-aarch64.c (PEI_HEADERS): Do not define.
		* pe-x86_64.c (PEI_HEADERS): Do not define.
		* pe-aarch64.c (PEI_HEADERS): Do not define.
		* libpei.h (_LIBPEI_H): Add include guard.
		* coff-x86_64.c (PEI_HEADERS): Do not check.
		* coff-loongarch64.c (PEI_HEADERS): Do not check.
		* coff-aarch64.c (PEI_HEADERS): Do not check.

	include/ChangeLog
	2023-08-02  Tom Tromey  <tromey@adacore.com>

		* coff/x86_64.h (COFF_X86_64_H): Add include guard.
		* coff/loongarch64.h (COFF_LOONGARCH64_H): Add include guard.
		* coff/aarch64.h (COFF_AARCH64_H): Add include guard.

2023-08-03  Alan Modra  <amodra@gmail.com>

	readelf sprintf optimisation
	This replaces sprintf and strcat calls with stpcpy, and makes use of
	sprintf return value rather than using strlen, for get_machine_flags.

	decode_NDS32_machine_flags made use of snprintf, which is arguably the
	"correct" way to do things if there can be a buffer overflow.  In this
	case I don't think there can be, the buffer is 1k in size which is at
	least 5 times more than needed.  What's more, snprintf returns the
	count of chars that would be output given no buffer limit, which means
	code like
	  r += snprintf (buf + r, size - r, ...);
	  r += snprintf (buf + r, size - r, ...);
	is just wrong.  There needs to be a check on the return value in order
	to prevent buf + r being out of bounds for the second snprintf call.

	BTW, if you look closely you'll see the return value of the decode
	functions is unused.  I admit to getting a little carried away with
	writing "out = stpcpy (out, ...):" in each of the decode functions and
	didn't notice that until get_machine_flags was trimmed down to a much
	smaller size.  When I did notice, I decided it's not such a bad thing.

		* readelf.c (decode_ARC_machine_flags, decode_ARM_machine_flags),
		(decode_AVR_machine_flags, decode_NDS32_machine_flags),
		(decode_AMDGPU_machine_flags): Use stpcpy and sprintf return
		value.  Return end of string.
		(decode_BLACKFIN_machine_flags, decode_FRV_machine_flags),
		(decode_IA64_machine_flags, decode_LOONGARCH_machine_flags),
		(decode_M68K_machine_flags, decode_MeP_machine_flags),
		(decode_MIPS_machine_flags, decode_MSP430_machine_flags),
		(decode_PARISC_machine_flags, decode_RISCV_machine_flags),
		(decode_RL78_machine_flags, decode_RX_machine_flags),
		(decode_SH_machine_flags, decode_SPARC_machine_flags),
		(decode_V800_machine_flags, decode_V850_machine_flags),
		(decode_Z80_machine_flags): New functions, split out from..
		(get_machine_flags): ..here.  Similarly use stpcpy.

2023-08-03  Alan Modra  <amodra@gmail.com>

	binutils sprintf optimisation
	Avoid the use of sprintf with a "%s" format string, replacing with
	strcpy or stpcpy.  Use sprintf return value rather than a later
	strlen.  Don't use strcat where we can keep track of the end of a
	string output buffer.

		* dlltool.c (look_for_prog): memcpy prefix and strcpy prog_name.
		* dllwrap.c (look_for_prog): Likewise.
		* resrc.c (look_for_default): Likewise.  Add quotes with memmove
		rather than allocating another buffer.
		* size.c (size_number): Use sprintf return value.
		* stabs.c (parse_stab_argtypes): Likewise.
		* windmc.c (write_bin): Likewes, and use stpcpy.
		* wrstabs.c: Similarly throughout.

2023-08-03  Alan Modra  <amodra@gmail.com>

	cris: sprintf optimisation
	Since I was poking at cris-dis.c to avoid the sanitizer warning,
	I figure I might as well make use of stpcpy and sprintf return value
	in other places in this file.

		* cris-dis.c (format_hex): Use sprintf return value.
		(format_reg): Use stpcpy and sprintf return, avoiding strlen.
		(format_sup_reg): Likewise.

2023-08-03  Alan Modra  <amodra@gmail.com>

	arm: sanitizer stringop-overflow
	In function 'memset',
	    inlined from 'create_unwind_entry' at /home/alan/src/binutils-gdb/gas/config/tc-arm.c:27881:3:
	/usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' specified size between 2147483652 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
	   59 |   return __builtin___memset_chk (__dest, __ch, __len,
	      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	   60 |                                  __glibc_objsize0 (__dest));
	      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

		* config/tc-arm.c (create_unwind_entry): Return after bad size,
		and bad opcode count.

2023-08-03  Alan Modra  <amodra@gmail.com>

	xtensa: sprintf sanitizer null destination pointer
		* config/tc-xtensa.c (xtensa_add_config_info): Use auto buffer
		rather than malloc.  Use sprintf return value.

	ld: sprintf sanitizer null destination pointer
		* configure.ac (stpcpy): AC_CHECK_DECLS.
		* sysdep.h (stpcpy): Add fallback declaraion.
		* config.in: Regenerate.
		* configure: Regenerate.
		* emultempl/pe.em (open_dynamic_archive): Use
		stpcpy rather than sprintf plus strlen.
		* emultempl/pep.em (open_dynamic_archive): Likewise.
		* emultempl/xtensaelf.em (elf_xtensa_before_allocation): Use
		auto rather than malloc'd buffer.  Use sprintf count.
		* ldelf.c (ldelf_search_needed): Use memcpy in place of sprintf.
		* pe-dll.c (pe_process_import_defs): Use string already formed
		for alias match rather than recreating.

	gprof: sprintf sanitizer null destination pointer
		* basic_blocks.c (annotate_with_count): Use output of sprintf
		rather than strlen.

	resrc: sprintf sanitizer null destination pointer
		* resrc.c (read_rc_file): Use stpcpy rather than sprintf
		followed by strlen.  Tidy.

	dlltool: sprintf sanitizer null destination pointer
		* dlltool.c (gen_lib_file): Avoid bogus sanitizer error.

2023-08-03  Alan Modra  <amodra@gmail.com>

	wrstabs: sprintf sanitizer null destination pointer
	gcc-2.12 seems to be ignoring __attribute__((__returns_nonnull__))
	on xmalloc.

		* wrstabs.c (stab_method_type): Use stpcpy rather than sprintf
		or strcat.

2023-08-03  Alan Modra  <amodra@gmail.com>

	cris: sprintf sanitizer null destination pointer
	Simplify the sprintf calls, and use sprintf return value.  Older code
	in binutils avoided using the sprintf return count of chars printed,
	because with some older C libraries it wasn't reliable.  Nowadays it
	should be OK to use (and we already use the return value elsewhere).
	sprintf can't return an error status of -1 here.

		* cris-dis.c (format_dec): Avoid sanitizer warning.  Use sprintf
		return value rather than calling strlen.

2023-08-03  Alan Modra  <amodra@gmail.com>

	objdump, nm: sprintf sanitizer null destination pointer
	Seen on Ubuntu 23.04 x86_64-linux using gcc-12.2 and gcc-12.3 with
	CFLAGS="-m32 -g -O2 -fsanitize=address,undefined".

	  CC       objdump.o
	In file included from /usr/include/stdio.h:906,
	                 from /home/alan/src/binutils-gdb/binutils/sysdep.h:24,
	                 from /home/alan/src/binutils-gdb/binutils/objdump.c:51:
	In function 'sprintf',
	    inlined from 'display_utf8' at /home/alan/src/binutils-gdb/binutils/objdump.c:621:14,
	    inlined from 'sanitize_string.part.0' at /home/alan/src/binutils-gdb/binutils/objdump.c:742:11:
	/usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
	   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
	      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	   31 |                                   __glibc_objsize (__s), __fmt,
	      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	   32 |                                   __va_arg_pack ());
	      |                                   ~~~~~~~~~~~~~~~~~
	cc1: all warnings being treated as errors

	The warning is bogus of course.  xmalloc is guaranteed to return
	non-NULL, but apparently this isn't seen in display_utf6.  The same
	doesn't happen with -m64, maybe due to inlining differences, I haven't
	investigated fully.  Easily avoided as we hardly need to use sprintf
	for a single char, or a two char string.

		* objdump.c (display_utf8): Avoid bogus sprintf sanitizer warning.
		Use hex ESC to switch back to default colour.
		(sanitize_string): Comment.  Bump buffer size by one.  Fix overlong
		line.
		* nm.c (display_utf8, sanitize_string): As above.

2023-08-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix possible nullptr dereference in a remote_debug_printf call
	While working on another patch I triggered a segfault from within the
	function remote_target::discard_pending_stop_replies.  Turns out this
	was caused by a cut&paste error introduced in this commit:

	  commit df5ad102009c41ab4dfadbb8cfb8c8b2a02a4f78
	  Date:   Wed Dec 1 09:40:03 2021 -0500

	      gdb, gdbserver: detach fork child when detaching from fork parent

	This commit adds a remote_debug_printf call that was copied from
	earlier in the function, however, the new call wasn't updated to use
	the appropriate local variable.  The local variable that it is using
	might be nullptr, in which case we trigger undefined behaviour, and
	could crash, which is what I was seeing.

	Fixed by updating to use the correct local variable.

2023-08-03  Tom de Vries  <tdevries@suse.de>

	 Fix Wlto-type-mismatch in opcodes/ft32-dis.c

2023-08-03  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add support for 'Zvfh' and 'Zvfhmin'
	This commit adds support for recently ratified vector FP16 extensions:
	'Zvfh' and 'Zvfhmin'.

	This is based on:
	<https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point>
	<https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfh-vector-extension-for-half-precision-floating-point>

	Despite not having any new instructions, it will be necessary since those
	extensions are already implemented in GCC.

	Note that however, in this commit, following dependencies are implemented.

	1.  'Zvfhmin' -> 'Zve32f'
	2.  'Zvfh' -> 'Zvfhmin' (not 'Zvfh' -> 'Zve32f' as in the documentation)
	3.  'Zvfh' -> 'Zfhmin'

	This is because the instructions and configurations supported by the
	'Zvfh' extension is a strict superset of the 'Zvfhmin' extension and
	'Zvfh' -> 'Zve32f' dependency is indirectly derived from that fact.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add implications
		related to 'Zvfh' and 'Zvfhmin' extensions.
		(riscv_supported_std_z_ext) Add 'Zvfh' and 'Zvfhmin' to the list.

2023-08-03  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Imply 'Zicsr' from 'Zve32x'
	Further clarification is made so that 'Zve32x' implies 'Zicsr' (the same
	implication is already implemented in LLVM).

	See related issue (the author raised) on the vector specification:
	<https://github.com/riscv/riscv-v-spec/issues/908>
	and its resolution:
	<https://github.com/riscv/riscv-v-spec/issues/909>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add 'Zve32x' -> 'Zicsr'.

2023-08-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-02  Tom de Vries  <tdevries@suse.de>

	[gdb] Initialize main_thread_id earlier
	I wrote a patch using is_main_thread (), and found it returning false in the
	main thread due to main_thread_id not being initialized yet.

	Initialization currently takes place in _initialize_run_on_main_thread, but
	that's too late for earlier uses.

	Fix this by initializing, either:
	- when entering main, or
	- on an earlier first use.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-02  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Disable DAP for python <= 3.5
	DAP requires python module typing, which is supported starting python 3.5.

	Make this formal by:
	- disabling the dap interpreter for python version < 3.5
	- returning 0 in allow_dap_tests for python version < 3.5

	Approved-By: Tom Tromey <tom@tromey.com>

	PR dap/30708
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708

2023-08-02  Tom Tromey  <tromey@adacore.com>

	Avoid failures in fixed_points.exp with older GCC
	Tom de Vries pointed out that my recent change to fixed_points.exp
	failed with older versions of GCC.  This patch fixes the problem by
	skipping the new test in this situation.

2023-08-02  Sam James  <sam@gentoo.org>

	Revert "2.41 Release sources"
	This reverts commit 675b9d612cc59446e84e2c6d89b45500cb603a8d.

	See https://sourceware.org/pipermail/binutils/2023-August/128761.html.

2023-08-02  Nick Clifton  <nickc@redhat.com>

	2.41 Release sources

2023-08-02  Khem Raj  <raj.khem@gmail.com>

	gprofng: Fix build with 64bit file offset on 32bit machines
	gprofng/ChangeLog
	2023-07-31  Khem Raj <raj.khem@gmail.com>

	* libcollector/iotrace.c: Define open64, fgetpos64, and fsetpos64
	  only when __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not
	  defined.

2023-08-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-08-01  Alan Modra  <amodra@gmail.com>

	Don't declare xmalloc and others in ldmisc.h
		* ldmisc.h (xmalloc, xrealloc, xexit, yyerror): Don't declare.
		* emultempl/pdp11.em: Include libiberty.h.
		* emultempl/ticoff.em: Likewise.
		* emultempl/vms.em: Likewise.
		* ldctor.c: Likewise.
		* ldelfgen.c: Likewise.
		* ldgram.y: Likewise.
		(yyerror): Prototype and make static.

2023-08-01  Alan Modra  <amodra@gmail.com>

	Don't declare xmalloc or xrealloc in bucomm.h
	It's better to include the proper header, which has declarations with
	various attributes.  Commit 096aefc040 in 1994 introduced this wart.

		* bucomm.h (xmalloc, xrealloc): Delete declaration.
		* od-macho.c: Include libiberty.h.
		* od-xcoff.c: Include libiberty.h.

2023-08-01  Alan Modra  <amodra@gmail.com>

	Regen ld/configure
	For commit 3d05c80b5dc4.

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Implement DAP "source" request
	This implements the DAP "source" request.  I renamed the
	"loadedSources" function from "sources" to "loaded_sources" to avoid
	any confusion.  I also moved the loadedSources test to the new
	sources.exp.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30691

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Handle Source in DAP breakpointLocations
	This changes the DAP breakpointLocations request to accept a Source
	and to decode it properly.

	Introduce sourceReference handling in DAP
	This changes the gdb DAP implementation to emit a real
	sourceReference, rather than emitting 0.  Sources are tracked in some
	maps in sources.py, and a new helper function is introduced to compute
	the "Source" object that can be sent to the client.

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Don't supply DAP 'path' for non-file shared libraries
	The DAP 'module' event may include a 'path' component.  I noticed that
	this is supplied even when the module in question does not come from a
	file.

	This patch only emits this field when the objfile corresponds to a
	real file.

	No test case, because I wasn't sure how to write a portable one.
	However, it's clear from gdb.log on Linux:

	{"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21}

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Implement ValueFormat for DAP
	This patch implements ValueFormat for DAP.  Currently this only means
	supporting "hex".

	Note that StackFrameFormat is defined to have many more options, but
	none are currently recognized.  It isn't entirely clear how these
	should be handled.  I'll file a new gdb bug for this, and perhaps an
	upstream DAP bug as well.

	New in v2:
	- I realized that the "hover" context was broken, and furthermore
	  that we only had tests for "hover" failing, not for it succeeding.
	  This version fixes the oversight and adds a test.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30469

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Respect supportsMemoryReferences in DAP
	I noticed that the support for memoryReference in the "variables"
	output is gated on the client "supportsMemoryReferences" capability.

	This patch implements this and makes some other changes to the DAP
	memory reference code:

	* Remove the memoryReference special case from _SetResult.
	  Upstream DAP fixed this oversight in response to
	  https://github.com/microsoft/debug-adapter-protocol/issues/414

	* Don't use the address of a variable as its memoryReference -- only
	  emit this for pointer types.  There's no spec support for the
	  previous approach.

	* Use strip_typedefs to handle typedefs of pointers.

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Add DAP support for C++ exceptions
	This adds DAP support for the various C++ exception-catching
	operations.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Implement DAP 'terminated' event
	This implements the DAP 'terminated' event.  Vladimir Makaev noticed
	that VSCode will not report the debug session as over unless this is
	sent.

	It's not completely clear when exactly this event ought to be sent.
	Here I've done it when the inferior exits.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30681

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Do not send "new breakpoint" event when breakpoint is set
	When the DAP client sets a breakpoint, gdb currently sends a "new
	breakpoint" event.  However, Vladimir Makaev discovered that this
	causes VSCode to think there are two breakpoints.

	This patch changes gdb to suppress the event in this case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Move DAP breakpoint event code to breakpoint.py
	A subsequent patch will add the ability to suppress breakpoint events
	to DAP.  My first attempt at this ended up with recurse imports,
	causing Python failures.  So, this patch moves all the DAP breakpoint
	event code to breakpoint.py in preparation for the change.

	I've renamed breakpoint_descriptor here as well, because it can now be
	private to breakpoint.py.

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Full paths in DAP stackTrace responses
	Vladimir Makaev noticed that, in some cases, a DAP stackTrace response
	would include a relative path name for the "path" component.

	This patch changes the frame decorator code to add a new DAP-specific
	decorator, and changes the DAP entry point to frame filters to use it.
	This decorator prefers the symtab's full name, and does not fall back
	to the solib's name.

	I'm not entirely happy with this patch, because if a user frame filter
	uses FrameDecorator, it may still do the wrong thing.  It would be
	better to have frame filters return symtab-like objects instead, or to
	have a separate method to return the full path to the source file.

	I also tend to think that the solib fallback behavior of
	FrameDecorator is a mistake.  If this is ever needed, it seems to me
	that it should be a separate method.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Add "cwd" parameter to DAP launch request
	This adds the "cwd" parameter to the DAP launch request.

	This came up here:
	    https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90
	... and seemed like a good idea.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-08-01  Tom Tromey  <tromey@adacore.com>

	Refactor dap_launch
	This patch refactors dap_launch to make it more extensible and also
	easier to use.

	Rename private member of FrameDecorator
	In Python, a member name starting with "__" is specially handled to
	make it "more private" to the class -- it isn't truly private, but it
	is renamed to make it less likely to be reused by mistake.  This patch
	ensures that this is done for the private method of FrameDecorator.

2023-08-01  Simon Farre  <simon.farre.cx@gmail.com>

	Add thread exited event
	Reports a thread exit according to the DAP spec:
	https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread

	This patch requires the ThreadExitedEvent to be checked in,
	in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html

	Formatted correctly using black

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30474

	Approved-By: Tom Tromey <tom@tromey.com>

2023-08-01  Nick Clifton  <nickc@redhat.com>

	Fix "--only-keep-debug for ELF relocatables" binutils test for compilers which add .debug_macro sections to object files.
	  PR 30699
	  * binutils/testsuite/binutils-all/objcopy.exp (keep_debug_symbols_for_elf_relocatable): Do not add sections containing the string "debug_" to the list of non-debug sections.

2023-08-01  Jan Beulich  <jbeulich@suse.com>

	gas: rework timestamp preservation on doc/asconfig.texi
	PR 28909

	Sadly "cp -p", doing more than just preserving the time stamp, can fail
	e.g. upon trying to preserve ownership (which we don't care about), as
	can be observed on e.g. Cygwin. Replace the use of -p by a use of touch,
	this way also only preserving modification time.

2023-08-01  Nick Clifton  <nickc@redhat.com>

	Add note to check that all changes have been pushed before creating the source tarballs

2023-08-01  Sam James  <sam@gentoo.org>

	ld: Fix test failures with --enable-textrel-check=error

2023-08-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: create a list of available views
	In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
	the output of gp-display-text to display the data.
	gp-display-text did not report available views.

	gprofng/ChangeLog
	2023-07-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Command.cc: Add commands for gprofng GUI.
		* src/gprofng.rc: Set defaults for gprofng GUI.

2023-08-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set TSAN_OPTIONS by default to history_size=7
	I build gdb with -fsanitize=thread and ran the testsuite, and ran into the
	case that a race is detected, but we see the full stack trace only for one of
	the two accesses, and the other one is showing "failed to restore the stack".

	Try to prevent this by setting ThreadSanitizer flag history_size [1] to the
	maximum (7) by default, as suggested here [2].

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	[1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags
	[2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE

2023-07-31  Tom Tromey  <tromey@adacore.com>

	Fix bug in fixed-point handling
	Alexandre Oliva found a bug in gdb's handling of fixed-point -- a
	certain Ada fixed-point type would be misintepreted.  The bug was that
	the DW_AT_small looked like:

	 <1><13cd>: Abbrev Number: 16 (DW_TAG_constant)
	    <13ce>   DW_AT_GNU_numerator: 1
	    <13cf>   DW_AT_GNU_denominator: 0x8000000000000000

	... but gdb interpreted the denominator as a negative value.

2023-07-31  Sam James  <sam@gentoo.org>

	ld: fix typo in --enable-warn-rwx-segments help

2023-07-31  Lancelot Six  <lancelot.six@amd.com>

	gdb/amdgpu: Fix debugging multiple inferiors using the ROCm runtime
	When debugging a multi-process application where a parent spawns
	multiple child processes using the ROCm runtime, I see the following
	assertion failure:

	    ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
	    A problem internal to GDB has been detected,
	    further debugging may prove unreliable.
	    ----- Backtrace -----
	    0x556e9a318540 gdb_internal_backtrace_1
	            ../../gdb/bt-utils.c:122
	    0x556e9a318540 _Z22gdb_internal_backtracev
	            ../../gdb/bt-utils.c:168
	    0x556e9a730224 internal_vproblem
	            ../../gdb/utils.c:396
	    0x556e9a7304e0 _Z15internal_verrorPKciS0_P13__va_list_tag
	            ../../gdb/utils.c:476
	    0x556e9a87aeb4 _Z18internal_error_locPKciS0_z
	            ../../gdbsupport/errors.cc:58
	    0x556e9a29f446 process_one_event
	            ../../gdb/amd-dbgapi-target.c:1071
	    0x556e9a29f446 process_event_queue
	            ../../gdb/amd-dbgapi-target.c:1156
	    0x556e9a29faf2 _ZN17amd_dbgapi_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
	            ../../gdb/amd-dbgapi-target.c:1262
	    0x556e9a6b0965 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
	            ../../gdb/target.c:2586
	    0x556e9a4c221f do_target_wait_1
	            ../../gdb/infrun.c:3876
	    0x556e9a4d8489 operator()
	            ../../gdb/infrun.c:3935
	    0x556e9a4d8489 do_target_wait
	            ../../gdb/infrun.c:3964
	    0x556e9a4d8489 _Z20fetch_inferior_eventv
	            ../../gdb/infrun.c:4365
	    0x556e9a87b915 gdb_wait_for_event
	            ../../gdbsupport/event-loop.cc:694
	    0x556e9a87c3a9 gdb_wait_for_event
	            ../../gdbsupport/event-loop.cc:593
	    0x556e9a87c3a9 _Z16gdb_do_one_eventi
	            ../../gdbsupport/event-loop.cc:217
	    0x556e9a521689 start_event_loop
	            ../../gdb/main.c:412
	    0x556e9a521689 captured_command_loop
	            ../../gdb/main.c:476
	    0x556e9a523c04 captured_main
	            ../../gdb/main.c:1320
	    0x556e9a523c04 _Z8gdb_mainP18captured_main_args
	            ../../gdb/main.c:1339
	    0x556e9a24b1bf main
	            ../../gdb/gdb.c:32
	    ---------------------
	    ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
	    A problem internal to GDB has been detected,

	Before diving into why this error appears, let's explore how things are
	expected to work in normal circumstances.  When a process being debugged
	starts using the ROCm runtime, the following happens:

	- The runtime registers itself to the driver.
	- The driver creates a "runtime loaded" event and notifies the debugger
	  that a new event is available by writing to a file descriptor which is
	  registered in GDB's main event loop.
	- GDB core calls the callback associated with this file descriptor
	  (dbgapi_notifier_handler).  Because the amd-dbgapi-target is not
	  pushed at this point, the handler pulls the "runtime loaded" event
	  from the driver (this is the only event which can be available at this
	  point) and eventually pushes the amd-dbgapi-target on the inferior's
	  target stack.

	In a nutshell, this is the expected AMDGPU runtime activation process.

	From there, when new events are available regarding the GPU threads, the
	same file descriptor is written to.  The callback sees that the
	amd-dbgapi-target is pushed so marks the amd_dbgapi_async_event_handler.
	This will later cause amd_dbgapi_target::wait to be called.  The wait
	method pulls all the available events from the driver and handles them.
	The wait method returns the information conveyed by the first event, the
	other events are cached for later calls of the wait method.

	Note that because we are under the wait method, we know that the
	amd-dbgapi-target is pushed on the inferior target stack.  This implies
	that the runtime activation event has been seen already.  As a
	consequence, we cannot receive another event indicating that the runtime
	gets activated.  This is what the failing assertion checks.

	In the case when we have multiple inferiors however, there is a flaw in
	what have been described above.  If one inferior (let's call it inferior
	1) already has the amd-dbgapi-target pushed to its target stack and
	another inferior (inferior 2) activates the ROCm runtime, here is what
	can happen:

	- The driver creates the runtime activation for inferior 2 and writes to
	  the associated file descriptor.
	- GDB has inferior 1 selected and calls target_wait for some reason.
	- This prompts amd_dbgapi_target::wait to be called.  The method pulls
	  all events from the driver, including the runtime activation event for
	  inferior 2, leading to the assertion failure.

	The fix for this problem is simple.  To avoid such problem, we need to
	make sure that amd_dbgapi_target::wait only pulls events for the current
	inferior from the driver.  This is what this patch implements.

	This patch also includes a testcase which could fail before this patch.

	This patch has been tested on a system with multiple GPUs which had more
	chances to reproduce the original bug.  It has also been tested on top
	of the downstream ROCgdb port which has more AMDGPU related tests.  The
	testcase has been tested with `make check check-read1 check-readmore`.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-31  Lancelot Six  <lancelot.six@amd.com>

	gdb/testsuite/rocm: Add the hip_devices_support_debug_multi_process proc
	It is not possible to debug multiple processes simultaneously on all
	generations of AMDGPU devices.  As some tests will need to debug
	multiple inferiors using AMDGPU devices, we need to ensure that all
	devices available have the required capability.  Failing to do so would
	result in GDB not being able to debug all inferiors properly.

	Add the hip_devices_support_debug_multi_process helper function used to
	ensure that all devices available can debug multiple processes.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-31  Tom Tromey  <tromey@adacore.com>

	Set PYTHONMALLOC in the test suite
	Setting PYTHONMALLOC helped me locate an earlier bug.  It seems to me
	that there aren't big downsides to always setting this during testing,
	and it might help find other bugs in the future.

2023-07-31  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: opcodes: fix regression in BPF disassembler
	This patch fixes a regression recently introduced in the BPF
	disassembler, that was assuming an abfd was always available in
	info->section->owner.  Apparently this is not so in GDB, and therefore
	https://sourceware.org/bugzilla/show_bug.cgi?id=30705.

	Tested in bpf-unkonwn-none.

	opcodes/ChangeLog:

	2023-07-31  Jose E. Marchesi  <jose.marchesi@oracle.com>

		PR 30705
		* bpf-dis.c (print_insn_bpf): Check that info->section->owner is
		actually available before using it.

2023-07-31  Nick Clifton  <nickc@redhat.com>

	Updated Spanish translation for the gprof directory

2023-07-31  Tom Tromey  <tromey@adacore.com>

	Restore previous sigmask in gdb.block_signals
	Tom de Vries found a bug where, sometimes, a SIGCHLD would be
	delivered to a non-main thread, wreaking havoc.

	The problem is that gdb.block_signals after first blocking a set of
	signals, then unblocked the same set rather than restoring the initial
	situation.  This function being called from the DAP thread lead to
	SIGCHLD being unblocked there.

	This patch fixes the problem by restoring the previous set of signals
	instead.

	Tested-by: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30680

2023-07-31  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Fix typo in the test case name
	gas/ChangeLog:

		* testsuite/gas/riscv/rouding-fail.s: Moved to...
		* testsuite/gas/riscv/rounding-fail.s: ...here.
		* testsuite/gas/riscv/rouding-fail.d: Moved to...
		* testsuite/gas/riscv/rounding-fail.d: ...here.
		* testsuite/gas/riscv/rouding-fail.l: Moved to...
		* testsuite/gas/riscv/rounding-fail.l: ...here.

2023-07-31  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: sim: do not overflow instruction immediates in tests
	This patch fixes some instructions in the BPF tests that overflow the
	signed immediates.  Note that this happened to work before by chance,
	as GAS would silently truncate.

	Tested in bpf-unknown-none.

2023-07-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-31  Joel Brobecker  <brobecker@adacore.com>

	GDB Global Maintainer update (3 maintainers stepping down)
	Doug Evans, Yao Qi and myself are stepping down as GDB Global
	Maintainers. This commit therefore moves our entries to the
	"Past Maintainers" section.

	I've also removed myself as Ada maintainer, as well as MIPS
	authorized committer.

2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: include, bfd, opcodes: add EF_BPF_CPUVER ELF header flags
	This patch adds support for EF_BPF_CPUVER bits in the ELF
	machine-dependent header flags.  These bits encode the BPF CPU
	version for which the object file has been compiled for.

	The BPF assembler is updated so it annotates the object files it
	generates with these bits.

	The BPF disassembler is updated so it honors EF_BPF_CPUVER to use the
	appropriate ISA version if the user didn't specify an explicit ISA
	version in the command line.  Note that a value of zero in
	EF_BPF_CPUVER is interpreted by the disassembler as "use the later
	supported version" (the BPF CPU versions start with v1.)

	The readelf utility is updated to pretty print EF_BPF_CPUVER when it
	prints out the ELF header:

	   $ readelf -h a.out
	   ELF Header:
	     ...
	     Flags:                             0x4, CPU Version: 4

	Tested in bpf-unknown-none.

	include/ChangeLog:

	2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* elf/bpf.h (EF_BPF_CPUVER): Define.
		* opcode/bpf.h (BPF_XBPF): Change from 0xf to 0xff so it fits in
		EF_BPF_CPUVER.

	binutils/ChangeLog:

	2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* readelf.c (get_machine_flags): Recognize and pretty print BPF
		machine flags.

	opcodes/ChangeLog:

	2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-dis.c: Initialize asm_bpf_version to -1.
		(print_insn_bpf): Set BPF ISA version from the cpu version ELF
		header flags if no explicit version set in the command line.
		* disassemble.c (disassemble_init_for_target): Remove unused code.

	gas/ChangeLog:

	2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* config/tc-bpf.h (elf_tc_final_processing): Define.
		* config/tc-bpf.c (bpf_elf_final_processing): New function.

2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: add field overflow checking to the BPF assembler
	This patch makes the BPF assembler to throughfully check for overflow
	in immediates.  This includes relaxed instructions.

	Tested in bpf-unknown-none.

	gas/ChangeLog:

	2023-07-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* config/tc-bpf.c (signed_overflow): Copy function from
		tc-aarch64.c.
		(encode_insn): Check for overflow in constant immediates.
		(add_relaxed_insn): Pass relax argument to encode_insn.
		(add_fixed_insn): Likewise.
		* testsuite/gas/bpf/disp16-overflow.d: New file.
		* testsuite/gas/bpf/disp16-overflow.s: Likewise.
		* testsuite/gas/bpf/disp16-overflow.l: Likewise.
		* testsuite/gas/bpf/disp32-overflow.d: Likewise.
		* testsuite/gas/bpf/disp32-overflow.s: Likewise.
		* testsuite/gas/bpf/disp32-overflow.l: Likewise.
		* testsuite/gas/bpf/imm32-overflow.d: Likewise.
		* testsuite/gas/bpf/imm32-overflow.s: Likewise.
		* testsuite/gas/bpf/imm32-overflow.l: Likewise.
		* testsuite/gas/bpf/offset16-overflow.d: Likewise.
		* testsuite/gas/bpf/offset16-overflow.s: Likewise.
		* testsuite/gas/bpf/offset16-overflow.l: Likewise.
		* testsuite/gas/bpf/disp16-overflow-relax.d: Likewise.
		* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
		* testsuite/gas/bpf/disp16-overflow-relax.s: Likewise.
		* testsuite/gas/bpf/jump-relax-jump-be.d: New file.
		* testsuite/gas/bpf/bpf.exp: Run new tests.

2023-07-30  Nick Clifton  <nickc@redhat.com>

	Update how to make a release document after the 2.41 release

2023-07-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: remove spurious comment from tc-bpf.c

2023-07-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: support relaxation of V4 jump instructions
	The BPF jump-always instruction (JA), like all other jump instructions
	in the ISA, get a signed 16-bit displacement target argument denoted
	in number of 64-bit words minus one.  This can sometimes be overflown.

	The BPF V4 ISA thus introduced support for a jump-always
	instruction (JAL) that gets a signed 32-bit displacement instead.

	This patch makes the BPF assembler to perform the following
	relaxations when the disp16 field gets overflown, unless the option
	-mno-relax is specified:

	  JA disp16  -> JAL disp32
	  Jxx disp16 -> Jxx +1; JA +1; JAL disp32

	Documentation and tests added.
	Tested in bpf-unknown-none.

	gas/ChangeLog:

	2023-07-28  Jose E. Marchesi  <jose.marchesi@oracle.com>

		PR gas/30690
		* config/tc-bpf.c (struct bpf_insn): Add fields is_relaxable and
		relaxed_exp.
		(enum options): Add OPTION_NO_RELAX.
		(md_longopts): Likewise for -mno-relax.
		(do_relax): New global.
		(md_parse_option): Handle OPTION_NO_RELAX.
		(RELAX_BRANCH_ENCODE): Define.
		(RELAX_BRANCH_P): Likewise.
		(RELAX_BRANCH_LENGTH): Likewise.
		(RELAX_BRANCH_CONST): Likewise.
		(RELAX_BRANCH_UNCOND): Likewise.
		(relaxed_branch_length): New function.
		(md_estimate_size_before_relax): Likewise.
		(read_insn_word): Likewise.
		(encode_int16): Likewise.
		(encode_int32): Likewise.
		(write_insn_bytes): Likewise.
		(md_convert_frag): Likewise.
		(encode_insn): Likewise.
		(install_insn_fixups): Likewise.
		(add_fixed_insn): Likewise.
		(add_relaxed_insn): Likewise.
		(md_assemble): Move instruction encoding logic to the above
		new functions.
		* testsuite/gas/bpf/jump-relax-ja.d: New test.
		* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
		* testsuite/gas/bpf/jump-relax-ja.s: And corresponding source.
		* testsuite/gas/bpf/jump-relax-jump.d: New test.
		* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
		* testsuite/gas/bpf/jump-relax-jump.s: And corresponding source.
		* testsuite/gas/bpf/bpf.exp: Run new tests.
		* doc/c-bpf.texi (BPF Options): Document -mno-relax.

2023-07-28  Tom de Vries  <tdevries@suse.de>

	[gdb] Rename variable main_thread to main_thread_id
	I noticed that the variable main_thread:
	...
	/* The main thread.  */

	static std::thread::id main_thread;
	...
	has a confusing name and corresponding comment, because it doesn't contain the
	main thread, but rather the main thread's std::thread::id.

	Fix this by renaming to main_thread_id.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-28  Tom Tromey  <tromey@adacore.com>

	Re-acquire GIL earlier in gdbpy_parse_and_eval
	Tom de Vries filed a bug about an intermittent gdb DAP failure -- and
	coincidentally, at the same time, Alexandra Hájková sent email about a
	somewhat similar failure.

	After looking into this for a while (with no results) using ASan and
	valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug
	instantly.

	The problem is that gdbpy_parse_and_eval releases the GIL while
	calling parse_and_eval, but fails to re-acquire it before calling
	value_to_value_object.  This is easily fixed by introducing a new
	scope.

	I wonder whether the test suite should unconditionally set
	PYTHONMALLOC=malloc_debug.

	Tested-by: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Tom de Vries <tdevries@suse.de>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686

2023-07-28  Jan Beulich  <jbeulich@suse.com>

	gas: amend X_unsigned uses
	PR gas/30688

	X_unsigned being clear does not indicate a negative number; it merely
	indicates a signed one (whose sign may still be clear). Amend two uses
	by an actual value check.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: Support `-gnuabi64' target triplet suffix for 64-bit Linux targets
	Make the n64 ABI the default for 64-bit Linux targets specified with
	`-gnuabi64' suffix included in the target triplet, for configurations
	such as the Debian mips64el and mips64r6el ports.  Adjust testsuite
	configuration accordingly.

	There are the following regressions with the new target triplet:

	mips64-linux-gnuabi64  +FAIL: readelf -S bintest
	mips64-linux-gnuabi64  +FAIL: MIPS reloc estimation 1
	mips64el-linux-gnuabi64  +FAIL: readelf -S bintest
	mips64el-linux-gnuabi64  +FAIL: MIPS reloc estimation 1

	The `readelf' issue comes from a difference in section headers produced
	that the `binutils/testsuite/binutils-all/readelf.s-64' pattern template
	does not match.  While there has been a precedent it does not appear to
	me that there is a clear advantage from adding more and more variations
	to the template rather than forking the existing template into multiple
	ones for a more exact match.  So this is best deferred to a separate
	discussion.

	The MIPS reloc estimation issue is an actual bug in `objdump', which
	discards a number of trailing entries from output here for n64 composed
	relocations:

	DYNAMIC RELOCATION RECORDS
	OFFSET           TYPE              VALUE
	0000000000000000 R_MIPS_NONE       *ABS*
	0000000000000000 R_MIPS_NONE       *ABS*

	and consequently `ld/testsuite/ld-mips-elf/reloc-estimate-1.d' does not
	match even though ELF output produced is correct according to `readelf':

	Relocation section '.rel.dyn' at offset 0x10400 contains 2 entries:
	  Offset          Info           Type           Sym. Value    Sym. Name
	000000000000  000000000000 R_MIPS_NONE
	                    Type2: R_MIPS_NONE
	                    Type3: R_MIPS_NONE
	000000010000  000300001203 R_MIPS_REL32      0000000000010010 foo@@V2
	                    Type2: R_MIPS_64
	                    Type3: R_MIPS_NONE

	As a genuine bug this has to be handled separately.

	Co-Authored by: Maciej W. Rozycki <macro@orcam.me.uk>

		bfd/
		* config.bfd: Add `mips64*el-*-linux*-gnuabi64' and
		`mips64*-*-linux*-gnuabi64' targets.

		binutils/
		* testsuite/binutils-all/mips/mips.exp: Handle `*-*-*-gnuabi64'
		targets.
		* testsuite/binutils-all/objcopy.exp: Handle
		`mips64*-*-*-gnuabi64' targets.
		* testsuite/binutils-all/remove-relocs-01.d: Likewise.
		* testsuite/binutils-all/remove-relocs-04.d: Likewise.
		* testsuite/binutils-all/remove-relocs-05.d: Likewise.
		* testsuite/binutils-all/remove-relocs-06.d: Likewise.

		gas/
		* configure.ac: Handle `mips64*-linux-gnuabi64' targets.
		* configure: Regenerate.
		* testsuite/gas/mips/compact-eh-eb-7.d: Handle
		`mips64*-*-*-gnuabi64' targets.
		* testsuite/gas/mips/compact-eh-el-7.d: Likewise.

		ld/
		* configure.tgt: Add `mips64*el-*-linux-gnuabi64' and
		`mips64*-*-linux-gnuabi64' targets.
		* testsuite/ld-undefined/undefined.exp: Handle
		`mips64*-*-*-gnuabi64' targets.
		* testsuite/ld-mips-elf/attr-gnu-4-10.d: Likewise.
		* testsuite/ld-mips-elf/compact-eh6.d: Likewise.
		* testsuite/ld-mips-elf/mips-elf.exp: Handle `*-*-*-gnuabi64'
		targets.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/GAS/testsuite: Fix n64 compact EH failures
	Expect a `.MIPS.options' section alternatively to `.reginfo' and ignore
	contents of either as irrelevant for all the affected compact EH tests,
	removing these regressions:

	mips64-openbsd  -FAIL: Compact EH EB #1 with personality ID and FDE data
	mips64-openbsd  -FAIL: Compact EH EB #2 with personality routine and FDE data
	mips64-openbsd  -FAIL: Compact EH EB #3 with personality id and large FDE data
	mips64-openbsd  -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA
	mips64-openbsd  -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA
	mips64-openbsd  -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data
	mips64-openbsd  -FAIL: Compact EH EL #1 with personality ID and FDE data
	mips64-openbsd  -FAIL: Compact EH EL #2 with personality routine and FDE data
	mips64-openbsd  -FAIL: Compact EH EL #3 with personality id and large FDE data
	mips64-openbsd  -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA
	mips64-openbsd  -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA
	mips64-openbsd  -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data
	mips64el-openbsd  -FAIL: Compact EH EB #1 with personality ID and FDE data
	mips64el-openbsd  -FAIL: Compact EH EB #2 with personality routine and FDE data
	mips64el-openbsd  -FAIL: Compact EH EB #3 with personality id and large FDE data
	mips64el-openbsd  -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA
	mips64el-openbsd  -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA
	mips64el-openbsd  -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data
	mips64el-openbsd  -FAIL: Compact EH EL #1 with personality ID and FDE data
	mips64el-openbsd  -FAIL: Compact EH EL #2 with personality routine and FDE data
	mips64el-openbsd  -FAIL: Compact EH EL #3 with personality id and large FDE data
	mips64el-openbsd  -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA
	mips64el-openbsd  -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA
	mips64el-openbsd  -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		gas/
		* testsuite/gas/mips/compact-eh-eb-1.d: Accept `.MIPS.options'
		section as an alternative to `.reginfo' and ignore contents of
		either.
		* testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-1.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-6.d: Likewise.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	testsuite: Handle composed R_MIPS_NONE relocations
	MIPS n64 ABI has a peculiarity where all relocations are composed of
	three, with subsequent relocation types set to R_MIPS_NONE if further
	calculation is not required.  Example output produced by `readelf' and
	`objdump' for such relocations is:

	  Offset          Info           Type           Sym. Value    Sym. Name + Addend
	000000000000  000800000002 R_MIPS_32         0000000000000000 foo + 0
	                    Type2: R_MIPS_NONE
	                    Type3: R_MIPS_NONE

	and:

	OFFSET           TYPE              VALUE
	0000000000000000 R_MIPS_32         foo
	0000000000000000 R_MIPS_NONE       *ABS*
	0000000000000000 R_MIPS_NONE       *ABS*

	respectively.  The presence of these extra R_MIPS_NONE entries is not
	relevant for generic or even some MIPS tests, so optionally match them
	with the respective dump patterns, also discarding `xfail' annotation
	for MIPS/OpenBSD targets from gas/elf/missing-build-notes.d, removing
	these regressions:

	mips64-openbsd  -FAIL: readelf -r bintest
	mips64-openbsd  -FAIL: forward expression
	mips64-openbsd  -FAIL: assignment tests
	mips64-openbsd  -FAIL: gas/all/none
	mips64-openbsd  -XFAIL: gas/elf/missing-build-notes
	mips64-openbsd  -FAIL: macro test 2
	mips64-openbsd  -FAIL: macro irp
	mips64-openbsd  -FAIL: macro rept
	mips64-openbsd  -FAIL: nested irp/irpc/rept
	mips64-openbsd  -FAIL: macro vararg
	mips64-openbsd  -FAIL: mips jalx
	mips64-openbsd  -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
	mips64el-openbsd  -FAIL: readelf -r bintest
	mips64el-openbsd  -FAIL: forward expression
	mips64el-openbsd  -FAIL: assignment tests
	mips64el-openbsd  -FAIL: gas/all/none
	mips64el-openbsd  -XFAIL: gas/elf/missing-build-notes
	mips64el-openbsd  -FAIL: macro test 2
	mips64el-openbsd  -FAIL: macro irp
	mips64el-openbsd  -FAIL: macro rept
	mips64el-openbsd  -FAIL: nested irp/irpc/rept
	mips64el-openbsd  -FAIL: macro vararg
	mips64el-openbsd  -FAIL: mips jalx
	mips64el-openbsd  -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		binutils/
		* testsuite/binutils-all/readelf.r-64: Optionally match extra
		R_MIPS_NONE pairs.

		gas/
		* testsuite/gas/all/assign.d: Optionally match extra
		R_MIPS_NONE pairs.
		* testsuite/gas/all/fwdexp.d: Likewise.
		* testsuite/gas/all/none.d: Likewise.
		* testsuite/gas/macros/irp.d: Likewise.
		* testsuite/gas/macros/repeat.d: Likewise.
		* testsuite/gas/macros/rept.d: Likewise.
		* testsuite/gas/macros/test2.d: Likewise.
		* testsuite/gas/macros/vararg.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-1.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-1.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-6.d: Likewise.
		* testsuite/gas/mips/loongson-2f-3.d: Likewise.
		* testsuite/gas/mips/mips-jalx.d: Likewise.
		* testsuite/gas/elf/missing-build-notes.d: Likewise.  Remove
		the `xfail' tag.

		ld/
		* testsuite/ld-mips-elf/reloc-estimate-1.d: Optionally match
		extra R_MIPS_NONE pairs.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/testsuite: Handle 64-bit addresses
	Several MIPS test cases are suitable for the n64 ABI if not for the
	extra leading zeros or spaces in addresses not handled by dump patterns.
	Match the characters then, removing these regressions:

	mips64-openbsd  -FAIL: .set arch=FOO
	mips64-openbsd  -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue
	mips64-openbsd  -FAIL: MIPS DSP ASE for MIPS64
	mips64-openbsd  -FAIL: gas/mips/align2
	mips64-openbsd  -FAIL: gas/mips/align2-el
	mips64-openbsd  -FAIL: Locally-resolvable PC-relative code references
	mips64-openbsd  -FAIL: MIPS jalx-1
	mips64-openbsd  -FAIL: JAL overflow 2
	mips64el-openbsd  -FAIL: .set arch=FOO
	mips64el-openbsd  -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue
	mips64el-openbsd  -FAIL: MIPS DSP ASE for MIPS64
	mips64el-openbsd  -FAIL: gas/mips/align2
	mips64el-openbsd  -FAIL: gas/mips/align2-el
	mips64el-openbsd  -FAIL: Locally-resolvable PC-relative code references
	mips64el-openbsd  -FAIL: MIPS jalx-1
	mips64el-openbsd  -FAIL: JAL overflow 2

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		gas/
		* testsuite/gas/mips/align2-el.d: Match extra leading zeros
		with addresses.
		* testsuite/gas/mips/align2.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-1.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-1.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-2.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-3.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-4.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-5.d: Likewise.
		* testsuite/gas/mips/compact-eh-el-6.d: Likewise.
		* testsuite/gas/mips/loongson-2f-2.d: Likewise.
		* testsuite/gas/mips/loongson-2f-3.d: Likewise.
		* testsuite/gas/mips/mips-jalx.d: Likewise.
		* testsuite/gas/mips/mips64-dsp.d: Likewise.
		* testsuite/gas/mips/pcrel-1.d: Likewise.
		* testsuite/gas/mips/set-arch.d: Likewise.

		ld/
		* testsuite/ld-mips-elf/jaloverflow-2.d: Match extra leading
		zeros and spaces with addresses as appropriate.
		* testsuite/ld-mips-elf/jalx-1.d: Likewise.
		* testsuite/ld-mips-elf/reloc-estimate-1.d: Likewise.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	testsuite: Also discard the `.MIPS.options' section
	Also discard the `.MIPS.options' section, used with n64 MIPS binaries,
	along with similar other MIPS sections (`.reginfo', `.MIPS.abiflags')
	not relevant for the test cases concerned, fixing these regressions:

	mips64-openbsd  -FAIL: ld-elf/group3a
	mips64-openbsd  -FAIL: ld-elf/group3b
	mips64-openbsd  -FAIL: Place orphan sections (map file check)
	mips64-openbsd  -FAIL: ld-elf/orphan-region
	mips64-openbsd  -FAIL: ld-elf/orphan
	mips64-openbsd  -FAIL: overlay size (map file check)
	mips64-openbsd  -FAIL: overlay size
	mips64el-openbsd  -FAIL: ld-elf/group3a
	mips64el-openbsd  -FAIL: ld-elf/group3b
	mips64el-openbsd  -FAIL: Place orphan sections (map file check)
	mips64el-openbsd  -FAIL: ld-elf/orphan-region
	mips64el-openbsd  -FAIL: ld-elf/orphan
	mips64el-openbsd  -FAIL: overlay size (map file check)
	mips64el-openbsd  -FAIL: overlay size

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		binutils/
		* testsuite/binutils-all/strip-3.d: Add `-R .MIPS.options' to
		the `strip' tag.

		ld/
		* testsuite/ld-elf/group.ld: Also discard `.MIPS.options'.
		* testsuite/ld-elf/orphan-region.ld: Likewise.
		* testsuite/ld-elf/orphan.ld: Likewise.
		* testsuite/ld-mips-elf/got-page-1.ld: Likewise.
		* testsuite/ld-scripts/overlay-size.t: Likewise.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix MIPS16 interlinking test IRIX 6 regressions
	IRIX 6 does not have MIPS16 stub section support in its n32 linker
	scripts, causing such input sections to be propagated to the respective
	output sections rather than `.text', causing dump pattern mismatches.

	Expect IRIX 6 to fail with n32 testing then, removing this regression:

	mips-sgi-irix6  -FAIL: MIPS16 interlinking for local functions 1 (n32)

	We may choose to update IRIX 6 n32 linker scripts sometime, as it seems
	a harmless change.

		ld/
		* testsuite/ld-mips-elf/mips-elf.exp: Expect IRIX 6 to fail with
		n32 `mips16-local-stubs-1' testing.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/LD/testsuite: Fix MIPS16 interlinking test n64 regressions
	The MIPS16 interlinking test for local functions expects to be assembled
	with 32-bit addressing, otherwise causing assembly warnings:

	.../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s: Assembler messages:
	.../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s:16: Warning: la used to load 64-bit address; recommend using dla instead

	Use the per-ABI framework then to run the test explicitly for o32 and
	n32 ABIs only, replacing the `-mips4' option from the `as' tag with
	`.module mips4' pseudo-op within the source itself so as to avoid
	assembly errors:

	Assembler messages:
	Error: -mips4 conflicts with the other architecture options, which imply -mips3

	with n32 testing for some targets, and ultimately removing these
	regressions:

	mips64-openbsd  -FAIL: MIPS16 interlinking for local functions 1
	mips64el-openbsd  -FAIL: MIPS16 interlinking for local functions 1

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		ld/
		* testsuite/ld-mips-elf/mips16-local-stubs-1.d: Remove `-mips4'
		from the `as' tag.
		* testsuite/ld-mips-elf/mips16-local-stubs-1.s: Add `.module
		mips4'.
		* testsuite/ld-mips-elf/mips-elf.exp: Run `mips16-local-stubs-1'
		for o32 and n32 ABIs only.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/GAS/testsuite: Force o32 for tests expecting 32-bit addressing
	A few GAS tests expect to be assembled with 32-bit addressing, otherwise
	causing an assembly warning:

	.../gas/testsuite/gas/mips/fix-rm7000-2.s:11: Warning: la used to load 64-bit address; recommend using dla instead

	or pattern dump mismatches against 32-bit address calculations, however
	these tests do not enforce their expectation in any.  For none of them
	the specific ABI used is of any relevance however, so select the o32 ABI
	unconditionally, removing these failures with OpenBSD targets:

	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (micromips)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips3)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips4)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips5)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r2)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r3)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r5)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon2)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon3)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeonp)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (r4000)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (sb1)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (vr5400)
	mips64-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (xlr)
	mips64-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2)
	mips64-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3)
	mips64-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp)
	mips64-openbsd  -FAIL: Full MIPS R5900
	mips64-openbsd  -FAIL: MIPS R5900 VU0
	mips64-openbsd  -FAIL: Paired LL/SC for mips64r6 (mips64r6)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (micromips)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips3)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips4)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips5)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r2)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r3)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (mips64r5)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon2)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeon3)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (octeonp)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (r4000)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (sb1)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (vr5400)
	mips64el-openbsd  -FAIL: MIPS RM7000 workarounds test 2 (xlr)
	mips64el-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2)
	mips64el-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3)
	mips64el-openbsd  -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp)
	mips64el-openbsd  -FAIL: Full MIPS R5900
	mips64el-openbsd  -FAIL: MIPS R5900 VU0
	mips64el-openbsd  -FAIL: Paired LL/SC for mips64r6 (mips64r6)

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

		gas/
		* testsuite/gas/mips/fix-rm7000-2.d: Add `-32' to the `as' tag.
		* testsuite/gas/mips/micromips@fix-rm7000-2.d: Likewise.
		* testsuite/gas/mips/r5900-full.d: Likewise.
		* testsuite/gas/mips/r5900-vu0.d: Likewise.
		* testsuite/gas/mips/llpscp-64.d: Add `as' tag with `-32'.
		* testsuite/gas/mips/octeon-saa-saad.d: Likewise.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Run `got-dump-1' for o32/n32 ABIs
	The `got-dump-1' test case uses 32-bit addressing, so it makes no sense
	to run it with the n64 ABI.  And there is a corresponding `got-dump-2'
	test already for the n64 ABI.

	Use the per-ABI framework then to run the `got-dump-1' test explicitly
	for o32 and n32 ABIs only.

		ld/
		* testsuite/ld-mips-elf/mips-elf.exp: Run `got-dump-1' for o32
		and n32 ABIs only.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with OpenBSD targets
	OpenBSD targets produce ELF64 files while the pattern dump expects ELF32
	output and specific header sizes.  Disable it for `mips64*-*-openbsd*'
	for these targets then, removing these failures:

	mips64-openbsd  -FAIL: ld-mips-elf/attr-gnu-4-10
	mips64el-openbsd  -FAIL: ld-mips-elf/attr-gnu-4-10

		ld/
		* testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `notarget' tag with
		`mips64*-*-openbsd*'.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with IRIX targets
	IRIX targets do not enable the production of a `.pdr' section in GAS by
	default, which causes a failure with the `attr-gnu-4-10' test case due
	to a difference resulting in the number and indices of sections produced
	in linker output.

	As the presence or absence of this section is not relevant to this test
	case, just enable it unconditionally, fixing these regressions:

	mips-sgi-irix5  -FAIL: ld-mips-elf/attr-gnu-4-10
	mips-sgi-irix6  -FAIL: ld-mips-elf/attr-gnu-4-10

		ld/
		* testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `as' tag with
		`-mpdr'.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix JALR relaxation test failure with IRIX 6
	The `mips-sgi-irix6' target only supports IRIX linker emulations, but
	most JALR relaxation tests request the relevant traditional emulation
	instead, causing a link failure:

	./ld-new: unrecognised emulation mode: elf32btsmipn32
	Supported emulations: elf32bmipn32 elf32bsmip elf64bmip

	This is clearly an omission from the conversion to use the per-ABI
	framework made with commit 78da84f99405 ("MIPS/LD/testsuite: Correct
	mips-elf.exp test ABI/emul/endian arrangement").  These tests are also
	endianness agnostic, which was missed in the conversion as well.

	Remove the unnecessary explicit ABI and endianness options then and rely
	on the per-ABI framework to get things right, removing this regression:

	mips-sgi-irix6  -FAIL: MIPS relax-jalr-shared n32

		ld/
		* testsuite/ld-mips-elf/relax-jalr-n32-shared.d: Remove flags
		related to ABI and endianness selection from the `as' and `ld'
		tags.
		* testsuite/ld-mips-elf/relax-jalr-n64.d: Likewise.
		* testsuite/ld-mips-elf/relax-jalr-n64-shared.d: Likewise.
		* testsuite/ld-mips-elf/mips-elf.exp: Remove `as' and `ld' tag
		additions from the invocation of JALR relaxation tests.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/LD/testsuite: Fix unaligned JALX failures with OpenBSD targets
	There are only n64 linker emulations included with `mips64*-*-openbsd*'
	targets, however the unaligned JALX tests insist on running across all
	targets and force the n32 ABI, causing link errors with the targets
	concerned, e.g.:

	./ld-new: tmpdir/unaligned-jalx-0.o: ABI is incompatible with that of the selected emulation
	./ld-new: failed to merge target specific data of file tmpdir/unaligned-jalx-0.o
	./ld-new: tmpdir/unaligned-insn.o: ABI is incompatible with that of the selected emulation
	./ld-new: failed to merge target specific data of file tmpdir/unaligned-insn.o

	Convert the tests then to use the per-ABI framework and run them for the
	o32 and n32 ABIs, removing these regressions:

	mips64-openbsd  -FAIL: MIPS JALX to unaligned symbol 0
	mips64-openbsd  -FAIL: MIPS JALX to unaligned symbol 1
	mips64-openbsd  -FAIL: MIPS JALX to unaligned symbol 2
	mips64-openbsd  -FAIL: MIPS JALX to unaligned symbol 3
	mips64-openbsd  -FAIL: MIPS16 JALX to unaligned symbol 0
	mips64-openbsd  -FAIL: MIPS16 JALX to unaligned symbol 1
	mips64-openbsd  -FAIL: microMIPS JALX to unaligned symbol 0
	mips64-openbsd  -FAIL: microMIPS JALX to unaligned symbol 1
	mips64el-openbsd  -FAIL: MIPS JALX to unaligned symbol 0
	mips64el-openbsd  -FAIL: MIPS JALX to unaligned symbol 1
	mips64el-openbsd  -FAIL: MIPS JALX to unaligned symbol 2
	mips64el-openbsd  -FAIL: MIPS JALX to unaligned symbol 3
	mips64el-openbsd  -FAIL: MIPS16 JALX to unaligned symbol 0
	mips64el-openbsd  -FAIL: MIPS16 JALX to unaligned symbol 1
	mips64el-openbsd  -FAIL: microMIPS JALX to unaligned symbol 0
	mips64el-openbsd  -FAIL: microMIPS JALX to unaligned symbol 1

	Similar tests for the n64 ABI can be added separately, using suitable
	dump patterns.

		ld/
		* testsuite/ld-mips-elf/unaligned-jalx-0.d: Remove `-32' from
		the `as' tag.
		* testsuite/ld-mips-elf/unaligned-jalx-1.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-2.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-3.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-mips16-0.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-mips16-1.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-micromips-0.d: Likewise.
		* testsuite/ld-mips-elf/unaligned-jalx-micromips-1.d: Likewise.
		* testsuite/ld-mips-elf/mips-elf.exp: Run unaligned JALX tests
		with `run_dump_test_o32' and `run_dump_test_n32' rather than
		`run_dump_test'.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Disable compact EH #7 tests with OpenBSD targets
	Compact EH #7 tests use output templates that are not suitable for the
	n64 ABI, which `mips64*-*-openbsd*' targets use by default, because the
	contents of the sections examined are expected to be differnt.  Disable
	the tests then, removing these regressions:

	mips64-openbsd  -FAIL: Compact EH EB #7 with personality id and fallback FDE
	mips64-openbsd  -FAIL: Compact EH EL #7 with personality id and fallback FDE
	mips64el-openbsd  -FAIL: Compact EH EB #7 with personality id and fallback FDE
	mips64el-openbsd  -FAIL: Compact EH EL #7 with personality id and fallback FDE

	Suitable corresponding tests for the n64 ABI can be added separately.

		gas/
		* testsuite/gas/mips/compact-eh-eb-7.d: Exclude for
		`mips64*-*-openbsd*'.
		* testsuite/gas/mips/compact-eh-el-7.d: Likewise.

2023-07-28  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS/LD: Include n64 `.interp' with INITIAL_READONLY_SECTIONS
	In ld/emulparams/elf64bmip-defs.sh there is no explicit handling of the
	`.interp' section, which causes it to be positioned in output at an odd
	place.

	Let's include it with INITIAL_READONLY_SECTIONS, just like o32/n32 do,
	fixing a regression from commit 5a8e7be242f3 ("INITIAL_READONLY_SECTIONS
	in elf.sc"), where the handling of n64 was missed due to an unfortunate
	sequence of events where ld/emulparams/elf64bmip-defs.sh was only added
	with commit 94bb04b3c611 ("Use .reginfo rather than .MIPS.options in n32
	linker scripts") the day before.

	Add test cases covering section ordering across the three ABIs.  This
	change also fixes ld/pr23658-2:

	FAIL: Build pr23658-2

	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>

	ld/ChangeLog:
		* emulparams/elf64bmip-defs.sh: Include `.interp' with
		INITIAL_READONLY_SECTIONS.
		* testsuite/ld-mips-elf/pie-n64.d: Adjust addresses.
		* testsuite/ld-mips-elf/sections-1-o32.rd: New test.
		* testsuite/ld-mips-elf/sections-1-o32t.rd: New test.
		* testsuite/ld-mips-elf/sections-1-n32.rd: New test.
		* testsuite/ld-mips-elf/sections-1-n32t.rd: New test.
		* testsuite/ld-mips-elf/sections-1-n32p.rd: New test.
		* testsuite/ld-mips-elf/sections-1-n64.rd: New test.
		* testsuite/ld-mips-elf/sections-1-n64t.rd: New test.
		* testsuite/ld-mips-elf/sections-2-o32.rd: New test.
		* testsuite/ld-mips-elf/sections-2-o32t.rd: New test.
		* testsuite/ld-mips-elf/sections-2-n32.rd: New test.
		* testsuite/ld-mips-elf/sections-2-n32t.rd: New test.
		* testsuite/ld-mips-elf/sections-2-n32p.rd: New test.
		* testsuite/ld-mips-elf/sections-2-n64.rd: New test.
		* testsuite/ld-mips-elf/sections-2-n64t.rd: New test.
		* testsuite/ld-mips-elf/sections.s: New test source.
		* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.

2023-07-28  Maciej W. Rozycki  <macro@orcam.me.uk>

	Revert "MIPS: support mips*64 as CPU and gnuabi64 as ABI"
	This reverts commit 32f1c80375ebe8ad25d9805ee5889f0006c51e59.  It had
	two unrelated changes lumped together, one of which changed the meaning
	of the `mipsisa64*-*-linux*' target triplets, which was not properly
	evaluated.

2023-07-28  Alan Modra  <amodra@gmail.com>

	ldscripts/empty-address vs. xcoff
	The empty-address tests check that if a section is removed by ld due
	to being empty then properties of that section don't affect following
	addresses.  The xcoff backend doesn't remove the empty .data section
	created by empty-address-2* and empty-address-3* for some reason, and
	therefore fails the test.

		* testsuite/ld-scripts/empty-address-1.d: Accept more symbols.
		* testsuite/ld-scripts/empty-address-2a.d: xfail for xcoff.
		* testsuite/ld-scripts/empty-address-2b.d: Likewise.
		* testsuite/ld-scripts/empty-address-3a.d: Likewise.
		* testsuite/ld-scripts/empty-address-3b.d: Likewise.

2023-07-28  Alan Modra  <amodra@gmail.com>

	Fix recent x86 pe/coff testsuite regressions
		* testsuite/gas/i386/sha512-intel.d: Accept section nop padding.
		* testsuite/gas/i386/sha512.d: Likewise.
		* testsuite/gas/i386/sm3-intel.d: Likewise.
		* testsuite/gas/i386/sm3.d: Likewise.
		* testsuite/gas/i386/x86-64-pbndkb-intel.d: Likewise.
		* testsuite/gas/i386/x86-64-pbndkb.d: Likewise.
		* testsuite/gas/i386/x86-64-sha512-intel.d: Likewise.
		* testsuite/gas/i386/x86-64-sha512.d: Likewise.
		* testsuite/gas/i386/x86-64-sm3-intel.d: Likewise.
		* testsuite/gas/i386/x86-64-sm3.d: Likewise.

2023-07-28  Alan Modra  <amodra@gmail.com>

	coff/pe/xcoff and --extract-symbols
	This fixes failure of the "extract symbols" test for rs6000, where
	--extract-symbols generates a non-zero sized .text.  By the look of
	coffcode.h the same problem might occur for coff/pe too, but doesn't
	happen to trigger a test failure.

	bfd/
		* coffcode.h (coff_compute_section_file_positions): Don't
		adjust size of !SEC_LOAD sections.
	binutils/
		* objcopy.c (setup_section): Clear SEC_LOAD for --extract-symbol.

2023-07-28  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Add actual 'Zvkt' extension support
	The 'Zvkt' extension is listed on the added extensions in the GNU Binutils
	version 2.41 (see binutils/NEWS).  However, the support of this extension
	was actually missing.

	This commit adds actual support of this extension and adds implications
	from 'Zvkn' and 'Zvks' superset extensions.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets) Add implications from
		'Zvkn' and 'Zvks'.  (riscv_supported_std_z_ext): Add 'Zvkt' to
		the supported extension list.

2023-07-28  Tsukasa OI  <research_trasio@irq.a4lg.com>

	Fix typo in riscv-dis.c comment
	Don't go "past" the start of the section.

2023-07-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove trailing empty line in target-delegates.c
	In a review [1], I pointed out that applying the patch, git would say:

	    .git/rebase-apply/patch:147: new blank line at EOF.

	However, since the empty line is in target-delegates.c (a generated
	file), there's nothing the author can do about it.  To avoid this
	comment coming up again in the future, change make-target-delegates.py
	to avoid the trailing empty line.  Do this by making it output empty
	lines before each entity, not after.

	Since this needs removing a newline output in gdbcopyright, adjust
	ada-unicode.py and gdbarch.py to avoid changes in the files they
	generate.

	[1] https://inbox.sourceware.org/gdb-patches/20230427210113.45380-1-jhb@FreeBSD.org/T/#m083598405bef19157f67c9d97846d3dd90dc7d1c

	Change-Id: Ic4c648f06443b432168cb76603402c918aa6e5d2
	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-27  Tom Tromey  <tromey@adacore.com>

	Report supportsBreakpointLocationsRequest
	While looking at the DAP spec, I noticed that the breakpointLocations
	request is gated behind a capability.  This patch changes gdb to
	report this capability.

	I've also added a comment to explain the fact that arguments to
	breakpointLocations are not optional, even though the spec says they
	are.

2023-07-27  Alan Modra  <amodra@gmail.com>

	/DISCARD/ in ld testsuite
	The canonical form to discard all sections not mentioned earlier in
	the script is
	  /DISCARD/ : { *(*) }
	not
	  /DISCARD/ : { *(.*) }
	".*" happens to work with the usual section names starting with a dot,
	but let's not promote something not quite right.

2023-07-27  Alan Modra  <amodra@gmail.com>

	sh: uninitialised sh_operand_info.type in get_specific
	Seen when running gas/testsuite/gas/sh/err-at.s

		* config/tc-sh.c (get_operands): Always init operand type.
		* testsuite/gas/sh/err-at.s: Expect unnecessary extra errors.

2023-07-27  Hu, Lin1  <lin1.hu@intel.com>

	Support Intel PBNDKB
	gas/ChangeLog:

		* NEWS: Support Intel PBNDKB.
		* config/tc-i386.c: Add pbndkb.
		* doc/c-i386.texi: Document .pbndkb.
		* testsuite/gas/i386/i386.exp: Add PBNDKB tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/pbndkb-inval.l: New test.
		* testsuite/gas/i386/pbndkb-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-pbndkb-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-pbndkb.d: Ditto.
		* testsuite/gas/i386/x86-64-pbndkb.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_7): New.
		(X86_64_0F01_REG_0_MOD_3_RM_7_P_0): Ditto.
		(prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_7.
		(x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_7_P_0.
		(rm_table): New entry for pbndkb.
		* i386-gen.c (cpu_flag): Add PBNDKB.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuPBNDKB): New.
		(i386_cpu_flags): Add cpupbndkb.
		* i386-opc.tbl: Add PBNDKB instructions.
		* i386-tbl.h: Regenerated.

2023-07-27  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel SM4
	gas/ChangeLog:

		* NEWS: Support Intel SM4.
		* config/tc-i386.c: Add sm4.
		* doc/c-i386.texi: Document .sm4.
		* testsuite/gas/i386/i386.exp: Run SM4 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/sm4-intel.d: Add SM4 tests.
		* testsuite/gas/i386/sm4.d: Ditto.
		* testsuite/gas/i386/sm4.s: Ditto.
		* testsuite/gas/i386/x86-64-sm4-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-sm4.d: Ditto.
		* testsuite/gas/i386/x86-64-sm4.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (prefix_table): Add SM4 instructions.
		* i386-gen.c (isa_dependencies): Add SM4.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuSM4): New.
		(i386_cpu_flags): Add cpusm4.
		* i386-opc.tbl: Add SM4 instructions.
		* i386-tbl.h: Regenerated.

2023-07-27  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel SM3
	gas/ChangeLog:

		* NEWS: Support Intel SM3.
		* config/tc-i386.c: Add sm3.
		* doc/c-i386.texi: Document .sm3.
		* testsuite/gas/i386/i386.exp: Run sm3 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/sm3-intel.d: New test.
		* testsuite/gas/i386/sm3.d: Ditto.
		* testsuite/gas/i386/sm3.s: Ditto.
		* testsuite/gas/i386/x86-64-sm3-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-sm3.d: Ditto.
		* testsuite/gas/i386/x86-64-sm3.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (PREFIX_VEX_0F38DA_W_0): New.
		(VEX_LEN_0F38DA_W_0_P_0): Ditto.
		(VEX_LEN_0F38DA_W_0_P_2): Ditto.
		(VEX_LEN_0F3ADE_W_0): Ditto.
		(VEX_W_0F38DA): Ditto.
		(VEX_W_0F3ADE): Ditto.
		(prefix_table): Add PREFIX_VEX_0F38DA_W_0.
		(vex_len_table): Add VEX_LEN_0F38DA_W_0_P_0,
		VEX_LEN_0F38DA_W_0_P_2, VEX_LEN_0F3ADE_W_0.
		(vex_w_table): Add VEX_W_0F38DA, VEX_W_0F3ADE.
		* i386-gen.c (isa_dependencies): Add SM3.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuSM3): New.
		(i386_cpu_flags): Add cpusm3.
		* i386-opc.tbl: Add SM3 instructions.
		* i386-tbl.h: Regenerated.

2023-07-27  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel SHA512
	gas/ChangeLog:

		* NEWS: Support Intel SHA512.
		* config/tc-i386.c: Add sha512.
		* doc/c-i386.texi: Document .sha512.
		* testsuite/gas/i386/disassem.d: Add SHA512 tests.
		* testsuite/gas/i386/disassem.s: Ditto.
		* testsuite/gas/i386/i386.exp: Run SHA512 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/sha512-intel.d: New test.
		* testsuite/gas/i386/sha512-inval.l: Ditto.
		* testsuite/gas/i386/sha512-inval.s: Ditto.
		* testsuite/gas/i386/sha512.d: Ditto.
		* testsuite/gas/i386/sha512.s: Ditto.
		* testsuite/gas/i386/x86-64-sha512-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-sha512-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-sha512-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-sha512.d: Ditto.
		* testsuite/gas/i386/x86-64-sha512.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (Rxmmq): New.
		(Rymm): Ditto.
		(PREFIX_VEX_0F38CB): Ditto.
		(PREFIX_VEX_0F38CC): Ditto.
		(PREFIX_VEX_0F38CD): Ditto.
		(VEX_LEN_0F38CB_P_3_W_0): Ditto.
		(VEX_LEN_0F38CC_P_3_W_0): Ditto.
		(VEX_LEN_0F38CD_P_3_W_0): Ditto.
		(VEX_W_0F38CB_P_3): Ditto.
		(VEX_W_0F38CC_P_3): Ditto.
		(VEX_W_0F38CD_P_3): Ditto.
		(prefix_table): Add PREFIX_VEX_0F38CB, PREFIX_VEX_0F38CC,
		PREFIX_VEX_0F38CD.
		(vex_len_table): Add VEX_LEN_0F38CB_P_3_W_0,
		VEX_LEN_0F38CC_P_3_W_0, VEX_LEN_0F38CD_P_3_W_0.
		(vex_w_table): Add VEX_W_0F38CB_P_3, VEX_W_0F38CC_P_3, VEX_W_0F38CD_P_3.
		* i386-gen.c (isa_dependencies): Add SHA512.
		(cpu_flags): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuSHA512): New.
		(i386_cpu_flags): Add cpusha512.
		* i386-opc.tbl: Add SHA512 instructions.
		* i386-tbl.h: Regenerated.

2023-07-27  konglin1  <lingling.kong@intel.com>

	Support Intel AVX-VNNI-INT16
	gas/ChangeLog:

		* NEWS: Support Intel AVX-VNNI-INT16.
		* config/tc-i386.c: Add avx_vnni_int16.
		* doc/c-i386.texi: Document avx_vnni_int16.
		* testsuite/gas/i386/i386.exp: Run AVX VNNI INT16 tests.
		* testsuite/gas/i386/x86-64.exp: Ditto.
		* testsuite/gas/i386/avx-vnni-int16-intel.d: New test.
		* testsuite/gas/i386/avx-vnni-int16.d: New test.
		* testsuite/gas/i386/avx-vnni-int16.s: New test.
		* testsuite/gas/i386/x86-64-avx-vnni-int16-intel.d: New test.
		* testsuite/gas/i386/x86-64-avx-vnni-int16.d: New test.
		* testsuite/gas/i386/x86-64-avx-vnni-int16.s: New test.

	opcodes/ChangeLog:

		* i386-dis.c (PREFIX_VEX_0F38D2_W_0): New.
		(PREFIX_VEX_0F38D3_W_0): Ditto.
		(VEX_W_0F38D2_P_0): Ditto.
		(VEX_W_0F38D2_P_1): Ditto.
		(VEX_W_0F38D2_P_2): Ditto.
		(VEX_W_0F38D3_P_0): Ditto.
		(VEX_W_0F38D3_P_1): Ditto.
		(VEX_W_0F38D3_P_2): Ditto.
		(prefix_table): Add PREFIX_VEX_0F38D2_W_0 and
		PREFIX_VEX_0F38D3_W_0.
		(vex_table): Add VEX_W_0F38D2 and VEX_W_0F38D3.
		(vex_w_table): Ditto.
		* i386-gen.c (isa_dependencies): Add AVX_VNNI_INT16.
		(cpu_flag): Ditto.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h: (CpuAVX_VNNI_INT16): New.
		* i386-opc.tbl: Add Intel AVX_VNNI_INT16 instructions.
		* i386-tbl.h: Regenerated.

2023-07-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-thread-exited.exp
	Two fixes in gdb.python/py-thread-exited.exp:
	- fix the copyright notice validity range (PR testsuite/30687):
	  2022-202 -> 2022-2023, and
	- add missing "require allow_python_tests".

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30687

2023-07-26  David Faust  <david.faust@oracle.com>

	bpf: accept # as an inline comment char
	This little patch makes the BPF assembler accept '#' as an inline
	comment character, which clang -S seems to use.

	gas/
		* config/tc-bpf.c (comment_chars): Add '#'.
		* doc/c-bpf.texi (BPF Special Characters): Add note that '#' may
		be used for inline comments.

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix Wstringop-truncation in coff_getfilename
	When building gdb with -O2 -fsanitize-threads, I ran into
	a Werror=stringop-truncation.

	The problem is here in coff_getfilename in coffread.c:
	...
	      strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
	      buffer[FILNMLEN] = '\0';
	...

	The constant FILNMLEN is expected to designate the size of
	aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit
	60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW
	targets.").

	Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead.

	Likewise in xcoffread.c.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

	PR build/30669
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669

2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: add negi and neg32i tests
	gas/ChangeLog:

	2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/alu.s: Add test for NEGI and NEG32I.
		* testsuite/gas/bpf/alu32.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu.d: Add expected results.
		* testsuite/gas/bpf/alu-be.d: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32.d: Likewise.
		* testsuite/gas/bpf/alu32-be.d: Likewise.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Drop -nostdlib in gdb.dwarf2/typeddwarf.exp
	As reported in PR testsuite/30633, when running test-case
	gdb.dwarf2/typeddwarf.exp with target board native-gdbserver on Ubuntu
	22.04.2, we run into:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Program received signal SIGSEGV, Segmentation fault.^M
	0x0000000000000001 in ?? ()^M
	(gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
	...

	We run into the FAIL as follows:
	- due to using gdbserver, we attach at the point of the first instruction, in
	  _start
	- we then set a breakpoint at main
	- the test-case is a .s file, that has main renamed to _start in the assembly,
	  but not in the debuginfo
	- setting a breakpoint at main sets the breakpoint at the same instruction
	  we're currently stopped at
	- continue doesn't hit the breakpoint, and we return out of _start, which
	  causes a sigsegv

	Note that this is for the amd64 case (using gdb.dwarf2/typeddwarf-amd64.S).
	For the i386 case (using gdb.dwarf2/typeddwarf.S), setting a breakpoint in
	main sets it one insn after function entry, and consequently the problem does
	not occur.

	The FAIL is a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie
	in a few test-cases").

	Without nopie the executable is PIE, with nopie it's static instead.

	In the PIE case, we attach at the point of _start in the dynamic linker, and
	consequently we do not skip the breakpoint in main, and also don't run into
	the FAIL.

	Fix this by:
	- removing the -nostdlib setting, and
	- renaming _start to main in both .S files.

	The change to use -nostdlib and rename main to _start was originally added
	in commit 6edba76fe8b (submitted here:
	https://sourceware.org/pipermail/gdb-patches/2011-May/082657.html ) , I assume
	to fix the problem now fixed by using nopie.

	Tested on x86_64-linux.

	Reported-By: Simon Marchi <simon.marchi@efficios.com>
	Tested-By: Simon Marchi <simon.marchi@efficios.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30633

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix secondary prompt
	With CLI, a session defining a command looks like:
	...
	(gdb) define foo
	Type commands for definition of "foo".
	End with a line saying just "end".
	>bar
	>end
	(gdb)
	...

	With TUI however, we get the same secondary prompts, and type the same, but
	are left with:
	...
	(gdb) define foo
	Type commands for definition of "foo".
	End with a line saying just "end".
	(gdb)
	...

	Fix this by calling tui_inject_newline_into_command_window in
	gdb_readline_wrapper_line, as is done in tui_command_line_handler.

	Tested on x86_64-linux.

	PR tui/30636
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30636

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0 some more
	With a gdb build with -O2 -flto=auto and gcc 7.5.0 and test-case
	gdb.gdb/python-helper.exp I run into:
	...
	(outer-gdb) continue^M
	Continuing.^M
	print 1^M
	^M
	Thread 1 "xgdb" hit Breakpoint 2, \
	  _Z11value_printP5valueP7ui_filePK19value_print_options (val=0x22e2590, \
	  stream=0x1f65480, options=0x7fffffffcdc0) at gdb/valprint.c:1193^M
	1193    {^M
	(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
	...

	This is the "value_print" variant of the problem with "c_print_type" I fixed
	in commit 0d332f11122 ("[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2
	 -flto=auto and gcc 7.5.0").

	Fix this likewise.

	Tested on x86_64-linux.

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix assert in ~gdbpy_tui_window_maker
	In gdb/tui/tui-layout.c, we have:
	...
	static window_types_map known_window_types;
	...
	and in gdb/python/py-tui.c:
	...
	  /* A global list of all gdbpy_tui_window_maker objects.  */
	  static intrusive_list<gdbpy_tui_window_maker> m_window_maker_list;
	};

	/* See comment in class declaration above.  */

	intrusive_list<gdbpy_tui_window_maker>
	  gdbpy_tui_window_maker::m_window_maker_list;
	...

	With a gdb build with -O0 or -O2, the static destructor calling order seems to be:
	- first gdb/tui/tui-layout.c,
	- then gdb/python/py-tui.c.

	So when running test-case gdb.python/tui-window-factory.exp, we see the
	following order of events:
	- the destructor for known_window_types is called, which triggers calling the
	  destructor for the only element E of m_window_maker_list.  The destructor
	  destroys E, and also removes E from m_window_maker_list, leaving it empty.
	- the destructor for m_window_maker_list is called.  It's empty, so it's a nop.

	However, when building gdb with -O2 -flto=auto, the static destructor calling
	order seems to be reversed.

	Instead, we have these events:
	- the destructor for m_window_maker_list is called.  This doesn't destroy it's
	  only element E, but it does make m_window_maker_list empty.
	- the destructor for known_window_types is called, which triggers calling the
	  destructor for E.  An attempt is done to remove E from m_window_maker_list,
	  but we run into an assertion failure, because the list is empty.

	Fix this by checking is_linked () before attempting to remove from
	m_window_maker_list, similar to how things were addressed in commit 995a34b1772
	("Guard against frame.c destructors running before frame-info.c's").

	Tested on x86_64-linux.

	PR tui/30646
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30646

2023-07-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexps in gdb.base/step-over-syscall.exp
	When running test-case gdb.base/step-over-syscall.exp without glibc debuginfo
	installed, I get:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, 0x00007ffff7d4405e in vfork () from /lib64/libc.so.6^M
	(gdb) PASS: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
	  continue to vfork (1st time)
	...
	but with glibc debuginfo installed I get instead:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, 0x00007ffff7d4405e in __libc_vfork () at \
	  ../sysdeps/unix/sysv/linux/x86_64/vfork.S:44^M
	44      ENTRY (__vfork)^M
	(gdb) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
	  continue to vfork (1st time)
	...

	The FAIL is due to a mismatch with regexp:
	...
	  "Breakpoint \[0-9\]+, (.* in |__libc_|)$syscall \\(\\).*"
	...
	because it cannot match both ".* in " and the __libc_ prefix.

	Fix this by using instead the regexp:
	...
	  "Breakpoint \[0-9\]+, (.* in )?(__libc_)?$syscall \\(\\).*"
	...

	Tested on x86_64-linux.

2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: fix neg and neg32 BPF instructions in simulator
	This patch fixes the semantics of the neg and neg32 BPF instructions
	in the simulator, and also updates the corresponding tests
	accordingly.

	Tested in target bpf-unknown-none.

2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: fix register NEG[32] instructions
	This patch fixes the BPF_INSN_NEGR and BPF_INSN_NEG32R BPF
	instructions to not use their source registers.

	Tested in bpf-unknown-none.

	opcodes/ChangeLog:

	2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Fix BPF_INSN_NEGR to not use a src
		register.

	gas/ChangeLog:

	2023-07-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/alu.s: The register neg instruction gets only
		one argument.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-be.d: Likewise.
		* testsuite/gas/bpf/alu.d: Likewise.
		* testsuite/gas/bpf/alu32-be.d: Likewise.
		* testsuite/gas/bpf/alu32.d: Likewise.
		* testsuite/gas/bpf/alu32.s: Likewise.
		* doc/c-bpf.texi (BPF Instructions): Update accordingly.

2023-07-26  Alan Modra  <amodra@gmail.com>

	PR30657, gprof heap buffer overflow
		PR 30657
		* cg_arcs.c (cg_assemble): Sanity check find_call addresses.
		* i386.c (i386_find_call): Don't access past end of core_text_space.
		* aarch64.c (aarch64_find_call): Round up lowpc, round down highpc.
		* alpha.c (alpha_find_call): Likewise.
		* mips.c (mips_find_call): Likewise.
		* sparc.c (sparc_find_call): Likewise.
		* vax.c (vax_find_call): Sanity check core_text_space accesses.

2023-07-26  Alan Modra  <amodra@gmail.com>

	[GOLD] reporting local symbol names
	get_symbol_name currently returns "" for the usual STT_SECTION symbols
	generated by gas.  That's not very helpful, return the section name.
	Demangle local symbols too, fixing an inconsistency in
	issue_discarded_error where global symbols are demangled.

		* object.cc (Sized_relobj_file::get_symbol_name): Return a
		std::string.  Return section name for STT_SECTION symbols with
		zero st_name.  Sanity check st_name, and don't run off the end
		of an improperly terminated .strtab.  Demangle sym names.
		* object.h (Sized_relobj_file::get_symbol_name): Update decl.
		* target-reloc.h (issue_discarded_error): Adjust.
		* powerpc.cc (Target_powerpc::Relocate::relocate): Report reloc
		type and symbol for relocation overflows.

2023-07-26  Alan Modra  <amodra@gmail.com>

	Don't warn on .attach_to_group to same group
		* config/obj-elf.c (obj_elf_attach_to_group): Don't warn if
		group name matches current group for section.

	bpf: format not a string literal
		* config/tc-bpf.c (md_assemble): Correct as_bad call.

	Regen bpf opcodes POTFILE

2023-07-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-25  David Faust  <david.faust@oracle.com>

	bpf: Add atomic compare-and-exchange instructions
	This patch adds the two remaining BPF v3 atomic instructions:
	- BPF_INSN_ACMP{,32}: atomic compare-and-swap
	- BPF_INSN_AXCHG{,32}: atomic (non-conditional) exchange

	Tests and documentation are also updated.

	gas/
		* doc/c-bpf.texi (BPF Instructions): Document atomic exchange and
		atomic compare-and-swap instructions.
		* testsuite/gas/bpf/atomic.s: Test ACMP, ACMP32, AXCHG, AXCGH32
		instructions.
		* testsuite/gas/bpf/atomic.d: Likewise.
		* testsuite/gas/bpf/atomic-be.d: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
		* testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise.

	include/
		* opcode/bpf.h (BPF_IMM32_ACMP): Fix typo.
		(enum bpf_insn_id): New entries for BPF_INSN_ACMP{,32} and
		BPF_INSN_AXCHG{,32}.

	opcodes/
		* bpf-opc.c (bpf_opcodes): Add entries for ACMP{,32} and
		AXCHG{,32} instructions.

2023-07-25  David Faust  <david.faust@oracle.com>

	bpf: Update atomic instruction pseudo-C syntax
	This patch updates the pseudo-C dialect templates for the BPF v3 atomic
	instructions.  The templates match the strings emitted by clang -S for
	these instructions.

	The tests and documentation are updated accordingly.

	gas/
		* doc/c-bpf.texi (BPF Instructions): Update entries for atomic
		and 32-bit atomic instructions.
		* testsuite/gas/bpf/atomic.s: Test AAND, AAND32, AOR, AOR32,
		AXOR, AXOR32, AFADD, AFADD32, AFAND, AFAND32, AFOR, AFOR32,
		AFXOR and AFXOR32 instructions.
		* testsuite/gas/bpf/atomic.d: Likewise.
		* testsuite/gas/bpf/atomic-be.d: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
		* testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/atomic-v1.s: New test.
		* testsuite/gas/bpf/atomic-v1.d: Likewise.
		* testuiste/gas/bpf/atomic-v1-be.d: Likewise.
		* testuiste/gas/bpf/bpf.exp: Run new tests.

	opcodes/
		* bpf-opc.c (bpf_opcodes): Update pseudo-C dialect templates for:
		BPF_INSN_AADD, BPF_INSN_AOR, BPF_INSN_AAND, BPF_INSN_AXOR,
		BPF_INSN_AFADD, BPF_INSN_AFOR, BPF_INSN_AFAND, BPF_INSN_AFXOR,
		BPF_INSN_AADD32, BPF_INSN_AOR32, BPF_INSN_AAND32,
		BPF_INSN_AXOR32, BPF_INSN_AFADD32, BPF_INSN_AFOR32,
		BPF_INSN_AFAND32, and BPF_INSN_AFXOR32 instructions.

2023-07-25  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Enable RVC on ".option arch, +zca" etc.
	Since the 'Zca' extension is the new base of the compressed instructions,
	this commit enables RVC *also* when the 'Zca' extension is enabled
	via ".option arch" directive.

	gas/ChangeLog:

		* config/tc-riscv.c (s_riscv_option): Enable RVC also when the
		'Zca' extension is enabled after an ".option arch" directive.

2023-07-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-25  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Implications from 'Zc[fd]' extensions
	The version 1.0.4-1 of the code size reduction specification clarifies
	that 'Zcf' implies 'F' and 'Zcd' implies 'D'.

	cf:
	<https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1>

	This commit adds those implications.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_implicit_subsets): Add two implications,
		'Zcf' -> 'F' and 'Zcd' -> 'D'.

	gas/ChangeLog:

		* testsuite/gas/riscv/march-imply-zcd.d: New test.
		* testsuite/gas/riscv/march-imply-zcf.d: New test.

2023-07-25  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Prohibit the 'Zcf' extension on RV64
	As per:
	<https://github.com/riscv/riscv-code-size-reduction/issues/221>,
	the 'Zcf' extension does not exist on RV64.  This is reflected on the
	version 1.0.4-1 of the code size reduction specification:
	<https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1>.

	This commit prohibits the combination: RV64 (or any ISA with XLEN > 32)
	and the 'Zcf' extension.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit
		combination of RV64 and 'Zcf'.

	gas/ChangeLog:

		* testsuite/gas/riscv/march-fail-rv64i_zcf.d: New test.
		* testsuite/gas/riscv/march-fail-rv64i_zcf.l: Likewise.

2023-07-24  Johannes Schauer Marin Rodrigues  <josch@debian.org>

	objcopy embeds the current time and ignores SOURCE_DATE_EPOCH making the output unreproducible.
	bfd
	  * peXXigen.c (_bfd_XXi_only_swap_filehdr_out): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined.
	binutils
	  * doc/binutils.texi (objcopy): Document change in behaviour of objcopy's --preserve-dates command line option.
	ld
	  * pe-dll.c (fill_edata): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined.
	  * ld.texi (--insert-timestamp): Document change in behaviour.

2023-07-24  Nick Clifton  <nickc@redhat.com>

	Updated translations for bfd, gold and opcodes

2023-07-24  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: ld: Simplify inserting IRELATIVE relocations to .rela.dyn
	In LoongArch, the R_LARCH_IRELATIVE relocations for local ifunc symbols are
	in .rela.dyn. Before, this is done by loongarch_elf_finish_dynamic_sections.
	But this function is called after elf_link_sort_relocs, it need to find a
	null slot to insert IRELATIVE relocation.

	Now, it is processed by elf_loongarch_output_arch_local_syms before
	elf_link_sort_relocs, just need to call loongarch_elf_append_rela to
	insert IRELATIVE relocation.

	bfd/ChangeLog:

		* elfnn-loongarch.c (elfNN_allocate_local_ifunc_dynrelocs): Return
		type change to int.
		(loongarch_elf_size_dynamic_sections): Delete (void *).
		(loongarch_elf_finish_dynamic_symbol): Use loongarch_elf_append_rela
		insert IRELATIVE relocation to .rela.dyn.
		(elfNN_loongarch_finish_local_dynamic_symbol): Return type change to
		int.
		(loongarch_elf_finish_dynamic_sections): Delete process of local
		ifunc symbols.
		(elf_backend_output_arch_local_syms): New.

	ld/ChangeLog:

		* testsuite/ld-loongarch-elf/local-ifunc-reloc.d: Regenerated.

2023-07-24  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix immediate overflow check bug
	For B16/B21/B26/PCREL20_S2 relocations, if immediate overflow check after
	rightshift, and the mask need to include sign bit.

	Now, the immediate overflow check before rightshift for easier understand.

	bfd/ChangeLog:

		* elfxx-loongarch.c (reloc_bits_pcrel20_s2): Delete.
		(reloc_bits_b16): Delete.
		(reloc_bits_b21): Delete.
		(reloc_bits_b26): Delete.
		(reloc_sign_bits): New.

2023-07-24  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix instruction immediate bug caused by sign-extend
	For extreme code mode, the instruction sequences is
	    pcalau12i $t0, hi20
	    addi.d $t1, $zero, lo12
	    lu32i.d $t1, lo20
	    lu52i.d $t1, hi12
	    add.d $t1, $t0, $t1

	If lo12 > 0x7ff, hi20 need to add 0x1, lo20 need to sub 0x1.
	If hi20 > 0x7ffff, lo20 need to add 0x1.

	bfd/ChangeLog:

		* elfnn-loongarch.c (RELOCATE_CALC_PC32_HI20): Redefined.
		(RELOCATE_CALC_PC64_HI32): Redefined.

2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas,include,opcode: add suppor for instructions BSWAP{16,32,64}
	This patch adds support for the BPF V4 ISA byte swap instructions to
	opcodes, assembler and disassembler.

	Tested in bpf-unknown-none.

	include/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* opcode/bpf.h (BPF_IMM32_BSWAP16): Define.
		(BPF_IMM32_BSWAP32): Likewise.
		(BPF_IMM32_BSWAP64): Likewise.
		(enum bpf_insn_id): New entries BPF_INSN_BSWAP{16,32,64}.

	opcodes/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Add entries for the BSWAP*
		instructions.

	gas/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* doc/c-bpf.texi (BPF Instructions): Document BSWAP* instructions.
		* testsuite/gas/bpf/alu.s: Test BSWAP{16,32,64} instructions.
		* testsuite/gas/bpf/alu.d: Likewise.
		* testsuite/gas/bpf/alu-be.d: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.

2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas: fix in manual that MOVS* pseudoc syntax uses = instead of s=
	gas/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* doc/c-bpf.texi (BPF Instructions): The pseudoc syntax for MOVS*
		doesn't use `s=' but `='.

2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: gas,opcodes: fix pseudoc syntax for MOVS* and LDXS* insns
	This patch fixes the pseudoc syntax of the V4 instructions MOVS* and
	LDXS* in order to reflect https://reviews.llvm.org/D144829.

	opcodes/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Fix pseudo-c syntax for MOVS* and LDXS*
		instructions.

	gas/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* doc/c-bpf.texi (BPF Instructions): Fix pseudoc syntax for MOVS*
		and LDXS* instructions.
		* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.

2023-07-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: add support for jal/gotol jump instruction with 32-bit target
	This patch adds support for the V4 BPF instruction jal/gotol, which is
	like ja/goto but it supports a signed 32-bit PC-relative (in number of
	64-bit words minus one) target operand instead of the 16-bit signed
	operand of the other instruction.  This greatly increases the jump
	range in BPF programs.

	Tested in bpf-unkown-none.

	bfd/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* reloc.c: New reloc BFD_RELOC_BPF_DISPCALL32.
		* elf64-bpf.c (bpf_reloc_type_lookup): Handle the new reloc.
		* libbfd.h (bfd_reloc_code_real_names): Regenerate.

	gas/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* config/tc-bpf.c (struct bpf_insn): New field `id'.
		(md_assemble): Save the ids of successfully parsed instructions
		and use the new BFD_RELOC_BPF_DISPCALL32 whenever appropriate.
		(md_apply_fix): Adapt to the new BFD reloc.
		* testsuite/gas/bpf/jump.s: Test JAL.
		* testsuite/gas/bpf/jump.d: Likewise.
		* testsuite/gas/bpf/jump-pseudoc.d: Likewise.
		* testsuite/gas/bpf/jump-be.d: Likewise.
		* testsuite/gas/bpf/jump-be-pseudoc.d: Likewise.
		* doc/c-bpf.texi (BPF Instructions): Document new instruction
		jal/gotol.
		Document new operand type disp32.

	include/ChangeLog:

	2023-07-24  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* opcode/bpf.h (enum bpf_insn_id): Add entry BPF_INSN_JAL.
		(enum bpf_insn_id): Remove spurious entry BPF_INSN_CALLI.

	opcodes/ChangeLog:

	2023-07-23  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Add entry for jal.

2023-07-23  Tom Tromey  <tom@tromey.com>

	Use 'name' in DAP start_thread function
	The DAP start_thread helper function has a 'name' parameter that is
	unused.  Apparently I forgot to hook it up to the thread constructor.
	This patch fixes the oversight.

2023-07-23  Tom Tromey  <tom@tromey.com>

	Export gdb.block_signals and create gdb.Thread
	While working on an experiment, I realized that I needed the DAP
	block_signals function.  I figured other developers may need it as
	well, so this patch moves it from DAP to the gdb module and exports
	it.

	I also added a new subclass of threading.Thread that ensures that
	signals are blocked in the new thread.

	Finally, this patch slightly rearranges the documentation so that
	gdb-side threading issues and functions are all discussed in a single
	node.

2023-07-23  Andrew Burgess  <aburgess@redhat.com>

	gdb: two changes to linux_nat_debug_printf calls in linux-nat.c
	This commit adjusts some of the debug output in linux-nat.c, but makes
	no other functional changes to GDB.

	In resume_lwp I've added the word "sibling" to one of the debug
	messages.  All the other debug messages in this function talk about
	operating on the sibling thread, so I think it makes sense, for
	consistency, if the message I've updated also talks about the sibling
	thread.

	In resume_stopped_resumed_lwps I've reordered the condition checks so
	that the vfork-parent check now happens after the checks for whether
	the thread is already resumed or not.  This makes no functional
	difference to GDB, but does, I think, mean we see more helpful debug
	messages first.

	Consider the situation where a vfork-parent thread is already resumed,
	and resume_stopped_resumed_lwps is called.  Previously the message
	saying that the thread was not being resumed due to being a
	vfork-parent, was printed.  This might give the impression that the
	thread is left in a not resumed state, which is misleading.

	After this change we now get a message saying that the thread is not
	being resumed due to it not being stopped (i.e. is already resumed).
	With this message the already resumed nature of the thread is much
	clearer.

	I found this change helpful when debugging some vfork related issues.

2023-07-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: replace $testfile with $binfile in one case
	For *reasons* I was hacking on gdb.base/foll-vfork.exp and wanted to
	change the name of the binary that was created.  Should be easy, I
	adjusted the global $binfile variable .... but that didn't work.

	In one place the script uses $testfile instead of $binfile.

	Fixed this to use $binfile, now I can easily change the name of the
	generated binary, and the test still works.

	There's no change in what is tested after this commit.

2023-07-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve gdb.arch/arm-pthread_cond_timedwait-bt.exp
	I noticed in test-case gdb.arch/arm-pthread_cond_timedwait-bt.exp that
	prepare_for_testing is used, followed by a clean_restart.

	This calls clean_restart twice in a row.

	Fix this by using build_executable instead.

	Also, I noticed that the test-case requires an SVC instruction, so add a
	require to limit the test-case to supported architectures.

	While we're at it, run M-x indent-region in emacs to fix indentation.

	Tested on x86_64-linux.

2023-07-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use proc readnow in two test-cases
	Use "require !readnow" in two test-cases, instead of the written-out variant.

	Tested on x86_64-linux, with target boards unix and readnow.

2023-07-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-21  Tom Tromey  <tom@tromey.com>

	Fix crash with DW_FORM_implicit_const
	Jakub pointed out that using DW_FORM_implicit_const with
	DW_AT_bit_size would cause gdb to crash.  This happened because
	DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned
	to assert.  This patch fixes the problem.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-07-21  David Faust  <david.faust@oracle.com>

	bpf: disasemble offsets of value 0 as "+0"
	This tiny patch makes the BPF disassembler to emit, e.g.

	  ldxdw %r1, [%r0+0]

	instead of

	  ldxdw %r1, [%r00]

	when the offset is 0, to avoid confusion.

	opcodes/

		* bpf-dis.c (print_insn_bpf): Print offsets with value 0 as "+0".

	gas/

		* testsuite/gas/bpf/mem.s: Add tests with offset 0.
		* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
		* testsuite/gas/bpf/mem.d: Update accordingly.
		* testsuite/gas/bpf/mem-be.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Implement DAP modules request
	This implements the DAP "modules" request, and also arranges to add
	the module ID to stack frames.

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Add Progspace.objfile_for_address
	This adds a new objfile_for_address method to gdb.Progspace.  This
	makes it easy to find the objfile for a given address.

	There's a related PR; and while this change would have been sufficient
	for my original need, it's not clear to me whether I should close the
	bug.  Nevertheless I think it makes sense to at least mention it here.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Remove unused imports
	I noticed an unused import in dap/evaluate.py; and also I found out
	that my recent changes to use frame filters from DAP left some unused
	imports in dap/bt.py.

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Document array indexing for Python gdb.Value
	I noticed that the documentation for gdb.Value doesn't mention array
	indexing.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: opcodes, gas: support for signed load V4 instructions
	This commit adds the signed load to register (ldxs*) instructions
	introduced in the BPF ISA version 4, including opcodes and assembler
	tests.

	Tested in bpf-unknown-none.

	include/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* opcode/bpf.h (enum bpf_insn_id): Add entries for signed load
		instructions.
		(BPF_MODE_SMEM): Define.

	opcodes/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Add entries for LDXS{B,W,H,DW}
		instructions.

	gas/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/mem.s: Add signed load instructions.
		* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
		* testsuite/gas/bpf/mem.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem-be.d: Likewise.
		* doc/c-bpf.texi (BPF Instructions): Document the signed load
		instructions.

2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: opcodes, gas: support for signed register move V4 instructions
	This commit adds the signed register move (movs) instructions
	introduced in the BPF ISA version 4, including opcodes and assembler
	tests.

	Tested in bpf-unknown-none.

	include/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* opcode/bpf.h (BPF_OFFSET16_MOVS8): Define.
		(BPF_OFFSET16_MOVS16): Likewise.
		(BPF_OFFSET16_MOVS32): Likewise.
		(enum bpf_insn_id): Add entries for MOVS{8,16,32}R and
		MOVS32{8,16,32}R.

	opcodes/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* bpf-opc.c (bpf_opcodes): Add entries for MOVS{8,16,32}R and
		MOVS32{8,16,32}R instructions.  and MOVS32I instructions.

	gas/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/alu.s: Test movs instructions.
		* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu32.s: Likewise for movs32 instruction.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu.d: Add expected results.
		* testsuite/gas/bpf/alu32.d: Likewise.
		* testsuite/gas/bpf/alu-be.d: Likewise.
		* testsuite/gas/bpf/alu32-be.d: Likewise.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Remove redundant @findex from python.texi
	In a review, Eli pointed out that @findex is redundant when used with
	@defun.  This patch removes all such uses from python.texi, plus a
	couple uses before @defvar that are also unnecessary.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Fix typo in py-type.c docstring
	I noticed that a doc string py-type.c says "an signed".
	This patch corrects it to "a signed".

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Implement Ada target name symbol
	Ada 2022 adds the "target name symbol", which can be used on the right
	hand side of an assignment to refer to the left hand side.  This
	allows for convenient updates.  This patch implements this for gdb's
	Ada expression parser.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Add instruction bytes to DAP disassembly response
	The DAP disassemble command lets the client return the underlying
	bytes of the instruction in an implementation-defined format.  This
	patch updates gdb to return this, and simply uses a hex string of the
	bytes as the format.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-07-21  Tom Tromey  <tromey@adacore.com>

	Remove ancient Ada workaround
	I ran across this very old code in gdb's Ada support.  After a bit of
	archaeology, we couldn't determine what bug this might have been
	working around.  It is no longer needed, so this patch removes it.

	As this is entirely Ada-specific and was reviewed and tested at
	AdaCore, I'm checking it in.

2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

	bpf: add missing bpf-dis.c to opcodes/Makefile.am
	This was breaking --enable-targets=all builds.

	opcodes/ChangeLog:

	2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* Makefile.am (TARGET64_LIBOPCODES_CFILES): Add missing bpf-dis.c
		* Makefile.in: Regenerate.

2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

	sim/bpf: desCGENization of the BPF simulator
	The BPF port in binutils has been rewritten (commit
	d218e7fedc74d67837d2134120917f4ac877454c) in order to not be longer
	based on CGEN.  Please see that commit log for more information.

	This patch updates the BPF simulator accordingly.  The new
	implementation is much simpler and it is based on the new BPF opcodes.

	Tested with target bpf-unknown-none with both 64-bit little-endian
	host and 32-bit little-endian host.

	Note that I have not tested in a big-endian host yet.  I will do so
	once this lands upstream so I can use the GCC compiler farm.

2023-07-21  Jose E. Marchesi  <jose.marchesi@oracle.com>

	DesCGENization of the BPF binutils port
	CGEN is cool, but the BPF architecture is simply too bizarre for it.

	The weird way of BPF to handle endianness in instruction encoding, the
	weird C-like alternative assembly syntax, the weird abuse of
	multi-byte (or infra-byte) instruction fields as opcodes, the unusual
	presence of opcodes beyond the first 32-bits of some instructions, are
	all examples of what makes it a PITA to continue using CGEN for this
	port.  The bpf.cpu file is becoming so complex and so nested with
	p-macros that it is very difficult to read, and quite challenging to
	update.  Also, every time we are forced to change something in CGEN to
	accommodate BPF requirements (which is often) we have to do extensive
	testing to make sure we do not break any other target using CGEN.

	This is getting un-maintenable.

	So I have decided to bite the bullet and revamp/rewrite the port so it
	no longer uses CGEN.  Overall, this involved:

	* To remove the cpu/bpf.{cpu,opc} descriptions.

	* To remove the CGEN generated files.

	* To replace the CGEN generated opcodes table with a new hand-written
	  opcodes table for BPF.

	* To replace the CGEN generated disassembler wih a new disassembler
	  that uses the new opcodes.

	* To replace the CGEN generated assembler with a new assembler that uses the
	  new opcodes.

	* To replace the CGEN generated simulator with a new simulator that uses the
	  new opcodes. [This is pushed in GDB in another patch.]

	* To adapt the build systems to the new situation.

	Additionally, this patch introduces some extensions and improvements:

	* A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF
	  relocation R_BPF_GNU_64_16 are added to the BPF BFD port.  These
	  relocations are used for section-relative 16-bit offsets used in
	  load/store instructions.

	* The disassembler now has support for the "pseudo-c" assembly syntax of
	  BPF.  What dialect to use when disassembling is controlled by a command
	  line option.

	* The disassembler now has support for dumping instruction immediates in
	  either octal, hexadecimal or decimal.  The used output base is controlled
	  by a new command-line option.

	* The GAS BPF test suite has been re-structured and expanded in order to
	  test the disassembler pseudoc syntax support.  Minor bugs have been also
	  fixed there.  The assembler generic tests that were disabled for bpf-*-*
	  targets due to the previous implementation of pseudoc syntax are now
	  re-enabled.  Additional tests have been added to test the new features of
	  the assembler.  .dump files are no longer used.

	* The linker BPF test suite has been adapted to the command line options
	  used by the new disassembler.

	The result is very satisfactory.  This patchs adds 3448 lines of code
	and removes 10542 lines of code.

	Tested in:

	* Target bpf-unknown-none with 64-bit little-endian host and 32-bit
	  little-endian host.

	* Target x86-64-linux-gnu with --enable-targets=all

	Note that I have not tested in a big-endian host yet.  I will do so
	once this lands upstream so I can use the GCC compiler farm.

	I have not included ChangeLog entries in this patch: these would be
	massive and not very useful, considering this is pretty much a rewrite
	of the port.  I beg the indulgence of the global maintainers.

2023-07-21  Lancelot Six  <lancelot.six@amd.com>

	gdb/solib-rocm: limit the number of opened file descriptors
	ROCm programs can load a high number of compute kernels on GPU devices,
	especially if lazy code-object loading have been disabled.  Each code
	object containing such program is loaded once for each device available,
	and each instance is reported by GDB as an individual shared library.

	We came across situations where the number of shared libraries opened by
	GDB gets higher than the allowed number of opened files for the process.
	Increasing the opened files limit works around the problem, but there is a
	better way this patch proposes to follow.

	Under the hood, the GPU code objects are embedded inside the host
	application binary and shared library binaries.  GDB currently opens the
	underlying file once for each shared library it sees.  That means that
	the same file is re-opened every time a code object is loaded on a GPU.

	This patch proposes to only open each underlying file once.  This is
	done by implementing a reference counting mechanism so the underlying
	file is opened when the underlying file first needs to be opened, and
	closed when the last BFD using the underlying file is closed.

	On a program where GDB used to open about 1500 files to load all shared
	libraries, this patch makes it so only 54 opened file descriptors are
	needed.

	I have tested this patch on downstream ROCgdb's full testsuite and
	upstream GDB testsuite with no regression.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-21  Jan Beulich  <jbeulich@suse.com>

	x86: adjust disassembly of insns operating on selector values
	Bring disassembly back in line with what the assembler accepts, thus
	also making it self-consistent (with, in particular selector load/store
	insns). While there further add D to all affected insns except ARPL
	(where S is used, matching LAR/LSL), to also behave correctly in suffix-
	always mode.

	While there also hook up the Intel variant of the LKGS test.

2023-07-21  Jan Beulich  <jbeulich@suse.com>

	x86: simplify disassembly of LAR/LSL
	For whatever reason in c9f5b96bdab0 ("x86: correct handling of LAR and
	LSL") I didn't realize that we can easily use Sv instead of going
	through mod_table[]. Redo this aspect of that change.

2023-07-21  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Add optimized out static var to cooked index
	Consider the test-case:
	...
	$ cat main.c
	int main (void) { return 0; }
	$ cat static-optimized-out.c
	static int aaa;
	...
	compiled like this:
	...
	$ gcc-12 static-optimized-out.c main.c -g -O2 -flto
	...

	There's a difference in behaviour depending on symtab expansion state:
	...
	$ gdb -q -batch a.out -ex "print aaa"
	No symbol "aaa" in current context.
	$ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa"
	$1 = <optimized out>
	...

	The reason for the difference is that the optimized out variable aaa:
	...
	 <1><104>: Abbrev Number: 2 (DW_TAG_variable)
	    <105>   DW_AT_name        : aaa
	    <109>   DW_AT_decl_file   : 1
	    <10a>   DW_AT_decl_line   : 18
	    <10b>   DW_AT_decl_column : 12
	    <10c>   DW_AT_type        : <0x110>
	...
	is not added to the cooked index because of this clause in abbrev_table::read:
	...
	     else if (!has_location && !has_specification_or_origin && !has_external
		       && cur_abbrev->tag == DW_TAG_variable)
		cur_abbrev->interesting = false;
	...

	Fix this inconsistency by making sure that the optimized out variable is added
	to the cooked index.

	Regression tested on x86_64-linux.

	Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf
	assembly test-case gdb.dwarf2/static-optimized-out.exp.

	Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now
	consistently get:
	...
	(gdb) print aaa^M
	$1 = <optimized out>^M
	...
	and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get:
	...
	(gdb) print aaa^M
	No symbol "aaa" in current context.^M
	...
	due to missing debug info for the variable.

	PR symtab/30656
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-21  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix superfluous newline for long prompt
	In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size
	as the terminal width, we get a superfluous newline at line 19:
	...
	16 (gdb) set prompt 123456789A123456789B123
	17 456789C123456789>
	18 123456789A123456789B123456789C123456789>
	19
	20 123456789A123456789B123456789C123456789>
	21 set prompt (gdb)
	22 (gdb)
	...
	as well as a superfluous repetition of the prompt at line 20 once we type the
	's' starting "set prompt".

	I traced the superfluous newline back to readline's readline_internal_setup,
	that does:
	...
	  /* If we're not echoing, we still want to at least print a prompt, because
	     rl_redisplay will not do it for us.  If the calling application has a
	     custom redisplay function, though, let that function handle it. */
	  if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay)
	    ...
	  else
	    {
	      if (rl_prompt && rl_already_prompted)
		rl_on_new_line_with_prompt ();
	      else
		rl_on_new_line ();
	      (*rl_redisplay_function) ();
	...
	and then we hit the case that calls rl_on_new_line_with_prompt, which does:
	...
	  /* If the prompt length is a multiple of real_screenwidth, we don't know
	     whether the cursor is at the end of the last line, or already at the
	     beginning of the next line. Output a newline just to be safe. */
	  if (l > 0 && (l % real_screenwidth) == 0)
	    _rl_output_some_chars ("\n", 1);
	...

	This doesn't look like a readline bug, because the behaviour matches the
	comment.

	[ And the fact that the output of the newline doesn't happen in the scope of
	tui_redisplay_readline means it doesn't get the prompt wrap detection
	treatment, causing start_line to be incorrect, which causes the superfluous
	repetition of the prompt. ]

	I looked at ways to work around this, and managed by switching off
	rl_already_prompted, which we set to 1 in tui_rl_startup_hook:
	...
	/* Readline hook to redisplay ourself the gdb prompt.
	   In the SingleKey mode, the prompt is not printed so that
	   the command window is cleaner.  It will be displayed if
	   we temporarily leave the SingleKey mode.  */
	static int
	tui_rl_startup_hook (void)
	{
	  rl_already_prompted = 1;
	  if (tui_current_key_mode != TUI_COMMAND_MODE
	      && !gdb_in_secondary_prompt_p (current_ui))
	    tui_set_key_mode (TUI_SINGLE_KEY_MODE);
	  tui_redisplay_readline ();
	  return 0;
	}
	...

	Then I started looking at why rl_already_prompted is set to 1.

	The use case for rl_already_prompted seems to be:
	- app (application, the readline user) outputs prompt,
	- app sets rl_already_prompted to 1, and
	- app calls readline, which calls rl_on_new_line_with_prompt, which figures
	  out how long the prompt is, and sets a few readline variables accordingly,
	  which can be used in the following call to rl_redisplay_function.

	AFAICT, TUI does not fit this pattern.  It does not output an initial prompt,
	rather it writes the prompt in every rl_redisplay_function.  It doesn't use
	the variables set by rl_on_new_line_with_prompt, instead it figures stuff out
	by itself.

	Fix this by removing the rl_already_prompted setting.

	Also remove the call to tui_redisplay_readline, it's not necessary, the
	function is called anyway.

	Tested on x86_64-linux, no regressions.

2023-07-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-20  Alan Modra  <amodra@gmail.com>

	MIPS: Don't move __gnu_lto_slim to .scommon
		* elfxx-mips.c (_bfd_mips_elf_symbol_processing): Don't treat
		__gnu_lto_slim as SHN_MIPS_SCOMMON.
		(_bfd_mips_elf_add_symbol_hook): Likewise.

2023-07-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-19  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Update status of the entire regset in regcache
	In the current code, when a register is fetched, the entire regset
	are fetched via ptrace, but only this register status is updated in
	regcache, it needs to fetch the same regset through ptrace again if
	another register in this regset is fetched later, this is obviously
	unnecessary. It is proper to update the status of the entire regset
	in regcache when fetching a register via ptrace.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-07-19  Pedro Alves  <pedro@palves.net>

	Fix gdb.Inferior.read_memory without execution (PR dap/30644)
	Andrew reported that the previous change to gdb.Inferior.read_memory &
	friends introducing scoped_restore_current_inferior_for_memory broke
	gdb.dap/stop-at-main.exp.  This is also reported as PR dap/30644.

	The root of the problem is that all the methods that now use
	scoped_restore_current_inferior_for_memory cause GDB to crash with a
	failed assert if they are run on an inferior that is not yet started.

	E.g.:

	 (gdb) python i = gdb.selected_inferior ()
	 (gdb) python i.read_memory (4,4)
	 gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed.

	This patch fixes the problem by removing
	scoped_restore_current_inferior_for_memory's ctor ptid parameter and
	the any_thread_of_inferior calls completely, and making
	scoped_restore_current_inferior_for_memory switch inferior_ptid to a
	pid ptid.

	I was a little worried that some port might be assuming inferior_ptid
	points at a thread in the xfer_partial memory access routines.  We
	know that anything that supports forks must not assume that, due to
	how detach_breakpoints works.  I looked at a number of xfer_partial
	implementations, and didn't see anything that is looking at
	inferior_ptid in a way that would misbehave.  I'm thinking that we
	could go forward with this and just fix ports if they break.

	While on some ports like on AMD GPU we have thread-specific address
	spaces, and so when accessing memory for those address spaces, we must
	have the right thread context (via inferior_ptid) selected, in
	Inferior.read_memory, we only have the inferior to work with, so this
	API as is can't be used to access thread-specific address spaces.
	IOW, it can only be used to access the global address space that is
	visible to both the CPU and the GPUs.

	In proc-service.c:ps_xfer_memory, the other spot using
	scoped_restore_current_inferior_for_memory, we're always accessing
	per-inferior memory.

	If we end up using scoped_restore_current_inferior_for_memory later to
	set up the context to read memory from a specific thread, then we can
	add an alternative ctor that takes a thread_info pointer, and make
	inferior_ptid point to the thread, for example.

	New test added to gdb.python/py-inferior.exp, exercising
	Inferior.read_memory without execution.

	No regressions on native and extended-gdbserver x86_64 GNU/Linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644
	Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19

2023-07-19  Nick Clifton  <nickc@redhat.com>

	Updated Romainian translation for the opcodes directory

2023-07-19  Lancelot SIX  <lancelot.six@amd.com>

	gdb/amd-dbgapi-target: Use inf param in detach
	Current implementation of amd_dbgapi_target::detach (inferior *, int)
	does the following:

	  remove_breakpoints_inf (current_inferior ());
	  detach_amd_dbgapi (inf);
	  beneath ()->detach (inf, from_tty);

	I find that using a mix of `current_inferior ()` and `inf` disturbing.
	At this point, we know that both are the same (target_detach does assert
	that `inf == current_inferior ()` before calling target_ops::detach).

	To improve consistency, this patch replaces `current_inferior ()` with
	`inf` in amd_dbgapi_target::detach.

	Change-Id: I01b7ba2e661c25839438354b509d7abbddb7c5ed
	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0
	With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into:
	...
	(gdb) ptype global_c^M
	^M
	Thread 1 "xgdb" hit Breakpoint 3, \
	  _Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \
	  gdb/c-typeprint.c:175^M
	175     {^M
	(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
	...

	This is a problem with the debug info, which marks the CU containing the
	function declaration as C rather than C++.  This is fixed in gcc 8 and later.

	Work around this compiler problem by allowing the mangled name.

	Tested on x86_64-linux.

	PR testsuite/30648
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648

2023-07-19  Alan Modra  <amodra@gmail.com>

	[GOLD, PowerPC64] Debug info relocation overflow
	It is possible to build huge binaries on powerpc64, where 32-bit
	addresses in debug info are insufficient to descibe locations in the
	binary.  Help out the user, and only warn about debug overflows.

		* powerpc.cc (Target_powerpc::Relocate::relocate): Warn on
		relocation overflows in debug info.

2023-07-19  Alan Modra  <amodra@gmail.com>

	Tidy binutils configure
	Separate out some of the defines from the block handling windows
	support, so they don't get lost.  Delete an unused variable.

2023-07-19  Alan Modra  <amodra@gmail.com>

	Build all the objdump extensions with --enable-targets=all
	Only the xcoff and pe extensions were enabled.  Build the lot, and fix
	some more printf format problems when the host is 32-bit.

		* configure.ac (od_vectors): Set up for --enable-targets=all.
		* configure: Regenerate.
		* od-elf32_avr.c (elf32_avr_dump_mem_usage): Correct format
		specifier vs. arg mismatch.
		(elf32_avr_dump_avr_prop): Likewise.

2023-07-19  Alan Modra  <amodra@gmail.com>

	gas 32-bit host compile warnings
		* config/tc-d10v.c (find_opcode): Correct format specifier vs.
		arg mismatch.
		* config/tc-m68hc11.c (fixup8, fixup16, fixup24, fixup8_xg): Likewise.
		* config/tc-vax.c (md_assemble): Likewise.
		* config/tc-xtensa.c (dump_litpools): Likewise.
		* config/tc-z80.c (emit_data_val, emit_byte): Likewise.

2023-07-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-18  Nick Clifton  <nickc@redhat.com>

	Updated Swedish translation for the binutils subdirectory

2023-07-18  Pter Chubb  <peter.chubb@unsw.edu.au>

	PR 30632 - ld segfaults if linker script includes a STARTUP line.

2023-07-18  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Supports Zcb extension.
	This patch support Zcb extension, contains new compressed instructions,
	some instructions depend on other existed extension, like 'zba', 'zbb'
	and 'zmmul'.  Zcb also imply Zca extension to enable the compressing
	features.

	Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
	Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
	Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
	Co-Authored by: Simon Cook <simon.cook@embecosm.com>
	Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
	Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>

	bfd/ChangeLog:

	        * elfxx-riscv.c (riscv_multi_subset_supports): New extension.
	        (riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

	        * config/tc-riscv.c (validate_riscv_insn): New operators.
	        (riscv_ip): Ditto.
	        * testsuite/gas/riscv/zcb.d: New test.
	        * testsuite/gas/riscv/zcb.s: New test.

	include/ChangeLog:

	        * opcode/riscv-opc.h (MATCH_C_LBU): New opcode.
	        (MASK_C_LBU): New mask.
	        (MATCH_C_LHU): New opcode.
	        (MASK_C_LHU): New mask.
	        (MATCH_C_LH): New opcode.
	        (MASK_C_LH): New mask.
	        (MATCH_C_SB): New opcode.
	        (MASK_C_SB): New mask.
	        (MATCH_C_SH): New opcode.
	        (MASK_C_SH): New mask.
	        (MATCH_C_ZEXT_B): New opcode.
	        (MASK_C_ZEXT_B): New mask.
	        (MATCH_C_SEXT_B): New opcode.
	        (MASK_C_SEXT_B): New mask.
	        (MATCH_C_ZEXT_H): New opcode.
	        (MASK_C_ZEXT_H): New mask.
	        (MATCH_C_SEXT_H): New opcode.
	        (MASK_C_SEXT_H): New mask.
	        (MATCH_C_ZEXT_W): New opcode.
	        (MASK_C_ZEXT_W): New mask.
	        (MATCH_C_NOT): New opcode.
	        (MASK_C_NOT): New mask.
	        (MATCH_C_MUL): New opcode.
	        (MASK_C_MUL): New mask.
	        (DECLARE_INSN): New opcode.
	        * opcode/riscv.h (EXTRACT_ZCB_BYTE_UIMM): New inline func.
	        (EXTRACT_ZCB_HALFWORD_UIMM): Ditto.
	        (ENCODE_ZCB_BYTE_UIMM): Ditto.
	        (ENCODE_ZCB_HALFWORD_UIMM): Ditto.
	        (VALID_ZCB_BYTE_UIMM): Ditto.
	        (VALID_ZCB_HALFWORD_UIMM): Ditto.
	        (enum riscv_insn_class): New extension class.

	opcodes/ChangeLog:

	        * riscv-dis.c (print_insn_args): New operators.
	        * riscv-opc.c: New instructions.

2023-07-18  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Support Zca/f/d extensions.
	This patch add Zca/f/d extensions support, since all ZC*
	extensions will imply Zca extension, just enabled compress
	feature when Zca extension is available.

	Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
	Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
	Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
	Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
	Co-Authored by: Simon Cook <simon.cook@embecosm.com>
	Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
	Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
		(riscv_multi_subset_supports_ext): Ditto.

	gas/ChangeLog:

		* config/tc-riscv.c (riscv_set_arch): Extend compress check.
		* testsuite/gas/riscv/zca.d: New test.
		* testsuite/gas/riscv/zca.s: New test.
		* testsuite/gas/riscv/zcd.d: New test.
		* testsuite/gas/riscv/zcd.s: New test.
		* testsuite/gas/riscv/zcf.d: New test.
		* testsuite/gas/riscv/zcf.s: New test.

2023-07-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-17  Tom Tromey  <tromey@adacore.com>

	Remove unused declaration of child_terminal_init_with_pgrp
	child_terminal_init_with_pgrp is declared but not defined.  This patch
	removes the declaration.  Tested by grep and rebuilding.

2023-07-17  Michael Matz  <matz@suse.de>

	Also support '^=' in linker script expressions
	this requires also changes in ldgram.y and ldexp.c, unlike
	accepting '^' only.  But let's do this anyway, if only for
	symmetry.

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: additional debug output in infrun.c and linux-nat.c
	While working on some of the recent patches relating to vfork handling
	I found this debug output very helpful, I'd like to propose adding
	this into GDB.

	With debug turned off there should be no user visible changes after
	this commit.

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp
	While working on gdb.base/foll-vfork.exp I noticed that there are
	several random 'sleep' calls throughout the test.

	The comment suggests these are to allow for output from a vforked
	child to arrive, but in each case the test is about to close and
	restart GDB, so I don't see how random output from a child process
	could impact testing.

	I removed the sleep calls and couldn't reproduce any failures from
	this test, I left the test running for a couple of hours, and tried
	loading my machine, and the test seems fine with these removed.

	I've left this as a separate commit so that if, in the future, someone
	can show that these are required, it will be easy to revert this one
	patch and bring them back.

	There should be no change in what is tested after this commit.

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: expand gdb.base/foll-vfork.exp
	This commit provides tests for all of the bugs fixed in the previous
	four commits, this is achieved by expanding gdb.base/foll-vfork.exp to
	run with different configurations:

	  * target-non-stop on/off
	  * non-stop on/off
	  * schedule-multiple on/off

	We don't test with schedule-multiple on if we are using a remote
	target, this is due to bug gdb/30574.  I've added a link to that bug
	in this commit, but all this commit does is expose that bug, there's
	no fixes here.

	Some of the bugs fixed in the previous commits are very timing
	dependent, as such, they don't always show up.  I've had more success
	when running this test on a very loaded machine -- I usually run ~8
	copies of the test in parallel, then the bugs would normally show up
	pretty quickly.

	Other than running the test in more configurations, I've not made any
	changes to what is actually being tested, other than in one place
	where, when testing with non-stop mode, GDB stops in a different
	inferior, as such I had to add a new 'inferior 2' call, this can be
	found in vfork_relations_in_info_inferiors.

	I have cleaned things up a little, for example, making use of
	proc_with_prefix to remove some with_test_prefix calls.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30574

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't resume vfork parent while child is still running
	Like the last few commit, this fixes yet another vfork related issue.
	Like the commit titled:

	  gdb: don't restart vfork parent while waiting for child to finish

	which addressed a case in linux-nat where we would try to resume a
	vfork parent, this commit addresses a very similar case, but this time
	occurring in infrun.c.  Just like with that previous commit, this bug
	results in the assert:

	  x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.

	In this case the issue occurs when target-non-stop is on, but non-stop
	is off, and again, schedule-multiple is on.  As with the previous
	commit, GDB is in follow-fork-mode child.  If you have not done so, it
	is worth reading the earlier commit as many of the problems leading to
	the failure are the same, they just appear in a different part of GDB.

	Here are the steps leading to the assertion failure:

	  1. The user performs a 'next' over a vfork, GDB stop in the vfork
	  child,

	  2. As we are planning to follow the child GDB sets the vfork_parent
	  and vfork_child member variables in the two inferiors, the
	  thread_waiting_for_vfork_done member is left as nullptr, that member
	  is only used when GDB is planning to follow the parent inferior,

	  3. The user does 'continue', our expectation is that the vfork child
	  should resume, and once that process has exited or execd, GDB should
	  detach from the vfork parent.  As a result of the 'continue' GDB
	  eventually enters the proceed function,

	  4. In proceed we selected a ptid_t to resume, because
	  schedule-multiple is on we select minus_one_ptid (see
	  user_visible_resume_ptid),

	  5. As GDB is running in all-stop on top of non-stop mode, in the
	  proceed function we iterate over all threads that match the resume
	  ptid, which turns out to be all threads, and call
	  proceed_resume_thread_checked.  One of the threads we iterate over
	  is the vfork parent thread,

	  6. As the thread passed to proceed_resume_thread_checked doesn't
	  match any of the early return conditions, GDB will set the thread
	  resumed,

	  7. As we are resuming one thread at a time, this thread is seen by
	  the lower layers (e.g. linux-nat) as the "event thread", which means
	  we don't apply any of the checks, e.g. is this thread a
	  vfork parent, instead we assume that GDB core knows what it's doing,
	  and linux-nat will resume the thread, we have now incorrectly set
	  running the vfork parent thread when this thread should be waiting
	  for the vfork child to complete,

	  8. Back in the proceed function GDB continues to iterate over all
	  threads, and now (correctly) resumes the vfork child thread,

	  8. As the vfork child is still alive the kernel holds the vfork
	  parent stopped,

	  9. Eventually the child performs its exec and GDB is sent and EXECD
	  event.  However, because the parent is resumed, as soon as the child
	  performs its exec the vfork parent also sends a VFORK_DONE event to
	  GDB,

	  10. Depending on timing both of these events might seem to arrive in
	  GDB at the same time.  Normally GDB expects to see the EXECD or
	  EXITED/SIGNALED event from the vfork child before getting the
	  VFORK_DONE in the parent.  We know this because it is as a result of
	  the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
	  handle_vfork_child_exec_or_exit for details).  Further the comment
	  in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
	  when we remain attached to the child (not the parent) we should not
	  expect to see a VFORK_DONE,

	  11. If both events arrive at the same time then GDB will randomly
	  choose one event to handle first, in some cases this will be the
	  VFORK_DONE.  As described above, upon seeing a VFORK_DONE GDB
	  expects that (a) the vfork child has finished, however, in this case
	  this is not completely true, the child has finished, but GDB has not
	  processed the event associated with the completion yet, and (b) upon
	  seeing a VFORK_DONE GDB assumes we are remaining attached to the
	  parent, and so resumes the parent process,

	  12. GDB now handles the EXECD event.  In our case we are detaching
	  from the parent, so GDB calls target_detach (see
	  handle_vfork_child_exec_or_exit),

	  13. While this has been going on the vfork parent is executing, and
	  might even exit,

	  14. In linux_nat_target::detach the first thing we do is stop all
	  threads in the process we're detaching from, the result of the stop
	  request will be cached on the lwp_info object,

	  15. In our case the vfork parent has exited though, so when GDB
	  waits for the thread, instead of a stop due to signal, we instead
	  get a thread exited status,

	  16. Later in the detach process we try to resume the threads just
	  prior to making the ptrace call to actually detach (see
	  detach_one_lwp), as part of the process to resume a thread we try to
	  touch some registers within the thread, and before doing this GDB
	  asserts that the thread is stopped,

	  17. An exited thread is not classified as stopped, and so the assert
	  triggers!

	Just like with the earlier commit, the fix is to spot the vfork parent
	status of the thread, and not resume such threads.  Where the earlier
	commit fixed this in linux-nat, in this case I think the fix should
	live in infrun.c, in proceed_resume_thread_checked.  This function
	already has a similar check to not resume the vfork parent in the case
	where we are planning to follow the vfork parent, I propose adding a
	similar case that checks for the vfork parent when we plan to follow
	the vfork child.

	This new check will mean that at step #6 above GDB doesn't try to
	resume the vfork parent thread, which prevents the VFORK_DONE from
	ever arriving.  Once GDB sees the EXECD/EXITED/SIGNALLED event from
	the vfork child GDB will detach from the parent.

	There's no test included in this commit.  In a subsequent commit I
	will expand gdb.base/foll-vfork.exp which is when this bug would be
	exposed.

	If you do want to reproduce this failure then you will for certainly
	need to run the gdb.base/foll-vfork.exp test in a loop as the failures
	are all very timing sensitive.  I've found that running multiple
	copies in parallel makes the failure more likely to appear, I usually
	run ~6 copies in parallel and expect to see a failure after within
	10mins.

2023-07-17  Mihails Strasuns  <mihails.strasuns@intel.com>

	gdb, infrun: refactor part of `proceed` into separate function
	Split the thread resuming code from proceed into new function
	proceed_resume_thread_checked.

	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix an issue with vfork in non-stop mode
	This commit fixes a bug introduced by this commit:

	  commit d8bbae6ea080249c05ca90b1f8640fde48a18301
	  Date:   Fri Jan 14 15:40:59 2022 -0500

	      gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on)

	The problem can be seen in this GDB session:

	  $ gdb -q
	  (gdb) set non-stop on
	  (gdb) file ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork
	  Reading symbols from ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork...
	  (gdb) tcatch vfork
	  Catchpoint 1 (vfork)
	  (gdb) run
	  Starting program: /tmp/gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork

	  Temporary catchpoint 1 (vforked process 1375914), 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
	  (gdb) bt
	  #0  0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
	  #1  0x00000000004011af in main (argc=1, argv=0x7fffffffad88) at .../gdb/testsuite/gdb.base/foll-vfork.c:32
	  (gdb) finish
	  Run till exit from #0  0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
	  [Detaching after vfork from child process 1375914]
	  No unwaited-for children left.
	  (gdb)

	Notice the "No unwaited-for children left." error.  This is incorrect,
	given where we are stopped there's no reason why we shouldn't be able
	to use "finish" to return to the main frame.

	When the inferior is stopped as a result of the 'tcatch vfork', the
	inferior is in the process of performing the vfork, that is, GDB has
	seen the VFORKED event, but has not yet attached to the new child
	process, nor has the child process been resumed.

	However, GDB has seen the VFORKED, and, as we are going to follow the
	parent process, the inferior for the vfork parent will have its
	thread_waiting_for_vfork_done member variable set, this will point to
	the one and only thread that makes up the vfork parent process.

	When the "finish" command is used GDB eventually ends up in the
	proceed function (in infrun.c), in here we pass through all the
	function until we eventually encounter this 'else if' condition:

	   else if (!cur_thr->resumed ()
		     && !thread_is_in_step_over_chain (cur_thr)
		     /* In non-stop, forbid resuming a thread if some other thread of
			that inferior is waiting for a vfork-done event (this means
			breakpoints are out for this inferior).  */
		     && !(non_stop
			  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))
	      {

	The first two of these conditions will both be true, the thread is not
	already resumed, and is not in the step-over chain, however, the third
	condition, this one:

		     && !(non_stop
			  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))

	is false, and this prevents the thread we are trying to finish from
	being resumed.  This condition is false because (a) non_stop is true,
	and (b) cur_thr->inf->thread_waiting_for_vfork_done is not
	nullptr (see above for why).

	Now, if we check the comment embedded within the condition it says:

	     /* In non-stop, forbid resuming a thread if some other thread of
	        that inferior is waiting for a vfork-done event (this means
	        breakpoints are out for this inferior).  */

	And this makes sense, if we have a vfork parent with two thread, and
	one thread has performed a vfork, then we shouldn't try to resume the
	second thread.

	However, if we are trying to resume the thread that actually performed
	a vfork, then this is fine.  If we never resume the vfork parent then
	we'll never get a VFORK_DONE event, and so the vfork will never
	complete.

	Thus, the condition should actually be:

	     && !(non_stop
		  && cur_thr->inf->thread_waiting_for_vfork_done != nullptr
		  && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr))

	This extra check will allow the vfork parent thread to resume, but
	prevent any other thread in the vfork parent process from resuming.
	This is the same condition that already exists in the all-stop on a
	non-stop-target block earlier in the proceed function.

	My actual fix is slightly different to the above, first, I've chosen
	to use a nested 'if' check instead of extending the original 'else if'
	check, this makes it easier to write a longer comment explaining
	what's going on, and second, instead of checking 'non_stop' I've
	switched to checking 'target_is_non_stop_p'.  In this context this is
	effectively the same thing, a previous 'else if' block in proceed
	already handles '!non_stop && target_is_non_stop_p ()', so by the time
	we get here, if 'target_is_non_stop_p ()' then we must be running in
	non_stop mode.

	Both of these tweaks will make the next patch easier, which is a
	refactor to merge two parts of the proceed function, so this nested
	'if' block is not going to exist for long.

	For testing, there is no test included with this commit.  The test was
	exposed when using a modified version of the gdb.base/foll-vfork.exp
	test script, however, there are other bugs that are exposed when using
	the modified test script.  These bugs will be addressed in subsequent
	commits, and then I'll add the updated gdb.base/foll-vfork.exp.

	If you wish to reproduce this failure then grab the updates to
	gdb.base/foll-vfork.exp from the later commit and run this test, the
	failure is always reproducible.

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't restart vfork parent while waiting for child to finish
	While working on a later patch, which changes gdb.base/foll-vfork.exp,
	I noticed that sometimes I would hit this assert:

	  x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.

	I eventually tracked it down to a combination of schedule-multiple
	mode being on, target-non-stop being off, follow-fork-mode being set
	to child, and some bad timing.  The failing case is pretty simple, a
	single threaded application performs a vfork, the child process then
	execs some other application while the parent process (once the vfork
	child has completed its exec) just exits.  As best I understand
	things, here's what happens when things go wrong:

	  1. The parent process performs a vfork, GDB sees the VFORKED event
	  and creates an inferior and thread for the vfork child,

	  2. GDB resumes the vfork child process.  As schedule-multiple is on
	  and target-non-stop is off, this is translated into a request to
	  start all processes (see user_visible_resume_ptid),

	  3. In the linux-nat layer we spot that one of the threads we are
	  about to start is a vfork parent, and so don't start that
	  thread (see resume_lwp), the vfork child thread is resumed,

	  4. GDB waits for the next event, eventually entering
	  linux_nat_target::wait, which in turn calls linux_nat_wait_1,

	  5. In linux_nat_wait_1 we eventually call
	  resume_stopped_resumed_lwps, this should restart threads that have
	  stopped but don't actually have anything interesting to report.

	  6. Unfortunately, resume_stopped_resumed_lwps doesn't check for
	  vfork parents like resume_lwp does, so at this point the vfork
	  parent is resumed.  This feels like the start of the bug, and this
	  is where I'm proposing to fix things, but, resuming the vfork parent
	  isn't the worst thing in the world because....

	  7. As the vfork child is still alive the kernel holds the vfork
	  parent stopped,

	  8. Eventually the child performs its exec and GDB is sent and EXECD
	  event.  However, because the parent is resumed, as soon as the child
	  performs its exec the vfork parent also sends a VFORK_DONE event to
	  GDB,

	  9. Depending on timing both of these events might seem to arrive in
	  GDB at the same time.  Normally GDB expects to see the EXECD or
	  EXITED/SIGNALED event from the vfork child before getting the
	  VFORK_DONE in the parent.  We know this because it is as a result of
	  the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
	  handle_vfork_child_exec_or_exit for details).  Further the comment
	  in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
	  when we remain attached to the child (not the parent) we should not
	  expect to see a VFORK_DONE,

	  10. If both events arrive at the same time then GDB will randomly
	  choose one event to handle first, in some cases this will be the
	  VFORK_DONE.  As described above, upon seeing a VFORK_DONE GDB
	  expects that (a) the vfork child has finished, however, in this case
	  this is not completely true, the child has finished, but GDB has not
	  processed the event associated with the completion yet, and (b) upon
	  seeing a VFORK_DONE GDB assumes we are remaining attached to the
	  parent, and so resumes the parent process,

	  11. GDB now handles the EXECD event.  In our case we are detaching
	  from the parent, so GDB calls target_detach (see
	  handle_vfork_child_exec_or_exit),

	  12. While this has been going on the vfork parent is executing, and
	  might even exit,

	  13. In linux_nat_target::detach the first thing we do is stop all
	  threads in the process we're detaching from, the result of the stop
	  request will be cached on the lwp_info object,

	  14. In our case the vfork parent has exited though, so when GDB
	  waits for the thread, instead of a stop due to signal, we instead
	  get a thread exited status,

	  15. Later in the detach process we try to resume the threads just
	  prior to making the ptrace call to actually detach (see
	  detach_one_lwp), as part of the process to resume a thread we try to
	  touch some registers within the thread, and before doing this GDB
	  asserts that the thread is stopped,

	  16. An exited thread is not classified as stopped, and so the assert
	  triggers!

	So there's two bugs I see here.  The first, and most critical one here
	is in step #6.  I think that resume_stopped_resumed_lwps should not
	resume a vfork parent, just like resume_lwp doesn't resume a vfork
	parent.

	With this change in place the vfork parent will remain stopped in step
	instead GDB will only see the EXECD/EXITED/SIGNALLED event.  The
	problems in #9 and #10 are therefore skipped and we arrive at #11,
	handling the EXECD event.  As the parent is still stopped #12 doesn't
	apply, and in #13 when we try to stop the process we will see that it
	is already stopped, there's no risk of the vfork parent exiting before
	we get to this point.  And finally, in #15 we are safe to poke the
	process registers because it will not have exited by this point.

	However, I did mention two bugs.

	The second bug I've not yet managed to actually trigger, but I'm
	convinced it must exist: if we forget vforks for a moment, in step #13
	above, when linux_nat_target::detach is called, we first try to stop
	all threads in the process GDB is detaching from.  If we imagine a
	multi-threaded inferior with many threads, and GDB running in non-stop
	mode, then, if the user tries to detach there is a chance that thread
	could exit just as linux_nat_target::detach is entered, in which case
	we should be able to trigger the same assert.

	But, like I said, I've not (yet) managed to trigger this second bug,
	and even if I could, the fix would not belong in this commit, so I'm
	pointing this out just for completeness.

	There's no test included in this commit.  In a couple of commits time
	I will expand gdb.base/foll-vfork.exp which is when this bug would be
	exposed.  Unfortunately there are at least two other bugs (separate
	from the ones discussed above) that need fixing first, these will be
	fixed in the next commits before the gdb.base/foll-vfork.exp test is
	expanded.

	If you do want to reproduce this failure then you will for certainly
	need to run the gdb.base/foll-vfork.exp test in a loop as the failures
	are all very timing sensitive.  I've found that running multiple
	copies in parallel makes the failure more likely to appear, I usually
	run ~6 copies in parallel and expect to see a failure after within
	10mins.

2023-07-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: catch more errors in gdb.base/foll-vfork.exp
	For *reasons* I was looking at gdb.base/foll-vfork.exp.  This test
	script has a proc 'setup_gdb' that could (potentially) fail.  The
	setup_gdb proc is called from many places and I, initially, didn't
	think that we were checking if setup_gdb had failed or not.

	My confusion was because I didn't understand what this tcl construct
	did:

	  return -code return

	this will actually act as a return in the context of a proc's caller,
	effectively returning two levels of the call stack.  Neat (I guess).

	So it turns out my worries were misplaced, everywhere setup_gdb is
	called, if setup_gdb fails then we will (magically) return.

	However, I did spot one place where we managed to confuse ourselves
	with our cleverness.

	In check_vfork_catchpoints, this proc is called to check that GDB is
	able to catch vforks or not.  This proc is called early in the test
	script, and the intention is that, should this proc fail, we'll mark
	the whole test script as unsupported and then move onto the next test
	script.

	However, check_vfork_catchpoints also uses setup_gdb, and so, if that
	call to setup_gdb fails we'll end up returning immediately from
	check_vfork_catchpoints, and then continue with the test of _this_
	test script, which is not correct.

	To fix this I see two choices, one is remove the use of 'return -code
	return' from setup_gdb, however, this would require every use of
	setup_gdb to then be placed inside:

	  if { ![setup_gdb] } {
	    return
	  }

	Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints
	and check its return code.

	I chose the second option as this is the smaller code change.

	There should be no change in what is tested after this commit.

2023-07-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-16  Alan Modra  <amodra@gmail.com>

	PR10957, Missing option to really print section+offset
	Many of the reloc error messages have already been converted from
	using %C to using %H in ld.bfd, to print section+offset as well as
	file/line/function.  This catches a few remaining, and changes gold to
	do the same.

		PR 10957
	bfd/
		* elf32-sh.c (sh_elf_relocate_section): Use %H in error messages.
	gold/
		* object.cc (Relocate_info::location): Always report section+offset.
		* testsuite/debug_msg.sh: Adjust to suit.
		* testsuite/x32_overflow_pc32.sh: Likewise.
		* testsuite/x86_64_overflow_pc32.sh: Likewise.
	ld/
		* emultempl/pe.em (read_addend): Use %H in error message.
		* emultempl/pep.em (read_addend): Likewise.
		* ldcref.c (check_reloc_refs): Likewise.
		* ldmain.c (warning_find_reloc, undefined_symbol): Likewise.
		* pe-dll.c (pe_create_import_fixup): Likewise.
		* testsuite/ld-cris/undef2.d: Adjust expected output to suit.
		* testsuite/ld-cris/undef3.d: Likewise.
		* testsuite/ld-elf/shared.exp: Likewise.
		* testsuite/ld-i386/compressed1.d: Likewise.
		* testsuite/ld-ia64/line.exp: Likewise.
		* testsuite/ld-plugin/lto.exp: Likewise.
		* testsuite/ld-undefined/undefined.exp: Likewise.
		* testsuite/ld-x86-64/compressed1.d: Likewise.
		* testsuite/ld-x86-64/line.exp: Likewise.
		* testsuite/ld-x86-64/pr27587.err: Likewise.

2023-07-16  Alan Modra  <amodra@gmail.com>

	Support NEXT_SECTION in ALIGNOF and SIZEOF
	This patch is aimed at making __bss_start properly aligned with the
	first of any bss-style sections following.  Most of the work here
	involves keeping track of the last output section seen when processing
	the linker script.

	You can almost align __bss_start properly by using
	${RELOCATING+. = ALIGN(${DATA_SDATA-${NO_SMALL_DATA-ALIGNOF(.${SBSS_NAME}) != 0 ? ALIGNOF(.${SBSS_NAME}) : }}${BSS_PLT+ALIGNOF(.plt) != 0 ? ALIGNOF(.plt) : }ALIGNOF(.${BSS_NAME}));}
	and changing every place that defines NO_SMALL_DATA to use " ", but
	having two .plt sections (marked SPECIAL) on some backends foils that
	idea.  The problem is that you only want to pick up the following
	.plt, not the one preceeding __bss_start in the data segment if the
	backend decides that is the proper .plt section.

	Perhaps that could be fixed too, but I decided instead to extend the
	linker script a little.  THIS_SECTION and PREV_SECTION could easily be
	added too.

		* ld.texi (ALIGNOF, SIZEOF): Update and mention NEXT_SECTION.
		* ldexp.c (output_section_find): New function.
		(fold_name <ALIGNOF, SIZEOF>): Use output_section_find.
		(exp_fold_tree): Add os parameter.  Adjust all calls.
		(exp_fold_tree_no_dot, exp_get_vma, exp_get_power): Likewise.
		* ldexp.h (struct ldexp_control): Add last_os.
		(exp_fold_tree, exp_fold_tree_no_dot): Update prototypes.
		(exp_get_vma, exp_get_power): Likewise.
		* ldlang.c: Pass last output section to expression folder
		calls throughout file.
		(open_input_bfds): Add os parameter to track last os seen.
		(lang_size_sections_1): Rename output_section_statement param
		to current_os.  Track last os.
		(lang_do_assignments_1): Track last os.
		* scripttempl/arclinux.sc: Align to ALIGNOF NEXT_SECTION
		before defining __bss_start.
		* scripttempl/elf.sc: Likewise.
		* scripttempl/elf64bpf.sc: Likewise.
		* scripttempl/elf64hppa.sc: Likewise.
		* scripttempl/elf_chaos.sc: Likewise.
		* scripttempl/elfarc.sc: Likewise.
		* scripttempl/elfd10v.sc: Likewise.
		* scripttempl/elfxtensa.sc: Likewise.
		* scripttempl/epiphany_4x4.sc: Likewise.
		* scripttempl/iq2000.sc: Likewise.
		* scripttempl/mep.sc: Likewise.
		* scripttempl/nds32elf.sc: Likewise.
		* scripttempl/xstormy16.sc: Likewise.
		* testsuite/ld-x86-64/pe-x86-64-5.od: Update expected __bss_start.
		* testsuite/ld-x86-64/pe-x86-64-5.rd: Likewise.

2023-07-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle has_native_target in gdb.testsuite/gdb-caching-proc-consistency.exp
	With test-case gdb.testsuite/gdb-caching-proc-consistency.exp we run into:
	...
	ERROR: no fileid for xerxes
	Couldn't send help target native to GDB.
	UNRESOLVED: <exp>: have_native_target: initial: help target native
	...

	Fix this by handling have_native_target in
	gdb.testsuite/gdb-caching-proc-consistency.exp.

	Tested on x86_64-linux.

2023-07-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-15  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: make tui_win_info::title private
	This commit builds on this earlier work:

	  commit 9fe01a376b2fb096e4836e985ba316ce9dc02399
	  Date:   Thu Jun 29 11:26:55 2023 -0600

	      Update TUI window title when changed

	and makes tui_win_info::title private, renaming to m_title at the same
	time.  There's a new tui_win_info::title() member function to provide
	read-only access to the title.

	There should be no user visible changes after this commit.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-15  Andrew Burgess  <aburgess@redhat.com>

	gdb: style filenames in separate debug file warnings
	After the commit:

	  commit 6647f05df023b63bbe056e9167e9e234172fa2ca
	  Date:   Tue Jan 24 18:13:38 2023 +0100

	      gdb: defer warnings when loading separate debug files

	It was pointed out[1] that the warnings being deferred and then later
	emitted lacked styling.  The warnings lacked styling before the above
	commit, but it was suggested that the filenames in these warnings
	should be styled, and this commit does this.

	There were a couple of previous attempts[2][3][4] to solve this
	problem, but these all tried to extend the mechanism introduced in the
	above commit, the deferred warnings were placed directly into a
	std::vector, but now we tried to, when appropriate, style these
	warnings.  The review feedback that this approach looked too complex.

	So instead, this revision adds a new helper class 'deferred_warnings'
	which can be used to collect a set of deferred warnings, and then emit
	these deferred warnings later, if needed.  This helper class hides the
	complexity, so at the point the deferred warning is created no extra
	logic is required.

	The deferred_warnings class will style the deferred warnings only if
	gdb_stderr supports styling.  GDB's warnings are sent to gdb_stderr,
	so this should ensure we only style when expected.

	There was also review feedback[5] that all of the warnings should be
	bundled into a single string_file, this has not been done.  I feel
	pretty strongly that separate warnings should be emitted using
	separate "warning" calls.  If we do end up with multiple warnings in
	this case they aren't really related, one will be about looking up
	debug via .gnu_debuglink, while the other will be about build-id based
	lookup.  So I'd really rather keep the warnings separate.

	[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
	[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
	[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
	[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
	[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/

	Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-07-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/forward-spec.exp with read1
	When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run
	into:
	...
	    parent:     ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent
	7fdc1c002ed0) [ns]^M
	...

	The problem is using regexps containing '.' to avoid escaping, which makes
	them too generic.

	Fix this by eliminating the '.' from the regexps.

	Tested on x86_64-linux.

2023-07-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Use correct inferior in Inferior.read_memory et al
	A user noticed that Inferior.read_memory and a few other Python APIs
	will always use the currently selected inferior, not the one passed to
	the call.

	This patch fixes the bug by arranging to switch to the inferior.  I
	found this same issue in several APIs, so this fixes them all.

	I also added a few missing calls to INFPY_REQUIRE_VALID to these
	methods.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30615
	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Introduce scoped_restore_current_inferior_for_memory
	This introduces a new class,
	scoped_restore_current_inferior_for_memory, and arranges to use it in
	a few places.  This class is intended to handle setting up and
	restoring the various globals that are needed to read or write memory
	-- but without invalidating the frame cache.

	I wasn't able to test the change to aix-thread.c.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Remove obsolete comment from gdbthread.h
	A comment in gdbthread.h refers to a global that no longer exists.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Rename Python variable in py-inferior.exp
	py-inferior.exp creates a Python variable named 'str'.  This clashes
	with the built-in type of the same name and can be confusing when
	trying to evaluate Python code when debugging the test case.  This
	patch renames it.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Refactor py-inferior.exp
	This changes py-inferior.exp to make it a bit more robust when adding
	new inferiors during the course of the test.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Minor cleanups in py-inferior.exp
	While working on this series, I noticed a some oddities in
	py-inferior.exp.  One is an obviously incorrect comment, and the
	others are confusing test names.  This patch fixes these.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-14  Tom Tromey  <tromey@adacore.com>

	Revert "Simplify auto_load_expand_dir_vars and remove substitute_path_component"
	This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489.

	This commit was a refactoring to remove an xrealloc and simplify
	utils.[ch].  However, it has a flaw -- it mishandles a substitution
	like "$datadir/subdir".

	I am backing out the patch in the interests of fixing the regression
	before GDB 14.  It can be reinstated (with modifications) later if we
	like.

	Regression tested on x86-64 Fedora 36.

2023-07-14  John Baldwin  <jhb@FreeBSD.org>

	Test that native targets can read a tdesc without a process attached.
	This ensures that 'unset tdesc filename' does not generate any output
	on a "bare" native target inferior without an attached process.

	Add a have_native_target helper function for use with require.
	Move logic from auto-connect-native-target.exp into this helper.

2023-07-14  John Baldwin  <jhb@FreeBSD.org>

	*-linux-nat: Handle null inferior in read_description.
	Don't invoke ptrace in the target read_description method if there is
	not an active inferior to query via ptrace.  Instead, use the default
	register set for the architecture.

	Previously the native target could report an error from a failed
	ptrace operation when fetching a tdesc without an attached process.
	For example on Linux x86-64:

	(gdb) target native
	Done.  Use the "run" command to start a process.
	(gdb) unset tdesc filename
	Couldn't get CS register: No such process.

2023-07-14  John Baldwin  <jhb@FreeBSD.org>

	*-fbsd-nat: Handle null inferior in read_description.
	Don't invoke ptrace in the target read_description method if there is
	not an active inferior to query via ptrace.  Instead, use the default
	register set for the architecture.

	Previously the native target could report an error from a failed
	ptrace operation when fetching a tdesc without an attached process.
	For example on FreeBSD/amd64:

	(gdb) target native
	Done.  Use the "run" command to start a process.
	(gdb) unset tdesc filename
	Couldn't get registers: Operation not permitted.

2023-07-14  Tobias Burnus  <tobias@codesourcery.com>

	Re: Let '^' through the lexer
	Fix "make pdf".

2023-07-14  Bruno Larsen  <blarsen@redhat.com>

	gdb/doc: document '+' argument for 'list' command
	The command 'list' has accepted the argument '+' for many years already,
	but this option wasn't documented either in the texinfo docs or in the
	help text for the command.  This commit documents it.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-14  Bruno Larsen  <blarsen@redhat.com>

	gdb/cli: Improve UX when using list with no args
	When using "list" with no arguments, GDB will first print the lines
	around where the inferior is stopped, then print the next N lines until
	reaching the end of file, at which point it warns the user "Line X out
	of range, file Y only has X-1 lines.".  This is usually desirable, but
	if the user can no longer see the original line, they may have forgotten
	the current line or that a list command was used at all, making GDB's
	error message look cryptic. It was reported in bugzilla as PR cli/30497.

	This commit improves the user experience by changing the behavior of
	"list" slightly when a user passes no arguments.  It now prints that the
	end of the file has been reached and recommends that the user use the
	command "list ." instead.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-14  Bruno Larsen  <blarsen@redhat.com>

	gdb/cli: add '.' as an argument for 'list' command
	Currently, after the user has used the list command once, there is no
	self-contained way to ask GDB to print the location where the inferior is
	stopped.  The current best options require either using a separate
	command to scope out where the inferior is stopped, or using "list *$pc"
	requiring knowledge of GDB standard registers.  This commit adds a way
	to do that using '.' as a new argument for the 'list' command.  If the
	inferior isn't running, the command prints around the main function.

	Because this necessitated having the inferior running and the test was
	(seemingly unnecessarily) using printf in a non-essential way and it
	would make the resulting log harder to read for no benefit, it was
	replaced by a different statement.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-14  Bruno Larsen  <blarsen@redhat.com>

	gdb/cli: Factor out code to list lines around a given line
	A future patch will add more situations that calculates "lines around a
	certain point" to be printed using print_source_lines, and the logic
	could be re-used. As a preparation for those commits, this one factors
	out that part of the logic of the list command into its own function.
	No functional changes are expected

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30602 [2.41] gprofng test hangs on i686-linux-gnu
	There were several problems in the gprofng testing:
	 - we did not catch a timeout for each test.
	 - we used exit() to stop a failed test. But this stops all other tests.
	 - we used a time_t (long) type in smalltest.c instead of a long long type.

		PR gprofng/30602
		* configure.ac: Launch only native testing.
		* configure: Rebuild.
		* testsuite/config/default.exp: Set TEST_TIMEOUT.
		* testsuite/gprofng.display/setpath_map.exp: Use return instead of exit.
		* testsuite/gprofng.display/gp-archive.exp: Likewise.
		* testsuite/gprofng.display/gp-collect-app_F.exp: Likewise.
		* testsuite/gprofng.display/display.exp: Delete an unnecessary test
		for native testing.
		* testsuite/lib/display-lib.exp (run_native_host_cmd): Add timeout.
		* testsuite/lib/smalltest.c: Use a long long type instead of time_t.

2023-07-14  Alan Modra  <amodra@gmail.com>

	Make the default gas symbol hash table larger
	We may as well start with the symbol table a little larger, saving
	time resizing.  Even a simple C hello world compiled with -O2 -g will
	exceed 16 symbols (by well over 3 times with gcc-11).

		* symbols.c (symbol_begin): Create sy_hash with more entries.

2023-07-14  Alan Modra  <amodra@gmail.com>

	Fix loongarch build with gcc-4.5
		* loongarch-opc.c (loongarch_alias_opcodes): Don't trigger
		gcc-4.5 bug in handling of struct initialisation.

2023-07-14  Alan Modra  <amodra@gmail.com>

	More tidies to objcopy archive handling
	This makes sure copy_archive exits with ibfd and obfd closed.  Error
	paths didn't do that, leading to memory leaks.  None of this matters
	very much.

		* objcopy.c (copy_archive): bfd_close ibfd and obfd on error
		return paths.  Remove braces around "list" free.
		(copy_file): Don't close invalid file descriptor.

2023-07-14  Alan Modra  <amodra@gmail.com>

	AIX_WEAK_SUPPORT
	Making target code depend on a host define like _AIX52 is never
	correct, so out it goes.  Also, sort some config.bfd entries a little
	to make it more obvious there is a config difference between aix5.1
	and aix5.2.  These two changes should make no difference to anything
	in binutils.  The gas define of AIX_WEAK_SUPPORT on the other hand was
	wrong, so fix that.  Finally, fix some testsuite fails on aix < 5.2 by
	simply not running the tests.

	include/
		* coff/internal.h (C_WEAKEXT): Don't depend on _AIX52.
	bfd/
		* coffcode.h (coff_slurp_symbol_table): Don't depend on _AIX52.
		(coff_classify_symbol): Likewise.
		* config.bfd: Sort some entries.
	gas/
		* configure.ac (AIX_WEAK_SUPPORT): Don't set for aix5.[01].
		* configure: Regenerate.
		* testsuite/gas/ppc/aix.exp (xcoff-visibility-1*) Don't run
		for aix < 5.2.

2023-07-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-13  Tom Tromey  <tromey@adacore.com>

	Implement 'Enum_Val and 'Enum_Rep
	This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-07-13  Tom Tromey  <tromey@adacore.com>

	Remove ada_attribute_name
	ada_attribute_name uses an array that must be kept in sync with an
	enum -- but the comment here refers to an enum that no longer exists.
	Looking at the sole caller, I see this can only be called for two
	opcodes.  So, remove this entirely and inline it.

2023-07-13  Michael Matz  <matz@suse.de>

	Let '^' through the lexer
	so that the (existing) code in parser and expression evaluator
	actually get to see it and handle it as XOR.  Also adjust docu
	to match what's there.

2023-07-13  Alan Modra  <amodra@gmail.com>

	elf_object_p load of dynamic symbols
	This fixes an uninitialised memory access on a fuzzed file:
	0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2
	1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13
	2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9

	Hopefully it will also stop any attempt to load dynamic symbols from
	eu-strip debug files.

		* elfcode.h (elf_object_p): Do not attempt to load dynamic
		symbols for a file with no section headers until all the
		program headers are swapped in.  Do not fail on eu-strip debug
		files.

2023-07-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Assume HAVE_WBORDER
	The tui border-kind setting allows values acs, ascii and space.

	The values ascii and space however don't work well with !HAVE_WBORDER.

	Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
	support, which is now obsolete.

	Tested on x86_64-linux.

	PR tui/30580
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Make translate return entry->value instead of entry
	The only use of "entry = translate (...)" is entry->value.

	Simplify using the function by returning entry->value instead.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Merge tui border-kind corner translation tables
	The tables:
	- tui_border_kind_translate_ulcorner
	- tui_border_kind_translate_urcorner
	- tui_border_kind_translate_llcorner
	- tui_border_kind_translate_lrcorner
	are identical.

	Merge and rename to tui_border_kind_translate_corner.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Introduce translate_acs
	In function tui_update_variables we have the somewhat inconvenient:
	...
	  entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
	  int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
	...

	Add a new function translate_acs, that allows us to do the more straighforward:
	...
	  int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner,
				   ACS_LRCORNER);
	...

	By special-casing "acs" in translate_acs, we can now remove the acs entries
	from the translation tables.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Remove default entries in TUI translation tables
	The TUI translation tables contain default entries at the end:
	...
	static struct tui_translate tui_border_kind_translate_hline[] = {
	  { "space",    ' ' },
	  { "ascii",    '-' },
	  { "acs",      -1 },
	  { 0, 0 },
	  { "ascii",    '-' }
	};
	...

	A simpler way of implementing this would be to to declare the first (or last)
	entry the default, but in fact these default entries are not used.

	Make this explicit by removing the default entries, and asserting in translate
	that an entry will always be found.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-12  Alan Modra  <amodra@gmail.com>

	.noinit and .persistent for msp430
	Similar to the previous patch, but also tidy a few more sections.

		* scripttempl/elf32msp430.sc (.text, .rodata, .data, .bss, .noinit),
		(.persistent): Align the section rather than aligning inside.

2023-07-12  Alan Modra  <amodra@gmail.com>

	.noinit and .persistent alignment
	It's more elegant to make the section match up with its "_start"
	symbol.  We could align by setting the address of the section (by
	using ALIGN before the colon), but this way we also set sh_addralign
	to at least $ALIGNMENT.

		* scripttempl/elf.sc (.noinit, .persistent): Align the output
		section rather than using ". = ALIGN();" at the beginning.
		Set address to zero when not a final link.

2023-07-12  Alan Modra  <amodra@gmail.com>

	Re: Align linkerscript symbols according to ABI
	Align dot before symbols defined outside of output sections.  Before _end
	is already aligned.

		* scripttempl/elf.sc (def_symbol): Tidy excess space.
		(_edata): Align before emitting symbol when SYMBOL_ABI_ALIGNMENT.

2023-07-12  Alan Modra  <amodra@gmail.com>

	Re: Keeping track of rs6000-coff archive element pointers
	bfd/
		* coff-rs6000.c (add_range): Revise comment, noting possible fail.
		(_bfd_xcoff_openr_next_archived_file): Start with clean ranges.
	binutils/
		* bfdtest1.c: Enhance to catch errors on second scan.

2023-07-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-11  Tom Tromey  <tromey@adacore.com>

	Remove some TODOs from gdb.cp tests
	This patch removes many TODOs from the gdb.cp tests.
	Going through the patch:

	* bs15503.exp - these have been commented out forever and rely on
	  libstdc++ debuginfo.  It's better to just remove these.

	* classes.exp - the test is wrong, I think, according to the C++ ABI
	  that gdb understands; and the test can be fixed and comments removed
	  with a simple change to the code.

	* ctti.exp - there's no need to bail out any more, as the test works.

	* exception.exp - the code relying on the line numbers can't work,
	  because gdb never prints that message anyway.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: simplify table-referencing macros
	First of all it is entirely unclear why THREE_BYTE_TABLE_PREFIX() was
	introduced by bf890a93a7c4. Nothing uses the .prefix_requirement values
	from the two relevant entries.

	And then having VEX_Cn_TABLE() and friends take arguments is misleading.
	These aren't used (or pointlessly used in the case of VEX_C5_TABLE); the
	respective table index is decoded from the insn (or implied in the case
	of VEX_C5_TABLE).

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: convert 0FXOP to just XOP in enumerator names
	There's nothing 0f-ish in XOP encodings.

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: misc further register-only insns don't need to go through mod_table[]
	Several already use OP_R(), which rejects the memory forms of insns, and
	a few others can easily be converted to do so as well. Note that for it
	to be able to use BadOp() without forward declaration, OP_Skip_MODRM() is
	moved down.

	While there add the previously missing PREFIX_OPCODE to legacy opcode
	0FD7.

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: various operations on mask registers can avoid going through mod_table[]
	Now that we have OP_R(), use it here as well, while wiring memory-only
	operands to OP_M() at the same time. To keep the number of consumed
	opcode bytes similar to before, make BadOp() also account for VEX/XOP/
	EVEX prefix bytes. To keep that change simple, convert need_vex to an
	actual count of prefix bytes (keeping intact all prior boolean uses of
	the field).

	Note how this improves disassembly of such bad encodings, by at least
	leaving a hint towards what a "nearby" instruction is. (For KSHIFT*
	change the immediates test testcases use, such that disassembly remains
	sufficiently in sync.)

	While there also use Ux for VPMOV{B,W,D,Q}2M, where decoding through
	mod_table[] was missing in the earlier scheme.

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: slightly rework handling of some register-only insns
	Fold OP_MS() and OP_XS() into OP_R(), paralleling OP_M(). Use operand
	names (largely) matching those in the SDM. For 128-bit-only forms use
	Uxmm though, marking 256-bit forms as bad. This then allows no longer
	going through vex_len_table[] for two of the insns.

	Specifically _do not_ continue to mis-use v_mode.

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: SIMD shift-by-immediate don't need to go through mod_table[]
	OP_MS() and OP_XS() reject memory forms of insns quite fine. This then
	also eliminates mis-named enumerators (we use M_1 for register forms).

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: misc further memory-only insns don't need to go through mod_table[]
	Several already use OP_M(), which rejects the register forms of insns,
	and a few others can easily be converted to do so as well. (Note that
	FXSAVE_Fixup() wires through to OP_M(). Note further that OP_IndirE(),
	which wasn't placed very well anyway, is moved down to avoid the need to
	forward-declare BadOp().)

	Also adjust formatting of and drop PREFIX_OPCODE from a few adjacent
	entries.

2023-07-11  Jan Beulich  <jbeulich@suse.com>

	x86: {,V}MOVNT* don't need to go through mod_table[]
	Most of them use Mx already for the memory operand, which rejects the
	register form of the insn. Use that operand type also for the two EVEX
	forms which so far have used EXEvexXNoBcst (and thus failed to reject
	the register forms), compensating by flagging broadcast as bad for all
	Mx. This way several other insns which don't permit embedded broadcast
	either are also covered at the same time.

	x86: fold legacy/VEX {,V}MOV{H,L}* entries
	By changing decode order to do ModR/M.mod last (rather than VEX.L), the
	VEX entries (which are already reused by EVEX decoding) can be folded
	with their legacy counterparts as well. Note how this change of decode
	order also allows removing two auxiliary #define-s, which were
	introduced during earlier folding (because of that unhelpful order of
	steps).

	x86: fold certain legacy/VEX table entries
	Introduce macro V to expand to 'v' in the VEX/EVEX case, and replace a
	couple of abort()s where legacy code can now legitimately make it. While
	there for {,V}LDDQU drop hoing through mod_table[] - OP_M() rejects
	register operands quite fine.

	ld/PDB: fix off-by-1 in add_globals_ref()
	Copying one too many bytes can corrupt memory, detected/reported by
	glibc on a 32-bit distro.

2023-07-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-10  Tom Tromey  <tom@tromey.com>

	Remove target_close
	I noticed that target_close is only called in two places:
	solib-svr4.c, and target_ops_ref_policy::decref.

	This patch fixes the former by changing target_bfd_reopen to return a
	target_ops_up and then fixing the sole caller.  Then it removes
	target_close by inlining its body into the decref method.

	The advantage of this approach is that targets are now automatically
	managed.

	Regression tested on x86-64 Fedora 38.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Update TUI window title when changed
	I wrote a TUI window in Python, and I noticed that setting its title
	did not result in a refresh, so the new title did not appear.  This
	patch corrects this problem.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Add Ada scope test for DAP
	This adds a DAP test for fetching scopes and variables with an Ada
	program.  This test is the reason that the FrameVars code does not
	check is_constant on the symbols it returns.

	Note that this test also shows that string-printing is incorrect in
	Ada.  This is a known bug but I'm still considering how to fix it.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Handle typedefs in no-op pretty printers
	The no-ops pretty-printers that were introduced for DAP have a classic
	gdb bug: they neglect to call check_typedef.  This will cause some
	strange behavior; for example not showing the children of a variable
	whose type is a typedef of a structure type.  This patch fixes the
	oversight.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Reimplement DAP stack traces using frame filters
	This reimplements DAP stack traces using frame filters.  This slightly
	simplifies the code, because frame filters and DAP were already doing
	some similar work.  This also renames RegisterReference and
	ScopeReference to make it clear that these are private (and so changes
	don't have to worry about other files).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30468

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Simplify FrameVars
	FrameVars implements its own variant of Symbol.is_variable.  This
	patch replaces this code.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Fix oversights in frame decorator code
	The frame decorator "FrameVars" code misses a couple of cases,
	discovered when working on related DAP changes.

	First, fetch_frame_locals does not stop when reaching a function
	boundary.  This means it would return locals from any enclosing
	functions.

	Second, fetch_frame_args assumes that all arguments are at the
	outermost scope, but this doesn't seem to be required by gdb.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Add new interface to frame filter iteration
	This patch adds a new function, frame_iterator, that wraps the
	existing code to find and execute the frame filters.  However, unlike
	execute_frame_filters, it will always return an iterator -- whereas
	execute_frame_filters will return None if no frame filters apply.

	Nothing uses this new function yet, but it will used by a subsequent
	DAP patch.

2023-07-10  Tom Tromey  <tromey@adacore.com>

	Fix execute_frame_filters doc string
	When reading the doc string for execute_frame_filters, I wasn't sure
	if the ranges were inclusive or exclusive.  This patch updates the doc
	string to reflect my findings, and also fixes an existing typo.

2023-07-10  Tom Tromey  <tom@tromey.com>

	Change 'handle_id' to be a local variable
	The global variable 'handle_id' in tracectf.c is only used in a single
	function, so change it to be a local variable.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Move definition of ctf_target type
	This moves the definition of the ctf_target type into the
	HAVE_LIBBABELTRACE block.  This type is only used in this block, so it
	makes sense to only define it there.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Constify tfile_interp_line
	This adds 'const' to tfile_interp_line.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Use function_view in traceframe_walk_blocks
	This change traceframe_walk_blocks to take a function_view.  This
	simplifies the code somewhat and lets us entirely remove one helper
	function.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Use unique_ptr for trace_dirname
	This changes trace_dirname to use unique_ptr, removing some manual
	memory management.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Use unique_ptr for trace_filename
	This changes trace_filename to use unique_ptr, removing some manual
	memory management.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Replace use of xfree with byte_vector
	This replaces a use of xfree with a byte_vector.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Remove a use of xfree
	This removes a use of xfree from tracefile-tfile.c, replacing it with
	a unique_xmalloc_ptr.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-07-10  Tom Tromey  <tom@tromey.com>

	Avoid crash with absolute symbol
	A user supplied an executable and a remote logfile that could be used
	to crash gdb.  The problem is that the BFD section for a particular
	symbol was null, because the section was not marked "allocated".
	Digging deeper, the problem was that elfread.c dropped the section for
	absolute symbols.  This patch fixes the crash.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431

2023-07-10  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: handle all eval_result_type values in tracepoint.cc
	It was pointed out[1] that after this commit:

	  commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab
	  Date:   Thu Oct 20 11:14:33 2022 +0100

	      gdbserver: allow agent expressions to fail with invalid memory access

	Now that agent expressions might fail with the error
	expr_eval_invalid_memory_access, we might overflow the
	eval_result_names array in tracepoint.cc.  This is because the
	eval_result_names array does not include a string for either
	expr_eval_invalid_goto or expr_eval_invalid_memory_access.

	I don't know if having expr_eval_invalid_goto missing is also a
	problem, but it feels like eval_result_names should just include a
	string for every possible error.

	I could just add two more strings into the array, but I figure that a
	more robust solution will be to move all of the error types, and their
	associated strings, into a new ax-result-types.def file, and to then
	include this file in both ax.h and tracepoint.cc in order to build
	the enum eval_result_type and the eval_result_names string array.
	Doing this means it is impossible to have a missing error string in
	the future.

	[1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: avoid stack addresses in test names
	When comparing the test results for two different runs of GDB I
	noticed a difference in the results for gdb.base/frame-view.exp.

	The difference was caused by one of the tests including a stack
	address in the test name:

	  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b

	and

	  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b

	If for whatever reason the stack address changes between test runs
	then it becomes harder to compare results.

	Fix this by giving the test a descriptive name that doesn't include a
	stack address:

	  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1

	and

	  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1

	There's no change to what is actually tested after this commit.

2023-07-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: return after reporting a test unsupported
	In this commit:

	  commit 8bcead69665af3a9f9867cd34c3a1daf22120027
	  Date:   Tue May 23 11:25:01 2023 +0100

	      gdb/testsuite: add test for core file with a 0 pid

	a new test gdb.arch/core-file-pid0.exp was added.  This test includes
	a pre-generated core file for x86-64 and for other architectures the
	test reports 'unsupported'.

	However, after reporting 'unsupported' the test failed to perform an
	early return, so the test would then carry on and try to actually
	perform the test, which resulted in some TCL errors.

	Fix this by returning after reporting the test unsupported.

2023-07-10  Andrew Burgess  <aburgess@redhat.com>

	gdb: include location number in breakpoint error message
	This commit improves the output of this previous commit:

	  commit 2dc3457a454a35d0617dc1f9cc1db77468471f95
	  Date:   Fri Oct 14 13:22:55 2022 +0100

	      gdb: include breakpoint number in testing condition error message

	The earlier commit extended the error message:

	  Error in testing breakpoint condition:

	to include the breakpoint number, e.g.:

	  Error in testing breakpoint condition 3:

	This commit extends takes this further, and includes the location
	number if the breakpoint has multiple locations, so we might now see:

	  Error in testing breakpoint condition 3.2:

	Just as with how GDB reports a normal breakpoint stop, if a breakpoint
	only has a single location then the location number is not included,
	this keeps things nice and consistent.

	I've extended one of the tests to cover the new functionality.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-07-10  Richard Bunt  <richard.bunt@linaro.org>

	gdb/testsuite: Testing with the nvfortran compiler
	Currently, the Fortran test suite does not run with NVIDIA's Fortran
	compiler (nvfortran).

	The goal here is to get the tests running and preventing further
	regressions during future work. This change does not do anything to fix
	existing failures.

	Teach the compiler detection about nvfortran. There is no underlying
	information about whether this compiler is related to flang classic or
	flang, so we cannot reuse the main and type definitions. Therefore, we
	explicitly record the main method and type information observed when
	using nvfortran.

	The main name was extracted by trying to set breakpoints on both MAIN_
	and MAIN__.

	The following mapping of test to type names was used to extract how
	nvfortran reports types.

	info-types.exp: fortran_int4, fortran_int8, fortran_real4,
	fortran_logical4

	common-block.exp: fortran_real8

	complex.exp: fortran_complex4 fortran_complex8

	logical.exp: fortran_character1. Ran ptype on "c".

	Types defined as fortran_complex16 do not compile with nvfortran, so it
	was left unset.

	gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
	No regressions detected.

	The gdb.fortran test results with nvfortran 23.3 are as follows.

	Before:

	    # of expected passes        523
	    # of unexpected failures    107
	    # of known failures         2
	    # of unresolved testcases   1
	    # of untested testcases     7
	    # of duplicate test names   2

	After:

	    # of expected passes        5696
	    # of unexpected failures    271
	    # of known failures         12
	    # of untested testcases     9
	    # of unsupported tests      5

	As can be seen from the above, there are now considerably more passing
	assertions.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-09  Fangrui Song  <maskray@google.com>

	PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE
	For example, objcopy --set-section-flags .data=alloc,large will add
	SHF_X86_64_LARGE to the .data section.  Omitting "large" will drop the
	SHF_X86_64_LARGE flag.

	The bfd_section flag is named generically, SEC_ELF_LARGE, in case other
	processors want to follow SHF_X86_64_LARGE.  SEC_ELF_LARGE has the same
	value as SEC_TIC54X_BLOCK used by coff.

	bfd/
	    * section.c: Define SEC_ELF_LARGE.
	    * bfd-in2.h: Regenerate.
	    * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections,
	    elf_x86_64_copy_private_section_data): New.

	binutils/
	    * NEWS: Mention the new feature for objcopy.
	    * doc/binutils.texi: Mention "large".
	    * objcopy.c (parse_flags): Parse "large".
	    (check_new_section_flags): Error if "large" is used with a
	    non-x86-64 ELF target.
	    * testsuite/binutils-all/x86-64/large-sections.d: New.
	    * testsuite/binutils-all/x86-64/large-sections.s: New.
	    * testsuite/binutils-all/x86-64/large-sections-i386.d: New.
	    * testsuite/binutils-all/x86-64/large-sections-2.d: New.
	    * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.

2023-07-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-08  Aaron Merey  <amerey@redhat.com>

	gdb/cp-namespace.c: Fix assert failure caused by malformed user input
	When debugging C++ programs, it is possible to trigger a spurious assert
	failure when attempting to set a breakpoint on a malformed symbol name.
	Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
	cp_lookup_bare_symbol:

	    $ gdb gdb
	    [...]
	    (gdb) br test>::assert
	    Function "test>::assert" not defined.
	    Make breakpoint pending on future shared library load? (y or [n]) y
	    Breakpoint 1 (test>::assert) pending.
	    (gdb) start
	    [...]
	    cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
	    A problem internal to GDB has been detected,
	    further debugging may prove unreliable.
	    ----- Backtrace -----
	    0x5217e2 gdb_internal_backtrace_1
	            /home/amerey/binutils-gdb/gdb/bt-utils.c:122
	    0x521885 _Z22gdb_internal_backtracev
	            /home/amerey/binutils-gdb/gdb/bt-utils.c:168
	    0xaf8303 internal_vproblem
	            /home/amerey/binutils-gdb/gdb/utils.c:396
	    0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
	            /home/amerey/binutils-gdb/gdb/utils.c:476
	    0xccdb3f _Z18internal_error_locPKciS0_z
	            /home/amerey/binutils-gdb/gdbsupport/errors.cc:58
	    0x5dded9 cp_lookup_bare_symbol
	            /home/amerey/binutils-gdb/gdb/cp-namespace.c:181
	    0x5de39d cp_lookup_symbol_in_namespace
	            /home/amerey/binutils-gdb/gdb/cp-namespace.c:328
	    [...]

	Currently this assert is skipped if the symbol name contains '<' or '('.
	Fix this spurious failure by also skipping the assert when the symbol
	name contains '>' or ')'.

	Regression tested on F38 x86_64.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-07-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-07  Tom Tromey  <tromey@adacore.com>

	Fix result of DAP setExpression
	A co-worker, Andry, noticed that the DAP setExpression implementation
	returned the wrong fields -- it used "result" rather than "value", and
	included "memoryReference", which isn't in the spec (an odd oversight,
	IMO).

	This patch fixes the problems.

2023-07-07  Tom Tromey  <tromey@adacore.com>

	Remove unchecked casts to mi_interp
	Simon noticed a crash that could be caused via new Python
	gdb.execute_mi function.  Looking into this, I found a few unchecked
	casts to mi_interp, like:

	-  struct mi_interp *mi = (struct mi_interp *) command_interp ();

	This patch replaces all such casts with safer variants.

	For -gdb-exit and mi_load_progress, I chose to have the functions
	simply not generate any output.  It didn't seem useful to do so.

	Some casts I eliminated by adding a parameter to a function.  Then, in
	mi_execute_command, I changed the code to use
	gdb::checked_static_cast.  This is appropriate because this particular
	overload can only be called by the MI interpreter.

	There does not seem to be a very good way to test -gdb-exit.

	Regression tested on x86-64 Fedora 36.

2023-07-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: check max-value-size when reading strings for printf
	I noticed that the printf code for strings, printf_c_string and
	printf_wide_c_string, don't take max-value-size into account, but do
	load a complete string from the inferior into a GDB buffer.

	As such it would be possible for an badly behaved inferior to cause
	GDB to try and allocate an excessively large buffer, potentially
	crashing GDB, or at least causing GDB to swap lots, which isn't
	great.

	We already have a setting to protect against this sort of thing, the
	'max-value-size'.  So this commit updates the two function mentioned
	above to check the max-value-size and give an error if the
	max-value-size is exceeded.

	If the max-value-size is exceeded, I chose to continue reading
	inferior memory to figure out how long the string actually is, we just
	don't store the results.  The benefit of this is that when we give the
	user an error we can tell the user how big the string actually is,
	which would allow them to correctly adjust max-value-size, if that's
	what they choose to do.

	The default for max-value-size is 64k so there should be no user
	visible changes after this commit, unless the user was previously
	printing very large strings.  If that is the case then the user will
	now need to increase max-value-size.

2023-07-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove last alloca call from printcmd.c
	This commit removes the last alloca call from printcmd.c.  This is
	similar to the patches I originally posted here:

	  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

	However, this change was not included in that original series.

	The original series received push back because it was thought that
	replacing alloca with a C++ container type would introduce unnecessary
	malloc/free overhead.

	However, in this case we are building a string, and (at least for
	GCC), the std::string type has a small string optimisation, where
	small strings are stored on the stack.

	And in this case we are building what will usually be a very small
	string, we're just constructing a printf format specifier for a hex
	value, so it'll be something like '%#x' -- though it could also have a
	width in there too -- but still, it should normally fit within GCCs
	small string buffer.

	So, in this commit, I propose replacing the use of alloca with a
	std::string.  This shouldn't result (normally) in any additional
	malloc or free calls, so should be similar in performance to the
	original approach.

	There should be no user visible differences after this commit.

2023-07-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove two uses of alloca from printcmd.c
	Remove a couple of uses of alloca from printcmd.c, and replace them
	with gdb::byte_vector.

	An earlier variant of this patch was proposed in this thread:

	  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

	however, there was push back on that thread due to it adding extra
	dynamic allocation, i.e. moving the memory buffers off the stack on to
	the heap.

	However, of all the patches originally proposed, I think in these two
	cases moving off the stack is the correct thing to do.  Unlike all the
	other patches in the original series, where the data being read
	was (mostly) small in size, a register, or a couple of registers, in
	this case we are reading an arbitrary string from the inferior.  This
	could be any size, and so should not be placed on the stack.

	So in this commit I replace the use of alloca with std::byte_vector
	and simplify the logic a little (I think) to take advantage of the
	ability of std::byte_vector to dynamically grow in size.

	Of course, really, we should probably be checking the max-value-size
	setting as we load the string to stop GDB crashing if a corrupted
	inferior causes GDB to try read a stupidly large amount of
	memory... but I'm leaving that for a follow on patch.

	There should be no user visible changes after this commit.

2023-07-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix printf of wchar_t early in a gdb session
	Given this test program:

	  #include <wchar.h>

	  const wchar_t wide_str[] = L"wide string";

	  int
	  main (void)
	  {
	    return 0;
	  }

	I observed this GDB behaviour:

	  $ gdb -q /tmp/printf-wchar_t
	  Reading symbols from /tmp/printf-wchar_t...
	  (gdb) start
	  Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
	  Starting program: /tmp/printf-wchar_t

	  Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
	  25	  return 0;
	  (gdb) printf "%ls\n", wide_str

	  (gdb)

	Notice that the printf results in a blank line rather than the
	expected 'wide string' output.

	I tracked the problem down to printf_wide_c_string (in printcmd.c), in
	this function we do this:

	  struct type *wctype = lookup_typename (current_language,
						 "wchar_t", NULL, 0);
	  int wcwidth = wctype->length ();

	the problem here is that 'wchar_t' is a typedef.  If we look at the
	comment on type::length() we see this:

	  /* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
	     But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
	     so you only have to call check_typedef once.  Since value::allocate
	     calls check_typedef, X->type ()->length () is safe.  */

	What this means is that after calling lookup_typename we should call
	check_typedef in order to ensure that the length of the typedef has
	been setup correctly.  We are not doing this in printf_wide_c_string,
	and so wcwidth is incorrectly calculated as 0.  This is what leads GDB
	to print an empty string.

	We can see in c_string_operation::evaluate (in c-lang.c) an example of
	calling check_typedef specifically to fix this exact issue.

	Initially I did fix this problem by adding a check_typedef call into
	printf_wide_c_string, but then I figured why not move the
	check_typedef call up into lookup_typename itself, that feels like it
	should be harmless when looking up a non-typedef type, but will avoid
	bugs like this when looking up a typedef.  So that's what I did.

	I can then remove the extra check_typedef call from c-lang.c, I don't
	see any other places where we had extra check_typedef calls.  This
	doesn't mean we definitely had bugs -- so long as we never checked the
	length, or, if we knew that check_typedef had already been called,
	then we would be fine.

	I don't see any test regressions after this change, and my new test
	case is now passing.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-07-07  Jan Beulich  <jbeulich@suse.com>

	ld: fix build with old glibc / gcc
	"rename" conflicts with a function of that name, which gcc from that
	same timeframe then complains about. Use a name matching that of
	struct input_remap's respective field.

2023-07-07  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update/Add ARCv3 support.
	The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA
	that implements a full range of 32-bit and 64-bit instructions.  These
	processors feature a high-speed 10-stage, dual-issue pipeline that
	offers increased utilization of functional units with a limited
	increase in power and area.  The HS5x processors feature a 32-bit
	pipeline that can execute all ARCv3 32-bit instructions, while the
	HS6x processors feature a full 64-bit pipeline and register file that
	can execute both 32-bit and 64-bit instructions.  In addition, the ARC
	HS6x supports 64-bit virtual and 52-bit physical address spaces to
	enable direct addressing of current and future large memories, as well
	as 128-bit loads and stores for efficient data movement.

	This readelf patch updates/adds Synopsys ARCv3 machine name fileds and
	supported relocations.

2023-07-07  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix license on recently added file
	The license header on a file I recently contributed was incorrect.
	The file was added in commit:

	  commit 087969169836f802a09b1cd0502d2f22d7a8f7dc
	  Date:   Tue May 23 11:25:21 2023 +0100

	      gdb: handle core files with .reg/0 section names

	The problems were:

	  - GPLv2 instead of GPLv3,
	  - Use the FSF postal address rather than their URL.

	Nobody else has touched the file since I merged it, so I don't believe
	there are any problems with me changing the license, this commit does
	just that.

2023-07-07  Nick Clifton  <nickc@redhat.com>

	Udated Freach and Romainian translations for various sub-directories

	Minor updates to release readme

2023-07-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-06  Pedro Alves  <pedro@palves.net>

	Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525)
	Since commit 05c06f318fd9 ("Linux: Access memory even if threads are
	running"), GDB prefers pread64/pwrite64 to access inferior memory
	instead of ptrace.  That change broke reading shared libraries on
	SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared
	libraries on SPARC64").

	On SPARC64 Linux, surprisingly (to me), userspace shared libraries are
	mapped at high 64-bit addresses:

	   (gdb) info sharedlibrary
	   Cannot access memory at address 0xfff80001002011e0
	   Cannot access memory at address 0xfff80001002011d8
	   Cannot access memory at address 0xfff80001002011d8
	   From                To                  Syms Read   Shared Object Library
	   0xfff80001000010a0  0xfff8000100021f80  Yes (*)     /lib64/ld-linux.so.2
	   (*): Shared library is missing debugging information.

	Those addresses are 64-bit addresses with the high bits set.  When
	interpreted as signed, they're negative.

	The Linux kernel rejects pread64/pwrite64 if the offset argument of
	type off_t (a signed type) is negative, which happens if the memory
	address we're accessing has its high bit set.  See
	linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux.

	Thankfully, lseek does not fail in that situation.  So the fix is to
	use the 'lseek + read|write' path if the offset would be negative.

	Fix this in both native GDB and GDBserver.

	Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525
	Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5

2023-07-06  Branislav Brzak  <branislav.brzak@syrmia.com>

	riscv: Ensure LE instruction fetching
	Currently riscv gdb code looks at arch byte order
	when fetching instructions. This works when the
	target is LE, but on BE arch it will byte swap the
	instruction, while the riscv spec defines all
	instructions are LE encoded regardless of
	system memory endianess.

2023-07-06  Pedro Alves  <pedro@palves.net>

	Fix Solaris regression (PR tdep/30252)
	PR tdep/30252 reports that using GDB on Solaris fails an assertion in
	target_resume:

	 target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed.
	 A problem internal to GDB has been detected,
	 further debugging may prove unreliable.
	 Quit this debugging session? (y or n)

	The backtrace, after running it through c++filt, looks like:

	 ----- Backtrace -----
	 0xa18914 gdb_internal_backtrace_1
		 /root/binutils-gdb/gdb/bt-utils.c:122
	 0xa18914 gdb_internal_backtrace()
		 /root/binutils-gdb/gdb/bt-utils.c:168
	 0xdec834 internal_vproblem
		 /root/binutils-gdb/gdb/utils.c:401
	 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*)
		 /root/binutils-gdb/gdb/utils.c:481
	 0xf3638c internal_error_loc(char const*, int, char const*, ...)
		 /root/binutils-gdb/gdbsupport/errors.cc:58
	 0xd70580 target_resume(ptid_t, int, gdb_signal)
		 /root/binutils-gdb/gdb/target.c:2648
	 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
		 /root/binutils-gdb/gdb/procfs.c:2187
	 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
		 /root/binutils-gdb/gdb/sol-thread.c:442
	 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
		 /root/binutils-gdb/gdb/target.c:2586
	 ...

	The problem is that the procfs backend, while inside target_wait,
	called target_resume without switching to the leader thread of that
	resumption.

	The target_resume interface is:

	 /* Resume execution (or prepare for execution) of the current thread
	    (INFERIOR_PTID), while optionally letting other threads of the
	    current process or all processes run free.
	    ...

	Thus calling target_resume with inferior_ptid == null_ptid is bogus.

	target_wait (which leads to procfs_target::wait on Solaris) is called
	with inferior_ptid == null_ptid on entry exactly to help catch such
	bogus uses.

	From the backtrace, it seems that the relevant line in question is
	procfs.c:2187:

	2186  /* How to keep going without returning to wfi: */
	2187  target_continue_no_signal (ptid);
	2188  goto wait_again;

	target_continue_no_signal is a small wrapper around target_resume,
	which would make sense.

	The fix is to not call target_resume or go via the target stack at
	all.  Instead, factor out a new proc_resume function out of
	procfs_target::resume, and call that.  The new function does not rely
	on inferior_ptid.

	I've not been able to test it myself, but Petr confirmed it fixes the
	assertion failure with his test case, and Marcel Telka also confirmed
	it solves the problem.

	Tested-By: Petr Šumbera <petr.sumbera@oracle.com>
	Tested-By: Marcel Telka <marcel@telka.sk>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252
	Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3

2023-07-06  YunQiang Su  <yunqiang.su@cipunited.com>

	ld: fix plugin tests for MIPS PIC
	On MIPS, for PIC objects, symbols may reference 2 times:
	once from the caller, and once from GOT.
	Thus ld may complains 2 times about "undefined reference".

	So we add a new "#?" line to every effected testsuite.

2023-07-06  Alan Modra  <amodra@gmail.com>

	Use run_host_cmd to run $CC and other no-section-header test fixes
	We should be using run_host_cmd everywhere we invoke a compiler in the
	ld testsuite, if we want to use ld/ld-new just built.  run_host_cmd
	properly inserts $gcc_B_opt in cases where a user wants to test
	binutils with a newly built compiler, ie. when $CC specifies -B itself.

	Also, it is not good practice to exclude tests when non-native except
	of course those tests that run a target binary.  Compiling and linking
	often shows up problems.

		* testsuite/ld-elf/no-section-header.exp (binutils_run_test):
		Use run_host_cmd to invoke $CC_FOR_TARGET.  Run all tests
		non-native too, except for attempting to run the binaries.
		Run tests for ELF in general, not just linux.
		* testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry
		symbol decoration, and support either sorting of symbols.
		* testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms.
		* testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept
		mips-sgi-irix symbol output.
		* testsuite/ld-elf/start-shared-noheader.nd: Likewise.

2023-07-06  Alan Modra  <amodra@gmail.com>

	Re: Stop the linker's --dependency-file option from including temporary lto files.
		PR 30568
		* ldfile.c (ldfile_try_open_bfd): Fix build failure when
		!BFD_SUPPORTS_PLUGINS.

2023-07-06  YunQiang Su  <yunqiang.su@cipunited.com>

	ld: Use run_host_cmd_yesno in indirect.exp instead of catch exec
	Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build,
	and in fact run_host_cmd_yesno is a better choice for it.

	ld/ChangeLog:

		* testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno
		instead of handwrite catch exec $CC_FOR_TARGET.

2023-07-06  YunQiang Su  <yunqiang.su@cipunited.com>

	ld: Use [list ] syntax to define run_tests in indirect.exp
	Currently, the var run_tests is defined by syntax {{}},
	while in this case, variables cannot be used.
	Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names
	instead of values:
	  gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o

	Let's use [list [list ]] syntax instead.

	ld/ChangeLog:

		* testsuite/ld-elf/indirect.exp(run_tests): use [list [list]]
		syntax instead of {{}}.

2023-07-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-05  Andreas Krebbel  <krebbel@linux.ibm.com>

	Align linkerscript symbols according to ABI
	Apply ABI specific alignment to symbols generated in the default
	linker script.

2023-07-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-04  Jan Beulich  <jbeulich@suse.com>

	x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ
	The alternative is 1 byte shorter when the source is %xmm0-7, as a
	2-byte VEX prefix can then be used.

	x86: optimize pre-AVX512 {,V}PCMPGT* with identical sources
	These are better expressed by the zeroing idiom {,V}PXOR. In some cases
	this also results in a shorter encoding.

	x86: optimize pre-AVX512 {,V}PCMPEQQ with identical sources
	The {,V}PCMPEQD alternative is 1 byte shorter in many cases.

2023-07-04  Jan Beulich  <jbeulich@suse.com>

	x86: flag bad EVEX masking for miscellaneous insns
	Masking is not permitted for certain further insns, not falling in any
	of the earlier categories. Introduce the Y macro (not expanding to any
	output) to flag such cases.

	Note that in a few cases entries already covered otherwise are converted
	as well, to continue to allow sharing of the string literals.

2023-07-04  Jan Beulich  <jbeulich@suse.com>

	x86: flag EVEX masking when destination is GPR(-like)
	Masking is not permitted in this case. See the code comment for how this
	is being dealt with.

	To avoid excess special casing of modes, have OP_M() call OP_E_memory()
	directly.

2023-07-04  Jan Beulich  <jbeulich@suse.com>

	x86: flag EVEX.z set when destination is memory
	Zeroing-masking is not permitted in this case. See the code comment for
	how this is being dealt with.

	x86: flag EVEX.z set when destination is a mask register
	While only zeroing-masking is possible in this case, this still requires
	EVEX.z to be clear. Introduce a "global" flag right here, to be re-used
	by checks which need to live in specific operand handlers.

	x86: re-work EVEX-z-without-masking check
	Rather than corrupting disassmbly altogether, flag EVEX.z set as bad
	when masking isn't in effect in the first place at the time the
	destination operand is actually processed.

2023-07-04  Matheus Branco Borella  <dark.ryu.550@gmail.com>

	gdb: add __repr__() implementation to a few Python types
	Only a few types in the Python API currently have __repr__()
	implementations.  This patch adds a few more of them. specifically: it
	adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
	gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.

	This makes it easier to play around the GDB Python API in the Python
	interpreter session invoked with the 'pi' command in GDB, giving more
	easily accessible tipe information to users.

	An example of how this would look like:

	  (gdb) pi
	  >> gdb.lookup_type("char")
	  <gdb.Type code=TYPE_CODE_INT name=char>
	  >> gdb.lookup_global_symbol("main")
	  <gdb.Symbol print_name=main>

	The gdb.Block.__repr__() method shows the first 5 symbols from the
	block, and then a message to show how many more were elided (if any).

2023-07-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: have mdict_size always return a symbol count
	In the next commit we would like to have mdict_size return the number
	of symbols in the dictionary, currently mdict_size is just a
	heuristic, sometimes it returns the number of symbols, and sometimes
	the number of buckets in a hashing dictionary (see size_hashed in
	dictionary.c).

	Currently this vague notion of size is good enough, the only place
	mdict_size is used is in a maintenance command in order to print a
	message containing the size of the dictionary ... so we don't really
	care that the value isn't correct.

	However, in the next commit we do want the size returned to be the
	number of symbols in the dictionary, so this commit makes mdict_size
	return the symbol count in all cases.

	The new use is still not on a hot path -- it's going to be a Python
	__repr__ method, so all I do in this commit is have size_hashed walk
	the dictionary and count the entries, obviously this could be slow if
	we have a large number of symbols, but for now I'm not worrying about
	that case.  We could always store the symbol count if we wanted, but
	that would increase the size of every dictionary for a use case that
	isn't going to be hit that often.

	I've updated the text in 'maint print symbols' so that we don't talk
	about the size being 'syms/buckets', but just 'symbols' now.

2023-07-04  Nick Clifton  <nickc@redhat.com>

	Updated Ukranian, Romanian and German translations for various sub-directories

2023-07-04  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Update default target CPU to match GCC defaults

	arc: Update neg<.f> 0,b encoding
	Wrong encoding for null destination NEG instruction. Fix it.

2023-07-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-03  Andreas Krebbel  <krebbel@linux.ibm.com>

	IBM Z: Fix pcrel relocs for symA-symB expressions
	The code in md_apply_fix which tries to deduce from the operand type
	which reloc to apply currently does the wrong thing for absolute
	relocs which have been re-written by fixup_segment as pc-relative to
	implement a subtraction of a local and an external symbol.

	In all these cases we wrongly emit an absolute reloc because we ignore
	the fx_pcrel flag in md_apply_fix. However, only for the last one we
	actually support a pc relative relocation of the proper size and can
	implement it accordingly. For the other 3 we have to issue an error.

	foo:
	  cli	0(%r2),undef-foo
	  la	%r2,undef-foo(%r2)
	  lay	%r2,undef-foo(%r2)
	  lhi	%r2,undef-foo

2023-07-03  Tom Tromey  <tromey@adacore.com>

	Fix two Python calls that don't check for errors
	PyModule_AddObject steals a reference on success, but not on error,
	which is why we have gdb_pymodule_addobject.  I found one spot still
	calling the former, which could in theory leak memory on failure.
	This patch fixes this.

	In the same function I found an unchecked call to
	PyDict_SetItemString.  This patch fixes this as well.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-07-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: handle core files with .reg/0 section names
	The previous commit added the test gdb.arch/core-file-pid0.exp which
	tests GDB's ability to load a core file containing threads with an
	lwpid of 0, which is something we GDB can encounter when loading a
	vmcore file -- a core file generated by the Linux kernel.  The threads
	with an lwpid of 0 represents idle cores.

	While the previous commit added the test, which confirms GDB doesn't
	crash when confronted with such a core file, there are still some
	problems with GDB's handling of these core files.  These problems all
	originate from the fact that the core file (once opened by bfd)
	contains multiple sections called .reg/0, these sections all
	represents different threads (cpu cores in the original vmcore dump),
	but GDB gets confused and thinks all of these .reg/0 sections are all
	referencing the same thread.

	Here is a GDB session on an x86-64 machine which loads the core file
	from the gdb.arch/core-file-pid0.exp, this core file contains two
	threads, both of which have a pid of 0:

	  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
	  (gdb) core-file /tmp/x86_64-pid0-core.core
	  [New process 1]
	  [New process 1]
	  Failed to read a valid object file image from memory.
	  Core was generated by `./segv-mt'.
	  Program terminated with signal SIGSEGV, Segmentation fault.
	  The current thread has terminated
	  (gdb) info threads
	    Id   Target Id         Frame
	    2    process 1         0x00000000004017c2 in ?? ()

	  The current thread <Thread ID 1> has terminated.  See `help thread'.
	  (gdb) maintenance info sections
	  Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
	   [0]      0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
	   [1]      0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
	   [2]      0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
	   [3]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
	   [4]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
	   [5]      0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
	   [6]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
	   [7]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
	   [8]      0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
	   [9]      0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
	   [10]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
	   [11]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
	   [12]     0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
	   [13]     0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
	   [14]     0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
	   [15]     0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
	   [16]     0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
	   [17]     0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
	   [18]     0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
	   [19]     0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
	   [20]     0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
	   [21]     0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
	   [22]     0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
	   [23]     0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
	   [24]     0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
	   [25]     0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
	   [26]     0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
	  (gdb)

	Notice when the core file is first loaded we see two lines like:

	  [New process 1]

	And GDB reports:

	  The current thread has terminated

	Which isn't what we'd expect from a core file -- the core file should
	only contain threads that are live at the point of the crash, one of
	which should be the current thread.  The above message is reported
	because GDB has deleted what we think is the current thread!

	And in the 'info threads' output we are only seeing a single thread,
	again, this is because GDB has deleted one of the threads.

	Finally, the 'maintenance info sections' output shows the cause of all
	our problems, two sections named .reg/0.  When GDB sees the first of
	these it creates a new thread.  But, when we see the second .reg/0 GDB
	tries to create another new thread, but this thread has the same
	ptid_t as the first thread, so GDB deletes the first thread and
	creates the second thread in its place.

	Because both these threads are created with an lwpid of 0 GDB reports
	these are 'New process NN' rather than 'New LWP NN' which is what we
	would normally expect.

	The previous commit includes a little more of the history of GDB
	support in this area, but these problems were discussed on the mailing
	list a while ago in this thread:

	  https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/

	In this commit I propose a solution to these problems.

	What I propose is that GDB should spot when we have .reg/0 sections
	and, when these are found, should rename these sections using some
	unique non-zero lwpid.

	Note in the above output we also have sections like .reg2/0 and
	.reg-xstate/0, these are additional register sets, this commit also
	renumbers these sections inline with their .reg section.

	The user is warned that some section renumbering has been performed.

	GDB takes care to ensure that the new numbers assigned are unique and
	don't clash with any of the pid's that might already be in use --
	remember, in a real vmcore file, 0 is used to indicate an idle core,
	non-idle cores will have the pid of whichever process was running on
	that core, so we don't want GDB to assign an lwpid that clashes with
	an actual pid that is in use in the core file.

	After this commit here's the updated GDB session output:

	  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
	  (gdb) core-file /tmp/x86_64-pid0-core.core
	  warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
	  [New LWP 1]
	  [New LWP 2]
	  Failed to read a valid object file image from memory.
	  Core was generated by `./segv-mt'.
	  Program terminated with signal SIGSEGV, Segmentation fault.
	  #0  0x00000000004017c2 in ?? ()
	  [Current thread is 1 (LWP 1)]
	  (gdb) info threads
	    Id   Target Id         Frame
	  * 1    LWP 1             0x00000000004017c2 in ?? ()
	    2    LWP 2             0x000000000040dda5 in ?? ()
	  (gdb) maintenance info sections
	  Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
	   [0]      0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
	   [1]      0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
	   [2]      0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
	   [3]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
	   [4]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
	   [5]      0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
	   [6]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
	   [7]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
	   [8]      0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
	   [9]      0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
	   [10]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
	   [11]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
	   [12]     0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
	   [13]     0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
	   [14]     0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
	   [15]     0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
	   [16]     0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
	   [17]     0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
	   [18]     0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
	   [19]     0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
	   [20]     0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
	   [21]     0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
	   [22]     0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
	   [23]     0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
	   [24]     0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
	   [25]     0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
	   [26]     0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
	  (gdb)

	Notice the new warning which is issued when the core file is being
	loaded.  The threads are announced as '[New LWP NN]', and we see two
	threads in the 'info threads' output.  The 'maintenance info sections'
	output shows the result of the section renaming.

	The gdb.arch/core-file-pid0.exp test has been update to check for the
	improved GDB output.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2023-07-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: add test for core file with a 0 pid
	This patch contains a test for this commit:

	  commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
	  Date:   Fri Aug 6 19:45:58 2010 +0000

	              * thread.c (add_thread_silent): Use null_ptid instead of
	              minus_one_ptid while getting rid of stale inferior_ptid.

	This is another test that has been carried in the Fedora GDB tree for
	some time, and I thought that it would be worth merging to master.  I
	don't believe there is any test like this currently in the testsuite.

	The original issue was reported in this thread:

	  https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/

	The problem was that when GDB was used to open a vmcore (core file)
	image generated by the Linux kernel GDB would (sometimes) crash with
	an assertion failure:

	  thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.

	To understand what's going on we need some background; a vmcore file
	represents each processor core in the same way that a standard
	application core file represents threads.  Thus, we might say, a
	vmcore file represents cores as threads.

	When writing a vmcore file, the kernel will store the pid of the
	process currently running on that core as the thread's lwpid.

	However, if a core is idle, with no process currently running on it,
	then the lwpid for that thread is stored as 0 in the vmcore file.  If
	multiple cores are idle then multiple threads will have a lwpid of 0.

	Back in 2010, the original issue reported tried to change the kernel's
	behaviour in this thread:

	  https://lkml.org/lkml/2010/8/3/75

	This change was rejected by the kernel team, the current
	behaviour (lwpid of 0) was considered correct.  I've checked the
	source of a recent kernel.  The code mentioned in the lkml.org posting
	has moved, it's now in the function crash_save_cpu in the file
	kernel/kexec_core.c, but the general behaviour is unchanged, an idle
	core will have an lwpid of 0, so I think GDB still needs to be able to
	handle this case.

	When GDB loads a vmcore file (which is handled just like any other
	core file) the sections are processed in core_open to generate the
	threads for the core file.  The processing is done by calling
	add_to_thread_list, a function which looks for sections named .reg/NN
	where NN is the lwpid of the thread, GDB then builds a ptid_t for the
	new thread and calls add_thread.

	Remember, in our case the lwpid is 0.  Now for the first thread this
	is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
	OK, GDB creates a thread with lwpid of 0 and carries on.

	When we find the next thread (core) with lwpid of 0, we attempt to
	create another thread with an lwpid of 0.  This of course clashes with
	the previously created thread, they have the same ptid_t, so GDB tries
	to delete the first thread.

	And it was within this thread delete code that we triggered a bug
	which would then cause GDB to assert -- when deleting we tried to
	switch to a thread with minus_one_ptid, this resulted in a call to
	find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
	find_inferior_pid call fails and returns NULL, which then triggered an
	assert in switch_to_thread.

	The actual details of the why the assert triggered are really not
	important.  What's important (I think) is that a vmcore file might
	have this interesting lwpid of 0 characteristic, which isn't something
	we see in "normal" application core files, and it is this that I think
	we should be testing.

	Now, you might be thinking: isn't deleting the first thread the wrong
	thing to do?  If the vmcore file has two threads that represent two
	cores, and both have an lwpid of 0 (indicating both cores are idle),
	then surely GDB should still represent this as two threads?  You're
	not wrong.  This was mentioned by Pedro in the original GDB mailing
	list thread here:

	  https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/

	This is indeed a problem, and this problem is still present in GDB
	today.  I plan to try and address this in a later commit, however,
	this first commit is about getting a test in place to confirm that GDB
	at a minimum doesn't crash when loading such a vmcore file.

	And so, finally, what's in this commit?

	This commit contains a new test.  The test doesn't actually contain a
	vmcore file.  Instead I've created a standard application core file
	that contains two threads, and then manually edited the core file to
	set the lwpid of each thread to 0.

	To further reduce the size of the core file (as it will be stored in
	git), I've zeroed all of the LOAD-able segments in the core file.
	This test really doesn't care about that part of the core file, we
	only really care about loading the register's, this is enough to
	confirm that the GDB doesn't crash.

	Obviously as the core file is pre-generated, this test is architecture
	specific.  There are already a few tests in gdb.arch/ that include
	pre-generate core files.  Just as those existing tests do, I've
	compressed the core file with bzip2, which reduces it to just 750
	bytes.  I have structured the test so that if/when this patch is
	merged I can add some additional core files for other architectures,
	however, these are not included in this commit.

	The test simply expands the core file, and then loads it into GDB.
	One interesting thing to note is that GDB reports the core file
	loading like this:

	  (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
	  [New process 1]
	  [New process 1]
	  Failed to read a valid object file image from memory.
	  Core was generated by `./segv-mt'.
	  Program terminated with signal SIGSEGV, Segmentation fault.
	  The current thread has terminated
	  (gdb)

	There's two interesting things here: first, the repeated "New process
	1" message.  This is caused because linux_core_pid_to_str reports
	anything with an lwpid of 0 as a process, rather than an LWP.  And
	second, the "The current thread has terminated" message.  This is
	because the first thread in the core file is the current thread, but
	when GDB loads the second thread (which also has lwpid 0) this causes
	the first thread to be deleted, as a result GDB thinks that the
	current (first) thread has terminated.

	As I said previously, both of these problems are a result of the lwpid
	0 aliasing, which is not being fixed in this commit -- this commit is
	just confirming that GDB doesn't crash when loading this core file.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2023-07-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: split inferior and thread setup when opening a core file
	I noticed that in corelow.c, when a core file is opened, both the
	thread and inferior setup is done in add_to_thread_list.  In this
	patch I propose hoisting the inferior setup out of add_to_thread_list
	into core_target_open.

	The only thing about this change that gave me cause for concern is
	that in add_to_thread_list, we only setup the inferior after finding
	the first section with a name like ".reg/NN".  If we find no such
	section then the inferior will never be setup.

	Is this important?

	Well, I don't think so.  Back in core_target_open, if there is no
	current thread (which there will not be if no ".reg/NN" section was
	found), then we look for a thread in the current inferior.  If there
	are no threads (which there will not be if no ".reg/NN" is found),
	then we once again setup the current inferior.

	What I think this means, is that, in all cases, the current inferior
	will end up being setup.  By moving the inferior setup code earlier in
	core_target_open and making it non-conditional, we can remove the
	later code that sets up the inferior, we now know this will always
	have been done.

	There should be no user visible changes after this commit.

	Reviewed-By: Kevin Buettner <kevinb@redhat.com>

2023-07-03  Nick Clifton  <nickc@redhat.com>

	Update after creating 2.41 branch

	Change version number to 2.41.50 and regenerate files

2023-07-03  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Zvkh[a,b]: Remove individual instruction class
	Currently we have three instruction classes defined for Zvkh[a,b]:
	- INSN_CLASS_ZVKNHA
	- INSN_CLASS_ZVKNHB
	- INSN_CLASS_ZVKNHA_OR_ZVKNHB

	The encodings of all instructions in Zvknh[a,b] are identical.
	Therefore, we don't need the individual instruction classes
	and can remove them.

	This patch also adds the missing support of the combined instruction
	class in riscv_multi_subset_supports_ext().

	Fixes: 62edb233ef5 ("RISC-V: Add support for the Zvknh[a,b] ISA extensions")
	Reported-By: Nelson Chu <nelson@rivosinc.com>

2023-07-03  Nick Clifton  <nickc@redhat.com>

	Add markers for the 2.41 branch

2023-07-03  WANG Xuerui  <git@xen0n.name>

	gas: NEWS: Announce LoongArch changes in the 2.41 cycle
	gas/ChangeLog:

		* NEWS: Mention LoongArch changes for 2.41.

2023-07-03  WANG Xuerui  <git@xen0n.name>

	binutils: NEWS: Announce LoongArch changes in the 2.41 cycle
	binutils/ChangeLog:

		* NEWS: Mention LoongArch changes for 2.41.

2023-07-03  WANG Xuerui  <git@xen0n.name>

	LoongArch: gas: Fix shared builds
	Formerly an include of libbfd.h was added in commit 56576f4a722
	("LoongArch: gas: Add support for linker relaxation."), in order to
	allow calling _bfd_read_unsigned_leb128 from gas, but doing so broke
	shared builds. Commit d2fddb6d783 fixed this reference but did not
	remove the now unnecessary inclusion of libbfd.h. The gas_assert macro
	expands into a conditional call to abort(), but "abort" is re-defined to
	_bfd_abort in libbfd.h, so the extra include breaks any gas_assert
	usage, and should be removed.

	gas/ChangeLog:

		* config/tc-loongarch.c: Don't include libbfd.h.

	Fixes: d2fddb6d783 ("LoongArch: Fix ld "undefined reference" error with --enable-shared")

2023-07-03  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: Mark address offset operands of LVZ/LBT insns as such
	opcodes/ChangeLog:

		* loongarch-opc.c: Mark the offset operands as "so" for
		{,x}v{ld,st}, {,x}v{ldrepl,stelm}.[bhwd], and {ld,st}[lr].[wd].

2023-07-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-07-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix data race
	In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
	the output of gprofng to display the data. Sometimes this data is corrupted.

	gprofng/ChangeLog
	2023-06-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/ipc.cc (ipc_doWork): Fix data race.
		* src/ipcio.cc (IPCresponse::print): Fix data race.
		Remove unused variables and functions.
		* src/ipcio.h: Declare two variables.
		* src/StringBuilder.cc (StringBuilder::write): New function.
		* src/StringBuilder.h: Likewise.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	binutils: NEWS: Announce new RISC-V vector crypto extensions
	This commit adds the recently added support of the RISC-V vector crypto
	extensions to the NEWS file.

	binutils/ChangeLog:

		* NEWS: Announce new RISC-V vector crypto extensions.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Add support for the Zvksc ISA extension
	Zvksc is part of the vector crypto extensions.

	Zvksc is shorthand for the following set of extensions:
	- Zvks
	- Zvbc

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvksc extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvksc.d: New test.
		* testsuite/gas/riscv/zvksc.s: New test.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Add support for the Zvknc ISA extension
	Zvknc is part of the vector crypto extensions.

	Zvknc is shorthand for the following set of extensxions:
	- Zvkn
	- Zvbc

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvknc extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvknc.d: New test.
		* testsuite/gas/riscv/zvknc.s: New test.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Add support for the Zvksg ISA extension
	Zvksg is part of the vector crypto extensions.

	Zvksg is shorthand for the following set of extensions:
	- Zvks
	- Zvkg

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvksg extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvksg.d: New test.
		* testsuite/gas/riscv/zvksg.s: New test.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvks ISA extension
	Zvks is part of the vector crypto extensions.

	Zvks is shorthand for the following set of extensions:
	- Zvksed
	- Zvksh
	- Zvbb
	- Zvkt

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvks extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvks.d: New test.
		* testsuite/gas/riscv/zvks.s: New test.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Add support for the Zvkng ISA extension
	Zvkng is part of the vector crypto extensions.

	Zvkng is shorthand for the following set of extensions:
	- Zvkn
	- Zvkg

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvkng extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvkng.d: New test.
		* testsuite/gas/riscv/zvkng.s: New test.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Allow nested implications for extensions
	Certain extensions require two levels of implications.  For example,
	zvkng implies zvkn and zvkn implies zvkned.  Enabling zvkng should also
	enable zvkned.

	This patch fixes this behavior.

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_parse_add_implicit_subsets): Allow nested
		implications for extensions.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvkn ISA extension
	Zvkn is part of the vector crypto extensions.

	Zvkn is shorthand for the following set of extensions:
	- Zvkned
	- Zvknhb
	- Zvbb
	- Zvkt

	bfd/ChangeLog:

		* elfxx-riscv.c: Define Zvkn extension.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvkn.d: New test.
		* testsuite/gas/riscv/zvkn.s: New test.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvksh ISA extension
	Zvksh is part of the vector crypto extensions.

	This extension adds the following instructions:
	- vsm3me.vv
	- vsm3c.vi

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvksh.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvksh.d: New test.
		* testsuite/gas/riscv/zvksh.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VSM3C_VI): New.
		(MASK_VSM3C_VI): New.
		(MATCH_VSM3ME_VV): New.
		(MASK_VSM3ME_VV): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		support for Zvksh.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvksh instructions.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvksed ISA extension
	Zvksed is part of the vector crypto extensions.

	This extension adds the following instructions:
	- vsm4k.vi
	- vsm4r.[vv,vs]

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvksed.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvksed.d: New test.
		* testsuite/gas/riscv/zvksed.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VSM4K_VI): New.
		(MASK_VSM4K_VI): New.
		(MATCH_VSM4R_VS): New.
		(MASK_VSM4R_VS): New.
		(MATCH_VSM4R_VV): New.
		(MASK_VSM4R_VV): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		support for Zvksed.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvksed instructions.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvknh[a,b] ISA extensions
	Zvknh[a,b] are parts of the vector crypto extensions.

	This extension adds the following instructions:
	- vsha2ms.vv
	- vsha2c[hl].vv

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvknh[a,b].
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvknha.d: New test.
		* testsuite/gas/riscv/zvknha_zvknhb.s: New test.
		* testsuite/gas/riscv/zvknhb.d: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VSHA2CH_VV): New.
		(MASK_VSHA2CH_VV): New.
		(MATCH_VSHA2CL_VV): New.
		(MASK_VSHA2CL_VV): New.
		(MATCH_VSHA2MS_VV): New.
		(MASK_VSHA2MS_VV): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		support for Zvknh[a,b].

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvknh[a,b] instructions.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvkned ISA extension
	Zvkned is part of the vector crypto extensions.

	This extension adds the following instructions:
	- vaesef.[vv,vs]
	- vaesem.[vv,vs]
	- vaesdf.[vv,vs]
	- vaesdm.[vv,vs]
	- vaeskf1.vi
	- vaeskf2.vi
	- vaesz.vs

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvkned.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvkned.d: New test.
		* testsuite/gas/riscv/zvkned.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VAESDF_VS): New.
		(MASK_VAESDF_VS): New.
		(MATCH_VAESDF_VV): New.
		(MASK_VAESDF_VV): New.
		(MATCH_VAESDM_VS): New.
		(MASK_VAESDM_VS): New.
		(MATCH_VAESDM_VV): New.
		(MASK_VAESDM_VV): New.
		(MATCH_VAESEF_VS): New.
		(MASK_VAESEF_VS): New.
		(MATCH_VAESEF_VV): New.
		(MASK_VAESEF_VV): New.
		(MATCH_VAESEM_VS): New.
		(MASK_VAESEM_VS): New.
		(MATCH_VAESEM_VV): New.
		(MASK_VAESEM_VV): New.
		(MATCH_VAESKF1_VI): New.
		(MASK_VAESKF1_VI): New.
		(MATCH_VAESKF2_VI): New.
		(MASK_VAESKF2_VI): New.
		(MATCH_VAESZ_VS): New.
		(MASK_VAESZ_VS): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		support for Zvkned.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvkned instructions.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvkg ISA extension
	Zvkg is part of the vector crypto extensions.

	This extension adds the following instructions:
	- vghsh.vv
	- vgmul.vv

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvkg.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvkg.d: New test.
		* testsuite/gas/riscv/zvkg.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VGHSH_VV): New.
		(MASK_VGHSH_VV): New.
		(MATCH_VGMUL_VV): New.
		(MASK_VGMUL_VV): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		support for Zvkg.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvkg instructions.

2023-07-01  Nathan Huckleberry  <nhuck@google.com>

	RISC-V: Add support for the Zvbc extension
	Zvbc is part of the crypto vector extensions.

	This extension adds the following instructions:
	- vclmul.[vv,vx]
	- vclmulh.[vv,vx]

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvbc.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* testsuite/gas/riscv/zvbc.d: New test.
		* testsuite/gas/riscv/zvbc.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VCLMUL_VV): New.
		(MASK_VCLMUL_VV): New.
		(MATCH_VCLMUL_VX): New.
		(MASK_VCLMUL_VX): New.
		(MATCH_VCLMULH_VV): New.
		(MASK_VCLMULH_VV): New.
		(MATCH_VCLMULH_VX): New.
		(MASK_VCLMULH_VX): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction class
		  support for Zvbc.

	opcodes/ChangeLog:

		* riscv-opc.c: Add Zvbc instruction.

2023-07-01  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zvbb ISA extension
	Zvbb is part of the vector crypto extensions.

	This extension adds the following instructions:
	- vandn.[vv,vx]
	- vbrev.v
	- vbrev8.v
	- vrev8.v
	- vclz.v
	- vctz.v
	- vcpop.v
	- vrol.[vv,vx]
	- vror.[vv,vx,vi]
	- vwsll.[vv,vx,vi]

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for Zvbb.
		(riscv_multi_subset_supports_ext): Likewise.

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn): Add 'l' as new format
		string directive.
		(riscv_ip): Likewise.
		* testsuite/gas/riscv/zvbb.d: New test.
		* testsuite/gas/riscv/zvbb.s: New test.

	include/ChangeLog:

		* opcode/riscv-opc.h (MATCH_VANDN_VV): New.
		(MASK_VANDN_VV): New.
		(MATCH_VANDN_VX): New.
		(MASK_VANDN_VX): New.
		(MATCH_VBREV8_V): New.
		(MASK_VBREV8_V): New.
		(MATCH_VBREV_V): New.
		(MASK_VBREV_V): New.
		(MATCH_VCLZ_V): New.
		(MASK_VCLZ_V): New.
		(MATCH_VCPOP_V): New.
		(MASK_VCPOP_V): New.
		(MATCH_VCTZ_V): New.
		(MASK_VCTZ_V): New.
		(MATCH_VREV8_V): New.
		(MASK_VREV8_V): New.
		(MATCH_VROL_VV): New.
		(MASK_VROL_VV): New.
		(MATCH_VROL_VX): New.
		(MASK_VROL_VX): New.
		(MATCH_VROR_VI): New.
		(MASK_VROR_VI): New.
		(MATCH_VROR_VV): New.
		(MASK_VROR_VV): New.
		(MATCH_VROR_VX): New.
		(MASK_VROR_VX): New.
		(MATCH_VWSLL_VI): New.
		(MASK_VWSLL_VI): New.
		(MATCH_VWSLL_VV): New.
		(MASK_VWSLL_VV): New.
		(MATCH_VWSLL_VX): New.
		(MASK_VWSLL_VX): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (EXTRACT_RVV_VI_UIMM6): New.
		(ENCODE_RVV_VI_UIMM6): New.
		(enum riscv_insn_class): Add instruction class for Zvbb.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Add 'l' as new format string
		directive.
		* riscv-opc.c: Add Zvbb instructions.

2023-07-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-30  Tom Tromey  <tom@tromey.com>

	Fix regressions caused by agent expression C++-ification
	Simon pointed out that my agent expression C++-ification patches
	caused a regression with the native-gdbserver target board.  The bug
	is that append_const is supposed to write in big-endian order, but I
	switched this by mistake.

2023-06-30  Philipp Tomsich  <philipp.tomsich@vrull.eu>

	binutils: NEWS: announce new RISC-V extensions
	We picked up support for a few new extensions over the last weeks
	(this may need further updating prior to the next release), list them
	in the NEWS file.

	binutils/ChangeLog:

		* binutils/NEWS: announce suuport for the new RISC-V
	          extensions (Zicond, Zfa, XVentanaCondOps).

2023-06-30  Christoph Müllner  <christoph.muellner@vrull.eu>

	RISC-V: Add support for the Zfa extension
	This patch adds support for the RISC-V Zfa extension,
	which introduces additional floating-point instructions:
	* fli (load-immediate) with pre-defined immediates
	* fminm/fmaxm (like fmin/fmax but with different NaN behaviour)
	* fround/froundmx (round to integer)
	* fcvtmod.w.d (Modular Convert-to-Integer)
	* fmv* to access high bits of FP registers in case XLEN < FLEN
	* fleq/fltq (quiet comparison instructions)

	Zfa defines its instructions in combination with the following
	extensions:
	* single-precision floating-point (F)
	* double-precision floating-point (D)
	* quad-precision floating-point (Q)
	* half-precision floating-point (Zfh)

	This patch is based on an earlier version from Tsukasa OI:
	  https://sourceware.org/pipermail/binutils/2022-September/122939.html
	Most significant change to that commit is the switch from the rs1-field
	value to the actual floating-point value in the last operand of the fli*
	instructions. Everything that strtof() can parse is accepted and
	the '%a' printf specifier is used to output hex floating-point literals
	in the disassembly.

	The Zfa specification is frozen (and has passed public review).  It is
	available as a chapter in "The RISC-V Instruction Set Manual: Volume 1":
	  https://github.com/riscv/riscv-isa-manual/releases

	bfd/ChangeLog:

		* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
		class support for 'Zfa' extension.
		(riscv_multi_subset_supports_ext): Likewise.
		(riscv_implicit_subsets): Add 'Zfa' -> 'F' dependency.

	gas/ChangeLog:

		* config/tc-riscv.c (flt_lookup): New helper to lookup a float value
		in an array.
		(validate_riscv_insn): Add 'Wfv' as new format string directive.
		(riscv_ip): Likewise.
		* doc/c-riscv.texi: Add floating-point chapter and describe
		limiations of the Zfa FP literal parsing.
		* testsuite/gas/riscv/zfa-32.d: New test.
		* testsuite/gas/riscv/zfa-32.s: New test.
		* testsuite/gas/riscv/zfa-64.d: New test.
		* testsuite/gas/riscv/zfa-64.s: New test.
		* testsuite/gas/riscv/zfa-fail.d: New test.
		* testsuite/gas/riscv/zfa-fail.l: New test.
		* testsuite/gas/riscv/zfa-fail.s: New test.
		* testsuite/gas/riscv/zfa.d: New test.
		* testsuite/gas/riscv/zfa.s: New test.
		* testsuite/gas/riscv/zfa.s: New test.

		* opcode/riscv-opc.h (MATCH_FLI_H): New.
		(MASK_FLI_H): New.
		(MATCH_FMINM_H): New.
		(MASK_FMINM_H): New.
		(MATCH_FMAXM_H): New.
		(MASK_FMAXM_H): New.
		(MATCH_FROUND_H): New.
		(MASK_FROUND_H): New.
		(MATCH_FROUNDNX_H): New.
		(MASK_FROUNDNX_H): New.
		(MATCH_FLTQ_H): New.
		(MASK_FLTQ_H): New.
		(MATCH_FLEQ_H): New.
		(MASK_FLEQ_H): New.
		(MATCH_FLI_S): New.
		(MASK_FLI_S): New.
		(MATCH_FMINM_S): New.
		(MASK_FMINM_S): New.
		(MATCH_FMAXM_S): New.
		(MASK_FMAXM_S): New.
		(MATCH_FROUND_S): New.
		(MASK_FROUND_S): New.
		(MATCH_FROUNDNX_S): New.
		(MASK_FROUNDNX_S): New.
		(MATCH_FLTQ_S): New.
		(MASK_FLTQ_S): New.
		(MATCH_FLEQ_S): New.
		(MASK_FLEQ_S): New.
		(MATCH_FLI_D): New.
		(MASK_FLI_D): New.
		(MATCH_FMINM_D): New.
		(MASK_FMINM_D): New.
		(MATCH_FMAXM_D): New.
		(MASK_FMAXM_D): New.
		(MATCH_FROUND_D): New.
		(MASK_FROUND_D): New.
		(MATCH_FROUNDNX_D): New.
		(MASK_FROUNDNX_D): New.
		(MATCH_FLTQ_D): New.
		(MASK_FLTQ_D): New.
		(MATCH_FLEQ_D): New.
		(MASK_FLEQ_D): New.
		(MATCH_FLI_Q): New.
		(MASK_FLI_Q): New.
		(MATCH_FMINM_Q): New.
		(MASK_FMINM_Q): New.
		(MATCH_FMAXM_Q): New.
		(MASK_FMAXM_Q): New.
		(MATCH_FROUND_Q): New.
		(MASK_FROUND_Q): New.
		(MATCH_FROUNDNX_Q): New.
		(MASK_FROUNDNX_Q): New.
		(MATCH_FLTQ_Q): New.
		(MASK_FLTQ_Q): New.
		(MATCH_FLEQ_Q): New.
		(MASK_FLEQ_Q): New.
		(MATCH_FCVTMOD_W_D): New.
		(MASK_FCVTMOD_W_D): New.
		(MATCH_FMVH_X_D): New.
		(MASK_FMVH_X_D): New.
		(MATCH_FMVH_X_Q): New.
		(MASK_FMVH_X_Q): New.
		(MATCH_FMVP_D_X): New.
		(MASK_FMVP_D_X): New.
		(MATCH_FMVP_Q_X): New.
		(MASK_FMVP_Q_X): New.
		(DECLARE_INSN): New.
		* opcode/riscv.h (enum riscv_insn_class): Add instruction
		classes for the Zfa extension.

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Add support for
		new format string directive 'Wfv'.
		* riscv-opc.c: Add Zfa instructions.

	Co-Developed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
	Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
	Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-06-30  Nick Clifton  <nickc@redhat.com>

	strings: Improve code to detect excessively large minimum string lengths.
	  PR 30598
	  * strings.c (set_string_min): New function. (main): Use it. (print_unicode_stream): Calculate buffer size using a size_t.

	Prevent an illegal memory access when running the strings program with an excessively lerge minimum string length.
	  PR 30595
	  * strings.c (main): Check for an excessively large minimum string length.

	Fix used-before-initialized warnings when compiling elf.c with Clang-16.

2023-06-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Fix code style issues
	  Blocks of 8 spaces be replaced with tabs.
	  Fix alignment issues.

2023-06-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Add LVZ and LBT instructions support
	gas/ChangeLog:
		* config/tc-loongarch.c (md_parse_option): Add LARCH_opts.ase_lvz and
		LARCH_opts.ase_lbt.
		* testsuite/gas/loongarch/uleb128.d: Regenerated.
		* testsuite/gas/loongarch/lvz-lbt.d: New test.
		* testsuite/gas/loongarch/lvz-lbt.s: New test.

	include/ChangeLog:
		* opcode/loongarch.h (ase_lvz): New.
		(ase_lbt): New.

	opcodes/ChangeLog:
		* loongarch-dis.c (set_default_loongarch_dis_options): Add
		LARCH_opts.ase_lvz and LARCH_opts.ase_lbt.
		* loongarch-opc.c (struct loongarch_ase): Add LVZ and LBT instructions.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	LoongArch: Deprecate $v[01], $fv[01] and $x names per spec
	As outlined in the LoongArch ELF psABI spec [1], it is actually already
	2 versions after the initial LoongArch support, and the $v[01] and
	$fv[01] names should really get sunset by now.

	In addition, the "$x" name for $r21 was never included in any released
	version of the ABI spec, and such usages are all fixed to say just $r21
	for every project I could think of that accepted a LoongArch port.

	Plus, the upcoming LSX/LASX support makes use of registers named
	"$vrNN" and "$xrNN", so having "$vN" and "$x" alongside would almost
	certainly create confusion for developers.

	Issue warnings for such usages per the deprecation procedure detailed
	in the spec, so we can finally remove support in the next release cycle
	after this.

	[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

	gas/ChangeLog:

		* config/tc-loongarch.c: Init canonical register ABI name
		mappings and deprecated register names.
		(loongarch_args_parser_can_match_arg_helper): Warn in case of
		deprecated register name usage.
		* testsuite/gas/loongarch/deprecated_reg_aliases.d: New test.
		* testsuite/gas/loongarch/deprecated_reg_aliases.l: Likewise.
		* testsuite/gas/loongarch/deprecated_reg_aliases.s: Likewise.

	include/ChangeLog:

		* opcode/loongarch.h: Rename global variables.

	opcodes/ChangeLog:

		* loongarch-opc.c: Rename the alternate/deprecated register name
		mappings, and move $x to the deprecated name map.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: print unrecognized insn words with the .word directive
	For better round-trip fidelity and readability in general.

	gas/ChangeLog:

		* testsuite/gas/loongarch/uleb128.d: Update test case.
		* testsuite/gas/loongarch/raw-insn.d: New test.
		* testsuite/gas/loongarch/raw-insn.s: Likewise.

	opcodes/ChangeLog:

		* loongarch-dis.c (disassemble_one): Print ".word" if !opc.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: do not print hex notation for signed immediates
	The additional hex notation was minimally useful when one had to
	inspect code with heavy bit manipulation, or of unclear signedness, but
	it clutters the output, and the style is not regular assembly language
	syntax either.

	Precisely how one approaches the original use case is not taken care of
	in this patch (maybe we want a disassembler option forcing a certain
	style for immediates, like for example printing every immediate in
	decimal or hexadecimal notation), but at least let's stop the current
	practice.

	ChangeLog:

		* testsuite/gas/loongarch/imm_ins.d: Update test case.
		* testsuite/gas/loongarch/imm_ins_32.d: Likewise.
		* testsuite/gas/loongarch/imm_op.d: Likewise.
		* testsuite/gas/loongarch/jmp_op.d: Likewise.
		* testsuite/gas/loongarch/load_store_op.d: Likewise.
		* testsuite/gas/loongarch/macro_op.d: Likewise.
		* testsuite/gas/loongarch/macro_op_32.d: Likewise.
		* testsuite/gas/loongarch/privilege_op.d: Likewise.
		* testsuite/gas/loongarch/uleb128.d: Likewise.
		* testsuite/gas/loongarch/vector.d: Likewise.

	ld/ChangeLog:

		* testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
		* testsuite/ld-loongarch-elf/macro_op.d: Likewise.
		* testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.

	opcodes/ChangeLog:

		* loongarch-dis.c (dis_one_arg): Remove the "(0x%x)" part from
		disassembly output of signed immediate operands.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: style disassembled address offsets as such
	Add a modifier char 'o' telling the disassembler to print the immediate
	using the address offset style, and mark the memory access instructions'
	offset operands as such.

	opcodes/ChangeLog:

		* loongarch-dis.c (dis_one_arg): Style disassembled address
		offsets as such when the operand has a modifier char 'o'.
		* loongarch-opc.c: Add 'o' to operands that represent address
		offsets.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: implement style support in the disassembler
	Update the LoongArch disassembler to supply style information to the
	disassembler output. The output formatting remains unchanged.

	opcodes/ChangeLog:

		* disassemble.c: Mark LoongArch as created_styled_output=true.
		* loongarch-dis.c (dis_one_arg): Use fprintf_styled_func
		throughout with proper styles.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	opcodes/loongarch: remove unused code
	Remove some unused declarations and code.

	include/ChangeLog:

		* opcode/loongarch.h: Remove unused declarations.

	opcodes/ChangeLog:

		* loongarch-dis.c (loongarch_parse_dis_options): Remove.
		(my_print_address_func): Likewise.
		(loongarch_disassemble_one): Likewise.

2023-06-30  WANG Xuerui  <git@xen0n.name>

	LoongArch: support disassembling certain pseudo-instructions
	Add a flag in the pinfo field for being able to mark certain specialized
	matchers as disassembler-only, so some degree of isolation between
	assembler-side and disassembler-side can be achieved.

	This isolation is necessary, firstly because some pseudo-instructions
	cannot be fully described in the opcode table, like `li.[wd]`, so the
	corresponding opcode entry cannot have meaningful match/mask values.
	Secondly, some of these pseudo-instructions can be realized in more than
	one plausible ways; e.g. `li.w rd, <something between 0 and 0x7ff>` can
	be realized on LA64 with any of `addi.w`, `addi.d` or `ori`. If we tie
	disassembly of such aliases with the corresponding GAS support, only one
	canonical form among the above would be recognized as `li.w`, and it
	would mildly impact the readability of disassembly output.
	People wanting the exact disassembly can always set `-M no-aliases` to
	get the original behavior back.

	In addition, in certain cases, information is irreversibly lost after
	assembling, so perfect round-trip would not be possible in such cases.
	For example, `li.w` and `li.d` of immediates within int32_t range
	produce the same code; in this patch, `addi.d rd, $zero, imm` is treated
	as `li.d`, while `addi.w` and `ori` immediate loads are shown as `li.w`,
	due to the expressible value range well within 32 bits.

	gas/ChangeLog:

		* config/tc-loongarch.c (get_loongarch_opcode): Ignore
		disassembler-only aliases.
		* testsuite/gas/loongarch/64_pcrel.d: Update test case.
		* testsuite/gas/loongarch/imm_ins.d: Likewise.
		* testsuite/gas/loongarch/imm_ins_32.d: Likewise.
		* testsuite/gas/loongarch/jmp_op.d: Likewise.
		* testsuite/gas/loongarch/li.d: Likewise.
		* testsuite/gas/loongarch/macro_op.d: Likewise.
		* testsuite/gas/loongarch/macro_op_32.d: Likewise.
		* testsuite/gas/loongarch/macro_op_large_abs.d: Likewise.
		* testsuite/gas/loongarch/macro_op_large_pc.d: Likewise.
		* testsuite/gas/loongarch/nop.d: Likewise.
		* testsuite/gas/loongarch/relax_align.d: Likewise.
		* testsuite/gas/loongarch/reloc.d: Likewise.

	include/ChangeLog:

		* opcode/loongarch.h (INSN_DIS_ALIAS): Add.

	ld/ChangeLog:

		* testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
		* testsuite/ld-loongarch-elf/macro_op.d: Likewise.
		* testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
		* testsuite/ld-loongarch-elf/relax-align.dd: Likewise.

	opcodes/ChangeLog:

		* loongarch-dis.c: Move register name map declarations to top.
		(get_loongarch_opcode_by_binfmt): Consider aliases when
		disassembling without the no-aliases option.
		(parse_loongarch_dis_option): Support the no-aliases option.
		* loongarch-opc.c: Collect pseudo instructions into a new
		dedicated table.

2023-06-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-30  Indu Bhagat  <indu.bhagat@oracle.com>

	binutils/NEWS: announce SFrame version 2 as the new default

2023-06-30  Indu Bhagat  <indu.bhagat@oracle.com>

	doc: sframe: update specification for SFRAME_VERSION_2
	Add details for the changes made from Version 1 to Version 2 of the format.

	Also add details about alignment in the SFrame format.  A portion of the
	SFrame stack trace format has an unaligned on-disk representation.  Add
	description at relevant points in the specificatin to clarify the
	alignment related details.

2023-06-30  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: bfd: gas: ld: format bump to SFrame version 2
	SFrame version 2 encodes the size of repetitive insn block explicitly
	in the format.  Add information in the SFrame FDE to convey the size
	of the block of repeating instructions.  This information is used only
	for SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.

	Introduce two extra bytes for padding: this ensures that the memory
	accesses to the members of the SFrame Frame Descriptor Entry (FDE) are
	naturally aligned.

	gas generates SFrame section with version SFRAME_VERSION_2 by default.

	libsframe provides two new APIs to:
	  - get an SFrame FDE data from the decoder context, and
	  - add an SFrame FDE to the encoder context.
	The additional argument (for rep_block_size) is useful for SFrame FDEs
	where FDE type is SFRAME_FDE_TYPE_PCMASK.

	The linker will generate the output SFrame sections in the
	SFRAME_VERSION_2 format.  If the input sections offered to the linker
	are not all in the SFRAME_VERSION_2 format, the linker issues an error
	to the user.

	objdump/readelf will show the following message to the user if .sframe
	section in SFRAME_VERSION_1 format is seen:

	 "No further information can be displayed.  SFrame version not
	 supported."

	In other words, like the rest of the binutils, only the current SFrame
	format version, i.e., SFRAME_VERSION_2 is supported by the textual dump
	facilities.

	bfd/
		* elf-sframe.c (_bfd_elf_merge_section_sframe): Generate an
		output SFrame section with version SFRAME_VERSION_2.  Also,
		error out if the SFrame sections do not all have
		SFRAME_VERSION_2.
		* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Generate SFrame
		section for plt entries with version SFRAME_VERSION_2.
	gas/
		* gen-sframe.c (sframe_set_version): Update to SFRAME_VERSION_2.
		(output_sframe): Likewise.
	gas/testsuite/
		* gas/cfi-sframe/cfi-sframe-aarch64-1.d: Use SFRAME_VERSION_2.
		* gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
		* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
		* gas/cfi-sframe/common-empty-1.d: Likewise.
		* gas/cfi-sframe/common-empty-2.d: Likewise.
		* gas/cfi-sframe/common-empty-3.d: Likewise.
	ld/testsuite/
		* ld-aarch64/sframe-simple-1.d: Adjust for SFRAME_VERSION_2.
		* ld-x86-64/sframe-plt-1.d: Likewise.
		* ld-x86-64/sframe-simple-1.d: Likewise.
	libsframe/
		* libsframe.ver: Add the new APIs.
		* sframe.c (sframe_decoder_get_funcdesc_v2): New definition.
		(sframe_encoder_add_funcdesc_v2): Likewise.
		(sframe_header_sanity_check_p): Include SFRAME_VERSION_2.
		(sframe_fre_check_range_p): Get rep_block_size info from SFrame
		FDE.
		* sframe-dump.c (dump_sframe_header): Add support for
		SFRAME_VERSION_2.
		(dump_sframe): Inform user if SFrame section in SFRAME_VERSION_1
		format is seen.
	libsframe/testsuite/
		* libsframe.decode/DATA-BE: Regenerated data file.
		* libsframe.decode/DATA1: Likewise.
		* libsframe.decode/DATA2: Likewise.
		* libsframe.find/plt-findfre-1.c: Use new API in the testcase.
	include/
		* sframe.h: Add member to encode size of the code block of
		repeating instructions.  Add 2 bytes of padding.
		* sframe-api.h (sframe_decoder_get_funcdesc_v2): New
		declaration.
		(sframe_encoder_add_funcdesc_v2): Likewise.

2023-06-30  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: add new APIs to get SFrame version
	While the SFrame preamble is guaranteed to not change between versions,
	providing these access APIs from the SFrame decoder and encoder APIs is
	for convenience only.  The linker may want to use these APIs as the
	format evolves.

	include/
		* sframe-api.h (sframe_decoder_get_version): New declaration.
		(sframe_encoder_get_version): Likewise.

	libsframe/
		* libsframe/libsframe.ver: Add new APIs.
		* libsframe/sframe.c (sframe_decoder_get_version): New
		definition.
		(sframe_encoder_get_version): Likewise.

2023-06-29  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fix sframe_find_fre for pltN entries
	For a toy application on x86_64, for example, following is the SFrame
	stack trace information for the 3 pltN entries of 16 bytes each:

	   func idx [1]: pc = 0x401030, size = 48 bytes
	   STARTPC[m]      CFA       FP        RA
	   0000000000000000  sp+8      u         u
	   000000000000000b  sp+16     u         u

	The data in first column is the start_ip_offset.  Also note that the FDE
	is of type SFRAME_FDE_TYPE_PCMASK (denoted by the [m] on LHS).

	Where each pltN (note: excluding plt0 entry) entry looks like:

	  401030: jmp    *0x2fca(%rip)
	  401036: push   $0x0
	  40103b: jmp    401020<_init+0x20>

	  401040: jmp    *0x2fc2(%rip)
	  401046: push   $0x1
	  40104b: jmp    401020<_init+0x20>

	  401050: jmp    *0x2fba(%rip)
	  401056: push   $0x2
	  40105b: jmp    401020<_init+0x20>

	Now, to find SFrame stack trace information from an FDE of type
	SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
	like,
	  (start_ip_offset & 0xf) >= (pc & 0xf)

	This works for pltN entry of size, say, less than 16 bytes.  But if the
	pltN entries or similar code stubs (for which SFrame FDE of type
	SFRAME_FDE_TYPE_PCMASK may be used), evolve to be of size > 16 bytes,
	this will cease to work.

	To match the range covered by the SFrame FRE, one should instead perform
	a modulo operation.  The constant for the modulo operation must be the
	size of the pltN entry.  Further, this constant should ideally be
	encoded in the format, as it may be different for each ABI.

	In SFrame Version 2 of the format, we will move towards encoding it
	explicitly in the SFrame FDE.  For now, fix up the logic to at least
	move towards modulo operation.

	libsframe/
		* sframe.c (sframe_fre_check_range_p): New definition.
		(sframe_find_fre): Refactor a bit and use the new definition
		above.
	include/
		* sframe.h (SFRAME_FDE_TYPE_PCMASK): Update comment.
	libsframe/doc/
		* sframe-spec.texi: Fix the text for SFRAME_FDE_TYPE_PCMASK FDE
		type.

2023-06-29  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add -z nosectionheader test to bootstrap.exp
		PR ld/25617
		* testsuite/ld-bootstrap/bootstrap.exp: Add -z nosectionheader
		test.

2023-06-29  H.J. Lu  <hjl.tools@gmail.com>

	ld: Add tests for -z nosectionheader and --strip-section-headers
	Add tests to verify that the linker option, -z nosectionheader and
	objcopy and strip option, --strip-section-headers, work correctly as well
	as linker issues an error when dynamic symbol table from PT_DYNAMIC
	segment is used.

		PR ld/25617
		* testsuite/ld-elf/hash-2.d: New file.
		* testsuite/ld-elf/no-section-header.exp: Likewise.
		* testsuite/ld-elf/pr25617-1-no-sec-hdr.nd: Likewise.
		* testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1-static-no-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Likewise.
		* testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
		* testsuite/ld-elf/pr25617-1a.c: Likewise.
		* testsuite/ld-elf/pr25617-1b.c: Likewise.
		* testsuite/ld-elf/start-noheader.rd: Likewise.
		* testsuite/ld-elf/start-shared-noheader-gnu.rd: Likewise.
		* testsuite/ld-elf/start-shared-noheader-sysv.rd: Likewise.
		* testsuite/ld-elf/start-shared-noheader.nd: Likewise.

2023-06-29  H.J. Lu  <hjl.tools@gmail.com>

	binutils: Add a --strip-section-headers test
		PR ld/25617
		* testsuite/binutils-all/objcopy.exp: Run strip-section-headers-1.
		* testsuite/binutils-all/strip-section-headers-1.d: New file.

2023-06-29  Kaylee Blake  <klkblake@gmail.com>

	ld: Add simple tests for -z nosectionheader
	2020-06-06  Kaylee Blake  <klkblake@gmail.com>
		    H.J. Lu  <hongjiu.lu@intel.com>

		PR ld/25617
		* testsuite/ld-elf/nosectionheader-1.d: New file.
		* testsuite/ld-elf/nosectionheader-2.d: Likewise.

2023-06-29  H.J. Lu  <hjl.tools@gmail.com>

	bfd: Improve nm and objdump without section header
	When there is no section header in an executable or shared library, we
	reconstruct dynamic symbol table from the PT_DYNAMIC segment, which
	contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, DT_STRTAB, DT_SYMTAB,
	DT_STRSZ, and DT_SYMENT entries, to improve nm and objdump.  For DT_HASH,
	the number of dynamic symbol table entries equals the number of chains.
	For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols with non-STB_LOCAL
	indings are in hash table.  Since DT_GNU_HASH/DT_MIPS_XHASH place all
	symbols with STB_LOCAL binding before symbols with other bindings and
	all undefined symbols defined ones in dynamic symbol table, the highest
	symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest dynamic symbol
	table index.  We can also get symbol version from DT_VERSYM, DT_VERDEF
	and DT_VERNEED entries.

	dt_symtab, dt_versym, dt_verdef, dt_verneed, dt_symtab_count,
	dt_verdef_count, dt_verneed_count and dt_strtab are added to
	elf_obj_tdata to store dynamic symbol table information.

		PR ld/25617
		* elf-bfd.h (elf_obj_tdata): Add dt_symtab, dt_verdef, dt_verneed,
		dt_symtab_count, dt_verdef_count, dt_verneed_count and dt_strtab.
		(elf_use_dt_symtab_p): New.
		(_bfd_elf_get_dynamic_symbols): Likewise.
		(_bfd_elf_get_section_from_dynamic_symbol): Likewise.
		* elf.c (bfd_elf_get_elf_syms): Use dynamic symbol table if
		neeeded.
		(_bfd_elf_get_dynamic_symtab_upper_bound): Likewise.
		(_bfd_elf_slurp_version_tables): Likewise.
		(offset_from_vma): New function.
		(get_hash_table_data): Likewise.
		(_bfd_elf_get_dynamic_symbols): Likewise.
		(_bfd_elf_get_section_from_dynamic_symbol): Likewise.
		(_bfd_elf_get_symbol_version_name): Likewise.
		* elfcode.h (elf_object_p): Call _bfd_elf_get_dynamic_symbols
		to reconstruct dynamic symbol table from PT_DYNAMIC segment if
		there is no section header.
		(elf_slurp_symbol_table): Use dynamic symbol table if neeeded.
		Don't free isymbuf when dynamic symbol table is used.
		* elflink.c (elf_link_is_defined_archive_symbol): Return wrong
		format error when dynamic symbol table is used.
		(elf_link_add_object_symbols): Likewise.

2023-06-29  H.J. Lu  <hjl.tools@gmail.com>

	ELF: Discard non-alloc sections without section header
	Discard non-alloc sections when section headers are stripped.

	bfd/

		PR ld/25617
		* elf.c (_bfd_elf_assign_file_positions_for_non_load): Skip
		non-load sections without section header.
		(_bfd_elf_write_object_contents): Don't set the sh_name field
		without section header.  Write out the .shstrtab section only
		if its sh_offset field isn't -1.

	binutils/

		PR ld/25617
		* objcopy.c (is_strip_section_1): Remove non-alloc sections for
		--strip-section-headers.

	ld/

		PR ld/25617
		* ldlang.c (lang_discard_section_p): Discard non-alloc sections
		if we are stripping section headers.

2023-06-29  Kaylee Blake  <klkblake@gmail.com>

	ELF: Strip section header in ELF objects
	Section header isn't mandatory on ELF executable nor shared library.
	This patch adds a new linker option, -z nosectionheader, to omit ELF
	section header, a new objcopy and strip option, --strip-section-headers,
	to remove ELF section headers.

	bfd/

	2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>
		    Kaylee Blake  <klkblake@gmail.com>

		PR ld/25617
		* bfd.c (BFD_NO_SECTION_HEADER): New.
		(BFD_FLAGS_SAVED): Add BFD_NO_SECTION_HEADER.
		(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.
		* elfcode.h (elf_swap_ehdr_out): Omit section header with
		BFD_NO_SECTION_HEADER.
		(elf_write_shdrs_and_ehdr): Likewise.
		* elfxx-target.h (TARGET_BIG_SYM): Add BFD_NO_SECTION_HEADER
		to object_flags.
		(TARGET_LITTLE_SYM): Likewise.
		* bfd-in2.h: Regenerated.

	binutils/

	2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>

		PR ld/25617
		* NEWS: Mention --strip-section-headers for objcopy and strip.
		* objcopy.c (strip_section_headers): New.
		(command_line_switch): Add OPTION_STRIP_SECTION_HEADERS.
		(strip_options): Add --strip-section-headers.
		(copy_options): Likewise.
		(copy_usage): Add --strip-section-headers.
		(strip_usage): Likewise.
		(copy_object): Handle --strip-section-headers for ELF files.
		(strip_main): Handle OPTION_STRIP_SECTION_HEADERS.
		(copy_main): Likewise.
		* doc/binutils.texi: Document --strip-section-headers for objcopy
		and strip.

	ld/

	2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>
		    Kaylee Blake  <klkblake@gmail.com>

		PR ld/25617
		* NEWS: Mention -z nosectionheader.
		* emultempl/elf.em: Support -z sectionheader and
		-z nosectionheader.
		* ld.h (ld_config_type): Add no_section_header.
		* ld.texi: Document -z sectionheader and -z nosectionheader.
		* ldlang.c (ldlang_open_output): Handle
		config.no_section_header.
		* lexsup.c (parse_args): Enable --strip-all with
		-z nosectionheader.  Disallow -r with -z nosectionheader.
		(elf_static_list_options): Add -z sectionheader and
		-z nosectionheader.

2023-06-29  Matthias Klose  <doko@debian.org>

	Ignore --prefix-file-map compiler option whist running testsuite.

	ignore lto-wrapper warnings for lto builds.
	  I see these warnings from time to time, when configuring a build with  --enable-pgo-build=lto, I haven't yet found out why I see these sometime, and  why not. E.g. https://gcc.gnu.org/PR109241. Just ignore these when they appear  in test cases. lto-wrapper: warning: using serial compilation of N LTRANS jobs

2023-06-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Add new tests
	gprofng/ChangeLog
	2023-06-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* Makefile.am: Pass CLOCK_GETTIME_LINK to the testsuite
		* Makefile.in: Rebuild.
		* testsuite/gprofng.display/gp-archive.exp: New file.
		* testsuite/gprofng.display/gp-collect-app_F.exp: New file.
		* testsuite/gprofng.display/setpath_map.exp: New file.
		* testsuite/lib/smalltest.c: New file.

2023-06-28  Andrew Carlotti  <andrew.carlotti@arm.com>

	aarch64: Remove version dependencies from features
	Many instructions were enabled only when both a feature flag and a minimum
	architecture version are specified.  This behaviour differs from GCC, which (in
	most cases) allows features to be enabled at any architecture version.

	There is no need for the toolchain to restrict combinations of unrelated
	features in this way, so this patch removes the unnecessary dependencies.

2023-06-28  Tom Tromey  <tromey@adacore.com>

	Remove Python 2 from gdb documentation
	GDB can't be built using Python 2 any more, so remove the remaining
	vestiges of this from the documentation.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-06-28  Michael Matz  <matz@suse.de>

	section-match: Check parent archive name as well
	rewriting the section matching routines lost a special case
	of matching: section statements of the form

	    NAME(section-glob)

	normally match against NAME being an object file, but like in
	the exclude list we happened to accept archive names as NAME
	(undocumented).  The documented way to specify (all) archive members
	is by using e.g.

	    lib.a:(section-glob)

	(that does work also with the prefix tree matcher).

	But I intended to not actually change behaviour with the prefix
	tree implementation.  So, let's also implement checking against
	archive names with a similar FIXME comment we already have in
	walk_wild_file_in_exclude_list.

		PR 30590

		ld/
		* ldlang.c (walk_wild_section_match): Also look at archive
		parents for a name match.

2023-06-28  Tom Tromey  <tromey@adacore.com>

	Fix handling of DW_TAG_unspecified_type for Ada
	Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type
	DIE") changed the handling of DW_TAG_unspecified_type.  Before this
	change, such types were not entered into the symbol table.

	It turns out that, when such a type is in the symtab, it can cause
	failures in Ada.  In particular, a private type in another package may
	be seen locally as "void".

	Now, it would probably be better to fix this via check_typedef.
	However, that is somewhat difficult given the state of the DWARF
	reader -- in particular with gdb_index, this would require expanding
	potentially many CUs to find the correct type.

	Instead, this patch changes gdb to not enter a symbol for an
	unspecified type -- but only for Ada.

2023-06-28  Tom Tromey  <tromey@adacore.com>

	Remove some Python 2 code
	I found some Python 2 compatibility code in gdb's Python library.
	There's no need for this any more, so this removes it.  There is still
	a bit more of this remaining in __init__.py, but I haven't tried
	removing that yet.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-06-28  Nick Clifton  <nickc@redhat.com>

	Stop the linker's --dependency-file option from including temporary lto files.
	  PR 30568
	  * ldfile.c (ldfile_try_open_bfd): Do not track lto generated temporary files.

	Updated French translation for the gold sub-directory

2023-06-28  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Add LSX and LASX instructions test
	gas/ChangeLog:

		* testsuite/gas/loongarch/vector.d: New test.
		* testsuite/gas/loongarch/vector.s: New test.

2023-06-28  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Add lsx and lasx instructions support
	gas/ChangeLog:

		* config/tc-loongarch.c (md_parse_option): Add lsx and lasx option.
		(loongarch_after_parse_args): Add lsx and lasx option.

	opcodes/ChangeLog:

		* loongarch-opc.c (struct loongarch_ase): Add lsx and lasx
		instructions.

2023-06-28  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Add R_LARCH_64_PCREL relocation support
	  Gas defaults to emit R_LARCH_ADD64/R_LARCH_SUB64 unless explcitly declared
	  to emit R_LARCH_64_PCREL.

	  The LoongArch ABI at here:
	    https://github.com/loongson/la-abi-specs/blob/release/la-abi.adoc

	bfd/ChangeLog:

		* bfd-in2.h (not): Add R_LARCH_64_PCREL
		* elfnn-loongarch.c (perform_relocation): Likewise.
		* elfxx-loongarch.c: Likewise.
		* libbfd.h: Likewise.
		* reloc.c: Likewise.

	gas/ChangeLog:

		* config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
		(md_apply_fix): Add R_LARCH_64_PCREL.
		* testsuite/gas/loongarch/64_pcrel.d: New test.
		* testsuite/gas/loongarch/64_pcrel.s: New test.

	include/ChangeLog:

		* elf/loongarch.h (RELOC_NUMBER): Add R_LARCH_64_PCREL.

	ld/ChangeLog:

		* testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test.
		* testsuite/ld-loongarch-elf/64_pcrel.d: New test.
		* testsuite/ld-loongarch-elf/64_pcrel.s: New test.

2023-06-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	binutils/NEWS: add note about upcoming libsframe changes
	Some of these changes update the ABI in an incompatible way.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: bfd: use uint32_t for return type of get_num_fidx APIs
	Keep the data types usage in libsframe look consistent.

	bfd/
		* elf-sframe.c (_bfd_elf_merge_section_sframe): Use uint32_t
		type alias.
		* libsframe/sframe.c (sframe_decoder_get_funcdesc_at_index):
		Likewise.
		(sframe_decoder_get_num_fidx): Likewise.
		(sframe_encoder_get_num_fidx): Likewise.
	include/
		* sframe-api.h (sframe_decoder_get_num_fidx): Likewise.
		(sframe_encoder_get_num_fidx): Likewise.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use appropriate data types for args of sframe_encode
	include/
		* sframe-api.h (sframe_encode): Use of uint8_t is more
		appropriate.
	libsframe/
		* sframe.c (sframe_encode): Likewise.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use uint8_t for return type of sframe_fre_get_base_reg_id
	Use a more appropriate data type.

	include/
		* sframe-api.h (sframe_fre_get_base_reg_id): Use uint8_t as
		return type.
	libsframe/
		* sframe-dump.c (dump_sframe_func_with_fres): Use uint8_t type
		for base reg id.
		* sframe.c (sframe_fre_get_base_reg_id): Use uin8_t as return
		type.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use uint8_t instead of unsigned char for abi_arch
	Use uint8_t consistently for identifying ABI/arch in SFrame format.

	bfd/
		* elf-sframe.c (_bfd_elf_merge_section_sframe):
	libsframe/
		* sframe-dump.c (is_sframe_abi_arch_aarch64): Use uint8_t for
		local variable.
		* sframe.c (sframe_decoder_get_abi_arch): Update return type to
		uint8_t.
		(sframe_encoder_get_abi_arch): Likewise.
	include/
		* sframe-api.h (sframe_decoder_get_abi_arch): Likewise.
		(sframe_encoder_get_abi_arch): Likewise.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: bfd: use uint32_t for return type of sframe_calc_fre_type
	Use uint32_t type alias consistently for all APIs in libsframe.

	bfd/
		* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for the
		changed return type.
	libsframe/
		* sframe.c (sframe_calc_fre_type): Use uint32_t for return type.
	include/
		* sframe-api.h (sframe_calc_fre_type): Likewise.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use uint32_t for fre_type and fde_type function args
	The API sframe_fde_create_func_info is provided by libsframe.  Current
	users are the bfd linker.  Adjust the argument type for the variables
	carrying the SFrame FRE type and SFrame FDE type to consistenly use
	uint32_t type alias.

	include/
		* sframe-api.h (sframe_fde_create_func_info): Use uint32_t
		instead of unsigned int.
	libsframe/
		* sframe.c (sframe_get_fre_type): Likewise.
		(sframe_get_fde_type): Likewise.
		(flip_fre_start_address): Likewise.
		(sframe_fre_start_addr_size): Likewise.
		(sframe_fre_entry_size): Likewise.
		(flip_fre): Likewise.
		(flip_sframe): Likewise.
		(sframe_fde_create_func_info): Likewise.
		(sframe_calc_fre_type): Likewise.
		(sframe_decode_fre_start_address): Likewise.
		(sframe_decode_fre): Likewise.
		(sframe_find_fre): Likewise.
		(sframe_decoder_get_fre): Likewise.
		(sframe_encoder_add_fre): Likewise.
		(sframe_encoder_write_fre_start_addr): Likewise.
		(sframe_encoder_write_fre): Likewise.
		(sframe_encoder_write_sframe): Likewise.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: update the semantics of sframe_fre_get_fp_offset
	Until now, sframe_fre_get_fp_offset () would return
	SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed FP offset.  A stack
	tracer, then, would call an explicit sframe_decoder_get_fixed_fp_offset ()
	to get the FP offset.

	On second look, it appears to make sense to hide these details of
	whether the FP offset is fixed or not in an ABI from the consumer.  Now,
	with the changed semantics, the call to sframe_fre_get_fp_offset () will
	fetch the fixed FP offset if applicable, or get the FP offset from FRE
	when there is no fixed FP offset.

	This patch changes the behavior of sframe_fre_get_fp_offset (): it turns
	an error into non-error.  This change will be included with the next
	release of libsframe, where all the exposed symbols will be versioned
	with version node LIBSFRAME_1.0 for the first time.

	libsframe/
		* sframe.c (sframe_fre_get_fp_offset): Return the fixed offset, if
		applicable. Else return the FP offset from the FRE.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: update the semantics of sframe_fre_get_ra_offset
	Until now, sframe_fre_get_ra_offset () would return
	SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed RA offset (e.g.,
	AMD64).  A stack tracer, then, will call an explicit
	sframe_decoder_get_fixed_ra_offset () to get the RA offset.

	On second look, it appears to make sense to hide these details of
	whether the RA offset is fixed or not from the consumer.  Now, with the
	changed semantics, the call to sframe_fre_get_ra_offset () will fetch
	the fixed RA offset if applicable, or get the RA offset from FRE when
	there is no fixed RA offset.

	Adjustments need to be made to ensure the textual dump remains the same
	as preivous.  Currently, e.g., if RA is not being tracked per FRE,
	following is seen with objdump --sframe:

	    STARTPC         CFA       FP        RA
	    000000000000NNNN  sp+X      u         u

	This patch changes the behavior of sframe_fre_get_ra_offset: it turns an
	error into non-error.  This change will be included with the next
	release of libsframe, where all exposed symbols will be versioned for
	the first time.

	libsframe/
		* sframe.c (sframe_fre_get_ra_offset): Return the fixed offset,
		if applicable.  Else return the RA offset from the FRE.
		* sframe-dump.c (dump_sframe_func_with_fres): Make adjustments
		to keep the textual dump same as previous.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: add symbol versioning
	Define an empty base version LIBSFRAME_0.0 and add all symbols to
	version LIBSFRAME_1.0.

	The previous release of libsframe (libsframe.so.0) did not have
	versioned symbols.  Adding a libsframe.ver file so that future releases
	of the library (and its consumers) can manage the changes better.

	For Solaris ld, use -M mapfile command line option.  libsframe does not
	restrict the set of exported symbols, so at this time there is no need
	to fall back on the libtool's -export-symbols option for platforms where
	some other linker (with a different command line option for symbol
	versioning) may be used.

	libsframe/
		* Makefile.am: Use symbol versioning for libsframe.
		* Makefile.in: Regenerated.
		* configure: Check for Solaris ld.
		* configure.ac: Regenerated.
		* libsframe.ver: New file.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: remove sframe_get_funcdesc_with_addr API
	This is an incompatible ABI change in libsframe.

	The interface provided by this function is not a healthy abstraction to
	expose: the return type sframe_func_desc_entry, which is defined in
	include/sframe.h (the SFrame binary format definition).  This ties up
	the library in a undesirable way.  Most importantly, this function
	should technically not be directly necessary for a stack tracer.  A
	stack tracer will likely only need to do a sframe_find_fre ().

	Rename the API to continue to use the functionality internally in the
	library.  bfd/linker does not use this function.

	Change the return type of the previous definition and make a note about
	its planned deprecation.

	include/
		* sframe-api.h:  Change return type of sframe_get_funcdesc_with_addr.
		Add comment for intention to deprecate.
	libsframe/
		*sframe.c (sframe_get_funcdesc_with_addr): Change return type
		and set error code. This API is deprecated.
	        (sframe_get_funcdesc_with_addr_internal): New definition for
		internal use.
		(sframe_find_fre): Use sframe_get_funcdesc_with_addr_internal
		instead.

2023-06-27  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: add library versioning
	lisbframe was first released with Bintuils 2.40.  As the library
	evolves, some changes will break the ABI.  Add library versioning for
	users to manage these changes.

	For the next release of the library (libsframe.so.1), incompatible ABI
	changes are planned. These will include:
	 - Deprecation of some APIs, like sframe_get_funcdesc_with_addr (), and
	 - Change in the contract of some APIs (e.g., return type, behavior).

	In libtool-version, set the current to 1 to prepare for the upcoming
	release.  Reset revision and age to 0.

	Add libtool-version file to EXTRA_DIST.

	libsframe/
		* Makefile.am: Use libtool versioning.
		* Makefile.in: Regenerated.
		* libtool-version: New file.

2023-06-27  Philipp Tomsich  <philipp.tomsich@vrull.eu>

	    RISC-V: Support Zicond extension
	    This implements the Zicond (conditional integer operations) extension,
	    as of version 1.0-rc2.

	    The Zicond extension acts as a building block for branchless sequences
	    including conditional-arithmetic, conditional-logic and
	    conditional-select/move.
	    The following instructions constitute Zicond:
	      - czero.eqz rd, rs1, rs2  =>  rd = (rs2 == 0) ? 0 : rs1
	      - czero.nez rd, rs1, rs2  =>  rd = (rs2 != 0) ? 0 : rs1

	    See
	      https://github.com/riscv/riscv-zicond/releases/download/v1.0-rc2/riscv-zicond-v1.0-rc2.pdf
	    for the proposed specification and usage details.

	    bfd/ChangeLog:

	            * elfxx-riscv.c (riscv_multi_subset_supports): Recognize
	            INSN_CLASS_ZICOND.
	            (riscv_multi_subset_supports_ext): Recognize INSN_CLASS_ZICOND.

	    gas/ChangeLog:

	            * testsuite/gas/riscv/zicond.d: New test.
	            * testsuite/gas/riscv/zicond.s: New test.

	    include/ChangeLog:

	            * opcode/riscv-opc.h (MATCH_CZERO_EQZ): Define.
	            (MASK_CZERO_EQZ): Define.
	            (MATCH_CZERO_NEZ): Define,
	            (MASK_CZERO_NEZ): Define.
	            (DECLARE_INSN): Add czero.eqz and czero.nez.
	            * opcode/riscv.h (enum riscv_insn_class): Add
	            INSN_CLASS_ZICOND.

	    opcodes/ChangeLog:

	            * riscv-opc.c: Add czero.eqz and czero.nez.

	    Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

2023-06-27  Nick Clifton  <nickc@redhat.com>

	Add note about adding ChangeLog.git to src-release.sh

2023-06-27  Cui, Lili  <lili.cui@intel.com>

	gprofng: Update intel url
	Since the old software.intel.com has been removed, update a new one.

	gprofng/ChangeLog
	2023-06-27  Lili Cui  <lili.cui@intel.com>

		* gp-display-html/gp-display-html.in: Update intel url.

2023-06-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-26  Nick Clifton  <nickc@redhat.com>

	Fix gas tests for aarch64-pe

	Synchromize libiberty sources with master version in gcc repository

	Sync config.guess and config.sub with upstream master versions.

	Updated French translation for the gprof sub-directory

2023-06-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-25  Feiyang Chen  <chenfeiyang@loongson.cn>

	LoongArch: Support referring to FCSRs as $fcsrX
	Previously, FCSRs were referred to as $rX, which seemed strange.
	We refer to FCSRs as $fcsrX, which ensures compatibility with LLVM
	IAS as well.

	gas/ChangeLog:

	        * config/tc-loongarch.c:
	        (loongarch_fc_normal_name): New definition.
	        (loongarch_fc_numeric_name): New definition.
	        (loongarch_single_float_opcodes): Modify `movgr2fcsr` and
	        `movfcsr2gr`.
	        testsuite/gas/loongarch/float_op.d: Likewise.
	        testsuite/gas/loongarch/float_op.s: Likewise.

	include/ChangeLog:

	        * opcode/loongarch.h:
	        (loongarch_fc_normal_name): New extern.
	        (loongarch_fc_numeric_name): New extern.

	opcodes/ChangeLog:

	        * opcodes/loongarch-dis.c (loongarch_after_parse_args): Support
	        referring to FCSRs as $fcsrX.
	        * opcodes/loongarch-opc.c (loongarch_args_parser_can_match_arg_helper):
	        Likewise.

2023-06-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-23  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Avoid infinite loop in gdb.reverse/step-reverse.exp
	This testcase sometimes gets stuck in a loop for hours when running in our
	CI.  The problem is that due to an issue unrelated to reverse debugging the
	inferior exits early, and because of the overly generic ".*" pattern the
	testcase keeps sending the "next" command without noticing that the
	inferior is gone.

	gdb_test_multiple has a pattern to detect that "The program is not being
	run.", but since it is placed after the patterns from the caller it won't
	be triggered.  It also has a timeout pattern but because it is triggered
	between successful matches, each time the test matches the '-re -wrap ".*"'
	this counts as a successful match and the timeout is reset.

	Since the test binary is compiled with debug information, fix by changing
	one of the generic patterns to match entering the main function and the
	other one to match the source code line number that is shown by GDB right
	after the "step" command.

	Also, as a precaution add a maximum number of times the "next" command will
	be sent.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>
	Approved-By: Tom de Vries <tdevries@suse.de>

2023-06-23  Alan Modra  <amodra@gmail.com>

	[GOLD] PowerPC64 huge branch dynamic relocs
	PowerPC64 gold and ld.bfd implement an indirect branch trampoline,
	used when the destination of a branch exceeds a bounce through another
	"b" instruction.  When generating PIEs or shared libraries, the
	addresses need dynamic relocations.  This was implemented in gold
	using a dedicated relocation section, but this means the relative
	relocations for these addresses are not sorted properly with other
	dynamic relative relocations: gold doesn't support merging relocation
	sections, then sorting.  Instead we need to use a single .rela.dyn
	section.

	This is done by increasing the size of rela_dyn_ during do_relax to
	account for needed dynamic relocations, delaying adding the actual
	relocations until the end of relaxation once the layout has
	stabilised.

		* powerpc.cc (Target_powerpc): Add rela_dyn_size_;
		(update_current_size): New function.
		(Target_powerpc::do_relax): Capture the size of rela_dyn_ at
		the start of relaxation.  Artifically increase its size during
		relaxation to account for needed indirect branches, and add
		those relocations at the end.
		(Output_data_brlt_powerpc::rel_, reset_brlt_sizes),
		(finalize_brlt_sizes, add_reloc, set_current_size): Delete.
		(Target_powerpc::make_brlt_section): Don't make reloc section.

2023-06-23  Alan Modra  <amodra@gmail.com>

	[GOLD] Support setting DT_RELACOUNT late
	PowerPC gold adds relative dynamic relocs in do_relax.  These aren't
	accounted for in the value set in add_target_dynamic_tags, which is
	called before do_relax.  Provide a way of setting DT_RELCOUNT and
	DT_RELACOUNT at the point where .dynamic is written.

		* layout.cc (Layout::add_target_dynamic_tags): Add custom_relcount
		parameter.  Emit DT_RELCOUNT/RELACOUNT as a custom target handled
		dynamic tag if set.
		* layout.h(Layout::add_target_dynamic_tags): Update prototype.
		* aarch64.cc (Target_aarch64::do_finalize_sections): Adjust
		add_target_dynamic_tags call.
		* arm.cc (Target_arm::do_finalize_sections): Likewise.
		* i386.cc (Target_i386::do_finalize_sections): Likewise.
		* mips.cc (Target_mips::do_finalize_sections): Likewise.
		* s390.cc (Target_s390::do_finalize_sections): Likewise.
		* sparc.cc (Target_sparc::do_finalize_sections): Likewise.
		* tilegx.cc (Target_tilegx::do_finalize_sections): Likewise.
		* x86_64.cc (Target_x86_64::do_finalize_sections): Likewise.
		* powerpc.cc (Target_powerpc::do_finalize_sections): Likewise.
		(Target_powerpc::do_dynamic_tag_custom_value): New function.

2023-06-23  Alan Modra  <amodra@gmail.com>

	[GOLD] powerpc DT_RELACOUNT
	DT_RELACOUNT was calculated incorrectly, and relative relocs not
	sorted as they should be to the start of .rela.dyn, due to adding one
	particular class of dynamic reloc using the wrong "add" method.

		* powerpc.cc (Target_powerpc::Scan::global): Add relative
		dyn relocs for ADDR64 and similar using add_global_relative.

2023-06-23  Alan Modra  <amodra@gmail.com>

	lto test fails with -fno-inline in CFLAGS
	Putting -fno-inline in CFLAGS results in these failures.
	FAIL: Build liblto-17b.so 1
	FAIL: PR ld/12365
	FAIL: PR ld/13183

		* ld-plugin/lto.exp: Add -finline to compiler flags in some tests.

2023-06-23  Tom Tromey  <tom@tromey.com>

	Fix off-by-one error
	Simon pointed out that commit a2bbca9fa5e ("Use std::vector<bool> for
	agent_expr::reg_mask") caused a regression in libstdc++ debug mode.
	This was due to an off-by-one error in a vector resize.  This patch
	fixes the problem.

2023-06-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-22  Ilya Leoshkevich  <iii@linux.ibm.com>

	gdb/testsuite: fix gdb.python/py-unwind.exp with python >= 3.11
	Python 3.11 changed the AttributeError message - see commit
	0cb765b2cec9 ("bpo-46730: Add more info to @property AttributeError
	messages (GH-31311)").  Add the new message to the expectations.

	Approved-By: Tom Tromey <tom@tromey.com>
	Link: https://sourceware.org/pipermail/gdb-patches/2023-June/200433.html

2023-06-22  H.J. Lu  <hjl.tools@gmail.com>

	Revert "x86: Don't check if AVX512 template requires AVX512VL"
	This reverts commit c7face14225296a2f5d3ebeb8ace88c166d80c3e.

2023-06-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean or check standard_output_file dir in gdb_init
	In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
	gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
	files at the start of the test-case:
	...
	remote_file host delete [standard_output_file prog.o]
	remote_file host delete [standard_output_file prog.ali]
	...

	Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in
	gdb_init") I tried to do this more structurally, by cleaning up the entire
	standard_output_file directory, for all test-cases.

	This caused a regression when using "make check -j 2", due to the cleanup
	removing the active gdb.log, so I reverted the commit.

	Try again, this time handling the two cases separately.

	If the standard_output_file directory contains an active gdb.log, check that
	the directory contains no files other than gdb.log and gdb.sum.  This puts
	the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in
	which use --outdir.

	If the standard_output_file directory doesn't contain an active gdb.log, clean
	it by removing the entire directory.

	An exception is made for performance tests, where cleaning up the
	standard_output_file dir is the wrong thing to do, because an invocation with
	GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an
	earlier invocation with GDB_PERFTEST_MODE == compile.

	Tested on x86_64-linux.

	Suggested-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Tested-By: Luis Machado <luis.machado@arm.com>

2023-06-22  Tom Tromey  <tromey@adacore.com>

	Implement DAP "hover" context
	A DAP client can request that an expression be evaluated in "hover"
	context, meaning that it should not cause side effects.  In gdb, this
	can be implemented by temporarily setting a few "may-" parameters to
	"off".

	In order to make this work, I had to also change "may-write-registers"
	so that it can be changed while the program is running.  I don't think
	there was any reason for this prohibition in the first place.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30476

2023-06-22  Tom Tromey  <tromey@adacore.com>

	Implement DAP logging breakpoints
	DAP allows a source breakpoint to specify a log message.  When this is
	done, the breakpoint acts more like gdb's dprintf: it logs a message
	but does not cause a stop.

	I looked into implement this using dprintf with the new %V printf
	format.  However, my initial attempt at this did not work, because
	when the inferior is continued, the dprintf output is captured by the
	gdb.execute call.  Maybe this could be fixed by having all
	inferior-continuation commands use the "&" form; the main benefit of
	this would be that expressions are only parsed a single time.

2023-06-22  Tom Tromey  <tromey@adacore.com>

	Handle supportsVariablePaging in DAP
	A bug report about the supportsVariablePaging capability in DAP
	resulted in a clarification: when this capability is not present, DAP
	implementations should ignore the paging parameters to the "variables"
	request.  This patch implements this clarification.

	Implement type checking for DAP breakpoint requests
	I realized that with a small refactoring, it is possible to type-check
	the parameters to the various DAP breakpoint requests.  This would
	have caught the earlier bug involving hitCondition.

	Handle exceptions when creating DAP breakpoints
	When creating a DAP breakpoint, a failure should be returned by
	setting "verified" to False.  gdb didn't properly implement this, and
	there was a FIXME comment to this effect.  This patch fixes the
	problem.

	Reuse breakpoints more frequently in DAP
	The DAP breakpoint code tries to reuse a breakpoint when possible.
	Currently it uses the condition and the hit condition (aka ignore
	count) when making this determination.  However, these attributes are
	just going to be reset anyway, so this patch changes the code to
	exclude these from the reuse decision.

	Fix type of DAP hitCondition
	DAP specifies a breakpoint's hitCondition as a string, meaning it is
	an expression to be evaluated.  However, gdb implemented this as if it
	were an integer instead.  This patch fixes this oversight.

2023-06-22  Simon Farre  <simon.farre.cx@gmail.com>

	gdb/DAP Few bug fixes & Evaluate Array Watch vars
	v2.

	EvaluateResult does not need a name, just as what Tom pointed out in
	previous review. It's only the *children* that need to be made sure that
	their names are valid. An identifier for a variable, can't ever have an
	integer as a name, anyhow (not as far as I am aware, no programming
	languages allow for that).

	Removed the f-strings and use str() instead as pointed out that
	f-strings might not be supported fully.

	v1.

	This patch fixes a few bugs.

	First of all, name of VariableReferences must always be of string type.
	This patch makes sure that this is the case by formatting the name. If
	(when) the name is an integer, this will cause clients to fail or throw
	errors.

	Fixes a bug in NoOpArrayPrinter that calculated children to be N, but
	only ever retrieves N-1 children, which makes Python at some time later
	(during fetch_children -> fetch_one_child(N) ) raise an exception (out
	of list index) which makes the entire request go bad.

	The result[self.result_name] also f-strings the printer.to_string()
	value, because this can potentially be a LazyString (which is a Python
	object, not a string) and is not serializable by json.dumps.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-06-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-21  H.J. Lu  <hjl.tools@gmail.com>

	x86: Free the symbol buffer and the relocation buffer after use
	When --no-keep-memory is used, the symbol buffer and the relocation
	buffer aren't cached.  When packing relative relocations, we may
	allocate a new symbol buffer and a new relocation buffer for each
	eligible section in an object file.  If there are many sections,
	memory may be exhausted.  In this case, we should free the symbol
	buffer and the relocation buffer after use.  If symbol buffer entries
	are used to track relative relocations against local symbols for later
	use, the symbol buffer should be cached.

		PR ld/30566
		* elfxx-x86.c (elf_x86_relative_reloc_record_add): Add an
		argument to inform caller if the symbol buffer should be kept.
		(_bfd_x86_elf_link_relax_section): Call
		_bfd_elf_link_info_read_relocs instead of
		_bfd_elf_link_read_relocs.  Free the symbol buffer and the
		relocation buffer after use.  Cache the symbol buffer if it
		is used.

2023-06-21  Tom Tromey  <tromey@adacore.com>

	Add missing backslash to update-gnulib.sh
	A user on irc noticed a missing backslash on one line in
	update-gnulib.sh.  This patch adds it.

	Re-running update-gnulib.sh causes a few copyright notices to change.
	Presumably these are from upstream gnulib and shouldn't be touched by
	our yearly update.  I've updated the script to account for this, but I
	did not want to try testing it...

2023-06-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add have_host_locale
	With test-case gdb.tui/pr30056.exp, I run into:
	...
	sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M
	...
	and then subsequently into:
	...
	WARNING: timeout in accept_gdb_output
	FAIL: gdb.tui/pr30056.exp: Control-C
	...

	This is on a CentOS 7 distro for powerpc64le.

	Either it has no C.UTF-8 support, or it's not installed:
	...
	$ locale -a | grep ^C
	C
	$
	...

	Fix this by:
	- adding a new proc have_host_locale, and
	- using it in all test-cases using setenv LC_ALL.

	Tested on powerpc64le-linux and x86_64-linux.

2023-06-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/wrap-line.exp
	PR testsuite/30458 reports the following FAIL:
	...
	PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap
	^CQuit
	(gdb) WARNING: timeout in accept_gdb_output
	Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3):
	    0 Quit
	    1 (gdb) 7890123456789012345678901234567890123456789
	    2 W^CQuit
	    3 (gdb)
	  ...
	FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap
	...

	The problem is that the regexp doesn't account for the ^C:
	...
	    gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
	...

	The ^C occurs occasionally.  This is something we'd like to fix.  It's
	reported as a readline problem here (
	https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html ).

	For now, fix this by updating the regexp, and likewise in another place in the
	test-case where we use ^C.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458

2023-06-21  Alan Modra  <amodra@gmail.com>

	PR30536, ppc64el gold linker produces unusable clang-16 binary
	In commit 0961e631575b, the fix for PR30217, make_lplt_section and
	make_brlt_section were changed to use rela_dyn_ rather than their own
	separate dynamic reloc sections.  This fails miserably whenever brlt_
	is needed for long branches, due to needing to iterate sizing and thus
	reset brlt_ sizes.

		PR 30536
		PR 30217
		* powerpc.cc (Target_powerpc::make_brlt_section): Don't use
		rela_dyn_.

2023-06-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Reimplement Term::command_no_prompt_prefix
	Say we run test-case gdb.tui/basic.exp.  It calls Term::enter_tui, which does:
	...
		command_no_prompt_prefix "tui enable"
	...

	The proc command_no_prompt_prefix is documented as:
	...
	    # As proc command, but don't wait for an initial prompt.  This is used for
	    # initial terminal commands, where there's no prompt yet.
	...

	Indeed, before the "tui enable" command, the tuiterm is empty, so there is no
	prompt and just before switching to TUI we have in the tuiterm:
	...
	tui enable
	...

	The reason that there is no prompt, is that:
	- in order for tuiterm to show something, its input processing procs need to
	  be called, and
	- the initial gdb prompt, and subsequent prompts generated by gdb_test-style
	  procs, are all consumed by those procs instead.

	This is in principle not a problem, but the absence of a prompt makes a
	tuiterm session look less like a session on an actual xterm.

	Add a new proc gen_prompt, that:
	- generates a prompt using echo
	- consumes the response before the prompt using gdb_expect
	- consumes the prompt using Term::wait_for "".

	This allows us to reimplement Term::command_no_prompt_prefix using
	Term::command, and just before switching to TUI we have in the tuiterm:
	...
	(gdb) tui enable
	...

	Tested on x86_64-linux.

2023-06-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make Term::wait_for "" match only a prompt
	The semantics of Term::wait_for is:
	...
	    # Accept some output from gdb and update the screen.  WAIT_FOR is
	    # a regexp matching the line to wait for.  Return 0 on timeout, 1
	    # on success.
	    proc wait_for {wait_for} {
	...

	Note that besides the regexp, also a subsequent gdb prompt is matched.

	I recently used wait_for "" in a few test-cases, thinking that this would
	match just a prompt, but in fact that's not the case.

	Fix this in wait_for, and add a corresponding test in gdb.tui/tuiterm-2.exp.

	Tested on x86_64-linux.

2023-06-21  Nick Clifton  <nickc@redhat.com>

	Prune linker warnings about an executable stack being created with the -z execstack option.
	  * testsuite/lib/binutils-common.exp (prune_warnings_extra): Prune warnings about -z execstack creating an executable stack.

	For test for PR 29072 when the linker is configured with --enable-default-execstack=no.
	  PR 29072
	  * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Always return false for linkers configured with the --enable-default-execstack=no option.

2023-06-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdbserver: use target_waitstatus::to_string in 'prepare_resume_reply'
	Use the to_string method of target_waitstatus in
	'prepare_resume_reply' for a more readable log message.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-06-21  Jan Beulich  <jbeulich@suse.com>

	x86: fix expansion of %XV
	Only %LV should continue on to S handling; avoid emitting a stray 'l'
	(typically) in suffix-always mode.

2023-06-21  Alan Modra  <amodra@gmail.com>

	elf32_arm_get_synthetic_symtab memory leak
	ARM get_synthetic_symtab reads .plt and caches that data.  Caching the
	data doesn't make a lot of sense since get_synthetic_symtab is only
	called once per bfd, and the memory might be put to better use.  It
	also leaks on closing the bfd.

		* elf32-arm.c (elf32_arm_get_synthetic_symtab): Don't cache
		plt contents.  Free plt data before returning.

2023-06-21  Alan Modra  <amodra@gmail.com>

	macho-o.c don't leak strtab
		* mach-o.c (bfd_mach_o_write_symtab_content): Free strtab on
		success path.

2023-06-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use ARRAY_SIZE in ax-general.c
	This changes a couple of spots in ax-general.c to use ARRAY_SIZE.
	While making this change, I noticed that one of the bounds checks was
	incorrect.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Remove aop_last
	aop_last is only used for an assertion.  However, due to the '.def'
	construct in the sources, this assert could never plausibly trigger
	(the assert predates the use of a .def file here).  This patch removes
	the constant and the assert.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Make aop_map 'static'
	This changes aop_map to be 'static'.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use bool for agent_expr::tracing
	This changese agent_expr::tracing to have type bool, allowing inline
	initialization and cleaning up the code a little.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Simplify agent_expr constructor
	This simplifies the agent_expr constructor a bit, and removes the
	destructor entirely.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use std::vector<bool> for agent_expr::reg_mask
	agent_expr::reg_mask implements its own packed boolean vector.  This
	patch replaces it with a std::vector<bool>, simplifying the code.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use gdb::byte_vector in agent_expr
	This changes agent_expr to use gdb::byte_vector rather than manually
	reimplementing a vector.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Remove mem2hex
	tracepoint.c has a 'mem2hex' function that is functionally equivalent
	to bin2hex.  This patch removes the redundancy.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  H.J. Lu  <hjl.tools@gmail.com>

	x86: Don't check if AVX512 template requires AVX512VL
	If the ZMM operand in an AVX12 template also allows XMM or ZMM, this
	template must require AVX512VL.  Drop the AVX512VL requirement check
	on such AVX512 templates.

		* config/tc-i386.c (check_VecOperands): Don't check if AVX512
		template requires AVX512VL.

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use std::string in do_set_command
	do_set_command manually updates a string, only to copy it to a
	std::string and free the working copy.  This patch changes this code
	to use std::string for everything, simplifying the code and removing a
	copy.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use byte_vector in remote.c:readahead_cache
	This patch changes the remote.c readahead_cache to use
	gdb::byte_vector.  This simplifies the code by removing manual memory
	management.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tom@tromey.com>

	Use std::string in linux-osdata.c
	I found some code in linux-osdata that manually managed a string.
	Replacing this with std::string simplifies it.

	Reviewed-by: John Baldwin <jhb@FreeBSD.org>

2023-06-20  Tom Tromey  <tromey@adacore.com>

	Use unique_xmalloc_ptr for mi_parse::command
	This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up
	all the uses.  This avoids some manual memory management.  std::string
	is not used here due to how the Python API works -- this approach
	avoids an extra copy there.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-06-20  Tom Tromey  <tromey@adacore.com>

	Use std::string for MI token
	This changes the MI "token" to be a std::string, removing some manual
	memory management.  It also makes current_token 'const' in order to
	support this change.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-06-20  Alan Modra  <amodra@gmail.com>

	Don't segfault in mips reloc special_functions
	A symbol defined in a section from a shared library will have a NULL
	section->output_section during linking.

		* elf32-mips.c (gprel32_with_gp): Don't segfault on NULL
		symbol->section->output_section.
		* elf64-mips.c (mips_elf64_gprel32_reloc): Likewise.
		* elfn32-mips.c (mips_elf_gprel16_reloc): Likewise.
		(mips_elf_literal_reloc, mips_elf_gprel32_reloc): Likewise.
		(gprel32_with_gp, mips16_gprel_reloc): Likewise.
		* elfxx-mips.c (_bfd_mips_elf_gprel16_with_gp): Likewise.
		(_bfd_mips_elf_generic_reloc): Likewise.

2023-06-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-19  Tom de Vries  <tdevries@suse.de>

	Revert "[gdb/testsuite] Clean standard_output_file dir in gdb_init"
	This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.

2023-06-19  Simon Farre  <simon.farre.cx@gmail.com>

	Fixes 28ab59607ef40b9571c0702ffba8f6aa6fb1b033
	Python formatting errors fixed, introduced by this commit.

	Fixes f1a614dc8f015743e9fe7fe5f3f019303f8db718
	Fixes failure reported by buildbot regarding ill-formatted Python code.

2023-06-19  Simon Farre  <simon.farre.cx@gmail.com>

	gdb/Python: Added ThreadExitedEvent
	v6:
	Fix comments.
	Fix copyright
	Remove unnecessary test suite stuff. save_var had to stay, as it mutates
	some test suite state that otherwise fails.

	v5:
	Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/

	v4:
	Doc formatting fixed.

	v3:
	Eli:
	Updated docs & NEWS to reflect new changes. Added
	a reference from the .ptid attribute of the ThreadExitedEvent
	to the ptid attribute of InferiorThread. To do this,
	I've added an anchor to that attribute.

	Tom:
	Tom requested that I should probably just emit the thread object;
	I ran into two issues for this, which I could not resolve in this patch;

	1 - The Thread Object (the python type) checks it's own validity
	by doing a comparison of it's `thread_info* thread` to nullptr. This
	means that any access of it's attributes may (probably, since we are
	in "async" land) throw Python exceptions because the thread has been
	removed from the thread object. Therefore I've decided in v3 of this
	patch to just emit most of the same fields that gdb.InferiorThread has, namely
	global_num, name, num and ptid (the 3-attribute tuple provided by
	gdb.InferiorThread.ptid).

	2 - A python user can hold a global reference to an exiting thread. Thus
	in order to have a ThreadExit event that can provide attribute access
	reliably (both as a global reference, but also inside the thread exit
	handler, as we can never guarantee that it's executed _before_ the
	thread_info pointer is removed from the gdbpy thread object),
	the `thread_info *` thread pointer must not be null. However, this
	comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
	that if a user holds takes a global reference to that
	exiting event thread object, they can some time later do `t.switch()` at which
	point GDB will 'explode' so to speak.

	v2:
	Fixed white space issues and NULL/nullptr stuff,
	as requested by Tom Tromey.

	v1:
	Currently no event is emitted for a thread exit.

	This adds this functionality by emitting a new gdb.ThreadExitedEvent.

	It currently provides four attributes:
	- global_num: The GDB assigned global thread number
	- num: the per-inferior thread number
	- name: name of the thread or none if not set
	- ptid: the PTID of the thread, a 3-attribute tuple, identical to
	InferiorThread.ptid attribute

	Added info to docs & the NEWS file as well.

	Added test to test suite.

	Fixed formatting.

	Feedback wanted and appreciated.

2023-06-19  Simon Farre  <simon.farre.cx@gmail.com>

	gdb/dap - Getting thread names
	Renamed thread_name according to convention (_ first)

	When testing firefox tests, it is apparent that
	_get_threads returns threads with name field = None.

	I had initially thought that this was due to Firefox setting the names
	using /proc/pid/task/tid/comm, by writing directly to the proc fs the
	names, but apparently GDB seems to catch this, because I re-wrote
	the basic-dap.exp/c to do this specifically and it saw the changes.

	So I couldn't determine right now, what operation of name change that
	GDB does not pick up, but with this patch, GDB will pick up the thread
	names for an applications that set the name of a thread in ways that
	aren't obvious.

2023-06-19  Nick Clifton  <nickc@redhat.com>

	Fix illegal memory access implementing relocs in a fuzzed x86_64 object file.
	  PR 30560
	  * elf64-x86-64.c (elf_x86_64_relocate_section): Add more checks for a valid relocation offset.

2023-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add shared_gnat_runtime_has_debug_info
	Test-case gdb.ada/catch_ex_std.exp passes for me with package
	libada7-debuginfo installed, but after removing it I get:
	...
	(gdb) catch exception some_kind_of_error^M
	Your Ada runtime appears to be missing some debugging information.^M
	Cannot insert Ada exception catchpoint in this configuration.^M
	(gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error
	...

	The test-case contains a require gnat_runtime_has_debug_info to deal with
	this, but the problem is that this checks the static gnat runtime, while this
	test-case uses the shared one.

	Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that
	one instead.

	Tested on x86_64-linux.

	PR testsuite/30094
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094

2023-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Simplify tui_update_variables
	Simplify tui_update_variables by using template function
	assign_return_if_changed.

	Tested on x86_64-linux.

2023-06-19  Tom de Vries  <tdevries@suse.de>

	[gdb] Add template functions assign_return/set_if_changed
	Add template functions assign_return_if_changed and assign_set_if_changed in
	gdb/utils.h:
	...
	template<typename T> void assign_set_if_changed (T &lval, const T &val, bool &changed)
	{ ... }
	template<typename T> bool assign_return_if_changed (T &lval, const T &val)
	{ ... }
	...

	This allows us to rewrite code like this:
	...
	  if (tui_border_attrs != entry->value)
	    {
	      tui_border_attrs = entry->value;
	      need_redraw = true;
	    }
	...
	into this:
	...
	  need_redraw |= assign_return_if_changed<int> (tui_border_attrs, entry->value);
	...
	or:
	...
	  assign_set_if_changed<int> (tui_border_attrs, entry->value, need_redraw);
	...

	The names are a composition of the functionality.  The functions:
	- assign VAL to LVAL, and either
	- return true if the assignment changed LVAL, or
	- set CHANGED to true if the assignment changed LVAL.

	Tested on x86_64-linux.

2023-06-19  Andreas Schwab  <schwab@suse.de>

	riscv: Use run-time endianess for floating point literals
	gas/
		PR binutils/30551
		* config/tc-riscv.c (md_atof): Use target_big_endian instead of
		TARGET_BYTES_BIG_ENDIAN.
		* testsuite/gas/riscv/float-be.d: New file.
		* testsuite/gas/riscv/float-le.d: New file.
		* testsuite/gas/riscv/float.s: New file.

2023-06-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean standard_output_file dir in gdb_init
	In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
	gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
	files at the start of the test-case:
	...
	remote_file host delete [standard_output_file prog.o]
	remote_file host delete [standard_output_file prog.ali]
	...

	Replace this with cleaning up the entire directory instead, for all
	test-cases.

	Tested on x86_64-linux.

	Suggested-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove f-string in gdb.python/py-unwind.py
	on openSUSE Leap 42.3, with python 3.4, I run into a
	"SyntaxError: invalid syntax" due to usage of an f-string in test-case
	gdb.python/py-unwind.py.

	Fix this by using string concatenation using '+' instead.

	Tested on x86_64-linux.

2023-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add nopie in a few test-cases
	When running test-case gdb.arch/i386-disp-step.exp with target board
	unix/-m32/-fPIE/-pie we run into:
	...
	gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
	ld: warning: creating DT_TEXTREL in a PIE
	...

	Fix this by adding nopie in the compilation flags.

	Likewise in a few other test-cases.

	Tested on x86_64-linux.

2023-06-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use require in gdb.dwarf2/implptr.exp
	In test-case gdb.dwarf2/implptr.exp I noticed:
	...
	} elseif {![is_x86_like_target]} {
	    # This test can only be run on x86 targets.
	    unsupported "needs x86-like target"
	    return 0
	}
	...

	Use instead "require is_x86_like_target".

	Tested on x86_64-linux.

2023-06-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp
	Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
	fine, but if we run it again with target board unix-m32, we run into:
	...
	gnatlink prog.ali -m32 -g -o prog^M
	ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
	  i386 output^M
	...

	This is due to compiling with no-force.

	The test-case:
	- first compiles pck.adb into pck.o (without debug info), and
	- then compiles prog.adb and pck.o into prog (with debug info).

	Using no-force in the second compilation make sure that pck.adb is not
	compiled again, with debug info.

	But it also means it will pick up intermediate files related to prog.adb from
	a previous compilation.

	Fix this by removing prog.o and prog.ali before compilation.

	Tested on x86_64-linux.

2023-06-16  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use %progbits in gdb.arch/thumb*.S
	In commit 0f2cd53cf4f ("[gdb/testsuite] Handle missing .note.GNU-stack") I
	updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits,
	but failed to do so for gdb.arch/thumb*.S.  Fix this oversight.

	Tested on arm-linux-gnueabihf.

2023-06-16  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix ld "undefined reference" error with --enable-shared
	  Because _bfd_read_unsigned_leb128 is hidden visibility, so it can't
	  be referenced out of shared object.

	  The new function loongarch_get_uleb128_length just used to call
	  _bfd_read_unsigned_leb128.

	bfd/ChangeLog:

		* elfxx-loongarch.c (loongarch_get_uleb128_length): New function.
		* elfxx-loongarch.h (loongarch_get_uleb128_length): New function.

	gas/ChangeLog:

		* config/tc-loongarch.c (md_apply_fix): Use
		loongarch_get_uleb128_length.

2023-06-16  Andrew Burgess  <aburgess@redhat.com>

	gdb: update IRC reference from Freenode to Libera.Chat
	It's been some time since the switch from Freenode to Libera.Chat,
	however, there's still a reference to Freenode in the 'gdb --help'
	output.  Lets update that.

2023-06-16  Jan Beulich  <jbeulich@suse.com>

	x86: shrink Masking insn attribute to a single bit (boolean)
	The logic can actually be expressed with less code that way, utilizing
	that there are common patterns of when which form of masking is
	permitted. This then also eliminates the large set of open-codings of
	BOTH_MASKING in the opcode table.

2023-06-16  Alan Modra  <amodra@gmail.com>

	Correct ld-elf/eh5 test for hppa64
	Commit 3c0afdb78988 regressed this test for hppa64, because the test
	had been enabled for hppa64 in the time between the mips changes and
	their reversion.  This patch isn't just a simple reapply, I recreated
	the testsuite change by hand for hppa64: Two lines in eh5.d might need
	further changes for mips.

2023-06-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	binutils/NEWS: Mention Sony Allegrex MIPS CPU support
	Mention the addition of Sony Allegrex processor support to the MIPS port.

		binutils/
		* NEWS: Mention Sony Allegrex MIPS CPU support.

2023-06-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	MIPS/GAS/testsuite: Fix `-modd-spreg'/`-mno-odd-spreg' test invocations
	Reformat `-modd-spreg'/`-mno-odd-spreg' test invocations in mips.exp to
	fit in 79 columns

		gas/
		* testsuite/gas/mips/mips.exp: Reformat
		`-modd-spreg'/`-mno-odd-spreg' test invocations.

2023-06-15  David Guillen Fandos  <david@davidgf.net>

	Add additional missing Allegrex CPU instructions
	Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with
	some encoding differences) such as bit manipulation (ins/ext) and MLA
	(madd/msub).  It also features some new instructions like wsbw and
	min/max or device-specific ones such as mfic.

	Add rotation instructions to MIPS Allegrex CPU
	The Allegrex CPU supports bit rotation instructions as described in the
	MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU).

	Add MIPS Allegrex CPU as a MIPS2-based CPU
	The Allegrex CPU was created by Sony Interactive Entertainment to power
	their portable console, the PlayStation Portable.
	The pspdev organization maintains all sorts of tools to create software
	for said device including documentation.

2023-06-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	GAS/doc: Correct Tag_GNU_MIPS_ABI_MSA attribute description
	Rewrite the paragraph to match the style of Tag_GNU_MIPS_ABI_FP text
	immediately above, correcting grammar and formatting at the same time.

		gas/
		* doc/as.texi (MIPS Attributes): Correct Tag_GNU_MIPS_ABI_MSA
		attribute description.

2023-06-15  Maciej W. Rozycki  <macro@orcam.me.uk>

	Revert "MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit"
	This reverts commit 094025a30bb2da19df3990e0c0ff8167af823aa1.  It was
	applied unapproved.

	Revert "MIPS: default r6 if vendor is img"
	This reverts commit be0d391f22fe6009c3be907753975a984cbbcc23.  It was
	applied unapproved.

	Revert "MIPS: fix r6 testsuites"
	This reverts commit ffc528aed56b9e2c171137da28690a9bb6861b0b.  It was
	applied unapproved.

	Revert "MIPS: fix -gnuabi64 testsuite"
	This reverts commit cb81e84c72933a7fad10b75b7e270d92d8d65251.  It was
	applied unapproved.

	Revert "MIPS: fix some ld testcases with compiler"
	This reverts commit a0631c1501c113c04891c9a24a9ff5276257f28d.  It was
	applied unapproved.

	Revert "MIPS: add MT ASE support for micromips32"
	This reverts commit acce83dacff0ce43677410c67aaae32817afe991.  It was
	applied unapproved.

	Revert "MIPS: sync oprand char usage between mips and micromips"
	This reverts commit 5b207b919483f67311a73dfc1de8897ecfd8e776.  It was
	applied unapproved.

2023-06-15  Alan Modra  <amodra@gmail.com>

	Re: Add some expected failures for bfin linker tests
	After commit 7ade0f1582c4 I was seeing bfin-elf +XPASS: weak symbols,
	and on looking into the bfin targets a little, discovered we have two
	bfin-linux targets.  One, bfin-uclinux, is like bfin-elf in that
	ld -m elf32bfin is the default, and the other, bfin-linux-uclibc where
	ld -m elf32bfinfd is the default.  So putting bfin-*-*linux* in test
	xfails or elsewhere is wrong.  We want bfin-*-linux* instead to just
	select the fdpic bfin target.

	This patch corrects wrong bfin target triples in the ld testsuite,
	not just the recent change but others I'd added to xfails too.
	It also fixes the bfin-linux-uclibc ld-elf/64ksec fail

2023-06-15  Alan Modra  <amodra@gmail.com>

	vms write_archive memory leaks
	This fixes two memory leaks in the vms archive handling.

		* vms-lib.c (_bfd_vms_lib_build_map): Free input symbols.
		(_bfd_vms_lib_write_archive_contents): Free archive map symbols.

2023-06-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/step-over-exit.exp with glibc debuginfo
	In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
	continue, expecting to hit the breakpoint.

	Without glibc debug info installed, we have with target board unix/-m64:
	...
	Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
	  _exit () from /lib64/libc.so.6^M
	(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
	...
	and with target board unix/-m32:
	...
	Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
	  /lib/libc.so.6^M
	(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
	...

	However after installing debug info (packages glibc-debuginfo and
	glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
	...
	Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
	  __GI__exit (status=<optimized out>) at \
	  ../sysdeps/unix/sysv/linux/_exit.c:27^M
	27      {^M
	(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
	...
	and -m32 (note: _Exit instead of _exit):
	...
	Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
	  ../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
	24      ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
	(gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
	...

	The gdb_test allows for both _exit and __GI__exit, but not _Exit:
	...
	gdb_test "continue" \
	    "Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
	    "continue to exit"
	...

	Fix this by allowing _Exit as well.

	Tested on x86_64-linux.

2023-06-14  Nick Clifton  <nickc@redhat.com>

	Add some expected failures for bfin linker tests

	Add --remap-inputs option to the BFD linker.
	  PR 30374
	  * ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions.
	  * ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps.
	  * ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define.
	  * lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options.
	  * NEWS: Mention the new feature.
	  * ld.texi: Document the new options.
	  * testsuite/ld-misc/input-remap.exp: New test driver.
	  * testsuite/ld-misc/remaps.r: New file: Expected linker output.
	  * testsuite/ld-misc/remaps.txt: New file.  Input remaps file.

2023-06-14  Alan Modra  <amodra@gmail.com>

	asprintf memory leaks
	A number of backends want to return bfd_reloc_dangerous messaqes from
	relocation special_function, and construct the message using asprintf.
	Such messages are not freed anywhere, leading to small memory leaks
	inside libbfd.  To limit the leaks, I'd implemented a static buffer in
	the ppc backends that was freed before use in asprintf output.  This
	patch extends that scheme to other backends using a shared static
	buffer and goes further in freeing the buffer on any bfd_close.

	The patch also fixes a few other cases where asprintf output was not
	freed after use.

	bfd/
		* bfd.c (_input_error_msg): Make global and rename to..
		(_bfd_error_buf): ..this.
		(bfd_asprintf): New function.
		(bfd_errmsg): Use bfd_asprintf.
		* opncls.c (bfd_close_all_done): Free _buf_error_buf.
		* elf32-arm.c (find_thumb_glue, find_arm_glue): Use bfd_asprintf.
		* elf32-nios2.c (nios2_elf32_relocate_section): Likewise.
		* elf32-ppc.c (ppc_elf_unhandled_reloc): Likewise.
		* elf64-ppc.c (ppc64_elf_unhandled_reloc): Likewise.
		* elfnn-riscv.c (riscv_resolve_pcrel_lo_relocs): Likewise.
		(riscv_elf_relocate_section): Likewise.
		* libbfd.h: Regenerate.
	gas/
		* read.c (read_end): Free current_name and current_label.
		(do_s_func): Likewise on error path.  strdup label.
	ld/
		* pe-dll.c (make_head, make_tail, make_one),
		(make_singleton_name_thunk, make_import_fixup_entry),
		(make_runtime_pseudo_reloc),
		(pe_create_runtime_relocator_reference: Free oname after use.

2023-06-14  Alan Modra  <amodra@gmail.com>

	Re: bfd/elf.c strtab memory leak
	There are other places that leak the strtab.

		* elf.c (_bfd_elf_compute_section_file_positions): Free strtab
		on error paths.

2023-06-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/long-prompt.exp with read1
	When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
	...
	(gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
	  end of screen: at last line
	...

	The problem is in these commands:
	...
	    Term::command "echo \\n"
	    Term::command "echo \\n"
	    Term::command "echo \\n"
	    Term::command "echo \\n"
	...

	The last one makes the terminal scroll, and the scrolling makes the expected
	output match on a different line.

	Fix this by replacing the sequence with a single command:
	...
	    Term::command "echo \\n\\n\\n\\n\\n\\n"
	...
	which avoids scrolling.

	Tested on x86_64-linux.

2023-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix and add prompt anchoring in tuiterm
	There is a test-case that contains a unit test for tuiterm:
	gdb.tui/tuiterm.exp.

	However, this only excercises the tuiterm itself, and not the functions that
	interact with it, like Term::command.

	Add a new test-case gdb.tui/tuiterm-2.exp that:
	- overrides proc accept_gdb_output (to be able simulate incorrect responses
	  while avoiding the timeout),
	- overrides proc send_gdb (to be able to call Term::command without a gdb
	  instance, such that all tuiterm input is generated by the test-case).
	- issues Term::command calls, and
	- checks whether they behave correctly.

	This exposes a problem in Term::command.  The "prompt before command" regexp
	starts with a bit that is supposed to anchor the prompt to the border:
	...
		set str "(^|\|)$gdb_prompt $str"
	...
	but that doesn't work due to insufficient escaping.  Fix this by adding the
	missing escape:
	...
		set str "(^|\\|)$gdb_prompt $str"
	...

	Futhermore, the "prompt after command" regexp in Term::wait_for has no
	anchoring at all:
	...
		set prompt_wait_for "$gdb_prompt \$"
	...
	so add that as well.

	Tested on x86_64-linux.

2023-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow procs with default value args in with_override
	Currently proc with_override does not work with procs with default value args.

	Fix this, and add a test-case excercising this scenario.

	Tested on x86_64-linux.

2023-06-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dap/type_check.exp with older python
	On openSUSE Leap 15.4 with system python 3.6, I run into:
	...
	(gdb) python check_everything()^M
	(gdb) FAIL: gdb.dap/type_check.exp: type checker
	...

	In check_everything, the hasattr test fails silently:
	...
	def check_everything():
	    # Older versions of Python can't really implement this.
	    if hasattr(typing, "get_origin"):
	...
	and that makes the gdb_test in the test-case fail.

	Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
	this in the test-case.

	Tested on x86_64-linux.

2023-06-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: use proper int size for gdb.dwarf2/symbol_needs_eval*.exp
	We recently realized that symbol_needs_eval_fail.exp and
	symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
	x86_64) by reading 8 bytes (the size of a pointer).

	Here how it goes:

	In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
	defined:

	    int exec_mask = 1;

	and later both tests build some DWARF using the assembler doing:

	    set exec_mask_var [gdb_target_symbol exec_mask]
	    ...
	        DW_TAG_variable {
	          {DW_AT_name a}
	          {DW_AT_type :$int_type_label}
	          {DW_AT_location {
	            DW_OP_addr $exec_mask_var
	            DW_OP_deref
	            ...
	          }
	        }

	The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
	says that "The size of the data retrieved from the dereferenced address
	is the size of an address on the target machine."

	On x86_64, the size of an int is 4 while the size of an address is 8.
	The result is that when evaluating this expression, the debugger reads
	outside of the `a` variable.

	Fix this by using `DW_OP_deref_size $int_size` instead.  To achieve
	this, this patch adds the necessary steps so we can figure out what
	`sizeof(int)` evaluates to for the current target.

	While at it, also change the definition of the int type in the assembled
	DWARF information so we use the actual target's size for an int instead
	of the literal 4.

	Tested on x86_64 Linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-06-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-13  Kevin Buettner  <kevinb@redhat.com>

	Simplify case DW_OP_GNU_uninit in dwarf_expr_context::execute_stack_op
	Tom Tromey pointed out that the test and call to error() for the
	DW_OP_GNU_uninit case in dwarf_expr_context::execute_stack_op (in
	gdb/dwarf2/expr.c)...

		  if (op_ptr != op_end && *op_ptr != DW_OP_piece
		      && *op_ptr != DW_OP_bit_piece)
		    error (_("DWARF-2 expression error: DW_OP_GNU_uninit must always "
			   "be the very last op in a DWARF expression or "
			   "DW_OP_piece/DW_OP_bit_piece piece."));

	...could be replaced by a call to dwarf_expr_require_composition which
	performs a similar check and outputs a suitable error message.

2023-06-12  Simon Farre  <simon.farre.cx@gmail.com>

	Added self to W.A.A. maintainers

2023-06-12  Richard Bunt  <richard.bunt@linaro.org>

	gdb/testsuite: Testing with the armflang compiler
	Currently the Fortran test suite does not run with armflang because the
	compiler detection fails. This in turn means fortran_runto_main does not
	know which main method to use to start a test case.

	Fortran compiler detection was added in 44d469c5f85; however, the commit
	message notes that it was not tested with armflang.

	This commit tests and fixes up a minor issue to get the detection
	working.

	The goal here is to get the tests running and preventing further
	regressions during future work. This change does not do anything to fix
	existing failures.

	>From what I can understand, the auto detection leverages the
	preprocessor to extract the Fortran compiler identity from the defines.
	This preprocessor output is then evaluated by the test suite to import
	these defines.

	In the case of armflang, this evaluation step is disrupted by the
	presence of the following warning:

	    $ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
	    $ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]

	The evaluation logic is already set up to filter this warning, but the
	prefix differs.

	This commit fixes the issue by updating the filter to exclude the
	armflang flavour of warning.

	gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
	regressions detected.

	The gdb.fortran test results with ACfL 23.04.1 are as follows.

	Before:

	 # of expected passes		560
	 # of unexpected failures	113
	 # of unresolved testcases	2
	 # of untested testcases	5
	 # of duplicate test names	2

	After:

	 # of expected passes		5388
	 # of unexpected failures	628
	 # of known failures		10
	 # of untested testcases	8
	 # of unsupported tests		5
	 # of duplicate test names	5

	As can be seen from the above, there are now considerably more passing
	assertions.

	Reviewed-By: Luis Machado <luis.machado@arm.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Remove f-strings from DAP
	Kévin pointed out that gdb claims a minimum Python version of 3.2, but
	the DAP code uses f-strings, which were added in 3.6.

	This patch removes the uses of f-strings from the DAP code.  I can't
	test an older version of Python, but I did confirm that this still
	works with the version I have.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Implement DAP conditional breakpoints
	I realized that I had only implemented DAP breakpoint conditions for
	exception breakpoints, and not other kinds of breakpoints.  This patch
	corrects the oversight.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Do not report totalFrames from DAP stackTrace request
	Currently, gdb will unwind the entire stack in response to the
	stackTrace request.  I had erroneously thought that the totalFrames
	attribute was required in the response.  However, the spec says:

	    If omitted or if `totalFrames` is larger than the available
	    frames, a client is expected to request frames until a request
	    returns less frames than requested (which indicates the end of the
	    stack).

	This patch removes this from the response in order to improve
	performance when the stack trace is very long.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Implement DAP breakpointLocations request
	This implements the DAP breakpointLocations request.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Add "stop at main" extension to DAP launch request
	Co-workers who work on a program that uses DAP asked for the ability
	to have gdb stop at the main subprogram when launching.  This patch
	implements this extension.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Add "target" parameter to DAP attach request
	This adds a new "target" to the DAP attach request.  This is passed to
	"target remote".  I thought "attach" made the most sense for this,
	because in some sense gdb is attaching to a running process.  It's
	worth noting that all DAP "attach" parameters are defined by the
	implementation.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Handle DAP supportsVariableType capability
	A DAP client can report the supportsVariableType capability in the
	initialize request.  In this case, gdb can include the type of a
	variable or expression in various results.

	Implement DAP setExpression request
	This implements the DAP setExpression request.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Add gdb.Value.assign method
	This adds an 'assign' method to gdb.Value.  This allows for assignment
	without requiring the use of parse_and_eval.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Add type-checking to DAP requests
	It occurred to me recently that gdb's DAP implementation should
	probably check the types of objects coming from the client.  This
	patch implements this idea by reusing Python's existing type
	annotations, and supplying a decorator that verifies these at runtime.

	Python doesn't make it very easy to do runtime type-checking, so the
	core of the checker is written by hand.  I haven't tried to make a
	fully generic runtime type checker.  Instead, this only checks the
	subset that is needed by DAP.  For example, only keyword-only
	functions are handled.

	Furthermore, in a few spots, it wasn't convenient to spell out the
	type that is accepted.  I've added a couple of comments to this effect
	in breakpoint.py.

	I've tried to make this code compatible with older versions of Python,
	but I've only been able to try it with 3.9 and 3.10.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Use tuples for default arguments in DAP
	My co-worker Kévin taught me that using a mutable object as a default
	argument in Python is somewhat dangerous, because the object is
	created a single time (when the function is defined), and so if it is
	mutated in the body of the function, the changes will stick around.

	This patch changes the cases like this in DAP to use () rather than []
	as the default.  This patch is merely preventative, as no bugs like
	this are in the code.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Fix a latent bug in DAP request decorator
	The 'request' decorator is intended to also ensure that the request
	function runs in the DAP thread.  However, the unwrapped function is
	installed in the global request map, so the wrapped version is never
	called.  This patch fixes the bug.

	Add test for DAP pause request
	I neglected to write a test for the DAP "pause" request.  This patch
	adds one.

	Rename one DAP function
	When I first started implementing DAP, I had some vague plan of having
	the implementation functions use the same name as the request.  I
	abandoned this idea, but one vestige remained.  This patch renames the
	one remaining function to be gdb-ish.

	Add singleThread support to some DAP requests
	A few DAP requests support a "singleThread" parameter, which is
	somewhat similar to scheduler-locking.  This patch implements support
	for this.

	Implement DAP stepOut request
	This implements the DAP "stepOut" request.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Implement DAP attach request
	This implements the DAP "attach" request.

	Note that the copyright dates on the new test source file are not
	incorrect -- this was copied verbatim from another directory.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Implement DAP setExceptionBreakpoints request
	This implements the DAP setExceptionBreakpoints request for Ada.  This
	is a somewhat minimal implementation, in that "exceptionOptions" are
	not implemented (or advertised) -- I wasn't completely sure how this
	feature is supposed to work.

	I haven't added C++ exception handling here, but it's easy to do if
	needed.

	This patch relies on the new MI command execution support to do its
	work.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Don't require inferior execution for Ada catchpoints
	Currently, Ada catchpoints require that the inferior be running.
	However, there's no deep reason for this -- for example, C++ exception
	catchpoints do not have this requirement.  Instead, those work like
	ordinary breakpoints: they are pending until the needed runtime
	locations are seen.

	This patch changes Ada catchpoints to work the same way.

2023-06-12  Tom Tromey  <tromey@adacore.com>

	Mark members of ada_catchpoint "private"
	This changes the members of ada_catchpoint to be private.

	Turn should_stop_exception into a method of ada_catchpoint
	This turns the should_stop_exception function in ada-lang.c into a
	method of ada_catchpoint.

	Combine create_excep_cond_exprs and ada_catchpoint::re_set
	This patch merges create_excep_cond_exprs into ada_catchpoint::re_set.
	This is less verbose and is also a step toward making ada_catchpoint
	work more like the other code_breakpoint-based exception catchpoints.

	Transfer ownership of exception string to ada_catchpoint
	This changes the ada_catchpoint to require an rvalue ref, so that
	ownership of the exception string can be transferred to the catchpoint
	object.

	Pass tempflag to ada_catchpoint constructor
	This is a minor cleanup to pass tempflag to the ada_catchpoint
	constructor.

	Use gnat_runtime_has_debug_info in Ada catchpoint tests
	This changes the Ada catchpoint tests to use
	gnat_runtime_has_debug_info.  This simplifies the code.

	Stop gdb in gnat_runtime_has_debug_info
	gnat_runtime_has_debug_info starts a new gdb to do its work.  However,
	it also leaves this gdb running, which can potentially confuse the
	calling test -- I encountered this when writing a new DAP test.  This
	patch changes the proc to shut down gdb.

2023-06-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Relax breakpoint count check in gdb.python/py-rbreak.exp
	With a gdb 13.2 based package on SLE-15 aarch64,  I run into:
	...
	(gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary
	py sl = gdb.rbreak("^[^_]",minsyms=False)^M
	Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M
	  ...
	(gdb) py print(len(sl))^M
	12^M
	(gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
	...

	The FAIL is due to:
	- the glibc object crti.o containing debug information for function
	  call_weak_fn, and
	- the test-case not expecting this.

	The debug information is there due to compiling glibc using a binutils which
	contains commit 591cc9fbbfd ("gas/Dwarf: record functions").

	I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite]
	Fix regexp in py-rbreak.exp").

	The fix I applied there was to use a regexp "^[^_]" to filter out
	__libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn.

	Fix this by:
	- reverting the regexp to "", and
	- rewriting the check to require at least 11 functions, rather than a precise
	  match.

	Tested on x86_64-linux.

	PR testsuite/30538
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30538

2023-06-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix breakpoint regexp in gdb.ada/out_of_line_in_inlined.exp
	With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
	...
	(gdb) run ^M
	Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
	[Thread debugging using libthread_db enabled]^M
	Using host libthread_db library "/lib/libthread_db.so.1".^M
	^M
	Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
	26                  for C of S loop^M
	(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
	  run to foo_o224_021.child1.child2
	...

	I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
	instead of optimize=-O2.

	Fix this by using $bkptno_num_re.

	Tested on x86_64-linux.

	PR testsuite/30539
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539

2023-06-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Replace macro HELP_ATTRIBUTE_MODE with std::string
	Replace macro HELP_ATTRIBUTE_MODE with a std::string.

	Tested on x86_64-linux.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-12  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Relocations simplification when -mno-relax
	  Gas does not emit ADD/SUB relocation pairs for label differences
	  when -mno-relax.

2023-06-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-11  Kevin Buettner  <kevinb@redhat.com>

	Permit DW_OP_GNU_uninit to be used with DW_OP_piece
	This commit implements a fix for a bug reported against GDB on
	Fedora bugzilla...

	https://bugzilla.redhat.com/show_bug.cgi?id=2166796

	The test case in that bug report involved running gdb against the 'jq'
	program (which is a command-line JSON processor) on Fedora 37.  Since
	the debug info is compiler (and compile-time option) dependent, it
	won't necessarily show up in other distributions or even past or
	future versions of Fedora.  (E.g. when trying the example shown below
	on Fedora 38, GDB says that the value of 'value' has been optimized
	out.  I.e. it does not demonstrate the same DWARF error that can be
	see when using Fedora 37.)

	That said, on Fedora 37, the bug could be reproduced as follows:

	[kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null'
	Reading symbols from jq...

	This GDB supports auto-downloading debuginfo from the following URLs:
	  <https://debuginfod.fedoraproject.org/>
	Enable debuginfod for this session? (y or [n]) y
	Debuginfod has been enabled.
	To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
	Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
	No source file named src/util.c.
	Make breakpoint pending on future shared library load? (y or [n]) y
	Breakpoint 1 (src/util.c:415) pending.
	Starting program: /usr/bin/jq </dev/null
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib64/libthread_db.so.1".

	Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
	416	    if (state->parser == NULL) {
	(gdb) p value
	DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.

	This is undesirable - rather than output an error about the DWARF
	info, we'd prefer to see a value, even if it is uninitialized.

	Examination of the debuginfo showed the following:

	 <1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
	    <468f2>   DW_AT_external    : 1
	    <468f2>   DW_AT_name        : (indirect string, offset: 0x4781): jq_util_input_next_input
	    <468f6>   DW_AT_decl_file   : 10
	    <468f6>   DW_AT_decl_line   : 411
	    <468f8>   DW_AT_decl_column : 4
	    <468f9>   DW_AT_prototyped  : 1
	    <468f9>   DW_AT_type        : <0x3f2>
	    <468fd>   DW_AT_sibling     : <0x4692e>
	...
	 <2><46921>: Abbrev Number: 102 (DW_TAG_variable)
	    <46922>   DW_AT_name        : (indirect string, offset: 0x8cb): value
	    <46926>   DW_AT_decl_file   : 10
	    <46926>   DW_AT_decl_line   : 414
	    <46928>   DW_AT_decl_column : 6
	    <46929>   DW_AT_type        : <0x3f2>

	Note that there's no DW_AT_location, so I looked for an abstract origin entry:

	 <2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
	    <2dfa1>   DW_AT_abstract_origin: <0x46921>
	    <2dfa5>   DW_AT_location    : 0x27cf1 (location list)
	    <2dfa9>   DW_AT_GNU_locviews: 0x27ce1

	(Note that the DW_AT_abstract_origin attribute's value is 0x46921 which
	is the DIE for the local variable "value".)

	Looking at the location list, I see:

	    00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
	             000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)

	While DW_OP_GNU_uninit is not the very last op, it is the last op
	prior to DW_OP_piece.  The fix involved changing the DW_OP_GNU_uninit
	case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
	that DW_OP_GNU_uninit may appear just before DW_OP_piece.

	With the fix in place, attempting to print 'value' now looks like
	this:

	(gdb) p value
	$1 =  [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
	  size = 0, u = {ptr = 0x0, number = 0}}

	Note that "[uninitialized]" is part of the output.  (But also note
	that there's an extra space character.)

	I've made a new test case,
	gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
	existing one, gdb.dwarf2/opt-out-not-implptr.exp.  Since it uses the
	DWARF assembler, the test case does not depend on a specific compiler
	version or compiler options.

	Tested on Fedora 37 and Fedora 38.

2023-06-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-09  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: add sframe_find_fre tests for pltN entries
	Add a new test plt-findfre-1 to ensure lookup of SFrame stack trace
	information for pltN entries is correct.

	In this test, a dummy SFrame FDE of type SFRAME_FDE_TYPE_PCMASK is
	created.  The size of the 'function code block' covered by the SFrame
	FDE is equivalent to 5 pltN entries of 16 bytes each.

	The test first looks up SFrame FREs for some addresses in the first pltN
	entry, followed by lookups for some addresses in the fourth pltN entry.

	libsframe/
		* Makefile.in: Regenerated.
		* testsuite/libsframe.find/find.exp: Add new test.
		* testsuite/libsframe.find/local.mk: Likewise.
		* testsuite/libsframe.find/plt-findfre-1.c: New test.

2023-06-09  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fix sframe_find_fre for pltN entries
	To find SFrame stack trace information from an FDE of type
	SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
	like,
	  (start_ip_offset & 0xff) >= (pc & 0xff), etc.

	This is buggy and needs correction.  The mask 0xff should be 0xf (to
	work for a pltN entry of size say, 16 bytes).

	At this time, the size of the pltN entry is implicitly assumed to be 16
	bytes by libsframe.  In next version of the SFrame format, we can encode
	this information explicitly in the SFrame FDE.

	For now, we should fix the code to at least behave correctly for the
	generated code and the generated SFrame stack trace information for the
	pltN entries on x86_64.

	libsframe/
		* sframe.c (sframe_find_fre): Correct the bitmask used for
		SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.

2023-06-09  Luis Machado  <luis.machado@arm.com>

	[AArch64,arm] Fix some formatting issues in the aarch64/arm codebase
	As noted by Tom Tromey, there are some formatting issues with the ternary
	operator in the aarch64/arm codebase.  This patch fixes those.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Simplify tui_puts_internal
	Simplify tui_puts_internal by using continue, as per this [1] coding standard
	rule, making the function more readable and easier to understand.

	No functional changes.

	Tested on x86_64-linux.

	[1] https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-09  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Delete line buffer when switching to singlekey
	Say we're in TUI mode, and type "sun":
	...
	(gdb) sun
	...

	After switching to SingleKey mode using C-x s, we have just:
	...
	sun
	...

	After typing "d", we get:
	...
	sun
	Undefined command: "sundown".  Try "help".
	...

	The SingleKey "d" is supposed run the "down" command.

	Fix this by clearing the readline line buffer when switching to SingleKey
	mode.

	Tested on x86_64-linux.

	PR tui/30522
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add test-case gdb.tui/single-key.exp
	I noticed that there's no test-case excercising SingleKey mode, so add a test-case.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-09  Andrew Burgess  <aburgess@redhat.com>

	gdb/debuginfod: cleanup debuginfod earlier
	A GDB crash was discovered on Fedora GDB that was tracked back to an
	issue with the way that debuginfod is cleaned up.

	The bug was reported on Fedora 37, 38, and 39.  Here are the steps to
	reproduce:

	1. The file /etc/ssl/openssl.cnf contains the following lines:

	   [provider_sect]
	   default = default_sect
	   ##legacy = legacy_sect
	   ##
	   [default_sect]
	   activate = 1

	   ##[legacy_sect]
	   ##activate = 1

	   The bug will occur when the '##' characters are removed so that the
	   lines in question look like this:

	   [provider_sect]
	   default = default_sect
	   legacy = legacy_sect

	   [default_sect]
	   activate = 1

	   [legacy_sect]
	   activate = 1

	2. Clean up any existing debuginfod cache data:

	   > rm -rf $HOME/.cache/debuginfod_client

	3. Run GDB:

	   > gdb -nx -q -iex 'set trace-commands on' \
	                -iex 'set debuginfod enabled on' \
	                -iex 'set confirm off' \
			-ex 'start' -ex 'quit' /bin/ls
	   +set debuginfod enabled on
	   +set confirm off
	   Reading symbols from /bin/ls...
	   Downloading separate debug info for /usr/bin/ls
	   ... snip ...
	   Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde38) at ../src/ls.c:1646
	   1646    {
	   +quit

	   Fatal signal: Segmentation fault
	   ----- Backtrace -----
	   ... snip ...

	So GDB ends up crashing during exit.

	What's happening is that when debuginfod is initialised
	debuginfod_begin is called (this is in the debuginfod library), this
	in turn sets up libcurl, which makes use of openssl.  Somewhere during
	this setup process an at_exit function is registered to cleanup some
	state.

	Back in GDB the debuginfod_client object is managed using this code:

	  /* Deleter for a debuginfod_client.  */

	  struct debuginfod_client_deleter
	  {
	    void operator() (debuginfod_client *c)
	    {
	      debuginfod_end (c);
	    }
	  };

	  using debuginfod_client_up
	    = std::unique_ptr<debuginfod_client, debuginfod_client_deleter>;

	And then a global debuginfod_client_up is created to hold a pointer to
	the debuginfod_client object.  As a global this will be cleaned up
	using the standard C++ global object destructor mechanism, which is
	run after the at_exit handlers.

	However, it is expected that when debuginfod_end is called the
	debuginfod_client object will still be in a usable state, that is, we
	don't expect the at_exit handlers to have run and started cleaning up
	the library state.

	To fix this issue we need to ensure that debuginfod_end is called
	before the at_exit handlers have a chance to run.

	This commit removes the debuginfod_client_up type, and instead has GDB
	hold a raw pointer to the debuginfod_client object.  We then make use
	of GDB's make_final_cleanup to register a function that will call
	debuginfod_end.

	As GDB's final cleanups are called before exit is called, this means
	that debuginfod_end will be called before the at_exit handlers are
	called, and the crash identified above is resolved.

	It's not obvious how this issue can easily be tested for. The bug does
	not appear to manifest when using a local debuginfod server, so we'd
	need to setup something more involved.  For now I'm proposing this
	patch without any associated tests.

	Co-Authored-By: Mark Wielaard <mark@klomp.org>
	Co-Authored-By: Simon Marchi <simark@simark.ca>
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Aaron Merey <amerey@redhat.com>

2023-06-09  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix ASan failure after recent string changes
	After this commit:

	  commit baab375361c365afee2577c94cbbd3fdd443d6da
	  Date:   Tue Jul 13 14:44:27 2021 -0400

	      gdb: building inferior strings from within GDB

	It was pointed out that a new ASan failure had been introduced which
	was triggered by gdb.base/internal-string-values.exp:

	  (gdb) PASS: gdb.base/internal-string-values.exp: test_setting: all langs: lang=ada: ptype "foo"
	  print $_gdb_maint_setting("test-settings string")
	  =================================================================
	  ==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba682 bp 0x7ffd20644620 sp 0x7ffd20644610
	  READ of size 1 at 0x603000068034 thread T0
	      #0 0x564785cba681 in find_command_name_length(char const*) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2129
	      #1 0x564785cbacb2 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2186
	      #2 0x564785cbb539 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2248
	      #3 0x564785cbbcf3 in lookup_cmd(char const**, cmd_list_element*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2339
	      #4 0x564785c82df2 in setting_cmd /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2219
	      #5 0x564785c84274 in gdb_maint_setting_internal_fn /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2348
	      #6 0x564788167b3b in call_internal_function(gdbarch*, language_defn const*, value*, int, value**) /tmp/src/binutils-gdb/gdb/value.c:2321
	      #7 0x5647854b6ebd in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11254
	      #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
	      #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
	      #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
	      #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
	      #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
	      #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
	      #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
	      #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
	      #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
	      #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
	      #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
	      #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
	      #20 0x564786683dea in gdb_rl_callback_read_char_wrapper_noexcept /tmp/src/binutils-gdb/gdb/event-top.c:192
	      #21 0x564786684042 in gdb_rl_callback_read_char_wrapper /tmp/src/binutils-gdb/gdb/event-top.c:225
	      #22 0x564787f1b119 in stdin_event_handler /tmp/src/binutils-gdb/gdb/ui.c:155
	      #23 0x56478862438d in handle_file_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:573
	      #24 0x564788624d23 in gdb_wait_for_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:694
	      #25 0x56478862297c in gdb_do_one_event(int) /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:264
	      #26 0x564786df99f0 in start_event_loop /tmp/src/binutils-gdb/gdb/main.c:412
	      #27 0x564786dfa069 in captured_command_loop /tmp/src/binutils-gdb/gdb/main.c:476
	      #28 0x564786dff61f in captured_main /tmp/src/binutils-gdb/gdb/main.c:1320
	      #29 0x564786dff75c in gdb_main(captured_main_args*) /tmp/src/binutils-gdb/gdb/main.c:1339
	      #30 0x564785381b6d in main /tmp/src/binutils-gdb/gdb/gdb.c:32
	      #31 0x7f4efbc3984f  (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
	      #32 0x7f4efbc39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
	      #33 0x564785381934 in _start (/tmp/build/binutils-gdb/gdb/gdb+0xabc5934) (BuildId: 90de353ac158646e7dab501b76a18a76628fca33)

	  0x603000068034 is located 0 bytes after 20-byte region [0x603000068020,0x603000068034) allocated by thread T0 here:
	      #0 0x7f4efcee0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
	      #1 0x5647856265d8 in xcalloc /tmp/src/binutils-gdb/gdb/alloc.c:97
	      #2 0x564788610c6b in xzalloc(unsigned long) /tmp/src/binutils-gdb/gdbsupport/common-utils.cc:29
	      #3 0x56478815721a in value::allocate_contents(bool) /tmp/src/binutils-gdb/gdb/value.c:929
	      #4 0x564788157285 in value::allocate(type*, bool) /tmp/src/binutils-gdb/gdb/value.c:941
	      #5 0x56478815733a in value::allocate(type*) /tmp/src/binutils-gdb/gdb/value.c:951
	      #6 0x5647854ae81c in expr::ada_string_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:10675
	      #7 0x5647854b63b8 in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11184
	      #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
	      #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
	      #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
	      #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
	      #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
	      #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
	      #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
	      #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
	      #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
	      #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
	      #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
	      #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)

	The problem is in cli/cli-cmds.c, in the function setting_cmd, where
	we do this:

	  const char *a0 = (const char *) argv[0]->contents ().data ();

	Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or
	a TYPE_CODE_STRING.  The problem is that the above line is casting the
	value contents directly to a C-string, i.e. one that is assumed to
	have a null-terminator at the end.

	After the above commit this can no longer be assumed to be true.  A
	string value will be represented just as it would be in the current
	language, so for Ada and Fortran the string will be an array of
	characters with no null-terminator at the end.

	My proposed solution is to copy the string contents into a std::string
	object, and then use the std::string::c_str() value, this will ensure
	that a null-terminator has been added.

	I had a check through GDB at places TYPE_CODE_STRING was used and
	couldn't see any other obvious places where this type of assumption
	was being made, so hopefully this is the only offender.

	Running the above test with ASan compiled in no longer gives an error.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-09  Tom Tromey  <tromey@adacore.com>

	Use scoped_value_mark in two more places
	I found a couple of spots that could use scoped_value_mark.  One of
	them is a spot that didn't consider the possibility that value_mark
	can return NULL.  I tend to doubt this can be seen in this context,
	but nevertheless this is safer.

	Regression tested on x86-64 Fedora 36.

2023-06-09  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix typos
	Fix typos:
	- reponse -> response
	- inital -> initial
	- a -> an

2023-06-09  Alan Modra  <amodra@gmail.com>

	readelf/objdump remember_state memory leaks
		* dwarf.c (display_debug_frames <DW_CFA_restore_state>): Do free
		invalid remember_state.

2023-06-09  Alan Modra  <amodra@gmail.com>

	ecoff find_nearest_line and final link leaks
	Freeing ecoff_debug_info "pointers to the unswapped symbolic info"
	isn't a simple matter, due to differing allocation strategies.  In
	_bfd_ecoff_slurp_symbolic_info the pointers are to objalloc memory.
	In the ecoff linker they are to separately malloc'd memory.  In gas we
	have most (obj-elf) or all (obj-ecoff) into a single malloc'd buffer.

	This patch fixes the leaks for binutils and ld, leaving the gas leaks
	for another day.  The mips elf backend already had this covered, and
	the ecoff backend had a pointer, raw_syments used as a flag, so most
	of the patch is moving these around a little so they are accessible
	for both ecoff and elf.

	include/
		* coff/ecoff.h (struct ecoff_debug_info): Add alloc_syments.
	bfd/
		* libecoff.h (struct ecoff_tdata): Delete raw_syments.
		* elfxx-mips.c (free_ecoff_debug): Delete.  Replace uses with
		_bfd_ecoff_free_ecoff_debug_info.
		(_bfd_mips_elf_final_link): Init debug.alloc_syments.
		* ecofflink.c (_bfd_ecoff_free_ecoff_debug_info): New function.
		* ecoff.c (_bfd_ecoff_bfd_free_cached_info): Call
		_bfd_ecoff_free_ecoff_debug_info.
		(_bfd_ecoff_slurp_symbolic_info): Replace uses of raw_syments
		with alloc_syments.
		(ecoff_final_link_debug_accumulate): Likewise.  Use
		_bfd_ecoff_free_ecoff_debug_info.
		(_bfd_ecoff_bfd_copy_private_bfd_data): Set alloc_syments for
		copied output.
		* elf64-alpha.c (elf64_alpha_read_ecoff_info): Use
		_bfd_ecoff_free_ecoff_debug_info.
		* libbfd-in.h (_bfd_ecoff_free_ecoff_debug_info): Declare.
		* libbfd.h: Regenerate.
	gas/
		* config/obj-ecoff.c (ecoff_frob_file): Set alloc_syments.
		* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.

2023-06-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add test-case gdb.tui/long-prompt.exp
	I noticed that the test-suite doesn't excercise the case in
	tui_redisplay_readline that height (initially 1) is changed by this call:
	...
	    tui_puts_internal (w, prompt, &height);
	...

	Add a test-case that excercises this.

	Tested on x86_64-linux.

2023-06-08  Lancelot SIX  <lancelot.six@amd.com>

	gdb/corelow.c: do not try to reopen a file if open failed once
	In the current implementation, core_target::build_file_mappings will try
	to locate and open files which were mapped in the process for which the
	core dump was produced.  If the file cannot be found or cannot be
	opened, GDB will re-try to open it once for each time it was mapped in
	the process's address space.

	This patch makes it so GDB recognizes that it has already failed to open
	a given file once and does not re-try the process for each mapping.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-06-08  Lancelot SIX  <lancelot.six@amd.com>

	gdb/corelow.c: avoid repeated warnings in build_file_mappings
	When GDB opens a coredump it tries to locate and then open all files
	which were mapped in the process.

	If a file is found but cannot be opened with BFD (bfd_open /
	bfd_check_format fails), then a warning is printed to the user.  If the
	same file was mapped multiple times in the process's address space, the
	warning is printed once for each time the file was mapped.  I find this
	un-necessarily noisy.

	This patch makes it so the warning message is printed only once per
	file.

	There was a comment in the code assuming that if the file was found on
	the system, opening it (bfd_open + bfd_check_format) should always
	succeed.  A recent change in BFD (014a602b86f "Don't optimise bfd_seek
	to same position") showed that this assumption is not valid.  For
	example, it is possible to have a core dump of a process which had
	mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM).  In
	such case the core dump does contain the information that portions of
	this special file were mapped in the host process, but trying to seek to
	position 0 will fail, making bfd_check_format fail.  This patch removes
	this comment.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-06-08  Lancelot SIX  <lancelot.six@amd.com>

	gdb/corelow.c: fix use-after-free in build_file_mappings
	In core_target::build_file_mappings, GDB tries to open files referenced
	in the core dump.

	The process goes like this:

	    struct bfd *bfd = bfd_map[filename];
	    if (bfd == nullptr)
	      {
	        bfd = bfd_map[filename]
	          = bfd_openr (expanded_fname.get (), "binary");
	        if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
	          {
	            if (bfd != nullptr)
	              bfd_close (bfd);
	            return;
	          }
	      }
	    asection *sec = bfd_make_section_anyway (bfd, "load");
	    ...

	The problem is that if bfd_check_format fails, we close the bfd but keep
	a reference to it in the bfd_map.

	If the same filename appears another time in the NT_FILE note, we enter
	this code again.  The second time, bfd_map[filename] is not nullptr and
	we try to call bfd_make_section_anyway on an already closed BFD, which
	is a use-after-free error.

	This patch makes sure that the bfd is only saved in the bfd_map if it
	got opened successfully.

	This error got exposed by a recent change in BFD (014a602b86f "Don't
	optimise bfd_seek to same position").  Since this change, opening a
	coredump which contains mapping to some special files such as a DRI
	render node (/dev/dri/renderD$NUM) exposes the issue.  This happens for
	example for processes using AMDGPU devices to offload compute tasks.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-06-08  Alan Modra  <amodra@gmail.com>

	Re: _bfd_free_cached_info
	Oops, another leak caused by not defining the correct macro.

		* elf32-mips.c: Define bfd_elf32_bfd_free_cached_info.
		* elfn32-mips.c: Likewise.
		* elf64-mips.c: Define bfd_elf64_bfd_free_cached_info.

2023-06-08  Alan Modra  <amodra@gmail.com>

	Re: _bfd_free_cached_info
	ELF targets with target-specific free_cache_info functions need to
	call _bfd_elf_free_cached_info, not _bfd_generic_bfd_free_cached_info.

		* elf64-ppc.c (ppc64_elf_free_cached_info): Call
		_bfd_elf_free_cached_info.
		* elfnn-aarch64.c (elfNN_aarch64_bfd_free_cached_info): Likewise.

2023-06-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-07  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: reuse static function sframe_decoder_get_funcdesc_at_index
	sframe_decoder_get_funcdesc_at_index () is the function to access SFrame
	FDEs in the SFrame decoder context.  Use it consistently.

	Avoid unnecessary type cast and include minor enhancements as the code
	is moved around.

	libsframe/
		* sframe.c (sframe_decoder_get_funcdesc_at_index): Move some
		checks here.  Move the static function definition before the new
		use.
		(sframe_decoder_get_funcdesc): Use
		sframe_decoder_get_funcdesc_at_index instead.

2023-06-07  Tom Tromey  <tromey@adacore.com>

	Simplify ada_lookup_struct_elt_type
	This patch simplifies ada_lookup_struct_elt_type by changing it to
	call find_struct_field.  The two functions were substantially similar,
	even to the point of having identical comments.

	I tested this using both the gdb test suite and the internal AdaCore
	test suite.  Given this and the fact that it is Ada-specific, I am
	checking it in.

2023-06-07  Nick Clifton  <nickc@redhat.com>

	Add extra linker warning message about discrepancies between normal and common symbols.
	  PR 30499
	  bfd * elflink.c (elf_link_add_object_symbols): Add a message indicating that alignment and size discrepancies between the definition of common symbols and normal symbols are serious and should be investigated.
	  ld  * testsuite/ld-elfcomm/elfcomm.exp: Update regexps to match new output from the linker.

2023-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Factor out border-mode help text
	I noticed that the help texts for tui border-mode and tui active-border-mode
	are similar.

	Factor out the common part into macro HELP_ATTRIBUTE_MODE.

	Tested on x86_64-linux.

2023-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Handle pending ^C after rl_callback_read_char for readline 7
	In commit faf01aee1d0 ("[gdb] Handle pending ^C after rl_callback_read_char")
	we handled a problem (described in detail in that commit) for readline >= 8
	using public readline functions rl_pending_signal and rl_check_signals.

	For readline 7 (note that we require at least readline 7 so there's no need to
	worry about readline 6), there was no fix though, because rl_check_signals was
	not available.

	Fix this by instead using the private readline function _rl_signal_handler.

	There is precedent for using private readline variables and functions, but
	it's something we want to get rid of (PR build/10723).  Nevertheless, I think
	we can allow this specific instance because it's not used when building
	against readline >= 8.

	[ In the meanwhile, a fix was committed in the devel branch of the readline
	repo, contained in commit 8d0c439 ("rollup of changes since readline-8.2"),
	first proposed here (
	https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00008.html ). ]

	Tested on x86_64-linux, against system readline 7.0 on openSUSE Leap 15.4.

	PR cli/27813
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813

2023-06-07  Tom de Vries  <tdevries@suse.de>

	Fix PR30369 regression on aarch64/arm (PR30506)
	The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
	Arm.

	As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
	there are issues with both the prologue skipper for AArch64 and Arm and an
	incorrect assumption by the testcase.

	This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
	the end of a function.  It also incorporates a fix to the testcase so it
	doesn't assume the prologue skipper will stop at the first instruction of the
	functions/labels.

	Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
	x86_64-linux Ubuntu 20.04.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30506

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	Co-Authored-By: Luis Machado <luis.machado@arm.com>

2023-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing wait in gdb.python/tui-window-disabled.exp
	While working on PR tui/30526, I noticed a bug in test-case
	gdb.python/tui-window-disabled.exp.

	Here we send "tui enable" to gdb, but don't wait for it to arrive before
	checking for a window box:
	...
	    send_gdb "tui enable\n"
	    Term::check_box "check for python window" 0 0 80 16
	...

	Fix this by waiting for the prompt to be issued in TUI before doing the check.

	Tested on x86_64-linux.

2023-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix two typos in gdb.python/tui-window-disabled.exp
	Fix two typos in test-case gdb.python/tui-window-disabled.exp.

2023-06-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle output after prompt in gdb.threads/step-N-all-progress.exp
	Using "taskset -c 0" I run into this timeout:
	...
	(gdb) PASS: gdb.threads/step-N-all-progress.exp: non-stop=on: \
	  target-non-stop=on: continue to breakpoint: break here
	next 3^M
	[New Thread 0x7ffff7dbd6c0 (LWP 10202)]^M
	50        return 0;^M
	(gdb) [Thread 0x7ffff7dbd6c0 (LWP 10202) exited]^M
	FAIL: gdb.threads/step-N-all-progress.exp: non-stop=on: target-non-stop=on: \
	  next 3 (timeout)
	...

	The problem is that this test:
	...
	    gdb_test "next 3" "return 0;"
	...
	expects no output after the prompt.

	Fix this by using -no-prompt-anchor.

	Tested on x86_64-linux.

2023-06-07  Alan Modra  <amodra@gmail.com>

	ld-elf/eh5 remove xfail hppa64
	Commit cb81e84c72 resulted in an xpass for hppa64-hp-hpux11, but the
	test still fails on hpp64-linux.  Let's make it pass for hppa64-linux
	too, by accepting pcrel sdata8 encoding in the augmentation data.

2023-06-07  Luis Machado  <luis.machado@arm.com>

	Fix gdb.base/memtag.exp failure
	While running this test on an emulator, I noticed we're failing to match the
	output message when "memory-tag check" is issued with no arguments.  That's
	because I coded the message using "error" and missed a period at the end.  Other
	similar messages are issued with error_no_arg.

	This patch changes that call to use error_no_arg.

	Tested on aarch64-linux Ubuntu 20.04/22.04.

2023-06-07  Alan Modra  <amodra@gmail.com>

	_bfd_free_cached_info
	doc/bfdint.texi and comments in the aout and som code about this
	function are just wrong, and its name is not very apt.  Better would
	be _bfd_mostly_destroy, and we certainly should not be saying anything
	about the possibility of later recreating anything lost by this
	function.  What's more, if _bfd_free_cached_info is called when
	creating an archive map to reduce memory usage by throwing away
	symbols, the target _close_and_cleanup function won't have access to
	tdata or section bfd_user_data to tidy memory.  This means most of the
	target _close_and_cleanup function won't do anything, and therefore
	sometimes will result in memory leaks.

	This patch fixes the documentation problems and moves most of the
	target _close_and_cleanup code to target _bfd_free_cached_info.
	Another notable change is that bfd_generic_bfd_free_cached_info is now
	defined as _bfd_free_cached_info rather than _bfd_bool_bfd_true,
	ie. the default now frees objalloc memory.

2023-06-07  Alan Modra  <amodra@gmail.com>

	Memory leaks in bfd/vms-lib.c
		* vms-lib.c (vms_lib_read_index): Free malloc'd memory on error
		return paths.
		(vms_write_index, _bfd_vms_lib_write_archive_contents): Likewise.

	bfd/elf.c strtab memory leak
		* elf.c (_bfd_elf_compute_section_file_positions): Free strtab
		on set_group_contents failure return path.

2023-06-07  Alan Modra  <amodra@gmail.com>

	objcopy memory leaks after errors
	These aren't important at all, but tidy them in case they obscure
	other more important leaks.

		* objcopy (copy_file): Close input bfd after errors.

2023-06-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-06  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: fix cosmetic issues and typos
	include/
		* sframe-api.h (sframe_decoder_get_num_fidx): Use extern.
	libsframe/
		* sframe-dump.c (dump_sframe_func_with_fres): Fix line length.
		* sframe.c (sframe_frame_row_entry_copy): Likewise.
		(sframe_decode_fre_start_address): Use the intended type uint32_t.

2023-06-06  Alan Modra  <amodra@gmail.com>

	Re: loongarch readelf support
	Commit 89c70cd358b8 apparently results in a bogus "value may be used
	uninitialized" warning with some combination of compiler and
	optimisation options.

		* readelf.c (target_specific_reloc_handling): Init value.

2023-06-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-05  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: avoid unnecessary type casts
	Change the data type of some of the members of the sframe_decoder_ctx
	and sframe_encoder_ctx data structures to use the applicable data types
	explicitly. Current implementation in libsframe does type casts, which
	seem unnecessary.

	libsframe/
		* libsframe/sframe-impl.h (struct sframe_decoder_ctx): Use
		applicable data type explicitly.
		(struct sframe_encoder_ctx): Likewise. Use same style of
		comments consistently.
		* libsframe/sframe.c (struct sf_fde_tbl): Define without
		typedef.
		(struct sf_fre_tbl): Likewise.
		(sframe_decode): Remove unnecessary type casts.
		(sframe_encoder_get_funcdesc_at_index): Likewise.
		(sframe_encoder_add_fre): Likewise.
		(sframe_encoder_add_funcdesc): Likewise.
		(sframe_sort_funcdesc): Likewise.
		(sframe_encoder_write_sframe): Likewise.

2023-06-05  H.J. Lu  <hjl.tools@gmail.com>

	ELF: Add "#pass" to ld-elf/pr30508.d
	Add "#pass" to ld-elf/pr30508.d to allow extra segments.

		PR binutils/30508
		* testsuite/ld-elf/pr30508.d: Add "#pass".

2023-06-05  Tom Tromey  <tromey@adacore.com>

	Use unrelocated_addr in dwarf2_fde
	This changes dwarf2_fde to use the unrelocated_addr type.  This
	pointed out a latent bug in dwarf2_frame_cache, where a relocated
	address is compared to an unrelocated address.

2023-06-05  Tom Tromey  <tromey@adacore.com>

	Use local "text offset" variable in dwarf2_frame_cache
	A few spots in dwarf2_frame_cache use:

	    cache->per_objfile->objfile->text_section_offset ()

	... and a subsequent patch will add more, so move this into a local
	variable.

2023-06-05  Tom Tromey  <tromey@adacore.com>

	Constify dwarf2_cie::augmentation
	I noticed that dwarf2_cie::augmentation could be 'const'.

	Use "unrelocated" terminology in linetable_entry
	I forgot to convert struct linetable_entry to use the "unrelocated"
	(as opposed to "raw") terminology.  This patch corrects the oversight.

	Fix comment in address_class
	enum address_class has a stale comment referring to
	MSYMBOL_VALUE_RAW_ADDRESS, which no longer exists.  This patch updates
	the comment.

	Use unrelocated_addr in dwarf_decode_lines
	This changes dwarf_decode_lines to accept an unrelocated_addr and
	fixes up the fallout.

	Use unrelocated_addr in the DWARF reader
	This changes various spots in the DWARF reader to use
	unrelocated_addr.

	Move unrelocated_addr to common-types.h
	unrelocated_addr is currently defined in symtab.h, but in order to
	avoid having to include that in more places, I wanted to move the type
	elsewhere.  I considered defs.h, but it seemed reasonable to have it
	next to CORE_ADDR, which is what this patch does.

	Minor cleanup in loclist_describe_location
	loclist_describe_location already has a per_objfile local variable, so
	use it consistently.

	Remove baseaddr parameter from dwarf2_record_block_ranges
	dwarf2_record_block_ranges is only ever called with the text section
	offset, so this patch removes the parameter entirely.  This makes a
	subsequent patch a little simpler.

2023-06-05  H.J. Lu  <hjl.tools@gmail.com>

	ELF: Don't warn an empty PT_LOAD with the program headers
	When rewriting the program headers, don't warn an empty PT_LOAD with the
	program headers.

	bfd/

		PR binutils/30508
		* elf.c (rewrite_elf_program_header): Don't warn if an empty
		PT_LOAD contains the program headers.

	ld/

		PR binutils/30508
		* testsuite/ld-elf/pr30508.d: New file.
		* testsuite/ld-elf/pr30508.s: Likewise.

2023-06-05  Andrew Burgess  <aburgess@redhat.com>

	gdb: building inferior strings from within GDB
	History Of This Patch
	=====================

	This commit aims to address PR gdb/21699.  There have now been a
	couple of attempts to fix this issue.  Simon originally posted two
	patches back in 2021:

	  https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html
	  https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html

	Before Pedro then posted a version of his own:

	  https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html

	After this the conversation halted.  Then in 2023 I (Andrew) also took
	a look at this bug and posted two versions:

	  https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html
	  https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html

	The approach taken in my first patch was pretty similar to what Simon
	originally posted back in 2021.  My second attempt was only a slight
	variation on the first.

	Pedro then pointed out his older patch, and so we arrive at this
	patch.  The GDB changes here are mostly Pedro's work, but updated by
	me (Andrew), any mistakes are mine.

	The tests here are a combinations of everyone's work, and the commit
	message is new, but copies bits from everyone's earlier work.

	Problem Description
	===================

	Bug PR gdb/21699 makes the observation that using $_as_string with
	GDB's printf can cause GDB to print unexpected data from the
	inferior.  The reproducer is pretty simple:

	  #include <stddef.h>
	  static char arena[100];

	  /* Override malloc() so value_coerce_to_target() gets a known
	     pointer, and we know we"ll see an error if $_as_string() gives
	     a string that isn't null terminated. */
	  void
	  *malloc (size_t size)
	  {
	      memset (arena, 'x', sizeof (arena));
	      if (size > sizeof (arena))
	          return NULL;
	      return arena;
	  }

	  int
	  main ()
	  {
	    return 0;
	  }

	And then in a GDB session:

	  $ gdb -q test
	  Reading symbols from /tmp/test...
	  (gdb) start
	  Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
	  Starting program: /tmp/test

	  Temporary breakpoint 1, main () at test.c:17
	  17        return 0;
	  (gdb) printf "%s\n", $_as_string("hello")
	  "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
	  (gdb) quit

	The problem above is caused by how value_cstring is used within
	py-value.c, but once we understand the issue then it turns out that
	value_cstring is used in an unexpected way in many places within GDB.

	Within py-value.c we have a null-terminated C-style string.  We then
	pass a pointer to this string, along with the length of this
	string (so not including the null-character) to value_cstring.

	In value_cstring GDB allocates an array value of the given character
	type, and copies in requested number of characters.  However
	value_cstring does not add a null-character of its own.  This means
	that the value created by calling value_cstring is only
	null-terminated if the null-character is included in the passed in
	length.  In py-value.c this is not the case, and indeed, in most uses
	of value_cstring, this is not the case.

	When GDB tries to print one of these strings the value contents are
	pushed to the inferior, and then read back as a C-style string, that
	is, GDB reads inferior memory until it finds a null-terminator.  For
	the py-value.c case, no null-terminator is pushed into the inferior,
	so GDB will continue reading inferior memory until a null-terminator
	is found, with unpredictable results.

	Patch Description
	=================

	The first thing this patch does is better define what the arguments
	for the two function value_cstring and value_string should represent.
	The comments in the header file are updated to describe whether the
	length argument should, or should not, include a null-character.
	Also, the data argument is changed to type gdb_byte.  The functions as
	they currently exist will handle wide-characters, in which case more
	than one 'char' would be needed for each character.  As such using
	gdb_byte seems to make more sense.

	To avoid adding casts throughout GDB, I've also added an overload that
	still takes a 'char *', but asserts that the character type being used
	is of size '1'.

	The value_cstring function is now responsible for adding a null
	character at the end of the string value it creates.

	However, once we start looking at how value_cstring is used, we
	realise there's another, related, problem.  Not every language's
	strings are null terminated.  Fortran and Ada strings, for example,
	are just an array of characters, GDB already has the function
	value_string which can be used to create such values.

	Consider this example using current GDB:

	  (gdb) set language ada
	  (gdb) p $_gdb_setting("arch")
	  $1 = (97, 117, 116, 111)
	  (gdb) ptype $
	  type = array (1 .. 4) of char
	  (gdb) p $_gdb_maint_setting("test-settings string")
	  $2 = (0)
	  (gdb) ptype $
	  type = array (1 .. 1) of char

	This shows two problems, first, the $_gdb_setting and
	$_gdb_maint_setting functions are calling value_cstring using the
	builtin_char character, rather than a language appropriate type.  In
	the first call, the 'arch' case, the value_cstring call doesn't
	include the null character, so the returned array only contains the
	expected characters.  But, in the $_gdb_maint_setting example we do
	end up including the null-character, even though this is not expected
	for Ada strings.

	This commit adds a new language method language_defn::value_string,
	this function takes a pointer and length and creates a language
	appropriate value that represents the string.  For C, C++, etc this
	will be a null-terminated string (by calling value_cstring), and for
	Fortran and Ada this can be a bounded array of characters with no null
	terminator.  Additionally, this new language_defn::value_string
	function is responsible for selecting a language appropriate character
	type.

	After this commit the only calls to value_cstring are from the C
	expression evaluator and from the default language_defn::value_string.

	And the only calls to value_string are from Fortan, Ada, and ObjectC
	related code.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-06-05  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix grammar in comments and docs
	Fix grammar in some comments and docs:
	- machines that doesn't -> machines that don't
	- its a -> it's a
	- its the -> it's the
	- if does its not -> if it does it's not
	- one more instructions if doesn't match ->
	  one more instruction if it doesn't match
	- it's own -> its own
	- it's first -> its first
	- it's pointer -> its pointer

	I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
	domain notice, I've left that alone.

	Tested on x86_64-linux.

2023-06-05  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix more typos
	Fix some more typos:
	- distinquish -> distinguish
	- actualy -> actually
	- singe -> single
	- frash -> frame
	- chid -> child
	- dissassembler -> disassembler
	- uninitalized -> uninitialized
	- precontidion -> precondition
	- regsiters -> registers
	- marge -> merge
	- sate -> state
	- garanteed -> guaranteed
	- explictly -> explicitly
	- prefices (nonstandard plural) -> prefixes
	- bondary -> boundary
	- formated -> formatted
	- ithe -> the
	- arrav -> array
	- coresponding -> corresponding
	- owend -> owned
	- fials -> fails
	- diasm -> disasm
	- ture -> true
	- tpye -> type

	There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to
	SIG_CODE_BOUNDARY_FAULT.

	Tested on x86_64-linux.

2023-06-05  Alan Modra  <amodra@gmail.com>

	bfd_error_on_input messages
	bfd_errmsg uses asprintf for bfd_error_on_input, which means we
	currently leak memory.  Keep a static pointer to the message and free
	it in various places to minimise the leaks.
	bfd_set_input_error (NULL, bfd_error_no_error) is a way to free up the
	last string if that matters.

		* bfd.c (input_error_msg): New static var.
		(bfd_set_input_error): Free it here..
		(bfd_init): ..and here..
		(bfd_errmsg): ..and here.  Use it for asprintf output.

2023-06-05  Alan Modra  <amodra@gmail.com>

	Yet another ecoff fuzzed object fix
		* ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check fdr_ptr
		csym against remaining space for symbols.  Error on out of bounds
		fdr_ptr fields.

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: sync oprand char usage between mips and micromips
	We should try our best to make mips32 using the same
	oprand char with micromips. So for mips32, we use:

	  ^  is added for 5bit sa oprand for some new DSPr2 instructions:
		APPEND, PREPEND, PRECR_SRA[_R].PH.W
		the LSB bit is 11, like RD.
	  +t is removed for coprocessor 0 destination register.
		'E' does the samething.
	  +t is now used for RX oprand for MFTR/MTTR (MT ASE)
	  ?  is added for sel oprand for MFTR/MTTR (MT ASE)
		For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc,
		while for micromips, they are different.

	We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2:
		concatenating rs with rx as the index of control or data.

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: add MT ASE support for micromips32
	These instructions are descripted in MD00768.

	MIPS® Architecture for Programmers
	Volume IV-f: The MIPS® MT Module for
	the microMIPS32™ Architecture

	Document Number: MD00768
	Revision 1.12
	July 16, 2013

	https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	Revert "MIPS: add MT ASE support for micromips32"
	This reverts commit 783a5f46b0583e9ed3a63acd3361009f46de5c17.

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: add MT ASE support for micromips32
	These instructions are descripted in MD00768.

	MIPS® Architecture for Programmers
	Volume IV-f: The MIPS® MT Module for
	the microMIPS32™ Architecture

	Document Number: MD00768
	Revision 1.12
	July 16, 2013

	https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: fix some ld testcases with compiler
	1. config/default.exp:
		use -mabi=32 not for -gnuabi64
		xfail_from_runlist: remove an element and mark it xfail.
	2. ld-elf/indirect.exp: xfail
		indirect5a indirect5b indirect6a indirect6b
		indirect5c indirect5d indirect6c indirect6d
	3. ld-elf/pr23658-2: mips output is not common
	4. ld-elf/shared.exp: non-run on mips: Build libpr16496b.so
	5. ld-elfvers/vers.exp:
		xfail vers4, vers4b
		no-run on mips: vers24a, vers24b, vers24c
	6. ld-gc/gc.exp: add -KPIC into asflags for pr13683, pr14265, pr19161
	7. ld-mips-elf/mips-elf.exp:
		use noarch for mips16-local-stubs-1, since it use -mips4
	8. ld-plugin/lto.exp:
		no-run on mips/linux: PR ld/12982
		add -KPIC into asflags for lto-3r, lto-5r, PR ld/19317 (2)
		xfail PR ld/15323 (4), PR ld/19317 (3)
	9. ld-plugin/plugin.exp: xfail
		plugin claimfile lost symbol
		plugin claimfile replace symbol
		plugin claimfile replace symbol
		plugin claimfile lost symbol with source
		plugin claimfile replace symbol with source
		plugin claimfile resolve symbol with source
		plugin 2 with source lib
		load plugin 2 with source
		plugin 3 with source lib
		load plugin 3 with source
	11. ld-selective/selective.exp: add -fno-PIC, which is needed for -mno-abicalls
	12. ld-shared/shared.exp: xfail shared (non PIC), shared (PIC main, non PIC so)

	MIPS: fix -gnuabi64 testsuite
	Test on:
		mips64-linux-gnuabi64
		mips64el-linux-gnuabi64
		mipsisa64-linux-gnuabi64
		mipsisa64el-linux-gnuabi64
		mipsisa64r2-linux-gnuabi64
		mipsisa64r2el-linux-gnuabi64
		mipsisa64r6-linux-gnuabi64
		mipsisa64r6el-linux-gnuabi64

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: fix r6 testsuites
	Introduce
		run_dump_test_o32l
		run_dump_test_n32l
		run_dump_test_n64l
	Which use `-march=from-abi` for pre-R6 testcases,
	like micromips/mips16e etc.

	For cases doesn't use run_dump_test_*, we use
		-mips32r2 for micromips32
		-mips1 for mips16-32
		-march=from-abi for testcases to o32/n32/n64 both/all.

	Replace `addi` with `addiu` for some cases for both r6 and pre-R6.

	Introduce some new testcases for r6 with FPXX/FP64.
	Introduce new testcase: comdat-reloc-r6.

	Skip `default` in mips_arch_list_matching if triple is mipsisa*, due to:
	  1)it will cannot match mipsr6@*.d: since mips32rN/mips64rN
	    will always be used, it won't be a problem.
	  2)some test think -march=mips64rN will alway true for mipsisa64rN,
	    which is not true now.

	This patch fix testsuite for all r6-default gnu triples:
	  mipsisa32r6-linux-gnu
	  mipsisa32r6el-linux-gnu
	  mips-img-linux-gnu
	  mipsel-img-linux-gnu
	  mipsisa64r6-linux-gnu
	  mipsisa64r6el-linux-gnu

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: default r6 if vendor is img
	This behavior is used by downstream toolchain since 2014.
	We also set the default ABI for mips*-img-elf to O32.
	The previous value is NO_ABI, which is not good default ABI.

	We don't support mips64*-img* due to GCC doesn't support it,
	and We believe that the multilib should be used for this case.

2023-06-05  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit
	When configure with triples mipsisa[32,64]rN[el,], the march value
	is pinned to a fix value if not given explicitly. for example
	   1) mipsisa32r6-linux-gnu -n32 xx.s will complains that:
	      -march=mips32r6 is not compatible with the selected ABI
	   2) mipsisa64r2el-linux-gnu -o32 generates objects with 64bit CPU:
	      ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
	They are not good default behaviors: Let's alter the CPU info

	Since we are using these triples as a regular linux distributions,
	let's alter march according to ABI.

2023-06-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb] Fix typos
	Fix a few typos:
	- implemention -> implementation
	- convertion(s) -> conversion(s)
	- backlashes -> backslashes
	- signoring -> ignoring
	- (un)ambigious -> (un)ambiguous
	- occured -> occurred
	- hidding -> hiding
	- temporarilly -> temporarily
	- immediatelly -> immediately
	- sillyness -> silliness
	- similiar -> similar
	- porkuser -> pokeuser
	- thats -> that
	- alway -> always
	- supercede -> supersede
	- accomodate -> accommodate
	- aquire -> acquire
	- priveleged -> privileged
	- priviliged -> privileged
	- priviledges -> privileges
	- privilige -> privilege
	- recieve -> receive
	- (p)refered -> (p)referred
	- succesfully -> successfully
	- successfuly -> successfully
	- responsability -> responsibility
	- wether -> whether
	- wich -> which
	- disasbleable -> disableable
	- descriminant -> discriminant
	- construcstor -> constructor
	- underlaying -> underlying
	- underyling -> underlying
	- structureal -> structural
	- appearences -> appearances
	- terciarily -> tertiarily
	- resgisters -> registers
	- reacheable -> reachable
	- likelyhood -> likelihood
	- intepreter -> interpreter
	- disassemly -> disassembly
	- covnersion -> conversion
	- conviently -> conveniently
	- atttribute -> attribute
	- struction -> struct
	- resonable -> reasonable
	- popupated -> populated
	- namespaxe -> namespace
	- intialize -> initialize
	- identifer(s) -> identifier(s)
	- expection -> exception
	- exectuted -> executed
	- dungerous -> dangerous
	- dissapear -> disappear
	- completly -> completely
	- (inter)changable -> (inter)changeable
	- beakpoint -> breakpoint
	- automativ -> automatic
	- alocating -> allocating
	- agressive -> aggressive
	- writting -> writing
	- reguires -> requires
	- registed -> registered
	- recuding -> reducing
	- opeartor -> operator
	- ommitted -> omitted
	- modifing -> modifying
	- intances -> instances
	- imbedded -> embedded
	- gdbaarch -> gdbarch
	- exection -> execution
	- direcive -> directive
	- demanged -> demangled
	- decidely -> decidedly
	- argments -> arguments
	- agrument -> argument
	- amespace -> namespace
	- targtet -> target
	- supress(ed) -> suppress(ed)
	- startum -> stratum
	- squence -> sequence
	- prompty -> prompt
	- overlow -> overflow
	- memember -> member
	- languge -> language
	- geneate -> generate
	- funcion -> function
	- exising -> existing
	- dinking -> syncing
	- destroh -> destroy
	- clenaed -> cleaned
	- changep -> changedp (name of variable)
	- arround -> around
	- aproach -> approach
	- whould -> would
	- symobl -> symbol
	- recuse -> recurse
	- outter -> outer
	- freeds -> frees
	- contex -> context

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix typo in debug message
	In microblaze_analyze_prologue in gdb/microblaze-tdep.c I came across:
	...
		  microblaze_debug ("got addi r1,r1,%d; contnuing\n", imm);
	...

	Fix this by using "continuing".

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix doc string of valpy_const_value
	In gdb/python/py-value.c, in the value_object_methods array I noticed:
	...
	  { "const_value", valpy_const_value, METH_NOARGS,
	    "Return a 'const' qualied version of the same value." },
	...

	Fix the qualied -> qualified typo.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/guile] Fix doc string for value-optimized-out?
	In gdb/guile/scm-value.c, I noticed in the value_functions array initializer:
	...
	  { "value-optimized-out?", 1, 0, 0,
	    as_a_scm_t_subr (gdbscm_value_optimized_out_p),
	    "\
	Return #t if the value has been optimizd out." },
	...
	There's a typo in the doc string.

	Fix this by using "optimized".

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix help text of show tui tab-width
	I noticed:
	...
	(gdb) help show tui tab-width
	Show the tab witdh, in characters, for the TUI.
	This variable controls how many spaces are used to display a tab character.
	...
	a typo: "witdh".

	Fix this by using "width" instead.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Fix help text of maint info target-sections
	I noticed a typo:
	...
	(gdb) help maint info target-sections
	List GDB's internal section table.

	Print the current targets section list.  This is a sub-set of all
	sections, from all objects currently loaded.  Usually the ALLOC
	sectoins.
	...

	Fix this by using "sections".

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Fix help text of maint set ignore-prologue-end-flag
	I noticed here:
	...
	(gdb) help maint set ignore-prologue-end-flag
	Set if the PROLOGUE-END flag is ignored.
	The PROLOGUE-END flag from the line-table entries is used to place \
	  breakpoints past the prologue of functions.  Disabeling its use use forces \
	  the use of prologue scanners.
	...
	a typo in "Disabeling" and accidental word repetition "use use".

	Fix by replacing with "Disabling" and "use".

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/compile] Fix typo in debug message
	In compile_object_load in gdb/compile/compile-object-load.c I came across:
	...
				"Connectiong ELF symbol \"%s\" to the .toc section (%s)\n",
	...

	Fix this typo by using "Connecting" instead.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdbserver] Fix typo in debug message
	I noticed in emit_ops_insns in gdbserver/linux-aarch64-low.cc:
	...
	  threads_debug_printf ("Adding %d instrucions at %s",
	...

	Fix the typo by using "instructions" instead.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Tom de Vries  <tdevries@suse.de>

	[gdb/ada] Fix argument name misspelling
	Two functions use the argument name bounds_prefered_p.

	This misspells "preferred".

	Fix this by using bounds_preferred_p instead.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-06-03  Alan Modra  <amodra@gmail.com>

	Re: loongarch readelf support
	Another segfault.

		* readelf.c (target_specific_reloc_handling): Sanity check
		loongarch reloc r_offset.

2023-06-03  Alan Modra  <amodra@gmail.com>

	Re: More ecoff sanity checks
	Yet another fuzzer fix.

		* ecoff.c (ecoff_slurp_symbolic_header <FIX>): Zero counts when
		associated pointer is zero.
		(_bfd_ecoff_slurp_symbolic_info): Remove now unnecessary check.

2023-06-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-02  Luis Machado  <luis.machado@arm.com>

	[AArch64] Fix architecture debug version constant thinkos
	Caught this during emulator testing.

	Fix the constants. They should be 0xa and 0xb as opposed to 0x10 and
	0x11.  There was a thinko while defining them.

	Obvious enough.

	Tested on aarch64-linux Ubuntu 20.04/22.04.

2023-06-02  Alan Modra  <amodra@gmail.com>

	Re: bfd_close and target free_cached_memory
	_bfd_delete_bfd can be called early, before the target xvec is set up.

		* opncls.c (_bfd_delete_bfd): Don't segfault on NULL xvec.

2023-06-02  Alan Modra  <amodra@gmail.com>

	Re: More ecoff sanity checks
	Another fix for fuzzed object files, exhibiting as a segfault in
	nm.c filter_symbols when accessing a symbol name.

		* ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check
		fdr_ptr->issBase, and tighten sym.iss check.

2023-06-02  Alan Modra  <amodra@gmail.com>

	loongarch readelf support
	This fixes two buffer overflows found by fuzzers.

		* readelf.c (target_specific_reloc_handling): Sanity check
		loongarch reloc symbol index.  Don't apply reloc after errors.
		Reduce translation work of "invalid symbol index" error message.

2023-06-02  Alan Modra  <amodra@gmail.com>

	Minor objcopy optimisation for copy_relocations_in_section
		* objcopy (copy_relocations_in_section): Don't read the relocs
		for STRIP_ALL if keep_specific_htab is empty.

2023-06-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-06-01  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: avoid using magic number
	Define a new constant for the maximum number of stack offsets handled in
	libsframe, and use it.  Note that the SFrame format does not define such
	a constant (limit).  This is an implmentation-defined constant in
	libsframe.

	include/
		* sframe-api.h (MAX_NUM_STACK_OFFSETS): New definition.
	libsframe/
		* sframe.c (sframe_fre_sanity_check_p): Use it.

2023-06-01  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: minor fixups in flip_fre related functions
	libsframe/
		* sframe.c (flip_fre_start_address): Remove unnecessary type
		cast.  Use uint16_t instead of unsigned short.
		(flip_fre_stack_offsets): Likewise.

2023-06-01  Jim Wilson  <jimw@sifive.com>

	RISC-V: PR30449, Add lga assembler macro support.
	Originally discussion, https://github.com/riscv/riscv-isa-manual/pull/539

	Added new load address pseudo instruction which is always expanded to GOT
	access, no matter the .option rvc is set or not.

	gas/
		PR 30449
		* config/tc-riscv.c (macro): Add M_LGA support.
		* testsuite/gas/riscv/la-variants.d: New.
		* testsuite/gas/riscv/la-variants.s: New.
	include/
		PR 30449
		* opcode/riscv.h (M_LGA): New.
	opcodes/
		PR 30449
		* riscv-opc.c (riscv_opcodes): Add lga support.

2023-06-01  Nelson Chu  <nelson@rivosinc.com>

	[PR ld/22263][PR ld/24676] RISC-V: Avoid spurious R_RISCV_NONE for TLS GD/IE.
	For TLS GD/IE, add the same condition with the relocate_section in the
	allocate_dynrelocs, to make sure we won't reserve redundant spaces
	for dynamic relocations since the conservative estimatation.

	After applying this patch, ld seems no longer generate the spurious
	R_RISCV_NONE for pr22263-1 test, and the test in pr24676.

	bfd/
		PR ld/22263
		PR ld/24676
		* elfnn-riscv.c (RISCV_TLS_GD_IE_NEED_DYN_RELOC): New defined.
		Set NEED_RELOC to true if TLS GD/IE needs dynamic relocations,
		and INDX will be the dynamic index.
		(allocate_dynrelocs): Don't reserve extra spaces in the rela.got
		if RISCV_TLS_GD_IE_NEED_DYN_RELOC set need_reloc to false.  This
		condition needs to be same as relocate_section.
		(relocate_section): Likewise, use the same condition as
		allocate_dynrelocs.

2023-06-01  Alan Modra  <amodra@gmail.com>

	Harden PowerPC64 OPD handling against fuzzers
	PowerPC64 ELFv1 object files should have at most one .opd section, and
	OPD handling in elf64-ppc.c makes use of this fact by caching some
	.opd section info in the per-object bfd.tdata.  This was done to avoid
	another word in the target specific section data.  Of course, fuzzers
	don't respect the ABI, and even non-malicious users can accidentally
	create multiple .opd sections.  So it is better to avoid possible
	buffer overflows and other confusion when OPD handling for a second
	.opd section references data for the first .opd section, by keeping
	the data per-section.

	The patch also fixes a memory leak, and a corner case where I think we
	could hit an assertion in opd_entry_value or read out of bounds in
	ppc64_elf_branch_reloc doing a final link producing non-ppc64 output.
	(It's a really rare corner case because not only would you need to be
	linking ppc64 objects to non-ppc64 output, you'd also need a branch
	reloc symbol to be defined in a .opd section of a non-ppc64 input.)

		* elf64-ppc.c (is_ppc64_elf): Move earlier in file.
		(ppc64_elf_branch_reloc): Check symbol bfd before accessing
		ppc64 elf specific data structures.
		(struct ppc64_elf_obj_tdata): Move opd union..
		(struct _ppc64_elf_section_data): ..to here.
		(ppc64_elf_before_check_relocs): Allow for opd sec_type
		already set to sec_opd.
		(ppc64_elf_check_relocs): Only set sec_type to sec_toc when
		unset.  Error for unexpected toc relocs.
		(opd_entry_value): Return -1 when non-ppc64 rather than
		asserting.  Check and set sec_type too.  Adjust for changed
		location of contents and relocs.
		(ppc64_elf_relocate_section): Adjust for changed location of
		cached .opd relocs.
		(ppc64_elf_free_cached_info): New function.
		(bfd_elf64_bfd_free_cached_info): Define.

2023-06-01  Alan Modra  <amodra@gmail.com>

	bfd_close and target free_cached_memory
	bfd_free_cached_info is used in just one place in archive.c, which
	means most times we reach bfd_close the function isn't called.  On the
	other hand, if bfd_free_cached_info is called we can't do much on the
	bfd since it loses all its obj_alloc memory.  This restricts what can
	be done in a target _close_and_cleanup.  In particular you can't look
	at sections, which leads to duplication of code in target
	close_and_cleanup and free_cached_info, eg. elfnn-aarch64.c.

		* opncls.c (_bfd_delete_bfd): Call bfd_free_cached_info.
		* elfnn-aarch64.c (elfNN_aarch64_close_and_cleanup): Delete.
		(bfd_elfNN_close_and_cleanup): Don't define.
		* som.c (som_bfd_free_cached_info): Don't call
		_bfd_generic_close_and_cleanup here.
		(som_close_and_cleanup): Define as _bfd_generic_close_and_cleanup.

2023-06-01  Alan Modra  <amodra@gmail.com>

	section_by_target_index memory leak
	The rs6000 backend can call coff_section_from_bfd_index from its
	object_p function via coff_set_alignment_hook.  If the object doesn't
	match, or another target matches too, then the hash table needs to be
	freed via a cleanup.

		* coffgen.c (coff_object_cleanup): New function.
		(coff_real_object_p): Return coff_object_cleanup, and call on
		failure path.  Move declaration to..
		* libcoff-in.h: ..here.
		(coff_object_cleanup): Declare.
		* coff-stgo32.c (go32exe_cleanup): Call coff_object_cleanup.
		(go32exe_check_format): Adjust assertion.
		* libcoff.h: Regenerate.

2023-06-01  Alan Modra  <amodra@gmail.com>

	Remove BFD_FAIL in cpu-sh.c
	The assertions in cpu-sh.c can be triggered by passing bogus values
	in disassemble_info.mach.  This doesn't cause any bfd misbehaviour.

		* cpu-sh.c (sh_get_arch_from_bfd_mach): Remove BFD_FAIL.
		(sh_get_arch_up_from_bfd_mach): Likewise.

2023-06-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Fix -Wsign-compare warning
	gprofng/ChangeLog
	2023-05-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30490
		* src/LoadObject.cc: Fix -Wsign-compare warning.

2023-05-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 29470 The test suite should be made more flexible
	I add two new targets (check-extra, check-install) for gprofng testing:
	  `make check` runs sanity testing for gprofng and takes ~30 secunds.
	  `make check-extra` runs all gprofng tests and takes ~20 minutus.
	  `make check-install` runs all gprofng tests and uses gprofng installation.

	On aarch64, there are unwind problems in libgp-collector.so.
	I set ACCT_FILTER to temporarily ignore problematic functions.

	gprofng/ChangeLog
	2023-05-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/29470
		* Makefile.am: Add check-extra, check-install.
		* Makefile.in: Rebuild
		* testsuite/config/default.exp: Set the GPROFNG variable.
		* testsuite/gprofng.display/display.exp: Updated the test list.
		* testsuite/gprofng.display/jsynprog/Intface.java: Correct copyright.
		* testsuite/gprofng.display/jsynprog/Launcher.java: Likewise.
		* testsuite/gprofng.display/jsynprog/Makefile: Likewise.
		* testsuite/gprofng.display/jsynprog/Routine.java: Likewise.
		* testsuite/gprofng.display/jsynprog/Sub_Routine.java: Likewise.
		* testsuite/gprofng.display/jsynprog/cloop.cc: Likewise.
		* testsuite/gprofng.display/jsynprog/jsynprog.h: Likewise.
		* testsuite/gprofng.display/jsynprog/jsynprog.java: Correct copyright.
		Add the -j option to run the selected functions.
		* testsuite/gprofng.display/synprog/check_results.pl:
		Remove unused environment variable.
		* testsuite/gprofng.display/synprog/synprog.c: Updated DEFAULT_COMMAND.
		* testsuite/lib/Makefile.skel: Apply $(ACCT_FILTER).
		* testsuite/lib/acct.pm: Ignore errors when $(ACCT_FILTER) is set.
		* testsuite/lib/display-lib.exp: Add TARGET_FLAGS in make_args.

2023-05-31  Tom Tromey  <tromey@adacore.com>

	Improve MI -dprintf-insert documentation
	I found the documentation for -dprintf-insert a bit unclear.  It
	didn't mention the possibility of multiple arguments, and I also
	noticed that it implied that the format parameter is optional, which
	it is not.

	While looking into this I also noticed a few comments in the
	implementation that could also be improved.

	Then, I noticed a repeated call to strlen in a loop condition, so I
	fixed this up as well.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-31  Tom Tromey  <tromey@adacore.com>

	Pass correct name to @value in gdb.texinfo
	I noticed a couple instance of this warning when rebuilding the gdb
	info files:

	    warning: undefined flag: GDB

	The problem is that the wrong argument was passed to @value.  This
	patch fixes the problem.

2023-05-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/wrap-line.exp with --disable-tui
	When running the test-case gdb.tui/wrap-line.exp with a build configured with
	--disable-tui, we run into:
	...
	(gdb) PASS: gdb.tui/wrap-line.exp: width-hard-coded: set width 50
	tui new-layout command-layout cmd 1^M
	Undefined command: "tui".  Try "help".^M
	(gdb) ERROR: Undefined command "tui new-layout command-layout cmd 1".
	...

	Fix this by guarding the command with allow_tui_tests.

	Tested on x86_64-linux.

2023-05-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/pr30056.exp for native-extended-gdbserver
	When running test-case gdb.tui/pr30056.exp with target board
	native-extended-gdbserver, I run into:
	...
	Quit^[[K^M^[[B(gdb) PASS: gdb.tui/pr30056.exp: Control-C
	Remote debugging from host ::1, port 38810^M
	^M(failed reverse-i-search)`xyz': ^M(gdb) target extended-remote \
	  localhost:2346^[[7GWARNING: Timed out waiting for EOF in server after \
	  monitor exit
	...

	This is due to the fact that ^C doesn't abort the reverse-i-search.  This
	appears to be due to a readline problem.  A PR is open about this: PR
	cli/30498.

	Add a KFAIL for the PR, and ensure that the isearch is aborted by using ^G,
	such that we have a responsive prompt to handle the "monitor exit" command
	that native-extended-gdbserver issues.

	Tested on x86_64-linux.

2023-05-31  Tristan Gingold  <tgingold@free.fr>

	pe/coff - add support for base64 encoded long section names
	  PR 30444
	  * coffcode.h (coff_write_object_contents): Handle base64 encoding on PE.  Also check for too large string table.
	  * coffgen.c (extract_long_section_name): New function extracted from ... (make_a_section_from_file): ... here.  Add support for base64 long section names. (decode_base64): New function.

2023-05-31  Nick Clifton  <nickc@redhat.com>

	Fix printf formating issues in elfxx-loongarch64.c

2023-05-31  Felix Willgerodt  <felix.willgerodt@intel.com>

	python, btrace: Fix some small formatting issues.
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-31  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix fingerprint for cmd-only layout
	I added a cmd-only layout:
	...
	(gdb) tui new-layout cmd cmd 1
	...
	and set it:
	...
	(gdb) layout cmd
	...
	which gave me the expect result: only the cmd window in the screen.

	However, after going back to layout src:
	...
	(gdb) layout src
	...
	I got a source window with only one line in it, and the cmd window taking most
	of the screen.

	I traced this back to tui_set_layout, where for both the old and the new
	layout the fingerprint of the cmd window in the layout is taken.  If the
	fingerprint is the same, an effort will be done to preserve the command
	window size.

	The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which
	explains the behaviour.

	I think this is essentially a bug in the finger print calculation, and it
	should be "C" for the cmd layout.

	Fix this by not adding a V or H in the fingerprint if the list size is one.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-30  Andrew Burgess  <aburgess@redhat.com>

	gdb: add support for %V to printf command
	This commit adds a new format for the printf and dprintf commands:
	'%V'.  This new format takes any GDB expression and formats it as a
	string, just as GDB would for a 'print' command, e.g.:

	  (gdb) print a1
	  $a = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
	  (gdb) printf "%V\n", a1
	  {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
	  (gdb)

	It is also possible to pass the same options to %V as you might pass
	to the print command, e.g.:

	  (gdb) print -elements 3 -- a1
	  $4 = {2, 4, 6...}
	  (gdb) printf "%V[-elements 3]\n", a1
	  {2, 4, 6...}
	  (gdb)

	This new feature would effectively replace an existing feature of GDB,
	the $_as_string builtin convenience function.  However, the
	$_as_string function has a few problems which this new feature solves:

	1. $_as_string doesn't currently work when the inferior is not
	running, e.g:

	  (gdb) printf "%s", $_as_string(a1)
	  You can't do that without a process to debug.
	  (gdb)

	The reason for this is that $_as_string returns a value object with
	string type.  When we try to print this we call value_as_address,
	which ends up trying to push the string into the inferior's address
	space.

	Clearly we could solve this problem, the string data exists in GDB, so
	there's no reason why we have to push it into the inferior, but this
	is an existing problem that would need solving.

	2. $_as_string suffers from the fact that C degrades arrays to
	pointers, e.g.:

	  (gdb) printf "%s\n", $_as_string(a1)
	  0x404260 <a1>
	  (gdb)

	The implementation of $_as_string is passed a gdb.Value object that is
	a pointer, it doesn't understand that it's actually an array.  Solving
	this would be harder than issue #1 I think.  The whole array to
	pointer transformation is part of our expression evaluation.  And in
	most cases this is exactly what we want.  It's not clear to me how
	we'd (easily) tell GDB that we didn't want this reduction in _some_
	cases.  But I'm sure this is solvable if we really wanted to.

	3. $_as_string is a gdb.Function sub-class, and as such is passed
	gdb.Value objects.  There's no super convenient way to pass formatting
	options to $_as_string.  By this I mean that the new %V feature
	supports print formatting options.  Ideally, we might want to add this
	feature to $_as_string, we might imagine it working something like:

	  (gdb) printf "%s\n", $_as_string(a1,
	                                   elements = 3,
	                                   array_indexes = True)

	where the first item is the value to print, while the remaining
	options are the print formatting options.  However, this relies on
	Python calling syntax, which isn't something that convenience
	functions handle.  We could possibly rely on strictly positional
	arguments, like:

	  (gdb) printf "%s\n", $_as_string(a1, 3, 1)

	But that's clearly terrible as there's far more print formatting
	options, and if you needed to set the 9th option you'd need to fill in
	all the previous options.

	And right now, the only way to pass these options to a gdb.Function is
	to have GDB first convert them all into gdb.Value objects, which is
	really overkill for what we want.

	The new %V format solves all these problems: the string is computed
	and printed entirely on the GDB side, we are able to print arrays as
	actual arrays rather than pointers, and we can pass named format
	arguments.

	Finally, the $_as_string is sold in the manual as allowing users to
	print the string representation of flag enums, so given:

	  enum flags
	    {
	      FLAG_A = (1 << 0),
	      FLAG_B = (1 << 1),
	      FLAG_C = (1 << 1)
	    };

	  enum flags ff = FLAG_B;

	We can:

	  (gdb) printf "%s\n", $_as_string(ff)
	  FLAG_B

	This works just fine with %V too:

	  (gdb) printf "%V\n", ff
	  FLAG_B

	So all functionality of $_as_string is replaced by %V.  I'm not
	proposing to remove $_as_string, there might be users currently
	depending on it, but I am proposing that we don't push $_as_string in
	the documentation.

	As %V is a feature of printf, GDB's dprintf breakpoints naturally gain
	access to this feature too.  dprintf breakpoints can be operated in
	three different styles 'gdb' (use GDB's printf), 'call' (call a
	function in the inferior), or 'agent' (perform the dprintf on the
	remote).

	The use of '%V' will work just fine when dprintf-style is 'gdb'.

	When dprintf-style is 'call' the format string and arguments are
	passed to an inferior function (printf by default).  In this case GDB
	doesn't prevent use of '%V', but the documentation makes it clear that
	support for '%V' will depend on the inferior function being called.

	I chose this approach because the current implementation doesn't place
	any restrictions on the format string when operating in 'call' style.
	That is, the user might already be calling a function that supports
	custom print format specifiers (maybe including '%V') so, I claim, it
	would be wrong to block use of '%V' in this case.  The documentation
	does make it clear that users shouldn't expect this to "just work"
	though.

	When dprintf-style is 'agent' then GDB does no support the use of
	'%V' (right now).  This is handled at the point when GDB tries to
	process the format string and send the dprintf command to the remote,
	here's an example:

	  Reading symbols from /tmp/hello.x...
	  (gdb) dprintf call_me, "%V", a1
	  Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
	  (gdb) set sysroot /
	  (gdb) target remote | gdbserver --once - /tmp/hello.x
	  Remote debugging using | gdbserver --once - /tmp/hello.x
	  stdin/stdout redirected
	  Process /tmp/hello.x created; pid = 3088822
	  Remote debugging using stdio
	  Reading symbols from /lib64/ld-linux-x86-64.so.2...
	  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) set dprintf-style agent
	  (gdb) c
	  Continuing.
	  Unrecognized format specifier 'V' in printf
	  Command aborted.
	  (gdb)

	This is exactly how GDB would handle any other invalid format
	specifier, for example:

	  Reading symbols from /tmp/hello.x...
	  (gdb) dprintf call_me, "%Q", a1
	  Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
	  (gdb) set sysroot /
	  (gdb) target remote | gdbserver --once - /tmp/hello.x
	  Remote debugging using | gdbserver --once - /tmp/hello.x
	  stdin/stdout redirected
	  Process /tmp/hello.x created; pid = 3089193
	  Remote debugging using stdio
	  Reading symbols from /lib64/ld-linux-x86-64.so.2...
	  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) set dprintf-style agent
	  (gdb) c
	  Continuing.
	  Unrecognized format specifier 'Q' in printf
	  Command aborted.
	  (gdb)

	The error message isn't the greatest, but improving that can be put
	off for another day I hope.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Acked-By: Simon Marchi <simon.marchi@efficios.com>

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_memory_changed method
	Same idea as previous patches, but for memory_changed.

	Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_param_changed method
	Same idea as previous patches, but for command_param_changed.

	Change-Id: I7c2196343423360da05f016f8ffa871c064092bb

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_breakpoint_modified method
	Same idea as previous patches, but for breakpoint_modified.

	Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_breakpoint_deleted method
	Same idea as previous patches, but for breakpoint_deleted.

	Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_breakpoint_created method
	Same idea as previous patches, but for breakpoint_created.

	Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_tsv_modified method
	Same idea as previous patches, but for tsv_modified.

	Change-Id: I55454a2386d5450040b3a353909b26f389a43682

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_tsv_deleted method
	Same idea as previous patches, but for tsv_deleted.

	Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_tsv_created method
	Same idea as previous patches, but for tsv_created.

	Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_traceframe_changed method
	Same idea as previous patches, but for traceframe_changed.

	Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_about_to_proceed method
	Same idea as previous patches, but for about_to_proceed.  We only need
	(and want, as far as the mi_interp implementation is concerned) to
	notify the interpreter that caused the proceed.

	Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_solib_unloaded method
	Same idea as previous patches, but for solib_unloaded.

	Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_solib_loaded method
	Same idea as previous patches, but for solib_loaded

	Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_target_resumed method
	Same idea as previous patches, but for target_resumed.

	Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_record_changed method
	Same idea as previous patches, but for record_changed

	Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_inferior_removed method
	Same idea as previous patches, but for inferior_removed.

	Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_inferior_disappeared method
	Same idea as previous patches, but for inferior_disappeared.

	For symmetry with on_inferior_appeared, I named this one
	on_inferior_disappeared, despite the observer being called
	inferior_exit.  This is called when detaching an inferior, so I think
	that calling it "disappeared" is a bit less misleading (the observer
	should probably be renamed later).

	Change-Id: I372101586bc9454997953c1e540a2a6685f53ef6

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_inferior_appeared method
	Same idea as previous patches, but for inferior_appeared.

	Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_inferior_added method
	Same idea as previous patches, but for inferior_added.

	mi_interp::init avoided using mi_inferior_added, since, as the comment
	used to say, it would notify all MI interpreters.  Now, it's easy to
	only notify the new interpreter, so it's possible to just call the
	on_inferior_added method in mi_interp::init.

	Change-Id: I0eddbd5367217d1c982516982089913019ef309f

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_thread_exited method
	Same idea as previous patches, but for thread_exited.

	Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_new_thread method
	Same idea as previous patches, but for new_thread.

	Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_user_selected_context_changed method
	Same as previous patches, but for user_selected_context_changed.

	Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_command_error method
	Same idea as the previous patches, but for command_error.

	Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_sync_execution_done method
	Same as previous patches, but for sync_execution_done.  Except that
	here, we only want to notify the interpreter that is executing the
	command, not all interpreters.

	Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_no_history method
	Same as previous patches, but for no_history.

	Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_exited method
	Same as previous patch, but for exited.  Remove the exited observable,
	since nothing uses it anymore, and we don't have anything coming that
	will use it.

	Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_signal_exited method
	Same as previous patch, but for signal_exited.  Remove the signal_exited
	observable, since nothing uses it anymore, and we don't have anything
	coming that will use it.

	Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_normal_stop method
	Same idea as the previous patch, but for the normal_stop event.

	Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863

2023-05-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add interp::on_signal_received method
	Instead of having the interpreter code registering observers for the
	signal_received observable, add a "signal_received" virtual method to
	struct interp.  Add a interps_notify_signal_received function that loops
	over all UIs and calls the signal_received method on the interpreter.
	Finally, add a notify_signal_received function that calls
	interps_notify_signal_received and then notifies the observers.  Replace
	all existing notifications to the signal_received observers with calls
	to notify_signal_received.

	Before this patch, the CLI and MI code both register a signal_received
	observer.  These observer go over all UIs, and, for those that have a
	interpreter of the right kind, print the stop notifiation.

	After this patch, we have just one "loop over all UIs", inside
	interps_notify_signal_received.  Since the interp::on_signal_received
	method gets called once for each interpreter, the implementations only
	need to deal with the current interpreter (the "this" pointer).

	The motivation for this patch comes from a future patch, that makes the
	amdgpu code register an observer to print a warning after the CLI's
	signal stop message.  Since the amdgpu and the CLI code both use
	observers, the order of the two messages is not stable, unless we define
	the priority using the observer dependency system.  However, the
	approach of using virtual methods on the interpreters seems like a good
	change anyway, I think it's more straightforward and simple to
	understand than the current solution that uses observers.  We are sure
	that the amdgpu message gets printed after the CLI message, since
	observers are notified after interpreters.

	Keep the signal_received, even if nothing uses if, because we will be
	using it in the upcoming amdgpu patch implementing the warning described
	above.

	Change-Id: I4d8614bb8f6e0717f4bfc2a59abded3702f23ac4

2023-05-30  Tom de Vries  <tdevries@suse.de>

	[gdb] Mention --with/without-system-readline for --configuration
	Simon reported that the new test-case gdb.tui/pr30056.exp fails with system
	readline.

	This is because the test-case requires a fix in readline that's present in our
	in-repo copy of readline, but most likely not in any system readline yet.

	Fix this by:
	- mentioning --with-system-readline or --without-system-readline in the
	  configuration string.
	- adding a new proc with_system_readline that makes this information available
	  in the testsuite.
	- using this in test-case gdb.tui/pr30056.exp to declare it unsupported for
	  --with-system-readline.

	Tested on x86_64-linux.

	Reported-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-05-30  Nick Clifton  <nickc@redhat.com>

	Slight wording improvement for the -Ur documentation

	Improve header information displayed with objdump -P for PE binaries.
	  * od-pe.c (targ_info): New array.
	  (get_target_specific_info): New function.
	  (decode_machine_number): Retire.  Use get_target_specific_info instead.
	  (is_pe_object_magic): Likewise.
	  (dump_pe_file_header): Display more information.
	  Rework layout to be similar to that from 'objdump -p'.
	  Add code to handle larger than normnal AOUT headers.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: ld: Add support for linker relaxation.
	Add ld relax support and testsuits.

	ld/ChangeLog:

		* emultempl/loongarchelf.em: Regenerated.
		* testsuite/ld-elf/compressed1d.d: Xfail loongarch*-*.
		* testsuite/ld-elf/pr26936.d: Likewise.
		* testsuite/ld-loongarch-elf/disas-jirl.d: Regenerated.
		* testsuite/ld-loongarch-elf/disas-jirl-32.d: Regenerated.
		* testsuite/ld-loongarch-elf/jmp_op.d: Likewise.
		* testsuite/ld-loongarch-elf/macro_op.d: Likewise.
		* testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
		* testsuite/ld-loongarch-elf/relax-align.dd: New test.
		* testsuite/ld-loongarch-elf/relax-align.s: New test.
		* testsuite/ld-loongarch-elf/relax.exp: New test.
		* testsuite/ld-loongarch-elf/relax.s: New test.
		* testsuite/ld-loongarch-elf/uleb128.dd: New test.
		* testsuite/ld-loongarch-elf/uleb128.s: New test.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: gas: Add support for linker relaxation.
	Add gas -mrelax and -mno-relax option.
	Add R_LARCH_RELAX reloc for instrction if it can be relaxed.
	ADD R_LARCH_ALIGN reloc for align pseudo instruction because relax.
	Add ADD/SUB reloc pair for debug and exception data to calculate symbol
	substraction because relax.

	gas/ChangeLog:

		* config/tc-loongarch.c:
		(struct loongarch_cl_insn): New macro_id member.
		(enum options): New OPTION_RELAX and OPTION_NO_RELAX.
		(struct option): New mrelax and mno-relax.
		(md_parse_option): Likewise.
		(get_internal_label):
		(loongarch_args_parser_can_match_arg_helper): Generate relax reloc.
		(move_insn): Set fx_frag and fx_where if exist.
		(append_fixp_and_insn): Call frag_wane and frag_new for linker relax
		relocs.
		(loongarch_assemble_INSNs): New loongarch_cl_insn pointer parameter.
		(md_assemble): Fix function call.
		(fix_reloc_insn): Likewise.
		(md_apply_fix): Generate ADD/SUB reloc pair for debug and exception
		data.
		(loongarch_fix_adjustable): Delete.
		(md_convert_frag): Generate new fix.
		(loongarch_pre_output_hook): New function.
		(loongarch_make_nops): Likewise.
		(loongarch_frag_align_code): Likewise.
		(loongarch_insert_uleb128_fixes): Likewise.
		(loongarch_md_finish): Likewise.
		* config/tc-loongarch.h
		(md_allow_local_subtract): New macro define.
		(loongarch_frag_align_code): New declare.
		(md_do_align): Likewise.
		(loongarch_fix_adjustable): Delete.
		(tc_fix_adjustable): New macro define.
		(TC_FORCE_RELOCATION_SUB_SAME): Likewise.
		(TC_LINKRELAX_FIXUP): Likewise.
		(TC_FORCE_RELOCATION_LOCAL): Likewise.
		(DWARF2_USE_FIXED_ADVANCE_PC): Likewise.
		(MD_APPLY_SYM_VALUE): Likewise.
		(tc_symbol_new_hook): New extern.
		(NOP_OPCODE): Delete.
		(loongarch_pre_output_hook): New macro define.
		(md_pre_output_hook): Likewise.
		(md_finish): Likewise.
		(loongarch_md_finish): New extern.
		* testsuite/gas/all/align.d: Mark as unsupported on LoongArch.
		* testsuite/gas/all/gas.exp: Xfail loongarch*-*.
		* testsuite/gas/all/relax.d: Likewise.
		* testsuite/gas/elf/dwarf-5-irp.d: Likewise.
		* testsuite/gas/elf/dwarf-5-loc0.d: Likewise.
		* testsuite/gas/elf/dwarf-5-macro-include.d: Likewise.
		* testsuite/gas/elf/dwarf-5-macro.d: Likewise.
		* testsuite/gas/elf/dwarf2-11.d: Likewise.
		* testsuite/gas/elf/dwarf2-15.d: Likewise.
		* testsuite/gas/elf/dwarf2-16.d: Likewise.
		* testsuite/gas/elf/dwarf2-17.d: Likewise.
		* testsuite/gas/elf/dwarf2-18.d: Likewise.
		* testsuite/gas/elf/dwarf2-19.d: Likewise.
		* testsuite/gas/elf/dwarf2-5.d: Likewise.
		* testsuite/gas/elf/ehopt0.d: Likewise.
		* testsuite/gas/elf/elf.exp: Likewise.
		* testsuite/gas/elf/section11.d: Likewise.
		* testsuite/gas/lns/lns.exp: Likewise.
		* testsuite/gas/loongarch/jmp_op.d: Regenerated.
		* testsuite/gas/loongarch/li.d: Likewise.
		* testsuite/gas/loongarch/macro_op.d: Likewise.
		* testsuite/gas/loongarch/macro_op_32.d: Likewise.
		* testsuite/gas/loongarch/macro_op_large_abs.d: Likewise.
		* testsuite/gas/loongarch/macro_op_large_pc.d: Likewise.
		* testsuite/gas/loongarch/relax_align.d: New test.
		* testsuite/gas/loongarch/relax_align.s: New test.
		* testsuite/gas/loongarch/uleb128.d: New test.
		* testsuite/gas/loongarch/uleb128.s: New test.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: binutils: Add support for linker relaxation.
	Add support for relocs related to relax to readelf.

	binutils/ChangeLog:

		* readelf.c (target_specific_reloc_handling): Handle ULEB128 reloc.
		(is_32bit_inplace_add_reloc): Handle new reloc.
		(is_32bit_inplace_sub_reloc): Likewise.
		(is_64bit_inplace_add_reloc): Likewise.
		(is_64bit_inplace_sub_reloc): Likewise.
		(is_16bit_inplace_add_reloc): Likewise.
		(is_16bit_inplace_sub_reloc): Likewise.
		(is_8bit_inplace_add_reloc): Likewise.
		(is_8bit_inplace_sub_reloc): Likewise.
		(is_6bit_inplace_sub_reloc): Likewise.
		(is_6bit_inplace_add_reloc): New function.
		(apply_relocations): Handle new reloc.
		* testsuite/binutils-all/readelf.exp: Add -mno-relax option
		for LoongArch.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: opcodes: Add support for linker relaxation.
	Set gas default to enable relax.

	opcodes/ChangeLog:

		* loongarch-opc.c (struct loongarch_ASEs_option): New member relax
		with the default value 1.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: bfd: Add support for linker relaxation.
	Add relax support and related relocs in bfd.

	bfd/ChangeLog:

		* bfd-in2.h: Add relocs related to relax.
		* elfnn-loongarch.c (struct loongarch_elf_link_hash_table): New integer
		pointer (data_segment_phase) to monitor the data segment phase.
		(loongarch_elf_check_relocs): Swap B21/B26 reloc sequence.
		(loongarch_elf_adjust_dynamic_symbol): Fix code format.
		(loongarch_reloc_rewrite_imm_insn): Fix function call.
		(perform_relocation): Handle new relocs related to relax.
		(RELOCATE_CALC_PC32_HI20): Fix code format.
		(RELOCATE_CALC_PC64_HI32): Likewise.
		(loongarch_elf_relocate_section): Handle new relocs related to relax.
		(loongarch_relax_delete_bytes): New function.
		(loongarch_relax_pcala_addi): Likewise.
		(loongarch_relax_pcala_ld): Likewise.
		(bfd_elfNN_loongarch_set_data_segment_info): Likewise.
		(loongarch_relax_align): Likewise.
		(loongarch_elf_relax_section): Likewise.
		(bfd_elfNN_bfd_relax_section): New macro define.
		* elfxx-loongarch.c (reloc_bits): New bfd point parameter.
		(reloc_bits_b16): Likewise.
		(reloc_bits_b21): Likewise.
		(reloc_bits_b26): Likewise.
		(loongarch_adjust_reloc_bitsfield): Likewise.
		(reloc_bits_pcrel20_s2): New function.
		(loongarch_elf_add_sub_reloc): Likewise.
		(loongarch_elf_add_sub_reloc_uleb128): Likewise.
		(loongarch_write_unsigned_leb128): New function.
		* elfxx-loongarch.h (loongarch_adjust_reloc_bitsfield): New bfd point
		parameter.
		(bfd_elf32_loongarch_set_data_segment_info): New declare.
		(bfd_elf64_loongarch_set_data_segment_info): Likewise.
		(loongarch_write_unsigned_leb128): Likewise.
		* libbfd.h: Add relocs related to relax.
		* reloc.c: Add relocs related to relax.

2023-05-30  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: include: Add support for linker relaxation.
	Add relocs and gas LARCH_opts.relax option.

	include/ChangeLog:

		* elf/loongarch.h: Add relocs.
		* opcode/loongarch.h: Add LARCH_opts.relax and macro LARCH_NOP.

2023-05-30  Nick Clifton  <nickc@redhat.com>

	Add support for an ARMMAGIC value of 0xa00 to the PE dumper.

2023-05-30  Alan Modra  <amodra@gmail.com>

	arm-pe objdump -P
	arm-pe looks to be a very old PE implementation, incompatible with
	current arm-wince-pe.  arm-pe has different relocations and uses
	ARMMAGIC which has this comment: "I just made this up".  Well, OK, I
	don't know the history but it was probably before Microsoft "just made
	up" their constants for ARM windows CE.

	This patch supports objdump -P for arm-pe, and another magic constant
	that may appear in object files.  (I don't think binutils generates
	files using ARMV7PEMAGIC aka IMAGE_FILE_MACHINE_ARMNT.)

		* od-pe.c (is_pe_object_magic): Handle IMAGE_FILE_MACHINE_ARMNT
		and ARMMAGIC.

2023-05-30  Alan Modra  <amodra@gmail.com>

	Define IMAGE_FILE_MACHINE_ARMNT
	Same value as ARMV7PEMAGIC.
	https://learn.microsoft.com/en-us/windows/win32/sysinfo/image-file-machine-constants

		* coff/pe.h (IMAGE_FILE_MACHINE_ARMNT): Define.

2023-05-30  Alan Modra  <amodra@gmail.com>

	Don't define COFF_MAGIC
	This macro was unused apart from aout/encap.h, which has been deleted.

		* config/tc-arm.h (COFF_MAGIC): Don't define.
		* config/tc-sh.h (COFF_MAGIC): Don't define.
		* config/tc-z80.h (COFF_MAGIC): Don't define.
		* config/tc-z8k.h (COFF_MAGIC): Don't define.

2023-05-30  Alan Modra  <amodra@gmail.com>

	Delete include/aout/encap.h
	This file is unused and as the header comment says, obsolete.

	Regen binutils POTFILES.in
	for od-pe.c

2023-05-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix linefeed scrolling in tuiterm
	I came across a bug in the implementation of line feed in tuiterm, and added a
	unit test that exposes it.

	Before sending the line feed we have:
	...
	Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 3):
	    0 abcdefgh
	    1 ijklmnop
	    2 qrstuvwx
	    3 yz01234
	...
	and after it we have:
	...
	Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 1):
	    0 ijklmnop
	    1 qrstuvwx
	    2 yz01234
	    3 yz01234
	...

	Note how the cursor started at row 3 and after the line feed ended up at
	row 1, while it should have stayed in row 3.

	Fix this by moving "incr _cur_row -1" one level up in the loop nest in
	proc _ctl_0x0a.

	Tested on x86_64-linux.

2023-05-29  Simon Marchi  <simon.marchi@efficios.com>

	gdb/mi: fix ^running record with multiple MI interpreters
	I stumbled on the mi_proceeded and running_result_record_printed
	globals, which are shared by all MI interpreter instances (it's unlikely
	that people use multiple MI interpreter instances, but it's possible).
	After poking at it, I found this bug:

	1. Start GDB in MI mode
	2. Add a second MI interpreter with the new-ui command
	3. Use -exec-run on the second interpreter

	This is the output I get on the first interpreter:

	    =thread-group-added,id="i1"
	    ~"Reading symbols from a.out...\n"
	    ~"New UI allocated\n"
	    (gdb)
	    =thread-group-started,id="i1",pid="94718"
	    =thread-created,id="1",group-id="i1"
	    ^running
	    *running,thread-id="all"

	And this is the output I get on the second intepreter:

	    =thread-group-added,id="i1"
	    (gdb)
	    -exec-run
	    =thread-group-started,id="i1",pid="94718"
	    =thread-created,id="1",group-id="i1"
	    *running,thread-id="all"

	The problem here is that the `^running` reply to the -exec-run command
	is printed on the wrong UI.  It is printed on the first one, it should
	be printed on the second (the one on which we sent the -exec-run).

	What happens under the hood is that captured_mi_execute_command, while
	executing a command for the second intepreter, clears the
	running_result_record_printed and mi_proceeded globals.
	mi_about_to_proceed then sets mi_proceeded.  Then, mi_on_resume_1 gets
	called for the first intepreter first.  Since the

	    !running_result_record_printed && mi_proceeded

	condition is true, it prints a ^running, and sets
	running_result_record_printed.  When mi_on_resume_1 gets called for the
	second interpreter, running_result_record_printed is already set, so
	^running is not printed there.

	It took me a while to understand the relationship between these two
	variables.  I think that in the end, this is what we want to track:

	 1. When executing an MI command, take note if that command causes a
	    "proceed".  This is done in mi_about_to_proceed.
	 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want
	    to output a ^running record.  And we want to remember that we did,
	    because...
	 3. Back in captured_mi_execute_command, if we did not output a
	    ^running, we want to output a ^done.

	Moving those two variables to the mi_interp struture appears to fix it.
	Only for the interpreter doing the -exec-run command does the
	running_result_record_printed flag get cleared, and therefore only or
	that one does the ^running record get printed.

	Add a new test for this, that does pretty much what the reproducer above
	shows.  Without the fix, the test fails because
	mi_send_resuming_command_raw never sees the ^running record.

	Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b
	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

2023-05-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-28  Tom de Vries  <tdevries@suse.de>

	[readline] Fix double free in _rl_scxt_dispose
	Consider the following scenario.  We start gdb in TUI mode:
	...
	$ gdb -q -tui
	...
	and type ^R which gives us the reverse-isearch prompt in the cmd window:
	...
	(reverse-i-search)`':
	...
	and then type "foo", right-arrow-key, and ^C.

	In TUI mode, gdb uses a custom rl_getc_function tui_getc.

	When pressing the right-arrow-key, tui_getc:
	- attempts to scroll the TUI src window, without any effect, and
	- returns 0.

	The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char:
	...
	  /* We intercepted the control character, so return 0 (which readline
	     will interpret as a no-op).  */
	  return 0;
	...

	However, after this 0 is returned by the rl_read_key () call in
	_rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets
	0 as the first part of an utf-8 multibyte char, and tries to read the next
	char.

	In this state, the ^C takes effect and we run into a double free because
	_rl_isearch_cleanup is called twice.

	Both these issues need fixing independently, though after fixing the first we
	no longer trigger the second.

	The first issue is caused by the subtle difference between:
	- a char array containing 0 chars, which is zero-terminated, and
	- a char array containing 1 char, which is zero.

	In mbrtowc terms, this is the difference between:
	...
	  mbrtowc (&wc, "", 0, &ps);
	...
	which returns -2, and:
	...
	  mbrtowc (&wc, "", 1, &ps);
	...
	which returns 0.

	Note that _rl_read_mbstring calls _rl_get_char_len without passing it an
	explicit length parameter, and consequently it cannot distinguish between the
	two, and defaults to the "0 chars" choice.

	Note that the same problem doesn't exist in _rl_read_mbchar.

	Fix this by defaulting to the "1 char" choice in _rl_get_char_len:
	...
	-  if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src))
	+  if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src))
	...

	The second problem happens when the call to _rl_search_getchar in
	_rl_isearch_callback returns.  At that point _rl_isearch_cleanup has already
	been called from the signal handler, but we proceed regardless, using a cxt
	pointer that has been freed.

	Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to
	_rl_search_getchar:
	...
	   c = _rl_search_getchar (cxt);
	+  if (!RL_ISSTATE (RL_STATE_ISEARCH))
	+    return 1;
	...

	Tested on x86_64-linux.

	Approved-By: Chet Ramey <chet.ramey@case.edu>

	PR tui/30056
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056

2023-05-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-27  Nelson Chu  <nelson@nelson.ba.rivosinc.com>

	[PR ld/22263][PR ld/25694] RISC-V: Avoid dynamic TLS relocs in PIE.
	Lots of targets already fixed the TEXTREL problem for TLS in PIE.

	* For PR ld/25694,
	In the check_reloc, refer to spare and loongarch, they don't need to reserve
	any local dynamic reloc for TLS LE in pie/pde, and similar to other targets.
	So it seems like riscv was too conservative to estimate the TLS LE before.
	Just break and don't goto static_reloc for TLS LE in pie/pde can fix the
	TEXTREL problem.

	* For PR ld/22263,
	The risc-v code for TLS GD/IE in the relocate_section seems same as MIPS port.
	So similar to MIPS, pr22570, commits 9143e72c6d4d and 1cb83cac9a89, it seems
	also the right way to do the same thing for risc-v.

	On risc-v, fixes
	FAIL: Build pr22263-1

	RISC-V haven't supported the TLS transitions, so will need the same fix (use
	bfd_link_dll) in the future.

	bfd/
		PR ld/22263
		PR ld/25694
		* elfnn-riscv.c (riscv_elf_check_relocs): Replace bfd_link_pic with
		bfd_link_dll for TLS IE.  Don't need to reserve the local dynamic
		relocation for TLS LE in pie/pde, and report error in pic just like
		before.
		(riscv_elf_relocate_section): For TLS GD/IE, use bfd_link_dll rather
		than !bfd_link_pic in determining the dynamic symbol index.  Avoid
		the index of -1.

2023-05-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-26  Nick Clifton  <nickc@redhat.com>

	Enhance objdump's --private option so that it can display the contents of PE format files.
	  * od-pe.c: New file: Dumps fields in PE format headers.
	  * configure.ac (od_vectors): Add objdump_private_desc_pe for PE format targets. (od_files): Add od-pe for PE format targets.
	  * configure: Regenerate.
	  * Makefile.am (CFILES): Add od-pe.c (EXTRA_objdump_SOURCE): Likewise.
	  * Makefile.in: Generate.
	  * NEWS: Mention the new feature.
	  * doc/binutils.texi: Document the new support.
	  * objdump.c (wide_output): Change from local to global.
	  * objdump.h (wide_output): Prototype. (objdump_private_desc_pe): Prototype.
	  * testsuite/binutils-all/objdump.exp: Add a test of the new feature.

2023-05-26  Andreas Schwab  <schwab@linux-m68k.org>

	Remove duplicate definition
		* coff/pe.h (IMAGE_FILE_MACHINE_AMD64): Remove duplicate
		definition.  Alphabetize.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	x86: fix disassembler build after 1a3b4f90bc5f
	In commit 1a3b4f90bc5f ("x86: convert two pointers to (indexing)
	integers") I neglected the fact that compilers may warn about comparing
	ptrdiff_t (signed long) with size_t (unsigned long) values. Since just
	before we've checked that the value is positive, simply add a cast
	(despite my dislike for casts).

2023-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add test-case gdb.tui/color-prompt.exp
	Add a test-case that sets a prompt with color in TUI.

	The line containing the prompt is shown by get_line_with_attrs as follows:
	...
	<fg:31>(gdb) <fg:default>
	...

	The 31 means red, but only for foreground colors, for background colors 41
	means red.

	Make this more readable by using color names for both foreground and
	background, such that we have instead:
	....
	<fg:red>(gdb) <fg:default>
	...

	Tested on x86_64-linux.

2023-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add invisible and blinking attributes in tuiterm
	I noticed curses using the invisible and blinking attributes.

	Add these in tuiterm.

	Tested on x86_64-linux.

2023-05-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix reverse attribute in tuiterm
	I noticed in proc Term::_csi_m arguments that while parameters 7 and 27 are
	supposed to set the reverse attribute to 1 and 0, in fact it's set to 1 in
	both cases:
	...
	 		    7 {
				set _attrs(reverse) 1
			    }
	  ...
			    27 {
				set _attrs(reverse) 1
	 		    }
	...

	Fix this and add a regression test in gdb.tui/tuiterm.exp.

	Tested on x86_64-linux.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	iamcu: suppress tests which can't possibly work
	With neither --32 nor --64 passed to gas, advanced features like AVX
	aren't available without explicitly enabling them.

	x86-64: improve gas diagnostic when no 32-bit target is configured
	Make this similar to --64 and --x32: Check whether a suitable target
	exists.

	x86-64: conditionalize tests using --32
	Using this option doesn't really work when no support for any 32-bit
	target was configured in (as is the case for at least cloudabi and
	rdos).

	x86: split gas testsuite .exp file
	The set of 32-bit-only and 64-bit-only tests has grown quite large. In
	particular when one's after only the results for the 64-bit set, having
	them live in a separate .exp file is easier / faster.

	x86: convert two pointers to (indexing) integers
	This in particular reduces the number of pointers to non-const that we
	have (and that could potentially be used for undue modification of
	state). As a result, fetch_code()'s 2nd parameter can then also become
	pointer-to-const.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	x86: disassembling over-long insns
	The present way of dealing with them - misusing MAX_MNEM_SIZE, which has
	nothing to do with insn length - leads to inconsistent results. Since we
	allow for up to MAX_CODE_LENGTH - 1 prefix bytes (which then could be
	followed by another MAX_CODE_LENGTH "normal" insn bytes until we're done
	decoding), size the_buffer[] accordingly.

	Move struct dis_private down to be able to use MAX_CODE_LENGTH without
	moving its #define. While doing this also alter the order to have the
	potentially large array last.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	x86: use fixed-width type for codep and friends
	This first of all removes a dependency on bfd_byte and unsigned char
	being the same types. It further eliminates the need to mask by 0xff
	when fetching values (which wasn't done fully consistently anyway),
	improving code legibility.

	While there, where possible add const.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	x86: figure braces aren't really part of mnemonics
	Instead they're separators for pseudo-prefixes. Don't insert them in
	mnemonic_chars[], handling them explicitly in parse_insn() instead. Note
	that this eliminates the need for another separator after a pseudo-
	prefix. While maybe not overly interesting for a following real
	mnemonic, I view this as quite desirable between multiple successive
	pseudo-prefixes (bringing things in line with the other use of figure
	braces in AVX512's zeroing-masking).

	Drop the unused is_mnemonic_char() at this occasion.

2023-05-26  Jan Beulich  <jbeulich@suse.com>

	x86: de-duplicate operand_special_chars[] wrt extra_symbol_chars[]
	Having to add characters to both arrays can easily lead to oversights.
	Consuming extra_symbol_chars[] when populating operand_chars[] also
	allows to drop two special cases in md_begin().

	Constify operand_special_chars[] at this occasion.

2023-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe/doc: minor improvements for readability
	libsframe/
		* sframe-spec.texi: Cosmetic fixes.

2023-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: revisit sframe_find_fre API
	Inspite of implementing a rather simple functionality, this function was
	relatively difficult to follow, and maintain.  Some changes are done now
	to address that - refactor the function and use better names to make it
	more readable.

	The changes to the implementation do not cause any change in the
	contract of the API.

	libsframe/
	        * sframe.c (sframe_fre_get_end_ip_offset): to here...
	        (sframe_find_fre): Refactor some bits from...

2023-05-26  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use const char * consistently for immutable FRE buffers
	libsframe/
	        * sframe.c (sframe_decode_fre): Use const char * datatype when
		handling buffer containing the FREs.
		(sframe_fre_get_end_ip_offset): Likewise.
		(sframe_find_fre): Likewise.
		(sframe_decoder_get_fre): Likewise.

	libsframe: use uint8_t data type for FRE info related stubs
	libsframe/
		* sframe.c: Use uint8_t for FRE offset count and FRE offset
		size.  Use uint8_t for FRE info word as well.

2023-05-26  Alan Modra  <amodra@gmail.com>

	PR22263 ld test
	A number of targets that I test regularly fail the "Build pr22263-1"
	test for various reasons.

	arm-linux-gnueabi: "undefined reference to `__aeabi_read_tp'"
	ia64-linux-gnu: "Explicit stops are ignored in auto mode"
	m68k-linux-gnu: "undefined reference to `__m68k_read_tp'"
	microblaze-linux-gnu: "undefined reference to `__tls_get_addr'"
	nios2-linux-gnu, s390-linux-gnu and sh4-linux-gnu have a tprel reloc in .got
	riscv64-linux-gnu has a dynamic relocation in text

	So only riscv really fails the pr.  The rest fail due to test issues
	or lack of a linker optimisation.  Lack of an optimisation isn't
	really a fail, but it's worth keeping the test to ensure those
	optimisations don't regress.  The xfail targets may not be an
	exhaustive list.  This just tidies test results for those for which I
	have cross compilers installed.

		PR 22263
		* testsuite/ld-elf/tls.exp: Split pr22263 test into two parts,
		one to check for -z text errors, the other to check tprel
		linker optimisation.  Supply needed symbols and assembler flags.
		xfail the linker optimisation on targets known to fail.

2023-05-26  Tom Tromey  <tom@tromey.com>

	Make MI commands const-correct
	I've had this patch for a while now and figured I'd update it and send
	it.  It changes MI commands to use a "const char * const" for their
	argv parameter.

	Regression tested on x86-64 Fedora 36.

	Acked-By: Simon Marchi <simon.marchi@efficios.com>

2023-05-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-25  Ciaran Woodward  <ciaranwoodward@xmos.com>

	Fix scoped_value_mark not working with empty value chain
	The scoped_value_mark helper class was setting its internal
	mark value to NULL to indicate that the value chain had already
	been freed to mark.

	However, value_mark() also returns NULL if the value chain is
	empty at the time of call.

	This lead to the situation that if the value chain was empty
	at the time the scoped_value_mark was created, the class
	would not correctly clean up the state when it was destroyed,
	because it believed it had already been freed.

	I noticed this because I was setting a watchpoint very early
	in my debug session, and it was becoming a software watchpoint
	rather than hardware. Running any command that called evaluate()
	beforehand (such as 'x 0') would mean that a hardware watchpoint
	was correctly used. After some careful examination of the
	differences in execution, I noticed that values were being freed
	later in the 'bad case', which lead me to notice the issue with
	scoped_value_mark.

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove breakpoint_pointer_iterator
	Remove the breakpoint_pointer_iterator layer.  Adjust all users of
	all_breakpoints and all_tracepoints to use references instead of
	pointers.

	Change-Id: I376826f812117cee1e6b199c384a10376973af5d
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: make filtered_iterator::operator* return the same thing as underlying iterator
	This is the same idea as the previous patch, but for filtered_iterator.
	Without this patch, I would see this when applying the patch that
	removes reference_to_pointer_iterator from breakpoint_range:

	      CXX    breakpoint.o
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void download_tracepoint_locations()’:
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:11007:41: error: cannot allocate an object of abstract type ‘breakpoint’
	    11007 |   for (breakpoint &b : all_tracepoints ())
	          |                                         ^
	    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
	                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
	                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
	                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
	                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
	      619 | struct breakpoint : public intrusive_list_node<breakpoint>
	          |        ^~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
	      250 | breakpoint::~breakpoint ()
	          | ^~~~~~~~~~

	Change-Id: I05285ff27d21cb0ab80cba392ec4e959167e3cd7
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: make basic_safe_iterator::operator* return the same thing as underlying iterator
	Using the following patch that removes the reference_to_pointer_iterator
	from breakpoint_range, I would get:

	      CXX    breakpoint.o
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’:
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’
	     3030 |   for (breakpoint &b : all_breakpoints_safe ())
	          |                                              ^
	    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
	                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
	                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
	                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
	                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
	      619 | struct breakpoint : public intrusive_list_node<breakpoint>
	          |        ^~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
	      250 | breakpoint::~breakpoint ()
	          | ^~~~~~~~~~

	This is because the operator* method of the basic_safe_iterator iterator
	wrapper returns a value_type.  So, even if the method of the underlying
	iterator (breakpoint_iterator, an intrusive_list iterator) returns a
	`breakpoint &`, the method of the wrapper returns a `breakpoint`.

	I think it would make sense for iterator wrappers such as
	basic_safe_iterator to return the exact same thing as the iterator they
	wrap.  At least, it fixes my problem.

	Change-Id: Ibbcd390ac03d2fb6ae4854923750c8d7c3c04e8a
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: link breakpoints with intrusive_list
	Change-Id: I043d8d6f3dd864d80d5088f6ffc2c098337249ea
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove bp_location_pointer_iterator
	Remove the bp_location_pointer_iterator layer.  Adjust all users of
	breakpoint::locations to use references instead of pointers.

	Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use intrusive_list for breakpoint locations
	Replace the hand-maintained linked lists of breakpoint locations with
	and intrusive list.

	 - Remove breakpoint::loc, add breakpoint::m_locations.

	 - Add methods for the various manipulations that need to be done on the
	   location list, while maintaining reasonably good encapsulation.

	 - bp_location currently has a default constructor because of one use
	   in hoist_existing_locations.  hoist_existing_locations now returns a
	   bp_location_list, and doesn't need the default-constructor
	   bp_location anymore, so remove the bp_location default constructor.

	 - I needed to add a call to clear_locations in delete_breakpoint to
	   avoid a use-after-free.

	 - Add a breakpoint::last_loc method, for use in
	   set_breakpoint_condition.

	bp_location_range uses reference_to_pointer_iterator, so that all
	existing callers of breakpoint::locations don't need to change right
	now.  It will be removed in the next patch.

	The rest of the changes are to adapt the call sites to use the new
	methods, of breakpoint::locations, rather than breakpoint::loc directly.

	Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: add missing increment/decrement operators to reference_to_pointer_iterator
	Using the following patch, I would get this build failure:

	      CXX    breakpoint.o
	    In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66,
	                     from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36,
	                     from /usr/include/c++/13.1.1/bits/hashtable.h:35,
	                     from /usr/include/c++/13.1.1/bits/unordered_map.h:33,
	                     from /usr/include/c++/13.1.1/unordered_map:41,
	                     from /usr/include/c++/13.1.1/functional:63,
	                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
	                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206,
	                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:26,
	                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20:
	    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’:
	    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21:   required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’
	    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19:   required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’
	    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19:   required from here
	    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’)
	      179 |           --__i;
	          |           ^~~~~

	This points out that while intrusive_list_iterator has an operator--,
	the reference_to_pointer_iterator wrapper does not.  I'm not to sure why
	the compiler chooses the overload of __advance that accepts a
	_BidirectionalIterator, given that reference_to_pointer_iterator can't
	be decremented, but adding those operators seems like the right thing to
	do in any case, for completeness.

	Change-Id: I8e2044b6734fadf0f21093047cf35bb7080dbdc3
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add breakpoint::first_loc methods
	Add convenience first_loc methods to struct breakpoint (const and
	non-const overloads).  A subsequent patch changes the list of locations
	to be an intrusive_list and makes the actual list private, so these
	spots would need to change from:

	    b->loc

	to something ugly like:

	    *b->locations ().begin ()

	That would make the code much heavier and not readable.  There is a
	surprisingly big number of places that access the first location of
	breakpoints.  Whether this is correct, or these spots fail to consider
	the possibility of multi-location breakpoints, I don't know.  But
	anyhow, I think that using this instead:

	 b->first_loc ()

	conveys the intention better than the other two forms.

	Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add breakpoint "has locations" methods
	Add three convenience methods to struct breakpoint:

	 - has_locations: returns true if the breakpoint has at least one
	   location
	 - has_single_location: returns true if the breakpoint has exactly one
	   location
	 - has_multiple_locations: returns true if the breakpoint has more than
	   one location

	A subsequent patch changes the list of breakpoints to be an
	intrusive_list, so all these spots would need to change.  But in any
	case, I think that this:

	  if (b->has_multiple_locations ())

	conveys the intention better than:

	  if (b->loc != nullptr && b->loc->next != nullptr)

	Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: constify breakpoint::print_it parameter
	The print_it method itself is const.  In a subsequent patch, the
	locations that come out of a const breakpoint will be const as well.  It
	will therefore be needed to make the last_loc output parameter const as
	well.  Make that change now to reduce the size of the following patches.

	Change-Id: I7ed962950bc9582646e31e2e42beca2a1c9c5105
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make some breakpoint methods use `this`
	Some implementations of breakpoint::check_status and
	breakpoint::print_it do this:

	    struct breakpoint *b = bs->breakpoint_at;

	bs->breakpoint_at is always the same as `this` (we can get convinced by
	looking at the call sites of check_status and print_it), so it would
	just be clearer to access fields through `this` instead.

	Change-Id: Ic542a64fcd88e31ae2aad6feff1da278c7086891
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Simon Marchi  <simon.marchi@efficios.com>

	gdb: get gdbarch from syscall_catchpoint instead of location
	I noticed some methods of syscall_catchpoint doing this:

	  struct gdbarch *gdbarch = loc->owner->gdbarch;

	`loc` is the list of locations of this catchpoint.  Logically, the owner
	the locations are this catchpoint.  So this just ends up getting
	this->gdbarch.  Remove the unnecessary indirection through the loc.

	syscall_catchpoint::print_recreate does something slightly different,
	getting its arch from the loc:

	  struct gdbarch *gdbarch = loc->gdbarch;

	I suppose it's always going to be the same arch, so get it from the
	catchpoint there too.

	Change-Id: I6f6a6f8e0cd7cfb754cecfb6249e71ec12ba4855
	Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-25  Alan Modra  <amodra@gmail.com>

	PR29189, dlltool delaylibs corrupt float/double arguments
		PR 29189
		* dlltool.c (i386_x64_trampoline): Save and restore xmm0-5.  Make
		use of parameter save area for integer arg regs.  Comment.

2023-05-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-24  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: add support for references to checked_static_cast
	Add a checked_static_cast overload that works with references.  A bad
	dynamic cast with references throws std::bad_cast, it would be possible
	to implement the new overload based on that, but it seemed simpler to
	just piggy back off the existing function.

	I found some potential uses of this new overload in amd-dbgapi-target.c,
	update them to illustrate the use of the new overload.  To build
	amd-dbgapi-target.c, on needs the amd-dbgapi library, which I don't
	expect many people to have.  But I have it, and it builds fine here.  I
	did test the new overload by making a purposely bad cast and it did
	catch it.

	Change-Id: Id6b6a7db09fe3b4aa43cddb60575ff5f46761e96
	Reviewed-By: Lancelot SIX <lsix@lancelotsix.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-24  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix race in gdb.server/multi-ui-errors.exp
	After this commit:

	  commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd
	  Date:   Thu Mar 9 10:45:03 2023 +0100

	      [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target

	I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
	which looked like this:

	  (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
	  interrupt
	  (gdb)
	  Program received signal SIGINT, Interrupt.
	  0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
	  FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
	  PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
	  p server_pid
	  $1 = 718174
	  (gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid

	This is triggered by this code in gdb.server/multi-ui-errors.exp:

	    gdb_test "interrupt"

	    gdb_test_multiple "" "interrupt arrived" {
		-re "Program received signal SIGINT, Interrupt\\.\r\n" {
		    pass $gdb_test_name
		}
	    }

	The problem here is that the first interrupt will trigger the prompt
	to be printed, and then, after some time the inferior will be
	interrupted.

	However the default pattern for gdb_test includes a '$' end anchor.
	If expect sees the prompt with nothing following it then everything is
	fine, and the test passes.

	However, if the interrupt is quick and so what expect sees is this:

	  (gdb)
	  Program received signal SIGINT, Interrupt.
	  0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6

	In this case the end anchor means that the gdb_test fails to match,
	and eventually times out.

	Fix this by passing -no-prompt-anchor to gdb_test.

	Reviewed-By: Tom de Vries <tdevries@suse.de>

2023-05-24  Matti Puputti  <matti.puputti@intel.com>

	gdb, infcmd: Support jump command with same line in multiple symtabs
	If a header file defining a static function is included in multiple source
	files, each calling the function, and GDB is asked to jump to a line inside
	that function, there would be multiple locations matching the target.  The
	solution in this commit is to select the location in the current symtab.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-05-24  Tom Tromey  <tromey@adacore.com>

	Add "args" and "env" parameters to DAP launch request
	This patch augments the DAP launch request with some optional new
	parameters that let the client control the command-line arguments and
	the environment of the inferior.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-24  Tom Tromey  <tromey@adacore.com>

	Add attributes and methods to gdb.Inferior
	This adds two new attributes and three new methods to gdb.Inferior.

	The attributes let Python code see the command-line arguments and the
	name of "main".  Argument setting is also supported.

	The methods let Python code manipulate the inferior's environment
	variables.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-24  Andreas Schwab  <schwab@suse.de>

	Remove accidentally added file

2023-05-24  Alan Modra  <amodra@gmail.com>

	Don't optimise bfd_seek to same position
	It's not worth avoiding an fseek to the same position, and can cause
	problems if the linker's output file (which is opened "w+") is read,
	because that can result in writing, reading, then writing again.

	POSIX.1-2017 (IEEE Std 1003.1) says of fopen:
	"When a file is opened with update mode ('+' as the second or third
	character in the mode argument), both input and output may be
	performed on the associated stream. However, the application shall
	ensure that output is not directly followed by input without an
	intervening call to fflush() or to a file positioning function
	(fseek(), fsetpos(), or rewind()), and input is not directly followed
	by output without an intervening call to a file positioning function,
	unless the input operation encounters end-of-file."

		* bfdio.c (bfd_seek): Always call iovec->bseek.

2023-05-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-23  Tom Tromey  <tromey@adacore.com>

	Handle DAP evaluate request without a frame ID
	DAP specifies that if an evaluate request does not have a frameID
	parameter, then the expression is evaluated in the global scope.

2023-05-23  Tom Tromey  <tromey@adacore.com>

	Add global_context parameter to gdb.parse_and_eval
	This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
	This lets users request a parse that is done at "global scope".

	I considered letting callers pass in a block instead, with None
	meaning "global" -- but then there didn't seem to be a clean way to
	express the default for this parameter.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-23  Tom Tromey  <tromey@adacore.com>

	Add flags to parse_and_eval
	This adds a flags parameter to parse_and_eval.

	Add PARSER_LEAVE_BLOCK_ALONE flag
	This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API
	to respect it.  This flag lets callers avoid any change to the
	passed-in block and expression PC, letting them specify the context
	exactly.  In particular, now nullptr can be used to indicate that the
	parse should not examine any local variables.

	Add PARSER_DEBUG flag
	This adds a new PARSER_DEBUG constant and changes the parser code to
	use it.  This lets us make the 'parser_debug' global 'static'.

	Rearrange parser_state
	This patch mildly rearranges parser_state, moving all the bool fields
	together.

	Boolify parser_state::comma_terminates
	parser_state::comma_terminates ought to be boolean, and changing it
	does not require any other changes.

	Simplify parser_state constructor
	This simplifies the parser_state constructor by having it accept a
	parser_flags parameter.

	Introduce and use parser flags
	This patch adds a new parser_flags type and changes the parser APIs to
	use it rather than a collection of 'int' and 'bool'.  More flags will
	be added in subsquent patches.

	Move innermost_block_tracker to expression.h
	I think parser-defs.h should hold declarations that can be used by
	parser implementations, whereas expression.h should hold declarations
	that are used by code that wants to call a parser.  Following this
	logic, this patch moves innermost_block_tracker to expression.h.

	Avoid forward declaration in parse.c
	This minorly rearranges parse.c to avoid the need for a forward
	declaration.

	Implement DAP loadedSources request
	This implements the DAP loadedSources request, using gdb.execute_mi to
	avoid having to write another custom Python API.

2023-05-23  Tom Tromey  <tromey@adacore.com>

	Implement gdb.execute_mi
	This adds a new Python function, gdb.execute_mi, that can be used to
	invoke an MI command but get the output as a Python object, rather
	than a string.  This is done by implementing a new ui_out subclass
	that builds a Python object.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-23  Tom Tromey  <tromey@adacore.com>

	Add second mi_parse constructor
	This adds a second mi_parse constructor.  This constructor takes a
	command name and vector of arguments, and does not do any escape
	processing.  This also changes mi_parse::args to handle parse objects
	created this new way.

	Introduce mi_parse helper methods
	This introduces some helper methods for mi_parse that handle some of
	the details of parsing.  This approach lets us reuse them later.

	Introduce "static constructor" for mi_parse
	Change the mi_parse function to be a static method of mi_parse.  This
	lets us remove the 'set_args' setter function.

	Change mi_parse_argv to a method
	This changes mi_parse_argv to be a method of mi_parse.  This is just a
	minor cleanup.

	Use accessor for mi_parse::args
	This changes mi_parse::args to be a private member, retrieved via
	accessor.  It also changes this member to be a std::string.  This
	makes it simpler for a subsequent patch to implement different
	behavior for argument parsing.

	Use member initializers in mi_parse
	This changes mi_parse to use member initializers rather than a
	constructor.  This is easier to follow.

	Use field_signed from Python MI commands
	If an MI command written in Python includes a number in its output,
	currently that is simply emitted as a string.  However, it's
	convenient for a later patch if these are emitted using field_signed.
	This does not make a difference to ordinary MI clients.

2023-05-23  Aaron Merey  <amerey@redhat.com>

	gdb/cli-out.c: clear_current_line shouldn't trigger pagination prompt
	clear_current_line overwrites the current line with chars_per_line
	blank spaces.  Printing the final space triggers a condition in
	pager_file::puts that causes lines_printed to be incremented.  If
	lines_printed becomes greater than or equal to lines_allowed, the
	pagination prompt will appear if enabled.

	In this case the prompt is unnecessary since after printing the final
	space clear_current_line immediately moves the cursor to the beginning
	of the line with '\r'.  A new line isn't actually started, so the prompt
	ends up being spurious.

	Additionally it's possible for gdb to crash during this pagination prompt.
	Answering the prompt with 'q' throws an exception intended to bring gdb
	back to the main event loop.  But since commit 0fea10f32746,
	clear_current_line may be called under the progress_update destructor.
	The exception will try to propagate through the destructor, causing an abort.

	To fix this, pagination is disabled for the duration for clear_current_line.
	clear_current_line is also renamed to clear_progress_notify to help
	indicate that it is a special purpose function intended for use with
	do_progress_notify.

	Acked-by: Eli Zaretskii <eliz@gnu.org>

2023-05-23  Michael Matz  <matz@suse.de>

	PR30437 aarch64: make RELA relocs idempotent
	normally RELA relocs in BFD should not consider the contents of the
	relocated place.  The aarch64 psABI is even stricter, it specifies
	(section 5.7.16) that all RELA relocs _must_ be idempotent.

	Since the inception of the aarch64 BFD backend all the relocs have a
	non-zero src_mask, and hence break this invariant.  It's normally not
	a very visible problem as one can see it only when the relocated place
	already contains a non-zero value, which usually only happens sometimes
	when using 'ld -r' (or as in the testcase when jumping through hoops to
	generate the relocations).  Or with alternative toolchains that do encode
	stuff in the relocated places with the assumption that a relocation
	to that place ignores whatever is there (as they can according to
	the psABI).

	Golang is such a toolchain and https://github.com/golang/go/issues/39927
	is ultimately caused by this problem: the testcase testGCData failing
	is caused by the garbage collection data-structure to describe a type
	containing pointers to be wrong.  It's wrong because a field that's
	supposed to contain a file-relative offset (to some gcbits) has a
	relocation applied and that relocation has an addend which also is
	already part of the go-produced object file (so the addend is
	implicitely applied twice).

	bfd/
		PR ld/30437
		* elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
		if all relocation descriptors.

	ld/
		* testsuite/ld-aarch64/rela-idempotent.s: New testcase.
		* testsuite/ld-aarch64/rela-idempotent.d: New.
		* testsuite/ld-aarch64/aarch64-elf.exp: Run it.

2023-05-23  Nick Clifton  <nickc@redhat.com>

	Updated Swedish translation for the opcodes directory

2023-05-23  Bruno Larsen  <blarsen@redhat.com>

	gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.exp
	When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
	machine, the compiled test case would segfault when returning from
	the function can_relocate_call, with a suggestion of a broken stack.
	The example assembly in the commment was the following:

	   f:
	     MOV $1, %[ok]
	     JMP end
	   set_point0:
	     CALL f ; tracepoint here.
	   end:

	And the segmentation fault happening at the final "ret" instruction of
	can_relocate_call.  Looking at the disassembled version of the later
	half of the important function, we see:

	Clang version (f starting at 11a4):
	  00000000000011ae <set_point0>:
	      11ae:       e8 f1 ff ff ff          callq  11a4 <can_relocate_call+0x14>
	      11b3:       89 45 fc                mov    %eax,-0x4(%rbp)
	      11b6:       83 7d fc 01             cmpl   $0x1,-0x4(%rbp)
	      11ba:       0f 85 0a 00 00 00       jne    11ca <set_point0+0x1c>
	      11c0:       e8 5b 00 00 00          callq  1220 <pass>
	      11c5:       e9 05 00 00 00          jmpq   11cf <set_point0+0x21>
	      11ca:       e8 61 00 00 00          callq  1230 <fail>
	      11cf:       48 83 c4 10             add    $0x10,%rsp
	      11d3:       5d                      pop    %rbp
	      11d4:       c3                      retq
	      11d5:       66 66 2e 0f 1f 84 00    data16 nopw %cs:0x0(%rax,%rax,1)
	      11dc:       00 00 00 00

	gcc version (f starting at 401125):
	  000000000040112c <set_point0>:
	    40112c:       e8 f4 ff ff ff          callq  401125 <can_relocate_call+0x11>
	    401131:       89 45 fc                mov    %eax,-0x4(%rbp)
	    401134:       83 7d fc 01             cmpl   $0x1,-0x4(%rbp)
	    401138:       75 07                   jne    401141 <set_point0+0x15>
	    40113a:       e8 c7 ff ff ff          callq  401106 <pass>
	    40113f:       eb 05                   jmp    401146 <set_point0+0x1a>
	    401141:       e8 c7 ff ff ff          callq  40110d <fail>
	    401146:       90                      nop
	    401147:       c9                      leaveq
	    401148:       c3                      retq

	The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
	difference: GCC's version uses the leaveq instruction, which resets rsp
	based on rbp, while clang adds the same constant to rsp that it
	subtracted in the prologue.  Clang fails because the return address that
	is added by the "call f" instruction isn't accounted for.

	This commit fixes that by adding a return instruction to f, which leaves
	the rsp as the compilers would expect.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-05-23  Jan Beulich  <jbeulich@suse.com>

	x86/Intel: address quoted-symbol related FIXMEs
	If in a "word ptr <address>" or alike construct the "ptr" part is
	double-quoted, it shouldn't be recognized as the specific keyword we're
	looking for (just like we don't recognize double-quoted operator or
	register names anymore). Be careful though to tell closing from opening
	double-quotes, as a quoted symbol may follow right afterwards.

2023-05-23  Jan Beulich  <jbeulich@suse.com>

	x86: don't recognize quoted symbol names as registers or operators
	The concept of quoted symbols names was introduced pretty late. Utilize
	it to allow access to symbols with names matching that of a register (or,
	in Intel syntax, also an identifier-like operator).

	This is primarily to aid gcc when generating Intel syntax output; see
	their bug target/53929.

2023-05-23  Zhang, Jun  <jun.zhang@intel.com>

	Support Intel FRED LKGS
	gas/ChangeLog:

		* NEWS: Support Intel FRED LKGS.
		* config/tc-i386.c: Add fred lkgs
		* doc/c-i386.texi: Document .fred, .lkgs.
		* testsuite/gas/i386/i386.exp: Add FRED LKGS tests
		* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-fred.d: Ditto.
		* testsuite/gas/i386/x86-64-fred.s: Ditto.
		* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
		* testsuite/gas/i386/x86-64-lkgs.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c: New entry for fred, lkgs.
		* i386-gen.c: Add CPU_FRED CPU_LKGS.
		* i386-init.h : Regenerated.
		* i386-mnem.h : Regenerated.
		* i386-opc.h: Add fred, lkgs.
		* i386-opc.tbl: Add FRED, LKGS instructions.
		* i386-tbl.h: Regenerated.

2023-05-23  liuhongt  <hongtao.liu@intel.com>

	Revert "Support Intel FRED LKGS"
	This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.

2023-05-23  Zhang, Jun  <jun.zhang@intel.com>

	Support Intel FRED LKGS
	gas/ChangeLog:

	        * NEWS: Support Intel FRED LKGS.
	        * config/tc-i386.c: Add fred lkgs
	        * doc/c-i386.texi: Document .fred, .lkgs.
	        * testsuite/gas/i386/i386.exp: Add FRED LKGS tests
	        * testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
	        * testsuite/gas/i386/x86-64-fred.d: Ditto.
	        * testsuite/gas/i386/x86-64-fred.s: Ditto.
	        * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
	        * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
	        * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
	        * testsuite/gas/i386/x86-64-lkgs.d: Ditto.
	        * testsuite/gas/i386/x86-64-lkgs.s: Ditto.

	opcodes/ChangeLog:

	        * i386-dis.c: New entry for fred, lkgs.
	        * i386-gen.c: Add CPU_FRED CPU_LKGS.
	        * i386-init.h : Regenerated.
	        * i386-mnem.h : Regenerated.
	        * i386-opc.h: Add fred, lkgs.
	        * i386-opc.tbl: Add FRED, LKGS instructions.
	        * i386-tbl.h: Regenerated.

2023-05-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-22  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix buglet in tui_update_variables
	I noticed a buglet in tui_update_variables:
	...
	   entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
	   if (tui_border_lrcorner != (chtype) entry->value)
	    {
	      tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value;
	...

	When assigning the new value to tui_border_lrcorner, an entry->value of -1 is
	taken into account, but not when comparing to the current value of
	tui_border_lrcorner.

	Fix this by introducing:
	...
	  int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
	...
	and using this in both comparison and assignment.

	Tested on x86_64-linux.

2023-05-22  Tom Tromey  <tromey@adacore.com>

	Remove some FIXME comments from DAP
	I recently added a 'dap' component to bugzilla, and I filed a few bugs
	there.  This patch removes the corresponding FIXME comments.

	A few such comments still exist.  In at least one case, I have a fix
	I'll be submitting eventually; in others I think I need to do a bit of
	investigation to properly file a bug report.

2023-05-22  Richard Bunt  <richard.bunt@linaro.org>

	gdb: add Richard Bunt to gdb/MAINTAINERS

2023-05-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add Term::get_line_with_attrs
	Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that
	annotates a tuiterm line with the active attributes.

	For instance, the line representing the TUI status window with attribute mode
	standout looks like this with Term::get_line:
	...
	exec No process In: ... L??   PC: ??
	...
	but like this with Term::get_line_with_attrs:
	...
	<reverse:1>exec No process In: ... L??   PC: ?? <reverse:0>
	...

	Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses
	Term::get_line_with_attrs instead of Term::get_line.

	Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
	on x86_64-linux.

2023-05-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Factor out Term::_reset_attrs
	Factor out new proc Term::_reset_attrs.

	Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
	on x86_64-linux.

2023-05-22  Alan Modra  <amodra@gmail.com>

	Re: readelf: Support SHT_RELR/DT_RELR for -r
	Revert value of DT_ENCODING to as it was before commit a7fd118627, and
	adjust readelf.

	include/
		* elf/common.h (DT_ENCODING): Set back to 32.
	binutils/
		* readelf.c (struct filedata): Don't size dynamic_info array
		using DT_ENCODING.

2023-05-22  Alan Modra  <amodra@gmail.com>

	PowerPC64 report number of stub iterations
	As a developer it is sometimes useful to know how many times stubs
	have been resized.  Report the count for users too, in ld --stats.

2023-05-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-20  Alan Modra  <amodra@gmail.com>

	Re: Bug 23686, two segment faults in nm
	The fix for pr23686 had a hole in the reloc address sanity check,
	the calculation could overflow.  Note that stabsize is known to be a
	non-zero multiple of 12 so stabsize - 4 can't underflow.

		PR 23686
		* syms.c (_bfd_stab_section_find_nearest_line): Correct
		r->address sanity check.

2023-05-20  Alan Modra  <amodra@gmail.com>

	coffcode.h handle_COMDAT tidy
	I started down the path of attempting to fix
	https://sourceware.org/pipermail/binutils/2023-April/127263.html but
	decided after a while that I didn't want to mess with this code..

	This patch is a just a few things that I thought worth doing, the main
	one being reporting of errors up the call chain.  The while loop to
	for loop change is shamelessly stolen from Oleg.

		* coffcode.h (handle_COMDAT): Return bool.  Make sec_flags a
		flagword*, and adjust to suit.  Replace while loop with for
		loop.  Check isym.n_numaux before reading aux entries.  Alloc
		coff_comdat_info and name in one call to bfd_alloc.  Remove
		goto breakloop.
		(styp_to_sec_flags): Adjust handle_COMDAT call.

2023-05-20  Alan Modra  <amodra@gmail.com>

	tic54x set_arch_mach
	The tic54x backend provides its own coff_set_arch_mach, but wants to
	use the standard coff_set_section_contents.  BFD_JUMP_TABLE_WRITE
	defines both of these functions, so the code also provides a wrapper
	for coff_set_section_contents.  This is all quite OK, but I was on a
	mission to remove unnecessary declarations in coffcode.h, and on
	deleting the one for coff_set_arch_mach ran into a warning about the
	function being unused.  I could have kept that declaration with its
	ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the
	definition but the latter is not usual and looks odd to me.  So I
	had a closer look at tic54x_set_arch_mach and decided the function is
	very likely wrong to allow bfd_arch_unknown.  Thus the backend should
	be using the standard coff_set_arch_mach.

		* coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs.
		(tic54x_coff_set_arch_mach): Delete.
		(tic54x_set_section_contents): Delete.
		* coffcode.h: Delete unnecessary forward declarations.

2023-05-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-19  Tom Tromey  <tromey@adacore.com>

	Update documentation for Python Frame.older and Frame.newer
	I noticed that Frame.older and Frame.newer don't document that they
	return None at the ends of the stack.  This patch updates the
	documentation, and also fixes a somewhat related typo in a comment
	that I noticed while digging into this.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	ld: drop stray blank from ld.texi
	At least older makeinfo complains about it. Also fix an apparent typo
	while touching that line.

2023-05-19  Jan Vrany  <jan.vrany@labware.com>

	gdb: fix post-hook execution for remote targets
	Commit b5661ff2 ("gdb: fix possible use-after-free when
	executing commands") attempted to fix possible use-after-free
	in case command redefines itself.

	Commit 37e5833d ("gdb: fix command lookup in execute_command ()")
	updated the previous fix to handle subcommands as well by using the
	original command string to lookup the command again after its execution.

	This fixed the test in gdb.base/define.exp but it turned out that it
	does not work (at least) for "target remote" and "target extended-remote".

	The problem is that the command buffer P passed to execute_command ()
	gets overwritten in dont_repeat () while executing "target remote"
	command itself:

		#0  dont_repeat () at top.c:822
		#1  0x000055555730982a in target_preopen (from_tty=1) at target.c:2483
		#2  0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0)
		    at remote.c:5946
		#3  0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272
		#4  0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490)
		    at target.c:853
		#5  0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1)
		    at cli/cli-decode.c:2737
		#6  0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688

	Therefore the second call to lookup_cmd () at line 697 fails to find
	command because the original command string is gone.

	This commit addresses this particular problem by creating a *copy* of
	original command string for the sole purpose of using it after command
	execution to lookup the command again. It may not be the most efficient
	way but it's safer given that command buffer is shared and overwritten
	in hard-to-foresee situations.

	Tested on x86_64-linux.

	PR 30249
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249

	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-19  Richard Bunt  <richard.bunt@linaro.org>

	gdb: Remove redundant frame switching
	547ce8f00b fixed an issue where dynamic types were not being resolved
	correctly prior to printing a value. The same issue was discovered when
	printing the value using mi-mode, which was not covered by the fix.
	Porting the fix to the mi-mode code path resolved the issue.

	However, it was discovered that a later patch series, ending
	2fc3b8a4cb8, independently fixed the issue in both the cli- and mi-mode
	code paths, making the original fix unneeded.

	This commit removes this extra frame switch and adds test coverage for
	the mi-mode scenario to protect against any future divergence in this
	area.

	GDB built with GCC 11.

	No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1,
	Intel 22.1; Platforms: x86_64, aarch64.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-19  Andrew Burgess  <aburgess@redhat.com>

	gdb: safety checks in skip_prologue_using_sal
	While working on the previous patch I reverted this commit:

	  commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
	  Date:   Tue Nov 28 16:23:32 2006 +0000

	          * symtab.c (find_pc_sect_line): Do not return a line before
	            the start of a symtab.

	When I re-ran the testsuite I saw some GDB crashes in the tests:

	  gdb.dwarf2/dw2-line-number-zero.exp
	  gdb.dwarf2/dw2-lines.exp
	  gdb.dwarf2/dw2-vendor-extended-opcode.exp

	GDB was reading beyond the end of an array in the function
	skip_prologue_using_sal.

	Now, without the above commit reverted I don't believe that this
	should ever happen.  Reverting the above commit effectively breaks
	GDB's symtab_and_line lookup, we try to find a result for an address,
	and return the wrong symtab and line-table.  In
	skip_prologue_using_sal we then walk the line table looking for an
	appropriate entry, except we never find one, and GDB just keeps going,
	wandering off the end of the array.

	However, I think adding extra protection to prevent walking off the
	end of the array is pretty cheap, and if something does go wrong in
	the future then this should prevent a random crash.

	Obviously, I have no reproducer for this, as I said, I don't think
	this should impact GDB at all, this is just adding a little extra
	caution.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: test for a function with no line table
	This commit adds a test for the following commit:

	  commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
	  Date:   Tue Nov 28 16:23:32 2006 +0000

	              * symtab.c (find_pc_sect_line): Do not return a line before
	              the start of a symtab.

	We have been carrying a test for that commit in the Fedora GDB tree
	since that commit was added to GDB.  I don't know why the test wasn't
	added along with the original commit, but as was written, the test is
	pretty gross, it uses objcopy to pull the .text section from an object
	file, which was then injected into another source file within a .asm
	statement...

	... these days we can just make use of the DWARF assembler to achieve
	the same results, so I've rewritten the test and think it is worth
	adding this to upstream GDB.

	The original patch was about about how we find the best symtab and
	line table entry, and what to do when GDB can't find a good match.

	The new test creates a CU with two functions, only one of which is
	covered by the line table.  With the above patch reverted GDB returns
	an invalid address.

	With the above patch reverted I did run the testsuite to see what
	other tests might already be exercising this functionality, and I
	found two tests:

	  gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
	  gdb.dwarf2/dw2-vendor-extended-opcode.exp

	These are pretty similar, they either create minimal, or no line table
	for one of the functions in the source file, and as a consequence GDB
	returns an unexpected address at some point during the test.

	However, both of those tests are really focused on other issues, so I
	think this new test does add some value.  Plus the new test is not
	large, so it's not a huge cost to also run this new test.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/breakpoint: use warning function instead of gdb_printf
	Noticed that in breakpoint.c, in one place, we do this:

	  gdb_printf (_("warning: Error removing "
	                "breakpoint %d\n"),
	                old_loc->owner->number);

	Instead of using the `warning` function.  There are a number of
	differences between using gdb_printf like this and calling `warning`,
	the main one is probably that real warnings are sent to gdb_stderr,
	while the above gdb_printf call will go to gdb_stdout.

	In this commit I:

	  1. Change to call `warning`, we can drop the "warning: " prefix from
	  the string in breakpoint.c,

	  2. Update the warning text, I now start with a lower case 'e', which
	  I believe is the GDB style for warnings,

	  3. And I have included the address of the bp_location in the warning
	  messsage,

	  4. Finally, I update all the tests (2) that include this error
	  message.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-19  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: handle older Python versions in gdb.python/py-disasm.exp
	It was pointed out on the mailing list that the new tests added in
	this commit:

	  commit 4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1
	  Date:   Tue Jan 24 15:35:45 2023 +0000

	      gdb/python: extend the Python Disassembler API to allow for styling

	will fail when GDB is built with Python 3.6 or earlier.  This is
	because the error that is emitted when a function argument is missing
	changed in Python 3.7, instead of an error like this:

	  Python Exception <class 'TypeError'>: function missing required argument 'style' (pos 1)

	earlier versions of Python emit:

	  Python Exception <class 'TypeError'>: Required argument 'style' (pos 1) not found

	and the new tests didn't allow for this.

	This commit fixes this by allowing either pattern.  I've tested this
	building GDB against Python 3.7.9 and 3.6.15, with this commit all
	tests in gdb.python/py-disasm.exp now pass.

2023-05-19  Kuan-Lin Chen  <rufus@andestech.com>

	RISC-V: Support subtraction of .uleb128.
	https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/96d6e190e9fc04a8517f9ff7fb9aed3e9876cbd6

	There are some known limitations for now,

	* Do not shrink the length of the uleb128 value, even if the value is reduced
	after relaxations.  Also reports error if the length grows up.

	* The R_RISCV_SET_ULEB128 needs to be paired with and be placed before the
	R_RISCV_SUB_ULEB128.

	bfd/
		* bfd-in2.h: Regenerated.
		* elfnn-riscv.c (perform_relocation): Perform R_RISCV_SUB_ULEB128 and
		R_RISCV_SET_ULEB128 relocations.  Do not shrink the length of the
		uleb128 value, and report error if the length grows up.  Called the
		generic functions, _bfd_read_unsigned_leb128 and _bfd_write_unsigned_leb128,
		to encode the uleb128 into the section contents.
		(riscv_elf_relocate_section): Make sure that the R_RISCV_SET_ULEB128
		must be paired with and be placed before the R_RISCV_SUB_ULEB128.
		* elfxx-riscv.c (howto_table): Added R_RISCV_SUB_ULEB128 and
		R_RISCV_SET_ULEB128.
		(riscv_reloc_map): Likewise.
		(riscv_elf_ignore_reloc): New function.
		* libbfd.h: Regenerated.
		* reloc.c (BFD_RELOC_RISCV_SET_ULEB128, BFD_RELOC_RISCV_SUB_ULEB128):
		New relocations to support .uleb128 subtraction.
	gas/
		* config/tc-riscv.c (md_apply_fix): Added BFD_RELOC_RISCV_SET_ULEB128
		and BFD_RELOC_RISCV_SUB_ULEB128.
		(s_riscv_leb128): Updated to allow uleb128 subtraction.
		(riscv_insert_uleb128_fixes): New function, scan uleb128 subtraction
		expressions and insert fixups for them.
		(riscv_md_finish): Called riscv_insert_uleb128_fixes for all sections.
	include/
		* elf/riscv.h ((R_RISCV_SET_ULEB128, (R_RISCV_SUB_ULEB128): Defined.
	ld/
		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
		* testsuite/ld-riscv-elf/uleb128*: New testcase for uleb128 subtraction.
	binutils/
		* testsuite/binutils-all/nm.exp: Updated since RISCV supports .uleb128.

2023-05-19  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Minor improvements for dis-assembler.
	* Extract all private_data initializations into riscv_init_disasm_info, which
	called from print_insn_riscv rather than riscv_disassemble_insn.

	* The disassemble_free_target seems like the right place to release all target
	private_data, also including the internal data structures, like riscv_subsets.
	Therefore, add a new function, disassemble_free_riscv, to release them for safe.

	opcodes/
		* disassemble.c (disassemble_free_target): Called disassemble_free_riscv
		for riscv to release private_data and internal data structures.
		* disassemble.h: Added extern disassemble_free_riscv.
		* riscv-dis.c (riscv_init_disasm_info): New function, used to init
		riscv_private_data.
		(riscv_disassemble_insn): Moved riscv_private_data initializations
		into riscv_init_disasm_info.
		(print_insn_riscv): Called riscv_init_disasm_info to init
		riscv_private_data once time.
		(disassemble_free_riscv): New function, used to free the internal data
		structures, like riscv_subsets.

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	x86: permit all relational operators in insn operands
	Oddly enough == and != were not permitted, because of '=' not having
	been listed in operand_special_chars[].

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	x86: further adjust extend-to-32bit-address conditions
	While a442cac5084e ("ix86: wrap constants") helped address a number of
	inconsistencies between BFD64 and !BFD64 builds, it has also resulted in
	certain bogus uses of constants to no longer be warned about. Leverage
	the md_optimize_expr() hook to adjust when to actually truncate
	expressions to 32 bits - any involvement of binary expressions (which
	would be evaluated in 32 bits only when !BFD64) signals the need for
	doing so. Plain constants (or ones merely subject to unary operators)
	should remain un-truncated - they would be handled as bignums when
	!BFD64, and hence are okay to permit.

	To compensate
	- slightly extend optimize_imm() (to be honest I never understood why
	  the code being added - or something similar - wasn't there in the
	  first place),
	- adjust expectations of the disp-imm-32 testcase (there are now
	  warnings, as there should be for any code which won't build [warning-
	  free] when !BFD64, and Disp8/Imm8 are no longer used in the warned
	  about cases).

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	gas: invoke md_optimize_expr() also for unary expressions
	Give backends a chance to see these, just as they can see binary ones.
	Most of those which use this hook already cope with NULL being passed
	for the left operand (typically because of checking the operator first).
	Adjust the two which don't.

	Take the opportunity and also document the hook.

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	gas: maintain O_constant signedness in more cases
	Unary '~' doesn't really produce an unsigned result. Neither does
	subtraction (unless taking operand values into consideration). And an
	abstract operator applied to two operands which aren't both unsigned
	can't be assumed to yield an unsigned result; exceptions are
	- shifts, where only signedness of the left hand operand matters,
	- comparisons, which - unlike unary '!' - produce signed results (they
	  deliver 0 or ~0, as opposed to '!', which yields 0 or 1),
	- logical operators (yielding 0 or 1 and hence treated like unary '!').

	While doing this (specifically while extending the all/quad testcase),
	update .quad and .8byte documentation: With 64-bit architectures now
	being common, it is highly inappropriate to state that these directives
	unconditionally require bignums.

2023-05-19  Jan Beulich  <jbeulich@suse.com>

	x86: tighten extend-to-32bit-address conditions
	In a442cac5084e ("ix86: wrap constants") I made the truncation condition
	too relaxed: Any indication of a mode that's possible with BFD64 only
	should avoid the truncation. Therefore, like in the other two cases of
	calls to extend_to_32bit_address(), also check whether we're generating
	a 64-bit object.

2023-05-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-18  Tom Tromey  <tromey@adacore.com>

	Use lower-case in @sc in the documentation
	Eli pointed out that @sc only produces small caps for lower case
	letters in its argument, so it's weird to write it using upper-case
	letters.  This patch fixes the instances I found.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-05-18  Simon Marchi  <simon.marchi@efficios.com>

	gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function parameters (PR 30414)
	gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound
	values by reading some output from the inferior.  This is racy when
	running on boards where the inferior I/O is on a separate TTY than
	GDB's, such as native-gdbserver.

	I sometimes see this behavior:

	    (gdb) continue
	    Continuing.

	    Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
	    ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
	    45        print *, ""   ! Test Breakpoint
	    (gdb) Remote debugging from host ::1, port 37496

	     Expected GDB Output:

	    LBOUND = (-8, -10)
	    UBOUND = (-1, -2)
	    APB: Run a test here
	    APB: Expected lbound '(-8, -10)'
	    APB: Expected ubound ''

	What happened is that expect read the output from GDB before the output
	from the inferior, triggering this gdb_test_multiple clause:

	    -re "$gdb_prompt $" {
	        set found_prompt true

	        if {$found_dealloc_breakpoint
	            || ($expected_lbound != "" && $expected_ubound != "")} {
	            # We're done.
	        } else {
	            exp_continue
	        }
	    }

	So it set found_prompt, but the gdb_test_multiple kept going because
	found_dealloc_breakpoint is false (this is the flag indicating that the
	test is finished) and we still don't have expected_lbound and
	expected_ubound.  Then, expect reads in the inferior I/O, triggering
	this clause:

	    -re ".*LBOUND = (\[^\r\n\]+)\r\n" {
	        set expected_lbound $expect_out(1,string)
	        if {!$found_prompt} {
	            exp_continue
	        }
	    }

	This sets expected_lbound, but since found_prompt is true, we don't do
	exp_continue, and exit the gdb_test_multiple, without having an
	expected_ubound.

	Change the test to read the values from the lb and ub function
	parameters instead.  As far as I understand, this still exercises what
	we want to test.  These variables contain the return values of the
	lbound and ubound functions as computed by the program.  We'll use them
	to check the return values of the lbound and ubound functions as
	computed by GDB.

	Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414

2023-05-18  Hui Li  <lihui@loongson.cn>

	gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_
	In the current code, when execute the following test on LoongArch:

	$ make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
	 === gdb Summary ===

	 # of expected passes           111
	 # of unexpected failures       62

	According to IFUNC's working process [1]. first time the IFUNC function
	is called, the dynamic linker will not simply fill the .got.plt entry
	with the actual address of IFUNC symbol, it will call the IFUNC resolver
	function and take the return address, uses it as the sym-bound address
	and puts it in the .got.plt entry. Initial address in .got.plt entry is
	not a real function addresss. Depending on the compiler implementation,
	some different addresses will be filled in. Most architectures will use
	a .plt entry address to fill in the corresponding .got.plt entry.

	In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real
	IFUNC function addresss. First check to see if the real address for
	the IFUNC symbol has been resolved by the following function:

	elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p)
	{
	  if (elf_gnu_ifunc_resolve_by_cache (name, addr_p))
	    return true;

	  if (elf_gnu_ifunc_resolve_by_got (name, addr_p))
	    return true;

	  return false;
	}

	in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the
	.got.plt entry and determines if the contents is the correct address
	by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working
	principle analysis above, the address filled in the .got.plt entry is
	not the actual target function address initially, it would be a .plt
	entry address corresponding symbol like *@plt. In this case, gdb just
	go back to execute the resolver function and puts the return address
	in the .got.plt entry. After that, gdb can get a real ifun address via
	.got.plt entry.

	On LoongArch, initially, each address filled in the .got.plt entries
	is the first .plt entry address. Some architectures such as LoongArch
	define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt
	section. This symbol is the first plt entry, so gdb needs to check
	this symbol in elf_gnu_ifunc_record_cache().

	On LoongArch .got.plt and .plt section as follow:

	$objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0
	...
	0000000120010008 <.got.plt>:
	   120010008:   ffffffff        0xffffffff
	   12001000c:   ffffffff        0xffffffff
	        ...
	   120010018:   20004000        ll.w            $zero, $zero, 64(0x40)
	   12001001c:   00000001        0x00000001
	   120010020:   20004000        ll.w            $zero, $zero, 64(0x40)
	   120010024:   00000001        0x00000001
	   120010028:   20004000        ll.w            $zero, $zero, 64(0x40)
	   12001002c:   00000001        0x00000001
	   120010030:   20004000        ll.w            $zero, $zero, 64(0x40)
	   120010034:   00000001        0x00000001

	...
	Disassembly of section .plt:

	0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>:
	   120004000:   1c00018e        pcaddu12i       $t2, 12(0xc)
	   120004004:   0011bdad        sub.d           $t1, $t1, $t3
	   120004008:   28c021cf        ld.d            $t3, $t2, 8(0x8)
	   12000400c:   02ff51ad        addi.d          $t1, $t1, -44(0xfd4)
	   120004010:   02c021cc        addi.d          $t0, $t2, 8(0x8)
	   120004014:   004505ad        srli.d          $t1, $t1, 0x1
	   120004018:   28c0218c        ld.d            $t0, $t0, 8(0x8)
	   12000401c:   4c0001e0        jirl            $zero, $t3, 0

	0000000120004020 <__libc_start_main@plt>:
	   120004020:   1c00018f        pcaddu12i       $t3, 12(0xc)
	   120004024:   28ffe1ef        ld.d            $t3, $t3, -8(0xff8)
	   120004028:   4c0001ed        jirl            $t1, $t3, 0
	   12000402c:   03400000        andi            $zero, $zero, 0x0

	0000000120004030 <abort@plt>:
	   120004030:   1c00018f        pcaddu12i       $t3, 12(0xc)
	   120004034:   28ffc1ef        ld.d            $t3, $t3, -16(0xff0)
	   120004038:   4c0001ed        jirl            $t1, $t3, 0
	   12000403c:   03400000        andi            $zero, $zero, 0x0

	0000000120004040 <gnu_ifunc@plt>:
	   120004040:   1c00018f        pcaddu12i       $t3, 12(0xc)
	   120004044:   28ffa1ef        ld.d            $t3, $t3, -24(0xfe8)
	   120004048:   4c0001ed        jirl            $t1, $t3, 0
	   12000404c:   03400000        andi            $zero, $zero, 0x0
	...

	With this patch:

	$make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
	=== gdb Summary ===

	 #of expected passes            173

	[1] https://sourceware.org/glibc/wiki/GNU_IFUNC

2023-05-18  Alan Modra  <amodra@gmail.com>

	Re: Add section caches to coff_data_type
	Another thing, section target_index is renumbered in
	coff_compute_section_file_positions and _bfd_xcoff_bfd_final_link.  I
	don't know that there is currently any way that the output bfd
	section_by_target_index could be populated before this point but
	clear them out so no one need worry about it.

		* coffcode.h (coff_compute_section_file_positions): Clear
		section_by_target_index hash table when changing target_index.
		(_bfd_xcoff_bfd_final_link): Likewise.

2023-05-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix whitespace and indentation in lib/tuiterm.exp
	I noticed a trailing whitespace and some indentation errors in lib/tuiterm.exp.

	Fix these.

	Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
	on x86_64-linux.

2023-05-18  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: add tests for sframe_get_funcdesc_with_addr API
	sframe_get_funcdesc_with_addr API is currently used internally by the
	sframe_find_fre ().

	In this test, we create three dummy SFrame FDEs with 4 FREs each.  Then,
	we use few negative tests to lookup FREs with PCs not in the range of
	PCs covered by the FDEs, ensuring graceful return from
	sframe_get_funcdesc_with_addr in all cases.  Some positive tests are
	also added that exercise further scenarios as well.

	libsframe/
		* Makefile.in: Regenerated.
		* testsuite/libsframe.find/find.exp: Include new test.
		* testsuite/libsframe.find/findfunc-1.c: New Test.
		* testsuite/libsframe.find/local.mk: Include new test.

2023-05-18  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: testsuite: add new tests for sframe_find_fre API
	libsframe provides an API to find the FRE associated with a given PC in
	the program.  This patch adds a direct test of this API.

	In this test, we create two dummy SFrame FDEs with 4 FREs each.  Then we
	test that sframe_find_fre () works for the first, second, third and the
	last FRE from one of the FDEs.  Such a test ensures better regression
	testing for the sframe_find_fre () function which is going to be the
	bread and butter of an SFrame based stack tracer.

	libsframe/
		* Makefile.in: Regenerated.
		* testsuite/libsframe.find/find.exp: New test.
		* testsuite/libsframe.find/findfre-1.c: New test.
		* testsuite/libsframe.find/local.mk: Build new test.
		* testsuite/local.mk: Include libsframe.find.

2023-05-18  Alan Modra  <amodra@gmail.com>

	Re: Add section caches to coff_data_type
	Commit 0e759f232b6d regressed these tests:
	rs6000-aix7.2  +FAIL: Garbage collection test 1 (32-bit)
	rs6000-aix7.2  +FAIL: Garbage collection test 1 (64-bit)
	rs6000-aix7.2  +FAIL: Glink test 1 (32-bit)
	rs6000-aix7.2  +FAIL: Glink test 1 (64-bit)

	Investigation showed segfaults in coff_section_from_bfd_index called
	by xcoff_write_global_symbol due to the hash table pointer being
	NULL.  Well, yes, the hash table isn't initialised for the output bfd.
	mkobject_hook is the wrong place to do that.

		* coffcode.h: Revert 0e759f232b6d changes.
		* peicode.h: Likewise.
		* coff-x86_64.c (htab_hash_section_index, htab_eq_section_index):
		Moved here from coffcode.h.
		(coff_amd64_rtype_to_howto): Create section_by_index htab.
		* coffgen.c (htab_hash_section_target_index),
		(htab_eq_section_target_index): Moved here from coffcode.h.
		(coff_section_from_bfd_index): Create section_by_target_index
		htab.  Stash newly created sections in htab.

2023-05-18  Alan Modra  <amodra@gmail.com>

	PR11601, Solaris assembler compatibility doesn't work
	Well, it doesn't work on x86 or ppc, which both have # starting
	comments anywhere on a line.  I think it is therefore only useful on
	sparc.

		PR 11601
		* config/obj-elf.c (obj_elf_section_word): Only compile for sparc.
		(obj_elf_section): Only support solaris .section directive on
		sparc.
		* doc/as.texi (Section): Mention that solaris .section
		directive is only supported for sparc.

2023-05-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-17  Tom Tromey  <tom@tromey.com>

	Special case "&str" in Rust parser
	"&str" is an important type in Rust -- it's the type of string
	literals.  However, the compiler puts it in the DWARF in a funny way.
	The slice itself is present and named "&str".  However, the Rust
	parser doesn't look for types with names like this, but instead tries
	to construct them from components.  In this case it tries to make a
	pointer-to-"str" -- but "str" isn't always available, and in any case
	that wouldn't yield the best result.

	This patch adds a special case for &str.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-17  Luca Bacci  <luca.bacci@outlook.com>

	Decorated symbols in import libs (BUG 30421)
	  PR 30421
	  * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it.
	  * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype.
	  * libcoff.h: Regenerate.

	  * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function.
	  * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function.
	  * pe-dll.c (make_one): Check for decoated symbols.

2023-05-17  Alan Modra  <amodra@gmail.com>

	PR29961, plugin-api.h: "Could not detect architecture endianess"
	Found when attempting to build binutils on sparc sunos-5.8 where
	sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER
	variants.  This patch adds the extra tests to cope with the old
	machine, and tidies the header a little.

		PR 29961
		plugin-api.h: When handling non-gcc or gcc < 4.6.0 include
		necessary header files before testing macros.  Make more use
		of #elif.  Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests.

2023-05-17  Alan Modra  <amodra@gmail.com>

	gcc-4.5 build fixes
	Trying to build binutils with an older gcc currently fails.  Working
	around these gcc bugs is not onerous so let's fix them.

	bfd/
		* elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun
		pointer.
		* elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat"
		variable to "status".
	gas/
		* compress-debug.c (compress_finish): Supply all fields in
		ZSTD_inBuffer initialisation.
	include/
		* xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
		forward declaration.
	opcodes/
		* loongarch-opc.c: Supply all fields of zero struct initialisation
		in various opcode tables.

2023-05-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: include a new function in the right place
	Static function name is not available in stripped libraries.
	In this case, gprofng maps PC to a fake function like <static>@0xPC (<libname>).
	Sometimes gprofng creates two functions instead of one.
	Also FUNC_FLAG_SIMULATED is needed for these fake functions.

	gprofng/ChangeLog
	2023-05-11  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/LoadObject.cc (LoadObject::find_function): Set FUNC_FLAG_SIMULATED.
		Include a new function in the right place.

2023-05-16  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Don't show line number for lines not in source file
	Currently, for a source file containing only 5 lines, we also show line
	numbers 6 and 7 if they're in scope of the source window:
	...
	    0 +-compact-source.c----------------+
	    1 |___3_{                           |
	    2 |___4_  return 0;                 |
	    3 |___5_}                           |
	    4 |___6_                            |
	    5 |___7_                            |
	    6 +---------------------------------+
	...

	Fix this by not showing line numbers not in a source file, such that we have instead:
	...
	    0 +-compact-source.c----------------+
	    1 |___3_{                           |
	    2 |___4_  return 0;                 |
	    3 |___5_}                           |
	    4 |                                 |
	    5 |                                 |
	    6 +---------------------------------+
	...

	Tested on x86_64-linux.

	Suggested-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-16  Nick Clifton  <nickc@redhat.com>

	Document how to use the linker to create a resource only DLL.
	  PR 30359
	  * ld.texi (WIN32): Document how to create a resource only DLL.

2023-05-16  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	Add section caches to coff_data_type
	  * libcoff-in.h (struct coff_tdata): Add section_by_index and section_by_target_index hash tables.
	  * libcoff.h: Regenerate.
	  * coffcode.h (htab_hash_section_index): New function. (htab_eq_section_index): New function. (htab_hash_section_target_index): New function. (htab_eq_section_target_index): New function. (coff_mkobject_hool): Create the hash tables.
	  * peicode.h: Add the same new functions. (pe_mkobject_hook): Create the hash tables.
	  * coff-x86_64.c (coff_amd64_rtype_to_howto): Use the new tables to speed up lookups.
	  * coffgen.c (coff_section_from_bfd_index): Likewise. (_bfd_coff_close_and_cleanup): Delete the hash tables.

2023-05-16  Paul Pluzhnikov  <ppluzhnikov@google.com>

	Update comments for the gdb/24331 fix.
	Approved-by: Andrew Burgess <aburgess@redhat.com>

2023-05-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix formatting of gdb.python/py-disasm.py
	Run black on gdb.python/py-disasm.py file and commit the changes.

2023-05-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: make gdb_supported_languages a caching proc
	Rewrite gdb_supported_languages as a caching proc that actually
	queries GDB for the list of supported languages, rather than just
	containing a hard-coded list of languages.

	There's only one test that uses this proc right now,
	gdb.python/py-function.exp, and that still passes after this change,
	with no changes in the test names.

2023-05-16  Nick Clifton  <nickc@redhat.com>

	-Ur option documentation
	  * ld.texi (-Ur): Clarify the actions of this option.

2023-05-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix regressions in break-main-file-remove-fail.exp
	After this commit:

	  commit a68f7e9844208ad8cd498f89b5100084ece7d0f6
	  Date:   Tue May 9 10:28:42 2023 +0100

	      gdb/testsuite: extend special '^' handling to gdb_test_multiple

	buildbot notified me of a regression on s390 in the test:

	  gdb.base/break-main-file-remove-fail.exp

	the failure looks like this:

	  print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096)
	  warning: Error removing breakpoint 0
	  $2 = 0
	  (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)"

	On the mailing list it has been reported that this failure also
	impacts arm, aarch64, and possibly ppc/ppc64 too.

	The above commit changed get_integer_valueof so that no output is
	expected between the command and the '$2 = 0' line.  In this case the
	'warning: Error removing breakpoint 0' output is causing the
	get_integer_valueof call to fail.

	The reason for this warning is that this test deliberately calls
	munmap on a page of the inferior's code.  The test is checking that
	GDB can handle the situation where a s/w breakpoint can't be
	removed (due to the page no longer being readable/writable).

	The test that is supposed to trigger the warning is later in the test
	script when we delete a breakpoint.

	So why do some targets trigger the warning earlier during the inferior
	call?

	The impacted targets use AT_ENTRY_POINT as their strategy for handling
	inferior calls, that is, the trampoline that calls the inferior
	function is placed at the program's entry point, e.g. often the _start
	label.

	If this location happens to be on the same page as the page that the
	test script unmaps then, when the inferior function call returns, GDB
	will not be able to remove the temporary breakpoint that is inserted
	to catch the inferior function call returning!  As a result we end up
	seeing the warning earlier than expected.

	I did wonder if this means I should relax the pattern in
	get_integer_valueof - just accept that there might be additional
	output from GDB which we should ignore.

	However, I don't think this the right way to go.  With the change in
	a68f7e984420 we are now stricter for GDB emitting additional,
	unexpected, output, and I think that is a good thing.

	So, I think, in this case, in order to handle the possible extra
	output, we should implement something like get_integer_valueof
	directly in the gdb.base/break-main-file-remove-fail.exp test script.
	This local version will handle the possible warning output.

	After this the test should pass again on the impacted targets.

2023-05-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: extend the Python Disassembler API to allow for styling
	This commit extends the Python Disassembler API to allow for styling
	of the instructions.

	Before this commit the Python Disassembler API allowed the user to do
	two things:

	  - They could intercept instruction disassembly requests and return a
	    string of their choosing, this string then became the disassembled
	    instruction, or

	  - They could call builtin_disassemble, which would call back into
	    libopcode to perform the disassembly.  As libopcode printed the
	    instruction GDB would collect these print requests and build a
	    string.  This string was then returned from the builtin_disassemble
	    call, and the user could modify or extend this string as needed.

	Neither of these approaches allowed for, or preserved, disassembler
	styling, which is now available within libopcodes for many of the more
	popular architectures GDB supports.

	This commit aims to fill this gap.  After this commit a user will be
	able to do the following things:

	  - Implement a custom instruction disassembler entirely in Python
	    without calling back into libopcodes, the custom disassembler will
	    be able to return styling information such that GDB will display
	    the instruction fully styled.  All of GDB's existing style
	    settings will affect how instructions coming from the Python
	    disassembler are displayed in the expected manner.

	  - Call builtin_disassemble and receive a result that represents how
	    libopcode would like the instruction styled.  The user can then
	    adjust or extend the disassembled instruction before returning the
	    result to GDB.  Again, the instruction will be styled as expected.

	To achieve this I will add two new classes to GDB,
	DisassemblerTextPart and DisassemblerAddressPart.

	Within builtin_disassemble, instead of capturing the print calls from
	libopcodes and building a single string, we will now create either a
	text part or address part and store these parts in a vector.

	The DisassemblerTextPart will capture a small piece of text along with
	the associated style that should be used to display the text.  This
	corresponds to the disassembler calling
	disassemble_info::fprintf_styled_func, or for disassemblers that don't
	support styling disassemble_info::fprintf_func.

	The DisassemblerAddressPart is used when libopcodes requests that an
	address be printed, and takes care of printing the address and
	associated symbol, this corresponds to the disassembler calling
	disassemble_info::print_address_func.

	These parts are then placed within the DisassemblerResult when
	builtin_disassemble returns.

	Alternatively, the user can directly create parts by calling two new
	methods on the DisassembleInfo class: DisassembleInfo.text_part and
	DisassembleInfo.address_part.

	Having created these parts the user can then pass these parts when
	initializing a new DisassemblerResult object.

	Finally, when we return from Python to gdbpy_print_insn, one way or
	another, the result being returned will have a list of parts.  Back in
	GDB's C++ code we walk the list of parts and call back into GDB's core
	to display the disassembled instruction with the correct styling.

	The new API lives in parallel with the old API.  Any existing code
	that creates a DisassemblerResult using a single string immediately
	creates a single DisassemblerTextPart containing the entire
	instruction and gives this part the default text style.  This is also
	what happens if the user calls builtin_disassemble for an architecture
	that doesn't (yet) support libopcode styling.

	This matches up with what happens when the Python API is not involved,
	an architecture without disassembler styling support uses the old
	libopcodes printing API (the API that doesn't pass style info), and
	GDB just prints everything using the default text style.

	The reason that parts are created by calling methods on
	DisassembleInfo, rather than calling the class constructor directly,
	is DisassemblerAddressPart.  Ideally this part would only hold the
	address which the part represents, but in order to support backwards
	compatibility we need to be able to convert the
	DisassemblerAddressPart into a string.  To do that we need to call
	GDB's internal print_address function, and to do that we need an
	gdbarch.

	What this means is that the DisassemblerAddressPart needs to take a
	gdb.Architecture object at creation time.  The only valid place a user
	can pull this from is from the DisassembleInfo object, so having the
	DisassembleInfo act as a factory ensures that the correct gdbarch is
	passed over each time.  I implemented both solutions (the one
	presented here, and an alternative where parts could be constructed
	directly), and this felt like the cleanest solution.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: rework how the disassembler API reads the result object
	This commit is a refactor ahead of the next change which will make
	disassembler styling available through the Python API.

	Unfortunately, in order to make the styling support available, I think
	the easiest solution is to make a very small change to the existing
	API.

	The current API relies on returning a DisassemblerResult object to
	represent each disassembled instruction.  Currently GDB allows the
	DisassemblerResult class to be sub-classed, which could mean that a
	user tries to override the various attributes that exist on the
	DisassemblerResult object.

	This commit removes this ability, effectively making the
	DisassemblerResult class final.

	Though this is a change to the existing API, I'm hoping this isn't
	going to cause too many issues:

	  - The Python disassembler API was only added in the previous release
	    of GDB, so I don't expect it to be widely used yet, and

	  - It's not clear to me why a user would need to sub-class the
	    DisassemblerResult type, I allowed it in the original patch
	    because at the time I couldn't see any reason to NOT allow it.

	Having prevented sub-classing I can now rework the tail end of the
	gdbpy_print_insn function; instead of pulling the results out of the
	DisassemblerResult object by calling back into Python, I now cast the
	Python object back to its C++ type (disasm_result_object), and access
	the fields directly from there.  In later commits I will be reworking
	the disasm_result_object type in order to hold information about the
	styled disassembler output.

	The tests that dealt with sub-classing DisassemblerResult have been
	removed, and a new test that confirms that DisassemblerResult can't be
	sub-classed has been added.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-15  Tom Tromey  <tom@tromey.com>

	Correctly handle forward DIE references in scanner
	The cooked index scanner has special code to handle forward DIE
	references.  However, a bug report lead to the discovery that this
	code does not work -- the "deferred_entry::spec_offset" field is
	written to but never used, i.e., the lookup is done using the wrong
	key.

	This patch fixes the bug and adds a regression test.

	The test in the bug itself used a thread_local variable, which
	provoked a failure at runtime.  This test instead uses "maint print
	objfiles" and then inspects to ensure that the entry in question has a
	parent.  This lets us avoid a clang dependency in the test.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271

2023-05-15  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix PLT entry generate bug
	If a function symbol only get its address by la.global, without
	directly called by bl instruction, the PLT entry is not required.

	bfd/ChangeLog:

		* elfnn-loongarch.c (loongarch_elf_adjust_dynamic_symbol): Fix PLT
		entry generate bug.

	ld/ChangeLog:

		* testsuite/ld-elf/shared.exp: Clear xfail for LoongArch.

2023-05-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	Fix bad interaction between element limit and repeated values (BZ#24331).
	Currently

	  print -elements=3 -- "AAAAAA"

	prints complete string, which is not what the user asked for.

	Fix two buggy tests exposed by the fix, and add a new test.

	Reviewed-by: Keith Seitz <keiths@redhat.com>

2023-05-13  Alan Modra  <amodra@gmail.com>

	PR28955 mips gas segfault
	Testing for NULL in pic_need_relax fixes the other call to this
	function in md_estimate_size_before_relax.

		PR 28955
		* config/tc-mips.c (mips_frob_file): Move NULL sym test to..
		(pic_need_relax): ..here.

2023-05-13  Alan Modra  <amodra@gmail.com>

	PR28902, -T script with INSERT ordering
	The answer to PR28902 may be deduced from the existing INSERT
	documentation that says the default script is parsed after the -T
	INSERT script, if you assume (correctly) that nothing special is done
	when inserting into -T scripts overriding the default script.  In both
	cases INSERT handling looks for the specified output section later on
	the internal list of parsed script commands.  This isn't obvious
	though, so make the ordering explicit, and mention that section
	assignments are the same too.

		PR 28902
		* ld.texi (INSERT): Specify ordering when -T is used both to
		override the default script and to augment.

2023-05-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-12  Tom Tromey  <tromey@adacore.com>

	Fix regression due to Pragma Import series
	A co-worker here at AdaCore discovered that the Pragma Import series
	caused a rgression.  When debugging gnat1, gdb started asking for
	overload resolution like:

	(gdb) call pp(n)
	Multiple matches for pp
	[0] cancel
	[1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
	[2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511

	This worked before the series, and is strange anyway, because the
	matches refer to the same function.

	This patch adds a test case for this situation and fixes the bug by
	pruning identical functions in remove_extra_symbols.

2023-05-12  Tom Tromey  <tromey@adacore.com>

	Use bool and early loop exit in remove_extra_symbols
	This changes remove_extra_symbols to use bool rather than int, and
	changes the nested loops to exit early when "remove_p" is set.

	Use reference parameter in remove_extra_symbols
	Changing ada-lang.c:remove_extra_symbols to take a reference parameter
	makes the code a bit easier to read, by replacing "(*syms)" with plain
	"syms".

	Handle Ada Pragma Import and Pragma Export
	Ada can import C APIs and also export Ada constructs to C via Pragma
	Import and Pragma Export.  This patch adds support for these to gdb,
	by arranging to either defer some aspects of a symbol to the
	underlying C symbol (for Import) or by introducing a second symbol
	(for Export).  A somewhat tricky approach is needed, both because gdb
	doesn't generally handle symbol aliasing, and because Ada treats
	symbol names in an unusual way (as compared to the rest of gdb).

	Introduce symbol_block_ops::get_block_value
	This adds a new callback to symbol_block_ops.  This callback lets a
	LOC_BLOCK symbol implement its own function to find the underlying
	block.

	Define symbol::value_block separately
	This moves the definition of symbol::value_block outside of the class.
	A subsequent patch will change this method to use SYMBOL_BLOCK_OPS,
	and it seemed simplest to move this method out-of-line, and cleaner to
	do this as a separate change.

	Bump MAX_SYMBOL_IMPLS
	A subsequent patch will introduce more aclass registrations, causing
	the number to go over the current maximum.  This bumps the number.
	Note that there's a separate static assert that ensures that this
	number doesn't get too large for the field size in the symbol.

	Introduce lookup_minimal_symbol_linkage
	This introduces a new function, lookup_minimal_symbol_linkage, and
	refactors a couple other existing functions to call it.  This function
	will be used in a subsequent patch.

2023-05-12  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary call to std::string constructor
	I spotted this explicit call to std::string, which creates an
	unnecessary temporary extra std::string, while calling emplace_back.
	I'm not sure if it has any impact in an optimized build, maybe the
	compiler elides it.  But still, it's unnecessary.

	Change-Id: I873337ea91db29ac06267aff8fc12dcf52824cac
	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-12  Tom Tromey  <tromey@adacore.com>

	Add dynamic_prop::is_constant
	I noticed many spots checking whether a dynamic property's kind is
	PROP_CONST.  Some spots, I think, are doing a slightly incorrect check
	-- checking for != PROP_UNDEFINED where == PROP_CONST is actually
	required, the key thing being that const_val may only be called for
	PROP_CONST properties.

	This patch adds dynamic::is_constant and then updates these checks to
	use it.

	Regression tested on x86-64 Fedora 36.

2023-05-12  Tom Tromey  <tromey@adacore.com>

	Implement DAP register scope
	I noticed that gdb's DAP code did not provide a way to see register
	values.  DAP defines a "register" scope, which this patch implements.
	This patch also adds the missing (and optional) "presentationHint" to
	scopes.

2023-05-12  Tom Tromey  <tromey@adacore.com>

	Fix calling debuginfo-less functions in Ada
	A co-worker at AdaCore noticed that calling a function without
	debuginfo yields:

	(gdb) print plus_one(23)
	'pck.plus_one' has unknown return type; cast the call to its declared return type

	However, this also happens if you follow the directions and add the
	cast.

	This patch fixes the problem and adds a regression test.

2023-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: implement DisassemblerResult.__str__ method
	Add the DisassemblerResult.__str__ method.  This gives the same result
	as the DisassemblerResult.string attribute, but can be useful
	sometimes depending on how the user is trying to print the object.

	There's a test for the new functionality.

2023-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: implement __repr__ methods for py-disasm.c types
	Add a __repr__ method for the DisassembleInfo and DisassemblerResult
	types, and add some tests for these new methods.

2023-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: improve Python Disassembler API documentation
	Some small improvements to the Python Disassembler API documentation:

	  * Be consistent about using the package scope in the @deftp lines,

	  * Rework the description of the DisassemblerResult class to include
	    mention of builtin_disassemble.

2023-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: extend special '^' handling to gdb_test_multiple
	The commit:

	  commit 08ec06d6440745ef9204d39197aa1e732df41056
	  Date:   Wed Mar 29 10:41:07 2023 +0100

	      gdb/testsuite: special case '^' in gdb_test pattern

	Added some special handling of '^' to gdb_test -- a leading '^' will
	cause the command regexp to automatically be included in the expected
	output pattern.

	It was pointed out that the '-wrap' flag of gdb_test_multiple is
	supposed to work in the same way as gdb_test, and that the recent
	changes for '^' had not been replicated for gdb_test_multiple.  This
	patch addresses this issue.

	So, after this commit, the following two constructs should have the
	same meaning:

	  gdb_test "command" "^output" "test name"

	  gdb_test_multiple "command" "test name" {
	    -re -wrap "^output" {
	      pass $gdb_test_name
	    }
	  }

	In both cases the '^' will case gdb.exp to inject a regexp that
	matches 'command' after the '^' and before the 'output', this is in
	addition to adding the $gdb_prompt pattern after 'output' in the
	normal way.

	The special '^' handling is only applied when '-wrap' is used, as this
	is the only mode that aims to mimic gdb_test.

	While working on this patch I realised that I could actually improve
	the logic for the special '^' handling in the case where the expected
	output pattern is empty.  I replicated these updates for both gdb_test
	and gdb_test_multiple in order to keep these two paths in sync.

	There were a small number of tests that needed adjustment after this
	change, mostly just removing command regexps that are now added
	automatically, but the gdb.base/settings.exp case was a little weird
	as it turns out trying to match a single blank line is probably harder
	now than it used to be -- still, I suspect this is a pretty rare case,
	so I think the benefits (improved anchoring) outweigh this small
	downside (IMHO).

2023-05-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix error message for $_gdb_maint_setting
	I spotted this behaviour:

	  (gdb) p $_gdb_maint_setting("xxx")
	  First argument of $_gdb_maint_setting must be a valid setting of the 'show' command.

	Notice that GDB claims I need to use a setting from the 'show'
	command, which isn't correct for $_gdb_maint_setting, in this case I
	need to use a setting from 'maintenance show'.

	This same issue is present for $_gdb_maint_setting_str.

	This commit fixes this minor issue.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-05-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32
	When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board
	unix/-m32 we have:
	...
	(gdb) print noptr^M
	$1 = {0, <optimized out>, <optimized out>, <optimized out>}^M
	(gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
	...

	The problem happens when evaluating this dwarf expression:
	...
	  <45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \
	  (DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8)
	...

	The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and
	the "generic type" has the size of an address on the target machine, which for
	target board unix/-m32 is 4 bytes.  Consequently, the constant is abbreviated.

	Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes
	large, and we hit this clause in rw_pieced_value:
	...
	            /* Use zeroes if piece reaches beyond stack value.  */
	            if (p->offset + p->size > stack_value_size_bits)
	              break;
	...
	and consequently get a zero.

	We could just add require is_target_64 to the test-case, but instead, add a
	32-bit case and require is_target_64 just for the 64-bit case.

	Tested on x86_64-linux.

2023-05-12  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Make is_64_target more robust
	I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and
	with target board dwarf64 ran into:
	...
	FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
	...
	due to is_target_64 failing because of:
	...
	builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
	  -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \
	  is_64_target.c^M
	gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \
	  '-gdwarf -g64' for debug level^M
	compiler exited with status 1
	...

	The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64
	fails for both cases.

	The reason that is_target_64 is failing for target board dwarf64, is because
	of using system compiler 7.5.0 which doesn't support -gdwarf64.

	Fix this by making is_target_64 use nodebug instead of debug for compilation.

	Tested on x86_64-linux.

2023-05-12  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Fix wrapping for TERM=ansi
	I. Auto-detected width (xterm vs. ansi)

	Say we have a terminal with a width of 40 chars:
	...
	$ echo $COLUMNS
	40
	...

	With TERM=xterm, we report a width of 40 chars:
	...
	$ TERM=xterm gdb
	(gdb) show width
	Number of characters gdb thinks are in a line is 40.
	...

	And with TERM=ansi, a width of 39 chars:
	...
	$ TERM=ansi gdb
	(gdb) show width
	Number of characters gdb thinks are in a line is 39.
	...

	Gdb uses readline to auto-detect screen size, and readline decides in the
	TERM=ansi case that the terminal does not have reliable auto-wrap, and
	consequently decides to hide the last terminal column from the readline user
	(in other words GDB), hence we get 39 instead of 40.

	II. Types of wrapping

	Looking a bit more in detail inside gdb, it seems there are two types of
	wrapping:
	- readline wrapping (in other words, prompt edit wrapping), and
	- gdb output wrapping (can be observed by issuing "info sources").
	  This type of wrapping attempts to wrap some of the gdb output earlier
	  than the indicated width, to not break lines in inconvenient places.

	III. Readline wrapping, auto-detected screen size

	Let's investigate readline wrapping with the auto-detected screen widths.

	First, let's try with xterm:
	...
	$ TERM=xterm gdb
	(gdb) 7890123456789012345678901234567890
	123
	...
	That looks as expected, wrapping occurs after 40 chars.

	Now, let's try with ansi:
	...
	$ TERM=ansi gdb
	(gdb) 78901234567890123456789012345678
	90123
	...
	It looks like wrapping occurred after 38, while readline should be capable of
	wrapping after 39 chars.

	This is caused by readline hiding the last column, twice.

	In more detail:
	- readline detects the screen width: 40,
	- readline hides the last column, setting the readline screen width to 39,
	- readline reports 39 to gdb as screen width,
	- gdb sets its width setting to 39,
	- gdb sets readline screen width to 39,
	- readline hides the last column, again, setting the readline screen width to
	  38.

	This is reported as PR cli/30346.

	IV. gdb output wrapping, auto-detected screen size

	Say we set the terminal width to 56. With TERM=xterm, we have:
	...
	/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
	/data/vries/hello.c,
	...
	but with TERM=ansi:
	...
	/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
	data/vries/hello.c,
	...

	So what happened here?  With TERM=ansi, the width setting is auto-detected to
	55, and gdb assumes the terminal inserts a line break there, which it doesn't
	because the terminal width is 56.

	This is reported as PR cli/30411.

	V. Fix PRs

	Fix both mentioned PRs by taking into account the hidden column when readline
	reports the screen width in init_page_info, and updating chars_per_line
	accordingly.

	Note that now we report the same width for both TERM=xterm and TERM=ansi,
	which is much clearer.

	The point where readline respectively expects or ensures wrapping is still
	indicated by "maint info screen", for xterm:
	...
	Number of characters readline reports are in a line is 40.
	...
	and ansi:
	...
	Number of characters readline reports are in a line is 39.
	...

	VI. Testing

	PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
	and gdb.tui/wrap-line.exp, so remove the KFAILs there.

	I didn't manage to come up with a regression test for PR cli/30411.  Perhaps
	that would be easier if we had a maintenance command that echoes its arguments
	while applying gdb output wrapping.

	Tested on x86_64-linux.

	PR cli/30346
	PR cli/30411
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411

2023-05-12  Jan Beulich  <jbeulich@suse.com>

	x86: move a few more disassembler helper functions
	... such that they wouldn't need forward declarations anymore. Note that
	append_seg() already was suitably placed.

	x86: move get<N>() disassembler helper functions
	... such that none of them would need forward declarations anymore.

	x86: slightly simplify i386_parse_name()
	With the switch to parse_real_register() (commit 4faaa10f3fab) "bad_reg"
	cannot come back anymore. Drop the respective check.

2023-05-12  Jan Beulich  <jbeulich@suse.com>

	gas: equates of registers
	There are two problems: symbol_equated_p() doesn't recognize equates of
	registers, and S_CAN_BE_REDEFINED() goes by section rather than by
	expression type. Both together undermine .eqv and .equiv clearly meaning
	to guard the involved symbols against re-definition (both ways).

	To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
	now checking for O_register,
	- for targets creating register symbols through symbol_{new,create}() ->
	  symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
	  mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
	  symbol_init() set their expressions to O_register,
	- x86'es parse_register() also can't go by section anymore when
	  trying to "look through" equates; probably symbol_equated_p() should
	  have been used there from the beginning, if only that had worked for
	  equates of registers,
	- various targets need to "look through" equates when parsing insn
	  operands (which also helps transitive forward equates); perhaps even
	  more ought to, but many don't look to consider the possibility of
	  register equates in the first place.

	This was uncovered by code reported in PR gas/30274 (duplicating
	PR gas/30272), except that there .eqv was used when really .equ was
	meant. Therefore that bug report is addressed here only in so far as
	gas wouldn't crash anymore; the code there still won't assemble
	successfully, just that now the issues there are properly diagnosed.

2023-05-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-11  Tom Tromey  <tom@tromey.com>

	Do not print <synthetic pointer> when piece is optimized out
	A user reported a bug where printing a certain array of integer types
	would result in the nonsensical:

	(gdb) p l_126
	$1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>}

	I tracked this down to some issues in the DWARF expression code.
	First, check_pieced_synthetic_pointer did not account for the
	situation where a location expression does not describe all the bits
	of a value -- in this case it returned true, meaning there is a
	synthetic pointer, but in fact these bits are optimized out.  (It
	turns out this incorrect output had already been erroneously tested
	for as well.)

	Next, rw_pieced_value did not mark these bits as optimized-out,
	either.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296

2023-05-11  Aaron Merey  <amerey@redhat.com>

	gdb/testsuite: Match file size in gdb.debuginfod/crc_mismatch.exp
	gdb's debuginfod progress messages include the size of the file being
	downloaded if the size information is available at the time the message
	is printed.  For example:

	    Downloading 10 MB separate debug info for /lib64/libxyz.so

	This size information is omitted if it's not available at the time of
	printing:

	    Downloading separate debug info for /lib64/libxyz.so

	A pattern in crc_mismatch.exp fails to be matched if a progress message
	includes a file size.  Add a wildcard to the pattern so that it matches
	the progress message whether or not it includes the file size.

2023-05-11  Johnson Sun  <j3.soon777@gmail.com>

	Disable out-of-scope watchpoints
	Currently, when a local software watchpoint goes out of scope, GDB sets
	the watchpoint's disposition to `delete at next stop' and then normal
	stops (i.e., stop and wait for the next GDB command). When GDB normal
	stops, it automatically deletes the breakpoints with their disposition
	set to `delete at next stop'.

	Suppose a Python script decides not to normal stop when a local
	software watchpoint goes out of scope, the watchpoint will not be
	automatically deleted even when its disposition is set to
	`delete at next stop'.

	Since GDB single-steps the program and tests the watched expression
	after each instruction, not deleting the watchpoint causes the
	watchpoint to be hit many more times than it should, as reported in
	PR python/29603.

	This was happening because the watchpoint is not deleted or disabled
	when going out of scope.

	This commit fixes this issue by disabling the watchpoint when going out
	of scope. It also adds a test to ensure this feature isn't regressed in
	the future.

	Calling `breakpoint_auto_delete' on all kinds of stops (in
	`fetch_inferior_event') seem to solve this issue, but is in fact
	inappropriate, since `breakpoint_auto_delete' goes over all breakpoints
	instead of just going through the bpstat chain (which only contains the
	breakpoints that were hit right now).

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29603
	Change-Id: Ia85e670b2bcba2799219abe4b6be3b582387e383

2023-05-11  Tom Tromey  <tromey@adacore.com>

	Add "scheduler-locking" to documentation index
	I noticed that "scheduler-locking" does not appear in the index of the
	gdb manual.  This patch corrects this oversight.

2023-05-11  Joseph Myers  <joseph@codesourcery.com>

	Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]
	This is one part of the fix for GCC PR109128, along with a
	corresponding GCC change.  Without this patch, what happens in the
	linker, when an unused object in a .a file has offload data, is that
	elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p,
	which ends up calling the plugin's claim_file_handler, which then
	records the object as one with offload data. That is, the linker never
	decides to use the object in the first place, but use of this _p
	interface (called as part of trying to decide whether to use the
	object) results in the plugin deciding to use its offload data (and a
	consequent mismatch in the offload data present at runtime).

	The new hook allows the linker plugin to distinguish calls to
	claim_file_handler that know the object is being used by the linker
	(from ldmain.c:add_archive_element), from calls that don't know it's
	being used by the linker (from elf_link_is_defined_archive_symbol); in
	the latter case, the plugin should avoid recording the object as one
	with offload data.

		bfd/
		* plugin.c (struct plugin_list_entry): Add claim_file_v2.
		(register_claim_file_v2): New.
		(try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
		(ld_plugin_object_p): Take second argument.
		(bfd_link_plugin_object_p): Update call to ld_plugin_object_p.
		(register_ld_plugin_object_p): Update argument prototype.
		(bfd_plugin_object_p): Update call to ld_plugin_object_p.
		* plugin.h (register_ld_plugin_object_p): Update argument
		prototype.

		include/
		* plugin.api.h (ld_plugin_claim_file_handler_v2)
		(ld_plugin_register_claim_file_v2)
		(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
		(struct ld_plugin_tv): Add tv_register_claim_file_v2.

		ld/
		* plugin.c (struct plugin): Add claim_file_handler_v2.
		(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
		(plugin_object_p): Add second argument.  Update call to
		plugin_call_claim_file.
		(register_claim_file_v2): New.
		(set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
		(plugin_call_claim_file): Add argument known_used.
		(plugin_maybe_claim): Update call to plugin_object_p.
		* testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle
		LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
		* testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d,
		testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d,
		testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d,
		testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d,
		testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d,
		testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d,
		testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d,
		testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d,
		testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d,
		testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d:
		Update test expectations.

2023-05-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-10  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix tui compact-source a bit more
	Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp
	is incorrect:
	...
	0 +-compact-source.c--------------------------------------------------------+
	1 |___3_{                                                                   |
	2 |___4_  return 0;                                                         |
	3 |___5_}                                                                   |
	4 |___6_                                                                    |
	5 |___7_                                                                    |
	6 |___8_                                                                    |
	7 |___9_                                                                    |
	8 +-------------------------------------------------------------------------+
	...

	The last line number in the source file is 5, and there are 7 lines to display
	source lines, so if we'd scroll all the way down, the first line number in the
	source window would be 5, and the last one would be 11.

	To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of
	___4_, even though all line numbers currently in the src window (3-9) can be
	represented with only 1 digit.

	Fix this in tui_source_window::set_contents, by updating the computation of
	max_line_nr:
	...
	-      int max_line_nr = std::max (lines_in_file, last_line_nr_in_window);
	+      int max_line_nr = lines_in_file + nlines - 1;
	...

	Tested on x86_64-linux.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-10  Andrew Burgess  <aburgess@redhat.com>

	gdb/rust: fix crash for expression debug with strings
	While working on another patch I did this:

	  (gdb) set debug expression 1
	  (gdb) set language rust
	  (gdb) p "foo"
	  Operation: OP_AGGREGATE
	   Type: &str

	  Fatal signal: Segmentation fault
	  ... etc ...

	The problem is that the second field of the rust_aggregate_operation
	is created as a nullptr, this can be seen in rust-parse.c. in the
	function rust_parser::parse_string().

	However, in expop.h, in the function dump_for_expression, we make the
	assumption that the expressions will never be nullptr.

	I did consider moving the nullptr handling into a new function
	rust_aggregate_operation::dump, however, as the expression debug
	dumping code is not exercised as much as it might be, I would rather
	that this code be hardened and able to handle a nullptr without
	crashing, so I propose that we add nullptr handling into the general
	dump_for_expression function.  The behaviour is now:

	  (gdb) set debug expression 1
	  (gdb) set language rust
	  (gdb) p "foo"
	  Operation: OP_AGGREGATE
	   Type: &str
	   nullptr
	   Vector:
	    String: data_ptr
	    Operation: UNOP_ADDR
	     Operation: OP_STRING
	      String: foo
	    String: length
	    Operation: OP_LONG
	     Type: usize
	     Constant: 3
	  evaluation of this expression requires the target program to be active
	  (gdb)

	There's a new test to check for this case.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-10  Alan Modra  <amodra@gmail.com>

	Re: stack overflow in debug_write_type
	Apparently u.kindirect->slot can point at a NULL.

		* debug.c (debug_write_type): Don't segfault on NULL indirect.

2023-05-10  Luca Bonissi  <gcc@scarsita.it>

	or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large
	  PR 30422
	  * elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs.

2023-05-10  Nick Clifton  <nickc@redhat.com>

	Add linker option to include local symbols in  the linker map.
	  PR 16566
	  * ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section.
	  * ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS.
	  * lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals.
	  * NEWS: Mention the new feature.
	  * ld.h (struct ld_config_type): Add print_map_locals field.
	  * ld.texi: Document the new command line option.
	  * testsuite/ld-scripts/sizeof.s: Add a local symbol.
	  * testsuite/ld-scripts/map-locals.d: New test control file.
	  * testsuite/ld-scripts/map-address.exp: Run the new test.

2023-05-10  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix tui compact-source
	Consider a hello.c, with less than 10 lines:
	...
	$ wc -l hello.c
	8 hello.c
	...
	and compiled with -g into an a.out.

	With compact-source off:
	...
	$ gdb -q a.out \
	    -ex "set tui border-kind ascii" \
	    -ex "maint set tui-left-margin-verbose on" \
	    -ex "set tui compact-source off" \
	    -ex "tui enable"
	...
	we get:
	...
	+-./data/hello.c-----------------------+
	|___000005_{                           |
	|___000006_  printf ("hello\n");       |
	|___000007_  return 0;                 |
	|___000008_}                           |
	|___000009_                            |
	|___000010_                            |
	|___000011_                            |
	...
	but with compact-source on:
	...
	+-./data/hello.c-----------------------+
	|___5{                                 |
	|___6  printf ("hello\n");             |
	|___7  return 0;                       |
	|___8}                                 |
	|___9                                  |
	|___1                                  |
	|___1                                  |
	...

	There are a couple of problems with compact-source.

	First of all the documentation mentions:
	...
	The default display uses more space for line numbers and starts the
	source text at the next tab stop; the compact display uses only as
	much space as is needed for the line numbers in the current file, and
	only a single space to separate the line numbers from the source.
	...

	The bit about the default display and the next tab stop looks incorrect.  The
	source doesn't start at a tab stop, instead it uses a single space to separate
	the line numbers from the source.

	Then the documentation mentions that there's single space in the compact
	display, but evidently that's missing.

	Then there's the fact that the line numbers "10" and "11" are both abbreviated
	to "1" in the compact case.

	The abbreviation is due to allocating space for <lines in source>, which is
	8 for this example, and takes a single digit.  The line numbers though
	continue past the end of the file, so fix this by allocating space for
	max (<lines in source>, <last line in window>), which in this example takes 2
	digits.

	The missing space is due to some confusion about what the "1" here in
	tui_source_window::set_contents represent:
	...
	      double l = log10 ((double) offsets->size ());
	      m_digits = 1 + (int) l;
	...

	It could be the trailing space that's mentioned in tui-source.h:
	...
	  /* How many digits to use when formatting the line number.  This
	     includes the trailing space.  */
	  int m_digits;
	...

	Then again, it could be part of the calculation for the number of digits
	needed for printing.  With this minimal example:
	...
	int main () {
	  for (int i = 8; i <= 11; ++i) {
	    double l = log10 ((double) i);
	    printf ("%d %d\n", i, (int)l);
	  }
	  return 0;
	}
	...
	we get:
	...
	$ ./a.out
	8 0
	9 0
	10 1
	11 1
	...
	which shows that the number of digits needed for printing i is
	"1 + (int)log10 ((double) i)".

	Fix this by introducing named variables needed_digits and trailing_space, each
	adding 1.

	With the fixes, we get for compact-source on:
	...
	+-./data/hello.c-----------------------+
	|___05_{                               |
	|___06_  printf ("hello\n");           |
	|___07_  return 0;                     |
	|___08_}                               |
	|___09_                                |
	|___10_                                |
	|___11_                                |
	|...

	Also fix the documentation and help text to actually match effect of
	compact-source.

	Tested on x86_64-linux.

2023-05-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-09  Dan Callaghan  <dan.callaghan@morsemicro.com>

	Support higher baud rates when they are defined
	On Linux at least, baud rate codes are defined up to B4000000. Allow the
	user to select them if they are present in the system headers.

	Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e

2023-05-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy
	Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a
	use-after-free in the breakpoints iterations (see below for full ASan
	report).  This makes gdb.base/stale-infcall.exp fail when GDB is build
	with ASan.

	check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints,
	possibly deleting the current breakpoint as well as related breakpoints.
	The problem arises when a breakpoint in the B->related_breakpoint chain
	is also B->next.  In that case, deleting that related breakpoint frees
	the breakpoint that all_breakpoints_safe has saved.

	The old code worked around that by manually changing B_TMP, which was
	the next breakpoint saved by the "safe iterator":

		while (b->related_breakpoint != b)
		  {
		    if (b_tmp == b->related_breakpoint)
		      b_tmp = b->related_breakpoint->next;
		    delete_breakpoint (b->related_breakpoint);
		  }

	(Note that this seemed to assume that b->related_breakpoint->next was
	the same as b->next->next, not sure this is guaranteed.)

	The new code kept the B_TMP variable, but it's not useful in that
	context.  We can't go change the next breakpoint as saved by the safe
	iterator, like we did before.  I suggest fixing that by saving the
	breakpoints to delete in a map and deleting them all at the end.

	Here's the full ASan report:

	    (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1
	    print infcall ()
	    =================================================================
	    ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60
	    READ of size 8 at 0x611000034980 thread T0
	        #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66
	        #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84
	        #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611
	        #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
	        #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
	        #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
	        #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
	        #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
	        #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
	        #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
	        #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
	        #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
	        #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
	        #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
	        #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
	        #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
	        #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
	        #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
	        #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
	        #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
	        #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
	        #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
	        #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
	        #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
	        #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
	        #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
	        #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
	        #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
	        #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
	        #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
	        #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
	        #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
	        #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
	        #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192
	        #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225
	        #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155
	        #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
	        #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
	        #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
	        #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412
	        #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476
	        #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320
	        #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339
	        #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
	        #44 0x7f5a7e43984f  (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
	        #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
	        #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995)

	    0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50)
	    freed by thread T0 here:
	        #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164
	        #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304
	        #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404
	        #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673
	        #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
	        #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
	        #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
	        #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
	        #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
	        #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
	        #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
	        #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
	        #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
	        #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
	        #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
	        #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
	        #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
	        #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
	        #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
	        #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
	        #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
	        #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
	        #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
	        #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
	        #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
	        #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
	        #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
	        #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
	        #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
	        #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543

	    previously allocated by thread T0 here:
	        #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
	        #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129
	        #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169
	        #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582
	        #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260
	        #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
	        #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
	        #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
	        #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
	        #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
	        #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
	        #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
	        #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
	        #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
	        #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
	        #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
	        #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
	        #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
	        #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
	        #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
	        #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
	        #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
	        #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)

	Change-Id: Id00c17ab677f847fbf4efdf0f4038373668d3d88
	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-09  Enze Li  <enze.li@gmx.com>

	Correct a spelling mistake in the binutils README file.

2023-05-09  Alan Modra  <amodra@gmail.com>

	stack overflow in debug_write_type
	Another fuzzer attack.  This one was a "set" with elements using an
	indirect type pointing back at the set.  The existing recursion check
	only prevented simple recursion.

		* debug.c (struct debug_type_s): Add mark.
		(debug_write_type): Set mark and check before recursing into
		indirect types.

2023-05-09  Alan Modra  <amodra@gmail.com>

	alpha-vms reloc sanity check
	Stops fuzzed files triggering reads past the end of the reloc buffer.

		* vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records.

2023-05-09  Alan Modra  <amodra@gmail.com>

	regen ld/Makefile.in

2023-05-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-08  John Baldwin  <jhb@FreeBSD.org>

	gdbserver: Clear upper ZMM registers in the right location.
	This was previously clearing the upper 32 bytes of ZMM0-15 rather than
	ZMM16-31.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-05-08  John Baldwin  <jhb@FreeBSD.org>

	x86-fbsd-nat: Add missing public label.
	These two methods are both overrides of public methods in base
	classes.

2023-05-08  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb: Avoid warning for the jump command inside an inline function.
	When stopped inside an inline function, trying to jump to a different line
	of the same function currently results in a warning about jumping to another
	function.  Fix this by taking inline functions into account.

	Before:
	  Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22
	  22        a = a + x;             /* inline-funct */
	  (gdb) j 21
	  Line 21 is not in `function_inline(int)'.  Jump anyway? (y or n)

	After:
	  Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22
	  22        a = a + x;            /* inline-funct */
	  (gdb) j 21
	  Continuing at 0x400679.

	  Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21
	  21        a += 1020 + a;                /* increment-funct */

	This was regression-tested on X86-64 Linux.

	Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-05-08  Alan Modra  <amodra@gmail.com>

	pe.em and pep.em make_import_fixup
	This is a little cleanup that I made when looking at pr30343 that
	makes it more obvious that make_import_fixup in both files are
	identical (and in fact the new pep.em read_addend could be used in
	both files).

		* emultempl/pep.em (read_addend): Extract from..
		(make_import_fixup): ..here.
		* emultempl/pe.em (read_addend): Similarly.
		(make_import_fixup): Similarly.  Add debug code from pep.em.

2023-05-08  Alan Modra  <amodra@gmail.com>

	PR30343, LTO ignores linker reference to _pei386_runtime_relocator
	Make a reference to _pei386_runtime_relocator before LTO recompilation.
	This is done regardless of whether such a reference will be used,
	because it can't be known whether it is needed before LTO.

	I also found it necessary to enable long section names for the bfd
	created in make_runtime_pseudo_reloc, because otherwise when writing
	it out to the bfd-in-memory we get the section written as .rdata_r
	which when read back in leads to a linker warning ".rdata_r: section
	below image base" and likely runtime misbehaviour.

		PR 30343
		* emultempl/pe.em (make_runtime_ref): New function.
		(gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function.
		(LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define.
		* emultempl/pep.em: Similarly to pe.em.
		* pe-dll.c (make_runtime_pseudo_reloc): Set long section names.

2023-05-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-07  Tom Tromey  <tom@tromey.com>

	Remove parameter from select_source_symtab
	I noticed that select_source_symtab is only ever called with nullptr
	as an argument, so this patch removes the parameter and associated
	logic.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-05-07  Tom Tromey  <tom@tromey.com>

	Remove ALL_BREAKPOINTS_SAFE
	There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro;
	this patch replaces it with a for-each and an explicit temporary
	variable.

	Remove ALL_DICT_SYMBOLS
	This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can
	be used.

	Remove ALL_OBJFILE_OSECTIONS
	This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each
	can be used.

	Rename objfile::sections
	I think objfile::sections makes sense as the name of the method to
	iterate over an objfile's sections, so this patch renames the existing
	field to objfile::sections_start in preparation for that.

2023-05-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-06  Tom Tromey  <tom@tromey.com>

	Allow pretty-print of static members
	Python pretty-printers haven't applied to static members for quite
	some time.  I tracked this down to the call to cp_print_value_fields
	in cp_print_static_field -- it doesn't let pretty-printers have a
	chance to print the value.  This patch fixes the problem.

	The way that static members are handled is very weird to me.  I tend
	to think this should be done more globally, like in value_print.
	However, I haven't made any big change.

	Reviewed-by:  Keith Seitz <keiths@redhat.com>
	Tested-by:  Keith Seitz <keiths@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057

2023-05-06  YunQiang Su  <yunqiang.su@cipunited.com>

	gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA
	It is added since 2016 by
	  Add support for .MIPS.abiflags and .gnu.attributes sections
	  b52717c0e104eb603e8189c3c0d3658ef5d903f5
	But never documented.

2023-05-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-05  Tom Tromey  <tromey@adacore.com>

	Filter out types from DAP scopes request
	The DAP scopes request examines the symbols in a block tree, but
	neglects to omit types.  This patch fixes the problem.

2023-05-05  Tom Tromey  <tromey@adacore.com>

	Use discrete_position in ada-valprint.c
	I found a couple of spots in ada-valprint.c that use an explicit loop,
	but where discrete_position could be used instead.

	Reviewed-by:  Keith Seitz <keiths@redhat.com>

2023-05-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add mechanism to manage Python initialization functions
	Currently, when we add a new python sub-system to GDB,
	e.g. py-inferior.c, we end up having to create a new function like
	gdbpy_initialize_inferior, which then has to be called from the
	function do_start_initialization in python.c.

	In some cases (py-micmd.c and py-tui.c), we have two functions
	gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
	from finalize_python which is also in python.c.

	This commit proposes a mechanism to manage these initialization and
	finalization calls, this means that adding a new Python subsystem will
	no longer require changes to python.c or python-internal.h, instead,
	the initialization and finalization functions will be registered
	directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.

	The initialization and finalization functions are managed through a
	new class gdbpy_initialize_file in python-internal.h.  This class
	contains a single global vector of all the initialization and
	finalization functions.

	In each Python sub-system we create a new gdbpy_initialize_file
	object, the object constructor takes care of registering the two
	callback functions.

	Now from python.c we can call static functions on the
	gdbpy_initialize_file class which take care of walking the callback
	list and invoking each callback in turn.

	To slightly simplify the Python sub-system files I added a new macro
	GDBPY_INITIALIZE_FILE, which hides the need to create an object.  We
	can now just do this:

	  GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);

	One possible problem with this change is that there is now no
	guaranteed ordering of how the various sub-systems are initialized (or
	finalized).  To try and avoid dependencies creeping in I have added a
	use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
	the same environment variable used in the generated init.c file.

	Just like with init.c, when this environment variable is set we
	reverse the list of Python initialization (and finalization)
	functions.  As there is already a test that starts GDB with the
	environment variable set then this should offer some level of
	protection against dependencies creeping in - though for full
	protection I guess we'd need to run all gdb.python/*.exp tests with
	the variable set.

	I have tested this patch with the environment variable set, and saw no
	regressions, so I think we are fine right now.

	One other change of note was for gdbpy_initialize_gdb_readline, this
	function previously returned void.  In order to make this function
	have the correct signature I've updated its return type to int, and we
	now return 0 to indicate success.

	All of the other initialize (and finalize) functions have been made
	static within their respective sub-system files.

	There should be no user visible changes after this commit.

2023-05-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: more newline pattern cleanup
	After this commit:

	  commit e2f620135d92f7cd670af4e524fffec7ac307666
	  Date:   Thu Mar 30 13:26:25 2023 +0100

	      gdb/testsuite: change newline patterns used in gdb_test

	It was pointed out in PR gdb/30403 that the same patterns can be found
	in other lib/gdb.exp procs and that it would probably be a good idea
	if these procs remained in sync with gdb_test.  Actually, the bug
	specifically calls out gdb_test_multiple when using with '-wrap', but
	I found a couple of other locations in gdb_continue_to_breakpoint,
	gdb_test_multiline, get_valueof, and get_local_valueof.

	In all these locations one or both of the following issues are
	addressed:

	  1. A leading pattern of '[\r\n]*' is pointless.  If there is a
	  newline it will be matched, but if there is not then the testsuite
	  doesn't care.  Also, as expect is happy to skip non-matched output
	  at the start of a pattern, if there is a newline expect is happy to
	  skip over it before matching the rest.  As such, this leading
	  pattern is removed.

	  2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
	  unexpected blank lines at the end of a command's output, but also,
	  if the pattern from the test script ends with a '\r', '\n', or '.'
	  then these will partially match the trailing newline, with the
	  remainder of the newline matched by the pattern from gdb.exp.  This
	  split matching doesn't add any value, it's just something that has
	  appeared as a consequence of how gdb.exp was originally written.  In
	  this case the '\[\r\n\]*' is replaced with '\r\n'.

	I've rerun the testsuite and fixed the regressions that I saw, these
	were places where GDB emits a blank line at the end of the command
	output, which we now need to explicitly match in the test script, this
	was for:

	  gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
	  gdb.guile/guile.exp
	  gdb.python/python.exp

	Or a location where the test script was matching part of the newline
	sequence, while gdb.exp was previously matching the remainder of the
	newline sequence.  Now we rely on gdb.exp to match the complete
	newline sequence, this was for:

	  gdb.base/commands.exp

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403

2023-05-05  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Generate long string in gdb.base/page.exp
	I noticed in gdb.base/page.exp:
	...
	set fours [string repeat 4 40]
	...
	but then shortly afterwards:
	...
	    [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444]
	...

	Summarize the long string in the same way using string repeat:
	...
	    [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]]
	...

	Tested on x86_64-linux.

2023-05-05  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: tighten patterns in build-id-no-debug-warning.exp
	Tighten the expected output pattern in the test script:

	  gdb.debuginfod/build-id-no-debug-warning.exp

	While working on some other patch I broke GDB such that this warning:

	  warning: "FILENAME": separate debug info file has no debug info

	(which is generated in build-id.c) didn't actually include the
	FILENAME any more -- yet this test script continued to pass.  It turns
	out that this script doesn't actually check for FILENAME.

	This commit extends the test pattern to check for the full warning
	string, including FILENAME, and also removes some uses of '.*' to make
	the test stricter.

2023-05-05  Tom Tromey  <tom@tromey.com>

	Simplify decode_locdesc
	While looking into another bug, I noticed that the DWARF cooked
	indexer picks up an address for this symbol:

	 <1><82>: Abbrev Number: 2 (DW_TAG_variable)
	    <83>   DW_AT_specification: <0x9f>
	    <87>   DW_AT_location    : 10 byte block: e 0 0 0 0 0 0 0 0 e0 	(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)
	    <92>   DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E

	This happens because decode_locdesc allows the use of
	DW_OP_GNU_push_tls_address.

	This didn't make sense to me.  I looked into it a bit more, and I
	think decode_locdesc is used in three ways:

	1. Find a constant address of a symbol that happens to be encoded as a
	   location expression.

	2. Find the offset of a function in a virtual table.  (This one should
	   probably be replaced by code to just evaluate the expression in
	   gnu-v3-abi.c -- but there's no point yet because no compiler
	   actually seems to emit correct DWARF here, see the bug linked in
	   the patch.)

	3. Find the offset of a field, if the offset is a constant.

	None of these require TLS.

	This patch simplifies decode_locdesc by removing any opcodes that
	don't fit into the above.  It also changes the API a little, to make
	it less difficult to use.

	Regression tested on x86-64 Fedora 36.

2023-05-05  Tom Tromey  <tom@tromey.com>

	Simplify auto_load_expand_dir_vars and remove substitute_path_component
	This simplifies auto_load_expand_dir_vars to first split the string,
	then do any needed substitutions.  This was suggested by Simon, and is
	much simpler than the current approach.

	Then this patch also removes substitute_path_component, as it is no
	longer called.  This is nice because it helps with the long term goal
	of removing utils.h.

	Regression tested on x86-64 Fedora 36.

2023-05-05  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.base/wrap-line.exp
	Add a test-case that tests prompt edit wrapping in CLI, both
	for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width.

	In the TERM=ansi case with auto-detected width we run into PR cli/30346, so
	add a KFAIL for that failure mode.

	Tested on x86_64-linux.

2023-05-05  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.tui/wrap-line.exp
	Add a test-case that tests prompt edit wrapping behaviour in the tuiterm, both
	for CLI and TUI, both with auto-detected and hard-coded width.

	In the CLI case with auto-detected width we run into PR cli/30411, so add a
	KFAIL for that failure mode.

	Tested on x86_64-linux.

2023-05-05  Nick Clifton  <nickc@redhat.com>

	Debug info is lost for functions only called from functions marked with cmse_nonsecure_entr
	  PR 30354
	  * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies.

2023-05-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-04  Bruno Larsen  <blarsen@redhat.com>

	Revert "gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp"
	This reverts commit 476410b3bca1389ee69e9c8fa18aaee16793a56d.

	One of Simon's recent commits (2a740b3ba4c9f39c86dd75e0914ee00942cab471)
	changed the way recording a remote target works and fixed the underlying
	issue of the bug, so the KFails can be removed from the test.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-05-04  Gareth Rees  <grees@undo.io>

	Don't treat references to compound values as "simple".
	SUMMARY

	The '--simple-values' argument to '-stack-list-arguments' and similar
	GDB/MI commands does not take reference types into account, so that
	references to arbitrarily large structures are considered "simple" and
	printed. This means that the '--simple-values' argument cannot be used
	by IDEs when tracing the stack due to the time taken to print large
	structures passed by reference.

	DETAILS

	Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals',
	'-stack-list-variables' and so on) take a PRINT-VALUES argument which
	may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2).
	In the '--simple-values' case, the command is supposed to print the
	name, type, and value of variables with simple types, and print only the
	name and type of variables with compound types.

	The '--simple-values' argument ought to be suitable for IDEs that need
	to update their user interface with the program's call stack every time
	the program stops. However, it does not take C++ reference types into
	account, and this makes the argument unsuitable for this purpose.

	For example, consider the following C++ program:

	    struct s {
	        int v[10];
	    };

	    int
	    sum(const struct s &s)
	    {
	        int total = 0;
	        for (int i = 0; i < 10; ++i) total += s.v[i];
	        return total;
	    }

	    int
	    main(void)
	    {
	        struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } };
	        return sum(s);
	    }

	If we start GDB in MI mode and continue to 'sum', the behaviour of
	'-stack-list-arguments' is as follows:

	    (gdb)
	    -stack-list-arguments --simple-values
	    ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}]

	Note that the value of the argument 's' was printed, even though 's' is
	a reference to a structure, which is not a simple value.

	See https://github.com/microsoft/MIEngine/pull/673 for a case where this
	behaviour caused Microsoft to avoid the use of '--simple-values' in
	their MIEngine debug adapter, because it caused Visual Studio Code to
	take too long to refresh the call stack in the user interface.

	SOLUTIONS

	There are two ways we could fix this problem, depending on whether we
	consider the current behaviour to be a bug.

	1. If the current behaviour is a bug, then we can update the behaviour
	   of '--simple-values' so that it takes reference types into account:
	   that is, a value is simple if it is neither an array, struct, or
	   union, nor a reference to an array, struct or union.

	   In this case we must add a feature to the '-list-features' command so
	   that IDEs can detect that it is safe to use the '--simple-values'
	   argument when refreshing the call stack.

	2. If the current behaviour is not a bug, then we can add a new option
	   for the PRINT-VALUES argument, for example, '--scalar-values' (3),
	   that would be suitable for use by IDEs.

	   In this case we must add a feature to the '-list-features' command
	   so that IDEs can detect that the '--scalar-values' argument is
	   available for use when refreshing the call stack.

	PATCH

	This patch implements solution (1) as I think the current behaviour of
	not printing structures, but printing references to structures, is
	contrary to reasonable expectation.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554

2023-05-04  Nick Clifton  <nickc@redhat.com>

	Stop the linker from loosing the entry point for COFF/PE code when compiling with LTO enabled.
	  PR 30300
	  * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically.
	  * emultempl/pe.em (set_entry_point): Likewise.

2023-05-04  Dimitar Dimitrov  <dimitar@dinux.eu>

	ld: pru: Place exception-handling sections correctly
	  * scripttempl/pru.sc (OUTPUT_SECTION_ALIGN): New helper variable to place at end of DMEM output sections.
	  (.data): Use the helper variable.
	  (.eh_frame): New output section.
	  (.gnu_extab): Ditto.
	  (.gcc_except_table): Ditto.
	  (.resource_table): Use the helper variable.

2023-05-04  Jan Beulich  <jbeulich@suse.com>

	RISC-V: tighten post-relocation-operator separator expectation
	As per the spec merely a blank isn't okay as a separator, the operand
	to the relocation function ought to be parenthesized. Enforcing this
	then also eliminates an inconsistency in that

		lui	t0, %hi sym
		lui	t0, %hi 0x1000

	were accepted, but

		lui	t0, %hi +sym
		lui	t0, %hi -0x1000

	were not.

2023-05-04  Ilya Leoshkevich  <iii@linux.ibm.com>

	gas: fix building tc-bpf.c on s390x
	char is unsigned on s390x, so there are a lot of warnings like:

	    gas/config/tc-bpf.c: In function 'get_token':
	    gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits]
	      900 |       if (ch == EOF || len > MAX_TOKEN_SZ)
	          |              ^~

	Change its type to int, like in the other similar code.

	There is also:

	    gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized]
	      735 |    dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]);
	          |                   ~~~~~~~~~~~^~~~~~~~~~

	-Wmaybe-uninitialized doesn't seem to understand the FSM; just
	initialize bpf_endianness to silence it.  Add an assertion to
	build_bpf_endianness() in order to catch potential bugs.

2023-05-04  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: revert "default r6 if vendor is img"
	In commit: 9171de358f230b64646bbb525a74e5f8e3dbe0dc,
	The default output is set to r6 if the vendor is img,
	It is ugly and should not be in upstream.

	Let's revert it.

2023-05-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-03  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix frame_list position in frame.c
	In commit 995a34b1772 ("Guard against frame.c destructors running before
	frame-info.c's") the following problem was addressed.

	The frame_info_ptr destructor:
	...
	  ~frame_info_ptr ()
	  {
	    frame_list.erase (frame_list.iterator_to (*this));
	  }
	...
	uses frame_list, which is a static member of class frame_info_ptr,
	instantiated in frame-info.c:
	...
	intrusive_list<frame_info_ptr> frame_info_ptr::frame_list;
	...

	Then there's a static frame_info_pointer variable named selected_frame in
	frame.c:
	...
	static frame_info_ptr selected_frame;
	...

	Because the destructor of selected_frame uses frame_list, its destructor needs
	to be called before the destructor of frame_list.

	But because they're in different compilation units, the initialization order and
	consequently destruction order is not guarantueed.

	The commit fixed this by handling the case that the destructor of frame_list
	is called first, adding a check on is_linked ():
	...
	   ~frame_info_ptr ()
	   {
	-    frame_list.erase (frame_list.iterator_to (*this));
	+    /* If this node has static storage, it may be deleted after
	+       frame_list.  Attempting to erase ourselves would then trigger
	+       internal errors, so make sure we are still linked first.  */
	+    if (is_linked ())
	+      frame_list.erase (frame_list.iterator_to (*this));
	   }
	...

	However, since then frame_list has been moved into frame.c, and
	initialization/destruction order is guarantueed inside a compilation unit.

	Revert aforementioned commit, and fix the destruction order problem by moving
	frame_list before selected_frame.

	Reverting the commit is another way of fixing the already fixed
	Wdangling-pointer warning reported in PR build/30413, in a different way than
	commit 9b0ccb1ebae ("Pass const frame_info_ptr reference for
	skip_[language_]trampoline").

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Tested on x86_64-linux.
	PR build/30413
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413

2023-05-03  Lancelot SIX  <lancelot.six@amd.com>

	gdb/show_args_command: print to the ui_file argument
	The show_args_command uses gdb_printf without specifying the ui_file.
	This means that it prints to gdb_stdout instead of the stream given as
	an argument to the function.

	This commit fixes this.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-05-03  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	Make ar faster
	 * archive.c (_bfd_write_archive_contents): Use a larger buffer in order to improve efficiency.

2023-05-03  Mark Wielaard  <mark@klomp.org>

	Pass const frame_info_ptr reference for skip_[language_]trampoline
	g++ 13.1.1 produces a -Werror=dangling-pointer=

	In file included from ../../binutils-gdb/gdb/frame.h:75,
	                 from ../../binutils-gdb/gdb/symtab.h:40,
	                 from ../../binutils-gdb/gdb/language.c:33:
	In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’,
	    inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24,
	    inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26,
	    inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49:
	gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=]
	  415 |     m_back = &elem;
	      |     ~~~~~~~^~~~~~~
	gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’:
	gdb/language.c:530:49: note: ‘<anonymous>’ declared here
	  530 |       CORE_ADDR real_pc = lang->skip_trampoline (frame, pc);
	      |                           ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
	gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here
	  359 |   static intrusive_list<frame_info_ptr> frame_list;
	      |                                         ^~~~~~~~~~

	Each new frame_info_ptr is being pushed on a static frame list and g++
	cannot see why that is safe in case the frame_info_ptr is created and
	destroyed immediately when passed as value.

	It isn't clear why only in this one place g++ sees the issue (probably
	because it can inline enough code in this specific case).

	Since passing the frame_info_ptr as const reference is cheaper, use
	that as workaround for this warning.

	PR build/30413
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413

	Tested-by: Kevin Buettner <kevinb@redhat.com>
	Reviewed-by: Kevin Buettner <kevinb@redhat.com>
	Reviewed-by: Tom Tromey <tom@tromey.com>

2023-05-03  Oleg Tolmatcev  <oleg.tolmatcev@gmail.com>

	Improve the speed of computing checksums for COFF binaries.
	 * coffcode.h (coff_read_word_from_buffer): New function.
	 * coffcode.h (COFF_CHECKSUM_BUFFER_SIZE): New constant.
	 * coffcode.h (coff_compute_checksum): Improve speed by reducing the number of seeks and reads used.

2023-05-03  Alan Modra  <amodra@gmail.com>

	Remove unused args from bfd_make_debug_symbol
	The ptr and size args are unused.  Make the function look the same as
	bfd_make_empty_symbol.

	Generated docs and include files
	bfd/doc/chew.c extracts documentation from source code comments
	annotated with keywords, and generates much of bfd.h and libbfd.h from
	those same comments.  The docs have suffered from people (me too)
	adding things like CODE_FRAGMENT to the source to put code into bfd.h
	without realising that CODE_FRAGMENT also puts @example around said
	code into the docs.  So we have random senseless things in the docs.
	This patch fixes that problem (well, the senseless things from
	CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
	few chew.c features.  libbfd.h now automatically gets ATTRIBUTE_HIDDEN
	prototypes, and indentation in bfd.h and libbfd.h is better.

2023-05-03  Alan Modra  <amodra@gmail.com>

	Move bfd_alloc, bfd_zalloc and bfd_release to libbfd.c
	These functions don't belong in opncls.c.

		* libbfd-in.h (bfd_release): Delete prototype.
		* opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to..
		* libbfd.c: ..here.  Include objalloc.c and provide bfd_release
		with a FUNCTION comment.
		* bfd-in2.h: Regenerate.
		* libbfd.h: Regenerate.

2023-05-03  Alan Modra  <amodra@gmail.com>

	Move bfd_elf_bfd_from_remote_memory to opncls.c
	bfd_elf_bfd_from_remote_memory is just a wrapper, and the function
	could be implemented for other formats.  Move it to opncls.c because
	it acts a little like some of the other bfd_open* routines.  Also give
	it the usual FUNCTION etc. comment so prototypes and docs are handled
	automatically.

		* elf.c (bfd_elf_bfd_from_remote_memory): Move to..
		* opncls.c: ..here, add FUNCTION comment.
		* bfd-in.h (bfd_elf_bfd_from_remote_memory): Delete prototype.
		* bfd-in2.h: Regenerate.

2023-05-03  Alan Modra  <amodra@gmail.com>

	hash.c: replace some unsigned long with unsigned int
		* hash.c (higher_prime_number): Use uint32_t param, return value,
		tables and variables.
		(bfd_default_hash_table_size): Make it an unsigned int.
		(bfd_hash_set_default_size): Use unsigned int param and return.
		* bfd-in.h (bfd_hash_set_default_size): Update prototype.
		* bfd-in2.h: Regenerate.

	libbfc.c: Use stdint types for unsigned char and unsigned long
		* libbfd.c (bfd_put_8): Use bfd_byte rather than unsigned char.
		(bfd_get_8, bfd_get_signed_8): Likewise.
		(_bfd_read_unsigned_leb128, _bfd_safe_read_leb128): Likewise.
		(_bfd_read_signed_leb128): Likewise.
		(bfd_getb24, bfd_getl24): Replace unsigned long with uint32_t.
		(bfd_getb32, bfd_getl32): Likewise.
		(bfd_getb_signed_32, bfd_getl_signed_32): Likewise.

2023-05-03  Alan Modra  <amodra@gmail.com>

	Change signature of bfd crc functions
	The crc calculated is 32 bits.  Replace uses of unsigned long with
	uint32_t.  Also use bfd_byte* for buffers.

	bfd/
		* opncls.c (bfd_calc_gnu_debuglink_crc32): Use stdint types.
		(bfd_get_debug_link_info_1, bfd_get_debug_link_info): Likewise.
		(separate_debug_file_exists, bfd_follow_gnu_debuglink): Likewise.
		(bfd_fill_in_gnu_debuglink_section): Likewise.
		* bfd-in2.h: Regenerate.
	gdb/
		* auto-load.c (auto_load_objfile_script): Update type of
		bfd_get_debug_link_info argument.
		* symfile.c (find_separate_debug_file_by_debuglink): Likewise.
		* gdb_bfd.c (get_file_crc): Update type of
		bfd_calc_gnu_debuglink_crc32 argument.

2023-05-03  Alan Modra  <amodra@gmail.com>

	_bfd_mips_elf_lo16_reloc vallo comment
	This explains exactly why the high reloc adjustment is as it is,
	replacing the rather nebulous existing comment.  I've also changed the
	expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better
	matches part of the standard 16-bit sign extension (resulting in
	exactly the same value), and hoisted the calculation out of the loop.

		* elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo
		comment.  Hoist calculation out of loop.

2023-05-02  Alexandra Hájková  <ahajkova@redhat.com>

	gdb.base/watchpoint-unaligned.exp: Always initialize wpoffset_to_wpnum
	Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types.

	ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
	ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
	ERROR:  tcl error code TCL READ VARNAME
	ERROR:  tcl error info:
	can't read "wpoffset_to_wpnum(1)": no such element in array
	    while executing

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340

	Reviewed-by: Luis Machado <luis.machado@arm.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-05-02  Mark Wielaard  <mark@klomp.org>

	xcoffread.c: Fix -Werror=dangling-pointer= issue with main_subfile.
	GCC 13 points out that main_subfile has local function scope, but a
	pointer to it is assigned to the global inclTable array subfile
	element field:

	In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
	    inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
	    inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
	xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
	  629 |               inclTable[ii].subfile = &main_subfile;
	      |               ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
	xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
	xcoffread.c:579:18: note: ‘main_subfile’ declared here
	  579 |   struct subfile main_subfile;
	      |                  ^~~~~~~~~~~~
	xcoffread.c:496:19: note: ‘inclTable’ declared here
	  496 | static InclTable *inclTable;    /* global include table */
	      |                   ^~~~~~~~~

	Fix this by making main_subfile file static. And allocate and
	deallocated together with inclTable in allocate_include_entry and
	xcoff_symfile_finish. Adjust the use of main_subfile in
	process_linenos to take a pointer to the subfile.

2023-05-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use set in lmap in gdb.dwarf2/dw2-abs-hi-pc.exp
	In gdb.dwarf2/dw2-abs-hi-pc.exp we do:
	...
	set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
	...

	The use of expr is not idiomatic.  Fix this by using set instead:
	...
	set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }]
	...

	Reported-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andreas Schwab <schwab@suse.de>

2023-05-02  Aditya Kamath  <Aditya.Kamath1@ibm.com>

	Fix Assertion pid != 0 failure in AIX.
	In AIX if there is a main and a thread created from it , then once the
	program completed execution and goes to pd_disable () inferior_ptid
	had pid 0 leading to an assertion failure while finding the thread's data
	in aix-thread.c file.

	This patch is a fix for the same.

2023-05-02  Tom Tromey  <tom@tromey.com>

	Remove error_stream
	error_stream is trivial and only used in a couple of spots in
	breakpoint.c.  This patch removes it in favor of just writing it out
	at the spots where it was used.

2023-05-02  Nick Clifton  <nickc@redhat.com>

	Remove Dimity Diky as MSP430 maintainer.

2023-05-02  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: compile gdb.linespec/cp-completion-aliases.exp as C++
	Noticed in passing that the prepare_for_testing call in
	gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag,
	despite this being a C++ test.

	I guess, as the source file has the '.cc' extension, all the compilers
	are doing the right thing anyway -- the source file uses templates, so
	is definitely being compiled as C++.

	I noticed this when I tried to set CXX_FOR_TARGET (but not
	CC_FOR_TARGET) and spotted that this script was still using the C
	compiler.

	Fixed in this commit by adding the 'c++' flag for prepare_for_testing.

2023-05-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-05-01  Tom Tromey  <tromey@adacore.com>

	Document DAP 'launch' parameter
	The Debugger Adapter Protocol defines a "launch" request but leaves
	the parameters up to the implementation:

	    Since launching is debugger/runtime specific, the arguments for
	    this request are not part of this specification.

	This patch adds some documentation for the parameter GDB currently
	defines.  Note that I plan to add more parameters here, and perhaps
	there will be other extensions in time as well.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-05-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove ui_interp_info
	I don't think that having struct ui_interp_info separated from struct ui
	is very useful.  As of today, it looks like an unnecessary indirection
	layer.  Move the contents of ui_interp_info directly into struct ui, and
	update all users.

	Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521

2023-05-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: store interps in an intrusive_list
	Use intrusive_list, instead of hand-made linked list.

	Change-Id: Idc857b40dfa3e3c35671045898331cca2c928097

2023-05-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move struct ui and related things to ui.{c,h}
	I'd like to move some things so they become methods on struct ui.  But
	first, I think that struct ui and the related things are big enough to
	deserve their own file, instead of being scattered through top.{c,h} and
	event-top.c.

	Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc

2023-05-01  Tom Tromey  <tromey@adacore.com>

	Turn set_inferior_args_vector into method of inferior
	This patch turns set_inferior_args_vector into an overload of
	inferior::set_args.

	Regression tested on x86-64 Fedora 36.

2023-05-01  Tom Tromey  <tromey@adacore.com>

	Remove evaluate_type
	Like evaluate_expression, evaluate_type is also just a simple wrapper.
	Removing it makes the code a little nicer.

	Remove evaluate_expression
	evaluate_expression is just a little wrapper for a method on
	expression.  Removing it also removes a lot of ugly (IMO) calls to
	get().

	Remove op_name
	op_name is only needed in a single place, so remove it and inline it
	there.

2023-05-01  Tom Tromey  <tromey@adacore.com>

	Fix crash in Rust expression parser
	A user found that an array expression with just a single value (like
	"[23]") caused the Rust expression parser to crash.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30410

2023-05-01  Tom Tromey  <tom@tromey.com>

	Replace field_is_static with a method
	This changes field_is_static to be a method on struct field, and
	updates all the callers.  Most of this patch was written by script.

	Regression tested on x86-64 Fedora 36.

2023-05-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-30  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix TUI resizing for TERM=ansi
	With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
	(maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
	fix) and a message:
	...
	@@ resize done 0, size = 77x20
	...
	with the resulting width being 77 instead of the expected 78.

	[ The discrepancy also manifests in CLI, filed as PR30346. ]

	The discrepancy comes from tui_resize_all, where we ask readline for the
	screen size:
	...
	   rl_get_screen_size (&screenheight, &screenwidth);
	...

	As it happens, when TERM is set to ansi, readline decides that the terminal
	cannot auto-wrap lines, and reserves one column to deal with that, and as a
	result reports back one less than the actual screen width:
	...
	$ echo $COLUMNS
	78
	$ TERM=xterm gdb -ex "show width" -ex q
	Number of characters gdb thinks are in a line is 78.
	$ TERM=ansi  gdb -ex "show width" -ex q
	Number of characters gdb thinks are in a line is 77.
	...

	In tui_resize_all, we need the actual screen width, and using a screenwidth of
	one less than the actual value garbles the screen.

	This is currently not causing trouble in testing because we have a workaround
	in place in proc Term::resize.  If we disable the workaround:
	...
	-       stty columns [expr {$_cols + 1}] < $::gdb_tty_name
	+       stty columns $_cols < $::gdb_tty_name
	...
	and dump the screen we get the same type of screen garbling:
	...
	    0 +---------------------------------------+|
	    1                                         ||
	    2                                         ||
	    3                                         ||
	...

	Another way to reproduce the problem is using command "maint info screen".
	After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
	get:
	...
	Number of characters curses thinks are in a line is 78.
	...
	and after maximizing and demaximizing the window we get:
	...
	Number of characters curses thinks are in a line is 77.
	...
	If we use TERM=xterm, we do get the expected 78.

	Fix this by:
	- detecting when readline will report back less than the actual screen width,
	- accordingly setting a new variable readline_hidden_cols,
	- using readline_hidden_cols in tui_resize_all to fix the resize problem, and
	- removing the workaround in Term::resize.

	The test-case gdb.tui/empty.exp serves as regression test.

	I've applied the same fix in tui_async_resize_screen, the new test-case
	gdb.tui/resize-2.exp serves as a regression test for that change.  Without
	that fix, we have:
	...
	FAIL: gdb.tui/resize-2.exp: again: gdb width 80
	...

	Tested on x86_64-linux.

	PR tui/30337
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337

2023-04-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/readline.exp with stub-termcap
	When doing a build which uses stub-termcap, we run into:
	...
	(gdb) set width 7
	<b) FAIL: gdb.base/readline.exp: set width 7 (timeout)
	...

	Since readline can't detect very basic terminal support, it falls back on
	horizontal scrolling.

	Fix this by detecting the horizontal scrolling case, and skipping the
	subsequent test.

	Tested on x86_64-linux.

	PR testsuite/30400
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400

2023-04-29  Manoj Gupta  <manojgupta@google.com>

	gdb: Fix building with latest libc++
	Latest libc++[1] causes transitive include to <locale> when
	<mutex> or <thread> header is included. This causes
	gdb to not build[2] since <locale> defines isupper/islower etc.
	functions that are explicitly macroed-out in safe-ctype.h to
	prevent their use.
	Use the suggestion from libc++ to include <locale> internally when
	building in C++ mode to avoid build errors.
	Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
	to keep this isolated to gdb since rest of binutils
	does not seem to use much C++.

	[1]: https://reviews.llvm.org/D144331
	[2]: https://issuetracker.google.com/issues/277967395

2023-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.ada/excep_handle.exp for updated gdb_test
	Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9
	("gdb/testsuite: change newline patterns used in gdb_test"):
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
	26            when Constraint_Error =>^M
	(gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
	  exception handlers
	...

	The output is supposed to be matched by:
	...
	gdb_test "continue" \
	         "Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
	         "continuing to first Constraint_Error exception handlers"
	...
	but the $eol bit no longer matches due to the stricter matching introduced
	in aforementioned commit.

	Fix this by dropping the "$eol.*" bit.

	Tested on x86_64-linux.

	PR testsuite/30399
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399

2023-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/build] Fix build without ncurses in maintenance_info_screen
	With a build without ncurses we run into:
	...
	src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’:
	src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope
	       COLS);
	       ^~~~
	src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope
	        LINES);
	        ^~~~~
	...

	Fix this by using HAVE_LIBCURSES.

	Tested on x86_64-linux.

	PR build/30391
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30391

2023-04-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/main.exp without TUI
	With a build with --disable-tui, we get:
	...
	(gdb) PASS: gdb.tui/main.exp: set interactive-mode off
	maint set tui-left-margin-verbose on^M
	Undefined maintenance set command: "tui-left-margin-verbose on".  \
	  Try "help maintenance set".^M
	(gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on
	...

	Fix this by adding the missing "require allow_tui_tests".

	Tested on x86_64-linux.

2023-04-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-29  Andrew Burgess  <aburgess@redhat.com>

	gdb/mi: check thread exists when creating thread-specific b/p
	I noticed the following behaviour:

	  $ gdb -q -i=mi /tmp/hello.x
	  =thread-group-added,id="i1"
	  =cmd-param-changed,param="print pretty",value="on"
	  ~"Reading symbols from /tmp/hello.x...\n"
	  (gdb)
	  -break-insert -p 99 main
	  ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
	  (gdb)
	  info breakpoints
	  &"info breakpoints\n"
	  ~"Num     Type           Disp Enb Address            What\n"
	  ~"1       breakpoint     keep y   0x0000000000401198 in main at /tmp/hello.c:18\n"
	  &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
	  &"\n"
	  &"----- Backtrace -----\n"
	  &"Backtrace unavailable\n"
	  &"---------------------\n"
	  &"\nThis is a bug, please report it."
	  &"  For instructions, see:\n"
	  &"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
	  Aborted (core dumped)

	What we see here is that when using the MI a user can create
	thread-specific breakpoints for non-existent threads.  Then if we try
	to use the CLI 'info breakpoints' command GDB throws an assertion.
	The assert is a result of the print_thread_id call when trying to
	build the 'stop only in thread xx.yy' line; print_thread_id requires a
	valid thread_info pointer, which we can't have for a non-existent
	thread.

	In contrast, when using the CLI we see this behaviour:

	  $ gdb -q /tmp/hello.x
	  Reading symbols from /tmp/hello.x...
	  (gdb) break main thread 99
	  Unknown thread 99.
	  (gdb)

	The CLI doesn't allow a breakpoint to be created for a non-existent
	thread.  So the 'info breakpoints' command is always fine.

	Interestingly, the MI -break-info command doesn't crash, this is
	because the MI uses global thread-ids, and so never calls
	print_thread_id.  However, GDB does support using CLI and MI in
	parallel, so we need to solve this problem.

	One option would be to change the CLI behaviour to allow printing
	breakpoints for non-existent threads.  This would preserve the current
	MI behaviour.

	The other option is to pull the MI into line with the CLI and prevent
	breakpoints being created for non-existent threads.  This is good for
	consistency, but is a breaking change for the MI.

	In the end I figured that it was probably better to retain the
	consistent CLI behaviour, and just made the MI reject requests to
	place a breakpoint on a non-existent thread.  The only test we had
	that depended on the old behaviour was
	gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit:

	  commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c
	  Date:   Fri Feb 17 10:48:06 2023 +0000

	      gdb: don't duplicate 'thread' field in MI breakpoint output

	I certainly didn't intend for this test to rely on this feature of the
	MI, so I propose to update this test to only create breakpoints for
	threads that exist.

	Actually, I've added a new test that checks the MI rejects creating a
	breakpoint for a non-existent thread, and I've also extended the test
	to run with the separate MI/CLI UIs, and then tested 'info
	breakpoints' to ensure this command doesn't crash.

	I've extended the documentation of the `-p` flag to explain the
	constraints better.

	I have also added a NEWS entry just in case someone runs into this
	issue, at least then they'll know this change in behaviour was
	intentional.

	One thing that I did wonder about while writing this patch, is whether
	we should treat requests like this, on both the MI and CLI, as another
	form of pending breakpoint, something like:

	  (gdb) break foo thread 9
	  Thread 9 does not exist.
	  Make breakpoint pending on future thread creation? (y or [n]) y
	  Breakpoint 1 (foo thread 9) pending.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address    What
	  1       breakpoint     keep y   <PENDING>  foo thread 9

	Don't know if folk think that would be a useful idea or not?  Either
	way, I think that would be a separate patch from this one.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: make deprecated_show_value_hack static
	The deprecated_show_value_hack function is now only used inside
	cli-setshow.c, so lets make the function static to discourage its use
	anywhere else.

	There should be no user visible changes after this commit

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: make set/show inferior-tty work with $_gdb_setting_str
	Like the previous two commits, this commit fixes set/show inferior-tty
	to work with $_gdb_setting_str.

	Instead of using a scratch variable which is then pushed into the
	current inferior from a set callback, move to the API that allows for
	getters and setters, and store the value directly within the current
	inferior.

	Update an existing test to check the inferior-tty setting.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: make set/show cwd work with $_gdb_setting_str
	The previous commit fixed set/show args when used with
	$_gdb_setting_str, this commit fixes set/show cwd.

	Instead of using a scratch variable which is then pushed into the
	current inferior from a set callback, move to the API that allows for
	getters and setters, and store the value directly within the current
	inferior.

	Update the existing test to check the cwd setting.

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: make set/show args work with $_gdb_setting_str
	I noticed that $_gdb_setting_str was not working with 'args', e.g.:

	  $ gdb -q --args /tmp/hello.x arg1 arg2 arg3
	  Reading symbols from /tmp/hello.x...
	  (gdb) show args
	  Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
	  (gdb) print $_gdb_setting_str("args")
	  $1 = ""

	This is because the 'args' setting is implemented using a scratch
	variable ('inferior_args_scratch') which is updated when the user does
	'set args ...'.  There is then a function 'set_args_command' which is
	responsible for copying the scratch area into the current inferior.

	However, when the user sets the arguments via the command line the
	scratch variable is not updated, instead the arguments are pushed
	straight into the current inferior.

	There is a second problem, when the current inferior changes the
	scratch area is not updated, which means that the value returned will
	only ever reflect the last call to 'set args ...' regardless of which
	inferior is currently selected.

	Luckily, the fix is pretty easy, set/show variables have an
	alternative API which requires we provide some getter and setter
	functions.  With this done the scratch variable can be removed and the
	value returned will now always reflect the current inferior.

	While working on set/show args I also rewrote show_args_command to
	remove the use of deprecated_show_value_hack.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: cleanup command creation in infcmd.c
	In infcmd.c, in order to add command completion to some of the 'set'
	commands, we are currently creating the command, then looking up the
	command by calling lookup_cmd.

	This is no longer necessary, we already return the relevant
	cmd_list_element object when the set/show command is created, and we
	can use that to set the command completion callback.

	I don't know if there's actually any tests for completion of these
	commands, but I manually checked, and each command still appears to
	offer the expected filename completion.

	There should be no user visible changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb/record-full: disable range stepping when resuming threads
	I see these failures, when running with the native-gdbserver of
	native-extended-gdbserver boards:

	    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
	    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
	    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
	    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
	    FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body

	Let's use this simpler program to illustrate the problem:

	    int main()
	    {
	      int a = 362;
	      a = a * 17;
	      return a;
	    }

	It compiles down to:

	    int a = 362;
	    401689:       c7 45 fc 6a 01 00 00    movl   $0x16a,-0x4(%rbp)
	    a = a * 17;
	    401690:       8b 55 fc                mov    -0x4(%rbp),%edx
	    401693:       89 d0                   mov    %edx,%eax
	    401695:       c1 e0 04                shl    $0x4,%eax
	    401698:       01 d0                   add    %edx,%eax
	    40169a:       89 45 fc                mov    %eax,-0x4(%rbp)
	    return a;
	    40169d:       8b 45 fc                mov    -0x4(%rbp),%eax

	When single stepping these lines, debugging locally, while recording,
	these are the recorded instructions (basically one for each instruction
	shown above):

	    (gdb) maintenance print record-instruction 0
	    4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00
	    Register rip changed: (void (*)()) 0x40169a <main+21>
	    (gdb) maintenance print record-instruction -1
	    Register rax changed: 5792
	    Register eflags changed: [ PF AF IF ]
	    Register rip changed: (void (*)()) 0x401698 <main+19>
	    (gdb) maintenance print record-instruction -2
	    Register rax changed: 362
	    Register eflags changed: [ PF ZF IF ]
	    Register rip changed: (void (*)()) 0x401695 <main+16>
	    (gdb) maintenance print record-instruction -3
	    Register rax changed: 4200069
	    Register rip changed: (void (*)()) 0x401693 <main+14>
	    (gdb) maintenance print record-instruction -4
	    Register rdx changed: 140737488346696
	    Register rip changed: (void (*)()) 0x401690 <main+11>
	    (gdb) maintenance print record-instruction -5
	    4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00
	    Register rip changed: (void (*)()) 0x401689 <main+4>
	    (gdb) maintenance print record-instruction -6
	    Not enough recorded history

	But when debugging remotely:

	    (gdb) maintenance print record-instruction 0
	    Register rdx changed: 140737488346728
	    Register rip changed: (void (*)()) 0x401690 <main+11>
	    (gdb) maintenance print record-instruction -1
	    4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
	    Register rip changed: (void (*)()) 0x401689 <main+4>
	    (gdb) maintenance print record-instruction -2
	    Not enough recorded history

	In this list, we only have entries for the beginning of each line.  This
	is because of the remote target's support for range stepping.  The
	record-full layer can only record instructions when the underlying
	process target reports a stop.  With range stepping, the remote target
	single-steps multiple instructions at a time, so the record-full target
	doesn't get to see and record them all.

	Fix this by making the record-full layer disable range-stepping
	before handing the resume request to the beneath layer, forcing the
	remote target to report stops for each instruction.

	Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d

2023-04-28  Keith Seitz  <keiths@redhat.com>

	Allow strings with printf/eval
	PR 13098 explains that if a user attempts to use a string with either
	`printf' (or `eval'), gdb returns an error (inferior not running):

	(gdb) printf "%s\n", "hello"
	evaluation of this expression requires the target program to be active

	However, the parser can certainly handle this case:

	(gdb) p "hello"
	$1 = "hello"

	This discrepancy occurs because printf_c_string does not handle
	this specific case.  The passed-in value that we are attempting to print
	as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.

	printf_c_string will only attempt to print a string from the value's
	contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
	type is considered a string type:

	  if (value->type ()->code () != TYPE_CODE_PTR
	      && value->lval () == lval_internalvar
	      && c_is_string_type_p (value->type ()))
	    {
	      ...
	    }

	Otherwise, it attempts to read the value of the string from the target's
	memory (which is what actually generates the "evaluation of this ..."
	error message).

2023-04-28  Tom Tromey  <tromey@adacore.com>

	Move find_minimal_symbol_address to minsyms.c
	I found find_minimal_symbol_address in parse.c, but it seems to me
	that it belongs in minsyms.c.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-04-28  Tom Tromey  <tromey@adacore.com>

	Do not change type in get_discrete_low_bound
	get_discrete_low_bound has this code:

	    /* Set unsigned indicator if warranted.  */
	    if (low >= 0)
	      type->set_is_unsigned (true);

	It's bad to modify a type in a getter like this, so this patch removes
	this code.  FWIW I looked and this code has been there since at least
	1999 (it was in the initial sourceware import).

	Types in general would benefit from const-ification, which would
	probably reveal more code like this, but I haven't attempted that.

	Regression tested on x86-64 Fedora 36.

	Reviewed-by: Kevin Buettner <kevinb@redhat.com>

2023-04-28  Tom Tromey  <tromey@adacore.com>

	Remove @var from @defun in Python documentation
	Eli pointed out that @var isn't needed in @defun in Texinfo.  This
	patch removes the cases I found in python.texi.  I also renamed some
	variables in one spot, because "-" isn't valid in a Python variable
	name.

2023-04-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: additional test fixes after gdb_test changes
	After this commit:

	  commit e2f620135d92f7cd670af4e524fffec7ac307666
	  Date:   Thu Mar 30 13:26:25 2023 +0100

	      gdb/testsuite: change newline patterns used in gdb_test

	There were some regressions in gdb.trace/*.exp tests when run with the
	native-gdbserver board.  This commit fixes these regressions.

	All the problems are caused by unnecessary trailing newline characters
	included in the patterns passed to gdb_test.  After the above commit
	the testsuite is stricter when matching trailing newlines, and so the
	additional trailing newline characters are now causing the test to
	fail.  Fix by removing all the excess trailing newline characters.

	In some cases this cleanup means we should use gdb_test_no_output,
	I've done that where appropriate.  In a couple of other places I've
	made use of multi_line to better build the expected output pattern.

2023-04-28  H.J. Lu  <hjl.tools@gmail.com>

	ld: Use run_cc_link_tests for PR ld/26391 tests
	Use run_cc_link_tests for PR ld/26391 tests to compile PR ld/26391 tests
	in C.

		PR ld/30002
		* testsuite/ld-elf/elf.exp: Use run_cc_link_tests for PR ld/26391
		tests.

2023-04-28  Eli Zaretskii  <eliz@gnu.org>

	Fix a typo in gdb.texinfo.

2023-04-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Enable x0 base relaxation for relax_pc even if --no-relax-gp.
	Let --no-relax-gp only disable the gp relaxation for lui and pcrel
	relaxations, since x0 base and gp relaxations are different optimizations
	in fact, but just use the same function to handle.

	bfd/
		* elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui,
		set gp to zero when --no-relax-gp, then we should still keep the
		x0 base relaxation.
		(_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when
		--no-relax-gp, we will disable the gp relaxation in the
		_bfd_riscv_relax_pc.

2023-04-28  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Relax R_RISCV_[PCREL_]LO12_I/S to R_RISCV_GPREL_I/S for undefined weak.
	bfd/
		*elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol,
		just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't
		update the rs1 to zero until relocate_section.
		(_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S.

2023-04-28  Jan Beulich  <jbeulich@suse.com>

	x86: limit data passed to i386_dis_printf()
	The function doesn't use "ins" for other than retrieving "info". Remove
	a thus pointless level of indirection.

	x86: limit data passed to prefix_name()
	Make apparent that neither what "ins" points to nor, in particular, that
	"ins->info->private_data" is actually used in the function.

	x86/Intel: reduce ELF/PE conditional scope in x86_cons()
	All the Intel syntax related state adjustments apply independent of
	target or object format.

	gas: move shift count check
	... out of mainline code, grouping together the two case labels. This
	then also make more obvious that the comment there applies to both forms
	of shifts.

	x86: rework AMX control insn disassembly
	Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth,
	and only then prefix, resulting in fewer table entries. Note that in the
	course of the re-work
	- TILEZERO has a previously missing decode step through rm_table[]
	  added,
	- a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an
	  infix).

2023-04-28  Jan Beulich  <jbeulich@suse.com>

	x86: rework AMX multiplication insn disassembly
	Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
	and prefix last, resulting in fewer table entries. Note that in the
	course of the re-work wrong M_0 suffixes are also corrected to be M_1
	(partly infixes now).

	Since it ended up confusing while testing the change, also adjust the
	test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).

2023-04-28  Alan Modra  <amodra@gmail.com>

	Re: Keeping track of rs6000-coff archive element pointers
	Commit de7b90610e9e left a hole in the element checking, explained by
	the comment added to _bfd_xcoff_openr_next_archived_file.  While
	fixing this, tidy some types used to hold unsigned values so that
	casts are not needed to avoid signed/unsigned comparison warnings.
	Also tidy a few things in xcoff.h.

	bfd/
		* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check
		that we aren't pointing back at the last element.  Make
		filestart a ufile_ptr.  Update for xcoff_artdata change.
		(_bfd_strntol, _bfd_strntoll): Return unsigned values.
		(_bfd_xcoff_slurp_armap): Make off a ufile_ptr.
		(add_ranges): Update for xcoff_artdata change.
		* libbfd-in.h (struct artdata): Make first_file_filepos a
		ufile_ptr.
		* libbfd.h: Regenerate.
	include/
		* coff/xcoff.h (struct xcoff_artdata): Replace min_elt with
		ar_hdr_size.
		(xcoff_big_format_p): In the !SMALL_ARCHIVE case return true
		for anything but a small archive.

2023-04-28  Alan Modra  <amodra@gmail.com>

	Remove deprecated bfd_read
	20+ years is long enough to warn.

		* bfd-in.h (bfd_read, bfd_write): Don't define
		(_bfd_warn_deprecated): Don't declare.
		* bfd-in2.h: Regenerate.
		* libbfd.c (_bfd_warn_deprecated): Delete.

2023-04-28  Alan Modra  <amodra@gmail.com>

	Make bfd_byte an int8_t, flagword a uint32_t
		* bfd-in.h (bfd_byte): Typedef as int8_t.
		(flagword): Typedef as uint32_t.
		(bfd_vma, bfd_signed_vma, bfd_size_type, symvalue): Use stdint
		types in !BFD64 case.
		* bfd-in2.h: Regenerate.

2023-04-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-27  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: bpf: fix tests for pseudo-c syntax
	This patch fixes the GAS BPF testsuite so the tests for pseudo-c
	syntax are actually executed.

	2023-04-27  Jose E. Marchesi  <jose.marchesi@oracle.com>

		* testsuite/gas/bpf/mem.dump: New file.
		* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
		* testsuite/gas/bpf/mem.d: #dump mem.dump.
		* testsuite/gas/bpf/lddw.dump: New file.
		* testsuite/gas/bpf/lddw-pseudoc.d: Likewise.
		* testsuite/gas/bpf/lddw.d: #dump lddw.dump.
		* testsuite/gas/bpf/jump.dump: New file.
		* testsuite/gas/bpf/jump-pseudoc.d: Likewise
		* testsuite/gas/bpf/jump.d: #dump jump.dump.
		* testsuite/gas/bpf/jump32.dump: New file.
		* testsuite/gas/bpf/jump32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/jump32.d: #dump jump32.dump.
		* testsuite/gas/bpf/lddw-be.dump: New file.
		* testsuite/gas/bpf/lddw-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/lddw-be.d: #dump lddw-be.dump.
		* testsuite/gas/bpf/indcall-1.dump: New file.
		* testsuite/gas/bpf/indcall-1-pseudoc.d: Likewise.
		* testsuite/gas/bpf/indcall-1.d: #dump indcall-1.dump.
		* testsuite/gas/bpf/indcall-1-pseudoc.s (main): Fix lddw
		instruction.
		* testsuite/gas/bpf/atomic.dump: New file.
		* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
		* testsuite/gas/bpf/atomic.d: #dump atomic.dump.
		* testsuite/gas/bpf/alu32.dump: New file.
		* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu32.d: #dump alu32.dump.
		* testsuite/gas/bpf/alu.dump: New file.
		* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu.d: #dump alu.dump.

		* testsuite/gas/bpf/alu-be.dump: New file.
		* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
		* testsuite/gas/bpf/alu-be.d: #dump alu-be.dump.
		* testsuite/gas/bpf/alu32-be-pseudoc.d: New file.
		* testsuite/gas/bpf/alu32-be-dump: Likewise.
		* testsuite/gas/bpf/alu32-be.d: #dump alu32-be-dump.
		* testsuite/gas/bpf/bpf.exp: Run *-pseudoc tests.

2023-04-27  Tom Tromey  <tromey@adacore.com>

	Avoid some compiler warnings in gdb.ada
	Running gdb.ada/verylong.exp shows a warning from the Ada compiler:

	prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default]

	This patch fixes the problem, and another similar one in
	unchecked_union.exp.

2023-04-27  Michael Matz  <matz@suse.de>

	Fix PR30358, performance with --sort-section
	since af31506c we only use the binary tree when section sorting is
	required.  While its unbalanced and hence can degrade to a linear list
	it should otherwise have been equivalent to the old code relying on
	insertion sort.  Unfortunately it was not.  The old code directly used
	lang_add_section to populate the sorted list, the new code first
	populates the tree and only then does lang_add_section on the sorted
	result.

	In the testcase we have very many linkonce section groups, and hence
	lang_add_section won't actually insert anything for most of them.  That
	limited the to-be-sorted list length previously.  The tree-sorting code
	OTOH first created a tree of all candidates sections, including those
	that wouldn't be inserted by lang_add_section, hence increasing the size
	of the sorting problem.  In the testcase the chain length went from
	about 1500 to 106000, and in the degenerated case (as in the testcase)
	that goes in quadratically.

	This splits out most of the early-out code from lang_add_section to its
	own function and uses the latter to avoid inserting into the tree.  This
	refactoring slightly changes the order of early-out tests (the ones
	based on section flags is now done last, and only in lang_add_section).
	The new function is not a pure predicate: it can give warnings and it
	might change output_section, like the old early-out code did.  I have
	also added a skip-warning case in the first discard case, whose
	non-existence seemed to have been an oversight.

		PR 30358
		* ldlang.c (wont_add_section_p): Split out from ...
		(lang_add_section): ... here.
		(output_section_callback_sort): Use wont_add_section_p to not
		always add sections to the sort tree.

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: extend the documentation of the jump command
	This commit addresses PR gdb/7946.  While checking for bugs relating
	to the jump command I noticed a long standing bug that points out a
	deficiency with GDB's documentation of the jump command.

	The bug points out that 'jump 0x...' is not always the same as 'set
	$pc = 0x...' and then 'continue'.  Writing directly to the $pc
	register does not update any auxiliary state, e.g. $npc on SPARC,
	while using 'jump' does.

	It felt like this would be an easy issue to address by adding a
	paragraph to the docs, so I took a stab at writing something suitable.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7946

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: special case '^' in gdb_test pattern
	In this commit I propose that we add special handling for the '^' when
	used at the start of a gdb_test pattern.  Consider this usage:

	  gdb_test "some_command" "^command output pattern"

	I think the intention here is pretty clear - run 'some_command', and
	the output from the command should be exactly 'command output
	pattern'.

	After the previous commit which tightened up how gdb_test matches the
	final newline and prompt we know that the only thing after the output
	pattern will be a single newline and prompt, and the leading '^'
	ensures that there's no output before 'command output pattern', so
	this will do what I want, right?

	... except it doesn't.  The command itself will also needs to be
	matched, so I should really write:

	  gdb_test "some_command" "^some_command\r\ncommand output pattern"

	which will do what I want, right?  Well, that's fine until I change
	the command and include some regexp character, then I have to write:

	  gdb_test "some_command" \
	    "^[string_to_regexp some_command]\r\ncommand output pattern"

	but this all gets a bit verbose, so in most cases I simply don't
	bother anchoring the output with a '^', and a quick scan of the
	testsuite would indicate that most other folk don't both either.

	What I propose is this: the *only* thing that can appear immediately
	after the '^' is the command converted into a regexp, so lets do that
	automatically, moving the work into gdb_test.  Thus, when I write:

	  gdb_test "some_command" "^command output pattern"

	Inside gdb_test we will spot the leading '^' in the pattern, and
	inject the regexp version of the command after the '^', followed by a
	'\r\n'.

	My hope is that given this new ability, folk will be more inclined to
	anchor their output patterns when this makes sense to do so.  This
	should increase our ability to catch any unexpected output from GDB
	that appears as a result of running a particular command.

	There is one problem case we need to consider, sometime people do
	this:

	  gdb_test "" "^expected output pattern"

	In this case no command is sent to GDB, but we are still expecting
	some output from GDB.  This might be a result of some asynchronous
	event for example.  As there is no command sent to GDB (from the
	gdb_test) there will be no command text to parse.

	In this case my proposed new feature injects the command regexp, which
	is the empty string (as the command itself is empty), but still
	injects the '\r\n' after the command regexp, thus we end up with this
	pattern:

	  ^\r\nexpected output pattern

	This extra '\r\n' is not what we should expected here, and so there is
	a special case inside gdb_test -- if the command is empty then don't
	add anything after the '^' character.

	There are a bunch of tests that do already use '^' followed by the
	command, and these can all be simplified in this commit.

	I've tried to run all the tests that I can to check this commit, but I
	am certain that there will be some tests that I manage to miss.
	Apologies for any regressions this commit causes, hopefully fixing the
	regressions will not be too hard.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: change newline patterns used in gdb_test
	This commit makes two changes to how we match newline characters in
	the gdb_test proc.

	First, for the newline pattern between the command output and the
	prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.

	The old pattern would spot multiple newlines, and so there are a few
	places where, as part of this commit, I've needed to add an extra
	trailing '\r\n' to the pattern in the main test file, where GDB's
	output actually includes a blank line.

	But I think this is a good thing.  If a command produces a blank line
	then we should be checking for it, the current gdb_test doesn't do
	that.  But also, with the current gdb_test, if a blank line suddenly
	appears in the output, this is going to be silently ignored, and I
	think this is wrong, the test should fail in that case.

	Additionally, the existing pattern will happily match a partial
	newline.  There are a strangely large number of tests that end with a
	random '.' character.  Not matching a literal period, but matching any
	single character, this is then matching half of the trailing newline
	sequence, while the \[\r\n\]+ in gdb_test is matching the other half
	of the sequence.  I can think of no reason why this would be
	intentional, I suspect that the expected output at one time included a
	period, which has since been remove, but I haven't bothered to check
	on this.  In this commit I've removed all these unneeded trailing '.'
	characters.

	The basic rule of gdb_test after this is that the expected pattern
	needs to match everything up to, but not including the newline
	sequence immediately before the GDB prompt.  This is generally how the
	proc is used anyway, so in almost all cases, this commit represents no
	significant change.

	Second, while I was cleaning up newline matching in gdb_test, I've
	also removed the '[\r\n]*' that was added to the start of the pattern
	passed to gdb_test_multiple.

	The addition of this pattern adds no value.  If the user pattern
	matches at the start of a line then this would match against the
	newline sequence.  But, due to the '*', if the user pattern doesn't
	match at the start of a line then this group doesn't care, it'll
	happily match nothing.

	As such, there's no value to it, it just adds more complexity for no
	gain, so I'm removing it.  No tests will need updating as a
	consequence of this part of the patch.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: use 'return' in gdb_test_no_output
	A TCL proc will return the return value of the last command executed
	within the proc's body if there is no explicit return call, so
	gdb_test_no_output is already returning the return value of
	gdb_test_multiple.

	However, I'm not a fan of (relying on) this implicit return value
	behaviour -- I prefer to be explicit about what we are doing.  So in
	this commit I have extended the comment on gdb_test_no_output to
	document the possible return values (just as gdb_test does), and
	explicitly call return.

	This should make no different to our testing, but I think it's clearer
	now what the gdb_test_no_output proc is expected to do.

	The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the
	return value of gdb_test_no_output, and continue to pass after this
	change.

	I also spotted that gdb.base/watchpoint.exp could be updated to make
	use of gdb_test_no_output, so I did that.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove some trailing newlines from warning messages
	While working on a later patch in this series, which tightens up some
	of our pattern matching when using gdb_test, I ran into some failures
	caused by some warnings having a trailing newline character.

	The warning function already adds a trailing newline, and it is my
	understanding that we should not be adding a second by including a
	newline at the end of any warning message.

	The problem cases I found were in language.c and remote.c, in this
	patch I fix the cases I hit, but I also checked all the other warning
	calls in these two files and removed any additional trailing newlines
	I found.

	In remote.c the warning actually had a newline character in the middle
	of the warning message (in addition to the trailing newline), which
	I've removed.  I don't think it's helpful to forcibly split a warning
	as was done here -- in the middle of a sentence.  Additionally, the
	message isn't even that long (71 characters), so I think removing this
	newline is an improvement.

	None of the expected test result need updating with this commit,
	currently the patterns in gdb_test will match one or more newline
	sequences, so the tests are as happy with one newline (after this
	commit) as they are with two newlines (before this commit).  A later
	commit will change gdb_test so that it is not so forgiving, and these
	warnings would have caused some failures.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp
	I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
	fail when run from a particular directory.

	The test tries to find the number of the first internal breakpoint
	using this proc:

	  proc get_first_maint_bp_num { } {
	      gdb_test_multiple "maint info break" "find first internal bp num" {
	  	-re -wrap "(-\[0-9\]).*" {
	  	    return $expect_out(1,string)
	  	}
	      }
	      return ""
	  }

	The problem is, at the time we issue 'maint info break' there are both
	internal breakpoint and non-internal (user created) breakpoints in
	place.  The user created breakpoints include the path to the source
	file.

	Sometimes, I'll be working from a directory that includes a number,
	like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
	matches the '-1' from 'blah-1'.  In this case there's no significant
	problem as it turns out that -1 is the number of the first internal
	breakpoint.

	Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
	case the above pattern patches '-4' from 'blah-4'.  It turns out this
	is also not a problem -- the test doesn't actually need the first
	internal breakpoint number, it just needs the number of any internal
	breakpoint.

	But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
	which case the pattern above matches '-0' from 'blah-0', and in this
	case the test fails - there is no internal breakpoint '-0'.

	Fix this by spotting that the internal breakpoint numbers always
	occurs after a '\r\n', and that they never start with a 0.  Our
	pattern becomes:

	  	-re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
	  	    return $expect_out(1,string)
	  	}

	After this I'm no longer seeing any failures.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-27  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, doc: add index entry for the $_inferior_thread_count convenience var
	Add a marker in the documentation for indexing the $_inferior_thread_count
	variable.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-04-27  Nick Clifton  <nickc@redhat.com>

	Add support for %x and %lx formats to the linker's vinfo() function.

2023-04-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-26  Philipp Tomsich  <philipp.tomsich@vrull.eu>

	    RISC-V: Support XVentanaCondOps extension
	    Ventana Micro has published the specification for their
	    XVentanaCondOps ("conditional ops") extension at
	      https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
	    which contains two new instructions
	      - vt.maskc
	      - vt.maskcn
	    that can be used in constructing branchless sequences for
	    various conditional-arithmetic, conditional-logical, and
	    conditional-select operations.

	    To support such vendor-defined instructions in the mainline binutils,
	    this change also adds a riscv_supported_vendor_x_ext secondary
	    dispatch table (but also keeps the behaviour of allowing any unknow
	    X-extension to be specified in addition to the known ones from this
	    table).

	    As discussed, this change already includes the planned/agreed future
	    requirements for X-extensions (which are likely to be captured in the
	    riscv-toolchain-conventions repository):
	      - a public specification document is available (see above) and is
	        referenced from the gas-documentation
	      - the naming follows chapter 27 of the RISC-V ISA specification
	      - instructions are prefixed by a vendor-prefix (vt for Ventana)
	        to ensure that they neither conflict with future standard
	        extensions nor clash with other vendors

	    bfd/ChangeLog:

	            * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
	            (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.

	    gas/ChangeLog:

	            * doc/c-riscv.texi: Add section to list custom extensions and
	              their documentation URLs.
	            * testsuite/gas/riscv/x-ventana-condops.d: New test.
	            * testsuite/gas/riscv/x-ventana-condops.s: New test.

	    include/ChangeLog:

	            * opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
	            * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.

	    opcodes/ChangeLog:

	            * riscv-opc.c: Add vt.maskc and vt.maskcn.

	    Series-version: 1
	    Series-to: binutils@sourceware.org
	    Series-cc: Kito Cheng <kito.cheng@sifive.com>
	    Series-cc: Nelson Chu <nelson.chu@sifive.com>
	    Series-cc: Greg Favor <gfavor@ventanamicro.com>
	    Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>

2023-04-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

	gas: documentation for the BPF pseudo-c asm syntax
	This patch expands the GAS manual in order to specify the alternate
	pseudo-C assembly syntax used in BPF, and now supported by the
	assembler.

	gas/ChangeLog:

	2023-04-19  Jose E. Marchesi  <jose.marchesi@oracle.com>

		PR gas/29757
		* doc/c-bpf.texi (BPF Pseudo-C Syntax): New section.

2023-04-26  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

	gas: BPF pseudo-c syntax tests
	This patch expands the GAS BPF testsuite in order to also test the
	alternative pseudo-C syntax used in BPF assembly.

	This includes three main changes:

	- Some general GAS tests involving assignment and equality operands in
	  expressions (such as = and ==) are disabled in bpf-* targets,
	  because the syntax collides with the pseudo-C BPF assembly syntax.

	- New tests are added to the BPF GAS testsuite that test the pseudo-c
	syntax.  Tests for all BPF instructions are included.

	- New tests are added to the BPF GAS testsuite that test the support
	  for both syntaxes in the same source.

	gas/ChangeLog:

	2023-04-20  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

		PR gas/29728
		* testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
		targets.
		* testsuite/gas/all/eqv-dot.d: Likewise.
		* testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.
		* testsuite/gas/bpf/alu-pseudoc.s: New file.
		* testsuite/gas/bpf/pseudoc-normal.s: Likewise.
		* testsuite/gas/bpf/pseudoc-normal.d: Likewise.
		* testsuite/gas/bpf/pseudoc-normal-be.d: Likewise.
		* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
		* testsuite/gas/bpf/lddw-pseudoc.s: Likewise.
		* testsuite/gas/bpf/jump32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/jump-pseudoc.s: Likewise.
		* testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise.
		* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
		* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
		* testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests.

2023-04-26  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

	gas: support for the BPF pseudo-c assembly syntax
	This patch adds support to the GNU assembler for an alternative
	assembly syntax used in BPF.  This syntax is C-like and very
	unconventional for an assembly language, but it is generated by
	clang/llvm and is also used in inline asm templates in kernel code, so
	we ought to support it.

	After this patch, the assembler is able to parse instructions in both
	supported syntax: the normal assembly-like syntax and the pseudo-C
	syntax.  Instruction formats can be mixed in the source program: the
	assembler recognizes the right syntax to use.

	gas/ChangeLog:

	2023-04-20  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

		PR gas/29728
		* config/tc-bpf.h (TC_EQUAL_IN_INSN): Define.
		* config/tc-bpf.c (LEX_IS_SYMBOL_COMPONENT): Define.
		(LEX_IS_WHITESPACE): Likewise.
		(LEX_IS_NEWLINE): Likewise.
		(LEX_IS_ARITHM_OP): Likewise.
		(LEX_IS_STAR): Likewise.
		(LEX_IS_CLSE_BR): Likewise.
		(LEX_IS_OPEN_BR): Likewise.
		(LEX_IS_EQUAL): Likewise.
		(LEX_IS_EXCLA): Likewise.
		(ST_EOI): Likewise.
		(MAX_TOKEN_SZ): Likewise.
		(init_pseudoc_lex): New function.
		(md_begin): Call init_pseudoc_lex.
		(valid_expr): New function.
		(build_bpf_non_generic_load): Likewise.
		(build_bpf_atomic_insn): Likewise.
		(build_bpf_jmp_insn): Likewise.
		(build_bpf_arithm_insn): Likewise.
		(build_bpf_endianness): Likewise.
		(build_bpf_load_store_insn): Likewise.
		(look_for_reserved_word): Likewise.
		(is_register): Likewise.
		(is_cast): Likewise.
		(get_token): Likewise.
		(bpf_pseudoc_to_normal_syntax): Likewise.
		(md_assemble): Try pseudo-C syntax if an instruction cannot be
		parsed.

2023-04-26  Jose E. Marchesi  <jose.marchesi@oracle.com>

	sim: bpf: update to new BPF relocations
	This patch updates the BPF GNU sim testsuite in order to match the new
	BPF relocations introduced in binutils in a recent patch [1].

	[1] https://sourceware.org/pipermail/binutils/2023-March/126429.html

2023-04-26  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix length of status line string
	In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
	...
	+  std::string string_val = string.release ();
	...
	without updating subsequent uses of string.size (), which returns 0 after the
	string.release () call.

	Fix this by:
	- using string_val.size () instead of string.size (), and
	- adding an assert that would have caught this regression.

	Tested on x86_64-linux.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
	PR tui/30389
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389

2023-04-26  Tom Tromey  <tromey@adacore.com>

	Rewrite gdb_mpz::operator==
	Simon pointed out that the recent changes to gdb_mpz caused a build
	failure on amd64 macOS.  It turns out to be somewhat difficult to
	overload a method in a way that will work "naturally" for all integer
	types; especially in a case like gdb_mpz::operator==, where it's
	desirable to special case all integer types that are no wider than
	'long'.

	After a false start, I came up with this patch, which seems to work.
	It applies the desirable GMP special cases directly in the body,
	rather than via overloads.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-04-26  Luis Machado  <luis.machado@arm.com>

	Updated debug architecture version checks for fbsd
	There are two new debug architecture version entries.  I updated the
	code for Linux, but fbsd also needs updating.

	This patch does this, and should be pretty straightforward.

	I can't test this on native fbsd, but I'm fairly confident it should
	work.

2023-04-26  Luis Machado  <luis.machado@arm.com>

	Add new debug architecture version
	Teach gdb about a new debug architecture version for AArch64 (0x11).

	No user-visible changes.

	Regression-tested on aarch64-linux Ubuntu 20.04/22.04.

2023-04-26  Alan Modra  <amodra@gmail.com>

	i386-dis.c UB shift and other tidies
	1) i386-dis.c:12055:11: runtime error: left shift of negative value -1
	Bit twiddling is best done unsigned, due to UB on overflow of signed
	expressions.  Fix this by using bfd_vma rather than bfd_signed_vma
	everywhere in i386-dis.c except print_displacement.

	2) Return get32s and get16 value in a bfd_vma, reducing the need for
	temp variables.

	3) Introduce get16s and get8s functions to simplify the code.

	4) With some optimisation options gcc-13 legitimately complains about
	a fall-through in OP_I.  Fix that.  OP_I also doesn't need to use
	"mask" which was wrong for w_mode anyway.

	5) Masking with & 0xffffffff is better than casting to unsigned.  We
	don't know for sure that unsigned int is 32-bit.

	6) We also don't know that unsigned char is 8 bits.  Mask codep
	accesses everywhere.  I don't expect binutils will work on anything
	other than an 8-bit char host, but if we are masking codep accesses in
	some places we might as well be consistent.  (Better would be to use
	stdint.h types more in binutils.)

2023-04-26  Alan Modra  <amodra@gmail.com>

	binutils runtest $CC
	I noticed in the binutile Makefile that runtest is being invoked with
	CC, CC_FOR_BUILD and other compiler related flags in the environment.
	That doesn't work.  Those variables ought to be passed on the runtest
	command line.

	After fixing that I had some fails due to binutils testprog.c now
	being compiled with the default "-g -O2" picked up in
	CFLAGS_FOR_TARGET.  Hack around that by passing -O0.

	Also, with the binutils testsuite now taking notice of CC_FOR_TARGET,
	I found a couple of debuginfod.exp fails with one of my compilers that
	happened to be built without --debug-id being enabled by default.

		* Makefile.am (check-DEJAGNU): Pass $CC and other variable on
		the runtest command line rather than futilely in the
		environment.  Add -O0 to CFLAGS_FOR_TARGET.
		* Makefile.in: Regenerate.
		* testsuite/binutils-all/debuginfod.exp: Compile testprog.c
		with -Wl,--build-id.

2023-04-26  Alan Modra  <amodra@gmail.com>

	Avoid another -Werror=dangling-pointer
	write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used

		* write.c (chain_frchains_together_1): Rewrite loop as a do
		while to avoid false positive -Wdangling-pointer.

2023-04-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-25  Tom Tromey  <tromey@adacore.com>

	Use scoped_restore in varobj.c
	One spot in varobj.c should use scoped_restore to save and restore
	input_radix.  Note that the current code may fail to restore it on
	error, so this patch fixes a latent bug.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-04-25  Tom Tromey  <tromey@adacore.com>

	Remove some "goto"s from parse.c
	parser_state::push_dollar has some unnecessary "goto"s.  Replacing
	them cleans up the code.  Regression tested on x86-64 Fedora 36.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-04-25  Michael Matz  <matz@suse.de>

	section-select: Fix performance problem (PR30367)
	when using many wild-statements with non-wildcard filenames we
	were running into quadraticness via repeatedly using lookup_name
	on a long list of loaded files.  I've originally retained using
	lookup_name because that preserved existing behaviour most obviously.
	In particular in matching wild-statements when using a non-wildcard
	filename it matches against local_sym_name, not the filename member.
	If the wildspec would have an archive-spec or a wildcard it would use
	the filename member, though.  Also it would load the named file
	(and ignore it, as being not equal to the currently considered
	input-statement).

	Rewrite this to not use lookup_name but retain the comparison
	against local_sym_name with a comment to that effect.

		PR 30367
		* ldlang.c (walk_wild_section_match): Don't use lookup_name
		but directly compare spec and local_sym_name.

2023-04-25  Jan Beulich  <jbeulich@suse.com>

	RISC-V: adjust logic to avoid register name symbols
	Special casing GPR names in my_getSmallExpression() leads to a number of
	inconsistencies. Generalize this by utilizing the md_parse_name() hook,
	limited to when instruction operands are being parsed (really: probed).
	Then both the GPR lookup there and the yet more ad hoc workaround for
	PR/gas 29940 can be removed (including its extension needed for making
	the compressed form JAL work again).

	RISC-V: test for expected / no unexpected symbols
	Both the temporary workaround for PR/gas 29940 and the existing special
	casing of GPRs in my_getSmallExpression() aren't really tested anywhere
	(i.e. with the workarounds remove testing would still succeed). Nor is
	there any test for uses of symbols with names matching GPRs, where such
	is permitted. Before altering how this is to be dealt with, install two
	testcases covering the expected behavior. (For now this includes only
	known affected insns; re-ordering of entries in riscv_opcodes[] could,
	however, yield more of them.)

	RISC-V: don't recognize bogus relocations
	With my_getSmallExpression() consistently and silently failing on
	relocation operators not fitting an insn, it is no longer necessary to
	hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a
	subsequent parsing attempt for another operand combination might
	succeed). This also eliminates the latent problem of percent_op_itype[]
	and percent_op_stype[] growing a non-identical set of recognized
	relocation operators.

	RISC-V: avoid redundant and misleading/wrong error messages
	The use of a wrong (for the insn) relocation operator (or a future one
	which simply isn't recognized by older gas yet) doesn't render the (rest
	of the) expression "bad". Furthermore alongside the error from
	expression() in most cases the parser would emit another error then
	anyway. Suppress the call to my_getExpression() in such a case,
	arranging for a guaranteed subsequent error message by marking the
	expression "illegal".

	RISC-V: drop "percent_op" parameter from my_getOpcodeExpression()
	Both callers check for no relocations, so there's no point parsing for
	some. Have the function pass percent_op_null into
	my_getSmallExpression(). Note that there's no point passing
	percent_op_itype: Elsewhere, especially when processing compressed alias
	insns ahead of non-alias ones, this has the effect of avoiding "bad
	expression" errors when another parsing pass may follow (and succeed).
	Here, however, all alternative forms of an insn type will again start
	with the same O4 or O2, so avoiding errors earlier on doesn't really
	help. Plus constructs with a relocation specifier (as percent_op_itype
	would permit) can't be specified anyway, as the scrubber eats the
	whitespace between .insn's type and the O4 or O2 expression when that
	starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
	riscv_ip() looks only for whitespace when finding the end of a mnemonic.

	RISC-V: minor effort reduction in relocation specifier parsing
	The sole caller of parse_relocation() has already checked for the %
	prefix, so there's no need to check for it again in the strncasecmp()
	and there's also no reason to make the involved string literals longer
	than necessary.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/empty.exp
	In test-case gdb.tui/empty.exp we run into:
	...
	WARNING: timeout in accept_gdb_output
	PASS: gdb.tui/empty.exp: src: 90x40: box 1
	...

	We timeout here in Term::resize:
	...
		# Due to the strange column resizing behavior, and because we
		# don't care about this intermediate resize, we don't check
		# the size here.
		wait_for "@@ resize done $_resize_count"
	...
	because the string we're trying to match is split over two lines:
	...
	25 -----------------------------------------------------------------------------+No
	26 ne No process In:                                               L??   PC: ?? @@
	27 resize done 0, size = 79x40
	28 (gdb)
	...

	Fix this by dropping the "@@ " prefix.

	Tested on x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/completion.exp
	With test-case gdb.tui/completion.exp, we run into:
	...
	WARNING: timeout in accept_gdb_output
	PASS: gdb.tui/completion.exp: check focus completions
	...

	The timeout happens in this command:
	...
	Term::command "layout src"
	...
	which waits for:
	- "(gdb) layout src", and then
	- "(gdb) ".

	Because the "layout src" command enables the TUI there's just a prompt.

	Fix this by using Term::command_no_prompt_prefix.

	Tested on x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/new-layout.exp
	In test-case gdb.tui/new-layout.exp we run into:
	...
	WARNING: timeout in accept_gdb_output
	PASS: gdb.tui/new-layout.exp: layout=cmd_only {cmd 1} {} {}: \
	  bottom of cmd window is blank
	...

	The timeout happens here:
	...
	    Term::command "layout src"
	...

	Before the "layout src" command we have:
	...
	Screen Dump (size 80 columns x 24 rows, cursor at column 46, row 7):
	    0 +-tui-layout.c-------------------------+(gdb) layout example3
	    1 |       20 {                           |(gdb) layout src
	    2 |       21   return 0;                 |(gdb) winheight cmd 8
	    3 |       22 }                           |(gdb) layout example4
	    4 |       23                             |(gdb) layout src
	    5 |       24                             |(gdb) winheight cmd 8
	    6 |       25                             |(gdb) layout example5
	    7 |       26                             |(gdb)
	    8 |       27                             |
	    9 |       28                             |
	   10 |       29                             |
	   11 |       30                             |
	   12 |       31                             |
	   13 |       32                             |
	   14 |       33                             |
	   15 |       34                             |
	   16 |       35                             |
	   17 |       36                             |
	   18 |       37                             |
	   19 |       38                             |
	   20 |       39                             |
	   21 |       40                             |
	   22 +--------------------------------------+
	   23 exec No process In:                                                L??   PC: ??
	...
	and after:
	...
	Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 16):
	    0 +-tui-layout.c-----------------------------------------------------------------+
	    1 |       20 {                                                                   |
	    2 |       21   return 0;                                                         |
	    3 |       22 }                                                                   |
	    4 |       23                                                                     |
	    5 |       24                                                                     |
	    6 |       25                                                                     |
	    7 |       26                                                                     |
	    8 |       27                                                                     |
	    9 |       28                                                                     |
	   10 |       29                                                                     |
	   11 |       30                                                                     |
	   12 |       31                                                                     |
	   13 |       32                                                                     |
	   14 +------------------------------------------------------------------------------+
	   15 exec No process In:                                                L??   PC: ??
	   16 (gdb)
	   17
	   18
	   19
	   20
	   21
	   22
	   23
	...

	The Term::command "layout src" is waiting to match:
	- "(gdb) layout src", and then
	- "(gdb) ".

	The first part fails to match on a line:
	...
	|       26                             |(gdb) layout src
	...
	because it expects the prompt at the start of the line.

	Fix this by allowing the prompt at the start of a window as well.

	Tested by x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/main.exp
	With test-case gdb.tui/main.exp we run into:
	...
	WARNING: timeout in accept_gdb_output
	PASS: gdb.tui/main.exp: show main after file
	...

	The problem is that this command:
	...
	Term::command "file [standard_output_file $testfile]"
	...
	tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up
	over two lines:
	...
	   16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma
	   17 in
	   18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t
	   19 ui/main/main...
	   20 (gdb)
	...

	Fix this by matching "Reading symbols from" instead.

	Tested on x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix timeout in gdb.tui/corefile-run.exp
	With test-case gdb.tui/corefile-run.exp we run into:
	...
	WARNING: timeout in accept_gdb_output
	PASS: gdb.tui/corefile-run.exp: load corefile
	...

	The timeout happens in this command:
	...
	Term::command "core-file $core"
	...
	because it tries to match "(gdb) $cmd" but $cmd is split over two lines:
	...
	   16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co
	   17 refile-run/corefile-run.core
	   18 [New LWP 5370]
	   19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb
	   20 .tui/corefile-run/coref'.
	   21 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
	   22 #0  main () at tui-layout.c:21
	   23 (gdb)
	...

	Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead.

	Tested on x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add debug prints in Term::wait_for
	The semantics of wait_for are non-trivial, and a bit hard to understand
	sometimes.

	Add some debug prints in wait_for that make it clear:
	- what regexps we're trying to match,
	- what strings we compare to the regexps, and
	- whether there's a match or mismatch.

	I've added this ad-hoc a couple of times, and it seems that it's worth having
	readily available.

	The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the
	RUNTESTFLAGS:
	...
	$ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1"
	...

	Tested on x86_64-linux.

2023-04-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add warning for timeout in accept_gdb_output
	In accept_gdb_output we have:
	...
	            timeout {
	                # Assume a timeout means we somehow missed the
	                # expected result, and carry on.
	                return 0
	            }
	...

	The timeout is silent, and though in some places the return value is checked,
	this is not done consistently, and consequently there are silent timeouts
	when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).

	Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
	50 seconds overall:
	...
	real    1m0.275s
	user    0m10.440s
	sys     0m1.343s
	...

	With an entire testsuite run taking about 30 minutes, that is about 2.5% of
	the time spent waiting in TUI tests.

	Let's make the timeouts visible using a warning, such that they can be fixed.

	Tested on x86_64-linux.

2023-04-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix auto-indent in gdb.gdb/python-helper.exp
	When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
	(emacs).

	The problem is that this:
	...
	if { 1 } {
	    foo "{" "}"<ENTER>bar
	}
	...
	produces this:
	...
	if { 1 } {
	    foo "{" "}"
	bar
	}
	...

	Note that this doesn't happen for "{}".

	Fix this by using "\{" and "\}".

	Tested on x86_64-linux.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto
	On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
	-O2 -g -flto=auto, I run into:
	...
	FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
	FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
	FAIL: gdb.gdb/python-helper.exp: print *type->main_type
	...

	Fix the first two FAILs by using $bkptno_numopt_re.

	The last FAIL is due to:
	...
	(outer-gdb) print *type->main_type^M
	A syntax error in expression, near `->main_type'.^M
	(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
	...
	because:
	...
	(outer-gdb) print type^M
	Attempt to use a type name as an expression^M
	...

	Fix this by making the test unresolved if "print type" or
	"print type->main_type" doesn't succeed.

	On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
	-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
	not hitting.  Fix this by detecting the situation and bailing out.

	Tested on x86_64-linux.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multiple
	While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
	combination with -prompt and found out that it doesn't work, because -wrap uses
	"$gdb_prompt $" instead of $prompt_regexp.

	Fix this by making -wrap use $prompt_regexp.

	Tested on x86_64-linux.

2023-04-24  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove end_stepping_range observable
	I noticed that this observable was never notified, which means we can
	probably safely remove it.  The notification was removed in:

	    commit 243a925328f8e3184b2356bee497181049c0174f
	    Author: Pedro Alves <palves@redhat.com>
	    Date:   Wed Sep 9 18:23:24 2015 +0100

	        Replace "struct continuation" mechanism by something more extensible

	print_end_stepping_range_reason in turn becomes unused, so remote it as
	well.

	Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use -std=gnu99 for gdb.server/attach-flag.exp
	When using a compiler defaulting to -std=gnu90, we run into:
	...
	Running gdb.server/attach-flag.exp ...
	gdb compile failed, attach-flag.c: In function 'main':
	attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
	  in C99 or C11 mode
	   for (int i = 0; i < NTHREADS; i++)
	   ^~~
	attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
	  -std=gnu11 to compile your code
	...

	Fix this by using -std=gnu99.

	Tested on x86_64-linux.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.exp
	Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
	require this.

	Tested on x86_64-linux.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64le
	When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
	...
	Running gdb/testsuite/gdb.multi/multi-arch.exp ...
	gdb compile failed, In file included from /usr/include/features.h:399:0,
	                 from /usr/include/stdio.h:27,
	                 from gdb/testsuite/gdb.multi/hangout.c:18:
	/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
	  No such file or directory
	 # include <gnu/stubs-32.h>
	                           ^
	compilation terminated.
	...

	The problem is that the test-case attempts to use gcc -m32 to produce an
	executable while that's not available.

	Fix this by:
	- introduce a new caching proc have_compile_and_link_flag, and
	- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.

	Tested on:
	- x86_64-linux (openSUSE Leap 15.4), and
	- powerpc64le-linux (CentOS-7).

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add basic lmap for tcl < 8.6
	With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
	...
	ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
	ERROR: invalid command name "lmap"
	    while executing
	"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
	  dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
	...

	Fix this by adding basic lmap support for tcl version < 8.6.

	Tested on x86_64-linux.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Don't use string cat in gdb.dwarf2/dw2-abs-hi-pc.exp
	Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
	...
	set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
	...
	but that's only supported starting tcl 8.6.

	Fix this by using "expr" instead:
	...
	set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
	...

	Tested on x86_64-linux.

2023-04-24  Nick Clifton  <nickc@redhat.com>

	New georgian translation for the bfd sub-directory

2023-04-24  Alan Modra  <amodra@gmail.com>

	Revert "x86: work around compiler diagnosing dangling pointer"
	This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.

2023-04-24  Alan Modra  <amodra@gmail.com>

	gcc-13 i386-dis.c warning
	opcodes/i386-dis.c: In function ‘print_insn’:
	opcodes/i386-dis.c:9865:22: error: storing the address of local
	variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]

		* i386-dis.c (print_insn): Clear info->private_data before
		returning.

2023-04-24  Alan Modra  <amodra@gmail.com>

	asan: segfault in coff_mangle_symbols
	The testcase managed to trigger creation of a wild pointer in
	coff_slurp_symbol_table.  Stop that happening, and fix an unrelated
	problem I happened to see in bfd_coff_get_syment.

		* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
		converting n_value from a pointer to an index.
		* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
		symbol value before converting to a pointer.

2023-04-24  Alan Modra  <amodra@gmail.com>

	objcopy of archives tidy
	This makes sure the input element bfd is closed before exiting the
	loop copying elements.

		* objcopy.c (copy_archive): Rename output_bfd to output_element.
		Localise last_element.  Close this_element in more error cases.

2023-04-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Skip dap tests for tcl 8.5
	When running the dap tests on a system with tcl 8.5, we run into:
	...
	ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
	ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
	  digit, double, false, graph, integer, list, lower, print, punct, space, \
	  true, upper, wideinteger, wordchar, or xdigit
	    while executing
	"string is entier $num"
	    (procedure "num" line 16)
	    invoked from within
	...

	Fix this by:
	- requiring tcl 8.6 in allow_dap_tests, and
	- adding the missing require allow_dap_tests in gdb.dap/memory.exp.

	Tested on x86_64-linux.

2023-04-24  Jan Beulich  <jbeulich@suse.com>

	x86: work around compiler diagnosing dangling pointer
	For quite come time print_insn() has been storing the address of a local
	variable into info->private_data. Since the compiler can't know that the
	field won't be accessed again after print_insn() returns, it may kind of
	legitimately diagnose this. And recent enough gcc does as of the
	introduction of the fetch_error() return paths (replacing setjmp()-based
	error handling).

	Utilizing that neither prefix_name() nor i386_dis_printf() actually use
	info->private_data, zap the pointer in fetch_error(), after having
	retrieved it for local use.

2023-04-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-23  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: fix loongson3 llsc workaround
	-mfix-looongson3-llsc may add sync instructions not needed on some
	asm code with lots of debug info.

		PR: 30153
		* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.

2023-04-23  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: default output r6 obj if the triple is r6
	If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
	r6 objects by default.
	The triples with vendor `img` should do same.

	The examples include:
		as xx.s -o xx.o
		ld -r -b binary xx.dat -o xx.o

2023-04-23  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: support mips*64 as CPU and gnuabi64 as ABI
	For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
	used as the cpu name in triple.
	Let's recognize them by `mips*64*(el)`.

	For 64bit Ports, like Debian's mips64el and mips64r6el ports,
	`gnuabi64` is used as the abi section.
	Let's use N64 abi by default for the triple with gnuabi64.

2023-04-23  mengqinggang  <mengqinggang@loongson.cn>

	LoongArch: Fix loongarch32 test fails
	Regenerated macro_op_32.d and add skip loongarch64-*-*.

	gas/ChangeLog:

		* testsuite/gas/loongarch/macro_op_32.d: Regenerated.

	ld/ChangeLog:

		* testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated.

2023-04-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove debug prints in gdb_find_gdc
	When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
	rather than dejagnu's copy (mimicing what happens with an older dejagnu
	without find_gdc), I run into these debug prints:
	...
	Tool Root: /data/vries/gdb/leap-15-4/build
	CC: gdc
	...

	Remove these.

	Tested on x86_64-linux.

2023-04-22  WANG Rui  <r@hev.cc>

	gdb: Fix false match issue in skip_prologue_using_linetable
	[ Changes in v2:
	  - rebase on trunk
	  Changes in v3:
	  - add test-case ]

	We should exclude matches to the ending PC to prevent false matches with the
	next function, as prologue_end is located at the end PC.

	  <fun1>:
	    0x00: ... <-- start_pc
	    0x04: ...
	    0x08: ... <-- breakpoint
	    0x0c: ret
	  <fun2>:
	    0x10: ret <-- end_pc | prologue_end of fun2

	Tested on x86_64-linux.

	Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
	Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
	Approved-by: Kevin Buettner <kevinb@redhat.com>

	[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html

	PR symtab/30369
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369

2023-04-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove language_auto
	I think that the language_auto enumerator and the auto_language class
	can be removed.  There isn't really an "auto" language, it's only a
	construct of the "set language" command to say "pick the appropriate
	language automatically".  But "auto" is never the current language.  The
	`current_language` points to the current effective language, and the
	fact that we're in "auto language" mode is noted by the language_mode
	global.

	 - Change set_language to handle the "auto" (and "local", which is a
	   synonym) early, instead of in the for loop.  I think it makes the two
	   cases (auto vs explicit language) more clearly separated anyway.

	 - Adjust add_set_language_command to hard-code the "auto" string,
	   instead of using the "auto" language definition.

	 - Remove auto_language, rename auto_or_unknown_language to
	   unknown_language and move the bits of the existing unknown_language
	   in there.

	 - Remove the set_language at the end of _initialize_language.  I think
	   it's not needed, because we call set_language in gdb_init, after all
	   _initialize functions are called.  There is some chance that an
	   _initialize function that runs after _initialize_language implicitly
	   depends on current_language being set, but my testsuite runs haven't
	   found anything like that.

	 - Use language_unknown instead of language_auto when creating a minimal
	   symbol (minimal_symbol_reader::record_full).  I think that this value
	   is used to indicate that we don't know the symbol of the minimal
	   symbol (yet), so language_unknown makes sense to me.  Update a
	   condition accordingly in ada-lang.c.  symbol_find_demangled_name also
	   appears to "normalize" this value from "unknown" to "auto", remove
	   that part and update the condition to just check for
	   language_unknown.

	Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: switch "set language" to getter/setter
	The `language` global variable is mostly a scratch variable used for the
	setting.  The source of truth is really current_language and
	language_mode (auto vs manual), which are set by the
	set_language_command callback.

	Switch the setting to use the add_setshow_enum_cmd overload that takes a
	value getter and setter.

	Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-21  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove return value of set_language
	set_language returns the previous language, but nothing uses it.  Remove
	the return value.  This lets us remove the assignment to
	current_language, in _initialize_language.

	Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add make-check-all.sh
	Directory gdb/testsuite/boards contains a number of host/target boards, which
	run a test-case (or test-cases) in a different way.

	The benefits of using these boards are:
	- improving test coverage of gdb,
	- making the testsuite more robust, and
	- making sure the test-cases work for non-native and remote setups, if
	  possible.

	Each board is slightly different, and developers need to learn how to use each
	one, what parameters to pass and how, and which ones can be used in
	combination with each other.  This is a threshold to start using them.

	And then there quite a few, so I suppose typically only a few will be used by
	each developer.

	Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
	drop-in replacement of make check, while excercising all host/target boards in
	gdb/testsuite/boards.

	An example of make-check-all.sh for one test-case is:
	...
	 $  ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
	 LOCAL:
	 # of expected passes            8
	 TARGET BOARD: cc-with-gdb-index
	 # of expected passes            8
	   ...
	 HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
	 # of expected passes            8
	 HOST/TARGET BOARD: local-remote-host-native
	 # of expected passes            8
	...

	Shell-checked and tested on x86_64-linux.

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-04-21  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Add maint info screen
	While working on PRs tui/30337 and cli/30346 I came across various notions of
	width in gdb, as reported by gdb, readline, curses and the environment
	variables.

	As for gdb, readline and the environment variables, the way things work
	is:
	- Gdb asks readline to detect screen size,
	- readline sets the actual screen size in the environment variables
	  COLUMNS and LINES,
	- readline reports back a screen size to gdb, which may have one column
	  less than the actual screen size, to deal with lack of auto-wrap.
	  This becomes gdb's notion of screen size (in other words the point where
	  we can expect the gdb command line to wrap),
	- Gdb then explicitly sets readline's screen size, which readline itself may
	  adjust to deal with lack of auto-wrap.  This becomes readlines notion
	  of screen size (well, internally the unadjusted one, but it'll report back
	  the adjusted one).

	Add a command "maint info screen" that prints these notions, both for width
	and height.

	For TERM=xterm we have:
	...
	$ TERM=xterm gdb -ex "maint info screen"
	Number of characters gdb thinks are in a line is 118.
	Number of characters readline reports are in a line is 118.
	Number of characters curses thinks are in a line is 118.
	Number of characters environment thinks are in a line is 118 (COLUMNS).
	Number of lines gdb thinks are in a page is 27.
	Number of lines readline reports are in a page is 27.
	Number of lines curses thinks are in a page is 27.
	Number of lines environment thinks are in a page is 27 (LINES).
	...

	And for TERM=ansi:
	...
	$ TERM=ansi gdb -ex "maint info screen"
	Number of characters gdb thinks are in a line is 117.
	Number of characters readline reports are in a line is 116.
	Number of characters curses thinks are in a line is 118.
	Number of characters environment thinks are in a line is 118 (COLUMNS).
	Number of lines gdb thinks are in a page is 27.
	Number of lines readline reports are in a page is 27.
	Number of lines curses thinks are in a page is 27.
	Number of lines environment thinks are in a page is 27 (LINES).
	...

	[ The fact that we have "characters readline reports are in a line is 116" is
	is due to gdb making readline adjust twice for the lack of auto-wrap, this is
	PR cli/30346.

	Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
	"maint info screen":
	...
	Number of characters characters curses thinks are in a line is 110.
	Number of characters environment thinks are in a line is 111 (COLUMNS). ]

	And for TERM=ansi, with width and heigth set to 0:
	...
	Number of characters gdb thinks are in a line is 4294967295 (unlimited).
	Number of characters readline reports are in a line is 32766 (unlimited - 1).
	Number of characters curses thinks are in a line is 118.
	Number of characters environment thinks are in a line is 118 (COLUMNS).
	Number of lines gdb thinks are in a page is 4294967295 (unlimited).
	Number of lines readline reports are in a page is 32767 (unlimited).
	Number of lines curses thinks are in a page is 27.
	Number of lines environment thinks are in a page is 27 (LINES).
	...

	[ Note that when doing a resize by say maximizing or de-maximizing a terminal,
	all reported values are updated, except for curses when not in TUI mode.

	Maybe that means there's a bug.  If not, then maybe we should not print
	the curses lines unless in TUI mode, or annotate those lines such that it's
	clear that the values may be not up-to-date. ]

	I'd like to use this command in the regression test for PR cli/30346.

	Tested on x86_64-linux.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-21  Tom Tromey  <tromey@adacore.com>

	Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.c
	A recent change in opcodes/i386-dis.c caused a build failure on my
	x86-64 Fedora 36 system, which uses:

	$ gcc --version
	gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
	[...]

	The error is:

	../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
	../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
	12705 |           disp = val & 0x8000 ? val - 0x10000 : val;
	      |                  ~~~~^~~~~~~~

	This patch fixes the warning.

	opcodes/ChangeLog
	2023-04-21  Tom Tromey  <tromey@adacore.com>

		* i386-dis.c (OP_J): Check result of get16.

2023-04-21  Tom Tromey  <tromey@adacore.com>

	Use entry values for 32-bit PPC struct return
	AdaCore has a local patch for PPC "finish", but last year, Ulrich
	Weigand pointed out that this patch was incorrect.  It may work for
	simple functions like the one in the internal test, but nothing
	guarantees that r3 will be preserved by the callee, so checking r3 on
	exit is not always correct.

	This patch fixes the problem using the same approach as PPC64: use the
	entry value of r3, if available.  Ulrich confirmed this matches the
	PPC32 ABI.

2023-04-21  Tom Tromey  <tromey@adacore.com>

	Handle erroneous DW_AT_call_return_pc
	On PPC64, with the test case included in an earlier patch, we found
	that "finish" would still not correctly find the return value via
	entry values.

	The issue is simple.  The compiler emits:

	   0x00000000100032b8 <+28>:	bl      0x1000320c <pck__create_large>
	   0x00000000100032bc <+32>:	nop
	   0x00000000100032c0 <+36>:	li      r9,42

	... but the DWARF says:

	    <162a>   DW_AT_call_return_pc: 0x100032c0

	That is, the declared return PC is one instruction past the actual
	return PC.

	This patch adds a new arch hook to handle this scenario, and
	implements it for PPC64.  Some care is taken so that GDB will continue
	to work if this compiler bug is fixed.  A GCC patch is here:

	    https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html

	No check for 'nop' is done, as subsequent discussion revealed that the
	linker might replace this with another instruction.

2023-04-21  Tom Tromey  <tromey@adacore.com>

	Handle function descriptors in call_site_target
	call_site_target::iterate_over_addresses may look up a minimal symbol.
	On platforms like PPC64 that use function descriptors, this may find
	an unexpected address.  The fix is to use gdbarch_convert_from_func_ptr_addr
	to convert from a function descriptor to the address recorded at the
	call site.

	I've added a new test case that is based on the internal AdaCore test
	that provoked this bug.  However, I'm unable to test it as-is on
	PPC64.

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	x86: drop (explicit) BFD64 dependency from disassembler
	get64() is unreachable when !BFD64 (due to a check relatively early in
	print_insn()). Let's avoid the associated #ifdef-ary (or else we should
	extend it to remove more dead code).

	x86: drop use of setjmp() from disassembler
	With the longjmp() uses all gone, the setjmp() isn't necessary anymore
	either.

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	x86: change fetch error handling for get<N>()
	Make them return boolean and convert FETCH_DATA() uses to fetch_code().
	With this no further users of FETCH_DATA() remain, so the macro and its
	backing function are dropped as well.

	Leave value types as they were for the helper functions, even if I don't
	think that beyond get64() use of bfd_{,signed_}vma is really necessary.
	With type change of "disp" in OP_E_memory(), change the 2nd parameter of
	print_displacement() to a signed type as well, though (eliminating the
	need for a local variable of signed type). This also eliminates the need
	for custom printing of '-' in Intel syntax displacement expressions.

	While there drop forward declarations which aren't really needed.

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	x86: change fetch error handling when processing operands
	Make the handler functions all return boolean and convert FETCH_DATA()
	uses to fetch_code().

	x86: change fetch error handling in get_valid_dis386()
	Introduce a special error indicator node, for the sole (real) caller
	to recognize and act upon.

	x86: change fetch error handling in ckprefix()
	Use a tristate (enum) return value type to be able to express all three
	cases which are of interest to the (sole) caller. This also allows doing
	away with the abuse of "rex_used".

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	x86: change fetch error handling in top-level function
	... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
	error handling is problematic, as per
	https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
	using more conventional error handling instead.

	Also introduce a fetch_modrm() helper, for subsequent re-use.

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	x86: move fetch error handling into a helper function
	... such that it can be used from other than the setjmp() error handling
	path.

	Since I'd like the function's parameter to be pointer-to-const, two
	other functions need respective constification then, too (along with
	needing to be forward-declared).

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	bfd: fix STRICT_PE_FORMAT build
	A semicolon was missing and "name" needs to be pointer-to-const. While
	adding "const" there, also add it for "sec".

2023-04-21  Lifang Xia  <lifang_xia@linux.alibaba.com>

	RISC-V: Optimize relaxation of gp with max_alignment.
	This should be the first related issue, which posted in riscv-gnu-toolchain,
	https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497

	If the output sections are not between gp and the symbol, then their alignments
	shouldn't affect the gp relaxation.  However, this patch improves this idea
	even more, it limits the range to the gp+-2k, which means only the output
	section which are in the [gp-2K, gp+2K) range need to be considered.

	Even if the output section candidates may be different for each relax passes,
	the symbol that can be relaxed ar this round will not be truncated at next
	round.  That is because this round you can do relaxation which means that the
	section where the symbol is located is within the [gp-2K, gp+2K) range, so all
	the output section alignments between them should be considered.  In other
	words, if the alignments between them may cause truncated, then we should
	already preserve the size and won't do the gp relaxation this time.

	This patch can resolve the github issue which mentioned above, and also passed
	all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
	safe enough to commit.

	Originally, this patch also do the same optimization for the call relaxations,
	https://sourceware.org/pipermail/binutils/2022-October/123918.html
	But just in case there is something that has not been considered, we only
	deal with the gp relaxation at this time.

	bfd/
		* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
		max_alignment_for_gp.  It is used to record the maximum alignment of
		the output sections, which are in the [gp-2K, gp+2k) range.
		(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
		(_bfd_riscv_get_max_alignment): Added new parameter, gp.  If gp is
		zero, then all the output section alignments are possible candidates;
		Otherwise, only the output sections which are in the [gp-2K, gp+2K)
		range need to be considered.
		(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
		non-zero gp if the max_alignment_for_gp is -1.
		(_bfd_riscv_relax_pc): Likewise.
		(_bfd_riscv_relax_section): Record the first input section, so that
		we can reset the max_alignment_for_gp for each repeated relax passes.
	ld/
		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
		* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase.  It fails
		without this patch.

2023-04-21  Jan Beulich  <jbeulich@suse.com>

	ld: add missing period after @xref
	At least older versions of one of the doc generation tools complain
	(warn) about it missing.

2023-04-21  Alan Modra  <amodra@gmail.com>

	Keeping track of rs6000-coff archive element pointers
	rs6000-coff archives use a linked list of file offsets, where each
	element points to the next element.  The idea is to allow updating of
	large archives quickly without rewriting the whole archive.  (binutils
	ar does not do this.)  Unfortunately this is an easy target for
	fuzzers to create an archive that will cause ar or any other tool
	processing archives to hang.  I'd implemented guards against pointing
	back to the previous element, but of course that didn't last long.

	So this patch implements a scheme to keep track of file offset ranges
	used by elements as _bfd_read_ar_hdr is called for each element.  See
	the add_range function comment.  I needed a place to stash the list,
	so chose the obvious artdata.tdata backend extension to archive's
	tdata, already used by xcoff.  That involved a little cleanup, because
	while it would be possible to continue using different artdata.tdata
	for the big and small archives, it's nicer to use a union.

	If anyone is concerned this list of element ranges might grow large
	and thus significantly slow down the tools, adjacent ranges are
	merged.  In fact something like "ar t" will only ever have one range
	on xcoff archives generated by binutils/ar.  I agree there might still
	be a problem with ld random element access via the armap.

	include/
		* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
		(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
		(struct ar_ranges, struct xcoff_artdata): New.
		(x_artdata): Define.
		(xcoff_big_format_p): Rewrite.
		(xcoff_ardata, xcoff_ardata_big): Delete.
	bfd/
		* coff-rs6000.c: Replace uses of xcoff_ardata and
		xcoff_ardata_big throughout file.
		(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
		(add_range): New function.
		(_bfd_xcoff_read_ar_hdr): Use it here.  Fix memory leak.
		(_bfd_xcoff_openr_next_archived_file): Remove old sanity
		checks.  Set up range for header.
		(xcoff_write_archive_contents_old): Make the temporary
		artdata.tdata used here to pass info down to
		_bfd_compute_and_write_armap a struct xcoff_artdata.
		(xcoff_write_archive_contents_big): Likewise.
		* coff64-rs6000.c: Replace uses of xcoff_ardata and
		xcoff_ardata_big throughout file.
		(xcoff64_archive_p): Adjust artdata.tdata allocation.

2023-04-21  Alan Modra  <amodra@gmail.com>

	Delete struct artdata archive_head
	This element is unused.  Ideally we'd be moving archive_head and
	other archive specific fields from struct bfd to here, but that's a
	much larger change than this little bit of cleanup.

		* libbfd-in.h (struct artdata): Delete archive_head.
		* libbfd.h: Regenerate.
		* archive.c,
		* coff-rs6000.c,
		* coff64-rs6000.c: Delete comments mentioning artdata archive_head.

2023-04-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-20  Nick Clifton  <nickc@redhat.com>

	Add a SECURITY.txt file describing the GNU Binutils' project's stance on security related bugs.

2023-04-20  Jan Beulich  <jbeulich@suse.com>

	x86: adjust an ILP32 testcase using .insn
	In commit 6967633c8b49 ("x86: convert testcases to use .insn") an ILP32
	clone of a testcase was missed in the set of tests needing --divide
	added.

	Reported-by: Clément Chigot <chigot@adacore.com>

2023-04-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-20  Alan Modra  <amodra@gmail.com>

	sh4-linux segfaults running ld testsuite
	Segmentation fault
	FAIL: pr22269-1 (static pie undefined weak)
	and others running "visibility (hidden undef)" tests

	No code has any right to access bfd_link_hash_entry u.def without
	first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.

		* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
		relocs in GOT unless symbol is defined.

2023-04-20  Alan Modra  <amodra@gmail.com>

	PR30343 infrastructure
	Make ldemul_before_plugin_all_symbols_read more useful.

		* ldlang.c (lang_process): Move call to
		ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
		Allow backends to add to gc_sym_list before handling entry sym.
		* ldelf.c (ldelf_before_plugin_all_symbols_read): Test
		lto_plugin_active.

2023-04-20  Alan Modra  <amodra@gmail.com>

	ubsan: signed integer overflow in display_debug_lines_raw
	This one was caused by me unnecessarily promoting an "int adv" to
	"int64_t adv".  The expression overflowing was 4259 + 9223372036854775807
	with the left number being unsigned int.

		* dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
		with uint16_t and unsigned char with uint8_t.  Make li_line_base
		an int8_t.
		* dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.

2023-04-20  Alan Modra  <amodra@gmail.com>

	Yet another out-of-memory fuzzed object
	Do I care about out of memory conditions triggered by fuzzers?  Not
	much.  Your operating system ought to be able to handle it by killing
	the memory hog.  Oh well, this one was an element of a coff-alpha
	archive that said it was a little less that 2**64 in size.  The
	coff-alpha compression scheme expands at most 8 times, so we can do
	better in bfd_get_file_size.

		* bfdio.c (bfd_get_file_size): Assume elements in compressed
		archive can only expand a maximum of eight times.
		* coffgen.c (_bfd_coff_get_external_symbols): Sanity check
		size of symbol table agains file size.

2023-04-20  Alan Modra  <amodra@gmail.com>

	buffer overflow in print_symname
		* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate
		string sections.

2023-04-19  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: minor formatting fixes in sframe_encoder_write_fre
	libsframe/
		* sframe.c (sframe_encoder_write_fre): Formatting fixes for
		  readability.

	libsframe: use consistent function argument names
	libsframe/
		* sframe.c (sframe_decoder_get_header): Use consistent function
		arg names.
		(sframe_decoder_free): Likewise.
		(sframe_encode): Use more appropriate var name.

2023-04-19  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: correct some typos
	include/
		* sframe.h: Correct a typo.

	libsframe/
		* sframe.c: Likewise.

2023-04-19  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: use return type of bool for predicate functions
	libsframe/
		* sframe.c (sframe_header_sanity_check_p): Change return type to
		bool.
		(sframe_fre_sanity_check_p): Likewise.

	gas: sframe: fix comment

	gas: sframe: use ATTRIBUTE_UNUSED consistently
	gas/
		* gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
		consistently.
		(output_sframe): Likewise.
		(sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.

2023-04-19  Tom Tromey  <tromey@adacore.com>

	Remove adjust_type_signedness
	I happened across adjust_type_signedness, which may be used to modify
	a type when printing an Ada value.  Modifying a type like this is a
	bad idea -- they should normally be considered immutable.  Removing
	this function still passes both the dejagnu and internal AdaCore
	tests, though, so this patch drops it.

	As this was reviewed internally, and only affect Ada, I am checking it
	in.

2023-04-19  Nick Clifton  <nickc@redhat.com>

	Fix: readelf: loc_offset XX too big
	  PR 30355
	  * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section.

2023-04-19  Jan Beulich  <jbeulich@suse.com>

	gas: document that get_symbol_name() can clobber the input buffer
	Callers which want to make further parsing attempts at the buffer passed
	to the function need to be aware that due to the potential of string
	concatenation the input buffer may be altered in ways beyond what can be
	undone by putting back at *input_line_pointer the character that the
	function returns.

2023-04-19  Jan Beulich  <jbeulich@suse.com>

	x86: parse_register() must not alter the parsed string
	This reverts the code change done by 100f993c53a5 ("x86: Check
	unbalanced braces in memory reference"), which wrongly identified
	e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T
	syntax") as the root cause of PR gas/30248. (The testcase is left in
	place, no matter that it's at best marginally useful in that shape.)

	The problem instead is that parse_register() alters the string handed to
	it, thus breaking valid assumptions in subsequent parsing code. Since
	the function's behavior is a result of get_symbol_name()'s, make a copy
	of the incoming string before invoking that function.

	Like for parse_real_register() follow the model of strtol() et al: input
	string is const-qualified to signal that the string isn't altered, but
	the returned "end" pointer is not const-qualified, requiring const to be
	cast away (which generally is a bad idea, but the alternative would
	again be more convoluted code).

2023-04-19  Jan Beulich  <jbeulich@suse.com>

	x86: parse_real_register() does not alter the parsed string
	Follow the model of strtol() et al - input string is const-qualified to
	signal that the string isn't altered, but the returned "end" pointer is
	not const-qualified, requiring const to be cast away (which generally is
	a bad idea, but the alternative would be more convoluted code).

2023-04-19  Nick Clifton  <nickc@redhat.com>

	Updated Hungarian translation for the gprof directory

2023-04-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-18  Simon Marchi  <simon.marchi@efficios.com>

	gdb: re-format Python code with black 23
	Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b

2023-04-18  Carl Love  <cel@us.ibm.com>

	PowerPC: fix _Float128 type output string
	PowerPC supports two 128-bit floating point formats, the IBM long double
	and IEEE 128-bit float.  The issue is the DWARF information does not
	distinguish between the two.  There have been proposals of how to extend
	the DWARF information as discussed in

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

	but has not been fully implemented.

	GCC introduced the _Float128 internal type as a work around for the issue.
	The workaround is not transparent to GDB.  The internal _Float128 type
	name is printed rather then the user specified long double type.  This
	patch adds a new gdbarch method to allow PowerPC to detect the GCC
	workaround.  The workaround checks for "_Float128" name when reading the
	base typedef from the die_info.  If the workaround is detected, the type
	and format fields from the _Float128 typedef are copied to the long
	double typedef.  The same is done for the complex long double typedef.

	This patch fixes 74 regression test failures in
	gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
	default on GCC.  It fixes one regression test failure in
	gdb.base/complex-parts.exp.

	The patch has been tested on Power 10 where GCC defaults to IEEE Float
	128-bit and on Power 10 where GCC defaults to the IBM 128-bit float.  The
	patch as also been tested on X86-64 with no new regression failures.

2023-04-18  mengqinggang  <mengqinggang@loongson.cn>

	Symbols with GOT relocatios do not fix adjustbale
	  gas
	    * config/tc-loongarch.c (loongarch_fix_adjustable): Symbols with GOT relocatios do not fix adjustbale.
	    * testsuite/gas/loongarch/macro_op_large_abs.d: Regenerated.
	    * testsuite/gas/loongarch/macro_op_large_pc.d: Regenerated.
	  ld
	     * testsuite/ld-loongarch-elf/macro_op.d: Regenerated. -

2023-04-18  Thomas Koenig  <tkoenig@netcologne.de>

	Assembler Internal Docs: Describe handling of opcodes for relaxation a bit better.

2023-04-18  Kito Cheng  <kito.cheng@sifive.com>

	RISC-V: Cache the latest mapping symbol and its boundary.
	This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188

	Current flow:
	1) Scan any mapping symbol less than this instruciton.
	2) If not found, did a backward search.

	The flow seems not big issue, let run an example here:

	$x:
	0x0 a   <--- Found at step 1
	0x4 b   <--- Not found in step 1, but found at step 2
	0x8 c   <--- Not found in step 1, but found at step 2
	$d
	0x12 .word 1234 <-- Found at step 1

	The instruciton didn't have the same address with mapping symbol will
	still did backward search again and again.

	So the new flow is:
	1) Use the last mapping symbol status if the address is still within the range
	   of the current mapping symbol.
	2) Scan any mapping symbol less than this instruciton.
	3) If not found, did a backward search.
	4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
	   and cache that.

	Use the same example to run the new flow again:

	$x:
	0x0 a   <--- Found at step 2, the boundary is 0x12
	0x4 b   <--- Cache hit at step 1, within the boundary.
	0x8 c   <--- Cache hit at step 1, within the boundary.
	$d
	0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.

	The disassemble time of the test cases has been reduced from ~20 minutes to ~4
	seconds.

	opcode/ChangeLog
		PR 30282
		* riscv-dis.c (last_map_symbol_boundary): New.
		(last_map_state): New.
		(last_map_section): New.
		(riscv_search_mapping_symbol): Cache the result of latest
		mapping symbol.

2023-04-18  Alan Modra  <amodra@gmail.com>

	objdump use of uninitialised value in pr_string_field
		PR 30365
		* rdcoff.c (parse_coff_struct_type): Leave bitsize zero when no
		auxents.

	objdump buffer overflow in fetch_indexed_string
		PR 30361
		* dwarf.c (fetch_indexed_string): Sanity check string index.

2023-04-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30360 Seg. Fault when application uses std::thread
	We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
	Some of these functions have versions. For example,

	% nm -D /lib64/gprofng/libgp-collector.so  | grep thread_create@ | sort
	000000000004b420 T pthread_create@GLIBC_2.34
	000000000004b490 T pthread_create@GLIBC_2.17
	000000000004b500 T pthread_create@GLIBC_2.2.5
	000000000004b570 T pthread_create@GLIBC_2.1
	000000000004b5e0 T pthread_create@GLIBC_2.0

	Our library does not set the default version for symbols.
	This is correct because we don't know which libC will be used.

	gcc and g++ links differently the version symbols when the default version is
	not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using
	our pthread_create@GLIBC_2.0 by default.

	The current implementation of the interposed functions is:
	  If we are in our pthread_create@GLIBC_<NN>,
	  we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call
	  the same function from libC.
	In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC.
	We need to call the default version symbol from libC.

	gprofng/ChangeLog
	2023-04-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30360
		* libcollector/iotrace.c: Find and call a default libC version symbol.
		* libcollector/dispatcher.c: Likewise.
		* libcollector/iotrace.c: Likewise.
		* libcollector/linetrace.c: Likewise.
		* libcollector/mmaptrace.c: Likewise.
		* libcollector/synctrace.c: Likewise.
		* libcollector/collector.h (REAL_DCL): Remove an unused argument.

2023-04-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Update documentation
	This patch addresses bugzilla 29521:
	Bug 29521 - [docs] man pages are not in the release tarball

	The dependence on help2man to create the man pages has been eliminated.
	All man pages are now written in Texinfo. Texi2pod and pod2man are used
	to generate the man pages from the source.

	The user guide has been significantly expanded. It also includes all
	the man pages. These are formatted appropriately in the INFO, PDF, and
	HTML formats.

	The index in the user guide has been enhanced to include an overview
	of all options and commands that have been documented so far.

	The work on the documentation has not been completed, but this is
	a significant step forward.

	gprofng/ChangeLog
	2023-04-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/29521
		* doc/Makefile.am: Build documentation.
		* doc/gprofng.texi: Update documentation.
		* doc/version.texi: Likewise.
		* src/Makefile.am: Move the man pages generation to doc/Makefile.am.
		* gp-display-html/Makefile.am: Likewise.
		* doc/gp-archive.texi: New file.
		* doc/gp-collect-app.texi: New file.
		* doc/gp-display-html.texi: New file.
		* doc/gp-display-src.texi: New file.
		* doc/gp-display-text.texi: New file.
		* doc/gp-macros.texi: New file.
		* doc/gprofng_ug.texi: New file.
		* doc/Makefile.in: Rebuild.
		* gp-display-html/Makefile.in: Rebuild.
		* src/Makefile.in" Rebuild.

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Remove some unnecessary casts from ada-lang.c
	I noticed some unnecessary casts to LONGEST in ada-lang.c.  This patch
	removes the ones I think are very clearly not needed.  I'm checking
	this in as obvious.

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb/amdgpu: add follow fork and exec support
	Prior to this patch, it's not possible for GDB to debug GPU code in fork
	children or after an exec.  The amd-dbgapi target attaches to processes
	when an inferior appears due to a "run" or "attach" command, but not
	after a fork or exec.  This patch adds support for that, such that it's
	possible to for an inferior to fork and for GDB to debug the GPU code in
	the child.

	To achieve that, use the inferior_forked and inferior_execd observers.

	In the case of fork, we have nothing to do if `child_inf` is nullptr,
	meaning that GDB won't debug the child.  We also don't attach if the
	inferior has vforked.  We are already attached to the parent's address
	space, which is shared with the child, so trying to attach would cause
	problems.  And anyway, the inferior can't do anything other than exec or
	exit, it certainly won't start GPU kernels before exec'ing.

	In the case of exec, we detach from the exec'ing inferior and attach to
	the following inferior.  This works regardless of whether they are the
	same or not.  If they are the same, meaning the execution continues in
	the existing inferior, we need to do a detach/attach anyway, as
	amd-dbgapi needs to be aware of the new address space created by the
	exec.

	Note that we use observers and not target_ops::follow_{fork,exec} here.
	When the amd-dbgapi target is compiled in, it will attach (in the
	amd_dbgapi_process_attach sense, not the ptrace sense) to native
	inferiors when they appear, but won't push itself on the inferior's
	target stack just yet.  It only pushes itself if the inferior
	initializes the ROCm runtime.  So, if a non-GPU-using inferior calls
	fork, an amd_dbgapi_target::follow_fork method would not get called.
	Same for exec.  A previous version of the code had the amd-dbgapi target
	pushed all the time, in which case we could use the target methods.  But
	we prefer having the target pushed only when necessary, it's less
	intrusive when doing native debugging that doesn't involve the GPU.

	Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: switch to right inferior in fetch_inferior_event
	The problem explained and fixed in the previous patch could have also
	been fixed by this patch.  But I think it's good change anyhow, that
	could prevent future bugs, so here it is.

	fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
	of the process target of the inferior used to fetch the event.  The idea is
	that the event handling code will need to do some target calls, so we want to
	switch to an inferior that has target target.

	However, you can have two inferiors that share a process target, but with one
	inferior having an additional target on top:

	        inf 1            inf 2
	        -----            -----
	                         another target
	        process target   process target
	        exec             exec

	Let's say inferior 2 is selected by do_target_wait and returns an event that is
	really synthetized by "another target".  This "another target" could be a
	thread or record stratum target (in the case explained by the previous patch,
	it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
	layer).  fetch_inferior_event will then switch to the first inferior with
	"process target", so inferior 1.  handle_signal_stop then tries to fetch the
	thread's registers:

	    ecs->event_thread->set_stop_pc
	      (regcache_read_pc (get_thread_regcache (ecs->event_thread)));

	This will try to get the thread's register by calling into the current target
	stack, the stack of inferior 1.  This is problematic because "another target"
	might have a special fetch_registers implementation.

	I think it would be a good idea to switch to the inferior for which the
	even was reported, not just some inferior of the same process target.
	This will ensure that any target call done before we eventually call
	context_switch will be done on the full target stack that reported the
	event.

	Not all events are associated to an inferior though.  For instance,
	TARGET_WAITKIND_NO_RESUMED.  In those cases, some targets return
	null_ptid, some return minus_one_ptid (ideally the expected return value
	should be clearly defined / documented).  So, if the ptid returned is
	either of these, switch to an arbitrary inferior with that process
	target, as before.

	Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make regcache::raw_update switch to right inferior
	With the following patch, which teaches the amd-dbgapi target to handle
	inferiors that fork, we end up with target stacks in the following
	state, when an inferior that does not use the GPU forks an inferior that
	eventually uses the GPU.

	    inf 1            inf 2
	    -----            -----
	                     amd-dbgapi
	    linux-nat        linux-nat
	    exec             exec

	When a GPU thread from inferior 2 hits a breakpoint, the following
	sequence of events would happen, if it was not for the current patch.

	 - we start with inferior 1 as current
	 - do_target_wait_1 makes inferior 2 current, does a target_wait, which
	   returns a stop event for an amd-dbgapi wave (thread).
	 - do_target_wait's scoped_restore_current_thread restores inferior 1 as
	   current
	 - fetch_inferior_event calls switch_to_target_no_thread with linux-nat
	   as the process target, since linux-nat is officially the process
	   target of inferior 2.  This makes inferior 1 the current inferior, as
	   it's the first inferior with that target.
	 - In handle_signal_stop, we have:

	    ecs->event_thread->suspend.stop_pc
	      = regcache_read_pc (get_thread_regcache (ecs->event_thread));

	    context_switch (ecs);

	   regcache_read_pc executes while inferior 1 is still the current one
	   (because it's before the `context_switch`).  This is a problem,
	   because the regcache is for a ptid managed by the amd-dbgapi target
	   (e.g. (12345, 1, 1)), a ptid that does not make sense for the
	   linux-nat target.  The fetch_registers target call goes directly
	   to the linux-nat target, which gets confused.
	 - We would then get an error like:

	     Couldn't get extended state status: No such process.

	   ... since linux-nat tries to do a ptrace call on tid 1.

	GDB should switch to the inferior the ptid belongs to before doing the
	target call to fetch registers, to make sure the call hits the right
	target stack (it should be handled by the amd-dbgapi target in this
	case).  In fact the following patch does this change, and it would be
	enough to fix this specific problem.

	However, I propose to change regcache to make it switch to the right
	inferior, if needed, before doing target calls.  That makes the
	interface as a whole more independent of the global context.

	My first attempt at doing this was to find an inferior using the process
	stratum target and the ptid that regcache already knows about:

	      gdb::optional<scoped_restore_current_thread> restore_thread;
	      inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
	      if (inf != current_inferior ())
		{
		  restore_thread.emplace ();
		  switch_to_inferior_no_thread (inf);
		}

	However, this caused some failures in fork-related tests and gdbserver
	boards.  When we detach a fork child, we may create a regcache for the
	child, but there is no corresponding inferior.  For instance, to restore
	the PC after a displaced step over the fork syscall.  So
	find_inferior_ptid would return nullptr, and
	switch_to_inferior_no_thread would hit a failed assertion.

	So, this patch adds to regcache the information "the inferior to switch
	to to makes target calls".  In typical cases, it will be the inferior
	that matches the regcache's ptid.  But in some cases, like the detached
	fork child one, it will be another inferior (in this example, it will be
	the fork parent inferior).

	The problem that we witnessed was in regcache::raw_update specifically,
	but I looked for other regcache methods doing target calls, and added
	the same inferior switching code to raw_write too.

	In the regcache constructor and in get_thread_arch_aspace_regcache,
	"inf_for_target_calls" replaces the process_stratum_target parameter.
	We suppose that the process stratum target that would be passed
	otherwise is the same that is in inf_for_target_calls's target stack, so
	we don't need to pass both in parallel.  The process stratum target is
	still used as a key in the `target_pid_ptid_regcache_map` map, but
	that's it.

	There is one spot that needs to be updated outside of the regcache code,
	which is the path that handles the "restore PC after a displaced step in
	a fork child we're about to detach" case mentioned above.

	regcache_test_data needs to be changed to include full-fledged mock
	contexts (because there now needs to be inferiors, not just targets).

	Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add maybe_switch_inferior function
	Add the maybe_switch_inferior function, which ensures that the given
	inferior is the current one.  Return an instantiated
	scoped_restore_current_thread object only we actually needed to switch
	inferior.

	Returning a scoped_restore_current_thread requires it to be
	move-constructible, so give it a move constructor.

	Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove regcache::target
	The regcache class takes a process_stratum_target and then exposes it
	through regcache::target.  But it doesn't use it itself, suggesting it
	doesn't really make sense to put it there.  The only user of
	regcache::target is record_btrace_target::fetch_registers, but it might
	as well just get it from the current target stack.  This simplifies a
	little bit a patch later in this series.

	Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior_forked observable
	In the upcoming patch to support fork in the amd-dbgapi target, the
	amd-dbgapi target will need to be notified of fork events through an
	observer, to attach itself (attach in the amd-dbgapi sense, not ptrace
	sense) to the new inferior / process.

	The reason that this can't be done through target_ops::follow_fork is
	that the amd-dbgapi target isn't pushed on the inferior's target stack
	right away.  It attaches itself to the process and only pushes itself on
	its target stack if and when the inferior initializes the ROCm runtime.

	If an inferior that is not using the ROCm runtime forks, we want to be
	notified of it, so we can attach to the child, and catch if the child
	starts using the ROCm runtime.

	So, add a new observable and notify it in follow_fork_inferior.  It will
	be used later in this series.

	Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb: pass execing and following inferior to inferior_execd observers
	The upcoming patch to support exec in the amd-dbgapi target needs to
	detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi
	to the inferior continuing the execution.  They may or may not be the
	same, depending on the `set follow-exec-mode` setting.  But even if they
	are the same, we need to do the detach / attach dance.

	With the current observable signature, the observers only receive the
	inferior in which execution continues (the "following" inferior).

	Change the signature to pass both inferiors, and update all existing
	observers.

	Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659
	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Add 128-bit integer support to the Ada parser
	This adds support for 128-bit integers to the Ada parser.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30188

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Remove some Ada parser helper functions
	These helper functions in the Ada parser don't seem all that
	worthwhile to me, so this patch removes them.

	Add overload of fits_in_type
	This adds an overload of fits_in_type that accepts a gdb_mpz.  A
	subsequent patch will use this.

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Add 128-bit integer support to the Rust parser
	This adds support for 128-bit integers to the Rust parser.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Convert long_const_operation to use gdb_mpz
	This changes long_const_operation to use gdb_mpz for its storage.

2023-04-17  Tom Tromey  <tromey@adacore.com>

	Additions to gdb_mpz
	In preparation for adding more 128-bit support to gdb, a few additions
	to gdb_mpz are needed.

	First, this adds a new 'as_integer_truncate' method.  This method
	works like 'as_integer' but does not require the value to fit in the
	target type -- it just truncates.

	Second, gdb_mpz::export_bits is changed to handle the somewhat unusual
	situation of zero-length types.  This can happen for a Rust '()' type;
	but I think other languages have zero-bit integer types as well.

	Finally, this adds some operator== overloads.

2023-04-17  Nick Clifton  <nickc@redhat.com>

	Make the .rsrc section read only.
	  PR 30142
	  * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
	  * rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.

2023-04-17  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Handle empty file name in .debug_line section
	With DWARF 5, it's possible to produce an empty file name in the File Name
	Table of the .debug_line section:
	...
	 The File Name Table (offset 0x112, lines 1, columns 2):
	  Entry Dir     Name
	  0     1       (indirect line string, offset: 0x2d):
	...

	Currently, when gdb reads an exec containing such debug info, it segfaults:
	...
	Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
	0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
	  gdb/dwarf2/read.c:18716
	18716     if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
	...
	because read_direct_string transforms "" into a nullptr, and we end up
	dereferencing the nullptr.

	Note that the behaviour of read_direct_string has been present since repo
	creation.

	Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
	filenames.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

	PR symtab/30357
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357

2023-04-17  Nick Clifton  <nickc@redhat.com>

	Add support for the .gnu.sgstubs section to the linker for ARM/ELF based targets.
	  PR 30354
	  * emulparams/armelf.sh (OTHER_PLT_SECTIONS): Define in order to handle the .gnu.sgstubs section.

2023-04-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: accept script argument for mi_make_breakpoint_pending
	This commit changes mi_make_breakpoint_pending to accept the 'script'
	and 'times' arguments.

	I've then added a new test that makes use of 'scripts' in
	gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.

	There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
	argument -- previously this argument was being ignored, but is now
	used.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-14  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: avoid {"} pattern in lib/mi-support.exp
	Commit:

	  commit c569a946f6925d3f210c3eaf74dcda56843350ef
	  Date:   Fri Mar 24 10:45:37 2023 +0100

	      [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument

	Introduced the use of {"} in mi-support.exp.  There is absolutely
	nothing wrong with this in any way.  However, this is causing my
	editor to get the syntax highlighting of this file wrong after this
	point.

	Maybe the real answer is to use a better editor, or fix my current
	editor.... but I'm hoping I can instead take the lazy approach of just
	changing {"} to "\"", which is handled fine, and means exactly the
	same as far as I understand it.

	There should be no change in what is tested after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-14  Luis Machado  <luis.machado@arm.com>

	pauth: Create new feature string for pauth to prevent crashing older gdb's
	Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever
	a target reports the pauth feature string in the target description and also
	provide additional register outside of gdb's known and expected feature
	strings.

	This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out
	there that will crash on connection to the above targets.

	QEMU has postponed inclusion of the pauth feature string in version 8, and
	instead we agreed to use a new feature name to prevent crashing those older
	gdb's.

	Initially there was a plan to backport a trivial fix all the way to gdb 9, but
	given QEMU's choice, this is no longer needed.

	This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used
	by all targets going forward, except native linux gdb and gdbserver, for
	backwards compatibility with older gdb's/gdbserver's.

	gdb/gdbserver will still emit the old feature string for Linux since it doesn't
	report additional system registers and thus doesn't cause a crash of older
	gdb's. We can revisit this in the future once the problematic gdb's are likely
	no longer in use.

	I've added some documentation to explain the situation.

2023-04-14  Luis Machado  <luis.machado@arm.com>

	debug registers: Add missing debug version entry for FEAT_Debugv8p8
	The Arm Architecture Reference Manual defines debug version 0b1010 for
	FEAT_Debugv8p8. This is used to identify valid hardware debug registers.

	gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
	teaches gdb about this new version.

	No visible changes should happen as consequence of this patch, but in the
	future gdb will be able to identify debug registers in newer hardware.

	Regression-tested on aarch64-linux Ubuntu 20.04/22.04.

2023-04-14  Hui Li  <lihui@loongson.cn>

	gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp
	(1) Description of problem

	In the current code, when execute the following test on LoongArch:

	$make check-gdb TESTS="gdb.base/dump.exp"
	```
	FAIL: gdb.base/dump.exp: dump array as value, intel hex
	FAIL: gdb.base/dump.exp: dump struct as value, intel hex
	FAIL: gdb.base/dump.exp: dump array as memory, ihex
	FAIL: gdb.base/dump.exp: dump struct as memory, ihex

	```
	These tests passed on the X86_64,

	(2) Root cause

	On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
	so dump ihex test failed.

	gdb.base/dump.exp has the following code to check 64-bit address

	```
	 # Check the address of a variable.  If it is bigger than 32-bit,
	 # assume our target has 64-bit addresses that are not supported by SREC,
	 # IHEX and TEKHEX.  We skip those tests then.
	 set max_32bit_address "0xffffffff"
	 set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
	 if {${data_address} > ${max_32bit_address}} {
	    set is64bitonly "yes"
	}
	```

	We check the "&intarray" on different target as follow:

	```
	$gdb gdb/testsuite/outputs/gdb.base/dump/dump
	...
	(gdb) start
	...

	On X86_64:
	(gdb) print /x &intarray
	$1 = 0x404060

	On LoongArch:
	(gdb) print /x &intarray
	$1 = 0x120008068
	```
	The variable address difference here is due to the link script
	of linker.

	```
	On X86_64:
	$ld --verbose
	...
	PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
	. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

	On LoongArch:
	$ld --verbose
	...
	PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
	. = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;

	```

	(3) How to fix

	Because 64-bit variable address out of range for IHEX, it's not an
	functional problem for LoongArch. Refer to the handling of 64-bit
	targets in this testsuite, use the "is64bitonly" flag to skip those
	tests for the target has 64-bit addresses.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-04-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add regression test for PR30325
	Add regression tests for PR30325, one for the asm window and one for the
	source window.

	Use maint set tui-left-margin verbose to make the extend of the left margin
	clear.

	Tested on x86_64-linux.

	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-04-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-13  Tom Tromey  <tromey@adacore.com>

	Avoid double-free with debuginfod
	PR gdb/29257 points out a possible double free when debuginfod is in
	use.  Aside from some ugly warts in the symbol code (an ongoing
	issue), the underlying issue in this particular case is that elfread.c
	seems to assume that symfile_bfd_open will return NULL on error,
	whereas in reality it throws an exception.  As this code isn't
	prepared for an exception, bad things result.

	This patch fixes the problem by introducing a non-throwing variant of
	symfile_bfd_open and using it in the affected places.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257

2023-04-13  Claudiu Zissulescu  <claziss@synopsys.com>

	arc: Update ARC specific linker tests.
	All the tests are designed for a little-endian ARC system. Thus,
	update the arc predicate in arc.exp, improve the matching pattern for
	linker relaxation test, and add linker scripts to nps-1x tests.

	arc: Update ARC's CFI tests.
	The double store/loads instructions (e.g. STD/LDD) are not baseline
	ARC ISA.  The same holds for some short instructions.  Update the
	tests to use base ARC ISA.

2023-04-13  Claudiu Zissulescu  <claziss@gmail.com>

	arc: Update GAS test

2023-04-13  Alan Modra  <amodra@gmail.com>

	Preserve a few more bfd fields in check_format_matches
	AOUT and COFF targets set symcount and start_address in their object_p
	functions.  If these are used anywhere then it would pay to save and
	restore them so that a successful match gets the values expected
	rather than that for a later unsuccessful target match.

		* format.c (struct bfd_preserve): Move some fields.  Add
		symcount, read_only and start_address.
		(bfd_preserve_save): Save..
		(bfd_preserve_restore): ..and restore..
		(bfd_reinit): ..and zero new fields.

2023-04-13  Alan Modra  <amodra@gmail.com>

	Re: pe_ILF_object_p and bfd_check_format_matches
	The last patch wasn't quite correct.  bfd_preserve_restore also needs
	to handle an in-memory to file backed transition, seen in a testcase
	ILF object matching both pei-arm-little and pei-arm-wince-little.
	There the first match is saved in preserve_match, and restored at the
	end of the bfd_check_format_matches loop making the bfd in-memory.  On
	finding more than one match the function wants to restore the bfd back
	to its original state with another bfd_preserve_restore call before
	exiting with a bfd_error_file_ambiguously_recognized error.

	It is also not correct to restore abfd->iostream unless the iovec
	changes.  abfd->iostream is a FILE* when using cache_iovec, and if
	the file has been closed and reopened the iostream may have changed.

		* format.c (io_reinit): New function.
		(bfd_reinit, bfd_preserve_restore): Use it.

2023-04-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Revert workaround in tui_source_window::show_line_number
	The m_digits member of tui_source_window is documented as having semantics:
	...
	  /* How many digits to use when formatting the line number.  This
	     includes the trailing space.  */
	...

	The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source
	code") started printing two trailing spaces instead:
	...
	-  xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
	+  xsnprintf (text, sizeof (text), "%*d  ", m_digits - 1, lineno);
	...

	Now that PR30325 is fixed, this no longer has any effect.

	Fix this by reverting to the original behaviour: print one trailing space
	char.

	Tested on x86_64-linux.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-04-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Fix left margin in disassembly window
	With a hello world a.out, and maint set tui-left-margin-verbose on, we have
	this disassembly window:
	...
	┌───────────────────────────────────────────────────────────┐
	│___ 0x555555555149 <main>           endbr64                │
	│___ 0x55555555514d <main+4>         push   %rbp            │
	│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
	│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
	│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
	...
	Note the space between "B+>" and 0x555555555151.  The space shows that a bit
	of the left margin is not written, which is a problem because that location is
	showing a character previously written, which happens to be a space, but also
	may be something else, for instance a '[' as reported in PR tui/30325.

	The problem is caused by confusion about the meaning of:
	...
	 #define TUI_EXECINFO_SIZE 4
	...

	There's the meaning of defining the size of this zero-terminated char array:
	...
	      char element[TUI_EXECINFO_SIZE];
	...
	which is used to print the "B+>" bit, which is 3 chars wide.

	And there's the meaning of defining part of the size of the left margin:
	...
	  int left_margin () const
	  { return 1 + TUI_EXECINFO_SIZE + extra_margin (); }
	...
	where it represents 4 chars.

	The discrepancy between the two causes the space between "B+>" and
	"0x555555555151".

	Fix this by redefining TUI_EXECINFO_SIZE to 3, and using:
	...
	      char element[TUI_EXECINFO_SIZE + 1];
	...
	such that we have:
	...
	|B+>0x555555555151 <main+8>         lea    0xeac(%rip),%rax │
	...

	This changes the layout of the disassembly window back to what it was before
	commit 9e820dec13e ("Use a curses pad for source and disassembly windows"),
	the commit that introduced the PR30325 regression.

	This also changes the source window from:
	...
	│___000005__{                                               |
	...
	to:
	...
	│___000005_{                                                |
	...

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30325

	Approved-By: Tom Tromey <tom@tromey.com>

2023-04-12  Tom de Vries  <tdevries@suse.de>

	[gdb/tui] Add maint set/show tui-left-margin-verbose
	The TUI has two types of windows derived from tui_source_window_base:
	- tui_source_window (the source window), and
	- tui_disasm_window (the disassembly window).

	The two windows share a common concept: the left margin.

	With a hello world a.out, we can see the source window:
	...
	┌─/home/vries/hello.c───────────────────────────────────────┐
	│        5  {                                               │
	│B+>     6    printf ("hello\n");                           │
	│        7    return 0;                                     │
	│        8  }                                               │
	│        9                                                  │
	│
	...
	where the left margin is the part holding "B+>" and the line number, and the
	disassembly window:
	...
	┌───────────────────────────────────────────────────────────┐
	│    0x555555555149 <main>           endbr64                │
	│    0x55555555514d <main+4>         push   %rbp            │
	│    0x55555555514e <main+5>         mov    %rsp,%rbp       │
	│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
	│    0x555555555158 <main+15>        mov    %rax,%rdi       │
	...
	where the left margin is just the bit holding "B+>".

	Because the left margin contains some spaces, it's not clear where it starts
	and ends, making it harder to observe problems related to it.

	Add a new maintenance command "maint set tui-left-margin-verbose", that when
	set to on replaces the spaces in the left margin with either '_' or '0',
	giving us this for the source window:
	...
	┌─/home/vries/hello.c───────────────────────────────────────┐
	│___000005__{                                               │
	│B+>000006__  printf ("hello\n");                           │
	│___000007__  return 0;                                     │
	│___000008__}                                               │
	...
	and this for the disassembly window:
	...
	┌───────────────────────────────────────────────────────────┐
	│___ 0x555555555149 <main>           endbr64                │
	│___ 0x55555555514d <main+4>         push   %rbp            │
	│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
	│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
	│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
	...

	Note the space between "B+>" and 0x555555555151.  The space shows that a bit
	of the left margin is not written, a problem reported as PR tui/30325.

	Specifically, PR tui/30325 is about the fact that the '[' character from the
	string "[ No Assembly Available ]" ends up in that same spot:
	...
	│B+>[0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
	...
	which only happens for certain window widths.

	The new command allows us to spot the problem with any window width.

	Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces
	between line numbers and source code"), we have:
	...
	┌─/home/vries/hello.c───────────────────────────────────────┐
	│___000005_ {                                               │
	│B+>000006_   printf ("hello\n");                           │
	│___000007_   return 0;                                     │
	│___000008_ }                                               │
	...
	showing a similar problem at the space between '_' and '{'.

	Tested on x86_64-linux.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-04-12  Tom Tromey  <tom@tromey.com>

	Use SELF_CHECK in all unit tests
	I noticed a few unit tests are using gdb_assert.  I think this was an
	older style, before SELF_CHECK was added.  This patch switches them
	over.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-04-12  Claudiu Zissulescu  <claziss@gmail.com>

	arc: remove faulty instructions
	Clean not implemented ARC instruction from ARC instruction table.

2023-04-12  Tom Tromey  <tromey@adacore.com>

	Use 'require' with gnatmake_version_at_least
	I found a couple of tests that check gnatmake_version_at_least using
	"if" where "require" would be a little cleaner.  This patch converts
	these.

2023-04-12  YunQiang Su  <yunqiang.su@cipunited.com>

	MIPS: make mipsisa32 and mipsisa64 link more systematic
	Introduce `static const struct mips_mach_extension mips_mach_32_64[]`
	and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`,
	to make mipsisa32 and mipsisa64 interlink more systemtic.

	Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and
	mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1),
	so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64.

	Note: R6 is not compatible with pre-R6.

	bfd/ChangeLog:

		* elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and
		  mipsisa64 interlink more systematic.
		  (mips_mach_32_64): new struct added.
		  (mips_mach_extends_32_64): new function added.

2023-04-12  Nick Clifton  <nickc@redhat.com>

	Fix typos in the linker's documentation of the --enable-non-contiguous-regions option.

2023-04-12  Alan Modra  <amodra@gmail.com>

	PR30326, uninitialised value in objdump compare_relocs
	This is a fuzzing PR, with a testcase involving a SHF_ALLOC and
	SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc
	section.  BFD doesn't handle compressed relocation sections, with most
	of the code reading relocs using sh_size (often no bfd section is
	created) but in the case of SHF_ALLOC dynamic relocs we had some code
	using the bfd section size.  This led to a mismatch, sh_size is
	compressed, size is uncompressed, and from that some uninitialised
	memory.  Consistently using sh_size is enough to fix this PR, but I've
	also added tests to exclude SHF_COMPRESSED reloc sections from
	consideration.

		PR 30362
		* elf.c (bfd_section_from_shdr): Exclude reloc sections with
		SHF_COMPRESSED flag from normal reloc processing.
		(_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude
		SHF_COMPRESSED sections from consideration.  Use sh_size when
		sizing to match slurp_relocs.
		(_bfd_elf_canonicalize_dynamic_reloc): Likewise.
		(_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size
		plt relocs.
		* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
		* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
		* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
		* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.

2023-04-12  Alan Modra  <amodra@gmail.com>

	ubsan: dwarf2.c:2232:7: runtime error: index 16 out of bounds
	Except it isn't out of bounds because space for a larger array has
	been allocated.

		* dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
		(alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.

2023-04-12  Alan Modra  <amodra@gmail.com>

	Fail of x86_64 AMX-COMPLEX insns (Intel disassembly)
	x86_64-w64-mingw32 pads sections.

		* testsuite/gas/i386/x86-64-amx-complex-intel.d: Don't fail
		due to nop padding.

2023-04-12  Alan Modra  <amodra@gmail.com>

	pe_ILF_object_p and bfd_check_format_matches
	If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the
	bfd from being file backed to in-memory.  This can have unfortunate
	results for targets checked by bfd_check_format_matches after that
	point as they will be matching against the created in-memory image
	rather than the file.  bfd_preserve_restore also has a problem if it
	flips the BFD_IN_MEMORY flag, because the flag affects iostream
	meaning and should be set if using _bfd_memory_iovec.  To fix these
	problems, save and restore iostream and iovec along with flags, and
	modify bfd_reinit to make the bfd file backed again.  Restoring the
	iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY
	(part of BFD_FLAGS_SAVED) to be removed.
	One more detail: If restoring from file backed to in-memory then the
	bfd needs to be forcibly removed from the cache lru list, since after
	the bfd becomes in-memory a bfd_close will delete the bfd's memory
	leaving the lru list pointing into freed memory.

		* cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here..
		(bfd_cache_lookup_worker): ..rather than here.
		(bfd_cache_close): Comment.
		* format.c (struct bfd_preserve): Add iovec and iostream fields.
		(bfd_preserve_save): Save them..
		(bfd_preserve_restore): ..and restore them, calling
		bfd_cache_close if the iovec differs.
		(bfd_reinit): Add preserve param.  If the bfd has been flipped
		to in-memory, reopen the file.  Restore flags.
		* peicode.h (pe_ILF_cleanup): New function.
		(pe_ILF_object_p): Return it.
		* bfd.c (BFD_FLAGS_SAVED): Delete.
		* bfd-in2.h: Regenerate.

2023-04-12  Alan Modra  <amodra@gmail.com>

	Comment typo fix

2023-04-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-11  Nathan Sidwell  <nathan@acm.org>

	bfd: optimize bfd_elf_hash
	The bfd_elf_hash loop is taken straight from the sysV document, but it
	is poorly optimized. This refactoring removes about 5 x86 insns from
	the 15 insn loop.

	1) The if (..) is meaningless -- we're xoring with that value, and of
	course xor 0 is a nop. On x86 (at least) we actually compute the xor'd
	value and then cmov.  Removing the if test removes the cmov.

	2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits
	will be shifted out in the next iteration.  All we need to do is sink
	a mask of those 4 bits out of the loop.

	3) anding with 0xf0 after shifting by 24 bits can allow betterin
	encoding on RISC ISAs than masking with '0xf0 << 24' before shifting.
	RISC ISAs often require materializing larger constants.

		bfd/
		* elf.c (bfd_elf_hash): Refactor to optimize loop.
		(bfd_elf_gnu_hash): Refactor to use 32-bit type.

2023-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, doc: correct argument description for info connections/inferiors
	It said for 'info inferiors' and 'info connections' that the argument
	could be 'a space separated list of inferior numbers' which is correct
	but incomplete.  In fact the arguments can be any space separated
	combination of numbers and (ascending) ranges.

	The beginning of the section now describes the ID list as a new keyword.

	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-04-11  Nick Clifton  <nickc@redhat.com>

	Replace an assertion in the dwarf code with a warning message.
	  PR 30327
	  * dwarf.c (read_and_display_attr_value): Warn if the number of views is greater than the number of locations.

	Fix an illegal memorty access when running gprof over corrupt data.
	  PR 30324
	  * symtab.c (symtab_finalize): Only change the end address if dst has been updated.

	Fix an attempt to allocate an excessive amount of memory when parsing a corrupt DWARF file.
	  PR 30313
	  * dwarf.c (display_debug_lines_decoded): Check for an overlarge number of files or directories.

	Fix a potential illegal memory access when displaying corrupt DWARF information.
	  PR 30312
	  * dwarf.c (prealloc_cu_tu_list): Always allocate at least one entry.

	Fix an attempt to allocate an overlarge amount of memory when decoding a corrupt ELF format file.
	  PR 30311
	  * readelf.c (uncompress_section_contents): Check for a suspiciously large uncompressed size.

	Fix illegal memory access when disassembling corrupt NFP binaries.
	  PR 30310
	  * nfp-dis.c (init_nfp6000_priv): Check that the output section exists.

2023-04-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix indentation within print_one_breakpoint_location
	Spotted some code in print_one_breakpoint_location that was not
	indented correctly, this commit just changes the indentation.

	There should be no user visible changes after this commit.

2023-04-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix typo gdb_name_name -> gdb_test_name
	Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name
	instead of $gdb_test_name in one place.  Fixed in this commit.

2023-04-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: warn when converting h/w watchpoints to s/w
	On amd64 (at least) if a user sets a watchpoint before the inferior
	has started then GDB will assume that a hardware watchpoint can be
	created.

	When the inferior starts there is a chance that the watchpoint can't
	actually be create as a hardware watchpoint, in which case (currently)
	GDB will silently convert the watchpoint to a software watchpoint.
	Here's an example session:

	  (gdb) p sizeof var
	  $1 = 4000
	  (gdb) watch var
	  Hardware watchpoint 1: var
	  (gdb) info watchpoints
	  Num     Type           Disp Enb Address    What
	  1       hw watchpoint  keep y              var
	  (gdb) starti
	  Starting program: /home/andrew/tmp/watch

	  Program stopped.
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) info watchpoints
	  Num     Type           Disp Enb Address            What
	  1       watchpoint     keep y                      var
	  (gdb)

	Notice that before the `starti` command the watchpoint is showing as a
	hardware watchpoint, but afterwards it is showing as a software
	watchpoint.  Additionally, note that we clearly told the user we
	created a hardware watchpoint:

	  (gdb) watch var
	  Hardware watchpoint 1: var

	I think this is bad.  I used `starti`, but if the user did `start` or
	even `run` then the inferior is going to be _very_ slow, which will be
	unexpected -- after all, we clearly told the user that we created a
	hardware watchpoint, and the manual clearly says that hardware
	watchpoints are fast (at least compared to s/w watchpoints).

	In this patch I propose adding a new warning which will be emitted
	when GDB downgrades a h/w watchpoint to s/w.  The session now looks
	like this:

	  (gdb) p sizeof var
	  $1 = 4000
	  (gdb) watch var
	  Hardware watchpoint 1: var
	  (gdb) info watchpoints
	  Num     Type           Disp Enb Address    What
	  1       hw watchpoint  keep y              var
	  (gdb) starti
	  Starting program: /home/andrew/tmp/watch
	  warning: watchpoint 1 downgraded to software watchpoint

	  Program stopped.
	  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
	  (gdb) info watchpoints
	  Num     Type           Disp Enb Address            What
	  1       watchpoint     keep y                      var
	  (gdb)

	The important line is:

	  warning: watchpoint 1 downgraded to software watchpoint

	It's not much, but hopefully it will be enough to indicate to the user
	that something unexpected has occurred, and hopefully, they will not
	be surprised when the inferior runs much slower than they expected.

	I've added an amd64 only test in gdb.arch/, I didn't want to try
	adding this as a global test as other architectures might be able to
	support the watchpoint request in h/w.

	Also the test is skipped for extended-remote boards as there's a
	different set of options for limiting hardware watchpoints on remote
	targets, and this test isn't about them.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-04-11  Andrew Burgess  <aburgess@redhat.com>

	gdb/riscv: Support c.li in prologue unwinder
	I was seeing some failures in gdb.threads/omp-par-scope.exp when run
	on a riscv64 target.  It turns out the cause of the problem is that I
	didn't have debug information installed for libgomp.so, which this
	test makes use of.  The test requires GDB to backtrace through a
	libgomp function, and the riscv prologue unwinder was failing to
	unwind this particular stack frame.

	The reason for the failure to unwind was that the function prologue
	includes a c.li (compressed load immediate) instruction, and the riscv
	prologue scanning unwinder doesn't know what to do with this
	instruction, though the unwinder does understand c.lui (compressed
	load unsigned immediate).

	This commit adds support for c.li.  After this GDB is able to unwind
	through libgomp, and I no longer see any unexpected failures in
	gdb.threads/omp-par-scope.exp.

	I've also included a new test in gdb.arch/ which specifically checks
	for our c.li support.

2023-04-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-10  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/dwarf: Fix MinGW build
	Unfortunately MinGW doesn't support std::future yet, so this causes the
	build to fail.  Use GDB's version which provides a fallback for this case.

	Tested for regressions on native aarch64-linux.

	Approved-By: Tom Tromey <tromey@adacore.com>

2023-04-10  Tom Tromey  <tromey@adacore.com>

	Handle unwinding from SEGV on Windows
	PR win32/30255 points out that a call to a NULL function pointer will
	leave gdb unable to "bt" on Windows.

	I tracked this down to the amd64 windows unwinder.  If we treat this
	scenario as if it were a leaf function, unwinding works fine.

	I'm not completely sure this patch is the best way.  I considered
	having it check for 'pc==0' -- but then I figured this could affect
	any inaccessible PC, not just the special 0 value.

	No test case because I can't run dejagnu tests on Windows.  I tested
	this by hand using the test case in the bug.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30255

2023-04-10  Haochen Jiang  <haochen.jiang@intel.com>

	x86: Add inval tests for AMX instructions
	gas/ChangeLog:

		* testsuite/gas/i386/i386.exp: Run AMX-FP16 and AMX-COMPLEX
		inval testcases.
		* testsuite/gas/i386/x86-64-amx-inval.l: Add AMX-BF16 tests.
		* testsuite/gas/i386/x86-64-amx-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-inval.l: New test.
		* testsuite/gas/i386/x86-64-amx-complex-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16-inval.l: Ditto.
		* testsuite/gas/i386/x86-64-amx-fp16-inval.s: Ditto.

2023-04-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-08  Philippe Blain  <levraiphilippeblain@gmail.com>

	Fix typos in previous commit of gdb.texinfo.
	* gdb/doc/gdb.texinfo (Requirements): Fix typos.

2023-04-08  Nick Alcock  <nick.alcock@oracle.com>

	libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGS
	This is a bug in the intersection of two obscure options that cannot
	even be invoked from ld with a feature added to stop ld of the
	same input file repeatedly from crashing the linker.

	The latter fix involved tracking input files (internally to libctf) not
	just with their input CU name but with a version of their input CU name
	that was augmented with a numeric prefix if their linker input file name
	was changed, to prevent distinct CTF dicts with the same cuname from
	overwriting each other. (We can't use just the linker input file name
	because one linker input can contain many CU dicts, particularly under
	ld -r).  If these inputs then produced conflicting types, those types
	were emitted into similarly-named output dicts, so we needed similar
	machinery to detect clashing output dicts and add a numeric prefix to
	them as well.

	This works fine, except that if you used the cu-mapping feature to force
	double-linking of CTF (so that your CTF can be grouped into output dicts
	larger than a single translation unit) and then also used
	CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the
	mapping to be created (even if empty), we did the creation of empty dicts
	first, and then all the actual content got considered to be a clash. So
	you ended up with a pile of useless empty dicts and then all the content
	was in full dicts with the same names suffixed with a #0.  This seems
	likely to confuse consumers that use this facility.

	Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking
	is complete, not before it runs.

	No impact on ld, which does not do cu-mapped links or pass
	CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link().

	libctf/
		* ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one
	        already exists and we are making one for no input in particular.
	        (ctf_link): Emit empty CTF dicts corresponding to no input in
	        particular only after linkiing is complete.

2023-04-08  Nick Alcock  <nick.alcock@oracle.com>

	libctf: propagate errors from parents correctly
	CTF dicts have per-dict errno values: as with other errno values these
	are set on error and left unchanged on success.  This means that all
	errors *must* set the CTF errno: if a call leaves it unchanged, the
	caller is apt to find a previous, lingering error and misinterpret
	it as the real error.

	There are many places in libctf where we carry out operations on parent
	dicts as a result of carrying out other user-requested operations on
	child dicts (e.g. looking up information on a pointer to a type will
	look up the type as well: the pointer might well be in a child and the
	type it's a pointer to in the parent).  Those operations on the parent
	might fail; if they do, the error must be correctly reflected on the
	child that the user-visible operation was carried out on.  In many
	places this was not happening.

	So, audit and fix all those places.  Add tests for as many of those
	cases as possible so they don't regress.

	libctf/
		* ctf-create.c (ctf_add_slice): Use the original dict.
		* ctf-lookup.c (ctf_lookup_variable): Propagate errors.
		(ctf_lookup_symbol_idx): Likewise.
		* ctf-types.c (ctf_member_next): Likewise.
		(ctf_type_resolve_unsliced): Likewise.
		(ctf_type_aname): Likewise.
		(ctf_member_info): Likewise.
		(ctf_type_rvisit): Likewise.
		(ctf_func_type_info): Set the error on the right dict.
		(ctf_type_encoding): Use the original dict.
		* testsuite/libctf-writable/error-propagation.*: New test.

2023-04-08  Nick Alcock  <nick.alcock@oracle.com>

	libctf, tests: do not assume host and target have identical field offsets
	The newly-introduced libctf-lookup unnamed-field-info test checks
	C compiler-observed field offsets against libctf-computed ones
	by #including the testcase in the lookup runner as well as
	generating CTF for it.  This only works if the host, on which
	the lookup runner is compiled and executed, is the same architecture as
	the target, for which the CTF is generated: when crossing, the trick
	may fail.

	So pass down an indication of whether this is a cross into the
	testsuite, and add a new no_cross flag to .lk files that is used to
	suppress test execution when a cross-compiler is being tested.

	libctf/
		* Makefile.am (check_DEJAGNU): Pass down TEST_CROSS.
		* Makefile.in: Regenerated.
		* testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to
		implement the new no_cross option.
		* testsuite/libctf-lookup/unnamed-field-info.lk: Mark as
		no_cross.

2023-04-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-07  Tom Tromey  <tromey@adacore.com>

	Rewrite Ada symbol cache
	In an experiment I'm trying, I needed Ada symbol cache entries to be
	allocated with 'new'.  This patch reimplements the symbol cache to use
	the libiberty hash table and to use new and delete.  A couple of other
	minor cleanups are done.

	Add Ada test case for break using a label
	I noticed there aren't any Ada test cases for setting a breakpoint
	using a label.  This patch adds one, adapted from the AdaCore test
	suite.

	Use ui_out for "maint info frame-unwinders"
	This changes "maint info frame-unwinders" to use ui-out.  This makes
	the table slightly nicer.  In general I think it's better to use
	ui-out for tables.

2023-04-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS
	Whenever we start gdb in the testsuite, we have the rather verbose:
	...
	$ gdb
	GNU gdb (GDB) 14.0.50.20230405-git
	Copyright (C) 2023 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.
	Type "show copying" and "show warranty" for details.
	This GDB was configured as "x86_64-pc-linux-gnu".
	Type "show configuration" for configuration details.
	For bug reporting instructions, please see:
	<https://www.gnu.org/software/gdb/bugs/>.
	Find the GDB manual and other documentation resources online at:
	    <http://www.gnu.org/software/gdb/documentation/>.

	For help, type "help".
	Type "apropos word" to search for commands related to "word".
	(gdb)
	...

	This makes gdb.log longer than necessary and harder to read.

	We do need to test that the output is produced, but that should be limited to
	one or a few test-cases.

	Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have:
	...
	$ gdb -q
	(gdb)
	...

	Tested on x86_64-linux.

2023-04-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing .note.GNU-stack in gdb.arch/amd64-disp-step-self-call.exp
	For test-case gdb.arch/amd64-disp-step-self-call.exp I get:
	...
	gdb compile failed, ld: warning: amd64-disp-step-self-call0.o: \
	  missing .note.GNU-stack section implies executable stack
	ld: NOTE: This behaviour is deprecated and will be removed in a future \
	  version of the linker
	...

	Fix this by adding the missing .note.GNU-stack.

	Likewise for gdb.arch/i386-disp-step-self-call.exp.

	Tested on x86_64-linux.

2023-04-07  Haochen Jiang  <haochen.jiang@intel.com>

	Support Intel AMX-COMPLEX
	gas/ChangeLog:

		* NEWS: Support Intel AMX-COMPLEX.
		* config/tc-i386.c: Add amx_complex.
		* doc/c-i386.texi: Document .amx_complex.
		* testsuite/gas/i386/i386.exp: Run AMX-COMPLEX tests.
		* testsuite/gas/i386/amx-complex-inval.l: New test.
		* testsuite/gas/i386/amx-complex-inval.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-bad.s: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex.d: Ditto.
		* testsuite/gas/i386/x86-64-amx-complex.s: Ditto.

	opcodes/ChangeLog:

		* i386-dis.c (MOD_VEX_0F386C_X86_64_W_0): New.
		(PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0): Ditto.
		(X86_64_VEX_0F386C): Ditto.
		(VEX_LEN_0F386C_X86_64_W_0_M_1): Ditto.
		(VEX_W_0F386C_X86_64): Ditto.
		(mod_table): Add MOD_VEX_0F386C_X86_64_W_0.
		(prefix_table): Add PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0.
		(x86_64_table): Add X86_64_VEX_0F386C.
		(vex_len_table): Add VEX_LEN_0F386C_X86_64_W_0_M_1.
		(vex_w_table): Add VEX_W_0F386C_X86_64.
		* i386-gen.c (cpu_flag_init): Add CPU_AMX_COMPLEX_FLAGS and
		CPU_ANY_AMX_COMPLEX_FLAGS.
		* i386-init.h: Regenerated.
		* i386-mnem.h: Ditto.
		* i386-opc.h (CpuAMX_COMPLEX): New.
		(i386_cpu_flags): Add cpuamx_complex.
		* i386-opc.tbl: Add AMX-COMPLEX instructions.
		* i386-tbl.h: Regenerated.

2023-04-07  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: updates for gdb.arch/{amd64,i386}-disp-step-self-call.exp
	This commit:

	  commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
	  Date:   Wed Feb 22 12:15:34 2023 +0000

	      gdb: fix reg corruption from displaced stepping on amd64

	Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and
	gdb.arch/i386-disp-step-self-call.exp.  These scripts contained a test
	that included a stack address in the test name, this makes it harder
	to compare results between runs.

	This commit gives the tests proper names that doesn't include an
	address.

	Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were
	writing 8-bytes rather than 4 in order to clear the return address
	entry on the stack.  This is also fixed in this commit.

2023-04-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-06  Tom Tromey  <tromey@adacore.com>

	Use unique_xmalloc_ptr in apply_ext_lang_type_printers
	This changes apply_ext_lang_type_printers to use unique_xmalloc_ptr,
	removing some manual memory management.  Regression tested on x86-64
	Fedora 36.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-04-06  Pedro Alves  <pedro@palves.net>

	Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC
	Clang with LTO (clang -flto) garbage collects unused global variables,
	Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with
	hundreds of FAILs like so:

	 $ make check \
	    TESTS="gdb.*/align-*.exp" \
	    RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'"
	 ...
	 FAIL: gdb.base/align-c.exp: get integer valueof "a_char"
	 FAIL: gdb.base/align-c.exp: print _Alignof(char)
	 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char"
	 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char)
	 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char"
	 ...

	AIX GCC has the same issue, and there the easier way of adding
	__attribute__((used)) to globals does not help.

	So add explicit uses of all globals to the generated code.

	For the C++ test, that reveals that the static variable members of the
	generated structs are not defined anywhere, leading to undefined
	references.  Fixed by emitting initialization for all static members.

	Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's
	because the align-c++.exp testcase is compiling with the C compiler
	driver.  Fixed by passing "c++" as option to prepare_for_testing.

	Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: run black code formatter on gdbarch_components.py
	The following commit changed gdbarch_components.py but failed to
	format it with black:

	  commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
	  Date:   Wed Feb 22 12:15:34 2023 +0000

	      gdb: fix reg corruption from displaced stepping on amd64

	This commit just runs black on the file and commits the result.

	The change is just the addition of an extra "," -- there will be no
	change to the generated source files after this commit.

	There will be no user visible changes after this commit.

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: allow Frame.read_var to accept named arguments
	This commit allows Frame.read_var to accept named arguments, and also
	improves (I think) some of the error messages emitted when values of
	the wrong type are passed to this function.

	The read_var method takes two arguments, one a variable, which is
	either a gdb.Symbol or a string, while the second, optional, argument
	is always a gdb.Block.

	I'm now using 'O!' as the format specifier for the second argument,
	which allows the argument type to be checked early on.  Currently, if
	the second argument is of the wrong type then we get this error:

	  (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
	  Traceback (most recent call last):
	    File "<string>", line 1, in <module>
	  RuntimeError: Second argument must be block.
	  Error while executing Python code.
	  (gdb)

	After this commit, we now get an error like this:

	  (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
	  Traceback (most recent call last):
	    File "<string>", line 1, in <module>
	  TypeError: argument 2 must be gdb.Block, not str
	  Error while executing Python code.
	  (gdb)

	Changes are:

	  1. Exception type is TypeError not RuntimeError, this is unfortunate
	  as user code _could_ be relying on this, but I think the improvement
	  is worth the risk, user code relying on the exact exception type is
	  likely to be pretty rare,

	  2. New error message gives argument position and expected argument
	  type, as well as the type that was passed.

	If the first argument, the variable, has the wrong type then the
	previous exception was already a TypeError, however, I've updated the
	text of the exception to more closely match the "standard" error
	message we see above.  If the first argument has the wrong type then
	before this commit we saw this:

	  (gdb) python print(gdb.selected_frame().read_var(123))
	  Traceback (most recent call last):
	    File "<string>", line 1, in <module>
	  TypeError: Argument must be a symbol or string.
	  Error while executing Python code.
	  (gdb)

	And after we see this:

	  (gdb) python print(gdb.selected_frame().read_var(123))
	  Traceback (most recent call last):
	    File "<string>", line 1, in <module>
	  TypeError: argument 1 must be gdb.Symbol or str, not int
	  Error while executing Python code.
	  (gdb)

	For existing code that doesn't use named arguments and doesn't rely on
	exceptions, there will be no changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: convert Frame.read_register to take named arguments
	Following on from the previous commit, this updates
	Frame.read_register to accept named arguments.  As with the previous
	commit there's no huge benefit for the users in accepting named
	arguments here -- this function only takes a single argument after
	all.

	But I do think it is worth keeping Frame.read_register method in sync
	with the PendingFrame.read_register method, this allows for the
	possibility that the user has some code that can operate on either a
	Frame or a Pending frame.

	Minor update to allow for named arguments, and an extra test to check
	the new functionality.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: have PendingFrame methods accept keyword arguments
	Update the two gdb.PendingFrame methods gdb.PendingFrame.read_register
	and gdb.PendingFrame.create_unwind_info to accept keyword arguments.

	There's no huge benefit for making this change, both of these methods
	only take a single argument, so it is (maybe) less likely that a user
	will take advantage of the keyword arguments in these cases, but I
	think it's nice to be consistent, and I don't see any particular draw
	backs to making this change.

	For PendingFrame.read_register I've changed the argument name from
	'reg' to 'register' in the documentation and used 'register' as the
	argument name in GDB.  My preference for APIs is to use full words
	where possible, and given we didn't support named arguments before
	this change should not break any existing code.

	There should be no user visible changes (for existing code) after this
	commit.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: have UnwindInfo.add_saved_register accept named args
	Update gdb.UnwindInfo.add_saved_register to accept named keyword
	arguments.

	As part of this update we now use gdb_PyArg_ParseTupleAndKeywords
	instead of PyArg_UnpackTuple to parse the function arguments.

	By switching to gdb_PyArg_ParseTupleAndKeywords, we can now use 'O!'
	as the argument format for the function's value argument.  This means
	that we can check the argument type (is gdb.Value) as part of the
	argument processing rather than manually performing the check later in
	the function.  One result of this is that we now get a better error
	message (at least, I think so).  Previously we would get something
	like:

	  ValueError: Bad register value

	Now we get:

	  TypeError: argument 2 must be gdb.Value, not XXXX

	It's unfortunate that the exception type changed, but I think the new
	exception type actually makes more sense.

	My preference for argument names is to use full words where that's not
	too excessive.  As such, I've updated the name of the argument from
	'reg' to 'register' in the documentation, which is the argument name
	I've made GDB look for here.

	For existing unwinder code that doesn't throw any exceptions nothing
	should change with this commit.  It is possible that a user has some
	code that throws and catches the ValueError, and this code will break
	after this commit, but I think this is going to be sufficiently rare
	that we can take the risk here.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix reg corruption from displaced stepping on amd64
	This commit aims to address a problem that exists with the current
	approach to displaced stepping, and was identified in PR gdb/22921.

	Displaced stepping is currently supported on AArch64, ARM, amd64,
	i386, rs6000 (ppc), and s390.  Of these, I believe there is a problem
	with the current approach which will impact amd64 and ARM, and can
	lead to random register corruption when the inferior makes use of
	asynchronous signals and GDB is using displaced stepping.

	The problem can be found in displaced_step_buffers::finish in
	displaced-stepping.c, and is this; after GDB tries to perform a
	displaced step, and the inferior stops, GDB classifies the stop into
	one of two states, either the displaced step succeeded, or the
	displaced step failed.

	If the displaced step succeeded then gdbarch_displaced_step_fixup is
	called, which has the job of fixing up the state of the current
	inferior as if the step had not been performed in a displaced manner.
	This all seems just fine.

	However, if the displaced step is considered to have not completed
	then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB
	remains in displaced_step_buffers::finish and just performs a minimal
	fixup which involves adjusting the program counter back to its
	original value.

	The problem here is that for amd64 and ARM setting up for a displaced
	step can involve changing the values in some temporary registers.  If
	the displaced step succeeds then this is fine; after the step the
	temporary registers are restored to their original values in the
	architecture specific code.

	But if the displaced step does not succeed then the temporary
	registers are never restored, and they retain their modified values.

	In this context a temporary register is simply any register that is
	not otherwise used by the instruction being stepped that the
	architecture specific code considers safe to borrow for the lifetime
	of the instruction being stepped.

	In the bug PR gdb/22921, the amd64 instruction being stepped is
	an rip-relative instruction like this:

	  jmp    *0x2fe2(%rip)

	When we displaced step this instruction we borrow a register, and
	modify the instruction to something like:

	  jmp    *0x2fe2(%rcx)

	with %rcx having its value adjusted to contain the original %rip
	value.

	Now if the displaced step does not succeed, then %rcx will be left
	with a corrupted value.  Obviously corrupting any register is bad; in
	the bug report this problem was spotted because %rcx is used as a
	function argument register.

	And finally, why might a displaced step not succeed?  Asynchronous
	signals provides one reason.  GDB sets up for the displaced step and,
	at that precise moment, the OS delivers a signal (SIGALRM in the bug
	report), the signal stops the inferior at the address of the displaced
	instruction.  GDB cancels the displaced instruction, handles the
	signal, and then tries again with the displaced step.  But it is that
	first cancellation of the displaced step that causes the problem; in
	that case GDB (correctly) sees the displaced step as having not
	completed, and so does not perform the architecture specific fixup,
	leaving the register corrupted.

	The reason why I think AArch64, rs600, i386, and s390 are not effected
	by this problem is that I don't believe these architectures make use
	of any temporary registers, so when a displaced step is not completed
	successfully, the minimal fix up is sufficient.

	On amd64 we use at most one temporary register.

	On ARM, looking at arm_displaced_step_copy_insn_closure, we could
	modify up to 16 temporary registers, and the instruction being
	displaced stepped could be expanded to multiple replacement
	instructions, which increases the chances of this bug triggering.

	This commit only aims to address the issue on amd64 for now, though I
	believe that the approach I'm proposing here might be applicable for
	ARM too.

	What I propose is that we always call gdbarch_displaced_step_fixup.

	We will now pass an extra argument to gdbarch_displaced_step_fixup,
	this a boolean that indicates whether GDB thinks the displaced step
	completed successfully or not.

	When this flag is false this indicates that the displaced step halted
	for some "other" reason.  On ARM GDB can potentially read the
	inferior's program counter in order figure out how far through the
	sequence of replacement instructions we got, and from that GDB can
	figure out what fixup needs to be performed.

	On targets like amd64 the problem is slightly easier as displaced
	stepping only uses a single replacement instruction.  If the displaced
	step didn't complete the GDB knows that the single instruction didn't
	execute.

	The point is that by always calling gdbarch_displaced_step_fixup, each
	architecture can now ensure that the inferior state is fixed up
	correctly in all cases, not just the success case.

	On amd64 this ensures that we always restore the temporary register
	value, and so bug PR gdb/22921 is resolved.

	In order to move all architectures to this new API, I have moved the
	minimal roll-back version of the code inside the architecture specific
	fixup functions for AArch64, rs600, s390, and ARM.  For all of these
	except ARM I think this is good enough, as no temporaries are used all
	that's needed is the program counter restore anyway.

	For ARM the minimal code is no worse than what we had before, though I
	do consider this architecture's displaced-stepping broken.

	I've updated the gdb.arch/amd64-disp-step.exp test to cover the
	'jmpq*' instruction that was causing problems in the original bug, and
	also added support for testing the displaced step in the presence of
	asynchronous signal delivery.

	I've also added two new tests (for amd64 and i386) that check that GDB
	can correctly handle displaced stepping over a single instruction that
	branches to itself.  I added these tests after a first version of this
	patch relied too much on checking the program-counter value in order
	to see if the displaced instruction had executed.  This works fine in
	almost all cases, but when an instruction branches to itself a pure
	program counter check is not sufficient.  The new tests expose this
	problem.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22921

	Approved-By: Pedro Alves <pedro@palves.net>

2023-04-06  Alan Modra  <amodra@gmail.com>

	Re: objcopy write_debugging_info memory leaks
	Oops, tried to free too much

		* wrstabs.c (write_stabs_in_sections_debugging_info): Don't
		free strings.

2023-04-06  Alan Modra  <amodra@gmail.com>

	objdump print_debugging_info memory leaks
	Fix memory leaks and do a general tidy of the code for printing coff
	and stabs debug.

		* prdbg.c: Delete unnneeded forward function declarations.
		Delete unnecessary casts throughout.  Free all strings
		returned from pop_type throughout file.
		(struct pr_stack): Delete "num_parents".  Replace tests for
		"num_parents" non-zero with tests of "parents" non-NULL
		throughout.  Free "parents" before assigning, and set to NULL
		after freeing.  Remove const from "method".  Always strdup
		strings assigned to method, and free before assigning.
		(print_debugging_info): Free info.stack and info.filename.

2023-04-06  Alan Modra  <amodra@gmail.com>

	objdump -g on gcc COFF/PE files
	objdump -g can't be used much.  Trying to dump PE files invariably
	seems to run into "debug_name_type: no current file" or similar
	errors, because parse_coff expects a C_FILE symbol to be the first
	symbol.  Dumping -gstabs output works since the N_SO stab is present.
	Pre-setting the file name won't hurt stabs dumping.

		* rddbg.c (read_debugging_info): Call debug_set_filename.

2023-04-06  Alan Modra  <amodra@gmail.com>

	gas/write.c use better types
	A tiny tidy.

		* write.c (frags_chained): Make it a bool.
		(n_fixups): Make it unsigned.

2023-04-06  Alan Modra  <amodra@gmail.com>

	objcopy write_debugging_info memory leaks
	The old stabs code didn't bother too much about freeing memory.
	This patch corrects that and avoids some dubious copying of strings.

		* objcopy.c (write_debugging_info): Free both strings and
		syms on failure to create sections.
		* wrstabs.c: Delete unnecessary forward declarations and casts
		throughout file.
		(stab_write_symbol_and_free): New function.  Use it
		throughout, simplifying return paths.
		(stab_push_string): Don't strdup string.  Use it thoughout
		for malloced strings.
		(stab_push_string_dup): New function.  Use it throughout for
		strings in auto buffers.
		(write_stabs_in_sections_debugging_info): Free malloced memory.
		(stab_enum_type): Increase buffer sizing for worst case.
		(stab_range_type, stab_array_type): Reduce buffer size.
		(stab_set_type): Likewise.
		(stab_method_type): Free args on error return.  Correct
		buffer size.
		(stab_struct_field): Fix memory leaks.
		(stab_class_static_member, stab_class_baseclass): Likewise.
		(stab_start_class_type): Likewise.  Correct buffer size.
		(stab_class_start_method): Correct buffer size.
		(stab_class_method_var): Free memory on error return.
		(stab_start_function): Fix "rettype" memory leak.

2023-04-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-05  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb/testsuite: Default to assembler's preferred debug format in asm-source.exp
	The stabs debug format is obsolete and there's no reason to think that
	toolchains still have good support for it. Therefore, if a specific debug
	format wasn't set in asm-source.exp then leave it to the assembler to
	decide which one to use.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-05  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb: Fix reading of partial symtabs in dbxread.c
	After commit 9675da25357c ("Use unrelocated_addr in minimal symbols"),
	aarch64-linux started failing gdb.asm/asm-source.exp:

	Running /home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.asm/asm-source.exp ...
	PASS: gdb.asm/asm-source.exp: f at main
	PASS: gdb.asm/asm-source.exp: n at main
	PASS: gdb.asm/asm-source.exp: next over macro
	FAIL: gdb.asm/asm-source.exp: step into foo2
	PASS: gdb.asm/asm-source.exp: info target
	PASS: gdb.asm/asm-source.exp: info symbol
	PASS: gdb.asm/asm-source.exp: list
	PASS: gdb.asm/asm-source.exp: search
	FAIL: gdb.asm/asm-source.exp: f in foo2
	FAIL: gdb.asm/asm-source.exp: n in foo2 (the program exited)
	FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
	FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
	PASS: gdb.asm/asm-source.exp: s 2
	PASS: gdb.asm/asm-source.exp: n 2
	FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
	PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
	FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
	FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
	PASS: gdb.asm/asm-source.exp: info sources
	FAIL: gdb.asm/asm-source.exp: info line
	FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
	FAIL: gdb.asm/asm-source.exp: return from foo2
	PASS: gdb.asm/asm-source.exp: look at global variable
	PASS: gdb.asm/asm-source.exp: x/i &globalvar
	PASS: gdb.asm/asm-source.exp: disassem &globalvar, (int *) &globalvar+1
	PASS: gdb.asm/asm-source.exp: look at static variable
	PASS: gdb.asm/asm-source.exp: x/i &staticvar
	PASS: gdb.asm/asm-source.exp: disassem &staticvar, (int *) &staticvar+1
	PASS: gdb.asm/asm-source.exp: look at static function

	The problem is simple: a pair of parentheses was removed from the
	expression calculating text_end and thus text_size was only added if
	lowest_text_address wasn't equal to -1.

	This patch restores the previous behaviour and fixes the testcase.
	Tested on native aarch64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-05  Eli Zaretskii  <eliz@gnu.org>

	Improve documentation of GDB build requirements and options
	MPFR is now mandatory, so its previous description in Requirements
	was inappropriate and out of place.  In addition, the description
	of how to go about specifying 'configure' time options for
	building with libraries was highly repetitive.  Some of the text
	was also outdated and used wrong markup.

	Original patch and suggestions from Philippe Blain
	<levraiphilippeblain@gmail.com>.

	ChangeLog:
	2023-04-05  Eli Zaretskii  <eliz@gnu.org>

		* gdb/doc/gdb.texinfo (Requirements, Configure Options): Update and
		rearrange; improve and fix markup.

2023-04-05  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, doc: add the missing '-gid' option to 'info threads'
	The 'info threads' command does not show the '-gid' option
	in the syntax.  Add the option.  The flag is already explained
	in the command description and used in the examples.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-04-05  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb: boolify 'should_print_thread'
	Convert the return type of 'should_print_thread' from int to bool.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make find_thread_ptid a process_stratum_target method
	Make find_thread_ptid (the overload that takes a process_stratum_target)
	a method of process_stratum_target.

	Change-Id: Ib190a925a83c6b93e9c585dc7c6ab65efbdd8629
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make find_thread_ptid an inferior method
	Make find_thread_ptid (the overload that takes an inferior) a method of
	struct inferior.

	Change-Id: Ie5b9fa623ff35aa7ddb45e2805254fc8e83c9cd4
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-04-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-04  Jan Beulich  <jbeulich@suse.com>

	bfd+ld: when / whether to generate .c files
	Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re-
	generated in x86-only builds, I came across 769a27ade588 ("Re: bfd
	BLD-POTFILES.in dependencies"). I think this went slightly too far, as
	outside of maintainer mode dependencies will cause the subset of files
	to be (re-)generated which are actually needed for the build.
	Generating them all is only needed when wanting to update certain files
	under bfd/po/, i.e. in maintainer mode.

	In the course of looking around in an attempt to try to understand how
	things are meant to work, I further noticed that ld has got things
	slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't
	quite right (the output doesn't change when any of the enumerated files
	changes; it's the mere presence which matters); like in bfd it looks
	like we would better extend BUILT_SOURCES accordingly.

	Furthermore it became apparent that ld fails to enumerate the .c files
	generated from the .l and .y ones. While in their absence it was benign
	whether translatable strings in the source files were actually marked as
	such, this now becomes relevant. Mark respective strings at the same
	time, but skipping ones which look to be of interest for debugging
	purposes only (e.g. such used by printf() enclosed in #ifdef TRACE).

2023-04-04  Alan Modra  <amodra@gmail.com>

	Use bfd_alloc memory for read_debugging_info storage
	Trying to free malloc'd memory used by the stabs and coff debug info
	parsers is complicated, and traversing the trees generated requires a
	lot of code.  It's better to bfd_alloc the memory which allows it all
	to be freed without fuss when the bfd is closed.  In the process of
	doing this I reverted most of commit a6336913332.

	Some of the stabs handling code grows arrays of pointers with realloc,
	to deal with arbitrary numbers of fields, function args, etc.  The
	code still does that but copies over to bfd_alloc memory when
	finished.  The alternative is to parse twice, once to size, then again
	to populate the arrays.  I think that complication is unwarranted.

	Note that there is a greater than zero chance this patch breaks
	something, eg. that I missed an attempt to free obj_alloc memory.
	Also it seems there are no tests in the binutils testsuite aimed at
	exercising objdump --debugging.

		* budbg.h (finish_stab, parse_stab): Update prototypes
		* debug.c: Include bucomm.h.
		(struct debug_handle): Add "abfd" field.
		(debug_init): Add "abfd" param.  bfd_alloc handle.
		(debug_xalloc, debug_xzalloc): New functions.  Use throughout
		in place of xmalloc and memset.
		(debug_start_source): Remove "name_used" param.
		* debug.h (debug_init, debug_start_source): Update prototypes.
		(debug_xalloc, debug_xzalloc): Declare.
		* objcopy.c (copy_object): Don't free dhandle.
		* objdump.c (dump_bfd): Likewise.
		* rdcoff.c (coff_get_slot): Add dhandle arg.  debug_xzalloc
		memory in place of xcalloc.  Update callers.
		(parse_coff_struct_type): Don't leak on error return.  Copy
		fields over to debug_xalloc memory.
		(parse_coff_enum_type): Copy names and vals over the
		debug_xalloc memory.
		* rddbg.c (read_debugging_info): Adjust debug_init call.
		Don't free dhandle.
		(read_section_stabs_debugging_info): Don't free shandle.
		Adjust parse_stab call.  Call finish_stab on error return.
		(read_symbol_stabs_debugging_info): Similarly.
		* stabs.c (savestring): Delete unnecessary forward declaration.
		Add dhandle param.  debug_xalloc memory.  Update callers.
		(start_stab): Delete unnecessary casts.
		(finish_stab): Add "emit" param.  Free file_types, so_string,
		and stabs handle.
		(parse_stab): Delete string_used param.  Revert code dealing
		with string_used.  Copy so_string passed to debug_set_filename
		and stored as main_filename to debug_xalloc memory.  Similarly
		for string passed to debug_start_source and push_bincl.  Copy
		args to debug_xalloc memory.  Don't leak args.
		(parse_stab_enum_type): Copy names and values to debug_xalloc
		memory.  Don't free name.
		(parse_stab_struct_type): Don't free fields.
		(parse_stab_baseclasses): Delete unnecessary cast.
		(parse_stab_struct_fields): Return debug_xalloc fields.
		(parse_stab_cpp_abbrev): Use debug_xalloc for _vb$ type name.
		(parse_stab_one_struct_field): Don't free name.
		(parse_stab_members): Copy variants and methods to
		debug_xalloc memory.  Don't free name or argtypes.
		(parse_stab_argtypes): Use debug_xalloc memory for physname
		and args.
		(push_bincl): Add dhandle param.  Use debug_xalloc memory.
		(stab_record_variable): Use debug_xalloc memory.
		(stab_emit_pending_vars): Don't free var list.
		(stab_find_slot): Add dhandle param.  Use debug_xzalloc
		memory.  Update all callers.
		(stab_find_tagged_type): Don't free name.  Use debug_xzalloc.
		(stab_demangle_qualified): Don't free name.
		(stab_demangle_template): Don't free s1.
		(stab_demangle_args): Tidy pvarargs refs.  Copy *pargs on
		success to debug_xalloc memory, free on failure.
		(stab_demangle_fund_type): Don't free name.
		(stab_demangle_v3_arglist): Copy args to debug_xalloc memory.
		Don't free dt.

2023-04-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-03  Tom Tromey  <tromey@adacore.com>

	Add readMemory and writeMemory requests to DAP
	This adds the DAP readMemory and writeMemory requests.  A small change
	to the evaluation code is needed in order to test this -- this is one
	of the few ways for a client to actually acquire a memory reference.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: cleanup around some set_momentary_breakpoint_at_pc calls
	I noticed a couple of places in infrun.c where we call
	set_momentary_breakpoint_at_pc, and then set the newly created
	breakpoint's thread field, these are in:

	  insert_exception_resume_breakpoint
	  insert_exception_resume_from_probe

	Function set_momentary_breakpoint_at_pc calls
	set_momentary_breakpoint, which always creates the breakpoint as
	thread-specific for the current inferior_thread().

	The two insert_* functions mentioned above take an arbitrary
	thread_info* as an argument and set the breakpoint::thread to hold the
	thread number of that arbitrary thread.

	However, the insert_* functions store the breakpoint pointer within
	the current inferior_thread(), so we know that the thread being passed
	in must be the currently selected thread.

	What this means is that we can:

	  1. Assert that the thread being passed in is the currently selected
	  thread, and

	  2. No longer adjust the breakpoint::thread field, this will already
	  have been set correctly be calling set_momentary_breakpoint_at_pc.

	There should be no user visible changes after this commit.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't always print breakpoint location after failed condition check
	Consider the following session:

	  (gdb) list some_func
	  1	int
	  2	some_func ()
	  3	{
	  4	  int *p = 0;
	  5	  return *p;
	  6	}
	  7
	  8	void
	  9	foo ()
	  10	{
	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  Error in testing condition for breakpoint 1:
	  The program being debugged stopped while in a function called from GDB.
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.

	  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  (gdb)

	What happens here is the breakpoint condition includes a call to an
	inferior function, and the inferior function segfaults.  We can see
	that GDB reports the segfault, and then gives an error message that
	indicates that an inferior function call was interrupted.

	After this GDB appears to report that it is stopped at Breakpoint 1,
	inside some_func.

	I find this second stop report a little confusing.  While it is true
	that GDB stopped as a result of hitting breakpoint 1, I think the
	message GDB currently prints might give the impression that GDB is
	actually stopped at a location of breakpoint 1, which is not the case.

	Also, I find the second stop message draws attention away from
	the "Program received signal SIGSEGV, Segmentation fault" stop
	message, and this second stop might be thought of as replacing in
	someway the earlier message.

	In short, I think things would be clearer if the second stop message
	were not reported at all, so the output should, I think, look like
	this:

	  (gdb) list some_func
	  1	int
	  2	some_func ()
	  3	{
	  4	  int *p = 0;
	  5	  return *p;
	  6	}
	  7
	  8	void
	  9	foo ()
	  10	{
	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  Error in testing condition for breakpoint 1:
	  The program being debugged stopped while in a function called from GDB.
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.
	  (gdb)

	The user can still find the number of the breakpoint that triggered
	the initial stop in this line:

	  Error in testing condition for breakpoint 1:

	But there's now only one stop reason reported, the SIGSEGV, which I
	think is much clearer.

	To achieve this change I set the bpstat::print field when:

	  (a) a breakpoint condition evaluation failed, and

	  (b) the $pc of the thread changed during condition evaluation.

	I've updated the existing tests that checked the error message printed
	when a breakpoint condition evaluation failed.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: avoid repeated signal reporting during failed conditional breakpoint
	Consider the following case:

	  (gdb) list some_func
	  1	int
	  2	some_func ()
	  3	{
	  4	  int *p = 0;
	  5	  return *p;
	  6	}
	  7
	  8	void
	  9	foo ()
	  10	{
	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  Error in testing breakpoint condition:
	  The program being debugged was signaled while in a function called from GDB.
	  GDB remains in the frame where the signal was received.
	  To change this behavior use "set unwindonsignal on".
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.

	  Program received signal SIGSEGV, Segmentation fault.

	  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  (gdb)

	Notice that this line:

	  Program received signal SIGSEGV, Segmentation fault.

	Appears twice in the output.  The first time is followed by the
	current location.  The second time is a little odd, why do we print
	that?

	Printing that line is controlled, in part, by a global variable,
	stopped_by_random_signal.  This variable is reset to zero in
	handle_signal_stop, and is set if/when GDB figures out that the
	inferior stopped due to some random signal.

	The problem is, in our case, GDB first stops at the breakpoint for
	foo, and enters handle_signal_stop and the stopped_by_random_signal
	global is reset to 0.

	Later within handle_signal_stop GDB calls bpstat_stop_status, it is
	within this function (via bpstat_check_breakpoint_conditions) that the
	breakpoint condition is checked, and, we end up calling the inferior
	function (some_func in our example above).

	In our case above the thread performing the inferior function call
	segfaults in some_func.  GDB catches the SIGSEGV and handles the stop,
	this causes us to reenter handle_signal_stop.  The global variable
	stopped_by_random_signal is updated, this time it is set to true
	because the thread stopped due to SIGSEGV.  As a result of this we
	print the first instance of the line (as seen above in the example).

	Finally we unwind GDB's call stack, the inferior function call is
	complete, and we return to the original handle_signal_stop.  However,
	the stopped_by_random_signal global is still carrying the value as
	computed for the inferior function call's stop, which is why we now
	print a second instance of the line, as seen in the example.

	To prevent this, I propose adding a scoped_restore before we start an
	inferior function call.  This will save and restore the global
	stopped_by_random_signal value.

	With this done, the output from our example is now this:

	 (gdb) list some_func
	  1	int
	  2	some_func ()
	  3	{
	  4	  int *p = 0;
	  5	  return *p;
	  6	}
	  7
	  8	void
	  9	foo ()
	  10	{
	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  Error in testing condition for breakpoint 1:
	  The program being debugged stopped while in a function called from GDB.
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.

	  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  (gdb)

	We now only see the 'Program received signal SIGSEGV, ...' line once,
	which I think makes more sense.

	Finally, I'm aware that the last few lines, that report the stop as
	being at 'Breakpoint 1', when this is not where the thread is actually
	located anymore, is not great.  I'll address that in the next commit.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: allow agent expressions to fail with invalid memory access
	This commit extends gdbserver to take account of a failed memory
	access from agent_mem_read, and to return a new eval_result_type
	expr_eval_invalid_memory_access.

	I have only updated the agent_mem_read calls related directly to
	reading memory, I have not updated any of the calls related to
	tracepoint data collection.  This is just because I'm not familiar
	with that area of gdb/gdbserver, and I don't want to break anything,
	so leaving the existing behaviour untouched seems like the safest
	approach.

	I've then updated gdb.base/bp-cond-failure.exp to test evaluating the
	breakpoints on the target, and have also extended the test so that it
	checks for different sizes of memory access.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: allows agent_mem_read to return an error code
	Currently the gdbserver function agent_mem_read ignores any errors
	from calling read_inferior_memory.  This means that if there is an
	attempt to access invalid memory then this will appear to succeed.

	In this patch I update agent_mem_read so that if read_inferior_memory
	fails, agent_mem_read will return an error code.

	However, none of the callers of agent_mem_read actually check the
	return value, so this commit will have no effect on anything.  In the
	next commit I will update the users of agent_mem_read to check for the
	error code.

	I've also updated the header comments on agent_mem_read to better
	reflect what the function does, and its possible return values.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb: include breakpoint number in testing condition error message
	When GDB fails to test the condition of a conditional breakpoint, for
	whatever reason, the error message looks like this:

	  (gdb) break foo if (*(int *) 0) == 1
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond
	  Error in testing breakpoint condition:
	  Cannot access memory at address 0x0

	  Breakpoint 1, foo () at bpcond.c:11
	  11	  int a = 32;
	  (gdb)

	The line I'm interested in for this commit is this one:

	  Error in testing breakpoint condition:

	In the case above we can figure out that the problematic breakpoint
	was #1 because in the final line of the message GDB reports the stop
	at breakpoint #1.

	However, in the next few patches I plan to change this.  In some cases
	I don't think it makes sense for GDB to report the stop as being at
	breakpoint #1, consider this case:

	  (gdb) list some_func
	  1	int
	  2	some_func ()
	  3	{
	  4	  int *p = 0;
	  5	  return *p;
	  6	}
	  7
	  8	void
	  9	foo ()
	  10	{
	  (gdb) break foo if (some_func ())
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond

	  Program received signal SIGSEGV, Segmentation fault.
	  0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  Error in testing breakpoint condition:
	  The program being debugged was signaled while in a function called from GDB.
	  GDB remains in the frame where the signal was received.
	  To change this behavior use "set unwindonsignal on".
	  Evaluation of the expression containing the function
	  (some_func) will be abandoned.
	  When the function is done executing, GDB will silently stop.

	  Program received signal SIGSEGV, Segmentation fault.

	  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
	  5	  return *p;
	  (gdb)

	Notice that, the final lines of output reports the stop as being at
	breakpoint #1, even though the inferior in not located within
	some_func, and it's certainly not located at the breakpoint location.

	I find this behaviour confusing, and propose that this should be
	changed.  However, if I make that change then every reference to
	breakpoint #1 will be lost from the error message.

	So, in this commit, in preparation for the later commits, I propose to
	change the 'Error in testing breakpoint condition:' line to this:

	  Error in testing condition for breakpoint NUMBER:

	where NUMBER will be filled in as appropriate.  Here's the first
	example with the updated error:

	  (gdb) break foo if (*(int *) 0) == 0
	  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
	  (gdb) r
	  Starting program: /tmp/bpcond
	  Error in testing condition for breakpoint 1:
	  Cannot access memory at address 0x0

	  Breakpoint 1, foo () at bpcond.c:11
	  11	  int a = 32;
	  (gdb)

	The breakpoint number does now appear twice in the output, but I don't
	see that as a negative.

	This commit just changes the one line of the error, and updates the
	few tests that either included the old error in comments, or actually
	checked for the error in the expected output.

	As the only test that checked the line I modified is a Python test,
	I've added a new test that doesn't rely on Python that checks the
	error message in detail.

	While working on the new test, I spotted that it would fail when run
	with native-gdbserver and native-extended-gdbserver target boards.
	This turns out to be due to a gdbserver bug.  To avoid cluttering this
	commit I've added a work around to the new test script so that the
	test passes for the remote boards, in the next few commits I will fix
	gdbserver, and update the test script to remove the work around.

2023-04-03  Alan Modra  <amodra@gmail.com>

	asan: csky floatformat_to_double uninitialised value
		* csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't
		access ibytes after read_memory_func error.  Change type of
		ibytes to avoid casts.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/riscv: fix regressions in gdb.base/unwind-on-each-insn.exp
	This commit builds on the previous one to fix all the remaining
	failures in gdb.base/unwind-on-each-insn.exp for RISC-V.

	The problem we have in gdb.base/unwind-on-each-insn.exp is that, when
	we are in the function epilogue, the previous frame and stack pointer
	values are being restored, and so, the values that we calculated
	during the function prologue are no longer suitable.

	Here's an example from the function 'bar' in the mentioned test.  This
	was compiled for 64-bit RISC-V with compressed instruction support:

	  Dump of assembler code for function bar:
	     0x000000000001018a <+0>:	add	sp,sp,-32
	     0x000000000001018c <+2>:	sd	ra,24(sp)
	     0x000000000001018e <+4>:	sd	fp,16(sp)
	     0x0000000000010190 <+6>:	add	fp,sp,32
	     0x0000000000010192 <+8>:	sd	a0,-24(fp)
	     0x0000000000010196 <+12>:	ld	a0,-24(fp)
	     0x000000000001019a <+16>:	jal	0x10178 <foo>
	     0x000000000001019e <+20>:	nop
	     0x00000000000101a0 <+22>:	ld	ra,24(sp)
	     0x00000000000101a2 <+24>:	ld	fp,16(sp)
	     0x00000000000101a4 <+26>:	add	sp,sp,32
	     0x00000000000101a6 <+28>:	ret
	  End of assembler dump.

	When we are at address 0x101a4 the previous instruction has restored
	the frame-pointer, as such GDB's (current) preference for using the
	frame-pointer as the frame base address is clearly not going to work.
	We need to switch to using the stack-pointer instead.

	At address 0x101a6 the previous instruction has restored the
	stack-pointer value.  Currently GDB will not understand this and so
	will still assume the stack has been decreased by 32 bytes in this
	function.

	My proposed solution is to extend GDB such that GDB will scan the
	instructions at the current $pc looking for this pattern:

	  ld    fp,16(sp)
	  add   sp,sp,32
	  ret

	Obviously the immediates can change, but the basic pattern indicates
	that the function is in the process of restoring state before
	returning.  If GDB sees this pattern then GDB can use the inferior's
	position within this instruction sequence to help calculate the
	correct frame-id.

	With this implemented then gdb.base/unwind-on-each-insn.exp now fully
	passes.

	Obviously what I've implemented is just a heuristic.  It's not going
	to work for every function.  If the compiler reorders the
	instructions, or merges the epilogue back into the function body then
	GDB is once again going to get the frame-id wrong.

	I'm OK with that, we're no worse off that we are right now in that
	situation (plus we can always improve the heuristic later).

	Remember, this is for debugging code without debug information,
	and (in our imagined situation) with more aggressive levels of
	optimisation being used.  Obviously GDB is going to struggle in these
	situations.

	My thinking is, lets get something in place now.  Then, later, if
	possible, we might be able to improve the logic to cover more
	situations -- if there's an interest in doing so.  But I figure we
	need something in place as a starting point.

	After this commit gdb.base/unwind-on-each-insn.exp passes with no
	failures on RV64.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/riscv: support c.ldsp and c.lwsp in prologue scanner
	Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp
	instructions.

	This fixes some of the failures in gdb.base/unwind-on-each-insn.exp,
	though there are further failures that are not fixed by this commit.

	This change started as a wider fix that would address all the failures
	in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed
	support for the two additional compressed instructions.

	When I added support for those two compressed instructions I noticed
	that some of the failures in gdb.base/unwind-on-each-insn.exp resolved
	themselves!

	Here's what's going on:

	The reason for the failures is that GDB is trying to build the
	frame-id during the last few instructions of the function.  These are
	the instructions that restore the frame and stack pointers just prior
	to the return instruction itself.

	By the time we reach the function epilogue the stack offset that we
	calculated during the prologue scan is no longer valid, and so we
	calculate the wrong frame-id.

	However, in the particular case of interest here, the test function
	'foo', the function is so simple and short (the empty function) that
	GDB's prologue scan could, in theory, scan every instruction of the
	function.

	I say "could, in theory," because currently GDB stops the prologue
	scan early when it hits an unknown instruction.  The unknown
	instruction happens to be one of the compressed instructions that I'm
	adding support for in this commit.

	Now that GDB understands the compressed instructions the prologue scan
	really does go from the start of the function right up to the current
	program counter.  As such, GDB sees that the stack frame has been
	allocated, and then deallocated, and so builds the correct frame-id.

	Of course, most real functions are not as simple as the test function
	'foo'.  As such, we can't usually rely on scanning right up to the end
	of the function -- there are some instructions we always need to stop
	at because GDB can't reason about how they change the inferior
	state (e.g. a function call).  The test function 'bar' is just such an
	example.

	After this commit, we can now build the frame-id correctly for every
	instruction in 'foo', but there are some tests still failing in 'bar'.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/riscv: convert riscv debug settings to new debug print scheme
	Convert the RISC-V specific debug settings to use the new debug
	printing scheme.  This updates the following settings:

	  set/show debug riscv breakpoints
	  set/show debug riscv gdbarch
	  set/show debug riscv infcall
	  set/show debug riscv unwinder

	All of these settings now take a boolean rather than an integer, and
	all print their output using the new debug scheme.

	There should be no visible change for anyone not turning on debug.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	opcodes/arm: adjust whitespace in cpsie instruction
	While I was working on the disassembler styling for ARM I noticed that
	the whitespace in the cpsie instruction was inconsistent with most of
	the other ARM disassembly output, the disassembly for cpsie looks like
	this:

	  cpsie   if,#10

	notice there's no space before the '#10' immediate, most other ARM
	instructions have a space before each operand.

	This commit updates the disassembler to add the missing space, and
	updates the tests I found that tested this instruction.

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: gdb.server/server-kill.exp 'info frame' before kill_server
	This commit follows on from the following two commits:

	  commit 80dc83fd0e70f4d522a534bc601df5e05b81d564
	  Date:   Fri Jun 11 11:30:47 2021 +0100

	      gdb/remote: handle target dying just before a stepi

	And:

	  commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53
	  Date:   Thu Mar 9 10:45:03 2023 +0100

	      [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target

	The first of these commits fixed an issue in GDB and tried to extend
	the gdb.server/server-kill.exp test to cover the GDB fix.

	Unfortunately, the changes to gdb.server/server-kill.exp were not
	correct, and were causing problems when trying to run with the
	remote-gdbserver-on-localhost board file.

	The second commit reverts some of the gdb.server/server-kill.exp
	changes introduced in the first commit so that the test will now work
	correctly with the remote-gdbserver-on-localhost board file.

	The second commit is just about GDB's testing infrastructure -- it's
	not about the original fix to GDB from the first commit, the actual
	GDB change was fine.

	While reviewing the second commit I wanted to check that the problem
	fixed in the first commit is still being tested by the
	gdb.server/server-kill.exp script, so I reverted the change to
	breakpoint.c that is the core of the first commit and ran the test
	script ..... and saw no failures.

	The first commit is about GDB discovering that gdbserver has died
	while trying to insert a breakpoint.  As soon as GDB spots that
	gdbserver is gone we mourn the remote inferior, which ends up deleting
	all the breakpoints associated with the remote inferiors.  We then
	throw an exception which is caught in the insert breakpoints code, and
	we try to display an error that includes the breakpoint number
	.... but the breakpoint has already been deleted ... and so GDB
	crashes.

	After digging a little, what I found is that today, when the test does
	'stepi' the first thing we end up doing is calculating the frame-id as
	part of the stepi logic, it is during this frame-id calculation that
	we mourn the remote inferior, delete the breakpoints, and throw an
	exception.  The exception is caught by the top level interpreter loop,
	and so we never try to print the breakpoint number which is what
	caused the original crash.

	If I add an 'info frame' command to the test script, prior to killing
	gdbserver, then now when we 'stepi' GDB already has the frame-id
	calculated, and the first thing we do is try to insert the
	breakpoints, this will trigger the original bug.

	In order to reproduce this experiment you'll need to change a function
	in breakpoint.c, like this:

	  static void
	  rethrow_on_target_close_error (const gdb_exception &e)
	  {
	    return;
	  }

	Then run gdb.server/server-kill.exp with and without this patch.  You
	should find that without this patch there are zero test failures,
	while with this patch there will be one failure like this:

	  (gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
	  Executing on target: kill -9 4513    (timeout = 300)
	  builtin_spawn -ignore SIGHUP kill -9 4513
	  stepi
	  ../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
	  A problem internal to GDB has been detected,
	  further debugging may prove unreliable.
	  ----- Backtrace -----
	  ...

2023-04-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix failure in gdb.python/py-unwind.exp
	A potential test failure was introduced with commit:

	  commit 6bf5f25bb150c0fbcb125e3ee466ba8f9680310b
	  Date:   Wed Mar 8 16:11:30 2023 +0000

	      gdb/python: make the gdb.unwinder.Unwinder class more robust

	In this commit a new test was added, however the expected output
	pattern varies depending on which Python version GDB is linked
	against.

	Older versions of Python result in output like this:

	    (gdb) python global_test_unwinder.name = "foo"
	    Traceback (most recent call last):
	      File "<string>", line 1, in <module>
	    AttributeError: can't set attribute
	    Error while executing Python code.
	    (gdb)

	While more recent versions of Python give a similar, but slightly more
	verbose error message, like this:

	    (gdb) python global_test_unwinder.name = "foo"
	    Traceback (most recent call last):
	      File "<string>", line 1, in <module>
	    AttributeError: can't set attribute 'name'
	    Error while executing Python code.
	    (gdb)

	The test was only accepting the first version of the output.  This
	commit extends the test pattern so that either version will be
	accepted.

2023-04-03  Luis Machado  <luis.machado@arm.com>

	[aarch64] tpidr2: Fix erroneous detection logic for TPIDR2
	The detection logic for TPIDR2 was implemented incorrectly.  Originally
	the detection was supposed to be through a ptrace error code, but in reality,
	for backwards compatibility, the detection should be based on the size of
	the returned iovec.

	For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a
	iovec size of 16.  If a target only supports TPIDR and not TPIDR2, it will
	return a iovec size of 8, even if we asked for 16 bytes.

	This patch fixes this issue in code that is shared between gdb and gdbserver,
	therefore both gdb and gdbserver are fixed.

	Tested on AArch64/Linux Ubuntu 20.04.

2023-04-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-02  Alan Modra  <amodra@gmail.com>

	asan: heap buffer overflow printing ecoff debug info file name
	A case of a string section ending with an unterminated string.  Fix it
	by allocating one more byte and making it zero.  Also make functions
	reading the data return void* so that casts are not needed.

		* ecoff.c (READ): Delete type param.  Allocate one extra byte
		to terminate string sections with a NUL.  Adjust invocation.
		* elfxx-mips.c (READ): Likewise.
		* libbfd-in.h (_bfd_alloc_and_read): Return a void*.
		(_bfd_malloc_and_read): Likewise.
		* libbfd.h: Regenerate.

2023-04-02  Alan Modra  <amodra@gmail.com>

	ubsan: aarch64 parse_vector_reg_list
	tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places
	cannot be represented in type 'int'.

		* config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left
		shift.

2023-04-02  Alan Modra  <amodra@gmail.com>

	rddbg.c stabs FIXMEs
	This should sort out some very old FIXMEs in code handling stabs
	debug info.  Necessary if we are to fuss over freeing up memory before
	objdump and objcopy exit.  It is of course better from a user
	viewpoint to *not* free memory, which takes some time, and leave that
	to process exit.  The only reason to do so is that having many memory
	leaks in binutils/ code tends to hide leaks in bfd/ or opcodes/, which
	we should care about.

		* budbg.h (parse_stab): Update prototype.
		* debug.h (debug_start_source): Update prototype.
		* debug.c (debug_start_source): Add name_used.  Set if stashed.
		* rddbg.c (read_symbol_stabs_debugging_info): Always malloc
		stab string passed to parse_stab.  Free stab string when
		unreferenced.
		(read_section_stabs_debugging_info): Likewise, and strings
		section contents.
		* stabs.c (parse_stab): Add string_used param.  Set if string
		stashed.  Pass to debug_start_source.  Realloc file_types
		array rather that using malloc.  Clarify comment about
		debug_make_indirect_type.

2023-04-02  Alan Modra  <amodra@gmail.com>

	Memory leak in process_abbrev_set
	We may have added some abbrevs to the list before hitting an error.
	Free the list elements too.  free_abbrev_list returns list->next so we
	need to init it earlier to avoid an uninitialised memory access.

		* dwarf.c (process_abbrev_set): Call free_abbrev_list on errors.
		Set list->next earlier.

2023-04-02  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove unused parameters in print_doc_of_command, apropos_cmd
	I noticed the prefix parameter was unused in print_doc_of_command.  And
	when removing it, it becomes unused in apropos_cmd.

	Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e

2023-04-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-04-01  Jan Kratochvil  <jan.kratochvil@redhat.com>

	gdb/arm: Fix backtrace for pthread_cond_timedwait
	GDB expected PC should point right after the SVC instruction when the
	syscall is active. But some active syscalls keep PC pointing to the SVC
	instruction itself.

	This leads to a broken backtrace like:
	 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
	 #0  0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
	 #1  0xb6e21f80 in ?? ()

	The reason is that .ARM.exidx unwinder gives up if PC does not point
	right after the SVC (syscall) instruction. I did not investigate why but
	some syscalls will point PC to the SVC instruction itself. This happens
	for the "futex" syscall used by pthread_cond_timedwait.

	That normally does not matter as ARM prologue unwinder gets called
	instead of the .ARM.exidx one. Unfortunately some glibc calls have more
	complicated prologue where the GDB unwinder fails to properly determine
	the return address (that is in fact an orthogonal GDB bug). I expect it
	is due to the "vpush" there in this case but I did not investigate it more:

	Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4:
	   0xb6f8757c <+0>:     push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
	   0xb6f87580 <+4>:     mov     r10, r2
	   0xb6f87584 <+8>:     vpush   {d8}

	Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11).

	Approved-By: Luis Machado <luis.machado@arm.com>

2023-04-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-31  H.J. Lu  <hjl.tools@gmail.com>

	lto: Don't add indirect symbols for versioned aliases in IR
	Linker adds indirect symbols for versioned symbol aliases, which are
	created by ".symver foo, foo@FOO", by checking symbol type, value and
	section so that references to foo will be replaced by references to
	foo@FOO if foo and foo@FOO have the same symbol type, value and section.
	But in IR, since all symbols of the same type have the same value and
	section, we can't tell if a symbol is an alias of another symbol by
	their types, values and sections.  We shouldn't add indirect symbols
	for versioned symbol aliases in IR.

	bfd/

		PR ld/30281
		* elflink.c (elf_link_add_object_symbols): Don't add indirect
		symbols for ".symver foo, foo@FOO" aliases in IR.

	ld/

		PR ld/30281
		* testsuite/ld-plugin/lto.exp: Add PR ld/30281 test.
		* testsuite/ld-plugin/pr30281.t: New file.
		* testsuite/ld-plugin/pr30281.c: Likewise.

2023-03-31  Tom Tromey  <tom@tromey.com>

	Fix maybe-uninitialized warning in frame.c
	A recent patch caused my system gcc (Fedora 36, so gcc 12.2.1) to warn
	about sym_addr being possibly uninitialized in frame.c.  It isn't, but
	the compiler can't tell.  So, this patch initializes the variable.  I
	also fixed a formatting buglet that I missed in review.

2023-03-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/trace-commands.exp with editing off
	With test-case gdb.base/trace-commands.exp and editing off, I run into fails
	because multi-line commands are issued using gdb_test_sequence, which
	doesn't handle them correctly.

	Fix this by using gdb_test instead.

	Tested on x86_64-linux.

	PR testsuite/30288
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288

2023-03-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/threadapply.exp with editing off
	With test-case gdb.threads/threadapply.exp and editing set to on, we have:
	...
	(gdb) define remove^M
	Type commands for definition of "remove".^M
	End with a line saying just "end".^M
	>remove-inferiors 3^M
	>end^M
	(gdb)
	...
	but with editing set to off, we run into:
	...
	(gdb) define remove^M
	Type commands for definition of "remove".^M
	End with a line saying just "end".^M
	>remove-inferiors 3^M
	end^M
	>(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
	  define remove (timeout)
	...

	The commands are issued by this test:
	...
		gdb_define_cmd "remove" {
		    "remove-inferiors 3"
		}
	...
	which does:
	- gdb_test_multiple "define remove", followed by
	- gdb_test_multiple "remove-inferiors 3\nend".

	Proc gdb_test_multiple has special handling for multi-line commands, which
	splits it up into subcommands, and for each subcommand issues it and then
	waits for the resulting prompt (the secondary prompt ">" for all but the last
	subcommand).

	However, that doesn't work as expected in this case because the initial
	gdb_test_multiple "define remove" fails to match all resulting output, and
	consequently the secondary prompt resulting from "define remove" is counted as
	if it was the one resulting from "remove-inferiors 3".

	Fix this by matching the entire output of "define remove", including the
	secondary prompt.

	Tested on x86_64-linux.

	PR testsuite/30288
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288

2023-03-31  Tom Tromey  <tom@tromey.com>

	Remove language_demangle
	I noticed that language_demangle shadows the global
	"current_language".  When I went to fix this, though, I then saw that
	language_demangle is only called in two places, and has a comment
	saying it should be removed.  This patch removes it.  Note that the
	NULL check in language_demangle is not needed by either of the
	existing callers.

	Regression tested on x86-64 Fedora 36.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-31  Tom Tromey  <tom@tromey.com>

	Fix race in background index-cache writing
	Tom de Vries pointed out a bug in the index-cache background writer --
	sometimes it will fail.  He also noted that it fails when the number
	of worker threads is set to zero.  These turn out to be the same
	problem -- the cache can't be written to until the per-BFD's
	"index_table" member is set.

	This patch avoids the race by rearranging the code slightly, to ensure
	the cache cannot possibly be written before the member is set.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261

2023-03-31  Richard Bunt  <richard.bunt@linaro.org>

	GDB: Add `info main' command
	Allow consumers of GDB to extract the name of the main method.  This is
	most useful for Fortran programs which have a variable main method.

	Used by both MAP and DDT e.g. it is used to detect the presence of debug
	information.

	Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>

2023-03-31  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Bring back the handling of DW_CC_program
	Fix a functional regression and restore the handling of DW_CC_program
	code of DW_AT_calling_convention attribute for determining the name of
	the starting function of the program where the DW_AT_main_subprogram
	attribute has not been provided, such as with Fortran code compiled with
	GCC versions 4.5.4 and below, or where DWARF version 3 or below has been
	requested.  Without it "main" is considered the starting function.  Cf.
	GCC PR fortran/43414.

	Original code was removed with commit 6209cde4ddb8 ("Delete DWARF
	psymtab code"), and then an update to complement commit 81873cc81eff
	("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also
	been included here.

2023-03-31  Richard Bunt  <richard.bunt@linaro.org>

	GDB: Favor full symbol main name for backtrace stop
	In the case where a Fortran program has a program name of "main" and
	there is also a minimal symbol called main, such as with programs built
	with GCC version 4.4.7 or below, the backtrace will erroneously stop at
	the minimal symbol rather than the user specified main, e.g.:

	(gdb) bt
	#0  bar () at .../gdb/testsuite/gdb.fortran/backtrace.f90:17
	#1  0x0000000000402556 in foo () at .../gdb/testsuite/gdb.fortran/backtrace.f90:21
	#2  0x0000000000402575 in main () at .../gdb/testsuite/gdb.fortran/backtrace.f90:31
	#3  0x00000000004025aa in main ()
	(gdb)

	This patch fixes this issue by increasing the precedence of the full
	symbol when the language of the current frame is Fortran.

	Newer versions of GCC transform the program name to "MAIN__" in this
	case, avoiding the problem.

	Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>

2023-03-31  Ari Hannula  <ari.hannula@intel.com>

	gdb: Remove extra if statement
	The removed if statement is already checked in the parent if else
	statement.

	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-03-31  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Allocate "various" operand type
	This commit intends to move operands that require very special handling or
	operand types that are so minor (e.g. only useful on a few instructions)
	under "W".  I also intend this "W" to be "temporary" operand storage until
	we can find good two character (or less) operand type.

	In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved
	to "Wif" because of its special handling (and allocating single character
	"f" for this operand type seemed too much).

	Current expected allocation guideline is as follows:

	1.  'W'
	2.  The most closely related single-letter extension in lowercase
	    (strongly recommended but not mandatory)
	3.  Identify operand type

	The author currently plans to allocate following three-character operand
	types (for operands including instructions from unratified extensions).

	1.  "Wif" ('Zicbop': fetch offset)
	2.  "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions)
	3.  "Wfm" / "WfM"
	    'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling
	                          solely for widening conversion instructions.

	gas/ChangeLog:

		* config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from
		"f" to "Wif".

	opcodes/ChangeLog:

		* riscv-dis.c (print_insn_args): Move from "f" to "Wif".
		* riscv-opc.c (riscv_opcodes): Reflect new operand type.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: convert testcases to use .insn
	This can't be done for all insns currently encoded with .byte. For one
	outside of 64-bit mode unused (typically ignored) register encoding bits
	in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
	the necessary registers cannot be specified (and some of these bits
	can't even be used outside of 64-bit mode). And then there are odd tests
	like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
	together with EVEX.W (which could be expressed; note though EVEX.W set
	is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
	it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
	because that's another #UD reason).

	In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
	byte but insufficient displacement bytes, some using SIB encoding with
	the SIB byte actually being the supposed immediate. Some of these could
	be expressed by .insn, but I don't want to introduce bogus examples.
	These will all need adjustment anyway once the disassembler is improved
	in the way it deals with unrecognized encodings.

	Generally generated code is meant to remain the same. {,x86-64-}nops.d
	are exceptions because insn prefixes are emitted in a different order.
	opcode{,-intel,-suffix}.d are also adjusted (along with an according
	correction to opcode.s) to cover an apparent typo in the original tests
	(xor when or was meant).

	Where necessary --divide is added as gas option, to allow for the use
	of the extension opcode functionality.

	Comments are being adjusted where obviously wrong/misleading.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: document .insn
	... and mention its introduction in NEWS.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: handle immediate operands for .insn
	Since we have no insn suffix and it's also not realistic to infer
	immediate size from the size of other (typically register) operands
	(like optimize_imm() does), and since we also don't have a template
	telling us permitted size(s), a new syntax construct is introduced to
	allow size (and signedness) specification. In the absence of such, the
	size is inferred from significant bits (which obviously may yield
	inconsistent results at least for effectively negative values, depending
	on whether BFD64 is enabled), and only if supplied expressions can be
	evaluated at parsing time. Being explicit is generally recommended to
	users.

	Size specification is permitted at bit granularity, but of course the
	eventually emitted immediate values will be padded up to 8-, 16-, 32-,
	or 64-bit fields.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: allow for multiple immediates in output_disp()
	.insn isn't going to have a constraint of only a single immediate when,
	in particular, RIP-relative addressing is used.

	x86: handle EVEX Disp8 for .insn
	In particular the scaling factor cannot always be determined from pre-
	existing operand attributes. Introduce a new {:d<N>} vector operand
	syntax extension, restricted to .insn only, to allow specifying this in
	(at least) otherwise ambiguous cases.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: process instruction operands for .insn
	Deal with register and memory operands; immediate operands will follow
	later, as will the handling of EVEX embedded broadcast and EVEX Disp8
	scaling.

	Note that because we can't really know how to encode their use, %cr8 and
	up cannot be used with .insn outside of 64-bit mode. Users would need to
	specify an explicit LOCK prefix in combination with %cr0 etc.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: parse special opcode modifiers for .insn
	So called "short form" encoding is specified by a trailing "+r", whereas
	a possible extension opcode is specified by the usual "/<digit>". Take
	these off the expression before handing it to get_absolute_expression().

	Note that on targets where / starts a comment, --divide needs passing to
	gas in order to make use of the extension opcode functionality.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: parse VEX and alike specifiers for .insn
	All encoding spaces can be used this way; there's a certain risk that
	the bits presently reserved could be used for other purposes down the
	road, but people using .insn are expected to know what they're doing
	anyway. Plus this way there's at least _some_ way to have those bits
	set.

	For now this will only allow operand-less insns to be encoded this way.

2023-03-31  Jan Beulich  <jbeulich@suse.com>

	x86: introduce .insn directive
	For starters this deals with only very basic constructs.

	Arm64/ELF: accept relocations against STN_UNDEF
	While only a secondary issue there, the testcase of PR gas/27212 exposes
	an oversight in relocation handling: Just like e.g. Arm32, which has a
	similar comment and a similar check, relocations against STN_UNDEF have
	to be permitted to satisfy the ELF spec.

2023-03-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-30  Kevin Buettner  <kevinb@redhat.com>

	PR gdb/30219: Clear sync_quit_force_run in quit_force
	PR 30219 shows an internal error due to a "Bad switch" in
	print_exception() in gdb/exceptions.c.  The switch in question
	contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
	for the recently added RETURN_FORCED_QUIT.  This commit adds that case.

	Making the above change allows the errant test case to pass, but does
	not fix the underlying problem, which I'll describe shortly.  Even
	though the addition of a case for RETURN_FORCED_QUIT isn't the actual
	fix, I still think it's important to add this case so that other
	situations which lead to print_exeption() being called won't generate
	that "Bad switch" internal error.

	In order to understand the underlying problem, please examine
	this portion of the backtrace from the bug report:

	0x5576e4ff5780 print_exception
	        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
	0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
	        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
	0x5576e6a896dd quit_force(int*, int)
	        /home/smarchi/src/binutils-gdb/gdb/top.c:1849

	The real problem is in quit_force; here's the try/catch which
	eventually leads to the internal error:

	  /* Get out of tfind mode, and kill or detach all inferiors.  */
	  try
	    {
	      disconnect_tracing ();
	      for (inferior *inf : all_inferiors ())
		kill_or_detach (inf, from_tty);
	    }
	  catch (const gdb_exception &ex)
	    {
	      exception_print (gdb_stderr, ex);
	    }

	While running the calls in the try-block, a QUIT check is being
	performed.  This check finds that sync_quit_force_run is (still) set,
	causing a gdb_exception_forced_quit to be thrown.  The exception
	gdb_exception_forced_quit is derived from gdb_exception, causing
	exception_print to be called.  As shown by the backtrace,
	print_exception is then called, leading to the internal error.

	The actual fix, also implemented by this commit, is to clear
	sync_quit_force_run along with the quit flag.  This will allow the
	various cleanup code, called by quit_force, to run without triggering
	a gdb_exception_forced_quit.  (Though, if another SIGTERM is sent to
	the gdb process, these flags will be set again and a QUIT check in the
	cleanup code will detect it and throw the exception.)

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Remove stray reglist variable
	Sorry for not catching this during testing.  I was using a
	host compiler that predated the switch to -fno-common.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the RPRFM instruction
	This patch adds the RPRFM (range prefetch) instruction.
	It was introduced as part of SME2, but it belongs to the
	prefetch hint space and so doesn't require any specific
	ISA flags.

	The aarch64_rprfmop_array initialiser (deliberately) only
	fills in the leading non-null elements.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SVE FCLAMP instruction

	aarch64: Add new SVE shift instructions
	This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN
	instructions.

	aarch64: Add new SVE saturating conversion instructions
	This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions,
	which are available when FEAT_SME2 is implemented.

	aarch64: Add new SVE dot-product instructions
	This patch adds the SVE FDOT, SDOT and UDOT instructions,
	which are available when FEAT_SME2 is implemented.  The patch
	also reorders the existing SVE_Zm3_22_INDEX to keep the
	operands numerically sorted.

	aarch64: Add the SVE BFMLSL instructions
	This patch adds the SVE BFMLSLB and BFMLSLT instructions,
	which are available when FEAT_SME2 is implemented.

	aarch64: Add the SME2 UZP and ZIP instructions
	This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2}
	into single instructions.

	aarch64: Add the SME2 UNPK instructions
	This patch adds SUNPK and UUNPK, which unpack one register's
	worth of elements to two registers' worth, or two registers'
	worth to four registers' worth.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 shift instructions
	There are two instruction formats here:

	- SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two
	  or four registers.

	- SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of
	  four registers.

	These are the first SME2 instructions to have immediate operands.
	The patch makes sure that, when parsing SME2 instructions with
	immediate operands, the new predicate-as-counter registers are
	parsed as registers rather than as #-less immediates.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 saturating conversion instructions
	There are two instruction formats here:

	- SQCVT, SQCVTU and UQCVT, which operate on lists of two or
	  four registers.

	- SQCVTN, SQCVTUN and UQCVTN, which operate on lists of
	  four registers.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 FP<->FP conversion instructions
	This patch adds the BFCVT{,N} and FCVT{,N} instructions,
	which narrow a pair of .S registers to a single .H register.

	aarch64: Add the SME2 FP<->int conversion instructions
	This patch adds the SME2 versions of the FP<->integer conversion
	instructions FCVT* and *CVTF.  It also adds FP rounding instructions
	FRINT*, which share the same format.

	aarch64: Add the SME2 CLAMP instructions
	FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP
	doesn't have a .B form.

	aarch64: Add the SME2 MOPA and MOPS instructions
	[BSU]MOP[AS] share the same format.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 vertical dot-product instructions
	There are three instruction formats here:
	- BFVDOT + FVDOT
	- SVDOT + UVDOT
	- SUVDOT + USVDOT

	There are also 64-bit forms of SVDOT and UVDOT.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 dot-product instructions
	BFDOT, FDOT and USDOT share the same instruction format.
	SDOT and UDOT share a different format.  SUDOT does not
	have the multi vector x multi vector forms, since they
	would be redundant with USDOT.

	aarch64: Add the SME2 MLALL and MLSLL instructions
	SMLALL, SMLSLL, UMLALL and UMLSLL have the same format.
	USMLALL and SUMLALL allow the same operand types as those
	instructions, except that SUMLALL does not have the multi-vector
	x multi-vector forms (which would be redundant with USMLALL).

	aarch64: Add the SME2 MLAL and MLSL instructions
	The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same
	encoding.  They are the first instance of a ZA (as opposed to ZA tile)
	operand having a range of offsets.  As with ZA tiles, the expected
	range size is encoded in the operand-specific data field.

	aarch64: Add the SME2 FMLA and FMLS instructions

	aarch64: Add the SME2 maximum/minimum instructions
	This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM}
	and {S,U}{MAX,MIN}.  SQDMULH, SRSHL and URSHL have the same form
	as SMAX etc., so the patch adds them too.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 ADD and SUB instructions
	Add support for the SME2 ADD. SUB, FADD and FSUB instructions.
	SUB and FSUB have the same form as ADD and FADD, except that
	ADD also has a 2-operand accumulating form.

	The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the
	64-bit FADD/FSUB instructions require FEAT_SME_F64F64.

	These are the first instructions to have tied register list
	operands, as opposed to tied single registers.

	The parse_operands change prevents unsuffixed Z registers (width==-1)
	from being treated as though they had an Advanced SIMD-style suffix
	(.4s etc.).  It means that:

	  Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

	becomes:

	  Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 ZT0 instructions
	SME2 adds lookup table instructions for quantisation.  They use
	a new lookup table register called ZT0.

	LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>],
	which is the first time that this syntax has been used.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 predicate-related instructions
	Implementation-wise, the main things to note here are:

	- the WHILE* instructions have forms that return a pair of predicate
	  registers.  This is the first time that we've had lists of predicate
	  registers, and they wrap around after register 15 rather than after
	  register 31.

	- the predicate-as-counter WHILE* instructions have a fourth operand
	  that specifies the vector length.  We can treat this as an enumeration,
	  except that immediate values aren't allowed.

	- PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>].
	  This is the first instance of a vector/predicate index having
	  no suffix.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 multivector LD1 and ST1 instructions
	SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers.
	The registers can be consecutive or strided.  In the strided case,
	2-register lists have a stride of 8, starting at register x0xxx.
	4-register lists have a stride of 4, starting at register x00xx.

	The instructions are predicated on a predicate-as-counter register in
	the range pn8-pn15.  Although we already had register fields with upper
	bounds of 7 and 15, this is the first plain register operand to have a
	nonzero lower bound.  The patch uses the operand-specific data field
	to record the minimum value, rather than having separate inserters
	and extractors for each lower bound.  This in turn required adding
	an extra bit to the field.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add the SME2 MOVA instructions
	SME2 defines new MOVA instructions for moving multiple registers
	to and from ZA.  As with SME, the instructions are also available
	through MOV aliases.

	One notable feature of these instructions (and many other SME2
	instructions) is that some register lists must start at a multiple
	of the list's size.  The patch uses the general error "start register
	out of range" when this constraint isn't met, rather than an error
	specifically about multiples.  This ensures that the error is
	consistent between these simple consecutive lists and later
	strided lists, for which the requirements aren't a simple multiple.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add support for predicate-as-counter registers
	SME2 adds a new format for the existing SVE predicate registers:
	predicates as counters rather than predicates as masks.  In assembly
	code, operands that interpret predicates as counters are written
	pn<N> rather than p<N>.

	This patch adds support for these registers and extends some
	existing instructions to support them.  Since the new forms
	are just a programmer convenience, there's no need to make them
	more restrictive than the earlier predicate-as-mask forms.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64; Add support for vector offset ranges
	Some SME2 instructions operate on a range of consecutive ZA vectors.
	This is indicated by syntax such as:

	   za[<Wv>, <imml>:<immh>]

	Like with the earlier vgx2 and vgx4 support, we get better error
	messages if the parser allows all ZA indices to have a range.
	We can then reject invalid cases during constraint checking.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add support for vgx2 and vgx4
	Many SME2 instructions operate on groups of 2 or 4 ZA vectors.
	This is indicated by adding a "vgx2" or "vgx4" group size to the
	ZA index.  The group size is optional in assembly but preferred
	for disassembly.

	There is not a binary distinction between mnemonics that have
	group sizes and mnemonics that don't, nor between mnemonics that
	take vgx2 and mnemonics that take vgx4.  We therefore get better
	error messages if we allow any ZA index to have a group size
	during parsing, and wait until constraint checking to reject
	invalid sizes.

	A quirk of the way errors are reported means that if an instruction
	is wrong both in its qualifiers and its use of a group size, we'll
	print suggested alternative instructions that also have an incorrect
	group size.  But that's a general property that also applies to
	things like out-of-range immediates.  It's also not obviously the
	wrong thing to do.  We need to be relatively confident that we're
	looking at the right opcode before reporting detailed operand-specific
	errors, so doing qualifier checking first seems resonable.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array
	SME2 adds various new fields that are similar to
	AARCH64_OPND_SME_ZA_array, but are distinguished by the size of
	their offset fields.  This patch adds _off4 to the name of the
	field that we already have.

	aarch64: Add a _10 suffix to FLD_imm3
	SME2 adds various new 3-bit immediate fields, so this patch adds
	an lsb position suffix to the name of the field that we already have.

	aarch64: Add +sme2
	This patch adds bare-bones support for +sme2.  Later patches
	fill in the rest.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Prefer register ranges & support wrapping
	Until now, binutils has supported register ranges such
	as { v0.4s - v3.4s } as an unofficial shorthand for
	{ v0.4s, v1.4s, v2.4s, v3.4s }.  The SME2 ISA embraces this form
	and makes it the preferred disassembly.  It also embraces wrapped
	lists such as { z31.s - z2.s }, which is something that binutils
	didn't previously allow.

	The range form was already binutils's preferred disassembly for 3- and
	4-register lists.  This patch prefers it for 2-register lists too.
	The patch also adds support for wrap-around.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add support for strided register lists
	SME2 has instructions that accept strided register lists,
	such as { z0.s, z4.s, z8.s, z12.s }.  The purpose of this
	patch is to extend binutils to support such lists.

	The parsing code already had (unused) support for strides of 2.
	The idea here is instead to accept all strides during parsing
	and reject invalid strides during constraint checking.

	The SME2 instructions that accept strided operands also have
	non-strided forms.  The errors about invalid strides therefore
	take a bitmask of acceptable strides, which allows multiple
	possibilities to be summed up in a single message.

	I've tried to update all code that handles register lists.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Sort fields alphanumerically
	This patch just sorts the field enum alphanumerically, which makes
	it easier to see if a particular field has already been defined.

	aarch64: Resync field names
	This patch just makes the comments in aarch64-opc.c:fields match
	the names of the associated FLD_* enum.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Regularise FLD_* suffixes
	Some FLD_imm* suffixes used a counting scheme such as FLD_immN,
	FLD_immN_2, FLD_immN_3, etc., while others used the lsb as the
	suffix.  The latter seems more mnemonic, and was a big help
	in doing the SME2 work.

	Similarly, the _10 suffix on FLD_SME_size_10 was nonobvious.
	Presumably it indicated a 2-bit field, but it actually starts
	in bit 22.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Rename some of GAS's REG_TYPE_* macros
	In GAS, the vector and predicate registers are identified by
	REG_TYPE_VN, REG_TYPE_ZN and REG_TYPE_PN.  This "N" is obviously
	a placeholder for the register number.  However, we don't use that
	convention for integer and FP registers, and (more importantly)
	SME2 adds "predicate-as-counter" registers that are denoted PN.

	This patch therefore drops the "N" suffix from the existing
	registers.  The main hitch is that Z was also used for the
	zero register in things like R_Z, but using ZR seems more
	consistent with the SP-based names.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add a aarch64_cpu_supports_inst_p helper
	Quite a lot of SME2 instructions have an opcode bit that selects
	between 32-bit and 64-bit forms of an instruction, with the 32-bit
	forms being part of base SME2 and with the 64-bit forms being part
	of an optional extension.  It's nevertheless useful to have a single
	opcode entry for both forms since (a) that matches the ISA definition
	and (b) it tends to improve error reporting.

	This patch therefore adds a libopcodes function called
	aarch64_cpu_supports_inst_p that tests whether the target
	supports a particular instruction.  In future it will depend
	on internal libopcodes routines.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Reorder some OP_SVE_* macros
	This patch just moves some out-of-order-looking OP_SVE_* macros.

	aarch64: Rename aarch64-tbl.h OP_SME_* macros
	This patch renames the OP_SME_* macros in aarch64-tbl.h so that
	they follow the same scheme as the OP_SVE_* ones.  It also uses
	OP_SVE_ as the prefix, since there is no real distinction between
	the SVE and SME uses of qualifiers: a macro defined for one can
	be useful for the other too.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Tweak priorities of parsing-related errors
	There are three main kinds of error reported during parsing,
	in increasing order of priority:

	- AARCH64_OPDE_RECOVERABLE (register seen instead of immediate)
	- AARCH64_OPDE_SYNTAX_ERROR
	- AARCH64_OPDE_FATAL_SYNTAX_ERROR

	This priority makes sense when comparing errors reported against the
	same operand.  But if we get to operand 3 (say) and see a register
	instead of an immediate, that's likely to be a better match than
	something that fails with a syntax error at operand 1.

	The idea of this patch is to prioritise parsing-related errors
	based on operand index first, then by error code.  Post-parsing
	errors still win over parsing errors, and their relative priorities
	don't change.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Try to report invalid variants against the closest match
	If an instruction has invalid qualifiers, GAS would report the
	error against the final opcode entry that got to the qualifier-
	checking stage.  It seems better to report the error against
	the opcode entry that had the closest match, just like we
	pick the closest match within an opcode entry for the
	"did you mean this?" message.

	This patch adds the number of invalid operands as an
	argument to AARCH64_OPDE_INVALID_VARIANT and then picks the
	AARCH64_OPDE_INVALID_VARIANT with the lowest argument.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Tweak register list errors
	The error for invalid register lists had the form:

	  invalid number of registers in the list; N registers are expected at operand M -- `insn'

	This seems a bit verbose.  Also, the "bracketing" is really:

	  (invalid number of registers in the list; N registers are expected) at operand M

	but the semicolon works against that.

	This patch goes for slightly shorter messages, setting a template
	that later patches can use for more complex cases.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Make AARCH64_OPDE_REG_LIST take a bitfield
	AARCH64_OPDE_REG_LIST took a single operand that specified the
	expected number of registers.  However, there are quite a few
	SME2 instructions that have both 2-register forms and (separate)
	4-register forms.  If the user tries to use a 3-register list,
	it isn't obvious which opcode entry they meant.  Saying that we
	expect 2 registers and saying that we expect 4 registers would
	both be wrong.

	This patch therefore switches the operand to a bitfield.  If a
	AARCH64_OPDE_REG_LIST is reported against multiple opcode entries,
	the patch ORs up the expected lengths.

	This has no user-visible effect yet.  A later patch adds more error
	strings, alongside tests that use them.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Add an operand class for SVE register lists
	SVE register lists were classified as SVE_REG, since there had been
	no particular reason to separate them out.  However, some SME2
	instructions have tied register list operands, and so we need to
	distinguish registers and register lists when checking whether two
	operands match.

	Also, the register list operands used a general error message,
	even though we already have a dedicated error code for register
	lists that are the wrong length.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Commonise checks for index operands
	This patch splits out the constraint checking for index operands,
	so that it can be reused by new SME2 operands.

	aarch64: Add an error code for out-of-range registers
	libopcodes currently reports out-of-range registers as a general
	AARCH64_OPDE_OTHER_ERROR.  However, this means that each register
	range needs its own hard-coded string, which is a bit cumbersome
	if the range is determined programmatically.  This patch therefore
	adds a dedicated error type for out-of-range errors.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Deprioritise AARCH64_OPDE_REG_LIST
	SME2 has many instructions that take a list of SVE registers.
	There are often multiple forms, with different forms taking
	different numbers of registers.

	This means that if, after a successful parse and qualifier match,
	we find that the number of registers does not match the opcode entry,
	the associated error should have a lower priority/severity than other
	errors reported at the same stage.  For example, if there are 2-register
	and 4-register forms of an instruction, and if the assembly code uses
	the 2-register form with an out-of-range value, the out-of-range value
	error against the 2-register instruction should have a higher priority
	than the "wrong number of registers" error against the 4-register
	instruction.

	This is tested by the main SME2 patches, but seemed worth splitting out.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Update operand_mismatch_kind_names
	The contents of operand_mismatch_kind_names were out of sync
	with the enum.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Rework reporting of failed register checks
	There are many opcode table entries that share the same mnemonic.
	Trying to parse an invalid assembly line will trigger an error for
	each of these entries, but the specific error might vary from one
	entry to another, depending on the exact nature of the problem.

	GAS has quite an elaborate system for picking the most appropriate
	error out of all the failed matches.  And in many cases it works well.
	However, one of the limitations is that the error is always reported
	against a single opcode table entry.  If that table entry isn't the
	one that the user intended to use, then the error can end up being
	overly specific.

	This is particularly true if an instruction has a typoed register
	name, or uses a type of register that is not accepted by any
	opcode table entry.  For example, one of the expected error
	matches for an attempted SVE2 instruction is:

	  Error: operand 1 must be a SIMD scalar register -- `addp z32\.s,p0/m,z32\.s,z0\.s'

	even though the hypothetical user was presumably attempting to use
	the SVE form of ADDP rather than the Advanced SIMD one.  There are
	many other instances of this in the testsuite.

	The problem becomes especially acute with SME2, since many SME2
	instructions reuse existing mnemonics.  This could lead to us
	reporting an SME-related error against a non-SME instruction,
	or a non-SME-related error against an SME instruction.

	This patch tries to improve things by collecting together all
	the register types that an opcode table entry expected for a
	given operand.  It also records what kind of register was
	actually seen, if any.  It then tries to summarise all this
	in a more directed way, falling back to a generic error if
	the combination defies a neat summary.

	The patch includes tests for all new messages except REG_TYPE_ZA,
	which only triggers with SME2.

	To test this, I created an assembly file that contained the cross
	product of all known mnemonics and one example from each register
	class.  I then looked for cases where the new routines fell back on the
	generic errors ("expected a register" or "unexpected register type").
	I locally added dummy messages for each one until there were no
	more hits.  The patch adds a specimen instruction to diagnostics.s
	for each of these combinations.  In each case, the combination didn't
	seem like something that could be summarised in a natural way, so the
	generic messages seemed better.  There's always going to be an element
	of personal taste around this kind of thing though.

	Adding more register types made 1<<REG_TYPE_MAX exceed the range
	of the type, but we don't actually need/want 1<<REG_TYPE_MAX.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Try to avoid inappropriate default errors
	After parsing a '{' and the first register, parse_typed_reg would
	report errors in subsequent registers in the same way as for the
	first register.  It used set_default_error, which reports errors
	of the form "operand N must be X".

	The problem is that if there are multiple opcode entries for the
	same mnemonic, there could be several matches that lead to a
	default error.  There's no guarantee that the default error for
	the register list is the one that will be chosen.

	To take an example from the testsuite:

	    ext z0.b,{z31.b,z32.b},#0

	gave:

	    operand 2 must be an SVE vector register

	with the error being reported against the single-vector version
	of ext, even though the operand is clearly a list.

	This patch uses set_fatal_syntax_error to bump the priority of the
	error once we're sure that the operand is a list of the right type.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Improve errors for malformed register lists
	parse_typed_reg is used for parsing both bare registers and
	registers that occur in lists.  If it doesn't see a register,
	or sees an unexpected kind of register, it queues a default
	error to report the problem.  These default errors have the form
	"operand N must be an X", where X comes from the operand table.

	If there are multiple opcode entries that report default errors,
	GAS tries to pick the most appropriate one, using the opcode
	table order as a tiebreaker.  But this can lead to cases where
	a syntax error in a register list is reported against an opcode
	that doesn't accept register lists.  For example, the unlikely
	error:

	  ext z0.b,{,},#0

	is reported as:

	  operand 2 must be an SVE vector register -- `ext z0.b,{,},#0'

	even though operand 2 can be a register list.

	If we've parsed the opening '{' of a register list, and then see
	something that isn't remotely register-like, it seems better to
	report that directly as a syntax error, rather than rely on the
	default error.  The operand won't be a valid list of anything,
	so there's no need to pick a specific Y in "operand N must be
	a list of Y".

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Tweak parsing of integer & FP registers
	Integer registers were parsed indirectly through
	aarch64_reg_parse_32_64 (and thus aarch64_addr_reg_parse) rather
	than directly through parse_reg.  This was because we need the
	qualifier associated with the register, and the logic to calculate
	that was buried in aarch64_addr_reg_parse.

	The code that parses FP registers had the same need, but it
	open-coded the calculation of the qualifier.

	This patch tries to handle both cases in the same way.  It is
	needed by a later patch that tries to improve the register-related
	diagnostics.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Tweak errors for base & offset registers
	parse_address_main currently uses get_reg_expected_msg to
	report invalid base and offset registers, but the disadvantage
	of doing that is that it isn't immediately clear which register
	is wrong (the base or the offset).

	A later patch moves away from using get_reg_expected_msg for failed
	type checks, but doing that here didn't seem like the best approach.
	The patch tries to use more tailored messages instead.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Tweak error for missing immediate offset
	This patch tweaks the error message that is printed when
	a ZA-style index is missing the immediate offset.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Move w12-w15 range check to libopcodes
	In SME, the vector select register had to be in the range
	w12-w15, so it made sense to enforce that during parsing.
	However, SME2 adds instructions for which the range is
	w8-w11 instead.

	This patch therefore moves the range check from the parsing
	stage to the constraint-checking stage.

	Also, the previous error used a capitalised range W12-W15,
	whereas other register range errors used lowercase ranges
	like p0-p7.  A quick internal poll showed a preference for
	the lowercase form, so the patch uses that.

	The patch uses "selection register" rather than "vector
	select register" so that the terminology extends more
	naturally to PSEL.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Commonise index parsing
	Just a minor clean-up to factor out the index parsing, partly to
	ensure that the error handling remains consistent.  No behavioural
	change intended.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Consolidate ZA slice parsing
	Now that parse_typed_reg checks the range of tile register numbers
	and libopcodes checks the range of vector select offsets, there's
	very little difference between the parsing of ZA tile indices,
	ZA array indices, and PSEL indices.  The main one is that ZA
	array indices don't currently allow "za" to be qualified,
	but we need to remove that restriction for SME2.

	This patch therefore consolidates all three parsers into a single
	routine, parameterised by the type of register that they expect.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Move ZA range checks to aarch64-opc.c
	This patch moves the range checks on ZA vector select offsets from
	gas to libopcodes.  Doing the checks there means that the error
	messages contain the expected range.  It also fits in better
	with the error severity scheme, which becomes important later.
	(This is because out-of-range indices are treated as more severe than
	syntax errors, on the basis that parsing must have succeeded if we get
	to the point of checking the completed opcode.)

	The patch also adds a new check_za_access function for checking
	ZA accesses.  That's a bit over the top for one offset check, but the
	function becomes more complex with later patches.

	sme-9-illegal.s checked for an invalid .q suffix using:

	  psel p1, p15, p3.q[w15]

	but this is doubly invalid because it misses the immediate part
	of the index.  The patch keeps that test but adds another with
	a zero index, so that .q is the only thing wrong.

	The aarch64-tbl.h change includes neatening up the backslash
	positions.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Pass aarch64_indexed_za to parsers
	ZA indices have more parts than most operands, so passing these
	parts around individually is more awkward than for other operand
	types.  Things aren't too bad at the moment, but SME2 adds two
	further pieces: an offset range and a vector group size.

	This patch therefore replaces arguments for the individual pieces
	with a single argument for the index as a whole.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Make indexed_za use 64-bit immediates
	A later patch moves the range checking for ZA vector select
	offsets from gas to libopcodes.  That in turn requires the
	immediate field to be big enough to support all parsed values.

	This shouldn't be a particularly size-sensitive structure,
	so there should be no memory problems with doing this.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Rename za_tile_vector to za_index
	za_tile_vector is also used for indexing ZA as a whole, rather than
	just for indexing tiles.  The former is more common than the latter
	in SME2, so this patch generalises the name to "indexed_za".

	The patch also names the associated structure, so that later patches
	can reuse it during parsing.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Treat ZA as a register
	We already treat the ZA tiles ZA0-ZA15 as registers.  This patch
	does the same for ZA itself.  parse_sme_zero_mask can then parse
	ZA tiles and ZA in the same way, through parsed_type_reg.

	One important effect of going through parsed_type_reg (in general)
	is that it allows ZA to take qualifiers.  This is necessary for many
	SME2 instructions.

	However, to support existing unqualified uses of ZA, parse_reg_with_qual
	needs to treat the qualiier as optional.  Hopefully the net effect is
	to give better error messages, since now that SME2 makes "za.<T>"
	valid in some contexts, it might be natural to use it (incorrectly)
	in ZERO too.

	While there, the patch also tweaks the error messages for invalid
	ZA tiles, to try to make some cases more specific.

	For now, parse_sme_za_array just uses parse_reg, rather than
	parse_typed_reg/parse_reg_with_qual.  A later patch consolidates
	the parsing further.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Consolidate ZA tile range checks
	Now that all parsing of ZA tile names goes through parse_typed_reg,
	we can check there for out-of-range tile numbers.  The other check
	performed by parse_sme_zada_operand was to reject .q, but that can
	now be done via F_STRICT instead.  (.q tiles are valid in other
	contexts, so they shouldn't be rejected in parse_typed_reg.)

	aarch64: Reuse parse_typed_reg for ZA tiles
	This patch reuses the general parse_typed_reg for ZA tiles.
	This involves adding a way of suppressing the usual treatment
	of register indices, since ZA indices look very different from
	Advanced SIMD and SVE vector indices.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Rework parse_typed_reg interface
	parse_typed_reg returned a register number and passed the
	register type back using a pointer parameter.  It seems simpler
	to return the register entry instead, since that has both pieces
	of information in one place.

	The patch also replaces the boolean in_reg_list parameter with
	a mask of flags.  This hopefully makes calls easier to read
	(more self-documenting than "true" or "false"), but more
	importantly, it allows a later patch to add a second flag.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Move vectype_to_qualifier further up
	This patch just moves vectype_to_qualifier further up, so that
	a later patch can call it at an earlier point in the file.
	No behavioural change intended.

	aarch64: Add REG_TYPE_ZATHV
	This patch adds a multi-register type that includes both REG_TYPE_ZATH
	and REG_TYPE_ZATV.  This slightly simplifies the existing code, but the
	main purpose is to enable later patches.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Rename REG_TYPE_ZA* to REG_TYPE_ZAT*
	The ZA tile registers were called REG_TYPE_ZA, REG_TYPE_ZAH and
	REG_TYPE_ZAV.  However, a later patch wants to make plain "za"
	a register type too, and REG_TYPE_ZA is the obvious name for that.

	This patch therefore adds "T" (tile) to the existing names.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Use aarch64_operand_error more widely
	GAS's aarch64_instruction had its own cut-down error record,
	but it's better for later patches if it reuses the binutils-wide
	aarch64_operand_error instead.  The main difference is that
	aarch64_operand_error can store arguments to the error while
	aarch64_instruction couldn't.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Make SME instructions use F_STRICT
	This patch makes all SME instructions use F_STRICT, so that qualifiers
	have to be provided explicitly rather than being inferred from other
	operands.  The main change is to move the qualifier setting from the
	operand-level decoders to the opcode level.

	This is one step towards consolidating the ZA parsing code and
	extending it to handle SME2.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Fix SVE2 register/immediate distinction
	GAS refuses to interpret register names like x0 as unadorned
	immediates, due to the obvious potential for confusion with
	register operands.  (An explicit #x0 is OK.)

	For compatibility reasons, we can't extend the set of registers
	that GAS rejects for existing instructions.  For example:

	   mov x0, z0

	was valid code before SVE was added, so it needs to stay valid
	code even when SVE is enabled.  But we can make GAS reject newer
	registers in newer instructions.  The SVE instruction:

	   and z0.s, z0.s, z0.h

	is therefore invalid, rather than z0.h being an immediate.

	This patch extends the SVE behaviour to SVE2.  The old call
	to AARCH64_CPU_HAS_FEATURE was technically the wrong way around,
	although it didn't matter in practice for base SVE instructions
	since their avariants only set SVE.

2023-03-30  Richard Sandiford  <richard.sandiford@arm.com>

	aarch64: Restrict range of PRFM opcodes
	In the register-index forms of PRFM, the unallocated prefetch opcodes
	24-31 have been reused for the encoding of the new RPRFM instruction.
	The PRFM opcode space is now capped at 23 for these forms.  The other
	forms of PRFM are unaffected.

	aarch64: Fix PSEL opcode mask
	The opcode mask for PSEL was missing some bits, which meant
	that some upcoming SME2 opcodes would be misinterpreted as PSELs.

	aarch64: Add sme-i16i64 and sme-f64f64 aliases
	Most extension flags are named after the associated architectural
	FEAT_* flags, but sme-i64 and sme-f64 were exceptions.  This patch
	adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too
	for compatibility.

2023-03-30  Nick Clifton  <nickc@redhat.com>

	Fix an illegal memory access triggered by parsing corrupt DWARF info.
	  PR 30284
	  * dwarf.c (read_and_display_attr_value): Detect and ignore negative base values.

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: Add new gdb.unwinder.FrameId class
	When writing an unwinder it is necessary to create a new class to act
	as a frame-id.  This new class is almost certainly just going to set a
	'sp' and 'pc' attribute within the instance.

	This commit adds a little helper class gdb.unwinder.FrameId that does
	this job.  Users can make use of this to avoid having to write out
	standard boilerplate code any time they write an unwinder.

	Of course, if the user wants their FrameId class to be more
	complicated in some way, then they can still write their own class,
	just like they could before.

	I've simplified the example code in the documentation to now use the
	new helper class, and I've also made use of this helper within the
	testsuite.

	Any existing user code will continue to work just as it did before
	after this change.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args
	Currently when creating a gdb.UnwindInfo object a user must call
	gdb.PendingFrame.create_unwind_info and pass a frame-id object.

	The frame-id object should have at least a 'sp' attribute, and
	probably a 'pc' attribute too (it can also, in some cases have a
	'special' attribute).

	Currently all of these frame-id attributes need to be gdb.Value
	objects, but the only reason for that requirement is that we have some
	code in py-unwind.c that only handles gdb.Value objects.

	If instead we switch to using get_addr_from_python in py-utils.c then
	we will support both gdb.Value objects and also raw numbers, which
	might make things simpler in some cases.

	So, I started rewriting pyuw_object_attribute_to_pointer (in
	py-unwind.c) to use get_addr_from_python.  However, while looking at
	the code I noticed a problem.

	The pyuw_object_attribute_to_pointer function returns a boolean flag,
	if everything goes OK we return true, but we return false in two
	cases, (1) when the attribute is not present, which might be
	acceptable, or might be an error, and (2) when we get an error trying
	to extract the attribute value, in which case a Python error will have
	been set.

	Now in pending_framepy_create_unwind_info we have this code:

	  if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
	    {
	      PyErr_SetString (PyExc_ValueError,
			       _("frame_id should have 'sp' attribute."));
	      return NULL;
	    }

	Notice how we always set an error.  This will override any error that
	is already set.

	So, if you create a frame-id object that has an 'sp' attribute, but
	the attribute is not a gdb.Value, then currently we fail to extract
	the attribute value (it's not a gdb.Value) and set this error in
	pyuw_object_attribute_to_pointer:

	  rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
	  if (!rc)
	    PyErr_Format (
	        PyExc_ValueError,
	        _("The value of the '%s' attribute is not a pointer."),
	        attr_name);

	Then we return to pending_framepy_create_unwind_info and immediately
	override this error with the error about 'sp' being missing.

	This all feels very confused.

	Here's my proposed solution: pyuw_object_attribute_to_pointer will now
	return a tri-state enum, with states OK, MISSING, or ERROR.  The
	meanings of these states are:

	  OK - Attribute exists and was extracted fine,

	  MISSING - Attribute doesn't exist, no Python error was set.

	  ERROR - Attribute does exist, but there was an error while
	     extracting it, a Python error was set.

	We need to update pending_framepy_create_unwind_info, the only user of
	pyuw_object_attribute_to_pointer, but now I think things are much
	clearer.  Errors from lower levels are not blindly overridden with the
	generic meaningless error message, but we still get the "missing 'sp'
	attribute" error when appropriate.

	This change also includes the switch to get_addr_from_python which was
	what started this whole journey.

	For well behaving user code there should be no visible changes after
	this commit.

	For user code that hits an error, hopefully the new errors should be
	more helpful in figuring out what's gone wrong.

	Additionally, users can now use integers for the 'sp' and 'pc'
	attributes in their frame-id objects if that is useful.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb: have value_as_address call unpack_pointer
	While refactoring some other code in gdb/python/* I wanted to merge
	two code paths.  One path calls value_as_address, while the other
	calls unpack_pointer.

	I suspect calling value_as_address is the correct choice, but, while
	examining the code I noticed that value_as_address calls unpack_long
	rather than unpack_pointer.

	Under the hood, unpack_pointer does just call unpack_long so there's
	no real difference here, but it feels like value_as_address should
	call unpack_pointer.

	I've updated the code to use unpack_pointer, and changed a related
	comment to say that we call unpack_pointer.  I've also adjusted the
	header comment on value_as_address.  The existing header refers to
	some code that is now commented out.

	Rather than trying to describe the whole algorithm of
	value_as_address, which is already well commented within the function,
	I've just trimmed the comment on value_as_address to be a brief
	summary of what the function does.

	There should be no user visible changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.UnwindInfo
	It is not currently possible to directly create gdb.UnwindInfo
	instances, they need to be created by calling
	gdb.PendingFrame.create_unwind_info so that the newly created
	UnwindInfo can be linked to the pending frame.

	As such there's no tp_init method defined for UnwindInfo.

	A consequence of all this is that it doesn't really make sense to
	allow sub-classing of gdb.UnwindInfo.  Any sub-class can't call the
	parents __init__ method to correctly link up the PendingFrame
	object (there is no parent __init__ method).  And any instances that
	sub-classes UnwindInfo but doesn't call the parent __init__ is going
	to be invalid for use in GDB.

	This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo
	class, which prevents the class being sub-classed.  Then I've added a
	test to check that this is indeed prevented.

	Any functional user code will not have any issues with this change.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add __repr__ for PendingFrame and UnwindInfo
	Having a useful __repr__ method can make debugging Python code that
	little bit easier.  This commit adds __repr__ for gdb.PendingFrame and
	gdb.UnwindInfo classes, along with some tests.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add some additional methods to gdb.PendingFrame
	The gdb.Frame class has far more methods than gdb.PendingFrame.  Given
	that a PendingFrame hasn't yet been claimed by an unwinder, there is a
	limit to which methods we can add to it, but many of the methods that
	the Frame class has, the PendingFrame class could also support.

	In this commit I've added those methods to PendingFrame that I believe
	are safe.

	In terms of implementation: if I was starting from scratch then I
	would implement many of these (or most of these) as attributes rather
	than methods.  However, given both Frame and PendingFrame are just
	different representation of a frame, I think there is value in keeping
	the interface for the two classes the same.  For this reason
	everything here is a method -- that's what the Frame class does.

	The new methods I've added are:

	  - gdb.PendingFrame.is_valid: Return True if the pending frame
	    object is valid.

	  - gdb.PendingFrame.name: Return the name for the frame's function,
	    or None.

	  - gdb.PendingFrame.pc: Return the $pc register value for this
	    frame.

	  - gdb.PendingFrame.language: Return a string containing the
	    language for this frame, or None.

	  - gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
	    for the current location within the pending frame, or None.

	  - gdb.PendingFrame.block: Return a gdb.Block for the current
	    pending frame, or None.

	  - gdb.PendingFrame.function: Return a gdb.Symbol for the current
	    pending frame, or None.

	In every case I've just copied the implementation over from gdb.Frame
	and cleaned the code slightly e.g. NULL to nullptr.  Additionally each
	function required a small update to reflect the PendingFrame type, but
	that's pretty minor.

	There are tests for all the new methods.

	For more extensive testing, I added the following code to the file
	gdb/python/lib/command/unwinders.py:

	  from gdb.unwinder import Unwinder

	  class TestUnwinder(Unwinder):
	      def __init__(self):
	          super().__init__("XXX_TestUnwinder_XXX")

	      def __call__(self,pending_frame):
	          lang = pending_frame.language()
	          try:
	              block = pending_frame.block()
	              assert isinstance(block, gdb.Block)
	          except RuntimeError as rte:
	              assert str(rte) == "Cannot locate block for frame."
	          function = pending_frame.function()
	          arch = pending_frame.architecture()
	          assert arch is None or isinstance(arch, gdb.Architecture)
	          name = pending_frame.name()
	          assert name is None or isinstance(name, str)
	          valid = pending_frame.is_valid()
	          pc = pending_frame.pc()
	          sal = pending_frame.find_sal()
	          assert sal is None or isinstance(sal, gdb.Symtab_and_line)
	          return None

	  gdb.unwinder.register_unwinder(None, TestUnwinder())

	This registers a global unwinder that calls each of the new
	PendingFrame methods and checks the result is of an acceptable type.
	The unwinder never claims any frames though, so shouldn't change how
	GDB actually behaves.

	I then ran the testsuite.  There was only a single regression, a test
	that uses 'disable unwinder' and expects a single unwinder to be
	disabled -- the extra unwinder is now disabled too, which changes the
	test output.  So I'm reasonably confident that the new methods are not
	going to crash GDB.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c
	This commit copies the pattern that is present in many other py-*.c
	files: having a single macro to check that the Python object is still
	valid.

	This cleans up the code a little throughout the py-unwind.c file.

	Some of the exception messages will change slightly with this commit,
	though the type of the exceptions is still ValueError in all cases.

	I started writing some tests for this change and immediately ran into
	a problem: GDB would crash.  It turns out that the PendingFrame
	objects are not being marked as invalid!

	In pyuw_sniffer where the pending frames are created, we make use of a
	scoped_restore to invalidate the pending frame objects.  However, this
	only restores the pending_frame_object::frame_info field to its
	previous value -- and it turns out we never actually give this field
	an initial value, it's left undefined.

	So, when the scoped_restore (called invalidate_frame) performs its
	cleanup, it actually restores the frame_info field to an undefined
	value.  If this undefined value is not nullptr then any future
	accesses to the PendingFrame object result in undefined behaviour and
	most likely, a crash.

	As part of this commit I now initialize the frame_info field, which
	ensures all the new tests now pass.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: remove unneeded nullptr check in frapy_block
	Spotted a redundant nullptr check in python/py-frame.c in the function
	frapy_block.  This was introduced in commit 57126e4a45e3000e when we
	expanded an earlier check in return early if the pointer in question
	is nullptr.

	There should be no user visible changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: make the gdb.unwinder.Unwinder class more robust
	This commit makes a few related changes to the gdb.unwinder.Unwinder
	class attributes:

	  1. The 'name' attribute is now a read-only attribute.  This prevents
	  user code from changing the name after registering the unwinder.  It
	  seems very unlikely that any user is actually trying to do this in
	  the wild, so I'm not very worried that this will upset anyone,

	  2. We now validate that the name is a string in the
	  Unwinder.__init__ method, and throw an error if this is not the
	  case.  Hopefully nobody was doing this in the wild.  This should
	  make it easier to ensure the 'info unwinder' command shows sane
	  output (how to display a non-string name for an unwinder?),

	  3. The 'enabled' attribute is now implemented with a getter and
	  setter.  In the setter we ensure that the new value is a boolean,
	  but the real important change is that we call
	  'gdb.invalidate_cached_frames()'.  This means that the backtrace
	  will be updated if a user manually disables an unwinder (rather than
	  calling the 'disable unwinder' command).  It is not unreasonable to
	  think that a user might register multiple unwinders (relating to
	  some project) and have one command that disables/enables all the
	  related unwinders.  This command might operate by poking the enabled
	  attribute of each unwinder object directly, after this commit, this
	  would now work correctly.

	There's tests for all the changes, and lots of documentation updates
	that both cover the new changes, but also further improve (I think)
	the general documentation for GDB's Unwinder API.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-30  Nick Clifton  <nickc@redhat.com>

	Fix an illegal memory access when an accessing a zer0-lengthverdef table.
	  PR 30285
	  * elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated.

2023-03-30  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Add version symbols to libgprofng.ver
	gprofng/ChangeLog
	2023-03-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30089
		* libcollector/libgprofng.ver: Add version symbols.
		* libcollector/synctrace.c: Fix typo for pthread_mutex_lock.

2023-03-30  Alan Modra  <amodra@gmail.com>

	Setting sh_link for SHT_REL/SHT_RELA
	It's wrong to have an alloc reloc section trying to use a non-alloc
	symbol table.

		* elf.c (assign_section_numbers <SHT_REL, SHT_RELA>): Correct
		comment.  Always set sh_link to .dynsym for alloc reloc
		sections and to .symtab for non-alloc.

2023-03-30  Alan Modra  <amodra@gmail.com>

	Fix memory leak in bfd_get_debug_link_info_1
		* opncls.c (bfd_get_alt_debug_link_info): Don't bother freeing
		after bfd_malloc_and_get_section failure.
		(get_build_id): Likewise.
		(bfd_get_debug_link_info_1): Likewise.  Free section contents
		when crc not present.
		* section.c (bfd_malloc_and_get_section): Document that the
		buffer is NULL on error return.

	Tidy leaked objcopy memory
		* objcopy.c (delete_symbol_htabs): Also free symbols.
		(write_debugging_info): Free strings and syms once written.
		* wrstabs.c (write_stabs_in_sections_debugging_info): memset
		entire info struct.  Free hash tables before returning.  Free
		syms on error return.

	Tidy memory on addr2line failures
		* addr2line.c (process_file): Close bfd on error paths.

2023-03-30  Roland McGrath  <mcgrathr@google.com>

	Fix typo in ld manual --enable-non-contiguous-regions example

2023-03-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-30  Palmer Dabbelt  <palmer@rivosinc.com>

	RISC-V: PR28789, Reject R_RISCV_PCREL relocations with ABS symbol in PIC/PIE.
	The non-preemptible SHN_ABS symbol with a pc-relative relocation should be
	disallowed when generating shared object (pic and pie).  Generally, the
	following cases, which refer to pr25749, will cause a symbol be
	non-preemptible,

	* -pie, or -shared with -symbolic
	* STV_HIDDEN, STV_INTERNAL, STV_PROTECTED
	* Have dynamic symbol table, but without the symbol
	* VER_NDX_LOCAL

	However, PCREL_HI20/LO12 relocs are always bind locally when generating
	shared object, so not only the non-preemptible absolute symbol need to
	be disallowed, all absolute symbol references need but except that they
	are defined in linker script.  If we also disallow the absolute symbol
	in linker script, then the glibc-linux toolchain build failed, so regard
	them as pc-relative symbols, just like what x86 did.

	Maybe we should add this check for all pc-relative relocations, rather
	than just handle in R_RISCV_PCREL relocs.  Ideally, since the value of
	SHN_ABS symbol is a constant, only S - A relocations should be allowed
	in the shared object, so only BFD_RELOC_8/16/32/64 are allowed, which
	means R_RISCV_32/R_RISCV_64.

	bfd/
	    PR 28789
	    * elfnn-riscv.c (riscv_elf_check_relocs): The absolute symbol cannot be
	    referneced with pc-relative relocation when generating shared object.
	ld/
	    PR 28789
	    * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
	    * ld/testsuite/ld-riscv-elf/pcrel-reloc*: New testcases.

2023-03-30  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Clarify link behaviors of R_RISCV_32/64 relocations with ABS symbol.
	There are two improvements, which are all referenced to aarch64,

	* R_RISCV_32 with non ABS symbol cannot be used under RV64 when making
	  shard objects.

	* Don't need dynamic relocation for R_RISCV_32/64 under RV32/RV64 when
	  making shared objects, if the referenced symbol is local ABS symbol.

	However, considering this link,
	https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/341

	Seems like we should makes all R_RISCV_32/64 relocs with ABS symbol
	that don't need any dynamic relocations when making the shared objects.
	But anyway, I just sync the current behavior as aarch64 ld, in case
	there are any unexpected behaviors happen.

	Passed the gcc/binutils regressions in riscv-gnu-toolchain.

	bfd/
	    * elfnn-riscv.c (riscv_elf_check_relocs): Only allow R_RISCV_32 with ABS
	    symbol under RV64.
	    (riscv_elf_relocate_section): R_RISCV_32/64 with local ABS symbol under
	    RV32/RV64 doesn't need any dynamic relocation when making shared objects.
	    I just make the implementations similar to other targets, so that will be
	    more easy to mainatain.
	ld/
	    * testsuite/ld-riscv-elf/data-reloc*: New testcases.
	    * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Added new data-reloc* testcases,
	    and need to make ifunc-seperate* testcases work for rv32.
	    * testsuite/ld-riscv-elf/ifunc-seperate-caller-nonplt.s: Likewise.
	    * testsuite/ld-riscv-elf/ifunc-seperate-caller-plt.s: Likewise.

2023-03-30  Nelson Chu  <nelson@rivosinc.com>

	RISC-V: Extract the ld code which are too complicated, and may be reused.
	These types of codes are different for each target, I am not sure what are the
	best for RISC-V, so extract them out may be more easy to compare what's the
	difference.

	bfd/
	    * elfnn-riscv.c (RISCV_NEED_DYNAMIC_RELOC): New defined.  Extracted
	    from riscv_elf_check_relocs, to see if dynamic reloc is needed for the
	    specific relocation.
	    (RISCV_GENERATE_DYNAMIC_RELOC): New defined.  Extracted from
	    riscv_elf_relocate_section, to see if R_RISCV_32/64 need to generate
	    dynamic relocation.
	    (RISCV_COPY_INPUT_RELOC): New defined.  Extracted from
	    riscv_elf_relocate_section, to see if R_RISCV_32/64 need to copy itslef
	    tp output file.
	    (RISCV_RESOLVED_LOCALLY): New defined.  Extracted from
	    riscv_elf_relocate_section, to see if R_RISCV_GOT_HI20 can be resolved
	    locally.

2023-03-29  Tom Tromey  <tromey@adacore.com>

	Use the correct frame when evaluating a dynamic property
	The test case in this patch shows an unusual situation: an Ada array
	has a dynamic bound, but the bound comes from a frame that's referred
	to by the static link.  This frame is correctly found when evaluating
	the array variable itself, but is lost when evaluating the array's
	bounds.

	This patch fixes the problem by passing this frame through to
	value_at_lazy in the DWARF expression evaluator.

2023-03-29  Tom Tromey  <tromey@adacore.com>

	Pass a frame to value_at_lazy and value_from_contents_and_address
	This patch adds a 'frame' parameter to value_at_lazy and ensures that
	it is passed down to the call to resolve_dynamic_type.  This required
	also adding a frame parameter to value_from_contents_and_address.

	Nothing passes this parameter to value_at_lazy yet, so this patch
	should have no visible effect.

2023-03-29  Tom Tromey  <tromey@adacore.com>

	Add frame parameter to resolve_dynamic_type
	This adds a frame parameter to resolve_dynamic_type and arranges for
	it to be passed through the call tree and, in particular, to all calls
	to dwarf2_evaluate_property.

	Nothing passes this parameter yet, so this patch should have no
	visible effect.

	A 'const frame_info_ptr *' is used here to avoid including frame.h
	from gdbtypes.h.

2023-03-29  Tom Tromey  <tromey@adacore.com>

	Remove version_at_least
	version_at_least is a less capable variant of version_compare, so this
	patch removes it.

	Rewrite version_compare and rust_at_least
	This rewrites version_compare to allow the input lists to have
	different lengths, then rewrites rust_at_least to use version_compare.

	Introduce rust_at_least helper proc
	This adds a 'rust_at_least' helper proc, for checking the version of
	the Rust compiler in use.  It then changes various tests to use this
	with 'require'.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require gnatmake 11 for gdb.ada/verylong.exp
	With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
	...
	compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
	prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
	prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
	gnatmake: "prog.adb" compilation error

	FAIL: gdb.ada/verylong.exp: compilation prog.adb
	...

	AFAICT, support for Long_Long_Long_Integer was added in gcc 11.

	Fix this by requiring gnatmake version 11 or higher in the test-case.

	Tested on x86_64-linux.

2023-03-29  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	doc: fix informations typo in gdb.texinfo
	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-03-29  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	gdb, infcmd: remove redundant ERROR_NO_INFERIOR in continue_command
	The ERROR_NO_INFERIOR macro is already called at the beginning of the
	function continue_command.  Since target/inferior are not switched in-between,
	the second call to it is redundant.

	Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

2023-03-29  Andrew Burgess  <aburgess@redhat.com>

	gdb: move displaced_step_dump_bytes into gdbsupport (and rename)
	It was pointed out during review of another patch that the function
	displaced_step_dump_bytes really isn't specific to displaced stepping,
	and should really get a more generic name and move into gdbsupport/.

	This commit does just that.  The function is renamed to
	bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}.  The
	function implementation doesn't really change. Much...

	... I have updated the function to take an array view, which makes it
	slightly easier to call in a couple of places where we already have a
	gdb::bytes_vector.  I've then added an inline wrapper to convert a raw
	pointer and length into an array view, which is used in places where
	we don't easily have a gdb::bytes_vector (or similar).

	Updated all users of displaced_step_dump_bytes.

	There should be no user visible changes after this commit.

	Finally, I ended up having to add an include of gdb_assert.h into
	array-view.h.  When I include array-view.h into common-utils.h I ran
	into build problems because array-view.h calls gdb_assert.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-29  Andrew Burgess  <aburgess@redhat.com>

	gdb: more debug output for displaced stepping
	While investigating a displaced stepping issue I wanted an easy way to
	see what GDB thought the original instruction was, and what
	instruction GDB replaced that with when performing the displaced step.

	We do print out the address that is being stepped, so I can track down
	the original instruction, I just need to go find the information
	myself.

	And we do print out the bytes of the new instruction, so I can figure
	out what the replacement instruction was, but it's not really easy.

	Also, the code that prints the bytes of the replacement instruction
	only prints 4 bytes, which clearly isn't always going to be correct.

	In this commit I remove the existing code that prints the bytes of the
	replacement instruction, and add two new blocks of code to
	displaced_step_prepare_throw.  This new code prints the original
	instruction, and the replacement instruction.  In each case we print
	both the bytes that make up the instruction and the completely
	disassembled instruction.

	Here's an example of what the output looks like on x86-64 (this is
	with 'set debug displaced on').  The two interesting lines contain the
	strings 'original insn' and 'replacement insn':

	  (gdb) step
	  [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
	  [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00	jmp    *0x2fe2(%rip)        # 0x404018 <puts@got.plt>
	  [displaced] prepare: selected buffer at 0x401052
	  [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
	  [displaced] fixup_riprel: %rip-relative addressing used.
	  [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
	  [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
	  [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
	  [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00	jmp    *0x2fe2(%rcx)
	  [displaced] finish: restored 2892655.2892655.0 0x401052
	  [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
	  [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
	  0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
	  (gdb)

	One final note.  For many targets that support displaced stepping (in
	fact all targets except ARM) the replacement instruction is always a
	single instruction.  But on ARM the replacement could actually be a
	series of instructions.

	The debug code tries to handle this by disassembling the entire
	displaced stepping buffer.  Obviously this might actually print more
	than is necessary, but there's (currently) no easy way to know how
	many instructions to disassemble; that knowledge is all locked in the
	architecture specific code.  Still I don't think it really hurts, if
	someone is looking at this debug then hopefully they known what to
	expect.

	Obviously we can imagine schemes where the architecture specific
	displaced stepping code could communicate back how many bytes its
	replacement sequence was, and then our debug print code could use this
	to limit the disassembly.  But this seems like a lot of effort just to
	save printing a few additional instructions in some debug output.

	I'm not proposing to do anything about this issue for now.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.guile/scm-symbol.exp for remote host
	Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less
	strict.

	Likewise in gdb.guile/scm-symtab.exp.

	Tested on x86_64-linux.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix /gdb.guile/scm-parameter.exp for remote host
	Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
	account that gdb_reinitialize_dir has no effect for remote host.

	Tested on x86_64-linux.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host
	Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download.

	Tested on x86_64-linux.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host
	Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file.

	Tested on x86_64-linux.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.guile/scm-cmd.exp without readline
	Fix test-case gdb.guile/scm-cmd.exp using readline_is_used.

	Tested on x86_64-linux.

2023-03-29  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.guile/guile.exp for remote host
	Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download.

	Tested on x86_64-linux.

2023-03-29  Alan Modra  <amodra@gmail.com>

	Sanity check section size in bfd_init_section_compress_status
	This function doesn't just initialise for compression, it actually
	compresses.  This patch sanity checks section size before allocating
	buffers for the uncompressed contents.

		* compress.c (bfd_init_section_compress_status): Sanity check
		section size.

2023-03-29  Alan Modra  <amodra@gmail.com>

	Re: Fix an aout memory leak
	We have way too much duplicated code in bfd.  Apply dd3a3d0af9f6 and
	920581c57e08 to pdp11.c.

		* pdp11.c (bfd_free_cached_info): Free line_buf.  Return true
		if tdata.aout_data is NULL.

2023-03-29  Alan Modra  <amodra@gmail.com>

	ld testsuite CFLAGS_FOR_TARGET
	run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it
	detects the program being run is a compiler.  Since the program being
	run in lto.exp linking pr28138 is "sh", we need to add these by hand.
	This isn't exactly as run_host_cmd does, as it lacks reordering of
	any user -B option in $CC_FOR_TARGET, but it's better than ignoring
	gcc_B_opt.  This fixes a mips64 testsuite fail.

	ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there
	is no need for the ld_compile command line to include
	CFLAGS_FOR_TARGET.  Fixing this is just a tidy.

		* testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET
		and $ld_L_opt to pr28138 link line.
		* testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass
		unnecessary flags to ld_compile.
		(run_ld_link_exec_tests, run_cc_link_tests): Likewise.

2023-03-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-28  Tom Tromey  <tom@tromey.com>

	Rename "raw" to "unrelocated"
	Per an earlier discussion, this patch renames the existing "raw" APIs
	to use the word "unrelocated" instead.

	Use unrelocated_addr in minimal symbols
	This changes minimal symbols to use unrelocated_addr.  I believe this
	detected a latent bug in add_pe_forwarded_sym.

	Use unrelocated_addr in psymbols
	This changes psymbols themselves to use unrelocated_addr.  This
	transform is largely mechanical.  I don't think it finds any bugs.

	Use unrelocated_addr in partial symbol tables
	This changes partial symbol tables to use unrelocated_addr for the
	text_high and text_low members.  This revealed some latent bugs in
	ctfread.c, which are fixed here.

	Move definition of unrelocated_addr earlier
	This moves the definition of unrelocated_addr a bit earlier in
	symtab.h, so that it can be used elsewhere in the file.

	Use function_view in gdb_bfd_lookup_symbol
	This changes gdb_bfd_lookup_symbol to use a function_view.  This
	simplifies the code a little bit.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.btrace/multi-inferior.exp for remote host
	Fix test-case gdb.btrace/multi-inferior.exp for remote host using
	gdb_remote_download.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.btrace/gcore.exp for remote host
	Fix test-case gdb.btrace/gcore.exp for remote host using
	host_standard_output.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.btrace/reconnect.exp for remote target
	Fix test-case gdb.btrace/reconnect.exp for target board
	remote-gdbserver-on-localhost using gdb_remote_download.

	Tested on x86_64-linux.

2023-03-28  Tom Tromey  <tromey@adacore.com>

	Put pretty-printers to_string output in varobj result
	PR mi/11335 points out that an MI varobj will not display the result
	of a pretty-printer's "to_string" method.  Instead, it always shows
	"{...}".

	This does not seem very useful, and there have been multiple
	complaints about it over the years.  This patch changes varobj to emit
	this string when possible, and updates the test suite.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335

2023-03-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: allow "require" callbacks to provide a reason
	When an allow_* proc returns false, it can be a bit difficult what check
	failed exactly, if the procedure does multiple checks.  To make
	investigation easier, I propose to allow the "require" callbacks to be
	able to return a list of two elements: the zero/non-zero value, and a
	reason string.

	Use the new feature in allow_hipcc_tests to demonstrate it (it's also
	where I hit actually hit this inconvenience).  On my computer (where GDB
	is built with amd-dbgapi support but where I don't have a suitable GPU
	target), I get:

	    UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)

	vs before:

	    UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests

	Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
	Approved-By: Tom de Vries <tdevries@suse.de>

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/server-kill-python.exp for remote host
	Fix test-case gdb.server/server-kill-python.exp for remote host using
	gdb_remote_download.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/sysroot.exp for remote host
	Fix test-case gdb.server/sysroot.exp for remote host, by:
	- using gdb_remote_download, and
	- disabling the "local" scenario for remote host/target, unless
	  remote host == remote target.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require non-remote host for gdb.server/multi-ui-errors.exp
	Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
	it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
	remote host.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/solib-list.exp for remote host
	Fix test-case gdb.server/solib-list.exp for remote host using
	gdb_remote_download.

	Likewise in another test-case.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/file-transfer.exp for remote host
	Fix test-case gdb.server/file-transfer.exp for remote host using
	gdb_remote_download and host_standard_output_file.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix local-remote-host-native.exp for gdb.server tests
	When running test-case gdb.server/stop-reply-no-thread-multi.exp with
	host+target board local-remote-host-native, I run into a time-out:
	...
	(gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
	  to_disable=: disconnect
	builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \
	  localhost:2346 stop-reply-no-thread-multi^M
	Process stop-reply-no-thread-multi created; pid = 32600^M
	Listening on port 2346^M
	set remote threads-packet off^M
	FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
	  to_disable=: set remote threads-packet off (timeout)
	...

	This is due to this line in ${board}_spawn:
	...
	    set board_info($board,fileid) $spawn_id
	...

	We have the following series of events:
	- gdb is spawned, setting fileid
	- a few gdb commands (set height etc) are send using fileid, arrive at gdb and
	  are successful
	- gdbserver is spawned, overwriting fileid
	- the next gdb command is sent using fileid, so it's send
	  to gdbserver instead of gdb, and we run into the timeout.

	There is some notion of current gdb, tracked in both gdb_spawn_id and fileid
	of the host board (see switch_gdb_spawn_id).  And because the host and target
	board are the same, spawning something on the target overwrites the fileid on
	host, and consequently the current gdb.

	Fix this by only setting fileid when spawning gdb.

	Tested on x86_64-linux.

	Now gdb.server/*.exp passes for host+target board local-remote-host-native,
	except for file-transfer.exp.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734

2023-03-28  Enze Li  <enze.li@hotmail.com>

	gdb: use dynamic year in update-freebsd.sh
	When running update-freebsd.sh on FreeBSD, I see the following
	modification in freebsd.xml,

	-<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc.
	+<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc.

	It means that each time, when we running the update-freebsd.sh on
	FreeBSD, we have to correct the year of copyright manually. So fix this
	issue by using dynamic year.

	Tested by regenerating freebsd.xml on FreeBSD/amd64.

	Reviewed-By: John Baldwin <jhb@FreeBSD.org>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/non-existing-program.exp with remote-gdbserver-on-localhost
	With test-case gdb.server/non-existing-program.exp and native, I have reliably:
	...
	(gdb) builtin_spawn gdbserver stdio non-existing-program^M
	stdin/stdout redirected^M
	/bin/bash: line 0: exec: non-existing-program: not found^M
	During startup program exited with code 127.^M
	Exiting^M
	PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
	...

	But with target board remote-gdbserver-on-localhost I sometimes have:
	...
	(gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
	  stdio non-existing-program^M
	stdin/stdout redirected^M
	/bin/bash: line 0: exec: non-existing-program: not found^M
	During startup program exited with code 127.^M
	Exiting^M
	Connection to localhost closed.^M^M
	PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
	...
	and sometimes the exact same output, but a FAIL instead.

	Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.

	Tested on x86_64-linux.

2023-03-28  Alan Modra  <amodra@gmail.com>

	Avoid undefined behaviour in m68hc11 md_begin
	Given p = A where p is a pointer to some type and A is an array of
	that type, then the expression p - 1 + 1 evokes undefined behaviour
	according to the C standard.

	gcc-13 -fsanitize=address,undefined complains about this, but not
	where the undefined behaviour actually occurs at tc-m68hc11.c:646.
	Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store
	to address 0x62600000016c with insufficient space for an object of
	type 'int'".  Which is a lie.  There most definitely is space there.
	Oh well, diagnostics are sometimes hard to get right.  The UB is easy
	to avoid.

		PR 30279
		* config/tc-m68hc11.c (md_begin): Avoid undefined pointer
		decrement.  Remove unnecessary cast.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow gdb.rust/expr.exp without rust compiler
	Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
	the wrong answer for gdb.rust/expr.exp, which doesn't require it.

	Fix this by using can_compile rust in the test-cases that need it, and just
	returning 1 in allow_rust_tests.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add can_compile rust
	If I deinstall the rust compiler, I get:
	...
	gdb compile failed, default_target_compile: Can't find rustc --color never.
	UNTESTED: gdb.rust/watch.exp: failed to prepare
	...

	Fix this by adding can_compile rust, and using it in allow_rust_tests, such
	that we have instead:
	...
	UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
	...

	Since the rest of the code in allow_rust_tests is also about availability of
	the rust compiler, move it to can_compile.

	Tested on x86_64-linux.

2023-03-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Unsupport gdb.rust for remote host
	With test-case gdb.rust/watch.exp and remote host I run into:
	...
	Executing on host: gcc   watch.rs  -g  -lm   -o watch    (timeout = 300)
	  ...
	ld:watch.rs: file format not recognized; treating as linker script
	ld:watch.rs:1: syntax error
	  ...
	UNTESTED: gdb.rust/watch.exp: failed to prepare
	...

	The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.

	Fix this by returning 0 in allow_rust_tests for remote host.

	Tested on x86_64-linux.

2023-03-28  Alan Modra  <amodra@gmail.com>

	ubsan: elfnn-aarch64.c:4595:19: runtime error: load of value 190
	which is not a valid value for type '_Bool'

		* elfnn-aarch64.c (stub_hash_newfunc): Clear all fields past root.

2023-03-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gnat_runtime_has_debug_info for remote host
	Fix gnat_runtime_has_debug_info for remote host by checking for
	allow_ada_tests.

	This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
	remote host.

	Tested on x86_64-linux.

2023-03-27  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Use correct constant for target_waitstatus::sig.
	Use GDB_SIGNAL_TRAP instead of SIGTRAP.  This is a no-op since the
	value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but
	it is more correct.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-27  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Avoid a direct write to target_waitstatus::kind.
	This is in #ifdef'd code for a workaround for FreeBSD versions older
	than 11.1 which is why it wasn't caught earlier.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-27  John Baldwin  <jhb@FreeBSD.org>

	fbsd-nat: Add missing spaces.
	No functional change, just style fixes.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: 30089 [display text] Invalid number of threads
	The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34
	We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
	Some of these functions have versions. For example, dlopen@GLIBC_2.34,
	dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc.
	We have to interpose each of the functions because we don't know
	which version of libC will be used during profiling.
	Historically, we have used three versions of scripts (mapfile.aarch64-Linux,
	mapfile.amd64-Linux, mapfile.intel-Linux).
	Three are not needed. One is enough

	The fixes below include:
	 - merged all version symbols into one version script.
	 - added new version symbols which are defined in latest versions of libC.
	 - removed unused defines and duplicated code.
	 - added the DCL_FUNC_VER macro to define the version symbols.

	Tested on x86_64 and aarch64 (OL8/OL9). No regression.

	gprofng/ChangeLog
	2023-03-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30089
		* libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.*
		* libcollector/configure.ac: Delete GPROFNG_VARIANT.
		* src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h
		* libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER).
		Remove unused defines.
		* libcollector/dispatcher.c: Interpose functions from libC.
		Clean up the old code.
		* libcollector/iotrace.c: Likewise.
		* libcollector/libcol_util.c: Likewise.
		* libcollector/linetrace.c: Likewise.
		* libcollector/mmaptrace.c: Likewise.
		* libcollector/synctrace.c: Likewise.
		* libcollector/libgprofng.ver: New file.
		* libcollector/Makefile.in: Rebuild.
		* libcollector/configure: Rebuild.
		* libcollector/mapfile.aarch64-Linux: Removed.
		* libcollector/mapfile.amd64-Linux: Removed.
		* libcollector/mapfile.intel-Linux: Removed.
		* libcollector/mapfile.sparc-Linux: Removed.
		* libcollector/mapfile.sparcv9-Linux: Removed.

2023-03-27  Pedro Alves  <pedro@palves.net>

	linux-nat: introduce pending_status_str
	I noticed that some debug log output printing an lwp's pending status
	wasn't considering lp->waitstatus.  This fixes it, by introducing a
	new pending_status_str function.

	Also fix the comment in gdb/linux-nat.h describing
	lwp_info::waitstatus and details the description of lwp_info::status
	while at it.

	Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-03-27  Pedro Alves  <pedro@palves.net>

	displaced step: pass down target_waitstatus instead of gdb_signal
	This commit tweaks displaced_step_finish & friends to pass down a
	target_waitstatus instead of a gdb_signal.  This is needed because a
	patch later in the step-over-{thread-exit,clone] series will want to
	make displaced_step_buffers::finish handle
	TARGET_WAITKIND_THREAD_EXITED.  It also helps with the
	TARGET_WAITKIND_THREAD_CLONED patch later in that same series.

	It's also a bit more logical this way, as we don't have to pass down
	signals when the thread didn't actually stop for a signal.  So we can
	also think of it as a clean up.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
	Change-Id: I4c5d338647b028071bc498c4e47063795a2db4c0
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.stabs/exclfwd.exp for remote host
	Fix test-case gdb.stabs/exclfwd.exp for remote host using include_file.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.stabs/weird.exp for remote host
	Fix test-case gdb.stabs/weird.exp for remote host by not using an absolute
	destfile argument to gdb_remote_download, which doesn't work well with remotedir.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.gdb/unittest.exp for remote host
	Fix test-case gdb.gdb/unittest.exp for remote host, by:
	- disabling the completion tests if readline is not used, and
	- not using with_gdb_cwd $dir for remote host (because it does
	  not support changing to ".").

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Skip do_self_tests on remote host
	In do_self_tests we try to find out the location of the gdb to debug, which
	will then be copied and renamed to xgdb.

	In principle, the host board specifies the location of GDB, on host.

	With remote host, we could upload that gdb from host to build/target, but we
	would miss the data directory (which is listed as the reason to skip
	do_self_tests for remote target).

	We could fix that by instead taking the gdb from build instead, but that
	wouldn't work with installed testing.

	It seems easier to just skip this on remote host.

	It could be made to work for the "[is_remote host] && [is_remote target]
	&& host == target" scenario (see board local-remote-host-native.exp), but
	that doesn't seem worth the effort.

	Tested on x86_64-linux.

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Change symbol::line to unsigned int
	A user here at AdaCore noticed that, when debugging a certain program,
	a stack frame reported line 34358, where it should have been line
	99894.

	After debugging a bit, I discovered:

	(top) p (99894 & ~65536)
	$60 = 34358

	That line, symbol::line is too narrow.

	This patch widens the member and changes all the uses that currently
	use the narrower type.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Fix 128-bit integer bug in Ada
	While working on 128-bit integer support, I found one spot in Ada that
	needed a fix as well.

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Use gdb_gmp for scalar arithmetic
	This changes gdb to use scalar arithmetic for expression evaluation.

	I suspect this patch is not truly complete, as there may be code paths
	that still don't correctly handle 128-bit integers.  However, many
	things do work now.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30190

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Use value_true in value_equal and value_less
	Both value_equal and value_less use value_as_long to check a
	presumably boolean result of calling value_binop.  However,
	value_binop in this case actually returns an int as wide as its
	arguments, and this approach can then fail for integers wider than
	LONGEST.  Instead, rewrite this in a form that works for any size
	integer.

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Simplify binop_promote
	binop_promote currently only handles integer sizes up to
	builtin_long_long.  However, this may not handle 128-bit types.
	Simplify this code, unify the C and non-C (but not OpenCL, as I don't
	know how to test this) cases, and handle 128-bit integers as well.

	This still doesn't exactly follow C or C++ rules.  This could be
	implemented, but if so, I think it makes more sense as a C-specific
	expression node.

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Add value_as_mpz and value_from_mpz
	This adds the two new functions, value_as_mpz and value_from_mpz,
	useful for manipulation values via gdb_mpz.

	Add truncation mode to gdb_mpz
	This renames gdb_mpz::safe_export to export_bits, and adds a new flag
	to export a truncated value.  This is needed by value arithmetic.

	Avoid a copy in gdb_mpz::safe_export
	Currently, gdb_mpz::safe_export will always make a copy of *this.
	However, this copy isn't always needed.  This patch makes this code
	slightly more efficient, by avoiding the copy when possible.

	Add many operators to gdb_mpz
	This adds many operator overloads and other useful methods to gdb_mpz.
	This is preparation for using this class for scalar arithmetic in gdb
	expression evaluation.

2023-03-27  Tom Tromey  <tromey@adacore.com>

	Populate seen_names hash in cooked_index_shard::do_finalize
	Hannes pointed out that cooked_index_shard::do_finalize never
	populates the seen_names hash table.  This patch adds the necessary
	store.  This reduces memory use a little for "gdb gdb":

	(before) Space used: 28909568 (+0 for this command)
	(after)  Space used: 28884992 (+0 for this command)

	What this means, btw, is that in gdb there are not many symbols that
	are both mentioned in many CUs and that also require name
	canonicalization.  It's possible this would differ in other programs.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.asm/asm-source.exp for remote host
	Fix test-case gdb.asm/asm-source.exp for remote host using
	host_standard_output_file and gdb_remote_download.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/imported-unit-bp-c.exp for remote host
	Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a
	downloaded source file.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Unsupport gdb.dwarf2/gdb-add-index-symlink.exp for remote host
	Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote
	host, because the current implementation of gdb_ensure_index doesn't support it.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote host
	Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using
	host_standard_output_file.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp for remote host
	Fix test-case gdb.dwarf2/enqueued-cu-base-addr.exp for remote host by using
	$testfile instead $binfile.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote host
	Fix test-case gdb.dwarf2/gdb-index.exp on remote host using
	gdb_remote_download and host_standard_output_file.

	Also declare the test-case unsupported with readnow.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp for remote host
	Fix test-case gdb.dwarf2/per-bfd-sharing.exp for remote host using
	gdb_remote_download.

	Likewise in a few other test-cases.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix quoting issue in gdb.base/index-cache.exp
	For test-case gdb.base/index-cache.exp and remote host, this:
	...
	lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret
	...
	gives us:
	...
	Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index    (timeout = 300)
	builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M
	rm: missing operand^M
	Try 'rm --help' for more information.^M
	FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir
	...

	Fix this using quote_for_host.  Likewise in gdb.dwarf2/per-bfd-sharing.exp.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix quoting issues in gdb.dwarf2 for remote host
	A few test-cases in gdb.dwarf2 use something like:
	...
	  additional_flags=\"-DFOO=BAR + 10\"
	...
	which doesn't work on remote host.

	Fix this by introducing a new proc quote_for_host that also works for remote
	host, such that we have:
	...
	  additional_flags=[quote_for_host -DFOO=BAR + 10]
	...

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix have_index for remote host
	Proc have_index is mostly used with $binfile, which gives problems
	for remote host.

	Fix this by using "file tail" on the proc argument.

	Tested on x86_64-linux.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing include_file in gdb.dwarf/*.exp

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add test-case gdb.dlang/dlang-start-2.exp
	For test-case gdb.dlang/dlang-start.exp, I run into:
	...
	UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
	...

	My distro has no support for gdc, but I'd like to have the test-case
	running and passing, so let's rewrite the test-case using dwarf assembly
	and add it alongside (rather than replacing it, because it's good to use
	actual compiler output if we have it available).

	My distro does have a package providing dmd, so let's mimic that debug info in
	the dwarf assembly.  This gives us:
	...
	(gdb) start ^M
	Temporary breakpoint 1 at 0x4004ab^M
	Starting program: dlang-start-2 ^M
	^M
	Temporary breakpoint 1, 0x00000000004004ab in _Dmain ()^M
	...

	The "_Dmain ()" should probably be "D main", I've filed PR30276 about that.

	Also add a "show language" to check that we automatically set the language
	correctly to D.

	Note that the dwarf assembly also describes main, otherwise the test-case
	doesn't function as regression test for commit 47fe57c9281 ("Fix "start" for
	D, Rust, etc").

	Tested on x86_64-linux.

2023-03-27  Alan Modra  <amodra@gmail.com>

	Tidy tc-ppc.c XCOFF auxent access
	It's better not to drill down into u.auxent but instead use a pointer
	to the combined_entry_type.  That way the fix_scnlen field is
	available, and no one looking at the codes needs to wonder whether
	coffsymbol (symbol_get_bfdsym (sym))->native[i + 1] is the same
	auxent.

		* config/tc-ppc.c (ppc_frob_symbol): Tidy XCOFF auxent access.
		(ppc_adjust_symtab): Likewise.

2023-03-27  Alan Modra  <amodra@gmail.com>

	Remove coff_pointerize_aux table_end param
	I'm fairly certain the table_end checks are redundant now.  This
	patch reverts commit 334d4ced42d3.

		* coffgen.c (coff_pointerize_aux): Remove table_end parameter.
		(coff_get_normalized_symtab): Adjust to suit.

2023-03-27  Alan Modra  <amodra@gmail.com>

	Use stdint types in coff internal_auxent
	long is a poor choice of type to store 32-bit values read from
	objects files by H_GET_32.  H_GET_32 doesn't sign extend so tests like
	that in gdb/coffread.c for "negative" values won't work if long is
	larger than 32 bits.  If long is 32-bit then code needs to be careful
	to not accidentally index negative array elements.  (I'd rather see a
	segfault on an unmapped 4G array index than silently reading bogus
	data.)  long is also a poor choice for x_sect.s_scnlen, which might
	have 64-bit values.  It's better to use unsigned exact width types to
	avoid surprises.

	I decided to change the field names too, which makes most of this
	patch simply renaming.  Besides that there are a few places where
	casts are no longer needed, and where printf format strings or tests
	need adjusting.

	include/
		* coff/internal.h (union internal_auxent): Use unsigned stdint
		types.  Rename l fields to u32 and u64 as appropriate.
	bfd/
		* coff-bfd.c,
		* coff-rs6000.c,
		* coff64-rs6000.c,
		* coffcode.h,
		* coffgen.c,
		* cofflink.c,
		* coffswap.h,
		* peXXigen.c,
		* xcofflink.c: Adjust to suit internal_auxent changes.
	binutils/
		* rdcoff.c: Adjust to suit internal_auxent changes.
	gas/
		* config/obj-coff.h,
		* config/tc-ppc.c: Adjust to suit internal_auxent changes.
	gdb/
		* coffread.c,
		* xcoffread.c: Adjust to suit internal_auxent changes.
	ld/
		* pe-dll.c: Adjust to suit internal_auxent changes.

2023-03-27  Alan Modra  <amodra@gmail.com>

	Set proper union selector tag
		* coff-bfd.c (bfd_coff_get_auxent): After converting sym pointer
		to an index, reset the union tag.

2023-03-27  Alan Modra  <amodra@gmail.com>

	coffgrok access of u.auxent.x_sym.x_tagndx.p
	u.auxent.x_sym.x_tagndx is a union.  The p field is only valid when
	fix_tag is set.  This patch fixes code in coffgrok.c that accessed the
	field without first checking fix_tag, and removes a whole lot of code
	validating bogus pointers to prevent segfaults (which no longer
	happen, I checked the referenced PR 17512 testcases).  The patch also
	documents this in the fix_tag comment, makes is_sym a bitfield, and
	sorts the selecter fields a little.

	bfd/
		* coffcode.h (combined_entry_type): Make is_sym a bitfield.
		Sort and comment on union selectors.
		* libcoff.h: Regenerate.
	binutils/
		* coffgrok.c (do_type): Make aux a combined_entry_type.  Test
		fix_tag before accessing u.auxent.x_sym.x_tagndx.p.  Remove
		now unnecessary pointer bounds checking.

2023-03-27  Alan Modra  <amodra@gmail.com>

	Duplicate DW_AT_call_file leak
	When given two or more DW_AT_call_file for a given function we
	currently leak the concat memory.

		* dwarf2.c (scan_unit_for_symbols): Don't leak on duplicate
		DW_AT_call_file.

2023-03-27  Alan Modra  <amodra@gmail.com>

	XCOFF sanity check
		* coffcode.h (coff_pointerize_aux_hook): Sanity check
		x_csect.x_scnlen against raw_syment_count.

2023-03-27  Nick Clifton  <nickc@redhat.com>

	Add an option to the gold linker to put its version string into the .comment section.
	  PR 30187
	  * options.h (class General_options): Add enable-linker-version.
	  * layout.cc (Layout::create_gold_note): If linker-version is enabled put the version string into the .comment section.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle missing gdc in gdb.dlang/dlang-start.exp
	On openSUSE Leap 15.4, I get:
	...
	Running gdb.dlang/dlang-start.exp ...
	gdb compile failed, default_target_compile: Can't find gdc.
	UNTESTED: gdb.dlang/dlang-start.exp: failed to prepare
	...

	Fix this by:
	- introducing a new proc can_compile, and
	- requiring "can_compile d" in the test-case,
	such that I have instead:
	...
	Running gdb.dlang/dlang-start.exp ...
	UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
	...

	Tested on x86_64-linux, on openSUSE Leap 15.4 and Fedora 37.

2023-03-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove superfluous pid in temp files
	While trying to use gdb_can_simple_compile with a d program, I ran into:
	...
	/data/vries/gdb/f37/build/gdb/testsuite/temp/105856/can_compile_d-105856.d: \
	  error: module 'can_compile_d-105856' has non-identifier characters in \
	  filename, use module declaration instead
	...

	The d compiler has a problem with the filename can_compile_d-105856.d, which
	contains the pid.  The pid is added by gdb_simple_compile:
	...
	    set obj [standard_temp_file $name-[pid].$postfix]
	...
	but it's unnecessary because standard_temp_file already uses the pid.

	Fix this by removing "[pid]" in all calls to standard_temp_file.

	Tested on x86_64-linux.

2023-03-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Introduce allow_dap_tests
	Simon pointed out that with gdb.dap/*.exp and target board
	native-gdbserver, we run into problems.

	I see for each test-case:
	...
	+++ run
	Traceback (most recent call last):
	  File "startup.py", line 146, in exec_and_log
	    output = gdb.execute(cmd, from_tty=True, to_string=True)
	gdb.error: Don't know how to run.  Try "help target".
	...

	Likewise with target board native-extended-gdbserver.

	Fix this by:
	- adding a new proc allow_dap_tests,
	- using it in all the gdb.dap tests, and
	- bailing out if GDBFLAGS/INTERNAL_GDBFLAGS contains
	  "set auto-connect-native-target off".

	Tested on x86_64-linux.

	Reported-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-03-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-24  Tom Tromey  <tromey@adacore.com>

	Preserve name of range types
	The type-allocation patches introduced a small regression that was
	picked up by the AdaCore internal test suite.  Previously, the name of
	a range type was preserved by resolve_dynamic_range, but now it is
	not.  This patch changes this code to preserve the name.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-03-24  Tom Tromey  <tromey@adacore.com>

	Implement repl evaluation for DAP
	The evaluate command supports a "context" parameter which tells the
	adapter the context in which an evaluation occurs.  One of the
	supported values is "repl", which we took to mean evaluation of a gdb
	command.  That is what this patch implements.

	Note that some gdb commands probably will not work correctly with the
	rest of the protocol.  For example if the user types "continue",
	confusion may result.

	This patch requires the earlier patch to fix up scopes in DAP.

2023-03-24  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Fix line number of static const class member
	Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there
	was a silent regression on openSUSE Leap 15.4 for test-case
	gdb.cp/m-static.exp, from:
	...
	(gdb) info variable everywhere^M
	All variables matching regular expression "everywhere":^M
	^M
	File /home/vries/tmp.local-remote-host-native/m-static.h:^M
	8:      const int gnu_obj_4::everywhere;^M
	(gdb)
	...
	to:
	...
	(gdb) info variable everywhere^M
	All variables matching regular expression "everywhere":^M
	^M
	File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
	8:      const int gnu_obj_4::everywhere;^M
	^M
	File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
	8:      const int gnu_obj_4::everywhere;^M
	(gdb)
	...

	Another regression was found due to that commit, and it was fixed in commit
	99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by
	limiting the scope of the fix in the original commit.

	Fix this regression by yet further limiting the scope of that fix, making sure
	that this bit in dwarf_decode_lines is executed again for m-static1.cc:
	...
	  /* Make sure a symtab is created for every file, even files
	     which contain only variables (i.e. no code with associated
	     line numbers).  */
	...

	Tested on x86_64-linux.

	PR symtab/30265
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265

2023-03-24  Nick Alcock  <nick.alcock@oracle.com>

	libctf: get the offsets of fields of unnamed structs/unions right
	We were failing to add the offsets of the containing struct/union
	in this case, leading to all offsets being relative to the unnamed
	struct/union itself.

	libctf/
		PR libctf/30264
		* ctf-types.c (ctf_member_info): Add the offset of the unnamed
		member of the current struct as necessary.
		* testsuite/libctf-lookup/unnamed-field-info*: New test.

2023-03-24  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix a comment typo
	ctf_dedup's intern() function does not return a dynamically allocated
	string, so I just spent ten minutes auditing for obvious memory leaks
	that couldn't actually happen.  Update the comment to note what it
	actually returns (a pointer into an atoms table: i.e. possibly not
	a new string, and not so easily leakable).

	libctf/
		* ctf-dedup.c (intern): Update comment.

2023-03-24  Nick Alcock  <nick.alcock@oracle.com>

	libctf: work around an uninitialized variable warning
	GCC 11+ complains that sym is uninitialized in ctf_symbol_next.  It
	isn't, but it's not quite smart enough to figure that out (it requires
	domain-specific knowledge of the state of the ctf_next_t iterator
	over multiple calls).

	libctf/
		* ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable
		value for returning if never reset during the function.

2023-03-24  Nick Alcock  <nick.alcock@oracle.com>

	libctf: fix assertion failure with no system qsort_r
	If no suitable qsort_r is found in libc, we fall back to an
	implementation in ctf-qsort.c.  But this implementation routinely calls
	the comparison function with two identical arguments. The comparison
	function that ensures that the order of output types is stable is not
	ready for this, misinterprets it as a type appearing more that once (a
	can-never-happen condition) and fails with an assertion failure.

	Fixed, audited for further instances of the same failure (none found)
	and added a no-qsort test to my regular testsuite run.

	libctf/:
		PR libctf/30013
		* ctf-dedup.c (sort_output_mapping): Inputs are always equal to
		themselves.

2023-03-24  Tom Tromey  <tromey@adacore.com>

	Fix race in DAP startup
	Internal AdaCore DAP testing on Windows has had occasional failures
	that show:

	    assert threading.current_thread() is _dap_thread

	I think this is a race in DAP startup: the _dap_thread global is only
	set on return from start_thread, but it seems possible that the thread
	itself could already run and encounter a @in_dap_thread decorator.

	This patch fixes the problem by setting the global before running any
	of the code in the new thread.  This also lets us remove a FIXME.

2023-03-24  Luis Machado  <luis.machado@arm.com>

	aarch64: Check for valid inferior thread/regcache before reading pauth registers
	There were reports of gdb throwing internal errors when calling
	inferior_thread ()/get_current_regcache () on a system with
	Pointer Authentication enabled.

	In such cases, gdb produces the following backtrace:

	../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	----- Backtrace -----
	0xaaaae04a571f gdb_internal_backtrace_1
		../../../repos/binutils-gdb/gdb/bt-utils.c:122
	0xaaaae04a57f3 _Z22gdb_internal_backtracev
		../../../repos/binutils-gdb/gdb/bt-utils.c:168
	0xaaaae0b52ccf internal_vproblem
		../../../repos/binutils-gdb/gdb/utils.c:401
	0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list
		../../../repos/binutils-gdb/gdb/utils.c:481
	0xaaaae0e24b8f _Z18internal_error_locPKciS0_z
		../../../repos/binutils-gdb/gdbsupport/errors.cc:58
	0xaaaae0a88983 _Z15inferior_threadv
		../../../repos/binutils-gdb/gdb/thread.c:86
	0xaaaae0956c87 _Z20get_current_regcachev
		../../../repos/binutils-gdb/gdb/regcache.c:428
	0xaaaae035223f aarch64_remove_non_address_bits
		../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572
	0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm
		../../../repos/binutils-gdb/gdb/gdbarch.c:3109
	0xaaaae0a692d7 memory_xfer_partial
		../../../repos/binutils-gdb/gdb/target.c:1620
	0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm
		../../../repos/binutils-gdb/gdb/target.c:1684
	0xaaaae0a69e9f target_read_partial
		../../../repos/binutils-gdb/gdb/target.c:1937
	0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml
		../../../repos/binutils-gdb/gdb/target.c:1977
	0xaaaae0a69937 _Z18target_read_memorymPhl
		../../../repos/binutils-gdb/gdb/target.c:1773
	0xaaaae08be523 ps_xfer_memory
		../../../repos/binutils-gdb/gdb/proc-service.c:90
	0xaaaae08be6db ps_pdread
		../../../repos/binutils-gdb/gdb/proc-service.c:124
	0x40001ed7c3b3 _td_fetch_value
		/build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115
	0x40001ed791ef td_ta_map_lwp2thr
		/build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194
	0xaaaae07f4473 thread_from_lwp
		../../../repos/binutils-gdb/gdb/linux-thread-db.c:413
	0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
		../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420
	0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
		../../../repos/binutils-gdb/gdb/target.c:2586
	0xaaaae0789cf7 do_target_wait_1
		../../../repos/binutils-gdb/gdb/infrun.c:3825
	0xaaaae0789e6f operator()
		../../../repos/binutils-gdb/gdb/infrun.c:3884
	0xaaaae078a167 do_target_wait
		../../../repos/binutils-gdb/gdb/infrun.c:3903
	0xaaaae078b0af _Z20fetch_inferior_eventv
		../../../repos/binutils-gdb/gdb/infrun.c:4314
	0xaaaae076652f _Z22inferior_event_handler19inferior_event_type
		../../../repos/binutils-gdb/gdb/inf-loop.c:41
	0xaaaae07dc68b handle_target_event
		../../../repos/binutils-gdb/gdb/linux-nat.c:4206
	0xaaaae0e25fbb handle_file_event
		../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573
	0xaaaae0e264f3 gdb_wait_for_event
		../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694
	0xaaaae0e24f9b _Z16gdb_do_one_eventi
		../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217
	0xaaaae080f033 start_event_loop
		../../../repos/binutils-gdb/gdb/main.c:411
	0xaaaae080f1b7 captured_command_loop
		../../../repos/binutils-gdb/gdb/main.c:475
	0xaaaae0810b97 captured_main
		../../../repos/binutils-gdb/gdb/main.c:1318
	0xaaaae0810c1b _Z8gdb_mainP18captured_main_args
		../../../repos/binutils-gdb/gdb/main.c:1337
	0xaaaae0338453 main
		../../../repos/binutils-gdb/gdb/gdb.c:32
	---------------------
	../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
	A problem internal to GDB has been detected,
	further debugging may prove unreliable.
	Quit this debugging session? (y or n)

	We also see failures across the testsuite if the tests get executed on a target
	that has native support for the pointer authentication feature. But
	gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of
	tests that run into errors and internal errors.

	This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which
	enabled more broad use of pointer authentication masks to remove non-address
	bits of pointers, but wasn't immediately detected because systems with native
	support for pointer authentication are not that common yet.

	The above crash happens because gdb is in the middle of handling an event,
	and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the
	current thread.  This means a call to inferior_thread () will assert, and
	attempting to call get_current_regcache () will also call inferior_thread (),
	resulting in an assertion as well.

	target_has_registers was one function that seemed useful for detecting these
	types of situation where we don't have a register cache. The problem with that
	is the inconsistent state of inferior_ptid, which is used by
	target_has_registers.

	Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from
	do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to
	ps_xfer_memory sets inferior_ptid momentarily before reading memory:

	static ps_err_e
	ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr,
	                gdb_byte *buf, size_t len, int write)
	{
	  scoped_restore_current_inferior restore_inferior;
	  set_current_inferior (ph->thread->inf);

	  scoped_restore_current_program_space restore_current_progspace;
	  set_current_program_space (ph->thread->inf->pspace);

	  scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid);
	  inferior_ptid = ph->thread->ptid;

	  CORE_ADDR core_addr = ps_addr_to_core_addr (addr);

	  int ret;
	  if (write)
	    ret = target_write_memory (core_addr, buf, len);
	  else
	    ret = target_read_memory (core_addr, buf, len);
	  return (ret == 0 ? PS_OK : PS_ERR);
	}

	Maybe this shouldn't happen, or maybe it is just an unfortunate state to be
	in. But this prevents the use of target_has_registers to guard against the
	lack of registers, since, although current_thread_ is still nullptr,
	inferior_ptid is valid and is not null_ptid.

	There is another crash scenario after we kill a previously active inferior, in
	which case the gdbarch will still say we support pointer authentication but we
	will also have no current thread (inferior_thread () will assert etc).

	If the target has support for pointer authentication, gdb needs to use
	a couple (or 4, for bare-metal) mask registers to mask off some bits of
	pointers, and for that it needs to access the registers.

	At some points, like the one from the backtrace above, there is no active
	thread/current regcache because gdb is in the middle of doing event handling
	and switching between threads.

	Simon suggested the use of inferior_ptid to fetch the register cache, as
	opposed to relying on the current register cache.  Though we need to make sure
	inferior_ptid is valid (not null_ptid), I think this works nicely.

	With inferior_ptid, we can do safety checks along the way, making sure we have
	a thread to fetch a register cache from and checking if the thread is actually
	stopped or running.

	The following patch implements this idea with safety checks to make sure we
	don't run into assertions or errors.  If any of the checks fail, we fallback to
	using a default mask to remove non-address bits of a pointer.

	I discussed with Pedro the possibility of caching the mask register values
	(which are per-process and can change mid-execution), but there isn't a good
	spot to cache those values. Besides, the mask registers can change constantly
	for bare-metal debugging when switching between exception levels.

	In some cases, it is just not possible to get access to these mask registers,
	like the case where threads are running. In those cases, using a default mask
	to remove the non-address bits should be enough.

	This can happen when we let threads run in the background and then we attempt
	to access a memory address (now that gdb is capable of reading memory even
	with threads running).  Thus gdb will attempt to remove non-address bits
	of that memory access, will attempt to access registers, running into errors.

	Regression-tested on aarch64-linux Ubuntu 20.04.

2023-03-24  Alan Modra  <amodra@gmail.com>

	Tidy string_ptr increment
		* peicode.h (pe_ILF_make_a_symbol): Use sprintf output to
		increment string_ptr to end of new string.

	Tidy dwarf1 cached section contents
		* dwarf1.c (_bfd_dwarf1_cleanup_debug_info): New function.
		* libbfd-in.h (_bfd_dwarf1_cleanup_debug_info): Declare.
		* elf.c (_bfd_elf_close_and_cleanup): Call it.
		* elf-bfd.h (struct elf_obj_tdata): Make dwarf1_find_line_info
		a void*.
		* libbfd.h: Regenerate.

2023-03-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument
	In proc mi_expect_stop there's a proc argument reason that's handled like so:
	...
	set r "reason=\"$reason\","
	...

	That's fine for say:
	...
	set reason "foo"
	...
	for which this evaluates to:
	...
	set r "reason=\"foo\","
	...

	But there are more complex uses, for instance:
	...
	set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
	...
	which evaluates to:
	...
	set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
	...

	Note how in this reason argument, the first two '\"' seems to form a pair
	surrounding ',disp=', which is not the case, which is confusing.

	Fix this by only adding the quotes in mi_expect_stop if the string doesn't
	already contain quotes, such that we have the more readable:
	...
	set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
	...

	Tested on x86_64-linux.

2023-03-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/m-static.exp regression on Ubuntu 20.04
	In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I
	needed to change ".*/" into "(.*/)?" in:
	...
	gdb_test "info variable everywhere" \
	    "File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;"
	...

	However, due to the fact that I got this output:
	...
	(gdb) info variable everywhere^M
	All variables matching regular expression "everywhere":^M
	^M
	File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
	8:      const int gnu_obj_4::everywhere;^M
	^M
	File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
	8:      const int gnu_obj_4::everywhere;^M
	...
	I decided to make the matching somewhat stricter, to make sure that the two
	matched lines were subsequent.

	The commit turned out to be more strict than intended, and caused a regression
	on Ubuntu 20.04, where the output was instead:
	...
	(gdb) info variable everywhere^M
	All variables matching regular expression "everywhere":^M
	^M
	File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
	8:      const int gnu_obj_4::everywhere;^M
	...

	At that point I realized I'm looking at a bug (filed as PR symtab/30265),
	which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu
	20.04 for readnow, but not for native.

	Before my commit, the test-case passed whether the bug manifested or not.

	After my commit, the test-case only passed when the bug manifested.

	Fix the test-case regression by reverting to the situation before the commit:
	pass whether the bug manifests or not.  We could add an xfail for the PR, but
	I'm expecting a fix soon, so that doesn't look worth the effort.

	Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with
	native and readnow.

	Reported-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-24  Tom de Vries  <tdevries@suse.de>

	[gdb/dap] Add logging of ignored lines
	This input sequence is accepted by DAP:
	...
	{"seq": 4, "type": "request", "command": "configurationDone"}Content-Length: 84
	...

	This input sequence has the same effect:
	...
	{"seq": 4, "type": "request", "command": "configurationDone"}ignorethis
	Content-Length: 84
	...
	but the 'ignorethis' part is silently ignored.

	Log the ignored bit, such that we have:
	...
	READ: <<<{"seq": 4, "type": "request", "command": "configurationDone"}>>>
	WROTE: <<<{"request_seq": 4, "type": "response", "command": "configurationDone"
	, "success": true}>>>
	+++ run
	IGNORED: <<<b'ignorethis'>>>
	...

2023-03-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-23  Tom Tromey  <tromey@adacore.com>

	Fix minor grammar issue in python.texi
	I noticed a minor grammar problem in the 'GDB/MI Commands In Python'
	node of the manual.  I'm checking in this patch to correct it.

2023-03-23  Frederic Cambus  <fred@statdns.com>

	Add support to readelf for the PT_OPENBSD_MUTABLE segment type.
	binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type.
	include  * elf/common.h (PT_OPENBSD_MUTABLE): Define.

2023-03-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use gdb_remote_download in allow_opencl_tests
	Simon reported that doing:
	...
	$ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
	...
	could run into:
	...
	ERROR: remote_download to target of \
	  /data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
	  cp: cannot create regular file 'opencl_kernel.cl': File exists
	...

	Fix this by using gdb_remote_download (instead of plain remote_download) in
	allow_opencl_test, which takes care of:
	- downloading to a location which is safe for parallel testing, by
	  using standard_output_file, and
	- cleaning up the downloaded file, meaning we can remove the corresponding
	  "remote_file target delete ${clprogram}" lines in allow_opencl_test.

	Tested on x86_64-linux.

	Reported-by: Simon Marchi <simon.marchi@efficios.com>

2023-03-23  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Optimize BTI stubs PR30076
	Don't insert a second stub if the target is already compatible with
	an indirect branch.

2023-03-23  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Fix stubs that may break BTI PR30076
	Insert two stubs in a BTI enabled binary when fixing long calls: The
	first is near the call site and uses an indirect jump like before,
	but it targets the second stub that is near the call target site and
	uses a direct jump.

	This is needed when a single stub breaks BTI compatibility.

	The stub layout is kept fixed between sizing and building the stubs,
	so the location of the second stub is known at build time, this may
	introduce padding between stubs when those are relaxed.  Stub layout
	with BTI disabled is unchanged.

2023-03-23  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	bfd: aarch64: Refactor stub sizing code
	elfNN_aarch64_size_stubs has grown big, so factor out the call stub
	related code before adding new logic there.

2023-03-23  Andrew Burgess  <aburgess@redhat.com>

	gdb/riscv: add systemtap support
	This commit is initial support for SystemTap for RISC-V Linux.  The
	following two tests exercise SystemTap functionality, and are showing
	many failures, which are all fixed by this commit:

	  gdb.cp/exceptprint.exp
	  gdb.base/stap-probe.exp

	One thing I wasn't sure about is if the SystemTap support should be
	Linux specific, or architecture specific.  For aarch64, arm, ia64, and
	ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c
	file, while for amd64, i386, and s390 the implementation lives in
	ARCH-tdep.c.  I have no idea which of these is the better choice -- or
	maybe both choices are correct in the right circumstances, and I'm
	just not aware of how to choose between them.

	Anyway, for this patch I selected riscv-tdep.c (though clearly, moving
	the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a
	more appropriate location).

	The stap-probe.exp file tests immediate, register, and register
	indirect operands, all of which appear to be working fine with this
	commit.  The generic expression support doesn't appear to be
	architecture specific, so I'd expect that to work fine too.

2023-03-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-22  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove gdbarch_displaced_step_fixup_p
	The comment on the gdbarch_displaced_step_fixup gdbarch method
	indicates that this method is optional and that GDB will perform some
	default if this method is not supplied.  As such we define a predicate
	gdbarch_displaced_step_fixup_p.

	It may have been true at one point that the fixup method was optional,
	but it is no longer true.  If this method is not defined and GDB tries
	to complete a displaced step, then GDB is going to crash.

	Additionally the gdbarch_displaced_step_fixup_p predicate is not used
	anywhere in GDB.

	In this commit I have removed the gdbarch_displaced_step_fixup_p
	predicate, and I have updated the validation check for the
	gdbarch_displaced_step_fixup method; if the
	gdbarch_displaced_step_copy_insn method is defined then the fixup
	method must also be defined.

	I believe I've manually checked all the current places where
	gdbarch_displaced_step_copy_insn is defined and they all also define
	the fixup method, so this change should cause no problems for anyone.

	There should be no user visible changes after this commit.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-03-22  Tom Tromey  <tromey@adacore.com>

	Remove unnecessary cast
	I found an upcast from template_symbol to symbol.  This was necessary
	long ago, but since symbols use inheritance now, it is not.  This
	patch removes it.  Tested by rebuilding.

2023-03-22  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: adjust test cases to previous "maintenance info line-table" change
	Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show
	relocated addresses again") changed the format of that command, but
	failed to adjust some test cases that relied on it.  This patch fixes
	it.

	The failures fixed are:

	    FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
	    FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
	    FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table

	Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c

2023-03-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/cp-relocate.exp for remote host
	Fix test-case gdb.cp/cp-relocate.exp for remote host using
	gdb_remote_download.

	Tested on x86_64-linux.

2023-03-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/annota{2,3}.exp for native-extended-gdbserver
	When running test-cases gdb.cp/annota{2,3}.exp with target board
	native-extended-gdbserver, we run into a few FAILs, due to the test-cases
	trying to match inferior output together with gdb output.

	Fix this by ignoring the inferior output in this case.

	Tested on x86_64-linux.

2023-03-22  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/*.exp for remote host
	Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
	include_file.

	Tested on x86_64-linux.

2023-03-22  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make "maintenance info line-table" show relocated addresses again
	Commit 1acc9dca423f ("Change linetables to be objfile-independent")
	changed "maintenance info line-table" to print unrelocated addresses
	instead of relocated.  This breaks a few tests on systems where that
	matters.  The ones I see are:

	    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
	    FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
	    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
	    FAIL: gdb.base/async.exp: stepi&
	    FAIL: gdb.base/async.exp: nexti&
	    FAIL: gdb.base/async.exp: finish&

	These tests run "maintenance info line-table" to record the address of
	some lines, and then use these addresses in expected patterns.  It
	therefore expects these addresses to match the runtime addresses,
	therefore the relocated addresses.

	Add back the relocated addresses, next to the unrelocated addresses,
	like so:

	    INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END
	    0      6      0x0000555555555119 0x0000000000001119 Y
	    1      7      0x000055555555511d 0x000000000000111d Y
	    2      8      0x0000555555555123 0x0000000000001123 Y
	    3      END    0x0000555555555125 0x0000000000001125 Y

	The unrelocated addresses can always be useful trying to map this
	information with a DWARF info dump.

	Adjust the is_stmt_addresses proc in the testsuite to match the new
	output.

	Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf

2023-03-22  Alan Modra  <amodra@gmail.com>

	coff_get_normalized_symtab bfd_release
	We can't free "internal" on errors, since bfd_coff_swap_sym_in may
	call bfd_alloc.  For example, _bfd_XXi_swap_sym_in may even create new
	sections, which use bfd_alloc'd memory.  If "internal" is freed, all
	more recently bfd_alloc'd memory is also freed.

		* coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
		error.

2023-03-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-21  Alan Modra  <amodra@gmail.com>

	Remove unnecessary memsets in sframe-dump.c
		* sframe-dump.c (dump_sframe_func_with_fres): Don't memset temp.

	Sanity check coff-sh and coff-mcore sym string offset
		* coff-mcore.c (coff_mcore_relocate_section): Sanity check sym
		string offset when setting up name for use by error messages.
		* coff-sh.c (sh_relocate_section): Likewise.

2023-03-21  Alan Modra  <amodra@gmail.com>

	PR17910 sym string offset check
	As far as I can see the only place that sets obj_coff_strings without
	setting obj_coff_strings_len is pe_ILF_build_a_bfd.  Fix that and we
	can simplify the sym string offset check.  This is just a tidy.
	pe_ILF_build_a_bfd doesn't create bad symbols and
	_bfd_coff_read_string_table will always result in non-zero
	obj_coff_strings_len when obj_coff_strings is non-NULL.

		PR 17910
		* coffgen.c (_bfd_coff_internal_syment_name): Always sanity
		check sym string offset.
		* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len.

2023-03-21  Alan Modra  <amodra@gmail.com>

	PE fake section for C_SECTION syms
	It's an odd thing to have objdump -x show a different section table
	to objdump -h, but that can happen if swapping in symbols leads to
	creating sections.  Setting SEC_LINKER_CREATED stops the display of
	these sections, so that you get shown what is in the object file.

		* peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on
		fake section created for C_SECTION syms.  Don't zero asection
		fields that are already zero.

2023-03-21  Alan Modra  <amodra@gmail.com>

	XCOFF: use bfd_coff_close_and_cleanup
	Free memory on closing bfds.  The COFF close_and_cleanup does more
	work than _bfd_generic_close_and_cleanup (defined as
	_bfd_archive_close_and_cleanup).

		* coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as
		_bfd_coff_close_and_cleanup.
		* coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use
		_bfd_coff_close_and_cleanup.

2023-03-21  Alan Modra  <amodra@gmail.com>

	gas: expand_irp memory leaks
		* macro.c (expand_irp): Free memory on error return paths.

2023-03-21  H.J. Lu  <hjl.tools@gmail.com>

	x86: Check unbalanced braces in memory reference
	Check unbalanced braces in memory reference to avoid assembler crash
	caused by

	commit e87fb6a6d0cdfc0e9c471b7825c20c238c2cf506
	Author: Jan Beulich <jbeulich@suse.com>
	Date:   Wed Oct 5 09:16:24 2022 +0200

	    x86/gas: support quoted address scale factor in AT&T syntax

		PR gas/30248
		* config/tc-i386.c (i386_att_operand): Check unbalanced braces
		in memory reference.
		* testsuite/gas/i386/i386.exp: Run pr30248.
		* testsuite/gas/i386/pr30248.d: New file.
		* testsuite/gas/i386/pr30248.err: Likewise.
		* testsuite/gas/i386/pr30248.s: Likewise.

2023-03-21  Carl Love  <cel@us.ibm.com>

	PowerPC: regression fix for reverse-finish command.
	The recent commit:

	  commit 2a8339b71f37f2d02f5b2194929c9d702ef27223
	  Author: Carl Love <cel@us.ibm.com>
	  Date:   Thu Mar 9 16:10:18 2023 -0500

	   PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

	   PPC64 multiple entry points, a normal entry point and an alternate entry
	   point.  The alternate entry point is to setup the Table of Contents (TOC)
	   register before continuing at the normal entry point.  When the TOC is
	   already valid, the normal entry point is used, this is typically the case.
	   The alternate entry point is typically referred to as the global entry
	   point (GEP) in IBM.  The normal entry point is typically referred to as
	   the local entry point (LEP).
	     .....

	Is causing regression failures on on PowerPC platforms.  The regression
	failures are in tests:

	  gdb.reverse/finish-precsave.exp
	  gdb.btrace/tailcall.exp
	  gdb.mi/mi-reverse.exp
	  gdb.btrace/step.exp
	  gdb.reverse/until-precsave.exp
	  gdb.reverse/finish-reverse.exp
	  gdb.btrace/tailcall-only.exp

	The issue is in gdb/infcmd.c, function finish_command.  The value of the
	two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed
	to SAL.PC.  However, SAL has just been declared.  The value of SAL.PC is
	zero at this point.  The intialization of ALT_ENTRY_POINT and ENTRY_POINT
	needs to be after the initialization of SAL.

	This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT
	variables to fix the regression failures.

	The patch has been tested on Power10 and on X86.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Check remote_exec results in board files
	Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is
	checked.

	Tested on x86_64-linux.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.exp
	In a recent commit I forgot to add a double quote before chmod here:
	...
	      remote_exec build $rsh_cmd chmod go-rx ."
	...

	Fix it by adding the missing double quote.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.exp
	Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp,
	I don't see a relevant difference with the implementation of standard_file
	in dejagnu.

	Simplify the board by removing ${board}_file.

	Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use localhost instead of 127.0.0.1 for boards
	Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1".

	Use instead "localhost".

	Tested on x86_64-linux.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.xml/tdesc-regs.exp for remote host
	Fix test-case gdb.xml/tdesc-regs.exp for remote host by using appropriate
	filenames.

	Tested on x86_64-linux.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.xml/tdesc-reload.exp for remote host
	Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate
	filenames.

	Tested on x86_64-linux.

2023-03-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set remotedir in local-remote-host-native.exp
	In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I
	removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs
	in test-case gdb.testsuite/board-sanity.exp.

	Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for
	a host board no longer make compilation fail due to commit 80d6c79866f
	("[gdb/testsuite] Handle remotedir in remote_upload").

	This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit
	3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards").

	Tested on x86_64-linux.

2023-03-21  Jiawei  <jiawei@iscas.ac.cn>

	RISC-V: Fix disassemble fetch fail return value.
	This bug reported in
	https://sourceware.org/bugzilla/show_bug.cgi?id=30184
	And discussed in
	https://sourceware.org/pipermail/binutils/2023-February/126213.html

	We also checked the implementation of return value in arm and mips.
	So this patch changes the return value to -1, that can fix bugs and maintain
	consistency with other architectures.

	opcodes/ChangeLog:

	        * riscv-dis.c (print_insn_riscv):Change the return value.

2023-03-21  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Remove .c header files from rs6000-aix-nat.c file
	Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64
	definitions are moved to ppc-tdep.h we no longer need to import these .c files.

2023-03-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-20  Tom Tromey  <tom@tromey.com>

	Remove some unnecessary includes from *-exp.y
	I noticed a weird comment in one of the .y files, and then ended up
	removing some unnecessary #includes from these files.

	Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-20  Tom Tromey  <tromey@adacore.com>

	Remove mi_version function
	The mi_version function is unused, and I think it's better overall if
	it is never used.  This patch removes it.  Tested by rebuilding.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-20  Tom Tromey  <tromey@adacore.com>

	Update python-helper.exp for type allocation changes
	The type allocation changes introduced a failure in python-helper.exp
	that I did not notice.  The bug is that, with these patches,
	arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
	This patch updates the test to allow this.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30253

2023-03-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle remotedir in remote_upload
	Dejagnu's remotedir implementation has support in remote_exec and
	remote_download, but not remote_upload.

	Consider the following scenario:
	- downloading an executable to target,
	- running it,
	- uploading a file produced by the executable
	while assuming remote target user remote-target with homedir
	/home/remote-target and remotedir set to /home/remote-target/tmp.

	Concretely, it looks like this:
	...
	 # binfile == "$outputs/gdb.abc/a.out"
	 set target_binfile [remote_download target $binfile]
	 # target_binfile == "/home/remote-target/tmp/a.out"
	 remote_exec target $target_binfile
	 # Running $target_binfile produced /home/remote-target/tmp/result.txt.
	 set result [remote_upload target /home/remote-target/tmp/result.txt \
	                 $outputs/gdb.abc/result.txt]
	 # result == $outputs/gdb.abc/result.txt.
	...

	Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
	overriding dejagnu's remote_upload, such that we can simplify the
	remote_upload call to:
	...
	 set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
	...

	Tested on x86_64-linux.

	PR testsuite/30250
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250

2023-03-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix crash during command completion
	In some cases GDB will fail when attempting to complete a command that
	involves a rust symbol, the failure can manifest as a crash.

	The problem is caused by the completion_match_for_lcd object being
	left containing invalid data during calls to cp_symbol_name_matches_1.

	The first question to address is why we are calling a C++ support
	function when handling a rust symbol.  That's due to GDB's auto
	language detection for msymbols, in some cases GDB can't tell if a
	symbol is a rust symbol, or a C++ symbol.

	The test application contains symbols for functions which are
	statically linked in from various rust support libraries.  There's no
	DWARF for these symbols, so all GDB has is the msymbols built from the
	ELF symbol table.

	Here's the problematic symbol that leads to our crash:

	    mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE
	  demangled: core::str::<impl str>::parse

	As an msymbol this is initially created with language auto, then GDB
	eventually calls symbol_find_demangled_name, which loops over all
	languages calling language_defn::sniff_from_mangled_name, the first
	language that can demangle the symbol gets assigned as the language
	for that symbol.

	Unfortunately, there's overlap in the mangled symbol names,
	some (legacy) rust symbols can be demangled as both rust and C++, see
	cplus_demangle in libiberty/cplus-dem.c where this is mentioned.

	And so, because we check the C++ language before we check for rust,
	then the msymbol is (incorrectly) given the C++ language.

	Now it's true that is some cases we might be able to figure out that a
	demangled symbol is not actually a valid C++ symbol, for example, in
	our case, the construct '::<impl str>::' is not, I believe, valid in a
	C++ symbol, we could look for ':<' and '>:' and refuse to accept this
	as a C++ symbol.

	However, I'm not sure it is always possible to tell that a demangled
	symbol is rust or C++, so, I think, we have to accept that some times
	we will get this language detection wrong.

	If we accept that we can't fix the symbol language detection 100% of
	the time, then we should make sure that GDB doesn't crash when it gets
	the language wrong, that is what this commit addresses.

	In our test case the user tries to complete a symbol name like this:

	  (gdb) complete break pars

	This results in GDB trying to find all symbols that match 'pars',
	eventually we consider our problematic symbol, and we end up with a
	call stack that looks like this:

	  #0  0x0000000000f3c6bd in strncmp_iw_with_mode
	  #1  0x0000000000706d8d in cp_symbol_name_matches_1
	  #2  0x0000000000706fa4 in cp_symbol_name_matches
	  #3  0x0000000000df3c45 in compare_symbol_name
	  #4  0x0000000000df3c91 in completion_list_add_name
	  #5  0x0000000000df3f1d in completion_list_add_msymbol
	  #6  0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on
	  #7  0x0000000000658c08 in language_defn::collect_symbol_completion_matches
	  #8  0x0000000000df54c9 in collect_symbol_completion_matches
	  #9  0x00000000009d98fb in linespec_complete_function
	  #10 0x00000000009d99f0 in complete_linespec_component
	  #11 0x00000000009da200 in linespec_complete
	  #12 0x00000000006e4132 in complete_address_and_linespec_locations
	  #13 0x00000000006e4ac3 in location_completer

	In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly
	tries to match the demangled problematic symbol name against the user
	supplied text ('pars').  Each time around the loop another component
	of the symbol name is stripped off, thus, we check 'pars' against
	these options:

	  core::str::<impl str>::parse
	  str::<impl str>::parse
	  <impl str>::parse
	  parse

	As soon as we get a match the cp_symbol_name_matches_1 exits its loop
	and returns.  In our case, when we're looking for 'pars', the match
	occurs on the last iteration of the loop, when we are comparing to
	'parse'.

	Now the problem here is that cp_symbol_name_matches_1 uses the
	strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for
	skipping over template parameters.  This allows GDB to match the
	symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'.
	Inside strncmp_iw_with_mode GDB will record any template arguments
	that it has skipped over inside the completion_match_for_lcd object
	that is passed in as an argument.

	And so, when GDB tries to match against '<impl str>::parse', the first
	thing it sees is '<impl str>', GDB assumes this is a template argument
	and records this as a skipped region within the
	completion_match_for_lcd object.  After '<impl str>' GDB sees a ':'
	character, which doesn't match with the 'pars' the user supplied, so
	strncmp_iw_with_mode returns a value indicating a non-match.  GDB then
	removes the '<impl str>' component from the symbol name and tries
	again, this time comparing to 'parse', which does match.

	Having found a match, then in cp_symbol_name_matches_1 we record the
	match string, and the full symbol name within the
	completion_match_result object, and return.

	The problem here is that the skipped region, the '<impl str>' that we
	recorded in the penultimate loop iteration was never discarded, its
	still there in our returned result.

	If we look at what the pointers held in the completion_match_result
	that cp_symbol_name_matches_1 returns, this is what we see:

	  core::str::<impl str>::parse
	  |          \________/  |
	  |               |      '--- completion match string
	  |               '---skip range
	  '--- full symbol name

	When GDB calls completion_match_for_lcd::finish, GDB tries to create a
	string using the completion match string (parse), but excluding the
	skip range, as the stored skip range is before the start of the
	completion match string, then GDB tries to do some weird string
	creation, which will cause GDB to crash.

	The reason we don't often see this problem in C++ is that for C++
	symbols there is always some non-template text before the template
	argument.  This non-template text means GDB is likely to either match
	the symbol, or reject the symbol without storing a skip range.

	However, notice, I did say, we don't often see this problem.  Once I
	understood the issue, I was able to reproduce the crash using a pure
	C++ example:

	  template<typename S>
	  struct foo
	  {
	    template<typename T>
	    foo (int p1, T a)
	    {
	      s = 0;
	    }

	    S s;
	  };

	  int
	  main ()
	  {
	    foo<int> obj (2.3, 0);
	    return 0;
	  }

	Then in GDB:

	  (gdb) complete break foo(int

	The problem here is that the C++ symbol for the constructor looks like
	this:

	  foo<int>::foo<double>(int, double)

	When GDB enters cp_symbol_name_matches_1 the symbols it examines are:

	  foo<int>::foo<double>(int, double)
	  foo<double>(int, double)

	The first iteration of the loop will match the 'foo', then add the
	'<int>' template argument will be added as a skip range.  When GDB
	find the ':' after the '<int>' the first iteration of the loop fails
	to match, GDB removes the 'foo<int>::' component, and starts the
	second iteration of the loop.

	Again, GDB matches the 'foo', and now adds '<double>' as a skip
	region.  After that the '(int' successfully matches, and so the second
	iteration of the loop succeeds, but, once again we left the '<int>' in
	place as a skip region, even though this occurs before the start of
	our match string, and this will cause GDB to crash.

	This problem was reported to the mailing list, and a solution
	discussed in this thread:

	  https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html

	The solution proposed here is similar to one proposed by the original
	bug reported, but implemented in a different location within GDB.
	Instead of placing the fix in strncmp_iw_with_mode, I place the fix in
	cp_symbol_name_matches_1.  I believe this is a better location as it
	is this function that implements the loop, and it is this loop, which
	repeatedly calls strncmp_iw_with_mode, that should be resetting the
	result object state (I believe).

	What I have done is add an assert to strncmp_iw_with_mode that the
	incoming result object is empty.

	I've also added some other asserts in related code, in
	completion_match_for_lcd::mark_ignored_range, I make some basic
	assertions about the incoming range pointers, and in
	completion_match_for_lcd::finish I also make some assertions about how
	the skip ranges relate to the match pointer.

	There's two new tests.  The original rust example that was used in the
	initial bug report, and a C++ test.  The rust example depends on which
	symbols are pulled in from the rust libraries, so it is possible that,
	at some future date, the problematic symbol will disappear from this
	test program.  The C++ test should be more reliable, as this only
	depends on symbols from within the C++ source code.

	Since I originally posted this patch to the mailing list, the
	following patch has been merged:

	  commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb
	  Date:   Sun Mar 19 09:13:10 2023 -0600

	      Use rust_demangle to fix a crash

	This solves the problem of a rust symbol ending up in the C++ specific
	code by changing the order languages are sorted.  However, this new
	commit doesn't address the issue in the C++ code which was fixed with
	this commit.

	Given that the C++ issue is real, and has a reproducer, I'm still
	going to merge this fix.  I've left the discussion of rust in this
	commit message as I originally wrote it, but it should be read within
	the context of GDB prior to commit 6e7eef72164c00d6a5a7.

	Co-Authored-By:  Zheng Zhan <zzlossdev@163.com>

2023-03-20  Jan Beulich  <jbeulich@suse.com>

	x86: drop identifier_chars[]
	It tries to resemble what's underlying is_part_of_name(), but doesn't
	quite achieve that: '$' for example is unconditionally marked as part of
	symbol names, but was included as identifier char for Intel syntax only.
	Note that i386_att_operand() checks for the immediate prefix first, so
	the wider coverage by starts_memory_operand() is has no real effect
	there, but it does matter for something like

		mov	%fs:$dollar, %eax

	which previously wasn't accepted (but which clearly is a memory
	reference - there's no point in forcing people to parenthesize the
	symbol name). Similarly including '%' as an identfier for Intel syntax
	had no real significance to the rest of the assembler. If '%' was to be
	valid in (unquoted) symbol names, LEX_PCT would need to be defined.

	Note further that this also addresses the latent issue of a sub-target
	defining LEX_AT or LEX_QM to zero: That would make '@' and/or '?' no
	valid part of symbol names, but would have included them in what
	is_identifier_char() considers a valid part of a name. (There's a minor
	related issue which is actually being eliminated: te-interix.h allows
	'@' only in the middle of symbol names, yet starts_memory_operand()
	specifically looks at the first character of [possibly] a symbol name.)

	In parse_real_register() there's no point also checking is_name_ender()
	as at this point no character is marked solely LEX_END_NAME by any sub-
	target. Checking is_name_beginner() is also pointless as the hash lookup
	will fail anyway for a zero-length name.

	While touching the check in parse_real_register() also drop the
	"allow_naked_reg" part of the condition: This has only led to
	inconsistent error messages.

2023-03-20  Jan Beulich  <jbeulich@suse.com>

	x86/AT&T: restrict recognition of the "absolute branch" prefix character
	While in principle merely rejecting this for .insn would be sufficient
	for the purposes there, be more generic and reject it for anything that
	isn't going to be a branch: All elements of same-mnemonic template
	groups either are branches, or are not, and the few cases possibly
	requiring a 2nd parsing pass aren't affected either. This then also
	improves diagnostics for misuses like

		inc	*%eax
		incl	%fs:*(%eax)
		add	*$1, %eax

2023-03-20  Jan Beulich  <jbeulich@suse.com>

	x86: drop "shimm" special case template expansions
	With VexVVVV only being boolean, the SSE shift-by-immediate instructions
	don't need special casing anymore for SSE2AVX handling. Simplify the two
	respective templates. (No change to generated tables.)

2023-03-20  Jan Beulich  <jbeulich@suse.com>

	x86: VexVVVV is now merely a boolean
	With the SDM long having dropped the NDS/NDD/DDS concept of identifying
	encoding variants, we can finally do away with this concept as well. Of
	the few consumers of the attribute, only an assertion was still checking
	for a particular value, which we don't really need to retain.

	When touching lines anyway, modernize other aspects as well. This often
	improves similarity to adjacent lines.

2023-03-20  Jan Beulich  <jbeulich@suse.com>

	x86: re-work build_modrm_byte()'s register assignment
	The function has accumulated a number of special cases for no real
	reason. Some were necessary because insn attributes (SwapSources in
	particular) weren't suitably utilized instead. Note that the addition of
	SwapSources actually increases consistency among the templates: Like
	others which already have the attribute, these are all insns where the
	VEX.VVVV-encoded register comes first (or last when looking at the SDM).

	Note that the vexvvvv attribute now has merely boolean meaning anymore,
	in line with the SDM long having dropped the NDS/NDD/DDS concept of
	identifying encoding variants. The fallout will be taken care of
	subsequently, though, to not further clutter the change here.

	As to the TILEZERO special case: If more instructions like this
	appeared, a new attribute would likely be the way to go. But as long as
	it's only a single insn, going from the mnemonic is cheaper.

2023-03-20  Cupertino Miranda  <cupertino.miranda@oracle.com>

	Changed ld and gas BPF tests
	Recent BPF patch removed and renamed the list of relocations based on
	the limitations of BPF instruction set.
	This patch is a correction to the tests.

	Reloc howto access broken for BPF
	Forgot to change the logic to access the reloc howto from
	bpf_elf_relocate_section.
	Problem was introduced in previous BPF commit.

2023-03-20  Tom Tromey  <tom@tromey.com>

	Use rust_demangle to fix a crash
	PR rust/30211 points out a crash caused by a particular completion.
	This turns out to happen because a Rust minsym winds up in a
	C++-specific path in strncmp_iw_with_mode, which ultimately causes the
	completer to pass invalid arguments to string::append.

	This patch fixes the bug by reordering the language constants so that
	Rust comes before C++, and then using rust_demangle.  This ensures
	that minsyms are correctly marked as "Rust", avoiding this code and
	thus the crash.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20367
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30211
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-03-20  Tom Tromey  <tromey@adacore.com>

	Make ui_out::do_progress_end 'private'
	I noticed that ui_out::do_progress_end is public, just to support one
	use in debuginfod-support.c.  This patch makes it private, updates
	progress_info to call it from its destructor, and finally changes
	debuginfod-support.c to follow.

2023-03-20  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't use the global thread-id in the saved breakpoints file
	I noticed that breakpoint::print_recreate_thread was printing the
	global thread-id.  This function is used to implement the 'save
	breakpoints' command, and should be writing out suitable CLI commands
	for recreating the current breakpoints.  The CLI does not use global
	thread-ids, but instead uses the inferior specific thread-ids,
	e.g. "2.1".

	After some discussion on the mailing list it was suggested that the
	most consistent solution would be for the saved breakpoints file to
	always contain the inferior-qualified thread-id, so the file would
	include "thread 1.1" instead of just "thread 1", even when there is
	only a single inferior.

	So, this commit adds print_full_thread_id, which is just like the
	existing print_thread_id, only it always prints the inferior-qualified
	thread-id.

	I then update the existing print_thread_id to make use of this new
	function, and finally, I update  breakpoint::print_recreate_thread to
	also use this new function.

	There's a multi-inferior test that confirms the saved breakpoints file
	correctly includes the fully-qualified thread-id, and I've also
	updated the single inferior test gdb.base/save-bp.exp to have it
	validate that the saved breakpoints file includes the
	inferior-qualified thread-id, even for this single inferior case.

2023-03-20  Alan Modra  <amodra@gmail.com>

	Revert "segfault at i386-dis.c:9815"
	This reverts commit 92d450c79ad321e42f9a77692b5db10d0f7b9344.

	Accessing these local var structs using a volatile qualified pointer
	may indeed read the object, but I don't think changed values are
	guaranteed to be written back to the object unless the actual object
	is declared volatile.  That would probably slow down i386 disassembly
	unacceptably.

2023-03-20  Alan Modra  <amodra@gmail.com>

	libctf: unused variable
		* ctf-archive.c (arc_mmap_writeout): Delete unused variable.

2023-03-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: Use prototype to call libc functions
	libcollector may not link against libC.
	We use dlsym() to get a function from libc.
	In some files, pointers to these functions do not have prototypes.
	I also moved the shared definitions to libcollector/collect.h.

	gprofng/ChangeLog
	2023-03-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		libcollector/collector.c: Add prototypes.
		libcollector/dispatcher.c: Likewise.
		libcollector/heaptrace.c: Likewise.
		libcollector/iotrace.c: Likewise.
		libcollector/linetrace.c: Likewise.
		libcollector/mmaptrace.c: Likewise.
		libcollector/synctrace.c: Likewise.
		libcollector/collector.h: Add CALL_REAL(), NULL_PTR(), and DBG_LT.

2023-03-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-19  Tom Tromey  <tom@tromey.com>

	Don't declare psymbol_functions::fill_psymbol_map
	psymbol_functions::fill_psymbol_map was removed, but I forgot to
	remove the declaration.  This patch removes it.  Tested by rebuilding.

2023-03-19  Alan Modra  <amodra@gmail.com>

	segfault at i386-dis.c:9815
		* i386-dis.c (print_insn): Access "ins" and "priv" via volatile
		pointers after second sigsetjmp return.

2023-03-19  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Enable vector register visibility in core file for AIX binutils
	This patch will enable vector register visibility when AIX FOLKS do
	core file analysis.

2023-03-19  Alan Modra  <amodra@gmail.com>

	Regen ld/po/BLD-POTFILES.in

2023-03-19  Alan Modra  <amodra@gmail.com>

	XCOFF archive sanity check
	XCOFF archive elements are in a linked list.  Add a little more sanity
	checking.  This of course doesn't stop the fuzzers finding a way to
	make a loop, but this check is cheap.

		* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Sanity
		check that next element isn't pointing back to the header.

2023-03-19  Alan Modra  <amodra@gmail.com>

	rewrite_elf_program_header and want_p_paddr_set_to_zero
	Layout in rewrite_elf_program_header is really done by lma, even if
	program headers are going to have their p_paddr forced to zero.  Thus
	when not matching against an existing segment, don't try to use a
	"vma" from elf_segment_map.

		* elf.c (is_contained_by): Replace "bed" param with "use_vaddr".
		(IS_SECTION_IN_INPUT_SEGMENT): Adjust is_contained_by call.
		(rewrite_elf_program_header): Always match against lma in
		calls to is_contained_by using new maps.

2023-03-19  Alan Modra  <amodra@gmail.com>

	Another sanity check for read_section_stabs_debugging_info
		* rddbg.c (read_section_stabs_debugging_info): Ignore invalid
		stab sections with size less than 12 bytes.

	ctf segfaults
		PR 30228
		PR 30229
		* ctf-open.c (ctf_bufopen_internal): Check for NULL cts_data.
		* ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Likewise.

2023-03-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove objfile_type
	This removes objfile_type, in favor of always using the per-arch
	builtins.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Add some types to struct builtin_type
	This adds some types to struct builtin_type, ensuring it contains all
	the types currently used by objfile_type.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Rename objfile_type to builtin_type
	This renames objfile_type to be an overload of builtin_type, in
	preparation for their unification.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Use builtin type when appropriate
	There are a few spots that check whether a type is objfile-owned, and
	then choose either the objfile- or arch-specific builtin type.  I
	don't think there is a need to do this any more (if there ever was),
	because it is ok for an objfile-allocated type to refer to an
	arch-allocated type.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Use type allocator for set types
	This changes the set type creation function to accept a type
	allocator, and updates all the callers.  Note that symbol readers
	should generally allocate on the relevant objfile, regardless of the
	underlying type of the set, which is what this patch implements.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Use type allocator for array types
	This changes the array type creation functions to accept a type
	allocator, and updates all the callers.  Note that symbol readers
	should generally allocate on the relevant objfile, regardless of the
	placement of the index type of the array, which is what this patch
	implements.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Use type allocator for range types
	This changes the range type creation functions to accept a type
	allocator, and updates all the callers.  Note that symbol readers
	should generally allocate on the relevant objfile, regardless of the
	underlying type of the range, which is what this patch implements.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_pointer_type and init_pointer_type
	This unifies arch_pointer_type and init_pointer_type by using a type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_decfloat_type and init_decfloat_type
	This unifies arch_decfloat_type and init_decfloat_type by using a type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_float_type and init_float_type
	This unifies arch_float_type and init_float_type by using a type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_boolean_type and init_boolean_type
	This unifies arch_boolean_type and init_boolean_type by using a type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_character_type and init_character_type
	This unifies arch_character_type and init_character_type by using a
	type allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Unify arch_integer_type and init_integer_type
	This unifies arch_integer_type and init_integer_type by using a type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove init_type
	This removes init_type, replacing all uses with the new type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove arch_type
	This removes arch_type, replacing all uses with the new type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Reuse existing builtin types
	This changes a few spots to reuse the existing builting "void" type,
	rather than construct a new one.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove alloc_type
	This removes alloc_type, replacing all uses with the new type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove alloc_type_copy
	This removes alloc_type_copy, replacing all uses with the new type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Remove alloc_type_arch
	This removes alloc_type_arch, replacing all uses with the new type
	allocator.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom Tromey  <tom@tromey.com>

	Introduce type_allocator
	This introduces a new type_allocator class.  This class will be used
	to abstract out the placement of new types, so that type-creation code
	can be simplified and shared.

	Reviewed-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle unbuffer_output.c for remote host
	Handle $srcdir/lib/unbuffer_output.c using lappend_include_file.

	Tested on x86_64-linux.

2023-03-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle my-syscalls.h for remote host
	Handle $srcdir/lib/my-syscalls.h using lappend_include_dir.

	Tested on x86_64-linux.

2023-03-18  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle attributes.h for remote host
	Handle $srcdir/lib/attributes.h using lappend_include_dir.

	Tested on x86_64-linux.

2023-03-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-17  Tom Tromey  <tom@tromey.com>

	Fix line table regression
	Simon pointed out a line table regression, and after a couple of false
	starts, I was able to reproduce it by hand using his instructions.

	The bug is that most of the code in do_mixed_source_and_assembly uses
	unrelocated addresses, but one spot does:

	  pc = low;

	... after the text offset has been removed.

	This patch fixes the problem by introducing a new type to represent
	unrelocated addresses in the line table.  This prevents this sort of
	bug to some degree (it's still possible to manipulate a CORE_ADDR in a
	bad way, this is unavoidable).

	However, this did let the compiler flag a few spots in that function,
	and now it's not possible to compare an unrelocated address from a
	line table with an ordinary CORE_ADDR.

	Regression tested on x86-64 Fedora 36, though note this setup never
	reproduced the bug in the first place.  I also tested it by hand on
	the disasm-optim test program.

2023-03-17  Frederic Cambus  <fred@statdns.com>

	Update the NetBSD system call table to add eventfd(2) and timerfd(2).
	Generated from sys/sys/syscall.h revision 1.321.

2023-03-17  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: introduce bp_loc_tracepoint
	Since commit cb1e4e32c2d9 ("catch catch/throw/rethrow", breakpoint ->
	catchpoint), this simple tracing scenario does not work:

	    $ gdb/gdb -nx -q --data-directory=gdb/data-directory ./test
	    Reading symbols from ./test...
	    (gdb) tar rem :1234
	    Remote debugging using :1234
	    Reading symbols from /lib64/ld-linux-x86-64.so.2...
	    (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
	    0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2
	    (gdb) trace do_something
	    Tracepoint 1 at 0x555555555144: file test.c, line 5.
	    (gdb) tstart
	    (gdb) continue
	    Continuing.
	    Target returns error code '01'.

	The root cause is that the bp_location::nserted flag does not transfer
	anymore from an old bp_location to the new matching one.  When a shared
	library gets loaded, GDB computes new breakpoint locations for each
	breakpoint in update_breakpoint_locations.  The new locations are in the
	breakpoint::loc chain, while the old locations are still in the
	bp_locations global vector.  Later, update_global_location_list is
	called.  It tries to map old locations to new locations, and if
	necessary transfer some properties, like the inserted flag.

	Since commit cb1e4e32c2d9, the inserted flag isn't transferred for
	locations of tracepoints.  This is because bl_address_is_meaningful used
	to be implemented like this:

	    static int
	    breakpoint_address_is_meaningful (struct breakpoint *bpt)
	    {
	      enum bptype type = bpt->type;

	      return (type != bp_watchpoint && type != bp_catchpoint);
	    }

	and was changed to this:

	    static bool
	    bl_address_is_meaningful (bp_location *loc)
	    {
	      return loc->loc_type != bp_loc_other;
	    }

	Because locations for tracepoints have the bp_loc_other type,
	bl_address_is_meaningful started to return false for them, where it
	returned true before.  This made update_global_location_list skip the
	part where it calls swap_insertion.

	I think this can be solved by introduced a new bp_loc_tracepoint
	bp_loc_type.

	I don't know if it's accurate, but my understanding is that bp_loc_type
	describes roughly "how do we ask the target to insert that location".
	bp_loc_software_breakpoint are inserted using
	target_ops::insert_breakpoint_location.  bp_loc_hardware_breakpoint are
	inserted using target_ops::insert_hw_breakpoint.
	bp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted
	using target_ops::insert_watchpoint.  For all these, the address is
	meaningful, as we ask the target to insert the point at a specific
	address.  bp_loc_other is a catch-all for "the rest", in practice for
	catchpoints that don't have a specific address (hence why
	bl_address_is_meaningful returns false for them).  For instance,
	inserting a signal catchpoint is done by asking the target to report
	that specific signal.  GDB doesn't associate an address to that.

	But tracepoints do have a meaningful address to thems, so they can't be
	bp_loc_other, with that logic.  They also can't be
	bp_loc_software_breakpoint, because we don't want GDB to insert
	breakpoints for them (even though they might be implemented using
	software breakpoints by the remote side).  So, the new bp_loc_tracepoint
	type describes that the way to insert these locations is with
	target_ops::download_tracepoint.  It makes bl_address_is_meaningful
	return true for them.  And they'll be ignored by insert_bp_location and
	GDB won't try to insert a memory breakpoint for them.

	With this, I see a few instances of 'Target returns error code: 01'
	disappearing from gdb.log, and the results of gdb.trace/*.exp improve a
	little bit:

	    -# of expected passes       3765
	    +# of expected passes       3781
	    -# of unexpected failures   518
	    +# of unexpected failures   498

	Things remain quite broken in that area though.

	Change-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3

2023-03-17  Carl Love  <cel@us.ibm.com>

	PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
	PPC64 multiple entry points, a normal entry point and an alternate entry
	point.  The alternate entry point is to setup the Table of Contents (TOC)
	register before continuing at the normal entry point.  When the TOC is
	already valid, the normal entry point is used, this is typically the case.
	The alternate entry point is typically referred to as the global entry
	point (GEP) in IBM.  The normal entry point is typically referred to as
	the local entry point (LEP).

	When GDB is executing the finish command in reverse, the function
	finish_backward currently sets the break point at the alternate entry point.
	This issue is if the function, when executing in the forward direction,
	entered the function via the normal entry point, execution in the reverse
	direction will never sees the break point at the alternate entry point.  In
	this case, the reverse execution continues until the next break point is
	encountered thus stopping at the wrong place.

	This patch adds a new address to struct execution_control_state to hold the
	address of the alternate entry point (GEP).  The finish_backwards function
	is updated, if the stopping point is between the normal entry point (LEP)
	and the end of the function, a breakpoint is set at the normal entry point.
	If the stopping point is between the entry points, a breakpoint is set at
	the alternate entry point.  This ensures that GDB will always stop at the
	normal entry point.  If the function did enter via the alternate entry
	point, GDB will detect that and continue to execute backwards in the
	function until the alternate entry point is reached.

	The patch fixes the behavior of the reverse-finish command on PowerPC to
	match the behavior of the command on other platforms, specifically X86.
	The patch does not change the behavior of the command on X86.

	A new test is added to verify the reverse-finish command on PowerPC
	correctly stops at the instruction where the function call is made.

	The patch fixes 11 regression errors in test gdb.reverse/finish-precsave.exp
	and 11 regression errors in test gdb.reverse/finish-reverse.exp.

	The patch has been tested on Power 10 and X86 processor with no new
	regression failures.

2023-03-17  Carl Love  <cel@us.ibm.com>

	Move step_until procedure
	Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp
	is moved to lib/gdb.exp and renamed repeat_cmd_until.  The existing procedure
	gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until
	procedure.  The existing procedure gdb_step_until is changed to just call
	the new repeat_cmd_until procedure with the command set to "step" and an
	optional CURRENT string.  The default CURRENT string is set to "\}" to work
	with the existing uses of procedure gdb_step_until.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix regexp in gdb.arch/ftrace-insn-reloc.exp
	With test-case gdb.arch/ftrace-insn-reloc.exp and host board
	local-remote-host-notty and target board native-gdbserver I run into:
	...
	(gdb) info sharedlibrary^M
	From To    Syms Read   Shared Object Library^M
	$hex $hex  Yes         /lib64/ld-linux-x86-64.so.2^M
	$hex $hex  Yes         /home/remote-host/libinproctrace.so^M
	$hex $hex  Yes         /lib64/libm.so.6^M
	$hex $hex  Yes         /lib64/libc.so.6^M
	$hex $hex  Yes         /lib64/libdl.so.2^M
	$hex $hex  Yes (*)     /usr/lib64/libstdc++.so.6^M
	$hex $hex  Yes (*)     /lib64/libgcc_s.so.1^M
	$hex $hex  Yes         /lib64/libpthread.so.0^M
	(*): Shared library is missing debugging information.^M
	(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
	...
	due to trying to match libinproctrace.so using the target path, while the
	command lists it using the host path.

	Fix this by making the regexp less strict.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle remote host in gdb_load_shlib
	With test-case gdb.arch/ftrace-insn-reloc.exp and host board
	local-remote-host-notty and target board native-gdbserver I run into:
	...
	(gdb) tstart^M
	Target returns error code '.In-process agent library not loaded in process.  \
	  Fast and static trace points unavailable.'.^M
	(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
	...

	Fix this by:
	- handling remote host in gdb_load_shlib, and
	- moving the gdb_load_shlib to after the clean_restart, such that the
	  set solib-search-path can take effect.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/i386-biarch-core.exp for remote host
	Fix test-case gdb.arch/i386-biarch-core.exp using gdb_download_remote host.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle REMOTE_HOST_USERNAME in local-remote-host
	Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for
	REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.

	This helps to keep the home dir clean.

	Since the setup makes $build/gdb/testsuite on build unreadable for the remote
	host, we run into permission problems for GDB and the data-directory, so fix
	this (as was done for gdbserver in gdbserver-base.exp) using file normalize.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Set remotedir by default in some boards
	When doing a gdb_simple_compile, and downloading the resulting exec $obj
	to target the result $target_obj may be a relative file path, which may give
	problems when trying to do:
	...
	remote_exec target $target_obj
	...

	Fix/workaround this on some target boards by setting remotedir by default, and
	add a corresponding test in gdb.testsuite/board-sanity.exp.

	This doesn't work for host/target board local-remote-host-native, so xfail this.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix have_avx for remote target
	In proc have_avx we compile some source into an exec, resulting in a file $obj
	on build, and then attempt to execute it on target:
	...
	    set result [remote_exec target $obj]
	...

	Fix this by using gdb_remote_download target.

	Likewise in a few other procs that use "remote_exec target".

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle precise-aligned-alloc.c for remote host
	With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
	host board local-remote-host-notty and target board native-gdbserver I run
	into:
	...
	gdb compile failed, i386-sse.c:68:10: fatal error: \
	  ../lib/precise-aligned-alloc.c: No such file or directory
	 #include "../lib/precise-aligned-alloc.c"
	          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	...

	Fix this using '#include "precise-aligned-alloc.c"' and making that work with
	non-remote and remote host.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle remote host in escape_for_host
	With test-case gdb.arch/ftrace-insn-reloc.exp and host board
	local-remote-host-notty and target board native-gdbserver, I run into:
	...
	FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
	...
	due to having:
	...
	$ readelf -d ftrace-insn-reloc | grep RUNPATH
	 0x000000000000001d (RUNPATH)            Library runpath: []
	...
	instead of:
	...
	$ readelf -d ftrace-insn-reloc | grep RUNPATH
	 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
	...

	Handle this in escape_for_host.

	Tested on x86_64-linux.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add escape_for_host
	In gdb_compile we have:
	...
	           lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
	...
	and we could improve readability by using {} rather than "":
	...
	           lappend new_options {ldflags=-Wl,-rpath,\$ORIGIN}
	...

	But rather than manually adding escapes in a string, add a new proc
	escape_for_host that care of this for us, allowing us to write:
	...
	           lappend new_options [escape_for_host {ldflags=-Wl,-rpath,$ORIGIN}]
	...

	Tested on x86_64-linux.

2023-03-17  Alan Modra  <amodra@gmail.com>

	mach-o: out of memory in get_dynamic_reloc_upper_bound
		* mach-o.c (bfd_mach_o_canonicalize_dynamic_reloc): Move sanity
		checks..
		(bfd_mach_o_get_dynamic_reloc_upper_bound): ..to here.

	Another source_sh
		* scripttempl/z80.sc: Use source_sh to source elf.sc.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Declare ada unsupported for remote host
	Currently gdb_ada_compile doesn't support remote host.

	Make this explicit in allow_ada_tests.

	Tested on x86_64-linux.

2023-03-17  Jan Beulich  <jbeulich@suse.com>

	gas: apply md_register_arithmetic also to unary '+'
	Even a unary '+' has to be considered arithmetic; at least on x86 in
	Intel Syntax mode otherwise bogus insn operands may be accepted.
	Convert this specific case to binary + (i.e. 0 + <register>). (An
	implication is that md_operator(,1,) would need to deal with arch-
	specific equivalents of unary '+' is a similar way, if such an arch-
	specific variant would be specified in the first place.)

	To avoid duplicating what make_expr_symbol() does to construct a
	constant-zero expression, simply make its previously local variable a
	file-scope static one. This way there's also no need to invoke
	clean_up_expression().

2023-03-17  Jan Beulich  <jbeulich@suse.com>

	gas: expose flag_macro_alternate globally
	Yet again with the removal of gasp about 20 years ago this extra level
	of indirection isn't necessary anymore either. Drop macro.c's local
	variable and make as.c's global.

	While doing the conversion, switch the variable to "bool".

2023-03-17  Jan Beulich  <jbeulich@suse.com>

	gas: use flag_mri directly in macro processing
	Again with the removal of gasp about 20 years ago the extra level of
	indirection isn't necessary anymore. Drop macro.c's local variable and
	use the global flag directly.

	gas: isolate macro_strip_at to macro.c
	This removes a leftover from i960 support; with that nothing is left
	which would set macro_strip_at to non-zero, so the variable is converted
	to a #define (retaining the logic in case a new user would appear) and
	macro_init()'s respective parameter is dropped.

	gas: drop function pointer parameter from macro_init()
	With the removal of gasp (about 20 years ago) the need for this kind-
	of-hook has disappeared. Go a step beyond merely moving the to be called
	function: Inline its contents right at the sole call site.

2023-03-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix filename in gdb.debuginfod/crc_mismatch.exp
	After running test-case gdb.debuginfod/crc_mismatch.exp, I find a dir called '$':
	...
	$ ls $build/gdb/testsuite/
	$      config.log     gdb.log  lib       outputs   site.exp
	cache  config.status  gdb.sum  Makefile  site.bak  temp
	...

	Fix this by removing the stray '$' here:
	...
	set debugfile "$[standard_output_file ${testfile}.debug]"
	...

	Tested on x86_64-linux.

2023-03-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: extended documentation for inferior function calls
	I noticed that the documentation for inferior function calls doesn't
	say much about what happens if/when an inferior function call is
	interrupted, i.e. it doesn't describe what the dummy frame looks like
	on the stack, or how GDB behaves when the inferior is continued and
	reaches the dummy frame.

	This commit aims to add some of this missing information.

2023-03-16  Tom Tromey  <tromey@adacore.com>

	Fix build breakage in rs6000-aix-tdep.c
	A recent change to rs6000-aix-tdep.c broke the build.  This patch
	fixes it by declaring a few target descriptions in ppc-tdep.h and then
	not including the various features .c files in rs6000-aix-tdep.c.

2023-03-16  Hui Li  <lihui@loongson.cn>

	gdb/testsuite: Add support for LoongArch in gdb.base/float.exp
	The test results on LoongArch as follows:

	Without this patch:

	```
	$ make check-gdb TESTS="gdb.base/float.exp"
	=== gdb Summary ===

	 # of expected passes		2
	 # of unexpected failures	1

	```
	With this patch:

	```
	$ make check-gdb TESTS="gdb.base/float.exp"
	=== gdb Summary ===

	 # of expected passes		3

	```

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-16  Christophe Lyon  <christophe.lyon@linaro.org>

	Re: Add --enable-linker-version option
	The recently-added ld-version*.d tests expect
	.*GNU ld \(GNU Binutils\) 2.*
	in the .comment section.

	However, when buidling --with-pkgversion=XXX, we get
	GNU ld (XXX) 2.[...]
	instead, leading to a spurious FAIL.

	This small patch replaces "GNU Binutils" with ".*" instead.

	I inspected other testcases to see if we already had similar
	occurrences but I couldn't see any, so I hope this fix is OK for the
	purpose?

	Thanks,

	Christophe

2023-03-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: spring clean the Python unwinders documentation
	The documentation for the Python Unwinders API could do with some
	improvement.  The 'Unwinder Skeleton Code' has an error: it says
	'unwinders' when it should say 'unwinder' in one case.

	Additionally, by placing the 'Unwinder Skeleton Code' before the
	section 'Registering an Unwinder' we have skipping including the
	registration line in the skeleton code.  But this is confusion for
	users (I think) as the skeleton code is almost complete, except for
	one missing line which the user has to figure out for themselves.  By
	reordering the sections, it is now obvious that the registration
	should be included in the skeleton code, and the example is therefore
	almost complete.

	Additionally, in the example skeleton code the way in which the
	frame-id was being built (using the current stack point and program
	counter is (a) not correct, and (b) counter to what is laid out in the
	'Unwinder Input' section when describing building a frame-id.

	I've removed the incorrect code and replaced it with more generic
	comments indicating what needs to be done.  As the actual actions that
	need to be performed are both architecture specific, and dependent on
	the function being unwound, it's almost impossible to include more
	exact code here, but I think what I'm proposing is less misleading
	than what we had before.

	I've also added more cross references.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-03-16  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: disable ilp32 tests for aarch64-qnx
	aarch64nto32 emulation isn't supported. The tests will then fall back
	on aarch64elf32. It does work but some extra warnings are being
	generated because the "-z relro" being added aarch64nto but ignored by
	aarch64elf32 emulation.
	Skip the tests to avoid any problems.

	ld/ChangeLog:

	        * testsuite/ld-aarch64/emit-relocs-112-overflow.d: Skip for
	        aarch64nto.
	        * testsuite/ld-aarch64/emit-relocs-112.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-113.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-114-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-114.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-115.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-116-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-116.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-117.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-118-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-118.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-119.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-22.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-23.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-28.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-86-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-86.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-87.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-88-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-88.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-89.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-90-overflow.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-90.d: Likewise.
	        * testsuite/ld-aarch64/emit-relocs-92.d: Likewise.
	        * testsuite/ld-aarch64/tls-desc-ie-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-all-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-gd-ie-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-gd-le-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-gdesc-le-2-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-gdesc-le-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-ie-le-2-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-ie-le-3-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-ie-le-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-ld-le-small-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-relax-ld-le-tiny-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-tiny-desc-ie-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-tiny-desc-le-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-tiny-gd-ie-ilp32.d: Likewise.
	        * testsuite/ld-aarch64/tls-tiny-gd-le-ilp32.d: Likewise.

2023-03-16  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: add aarch64nto to ld-aarch64
	ld/ChangeLog:

	        * testsuite/ld-aarch64/aarch64-elf.exp: Add support for
	        aarch64nto.

2023-03-16  Clément Chigot  <chigot@adacore.com>

	ld: add support of QNX stack arguments for aarch64nto
	QNX is handling the stack argument using a .note section. Generate it
	according to ELF argument -zexecstack, -zstack-size and a new NTO
	argument --lazy-stack. Another NTO argument --stack mimicking
	-zstack-size is added in order to ensure compatibility with previously
	made NTO linkers.
	This requires a new emultempl nto.em which is applied above the default
	${ARCH}elf.em.

	ld/ChangeLog:

		* emulparams/aarch64nto.sh: Move to nto.em.
		* emultempl/nto.em: New file.
		* testsuite/ld-aarch64/aarch64-nto.exp: New test.
		* testsuite/ld-aarch64/nto-stack-note-1.d: New test.
		* testsuite/ld-aarch64/nto-stack-note-2.d: New test.
		* testsuite/ld-aarch64/start.s: New test.

2023-03-16  Clément Chigot  <chigot@adacore.com>

	readelf: add support for QNT_STACK note subsections
	QNX provides some .note subsections. QNT_STACK is the one controling
	the stack allocation.

	bfd/ChangeLog:

		* elf.c (BFD_QNT_CORE_INFO): Delete.
		(BFD_QNT_CORE_STATUS): Likewise.
		(BFD_QNT_CORE_GREG): Likewise.
		(BFD_QNT_CORE_FPREG): Likewise.
		(elfcore_grok_nto_note): Replace BFD_QNT_* by QNT_*.

	binutils/ChangeLog:

		* readelf.c (get_qnx_elfcore_note_type): New function.
		(print_qnx_note): New function.
		(process_note): Add support for QNX support.

	include/ChangeLog:

		* elf/common.h (QNT_DEBUG_FULLPATH): New define.
		(QNT_DEBUG_RELOC): New define.
		(QNT_STACK): New define.
		(QNT_GENERATOR): New define.
		(QNT_DEFAULT_LIB): New define.
		(QNT_CORE_SYSINFO): New define.
		(QNT_CORE_INFO): New define.
		(QNT_CORE_STATUS): New define.
		(QNT_CORE_GREG): New define.
		(QNT_CORE_FPREG): New define.
		(QNT_LINK_MAP): New define.

2023-03-16  Clément Chigot  <chigot@adacore.com>

	configure: add new target aarch64-*-nto*
	This target has its own ld emulation based on aarch64elf.em.

2023-03-16  Cupertino Miranda  <cupertino.miranda@oracle.com>

	BPF relocations review / refactoring
	- Removed not needed relocations.
	- Renamed relocations to match llvm and linux kernel.

	Relocation changes:
	  R_BPF_INSN_64 	=> R_BPF_64_64
	  R_BPF_INSN_DISP32 	=> R_BPF_64_32
	  R_BPF_DATA_32 	=> R_BPF_64_ABS32
	  R_BPF_DATA_64 	=> R_BPF_64_ABS64

	ChangeLog:

	  * bfd/bpf-reloc.def: Created file with BPF_HOWTO macro entries.
	  * bfd/reloc.c: Removed non needed relocations.
	  * bfd/bfd-in2.h: regenerated.
	  * bfd/libbfd.h: regenerated.
	  * bfd/elf64-bpf.c: Changed relocations.
	  * include/elf/bpf.h: Adapted relocation values/names.
	  * gas/config/tc-bpf.c: Changed relocation mapping.

2023-03-16  Alan Modra  <amodra@gmail.com>

	Re: Add --enable-linker-verssion
	Output sections without any input sections to initialise their flags
	have their flags initialised by data statements to LOAD, ALLOC,
	HAS_CONTENTS by default.  This is wrong for .comment.  Fix that by
	making the script initialise the section type to INFO, one of the
	noalloc section types.  That also allows the address of .comment to be
	set to zero, as is usual for non-alloc sections.

	Also, use source_sh for all of the sourced scripts to set up make
	dependencies.

		PR 30187
		* scripttempl/misc-sections.sc: Set .comment address to zero
		and type to INFO.
		* scripttempl/ft32.sc: Fix breakages from last edit.
		* scripttempl/arclinux.sc: Use source_sh to source DWARF.sc
		and misc-sections.sc.
		* scripttempl/avr.sc: Likewise.
		* scripttempl/dlx.sc: Likewise.
		* scripttempl/elf.sc: Likewise.
		* scripttempl/elf32cr16.sc: Likewise.
		* scripttempl/elf32crx.sc: Likewise.
		* scripttempl/elf32msp430.sc: Likewise.
		* scripttempl/elf64bpf.sc: Likewise.
		* scripttempl/elf64hppa.sc: Likewise.
		* scripttempl/elf_chaos.sc: Likewise.
		* scripttempl/elfarc.sc: Likewise.
		* scripttempl/elfarcv2.sc: Likewise.
		* scripttempl/elfd10v.sc: Likewise.
		* scripttempl/elfd30v.sc: Likewise.
		* scripttempl/elfm68hc11.sc: Likewise.
		* scripttempl/elfm68hc12.sc: Likewise.
		* scripttempl/elfm9s12z.sc: Likewise.
		* scripttempl/elfmicroblaze.sc: Likewise.
		* scripttempl/elfxgate.sc: Likewise.
		* scripttempl/elfxtensa.sc: Likewise.
		* scripttempl/epiphany_4x4.sc: Likewise.
		* scripttempl/i386beos.sc: Likewise.
		* scripttempl/i386go32.sc: Likewise.
		* scripttempl/ia64vms.sc: Likewise.
		* scripttempl/ip2k.sc: Likewise.
		* scripttempl/iq2000.sc: Likewise.
		* scripttempl/mep.sc: Likewise.
		* scripttempl/mmo.sc: Likewise.
		* scripttempl/nds32elf.sc: Likewise.
		* scripttempl/pru.sc: Likewise.
		* scripttempl/v850.sc: Likewise.
		* scripttempl/v850_rh850.sc: Likewise.
		* scripttempl/visium.sc: Likewise.
		* scripttempl/xstormy16.sc: Likewise.
		* scripttempl/z80.sc: Likewise.
		* testsuite/ld-scripts/ld-version-2.d: Don't skip ft32 or pru.

2023-03-16  Alan Modra  <amodra@gmail.com>

	cpu/mem.opc whitespace tidy
	cpu/
		* mep.opc: Whitespace and formatting.
	opcodes/
		* mep-asm.c: Regenerate.
		* mep-dis.c: Regenerate.

2023-03-16  Alan Modra  <amodra@gmail.com>

	PR30217, dynamic relocations using local dynamic symbols
	glibc's ld.so ignores local dynamic symbols.  It's been that way
	forever.  We therefore can't use them on dynamic relocations.  Fixing
	that problem uncovered another problem in sorting of dynamic relocs,
	caused no doubt by copying make_iplt_section (where we don't want
	reloc sorting by the generic gold function, we want iplt relocs last)
	to make_lplt_section (where we do want sorting).

		PR 30217
		* powerpc.cc (branch_needs_plt_entry): New function.
		(Target_powerpc::plt_off): Use it here..
		(Target_powerpc::Scan::global): ..and here to correct PLT16 reloc
		handling for forced-local global symbols.
		(Output_data_plt_powerpc::add_entry): Rename "stash"
		parameter "is_local".  Emit relative relocs for globals that
		are forced local, and don't set_needs_dynsym_entry.
		(Target_powerpc::make_lplt_section): Don't create a separate
		reloc section, use rela_dyn.
		(Target_powerpc::make_brlt_section): Likewise.

2023-03-16  Alan Modra  <amodra@gmail.com>

	Re: Sanity check read_section_stabs_debugging_info
		* rddbg.c (read_section_stabs_debugging_info): Don't segfault on
		zero size string section.

2023-03-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-15  Tom Tromey  <tromey@adacore.com>

	Fix formatting in gdb/printing.py
	According to black 23, gdb/printing.py was mis-formatted.  This patch
	fixes it.

2023-03-15  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Enable vector register visibility in core for AIX.
	This patch enables AIX folks to see vector register contents while they
	analyse the core file.

2023-03-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix re-used exec in gdb.arch/ftrace-insn-reloc.exp
	In test-case gdb.arch/ftrace-insn-reloc.exp we generate two executables with
	the same name, which is confusing and known to cause trouble.

	Fix this by making the executable names unique.

	Tested on x86_64-linux.

2023-03-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/amd64-stap-special-operands.exp for remote host
	With test-case gdb.arch/amd64-stap-special-operands.exp and host board
	local-remote-host-notty and target board native-gdbserver I run into:
	...
	(gdb) break -pstap three_arg^M
	No probe matching objfile=`<any>', provider=`<any>', name=`three_arg'^M
	Make breakpoint pending on future shared library load? (y or [n]) n^M
	(gdb) FAIL: gdb.arch/amd64-stap-special-operands.exp: probe: three_arg: \
	  gdb_breakpoint: set breakpoint at -pstap three_arg
	...
	due to compiling two executables with the same name, and when uploading the
	second one from host to build, we run into:
	...
	Upload from 127.0.0.1 failed, \
	  $outputs/gdb.arch/amd64-stap-special-operands/amd64-stap-special-operands: \
	  Text file busy.
	...

	Fix this by making the executable names unique.

	Tested on x86_64-linux.

2023-03-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/i386-pkru.exp for native-gdbserver
	With test-case gdb.arch/i386-pkru.exp and target board native-gdbserver we run
	into:
	...
	FAIL: gdb.arch/i386-pkru.exp: variable after reading pkru
	...

	This looks similar to the the problem for which there's already an xfail, so
	fix this by extending the xfail matching.

	Tested on x86_64-linux.

	Also tested on openSUSE Tumbleweed, where all tests in the test-case pass.

2023-03-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Unset DEBUGINFOD_URLS on remote host
	When running test-case gdb.arch/i386-pkru.exp with host board
	local-remote-host-notty and target board native-gdbserver on openSUSE
	Tumbleweed (with DEBUGINFOD_URLS set), I run into:
	...
	This GDB supports auto-downloading debuginfo from the following URLs:^M
	  <https://debuginfod.opensuse.org/>^M
	Enable debuginfod for this session? (y or [n]) ^CQuit^M
	(gdb) FAIL: gdb.arch/i386-pkru.exp: runto: run to main
	...

	The problem is that the unsetenv for DEBUGINFOD_URLS in default_gdb_init:
	...
	    # If DEBUGINFOD_URLS is set, gdb will try to download sources and
	    # debug info for f.i. system libraries.  Prevent this.
	    unset -nocomplain ::env(DEBUGINFOD_URLS)
	...
	doesn't work on remote host.

	Fix this by using "set debuginfod enabled off" for remote host.

	Tested on x86_64-linux.

2023-03-15  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.arch/amd64*.exp with local-remote-host-native.exp
	There's a number of gdb.arch/amd64*.exp test-cases that fail with host+target
	board local-remote-host-native.exp because of using a .S file, generated from
	a .c file.

	If a test-case compiles the .S file when executing on remote host,
	the .S file is already copied from build to host, such that it's available for
	the compiler.

	But that's not the case for the .c file, which is needed by gdb to show a
	source line:
	...
	(gdb) continue^M
	Continuing.^M
	^M
	Breakpoint 2, fn2 (y=y@entry=25, x=x@entry=6) at amd64-entry-value-inline.c:32^M
	32      in gdb.arch/amd64-entry-value-inline.c^M
	(gdb) FAIL: gdb.arch/amd64-entry-value-inline.exp: continue to breakpoint: \
	  break-here
	...

	Fix this by using "gdb_remote_download host <.c file>".

	Tested on x86_64-linux, with host+target board local-remote-host-native.

2023-03-15  Nick Clifton  <nickc@redhat.com>

	Add --enable-linker-version option to bfd linker to add an entry in the .comment section.
	   PR 30187
	  * NEWS: Mention the new feature. * ld.texi: Document the new feature. * ldgram.y: Handle LINKER_VERSION token. * ldlang.c (lang_add_version): New function. (enable_linker_version): New global variable. * ldlang.h (land_add_version): Prototype. (enable_linker_version): Export. * ldlex.h (OPTION_ENABLE_LINKER_VERSION): Define. (OPTION_DISABLE_LINKER_VERSION): Define. * ldlex.l (LINKER_VERSION): Add token. * lexsup.c (ld_options): Add --enable-linker-version and --disable-linker-version. (parse_args): Handle the new options. * scripttempl/arclinux.sc: Remove stabs and comment sections and replace with inclusion of misc-sections.sc * scripttempl/avr.sc: Likewise. * scripttempl/dlx.sc: Likewise. * scripttempl/elf.sc: Likewise. * scripttempl/elf32cr16.sc: Likewise. * scripttempl/elf32crx.sc: Likewise. * scripttempl/elf32msp430.sc: Likewise. * scripttempl/elf64bpf.sc: Likewise. * scripttempl/elf64hppa.sc: Likewise. * scripttempl/elf_chaos.sc: Likewise. * scripttempl/elfarc.sc: Likewise. * scripttempl/elfarcv2.sc: Likewise. * scripttempl/elfd10v.sc: Likewise. * scripttempl/elfd30v.sc: Likewise. * scripttempl/elfm68hc11.sc: Likewise. * scripttempl/elfm68hc12.sc: Likewise. * scripttempl/elfm9s12z.sc: Likewise. * scripttempl/elfmicroblaze.sc: Likewise. * scripttempl/elfxgate.sc: Likewise. * scripttempl/elfxtensa.sc: Likewise. * scripttempl/epiphany_4x4.sc: Likewise. * scripttempl/ft32.sc: Likewise. * scripttempl/ip2k.sc: Likewise. * scripttempl/iq2000.sc: Likewise. * scripttempl/mep.sc: Likewise. * scripttempl/nds32elf.sc: Likewise. * scripttempl/pru.sc: Likewise. * scripttempl/v850.sc: Likewise. * scripttempl/v850_rh850.sc: Likewise. * scripttempl/visium.sc: Likewise. * scripttempl/xstormy16.sc: Likewise. * scripttempl/z80.sc: Likewise. * testsuite/ld-scripts/script.exp: Run new tests. * scripttempl/misc-sections.sc: New file. * testsuite/ld-scripts/ld-version-2.d: New file. * testsuite/ld-scripts/ld-version.d: New file. * testsuite/ld-scripts/ld-version.t: New file.

	Fix an illegal memory access when disassembling a corrupt MeP file.
	  PR 30231
	  * mep.opc (mep_print_insn): Check for an out of range index.

	Fix an illegal memory access when disassebling a corrupt ARM file.
	  PR 30230
	  * arm-dis.c (get_sym_code_type): Check for non-ELF symbols.

2023-03-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Implement DAP variables, scopes, and evaluate requests
	The DAP code already claimed to implement "scopes" and "evaluate", but
	this wasn't done completely correctly.  This patch implements these
	and also implements the "variables" request.

	After this patch, variables and scopes correctly report their
	sub-structure.  This also interfaces with the gdb pretty-printer API,
	so the output of pretty-printers is available.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Hide the implementation of gdb_mpf
	This renames the data member of gdb_mpf and makes it private.  It also
	adds a single new method to aid in this change.  Unlike the earlier
	changes here, I did this one all together because gdb_mpf has very few
	uses.

	Rename gdb_mpq::val and make contents private
	This changes gdb_mpq to hide its data, and renames the data member
	from 'val' to 'm_val', following gdb convention.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Add operators and methods to gdb_mpq
	This adds some operators and methods to gdb_mpq, in preparation for
	making its implementation private.

	This only adds the operators currently needed by gdb.  More could be
	added as necessary.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Rename gdb_mpz::val and make contents private
	This changes gdb_mpz to hide its data, and renames the data member
	from 'val' to 'm_val', following gdb convention.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Add methods and operators to gdb_mpz
	This adds various methods and operators to gdb_mpz, as a step toward
	hiding the implementation.

	This only adds the operators that were needed.  Many more could be
	added as required.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Clean up gmp-utils.h includes
	gmp-utils.h includes "defs.h", but normally the rule in gdb is that
	the .c files include this first.  This patch changes this code to
	match the rest of gdb.

2023-03-14  Tom Tromey  <tromey@adacore.com>

	Fix DAP frame bug with older versions of Python
	Tom de Vries pointed out that one DAP test failed on Python 3.6
	because gdb.Frame is not hashable.

	This patch fixes the problem by using a list to hold the frames.  This
	is less efficient but there normally won't be that many frames.

	Tested-by: Tom de Vries <tdevries@suse.de>

2023-03-14  Nick Clifton  <nickc@redhat.com>

	Prevent an over large memory allocation in readelf when parsing a corrupt DWARF file.
	  PR 30227
	  * dwarf.c (process_cu_tu_index): Prevent excessive memory allocation when nused is large and ncols is zero.

2023-03-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.testsuite/board-sanity.exp
	Add a test-case that tests the sanity of target/host boards.

	It contains a number of tests related to remote file manipulation, exercising:
	- remote_upload
	- remote_download
	- remote_file exists
	- remote_file delete
	which check that these work together as expected.

	Tested on x86_64-linux, with all relevant gdb/testsuite/boards/*.exp boards.

	For target board remote-stdio-gdbserver.exp, this revealed a trivial problem
	with the return value of proc ${board}_file for delete, so fix this.

	The test-case shows that the proc ${board}_download in
	local-remote-host-native.exp is broken, so remove it.

	Likewise for board local-remote-host.exp, so remove proc ${board}_download and
	associated ${board}_file.

	Tested on x86_64-linux.

2023-03-14  Nick Clifton  <nickc@redhat.com>

	Adjust the decoded line output to fit into 80 columns.
	  PR 30216
	  * dwarf.c (display_debug_lines_decoded): Reduce space for filenames.
	  * testsuite/binutils-all/dw5.W: Adjust expected output.
	  * testsuite/binutils-all/objdump.WL: Adjust expected output.

	Fix assembler documentation regarding data directives.
	 PR 30206
	 * doc/as.texi (Pseudo Ops): Document that data directives such as .byte and .int are not intended for encoding instructions.

2023-03-14  Alan Modra  <amodra@gmail.com>

	objdump segfault after symbol table error
	This memcpy segfaults if symcount is -1 (=> syms is NULL).
	      memcpy (sorted_syms, symcount ? syms : dynsyms,
		      sorted_symcount * sizeof (asymbol *));

		* objdump.c (slurp_symtab): Don't leave symcount as -1 after
		an error.
		(slurp_dynamic_symtab): Likewise for dynsymcount.

2023-03-14  Alan Modra  <amodra@gmail.com>

	Sanity check read_section_stabs_debugging_info
		* rddbg.c (read_section_stabs_debugging_info): Exclude sections
		without contents.  Use bfd_malloc_and_get_section.  Don't alloc
		one extra for strings.

	gas/read.c: init more statics
		* read.c (current_name, current_label, dwarf_file, dwarf_line): Move
		to file scope.
		(pobegin): Tidy pop_override_ok.
		(read_a_source_file): Make last_eol an auto var.
		(s_reloc): Constify bfd_relocs.
		(read_begin): Init more variables.

2023-03-14  Alan Modra  <amodra@gmail.com>

	gas .include and .incbin
	This fixes a bug in .include and .incbin where given an absolute path
	the -I dirs would be searched for the path.

		* read.c (include_dir_count, include_dir_maxlen): Make them size_t.
		(search_and_open): New function.
		(s_incbin, s_include): Use search_and_open.
		(init_include_dir): New function.
		(add_include_dir): Don't set initial "." dir here.
		* read.h (include_dir_count, include_dir_maxlen): Update.
		(init_include_dir, search_and_open): Declare.
		* as.c (gas_early_init): Call init_include_dir.
		* config/tc-rx.c (rx_include): Avoid warning by using size_t.
		* config/tc-tic54x.c (tic54x_set_default_include): Simplify and
		use notes for include path.
		(tic54x_mlib): Use search_and_open.

2023-03-14  Alan Modra  <amodra@gmail.com>

	gas/dwarf2dbg.c init more statics
		* dwarf2dbg.c (dw2_line, dw2_filename): Move to file scope and..
		(dwarf2_gen_line_info): ..renamed from here.
		(label_num, last_used, last_used_dir_len): Move to file scope.
		(dwarf2_init): Init moved statics, except last_used_dir_len.

2023-03-14  Alan Modra  <amodra@gmail.com>

	gas/ecoff.c: don't use zero struct copies to init
	It might have made sense once upon a time, but doesn't nowadays when
	compilers expand memset inline.

		* ecoff.c (add_aux_sym_tir, allocate_scope, allocate_vlinks),
		(allocate_shash, allocate_thash, allocate_tag, allocate_forward),
		(allocate_thead, allocate_lineno_list): Use memset rather than
		copying zero struct.

2023-03-14  Alan Modra  <amodra@gmail.com>

	gas/compress-debug.c init all of strm
		* compress-debug.c (compress_init): Clear all of strm.

2023-03-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb: add gdbarch::displaced_step_buffer_length
	The gdbarch::max_insn_length field is used mostly to support displaced
	stepping; it controls the size of the buffers allocated for the
	displaced-step instruction, and is also used when first copying the
	instruction, and later, when fixing up the instruction, in order to
	read in and parse the instruction being stepped.

	However, it has started to be used in other places in GDB, for
	example, it's used in the Python disassembler API, and it is used on
	amd64 as part of branch-tracing instruction classification.

	The problem is that the value assigned to max_insn_length is not
	always the maximum instruction length, but sometimes is a multiple of
	that length, as required to support displaced stepping, see rs600,
	ARM, and AArch64 for examples of this.

	It seems to me that we are overloading the meaning of the
	max_insn_length field, and I think that could potentially lead to
	confusion.

	I propose that we add a new gdbarch field,
	gdbarch::displaced_step_buffer_length, this new field will do
	exactly what it says on the tin; represent the required displaced step
	buffer size.  The max_insn_length field can then do exactly what it
	claims to do; represent the maximum length of a single instruction.

	As some architectures (e.g. i386, and amd64) only require their
	displaced step buffers to be a single instruction in size, I propose
	that the default for displaced_step_buffer_length will be the
	value of max_insn_length.  Architectures than need more buffer space
	can then override this default as needed.

	I've updated all architectures to setup the new field if appropriate,
	and I've audited all calls to gdbarch_max_insn_length and switched to
	gdbarch_displaced_step_buffer_length where appropriate.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdbarch: make invalid=True the default for all Components
	This commit switches the default value for the 'invalid' field from
	False to True.  All components that previous set the invalid field to
	True explicitly have had the field removed.

	I think that True is a good choice for the default, this means that we
	now get the validity checks by default, and if anyone adds a new
	Component they need to make a choice to add an 'invalid=False' line
	and disable the validation.

	The flip side of this is that 'invalid=False' seems to be far more
	common than 'invalid=True'.  But I don't see a huge problem with this,
	we shouldn't be aiming to reduce our typing, rather we should choose
	based on which is least likely to introduce bugs.  I think assuming
	that we should do a validity check will achieve that.

	Some additional components need to have an 'invalid=False' line added
	to their definition, these are components that have a predefault
	value, which is sufficient; the tdep code doesn't need to replace this
	value if it doesn't want to.

	Without adding the 'invalid=False' these components would be
	considered to be invalid if they have not changed from their
	predefault value -- but the predefault is fine.

	There's no change in the generated code after this commit, so there
	will be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdbarch: remove some unneeded predefault="0" from gdbarch_components.py
	I noticed that there are a bunch of 'predefault="0"' lines in
	gdbarch_components.py, and that some (just some, not all) of these are
	not needed.

	The gdbarch is already zero initialized, but these lines seem to
	exists so that we can know when to compare against "0" and when to
	compare against "NULL".  At least, this seems to be useful in some
	places in the generated code.

	Specifically, if we remove the predefault="0" line from the
	max_insn_length component then we end up generating a line like:

	  gdb_assert (gdbarch->max_insn_length != NULL);

	which doesn't compile as we compare a ULONGEST to NULL.

	In this commit I remove all the predefault="0" lines that I claim are
	obviously not needed.  These are lines for components that are not
	Values (i.e. the component holds a function pointer anyway), or for
	Value components that hold a pointer type, in which case using NULL is
	fine.

	The only changes after this commit are some fields that have nullptr
	as their initial value, and gcore_bfd_target now compares to NULL not
	0 in gdbarch_gcore_bfd_target_p, which, given the field is of type
	'const char *', seems like an improvement.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdbarch: improve generation of validation in gdbarch getters
	We currently generate some validation code within the gdbarch getter
	methods.

	This commit adjusts the algorithm used to generate this validation
	slightly to make the gdbarch.py code (I think) clearer; there's no
	significant changes to what is generated.

	The validation algorithm for gdbarch values is now:

	  - If the Value has an 'invalid' field that is a string, use that for
	    validation,

	  - If the Value has its 'predicate' field set to true, then check the
	    predicate returns true, this ensures the predicate has been
	    called,

	  - If the Value has its 'invalid' field set to True, or the Value has
	    'postdefault' field, then check the fields has changed from its
	    initial value,

	  - Otherwise no validation is performed.

	The only changes after this commit are:

	  - Some comments change slightly, and

	  - For 'gcore_bfd_target' and 'max_insn_length' we now validate by
	    calling the predicate rather than checking the field value
	    directly, the underlying check being performed is unchanged
	    though.

	There should be no user visible changes after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdbarch: use predefault for more value components within gdbarch
	For some reason the following value components of gdbarch:

	  bfloat16_format
	  half_format
	  float_format
	  double_format
	  long_double_format
	  so_ops

	All use a postdefault but no predefault to set the default value for
	the component.

	As the postdefault values for these components are all constant
	pointers that don't depend on other fields within the gdbarch, then I
	don't see any reason why we couldn't use a predefault instead.

	So lets do that.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py
	This commit ensures that the 'invalid' property of all components is
	either True, False, or a string.

	Additionally, this commit allows a component to have both a predicate
	and for the 'invalid' property to be a string.

	Removing the option for 'invalid' to be None allows us to simplify the
	algorithms in gdbarch.py a little.

	Allowing a component to have both a predicate and an 'invalid' string
	means that we can validate the value that a tdep sets into a field,
	but also allow a predicate to ensure that the field has changed from
	the default.

	This functionality isn't going to be used in this series, but I have
	tested it locally and believe that it would work, and this might make
	it easier for others to add new components in the future.

	In gdbarch_types.py, I've updated the type annotations to show that
	the 'invalid' field should not be None, and I've changed the default
	for this field from None to False.

	The change to using False as the default is temporary.  Later in this
	series I'm going to change the default to True, but we need more fixes
	before that can be done.

	Additionally, in gdbarch_types.py I've removed an assert from
	Component.get_predicate.  This assert ensured that we didn't have the
	predicate field set to True and the invalid field set to a string.
	However, no component currently uses this configuration, and after
	this commit, that combination is now supported, so the assert can be
	removed.

	As a consequence of the gdbarch_types.py changes we see some
	additional comments generated in gdbarch.c about verification being
	skipped due to the invalid field being False.  This comment is inline
	with plenty of other getters that also have a similar comment.  Plenty
	of the getters do have validation, so I think it is reasonable to have
	a comment noting that the validation has been skipped for a specific
	reason, rather than due to some bug.

	In gdbarch_components.py I've had to add 'invalid=True' for two
	components: gcore_bfd_target and max_insn_length, without this the
	validation in the gdbarch getter would disappear.

	And in gdbarch.py I've reworked the logic for generating the
	verify_gdbarch function, and for generating the getter functions.

	The logic for generating the getter functions is still not ideal,  I
	ended up having to add this additional logic block:

	  elif c.postdefault is not None and c.predefault is not None:
	      print("  /* Check variable changed from pre-default.  */", file=f)
	      print(f"  gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f)

	which was needed to ensure we continued to generate the same code as
	before, without this the fact that invalid is now False when it would
	previously have been None, meant that we dropped the gdb_assert in
	favour of a comment like:

	  print(f"  /* Skip verify of {c.name}, invalid_p == 0 */", file=f)

	which is clearly not a good change.  We could potentially look at
	improving this in a later commit, but I don't plan to do that in this
	series.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbarch: split postdefault setup from invalid check in gdbarch.py
	Restructure how gdbarch.py generates the verify_gdbarch function.
	Previously the postdefault handling was bundled together with the
	validation.  This means that a field can't have both a postdefault,
	and set its invalid attribute to a string.

	This doesn't seem reasonable to me, I see no reason why a field can't
	have both a postdefault (used when the tdep doesn't set the field),
	and an invalid expression, which can be used to validate the value
	that a tdep might set.

	In this commit I restructure the verify_gdbarch generation code to
	allow the above, there is no change in the actual generated code in
	this commit, that will come in later commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbarch: remove yet more 'invalid=True' from gdbarch_components.py
	Following on from the previous commit, this commit removes yet more
	'invalid=True' lines from gdbarch_components.py where the invalid
	setting has no effect.

	Due to the algorithm used in gdbarch.py for generated verify_gdbarch,
	if a component has a postdefault value then no invalid check will ever
	be generated for the component, as such setting 'invalid=True' on the
	component is pointless.  This commit removes the setting of invalid.

	There is no change in the generated code after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/gdbarch: remove unused 'invalid=True' from gdbarch_components.py
	Due to the algorithm used to generate verify_gdbarch in gdbarch.py, if
	a component has a predicate, then a validation check will never be
	generated.

	There are a bunch of components that are declared with both a
	predicate AND have 'invalid=True' set.  The 'invalid=True' has no
	effect.

	In this commit I clean things up by removing all these additional
	'invalid=True' lines.  There's no change in any of the generated files
	after this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-13  Tom Tromey  <tromey@adacore.com>

	Fix crash in inside_main_func
	gdb 13.1 crashes while running the rust compiler's debugger tests.
	The crash has a number of causes.

	First, the rust compiler still uses the C++-like _Z mangling, but with
	its own twist -- some hex digits added to the end of a symbol.  So,
	while gdb finds the correct name of "main":

	(top-gdb) p name
	$13 = 0x292e0c0 "rustc_gdb_1031745::main"

	It isn't found in the minsyms, because C++ demangling yields:

	[99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text  rustc_gdb_1031745::main::h5b5be7fe16a97225  zko06yobckx336v

	This could perhaps be fixed.  I also filed a new PR to suggest
	preferring the linkage name of the main program.

	Next, the rust compiler emits both a DW_TAG_subprogram and a
	DW_TAG_namespace for "main".  This happens because the file is named
	"main.rs" -- i.e., the bug is specific to the source file name.  The
	crash also seems to require the nested function inside of 'main', at
	least for me.  The namespace always is generated, but perhaps this
	changes the ordering in the DWARF.

	When inside_main_func looks up the main symbol, it finds the namespace
	symbol rather than the function.  (I filed a bug about fixing gdb's
	symbol tables -- long overdue.)

	Meanwhile, as I think it's important to fix this crash sooner rather
	than later, this patch changes inside_main_func to check that the
	symbol that is found is LOC_BLOCK.  This perhaps should have been done
	in the first place, anyway.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30158

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/tui-window-factory.exp for remote host
	When running gdb.python/tui-window.exp with host board
	local-remote-host-notty and target board native-gdbserver, I get:
	...
	FAIL: gdb.python/tui-window-factory.exp: msg_2: \
	  check test_window box (box check: ul corner is l, not +)
	...

	The problem is that the result of Term::prepare_for_tui is not checked.

	Fix this by adding the missing check.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/tui-window.exp for remote host
	When running gdb.python/tui-window.exp with host board
	local-remote-host-notty and target board native-gdbserver, I get:
	...
	UNSUPPORTED: gdb.python/tui-window.exp: TUI not supported
	FAIL: gdb.python/tui-window.exp: test title
	...

	Fix this by adding the missing return after the unsupported.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/completion.exp for local-remote-host-notty
	When running test-case gdb.tui/completion.exp with host board
	local-remote-host-notty and target board native-gdbserver, I get:
	...
	FAIL: gdb.tui/completion.exp: completion of layout names: \
	  tab completion (timeout)
	...

	The test-case contains a few tests that do tab completion, which requires
	readline, which is unavailable with host board local-remote-host-notty.

	Fix this by adding the missing check for readline_is_used.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/tui-layout.exp for remote host
	When running test-case gdb.tui/tui-layout.exp with host board
	local-remote-host-notty and target board native-gdbserver, I get:
	...
	FAIL: gdb.tui/tui-layout.exp: terminal=dumb: execution=false: layout=asm: \
	  layout asm (timeout)
	...

	The problem is that the test-case expects that the default "setenv TERM dumb"
	has effect, which is not the case for remote host.

	Fix this by skipping the test for remote host.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.tui/tui-nl-filtered-output.exp for remote host
	When running test-case gdb.tui/tui-nl-filtered-output.exp with host board
	local-remote-host-notty and target board native-gdbserver, I get:
	...
	FAIL: gdb.tui/tui-nl-filtered-output.exp: check printf output
	...

	The problem is that Term::enter_tui is returning 0, but the test-case doesn't
	check for this, and consequently runs unsupported tests.

	Fix this by adding the missing check.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require ![is_remote host] for TUI
	When running test-case gdb.tui/corefile-run.exp with both host and target board
	local-remote-host-native.exp, we run into:
	...
	FAIL: gdb.tui/corefile-run.exp: load corefile
	...
	while this passes with USE_TUI=0.

	The problem is that the TUI setup code uses "setenv TERM ansi", which has no
	effect on remote host.

	I can confirm this analysis by working around this problem in
	local-remote-host-native.exp like this:
	...
	-    spawn $RSH -t -l $username $remote $cmd
	+    spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
	...

	For now, simply make TUI unsupported for remote host, by returning 0 in
	prepare_for_tui.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Handle USE_TUI in gdb.tui/corefile-run.exp
	Once in a while I find myself rewriting a TUI test-case into a non-TUI
	test-case, to better understand whether the problem I'm looking at is
	related to the TUI or not.

	I've got the impression that I've done this sufficiently often that it's worth
	committing the non-TUI version, so having just written a non-TUI version of
	gdb.tui/corefile-run.exp, let's commit it.

	The non-TUI version can be enabled by doing:
	...
	$ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0"
	...

	Also remove hard-coding of a source line number.

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix untested message in gdb.tui/corefile-run.exp
	In test-case gdb.tui/corefile-run.exp, we have this bit:
	...
	require !use_gdb_stub
	if { [target_info gdb_protocol] == "extended-remote" } {
	    untested "not supported"
	    return
	}
	...

	So with target board native-gdbserver we get:
	...
	UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
	...
	and with target board native-extended-gdbserver instead:
	...
	UNTESTED: gdb.tui/corefile-run.exp: not supported
	...

	Fix this by:
	- adding an optional argument target_description to proc
	  target_can_use_run_cmd
	- handling the target_description == core &&
	  [target_info gdb_protocol] == "extended-remote" case in the proc
	- using require {target_can_use_run_cmd core}
	such that now in both cases we have:
	...
	UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
	  target_can_use_run_cmd core
	...

	Tested on x86_64-linux.

2023-03-13  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/step-bg-decr-pc-switch-thread.exp for native-gdbserver
	With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board
	native-gdbserver, I run into:
	...
	(gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \
	  switch to main thread
	Remote debugging from host ::1, port 43914^M
	monitor exit^M
	Cannot execute this command while the target is running.^M
	Use the "interrupt" command to stop the target^M
	and then try again.^M
	(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
	...

	Fix this by following the advice and issuing an interrupt command, allowing
	the following monitor exit command to succeed.

	Tested on x86_64-linux.

2023-03-13  Bruno Larsen  <blarsen@redhat.com>

	[gdb/obvious]: fix python formatting for test gdb.python/py-typeprint.py
	python black formatter was complaining about the formatting of
	gdb.python/py-typeprint.py, so this commit corrects it.

2023-03-13  Bruno Larsen  <blarsen@redhat.com>

	gdb/testsuite: add regression test for per-objfile typeprinters
	PR python/17136 reported an unhandled exception when using typeprinters
	only valid on some objfiles, rather than being a global typeprinter. The
	fix was accepted without a regression test, and we've been carrying one
	out-of-tree for a while but I think it's worth upstreaming. The code
	itself was developed by Jan Kratochvil.

	Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>

2023-03-13  Tom Tromey  <tromey@adacore.com>

	Remove dead code from scalar_binop
	scalar_binop has code for "&&" and "||", but I think this code can't
	currently be run -- and, furthermore, it doesn't make sense to have
	this code here, as the point of these operators is to short-circuit
	evaluation.

	This patch removes the dead code.

	Regression tested on x86-64 Fedora 36.

	Approved-by: Kevin Buettner <kevinb@redhat.com>

2023-03-13  Luis Machado  <luis.machado@arm.com>

	aarch64: Expand documentation of XML features
	Similar to the arm target documentation situation, the documentation of the
	XML features for AArch64 targets is rather brief.  I have received the same
	feedback that what gdb carries in the documentation is quite unclear from the
	perspective of what debugging servers should define in the XML features, how and
	what the outcome is in gdb.

	This patch attempts to clarify a bit more what all the possible features are.

2023-03-13  Luis Machado  <luis.machado@arm.com>

	arm: Expand documentation of XML features
	The documentation of the XML features for Arm targets is very brief.  I have
	received feedback saying it is quite unclear from the perspective of the
	debugging servers what should be defined in the XML features, how and
	what the outcome is in gdb.

	This patch attempts to clarify a bit more what all the possible features are.

2023-03-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-11  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix the Dwarf reader
	gprofng/ChangeLog
	2023-03-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		gprofng/src/DwarfLib.cc (DwrLineRegs::getPath): Add a DW_AT_comp_dir
		string if the directoty table has relative names.

2023-03-11  Tom Tromey  <tom@tromey.com>

	Change linetable_entry::is_stmt to bool
	This changes linetable_entry::is_stmt to type bool, rather than
	unsigned.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-11  Tom Tromey  <tom@tromey.com>

	Remove extra scopes from objfile_relocate1
	objfile_relocate1 introduces new scopes that aren't necessary.  I
	noticed this while working on an earlier patch in this series.  This
	patch removes these.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-11  Tom Tromey  <tom@tromey.com>

	Constify linetables
	Linetables no longer change after they are created.  This patch
	applies const to them.

	Note there is one hack to cast away const in mdebugread.c.  This code
	allocates a linetable using 'malloc', then later copies it to the
	obstack.  While this could be cleaned up, I chose not to do so because
	I have no way of testing it.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-11  Tom Tromey  <tom@tromey.com>

	Change linetables to be objfile-independent
	This changes linetables to not add the text offset to the addresses
	they contain.  I did this in a few steps, necessarily combined
	together in one patch: I renamed the 'pc' member to 'm_pc', added the
	appropriate accessors, and then recompiled.  Then I fixed all the
	errors.  Where possible I generally chose to use the raw_pc accessor,
	as it is less expensive.

	Note that this patch discounts the possibility that the text section
	offset might cause wraparound in the addresses in the line table.
	However, this was already discounted -- in particular,
	objfile_relocate1 did not re-sort the table in this scenario.  (There
	was a bug open about this, but as far as I can tell this has never
	happened, it's not even clear what inspired that bug.)

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-11  Tom Tromey  <tom@tromey.com>

	Add operator< and operator== to linetable_entry
	This adds a couple of comparison operators to linetable_entry, and
	simplifies both the calls to sort and one other spot that checks for
	equality.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: PR30195 [display text] Source code location can not be found
	gprofng/ChangeLog
	2023-03-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30195
		gprofng/src/DwarfLib.cc (DwrLineRegs::reset): Set 'file = 1;'.

2023-03-10  John Baldwin  <jhb@FreeBSD.org>

	PR gdb/30214: Prefer local include paths to system include paths
	Some systems may install binutils headers into a system location
	(e.g. /usr/local/include on FreeBSD) which may also include headers
	for other external packages used by GDB such as zlib or zstd.  If a
	system include path such as /usr/local/include is added before local
	include paths to directories within a clone or release tarball, then
	headers from the external binutils package are used which can result
	in build failures if the external binutils package is out of sync with
	the version of GDB being built.

	To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
	for "local" componenets before external components.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-10  Fangrui Song  <maskray@google.com>

	ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)
	Similar to d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274 for x86_64.

	_Thread_local int a;
	int main() { return a; }

	% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
	/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
	/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
	collect2: error: ld returned 1 exit status

	This commit fixes the issue.

	There is an argument that the -fno-plt TLS sequence was added after
	R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
	intended to be unsupported.

	Unfortunately this standpoint has caused interop difficulty: some
	projects specify -mrelax-relocations=no to build relocatable object
	files compatible with older linkers (e.g.
	https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
	(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
	today).  Many uses have not been cleaned up in practice, and compiling
	with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
	error which is hard to reason about.

	It seems easier to apply this simple change to prevent the footgun.

	    PR ld/24784
	    * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.

2023-03-10  Fangrui Song  <maskray@google.com>

	ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)
	_Thread_local int a;
	int main() { return a; }

	% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
	/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
	/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
	collect2: error: ld returned 1 exit status

	This commit fixes the issue.

	There is an argument that the -fno-plt TLS sequence was added after
	R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
	intended to be unsupported.

	Unfortunately this standpoint has caused interop difficulty: some
	projects specify -mrelax-relocations=no to build relocatable object
	files compatible with older linkers (e.g.
	https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
	(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
	today).  Many uses have not been cleaned up in practice, and compiling
	with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
	error which is hard to reason about.

	There is another argument which may be weaker but relevant to the
	necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
	likely need some assembler support to disable relaxation.  Without the
	support and if the compiler needs to support many gas version, the
	simplest solution would be to use -Wa,-mrelax-relocations=no.

	    PR ld/24784
	    * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
	      R_X86_64_GOTPCREL.

2023-03-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-completion.exp
	With test-case gdb.python/py-completion.exp and target board
	native-extended-gdbserver I get this warning:
	...
	(gdb) PASS: gdb.python/py-completion.exp: discard #2
	completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
	  PASS: gdb.python/py-completion.exp: completefilecommandcond completion
	Remote debugging from host ::1, port 53346^M
	monitor exit^M
	not implemented^M
	(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
	...

	Fix this by adding the missing "discard #3", such that we have instead:
	...
	(gdb) PASS: gdb.python/py-completion.exp: discard #2
	completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
	  PASS: gdb.python/py-completion.exp: completefilecommandcond completion
	 ^M
	not implemented^M
	(gdb) PASS: gdb.python/py-completion.exp: discard #3
	Remote debugging from host ::1, port 36278^M
	monitor exit^M
	(gdb)
	...

	Tested on x86_64-linux.

2023-03-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-cmd.exp
	[ Using $pp as shorthand for the pagination prompt
	"--Type <RET> for more, q to quit, c to continue without paging--". ]

	The test-case gdb.python/py-cmd.exp passes, but the handling of the
	test_multiline command output looks a bit odd:
	...
	(gdb) test_multiline
	test_multiline output
	  ...
	test_multiline output
	$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
	q
	test_multiline
	Quit
	(gdb) test_multiline
	test_multiline output
	  ...
	test_multiline output
	$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
	...

	What happens is:
	- a test_multiline command is issued
	- some output is printed, followed by a pagination prompt
	- the test-case concludes that pagination occurred, and produces a PASS
	- "q\n" is replied to the pagination prompt
	- without waiting for response to the "q\n", another test_multiline command is
	  issued
	- in response to the "q\n" we get "Quit\n(gdb) "
	- some output is printed, followed by a pagination prompt
	- the test-case concludes that there's a valid response to the "q\n", and
	  produces a PASS, consuming the second pagination prompt, but without a reply.

	My conclusion is that the second test_multiline command is unintentional, so fix
	this by removing it.

	Without it, we have the more straightforward:
	...
	(gdb) test_multiline
	test_multiline output
	  ...
	test_multiline output
	$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
	q
	Quit
	(gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
	...

	This also fixes the following warning with target board native-gdbserver:
	...
	WARNING: Timed out waiting for EOF in server after monitor exit
	...

	Tested on x86_64-linux.

2023-03-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix py-autoloaded-pretty-printers-in-newobjfile-event.exp for remote target
	With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp
	and target board remote-gdbserver-on-localhost, I run into:
	...
	FAIL: $exp: runto: run to main
	...

	I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into:
	...
	(gdb) print all_good^M
	$1 = false^M
	(gdb) FAIL: $exp: print all_good
	info pretty-printer^M
	...

	Sysroot is set to "target:", so gdb downloads the shared library from the target
	(Using $so as shorthand for
	libpy-autoloaded-pretty-printers-in-newobjfile-event.so):
	...
	Reading /home/remote-target/$so from remote target...^M
	...
	and internally refers to it as "target:/home/remote-target/$so".

	In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts
	for $so once it checks for is_target_filename.

	Fix this by declaring auto-load unsupported if sysroot starts with "target:".

	Tested on x86_64-linux.

2023-03-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-event-load.exp for remote target
	Fix test-case gdb.python/py-event-load.exp for target board
	remote-gdbserver-on-localhost using gdb_download_shlib.

	Tested on x86_64-linux.

2023-03-10  Tom Tromey  <tom@tromey.com>

	Use require with test_compiler_info
	One spot that checks test_compiler_info can be switched to use
	'require'.

	More uses of require with istarget
	I found a few more spots that check istarget that can be switched to
	use 'require'.

	Use require with gdb_skip_stdio_test
	One use of gdb_skip_stdio_test can use 'require'.

	Use require with target_info
	This changes many tests to use 'require' when checking target_info.
	In a few spots, the require is hoisted to the top of the file, to
	avoid doing any extra work when the test is going to be skipped
	anyway.

2023-03-10  Tom Tromey  <tromey@adacore.com>

	Move allocate_stub_method to stabsread.c
	allocate_stub_method is only called from stabsread.c, and I don't
	think it will be needed anywhere else.  So, move it and make it
	static.  Tested by rebuilding.

2023-03-10  Alan Modra  <amodra@gmail.com>

	Revert ld ASCII support
	Revert "Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant."
	This reverts commit adbe951fc95943016325af08d677f18e8c177ac1.

	Revert "ld test asciz and ascii fails"
	This reverts the ascii.d part of commit 5f497256bee624f0fa470949aa41534093bc5b25.

	Revert "Add support for the ASCII directive inside linker scripts."
	This mostly reverts commit 9fe129a4105bb59398f73ce96938a94f19265b79
	leaving the asciz.d and asciz.t changes in place.

2023-03-10  Alan Modra  <amodra@gmail.com>

	Revert ld DIGEST support
	This is a hopefully temporary reversion of new ld features for
	embedded processors by Ulf Samuelsson, plus some followup patches.

	Squashed together from the following:

	Revert "lddigest 32-bit support and gcc-4 compile errors"
	This reverts commit d7ee19be87110a8f5342cec6e323d83d01c641d1.

	Revert "ld: Use correct types for crc64 calculations"
	This reverts commit 9a534b9f8e3d0f3cdb5a20f19ff165693fbb84d2.

	Revert "Re: DIGEST: testsuite"
	This reverts commit c8e85484d8a0fe9f7b88e00a6b9ae63bcb53ba32.

	Revert "Regen potfiles"
	This reverts commit 4d98c966f8bf305ab25badd34cb295631873cf7c.

	Revert "DIGEST: Makefile.*"
	This reverts commit 78ef6ab03f56ce83a606d974bb8a9f34b5d6e0b7.

	Revert "DIGEST: calculation"
	This reverts commit 5243990191e683d5066d3dd622c76deaba0bf15c.

	Revert "DIGEST: ldlang.*: add timestamp"
	This reverts commit bd9466d4aa277a469a9d8b12f0a6e6fa51678e36.

	Revert "DIGEST: ldmain.c"
	This reverts commit c8f8653fa7eeb3dc0769ac23039eadb5c5f09dff.

	Revert "DIGEST: ldgram.y"
	This reverts commit d73c01be2669e9c5267fab669a269f95a32048c9.

	Revert "DIGEST: ldlex.l"
	This reverts commit 48b5163a9dd5759cc87171331bbd6e902c547b5a.

	Revert "DIGEST: testsuite"
	This reverts commit a4135d1a4886400ea29af2da782dd8dd40ccad23.

	Revert "DIGEST: Documentation"
	This reverts commit 3ec28966c3e4c63704212778f96c517cbf2e0090.

	Revert "DIGEST: NEWS"
	This reverts commit 099bf2927d446424e8585a60cf4ce63209999aa2.

	Revert "DIGEST: LICENSING"
	This reverts commit 5c8a0c6654fb55926985edf3b360b62d4f20691d.

2023-03-10  Jan Beulich  <jbeulich@suse.com>

	Arm64/gas: drop redundant feature prereqs
	Logic exists to deal with prereqs or prereqs, and in many cases
	transitive prereqs are already not spelled out explicitly. Drop further
	ones:
	- FP is already a prereq to F16,
	- SIMD and F16 are already prereqs to COMPNUM, and
	- SVE2 and BFLOAT16 are already prereqs to SME.

	Arm64/gas: add missing prereq features
	A number of newer features are really SIMD or FP extensions, but don't
	have this properly specified.

	x86: decouple broadcast type and bytes fields
	Keep both representing exclusively what was parsed from input, to avoid
	the need for (potentially bogus) calculations when processing .insn.

	x86-64: adjust REX-prefix part of SSE2AVX test
	Before altering how build_modrm_byte() works, arrange for this part of
	the testcase to actually use distinguishable source and destination
	register numbers, such that incorrect propagation of, in particular, the
	high bit encodings (from REX to VEX) can be noticed (in turn
	specifically assertions [not] triggering in the respective code).

2023-03-10  Jan Beulich  <jbeulich@suse.com>

	x86: move more disp processing out of md_assemble()
	Put it in optimize_disp() such that it can then be re-used by .insn
	handling. The movement makes it necessary (or at least very desirable,
	to avoid introducing a fragile cast) to convert to local variable to
	"unsigned", which in turn requires an adjustment to the pre-existing
	loop header.

	Having the caller pass in the specific template under consideration has
	another benefit then: We can replace the two uses of current_templates
	in the function as well, thus no longer looking at some merely "related"
	template. (This may allow further tightening, but if so that's to be the
	subject of another change.)

2023-03-10  Jan Beulich  <jbeulich@suse.com>

	x86: use set_rex_vrex() also for short-form handling
	This is benign for all existing insns, but is going to be needed for
	handling of .insn operands. The earlier use requires moving up the
	function, to avoid the need for a forward declaration.

2023-03-10  Alan Modra  <amodra@gmail.com>

	eh static data
	Fix another case of oss-fuzz tripping over gas static state,
	ie. starting over testing another input file with rubbish left
	uncleared in bss.  size_end_sym pointed at garbage.

		* ehopt.c (get_cie_info): Delete forward declaration.
		(struct frame_data): Move to file scope.
		(frame): New static, packaged..
		(check_eh_frame): ..eh_frame_data and debug_frame_data.
		(eh_begin): New function.
		* as.c (gas_init): Call eh_begin.
		* as.h (eh_begin): Declare.

2023-03-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-09  Simon Marchi  <simon.marchi@efficios.com>

	gdb, gdbserver, gdbsupport: fix whitespace issues
	Replace spaces with tabs in a bunch of places.

	Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/pending-fork-event-detach.exp for remote target
	Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
	remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.

	Then, fix the test-case for target board remote-stdio-gdbserver with
	REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
	on target using remote_download, and using the resulting path.

	Tested on x86_64-linux.

2023-03-09  Alan Modra  <amodra@gmail.com>

	objdump: report no section contents
	objdump's read_section is never used for bss-style sections, so to
	plug a hole that fuzzers have found, exclude sections without
	SEC_HAS_CONTENTS.

		* objdump.c (read_section): Report and return an error on
		a no contents section.

2023-03-09  Alan Modra  <amodra@gmail.com>

	gas: allow frag address wrapping in absolute section
	This:
		 .struct -1
		x:
		 .fill 1
		y:
	results in an internal error in frag_new due to abs_section_offset
	wrapping from -1 to 0.  Frags in the absolute section don't do much so
	I think we can allow the address wrap.

		* frags.c (frag_new): Allow address wrap in absolute section.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/multiple-successive-infcall.exp on native-gdbserver
	With test-case gdb.threads/multiple-successive-infcall.exp and target board
	native-gdbserver I run into:
	...
	(gdb) continue^M
	Continuing.^M
	[New Thread 758.759]^M
	^M
	Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
	  multiple-successive-infcall.c:97^M
	97            thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
	(gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
	  created new thread
	...

	The problem is that the new thread message doesn't match the regexp, which
	expects something like this instead:
	...
	[New Thread 0x7ffff746e700 (LWP 570)]^M
	...

	Fix this by accepting this form of new thread message.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
	With test-case gdb.threads/thread-specific-bp.exp and target board
	native-gdbserver I run into:
	...
	(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
	continue^M
	Continuing.^M
	Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
	^M
	Thread 1 "thread-specific" hit Breakpoint 4, end () at \
	  thread-specific-bp.c:29^M
	29      }^M
	(gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
	  continue to end (timeout)
	...

	The problem is that the test-case tries to match the "[Thread ... exited]"
	message which we do see with native testing:
	...
	Continuing.^M
	[Thread 0x7ffff746e700 (LWP 7047) exited]^M
	Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
	...

	The fact that the message is missing was reported as PR remote/30129.

	We could add a KFAIL for this, but the functionality the test-case is trying
	to test has nothing to do with the message, so it should pass.  I only added
	matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix
	gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
	broke testing on native-gdbserver.

	Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
	instead.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/*.exp for remote target
	Fix test-cases for target board remote-gdbserver-on-localhost by using
	gdb_remote_download.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/unittest.exp for remote target
	With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
	get:
	...
	(gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
	  --selftest^M
	Selftests have been disabled for this build.^M
	UNSUPPORTED: gdb.server/unittest.exp: unit tests
	...
	but with target board remote-stdio-gdbserver I get instead:
	...
	(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
	  /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
	Selftests have been disabled for this build.^M
	Connection to localhost closed.^M^M
	FAIL: gdb.server/unittest.exp: unit tests
	...

	Fix this by making the regexp less strict.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.exp
	With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver
	I run into:
	...
	(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \
	  --selftest^M
	Selftests have been disabled for this build.^M
	UNSUPPORTED: gdb.server/unittest.exp: unit tests
	...
	due to using the system gdbserver /usr/bin/gdbserver rather than the one from
	the build.

	Fix this by removing the hard-coding of /usr/bin/gdbserver in
	remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we
	have instead:
	...
	(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
	  /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
	Running selftest remote_memory_tagging.^M
	Ran 1 unit tests, 0 failed^M
	Connection to localhost closed.^M^M
	PASS: gdb.server/unittest.exp: unit tests
	...

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/sysroot.exp for remote target
	Fix test-case gdb.server/sysroot.exp with target board
	remote-gdbserver-on-localhost, by:
	- using gdb_remote_download, and
	- disabling the "local" scenario for remote host.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
	Test-case gdb.server/multi-ui-errors.exp fails for target board
	remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
	...
	(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
	Executing on target: kill -9 6447    (timeout = 300)
	builtin_spawn [open ...]^M
	XYZ1ZYX
	sh: line 0: kill: (6447) - Operation not permitted
	...

	The problem is that the kill command:
	...
	remote_exec target "kill -9 $gdbserver_pid"
	...
	intended to kill gdbserver instead tries to kill the ssh client session in
	which the gdbserver runs, and fails because it's trying as the remote target
	user (remote-target on localhost) to kill a pid owned by the the build user
	($USER on localhost).

	Fix this by getting the gdbserver pid using the ppid trick from
	server-kill.exp.

	Likewise in gdb.server/server-kill-python.exp.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
	In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
	an observation is made that test-case gdb.server/server-kill.exp claims to
	kill gdbserver, but actually kills the inferior.  Consequently, the commit
	adds testing of killing gdbserver alongside.

	The problem is that:
	- the original observation is incorrect (possibly caused by misreading getppid
	  as getpid)
	- consequently, the test-case doesn't test killing the inferior, instead it
	  tests killing gdbserver twice
	- the method to get the gdbserver PID added in the commit doesn't work
	  for target board remote-gdbserver-on-localhost, it returns the
	  PID of the ssh client session instead.

	Fixing the method for getting the inferior PID gives us fails, and there's no
	evidence that killing the inferior ever worked.

	So, fix this by reverting the commit and just killing gdbserver, using the
	original method of getting the gdbserver PID which does work for target board
	remote-gdbserver-on-localhost.

	Tested on x86_64-linux.

2023-03-09  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target
	Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
	remote-gdbserver-on-localhost.

	The problem is here:
	...
	       set target_exec [gdb_remote_download target $binfile.bak $binfile]
	...
	A "gdb_remote_download target" copies from build to target.  So $binfile is
	assumed to be a target path, but it's actually a build path.

	Fix this by:
	- fist copying $binfile.bak to $binfile, and
	- simply doing [gdb_remote_download target $binfile].

	Then, $binfile.bak is created here:
	...
	 # Make sure we have the original symbol file in a safe place to copy from.
	 gdb_remote_download host $binfile $binfile.bak
	...
	and since "gdb_remote_download host" copies from build to host, $binfile.bak
	is assumed to be a host path, but it's actually a build path.  This happens to
	cause no problems in this configuration (because build == host), but it would
	for a remote host configuration.

	So let's fix this by making build rather than host the "safe place to copy
	from".

	Tested on x86_64-linux.

2023-03-09  Alan Modra  <amodra@gmail.com>

	lddigest 32-bit support and gcc-4 compile errors
		* ld.texi: Revert 2023-03-08 commit 9a534b9f8e3d.
		* testsuite/ld-scripts/crc64-poly.d: Likewise.
		* testsuite/ld-scripts/crc64-poly.t: Likewise.
		* lddigest.c: Formatting.
		(get_uint64_t): New function.
		(lang_add_digest): Take etree_type* args.  Replace "illegal" with
		"invalid" in error message.
		* lddigest.h (lang_add_digest): Update prototype.
		* lddigest_tab.c (algorithms): Work around gcc-4 errors.
		* ldgram.y (polynome): Adjust lang_add_digest call.
		* testsuite/ld-scripts/crc64-poly-size.d: Update expected error.

2023-03-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-08  Tom Tromey  <tom@tromey.com>

	Remove OBJF_REORDERED
	OBJF_REORDERED is set for nearly every object format.  And, despite
	the ominous warnings here and there, it does not seem very expensive.
	This patch removes the flag entirely.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-03-08  Carl Love  <cel@us.ibm.com>

	PowerPC, fix test gdb.arch/altivec-regs.exp
	The test fails on Power 10 with the RHEL9 distro.  It also fails on
	Power 9.

	The test set a the breakpoint in main that stops at line:
	a = 9; /* start here */.  The test then sets a break point at the same
	line where it wants to start the test and does a continue.  GDB does not
	stop again on the same line where it is stopped, but rather continues to
	the end of the program.

	Initialize variable A to zero so the break on main will stop before setting
	a break point on line a = 9; /* start here */.

	Make the match on the breakpoint number generic.

	Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
	and Power 9 with Fedora 36 with no regression failures.

2023-03-08  Nick Clifton  <nickc@redhat.com>

	ld: Use correct types for crc64 calculations

2023-03-08  Alan Modra  <amodra@gmail.com>

	Tidy pe_ILF_build_a_bfd a little
		* peicode.h (ILF section, pe_ILF_object_p): Correct comments
		and update the reference to Microsoft's docs.
		(pe_ILF_build_a_bfd): Move all symbol creation before flipping
		the bfd over to in-memory.

	Re: DIGEST: testsuite
	Correct test target/skip lines to fix fails on alpha-dec-vms,
	alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd,
	ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and
	tic54x-coff.

	Regen potfiles

2023-03-08  Alan Modra  <amodra@gmail.com>

	Re: Move nm.c cached line number info to bfd usrdata
	Commit e3f450f3933d resulted in a nm -l segfault on object files
	without undefined symbols.  Fix that, and be paranoid about bfd
	section count changing.

		* nm.c (struct lineno_cache): Add seccount.
		(free_lineno_cache): Don't segfault on NULL lc->relocs.
		(print_symbol): Stash section count when creating arrays.

2023-03-08  Alan Modra  <amodra@gmail.com>

	z8 and z80 coff_reloc16_extra_cases sanity checks
		* reloc16.c (bfd_coff_reloc16_get_relocated_section_contents):
		Use size_t variables.  Sanity check reloc address.  Handle
		errors from bfd_coff_reloc16_extra_cases.
		* coffcode.h (_bfd_coff_reloc16_extra_cases): Return bool, take
		size_t* args.
		(dummy_reloc16_extra_cases): Adjust to suit.  Don't abort.
		* coff-z80.c (extra_case): Sanity check reloc address.  Return
		errors.  Tidy formatting.  Use bfd_signed_vma temp var to
		check for reloc overflow.  Don't abort on unexpected reloc type,
		instead print an error and return false.
		* coff-z8k.c (extra_case): Likewise.
		* libcoff.h: Regenerate.

2023-03-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value
	The AMD GPU support has been merged shortly after commit 4e1d2f5814b2
	("Add new overload of gdbarch_return_value"), which made it mandatory
	for architectures to provide either a return_value or
	return_value_as_value implementation.  Because of my failure to test
	properly after rebasing and before pushing, we get this with the current
	master:

	    $ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch
	    /home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ...
	            return_value_as_value

	I started trying to change GDB to not force architectures to provide a
	return_value or return_value_as_value implementation, but Andrew pointed
	out that any serious port will have an implementation one day or
	another, and it's easy to add a dummy implementation in the mean time.
	So it's better to not complicate the core of GDB to know how to deal
	with this.

	There is an implementation of return_value in the downstream ROCgdb port
	(which we'll need to convert to the new return_value_as_value), which
	we'll contribute soon-ish.  In the mean time, add a dummy implementation
	of return_value_as_value to avoid the failed assertion.

	Change-Id: I26edf441b511170aa64068fd248ab6201158bb63
	Reviewed-By: Lancelot SIX <lancelot.six@amd.com>

2023-03-07  Tom Tromey  <tom@tromey.com>

	Merge forget_cached_source_info_for_objfile into objfile method
	forget_cached_source_info_for_objfile does some objfile-specific work
	and then calls objfile::forget_cached_source_info.  It seems better to
	me to just have the method do all the work.

2023-03-07  Tom Tromey  <tom@tromey.com>

	Clean up attribute reprocessing
	I ran across the attribute reprocessing code recently and noticed that
	it unconditionally sets members of the CU when reading a DIE.  Also,
	each spot reading attributes needs to be careful to "reprocess" them
	as a separate step.

	This seemed excessive to me, because while reprocessing applies to any
	DIE, setting the CU members is only necessary for the toplevel DIE in
	any given CU.

	This patch introduces a new read_toplevel_die function and changes a
	few spots to call it.  This is easily done because reading the
	toplevel DIE is already special.

	I left the reprocessing flag and associated checks in attribute.  It
	could be stripped out, but I am not sure it would provide much value
	(maybe some iota of performance).

	Regression tested on x86-64 Fedora 36.

2023-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: initialize interp::next
	This field is never initialized, it seems to me like it would be a good
	idea to initialize it to nullptr to avoid bad surprises.

	Change-Id: I8c04319d564f5d385d8bf0acee758f6ce28b4447
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-07  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make interp::m_name an `const char *`
	I realized that the memory for interp names does not need to be
	allocated.  The name used to register interp factory functions is always
	a literal string, so has static storage duration.  If we change
	interp_lookup to pass that name instead of the string that it receives
	as a parameter (which does not always have static storage duration),
	then interps can simply store pointers to the name.

	So, change interp_lookup to pass `factory.name` rather than `name`.
	Change interp::m_name to be a `const char *` rather than an std::string.

	Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-07  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make get_interp_info return a reference
	get_interp_info and get_current_interp_info always return non-nullptr,
	so they can return a reference instead of a pointer.

	Since we don't need to copy it, make ui_interp_info non-copyiable, to
	avoid a copying it in a local variable, instead of getting a reference.

	Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-07  Tom Tromey  <tromey@adacore.com>

	Fix selfcheck regression due to new maint command
	Simon points out that the new maint command, intended to fix a
	regression, also introduces a new regression in "maint selftest".

	This patch fixes the error.  I did a full regression test on x86-64
	Fedora 36.

2023-03-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: read Dwarf 5
	gprofng reads Dwarf to find function names, sources, and line numbers.
	gprofng skips other debug information.
	I fixed three places in gprofng Dwarf reader:
	 - parsing the compilation unit header.
	 - parsing the line number table header.
	 - parsing new DW_FORMs.

	Tested on aarch64-linux/x86_64-linux.

	gprofng/ChangeLog
	2023-03-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30195
		gprofng/src/Dwarf.cc: Support Dwarf-5.
		gprofng/src/DwarfLib.cc: Likewise.
		gprofng/src/Dwarf.h: Likewise.
		gprofng/src/DwarfLib.h: Likewise.
		gprofng/src/collctrl.cc: Don't read freed memory.

2023-03-07  Richard Purdie  <richard.purdie@linuxfoundation.org>

	gdb: Fix GDB_AC_CHECK_BFD macro regression
	Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in
	GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
	this caused the configure check "checking for ELF support in BFD" to stop
	working causing build failures as we need our LDFLAGS to be used for
	correct linking.

	That change also meant the code failed to match the comments. Add back the
	missing LDFLAGS preservation, fix our builds and match the comment.

	Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112
	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>

2023-03-07  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Enable vector instruction debugging for AIX
	AIX now supports vector register contents debugging for both VMX
	VSX registers.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/execl.exp for remote target
	Fix test-case gdb.threads/execl.exp on target board
	remote-gdbserver-on-localhost using gdb_remote_download.

	Tested on x86_64-linux.

2023-03-07  Tom Tromey  <tromey@adacore.com>

	Ensure index cache entry written in test
	Now that index cache files are written in the background, one test in
	index-cache.exp is racy -- it assumes that the cache file will have
	been written during startup.

	This patch fixes the problem by introducing a new maintenance command
	to wait for all pending writes to the index cache.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/skip-solib.exp for remote target
	Fix test-case gdb.base/skip-solib.exp for target board
	remote-gdbserver-on-localhost using gdb_load_shlib.

	Tested on x86_64-linux.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.exp
	In test-case gdb.base/skip-solib.exp the linking against a shared library is
	done manually:
	...
	if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \
	        [list debug "additional_flags=-L$testobjdir" \
	             "additional_flags=-l${test}" \
	             "ldflags=-Wl,-rpath=$testobjdir"]] != ""} {
	...

	Instead, use the shlib gdb_compile option such that we simply have:
	...
	        [list debug shlib=$binfile_lib]] != ""} {
	...

	Tested on x86_64-linux.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for remote target
	Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board
	remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib.

	Tested on x86_64-linux.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/break-probes.exp for remote target
	With test-case gdb.base/break-probes.exp and target board
	remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
	failures.

	Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib.

	Tested on x86_64-linux.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.dwarf2/dw2-zero-range.exp for remote-gdbserver-on-localhost
	Fix test-case gdb.dwarf2/dw2-zero-range.exp for target board
	remote-gdbserver-on-localhost using gdb_load_shlib.

	Tested on x86_64-linux.

2023-03-07  Ulf Samuelsson  <ulf@emagii.com>

	Build ldint

2023-03-07  Ulf Samuelsson  <ulf@emagii.com>

	DIGEST: Makefile.*
	The Makefile.in was generated using automake
	after adding a few files.

	When adding the ldreflect.* files, the autotools
	versions were wrong.
	After upgrading the host OS, autotools were upgraded to 2.71
	reinstalling the desired 2.69 still generates a lot of changes.

	Makefile.ini has therefore been manually edited.

2023-03-07  Ulf Samuelsson  <ulf@emagii.com>

	DIGEST: calculation

	DIGEST: ldlang.*: add timestamp

	DIGEST: ldmain.c

	DIGEST: ldgram.y

	DIGEST: ldlex.l

	DIGEST: testsuite

	DIGEST: Documentation

	DIGEST: NEWS

	DIGEST: LICENSING

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
	With test-case gdb.base/signals-state-child.exp on target board
	remote-gdbserver-on-localhost I run into:
	...
	builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
	  $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
	bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
	  Permission denied^M
	Connection to localhost closed.^M^M
	FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
	...

	The problem is that we're trying to run an executable on the target board using
	a host path.

	After fixing this by downloading the exec to the target board, we run into:
	...
	builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
	  signals-state-child-standalone^M
	bash: signals-state-child-standalone: command not found^M
	Connection to localhost closed.^M^M
	FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
	...

	Fix this by using an absolute path name for the exec on the target board.

	The dejagnu proc standard_file does not support op == "absolute" for target
	boards, so add an implementation in remote-gdbserver-on-localhost.exp.

	Also:
	- fix a PATH-in-test-name issue
	- cleanup gdb.txt and standalone.txt on target board

	Tested on x86_64-linux.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/breakpoint-shlib-func.exp with remote-gdbserver-on-localhost
	Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board
	remote-gdbserver-on-localhost.

	Fix this by adding the missing gdb_load_shlib.

	Tested on x86_64-linux.

2023-03-07  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Modify altivec-regs.exp testcase for AIX
	On AIX, the debugger cannot access vector registers before they
	are first used by the inferior.  Hence we change the test case
	such that some vector registers are accessed by the variable 'x' in AIX
	and other targets are not affected as a consequence of the same.

2023-03-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.mi/*.exp with remote-gdbserver-on-localhost
	When running test-cases gdb.mi/*.exp with target board
	remote-gdbserver-on-localhost, we run into a few fails.

	Fix these (and make things more similar to the gdb.exp procs) by:
	- factoring out mi_load_shlib out of mi_load_shlibs
	- making mi_load_shlib use gdb_download_shlib, like
	  gdb_load_shlib
	- factoring out mi_locate_shlib out of mi_load_shlib
	- making mi_locate_shlib check for mi_spawn_id, like
	  gdb_locate_shlib
	- using gdb_download_shlib and mi_locate_shlib in the test-cases.

	Tested on x86_64-linux, with and without target board
	remote-gdbserver-on-localhost.

2023-03-07  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.c
	When building with clang 16, I see:

	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	            info->prologue_type.load_args = 1;
	                                          ^ ~
	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	          info->prologue_type.critical = 1;
	                                       ^ ~
	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	          info->prologue_type.interrupt = 1;
	                                        ^ ~
	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	                  info->prologue_type.fp_sdcc = 1;
	                                              ^ ~
	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	          info->prologue_type.fp_sdcc = 1;
	                                      ^ ~
	    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	          info->prologue_type.fp_sdcc = 1;
	                                      ^ ~

	Fix that by using "unsigned int" as the bitfield's underlying type.

	Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d

2023-03-07  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h
	When building with clang 16, we get:

	      CXX    gdb.o
	    In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
	    In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
	    /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]
	        integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
	                                                       ^

	The error message does not make it clear in the context of which enum
	flag this fails (i.e. what is T in this context), but it doesn't really
	matter, we have similar warning/errors for many of them, if we let the
	build go through.

	clang is right that the value -1 is invalid for the enum type we cast -1
	to.  However, we do need this expression in order to select an integer
	type with the appropriate signedness.  That is, with the same signedness
	as the underlying type of the enum.

	I first wondered if that was really needed, if we couldn't use
	std::underlying_type for that.  It turns out that the comment just above
	says:

	    /* Note that std::underlying_type<enum_type> is not what we want here,
	       since that returns unsigned int even when the enum decays to signed
	       int.  */

	I was surprised, because std::is_signed<std::underlying_type<enum_type>>
	returns the right thing.  So I tried replacing all this with
	std::underlying_type, see if that would work.  Doing so causes some
	build failures in unittests/enum-flags-selftests.c:

	      CXX    unittests/enum-flags-selftests.o
	    /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::check_valid_expr254::archetype<enum_flags<s
	    elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla
	    gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte
	    sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true':
	    CHECK_VALID (true,  int,  true ? EF () : EF2 ())
	    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'
	      CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)
	      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'
	      CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2,           \
	      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'
	      static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>,    \
	      ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	This is a bit hard to decode, but basically enumerations have the
	following funny property that they decay into a signed int, even if
	their implicit underlying type is unsigned.  This code:

	    enum A {};
	    enum B {};

	    int main() {
	      std::cout << std::is_signed<std::underlying_type<A>::type>::value
	                << std::endl;
	      std::cout << std::is_signed<std::underlying_type<B>::type>::value
	                << std::endl;
	      auto result = true ? A() : B();
	      std::cout << std::is_signed<decltype(result)>::value << std::endl;
	    }

	produces:

	    0
	    0
	    1

	So, the "CHECK_VALID" above checks that this property works for enum flags the
	same way as it would if you were using their underlying enum types.  And
	somehow, changing integer_for_size to use std::underlying_type breaks that.

	Since the current code does what we want, and I don't see any way of doing it
	differently, ignore -Wenum-constexpr-conversion around it.

	Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2

2023-03-07  John Baldwin  <jhb@FreeBSD.org>

	gdb.threads/next-bp-other-thread.c: Ensure child thread is started.
	Use a pthread_barrier to ensure the child thread is started before
	the main thread gets to the first breakpoint.

	gdb.threads/execl.c: Ensure all threads are started before execl.
	Use a pthread_barrier to ensure all threads are started before
	proceeding to the breakpoint where info threads output is checked.

2023-03-07  John Baldwin  <jhb@FreeBSD.org>

	gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.
	- Some OS's use a different syscall for exit().  For example, the
	  BSD's use SYS_exit rather than SYS_exit_group.  Update the C source
	  file and the expect script to support SYS_exit as an alternative to
	  SYS_exit_group.

	- The cross-arch syscall number tests are all Linux-specific with
	  hardcoded syscall numbers specific to Linux kernels.  Skip these
	  tests on non-Linux systems.  FreeBSD kernels for example use the
	  same system call numbers on all platforms, so the test is also not
	  relevant on FreeBSD.

2023-03-07  John Baldwin  <jhb@FreeBSD.org>

	gdb.threads/multi-create: Double the existing stack size.
	Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the
	stack on FreeBSD rather than raising it causing non-main threads in
	the test program to overflow their stack and crash.  Double the
	existing stack size rather than assuming that the initial stack size
	is PTHREAD_STACK_MIN.

2023-03-07  John Baldwin  <jhb@FreeBSD.org>

	amd64-linux-tdep: Don't treat fs_base and gs_base as system registers.
	These registers can be changed directly in userspace, and similar
	registers to support TLS on other architectures (tpidr* on ARM and
	AArch64, tp on RISC-V) are treated as general purpose registers.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-07  John Baldwin  <jhb@FreeBSD.org>

	gdb.arch/amd64-gs_base.exp: Support non-Linux.
	The orig_rax pseudo-register is Linux-specific and isn't relevant to
	this test.  The fs_base and gs_base registers are also not treated as
	system registers in other OS ABIs.  This allows the test to pass on
	FreeBSD.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-06  Kévin Le Gouguec  <legouguec@adacore.com>

	gdb/python: Fix --disable-tui build
	As of 2023-02-13 "gdb/python: deallocate tui window factories at Python
	shut down" (9ae4519da90), a TUI-less build fails with:

	$src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’:
	$src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared
	  621 |   gdbpy_tui_window_maker::invalidate_all ();
	      |   ^~~~~~~~~~~~~~~~~~~~~~

	Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an
	#ifdef guard in gdbpy_finalize_tui as well.

2023-03-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuite
	Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests
	the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather
	than gdb.base.

	Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to
	gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with
	recently added gdb.testsuite/gdb-caching-proc.exp.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow args in gdb_caching_proc
	Test-case gdb.base/morestack.exp contains:
	...
	require {have_compile_flag -fsplit-stack}
	...
	and I want to cache the result of have_compile_flag.

	Currently gdb_caching_proc doesn't allow args, so I could add:
	...
	gdb_caching_proc have_compile_flag_fsplit_stack {
	    return [have_compile_flag -fsplit-stack]
	}
	...
	and then use that proc instead, but I find this cumbersome and
	maintenance-unfriendly.

	Instead, allow args in a gdb_caching_proc, such that I can simply do:
	...
	-proc have_compile_flag { flag } {
	+gdb_caching_proc have_compile_flag { flag } {
	...

	Note that gdb_caching_procs with args do not work with the
	gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use regular proc syntax for gdb_caching_proc
	A regular tcl proc with no args looks like:
	...
	proc foo {} {
	     return 1
	}
	...
	but a gdb_caching_proc deviates from that syntax by dropping the explicit no
	args bit:
	...
	gdb_caching_proc foo {
	     return 1
	}
	...

	Make the gdb_caching_proc use the same syntax as regular procs, such that we
	have instead:
	...
	gdb_caching_proc foo {} {
	     return 1
	}
	...

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.testsuite/gdb-caching-proc.exp
	Add test-case gdb.testsuite/gdb-caching-proc.exp that excercises
	gdb_caching_proc.

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-06  Tom Tromey  <tromey@adacore.com>

	Fix DAP stackTrace through frames without debuginfo
	The DAP stackTrace implementation did not fully account for frames
	without debuginfo.  Attemping this would yield a result like:

	{"request_seq": 5, "type": "response", "command": "stackTrace", "success": false, "message": "'NoneType' object has no attribute 'filename'", "seq": 11}

	This patch fixes the problem by adding another check for None.

2023-03-06  Tom Tromey  <tromey@adacore.com>

	Remove exception_catchpoint::resources_needed
	exception_catchpoint::resources_needed has a FIXME comment that I
	think makes this method obsolete.  Also, I note that similar
	catchpoints, for example Ada catchpoints, don't have this method.
	This patch removes the method.  Regression tested on x86-64 Fedora 36.

2023-03-06  Tom Tromey  <tromey@adacore.com>

	Remove two more files in gdb "distclean"
	The recent work to have gdb link via libtool means that there are a
	couple more generated files in the build directory that should be
	removed by "distclean".

	Note that gdb can't really fully implement distclean due to the desire
	to put certain generated files into the distribution.  Still, it can
	get pretty close.

2023-03-06  Alan Modra  <amodra@gmail.com>

	macho null dereference read
	The main problem here was not returning -1 from canonicalize_symtab on
	an error, leaving the vector of relocs only partly initialised and one
	with a null sym_ptr_ptr.

		* mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error,
		not 0.
		(bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to
		undefined section sym.

2023-03-06  Alan Modra  <amodra@gmail.com>

	PR30198, Assertion and segfault when linking x86_64 elf and coff
		PR 30198
		* coff-x86_64.c (coff_amd64_reloc): Set *error_message when
		returning bfd_reloc_dangerous.  Also check that __ImageBase is
		defined before accessing h->u.def.

	More _bfd_ecoff_locate_line sanity checks
		* ecofflink.c (mk_fdrtab): Discard fdr with negative cpd.
		(lookup_line): Sanity check fdr cbLineOffset and cbLine.
		Sanity check pdr cbLineOffset.

2023-03-06  Alan Modra  <amodra@gmail.com>

	Correct odd loop in ecoff lookup_line
	I can't see why this really odd looking loop was written the way it
	was in commit a877f5917f90, but it can result in a buffer overrun.

		* ecofflink.c (lookup_line): Don't swap in pdr at pdr_end.

2023-03-06  Alan Modra  <amodra@gmail.com>

	Downgrade objdump fatal errors to non-fatal
		* objdump.c (slurp_symtab): Replace bfd_fatal calls with calls
		to my_bfd_nonfatal.
		(slurp_dynamic_symtab, disassemble_section): Likewise.
		(disassemble_data): Replace fatal call with non_fatal call, and
		set exit_status.  Don't error on non-existent dynamic relocs.
		Don't call bfd_fatal on bfd_canonicalize_dynamic_reloc error.
		(dump_ctf, dump_section_sframe): Replace bfd_fatal calls with
		calls to my_bfd_nonfatal and clean up memory.
		(dump_relocs_in_section): Don't call bfd_fatal on errors.
		(dump_dynamic_relocs): Likewise.
		(display_any_bfd): Make archive nesting too depp non_fatal.

	Downgrade addr2line fatal errors to non-fatal
		* addr2line.c (slurp_symtab): Don't exit on errors.
		(process_file): Likewise.

2023-03-06  Alan Modra  <amodra@gmail.com>

	Downgrade nm fatal errors to non-fatal
	Many of the fatal errors in nm ought to be recoverable.  This patch
	downgrades most of them.  The ones that are left are most likely due
	to memory allocation failures.

		* nm.c (print_symdef_entry): Don't bomb with a fatal error
		on a corrupted archive symbol table.
		(filter_symbols): Silently omit symbols that return NULL
		from bfd_minisymbol_to_symbol rather than giving a fatal
		error.
		(display_rel_file): Don't give a fatal error on
		bfd_read_minisymbols returning an error, or on not being able
		to read dynamic symbols for synth syms.
		(display_archive): Downgrade bfd_openr_next_archived_file
		error.
		(display_file): Don't bomb on a bfd_close failure.

2023-03-06  Alan Modra  <amodra@gmail.com>

	Move nm.c cached line number info to bfd usrdata
	Replace the static variables used by nm to cache line number info
	with a struct attached to the bfd.  Cleaner, and it avoids any concern
	that lineno_cache_bfd is somehow left pointing at memory for a closed
	bfd and that memory is later reused for another bfd, not that I think
	this is possible.  Also don't bomb via bfd_fatal on errors getting
	the line number info, just omit the line numbers.

		* nm.c (struct lineno_cache): Rename from get_relocs_info.
		Add symcount.
		(lineno_cache_bfd, lineno_cache_rel_bfd): Delete.
		(get_relocs): Adjust for struct rename.  Don't call bfd_fatal
		on errors.
		(free_lineno_cache): New function.
		(print_symbol): Use lineno_cache in place of statics.  Don't
		call bfd_fatal on errors reading symbols, just omit the line
		info.
		(display_archive, display_file): Call free_lineno_cache.

2023-03-06  Alan Modra  <amodra@gmail.com>

	Correct objdump command line error handling
	bfd_nonfatal is used when a bfd error is to be printed.  That's not
	the case for command line errors.

		* objdump.c (nonfatal): Rename to my_bfd_nonfatal.
		(main): Use non_fatal and call usage on unrecognized arg errors.
		Don't set exit_status when calling usage.

2023-03-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-03  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO`
	When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash,
	rather than bash, I get:

	    c&^M
	    Continuing.^M
	    (gdb) sh: 1: kill: Illegal option -S^M
	    ^M
	    Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M
	    23        return 0;^M
	    FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout)

	This is because it uses the kill command built-in the dash shell, and
	using the SIG prefix with kill does not work with dash's kill.  The
	difference is listed in the documentation for bash's POSIX-correct mode
	[1]:

	    The kill builtin does not accept signal names with a ‘SIG’ prefix.

	Replace SIGINT with INT in that test.

	By grepping, I found two other instances (gdb.base/sigwinch-notty.exp
	and gdb.threads/detach-step-over.exp).  Those were not problematic on my
	system though.  Since they are done through remote_exec, they don't go
	through the shell and therefore invoke /bin/kill.  On my Arch Linux,
	it's:

	    $ /bin/kill --version
	    kill from util-linux 2.38.1 (with: sigqueue, pidfd)

	and on my Ubuntu:

	    $ /bin/kill --version
	    kill from procps-ng 3.3.17

	These two implementations accept "-SIGINT".  But according to the POSIX
	spec [2], the kill utility should recognize the signal name without the
	SIG prefix (if it recognizes them with the SIG prefix, it's an
	extension):

	    -s  signal_name
	        Specify the signal to send, using one of the symbolic names defined
		in the <signal.h> header. Values of signal_name shall be recognized
		in a case-independent fashion, without the SIG prefix. In addition,
		the symbolic name 0 shall be recognized, representing the signal
		value zero. The corresponding signal shall be sent instead of SIGTERM.
	    -signal_name
	        [XSI] [Option Start]
	        Equivalent to -s signal_name. [Option End]

	So, just in case some /bin/kill implementation happens to not recognize
	the SIG prefixes, change these two other calls to remove the SIG
	prefix.

	[1] https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html
	[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html

	Change-Id: I81ccedd6c9428ab63b9261813f1905a18941f8da
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use set always-read-ctf on instead of --strip-debug
	Use "set always-read-ctf on" instead of --strip-debug in the ctf test-cases.

	Tested on x86_64-linux.

2023-03-03  Tom Tromey  <tromey@adacore.com>

	Update expected results in long_long.exp
	Simon pointed out that the recent patch to add half-float support to
	'x/f' caused a couple of regressions in long_long.exp.  This patch
	fixes these by updating the expected results.

2023-03-03  Nick Clifton  <nickc@redhat.com>

	Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant.
	 PR 30193 * ldgram.y (ASCII): Fail if the size is not a constant.

2023-03-03  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: replace strlen call with std::string::size call
	Small cleanup to use std::string::size instead of calling strlen on
	the result of std::string::c_str.

	Should be no user visible changes after this call.

2023-03-03  Jan Beulich  <jbeulich@suse.com>

	x86: use swap_2_operands() in build_vex_prefix()
	Open-coding part of what may eventually be needed is somewhat risky.
	Let's use the function we have, taking care of all pieces of data which
	may need swapping, no matter that
	- right now i.flags[] and i.reloc[] aren't relevant here (yet),
	- EVEX masking and embedded broadcast aren't applicable.

	x86: drop redundant calculation of EVEX broadcast size
	In commit a5748e0d8c50 ("x86/Intel: allow MASM representation of
	embedded broadcast") I replaced the calculation of i.broadcast.bytes in
	check_VecOperands() not paying attention to the immediately following
	call to get_broadcast_bytes() doing exactly that (again) first thing.

2023-03-03  Jan Beulich  <jbeulich@suse.com>

	gas: default .debug section compression method adjustments
	While commit b0c295e1b8d0 ("add --enable-default-compressed-debug-
	sections-algorithm configure option") adjusted flag_compress_debug's
	initializer, it didn't alter the default used when the command line
	option was specified with an (optional!) argument. This rendered help
	text inconsistent with actual behavior in certain configurations.

	As to help text - the default reported there clearly shouldn't be
	affected by a possible earlier --compress-debug-sections= option, so
	flag_compress_debug can't be used when emitting usage information.

2023-03-03  Jan Beulich  <jbeulich@suse.com>

	x86: avoid .byte in testcases where possible
	In the course of using the upcoming .insn directive to eliminate various
	.byte uses in testcases I've come across these, which needlessly use
	more .byte than necessary even without the availability of .insn.

2023-03-03  Alan Modra  <amodra@gmail.com>

	Tidy type handling in binutils/rdcoff.c
	There isn't really any good reason for code in rdcoff.c to distinguish
	between "basic" types and any other type.  This patch dispenses with
	the array reserved for basic types and instead handles all types using
	coff_get_slot, simplifying the code.

		* rdcoff.c (struct coff_types, coff_slots): Merge.  Delete
		coff_slots.
		(T_MAX): Delete.
		(parse_coff_base_type): Use coff_get_slot to store baseic types.
		(coff_get_slot, parse_coff_type, parse_coff_base_type),
		(parse_coff_struct_type, parse_coff_enum_type),
		(parse_coff_symbol, parse_coff): Pass types as coff_types**.

2023-03-03  Alan Modra  <amodra@gmail.com>

	binutils coff type list
	As for commit 72d225ef9cc7, handle type numbers starting anywhere.

		PR 17512
		* rdcoff.c (struct coff_slots): Add base_index.
		(coff_get_slot): Delete pr17512 excessively large slot check.
		Don't allocate entire array from 0 to type number, allocate a
		sparse array.

2023-03-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix -Wmaybe-uninitialized warning in value.c
	Since commit 11470e70ea0d ("gdb: store internalvars in an std::map"), bulding
	with -O2, with g++ 11.3.0 on Ubuntu 22.04, I see:

	      CXX    value.o
	    In constructor ‘internalvar::internalvar(internalvar&&)’,
	        inlined from ‘constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const char*&; _U2 = internalvar; typename std::enable_if<(std::_PCC<true, _T1, _T2>::_MoveConstructiblePair<_U1, _U2>() && std::_PCC<true, _T1, _T2>::_ImplicitlyMoveConvertiblePair<_U1, _U2>()), bool>::type <anonymous> = true; _T1 = const char*; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:353:35,
	        inlined from ‘constexpr std::pair<typename std::__strip_reference_wrapper<typename std::decay<_Tp>::type>::__type, typename std::__strip_reference_wrapper<typename std::decay<_Tp2>::type>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = const char*&; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:572:72,
	        inlined from ‘internalvar* create_internalvar(const char*)’ at /home/smarchi/src/binutils-gdb/gdb/value.c:1933:52:
	    /home/smarchi/src/binutils-gdb/gdb/value.c:1831:8: warning: ‘<unnamed>.internalvar::u’ may be used uninitialized [-Wmaybe-uninitialized]
	     1831 | struct internalvar
	          |        ^~~~~~~~~~~
	    /home/smarchi/src/binutils-gdb/gdb/value.c: In function ‘internalvar* create_internalvar(const char*)’:
	    /home/smarchi/src/binutils-gdb/gdb/value.c:1933:76: note: ‘<anonymous>’ declared here
	     1933 |   auto pair = internalvars.emplace (std::make_pair (name, internalvar (name)));
	          |                                                                            ^

	This is because the union field internalvar::u is not initialized when
	constructing the temporary internalvar object above.  That object is then used
	for move-construction, and the (implicit) move constructor copies the
	uninitialized bytes of field u over from the temporary object to the new
	internalvar object.  The compiler therefore complains that we use uninitialized
	bytes.  I don't think it's really a problem, because the internalvar object is
	in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
	irrelevant.  Still, mute the warning by default-initializing the union.

	Change-Id: I70c392842f35255f50d8e63f4099cb6685366fb7
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-02  Tom Tromey  <tromey@adacore.com>

	Handle half-float in 'x' command
	Using 'x/hf' should print bytes as float16, but instead it currently
	prints as an integer.  I tracked this down to a missing case in
	float_type_from_length.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30161
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-02  Tom Tromey  <tromey@adacore.com>

	Fix some value comments
	I noticed a very stale comment in valarith.c.  This patch fixes a few
	comments in this area.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-03-02  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Add support for static data member in struct
	As described in C++ reference [1], static data members are not part
	of objects of a given class type. Modified compute_struct_member ()
	to ignore static data member so that we can get the expected result.

	loongson@linux:~$ cat test.c
	#include<stdio.h>
	struct struct_01 { static unsigned a; float b;};
	unsigned struct_01::a = 66;
	struct struct_01 struct_01_val = { 99.00 };
	int check_arg_struct(struct struct_01 arg)
	  {
	    printf("arg.a = %d\n", arg.a);
	    printf("arg.b = %f\n", arg.b);
	    return 0;
	  }
	int main()
	  {
	    check_arg_struct(struct_01_val);
	    return 0;
	  }
	loongson@linux:~$ g++ -g test.c -o test++
	loongson@linux:~$ gdb test++

	Without this patch:
	...
	(gdb) start
	...
	(gdb) p check_arg_struct(struct_01_val)
	arg.a = 66
	arg.b = 0.000000
	$1 = 0

	With this patch:
	...
	(gdb) start
	...
	(gdb) p check_arg_struct(struct_01_val)
	arg.a = 66
	arg.b = 99.000000
	$1 = 0

	[1] https://learn.microsoft.com/en-us/cpp/cpp/static-members-cpp?view=msvc-170

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-02  Alan Modra  <amodra@gmail.com>

	Don't write zeros to a gap in the output file
	Writing out zeros is counterproductive if a file system supports
	sparse files.  A very large gap need not take much actual disk space,
	but it usually will if zeros are written.

	memory_bseek also supports not writing out zeros in a gap.

		* elf.c (write_zeros): Delete.
		(assign_file_positions_for_load_sections): Don't call write_zeros.
		Comment.

2023-03-02  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Add set/show always-read-ctf on/off
	[ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add
	maint set symbol-read-order", submitted here (
	https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html
	). ]

	With the test-case included in this patch, we run into:
	...
	(gdb) file dwarf2-and-ctf
	(gdb) print var_ctf^M
	'var_ctf' has unknown type; cast it to its declared type^M
	...

	The problem is that the executable contains both ctf and dwarf2, so the ctf
	info (which contains the type information about var_ctf) is ignored.

	GDB has support for handling multiple debug formats, but the common use case
	for ctf is to be used when dwarf2 is not present, and gdb reflects that,
	assuming that by reading ctf in addition there won't be any extra information,
	so it's not worth the additional cycles and memory.

	Add a new command "set/show always-read-ctf on/off", that when on forces
	unconditional reading of ctf, allowing us to do:
	...
	(gdb) set always-read-ctf on
	(gdb) file dwarf2-and-ctf
	(gdb) print var_ctf^M
	$2 = 2^M
	...

	The setting is off by default, preserving current behaviour.

	A bit of background on the relevance of reading order: the formats have a
	priority relationship between them, where reading earlier means lower
	priority.  By reading the format with the most detail last, we ensure it has
	the highest priority, which makes sure that in case there is overlapping info,
	the most detailed info is found.  This explains the current reading order of
	mdebug, stabs and dwarf2.

	Add the unconditional reading of ctf before dwarf2, because it's less detailed
	than dwarf2.  The conditional reading of ctf is still done after the attempt to
	read dwarf2, necessarily so because we only know whether there's dwarf2 after
	we've tried to read it.

	The new command allow us to replace uses of -Wl,--strip-debug added in commit
	908a926ec4e ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by
	uses of "set always-read-ctf on", but I've left that for another commit.

	Tested on x86_64-linux.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: update some copyright years (2022 -> 2023)
	The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
	they end in 2022 instead of 2023.  I suppose because I posted (or at
	least prepared) the patches in 2022 but merged them in 2023, and forgot
	to update the year.  I found a bunch of other files that are in the same
	situation.  Fix them all up.

	Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-03-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-03-01  Tom Tromey  <tromey@adacore.com>

	Use const for dwarf2_property_baton
	Once a baton is stored in a struct type, it doesn't make sense to
	modify it.  This patch constifies the API.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-01  Tom Tromey  <tromey@adacore.com>

	Make gdb property batons type-safe
	gdbtypes treats dynamic property batons as 'void *', but in actuality
	the only users all use dwarf2_property_baton.  This patch changes this
	code to be type-safe.  If a new type is needed here, it seems like
	that too could be done in a type-safe way.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-03-01  Alan Modra  <amodra@gmail.com>

	More bounds checking in macro_expand
		* macro.c (macro_expand): Ensure input string buffer is not
		read past end.

2023-03-01  Alan Modra  <amodra@gmail.com>

	Using .mri in assembly
	Changing mri mode between macro definition and use isn't good.  This
		.macro x
		.endm
		.mri 1
		x
	leads to a segfault.  Fixed with the following patch, but I suppose
	what should really happen is that macros be marked as being mri mode
	when defined, and that determine whether the magic NARG parameter be
	supplied at expansion.  Nobody has complained about this in 30 years
	so I'm not inclined to change gas behaviour to that extent.

		* macro.c (macro_expand): Don't segfault in mri mode if NARG
		formal isn't found.

2023-03-01  Tom Tromey  <tromey@adacore.com>

	Fix type of check_valid_shift_count parameter
	check_valid_shift_count has an 'int' parameter that really should be
	an enum exp_opcode.  This patch makes the change.  Tested by
	rebuilding.

2023-03-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix a whitespace issue in solib-rocm.c
	Change-Id: I9cd236eaf161fe3a1abf0d212efca47a7149e021

2023-03-01  Nick Clifton  <nickc@redhat.com>

	Fix typo with my email address

2023-03-01  Tom Tromey  <tom@tromey.com>

	Fix btrace regression
	Tom de Vries pointed out that my earlier patch:

	    commit 873a185be258ad2552b9579005852815b4da5baf
	    Date:   Fri Dec 16 07:56:57 2022 -0700

		Don't use struct buffer in handle_qxfer_btrace

	regressed gdb.btrace/reconnect.exp.  I didn't notice this because I
	did not have libipt installed.

	This patch fixes the bug.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30169
	Tested-By: Bruno Larsen <blarsen@redhat.com>

2023-03-01  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add another xfail case in gdb.python/py-record-btrace.exp
	I ran into:
	...
	(gdb) PASS: gdb.python/py-record-btrace.exp: function call: \
	  python print(c.prev)
	python print(c == c.next.prev)^M
	Traceback (most recent call last):^M
	  File "<string>", line 1, in <module>^M
	AttributeError: 'NoneType' object has no attribute 'prev'^M
	Error while executing Python code.^M
	(gdb) FAIL: gdb.python/py-record-btrace.exp: function call: \
	  python print(c == c.next.prev)
	...
	due to having only 4 insn instead of 100:
	...
	python print(len(insn))^M
	4^M
	...

	This could be caused by the same hw bug as we already have an xfail for, so
	expand the xfail matching.

	Tested on x86_64-linux.

	PR testsuite/30185
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30185

	Approved-By: Markus T. Metzger <markus.t.metzger@intel.com>

2023-03-01  Alan Modra  <amodra@gmail.com>

	Catch overflow in gas s_space
	Also fix an error introduced in 1998 in reporting a zero count for
	negative counts.

	      * read.c (s_space): Use unsigned multiply, and catch overflow.
	      Correct order of tests for invalid repeat counts.  Ensure
	      ignored directives don't affect mri_pending_align.

2023-03-01  Alan Modra  <amodra@gmail.com>

	gas s_fill caused internal error in frag_new
	Fix an internal error after "non-constant fill count for absolute
	section".

		* read.c (s_fill): Don't create frags after errors.

2023-03-01  Alan Modra  <amodra@gmail.com>

	Memory leak in gas do_repeat
		* read.c (do_repeat): Free sb on error path.

2023-03-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-28  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add HtabPrinter to gdb-gdb.py.in
	When debugging GDB, I find it a bit tedious to inspect htab_t objects.
	It is possible to find the entries by poking at the fields, but it's
	annoying to do each time.  I think a pretty printer would help.  Add a
	basic one to gdb-gdb.py.

	The pretty printer advertises itself as "array-like", and the result
	looks like:

	    (top-gdb) p bfcache
	    $3 = htab_t with 3 elements = {0x6210003252a0, 0x62100032caa0, 0x62100033baa0}

	The htab_t itself doesn't know about the type of pointed objects.  But
	it's easy enough to cast the addresses to the right type to use them:

	    (top-gdb) print *((btrace_frame_cache *) 0x6210003252a0)
	    $6 = {tp = 0x61700002ed80, frame = 0x6210003251e0, bfun = 0x62000000b390}

	Change-Id: Ia692e3555fe7a117b7ec087840246b1260a704c6
	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-breakpoint.exp timeouts
	On powerpc64le-linux, I run into two timeouts:
	...
	FAIL: gdb.python/py-breakpoint.exp: test_watchpoints: \
	  Test watchpoint write (timeout)
	FAIL: gdb.python/py-breakpoint.exp: test_bkpt_internal: \
	  Test watchpoint write (timeout)
	...

	In this case, hw watchpoints are not supported, and using sw watchpoints
	is slow.

	Most of the time is spent in handling a try-catch, which triggers a malloc.  I
	think this bit is more relevant for the "catch throw" part of the test-case,
	so fix the timeouts by setting the watchpoints after the try-catch.

	Tested on x86_64-linux and powerpc64le-linux.

2023-02-28  Tom Tromey  <tromey@adacore.com>

	Remove value_in
	value_in is unused.  From git log, it seems to have been part of the
	Chill language, which was removed from gdb eons ago.  This patch
	removes the function.  Tested by rebuilding.

2023-02-28  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.rust/watch.exp on ppc64le
	On x86_64-linux, I have:
	...
	(gdb) watch -location y^M
	Hardware watchpoint 2: -location y^M
	(gdb) PASS: gdb.rust/watch.exp: watch -location y
	...
	but on powerpc64le-linux, I run into:
	...
	(gdb) watch -location y^M
	Watchpoint 2: -location y^M
	(gdb) FAIL: gdb.rust/watch.exp: watch -location y
	...
	due to the regexp matching "Hardware watchpoint" but not "Watchpoint":
	...
	gdb_test "watch -location y" ".*watchpoint .* -location .*"
	...

	Fix this by making the regexp less restrictive.

	Tested on x86_64-linux and powerpc64le-linux.

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix mi breakpoint-deleted notifications for thread-specific b/p
	Background
	----------

	When a thread-specific breakpoint is deleted as a result of the
	specific thread exiting the function remove_threaded_breakpoints is
	called which sets the disposition of the breakpoint to
	disp_del_at_next_stop and sets the breakpoint number to 0.  Setting
	the breakpoint number to zero has the effect of hiding the breakpoint
	from the user.  We also print a message indicating that the breakpoint
	has been deleted.

	It was brought to my attention during a review of another patch[1]
	that setting a breakpoints number to zero will suppress the MI
	breakpoint-deleted notification for that breakpoint, and indeed, this
	can be seen to be true, in delete_breakpoint, if the breakpoint number
	is zero, then GDB will not notify the breakpoint_deleted observer.

	It seems wrong that a user created, thread-specific breakpoint, will
	have a =breakpoint-created notification, but will not have a
	=breakpoint-deleted notification.  I suspect that this is a bug.

	[1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html

	The First Problem
	-----------------

	During my initial testing I wanted to see how GDB handled the
	breakpoint after it's number was set to zero.  To do this I created
	the testcase gdb.threads/thread-bp-deleted.exp.  This test creates a
	worker thread, which immediately exits.  After the worker thread has
	exited the main thread spins in a loop.

	In GDB I break once the worker thread has been created and place a
	thread-specific breakpoint, then use 'continue&' to resume the
	inferior in non-stop mode.  The worker thread then exits, but the main
	thread never stops - instead it sits in the spin.  I then tried to use
	'maint info breakpoints' to see what GDB thought of the
	thread-specific breakpoint.

	Unfortunately, GDB crashed like this:

	  (gdb) continue&
	  Continuing.
	  (gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited]
	  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
	  maint info breakpoints
	  ... snip some output ...

	  Fatal signal: Segmentation fault
	  ----- Backtrace -----
	  0x5ffb62 gdb_internal_backtrace_1
	          ../../src/gdb/bt-utils.c:122
	  0x5ffc05 _Z22gdb_internal_backtracev
	          ../../src/gdb/bt-utils.c:168
	  0x89965e handle_fatal_signal
	          ../../src/gdb/event-top.c:964
	  0x8997ca handle_sigsegv
	          ../../src/gdb/event-top.c:1037
	  0x7f96f5971b1f ???
	          /usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
	  0xe602b0 _Z15print_thread_idP11thread_info
	          ../../src/gdb/thread.c:1439
	  0x5b3d05 print_one_breakpoint_location
	          ../../src/gdb/breakpoint.c:6542
	  0x5b462e print_one_breakpoint
	          ../../src/gdb/breakpoint.c:6702
	  0x5b5354 breakpoint_1
	          ../../src/gdb/breakpoint.c:6924
	  0x5b58b8 maintenance_info_breakpoints
	          ../../src/gdb/breakpoint.c:7009
	  ... etc ...

	As the thread-specific breakpoint is set to disp_del_at_next_stop, and
	GDB hasn't stopped yet, then the breakpoint still exists in the global
	breakpoint list.

	The breakpoint will not show in 'info breakpoints' as its number is
	zero, but it will show in 'maint info breakpoints'.

	As GDB prints the breakpoint, the thread-id for the breakpoint is
	printed as part of the 'stop only in thread ...' line.  Printing the
	thread-id involves calling find_thread_global_id to convert the global
	thread-id into a thread_info*.  Then calling print_thread_id to
	convert the thread_info* into a string.

	The problem is that find_thread_global_id returns nullptr as the
	thread for the thread-specific breakpoint has exited.  The
	print_thread_id assumes it will be passed a non-nullptr.  As a result
	GDB crashes.

	In this commit I've added an assert to print_thread_id (gdb/thread.c)
	to check that the pointed passed in is not nullptr.  This assert would
	have triggered in the above case before GDB crashed.

	MI Notifications: The Dangers Of Changing A Breakpoint's Number
	---------------------------------------------------------------

	Currently the delete_breakpoint function doesn't trigger the
	breakpoint_deleted observer for any breakpoint with the number zero.

	There is a comment explaining why this is the case in the code; it's
	something about watchpoints.  But I did consider just removing the 'is
	the number zero' guard and always triggering the breakpoint_deleted
	observer, figuring that I'd then fix the watchpoint issue some other
	way.

	But I realised this wasn't going to be good enough.  When the MI
	notification was delivered the number would be zero, so any frontend
	parsing the notifications would not be able to match
	=breakpoint-deleted notification to the earlier =breakpoint-created
	notification.

	What this means is that, at the point the breakpoint_deleted observer
	is called, the breakpoint's number must be correct.

	MI Notifications: The Dangers Of Delaying Deletion
	--------------------------------------------------

	The test I used to expose the above crash also brought another problem
	to my attention.  In the above test we used 'continue&' to resume,
	after which a thread exited, but the inferior didn't stop.  Recreating
	the same test in the MI looks like this:

	  -break-insert -p 2 main
	  ^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...}
	  (gdb)
	  -exec-continue
	  ^running
	  *running,thread-id="all"
	  (gdb)
	  ~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n"
	  =thread-exited,id="2",group-id="i1"
	  ~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n"

	At this point the we have a single thread left, which is still
	running:

	  -thread-info
	  ^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1"
	  (gdb)

	Notice that we got the =thread-exited notification from GDB as soon as
	the thread exited.  We also saw the CLI line from GDB, the line
	explaining that breakpoint 2 was deleted.  But, as expected, we didn't
	see the =breakpoint-deleted notification.

	I say "as expected" because the number was set to zero.  But, even if
	the number was not set to zero we still wouldn't see the
	notification.  The MI notification is driven by the breakpoint_deleted
	observer, which is only called when we actually delete the breakpoint,
	which is only done the next time GDB stops.

	Now, maybe this is fine.  The notification is delivered a little
	late.  But remember, by setting the number to zero the breakpoint will
	be hidden from the user, for example, the breakpoint is removed from
	the MI's -break-info command output.

	This means that GDB is in a position where the breakpoint doesn't show
	up in the breakpoint table, but a =breakpoint-deleted notification has
	not yet been sent out.  This doesn't seem right to me.

	What this means is that, when the thread exits, we should immediately
	be sending out the =breakpoint-deleted notification.  We should not
	wait for GDB to next stop before sending the notification.

	The Solution
	------------

	My proposed solution is this; in remove_threaded_breakpoints, instead
	of setting the disposition to disp_del_at_next_stop and setting the
	number to zero, we now just call delete_breakpoint directly.

	The notification will now be sent out immediately; as soon as the
	thread exits.

	As the number has not changed when delete_breakpoint is called, the
	notification will have the correct number.

	And as the breakpoint is immediately removed from the breakpoint list,
	we no longer need to worry about 'maint info breakpoints' trying to
	print the thread-id for an exited thread.

	My only concern is that calling delete_breakpoint directly seems so
	obvious that I wonder why the original patch (that added
	remove_threaded_breakpoints) didn't take this approach.  This code was
	added in commit 49fa26b0411d, but the commit message offers no clues
	to why this approach was taken, and the original email thread offers
	no insights either[2].  There are no test regressions after making
	this change, so I'm hopeful that this is going to be fine.

	[2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html

	The Complication
	----------------

	Of course, it couldn't be that simple.

	The script gdb.python/py-finish-breakpoint.exp had some regressions
	during testing.

	The problem was with the FinishBreakpoint.out_of_scope callback
	implementation.  This callback is supposed to trigger whenever the
	FinishBreakpoint goes out of scope; and this includes when the thread
	for the breakpoint exits.

	The problem I ran into is the Python FinishBreakpoint implementation.
	Specifically, after this change I was loosing some of the out_of_scope
	calls.

	The problem is that the out_of_scope call (of which I'm interested) is
	triggered from the inferior_exit observer.  Before my change the
	observers were called in this order:

	  thread_exit
	  inferior_exit
	  breakpoint_deleted

	The inferior_exit would trigger the out_of_scope call.

	After my change the breakpoint_deleted notification (for
	thread-specific breakpoints) occurs earlier, as soon as the
	thread-exits, so now the order is:

	  thread_exit
	  breakpoint_deleted
	  inferior_exit

	Currently, after the breakpoint_deleted call the Python object
	associated with the breakpoint is released, so, when we get to the
	inferior_exit observer, there's no longer a Python object to call the
	out_of_scope method on.

	My solution is to follow the model for how bpfinishpy_pre_stop_hook
	and bpfinishpy_post_stop_hook are called, this is done from
	gdbpy_breakpoint_cond_says_stop in py-breakpoint.c.

	I've now added a new bpfinishpy_pre_delete_hook
	gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook
	function I check and where needed call the out_of_scope method.

	With this fix in place I now see the
	gdb.python/py-finish-breakpoint.exp test fully passing again.

	Testing
	-------

	Tested on x86-64/Linux with unix, native-gdbserver, and
	native-extended-gdbserver boards.

	New tests added to covers all the cases I've discussed above.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix failure in gdb.mi/mi-pending.exp with extended-remote
	I currently see this failure when running the gdb.mi/mi-pending.exp
	test using the native-extended-remote board:

	  -break-insert -f -c x==4 mi-pendshr.c:pendfunc2
	  &"No source file named mi-pendshr.c.\n"
	  ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="mi-pendshr.c:pendfunc2",cond="x==4",evaluated-by="host",times="0",original-location="mi-pendshr.c:pendfunc2"}
	  (gdb)
	  FAIL: gdb.mi/mi-pending.exp: MI pending breakpoint on mi-pendshr.c:pendfunc2 if x==4 (unexpected output)

	The failure is caused by the 'evaluated-by="host"' string, which only
	appears in the output when the test is run using the
	native-extended-remote board.

	I could fix this by just updating the pattern in
	gdb.mi/mi-pending.exp, but I have instead updated mi-pending.exp to
	make more use of the support procs in mi-support.exp.  This did
	require making a couple of adjustments to mi-support.exp, but I think
	the result is that mi-pending.exp is now easier to read, and I see no
	failures with native-extended-remote anymore.

	One of the test names has changed after this work, I think the old
	test name was wrong - it described a breakpoint as pending when the
	breakpoint was not pending, I suspect a copy & paste error.

	But there's no changes to what is actually being tested after this
	patch.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: introduce is_target_non_stop helper proc
	I noticed that several tests included copy & pasted code to run the
	'maint show target-non-stop' command, and then switch based on the
	result.

	In this commit I factor this code out into a helper proc in
	lib/gdb.exp, and update all the places I could find that used this
	pattern to make use of the helper proc.

	There should be no change in what is tested after this commit.

	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite introduce foreach_mi_ui_mode helper proc
	Introduce foreach_mi_ui_mode, a helper proc which can be used when
	tests are going to be repeated once with the MI in the main UI, and
	once with the MI on a separate UI.

	The proc is used like this:

	  foreach_mi_ui_mode VAR {
	    # BODY
	  }

	The BODY will be run twice, once with VAR set to 'main' and once with
	VAR set to 'separate', inside BODY we can then change the behaviour
	based on the current UI mode.

	The point of this proc is that we sometimes shouldn't run the separate
	UI tests (when gdb_debug_enabled is true), and this proc hides all
	this logic.  If the separate UI mode should not be used then BODY will
	be run just once with VAR set to 'main'.

	I've updated two tests that can make use of this helper proc.  I'm
	going to add another similar test in a later commit.

	There should be no change to what is tested with this commit.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: extend the use of mi_clean_restart
	The mi_clean_restart proc calls the mi_gdb_start proc passing no
	arguments.

	In this commit I add an extra (optional) argument to the
	mi_clean_restart proc, and pass this through to mi_gdb_start.

	The benefit of this is that we can now use mi_clean_restart when we
	also want to pass the 'separate-mi-tty' or 'separate-inferior-tty'
	flags to mi_gdb_start, and avoids having to otherwise duplicate the
	contents of mi_clean_restart in different tests.

	I've updated the obvious places where this new functionality can be
	used, and I'm seeing no test regressions.

	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: make more use of mi-support.exp
	Building on the previous commit, now that the breakpoint related
	support functions in lib/mi-support.exp can now help creating the
	patterns for thread specific breakpoints, make use of this
	functionality for gdb.mi/mi-nsmoribund.exp and gdb.mi/mi-pending.exp.

	There should be no changes in what is tested after this commit.

	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't duplicate 'thread' field in MI breakpoint output
	When creating a thread-specific breakpoint with a single location, the
	'thread' field would be repeated in the MI output.  This can be seen
	in two existing tests gdb.mi/mi-nsmoribund.exp and
	gdb.mi/mi-pending.exp, e.g.:

	  (gdb)
	  -break-insert -p 1 bar
	  ^done,bkpt={number="1",type="breakpoint",disp="keep",
		      enabled="y",
		      addr="0x000000000040110a",func="bar",
		      file="/tmp/mi-thread-specific-bp.c",
		      fullname="/tmp/mi-thread-specific-bp.c",
		      line="32",thread-groups=["i1"],
		      thread="1",thread="1",  <================ DUPLICATION!
		      times="0",original-location="bar"}

	I know we need to be careful when adjusting MI output, but I'm hopeful
	in this case, as the field is duplicated, and the field contents are
	always identical, that we might get away with removing one of the
	duplicates.

	The change in GDB is a fairly trivial condition change.

	We did have a couple of tests that contained the duplicate fields in
	their expected output, but given there was no comment pointing out
	this oddity either in the GDB code, or in the test, I suspect this was
	more a case of copying whatever output GDB produced and using that as
	the expected results.  I've updated these tests to remove the
	duplication.

	I've update lib/mi-support.exp to provide support for building
	breakpoint patterns that contain the thread field, and I've made use
	of this in a new test I've added that is just about creating
	thread-specific breakpoints and checking the results.  The two tests I
	mentioned above as being updated could also use the new
	lib/mi-support.exp functionality, but I'm going to do that in a later
	patch, this way it is clear what changes I'm actually proposing to
	make to the expected output.

	As I said, I hope that frontends will be able to handle this change,
	but I still think its worth adding a NEWS entry, that way, if someone
	runs into problems, there's a chance they can figure out what's going
	on.

	This should not impact CLI output at all.

	Reviewed-By: Eli Zaretskii <eliz@gnu.org>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-28  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove an out of date comment about disp_del_at_next_stop
	Delete an out of date comment about disp_del_at_next_stop, the comment
	says:

	  /* NOTE drow/2003-09-08: This state only exists for removing
	     watchpoints.  It's not clear that it's necessary...  */

	I'm sure this was true when the comment was added, but today the
	disp_del_at_next_stop state is not just used for deleting watchpoints,
	which leaves us with "It's not clear that it's necessary...", which
	doesn't really help at all.

	And then this comment is located on one random place where
	disp_del_at_next_stop is used, rather than at its definition site.

	Lets just delete the comment.

	No user visible changes after this commit.

	Reviewed-By: Pedro Alves <pedro@palves.net>

2023-02-28  Richard Ball  <richard.ball@arm.com>

	[Aarch64] Add Binutils support for MEC
	This change supports MEC which is part of RME (Realm Management Extension).

2023-02-28  Alan Modra  <amodra@gmail.com>

	chew.c printf of intptr_t
	Seen when building binutils with gcc -m32 on x86_64-linux.
	chew.c: In function ‘print’:
	chew.c:1434:59: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘intptr_t’ {aka ‘int’} [-Wformat=]
	 1434 |     fprintf (stderr, "print: illegal print destination `%ld'\n", *isp);
	      |                                                         ~~^      ~~~~
	      |                                                           |      |
	      |                                                           |      intptr_t {aka int}
	      |                                                           long int
	      |                                                         %d

		* chew.c: Include inttypes.h.
		(print): Use PRIdPTR for *isp.

2023-02-28  Mark Harmstone  <mark@harmstone.com>

	ld: Sort section contributions in PDB files
	Microsoft's DIA library, and thus also MSVC and WinDbg, expects section
	contributions to be ordered by section number and offset, otherwise it's
	unable to resolve line numbers.

2023-02-28  Alan Modra  <amodra@gmail.com>

	Free ecoff debug info
	This frees memory associated with the mips ecoff find_nearest_line.

		* elfxx-mips.x (free_ecoff_debug): New function, extracted from..
		(_bfd_mips_elf_read_ecoff_info): ..here.  Free ext_hdr earlier.
		Don't clear already NULL fdr.
		(struct mips_elf_find_line): Move earlier.
		(_bfd_mips_elf_close_and_cleanup): Call free_ecoff_debug.
		(_bfd_mips_elf_find_nearest_line): Likewise on error paths,
		and to clean up input_debug when done.

2023-02-28  Alan Modra  <amodra@gmail.com>

	Add some sanity checking in ECOFF lookup_line
	More anti-fuzzer bounds checking for the ECOFF support.  A lot of this
	is in ancient code using "long" for counts and sizes, which is why the
	patch uses "(long) ((unsigned long) x + 1) > 0" in a few places.  The
	unsigned long cast is so that "x + 1" doesn't trigger ubsan warnings
	about signed integer overflow.  It would be a good idea to replace
	most of the longs used in binutils with size_t, but that's more than I
	care to do for COFF/ECOFF.

		* ecofflink.c (mk_fdrtab): Sanity check string offsets.
		(lookup_line): Likewise, and symbol indices.

2023-02-28  Alan Modra  <amodra@gmail.com>

	Another PE SEC_HAS_CONTENTS test
	I'd skipped this one before, thinking "obfd, that's the linker output
	bfd so no need to test".  Wrong, this is objcopy output.

		* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Test
		SEC_HAS_CONTENTS before reading section.

2023-02-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Forced quit cases handled by resetting sync_quit_force_run
	During my audit of the use of gdb_exception with regard to QUIT
	processing, I found a try/catch in the scoped_switch_fork_info
	destructor.

	Static analysis found this call path from the destructor to
	maybe_quit():

	  scoped_switch_fork_info::~scoped_switch_fork_info()
	    -> remove_breakpoints()
	    -> remove_breakpoint(bp_location*)
	    -> remove_breakpoint_1(bp_location*, remove_bp_reason)
	    -> memory_validate_breakpoint(gdbarch*, bp_target_info*)
	    -> target_read_memory(unsigned long, unsigned char*, long)
	    -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
	    -> maybe_quit()

	Since it's not safe to do a 'throw' from a destructor, we simply
	call set_quit_flag and, for gdb_exception_forced_quit, also
	set sync_quit_force_run.  This will cause the appropriate
	exception to be rethrown at the next QUIT check.

	Another case is the try / catch in tui_getc() in tui-io.c.  The
	existing catch swallows the exception.  I've added a catch for
	'gdb_exception_forced_quit', which also swallows the exception,
	but also sets sync_quit_force_run and calls set_quit_flag in
	order to restart forced quit processing at the next QUIT check.
	This is required because it isn't safe to throw into/through
	readline.

	Thanks to Pedro Alves for suggesting this idea.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Introduce set_force_quit_flag and change type of sync_quit_force_run
	At the moment, handle_sigterm() in event-top.c does the following:

	  sync_quit_force_run = 1;
	  set_quit_flag ();

	This was used several more times in a later patch in this series, so
	I'm introducing (at Pedro's suggestion) a new function named
	'set_force_quit_flag'.  It simply sets sync_quit_force_run and also
	calls set_quit_flag().  I've revised the later patch to call
	set_force_quit_flag instead.

	I noticed that sync_quit_force_run is declared as an int but is being
	used as a bool, so I also changed its type to bool in this commit.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	QUIT processing w/ explicit throw for gdb_exception_forced_quit
	This commit contains changes which have an explicit throw for
	gdb_exception_forced_quit, or, in a couple of cases for gdb_exception,
	but with a throw following a check to see if 'reason' is
	RETURN_FORCED_QUIT.

	Most of these are straightforward - it made sense to continue to allow
	an existing catch of gdb_exception to also catch gdb_exception_quit;
	in these cases, a catch/throw for gdb_exception_forced_quit was added.

	There are two cases, however, which deserve a more detailed
	explanation.

	1) remote_fileio_request in gdb/remote-fileio.c:

	The try block calls do_remote_fileio_request which can (in turn)
	call one of the functions in remote_fio_func_map[].  Taking the
	first one, remote_fileio_func_open(), we have the following call
	path to maybe_quit():

	  remote_fileio_func_open(remote_target*, char*)
	    -> target_read_memory(unsigned long, unsigned char*, long)
	    -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
	    -> maybe_quit()

	Since there is a path to maybe_quit(), we must ensure that the
	catch block is not permitted to swallow a QUIT representing a
	SIGTERM.

	However, for this case, we must take care not to change the way that
	Ctrl-C / SIGINT is handled; we want to send a suitable EINTR reply to
	the remote target should that happen.  That being the case, I added a
	catch/throw for gdb_exception_forced_quit.  I also did a bit of
	rewriting here, adding a catch for gdb_exception_quit in favor of
	checking the 'reason' code in the catch block for gdb_exception.

	2) mi_execute_command in gdb/mi/mi-main.c:

	The try block calls captured_mi_execute_command(); there exists
	a call path to maybe_quit():

	  captured_mi_execute_command(ui_out*, mi_parse*)
	    -> mi_cmd_execute(mi_parse*)
	    -> get_current_frame()
	    -> get_prev_frame_always_1(frame_info*)
	    -> frame_register_unwind_location(frame_info*, int, int*, lval_type*, unsigned long*, int*)
	    -> frame_register_unwind(frame_info*, int, int*, int*, lval_type*, unsigned long*, int*, unsigned char*)
	    -> value_entirely_available(value*)
	    -> value_fetch_lazy(value*)
	    -> value_fetch_lazy_memory(value*)
	    -> read_value_memory(value*, long, int, unsigned long, unsigned char*, unsigned long)
	    -> maybe_quit()

	That being the case, we can't allow the exception handler (catch block)
	to swallow a gdb_exception_quit for SIGTERM.  However, it does seem
	reasonable to output the exception via the mi interface so that some
	suitable message regarding SIGTERM might be printed; therefore, I
	check the exception's 'reason' field for RETURN_FORCED_QUIT and
	do a throw for this case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Guile QUIT processing updates
	This commit contains QUIT processing updates for GDB's Guile support.
	As with the Python updates, we don't want to permit this code to
	swallow the exception, gdb_exception_forced_quit, which is associated
	with GDB receiving a SIGTERM.

	I've adopted the same solution that I used for Python; whereever
	a gdb_exception is caught in try/catch code in the Guile extension
	language support, a catch for gdb_exception_forced_quit has been
	added; this catch block will simply call quit_force(), which will
	cause the necessary cleanups to occur followed by GDB exiting.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Python QUIT processing updates
	See the previous patches in this series for the motivation behind
	these changes.

	This commit contains updates to Python's QUIT handling.  Ideally, we'd
	like to throw gdb_exception_forced_quit through the extension
	language; I made an attempt to do this for gdb_exception_quit in an
	earlier version of this patch, but Pedro pointed out that it is
	(almost certainly) not safe to do so.

	Still, we definitely don't want to swallow the exception representing
	a SIGTERM for GDB, nor do we want to force modules written in the
	extension language to have to explicitly handle this case.  Since the
	idea is for GDB to cleanup and quit for this exception, we'll simply
	call quit_force() just as if the gdb_exception_forced_quit propagation
	had managed to make it back to the top level.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Catch gdb_exception_error instead of gdb_exception (in many places)
	As described in the previous commit for this series, I became
	concerned that there might be instances in which a QUIT (due to either
	a SIGINT or SIGTERM) might not cause execution to return to the top
	level.  In some (though very few) instances, it is okay to not
	propagate the exception for a Ctrl-C / SIGINT, but I don't think that
	it is ever okay to swallow the exception caused by a SIGTERM.
	Allowing that to happen would definitely be a deviation from the
	current behavior in which GDB exits upon receipt of a SIGTERM.

	I looked at all cases where an exception handler catches a
	gdb_exception.  Handlers which did NOT need modification were those
	which satisifed one or more of the following conditions:

	  1) There is no call path to maybe_quit() in the try block.  I used a
	     static analysis tool to help make this determination.  In
	     instances where the tool didn't provide an answer of "yes, this
	     call path can result in maybe_quit() being called", I reviewed it
	     by hand.

	  2) The catch block contains a throw for conditions that it
	     doesn't want to handle; these "not handled" conditions
	     must include the quit exception and the new "forced quit" exception.

	  3) There was (also) a catch for gdb_exception_quit.

	Any try/catch blocks not meeting the above conditions could
	potentially swallow a QUIT exception.

	My first thought was to add catch blocks for gdb_exception_quit and
	then rethrow the exception.  But Pedro pointed out that this can be
	handled without adding additional code by simply catching
	gdb_exception_error instead.  That's what this patch series does.

	There are some oddball cases which needed to be handled differently,
	plus the extension languages, but those are handled in later patches.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-by: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit
	When a GDB process receives the SIGTERM signal, handle_sigterm() in
	event-top.c is called.  The global variable 'sync_quit_force_run' is
	set by this signal handler.  It does some other things too, but the
	setting of this global is the important bit for the SIGTERM part of
	this discussion.

	GDB will periodically check to see whether a Ctrl-C or SIGTERM has
	been received.  This is performed via use of the QUIT macro in
	GDB's code.  QUIT is defined to invoke maybe_quit(), which will be
	periodically called during any lengthy operation.  This is supposed to
	ensure that the user won't have to wait too long for a Ctrl-C or
	SIGTERM to be acted upon.

	When a Ctrl-C / SIGINT is received, quit_handler() will decide whether
	to pass the SIGINT onto the inferior or to call quit() which causes
	gdb_exception_quit to be thrown.  This exception (usually) propagates
	to the top level.  Control is then returned to the top level event
	loop.

	At the moment, SIGTERM is handled very differently.  Instead of
	throwing an exception, quit_force() is called.  This does eventually
	cause GDB to exit(), but prior to that happening, the inferiors
	are killed or detached and other target related cleanup occurs.
	As shown in this discussion between Pedro Alves and myself...

	https://sourceware.org/pipermail/gdb-patches/2021-July/180802.html
	https://sourceware.org/pipermail/gdb-patches/2021-July/180902.html
	https://sourceware.org/pipermail/gdb-patches/2021-July/180903.html

	...we found that it is possible for inferior_ptid and current_thread_
	to get out of sync.  When that happens, the "current_thread_ != nullptr"
	assertion in inferior_thread() can fail resulting in a GDB internal
	error.

	Pedro recommended that we "let the normal quit exception propagate all
	the way to the top level, and then have the top level call quit_force
	if sync_quit_force_run is set."  However, after the v2 series for this
	patch set, we tweaked that idea by introducing a new exception for
	handling SIGTERM.

	This commit implements the obvious part of Pedro's suggestion:
	Instead of calling quit_force from quit(), throw_forced_quit() is now
	called instead.  This causes the new exception 'gdb_exception_forced_quit'
	to be thrown.

	At the top level, I changed catch_command_errors() and captured_main()
	to catch gdb_exception_forced_quit and then call quit_force() from the
	catch block.  I also changed start_event_loop() to also catch
	gdb_exception_forced_quit; while we could also call quit_force() from
	that catch block, it's sufficient to simply rethrow the exception
	since it'll be caught by the newly added code in captured_main().

	Making these changes fixed the failure / regression that I was seeing
	for gdb.base/gdb-sigterm.exp when run on a machine with glibc-2.34.
	However, there are many other paths back to the top level which this
	test case does not test.  I did an audit of all of the try / catch
	code in GDB in which calls in the try-block might (eventually) call
	QUIT.  I found many cases where gdb_exception_quit and the new
	gdb_exception_forced_quit will be swallowed.  (When using GDB, have
	you ever hit Ctrl-C and not have it do anything; if so, it could be
	due to a swallowed gdb_exception_quit in one of the cases I've
	identified.)  The rest of the patches in this series deal with this
	concern.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-by: Pedro Alves <pedro@palves.net>

2023-02-27  Kevin Buettner  <kevinb@redhat.com>

	Introduce gdb_exception_forced_quit
	This commit adds a new exception 'gdb_exception_forced_quit', reason
	code 'REASON_FORCED_QUIT', return mask 'RETURN_MASK_FORCED_QUIT', and
	a wrapper for throwing the exception, throw_forced_quit().

	The addition of this exception plus supporting code will allow us to
	recognize that a SIGTERM has been received by GDB and then propagate
	recognition of that fact to the upper levels of GDB where it can be
	correctly handled.  At the moment, when GDB receives a SIGTERM, it
	will attempt to exit via a series of calls from the QUIT checking
	code.  However, before it can exit, it must do various cleanups, such
	as killing or detaching all inferiors.  Should these cleanups be
	attempted while GDB is executing very low level code, such as reading
	target memory from within ps_xfer_memory(), it can happen that some of
	GDB's state is out of sync with regard to the cleanup code's
	expectations.  In the case just mentioned, it's been observed that
	inferior_ptid and the current_thread_ are not in sync; this triggers
	an assert / internal error.

	This commit only introduces the exception plus supporting machinery;
	changes which use this new exception are in later commits in this
	series.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
	Tested-by: Tom de Vries <tdevries@suse.de>
	Approved-by: Pedro Alves <pedro@palves.net>

2023-02-27  Tom Tromey  <tom@tromey.com>

	Fix value chain use-after-free
	Hannes filed a bug showing a crash, where a pretty-printer written in
	Python could cause a use-after-free.  He sent a patch, but I thought a
	different approach was needed.

	In a much earlier patch (see bug #12533), we changed the Python code
	to release new values from the value chain when constructing a
	gdb.Value.  The rationale for this is that if you write a command that
	does a lot of computations in a loop, all the values will be kept live
	by the value chain, resulting in gdb using a large amount of memory.

	However, suppose a value is passed to Python from some code in gdb
	that needs to use the value after the call into Python.  In this
	scenario, value_to_value_object will still release the value -- and
	because gdb code doesn't generally keep strong references to values (a
	consequence of the ancient decision to use the value chain to avoid
	memory management), this will result in a use-after-free.

	This scenario can happen, as it turns out, when a value is passed to
	Python for pretty-printing.  Now, normally this route boxes the value
	via value_to_value_object_no_release, avoiding the problematic release
	from the value chain.  However, if you then call Value.cast, the
	underlying value API might return the same value, when is then
	released from the chain.

	This patch fixes the problem by changing how value boxing is done.
	value_to_value_object no longer removes a value from the chain.
	Instead, every spot in gdb that might construct new values uses a
	scoped_value_mark to ensure that the requirements of bug #12533 are
	met.  And, because incoming values aren't ever released from the chain
	(the Value.cast one comes earlier on the chain than the
	scoped_value_mark), the bug can no longer occur.  (Note that many
	spots in the Python layer already take this approach, so not many
	places needed to be touched.)

	In the future I think we should replace the use of raw "value *" with
	value_ref_ptr pretty much everywhere.  This will ensure lifetime
	safety throughout gdb.

	The test case in this patch comes from Hannes' original patch.  I only
	made a trivial ("require") change to it.  However, while this fails
	for him, I can't make it fail on this machine; nevertheless, he tried
	my patch and reported the bug as being fixed.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044

2023-02-27  Pedro Alves  <pedro@palves.net>

	Remove infrun_thread_thread_exit observer
	After the previous patches, I believe this observer isn't necessary
	anymore for anything.  Remove it.

	Change-Id: Idb33fb6b6f55589c8c523a92169b3ca95a23d0b9

2023-02-27  Pedro Alves  <pedro@palves.net>

	all-stop "follow-fork parent" and selecting another thread
	With:

	 - catch a fork in thread 1
	 - select thread 2
	 - set follow-fork child
	 - next

	... follow_fork notices that thread 1 had last stopped for a fork
	which hasn't been followed yet, and because thread 1 is not the
	current thread, GDB aborts the execution command, presenting the stop
	in thread 1.

	That makes sense, as only the forking thread (thread 1) survives in
	the child, so better stop and let the user decide how to proceed.

	However, with:

	 - catch a fork in thread 1
	 - select thread 2
	 - set follow-fork parent << note difference here
	 - next

	... GDB does the same: follow_fork notices that thread 1 had last
	stopped for a fork which hasn't been followed yet, and because thread
	1 is not the current thread, GDB aborts the execution command,
	presenting the stop in thread 1.

	Aborting/stopping in this case doesn't make sense to me.  As we're
	following the parent, thread 2 will still continue to exist in the
	parent.  What the child does after we've followed the parent shouldn't
	matter -- it can go on running free, be detached, etc., depending on
	"set schedule-multiple", "set detach-on-fork", etc.  That does not
	influence the execution command that the user issued for the parent
	thread.

	So this patch changes GDB in that direction -- in follow_fork, if
	following the parent, and we've switched threads meanwhile, switch
	back to the unfollowed thread, follow it (stay with the parent), and
	don't abort/stop.  If we're following a fork (as opposed to vfork),
	then switch back again to the thread that the user was trying to
	resume.  If following a vfork, however, stay with the vforking-thread
	selected, as we will need to see a vfork_done event first, before we
	can resume any other thread.

	As I was working on this, I managed to end up calling target_resume
	for a solo-thread resume (to collect the vfork_done event), with
	scope_ptid pointing at the vfork parent thread, and inferior_ptid
	pointing to the vfork child.  For a solo-thread resume, the scope_ptid
	argument to target_resume must the same as inferior_ptid.  The mistake
	was caught by the assertion in target_resume, like so:

	...
	  [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [1722839.1722839.0] at 0x5555555553c3
	  [infrun] do_target_resume: resume_ptid=1722839.1722939.0, step=0, sig=GDB_SIGNAL_0
	../../src/gdb/target.c:2661: internal-error: target_resume: Assertion `inferior_ptid.matches (scope_ptid)' failed.
	...

	but I think it doesn't hurt to catch such a mistake earlier, hence the
	change in internal_resume_ptid.

	Change-Id: I896705506a16d2488b1bfb4736315dd966f4e412

2023-02-27  Pedro Alves  <pedro@palves.net>

	Make follow_fork not rely on get_last_target_status
	Currently, if

	  - you're in all-stop mode,
	  - the inferior last stopped because of a fork catchpoint,

	when you next resume the program, gdb checks whether it had last
	stopped for a fork/vfork, and if so,

	 a) if the current thread is the one that forked, gdb follows the
	   parent/child, depending on "set follow-fork" mode.

	 b) if the current thread is some other thread (because you switched
	   threads meanwhile), gdb switches back to that thread, gdb follows
	   the parent/child, and stops the resumption command.

	There's a problem in b), however -- if you have "set schedule-multiple
	off", which is the default, or "set scheduler-locking on", gdb will
	still switch back to the forking thread, even if you didn't want to
	resume it.  For example, with:

	  (gdb) catch fork
	  (gdb) c
	  * thread 1 stops for fork
	  (gdb) thread 2
	  (gdb) set scheduler-locking on
	  (gdb) c

	gdb switches back to thread 1, and follows the fork.

	Or with:

	  (gdb) add-inferior -exec prog
	  (gdb) inferior 2
	  (gdb) start
	  (gdb) inferior 1
	  (gdb) catch fork
	  (gdb) c
	  * thread 1.1 stops for fork
	  (gdb) inferior 2
	  (gdb) set schedule-multiple off # this is the default
	  (gdb) c

	gdb switches back to thread 1.1, and follows the fork.

	Another issue is that, because follow_fork relies on
	get_last_target_status to find the thread that has a pending fork, it
	is possible to confuse it.  For example, "run" or "start" call
	init_wait_for_inferior, which clears the last target status, so this:

	  (gdb) catch fork
	  (gdb) c
	  * thread 1 stops for fork
	  (gdb) add-inferior -exec prog
	  (gdb) inferior 2
	  (gdb) start
	  (gdb) set follow-fork child
	  (gdb) inferior 1
	  (gdb) n

	... does not follow to the fork child of inferior 1, because the
	get_last_target_status call in follow_fork doesn't return a
	TARGET_WAITKIND_FORKED.  Thanks to Simon for this example.

	All of the above are fixed by this patch.  It changes follow_fork to
	not look at get_last_target_status, but to instead iterate over the
	set of threads that the user is resuming, and find the one that has a
	pending_follow kind of fork/vfork.

	gdb.base/foll-fork.exp is augmented to exercise the last "start"
	scenario described above.  The other cases will be exercised in the
	testcase added by the following patch.

	Change-Id: Ifcca77e7b2456277387f40660ef06cec2b93b97e

2023-02-27  Pedro Alves  <pedro@palves.net>

	Improve "info program"
	With gdb.base/catch-follow-exec.exp, we currently see:

	~~~~~~~~~~~~~~~
	 (gdb)
	 continue
	 Continuing.
	 process 693251 is executing new program: /usr/bin/ls
	 [New inferior 2]
	 [New process 693251]
	 [Switching to process 693251]

	 Thread 2.1 "ls" hit Catchpoint 2 (exec'd /usr/bin/ls), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2
	 (gdb)
	 info prog
	 No selected thread.
	~~~~~~~~~~~~~~~

	Note the "No selected thread" output.  That is totally bogus, because
	there _is_ a selected thread.  What GDB really means, is that it can't
	find the thread that had the latest (user-visible) stop.  And that
	happens because "info program" gets that info from
	get_last_target_status, and the last target status has been cleared.

	However, GDB also checks if there is a selected thread, here:

	  if (ptid == null_ptid || ptid == minus_one_ptid)
	    error (_("No selected thread."));

	.. the null_ptid part.  That is also bogus, because what matters is
	the thread that last reported a stop, not the current thread:

	 - in all-stop mode, "info program" displays info about the last stop.
	   That may have happened on a thread different from the selected
	   thread.

	 - in non-stop mode, because all threads are controlled individually,
	   "info program" shows info about the last stop of the selected
	   thread.

	The current code already behaves this way, though in a poor way.  This
	patch reimplements it, such that the all-stop version now finds the
	thread that last reported an event via the 'previous_thread' strong
	reference.  Being a strong reference means that if that thread has
	exited since the event was reported, 'previous_thread' will still
	point to it, so we can say that the thread exited meanwhile.

	The patch also extends "info program" output a little, to let the user
	know which thread we are printing info for.  For example, for the
	gdb.base/catch-follow-exec.exp case we shown above, we now get:

	 (gdb) info prog
	 Last stopped for thread 2.1 (process 710867).
		 Using the running image of child process 710867.
	 Program stopped at 0x7ffff7fd0100.
	 It stopped at breakpoint 2.
	 Type "info stack" or "info registers" for more information.
	 (gdb)

	while in non-stop mode, we get:

	 (gdb) info prog
	 Selected thread 2.1 (process 710867).
		 Using the running image of child process 710867.
	 Program stopped at 0x7ffff7fd0100.
	 It stopped at breakpoint 2.
	 Type "info stack" or "info registers" for more information.
	 (gdb)

	In both cases, the first line of output is new.

	The existing code considered these running/exited cases as an error,
	but I think that that's incorrect, since this is IMO just plain
	execution info as well.  So the patch makes those cases regular
	prints, not errors.

	If the thread is running, we get, in non-stop mode:

	 (gdb) info prog
	 Selected thread 2.1 (process 710867).
	 Selected thread is running.

	... and in all-stop:

	 (gdb) info prog
	 Last stopped for thread 2.1 (process 710867).
	 Thread is now running.

	If the thread has exited, we get, in non-stop mode:

	 (gdb) info prog
	 Selected thread 2.1 (process 710867).
	 Selected thread has exited.

	... and in all-stop:

	 (gdb) info prog
	 Last stopped for thread 2.1 (process 710867).
	 Thread has since exited.

	The gdb.base/info-program.exp testcase was much extended to test
	all-stop/non-stop and single-threaded/multi-threaded.

	Change-Id: I51d9d445f772d872af3eead3449ad4aa445781b1

2023-02-27  Pedro Alves  <pedro@palves.net>

	Convert previous_inferior_ptid to strong reference to thread_info
	I originally wrote this patch, because while working on some other
	patch, I spotted a regression in the
	gdb.multi/multi-target-no-resumed.exp.exp testcase.  Debugging the
	issue, I realized that the problem was related to how I was using
	previous_inferior_ptid to look up the thread the user had last
	selected.  The problem is that previous_inferior_ptid alone doesn't
	tell you which target that ptid is from, and I was just always using
	the current target, which was incorrect.  Two different targets may
	have threads with the same ptid.

	I decided to fix this by replacing previous_inferior_ptid with a
	strong reference to the thread, called previous_thread.

	I have since found a new motivation for this change -- I would like to
	tweak "info program" to not rely on get_last_target_status returning a
	ptid that still exists in the thread list.  With both the follow_fork
	changes later in this series, and the step-over-thread-exit changes,
	that can happen, as we'll delete threads and not clear the last
	waitstatus.

	A new update_previous_thread function is added that can be used to
	update previous_thread from inferior_ptid.  This must be called in
	several places that really want to get rid of previous_thread thread,
	and reset the thread id counter, otherwise we get regressions like
	these:

	  (gdb) info threads -gid
	    Id   GId  Target Id                               Frame
	 - * 1    1    Thread 2974541.2974541 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
	 - (gdb) PASS: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid
	 + * 1    2    Thread 2958361.2958361 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
	 + (gdb) FAIL: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid

	and:

	  Core was generated by `build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/si'.
	  Program terminated with signal SIGTRAP, Trace/breakpoint trap.
	  #0  gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
	  398      kill (getpid (), SIGABRT);
	 +[Current thread is 1 (LWP 2662066)]
	  Restored records from core file build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/sigall.precsave.
	  #0  gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
	  398      kill (getpid (), SIGABRT);

	  continue
	  Continuing.

	 -Program received signal SIGABRT, Aborted.
	 +Thread 1 received signal SIGABRT, Aborted.
	  0x00007ffff7dfd55b in kill () at ../sysdeps/unix/syscall-template.S:78
	  78     ../sysdeps/unix/syscall-template.S: No such file or directory.
	 -(gdb) PASS: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT
	 +(gdb) FAIL: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT

	I.e., GDB was failing to restart the thread counter back to 1, because
	the previous_thread thread was being help due to the strong reference.

	Tested on GNU/Linux native, gdbserver and gdbserver + "maint set
	target-non-stop on".

	gdb/ChangeLog:
	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

		* infcmd.c (kill_command, detach_command, disconnect_command):
		Call update_previous_thread.
		* infrun.c (previous_inferior_ptid): Delete.
		(previous_thread): New.
		(update_previous_thread): New.
		(proceed, init_wait_for_inferior): Call update_previous_thread.
		(normal_stop): Adjust to compare previous_thread and
		inferior_thread.  Call update_previous_thread.
		* infrun.h (update_previous_thread): Declare.
		* target.c (target_pre_inferior, target_preopen): Call
		update_previous_thread.

	Change-Id: I42779a1ee51a996fa1e8f6e1525c6605dbfd42c7

2023-02-27  Pedro Alves  <pedro@palves.net>

	Tweak "Using the running image of ..." output
	Currently, "info files" and "info program" on a few native targets
	show:

	 (gdb) info files
	 Symbols from "/home/pedro/gdb/tests/threads".
	 Native process:
		 Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	 ...

	 (gdb) info program
		 Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	 Program stopped at 0x555555555278.
	 ...


	This patch changes them to:

	 (gdb) info files
	 Symbols from "/home/pedro/gdb/tests/threads".
	 Native process:
		 Using the running image of child process 1097968.
		                                  ^^^^^^^^^^^^^^^
	 ...

	 (gdb) info program
		 Using the running image of child process 1097968.
		                                  ^^^^^^^^^^^^^^^
	 Program stopped at 0x555555555278.
	 ...


	... which I think makes a lot more sense in this context.  The "info
	program" manual entry even says:

	  "Display information about the status of your program: whether it is
	   running or not, what process it is, and why it stopped."
	                        ^^^^^^^^^^^^^

	This change affects ptrace targets, procfs targets, and Windows.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I6aab061ff494a84ba3398cf98fd49efd7a6ec1ca

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make-target-delegates.py: add type annotations
	Fixes all warnings given by pyright.

	Change-Id: I480521bfc62960c4eccd9d32c886392b05a1ddaa
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make-target-delegates.py: add Entry type
	Add the Entry type and use it in the `entries` map, rather than using an
	ad-hoc str -> str map that comes from the re.match.  This will make it
	easier to make typing work in a subsequent patch, but it also helps
	readers know what attributes exist for entries, which is not clear
	currently.

	Change-Id: I5b58dee1ed7ae85987b99bd417e641ede718624c
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make-target-delegates.py: make one string raw
	Fixes the following flake8 warning:

	  make-target-delegates.py:36:39: W605 invalid escape sequence '\s'

	Change-Id: I25eeb296f55765e17e5217a2d1e49018f63a3acd
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: gdbarch*.py, copyright.py: add type annotations
	Add type annotations to gdbarch*.py to fix all errors shown by pyright.
	There is one change in copyright.py too, to fix this one:

	    /home/simark/src/binutils-gdb/gdb/gdbarch.py
	      /home/simark/src/binutils-gdb/gdb/gdbarch.py:206:13 - error: Type of "copyright" is partially unknown
	        Type of "copyright" is "(tool: Unknown, description: Unknown) -> str" (reportUnknownMemberType)

	Change-Id: Ia109b53e267f6e2f5bd79a1288d0d5c9508c9ac4
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: split gdbarch component types to gdbarch_types.py
	Editing gdbarch-components.py is not an experience in an editor that is
	minimally smart about Python.  Because gdbarch-components.py is read and
	exec'd by gdbarch.py, it doesn't import the  Info / Method / Function /
	Value types.  And because these types are defined in gdbarch.py, it
	can't import them, as that would make a cyclic dependency.

	Solve this by introducing a third file, gdbarch_types.py, to define
	these types.  Make gdbarch.py and gdbarch-components.py import it.
	Also, replace the read & exec of gdbarch-components.py by a regular
	import.  For this to work though, gdbarch-components.py needs to be
	renamed to gdbarch_components.py.

	Change-Id: Ibe994d56ef9efcc0698b3ca9670d4d9bf8bbb853
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: pyproject.toml: set pyright typeCheckingMode = "strict"
	While working on other projects, I found the pyright type checker very
	helpful when editing Python code.  I don't think I have to explain the
	advantages of type checking to a crowd used to C/C++.

	Setting typeCheckingMode to "strict" makes pyright flag a bit more type
	issues than the default of "basic".

	Change-Id: I38818ec59f7f73c2ab020cc9226286cdd485abc7
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: gdbarch.py: remove Info.__init__
	Info.__init__ currently assigns `self.predicate = None`.  This was
	helpful to ensure that all component types had a `predicate` attribute.
	The generator code could then avoid having code like "if the component
	is anything but Info, use predicate".  Since the previous commit, all
	component types have a predicate attribute which defaults to False.  We
	can therefore remove the assignment in Info.__init__, and in turn remove
	Info.__init__.  We however need to make the printer parameter of
	_Component.__init__ optional, as Info don't need a printer.

	Change-Id: I611edeca9cc9837eb49dddfe038595e1ff3b7239
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: gdbarch.py: spell out parameters of _Component.__init__
	The way _Component uses kwargs is handy to save a few characters, but it
	doesn't play well with static analysis.  When editing gdbarch.py, my
	editor (which uses pylance under the hood) knows nothing about the
	properties of components.  So it's full of squiggly lines, and typing
	analysis (which I find really helpful) doesn't work.  I therefore think
	it would be better to spell out the parameters.

	Change-Id: Iaf561beb0d0fbe170ce1c79252a291e0945e1830
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: reformat Python files with black 23.1.0
	Change-Id: Ie8ec8870a16d71c5858f5d08958309d23c318302
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove invalid / dead code from gdbarch.py
	My editor flagged that the variable `c` (in the lines removed by this
	patch) was unknown.  I guess it ends up working because there is a `c`
	variable in the global scope.  I tried putting `assert False` inside
	that if, and it is not hit, showing that we never enter this if.  So,
	remove it.  There is no change in the generated files.

	Change-Id: Id3b9f67719e88cada7c6fde673c8d7842ab13617
	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-27  Tom Tromey  <tom@tromey.com>

	Fix crash with "finish" in Rust
	PR rust/30090 points out that a certain "finish" in a Rust program
	will cause gdb to crash.  This happens due to some confusion about
	field indices in rust_language::print_enum.  The fix is to use
	value_primitive_field so that the correct type can be passed; other
	spots in rust-lang.c already do this.

	Note that the enclosed test case comes with an xfail.  This is needed
	because for this function, rustc doesn't follow the platform ABI.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30090

2023-02-27  Tom Tromey  <tom@tromey.com>

	Remove old GNU indent directives
	Now that gdb_indent.sh has been removed, I think it makes sense to
	also remove the directives intended for GNU indent.

2023-02-27  Tom Tromey  <tromey@adacore.com>

	Handle range types in ax-gdb.c
	A range type can usually be treated the same as its underlying integer
	type, at least for the purposes of agent expressions.  This patch
	arranges for range types to be handled this way in ax-gdb.c, letting a
	somewhat larger subset of Ada expressions be compiled.

2023-02-27  Tom Tromey  <tromey@adacore.com>

	Implement some agent expressions for Ada
	Ada historically has not implemented agent expressions, and some Ada
	constructs probably cannot reasonably be converted to agent
	expressions.  However, a subset of simple operations can be, and this
	patch represents a first step in that direction.

	On one internal AdaCore test case, this improves the performance of a
	conditional breakpoint from 5 minutes to 5 seconds.

	The main tricky part in this patch is ensuring the converted
	expressions detect the cases that will not work.  This is done by
	examining the code in the corresponding evaluation methods.

2023-02-27  Pedro Alves  <pedro@palves.net>

	Regenerate Linux syscall group info
	This commit makes use of the new script to regenerate the Linux
	syscall group info against strace git hash
	e88e5e9ae6da68f22d15f9be3193b1412ac9aa02.

	Like so:

	 $ cd gdb/syscalls/
	 $ ./update-linux-defaults.sh ~/strace.git/
	 Generating linux-defaults.xml.in
	 $ make
	 for f in aarch64-linux.xml amd64-linux.xml arm-linux.xml bfin-linux.xml \
	          i386-linux.xml mips-n32-linux.xml mips-n64-linux.xml \
		  mips-o32-linux.xml ppc64-linux.xml ppc-linux.xml s390-linux.xml \
		  s390x-linux.xml sparc64-linux.xml sparc-linux.xml; do \
	   xsltproc --output $f apply-defaults.xsl $f.in; \
	 done

	The result is that a lot more syscalls end up assigned to groups.
	Some lose their group info, but that just mirrors what strace does.

	The gdb/syscalls/linux-defaults.xml.in file shows a large diff because
	the new version is ASCII sorted, while the current version was
	somewhat (but not consistently) sorted by "family" of syscalls.

	If I sort the old file and diff against the new, the difference is
	like this:

	     <syscall name="accept4" groups="network"/>
	     <syscall name="accept" groups="network"/>
	     <syscall name="access" groups="file"/>
	     <syscall name="acct" groups="file"/>
	  -  <syscall name="arch_prctl" groups="process"/>
	     <syscall name="bind" groups="network"/>
	  +  <syscall name="bpf" groups="descriptor"/>
	     <syscall name="break" groups="memory"/>
	     <syscall name="brk" groups="memory"/>
	  +  <syscall name="bsd43_fstatfs" groups="descriptor"/>
	  +  <syscall name="bsd43_fstat" groups="descriptor"/>
	  +  <syscall name="bsd43_killpg" groups="process"/>
	  +  <syscall name="bsd43_kill" groups="process"/>
	  +  <syscall name="bsd43_lstat" groups="file"/>
	  +  <syscall name="bsd43_madvise" groups="memory"/>
	  +  <syscall name="bsd43_mincore" groups="memory"/>
	  +  <syscall name="bsd43_mmap" groups="descriptor,memory"/>
	  +  <syscall name="bsd43_mprotect" groups="memory"/>
	  +  <syscall name="bsd43_mremap" groups="memory"/>
	  +  <syscall name="bsd43_munmap" groups="memory"/>
	  +  <syscall name="bsd43_oldfstat" groups="descriptor"/>
	  +  <syscall name="bsd43_oldstat" groups="file"/>
	  +  <syscall name="bsd43_quotactl" groups="file"/>
	  +  <syscall name="bsd43_sbreak" groups="memory"/>
	  +  <syscall name="bsd43_sbrk" groups="memory"/>
	  +  <syscall name="bsd43_statfs" groups="file"/>
	  +  <syscall name="bsd43_stat" groups="file"/>
	  +  <syscall name="cacheflush" groups="memory"/>
	     <syscall name="chdir" groups="file"/>
	     <syscall name="chmod" groups="file"/>
	     <syscall name="chown32" groups="file"/>
	     <syscall name="chown" groups="file"/>
	     <syscall name="chroot" groups="file"/>
	  +  <syscall name="clone2" groups="process"/>
	  +  <syscall name="clone3" groups="process"/>
	     <syscall name="clone" groups="process"/>
	     <syscall name="close" groups="descriptor"/>
	     <syscall name="connect" groups="network"/>
	  +  <syscall name="copy_file_range" groups="descriptor"/>
	     <syscall name="creat" groups="descriptor,file"/>
	     <syscall name="dup2" groups="descriptor"/>
	     <syscall name="dup3" groups="descriptor"/>
	  @@ -28,14 +52,17 @@
	     <syscall name="epoll_create1" groups="descriptor"/>
	     <syscall name="epoll_create" groups="descriptor"/>
	     <syscall name="epoll_ctl" groups="descriptor"/>
	  +  <syscall name="epoll_pwait2" groups="descriptor"/>
	     <syscall name="epoll_pwait" groups="descriptor"/>
	     <syscall name="epoll_wait" groups="descriptor"/>
	     <syscall name="eventfd2" groups="descriptor"/>
	     <syscall name="eventfd" groups="descriptor"/>
	  +  <syscall name="execveat" groups="descriptor,file,process"/>
	     <syscall name="execve" groups="file,process"/>
	     <syscall name="execv" groups="file,process"/>
	     <syscall name="exit_group" groups="process"/>
	     <syscall name="exit" groups="process"/>
	  +  <syscall name="faccessat2" groups="descriptor,file"/>
	     <syscall name="faccessat" groups="descriptor,file"/>
	     <syscall name="fadvise64_64" groups="descriptor"/>
	     <syscall name="fadvise64" groups="descriptor"/>
	  @@ -57,7 +84,11 @@
	     <syscall name="flock" groups="descriptor"/>
	     <syscall name="fork" groups="process"/>
	     <syscall name="fremovexattr" groups="descriptor"/>
	  +  <syscall name="fsconfig" groups="descriptor,file"/>
	     <syscall name="fsetxattr" groups="descriptor"/>
	  +  <syscall name="fsmount" groups="descriptor"/>
	  +  <syscall name="fsopen" groups="descriptor"/>
	  +  <syscall name="fspick" groups="descriptor,file"/>
	     <syscall name="fstat64" groups="descriptor"/>
	     <syscall name="fstatat64" groups="descriptor,file"/>
	     <syscall name="fstatfs64" groups="descriptor"/>
	  @@ -72,16 +103,26 @@
	     <syscall name="getdents" groups="descriptor"/>
	     <syscall name="get_mempolicy" groups="memory"/>
	     <syscall name="getpeername" groups="network"/>
	  +  <syscall name="getpmsg" groups="network"/>
	     <syscall name="getsockname" groups="network"/>
	     <syscall name="getsockopt" groups="network"/>
	     <syscall name="getxattr" groups="file"/>
	  -  <syscall name="inotify_add_watch" groups="descriptor"/>
	  +  <syscall name="inotify_add_watch" groups="descriptor,file"/>
	     <syscall name="inotify_init1" groups="descriptor"/>
	     <syscall name="inotify_init" groups="descriptor"/>
	     <syscall name="inotify_rm_watch" groups="descriptor"/>
	     <syscall name="ioctl" groups="descriptor"/>
	  +  <syscall name="io_destroy" groups="memory"/>
	  +  <syscall name="io_setup" groups="memory"/>
	  +  <syscall name="io_uring_enter" groups="descriptor,signal"/>
	  +  <syscall name="io_uring_register" groups="descriptor,memory"/>
	  +  <syscall name="io_uring_setup" groups="descriptor"/>
	     <syscall name="ipc" groups="ipc"/>
	  -  <syscall name="kill" groups="signal"/>
	  +  <syscall name="kexec_file_load" groups="descriptor"/>
	  +  <syscall name="kill" groups="signal,process"/>
	  +  <syscall name="landlock_add_rule" groups="descriptor"/>
	  +  <syscall name="landlock_create_ruleset" groups="descriptor"/>
	  +  <syscall name="landlock_restrict_self" groups="descriptor"/>
	     <syscall name="lchown32" groups="file"/>
	     <syscall name="lchown" groups="file"/>
	     <syscall name="lgetxattr" groups="file"/>
	  @@ -98,19 +139,31 @@
	     <syscall name="lstat" groups="file"/>
	     <syscall name="madvise" groups="memory"/>
	     <syscall name="mbind" groups="memory"/>
	  +  <syscall name="memfd_create" groups="descriptor"/>
	  +  <syscall name="memfd_secret" groups="descriptor"/>
	     <syscall name="migrate_pages" groups="memory"/>
	     <syscall name="mincore" groups="memory"/>
	     <syscall name="mkdirat" groups="descriptor,file"/>
	     <syscall name="mkdir" groups="file"/>
	     <syscall name="mknodat" groups="descriptor,file"/>
	     <syscall name="mknod" groups="file"/>
	  +  <syscall name="mlock2" groups="memory"/>
	     <syscall name="mlockall" groups="memory"/>
	     <syscall name="mlock" groups="memory"/>
	     <syscall name="mmap2" groups="descriptor,memory"/>
	     <syscall name="mmap" groups="descriptor,memory"/>
	  +  <syscall name="mount_setattr" groups="descriptor,file"/>
	     <syscall name="mount" groups="file"/>
	  +  <syscall name="move_mount" groups="descriptor,file"/>
	     <syscall name="move_pages" groups="memory"/>
	     <syscall name="mprotect" groups="memory"/>
	  +  <syscall name="mq_getsetattr" groups="descriptor"/>
	  +  <syscall name="mq_notify" groups="descriptor"/>
	  +  <syscall name="mq_open" groups="descriptor"/>
	  +  <syscall name="mq_timedreceive" groups="descriptor"/>
	  +  <syscall name="mq_timedreceive_time64" groups="descriptor"/>
	  +  <syscall name="mq_timedsend" groups="descriptor"/>
	  +  <syscall name="mq_timedsend_time64" groups="descriptor"/>
	     <syscall name="mremap" groups="memory"/>
	     <syscall name="msgctl" groups="ipc"/>
	     <syscall name="msgget" groups="ipc"/>
	  @@ -126,45 +179,98 @@
	     <syscall name="oldfstat" groups="descriptor"/>
	     <syscall name="oldlstat" groups="file"/>
	     <syscall name="oldstat" groups="file"/>
	  +  <syscall name="oldumount" groups="file"/>
	  +  <syscall name="openat2" groups="descriptor,file"/>
	     <syscall name="openat" groups="descriptor,file"/>
	     <syscall name="open_by_handle_at" groups="descriptor"/>
	     <syscall name="open" groups="descriptor,file"/>
	  +  <syscall name="open_tree" groups="descriptor,file"/>
	  +  <syscall name="osf_fstatfs64" groups="descriptor"/>
	  +  <syscall name="osf_fstatfs" groups="descriptor"/>
	  +  <syscall name="osf_fstat" groups="descriptor"/>
	  +  <syscall name="osf_lstat" groups="file"/>
	  +  <syscall name="osf_mincore" groups="memory"/>
	  +  <syscall name="osf_mremap" groups="memory"/>
	  +  <syscall name="osf_old_fstat" groups="descriptor"/>
	  +  <syscall name="osf_old_killpg" groups="process"/>
	  +  <syscall name="osf_old_lstat" groups="file"/>
	  +  <syscall name="osf_old_stat" groups="file"/>
	  +  <syscall name="osf_sbrk" groups="memory"/>
	  +  <syscall name="osf_select" groups="descriptor"/>
	  +  <syscall name="osf_shmat" groups="ipc,memory"/>
	  +  <syscall name="osf_sigprocmask" groups="signal"/>
	  +  <syscall name="osf_statfs64" groups="file"/>
	  +  <syscall name="osf_statfs" groups="file"/>
	  +  <syscall name="osf_stat" groups="file"/>
	  +  <syscall name="osf_utimes" groups="file"/>
	  +  <syscall name="osf_wait4" groups="process"/>
	     <syscall name="pause" groups="signal"/>
	     <syscall name="perf_event_open" groups="descriptor"/>
	  +  <syscall name="pidfd_getfd" groups="descriptor"/>
	  +  <syscall name="pidfd_open" groups="descriptor"/>
	  +  <syscall name="pidfd_send_signal" groups="descriptor,signal,process"/>
	     <syscall name="pipe2" groups="descriptor"/>
	     <syscall name="pipe" groups="descriptor"/>
	     <syscall name="pivot_root" groups="file"/>
	  +  <syscall name="pkey_mprotect" groups="memory"/>
	     <syscall name="poll" groups="descriptor"/>
	  +  <syscall name="posix_fstatfs" groups="descriptor"/>
	  +  <syscall name="posix_fstat" groups="descriptor"/>
	  +  <syscall name="posix_kill" groups="process"/>
	  +  <syscall name="posix_lstat" groups="file"/>
	  +  <syscall name="posix_madvise" groups="memory"/>
	  +  <syscall name="posix_mmap" groups="descriptor,memory"/>
	  +  <syscall name="posix_munmap" groups="memory"/>
	  +  <syscall name="posix_sbreak" groups="memory"/>
	  +  <syscall name="posix_SGI_madvise" groups="memory"/>
	  +  <syscall name="posix_SGI_mmap" groups="descriptor,memory"/>
	  +  <syscall name="posix_SGI_mprotect" groups="memory"/>
	  +  <syscall name="posix_SGI_msync" groups="memory"/>
	  +  <syscall name="posix_SGI_munmap" groups="memory"/>
	  +  <syscall name="posix_statfs" groups="file"/>
	  +  <syscall name="posix_stat" groups="file"/>
	     <syscall name="ppoll" groups="descriptor"/>
	  +  <syscall name="ppoll_time64" groups="descriptor"/>
	     <syscall name="pread64" groups="descriptor"/>
	     <syscall name="pread" groups="descriptor"/>
	  +  <syscall name="preadv2" groups="descriptor"/>
	     <syscall name="preadv" groups="descriptor"/>
	  +  <syscall name="process_madvise" groups="descriptor"/>
	  +  <syscall name="process_mrelease" groups="descriptor"/>
	     <syscall name="pselect6" groups="descriptor"/>
	  +  <syscall name="pselect6_time64" groups="descriptor"/>
	  +  <syscall name="putpmsg" groups="network"/>
	     <syscall name="pwrite64" groups="descriptor"/>
	     <syscall name="pwrite" groups="descriptor"/>
	  +  <syscall name="pwritev2" groups="descriptor"/>
	     <syscall name="pwritev" groups="descriptor"/>
	  +  <syscall name="quotactl_fd" groups="descriptor"/>
	     <syscall name="quotactl" groups="file"/>
	     <syscall name="readahead" groups="descriptor"/>
	     <syscall name="readdir" groups="descriptor"/>
	  -  <syscall name="read" groups="descriptor"/>
	     <syscall name="readlinkat" groups="descriptor,file"/>
	     <syscall name="readlink" groups="file"/>
	  +  <syscall name="read" groups="descriptor"/>
	     <syscall name="readv" groups="descriptor"/>
	     <syscall name="recvfrom" groups="network"/>
	  -  <syscall name="recv" groups="network"/>
	  +  <syscall name="recvmmsg_time64" groups="network"/>
	     <syscall name="recvmmsg" groups="network"/>
	     <syscall name="recvmsg" groups="network"/>
	  +  <syscall name="recv" groups="network"/>
	     <syscall name="remap_file_pages" groups="memory"/>
	     <syscall name="removexattr" groups="file"/>
	  +  <syscall name="renameat2" groups="descriptor,file"/>
	     <syscall name="renameat" groups="descriptor,file"/>
	     <syscall name="rename" groups="file"/>
	  +  <syscall name="riscv_flush_icache" groups="memory"/>
	     <syscall name="rmdir" groups="file"/>
	     <syscall name="rt_sigaction" groups="signal"/>
	     <syscall name="rt_sigpending" groups="signal"/>
	     <syscall name="rt_sigprocmask" groups="signal"/>
	  -  <syscall name="rt_sigqueueinfo" groups="signal"/>
	  +  <syscall name="rt_sigqueueinfo" groups="signal,process"/>
	     <syscall name="rt_sigreturn" groups="signal"/>
	     <syscall name="rt_sigsuspend" groups="signal"/>
	  +  <syscall name="rt_sigtimedwait_time64" groups="signal"/>
	     <syscall name="rt_sigtimedwait" groups="signal"/>
	     <syscall name="rt_tgsigqueueinfo" groups="process,signal"/>
	     <syscall name="select" groups="descriptor"/>
	  @@ -172,12 +278,14 @@
	     <syscall name="semget" groups="ipc"/>
	     <syscall name="semop" groups="ipc"/>
	     <syscall name="semtimedop" groups="ipc"/>
	  +  <syscall name="semtimedop_time64" groups="ipc"/>
	     <syscall name="sendfile64" groups="descriptor,network"/>
	     <syscall name="sendfile" groups="descriptor,network"/>
	  -  <syscall name="send" groups="network"/>
	     <syscall name="sendmmsg" groups="network"/>
	     <syscall name="sendmsg" groups="network"/>
	  +  <syscall name="send" groups="network"/>
	     <syscall name="sendto" groups="network"/>
	  +  <syscall name="set_mempolicy_home_node" groups="memory"/>
	     <syscall name="set_mempolicy" groups="memory"/>
	     <syscall name="setns" groups="descriptor"/>
	     <syscall name="setsockopt" groups="network"/>
	  @@ -198,38 +306,78 @@
	     <syscall name="sigreturn" groups="signal"/>
	     <syscall name="sigsuspend" groups="signal"/>
	     <syscall name="socketcall" groups="descriptor"/>
	  -  <syscall name="socket" groups="network"/>
	     <syscall name="socketpair" groups="network"/>
	  +  <syscall name="socket" groups="network"/>
	     <syscall name="splice" groups="descriptor"/>
	     <syscall name="ssetmask" groups="signal"/>
	     <syscall name="stat64" groups="file"/>
	     <syscall name="statfs64" groups="file"/>
	     <syscall name="statfs" groups="file"/>
	     <syscall name="stat" groups="file"/>
	  +  <syscall name="statx" groups="descriptor,file"/>
	  +  <syscall name="svr4_fstatfs" groups="descriptor"/>
	  +  <syscall name="svr4_fstat" groups="descriptor"/>
	  +  <syscall name="svr4_fstatvfs" groups="descriptor"/>
	  +  <syscall name="svr4_fxstat" groups="descriptor"/>
	  +  <syscall name="svr4_kill" groups="process"/>
	  +  <syscall name="svr4_lstat" groups="file"/>
	  +  <syscall name="svr4_lxstat" groups="file"/>
	  +  <syscall name="svr4_mincore" groups="memory"/>
	  +  <syscall name="svr4_mmap" groups="descriptor,memory"/>
	  +  <syscall name="svr4_mprotect" groups="memory"/>
	  +  <syscall name="svr4_munmap" groups="memory"/>
	  +  <syscall name="svr4_sbreak" groups="memory"/>
	  +  <syscall name="svr4_statfs" groups="file"/>
	  +  <syscall name="svr4_stat" groups="file"/>
	  +  <syscall name="svr4_statvfs" groups="file"/>
	  +  <syscall name="svr4_xstat" groups="file"/>
	     <syscall name="swapoff" groups="file"/>
	     <syscall name="swapon" groups="file"/>
	     <syscall name="symlinkat" groups="descriptor,file"/>
	     <syscall name="symlink" groups="file"/>
	  +  <syscall name="sync_file_range2" groups="descriptor"/>
	     <syscall name="sync_file_range" groups="descriptor"/>
	     <syscall name="syncfs" groups="descriptor"/>
	  +  <syscall name="sysv_brk" groups="memory"/>
	  +  <syscall name="sysv_fstatfs" groups="descriptor"/>
	  +  <syscall name="sysv_fstat" groups="descriptor"/>
	  +  <syscall name="sysv_fstatvfs" groups="descriptor"/>
	  +  <syscall name="sysv_fxstat" groups="descriptor"/>
	  +  <syscall name="sysv_kill" groups="process"/>
	  +  <syscall name="sysv_lstat" groups="file"/>
	  +  <syscall name="sysv_lxstat" groups="file"/>
	  +  <syscall name="sysv_madvise" groups="memory"/>
	  +  <syscall name="sysv_mmap64" groups="descriptor,memory"/>
	  +  <syscall name="sysv_mmap" groups="descriptor,memory"/>
	  +  <syscall name="sysv_mprotect" groups="memory"/>
	  +  <syscall name="sysv_msync" groups="memory"/>
	  +  <syscall name="sysv_munmap" groups="memory"/>
	  +  <syscall name="sysv_quotactl" groups="file"/>
	  +  <syscall name="sysv_statfs" groups="file"/>
	  +  <syscall name="sysv_stat" groups="file"/>
	  +  <syscall name="sysv_statvfs" groups="file"/>
	  +  <syscall name="sysv_xstat" groups="file"/>
	     <syscall name="tee" groups="descriptor"/>
	  -  <syscall name="tgkill" groups="signal"/>
	  +  <syscall name="tgkill" groups="signal,process"/>
	     <syscall name="timerfd_create" groups="descriptor"/>
	  +  <syscall name="timerfd_gettime64" groups="descriptor"/>
	     <syscall name="timerfd_gettime" groups="descriptor"/>
	  -  <syscall name="timerfd" groups="descriptor"/>
	  +  <syscall name="timerfd_settime64" groups="descriptor"/>
	     <syscall name="timerfd_settime" groups="descriptor"/>
	  -  <syscall name="tkill" groups="signal"/>
	  +  <syscall name="timerfd" groups="descriptor"/>
	  +  <syscall name="tkill" groups="signal,process"/>
	     <syscall name="truncate64" groups="file"/>
	     <syscall name="truncate" groups="file"/>
	     <syscall name="umount2" groups="file"/>
	     <syscall name="umount" groups="file"/>
	     <syscall name="unlinkat" groups="descriptor,file"/>
	     <syscall name="unlink" groups="file"/>
	  -  <syscall name="unshare" groups="process"/>
	     <syscall name="uselib" groups="file"/>
	  -  <syscall name="utime" groups="file"/>
	  +  <syscall name="userfaultfd" groups="descriptor"/>
	     <syscall name="utimensat" groups="descriptor,file"/>
	  +  <syscall name="utimensat_time64" groups="descriptor,file"/>
	     <syscall name="utimes" groups="file"/>
	  +  <syscall name="utime" groups="file"/>
	     <syscall name="vfork" groups="process"/>
	     <syscall name="vmsplice" groups="descriptor"/>
	     <syscall name="wait4" groups="process"/>

	Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1

2023-02-27  Pedro Alves  <pedro@palves.net>

	Autogenerate gdb/syscalls/linux-defaults.xml.in (groups) from strace sources
	I noticed that "catch syscall group:process" doesn't catch clone3,
	while it does catch clone.

	The catch syscall group information is recorded in the
	gdb/syscalls/linux-defaults.xml.in file, which says:

	  <!-- The group field information was based on strace.  -->

	So I looked at the strace sources, to confirm that clone3 is in fact
	recorded in the "process" group there too, and to check what other
	syscalls might be missing groups.

	After some digging, I found that strace records the group info in C
	arrays, with entries like:
	...
	[ 61] = { 4,	TP,		SEN(wait4),			"wait4"			},
	[ 62] = { 2,	TS|TP,		SEN(kill),			"kill"			},
	[ 63] = { 1,	0,		SEN(uname),			"uname"			},
	...

	You can see the current master's table for Linux x86-64 here:

	  https://github.com/strace/strace/blob/e88e5e9ae6da68f22d15f9be3193b1412ac9aa02/src/linux/x86_64/syscallent.h

	The column with TS|TP above is what defines each syscall's groups.  So
	I wrote a script that extracts this information and generates
	linux-defaults.xml.in.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1

2023-02-27  Clément Chigot  <chigot@adacore.com>

	gas/testsuite: adjust another test for case insensitive file systems
	As 1fafeaac8503eea2f61c3a35f0eef183b7e7cc65, "line.s" and "Line.s" are
	identical in case insensitive file systems. Thus, gas doesn't trigger
	an input file switch.

	gas/ChangeLog:

	        * testsuite/gas/elf/dwarf-5-macro.s: Change Line.s to Line2.s.

2023-02-27  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't treat empty enums as flag enums
	In C++ it is possible to use an empty enum as a strong typedef.  For
	example, a user could write:

	  enum class my_type : unsigned char {};

	Now my_type can be used like 'unsigned char' except the compiler will
	not allow implicit conversion too and from the native 'unsigned char'
	type.

	This is used in the standard library for things like std::byte.

	Currently, when GDB prints a value of type my_type, it looks like
	this:

	  (gdb) print my_var
	  $1 = (unknown: 0x4)

	Which isn't great.  This gets worse when we consider something like:

	  std::vector<my_type> vec;

	When using a pretty-printer, this could look like this:

	  std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)}

	Clearly not great.  This is described in PR gdb/30148.

	The problem here is in dwarf2/read.c, we assume all enums are flag
	enums unless we find an enumerator with a non-flag like value.
	Clearly an empty enum contains no non-flag values, so we assume the
	enum is a flag enum.

	I propose adding an extra check here; that is, an empty enum should
	never be a flag enum.

	With this the above cases look more like:

	  (gdb) print my_var
	  $1 = 4

	and:

	  std::vector of length 2, capacity 2 = {2, 4}

	Which look much better.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-27  Benson Muite  <benson_muite@emailplus.org>

	Do not change the timestamp when updating the gas asconfig file.
	 PR 28909 * doc/local.mk (asconfig.texi): Use "cp -p" to preserve timestamps. * Makefile.in: Regenerate.

2023-02-27  Felix Willgerodt  <felix.willgerodt@intel.com>

	Fix missing "Core was generated by" when loading a x32 corefile.

2023-02-27  Nick Clifton  <nickc@redhat.com>

	Updated Serbian translations for gold, gprof and opcodes sub-directories

2023-02-27  Bruno Larsen  <blarsen@redhat.com>

	gdb/testsuite: Improve testing of GDB's completion functions
	When looking at some failures of gdb.linespec/cp-completion-aliases.exp,
	I noticed that when a completion test will fail, it always fails with a
	timeout.  This is because most completion tests use gdb_test_multiple
	and only add a check for the correct output.  This commit adds new
	options for both, tab and command completion.

	For command completion, the new option will check if the prompt was
	printed, and fail in this case. This is enough to know that the test has
	failed because the check comes after the PASS path. For tab completion,
	we have to check if GDB outputted more than just the input line, because
	sometimes GDB would have printed a partial line before finishing with
	the correct completion.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-27  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	gdb, python: do minor modernization in execute_gdb_command
	Use nullptr instead of NULL and boolify two local variables in
	execute_gdb_command.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-26  Tom Tromey  <tom@tromey.com>

	Remove expand_symtab_containing_pc
	The function expand_symtab_containing_pc is unused; remove it.
	Tested by rebuilding.

2023-02-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/amd64: replace xmalloc/alloca with gdb::byte_vector
	Replace a couple of uses of xmalloc and alloc with a gdb::byte_vector
	local variable instead.

	There should be no user visible changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-25  Andrew Burgess  <aburgess@redhat.com>

	opcodes/m68k: enable libopcodes styling for GDB
	The following commit added libopcodes styling for m68k:

	  commit c22ff449275c91e4842bb10c650e83c572580f65
	  Date:   Tue Feb 14 18:07:19 2023 +0100

	      opcodes: style m68k disassembler output

	but didn't set disassemble_info::created_styled_output in
	disassemble.c, which is needed in order for GDB to start using the
	libopcodes based styling.

	This commit fixes this small oversight.  GDB now styles correctly.

2023-02-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-24  Khem Raj  <raj.khem@gmail.com>

	gdbserver/linux-low.cc: Fix a typo in ternary operator

2023-02-24  Tom Tromey  <tom@tromey.com>

	Remove struct buffer
	I've long wanted to remove 'struct buffer', and thanks to Simon's
	earlier patch, I was finally able to do so.  My feeling has been that
	gdb already has several decent structures available for growing
	strings: std::string of course, but also obstack and even objalloc
	from BFD and dyn-string from libiberty.  The previous patches in this
	series removed all the uses of struct buffer, so this one can remove
	the code and the remaining #includes.

	Don't use struct buffer in top.c
	This changes top.c to use std::string rather than struct buffer.  Like
	the event-top.c change, this is not completely ideal in that it
	requires a copy of the string.

	Don't use struct buffer in event-top.c
	This changes event-top.c to use std::string rather than struct buffer.
	This isn't completely ideal, in that it requires a copy of the string
	to be made.

	Don't use struct buffer in handle_qxfer_threads
	This changes handle_qxfer_threads, in gdbserver, to use std::string
	rather than struct buffer.

	Don't use struct buffer in handle_qxfer_btrace
	This changes handle_qxfer_btrace and handle_qxfer_btrace_conf, in
	gdbserver, to use std::string rather than struct buffer.

	Don't use struct buffer in handle_qxfer_traceframe_info
	This changes handle_qxfer_traceframe_info, in gdbserver, to use
	std::string rather than struct buffer.

	Remove struct buffer from tracefile-tfile.c
	This changes tracefile-tfile.c to use std::string rather than struct
	buffer.

2023-02-24  Tom Tromey  <tromey@adacore.com>

	Write the DWARF index in the background
	The new DWARF cooked indexer interacts poorly with the DWARF index
	cache.  In particular, the cache will require gdb to wait for the
	cooked index to be finalized.  As this happens in the foreground, it
	means that users with this setting enabled will see a slowdown.

	This patch changes gdb to write the cache entry a worker thread.  (As
	usual, in the absence of threads, this work is simply done immediately
	in the main thread.)

	Some care is taken to ensure that this can't crash, and that gdb will
	not exit before the task is complete.

	To avoid use-after-free problems, the DWARF per-BFD object explicitly
	waits for the index cache task to complete.

	To avoid gdb exiting early, an exit observer is used to wait for all
	such pending tasks.

	In normal use, neither of these waits will be very visible.  For users
	using "-batch" to pre-generate the index, though, it would be.
	However I don't think there is much to be done about this, as it was
	the status quo ante.

2023-02-24  Tom Tromey  <tromey@adacore.com>

	Only use the per-BFD object to write a DWARF index
	The DWARF index does not need access to the objfile or per-objfile
	objects when writing -- it's entirely based on the objfile-independent
	per-BFD data.

	This patch implements this idea by changing the entire API to only be
	passed the per-BFD object.  This simplifies some lifetime reasoning
	for the next patch.

	This patch removes some code that ensures that the BFD came from a
	file.  It seems to me that checking for the existence of a build-id is
	good enough for the index cache.

2023-02-24  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: fix parenthesis position in comment
	Change-Id: I535b597ab4482378910570d8dd69c090419941eb

2023-02-24  Clément Chigot  <chigot@adacore.com>

	testsuite: prune DOS drive letter in test outputs
	On DOS systems, absolute paths start with the drive letter. This can
	trigger failures in the regexp from dump tests, especially for those
	checking for warnings or errors. They are usually skipping everything
	before the first ":" as it has to be the file path.
	  | [^:]*: warning: ...

	In order to avoid modifying many regexps to allow such drive letters,
	prune them from all the outputs if they are found at the beginning of
	a line.

	binutils/ChangeLog:

		* testsuite/lib/binutils-common.exp (prune_dump_output): New
		(run_dump_test): Use it.

	ld/ChangeLog:

		* testsuite/ld-elf/noinit-sections-2.l: Remove DOS drive letter
		handler.

2023-02-24  Jan Beulich  <jbeulich@suse.com>

	x86: allow to request ModR/M encoding
	Several insns have a (typically shorter) non-ModR/M and a (typically
	longer) ModR/M encoding. In most cases the former is used by default.
	This isn't too dissimilar from register-only insns sometimes having two
	encoding forms. In those cases {load} or {store} can be used to control
	the encoding used. Extend this to ModR/M-less encodings which have a
	ModR/M counterpart (note that BSWAP hasn't). For insn reading and
	writing their (explicit) memory operand, both prefixes are honored;
	otherwise only the applicable one is.

	Note that for some forms of XCHG, {store} has already been performing
	this function, apparently as an unnoticed side effect of adding D to
	the template.

2023-02-24  Jan Beulich  <jbeulich@suse.com>

	x86: MONITOR/MWAIT are not SSE3 insns
	These have their own CPUID bit and hence they should also have their own
	separate control.

2023-02-24  Jan Beulich  <jbeulich@suse.com>

	x86-64: don't permit LAHF/SAHF with "generic64"
	The feature isn't universally available on 64-bit CPUs.

	Note that in i386-gen.c:isa_dependencies[] I'm only adding it to models
	where I'm certain the functionality exists. For Nocona and Core I'm
	uncertain in particular.

2023-02-24  Jan Beulich  <jbeulich@suse.com>

	x86: have insns acting on segment selector values allow for consistent operands
	While MOV to/from segment register as well as selector storing insns
	already permit 32- and 64-bit GPR operands, selector loading insns and
	ARPL do not. Split templates accordingly.

2023-02-24  Jan Beulich  <jbeulich@suse.com>

	x86: restrict insn templates accepting negative 8-bit immediates
	For shifts (but not ordinary rotates) and other cases where an immediate
	describes e.g. a bit count or position, allowing negative operands is at
	best confusing. An extreme example would be the two rotate-through-carry
	insns, where a negative value would _not_ mean rotating the
	corresponding number of bits in the other direction. To refuse such,
	give meaning to the combination of Imm8 and Imm8S in templates (so far
	these weren't used together anywhere). The issue was with
	smallest_imm_type() blindly setting .imm8 for signed numbers determined
	to fit in a byte.

	VPROT{B,W,D,Q} is a little special: The rotate count there is a signed
	quantity, so Imm8 is replaced by Imm8S. Adjust affected testcases
	accordingly as well.

	Another small adjustment to the testsuite is necessary: AAM and AAD were
	never sensible to use with 0xffffff90 operands. This should have been an
	error.

2023-02-24  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Cleanup unnecessary expr from require line
	In a recent commit I've added:
	...
	require {expr [have_compile_flag -fsplit-stack]}
	...
	but actually the expr bit is unnecessary, and we can just use:
	...
	require {have_compile_flag -fsplit-stack}
	...

	Reported-By: Tom Tromey <tom@tromey.com>

2023-02-24  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Fix out of bounds accesses with limited-length values
	Fix accesses to limited-length values in `contents_copy_raw' and
	`contents_copy_raw_bitwise' so that they observe the limit of the
	original allocation.

	Reported by Simon Marchi as a heap-buffer-overflow AddressSanitizer
	issue triggered with gdb.ada/limited-length.exp.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-24  Nick Clifton  <nickc@redhat.com>

	Enhance better_fit() function to prefer function symbols over non-function symbols.

2023-02-24  Alan Modra  <amodra@gmail.com>

	PR30155, ld segfault in _bfd_nearby_section
	The segfault was a symptom of messing with the absolute section next
	field, confusing bfd_section_removed_from_list in linker.c:fix_syms.
	That's not all that was going wrong.  The INSERT list of output
	sections was being inserted into itself, ie. lost from the main
	list of linker statements.

		PR 30155
		* ldlang.c (process_insert_statements): Handle pathological
		case of the insert script being inserted before the first
		output section statement in the default script.
		(output_prev_sec_find): Don't test section owner here.
		(insert_os_after): Change parameter to a list union pointer.
		(lang_insert_orphan): Test section owner here and adjust
		insert_os_after call.

2023-02-24  Fangrui Song  <i@maskray.me>

	RISC-V: Add --[no-]relax-gp to ld
	--relax enables all relaxations.  --no-relax-gp disables GP relaxation to
	allow measuring its effect.

	The option can test effectiveness of GP relaxation and support some ABI
	variants that use GP for other purposes.

	Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/298

	bfd/
	    * elfnn-riscv.c (struct riscv_elf_link_hash_table): Add params.
	    (riscv_elfNN_set_options): New.
	    (riscv_info_to_howto_rela): Check relax_gp.
	    (_bfd_riscv_relax_section): Likewise.
	    * elfxx-riscv.h (struct riscv_elf_params): New.
	    (riscv_elf32_set_options): New.
	    (riscv_elf64_set_options): New.
	ld/
	    * emultempl/riscvelf.em: Add option parsing.
	    * testsuite/ld-riscv-elf/code-model-relax-medlow-01-norelaxgp.d: New.
	    * testsuite/ld-riscv-elf/pcgp-relax-01-norelaxgp.d: New.
	    * testsuite/ld-riscv-elf/pcgp-relax-02.d: Test --relax --relax-gp can be
	      used together.

2023-02-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-23  Palmer Dabbelt  <palmer@rivosinc.com>

	gdb/doc: The RISC-V vector registers didn't change
	When we merged the GDB vector register support we did it a bit early,
	just eating the risk in the very unlikely case that the vector register
	names changed.  They didn't, so we can now remove the caveat in the docs
	that they might.

2023-02-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove --disable-gdbmi configure option
	I noticed that the --disable-gdbmi option was broken for almost a year
	(since 740b42ceb7c "gdb/python/mi: create MI commands using python").

	The problem today is the python/py-cmd.c file.  It is included in the
	build if Python support is enabled, and it calls into some MI functions
	(e.g. insert_mi_cmd_entry).  If MI support is disabled, we get some
	undefined symbols like:

	    mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >)
	    >>> referenced by py-micmd.c
	    >>>               python/py-micmd.o:(micmdpy_install_command(micmdpy_object*))

	The python/py-cmd.c file should be included in the build if both Python
	and MI support are enabled.  It is not a case we support today, but it
	could be done with a bit more configure code.  However, I think we
	should just remove the --disable-gdbmi option, and just include MI
	support unconditionally.

	Tom Tromey proposed a while ago to remove this option, but it ended
	staying:

	  https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/

	However, there was no strong opposition to remove it.  The argument was
	just "bah, it doesn't hurt anybody".

	But given today's case, I would rather remove complexity rather than add
	some.  I couldn't find anybody caring deeply for that option, and it's
	not like MI adds any external dependency.  It's just a bit more code.

	Removing the option will not break anybody using --disable-gdbmi (it can
	be found in many build scripts [1]), since we don't flag invalid
	configure flags.

	So, remove the option from configure.ac, and adjust Makefile.in
	accordingly to always include the MI objects in the build.

	[1] https://github.com/search?q=%22--disable-gdbmi%22&type=code

	Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-23  Tom Tromey  <tromey@adacore.com>

	Fix Tcl quoting in gdb_assert
	The gdb_assert proc under-quotes the expression that is passed in.
	This leads to weird code in a couple of spots that tries to
	compensate:

	    gdb_assert {{$all_regs eq $completed_regs}} ...

	The fix is to add a bit of quoting when evaluating the expression.

2023-02-23  Nick Clifton  <nickc@redhat.com>

	Fix _bfd_elf_find_function so that it can cope with overlapping symbols

2023-02-23  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add AMDGPU header files to HFILES_NO_SRCDIR
	Commit 18b4d0736bc5 ("gdb: initial support for ROCm platform (AMDGPU)
	debugging") missed adding these header files to the HFILES_NO_SRCDIR
	list in the Makefile.  Fix that now.

	Change-Id: Ifd387096aef3d147b51aefa2037da5bf6373ea64

2023-02-23  Tom Tromey  <tromey@adacore.com>

	Remove 'eval' from gdb_breakpoint
	Now that Tcl has the {*} operator, we can remove the use of eval from
	gdb_breakpoint.  Tested on x86-64 Fedora 36.

2023-02-23  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Support reg aliases in info reg command
	According to LoongArch ELF ABI specification [1], support the register
	aliases in "info register" command.

	Without this patch:
	```
	(gdb) info reg a0
	Invalid register `a0'

	```
	With this patch:

	```
	(gdb) info reg a0

	a0             0x1                 1

	```
	[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_register_convention

2023-02-23  Hui Li  <lihui@loongson.cn>

	gdb: LoongArch: Modify the result of the info reg command
	The "info register" command should only display general registers,
	but it shows the information of all registers in the current code,
	add loongarch_register_reggroup_p() so that we can get the expected
	result.

2023-02-23  Alexey Lapshin  <alexey.lapshin@espressif.com>

	bfd: xtensa: fix __stop_SECTION literal drop

2023-02-23  Nick Clifton  <nickc@redhat.com>

	Fix the BFD library's find_nearest_line feature to produce consistent results.
	 PR 30150
	 * dwarf2.c (comp_unit_contains_address): Renamed to ... (comp_unit_may_contain_address): this,
	 and added code to return true if the CU's ranges have not yet been computed.
	 (_bfd_dwarf2_find_nearest_line_with_alt): Use the renamed function, simplifying code in the process.

2023-02-23  Alan Modra  <amodra@gmail.com>

	dwarf1 .line SEC_HAS_CONTENTS
		* dwarf1.c (parse_line_table): Ignore .line without SEC_HAS_CONTENTS.
		Formatting.

2023-02-23  Alan Modra  <amodra@gmail.com>

	ip2k: don't look at stab sections without relocs
	No need to read contents if we won't do anything.

		* elf32-ip2k.c (adjust_all_relocations): Skip stab sections
		without relocs.

2023-02-23  Alan Modra  <amodra@gmail.com>

	Test SEC_HAS_CONTENTS in relax routines
	More places that generally expect instructions, so not zeros.

		* coff-sh.c (sh_relax_section, sh_relax_delete_bytes): Exclude
		sections without SEC_HAS_CONTENTS set.
		* elf-m10200.c (mn10200_elf_relax_section): Likewise.
		* elf32-arc.c (arc_elf_relax_section): Likewise.
		* elf32-avr.c (elf32_avr_relax_section): Likewise.
		* elf32-cr16.c (elf32_cr16_relax_section): Likewise.
		* elf32-crx.c (elf32_crx_relax_section): Likewise.
		* elf32-epiphany.c (epiphany_elf_relax_section): Likewise.
		* elf32-ft32.c (ft32_elf_relax_section): Likewise.
		* elf32-h8300.c (elf32_h8_relax_section): Likewise.
		* elf32-ip2k.c (ip2k_elf_relax_section): Likewise.
		* elf32-m32c.c (m32c_elf_relax_section): Likewise.
		* elf32-m68hc11.c (m68hc11_elf_relax_section): Likewise.
		* elf32-msp430.c (msp430_elf_relax_section): Likewise.
		* elf32-pru.c (pru_elf32_relax_section): Likewise.
		* elf32-rl78.c (rl78_elf_relax_section): Likewise.
		* elf32-rx.c (elf32_rx_relax_section): Likewise.
		* elf32-sh.c (sh_elf_relax_section): Likewise.
		(sh_elf_relax_delete_bytes): Likewise.
		* elf32-v850.c (v850_elf_relax_section): Likewise.
		* elf64-alpha.c (elf64_alpha_relax_section): Likewise.
		* elf64-ia64-vms.c (elf64_ia64_relax_section): Likewise.
		* elfnn-ia64.c (elfNN_ia64_relax_section): Likewise.
		* elfnn-riscv.c (_bfd_riscv_relax_section): Likewise.
		* elfxx-mips.c (_bfd_mips_elf_relax_section): Likewise.

2023-02-23  Alan Modra  <amodra@gmail.com>

	Test SEC_HAS_CONTENTS before reading section contents
	bfd_malloc_and_get_section does size sanity checking before allocating
	memory and reading contents.  These size checks are not done for bss
	style sections, because they typically don't occupy file space and
	thus can't be compared against file size.  However, if you are
	expecting to look at something other than a whole lot of zeros, don't
	allow fuzzers to avoid the size checking.

		* cofflink.c (process_embedded_commands): Don't look at
		sections without SEC_HAS_CONTENTS set.
		* cpu-arm.c (bfd_arm_update_notes): Likewise.
		(bfd_arm_get_mach_from_notes): Likewise.
		* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Likewise.
		* elf-hppa.h (elf_hppa_sort_unwind): Likewise.
		* elf-m10300.c (mn10300_elf_relax_section): Likewise.
		* elf-sframe.c (_bfd_elf_parse_sframe): Likewise.
		* elf.c (_bfd_elf_print_private_bfd_data): Likewise.
		* elf32-arm.c (bfd_elf32_arm_process_before_allocation): Likewise.
		* elf32-avr.c (avr_elf32_load_property_records): Likewise.
		* elf32-ppc.c (_bfd_elf_ppc_set_arch): Likewise.
		(ppc_elf_get_synthetic_symtab, ppc_elf_relax_section): Likewise.
		* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
		(opd_entry_value, ppc64_elf_edit_opd, ppc64_elf_edit_toc): Likewise.
		* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise.
		* elflink.c (elf_link_add_object_symbols): Likewise.
		(bfd_elf_get_bfd_needed_list): Likewise.
		* elfnn-aarch64.c (get_plt_type): Likewise.
		* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.
		* linker.c (_bfd_handle_already_linked): Likewise.
		* opncls.c (bfd_get_debug_link_info_1): Likewise.
		(bfd_get_alt_debug_link_info, get_build_id): Likewise.
		* peXXigen.c (pe_print_idata, pe_print_pdata): Likewise.
		(_bfd_XX_print_ce_compressed_pdata, pe_print_reloc): Likewise.
		* pei-x86_64.c (pex64_bfd_print_pdata_section): Likewise.
		* stabs.c (_bfd_link_section_stabs): Likewise.
		(_bfd_discard_section_stabs): Likewise.
		* xcofflink.c (_bfd_xcoff_get_dynamic_symtab_upper_bound): Likewise.
		(_bfd_xcoff_canonicalize_dynamic_symtab): Likewise.
		(_bfd_xcoff_get_dynamic_reloc_upper_bound): Likewise.
		(_bfd_xcoff_canonicalize_dynamic_reloc): Likewise.
		(xcoff_link_add_dynamic_symbols): Likewise.
		(xcoff_link_check_dynamic_ar_symbols): Likewise.
		(bfd_xcoff_build_dynamic_sections): Likewise.

2023-02-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-22  Pedro Alves  <pedro@palves.net>

	gdb.reverse/time-reverse.exp: test both time syscall and C time function
	Instead of only testing this on systems that have a SYS_time syscall,
	test it everywhere using the time(2) C function, and in addition, run
	the tests again using the SYS_time syscall.

	The C variant ensures that if some platform uses some syscall we are
	not aware of yet, we'll still exercise it, and likely fail, at which
	point we should teach GDB about the syscall.

	The explicit syscall variant is useful on platforms where the C
	function does not call a syscall at all by default, e.g., on some
	systems the C time function wraps an implementation provided by the
	vDSO.

	Approved-By: Tom de Vries <tdevries@suse.de>
	Change-Id: Id4b755d76577d02c46b8acbfa249d9c31b587633

2023-02-22  Jan Beulich  <jbeulich@suse.com>

	x86-64: LAR and LSL don't need REX.W
	Just like we suppress emitting REX.W for e.g. MOV from/to segment
	register, there's also no need for it for LAR and LSL - these can only
	ever return 32-bit values and hence always zero-extend their results
	anyway.

	While there also drop the redundant Word from the first operand of
	the second template each - this is already implied by Reg16.

2023-02-22  Jan Beulich  <jbeulich@suse.com>

	x86: optimize BT{,C,R,S} $imm,%reg
	In 64-bit mode BT can have REX.W or a data size prefix dropped in
	certain cases. Outside of 64-bit mode all 4 insns can have the data
	size prefix dropped in certain cases.

2023-02-22  Alan Modra  <amodra@gmail.com>

	set bfd_error on make_tempname or make_tempdir failure
		* bucomm.c (make_tempname, make_tempdir): Set bfd_error on error.

2023-02-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-21  Alan Modra  <amodra@gmail.com>

	Re: objdump read_section_stabs
	Also fix ubsan "applying zero offset to null pointer".

		* objdump.c (print_section_stabs): Avoid ubsan warning.

2023-02-21  Alan Modra  <amodra@gmail.com>

	Re: objdump read_section_stabs
	Commit f9c36cc99518 changed (and renamed) read_section_stabs with one
	difference in overall behaviour.  Previously read_section_stabs would
	return a NULL for an empty section, which was then treated the same as
	a missing section.  Now an empty section is recognized and dumped.
	This leads to NULL stabp and stabs_end in print_section_stabs.  Since
	stabs_end - STABSIZE is then a pointer to a very large address, the
	test "stabp < stabs_end - STABSIZE" succeeds.

		* objdump.c (print_section_stabs): Correct STABSIZE comparison.

2023-02-21  Alan Modra  <amodra@gmail.com>

	debug_link duplicate file size checks
	bfd_malloc_and_get_section does these checks.

		* opncls.c (bfd_get_debug_link_info_1): Don't check section
		size against file size.
		(bfd_get_alt_debug_link_info): Likewise.

2023-02-21  Tom Tromey  <tom@tromey.com>

	Issue error on erroneous expression
	A while back I discovered that this does not issue an error:

	    (gdb) p $x = (void * ) 57
	    $3 = (void *) 0x39
	    (gdb) p $x + 7 = 3
	    $6 = (void *) 0x3

	This patch fixes the bug.
	Regression tested on x86-64 Fedora 36.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19312

2023-02-21  Philippe Blain  <levraiphilippeblain@gmail.com>

	gdb: add --with-curses to --configuration output
	'gdb --configuration' does not mention if GDB was built with curses.
	Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show
	--enable-tui (or --disable-tui), but one might want to know if GDB was
	built with curses independently of the availability of the TUI.

	Since configure.ac uses AC_SEARCH_LIBS to check for the curses library,
	we do not get an automatically defined HAVE_LIBCURSES symbol in
	config.in. We do have symbols defined by AC_CHECK_HEADERS
	(HAVE_CURSES_H, etc.) but it would be cumbersome to use those in
	print_gdb_configuration because we would have to check for all 6 symbols
	corresponding the 6 headers listed. This would also increase the
	maintenance burden if support for other variations of curses are added.

	Instead, define 'HAVE_LIBCURSES' ourselves by adding an
	'action-if-found' argument to AC_SEARCH_LIBS, and use it in
	print_gdb_configuration.

	While at it, remove the condition on 'ac_cv_search_waddstr' and set
	'curses_found' directly in 'action-if-found'.

	Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require compilation flags in two gdb.arch/aarch64 test-cases
	With test-cases gdb.arch/aarch64-mte-core.exp and gdb.arch/aarch64-pauth.exp I
	run into compilation errors due to unsupported compilation flags.

	Fix this by requiring the compilation flags, such that I have instead:
	...
	UNSUPPORTED: gdb.arch/aarch64-mte-core.exp: require failed: \
	  have_compile_flag -march=armv8.5-a+memtag
	UNSUPPORTED: gdb.arch/aarch64-pauth.exp: require failed: \
	  have_compile_flag -mbranch-protection=pac-ret+leaf
	...

	Tested on aarch64-linux.

2023-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require istarget x86* in gdb.reverse/step-indirect-call-thunk.exp
	On aarch64-linux, I run into:
	...
	Running gdb.reverse/step-indirect-call-thunk.exp ...
	gdb compile failed, gcc: error: unrecognized command line option \
	  '-mindirect-branch=thunk'; did you mean '-findirect-inlining'?
	gcc: error: unrecognized command line option '-mfunction-return=thunk'; \
	  did you mean '-Wfunction-elimination'?
	UNTESTED: gdb.reverse/step-indirect-call-thunk.exp: failed to prepare
	...

	Fix this by requiring istarget "x86*", similar to what was added in
	gdb.base/step-indirect-call-thunk.exp by commit 43127ae5714 ("Fix
	gdb.base/step-indirect-call-thunk.exp"), such that we have instead:
	...
	UNSUPPORTED: gdb.reverse/step-indirect-call-thunk.exp: require failed: \
	  istarget "x86*
	...

	Tested on x86_64-linux and aarch64-linux.

2023-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require -fsplit-stack in gdb.base/morestack.exp
	On aarch64-linux, I run into:
	...
	gdb compile failed, cc1: error: '-fsplit-stack' is not supported by this \
	  compiler configuration
	UNTESTED: gdb.base/morestack.exp: failed to prepare
	...

	Fix this by requiring -fsplit-stack, such that we have instead:
	...
	UNSUPPORTED: gdb.base/morestack.exp: require failed: \
	  expr [have_compile_flag -fsplit-stack]
	...

	Tested on x86_64-linux and aarch64-linux.

2023-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require syscall time in gdb.reverse/time-reverse.exp
	On aarch64-linux, I run into:
	...
	Running gdb.reverse/time-reverse.exp ...
	gdb compile failed, gdb.reverse/time-reverse.c: In function 'main':
	gdb.reverse/time-reverse.c:39:12: error: 'SYS_time' undeclared \
	  (first use in this function); did you mean 'SYS_times'?
	   syscall (SYS_time, &time_global);
	            ^~~~~~~~
	            SYS_times
	gdb.reverse/time-reverse.c:39:12: note: each undeclared identifier is \
	  reported only once for each function it appears in
	UNTESTED: gdb.reverse/time-reverse.exp: failed to prepare
	...

	Fix this by adding a new proc have_syscall, and requiring syscall time, such
	that we have instead:
	...
	UNSUPPORTED: gdb.reverse/time-reverse.exp: require failed: \
	  expr [have_syscall time]
	...

	Tested on x86_64-linux and aarch64-linux.

2023-02-21  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Require python in gdb.dap/basic-dap.exp
	When running test-case gdb.dap/basic-dap.exp with a gdb without python
	support, I run into:
	...
	builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 \
	  -data-directory data-directory -iex set debug dap-log-file dap.log.1 -q \
	  -i=dap
	>>> {"seq": 1, "type": "request", "command": "initialize"}
	Interpreter `dap' unrecognized
	ERROR: eof reading json header
	...

	Fix this by requiring python in the test-case.

	Tested on x86_64-linux, both with a gdb without and with python.

2023-02-21  Nick Clifton  <nickc@redhat.com>

	Update the description of the bfd_fill_in_gnu_debuglink_section function

	Updated translatios for the bfd and gprof directories.

2023-02-21  Clément Chigot  <chigot@adacore.com>

	gas/testsuite: adjust a test for case insensitive file systems
	When dealing with case insensitive file systems, ".file line.s" and
	".file Line.s" are identical and thus gas won't change the current
	input file.
	However, in line.l test, it's expecting to trigger an input file switch.
	As the second filename doesn't matter in it, change it to fit for those
	file systems.

	gas/ChangeLog:

		* testsuite/gas/elf/line.l: Change Line.s to Line2.s.
		* testsuite/gas/elf/line.s: Adjust output.

2023-02-21  Luis Machado  <luis.machado@arm.com>

	[aarch64] Enable pointer authentication support for aarch64 bare metal/kernel mode addresses
	At the moment GDB only handles pointer authentication (pauth) for userspace
	addresses and if we're debugging a Linux-hosted program.

	The Linux Kernel can be configured to use pauth instructions for some
	additional security hardening, but GDB doesn't handle this well.

	To overcome this limitation, GDB needs a couple things:

	1 - The target needs to advertise pauth support.
	2 - The hook to remove non-address bits from a pointer needs to be registered
	    in aarch64-tdep.c as opposed to aarch64-linux-tdep.c.

	There is a patch for QEMU that addresses the first point, and it makes
	QEMU's gdbstub expose a couple more pauth mask registers, so overall we will
	have up to 4 pauth masks (2 masks or 4 masks):

	pauth_dmask
	pauth_cmask
	pauth_dmask_high
	pauth_cmask_high

	pauth_dmask and pauth_cmask are the masks used to remove pauth signatures
	from userspace addresses. pauth_dmask_high and pauth_cmask_high masks are used
	to remove pauth signatures from kernel addresses.

	The second point is easily addressed by moving code around.

	When debugging a Linux Kernel built with pauth with an unpatched GDB, we get
	the following backtrace:

	 #0  __fput (file=0xffff0000c17a6400) at /repos/linux/fs/file_table.c:296
	 #1  0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
	 #2  0x30008000080ade30 [PAC] in ?? ()
	 #3  0x30d48000080ade30 in ?? ()
	 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

	With a patched GDB, we get something a lot more meaningful:

	 #0  __fput (file=0xffff0000c1bcfa00) at /repos/linux/fs/file_table.c:296
	 #1  0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
	 #2  0xffff8000080ade30 [PAC] in task_work_run () at /repos/linux/kernel/task_work.c:179
	 #3  0xffff80000801db90 [PAC] in resume_user_mode_work (regs=0xffff80000a96beb0) at /repos/linux/include/linux/resume_user_mode.h:49
	 #4  do_notify_resume (regs=regs@entry=0xffff80000a96beb0, thread_flags=4) at /repos/linux/arch/arm64/kernel/signal.c:1127
	 #5  0xffff800008fb9974 [PAC] in prepare_exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:137
	 #6  exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:142
	 #7  el0_svc (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:638
	 #8  0xffff800008fb9d34 [PAC] in el0t_64_sync_handler (regs=<optimized out>) at /repos/linux/arch/arm64/kernel/entry-common.c:655
	 #9  0xffff800008011548 [PAC] in el0t_64_sync () at /repos/linux/arch/arm64/kernel/entry.S:586
	 Backtrace stopped: Cannot access memory at address 0xffff80000a96c0c8

2023-02-21  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: don't output to /dev/null
	Mingw doesn't have /dev/null and thus "-o /dev/null" will fail.
	Currently, all the options are checked using this "-o /dev/null",
	resulting in them being disabled on mingw hosts.
	Fix that by outputting to a real file for all targets.

	ld/ChangeLog:

		* testsuite/config/default.exp: Replace "-o /dev/null" by a
		file.

2023-02-21  Alan Modra  <amodra@gmail.com>

	Both FAIL and PASS "check sections 2"?
		* testsuite/ld-checks/checks.exp (check sections 2): Don't
		continue on with rest of test past first fail.

	ld-libs test on alpha-vms
		* testsuite/ld-libs/libs.exp: Don't run for alpha-vms.

2023-02-21  Alan Modra  <amodra@gmail.com>

	alpha-*-vms missing libraries
	For this:
	./ld-new: cannot find -limagelib: No such file or directory
	./ld-new: cannot find -lstarlet: No such file or directory
	./ld-new: cannot find -lsys$public_vectors: No such file or directory
	the logs showed
	creating dummy tmpdir/libimagelib:
	creating dummy No
	creating dummy such
	etc.
	So rubbish instead of tmpdir/libimagelib.a and the other required libs.

		* testsuite/config/default.exp: Correct regex detecting missing
		libraries automatically searched by alpha-dec-vms-ld.

2023-02-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-20  Tom Tromey  <tom@tromey.com>

	Redefine FUNCTION in doc.str
	FUNCTION is identical to func, so simplify doc.str.

	2023-02-17  Tom Tromey  <tom@tromey.com>

		* doc/doc.str (FUNCTION): Call func.

2023-02-20  Tom Tromey  <tom@tromey.com>

	Hoist the SECTION comment in opncls.c
	The opening and closing node in BFD starts:

	    File: bfd.info, [...]

		 /* Set to N to open the next N BFDs using an alternate id space.  */
		 extern unsigned int bfd_use_reserved_id;

	    2.13 Opening and closing BFDs
	    =============================

	That is, there's a stray C comment and declaration before any other
	text or subsections.

	This occurs because the code fragment for bfd_use_reserved_id comes
	before the SECTION comment.  Hoisting it makes this a little nicer.

	2023-02-17  Tom Tromey  <tom@tromey.com>

		* opncls.c: Hoist the SECTION comment.

2023-02-20  Tom Tromey  <tom@tromey.com>

	Don't use chew comments for static functions
	I found a few static functions in the BFD manual.  These can't be
	called by any user of the library, so I don't think it's useful to put
	them in the manual.  This patch removes the chew markup from their
	comments.

	2023-02-17  Tom Tromey  <tom@tromey.com>

		* opncls.c (bfd_get_debug_link_info_1, separate_debug_file_exists)
		(separate_alt_debug_file_exists, find_separate_debug_file)
		(get_build_id, get_build_id_name, check_build_id_file): Don't use
		chew comments.

2023-02-20  Tom Tromey  <tom@tromey.com>

	Fix formatting of long function description in chew output
	Currently, if a function description spans a line, the resulting info
	can look like this:

	 -- Function: long bfd_canonicalize_reloc
	     (bfd *abfd, asection *sec, arelent **loc, asymbol **syms); Call the
	     back end associated with the open BFD ABFD and translate the
	     external form of the relocation information attached to SEC into
	     the internal canonical form.  Place the table into memory at LOC,

	That is, the function prototype runs together with the text in an ugly
	way.  This patch fixes this by introducing a new primitive, so that
	the generated Texinfo can be a bit nicer.  Now this output looks like:

	 -- Function: long bfd_canonicalize_reloc (bfd *abfd, asection *sec,
	          arelent **loc, asymbol **syms);
	     Call the back end associated with the open BFD ABFD and translate
	     the external form of the relocation information attached to SEC

	2023-02-17  Tom Tromey  <tom@tromey.com>

		* doc/doc.str (SYNOPSIS): Use collapse_whitespace.
		* doc/chew.c (collapse_whitespace): New function.
		(main): Register collapse_whitespace.

2023-02-20  Andreas Schwab  <schwab@suse.de>

	opcodes: style m68k disassembler output

2023-02-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: revert one erroneous bool-ification change
	Commit 42c13555ff88 ("Change value::m_stack to bool") erroneously
	changed a `0` to `false` in this call to read_value_memory.  This
	parameter is `LONGEST bit_offset`, it should stay `0`.

	Change-Id: I128df6834cf8055ec6a7051e237e379978d3d651

2023-02-20  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: handle Windows drive letter in a noinit test
	The regexp in "noinit sections (ld -r)" is skipping the file path before
	the first ":". However, on Windows, a path can start with "C:". Adjust
	the regexp to allow such cases.

	ld/ChangeLog:

		* testsuite/ld-elf/noinit-sections-2.l: Allow Windows paths
		(starting with C:).

2023-02-20  Clément Chigot  <chigot@adacore.com>

	ld/testsuite: adjust to Windows path separator.
	In some tests, the path reported on Windows will have a \ instead of a
	/. This occurs when a file is concatened with the search path in
	ldfile.c.:  "ld -Ltmpdir -ltext" will result into "tmpdir\libtext.a".

	ld/ChangeLog:

		* testsuite/ld-elf/retain5.map: Allow \ path separator.
		* testsuite/ld-plugin/plugin-10.d: Likewise.
		* testsuite/ld-plugin/plugin-11.d: Likewise.
		* testsuite/ld-plugin/plugin-18.d: Likewise.
		* testsuite/ld-plugin/plugin-19.d: Likewise.
		* testsuite/ld-plugin/plugin-20.d: Likewise.
		* testsuite/ld-plugin/plugin-22.d: Likewise.

2023-02-20  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: Consistency fixes for GDB/MI documentation
	I noticed two inconsistencies in the GDB/MI documentation, which this
	commit addresses:

	  1. Each MI command is introduced like this:

	     @subheading The @code{-command-name} Command

	     Except for a few of the tracing command, which just use:

	     @subheading -command-name

	     In this commit I've updated all these trace commands to use the
	     more common format.

	  2. Each MI command starts with a @subheading, and then the details
	     of that command are split up using multiple @subsubheading
	     entries.

	     Except for a few commands which use @subheading for the top-level
	     command, and then continue to use @subheading for each part of
	     the command description.

	     In this commit I've updated these to use @subsubheading where
	     appropriate.

2023-02-20  Nick Clifton  <nickc@redhat.com>

	So the linker from producing an export data table when run with --exclude-all-symbols.
	 PR 30004 * pe-dll.c (pe_dll_build_sections): Do not build an edata section if all symbols are being excluded.

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Trust epilogue unwind info for unknown or non-gcc producer
	Currently we only trust epilogue unwind info only for gcc >= 4.5.0.

	This has the effect that we don't trust epilogue unwind info for:
	- unknown producers (CU without DW_AT_producer attribute)
	- non-gcc producers (say, clang).

	Instead, only distrust epilogue unwind info only for gcc < 4.5.0.

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Trust epilogue unwind info for unknown producer (-g0 case)
	For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with
	.eh_frame section), start using the dwarf2 unwinder instead of the
	"amd64 epilogue override" unwinder, by returning true in
	compunit_epilogue_unwind_valid for cust == nullptr.

	This has effect both on the amd64 and i386 targets, but only add amd64
	test-case gdb.base/unwind-on-each-insn-amd64-2.exp.

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Add amd64/i386 epilogue override unwinders
	For amd64 the current frame-unwinders are:
	...
	$ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
	The target architecture is set to "i386:x86-64".
	dummy                   DUMMY_FRAME
	dwarf2 tailcall         TAILCALL_FRAME
	inline                  INLINE_FRAME
	python                  NORMAL_FRAME
	amd64 epilogue          NORMAL_FRAME
	dwarf2                  NORMAL_FRAME
	dwarf2 signal           SIGTRAMP_FRAME
	amd64 sigtramp          SIGTRAMP_FRAME
	amd64 prologue          NORMAL_FRAME
	...

	For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with
	.eh_frame section), we'd like to start using the dwarf2 unwinder instead of
	the "amd64 epilogue" unwinder, by returning true in
	compunit_epilogue_unwind_valid for cust == nullptr.

	But we'd run into the following problem for a -g0
	-fno-asynchronous-unwind-tables (without .debug_info and .eh_frame section)
	exec:
	- the "amd64 epilogue" unwinder would not run
	  (because compunit_epilogue_unwind_valid () == true)
	- the dwarf2 unwinder would also not run
	  (because there's no .eh_frame info).

	Fix this by:
	- renaming the "amd64 epilogue" unwinder to "amd64 epilogue override", and
	- adding a fallback "amd64 epilogue" after the dwarf unwinders,
	while making sure that only one of the two is active.  Likewise for i386.  NFC.

	For amd64, this results in this change:
	...
	 $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
	 The target architecture is set to "i386:x86-64".
	 dummy                   DUMMY_FRAME
	 dwarf2 tailcall         TAILCALL_FRAME
	 inline                  INLINE_FRAME
	 python                  NORMAL_FRAME
	-amd64 epilogue          NORMAL_FRAME
	+amd64 epilogue override NORMAL_FRAME
	 dwarf2                  NORMAL_FRAME
	 dwarf2 signal           SIGTRAMP_FRAME
	+amd64 epilogue          NORMAL_FRAME
	 amd64 sigtramp          SIGTRAMP_FRAME
	 amd64 prologue          NORMAL_FRAME
	...

	And for i386:
	...
	 $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
	 The target architecture is set to "i386".
	 dummy                   DUMMY_FRAME
	 dwarf2 tailcall         TAILCALL_FRAME
	 iline                  INLINE_FRAME
	-i386 epilogue           NORMAL_FRAME
	+i386 epilogue override  NORMAL_FRAME
	 dwarf2                  NORMAL_FRAME
	 dwarf2 signal           SIGTRAMP_FRAME
	+i386 epilogue           NORMAL_FRAME
	 i386 stack tramp        NORMAL_FRAME
	 i386 sigtramp           SIGTRAMP_FRAME
	 i386 prologue           NORMAL_FRAME
	...

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Fix amd64/i386_stack_frame_destroyed_p
	The use of compunit_epilogue_unwind_valid in both amd64_stack_frame_destroyed_p
	and i386_stack_frame_destroyed_p is problematic, in the sense that the
	functions no longer match their documented behaviour.

	Fix this by moving the use of compunit_epilogue_unwind_valid to
	amd64_epilogue_frame_sniffer and i386_epilogue_frame_sniffer.  No functional
	changes.

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Factor out compunit_epilogue_unwind_valid
	Factor out compunit_epilogue_unwind_valid from both
	amd64_stack_frame_destroyed_p and i386_stack_frame_destroyed_p.  No functional
	changes.

	Also add a comment in the new function about the assumption that in absence of
	producer information, epilogue unwind info is invalid.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add xfail case in gdb.python/py-record-btrace.exp
	I came across:
	...
	gdb) PASS: gdb.python/py-record-btrace.exp: prepare record: stepi 100
	python insn = r.instruction_history^M
	warning: Non-contiguous trace at instruction 1 (offset = 0x3e10).^M
	(gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: python insn = r.i\
	nstruction_history
	...

	I'm assuming it's the same root cause as for the already present XFAIL.

	Fix this by recognizing above warning in the xfail regexp.

	Tested on x86_64-linux, although sofar I was not able to trigger the warning
	again.

	Approved-By: Markus T. Metzger <markus.t.metzger@intel.com>

2023-02-20  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/schedlock.exp for gcc 4.8.5
	Since commit 9af467b8240 ("[gdb/testsuite] Fix gdb.threads/schedlock.exp on
	fast cpu"), the test-case fails for gcc 4.8.5.

	The problem is that for gcc 4.8.5, the commit turned a two-line loop:
	...
	(gdb) next
	78          while (*myp > 0)
	(gdb) next
	81              MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
	(gdb) next
	78          while (*myp > 0)
	...
	into a three-line loop:
	...
	(gdb) next
	83              MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
	(gdb) next
	84              cnt++;
	(gdb) next
	85            }
	(gdb) next
	83              MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
	(gdb)
	...
	and the test-case doesn't expect this.

	Fix this by reverting back to the original loop shape as much as possible by:
	- removing the cnt++ line
	- replacing "while (1)" with "while (one)", where one is a volatile variable
	  set to 1.

	Tested on x86_64-linux, using compilers:
	- gcc 4.8.5, 7.5.0, 12.2.1
	- clang 4.0.1, 13.0.1

2023-02-20  Alan Modra  <amodra@gmail.com>

	In-memory nested archives
	alpha-linuxecoff has compressed archives that are decompressed to a
	bfd-in-memory.  We'd need to handle quite a lot of corner cases to
	support nesting of such archives, so just stop it before we run into
	segfaults later.

		* opncls.c (_bfd_new_bfd_contained_in): Prohibit nested
		archives in memory.

2023-02-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-19  Tom Tromey  <tom@tromey.com>

	Convert contained_in to method
	This converts contained_in to be a method of block.

	Make block members 'private'
	This changes block to make the data members 'private'.

	Remove allocate_block and allocate_global_block
	This removes allocate_block and allocate_global_block in favor of
	simply calling 'new'.

	Have global_block inherit from block
	This changes global_block to inherit from block, which is what was
	always intended.

	Use 'new' for block and global_block
	This changes block and global_block to add initializers, and then to
	use 'new' for allocation.

2023-02-19  Tom Tromey  <tom@tromey.com>

	Fix memory leak in mdebugread.c
	mdebugread.c allocates blocks on the heap.  However, this is a memory
	leak if the corresponding objfile is ever destroyed.

	This patch changes this code to use allocate_block instead, fixing a
	FIXME from 2003.

	I don't know how to test this patch.

2023-02-19  Tom Tromey  <tom@tromey.com>

	Remove ALL_BLOCK_SYMBOLS
	This removes ALL_BLOCK_SYMBOLS in favor of foreach.

	Remove ALL_BLOCK_SYMBOLS_WITH_NAME
	This removes ALL_BLOCK_SYMBOLS_WITH_NAME in favor of foreach.

	Convert explicit iterator uses to foreach
	This converts most existing explicit uses of block_iterator to use
	foreach with the range iterator instead.

	Introduce a block iterator wrapper
	This introduces a C++-style iterator that wraps the existing
	block_iterator.  It also adds a range adapter.  These will be used in
	a later patch.

	Combine both styles of block iterator
	This merges the two styles of block iterator, having the
	initialization API decide which to use based on an optional parameter.

	Store 'name' in block_iterator
	This changes the block_iterator to store the 'name' that is used by
	block_iter_match_next.  This avoids any problem where the name could
	be passed inconsistently, and also makes the subsequent patches easier
	to understand.

	Convert block_static_link to method
	This converts block_static_link to be a method.  This was mostly
	written by script.

	Convert set_block_compunit_symtab to method
	This converts set_block_compunit_symtab to be a method.  This was
	mostly written by script.

	Convert block_static_block and block_global_block to methods
	This converts block_static_block and block_global_block to be methods.
	This was mostly written by script.  It was simpler to convert them at
	the same time because they're often used near each other.

	Convert block_containing_function to method
	This converts block_containing_function to be a method.  This was
	mostly written by script.

	Convert block_linkage_function to method
	This converts block_linkage_function to be a method.  This was mostly
	written by script.

	Convert more block functions to methods
	This converts block_scope, block_set_scope, block_using, and
	block_set_using to be methods.  These are all done at once to make it
	easier to also convert block_initialize_namespace at the same time.
	This was mostly written by script.

	Convert block_inlined_p to method
	This converts block_inlined_p to be a method.  This was mostly written
	by script.

	Convert block_gdbarch to method
	This converts block_gdbarch to be a method.  This was mostly written
	by script.

	Convert block_objfile to method
	This converts block_objfile to be a method.  This was mostly written
	by script.

	Don't allow NULL as an argument to block_global_block
	block_global_block has special behavior when the block is NULL.
	Remove this and patch up the callers instead.

	Don't allow NULL as an argument to block_static_block
	block_static_block has special behavior when the block is NULL.
	Remove this and patch up the callers instead.

	Don't allow NULL as an argument to block_using
	block_using has special behavior when the block is NULL.
	Remove this.  No caller seems to be affected.

	Don't allow NULL as an argument to block_scope
	block_scope has special behavior when the block is NULL.
	Remove this and patch up the callers instead.

	Avoid extra allocations in block
	block_set_scope and block_set_using unconditionally allocate the block
	namespace object.  However, this isn't truly needed, so arrange to
	only allocate when it is.

	Rearrange block.c to avoid a forward declaration
	Moving block_initialize_namespace before its callers lets us avoid a
	forward declaration.

2023-02-19  Alan Modra  <amodra@gmail.com>

	Buffer overflow in evax_bfd_print_eobj
		* vms-alpha.c (evax_bfd_print_eobj): Rewrite header handling,
		sanity checking rec_len.  Check bfd_malloc return.

2023-02-19  Tom Tromey  <tom@tromey.com>

	Avoid memory leak in chew
	An earlier patch of mine introduced a memory leak in chew.  The bug
	was that the new "variable" word didn't free the following word.  This
	patch fixes it by arranging to transfer ownership of the name to the
	variable itself.

		* doc/chew.c (add_variable): New function, from
		add_intrinsic_variable.
		(add_intrinsic_variable): Call add_variable.
		(compile): Call add_variable.

2023-02-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-18  Tom Tromey  <tom@tromey.com>

	Fix "start" for D, Rust, etc
	The new DWARF indexer broke "start" for some languages.

	For D, it is broken because, while the code in cooked_index_shard::add
	specifically excludes Ada, it fails to exclude D.  This means that the
	C "main" will be detected as "main" here -- whereas what is intended
	is for the code in find_main_name to use d_main_name to find the name.

	The Rust compiler, on the other hand, uses DW_AT_main_subprogram.
	However, the code in dwarf2_build_psymtabs_hard fails to create a
	fully-qualified name, so the name always ends up as plain "main".

	For D and Ada, a very simple approach suffices: remove the check
	against "main" from cooked_index_shard::add.  This also has the
	benefit of slightly speeding up DWARF indexing.  I assume this
	approach will work for Pascal and Modula-2 as well, but I don't have a
	way to test those at present.

	For Rust, though, this is not sufficient.  And, computing the
	fully-qualified name in dwarf2_build_psymtabs_hard will crash, because
	cooked_index_entry::full_name uses the canonical name -- and that is
	not computed until after canonicalization.

	However, we don't want to wait for canonicalization to be done before
	computing the main name.  That would remove any benefit from doing
	canonicalization is the background.

	This patch solves this dilemma by noticing that languages using
	DW_AT_main_subprogram are, currently, disjoint from languages
	requiring canonicalization.  Because of this, we can add a parameter
	to full_name to let us avoid crashes, slowdowns, and races here.

	This is kind of tricky and ugly, so I've tried to comment it
	sufficiently.

	While doing this, I had to change gdb.dwarf2/main-subprogram.exp.  A
	different possibility here would be to ignore the canonicalization
	needs of C in this situation, because those only affect certain types.
	However, I chose this approach because the test case is artificial
	anyhow.

	A long time ago, in an earlier threading attempt, I changed the global
	current_language to be a function (hidden behind a macro) to let us
	attempt lazily computing the current language.  Perhaps this approach
	could still be made to work.  However, that also seemed rather tricky,
	more so than this patch.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116

2023-02-18  Tom Tromey  <tom@tromey.com>

	Fix crash in go_symbol_package_name
	go_symbol_package_name package name asserts that it is only passed a
	Go symbol, but this is not enforced by one caller.  It seems simplest
	to just check and return early in this case.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17876
	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-18  Tom Tromey  <tom@tromey.com>

	Avoid manual memory management in go-lang.c
	I noticed a couple of spots in go-lang.c that could be improved by
	using unique_ptr.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-17  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix regression in gdb.xml/maint_print_struct.exp
	A regression in gdb.xml/maint_print_struct.exp was introduced with
	commit:

	  commit 81b86eced24f905545b58aa6c27478104c364976
	  Date:   Fri Jan 6 09:30:40 2023 -0700

	      Do not record a rejected target description

	The test relied on an invalid target description being stored within
	the tdesc_info of the current inferior, the above commit stopped this
	behaviour.

	Update the test to check that the invalid architecture is NOT stored,
	and then check printing the target description directly from the
	file.

	Approved-By: Tom Tromey <tromey@adacore.com>

2023-02-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix Dwarf reader for DW_TAG_subprogram
	gprofng/ChangeLog
	2023-02-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		* src/Dwarf.cc: Skip DW_TAG_subprogram when DW_AT_declaration is 1.

2023-02-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: PR30036 Build failure on aarch64 w/ glibc: symbol `pwrite64' is already defined
	gprofng/ChangeLog
	2023-02-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30036
		* libcollector/iotrace.c: Define creat64 and pwrite64 only when
		__USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not defined.
		* libcollector/mmaptrace.c: Likewise for mmap64.

2023-02-17  Aditya Vidyadhar Kamath  <Aditya.Kamath1@ibm.com>

	Fix multi-threaded debugging under AIX
	Multi-threaded debugging using the libpthdebug debug interface
	is currently broken due to multiple issues.

	When debugging a single inferior, we were getting assertion
	failures in get_aix_thread_info as no tp->priv structure was
	allocated for the main thread.

	We fixed this by switching the main
	thread from a (pid, 0, 0) ptid_t to a (pid, 0, tid) ptid_t and
	allocaing the tp->priv structure in sync_threadlists.

	As a result, the switch_to_thread call in pdc_read_data could
	now fail since the main thread no longer uses (pid, 0, 0).

	So we replaced the call by only switching inferior_ptid, the current
	inferior, and the current address space (like proc-service.c).
	Add similar switching to pdc_write_data where it was missing
	completely.

	When debugging multiple inferiors, an additional set of
	problems prevented correct multi-threaded debugging:

	First of all, aix-thread.c used to have a number of global
	variables holding per-inferior information.

	We switched hese
	to a per-inferior data structure instead.

	Also, sync_threadlists was getting confused as we were
	comparing the list of threads returned by libpthdebug
	for *one* process with GDB's list of threads for *all*
	processes. Now we only use he GDB threads of the current
	inferior instead.

	We also skip calling pd_activate
	from pd_enable if that in_initial_library_scan flag is
	true for the current inferior.

	Finally, the presence of the thread library in any but
	the first inferior was not correctly detected due to a
	bug in solib-aix.c, where the BFD file name for shared
	library members was changed when the library was loaded
	for the first time, which caused the library to no longer
	be recognized by name when loaded a second time.

2023-02-17  Tom Tromey  <tromey@adacore.com>

	Remove two unnecessary returns in ada-lang.c
	I found a couple of spots in ada-lang.c where a return follows a call
	to error.  These are unnecessary because error never returns.

2023-02-17  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.arch/amd64-disp-step-avx.exp
	On SLE-11, with glibc 2.11.3, I run into:
	...
	(gdb) PASS: gdb.arch/amd64-disp-step-avx.exp: vex3: \
	  var128 has expected value after
	continue^M
	Continuing.^M
	^M
	Program received signal SIGSEGV, Segmentation fault.^M
	0x0000000000400283 in _exit (status=0) at \
	  ../sysdeps/unix/sysv/linux/_exit.c:33^M
	33      ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.^M
	(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: \
	  continue until exit at amd64-disp-step-avx
	...

	This is not related to gdb, we get the same result by just running the exec.

	The problem is that the test-case:
	- calls glibc's _exit, and
	- uses -nostartfiles -static, putting the burden for any necessary
	  initialization for calling glibc's _exit on the test-case itself.

	So, when we get to the second insn in _exit:
	...
	000000000040acb0 <_exit>:
	  40acb0:       48 63 d7                movslq %edi,%rdx
	  40acb3:       64 4c 8b 14 25 00 00    mov    %fs:0x0,%r10
	...
	no glibc-related initialization is done, and we run into the segfault.

	Adding this (borrowed from __libc_start_main) in _start in the .S file is
	sufficient to fix it:
	...
	         .rept 200
	         nop
	+        call __pthread_initialize_minimal
	         .endr
	...
	But that already doesn't compile with say glibc 2.31, and regardless I think
	this sort of fix is too fragile.

	We could of course fix this by simply not running to exit.  But ideally we'd
	have an exec that doesn't segfault when you just run it.

	Alternatively, we could hand-code an _exit syscall and bypass glibc
	all together.  But I'd rather fix this in a way that simplifies the test-case.

	Taking a step back, the -nostartfiles -static was added to address that the
	xmm registers were not zero at main (which AFAICT is a valid thing to happen).

	[ The change itself silently broke the test-case, needing further fixing by
	commit 40310f30a51 ("gdb: make gdb.arch/amd64-disp-step-avx.exp actually test
	displaced stepping"). ]

	Instead, simplify things by reverting to the original situation:
	- no -nostartfiles -static compilation flags,
	- no _start in the .S file,
	- use exit instead of _exit in the .S file,
	and fix the original problem by setting the xmm registers to zero rather than
	checking that they're zero.

	Now that we're no longer forcing -static, add nopie to the flags to prevent
	compilation failure with target board unix/-fPIE/-pie.

	Tested on x86_64-linux.

	PR testsuite/30132
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30132

2023-02-17  Alan Modra  <amodra@gmail.com>

	ld test asciz and ascii fails
	Fix these fails:
	alpha-dec-vms  +FAIL: ld-scripts/asciz
	alpha-dec-vms  +FAIL: ld-scripts/ascii
	i386-go32  +FAIL: ld-scripts/asciz
	sh-coff  +FAIL: ld-scripts/asciz

	It's better to positively select targets for .section support than to
	try to exclude all targets that don't.  Make a new is_coff_format so
	we can easily select such.

	binutils/
		* testsuite/lib/binutils-common.exp (is_coff_format): New.
	ld/
		* testsuite/ld-scripts/ascii.d: Use is_elf_format and
		is_coff_format to select targets, exclude ti coff.
		* testsuite/ld-scripts/asciz.d: Likewise.  Accept trailing zeros.

2023-02-17  Alan Modra  <amodra@gmail.com>

	Wild pointer reads in _bfd_ecoff_locate_line
		* ecofflink.c (mk_fdrtab): Sanity check fdr procedure descriptor
		pointer and isymBase.  Set fdrtab_len after possible discards.
		Use size_t vars and catch possible size overflows.

2023-02-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-16  Alan Modra  <amodra@gmail.com>

	PR30046, power cmpi leads to unknown architecture
	PowerPC ELF always uses bfd_arch_powerpc, so we shouldn't allow the
	gas -mpwr, -mpwr2 or -mpwrx options to choose bfd_arch_rs6000.
	Given the possible values of ppc_cpu, I think the as_fatal at the end
	of ppc_arch will never be reached, so it can be deleted and the code
	simplified a little.

		PR 30046
		* config/tc-ppc.c (ppc_arch): Return bfd_arch_powerpc for ELF.
		Delete dead code.

2023-02-16  Tom Tromey  <tromey@adacore.com>

	Rename parameter of create_ada_exception_catchpoint
	create_ada_exception_catchpoint has a parameter named "disabled", but
	both its callers and callees use it to mean "enabled".  This is
	confusing, so this patch renames the parameter.

2023-02-16  Tom Tromey  <tom@tromey.com>

	Update the 'g' packet documentation
	The 'g' packet documentation references a macro that no longer exists,
	and it also claims that the 'x' response for an unavailable register
	is limited to trace frames.  This patch updates the documentation to
	reflect what I think is currently correct.

	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Change-Id: I863baa3b9293059cfd4aa3d534602cbcb693ba87

2023-02-16  Nick Clifton  <nickc@redhat.com>

	Add support for the ASCII directive inside linker scripts.
	 * ldlex.l: Add ASCII token.
	 * ldgram.y: Add parsing of the ASCII command.
	 * ldlang.c (lang_add_string): Add maximum size parameter.  Move escape character handling code into separate function.
	 * ldlang.h (lang_add_string): Update prototype.
	 * NEWS: Mention the new feature.
	 * ld.texi (Output Section Data): Document the new directives.
	 * testsuite/ld-scripts/asciz.t: Adjust to work on more architectures and to test more aspects of the ASCIZ directive.
	 * testsuite/ld-scripts/asciz.d: Adjust to match the changes to the test linker script.
	 * testsuite/ld-scripts/ascii.d: New test driver.
	 * testsuite/ld-scripts/ascii.s: New test assembler source.
	 * testsuite/ld-scripts/ascii.t: New test script.
	 * testsuite/ld-scripts/script.exp: Run the new test.

2023-02-16  Tom Tromey  <tromey@adacore.com>

	Constify ada_main_name
	Unlike the other *_main_name functions, ada_main_name returns a
	non-const "char *".  This is strange, though, because the caller
	should not in fact modify or free this pointer.  This patch changes
	this function to constify its return type.

	Remove unused declaration from ada-lang.h
	I stumbled across this declaration in ada-lang.h.  I don't know what
	function did, but it no longer exists, so remove the declaration.
	Tested by rebuilding.

2023-02-16  Alan Modra  <amodra@gmail.com>

	Delete PROGRESS macros
	I don't see much point in cluttering the source with the PROGRESS
	macros, which of course do nothing at all with the definitions in
	progress.h.  progress.h is unchanged apart from the copyright comment
	since commit d4d4c53c68f0 in 1994.

	binutils/
		* ar.c: Don't include progress.h, or invoke PROGRESS macros.
		* nm.c: Likewise.
		* objcopy.c: Likewise.
		* objdump.c: Likewise.
	gas/
		* as.h: Don't include progress.h.
		* as.c: Don't invoke PROGRESS macros.
		* write.c: Likewise.
	include/
		* progress.h: Delete.
	ld/
		* ldmain.c: Don't include progress.h, or invoke PROGRESS macros.

2023-02-16  Alan Modra  <amodra@gmail.com>

	gas_init
	Rename gas_late_init to plain gas_init, to reinforce the idea that
	this is where the bulk of gas initialisation belongs.  Also reorder
	some initialisation.

		* as.c (gas_init): Rename from gas_late_init.  Open output
		file and arrange for dump_statistics to be called here rather
		than in main.  Create .gasversion. local symbol earlier,
		because we can.

2023-02-16  Jan Beulich  <jbeulich@suse.com>

	RISC-V: as_warn() already emits a newline
	Therefore there shouldn't be any at the end of the format string.

2023-02-16  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: document MI -remove-inferior command
	Back in 2010 the -remove-inferior command was added in commit
	a79b8f6ea8c2, unfortunately this command was never added to the
	documentation.

	This commit addresses that oversight.

	Approved-By: Eli Zaretskii <eliz@gnu.org>

2023-02-16  Jan Beulich  <jbeulich@suse.com>

	x86/gas: replace inappropriate assertion when parsing registers
	PR gas/30117
	Once a symbol had its expression evaluated, the "segment" of the symbol
	may be reg_section if a register is merely involved in the expression,
	not just when the expression references a "plain" register. Therefore
	the first of the assertions put in place by 4d1bb7955a8b was too strict.
	Convert it to an if() to deal with situations like this one found by
	fuzzing:

		x=s
		s=%eax+0
		y=s
		or $6,x

	In non-debug builds this also avoids potentially silently generating bad
	code.

2023-02-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-15  Tom Tromey  <tom@tromey.com>

	Return bool from more value methods
	There are several more value methods that currently return 'int' but
	that should return 'bool'.  This patch updates these.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Tom Tromey  <tom@tromey.com>

	Have value::bits_synthetic_pointer return bool
	This changes value::bits_synthetic_pointer to return bool and fixes up
	some fallout from this.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Tom Tromey  <tom@tromey.com>

	Change value::m_stack to bool
	This changes value::m_stack to be a bool and updates the various uses.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Tom Tromey  <tom@tromey.com>

	Change value::m_initialized to bool
	This changes value::m_initialized to be a bool and updates the various
	uses.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Tom Tromey  <tom@tromey.com>

	Change value::m_lazy to bool
	This changes value::m_lazy to be a bool and updates the various uses.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Tom Tromey  <tom@tromey.com>

	Change value::m_modifiable to bool
	This changes value::m_modifiable to be a bool and updates the various
	uses.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-02-15  Pedro Alves  <pedro@palves.net>

	Don't throw quit while handling inferior events, part II
	I noticed that if Ctrl-C was typed just while GDB is evaluating a
	breakpoint condition in the background, and GDB ends up reaching out
	to the Python interpreter, then the breakpoint condition would still
	fail, like:

	  c&
	  Continuing.
	  (gdb) Error in testing breakpoint condition:
	  Quit

	That happens because while evaluating the breakpoint condition, we
	enter Python, and end up calling PyErr_SetInterrupt (it's called by
	gdbpy_set_quit_flag, in frame #0):

	 (top-gdb) bt
	 #0  gdbpy_set_quit_flag (extlang=0x558c68f81900 <extension_language_python>) at ../../src/gdb/python/python.c:288
	 #1  0x0000558c6845f049 in set_quit_flag () at ../../src/gdb/extension.c:785
	 #2  0x0000558c6845ef98 in set_active_ext_lang (now_active=0x558c68f81900 <extension_language_python>) at ../../src/gdb/extension.c:743
	 #3  0x0000558c686d3e56 in gdbpy_enter::gdbpy_enter (this=0x7fff2b70bb90, gdbarch=0x558c6ab9eac0, language=0x0) at ../../src/gdb/python/python.c:212
	 #4  0x0000558c68695d49 in python_on_memory_change (inferior=0x558c6a830b00, addr=0x555555558014, len=4, data=0x558c6af8a610 "") at ../../src/gdb/python/py-inferior.c:146
	 #5  0x0000558c6823a071 in std::__invoke_impl<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__f=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:61
	 #6  0x0000558c68237591 in std::__invoke_r<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__fn=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:111
	 #7  0x0000558c68233e64 in std::_Function_handler<void (inferior*, unsigned long, long, unsigned char const*), void (*)(inferior*, unsigned long, long, unsigned char const*)>::_M_invoke(std::_Any_data const&, inferior*&&, unsigned long&&, long&&, unsigned char const*&&) (__functor=..., __args#0=@0x7fff2b70bd40: 0x558c6a830b00, __args#1=@0x7fff2b70bd38: 93824992247828, __args#2=@0x7fff2b70bd30: 4, __args#3=@0x7fff2b70bd28: 0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:290
	 #8  0x0000558c6830a96e in std::function<void (inferior*, unsigned long, long, unsigned char const*)>::operator()(inferior*, unsigned long, long, unsigned char const*) const (this=0x558c6a8ecd98, __args#0=0x558c6a830b00, __args#1=93824992247828, __args#2=4, __args#3=0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:590
	 #9  0x0000558c6830a620 in gdb::observers::observable<inferior*, unsigned long, long, unsigned char const*>::notify (this=0x558c690828c0 <gdb::observers::memory_changed>, args#0=0x558c6a830b00, args#1=93824992247828, args#2=4, args#3=0x558c6af8a610 "") at ../../src/gdb/../gdbsupport/observable.h:166
	 #10 0x0000558c68309d95 in write_memory_with_notification (memaddr=0x555555558014, myaddr=0x558c6af8a610 "", len=4) at ../../src/gdb/corefile.c:363
	 #11 0x0000558c68904224 in value_assign (toval=0x558c6afce910, fromval=0x558c6afba6c0) at ../../src/gdb/valops.c:1190
	 #12 0x0000558c681e3869 in expr::assign_operation::evaluate (this=0x558c6af8e150, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/expop.h:1902
	 #13 0x0000558c68450c89 in expr::logical_or_operation::evaluate (this=0x558c6afab060, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:2330
	 #14 0x0000558c6844a896 in expression::evaluate (this=0x558c6afcfe60, expect_type=0x0, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:110
	 #15 0x0000558c6844a95e in evaluate_expression (exp=0x558c6afcfe60, expect_type=0x0) at ../../src/gdb/eval.c:124
	 #16 0x0000558c682061ef in breakpoint_cond_eval (exp=0x558c6afcfe60) at ../../src/gdb/breakpoint.c:4971
	 ...


	The fix is to disable cooperative SIGINT handling while handling
	inferior events, so that SIGINT is saved in the global quit flag, and
	not in the extension language, while handling an event.

	This commit augments the testcase added by the previous commit to test
	this scenario as well.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Idf8ab815774ee6f4b45ca2d0caaf30c9b9f127bb

2023-02-15  Pedro Alves  <pedro@palves.net>

	GC get_active_ext_lang
	get_active_ext_lang is not used anywhere.  Delete it.

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I4c2b6d0d11291103c098e4db1d6ea449875c96b7

2023-02-15  Pedro Alves  <pedro@palves.net>

	Don't throw quit while handling inferior events
	This implements what I suggested here:

	 https://inbox.sourceware.org/gdb-patches/ab97c553-f406-b094-cdf3-ba031fdea925@palves.net/

	Here is the current default quit_handler, a function that ends up
	called by the QUIT macro:

	 void
	 default_quit_handler (void)
	 {
	   if (check_quit_flag ())
	     {
	       if (target_terminal::is_ours ())
	 	quit ();
	       else
	 	target_pass_ctrlc ();
	      }
	 }

	As we can see above, when the inferior is running in the foreground,
	then a Ctrl-C is translated into a call to target_pass_ctrlc().

	The target_terminal::is_ours() case above is there to handle the
	scenario where GDB has the terminal, meaning it is handling some
	command the user typed, like "list", or "p a + b" or some such.

	However, when the inferior is running on the background, say with
	"c&", GDB also has the terminal.  Run control handling is now done in
	the "background".  The CLI is responsive to user commands.  If users
	type Ctrl-C, they're expecting it to interrupt whatever command they
	next type in the CLI, which again, could be "list", "p a + b", etc.
	It's as if background run control was handled by a separate thread,
	and the Ctrl-C is meant to go to the main thread, handling the CLI.

	However, when handling an event, inside fetch_inferior_event &
	friends, a Ctrl-C _also_ results in a Quit exception, from the same
	default_quit_handler function shown above.  This quit aborts run
	control handling, breakpoint condition evaluation, etc., and may even
	leave run control in an inconsistent state.

	The testcase added by this patch illustrates this.  The test program
	just loops a number of times calling the "foo" function.

	The idea is to set a breakpoint in the "foo" function with a condition
	that sends SIGINT to GDB, and then evaluates to false, which results
	in the program being re-resumed in the background.  The SIGINT-sending
	emulates pressing Ctrl-C just while GDB was evaluating the breakpoint
	condition, except, it's more deterministic.

	It looks like this:

	  (gdb) p $counter = 0
	  $1 = 0
	  (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
	  Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21.
	  (gdb) c&
	  Continuing.
	  (gdb)

	After that background continue, the breakpoint should be hit 10 times,
	and we should see 10 "Quit" being printed on the screen.  As if the
	user typed Ctrl-C on the prompt a number of times with no inferior
	running:

	  (gdb)        <<< Ctrl-C
	  (gdb) Quit   <<< Ctrl-C
	  (gdb) Quit   <<< Ctrl-C
	  (gdb)

	However, here's what you see instead:

	  (gdb) c&
	  Continuing.
	  (gdb) Quit
	  (gdb)

	Just one Quit, and nothing else.  If we look at the thread's state, we see:

	  (gdb) info threads
	    Id   Target Id                                            Frame
	  * 1    Thread 0x7ffff7d6f740 (LWP 112192) "bg-exec-sigint-" foo () at gdb.base/bg-exec-sigint-bp-cond.c:21

	So the thread stopped, but we didn't report a stop...

	Issuing another continue shows the same immediate-and-silent-stop:

	  (gdb) c&
	  Continuing.
	  (gdb) Quit
	  (gdb) p $counter
	  $2 = 2

	As mentioned, since the run control handling, and breakpoint and
	watchpoint evaluation, etc. are running in the background from the
	perspective of the CLI, when users type Ctrl-C in this situation,
	they're thinking of aborting whatever other command they were typing
	or running at the prompt, not the run control side, not the previous
	"c&" command.

	So I think that we should install a custom quit_handler while inside
	fetch_inferior_event, where we already disable pagination and other
	things for a similar reason.  This custom quit handler does nothing if
	GDB has the terminal, and forwards Ctrl-C to the inferior otherwise.

	With the patch implementing that, and the same testcase, here's what
	you see instead:

	 (gdb) p $counter = 0
	 $1 = 0
	 (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
	 Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21.
	 (gdb) c&
	 Continuing.
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb) Quit
	 (gdb)
	 Breakpoint 2, foo () at gdb.base/bg-exec-sigint-bp-cond.c:21
	 21        return 0;

	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: I1f10d99496a7d67c94b258e45963e83e439e1778

2023-02-15  Pedro Alves  <pedro@palves.net>

	Add new "$_shell(CMD)" internal function
	For testing a following patch, I wanted a way to send a SIGINT to GDB
	from a breakpoint condition.  And I didn't want to do it from a Python
	breakpoint or Python function, as I wanted to exercise non-Python code
	paths.  So I thought I'd add a new $_shell internal function, that
	runs a command under the shell, and returns the exit code.  With this,
	I could write:

	  (gdb) b foo if $_shell("kill -SIGINT $gdb_pid") != 0 || <other condition>

	I think this is generally useful, hence I'm proposing it here.

	Here's the new function in action:

	 (gdb) p $_shell("true")
	 $1 = 0
	 (gdb) p $_shell("false")
	 $2 = 1
	 (gdb) p $_shell("echo hello")
	 hello
	 $3 = 0
	 (gdb) p $_shell("foobar")
	 bash: line 1: foobar: command not found
	 $4 = 127
	 (gdb) help function _shell
	 $_shell - execute a shell command and returns the result.
	 Usage: $_shell (command)
	 Returns the command's exit code: zero on success, non-zero otherwise.
	 (gdb)

	NEWS and manual changes included.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>
	Approved-By: Eli Zaretskii <eliz@gnu.org>
	Change-Id: I7e36d451ee6b428cbf41fded415ae2d6b4efaa4e

2023-02-15  Pedro Alves  <pedro@palves.net>

	Make "ptype INTERNAL_FUNCTION" in Ada print like other languages
	Currently, printing the type of an internal function in Ada shows
	double <>s, like:

	 (gdb) with language ada -- ptype $_isvoid
	 type = <<internal function>>

	while all other languages print it with a single <>, like:

	 (gdb) with language c -- ptype $_isvoid
	 type = <internal function>

	I don't think there's a reason that Ada needs to be different.  We
	currently print the double <>s because we take this path in
	ada_print_type:

	    switch (type->code ())
	      {
	      default:
		gdb_printf (stream, "<");
		c_print_type (type, "", stream, show, level, language_ada, flags);
		gdb_printf (stream, ">");
		break;

	... and the type's name already has the <>s.

	Fix this by simply adding an early check for
	TYPE_CODE_INTERNAL_FUNCTION.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Approved-By: Tom Tromey <tom@tromey.com>
	Change-Id: Ic2b6527b9240a367471431023f6e27e6daed5501
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105

2023-02-15  Pedro Alves  <pedro@palves.net>

	Fix "ptype INTERNAL_FUNC" (PR gdb/30105)
	Currently, looking at the type of an internal function, like below,
	hits an odd error:

	 (gdb) ptype $_isvoid
	 type = <internal function>type not handled in c_type_print_varspec_prefix()

	That is an error thrown from
	c-typeprint.c:c_type_print_varspec_prefix, where it reads:

	    ...
	    case TYPE_CODE_DECFLOAT:
	    case TYPE_CODE_FIXED_POINT:
	      /* These types need no prefix.  They are listed here so that
		 gcc -Wall will reveal any types that haven't been handled.  */
	      break;
	    default:
	      error (_("type not handled in c_type_print_varspec_prefix()"));
	      break;

	Internal function types have type code TYPE_CODE_INTERNAL_FUNCTION,
	which is not explicitly handled by that switch.

	That comment quoted above says that gcc -Wall will reveal any types
	that haven't been handled, but that's not actually true, at least with
	modern GCCs.  You would need to enable -Wswitch-enum for that, which
	we don't.  If I do enable that warning, then I see that we're missing
	handling for the following type codes:

	   TYPE_CODE_INTERNAL_FUNCTION,
	   TYPE_CODE_MODULE,
	   TYPE_CODE_NAMELIST,
	   TYPE_CODE_XMETHOD

	TYPE_CODE_MODULE and TYPE_CODE_NAMELIST and Fortran-specific, so it'd
	be a little weird to handle them here.

	I tried to reach this code with TYPE_CODE_XMETHOD, but couldn't figure
	out how to.  ptype on an xmethod isn't treated specially, it just
	complains that the method doesn't exist.  I've extended the
	gdb.python/py-xmethods.exp testcase to make sure of that.

	My thinking is that whatever type code we add next, the most likely
	scenario is that it won't need any special handling, so we'd just be
	adding another case to that "do nothing" list.  If we do need special
	casing for whatever type code, I think that tests added at the same
	time as the feature would uncover it anyhow.  If we do miss adding the
	special casing, then it still looks better to me to print the type
	somewhat incompletely than to error out and make it harder for users
	to debug whatever they need.  So I think that the best thing to do
	here is to just remove all those explicit "do nothing" cases, along
	with the error default case.

	After doing that, I decided to write a testcase that iterates over all
	supported languages doing "ptype INTERNAL_FUNC".  That revealed that
	Pascal has a similar problem, except the default case hits a
	gdb_assert instead of an error:

	 (gdb) with language pascal -- ptype $_isvoid
	 type =
	 ../../src/gdb/p-typeprint.c:268: internal-error: type_print_varspec_prefix: unexpected type
	 A problem internal to GDB has been detected,
	 further debugging may prove unreliable.

	That is fixed by this patch in the same way.

	You'll notice that the new testcase special-cases the Ada expected
	output:

		} elseif {$lang == "ada"} {
		    gdb_test "ptype \$_isvoid" "<<internal function>>"
		} else {
		    gdb_test "ptype \$_isvoid" "<internal function>"
		}

	That will be subject of the following patch.

	Approved-By: Andrew Burgess <aburgess@redhat.com>
	Change-Id: I81aec03523cceb338b5180a0b4c2e4ad26b4c4db
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2: split .debug_names reading code to own file
	Move everything related to reading .debug_names from read.c to
	read-debug-names.c.  The only entry point exposed by
	read-debug-names.{c,h} is dwarf2_read_debug_names.

	Change-Id: I18b23f3c7a61b14abc3a46e4bf559bc2d078e8bc
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf2: split .gdb_index reading code to own file
	Move everything related to reading .gdb_index from read.c to
	read-gdb-index.c.  The only entry point exposed by read-gdb-index.{c,h}
	is dwarf2_read_gdb_index.

	Change-Id: I1e32c8f0720086538de8d2f612f27545377099bc
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf2: move some things to read.h
	The following 2 patches move .gdb_index and .debug_names reading code to
	their own file.  Prepare this by exposing some things used by that code
	to read.h.

	Change-Id: If8ef135758a2ff0ab3b765cc92596da8189f3bbd
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix dealloc function not being called for frame 0
	Tom de Vries reported [1] a regression in gdb.btrace/record_goto.exp
	caused by 6d3717d4c4 ("gdb: call frame unwinders' dealloc_cache methods
	through destroying the frame cache").  This issue is caught by ASan.  On
	a non-ASan build, it may or may not cause a crash or some other issue, I
	haven't tried.

	I managed to narrow it down to:

	    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.btrace/record_goto/record_goto -ex "start" -ex "record btrace" -ex "next"

	... and then doing repeatedly "record goto 19" and "record goto 27".
	Eventually, I get:

	    (gdb) record goto 27
	    =================================================================
	    ==1527735==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003392a8 at pc 0x55e4c26eef86 bp 0x7ffd229f24e0 sp 0x7ffd229f24d8
	    READ of size 8 at 0x6210003392a8 thread T0
	        #0 0x55e4c26eef85 in bfcache_eq /home/simark/src/binutils-gdb/gdb/record-btrace.c:1639
	        #1 0x55e4c37cdeff in htab_find_slot_with_hash /home/simark/src/binutils-gdb/libiberty/hashtab.c:659
	        #2 0x55e4c37ce24a in htab_find_slot /home/simark/src/binutils-gdb/libiberty/hashtab.c:703
	        #3 0x55e4c26ef0c6 in bfcache_new /home/simark/src/binutils-gdb/gdb/record-btrace.c:1653
	        #4 0x55e4c26f1242 in record_btrace_frame_sniffer /home/simark/src/binutils-gdb/gdb/record-btrace.c:1820
	        #5 0x55e4c1b926a1 in frame_unwind_try_unwinder /home/simark/src/binutils-gdb/gdb/frame-unwind.c:136
	        #6 0x55e4c1b930d7 in frame_unwind_find_by_frame(frame_info_ptr, void**) /home/simark/src/binutils-gdb/gdb/frame-unwind.c:196
	        #7 0x55e4c1bb867f in get_frame_type(frame_info_ptr) /home/simark/src/binutils-gdb/gdb/frame.c:2925
	        #8 0x55e4c2ae6798 in print_frame_info(frame_print_options const&, frame_info_ptr, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:1049
	        #9 0x55e4c2ade3e1 in print_stack_frame(frame_info_ptr, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:367
	        #10 0x55e4c26fda03 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2779
	        #11 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
	        #12 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
	        #13 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
	        #14 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383

	    0x6210003392a8 is located 424 bytes inside of 4064-byte region [0x621000339100,0x62100033a0e0)
	    freed by thread T0 here:
	        #0 0x7f6ca34a5b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
	        #1 0x55e4c38a4c17 in rpl_free /home/simark/src/binutils-gdb/gnulib/import/free.c:44
	        #2 0x55e4c1bbd378 in xfree<void> /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb-xfree.h:37
	        #3 0x55e4c37d1b63 in call_freefun /home/simark/src/binutils-gdb/libiberty/obstack.c:103
	        #4 0x55e4c37d25a2 in _obstack_free /home/simark/src/binutils-gdb/libiberty/obstack.c:280
	        #5 0x55e4c1bad701 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2112
	        #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564
	        #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573
	        #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772
	        #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
	        #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
	        #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
	        #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383

	    previously allocated by thread T0 here:
	        #0 0x7f6ca34a5e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
	        #1 0x55e4c0b55c60 in xmalloc /home/simark/src/binutils-gdb/gdb/alloc.c:57
	        #2 0x55e4c37d1a6d in call_chunkfun /home/simark/src/binutils-gdb/libiberty/obstack.c:94
	        #3 0x55e4c37d1c20 in _obstack_begin_worker /home/simark/src/binutils-gdb/libiberty/obstack.c:141
	        #4 0x55e4c37d1ed7 in _obstack_begin /home/simark/src/binutils-gdb/libiberty/obstack.c:164
	        #5 0x55e4c1bad728 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2113
	        #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564
	        #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573
	        #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772
	        #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
	        #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
	        #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
	        #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383

	The problem is a stale entry in the bfcache hash table (in
	record-btrace.c), left across a reinit_frame_cache.  This entry points
	to something that used to be allocated on the frame obstack, that has
	since been wiped by reinit_frame_cache.

	Before the aforementioned, unwinder deallocation functions were called
	by iterating on the frame chain, starting with the sentinel frame, like
	so:

	  /* Tear down all frame caches.  */
	  for (frame_info *fi = sentinel_frame; fi != NULL; fi = fi->prev)
	    {
	      if (fi->prologue_cache && fi->unwind->dealloc_cache)
		fi->unwind->dealloc_cache (fi, fi->prologue_cache);
	      if (fi->base_cache && fi->base->unwind->dealloc_cache)
		fi->base->unwind->dealloc_cache (fi, fi->base_cache);
	    }

	After that patch, we relied on the fact that all frames are (supposedly)
	in the frame_stash.  A deletion function was added to the frame_stash
	hash table, so that dealloc functions would be called when emptying the
	frame stash.  There is one case, however, where a frame_info is not in
	the frame stash.  That is when we create the frame_info for the current
	frame (level 0, unwound from the sentinel frame), but don't compute its
	frame id.  The computation of the frame id for that frame (and only that
	frame, AFAIK) is done lazily.  And putting a frame_info in the frame stash
	requires knowing its id.  So a frame 0 whose frame id is not computed
	yet is necessarily not in the frame stash.

	When replaying with btrace, record_btrace_frame_sniffer insert entries
	corresponding to frames in the "bfcache" hash table.  It then relies on
	record_btrace_frame_dealloc_cache being called for each frame to remove
	all those entries when the frames get invalidated.  If a frame reinit
	happens while frame 0's id is not computed  (and therefore that frame is
	not in frame_stash), record_btrace_frame_dealloc_cache does not get
	called for it, and it leaves a stale entry in bfcache.  That then leads
	to a use-after-free when that entry is accessed later, which ASan
	catches.

	The proposed solution is to explicitly call frame_info_del on frame 0,
	if it exists, and if its frame id is not computed.  If its frame id is
	computed, it is expected that it will be in the frame stash, so it will
	be "deleted" through that.

	[1] https://inbox.sourceware.org/gdb-patches/20230130200249.131155-1-simon.marchi@efficios.com/T/#mcf1340ce2906a72ec7ed535ec0c97dba11c3d977

	Reported-By: Tom de Vries <tdevries@suse.de>
	Tested-By: Tom de Vries <tdevries@suse.de>
	Change-Id: I2351882dd511f3bbc01e4152e9db13b69b3ba384

2023-02-15  Tom Tromey  <tom@tromey.com>

	Remove RETURNS from BFD chew comments
	When reading the BFD manual, I noticed text like this:

	     -- Function: bool bfd_close (bfd *abfd);
		 Close a BFD. If the BFD was open for writing, then pending
		 operations are completed and the file written out and closed.  If
	    ...
	       *Returns*
	    'TRUE' is returned if all is ok, otherwise 'FALSE'.

	The *Returns*, like the *Synopsis* in the earlier patch, is
	un-info-like.  It's also used inconsistently.

	This patch removes all the uses of the RETURNS word and removes it
	entirely from the chew scripts.  Now this example reads:

	     -- Function: bool bfd_close (bfd *abfd);
		 Close a BFD. If the BFD was open for writing, then pending
		 operations are completed and the file written out and closed.  If
	    ...
		 'TRUE' is returned if all is ok, otherwise 'FALSE'.

	In a few cases I had to slightly reword the comment.  There were also
	a couple of cases where there was redundant text.  In these cases I
	just dropped the RETURNS copy.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* bfd.c, cache.c, compress.c, opncls.c: Remove RETURNS from
		documentation comments.
		* doc/doc.str, doc/proto.str (RETURNS): Remove.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Use @deftypefn in chew output
	When reading the BFD info manual, function definitions looked very
	strange to me:

	    *Synopsis*
		 long bfd_get_mtime (bfd *abfd);
	       *Description*
	    Return the file modification time (as read from the file system, or from
	    the archive header for archive members).

	The *Synopsis* and *Description* text in particular is very un-info-like.

	To fix this, I tried removing the *Synopsis* text and having FUNCTION
	use @deftypefn instead.  However, this ended up requiring some new
	state, because SYNOPSIS can appear without FUNCTION.  This in turn
	required "catstrif" (I considered adding FORTH-style if-else-then, but
	in the end decided on an ad hoc approach).

	After this the result looks like:

	 -- Function: long bfd_get_mtime (bfd *abfd);
	     Return the file modification time (as read from the file system, or
	     from the archive header for archive members).

	This patch also reorders a few documentation comments to ensure that
	SYNOPSIS comes before DESCRIPTION.  This is the more common style and
	is also now required by doc.str.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* syms.c (bfd_decode_symclass, bfd_is_undefined_symclass)
		(bfd_symbol_info): Reorder documentation comment.
		* doc/doc.str (synopsis_seen): New variable.
		(SYNOPSIS): Set synopsis_seen.  Emit @deftypefn.
		(DESCRIPTION): Use synopsis_seen.
		* doc/chew.c (catstrif): New function.
		(main): Add catstrif intrinsic.
		(compile): Recognize "variable" command.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Change internalmode to be an intrinsic variable
	Currently, internalmode is a special word to set an internal state
	variable.  Because this series adds variables anyway, change this to
	be a variable instead.

	I saw some commits in the history that made sure that chew did not
	leak memory, so I put some extra effort into trying to handle this for
	variables as well.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* doc/proto.str (external, internal, ifinternal, ENUMEQ, ENUMDOC):
		Update.
		* doc/chew.c (internalmode): Remove.
		(add_intrinsic_variable): New function.
		(main): Add internalmode as intrinsic.
		(internal_mode): Remove global.
		(maybecatstr): Update.
		(free_words): Free variables.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Use intptr_t rather than long in chew
	To implement variables in chew, it's convenient to have a
	pointer-sized integer on the stack.  To this end, use intptr_t rather
	than long.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* doc/chew.c (pcu) <l>: Now intptr_t.
		(internal_mode, istack, isp): Likewise.
		(bang, atsign): Use intptr_t.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Remove the paramstuff word
	The chew "paramstuff" word has been a no-op since:

	    commit c58b95236ce4c9345c4fa76e7ef16762e5229380
	    Author: Alan Modra <amodra@gmail.com>
	    Date:   Sun Jun 29 10:06:40 2003 +0000

		Convert to C90 and a few tweaks.

	Remove it and its one use.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* doc/proto.str (SYNOPSIS): Don't use paramstuff.
		* doc/chew.c (paramstuff): Remove.
		(main): Don't add paramstuff intrinsic.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Add copyright headers to the .str files
	The .str script files don't have copyright headers, but I think they
	should.  I used the same dates that chew.c uses, which I think makes
	sense because these are inputs to chew.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* doc/doc.str, doc/proto.str: Add copyright header.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Simplify @node use in BFD documentation
	The BFD docs currently specify all the parameters to @node.  However,
	this results in bad navigation in certain nodes -- the "space" command
	in info doesn't know how to find the next node.

	I think this style of @node is a leftover from ancient times.
	Makeinfo can figure out the node structure on its own now, so simplify
	everything to a single-argument @node.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* doc/webassembly.texi (File layout): Remove second argument from
		@node.
		* doc/bfd.texi: Use single-argument @node everywhere.

2023-02-15  Tom Tromey  <tom@tromey.com>

	Remove H_CFLAGS from doc/local.mk
	I couldn't see that H_CFLAGS is defined anywhere, so remove it.

	2023-02-07  Tom Tromey  <tom@tromey.com>

		* Makefile.in: Rebuild.
		* doc/local.mk (%D%/chew.stamp): Don't use H_CFLAGS.

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: store internalvars in an std::map
	In a test downstream in ROCgdb, we had a test case failing when
	GDB_REVERSE_INIT_FUNCTIONS was set.  The test was assuming a particular
	order in the output of "show convenience".  And the order changes when
	running with GDB_REVERSE_INIT_FUNCTIONS.

	I think that a nice way to fix it is to make the output of "show
	convenience" sorted, and therefore stable.  Ideally, I think that the
	the user-visible behavior of GDB should not change when using
	GDB_REVERSE_INIT_FUNCTIONS.  Plus, it makes the output of "show
	convenience" look nice, not that it's really important.

	Implement this by storing the internal vars in an std::map, which is a
	sorted container.

	Change-Id: I1fca7e7877cc984a3a3432c7639d45e68d437241
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add constructor to internalvar
	Add a constructor that takes the name as a parameter.  Initialize the
	next and kind fields inline.

	Change-Id: Ic4db0aba85f1da9f12f3eee0ac62c0e5ef0cfe88
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Simon Marchi  <simon.marchi@efficios.com>

	gdb: use std::string for internalvar::name
	Change internalvar::name to std::string, automating memory management.
	It becomes necessary to allocate internalvar with new instead of XNEW.

	I didn't find how to trigger the code in complete_internalvar.  It is
	called from condition_completer, so it should be by using the
	"condition" command, but I never managed to get in the right code path.

	Change-Id: I814d61361663e7becb8f3fb5f58c0180cdc414bc
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Tom Tromey  <tromey@adacore.com>

	Do not record a rejected target description
	When connecting to a certain target, gdb issues a warning about the
	target description:

	    (gdb) target remote localhost:7947
	    Remote debugging using localhost:7947
	    warning: Architecture rejected target-supplied description

	If you then kill the inferior and change the exec-file, this will
	happen:

	    (gdb) file bar
	    Architecture of file not recognized.

	After this, debugging doesn't work very well.

	What happens here is that, despite the warning,
	target_find_description records the downloaded description in the
	target_desc_info.  Then the "file" command ends up calling
	set_gdbarch_from_file, which uses that description.

	It seems to me that, because the architecture rejected the
	description, it should not be used.  That is what this patch
	implements.

2023-02-15  Pedro Alves  <pedro@palves.net>

	gdb/manual: Move @findex entries
	The manual currently has many cases like these:

	 @item $_gdb_setting_str (@var{setting})
	 @findex $_gdb_setting_str@r{, convenience function}

	As suggested by Eli, move the @findex entries before @item so that the
	index records the position of @item, and the Info reader places you
	there when you use index-search.

	I went over all @findex calls in the manual, and most are like the
	above.  Most either appear before @item, or before @subheading, like:

	 @subheading The @code{-break-after} Command
	 @findex -break-after

	I fixed all of them.

	There are findex entries in annotate.texinfo,python.texi, and
	stabs.texinfo as well, though those all look right to me already.

	Tested by typing "i _isvoid" (@item case) and "i -complete"
	(@subheading case) in an Info reader, and checking where those took
	me.

	Change-Id: Idb6903b0bb39ff03f93524628dcef86b5585c97e
	Suggested-By: Eli Zaretskii <eliz@gnu.org>

2023-02-15  Alan Modra  <amodra@gmail.com>

	objdump read_section_stabs
	This function is used to read sections other than stabs, and there is
	now another version of it that extracts different info from the bfd
	section.  Rename it and return the bfd section instead of assorted
	fields of the bfd section.

		* objcopy.c (read_section): Renamed from read_section_stabs.
		Delete size_ptr and entsize_ptr params, add contents param.
		Return asection pointer.  Don't unnecessarily free contents on
		failure from bfd_malloc_and_get_section.
		(find_stabs_section): Use read_section.
		(dump_ctf, dump_section_sframe): Likewise.
		(read_section_sframe): Delete.

2023-02-15  Alan Modra  <amodra@gmail.com>

	objdump -G memory leak
		* objdump.c (find_stabs_section): Free stabs.

2023-02-15  Nick Clifton  <nickc@redhat.com>

	Fix the linker's merge4 test for the HPPA architecture.
	 PR 30078 * testsuite/ld-elf/merge4b.s: Use .asciz instead of .string in order to avoid the special behaviour of the .string directive on HPPA architectures.

2023-02-15  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb, fortran: Fix quad floating-point type for ifort compiler.
	I fixed this a while ago for ifx, one of the two Intel compilers, in
	8d624a9d8050ca96e154215c7858ac5c2d8b0b19.

	Apparently I missed that the older ifort Intel compiler actually emits
	slightly different debug info again:

	0x0000007a:   DW_TAG_base_type
	                DW_AT_byte_size	(0x20)
	                DW_AT_encoding	(DW_ATE_complex_float)
	                DW_AT_name	("COMPLEX(16)")

	0x00000081:   DW_TAG_base_type
	                DW_AT_byte_size	(0x10)
	                DW_AT_encoding	(DW_ATE_float)
	                DW_AT_name	("REAL(16)")

	This fixes two failures in gdb.fortran/complex.exp with ifort.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-15  Jan Beulich  <jbeulich@suse.com>

	gas: buffer_and_nest() needs to pass nul-terminated string to temp_ilp()
	In 7545aa2dd2eb ("gas: improve interaction between read_a_source_file()
	and s_linefile()") I didn't pay attention to the dual purpose of the
	nul character previously used. This was to a fair degree because of the
	open-coding of certain operations. Insert the earlier found line
	terminator instead of a hard-coded newline, and do so early in this
	special case (bypassing the later general insertion point). Plus
	properly use sb_terminate() to mark the end of the string. (Note that
	saved_eol_char was misnamed: Without calling sb_terminate() there's
	simply random data at that position in the buffer.)

2023-02-15  Alan Modra  <amodra@gmail.com>

	More ecoff sanity checks
	Change FIX so that unused pointers that escape the UPDATE_RAW_END
	sanity checks won't result in overflows.  Also sanity check the local
	sym fdr isymBase and csym values.

		* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Define FIX to set
		pointers into swapped internal data to NULL if count is zero.
		Sanity check local sym fdr_ptr->isymBase and fdr_ptr->csym.

2023-02-15  Alan Modra  <amodra@gmail.com>

	binutils stabs type list
	Fuzzers have found that specifying a large stab type number results in
	lots of memory being requested, as the list is extended with a 16
	element array at a time until we reach the given stab type.  It also
	takes a long time.  Of course normal sane stab types use small
	positive integers, but it's not hard to modify the code to handle type
	numbers starting anyhere.

		* stabs.c (struct stab_types): Add base_index.
		(stab_find_slot): Simplify filenum check.  Delete type number
		check.  Don't allocate entire array from 0 to type number,
		allocate a sparse array.

2023-02-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-14  Tom Tromey  <tom@tromey.com>

	Remove a use of pagination_enabled
	I noticed that the TUI temporarily sets pagination_enabled and
	gdb_stdout in one spot.  However, I don't believe these settings are
	necessary here, as a ui_file is passed to
	gdbarch_print_registers_info.  This patch removes these settings.

2023-02-14  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf2: rename some things, index -> gdb_index
	This renaming helps make it clearer that these entites (classes,
	functions) are specific to .gdb_index only, they are not shared with the
	.debug_names handling.

	Change-Id: I1a3cf3dbf450b62d1a0879d9aedd26397abdfd13
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: cast return value of std::unique_ptr::release to void
	My editor shows warnings like:

	     value.c:2784: warning: The value returned by this function should be used
	     value.c:2784: note: cast the expression to void to silence this warning [bugprone-unused-return-value]

	These warnings come from clangd, so ultimately from one of the clang
	static analyzers (probably clang-tidy).

	Silence these warnings by casting to void.  Add a comment to explain
	why this unusual thing is done.

	Change-Id: I58323959c0baf9f1b20a8d596e4c58dc77c6809a
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-14  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove unnecessary tui directory check in configure
	I suppose this was possible in the CVS days for the tui directory to be
	missing, but it's not really possible nowaday.  Well, a user could
	delete the directory from their source tree but... it doesn't make
	sense.  Remove the check for that directory in configure.

	Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-14  Tom Tromey  <tromey@adacore.com>

	Do not cast away const in agent_run_command
	While investigating something else, I noticed some weird code in
	agent_run_command (use of memcpy rather than strcpy).  Then I noticed
	that 'cmd' is used as both an in and out parameter, despite being
	const.

	Casting away const like this is bad.  This patch removes the const and
	fixes the memcpy.  I also added a static assert to assure myself that
	the code in gdbserver is correct -- gdbserver is passing its own
	buffer directly to agent_run_command.

	Reviewed-By: Andrew Burgess <aburgess@redhat.com>

2023-02-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp
	There's a HW bug affecting Processor Trace on some Intel processors
	(Ice Lake to Raptor Lake microarchitectures).

	The bug was exposed by linux kernel commit 670638477aed
	("perf/x86/intel/pt: Opportunistically use single range output mode"),
	added in version v5.5.0, and was worked around by commit ce0d998be927
	("perf/x86/intel/pt: Fix sampling using single range output") in version
	6.1.0.

	The bug manifests (on a Performance-core of an i7-1250U, an Alder Lake cpu) in
	a single test-case:
	...
	(gdb) python insn = r.instruction_history^M
	warning: Decode error (-20) at instruction 33 (offset = 0x3d6a, \
	  pc = 0x400501): compressed return without call.^M
	(gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: \
	  python insn = r.instruction_history
	...

	Add a corresponding XFAIL.

	Note that the i7-1250U has both Performance-cores and Efficient-cores, and on
	an Efficient-Core the test-case runs without any problems, so if the testsuite
	run is not pinned to a specific cpu, the test may either PASS or XFAIL.

	Tested on x86_64-linux:
	- openSUSE Leap 15.4 with linux kernel version 5.14.21
	- openSUSE Tumbleweed with linux kernel version 6.1.8

	PR testsuite/30075
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30075

2023-02-14  Nick Clifton  <nickc@redhat.com>

	 Mention that the -plugin command line option is used to load plugins.

2023-02-14  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Factor out proc linux_kernel_version
	Factor out new proc linux_kernel_version from test-case
	gdb.arch/i386-pkru.exp.

	Tested on x86_64-linux.

2023-02-14  Ulf Samuelsson  <ulf@emagii.com>

	ASCIZ Command for output section
	Adds a new directive to the linker script syntax: ASCIZ.
	This inserts a zero-terminated string into the output at the place where it is used.

2023-02-14  Jan Beulich  <jbeulich@suse.com>

	gas: correct symbol name comparison in .startof./.sizeof. handling
	In 162c6aef1f3a ("gas: fold symbol table entries generated for
	.startof.() / .sizeof.()") I screwed up quite badly, inverting the case
	sensitive and case insensitive comparison functions.

	x86: {LD,ST}TILECFG use an extension opcode
	It being zero and happening to work right now doesn't mean the insns
	shouldn't be spelled out properly.

2023-02-14  Jan Beulich  <jbeulich@suse.com>

	gas: improve interaction between read_a_source_file() and s_linefile()
	read_a_source_file() would bump line numbers only when seeing a newline,
	whereas is_end_of_line[] indicates further end-of-line characters, in
	particular the nul character. s_linefile() attempts to compensate for
	the bump, but was too aggressive with this so far: It should only adjust
	when a newline ends the line. To facilitate such a check, the check for
	nothing else on the line needs to move ahead, which luckily is easily
	possible: The relevant two conditions match, and the function can
	simply return from the body of that earlier instance of the conditional.

	The more strict treatment in s_linefile() then requires an adjustment
	to buffer_and_nest()'s invocation of the function: The line terminator
	now needs to be a newline, not nul.

2023-02-14  Tom Tromey  <tom@tromey.com>

	Fix build bug in ppc-linux-nat.c
	The buildbot pointed out that my value refactoring series introduced a
	bug in ppc-linux-nat.c:

	../../binutils-gdb/gdb/ppc-linux-nat.c: In member function ‘int ppc_linux_nat_target::num_memory_accesses(const std::vector<gdb::ref_ptr<value, value_ref_policy> >&)’:
	../../binutils-gdb/gdb/ppc-linux-nat.c:2458:44: error: expected unqualified-id before ‘->’ token
	 2458 |       if (VALUE_LVAL (v) == not_lval || v->->deprecated_modifiable () == 0)

	I don't know how that happened, but I am checking in this patch which
	I think should fix it.  It just removes the second "->".

	I can't readily test this, so perhaps there's another bug lurking
	after this one.

2023-02-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-13  Tom Tromey  <tom@tromey.com>

	Rely on value_ref_ptr::operator->
	Simon pointed out some spots were doing val.get()->mumble, where val
	is a value_ref_ptr.  These were introduced by the function-to-method
	script, replacing older code that passed the result of .get() to a
	function.

	Now that value.h is using methods, we can instead rely on operator->.
	This patch replaces all the newly-introduced instances of this.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Remove deprecated_lval_hack
	This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
	all uses with a call to value::lval.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Introduce set_lval method on value
	This introduces the set_lval method on value, one step toward removing
	deprecated_lval_hack.  Ultimately I think the goal should be for some
	of these set_* methods to be replaced with constructors; but I haven't
	done this, as the series is already too long.  Other 'deprecated'
	methods can probably be handled the same way.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Make ~value private
	At the end of this series, I belatedly realized that values should
	only be destroyed by value_decref.  This patch marks the the
	destructor private to enforce this.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Make struct value data members private
	This hoists the 'private' in struct value to also encompass the data
	members.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn record_latest_value into a method
	record_latest_value now access some internals of struct value, so turn
	it into a method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Add value::set_modifiable
	This introduces a value::set_modifiable and changes a couple of spots
	to use it.

	I'm not completely sure the comments by deprecated_modifiable are
	correct any more.  Perhaps they should be removed and the method
	renamed.  Like so many before me, though, I've deferred investigation
	of the issue.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn various value copying-related functions into methods
	This patch turns a grab bag of value functions to methods of value.
	These are done together because their implementations are
	interrelated.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn preserve_one_value into method
	This changes preserve_one_value to be a method of value.  Much of this
	patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn some xmethod functions into methods
	This turns value_from_xmethod, result_type_of_xmethod, and
	call_xmethod to be methods of value.  value_from_xmethod is a static
	"constructor" now.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Change some code to use value methods
	A few functions in value.c were accessing the internal fields of
	struct value.  However, in these cases it seemed simpler to change
	them to use the public API rather than convert them to be methods.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn set_value_component_location into method
	This turns set_value_component_location into a method of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_non_lval and value_force_lval into methods
	This changes value_non_lval and value_force_lval to be methods of
	value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn many optimized-out value functions into methods
	This turns many functions that are related to optimized-out or
	availability-checking to be methods of value.  The static function
	value_entirely_covered_by_range_vector is also converted to be a
	private method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_copy into a method
	This turns value_copy into a method of value.  Much of this was
	written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Fully qualify calls to copy in value.c
	A coming patch will add value::copy, so this namespace-qualifies
	existing calls to 'copy' in value.c, to ensure it will still compile
	after that change is done.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn remaining value_contents functions into methods
	This turns the remaining value_contents functions -- value_contents,
	value_contents_all, value_contents_for_printing, and
	value_contents_for_printing_const -- into methods of value.  It also
	converts the static functions require_not_optimized_out and
	require_available to be private methods.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_incref and value_decref into methods
	This changes value_incref and value_decref to be methods of value.
	Much of this patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Move value_ref_policy methods out-of-line
	This moves the value_ref_policy methods to be defined out-of-line.
	This is a necessary step to change value_incref and value_decref to be
	methods of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_bits_synthetic_pointer into a method
	This changes value_bits_synthetic_pointer to be a method of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_contents_eq into a method
	This changes value_contents_eq to be a method of value.  It also
	converts the static function value_contents_bits_eq into a private
	method.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn allocate_value_contents into a method
	This turns the static function allocate_value_contents into a method
	on value.  It is temporarily public, until some users are converted.
	set_limited_array_length is converted as well.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_fetch_lazy into a method
	This changes value_fetch_lazy to be a method of value.  A few helper
	functions are converted as well, to avoid problems in later patches
	when the data members are all made private.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn some value_contents functions into methods
	This turns value_contents_raw, value_contents_writeable, and
	value_contents_all_raw into methods on value.  The remaining functions
	will be changed later in the series; they were a bit trickier and so I
	didn't include them in this patch.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_zero into static "constructor"
	This turns value_zero into a static "constructor" of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn allocate_optimized_out_value into static "constructor"
	This turns allocate_optimized_out_value into a static "constructor" of
	value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn allocate_computed_value into static "constructor"
	This turns allocate_computed_value into a static "constructor" of
	value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn allocate_value into a static "constructor"
	This changes allocate_value to be a static "constructor" of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn allocate_value_lazy into a static "constructor"
	This changes allocate_value_lazy to be a static "constructor" of
	struct value.

	I considered trying to change value to use ordinary new/delete, but it
	seems to me that due to reference counting, we may someday want to
	change these static constructors to return value_ref_ptr instead.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn more deprecated_* functions into methods
	This changes deprecated_value_internalvar_hack,
	deprecated_value_internalvar_hack, and deprecated_value_regnum_hack
	into methods on value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_address and set_value_address functions into methods
	This changes the value_address and set_value_address functions to be
	methods of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_initialized and set_value_initialized functions into methods
	This changes the value_initialized and set_value_initialized functions
	to be methods of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Convert value_lval_const and deprecated_lval_hack to methods
	This converts the value_lval_const and deprecated_lval_hack functions
	to be methods on value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_computed_closure and value_computed_funcs functions into methods
	This changes the value_computed_funcs and value_computed_closure
	functions to be methods of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_stack and set_value_stack functions into methods
	This changes the value_stack and set_value_stack functions to be
	methods of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_lazy and set_value_lazy functions into methods
	This changes the value_lazy and set_value_lazy functions to be methods
	of value.  Much of this patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn some value offset functions into method
	This changes various offset-related functions to be methods of value.
	Much of this patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_enclosing_type into method
	This changes value_enclosing_type to be a method of value.  Much of
	this patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn deprecated_value_modifiable into method
	This changes deprecated_value_modifiable to be a method of value.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_offset into method
	This changes value_offset to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_parent into method
	This changes value_parent to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_bitpos into method
	This changes value_bitpos to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_bitsize into method
	This changes value_bitsize to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_arch into method
	This changes value_arch to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn deprecated_set_value_type into a method
	This changes deprecated_set_value_type to be a method of value.  Much
	of this patch was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Turn value_type into method
	This changes value_type to be a method of value.  Much of this patch
	was written by script.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Move struct value to value.h
	This moves struct value to value.h.  For now, all members remain
	public, but this is a temporary state -- by the end of the series
	we'll add 'private'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Move ~value body out-of-line
	struct value is going to move to value.h, but to avoid having
	excessive code there, first move the destructor body out-of-line.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Tom Tromey  <tom@tromey.com>

	Rename all fields of struct value
	This renames all the fields of struct value, in preparation for the
	coming changes.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Michael Matz  <matz@suse.de>

	PR30120: fix x87 fucomp misassembled
	this fixes the entry for 'fucomp' to use the correct Reg value
	(otherwise it's assembled as 'fucom').

2023-02-13  Tom Tromey  <tromey@adacore.com>

	Remove unused imports from gdb's Python code
	The "sys" import is unused in several Python files.  This removes this
	line from all the places where it is unnecessary.

2023-02-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: don't leak the known_window_types map
	This commit finishes the task that was started in the previous
	commit.

	Now that all Python TUI window factories are correctly deleted when
	the Python interpreter is shut down, we no longer need to dynamically
	allocate the known_window_types map in tui-layout.c

	This commit changes known_window_types to a statically allocated data
	structure, removes the dynamic allocation from
	initialize_known_windows, and then replaces lots of '->' with '.'
	throughout this file.

	There should be no user visible changes after this commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: deallocate tui window factories at Python shut down
	The previous commit relied on spotting when a Python defined TUI
	window factory was deleted.  I spotted that the window factories are
	not deleted when GDB shuts down its Python environment, they are only
	deleted when one window factory replaces another.  Consider this
	example Python script:

	  class TestWindowFactory:
	      def __init__(self, msg):
	          self.msg = msg
	          print("Entering TestWindowFactory.__init__: %s" % self.msg)

	      def __call__(self, tui_win):
	          print("Entering TestWindowFactory.__call__: %s" % self.msg)
	          return TestWindow(tui_win, self.msg)

	      def __del__(self):
	          print("Entering TestWindowFactory.__del__: %s" % self.msg)

	  gdb.register_window_type("test_window", TestWindowFactory("A"))
	  gdb.register_window_type("test_window", TestWindowFactory("B"))

	And this GDB session:

	  (gdb) source tui.py
	  Entering TestWindowFactory.__init__: A
	  Entering TestWindowFactory.__init__: B
	  Entering TestWindowFactory.__del__: B
	  (gdb) quit

	Notice that when the 'B' window replaces the 'A' window we see the 'A'
	object being deleted.  But, when Python is shut down (after the
	'quit') the 'B' object is never deleted.

	Instead, GDB retains a reference to the window factory object, which
	forces the Python object to remain live even after the Python
	interpreter itself has been shut down.

	The references themselves are held in a dynamically allocated
	std::unordered_map (in tui/tui-layout.c) which is never deallocated,
	thus the underlying Python references are never decremented to zero,
	and so GDB never tries to delete these Python objects.

	This commit is the first half of the work to clean up this edge case.

	All gdbpy_tui_window_maker objects (the objects that implement the
	TUI window factory callback for Python defined TUI windows), are now
	linked together into a global list using the intrusive list mechanism.

	When GDB shuts down the Python interpreter we can now walk this global
	list and release the reference that is held to the underlying Python
	object.  By releasing this reference the Python object will now be
	deleted.

	I've added a new assert in gdbpy_tui_window_maker::operator(), this
	will catch the case where we somehow end up in here after having
	reset the reference to the underlying Python object.  I don't think
	this should ever happen though as we only clear the references when
	shutting down the Python interpreter, and the ::operator() function is
	only called when trying to apply a new TUI layout - something that
	shouldn't happen while GDB itself is shutting down.

	This commit does not update the std::unordered_map in tui-layout.c,
	that will be done in the next commit.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/python: allow Python TUI windows to be replaced
	The documentation for gdb.register_window_type says:

	  "...  It's an error to try to replace one of the built-in windows,
	  but other window types can be replaced. ..."

	I take this to mean that if I imported a Python script like this:

	  gdb.register_window_type('my_window', FactoryFunction)

	Then GDB would have a new TUI window 'my_window', which could be
	created by calling FactoryFunction().  If I then, in the same GDB
	session imported a script which included:

	  gdb.register_window_type('my_window', UpdatedFactoryFunction)

	Then GDB would replace the old 'my_window' factory with my new one,
	GDB would now call UpdatedFactoryFunction().

	This is pretty useful in practice, as it allows users to iterate on
	their window implementation within a single GDB session.

	However, right now, this is not how GDB operates.  The second call to
	register_window_type is basically ignored and the old window factory
	is retained.

	This is because in tui_register_window (tui/tui-layout.c) we use
	std::unordered_map::emplace to insert the new factory function, and
	emplace doesn't replace an existing element in an unordered_map.

	In this commit, before the emplace call, I now search for an already
	existing element, and delete any matching element from the map, the
	emplace call will then add the new factory function.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-13  Keith Seitz  <keiths@redhat.com>

	Fix doc build dependencies for --with-system-readline
	PR build/30108 concerns building gdb documentation with
	--with-sytem-readline.  If the in-tree readline directory is
	missing, though, the docs will fail to build:

	make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc'
	make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'.  Stop.

	The listed file (and hsuser.texi) are conditionally included by gdb.texinfo.
	When system readline is used, gdb/configure.ac will leave
	READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to
	$BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE".  This surpresses the
	inclusion of the missing files. They are not needed or used in this
	scenario.

	However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies,
	thus provoking the build error whenever readline/ is missing.

	This patch fixes this by creating (essentially) a conditional setting of the
	dependencies to be included from readline.

2023-02-13  Michael Matz  <matz@suse.de>

	Fix PR30079: abort on mingw
	the early-out in wild_sort is not enough, it might still be
	that filenames are equal _and_ the wildcard list doesn't specify
	a sort order either.  Don't call compare_section then.

	Tested on all targets.

2023-02-13  Alan Modra  <amodra@gmail.com>

	_bfd_ecoff_slurp_symbol_table buffer overflow
	Add missing bounds check, and tidy the existing bounds checking.

		* ecoff.c (_bfd_ecoff_slurp_symbol_table): Break overlong lines.
		Set bfd_error.  Bounds check internal_sym.iss.

2023-02-13  Andrew Burgess  <aburgess@redhat.com>

	opcodes/mips: disassemble unknown micromips instructions as two shorts
	Before commit:

	  commit 2438b771ee07be19d5b01ea55e077dd8b7cef445
	  Date:   Wed Nov 2 15:53:43 2022 +0000

	      opcodes/mips: use .word/.short for undefined instructions

	unknown 32-bit microMIPS instructions were disassembled as a raw
	32-bit number with no '.word' directive.  The above commit changed
	this and added a '.word' directive before the 32-bit number.

	It was pointed out on the mailing list, that for microMIPS it would be
	better to display such 32-bit instructions using a '.short' directive
	followed by two 16-bit values.

	This commit updates the mips disassembler to do this, and adds a new
	test that validates this output.

2023-02-13  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: handle differences in guile error string output
	A new guile test added in commit:

	  commit 0a9ccb9dd79384f3ba3f8cd75940e8868f3b526f
	  Date:   Mon Feb 6 13:04:16 2023 +0000

	      gdb: only allow one of thread or task on breakpoints or watchpoints

	fails for some versions of guile.  It turns out that some versions of
	guile emit an error like this:

	  (gdb) guile (set-breakpoint-thread! bp 1)
	  ERROR: In procedure set-breakpoint-thread!:
	  In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
	  Error while executing Scheme code.

	while other versions of guile emit the error like this:

	  (gdb) guile (set-breakpoint-thread! bp 1)
	  ERROR: In procedure set-breakpoint-thread!:
	  ERROR: In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
	  Error while executing Scheme code.

	notice the extra 'ERROR: ' on the second line of output.  This commit
	updates the test regexp to handle this optional 'ERROR: ' string.

2023-02-13  Alan Modra  <amodra@gmail.com>

	stabs.c static state
	Move all the function local static state variables to file scope,
	in order to tidy memory on exit and to reinit everything for that
	annoying oss-fuzz.  Also fix a couple memory leaks.

		* read.h (read_begin, read_end): Declare.
		* read.c (read_begin): Call stabs_begin.
		(read_end): Call stabs_end.
		* stabs.c (stabs_begin, stabs_end): New functions.
		(in_dot_func_p): Delete, use current_function_label instead.
		(cached_sec): Move from s_stab_generic.
		(last_asm_file, file_label_count): Move from generate_asm_file.
		(line_label_count, prev_lineno, prev_line_file): Move from
		stabs_generate_asm_lineno.
		(void_emitted_p): Move from stabs_generate_asm_func.
		(endfunc_label_count): Move from stabs_generate_asm_endfunc.
		(stabs_generate_asm_lineno): Simplify setting of
		prev_line_file.
		(stabs_generate_asm_func): Don't leak current_function_label.
		(stabs_generate_asm_endfunc): Likewise.

2023-02-13  Alan Modra  <amodra@gmail.com>

	Split off gas init to functions
	With some slight reordering.

		* as.c (gas_early_init, gas_late_init): New functions, split..
		(main): ..from here.

2023-02-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: look for hipcc in env(ROCM_PATH)
	If the hipcc compiler cannot be found in dejagnu's tool_root_dir, look
	for it in $::env(ROCM_PATH) (if set).  If hipcc is still not found,
	fallback to "hipcc" so the compiler will be searched in the PATH.  This
	removes the fallback to the hard-coded "/opt/rocm/bin" prefix.

	This change is done so ROCM tools are searched in a uniform manner.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: allow_hipcc_tests tests the hipcc compiler
	Update allow_hipcc_tests so all gdb.rocm tests are skipped if we do not
	have a working hipcc compiler available.

	To achieve this, adjust gdb_simple_compile to ensure that the hip
	program is saved in a ".cpp" file before calling hipcc otherwise
	compilation will fail.

	One thing to note is that it is possible to have a hipcc installed with
	a CUDA backend.  Compiling with this back-end will successfully result
	in an application, but GDB cannot debug it (at least for the offload
	part). In the context of the gdb.rocm tests, we want to detect such
	situation where gdb_simple_compile would give a false positive.

	To achieve this, this patch checks that there is at least one AMDGPU
	device available and that hipcc can compile for this or those targets.
	Detecting the device is done using the rocm_agent_enumerator tool which
	is installed with the all ROCm installations (it is used by hipcc to
	detect identify targets if this is not specified on the comand line).

	This patch also makes the allow_hipcc_tests proc a cached proc.

	Co-Authored-By: Pedro Alves <pedro@palves.net>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: require amd-dbgapi support to run rocm tests
	Update allow_hipcc_tests to check that GDB has the amd-dbgapi support
	built-in.  Without this support, all tests using hipcc and the rocm
	stack will fail.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb/testsuite: Rename skip_hipcc_tests to allow_hipcc_tests
	Rename skip_hipcc_tests to allow_hipcc_tests so it can be used as a
	"require" predicate in tests.

	Use require in gdb.rocm/simple.exp.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Lancelot SIX  <lancelot.six@amd.com>

	gdb: 'show config' shows --with[out]-amd-dbgapi
	Ensure that the "show configuration" command and the "--configuration"
	command line switch shows if GDB was built with the AMDGPU support or
	not.

	This will be used in a later patch in this series.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-13  Alan Modra  <amodra@gmail.com>

	objcopy memory leaks
	This fixes some objcopy memory leaks.  commit 450da4bd38ae used
	xatexit to tidy most of the hash table memory, but of course that's
	ineffective without a call to xexit.  The other major memory leak
	happens if there is an error of some sort writing the output file, due
	to not closing the input file and thus not freeing memory attached to
	the bfd.

		* objcopy.c (copy_file): Don't return when bfd_close of output
		gives an error, always bfd_close input too.
		(main): Call xexit.

2023-02-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-12  Tom Tromey  <tom@tromey.com>

	Move some code from dwarf2/read.c to die.c
	This patch introduces a new file, dwarf2/die.c, and moves some
	DIE-related code out of dwarf2/read.c and into this new file.  This is
	just a small part of the long-term project to split up read.c.
	(According to 'wc', dwarf2/read.c is the largest file in gdb by around
	8000 LOC.)

	Regression tested on x86-64 Fedora 36.

2023-02-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix describe_other_breakpoints for default task being -1
	Commit:

	  commit 2ecee236752932672fb3d6cd63c6976927f747d8
	  CommitDate: Sun Feb 12 05:46:44 2023 +0000

	      gdb: use -1 for breakpoint::task default value

	Failed to take account of an earlier commit:

	  commit f1f517e81039f6aa673b7d87a66bfbd25a66e3d3
	  CommitDate: Sat Feb 11 17:36:24 2023 +0000

	      gdb: show task number in describe_other_breakpoints

	That both of these are my own commits is only more embarrassing.

	This small fix updates describe_other_breakpoints to take account of
	the default task number now being -1.  This fixes regressions in
	gdb.base/break.exp, gdb.base/break-always.exp, and many other tests.

2023-02-12  Andrew Burgess  <aburgess@redhat.com>

	gdb/c++: fix handling of breakpoints on @plt symbols
	This commit should fix PR gdb/20091, PR gdb/17201, and PR gdb/17071.
	Additionally, PR gdb/17199 relates to this area of code, but is more
	of a request to refactor some parts of GDB, this commit does not
	address that request, but it is probably worth reading that PR when
	looking at this commit.

	When the current language is C++, and the user places a breakpoint on
	a function in a shared library, GDB will currently find two locations
	for the breakpoint, one location will be within the function itself as
	we would expect, but the other location will be within the PLT table
	for the call to the named function.  Consider this session:

	  $ gdb -q /tmp/breakpoint-shlib-func
	  Reading symbols from /tmp/breakpoint-shlib-func...
	  (gdb) start
	  Temporary breakpoint 1 at 0x40112e: file /tmp/breakpoint-shlib-func.cc, line 20.
	  Starting program: /tmp/breakpoint-shlib-func

	  Temporary breakpoint 1, main () at /tmp/breakpoint-shlib-func.cc:20
	  20	  int answer = foo ();
	  (gdb) break foo
	  Breakpoint 2 at 0x401030 (2 locations)
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   <MULTIPLE>
	  2.1                         y   0x0000000000401030 <foo()@plt>
	  2.2                         y   0x00007ffff7fc50fd in foo() at /tmp/breakpoint-shlib-func-lib.cc:20

	This is not the expected behaviour.  If we compile the same test using
	a C compiler then we see this:

	  (gdb) break foo
	  Breakpoint 2 at 0x7ffff7fc50fd: file /tmp/breakpoint-shlib-func-c-lib.c, line 20.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   0x00007ffff7fc50fd in foo at /tmp/breakpoint-shlib-func-c-lib.c:20

	Here's what's happening.  When GDB parses the symbols in the main
	executable and the shared library we see a number of different symbols
	for foo, and use these to create entries in GDB's msymbol table:

	  - In the main executable we see a symbol 'foo@plt' that points at
	    the plt entry for foo, from this we add two entries into GDB's
	    msymbol table, one called 'foo@plt' which points at the plt entry
	    and has type mst_text, then we create a second symbol, this time
	    called 'foo' with type mst_solib_trampoline which also points at
	    the plt entry,

	  - Then, when the shared library is loaded we see another symbol
	    called 'foo', this one points at the actual implementation in the
	    shared library.  This time GDB creates a msymbol called 'foo' with
	    type mst_text that points at the implementation.

	This means that GDB creates 3 msymbols to represent the 2 symbols
	found in the executable and shared library.

	When the user creates a breakpoint on 'foo' GDB eventually ends up in
	search_minsyms_for_name (linespec.c), this function then calls
	iterate_over_minimal_symbols passing in the name we are looking for
	wrapped in a lookup_name_info object.

	In iterate_over_minimal_symbols we iterate over two hash tables (using
	the name we're looking for as the hash key), first we walk the hash
	table of symbol linkage names, then we walk the hash table of
	demangled symbol names.

	When the language is C++ the symbols for 'foo' will all have been
	mangled, as a result, in this case, the iteration of the linkage name
	hash table will find no matching results.

	However, when we walk the demangled hash table we do find some
	results.  In order to match symbol names, GDB obtains a symbol name
	matching function by calling the get_symbol_name_matcher method on the
	language_defn class.  For C++, in this case, the matching function we
	use is cp_fq_symbol_name_matches, which delegates the work to
	strncmp_iw_with_mode with mode strncmp_iw_mode::MATCH_PARAMS and
	language set to language_cplus.

	The strncmp_iw_mode::MATCH_PARAMS mode means that strncmp_iw_mode will
	skip any parameters in the demangled symbol name when checking for a
	match, e.g. 'foo' will match the demangled name 'foo()'.  The way this
	is done is that the strings are matched character by character, but,
	once the string we are looking for ('foo' here) is exhausted, if we
	are looking at '(' then we consider the match a success.

	Lets consider the 3 symbols GDB created.  If the function declaration
	is 'void foo ()' then from the main executable we added symbols
	'_Z3foov@plt' and '_Z3foov', while from the shared library we added
	another symbol call '_Z3foov'.  When these are demangled they become
	'foo()@plt', 'foo()', and 'foo()' respectively.

	Now, the '_Z3foov' symbol from the main executable has the type
	mst_solib_trampoline, and in search_minsyms_for_name, we search for
	any symbols of type mst_solib_trampoline and filter these out of the
	results.

	However, the '_Z3foov@plt' symbol (from the main executable), and the
	'_Z3foov' symbol (from the shared library) both have type mst_text.

	During the demangled name matching, due to the use of MATCH_PARAMS
	mode, we stop the comparison as soon as we hit a '(' in the demangled
	name.  And so, '_Z3foov@plt', which demangles to 'foo()@plt' matches
	'foo', and '_Z3foov', which demangles to 'foo()' also matches 'foo'.

	By contrast, for C, there are no demangled hash table entries to be
	iterated over (in iterate_over_minimal_symbols), we only consider the
	linkage name symbols which are 'foo@plt' and 'foo'.  The plain 'foo'
	symbol obviously matches when we are looking for 'foo', but in this
	case the 'foo@plt' will not match due to the '@plt' suffix.

	And so, when the user asks for a breakpoint in 'foo', and the language
	is C, search_minsyms_for_name, returns a single msymbol, the mst_text
	symbol for foo in the shared library, while, when the language is C++,
	we get two results, '_Z3foov' for the shared library function, and
	'_Z3foov@plt' for the plt entry in the main executable.

	I propose to fix this in strncmp_iw_with_mode.  When the mode is
	MATCH_PARAMS, instead of stopping at a '(' and assuming the match is a
	success, GDB will instead search forward for the matching, closing,
	')', effectively skipping the parameter list, and then resume
	matching.  Thus, when comparing 'foo' to 'foo()@plt' GDB will
	effectively compare against 'foo@plt' (skipping the parameter list),
	and the match will fail, just as it does when the language is C.

	There is one slight complication, which is revealed by the test
	gdb.linespec/cpcompletion.exp, when searching for the symbol of a
	const member function, the demangled symbol will have 'const' at the
	end of its name, e.g.:

	  struct_with_const_overload::const_overload_fn() const

	Previously, the matching would stop at the '(' character, but after my
	change the whole '()' is skipped, and the match resumes.  As a result,
	the 'const' modifier results in a failure to match, when previously
	GDB would have found a match.

	To work around this issue, in strncmp_iw_with_mode, when mode is
	MATCH_PARAMS, after skipping the parameter list, if the next character
	is '@' then we assume we are looking at something like '@plt' and
	return a value indicating the match failed, otherwise, we return a
	value indicating the match succeeded, this allows things like 'const'
	to be skipped.

	With these changes in place I now see GDB correctly setting a
	breakpoint only at the implementation of 'foo' in the shared library.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20091
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17201
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17071
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17199

	Tested-By: Bruno Larsen <blarsen@redhat.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: use -1 for breakpoint::task default value
	Within the breakpoint struct we have two fields ::thread and ::task
	which are used for thread or task specific breakpoints.  When a
	breakpoint doesn't have a specific thread or task then these fields
	have the values -1 and 0 respectively.

	There's no particular reason (as far as I can tell) why these two
	"default" values are different, and I find the difference a little
	confusing.  Long term I'd like to potentially fold these two fields
	into a single field, but that isn't what this commit does.

	What this commit does is switch to using -1 as the "default" value for
	both fields, this means that the default for breakpoint::task has
	changed from 0 to -1.   I've updated all the code I can find that
	relied on the value of 0, and I see no test regressions, especially in
	gdb.ada/tasks.exp, which still fully passes.

	There should be no user visible changes after this commit.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-12  Andrew Burgess  <aburgess@redhat.com>

	gdb: only allow one of thread or task on breakpoints or watchpoints
	After this mailing list posting:

	  https://sourceware.org/pipermail/gdb-patches/2023-February/196607.html

	it seems to me that in practice an Ada task maps 1:1 with a GDB
	thread, and so it doesn't really make sense to allow uses to give both
	a thread and a task within a single breakpoint or watchpoint
	condition.

	This commit updates GDB so that the user will get an error if both
	are specified.

	I've added new tests to cover the CLI as well as the Python and Guile
	APIs.  For the Python and Guile testing, as far as I can tell, this
	was the first testing for this corner of the APIs, so I ended up
	adding more than just a single test.

	For documentation I've added a NEWS entry, but I've not added anything
	to the docs themselves.  Currently we document the commands with a
	thread-id or task-id as distinct command, e.g.:

	  'break LOCSPEC task TASKNO'
	  'break LOCSPEC task TASKNO if ...'
	  'break LOCSPEC thread THREAD-ID'
	  'break LOCSPEC thread THREAD-ID if ...'

	As such, I don't believe there is any indication that combining 'task'
	and 'thread' would be expected to work; it seems clear to me in the
	above that those four options are all distinct commands.

	I think the NEWS entry is enough that if someone is combining these
	keywords (it's not clear what the expected behaviour would be in this
	case) then they can figure out that this was a deliberate change in
	GDB, but for a new user, the manual doesn't suggest combining them is
	OK, and any future attempt to combine them will give an error.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: show task number in describe_other_breakpoints
	I noticed that describe_other_breakpoints doesn't show the task
	number, but does show the thread-id.  I can't see any reason why we'd
	want to not show the task number in this situation, so this commit
	adds this missing information, and extends gdb.ada/tasks.exp to check
	this case.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: don't print global thread-id to CLI in describe_other_breakpoints
	I noticed that describe_other_breakpoints was printing the global
	thread-id to the CLI.  For CLI output we should be printing the
	inferior local thread-id (e.g. "2.1").  This can be seen in the
	following GDB session:

	  (gdb) info threads
	    Id   Target Id                                Frame
	    1.1  Thread 4065742.4065742 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27
	  * 2.1  Thread 4065743.4065743 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27
	  (gdb) break foo thread 2.1
	  Breakpoint 3 at 0x40110a: foo. (2 locations)
	  (gdb) break foo thread 1.1
	  Note: breakpoint 3 (thread 2) also set at pc 0x40110a.
	  Note: breakpoint 3 (thread 2) also set at pc 0x40110a.
	  Breakpoint 4 at 0x40110a: foo. (2 locations)

	Notice that GDB says:

	  Note: breakpoint 3 (thread 2) also set at pc 0x40110a.

	The 'thread 2' in here is using the global thread-id, we should
	instead say 'thread 2.1' which corresponds to how the user specified
	the breakpoint.

	This commit fixes this issue and adds a test.

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: add test for readline handling very long commands
	The test added in this commit tests for a long fixed readline issue
	relating to long command lines.  A similar patch has existed in the
	Fedora GDB tree for several years, but I don't see any reason why this
	test would not be suitable for inclusion in upstream GDB.  I've
	updated the patch to current testsuite standards.

	The test is checking for an issue that was fixed by this readline
	patch:

	  https://lists.gnu.org/archive/html/bug-readline/2006-11/msg00002.html

	Which was merged into readline 6.0 (released ~2010).  The issue was
	triggered when the user enters a long command line, which wrapped over
	multiple terminal lines.  The crash looks like this:

	  free(): invalid pointer

	  Fatal signal: Aborted
	  ----- Backtrace -----
	  0x4fb583 gdb_internal_backtrace_1
	          ../../src/gdb/bt-utils.c:122
	  0x4fb583 _Z22gdb_internal_backtracev
	          ../../src/gdb/bt-utils.c:168
	  0x6047b9 handle_fatal_signal
	          ../../src/gdb/event-top.c:964
	  0x7f26e0cc56af ???
	  0x7f26e0cc5625 ???
	  0x7f26e0cae8d8 ???
	  0x7f26e0d094be ???
	  0x7f26e0d10aab ???
	  0x7f26e0d124ab ???
	  0x7f26e1d32e12 rl_free_undo_list
	          ../../readline-5.2/undo.c:119
	  0x7f26e1d229eb readline_internal_teardown
	          ../../readline-5.2/readline.c:405
	  0x7f26e1d3425f rl_callback_read_char
	          ../../readline-5.2/callback.c:197
	  0x604c0d gdb_rl_callback_read_char_wrapper_noexcept
	          ../../src/gdb/event-top.c:192
	  0x60581d gdb_rl_callback_read_char_wrapper
	          ../../src/gdb/event-top.c:225
	  0x60492f stdin_event_handler
	          ../../src/gdb/event-top.c:545
	  0xa60015 gdb_wait_for_event
	          ../../src/gdbsupport/event-loop.cc:694
	  0xa6078d gdb_wait_for_event
	          ../../src/gdbsupport/event-loop.cc:593
	  0xa6078d _Z16gdb_do_one_eventi
	          ../../src/gdbsupport/event-loop.cc:264
	  0x6fc459 start_event_loop
	          ../../src/gdb/main.c:411
	  0x6fc459 captured_command_loop
	          ../../src/gdb/main.c:471
	  0x6fdce4 captured_main
	          ../../src/gdb/main.c:1310
	  0x6fdce4 _Z8gdb_mainP18captured_main_args
	          ../../src/gdb/main.c:1325
	  0x44f694 main
	          ../../src/gdb/gdb.c:32
	  ---------------------

	I recreated the above crash by a little light hacking on GDB, and then
	linking GDB against readline 5.2.  The above stack trace was generated
	from the test included in this patch, and matches the trace that was
	included in the original bug report.

	It is worth acknowledging that without hacking things GDB has a
	minimum requirement of readline 7.0.  This test is not about checking
	whether GDB has been built against an older version of readline, it is
	about checking that readline doesn't regress in this area.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-11  Andrew Burgess  <aburgess@redhat.com>

	gdb: remove unnecessary 'dir' commands from gdb-gdb.gdb script
	While debugging GDB I used 'show directories' and spotted lots of
	entries that didn't make much sense. Here are all the entries that are
	in my directories list:

	  /tmp/binutils-gdb/build
	  /tmp/binutils-gdb/build/../../src/gdb
	  /tmp/binutils-gdb/build/../../src/gdb/../bfd
	  /tmp/binutils-gdb/build/../../src/gdb/../libiberty
	  $cdir
	  $cwd

	Notice the second, third, and fourth entries in this list, these
	should really be:

	  /tmp/binutils-gdb/build/../src/gdb
	  /tmp/binutils-gdb/build/../src/gdb/../bfd
	  /tmp/binutils-gdb/build/../src/gdb/../libiberty

	The problem is because I generally run everything from the top level
	build directory, not the gdb/ sub-directory, thus, I start GDB like:

	  ./gdb/gdb --data-directory ./gdb/data-directory

	If run GDB under GDB, then I end up loading the gdb/gdb-gdb.gdb
	script, which contains these lines:

	  dir ../../src/gdb/../libiberty
	  dir ../../src/gdb/../bfd
	  dir ../../src/gdb
	  dir .

	These commands only make sense when running within the gdb/
	sub-directory.

	However, my debugging experience doesn't seem to be degraded at all, I
	can still see the GDB source code just fine; which is because the
	directory list still contains $cdir.

	The build/gdb/gdb-gdb.gdb script is created from the
	src/gdb/gdb-gdb.gdb.in template, which includes the automake @srcdir@
	markers.

	The 'dir' commands have mostly been around since the sourceware
	repository was first created, though this commit 67f0714670383a did
	reorder some of the 'dir' commands, which would seem to indicate these
	commands were important to some people, at some time.

	One possible fix would be to replace @srcdir@ with @abs_srcdir@, this
	would ensure that the entries added were all valid, no matter the
	user's current directory when debugging GDB.

	However... I'd like to propose that we instead remove all the extra
	directories completely.  My hope is that, with more recent tools, the
	debug information should allow us to correctly find all of the source
	files without having to add any extra 'dir' entries.  Obviously,
	commit 67f0714670383a does make me a little nervous, but the
	gdb-gdb.gdb script isn't something a non-maintainer will be using, so
	I think we can afford to be a little more aggressive here.  If it
	turns out the 'dir' entries are needed then we can add them back, but
	actually document why they are needed.  Plus, when we add them back we
	will use @abs_srcdir@ instead of @srcdir@.

	Reviewed-By: Tom Tromey <tom@tromey.com>

2023-02-11  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep] Don't use i386 unwinder for amd64
	For i386 we have these unwinders:
	...
	$ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
	The target architecture is set to "i386".
	dummy                   DUMMY_FRAME
	dwarf2 tailcall         TAILCALL_FRAME
	inline                  INLINE_FRAME
	i386 epilogue           NORMAL_FRAME
	dwarf2                  NORMAL_FRAME
	dwarf2 signal           SIGTRAMP_FRAME
	i386 stack tramp        NORMAL_FRAME
	i386 sigtramp           SIGTRAMP_FRAME
	i386 prologue           NORMAL_FRAME
	...
	and for amd64:
	...
	$ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
	The target architecture is set to "i386:x86-64".
	dummy                   DUMMY_FRAME
	dwarf2 tailcall         TAILCALL_FRAME
	inline                  INLINE_FRAME
	python                  NORMAL_FRAME
	amd64 epilogue          NORMAL_FRAME
	i386 epilogue           NORMAL_FRAME
	dwarf2                  NORMAL_FRAME
	dwarf2 signal           SIGTRAMP_FRAME
	amd64 sigtramp          SIGTRAMP_FRAME
	amd64 prologue          NORMAL_FRAME
	i386 stack tramp        NORMAL_FRAME
	i386 sigtramp           SIGTRAMP_FRAME
	i386 prologue           NORMAL_FRAME
	...

	ISTM me there's no reason for the i386 unwinders to be there for amd64.

	Furthermore, there's a generic need to play around with enabling and disabling
	unwinders, see PR8434.  Currently, that's only available for both the dwarf2
	unwinders at once using "maint set dwarf unwinders on/off".

	If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue"
	unwinder becomes active and gives the wrong answer, while I'm actually
	interested in the result of the dwarf2 unwinder.  Of course I can also
	manually disable the "i386 epilogue", but I take the fact that I have to do
	that as evidence that on amd64, the "i386 epilogue" is not only unnecessary,
	but in the way.

	Fix this by only adding the i386 unwinders if
	"info.bfd_arch_info->bits_per_word == 32".

	Note that the x32 abi (x86_64/-mx32):
	- has the same unwinder list as amd64 (x86_64/-m64) before this commit,
	- has info.bfd_arch_info->bits_per_word == 64, the same as amd64, and
	  consequently,
	- has the same unwinder list as amd64 after this commit.

	Tested on x86_64-linux, -m64 and -m32.  Not tested with -mx32.

	Reviewed-By: John Baldwin <jhb@freebsd.org>

	PR tdep/30102
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30102

2023-02-11  Alan Modra  <amodra@gmail.com>

	objdump -D of bss sections and -s with -j
	There is some inconsistency between the behaviour of objdump -D and
	objdump -s, both supposedly operating on all sections by default.
	objdump -s ignores bss sections, while objdump -D dissassembles the
	zeros.  Fix this by making objdump -D ignore bss sections too.

	Furthermore, "objdump -s -j .bss" doesn't dump .bss as it should,
	since the user is specifically asking to look at all those zeros.

	This change does find some tests that used objdump -D with expected
	output in bss-style sections.  I've updated all the msp430 tests that
	just wanted to find a non-empty section to look at section headers
	instead, making the tests slightly more stringent.  The ppc xcoff and
	spu tests are fixed by adding -j options to objdump, which makes the
	tests somewhat more lenient.

	binutils/
		* objdump.c (disassemble_section): Ignore sections without
		contents, unless overridden by -j.
		(dump_section): Allow -j to override the default of not
		displaying sections without contents.
		* doc/binutils.texi (objdump options): Update -D, -s and -j
		description.
	gas/
		* testsuite/gas/ppc/xcoff-tls-32.d: Select wanted objdump
		sections with -j.
		* testsuite/gas/ppc/xcoff-tls-64.d: Likewise.
	ld/
		* testsuite/ld-msp430-elf/main-bss-lower.d,
		* testsuite/ld-msp430-elf/main-bss-upper.d,
		* testsuite/ld-msp430-elf/main-const-lower.d,
		* testsuite/ld-msp430-elf/main-const-upper.d,
		* testsuite/ld-msp430-elf/main-text-lower.d,
		* testsuite/ld-msp430-elf/main-text-upper.d,
		* testsuite/ld-msp430-elf/main-var-lower.d,
		* testsuite/ld-msp430-elf/main-var-upper.d: Expect -wh output.
		* testsuite/ld-msp430-elf/msp430-elf.exp: Use objdump -wh
		rather than objdump -D or objdump -d with tests checking for
		non-empty given sections.
		* testsuite/ld-spu/ear.d,
		* testsuite/ld-spu/icache1.d,
		* testsuite/ld-spu/ovl.d,
		* testsuite/ld-spu/ovl2.d: Select wanted objdump sections.

2023-02-11  Alan Modra  <amodra@gmail.com>

	.debug sections without contents
		* dwarf1.c (_bfd_dwarf1_find_nearest_line): Exclude .debug
		sections without contents.

2023-02-11  Aaron Merey  <amerey@redhat.com>

	gdb/source: Fix open_source_file error handling
	open_source_file relies on errno to communicate the reason for a missing
	source file.

	open_source_file may also call debuginfod_find_source.  It is possible
	for debuginfod_find_source to set errno to a value unrelated to the
	reason for a failed download.

	This can result in bogus error messages being reported as the reason for
	a missing source file.  The following error message should instead be
	"No such file or directory":

	  Temporary breakpoint 1, 0x00005555556f4de0 in main ()
	  (gdb) list
	  Downloading source file /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in>
	  1       /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in>: Directory not empty.

	Fix this by having open_source_file return a negative errno if it fails
	to open a source file.  Use this value to generate the error message
	instead of errno.

	Approved-By: Tom Tromey <tom@tromey.com>
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29999

2023-02-11  Aaron Merey  <amerey@redhat.com>

	Move implementation of perror_with_name to gdbsupport
	gdbsupport/errors.h declares perror_with_name and leaves the
	implementation to the clients.

	However gdb and gdbserver's implementations are essentially the
	same, resulting in unnecessary code duplication.

	Fix this by implementing perror_with_name in gdbsupport.  Add an
	optional parameter for specifying the errno used to generate the
	error message.

	Also move the implementation of perror_string to gdbsupport since
	perror_with_name requires it.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-10  Andrew Burgess  <andrew.burgess@embecosm.com>

	GDB: Introduce limited array lengths while printing values
	This commit introduces the idea of loading only part of an array in
	order to print it, what I call "limited length" arrays.

	The motivation behind this work is to make it possible to print slices
	of very large arrays, where very large means bigger than
	`max-value-size'.

	Consider this GDB session with the current GDB:

	  (gdb) set max-value-size 100
	  (gdb) p large_1d_array
	  value requires 400 bytes, which is more than max-value-size
	  (gdb) p -elements 10 -- large_1d_array
	  value requires 400 bytes, which is more than max-value-size

	notice that the request to print 10 elements still fails, even though 10
	elements should be less than the max-value-size.  With a patched version
	of GDB:

	  (gdb) p -elements 10 -- large_1d_array
	  $1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}

	So now the print has succeeded.  It also has loaded `max-value-size'
	worth of data into value history, so the recorded value can be accessed
	consistently:

	  (gdb) p -elements 10 -- $1
	  $2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
	  (gdb) p $1
	  $3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
	    20, 21, 22, 23, 24, <unavailable> <repeats 75 times>}
	  (gdb)

	Accesses with other languages work similarly, although for Ada only
	C-style [] array element/dimension accesses use history.  For both Ada
	and Fortran () array element/dimension accesses go straight to the
	inferior, bypassing the value history just as with C pointers.

	Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>

2023-02-10  Maciej W. Rozycki  <macro@embecosm.com>

	GDB/testsuite: Add `-nonl' option to `gdb_test'
	Add a `-nonl' option to `gdb_test' making it possible to match output
	from commands such as `output' that do not produce a new line sequence
	at the end, e.g.:

	  (gdb) output 0
	  0(gdb)

2023-02-10  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Only make data actually retrieved into value history available
	While it makes sense to allow accessing out-of-bounds elements in the
	debuggee and see whatever there might happen to be there in memory (we
	are a debugger and not a programming rules enforcement facility and we
	want to make people's life easier in chasing bugs), e.g.:

	  (gdb) print one_hundred[-1]
	  $1 = 0
	  (gdb) print one_hundred[100]
	  $2 = 0
	  (gdb)

	we shouldn't really pretend that we have any meaningful data around
	values recorded in history (what these commands really retrieve are
	current debuggee memory contents outside the original data accessed,
	really confusing in my opinion).  Mark values recorded in history as
	such then and verify accesses to be in-range for them:

	  (gdb) print one_hundred[-1]
	  $1 = <unavailable>
	  (gdb) print one_hundred[100]
	  $2 = <unavailable>

	Add a suitable test case, which also covers integer overflows in data
	location calculation.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-10  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Fix the mess with value byte/bit range types
	Consistently use the LONGEST and ULONGEST types for value byte/bit
	offsets and lengths respectively, avoiding silent truncation for ranges
	exceeding the 32-bit span, which may cause incorrect matching.  Also
	report a conversion overflow on byte ranges that cannot be expressed in
	terms of bits with these data types, e.g.:

	  (gdb) print one_hundred[1LL << 58]
	  Integer overflow in data location calculation
	  (gdb) print one_hundred[(-1LL << 58) - 1]
	  Integer overflow in data location calculation
	  (gdb)

	Previously such accesses would be let through with unpredictable results
	produced.

2023-02-10  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Ignore `max-value-size' setting with value history accesses
	We have an inconsistency in value history accesses where array element
	accesses cause an error for entries exceeding the currently selected
	`max-value-size' setting even where such accesses successfully complete
	for elements located in the inferior, e.g.:

	  (gdb) p/d one
	  $1 = 0
	  (gdb) p/d one_hundred
	  $2 = {0 <repeats 100 times>}
	  (gdb) p/d one_hundred[99]
	  $3 = 0
	  (gdb) set max-value-size 25
	  (gdb) p/d one_hundred
	  value requires 100 bytes, which is more than max-value-size
	  (gdb) p/d one_hundred[99]
	  $7 = 0
	  (gdb) p/d $2
	  value requires 100 bytes, which is more than max-value-size
	  (gdb) p/d $2[99]
	  value requires 100 bytes, which is more than max-value-size
	  (gdb)

	According to our documentation the `max-value-size' setting is a safety
	guard against allocating an overly large amount of memory.  Moreover a
	statement in documentation says, concerning this setting, that: "Setting
	this variable does not affect values that have already been allocated
	within GDB, only future allocations."  While in the implementer-speak
	the sentence may be unambiguous I think the outside user may well infer
	that the setting does not apply to values previously printed.

	Therefore rather than just fixing this inconsistency it seems reasonable
	to lift the setting for value history accesses, under an implication
	that by having been retrieved from the debuggee they have already passed
	the safety check.  Do it then, by suppressing the value size check in
	`value_copy' -- under an observation that if the original value has been
	already loaded (i.e. it's not lazy), then it must have previously passed
	said check -- making the last two commands succeed:

	  (gdb) p/d $2
	  $8 = {0 <repeats 100 times>}
	  (gdb) p/d $2 [99]
	  $9 = 0
	  (gdb)

	Expand the testsuite accordingly, covering both value history handling
	and the use of `value_copy' by `make_cv_value', used by Python code.

2023-02-10  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Switch to using C++ standard integer type limits
	Use <climits> instead of <limits.h> and ditch local fallback definitions
	for minimum and maximum value macros provided by C++11.  Add LONGEST_MAX
	and LONGEST_MIN definitions.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-10  Tom Tromey  <tromey@adacore.com>

	Ensure all DAP requests are keyword-only
	Python functions implementing DAP requests should not use positional
	parameters -- it only makes sense to call them with keyword arguments.
	This patch changes the few remaining cases to start with the special
	"*" parameter, following this rule.

2023-02-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: fix gdb.gdb/selftest.exp for native-extended-gdbserver
	Following commit 4e2a80ba606 ("gdb/testsuite: expect SIGSEGV from top
	GDB spawn id"), the next failure I get in gdb.gdb/selftest.exp, using
	the native-extended-gdbserver, is:

	    (gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
	    signal SIGINT
	    Continuing with signal SIGINT.
	    FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout)

	The problem is that in this gdb_test_multiple:

	    set description "send SIGINT signal to child process"
	    gdb_test_multiple "signal SIGINT" "$description" {
		-re "^signal SIGINT\r\nContinuing with signal SIGINT.\r\nQuit\r\n.* $" {
		    pass "$description"
		}
	    }

	The "Continuing with signal SIGINT" portion is printed by the top GDB,
	while the Quit portion is printed by the bottom GDB.  As the
	gdb_test_multiple is written, it expects both the the top GDB's spawn
	id.

	Fix this by splitting the gdb_test_multiple in two.  The first one
	expects the "Continuing with signal SIGINT" from the top GDB.  The
	second one expect "Quit"  and the "(xgdb)" prompt from
	$inferior_spawn_id.  When debugging natively, this spawn id will be the
	same as the top GDB's spawn id, but it's different when debugging with
	GDBserver.

	Change-Id: I689bd369a041b48f4dc9858d38bf977d09600da2

2023-02-10  Tom Tromey  <tom@tromey.com>

	Use std::string in main_info
	This changes main_info to use std::string.  It removes some manual
	memory management.

2023-02-10  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp
	PR testsuite/30103 reports the following failure on aarch64-linux
	(ubuntu 22.04):
	...
	(gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp
	next
	warning: Breakpoint address adjusted from 0x83dc305fef755015 to \
	  0xffdc305fef755015.
	Warning:
	Cannot insert breakpoint 0.
	Cannot access memory at address 0xffdc305fef755015

	__libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30
	30	}
	(gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
	  (PRMS: next over longjmp)
	delete breakpoints
	Delete all breakpoints? (y or n) y
	(gdb) info breakpoints
	No breakpoints or watchpoints.
	(gdb) break 63
	No line 63 in the current file.
	Make breakpoint pending on future shared library load? (y or [n]) n
	(gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \
	  at pattern start (got interactive prompt)
	...

	The test-case intends to set the breakpoint on line number 63 in
	gdb.base/longjmp.c.

	It tries to do so by specifying "break 63", which specifies a line in the
	"current source file".

	Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence
	of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c.

	Consequently, setting the breakpoint fails.

	Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs.

	I've managed to reproduce the FAIL on x86_64/-m32, by installing the
	glibc-32bit-debuginfo package.  This allowed me to confirm the "current source
	file" that is used:
	...
	(gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
	  (PRMS: next over longjmp)
	info source^M
	Current source file is ../setjmp/longjmp.c^M
	...

	Tested on x86_64-linux, target boards unix/{-m64,-m32}.

	Reported-By: Luis Machado <luis.machado@arm.com>
	Reviewed-By: Tom Tromey <tom@tromey.com>

	PR testsuite/30103
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103

2023-02-10  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Add maint info frame-unwinders
	Add a new command "maint info frame-unwinders":
	...
	(gdb) help maint info frame-unwinders
	List the frame unwinders currently in effect, starting with the highest \
	  priority.
	...

	Output for i386:
	...
	$ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
	The target architecture is set to "i386".
	dummy                   DUMMY_FRAME
	dwarf2 tailcall         TAILCALL_FRAME
	inline                  INLINE_FRAME
	i386 epilogue           NORMAL_FRAME
	dwarf2                  NORMAL_FRAME
	dwarf2 signal           SIGTRAMP_FRAME
	i386 stack tramp        NORMAL_FRAME
	i386 sigtramp           SIGTRAMP_FRAME
	i386 prologue           NORMAL_FRAME
	...

	Output for x86_64:
	...
	$ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
	The target architecture is set to "i386:x86-64".
	dummy                   DUMMY_FRAME
	dwarf2 tailcall         TAILCALL_FRAME
	inline                  INLINE_FRAME
	python                  NORMAL_FRAME
	amd64 epilogue          NORMAL_FRAME
	i386 epilogue           NORMAL_FRAME
	dwarf2                  NORMAL_FRAME
	dwarf2 signal           SIGTRAMP_FRAME
	amd64 sigtramp          SIGTRAMP_FRAME
	amd64 prologue          NORMAL_FRAME
	i386 stack tramp        NORMAL_FRAME
	i386 sigtramp           SIGTRAMP_FRAME
	i386 prologue           NORMAL_FRAME
	...

	Tested on x86_64-linux.

	Reviewed-By: Tom Tromey <tom@tromey.com>
	Reviewed-By: Eli Zaretskii <eliz@gnu.org>

2023-02-10  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Reduce effective linker relaxation passses
	Commit 43025f01a0c9 ("RISC-V: Improve link time complexity.") reduced the
	time complexity of the linker relaxation but some code portions did not
	reflect this change.

	This commit fixes a comment describing each relaxation pass and reduces
	actual number of passes for the RISC-V linker relaxation from 3 to 2.
	Though it does not change the functionality, it marginally improves the
	performance while linking large programs (with many relocations).

	bfd/ChangeLog:

		* elfnn-riscv.c (_bfd_riscv_relax_section): Fix a comment to
		reflect current roles of each relaxation pass.

	ld/ChangeLog:

		* emultempl/riscvelf.em: Reduce the number of linker relaxation
		passes from 3 to 2.

2023-02-10  Alan Modra  <amodra@gmail.com>

	Fix mmo memory leaks
	The main one here is the section buffer, which can be quite large.
	By using alloc rather than malloc we can leave tidying memory to the
	generic bfd code when the bfd is closed.  bfd_check_format also
	releases memory when object_p fails, so while it wouldn't be wrong
	to bfd_release at bad_format_free in mmo_object_p, it's a little extra
	code and work for no gain.

		* mmo.c (mmo_object_p): bfd_alloc rather than bfd_malloc
		lop_stab_symbol.  Don't free/release on error.
		(mmo_get_spec_section): bfd_zalloc rather than bfd_zmalloc
		section buffer.
		(mmo_scan): Free fname on another error path.

2023-02-10  Alan Modra  <amodra@gmail.com>

	Local label checks in integer_constant
	"Local labels are never absolute" says the comment.  Except when they
	are.  Testcase
	 .offset
	0:
	 a=0b
	I don't see any particular reason to disallow local labels inside
	struct definitions, so delete the comment and assertions.

		* expr.c (integer_constant): Delete local label assertions.

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: drop use of VEX3SOURCES
	The attribute really specifies that the sum of register and memory
	operands is 4. Express it like that in most places, while using the 2nd
	(apart from XOP) CPU feature flags (FMA4) in reversed operand matching
	logic.

	With the use in build_modrm_byte() gone, part of an assertion there
	also becomes meaningless - simplify that at the same time.

	With all uses of the opcode modifier field gone, also drop that.

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: drop use of XOP2SOURCES
	The few XOP insns which used it wrongly didn't have VexVVVV specified.
	With that added, the only further missing piece to use more generic code
	elsewhere is SwapSources - see e.g. the BMI2 insns for similar operand
	patterns.

	With the only users gone, drop the #define as well as the special case
	code.

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: limit use of XOP2SOURCES
	The VPROT* forms with an immediate operand are entirely standard in the
	way their ModR/M bytes are built. There's no reason to invoke special
	case code. With that the handling of an immediate there can also be
	dropped; it was partially bogus anyway, as in its "no memory operands"
	portion it ignores the possibility of an immediate operand (which was
	okay only because that case was already handled by more generic code).

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: move (and rename) opcodespace attribute
	This really isn't a "modifier" and rather ought to live next to the base
	opcode anyway. Use the bits we presently have available to fit in the
	field, renaming it to opcode_space. As an intended side effect this
	helps readability at the use sites, by shortening the references quite a
	bit.

	In generated code arrange for human readable output, by using the
	SPACE_* constants there rather than raw numbers. This may aid debugging
	down the road.

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: simplify a few expressions
	Fold adjacent comparisons when, by ORing in a certain mask, the same
	effect can be achieved by a single one. In load_insn_p() this extends
	to further uses of an already available local variable.

2023-02-10  Jan Beulich  <jbeulich@suse.com>

	x86: improve special casing of certain insns
	Now that we have identifiers for the mnemonic strings we can avoid
	opcode based comparisons, for (in many cases) being more expensive and
	(in a few cases) being a little fragile and not self-documenting.

	Note that the MOV optimization can be engaged by the earlier LEA one,
	and hence LEA also needs checking for there.

2023-02-10  Alan Modra  <amodra@gmail.com>

	objcopy of mach-o indirect symbols
	Anti-fuzzer measure.  I'm not sure what the correct fix is for
	objcopy.  Probably the BFD_MACH_O_S_NON_LAZY_SYMBOL_POINTERS,
	BFD_MACH_O_S_LAZY_SYMBOL_POINTERS and BFD_MACH_O_S_SYMBOL_STUBS
	contents should be read.

		* mach-o.c (bfd_mach_o_section_get_nbr_indirect): Omit sections
		with NULL sec->indirect_syms.

2023-02-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-09  Tom Tromey  <tromey@adacore.com>

	Add full display feature to dwarf-mode.el
	I've found that I often use dwarf-mode with relatively small test
	files.  In this situation, it's handy to be able to expand all the
	DWARF, rather than moving to each "..." separately and using C-u C-m.

	This patch implements this feature.  It also makes a couple of other
	minor changes:

	* I removed a stale FIXME from dwarf-mode.  In practice I find I often
	  use "g" to restore the buffer to a pristine state; checking the file
	  mtime would work against this.

	* I tightened the regexp in dwarf-insert-substructure.  This prevents
	  the C-m binding from trying to re-read a DIE which has already been
	  expanded.

	* Finally, I've bumped the dwarf-mode version number so that this
	  version can easily be installed using package.el.

	2023-02-09  Tom Tromey  <tromey@adacore.com>

		* dwarf-mode.el: Bump version to 1.8.
		(dwarf-insert-substructure): Tighten regexp.
		(dwarf-refresh-all): New defun.
		(dwarf-mode-map): Bind "A" to dwarf-refresh-all.
		(dwarf-mode): Remove old FIXME.

2023-02-09  Tom Tromey  <tom@tromey.com>

	Fix comment in gdb.rust/fnfield.exp
	gdb.rust/fnfield.exp has a comment that, I assume, I copied from some
	other test.  This patch fixes it.

2023-02-09  Tom Tromey  <tom@tromey.com>

	Trivially simplify rust_language::print_enum
	rust_language::print_enum computes:

	  int nfields = variant_type->num_fields ();

	... but then does not reuse this in one spot.  This patch corrects the
	oversight.

2023-02-09  Roland McGrath  <mcgrathr@google.com>

	[aarch64] Avoid initializers for VLAs
	Clang doesn't accept initializer syntax for variable-length
	arrays in C. Just use memset instead.

2023-02-09  Christina Schimpe  <christina.schimpe@intel.com>

	gdb, testsuite: Remove unnecessary call of "set print pretty on"
	The command has no effect for the loading of GDB pretty printers and is
	removed by this patch to avoid confusion.

	Documentation for "set print pretty"
	"Cause GDB to print structures in an indented format with one member per line"

2023-02-09  Tom Tromey  <tromey@adacore.com>

	Increase size of main_type::nfields
	main_type::nfields is a 'short', and has been for many years.  PR
	c++/29985 points out that 'short' is too narrow for an enum that
	contains more than 2^15 constants.

	This patch bumps the size of 'nfields'.  To verify that the field
	isn't directly used, it is also renamed.  Note that this does not
	affect the size of main_type on x86-64 Fedora 36.  And, if it does
	have a negative effect somewhere, it's worth considering that types
	could be shrunk more drastically by using subclasses for the different
	codes.

	This is v2 of this patch, which has these changes:

	* I changed nfields to 'unsigned', per Simon's request.  I looked at
	  changing all the uses, but this quickly fans out into a very large
	  patch.  (One additional tweak was needed, though.)

	* I wrote a test case.  I discovered that GCC cannot compile a large
	  enough C test case, so I resorted to using the DWARF assembler.
	  This test doesn't reproduce the crash, but it does fail without the
	  patch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29985

2023-02-09  Tom Tromey  <tromey@adacore.com>

	Remove mention of cooked_index_vector
	I noticed a leftover mention of cooked_index_vector.  This updates the
	text.

2023-02-09  Tom Tromey  <tromey@adacore.com>

	Let user C-c when waiting for DWARF index finalization
	In PR gdb/29854, Simon pointed out that it would be good to be able to
	use C-c when the DWARF cooked index is waiting for finalization.  The
	idea here is to be able to interrupt a command like "break" -- not to
	stop the finalization process itself, which runs in a worker thread.

	This patch implements this idea, by changing the index wait functions
	to, by default, allow a quit.  Polling is done, because there doesn't
	seem to be a better way to interrupt a wait on a std::future.

	For v2, I realized that the thread compatibility code in thread-pool.h
	also needed an update.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29854

2023-02-09  Alan Modra  <amodra@gmail.com>

	coff keep_relocs and keep_contents
	keep_relocs is set by pe_ILF_save_relocs but not used anywhere in the
	coff/pe code.  It is tested by the xcoff backend but not set.

	keep_contents is only used by the xcoff backend when dealing with
	the .loader section, and it's easy enough to dispense with it there.
	keep_contents is set in various places but that's fairly useless when
	the contents aren't freed anyway until later linker support functions,
	add_dynamic_symbols and check_dynamic_ar_symbols.  There the contents
	were freed if keep_contents wasn't set.  I reckon we can free them
	unconditionally.

		* coff-bfd.h (struct coff_section_tdata): Delete keep_relocs
		and keep_contents.
		* peicode.h (pe_ILF_save_relocs): Don't set keep_relocs.
		* xcofflink.c (xcoff_get_section_contents): Cache contents.
		Return the contents.  Update callers.
		(_bfd_xcoff_canonicalize_dynamic_symtab): Don't set
		keep_contents for .loader.
		(xcoff_link_add_dynamic_symbols): Free .loader contents
		unconditionally.
		(xcoff_link_check_dynamic_ar_symbols): Likewise.

2023-02-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-08  Alan Modra  <amodra@gmail.com>

	coff-sh.c keep_relocs, keep_contents and keep_syms
	keep_relocs and keep_contents are unused nowadays except by
	xcofflink.c, and I can't see a reason why keep_syms needs to be set.
	The external syms are read and used by sh_relax_section and used by
	sh_relax_delete_bytes.  There doesn't appear to be any way that
	freeing them will cause trouble.

		* coff-sh.c (sh_relax_section): Don't set keep_relocs,
		keep_contents or keep_syms.
		(sh_relax_delete_bytes): Don't set keep_contents.

2023-02-08  Alan Modra  <amodra@gmail.com>

	Memory leak in bfd_init_section_compress_status
		* compress.c (bfd_init_section_compress_status): Free
		uncompressed_buffer on error return.

2023-02-08  Alan Modra  <amodra@gmail.com>

	Clear cached file size when bfd changed to BFD_IN_MEMORY
	If file size is calculated by bfd_get_file_size, as it is by
	_bfd_alloc_and_read calls in coff_object_p, then it is cached and when
	pe_ILF_build_a_bfd converts an archive entry over to BFD_IN_MEMORY,
	the file size is no longer valid.  Found when attempting objdump -t on
	a very small (27 bytes) ILF file and hitting the pr24707 fix (commit
	781152ec18f5).  So, clear file size when setting BFD_IN_MEMORY on bfds
	that may have been read.  (It's not necessary in writable bfds,
	because caching is ignored by bfd_get_size when bfd_write_p.)

	I also think the PR 24707 fix is no longer neeeded.  All of the
	testcases in that PR and in PR24712 are caught earlier by file size
	checks when reading the symbols from file.  So I'm reverting that fix,
	which just compared the size of an array of symbol pointers against
	file size.  That's only valid if on-disk symbols are larger than a
	host pointer, so the test is better done in format-specific code.

	bfd/
		* coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Clear cached
		file size when making a BFD_IN_MEMORY bfd.
		* opncls.c (bfd_make_readable): Likewise.
		* peicode.h (pe_ILF_build_a_bfd): Likewise.
	binutils/
		PR 24707
		* objdump.c (slurp_symtab): Revert PR24707 fix.  Tidy.
		(slurp_dynamic_symtab): Tidy.

2023-02-08  Alan Modra  <amodra@gmail.com>

	Internal error at gas/expr.c:1814
	This is the assertion
	  know (*input_line_pointer != ' ');
	after calling operand.

	The usual exit from operand calls SKIP_ALL_WHITESPACE.

		* expr.c (operand): Call SKIP_ALL_WHITESPACE after call to expr.

2023-02-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: give sentinel for user frames distinct IDs, register sentinel frames to the frame cache
	The test gdb.base/frame-view.exp fails like this on AArch64:

	    frame^M
	    #0  baz (z1=hahaha, /home/simark/src/binutils-gdb/gdb/value.c:4056: internal-error: value_fetch_lazy_register: Assertion `next_frame != NULL' failed.^M
	    A problem internal to GDB has been detected,^M
	    further debugging may prove unreliable.^M
	    FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame (GDB internal error)

	The sequence of events leading to this is the following:

	 - When we create the user frame (the "select-frame view" command), we
	   create a sentinel frame just for our user-created frame, in
	   create_new_frame.  This sentinel frame has the same id as the regular
	   sentinel frame.

	 - When printing the frame, after doing the "select-frame view" command,
	   the argument's pretty printer is invoked, which does an inferior
	   function call (this is the point of the test).  This clears the frame
	   cache, including the "real" sentinel frame, which sets the
	   sentinel_frame global to nullptr.

	 - Later in the frame-printing process (when printing the second
	   argument), the auto-reinflation mechanism re-creates the user frame
	   by calling create_new_frame again, creating its own special sentinel
	   frame again.  However, note that the "real" sentinel frame, the
	   sentinel_frame global, is still nullptr.  If the selected frame had
	   been a regular frame, we would have called get_current_frame at some
	   point during the reinflation, which would have re-created the "real"
	   sentinel frame.  But it's not the case when reinflating a user frame.

	 - Deep down the stack, something wants to fill in the unwind stop
	   reason for frame 0, which requires trying to unwind frame 1.  This
	   leads us to trying to unwind the PC of frame 1:

	     #0  gdbarch_unwind_pc (gdbarch=0xffff8d010080, next_frame=...) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:2955
	     #1  0x000000000134569c in dwarf2_tailcall_sniffer_first (this_frame=..., tailcall_cachep=0xffff773fcae0, entry_cfa_sp_offsetp=0xfffff7f7d450)
	         at /home/simark/src/binutils-gdb/gdb/dwarf2/frame-tailcall.c:390
	     #2  0x0000000001355d84 in dwarf2_frame_cache (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1089
	     #3  0x00000000013562b0 in dwarf2_frame_unwind_stop_reason (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1101
	     #4  0x0000000001990f64 in get_prev_frame_always_1 (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2281
	     #5  0x0000000001993034 in get_prev_frame_always (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2376
	     #6  0x000000000199b814 in get_frame_unwind_stop_reason (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:3051
	     #7  0x0000000001359cd8 in dwarf2_frame_cfa (this_frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1356
	     #8  0x000000000132122c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d8883ee "\217\002", op_end=0xffff8d8883ee "\217\002")
	         at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:2110
	     #9  0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d8883ed "\234\217\002", len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239
	     #10 0x000000000131d68c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d88840e "", op_end=0xffff8d88840e "") at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1811
	     #11 0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239
	     #12 0x0000000001314c3c in dwarf_expr_context::evaluate (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2, as_lval=true, per_cu=0xffff90b03700, frame=..., addr_info=0x0,
	         type=0xffff8f6c8400, subobj_type=0xffff8f6c8400, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1078
	     #13 0x000000000149f9e0 in dwarf2_evaluate_loc_desc_full (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980,
	         subobj_type=0xffff8f6c8400, subobj_byte_offset=0, as_lval=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1513
	     #14 0x00000000014a0100 in dwarf2_evaluate_loc_desc (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980, as_lval=true)
	         at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1557
	     #15 0x00000000014aa584 in locexpr_read_variable (symbol=0xffff8f6cd770, frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3052

	 - AArch64 defines a special "prev register" function,
	   aarch64_dwarf2_prev_register, to handle unwinding the PC.  This
	   function does

	     frame_unwind_register_unsigned (this_frame, AARCH64_LR_REGNUM);

	 - frame_unwind_register_unsigned ultimately creates a lazy register
	   value, saving the frame id of this_frame->next.  this_frame is the
	   user-created frame, to this_frame->next is the special sentinel frame
	   we created for it.  So the saved ID is the sentinel frame ID.

	 - When time comes to un-lazify the value, value_fetch_lazy_register
	   calls frame_find_by_id, to find the frame with the ID we saved.

	 - frame_find_by_id sees it's the sentinel frame ID, so returns the
	   sentinel_frame global, which is, if you remember, nullptr.

	 - We hit the `gdb_assert (next_frame != NULL)` assertion in
	   value_fetch_lazy_register.

	The issues I see here are:

	 - The ID of the sentinel frame created for the user-created frame is
	   not distinguishable from the ID of the regular sentinel frame.  So
	   there's no way frame_find_by_id could find the right frame, in
	   value_fetch_lazy_register.
	 - Even if they had distinguishable IDs, sentinel frames created for
	   user frames are not registered anywhere, so there's no easy way
	   frame_find_by_id could find it.

	This patch addresses these two issues:

	 - Give sentinel frames created for user frames their own distinct IDs
	 - Register sentinel frames in the frame cache, so they can be found
	   with frame_find_by_id.

	I initially had this split in two patches, but I then found that it was
	easier to explain as a single patch.

	Rergarding the first part of the change: with this patch, the sentinel
	frames created for user frames (in create_new_frame) still have
	stack_status == FID_STACK_SENTINEL, but their code_addr and stack_addr
	fields are now filled with the addresses used to create the user frame.
	This ensures this sentinel frame ID is different from the "target"
	sentinel frame ID, as well as any other "user" sentinel frame ID.  If
	the user tries to create the same frame, with the same addresses,
	multiple times, create_sentinel_frame just reuses the existing frame.
	So we won't end up with multiple user sentinels with the same ID.

	Regular "target" sentinel frames remain with code_addr and stack_addr
	unset.

	The concrete changes for that part are:

	 - Remove the sentinel_frame_id constant, since there isn't one
	   "sentinel frame ID" now.  Add the frame_id_build_sentinel function
	   for building sentinel frame IDs and a is_sentinel_frame_id function
	   to check if a frame id represents a sentinel frame.
	 - Replace the sentinel_frame_id check in frame_find_by_id with a
	   comparison to `frame_id_build_sentinel (0, 0)`.  The sentinel_frame
	   global is meant to contain a reference to the "target" sentinel, so
	   the one with addresses (0, 0).
	 - Add stack and code address parameters to create_sentinel_frame, to be
	   able to create the various types of sentinel frames.
	 - Adjust get_current_frame to create the regular "target" sentinel.
	 - Adjust create_new_frame to create a sentinel with the ID specific to
	   the created user frame.
	 - Adjust sentinel_frame_prev_register to get the sentinel frame ID from
	   the frame_info object, since there isn't a single "sentinel frame ID"
	   now.
	 - Change get_next_frame_sentinel_okay to check for a
	   sentinel-frame-id-like frame ID, rather than for sentinel_frame
	   specifically, since this function could be called with another
	   sentinel frame (and we would want the assert to catch it).

	The rest of the change is about registering the sentinel frame in the
	frame cache:

	 - Change frame_stash_add's assertion to allow sentinel frame levels
	   (-1).
	 - Make create_sentinel_frame add the frame to the frame cache.
	 - Change the "sentinel_frame != NULL" check in reinit_frame_cache for a
	   check that the frame stash is not empty.  The idea is that if we only
	   have some user-created frames in the cache when reinit_frame_cache is
	   called, we probably want to emit the frames invalid annotation.  The
	   goal of that check is to avoid unnecessary repeated annotations, I
	   suppose, so the "frame cache not empty" check should achieve that.

	After this change, I think we could theoritically get rid of the
	sentienl_frame global.  That sentinel frame could always be found by
	looking up `frame_id_build_sentinel (0, 0)` in the frame cache.
	However, I left the global there to avoid slowing the typical case down
	for nothing.  I however, noted in its comment that it is an
	optimization.

	With this fix applied, the gdb.base/frame-view.exp now passes for me on
	AArch64.  value_of_register_lazy now saves the special sentinel frame ID
	in the value, and value_fetch_lazy_register is able to find that
	sentinel frame after the frame cache reinit and after the user-created
	frame was reinflated.

	Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
	Tested-By: Luis Machado <luis.machado@arm.com>
	Change-Id: I8b77b3448822c8aab3e1c3dda76ec434eb62704f

2023-02-08  Simon Marchi  <simon.marchi@efficios.com>

	gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache
	Currently, some frame resources are deallocated by iterating on the
	frame chain (starting from the sentinel), calling dealloc_cache.  The
	problem is that user-created frames are not part of that chain, so we
	never call dealloc_cache for them.

	I propose to make it so the dealloc_cache callbacks are called when the
	frames are removed from the frame_stash hash table, by registering a
	deletion function to the hash table.  This happens when
	frame_stash_invalidate is called by reinit_frame_cache.  This way, all
	frames registered in the cache will get their unwinder's dealloc_cache
	callbacks called.

	Note that at the moment, the sentinel frames are not registered in the
	cache, so we won't call dealloc_cache for them.  However, it's just a
	theoritical problem, because the sentinel frame unwinder does not
	provide this callback.  Also, a subsequent patch will change things so
	that sentinel frames are registered to the cache.

	I moved the obstack_free / obstack_init pair below the
	frame_stash_invalidate call in reinit_frame_cache, because I assumed
	that some dealloc_cache would need to access some data on that obstack,
	so it would be better to free it after clearing the hash table.

	Change-Id: If4f9b38266b458c4e2f7eb43e933090177c22190

2023-02-08  Tom Tromey  <tom@tromey.com>

	Remove block.h includes from some tdep files
	A few tdep files include block.h but do not need to.  This patch
	removes the inclusions.  I checked that this worked correctly by
	examining the resulting .Po file to make sure that block.h was not
	being included by some other route.

	Don't include block.h from expop.h
	expop.h needs block.h for a single inline function.  However, I don't
	think most of the check_objfile functions need to be defined in the
	header (just the templates).  This patch moves the one offending
	function and removes the include.

2023-02-08  Pedro Alves  <pedro@palves.net>

	Simplify interp::exec / interp_exec - let exceptions propagate
	This patch implements a simplication that I suggested here:

	  https://sourceware.org/pipermail/gdb-patches/2022-March/186320.html

	Currently, the interp::exec virtual method interface is such that
	subclass implementations must catch exceptions and then return them
	via normal function return.

	However, higher up the in chain, for the CLI we get to
	interpreter_exec_cmd, which does:

	  for (i = 1; i < nrules; i++)
	    {
	      struct gdb_exception e = interp_exec (interp_to_use, prules[i]);

	      if (e.reason < 0)
		{
		  interp_set (old_interp, 0);
		  error (_("error in command: \"%s\"."), prules[i]);
		}
	    }

	and for MI we get to mi_cmd_interpreter_exec, which has:

	  void
	  mi_cmd_interpreter_exec (const char *command, char **argv, int argc)
	  {
	  ...
	    for (i = 1; i < argc; i++)
	      {
		struct gdb_exception e = interp_exec (interp_to_use, argv[i]);

		if (e.reason < 0)
		  error ("%s", e.what ());
	      }
	  }

	Note that if those errors are reached, we lose the original
	exception's error code.  I can't see why we'd want that.

	And, I can't see why we need to have interp_exec catch the exception
	and return it via the normal return path.  That's normally needed when
	we need to handle propagating exceptions across C code, like across
	readline or ncurses, but that's not the case here.

	It seems to me that we can simplify things by removing some
	try/catch-ing and just letting exceptions propagate normally.

	Note, the "error in command" error shown above, which only exists in
	the CLI interpreter-exec command, is only ever printed AFAICS if you
	run "interpreter-exec console" when the top level interpreter is
	already the console/tui.  Like:

	 (gdb) interpreter-exec console "foobar"
	 Undefined command: "foobar".  Try "help".
	 error in command: "foobar".

	You won't see it with MI's "-interpreter-exec console" from a top
	level MI interpreter:

	 (gdb)
	 -interpreter-exec console "foobar"
	 &"Undefined command: \"foobar\".  Try \"help\".\n"
	 ^error,msg="Undefined command: \"foobar\".  Try \"help\"."
	 (gdb)

	nor with MI's "-interpreter-exec mi" from a top level MI interpreter:

	 (gdb)
	 -interpreter-exec mi "-foobar"
	 ^error,msg="Undefined MI command: foobar",code="undefined-command"
	 ^done
	 (gdb)

	in both these cases because MI's -interpreter-exec just does:

	  error ("%s", e.what ());

	You won't see it either when running an MI command with the CLI's
	"interpreter-exec mi":

	 (gdb) interpreter-exec mi "-foobar"
	 ^error,msg="Undefined MI command: foobar",code="undefined-command"
	 (gdb)

	This last case is because MI's interp::exec implementation never
	returns an error:

	 gdb_exception
	 mi_interp::exec (const char *command)
	 {
	   mi_execute_command_wrapper (command);
	   return gdb_exception ();
	 }

	Thus I think that "error in command" error is pretty pointless, and
	since it simplifies things to not have it, the patch just removes it.

	The patch also ends up addressing an old FIXME.

	Change-Id: I5a6432a80496934ac7127594c53bf5221622e393
	Approved-By: Tom Tromey <tromey@adacore.com>
	Approved-By: Kevin Buettner <kevinb@redhat.com>

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Avoid FAILs in gdb.compile
	Many gdb.compile C++ tests fail for me on Fedora 36.  I think these
	are largely bugs in the plugin, though I didn't investigate too
	deeply.  Once one failure is seen, this often cascades and sometimes
	there are many timeouts.

	For example, this can happen:

	    (gdb) compile code var = a->get_var ()
	    warning: Could not find symbol "_ZZ9_gdb_exprP10__gdb_regsE1a" for compiled module "/tmp/gdbobj-0xdI6U/out2.o".
	    1 symbols were missing, cannot continue.

	I think this is probably a plugin bug because, IIRC, in theory these
	symbols should be exempt from a lookup via gdb.

	This patch arranges to catch any catastrophic failure and then simply
	exit the entire .exp file.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Don't let .gdb_history file cause failures
	I had a .gdb_history file in my testsuite directory in the build tree,
	and this provoked a failure in gdbhistsize-history.exp.  It seems
	simple to prevent this file from causing a failure.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Merge fixup_section and fixup_symbol_section
	fixup_symbol_section delegates all its work to fixup_section, so merge
	the two.

	Because there is only a single caller to fixup_symbol_section, we can
	also remove some of the introductory logic.  For example, this will
	never be called with a NULL objfile any more.

	The LOC_BLOCK case can be removed, because such symbols are handled by
	the buildsym code now.

	Finally, a symbol can only appear in a SEC_ALLOC section, so the loop
	is modified to skip sections that do not have this flag set.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Remove most calls to fixup_symbol_section
	Nearly every call to fixup_symbol_section in gdb is incorrect, and if
	any such call has an effect, it's purely by happenstance.

	fixup_section has a long comment explaining that the call should only
	be made before runtime section offsets are applied.  And, the loop in
	this code (the fallback loop -- the minsym lookup code is "ok") is
	careful to remove these offsets before comparing addresses.

	However, aside from a single call in dwarf2/read.c, every call in gdb
	is actually done after section offsets have been applied.  So, these
	calls are incorrect.

	Now, these calls could be made when the symbol is created.  I
	considered this approach, but I reasoned that the code has been this
	way for many years, seemingly without ill effect.  So, instead I chose
	to simply remove the offending calls.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Set section index when setting a symbol's block
	When a symbol's block is set, the block has the runtime section offset
	applied.  So, it seems to me that the symbol implicitly is in the same
	section as the block.  Therefore, this patch sets the symbol's section
	index at this same spot.

	Remove compunit_symtab::m_block_line_section
	The previous patch hard-coded SECT_OFF_TEXT into the buildsym code.
	After this, it's clear that there is only one caller of
	compunit_symtab::set_block_line_section, and it always passes
	SECT_OFF_TEXT.  So, remove compunit_symtab::m_block_line_section and
	use SECT_OFF_TEXT instead.

	Do not pass section index to end_compunit_symtab
	Right now, the section index passed to end_compunit_symtab is always
	SECT_OFF_TEXT.  Remove this parameter and simply always use
	SECT_OFF_TEXT.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Set section indices when symbols are made
	Most places in gdb that create a new symbol will apply a section
	offset to the address.  It seems to me that the choice of offset here
	is also an implicit choice of the section.  This is particularly true
	if you examine fixup_section, which notes that it must be called
	before such offsets are applied -- meaning that if any such call has
	an effect, it's purely by accident.

	This patch cleans up this area by tracking the section index and
	applying it to a symbol when the address is set.  This is done for
	nearly every case -- the remaining cases will be handled in later
	patches.

2023-02-08  Tom Tromey  <tromey@adacore.com>

	Use default section indexes in fixup_symbol_section
	If fixup_section does not find a matching section, it arbitrarily
	chooses the first one.  However, it seems better to make this default
	depend on the type of the symbol -- i.e., default data symbols to
	.data and text symbols to .text.

	I've also made fixup_section static, as it only has one caller.

2023-02-08  Tom Tromey  <tom@tromey.com>

	Simplify checks of cooked_index
	This changes the cooked_index_functions to avoid an extra null check
	now that checked_static_cast allows a null argument.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp
	Test-case gdb.base/longjmp.exp handles both the case that there is a libc
	longjmp probe, and the case that there isn't.

	However, it only tests one of the two cases.

	Use maint ignore-probes to test both cases, if possible.

	Tested on x86_64-linux.

2023-02-08  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Use maint ignore-probes in gdb.base/solib-corrupted.exp
	Test-case gdb.base/solib-corrupted.exp only works for a glibc without probes
	interface, otherwise we run into:
	...
	XFAIL: gdb.base/solib-corrupted.exp: info probes
	UNTESTED: gdb.base/solib-corrupted.exp: GDB is using probes
	...

	Fix this by using maint ignore-probes to simulate the absence of the relevant
	probes.

	Also, it requires glibc debuginfo, and if not present, it produces an XFAIL:
	...
	XFAIL: gdb.base/solib-corrupted.exp: make solibs looping
	UNTESTED: gdb.base/solib-corrupted.exp: no _r_debug symbol has been found
	...
	This is incorrect, because an XFAIL indicates a known problem in the
	environment.  In this case, there is no problem: the environment is
	functioning as expected when glibc debuginfo is not installed.

	Fix this by using UNSUPPORTED instead, and make the message less cryptic:
	...
	UNSUPPORTED: gdb.base/solib-corrupted.exp: make solibs looping \
	  (glibc debuginfo required)
	...

	Finally, with glibc debuginfo present, we run into:
	...
	(gdb) PASS: gdb.base/solib-corrupted.exp: make solibs looping
	info sharedlibrary^M
	warning: Corrupted shared library list: 0x7ffff7ffe750 != 0x0^M
	From                To                  Syms Read   Shared Object Library^M
	0x00007ffff7dd4170  0x00007ffff7df4090  Yes         /lib64/ld-linux-x86-64.so.2^M
	(gdb) FAIL: gdb.base/solib-corrupted.exp: corrupted list \
	  (shared library list corrupted)
	...
	due to commit 44288716537 ("gdb, testsuite: extend gdb_test_multiple checks").

	Fix this by rewriting into gdb_test_multiple and using -early.

	Tested on x86_64-linux, with and without glibc debuginfo installed.

2023-02-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: fix SIGSEGV when processing unusual dwarf
	gprofng/ChangeLog
	2023-02-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30093
		* src/Dwarf.cc: add nullptr check.
		* src/DwarfLib.cc: Likewise.

2023-02-08  Alan Modra  <amodra@gmail.com>

	Re: Resetting section vma after _bfd_dwarf2_find_nearest_line
	f.bfd_ptr is set too early to be a reliable indicator of good debug
	info.

		* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Correct test for
		debug info being previously found.

2023-02-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-07  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix display of thread condition for multi-location breakpoints
	This commit addresses the issue in PR gdb/30087.

	If a breakpoint with multiple locations has a thread condition, then
	the 'info breakpoints' output is a little messed up, here's an example
	of the current output:

	  (gdb) break foo thread 1
	  Breakpoint 2 at 0x401114: foo. (3 locations)
	  (gdb) break bar thread 1
	  Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   <MULTIPLE>          thread 1
	          stop only in thread 1
	  2.1                         y   0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  2.2                         y   0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  2.3                         y   0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  3       breakpoint     keep y   0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1
	          stop only in thread 1

	Notice that, at the end of the location for breakpoint 3, the 'thread
	1' condition is printed, but this is then repeated on the next line
	with 'stop only in thread 1'.

	In contrast, for breakpoint 2, the 'thread 1' appears randomly, in the
	"What" column, though slightly offset, non of the separate locations
	have the 'thread 1' information.  Additionally for breakpoint 2 we
	also get a 'stop only in thread 1' line.

	There's two things going on here.  First the randomly placed 'thread
	1' for breakpoint 2 is due to a bug in print_one_breakpoint_location,
	where we check the variable part_of_multiple instead of
	header_of_multiple.

	If I fix this oversight, then the output is now:

	  (gdb) break foo thread 1
	  Breakpoint 2 at 0x401114: foo. (3 locations)
	  (gdb) break bar thread 1
	  Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   <MULTIPLE>
	          stop only in thread 1
	  2.1                         y   0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
	  2.2                         y   0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
	  2.3                         y   0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
	  3       breakpoint     keep y   0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1
	          stop only in thread 1

	The 'thread 1' condition is now displayed at the end of each location,
	which makes the output the same for single location breakpoints and
	multi-location breakpoints.

	However, there's still some duplication here.  Both breakpoints 2 and
	3 include a 'stop only in thread 1' line, and it feels like the
	additional 'thread 1' is redundant.  In fact, there's a comment to
	this very effect in the code:

	  /* FIXME: This seems to be redundant and lost here; see the
	     "stop only in" line a little further down.  */

	So, lets fix this FIXME.  The new plan is to remove all the trailing
	'thread 1' markers from the CLI output, we now get this:

	  (gdb) break foo thread 1
	  Breakpoint 2 at 0x401114: foo. (3 locations)
	  (gdb) break bar thread 1
	  Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
	  (gdb) info breakpoints
	  Num     Type           Disp Enb Address            What
	  2       breakpoint     keep y   <MULTIPLE>
	          stop only in thread 1
	  2.1                         y   0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  2.2                         y   0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  2.3                         y   0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
	  3       breakpoint     keep y   0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32
	          stop only in thread 1

	All of the above points are also true for the Ada 'task' breakpoint
	condition, and the changes I've made also update how the task
	information is printed, though in the case of the Ada task there was
	no 'stop only in task XXX' line printed, so I've added one of those.

	Obviously it can't be quite that easy.  For MI backwards compatibility
	I've retained the existing code (but now only for MI like outputs),
	which ensures we should generate backwards compatible output.

	I've extended an Ada test to cover the new task related output, and
	updated all the tests I could find that checked for the old output.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30087

	Approved-By: Pedro Alves <pedro@palves.net>

2023-02-07  Nick Clifton  <nickc@redhat.com>

	Fix documentation of the 'n' symbol type displayed by nm.
	PR 30080 * doc/binutils.texi (nm): Update description of the 'n' symbol type.

2023-02-07  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve untested message in gdb.ada/finish-var-size.exp
	I came across:
	...
	UNTESTED: gdb.ada/finish-var-size.exp: GCC too told for this test
	...
	The message only tells us that the compiler version too old, not what compiler
	version is required.

	Fix this by rewriting using required:
	...
	UNSUPPORTED: gdb.ada/finish-var-size.exp: require failed: \
	  expr [gcc_major_version] >= 12
	...

	Tested on x86_64-linux.

2023-02-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-06  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: adjust comment on target_desc_info::from_user_p
	Remove the stale reference to INFO, which is now "this target
	description info" now.

	Change-Id: I35dbdb089048ed7cfffe730d3134ee391b176abf

2023-02-06  Andrew Burgess  <aburgess@redhat.com>

	gdb/doc: extend the documentation for the 'handle' command
	The documentation for the 'handle' command does not cover all of the
	features of the command, and in one case, is just wrong.

	The user can specify 'all' as signal name, the documentation implies
	that this will change the behaviour of all signals, in reality, this
	changes all signals except SIGINT and SIGTRAP (the signals used by
	GDB).  I've updated the docs to list this limitation.

	The 'handle' command also allows the user to specify multiple signals
	for a single command, e.g. 'handle SIGFPE SIGILL nostop pass print',
	however the documentation doesn't describe this, so I've updated the
	docs to describe this feature.

2023-02-06  Alan Modra  <amodra@gmail.com>

	ppc32 and "LOAD segment with RWX permissions"
	When using a bss-plt we'll always trigger the RWX warning, which
	disturbs gcc test results.  On the other hand, there may be reason to
	want the warning when gcc is configured with --enable-secureplt.
	So turning off the warning entirely for powerpc might not be the best
	solution.  Instead, we'll turn off the warning whenever a bss-plt is
	generated, unless the user explicitly asked for the warning.

	bfd/
		* elf32-ppc.c (ppc_elf_select_plt_layout): Set
		no_warn_rwx_segments on generating a bss plt, unless explicity
		enabled by the user.  Also show the bss-plt warning when
		--warn-rwx-segments is given without --bss-plt.
	include/
		* bfdlink.h (struct bfd_link_info): Add user_warn_rwx_segments.
	ld/
		* lexsup.c (parse_args): Set user_warn_rwx_segments.
		* testsuite/ld-elf/elf.exp: Pass --secure-plt for powerpc to
		the rwx tests.

2023-02-06  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu
	Occasionally, I run into:
	...
	(gdb) PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
	  set scheduler-locking on
	continue^M
	Continuing.^M
	PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
	  continue (with lock)
	[Thread 0x7ffff746e700 (LWP 1339) exited]^M
	No unwaited-for children left.^M
	(gdb) Quit^M
	(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
	  stop all threads (with lock) (timeout)
	...

	What happens is that this loop which is supposed to run "just short of forever":
	...
	    /* Don't run forever.  Run just short of it :)  */
	    while (*myp > 0)
	      {
	        /* schedlock.exp: main loop.  */
	        MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
	      }
	...
	finishes after 0x7fffffff iterations (when a signed wrap occurs), which on my
	system takes only about 1.5 seconds.

	Fix this by:
	- changing the pointed-at type of myp from signed to unsigned, which makes the
	  wrap defined behaviour (and which also make the loop run twice as long,
	  which is already enough to make it impossible for me to reproduce the FAIL.
	  But let's try to solve this more structurally).
	- changing the pointed-at type of myp from int to long long, making the wrap
	  unlikely.
	- making sure the loop runs forever, by setting the loop condition to 1.
	- making sure the loop still contains different lines (as far as debug info is
	  concerned) by incrementing a volatile counter in the loop.
	- making sure the program doesn't run forever in case of trouble, by adding an
	  "alarm (30)".

	Tested on x86_64-linux.

	PR testsuite/30074
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30074

2023-02-06  Andrew Burgess  <aburgess@redhat.com>

	gdb: error if 'thread' or 'task' keywords are overused
	When creating a breakpoint or watchpoint, the 'thread' and 'task'
	keywords can be used to create a thread or task specific breakpoint or
	watchpoint.

	Currently, a thread or task specific breakpoint can only apply for a
	single thread or task, if multiple threads or tasks are specified when
	creating the breakpoint (or watchpoint), then the last specified id
	will be used.

	The exception to the above is that when the 'thread' keyword is used
	during the creation of a watchpoint, GDB will give an error if
	'thread' is given more than once.

	In this commit I propose making this behaviour consistent, if the
	'thread' or 'task' keywords are used more than once when creating
	either a breakpoint or watchpoint, then GDB will give an error.

	I haven't updated the manual, we don't explicitly say that these
	keywords can be repeated, and (to me), given the keyword takes a
	single id, I don't think it makes much sense to repeat the keyword.
	As such, I see this more as adding a missing error to GDB, rather than
	making some big change.  However, I have added an entry to the NEWS
	file as I guess it is possible that some people might hit this new
	error with an existing (I claim, badly written) GDB script.

	I've added some new tests to check for the new error.

	Just one test needed updating, gdb.linespec/keywords.exp, this test
	did use the 'thread' keyword twice, and expected the breakpoint to be
	created.  Looking at what this test was for though, it was checking
	the use of '-force-condition', and I don't think that being able to
	repeat 'thread' was actually a critical part of this test.

	As such, I've updated this test to expect the error when 'thread' is
	repeated.

2023-02-06  Alan Modra  <amodra@gmail.com>

	Resetting section vma after _bfd_dwarf2_find_nearest_line
	There are failure paths in _bfd_dwarf2_slurp_debug_info that can
	result in altered section vmas.  Also, when setting ET_REL section
	vmas it's not too difficult to handle cases where the original vma was
	non-zero, so do that too.

	This patch was really in response to an addr2line buffer overflow
	processing a fuzzed mips relocatable object file.  The file had a
	number of .debug_info sections with relocations that included lo16 and
	hi16 relocs, and in that order.  At least one section VMA was
	non-zero.  This resulted in processing of DWARF info twice, once via
	the call to _bfd_dwarf2_find_nearest_line in
	_bfd_mips_elf_find_nearest_line, and because that failed leaving VMAs
	altered, the second via the call in _bfd_elf_find_nearest_line.  The
	first call left entries on mips_hi16_list pointing at buffers
	allocated during the first call, the second call processed the
	mips_hi16_list after the buffers had been freed.  (At least when
	running with asan and under valgrind.  Under gdb with a non-asan
	addr2line the second call allocated exactly the same buffer and the
	bug didn't show.)  Now I don't really care too much what happens with
	fuzzed files, but the logic in _bfd_dwarf2_find_nearest_line is meant
	to result in only one read of .debug_info, not multiple reads of the
	same info when there are errors.  This patch fixes that problem.

		* dwarf2.c (struct adjusted_section): Add orig_vma.
		(unset_sections): Reset vma to it.
		(place_sections): Handle non-zero vma too.  Save orig_vma.
		(_bfd_dwarf2_slurp_debug_info): Tidy.  Correct outdated comment.
		On error returns after calling place_sections, call
		unset_sections.
		(_bfd_dwarf2_find_nearest_line_with_alt): Simplify call to
		unset_sections.

2023-02-06  Romain Geissler  <romain.geissler@amadeus.com>

	[PR 30082] Pass $JANSSON_LIBS and $ZSTD_LIBS to ld-bootstrap/bootrap.exp

2023-02-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-04  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: don't try to set non-stop mode on a running target
	The test gdb.threads/thread-specific-bp.exp tries to set non-stop mode
	on a running target, something which the manual makes clear is not
	allowed.

	This commit restructures the test a little, we now set the non-stop
	mode as part of the GDBFLAGS, so the mode will be set before GDB
	connects to the target.  As a consequence I'm able to move the
	with_test_prefix out of the check_thread_specific_breakpoint proc.
	The check_thread_specific_breakpoint proc is now called within a loop.

	After this commit the gdb.threads/thread-specific-bp.exp test still
	has some failures, this is because of an issue GDB currently has
	printing "Thread ... exited" messages.  This problem should be
	addressed by this patch:

	  https://sourceware.org/pipermail/gdb-patches/2022-December/194694.html

	when it is merged.

2023-02-04  Dimitar Dimitrov  <dimitar@dinux.eu>

	ld: pru: Add optional section alignments
	The Texas Instruments SoCs with AARCH64 host processors have stricter
	alignment requirements than ones with ARM32 host processors.  It's not
	only the requirement for resource_table to be aligned to 8.  But also
	any loadable segment size must be a multiple of 4 [1].

	The current PRU default linker script may output a segment size not
	aligned to 4, which would cause firmware load failure on AARCH64 hosts.

	Fix this by using COMMONPAGESIZE and MAXPAGESIZE to signify respectively
	the section memory size requirement and the resource table section's
	start address alignment.  This would avoid penalizing the ARM32 hosts,
	for which the default values (1 and 1) are sufficient.

	For AARCH64 hosts, the alignments would be overwritten from GCC spec
	files using the linker command line, e.g.:
	  -z common-page-size=4 -z max-page-size=8

	[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n555

	ld/ChangeLog:

		* scripttempl/pru.sc (_data_end): Remove the alignment.
		(.data): Align output section size to COMMONPAGESIZE.
		(.resource_table): Ditto.

2023-02-04  Dimitar Dimitrov  <dimitar@dinux.eu>

	ld: pru: Merge the bss input sections into data
	The popular method to load PRU firmware is through the remoteproc Linux
	kernel driver.  In order to save a few bytes from the firmware, the PRU
	CRT0 is spared from calling memset for the bss segment [1].  Instead the
	host loader is supposed to zero out the bss segment.  This is important
	for PRU, which typically has only 8KB for instruction memory.

	The legacy non-mainline PRU host driver relied on the default
	behaviour of the kernel core remoteproc [2].  That default is to zero
	out the loadable memory regions not backed by file storage (i.e. the
	bss sections).  This worked for the libgloss' CRT0.

	But the PRU loader merged in mainline Linux explicitly changes the
	default behaviour [3].  It no longer is zeroing out memory regions.
	Hence the bss sections are not initialized - neither by CRT0, nor by the
	host loader.

	This patch fixes the issue by aligning the GNU LD default linker script
	with the mainline Linux kernel expectation.  Since the mainline kernel
	driver is submitted by the PRU manufacturer itself (Text Instruments),
	we can consider that as defining the ABI.

	This change has been tested on Beaglebone AI-64 [4].  Static counter
	variables in the firmware are now always starting from zero, as
	expected.  There was only one new toolchain test failure in orphan3.d,
	due to reordering of the output sections.  I believe this is a harmless
	issue.  I could not rewrite the PASS criteria to ignore the output
	section ordering, so I have disabled that test case for PRU.

	[1] https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=libgloss/pru/crt0.S;h=b3f0d53a93acc372f461007553e7688ca77753c9;hb=HEAD#l40
	[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/remoteproc_elf_loader.c?h=v6.1#n228
	[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n641
	[4] https://beagleboard.org/ai-64

	ld/ChangeLog:

		* scripttempl/pru.sc (.data): Merge .bss input sections into the
		.data output section.
		* testsuite/ld-elf/orphan3.d: Disable for PRU.

2023-02-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-03  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

	bpf: fix error conversion from long unsigned int to unsigned int [-Werror=overflow]
	Regenerating BPF target using the maintainer mode emits:
	.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
	  57 |   64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }

	The use of a narrow size to handle the mask CGEN in instruction format
	is causing this error.  Additionally eBPF `call' instructions
	constructed by expressions using symbols (BPF_PSEUDO_CALL) emits
	annotations in `src' field of the instruction, used to identify BPF
	target endianness.

	cpu/
		* bpf.cpu (define-call-insn): Remove `src' field from
		instruction mask.

	include/
		*opcode/cge.h (CGEN_IFMT): Adjust mask bit width.

	opcodes/
		* bpf-opc.c: Regenerate.

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make target_desc_info_from_user_p a method of target_desc_info
	Move the implementation over to target_desc_info.  Remove the
	target_desc_info forward declaration in target-descriptions.h, it's no
	longer needed.

	Change-Id: Ic95060341685afe0b73af591ca6efe32f5e7e892

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove copy_inferior_target_desc_info
	This function is now trivial, we can just copy inferior::tdesc_info
	where needed.

	Change-Id: I25185e2cd4ba1ef24a822d9e0eebec6e611d54d6

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove get_tdesc_info
	Remove this function, since it's now a trivial access to
	inferior::tdesc_info.

	Change-Id: I3e88a8214034f1a4163420b434be11f51eef462c

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: change inferior::tdesc_info to non-pointer
	I initially made this field a unique pointer, to have automatic memory
	management.  But I then thought that the field didn't really need to be
	allocated separately from struct inferior.  So make it a regular
	non-pointer field of inferior.

	Remove target_desc_info_free, as it's no longer needed.

	Change-Id: Ica2b97071226f31c40e86222a2f6922454df1229

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move target_desc_info to inferior.h
	In preparation for the following patch, where struct inferior needs to
	"see" struct target_desc_info, move target_desc_info to the header file.

	I initially moved the structure to target-descriptions.h, and later made
	inferior.h include target-descriptions.h.  This worked, but it then
	occured to me that target_desc_info is really an inferior property that
	involves a target description, so I think it makes sense to have it in
	inferior.h.

	Change-Id: I3e81d04faafcad431e294357389f3d4c601ee83d

2023-02-03  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: use assignment to initialize variable in tdesc_parse_xml
	Since allocate_target_description returns a target_desc_up, use
	assignment to initialize the description variable.

	Change-Id: Iab3311642c09b95648984f305936f4a4cde09440

2023-02-03  Jan Beulich  <jbeulich@suse.com>

	x86: drop LOCK from XCHG when optimizing
	Like with segment overrides on LEA, optimize away such a redundant
	instruction prefix.

	x86-64: respect {nooptimize} when building VEX prefix
	Swapping operands for commutative insns occurs outside of
	optimize_encoding() and hence needs explicit checking for a request to
	avoid any optimizations.

	x86: respect {nooptimize} for LEA
	Dropping a meaningless segment prefix occurs outside of
	optimize_encoding() and hence needs explicit checking for a request to
	avoid any optimizations.

	x86-64: respect MOVABS when choosing alternative encodings
	The alternative encoding is valid for MOV, but there's no such thing for
	MOVABS.

	RISC-V: don't disassemble unrecognized insns as .byte
	Insn width granularity being 16 bits, producing byte granular output
	isn't very useful. With there being a way to specific otherwise
	unknown insns to the assembler, use that same representation (to be
	precise: its <length>,<encoding> flavor) for disassembly.

2023-02-03  Alan Modra  <amodra@gmail.com>

	Add ECOFF Symbolic Header sanity checks
	Anti-fuzzer measures.  The checks don't ensure the various elements in
	the header are distinct, but that isn't important as far as making
	sure we don't overrun the buffer containing all the elements.  Also,
	we now don't care about offsets where the corresponding count is zero.

		* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Sanity check offsets
		in debug->symbolic_header.

2023-02-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-02  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: initial support for ROCm platform (AMDGPU) debugging
	This patch adds the foundation for GDB to be able to debug programs
	offloaded to AMD GPUs using the AMD ROCm platform [1].  The latest
	public release of the ROCm release at the time of writing is 5.4, so
	this is what this patch targets.

	The ROCm platform allows host programs to schedule bits of code for
	execution on GPUs or similar accelerators.  The programs running on GPUs
	are typically referred to as `kernels` (not related to operating system
	kernels).

	Programs offloaded with the AMD ROCm platform can be written in the HIP
	language [2], OpenCL and OpenMP, but we're going to focus on HIP here.
	The HIP language consists of a C++ Runtime API and kernel language.
	Here's an example of a very simple HIP program:

	    #include "hip/hip_runtime.h"
	    #include <cassert>

	    __global__ void
	    do_an_addition (int a, int b, int *out)
	    {
	      *out = a + b;
	    }

	    int
	    main ()
	    {
	      int *result_ptr, result;

	      /* Allocate memory for the device to write the result to.  */
	      hipError_t error = hipMalloc (&result_ptr, sizeof (int));
	      assert (error == hipSuccess);

	      /* Run `do_an_addition` on one workgroup containing one work item.  */
	      do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr);

	      /* Copy result from device to host.  Note that this acts as a synchronization
	         point, waiting for the kernel dispatch to complete.  */
	      error = hipMemcpyDtoH (&result, result_ptr, sizeof (int));
	      assert (error == hipSuccess);

	      printf ("result is %d\n", result);
	      assert (result == 3);

	      return 0;
	    }

	This program can be compiled with:

	    $ hipcc simple.cpp -g -O0 -o simple

	... where `hipcc` is the HIP compiler, shipped with ROCm releases.  This
	generates an ELF binary for the host architecture, containing another
	ELF binary with the device code.  The ELF for the device can be
	inspected with:

	    $ roc-obj-ls simple
	    1       host-x86_64-unknown-linux                                           file://simple#offset=8192&size=0
	    1       hipv4-amdgcn-amd-amdhsa--gfx906                                     file://simple#offset=8192&size=34216
	    $ roc-obj-extract 'file://simple#offset=8192&size=34216'
	    $ file simple-offset8192-size34216.co
	    simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped
	                                                                                 ^
	                       amcgcn architecture that my `file` doesn't know about ----´

	Running the program gives the very unimpressive result:

	    $ ./simple
	    result is 3

	While running, this host program has copied the device program into the
	GPU's memory and spawned an execution thread on it.  The goal of this
	GDB port is to let the user debug host threads and these GPU threads
	simultaneously.  Here's a sample session using a GDB with this patch
	applied:

	    $ ./gdb -q -nx --data-directory=data-directory ./simple
	    Reading symbols from ./simple...
	    (gdb) break do_an_addition
	    Function "do_an_addition" not defined.
	    Make breakpoint pending on future shared library load? (y or [n]) y
	    Breakpoint 1 (do_an_addition) pending.
	    (gdb) r
	    Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
	    [Thread debugging using libthread_db enabled]
	    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
	    [New Thread 0x7ffff5db7640 (LWP 1082911)]
	    [New Thread 0x7ffef53ff640 (LWP 1082913)]
	    [Thread 0x7ffef53ff640 (LWP 1082913) exited]
	    [New Thread 0x7ffdecb53640 (LWP 1083185)]
	    [New Thread 0x7ffff54bf640 (LWP 1083186)]
	    [Thread 0x7ffdecb53640 (LWP 1083185) exited]
	    [Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0]

	    Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
	    24        *out = a + b;
	    (gdb) info inferiors
	      Num  Description       Connection           Executable
	    * 1    process 1082907   1 (native)           /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
	    (gdb) info threads
	      Id   Target Id                                    Frame
	      1    Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1
	      2    Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
	      5    Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
	    * 6    AMDGPU Wave 2:2:1:1 (0,0,0)/0                do_an_addition (
	        a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
	    (gdb) bt
	    Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1
	    #0  do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
	        out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
	    (gdb) continue
	    Continuing.
	    result is 3
	    warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208"
	    [Thread 0x7ffff54bf640 (LWP 1083186) exited]
	    [Thread 0x7ffff5db7640 (LWP 1082911) exited]
	    [Inferior 1 (process 1082907) exited normally]

	One thing to notice is the host and GPU threads appearing under
	the same inferior.  This is a design goal for us, as programmers tend to
	think of the threads running on the GPU as part of the same program as
	the host threads, so showing them in the same inferior in GDB seems
	natural.  Also, the host and GPU threads share a global memory space,
	which fits the inferior model.

	Another thing to notice is the error messages when trying to read
	variables or printing a backtrace.  This is expected for the moment,
	since the AMD GPU compiler produces some DWARF that uses some
	non-standard extensions:

	  https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html

	There were already some patches posted by Zoran Zaric earlier to make
	GDB support these extensions:

	  https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/

	We think it's better to get the basic support for AMD GPU in first,
	which will then give a better justification for GDB to support these
	extensions.

	GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware
	thread using the SIMT (single-instruction, multiple-threads) [3]
	execution model.

	GDB uses the amd-dbgapi library [4], included in the ROCm platform, for
	a few things related to AMD GPU threads debugging.  Different components
	talk to the library, as show on the following diagram:

	    +---------------------------+     +-------------+     +------------------+
	    | GDB   | amd-dbgapi target | <-> |     AMD     |     |    Linux kernel  |
	    |       +-------------------+     |   Debugger  |     +--------+         |
	    |       | amdgcn gdbarch    | <-> |     API     | <=> | AMDGPU |         |
	    |       +-------------------+     |             |     | driver |         |
	    |       | solib-rocm        | <-> | (dbgapi.so) |     +--------+---------+
	    +---------------------------+     +-------------+

	  - The amd-dbgapi target is a target_ops implementation used to control
	    execution of GPU threads.  While the debugging of host threads works
	    by using the ptrace / wait Linux kernel interface (as usual), control
	    of GPU threads is done through a special interface (dubbed `kfd`)
	    exposed by the `amdgpu` Linux kernel module.  GDB doesn't interact
	    directly with `kfd`, but instead goes through the amd-dbgapi library
	    (AMD Debugger API on the diagram).

	    Since it provides execution control, the amd-dbgapi target should
	    normally be a process_stratum_target, not just a target_ops.  More
	    on that later.

	  - The amdgcn gdbarch (describing the hardware architecture of the GPU
	    execution units) offloads some requests to the amd-dbgapi library,
	    so that knowledge about the various architectures doesn't need to be
	    duplicated and baked in GDB.  This is for example for things like
	    the list of registers.

	  - The solib-rocm component is an solib provider that fetches the list of
	    code objects loaded on the device from the amd-dbgapi library, and
	    makes GDB read their symbols.  This is very similar to other solib
	    providers that handle shared libraries, except that here the shared
	    libraries are the pieces of code loaded on the device.

	Given that Linux host threads are managed by the linux-nat target, and
	the GPU threads are managed by the amd-dbgapi target, having all threads
	appear in the same inferior requires the two targets to be in that
	inferior's target stack.  However, there can only be one
	process_stratum_target in a given target stack, since there can be only
	one target per slot.  To achieve it, we therefore resort the hack^W
	solution of placing the amd-dbgapi target in the arch_stratum slot of
	the target stack, on top of the linux-nat target.  Doing so allows the
	amd-dbgapi target to intercept target calls and handle them if they
	concern GPU threads, and offload to beneath otherwise.  See
	amd_dbgapi_target::fetch_registers for a simple example:

	    void
	    amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno)
	    {
	      if (!ptid_is_gpu (regcache->ptid ()))
	        {
	          beneath ()->fetch_registers (regcache, regno);
	          return;
	        }

	      // handle it
	    }

	ptids of GPU threads are crafted with the following pattern:

	  (pid, 1, wave id)

	Where pid is the inferior's pid and "wave id" is the wave handle handed
	to us by the amd-dbgapi library (in practice, a monotonically
	incrementing integer).  The idea is that on Linux systems, the
	combination (pid != 1, lwp == 1) is not possible.  lwp == 1 would always
	belong to the init process, which would also have pid == 1 (and it's
	improbable for the init process to offload work to the GPU and much less
	for the user to debug it).  We can therefore differentiate GPU and
	non-GPU ptids this way.  See ptid_is_gpu for more details.

	Note that we believe that this scheme could break down in the context of
	containers, where the initial process executed in a container has pid 1
	(in its own pid namespace).  For instance, if you were to execute a ROCm
	program in a container, then spawn a GDB in that container and attach to
	the process, it will likely not work.  This is a known limitation.  A
	workaround for this is to have a dummy process (like a shell) fork and
	execute the program of interest.

	The amd-dbgapi target watches native inferiors, and "attaches" to them
	using amd_dbgapi_process_attach, which gives it a notifier fd that is
	registered in the event loop (see enable_amd_dbgapi).  Note that this
	isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached
	is a precondition for amd_dbgapi_process_attach to work.  When the
	debugged process enables the ROCm runtime, the amd-dbgapi target gets
	notified through that fd, and pushes itself on the target stack of the
	inferior.  The amd-dbgapi target is then able to intercept target_ops
	calls.  If the debugged process disables the ROCm runtime, the
	amd-dbgapi target unpushes itself from the target stack.

	This way, the amd-dbgapi target's footprint stays minimal when debugging
	a process that doesn't use the AMD ROCm platform, it does not intercept
	target calls.

	The amd-dbgapi library is found using pkg-config.  Since enabling
	support for the amdgpu architecture (amdgpu-tdep.c) depends on the
	amd-dbgapi library being present, we have the following logic for
	the interaction with --target and --enable-targets:

	 - if the user explicitly asks for amdgcn support with
	   --target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for
	   the amd-dbgapi and fail if not found

	 - if the user uses --enable-targets=all, we probe for amd-dbgapi,
	   enable amdgcn support if found, disable amdgcn support if not found

	 - if the user uses --enable-targets=all and --with-amd-dbgapi=yes,
	   we probe for amd-dbgapi, enable amdgcn if found and fail if not found

	 - if the user uses --enable-targets=all and --with-amd-dbgapi=no,
	   we do not probe for amd-dbgapi, disable amdgcn support

	 - otherwise, amd-dbgapi is not probed for and support for amdgcn is not
	   enabled

	Finally, a simple test is included.  It only tests hitting a breakpoint
	in device code and resuming execution, pretty much like the example
	shown above.

	[1] https://docs.amd.com/category/ROCm_v5.4
	[2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4
	[3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads
	[4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4

	Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee
	Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com>
	Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
	Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
	Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
	Co-Authored-By: Pedro Alves <pedro@palves.net>

2023-02-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make gdb_printing_disassembler::stream public
	In the ROCm port, we need to access the underlying stream of a
	gdb_printing_disassembler, so make it public.  The reason we need to
	access it is to know whether it supports style escape code.  We then
	pass that information to a temporary string_file we use while
	symbolizing addresses.

	Change-Id: Ib95755a4a45b8f6478787993e9f904df60dd8dc1
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb/solib-svr4: don't disable probes interface if probe not found
	In ROCm-GDB, we install an solib provider for the GPU code objects on
	top of the svr4 provider for the host, in order to add solibs
	representing the GPU code objects to the solib list containing the host
	process' shared libraries.  We override the target_so_ops::handle_event
	function pointer with our own, in which we call svr4_so_ops.handle_event
	(which contains svr4_handle_solib_event) manually.  When the host
	(un)loads a library, the ROCm part of handle_event is a no-op.  When the
	GPU (un)loads a code object, we want the host side (svr4) to be a no-op.

	The problem is that when handle_event is called because of a GPU event,
	svr4_handle_solib_event gets called while not stopped at an svr4
	probe.  It then assumes this means there's a problem with the probes
	interface and disables it through the following sequence of events:

	  - solib_event_probe_at return nullptr
	  - svr4_handle_solib_event returns early
	  - the make_scope_exit callback calls disable_probes_interface

	We could fix that by making the ROCm handle_event callback check if an
	svr4 probe is that the stop address, and only call
	svr4_so_ops.handle_event if so.  However, it doesn't feel right to
	include some svr4 implementation detail in the ROCm event handler.

	Instead, this patch changes svr4_handle_solib_event to not assume it is
	an error if called while not at an svr4 probe location, and therefore
	not disable the probes interface.  That just means moving the
	make_scope_exit call below where we lookup the probe by pc.

	Change-Id: Ie8ddf5beffa2e92b8ebfdd016454546252519244
	Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>

2023-02-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add gdbarch_up
	Add a gdbarch_up unique pointer type, that calls gdbarch_free on
	deletion.  This is used in the ROCm support patch at the end of this
	series.

	Change-Id: I4b808892d35d69a590ce83180f41afd91705b2c8
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add inferior_pre_detach observable
	Add an observable notified in target_detach just before calling the
	detach method on the inferior's target stack.  This allows observer to
	do some work on the inferior while it's still ptrace-attached, in the
	case of a native Linux inferior.  Specifically, the amd-dbgapi target
	will need it in order to call amd_dbgapi_process_detach before the
	process gets ptrace-detached.

	Change-Id: I28b6065e251012a4c2db8a600fe13ba31671e3c9
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: add type definitions for pid, lwp and tid
	A following patch will want to declare variables of the same type as
	some ptid_t components.  To make that easy (and avoid harcoding those
	types everywhere), define some type definitions in the ptid_t struct for
	each of them.  Use them throughout ptid.h.

	I initially used pid_t, lwp_t and tid_t, but there is the risk of some
	system defining the pid_t type using a macro instead of a typedef, which
	would break things.  So, use the _type suffix instead.

	Change-Id: I820b0bea9dafcb4914f1c9ba4bb96b5c666c8dec
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Pedro Alves  <pedro@palves.net>

	gdb: make install_breakpoint return a non-owning reference
	A following patch will want to install a breakpoint and then keep a
	non-owning reference to it.  Make install_breakpoint return a non-owning
	reference, to make that easy.

	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I2e8106a784021ff276ce251e24708cbdccc2d479
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Lancelot SIX  <lancelot.six@amd.com>

	gdb: add supports_arch_info callback to gdbarch_register
	In the ROCm GDB port, there are some amdgcn architectures known by BFD
	that we don't actually support in GDB.  We don't want
	gdbarch_printable_names to return these architectures.

	gdbarch_printable_names is used for a few things:

	 - completion of the "set architecture" command
	 - the gdb.architecture_names function in Python
	 - foreach-arch selftests

	Add an optional callback to gdbarch_register that is a predicate
	indicating whether the gdbarch supports the given bfd_arch_info.  by
	default, it is nullptr, meaning that the gdbarch accepts all "mach"s for
	that architecture known by BFD.

	Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860
	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-02-02  Tom de Vries  <tdevries@suse.de>

	[gas] Update .loc syntax comment in dwarf2dbg.c
	I noticed that a comment in gas/dwarf2dbg.c describing .loc syntax was missing
	the "view VALUE" option.

	Fix this by adding the missing option.

2023-02-02  Enze Li  <enze.li@hotmail.com>

	gdb: remove gdb_indent.sh
	GDB has been converted to a C++ program for many years[1], and the
	gdb_indent.sh will not be used any more. Therefore, remove the script as
	obvious.

	[1] https://sourceware.org/gdb/wiki/cxx-conversion

	Approved-By: Simon Marchi <simark@simark.ca>

2023-02-02  Indu Bhagat  <indu.bhagat@oracle.com>

	ld/doc: use "stack trace" instead of "unwind" for SFrame
	SFrame format is meant for generating stack traces only.

	ld/
		* ld.texi: Replace the use of "unwind" with "stack trace".

2023-02-02  Indu Bhagat  <indu.bhagat@oracle.com>

	bfd: use "stack trace" instead of "unwind" for SFrame
	SFrame format is meant for generating stack traces only.

	bfd/
		* elf-bfd.h: Replace the use of "unwind" with "stack trace".
		* elf-sframe.c: Likewise.
		* elf64-x86-64.c: Likewise.
		* elfxx-x86.c: Likewise.

	include/
		* elf/common.h: Likewise.

2023-02-02  Indu Bhagat  <indu.bhagat@oracle.com>

	gas: use "stack trace" instead of "unwind" for SFrame
	SFrame format is meant for generating stack traces only.

	gas/
		* as.c: Replace the use of "unwind" with "stack trace".
		* config/tc-aarch64.c: Likewise.
		* config/tc-aarch64.h: Likewise.
		* config/tc-i386.c: Likewise.
		* config/tc-i386.h: Likewise.
		* gen-sframe.c: Likewise.
		* gen-sframe.h: Likewise.
		* testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise.
		* testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise.
		* testsuite/gas/cfi-sframe/common-empty-2.s: Likewise.
		* testsuite/gas/cfi-sframe/common-empty-3.s: Likewise.

2023-02-02  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: use "stack trace" instead of "unwind" for SFrame
	SFrame format is meant for generating stack traces only.

	include/
		* sframe.h: Fix comments in the header file.

2023-02-02  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe/doc: use "stack trace" instead of "unwind" for SFrame
	SFrame format is meant for generating stack traces only.

	libsframe/
		* doc/sframe-spec.texi: Use "stack trace" instead of "unwind".

2023-02-02  Alan Modra  <amodra@gmail.com>

	ld-elf/merge test update
	The merge test fais on numerous targets because they don't support the
	necessary pc-relative relocs.  This patch removes that part of the
	merge test, and makes references to the merged strings from .data
	rather than .text to better support targets that relax text by
	default.

2023-02-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-02-01  Alan Modra  <amodra@gmail.com>

	obj-elf.h BYTES_IN_WORD
	Don't define this.  It is defined just before elf-bfd.h is included,
	but doesn't have any relevance there.  Instead is for aout64.h where
	the default is 4 anyway.

2023-02-01  Alan Modra  <amodra@gmail.com>

	gas obj_end
	Provide a way for config/obj-* to clean up at end of assembly, and do
	so for ELF.

		* obj.h (struct format_ops): Add "end".
		* config/obj-aout.c (aout_format_ops): Init new field.
		* config/obj-coff.c (coff_format_ops): Likewise.
		* config/obj-ecoff.c (ecoff_format_ops): Likewise.
		* config/obj-elf.c (elf_format_ops): Likewise.
		(elf_begin): Move later in file.  Clear some more variables.
		(comment_section): Make file scope.
		(free_section_idx): Rewrite.
		(elf_adjust_symtab): Expand str_htab_create call and use
		free_section_idx as delete function.
		(elf_frob_file_after_relocs): Don't clean up groups.indexes here.
		(elf_end): New function.
		* config/obj-elf.h (obj_end): Define.
		* config/obj-multi.h (obj_end): Define.
		* output-file.c (output_file_close): Call obj_end.

2023-02-01  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap
	This patch doesn't change gdbserver behaviour, but after later changes are
	made it avoids a null pointer dereference when HWCAP needs to be obtained
	for a specific process while current_thread is nullptr.

	Fixing linux_read_auxv, linux_get_hwcap and linux_get_hwcap2 to take a PID
	parameter seems more correct than setting current_thread in one particular
	code path.

	Changes are propagated to allow passing the new parameter through the call
	chain.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-01  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdbserver: Add assert in find_register_by_number
	It helped me during development, catching bugs closer to when they actually
	happened.

	Also remove the equivalent gdb_assert in regcache_raw_read_unsigned, since
	it's checking the same condition a few frames above.

	Suggested-By: Simon Marchi <simon.marchi@efficios.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-02-01  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix fetch_src_and_symbols.exp with native-gdbserver board
	I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp script
	doesn't work with the native-gdbserver board, I see this error:

	  ERROR: tcl error sourcing /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
	  ERROR: gdbserver does not support run without extended-remote
	      while executing
	  "error "gdbserver does not support $command without extended-remote""
	      (procedure "gdb_test_multiple" line 51)
	      invoked from within

	This was introduced with this commit:

	  commit 7dd38e31d67c2548b52bea313ab18e40824c05da
	  Date:   Fri Jan 6 18:45:27 2023 -0500

	      gdb/linespec.c: Fix missing source file during breakpoint re-set

	The problem is that the above commit introduces a direct use of the
	"run" command, which doesn't work with 'target remote' targets, as
	exercised by the native-gdbserver board.

	To avoid this, in this commit I switch to using runto_main.  However,
	calling runto_main will, by default, delete all the currently set
	breakpoints.  As the point of the above commit was to check that a
	breakpoint set before stating an inferior would be correctly re-set,
	we need to avoid this breakpoint deleting behaviour.

	To do this I make use of with_override, and override the
	delete_breakpoints proc with a dummy proc which does nothing.

	By reverting the GDB changes in commit 7dd38e31d67c I have confirmed
	that even after my changes in this commit, the test still fails.  But
	with the fixes in commit 7dd38e31d67c, this test now passed using the
	unix, native-gdbserver, and native-extended-gdbserver boards.

2023-02-01  Alexandra Hájková  <ahajkova@redhat.com>

	gdb: defer warnings when loading separate debug files
	Currently, when GDB loads debug information from a separate debug
	file, there are a couple of warnings that could be produced if things
	go wrong.

	In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
	warning if the separate debug file doesn't include any actual debug
	information, and in separate_debug_file_exists (symfile.c) we can warn
	if the CRC checksum in the separate debug file doesn't match the
	checksum in the original executable.

	The problem here is that, when looking up debug information, GDB will
	try several different approaches, lookup by build-id, lookup by
	debug-link, and then a lookup from debuginfod.  GDB can potentially
	give a warning from an earlier attempt, and then succeed with a later
	attempt.  In the cases I have run into this is primarily a warning
	about some out of date debug information on my machine, but then GDB
	finds the correct information using debuginfod.  This can be confusing
	to a user, they will see warnings from GDB when really everything is
	working just fine.

	For example:

	  warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
	      does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

	This diagnostic was printed on Fedora 33 even when the correct
	debuginfo was downloaded.

	In this patch I propose that we defer any warnings related to looking
	up debug information from a separate debug file.  If any of the
	approaches are successful then GDB will not print any of the warnings.
	As far as the user is concerned, everything "just worked".  Only if
	GDB completely fails to find any suitable debug information will the
	warnings be printed.

	The crc_mismatch test compiles two executables: crc_mismatch and
	crc_mismatch-2 and then strips them of debuginfo creating separate
	debug files. The test then replaces crc_mismatch-2.debug with
	crc_mismatch.debug to trigger "CRC mismatch" warning. A local
	debuginfod server is setup to supply the correct debug file, now when
	GDB looks up the debug info no warning is given.

	The build-id-no-debug-warning.exp is similar to the previous test. It
	triggers the "separate debug info file has no debug info" warning by
	replacing the build-id based .debug file with the stripped binary and
	then loading it to GDB.  It then also sets up local debuginfod server
	with the correct debug file to download to make sure no warnings are
	emitted.

2023-02-01  Nick Clifton  <nickc@redhat.com>

	Fix compilation of the assembler with sanitization enabled.
	  * dwarf2dbg.c (emit_inc_line_addr): Use unsigned constants when checking addr_delta.

2023-02-01  Alan Modra  <amodra@gmail.com>

	Recursion in as_info_where
	This function has a gas_assert, ie. possible call to as_abort, which
	calls as_report_context, which calls as_info_where.

		* messages.c (as_info_where): Don't gas_assert.

2023-02-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename cooked_index_vector to cooked_index
	See previous patch's commit message for rationale.

	Change-Id: I6b8cdc045dffccc1c01ed690ff258af09f6ff076
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-01  Simon Marchi  <simon.marchi@efficios.com>

	gdb/dwarf: rename cooked_index to cooked_index_shard
	I propose to rename cooked_index_vector and cooked_index such that the
	"main" object, that is the entry point to the index, is called
	cooked_index.  The fact that the cooked index is implemented as a vector
	of smaller indexes is an implementation detail.

	This patch renames cooked_index to cooked_index_shard.  The following
	patch renames cooked_index_vector to cooked_index.

	Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177
	Approved-By: Tom Tromey <tom@tromey.com>

2023-02-01  Tom de Vries  <tdevries@suse.de>

	[gas] Emit v2 .debug_line for -gdwarf-2
	Currently, when using -gdwarf-2, gas emits a v3 .debug_line contribution.

	Fix this by emitting a v2 .debug_line contribution instead.

	gas/ChangeLog:

	2023-01-31  Tom de Vries  <tdevries@suse.de>

		PR 23941
		* dwarf2dbg.c (DWARF2_LINE_VERSION): Set to 2 for -gdwarf-2.
		(DWARF2_LINE_OPCODE_BASE): Handle DWARF2_LINE_VERSION == 2.
		(dwarf2_directive_loc): Bump dwarf_level when encountering
		v3 .loc options.
		(out_debug_line): Don't output v3 standard opcodes for v2.
		* testsuite/gas/i386/debug1.d: Update.
		* testsuite/gas/i386/dwarf2-line-1.d: Update.
		* testsuite/gas/i386/dwarf2-line-4.d: Update.

2023-02-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-31  Simon Marchi  <simon.marchi@efficios.com>

	gdb: add nullptr check to cooked_index_functions::dump
	Since commit 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in
	cooked_index_functions::dump"), we see:

	    maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error^M
	    ^M
	    Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error:  Objfile at 0x614000005040, bfd at 0x6120000e08c0, 15 minsyms^M
	    ^M
	    Cooked index in use:^M
	    ^M
	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb-checked-static-cast.h:58: internal-error: checked_static_cast: Assertion `result != nullptr' failed.^M
	    A problem internal to GDB has been detected,^M
	    further debugging may prove unreliable.^M
	    ----- Backtrace -----^M
	    FAIL: gdb.dwarf2/dw2-error.exp: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error (GDB internal error)

	The problem is that when cooked_index_functions fails to build an index,
	per_objfile->index_table is nullptr.  Therefore, add a nullptr check,
	like other methods of cooked_index_functions already do.

	Print the "Cooked index in use" message after the nullptr check, such
	that if the cooked index failed to build, that message is not printed.

	Change-Id: Id67aef592e76c41b1e3bde9838a4e36cef873253

2023-01-31  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: allow passing nullptr to checked_static_cast
	Both static_cast and dynamic_cast handle nullptr (they return nullptr),
	so I think checked_static_cast should too.  This will allow doing a null
	check after a checked_static_cast:

	  cooked_index_vector *table
	    = (gdb::checked_static_cast<cooked_index_vector *>
	       (per_bfd->index_table.get ()));
	  if (table != nullptr)
	    return;

	Change-Id: If5c3134e63696f8e417c87b5f3901240c9f7ea97

2023-01-31  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: adjust ensure_gdb_index to cooked_index_functions::dump changes
	Following 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in
	cooked_index_functions::dump"), I see some failures like:

	    (gdb) mt print objfiles with-mf^M
	    ^M
	    Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/with-mf/with-mf:  Objfile at 0x614000005040, bfd at 0x6120000e08c0, 18 minsyms    ^M
	    ^M
	    Cooked index in use:^M
	    ^M
	    ...
	    (gdb) FAIL: gdb.base/with-mf.exp: check if index present

	This is because the format of the "Cooked index in use" line changed
	slightly.  Adjust ensure_gdb_index to expect the trailing colon.

	Change-Id: If0a87575c02d8a0bc0d4b8ead540c234c62760f8

2023-01-31  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: fix xfail in gdb.ada/ptype_tagged_param.exp
	I see:

	    ERROR: wrong # args: should be "xfail message"
	        while executing
	    "xfail "no debug info" $gdb_test_name"
	        ("uplevel" body line 3)
	        invoked from within
	    "uplevel {
	            if {!$has_runtime_debug_info} {
	                xfail "no debug info" $gdb_test_name
	            } else {
	                fail $gdb_test_name
	            }
	        }"

	This is because the xfail takes only one argument, fix that.

	Change-Id: I2e304d4fd3aa61067c04b5dac2be2ed34dab3190

2023-01-31  Nick Clifton  <nickc@redhat.com>

	Updated Swedish translation for the binutils sub-directory

2023-01-31  Alan Modra  <amodra@gmail.com>

	Re: Another fix for EFI generation with LTO enabled
	Revert 1c66b8a03989 and instead fix the broken list pointer.

		PR 29998
		* pe-dll.c (build_filler_bfd): Revert last change.
		* ldlang.c (lang_process): When rescanning archives for lto,
		fix file_chain.tail pointer if the insert point happens to be
		at the end of the list.

2023-01-31  Andrew Burgess  <aburgess@redhat.com>

	gas/ppc: Additional tests for DFP instructions
	I noticed that some of the Power6 DFP instructions were not covered by
	the assembler tests.  I've added a new test file which I believe
	covers all the DFP Power6 instructions.

	The existing gas/testsuite/gas/ppc/power6.d test is called:

	  POWER6 tests (includes DFP and Altivec)

	And does cover some of the DFP instructions.  But, given the number of
	additional instructions I'm adding I opted to add a whole new test
	file.  I've left the original power6.d unchanged, so there is now some
	overlap, but I don't think that should hurt much.

2023-01-31  Jan Beulich  <jbeulich@suse.com>

	RISC-V: make C-extension JAL available again for (32-bit) assembly
	Along with the normal JAL alias, the C-extension one should have been
	moved as well by 839189bc932e ("RISC-V: re-arrange opcode table for
	consistent alias handling"), for the assembler to actually be able to
	use it where/when possible.

	Since neither this nor any other compressed branch insn was being tested
	so far, take the opportunity and introduce a new testcase covering those.

2023-01-31  Alan Modra  <amodra@gmail.com>

	Silence ubsan warning about 1<<31
		* merge.c (hash_blob): Write 1u << 31.

2023-01-31  Alan Modra  <amodra@gmail.com>

	PR 30060, ASAN error in bfd_cache_close
	After bfd_close nothing should access bfd memory.  Now that bfd_close
	always tidies up even after an error, attempting to tidy the cached
	bfd list by calling bfd_cache_close is wrong and not needed.

		PR 30060
		* ar.c (remove_output): Don't call bfd_cache_close.
		(output_bfd): Delete.
		* arsup.c (ar_end): Call bfd_close_all_done, not bfd_cache_close.

2023-01-31  Alan Modra  <amodra@gmail.com>

	testsuite XPASSes
	This adjusts the testsuite to get rid of a number of XPASSes that have
	appeared.  Someone might like to look into a better patch for the s390
	change.

	aarch64-pe  XPASS: weak symbols
	arm-nacl  XPASS: rgn-over8
	mcore-pe  XPASS: ld-scripts/provide-8
	mips64-linux-gnuabi64  XPASS: vers4
	mips64-linux-gnuabi64  XPASS: vers4b
	mips-linux-gnu  XPASS: vers4
	mips-linux-gnu  XPASS: vers4b
	s390-linux-gnu  XPASS: undefined line
	sh4-linux-gnu  XPASS: --gc-sections with __start_SECTIONNAME
	sh-coff  XPASS: objcopy object (simple copy)
	sh-coff  XPASS: objcopy executable (pr25662)

	binutils/
		* testsuite/binutils-all/objcopy.exp: Don't xfail "simple
		copy" and "pr25662" on sh-*-coff.  Remove all non-ELF xfails
		on "ELF unknown section type" test.
	ld/
		* testsuite/ld-elfvers/vers.exp (vers4, vers4b): Don't xfail
		all mips, just xfail mips irix.
		* testsuite/ld-gc/pr19161.d: Don't xfail sh.
		* testsuite/ld-scripts/rgn-over8-ok.d: Don't xfail nacl.
		* testsuite/ld-scripts/weak.exp: Don't xfail aarch64-pe.
		* testsuite/ld-undefined/undefined.exp: Conditionally xfail
		"undefined line" depending on gcc version for s390.

2023-01-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-30  Tom Tromey  <tom@tromey.com>

	Remove value_next declaration
	value_next is declared but not defined.  It's long obsolete.  This
	patch removes the stray declaration.

2023-01-30  Simon Marchi  <simon.marchi@efficios.com>

	gdb: fix dwarf2/cooked-index.c compilation on 32-bit systems
	The i386 builder shows:

	    ../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’:
	    ../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=]
	      492 |       gdb_printf ("    DIE offset: 0x%lx\n",
	          |                                      ~~^
	          |                                        |
	          |                                        long unsigned int
	          |                                      %llx
	      493 |     to_underlying (entry->die_offset));
	          |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	          |                   |
	          |                   std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int}

	The die_offset's underlying type is uint64, so use PRIx64 in the format
	string.

	Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323

2023-01-30  Mark Wielaard  <mark@klomp.org>

	gdb: Replace memcpy with std::copy to avoid some g++ warnings on sparc
	For some reason g++ 12.2.1 on sparc produces spurious warnings for
	stringop-overread and restrict in fbsd-tdep.c for a memcpy call.
	Use std::copy to avoid the warnings:

	In function ‘void* memcpy(void*, const void*, size_t)’,
	    inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:666:10:
	/usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified bound 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]

	In function ‘void* memcpy(void*, const void*, size_t)’,
	    inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:673:10:
	/usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744073709551612 bytes at offsets 0 and 0 overlaps 9223372036854775801 bytes at offset -9223372036854775805 [-Werror=restrict]

	gdb/ChangeLog:

		* fbsd-tdep.c (fbsd_make_note_desc): Use std::copy instead
		of memcpy.

2023-01-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: dump cooked index contents in cooked_index_functions::dump
	As I am investigating a crash I see with the cooked index, I thought it
	would be useful to have a way to dump the index contents.  For those not
	too familiar with it (that includes me), it can help get a feel of what
	it contains and how it is structured.

	The cooked_index_functions::dump function is called as part of the
	"maintenance print objfiles" command.  I tried to make the output
	well structured and indented to help readability, as this prints a lot
	of text.

	The dump function first dumps all cooked index entries, like this:

	    [25] ((cooked_index_entry *) 0x621000121220)
	    name:       __ioinit
	    canonical:  __ioinit
	    DWARF tag:  DW_TAG_variable
	    flags:      0x2 [IS_STATIC]
	    DIE offset: 0x21a4
	    parent:     ((cooked_index_entry *) 0x6210000f9610) [std]

	Then the information about the main symbol:

	    main: ((cooked_index_entry *) 0x621000123b40) [main]

	And finally the address map contents:

	    [1] ((addrmap *) 0x6210000f7910)

	      [0x0] ((dwarf2_per_cu_data *) 0)
	      [0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00)
	      [0x1cc7] ((dwarf2_per_cu_data *) 0)
	      [0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00)
	      [0x1cdf] ((dwarf2_per_cu_data *) 0)
	      [0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00)

	The display of address maps above could probably be improved, to show it
	more as ranges, but I think this is a reasonable start.

	Note that this patch depends on Pedro Alves' patch "enum_flags
	to_string" [1].  If my patch is to be merged before Pedro's series, I
	will cherry-pick this patch from his series and merge it before mine.

	[1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/

	Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a

2023-01-30  Pedro Alves  <pedro@palves.net>

	enum_flags to_string
	This commit introduces shared infrastructure that can be used to
	implement enum_flags -> to_string functions.  With this, if we want to
	support converting a given enum_flags specialization to string, we
	just need to implement a function that provides the enumerator->string
	mapping, like so:

	 enum some_flag
	   {
	     SOME_FLAG1 = 1 << 0,
	     SOME_FLAG2 = 1 << 1,
	     SOME_FLAG3 = 1 << 2,
	   };

	 DEF_ENUM_FLAGS_TYPE (some_flag, some_flags);

	 static std::string
	 to_string (some_flags flags)
	 {
	   static constexpr some_flags::string_mapping mapping[] = {
	     MAP_ENUM_FLAG (SOME_FLAG1),
	     MAP_ENUM_FLAG (SOME_FLAG2),
	     MAP_ENUM_FLAG (SOME_FLAG3),
	   };
	   return flags.to_string (mapping);
	 }

	.. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like
	"0x6 [SOME_FLAG2 SOME_FLAG3]".

	If we happen to forget to update the mapping array when we introduce a
	new enumerator, then the string representation will pretty-print the
	flags it knows about, and then the leftover flags in hex (one single
	number).  For example, if we had missed mapping SOME_FLAG2 above, we'd
	end up with:

	  to_string(SOME_FLAG2 | SOME_FLAG3)  => "0x6 [SOME_FLAG2 0x4]");

	Other than in the unit tests included, no actual usage of the
	functionality is added in this commit.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>
	Change-Id: I835de43c33d13bc0c95132f42c3f97318b875779

2023-01-30  Tom Tromey  <tromey@adacore.com>

	Fix comparator bug in cooked index
	Simon pointed out that the cooked index template-matching patch
	introduced a failure in libstdc++ debug mode.  In particular, the new
	code violates the assumption of std::lower_bound and std::upper_bound
	that the range is sorted with respect to the comparison.

	When I first debugged this, I thought the problem was unfixable as-is
	and that a second layer of filtering would have to be done.  However,
	on irc, Simon pointed out that it could perhaps be solved if the
	comparison function were assured that one operand always came from the
	index, with the other always being the search string.

	This patch implements this idea.

	First, a new mode is introduced: a sorting mode for
	cooked_index_entry::compare.  In this mode, strings are compared
	case-insensitively, but we're careful to always sort '<' before any
	other printable character.  This way, two names like "func" and
	"func<param>" will be sorted next to each other -- i.e., "func1" will
	not be seen between them.  This is important when searching.

	Second, the compare function is changed to work in a strcmp-like way.
	This makes it easier to test and (IMO) understand.

	Third, the compare function is modified so that in non-sorting modes,
	the index entry is always the first argument.  This allows consistency
	in compares.

	I regression tested this in libstdc++ debug mode on x86-64 Fedora 36.
	It fixes the crash that Simon saw.

	This is v2.  I believe it addresses the review comments, except for
	the 'enum class' change, as I mentioned in email on the list.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-30  Tom Tromey  <tom@tromey.com>

	Clean up lnp_state_machine constructor
	This changes the lnp_state_machine constructor to initialize members
	directly; and changes lnp_state_machine itself to initialize members
	inline when possible.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-01-30  Tom Tromey  <tromey@adacore.com>

	Make addrmap const-correct in cooked index
	After the cooked index is created, the addrmaps should be const.

	Change-Id: I8234520ab346ced40a8dd6e478ba21fc438c2ba2

2023-01-30  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: provide const-correct versions of addrmap::find and addrmap::foreach
	Users of addrmap::find and addrmap::foreach that have a const addrmap
	should ideally receive const pointers to objects, to indicate they
	should not be modified.  However, users that have a non-const addrmap
	should still receive a non-const pointer.

	To achieve this, without adding more virtual methods, make the existing
	find and foreach virtual methods private and prefix them with "do_".
	Add small non-const and const wrappers for find and foreach.

	Obviously, the const can be cast away, but if using static_cast
	instead of C-style casts, then the compiler won't let you cast
	the const away.  I changed all the callers of addrmap::find and
	addrmap::foreach I could find to make them use static_cast.

	Change-Id: Ia8e69d022564f80d961413658fe6068edc71a094

2023-01-30  Tom Tromey  <tromey@adacore.com>

	Use xfail in ptype_tagged_param.exp
	Pedro pointed out that ptype_tagged_param.exp used a kfail, but an
	xfail would be more appropriate as the problem appears to be in gcc,
	not gdb.

2023-01-30  Christina Schimpe  <christina.schimpe@intel.com>

	gdb: Remove workaround for the vCont packet
	The workaround for the vCont packet is no longer required due to the
	former commit "gdb: Make global feature array a per-remote target array".
	The vCont packet is now checked once when the connection is started and
	the supported vCont actions are set to the target's remote state
	attribute.

2023-01-30  Christina Schimpe  <christina.schimpe@intel.com>

	gdb: Add per-remote target variables for memory read and write config
	This patch adds per-remote target variables for the configuration of
	memory read- and write packet size.  It is a further change to commit
	"gdb: Make global feature array a per-remote target array" to apply the
	fixme notes described in commit 5b6d1e4 "Multi-target support".

	The former global variables for that configuration are still available
	to allow the command line configuration for all future remote
	connections.  Similar to the command line configuration of the per-
	remote target feature array, the commands

	- set remotewritesize (deprecated)
	- set remote memory-read-packet-size
	- set remote memory-write-packet-size

	will configure the current target (if available).  If no target is
	available, the default configuration for future remote connections is
	adapted.  The show command will display the current remote target's
	packet size configuration.  If no remote target is selected, the default
	configuration for future connections will be shown.

	It is required to adapt the test gdb.base/remote.exp which is failing
	for --target_board=native-extended-gdbserver.  With that board GDB
	connects to gdbserver at gdb start time.  Due to this patch two loggings
	"The target may not be able to.." are shown if the command 'set remote
	memory-write-packet-size fixed' is executed while a target is connected
	for the current inferior.  To fix this, the clean_restart command is
	moved to a later time point of the test.  It is sufficient to be
	connected to the server when "runto_main" is executed.  Now the
	connection time is similar to a testrun with
	--target_board=native-gdbserver.

	To allow the user to distinguish between the packet-size configuration
	for future remote connections and for the currently selected target, the
	commands' loggings are adapted.

2023-01-30  Christina Schimpe  <christina.schimpe@intel.com>

	gdb: Make global feature array a per-remote target array
	This patch applies the appropriate FIXME notes described in commit 5b6d1e4
	"Multi-target support".

	"You'll notice that remote.c includes some FIXME notes.  These refer to
	the fact that the global arrays that hold data for the remote packets
	supported are still globals.  For example, if we connect to two
	different servers/stubs, then each might support different remote
	protocol features.  They might even be different architectures, like
	e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a
	host/controller scenario as a single program.  That isn't going to
	work correctly today, because of said globals.  I'm leaving fixing
	that for another pass, since it does not appear to be trivial, and I'd
	rather land the base work first.  It's already useful to be able to
	debug multiple instances of the same server (e.g., a distributed
	cluster, where you have full control over the servers installed), so I
	think as is it's already reasonable incremental progress."

	Using this patch it is possible to configure per-remote targets'
	feature packets.

	Given the following setup for two gdbservers:

	~~~~
	gdbserver --multi :1234
	gdbserver --disable-packet=vCont --multi :2345
	~~~~

	Before this patch configuring of range-stepping was not possible for one
	of two connected remote targets with different support for the vCont
	packet.  As one of the targets supports vCont, it should be possible to
	configure "set range-stepping".  However, the output of GDB looks like:

	(gdb) target extended-remote :1234
	Remote debugging using :1234
	(gdb) add-inferior -no-connection
	[New inferior 2]
	Added inferior 2
	(gdb) inferior 2
	[Switching to inferior 2 [<null>] (<noexec>)]
	(gdb) target extended-remote :2345
	Remote debugging using :2345
	(gdb) set range-stepping on
	warning: Range stepping is not supported by the current target
	(gdb) inferior 1
	[Switching to inferior 1 [<null>] (<noexec>)]
	(gdb) set range-stepping on
	warning: Range stepping is not supported by the current target
	~~~~

	Two warnings are shown.  The warning for inferior 1 should not appear
	as it is connected to a target supporting the vCont package.

	~~~~
	(gdb) target extended-remote :1234
	Remote debugging using :1234
	(gdb) add-inferior -no-connection
	[New inferior 2]
	Added inferior 2
	(gdb) inferior 2
	[Switching to inferior 2 [<null>] (<noexec>)]
	(gdb) target extended-remote :2345
	Remote debugging using :2345
	(gdb) set range-stepping on
	warning: Range stepping is not supported by the current target
	(gdb) inferior 1
	[Switching to inferior 1 [<null>] (<noexec>)]
	(gdb) set range-stepping on
	(gdb)
	~~~~

	Now only one warning is shown for inferior 2, which is connected to
	a target not supporting vCont.

	The per-remote target feature array is realized by a new class
	remote_features, which stores the per-remote target array and
	provides functions to determine supported features of the target.
	A remote_target object now has a new member of that class.

	Each time a new remote_target object is initialized, a new per-remote
	target array is constructed based on the global remote_protocol_packets
	array.  The global array is initialized in the function _initialize_remote
	and can be configured using the command line.  Before this patch the
	command line configuration affected current targets and future remote
	targets (due to the global feature array used by all remote
	targets).  This behavior is different and the configuration applies as
	follows:

	 - If a target is connected, the command line configuration affects the
	   current connection.  All other existing remote targets are not
	   affected.

	 - If not connected, the command line configuration affects future
	   connections.

	The show command displays the current remote target's configuration.  If no
	remote target is selected the default configuration for future
	connections is shown.

	If we have for instance the following setup with inferior 2 being
	selected:
	~~~~
	(gdb) info inferiors
	  Num  Description       Connection                Executable
	  1    <null>             1 (extended-remote :1234)
	* 2    <null>             2 (extended-remote :2345)
	~~~~

	Before this patch, if we run 'set remote multiprocess-feature-packet', the
	following configuration was set:
	The feature array of all remote targets (in this setup the two connected
	targets) and all future remote connections are affected.

	After this patch, it will be configured as follows:
	The feature array of target with port :2345 which is currently selected
	will be configured.  All other existing remote targets are not affected.
	The show command 'show remote multiprocess-feature-packet' will display
	the configuration of target with port :2345.

	Due to this configuration change, it is required to adapt the test
	"gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the
	multiprocess-feature-packet before the connections are created.

	To inform the gdb user about the new behaviour of the 'show remote
	PACKET-NAME' commands and the new configuration impact for remote
	targets using the 'set remote PACKET-NAME' commands the commands'
	outputs are adapted.  Due to this change it is required to adapt each
	test using the set/show remote 'PACKET-NAME' commands.

2023-01-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-27  Tom Tromey  <tromey@adacore.com>

	More const-correctness in cooked indexer
	I noticed that iterating over the index yields non-const
	cooked_index_entry objects.  However, after finalization, they should
	not be modified.  This patch enforces this by adding const where
	needed.

	v2 makes the find, all_entries, and wait methods const as well.

2023-01-27  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp.tcl
	Recent commit 1d98e564c97 ("[gdb/testsuite] Add
	gdb.base/unwind-on-each-insn-{amd64,i386}.exp") broke commit eb015bf86b6
	("[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp"),
	in the sense that gdb.base/unwind-on-each-insn.exp no longer uses
	-fno-asynchronous-unwind-tables, due to trying to concatenate two lists using:
	...
	    lappend srcfile2_flags $nodebug_flags
	...
	which should instead be:
	...
	    lappend srcfile2_flags {*}$nodebug_flags
	...

	Fix this by simplifying gdb.base/unwind-on-each-insn.exp.tcl, completely
	leaving the responsibility to set srcfile_flags and srcfile2_flags to each
	includer.

	Tested on x86_64-linux.

2023-01-27  Tom Tromey  <tromey@adacore.com>

	Invert test in gdb.ada/ptype_tagged_param.exp
	Simon pointed out that the kfail check in
	gdb.ada/ptype_tagged_param.exp is inverted.  See:

	https://sourceware.org/pipermail/gdb-patches/2023-January/196296.html

	This patch fixes the problem.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: more debug output
	Add some additional debug output that I've found really useful while
	working on the previous set of patches.

	Unless tui debug is turned on, then there should be no user visible
	changes with this commit.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: avoid extra refresh_window on vertical scroll
	While working on the previous couple of patches I noticed that when I
	scroll the src and asm windows vertically, I get two refresh_window
	calls.

	The two calls can be traced back to
	tui_source_window_base::update_source_window_as_is, in here we call
	show_source_content, which calls refresh_window, and then
	update_exec_info, which also calls refresh_window.

	In this commit I propose making the refresh_window call in
	update_exec_info optional.  In update_source_window_as_is I'll then
	call update_exec_info before calling show_source_content, and pass a
	flag to update_exec_info to defer the refresh.

	There are places where update_exec_info is used without any subsequent
	refresh_window call (e.g. when a breakpoint is updated), so
	update_exec_info does not to call refresh_window in some cases, which
	is why I'm using a flag to control the refresh.

	With this changes I'm now only seeing a single refresh_window call for
	each vertical scroll.

	There should be no user visible changes after this commit.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: avoid extra refresh_window on horizontal scroll
	While working on the previous patches I noticed that in some cases I
	was seeing two calls to tui_source_window_base::refresh_window when
	scrolling the window horizontally.

	The two calls would trigger in for the tui-disasm-long-lines.exp test
	when the pad needed to be refilled.  The two called both come from
	tui_source_window_base::show_source_content.  The first call is nested
	within check_and_display_highlight_if_needed, while the second call is
	done directly at the end of show_source_content.

	The check_and_display_highlight_if_needed is being used to draw the
	window box to the window, this is needed here because
	show_source_content is what gets called when the window needs
	updating, e.g. after a resize.  We could potentially do the boxing in
	refresh_window, but then we'd be doing it each time we scroll, even
	though the box doesn't need changing in this case.

	However, we can move the check_and_display_highlight_if_needed to be
	the last thing done in show_source_content, this means that we can
	rely on the refresh_window call within it to be our single refresh
	call.

	There should be no user visible changes after this commit.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: rewrite of tui_source_window_base to handle very long lines
	This commit addresses an issue that is exposed by the test script
	gdb.tui/tui-disasm-long-lines.exp, that is, tui_source_window_base
	does not handle very long lines.

	The problem can be traced back to the newpad call in
	tui_source_window_base::show_source_content, this is where we allocate
	a backing pad to hold the window content.

	Unfortunately, there appears to be a limit to the size of pad that can
	be allocated, and the gdb.tui/tui-disasm-long-lines.exp test goes
	beyond this limit.  As a consequence the newpad call fails and returns
	nullptr.

	It just so happens that the reset of the tui_source_window_base code
	can handle the pad being nullptr (this happens anyway when the window
	is first created, so we already depend on nullptr handling), so all
	that happens is the source window displays no content.

	... well, sort of ... something weird does happen in the command
	window, we seem to see a whole bunch of blank lines.  I've not
	bothered to track down exactly what's happening there, but it's some
	consequence of GDB attempting to write content to a WINDOW* that is
	nullptr.

	Before explaining my solution, I'll outline how things currently work:

	Consider we have the following window content to display:

	  aaaaaaaaaa
	  bbbbbbbbbbbbbbbbbbbb
	  ccccccccccccccc

	the longest line here is 20 characters.  If our display window is 10
	characters wide, then we will create a pad that is 20 characters wide,
	and then copy the lines of content into the pad:

	  .--------------------.
	  |aaaaaaaaaa          |
	  |bbbbbbbbbbbbbbbbbbbb|
	  |ccccccccccccccc     |
	  .--------------------.

	Now we will copy a 10 character wide view into this pad to the
	display, our display will then see:

	  .----------.
	  |aaaaaaaaaa|
	  |bbbbbbbbbb|
	  |cccccccccc|
	  .----------.

	As the user scrolls left and right we adjust m_horizontal_offset and
	use this to select which part of the pad is copied onto the display.

	The benefit of this is that we only need to copy the content to the
	pad once, which includes processing the ansi escape sequences, and
	then the user can scroll left and right as much as they want
	relatively cheaply.

	The problem then, is that if the longest content line is very long,
	then we try to allocate a very large pad, which can fail.

	What I propose is that we allow both the pad and the display view to
	scroll.  Once we allow this, then it becomes possible to allocate a
	pad that is smaller than the longest display line.  We then copy part
	of the content into the pad.  As the user scrolls the view left and
	right GDB will continue to copy content from the pad just as it does
	right now.  But, when the user scrolls to the edge of the pad, GDB
	will copy a new block of content into the pad, and then update the
	view as normal.  This all works fine so long as the maximum pad size
	is larger than the current window size - which seems a reasonable
	restriction, if ncurses can't support a pad of a given size it seems
	likely it will not support a display window of that size either.

	If we return to our example above, but this time we assume that the
	maximum pad size is 15 characters, then initially the pad would be
	loaded like this:

	  .---------------.
	  |aaaaaaaaaa     |
	  |bbbbbbbbbbbbbbb|
	  |ccccccccccccccc|
	  .---------------.

	Notice that the last 5 characters from the 'b' line are no longer
	included in the pad.  There is still enough content though to fill the
	10 character wide display, just as we did before.

	The pad contents remain unchanged until the user scrolls the display
	right to this point:

	  .----------.
	  |aaaaa     |
	  |bbbbbbbbbb|
	  |cccccccccc|
	  .----------.

	Now, when the user scrolls right once more GDB spots that the user has
	reached the end of the pad, and the pad contents are reloaded, like
	this:

	  .---------------.
	  |aaaaa          |
	  |bbbbbbbbbbbbbbb|
	  |cccccccccc     |
	  .---------------.

	The display can now be updated from the pad again just like normal.

	With this change in place the gdb.tui/tui-disasm-long-lines.exp test
	now correctly loads the assembler code, and we can scroll around as
	expected.

	Most of the changes are pretty mundane, just updating to match the
	above.  One interesting change though is the new member function
	tui_source_window_base::puts_to_pad_with_skip.  This replaces direct
	calls to tui_puts when copying content to the pad.

	The content strings contain ansi escape sequences.  When these strings
	are written to the pad these escape sequences are translated into
	ncurses attribute setting calls.

	Now however, we sometimes only write a partial string to the pad,
	skipping some of the leading content.  Imagine then that we have a
	content line like this:

	  "\033[31mABCDEFGHIJKLM\033[0m"

	Now the escape sequences in this content mean that the actual
	content (the 'ABCDEFGHIJKLM') will have a red foreground color.

	If we want to copy this to the pad, but skip the first 3 characters,
	then what we expect is to have the pad contain 'DEFGHIJKLM', but this
	text should still have a red foreground color.

	It is this problem that puts_to_pad_with_skip solves.  This function
	skips some number of printable characters, but processes all the
	escape sequences.  This means that when we do start printing the
	actual content the content will have the expected attributes.
	/

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: make m_horizontal_offset private
	I noticed that tui_source_window_base::m_horizontal_offset was
	protected, but could be made private, so lets do that.

	This makes more sense in the context of a later commit where I plan to
	add another member variable that is similar to m_horizontal_offset.
	The new member variable could also be private.

	So I had to choose, place the new member variable next to
	m_horizontal_offset making it protected, but grouping similar
	variables together, or make m_horizontal_offset private, and then add
	the new variable as private too.

	I chose to make m_horizontal_offset private, which is this commit.

	There should be no user visible changes after this commit.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: disable tui mode when an assert triggers
	When an assert triggers in tui mode the output is not great, the
	internal backtrace that is generated is printed directly to the file
	descriptor for gdb_stderr, and, as a result, does not currently format
	itself correctly - the output uses only '\n' at the end of each line,
	and so, when the terminal is in raw mode, the cursor does not return
	to the start of each line after the '\n'.

	This is mostly fixable, we could update bt-utils.c to use '\r\n'
	instead of just '\n', and this would fix most of the problems.  The
	one we can't easily fix is if/when GDB is built to use execinfo
	instead of libbacktrace, in this case we use backtrace_symbols_fd to
	print the symbols, and this function only uses '\n' as the line
	terminator.  Fixing this would require switching to backtrace_symbols,
	but that API uses malloc, which is something we're trying to
	avoid (this code is called when GDB hits an error, so ideally we don't
	want to rely on malloc).

	However, the execinfo code is only used when libbacktrace is not
	available (or the user specifically disables libbacktrace) so maybe we
	can ignore that problem...

	... but there is another problem.  When the backtrace is printed in
	raw mode, it is possible that the backtrace fills the screen.  With
	the terminal in raw mode we don't have the ability to scroll back,
	which means we loose some of the backtrace, which isn't ideal.

	In this commit I propose that we should disable tui mode whenever we
	handle a fatal signal, or when we hit the internal error code
	path (e.g. when an assert triggers).  With this done then we don't
	need to update the bt-utils.c code, and the execinfo version of the
	code (using backtrace_symbols_fd) works just fine.  We also get the
	ability to scroll back to view the error message and all of the
	backtrace, assuming the users terminal supports scrolling back.

	The only downside I see with this change is if the tui_disable call
	itself causes an error for some reason, or, if we handle a single at a
	time when it is not safe to call tui_disable, in these cases the extra
	tui_disable call might cause GDB to loose the original error.

	However, I think (just from personal experience) that the above two
	issues are pretty rare and the benefits from this change far out
	weighs the possible drawbacks.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: improve errors from tui focus command
	This commit improves (I think) the errors from the tui focus command.
	There are a number of errors that can be triggered by the focus
	command, they include:

	  (1) Window name "NAME" is ambiguous

	  (2) Unrecognized window name "NAME"

	  (3) Window "NAME" cannot be focused

	Error (1) is triggered when the user gives a partial window name, and
	the name matches multiple windows in the current layout.

	It is worth noting that the ambiguity must be within the current
	layout; if the partial name matches one window in the current layout,
	and one or more windows not in the current layout, then this is not
	ambiguous, and focus will shift to the matching window in the current
	layout.

	This error was not previous being tested, but in this commit I make
	use of the Python API to trigger and test this error.

	Error (3) is simple enough, and was already being tested.  This is
	triggered by something like 'focus status'.  The named window needs to
	be present in the current layout, and non-focusable in order to
	trigger the error.

	Error (2) is what I'd like to improve in this commit.  This error
	triggers if the name the user gives doesn't match any window in the
	current layout.  Even if GDB does know about the window, but the
	window isn't in the current layout, then GDB will say it doesn't
	recognize the window name.

	In this commit I propose to to split this error into three different
	errors.  These will be:

	  (a) Unrecognized window name "NAME"

	  (b) No windows matching "NAME" in the current layout

	  (c) Window "NAME" is not in the current layout

	Error (a) is the same as before, but will now only trigger if GDB
	doesn't know about window NAME at all.  If the window is known, but
	not in the current layout then one of the other errors will trigger.

	Error (b) will trigger if NAME is ambiguous for multiple windows that
	are not in the current layout.  If NAME identifies a single window in
	the current layout then that window will continue to be selected, just
	as it currently is.  Only in the case where NAME doesn't identify a
	window in the current layout do we then check all the other known
	windows, if NAME matches multiple of these, then (b) is triggered.

	Finally, error (c) is used when NAME uniquely identifies a single
	window that is not in the current layout.

	The hope with these new errors is that the user will have a better
	understanding of what went wrong.  Instead of GDB claiming to not know
	about a window, the mention of the current layout will hint to the
	user that they should first switch layouts.

	There are tests included for all the new errors.

2023-01-27  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: fix line feed scrolling in tuiterm.exp
	In a following commit I managed to trigger the line feed scrolling
	case in tuiterm.exp.  This case is currently unhandled, and this
	commit fills in this missing functionality.

	The implementation is pretty simple, just scroll all the content up
	one line at a time until the cursor is back on the screen (a single
	line of scroll is all that should be needed).

	This change is untested in this commit, but is required by the next
	commit.

2023-01-27  Nick Clifton  <nickc@redhat.com>

	Another fix for EFI generation with LTO enabled.
	PR 29998 * pe-dll.c (build_filler_bfd): Initialise the next field of the filler input statement, so that it does not break the file chain.

2023-01-27  Jan Beulich  <jbeulich@suse.com>

	x86: move reg_operands adjustment
	Ideally we'd do away with this somewhat questionable adjustment (leaving
	i.types[] untouched). That's non-trivial though as it looks, so only
	- move the logic into process_operands(), putting it closer to related
	  logic and eliminating a conditional for operand-less insns,
	- make it consistent (i.e. also affect %xmm0), eliminating an ugly
	  special case later in the function.

	x86: drop dead SSE2AVX-related code
	All (there are just two) SSE2AVX templates with %xmm0 as first operand
	also specify VEX3SOURCES. Hence there's no need for an "else" to the
	respective if(), and the if() itself can become an assertion.

	x86: use ModR/M for FPU insns with operands
	This is the correct way of expressing things; encoding the ModR/M byte
	directly in base_opcode has always been bogus.

	x86/Intel: improve special casing of certain insns
	Now that we have identifiers for the mnemonic strings we can avoid
	opcode based comparisons, for (in many cases) being more expensive and
	(in a few cases) being a little fragile and not self-documenting.

2023-01-27  Jan Beulich  <jbeulich@suse.com>

	opcodes: suppress internationalization on build helper tools
	While one of the two actually having been instrumented (i386-gen.c) now
	has that instrumentation dropped, there's still no point in honoring
	such instrumentation in general (i.e. now for ia64-gen.c only), as that
	only leads to a waste of resources.

	With CFILES then being merely an alias of LIBOPCODES_CFILES, drop the
	former variable altogether.

2023-01-27  Jan Beulich  <jbeulich@suse.com>

	x86: remove internationalization from i386-gen.c
	This is a build time helper utility, which doesn't require translation.

2023-01-27  Alan Modra  <amodra@gmail.com>

	Call bfd_close_all_done in ld_cleanup
	This is similar to "Call bfd_close_all_done in output_file_close",
	but with some code tidying in the pe/pep write_build_id functions.
	write_build_id is passed the output bfd as its parameter, so there is
	no need to go looking for the output bfd via link_info (and doing so
	will no longer work since I clear link_info.output_bfd before calling
	bfd_close).

		* emultempl/pe.em (write_build_id): Rename t to td.  Formatting.
		Don't access pe_data(link_info.output_bfd), use td instead.
		(setup_build_id): Rename t to td.  Formatting.
		* emultempl/pep.em: As for pe.em.
		* ldmain.c (ld_cleanup): Call bfd_close_all_done on linker bfds.
		(main): Clear link_info.output_bfd when closing.

2023-01-27  Alan Modra  <amodra@gmail.com>

	Perform cleanup in bfd_close after errors
	It seems reasonable to continue after errors in bfd_close_all_done,
	particularly since bfd_close_all_done is typically called on an output
	file after we've hit some sort of error elsewhere.  The iovec test is
	necessary if bfd_close_all_done is to work on odd bfd's opened by
	bfd_create.

		* opncls.c (bfd_close): Call bfd_close_all_done after errors
		from _bfd_write_contents.
		(bfd_close_all_done): Call _bfd_delete_bfd after errors.
		Don't call iovec->bclose when iovec is NULL.

2023-01-27  Alan Modra  <amodra@gmail.com>

	Call bfd_close_all_done in output_file_close
	bfd_cache_close_all is good for closing file descriptors, but doesn't
	do the cleanup of bfd memory as in bfd_close_all_done.

		PR 13056
		* output-file.c (output_file_close): Call bfd_close_all_done,
		not bfd_cache_close_all.

2023-01-27  Alan Modra  <amodra@gmail.com>

	gas macro memory leaks
	This tidies memory allocated for entries in macro_hash.  Freeing the
	macro name requires a little restructuring of the define_macro
	interface due to the name being used in the error message, and exposed
	the fact that the name and other fields were not initialised by the
	iq2000 backend.

	There is also a fix for
	 .macro .macro
	 .endm
	 .macro .macro
	 .endm
	which prior to this patch reported
	mac.s:1: Warning: attempt to redefine pseudo-op `.macro' ignored
	mac.s:3: Error: Macro `.macro' was already defined
	rather than reporting the attempt to redefine twice.

		* macro.c (macro_del_f): New function.
		(macro_init): Use it when creating macro_hash.
		(free_macro): Free macro name too.
		(define_macro): Return the macro_entry, remove idx, file, line and
		namep params.  Call as_where.  Report errors here.  Delete macro
		from macro_hash on attempt to redefined pseudo-op.
		(delete_macro): Don't call free_macro.
		* macro.h (define_macro): Update prototype.
		* read.c (s_macro): Adjust to suit.
		* config/tc-iq2000.c (iq2000_add_macro): Init all fields of
		macro_entry.

2023-01-27  Mark Harmstone  <mark@harmstone.com>

	gas/testsuite: Add -gcodeview test for aarch64-w64-mingw32
	This is a copy of the x86 gas -gcodeview test, with changes made for the
	differing instruction lengths between x86 and aarch64.

	gas: Add CodeView constant for aarch64
	Adds the correct constant to the S_COMPILE3 CodeView record when
	assembling aarch64-w64-mingw32 with the -gcodeview flag.

2023-01-27  Tom Tromey  <tom@tromey.com>

	Use clean_restart in gdb.base
	Change gdb.base to use clean_restart more consistently.

	Use clean_restart in gdb.python
	Change gdb.python to use clean_restart more consistently.

	Use clean_restart in gdb.cp
	Change gdb.cp to use clean_restart more consistently.

	Use clean_restart in gdb.disasm
	Change gdb.disasm to use clean_restart more consistently.

	Use clean_restart in gdb.perf
	Change gdb.perf to use clean_restart more consistently.

	Use clean_restart in gdb.go
	Change gdb.go to use clean_restart more consistently.

	Use clean_restart in gdb.stabs
	Change gdb.stabs to use clean_restart more consistently.

	Use clean_restart in gdb.fortran
	Change gdb.fortran to use clean_restart more consistently.

	Use clean_restart in gdb.ada
	Change gdb.ada to use clean_restart more consistently.

	Use clean_restart in gdb.dwarf2
	Change gdb.dwarf2 to use clean_restart more consistently.

	Use clean_restart in gdb.reverse
	Change gdb.reverse to use clean_restart more consistently.

	Use clean_restart in gdb.arch
	Change gdb.arch to use clean_restart more consistently.

	Use clean_restart in gdb.guile
	Change gdb.guile to use clean_restart more consistently.

	Use clean_restart in gdb.threads
	Change gdb.threads to use clean_restart more consistently.

	Use clean_restart in gdb.objc
	Change gdb.objc to use clean_restart more consistently.

	Use clean_restart in gdb.trace
	Change gdb.trace to use clean_restart more consistently.

	Use clean_restart in gdb.opencl
	Change gdb.opencl to use clean_restart more consistently.

	Use clean_restart in gdb.linespec
	Change gdb.linespec to use clean_restart more consistently.

	Use clean_restart in gdb.pascal
	Change gdb.pascal to use clean_restart more consistently.

	Use mi_clean_restart more
	This changes a number of MI tests to use mi_clean_restart rather than
	separate calls.  This reduces the number of lines, which is nice, and
	also provides a nicer model to copy for future tests.

	Start gdb after building executable in mi-basics.exp
	A lot of the MI tests start gdb and only then build the executable.
	This just seemed weird to me, so I've fixed this up.  In this patch,
	no other cleanups are done, the startup is just moved to a more
	logical (to me) spot.

	Remove unnecessary call to standard_testfile
	This test does not build a program and does not need to call
	standard_testfile.

	Minor "require" fixups
	I found a couple of spots that could use "require", and one spot where
	hoisting the "require" closer to the top of the file made it more
	clear.

2023-01-27  Tom Tromey  <tom@tromey.com>

	Remove some dead code in gdb.fortran/info-types.exp
	An early "return" in this test case prevents a test from running.
	This seems to have been intentional and has been in place since:

	commit d57cbee932f86df06251498daa93154046dc77c0
	Author: Andrew Burgess <andrew.burgess@embecosm.com>
	Date:   Tue Dec 3 13:18:43 2019 +0000

	    gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+

	This patch removes the dead code.

2023-01-27  Tom Tromey  <tom@tromey.com>

	Eliminate spurious returns from the test suite
	A number of tests end with "return".  However, this is unnecessary.
	This patch removes all of these.

	Use clean_restart in gdb.dlang
	Change gdb.dlang to use clean_restart more consistently.

	Use ordinary calling convention for clean_restart
	clean_restart accepts a single optional argument.  Rather than using
	{args} and handling the argument by hand, change it to use Tcl's own
	argument-checking.

2023-01-27  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-26  Alan Modra  <amodra@gmail.com>

	Free gas/dwarf2dbg.c dirs
	Entries are allocated with xmemdup0.

		* dwarf2dbg.c (dwarf2_cleanup): Free dirs entries.

2023-01-26  Alan Modra  <amodra@gmail.com>

	Sanity check dwarf5 form of .file
	There's a comment a few lines earlier saying that demand_copy_C_string
	has already reported an error if it returns NULL.  Given the proximity
	I decided not to duplicate the comment.

		* dwarf2dbg.c (dwarf2_directive_filename): Check return of
		demand_copy_C_string for file.

2023-01-26  Alan Modra  <amodra@gmail.com>

	resolve gas shift expressions with large exponents to zero
		* expr.c (resolve_expression <O_left_shift, O_right_shift>): Resolve
		shifts exceeding bits in a valueT to zero.

	segv in coff_aarch64_addr32nb_reloc
		* coff-aarch64.c (coff_aarch64_addr32nb_reloc): When output_bfd
		is NULL (which it is for objdump -W) get the output bfd via the
		input section.

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: initialize "correct" variable in gdb.cp/cpexprs.exp.tcl
	Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB
	crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to
	read the string, at gdb.cp/cpexprs.exp.tcl:725.  The "correct" variable
	doesn't get set, and I then see this TCL error:

	  ERROR: can't read "correct": no such variable

	Avoid the TCL error by initializing the "correct" variable to a dummy
	value.

	Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE
	Prior to this patch, I get:

	    >>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}}
	    Content-Length: 147

	    {"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success
	    FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output

	The problem is that the PC to disassemble is taken from the breakpoint
	insertion response, which happens before running.  With a PIE
	executable, that PC is unrelocated, but the disassembly request happens
	after relocation.

	I chose to fix this by watching for a breakpoint changed event giving
	the new breakpoint address, and recording the address from there.  I
	think this is an interesting way to fix it, because it adds a bit of
	test coverage, I don't think these events are checked right now.

	Other ways to fix it would be:

	 - Get the address by doing a breakpoint insertion after the program is
	   started, or some other way.
	 - Do the disassembly by symbol instead of by address.
	 - Do the disassembly before running the program.

	Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: make dap_wait_for_event_and_check return preceding messages
	In the following patch, I change gdb.dap/basic-dap.exp such that after
	waiting for some event, it checks if it received another event
	meanwhile.  To help with this, make dap_wait_for_event_and_check and
	_dap_dap_wait_for_event return a list with everything received before
	the event of interest.  This is similar to what
	dap_check_request_and_response returns.

	Change-Id: I85c8980203a2dec833937e7552c2196bc137935d

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: rename dap_read_event to dap_wait_for_event_and_check
	I think that name describes a bit better what the proc does, it is
	similar to "wait_for" in tuiterm.exp.

	Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: pass around dicts instead of TON objects
	The DAP helper functions generally return TON objects.  However, callers
	almost all immediately use ton::2dict to convert them to dicts, to
	access their contents.  This commits makes things a bit simpler for them
	by having function return dicts directly instead.

	The downside is that the TON objects contain type information.  For
	instance, a "2" in a TCL dict could have been the integer 2 or the
	string "2" in JSON.  By converting to TCL dicts, we lose that
	information.  If some tests specifically want to check the types of some
	fields, I think we can add intermediary functions that return TON
	objects, without having to complicate other callers who don't care.

	Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: remove catch from dap_read_event
	This catch didn't cause me any trouble, but for the same reason as the
	preceding patch, I think it's a bit better to just let any exception
	propagate, to make for easier debugging.

	Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: make dap_request_and_response not catch / issue test result
	Following some of my changes, dap_request_and_response was failing and I
	didn't know why.  I think it's better to make it not catch any
	exception, and just make it do a simple "send request, read response".
	If an exception is thrown while sending a request or reading a response,
	things are going really badly, it's not like we'll want to recover from
	that and continue the test.

	Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: write requests to gdb.log
	This helps following what happens when reading gdb.log.  The downside is
	that it becomes harder to tell what text is from GDB and what text is
	going to GDB, but I think that seeing responses without seeing requests
	is even more confusing.  At least, the lines are prefix with >>>, so
	when you see this, you know that until the end of the line, it's
	something that was sent to GDB, and not GDB output.

	Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: prefix some procs with _
	Prefix some procs that are only used internally with an underscore, to
	make it clear they are internal.  If they need to be used by some test
	later, we can always un-prefix them.

	Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d

2023-01-26  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite/dap: use gdb_assert in gdb.dap/basic-dap.exp
	Use gdb_assert instead of manual pass/fail.

	Change-Id: I71fbc4e37a0a1ef4783056c7424e932651fa397f

2023-01-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: PR30043 libgprofng.so.* are installed to a wrong location
	gprofng/ChangeLog
	2023-01-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/30043
		PR gprofng/28972
		* src/Makefile.am: Use lib_LTLIBRARIES instead of pkglib_LTLIBRARIES.
		* src/Makefile.in: Rebuild.

2023-01-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.exp
	The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in
	the epilogue was inaccurate.

	In order to work around this in gdb, epilogue unwinders were added with a
	higher priority than the dwarf unwinders in the amd64 and i386 targets:
	- amd64_epilogue_frame_unwind, and
	- i386_epilogue_frame_unwind.

	Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0.

	However, the epilogue unwinders prevented gdb from taking advantage of the
	fixed epilogue unwind info, so the scope of the epilogue unwinders was
	limited, bailing out for gcc >= 4.5.0.

	There was no regression test added for this preference scheme, so if we now
	declare epilogue unwind info from all gcc versions as trusted, no test will
	start failing.

	Fix this by adding an amd64 and i386 regression test for this.

	I have no gcc 4.4.x lying around, so I fabricated the assembly files by:
	- commenting out some .cfi directives to break the epilogue unwind info, and
	- hand-editing the producer info to 4.4.7 to activate the fix.

	Tested on x86_64-linux, target boards unix/{-m64,-m32}.

2023-01-26  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add and use is_x86_64_m64_target
	Add new proc is_x86_64_m64_target and use it where appropriate.

	Tested on x86_64-linux.

2023-01-26  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-25  Mark Harmstone  <mark@harmstone.com>

	ld/testsuite: Add missing targets to PDB tests

2023-01-25  Mark Harmstone  <mark@harmstone.com>

	ld: Add pdb support to aarch64-w64-mingw32
	This extends PDB support to the aarch64 PE targets.

	The changes to the test files are just to make it so they can be assembled as
	either x86, x86_64, or aarch64, mainly by changing the comment style.
	The only actual code change here is in adding the architecture constants
	to pdb.c.

2023-01-25  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	gdb/arm: Use new dwarf2 function cache
	This patch resolves the performance issue reported in pr/29738 by
	caching the values for the stack pointers for the inner frame.  By
	doing so, the impact can be reduced to checking the state and
	returning the appropriate value.

2023-01-25  Torbjörn SVENSSON  <torbjorn.svensson@foss.st.com>

	gdb: dwarf2 generic implementation for caching function data
	When there is no dwarf2 data for a register, a function can be called
	to provide the value of this register.  In some situations, it might
	not be trivial to determine the value to return and it would cause a
	performance bottleneck to do the computation each time.

	This patch allows the called function to have a "cache" object that it
	can use to store some metadata between calls to reduce the performance
	impact of the complex logic.

	The cache object is unique for each function and frame, so if there are
	more than one function pointer stored in the dwarf2_frame_cache->reg
	array, then the appropriate pointer will be supplied (the type is not
	known by the dwarf2 implementation).

	dwarf2_frame_get_fn_data can be used to retrieve the function unique
	cache object.
	dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the
	function unique cache object.

2023-01-25  Tom Tromey  <tromey@adacore.com>

	Clean up unusual code in mi-cmd-stack.c
	I noticed some unusual code in mi-cmd-stack.c.  This code is a switch,
	where one of the cases appears in the middle of another block.  It
	seemed cleaner to me to have the earlier case just conditionally fall
	through.

2023-01-25  H.J. Lu  <hjl.tools@gmail.com>

	i386: Pass -Wl,--no-as-needed to compiler as needed
	Pass -Wl,--no-as-needed to linker tests to fix

	FAIL: Run pr19031
	FAIL: Run got1
	FAIL: Undefined weak symbol (-fPIE -no-pie)
	FAIL: Undefined weak symbol (-fPIE -pie)

	when --as-needed is passed to linker by compiler.

		PR ld/30050
		* testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
		as needed.

2023-01-25  Tom Tromey  <tom@tromey.com>

	Move target check into allow_altivec_tests
	Pedro pointed out that only PPC can possibly have altivec, so we can
	move the target check into allow_altivec_tests.

	Use require with is_remote
	This changes some tests to use require with 'is_remote', rather than
	an explicit test.  This adds uniformity helps clean up more spots
	where a test might exit early without any notification.

2023-01-25  Tom Tromey  <tom@tromey.com>

	Add unsupported calls where needed
	A number of tests will exit early without saying why.  This patch adds
	"unsupported" at spots like this that I could readily find.

	There are definitely more of these; for example dw2-ranges.exp fails
	silently because a compilation fails.  I didn't attempt to address
	these as that is a much larger task.

2023-01-25  Tom Tromey  <tom@tromey.com>

	Introduce and use is_any_target
	A few tests work on two different targets that can't be detected with
	a single call to istarget -- that proc only accepts globs, not regular
	expressions.

	This patch introduces a new is_any_target proc and then converts these
	tests to use it in a 'require'.

2023-01-25  Tom Tromey  <tom@tromey.com>

	Use require with istarget
	This changes many tests to use require when checking 'istarget'.  A
	few of these conversions were already done in earlier patches.

	No change was needed to 'require' to make this work, due to the way it
	is written.  I think the result looks pretty clear, and it has the
	bonus of helping to ensure that the reason that a test is skipped is
	always logged.

2023-01-25  Tom Tromey  <tom@tromey.com>

	Rename skip_vsx_tests to allow form
	This renames skip_vsx_tests to allow_vsx_tests and updates it users to
	use require.

	Rename skip_power_isa_3_1_tests to allow form
	This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and
	updates its users to use require.

	Rename skip_float_test to allow form
	This renames skip_float_test to allow_float_test and updates its users
	to use require.

	Convert skip_altivec_tests to allow form
	This renames skip_altivec_tests to allow_altivec_tests and updates its
	users to use require.

2023-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/unwind-on-each-insn.exp for -m32
	With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I
	now get:
	...
	 # of expected passes            25
	...
	instead of:
	...
	 # of expected passes            133
	...
	as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug
	srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match
	"rip = " and info frame printing "eip = " instead.

	Fix this by dropping "rip" from the regexp.

	Tested on x86_64-linux, target boards unix/{-m64,-m32}.

2023-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.exp
	Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
	$srcfile2 without.

	Occasionally, I try both files with debug info:
	...
	-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
	+             $srcfile $debug_flags $srcfile2 $debug_flags]]} {
	...

	This shortcuts the test due to no longer recognizing that stepi still lands
	in foo.

	Fix this by determining whether still in foo by checking the info frame output.

	Tested on x86_64-linux.

2023-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Allow nodebug srcfile in gdb.base/unwind-on-each-insn.exp
	Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
	$srcfile2 without.

	Occasionally, I try both files with debug info:
	...
	-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
	+             $srcfile $debug_flags $srcfile2 $debug_flags]]} {
	...
	and both files without:
	...
	-             $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
	+             $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} {
	...

	In the latter case, I run into:
	...
	FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2
	FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up
	...
	due to a mismatch between the regexp and the different output due to using
	nodebug.

	Fix this by making the regexp less strict.

	Tested on x86_64-linux.

2023-01-25  Felix Willgerodt  <felix.willgerodt@intel.com>

	gdb, i386: Update stale comment in i386-tdep.h.
	The comment seems no longer valid, the functions technically check for
	non-pseudo registers, like zmmh.  Which is a valid use case.

2023-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Analyze non-leaf fn in gdb.base/unwind-on-each-insn.exp
	In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
	to check various invariants at each insn, in particular hoping to excercise
	insns that modify stack and frame pointers.

	Function foo is a leaf function, so add a non-leaf function bar, and step
	through it as well (using nexti instead of stepi).

	With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049:
	...
	FAIL: bar: instruction 5: bt 2
	FAIL: bar: instruction 5: up
	FAIL: bar: instruction 5: [string equal $fid $::main_fid]
	FAIL: bar: instruction 6: bt 2
	FAIL: bar: instruction 6: up
	FAIL: bar: instruction 6: [string equal $fid $::main_fid]
	...

	Tested on:
	- x86_64-linux (-m64 and -m32)
	- s390x-linux (-m64 and -m31)
	- aarch64-linux
	- powerpc64le-linux

2023-01-25  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp
	In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
	to check various invariants at each insn, in particular hoping to excercise
	insns that modify stack and frame pointers.

	For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
	...
	  4004bc:       55                      push   %rbp
	  4004bd:       48 89 e5                mov    %rsp,%rbp
	  4004c0:       90                      nop
	  4004c1:       5d                      pop    %rbp
	  4004c2:       c3                      ret
	...
	Both stack pointer (%rsp) and frame pointer (%rbp) are modified.

	Also for s390x-linux (and similar for -m31):
	...
	0000000001000668 <foo>:
	 1000668:       e3 b0 f0 58 00 24       stg     %r11,88(%r15)
	 100066e:       b9 04 00 bf             lgr     %r11,%r15
	 1000672:       e3 b0 b0 58 00 04       lg      %r11,88(%r11)
	 1000678:       07 fe                   br      %r14
	...
	Frame pointer (%r11) is modified.

	Likewise for powerpc64le-linux:
	...
	00000000100006c8 <foo>:
	    100006c8:   f8 ff e1 fb     std     r31,-8(r1)
	    100006cc:   d1 ff 21 f8     stdu    r1,-48(r1)
	    100006d0:   78 0b 3f 7c     mr      r31,r1
	    100006d4:   00 00 00 60     nop
	    100006d8:   30 00 3f 38     addi    r1,r31,48
	    100006dc:   f8 ff e1 eb     ld      r31,-8(r1)
	    100006e0:   20 00 80 4e     blr
	...
	Both stack pointer (r1) and frame pointer (r31) are modified.

	But for aarch64-linux, we have:
	...
	00000000004005fc <foo>:
	  4005fc:       d503201f        nop
	  400600:       d65f03c0        ret
	...
	There's no insn that modifies stack or frame pointer.

	Fix this by making foo more complex, adding an (unused) argument:
	...
	0000000000400604 <foo>:
	  400604:       d10043ff        sub     sp, sp, #0x10
	  400608:       f90007e0        str     x0, [sp, #8]
	  40060c:       d503201f        nop
	  400610:       910043ff        add     sp, sp, #0x10
	  400614:       d65f03c0        ret
	...
	such that the stack pointer (sp) is modified.

	[ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
	-mno-omit-leaf-frame-pointer we have instead:
	...
	0000000000400604 <foo>:
	  400604:       a9be7bfd        stp     x29, x30, [sp, #-32]!
	  400608:       910003fd        mov     x29, sp
	  40060c:       f9000fa0        str     x0, [x29, #24]
	  400610:       d503201f        nop
	  400614:       a8c27bfd        ldp     x29, x30, [sp], #32
	  400618:       d65f03c0        ret
	...
	such that also the frame pointer (x29) is modified. ]

	Having made foo more complex, we now run into the following fail on
	x86_64/-m32:
	...
	FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp
	....

	The problem is that the stack pointer has changed inbetween the sampling of
	main_sp and *foo, in particular by the push insn:
	...
	 804841a:       68 c0 84 04 08          push   $0x80484c0
	 804841f:       e8 10 00 00 00          call   8048434 <foo>
	...

	Fix this by updating main_sp.

	On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
	...
	FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
	FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid]
	...
	but I saw the same failure before this commit with gcc 4.8.5.

	Tested on:
	- x86_64-linux (-m64 and -m32)
	- s390x-linux (-m64 and -m31)
	- powerpc64le-linux
	- aarch64-linux

	Also I've checked that the test-case still functions as regression test for PR
	record/16678 on x86_64.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: make use of a scoped_restore
	Make use of a scoped_restore object in tui_mld_read_key instead of
	doing a manual save/restore.

	I don't think the existing code can throw an exception, so this is
	just a cleanup rather than a bug fix.

	There should be no user visible changes after this commit.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: better filtering of tab completion results for focus command
	While working on the previous couple of commits, I noticed that the
	'focus' command would happily suggest 'status' as a possible focus
	completion, even though the 'status' window is non-focusable, and,
	after the previous couple of commits, trying to focus the status
	window will result in an error.

	This commit improves the tab-completion results for the focus command
	so that the status window is not included.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/tui: convert if/error to an assert
	While working on the previous commit, I realised that there was an
	error in tui_set_focus_command that could never be triggered.

	Since the big tui rewrite (adding dynamic layouts) it is no longer
	true that there is a tui_win_info object for every window at all
	times.  We now only create a tui_win_info object for a particular
	window, when the window is part of the current layout.  As a result,
	if we have a tui_win_info pointer, then the window must be visible
	inside tui_set_focus_command (this function calls tui_enable as its
	first action, which makes the current layout visible).

	The gdb.tui/tui-focus.exp test script exercises this area of code, and
	doesn't trigger the assert, nor do any of our other existing tui
	tests.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite/tui: more testing of the 'focus' command
	I noticed that we didn't have many tests of the tui 'focus' command,
	so I started adding some.  This exposed a bug in GDB; we are able to
	focus windows that should not be focusable, e.g. the 'status' window.

	This is harmless until we then do 'focus next' or 'focus prev', along
	this code path we assert that the currently focused window is
	focusable, which obviously, is not always true, so GDB fails with an
	assertion error.

	The fix is simple; add a check to the tui_set_focus_command function
	to ensure that the selected window is focusable.  If it is not then an
	error is thrown.  The new tests I've added cover this case.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: update gdb.tui/tui-nl-filtered-output.exp
	Following on from the previous commit, in this commit I am updating
	the test script gdb.tui/tui-nl-filtered-output.exp to take account of
	the changes in commit:

	  commit 9162a27c5f5828240b53379d735679e2a69a9f41
	  Date:   Tue Nov 13 11:59:03 2018 -0700

	      Change gdb test suite's TERM setting

	In the above commit the TERM environment variable was changed to be
	'dumb' by default, which means that tests, that previously activated
	tui mode, no longer do unless TERM is set to 'ansi'.

	As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the
	test stopped working.  As the expect patterns in this script were
	pretty generic no tests actually started failing, and we never
	noticed.

	In this commit I update the test script to correctly activate our
	terminal emulator, the test continues to pass after this update, but
	now we are testing in tui mode.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp
	Following on from the previous commit, in this commit I am updating
	the test script gdb.tui/tui-disasm-long-lines.exp to take account of
	the changes in commit:

	  commit 9162a27c5f5828240b53379d735679e2a69a9f41
	  Date:   Tue Nov 13 11:59:03 2018 -0700

	      Change gdb test suite's TERM setting

	In the above commit the TERM environment variable was changed to be
	'dumb' by default, which means that tests, that previously activated
	tui mode, no longer do unless TERM is set to 'ansi'.

	As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the
	test stopped working.  As the expect patterns in this script were
	pretty generic no tests actually started failing, and we never
	noticed.

	In this commit I update the script to use Term::clean_restart, which
	correctly sets TERM to 'ansi'.  I've also added a check that the asm
	box does appear on the screen, which should indicate that tui mode has
	correctly activated.

	However, I also notice that GDB doesn't appear to fully work
	correctly.  The test should display the disassembly for the test
	program, but it doesn't.

	The test is trying to disassemble some code that (deliberately) uses a
	very long symbol name, this eventually results in GDB entering
	tui_source_window_base::show_source_content and trying to allocate an
	ncurses pad in order to hold the current page of disassembler output.

	Unfortunately, due to the very long line, the call to newpad fails,
	meaning that tui_source_window_base::m_pad is nullptr.  Luckily non of
	the following calls appear to crash when passed a nullptr, however,
	all the output that is written to the pad is lost, which is why we
	don't see any assembly code written to the screen.

	As the test history indicates that the script was originally checking
	for a crash in GDB when the long identifier was encountered, I think
	there is value in just leaving the test as it is for now, I have a fix
	for the issue of the newpad call failing, which I'll post in a follow
	up commit later.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: extend gdb.tui/tui-layout.exp test script
	In passing I noticed that the gdb.tui/tui-layout.exp test script was a
	little strange, it tests the layout command multiple times, but never
	sets up our ANSI terminal emulator, so every layout command fails with
	a message about the terminal lacking the required abilities.

	It turns out that this was caused by this commit:

	  commit 9162a27c5f5828240b53379d735679e2a69a9f41
	  Date:   Tue Nov 13 11:59:03 2018 -0700

	      Change gdb test suite's TERM setting

	This was when we changed the testsuite to set the TERM environment
	variable to "dumb" by default.

	After this, any tui test that didn't set the terminal mode back to
	'ansi' would fail to activate tui mode.

	For the tui-layout.exp test it just so happens that the test patterns
	are generic enough that the test continued to pass, even after this
	change.

	In this commit I have updated the test so we now check the layout
	command both with a 'dumb' terminal and with the 'ansi' terminal.
	When testing with the 'ansi' terminal, I have some limited validation
	that GDB correctly entered tui mode.

	I figured that it is probably worth having at least one test in the
	test suite that deliberately tries to enter tui mode in a dumb
	terminal, it would be sad if we one day managed to break GDB such that
	this caused a crash, and never noticed.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: rename test source file to match test script
	The previous commit touched the source file for the test script
	gdb.cp/cpcompletion.exp.  This source file is called pr9594.cc.  The
	source file is only used by the one test script.

	This commit renames the source file to cpcompletion.cc to match the
	test script, this is more inline with how we name source files these
	days.

2023-01-25  Andrew Burgess  <aburgess@redhat.com>

	gdb/testsuite: use test_gdb_complete_unique more in C++ tests
	Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of
	gdb_test with test_gdb_complete_unique, this will extend the
	completion testing to check tab-completion as well as completion using
	the 'complete' command in some additional cases.

2023-01-25  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-24  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: PR29521 [docs] man pages are not in the release tarball
	gprofng/ChangeLog
	2023-01-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/29521
		* configure.ac: Check if $MAKEINFO and $HELP2MAN are missing.
		* Makefile.am: Build doc if $MAKEINFO exists.
		* doc/gprofng.texi: Update documentation for gprofng.
		* doc/Makefile.am: Build gprofng.1.
		* src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am.
		* configure: Rebuild.
		* Makefile.in: Rebuild.
		* doc/Makefile.in: Rebuild.
		* src/Makefile.in: Rebuild.

2023-01-24  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe/doc: fix some warnings
	'make pdf' in libsframe shows some warnings, some of which (especially
	the Overfull warnings) are causing undesirable effects on the rendered
	output.  Few examples of the warnings:

	  Underfull \hbox (badness 10000) in paragraph at lines 406--407
	   @texttt pauth_

	  Underfull \hbox (badness 10000) in paragraph at lines 407--410
	   @textrm Specify which key is used for signing the return

	  ...

	  Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413
	   @texttt fdetype[]|

	  ...

	  Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447
	   @textrm SFRAME[]FDE[]TYPE[]PCMASK|

	  ...

	This patch adjusts column widths of the affected cells to fix a subset
	of these warnings.  For the rest of the warnings, use explicit newline
	command to fix them.

	libsframe/
		* doc/sframe-spec.texi: Fix various underfull and overfull
		warnings.

2023-01-24  Nick Clifton  <nickc@redhat.com>

	Fix seg-fault when generating an empty DLL with LTO enabled.
	ld   PR 29998
	     * pe-dll.c (generate_reloc): Handle sections
	     with no assigned output section.
	     Terminate early of there are no relocs to put
	     in the .reloc section.
	     (pe_exe_fill_sections): Do not emit an empty
	     .reloc section.

	bfd  * cofflink.c (_bfd_coff_generic_relocate_section):
	     Add an assertion that the output section is set
	     for defined, global symbols.

2023-01-24  Enze Li  <enze.li@hotmail.com>

	gdb: some int to bool conversion
	When building GDB with clang 16, I got this,

	  CXX    maint.o
	maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	      m_space_enabled = 1;
	                      ^ ~
	maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	      m_time_enabled = 1;
	                     ^ ~
	maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
	      m_symtab_enabled = 1;
	                       ^ ~
	3 errors generated.

	Work around this by using bool bitfields instead.

	Tested by rebuilding on x86_64-linux with clang 16 and gcc 12.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-01-24  Mark Harmstone  <mark@harmstone.com>

	ld: Avoid magic numbers for subsystems in pe.em and pep.em

2023-01-24  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-23  Mark Harmstone  <mark@harmstone.com>

	ld: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI
	This fixes the test failures introduced by 87a5cf5c, by changing the
	default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to
	2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other
	PE targets.

	As far as I can tell there's no working modern Windows CE toolchain
	knocking about anyway, so this change shouldn't inconvenience anyone.

2023-01-23  Mark Harmstone  <mark@harmstone.com>

	Add support for secidx relocations to aarch64-w64-mingw32
	This patch adds support for the .secidx directive and its corresponding
	relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE
	integer which gets filled in with the 1-based index of the output
	section that a symbol ends up in.

	This is needed for PDBs, which represent addresses as a .secrel32,
	.secidx pair.

	The test is substantially the same as for amd64, but with changes made
	for padding and alignment.

2023-01-23  Tom de Vries  <tdevries@suse.de>

	[gdb/tdep, aarch64] Fix frame address of last insn
	Consider the test-case test.c, compiled without debug info:
	...
	void
	foo (const char *s)
	{
	}

	int
	main (void)
	{
	  foo ("foo");
	  return 0;
	}
	...

	Disassembly of foo:
	...
	0000000000400564 <foo>:
	  400564:       d10043ff        sub     sp, sp, #0x10
	  400568:       f90007e0        str     x0, [sp, #8]
	  40056c:       d503201f        nop
	  400570:       910043ff        add     sp, sp, #0x10
	  400574:       d65f03c0        ret
	...

	Now, let's do "info frame" at each insn in foo, as well as printing $sp
	and $x29 (and strip the output of info frame to the first line, for brevity):
	...
	$ gdb -q a.out
	Reading symbols from a.out...
	(gdb) b *foo
	Breakpoint 1 at 0x400564
	(gdb) r
	Starting program: a.out

	Breakpoint 1, 0x0000000000400564 in foo ()
	(gdb) display /x $sp
	1: /x $sp = 0xfffffffff3a0
	(gdb) display /x $x29
	2: /x $x29 = 0xfffffffff3a0
	(gdb) info frame
	Stack level 0, frame at 0xfffffffff3a0:
	(gdb) si
	0x0000000000400568 in foo ()
	1: /x $sp = 0xfffffffff390
	2: /x $x29 = 0xfffffffff3a0
	(gdb) info frame
	Stack level 0, frame at 0xfffffffff3a0:
	(gdb) si
	0x000000000040056c in foo ()
	1: /x $sp = 0xfffffffff390
	2: /x $x29 = 0xfffffffff3a0
	(gdb) info frame
	Stack level 0, frame at 0xfffffffff3a0:
	(gdb) si
	0x0000000000400570 in foo ()
	1: /x $sp = 0xfffffffff390
	2: /x $x29 = 0xfffffffff3a0
	(gdb) info frame
	Stack level 0, frame at 0xfffffffff3a0:
	(gdb) si
	0x0000000000400574 in foo ()
	1: /x $sp = 0xfffffffff3a0
	2: /x $x29 = 0xfffffffff3a0
	(gdb) info frame
	Stack level 0, frame at 0xfffffffff3b0:
	 pc = 0x400574 in foo; saved pc = 0x40058c
	(gdb) si
	0x000000000040058c in main ()
	1: /x $sp = 0xfffffffff3a0
	2: /x $x29 = 0xfffffffff3a0
	...

	The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
	lists 0xfffffffff3b0.

	The frame address is calculated here in aarch64_make_prologue_cache_1:
	...
	  unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
	  if (unwound_fp == 0)
	    return;

	  cache->prev_sp = unwound_fp + cache->framesize;
	...

	For insns after the prologue, we have cache->framereg == sp and
	cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
	answer once sp has been restored to entry value by the before-last insn.

	Fix this by detecting the situation that the sp has been restored.

	This fixes PRs tdep/30010 and tdep/30011.

	This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
	gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.

	Tested on aarch64-linux.
	PR tdep/30010
	PR tdep/30011
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011

2023-01-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp
	One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
	architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
	compiled with nodebug, to prevent the dwarf unwinders from taking effect.

	For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
	default, generating an .eh_frame section contribution which might enable the
	dwarf unwinders and bypass the architecture-specific unwinders.

	Currently, that happens to be not the case due to the current implementation
	of epilogue_unwind_valid, which assumes that in absence of debug info proving
	that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.

	That may change though, see PR30028, in which case
	gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
	49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").

	Fix this by making sure that we don't use .eh_frame info regardless of
	epilogue_unwind_valid, simply by not generating it using
	-fno-asynchronous-unwind-tables.

	Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
	gcc 7.5.0 and clang 13.0.1.

2023-01-23  Nick Clifton  <nickc@redhat.com>

	Updated Swedish translation for the binutils sub-directory

2023-01-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp
	In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
	disassembled insn in function foo.

	This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
	fix for gdb.base/unwind-on-each-insn.exp").

	The use of the last disassembled insn in the test-case is to stop stepping in
	foo once reaching it.

	However, the intent is to stop stepping just before returning to main.

	There is no guarantee that the last disassembled insn:
	- is actually executed
	- is executed just before returning to main
	- is executed only once.

	Fix this by simplying the test-case to continue stepping till stepping out of
	foo.

	Tested on x86_64-linux.

2023-01-23  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix untested in gdb.base/frame-view.exp
	When running test-case gdb.base/frame-view.exp, I see:
	...
	gdb compile failed, ld: frame-view0.o: in function `main':
	frame-view.c:73: undefined reference to `pthread_create'
	ld: frame-view.c:76: undefined reference to `pthread_join'
	collect2: error: ld returned 1 exit status
	UNTESTED: gdb.base/frame-view.exp: failed to prepare
	...

	Fix this by adding pthreads to the compilation flags.

	Tested on x86_64-linux.

2023-01-23  Vladislav Khmelevsky  <och95@yandex.ru>

	Fix objdump --reloc for specific symbol
	If objdump is used with both --disassemble=symbol and --reloc options
	skip relocations that have addresses before the symbol, so that they
	are not displayed.

2023-01-23  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-22  Tom Tromey  <tom@tromey.com>

	Remove path name from test
	The test suite reports several path names in tests.  I couldn't find
	most of these, and I suspect they are false reports, but I did manage
	to locate one.  This one is probably harmless, as I think the path
	does not vary; but it's also easy to fix and suppress one warning.

	Minor cleanup in gdb.btrace/enable.exp
	I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
	left over from an earlier change.  This patch moves the "!" inside the
	braces, where it belongs.

	Minor fixup in allow_aarch64_sve_tests
	An earlier patch failed to update a string in allow_aarch64_sve_tests.

2023-01-22  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-21  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make frame_info_ptr auto-reinflatable
	This is the second step of making frame_info_ptr automatic, reinflate on
	demand whenever trying to obtain the wrapper frame_info pointer, either
	through the get method or operator->.  Make the reinflate method
	private, it is used as a convenience method in those two.

	Add an "is_null" method, because it is often needed to know whether the
	frame_info_ptr wraps an frame_info or is empty.

	Make m_ptr mutable, so that it's possible to reinflate const
	frame_info_ptr objects.  Whether m_ptr is nullptr or not does not change
	the logical state of the object, because we re-create it on demand.  I
	believe this is the right use case for mutable.

	Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make frame_info_ptr grab frame level and id on construction
	This is the first step of making frame_info_ptr automatic.  Remove the
	frame_info_ptr::prepare_reinflate method, move that code to the
	constructor.

	Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make user-created frames reinflatable
	This patch teaches frame_info_ptr to reinflate user-created frames
	(frames created through create_new_frame, with the "select-frame view"
	command).

	Before this patch, frame_info_ptr doesn't support reinflating
	user-created frames, because it currently reinflates by getting the
	current target frame (for frame 0) or frame_find_by_id (for other
	frames).  To reinflate a user-created frame, we need to call
	create_new_frame, to make it lookup an existing user-created frame, or
	otherwise create one.

	So, in prepare_reinflate, get the frame id even if the frame has level
	0, if it is user-created.  In reinflate, if the saved frame id is user
	create it, call create_new_frame.

	In order to test this, I initially enhanced the gdb.base/frame-view.exp
	test added by the previous patch by setting a pretty-printer for the
	type of the function parameters, in which we do an inferior call.  This
	causes print_frame_args to not reinflate its frame (which is a
	user-created one) properly.  On one machine (my Arch Linux one), it
	properly catches the bug, as the frame is not correctly restored after
	printing the first parameter, so it messes up the second parameter:

	    frame
	    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
	    40        return z1.m + z2.n;
	    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
	    frame
	    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
	    40        return z1.m + z2.n;
	    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again

	However, on another machine (my Ubuntu 22.04 one), it just passes fine,
	without the appropriate fix.  I then thought about writing a selftest
	for that, it's more reliable.  I left the gdb.base/frame-view.exp pretty
	printer test there, it's already written, and we never know, it might
	catch some unrelated issue some day.

	Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: make it possible to restore selected user-created frames
	I would like to improve frame_info_ptr to automatically grab the
	information needed to reinflate a frame, and automatically reinflate it
	as needed.  One thing that is in the way is the fact that some frames
	can be created out of thin air by the create_new_frame function.  These
	frames are not the fruit of unwinding from the target's current frame.
	These frames are created by the "select-frame view" command.

	These frames are not correctly handled by the frame save/restore
	functions, save_selected_frame, restore_selected_frame and
	lookup_selected_frame.  This can be observed here, using the test
	included in this patch:

	    $ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view
	    Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view...
	    (gdb) break thread_func
	    Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42.
	    (gdb) run
	    Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view

	    [Thread debugging using libthread_db enabled]
	    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
	    [New Thread 0x7ffff7cc46c0 (LWP 4171134)]
	    [Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)]

	    Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
	    42        foo (11);
	    (gdb) info frame
	    Stack level 0, frame at 0x7ffff7cc3ee0:
	     rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd
	     called by frame at 0x7ffff7cc3f80
	     source language c.
	     Arglist at 0x7ffff7cc3ed0, args: p=0x0
	     Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0
	     Saved registers:
	      rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8
	    (gdb) thread 1
	    [Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))]
	    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

	Here, we create a custom frame for thread 1 (using the stack from thread
	2, for convenience):

	    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2

	The first calls to "frame" looks good:

	    (gdb) frame
	    #0  thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
	    42        foo (11);

	But not the second one:

	    (gdb) frame
	    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

	This second "frame" command shows the current target frame instead of
	the user-created frame.

	It's not totally clear how the "select-frame view" feature is expected
	to behave, especially since it's not tested.  I heard accounts that it
	used to be possible to select a frame like this and do "up" and "down"
	to navigate the backtrace starting from that frame.  The fact that
	create_new_frame calls frame_unwind_find_by_frame to install the right
	unwinder suggest that it used to be possible.  But that doesn't work
	today:

	    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
	    (gdb) up
	    Initial frame selected; you cannot go up.
	    (gdb) down
	    Bottom (innermost) frame selected; you cannot go down.

	and "backtrace" always shows the actual thread's backtrace, it ignores
	the user-created frame:

	    (gdb) bt
	    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
	    #1  0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6
	    #2  0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56

	I don't want to address all the `select-frame view` issues , but I think
	we can agree that the "frame" command changing the selected frame, as
	shown above, is a bug.  I would expect that command to show the
	currently selected frame and not change it.

	This happens because of the scoped_restore_selected_frame object in
	print_frame_args.  The frame information is saved in the constructor
	(the backtrace below), and restored in the destructor.

	    #0  save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682
	    #1  0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324
	    #2  0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755
	    #3  0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401
	    #4  0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126
	    #5  0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368
	    #6  0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346
	    #7  0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993
	    #8  0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871
	    #9  0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976

	Since the user-created frame has level 0 (identified by the saved level
	-1), lookup_selected_frame just reselects the target's current frame,
	and the user-created frame is lost.

	My goal here is to fix this particular problem.

	Currently, select_frame does not set selected_frame_id and
	selected_frame_level for frames with level 0.  It leaves them at
	null_frame_id / -1, indicating to restore_selected_frame to use the
	target's current frame.  User-created frames also have level 0, so add a
	special case them such that select_frame saves their selected id and
	level.

	save_selected_frame does not need any change.

	Change the assertion in restore_selected_frame that checks `frame_level
	!= 0` to account for the fact that we can restore user-created frames,
	which have level 0.

	Finally, change lookup_selected_frame to make it able to re-create
	user-created frame_info objects from selected_frame_level and
	selected_frame_id.

	Add a minimal test case for the case described above, that is the
	"select-frame view" command followed by the "frame" command twice.  In
	order to have a known stack frame to switch to, the test spawns a second
	thread, and tells the first thread to use the other thread's top frame.

	Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add create_new_frame(frame_id) overload
	The subsequent patches will need to call create_new_frame with an
	existing frame_id representing a user created frame.  They could call
	the existing create_new_frame, passing both addresses, but it seems
	nicer to have a version of the function that takes a frame_id directly.

	Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add user-created frames to stash
	A subsequent patch makes it possible for frame_info_ptr to reinflate
	user-created frames.  If two frame_info_ptr objects wrapping the same
	user-created frame_info need to do reinflation, we want them to end up
	pointing to the same frame_info instance, and not create two separate
	frame_infos.  Otherwise, GDB gets confused down the line, as the state
	kept in one frame_info object starts differing from the other
	frame_info.

	Achieve this by making create_new_frame place the user-created frames in
	the frame stash.  This way, when the second frame_info_ptr does
	reinflation, it will find the existing frame_info object, created by the
	other frame_info_ptr, in the frame stash.

	To make the frame stash differentiate between regular and user-created
	frame infos which would otherwise be equal, change frame_addr_hash and
	frame_id::operator== to account for frame_id::user_created_p.

	I made create_new_frame look up existing frames in the stash, and only
	create one if it doesn't find one.  The goal is to avoid the
	"select-frame view"/"info frame view"/"frame view" commands from
	overriding existing entries into the stash, should the user specify the
	same frame more than once.  This will also help in the subsequent patch
	that makes frame_info_ptr capable of reinflating user-created frames.
	It will be able to just call create_new_frame and it will do the right
	thing.

	Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: add frame_id::user_created_p
	Later in this series, we'll need to differentiate frame ids for regular
	frames (obtained from the target state and unwinding from it) vs frame
	ids for user-created frames (created with create_new_frame).  Add the
	frame_id::user_created_p field to indicate a frame is user-created, and
	set it in create_new_frame.

	The field is otherwise not used yet, so not changes in behavior are
	expected.

	Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: move frame_info_ptr to frame.{c,h}
	A patch later in this series will make frame_info_ptr access some
	fields internal to frame_info, which we don't want to expose outside of
	frame.c.  Move the frame_info_ptr class to frame.h, and the definitions
	to frame.c.  Remove frame-info.c and frame-info.h.

	Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move call site types to call-site.h
	I hesitated between putting  the file in the dwarf2 directory (as
	gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
	The concept of call site is not DWARF-specific, another debug info
	reader could provide this information.  But as it is, the implementation
	is a bit DWARF-specific, as one form it can take is a DWARF expression
	and parameters can be defined using a DWARF register number.  So I ended up
	choosing to put it under dwarf2/.  If another debug info reader ever
	wants to provide call site information, we can introduce a layer of
	abstraction between the "common" call site and the "dwarf2" call site.

	The copyright start year comes from the date `struct call_site` was
	introduced.

	Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move sect_offset and cu_offset to dwarf2/types.h
	I want to move the call_site stuff out of gdbtypes.h, to a new header
	file, to break some cyclic include problem.  The call_site stuff uses
	cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move
	somewhere else (otherwise, call-site.h will need to include gdbtypes.h,
	and we are back to square 1).  I could move cu_offset to the future new
	file dwarf2/call-site.h, but it doesn't sound like a good place for it,
	at cu_offset is not specific to call sites, it's used throughout
	dwarf2/.  So, move it to its own file, dwarf2/types.h.  For now,
	gdbtypes.h includes dwarf2/types.h, but that will be removed once the
	call site stuff is moved to its own file.

	Move sect_offset with it too.  sect_offset is not a DWARF-specific
	concept, but for the moment it is only used in dwarf2/.

	Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: remove language.h include from frame.h
	This helps resolve some cyclic include problem later in the series.
	The only language-related thing frame.h needs is enum language, and that
	is in defs.h.

	Doing so reveals that a bunch of files were relying on frame.h to
	include language.h, so fix the fallouts here and there.

	Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move compile_instance to compile/compile.h
	struct compile_instance needs to be visible to users, since we use
	std::unique<compile_instance>.  language.c and c-lang.c currently
	includes compile-internal.h for this reason, which kind of defeats the
	purpose of having an "internal" header file.

	Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Simon Marchi  <simon.marchi@efficios.com>

	gdb: move type_map_instance to compile/compile.c
	It's only used in compile/compile.c, it doesn't need to be in a header.

	Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-20  Indu Bhagat  <indu.bhagat@oracle.com>

	Upload SFrame spec files as well
	binutils/
		* README-how-to-make-a-release: Include sframe-spec html and pdf
		files.

2023-01-20  Tom Tromey  <tom@tromey.com>

	Use bool in pc_in_* functions
	I noticed that pc_in_unmapped_range had a weird return type -- it was
	returning a CORE_ADDR but intending to return a bool.  This patch
	changes all the pc_in_* functions to return bool instead.

2023-01-20  Tom Tromey  <tromey@adacore.com>

	Constify notif_client
	It seems to me that a notif_client is read-only, so this patch changes
	the code to use "const" everywhere.

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: remove struct trad_frame forward declaration
	I found this forward declaration for a struct that doesn't exist, remove
	it.

	Change-Id: Ib9473435a949452160598035e5e0fe19fcdc4d20

2023-01-20  Tom Tromey  <tromey@adacore.com>

	Make gdb.ada/ptype_tagged_param.exp pass
	gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
	However, it's actually generating the correct output -- it is just
	that the test thinks that the "ptype" will not work because I do not
	have the GNAT debuginfo installed.

	This patch changes the code to accept either result, and then to issue
	a kfail as appropriate.

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/dwarf: fix UBsan crash in read_subrange_type
	When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the
	`gnat-11` package installed (not `gnat`), with UBSan activated, I get:

	    (gdb) break foo.adb:40
	    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int'

	The problematic DIEs are:

	    0x00001460:       DW_TAG_subrange_type
	                        DW_AT_lower_bound [DW_FORM_data1]   (0x00)
	                        DW_AT_upper_bound [DW_FORM_data16]  (ffffffffffffffff3f00000000000000)
	                        DW_AT_name [DW_FORM_strp]   ("foo__packed_array___XP7___XDLU_0__1180591620717411303423")
	                        DW_AT_type [DW_FORM_ref4]   (0x0000153f "long_long_long_unsigned")
	                        DW_AT_GNAT_descriptive_type [DW_FORM_ref4]  (0x0000147e)
	                        DW_AT_artificial [DW_FORM_flag_present]     (true)

	    0x0000153f:   DW_TAG_base_type
	                    DW_AT_byte_size [DW_FORM_data1] (0x10)
	                    DW_AT_encoding [DW_FORM_data1]  (DW_ATE_unsigned)
	                    DW_AT_name [DW_FORM_strp]       ("long_long_long_unsigned")
	                    DW_AT_artificial [DW_FORM_flag_present] (true)

	When processed by this code:

	    negative_mask =
	      -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
	    if (low.kind () == PROP_CONST
	        && !base_type->is_unsigned () && (low.const_val () & negative_mask))
	      low.set_const_val (low.const_val () | negative_mask);

	When the base type's length (16 bytes in this case) is larger than a
	ULONGEST (typically 8 bytes), the bit shift is too large.

	My obvious fix is just to skip the fixup for base types larger than a
	ULONGEST (8 bytes).  I don't think we really handle constant attribute
	values larger than 8 bytes anyway, so this is part of a much larger
	problem.

	Add a test that replicates this situation, but uses bounds that fit in a
	signed 64 bit, so we get a sensible result.

	Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386

2023-01-20  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: add test for negative subrange bounds with unsigned form
	I am looking at this code [1]:

	  /* Normally, the DWARF producers are expected to use a signed
	     constant form (Eg. DW_FORM_sdata) to express negative bounds.
	     But this is unfortunately not always the case, as witnessed
	     with GCC, for instance, where the ambiguous DW_FORM_dataN form
	     is used instead.  To work around that ambiguity, we treat
	     the bounds as signed, and thus sign-extend their values, when
	     the base type is signed.  */
	  negative_mask =
	    -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
	  if (low.kind () == PROP_CONST
	      && !base_type->is_unsigned () && (low.const_val () & negative_mask))
	    low.set_const_val (low.const_val () | negative_mask);
	  if (high.kind () == PROP_CONST
	      && !base_type->is_unsigned () && (high.const_val () & negative_mask))
	    high.set_const_val (high.const_val () | negative_mask);

	Nothing in the testsuite seems to exercise it, as when I remove it, all
	of gdb.dwarf2 still passes.  And tests in other directories would be
	compiler-dependent, so would rely on having a buggy compiler.

	Update gdb.dwarf2/subrange.exp to have a test for it.  When removing the
	code above, the new test fails with:

	  ptype array_with_buggy_negative_bounds_type^M
	  type = array [240..244] of signed_byte^M
	  (gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type

	instead of the expected:

	  ptype array_with_buggy_negative_bounds_type^M
	  type = array [-16..-12] of signed_byte^M
	  (gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type

	[1] https://gitlab.com/gnutools/binutils-gdb/-/blob/5ea14aa4e53fa37f4ba4517497ed2c1e4c60dee2/gdb/dwarf2/read.c#L17681-17695

	Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2

2023-01-20  Michael Matz  <matz@suse.de>

	Add testcase ld-elf/merge4
	to check a situation that once failed with the new section merging
	when it mishandled offsets pointing into alignment padding in mergable
	string sections (i.e. pointing to zeros).  It made bootstrap.exp fail
	but that depends on many factors to actually go wrong so this is a more
	explicit variant of it.

2023-01-20  Michael Matz  <matz@suse.de>

	arm32: Fix rodata-merge-map
	the test expects a second, but useless, $d mapping symbol for
	the partially merged section, and specifically disallows one
	for the completely merged section.  The new merging algorithm
	makes it so that also the partially merged sections are conceptually
	SEC_EXCLUDED, except the first merge section (e.g. as if the very
	first object file already contains all strings).  So that second mapping
	symbol is now missing.  It never was needed anyway.

	So, adjust the test.

2023-01-20  Michael Matz  <matz@suse.de>

	Faster string merging
	* use power-of-two hash table
	* use better hash function (hashing 32bits at once and with better
	  mixing characteristics)
	* use input-offset-to-entry maps instead of retaining full input
	  contents for lookup time
	* don't reread SEC_MERGE section multiple times
	* care for cache behaviour for the hot lookup routine

	The overall effect is less usage in libz and much faster string merging
	itself.  On a debug-info-enabled cc1 the effect at the time of this
	writing on the machine I used was going from 14400 perf samples to 9300
	perf samples or from 3.7 seconds to 2.4 seconds, i.e. about 33% .

2023-01-20  Frederic Cambus  <fred@statdns.com>

	Add OpenBSD ARM GAS support.

2023-01-20  Jan Beulich  <jbeulich@suse.com>

	x86: split i386-gen's opcode hash entry struct
	All glibc malloc() implementations I've checked have a smallest
	allocation size worth of 3 pointers, with an increment worth of 2
	pointers. Hence mnemonics with multiple templates can be stored more
	efficiently when maintaining the shared "name" field only in the actual
	hash entry. (To express the shared nature, also convert "name" to by
	pointer-to-const.)

	While doing the conversation also pull out common code from the involved
	if/else construct in expand_templates().

2023-01-20  Jan Beulich  <jbeulich@suse.com>

	x86: embed register and alike names in disassembler
	Register names are (including their nul terminators) on average almost 4
	bytes long. Otoh no register name is longer than 8 bytes. Hence even for
	32-bit builds using a pointer is only slightly more space efficient than
	embedding the strings. A level of indirection can be also avoided by
	embedding the names as an array of 8 characters directly in the arrays,
	and the number of base relocations in libopcodes.so (or PIE builds of
	statically linked executables) goes down as well.

	To amortize for the otherwise reduced folding of string literals by the
	linker, use att_names_seg[] in place of string literals in append_seg()
	and OP_ESreg().

2023-01-20  Jan Beulich  <jbeulich@suse.com>

	x86: embed register names in reg_entry
	Register names are (including their nul terminators) on average almost 4
	bytes long. Otoh no register name is longer than 7 bytes. Hence even for
	32-bit builds using a pointer is only slightly more space efficient than
	embedding the strings. A level of indirection can be also avoided by
	embedding the names as an array of 8 characters directly in the struct,
	and the number of base relocations in PIE builds of gas goes down as
	well.

	x86: avoid strcmp() in a few places
	Now that we have identifiers for the mnemonic strings we can avoid
	strcmp() in a number of places, comparing the offsets into the mnemonic
	string table instead. While doing this also
	- convert a leftover strncmp() to startswith() (apparently an oversight
	  when rebasing the original patch introducing the startswith() uses),
	- use the new shorthand for current_templates->start also elsewhere in
	  md_assemble() (valid up to the point where match_template() is
	  called).

	x86: absorb allocation in i386-gen
	When generating the mnemonic string table we already set up an
	identifier for the following entry in a number of cases. Re-use that on
	the next loop iteration rather than re-doing allocation and conversion.

	x86: re-use insn mnemonic strings as much as possible
	Compact the mnemonic string table such that the tails of longer
	mnemonics are re-used for shorter ones, going beyond what compilers
	would typically do, but matching what ELF linkers may do when processing
	SHF_MERGE|SHF_STRINGS sections. This reduces table size by about 12.5%.

2023-01-20  Jan Beulich  <jbeulich@suse.com>

	x86: move insn mnemonics to a separate table
	Using full pointers to reference the insn mnemonic strings is not very
	efficient. With overall string size presently just slightly over 20k,
	even a 16-bit value would suffice. Use "unsigned int" for now, as
	there's no good use we could presently make of the otherwise saved 16
	bits.

	For 64-bit builds this reduces table size by 6.25% (prior to the recent
	ISA extension additions it would have been 12.5%), with a similar effect
	on cache occupation of table entries accessed. For PIE builds of gas
	this also reduces the number of base relocations quite a bit (obviously
	independent of bitness).

2023-01-20  Jan Beulich  <jbeulich@suse.com>

	x86: abstract out obtaining of a template's mnemonic
	In preparation for changing the representation of the "name" field
	introduce a wrapper function. This keeps the mechanical change separate
	from the functional one.

2023-01-20  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-19  Tom Tromey  <tromey@adacore.com>

	Use "maint ignore-probes" in no-libstdcxx-probe.exp
	While looking at some test output, I saw that no-libstdcxx-probe.exp
	was not being run.  However, it occurred to me that Tom de Vries' new
	"maint ignore-probes" command could be used to enable this test
	unconditionally.

	Reviewed-by: Tom de Vries <tdevries@suse.de>

2023-01-19  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	i386: Don't emit unsupported TLS relocs on Solaris
	Emit R_386_TLS_LE and R_386_TLS_IE, instead of R_386_TLS_LE_32 and
	R_386_TLS_IE_32, on Solaris.

		PR ld/13671
		* elf32-i386.c (elf_i386_tls_transition): Only emit R_386_TLS_LE,
		R_386_TLS_IE on Solaris.
		(elf_i386_relocate_section): Only use R_386_TLS_GD->R_386_TLS_LE
		transition on Solaris.

	Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>

2023-01-19  Andrew Burgess  <andrew.burgess@embecosm.com>

	GDB/testsuite: Expand for character string limiting options
	Modify test cases that verify the operation of the array element limit
	with character strings such that they are executed twice, once with the
	`set print characters' option set to `elements' and the limit controlled
	with the `set print elements' option, and then again with the limit
	controlled with the `set print characters' option instead.  Similarly
	with the `-elements' and `-characters' options for the `print' command.
	Additionally verify that said `print' command options combined yield the
	expected result.

	Verify correct $_gdb_setting and $_gdb_setting_str values for the `print
	characters' setting, in particular the `void' value for the `elements'
	default, which has no corresponding integer value exposed.

	Add Guile and Python coverage for the `print characters' GDB setting.

	There are new tests for Ada and Pascal, as the string printing code for
	these languages is different than the generic string printing code used
	by other languages.  Modula2 also has different string printing code,
	but (a) this is similar to Pascal, and (b) there are no existing modula2
	tests written in Modula2, so I'm not sure how I'd even test the Modula2
	string printing.

	Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-19  Andrew Burgess  <andrew.burgess@embecosm.com>

	GDB: Add a character string limiting option
	This commit splits the `set/show print elements' option into two.  We
	retain `set/show print elements' for controlling how many elements of an
	array we print, but a new `set/show print characters' setting is added
	which is used for controlling how many characters of a string are
	printed.

	The motivation behind this change is to allow users a finer level of
	control over how data is printed, reflecting that, although strings can
	be thought of as arrays of characters, users often want to treat these
	two things differently.

	For compatibility reasons by default the `set/show print characters'
	option is set to `elements', which makes the limit for character strings
	follow the setting of the `set/show print elements' option, as it used
	to.  Using `set print characters' with any other value makes the limit
	independent from the `set/show print elements' setting, however it can
	be restored to the default with the `set print characters elements'
	command at any time.

	A corresponding `-characters' option for the `print' command is added,
	with the same semantics, i.e. one can use `elements' to make a given
	`print' invocation follow the limit of elements, be it set with the
	`-elements' option also given with the same invocation or taken from the
	`set/show print elements' setting, for characters as well regardless of
	the current setting of the `set/show print characters' option.

	The GDB changes are all pretty straightforward, just changing references
	to the old 'print_max' to use a new `get_print_max_chars' helper which
	figures out which of the two of `print_max' and `print_max_chars' values
	to use.

	Likewise, the documentation is just updated to reference the new setting
	where appropriate.

	To make people's life easier the message shown by `show print elements'
	now indicates if the setting also applies to character strings:

	(gdb) set print characters elements
	(gdb) show print elements
	Limit on string chars or array elements to print is 200.
	(gdb) set print characters unlimited
	(gdb) show print elements
	Limit on array elements to print is 200.
	(gdb)

	and the help text shows the dependency as well:

	(gdb) help set print elements
	Set limit on array elements to print.
	"unlimited" causes there to be no limit.
	This setting also applies to string chars when "print characters"
	is set to "elements".
	(gdb)

	In the testsuite there are two minor updates, one to add `-characters'
	to the list of completions now shown for the `print' command, and a bare
	minimum pair of checks for the right handling of `set print characters'
	and `show print characters', copied from the corresponding checks for
	`set print elements' and `show print elements' respectively.

	Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-19  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Allow arbitrary keywords in integer set commands
	Rather than just `unlimited' allow the integer set commands (or command
	options) to define arbitrary keywords for the user to use, removing
	hardcoded arrangements for the `unlimited' keyword.

	Remove the confusingly named `var_zinteger', `var_zuinteger' and
	`var_zuinteger_unlimited' `set'/`show' command variable types redefining
	them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
	have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.

	Following existing practice `var_pinteger' allows extra negative values
	to be used, however unlike `var_zuinteger_unlimited' any number of such
	values can be defined rather than just `-1'.

	The "p" in `var_pinteger' stands for "positive", for the lack of a more
	appropriate unambiguous letter, even though 0 obviously is not positive;
	"n" would be confusing as to whether it stands for "non-negative" or
	"negative".

	Add a new structure, `literal_def', the entries of which define extra
	keywords allowed for a command and numerical values they correspond to.
	Those values are not verified against the basic range supported by the
	underlying variable type, allowing extra values to be allowed outside
	that range, which may or may not be individually made visible to the
	user.  An optional value translation is possible with the structure to
	follow the existing practice for some commands where user-entered 0 is
	internally translated to UINT_MAX or INT_MAX.  Such translation can now
	be arbitrary.  Literals defined by this structure are automatically used
	for completion as necessary.

	So for example:

	const literal_def integer_unlimited_literals[] =
	  {
	    { "unlimited", INT_MAX, 0 },
	    { nullptr }
	  };

	defines an extra `unlimited' keyword and a user-visible 0 value, both of
	which get translated to INT_MAX for the setting to be used with.

	Similarly:

	const literal_def zuinteger_unlimited_literals[] =
	  {
	    { "unlimited", -1, -1 },
	    { nullptr }
	  };

	defines the same keyword and a corresponding user-visible -1 value that
	is used for the requested setting.  If the last member were omitted (or
	set to `{}') here, then only the keyword would be allowed for the user
	to enter and while -1 would still be used internally trying to enter it
	as a part of a command would result in an "integer -1 out of range"
	error.

	Use said error message in all cases (citing the invalid value requested)
	replacing "only -1 is allowed to set as unlimited" previously used for
	`var_zuinteger_unlimited' settings only rather than propagating it to
	`var_pinteger' type.  It could only be used for the specific case where
	a single extra `unlimited' keyword was defined standing for -1 and the
	use of numeric equivalents is discouraged anyway as it is for historical
	reasons only that they expose GDB internals, confusingly different
	across variable types.  Similarly update the "must be >= -1" Guile error
	message.

	Redefine Guile and Python parameter types in terms of the new variable
	types and interpret extra keywords as Scheme keywords and Python strings
	used to communicate corresponding parameter values.  Do not add a new
	PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
	variable type now, permitting existing parameters defined by GDB proper,
	such as `listsize', to be accessed from Scheme code.

	With these changes in place it should be trivial for a Scheme or Python
	programmer to expand the syntax of the `make-parameter' command and the
	`gdb.Parameter' class initializer to have arbitrary extra literals along
	with their internal representation supplied.

	Update the testsuite accordingly.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-19  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: Use AM_SILENT_RULES macro in configure.ac
	Silence 'make' by default.

	libsframe/
		* configure.ac: Use AM_SILENT_RULES.
		* configure: Regenerate.

2023-01-19  Tom Tromey  <tom@tromey.com>

	Remove some unused includes
	I noticed a few spots that include gnu-stabs.h but that do not need
	to.  This patch removes these unnecessary includes.  Tested by
	rebuilding.

2023-01-19  Tom de Vries  <tdevries@space.suse.cz>

	[gdb/tdep, aarch64] Remove fp and sp reg aliases, add x31 reg alias
	In aarch64-tdep.c we find these register aliases:
	...
	{
	  /* 64-bit register names.  */
	  {"fp", AARCH64_FP_REGNUM},
	  {"lr", AARCH64_LR_REGNUM},
	  {"sp", AARCH64_SP_REGNUM},
	...

	The sp alias is superfluous, because the canonical name of x31 is already sp.

	The fp alias is superfluous, because it's already taken by the default meaning
	of fp, assigned here in _initialize_frame_reg:
	...
	  user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
	...

	Fix this by removing the fp and sp aliases.

	While we're at it, add an x31 alias for sp.

	Approved-By: Luis Machado <luis.machado@arm.com>

	Tested on aarch64-linux.
	PR tdep/30012
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012

2023-01-19  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian
	On s390x-linux, I run into:
	...
	(gdb) python print(u[u_fields[0]])^M
	99^M
	(gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field
	python print(u[u_fields[1]])^M
	0 '\000'^M
	(gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field
	...

	There's a var u of this type:
	...
	union U {
	  int a;
	  char c;
	};
	...
	and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which
	it does on x86_64), but instead it contains 0.

	Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both
	little and big endian.

	Tested on x86_64-linux and s390x-linux.

2023-01-19  Alan Modra  <amodra@gmail.com>

	Reinitialise macro_nest
		* input-scrub.c (input_scrub_begin): Init macro_nest.

2023-01-19  Alan Modra  <amodra@gmail.com>

	PR 30022, concurrent builds can fail
	So let's not copy .libs/libbfd.a to libbfd.a now that nothing in the
	binutils-gdb source tries to link against it.

		PR 30022
		* Makefile.am (noinst_LIBRARIES, libbfd_a_SOURCES, stamp-lib),
		(libbfd.a): Delete rules.
		(CLEANFILES): Adjust to suit.

2023-01-19  Indu Bhagat  <indu.bhagat@oracle.com>

	toplevel: Makefile.def: add install-strip dependency on libsframe
	As noted in PR libsframe/30014 - FTBFS: install-strip fails because
	bfdlib relinks and fails to find libsframe, the install time
	dependencies of libbfd need to be updated.

		PR libsframe/30014
		* Makefile.def: Reflect that libsframe needs to installed before
		libbfd.  Reorder a bit to better track libsframe dependencies.
		* Makefile.in: Regenerate.

2023-01-19  Alan Modra  <amodra@gmail.com>

	The fuzzers have found the reloc special functions in coff-aarch64.c
	All of them need a bfd_reloc_offset_in_range check before accessing
	data + reloc_entry->address.  This patch adds the missing checks and
	sanity checks reloc offsets in coff_pe_aarch64_relocate_section too.

	All of them also need changing to support objdump -W calls to
	bfd_simple_get_relocated_section_contents.  At least, secrel_reloc
	needs the support, the others might not be present in dwarf debug
	sections.

		* coff-aarch64.c (coff_aarch64_rel21_reloc): Range check
		reloc offset.  Support final-linking.
		(coff_aarch64_po12l_reloc): Likewise.
		(coff_aarch64_addr32nb_reloc): Likewise.
		(coff_aarch64_secrel_reloc): Likewise.
		(coff_pe_aarch64_relocate_section): Range check reloc offset.

2023-01-19  Alan Modra  <amodra@gmail.com>

	Correct coff-aarch64 howtos and delete unnecessary special functions
	The remaining special functions are still broken except when called
	by gas bfd_install_relocation.

		* coff-aarch64.c (coff_aarch64_addr64_reloc),
		(coff_aarch64_addr32_reloc, coff_aarch64_branch26_reloc),
		(coff_aarch64_branch19_reloc, coff_aarch64_branch14_reloc),
		(coff_aarch64_po12a_reloc): Delete.
		(HOWTO_INSTALL_ADDEND): Define as 1.
		(HOW): Remove pcrel_off.  Correct all the howtos.
		(CALC_ADDEND): Define.
		(coff_aarch64_rtype_to_howto): New function.
		(coff_rtype_to_howto): Define.

2023-01-19  Alan Modra  <amodra@gmail.com>

	coff-aarch64.c howtos
	This is just a patch to fix overlong lines.  Wrapping the HOWTO macro
	in a new HOW macro helps in this.  No functional changes here.

		* coff-aarch64.c (HOW): Define and use for reloc howtos.

2023-01-19  Alan Modra  <amodra@gmail.com>

	howto install_addend
	This adds a new flag to the reloc howtos that can be used to
	incrementally change targets over to simple bfd_install_relocation
	that just installs the addend without any weird adjustments.
	I've made a few other changes to bfd_install_relocation, removing dead
	code and comments that are really only applicable to
	bfd_perform_relocation.

	There is also a reloc offset bounds check change.  I've moved the
	check to where data is accessed, as it seems reasonable to me to not
	perform the check unless it is needed.  There is precedence for this;
	Relocations against absolute symbols already avoided the check.

	I also tried always performing the reloc offset check, and ran into
	testsuite failures due to _NONE and _ALIGN relocs at the end of
	sections.  These likely would be fixed if all such reloc howtos had
	size set to zero, but I would rather not edit lots of files when it
	involves checking that target code does not use the size.

		* reloc.c (struct reloc_howto_struct): Add install_addend.
		(HOWTO_INSTALL_ADDEND): Define.
		(HOWTO): Init new field with HOWTO_INSTALL_ADDEND.
		(bfd_install_relocation): Remove comments copied from
		bfd_perform_relocation that aren't applicable here.  Remove
		code dealing with output_offset and output_section.  Just set
		relocation to addend if install_addend.  Move reloc offset
		bounds check to just before section data is accessed, avoiding
		the check when data is not accessed.
		* bfd-in2.h: Regenerate.

2023-01-19  Mike Frysinger  <vapier@gentoo.org>

	sim: info: convert verbose field to a bool
	The verbose argument has always been an int treated as a bool, so
	convert it to an explicit bool.  Further, update the API docs to
	match the reality that the verbose value is actually used by some
	of the internal modules.

	sim: unify sim-signal.o building
	Now that sim-main.h has been reduced significantly, we can remove it
	from sim-signal.c and unify it across all boards since it compiles to
	the same code.

	sim: v850: reduce extra header inclusion to igen files
	Limit these extra header includes to only when specific igen files
	include us until we can move the includes to the igen fils directly.

	sim: v850: drop redundant define
	This is already in v850/local.mk, so we can drop it from sim-main.h.

2023-01-19  Mark Wielaard  <mark@klomp.org>

	sim: mn10300: minimize mn10300-sim.h include in sim-main.h
	sim-main.h is special since it is one of the files automatically
	included in igen generated files. But this means anything including
	sim-main.h might get everything included just for the igen files.

	To prevent clashing symbols/defines only include sim-fpu.h,
	sim-signal.h, mn10300-sim.h from sim-main.h if it is included
	from one of the generated igen C files. Add explicit includes
	of mn10300-sim.h, sim-fpu.h and/or sim-signal.h to dv-mn103cpu.c,
	interp.c and op_utils.c.

2023-01-19  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-18  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Add references to erased args in cli-decode.c
	Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within
	cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter
	callbacks for settings") and update inline documentation accordingly for
	`add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the
	`args' parameter and removing references to `var', `set_setting_func'
	and `get_setting_func'.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-18  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Add missing inline documentation for `add_setshow_cmd_full'
	Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct
	within cmd_list_element") and add missing description for
	`add_setshow_cmd_full'.

	GDB: Correct inline documentation for `add_setshow_cmd_full_erased'
	Use proper English in the description of SET_LIST and SHOW_LIST.

2023-01-18  Maciej W. Rozycki  <macro@embecosm.com>

	GDB: Fix documentation for `theclass' parameters in cli-decode.c
	Rename CLASS to THECLASS in the documentation for `theclass' parameters
	throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword
	cleanliness, mostly auto-generated").

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-18  Tom Tromey  <tom@tromey.com>

	Fix 'make TAGS' in gdbserver
	PR build/29003 points out that "make TAGS" is broken in gdbserver.
	This patch fixes the problem that is pointed out there, plus another
	one I noticed while working on that -- namely that the "sed" computes
	the wrong names for some source files.  Finally, a couple of obsolete
	variable references are removed.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29003

2023-01-18  Carl Love  <cel@us.ibm.com>

	Revert "X86: reverse-finish fix"
	This reverts commit b22548ddb30bfb167708e82d3bb932461c1b703a.

	This patch is being reverted since the patch series is causing regressions.

2023-01-18  Carl Love  <cel@us.ibm.com>

	Revert "PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp"
	This reverts commit 92e07580db6a5572573d5177ca23933064158f89.

	Reverting patch as the patch series is causing regressions.

2023-01-18  Jan Vrany  <jan.vrany@labware.com>

	gdb: care for dynamic objfiles in build_id_bfd_get ()
	Accessing gdb.Objfile.build_id caused GDB to crash when objfile is
	dynamic, that is created by JIT reader API.

	The issue was NULL-pointer dereferencing in build_id_bfd_get () because
	dynamic objfiles have no underlaying BFD structure. This commit fixes
	the problem by a NULL-check in build_id_bfd_get ().

2023-01-18  Nick Clifton  <nickc@redhat.com>

	Speed up objcopy's note merging.
	   PR 29993
	  * objcopy.c (merge_gnu_build_notes): Remember the last non-deleted note in order to speed up the scan for matching notes.

2023-01-18  Mike Frysinger  <vapier@gentoo.org>

	sim: ppc: drop local psim link
	This has never been installed, and it's not clear anyone cares about
	it in the local build dir (when the main program is sim/ppc/run), so
	drop all the logic to simplify.

2023-01-18  Mark Harmstone  <mark@harmstone.com>

	Use subsystem to distinguish between pei-arm-little and pei-arm-wince-little
	Running objdump against a 32-bit ARM PE file currently needs
	disambiguation, as it gets picked up by both pei-arm-little and
	pei-arm-wince-little.

	This adds a check in pe_bfd_object_p so that the subsystem in the PE
	header is used to do the disambiguation for us, so that WinCE images get
	assigned to pei-arm-wince-little, and everything else to pei-arm-little.

2023-01-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	Revert "gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'"
	This reverts commit c2a5d74050ea9d7897b4122ef57c627d395683b3.

2023-01-18  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-17  Tom Tromey  <tromey@adacore.com>

	Remove two unused fields from gdbarch
	When I converted gdbarch to use the registry, I forgot to remove the
	two fields that were used to implement the previous approach.  This
	patch removes them.  Tested by rebuilding.

	Use require in paramless.exp
	The new paramless.exp test was not converted to the new "require"
	approach.  This patch fixes the problem.

2023-01-17  Carl Love  <cel@us.ibm.com>

	PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
	PR record/29927 - reverse-finish requires two reverse next instructions to
	reach previous source line

	PowerPC uses two entry points called the local entry point (LEP) and the
	global entry point (GEP).  Normally the LEP is used when calling a
	function.  However, if the table of contents (TOC) value in register 2 is
	not valid the GEP is called to setup the TOC before execution continues at
	the LEP.  When executing in reverse, the function finish_backward sets the
	break point at the alternate entry point (GEP).  However if the forward
	execution enters via the normal entry point (LEP), the reverse execution
	never sees the break point at the GEP of the function.  Reverse execution
	continues until the next break point is encountered or the end of the
	recorded log is reached causing gdb to stop at the wrong place.

	This patch adds a new address to struct execution_control_state to hold the
	address of the alternate function start address, known as the GEP on
	PowerPC.  The finish_backwards function is updated.  If the stopping point
	is between the two entry points (the LEP and GEP on PowerPC), the stepping
	range is set to execute back to the alternate entry point (GEP on PowerPC).
	Otherwise, a breakpoint is inserted at the normal entry point (LEP on
	PowerPC).

	Function process_event_stop_test checks uses a stepping range to stop
	execution in the caller at the first instruction of the source code line.
	Note, on systems that only support one entry point, the address of the two
	entry points are the same.

	Test finish-reverse-next.exp is updated to include tests for the
	reverse-finish command when the function is entered via the normal entry
	point (i.e. the LEP) and the alternate entry point (i.e. the GEP).

	The patch has been tested on X86 and PowerPC with no regressions.

2023-01-17  Carl Love  <cel@us.ibm.com>

	X86: reverse-finish fix
	PR record/29927  - reverse-finish requires two reverse next instructions to
	reach previous source line

	Currently on X86, when executing the finish command in reverse, gdb does a
	single step from the first instruction in the callee to get back to the
	caller.  GDB stops on the last instruction in the source code line where
	the call was made.  When stopped at the last instruction of the source code
	line, a reverse next or step command will stop at the first instruction
	of the same source code line thus requiring two step/next commands to
	reach the previous source code line.  It should only require one step/next
	command to reach the previous source code line.

	By contrast, a reverse next or step command from the first line in a
	function stops at the first instruction in the source code line where the
	call was made.

	This patch fixes the reverse finish command so it will stop at the first
	instruction of the source line where the function call was made.  The
	behavior on X86 for the reverse-finish command now matches doing a
	reverse-next from the beginning of the function.

	The proceed_to_finish flag in struct thread_control_state is no longer
	used.  This patch removes the declaration, initialization and setting of
	the flag.

	This patch requires a number of regression tests to be updated.  Test
	gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
	previous line.  The gdb output for tests gdb.reverse/until-precsave.exp
	and gdb.reverse/until-reverse.exp changed slightly.  The expected result in
	tests gdb.reverse/amd64-failcall-reverse.exp and
	gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
	result.

	This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
	reverse-finish command when returning from the entry point and from the
	body of the function.

	The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
	was moved to lib/gdb.exp and renamed cmd_until.

	The patch has been tested on X86 and PowerPC to verify no additional
	regression failures occured.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927

2023-01-17  Simon Marchi  <simon.marchi@efficios.com>

	gdb/testsuite: expect SIGSEGV from top GDB spawn id
	When testing with the native-extended-gdbserver, I get:

	    Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.
	    0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1
	    (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt

	This is because the -re that is supposed to match this SIGSEGV is after
	`-i $inferior_spawn_id`.  On native, the top and bottom GDB are on the
	same spawn id, so it ends up working.  But with a gdbserver board,
	that's not the case.  Move the SIGSEGV -re before the `-i
	$inferior_spawn_id` line, such that it matches what the top GDB outputs.

	Do the same fix in gdb.gdb/python-helper.exp.

	Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927
	Approved-By: Tom Tromey <tom@tromey.com>

2023-01-17  Tom Tromey  <tromey@adacore.com>

	Fix parameter-less template regression in new DWARF reader
	PR c++/29896 points out a regression in the new DWARF reader.  It does
	not properly handle a case like "break fn", where "fn" is a template
	function.

	This happens because the new index uses strncasecmp to compare.
	However, to make this work correctly, we need a custom function that
	ignores template parameters.

	This patch adds a custom comparison function and fixes the bug.  A new
	test case is included.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896

2023-01-17  Tom Tromey  <tromey@adacore.com>

	Move hash_entry and eq_entry into cooked_index::do_finalize
	I was briefly confused by the hash_entry and eq_entry functions in the
	cooked index.  They are only needed in a single method, and that
	method already has a couple of local lambdas for a different hash
	table.  So, it seemed cleaner to move these there as well.

	Don't erase empty indices in DWARF reader
	The DWARF reader has some code to remove empty indices.  However, I
	think this code has been obsolete since some earlier changes to
	parallel_for_each.  This patch removes this code.

	Avoid submitting empty tasks in parallel_for_each
	I found that parallel_for_each would submit empty tasks to the thread
	pool.  For example, this can happen if the number of tasks is smaller
	than the number of available threads.  In the DWARF reader, this
	resulted in the cooked index containing empty sub-indices.  This patch
	arranges to instead shrink the result vector and process the trailing
	entries in the calling thread.

2023-01-17  Stam Markianos-Wright  <stam.markianos-wright@arm.com>

	gas: arm: Change warning message to not reference specific A-class architecture revision
	We noticed that a warning message about the use of scalar fp16
	instructions being UNPREDICTABLE when conditionalized in an IT
	block referenced the specific A-class architecture revision
	ARMv8.2-A.
	Many of these instructions are now also part of ARMv8.1-M, so
	the warning message had become misleading.  Here we just change
	the message to not specify an architecture revision at all and
	update all testing accordingly.  This was done with a simple
	find-n-replace within the binutils sources.  No tests have
	regressed for the arm target.

	gas/ChangeLog:

	        * config/tc-arm.c (do_scalar_fp16_v82_encode): Remove
	        ARMv8.2-A from the warning message.
	        (do_neon_movhf): Likewise
	        * testsuite/gas/arm/armv8-2-fp16-scalar-bad.l: Likewise
	        * testsuite/gas/arm/mve-vaddsub-it-bad.l: Likewise
	        * testsuite/gas/arm/mve-vcvtne-it-bad.l: Likewise
	        * testsuite/gas/arm/mve-vcvtne-it.d: Likewise

2023-01-17  Stam Markianos-Wright  <stam.markianos-wright@arm.com>

	gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn
	Previously we had experienced issues with assembling a "VCVTNE" instruction
	in the presence of the MVE architecture extension, because it could be
	interpreted both as:

	* The base instruction VCVT + NE for IT predication when inside an IT block.
	* The MVE instruction VCVTN + E in the Else of a VPT block.

	Given a C reproducer of:
	```
	int test_function(float value)
	{
	  int ret_val = 10;
	  if (value != 0.0)
	  {
	    ret_val = (int) value;
	  }
	  return ret_val;
	}
	```
	GCC generates a VCVTNE instruction based on the `truncsisf2_vfp`
	pattern, which will look like:
	`vcvtne.s32.f32 s-reg, s-reg`
	This still triggers an error due to being misidentified as "vcvtn+e"
	Similar errors were found with other type combinations and instruction
	patterns (these have all been added to the testing of this patch).

	This class of errors was previously worked around by:
	https://sourceware.org/pipermail/binutils/2020-August/112728.html
	which addressed this by looking at the operand types, however,
	that isn't adequate to cover all the extra cases that have been
	found.  Instead, we add some special-casing logic earlier when
	the instructions are parsed that is conditional on whether we are
	in a VPT block or not, when the instruction is parsed.

	gas/ChangeLog:

		* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.
		* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.
		* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.
		* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.
		* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.

2023-01-17  Nick Clifton  <nickc@redhat.com>

	Fix snafu in previous delta for elf32-csky.c

2023-01-17  Xianmiao Qu  <cooper.qu@linux.alibaba.com>

	C-SKY: Fix machine flag.
	* elf32-csky.c (elf32_csky_merge_attributes): Don't save and restore the ARCH attribute, it will actually clear the ARCH attribute. (csky_elf_merge_private_bfd_data): Store the machine flag correctly.

2023-01-17  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-16  Enze Li  <enze.li@hotmail.com>

	libctf: update regexp to allow makeinfo to build document
	While trying to build gdb on latest openSUSE Tumbleweed, I noticed the
	following warning,

	 checking for makeinfo... makeinfo --split-size=5000000
	 configure: WARNING:
	 *** Makeinfo is too old. Info documentation will not be built.

	then I checked the version of makeinfo, it said,
	======
	$ makeinfo --version
	texi2any (GNU texinfo) 7.0.1

	Copyright (C) 2022 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.
	======

	After digging a little bit, it became quite obvious that a dot is
	missing in regexp that makes it impossible to match versions higher than
	7.0, and here's the solution:

	-       | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9][0-9])' >/dev/null 2>&1; then
	+       | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9]\.[0-9])' >/dev/null 2>&1; then

	However, Eli pointed out that the solution above has another problem: it
	will stop working when Texinfo 10.1 will be released.  Meanwhile, he
	suggested to solve this problem permanently.  That is, we don't care
	about the minor version for Texinfo > 6.9, we only care about the major
	version.

	In this way, the problem will be resolved permanently, thanks to Eli.

	libctf/ChangeLog:

		* configure: Regenerated.
		* configure.ac: Update regexp to match versions higher than 7.0.

2023-01-16  Alan Modra  <amodra@gmail.com>

	Correct ld-pe/aarch64.d test output
	"foo" is at 0x2010.  This corrects the expected output for .long and
	.word referencing foo, showing a problem with relocation handling.

		* testsuite/ld-pe/aarch64.d: Correct expected output.

2023-01-16  Alan Modra  <amodra@gmail.com>

	Tidy gas/expr.c static state
		* expr.c (seen, nr_seen): Make file scope.
		(expr_begin): Clear seen, nr_seen, and expr_symbol_lines.
		(expr_end): New function.
		* expr.h (expr_end): Declare.
		* output-file.c (output_file_close): Call expr_end.
		* config/tc-hppa.c (expr_end): Rename to expr_parse_end.
		* config/tc-mips.c: Likewise.
		* config/tc-riscv.c: Likewise.
		* config/tc-sparc.c: Likewise.

	Leftover hack from i960-coff
		* reloc.c (bfd_perform_relocation, bfd_install_relocation): Remove
		i960-coff target hack.

2023-01-16  Alan Modra  <amodra@gmail.com>

	COFF CALC_ADDEND comment
	Old COFF (and AOUT) targets have unusual relocation addends.

		* coffcode.h (<Reading relocations>): Describe COFF addends.

2023-01-16  Alan Modra  <amodra@gmail.com>

	PR29991, MicroMIPS flag erased after align directives
		PR 29991
		* config/tc-mips.c (s_align): Call file_mips_check_options and
		mips_mark_labels.
		* testsuite/gas/mips/align-after-label.s,
		* testsuite/gas/mips/mips-align-after-label.d,
		* testsuite/gas/mips/micromips-align-after-label.d: New test.
		* testsuite/gas/mips/mips.exp: Run it.

2023-01-16  Nick Clifton  <nickc@redhat.com>

	Update release making howto

	Updated translations for the gas and binutils sub-directories

2023-01-16  Mike Frysinger  <vapier@gentoo.org>

	sim: assume sys/stat.h always exists (via gnulib)
	We have many uses of sys/stat.h that are unprotected by HAVE_SYS_STAT_H,
	so this is more formalizing the reality that we require this header.
	Since we switched to gnulib, it guarantees that a sys/stat.h exists
	for us to include, so we're doubly OK.

	sim: formally assume unistd.h always exists (via gnulib)
	We have many uses of unistd.h that are unprotected by HAVE_UNISTD_H,
	so this is more formalizing the reality that we require this header.
	Since we switched to gnulib, it guarantees that a unistd.h exists
	for us to include, so we're doubly OK.

	sim: build: stop probing system extensions (ourselves)
	This logic was added in order to expose the strsignal prototype for
	nrun.c.  Since then, we've migrated to gnulib as our portability layer,
	and it takes care of probing system extensions for us, so there's no
	need to duplicate the work.

2023-01-16  Mike Frysinger  <vapier@gentoo.org>

	sim: modules.c: fix generation after recent refactors
	Add explicit arch-specific modules.c rules to keep the build from
	generating an incorrect common/modules.c.  Otherwise the pattern
	rules would cascade such that it'd look for $arch/modules.o which
	turned into common/modules.c which triggered the gen rule.

	My local testing of this code didn't catch this bug because of how
	Automake manages .Po (dependency files) in incremental builds -- it
	was adding extra rules that override the pattern rules which caused
	the build to generate correct modules.c files.  But when building
	from a cold cache, the pattern rules would force common/modules.c to
	be used leading to crashes at runtime.

2023-01-16  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-15  Mark Wielaard  <mark@klomp.org>

	sim: microblaze, mn10300: remove signal.h include in interp.c
	signal.h isn't needed in microblaze and mn10300 interp.c
	so don't include it.

2023-01-15  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: fix typos in stamp depends
	Copying & pasting the first rule missed updating the dep to the right
	stamp file.

	sim: igen: simplify build logic a little
	Now that all ports (that use igen) build in the top-level and depend
	on igen, we can move the conditional logic out of configure.  We also
	switch from noinst_LIBRARIES to EXTRA_LIBRARIES so that the library
	is only built when needed (i.e. the igen tool is used).

	sim: build: drop depdir subdir hack
	Now that all the ports compile some C files in their arch dirs, Automake
	guarantees creating the depdir for us, so we can drop our configure hack.

	sim: common: simplify modules.c deps
	Now that all ports (other than ppc) build in the top-level, we don't
	need to expand all the modules.c targets as a recursive dep.  Each
	port depends on their respective file now, and the ppc port doesn't
	use it at all.

	sim: common: move modules.c to source tracking
	This makes sure the arch-specific modules.c wildcard is matched and
	not the common/%.c so that we compile it correctly.  It also makes
	sure each subdir has depdir logic enabled.

	sim: common: move libcommon.a dep to ppc code
	Rather than force this to be built ahead of time for all targets,
	move the dep to the ppc code since it's the only user of it now.

	sim: build: drop most recursive build deps
	Now that we build these objects in the top dir & generate modules.c
	there, we don't need to generate them all first -- we can let the
	normal dependency graph take care of building things in parallel.

	sim: common: move libcommon.a objects to sources
	This simplifies the build logic and avoids an Automake bug where the
	common_libcommon_a_OBJECTS variable isn't set in the arch libsim.a
	DEPENDENCIES for targets that, alphabetically, come before "common".
	We aren't affected by that bug with the current code, but as we move
	things out of SIM_ALL_RECURSIVE_DEPS and rely on finer dependencies,
	we will trip over it.

	sim: igen: simplify build dep
	Now that all ports (other than ppc) build in the top-level, we don't
	need to mark the igen tool as a recursive dep.  Each port depends on
	the tool if it actually uses it, and ppc doesn't use it at all.

	sim: common: simplify hw-config.h deps
	Now that all ports (other than ppc) build in the top-level, we don't
	need to expand all the hw-config.h targets as a recursive dep.  Each
	port depends on their respective header now, and the ppc port doesn't
	use it at all.

	sim: build: drop AM_MAKEFLAGS settings
	We don't have any recursive builds anymore, so we can drop this logic.

2023-01-15  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-14  Tom Tromey  <tom@tromey.com>

	Pass internal gdb flags to --configuration invocations
	The test suite uses the --configuration flag to feature-test gdb.
	However, when I added this, I neglected to pass the internal gdbflags
	to this, causing an error, which then caused failures in the test
	suite (which would not be seen if you'd ever run "make install").

	This patch fixes the bug.  Tested by removing my install tree first,
	to verify that I could reproduce the failure.

2023-01-14  Nick Clifton  <nickc@redhat.com>

	Update how-to-make-a-release file now that the 2.40 release is out

2023-01-14  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-13  Mike Frysinger  <vapier@gentoo.org>

	sim: build: delete Make-common.in logic
	Now that all (other than ppc) build in the top-level, this logic is
	unused, so punt it all.

2023-01-13  Tom Tromey  <tom@tromey.com>

	Rename to allow_tui_tests
	This changes skip_tui_tests to invert the sense, and renames it to
	allow_tui_tests.  It also rewrites this function to use the output of
	"gdb --configuration", and it adds a note about the state of the TUI
	to that output.

	Rename to allow_guile_tests
	This changes skip_guile_tests to invert the sense, and renames it to
	allow_guile_tests.  It also rewrites this proc to check the output of
	"gdb --configuration", as was done for Python.  Then it changes the
	code to use "require" where possible.

	Rename to allow_hw_breakpoint_tests
	This changes skip_hw_breakpoint_tests to invert the sense, and renames
	it to allow_hw_breakpoint_tests.  This also converts some tests to use
	"require" -- I missed this particular check in the first series.

	Rename to allow_tsx_tests
	This changes skip_tsx_tests to invert the sense, and renames it to
	allow_tsx_tests.

	Rename to allow_shlib_tests
	This changes skip_shlib_tests to invert the sense, and renames it to
	allow_shlib_tests.

	Rename to allow_rust_tests
	This changes skip_rust_tests to invert the sense, and renames it to
	allow_rust_tests.

	Rename to allow_python_tests
	This changes skip_python_tests to invert the sense, and renames it to
	allow_python_tests.

	Rename to allow_perf_tests
	This changes skip_perf_tests to invert the sense, and renames it to
	allow_perf_tests.

	Rename to allow_opencl_tests
	This changes skip_opencl_tests to invert the sense, and renames it to
	allow_opencl_tests.

	Rename to allow_ifunc_tests
	This changes skip_ifunc_tests to invert the sense, and renames it to
	allow_ifunc_tests.

	Rename to allow_hw_watchpoint_tests
	This changes skip_hw_watchpoint_tests to invert the sense, and renames
	it to allow_hw_watchpoint_tests.

	Rename to allow_hw_watchpoint_multi_tests
	This changes skip_hw_watchpoint_multi_tests to invert the sense, and
	renames it to allow_hw_watchpoint_multi_tests.

	Rename to allow_hw_watchpoint_access_tests
	This changes skip_hw_watchpoint_access_tests to invert the sense, and
	renames it to allow_hw_watchpoint_access_tests.

	Rename to allow_go_tests
	This changes skip_go_tests to invert the sense, and renames it to
	allow_go_tests.

	Rename to allow_gdbserver_tests
	This changes skip_gdbserver_tests to invert the sense, and renames it
	to allow_gdbserver_tests.

	Rename to allow_fortran_tests
	This changes skip_fortran_tests to invert the sense, and renames it to
	allow_fortran_tests.

	Rename to allow_d_tests
	This changes skip_d_tests to invert the sense, and renames it to
	allow_d_tests.

	Rename to allow_dlmopen_tests
	This changes skip_dlmopen_tests to invert the sense, and renames it to
	allow_dlmopen_tests.

	Rename to allow_debuginfod_tests
	This changes skip_debuginfod_tests to invert the sense, and renames it
	to allow_debuginfod_tests.

	Rename to allow_ctf_tests
	This changes skip_ctf_tests to invert the sense, and renames it to
	allow_ctf_tests.

	Rename to allow_cplus_tests and allow_stl_tests
	This changes skip_cplus_tests to invert the sense, and renames it to
	allow_cplus_tests.  This one also converts skip_stl_tests to
	allow_stl_tests, as that was convenient to do at the same time.

	Rename to allow_btrace_tests
	This changes skip_btrace_tests to invert the sense, and renames it to
	allow_btrace_tests.

	Rename to allow_btrace_pt_tests
	This changes skip_btrace_pt_tests to invert the sense, and renames it
	to allow_btrace_pt_tests.

	Rename to allow_avx512fp16_tests
	This changes skip_avx512fp16_tests to invert the sense, and renames it
	to allow_avx512fp16_tests.

	Rename to allow_avx512bf16_tests
	This changes skip_avx512bf16_tests to invert the sense, and renames it
	to allow_avx512bf16_tests.

	Rename to allow_ada_tests
	This changes skip_ada_tests to invert the sense, and renames it to
	allow_ada_tests.

	Rename to allow_aarch64_sve_tests
	This changes skip_aarch64_sve_tests to invert the sense, and renames
	it to allow_aarch64_sve_tests.

	Rename to allow_xml_test
	This changes gdb_skip_xml_test to invert the sense, and renames it to
	allow_xml_test.

	Use "require" for Python tests
	This changes various tests to use "require" for the Python feature.

2023-01-13  Tom Tromey  <tom@tromey.com>

	Fix latent bug in default_prompt_gdb_start
	default_prompt_gdb_start mimics default_gdb_start, but does not set
	the use_gdb_stub global.  This caused one Python test to work only
	because it used the ordinary gdb_start before later using
	default_prompt_gdb_start.

	This patch updates default_prompt_gdb_start to set this global as
	well.

2023-01-13  Tom Tromey  <tom@tromey.com>

	Remove mi_skip_python_tests
	mi_skip_python_tests was necessary because skip_python_tests used the
	running gdb, and so needed to know what prompt to expect.  Now that
	skip_python_tests has been rewritten, mi_skip_python_tests is no
	longer needed.

	Rewrite skip_python_tests
	This rewrites skip_python_tests to examine the output of
	"gdb --configuration".  This is a bit nicer because it
	does not require an already-running gdb.

	Use require gnat_runtime_has_debug_info
	This changes some tests to use "require gnat_runtime_has_debug_info".

	Use require !skip_debuginfod_tests
	This changes some tests to use "require !skip_debuginfod_tests".

	Use require using_fission
	This changes some tests to use "require using_fission".

	Use require target_can_use_run_cmd
	This changes some tests to use "require target_can_use_run_cmd".

	Use require !skip_opencl_tests
	This changes some tests to use "require !skip_opencl_tests".

	Use require !skip_perf_tests
	This changes some tests to use "require !skip_perf_tests".

	Use require gdb_trace_common_supports_arch
	This changes some tests to use "require gdb_trace_common_supports_arch".

	Use require gdb_skip_xml_test
	This changes some tests to use "require gdb_skip_xml_test".

	Use require !gdb_debug_enabled
	This changes some tests to use "require !gdb_debug_enabled".

	Use require is_c_compiler_gcc
	This changes some tests to use "require is_c_compiler_gcc".

	Use require !skip_shlib_tests
	This changes some tests to use "require !skip_shlib_tests".  This patch
	cleans up a few spots that were missed in the earlier patch.

	Use require !skip_gdbserver_tests
	This changes some tests to use "require !skip_gdbserver_tests".

	Use require isnative
	This changes some tests to use "require isnative".

	Use require can_spawn_for_attach
	This changes some tests to use "require can_spawn_for_attach".

	Use require !use_gdb_stub
	This changes some tests to use "require !use_gdb_stub".

	Use require support_go_compile
	This changes some tests to use "require support_go_compile".

	Use require supports_get_siginfo_type
	This changes some tests to use "require supports_get_siginfo_type".

	Use require can_single_step_to_signal_handler
	This changes some tests to use "require can_single_step_to_signal_handler".

	Use require is_elf_target
	This changes some tests to use "require is_elf_target".

	Use require is_amd64_regs_target
	This changes some tests to use "require is_amd64_regs_target".

	Use require is_aarch32_target
	This changes some tests to use "require is_aarch32_target".

	Use require is_aarch64_target
	This changes some tests to use "require is_aarch64_target".

	Use require support_displaced_stepping
	This changes some tests to use "require support_displaced_stepping".

	Use require !skip_avx_*
	This changes some tests to use "require" with !skip_avx_*.

	Use require !skip_btrace_tests
	This changes some tests to use "require !skip_btrace_tests".

	Use require !skip_btrace_pt_tests
	This changes some tests to use "require !skip_btrace_pt_tests" and
	"require !skip_tsx_tests".

	Use require !skip_aarch64_sve_tests
	This changes some tests to use "require !skip_aarch64_sve_tests".

	Use require !skip_ifunc_tests
	This changes some tests to use "require !skip_ifunc_tests".

	Use require !skip_hw_watchpoint_tests
	This changes some tests to use "require !skip_hw_watchpoint_tests".

	Use require !skip_ctf_tests
	This changes some tests to use "require !skip_ctf_tests".

	Use require !skip_d_tests
	This changes some tests to use "require !skip_d_tests".

	Use require !skip_go_tests
	This changes some tests to use "require !skip_go_tests".

	Use require !skip_ada_tests
	This changes some tests to use "require !skip_ada_tests".

	Use require !skip_fortran_tests
	This changes some tests to use "require !skip_fortran_tests".

	Use require !skip_rust_tests
	This changes some tests to use "require !skip_rust_tests".

	Use require !skip_stl_tests
	This changes some tests to use "require !skip_stl_tests".

	Use require !skip_dlmopen_tests
	This changes some tests to use "require !skip_dlmopen_tests".

	Use require !skip_shlib_tests
	This changes some tests to use "require !skip_shlib_tests".

	Use require !skip_cplus_tests
	This changes some tests to use "require !skip_cplus_tests".

	Use require is_x86_like_target
	This changes some tests to use "require is_x86_like_target".

	Use require dwarf2_support
	This changes some tests to use "require dwarf2_support".

	Use require supports_process_record
	This changes some tests to use "require supports_process_record".

	Use require supports_reverse
	This changes some tests to use "require supports_reverse".

2023-01-13  Tom Tromey  <tom@tromey.com>

	Use unsupported in 'require'
	This changes 'require' to use 'unsupported' rather than 'untested'.
	The latter doesn't really seem to be correct according to the DejaGNU
	documentation:

	    Declares a test was not run.  `untested' writes in the log file a
	    message beginning with _UNTESTED_, appending the `message' argument.
	    For example, you might use this in a dummy test whose only role is to
	    record that a test does not yet exist for some feature.

	The example there, and some text elsewhere, is what makes me think
	this isn't a great fit.  On the other hand, 'unsupported' says:

	    Declares that a test case depends on some facility that does not exist
	    in the testing environment.

2023-01-13  Tom Tromey  <tom@tromey.com>

	Change 'require' to accept a list of predicates
	This changes 'require' to accept a list of simple predicates.  For
	now, each predicate is just the name of a proc, optionally prefixed
	with "!" to indicate that the result should be inverted.

	It's possible to make this fancier, but so far I haven't done so.  One
	idea I had is to allow a predicate to have associated text to display
	on failure.  Another is to convert the predicates that need a running
	gdb (e.g., skip_python_tests) to start their own gdb, and then
	'require' could enforce the rule that gdb not be running when it is
	called.

2023-01-13  Tom Tromey  <tom@tromey.com>

	Don't use ensure_gdb_index with require
	This series changes 'require' to take a list of simple predicates.
	This patch backs out the one use of 'require' that doesn't conform to
	this -- calling ensure_gdb_index.

2023-01-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

	gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'
	gprofng/ChangeLog
	2023-01-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

		PR gprofng/29987
		* configure.ac: Remove dependencies on libbfd and libiberty.
		* gprofng/src/Makefile.am: Likewise.
		* configure: Rebuild.
		* Makefile.in: Rebuild.
		* src/Makefile.in: Rebuild.
		* doc/Makefile.in: Rebuild.
		* gp-display-html/Makefile.in: Rebuild.

2023-01-13  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: replace an strncat with strcat
	Calling strncat with the size of the src string is not so meaningful.
	The length argument to strncat should specify the remaining bytes
	bytes in the destination; although in this case, it appears to be
	unncessary altogether to use strncat in the first place.

	libsframe/
	        * sframe-dump.c (dump_sframe_func_with_fres): Use of strcat is
		just as fine.

2023-01-13  Andrew Burgess  <aburgess@redhat.com>

	gdbserver: add comments to read_inferior_memory function
	Just adding some comments to the gdbserver read_inferior_memory
	function.  No actual code changes.

	gdb/infrun: add debug print in print_signal_received_reason
	It would have helped me to see an infrun debug line being printed from
	print_signal_received_reason, so I'm adding one.

2023-01-13  Andrew Burgess  <aburgess@redhat.com>

	gdb: int to bool conversion for normal_stop
	Change the return type of normal_stop (infrun.c) from int to bool.
	Update callers.

	I've also converted the (void) to () in the function declaration and
	definition, given I was changing those lines anyway.

	There should be no user visible changes after this commit.

2023-01-13  Nick Clifton  <nickc@redhat.com>

	Updated Romainian translation for the bfd sub-directory

2023-01-13  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-12  Tom Tromey  <tromey@adacore.com>

	Disable ptype/o for dynamic types
	A user pointed out that "ptype/o" of a certain Ada type -- while in C
	mode -- caused gdb to crash.

	The bug here is that dynamic types can't really be printed this way.
	This patch avoids the bug by disabling the "/o" feature in this case.

	Note that using "ptype/o" in this way makes sense for the time being,
	because the Ada code doesn't support the "/o" feature (yet); and in
	any case gdb should not crash.

2023-01-12  Hans-Peter Nilsson  <hp@axis.com>

	ARM: Fix ld bloat introduced between binutils-2.38 and 2.39
	Since commit 9833b7757d24, "PR28824, relro security issues",
	ELF_MAXPAGESIZE matters much more, with regards to layout of
	the linked file.  That commit fixed an actual bug, but also
	exposes a problem for targets were that value is too high.

	For example, for ARM(32, a.k.a. "Aarch32") specifically
	bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU)
	targets pay an extra amount of up to 60 KiB of bloat in
	DSO:s and executables.  This matters when there are many
	such files, and where storage is expensive.

	It's *mostly* bloat when using a Linux kernel, as ARM(32) is
	a good example of an target where ELF_MAXPAGESIZE is set to
	an extreme value for an obscure corner-case.  The ARM
	(32-bit) kernel has 4 KiB pages, has had that value forever,
	and can't be configured to any other value.  The use-case is
	IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but
	not just that, but a setup where the Linux page-size is
	configured to something other than the *default* 4 KiB.  Not
	sure there actually any such systems in use, again with
	both Aarch32 compatibility support and a non-4KiB pagesize,
	with all the warnings in the kernel config and requiring the
	"EXPERT" level set on.

	So, let's do like x86-64 in a2267dbfc9e1 "x86-64: Use only
	one default max-page-size" and set ELF_MAXPAGESIZE to 4096.

	bfd:
		* elf32-arm.c (ELF_MAXPAGESIZE): Always set to 0x1000.

2023-01-12  Hans-Peter Nilsson  <hp@axis.com>

	ld/testsuite: Adjust for ELF_MAXPAGESIZE 0x1000
	Many tests reflect a setting of ELF_MAXPAGESIZE to 64 KiB.
	With ELF_MAXPAGESIZE changed to 4 KiB, layout is sometimes
	different and symbols end up in other places.  Avoid churn
	and regexpification of old test patterns by passing the
	max-page-size setting active at the time.

	ld/testsuite:

		* testsuite/ld-arm/arm-elf.exp,
	        testsuite/ld-arm/non-contiguous-arm2.d,
	        testsuite/ld-arm/non-contiguous-arm3.d,
	        testsuite/ld-arm/non-contiguous-arm5.d,
	        testsuite/ld-arm/non-contiguous-arm6.d,
	        testsuite/ld-arm/thumb-plt-got.d, testsuite/ld-arm/thumb-plt.d:
		Pass -z max-page-size=0x10000 explicitly to test that rely on
		that value in output-matching patterns.

2023-01-12  Nick Alcock  <nick.alcock@oracle.com>

	libctf: ctf-link outdated input check faulty
	This check has a pair of faults which, combined, can lead to memory
	corruption.  Firstly, it assumes that the values of the ctf_link_inputs
	hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much
	shorter structure.  So the flags check which is the core of this is
	faulty (but happens, by chance, to give the right output on most
	architectures, since usually we happen to get a 0 here, so the test that
	checks this usually passes).  Worse, the warning that is emitted when
	the test fails is added to the wrong dict -- it's added to the input
	dict, whose warning list is never consumed, rendering the whole check
	useless.  But the dict it adds to is still the wrong type, so we end up
	overwriting something deep in memory (or, much more likely,
	dereferencing a garbage pointer and crashing).

	Fixing both reveals another problem: the link input is an *archive*
	consisting of multiple members, so we have to consider whether to check
	all of them for the outdated-func-info thing we are checking here.
	However, no compiler exists that emits a mixture of members with this
	flag on and members with it off, and the linker always reserializes (and
	upgrades) such things when it sees them: so all members in a given
	archive must have the same value of the flag, so we only need to check
	one member per input archive.

	libctf/
		PR libctf/29983
		* ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of
	        members of ctf_link_inputs right, fixing a possible spurious
	        tesst failure / wild pointer deref / overwrite.  Emit the
	        warning message into the right dict.

2023-01-12  Nick Alcock  <nick.alcock@oracle.com>

	libctf: skip the testsuite from inside dejagnu
	The libctf testsuite uses Tcl try/catch to trap run_output errors.  This
	is only supported in reasonably recent Tcls, so we detect the lack of
	try/catch and suppress the testsuite via an Automake conditional in its
	absence.

	But this turns out not to work: Automake produces a check-DEJAGNU target
	regardless of the value of this conditional and sticks it in an
	unconditionally-executed part of the makefile, so the testsuite gets
	executed anyway, and fails with a nasty-looking syntax error.  We can't
	disable it by taking "dejagnu" out of AUTOMAKE_OPTIONS, because if you
	do that Automake stops you using RUNTEST, RUNTESTFLAGS and other
	variables users would expect to work.

	So move to disabling the testsuite from inside the testsuite itself,
	importing the value of the former Automake conditional as a Tcl variable
	and exiting very early in default.exp if it's false.

		* configure.ac (TCL_TRY): No longer an Automake conditional.
		Rename to...
		(HAVE_TCL_TRY): ... this.
		* Makefile.am: Drop TCL_TRY.
		(development.exp): Set have_tcl_try.
		* testsuite/config/default.exp: Exit if have_tcl_try is false.

		* configure: Regenerated.
		* Makefile.in: Likewise.

2023-01-12  Nick Alcock  <nick.alcock@oracle.com>

	ctf: fix various dreadful typos in the ctf_archive format comments
	When defining a format it helps to a) get the endianness right when you
	explicitly state what it is and b) define things in terms of fields that
	exist rather than fields that don't.

	(A bunch of changes of names during implementation were not reflected in
	these comments...)

	Thanks to Jose "Eye of the Eagle" Marchesi for spotting these.

	include/
		* ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of
		this is in little-endian byte order, not network byte order.
		(struct ctf_archive_modent): This is positioned right after the
		end fo the struct ctf_archive, not at the offset of a
		nonexistent field.  The number of elements in the array depends
		on ctfa_ndicts, not another nonexistent field.

2023-01-12  Nick Clifton  <nickc@redhat.com>

	Ensure that libbacktrace/allocfail.sh is not deleted when creating release tarballs.
	        * Makefile.am (CLEANFILES): Import patch from upstream to prevent
	        allocafail.sh from being removed when running 'make clean'.

2023-01-12  Alan Modra  <amodra@gmail.com>

	Use __func__ rather than __FUNCTION__
	We already use C99's __func__ in places, use it more generally.  This
	patch doesn't change uses in the testsuite.  I've also left one in
	gold.h that is protected by GCC_VERSION < 4003.  If any of the
	remaining uses bothers anyone I invite patches.

	bfd/
		* bfd-in.h: Replace __FUNCTION__ with __func__.
		* elf32-bfin.c: Likewise.
		* elfnn-aarch64.c: Likewise.
		* elfxx-sparc.c: Likewise.
		* bfd-in2.h: Regenerate.
	gas/
		* config/tc-cris.c: Replace __FUNCTION__ with __func__.
		* config/tc-m68hc11.c: Likewise.
		* config/tc-msp430.c: Likewise.
	gold/
		* dwp.h: Replace __FUNCTION__ with __func__.
		* gold.h: Likewise, except for use inside GCC_VERSION < 4003.
	ld/
		* emultempl/pe.em: Replace __FUNCTION__ with __func__.
		* emultempl/pep.em: Likewise.
		* pe-dll.c: Likewise.

2023-01-12  Alan Modra  <amodra@gmail.com>

	Remove myself as hppa32 maintainer
	Reflects the reality that I haven't done much on hppa32 for years.

2023-01-12  Mike Frysinger  <vapier@gentoo.org>

	sim: build: drop subdir Makefile.in files
	These aren't used anymore, so punt them all.

2023-01-12  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-11  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/doc: fix install-html with Texinfo 7
	Starting with Texinfo 7 (this commit [1]), the output directory for the
	HTML doc format is gdb/doc/gdb_html, rather than gdb/doc/gdb previously.
	This breaks the install-html target, which expects the HTML doc to be in
	gdb/doc/gdb:

	    $ make install-html MAKEINFO=makeinfo DESTDIR=/tmp/install
	    make[1]: Entering directory '/home/simark/build/binutils-gdb/gdb'
	    make[2]: Entering directory '/home/simark/build/binutils-gdb/gdb/doc'
	    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc/../../readline/readline/doc -I /home/simark/src/binutils-gdb/gdb/doc/../mi -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/gdb.texinfo
	    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/stabs.texinfo
	    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/annotate.texinfo
	    test -z "/usr/local/share/doc/gdb" || /bin/sh /home/simark/src/binutils-gdb/gdb/doc/../../mkinstalldirs "/tmp/install/usr/local/share/doc/gdb"
	     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/gdb' '/tmp/install/usr/local/share/doc/gdb/gdb'
	    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/gdb': No such file or directory
	     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/stabs' '/tmp/install/usr/local/share/doc/gdb/stabs'
	    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/stabs': No such file or directory
	     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/annotate' '/tmp/install/usr/local/share/doc/gdb/annotate'
	    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/annotate': No such file or directory
	    make[2]: *** [Makefile:278: install-html] Error 1
	    make[2]: Leaving directory '/home/simark/build/binutils-gdb/gdb/doc'
	    make[1]: *** [Makefile:2240: subdir_do] Error 1
	    make[1]: Leaving directory '/home/simark/build/binutils-gdb/gdb'
	    make: *** [Makefile:2006: install-html] Error 2

	Fix this by adding -o switches to the HTML targets, to force the output
	directories.

	[1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a868421baf9c44227c43490687f8d6b8d6c95414

	Change-Id: Ie147dc7b4a52eb2348005b8dc006a41b0784621f

2023-01-11  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>

	gdb: Update gdbarch.py with latest changes in gdbarch.c
	Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep")
	changed gdbarch.c without updating gdbarch.py.  As a result, running
	gdbarch.py reverts those changes and causes the build to fail.

	So change gdbarch.py to generate the current version of gdbarch.c.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-11  Tom Tromey  <tromey@adacore.com>

	Set _WIN32_WINNT in common.m4 configure check
	GCC recently added support for the Windows thread model, enabling
	libstdc++ to support Windows natively.  However, this supporrt
	requires a version of Windows later than the minimum version that is
	supported by GDB.

	PR build/29966 points out that the GDB configure test for std::thread
	does not work in this situation, because _WIN32_WINNT is not defined
	in test program, and so <thread> seems to be fine.

	This patch is an attempt to fix the problem, by using the same setting
	for _WIN32_WINNT at configure time as is used at build time.

	I don't have access to one of the older systems so I don't think I can
	truly test this.  I did do a mingw cross build, though.  I'm going to
	ask the bug reporter to test it.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966

2023-01-11  Simon Marchi  <simon.marchi@polymtl.ca>

	[gdb/testsuite] Fix regexp in gdb.threads/dlopen-libpthread.exp
	Fix regexp in gdb.threads/dlopen-libpthread.exp:
	'libpthread\\.so' -> '/libpthread\\.so'.

	Tested on x86_64-linux.

2023-01-11  Alan Modra  <amodra@gmail.com>

	Fix XPASS weak symbols on x86_64-mingw32
	Fixes commit 16fea92ccd99.

		* testsuite/ld-scripts/weak.exp: Don't xfail x86_64 PE targets.
		Do xfail other PE OS triplets by moving code setting xfails.

2023-01-11  Nick Clifton  <nickc@redhat.com>

	Fix a potential illegal memory access in the BFD library when parsing a corrupt DWARF file.
		PR 29988
		* dwarf2.c (read_indexed_address): Fix check for an out of range
		offset.

2023-01-11  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, again
	On an x86_64 laptop running ubuntu 22.04.1 with unity desktop:
	...
	$ echo $XDG_CURRENT_DESKTOP
	Unity:Unity7:ubuntu
	...
	I have:
	...
	$ echo $LD_PRELOAD
	libgtk3-nocsd.so.0
	...
	due to package gtk3-nocsd, a package recommended by unity-session.

	Consequently, for each exec these dependencies are pulled in, including
	libpthread.so.0:
	...
	$ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
	libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none)
	    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
	    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
	    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
	        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
	...

	So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok:
	...
	 # of expected passes		12
	 # of unsupported tests		1
	...
	with LD_PRELOAD="" we have instead:
	...
	(gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify
	info sharedlibrary^M
	From  To                  Syms Read   Shared Object Library^M
	$hex  $hex  Yes         /lib64/ld-linux-x86-64.so.2^M
	$hex  $hex  Yes         /lib/x86_64-linux-gnu/libc.so.6^M
	$hex  $hex  Yes         dlopen-libpthread.so^M
	(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
	...

	The problem is that libpthread is expected as dependency of
	dlopen-libpthread.so, but it's missing:
	...
	$ lddtree dlopen-libpthread.so
	dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none)
	    libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6
	        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
	...
	due to having glibc 2.35, which has libpthread integrated into libc.

	Fix this by:
	- adding a proc has_dependency
	- using [has_dependency $exec libpthread.so] as hint that libpthread
	  may be preloaded
	- using ![has_dependency $shlib libpthread.so] to detect that
	  the libpthread.so dependency is missing.

	Also add a missing return after untested "no matching probes".

	Tested on x86_64-linux, with and without LD_PRELOAD="".

2023-01-11  Jan Beulich  <jbeulich@suse.com>

	gas/RISC-V: adjust assembler for opcode table re-ordering
	PR gas/29940

	With the single-operand JAL entry now sitting ahead of the two-operand
	one, the parsing of a two-operand insn would first try to parse an 'a'-
	style operand, resulting in the insertion of bogus (and otherwise
	unused) undefined symbols in the symbol table, having register names.
	Since 'a' is used as 1st operand only with J and JAL, and since JAL is
	the only insn _also_ allowing for a register as 1st operand (and then
	there being a 2nd one), special case this parsing aspect right there.

	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

2023-01-11  Alan Modra  <amodra@gmail.com>

	Tidy some global bfd state used by gas
		* subsegs.c (subsegs_end): Clear abs and und userdata.

2023-01-11  Alan Modra  <amodra@gmail.com>

	now_seg after closing output file
	now_seg, a pointer into the output file sections, isn't valid after
	the output file is closed.  gas doesn't and shouldn't use now_seg
	after this point of course, but let's be safe.

		* output-file.c (output_file_close): Clear now_seg and now_subseg.

2023-01-11  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-10  Tom Tromey  <tom@tromey.com>

	Fix bug in 'say_where' transform
	The patch to change say_where into a method introduced a bug.  This
	patch fixes it.

2023-01-10  Mark Harmstone  <mark@harmstone.com>

	gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64
	Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to
	make sure that DWARF offsets are encoded correctly (they're secrels in
	COFF). There were remnants of this there before, but they were removed
	by Jedidiah's original patch - presumably because we didn't yet have
	.secrel32.

2023-01-10  Mark Harmstone  <mark@harmstone.com>

	Add aarch64-w64-mingw32 target
	This adds a mingw target for aarch64, including windres and dlltool.

	Note that the old value of jmp_aarch64_bytes was wrong, and this does
	the same thing as MSVC does.

2023-01-10  Mark Harmstone  <mark@harmstone.com>

	Add .secrel32 for pe-aarch64
	Adds the .secrel32 pseudo-directive and its corresponding relocation.

	Add pe-aarch64 relocations
	This adds the remaining pe-aarch64 relocations, and gets them working.
	It also brings in the constant directives from ELF, as otherwise .word
	would be 2 rather than 4 bytes, and .xword and .dword wouldn't be
	defined.

2023-01-10  Mark Harmstone  <mark@harmstone.com>

	Fix size of external_reloc for pe-aarch64
	This patch series finishes off the work by Jedidiah Thompson, and adds
	support for creating aarch64 PE images.

	This should be essentially complete: I've used this to create a "hello
	world" Windows program in asm, and (with GCC patches) a UEFI program in
	C. I think the only things missing are the .secidx relocation, which is
	needed for PDBs, and the SEH pseudos used for C++ exceptions.

	This first patch fixes the size of RELSZ; I'm not sure why it was 14 in
	the first place. This is the size of the "Base Relocation Block" in
	https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and
	AFAIK should be 10 for everything.

2023-01-10  Rohr, Stephan  <stephan.rohr@intel.com>

	gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.
	The 'rw_pieced_value' function is executed when fetching a (lazy)
	variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'.  The
	function checks the 'type' and 'enclosing_type' fields of the value
	for identity.

	  * The 'type' field describes the type of a value.
	  * In most cases, the 'enclosing_type' field is identical to the
	    'type' field.
	  * Scenarios where the 'type' and 'enclosing_type' of an object
	    differ are described in 'gdb/value.c'.  Possible cases are:
	    * If a value represents a C++ object, then the 'type' field
	      gives the object's compile-time type.  If the object actually
	      belongs to some class derived from `type', perhaps with other
	      base classes and additional members, then `type' is just a
	      subobject of the real thing, and the full object is probably
	      larger than `type' would suggest.
	    * If 'type' is a dynamic class (i.e. one with a vtable), then GDB
	      can actually determine the object's run-time type by looking at
	      the run-time type information in the vtable.  GDB may then elect
	      to read the entire object.
	    * If the user casts a variable to a different type
	      (e.g. 'print (<type> []) <variable>'), the value's type is
	      updated before reading the value.

	If a lazy value is fetched, GDB allocates space based on the enclosing
	type's length and typically reads the 'full' object.  This is not
	implemented for pieced values and causes an internal error if 'type'
	and 'enclosing_type' of a value are not identical.

	However, GDB can read the value based on its type.  Thus, this patch
	fixes the previously mentioned cases by removing the check for identity.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605

	gdb/ChangeLog:
	2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

		* dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and
		'enlcosing_type' when reading pieced value 'v'.

	gdb/testsuite/ChangeLog:
	2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

		* gdb.dwarf2/shortpiece.exp: Added test cases.

2023-01-10  Tom Tromey  <tromey@adacore.com>

	Convert say_where to method on code_breakpoint
	'say_where' is only useful (and only called for) code breakpoints, so
	convert it to be a protected method on code_breakpoint.

2023-01-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/doc: use @value{GDBP} in some spots
	Examples are supposed to use @value{GDBP} instead of the literal "(gdb)"
	(many of them already do).  Update a bunch of spots where it wasn't the
	case.

	Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d

2023-01-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/doc: use @value{GDBN} in some spots
	Change some spots to use "@value{GDBN}" instead of just "GDB".

	Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e

2023-01-10  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/doc: some whitespace fixes
	For consistency, replace tabs with spaces in all gdb.texinfo menus.

	Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce

2023-01-10  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

	IBM zSystems: Fix offset relative to static TLS
	For local exec TLS relocations of the form foo@NTPOFF+x the addend was
	ignored.

	bfd/ChangeLog:

		* elf32-s390.c (elf_s390_relocate_section): Honor addend for
		R_390_TLS_LE32.
		* elf64-s390.c (elf_s390_relocate_section): Honor addend for
		R_390_TLS_LE64.

	ld/ChangeLog:

		* testsuite/ld-s390/reloctlsle-1.d: New test.
		* testsuite/ld-s390/reloctlsle-1.s: New test.

2023-01-10  Pekka Seppänen  <pexu@sourceware.mail.kapsi.fi>

	PR 29981 references to init.texi

2023-01-10  Alan Modra  <amodra@gmail.com>

	Re: Move bfd_init to bfd.c
	Commit b1c95bc4dd73 resulted in
	...bfd.texi:246: @include: could not find init.texi
	which went unnoticed due to not building in a clean directory.

	This fixes the problem by moving bfd_init earlier, giving it a
	doc node, and stitching the nodes back together.

		* bfd.c (bfd_init): Move earlier.  Give it a doc inode.
		Adjust other inodes to suit.
		* doc/bfd.texi: Don't include init.texi.  Adjust nodes to suit.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: disable recursive make in (most) subdirs
	Now that all (other than ppc) build in the top-level, we can disable
	the recursive make calls to them.  This speeds things up nicely.

	sim: common: move test-hw-events to top-level build
	This is an internal developer target that isn't normally compiled,
	but it can still be occasionally useful.  Move it to the top-level
	build so we can kill off common/Make-common.in.

	sim: move arch-specific file compilation of common/ files to top-level

	sim: v850: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: sh: move arch-specific file compilation to top-level

	sim: rx: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: rl78: move arch-specific file compilation to top-level

	sim: riscv: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: pru: move arch-specific file compilation to top-level

	sim: or1k: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: msp430: move arch-specific file compilation to top-level

	sim: moxie: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: mn10300: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: mips: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: microblaze: move arch-specific file compilation to top-level

	sim: mcore: move arch-specific file compilation to top-level

	sim: m68hc11: move arch-specific file compilation to top-level
	The arch-specific compiler flags are duplicated, but they'll be cleaned
	up once we move all subdir compiles to the top-level.

	sim: m32r: move arch-specific file compilation to top-level

	sim: m32c: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: lm32: move arch-specific file compilation to top-level

	sim: iq2000: move arch-specific file compilation to top-level

	sim: h8300: move arch-specific file compilation to top-level

	sim: ft32: move arch-specific file compilation to top-level

	sim: frv: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: example-synacor: move arch-specific file compilation to top-level

	sim: erc32: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: d10v: move arch-specific file compilation to top-level

	sim: cris: move arch-specific file compilation to top-level

	sim: cr16: move arch-specific file compilation to top-level

	sim: bfin: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: bpf: move arch-specific file compilation to top-level
	We can drop the arch-specific rules from the subdir as they're no
	longer used.

	sim: avr: move arch-specific file compilation to top-level

	sim: arm: move arch-specific file compilation to top-level
	The arch-specific flags are only used by the arch-specific modules,
	not the common/ files, so we can delete them too.

	sim: aarch64: move arch-specific file compilation to top-level

	sim: build: add basic framework for compiling arch objects in top-level
	The code so far has been assuming that we only compile common/ objects.
	Now that we're ready to compile arch-specific objects, refactor some of
	the flags & checks a bit to support both.

	sim: modules.c: move generation to top-level
	Now that all arches create libsim.a from the top-level, we have full
	access to their inputs, and can move the actual generation from the
	subdir up to the top-level.  This avoids recursive makes and will
	help simplify state passing between the two.

	sim: build: drop common/nrun.o subdir hack
	Now that all the subdirs handle their own builds, we can drop this
	common rule as it's unused, and we don't want to use it anymore.

	sim: build: drop support for creating libsim.a in subdirs
	Now that all ports have moved to creating libsim.a in the top-level,
	drop all the support code to create it in a subdir.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: v850: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: rx: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: rl78: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: riscv: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: pru: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: or1k: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: msp430: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: moxie: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: mn10300: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: mips: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

	The mips code is a little more tricky than others because, for multi-run
	targets, it generates the list of sources & objects on the fly in the
	configure script.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: microblaze: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: mcore: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: m68hc11: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: m32r: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: m32c: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: lm32: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: iq2000: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: h8300: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: ft32: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: frv: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: example-synacor: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: erc32: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: d10v: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: cris: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: cr16: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: bpf: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: bfin: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: avr: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: arm: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: aarch64: move libsim.a creation to top-level
	The objects are still compiled in the subdir, but the creation of the
	archive itself is in the top-level.  This is a required step before we
	can move compilation itself up, and makes it easier to review.

	The downside is that each object compile is a recursive make instead of
	a single one.  On my 4 core system, it adds ~100msec to the build per
	port, so it's not great, but it shouldn't be a big deal.  This will go
	away of course once the top-level compiles objects.

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: build: drop support for subdir extra deps
	Nothing uses this hook anymore, so punt it.  It was largely used to
	track generated files (which we do in the top-level now) and extra
	header files (which we use automake depgen for now).

2023-01-10  Mike Frysinger  <vapier@gentoo.org>

	sim: modules: trigger generation from top-level
	Add rules for tracking generated subdir modules.c files.  This doesn't
	actually generate the file from the top-level, but allows us to add
	rules that need to be ordered wrt it.  Once those changes land, we can
	rework this to actually generate from the top-level.

	This currently builds off of the objects that go into the libsim.a as
	we don't build those from the top-level either.  Once we migrate that
	up, we can switch this to the source files directly.  It's a bit hacky
	overall, but makes it easier to migrate things in smaller chunks, and
	we aren't going to keep this logic long term.

2023-01-10  Aaron Merey  <amerey@redhat.com>

	gdb/linespec.c: Fix missing source file during breakpoint re-set
	During breakpoint re-setting, the source_filename of an
	explicit_location_spec is used to lookup the symtabs associated with
	the breakpoint being re-set.  This source_filename is compared with each
	known symtab filename in order to retrieve the breakpoint's symtabs.

	However the source_filename may have been originally copied from a
	symtab's fullname (the path where GDB found the source file) when the
	breakpoint was first created.  If a breakpoint symtab's filename and
	fullname differ and there is no substitute-path rule that converts the
	fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
	during re-setting.

	Fix this by using a symtab's filename to set the explicit_location_spec
	source_filename instead of the symtab's fullname.

2023-01-10  Aaron Merey  <amerey@redhat.com>

	gdb/linespec.c: Fix -Wmaybe-uninitialized warning
	Although the bool want_start_sal isn't actually used without being assigned
	a value, initialize it to be false in order to prevent the following
	-Wmaybe-uninitialized warning:

	    linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
	    linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
	     4150 |   if (is_function && want_start_sal)

2023-01-10  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-09  Alan Modra  <amodra@gmail.com>

	Set dwarf2 stash pointer earlier
	This fixes a memory leak in the vanishingly rare cases (found by
	fuzzers of course) when something goes wrong in the save_section_vma,
	htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
	If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
	to free that memory.

		* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
		on setting up stash.

2023-01-09  Alan Modra  <amodra@gmail.com>

	peXXigen.c sanity checks
	Also fix a memory leak, and make some style changes.  I tend to read
	(sizeof * x) as a multiplication of two variables, which I would not
	do if binutils followed the gcc coding conventions consistently (see
	https://gcc.gnu.org/codingconventions.html#Expressions).  (sizeof *x)
	looks a lot better to me, or even (sizeof (*x)) which I've used here.

		* peXXigen.c (get_contents_sanity_check): New function.
		(pe_print_idata): Use it here..
		(pe_print_edata): ..and here.  Free data on error return.
		(rsrc_parse_entry): Check entry size read from file.
		(rsrc_parse_entries): Style fixes.
		(rsrc_process_section): Use bfd_malloc_and_get_section.
		(_bfd_XXi_final_link_postscript): Likewise.

2023-01-09  Alan Modra  <amodra@gmail.com>

	Move mips_refhi_list to bfd tdata
	Similar to commit c799eddb3512, but for mips-ecoff.  mips-ecoff is
	marked obsolete, but we still allow reading of these object files in
	a number of mips targets.

		* coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
		(mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
		in ecoff_data.
		* ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
		* libecoff.h (struct mips_hi): Moved from coff-mips.c.
		(struct ecoff_tdata): Add mips_refhi_list.
		(_bfd_ecoff_close_and_cleanup): Declare.

2023-01-09  Alan Modra  <amodra@gmail.com>

	Move bfd_init to bfd.c
	init.c contains just one function that doesn't do much.  Move it to
	bfd.c and give it something to do, initialising static state.  So far
	the only initialisation is for bfd.c static variables.

	The idea behind reinitialising state is to see whether some set of
	flaky oss-fuzz crashes go away.  oss-fuzz stresses binutils in ways
	that can't occur in reality, feeding multiple testcases into the
	internals of binutils.  So one testcase may affect the result of the
	next testcase.

		* init.c: Delete file.  Move bfd_init to..
		* bfd.c (bfd_init): ..here.  Init static variables.
		* Makefile.am (BFD32_LIBS): Remove init.lo.
		(BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c.
		* doc/local.mk: Remove mention of init.texi and init.c.
		* Makefile.in: Regenerate.
		* bfd-in2.h: Regenerate.
		* po/SRC-POTFILES.in: Regenerate.

2023-01-09  Tom Tromey  <tom@tromey.com>

	Fix crash with C++ qualified names
	PR c++/29503 points out that something like "b->Base::member" will
	crash when 'b' does not have pointer type.  This seems to be a simple
	oversight in eval_op_member.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503
	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-09  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/doc: fix @code{GDBN} -> @value{GDBN}
	Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e

2023-01-09  Christophe Lyon  <christophe.lyon@arm.com>

	Skip ld/pr23169 test on arm.
	The test is already skipped on several targets (including AArch64)
	because it's invalid.

		* testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.

2023-01-09  Christophe Lyon  <christophe.lyon@arm.com>

	Fix PR18841 ifunc relocation ordering
	In order to get the ifunc relocs properly sorted the correct class
	needs to be returned.  The code mimics what has been done for AArch64.

	Fixes:
	FAIL: Run pr18841 with libpr18841b.so
	FAIL: Run pr18841 with libpr18841c.so
	FAIL: Run pr18841 with libpr18841bn.so (-z now)
	FAIL: Run pr18841 with libpr18841cn.so (-z now)

		bfd/
		PR ld/18841
		* elf32-arm.c (elf32_arm_reloc_type_class): Return
		reloc_class_ifunc for ifunc symbols.

		ld/testsuite/
		* ld-arm/ifunc-12.rd: Update relocations order.
		* ld-arm/ifunc-3.rd: Likewise.
		* ld-arm/ifunc-4.rd: Likewise.

2023-01-09  Nick Clifton  <nickc@redhat.com>

	Updated transaltions for the gprof and binutils sub-directories

2023-01-09  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	testsuite: add -O0 to Intel compilers if no 'optimize' option is given
	icpx/icx give the following warning if '-g' is used without '-O'.

	   icpx: remark: Note that use of '-g' without any optimization-level
	   option will turn off most compiler optimizations similar to use of
	   '-O0'; use '-Rno-debug-disables-optimization' to disable this
	   remark [-Rdebug-disables-optimization]

	The warning makes dejagnu think that compilation has failed.  E.g.:

	  $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
	  ...
	  gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]

	                  === gdb Summary ===

	  # of untested testcases         1

	Furthermore, if no -O flag is passed, icx/icc optimize
	the code by default.  This breaks assumptions in many GDB tests
	that the code is unoptimized by default.  E.g.:

	  $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
	  ...
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
	  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()

	                  === gdb Summary ===

	  # of expected passes            1
	  # of unexpected failures        9

	To fix both problems, pass the -O0 flag explicitly, if no optimization
	option is given.

	With this patch we get, e.g.:

	  $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
	  ...
	                  === gdb Summary ===

	  # of expected passes            19
	  # of known failures             1

	Approved-By: Tom Tromey <tom@tromey.com>

2023-01-09  Nils-Christian Kempke  <nils-christian.kempke@intel.com>

	testsuite: handle icc and icpc deprecated remarks
	Starting with icc/icpc version 2021.7.0 and higher both compilers emit a
	deprecation remark when used.  E.g.

	  >> icc --version
	  icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
	  deprecated and will be removed from product release in the second half
	  of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended
	  compiler moving forward. Please transition to use this compiler. Use
	  '-diag-disable=10441' to disable this message.
	  icc (ICC) 2021.7.0 20220713
	  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

	  >> icpc --version
	  icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
	  deprecated ...
	  icpc (ICC) 2021.7.0 20220720
	  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

	As the testsuite compile fails when unexpected output by the compiler is
	seen this change in the compiler breaks all existing icc and icpc tests.
	This patch makes the gdb testsuite more forgiving by a) allowing the
	output of the remark when trying to figure out the compiler version
	and by b) adding '-diag-disable=10441' to the compile command whenever
	gdb_compile is called without the intention to detect the compiler.

	Approved-By: Tom Tromey <tom@tromey.com>

2023-01-09  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-08  Alan Modra  <amodra@gmail.com>

	PR29972, inconsistent format specification in singular form
		PR 29972
		* readelf.c (process_dynamic_section): Correct format string.

2023-01-08  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-07  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-06  Indu Bhagat  <indu.bhagat@oracle.com>

	sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants
	An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT
	constants.  These constants are used (by gas and libsframe) to pick an
	SFrame FRE type based on the function size.  Those constants, however,
	were buggy, causing the generated SFrame sections to be bloated as
	SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than
	necessary.

	gas/
		* sframe-opt.c (sframe_estimate_size_before_relax): Use
		typecast.
		(sframe_convert_frag): Likewise.

	libsframe/
		* sframe.c (sframe_calc_fre_type): Use a more appropriate type
		for argument.  Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT
		to keep it warning-free but meaningful.

	include/
		* sframe-api.h (sframe_calc_fre_type): Use a more appropriate
		type for the argument.
		* sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant.
		(SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
		(SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.

2023-01-06  Indu Bhagat  <indu.bhagat@oracle.com>

	libsframe: adjust an incorrect check in flip_sframe
	When sframe_encoder_write needs to flip the buffer containing the SFrame
	section before writing, it is not necessary that the SFrame FDES are in
	the order of their sfde_func_start_fre_off.  On the contrary, SFrame
	FDEs will be sorted in the order of their start address.  So, remove
	this incorrect assumption which is basically assuming that the last
	sfde_func_start_fre_off seen will help determine the end of the flipped
	buffer.

	The function now keeps track of the bytes_flipped and then compares it with
	the expected value.  Also, added two more checks at appropriate places:
	 - check that the SFrame FDE read is within bounds
	 - check that the SFrame FRE read is within bounds

	libsframe/

		* sframe.c (flip_sframe): Adjust an incorrect check.
		Add other checks to ensure reads are within the buffer size.

2023-01-06  Jan Beulich  <jbeulich@suse.com>

	ld: yet another PDB build fix (or workaround)
	Older bash looks to improperly deal with backslashes in here-documents,
	leaving them in place on the escaped double quotes inside the parameter
	expansion. Convert to a model without using such a construct, by simply
	splitting the here-documents into three ones.

2023-01-06  Nick Clifton  <nickc@redhat.com>

	Updated Bulgarian and Russian translations for LD and BFD respectively

2023-01-06  Alan Modra  <amodra@gmail.com>

	Fix an aout memory leak
		* aoutx.h (aout_bfd_free_cached_info): Free line_buf.

	Tidy pe flag in coff_data
	Make it a bool, use obj_pe accessor everywhere.

2023-01-06  Alan Modra  <amodra@gmail.com>

	Make coff backend data read-only
	The bfd_coff_backend_data struct should be read-only, the only thing
	preventing this is that objcopy writes to one of the fields,
	_bfd_coff_long_section_names.  This patch creates a copy of the field
	in bfd coff_obj_tdata, which makes more sense anyway.  When enabling
	long section names the intent is to do so for a particular bfd, not
	for all bfds that might happen to be using the target xvec.

	bfd/
		* coffcode.h: Update coff long section name comment.
		(bfd_coff_set_long_section_names_allowed): Use macro accessor
		to set flag.
		(bfd_coff_set_long_section_names_disallowed): Tidy.
		(coff_backend_info): Return a const pointer.
		(bfd_coff_std_swap_table, ticoff0_swap_table, ticoff1_swap_table),
		(bigobj_swap_table): Make const.
		(bfd_coff_long_section_names): Use tdata copy.
		(coff_mkobject): Set long_section_names from coff_backend_info.
		* coff-go32.c (_bfd_go32_mkobject): Likewise.
		* peicode.h (pe_mkobject): Likewise.
		* coff-sh.c (bfd_coff_small_swap_table): Make const.
		* libcoff-in.h (struct coff_tdata): Add long_section_names,
		reorder fields.
		* libcoff.h: Regenerate.
	binutils/
		* objcopy.c (set_long_section_mode): Move earlier in file.
		(copy_object): Call set_long_section_mode here, after setting
		output format.
		(copy_file): Don't call set_long_section_mode.

2023-01-06  Bruno Larsen  <blarsen@redhat.com>

	gdb/c++: Detect ambiguous variables in imported namespaces
	When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB
	to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB
	will print M::x, and using clang 16.0.0 prints N::x. Not only is this
	behavior confusing to users, it is also not consistent with compiler
	behaviors, which would warn that using x is ambiguous at this point.

	This commit makes GDB behavior consistent with compilers. it achieves
	this by making it so instead of exiting early when finding any symbol
	with the correct name, GDB continues searching through all include
	directives, storing all matching symbols in a relational map betwen the
	mangled name and the found symbols.

	If the resulting map has more than one entry, GDB says that the
	reference is ambiguous and lists all possibilities. Otherwise it returns
	the block_symbol structure for the desired symbol, or an empty struct if
	nothing was found.

	The commit also changes gdb.cp/nsusing.exp to test the ambiguous
	detection.

2023-01-06  Bruno Larsen  <blarsen@redhat.com>

	gdb/mi: add no-history stop reason
	When executing in reverse and runs out of recorded history, GDB prints
	a warning to the user, but does not add a reason in the stopped record,
	for example:

	*stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"

	This problem was reported as record/29260.

	This commit adds the reason no-history to the record, making it easier
	for interfaces using the mi interpreter to report the result.  It also
	changes the test gdb.mi/mi-reverse.exp to test that the reason shows up
	correctly.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260

2023-01-06  Bruno Larsen  <blarsen@redhat.com>

	gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clang
	When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99
	unexpected failures.  They all fail to produce a complete list of
	completion options for a function, either overload2_function,
	overload3_function or anon_ns_function.  This happens because clang is
	optimizing them away, since they are never used.

	Fix this by adding __attribute__((used)) to all declarations to the
	aforementioned functions.

2023-01-06  Clément Chigot  <chigot@adacore.com>

	configure: remove dependencies on gmp and mpfr when gdb is disabled
	Since 991180627851801f1999d1ebbc0e569a17e47c74, the configure checks
	about GMP and MPFR for gdb builds have been moved to the toplevel
	configure.
	However, it doesn't take into account the --disable-gdb option. Meaning
	that a build without gdb will require these libraries even if not
	needed.

	ChangeLog:

		* configure.ac: Skip GMP and MPFR when --disable-gdb is
		provided.
		* configure: Regenerate.

2023-01-06  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdbsupport: fix scoped_debug_start_end's move constructor
	I spotted a problem with scoped_debug_start_end's move constructor.
	When constructing a scoped_debug_start_end through it, it doesn't
	disable the moved-from object, meaning there are now two objects that
	will do the side-effects of decrementing the debug_print_depth global
	and printing the "end" message.  Decrementing the debug_print_depth
	global twice is actually problematic, because the increments and
	decrements get out of sync, meaning we should hit this assertion, in
	theory:

	    gdb_assert (debug_print_depth > 0);

	However, in practice, we don't see that.  This is because despite the
	move constructor being required for this to compile:

	    template<typename PT>
	    static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7)
	    make_scoped_debug_start_end (PT &&pred, const char *module, const char *func,
	    			     const char *start_prefix,
	    			     const char *end_prefix, const char *fmt, ...)
	    {
	      va_list args;
	      va_start (args, fmt);
	      auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix,
	    					   end_prefix, fmt, args);
	      va_end (args);

	      return res;
	    }

	... it is never actually called, because compilers elide the move
	constructors all the way (the scoped_debug_start_end gets constructed
	directly in the instance of the top-level caller).  To confirm this, I
	built GDB with -fno-elide-constructors, and now I see it:

	    /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed.

	    #9  0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58
	    #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147
	    #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235

	Fix this by adding an m_disabled field to scoped_debug_start_end, and
	setting it in the move constructor.

	Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f

2023-01-05  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: add gdb::string_view_hash
	Add the string_view_hash type, which will be useful to be able to use
	gdb::string_view as std::unordered_map keys.

	Use it in gdb/symtab.c, to exercise it.

	Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-01-05  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: move fast_hash to gdbsupport/common-utils.h
	The following patch adds a hash type for gdb::string_view in gdbsupport,
	which will use the fast_hash function.  Move the latter to gdbsupport.

	Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-01-05  Simon Marchi  <simon.marchi@efficios.com>

	gdbsupport: move libxxhash configure check to gdbsupport
	The following patch moves the fast_hash function, which uses libxxhash,
	to gdbsupport.  Move the libxxhash configure check to gdbsupport (and
	transitively to gdbserver).

	Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-01-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: make gdbarch_alloc take ownership of the tdep
	It's currently not clear how the ownership of gdbarch_tdep objects
	works.  In fact, nothing ever takes ownership of it.  This is mostly
	fine because we never free gdbarch objects, and thus we never free
	gdbarch_tdep objects.  There is an exception to that however: when
	initialization fails, we do free the gdbarch object that is not going to
	be used, and we free the tdep too.  Currently, i386 and s390 do it.

	To make things clearer, change gdbarch_alloc so that it takes ownership
	of the tdep.  The tdep is thus automatically freed if the gdbarch is
	freed.

	Change all gdbarch initialization functions to pass a new gdbarch_tdep
	object to gdbarch_alloc and then retrieve a non-owning reference from
	the gdbarch object.

	Before this patch, the xtensa architecture had a single global instance
	of xtensa_gdbarch_tdep.  Since we need to pass a dynamically allocated
	gdbarch_tdep_base instance to gdbarch_alloc, remove this global
	instance, and dynamically allocate one as needed, like we do for all
	other architectures.  Make the `rmap` array externally visible and
	rename it to the less collision-prone `xtensa_rmap` name.

	Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
	Approved-By: Andrew Burgess <aburgess@redhat.com>

2023-01-05  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb/testsuite: add back needed -re clause in gdb_breakpoint
	Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused,
	amongst others:

	   (gdb) break 1^M
	   No line 1 in the current file.^M
	   Make breakpoint pending on future shared library load? (y or [n]) n^M
	   (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1
	   FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set

	This is because it removed one empty -re clause (matching just the
	prompt) that is necessary after replying "n" to the pending breakpoint
	question.  Add this clause back.

	Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6
	Approved-By: Tom de Vries <tdevries@suse.de>

2023-01-05  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Avoid queue.SimpleQueue for python 3.6
	On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case
	fails as follows:
	...
	ERROR: eof reading json header
	    while executing
	"error "eof reading json header""
	    invoked from within
	"expect {
	-i exp19 -timeout 10
	        -re "^Content-Length: (\[0-9\]+)\r\n" {
	            set length $expect_out(1,string)
	            exp_continue
	        }
	        -re "^(\[^\r\n\]+)..."
	    ("uplevel" body line 1)
	    invoked from within
	"uplevel $body" NONE eof reading json header
	UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize
	...

	Investigation using a "catch throw" shows that:
	...
	(gdb)
	    at gdb/python/py-utils.c:396
	396             error (_("Error occurred in Python: %s"), msg.get ());
	(gdb) p msg.get ()
	$1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'"
	...

	The python class queue.SimpleQueue was introduced in python 3.7.

	Fix this by falling back to queue.Queue for python <= 3.6.

	Tested on x86_64-linux, by successfully running the test-case:
	...
	 # of expected passes            47
	...

2023-01-05  Tom Tromey  <tromey@adacore.com>

	Add type to expression dump of symbol
	I recently had cause to dump some expressions from gdb.  I got output
	like this:

	 Operation: BINOP_GTR
	  Operation: OP_VAR_VALUE
	   Block symbol:
	    Symbol: small_value
	    Block: 0x39b4c20
	  Operation: OP_LONG
	   Operation: OP_LONG
	    Type: int
	    Constant: 0x0000000000000014

	This is ok, but it would have been handy to see the type of the
	symbol.  This patch adds this information.

	Reviewed-By: Bruno Larsen <blarsen@redhat.com>

2023-01-05  Nick Clifton  <nickc@redhat.com>

	Remove Stephen Casner as the PDP11 maintainer.

	Add an extra emulation called arm64pe to the aarch64pe emulation.

2023-01-05  Andreas K. Huettel  <dilfridge@gentoo.org>

	Un xfail the PR19719 test for the AArch64 architecture

2023-01-05  Nick Clifton  <nickc@redhat.com>

	Updated Bulgarian and Russian translations for the gprof subdirectory

2023-01-05  Paul Koning  <paulkoning@comcast.net>

	PR29963, PDP11 link produces spurious relocation truncated messages
	PDP11 is a 16-bit processor with 16-bit logical addresses.  Therefore
	wrapping should be allowed on the 16-bit relocs, and may as well be
	allowed for the 32-bit reloc too.

		PR 29963
		* pdp11.c (howto_table_pdp11): Use complain_overflow_dont.

2023-01-05  Mike Frysinger  <vapier@gentoo.org>

	sim: mips: add multi source to built sources
	The multirun generation mode is a bit of a mess as generated run files
	depend on generate igen files, all with unknown names ahead of time.
	In the multirun mode, be lazy and declare all of these generated source
	files as built sources so they'll be created early on.

2023-01-05  Tsukasa OI  <research_trasio@irq.a4lg.com>

	sim: Move getopt checking inside SIM_AC_PLATFORM
	This commit moves getopt declaration checker originally in sim/
	configure.ac; added in commit 340aa4f6872c ("sim: Check known getopt
	definition existence") to sim/m4/sim_ac_platform.m4 (inside the
	SIM_AC_PLATFORM macro).

	It also regenerates configuration files using the maintainer mode.

2023-01-05  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

	sim: bpf: fix testsuite due to linker warnings [PR sim/29954]
	On a bpf-*-* testsuite fails:
		./ld/ld-new: warning: test has a LOAD segment with RWX permissions

	Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes.

	Tested on bpf-*-*:

	Bug: https://sourceware.org/PR29954

	sim/testsuite:
		* bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags.

2023-01-05  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-04  Indu Bhagat  <indu.bhagat@oracle.com>

	MAINTAINERS: add myself as maintainer of libsframe
	binutils/
		* MAINTAINERS: Add myself as maintainer of libsframe.

2023-01-04  H.J. Lu  <hjl.tools@gmail.com>

	x86: Remove duplicated I386_PCREL_TYPE_P/X86_64_PCREL_TYPE_P
	I386_PCREL_TYPE_P and X86_64_PCREL_TYPE_P are defined twice.  Remove
	the duplications.

		* elfxx-x86.h (I386_PCREL_TYPE_P): Remove duplication.
		(X86_64_PCREL_TYPE_P): Likewise.

2023-01-04  Lancelot SIX  <lancelot.six@amd.com>

	gdb: ensure test_name is initialized in gdb_breakpoint
	A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in
	gdb_breakpoint) left the $test_name variable undefined.

	This patch fixes this.

	Approved-By: Simon Marchi <simon.marchi@efficios.com>

2023-01-04  Tom Tromey  <tromey@adacore.com>

	Use first_opcode in another spot
	I found one place that could use expression::first_opcode.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-01-04  Tom Tromey  <tromey@adacore.com>

	Convert exp_uses_objfile to a method of expression
	This changes the exp_uses_objfile function to be a method of
	'expression'.

	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-01-04  Simon Marchi  <simon.marchi@polymtl.ca>

	gdb: use gdb_test_multiple in gdb_breakpoint
	When running the testsuite in a non-optimized build on a slow machine, I
	sometimes get:

	    UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase.

	do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor
	10`, to account for the fact that reading the debug info of the gdb
	binary (especially in a non-optimized GDB) can take time.  But then it
	ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded
	timeout of 30 seconds.

	Fix this by making gdb_breakpoint use gdb_test_multiple, which is a
	desired change anyway for this kind of simple command / expected
	output case.

	Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75
	Reviewed-By: Lancelot Six <lancelot.six@amd.com>

2023-01-04  Alan Modra  <amodra@gmail.com>

	Re: Avoid unaligned pointer reads in PEP .idata section
	Fix testsuite fallout.

		* testsuite/ld-pe/cfi.d: Adjust for changed .idata padding.
		* testsuite/ld-pe/secidx_64.d: Likewise.
		* testsuite/ld-pe/secrel_64.d: Likewise.

2023-01-04  Alan Modra  <amodra@gmail.com>

	objcopy fuzzed pe out of memory
	This occurs when attempting to read back a section from the output
	file in _bfd_XX_bfd_copy_private_bfd_data_common.  The copy of the
	section failed size sanity checking, thus it won't be written.

		* objcopy.c (copy_object): Return false if copy_section or
		copy_relocations_in_section fails.

2023-01-04  Alan Modra  <amodra@gmail.com>

	fuzzed file timeout
	objcopy of archive, element containing an object with a fuzzed section
	size far exceeding the element size.  copy_section detects this, but
	the temp file is laid out for the large section.  It can take a long
	time to write terabytes of sparse file, a waste of time when it will
	be deleted.

		* objcopy.c (copy_archive): Don't write element contents after
		bad status result from copy_object.

2023-01-04  Alan Modra  <amodra@gmail.com>

	asan: segv in parse_module
		* vms-alpha.c (parse_module): Ignore DST__K_SRC_SETFILE data
		if out of range.

2023-01-04  Alan Modra  <amodra@gmail.com>

	addr2line out of memory on fuzzed file
	Another case of fuzzers finding the section size sanity checks are
	avoided with SHT_NOBITS sections.

		* dwarf2.c (read_section): Check that the DWARF section being
		read has contents.

2023-01-04  Andrew Burgess  <aburgess@redhat.com>

	gdb: fix some #ifdef logic in bt-utils.h
	In passing I spotted some incorrect #ifdef logic in bt-utils.h.  The
	logic in question has existed since the file was originally added in
	commit:

	  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
	  Date:   Wed Aug 11 13:24:33 2021 +0100

	      gdb: use libbacktrace to create a better backtrace for fatal signals

	The code is trying to select between using libbacktrace or using the
	execinfo supplied backtrace API.

	First we check to see if we can use libbacktrace.  If we can then we
	include some header files, and then set some defines to indicate that
	libbacktrace is being used.

	Then we check if execinfo is available, if it is then we include
	<execinfo.h> and set some alternative defines.

	In theory the second block of logic should not trigger if the first
	block (that uses libbacktrace) has also triggered, but we incorrectly
	check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking
	for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second
	block triggers more than it should.  The
	'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this
	was a mistake in the original commit.

	In reality this is harmless, we include <execinfo.h> when we don't
	need too, but in by-utils.c the libbacktrace define is always checked
	for before the execinfo define, so we never actually end up using the
	execinfo path (when libbacktrace is available).  But I figure its
	still worth cleaning this up.

	I've tested GDB in a "default" build where libbacktrace is used, and
	when configuring with --disable-libbacktrace which causes the execinfo
	backtrace API to be used instead, both still appear to work fine.

	There should be no user visible changes after this commit.

2023-01-04  Bruno Larsen  <blarsen@redhat.com>

	gdb: add 'maintenance print record-instruction' command
	While chasing some reverse debugging bugs, I found myself wondering what
	was recorded by GDB to undo and redo a certain instruction. This commit
	implements a simple way of printing that information.

	If there isn't enough history to print the desired instruction (such as
	when the user hasn't started recording yet or when they request 2
	instructions back but only 1 was recorded), GDB warns the user like so:

	(gdb) maint print record-instruction
	Not enough recorded history

	If there is enough, GDB prints the instruction like so:

	(gdb) maint print record-instruction
	4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00
	Register eflags changed: [ IF ]
	Register rip changed: (void (*)()) 0x401115 <main+15>

	Approved-by: Eli Zaretskii <eliz@gnu.org>
	Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com>
	Reviewed-by: Lancelot Six <lsix@lancelotsix.com>
	Approved-by: Tom Tromey <tom@tromey.com>

2023-01-04  Andreas K. Huettel  <dilfridge@gentoo.org>

	Fix AArch64 linker testsuite failures trigeered by differences in build environments.
		PR 29843
		* testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow
		for differences in build environments.
		* testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise.

2023-01-04  Mark Harmstone  <mark@harmstone.com>

	Avoid unaligned pointer reads in PEP .idata section
	This is something I discovered when working on aarch64, though it's
	relevant to x86_64 too.

	The PE32+ imports are located in the .idata section, which starts off
	with a 20-byte structure for each DLL, containing offsets into the rest
	of the section. This is the Import Directory Table in
	https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, which
	is a concatenation of the .idata$2 sections. This is then followed by an
	20 zero bytes generated by the linker script, which calls this .idata$3.

	After this comes the .idata$4 entries for each function, which the
	loader overwrites with the function pointers. Because there's no padding
	between .idata$3 and .idata$4, this means that if there's an even number
	of DLLs, the function pointers won't be aligned on an 8-byte boundary.

	Misaligned reads are slower on x86_64, but this is more important on
	aarch64, as the e.g. `ldr x0, [x0, :lo12:__imp__func]` the compiler
	might generate requires __imp__func (the .idata$4 entry) to be aligned
	to 8 bytes. Without this you get IMAGE_REL_ARM64_PAGEOFFSET_12L overflow
	errors.

2023-01-04  Alan Modra  <amodra@gmail.com>

	Merge config/picflag.m4 from gcc
	and regen libiberty/configure

2023-01-04  Tsukasa OI  <research_trasio@irq.a4lg.com>

	sim: Regenerate using the maintainer mode
	Those files have changed by regenerating using the maintainer mode.
	The first line of sim/ppc/pk.h have changed by an effect of the commit
	319e41e83a40 ("sim: ppc: inline the sim-packages option").

2023-01-04  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-03  Max Filippov  <jcmvbkbc@gmail.com>

	opcodes: xtensa: fix jump visualization for FLIX
	opcodes/
		* xtensa-dis.c (print_insn_xtensa): Add local variables
		insn_type, target and imm_pcrel to track control flow across
		multiple slots.

	opcodes: xtensa: implement styled disassembly
	opcodes/
		* xtensa-dis.c (print_xtensa_operand)
		(print_insn_xtensa): Replace fprintf_func with
		fprintf_styled_func.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Add test case for "finish" with variably-sized types
	This adds a test case for "finish" with variably-sized types, and for
	inferior calls as well.  This also extends the "runto" proc to handle
	temporary breakpoints.

	Use value_at_non_lval in get_call_return_value
	get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION,
	because the call is completely managed by gdb.  However, it does not
	handle variably-sized types correctly.  The simplest way to fix this
	is to use value_at_non_lval, which does type resolution.

	Fix inferior calls with variably-sized return type
	This patch updates the gdbarch_return_value_as_value implementations
	to work correctly with variably-sized return types.

	Convert selected architectures to gdbarch_return_value_as_value
	This converts a few selected architectures to use
	gdbarch_return_value_as_value rather than gdbarch_return_value.  The
	architectures are just the ones that I am able to test.  This patch
	should not introduce any behavior changes.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Don't let property evaluation affect the current language
	On PPC, we saw that calling an inferior function could sometimes
	change the current language, because gdb would select the call dummy
	frame -- associated with _start.

	This patch changes gdb so that the current language is never affected
	by DWARF property evaluation.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Introduce value_at_non_lval
	In some cases, while a value might be read from memory, gdb should not
	record the value as being equivalent to that memory.

	In Ada, the inferior call code will call ada_convert_actual -- and
	here, if the argument is already in memory, that address will simply
	be reused.  However, for a call like "f(g())", the result of "g" might
	be on the stack and thus overwritten by the call to "f".

	This patch introduces a new function that is like value_at but that
	ensures that the result is non-lvalue.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Don't emit gdbarch_return_value
	The previous patch introduced a new overload of gdbarch_return_value.
	The intent here is that this new overload always be called by the core
	of gdb -- the previous implementation is effectively deprecated,
	because a call to the old-style method will not work with any
	converted architectures (whereas calling the new-style method is will
	delegate when needed).

	This patch changes gdbarch.py so that the old gdbarch_return_value
	wrapper function can be omitted.  This will prevent any errors from
	creeping in.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Add new overload of gdbarch_return_value
	The gdbarch "return_value" can't correctly handle variably-sized
	types.  The problem here is that the TYPE_LENGTH of such a type is 0,
	until the type is resolved, which requires reading memory.  However,
	gdbarch_return_value only accepts a buffer as an out parameter.

	Fixing this requires letting the implementation of the gdbarch method
	resolve the type and return a value -- that is, both the contents and
	the new type.

	After an attempt at this, I realized I wouldn't be able to correctly
	update all implementations (there are ~80) of this method.  So,
	instead, this patch adds a new method that falls back to the current
	method, and it updates gdb to only call the new method.  This way it's
	possible to incrementally convert the architectures that I am able to
	test.

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Fix crash in amd64-tdep.c
	amd64-tdep.c could crash when 'finish'ing from a function whose return
	type had variable length.  In this situation, the value will be passed
	by reference, and this patch avoids the crash.

	(Note that this does not fully fix the bug reported, but it does fix
	the crash, so it seems worthwhile to land independently.)

2023-01-03  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Add xfail in gdb.arch/i386-pkru.exp
	On a x86_64-linux machine with pkru register, I run into:
	...
	(gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
	info register pkru^M
	pkru           0x12345678          305419896^M
	(gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
	...

	This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
	onto ptrace()").  This is fixed by recent kernel commit 4a804c4f8356
	("x86/fpu: Allow PKRU to be (once again) written by ptrace.").

	The regression occurs for kernel versions v5.14-rc1 (the first tag containing
	the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).

	Fix this by adding an xfail for the appropriate kernel versions.

	Tested on x86_64-linux.

	PR testsuite/29790
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790

2023-01-03  Tom Tromey  <tromey@adacore.com>

	Do not use PyObject_CallNoArgs
	PyObject_CallNoArgs was introduced in Python 3.9, so avoid it in favor
	of PyObject_CallObject.

2023-01-03  Himal  <himalr@proton.me>

	Fix a potential problem in the BFD library when accessing the Windows' nul device driver.
		PR 29947
		* bfdio.c (_bfd_real_fopen): Do not add a prefix to the Windows'
		nul device filename.

2023-01-03  Nick Clifton  <nickc@redhat.com>

	Fix a translation problem in the x86 assembler.
		PR 29952
		* config/tc-i386.c (md_assemble): Avoid constructing translatable
		strings.

	Updated translations for various languages and sub-directories

2023-01-03  Luis Machado  <luis.machado@arm.com>

	Add new NT_ARM_ZA and NT_ARM_SSVE register set constants.

2023-01-03  Andrew Burgess  <aburgess@redhat.com>

	[gdb] Fix segfault during inferior call to ifunc
	With a simple test-case:
	...
	$ cat test.c
	char *p = "a";
	int main (void) {
	  return strlen (p);
	}
	$ gcc -g test.c
	...
	we run into this segfault:
	...
	$ gdb -q -batch a.out -ex start -ex "p strlen (p)"
	Temporary breakpoint 1 at 0x1151: file test.c, line 4.
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

	Temporary breakpoint 1, main () at test.c:4
	4	  return strlen (p);

	Fatal signal: Segmentation fault
	...

	The strlen is an ifunc, and consequently during the call to
	call_function_by_hand_dummy for "p strlen (p)" another call
	to call_function_by_hand_dummy is used to resolve the ifunc.

	This invalidates the get_current_frame () result in the outer call.

	Fix this by using prepare_reinflate and reinflate.

	Note that this series (
	https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ )
	should address this problem, but this patch is a simpler fix which is easy to
	backport.

	Tested on x86_64-linux.

	Co-Authored-By: Tom de Vries <tdevries@suse.de>
	PR gdb/29941
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941

2023-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: sh: move some generated source files to built sources
	This should have been part of the previous commit 80636a54bcfa2bca3dc8f
	("sim: build: move generated headers to built sources"), but they were
	missed because they're .c files effectively treated as .h files.

	sim: build: add var for tracking sim enable directly
	Rather than rely on SIM_SUBDIRS being set, add a dedicated variable
	to track whether to enable the sim.  While the current code works
	fine, it won't work as we remove the recursive make logic (i.e. the
	SIM_SUBDIRS variable).

	sim: common: drop libcommon.a linkage
	All of these objects should be in libsim.a already, so don't link to
	it too.  In practice it never gets used, but no point in listing it.

2023-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: build: move generated headers to built sources
	Automake's automatic header deptracking has a bootstrap problem where
	it can't detect generated headers when compiling.  We've been handling
	that by adding a custom SIM_ALL_RECURSIVE_DEPS variable, but that only
	works when building objects recursively in subdirs.  As we move those
	out to the top-level, we don't have any recursive steps anymore.  The
	Automake approach is to declare those headers in BUILT_SOURCES.

	This isn't completely foolproof as the Automake manual documents: it
	only activates for `make all`, not `make foo.o`, but that shouldn't be
	a huge limitation as it only affects the initial compile.  After that,
	rebuilds should work fine.

2023-01-03  Mike Frysinger  <vapier@gentoo.org>

	sim: cgen: drop common subdir build rules
	Now that everything has been hoisted to the top-level, we can delete
	this unused logic.

	sim: or1k: hoist cgen rules to top-level

	sim: m32r: hoist cgen rules to top-level

	sim: lm32: hoist cgen rules to top-level

	sim: iq2000: hoist cgen rules to top-level

	sim: frv: hoist cgen rules to top-level

	sim: cris: hoist cgen rules to top-level

	sim: bpf: hoist cgen rules to top-level

	sim: cgen: hoist rules to the top-level build
	The rules seem to generate the same output as existing subdir cgen
	rules with cgen ports, so hopefully this should be correct.  These
	are the last set of codegen rules that we run in subdirs, so this
	will help unblock killing off subdir builds entirely.

	sim: build: use Automake include vars
	Rather than define our own hack for emitting an include statement,
	use the existing Automake include variables.  These have the nice
	side-effect of being more portable.

2023-01-03  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-02  Tom Tromey  <tromey@adacore.com>

	Simplify debug_exp
	debug_exp should call expression::dump rather than using the 'op'
	member.

2023-01-02  Tom Tromey  <tromey@adacore.com>

	Initial implementation of Debugger Adapter Protocol
	The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
	to communicate with debuggers.  You can find more information here:

	    https://microsoft.github.io/debug-adapter-protocol/

	Frequently this is implemented as a shim, but it seemed to me that GDB
	could implement it directly, via the Python API.  This patch is the
	initial implementation.

	DAP is implemented as a new "interp".  This is slightly weird, because
	it doesn't act like an ordinary interpreter -- for example it doesn't
	implement a command syntax, and doesn't use GDB's ordinary event loop.
	However, this seemed like the best approach overall.

	To run GDB in this mode, use:

	    gdb -i=dap

	The DAP code will accept JSON-RPC messages on stdin and print
	responses to stdout.  GDB redirects the inferior's stdout to a new
	pipe so that output can be encapsulated by the protocol.

	The Python code uses multiple threads to do its work.  Separate
	threads are used for reading JSON from the client and for writing JSON
	to the client.  All GDB work is done in the main thread.  (The first
	implementation used asyncio, but this had some limitations, and so I
	rewrote it to use threads instead.)

	This is not a complete implementation of the protocol, but it does
	implement enough to demonstrate that the overall approach works.

	There is a rudimentary test suite.  It uses a JSON parser written in
	pure Tcl.  This parser is under the same license as Tcl itself, so I
	felt it was acceptable to simply import it into the tree.

	There is also a bit of documentation -- just documenting the new
	interpreter name.

2023-01-02  Jonas Hoerberg  <JHorberg@danfoss.com>

	Fix target remote pipe command for MinGW
	The cced7cacecad104fff0 ("gdb: preserve `|` in connection details string")
	commit added '|' detection and removal to ser-pipe.c, but missed to add it
	to ser-mingw.c.

	This results in the error message below for MinGW hosts:
	error starting child process '| <executable> <args>': CreateProcess: No such file or directory

	This commit add the missing '|' detection and removal to ser-mingw.c.

2023-01-02  Tom Tromey  <tromey@adacore.com>

	Remove target: prefix from gdb_sysroot in find_separate_debug_file
	I noticed that, when using gdbserver, gdb might print:

	Reading /usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
	Reading target:/usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...

	The second line has the "target:" prefix, but from the code it's clear
	that this string is being passed verbatim to gdbserver -- which seems
	wrong.

	I filed PR remote/29929 for this.

	The problem here is that find_separate_debug_file uses gdb_sysroot
	without checking to see if it starts with the "target:" prefix.  This
	patch changes this code to be a little more careful.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29929

2023-01-02  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with libstdc++ debug info
	On x86_64-linux, I run into:
	...
	(gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M
	Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M
	(gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \
	  Set hardware breakpoint
	...
	due to libstdc++ debug info:
	...
	$ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \
	  -ex start \
	  -ex "b add" \
	  -ex "info break"
	Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50.

	Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50
	50        int foo = 5;
	Breakpoint 2 at 0x40072e: add. (7 locations)
	Num     Type           Disp Enb Address            What
	2       breakpoint     keep y   <MULTIPLE>
	2.1                         y   0x000000000040072e in add(int) at \
	  py-breakpoint.c:39
	2.2                         y   0x00007ffff7b131de in \
	  (anonymous namespace)::fast_float::bigint::add at \
	  ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
	  ...
	2.7                         y   0x00007ffff7b137e4 in \
	  (anonymous namespace)::fast_float::bigint::add at \
	  ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
	...

	Fix this by using qualified=True.

	Tested on x86_64-linux.
	PR testsuite/29910
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910

2023-01-02  Mike Frysinger  <vapier@gentoo.org>

	sim: replace -I$srcroot/bfd include with -I$srcroot
	Clean up includes a bit by making ports include bfd/ headers
	explicitly.  This matches other projects, and makes it more clear
	where these headers are coming from.

	sim: replace -I$srcroot/opcodes include with -I$srcroot
	Clean up includes a bit by making ports include opcodes/ headers
	explicitly.  This matches other projects, and makes it more clear
	where these headers are coming from.

2023-01-02  Alan Modra  <amodra@gmail.com>

	obsolete target tidy
	Delete a few files only used for obsolete targets, and tidy config,
	xfails and other pieces of support specific to those targets.  And
	since I was editing target triplets in test files, fix the nm
	alpha-linuxecoff fails.

2023-01-02  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2023-01-01  Mike Frysinger  <vapier@gentoo.org>

	sim: build: drop unused SIM_EXTRA_LIBS
	Now that all run binaries are linked in the topdir, this subdir libs
	variable isn't used anywhere, so punt it.

	sim: erc32: drop -I$(srcroot)
	Since the port doesn't actually use this include, drop it.
	No other port is doing this either.

	sim: drop mention of & support for subdir configure
	Now that no ports use these common configure APIs, delete the logic
	and remove it from the documentation.

	sim: refresh copyright dates a bit
	Update a few files that were missed, and revert the generated Automake
	output that uses dates from Automake itself.

	sim: or1k: drop unused rules
	These rules are the same as the common ones, so drop them to simplify.

	sim: iq2000: drop unused cpu define logic
	These defines seem to have been added in anticipation of adding another
	cpu port (IQ10BF?), but that was over 20 years ago, and that port has
	yet to materialize.  So drop these compile flags since they don't do
	anything to the generated code.  If another port ever shows up, it's
	easy enough to readd things as needed.

2023-01-01  Joel Brobecker  <brobecker@adacore.com>

	manual copyright year range of various GDB files to add 2023
	This commit updates the following file...

	   gdb/doc/gdb.texinfo
	   gdb/doc/refcard.tex
	   gdb/syscalls/update-netbsd.sh

	... by hand as instructed by the gdb/copyright.py script.
	The update by hand is needed because the copyright headers
	to update are actually nested inside those files, rather
	than located at the start of the file.

2023-01-01  Joel Brobecker  <brobecker@adacore.com>

	Update copyright year range in header of all files managed by GDB
	This commit is the result of running the gdb/copyright.py script,
	which automated the update of the copyright year range for all
	source files managed by the GDB project to be updated to include
	year 2023.

2023-01-01  Joel Brobecker  <brobecker@adacore.com>

	gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...
	... to sim/ppc/powerpc.igen

	This file is in the NOT_FSF_LIST because this file has a copyright
	which is not assigned to the FSF. Since the file got renamed,
	the corresponding entry in NOT_FSF_LIST needs to be renamed as well.

2023-01-01  Joel Brobecker  <brobecker@adacore.com>

	Update copyright year in help message of gdb, gdbserver, gdbreplay
	This commit updates the copyright year displayed by gdb, gdbserver
	and gdbreplay's help message from 2022 to 2023, as per our Start
	of New Year procedure. The corresponding source files' copyright
	header are also updated accordingly.

2023-01-01  Alan Modra  <amodra@gmail.com>

	Update year range in gprofng copyright notices
	This adds 'Innovative Computing Labs' as an external author to
	update-copyright.py, to cover the copyright notice in
	gprofng/common/opteron_pcbe.c, and uses that plus another external
	author 'Oracle and' to update gprofng copyright dates.  I'm not going
	to commit 'Oracle and' as an accepted author, but that covers the
	string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All
	rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog
	files.

	Update year range in copyright notice of binutils files
	The newer update-copyright.py fixes file encoding too, removing cr/lf
	on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
	embedded cr in binutils/testsuite/binutils-all/ar.exp string match.

2023-01-01  Alan Modra  <amodra@gmail.com>

	Update etc/update-copyright.py
	This picks up some improvements from gcc/contrib.  exceptions must
	derive from BaseException, port to python3, retain original file mode,
	fix name of script in examples.

	Adds libsframe to list of default dirs.  I would have added gprofng
	too but there are some files claiming copyright by authors other than
	the Free Software Foundation.

2023-01-01  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2022-12-31  Nick Clifton  <nickc@redhat.com>

	Update version numbers in howto-make-a-release document

	Update version number and regenerate files

	Add markers for 2.40 branch

	sync libiberty sources with gcc mainline

2022-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/cli] Add maintenance ignore-probes
	There's a command "disable probes", but SystemTap probes, for instance
	libc:longjmp cannot be disabled:
	...
	$ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
	  ...
	Probe libc:longjmp cannot be disabled.
	Probe libc:longjmp cannot be disabled.
	Probe libc:longjmp cannot be disabled.
	...

	Add a command "maintenance ignore-probes" that ignores probes during
	get_probes, such that we can easily pretend to use a libc without the
	libc:longjmp probe:
	...
	(gdb) maint ignore-probes -verbose libc ^longjmp$
	ignore-probes filter has been set to:
	PROVIDER: 'libc'
	PROBE_NAME: '^longjmp$'
	OBJNAME: ''
	(gdb) start ^M
	  ...
	Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
	Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
	Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
	...

	The "Ignoring ..." messages can be suppressed by not using -verbose.

	Note that as with "disable probes", running simply "maint ignore-probes"
	ignores all probes.

	The ignore-probes filter can be reset by using:
	...
	(gdb) maint ignore-probes -reset
	ignore-probes filter has been reset
	...

	For now, the command is only supported for SystemTap probes.

	PR cli/27159
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159

2022-12-31  Mark Harmstone  <mark@harmstone.com>

	ld/testsuite: Don't add index to sizes in pdb.exp

	ld: Handle LF_VFTABLE types in PDBs

2022-12-31  Mark Harmstone  <mark@harmstone.com>

	ld: Handle extended-length data structures in PDB types
	A few fixes to minor issues I've discovered in my PDB patches.

	* If sizes or offsets are greater than 0x8000, they get encoded as
	extended values in the same way as for enum values - e.g. a LF_ULONG
	.short followed by a .long.

	* I've managed to coax MSVC to produce another type, LF_VFTABLE, which
	is seen when dealing with COM. I don't think LLVM emits this. Note that
	we can't just implement everything in Microsoft's header files, as most
	of it is obsolete.

	* Fixes a stupid bug in the test program, where I was adding an index to
	a size. The index was hard-coded to 0, so this didn't cause any actual
	issues.

2022-12-31  Nick Clifton  <nickc@redhat.com>

	Updated Romanian translation for the binutils sub-directory

2022-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32
	[ Partial resubmission of an earlier submission by Andrew (
	https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
	listing him as co-author. ]

	With x86_64-linux and target board unix/-m32, we have:
	...
	(gdb) continue^M
	Continuing.^M
	Exception #10^M
	^M
	Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
	23        throw new int (e);^M
	(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
	  check FinishBreakpoint in catch()
	...

	The following scenario happens:
	- set breakpoint in throw_exception_1, a function that throws an exception
	- continue
	- hit breakpoint, with call stack main.c:38 -> throw_exception_1
	- set a finish breakpoint
	- continue
	- hit the breakpoint again, with call stack main.c:48 -> throw_exception
	  -> throw_exception_1

	Due to the exception, the function call did not properly terminate, and the
	finish breakpoint didn't trigger.  This is expected behaviour.

	However, the intention is that gdb detects this situation at the next stop
	and calls the out_of_scope callback, which would result here in this test-case
	in a rather confusing "exception did not finish" message.  So the problem is
	that this message doesn't show up, in other words, the out_of_scope callback
	is not called.

	[ Note that the fact that the situation is detected only at the next stop
	(wherever that happens to be) could be improved upon, and the earlier
	submission did that by setting a longjmp breakpoint.  But I'm considering this
	problem out-of-scope for this patch. ]

	Note that the message does show up later, at thread exit:
	...
	[Inferior 1 (process 20046) exited with code 0236]^M
	exception did not finish ...^M
	...

	The decision on whether to call the out_of_scope call back is taken in
	bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
	...
	             if (b->pspace == current_inferior ()->pspace
	                 && (!target_has_registers ()
	                     || frame_find_by_id (b->frame_id) == NULL))
	               bpfinishpy_out_of_scope (finish_bp);
	...

	In the case of the thread exit, the callback triggers because
	target_has_registers () == 0.

	So why doesn't the callback trigger in the case of the breakpoint?

	Well, the b->frame_id is the frame_id of the frame of main (the frame
	in which the finish breakpoint is supposed to trigger), so AFAIU
	frame_find_by_id (b->frame_id) == NULL will only be true once we've
	left main, at which point I guess we don't stop till thread exit.

	Fix this by saving the frame in which the finish breakpoint was created, and
	using frame_find_by_id () == NULL on that frame instead, such that we have:
	...
	(gdb) continue^M
	Continuing.^M
	Exception #10^M
	^M
	Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
	23        throw new int (e);^M
	exception did not finish ...^M
	(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
	  check FinishBreakpoint in catch()
	...

	Still, the test-case is failing because it's setup to match the behaviour that
	we get on x86_64-linux with target board unix/-m64:
	...
	(gdb) continue^M
	Continuing.^M
	Exception #10^M
	stopped at ExceptionFinishBreakpoint^M
	(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
	  check FinishBreakpoint in catch()
	...

	So what happens here?  Again, due to the exception, the function call did not
	properly terminate, but the finish breakpoint still triggers.  This is somewhat
	unexpected.  This happens because it just so happens to be that the frame
	return address at which the breakpoint is set, is also the first instruction
	after the exception has been handled.  This is a know problem, filed as
	PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
	callback.

	Also add a breakpoint after setting the finish breakpoint but before throwing
	the exception, to check that we don't call the out_of_scope callback too early.

	Tested on x86_64-linux, with target boards unix/-m32.

	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
	PR python/27247
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247

2022-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1
	On ubuntu 22.04.1 x86_64, I run into:
	...
	(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
	  set print symbol-loading off
	sharedlibrary .*^M
	Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
	Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
	(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
	...

	The test-case expects the libc.so line, but not the libpthread.so line.

	However, we have:
	...
	$ ldd /lib/x86_64-linux-gnu/libc.so.6
		linux-vdso.so.1 (0x00007ffd7f7e7000)
		libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
		/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
		libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
		libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
	...
	so it's not unexpected that libpthread.so is loaded if libc.so is loaded.

	Fix this by accepting the libpthread.so line.

	Tested on x86_64-linux.

	PR testsuite/29919
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919

2022-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Replace deprecated pthread_yield in gdb.threads/watchpoint-fork.exp
	On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
	...
	watchpoint-fork-mt.c: In function 'start':^M
	watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
	  pthread_yield is deprecated, use sched_yield instead \
	  [-Wdeprecated-declarations]^M
	   67 |       i = pthread_yield ();^M
	      |       ^^M
	...

	Fix this as suggested, by using sched_yield instead.

	Tested on x86_64-linux.

2022-12-31  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35
	On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
	...
	(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
	bt^M
	 #0  __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
	 #1  __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
	 #2  __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
	 #3  0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
	 #4  0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
	 #5  0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
	 #6  0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
	 #7  0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
	(gdb) PASS: gdb.base/corefile.exp: backtrace
	up^M
	 #1  __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
	 78      in ./nptl/pthread_kill.c^M
	(gdb) FAIL: gdb.base/corefile.exp: up
	...

	The problem is that the regexp used here:
	...
	gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
	...
	does not fit the __pthread_kill_internal line which lacks the instruction
	address due to inlining.

	Fix this by making the regexp less strict.

	Tested on x86_64-linux.

2022-12-31  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2022-12-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc
	On ubuntu 22.04.1 x86_64, I run into:
	...
	(gdb) info probes all rtld rtld_map_complete^M
	No probes matched.^M
	(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
	UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
	...
	This has been filed as PR testsuite/17016.

	The problem is that the name rtld_map_complete is used, which was only
	available in Fedora 17, and upstream the name map_complete was used.

	In the email thread discussing a proposed patch (
	https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
	suggested to make the test-case handle both names.

	So, handle both names: map_complete and rtld_map_complete.

	This exposes the following FAIL:
	...
	(gdb) info sharedlibrary^M
	From To    Syms Read Shared Object Library^M
	$hex $hex  Yes       /lib64/ld-linux-x86-64.so.2^M
	$hex $hex  Yes (*)   /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
	$hex $hex  Yes       /lib/x86_64-linux-gnu/libc.so.6^M
	$hex $hex  Yes       /lib/x86_64-linux-gnu/libdl.so.2^M
	$hex $hex  Yes       /lib/x86_64-linux-gnu/libpthread.so.0^M
	(*): Shared library is missing debugging information.^M
	(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
	...
	due to using a glibc (v2.35) that has libpthread integrated into libc.

	Fix this by changing the FAIL into UNSUPPORTED.

	Tested on x86_64-linux.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016

2022-12-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with -fcf-protection
	On Ubuntu 22.04.1 x86_64, I run into:
	...
	gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
	gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
	  '-fcf-protection' are not compatible^M
	   22 | {                /* inc.1 */^M
	      | ^^M
	...

	Fix this by forcing -fcf-protection=none, if supported.

	Tested on x86_64-linux.

2022-12-30  Tom de Vries  <tdevries@suse.de>

	[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protection
	On Ubuntu 22.04.1 x86_64, I run into:
	...
	(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
	next^M
	51        if (t != NULL^M
	(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
	...

	This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
	...
	0000000000001180 <_Z13get_alias_setP4tree>:
	    1180:       f3 0f 1e fa             endbr64
	    1184:       48 85 ff                test   %rdi,%rdi
	...
	so the extra insn gets an is-stmt line number entry:
	...
	INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END
	  ...
	11     50     0x0000000000001180 Y
	12     50     0x0000000000001180
	13     51     0x0000000000001184 Y
	14     54     0x0000000000001184
	...
	and when stepping into get_alias_set we step to line 50:
	...
	(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
	step^M
	get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
	50      {^M
	...

	In contrast, with -fcf-protection=none, we get:
	...
	0000000000001170 <_Z13get_alias_setP4tree>:
	    1170:       48 85 ff                test   %rdi,%rdi
	...
	and:
	...
	INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END
	  ...
	11     50     0x0000000000001170 Y
	12     51     0x0000000000001170 Y
	13     54     0x0000000000001170
	...
	so when stepping into get_alias_set we step to line 51:
	...
	(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
	step^M
	get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
	51        if (t != NULL^M
	...

	Fix this by rewriting the gdb_test issuing the step command to check which
	line the step lands on, and issuing an extra next if needed.

	Tested on x86_64-linux, both with and without -fcf-protection=none.

	PR testsuite/29920
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920

2022-12-30  Tom de Vries  <tdevries@suse.de>

	[gdb/symtab] Make comp_unit_head.length private
	Make comp_unit_head.length private, to enforce using accessor functions.

	Replace accessor function get_length with get_length_with_initial and
	get_length_without_initial, to make it explicit which variant we're using.

	Tested on x86_64-linux.

	PR symtab/29343
	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343

2022-12-30  Alan Modra  <amodra@gmail.com>

	PR29948, heap-buffer-overflow in display_debug_lines_decoded
	This fixes a couple of places in display_debug_lines_decoded that were
	off by one in checking DWARF5 .debug_line directory indices.  It also
	displays the DWARF5 entry 0 for the program current directory rather
	than "." as is done for pre-DWARF5.  I decided against displaying
	DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf
	to minimally interpret debug info.

	binutils/
		PR 29948
		* dwarf.c (display_debug_lines_decoded): Display the given
		directory entry 0 for DWARF5.  Properly check directory index
		against number of entries in the table.  Revert to using
		unsigned int for n_directories and associated variables.
		Correct warning messages.
	gas/
		* testsuite/gas/elf/dwarf-5-loc0.d: Update.

2022-12-30  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2022-12-29  Tsukasa OI  <research_trasio@irq.a4lg.com>

	RISC-V: Simplify riscv_csr_address logic on state enable extensions
	This commit makes CSR class handling for 'Smstateen' and 'Ssstateen'
	extensions simpler using fall-throughs (as used in CSR_CLASS_I{,_32}).

	gas/ChangeLog:

		* config/tc-riscv.c (riscv_csr_address): Simplify the logic for
		'Smstateen' and 'Ssstateen' extensions.

2022-12-29  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in

2022-12-28  Tom Tromey  <tom@tromey.com>

	Use $decimal in timestamp.exp
	This patch fixes a review comment by Tom de Vries.  He pointed out
	that the new timestamp.exp should use the $decimal convenience regexp.

2022-12-28  Tom Tromey  <tom@tromey.com>

	Fix "set debug timestamp"
	PR cli/29945 points out that "set debug timestamp 1" stopped working
	-- this is a regression due to commit b8043d27 ("Remove a ui-related
	memory leak").

	This patch fixes the bug and adds a regression test.

	I think this should probably be backported to the gdb 13 branch.

	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945

2022-12-28  GDB Administrator  <gdbadmin@sourceware.org>

	Automatic date update in version.in